Статус документа
Данный документ содержит стандарт протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе "Internet Official Protocol Standards" (STD 1). Документ можно распространять без ограничений.
Тезисы
Данный документ описывает протокол UDP-Lite, подобный протоколу UDP (User Datagram Protocol — протокол пользовательских дейтаграмм, RFC 768), но может также обслуживать в склонных к ошибкам сетевых средах приложения, которые предпочитают получать частично подтвержденные дейтаграммы, но не отбрасывать пакеты при любой ошибке. Если это свойство не использовать, UDP-Lite семантически идентичен протоколу UDP.
Оглавление
- 1. Введение
- 2. Терминология
- 3. Описание протокола
- 3.1. Поля
- 3.2. Псевдозаголовок
- 3.3. Интерфейс с приложением
- 3.4. Интерфейс с IP
- 3.5. Джамбограммы
- 4. Нижележащий уровень
- 5. Совместимость с UDP
- 6. Вопросы безопасности
- 7. Согласование с IANA
- 8. Литература
- 8.1. Нормативные документы
- 8.2. Дополнительная литература
- 9. Благодарности
1. Введение
Этот документ описывает новый транспортный протокол UDP-Lite, известный также, как UDPLite. Основой нового протокола служат три наблюдения:
Во первых, существует класс приложений, которые получат преимущества, если поврежденные данные будут доставляться, а не отбрасываться. Множество кодеков для голова и видео относятся к этому классу (например, кодек речи AMR [RFC-3267], кодек Internet Low Bit Rate Codec [ILBRC], устойчивые к ошибкам видеокодеки H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], MPEG-4 [ISO-14496]). Эти кодеки могут разрабатываться так, что ошибки в данных для них будут предпочтительней отбрасывания пакетов целиком.
Во вторых, всем каналам Second, поддерживающим передачу трафика IP, следует использовать строгую проверку целостности на канальном уровне(например, CRC-32 [RFC-3819]) и эта проверка должна по умолчанию использоваться для трафика IP. Когда нижележащий канальный уровень поддерживает такую проверку, некоторые типы трафика (например, UDP-Lite) могут получить преимущества в результате смены поведения канального уровня, чтобы позволить по запросу пересылку частично поврежденных пакетов IP [RFC-3819]. Некоторые радио-технологии (например, [3GPP]) поддерживают такое поведение при работе при работе в точках, где стоимость и задержки достаточно малы. Если склонные к ошибкам каналы знают о чувствительной к ошибкам части пакета, для физического соединения можно обеспечить дополнительную защиту за счет снижения вероятности повреждения чувствительных к ошибкам байтов (например, использовать неоднородную упреждающую коррекцию ошибок FEC).
В третьих, промежуточным уровням (т. е., IP и протокол транспортного уровня) не следует запрещать работу устойчивых к ошибкам приложений при наличии таких каналов. Протокол IP не создает проблем в этом отношении, поскольку заголовок IP включает контрольную сумму, покрывающую все данные пакета IP. Из транспортных протоколов общего назначения лучше всего подходит UDP, поскольку он не создает издержек, связанных с повтором передачи ошибочных пакетов, нарушением порядка доставки и коррекцией ошибок. Для IPv4 [RFC-791] контрольная сумма UDP покрывает пакет целиком или просто не используется. Для IPv6 [RFC-2460] контрольная сумма UDP является обязательной и ее использование не может быть отключено. Заголовок IPv6 не включает контрольной суммы самого заголовка и считается необходимым всегда защищать адресную информацию IP с помощью обязательной контрольной суммы UDP.
Требуется транспортный протокол, который соответствует свойствам канального уровня и перечисленным выше требованиям [LDP99]. Механизм детектирования ошибок транспортного уровня должен обеспечивать защиту важной информации (такой, как заголовки) вкупе с игнорированием ошибок, с которыми лучше иметь дело приложениям. Набор октетов, проверяемых с помощью контрольной суммы, лучше всего задавать со стороны передающего приложения.