RFC 2960 (часть 2)

image_print

Часть 1

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

Данные должны передаваться только в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Единственным исключением из этого правила является возможность включения блоков DATA в пакеты, содержащие блок COOKIE ECHO, в состоянии COOKIE-WAIT.

Блоки DATA должны приниматься только в соответствии с приведенными ниже правилами в состояниях ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. Блок DATA, полученный в состоянии CLOSED, следует обрабатывать в соответствии со специальными правилами, описанными в параграфе 8.4. Блоки DATA, полученные во всех прочих состояниях, следует отбрасывать.

           +----------------------------+
           | Пользовательское сообщение |
           +----------------------------+
Пользователь SCTP ^  |
==================|==|===================================
                  |  v (1)
         +------------------+    +----------------------+
         | Блоки SCTP DATA  |    |Блоки управления SCTP |
         +------------------+    +----------------------+
                    ^  |             ^  |
                    |  v (2)         |  v (2)
                 +--------------------------+
                 |      Пакеты SCTP         |
                 +--------------------------+
   SCTP                      ^  |
=============================|==|========================
                             |  v
Пакетный сервис без организации соединений (например, IP)

Примечания.

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

  2. Множество блоков DATA и блоков управления может группироваться отправителем в один пакет SCTP, пока размер результирующего пакета не будет превышать значение path MTU. Получатель будет разбирать групповой пакет, выделяя из него отдельные блоки. Блоки управления должны размещаться в пакете перед блоками DATA.

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

 

Подтверждения SACK должны обрабатываться в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Входящий блок SACK может быть обработан ассоциацией в состоянии COOKIE-ECHOED. Подтверждения SACK в состоянии CLOSED следует обрабатывать в соответствии со специальными правилами, рассмотренными в параграфе 8.4. Во всех прочих состояниях блоки SACK следует отбрасывать.

Получатель SCTP должен быть способен принимать пакеты SCTP размером как минимум 1500 байтов. Это означает, что для конечной точки SCTP недопустимо указывать значение меньше 1500 в стартовом параметре a_rwnd, передаваемом в INIT или INIT ACK.

Для эффективной передачи трафика протокол SCTP поддерживает механизм группировки мелких пользовательских сообщений и фрагментации больших сообщений. На рисунке 6 показана схема обмена пользовательскими сообщениями в SCTP.

В этом параграфе термин «отправитель» (data sender) будет указывать конечную точку, которая передает блок DATA, а термин «получатель» (data receiver) – конечную точку, принимающую блок DATA. Получатель подтверждает прием данных блоком SACK.

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

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

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

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

  1. В любой момент для отправителя недопустимо передавать новые данные по любому транспортному адресу получателя, если значение rwnd, полученное от партнера, говорит об отсутствии свободного пространства в буфере (т. е., rwnd = 0, см. параграф 6.2.1). Однако, независимо от значения rwnd (включая 0), отправитель может всегда держать один блок DATA пути к получателю, если позволяет cwnd (см. правило B). Это позволяет отправителю проверять изменение rwnd, о котором отправитель не знает по причине утери подтверждения SACK в процессе доставки от получателя.
  2. В любой момент времени для отправителя недопустимо передавать информацию по данному транспортному адресу, если имеется cwnd или более неподтвержденных байтов данных для этого адреса.
  3. Когда приходит время отправителю передавать данные, перед отправкой новых блоков DATA он должен сначала передать неподтвержденные блоки DATA, которые помечены для повтора (не более cwnd).
  4. Отправитель может передать столько новых блоков DATA, сколько позволяют правила A и B.

Множество блоков DATA, подготовленных для передачи, можно сгруппировать в один пакет. Более того, передаваемые повторно блоки DATA можно группировать с новыми блоками DATA, пока размер результирующего пакета не превышает path MTU. Протокол вышележащего уровня (ULP) может запросить передачу сообщений без группировки, но это означает лишь отключение задержек, которые реализация SCTP может использовать для повышения эффективности группировки. Группировка может происходить и в этом случае (например, при перегрузках или повторе передачи).

До того, как конечная точка передаст блок DATA, отправителю следует создать блок SACK для всех неподтвержденных данных и сгруппировать его с передаваемыми блоками DATA, пока размер результирующего пакета не превышает значение MTU (см. параграф 6.2).

Примечание для разработчиков. При заполнении окна (передача запрещена правилом A и/или B), отправитель может по-прежнему принимать запросы на передачу от вышележащего протокола, но он должен остановить передачу блоков DATA, пока некоторые или все остающиеся блоки DATA не будут подтверждены и правила A и B не будут выполнены.

Когда передача или повтор передачи происходит по любому из адресов и таймер T3-rtx для этого адреса не включен, отправитель должен запустить этот таймер. Если таймер для данного адреса уже включен, отправитель должен сбросить и запустить его заново, если по этому адресу происходит повтор передачи передачи остающихся в очереди (т. е., с меньшим значением TSN) блоков данных. В остальных случаях перезапуск таймера недопустим.

При старте или перезапуске таймера T3-rtx его значение должно быть установлено в соответствии с правилами, приведенными в параграфах 6.3.2 и 6.3.3.

Примечание: Отправителю не следует использовать значения TSN, которые превышают стартовое значение TSN для текущего окна более, чем на 231 — 1.

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

Конечная точка SCTP всегда должна подтверждать получение каждого корректного блока DATA.

При передаче подтверждений следует придерживаться рекомендаций по использованию алгоритма отложенных подтверждений, описанного в параграфе 4.2 [RFC2581]. В частности, подтверждения следует генерировать по крайней мере по факту доставки каждого второго пакета (не обязательно с блоком DATA), а также следует в течение 200 мсек генерировать подтверждение для любого еще не подтвержденного блока DATA. В некоторых случаях для отправителя SCTP разумно быть более консервативным, нежели предлагает описанный в данном документе алгоритм подтверждения. Однако для отправителей SCTP недопустимо быть более агрессивным, нежели предлагает описанный ниже алгоритм.

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

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

Для реализации протокола недопустимо позволять установку задержки сверх 500 мсек. Иными словами, реализация может устанавливать задержки менее 500 мсек, но задержка ни в коем случае не должна превышать 500 мсек.

Подтверждения должны передаваться в блоках SACK до тех пор, пока со стороны ULP не поступит запроса на завершение ассоциации (в последнем случае подтверждение может быть передано в блоке SHUTDOWN). Блок SACK может использоваться для подтверждения доставки нескольких блоков DATA. Формат блоков SACK описан в параграфе 3.3.4. В частности, конечная точка SCTP должна заполнить поле Cumulative TSN Ack, чтобы показать последний номер TSN для полученных без пропусков корректных блоков DATA. Все принятые блоки DATA с номерами TSN, превышающими значение Cumulative TSN Ack, следует указывать в полях Gap Ack Block.

Примечание. Блок SHUTDOWN не включает поля Gap Ack Block. Поэтому конечной точке следует использовать SACK, а не SHUTDOWN для подтверждения доставки блоков DATA, принятых с нарушением порядка.

При получении пакета с дубликатом блока(ов) DATA, в котором нет нового блока(ов) DATA, конечная точка должна незамедлительно передать SACK. Если пакет с дубликатом(ами) DATA содержит также новый блоки(и) DATA, конечная точка может передать SACK незамедлительно. Обычно получение дублирующих блоков DATA связано с потерей исходного блока SACK и тайм-аутом RTO у партнера. Номера TSN для дубликатов следует указывать в блоке SACK как дубликаты.

При получении блока SACK конечная точка может использовать информацию Duplicate TSN для обнаружения потери блоков SACK. Другие варианты использования этой информации требуют дальнейшего изучения.

Получатель данных отвечает за поддержку буферов приема. Получателю следует своевременно уведомлять отправителя об изменении своих возможностей приема данных. Способы управления приемными буферами в реализации протокола зависят от множества факторов (например, от операционной системы, системы управления памятью, размера ОЗУ и т. п.). Однако описанная в параграфе 6.2.1 стратегия передачи основана на предположении, что получатель использует описанный ниже алгоритм.

  1. При создании ассоциации конечная точка сообщает партнеру размер своего приемного буфера для данной ассоциации в блоке INIT или INIT ACK. Переданное значение размера буфера устанавливается для переменной a_rwnd.
  2. При получении и буферизации блоков DATA значение a_rwnd уменьшается на размер принятых и помещенных в буфер данных. Это по сути закрывает окно rwnd у отравителя и ограничивает количество данных, которые тот может передать.
  3. Когда блоки DATA передаются ULP и буфер освобождается, значение a_rwnd увеличивается на размер данных, которые отправлены протоколу вышележащего уровня. Таким образом окно rwnd открывается снова, позволяя отправителю передавать новые данные. Получателю не следует увеличивать значение a_rwnd, пока данные не будут освобождены из буфера. Например, если получатель удерживает фрагментированные блоки DATA в очереди на сборку, ему не следует увеличивать значение a_rwnd.
  4. При передаче блока SACK получателю данных следует поместить текущее значение переменной a_rwnd в поле a_rwnd передаваемого блока. Получателю данных следует принимать во внимание, что отправитель не будет повторять передачу блоков DATA, указанных в Cumulative TSN Ack (т. е., удалит их из очереди на повтор).

Возможны ситуации, когда получателю потребуется отбросить блоки DATA, которые были приняты, но еще не освобождены из приемного буфера (т. е., не переданы ULP). Такие блоки DATA могут быть подтверждены в Gap Ack Block. Например, получатель может удерживать принятые данные в буфере для сборки фрагментов пользовательского сообщения, когда обнаружится нехватка буферного пространства. Получатель в этом случае может отбросить блоки DATA из буфера, несмотря на то, что они уже подтверждены в Gap Ack Block. Если получатель отбрасывает блоки DATA, их недопустимо включать в Gap Ack Block последующих блоков SACK, пока отброшенные блоки не будут получены снова в повторных пакетах. В дополнение к сказанному конечной точке следует принимать во внимание отброшенные блоки при расчете значения a_rwnd.

Конечной точке не следует отзывать SACK и отбрасывать данные. Описанной процедурой следует пользоваться только в экстремальных ситуациях (например, при нехватке памяти). Получателю данных следует принимать во внимание, что отбрасывание данных, которые были подтверждены в Gap Ack Block, может привести к неоптимальной работе отправителя данных и снижению производительности.

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

Точка A                                      Точка Z

{Приложение передает 3 сообщения; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (отложенное подтверждение)
(Запуск таймера T3-rtx)

DATA [TSN=8,Strm=0,Seq=4] ------------> (передача подтверждения)
                              /------- SACK [TSN Ack=8,block=0]
(Остан. таймера T3-rtx)<-----/

DATA [TSN=9,Strm=0,Seq=5] ------------> (отложенное подтверждение)
(Запуск таймера T3-rtx)
                                       ...
                                       {Прил. перед. 1 сообщ.; strm 1}
                                       (групп. SACK с DATA)
                                /----- SACK [TSN Ack=9,block=0] \
                               /       DATA [TSN=6,Strm=1,Seq=2]
(Остан. таймера T3-rtx)<------/        (Запуск таймера T3-rtx)

(отложенное подтверждение)
(передача подтверждения)
SACK [TSN Ack=6,block=0] -------------> (Остан. таймера T3-rtx)

Рисунок 7. Пример подтверждения с задержкой

 

Если конечная точка получает блок DATA без пользовательских данных (Length = 16), она должна передать блок ABORT с причиной ошибки No User Data.

Конечной точке не следует передавать блоков DATA без пользовательских данных.

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

Каждый блок SACK, полученный конечной точкой, содержит значение a_rwnd. Это значение представляет объем свободного буферного пространства на приемной стороне в момент передачи блока SACK, которое осталось от приемного буфера, указанного в блоке INIT/INIT ACK. Используя значения a_rwnd, Cumulative TSN Ack и Gap Ack Block, отправитель может создать свое представление о буферном пространстве партнера.

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

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

Конечной точке следует использовать приведенные ниже правила расчета rwnd на основе значений a_rwnd, Cumulative TSN Ack и Gap Ack Block, полученных в блоке SACK.

  1. При создании ассоциации конечная точка устанавливает rwnd = Advertised Receiver Window Credit (a_rwnd), указанное партнером в блоке INIT или INIT ACK.
  2. Всякий раз при передаче (или повторе) блока DATA партнеру конечная точка вычитает размер переданной информации из значения rwnd для этого партнера.
  3. Всякий раз, когда блок DATA помечается для повтора (по таймеру T3-rtx (параграф 6.3.3) или fast retransmit (параграф 7.2.4))1, размер этого блока добавляется к значению rwnd.
  4. Всякий раз при получении SACK конечная точка выполняет следующие операции.
    1. Если Cumulative TSN Ack < Cumulative TSN Ack Point, блок SACK отбрасывается. Поскольку Cumulative TSN Ack возрастает монотонно, блок SACK, в котором Cumulative TSN Ack < Cumulative TSN Ack Point говорит о нарушении порядка доставки SACK.
    2. Для переменной rwnd устанавливается значение a_rwnd за вычетом числа байтов, остающихся не подтвержденными, после обработки Cumulative TSN Ack и Gap Ack Block.
    3. Если SACK является отсутствующим TSN, который был ранее подтвержден с использованием Gap Ack Block (например, получатель отказался от данных), соответствующий блок DATA помечается как доступный для повтора. Блок помечается как отсутствующий для быстрого повтора (параграф 7.2.4) и при отсутствии работающего таймера для адреса получателя, по которому блок DATA был передан изначально, для этого адреса запускается таймер T3-rtx.

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

Конечная точка SCTP использует таймер повтора передачи T3-rtx для обеспечения доставки данных при отсутствии обратной связи с партнером. Время этого таймера называют тайм-аутом повтора или RTO2.

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

Расчет и обслуживание RTO для протокола SCTP осуществляются так же, как это делается для таймера повтора передачи в TCP. Для расчета текущего значения RTO конечная точка поддерживает две переменных состояния для каждого адреса получателя — SRTT3 и RTTVAR4.

6.3.1 Расчет RTO

Ниже приводятся правила расчета значений SRTT, RTTVAR и RTO.

  1. До того, как будет измерено значение RTT для пакета, переданного по данному транспортному адресу, для RTO следует использовать параметр протокола RTO.Initial.
  2. После того, как будет определено значение RTT (обозначим его R), следует установить SRTT <- R, RTTVAR <- R/2, RTO <- SRTT + 4 * RTTVAR.
  3. Когда будет получено для RTT новое значение R’, следует установить5 RTTVAR <- (1 — RTO.Beta) * RTTVAR + RTO.Beta * |SRTT — R’| и SRTT <- (1 — RTO.Alpha) * SRTT + RTO.Alpha * R’
  4. Когда данные находятся в процессе доставки и выполняется правило C5, для каждого кругового обхода должно быть выполнено новое измерение RTT. Новое измерение RTT следует проводить не более одного раза на круговой обход для данного транспортного адреса. Такое ограничение обусловлено 2 причинами. Во-первых, более частые измерения не имеют смысла, поскольку не дают заметных преимуществ [ALLMAN99]; во-вторых, при частых измерениях значения RTO.Alpha и RTO.Beta в правиле C3 следует подбирать так, чтобы значения SRTT и RTTVAR рассчитывались примерно с такой же частотой (в терминах количества круговых обходов, при котором новые значения вступают в силу) как при одном измерении на круговой обход и с использованием RTO.Alpha и RTO.Beta в правиле C3. Однако точная процедура расчетов требует дополнительных исследований.
  5. Алгоритм Karn: измерение RTT недопустимо выполнять с использованием передаваемых повторно пакетов, поскольку нет возможности различить, к какой из переданных копий относится полученный отклик.
  6. Если после расчета RTO получается значение меньше RTO.Min, устанавливается RTO = RTO.Min. Причина этого заключается в том, что использование слишком малых значений RTO будет приводить к возникновению неоправданных тайм-аутов [ALLMAN99].
  7. Максимальное значение RTO составляет по крайней мере RTO.max секунд.

К дискретности временных параметров (G) при измерении RTT и различных переменных состояния применяется единственное правило.

G1) Если при расчете RTTVAR получено нулевое значение, следует установить RTTVAR <- G.

Опыт показывает [ALLMAN99], что дискретность не более 100 мсек является предпочтительной.

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

Ниже приведены правила управления таймером повтора передачи.

 

Точка A                                                Точка Z
{приложение начинает передачу}
Data [TSN=7,Strm=0,Seq=3] ------------> (задержка ack)
(Пуск таймера T3-rtx)
                                      {Прил. перед. 1 сообщ.; strm 1}
                                        (группировка ack и data)
DATA [TSN=8,Strm=0,Seq=4] ----\     /-- SACK [TSN Ack=7,Block=0]
                               \   /      DATA [TSN=6,Strm=1,Seq=2]
                                \ /     (Запуск таймера T3-rtx)
                                 \
                                / \
(Перезап. таймера T3-rtx)<-----/   \--> (задержка ack)
(задержка ack)
{передача ack}
SACK [TSN Ack=6,Block=0] --------------> (Остан. таймера T3-rtx)
                                        ..
                                        (передача ack)
(Остан. таймера T3-rtx)  <-------------- SACK [TSN Ack=8,Block=0]

Рисунок 8. Пример правил для таймера

 

  1. Каждый раз при передаче (включая повторы) блока DATA по любому из адресов следует запустить для этого адреса таймер T3-rtx (если он не работает) на время RTO. Используемое для таймера значение RTO удваивается после каждого случая тайм-аута для предыдущего таймера T3-rtx, связанного с этим адресом, как указано ниже в правиле E2.
  2. После подтверждения всех остающихся для этого адреса данных таймер T3-rtx для данного адреса сбрасывается.
  3. Всякий раз при получении SACK, подтверждающего блок DATA с остающимся TSN для данного адреса, таймер T3-rtx для этого адреса запускается заново с текущим значением RTO (если для этого адреса еще остаются данные).
  4. При получении SACK для отсутствующего TSN, который ранее был подтвержден с помощью Gap Ack Block, включается таймер T3-rtx для адреса получателя, по которому блок DATA был передан изначально (если этот таймер еще не запущен).

На рисунке 8 показан пример использования правил для таймера (предполагается, что получатель использует отложенные подтверждения).

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

При завершении отсчета T3-rtx для адреса получателя выполняются перечисленные ниже действия.

  1. Для этого адреса изменяется значение ssthresh в соответствии с правилами, приведенными в параграфе 7.2.3, и устанавливается cwnd <- MTU.
  2. Для этого адреса устанавливается RTO <- RTO * 2. Максимальное значение для таймера рассматривается в приведенном выше правиле C7 (RTO.max). Это значение может служить верхней границей для операций удваивания.
  3. Определяется количество более ранних (т. е., с меньшими номерами TSN) неподтвержденных блоков DATA для этого адреса, которые можно поместить в один пакет с учетом ограничений MTU на пути доставки по этому транспортному адресу (для разных путей могут быть разные значения MTU – см. параграф 6.4). Обозначим найденное число блоков K. Эти K блоков DATA группируются в один пакет и передаются удаленному партнеру по его транспортному адресу.
  4. Запускается таймер повтора T3-rtx для адреса, по которому был передан повторный пакет, если приведенное выше правило R1 указывает это. Используемое для таймера значение RTO следует брать для одного из адресов, по которым передается повтор — в случае многодомного получателя значения могут различаться для разных адресов получателя (см. параграф 6.4 ).

После повтора передачи, когда будет проведено новое измерение RTT (это может случиться только в том случае, когда новые данные были переданы и подтверждены в соответствии с правилом C5, или измерение сделано на основе HEARTBEAT (см. параграф 8.3)), выполняется расчет по правилу C3 (включая вычисление RTO), который может привести к “коллапсу” RTO (со снижением значения до начального уровня) после того, как это значение было удвоено (правило E2).

Примечание. Любые блоки DATA, переданные по адресу, для которого истекло время T3-rtx, но не был заполнен MTU (правило E3), следует пометить для повторной передачи и передать, как только позволит cwnd (обычно при получении SACK).

Заключительное правило управления таймером повтора передачи связано с переключением на другой адрес получателя (см. параграф 6.4.1).

  1. Всякий раз, когда конечная точка переключается с текущего транспортного адреса получателя на другой транспортный адрес, текущий таймер повтора передачи продолжает работать. Как только конечная точка передаст пакет, содержащий блок(и) DATA, по новому транспортному адресу, запускается таймер для этого адреса с использованием значения RTO для адреса получателя, по которому были посланы данные, если правило R1 указывает, что это нужно сделать.

6.4 Многодомные точки SCTP

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

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

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

Конечной точке следует передавать блоки откликов (например, SACK, HEARTBEAT ACK и т. п.) по тому же транспортному адресу, с которого был получен блок DATA или управляющий блок, вызвавший передачу отклика. Этому правилу нужно следовать также в тех случаях, когда конечная точка объединяет с откликом блоки DATA.

Однако при подтверждении множества блоков DATA, полученных в пакетах с разных адресов, в одном SACK этот блок SACK может передаваться по одному из транспортных адресов, с которых были получены подтверждаемые блоки DATA или управляющие блоки.

Когда получатель дубликата блока DATA передает блок SACK многодомной конечной точке, он может воспользоваться выбором адреса получателя и не использовать в качестве такового адрес отправителя блока DATA. Причина этого заключается в том, что получение дубликата от многодомной конечной точки может указывать на то, что путь возврата, указанный в поле отправителя блока DATA, может быть недоступен (разорван) для передачи SACK.

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

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

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

Некоторые транспортные адреса многодомной конечной точки SCTP могут утратить активность в результате ошибок (см. параграф 8.2) или по требованию пользователя SCTP.

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

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

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

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

Каждый блок DATA должен содержать корректный идентификатор потока. Если конечная точка получает блок DATA с некорректным идентификатором, ей следует подтвердить прием данных в соответствии с обычной процедурой, незамедлительно передать блок ERROR с причиной ошибки Invalid Stream Identifier (некорректный идентификатор потока, см. параграф 3.3.10) и отбросить блок DATA. Конечная точка может группировать блок ERROR в один пакет с блоком SACK, если ERROR следует после SACK.

Порядковые номера во всех потоках должны начинаться с нуля при создании ассоциации. При достижении порядковым номером в потоке значения 65535 следующим номером снова будет 0.

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

Внутри потока конечная точка должна доставлять блоки DATA, полученные с флагом U = 0, на вышележащий уровень в соответствии с порядковыми номерами блоков в потоке. Если блоки DATA поступают с нарушением порядка, конечная точка должна удерживать полученные блоки DATA от передачи ULP, пока не будет восстановлен порядок.

Однако конечная точка SCTP может запросить неупорядоченную доставку для определенного блока DATA, передаваемого в потоке, установив для этого блока флаг U = 1.

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

Это обеспечивает эффективный способ передачи “дополнительных” (out-of-band) данных в потоке. Кроме того, весь поток можно сделать “неупорядоченным”, устанавливая флаг U = 1 для каждого блока DATA, передаваемого в этом потоке.

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

Поле ‘Stream Sequence Number’ в блоке DATA с флагом U = 1 не имеет смысла. Отправитель может указывать в этом поле произвольное значение, а получатель должен игнорировать это поле.

Примечание. При передаче упорядоченных и неупорядоченных данных, конечная точка не увеличивает свое значение поля Stream Sequence Number, передавая блок DATA с флагом U = 1.

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

При получении нового блока DATA конечной точке следует проверить непрерывность порядковых номеров TSN. При обнаружении пропуска в порядковых номерах принятых блоков DATA конечной точке следует незамедлительно передать блок SACK с Gap Ack Block. Получатель продолжает передачу SACK после получения каждого пакета SCTP, который не закрывает пропуск в порядковых номерах.

На основе Gap Ack Block из полученного блока SACK конечная точка может определить пропущенные блоки DATA и принять решение о необходимости повторной передачи таких блоков (см. параграф 6.2.1).

В одном блоке SACK может передаваться информация о нескольких обнаруженных пропусках (см. параграф 3.3.4).

Если партнер является многодомным, конечной точке SCTP всегда следует пытаться передать SACK по тому адресу, с которого был получен последний блок DATA.

 

Точка A                                       Точка Z
{Приложение передало 3 сообщения; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (задержка ack)
(Запуск таймера T3-rtx)

DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)

DATA [TSN=8,Strm=0,Seq=4] ---------------> (обнаружен пропуск,
                                         немедленно передаем ack)
                                  /----- SACK [TSN Ack=6,Block=1,
                                 /             Strt=2,End=2]
                          <-----/
(удаляем 6 из выходной очереди и
помечаем 7 как отчет о пропуске "1")

Рисунок 9. Отчет о пропуске с использованием SACK

 

При получении блока SACK конечная точка должна удалить из выходной очереди все блоки DATA, которые были подтверждены в Cumulative TSN Ack блока SACK. Конечная точка должна также трактовать все блоки DATA с номерами TSN, не включенными в Gap Ack Block из блока SACK, как “потерянные”. Число отчетов о “потерях” для каждого неподтвержденного блока DATA должно быть записано отправителем, чтобы принять решение о повторной передаче (см. параграф 7.2.4).

На рисунке 9 приведен пример использования SACK для передачи информации о пропуске.

Максимальное число Gap Ack Block, которые могут быть включены в один блок SACK, ограничивается текущим значением MTU для пути. Когда в один блок SACK невозможно включить все Gap Ack Block, которые нужно передать, по причине ограничения MTU, конечная точка должна передать только один блок SACK, включающий все Gap Ack Block от младших номеров TSN к старшим, которые могут поместиться в блок, ограниченный значением MTU, и оставить старшие номера TSN неподтвержденными.

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

При передаче пакета SCTP конечная точка должна для обеспечения возможности контроля целостности данных включить в пакет значение контрольной суммы Adler-32 в соответствии с приведенным ниже описанием.

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

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

При получении пакета SCTP принимающая конечная точка должна проверить значение контрольной суммы Adler-32 в заголовке:

  1. Сохранить полученное в пакете значение контрольной суммы Adler-32.
  2. Заменить 32-битовое поле контрольной суммы принятого пакета SCTP значением 0 и рассчитать контрольную сумму по алгоритму Adler-32 для измененного пакета.
  3. Сравнить сохраненное значение (из пакета) контрольной суммы Adler-32 с контрольной суммой, полученной в результате расчета. Если значения не совпадут, получатель должен трактовать принятый пакет как некорректный.

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

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

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

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

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

Примечание. После фрагментации сообщения оно не может быть фрагментировано еще раз. Если же значение Path MTU уменьшилось, в таких случаях должна использоваться фрагментация IP. Определение значений Path MTU рассматривается в параграфе 7.3.

При решении вопроса о необходимости фрагментирования реализация SCTP должна принимать во внимание размер заголовка пакета SCTP и заголовков блоков DATA. Должен также приниматься во внимание размер блоков SACK, если они группируются с блоком DATA.

Фрагментация выполняется следующим образом.

  1. Отправитель должен разбить пользовательское сообщение не несколько блоков DATA, чтобы размер каждого блока в сумме со служебной информацией SCTP не превышал размер поля данных дейтаграммы IP, которая по своему размеру равна или меньше значения Path MTU для ассоциации.
  2. Отправитель должен выделить по порядку номера TSN для каждого из блоков DATA, содержащих фрагменты сообщения. Всем блокам DATA, содержащим фрагменты одного сообщения, присваиваются одинаковые номера SSN. Если пользователь указал, что сообщение доставляется без соблюдения порядка, для каждого блока DATA должен быть установлен флаг U = 1.
  3. Отправитель должен также установить биты B/E блока DATA для всех фрагментов (10 для первого, 01 для последнего и 00 для всех остальных).

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

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

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

Конечная точка группирует блоки путем простого включения множества блоков в один исходящий пакет SCTP. Суммарный размер получающейся в результате дейтаграммы IP (включая пакет SCTP и заголовок IP) должен быть не более текущего значения Path MTU.

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

При группировке управляющих блоков с блоками DATA конечная точка должна помещать управляющие блоки перед блоками данных. Отправитель должен передавать блоки DATA внутри пакета SCTP в соответствии с ростом номеров TSN.

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

Недопустимо включение в пакет SCTP неполных блоков (Partial chunk).

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

Недопустимо группировать блоки INIT, INIT ACK, SHUTDOWN COMPLETE с любыми другими блоками.

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

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

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

Алгоритмы контроля насыщения протокола SCTP основаны на [RFC2581]. В этой главе описано, как алгоритмы, определенные в RFC2581, адаптированы для использования в SCTP. Сначала рассматриваются различия между протоколами TCP и SCTP, а после этого описывается схема контроля насыщения в SCTP. В описании используется та же терминология, которая принята для протокола TCP. Контроль насыщения в SCTP всегда применяется ко всей ассоциации (соединению), а не к отдельным потокам.

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

Gap Ack Block в SCTP SACK имеют такой же смысл, как TCP SACK. Протокол TCP рассматривает информацию в SACK только как консультативную. SCTP также рассматривает информацию, передаваемую в Gap Ack Blocks блоков SACK как консультативную. В SCTP любой блок DATA, подтвержденный с помощью SACK (включая блоки DATA, полученные на приемной стороне с нарушением порядка), не рассматривается как доставленный окончательно, пока Cumulative TSN Ack Point не перейдет значение TSN блока DATA (т. е., пока блок DATA не будет подтвержден полем Cumulative TSN Ack в SACK). Следовательно, значение параметра cwnd контролирует количество неподтвержденных данных, а не (как в случае TCP без SACK) верхнюю границу между максимальным подтвержденным порядковым номером и последним блоком DATA, который может быть передан в окне насыщения. SCTP SACK обусловливает отличие реализации механизмов ускоренного повтора (fast-retransmit) и быстрого восстановления (fast-recovery) от случая TCP без SACK. Пример этого приведен в [FALL96].

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

  • Отправитель обычно не меняет адрес получателя, пока не получит запрос на такую замену от протокола вышележащего уровня; однако SCTP может переключиться на другой адрес получателя, если прежний адрес был помечен как неактивный (см. параграф 8.2). Кроме того, SCTP может повторять передачу пакетов по адресам, отличающимся от тех, которые использовались для передачи исходного пакета.
  • Отправитель сохраняет отдельный набор параметров контроля насыщения для каждого адреса получателя, по которому он может передавать данные (не для каждой пары адресов “отправитель-получатель”, а для каждого адреса получателя). Параметры следует отбрасывать, если адрес не используется достаточно долго.
  • Для каждого адреса получателя конечная точка выполняет процедуру замедленного старта (slow-start) в начале передачи данных по этому адресу.

Примечание. TCP гарантирует упорядоченную доставку данных протоколу вышележащего уровня в рамках одной сессии TCP. Это означает, что при получении протоколом TCP информации о пропуске в порядковых номерах он будет ждать заполнения пропуска и только после этого передаст данные вышележащему уровню. SCTP может доставлять данные на вышележащий уровень даже при наличии пропусков в порядковых номерах TSN, если порядковые номера в потоке (Stream Sequence Number) упорядочены в рамках данного потока (т. е., пропущенный блок DATA относится к другому потоку) или при запросе неупорядоченной доставки. Это различие не оказывает влияния на cwnd, но может влиять на расчет rwnd.

7.2 Процедуры Slow-Start6 и Congestion Avoidance7

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

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

  • Анонсируемый получателем размер окна приема (rwnd8, в байтах) устанавливается получателем данных с учетом возможностей выделения буферов для принимаемых пакетов.
  • Окно контроля насыщения (cwnd9, в байтах) устанавливается отправителем с учетом условий в сети.
  • Порог замедленного старта (ssthresh10, в байтах) используется отправителем для принятия решения о выборе используемого алгоритма контроля насыщения (slow start или congestion) на данной фазе.
  • Примечание. Эта переменная поддерживается для каждого адреса получателя.
  • Примечание. Эта переменная поддерживается для каждого адреса получателя.
  • Примечание. эта переменная имеет одно значение для всей ассоциации.

Протокол SCTP использует также одну дополнительную переменную – partial_bytes_acked, которая применяется в фазе предотвращения перегрузки для упрощения расчета значения cwnd.

В отличие от TCP, отправитель SCTP должен хранить набор из трех переменных (cwnd, ssthresh и partial_bytes_acked) для каждого адреса получателя на удаленной стороне (если партнер является многодомным). Только переменная rwnd имеет значение для всей ассоциации (независимо от того, является ли партнер многодомным).

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

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

  • Стартовое значение cwnd до передачи блоков DATA или после достаточно долгого бездействия должно быть не более 2*MTU.
  • Начальное значение cwnd после тайм-аута для повтора передачи должно быть не более 1*MTU.
  • Начальное значение ssthresh может быть произвольно большим (например, реализация может просто установить для этого параметра значение размера окна приема, анонсируемого получателем).
  • При положительном значении cwnd конечная точка может иметь cwnd ожидающих подтверждения байтов данных для этого транспортного адреса.
  • Если cwnd меньше или равно ssthresh, конечная точка SCTP должна использовать алгоритм slow start для увеличения размера cwnd (предполагается, что текущее окно насыщения полностью используется). Если входящее подтверждение SACK указывает за пределы Cumulative TSN Ack Point, значение cwnd должно быть увеличено не более чем на меньшее из двух значений — 1) общий размер подтвержденных блоков DATA или 2) значение path MTU для данного адресата. Такой подход обеспечивает защиту от атаки ACK-Splitting, описанной в [SAVAGE99].

В случаях, когда партнер является многодомным и конечная точка получает подтверждение SACK, указывающее за пределы Cumulative TSN Ack Point, ей следует обновить значение cwnd (или несколько значений cwnd) для адреса получателя, по которому были переданы подтвержденные данные. Однако, если принятое подтверждение SACK не указывает вперед Cumulative TSN Ack Point, для конечной точки недопустимо менять значение cwnd для любого из адресов получателя.

Поскольку значение cwnd для конечной точки не связано с Cumulative TSN Ack Point для нее, при получении дубликата SACK (даже если он не указывает за пределы Cumulative TSN Ack Point), конечная точка может продолжать использование этого подтверждения для синхронизации отправки новых данных. Т. е., данные, подтвержденные последним SACK уменьшают количество данных, находящихся в пути до значения меньше cwnd и даже неизменное значение cwnd позволяет передать новую порцию данных в сеть. С другой стороны, увеличение cwnd должно быть связано с подтверждением сверх Cumulative TSN Ack Point, как было сказано выше. В противном случае дубликат SACK будет не только разрешать передачу в сеть новых данных, но и увеличивать количество данных, которые можно передать, не дожидаясь подтверждения, хотя в это время сеть может оказаться перегруженной.

  • Когда конечная точка не передает данных по какому-либо транспортному адресу, в качестве значения cwnd для этого адреса следует установить max(cwnd/2, 2*MTU) в расчете на RTO.

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

При cwnd > ssthresh, значение cwnd следует увеличивать на 1*MTU за каждый период RTT, если у отправителя имеется не менее cwnd байтов неподтвержденных данных для соответствующего транспортного адреса.

На практике эта процедура может быть реализована следующим способом:

  • Устанавливается partial_bytes_acked = 0.
  • Если cwnd > ssthresh, всякий раз при получении SACK, указывающего за пределы Cumulative TSN Ack Point, значение partial_bytes_acked увеличивается на число байтов во всех блоках, подтвержденных этим SACK, включая блоки, подтвержденные новым значением Cumulative TSN Ack и Gap Ack Block.
  • Когда значение partial_bytes_acked становится равным cwnd или превышает его и до прибытия SACK у отправителя имеется не менее cwnd остающихся данных (т. е., до прибытия SACK, объем переданных, но еще не подтвержденных данных больше или равен размеру окна cwnd), значение cwnd увеличивается на MTU, а значение partial_bytes_acked уменьшается на cwnd.
  • Как и при замедленном старте в качестве значения cwnd для адреса получателя следует установить max(cwnd/2, 2*MTU) в расчете на RTO, если отправитель не передает блоков DATA по данному адресу.
  • Когда все переданные отправителем данные подтверждены получателем, устанавливается partial_bytes_acked = 0.

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

При обнаружении потери пакета из подтверждения SACK (см. параграф 7.2.4), конечной точке следует установить значения:

ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh

Обычно потеря пакета приводит к уменьшению cwnd вдвое.

Когда завершается отсчет по таймеру T3-rtx для этого адреса, SCTP следует выполнить процедуру замедленного старта, установив:

ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU

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

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

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

Всякий раз при получении SACK, указывающего на пропуск некоторых номеров TSN, конечной точке следует дождаться 3 последующих индикаций потери (в следующих подтверждениях SACK) для тех же номеров, прежде, чем начать реализацию механизма ускоренного повтора (Fast Retransmit).

Когда отсутствующие номера TSN указаны в 4 последовательных подтверждениях SACK, отправителю следует:

  1. Пометить указанные блоки DATA для повторной передачи.
  2. Изменить значения ssthresh и cwnd для адреса (или нескольких адресов) получателя, по которому были переданы утерянные данные в последний раз, согласно выражениям, приведенным в параграфе 7.2.3.
  3. Определить, сколько наиболее ранних (т. е., с меньшими номерами TSN) блоков DATA может быть включено в один пакет с учетом значения path MTU для адреса получателя, по которому будут передаваться данные (обозначим это количество буквой K). Повторно передать эти K блоков DATA в одном пакете.
  4. Заново запустить таймер T3-rtx, если последнее подтверждение SACK относится к меньшему из остающихся в сети номеров TSN для данного адреса получателя или конечная точка повторяет передачу первого из остающихся в сети блоков DATA, переданных по этому адресу.

Примечание. Если полученный блок SACK также подтверждает новые блоки DATA за пределами Cumulative TSN AckPoint, перед выполнением перечисленных в пп. 1 – 4 операций нужно сначала изменить значение cwnd в соответствии с правилами, приведенными в параграфах 7.2.1 и 7.2.2.

Корректная реализация приведенных выше правил будет подсчитывать все пропуски TSN, о которых сообщалось в SACK. Значение счетчика увеличивается для каждого последующего подтверждения SACK, указывающего на пропуск TSN. После того, как значение счетчика достигнет 4 и будет начата процедура ускоренного повтора передачи, значение счетчика сбрасывается в 0.

Поскольку значение cwnd в SCTP опосредованно ограничивает количество остающихся в сети TSN, механизм быстрого восстановления TCP (fast-recovery) реализуется автоматически без изменения размера окна контроля насыщения.

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

В [RFC1191] описан метод «Path MTU Discovery», позволяющий конечной точке оценить значение максимального размера пакета (MTU) на данном пути через Internet и воздерживаться от передачи по этому пути пакетов, размер которых превышает MTU, без использования методов зондирования с целью определения изменений Path MTU (PMTU). RFC 1191 предлагает механизм и стратегию определения “сквозного” значения MTU для пути и изменений этого параметра. В [RFC1981] определяется аналогичный метод для протокола IPv6. Отправитель SCTP, использующий IPv6, должен применять метод Path MTU Discovery, если размер пакетов может превышать минимальное значение MTU для IPv6 [RFC2460].

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

При определении значения MTU для протокола SCTP существуют несколько отличий от описания, приведенного в RFC 1191 для TCP:

  1. Ассоциация SCTP может включать множество адресов. Конечная точка должна поддерживать отдельную оценку значения MTU для каждого из адресов своего партнера.
  2. Термин «MTU» в данном документе всегда относится к значению MTU для адреса получателя, к которому относится обсуждение.
  3. В отличие от TCP, протокол SCTP не использует понятия “максимальный размер сегмента” (MSS11). Соответственно, MTU для каждого адреса получателя следует инициализировать значением, не превышающее MTU канала для локального интерфейса, через который пакет будет маршрутизироваться к получателю.
  4. Поскольку передача данных в SCTP структурируется естественным способом в терминах порядковых номеров TSN, а не в байтах (как в TCP), обсуждение в параграфе 6.5 RFC 1191 применимо и к этому протоколу: “При повторе передачи дейтаграммы IP по удаленному адресу, для которого исходная дейтаграмма оказалась слишком большой по сравнению с MTU для пути к данному адресу, дейтаграмму IP следует передавать повторно без флага DF, что позволит фрагментировать ее. При передаче новых дейтаграмм IP флаг DF должен устанавливаться.
  5. Отправителю следует контролировать значение PMTU для ассоциации в целом, выбирая для этого минимальное из значений PMTU для путей ко всем адресам партнера. При фрагментации сообщений значение PMTU для ассоциации в целом следует использовать для определении размера фрагментов. Такой подход позволит передавать фрагменты по любому из возможных путей без дополнительной фрагментации на уровне IP.

За исключением перечисленных выше различий методы определения MTU для пути, описанные в RFC 1191 и 1981 для протокола TCP, применимы к SCTP независимо для каждого адреса получателя.

Примечание: Для адресов IPv6 флаг DF не используется и дейтаграммы должны фрагментироваться в соответствии с [RFC2460].

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

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

Конечной точке следует подсчитывать общее количество последовательных повторов передачи своему партнеру (включая повторы по всем адресам для многодомных партнеров). Если значение этого счетчика превысит порог, указанный параметром протокола Association.Max.Retrans12, конечной точке следует рассмотреть вопрос о доступности партнера и прекращении передачи ему каких-либо данных (т. е., перевода ассоциации в состояние CLOSED). Кроме того, конечной точке следует передать информацию об отказе (и, возможно, об оставшихся в выходной очереди данных) протоколу вышележащего уровня. Ассоциация автоматически закрывается, когда удаленный партнер становится недоступным.

Счетчик повторов следует сбрасывать всякий раз, когда переданный партнеру блок DATA подтверждается с помощью SACK или от удаленного партнера принимается HEARTBEAT-ACK.

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

Если партнер является многодомным, конечной точке следует поддерживать счетчики ошибок для каждого транспортного адреса этого партнера.

Каждый раз, когда завершается отсчет таймера T3-rtx для любого из адресов или передача HEARTBEAT по бездействующему адресу не подтверждается в течение RTO, значение счетчика ошибок для соответствующего адреса будет увеличиваться на 1. Когда значение счетчика превысит значение параметра протокола Path.Max.Retrans13‘ для данного адреса, конечной точке следует пометить этот адрес как неактивный, а также следует передать уведомление об этом протоколу вышележащего уровня.

Когда остающиеся в сети номера TSN подтверждаются или блок HEARTBEAT, переданный по бездействующему адресу, подтверждается блоком HEARTBEAT ACK, конечная точка должна сбрасывать счетчик ошибок для транспортного адреса получателя, по которому был отправлен последний блок DATA (или блок HEARTBEAT). Если партнер является многодомным и последний блок был передан ему в качестве повтора с изменением адреса получателя, возникает неоднозначность в выборе адреса, для которого следует учитывать полученное подтверждение. Однако эта неоднозначность не оказывает существенного влияния на дальнейшее поведение SCTP. Если такие неоднозначности нежелательны, отправитель может не сбрасывать счетчик ошибок, когда последний блок передавался повторно.

Примечание. При настройке конфигурации конечной точки SCTP следует избегать установки для параметра Association.Max.Retrans значения, превышающего любое из значений Path.Max.Retrans для адресов удаленной конечной точки. В противном случае все адреса удаленного партнера могут стать неактивными, а данная точка будет по-прежнему считать этого партнера доступным. При возникновении такой ситуации поведение протокола SCTP будет зависеть от конкретной реализации.

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

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

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

Транспортный адрес рассматривается как бездействующий (idle), если нет новых блоков, которые могут использоваться для обновления периода RTT для пути (обычно, к таким блокам относятся DATA, INIT, COOKIE ECHO, HEARTBEAT и т. п.), и в течение текущего периода “проверки пульса”14 по этому адресу не было передано блоков HEARTBEAT. Эта трактовка относится как к активным адресам, так и к неактивным.

Вышележащий уровень может дополнительно инициировать следующие функции:

  1. запрет HEARTBEAT для определенного транспортного адреса в рамках данной ассоциации;
  2. изменение интервала HB.interval;
  3. восстановление передачи HEARTBEAT для указанного адреса в данной ассоциации;
  4. запрос на передачу HEARTBEAT по указанному адресу в данной ассоциации.

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

Когда значение счетчика достигает значения протокольного параметра Path.Max.Retrans, конечной точке следует пометить соответствующий адрес получателя как неактивный (если он еще не помечен). Кроме того, конечная точка может сообщить вышележащему уровню об изменении состояния доступности для данного адреса получателя. После этого конечной точке следует продолжать передачу блоков HEARTBEAT по этому адресу, но без дальнейшего увеличения значения счетчика ошибок.

Отправителю блока HEARTBEAT следует включать в поле Heartbeat Information этого блока текущее время в момент передачи пакета.

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

Получателю блока HEARTBEAT следует незамедлительно передать в ответ подтверждение HEARTBEAT ACK, содержащее Heartbeat Information из полученного блока HEARTBEAT.

При получении блока HEARTBEAT ACK отправителю блока HEARTBEAT следует сбросить счетчик ошибок для транспортного адреса получателя, по которому был отправлен подтвержденный блок HEARTBEAT, и пометить адрес как активный (если он не был помечен ранее). Конечная точка может также сообщить вышележащему уровню об активизации транспортного адреса в результате получения последнего блока HEARTBEAT ACK. Получатель блока HEARTBEAT ACK должен также сбросить значение общего счетчика ошибок для ассоциации (см. параграф 8.1).

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

Для бездействующего транспортного адреса, которому разрешено передавать блоки HEARTBEAT, рекомендуется передавать один блок в каждый период RTO для данного адреса получателя + HB.interval с вариациями ± 50% от RTO и экспоненциальным снижением RTO, если доставка предыдущего блока HEARTBEAT не подтверждена.

Для пользователей SCTP обеспечивается примитив, позволяющий изменять значение HB.interval и включать/выключать передачу блоков HEARTBEAT для данного адреса. Интервал передачи HEARTBEAT, устанавливаемый пользователем SCTP, добавляется к RTO для данного адресата (с учетом экспоненциального снижения RTO). Следует передавать только один блок HEARTBEAT в течение каждого периода отсчета heartbeat-таймера (если бездействует множество адресов). Разработчики вольны определить способ выбора кандидата для передачи блока при наличии множества бездействующих адресов.

Примечание. При подстройке интервала heartbeat может возникать побочный эффект, который следует принимать во внимание. Когда этот интервал возрастает (блоки HEARTBEAT передаются реже), детектирование потери сообщений ABORT также замедляется. Если партнер прервет (ABORT) ассоциацию по какой-либо причине и блок ABORT будет потерян, локальная точка обнаружит прерывание ассоциации только при передаче блока DATA или HEARTBEAT (это вынудит партнера передать блок ABORT повторно). Такой эффект следует учитывать при установке значения для таймера HEARTBEAT. Если передача HEARTBEAT запрещена, потеря блока ABORT будет обнаружена только после передачи блока DATA.

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

Пакет SCTP называется пакетом OOTB15, если он правильно сформирован (т. е., включает корректное значение контрольной суммы Adler-32, описанной в параграфе 6.8), но получатель не может идентифицировать ассоциацию, к которой этот пакет относится.

Получатель пакета OOTB должен выполнить следующие операции с соблюдением их порядка:

  1. Если в пакете OOTB указан отличный от индивидуального (non-unicast) адрес отправителя или получателя, такой пакет отбрасывается без уведомления.
  2. Если пакет OOTB содержит блок ABORT, получатель должен отбросить такой пакет без уведомления и выполнения каких-либо дополнительных действий.
  3. Если пакет содержит блок INIT с полем Verification Tag = 0, пакет обрабатывается как описано в параграфе 5.1.
  4. Если пакет содержит COOKIE ECHO в первом блоке, обработка пакета выполняется в соответствии с параграфом 5.1.
  5. Eсли пакет содержит блок SHUTDOWN ACK, получателю следует передать отправителю пакета OOTB блок SHUTDOWN COMPLETE. При передаче блока SHUTDOWN COMPLETE получатель пакета OOTB должен заполнить поле Verification Tag, скопировав в него значение Verification Tag из блока SHUTDOWN ACK и установить бит T в поле флагов блока для индикации отсутствия порядкового номера TCB.
  6. Если пакет содержит блок SHUTDOWN COMPLETE, получателю следует отбросить пакет без уведомления и выполнения каких-либо дополнительных действий.
  7. Если пакет содержит Stale cookie ERROR или блок COOKIE ACK, пакет следует отбросить без уведомления.
  8. В остальных случаях получателю следует ответить отправителю пакета OOTB пакетом с блоком ABORT. При передаче блока ABORT получатель пакета OOTB должен указать в поле Verification Tag значение Verification Tag из пакета OOTB и установить бит T в поле флагов для индикации отсутствия порядкового номера TCB. После передачи блока ABORT получатель пакета OOTB должен отбросить этот пакет, не выполняя каких-либо дополнительных действий.

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

Правила Verification Tag, определенные в этом параграфе, применяются для передачи и приема пакетов SCTP, не содержащих блоков INIT, SHUTDOWN COMPLETE, COOKIE ECHO (см. параграф 5.1), ABORT или SHUTDOWN ACK. Для перечисленных блоков правила рассмотрены отдельно в параграфе 8.5.1.

При передаче пакета SCTP конечная точка должна заполнить поле Verification Tag, указав в нем значение параметра Initiate Tag из полученного от партнера блока INIT или INIT ACK.

При получении пакета SCTP конечная точка должна проверить соответствие полученного значения Verification Tag своему значению тега. Если полученное значение Verification Tag не соответствует тегу локальной точки, получателю следует отбросить пакет без уведомления и не выполнять каких-либо дополнительных операций за исключением случаев, описанных в параграфе 8.5.1.

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

  1. Правила для пакетов с блоками INIT:
    • Отправитель должен установить Verification Tag = 0.
    • Когда конечная точка получает пакет SCTP с Verification Tag = 0, ей следует убедиться, что пакет содержит только блок INIT. В противном случае пакет должен быть отброшен без уведомления.
  1. Правила для пакетов с блоками ABORT:
    • Конечная точка всегда должна указывать в поле Verification Tag передаваемых пакетов значение тега адресата, если этот тег известен.
    • Если блок ABORT передается в ответ на пакет OOTB, конечная точка должна выполнить процедуру, описанную в параграфе 8.4.
    • Получатель блока ABORT должен воспринять пакет, если значение Verification Tag соответствует его собственному тегу или тегу партнера. В противном случае пакет должен отбрасываться без уведомления и выполнения каких-либо других действий.
  1. Правила для пакетов с блоками SHUTDOWN COMPLETE:
    • При передаче блока SHUTDOWN COMPLETE, если получатель блока SHUTDOWN ACK имеет значение TCB, в поле верификации должен использоваться тег адресата. При отсутствии TCB отправителю следует использовать значение Verification Tag из блока SHUTDOWN ACK.
    • Получатель SHUTDOWN COMPLETE должен воспринять пакет, если поле Verification Tag соответствует его собственному тегу или тегу его партнера и в поле флагов установлен бит T. В противном случае получатель должен отбрасывать пакет без уведомления и выполнения каких-либо иных действий. Конечная точка должна игнорировать SHUTDOWN COMPLETE, если она не находится в состоянии SHUTDOWN-ACK-SENT.
  1. Правила для пакетов с блоками COOKIE ECHO
    • При передаче COOKIE ECHO конечная точка должна использовать значение Initial Tag из принятого блока INIT ACK.
    • Получателю COOKIE ECHO следует выполнить процедуры, описанные в разделе 5.
  1. Правила для пакетов с блоками SHUTDOWN ACK
    • Если получатель находится в состоянии COOKIE-ECHOED или COOKIE-WAIT, следует выполнить процедуры, описанные в параграфе 8.4 (т. е., пакет должен трактоваться как OOTB).

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

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

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

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

Для конечной точки недопустима передача откликов на любой принятый пакет, содержащий блок ABORT (см. также параграф 8.4).

Конечная точка, получившая блок ABORT, должна выполнить специальную проверку Verification Tag в соответствии с правилами параграфа 8.5.1.

После проверки Verification Tag принявшая блок конечная точка должна удалить ассоциацию из своих записей и сообщить о разрыве ассоциации на вышележащий уровень.

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

Используя примитив SHUTDOWN (параграф 10.1), вышележащий уровень конечной точки ассоциации может выполнить аккуратное завершение работы ассоциации16. В этом случае все остающиеся блоки DATA от партнера, инициировавшего завершение ассоциации, будут доставлены до завершения работы.

При получении от вышележащего уровня примитива SHUTDOWN конечная точка переходит в состояние SHUTDOWN-PENDING и продолжает находиться в этом состоянии, пока все остающиеся данные не будут подтверждены партнером. Конечная точка не принимает новых данных от вышележащего уровня, но будет повторять передачу данных удаленному партнеру, если в этом возникает необходимость (заполнение пропуска в порядковых номерах).

После того, как все остающиеся в сети данные будут подтверждены партнером, конечная точка должна передать своему партнеру блок SHUTDOWN, содержащий в поле Cumulative TSN Ack последний порядковый номер TSN, полученный от партнера. После этого конечная точка должна запустить таймер T2-shutdown и перейти в состояние SHUTDOWN-SENT. По завершении отсчета таймера конечная точка должна повторно передать блок SHUTDOWN с обновленным значением последнего порядкового номера TSN, полученного от партнера.

Должны быть выполнены правила параграфа 6.3 для определения корректного значения таймера T2-shutdown. Для индикации пропусков в порядковых номерах TSN конечная точка может группировать SACK и блок SHUTDOWN в одном пакете SCTP.

Конечной точке следует ограничивать число повторов передачи блока SHUTDOWN с помощью протокольного параметра Association.Max.Retrans. После превышения этого порога конечной точке следует уничтожить TCB и обязательно передать информацию о недоступности партнера на вышележащий уровень (тем самым ассоциация переводится в состояние CLOSED). При получении любых пакетов от партнера (блоки DATA из очереди) следует сбрасывать счетчик повтора передачи и заново запускать таймер T2-Shutdown, давая партнеру дополнительную возможность передачи всех остающихся блоков DATA из его очередей.

При получении блока SHUTDOWN конечная точка должна:

  • перейти в состояние SHUTDOWN-RECEIVED;
  • прекратить прием новых данных от своего пользователя SCTP;
  • убедиться путем проверки поля Cumulative TSN Ack, что все блоки DATA приняты отправителем блока SHUTDOWN.

После перехода конечной точки в состояние SHUTDOWN-RECEIVED для нее недопустимо передавать SHUTDOWN в ответ на запрос ULP и следует отбрасывать последующие блоки SHUTDOWN.

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

Находясь в состоянии SHUTDOWN-SENT, отправитель блока SHUTDOWN должен незамедлительно передавать в ответ на каждый принятый пакет, содержащий хотя бы один блок DATA, подтверждение SACK и блок SHUTDOWN, а также заново запускать таймер T2-shutdown. При наличии остающихся блоков DATA получатель блока SHUTDOWN должен передать блок SHUTDOWN ACK, запустить таймер T2-shutdown и перейти в состояние SHUTDOWN-ACK-SENT. По завершении отсчета таймера конечная точка должна повторить передачу блока SHUTDOWN ACK.

Отправителю SHUTDOWN ACK следует ограничивать число повторов передачи SHUTDOWN ACK с помощью протокольного параметра Association.Max.Retrans. После превышения заданного порога конечной точке следует уничтожить TCB и можно сообщить вышележащему уровню о недоступности партнера (тем самым ассоциация переводится в состояние CLOSED).

При получении блока SHUTDOWN ACK отправитель SHUTDOWN должен остановить таймер T2-shutdown, передать своему партнеру блок SHUTDOWN COMPLETE и удалить все записи для данной ассоциации.

При получении блока SHUTDOWN COMPLETE конечная точка будет проверять, что она находится в состоянии SHUTDOWN-ACK-SENT и отбрасывать полученный блок, если состояние отличается от указанного. Если же конечная точка находится в состоянии SHUTDOWN-ACK-SENT, ей следует остановить таймер T2-shutdown и удалить все связанные с ассоциацией записи (тем самым ассоциация переводится в состояние CLOSED).

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

Конечной точке, находящейся в состоянии SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED или SHUTDOWN-ACK-SENT, следует отвергать все новые запросы данных от вышележащего уровня.

Если конечная точка, находящаяся в состоянии SHUTDOWN-ACK-SENT, получает блок INIT (например, при утере блока SHUTDOWN COMPLETE) с транспортными адресами отправителя и получателя (в заголовке IP или блоке INIT), относящимися к данной ассоциации, ей следует отбросить блок INIT и повторить передачу блока SHUTDOWN ACK.

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

Отправителю блока INIT или COOKIE ECHO следует отвечать на получение блока SHUTDOWN-ACK пакетом SCTP, содержащим только блок SHUTDOWN COMPLETE, а в поле Verification Tag общего заголовка следует включать значение тега из полученного пакета SHUTDOWN ACK. Такой пакет рассматривается как OOTB (см. параграф 8.4). Отправитель INIT оставляет работать свой таймер T1-init и сохраняет состояние COOKIE-WAIT или COOKIE-ECHOED. Завершение отсчета таймера T1-init будет приводить к повтору передачи блока INIT или COOKIE и последующему созданию новой ассоциации.

Если получатель блока SHUTDOWN находится в состоянии COOKIE WAIT или COOKIE ECHOED, блок SHUTDOWN следует отбрасывать без уведомления.

Если конечная точка находится в состоянии SHUTDOWN-SENT и получает от своего партнера блок SHUTDOWN, ей следует незамедлительно ответить блоком SHUTDOWN ACK и перейти в состояние SHUTDOWN-ACK-SENT с перезапуском своего таймера T2-shutdown.

Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и получает от партнера блок SHUTDOWN ACK, она должна остановить таймер T2-shutdown, передать партнеру блок SHUTDOWN COMPLETE и удалить все связанные с ассоциацией записи.

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

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

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

10.1 ULP -> SCTP

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

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

  1. A) Initialize — инициализация

Формат: INITIALIZE ([local port], [local eligible address list]) -> имя локального экземпляра SCTP

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

SCTP будет возвращать ULP имя локального экземпляра SCTP.

Обязательные атрибуты:

Нет.

Необязательные атрибуты:

С примитивом могут передаваться следующие типы атрибутов:

  • local port – номер порта SCTP, если ULP хочет задать порт;
  • local eligible address list – список адресов, с которыми следует связать локальную точку SCTP. По умолчанию при отсутствии списка локальная точка связывается со всеми адресами IP, присвоенными данному хосту.

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

  1. B) Associate – создать ассоциацию

Формат: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count)

-> association id [,destination transport addr list] [,outbound stream count]

Этот примитив позволяет инициировать создание ассоциации с указанным партнером.

Конечная точка партнера по создаваемой ассоциации должна указываться одним из транспортных адресов данной точки (см. параграф 1.4). Если локальный экземпляр SCTP еще не был инициализирована, вызов ASSOCIATE рассматривается как ошибка.

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

При создании ассоциации могут возвращаться другие параметры ассоциации, включая полные транспортные адреса партнера, а также счетчик исходящих потоков локальной точки. Один из транспортных адресов удаленного партнера выбирается локальной точкой в качестве первичного (используемого по умолчанию) транспортного адреса для передачи пакетов этому партнеру. Возвращаемый список транспортных адресов партнера (destination transport addr list) может использоваться ULP для смены первичного пути или задания передачи по определенному транспортному адресу партнера.

Примечание для разработчиков. Если примитив ASSOCIATE реализован, как блокируемый вызов функции, он может возвращать кроме идентификатора ассоциации дополнительные параметры. Если примитив ASSOCIATE реализован как неблокируемый вызов, возвращается только идентификатор ассоциации, а параметры созданной ассоциации передаются с использованием уведомления COMMUNICATION UP.

Обязательные атрибуты:

  • local SCTP instance name – возвращается операцией INITIALIZE.
  • destination transport addr – содержит один из транспортных адресов партнера, с которым создается ассоциация.
  • outbound stream count – число исходящих потоков, которые ULP может открывать для передачи данных удаленному партнеру.

Необязательные атрибуты:

Нет.

  1. C) Shutdown – завершение ассоциации

Формат: SHUTDOWN(association id) -> результат

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

Обязательные атрибуты:

  • association id – локальный идентификатор ассоциации SCTP.

Необязательные атрибуты:

Нет.

  1. D) Abort – разрыв ассоциации

Формат: ABORT(association id [, cause code]) -> результат

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP.

Необязательные атрибуты:

  • cause code – причина разрыва ассоциации, передаваемая партнеру.
  1. E) Send – передача данных

Формат: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address]

[,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> результат

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • buffer address – адрес, по которому сохраняется передаваемое пользовательское сообщение;
  • byte count – размер пользовательских данных в байтах.

Необязательные атрибуты:

  • context – необязательное 32-битовое целое число, которое будет передаваться в уведомлении об отказе протоколу ULP, если при передаче пользовательского сообщения произойдет ошибка;
  • stream id – идентификатор потока, используемого для передачи данных (по умолчанию используется поток 0);
  • life time – задает время жизни пользовательских данных. По истечении заданного времени SCTP уже не будет пытаться передавать эти данные. Параметр может использоваться для предотвращения передачи устаревших пользовательских сообщений. SCTP уведомляет ULP, если данные не удается передать с помощью SCTP в течение заданного этой переменной времени. Однако пользовательские данные будут передаваться, если протокол SCTP начал попытки передачи блока данных до истечения заданного времени.

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

  • destination transport address – задает один из транспортных адресов получателя, по которому пакет должен передаваться. По возможности протоколу SCTP следует использовать заданный адрес получателя вместо адреса первичного пути.
  • unorder flag – этот флаг указывает что пользовательские данные доставляются партнеру без соблюдения порядка (т. е., устанавливается флаг U = 1 во всех блоках DATA, содержащих это сообщение).
  • no-bundle flag – указывает протоколу SCTP, что эти данные не должны группироваться с другими передаваемыми блоками DATA. SCTP может выполнять в целях предотвращения перегрузки группировку блоков, игнорируя этот флаг.
  • payload protocol-id – 32-битовое целое число без знака, которое будет передаваться партнеру для индикации типа передаваемых данных. Это значение передается не обрабатывается протоколом SCTP.
  1. F) Set Primary – выбор основного пути

Формат: SETPRIMARY(association id, destination transport address, [source transport address] ) -> результат

Задает для локальной точки SCTP использование указанного транспортного адреса в качестве первичного пути передачи пакетов.

Примитив должен возвращать результат попытки задания первичного пути. Если заданного адреса нет в списке destination transport address list, возвращенном ранее командой создания ассоциации или уведомлением COMMUNICATION UP, должен возвращаться код ошибки.

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – задает один из транспортных адресов партнера для использования в качестве основного пути передачи пакетов. Это значение заменяет собой адрес первичного пути, поддерживавшегося до этого локальной точкой SCTP.

Необязательные атрибуты:

  • source transport address – некоторые реализации могут поддерживать задание адреса отправителя, который будет по умолчанию включаться во все исходящие дейтаграммы IP.
  1. G) Receive – прием данных

Формат: RECEIVE(association id, buffer address, buffer size [,stream id])

-> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]

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

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • buffer address – адрес в памяти, указанный ULP для считывания сообщения.
  • buffer size – максимальный размер считываемых данных в байтах.

Необязательные атрибуты:

  • stream id – для индикации потока, из которого были получены данные.
  • stream sequence number – порядковый номер в потоке, присвоенный передающим партнером SCTP.
  • partial flag – наличие этого флага говорит о том, что данный вызов Receive возвращает часть данных из сообщения. Установка данного флага должна сопровождаться возвратом идентификатора потока и порядкового номера в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных17.
  • payload protocol-id – 32-битовое целое число без знака, полученное от партнера и указывающее тип данных в принятом сообщении. Значение этого параметра передается не обрабатывается протоколом SCTP.
  1. H) Status — статус

Формат: STATUS(association id) -> данные о состоянии

Этот примитив должен возвращать блок данных, содержащий следующую информацию:

  • состояние соединения для ассоциации;
  • список адресов транспортного уровня для получателя;
  • состояния доступности транспортных адресов получателя;
  • текущий размер окна приема;
  • текущий размер окна насыщения;
  • число неподтвержденных блоков DATA;
  • число блоков DATA ожидающих приема;
  • основной путь;
  • самое новое значение SRTT на основном пути;
  • значение RTO для основного пути;
  • значения SRTT и RTO для других путей и т. п.

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP.

Необязательные атрибуты:

Нет.

  1. I) Change Heartbeat – смена режима HeartBeat

Формат: CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> результат

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

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – один из транспортных адресов партнера;
  • new state – новое состояние heartbeat для данного транспортного адреса (enabled или disabled).

Необязательные атрибуты:

  • interval – этот параметр определяет частоту передачи heartbeat, если эта функция включена для транспортного адреса партнера. Значение этого параметра добавляется к RTO транспортного адреса. Данный параметр имеет значение для всех транспортных адресов получателя.
  1. J) Request HeartBeat – запрос на выполнение HeartBeat

Формат: REQUESTHEARTBEAT(association id, destination transport address) -> результат

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес, для которого запрашивается передача блока HEARTBEAT.
  1. K) Get SRTT Report – запрос значения SRTT

Формат: GETSRTTREPORT(association id, destination transport address) -> результат srtt

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес партнера в данной ассоциации, для которого определяется значение SRTT.
  1. L) Set Failure Threshold – задать порог детектирования отказа

Формат: SETFAILURETHRESHOLD(association id, destination transport address, failure threshold) -> результат

Этот примитив позволяет локальному модулю SCTP задать значение порога детектирования отказа Path.Max.Retrans для заданного транспортного адреса.

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес партнера в данной ассоциации, для которого задается порог;
  • failure threshold – новое значение параметра Path.Max.Retrans для заданного транспортного адреса.
  1. M) Set Protocol Parameters – установить параметры протокола

Формат: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> результат

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

Обязательные атрибуты:

  • association id — локальный идентификатор ассоциации SCTP;
  • protocol parameter list – список имен и значений протокольных параметров (например, Association.Max.Retrans), которые будут установлены для протокола SCTP (см. главу 14).

Необязательные атрибуты:

  • destination transport address – некоторые параметры протокола могут независимо устанавливаться для каждого транспортного адреса партнера.
  1. N) Receive unsent message – получить неотправленное сообщение

Формат: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size

[,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

  • data retrieval id – идентификатор, передаваемый ULP в уведомлении об отказе.
  • buffer address – адрес буфера, указанный ULP для записи полученного сообщения.
  • buffer size – максимальный размер принимаемых данных в байтах.

Необязательные атрибуты:

  • stream id – это возвращаемое значение указывает идентификатор потока, в который были переданы данные.
  • stream sequence number – это возвращаемое значение указывает порядковый номер в потоке, связанный с сообщением.
  • partial flag – этот возвращаемый флаг указывает на частичную доставку сообщения. При установке этого флага должны также возвращаться идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных.
  • payload protocol-id – это 32-битовое целое число без знака, которое было передано для идентификации типа полученных данных.
  1. O) Receive unacknowledged message – получить неподтвержденное сообщение

Формат: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,

[,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

  • data retrieval id — идентификатор, передаваемый ULP в уведомлении об отказе.
  • buffer address — адрес буфера, указанный ULP для записи полученного сообщения.
  • buffer size — максимальный размер принимаемых данных в байтах.

Необязательные атрибуты:

  • stream id — это возвращаемое значение указывает идентификатор потока, в который были переданы данные.
  • stream sequence number — это возвращаемое значение указывает порядковый номер в потоке, связанный с сообщением.
  • partial flag — этот возвращаемый флаг указывает на частичную доставку сообщения. При установке этого флага должны также возвращаться идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных.
  • payload protocol-id — это 32-битовое целое число без знака, которое было передано для идентификации типа полученных данных.
  1. P) Destroy SCTP instance – уничтожить экземпляр SCTP

Формат: DESTROY(local SCTP instance name)

  • local SCTP instance name – значение, переданное приложению из примитива инициализации; указывает уничтожаемый экземпляр SCTP.

10.2 SCTP -> ULP

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

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

  1. A) уведомление DATA ARRIVE

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

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

  • association id — локальный идентификатор ассоциации SCTP;
  • stream id – идентификатор потока, в котором были получены данные.
  1. B) уведомление SEND FAILURE

Усли сообщение не может быть доставлено, протокол SCTP должен передать это уведомление ULP.

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

  • association id — локальный идентификатор ассоциации SCTP;
  • data retrieval id – идентификатор, используемый для считывание неотправленных или неподтвержденных данных.
  • cause code – указывает причину отказа (например, слишком большой размер сообщения, завершение срока жизни сообщения и т. п.).
  • context – дополнительная информация, связанная с сообщением (см. D в параграфе 10.1).
  1. C) уведомление NETWORK STATUS CHANGE

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

В уведомлении должна содержаться следующая информация:

  • association id — локальный идентификатор ассоциации SCTP;
  • destination transport address – указывает транспортный адрес партнера для которого зафиксировано изменение состояния;
  • new-status – указывает новое состояние.
  1. D) уведомление COMMUNICATION UP

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

Примечание для разработчиков. Если примитив ASSOCIATE реализован, как блокируемый вызов функции, параметры ассоциации возвращаются самим примитивом ASSOCIATE. В таких случаях на стороне инициатора ассоциации уведомления COMMUNICATION UP становятся необязательными.

В уведомлении должна содержаться следующая информация:

  • association id — локальный идентификатор ассоциации SCTP;
  • status – указывает тип события, с которым связано уведомление;
  • destination transport address list – полный набор транспортных адресов партнера;
  • outbound stream count – максимальное число исходящих потоков, которые ULP может использовать в данной ассоциации;
  • inbound stream count – число потоков, запрошенных партнером (это значение может отличаться от outbound stream count).
  1. E) уведомление COMMUNICATION LOST

Это уведомление должно передаваться протоколом SCTP в случае полной утраты связи с удаленной точкой (например, обнаруженной с помощью Heartbeat) или выполнения удаленной точкой операции прерывания ассоциации (abort).

В уведомлении должна содержаться следующая информация:

  • association id — локальный идентификатор ассоциации SCTP;
  • status — указывает тип события, с которым связано уведомление; этот параметр может говорить об отказе или обычном прекращении работы ассоциации с помощью запроса shutdown или abort.

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

  • data retrieval id — идентификатор, используемый для считывание неотправленных или неподтвержденных данных;
  • Last-acked — последний номер TSN, подтвержденный партнером;
  • last-sent – последний номер TSN, переданный партнеру.
  1. F) уведомление COMMUNICATION ERROR

Когда SCTP получает блок ERROR от своего партнера и решает уведомить об ошибке ULP, этот тип служит для передачи уведомления.

Уведомление может включать следующие параметры:

  • association id — локальный идентификатор ассоциации SCTP;
  • error info – указывает тип ошибки и может содержать дополнительную информацию, полученную из блока ERROR.
  1. G) уведомление RESTART

При обнаружении рестарта на стороне партнера SCTP может использовать этот тип для передачи уведомления ULP.

Уведомление может включать следующие параметры:

  • association id — локальный идентификатор ассоциации SCTP;
  1. H) уведомление SHUTDOWN COMPLETE

Это уведомление SCTP передает на вышележащий уровень при завершении процедуры (параграф 9.2).

Уведомление может включать следующие параметры:

  • association id — локальный идентификатор ассоциации SCTP;

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

11.1 Цели защиты

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

  • доступность сервиса с гарантией своевременной доставки;
  • целостность пользовательской информации, передаваемой через SCTP.

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

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

Операторам систем, использующих SCTP следует использовать [RFC2196] в качестве руководства по обеспечению безопасности своего сайта.

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

Следует использовать принципы, изложенные в [RFC2196] для минимизации риска утечки информации или саботажа со стороны сотрудников. Такие процедуры включают публикацию политики безопасности, контроль доступа к оборудованию, программам и сети, а также разделение служб.

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

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

Для обеспечения повторного использования кода, а также для предотвращения попыток изобрести велосипед и избыточной сложности SCTP следует использовать заголовки аутентификации IP AH18 [RFC2402] SHOULD, если опасная среда требует более сильной защиты целостности, но не требует конфиденциальности.

Существует широко распространенное расширение BSD Sockets API для приложений, которым требуется сервис IP типа AH или ESP на уровне ядра операционной системы. Приложения могут использовать этот API для использования AH в тех случаях, когда это возможно.

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

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

В дополнение к этому пользовательское приложение может использовать специфические для реализации API для запроса сервиса IP ESP19 [RFC2406], обеспечивающего конфиденциальность и целостность.

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

При использовании ESP шифрование данных на прикладном уровне в общем случае не требуется.

Независимо от способа обеспечения конфиденциальности следует использовать механизмы ISAKMP [RFC2408] и IKE20 [RFC2409] для управления ключами.

Операторам следует обратиться к [RFC2401] для получения дополнительной информации по средствам обеспечения безопасности непосредственно поверх уровня IP.

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

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

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

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

В общем случае защита от лавинной атаки начинается при разработке оборудования и включает такие меры, как:

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

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

Протокол SCTP устойчив к лавинным атакам в частности, благодаря использованию четырех-этапного согласования при старте ассоциации, механизма cookie для блокирования ресурсов отвечающего узла до тех пор, пока не будет завершено согласование, и тегов верификации (Verification Tag) для защиты от вставки дополнительных пакетов в поток данных действующей ассоциации.

Механизмы IP AH и ESP могут также оказаться полезными для снижения риска при некоторых типах атак на службы.

Параметр Host Name в блоках INIT можно использовать для лавинной атаки на сервер DNS. Большое количество backlog-запросов к DNS для преобразования Host Name из блоков INIT в IP-адреса может быть вызвано передачей множества запросов INIT в один домен. Кроме того, атакующий может воспользоваться Host Name для непрямой атаки на сторонний сервер, рассылая большое число блоков INIT с именем хоста-жертвы по случайно выбранным адресам. Помимо увеличения нагрузки на DNS, такая атака может привести к генерации и передаче большого числа блоков INIT ACK по адресу атакуемого хоста. Одним из способов защиты от этого типа атак является проверка наличия в числе адресов IP, полученных от DNS, IP-адреса отправителя исходного блока INIT. Если список адресов IP, полученных от сервера DNS, не включает IP-адрес отправителя INIT, конечная точка может отбрасывать блок INIT без уведомления. Отметим, что эта мера не защищает от атак на DNS.

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

Маскирование (Masquerade) может использоваться для атак на службы несколькими способами:

  • путем связывания ресурсов целевого узла SCTP, к которому ролевой (impersonated) узел имеет ограниченный доступ. Например, политика целевого узла может разрешать не более одной ассоциации SCTP с ролевого узла SCTP. Замаскированный атакующий может попытаться организовать ассоциацию и прикинуться ролевым узлом, чтобы впоследствии настоящий ролевой узел не мог подключиться к сервису.
  • посредством преднамеренного обнаружения подмены с целью провоцирования ролевого узла на блокирование целевого узла SCTP.
  • путем взаимодействия с существующей ассоциацией посредством вставки в поток добавочной информации (например, запроса SHUTDOWN).

SCTP снижает риск атак с помощью слепого маскирования с подменой адресов (IP spoofing) за счет использования четырехэтапного согласования при старте ассоциации. Маскирование с человеком в центре (Man-in-the-middle masquerade attack) рассматривается ниже в параграфе 11.3. Поскольку начальный обмен не запоминается, при атаках с маскированием вслепую нет возможности использования механизмов захвата. Кроме того, подтверждение INIT ACK, содержащее State Cookie, передается по адресу IP, с которого был получен блок INIT. Таким образом атакующий не получит блок INIT ACK, содержащий State Cookie. SCTP обеспечивает защиту от вставки дополнительных пакетов в поток данных существующей ассоциации за счет использования тегов верификации (Verification Tag).

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

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

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

Следует вводить административные ограничения на число ассоциаций, создаваемых узлами. Пользовательским приложениям SCTP следует обеспечивать возможность детектирования передачи больших объемов информации или сообщений no-op в данной ассоциации, а также другие механизмы протоколирования и разрыва ассоциаций в соответствии с принятой локальной политикой.

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

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

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

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

Параграф 11.2.4.2 описывает устойчивость SCTP к атакам с маскированием вслепую, обеспечиваемую 4-этапным согласованием при старте и тегами верификации. Verification Tag вместе с номерами TSN обеспечивают защиту от атак с повтором вслепую (blind replay), где данные помещаются в существующую ассоциацию.

Однако SCTP не обеспечивает защиты от атак с человеком в центре (man-in-the-middle), где атакующий может перехватывать и изменять пакеты, передаваемые через ассоциацию. Например, блок INIT ACK включает информацию, которую злоумышленник на пути передачи может перехватить из существующей ассоциации SCTP. Там, где существует возможность организации таких атак или связанный с этим отказ от оплаты, рекомендуется использовать IPSEC AH для обеспечения целостности и аутентичности передаваемых пакетов SCTP.

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

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

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

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

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

Secret Key – закрытый ключ: закрытый ключ используется данной конечной точкой для расчета MAC. В качестве ключа следует использовать случайное число криптографического качества и достаточной длины. Для выбора ключей могут быть полезны рекомендации [RFC1750].

Address List – список адресов: список адресов IP, с которыми связан данный экземпляр. Эта информация передается партнеру в блоках INIT и INIT ACK.

SCTP Port – номер порта: локальный номер порта, с которым связана конечная точка SCTP.

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

Peer Verification Tag: значение тега партнера, передаваемое в каждом пакете и полученное из блока INIT или INIT ACK.

My Verification Tag: значение тега, ожидаемое в каждом входящем пакете и передаваемое партнеру в блоке INIT или INIT ACK.

State: переменная, показывающая в каком состоянии находится ассоциация (COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT).

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

Peer Transport Address List: список транспортных адресов SCTP, с которыми связан партнер. Эта информация извлекается из блоков INIT или INIT ACK и используется для связывания входящих пакетов с данной ассоциацией. Обычно эта информация хэшируется или индексируется (keyed) для быстрого поиска и доступа к TCB.

Primary Path: текущее значение первичного транспортного адреса партнера. Это значение может также указывать адрес отправителя пакетов, получаемых этой точкой.

Overall Error Count: общий счетчик ошибок для всей ассоциации.

Overall Error Threshold: значение количества ошибок для ассоциации, при достижении которого данная ассоциация будет разорвана.

Peer Rwnd: текущее значение окна приема (rwnd), рассчитанное для партнера.

Next TSN: значение следующего номера TSN, которое будет присвоено новому блоку DATA. Начальный номер передается партнеру в блоке INIT или INIT ACK и далее номер увеличивается каждый раз, когда блоку DATA присваивается значение TSN (обычно непосредственно перед передачей или в процессе фрагментации).

Last Rcvd TSN: последний номер TSN, полученный с сохранением порядка. Начальное значение устанавливается на основе параметра Initial TSN, полученного от партнера в блоке INIT или INIT ACK, путем вычитания 1 из полученного значения.

Mapping Array: массив битов или байтов, показывающий какие упорядоченных номеров TSN были получены (относительно Last Rcvd TSN). При отсутствии пропусков (т. е., все пакеты получены с сохранением порядка доставки), этот массив может содержать только нулевые значения. Эта структура может использовать кольцевой буфер или битовый массив.

Ack State: это поле показывает, будет ли передано подтверждение SACK при получении следующего пакета. Начальное значение поля равно 0. При получении пакета значение увеличивается на 1. При достижении значения 2 или более в ответ на получение пакета передается подтверждение SACK и значение снова сбрасывается в 0. Отметим, что описанный механизм используется лишь при отсутствии нарушений в порядке доставки блоков DATA. Если имеется нарушение порядка доставки DATA, подтверждения SACK не задерживаются (см. раздел 6).

Inbound Streams: массив структур для отслеживания входящих потоков. Обычно данные о потоках включают следующий (ожидаемый) порядковый номер и могут включать номер потока.

Outbound Streams: массив структур для отслеживания исходящих потоков. Обычно данные о потоках включают следующий порядковый номер для передачи в поток.

Reasm Queue: очередь сборки фрагментов.

Local Transport Address List: список локальных адресов IP, связанных с данной ассоциацией.

Association PMTU: наименьшее значение PMTU среди всех путей к партнеру.

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

Для каждого транспортного адреса партнера из списка, полученного в блоке INIT или INIT ACK, поддерживается группа параметров, включающая:

Error count: текущее значение счетчика ошибок для данного транспортного адреса.

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

cwnd: текущий размер окна насыщения.

ssthresh: текущее значение порога Slow Start (ssthresh).

RTO: текущее значение тайм-аута для повтора передачи.

SRTT: текущее значение среднего времени кругового обхода.

RTTVAR: изменение текущего значения RTT.

partial bytes acked: метод слежения, используемый для увеличения размера cwnd в режиме предотвращения перегрузки (congestion avoidance, см. параграф 6.2.2).

state: текущее состояние адресата (DOWN, UP, ALLOW-HB, NO-HEARTBEAT и т. п.).

PMTU: текущее известное значение MTU для пути.

Per Destination Timer: таймер, используемый для каждого адреса получателя.

RTO-Pending: флаг, указывающий на то, что один из блоков DATA, переданных по этому адресу, в данный момент используется для расчета RTT. Если флаг сброшен (0), ближайший блок DATA, отправляемый по этому адресу, следует использовать для расчета RTT и установить данный флаг. При завершении расчета RTT (получение подтверждения SACK для блока DATA) флаг сбрасывается.

last-time used: время передачи адресату последнего пакета. Это значение может использоваться для определения необходимости передачи HEARTBEAT.

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

Out Queue: очередь исходящих блоков DATA.

In Queue: очередь входящих блоков DATA.

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

Данный протокол требует резервирования портов (как в TCP) для использования на широко используемых (well known) серверах в Internet. Все порты, зарезервированные для протокола TCP, автоматически резервируются и в пространстве портов SCTP. Запросы на выделение новых номеров должны следовать текущим механизмам IANA для выделения портов TCP.

Данный протокол может также расширяться по согласованию с IANA в трех направлениях:

  • определение новых типов блоков (chunk type),
  • определение новых типов параметров,
  • определение дополнительных кодов причин ошибок для блоков ERROR.

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

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

Определение и использование новых типов блоков (chunk type) является частью SCTP. Таким образом, новые типы блоков выделяются IANA по согласованию с IETF, как описано в [RFC2434].

Документация для новых типов блоков должна включать следующую информацию:

  1. полное и сокращенное имя нового типа блоков;
  2. детальное описание структуры блока, которое должно соответствовать базовой структуре, определенной в параграфе 3.2;
  3. определение и детальное описание каждого поля блока, включая флаги, если они используются;
  4. детальное описание процедур использования нового типа блоков в процессе работы протокола.

Максимальный номер типа (255) зарезервирован для будущих расширений.

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

Выделение новых кодов для параметров блоков осуществляется через IETF Consensus, как описано в [RFC2434]. Документация для новых параметров блока должна включать следующую информацию:

  1. Название типа параметра.
  2. Детальное описание структуры поля параметра. Структура должна соответствовать общему формату TLV22, описанному в параграфе 3.2.1.
  3. детальное описание каждой компоненты значения параметра.
  4. Детальное описание использования этого типа параметра и индикацию возможности и условий, при которых в одном блоке может содержаться более одного экземпляра параметров данного типа.

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

Дополнительные коды причин ошибок могут выделяться из диапазона [11: 65535] с использованием процедуры Specification Required, описанной в [RFC2434].

Документация для кода причины ошибки должна включать:

  1. имя ошибочной ситуации;
  2. детальное описание условий, при которых конечной точке SCTP следует генерировать блок ERROR (или ABORT) с данным кодом причины ошибки;
  3. предполагаемое действие конечной точки SCTP, получившей блок ERROR (или ABORT) с данным кодом;
  4. детальное описание структуры и содержимого полей данных, сопровождающих данный код;

Первое слово (32 бита) кода причины ошибки должно соответствовать формату, описанному в параграфе 3.3.10:

  • первые два байта содержат значение идентификатора кода
  • последние два байта содержат размер Cause Parameter.

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

За исключением значения 0, зарезервированного SCTP для индикации неуказанного протокола в блоках DATA, SCTP не принимает на себя ответственности за стандартизацию или проверку идентификаторов передаваемых протоколов. SCTP просто получает идентификатор от вышележащего уровня и передает его вместе с соответствующими данными.

Вышележащему уровню (например, пользовательскому приложению SCTP) следует стандартизовать нужные значение идентификаторов протоколов в IANA, если это нужно. Использование тех или иных значений идентификаторов передаваемых протоколов выходит за пределы спецификации SCTP.

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

Рекомендуется использовать следующие значения параметров протокола:

RTO.Initial — 3 секунды

RTO.Min — 1 секунда

RTO.Max — 60 секунд

RTO.Alpha — 1/8

RTO.Beta — 1/4

Valid.Cookie.Life — 60 секунд

Association.Max.Retrans — 10 попыток

Path.Max.Retrans — 5 попыток (для каждого адреса получателя)

Max.Init.Retransmits — 8 попыток

HB.interval — 30 секунд

Примечание для разработчиков. Реализация SCTP может разрешать ULP изменение некоторых параметров протокола (см. раздел 10).

Примечание. Для RTO.Min следует использовать приведенное выше значение.

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

Авторы выражают свою признательность Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll и другим людям, внесшим свой вклад в обсуждение протокола.

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

Randall R. Stewart

24 Burning Bush Trail.

Crystal Lake, IL 60012

USA

Phone: +1-815-477-2127

EMail: rrs@cisco.com

 

Qiaobing Xie

Motorola, Inc.

1501 W. Shure Drive, #2309

Arlington Heights, IL 60004

USA

Phone: +1-847-632-3028

EMail: qxie1@email.mot.com

 

Ken Morneault

Cisco Systems Inc.

13615 Dulles Technology Drive

Herndon, VA. 20171

USA

Phone: +1-703-484-3323

EMail: kmorneau@cisco.com

 

Chip Sharp

Cisco Systems Inc.

7025 Kit Creek Road

Research Triangle Park, NC 27709

USA

Phone: +1-919-392-3121

EMail: chsharp@cisco.com

 

Hanns Juergen Schwarzbauer

SIEMENS AG

Hofmannstr. 51

81359 Munich

Germany

Phone: +49-89-722-24236

EMail: HannsJuergen.Schwarzbauer@icn.siemens.de

 

Tom Taylor

Nortel Networks

1852 Lorraine Ave.

Ottawa, Ontario

Canada K1H 6Z8

Phone: +1-613-736-0961

EMail: taylor@nortelnetworks.com

 

Ian Rytina

Ericsson Australia

37/360 Elizabeth Street

Melbourne, Victoria 3000

Australia

Phone: +61-3-9301-6164

EMail: ian.rytina@ericsson.com

 

Malleswar Kalla

Telcordia Technologies

3 Corporate Place

PYA-2J-341

Piscataway, NJ 08854

USA

Phone: +1-732-699-3728

EMail: mkalla@telcordia.com

 

Lixia Zhang

UCLA Computer Science Department

4531G Boelter Hall

Los Angeles, CA 90095-1596

USA

Phone: +1-310-825-2695

EMail: lixia@cs.ucla.edu

 

Vern Paxson

ACIRI

1947 Center St., Suite 600,

Berkeley, CA 94704-1198

USA

Phone: +1-510-666-2882

EMail: vern@aciri.org

 

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

17. Документы

[RFC768] Postel, J. (ed.), «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC793] Postel, J. (ed.), «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1123] Braden, R., «Requirements for Internet hosts – application and support», STD 3, RFC 1123, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU Discovery», RFC 1191, November 1990.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 170023, October 1994.

[RFC1981] McCann, J., Deering, S. and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC1982] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, August 1996.

[RFC2026] Bradner, S., «The Internet Standards Process – Revision 3», BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240124, November 1998.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240225, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240626, November 1998.

[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, «Internet Security Association and Key Management Protocol», RFC 240827, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 24093, November 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC2581] Allman, M., Paxson, V. and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

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

[ALLMAN99] Allman, M. and Paxson, V., «On Estimating End-to-End Network Path Properties», Proc. SIGCOMM’99, 1999.

[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.

[RFC1750] Eastlake, D. (ed.), «Randomness Recommendations for Security», RFC 175028, December 1994.

[RFC1950] Deutsch P. and J. Gailly, «ZLIB Compressed Data Format Specification version 3.3», RFC 1950, May 1996.

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, March 1997.

[RFC2196] Fraser, B., «Site Security Handbook», FYI 8, RFC 2196, September 1997.

[RFC2522] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, March 1999.

[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., «TCP Congestion Control with a Misbehaving Receiver»29, ACM Computer Communication Review, 29(5), October 1999.

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

ECN (Ramakrishnan, K., Floyd, S., «Explicit Congestion Notification», RFC 2481, January 1999) описывает предложенное расширение протокола IP, включающее метод получения информации о насыщении в сети, отличный от детектирования потери дейтаграмм. Эта дополнительная функция может быть реализована и в протоколе SCTP. В данном приложении рассматриваются незначительные отличия, которые следует принимать во внимание при реализации этого механизма в SCTP. В целом нужно следовать рекомендациям RFC 2481 с учетом перечисленных ниже отличий.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Parameter Type = 32768      |     Parameter Length = 4      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Negotiation

RFC 2481 описывает согласование ECN на этапах SYN и SYN-ACK организации соединения TCP. Отправитель SYN устанавливает два бита в поле флагов TCP, а отправитель SYN-ACK – только 1 бит. Это сделано для того, чтобы убедиться в поддержке ECN на обеих сторонах соединения. Для протокола SCTP этого не требуется. Для индикации поддержки механизма ECN конечной точке следует добавить в блок INIT или INIT ACK структуру TLV, зарезервированную для ECN. TLV не включает параметров и имеет формат, показанный на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000|    Chunk Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Lowest TSN Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ECN-Echo

В соответствии с RFC 2481 получатель пакета устанавливает в передаваемом подтверждении специальный бит, который уведомляет отправителя CE31 о получении информации. Для SCTP подобная индикация осуществляется с путем включения специального блока ECNE. Этот блок содержит единственный элемент данных – минимальный номер TSN, связанный с дейтаграммой IP, промаркированной битом CE, как показано на рисунке.

Примечание. ECNE рассматривается как управляющий блок (Control chunk).

CWR

 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=13 | Flags=00000000|    Chunk Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Lowest TSN Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В соответствии с RFC 2481 отправитель устанавливает специальный бит CWR32 в заголовке следующего исходящего сегмента TCP для индикации снижения размера окна насыщения. Для SCTP такая индикация может обеспечиваться включением блока CWR. Этот блок содержит единственный элемент данных – номер TSN, который был передан в блоке ECNE. Этот элемент представляет наименьший номер TSN в дейтаграмме, которая была изначально помечена битом CE.

Примечание. Блок CWR относится к числу управляющих блоков.

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

Приведенный в этом приложении алгоритм расчета контрольной суммы Adler-32 скопирован из [RFC1950].

Контрольная сумма Adler-32 состоит из двух сумм, собранных для каждого байта: s1 представляет собой сумму значений всех байтов, а s2 – сумму всех значений s1. Обе суммы вычисляются по модулю 65521. Сумма s1 инициализируется значением 1, s2 – значением 0. Контрольная сумма Adler-32 сохраняется как s2*65536 + s1 с использованием сетевого порядка байтов.

Приведенный ниже код на языке C обеспечивает расчет контрольной суммы Adler-32 для буфера данных. Код оптимизирован с точки зрения понимания, а не скорости выполнения. В примере используется диалект ANSI C. Для читателей, не знакомых с языком C ниже приведены некоторые пояснения:

&      битовый оператор AND (И).
>>     оператор сдвига битов вправо. При использовании с числами без знака (как в приведенном примере) освобождающиеся слева биты заполняются нулями.
<<     оператор сдвига битов влево. Освобождающиеся справа биты заполняются нулями.
++     "n++" увеличивает значение переменной n на 1.
%      остаток от деления: a % b дает остаток от деления a на b.

#define BASE 65521 /* наибольшее значение суммы, не превышающее 65536 */
/*
Обновляет контрольную сумму Adler-32, учитывая в ней байты buf[0..len-1], и возвращает обновленное значение. Контрольную сумму Adler-32 следует инициализировать значением 1.
Пример использования:
	unsigned long adler = 1L;

       while (read_buffer(buffer, length) != EOF) {
       	adler = update_adler32(adler, buffer, length);
	}
       if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler, unsigned char *buf, int len)
{
       unsigned long s1 = adler & 0xffff;
       unsigned long s2 = (adler >> 16) & 0xffff;
       int n;

       for (n = 0; n < len; n++) {
       	s1 = (s1 + buf[n]) % BASE;
          	s2 = (s2 + s1)     % BASE;
       }
       return (s2 << 16) + s1;
}

/* Возвращает значение суммы Adler-32 для байтов buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
	return update_adler32(1L, buf, len);
}

Полное заявление авторских прав

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Финансирование функций RFC Editor обеспечено Internet Society.

1Если реализация поддерживает таймеры для каждого блока DATA, для повторной передачи помечаются только блоки DATA, для которых истекло заданное таймером время.

2Retransmission timeout — тайм-аут для повтора.

3Smoothed round-trip time – усредненное время кругового обхода.

4Round-trip time variation – вариации времени кругового обхода.

5Значение SRTT используемое для обновления RTTVAR представляет собой SRTT до обновления. После расчета следует обновить RTO <- SRTT + 4 * RTTVAR.

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

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

8Receiver advertised window size.

9Congestion control window. Для краткости будем называть его просто окном насыщения. Прим. перев.

10Slow-start threshold.

11Maximum Segment Size.

12Максимальное число повторов передачи для ассоциации.

13Максимальное число повторов для пути.

14Heartbeat period.

15out of the blue

16Разрыв соединений. Прим. перев.

17Сообщение прочитано целиком. Прим. перев.

18Authentication Header.

19Encapsulating Security Payload.

20Internet Key Exchange.

21Сервер, предоставляющий в сеть те или иные услуги. Прим. перев.

22Type-length-value — тип-размер-значение.

23В соответствии с RFC 3232 документ Assigned Numbers утратил прежнее значение, а информация о выделенных номерах хранится в реестре на сайте http://www.iana.org/numbers.html. Прим. перев.

24Этот документ в настоящее время заменен RFC 4301. Прим. перев.

25Этот документ в настоящее время заменен RFC 4302. Прим. перев.

26Этот документ в настоящее время заменен RFC 4305. Прим. перев.

27Этот документ в настоящее время заменен RFC 4306. Прим. перев.

28Этот документ в настоящее время заменен RFC 4086. Прим. перев.

29Копию этой статьи можно загрузить с сайта http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf. Прим. перев.

30Explicit Congestion Notification.

31Congestion Experienced.

32Congestion Window Reduced – окно насыщения уменьшено.

 

Please follow and like us:
error
Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий