RFC 4960 (Часть 2)

Please enter banners and links.

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, полученные во всех прочих состояниях, следует отбрасывать.

Подтверждения 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.

           +----------------------------+
           | Пользовательское сообщение |
           +----------------------------+
Пользователь 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 Пример передачи пользовательских данных

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

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

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

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

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

    Когда анонсированное получателем окно имеет нулевой размер, это называется «проверкой нулевого окна (zero window probe). Отметим, что такие пробы следует передавать только в тех случаях, когда все блоки DATA имеют кумулятивное подтверждение и нет находящихся «на лету» блоков DATA. Реализации должны поддерживать проверку нулевого окна.

    Если отправитель продолжает принимать новые пакеты от получателя во время проверки нулевого окна, отсутствие подтверждения проб не следует использовать для инкрементирования счетчика ошибок для ассоциации или каких-либо транспортных адресов партнера. Это связано с тем, что получатель может держать свое окно закрытым в течение неопределенного времени. Поведение получателя, анонсирующего нулевое окно, описано в параграфе 6.2. Отправителю следует передавать первую пробу нулевого окна по истечении 1 RTO с момента обнаружения закрытия окна получателем, а также следует экспоненциально увеличивать интервал между проверками. Отметим также, что значение cwnd следует подстраивать в соответствии с параграфом 7.2.1. Проверки нулевого окна не оказывают влияния на расчет cwnd.

    Отправитель должен также поддерживать алгоритм отправки новых блоков DATA, позволяющий предотвратить синдром SWS1, как описано в [RFC0813]. Алгоритм может быть похож на описанный в параграфе 4.2.3.4 [RFC1122].

    Однако, независимо от значения rwnd (включая 0), отправитель может всегда держать один блок DATA в состоянии на пути к получателю, если позволяет cwnd (см. правило B). Это позволяет отправителю проверять изменение rwnd, о котором отправитель не знает по причине утери подтверждения SACK в процессе доставки от получателя.

  2. В любой момент времени для отправителя недопустимо передавать информацию по данному транспортному адресу, если имеется cwnd или более неподтвержденных байтов данных для этого адреса.

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

  4. Когда приходит время отправителю передавать новые блоки DATA, следует использовать протокольный параметр Max.Burst для ограничения числа передаваемых пакетов. Ограничение может быть реализовано путем изменения cwnd

    if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + Max.Burst*MTU

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

  5. Отправитель может передать столько новых блоков 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, когда этот блок приходит в окне приема.

Когда получатель анонсирует размер окна 0, он должен отбрасывать все новые входящие блоки DATA со значением TSN, превышающим максимальное полученное до этого значение TSN. Если в новом входящем блоке DATA значение TSN меньше максимального из принятых до этого блоков, получателю следует отбросить наибольшее значение TSN, хранящееся для упорядочения, и воспринять новый блок DATA. В любом случае при отбрасывании блока DATA получатель должен незамедлительно вернуть блок SACK с текущим окном приема, показывающим лишь блоки DATA, полученные и воспринятые к этому моменту. Отброшенные блоки DATA недопустимо включать в SACK, поскольку они не были восприняты. Получатель должен также иметь алгоритм анонсирования своего приемного окна для предотвращения синдрома SWS, как описано в [RFC0813]. Это алгоритм может быть похож на описанный в параграфе 4.2.3.3 [RFC1122].

При передаче подтверждений следует придерживаться рекомендаций по использованию алгоритма отложенных подтверждений, описанного в параграфе 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. Конечная точка SCTP должна сообщить, сколько Gap Ack Block можно поместить в один блок SACK с учетом текущего значения MTU для пути.

Примечание. Блок 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 = a_rwnd2 (указано партнером в блоке INIT или INIT ACK).

  2. Всякий раз при передаче (или повторе) блока DATA партнеру конечная точка вычитает размер переданной информации из значения rwnd для этого партнера.

  3. Всякий раз, когда блок DATA помечается для повтора (по таймеру T3-rtx (параграф 6.3.3) или fast retransmit (параграф 7.2.4)), размер этого блока добавляется к значению rwnd.

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

  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.

    4. Если Cumulative TSN Ack совпадает со значением для точки выхода из процедуры Fast Recovery (параграф 7.2.4) или превышает его, процедура Fast Recovery завершается.

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

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

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

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

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’, следует установить

    RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| 
    SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

    Примечание. Значение SRTT используемое для обновления RTTVAR представляет собой SRTT до обновления.

    После расчета следует обновить RTO <- SRTT + 4 * RTTVAR.

  4. Когда данные находятся в процессе доставки и выполняется правило C5, для каждого кругового обхода должно быть выполнено новое измерение RTT. Новое измерение RTT следует проводить не более одного раза на круговой обход для данного транспортного адреса. Такое ограничение обусловлено 2 причинами. Во-первых, более частые измерения не имеют смысла, поскольку не дают заметных преимуществ [ALLMAN99], во-вторых, при частых измерениях значения RTO.Alpha и RTO.Beta в правиле C3 следует подбирать так, чтобы значения SRTT и RTTVAR рассчитывались примерно с такой же частотой (в терминах количества круговых обходов, при котором новые значения вступают в силу), как при одном измерении на круговой обход и с использованием RTO.Alpha и RTO.Beta в правиле C3. Однако точная процедура расчетов требует дополнительных исследований.

  5. Алгоритм Karn – измерение RTT недопустимо выполнять с использованием передаваемых повторно пакетов, поскольку нет возможности различить, к какой из переданных копий относится полученный отклик.

    Примечание для разработчиков. Измерение RTT с использованием блока с TSN r следует выполнять лишь в тех случаях, когда нет блоков с номерами TSN меньшими или равными r, повторно переданными с момента первой передачи r.

  6. Если после расчета RTO получается значение меньше RTO.Min, устанавливается RTO = RTO.Min. Причина этого заключается в том, что использование слишком малых значений RTO будет приводить к возникновению неоправданных тайм-аутов [ALLMAN99].

  7. Максимальное значение RTO составляет по крайней мере RTO.max секунд.

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

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

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

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

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

  1. Точка 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. Пример правил для таймера

    Каждый раз при передаче (включая повторы) блока 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.

Если партнер является многодомным, конечной точке 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. Расчет контрольных сумм CRC32c

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

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

  1. Заполнить поле Verification Tag общего заголовка SCTP и установить нулевое значение в поле контрольной суммы.

  2. Рассчитать контрольную сумму CRC32c с включением общего заголовка SCTP и всех блоков из пакета. Описание алгоритма CRC32c приводится в Приложении B.

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

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

  1. Сохранить полученное в пакете значение контрольной суммы CRC32c.

  2. Заменить 32-битовое поле контрольной суммы принятого пакета SCTP значением 0 и рассчитать контрольную сумму CRC32c для измененного пакета.

  3. Сравнить сохраненное значение (из пакета) CRC32c с контрольной суммой, полученной в результате расчета. Если значения не совпадут, получатель должен трактовать принятый пакет как некорректный.

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

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

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

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

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

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

Принимающая сторона должна обрабатывать полученные блоки в порядке их следования в пакете. Получатель использует поле длины блока для определения конца данного блока и начала следующего. При определении начала блока не следует забывать о выравнивании блоков по 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-Start и Congestion Avoidance

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

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

  • Анонсируемый получателем размер окна приема (rwnd7, в байтах) устанавливается получателем данных с учетом возможностей выделения буферов для принимаемых пакетов.

    Примечание. Эта переменная имеет общее значение для всей ассоциации.

  • Окно контроля насыщения (cwnd8, в байтах) устанавливается отправителем с учетом условий в сети.

    Примечание. Эта переменная поддерживается для каждого адреса получателя.

  • Порог замедленного старта (ssthresh9, в байтах) используется отправителем для принятия решения о выборе используемого алгоритма контроля насыщения (slow start или congestion) на данной фазе.

    Примечание. Эта переменная поддерживается для каждого адреса получателя.

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

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

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

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

  • В качестве стартового значения cwnd до передачи блоков DATA или после достаточно долгого бездействия должно выбираться значение min(4*MTU, max (2*MTU, 4380 байта).

  • Начальное значение cwnd после тайм-аута для повтора передачи должно быть не более 1*MTU.

  • Начальное значение ssthresh может быть произвольно большим (например, реализация может просто установить для этого параметра значение размера окна приема, анонсируемого получателем).

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

  • Если cwnd не больше ssthresh, конечная точка SCTP должна использовать алгоритм slow-start для увеличения размера cwnd только в том случае, когда текущее окно насыщения полностью использовано, входящих блок SACK указывает за пределы Cumulative TSN Ack Point и отправитель данных не находится в состоянии Fast Recovery. Размер окна cwnd можно увеличивать только при выполнении всех трех условий, в противном случае он не должен увеличиваться. Если все три условия выполнены, значение 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, 4*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, 4*MTU) в расчете на RTO, если отправитель не передает блоков DATA по данному адресу.

  • Когда все переданные отправителем данные подтверждены получателем, устанавливается partial_bytes_acked = 0.

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

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

      ssthresh = max(cwnd/2, 4*MTU)
      cwnd = ssthresh
      partial_bytes_acked = 0

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

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

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

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

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

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

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

Для индикации пропусков следует применять алгоритм HTNA10. Для каждого входящего блока SACK значение счетчика индикации пропуска увеличивается только для пропущенных TSN до максимального значения TSN, недавно подтвержденного в SACK. Недавно подтвержденным блоком DATA считается блок, который не был ранее указан в SACK. Если конечная точка находится в состоянии Fast Recovery и получает блок SACK, указывающий за пределы Cumulative TSN Ack Point, значения индикации пропуска увеличиваются для всех TSN, пропуск которых указывает этот блок SACK.

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

  1. Пометить указанные блоки DATA для повторной передачи.

  2. Если не введен режим Fast Recovery, изменить значения ssthresh и cwnd для адреса (или нескольких адресов) получателя, по которому были переданы утерянные данные в последний раз, согласно выражениям, приведенным в параграфе 7.2.3.

  3. Определить, сколько наиболее ранних (т. е., с меньшими номерами TSN) блоков DATA может быть включено в один пакет с учетом значения path MTU для транспортного адреса получателя, по которому будут передаваться данные (обозначим это количество буквой K). Повторно передать эти K блоков DATA в одном пакете. В режиме Fast Retransmit отправителю следует игнорировать значение cwnd и не следует задерживать повтор передачи для одного данного пакета.

  4. Заново запустить таймер T3-rtx, если последнее подтверждение SACK относится к меньшему из неподтвержденных номеров TSN для данного адреса получателя или конечная точка повторяет передачу первого из неподтвержденных блоков DATA, переданных по этому адресу.

  5. Пометить блок(и) DATA, как ускоренно повторенный и не приемлемый для последующего режима Fast Retransmit. Эти TSN маркируются для повторной передачи по причине того, что алгоритм Fast-Retransmit не подходит для дейтаграммы, содержащей K других TSN, которые также отмечены не приемлемыми для последующего ускоренного повтора. Однако в результате их маркировки для повтора эти номера будут переданы заново, как только позволит cwnd.

  6. Перейти в режим Fast Recovery (если он еще не введен) и указать старший неподтвержденный номер TSN в качестве точки выхода из режима быстрого восстановления. Когда блок SACK подтвердит все TSN, вплоть до указанной точки выхода, режим быстрого восстановления завершается. В режиме Fast Recovery значения ssthresh и cwnd не следует менять для каких-либо получателей по причине последующей процедуры быстрого восстановления (т. е., не следует снижать значение cwnd в результате последующего ускоренного повтора).

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

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

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

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

В [RFC4821], [RFC1981] и [RFC1191] описан алгоритм определения MTU для путей с коммутацией пакетов (Packetization Layer Path MTU Discovery), позволяющий конечным точкам оценить максимальный размер передаваемого блока (MTU11) для данного пути через Internet и воздерживаться от передачи по этому пути пакетов, размер которых превышает MTU, без использования методов зондирования с целью определения изменений Path MTU (PMTU). В [RFC4821] подробно рассмотрен механизм определения MTU и стратегия установки сквозного значения MTU для пути, а также детектирования изменений MTU.

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

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

  1. Ассоциация SCTP может включать множество адресов. Конечная точка должна поддерживать отдельную оценку значения MTU для каждого из адресов своего партнера.

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

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

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

Конечной точке следует подсчитывать общее количество последовательных повторов передачи своему партнеру (включая повторы по всем адресам для многодомных партнеров) с учетом неподтвержденных блоков HEARTBEAT. Если значение этого счетчика превысит порог, указанный параметром протокола 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. Передача HEARTBEAT может начинаться с момента перехода в состояние ESTABLISHED и завершаться после отправки блока SHUTDOWN или SHUTDOWN-ACK. Получатель блока должен отвечать на него блоком HEARTBEAT-ACK после перехода в состояние COOKIE-ECHOED (отправитель INIT) или ESTABLISHED (получатель INIT), пока не перейдет в состояние SHUTDOWN-SENT (отправитель SHUTDOWN) или SHUTDOWN-ACK-SENT (получатель SHUTDOWN).

Транспортный адрес рассматривается как бездействующий (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. Обработка неожиданных пакетов

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

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

  1. Если в пакете OOTB указан отличный от индивидуального (non-unicast) адрес отправителя или получателя, такой пакет следует отбрасывать без уведомления.

  2. Если пакет OOTB содержит блок ABORT, получатель должен отбросить такой пакет без уведомления и выполнения каких-либо дополнительных действий.

  3. Если пакет содержит блок INIT с полем Verification Tag = 0, он обрабатывается, как описано в параграфе 5.1. Если по той или иной причине нормальная обработка INIT не возможна и в ответ передается блок ABORT, поле Verification Tag в пакете, содержащем блок ABORT должно иметь значение Initiate Tag из полученного блока INIT, а бит T в блоке ABORT должен быть сброшен (0) для индикации того, что значение Verification Tag не отражено.

  4. Если пакет содержит COOKIE ECHO в первом блоке, обработка пакета выполняется в соответствии с параграфом 5.1.

  5. Eсли пакет содержит блок SHUTDOWN ACK, получателю следует передать отправителю пакета OOTB блок SHUTDOWN COMPLETE. При передаче блока SHUTDOWN COMPLETE получатель пакета OOTB должен заполнить поле Verification Tag, скопировав в него значение Verification Tag из блока SHUTDOWN ACK, и установить бит T в поле флагов блока для индикации отражения Verification Tag.

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

  7. Если пакет содержит Stale cookie ERROR или блок COOKIE ACK, пакет SCTP следует отбросить без уведомления.

  8. В остальных случаях получателю следует ответить отправителю пакета OOTB пакетом с блоком ABORT. При передаче блока ABORT получатель пакета OOTB должен указать в поле Verification Tag значение Verification Tag из пакета OOTB и установить бит T в поле флагов для индикации отражения Verification Tag. После передачи блока 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, в поле верификации должен использоваться тег адресата, а установка флага T недопустима. При отсутствии TCB отправителю следует использовать значение Verification Tag из блока SHUTDOWN ACK и он должен установить флаг T.

  • Получатель SHUTDOWN COMPLETE должен воспринять пакет, если поле Verification Tag соответствует его собственному тегу и в поле флагов бит T не установлен или поле соответствует тегу партнера и бит T установлен. В противном случае получатель должен отбрасывать пакет без уведомления и выполнения каких-либо иных действий. Конечная точка должна игнорировать SHUTDOWN COMPLETE, если она не находится в состоянии SHUTDOWN-ACK-SENT.

  1. Правила для пакетов с блоками COOKIE ECHO.

  • При передаче COOKIE ECHO конечная точка должна использовать значение Initial Tag из принятого блока INIT ACK.

  • Получателю COOKIE ECHO следует выполнить процедуры, описанные в разделе 5.

  1. Правило для пакетов с блоками SHUTDOWN ACK.

    1. Если получатель находится в состоянии COOKIE-ECHOED или COOKIE-WAIT, следует выполнить процедуры, описанные в параграфе 8.4 (т. е., пакет должен трактоваться как OOTB).

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

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

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

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

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

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

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

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

Используя примитив SHUTDOWN (параграф 10.1), вышележащий уровень конечной точки ассоциации может выполнить аккуратное завершение работы ассоциации. В этом случае все остающиеся блоки 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. Если блок SHUTDOWN сам по себе не может подтвердить все принятые блоки DATA (т. е., имеются номера TSN, которые могут быть подтверждены, но превышают кумулятивное значение TSN и в последовательности TSN возникает пропуск) или получены дубликаты TSN, должен передаваться также блок SACK.

Отправитель блока SHUTDOWN может также запустить таймер T5-shutdown-guard для ограничения общей продолжительности процедуры завершения ассоциации. По завершению отсчета этого таймера отправителю следует разорвать ассоциацию передачей блока ABORT. При использовании таймера T5-shutdown-guard для него следует устанавливать рекомендуемое значение 5 * RTO.Max.

Если у получателя блока SHUTDOWN больше не остается блоков DATA, он должен передать блок 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 должен выполнять для поддержки обмена данными между процессами. Та или иная реализация протокола может определять свой формат и поддерживать комбинации или подмножества базовых функций в одном вызове.

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 из заданного параметром списка.

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

Формат

ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]

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

Конечная точка партнера по создаваемой ассоциации должна указываться одним из транспортных адресов данной точки (см. параграф 1.3). Если локальный экземпляр 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 будет открывать для обмена данными с удаленным партнером.

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

Нет.

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

Формат

SHUTDOWN(association id) -> результат

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

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

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

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

Нет.

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

Формат

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

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

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

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

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

  • Upper Layer Abort Reason – причина разрыва ассоциации, передаваемая партнеру.

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.

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.

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, если такой буфер имеется. После выполнения команды возвращается размер прочитанных данных в байтах. В зависимости от реализации может также возвращаться такая информация, как адрес отправителя, идентификатор потока, из которого получены данные, сведения о наличии дополнительных данных для прочтения и т. п. Для упорядоченных сообщений может также возвращаться порядковый номер в потоке (Stream Sequence Number).

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

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

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

  • buffer address – адрес в памяти, указанный ULP для считывания сообщения;

  • buffer size – максимальный размер считываемых данных в байтах.

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

  • stream id – для индикации потока, из которого были получены данные.

  • Stream Sequence Number – порядковый номер в потоке, присвоенный передающим партнером SCTP.

  • partial flag – наличие этого флага говорит о том, что данный вызов Receive возвращает часть данных из сообщения. Установка данного флага должна сопровождаться возвратом идентификатора потока и порядкового номера в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных16.

  • payload protocol-id – 32-битовое целое число без знака, полученное от партнера и указывающее тип данных в принятом сообщении. Значение этого параметра передается не обрабатывается протоколом SCTP.

H) Status – статус

Формат

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

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

  • состояние соединения для ассоциации;

  • список адресов транспортного уровня для получателя;

  • состояния доступности транспортных адресов получателя;

  • текущий размер окна приема;

  • текущий размер окна насыщения;

  • число неподтвержденных блоков DATA;

  • число блоков DATA ожидающих приема;

  • основной путь;

  • самое новое значение SRTT на основном пути;

  • значение RTO для основного пути;

  • значения SRTT и RTO для других путей и т. п.

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

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

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

Нет.

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 транспортного адреса. Данный параметр действует для всех транспортных адресов получателя.

J) Request HeartBeat – запрос на выполнение HeartBeat

Формат

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

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

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

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

  • destination transport address – транспортный адрес, для которого запрашивается передача блока HEARTBEAT.

K) Get SRTT Report – запрос значения SRTT

Формат

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

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

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

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

  • destination transport address – транспортный адрес партнера в данной ассоциации, для которого определяется значение SRTT.

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 для заданного транспортного адреса.

M) Set Protocol Parameters – установить параметры протокола

Формат

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

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

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

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

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

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

  • destination transport address – некоторые параметры протокола могут независимо устанавливаться для каждого транспортного адреса партнера.

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-битовое целое число без знака, которое было передано для идентификации типа полученных данных.

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-битовое целое число без знака, которое было передано для идентификации типа полученных данных.

P) Destroy SCTP instance – уничтожить экземпляр SCTP

Формат

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

10.2. SCTP -> ULP

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

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

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

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

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

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

  • stream id – идентификатор потока, в котором были получены данные.

B) уведомление SEND FAILURE

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

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

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

  • data retrieval id – идентификатор, используемый для считывание неотправленных или неподтвержденных данных;

  • cause code – указывает причину отказа (например, слишком большой размер сообщения, завершение срока жизни сообщения и т. п.);

  • context – дополнительная информация, связанная с сообщением (см. D в параграфе 10.1).

C) уведомление NETWORK STATUS CHANGE

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

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

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

  • destination transport address – указывает транспортный адрес партнера для которого зафиксировано изменение состояния;

  • new-status – указывает новое состояние.

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).

E) уведомление COMMUNICATION LOST

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

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

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

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

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

  • data retrieval id – идентификатор, используемый для считывание неотправленных или неподтвержденных данных;

  • last-acked – последний номер TSN, подтвержденный партнером;

  • last-sent – последний номер TSN, переданный партнеру.

  • Upper Layer Abort Reason – причина прерывания указывается в случае разрыва по инициативе пользователя.

F) уведомление COMMUNICATION ERROR

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

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

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

  • error info – указывает тип ошибки и может содержать дополнительную информацию из блока ERROR.

G) уведомление RESTART

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

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

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

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-AUTH17 [RFC4895], если среда с угрозами требует сильной защиты целостности, не требуя защиты конфиденциальности.

11.2.3. Защита конфиденциальности

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

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

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

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

Операторам следует обратиться к [RFC4301] для получения дополнительной информации по средствам обеспечения безопасности непосредственно поверх уровня 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. Взаимодействие SCTP с межсетевыми экранами

Для некоторых межсетевых экранов будет полезна возможность проверки первого фрагмента фрагментированного пакета SCTP и однозначного определения его соответствия блоку INIT (см. дополнтельную информацию в [RFC1858]). Поэтому еще раз подчеркиваются требования, приведенные в параграфе 3.1, – (1) блок INIT недопустимо группировать с каким-либо другим блоком в одном пакете, (2) пакет с блоком INIT должен иметь Verification Tag = 0. Кроме того, проверка выполнения этих правил должна быть реализована на приемной стороне с отбрасыванием блоков INIT, сгруппированных с другими блоками, или имеющих отличный от нуля тег верификации.

11.4. Защита хостов, не поддерживающих SCTP

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

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

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

Реализация SCTP, получающая блок INIT, для отклика на который требуется большой пакет по причине включения в него множества параметров ERROR, может (по своему усмотрению) опустить часть или все параметры ERROR для снижения размера INIT ACK. С учетом размера параметра COOKIE и множества адресов, которые получатель INIT может указывать своему партнеру, размер блока INIT ACK может превышать размер исходного блока INIT. Реализациям SCTP следует предпринимать попытку максимального снижения размера блоков INIT ACK для снижения возможности организации «атак с усилением» (byte amplification attack).

12. Вопросы управления сетью

Модуль MIB для протокола SCTP, определенный в [RFC3873], применим для описанной здесь версии протокола.

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

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

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

Associations – ассоциации

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

Secret Key – секретный ключ

Секретный ключ используется данной конечной точкой для расчета MAC. В качестве ключа следует использовать случайное число криптографического качества и достаточной длины. Для выбора ключей могут быть полезны рекомендации RFC 4086.

Address List – список адресов

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

SCTP Port – номер порта

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

13.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 среди всех путей к партнеру.

13.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

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

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

Out Queue

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

In Queue

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

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

SCTP определяет три реестра, поддерживаемых агентством IANA:

  • типы блоков;

  • типы параметров;

  • коды причины ошибки в блоках ERROR.

Протокол SCTP требует создания в реестре IANA Port Numbers записи для порта SCTP, как описано в параграфе 14.5. Запросы на выделение номера порта SCTP поддержаны выделенным IESG экспертом.

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

Выделение новых кодов для блоков SCTP (chunk type code) осуществляется в соответствии с процедурой IETF Consensus, определенной в [RFC2434]. Документация для блока должна включать:

  1. полное и сокращенное имя нового типа блоков;

  2. подробное описание структуры блока, которое должно соответствовать базовой структуре, определенной в параграфе 3.2;

  3. определение и подробное описание каждого поля блока, включая флаги, если они используются;

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

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

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

Выделение новых кодов для параметров блоков SCTP (chunk parameter type code) осуществляется в соответствии с процедурой IETF Consensus, определенной в [RFC2434]. Документация для параметров блока должна включать:

  1. полное и сокращенное имя типа параметра;

  2. подробное описание структуры поля параметра, которое должно соответствовать базовому форматы TLV, определенному в параграфе 3.2.1;

  3. подробное описание каждой компоненты значения параметра;

  4. подробное описание предполагаемого использования этого типа параметра и возможности присутствия в одном блоке множества экземпляров данного параметра;

  5. каждый тип параметров должен быть уникальным для всех блоков.

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

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

  1. имя ошибки;

  2. подробное описание условий, при которых конечной точке SCTP следует генерировать блок ERROR (или ABORT) с этим кодом ошибки;

  3. ожидаемые действия конечной точки SCTP при получении блока ERROR (или ABORT) с этим кодом ошибки;

  4. подробное описание структуры и содержимого полей данных, сопровождающих этот код.

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

  • первые 2 байта содержат значение кода причины ошибки;

  • последние два байта указывают размер связанных с этим кодом параметров.

14.4. Идентификаторы протоколов (Payload)

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

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

14.5. Реестр номеров портов

Службы SCTP могут использовать контактные номера портов для предоставления услуг незнакомым абонентам, как это делается в TCP и UDP. Следовательно, у агентства IANA запрашивается открытие существующего реестра Port Numbers для протокола SCTP с использованием приведенных ниже правил, которые предполагается согласовать с существующими процедурами регистрации номеров портов. Назначенные IESG эксперты поддерживают запрос в IANA на выделение портов SCTP в соответствии с процедурами, описанными в [RFC2434].

Номера портов делятся на три основных группы — общеизвестные порты (Well Known Port) имспользуют номера от 0 до 1023, зарегистрированные порты (Registered Port) — от 1024 до 49151, а порты для динамического распределения и частного использования (Dynamic and/or Private Port) получают номера от 49152 до 65535. Общеизвестные и зарегистрированные порты предназначены для использования в серверных приложениях, где желательно иметь принятые по умолчанию точки контакта. В большинстве систем порты группы Well Known могут использоваться только системными (или root) процессами и программами, исполняемыми от имени привилегированных пользователей, а порты Registered могут использоваться обычными пользовательскими процессами и программами. Порты Dynamic и Private предназначены для временного использования (включая порты на клиентской стороне, согласованные по отдельным каналам порты и тестовые приложения до регистрации выделенных значений) и регистрировать их недопустимо.

Для реестра Port Numbers следует принимать запросы на регистрацию номеров из диапазонов Well Known и Registered. Такие номера портов не следует использовать без регистрации. Однако в некоторых случаях (например, при переносе приложений TCP на протокол SCTP) может оказаться разумным использование порта SCTP до завершения регистрации, но следует принимать во внимание, что IANA не гарантирует регистрацию конкретного номера порта. Следует начинать процедуру регистрации как можно раньше.

При каждой регистрации порта нужно представить перечисленные ниже сведения.

  • Краткое имя порта, состоящее целиком из букв (A-Z и a-z), цифр (0-9) и специальных символов «-_+./*» (без кавычек).

  • Запрашиваемый номер порта.

  • Краткое описание назначения порта на английском языке.

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

Лицам, выполняющим процедуру регистрации нужно следовать приведенным ниже рекомендациям.

  • Одно имя порта не следует регистрировать для нескольких номеров портов SCTP.

  • Имя, зарегистрированное для протокола TCP, можно регистрировать и для SCTP. При таких регистрациях следует использовать тот же номер порта, который уже выделен для TCP.

  • Конкретное назначение порта следует определять до начала регистрации. Например, не следует регистрировать используемые в TCP номера портов заранее с целью какого-либо использования их в SCTP.

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

         discard    9/sctp  Discard  # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com> 
                                     # [RFC4960]

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

         ftp-data  20/sctp  FTP      # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com> 
                                     # [RFC4960]

         ftp       21/sctp  FTP      # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com> 
                                     # [RFC4960]

            Порты переноса данных (20) и управления (21) для протокола FTP.

         ssh       22/sctp  SSH      # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com> 
                                     # [RFC4960]

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

         http      80/sctp  HTTP     # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com>
                                     # [RFC4960]

            Протокол «всемирной паутины» (HTTP) на основе SCTP.

         bgp      179/sctp  BGP      # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com>
                                     # [RFC4960]

            Протокол внешней маршрутизации (BGP) на основе SCTP.

         https    443/sctp  HTTPS    # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com>
                                     # [RFC4960]

            Защищенный протокол «всемирной паутины» (HTTP поверх TLS/SSL) на основе SCTP.

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

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

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

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

RTO.Max – 60 секунд

Max.Burst – 4

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 секунд

HB.Max.Burst – 1

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

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

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

Представленный в этом документе протокол является серьезным достижением, основанным на результатах работы авторов исходного RFC 2960 – Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.

Кроме того, следует отметить всех, кто внес вклад в создание исходного RFC – 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 и многие другие, кто дал свои значимые комментарии.

Дабавим в этот список автором рекомендаций для разработчиков SCTP – I. Arias-Rodriguez, K. Poon, A. Caro и M. Tuexen.

Отметим усилия участников всех семи проверок интероперабельности SCTP и тех, кто представил комментарии к RFC 4460, как отмечено в этом документе – Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani и Ronnie Sellar.

Отдельная благодарность Mark Allman, который реально должен был стать соавтором работы по max-burst, но сумел уклониться по причине занятости. Благодарим также Lyndon Ong и Phil Conrad за их полезный вклад в работу.

Отметим также комментарии к заключительной версии документа от Alfred Hoenes и Ronnie Sellars.

Благодарность в адрес участников кодирования, тестирования и обновления документа непросто выразить словами. Спасибо Вам!

Randall Stewart — редактор.

Приложение A. Явное уведомление о перегрузке

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

 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

[RFC3168] описывает согласование 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

В соответствии с [RFC3168] получатель пакета устанавливает в передаваемом подтверждении специальный бит, который уведомляет отправителя CE20 о получении информации. Для 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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

Приложение B. Расчет контрольной суммы CRC32c

Мы определяем «отраженное значение», как значение с порядком битов, обратным по отношению к используемому в машине. 32-битовое значение CRC22 рассчитывается, как описано для CRC32c и использует полиномиальный код 0x11EDC6F41 (Castagnoli93) или x32+x28+x27+x26+x25+x23+x22+x20+x19+x18+x14+x13+x11+x10+x9+x8+x6+x0. Значение CRC рассчитывается с помощью процедуры, похожей на ETHERNET CRC [ITU32], которая изменена с учетом применения на транспортном уровне.

Расчет CRC использует полиномиальное деление. Битовая строка сообщения (M) преобразуется в полином M(X) и значение CRC рассчитывается по M(X) с использованием полиномиальной арифметики.

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

Следовательно, требуется соглашение для отображения транспортных сообщений SCTP на полиномы с целью расчета CRC. При отображении сообщений SCTP на полиномы сначала берется старший байт, но в каждом байте биты берутся, начиная с младшего. Первый байт сообщения обеспечивает восемь старших коэффициентов. В каждом байте младший бит SCTP дает самый старший коэффициент полинома в рамках данного байта, а старший бит SCTP — младший коэффициент в рамках байта (такой порядок иногда называют отраженным — mirrored или reflected [WILLIAMS93]). Полиномы CRC преобразуются обратно в значения байтов транспортного уровня SCTP с помощью соответствующего отображения.

Значение CRC для транспортного уровня SCTP следует рассчитывать в соответствии с приведенным ниже описанием.

  • Входными данными CRC является поток байтов с номерами 0 – N-1.

  • Байтовый поток транспортного уровня отображается на полиномиальное значение. PDU размером N байтов с номерами j от 0 до N-1 рассматривается, как коэффициенты полинома M(x) порядка 8N-1 и бит 0 байта j будет коэффициентом x(8(N-j)-8), а бит 7 этого байта — x(8(N-j)-1).

  • Оставшаяся часть регистра CRC заполняется единицами и рассчитывается значение CRC с помощью умножения на x32 и деления на полином CRC.

  • Полином умножается на x32 и делится на G(x), что порождает полином степени не более 31, образующий оставшуюся часть R(x).

  • Коэффициенты R(x) рассматриваются, как 32-битовая последовательность.

  • Последовательность битов дополняется и результат является полиномом CRC.

  • Полином CRC отображается обратно на байты транспортного уровня SCTP. Коэффициент x31 дает значение биты 7 в байте SCTP 0, а коэффициент x24 дает значение бита 0 в байте 0. Коэффициент x7 дает значение бита 7 в байте 3, а коэффициент x0 — значение бита 0 в байте 3. Результирующая 4-байтовая последовательность является последовательностью транспортного уровня для 32-битовой контрольной суммы SCTP.

Примечание для разработчиков. В стандартах, книгах и литературе от производителей для CRC зачастую приводятся иные формулировки, где используется регистр для хранения остатка алгоритма деления long-division, инициализируемый нулями, а не 1 и первые 32 бита сообщения дополняются. Алгоритм long-division, используемый в нашей формулировке совмещает начальное умножение на 232 и «длинное деление» в одной операции. Для таких алгоритмов и сообщений, размер которых превышает 64 бита, две спецификации полностью эквивалентны. Обеспечение эквивалентности является одной из целей данного документа.

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

Можно несколько снизить вычислительные издержки, проверяя ассоциацию по значению Verification Tag до расчета контрольной суммы, чтобы не рассчитывать контрольные суммы для пакетов с некорректными тегами. Исключением из этого правила являются блоки INIT и некоторые обмены SHUTDOWN-COMPLETE, а также устаревшие блоки COOKIE ECHO. Однако в этих случаях пакеты достаточно малы и расчет контрольных сумм не требует значительных ресурсов.

Приложение C. Обработка ICMP

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

  1. Реализация может игнорировать все сообщения ICMPv4, где поле типа отлично от Destination Unreachable.

  2. Реализация может игнорировать все сообщения ICMPv6, где поле типа отлично от Destination Unreachable, Parameter Problem, и Packet Too Big.

  3. Реализация может игнорировать все сообщения ICMPv4, где код отличается от Protocol Unreachable и Fragmentation Needed.

  4. Реализация может игнорировать все сообщения ICMPv6 типа Parameter Problem, если код отличен от Unrecognized Next Header Type Encountered.

  5. Реализация должна использовать данные из сообщений ICMP (v4 или v6) для определения ассоциации, отправившей сообщение, в ответ на которое получен отклик ICMP. Если такой ассоциации не найдено, сообщение ICMP следует игнорировать.

  6. Реализация должна удостовериться, что значение Verification Tag в сообщении ICMP соответствует верификационному тегу партнера. Если значение Verification отлично от нуля и не совпадает с тегом партнера, сообщение ICMP отбрасывается. Если тег имеет значение 0 и сообщение ICMP содержит достаточно байтов для проверки того, что блок имел тип INIT и значение Initiate Tag соответствует тегу партнера, выполняется п. ICMP7. Если сообщение ICMP слишком коротко, тип блока иной или значение Initiate Tag не совпадает, пакет отбрасывается без уведомления.

  7. Если сообщение ICMP является v6 Packet Too Big или v4 Fragmentation Needed, реализация может обработать информацию, как указано для определения PATH MTU.

  8. Если код ICMP указывает Unrecognized Next Header Type Encountered или Protocol Unreachable, реализация должна трактовать такое сообщение, как разрыв ассоциации с установленным флагом T, если оно не содержит блок INIT. Если блок INIT включен и ассоциация находится в состоянии COOKIE-WAIT, сообщение ICMP обрабатывается подобно блоку ABORT.

  9. Если сообщение ICMPv6 имеет код Destination Unreachable, реализация может пометить адресата, как недоступного, а также увеличить значение счетчика ошибок для пути.

Отметим, что эти процедуры отличаются от [RFC1122] и приведенных там требований к обработке сообщений о недоступности порта, а также требования о том, что реализация должна прерывать ассоциацию в ответ на сообщение о недоступности протокола (protocol unreachable). Сообщения о недоступности портов не обрабатываются, поскольку реализации будут передавать блок ABORT, а не сообщение о недоступности порта. Более строгая обработка сообщений о недоступности протокола обусловлена вопросами защиты для хостов, не поддерживающих SCTP.

Ниже приведен (ненормативный) пример кода, заимствованный из генератора CRC с открытым кодом [WILLIAMS93], использующего метод «отражения» и таблицу для SCTP CRC32c с 256 записями по 32 бита в каждой. Этот метод не слишком быстрый и не слишком медленный по сравнению с поиском в таблицах CRC, но его преиуществом является возможность работы с процессами, использующими порядок big-endian и little-endian, при просмотре общих таблиц (с хост-порядком), а также использование лишь предопределенных операций ntohl() и htonl(). Код несколько отличается от [WILLIAMS93] для обеспечения переносимости между архитектурами big-endian и little-endian (отметим, что в тех случаях, когда известно, что целевая архитектура использует порядок little-endian, финальные операции bit-reversal и byte-reversal могут быть объединены).

   /*************************************************************/
   /* Для генератора таблиц Ross Williams устанавливаются       */
   /* значения TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE   */
   /* Для прямого расчета Mr. Williams используются значения    */
   /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,      */
   /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000        */
   /*************************************************************/

   /* Пример файла с таблицей crc */
   #ifndef __crc32cr_table_h__
   #define __crc32cr_table_h__

   #define CRC32C_POLY 0x1EDC6F41
   #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])

   unsigned long  crc_c[256] =
   {
   0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
   0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
   0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
   0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
   0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
   0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
   0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
   0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
   0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
   0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
   0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
   0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
   0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
   0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
   0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
   0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
   0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
   0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
   0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
   0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
   0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
   0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
   0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
   0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
   0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
   0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
   0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
   0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
   0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
   0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
   0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,
   0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
   0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
   0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
   0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
   0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
   0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
   0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
   0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
   0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
   0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
   0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
   0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
   0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
   0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
   0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
   0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
   0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
   0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
   0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
   0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
   0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
   0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
   0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
   0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
   0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
   0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
   0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
   0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
   0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
   0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
   0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
   0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
   0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
   };

   #endif

    /* Пример программы построения таблицы */

   #include <stdio.h>
   #include <stdlib.h>

   #define OUTPUT_FILE   "crc32cr.h"
   #define CRC32C_POLY    0x1EDC6F41L
   FILE *tf;
   unsigned long
   reflect_32 (unsigned long b)
   {
     int i;
     unsigned long rw = 0L;

     for (i = 0; i < 32; i++){
         if (b & 1)
           rw |= 1 << (31 - i);
         b >>= 1;
     }
     return (rw);
   }

   unsigned long
   build_crc_table (int index)
   {
     int i;
     unsigned long rb;

     rb = reflect_32 (index);

     for (i = 0; i < 8; i++){
         if (rb & 0x80000000L)
          rb = (rb << 1) ^ CRC32C_POLY;
         else
          rb <<= 1;
     }
     return (reflect_32 (rb));
   }

   main ()
   {
     int i;

     printf ("\nGenerating CRC-32c table file <%s>\n",
     OUTPUT_FILE);
     if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
         printf ("Unable to open %s\n", OUTPUT_FILE);
         exit (1);
     }
     fprintf (tf, "#ifndef __crc32cr_table_h__\n");
     fprintf (tf, "#define __crc32cr_table_h__\n\n");
     fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
     CRC32C_POLY);
     fprintf (tf,
     "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
     fprintf (tf, "\nunsigned long  crc_c[256] =\n{\n");
     for (i = 0; i < 256; i++){
         fprintf (tf, "0x%08lXL, ", build_crc_table (i));
         if ((i & 3) == 3)
           fprintf (tf, "\n");
     }
     fprintf (tf, "};\n\n#endif\n");

     if (fclose (tf) != 0)
       printf ("Unable to close <%s>." OUTPUT_FILE);
     else
       printf ("\nThe CRC-32c table has been written to <%s>.\n",
         OUTPUT_FILE);
   }

   /* Пример вставки crc */

   #include "crc32cr.h"

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = ~0L;
     unsigned long result;
     unsigned char byte0,byte1,byte2,byte3;

     for (i = 0; i < length; i++){
         CRC32C(crc32, buffer[i]);
     }

     result = ~crc32;

     /*  в result храниться «негативный» остаток полинома,
      *  поскольку таблица и алгоритм являются «зеркальными [williams95].
      *  Т. е., result имеет такое же значение, как будто мы отобразили сообщение
      *  на полином, рассчитали остаток полинома для хостового порядка битов
      *  выполнили финальныю смену знака (negation) и сквозное обращение битов.
      *  Отметим, что 32-битовое обращение битов идентично 4 восьмибитовым обращениям 
      *  с последующим обращением порядка байтов. На машинах little-endian 
      *  такое обращение байтов и финальная операция ntohl cancel не нужны.
      */

     byte0 = result & 0xff;
     byte1 = (result>>8) & 0xff;
     byte2 = (result>>16) & 0xff;
     byte3 = (result>>24) & 0xff;
     crc32 = ((byte0 << 24) |
              (byte1 << 16) |
              (byte2 << 8)  |
              byte3);
     return ( crc32 );
   }

   int
   insert_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned long crc32;
     message = (SCTP_message *) buffer;
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     /* and insert it into the message */
     message->common_header.checksum = htonl(crc32);
     return 1;
   }

   int
   validate_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned int i;
     unsigned long original_crc32;
     unsigned long crc32 = ~0L;

     /* save and zero checksum */
     message = (SCTP_message *) buffer;
     original_crc32 = ntohl(message->common_header.checksum);
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     return ((original_crc32 == crc32)? 1 : -1);
   }

Литература

Нормативные документы

[ITU32] “ITU-T Recommendation V.42, “Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion”.”, ITU-T section 8.1.1.6.2.

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, August 1980.

[RFC0793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, October 1989.

[RFC1123] Braden, R., Ed., “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.

[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.

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

[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.

[RFC3873] Pastor, J. and M. Belinchon, “Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)”, RFC 3873, September 2004.

[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, February 2006.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, December 2005.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, December 2005.

[RFC4306] Kaufman, C., Ed., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, March 2007.

Дополнительная литература

[FALL96] Fall, K. and S. Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”, SIGCOMM’99 V. 26 N. 3 pp 5-21, July 1996.

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

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

[WILLIAMS93] Williams, R., “A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS”, Internet publication, http://www.geocities.com/SiliconValley/Pines/8659/crc.htm, August 1993.

[RFC0813] Clark, D., “Window and Acknowledgement Strategy in TCP”, RFC 813, July 1982.

[RFC1858] Ziemba, G., Reed, D., and P. Traina, “Security Considerations for IP Fragment Filtering”, RFC 1858, October 1995.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, RFC 2104, February 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.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol”, RFC 2960, October 2000.

[RFC3309] Stone, J., Stewart, R., and D. Otis, “Stream Control Transmission Protocol (SCTP) Checksum Change”, RFC 3309, September 2002.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, September 2001.

[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, June 2005.

[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, “Stream Control Transmission Protocol (SCTP) Specification Errata and Issues”, RFC 4460, April 2006.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, “Authenticated Chunks for Stream Control Transmission Protocol (SCTP)”, RFC 4895, August 2007.


Адрес редактора

Randall R. Stewart

4875 Forest Drive

Suite 200

Columbia, SC 29206

US

EMail: rrs@cisco.com

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

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

nmalykh@gmail.com

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

Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

1Silly window syndrome — синдром неразумного окна.

2Advertised Receiver Window Credit — анонсированное окно приема.

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

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

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

6Path MTU.

7Receiver advertised window size.

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

9Slow-start threshold.

10Highest TSN Newly Acknowledged — максимальный недавно подтвержденный номер.

11Maximum transmission unit.

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

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

14Heartbeat period.

15Out of the blue — совершенно неожиданный.

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

17SCTP Authentication — аутентификация SCTP.

18Encapsulating Security Payload.

19Internet Key Exchange.

20Congestion Experienced.

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

22Cyclic Redundancy Check.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

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

Or