RFC 8487

RFC 8487 — это запрос комментариев (Request for Comments) под номером 8487, опубликованный в 2019 году в стандартизационной серии Интернет-инженерной рабочей группы (IETF). Документ озаглавлен «MTU Considerations for the MPLS Data Plane» и посвящён вопросам, связанным с максимальным размером передаваемого блока данных (MTU) в сетях с многопротокольной коммутацией по меткам (MPLS). RFC 8487 не является стандартом Интернета (Internet Standard), а относится к категории «Информационный» (Informational), то есть предоставляет рекомендации и разъяснения, а не устанавливает обязательные требования.

Предпосылки создания

Сети MPLS широко используются провайдерами связи и крупными корпоративными сетями для организации виртуальных частных сетей (VPN), трафика с гарантированным качеством обслуживания (QoS) и оптимизации маршрутизации. В таких сетях пакеты могут инкапсулироваться в несколько уровней меток MPLS, а также в туннели других протоколов (например, IP-in-IP, GRE, VXLAN). Каждая дополнительная инкапсуляция увеличивает размер заголовка пакета, что может привести к превышению MTU на каком-либо участке сети.

До появления RFC 8487 существовали разрозненные рекомендации по учёту MTU в MPLS (например, в RFC 3032, RFC 3270, RFC 3985), но не было единого, всеобъемлющего документа, который бы систематизировал проблемы и предлагал практические решения для операторов сетей. RFC 8487 был подготовлен рабочей группой IETF MPLS (Multiprotocol Label Switching) и призван заполнить этот пробел.

Основные положения документа

RFC 8487 не вводит новых протоколов или механизмов, а анализирует существующие практики и формулирует рекомендации. Ключевые темы документа включают:

Определение MTU в контексте MPLS

В документе чётко разграничиваются несколько понятий MTU, важных для MPLS-сетей:

• MTU канала (Link MTU) — максимальный размер кадра, который может быть передан по физическому каналу (например, 1500 байт для Ethernet).
• MTU пути (Path MTU) — минимальный MTU среди всех каналов на пути следования пакета.
• MTU MPLS-уровня (MPLS MTU) — максимальный размер MPLS-пакета (включая все метки), который может быть передан без фрагментации.
• MTU полезной нагрузки (Payload MTU) — максимальный размер IP-пакета, который может быть инкапсулирован в MPLS без превышения MTU канала.

Проблема фрагментации и ICMP

В традиционных IP-сетях при превышении MTU маршрутизатор может фрагментировать пакет или отправить ICMP-сообщение «Fragmentation Needed» (тип 3, код 4). В MPLS-сетях ситуация сложнее:

• MPLS-коммутаторы (LSR) обычно не выполняют фрагментацию на уровне меток; они просто отбрасывают слишком большие пакеты.
• ICMP-сообщения генерируются только на IP-уровне, но в MPLS-туннелях они могут не доходить до источника из-за того, что метки скрывают исходные IP-адреса.
• В результате источник IP-пакета может не узнать о необходимости уменьшить размер передаваемых данных, что приводит к потерям.

RFC 8487 рекомендует операторам сетей MPLS настраивать MTU таким образом, чтобы избежать фрагментации на всём пути. Для этого предлагается:

• Уменьшать MTU на интерфейсах LSR на величину, равную максимальной длине стека меток (обычно 4-8 байт на метку, но может быть больше при использовании нескольких уровней).
• Использовать механизмы Path MTU Discovery (PMTUD) с учётом MPLS-инкапсуляции.
• Применять протоколы сигнализации (например, LDP или RSVP-TE) для согласования MTU между LSR.

Влияние различных типов инкапсуляции

Документ подробно рассматривает, как разные способы инкапсуляции влияют на MTU:

• MPLS поверх Ethernet — наиболее распространённый случай. К стандартному Ethernet-кадру (1500 байт полезной нагрузки) добавляются метки MPLS (4 байта каждая). Если стек меток содержит 2-3 метки, то максимальный размер IP-пакета, который можно передать без фрагментации, уменьшается до 1492-1496 байт.
• MPLS поверх PPP/HDLC — в таких каналах MTU обычно больше (например, 1500 или 4470 байт), но проблема инкапсуляции остаётся.
• MPLS в туннелях (MPLS-in-IP, MPLS-in-GRE) — добавляется внешний IP-заголовок (20 байт) и, возможно, заголовок GRE (4 байта). Это может существенно снизить эффективный MTU.
• MPLS поверх MPLS (иерархические LSP) — при организации многоуровневых туннелей (например, для защиты трафика) стек меток может содержать 4-6 меток, что требует соответствующего уменьшения MTU.

Рекомендации для операторов

RFC 8487 содержит ряд практических советов:

1. Настройка MTU на интерфейсах LSR — рекомендуется устанавливать MTU на интерфейсах, подключённых к MPLS-сетям, с запасом в 16-32 байта для учёта возможного роста стека меток.
2. Использование Jumbo Frames — в сетях Ethernet, где поддерживаются кадры размером более 1500 байт (например, 9000 байт), можно увеличить MTU канала, чтобы компенсировать накладные расходы MPLS.
3. Мониторинг и диагностика — операторам рекомендуется отслеживать количество отброшенных пакетов из-за превышения MTU и использовать инструменты (например, ping с установленным битом DF) для проверки пути.
4. Согласование MTU с клиентами — при предоставлении услуг MPLS VPN провайдер должен гарантировать, что MTU на клиентском интерфейсе (CE-PE) согласован с MTU внутри магистральной сети.

Критика и ограничения

RFC 8487, будучи информационным документом, не решает всех проблем, связанных с MTU в MPLS. Основные критические замечания:

• Документ не предлагает автоматических механизмов адаптации MTU; все рекомендации требуют ручной настройки или использования внешних протоколов.
• В нём не рассматриваются современные технологии, такие как Segment Routing (SR-MPLS), которые могут использовать более длинные стеки меток (до 10-15 меток) и требуют иных подходов к расчёту MTU.
• Некоторые операторы отмечают, что рекомендации RFC 8487 слишком консервативны и не учитывают возможность использования механизмов фрагментации на границах MPLS-сети (например, на маршрутизаторах PE).

Значение

RFC 8487 стал полезным справочным материалом для инженеров и администраторов сетей MPLS. Он систематизировал разрозненные знания и предоставил единую терминологию и подходы к управлению MTU. Документ часто цитируется в более поздних RFC и технических руководствах, посвящённых проектированию MPLS-сетей. Несмотря на отсутствие статуса стандарта, его рекомендации широко применяются на практике, особенно в крупных провайдерских сетях, где вопросы производительности и надёжности критичны.

Источники

• RFC 8487 — «MTU Considerations for the MPLS Data Plane», IETF, 2019.
• RFC 3032 — «MPLS Label Stack Encoding», IETF, 2001.
• RFC 3270 — «Multi-Protocol Label Switching (MPLS) Support of Differentiated Services», IETF, 2002.
• RFC 3985 — «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture», IETF, 2005.
• «MPLS and VPN Architectures», Ivan Pepelnjak, Jim Guichard, Cisco Press, 2000.
• «MPLS Fundamentals», Luc De Ghein, Cisco Press, 2006.