4.4.3.4 Протокол DCCP

1.1. Основные отличия от TCP

Ниже рассмотрены наиболее существенные отличия DCCP от TCP.

• Поток пакетов. DCCP является протоколом для потоков пакетов, а не потоков байт.
• Ненадежность. DCCP никогда не пересылает дейтограммы повторно.
• Порядковые номера пакетов. Порядковые номера относятся к пакетам, а не байтам. Каждому пакету, посылаемому DCCP, присваивается новый порядковый номер, это относится и к пакетам подтверждений. Это позволяет получателю пакетов DCCP детектировать потери подтверждений; смотри раздел “Sequence Number Validity” в [DCCP].
• Обширное пространство для опций (до 1020 байт).
• Согласование параметров. Это является базовым механизмом, с помощью которого партнеры согласуют значения параметров или свойства соединения.
• Выбор управления перегрузкой. Партнеры могут использовать разные механизмы управления перегрузкой. В соединении A<- >B, информационные пакеты, посланные от A->B могут использовать алгоритм CCID 2, а пакеты данных от B->A могут использовать CCID 3.
• Различные форматы подтверждений. CCID-соединения определяет то, какой объем данных должен быть передан в ack. В CCID 2 (TCP-подобном), посылается один ack на 2 пакета, а каждый ack должен оповещать, какие конкретно пакеты получены (опция Ack Vector); в CCID 3 (TFRC), посылается в среднем один ack за время RTT, а ack должны сообщать как минимум о длинах последних интервалов потерь.
• Отсутствие приемного окна. DCCP является протоколом управления перегрузкой, а не протоколом управления потоками.
• Разделение различных видов потерь. Опция потерянных данных (Data Dropped) позволяет одному из партнеров сообщить, что пакет был потерян из-за повреждения, переполнения входного буфера и т.д..
• Определение подтверждения. В TCP получение пакетов подтверждается, только когда они ставятся в очередь для передачи приложению. В протоколе DCCP это делается не так. Получение пакета подтверждается, когда обработаны поля его опций.
• Встроенная поддержка мобильности.

2. Основные понятия и термины

Каждое DCCP соединение реализуется между двумя партнерами, которые будут называться DCCP A и DCCP B. Данные могут передаваться в обоих направлениях. В рамках протокола рассматриваются субнаборы соединений, называемых полусоединениями (half-connection - HC). Смотри рис. 1. Эти полусоединения обеспечивают передачу информационных пакетов в одном направлении, плюс соответствующие подтверждения в противоположном направлении. В контексте одного полусоединения, HC-отправитель является партнером отправителем данных, в то время как HC-Receiver является партнером, посылающим подтверждения. Каждое полусоединение контролируется механизмом управления перегрузкой, специфицированным однобайтовым идентификатором, или CCID (Congestion Control ID). Партнеры согласуют режим обмена на фазе формирования соединения. CCID для полусоедиения описывает, как HC-отправитель ограничивает поток информационных пакетов; как он поддерживает необходимые значения параметров, такие как окна перегрузки; как HC-получатель уведомляет отправителя о перегрузке, посылая подтверждения; и как он поддерживает частоту подтверждений.

Рис. 1. Структура обменов в протоколе DCCP

2.1. Инициация и разрыв соединения

Любое соединение DCCP предполагает формирование DCCP сокетов в пассивном состоянии прослушивания. Активной стороной считается клиент, а роль пассивной стороны выполняет сервер.

2.2. Характеристики

DCCP имеет встроенный механизм согласования параметров соединения, такой как активные CCID для обеих полусоединений (см. рис. 1). Опции Change, Prefer и Confirm служат для согласования параметров. Change посылается с целью изменения определенного параметра. Адресат может откликнуться, послав Prefer, где запросит партнера заменить значение параметра, или может изменить значение параметра и послать подтверждение Confirm. Надежность установления параметров обеспечивается повторной передачей, если это потребуется.

3. Пакеты DCCP

Протокол DCCP использует девять различных типов пакетов: DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, DCCP-Reset, и DCCPMove. Длина пакета DCCP варьируется в пределах от 12 до 1020 байт. Алгоритм формирования и разрыва DCCP соединения подразумевает следующие обмены.

DCCP-Request

Посылается клиентом для инициализации соединения (первый шаг трехходовой процедуры).

DCCP-Response

Посылается сервером в ответ на запрос DCCP-Request (второй этап трехшаговой процедуры инициации соединения).

DCCP-Data

Используется для передачи прикладных данных.

DCCP-Ack

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

DCCP-DataAck

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

DCCP-CloseReq

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

DCCP-Close

Используется клиентом или сервером для закрытия соединения; для запуска процедуры сброса (DCCP-Reset).

DCCP-Reset

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

DCCP-Sync, DCCP-SyncAck

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

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

1. Клиент посылает серверу пакет DCCP-Request, специфицируя номера портов клиента и сервера, запрашиваемый сервис, и любые параметры, подлежащие согласованию, включая CCID, который должен использовать сервер при работе с клиентом. Клиент может опционно подключать к пакету DCCP-Request некоторые данные.
2. Сервер посылает клиенту пакет-отклик, уведомляя его о своем желании осуществить обмен данными. В отклике указываются любые особенности и опции, которые предлагает сервер. Опционно отклик может содержать Init Cookie.
3. Клиент посылает серверу пакет DCCP-Ack, который подтверждает получение пакета DCCP-отклика.
4. Далее следуют обмен нулем или более подтверждениями DCCP-Ack, если требуется завершить согласование используемых параметров.
5. Сервер и клиент обмениваются пакетами DCCP-Data, DCCP-Ack. Если у клиента нет данных, тогда сервер посылает пакеты DCCP-Data и DCCP-DataAck, в то время как клиент будет посылать только DCCP-Acks.
6. Сервер посылает пакет DCCP-CloseReq, запрашивая закрытие соединения.
7. Клиент посылает пакет DCCP-Close, подтверждая закрытие.
8. Сервер посылает пакет DCCP-Reset, в котором поле причина содержит "Closed", при этом состояние соединения ликвидируется.
9. Клиент получает пакет DCCP-Reset и сохраняет свое состояние в течение некоторого времени для завершения происходящих обменов.

4. Форматы пакетов
4.1. Базовый заголовок пакета

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

Рис. 2. Базовый заголовок пакетов 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 бита)

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

Таблица 1. Типы пакетов DCCP

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

Расширенные порядковые номера (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 бита

На рис. 2А показан формат базового паета DCCP при Х=0.

Рис. 2A. Базовый заголовок пакетов DCCP при Х=0

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

Каждому механизму управления перегрузкой, поддерживаемому DCCP, присвоен идентификатор, или CCID: номер в диапазоне от 0 до 255. Во время установления соединения и опционно после этого, партнеры согласуют свои механизмы управления перегрузкой. ID управления перегрузкой имеет код 1. Величина CCID/A равна CCID, используемому для полусоедиения A →B. 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.

Таблица 2. Идентификаторы управления перегрузкой DCCP

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

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

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

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

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

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

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

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

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

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

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

4.4.2. Форматы пакетов DCCP-Data, DCCP-Ack и DCCP-DataAck

Поле данных DCCP соединения пересылается в пакетах DCCP-Data и DCCP-DataAck, в то время как пакеты DCCP-Ack используются для подтверждений, когда не требуется передавать какой-либо информации. Пакеты DCCP-Ack не содержат данных, но имеют номера подтверждений.

Рис. 6. Формат пакета DCCP-Data

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

5. Опции и характеристики

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

Таблица 3. Опции

5.1. Числовые характеристики

Первый байт данных каждой опции Change, Prefer или Confirm является числовым параметром, определяющим тип согласуемого параметра. Остальные данные представляют собой одно или более значение параметра, и интерпретируется в соответствии с особенностями данного параметра (характеристики). В настоящее время определены следующие параметры:

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

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

6.1. Сервис Ack Ratio

Ack Ratio предоставляет общий механизм, с помощью которого CCID, определяющий время подтверждения информационных пакетов, может выполнять упрощенное управление перегрузкой. CCID 2, TCP-подобное управление перегрузкой, использует Ack Ratio, чтобы ограничить частоту подтверждений. Некоторые CCID игнорируют Ack Ratio, выполняя управление перегрузкой для подтверждений каким-то другим способом.

4.6.2. Опция медленного получателя

HC-Получатель посылает опцию Slow Receiver (медленный получатель) своему отправителю, чтобы уведомить его о проблемах с обработкой его данных.

6.3. Опция отброшенных данных

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

6.4. Опция контрольной суммы поля данных

Опция контрольной суммы поля данных содержит в себе 16 битное дополнение по модулю 1 суммы всех 16-битных слов, содержащихся в поле данных DCCP (информации, транспортируемой пакетами DCCP-Request, DCCP-Response, DCCP-Data, DCCP-DataAck или DCCP-Move). В сочетании с длиной контрольной суммы меньше 15, это позволяет различить случаи повреждения заголовка и поля данных пакета. Пакеты с поврежденным заголовком должны рассматриваться как отброшенные сетью, в то время как пакеты с поврежденным полем данных могут обрабатываться дифференцированно, например, реакция отправителя на повреждение может быть менее жесткой, чем на перегрузку.

7. Многодомность и мобильность

Протокол DCCP осуществляет простую поддержку многодомности и мобильности за счет механизма переадресации партнеров. Мобильный партер должен согласовать поддержку мобильности заранее. Когда мобильный партнер получает новый адрес, он посылает пакет DCCP-Move с этого адреса стационарной станции. Стационарная станция изменяет состояние соединения с учетом изменившегося адреса партнера. Поддержка DCCP мобильности призвана решить лишь простейшие проблемы многодомности и мобильности. Например, DCCP не имеет поддержки одновременного перемещения партнеров. Приложениям, где требуется более сложная семантика мобильности, или более сильные гарантии безопасности, следует использовать существующие решения, подобные Mobile IP или [SB00].

8. Мультиплексирование

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

9. DCCP и RTP

Транспортный протокол реального времени, RTP [RFC 1889], в настоящее время используется (поверх UDP) многими приложениями DCCP. Существует два потенциальных источника избыточности в комбинации RTP-поверх-DCCP, задублированные данные подтверждения и задублированные порядковые номера. Этот источник избыточности добавляет 4 байта на пакет по отношению к RTP-поверх-UDP. Однако конкретные CCID могут использовать место, занимаемое порядковым номером RTP.

10. Соображения безопасности

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

Текущий список Интернет-проектов, в том числе по направлению DCCP, доступен по адресу http://www.ietf.org/ietf/1id-abstracts.txt.

11. Ссылки