22. Ретроспектива использования октета IPv4 TOS
RFC 791 [RFC791] определяет октет ToS (Type of Service — тип обслуживания) в заголовке IP. В RFC 791 биты 6 и 7 октета ToS отмечены, как резервные (Reserved for Future Use), и указано, что они имеют нулевое значение. Первые два поля октета ToS определены в документе, как Precedence (предпочтения) и Type of Service (тип обслуживания — TOS).
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | 0 | 0 | RFC 791 +-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 включает биты 6 и 7 в поле ToS, не обсуждая конкретного их использования:
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | RFC 1122 +-----+-----+-----+-----+-----+-----+-----+-----+
Октет ToS заголовка IPv4 был заново определен в RFC 1349 [RFC1349], как показано ниже.
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | MBZ | RFC 1349 +-----+-----+-----+-----+-----+-----+-----+-----+
Бит 6 поля TOS был определен в RFC 1349, как «минимизация финансовых расходов». В дополнение к полям Precedence и TOS было определено поле MBZ (Must be zero — должно иметь нулевое значение), которое в настоящее врямя не используется. В RFC 1349 отмечетно, что отправитель дейтаграмм устанавливает в поле MBZ нулевое значение, если не используется экспериментальных протоколов с иной трактовкой этого бита.
RFC 1455 [RFC 1455] определяет экспериментальный стандарт, использующий все четыре бита поля TOS для запроса гарантированного уровня защиты канала.
Документы RFC 1349 и RFC 1455 были отменены RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» [RFC2474], в котором биты 6 и 7 поля DS были указаны, как неиспользуемые (CU — Currently Unused). В RFC 2780 [RFC2780] содержится спецификация ECN для экспериментального использования двухбитового поля CU. RFC 2780 обновляет определение поля DS Field, оставляя в нем лишь первых шесть битов, которые трактуются, как коды дифференцированного обслуживания (DSCP — Differentiated Services CodePoint). Формат поля показан на рисунке.
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DSCP | CU | RFCs 2474, +-----+-----+-----+-----+-----+-----+-----+-----+ 2780
Поскольку история еще не завершена, определение поля ECN в данном документе не гарантирует совместимости со всеми предшествующими вариантами использования этих двух битов.
До RFC 2474, маршрутизаторам не разрешалось менять биты в полях DSCP и ECN пересылаемых пакетов и, следовательно, маршрутизаторы, соответствующие только требованиям RFC до 2474, не оказывают влияния на ECN. Для конечных узлов бит 7 (второй бит ECN) должен передаваться с нулевым значением всеми реализациями, совместимыми только с RFC до 2474. Такие узлы могут передавать в бите 6 (первый бит ECN) единицу для указания необходимости экономной передачи (Minimize Monetary Cost) в соответствии с RFC 1349 или экспериментами, разрешенными RFC 1455, однако оба эти варианта не получили широкого распространения. Помехи, которые могут создавать некорректно работающие маршрутизаторы, включают «удаление» кода CE для поддерживающих ECN пакетов, которые поступили на маршрутизатор с установленным флагом CE, и установку кода CE при отсутствии перегрузок. Эти вопросы рассмотрены в параграфе «Неподатливость в сети».
Нарушения в работе поддерживающей ECN среды, которые могут создаваться не совместимыми с ECN конечными узлами, передающими пакеты с установленным кодом ECT, рассмотрены в параграфе «Неподатливость конечных узлов».