Протокол передачи команд и сообщений об ошибках (ICMP). Протоколы DCCP и TFRC

Форматы пакетов

Базовый заголовок пакета

Все DCCP пакеты имеют базовый заголовок с форматом, показанным на рис. 3.13.

Рис. 3.13. Базовый заголовок пакетов DCCP

Если X равно нулю, передаются только младшие (LSB) 24 бита порядкового номера, а базовый заголовок имеет длину 12 байт. Ниже поясняется назначение полей базового заголовка.

Порт отправителя и получателя (по 16 бит каждый)

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

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

Смещение данных (8 бит)

Смещение от начала заголовка пакета DCCP первого октета прикладных данных (выражается в 32-битных словах). Получатель должен игнорировать пакеты, где значение поля Data Offset (смещение данных) меньше минимального размера заголовка для данного типа или больше размера самого пакета DCCP.

CCVal (4 бита)

Используется HCотправителем CCID. Например, CCID отправителя A-B, который активен в DCCP A, может послать 4 бита данных с каждым пакетом получателю, записав их в поле CCVal. Отправитель должен установить CCVal равным нулю, если только HCотправитель CCID не требует иного, а получатель должен игнорировать поле CCVal, если HCполучатель CCID не специфицирует обратного.

Checksum Coverage (CsCov - покрытие контрольным суммированием): 4 бита.

Поле CsCov определяет части пакета, которые покрываются полем контрольная сумма. Она всегда покрывает заголовок и опции DCCP, но некоторые приложения могут допускать исключения. Это может улучшить работу протокола в условиях каналов с высоким уровнем шума.

Контрольная сумма (16 бит)

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

Зарезервировано (Res) (3 бита)

Отправитель должен записать в это поле все нули, а получатель должен это поле игнорировать.

Тип (4 бита)

Поле тип специфицирует тип пакета. Определены следующие типы пакетов:

Адресаты должны игнорировать любые пакеты с зарезервированным типом.

Расширенные порядковые номера (X). 1 бит

Если Х=1, в заголовке используются 48-разрядные порядковые номера. Пакеты DCCP-Data, DCCP-DataAck и DCCP-Ack могут иметь значение X, равное 0 или 1. Все пакеты DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync и DCCP-SyncAck должны иметь Х=1 ; партнеры должны игнорировать любые такие пакеты с Х=0. При высокоскоростных соединениях следует использовать для всех пакетов Х=1.

Порядковый номер. 48 или 24 бита

Идентифицирует пакет в последовательности. Номер по порядку увеличивается на 1 после посылки каждого пакета, включая пакеты DCCP-Ack, которые не несут в себе прикладных данных.

Каждому механизму управления перегрузкой, поддерживаемому DCCP, присвоен идентификатор, или CCID: номер в диапазоне от 0 до 255. Во время установления соединения (и опционно после этого) партнеры согласуют свои механизмы управления перегрузкой. ID управления перегрузкой имеет код 1. Величина CCID/A равна CCID, используемому для полусоедиения . DCCP B посылает опцию "Change R(CCID, K)", чтобы DCCP A применял для своих информационных пакетов CCID K.

CCID является характеристикой сервера, при согласовании CCIDопций может использоваться список из нескольких приемлемых CCID, записанных в убывающем порядке по приоритету. Например, опция "Change R(CCID, 2 3 4)" просит получателя применять для своих пакетов CCID 2, хотя CCID 3 и 4 также являются приемлемыми. (Это соответствует байтам "35, 6, 1, 2, 3, 4": Change R опция <35>, длина опции <6>, ID код <1>, CCID (2, 3, 4) ). Аналогично, "Confirm L(CCID, 1, 2 3 4)" говорит получателю, что отправитель использует для своих пакетов CCID 2, но что CCID 3 и 4 могут быть также приемлемыми. В настоящее время стандартизованы следующие значения CCID:

Все определенные в настоящее время типы пакетов, за исключением DCCP-запрос и DCCP-Data, содержат в себе субзаголовок номера подтверждения в четырех или восьми байтах, следующих за базовым заголовком. Когда X=1, он имеет формат, показанный на рис. 3.14.

Рис. 3.14. Формат подзаголовка номера подтверждения

Клиент инициирует DCCP соединение, посылая пакет запроса. Эти пакеты могут содержать прикладные данные и должны иметь 48-битные порядковые номера ( X=1 ).

Рис. 3.15. Формат пакета DCCP-запроса

Код сервиса: 32 бита

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

Сервер откликается на корректный DCCP-запрос пакетом DCCP-отклика. Это является второй фазой трехходового диалога. Пакеты DCCP-отклика могут содержать прикладные данные и должны использовать 48-битные порядковые номера ( X=1 ).

Рис. 3.16. Формат пакета DCCP-отклика

Номер подтверждения имеет 48 бит

Содержит GSR (Greatest Sequence Number Received - наибольший полученный порядковый номер). Так как DCCP-отклик посылается только во время установления соединения, он всегда равен порядковому номеру полученного DCCP-запроса.

Код сервиса: 32 бита

Должен равняться коду сервиса, соответствующему DCCP-запросу.