Перевод RFC 2960

| Приложения | | SCTP |

Один или несколько адресов IP

|

|

|

|

|

|

Один или |

несколько |

адресов IP |

|

Приложения | SCTP |

| ------------- |

|Транспортный | | сервис SCTP |

------------- |

Транспортный | сервис SCTP |

| ------------- |

| Сетевой | | сервис IP | | | | _____________ |

------------- |

Сетевой |

сервис IP |

|

_____________ |

На главную

Network Working Group Request for Comments: 2960 Category: Standards Track

R. Stewart

Q. Xie

Motorola

K. Morneault

C. Sharp

Cisco

H. Schwarzbauer

Siemens

T. Taylor

Nortel Networks

I. Rytina

Ericsson

M. Kalla

Telcordia

L. Zhang

UCLA

V. Paxson

ACIRI

October 2000

Протокол SCTP

Stream Control Transmission Protocol

Статус документа

Этот документ является спецификацией стандарта Internet, предназначенного для сообщества Internet, и служит приглашением к дискуссии в целях развития протокола. Сведения о текущем состоянии стандартизации протокола можно найти в документе "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Авторские права

Тезисы

Данный документ описывает протокол управления потоковой передачей SCTP¹. Протокол SCTP предназначен для передачи сигнальных сообщений PSTN² через сети IP, но может использоваться и для других приложений.

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

♦ передача данных с корректировкой ошибок, подтверждением доставки и отсутствием дубликатов;

♦ передача данных в соответствии с определенным для пути значением MTU³;

♦ упорядоченная доставка пользовательских сообщений внутри множества потоков с возможностью управления порядком доставки отдельных пользовательских сообщений;

♦ возможность группировки пользовательских сообщений в один пакет SCTP;

♦ устойчивость к отказам на сетевом уровне и поддержка многодомных хостов на обеих сторонах соединения.

Протокол SCTP включает механизмы предотвращения насыщения и устойчивости к атакам с использованием лавины пакетов (flooding) или маскированием адресов (masquerade).

¹ Stream Control Transmission Protocol.

² Телефонные сети общего назначения. Прим. перев.

³ Максимальный размер передаваемых пакетов. Прим. перев.

rfc.com.ru

Перевод RFC 2960

Оглавление

1. Введение ................................................................................................................................................................................. .... .................... 4

1.1 Мотивы создания ................................................................................................................................................................................ 4...

1.2 Архитектура SCTP ................................................................................................................................................................. ............. 4

1.3 Функциональность SCTP ......................................................................................................................................... ........................... 4

1.3.1 Создание и разрыв ассоциаций ............................................................................................................................. ..... .. .............. 5

1.3.2 Упорядоченная доставка в потоках ................................................................................................................................... .. ..... 5

1.3.3 Фрагментация пользовательских данных ............................................................................................................ .. ................... 5

1.3.4 Подтверждения и предотвращение насыщения ................................................................................................................ .....5

1.3.5 Группировка блоков (Chunk Bundling) .................................................................................................................... ................ 5

1.3.6 Проверка пакетов ................................................................................................................................................................ ...... 5.

1.3.7 Управление путями .............................................................................................................................................. ...................... 5

1.4 Терминология ................................................................................................................................................................................. ........6. .

1.5. Используемые сокращения ............................................................................................................................................................. ...7...

1.6 Порядковые номера ............................................................................................................................................................... .............. 7

2. Соглашения о терминах ............................................................................................................................................................................. 8....

3. Формат пакетов SCTP ........................................................................................................................................................ ....... ..................... 8

3.1 Описание полей общего заголовка SCTP ........................................................................................................................... .............. 8

3.2 Описание поля Chunk ......................................................................................................................................................... ...... ............. 9

3.2.1 Необязательные параметры и поля переменного размера ................................................................................................ .1. 0

3.3 Определения блоков SCTP ..................................................................................................................................... .......................... 10

3.3.1 Пользовательские данные (DATA) (0) ............................................................................................................................ ...... 10

3.3.2 Инициирование (INIT) (1) ...................................................................................................................................................... 11

3.3.2.1 Необязательные параметры и параметры переменного размера в блоке INIT ....................................... ................ 12

3.3.3 Подтверждение инициирования (INIT ACK) (2): ................................................................................................... .............. 13

3.3.3.1 Необязательные параметры и параметры переменной длины ................................................................... .............. 14

3.3.4 Селективное подтверждение (SACK) (3): .................................................................................................................. .......... 14

3.3.5 Запрос Heartbeat (HEARTBEAT) (4): ........................................................................................................................ ............. 15

3.3.6 Подтверждение Heartbeat (HEARTBEAT ACK) (5): .................................................................................................. .......... 15

3.3.7 Разрыв ассоциации (ABORT) (6): ...................................................................................................................... ..................... 16

3.3.8 Завершение ассоциации (SHUTDOWN) (7): ....................................................................................................................... ..1. 6.

3.3.9 Подтверждение закрытия ассоциации (SHUTDOWN ACK) (8): .............................................................................. .......... 16

3.3.10 Ошибка при работе (ERROR) (9): ..................................................................................................................................... .....1. .7

3.3.10.1 Некорректный идентификатор потока (1) ............................................................................................................... ..1. .7.

3.3.10.2 Отсутствует обязательный параметр (2) ............................................................................................................. ...... 17

3.3.10.3 Ошибка Stale Cookie (3) ............................................................................................................................................... 1. .7...

3.3.10.4 Нехватка ресурсов (4) ...................................................................................................................................... ............ 18

3.3.10.5 Не удалось преобразовать адрес (5) .......................................................................................................... ..... ............... 18

3.3.10.6 Не распознан тип блока (6) .......................................................................................................................... ................ 18

3.3.10.7 Некорректный обязательный параметр (7) ............................................................................................................... 18

3.3.10.8 Нераспознанные параметры (8) ................................................................................................................. ................. 18

3.3.10.9 Нет пользовательских данных (9) ............................................................................................................................ ..1..8.

3.3.10.10 Cookie Received While Shutting Down (10) .................................................................................................. ............. 19

3.3.11 Cookie Echo (COOKIE ECHO) (10): .......................................................................................................... ...................... 19

3.3.12 Подтверждение Cookie (COOKIE ACK) (11): ............................................................................................................. ........ 19

3.3.13 Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14): ............................................................................... 19

4. Диаграмма состояний ассоциации SCTP .......................................................................................................................................... ..... .19

5. Создание ассоциации ................................................................................................................................................................. ............... 20

5.1 Нормальное создание ассоциации ......................................................................................................................................... ......... 21

5.1.1 Обработка параметров потока ...................................................................................................................................... .......... 21

5.1.2 Обработка адресов ................................................................................................................................................................ ...2. .1. .

5.1.3 Генерация State Cookie ........................................................................................................................................ .................... 22

5.1.4 Обработка State Cookie ................................................................................................................................... .... ........................ 22

5.1.5 Аутентификация State Cookie ............................................................................................................................................... .2..3

5.1.6 Пример нормального создания ассоциации ................................................................................................................... ...... 23

5.2 Обработка дубликатов и неожиданных блоков INIT, INIT ACK, COOKIE ECHO, COOKIE ACK ............... .. ........................ 23

5.2.1 Блок INIT получен в состоянии COOKIE-WAIT или COOKIE-ECHOED (п. B) ............................................................ ....24

5.2.2 Неожиданный блок INIT в состоянии, отличном от CLOSED, COOKIE-ECHOED, COOKIE-WAIT и SHUTDOWN-ACK-SENT ................................................................................................................................................................................... .........2. 4

5.2.3 Неожиданный блок INIT ACK .................................................................................................................................... ........... 24

5.2.4 Обработка COOKIE ECHO при наличии TCB .................................................................................................................. ....2. 4

5.2.4.1Пример рестарта ассоциации ................................................................................................................................. ..... ....25

5.2.5 Обработка дубликатов COOKIE-ACK ................................................................................................................ .................... 25

5.2.6 Обработка ошибок Stale COOKIE .................................................................................................................................... .. ..... 25

5.3 Другие вопросы инициализации .................................................................................................................................................. ...26

5.3.1 Выбор значений тегов ........................................................................................................................................................... ....2. .6. .

6. Передача пользовательских данных ...................................................................................................................................................... .2..6...

6.1 Передача блоков DATA ......................................................................................................................................................... ..... ....... 26

6.2 Подтверждение приема блоков DATA ..................................................................................................................................... .........27

6.2.1 Обработка подтверждений SACK .................................................................................................................................... .. ..... 28

6.3 Управление таймером повтора передачи ............................................................................................................................... ..........29

6.3.1 Расчет RTO ............................................................................................................................................................................ ....2. 9

6.3.2 Правила для таймера повторной передачи ......................................................................................................... ..... ............... 29

6.3.3 Обработка завершения отсчета T3-rtx ............................................................................................................. ...................... 30

6.4 Многодомные хосты SCTP ............................................................................................................................................................ ....3..0..

6.4.1 Переключение с неактивного адреса получателя ................................................................................................................ 3. .0. .

rfc.com.ru 2 rfc.com.ru

Перевод RFC 2960

6.5 Идентификаторы и порядковые номера в потоке ...................................................................................................... ...... ............... 31

6.6 Упорядоченная и неупорядоченная доставка ................................................................................................................... ............ 31

6.7 Информация о пропусках в порядковых номерах TSN блоков DATA .................................................................. .................... 31

6.8 Расчет контрольной суммы Adler-32 .......................................................................................................................... ..................... 31

6.9 Фрагментация и сборка ........................................................................................................................................... .......................... 32

6.10 Группировка блоков ........................................................................................................................................................ ....... ........... 32

7. Контроль насыщения .................................................................................................................................................................. .............. 33

7.1 Различия в контроле насыщения для SCTP и TCP ................................................................................................................. ...... 33

7.2 Процедуры Slow-Start и Congestion Avoidance .............................................................................................................. ................ 33

7.2.1 Замедленный старт ......................................................................................................................................... .......................... 34

7.2.2 Предотвращение перегрузки ................................................................................................................................... ... .............. 34

7.2.3 Контроль насыщения ......................................................................................................................................... ...................... 34

7.2.4 Ускоренный повтор при пропуске ............................................................................................................................. ..... .. ...... 35

7.3 Определение MTU для пути .......................................................................................................................................................... ...3..5..

8. Контроль отказов ................................................................................................................................................................. ...................... 35

8.1 Обнаружение отказов конечных точек ........................................................................................................................... ..... .. .......... 35

8.2 Обнаружение сбоев в пути .................................................................................................................................................... ..... ....... 36

8.3 Проверка жизнеспособности пути ................................................................................................................................... ... .............. 36

8.4 Обработка пакетов OOTB .............................................................................................................................................................. ....3..7..

8.5 Правила для тегов верификации ........................................................................................................................................... .......... 37

8.5.1 Исключения из правил для Verification Tag ................................................................................................................. ........ 37

9. Прекращение работы ассоциации ........................................................................................................................................................... 3..8...

9.1 Разрыв ассоциации (Abort) ........................................................................................................................................... .................... 38

9.2 Завершение ассоциации (Shutdown) ...................................................................................................................................... .......... 38

10. Интерфейс с вышележащим уровнем .................................................................................................................................... ................ 39

10.1 ULP -> SCTP ................................................................................................................................................................................ ......3..9.

10.2 SCTP -> ULP .................................................................................................................................................................................... 4..4...

11. Вопросы безопасности ............................................................................................................................................................................ 4. .5

11.1 Security Objectives ............................................................................................................................................................ ................ 45

11.2 Реакция SCTP на потенциальные угрозы ............................................................................................................... ...................... 45

11.2.1 Учет возможности атак изнутри ................................................................................................................... ........................ 45

11.2.2 Защита от повреждения данных в сети ................................................................................................................... ............ 45

11.2.3 Сохранение конфиденциальности ..................................................................................................................................... ....4..5.

11.2.4 Защита от атак на службы вслепую (Blind DoS) ......................................................................................................... ....... 46

11.2.4.1 Лавинная атака (Flooding) ................................................................................................................................ ...... ........ 46

11.2.4.2 Слепое маскирование ............................................................................................................................................ ...... 46

11.2.4.3 Неправомерная монополизация ............................................................................................................. ...................... 47

11.3 Защита от мошенничества и отказа от оплаты ............................................................................................................... .... ......... 47

12. Рекомендуемые параметры TCB ....................................................................................................................................................... ......4..7

12.1 Параметры, требуемые для экземпляра SCTP ................................................................................................................ ............ 47

12.2 Параметры, требуемые для ассоциации в целом (например, TCB) .............................................................................. ............ 47

12.3 Данные для каждого транспортного адреса ............................................................................................................................ ....4. 8

12.4 Требуемые параметры общего назначения .............................................................................................................. .................... 48

13. Согласование с IANA ............................................................................................................................................................................. 4..8...

13.1 Расширения для блоков, определяемые IETF ........................................................................................................................... ......... 49

13.2 Определяемые IETF расширения для параметров блоков ................................................................................................... ...... 49

13.3 Определяемые IETF дополнительные коды причин ошибок ................................................................................................... .49

13.4 Идентификаторы передаваемых протоколов (Payload) ..................................................................................................... ......... 49

14. Предлагаемые параметры протокола SCTP ....................................................................................................................................... ..4. .9. .

15. Благодарности ............................................................................................................................................................................ ..... .. ........ 50

16. Адреса авторов ............................................................................................................................................................... .......................... 50

17. Документы .................................................................................................................................................................................... ............ 52

18. Библиография ........................................................................................................................................................................... ..... .... ......... 52

Приложение A: Явное уведомление о насыщении (ECN) ................................................................................................................... .....52

Приложение B Алгоритм Alder 32 для расчета контрольных сумм ........................................................................................... ............ 53

rfc.com.ru 3 rfc.com.ru

Перевод RFC 2960

1. Введение

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

1.1 Мотивы создания

Протокол TCP [RFC793] обеспечивает прежде всего гарантированную доставку данных в сетях IP. Однако многие современные приложения сталкиваются с ограниченными возможностями TCP и вынуждены реализовать свои средства обеспечения гарантированной доставки на основе транспорта UDP [RFC768]. Ниже перечислены основные ограничения TCP:

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

♦ Потоковая природа протокола TCP зачастую не подходит для приложений, которым приходится вводить свои средства маркировки записей для делинеаризации передаваемых сообщений. Кроме того, приложениям приходиться явно использовать средства “выталкивания” данных (push) для того, чтобы сообщение было передано полностью за разумное время.

♦ Ограниченные возможности сокетов TCP усложняют для приложений задачу обеспечения высокого уровня доступности при обмене данными за счет использования многодомных⁴ хостов.

♦ Протокол TCP достаточно слабо защищен от атак на службы⁵, в частности, от SYN-атак.

Передача сигнальных сообщений

PSTN через сети IP является примером приложения, которое сталкивается со всеми

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

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

Протокол SCTP размещается в многоуровневой модели между уровнем пользовательских приложений

SCTP и сетевым сервисом, не обеспечи

SCTP-узел A |< -------- Сетевой транспорт ------- >| SCTP-узел B

Рисунок 1 SCTP-ассоциация

В остальной части этого

документа предполагается, что SCTP работает “поверх” протокола IP.

Создание

Упорядоченная доставка в потоке

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

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

1.3 Функциональность SCTP

Транспортный сервис SCTP можно разделить на несколько функциональных групп, показанных на рисунке 2.

| Фрагментация польз. данных | ___________________________

разрыв

ассоциаций

Подтверждения

и предотвращения

насыщения

Связывание блоков

Проверка пакетов

| Управление путями | _______________________

Рисунок 2 Функциональное представление сервиса SCTP

⁴ Имеющих множество сетевых интерфейсов. Прим. перев.

⁵ denial of service attack

⁶ connection-oriented

rfc.com.ru

Перевод RFC 2960

1.3.1 Создание и разрыв ассоциаций

Ассоциации создаются по запросам пользователей SCTP (см. описание примитива ASSOCIATE на стр. 40 или SEND на стр. 40).

В процессе создания ассоциаций используется механизм cookie, подобный предложенному Кэрном (Karn) и Симпсоном (Simpson) в [RFC2522], для обеспечения защиты от атак. Этот механизм использует четырех этапное согласование (four-way handshake), в котором два последних этапа могут использоваться для передачи пользовательских данных в целях ускорения процедуры соединения. Стартовые последовательности описаны в главе 5 данного документа.

Протокол SCTP обеспечивает аккуратное завершение работы активных ассоциаций (shutdown) по запросу пользователя SCTP (см. описание примитива SHUTDOWN на стр. 40). Протокол SCTP позволяет также разрывать ассоциации (abort) по запросу пользователя (примитив ABORT) или в результате обнаружения ошибок на уровне SCTP. В главе 9 описаны оба варианта завершения работы ассоциаций.

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

1.3.2 Упорядоченная доставка в потоках

Термин поток (stream) используется в протоколе SCTP для обозначения последовательности пользовательских сообщений, которые доставляются протоколам вышележащих уровней в том же порядке, который сообщения имели в самом потоке. Это отличается от значения термина поток в контексте TCP, где потоком называют последовательности байтов (в этом документе предполагается, что размер байта составляет 8 битов.

Пользователь SCTP может во время создания ассоциации задать число потоков, поддерживаемых для этой ассоциации. Это значение согласуется с удаленной стороной (см. параграф 5.1.1). Пользовательские сообщения связываются с номерами потоков (см. примитивы SEND на стр. 40 и RECEIVE на стр. 41). Протокол SCTP присваивает порядковые номера потоков каждому сообщению, полученному протоколом от пользователя SCTP. На приемной стороне SCTP обеспечивает доставку сообщений пользователю с сохранением их последовательности в данном потоке. В силу того, что один поток может быть заблокирован ожиданием следующего по порядку пользовательского сообщения, в это время возможна доставка сообщений из других потоков.

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

1.3.3 Фрагментация пользовательских данных

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

1.3.4 Подтверждения и предотвращение насыщения

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

Функция подтверждения и предотвращения насыщения отвечает за повторную передачу пакетов, когда подтверждение о доставке не приходит от получателя вовремя. Повтор передачи связан с предотвращением насыщения подобно тому, как это сделано для протокола TCP. В главах 6 и 7 приводится подробное описание протокольных процедур, связанных с выполнением этой функции.

1.3.5 Группировка блоков (Chunk Bundling)

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

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

1.3.6 Проверка пакетов

Обязательное поле Verification Tag и 32-битовая контрольная сумма (см. Приложение B, в котором приведено описание алгоритма Adler-32), передаются в общем заголовке SCTP. Значение Verification Tag выбирается каждой стороной в процессе создания ассоциации. Пакеты, полученные без ожидаемого значения Verification Tag, отбрасываются в целях защиты от атак вслепую с маскированием адресов и избавления от старых пакетов SCTP, оставшихся от предыдущей ассоциации. Контрольная сумма Adler-32 помещается отправителем в каждый пакет SCTP для обеспечения дополнительной защиты от повреждения данных в сети. Получатель пакета SCTP с некорректной контрольной суммой Adler-32 отбрасывает такие пакеты без уведомления.

1.3.7 Управление путями

Передающий пакеты SCTP пользователь может манипулировать набором транспортных адресов, используемых для указания получателя пакетов SCTP с помощью примитивов, описанных в главе 10. Функция управления путями (SCTP path management) выбирает транспортный адрес получателя для каждого исходящего пакета SCTP на основе пользовательских инструкций и доступной информации о достижимости желанного для пользователя адреса. Функция управления путями ведет мониторинг доступности с помощью блоков heartbeat, когда другой трафик не позволяет получить достоверных данных о доступности адресов, и сообщает пользователю об изменениях состояния доступности любых адресов транспортного уровня на удаленной стороне. Функция управления путями отвечает также за передачу информации о доступных локальных адресах транспортного

⁷ Transmission Sequence Number – порядковый номер при передаче.

rfc.com.ru 5

rfc.com.ru

Перевод RFC 2960

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

При создании ассоциации определяется основной путь (primary path) для каждой конечной точки SCTP. Этот путь в дальнейшем используется при нормальных условиях работы.

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

Отметим, что Path Management и Packet Validation выполняются одновременно, хотя и описаны по-отдельности (в реальности эти не могут выполняться независимо одна от другой).

1.4 Терминология

Некоторые термины, используемые в контексте 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 (для конечной точки SCTP): номер TSN (и связанный с ним блок DATA), который был передан конечной точкой, но его получение еще не подтверждено.

♦ Path - путь: маршрут, используемый пакетами SCTP, переданными одной конечной точкой SCTP по определенному транспортному адресу другой конечной точки SCTP. Передача пакетов по различным транспортным адресам удаленной точки не обязательно ведет к изменению пути.

♦ Primary Path - основной путь: комбинация адресов отправителя и получателя которая будет помещаться в исходящие пакеты SCTP по умолчанию. Адрес отправителя включен в определение потому, что реализации протокола могут указывать оба адреса (получателя и отправителя) для обеспечения контроля пути возврата для блоков с откликами и выбора интерфейса для передачи пакетов многодомными хостами.

♦ Receiver Window (rwnd) - приемное окно: переменная SCTP, которую отправитель использует для хранения последнего рассчитанного значения размера окна приема своего партнера по ассоциации. Размер окна приема задается количеством байтов. Значение размера позволяет отправителю определить величину свободного пространства в приемном буфере получателя.

♦ SCTP association - ассоциация SCTP: протокольные отношения между конечными точками SCTP, включающие пару узлов SCTP и информацию о состоянии протокола (теги Verification Tag, активные значения TSN и т. п.). Для уникальной идентификации ассоциаций SCTP могут использоваться пары транспортных адресов конечных точек ассоциации. Между любой парой конечных точек SCTP недопустимо одновременное существование нескольких ассоциаций.

♦ SCTP endpoint - конечная точка SCTP: логический приемник/передатчик пакетов SCTP. Для многодомных хостов конечная точка SCTP представляется своему партнеру как комбинация набора допустимых транспортных адресов, по которым можно передавать пакеты SCTP и набора допустимых адресов транспортного уровня, с которых могут приниматься пакеты SCTP. Все транспортные адреса, используемые конечной точкой SCTP, должны быть связаны с одним номером порта, но могут иметь различные адреса IP. Транспортные адреса, используемые конечной точкой SCTP, недопустимо устанавливать для другой конечной точки SCTP (транспортный адрес каждой конечной точки SCTP должен быть уникальным).

rfc.com.ru

Перевод RFC 2960

♦ SCTP packet (packet) - пакет SCTP: элемент данных, передаваемый через интерфейс между SCTP и пакетной сетью без организации соединений (например, IP). Пакет SCTP включает общий заголовок SCTP, а также блок пользовательских данных (DATA chunk) и /или блок управления.

♦ SCTP user application (SCTP user) - пользовательское приложение SCTP (пользователь SCTP): логический объект вышележащего уровня, который использует сервис SCTP. Используется также термин Upper-layer Protocol (ULP).

♦ Slow Start Threshold (ssthresh) - порог Slow Start: переменная SCTP, определяющая пороговое значение, по которому конечная точка будет определять необходимость использования для конкретного транспортного адреса процедуры slow start или congestion avoidance. Значение ssthresh указывается в байтах.

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

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

♦ Stream Sequence Number - порядковый номер в потоке: 16-битовое беззнаковое целое число, используемое SCTP для обеспечения упорядоченной доставки пользовательских сообщений в данном потоке. Каждому пользовательскому сообщению в потоке присваивается один номер.

♦ Tie-Tags: теги Verification из предыдущей ассоциации. Эти теги используются в State Cookie для того, чтобы создаваемую ассоциацию можно было связать с предыдущей ассоциацией в той конечной точке где ассоциация не создается заново.

♦ 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.5. Используемые сокращения

MAC - Message Authentication Code [RFC2104] (код аутентификации сообщения)

RTO - Retransmission Time-out (тайм-аут повтора передачи)

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 (порядковый номер при передаче)

ULP - Upper-layer Protocol (протокол вышележащего уровня).

1.6 Порядковые номера

Важно помнить, что пространство пространство порядковых номеров TSN ограничено, хотя и достаточно велико. Значения порядковых номеров могут находиться в диапазоне от 0 до 2³² - 1. Ввиду конечных размеров пространства номеров TSN все арифметические операции с такими номерами должны осуществляться по модулю 2³² - это обеспечит после достижения максимального значения TSN снова перейти к номеру 0. При сравнении значений порядковых номеров следует принимать во внимание цикличность их изменения. Символ =< применительно к TSN означает “меньше или равно”(modulo 2³²).

При арифметических операциях и сравнении номеров TSN для протокола SCTP следует пользоваться арифметикой порядковых номеров ((Serial Number Arithmetic), определенной в [RFC1982] для случая SERIAL_BITS = 32.________________________________

rfc.com.ru 7 rfc.com.ru

Перевод RFC 2960

Конечным точкам не следует передавать блоки DATA со значением TSN, которое более чем на 2³¹ - 1 превышает начальное значение TSN для текущего окна передачи. Использование таких значений может привести к возникновению проблем при сравнении TSN.

Порядковые номера TSN сбрасываются в 0 при достижении границы 2³² - 1. Т. е., следующий блок DATA после блока с TSN = 2³²- 1 должен иметь TSN = 0.

Во всех арифметических операциях с порядковыми номерами в потоках (Stream Sequence Number) следует использовать арифметику порядковых номеров, определенную в [RFC1982] для случая SERIAL_BITS = 16.

Все прочие операции с порядковыми номерами в данном документе используют обычную арифметику.

2. Соглашения о терминах

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно

(OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC 2119]⁸.

3. Формат пакетов SCTP

Пакет SCTP состоит из общего заголов- 0 1 2 3

ка (common header) и блоков (chunk), 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 |

Формат пакетов SCTP показан на +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk #1 рисунке справа: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В одном пакете SCTP может содер- | ... |

жаться множество блоков, пока размер +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

пакета не превышает значение MTU. | Chunk #n |

Исключение составляют блоки INIT, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ INIT ACK, и SHUTDOWN COMPLETE,

которые недопустимо группировать с другими блоками в один пакет. Более подробное описание группировки блоков приводится в параграфе 6.10.

Если пользовательское сообщение не помещается в пакет SCTP, оно может быть разделено на фрагменты с использованием процедуры, описанной в параграфе 6.9.

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

3.1 Описание полей общего заголовка SCTP

Формат SCTP Common Header 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: 16 битов (целое

без знака) | Source Port Number | Destination Port Number |

Номер порта SCTP, используемого +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

отправителем. Это значение может | Verification Tag |

использоваться на приемной стороне +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

для идентификации ассоциации, к | Checksum |

которой относится пакет, вместе со +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ значениями IP-адреса отправителя, номера порта получателя и (возможно) IP-адреса получателя.

Destination Port Number: 16 битов (целое без знака)

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

Verification Tag: 32 бита (целое без знака)

Принимающая сторона использует Verification Tag для проверки отправителя пакета SCTP. На передающей стороне значение поля Verification Tag должно устанавливаться в соответствии со значением Initiate Tag, полученным от партнера при создании ассоциации, за исключением перечисленных ниже случаев:

♦ В пакетах, содержащих блок INIT, должно быть Verification Tag = 0.

♦ В пакетах, содержащих блок SHUTDOWN-COMPLETE с установленным флагом T-bit, значение Verification должно копироваться из пакета с блоком SHUTDOWN-ACK.

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

Более подробное описание приведено в параграфах 8.4 и 8.5.

Блок INIT должен быть единственным блоком в пакете SCTP.

Checksum: 32 бита (целое без знака)

Это поле содержит контрольную сумму для данного пакета SCTP. Расчет контрольных сумм описан в параграфе 6.8. Протокол SCTP использует алгоритм Adler-32, описанный в Приложении B.

⁸ На сайте rfc.com.ru имеется перевод этого документа на русский язык. Прим. перев.

rfc.com.ru 8 rfc.com.ru

Перевод RFC 2960

3.2 Описание поля Chunk

На рисунке справа показан формат блоков (chunk), передаваемых в пакетах SCTP. Каждый блок содержит поле Chunk Type, зависящие от типа флаги (Flags), поле размера Chunk Length и поле данных Value.

Chunk Type: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \

/ Chunk Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Это поле указывает тип блока, содер-

жащегося в поле Chunk Value. Поле типа может содержать значения от 0 до 254. Значение 255 зарезервировано для использования в качестве расширения.

Значения идентификаторов типа приведены в таблице:

Идентификатор Тип блока

0 Пользовательские данные (DATA)

Идентификатор

Тип блока

Зарезервировано для Explicit Congestion Notification Echo (ECNE)

Зарезервировано для Congestion Window Reduced (CWR)

Процедура окончания работы завершена (SHUTDOWN COMPLETE)

Резерв IETF

1 Инициализация(INIT)

2 Подтверждение инициирования (INIT ACK)

3 Выборочное подтверждение (SACK)

15 - 62

4 Запрос Heartbeat (HEARTBEAT) 63

5 Подтверждение Heartbeat (HEARTBEAT 64 - 126 ACK)

6 Прерывание (ABORT) 127

7 Завершение работы (SHUTDOWN) 128 - 190

Определенный IETF дополнительный блок Резерв IETF

8 Подтверждение завершения (SHUTDOWN 191 ACK)

9 Ошибка при операции (ERROR) 192 - 254

Определенный IETF дополнительный блок Резерв IETF

10 State Cookie (COOKIE ECHO)

255

Определенный IETF дополнительный блок

11 Подтверждение Cookie (COOKIE ACK)

Коды Chunk Type выбраны таким образом, два старших бита определяли действие, которое следует предпринять конечной точке на приемной стороне если Chunk Type не удается распознать.

00 – прекратить обработку данного пакета SCTP и отбросить его, не выполняя никаких действий по отношению к содержащейся в нем информации.

01 – прекратить обработку пакета SCTP и отбросить его без выполнения каких либо действий с содержащимися в пакете данными; указать неопознанный параметр в поле Unrecognized Parameter Type блока ERROR или INIT ACK.

10 – пропустить данный блок и продолжить обработку пакета.

11 – пропустить данный блок и продолжить обработку пакета с генерацией блока ERROR, содержащего в поле Unrecognized Chunk Type сведения о причине ошибки.

Отметим, что типы ECNE и CWR зарезервированы с целью использования в будущем для явного уведомления о насыщении (ECN⁹).

Chunk Flags: 8 битов

Использование этих битов определяется типом блока, указанным в поле Chunk Type. Если в документе явно не указано иное, на передающей стороне все биты следует устанавливать в 0, а на приемной - игнорировать.

Chunk Length: 16 битов (целое без знака)

Это поле указывает размер блока в байтах с учетом полей Chunk Type, Chunk Flags, Chunk Length и Chunk Value. Следовательно, для блоков и пустым Chunk Value поле Length имеет значение 4. Байты заполнения в поле Chunk Length не учитываются.

Chunk Value: переменный размер

Поле Chunk Value содержит данные, передаваемые в этом блоке. Формат этого поля и способы его использования зависят от значения Chunk Type.

Общий размер блока (включая поля Type, Length и Value) должен быть кратным 4. Если размер блока не кратен 4, отправитель должен дополнить блок 1 – 3 байтами со значением 0 для выравнивания размера. Получатель должен игнорировать байты заполнения.

Подробное описание используемых в SCTP блоков приводится в параграфе 3.3. Руководства для создания расширений, определяемых IETF, приведены в параграфе 13.1.

⁹ Explicit Congestion Notification

rfc.com.ru

Перевод RFC 2960

3.2.1 Необязательные парам

Блоки управления SCTP включают зависящий от типа блока заголовок с набором полей, за которым может следовать то или иное количество параметров. Необязательные параметры и поля переменной длины указываются в формате TLV¹⁰ как описано ниже.

0 1 2 iv>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \

/ Parameter Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type: знака)

16 битов (целое без

Поле Type содержит 16-битовый идентификатор типа параметра и может принимать значения от 0 до 65534. Значение 65535 зарезервировано для определяемых IETF расширений. Все значения, кроме тех которые перечислены в данном документе при описании отдельных типов блоков SCTP зарезервированы для использования IETF.

Parameter Length: 16 битов (целое без знака)

Поле Parameter Length определяет размер параметра в байтах с учетом полей Parameter Type, Parameter Length и Parameter Value. Следовательно, минимальное значение этого поля равно 4. Поле размера не учитывает байты заполнения.

Parameter Value: переменный размер.

Поле Parameter Value содержит информацию, передаваемую с помощью данного параметра.

Общий размер параметра (включая поля Type, Length и Value) должен быть кратным 4. Если размер параметра не кратен 4, поле Parameter Value дополняется в конце 1 -3 байтами с нулевым значением. Байты заполнения не учитываются в поле размера. Для отправителя недопустимо использование более 3 байтов заполнения. Получатель должен игнорировать байты заполнения.

Поле Parameter Type кодируется так, чтобы два старших бита определяли действия, предпринимаемые при обнаружении неизвестного параметра.

00 – прекращение обработки пакета SCTP и его отбрасывание без учета содержащихся в нем данных.

01 – прекращение обработки и отбрасывание пакета SCTP без обработки содержащихся в нем данных, но с генерацией сообщения об ошибке (блок ERROR или INIT ACK) с полем Unrecognized Parameter Type.

10 – пропуск параметра и продолжение обработки пакета.

11 - пропуск параметра и продолжение обработки пакета с генерацией сообщения об ошибке (блок ERROR или INIT ACK) с полем Unrecognized Parameter Type .

Параметры SCTP рассматриваются при описании конкретных блоков SCTP. Определяемые IETF параметры расширения описаны в параграфе 13.2.

3.3 Определения блоков SCTP

В этой главе описываются форматы блоков SCTP различного типа.

3.3.1 Пользовательские данные (DATA) (0)

Для блоков 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

Reserved: 5 битов

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type = 0 | Reserved|U|B|E| Length |

Отправитель должен заполнить это +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ поле нулями, а получатель – игнориро- | TSN |

вать его. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Stream Identifier S | Stream Sequence Number n | U bit: 1 бит +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Флаг разупорядочивания, устанавлива- | Payload Protocol Identifier |

емый для блоков DATA, которые могут +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ передаваться без сохранения порядка. \ \

Для таких блоков значение поля Stream / Пользовательские данные (последовательность n потока S) / Sequence Number не устанавливается, \ \

следовательно, получатель должен его +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ игнорировать.

После сборки (если она требуется) неупорядоченные блоки DATA должны диспетчеризоваться на вышележащий уровень без попыток восстановления порядка, если флаг U имеет значение 1.

B bit: 1 бит

Флаг первого фрагмента пользовательского сообщения.

E bit: 1 бит

Флаг последнего фрагмента пользовательского сообщения.

Для нефрагментированных пользовательских сообщений устанавливаются оба флага B и E. Нулевые значения обоих флагов указывают на один из промежуточных (не первый и не последний) фрагментов. Варианты состояния флагов показаны в таблице 1.

Таблица 1: Состояния флагов B и E

B E Описание

1 0 Первый фрагмент

0 0 Один из средних фрагментов

0 1 Последний фрагмент

1 1 Нефрагментированное сообщение

¹⁰ Type-Length-Value – Тип-Размер-Значение.

rfc.com.ru

Перевод RFC 2960

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

Length: 16 битов (целое без знака)

Это поле показывает размер блока DATA от начала поля типа и до конца пользовательских данных (без учета байтов заполнения). Для блоков DATA, не содержащих пользовательских данных, Length = 16.

TSN: 32 бита (целое без знака)

Это поле содержит порядковый номер TSN для блока DATA. Значения номеров TSN могут находиться в диапазоне от 0 до 4294967295 (2³² - 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 (чтобы обеспечить доступность информации для агентов в сети).

Нулевое значение показывает что протокол вышележащего уровня не указал идентификатор протокола для этого блока.

User Data: переменный размер

Это поле переменной длины содержит пользовательскую информацию. Реализация протокола должна обеспечивать выравнивание размеров поля по 4-байтовой границе путем добавления от 1 до 3 байтов с нулевым значением. Недопустимо учитывать байты в поле размера блока. Для отправителя недопустимо использование более 3 байтов заполнения.

3.3.2 Инициирование (INIT) (1)

Этот блок используется для создания 0 1 2 3

ассоциации SCTP между парой конеч- 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 ных точек. Формат блока INIT показан +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ на рисунке: | Type = 1 | Chunk Flags | Chunk Length |

Параметры блока INIT перечислены ниже. Если в описании явно не указано иное, каждый параметр должен включаться в блок INIT не более 1 раза.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Initiate Tag |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Advertised Receiver Window Credit (a_rwnd) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Параметры Initiate Tag, Advertised | Number of Outbound Streams | Number of Inbound Streams |

Receiver Window Credit, Number of +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outbound Streams, Number of Inbound | Initial TSN |

Streams и Initial TSN являются обяза- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

тельными и имеют фиксированные раз- \ \

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

необязательных параметров перемен- \ \

ной или фиксированной длины - IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address¹¹ (5), IPv6 Address¹¹ (6), Cookie

Preservative (9), ECN Capable¹² (32768 – 0x8000), Host Name Address¹³ (11), Supported Address Types¹⁴ (12).

Поле Chunk Flags в блоках INIT является резервным и отправитель должен установить нулевые значения во всех битах, а получатель – игнорировать это поле. Последующие параметры блока 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 зарезервировал для данной ассоциации. В течение срока существования ассоциации не следует снижать размер этого буфера (т. е., буфер может быть

¹¹ Блоки INIT могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

¹² Поле ECN capable зарезервировано для будущего использования с ECN.

¹³ Недопустимо включение в блок INIT более 1 параметра Host Name. Более того, для получателя недопустимо комбинировать в блоке INIT любые другие типы адресов с Host Name. Получатель блока INIT должен игнорировать адреса всех остальных типов при наличии в блоке INIT параметра Host Name.

¹⁴ Этот параметр используется для указания всех типов адресов, которые поддерживает передающая сторона. Отсутствие данного параметра говорит о поддержке передающей стороной адресов всех типов.

rfc.com.ru 11 rfc.com.ru

Перевод RFC 2960

удален только вместе с ассоциацией), однако конечная точка может изменить значение с помощью параметра a_rwnd, переданного в SACK.

Number of Outbound Streams (OS): 16 битов (целое без знака)

Указывает число исходящих потоков, которые отправитель блока INIT желает открыть для данной ассоциации. Для этого параметра недопустимо использование значения 0. При получении блока INIT с OS = 0 получателю следует прервать ассоциацию.

Number of Inbound Streams (MIS): 16 битов (целое без знака)

Определяет максимальное число потоков, которые отправитель данного блока INIT готов принять от удаленного партнера для этой ассоциации¹⁵. Использование значений 0 в данном поле недопустимо. При получении блока INIT с MIS = 0 получателю следует разорвать ассоциацию

Initial TSN (I-TSN): 32 бита (целое без знака)

Определяет начальное значение TSN, которое будет использовать отправитель (диапазон допустимых значений – от 0 до 42949672950. В это поле можно помещать значение поля Initiate Tag.

3.3.2.1 Необязательные параметры и параметры переменного размера в блоке INIT

Перечисленные ниже параметры используют формат TLV, как описано в параграфе 3.2.1. Любые комбинации параметров TLV должны размещаться в блоке после параметров фиксированного размера, описанных в предыдущем параграфе.

Параметр IPv4 Address (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 IPv4 Address: 32 бита (целое без знака) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Содержит адрес IPv4 для передающей | Type = 5 | Length = 8 |

стороны в двоичном формате. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 Address |

Параметр IPv6 Address (6) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 IPv6 Address: 128 битов (целое без

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 | Сстоодреорнжыи тв д ваодирченсом IпPрvе6д с тпаверлееднаиюи₁щ₆.ей

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | Вместе с параметром Source Port

| IPv6 Address | 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.

Отметим, что отсутствие параметров IP address в блоках INIT и INIT-ACK упрощает организацию ассоциаций при работе с использованием NAT.

Cookie Preservative (9) 0 1 2 3

Отправителю блока INIT следует использовать этот параметр для того, чтобы предложить получателю INIT увеличение срока жизни State Cookie.

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 (мсек.) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Suggested Cookie Life-span Increment:

32 бита (целое без знака)

Этот параметр показывает получателю размер увеличения срока жизни cookie в миллисекундах.

Этот необязательный параметр отправителю следует добавлять в блок INIT при попытке создания ассоциации после того, как предыдущая попытка сорвалась по причине ошибки в работе stale cookie. Получатель может проигнорировать предложенное увеличение срока жизни cookie в соответствии с принятой политикой безопасности.

Параметр Host Name (11)

Отправитель блока INIT использует этот параметр для передачи партнеру своего имени (Host Name) взамен адреса IP. Преобразование имени осуществляется на приемной стороне. Использование этого параметра может упростить создание ассоциаций через NAT.

¹⁵ В протоколе не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

¹⁶ Для отправителя недопустимо использование отображения адресов IPv4 на адреса Ipv6, описанное в [RFC2373]. Адреса IPv4 следует указывать с помощью параметра IPv4 Address Parameter.

rfc.com.ru 12 rfc.com.ru

Перевод RFC 2960

Host Name: переменный размер 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 Это поле содержит имя хоста с исполь- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ зRоFвCан1и1е2м3 Sсeиcнtтioаnкс 2и.с1а ,[RоFпCре1д1е2л3е]н. нМогеото дв | Type = 11 | Length |

преобразования имени в адрес выходит +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ за пределы спецификации протокола / Host Name /

SCTP. \ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Имя хоста должно содержать по крайней мере один завершающий нуль-символ, который учитывается в поле размера.

Supported Address Types (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 Отправитель блока INIT использует +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ этот параметр для перечисления всех | Type = 12 | Length |

типов поддерживаемых им адресов. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Type: 16 битов (целое без | Address Type #1 | Address Type #2 | знака) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ......

В этом поле указывается значение, типа +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ адреса из соответствующего TLV (например, IPv4 = 5, IPv6 = 6, Hostname = 11).

3.3.3 Подтверждение инициирования (INIT ACK) (2):

Блок INIT ACK используется для под- 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 SCTP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Параметры INIT ACK форматируются подобно параметрам блока INIT. Кроме того, блоки данного типа содержат два дополнительных параметра: State Cookie и Unrecognized Parameter.

| Type = 2 | Chunk Flags | Chunk Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Формат блока INIT ACK показан на ри- | Number of Outbound Streams | Number of Inbound Streams | сунке справа. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Initiate Tag: 32 бита (целое без знака)

| Initial TSN |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Получатель блока INIT ACK записывает \ \

значение параметра Initiate Tag. Это / Необязательные параметры и параметры переменной длины / значение должно помещаться в поле \ \

Verification Tag каждого пакета SCTP, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ который получатель INIT ACK будет передавать в данной ассоциации.

Для поля Initiate Tag недопустимо использование значения 0. Выбор значений параметра Initiate Tag рассматривается в параграфе 5.3.1.

Если в полученном блоке INIT ACK параметр Initiate Tag = 0, приемная сторона должна трактовать это как ошибку и прерывать ассоциацию с помощью ABORT.

Advertised Receiver Window Credit (a_rwnd): 32 бита (целое без знака)

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

Number of Outbound Streams (OS): 16 битов (целое без знака)

Определяет число исходящих потоков, которые отправитель INIT ACK желает создать для данной ассоциации. Недопустимо устанавливать для этого параметра значение 0.

Получателю блока INIT ACK с параметром OS = 0 следует закрыть ассоциацию, отбросив TCB.

Number of Inbound Streams (MIS): 16 битов (целое без знака)

Определяет максимальное число потоков, которые отправитель INIT ACK позволяет создать удаленному партнеру в данной ассоциации¹⁷. Недопустимо использование нулевого значения для этого параметра.

Получателю блока 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 Address¹⁸ (5), IPv6 Address¹³ (6), Unrecognized Parameters (8), ECN Capable¹⁹ (32768 – 0x8000) и Host Name²⁰ (11) являются необязательными.

¹⁷ В протоколе не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

¹⁸ Блоки INIT ACK могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

¹⁹ Поле ECN capable зарезервировано для будущего использования с ECN.

²⁰ Недопустимо включение в блок INIT ACK более 1 параметра Host Name. Более того, для получателя недопустимо комбинировать в блоке INIT ACK любые другие типы адресов с Host Name. Получатель блока INIT ACK должен игнорировать rfc.com.ru 13 rfc.com.ru

Перевод RFC 2960

Замечание для разработчиков: реализация протокола должна быть готова к приему достаточно больших блоков INIT ACK (более 1500 байтов) по причине наличия параметров переменной длины для state cookie и списка адресов. Например, если отвечающий на блок INIT хост имеет 1000 адресов IPv4, которые он желает сообщить партнеру, ему потребуется не менее 8000 байтов для включения этого списка в INIT ACK.

В комбинации с параметром Source Port из общего заголовка SCTP каждый параметр IP Address в блоке INIT ACK показывает получателю INIT ACK транспортный адрес отправителя INIT ACK, корректный в течение срока жизни создаваемой ассоциации.

Если INIT ACK содержит хотя бы один параметр IP Address, адрес отправителя в дейтаграмме, содержащей блок INIT, и любые адреса, указанные в INIT ACK, могут использоваться другой стороной при ответе в качестве адреса получателя. Если INIT ACK не содержит ни одного параметра IP Address, получившая блок INIT ACK конечная точка должна отправлять ответ по адресу отправителя в заголовке дейтаграммы IP, содержащей блок INIT ACK.

Параметры State Cookie и Unrecognized Parameters используют формат TLV в соответствии с определением параграфа 3.2.1 и описаны ниже.

Остальные поля соответствуют одноименным полям блока INIT.

3.3.3.1 Необязательные параметры и параметры переменной длины Параметр State Cookie (7)

Type: 7

Length: переменный размер, зависящий от длины Cookie

Value:

Этот параметр должен содержать всю информацию о параметрах и состоянии, требуемую отправителю данного блока INIT ACK для создания ассоциации вместе с кодом аутентификации MAC. Описание State Cookie приводится в параграфе 5.1.3.

Параметр Unrecognized Parameters (8)

Type: 8

Length: переменный размер.

Value:

Этот параметр возвращается отправителю блока INIT, если этот блок содержит значения, для которых отправителю должен передаваться отчет. Значение данного параметра будет содержать поле нераспознанного параметра, скопированное из блока INIT (все 3 поля Type, Length и Value).

3.3.4 Селективное подтверждение (SACK) (3):

Этот блок передается партнеру для 0 1 2 3

подтверждения приема блоков DATA т 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 информирования партнера о пропусках +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ в порядковых номерах блоков DATA, | Type = 3 |Chunk Flags | Chunk Length |

представленных в TSN. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Блок SACK должен содержать параметры Cumulative TSN Ack и Advertised Receiver Window Credit (a_rwnd).

| Cumulative TSN Ack |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Advertised Receiver Window Credit (a_rwnd) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |

По определению параметр Cumulative +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN Ack содержит значение последне- | Gap Ack Block #1 Start | Gap Ack Block #1 End |

го номера TSN, полученного до того, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

как была нарушена последователь- / /

ность принятых TSN; следующее за \ ... \

этим значение TSN (на 1 большее) еще / /

не получено стороной, передающей +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SACK. Этот параметр, следовательно, | Gap Ack Block #N Start | Gap Ack Block #N End |

подтверждает доставку всех TSN, но- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

мера которых не превышают значение | Duplicate TSN 1 |

параметра. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Обработка a_rwnd на принявшей SACK / /

стороне рассматривается в параграфе \ ... \

6.2.1. / /

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SACK может также содержать пара- | Duplicate TSN X |

метры Gap Ack Block, каждый из кото- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ рых подтверждает последовательность

TSN, полученных после прерывания основной последовательности номеров TSN. По определению все TSN, подтвержденные с помощью Gap Ack Block, имеют значения, превышающие Cumulative TSN Ack.

Chunk Flags: 8 битов

заполняется нулями на передающей стороне и игнорируется на приемной.

Cumulative TSN Ack: 32 бита (целое без знака)

Этот параметр содержит значение TSN последнего блока DATA, который был принят до прерывания последовательности номеров.

адреса всех остальных типов при наличии в блоке INIT ACK параметра Host Name.

rfc.com.ru 14 rfc.com.ru

Перевод RFC 2960

Advertised Receiver Window Credit (a_rwnd): 32 бита (целое без знака)

Это поле показывает обновленное значение размера (в байтах) приемного буфера на стороне отправителя данного блока SACK 9см. параграф 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 Block:

TSN=17

Эти поля содержат параметры 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, который был принят.

<- не получен

TSN=15

TSN=14

<- не получен

TSN=12

Gap Ack Block End: 16 битов (целое без знака)

TSN=11

Показывает финишное смещение TSN для

| Cumulative TSN Ack = 12

+ ------------------------------

| a_rwnd = 4660

+ ---------------- + --------------

| num of block=2 | num of dup=0 + ---------------- + --------------

I -+

данного Gap Ack Block. Для расчета

TSN=10

реального номера TSN это смещение ----------

добавляется к значению параметра Cumulative

TSN Ack. Рассчитанное таким способом значение TSN указывает последний

номер TSN в данном Gap Ack Block для принятого блока DATA.

Предположим для примера, что недавно принятые блоки DATA в момент принятия решения о передаче SACK образуют последовательность, показанную на рисунке справа. Тогда часть блока SACK должна включать поля, показанные на рисунке слева (предполагается, что новое значение a_rwnd = 4660).

|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 (HEAR

Конечной точке следует передавать такой запрос своему партнеру для проверки его доступности через тот или иной транспортный адрес, указанный для данной ассоциации.

Поле параметра Heartbeat Information имеет переменный размер и содержит структуру данных, понятную только отправителю.

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 (переменный размер) / \ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

Heartbeat Length: 16 битов (целое без знака)

Задает размер блока в байтах с учетом заголовка и поля Heartbeat Information.

Heartbeat Information: переменный размер

2 3

3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Содержит обязательный параметр Heartbeat Info (1) переменного размера, описанный в параграфе 3.2.1.

Устанавливаемое отправителем значение поля Heartbeat Info обычно включа-

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-specific Heartbeat Info /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ет текущее время отправителя в момент отправки блока HEARTBEAT и описание транспортного адреса, по которому передается HEARTBEAT (см. параграф 8.3).

3.3.6 Подтверждение Heartbeat (HEARTBEAT ACK) (5):

Конечной точке следует передавать такой блок в ответ на запрос HEARTBEAT (см. параграф 8.3). Блок HEARTBEAT ACK всегда передается по тому адресу IP, который был указан в заголовке дейтаграммы, содержавшей HEARTBEAT.

rfc.com.ru 15 rfc.com.ru

Перевод RFC 2960

Параметр 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 размер. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 битов | Type = 5 | Chunk Flags | Heartbeat Ack Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Устанавливается в 0 на передающей \ \

стороне и игнорируется на приемной. / Heartbeat Information TLV (переменный размер) /

\ \

Heartbeat Ack Length: 16 битов (целое +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ без знака)

Задает размер блока в байтах с учетом заголовка и поля Heartbeat Information.

Heartbeat Information: переменный размер

Это поле должно содержать параметр Heartbeat Information из запроса Heartbeat, на который передается отклик.

3.3.7 Разрыв ассоциации (AB

Блок ABORT передается партнеру для незамедлительного разрыва ассоциации. Блок ABORT может содержать параметры Error Cause, информирующие партнера о причинах разрыва ассоциации. Недопустимо группировать блоки DATA с блоком ABORT. Блоки управления (кроме INIT, INIT ACK и SHUTDOWN COMPLETE) могут груп-

0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \

/ Причины ошибок (Error Cause) /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

пироваться с ABORT, но эти блоки

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

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

Chunk Flags: 8 битов

Reserved: 7 битов

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

T bit: 1 бит

Бит T устанавливается в 0, если отправитель имеет TCB, который будет разрушен. При отсутствии разрушаемых TCB этот бит должен иметь значение 1.

Примечание: для верификации этого типа блоков служат специальные правила, описанные в параграфе 8.5.1.

Length: 16 битов (целое без знака)

Указывает размер блока в байтах с учетом заголовка и всех полей Error Cause. Определения причин ошибки (Error Cause) приведены в параграфе 3.3.10.

3.3.8 Завершение ассоциаци

Конечная точка ассоциации должна использовать этот блок для корректного завершения работы ассоциации. Формат блока описан ниже.

Chunk Flags: 8 битов

Устанавливается в 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 = 7 | Chunk Flags | Length = 8 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

стороне и игнорируется на приемной.

Length: 16 битов (целое без знака)

Показывает размер параметра и имеет значение 8.

Cumulative TSN Ack: 32 бита (целое без знака)

Этот параметр содержит номер последнего TSN, принятого без пропусков в нумерации²¹.

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

подтверждения приема блока

SHUTDOWN при завершении процессазакрытия, описанного в параграфе 9.2.

| Type = 8 |Chunk Flags | Length = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Блок SHUTDOWN ACK не содержит параметров.

²¹ Поскольку блок SHUTDOWN не содержит параметров Gap Ack Block, оно не может служить подтверждением TSN, принятых с нарушением порядка. В блоках SACK отсутствие Gap Ack Block, которые были указаны в предыдущих сообщениях, показывает, что получатель данных отказался от соответствующих блоков DATA. Поскольку SHUTDOWN не содержит Gap Ack Block, получателю блока SHUTDOWN не следует интерпретировать отсутствие Gap Ack Block как отказ (см. параграф 6.2).

rfc.com.ru 16

rfc.com.ru

Перевод RFC 2960

Chunk Flags: 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

3.3.10 Ошибка при работе (ERROR) (9):

Конечные точки передают блоки этого

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

типа для уведомления партнера о неко-

один или несколько кодов ошибок. Прием сообщения об ошибке не обязывает партнера разрывать ассоциацию, однако такие блоки могут передаваться вместе с блоком ABORT в качестве от-

| Type = 9 | Chunk Flags | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \

/ Один или несколько кодов Error Cause /

\ \

чета о причине разрыва. Параметры +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

блока описаны ниже.

Chunk Flags: 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

Length: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-specific Information /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Указывает размер блока в байтах с учетом заголовка и всех полей Error Cause.

Причины ошибок указываются как параметры переменного размера в соответствии с определением в параграфе 3.2.1.

Код Описание

1 Некорректный идентификатор потока

2 Отсутствие обязательного параметра

3 Ошибка Stale Cookie

Код

6 7 8

Описание

Нераспознанный тип блока Некорректный обязательный параметр Нераспознанные параметры

Cause Code: 16 битов (целое без знака)

Указывает тип причины, которая вызвала передачу сообщения.

Cause Length: 16 битов (целое без

знака)

4 Нехватка ресурсов 9 Отсутствие пользовательских данных

Указывает размер параметра в

5 Не удалось преобразовать адрес 10 Получение Cookie в процессе закрытия

байтах с учетом полей Cause Code, Cause Length и Cause-Specific Information

Cause-specific Information: переменный размер

В этом поле указываются сведения об ошибке. Причины ошибок SCTP рассматриваются в параграфах 3.3.10.1 - 3.3.10.10. Рекомендации по определению новых типов ошибок для IETF даны в параграфе 13.3.

3.3.10.1 Некорректный идентификатор потока (1) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=1 | Cause Length=8 |

Invalid Stream Identifier: показывает, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ чDтAо T Aк ,о нпеечрнедаяан нтыойчк ва н епсоулщуечситлвау ю бщлиойк | Stream Identifier | (Reserved) |

поток. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stream Identifier: 16 битов (целое без знака)

Этот параметр содержит значение Stream Identifier из блока DATA, вызвавшего ошибку.

Reserved: 16 битов

Зарезервированное поле. Устанавливается в 0 на передающей стороне и игнорируется на приемной.

3.3.10.2 Отсутствует обязательныйПричина ошибки

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Missing Mandatory Parameter: говорит об отсутствии одного или нескольких обязательных параметров TLV в принятом блоке INIT или INIT ACK.

Number of Missing params: 32 бита (целое без знака)

Это значение указывает число отсутствующих параметров, перечисленных в поле Cause-specific Information.

Missing Param Type: 16 битов (целое без знака)

Каждое поле содержит пропущенный обязательный параметр.

3.3.10.3 Ошибка Stale Cookie (3) Причина ошибки

rfc.com.ru

Перевод RFC 2960

Stale Cookie Error: говорит о получе- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ нии корректного значения State Cookie | Cause Code=3 | Cause Length=8 |

с истекшим сроком. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Measure of Staleness: 32 бита (целое без | Measure of Staleness (мксек.) |

знака) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В этом поле указывается разница между текущим временем и временем окончания срока действия State Cookie (в микросекундах).

Отправитель этого сообщения может указать время после завершения срока действия State Cookie отличным от нуля значением поля Measure of Staleness. Если отправитель не хочет передавать эти сведения, ему следует установить нулевое значение в поле Measure of Staleness.

3.3.10.4 Нехватка ресурсов (4) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=4 | Cause Length=4 |

Out of Resource: говорит о нехватке ре- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ сурсов. Обычно эта информация передается вместе с блоком ABORT.

3.3.10.5 Не удалось преобразовать адрес (5) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=5 | Cause Length |

Unresolvable Address: говорит о том, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ что конечной точке не удалось преоб- / Unresolvable Address /

рдаазнонвыайть т пиопл уадчреенснаыцйии а днрее сп о(дндаперржимивера-, \ \

ется). Обычно такое сообщение переда- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ется вместе с блоком ABORT. Unresolvable Address: переменный размер

Поле Unresolvable Address содержит полное значение параметра TLV, задающего адрес (или параметра Host Name), который не удалось преобразовать.

3.3.10.6 Не распознан тип блока (6) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=6 | Cause Length |

Unrecognized Chunk Type: эта инфор- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ме салции яп оплеурчедатаеелтсья ноет псрмаовгит еолпюр е дбеллоиктаь, / Unrecognized Chunk /

тип блока и два старших бита поля \ \

Chunk Type имеют значение 01 или 11. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Chunk: переменный размер

Поле Unrecognized Chunk содержит нераспознанный блок из пакета SCTP, включая поля Chunk Type, Chunk Flags и Chunk Length.

3.3.10.7 Некорректный обязательный параметр (7) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=7 | Cause Length=4 |

Invalid Mandatory Parameter: это +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ сообщение передается отправителю блока INIT или INIT ACK когда один или несколько обязательных параметров имеют некорректные значения.

3.3.10.8 Нераспознанные параметры (8) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=8 | Cause Length |

Unrecognized Parameters: это сообщение+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ вAоCз вKр, а ещсалеит спяо л уочтаптреалвюит енлею уд абелтоскяа р аIсNпIоT- / Unrecognized Parameters /

знать один или несколько необязатель-\ \

ных параметров TLV в блоке INIT ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Parameters: переменный размер

Поле Unrecognized Parameters содержит нераспознанные параметры, скопированные из блока INIT ACK полностью в форме TLV. Это сообщение обычно передается в блоках ERROR, объединенных с блоком COOKIE ECHO при отклике на INIT ACK, когда отправитель блока COOKIE ECHO желает сообщить о нераспознанных параметрах.

3.3.10.9 Нет пользовательских данных (9) Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=9 | Cause Length=8 |

No User Data: это сообщение передается +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ отытпйр абвлиотке лн юе с болдоеркаж иDт A пTоAль,з еосвлаите лпьрсикниях- / TSN value /

данных. \ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN value: 32 бита (целое без знака)

Значение поля TSN из блока DATA, с которым связана ошибка.

Это сообщение обычно передается в блоке ABORT (см. параграф 6.2)

rfc.com.ru 18 rfc.com.ru

Перевод RFC 2960

3.3.10.10 Cookie Received While Shutting Down (10)

Причина ошибки +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cause Code=10 | Cause Length=4 |

Cookie Received While Shutting Down:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ это сообщение говорит о приеме

COOKIE ECHO в то время, когда конечная точка находилась в состоянии SHUTDOWN-ACK-SENT. Обычно этот код возвращается в блоке ERROR сгруппированном с повторным блоком SHUTDOWN ACK.

3.3.11 Cookie Echo (COOKIE ECHO) (10):

Этот блок используется только в про- 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 /

блоку DATA, передаваемому через \ \

ассоциацию, но может быть сгруппиро- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ван с одним или несколькими блоками DATA в один пакет.

Chunk Flags: 8 bit

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

Length: 16 битов (целое без знака)

указывает размер блока в байтах, включая 4 байта заголовка блока и размер Cookie.

Cookie: переменный размер

Это поле должно содержать точную копию параметра State Cookie, полученного в предыдущем блоке INIT ACK.

Реализациям протокола следует стремиться к уменьшению размера cookie в целях обеспечения интероперабельности.

3.3.12 Подтверждение Cookie (COOKIE ACK) (11):

Этот тип блоков используется только 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

тверждением приема блока COOKIE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ECHO. Данный блок должен предше- | Type = 11 |Chunk Flags | Length = 4 |

ствовать любому блоку DATA или +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SACK в данной ассоциации, но может группироваться с одним или несколькими блоками DATA или блоком SACK в одном пакете SCTP.

Chunk Flags: 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приемной.

3.3.13 Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14):

Этот тип блоков должен использоваться для подтверждения приема блока SHUTDOWN ACK при завершении ассоциации (см. параграф 9.2).

Блок SHUTDOWN COMPLETE не содержит параметров.

0 1 2 3

Chunk Flags: 8 битов 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

Reserved: 7 битов +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Устанавливается в 0 на передающей +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ стороне и игнорируется на приемной.

T bit: 1 бит

Бит T устанавливается в 0, если отправитель имеет TCB, который будет разрушен. Если таких TCB, бит должен иметь значение 1.

Примечание: Для верификации этого типа блоков используются специальные правила, описанные в параграфе 8.5.1.

4. Диаграмма состояний ассоциации SCTP

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

rfc.com.ru 19 rfc.com.ru

Перевод RFC 2960

-------- (из любого состояния)

/ rcv ABORT [ABORT]

♦ вызовы пользовательских примитивов SCTP (например, [ASSOCIATE], [SHUTDOWN], [ABORT]);

♦ прием управляющих блоков INIT, COOKIE ECHO, ABORT, SHUTDOWN и т. п.;

♦ тайм-ауты.

Диаграмма состояний на рисунке справа показывает возможные состояния ассоциации и переходы между ними вместе с вызывающими эти переходы событиями и выполняемыми при смене состояния действиями. Некоторые ошибки не показаны на схеме состояний. Полное описание всех состояний и переходов приводится в тексте документа.

На схеме состояний имена блоков (Chunk) указаны заглавными буквами, а имена параметров начинаются с заглавной буквы (например, блок COOKIE ECHO, параметр State Cookie). Если смену состояния могут вызывать различные события, эти события выделены метками (A), (B) и т. д.

Примечания:

1) Если параметр State Cookie в принятом блоке COOKIE ECHO некорректен (например, не прошла проверка целостности), получатель должен отбросить пакет без уведомления. Если получен State Cookie с истекшим сроком (см. параграф 5.1.5), получатель должен оправить в ответ блок ERROR. В обоих случаях получатель остается в состоянии CLOSED.

2) Если истекло время по таймеру T1-init, конечная точка должна повторить передачу INIT и заново запустить таймер T1-init без смены своего состояния. Эти действия должны повторяться до MaxInitRetransmits раз после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.

3) Если истекло время по таймеру T1-cookie, конечная точка должна повторить передачу COOKIE ECHO и заново запустить таймер T1-cookie без смены состояния. Эта процедура должна повторяться до MaxInitRetransmits раз после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.

4) В состоянии SHUTDOWN-SENT конечная точка должна подтверждать все принятые блоки DATA без задержек.

5) В состоянии SHUTDOWN-RECEIVED для конечной точки недопустимо принимать любые новые запросы на передачу от пользователя SCTP.

6) В состоянии SHUTDOWN-RECEIVED конечная точка должна передать (возможно повторно) данные и выйти из этого состояния после того, как будут переданы все данные из очереди.

7) В состоянии SHUTDOWN-ACK-SENT для конечной точки недопустимо принимать от пользователя SCTP любые новые запросы на передачу.

Состояние CLOSED на схеме используется для того, чтобы показать, что ассоциация еще не создана (т .е., не существует).

5. Создание ассоциации

До того, как сможет произойти передача первых данных от одной конечной точки SCTP ("A") к другой ("Z"), эти две точки должны выполнить полностью процесс создания ассоциации.

rev INIT

| | ---------- или ----------

v v удалить TCB snd ABORT ------- + удалить TCB

генерация Cookie \ + ---------

и INIT ACK ---| CLOSED |

+ --------- +

[ASSOCIATE]

---------------

создать TCB

snd INIT

запустить таймер init

(1)

rcv корректн. COOKIE ECHO

\ I

+-----------+

| COOKIE-WAIT| (2)

создать TCB snd COOKIE ACK

rcv INIT ACK

-----------------

snd COOKIE ECHO остановить таймер init запустить таймер cookie

| COOKIE-ECHOED | (3) +-------------+

rcv COOKIE ACK

-----------------

остановить таймер cookie

| ESTABLISHED | + --------------- +

[SHUTDOWN]

(только из состояния ESTABLISHED)

------------------ |

проверить оставшиеся | блоки DATA |

+--------+

| SHUTDOWN- | |PENDING |

rcv SHUTDOWN/проверить оставшиеся блоки DATA

нет оставшихся блоков

snd SHUTDOWN запустить таймер shutdown

| SHUTDOWN- | (5,6) | RECEIVED | + ----------- +

(4) |SHUTDOWN-1 |SENT |

+--------+

(A) rcv SHUTDOWN ACK

ост. Таймер shutdown send SHUTDOWN COMPLETE удалить TCB

\rcv:SHUTDOWN \ (B) \ \ \ \ \ \ \ \

нет оставшихся блоков

(B)rcv SHUTDOWN

send SHUTDOWN ACK запустить таймер shutdown

send SHUTDOWN ACK зап. Таймер shutdown перейти в SHUTDOWN-ACK-SENT

| SHUTDOWN- | (7) | ACK-SENT | + ---------- +-(C)rcv SHUTDOWN COMPLETE

запустить таймер shutdown удалить TCB

(D)rcv SHUTDOWN ACK

останов. таймер shutdown send SHUTDOWN COMPLETE удалить TCB

\ + --------- + /

\-->| CLOSED |<--/ + --------- +

Рисунок 3 Диаграмма состояний протокола SCTP

Пользователю SCTP в конечной точке следует применять примитив ASSOCIATE для создания ассоциации с другой конечной точкой SCTP.

rfc.com.ru

Перевод RFC 2960

Примечания для разработчиков: С точки зрения пользователя SCTP ассоциация может быть создана неявно без использования примитива ASSOCIATE (см. 10.1 B) просто путем передачи первых пользовательских данных удаленному адресату. Инициирующий ассоциацию узел SCTP будет задавать принятые по умолчанию значения для всех обязательных и дополнительных параметров INIT/INIT ACK.

После создания ассоциации организуются двунаправленные потоки данных для передачи информации в обе стороны (см. параграф 5.1.1).

5.1 Нормальное создание ассоциации

Процесс инициализации описан ниже в предположении, что конечная точка "A" пытается создать ассоциацию, а точка "Z" принимает вызов.

A) Точка "A" сначала передает блок INIT точке "Z". В блока INIT точка "A" должна указать свой Verification Tag (Tag_A) в поле Initiate Tag. Для Tag_A следует использовать случайное число в диапазоне от 1 до 4294967295 (см. рекомендации по выбору значения тега в параграфе 5.3.1). После передачи блока INIT точка "A" запускает таймер T1-init и переходит в состояние COOKIE-WAIT.

B) Точке "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).

C) При получении блока INIT ACK от "Z" точке "A" следует остановить таймер T1-init и выйти из состояния COOKIE-WAIT. Далее точке "A" следует передать значение State Cookie из принятого блока INIT ACK в ответном блоке COOKIE ECHO²³, запустить таймер T1-cookie и перейти в состояние COOKIE-ECHOED.

D) При получении блока COOKIE ECHO точка "Z" будет передавать блок COOKIE ACK после создания TCB и перехода в состояние ESTABLISHED. Блок COOKIE ACK может объединяться с любыми ожидающими передачи блоками DATA и/или SACK, но блок COOKIE ACK должен быть первым в пакете.

Примечание для разработчиков: реализация протокола может передавать уведомление Communication Up пользователю SCTP при получении корректного блока COOKIE ECHO.

E) Приняв блок COOKIE ACK, точка "A" будет переходить из состояния COOKIE-ECHOED в состояние ESTABLISHED, останавливая таймер T1-cookie. Она может также уведомить ULP об успешном создании ассоциации с помощью Communication Up (см. главу 10).

Блоки 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, полученное от партнера.

После получения первого блока 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 Обработка адресов

В процессе создания ассоциации конечным точкам следует использовать перечисленные ниже правила для определения и сохранения транспортных адресов своего партнера.

A) Если в принятом блоке INIT или INIT ACK нет адресных параметров, следует взять адрес отправителя из заголовка пакета IP, в котором был доставлен блок, и сохранить этот адрес вместе с номером порта SCTP, использованным отправителем пакета, как единственный транспортный адрес партнера.

²² Сразу передачи INIT ACK с параметром State Cookie для точки "Z" недопустимо выделять какие-либо ресурсы или сохранять какие-либо состояния для новой ассоциации, поскольку это сделает точку "Z" уязвимой для атак на ресурсы системы.

²³ Блок COOKIE ECHO может группироваться с любыми ожидающими передачи блоками DATA, но эти блоки должны размещаться в пакете после блока COOKIE ECHO. До получения ответного блока COOKIE ACK недопустима передача каких-бы то ни было пакетов удаленному партнеру.

rfc.com.ru 21 rfc.com.ru

Перевод RFC 2960

B) Если параметр в полученном блоке INIT или INIT ACK присутствует параметр Host Name, имя следует преобразовать в адрес (список адресов) IP и сохранить транспортные адреса партнера как комбинации полученных при преобразовании адресов IP и номера порта отправителя SCTP. Конечная точка должна игнорировать все дополнительные параметры с IP-адресами, если они присутствуют в блоке INIT или INIT ACK.

Пока получатель блока INIT выполняет преобразование имени хоста в адрес, он подвержен потенциальному риску атак SCTP. Если получатель INIT преобразует имя хоста в адрес при получении блока и используемый механизм преобразования может вносить достаточно большую задержку (например, запросы DNS), получатель может открыть себя для атаки на ресурсы в течение периода ожидания результатов преобразования имени до создания State Cookie и освобождения локальных ресурсов.

Следовательно, в тех случаях, когда преобразование имен может происходить достаточно долго, получатель INIT должен отложить процедуру преобразования до того, как будет получен блок COOKIE ECHO от партнера. В таких случаях получателю INIT следует создать State Cookie с использованием полученного значения Host Name (вместо транспортного адреса получателя) и передать блок INIT ACK по адресу отправителя из заголовка IP в пакете, содержащем принятый блок INIT.

Получателю INIT ACK всегда следует незамедлительно предпринять попытку преобразования имени после получения блока.

Для получателя INIT или INIT ACK недопустима передача пользовательских данных до преобразования имени хоста в адрес.

Если не удается преобразовать имя, конечная точка должна незамедлительно передать своему партнеру блок ABORT с причиной ошибки "Unresolvable Address". Блок ABORT следует отправлять по адресу IP из заголовка пакета, в котором был получен блок от партнера.

C) Если в принятом блоке INIT или INIT ACK присутствуют только адреса IPv4/IPv6, получателю следует выделить и записать все транспортные адреса из полученного блока и адреса отправителя в заголовке IP пакета, содержащего блок INIT или INIT ACK. Транспортные адреса представляют собой комбинацию номера порта SCTP (из общего заголовка) и адресов IP, переданных в блоке INIT или INIT ACK и заголовке пакета IP, доставившего блок. Получателю следует использовать только эти транспортные адреса для передачи последующих пакетов удаленному партнеру.

Примечания для разработчиков: В некоторых случаях (например, когда реализация не контролирует 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 для индикации предпочтительных типов адресов.

5.1.3 Генерация State Cookie

При передаче блока INIT ACK в ответ на INIT отправитель INIT ACK создает значение State Cookie и передает его в одноименном параметре блока INIT ACK. В параметр State Cookie отправителю следует включить MAC (см., например, [RFC2104]), временную метку генерации State Cookie и время жизни параметра State Cookie, а также другую информацию, требуемую для создания ассоциации.

При генерации State Cookie следует выполнить перечисленные ниже операции:

1) Создать для ассоциации TCB с использованием информации из полученного блока INIT и передаваемого блока INIT ACK.

2) В TCB установить время создания по текущему времени суток, а для времени жизни использовать протокольный параметр 'Valid.Cookie.Life'.

3) Из TCB выделить и сохранить минимальный набор информации, требуемой для повторного создания TCB, и создать MAC с использованием этого набора и секретного ключа (см. пример генерации MAC в [RFC2104]).

4) Создать State Cookie, объединив минимальный набор информации и полученное значение MAC.

После передачи блока INIT ACK с параметром State Cookie отправителю следует удалить TCB и все прочие локальные ресурсы, связанные с новой ассоциацией в целях предотвращения атак на ресурсы.

Метод хеширования, используемый для генерации MAC является приватным делом получателя блока INIT. Использование MAC является обязательным с целью предотвращения атак на службы. В качестве секретного ключа следует использовать случайное значение (см. рекомендации [RFC1750]), которое следует менять достаточно часто. Для идентификации ключа, который будет использоваться для проверки 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'. Если

rfc.com.ru 22 rfc.com.ru

Перевод RFC 2960

заданное число попыток не привело CLOSED.

к успеху, партнер помечается как недоступный и ассоциация переводится в положение

5.1.5 Аутентификация State Cookie

Когда конечная точка получает блок COOKIE ECHO от другой конечной точки, с которой нет действующей ассоциации, следует выполнить перечисленные ниже операции:

1) Рассчитать MAC с использованием данных TCB, полученных в State Cookie, и секретного ключа (отметим, что для выбора секретного ключа может использоваться временная метка из State Cookie. Рекомендации по расчету MAC приведены в [RFC2104].

2) Проверить State Cookie, сравнивая рассчитанное значение MAC с полученным в State Cookie. При наличии расхождений пакет SCTP, включающий COOKIE ECHO и любые блоки DATA следует отбросить без уведомления отправителя.

3) Сравнить временную метку в State Cookie с текущим временем локальной системы. Если разница превышает срок заданный существования State Cookie, пакет, содержащий COOKIE ECHO и любые блоки DATA, следует отбросить. Конечная точка в таком случае должна передать партнеру блок ERROR с причиной ошибки "Stale Cookie",

4) Если значение State Cookie корректно, создается ассоциация с отправителем COOKIE ECHO, создается TCB с использованием данных из блока COOKIE ECHO и конечная точка переходит в состояние ESTABLISHED,

5) Передать блок COOKIE ACK удаленному партнеру для подтверждения приема COOKIE ECHO. Блок COOKIE ACK может группироваться с пользовательскими блоками DATA или блоком SACK, однако блок COOKIE ACK должен размещаться в пакете SCTP первым.

6) Незамедлительно подтвердить получение любых блоков DATA, сгруппированных с COOKIE ECHO путем передачи блока SACK (подтверждения последующих блоков DATA передаются с использованием правил, рассмотренных в параграфе 6.2). Как было отмечено в п. 5), блок SACK, группируемый с COOKIE ACK, должен размещаться в пакете SCTP после блока COOKIE ACK .

При получении блока COOKIE ECHO от конечной точки, операции, рассмотренные в параграфе 5.2.

с которой получатель имеет работающую ассоциацию, выполняются

5.1.6 Пример нормального создания а

В показанном на рисунке примере точка "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

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

Появление дубликатов и неожиданных установочных


	На главную




	Network Working Group Request for Comments: 2960 Category: Standards Track			R. Stewart Q. Xie Motorola K. Morneault C. Sharp Cisco H. Schwarzbauer Siemens T. Taylor Nortel Networks I. Rytina Ericsson M. Kalla Telcordia L. Zhang UCLA V. Paxson ACIRI October 2000

	Протокол SCTP Stream Control Transmission Protocol Статус документа Этот документ является спецификацией стандарта Internet, предназначенного для сообщества Internet, и служит приглашением к дискуссии в целях развития протокола. Сведения о текущем состоянии стандартизации протокола можно найти в документе "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений. Авторские права Copyright (C) The Internet Society (2000). All Rights Reserved. Тезисы Данный документ описывает протокол управления потоковой передачей SCTP¹. Протокол SCTP предназначен для передачи сигнальных сообщений PSTN² через сети IP, но может использоваться и для других приложений. SCTP представляет собой протокол транспортного уровня с гарантированной доставкой, работающий в пакетных сетях без явной организации соединений таких, как IP. Протокол обеспечивает пользователям следующие типы сервиса: ♦ передача данных с корректировкой ошибок, подтверждением доставки и отсутствием дубликатов; ♦ передача данных в соответствии с определенным для пути значением MTU³; ♦ упорядоченная доставка пользовательских сообщений внутри множества потоков с возможностью управления порядком доставки отдельных пользовательских сообщений; ♦ возможность группировки пользовательских сообщений в один пакет SCTP; ♦ устойчивость к отказам на сетевом уровне и поддержка многодомных хостов на обеих сторонах соединения. Протокол SCTP включает механизмы предотвращения насыщения и устойчивости к атакам с использованием лавины пакетов (flooding) или маскированием адресов (masquerade).

	¹ Stream Control Transmission Protocol. ² Телефонные сети общего назначения. Прим. перев. ³ Максимальный размер передаваемых пакетов. Прим. перев. rfc.com.ru			rfc.com.ru



		Перевод RFC 2960

	Оглавление 1. Введение ................................................................................................................................................................................. .... .................... 4 1.1 Мотивы создания ................................................................................................................................................................................ 4... 1.2 Архитектура SCTP ................................................................................................................................................................. ............. 4 1.3 Функциональность SCTP ......................................................................................................................................... ........................... 4 1.3.1 Создание и разрыв ассоциаций ............................................................................................................................. ..... .. .............. 5 1.3.2 Упорядоченная доставка в потоках ................................................................................................................................... .. ..... 5 1.3.3 Фрагментация пользовательских данных ............................................................................................................ .. ................... 5 1.3.4 Подтверждения и предотвращение насыщения ................................................................................................................ .....5 1.3.5 Группировка блоков (Chunk Bundling) .................................................................................................................... ................ 5 1.3.6 Проверка пакетов ................................................................................................................................................................ ...... 5. 1.3.7 Управление путями .............................................................................................................................................. ...................... 5 1.4 Терминология ................................................................................................................................................................................. ........6. . 1.5. Используемые сокращения ............................................................................................................................................................. ...7... 1.6 Порядковые номера ............................................................................................................................................................... .............. 7 2. Соглашения о терминах ............................................................................................................................................................................. 8.... 3. Формат пакетов SCTP ........................................................................................................................................................ ....... ..................... 8 3.1 Описание полей общего заголовка SCTP ........................................................................................................................... .............. 8 3.2 Описание поля Chunk ......................................................................................................................................................... ...... ............. 9 3.2.1 Необязательные параметры и поля переменного размера ................................................................................................ .1. 0 3.3 Определения блоков SCTP ..................................................................................................................................... .......................... 10 3.3.1 Пользовательские данные (DATA) (0) ............................................................................................................................ ...... 10 3.3.2 Инициирование (INIT) (1) ...................................................................................................................................................... 11 3.3.2.1 Необязательные параметры и параметры переменного размера в блоке INIT ....................................... ................ 12 3.3.3 Подтверждение инициирования (INIT ACK) (2): ................................................................................................... .............. 13 3.3.3.1 Необязательные параметры и параметры переменной длины ................................................................... .............. 14 3.3.4 Селективное подтверждение (SACK) (3): .................................................................................................................. .......... 14 3.3.5 Запрос Heartbeat (HEARTBEAT) (4): ........................................................................................................................ ............. 15 3.3.6 Подтверждение Heartbeat (HEARTBEAT ACK) (5): .................................................................................................. .......... 15 3.3.7 Разрыв ассоциации (ABORT) (6): ...................................................................................................................... ..................... 16 3.3.8 Завершение ассоциации (SHUTDOWN) (7): ....................................................................................................................... ..1. 6. 3.3.9 Подтверждение закрытия ассоциации (SHUTDOWN ACK) (8): .............................................................................. .......... 16 3.3.10 Ошибка при работе (ERROR) (9): ..................................................................................................................................... .....1. .7 3.3.10.1 Некорректный идентификатор потока (1) ............................................................................................................... ..1. .7. 3.3.10.2 Отсутствует обязательный параметр (2) ............................................................................................................. ...... 17 3.3.10.3 Ошибка Stale Cookie (3) ............................................................................................................................................... 1. .7... 3.3.10.4 Нехватка ресурсов (4) ...................................................................................................................................... ............ 18 3.3.10.5 Не удалось преобразовать адрес (5) .......................................................................................................... ..... ............... 18 3.3.10.6 Не распознан тип блока (6) .......................................................................................................................... ................ 18 3.3.10.7 Некорректный обязательный параметр (7) ............................................................................................................... 18 3.3.10.8 Нераспознанные параметры (8) ................................................................................................................. ................. 18 3.3.10.9 Нет пользовательских данных (9) ............................................................................................................................ ..1..8. 3.3.10.10 Cookie Received While Shutting Down (10) .................................................................................................. ............. 19 3.3.11 Cookie Echo (COOKIE ECHO) (10): .......................................................................................................... ...................... 19 3.3.12 Подтверждение Cookie (COOKIE ACK) (11): ............................................................................................................. ........ 19 3.3.13 Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14): ............................................................................... 19 4. Диаграмма состояний ассоциации SCTP .......................................................................................................................................... ..... .19 5. Создание ассоциации ................................................................................................................................................................. ............... 20 5.1 Нормальное создание ассоциации ......................................................................................................................................... ......... 21 5.1.1 Обработка параметров потока ...................................................................................................................................... .......... 21 5.1.2 Обработка адресов ................................................................................................................................................................ ...2. .1. . 5.1.3 Генерация State Cookie ........................................................................................................................................ .................... 22 5.1.4 Обработка State Cookie ................................................................................................................................... .... ........................ 22 5.1.5 Аутентификация State Cookie ............................................................................................................................................... .2..3 5.1.6 Пример нормального создания ассоциации ................................................................................................................... ...... 23 5.2 Обработка дубликатов и неожиданных блоков INIT, INIT ACK, COOKIE ECHO, COOKIE ACK ............... .. ........................ 23 5.2.1 Блок INIT получен в состоянии COOKIE-WAIT или COOKIE-ECHOED (п. B) ............................................................ ....24 5.2.2 Неожиданный блок INIT в состоянии, отличном от CLOSED, COOKIE-ECHOED, COOKIE-WAIT и SHUTDOWN-ACK-SENT ................................................................................................................................................................................... .........2. 4 5.2.3 Неожиданный блок INIT ACK .................................................................................................................................... ........... 24 5.2.4 Обработка COOKIE ECHO при наличии TCB .................................................................................................................. ....2. 4 5.2.4.1Пример рестарта ассоциации ................................................................................................................................. ..... ....25 5.2.5 Обработка дубликатов COOKIE-ACK ................................................................................................................ .................... 25 5.2.6 Обработка ошибок Stale COOKIE .................................................................................................................................... .. ..... 25 5.3 Другие вопросы инициализации .................................................................................................................................................. ...26 5.3.1 Выбор значений тегов ........................................................................................................................................................... ....2. .6. . 6. Передача пользовательских данных ...................................................................................................................................................... .2..6... 6.1 Передача блоков DATA ......................................................................................................................................................... ..... ....... 26 6.2 Подтверждение приема блоков DATA ..................................................................................................................................... .........27 6.2.1 Обработка подтверждений SACK .................................................................................................................................... .. ..... 28 6.3 Управление таймером повтора передачи ............................................................................................................................... ..........29 6.3.1 Расчет RTO ............................................................................................................................................................................ ....2. 9 6.3.2 Правила для таймера повторной передачи ......................................................................................................... ..... ............... 29 6.3.3 Обработка завершения отсчета T3-rtx ............................................................................................................. ...................... 30 6.4 Многодомные хосты SCTP ............................................................................................................................................................ ....3..0.. 6.4.1 Переключение с неактивного адреса получателя ................................................................................................................ 3. .0. . rfc.com.ru 2 rfc.com.ru



Перевод RFC 2960
3.2 Описание поля Chunk На рисунке справа показан формат блоков (chunk), передаваемых в пакетах SCTP. Каждый блок содержит поле Chunk Type, зависящие от типа флаги (Flags), поле размера Chunk Length и поле данных Value. Chunk Type: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Chunk Type \| Chunk Flags \| Chunk Length \| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Это поле указывает тип блока, содер-
жащегося в поле Chunk Value. Поле типа может содержать значения от 0 до 254. Значение 255 зарезервировано для использования в качестве расширения. Значения идентификаторов типа приведены в таблице:

*Идентификатор* *Тип блока* 0 Пользовательские данные (DATA)		*Идентификатор* 12 13			*Тип блока* Зарезервировано для Explicit Congestion Notification Echo (ECNE) Зарезервировано для Congestion Window Reduced (CWR) Процедура окончания работы завершена (SHUTDOWN COMPLETE) Резерв IETF
1 Инициализация(INIT) 2 Подтверждение инициирования (INIT ACK) 3 Выборочное подтверждение (SACK)
		14
		15 - 62

4 Запрос Heartbeat (HEARTBEAT) 63 5 Подтверждение Heartbeat (HEARTBEAT 64 - 126 ACK) 6 Прерывание (ABORT) 127 7 Завершение работы (SHUTDOWN) 128 - 190				Определенный IETF дополнительный блок Резерв IETF Определенный IETF дополнительный блок Резерв IETF

8 Подтверждение завершения (SHUTDOWN 191 ACK) 9 Ошибка при операции (ERROR) 192 - 254				Определенный IETF дополнительный блок Резерв IETF

10 State Cookie (COOKIE ECHO)			255	Определенный IETF дополнительный блок

11 Подтверждение Cookie (COOKIE ACK) Коды Chunk Type выбраны таким образом, два старших бита определяли действие, которое следует предпринять конечной точке на приемной стороне если Chunk Type не удается распознать. 00 – прекратить обработку данного пакета SCTP и отбросить его, не выполняя никаких действий по отношению к содержащейся в нем информации. 01 – прекратить обработку пакета SCTP и отбросить его без выполнения каких либо действий с содержащимися в пакете данными; указать неопознанный параметр в поле Unrecognized Parameter Type блока ERROR или INIT ACK. 10 – пропустить данный блок и продолжить обработку пакета. 11 – пропустить данный блок и продолжить обработку пакета с генерацией блока ERROR, содержащего в поле Unrecognized Chunk Type сведения о причине ошибки. Отметим, что типы ECNE и CWR зарезервированы с целью использования в будущем для явного уведомления о насыщении (ECN⁹). Chunk Flags: 8 битов Использование этих битов определяется типом блока, указанным в поле Chunk Type. Если в документе явно не указано иное, на передающей стороне все биты следует устанавливать в 0, а на приемной - игнорировать. Chunk Length: 16 битов (целое без знака) Это поле указывает размер блока в байтах с учетом полей Chunk Type, Chunk Flags, Chunk Length и Chunk Value. Следовательно, для блоков и пустым Chunk Value поле Length имеет значение 4. Байты заполнения в поле Chunk Length не учитываются. Chunk Value: переменный размер Поле Chunk Value содержит данные, передаваемые в этом блоке. Формат этого поля и способы его использования зависят от значения Chunk Type. Общий размер блока (включая поля Type, Length и Value) должен быть кратным 4. Если размер блока не кратен 4, отправитель должен дополнить блок 1 – 3 байтами со значением 0 для выравнивания размера. Получатель должен игнорировать байты заполнения. Подробное описание используемых в SCTP блоков приводится в параграфе 3.3. Руководства для создания расширений, определяемых IETF, приведены в параграфе 13.1.

⁹ Explicit Congestion Notification rfc.com.ru	9				rfc.com.ru



	Перевод RFC 2960 Host Name: переменный размер 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 Это поле содержит имя хоста с исполь- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ зRоFвCан1и1е2м3 Sсeиcнtтioаnкс 2и.с1а ,[RоFпCре1д1е2л3е]н. нМогеото дв \| Type = 11 \| Length \| преобразования имени в адрес выходит +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ за пределы спецификации протокола / Host Name / SCTP. \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Имя хоста должно содержать по крайней мере один завершающий нуль-символ, который учитывается в поле размера. Supported Address Types (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 Отправитель блока INIT использует +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ этот параметр для перечисления всех \| Type = 12 \| Length \| типов поддерживаемых им адресов. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type: 16 битов (целое без \| Address Type #1 \| Address Type #2 \| знака) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| ...... В этом поле указывается значение, типа +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ адреса из соответствующего TLV (например, IPv4 = 5, IPv6 = 6, Hostname = 11). *3.3.3 Подтверждение инициирования (INIT ACK) (2):* Блок INIT ACK используется для под- 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 SCTP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Параметры INIT ACK форматируются подобно параметрам блока INIT. Кроме того, блоки данного типа содержат два дополнительных параметра: State Cookie и Unrecognized Parameter.	\| Type = 2 \| Chunk Flags \| Chunk Length \| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Initiate Tag \| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Advertised Receiver Window Credit \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Формат блока INIT ACK показан на ри- \| Number of Outbound Streams \| Number of Inbound Streams \| сунке справа. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Initiate Tag: 32 бита (целое без знака)	\| Initial TSN \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Получатель блока INIT ACK записывает \ \ значение параметра Initiate Tag. Это / Необязательные параметры и параметры переменной длины / значение должно помещаться в поле \ \ Verification Tag каждого пакета SCTP, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ который получатель INIT ACK будет передавать в данной ассоциации. Для поля Initiate Tag недопустимо использование значения 0. Выбор значений параметра Initiate Tag рассматривается в параграфе 5.3.1. Если в полученном блоке INIT ACK параметр Initiate Tag = 0, приемная сторона должна трактовать это как ошибку и прерывать ассоциацию с помощью ABORT. Advertised Receiver Window Credit (a_rwnd): 32 бита (целое без знака) Это значение указывает размер буфера (в байтах), выделенного отправителем INIT ACK для данной ассоциации. Во время существования ассоциации не следует уменьшать размер буфера (т. е., выделенный буфер должен умереть вместе с ассоциацией). Number of Outbound Streams (OS): 16 битов (целое без знака) Определяет число исходящих потоков, которые отправитель INIT ACK желает создать для данной ассоциации. Недопустимо устанавливать для этого параметра значение 0. Получателю блока INIT ACK с параметром OS = 0 следует закрыть ассоциацию, отбросив TCB. Number of Inbound Streams (MIS): 16 битов (целое без знака) Определяет максимальное число потоков, которые отправитель INIT ACK позволяет создать удаленному партнеру в данной ассоциации¹⁷. Недопустимо использование нулевого значения для этого параметра. Получателю блока 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 Address¹⁸ (5), IPv6 Address¹³ (6), Unrecognized Parameters (8), ECN Capable¹⁹ (32768 – 0x8000) и Host Name²⁰ (11) являются необязательными. ¹⁷ В протоколе не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1. ¹⁸ Блоки INIT ACK могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях. ¹⁹ Поле ECN capable зарезервировано для будущего использования с ECN. ²⁰ Недопустимо включение в блок INIT ACK более 1 параметра Host Name. Более того, для получателя недопустимо комбинировать в блоке INIT ACK любые другие типы адресов с Host Name. Получатель блока INIT ACK должен игнорировать rfc.com.ru 13 rfc.com.ru