Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Тезисы
Datagram Congestion Control Protocol представляет собой транспортный протокол, который обеспечивает двухсторонние индивидуальные (unicast) соединения для передачи дейтаграмм с контролем насыщения но без обеспечения гарантий доставки. Протокол DCCP подходит для приложений, которые передают достаточно большие объемы данных и могут получить преимущества в результате контроля выбора между своевременностью и надежностью.
Оглавление
- 1. Введение
- 2. Обоснование задач
- 3. Уровни требований
- 3.1. Числа и поля
- 3.2. Участники соединения
- 3.3. Признаки
- 3.4. Время кругового обхода
- 3.5. Ограниченность защиты
- 3.6. Отказоустойчивость
- 4. Обзор
- 4.1. Типы пакетов
- 4.2. Упорядочивание пакетов
- 4.3. Состояния
- 4.4. Механизмы контроля насыщения
- 4.5. Опции согласования признаков
- 4.6. Отличия от TCP
- 4.7. Пример соединения
- 5. Формат пакетов
- 5.1. Базовый заголовок
- 5.2. Пакеты DCCP-Request
- 5.3. Пакеты DCCP-Response
- 5.4. Пакеты DCCP-Data, DCCP-Ack и DCCP-DataAck
- 5.5. Пакеты DCCP-CloseReq и DCCP-Close
- 5.6. Пакеты DCCP-Reset
- 5.7. Пакеты DCCP-Sync и DCCP-SyncAck
- 5.8. Опции
- 5.8.1. Опция Padding
- 5.8.2. Опция Mandatory
- 6. Согласование признаков
- 6.1. Опции Change
- 6.2. Опции Confirm
- 6.3. Правила согласования
- 6.3.1. Приоритет сервера
- 6.3.2. Согласование не используется
- 6.4. Номера признаков
- 6.5. Примеры согласования признаков
- 6.6. Обмен опциями
- 6.6.1. Нормальный обмен
- 6.6.2. Обработка полученных опций
- 6.6.3. Потеря и повторная передача пакетов
- 6.6.4. Нарушение порядка доставки
- 6.6.5. Смена предпочтений
- 6.6.6. Одновременное согласование
- 6.6.7. Неизвестные признаки
- 6.6.8. Некорректные опции
- 6.6.9. Согласование обязательных признаков
- 7. Порядковые номера
- 7.1. Переменные
- 7.2. Начальные порядковые номера
- 7.3. Пауза (Quiet Time)
- 7.4. Номера подтверждений
- 7.5. Корректность номеров и синхронизация
- 7.5.1. Окна порядковых номеров и номеров подтверждений
- 7.5.2. Признак Sequence Window
- 7.5.3. Правила проверки корректности номеров
- 7.5.4. Обработка пакетов с некорректными номерами
- 7.5.5. Атаки на порядковые номера
- 7.5.6. Примеры обработки порядковых номеров
- 7.6. Короткие порядковые номера
- 7.6.1. Признак Allow Short Sequence Numbers
- 7.6.2. Когда не следует использовать короткие порядковые номера
- 7.7. Опция NDP Count и детектирование потери данных приложения
- 7.7.1. Использование NDP Count
- 7.7.2. Признак Send NDP Count
- 8. Обработка событий
- 8.1. Организация соединения
- 8.1.1. Запрос клиента
- 8.1.2. Коды сервиса
- 8.1.3. Отклик сервера
- 8.1.4. Опция Init Cookie
- 8.1.5. Завершение согласования
- 8.2. Передача данных
- 8.3. Разрыв соединения
- 8.3.1. Аварийное завершение
- 8.4. Диаграмма состояний DCCP
- 8.5. Псевдокод
- 9. Контрольные суммы
- 9.1. Поле Checksum в заголовке
- 9.2. Поле заголовка Checksum Coverage
- 9.2.1. Признак Minimum Checksum Coverage
- 9.3. Опция Data Checksum
- 9.3.1. Признак Check Data Checksum
- 9.3.2. Использование контрольных сумм
- 10. Контроль насыщения
- 10.1. Контроль насыщения в стиле TCP
- 10.2. Контроль насыщения TFRC
- 10.3. Опции, признаки и коды сброса, связанные с CCID
- 10.4. Требования к профилям CCID
- 10.5. Состояние насыщения
- 11. Подтверждения
- 11.1. Подтверждения подтверждений и односторонние соединения
- 11.2. Добавление подтверждений
- 11.3. Признак Ack Ratio
- 11.4. Опции Ack Vector
- 11.4.1. Согласованность Ack Vector
- 11.4.2. Покрытие Ack Vector
- 11.5. Признак Send Ack Vector
- 11.6. Опция Slow Receiver
- 11.7. Опция Data Dropped
- 11.7.1. Отклик на Data Dropped и обычный отклик на перегрузку
- 11.7.2. Отдельные значения Drop Code
- 12. Явное уведомление о насыщении
- 12.1. Признак ECN Incapable
- 12.2. Сигналы ECN Nonce
- 12.3. Наказания за агрессию
- 13. Опции синхронизации
- 13.1. Опция Timestamp
- 13.2. Опция Elapsed Time
- 13.3. Опция Timestamp Echo
- 14. Максимальный размер пакета
- 14.1. Измерение PMTU
- 14.2. Поведение отправителя
- 15. Совместимость с будущими версиями
- 16. Промежуточные устройства
- 17. Отношения с другими спецификациями
- 17.1. RTP
- 17.2. Congestion Manager и мультиплексирование
- 18. Вопросы безопасности
- 18.1. Вопросы безопасности для неполных контрольных сумм
- 19. Согласование с IANA
- 19.1. Реестр типов пакетов
- 19.2. Реестр кодов сброса
- 19.3. Реестр типов опций
- 19.4. Реестр номеров признаков
- 19.5. Реестр идентификаторов контроля насыщения
- 19.6. Реестр состояний Ack Vector
- 19.7. Реестр значений Drop Code
- 19.8. Реестр кодов сервиса
- 19.9. Реестр номеров портов
- 20. Благодарности
- Приложение A. Реализация Ack Vector
- A.1. Получение пакетов
- A.1.1. Новые пакеты
- A.1.2. Старые пакеты
- A.2. Отправка подтверждений
- A.3. Clearing State
- A.4. Обработка подтверждений
- Приложение B. Partial Checksumming Design Motivation
- Нормативные документы
- Дополнительная литература
1. Введение
DCCP представляет собой транспортный протокол, который обеспечивает двухсторонние индивидуальные (unicast) соединения для передачи дейтаграмм с контролем насыщения но без обеспечения гарантий доставки. В частности, DCCP обеспечивает следующие возможности:
- поддержка потоков дейтаграмм без гарантий доставки;
- гарантированное согласование параметров при организации и разрыве соединений;
- гарантированное согласование опций, включая выбор подходящего механизма контроля насыщения;
- механизмы, позволяющие серверам предотвратить сохранение состояния для неподтвержденных попыток организации соединений и завершенных соединений;
- контроль насыщения, включающий механизмы ECN [RFC3168] и ECN Nonce [RFC3540];
- механизм подтверждений, обеспечивающий сигналы о потере пакетов и информацию ECN; подтверждения передаются с таким уровнем надежности, который требуется механизмом контроля насыщения (включая полную гарантию доставки);
- дополнительные механизмы, обеспечивающие (с высоким уровнем надежности) передающее приложение информацией о доставке пакетов получателю, установке маркеров ECN, повреждении или отбрасывании пакетов;
- механизм определения PMTU [RFC1191].
- выбор модулей механизма контроля насыщения; в настоящее время поддерживаются два механизма — контроль насыщения в стиле TCP [RFC4341] и TFRC [RFC4342]; протокол DCCP легко расширяется с точки зрения поддержки новых механизмов контроля насыщения для unicast-пакетов.
Протокол DCCP предназначен для потоковых приложений и других задач, которые могут получить преимущества в результате использования контроля за счет возможности выбора между величиной задержки и надежной доставкой с соблюдением порядка. Протокол TCP не подходит для таких приложений, поскольку используемые в нем механизмы контроля насыщения и обеспечения гарантий упорядоченной доставки могут приводить к произвольно долгим задержкам. Протокол UDP избавляется от длительных задержек, но приложения UDP, поддерживающие контроль насыщения, делают это на свой страх и риск. Протокол DCCP поддерживает средства контроля насыщения, включая ECN, для потоков дейтаграмм без гарантий доставки но и без произвольно долгих задержек, присущих TCP. Протокол также поддерживает организацию, согласование параметров и разрыв соединений с гарантированной доставкой.