1

RFC 8303 On the Usage of Transport Features Provided by IETF Transport Protocols

Internet Engineering Task Force (IETF)                          M. Welzl
Request for Comments: 8303                            University of Oslo
Category: Informational                                        M. Tuexen
ISSN: 2070-1721                         Muenster Univ. of Appl. Sciences
                                                              N. Khademi
                                                      University of Oslo
                                                           February 2018

On the Usage of Transport Features Provided by IETF Transport Protocols

Использование транспортных свойств, предоставляемых транспортными протоколами IETF

PDF

Аннотация

В этом документе описано, как транспортные протоколы TCP1, MPTCP2, SCTP3, UDP4 и UDP-Lite5 раскрывают свои услуги приложениям и как приложение может настроить и использовать функции, составляющие эти услуги. Рассматриваются также услуги, предоставляемые механизмом контроля перегрузок LEDBAT6. Описание задает набор транспортных абстракций, которые можно экспортировать в API транспортных служб (TAPS).

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IETF7 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG8. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8303.

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

Copyright (c) 2018. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

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

Процесс разработки начался с обзора услуг, предоставляемых транспортными протоколами IETF и механизмами контроля перегрузок [RFC8095]. Данный документ вместе с [RFC8304] дополняют указанный обзор подробным описанием взаимодействия приложений с транспортными протоколами TCP, MPTCP, SCTP, UDP и UDP-Lite. Определены также примитивы для включения, выключения и настройки механизма контроля перегрузок для индивидуального (unicast) трафика LEDBAT. Для UDP и UDP-Lite первым шагом анализа служит обсуждение текста связанных с ними RFC, приведенное в [RFC8304].

Это «временной срез» транспортных протоколов IETF опубликован как RFC для документирования анализа авторами и членами рабочей группы TAPS. Он содержит набор транспортных абстракций, которые можно экспортировать в TAPS API. Документ обеспечивает базу для определения минимального набора транспортных служб, которые следует реализовать конечной системе, поддерживающей TAPS [TAPS-MINSET].

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

Те части протоколов, которые явно означены необязательными, не рассматриваются здесь. Не обсуждаются также взаимодействия между приложением и транспортным протоколом, не связанные напрямую с работой протокола. Например, приложение может разными способами использовать опции сокета для индикации своей заинтересованности в получении тех или иных уведомлений [RFC6458]. Однако для идентификации примитивов, событий и транспортных функций способность включать и отключать получение уведомлений интереса не представляет. Точно так же, сокеты в форме «один со многими» [RFC6458] просто влияют на стиль программирования приложений и не рассматриваются здесь. То же самое относится и к способности получить неизменное значение параметра, ранее установленного приложением (например, с помощью операции get [RFC6458]).

Этот документ представляет трехэтапный процесс получения списка транспортных функций. На первом этапе обсуждается текст соответствующих RFC по протоколам. На втором этапе предыдущее обсуждение служит для выведения списка примитивов и событий, которые единообразно классифицируются по протоколам. Здесь предпринята попытка представить или (при отсутствии теста, представляющего примитивы и события) сконструировать примитивы и события в несколько обобщенной форме для выделений сходства. Это достигается, например, переименованием протокольных примитивов и событий или исключения строго сопоставления (1:1) между примитивами и событиями в спецификации протокола и списке. Финальный этап 3 представляет транспортные функции (свойства) на основе этапа 2, указывая реализующие их протоколы.

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

Некоторые протоколы ориентированы на соединения и в них часто применяется начальный вызов определенного примитива для организации соединения до начала обмена данными и требуется явный разрыв соединения путем вызова другого примитива (обычно он называется Close). Соединение – это общее состояние, к которому относятся некоторые транспортные примитивы, например, настройка общих параметров конфигурации. Организация, поддержка и разрыв соединений поэтому служат для классификации транспортных примитивов ориентированных на соединения протоколов на этапах 2 и 3. Поэтому предполагается, что UDP используется с «подключенными» сокетами, т. е. сокетами, которые привязаны к конкретной паре адресов и портов [RFC8304].

2. Терминология

Transport Feature – транспортная функция (свойство)

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

Transport Service – транспортный сервис (служба)

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

Transport Protocol – транспортный протокол

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

Transport Protocol Component – компонент транспортного протокола

Реализация транспортной функции в протоколе.

Transport Service Instance – экземпляр транспортного сервиса

Набор транспортных протоколов и выбранными свойствами и параметрами конфигурации, реализующий один транспортный сервис, например, стек протоколов RTP на основе UDP.

Application – приложение

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

End точка – конечная точка

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

Connection – соединение

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

Primitive – примитив

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

Event – событие

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

Parameter – параметр

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

Socket – сокет

Комбинация IP-адреса и номера порта у получателя.

Transport Address – транспортный адрес

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

3. Этап 1

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

3.1. Примитивы, предоставляемые TCP

В исходной спецификации TCP [RFC0793] сказано:

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

В параграфе 3.8 [RFC0793] определено взаимодействие с приложением через несколько транспортных примитивов. Предполагается также, что операционная система обеспечивает для TCP возможности асинхронной передачи сигналов приложению. Примитивы, представляющие такие сигналы, в этом разделе называются событиями (event).

Open

Вызов может быть активным для организации соединения или пассивным для прослушивания входящих вызовов. Все другие примитивы связаны с конкретным соединением, которое предполагается созданным заранее. Активный вызов open содержит сокет, пассивный вызов с сокетом ожидает входящего соединения. Возможно при пассивном вызове не задавать сокет для восприятия любых входящих соединений. Полностью заданный пассивный вызов можно перевести в активное состояние с помощью Send. Можно при желании указать тайм-аут, по истечении которого TCP будет разрывать соединение, если через него получателю не были доставлены данные (если тайм-аут не задан, используется принятый по умолчанию). Процедура разрыва соединения служит для предотвращения избыточных повторов передачи и приложение может контролировать порог, определяющий условия разрыва. Порог может указываться временем ожидания или числом повторов передачи [RFC1122]. Тайм-аут также можно указать числом повторов.

Для многодомных хостов можно указать локальный адрес IP [RFC1122]. Если адрес не задан, при активном вызове будет использован принятый по умолчанию. Пассивный вызов будет ждать входящих соединений по всем локальным адресам и использовать адрес IP, на который поступил вызов. Параметр options позволяет приложению указать опции IP, такие как Source Route, Record Route, Timestamp [RFC1122]. Не указано, к каким сегментам соединения этот параметр следует применять (вероятно, ко всем, поскольку это задано для опции IP Source Route в параграфе 4.2.3.8 в [RFC1122]). Опция Source Route является единственной опцией IP в этом параметре, которая не указана не обязательной (non-optional), и позволяет приложению указать заданный отправителем маршрут при активной организации соединения TCP.

Кортежи первичных ключей (Master Key Tuple или MKT) для аутентификации можно задать при вызове Open (параграф 7.1 в [RFC5925]). При использовании аутентификации защищаются полные сегменты TCP, включая псевдозаголовок IPv4, заголовок и данные TCP.

TCP Fast Open (TFO) [RFC7413] позволяет приложению незамедлительно передать сообщение при активном вызове open на пассивную сторону соединения TCP вместе с первым пакетом организации соединения (SYN). Это может быть полезно для приложений, чувствительных к задержке при организации соединения TCP. В [RFC7413] сказано: «реализациям TCP недопустимо использовать TFO по умолчанию и можно применять TFO лишь при явном запросе приложения или настройке на уровне сервисного порта». Размер сообщения, передаваемого с TFO, не может быть больше максимального сегмента TCP (за вычетом опций, применяемых в SYN). Для активной стороны рекомендуется изменить или заменить вызов () для поддержки аргумента, задающего пользовательский буфер [RFC7413]. Для пассивной стороны приложение должно включить прием запросов Fast Open, например, через новую опцию сокета TCP_FASTOPEN setsockopt() перед listen(). Принимающее приложение должно быть готово воспринимать дубликаты сообщения TFO, поскольку первые данные, записанные в сокет, могут доставляться приложению на удаленном хосте в нескольких экземплярах.

Send

Этот примитив приложение использует для передачи локальной транспортной конечной точке TCP числа байтов, которые протоколу TCP нужно гарантированно передать на другую сторону соединения. Флаг важности (urgent) при его установке говорит, что данные этого вызова являются срочными (важными) и эту важность следует указать принимающему процессу, если он еще не воспринял всех полученных данных без такого флага. Необязательный параметр может задавать тайм-аут для соединения (см. Open). Кроме того, необязательные параметры позволяют указать предпочтительный исходящий MKT (current_key) и/или предпочтительный входящий MKT (rnext_key) для соединения (параграф 7.1 в [RFC5925]).

Receive

Этот примитив выделяет приемный буфер для представленного числа байтов. Примитив возвращает число принятых байтов, сообщенное буфером, когда они были приняты и записаны в буфер протоколом TCP. Приложение информируется о важных данных через флаг urgent, устанавливаемый при получении важных (срочных) данных. Сброшенный флаг говорит об отсутствии важных данных, т. е. они не были получены или данный вызов Receive вернул все срочные данные. Приложению также сообщается current_key и rnext_key из недавно принятого сегмента через необязательный параметр (параграф 7.1 в [RFC5925]).

Close

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

Abort

Этот примитив прерывает все ожидающие Send и Receive. Конечной точке TCP на другой стороне соединения передается сообщение TCP RESET [RFC0793].

Событие Close

TCP использует этот примитив для информирования приложения о вызове примитива Close приложением на удаленной стороне, чтобы локальное приложение также могло применить Close и аккуратно завершить соединение (параграф 3.5 в [RFC0793]).

Событие Abort

Когда TCP получает от партнера RESET, протокол: «уведомляет пользователя, и переходит в состояние CLOSED» (параграф 3.4 в [RFC0793]).

Событие User Timeout

Это событие выполняется при достижении заданного пользователем времени ожидания (параграф 3.9 в [RFC0793]), см. Open. Очищаются все очереди и приложение информируется о разрыве соединения по тайм-ауту.

Событие Error_Report

Это событие информирует приложение о «мягкой ошибке» (soft error), которую можно игнорировать [RFC5461], включая прием сообщения ICMP об ошибке или избыточные повторы (порог, который ниже порога прерывания), см. параграф 4.2.4.1 в [RFC1122].

Type-of-Service

В параграфе 4.2.4.2 [RFC1122] сказано: «Прикладному уровню должна быть обеспечена возможность задавать тип обслуживания TOS для сегментов, передаваемых через соединение». Приложению следует поддерживать возможность смены TOS в течение срока действия соединения и значение TOS следует без изменений передавать на уровень IP. Позднее поле TOS было переопределено и модель дифференцированного обслуживания (Differentiated Services или Diffserv) [RFC2475] [RFC3260] заменила это поле в заголовке IP, назначив 6 старших битов для передачи кода DSCP (Differentiated Services Code Point) [RFC2474].

Nagle

Алгоритм Nagle на некоторое время задерживает передачу данных для увеличения вероятности отправки полноразмерного сегмента (параграф 4.2.3.4 в [RFC1122]). Приложение может отключить алгоритм Nagle для отдельного соединения.

User Timeout Option

Опция пользовательского тайм-аута (User Timeout Option или UTO) [RFC5482] позволяет одной стороне соединения TCP аносировать свое значение заданного пользователем времени ожидания, чтобы друга сторона могла соответственно скорректировать свое значение. В дополнение к настройке тайм-аута (см. Send) имеется 3 переменных состояния на уровне соединения, которые приложение может настроить для работы UTO – adv_uto задает значение UTO, анонсируемое удаленному партнеру TCP (по умолчанию системное значение пользовательского тайм-аута), флаг enabled (по умолчанию false) для включения и отключения UTO на соединении и флаг changeable (по умолчанию true), определяющий возможность смены тайм-аута на основании опции UTO, полученной от удаленного партнера. Первые 2 переменных работают для приема и передачи, changeable принимает значение false, когда приложение явно задает пользовательский тайм-аут (см. Send).

Set/Get Authentication Parameters

Предпочтительный исходящий кортеж MKT (current_key) и/или предпочтительный входящий MKT (rnext_key) можно настроить для соединения. Можно извлечь информацию о текущих значениях current_key и rnext_key из последнего принятого сегмента (параграф 7.1 в [RFC5925]).

3.1.1. Исключенные примитивы и параметры

Примитиву Open можно передать информацию о предпочтении или защите (разделении – compartment) [RFC0793], но это не рассматривается здесь, поскольку в настоящее время в основно неактуально [RFC7414].

Примитив Status не включен в документ, поскольку в исходной спецификации TCP он указан как «зависящий от реализации» и сказано, что он: «может быть исключен без негативного влияния» [RFC0793]. Более того, хотя описан блок данных, содержащий конкретную информацию, сказано, что вся эта информация может быть доступна не всегда. Хотя в [RFC5925] сказано: «STATUS следует дополнить для обеспечения возможности читать MKT текущего или ожидающего соединения (для подтверждения)», та же самая информация доступна через примитив Receive, который в соответствии с [RFC5925] «должен быть дополнен» этой функциональностью. Примитив Send включает необязательный флаг push, установка которого требует немедленной передачи данных получателю [RFC0793]. Описанный там же примитив Receive может (в некоторых обстоятельствах) устанавливать флаг push. Поскольку функциональность push необязательная для примитивов Send и Receive [RFC1122], она не рассматривается здесь. В [RFC1122] введены сообщения keep-alive для TCP, но они не обязательны для реализации и не включены в документ. Там же сказано: «Некоторые реализации TCP включают вызовы FLUSH», что говорит о необязательности данного вызова и он не рассматривается здесь.

3.2. Примитивы, предоставляемые MPTCP

MPTCP является расширением TCP, позволяющим применять несколько путей для одного потока данных. Это достигается созданием так называемых субпотоков TCP для каждого из интерфейсов и планированием трафика через эти субпотоки. Сервис, предоставляемый MPTCP описан в [RFC6182]:

Протокол Multipath TCP должен следовать модели сервиса, используемой TCP [1] – упорядоченная, надежная, ориентированная на байты доставка. Кроме того, соединению Multipath TCP следует предоставлять приложению пропускную способность не хуже ожидаемой при работе через одно соединение TCP по любому из доступных путей.

Кроме того, имеются некоторые ограничения на API, раскрываемый MPTCP, как отмечено в [RFC6182]:

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

Таким образом, предоставляемые MPTCP примитивы эквивалентны примитивам TCP. Тем не менее, в MPTCP RFC [RFC6824] и [RFC6897] разъяснены некоторые детали примитивов TCP в отношении MPTCP и добавлены расширения для лучшего управления субпотоками MPTCP. Ниже приведен список уточнений и расширений, которые упомянутые RFC содержат для примитивов TCP.

Open

«Приложению следует иметь возможность включать и выключать применение MPTCP» [RFC6897]. Эта функциональность может быть обеспечена опцией сокета tcp_multipath_enable. Кроме того протокол MPTCP должен отключаться, если приложение привязано к конкретному адресу [RFC6897].

Send/Receive

Передача и прием данных не требуют менять приложение для использования MPTCP [RFC6824]. Уровень MPTCP принимает от приложения один поток данных и делит его на субпотоки с достаточным объемом данных управления, позволяющих гарантированно доставить данные с сохранением порядка и собрать их на приемной стороне.

Использование указателя важности (Urgent Pointer) отличается MPTCP и в [RFC6824] сказано: «Субпотоку TCP недопустимо использовать Urgent Pointer для прерывания имеющегося сопоставления».

Управление адресами и субпотоками

MPTCP использует разные адреса и позволяет хосту анонсировать их как часть протокола. В [RFC6897] сказано: «Приложению следует обеспечивать возможность ограничить MPTCP привязкой к данному набору адресов», что позволяет приложению указать ограниченный набор адресов для использования протоколом MPTCP. Там же сказано: «Приложению следует иметь возможность получить список пар адресов, используемых субпотоками MPTCP».

3.3. Примитивы, предоставляемые SCTP

TCP имеет множество ограничений, которые устранены в SCTP (параграф 1.1 в [RFC4960]). Три снятых ограничения напрямую отражаются в транспортных возможностях, которые видит использующее SCTP приложение – 1) возможность сохранить разграничители сообщений, 2) отсутствие гарантий доставки и сохранения порядка без запроса приложения, 3) поддержка многодомности. В SCTP соединения называются ассоциациями (association) и могут создаваться не только между парой (как в TCP), но и между множеством адресов на каждой конечной точке.

Раздел 10 базовой спецификации SCTP [RFC4960] задает взаимодействие с приложением, которое в SCTP называется протоколом вышележащего уровня (Upper-Layer Protocol или ULP). Предполагается, что операционная система обеспечивает SCTP возможность асинхронной передачи сигналов приложению, примитивы такой сигнализации называются здесь событиями (event) и описаны ниже. В дополнение к абстрактному API, заданному в разделе 10 [RFC4960], были описаны расширения для API сокетов [RFC6458], включающие функциональность базового протокола [RFC4960] и некоторые расширения [RFC3758] [RFC4895] [RFC5061]. Для других расширений протокола ([RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829] [RFC8260]) соответствующие расширения API сокетов описаны в спецификациях. Функциональность, раскрываемая ULP через все эти API описана здесь.

Абстрактный API содержит примитив SetProtocolParameters, позволяющий настраивать элементы списка параметров [RFC4960]. В спецификации протокола сказано: «Реализация SCTP может разрешать ULP изменение некоторых параметров протокола». Это указывает, что ни один из элементов этого списка параметров не является обязательным для настройки ULP. Поэтому здесь рассматриваются лишь параметры в абстрактном API, которые также указаны в одном из других RFC, упомянутых выше, что привело к исключению параметров RTO.Alpha, RTO.Beta, HB.Max.Burst. Для четкости сам примитив SetProtocolParameters здесь заменен примитивами настройки параметров или групп параметров.

Initialize

Примитив Initialize создает локальный экземпляр SCTP, связывая его с набором локальных адресов и номером порта (если он задан) [RFC4960]. Примитив нужно вызывать лишь один раз для набора локальных адресов. При создании ассоциации может использоваться множество параметров для нее, это нужно сделать до соединения (с помощью описанного ниже примитива Associate). Можно указать максимальное число входных потоков, которые приложение готово поддерживать, максимальное число попыток передачи INIT (первое сообщение при создании ассоциации) и максимальный тайм-аут повторной передачи (maximum retransmission timeout – RTO) для попыток INIT [RFC6458]. С этого момента (до соединения) приложение может также включить инкапсуляцию UDP путем настройки номера удаленного порта для нее [RFC6951].

Associate

Создает ассоциацию (эквивалент SCTP для соединения), связывающую локальный и удаленный экземпляр SCTP. Для идентификации удаленной конечной точки можно ей может быть назначен один или несколько (с помощью connectx) сокетов (параграф 9.9 в [RFC6458]). Большинство примитивов связано с конкретной ассоциацией, которая предполагается созданной первой. Associate может возвращать список транспортных адресов получателя, что позволяет использовать затем множество путей. Один из возвращенных сокетов выбирается локальной конечной точкой как используемый по умолчанию основной путь для передачи партнеру пакетов SCTP, но этот выбор приложение может изменить, используя список адресов получателя. Associate также получает число исходящих потоков для запроса и может возвращать число согласованных исходящих потоков. Может быть представлен необязательный 32-битовый параметр индикации уровня адаптации [RFC5061]. При использовании аутентифицированных блоков (chunk) могут быть представлены типы блоков, которые требуется передавать с проверкой подлинности [RFC4895]. Уведомление SCTP_Cant_Str_Assoc служит для информирования приложения об отказе при создании ассоциации [RFC6458]. Приложение может использовать sendto() или sendmsg() для неявного создания ассоциации, передавая тем самым сообщение, что SCTP может передавать на этапе создания ассоциации [RFC6458]. Отметим, что этот механизм отличается от TCP TFO и сообщение будет приходить лишь один раз по истечении по меньшей мере одного интервала RTT, поскольку передается вместе с третьим сообщением организации ассоциации (блок COOKIE-ECHO).

Send

Примитив передает через ассоциацию сообщение с неким числом байтов. Сообщению может быть назначен номер для последующего обращения к корректному сообщению при возникновении ошибки, а также предоставляется идентификатор для указания потока, используемого внутри ассоциации (этот параметр для простоты считается обязательным, а при его отсутствии просто используется 0). Могут быть заданы условия отказа от сообщения (например, ограничение числа повторных попыток передачи или срока действия пользовательского сообщения). Это позволяет управлять расширением частичных гарантий [RFC3758] [RFC7496]. Необязательный срок действия сообщения позволяет отбросить устаревшее сообщение без его отправки. Можно указать предпочтительный путь (выбор его не гарантирован) путем задания сокета, а также возможность неупорядоченной доставки с помощью флага unordered. Рекомендательный флаг указывает, что партнеру не следует задерживать подтверждение пользовательского сообщения [RFC7053], а другой рекомендательный флаг управляет предпочтениями приложения в части группировки данных пользователя с другими исходящими блоками DATA в один пакет. Идентификатор протокола для данных (payload) может предоставляться для партнеру передачи значения, указывающего тип данных. При использовании аутентификации блоков может предоставляться идентификатор ключа для проверки подлинности блоков DATA [RFC4895].

Receive

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

Shutdown

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

Abort

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

Change Heartbeat/Request Heartbeat

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

Configure Max. Retransmissions of an Association

Параметр Association.Max.Retrans [RFC4960] (sasoc_maxrxt расширении API сокетов [RFC6458]) позволяет задать число неудачных повторов, после которого принимается решение об отказе ассоциации в целом, кода следует вызывать уведомление Communication Lost.

Set Primary

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

Change Local Address/Set Peer Primary

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

Configure Path Switchover

Этот абстрактный API содержит примитив Set Failure Threshold [RFC4960], задающий параметр Path.Max.Retrans, который определяет число повторов, после которого определенный транспортный адрес считается недоступным. Если в ассоциации еще остаются транспортные адреса, достижение этого предела ведет к переключению пути. Расширение SCTP-PF добавляет в этот метод концепцию «ненадежных путей» (Potentially Failed или PF) [RFC7829]. SCTP не отказывается полностью от передачи по путям со статусом PF, но будет предпочитать другие активные пути, если они доступны. Переход в состояние PF происходит при превышении заданного максимума повторов передачи. Таким образом, для всех путей, гже применяется этот механизм, имеется два настраиваемых порога ошибок, один из которых определяет переход в состояние PF, а другой – принятие решения о недоступности адреса.

Set/Get Authentication Parameters

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

Add/Reset Streams, Reset Association

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

Status

Примитив возвращает блок данных с информацией об указанной ассоциации, списком транспортных адресов получателей, состояниях доступности этих транспортных адресов, текущих размерах локального и удаленного окна, текущем размере локального окна перегрузок, числе неподтвержденных блоков DATA; основном пути, последнем сглаженном времени кругового обхода (Smoothed Round-Trip Time или SRTT) на основном пути, RTO на основном пути, SRTT и RTO для других адресов получателя [RFC4960] и MTU на путях [RFC6458].

Enable/Disable Interleaving

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

Set Stream Scheduler

Позволяет выбрать планировщик потоков для ассоциации из числа First-Come-First-Served (обслуживание в порядке очередности поступления), Round-Robin (циклический перебор), Round-Robin per Packet (циклический перебор на уровне пакетов), Priority-Based (по приоритету), Fair Bandwidth (беспристрастное распределение пропускной способности, Weighted Fair Queuing (взвешенная беспристрастная очередь) [RFC8260].

Configure Stream Scheduler

Позволяет менять параметры планировщика на уровне потока – приоритет для планировщика Priority-Based и вес для Weighted Fair Queuing.

Enable/Disable NoDelay

Включает и отключает использование любого алгоритма в стиле Nagle для ассоциации [RFC6458].

Configure Send Buffer Size

Управляет объемом данных, которые могут ожидать передачи (включая повтор) во внутренних буферах SCTP [RFC6458].

Configure Receive Buffer Size

Задает размер приемного буфера в октетах, управляя тем самым окном приема для ассоциации [RFC6458].

Configure Message Fragmentation

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

Configure Path MTU Discovery

Механизм Path MTU Discovery (PMTUD) можно включить и выключить для каждого адреса партнера в ассоциации (параграф 8.1.12 в [RFC6458]). При включенном механизме определяется текущее значение Path MTU, при выключенном значение Path MTU контролируется приложением.

Configure Delayed SACK Timer

Время задержки отправки SACK может быть настроено, вплоть до запрета задержки. Можно задать также число пакетов, которые должны быть получены перед отправкой SACK без ожидания таймера задержки [RFC6458].

Set Cookie Life Value

Значение Cookie life может быть настроено (параграф 8.1.2 в [RFC6458]). Valid.Cookie.Life является одним из параметров, которые могут настраиваться с помощью SetProtocolParameters [RFC4960].

Set Maximum Burst

Максимальный пик пакетов, которые могут быть отправлены конкретной ассоциацией (по умолчанию 4 и большие значения поддерживать не требуется), см. параграф 8.1.2 в [RFC6458]). Max.Burst является одним из параметров, которые могут настраиваться с помощью SetProtocolParameters [RFC4960].

Configure RTO Calculation

Абстрактный API содержащий настраиваемые параметры RTO.Initial, RTO.Min, RTO.Max, RTO.Alpha. RTO.Beta. Лишь начальное, минимальное и максимальное значение RTO указаны как настраиваемые в расширении API сокетов SCTP [RFC6458].

Set DSCP Value

Значение DSCP можно установить для адреса партнера в ассоциации (параграф 8.1.12 в [RFC6458]).

Set IPv6 Flow Label

Метку потока можно установить для адреса партнера в ассоциации (параграф 8.1.12 в [RFC6458]).

Set Partial Delivery Point

Позволяет задать размер сообщения, при котором будет использоваться частичная доставка. Снижение порога приводит к более частому применению частичной доставки [RFC6458].

Уведомление Communication Up

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

Уведомление Restart

Передается на вышележащий уровень, когда конечная точка SCTP детектирует перезапуск партнера [RFC6458].

Data Arrive

Информирует приложение о готовности к приему сообщения с помощью примитива Receive.

Уведомление Send Failure Notification/Receive Unsent Message/Receive Unacknowledged Message

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

Уведомление Network Status Change

Информирует приложение о смене состояния активности сокета [RFC4960] или состоянии PF [RFC7829].

Уведомление Communication Lost

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

Уведомление Shutdown Complete

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

Уведомление Authentication

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

Уведомление Adaptation Layer Indication

Передается на вышележащий уровень, когда SCTP завершает создание ассоциации и партнер узнает уровень адаптации [RFC5061] [RFC6458].

Уведомление Stream Reset

Информирует вышележащий уровень о результате, когда SCTP завершает процедуры сброса потоков [RFC6525].

Уведомление Association Reset

Информирует вышележащий уровень о результате, когда SCTP завершает процедуру сброса [RFC6525],.

Уведомление Stream Change

Информирует вышележащий уровень о результате, когда SCTP завершает процедуру, используемую для увеличения числа потоков [RFC6525].

Уведомление Sender Dry

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

Уведомление Partial Delivery Aborted

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

3.3.1. Исключенные примитивы и параметры

Примитив Receive может возвращать дополнительную информацию, но она не обязательна для реализации и не рассматривается здесь. С уведомлением Communication Lost также может предоставляться дополнительная информация (например, идентификация для извлечения не отправленных или не подтвержденных данных). SCTP «может вызывать» уведомление Communication Error и «передавать» уведомление Restart, которые не обязательны для реализации. Список, для примитива Status включает «и т. п.», что говорит о дополнительной информации. Примитив Get SRTT Report возвращает информацию, предоставляемую примитивом Status, поэтому здесь не рассматривается. Функция API Destroy SCTP Instance была исключена – она удаляет экземпляр SCTP, созданный Initialize, но не является примитивом в смысле данного документа, поскольку не относится к транспортным свойствам. Событие Shutdown информирует приложение о передаче партнером SHUTDOWN, поэтому данные больше не следует передавать в сокет (параграф 6.1 в [RFC6458]). Однако при попытке приложения передать данные в сокет оно будет получать сообщение об ошибке, поэтому данное событие классифицировано лишь как воздействие на стиль программирования приложений и не включено в этот документ.

3.4. Примитивы, предоставляемые UDP и UDP-Lite

Набор примитивов этапа 1 для UDP и UDP-Lite приведен в [RFC8304].

3.5. Служба LEDBAT

Описание сервиса механизма контроля перегрузок LEDBAT приведено ниже.

LEDBAT предназначен для использования фоновыми процессами с передачей больших объемов данных и быть не более активным, нежели контроль перегрузок в стандартном TCP (RFC 5681), уступая в присутствии конкурирующих потоков, что ограничивает негативное влияние одновременных потоков на производительность сети [RFC6817].

LEDBAT не имеет своих примитивов и не является транспортным протоколом. В соответствии с [RFC6817]:

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

На момент написания этого документа расширений для TCP, SCTP или DCCP еще не было.

В спецификации LEDBAT имеется много настраиваемых параметров. Параметр TARGET, задающий целевое значение задержки, при которой LEDBAT пытается работать, должен иметь значение не более 100 мсек. Параметр allowed_increase (следует устанавливать 1 и должно быть больше 0) ограничивает скорость, с которой LEDBAT повышает свою скорость работы. Параметр gain, который в соответствии с [RFC6817] «должен быть не больше 1» для предотвращения более быстрого роста скорости, чем TCP Reno, определяет, как быстро отправитель реагирует на изменение задержки в очередях. Реализации могут делить gain на два параметра, один для роста, другой (возможно, больший) для снижения. Здесь эти параметры названы Gain_Inc и Gain_Dec. Base_History указывает размер списка измеренных базовых задержек и в соответствии с [RFC6817] для него «следует устанавливать значение 10». Этот список может фильтроваться с помощью функции Filter, которая не задана в [RFC6817], но дает список размером Current_Filter. Для начального и минимального размера окна (Init_CWND и Min_CWND) следует задавать значение 2.

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

4. Этап 2

Здесь классифицируются примитивы, выбранные на этапе 1 в зависимости от того, относятся они к организации соединения или передаче данных. Примитивы представлены в соответствии с номенклатурой «Категория.[Субкатегория].Свойство.Протокол» (CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL). Категориями могут быть соединения (CONNECTION) и данные (DATA). В категории соединений могут рассматриваться подкатегории организации (ESTABLISHMENT), доступности (AVAILABILITY), поддержки (MAINTENANCE) и прерывания (TERMINATION). В категории данных подкатегорий не задано. Имя протокола UDP(-Lite) используется в примитивах, которые эквивалентны для UDP и UDP-Lite, TCP – в примитивах, эквивалентных для TCP и MPTCP. Соединения представлены как базовая концепция, независимая от протокола и служащая для обозначения, например, соединений TCP (указываются уникальными парами адресов IP и портов TCP), ассоциаций SCTP (указываются множеством пар адресов IP и номеров портов), а также соединения UDP и UDP-Lite (указываются уникальной парой сокетов).

Для общности некоторые мелкие детали не рассматриваются, например, Close в SCTP [RFC4960] возвращает успех или отказ и позволяет приложению контролировать разрешение или запрет последующих операций приема и передачи [RFC6458]. Это не описывается так же для TCP [RFC0793], но эти детали не играют важной роли для примитивов, предоставляемых TCP или SCTP (для общности можно предположить запрет операций приема и передачи в обоих случаях).

Примитивы TCP Send и Receive включают использование параметра urgent, который контролирует механизм, требуемый для реализации «сигналов синхронизации», применяемых в telnet [RFC0854], но в [RFC6093] сказано: «новым приложениям не следует поддерживать механизм TCP». Поскольку этап 2 создает основу для будущих систем, механизм urgent здесь исключен. Это отноится и к уведомлению Urgent Pointer Advance в Error_Report (параграф 4.2.4.1 в [RFC1122]).

Поскольку LEDBAT является механизмом контроля насыщения, а не протоколом, в настоящее время не задано, когда следует включать и отключать или настраивать этот механизм. Например, это может быть однократным выбором при организации соединения или прослушивании входящих вызовов и в этих случаях его следует отнести к категории CONNECTION.ESTABLISHMENT или CONNECTION.AVAILABILITY, соответственно. Для предотвращения ненужных ограничений в будущих реализациях принято решение поместить его в категорию CONNECTION.MAINTENANCE с параметрами, описанными в [RFC6817], сделав все параметры настраиваемыми.

4.1. Примитивы, связанные с соединением

Организация

Активная организация соединения одной транспортной конечной точки с одной или множеством транспортных конечных точек. Интерфейсы UDP и UDP-Lite позволяют использовать API на основе соединений и без них [RFC8085].

CONNECT.TCP

Событие или примитив этапа 1: Open (активно) или Open (пассивно) с сокетом, затем Send.

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

Комментарии: Если локальный адрес IP не указан, автоматически выбирается принятый по умолчанию. Тайм-аут может быть задан числом попыток повтора. Опциями являются опции IP для использования во всех сегментах соединения. Для соединения TCP требуется представлять хотя бы одну опцию Source Route. Конфигурация MKT относится к возможности настроить кортежи MKT для проверки подлинности. Пользовательское сообщение может передаваться партнерскому приложению сразу после приема пакета TCP SYN. Для снижения задержки с помощью экспериментального механизма TFO размер первого сообщения должен быть не больше максимального сегмента TCP (за вычетом опций TCP, использованных в SYN). Сообщение (первое) может быть доставлено приложению на удаленном хосте в нескольких экземплярах.

CONNECT.SCTP

Событие или примитив этапа 1: Initialize, затем Enable/Disable Interleaving (необязательно) и Associate.

Параметры: список локальных пар «порт SCTP – адрес IP» (Initialize), один или несколько сокетов (идентификация партнера), число выходных потоков, максимальное число входных потоков, уровень адаптации (необязательно), аутентифицируемые типы блоков (необязательно), запрос чередования (on/off)Ю максимальное число попыток INIT (необязательно), максимальное начальное значение RTO для INIT (необязательно), пользовательское сообщение (необязательно), номер удаленного порта UDP (необязательно).

Возврат: список сокетов или отказ.

Комментарии: Initialize нужно вызывать лишь один раз для списка локальных пар «порт SCTP – адрес IP». Автоматически выбирается один сокет, который можно потом изменить с помощью MAINTENANCE. Пользовательское сообщение может быть передано партнерскому приложению сразу после приема пакета с блоком COOKIE-ECHO. Для сокращения задержки размер первого сообщения должен ограничиваться так, чтобы оно помещалось в блок COOKIE-ECHO. Если указан удаленный порт UDP, пакеты SCTP инкапсулируются в UDP.

CONNECT.MPTCP

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

CONNECT.UDP(-Lite)

Событие или примитив этапа 1: Connect, затем Send.

Параметры: 1 локальный адрес IP (по умолчанию ANY или указанный адрес), 1 транспортный адрес получателя, 1 локальный порт (по умолчанию выбранный ОС или указанный), 1 порт получателя (по умолчанию выбранный ОС или указанный).

Комментарии: Связывает транспортный адрес, создавая соединение сокета UDP(-Lite). Может вызываться неоднократно с разными транспортными адресами для организации новых соединений. Функция CONNECT позволяет приложению получать сведения об ошибках при передаче сообщений по транспортному адресу.

Доступность

Подготовка к приему входящих запросов на соединения.

LISTEN.TCP

Событие или примитив этапа 1: Open (пассивно).

Параметры: 1 локальный адрес IP (необязательно), 1 сокет (необязательно), тайм-аут (необязательно), буфер для приема пользовательского сообщения (необязательно), конфигурация MKT (необязательно).

Комментарии: Если представлен сокет и/или локальный адрес IP, входящие соединения ожидаются лишь из указанного адреса и/или сокета, в ином случае принимаются все вызовы. Позднее можно выполнить организацию соединения (ESTABLISHMENT) с примитивом Send. Если представлен приемный буфер для пользовательского сообщения, это сообщение может быть принято от отправителя с поддержкой TFO до завершения согласования TCP. Такое сообщение может быть получено несколько раз. Конфигурация MKT указывает возможность настройки MKT для аутентификации.

LISTEN.SCTP

Событие или примитив этапа 1: Initialize, затем уведомление Communication Up или Restart и, возможно, уведомление Adaptation Layer.

Параметры: Список локальных пар «порт SCTP – адрес IP» (инициализация).

Возврат: Список сокетов, число выходных потоков, число входных потоков, уровень адаптации, типы аутентифицируемых блоков, поддержка чередования на обеих сторонах (yes/no).

Комментарии: Initialize нужно вызывать лишь один раз для списка локальных пар «порт SCTP – адрес IP». За уведомлением Communication Lost может следовать Communication Up, указывая восстановление потерянной связи. Если партнер указал уровень адаптации, выдается уведомление Adaptation Layer.

LISTEN.MPTCP

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

LISTEN.UDP(-Lite)

Событие или примитив этапа 1: Receive.

Параметры: 1 локальный адрес IP (по умолчанию ANY или заданный), 1 транспортный адрес получателя, локальный порт (по умолчанию выбранный ОС или заданный), порт назначения (по умолчанию выбранный ОС или заданный).

Комментарии: Функция Receive регистрирует приложение, слушающее входящие дейтаграммы UDP(-Lite) на конечной точке.

Поддержка

Выполняет настройку имеющегося соединения или уведомлений о нем. Существуют передаваемые по отдельному каналу (out-of-band) сообщения для протокола, которые могут передаваться в любой момент, по крайней мере после организации соединения и до его разрыва (за исключением CHANGE_TIMEOUT.TCP, которое может передаваться лишь для открытых соединений, когда вызывается DATA.SEND.TCP). В некоторых случаях эти примитивы могут напрямую вызываться при организации (ESTABLISHMENT) или контроле доступности (AVAILABILITY) соединения без ожидания его организации (например, CHANGE_TIMEOUT.TCP можно выполнить с использованием примитива TCP Open). Для UDP и UDP-Lite эти функции могут задавать настройки на уровне соединения или отдельного сообщения.

CHANGE_TIMEOUT.TCP

Событие или примитив этапа 1: Open или Send с незаданными переменными контроля состояния соединения.

Параметры: Тайм-аут, adv_uto (необязательно); uto_enabled (необязательно, по умолчанию false), изменяемость (необязательно, по умолчанию true).

Комментарии: При передаче данных приложение может настроить тайм-аут для соединения (время, по истечении которого соединение разрывается, если данные не удается доставить). Если uto_enabled = true, значение тайм-аута (или adv_uto при наличии) будет анонсироваться TCP на другой стороне соединения для адаптации там значения пользовательского тайм-аута. Значение uto_enabled контролирует опцию UTO для соединения в обоих направлениях. Параметр changeable управляет возможностью изменять тайм-аут на основе опции UTO, принятой с другой стороны соединения, он получает значение becomes при использовании значения timeout.

CHANGE_TIMEOUT.SCTP

Событие или примитив этапа 1: Change Heartbeat вместе с Configure Max. Retransmissions of an Association.

Параметры: Change Heartbeat для частоты heartbeat и Configure Max. Retransmissions of an Association для Association.Max.Retrans.

Комментарии: Change Heartbeat может включать или выключать сообщения heartbeat в SCTP, а также менять их частоту. Параметр Association.Max.Retrans определяет число неудачных передач любых пакетов (включая heartbeat), после которого ассоциация разрывается. Таким образом, эти примитивы и параметры вместе могут задавать поведение ассоциации SCTP как CHANGE_TIMEOUT.TCP для соединений TCP.

DISABLE_NAGLE.TCP

Событие или примитив этапа 1: Не задано.

Параметры: 1 логическое значение.

Комментарии: Алгоритм Nagle задерживает передачу данных для повышения вероятности отправки полноразмерного сегмента. Приложение должно иметь возможность отключать этот алгоритм для соединения.

DISABLE_NAGLE.SCTP

Событие или примитив этапа 1: Enable/Disable NoDelay.

Параметры: 1 логическое значение.

Комментарии: Алгоритмы класса Nagle задерживают передачу данных для повышения вероятности отправки полноразмерного сегмента. Приложение должно иметь возможность отключать этот алгоритм для соединения.

REQUEST_HEARTBEAT.SCTP

Событие или примитив этапа 1: Request Heartbeat.

Параметры: Сокет.

Возврат: успех или отказ.

Комментарии: Запрашивает незамедлительное сообщение heartbeat на пути, возвращая отказ или успех.

ADD_PATH.MPTCP

Событие или примитив этапа 1: Не задано.

Параметры: Локальный адрес IP, локальный номер порта (необязательно).

Комментарии: Приложение указывает локальный адрес IP и номер порта, которые должны использоваться для субпотока.

ADD_PATH.SCTP

Событие или примитив этапа 1: Change Local Address/Set Peer Primary.

Параметры: Локальный адрес IP.

REM_PATH.MPTCP

Событие или примитив этапа 1: Не задано.

Параметры: Локальный адрес IP, локальный номер порта, удаленный адрес IP, удаленный номер порта.

Комментарии: Приложение удаляет субпоток, указанный парой «адрес IP – порт». Реализация MPTCP должна инициировать удаление субпотока, относящегося к этой паре.

REM_PATH.SCTP

Событие или примитив этапа 1: Change Local Address/Set Peer Primary.

Параметры: Локальный адрес IP.

SET_PRIMARY.SCTP

Событие или примитив этапа 1: Set Primary.

Параметры: Сокет.

Возврат: Результат предпринятой попытки.

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

SET_PEER_PRIMARY.SCTP

Событие или примитив этапа 1: Change Local Address/Set Peer Primary.

Параметры: Локальный адрес IP.

Комментарии: Это лишь рекомендация для партнера.

CONFIG_SWITCHOVER.SCTP

Событие или примитив этапа 1: Configure Path Switchover.

Параметры: Основное максимальное число повторов (после которого путь считается неактивным) и максимальное число повторов для PF (после которого путь считается ненадежным и применяются другие пути) (необязательно).

STATUS.SCTP

Событие или примитив этапа 1: Уведомления Status, Enable/Disable Interleaving и Network Status Change.

Возврат: Блок данных о конкретной ассоциации, содержащий состояние соединения, список транспортных адресов получателей и состояния их доступности, текущие размеры окна (локального и принимающего партнера), текущие размеры локального окна насыщения, число неподтвержденных блоков DATA, число блоков DATA, ожидающих приема, первичный путь, последнее значение SRTT на первичном пути, RTO на первичном пути, SRTT и RTO на других адресах получателей, MTU на каждом пути и поддержка чередования (yes/no).

Комментарии: Уведомление Network Status Change информирует приложение а смене состояния активности сокета. Оно влияет лишь на стиль программирования, поскольку эти же данные доступны через примитив Status.

STATUS.MPTCP

Событие или примитив этапа 1: Не задано.

Возврат: Список пар «адрес IP – порт TCP» каждого субпотока. Первая пара содержит локальный адрес IP и порт, вторая — удаленные.

SET_DSCP.TCP

Событие или примитив этапа 1: Не задано.

Параметры: Значение DSCP.

Комментарии: Примитив позволяет приложению изменить значение DSCP для исходящих сегментов.

SET_DSCP.SCTP

Событие или примитив этапа 1: Установка DSCP.

Параметры: Значение DSCP.

Комментарии: Примитив позволяет приложению изменить значение DSCP для исходящих пакетов на пути.

SET_DSCP.UDP(-Lite)

Событие или примитив этапа 1: Set_DSCP.

Параметры: Значение DSCP.

Комментарии: Примитив позволяет приложению изменить значение DSCP для исходящих дейтаграмм UDP(-Lite). Рекомендации по использованию поля приведены в [RFC7657] и [RFC8085].

ERROR.TCP

Событие или примитив этапа 1: Error_Report.

Возврат: Причина (кодирование не занято) и субпричина (кодирование не занято).

Комментарии: Мягкие ошибки многие приложения могут игнорировать без ущерба и следует обеспечивать возможность такого игнорирования. Ошибки включают сообщения ICMP об ошибках и избыточные повторы.

ERROR.UDP(-Lite)

Событие или примитив этапа 1: Error_Report.

Возврат: Сообщение об ошибке.

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

SET_AUTH.TCP

Событие или примитив этапа 1: Не задано.

Параметры: current_key и rnext_key.

Комментарии: Ключи current_key и rnext_key указывают предпочтительный исходящий и входящий MKT, соответственно, для сегмента, передаваемого в соединение.

SET_AUTH.SCTP

Событие или примитив этапа 1: Set/Get Authentication Parameters.

Параметры: key_id, key, hmac_id.

GET_AUTH.TCP

Событие или примитив этапа 1: Не задано.

Параметры: current_key и rnext_key

Комментарии: current_key и rnext_key указывают предпочтительный исходящий и входящий MKT, соответственно, переданные в недавно принятом сегменте.

GET_AUTH.SCTP

Событие или примитив этапа 1: Set/Get Authentication Parameters.

Параметры: key_id и chunk_list.

RESET_STREAM.SCTP

Событие или примитив этапа 1: Add/Reset Streams, Reset Association.

Параметры: sid и направление.

RESET_STREAM-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Stream Reset.

Параметры: Информация о результате RESET_STREAM.SCTP.

Комментарии: Вызывается при завершении процедуры сброса потоков.

RESET_ASSOC.SCTP

Событие или примитив этапа 1: Add/Reset Streams, Reset Association.

Параметры: Информация, относящаяся к расширению, как определено в [RFC3260].

RESET_ASSOC-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Association Reset.

Параметры: Информация о результате RESET_ASSOC.SCTP.

Комментарии: Вызывается при завершении процедуры сброса ассоциации.

ADD_STREAM.SCTP

Событие или примитив этапа 1: Add/Reset Streams, Reset Association.

Параметры: Число добавленных исходящих и входящих потоков.

ADD_STREAM-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Stream Change.

Параметры: Информация о результате ADD_STREAM.SCTP.

Комментарии: Вызывается при завершении процедуры добавления потока.

SET_STREAM_SCHEDULER.SCTP

Событие или примитив этапа 1: Set Stream Scheduler.

Параметры: Идентификатор планировщика.

Комментарии: Выбор из планировщиков First-Come-First-Served, Round-Robin, Round-Robin по пакетам, Priority-Based, Fair Bandwidth, Weighted Fair Queuing.

CONFIGURE_STREAM_SCHEDULER.SCTP

Событие или примитив этапа 1: Configure Stream Scheduler.

Параметры: Приоритет.

Комментарии: Значение приоритета применимо лишь при выборе планировщика Priority-Based или Weighted Fair Queuing с помощью SET_STREAM_SCHEDULER.SCTP. Смысл параметра разный для этих планировщиков, но в обоих случаях он реализует ту или иную форму приоритизации в части распределения пропускной способности между потоками.

SET_FLOWLABEL.SCTP

Событие или примитив этапа 1: Set IPv6 Flow Label

Параметры: Метка потока.

Комментарии: Примитив позволяет приложению изменять метку потока в заголовке IPv6 для исходящих пакетов на пути.

AUTHENTICATION_NOTIFICATION-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Authentication.

Возврат: Информация, относящаяся к управлению ключами.

CONFIG_SEND_BUFFER.SCTP

Событие или примитив этапа 1: Configure Send Buffer Size.

Параметры: Размер в октетах.

CONFIG_RECEIVE_BUFFER.SCTP

Событие или примитив этапа 1: Configure Receive Buffer Size.

Параметры: Размер в октетах.

Комментарии: Примитив управляет размером окна у получателя.

CONFIG_FRAGMENTATION.SCTP

Событие или примитив этапа 1: Configure Message Fragmentation.

Параметры: Логическое значение (enable/disable) и максимальный размер (необязательно, по умолчанию PMTU).

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

CONFIG_PMTUD.SCTP

Событие или примитив этапа 1: Configure Path MTU Discovery.

Параметры: Одно логическое значение (PMTUD вкл./выкл.) и размер PMTU (необязательно).

Возврат: Значение PMTU.

Комментарии: Примитив возвращает осмысленное значение PMTU, когда PMTUD включено (логический параметр true) и позволяет установить PMTU, если PMTUD отключено (логический параметр false).

CONFIG_DELAYED_SACK.SCTP

Событие или примитив этапа 1: Configure Delayed SACK Timer.

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

Комментарии: Если задержка SACK разрешена, SCTP будет слоть SACK при получении заданного числа пакетов или по таймеру (что наступит раньше).

CONFIG_RTO.SCTP

Событие или примитив этапа 1: Configure RTO Calculation.

Параметры: Начальное (необязательно), минимальное (необязательно), максимальное (необязательно) значение RTO.

Комментарии: Примитив настраивает начальное, минимальное и максимальное значение RTO.

SET_COOKIE_LIFE.SCTP

Событие или примитив этапа 1: Set Cookie Life Value

Параметры: Значение cookie life.

SET_MAX_BURST.SCTP

Событие или примитив этапа 1: Set Maximum Burst.

Параметры: Максимальный размер пика.

Комментарии: Не все реализации поддерживают значения больше 4.

SET_PARTIAL_DELIVERY_POINT.SCTP

Событие или примитив этапа 1: Set Partial Delivery Point

Параметры: Граница частичной доставки (integer).

Комментарии: Этот параметр должен быть не больше размера приемного буфера сокета.

SET_CHECKSUM_ENABLED.UDP

Событие или примитив этапа 1: Checksum_Enabled.

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

SET_CHECKSUM_REQUIRED.UDP

Событие или примитив этапа 1: Require_Checksum.

Параметры 0 разрешает нулевую контрольную сумму, 1 требует на приемной стороне контрольную сумму, отличную от 0 (принято по умолчанию).

SET_CHECKSUM_COVERAGE.UDP-Lite

Событие или примитив этапа 1: Set_Checksum_Coverage.

Параметры: Размер покрытия контрольной суммой у отправителя (по умолчанию максимальное покрытие).

SET_MIN_CHECKSUM_COVERAGE.UDP-Lite

Событие или примитив этапа 1: Set_Min_Coverage.

Параметры: Размер покрытия контрольной суммой у получателя (по умолчанию минимальное покрытие).

SET_DF.UDP(-Lite)

Событие или примитив этапа 1: Set_DF.

Параметры: 0, если флаг DF не установлен (принято по умолчанию) в заголовке IPv4, 1 при установленном флаге.

GET_MMS_S.UDP(-Lite)

Событие или примитив этапа 1: Get_MM_S.

Комментарии: Примитив позволяет определить максимальный размер транспортного сообщения, которое может быть передано без фрагментации IP с настроенного интерфейса.

GET_MMS_R.UDP(-Lite)

Событие или примитив этапа 1: Get_MMS_R.

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

SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS)

Событие или примитив этапа 1: Set_TTL и Set_IPV6_Unicast_Hops.

Параметры: Значение IPv4 TTL или IPv6 Hop Count.

Комментарии: Примитив позволяет приложению изменить значение IPv4 TTL или IPv6 Hop Count для исходящих дейтаграмм UDP(-Lite).

GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS)

Событие или примитив этапа 1: Get_TTL и Get_IPV6_Unicast_Hops.

Возврат: Значение IPv4 TTL или IPv6 Hop Count.

Комментарии: Примитив позволяет приложению узнать значение IPv4 TTL или IPv6 Hop Count из входящей дейтаграммы UDP(-Lite).

SET_ECN.UDP(-Lite)

Событие или примитив этапа 1: Set_ECN.

Параметры: Значение ECN.

Комментарии: Примитив позволяет приложению UDP(-Lite) установить код явного контроля перегрузок (ECN) в исходящих дейтаграммах UDP(-Lite). По умолчанию передается 00.

GET_ECN.UDP(-Lite)

Событие или примитив этапа 1: Get_ECN.

Параметры: Значение ECN.

Комментарии: Примитив позволяет приложению UDP(-Lite) прочитать код явного контроля перегрузок (ECN) из входящей дейтаграммы UDP(-Lite).

SET_IP_OPTIONS.UDP(-Lite)

Событие или примитив этапа 1: Set_IP_Options.

Параметры: Опции.

Комментарии: Примитив позволяет приложению UDP(-Lite) установить опции IP для исходящих дейтаграмм UDP(-Lite). Опции могут включать по меньшей мере Source Route, Record Route, Timestamp.

GET_IP_OPTIONS.UDP(-Lite)

Событие или примитив этапа 1: Get_IP_Options.

Возврат: Опции.

Комментарии: Примитив позволяет приложению UDP(-Lite) прочитать любые опции IP из входящей дейтаграммы UDP(-Lite).

CONFIGURE.LEDBAT

Событие или примитив этапа 1: Не задано.

Параметры: enable (логическое значение), target, allowed_increase, gain_inc, gain_dec, base_history, current_filter, init_cwnd, min_cwnd.

Комментарии: Новый параметр enable включает или отключает сервис LEDBAT.

Прерывание

Gracefully or forcefully closing a connection or being informed about this event happening.

CLOSE.TCP

Событие или примитив этапа 1: Close.

Комментарии: Примитив закрывает соединение на передающей стороне после гарантированной доставки оставшихся данных.

CLOSE.SCTP

Событие или примитив этапа 1: Shutdown.

Комментарии: Прерывает соединение после гарантированной доставки оставшихся данных.

ABORT.TCP

Событие или примитив этапа 1: Abort.

Комментарии: Прерывает соединение без доставки оставшихся данных и передает удаленной стороне сообщение об ошибке.

ABORT.SCTP

Событие или примитив этапа 1: Abort.

Параметры: Причина разрыва для партнера (необязательно).

Комментарии: Прерывает соединение без доставки оставшихся данных и передает другой стороне сообщение об ошибке.

ABORT.UDP(-Lite)

Событие или примитив этапа 1: Close.

Комментарии: Прерывает соединение без доставки оставшихся данных. Через этот экземпляр соединения дейтаграммы UDP(-Lite) больше не передаются и не принимаются.

TIMEOUT.TCP

Событие или примитив этапа 1: Событие User Timeout.

Комментарии: Приложение уведомляется о разрыве соединения. Событие вызывается по таймеру, установленному CONNECTION.ESTABLISHMENT.CONNECT.TCP (возможно изменено с помощью CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP).

TIMEOUT.SCTP

Событие или примитив этапа 1: Событие Communication Lost.

Комментарии: Приложение уведомляется о разрыве соединения. Событие вызывается по тайм-ауту, который следует включать по умолчанию (см. начало параграфа 8.3 в [RFC4960]). Тайм-аут может быть изменен с помощью CONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTP.

ABORT-EVENT.TCP

Событие или примитив этапа 1: Не задано.

ABORT-EVENT.SCTP

Событие или примитив этапа 1: Событие Communication Lost.

Возврат: Причина разрыва от партнера (при ее доступности).

Комментарии: Сообщает приложению о разрыве соединения партнером с помощью CONNECTION.TERMINATION.ABORT.SCTP.

CLOSE-EVENT.TCP

Событие или примитив этапа 1: Не задано.

CLOSE-EVENT.SCTP

Событие или примитив этапа 1: Событие Shutdown Complete.

Комментарии: Приложение информируется об успешном вызове CONNECTION.TERMINATION.CLOSE.SCTP.

4.2. Примитивы, связанные с передачей данных

Все примитивы в этом разделе относятся к существующему соединению, т. е. соединению, которое было организовано или стало доступным для получения данных (хотя это не обязательно для примитивов UDP(-Lite)). В дополнение к указанным параметра все примитивы передачи включают ссылку на блок данных, а примитивы приема – ссылку на буфер для размещения принимаемых данных. Отметим, что примитивы CONNECT.TCP и LISTEN.TCP в категории организации (ESTABLISHMENT) и доступности (AVAILABILITY) соединения также позволяют передавать данные (необязательное пользовательское сообщение) до завершения процесса организации соединения.

SEND.TCP

Событие или примитив этапа 1: Send.

Параметры: timeout (необязательно), current_key (необязательно), rnext_key (необязательно).

Комментарии: Примитив отдает TCP блок данных для гарантированной передачи TCP на другой стороне соединения. Этот вызов позволяет указать тайм-аут(см. CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). Параметры current_key и rnext_key связаны с проверкой подлинности и могут мыть настроены этим вызовом (см. CONNECTION.MAINTENANCE.SET_AUTH.TCP).

SEND.SCTP

Событие или примитив этапа 1: Send.

Параметры: Номер потока, контекст (необязательно), сокет (необязательно), флаг неупорядоченности (необязательно), флаг управления группировкой (необязательно), идентификатор протокола в данных (необязательно), pr-policy (необязательно), pr-value (необязательно), флаг незамедлительного подтверждения (необязательно), key-id (необязательно).

Комментарии: Примитив отдает SCTP блок данных для передачи SCTP на другой стороне соединения (ассоциации SCTP). Параметр stream number указывает используемый поток, context может позднее применяться для ссылки на корректное сообщение при уведомлении об ошибке, socket может служить для указания предпочтительного состояния пути при наличии нескольких путей (см. CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). Блок данных может доставляться без сохранения порядка, если установлен флаг unordered. Флаг no-bundle устанавливается для указания предпочтительности отказа от группировки сообщений. Идентификатор протокола в поле данных указывает принимающему приложению способ обработки данных. С помощью параметров pr-policy и pr-value можно управлять уровнем гарантий, флаг sack-immediately указывает партнеру, что следует передать соответствующее подтверждение SACK без задержки. Параметр key-id применяется для аутентификации пользовательского сообщения.

SEND.UDP(-Lite)

Событие или примитив этапа 1: Send.

Параметры: IP-адрес и номер порта у получателя (необязательно при соединении).

Комментарии: Примитив предоставляет сообщение для гарантированной доставки с использованием UDP(-Lite) по указанному транспортному адресу. Адрес IP и номер порта можно не указывать для соединенных сокетов UDP(-Lite). При отправке сообщения применяются все примитивы CONNECTION.MAINTENANCE.SET_*.UDP(-Lite).

RECEIVE.TCP

Событие или примитив этапа 1: Receive.

Параметры: current_key (необязательно) и rnext_key (необязательно).

Комментарии: Параметры аутентификации current_key и rnext_key могут быть прочитаны этим вызовом (см. CONNECTION.MAINTENANCE.GET_AUTH.TCP).

RECEIVE.SCTP

Событие или примитив этапа 1: Уведомление Data Arrive, затем Receive.

Параметры: Номер потока (необязательно).

Возврат: Порядковый номер потока (необязательно) и флаг частичной передачи (необязательно).

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

RECEIVE.UDP(-Lite)

Событие или примитив этапа 1: Receive.

Параметры: Буфер для принимаемой дейтаграммы.

Комментарии: К сообщению применяются все примитивы CONNECTION.MAINTENANCE.GET_*.UDP(-Lite).

SENDFAILURE-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Send Failure, за которым может слодовать сообщение Receive Unsent или Receive Unacknowledged.

Возврат: Код причины и не переданное (не подтвержденное) сообщение (необязательно).

Комментарии: Код причины указывает причину отказа, а context – номер контекста, если он предоставлен в DATA.SEND.SCTP, для последующего использования с сообщением Receive Unsent или Receive Unacknowledged. Эти примитивы можно применять для извлечения сообщений (или частей в случае частичной передачи), которые не были переданы или подтверждены.

SEND_FAILURE.UDP(-Lite)

Событие или примитив этапа 1: Send.

Комментарии: Этот примитив можно применять для определения эффективного PMTU при использовании с примитивом MAINTENANCE.SET_DF.

SENDER_DRY-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Sender Dry.

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

PARTIAL_DELIVERY_ABORTED-EVENT.SCTP

Событие или примитив этапа 1: Уведомление Partial Delivery Aborted.

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

5. Этап 3

Здесь представлен расширенный набор всех транспортных свойств всех протоколов, описанных в предшествующих разделах, на основе списка примитивов этапа 2, а также текста этапа 1 для включения транспортных свойств, которые могут быть настроены в одном протоколе и являются статическими в другом (например, контроль перегрузок). Некоторые мелкие детали опущены в целях общности, например, TCP может предоставлять разные опции IP, но лишь опция source route обязательна для реализации и эта деталь не видна на этапе 3 в транспортном свойстве «задание опций IP». Как и раньше, UDP(-Lite) представляет протоколы UDP и UDP-Lite, а TCP – TCP и MPTCP.

5.1. Свойства, связанные с соединением

Организация

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

Connect

Протоколы: TCP, SCTP, UDP(-Lite).

Задание опций IP, которые должны применяться всегда

Протоколы: TCP и UDP(-Lite).

Запрос множества потоков

Протоколы: SCTP.

Ограничение числа входящих потоков

Протоколы: SCTP.

Задание числа попыток и/или тайм-аутов для первого сообщения при организации

Протоколы: TCP и SCTP.

Получение множества сокетов

Протоколы: SCTP.

Отключение MPTCP

Протоколы: MPTCP.

Настройка аутентификации

Протоколы: TCP и SCTP.

Комментарии: В TCP это позволяет настраивать кортежи MKT, в SCTP – указание блоков, для которых нужна аутентификация. DATA, ACK и т. п. Являются в SCTP разными блоками и могут включаться в один пакет.

Указание кода уровня адаптации

Протоколы: SCTP.

Запрос согласования для чередования пользовательских сообщений

Протоколы: SCTP.

Отправка сообщения с гарантией доставки (возможно несколько раз) до организации соединения

Протоколы: TCP.

Отправка сообщения с гарантией доставки в процессе организации соединения

Протоколы: SCTP.

Включение UDP-инкапсуляции с заданным удаленным портом UDP

Протоколы: SCTP.

Доступность

Подготовка к приему входящих запросов на соединение.

Listen, 1 локальный интерфейс

Протоколы: TCP, SCTP, UDP(-Lite).

Listen, N локальных интерфейсов

Протоколы: SCTP.

Listen, все локальные интерфейсы

Протоколы: TCP, SCTP, UDP(-Lite).

Получение запрошенного числа потоков

Протоколы: SCTP.

Ограничение числа входящих потоков

Протоколы: SCTP.

Задание опций IP, которые должны применяться всегда

Протоколы: TCP и UDP(-Lite).

Отключение MPTCP

Протоколы: MPTCP.

Настройка аутентификации

Протоколы: TCP и SCTP.

Комментарии: В TCP это позволяет настраивать кортежи MKT, в SCTP – указание блоков, для которых нужна аутентификация. DATA, ACK и т. п. Являются в SCTP разными блоками и могут включаться в один пакет.

Указание кода уровня адаптации

Протоколы: SCTP.

Поддержка

Настройки для открытых соединений или уведомления о них.

Смена тайм-аута для разрыва соединения (время или число повторов)

Протоколы: TCP и SCTP.

Предложенный партнеру тайм-аут

Протоколы: TCP.

Отключение алгоритма Nagle

Протоколы: TCP и SCTP.

Запрос немедленной передачи heartbeat с возвратом результата

Протоколы: SCTP.

Уведомление об избыточных повторах (ранее до достижения порога разрыва)

Протоколы: TCP.

Добавление пути

Протоколы: MPTCP и SCTP.

Параметры MPTCP: source-IP, source-Port, destination-IP, destination-Port.

Параметры SCTP: локальный IP-адрес.

Удаление пути

Протоколы: MPTCP и SCTP.

Параметры MPTCP: source-IP, source-Port, destination-IP, destination-Port.

Параметры SCTP: локальный IP-адрес.

Задание основного пути

Протоколы: SCTP.

Предложение основного пути партнеру

Протоколы: SCTP.

Настройка переключения пути

Протоколы: SCTP.

Определение статуса (запрос или уведомление)

Протоколы: SCTP и MPTCP.

Параметры SCTP: Состояние соединения для ассоциации, список транспортных адресов получателей, состояния доступности транспортных адресов получателей, текущие размеры окна получателя (локальный и удаленный), текущий размер локального окна перегрузки, число неподтвержденных блоков DATA, число блоков DATA, ожидающих приема, последнее значение SRTT на основном пути, RTO на основном пути, SRTT и RTO для других адресов получателей, MTU для путей, поддержка чередования (yes/no).

Параметры MPTCP: Список субпотоков (идентификация по source-IP, source-Port, destination-IP, destination-Port).

Задание поля DSCP

Протоколы: TCP, SCTP, UDP(-Lite).

Уведомление о приеме сообщения ICMP об ошибке

Протоколы: TCP и UDP(-Lite).

Смена параметров аутентификации

Протоколы: TCP и SCTP.

Получение данных аутентификации

Протоколы: TCP и SCTP.

Сброс потока

Протоколы: SCTP.

Уведомление о сбросе потока

Протоколы: STCP.

Сброс ассоциации

Протоколы: SCTP.

Уведомление о сбросе ассоциации

Протоколы: STCP.

Добавление потоков

Протоколы: SCTP.

Уведомление о добавлении потоков

Протоколы: STCP.

Выбор планировщика для потоков в ассоциации

Протоколы: SCTP.

Настройка приоритета или веса для планировщика

Протоколы: SCTP.

Установка метки потока IPv6

Протоколы: SCTP.

Настройка размера буфера передачи

Протоколы: SCTP.

Настройка размера приемного буфера (и rwnd)

Протоколы: SCTP.

Настройка фрагментации сообщений

Протоколы: SCTP.

Настройка PMTUD

Протоколы: SCTP.

Настройка таймера задержки SACK

Протоколы: SCTP.

Установка значения Cookie life

Протоколы: SCTP.

Установка максимального пика

Протоколы: SCTP.

Настройка размера сообщений для частичной доставки

Протоколы: SCTP.

Запрет контрольной суммы при отправке

Протоколы: UDP.

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

Протоколы: UDP.

Задание покрытия для контрольной суммы у отправителя

Протоколы: UDP-Lite.

Минимальное покрытие для контрольной суммы, требуемое получателем

Протоколы: UDP-Lite.

Задание поля DF

Протоколы: UDP(-Lite).

Определение максимального размера транспортного сообщения для передачи без фрагментации IP через настроенный интерфейс

Протоколы: UDP(-Lite).

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

Протоколы: UDP(-Lite).

Задание поля TTL/Hop Count

Протоколы: UDP(-Lite).

Получение поля TTL/Hop Count

Протоколы: UDP(-Lite).

Задание поля ECN

Протоколы: UDP(-Lite).

Получение поля ECN

Протоколы: UDP(-Lite).

Задание опций IP

Протоколы: UDP(-Lite).

Получение опций IP

Протоколы: UDP(-Lite).

Включение и настройка LEDBAT

Протоколы: Протоколы, реализующие механизм контроля перегрузок LEDBAT.

Прерывание

Аккуратное или жесткое завершение соединения или информирование о таком событии.

Закрытие после гарантированной доставки оставшихся данных с уведомлением приложения на другой стороне

Протоколы: TCP и SCTP.

Комментарии: Конечная точка TCP локально закрывает соединение лишь для передачи и может ждать приема данных.

Разрыв без доставки оставшихся данных с уведомлением приложения на другой стороне

Протоколы: TCP и SCTP.

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

Разрыв без доставки оставшихся данных и уведомления приложения на другой стороне

Протоколы: UDP(-Lite).

Тайм-аут, когда данные не удается доставить слишком долго

Протоколы: TCP и SCTP.

Комментарии: Тайм-аут задается CONNECTION.MAINTENANCE.

5.2. Свойства, связанные с передачей данных

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

5.2.1. Передача

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

Гарантированная доставка данных с контролем перегрузок

Протоколы: TCP.

Гарантированная доставка сообщения с контролем перегрузок

Протоколы: SCTP.

Негарантированная доставка сообщения с контролем перегрузок

Протоколы: SCTP.

Негарантированная доставка сообщения без контроля перегрузок

Протоколы: UDP(-Lite).

Настраиваемые гарантии для сообщений

Протоколы: SCTP.

Выбор потока

Протоколы: SCTP.

Выбор пути (адреса получателя)

Протоколы: SCTP.

Упорядоченная доставка сообщений (возможно медленней неупорядоченной)

Протоколы: SCTP.

Неупорядоченная доставка сообщений (возможно быстрей упорядоченной)

Протоколы: SCTP и UDP(-Lite).

Запрос отмены группировки сообщений

Протоколы: SCTP.

Задание идентификатора протокола в области данных (для получателя)

Протоколы: SCTP.

Задание идентификатора ключа для аутентификации сообщения

Протоколы: SCTP.

Запрос передачи без задержки подтверждения SACK для сообщения

Протоколы: SCTP.

5.2.2. Прием

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

Прием данных (без границ сообщений)

Протоколы: TCP.

Прием сообщения

Протоколы: SCTP и UDP(-Lite).

Выбор потока для приема

Протоколы: SCTP.

Информация о частичной доставке сообщения

Протоколы: SCTP.

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

5.2.3. Ошибки

Здесь описаны отказы при передаче, связанные с конкретными вызовами примитива DATA.SEND этапа 2.

Уведомление о неотправленном (частино) сообщении

Протоколы: SCTP и UDP(-Lite).

Уведомление о неподтвержденном (частино) сообщении

Протоколы: SCTP.

Уведомление об отсутствии в стеке данных для передачи

Протоколы: SCTP.

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

Протоколы: SCTP.

6. Взаимодействие с IANA

Этот документ не требует действий со стороны IANA.

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

Проверка подлинности, защита целостности и конфиденциальности указаны как транспортные свойства в [RFC8095]. Эти свойства обычно присущи транспортному протоколоу или расположенному над ним уровню. Ни один из рассмотренных здесь транспортных протоколов сам по себе не обеспечивает этих свойств, поэтому они не рассматриваются в документе за исключением естественных функций аутентификации в TCP и SCTP, для которых применимы вопросы безопасности, отмеченные в [RFC5925] и [RFC4895].

Вопросы безопасности для UDP и UDP-Lite рассмотрены в упомянутых RFC. Рекомендации по защите приложений, использующих UDP, даны в [RFC8085].

8. Литература

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

[RFC0793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, “Stream Control Transmission Protocol (SCTP) Partial Reliability Extension”, RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, “Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)”, RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.

[RFC4960] Stewart, R., Ed., “Stream Control Transmission Protocol”, RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration”, RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.

[RFC5482] Eggert, L. and F. Gont, “TCP User Timeout Option”, RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option”, RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, “Architectural Guidelines for Multipath TCP Development”, RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.

[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, “Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)”, RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.

[RFC6525] Stewart, R., Tuexen, M., and P. Lei, “Stream Control Transmission Protocol (SCTP) Stream Reconfiguration”, RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, “Low Extra Delay Background Transport (LEDBAT)”, RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, “TCP Extensions for Multipath Operation with Multiple Addresses”, RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.

[RFC6897] Scharf, M. and A. Ford, “Multipath TCP (MPTCP) Application Interface Considerations”, RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.

[RFC6951] Tuexen, M. and R. Stewart, “UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication”, RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.

[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, “SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol”, RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, “TCP Fast Open”, RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, “Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension”, RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.

[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. Nielsen, “SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol”, RFC 7829, DOI 10.17487/RFC7829, April 2016, <https://www.rfc-editor.org/info/rfc7829>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, “Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol”, RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.

[RFC8304] Fairhurst, G. and T. Jones, “Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)”, RFC 8304, DOI 10.17487/RFC8304, February 2018, <https://www.rfc-editor.org/info/rfc8304>.

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

[RFC0854] Postel, J. and J. Reynolds, “Telnet Protocol Specification”, STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC3260] Grossman, D., “New Terminology and Clarifications for Diffserv”, RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.

[RFC5461] Gont, F., “TCP’s Reaction to Soft Errors”, RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.

[RFC6093] Gont, F. and A. Yourtchenko, “On the Implementation of the TCP Urgent Mechanism”, RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.

[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, “A Roadmap for Transmission Control Protocol (TCP) Specification Documents”, RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.

[RFC7657] Black, D., Ed. and P. Jones, “Differentiated Services (Diffserv) and Real-Time Communication”, RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., “Services Provided by IETF Transport Protocols and Congestion Control Mechanisms”, RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[TAPS-MINSET] Welzl, M. and S. Gjessing, “A Minimal Set of Transport Services for TAPS Systems”, Work in Progress11, draft-ietf-taps-minset-01, February 2018.

Приложение A. Список RFC, использованных для этапа 1

TCP

[RFC0793], [RFC1122], [RFC5482], [RFC5925], [RFC7413].

MPTCP

[RFC6182], [RFC6824], [RFC6897].

SCTP

RFC без спецификаций API сокетов: [RFC3758], [RFC4895], [RFC4960], [RFC5061].

RFC со спецификациями API сокетов: [RFC6458], [RFC6525], [RFC6951], [RFC7053], [RFC7496], [RFC7829].

UDP(-Lite)

См. [RFC8304].

LEDBAT

[RFC6817].

Приложение B. Как разрабатывался этот документ

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

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

Примитивы, которые могут быть реализованы транспортным протоколом, были исключены из рассмотрения. Для включения в документ минимальным требованием служило указание, что примитив следует реализовать. Там, где не применялся стиль обозначения требований из [RFC2119], примитивы исключались, если они были описаны вместе с такими утверждениями, как «некоторые реализации также представляют» или «реализация может также». Исключенные примитивы и параметры кратко упомянуты в специальных параграфах документа.

Этап 1 начинался с определения текста, описывающего примитив. Обычно примитивы описываются в спецификации API (возможно, абстрактной), но здесь представляли интерес не только спецификации API. Текст, описывающий примитив Send в API [RFC0793], например, не говорит о гарантированной передаче данных. Однако такие гарантии становятся очевидными из текста раздела 1 в [RFC0793].

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

Часть текста на этапе 1 была заимствована из соответствующих RFC с корректировкой терминов в соответствии с разделом 2 и сокращением фраз для сохранения стиля документа. Была попытка представить все как описания примитивов, сделав их максимально полными (например, примитив SEND.TCP на этапе 2 явно описан как гарантированная доставка данных). Текст, относящийся к представленным на этом этапе примитивам, но не входящий непосредственно в описание какого-либо примитива, использовался во вводной части параграфов.

Этап 2 служил для унификации примитивов. Входными данными служил лишь текст этапа 1 (без внешних источников). Список на этапе 2 упорядочен не по протоколам (в стиле «протокол X и его примитивы, протокол Y и его примитивы»), а по примитивам («примитив A реализован определенным способомв протоколе X, иным способом в протоколе Y …»). Цель состояла в получении на этапе 2 максимального числа похожих примитивов. Например, иной раз это достигалось за счет того, что не всегда поддерживалось отображение 1:1 между этапами 1 и 2, примитивы переименовывались и пр. Для каждого нового примитива рассматривались уже имеющиеся для обеспечения максимальной согласованности.

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

ИмяПримитива.Протокол

Событие или примитив этапа 1:

Параметры:

Возврат:

Комментарии:

Записи «Параметры», «Возврат», «Комментарии» пропускались, если с примитивом не было связано соответствующей информации. Необяхательные параметры были помечены текстом «(необязательно)», при наличии принятых по умолчанию значений они указывались.

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

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

Авторы благодарят (в алфавитном порядке) Bob Briscoe, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch, Brian Trammell за ценные отклики на этот документ. Большое спавибо Christoph Paasch за информацию о Multipath TCP, а Gorry Fairhurst и Tom Jones – за UDP(-Lite). Эта работа финансировалась исследовательской и инновационной программой Европейского Союза Horizon 2020 в рамках гранта 644334 (NEAT).

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

Michael Welzl

University of Oslo

PO Box 1080 Blindern

Oslo N-0316

Norway

Email: michawe@ifi.uio.no

Michael Tuexen

Muenster University of Applied Sciences

Stegerwaldstrasse 39

Steinfurt 48565

Germany

Email: tuexen@fh-muenster.de

Naeem Khademi

University of Oslo

PO Box 1080 Blindern

Oslo N-0316

Norway

Email: naeemk@ifi.uio.no

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

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

nmalykh@protocols.ru

1Transmission Control Protocol – протокол управления передачей.

2MultiPath TCP – TCP с множеством путей.

3Stream Control Transmission Protocol – протокол управления передачей потоков.

4User Datagram Protocol – протокол пользовательских дейтаграмм.

5Lightweight User Datagram Protocol – облегченный протокол пользовательских дейтаграмм.

6Low Extra Delay Background Transport – базовый транспорт с очень низкими задержками.

7Internet Engineering Task Force.

8Internet Engineering Steering Group.

9Datagram Congestion Control Protocol – протокол контроля перегрузок для дейтаграмм.

10Peer-to-peer – «равный с равным».

11Опубликовано в RFC 8923. Прим. перев.




RFC 8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8304                                      T. Jones
Category: Informational                           University of Aberdeen
ISSN: 2070-1721                                            February 2018

Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

Транспортные свойства UDP и UDP-Lite

PDF

Аннотация

Этот информационный документ описывает примитивы интерфейса транспортного протокола, предоставляемые протоколами UDP1 и UDP-Lite2. Он указывает службы дейтаграмм, раскрываемые приложениям, способы настройки приложений и использование ими функций, предоставляемых службой транспортировки дейтаграмм в Internet. В RFC 8303 описано применение транспортных функций, обеспечиваемых транспортными протоколами IETF3, с указанием как UDP, UDP-Lite и другие транспортные протоколы раскрывают свои услуги приложениям и как приложения могут настроить и использовать эти услуги. Этот документ предоставляет исходные данные и контекст для упомянутого документа, а также предлагает план документации, которая может помочь пользователям протоколов UDP и UDP-Lite.

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IETF и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG4. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8304.

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

Copyright (c) 2018. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions для документов IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите эти документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

В этом документе представлен некоторые взаимодействия между транспортными протоколами и приложениями в форме примитивов (вызовы функций) для протоколов UDP [RFC0768] и UDP-Lite [RFC3828]. В данном случае приложением считается оюбая программа, работающая на основе интерфейса дейтаграмм, включая туннели и другие протоколы вышележащих уровней, применяющий UDP и UDP-Lite.

Протокол UDP имеет множество реализаций и применяется для широкого спектра приложений. Особый класс приложений может получать преимущества при доставке поврежденных данных вместо их отбрасывания, когда нужно работать по путям с каналами, подверженными ошибкам. Приложения, устойчивые к повреждению данных, могут выбрать UDP-Lite вместо UDP и использовать API5 приложения для работы с контрольными суммами. Приложения UDP также могут выбрать UDP-Lite, но пока это менее распространено и пользователи могут столкнуться с путями, где UDP-Lite не поддерживается. Эти вопросы более подробно рассмотрены в параграфе 3.4 [RFC8085].

Стандартный IEEE API для приложений TCP/IP использует интерфейс сокетов [POSIX]. Приложение может использовать функции POSIX recv() и send() POSIX, а также recvfrom(), sendto(), recvmsg(), sendmsg(). API сокетов UDP и UDP-Lite отличается от интерфейса для TCP в нескольких важных аспектах (примеры использования API даны в [STEVENS]). В UDP и UDP-Lite каждая дейтаграмма является самодостаточным сообщением заданного размера и на транспортном уровне могут применяться опции, устанавливающие свойства для всех последующих дейтаграмм, передаваемых через этот сокет, или изменяемые для каждой дейтаграммы. Для дейтаграмм от приложения может потребоваться использование API при установке данных уровня IP (IP TTL6, кодов дифференцированного обслуживания DSCP7, фрагментирования IP и т. п.) для передаваемых и принимаемых дейтаграмм. При использовании TCP и другого транспорта, ориентированного на соединения) данные уровня IP обычно остаются неизменными в течение срока соединения или контролируются транспортным протоколом, а не приложением.

Опции сокета применяются в API для обеспечения дополнительных функций. Например, опция IP_RECVTTL применяется некоторыми групповыми приложениями UDP для возврата значения поля IP TTL из заголовка принятой дейтаграммы.

Некоторые платформы предлагают приложениям возможность напрямую собирать и передавать пакеты IP через «необрабатываемые» (raw) сокеты или аналогичные средства. API для raw-сокетов является вторым, более громоздким методом передачи дейтаграмм UDP. Использование этого API рассматривается в [RFC8085].

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

В описании раздела 3 используется терминология, определенная рабочей группой IETF TAPS в [RFC8303]. В частности, документ обеспечивает этап 1 описанного там процесса, который рассматривает RFC, описывающие примитивы каждого протокола. В [RFC8303] эти данные служат входной информацией для описания использования транспортных функций, предоставляемых транспортными протоколами IETF, показывающего как UDP, UDP-Lite и другие транспортные протоколы раскрывают свои услуги приложениям и как приложения могут настроить и применять эти функции для использования транспортных услуг.

Представленный план документации транспортного интерфейса может также помочь разработчикам при работе с UDP и UDP-Lite.

2. Терминология

В этом документе представлены детали для этапа в анализе UDP и UDP-Lite, который используется в [RFC8303]. Документ использует определенную там терминологию , а также уровни требований из RFC 2119 [RFC2119].

3. Примитивы UDP и UDP-Lite

UDP [RFC0768] [RFC8200] и UDP-Lite [RFC3828] – это стандартизованные IETF транспортные протоколы, обеспечивающие односторонние услуги на основе дейтаграмм, поддерживающие операции приема и передачи с сохранением границ сообщений.

В этом разделе приведены относящиеся к теме фрагменты текста RFC, описывающих протоколы UDP и UDP-Lite, с акцентом на предоставление транспортными протоколами своих услуг приложениях и способах использования приложениями этих услуг (на основе описаний абстрактных API, когда они доступны). Описано, как UDP применяется с протоколами IPv4 и IPv6 для отправки индивидуальных и anycast-дейтаграмм, а также для отправки широковещательных дейтаграмм для IPv4. Набор примитивов сетевого уровня для использования UDP или UDP-Lite при групповой адресации IP (IPv4 и IPv6) был задан в серии RFC. Приложение A описывает источники информации о примитивах сетевого уровня, нужных для использования с UDP или UDP-Lite при групповой адресации IP (IPv4 и IPv6).

3.1. Примитивы, предоставляемые UDP

В [RFC0768] сказано:

Протокол передачи пользовательских дейтаграмм (User Datagram Protocol или UDP) предназначен для поддержки режима обмена дейтаграммами на основе коммутации пакетов в среде связанных между собой компьютерных сетей. … Протокол UDP обеспечивает прикладным программам процедуры для передачи сообщений другим приложениям с минимальным сервисом.

В разделе «Пользовательский интерфейс» RFC 768 сказано, что интерфейс с приложением должен предоставлять:

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

Протокол UDP был определен для IPv6 [RFC8200] вместе с расширениями API “Расширения базового интерфейса сокетов для IPv6” [RFC3493].

В [RFC6935] и [RFC6936] обновлено определение транспорта UDP, заданное исходно в [RFC2460] (заменен RFC 8200). Это позволяет использовать режим с нулевой контрольной суммой UDP для туннельных протоколов при условии, что метод удовлетворяет требованиям в соответствующем заявлении о применимости [RFC6936].

UDP предлагает лишь базовый транспортный интерфейс. Дейтаграммы UDP можно напрямую передавать и принимать без обмена между конечными точками сообщениями для организации соединения (т. е. транспортный протокол не выполняет согласования перед обменом данными). Используя API сокетов, приложения могут принимать пакеты от нескольких адресов IP на один сокет UDP. Общая поддержка позволяет указать один локальный IP-адрес, IP-адрес получателя, локальный и удаленный порт. Можно использовать для любого или всех этих полей принятые по умолчанию значения, предоставляемые локальной системой. Локальный адрес конечной точки устанавливается с помощью вызова BIND, адрес удаленной точки – с помощью CONNECT. Функция CLOSE имеет лишь локальную значимость и не влияет на состояние удаленной точки.

Ни UDP, ни UDP-Lite не поддерживают контроля перегрузок, повтора передачи, механизмов пакетизации на прикладном уровне, позволяющих избежать фрагментации IP, и других транспортных функций. Это означает, что использующие UDP приложения должны обеспечивать дополнительные функции на основе транспортного API UDP [RFC8085]. Некоторые транспортные функции требует передачи через API параметров для управления сетевым уровнем (IPv4 или IPv6). Эти дополнительные примитивы можно считать частью сетевого уровня (например, контроль установки флага запрета фрагментирования DF в передаваемых дейтаграммах IPv4), но они необходимы для того, чтобы позволить пользователю UDP API реализовать функции, которые обычно связаны с транспортным уровнем (такие как зондирование максимального размера пакетов на пути). Этот документ включает такие примитивы.

Руководство по использованию услуг UDP представлено в [RFC8085], где также сказано:

Многие операционные системы позволяют подключить сокет UDP, т. е. связать его с конкретной парой адресов и портов. Это похоже на соответствующую функциональность API сокетов TCP, однако в UDP эта операция локальна и служит лишь для упрощения локальных функций приема и передачи, а также фильтрации трафика для конкретных адресов и портов. Привязка сокета UDP не организует соединения и UDP не уведомляет удаленную сторону о привязке локального сокета UDP. Привязка сокета также помогает в настройке опций, влияющих на уровень UDP или IP, например, использование контрольной суммы UDP или опции IP Timestamp. В некоторых стеках привязка сокета также позволяет приложению получать уведомления при получении сообщения ICMP об ошибках для переданных через сокет пакетов [RFC1122].

Базовая спецификация POSIX [POSIX] определяет API, который предлагает приложениям механизмы получения асинхронных событий, связанных с данными, на уровне сокета. Такие вызовы, как poll, select, queue позволяют приложению получать уведомления о прибытии данных в сокет или очистке сокетом своих буферов.

Управляемый обратными вызовами (callback) API сетевой интерфейс можно структурировать поверх этих вызовов. Неявная организация соединений позволяет приложениям передать управление «жизнью» соединения транспортному API, который использует примитивы протокола, чтобы предлагать приложению примитивы через API сокета. Комбинация примитивов UDP (CONNECT.UDP и SEND.UDP) с API вышележащего уровня может предоставлять похожие услуги.

Ниже перечислены примитивы дейтаграмм.

CONNECT

Примитив CONNECT позволяет связать наборы портов отправителя и получателя с сокетом, чтобы организовать «соединение» для трафика UDP. Такое соединение позволяет приложению получать сведения об ошибках от сетевого стека и обеспечивает сокращенный доступ к примитивам SEND и RECEIVE. Поскольку сам протокол UDP не использует соединений, выполнение этого примитива не вызывает передачи дейтаграммы. Для изменения ассоциации можно снова вызвать connect.

Роли клиента и сервера часто не подходят для UDP, где соединения могут быть peer-to-peer (равный с равным или одноранговые). Функция прослушивания выполняется с использованием одной из форм примитива CONNECT.

  1. bind() – операция привязки устанавливает локальный порт неявно, запуская операцию sendto на непривязанном и несоединенном сокете и использованием эфемерного порта, или с явной привязкой для использования настроенного или общепринятого порта.
  2. bind(); connect() – операция привязки с последующим примитивом CONNECT. Привязка организует использование известного локального порта для дейтаграмм вместо эфемерного порта. Операция connect задает известную комбинацию адрес-порт для использования по умолчанию в будущих дейтаграммах. Эта форма применяется после приема дейтаграммы от конечной точки, которая вызвала создание соедиения или может быть инициирована сторонней конфигурацией или протокольным триггером (например, прием записи протокола описания сервиса UDP SDP [RFC4566]).

SEND

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

RECEIVE

Примитив RECEIVE выделяет приемный буфер для размещения полученной дейтаграммы. Примитив возвращает число байтов из полученной дейтаграммы UDP. В параграфе 4.1.3.5 [RFC1122] сказано: «При получении дейтаграммы UDP указанный адрес получателя должен передаваться на уровень приложений».

CHECKSUM_ENABLED

Необязательный примитив CHECKSUM_ENABLED определяет, включает ли отправитель контрольную сумму UDP при передаче дейтаграмм [RFC0768] [RFC6935] [RFC6936] [RFC8085]. Если примитив сброшен (unset), это отменяет принятое по умолчанию поведение UDP, отключая контрольную сумму при отправке. В параграфе 4.1.3.4 [RFC1122] сказано: «Приложения могут управлять процессом генерации контрольных сумм UDP, но по умолчанию протокол должен включать контрольную сумму».

REQUIRE_CHECKSUM

Необязательный примитив REQUIRE_CHECKSUM определяет поведение при получении дейтаграмм с нулевой контрольной суммой UDP. По умолчанию UDP требует наличия контрольной суммы. В параграфе 4.1.3.4 [RFC1122] сказано: «Приложения могут управлять решением вопроса об отбрасывании дейтаграмм без контрольной суммы». Параграф 3.1 спецификации UDP-Lite [RFC3828] требует отличной от 0 контрольной суммы, поэтому интерфейс UDP-Lite API должен отбрасывать дейтаграммы с нулевой контрольной суммой.

SET_IP_OPTIONS

Примитив SET_IP_OPTIONS запрашивает у сетевого уровня передачу дейтаграммы с заданными опциями IP. В параграфе 4.1.3.2 [RFC1122] сказано: «Приложениям должна предоставляться возможность установки опций IP для передаваемых дейтаграмм UDP и протокол UDP должен передавать эти опции уровню IP».

GET_IP_OPTIONS

Примитив GET_IP_OPTIONS отыскивает опции IP для принятой сетевым уроынем дейтаграммы. В параграфе 4.1.3.2 [RFC1122] указано, что на стороне получателя UDP: «Протокол UDP должен передавать прикладным программам все опции IP, полученные от уровня IP».

SET_DF

Примитив SET_DF позволяет сетевому уровню фрагментировать пакеты с использованием Fragment Offset в IPv4 [RFC6864], а хосту – использовать Fragment Headers в IPv6 [RFC8200]. SET_DF устанавливает флаг DF в заголовке пакета IPv4 с дейтаграммой UDP, управляющий возможностью фрагментирования пакетов IPv4 маршрутизаторами. Хотя некоторые приложения опираются на поддержку фрагментирования, в общем случае приложениям UDP следует реализовать метод предотвращения фрагментации IP (раздел 4 в [RFC8085]). Отметим, что во многих других транспортных протоколах IETF (например, TCP и SCTP) транспорт обеспечивает поддержку, требуемую для применения DF. Однако при использовании UDP приложение отвечает за методы, требуемые для определения эффективного Path MTU (PMTU) на пути через сеть в координации с сетевым уровнем. Классический механизм Path MTU Discovery (PMTUD) [RFC1191] основан на возврате с пути сообщений ICMP Fragmentation Needed или ICMPv6 Packet Too Big. Когда такие сообщения ICMP не доставляются (или фильтруются), отправитель не может узнать реальное значение PMTU и дейтаграммы UDP, размер которых превышает PMTU, уйдут в «черную дыру». Для предотвращения этого приложение может реализовать механизм PLPMTUD (Packetization Layer Path MTU Discovery) [RFC4821], который не опирается на поддержку в сети сообщений ICMPv6 и поэтому считается более отказоустойчивым, нежели стандартный механизм PMTUD, как отмечено в [RFC8085] и [RFC8201].

GET_MMS_S

Примитив GET_MMS_S извлекает значение сетевого уровня, указывающее максимальный размер сообщения (MMS), которое можно передать на транспортном уровне в нефрагментируемом пакете IP через настроенный интерфейс. Это значение задано в параграфе 6.1 [RFC1191] и параграфе 5.1 [RFC8201]. Значение рассчитывается по эффективному MTU для передачи (Effective MTU for Sending или EMTU_S) и MTU на канале для данного IP-адреса отправителя. Учитывается размер заголовка IP и пространство, резервируемое уровнем IP для дополнительных заголовков (при наличии). Приложениям UDP следует использовать это значение как часть метода предотвращения отправки дейтаграмм UDP, порождающих пакеты IP, размер которых превышает эффективное значение PMTU на пути через сеть. Эффективное значение PMTU (см. раздел 1 в [RFC1191]) эквивалентно EMTU_S (задано в [RFC1122]). В спецификации PLPMTUD [RFC4821] сказано:

Если PLPMTUD обновляет MTU для определенного пути, все сессии уровня пакетизации, использующие этот путь (см. параграф 5.2), следует уведомить об использовании нового MTU и выполнении требуемой корректировки контроля перегрузок.

GET_MMS_R

Примитив GET_MMS_R извлекает значение сетевого уровня, указывающее MMS для пакетов, принимаемых транспортным уровнем через настроенный интерфейс. Значение задано в параграфе 3.1 [RFC1191] и рассчитывается из эффективного MTU для приема (Effective MTU for Receiving или EMTU_R) и MTU канала для данного IP-адреса отправителя с учетом размера заголовка IP и пространства, резервируемого уровнем IP для дополнительных заголовков (при наличии).

SET_TTL

Примитив SET_TTL устанавливает значение Hop Limit (поле TTL) на сетевом уровне, которое используется в заголовке IPv4 пакета с дейтаграммой UDP. Поле служит для ограничения области действия индивидуальных дейтаграмм. В параграфе 3.2.2.4 [RFC1122] сказано: «Принимаемые сообщения Time Exceeded должны передаваться на транспортный уровень».

GET_TTL

Примитив GET_TTL извлекает значение поля TTL в пакете IP, принятом сетевым уровнем. Приложения с поддержкой обобщенного механизма защиты GTSM [RFC5082] могут использовать эту информацию, чтобы доверять дейтаграммам со значением TTL в ожидаемом диапазоне, как указано в разделе 3 RFC 5082.

SET_MIN_TTL

Примитив SET_MIN_TTL ограничивает доставку дейтаграмм приложению на основании поля IP TTL, значение которого должно быть не меньше указанного параметром. Примитив можно использовать для реализации таких приложений, как GTSM (раздел 3 в RFC 5082) [RFC5082], но RFC не задает этого метода.

SET_IPV6_UNICAST_HOPS

Примитив SET_IPV6_UNICAST_HOPS задает поле сетевого уровня Hop Limit в заголовке пакета IPv6 [RFC8200] с дейтаграммой UDP. Для индивидуальных дейтаграмм IPv6 это функционально эквивалентно SET_TTL в IPv4.

GET_IPV6_UNICAST_HOPS

Примитив GET_IPV6_UNICAST_HOPS является функцией сетевого уровня, считывающей значение счетчика интервалов в заголовкеIPv6 header [RFC8200] полученной дейтаграммы UDP. Это задано в параграфе 6.3 RFC 3542. Для индивидуальных дейтаграмм IPv6 это функционально эквивалентно GET_TTL в IPv4.

SET_DSCP

Примитив SET_DSCP является функцией сетевого уровня, устанавливающей значение DSCP (или Type of Service – ToS) [RFC2474] в поле заголовка IP пакета с дейтаграммой UDP. В параграфе 2.4 [RFC1123] сказано: «Приложение должно выбирать приемлемые значения TOS при обращении к службам транспортного уровня и эти значения должны быть настраиваемыми». Приложению следует поддерживать возможность изменения ToS в процессе работы соединения и значение ToS следует передавать на уровень IP без изменения. В параграфе 4.1.4 [RFC1122] сказано: «UDP может передавать полученные значения TOS на уровень приложений». Модель Diffserv [RFC2475] [RFC3260] заменила это поле заголовка IP, выделив 6 старших битов для поля DSCP [RFC2474]. Сохранение требования [RFC1122] разрешать приложению задавать тип обслуживания следует понимать как сохранение возможности API разрешать приложению установку DSCP. В параграфе 3.1.8 [RFC8085] описаны способы использования этого поля приложениями UDP. Обычно сокет UDP будет назначать одно значение DSCP для всех дейтаграмм потока, но отправителю разрешено в некоторых случаях применять разные значения DSCP для дейтаграмм одного потока [RFC8085]. Рекомендации для WebRTC иллюстрируют такой случай [RFC7657].

SET_ECN

Примитив SET_ECN является функцией сетевого уровня, устанавливающей поле явного контроля перегрузок (Explicit Congestion Notification или ECN) в заголовке IP дейтаграммы UDP. Поле ECN по умолчанию имеет значение 00. Когда использование поля ToS было переопределено в Diffserv [RFC3260], 2 бита поля были выделены для ECN [RFC3168]. В параграфе 3.1.78 [RFC8085] описано, как приложению UDP следует использовать это поле. Отметим, что во многих других транспортных протоколах IETF (например, TCP) транспорт обеспечивает поддержку ECN. При использовании UDP за методы, требуемые для применения ECN отвечает приложение или протокол вышележащего уровня.

GET_ECN

Примитив GET_ECN является функцией сетевого уровня, возвращающей значение поля ECN в заголовке IP принятой дейтаграммы UDP. В параграфе 3.1.5 [RFC8085] сказано: «UDP, должен проверять поле ECN для каждой принятой на этом порту дейтаграммы UDP». Это требует от UDP API на стороне получателя передавать полученное поле ECN прикладному уровню для подобающей реакции на перегрузку.

ERROR_REPORT

Событие ERROR_REPORT информирует приложение о некритичной ошибке (soft errors), включая прием сообщения ICMP или ICMPv6 об ошибке. В параграфе 4.1.3.39 [RFC1122] сказано: «Протокол UDP должен передавать на уровень приложений все сообщения ICMP об ошибках, полученные от уровня IP». Это событие требуется, например, для реализации на основе ICMP механизма Path MTU Discovery [RFC1191] [RFC8201]. Приложения UDP должны выполнять примитив CONNECT для получения сообщений ICMP об ошибках.

CLOSE

Примитив CLOSE закрывает соединение. После этого дейтаграммы не передаются и не принимаются. Поскольку сам протокол UDP не использует соединения, после выполнения этого примитива дейтаграммы не передаются.

3.1.1. Исключенные примитивы

В параграфе 3.4 [RFC1122] описаны примитивы GET_MAXSIZES и ADVISE_DELIVPROB, а в параграфе 3.3.4.4 – GET_SRCADDR. Эти механизмы больше не применяются. Документ также задает использование сообщений ICMP Source Quench, которые были отменены [RFC6633].

Функция IPV6_V6ONLY является примитивом сетевого уровня, который применяется ко всем транспортным службам, как указано в параграфе 5.3 для базового интерфейса сокетов IPv6 [RFC3493]. Это ограничивает использование информации от распознавателя имен, разрешая лишь коммуникации сокетов AF_INET6 с использованием IPv6 и не считается частью транспортного сервиса.

3.2. Примитивы, предоставляемые UDP-Lite

UDP-Lite [RFC3828] предоставляет услуги, похожие на UDP. В протоколе изменена семантика поля размера данных UDP (payload length) на семантику поля покрытия контрольной суммой. UDP-Lite требует расчета контрольной суммы псевдозаголовка отправителем и ее проверки получателем. В остальном UDP-Lite семантически эквивалентен UDP.

Передающий интерфейс UDP-Lite отличается от UDP добавление одной опции (сокета), указывающей область покрытия контрольной суммы, которая задает учитываемую в расчете часть данных, а остальные называют нечувствительными к ошибкам (error-insensitive part).

Приемный интерфейс UDP-Lite отличается от UDP добавлением одной опции (сокета), задающей минимальное покрытие контрольной суммой. База UDP-Lite MIB (Management Information Base) [RFC5097] дополняет метод покрытия контрольной суммой. Рекомендации по использованию услуг UDP-Lite приведены в [RFC8085].

UDP-Lite требует наличия контрольной суммы UDP или UDP-Lite, поэтому не разрешает использовать функцию DISABLE_CHECKSUM для запрета расчета контрольной суммы и не позволяет отключить проверку контрольной суммы получателем с помощью REQUIRE_CHECKSUM. Остальные примитивы и функции UDP разрешены.

Кроме того, добавлено 2 примитива, описанных ниже.

SET_CHECKSUM_COVERAGE

Примитив SET_CHECKSUM_COVERAGE задает облать дейтаграммы, учитываемую в контрольной сумме. Трафик UDP-Lite использует этот примитив для установки размера области покрытия контрольной суммой UDP. В параграфе 3.3 спецификации UDP-Lite [RFC3828] сказано: «Приложениям, желающим определить часть своих данных, как нечувствительные к битовым ошибкам …, следует делать это путем явного системного вызова на стороне отправителя». По умолчанию применяется такое же покрытие как в UDP.

SET_MIN_COVERAGE

Примитив SET_MIN_COVERAGE задает минимальную приемлемую область покрытия контрольной суммой в принимаемой дейтаграмме. Трафик UDP-Lite использует этот примитив для установки области покрытия, проверяемой на приеме (в параграфе 1.1 [RFC5097] указана запись MIB udpliteEndpointMinCoverage). В параграфе 3.3 спецификации UDP-Lite [RFC3828] сказано: «Приложениям, желающим получать данные с неполным покрытием для контрольной суммы, следует информировать принимающую систему с помощью явного системного вызов». По умолчанию для принимаемых дейтаграмм требуется лишь минимальное покрытие.

4. Взаимодействие с IANA

Этот документ не требует действий со стороны IANA.

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

Вопросы безопасности при использовании UDP и UDP-Lite рассмотрены в упомянутых RFC. Рекомендации по защите приложений, использующих протоколы, даны в [RFC8085].

6. Литература

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

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC1112] Deering, S., “Host extensions for IP multicasting”, STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1123] Braden, R., Ed., “Requirements for Internet Hosts – Application and Support”, STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6”, RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.

[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., “The Lightweight User Datagram Protocol (UDP-Lite)”, RFC 3828, DOI 10.17487/RFC3828, July 2004, <https://www.rfc-editor.org/info/rfc3828>.

[RFC6864] Touch, J., “Updated Specification of the IPv4 ID Field”, RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, “IPv6 and UDP Checksums for Tunneled Packets”, RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, “Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., “Path MTU Discovery for IP version 6”, STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, “On the Usage of Transport Features Provided by IETF Transport Protocols”, RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.

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

[POSIX] IEEE, “Standard for Information Technology — Portable Operating System Interface (POSIX(R)) Base Specifications”, Issue 7, IEEE 1003.1, <http://ieeexplore.ieee.org/document/7582338/>.

[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC3260] Grossman, D., “New Terminology and Clarifications for Diffserv”, RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3”, RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

[RFC3678] Thaler, D., Fenner, B., and B. Quinn, “Socket Interface Extensions for Multicast Source Filters”, RFC 3678, DOI 10.17487/RFC3678, January 2004, <https://www.rfc-editor.org/info/rfc3678>.

[RFC3810] Vida, R., Ed. and L. Costa, Ed., “Multicast Listener Discovery Version 2 (MLDv2) for IPv6”, RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol”, RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4604] Holbrook, H., Cain, B., and B. Haberman, “Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast”, RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, “The Generalized TTL Security Mechanism (GTSM)”, RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5097] Renker, G. and G. Fairhurst, “MIB for the UDP-Lite protocol”, RFC 5097, DOI 10.17487/RFC5097, January 2008, <https://www.rfc-editor.org/info/rfc5097>.

[RFC5790] Liu, H., Cao, W., and H. Asaeda, “Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols”, RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>.

[RFC6633] Gont, F., “Deprecation of ICMP Source Quench Messages”, RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.

[RFC7657] Black, D., Ed. and P. Jones, “Differentiated Services (Diffserv) and Real-Time Communication”, RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, “UNIX Network Programming, The sockets Networking API”, Volume 1, ISBN-13: 9780131411555, October 2003.

Приложение A. Примитивы групповой адресации

В этом приложении описаны примитивы, служащие для поддержки в UDP и UDP-Lite групповой адресации IPv4 и IPv6. Групповые услуги не рассматриваются рабочей группой IETF TAPS, но имеющиеся примитивы для полноты указаны в этом приложении. Рекомендации по использованию групповых услуг UDP и UDP-Lite даны в [RFC8085].

Групповая адресация IP может поддерживаться с помощью модели ASM10 или SSM11. Во втором случае требуется применять фильтр отправителей (Multicast Source Filter или MSF) при указании группового IP-адреса получателей.

Для использования групповой адресации нужны дополнительные примитивы в транспортном API, которые вызываются для координации действий протоколов сетевого уровня IPv4 и IPv6. Например, для получения отправленных в группу дейтаграмм конечная точка должна сначала стать членом группы на сетевом уровне. Локальный прием групповых пакетов IPv4 использует сигнализацию протокола Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604]. В IPv6 используется эквивалентный протокол Multicast Listener Discovery (MLD) [RFC3810] [RFC5790], работающий на основе ICMPv6. Облегченные версии этих протоколов заданы в [RFC5790].

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

JoinHostGroup

В параграфе 7.1 [RFC1112] представлены функции, позволяющие принимать трафик из multicast-групп IP.

JoinLocalGroup

В параграфе 7.3 [RFC1112] представлены функции, позволяющие принимать трафик из локальных групп IP.

LeaveHostGroup

В параграфе 7.1 [RFC1112] представлены функции, позволяющие выходить из multicast-групп IP.

LeaveLocalGroup

В параграфе 7.3 представлены функции, позволяющие выходить из локальных multicast-групп IP.

IPV6_MULTICAST_IF

В параграфе 5.2 IPv6 [RFC3493] сказано, что этот примитив задает интерфейс, используемый для исходящих групповых пакетов.

IP_MULTICAST_TTL

Устанавливает поле времени жизни t в исходящих групповых пакетах IPv4 для ограничения области распространения дейтаграмм. Такие методы, как GTSM [RFC5082], устанавливают это значение для обеспечения передачи в локальный канал. GTSM также требует у получателя UDP API для передачи этого значения приложению.

IPV6_MULTICAST_HOPS

В параграфе 5.2 [RFC3493] сказано, что этот примитив задает число интервалов (hop count) для исходящих групповых пакетов IPv6 (эквивалент IP_MULTICAST_TTL в IPv4).

IPV6_MULTICAST_LOOP

В параграфе 5.2 [RFC3493] сказано, что этот примитив задает, нужно ли возвращать копию дейтаграммы на уровень IP для локальной доставки при передаче дейтаграммы в группу, к которой относится передающий хост.

IPV6_JOIN_GROUP

В параграфе 5.2 [RFC3493] представлена функция для включения конечной точки в multicast-группу IPv6.

SIOCGIPMSFILTER

В параграфе 8.1 [RFC3678] представлена функция, позволяющая читать фильтры multicast-отправителей.

SIOCSIPMSFILTER

В параграфе 8.1 [RFC3678] представлена функция для установки и изменения фильтров multicast-отправителей.

IPV6_LEAVE_GROUP

В параграфе 5.2 [RFC3493] представлена функция для выхода конечной точки из multicast-группы IPv6.

В [RFC3678] обновлен групповой интерфейс с добавлением поддержки MSF для IPv4 и IPv6, требуемой IGMPv3. В разделе 3 определены базовый и расширенный API, а раздел 5 описывает независимые от протокола версии этих API. Определены 4 набора функциональности API:

  1. Базовый IPv4 API. Каждый вызов функции задает один адрес отправителя, который следует добавить или удалить для фильтра данной прослушиваемой группы адресов.

  2. Расширенный IPv4 API. Позволяет приложению задать полный фильтр отправителей на замену имеющемуся.

  3. Независимый от протокола базовый MSF API.

  4. Независимый от протокола расширенный MSF API.

Определенные вновь примитивы перечислены ниже.

IP_ADD_MEMBERSHIP

Служит для присоединения к группе ASM.

IP_BLOCK_SOURCE

Этот фильтр MSF может блокировать данные от указанного отправителя в данную группу ASM или SSM.

IP_UNBLOCK_SOURCE

Обновляет MSF для отмены предыдущего вызова IP_UNBLOCK_SOURCE для группы ASM или SSM.

IP_DROP_MEMBERSHIP

Служит для выхода из группы ASM или SSM (в SSM ведет к отбрасыванию всех отправителей, присоединенных к конкретной группе и интерфейсу, что эквивалентно закрытию сокета).

В параграфе 4.1.2 MSF [RFC3678] обновлен интерфейс путем добавления поддержки IPv4 MSF в IGMPv3 с ASM.

IP_ADD_SOURCE_MEMBERSHIP

Служит для присоединения к группе SSM.

IP_DROP_SOURCE_MEMBERSHIP

Служит для выхода из группы SSM.

Параграф 4.2 [RFC3678] определяет расширенный API, примитивы которого указаны ниже.

setipv4sourcefilter

Служит для присоединения к группе IPv4 или разрешения multicast-трафика из указанного источника.

getipv4sourcefilter

Служит для выхода из группы IPv4 или фильтрации multicast-трафика из указанного источника.

В параграфе 5.1 [RFC3678] заданы функции независимого от протокола базового API, перечисленные ниже.

MCAST_JOIN_GROUP

Служит для присоединения к группе ASM.

MCAST_JOIN_SOURCE_GROUP

Служит для присоединения к группе SSM.

MCAST_BLOCK_SOURCE

Служит для блокировки отправителя в группе ASM.

MCAST_UNBLOCK_SOURCE

Удаляет прежний фильтр MSF, установленный MCAST_BLOCK_SOURCE.

MCAST_LEAVE_GROUP

Служит для выхода из группы ASM или SSM.

MCAST_LEAVE_SOURCE_GROUP

Служит для выхода из группы SSM.

В параграфе 5.2 [RFC3678] заданы функции независимого от протокола расширенного API для IPv4 и IPv6.

setsourcefilter

Служит для присоединения к группе IPv4 или IPv6 и разрешения multicast-трафика из указанного источника.

getsourcefilter

Служит для выхода из группы IPv4 или IPv6 и фильтрации multicast-трафика из указанного источника.

Протоколы Lightweight IGMPv3 (LW_IGMPv3) и MLDv2 [RFC5790] обновляют этот интерфейс (параграф 7.2 в RFC 5790).

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

Эта работа частично финансировалась исследовательской и инновационной программой Европейского Союза Horizon 2020 в рамках гранта 644334 (NEAT). Спасибо всем, кто внес свои комментарии или вклад в работу, включая Joe Touch, Ted Hardie, Aaron Falk, Tommy Pauly и Francis Dupont.

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

Godred Fairhurst

University of Aberdeen

School of Engineering

Fraser Noble Building

Fraser Noble Building Aberdeen AB24 3UE

United Kingdom

Email: gorry@erg.abdn.ac.uk

Tom Jones

University of Aberdeen

School of Engineering

Fraser Noble Building

Aberdeen AB24 3UE

United Kingdom

Email: tom@erg.abdn.ac.uk

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

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

nmalykh@protocols.ru

1User Datagram Protocol – протокол пользовательских дейтаграмм.

2Lightweight User Datagram Protocol – облегченный протокол UDP.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Application programming interface – интерфейс с прикладными программами.

6Time To Live – время жизни.

7Differentiated Services Code Point.

8В оригинале ошибочно указан параграф 3.1.5. См. https://www.rfc-editor.org/errata/eid6370. Прим. перев.

9В оригинале ошибочно указан параграф 4.1.4. https://www.rfc-editor.org/errata/eid6371. Прим. перев.

10Any Source Multicast – групповая адресация для любого источника.

11Source-Specific Multicast – зависимая от источника групповая адресация.




RFC 8335 PROBE: A Utility for Probing Interfaces

Internet Engineering Task Force (IETF)                         R. Bonica
Request for Comments: 8335                                     R. Thomas
Updates: 4884                                           Juniper Networks
Category: Standards Track                                     J. Linkova
ISSN: 2070-1721                                                   Google
                                                               C. Lenart
                                                                 Verizon
                                                            M. Boucadair
                                                                  Orange
                                                           February 2018

PROBE – утилита для зондирования интерфейсов

PROBE: A Utility for Probing Interfaces

PDF

Тезисы

Этот документ описывает инструмент сетевой диагностики, названный PROBE. Программа PROBE похожа на PING в том смысле, что может использоваться для запроса состояния проверяемого интерфейса, но отличается тем, что ей не требуется двухсторонняя связность между проверяющим и проверяемым интерфейсом. Вместо этого программе PROBE нужна двухсторонняя связность между проверяющим интерфейсом и интерфейсом-посредником (proxy). Этот интерфейс может размещаться на одном узле с проверяемым интерфейсом или на узле, с которым тот непосредственно соединен. Этот документ обновляет RFC 4884.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8335.

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

Авторские права (Copyright (c) 2018) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

Сетевые операторы используют PING [RFC2151] для проверки двухсторонней связности между интерфейсами. В этом документе такие интерфейсы называются проверяющим и проверяемым. PING передает сообщения ICMP [RFC792] [RFC4443] Echo Request с проверяющего интерфейса проверяемому. Проверяющий интерфейс размещается на проверяющем узле, а проверяемый – на проверяемом.

Если проверяемый интерфейс получает сообщение ICMP Echo Request, он возвращает ICMP Echo Reply. Получив ICMP Echo Reply, проверяющий узел убеждается в наличии двухсторонней связности между проверяющим и проверяемым интерфейсом. В частности, подтверждается:

  • возможность доступа проверяющего узла к проверяемому интерфейсу;

  • активность проверяемого интерфейса;

  • возможность доступа проверяемого узла к проверяющему интерфейсу;

  • активность проверяющего интерфейса.

Этот документ описывает инструмент сетевой диагностики, названный PROBE. Программа PROBE похожа на PING в том смысле, что может использоваться для запроса состояния проверяемого интерфейса, но отличается тем, что ей не требуется двухсторонняя связность между проверяющим и проверяемым интерфейсом. Вместо этого программе PROBE нужна двухсторонняя связность между проверяющим интерфейсом и интерфейсом-посредником (proxy). Этот интерфейс может размещаться на одном узле с проверяемым интерфейсом или на узле, с которым тот непосредственно соединен. В разделе 5 рассмотрены примеры использования программы.

Подобно PING, программа PROBE выполняется на проверяющем узле, который передает сообщение ICMP Extended Echo Request со своего локального интерфейса, называемого проверяющим, на интерфейс посредника, размещаемый на узле-посреднике.

ICMP Extended Echo Request содержит структуру ICMP Extension Structure, а та содержит объект Interface Identification Object, указывающий проверяемый интерфейс, который находится на узле-посреднике или соединен с ним.

Когда интерфейс-посредник получает ICMP Extended Echo Request, узел-посредник выполняет процедуры контроля доступа. Если доступ разрешен, этот узел определяет статус проверяемого интерфейса и возвращает ICMP Extended Echo Reply. Сообщение ICMP Extended Echo Reply указывает статус проверяемого интерфейса.

Если проверяемый интерфейс размерен на узле-посреднике, PROBE определяет его статус как oper-status [RFC7223]. Если oper-status имеет значение up (1), PROBE сообщает об активности интерфейса. В противном случае PROBE сообщает, что интерфейс не активен.

Если проверяемый интерфейс расположен на узле, напрямую соединенном с посредником, и присутствует в таблице IPv4 ARP3 [RFC826] или IPv6 Neighbor Cache [RFC4861], PROBE сообщает о доступности интерфейса. В противном случае PROBE сообщает, что в таблице нет записи для интерфейса.

1.1. Терминология

Ниже приведены определения используемых в документе терминов.

  • Probing interface (проверяющий интерфейс) – интерфейс, передающий ICMP Extended Echo Request.

  • Probing node (проверяющий узел) – узел, на котором размещается проверяющий интерфейс.

  • Proxy interface (интерфейс-посредник) – интерфейс, которому передается ICMP Extended Echo Request.

  • Proxy node (узел-посредник) – узел, на котором размещается proxy-интерфейс.

  • Probed interface (проверяемый интерфейс) – интерфейс, чей статус запрашивается.

  • Probed node (проверяемый узел) – узел, на котором размещается проверяемый интерфейс. Если проверяемый и посредничающий интерфейсы расположены на одном узле, узел посредник является и проверяемым узлом. В остальных случаях узел-посредник непосредственно соединен с проверяемым узлом.

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Запрос ICMP Extended Echo

Сообщение ICMP Extended Echo Request определено для ICMPv4 и ICMPv6. Подобно другим сообщениям ICMP, оно инкапсулируется с использованием заголовоков IP (версия ICMPv4 инкапсулируется в IPv4, версия ICMPv6 в IPv6).

На рисунке 1 показано сообщение ICMP Extended Echo Request.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |Sequence Number|   Reserved  |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Структура ICMP Extension

Рисунок 1. ICMP Extended Echo Request.


Поля заголовка IP

  • Source Address – адрес отправителя для проверяющего интерфейса. Поле должно содержать действительный индивидуальный адрес IPv4 или IPv6.

  • Destination Address – адрес получателя на интерфейсе-посреднике. Адрес должен быть индивидуальным.

Поля ICMP

  • Type – Extended Echo Request. Для ICMPv4 имеет значение 42, для ICMPv6 – 160.

  • Code – должен устанавливаться в 0 при передаче, на приемной стороне должен игнорироваться.

  • Checksum – для ICMPv4 см. RFC 792, для ICMPv6 – RFC 4443.

  • Identifier – идентификатор, служащий для сопоставления отклика с запросом. Может иметь значение 0.

  • Sequence Number – порядковый номер, служащий для сопоставления отклика с запросом. Может иметь значение 0.

  • Reserved – резервное поле, должно устанавливаться при передаче и игнорироваться при получении.

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

  • ICMP Extension Structure – структура, указывающая проверяемый интерфейс.

Определение ICMP Extension Structure дано в разделе 7 [RFC4884]. В соответствии с RFC 4884 эта структура включает одни заголовок Extension Header, за которым следует один или множество объектов. При использовании в сообщениях ICMP Extended Echo Request структура должна включать ровно один экземпляр Interface Identification Object (см. параграф 2.1).

Если бит L установлен, Interface Identification Object может указывать проверяемый интерфейс по имени, индексу или адресу. Если бит L сброшен, Interface Identification Object должен указывать адрес проверяемого интерфейса.

Если Interface Identification Object указывает адрес проверяемого интерфейса, этот адрес может относиться к любому семейству. Например, сообщение ICMPv4 Extended Echo Request может включать Interface Identification Object, указывающий проверяемый интерфейс адресом IPv4, IPv6 или IEEE 802. То же самое относится и к сообщениям ICMPv6 Extended Echo Request.

2.1. Объект идентификации интерфейса

Interface Identification Object указывает зондируемый интерфейс его именем, индексом или адресом. Подобно другим объектам ICMP Extension, этот идентификатор включает Object Header и Object Payload. Заголовок Object Header содержит следующие поля:

  • Class-Num – Interface Identification Object (3);

  • C-Type – значение 1 задает идентификацию интерфейса по имени, 2 – по индексу и 3 – по адресу;

  • Length – указывает размер объекта в октетах с учетом Object Header и Object Payload.

Если Interface Identification Object указывает интерфейс по имени, поле Object Payload должно содержать имя интерфейса в соответствии с [RFC7223]. Если Object Payload не завершается на 32-битовой границе, поле должно быть дополнено символами ASCII NULL.

Если Interface Identification Object указывает интерфейс индексом, поле length имеет значение 8, а поле данных содержит if-index [RFC7223].

Если Interface Identification Object указывает зондируемый интерфейс адресом, поле данных имеет вид, показанный на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            AFI                | Address Length|   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Address   ....

Рисунок 2. Interface Identification Object – C-Type 3.


Поля данных показаны ниже.

AFI4

Это 16-битовое поле указывает тип адреса в поле Address. Доступные значения приведены в реестре IANA Address Family Numbers.

Address Length

Число значимых байтов в поле Address (это поле может включать байты заполнения).

Reserved

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

Address

Это поле переменного размера представляет адрес, связанный с проверяемым интерфейсом. Если поле адреса не завершается на 32-битовой границе, оно должно быть дополнено нулями.

3. Отклик ICMP Extended Echo

Сообщения ICMP Extended Echo Reply определены для ICMPv4 и ICMPv6. Подобно остальным сообщениям ICMP, эти отклики инкапсулируются с использованием заголовка IP (ICMPv4 инкапсулируется в IPv4, ICMPv6 – в IPv6).

Сообщение ICMP Extended Echo Reply показано на рисунке 3.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |Sequence Number|State|Res|A|4|6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Сообщение ICMP Extended Echo Reply.

Поля заголовка IP

  • Source Address – копируется из поля Destination Address в заголовке Extended Echo Request.

  • Destination Address – копируется из поля Source Address в заголовке Extended Echo Request.

ICMP fields:

  • Type – Extended Echo Reply (для ICMPv4 имеет значение 43, для ICMPv6 – 161).

  • Code – может принимать значение 0 (No Error – нет ошибок), 1 (Malformed Query – непригодная форма запроса), 2 (No Such Interface – нет такого интерфейса), 3 (No Such Table Entry – нет такой записи в таблице) и 4 (Multiple Interfaces Satisfy Query – запросу соответствует множество интерфесов).

  • Checksum – для ICMPv4 см. RFC 792, для ICMPv6 – RFC 4443.

  • Identifier – копируется из поля Identifier соответствующего запроса Extended Echo.

  • Sequence Number – копируется из поля Sequence Number соответствующего запроса Extended Echo.

  • State – если поле Code отлично от 0, это поле должно иметь значение 0 и игнорироваться при получении. Если проверяемый интерфейс находится на узле-посреднике, это поле должно иметь значение 0 и игнорироваться при получении. В остальных случаях это поле отражает состояние таблицы ARP или записи Neighbor Cache, связанной с проверяемым интерфейсом. Состояние может указываться значением 0 (Reserved – резерв), 1 (Incomplete – неполная запись), 2 (Reachable – доступен), 3 (Stale – устарел), 4 (Delay – задержка), 5 (Probe – проба) или 6 (Failed – отказ).

  • Res – это поле должно устанавливаться в 0 и игнорироваться приемной стороной.

  • A (Active) – бит A устанавливается, если Code = 0, проверяемый интерфейс размещен на узле-посреднике и активен. В остальных случаях флаг A сбрасывается.

  • 4 (IPv4) – бит 4 устанавливается при установленном флаге A, если проверяемый интерфейс относится к IPv4.

  • 6 (IPv6) – бит 6 устанавливается при установленном флаге A, если проверяемый интерфейс относится к IPv6.

4. Обработка сообщений ICMP

Когда узел получает сообщение ICMP Extended Echo Request и выполняется любое из приведенных ниже условий, узел должен отбросить это сообщение, не уведомляя об этом отправителя.

  • Узел не понимает сообщений ICMP Extended Echo Request.

  • На узле явно не включена функциональность ICMP Extended Echo.

  • Входящий запрос ICMP Extend Echo содержит адрес отправителя (Source Address), который не уполномочен явно устанавливать флаг L в сообщениях ICMP Extended Echo Request.

  • Входящий запрос ICMP Extend Echo содержит адрес отправителя (Source Address), который не уполномочен явно для указанного типа ICMP Extended Echo Request (т. е. ifName, IfIndex или Address).

  • Поле Source Address во входящем сообщении содержит адрес, не являющийся индивидуальным.

  • Поле Destination Address во входящем сообщении содержит групповой адрес.

В остальных случаях получивший ICMPv4 Extended Echo Request узел должен сформировать сообщение ICMP Extended Echo Reply как показано ниже:

  • установлен флаг DF5 (1);

  • флаг More Fragments сброшен (0);

  • Fragment Offset = 0;

  • TTL = 255;

  • Protocol = ICMP.

Получивший сообщение ICMPv6 Extended Echo Request узел должен создать отклик ICMPv6 Extended Echo Reply :

  • Hop Limit = 255

  • Next Header – ICMPv6

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

  • Скопировать поле Source Address из сообщения Extended Echo Request в поле Destination Address отклика Extended Echo Reply.

  • Скопировать поле Destination Address из сообщения Extended Echo Request в поле Source Address отклика Extended Echo Reply.

  • Установить для кода DiffServ значение CS0 [RFC4594].

  • Установить для ICMP Type значение Extended Echo Reply.

  • Скопировать поле Identifier из сообщения Extended Echo Request в сообщение Extended Echo Reply.

  • Скопировать поле Sequence Number из сообщения Extended Echo Request в сообщение Extended Echo Reply.

  • Установить поле Code в соответствии с параграфом 4.1.

  • Установить в поле State значение 0.

  • Сбросить флаги A, 4 и 6.

  • Если (1) поле Code имеет значение 0 (нет ошибок), (2) флаг L установлен и (3) проверяемый интерфейс активен, установить бит A и один из битов 4 и 6.

  • Если (1) поле Code имеет значение 0 (нет ошибок), а бит L сброшен, значение поля State установить в соответствии с состоянием талицы ARP или записи Neighbor Cache для проверяемого интерфейса.

  • Установить подобающее значение поля Checksum.

  • Отправить сообщение ICMP Extended Echo Reply получателю.

4.1. Обработка поля Code

В поле Code должно устанавливаться значение 1 (Malformed Query) при выполнении любого из условий:

  • запрос ICMP Extended Echo Request не включает ICMP Extension Structure;

  • структура ICMP Extension Structure не включает ровно один Interface Identification Object;

  • бит L сброшен, а Interface Identification Object указывает проверяемый интерфейс по ifName или ifIndex;

  • иные ошибки в форме запроса.

В поле Code должно устанавливаться значение 2 (No Such Interface), если флаг L и ICMP Extension Structure не указывают интерфейс, размещенный на узле-посреднике.

В поле Code должно устанавливаться значение 3 (No Such Table Entry), если флаг L сброшен, а адрес, указанный в Interface Identification Object, не присутствует в таблице IPv4 ARP или IPv6 Neighbor Cache.

В поле Code должно устанавливаться значение 4 (Multiple Interfaces Satisfy Query) при выполнении любого из условий:

  • флаг L установлен, а ICMP Extension Structure указывает более одного интерфейса на узле-посреднике;

  • флаг L сброшен, а адрес, указанный в Interface Identification Object, отображается на несколько записей IPv4 ARP или IPv6 Neighbor Cache.

В остальных случаях для поля Code должно устанавливаться значение 0 (No Error).

5. Примеры использования

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

  • Проверяемый интерфейс не имеет адреса (unnumbered).

  • Проверяющий и проверяемый интерфейс не соединены между собой напрямую. Проверяемый интерфейс имеет адрес IPv6 link-local, но не имеет адрес с глобальной значимостью.

  • Проверяющий интерфейс поддерживает только IPv4, а проверяемый – только IPv6.

  • Проверяющий интерфейс поддерживает только IPv6, а проверяемый – только IPv4.

  • По причине отсутствия маршрута проверяющий интерфейс не может достигнуть проверяемого.

6. Обновление RFC 4884

В параграфе 4.6 [RFC4884] приведен список расширяемых сообщений ICMP (Т. е. сообщений, которые могут включать структуру ICMP Extension). Этот документ добавляет в список сообщения ICMP Extended Echo Request и ICMP Extended Echo Reply.

7. Взаимодействие с IANA

Агентство IANA выполнило перечисленные ниже действия.

  • Добавлена а запись в реестр ICMP Type Numbers

    42 Extended Echo Request

    Добавлена запись в субреестр Type 42 – Extended Echo Request

    (0) No Error

  • Добавлена а запись в реестр ICMPv6 ‘type’ Numbers

    160 Extended Echo Request

    В ICMPv6 различаются информационные сообщения и сообщения об ошибках. Данное сообщение является информационным и его значение должно относиться к диапазону 128-255.

    Добавлена запись в субреестр Type 160 – Extended Echo Request

    (0) No Error

  • Добавлена а запись в реестр ICMP Type Numbers

    43 Extended Echo Reply

    Добавлена запись в субреестр Type 43 – Extended Echo Reply

    (0) No Error

    (1) Malformed Query

    (2) No Such Interface

    (3) No Such Table Entry

    (4) Multiple Interfaces Satisfy Query

  • Добавлена а запись в реестр ICMPv6 ‘type’ Numbers

    161 Extended Echo Reply

    В ICMPv6 различаются информационные сообщения и сообщения об ошибках. Данное сообщение является информационным и его значение должно относиться к диапазону 128-255.

    Добавлена запись в субреестр Type 161 – Extended Echo Reply

    (0) No Error

    (1) Malformed Query

    (2) No Such Interface

    (3) No Such Table Entry

    (4) Multiple Interfaces Satisfy Query

  • Добавлена а запись в реестр ICMP Extension Object Classes and Class Sub-types

    (3) Interface Identification Object

    Добавлены перечисленные ниже C-типы в субреестр Sub-types – Class 3 – Interface Identification Object

    (0) Reserved

    (1) Identifies Interface by Name

    (2) Identifies Interface by Index

    (3) Identifies Interface by Address

    Значения C-Type выделяются по процедуре FCFS6 из диапазона 0-255.

Все указанные выше значения кодов выделены по процедуре FCFS из диапазона 0-255.

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

Утилиту PROBE легитимно можно применять для определения

  • рабочего состояния интерфейса;

  • активных на интерфейсе протоколов (например, IPv4 или IPv6).

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

  • пропускную способность интерфейса;

  • тип устройства, поддерживающего интерфейс (например, его производителя);

  • версию операционной системы, используемой устройством.

С учетом этих рисков операторам следует создать правила, ограничивающие доступ к функциональности ICMP Extended Echo. Для выполнения этих правил поддерживающие ICMP Extended Echo узлы должны иметь перечисленные ниже конфигурационные опции.

  • Включение и отключение функциональности ICMP Extended Echo (по умолчанию отключена).

  • Определение возможностей установки бита L (по умолчанию установка разрешена, сброс запрещен).

  • Определение разрешенных типов запросов – имя, индекс, адрес (по умолчанию все отключено).

  • Для каждого разрешенного типа запросов определение префиксов, с которых принимаются запросы ICMP Extended Echo Request.

  • Для каждого интерфейса управление восприятием сообщений ICMP Echo Request.

При получении узлом запроса ICMP Extended Echo, поддержка которого не разрешена, сообщение должно отбрасываться без уведомления отправителя (см. раздел 4).

При использовании PROBE недопустима утечка информации о VPN7 в другие сети VPN. Поэтому при получении узлом запроса ICMP Extended Echo для проверяемого интерфейса, относящегося к другой VPN, нежели интерфейс-посредник, узел должен возвращать отклик ICMP Extended Echo с кодом 2 (No Such Interface).

Для защиты локальных ресурсов реализациям следует ограничивать скорость входящих сообщений ICMP Extended Echo Request.

9. Литература

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

[RFC792] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC826] Plummer, D., “Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware”, STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, “Extended ICMP to Support Multi-Part Messages”, RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.

[RFC7223] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 72238, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

[RFC2151] Kessler, G. and S. Shepard, “A Primer On Internet and TCP/IP Tools and Utilities”, FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997, <https://www.rfc-editor.org/info/rfc2151>.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes”, RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.

Приложение A. Программа PROBE

Приложение PROBE принимает входные параметры, устанавливает счетчик и запускает цикл с выходом по нулевому значению счетчика. В каждом шаге цикла PROBE передает одно сообщение ICMP Extended Echo Request, декрементирует счетчик, запускает таймер и ждет. Запрос ICMP Extended Echo Request включает идентификатор и порядковый номер.

Если полученное в ответ сообщение ICMP Extended Echo Reply содержит такие же значения Identifier и Sequence Number, программа PROBE возвращает полученную информацию пользователю. Однако в каждом шаге цикла PROBE ждет завершения отсчета таймера, независимо от получения отклика Extended Echo.

Программа PROBE принимает следующий параметры:

  • счетчик;

  • время ожидания;

  • адрес проверяющего интерфейса;

  • счетчик интервалов маршрутизации (hop);

  • адрес интерфейса-посредника;

  • значение бита L;

  • идентификатор проверяемого интерфейса.

Счетчик указывается положительным целым числом (по умолчанию 3) и определяет число итераций упомянутого выше цикла PROBE.

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

Адрес проверяющего интерфейса задает поле Source Address в пакете ICMP Extended Echo Request. Это должен быть индивидуальный (unicast) адрес интерфейса проверяющего узла.

Адрес интерфейса-посредника указывает интерфейс, которому передается сообщение ICMP Extended Echo Request. Это должен быть индивидуальный адрес IPv4 или IPv6. Для адреса IPv4 программа PROBE будет передавать сообщение ICMPv4, для IPv6 – сообщение ICMPv6.

Бит L указывается логическим значением (TRUE для случая размерщения проверяемого интерфейса и посредника на одном узле, FALSE в противном случае).

Идентификатор проверяемого интерфейса указывает этот интерфейс с помощью

  • имени;

  • адреса из любого семейства (например, IPv4, IPv6, IEEE 802, 48-битовый MAC, 64-битовый MAC);

  • if-index.

Если идентификатором проверяемого интерфейса является адрес, он не обязан относиться к тому же семейству адресов, что и адрес интерфейса-посредника. Например, PROBE принимает адрес IPv4 для посредника и IPv6 для проверяемого узла.

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

Спасибо Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan Looney, Dave Thaler, Mikio Hara, Joel Halpern, Yaron Sheffer, Stefan Winter, Jean-Michel Combes, Amanda Barber и Joe Touch за рецензирование документа.

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

Ron Bonica

Juniper Networks

2251 Corporate Park Drive

Herndon, Virginia 20171

United States of America

Email: rbonica@juniper.net

Reji Thomas

Juniper Networks

Elnath-Exora Business Park Survey

Bangalore, Karnataka 560103

India

Email: rejithomas@juniper.net

Jen Linkova

Google

1600 Amphitheatre Parkway

Mountain View, California 94043

United States of America

Email: furry@google.com

Chris Lenart

Verizon

22001 Loudoun County Parkway

Ashburn, Virginia 20147

United States of America

Email: chris.lenart@verizon.com

Mohamed Boucadair

Orange

Rennes 35000

France

Email: mohamed.boucadair@orange.com


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

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

nmalykh@gmail.com


1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Address Resolution Protocol – протокол преобразования адресов.

4Address Family Identifier – идентификатор семейства адресов.

5Don’t Fragment – не фрагментировать.

6First Come First Serve – обслуживание в порядке очередности запросов.

7Virtual Private Network – виртуальная частная сеть.

8Заменен RFC 8343. Прим. перев.