Кратко
- Входной LSR выбирает поля пакета, пригодные для хеширования, получает EL и ставит непосредственно перед ним ELI с зарезервированным значением 7. Поэтому стек увеличивается на два элемента: ELI и EL.
- EL не является меткой пересылки, не сигнализируется и не разрешает объявление маршрута, создание нового LSP или изменение политики маршрутизации. Значение EL не должно находиться в зарезервированном диапазоне от 0 до 15.
- Выходной узел объявляет возможность работать с энтропийной кодировкой для туннеля, но решение вставить ELI и EL принимает входной LSR. Способный выходной узел должен принимать пакеты как с этими метками, так и без них.
Практический смысл схемы — предоставить транзитным узлам устойчивый вход для хеширования внутри стека. Это может помочь равномернее распределять потоки по членам LAG или ECMP и одновременно сохранять один поток на одном пути. Перемещение потока между путями способно вызвать джиттер, задержку и переупорядочивание пакетов. RFC 6790 не устанавливает один алгоритм хеширования, один набор ключей, универсальный порог или обязательную последовательность внедрения.
Возможность использования и полномочие на построение пути — разные вещи. Сигнализация capability разрешает применение кодирования для туннеля, но не создание маршрута или LSP и не изменение политики. Транзитные LSR по-прежнему владеют локальными решениями ECMP, LAG и пересылки. Без EL устройства могут хешировать более грубые MPLS-метки, при возможности анализировать более глубокие заголовки или применять другие методы балансировки. Ни один из этих вариантов не передаёт полномочия на новый путь.
RFC 7447 объявляет атрибут BGP Entropy Label Capability (ELCA) устаревшим. Не осведомлённый об атрибуте маршрутизатор, меняющий следующий переход, мог прозрачно пропустить опциональный транзитивный атрибут, после чего на него ошибочно полагались. Поэтому устаревший ELCA нельзя представлять как действующий механизм сигнализации.
RFC 8012 добавляет процедуры LSP ping и traceroute с учётом энтропии. Они предоставляют сведения о multipath и флаги для проверки ECMP-путей, когда одни узлы балансируют по EL, а другие — по IP-адресам или иным меткам. Это не доказывает, что весь трафик проходит по каждому измеренному пути, и не доказывает поддержку расширенного метода всеми узлами: проверка сквозной поддержки находится за пределами документа.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

