Кратко

  • RFC 3988 определял MTU LSP как минимум локальных ограничений и объявлений тех нижестоящих LSR, которые действительно выбраны для пересылки FEC.
  • Снижение требовало немедленного объявления: устаревшее завышение вело к сбросу, тогда как устаревшее занижение в основном оставляло часть ёмкости неиспользованной.

Экспериментальный RFC 3988 вышел в феврале 2005 года. Его карточка, перечень исправлений и история фиксируют исходный разрыв: LDP сообщал метку, но не сообщал входному LSR размер, допустимый на всём Label Switched Path. Завышенная статическая настройка могла направить пакет к молчаливому сбросу внутри пути.

MTU TLV передавался в Label Mapping для Forwarding Equivalence Class. Но не каждый LDP-сосед участвовал в вычислении. Документ различал peer LSR, приславший Mapping, и downstream LSR из выбранного маршрутом набора пересылки. Установленный контрольный сеанс ещё не означал, что через соседа идут эти пакеты.

Отдельными величинами оставались Link MTU, Hop MTU и LSP MTU. Первая включала IP-заголовок, нагрузку и стек меток, но не нижние заголовки; «ссылкой» могли быть интерфейс, туннель или иной LSP. Вторая ограничивала участок между парой LSR и брала минимум используемых линий. Третья охватывала все действующие пути пересылки к выходам.

RFC 3032, его карточка, исправления и история дают учёт меток. Обычная метка занимает четыре октета. Поэтому линия 1500 в примере RFC 3988 давала 1496, а дополнительный туннель мог оставить 1492. Номинал интерфейса не описывал пакет после текущей инкапсуляции.

На выходе расчёт начинался со служебного значения 65535. Для каждого выбранного downstream узел брал меньшее из локальной Hop MTU и полученной LSP MTU, а затем минимум всех кандидатов. Если TLV отсутствовал, вклад считался равным 65535, чтобы известная локальная граница продолжала ограничивать результат. Это не было измерением проходимости пакета такого размера.

Узел мог объявить меньше вычисленного, но не больше. Допустимая ошибка имела одно направление: занижение теряло эффективность, завышение создавало разрешение на пакет, который дальше не пройдёт. Число являлось безопасной оболочкой плоскости управления, а не обещанием производительности.

Изменение downstream-значения или самого выбранного набора требовало пересчёта. Новый меньший результат следовало объявлять сразу; больший разрешалось задержать. После расширения прежний малый предел оставался безопасным. После сужения прежний большой предел становился опасным. Свежесть зависела не только от возраста, но и от направления изменения.

Правило неизвестного TLV показывало границу понимания. LSR без поддержки расширения должен был не обрабатывать атрибут, но переслать его дальше. RFC прямо предупреждал о возможном неверном вычислении. Сохранение утверждения через непрозрачный участок не превращало этот участок в проверяющего свидетеля.

Основанием служил LDP из RFC 3036, с карточкой, исправлениями и историей. Позднее базовую спецификацию заменил RFC 5036, чьи карточка, исправления и история описывают развитие LDP. Они не доказывают внедрение экспериментального расширения.

На входе предел переходил в поведение IPv4 из RFC 1191, его карточки, исправлений и истории. Разрешённый пакет можно было фрагментировать; при DF следовали сброс и ICMP. Верное решение на входе всё равно не подтверждало прохождение каждого участка и приём приложением.

RFC 3209, его карточка, исправления и история задавали контекст RSVP-TE. RFC 3988 мог считать туннель ссылкой, так что предел одного пути рекурсивно зависел от другого пути и ещё одной метки.

Исторический принцип RFC 3988 состоял в приоритете ограничивающего сведения. Запоздалая хорошая новость сохраняет обратимую осторожность. Запоздалая плохая новость сохраняет вымышленную возможность и может уничтожать пакеты. Но даже своевременный минимум остаётся выводом управления, а не квитанцией о доставке.

Источники