RFC: 3168
Оригинал: The Addition of Explicit Congestion Notification (ECN) to IP
Предыдущие версии: RFC 2481
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

RFC 3168, Страница 7 из 56

В RFC 2481 [RFC2481] поле ECN было разделено на две части — бит ECT и бит CE. Поле ECN, в котором установлен только бит ECT (в соответствии с RFC 2481), эквивалентно маркеру ECT(0), а поле ECN, в котором установлены оба флага ECT и CE — маркеру CE. Маркер 01 не определен в RFC 2481 и по этой причине следует использовать маркер ECT(0) в тех случаях, когда требуется единственный маркер ECT.

    0     1     2     3     4     5     6     7
 +-----+-----+-----+-----+-----+-----+-----+-----+
|           Поле DS, DSCP           | Поле ECN  |
 +-----+-----+-----+-----+-----+-----+-----+-----+
   DSCP: код дифференцированного обслуживания
   ECN:  явное уведомление о перегрузке
Рисунок 2: Поля Differentiated Services и ECN в заголовке IP

Биты 6 и 7 октета IPv4 TOS обозначены как поле ECN. Октет IPv4 TOS соответствует октету Traffic Class в IPv6, а поле ECN определяется одинаково для обоих случаев. Определения для октета IPv4 TOS [RFC791] и октета IPv6 Traffic Class были отменены определением шестибитового поля DS (Differentiated Services) [RFC2474, RFC2780]. Биты 6 и 7 указаны в [RFC2474] как неиспользуемые (Currently Unused), а в RFC 2780 — как предложенные для экспериментального использования в ECN. В параграфе 22 приведена краткая ретроспектива использования поля октета TOS.

По причине изменений в характере использования TOS описанное здесь применение поля ECN не может гарантировать обратной совместимости со всеми прежними вариантами использования двух битов, отведенных для поля ECN. Потенциальные проблемы, связанные с таким отсутствием совместимости рассматриваются в параграфе 22.

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

Одной из причин требования идентичной реакции на индикацию насыщения при получении CE-пакета или отбрасывании пакета является необходимость обеспечения постепенного развертывания ECN как в конечных системах, так и в маршрутизаторах. Некоторые маршрутизаторы могут отбрасывать ECN-пакеты (например, при использовании некоторых правил детектирования перегрузки в AQM), тогда как другие маршрутизаторы будут устанавливать маркер CE при таких же условиях насыщения. Подобно этому маршрутизатор может отбрасывать не поддерживающие ECN пакеты и устанавливать бит CE в ECN-пакетах при одинаковых условиях насыщения. Разная реакция на индикацию насыщения путем установки бита CE и путем отбрасывания пакетов может приводить к различным (неправильным) трактовкам для разных потоков.

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

Маршрутизаторам следует устанавливать маркер CE в ECN-пакетах только в тех случаях, когда маршрутизатор должен был бы отбросить пакет для индикации насыщения конечным узлам. Когда буфер маршрутизатора еще не заполнен, но маршрутизатор уже приготовился к отбрасыванию пакетов для уведомления конечных узлов о насыщении, этому маршрутизатору следует сначала проверить наличие маркера ECT в заголовке IP. Если данный маркер установлен, вместо отбрасывания пакетов маршрутизатор может устанавливать маркер CE в заголовке IP.

Страница 7 из 56

2007 - 2022 © Русские переводы RFC, IETF, ISOC.