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

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

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

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

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

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

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

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

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

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

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

Сервис Ack Ratio

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

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

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

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

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

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

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

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

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

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

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

DCCP и RTP

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

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

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

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