Кратко
- RFC 3034 назвал последовательность Frame Relay LSR, меняющих DLCI без уменьшения MPLS TTL, сегментом без TTL; пропущенные ядром переходы требовалось учесть на одной из границ.
- Переданный через LDP Hop Count мог использоваться входом unicast для предварительного вычитания, однако оставался утверждением плоскости управления, а не наблюдением пути или квитанцией о доставке.
Коммутатор не был плох в коммутации. Он принимал кадр, находил входной DLCI, записывал выходной и отправлял кадр дальше. Но его аппаратура, как правило, не умела выполнять действие, привычное для маршрутизатора: уменьшать TTL в каждом пакете. Когда такой коммутатор становился MPLS Label Switching Router, отсутствующая операция превращалась в проблему всего пути.
RFC 3034 вышел в январе 2001 года как Proposed Standard. Документ не приписал оборудованию несуществующую возможность. Он выделил цепочку подобных устройств в «сегмент без TTL» и поручил его границе списать суммарное число переходов.
Рабочее значение метки находилось в DLCI
На канале Frame Relay значение текущей MPLS-метки помещалось в поле DLCI заголовка канального уровня. Дополнительные метки и остальные поля верхнего элемента стека оставались в общей инкапсуляции MPLS. В ядре FR-LSR искал DLCI, заменял его выходным значением и пересылал кадр.
Логическое состояние оказалось представлено в двух местах. Значение, управлявшее коммутацией, находилось в заголовке канала, тогда как TTL и другие значимые поля сохранялись в стеке. На границе другой инкапсуляции LSR должен был декодировать логический стек, выполнить операцию и закодировать его заново. Один LSP поэтому мог выглядеть по-разному на соседних линиях.
Если на выходе снималась последняя метка, стек не содержал явного идентификатора следующего протокола сетевого уровня. Его следовало вывести из привязки метки. Привязка задавала ограниченное правило разбора и пересылки, но не удостоверяла отправителя, не разрешала маршрут и не подтверждала ни прохождение ожидаемой цепи, ни доставку.
Невидимый счётчику переход всё равно расходовал дальность
TTL в MPLS должен был подавлять петли и ограничивать область распространения пакета. Если пять коммутаторов Frame Relay постоянно считать нулём, пакет покинет их с большим остатком жизни, чем после пяти эквивалентных маршрутизаторов. Даже безошибочная локальная замена DLCI не сохраняет глобальное свойство.
RFC записал расчёт как выходной TTL = входной TTL - d. Величина d зависела от входной, пересылочной и выходной инкапсуляций. Внутри одноуровневого ядра Frame Relay использовался ноль, поскольку плата переносилась на границу. Обычный переход MPLS, как правило, стоил единицу. Вход в сегмент без TTL мог сразу стоить всё распространённое число его переходов.
Для unicast значимую длину передавали ко входу, который вычитал её до допуска пакета. Для multicast длина шла к выходу, где производился соответствующий граничный расчёт. Место списания менялось, но скрытая от аппаратной инструкции часть пути не становилась бесплатной.
Вход мог отказать до истечения TTL внутри сегмента
Предварительная оплата позволяла принять решение до первой замены DLCI. Если расчёт показывал, что TTL unicast-пакета истечёт до выхода, вход не имел права направлять пакет с меткой в сегмент без TTL.
Вместо этого он должен был попытаться вернуть ошибку ICMP по правилам стека меток либо переслать пакет без метки с TTL, отражающим IP-пересылку. При входном TTL, равном единице, оставался только путь ошибки.
«Попытаться» — важное ограничение. Созданная ошибка ICMP не доказывает, что источник её получил. Передача пакета без метки не доказывает его дальнейшую доставку. Граничная запись подтверждает лишь решение и использованные при нём значения.
Hop Count был распределённым состоянием, а не телеметрией
LDP мог приложить объект Hop Count к привязке метки. Получив известное значение снизу, FR-LSR увеличивал его на один перед объявлением наверх. Неизвестное оставалось неизвестным. Если приращение превышало максимум, привязку нельзя было передавать дальше; требовалось отправить ошибку.
При ordered control узел ожидал нижестоящую привязку и только затем отвечал вышестоящему, сразу передавая увеличенное число. При independent control он мог раньше объявить привязку с неизвестным Hop Count и исправить её позднее. Если LDP не давал числа либо помечал его неизвестным, расчёт RFC 3034 использовал значение по умолчанию, равное единице.
Эта единица не означала, что измерен одношаговый путь. Она лишь задавала поведение при отсутствии сведений. Даже известное число собиралось из маршрутизации и сообщений распределения, а не из наблюдений за пакетом. Оно не доказывало работу всех коммутаторов, прохождение конкретного пакета именно этой цепью или приём на выходе.
Новая трасса лишала старую арифметику полномочий
Уже объявленная наверх привязка не замораживала число. Завершение нижестоящего построения или выбор другого next hop могли изменить длину. FR-LSR был обязан увеличить новый результат и распространить его в сторону входа. Если значение превышало максимум, связанные с FEC метки следовало отозвать у вышестоящих соседей, чтобы обнаружение петель не опиралось на невозможное число.
Сбои также отменяли силу сохранённого состояния. Если запрос вниз нельзя было удовлетворить, временную привязку, созданную по запросу сверху, следовало уничтожить и отозвать. Потеря сессии LDP требовала отбросить привязки, изученные через это соединение. Даже liberal retention разрешал повторное использование лишь при совпадении маршрута и Hop Count с условиями RFC.
Поэтому строка в Label Information Base не доказывала наличие рабочего пути. Важны сессия происхождения, живая зависимость снизу, соответствие числа текущему маршруту и факт распространения обновления до входа.
Адаптация к аппаратуре не объединила уровни доказательств
Коммутатор Frame Relay в роли LSR должен был выделять и поддерживать метки и участвовать как равноправный узел в протоколе маршрутизации сетевого уровня. При этом традиционное управление Frame Relay и управление коммутацией по меткам могли независимо сосуществовать на одном устройстве и интерфейсах, совместно используя лишь ограниченные ресурсы вроде разделения пространства DLCI. Совмещённая работа оставалась вне рамок RFC.
Компромисс имел точные границы: маршрутизация выбирала зависимость, LDP сообщал длину, вход производил вычитание, ядро заменяло DLCI. Наблюдение пакета и выходной TTL были отдельными квитанциями. RFC 3034 перенёс работу из-за ограничения аппаратуры, но не перенёс истину о пути в число плоскости управления.
Источники
- Запись RFC Editor о RFC 3034
- RFC 3034 в HTML
- Текст RFC 3034
- RFC 3031: архитектура MPLS
- RFC 3032: кодирование стека меток MPLS
- RFC 3036: протокол LDP
- RFC 2427: многопротокольное соединение поверх Frame Relay
- RFC 3035: MPLS с коммутацией ATM VC
- RFC 3443: обработка TTL в сетях MPLS
- Lu Heng о приоритете работающего кода
- Lu Heng о минимальной начальной спецификации
- Lu Heng об уровнях реальности
Lu Heng не писал и не одобрял RFC 3034 либо связанные стандарты. Его эссе используются здесь как явно раскрытые аналитические рамки.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
