Кратко

  • RFC 3037 рекомендовала реализовывать базовый LDP на устройствах, которые пересылают MPLS по обычным путям, выбранным по адресу назначения; она не делала LDP обязательным для каждого MPLS-устройства и не подтверждала настройку и работу конкретного экземпляра.
  • Документ отделил пошаговое распределение меток от трафик-инжиниринга с явно заданным маршрутом и показал независимые свидетельства: обнаружение, TCP-соединение, согласование параметров, рабочая сессия, обмен привязками, сохранённое состояние, программирование пересылки и наблюдаемый трафик.

Самое опасное для переоценки слово в RFC 3037 — не название протокола, а «рекомендуется». В коротком разделе об уровне требований документ рекомендовал реализовывать LDP на устройствах, выполняющих MPLS-пересылку по обычным путям, выбранным маршрутизацией по назначению. Это было ограниченное инженерное суждение. Оно не было всеобщим предписанием, сертификатом реализации или отчётом о работающей сети.

Документ вышел в январе 2001 года как Informational RFC и отвечал на вопрос применимости: какое место базовый LDP занимал среди возможных способов распределения MPLS-меток? Ответ очертил границу вокруг обычного маршрутизируемого пути. Точное чтение требует не выдавать пригодность протокола за факт эксплуатации.

В область применения входил обычный маршрут

Для MPLS-пересылки соседние коммутаторы меток должны разделять смысл меток, используемых между ними и через них. LDP задавал процедуры, по которым LSR объявлял созданную им привязку. RFC 3037 описала их как поддержку распределения меток вдоль путей, уже выбранных маршрутизацией по назначению, — пошаговой MPLS-пересылки.

Эта роль могла соединять разнородные механизмы. LDP, плоскость IP-маршрутизации и программа, способная настраивать кросс-соединения ATM или Frame Relay, могли провести IP через коммутируемые сети без оверлея или отдельной системы адресации и маршрутизации. Самостоятельный LDP также не требовал одного протокола маршрутизации, способного переносить расширения, на каждом участке LSP.

У каждого «могли» был ограниченный объект. Архитектура могла убрать зависимость; она не доказывала наличие программы кросс-соединений на названном коммутаторе, образование сессии на каждом участке или передачу трафика по полученному пути. Применимость указывала способ собрать систему. Она не сообщала, что сборка состоялась.

Та же граница отделяла базовый LDP от трафик-инжиниринга. Явно маршрутизируемый LSP не обязан следовать пути обычной маршрутизации. RFC 3037 назвала расширения CR-LDP и RSVP-TE двумя возможными механизмами и отметила отсутствие тогдашнего консенсуса о техническом превосходстве. Администраторам предлагалось выбирать по потребностям и обстоятельствам. Механизм расширений LDP позволял дальнейшую работу; наличие точки расширения не делало конкретное расширение частью базового протокола.

Рекомендация относилась к функции, а не к каждой коробке

Формулировка требования была точной: реализация рекомендовалась для устройств, пересылающих MPLS по обычным путям на основе назначения. Условие имеет значение. Устройство вне этой функции не становилось несоответствующим лишь из-за отсутствия базового LDP, а устройство с кодом LDP не становилось рабочим лишь потому, что документ отдавал ему предпочтение.

Реализация — только одна квитанция. Программа может присутствовать при выключенной функции. Включённый процесс может не обнаружить соседа. Обнаружение может не привести к TCP-соединению. Соединение может не завершить согласование. Рабочая сессия может не обменяться полезной привязкой. Привязка может не попасть в таблицу пересылки. Запрограммированная метка может не увидеть ни одного пакета.

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

Сессия была последовательностью, а не одной зелёной лампой

RFC 3037 изложила управляющий путь LDP как ряд шагов. Обнаружение находило возможного соседа. Установка сессии создавала TCP-соединение. Стороны согласовывали параметры, включая способ распределения. Только после соглашения сессия становилась рабочей для передачи меток.

TCP обеспечивал надёжную доставку сообщений сессии, поэтому распределённые метки и связанное состояние LSP не требовали периодического обновления. Но надёжность относилась к потоку байтов. Она не доказывала принятие смысла соседом, соответствие привязки маршруту, программирование оборудования или доставку пакета.

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

Меню режимов выражало довод о ресурсах

LDP не предписывал единого сочетания. В Downstream Unsolicited LSR объявлял привязку FEC к метке, когда был готов пересылать этот FEC; в Downstream on Demand отвечал на запрос. Liberal Retention сохранял метки соседей, даже если они не нужны немедленно; Conservative Retention освобождал лишние. Independent Control позволял объявлять по готовности LSR; Ordered Control ждал привязки от следующего узла FEC либо статуса выходного узла.

RFC 3037 сгруппировала выбор вокруг дефицита. При ограниченных значениях меток, как на ATM и Frame Relay, подходящими названы распределение по запросу, консервативное хранение и упорядоченное управление. При изобилии меток незапрошенное распределение, либеральное хранение и независимое управление могли ускорять смену следующего узла, поскольку полезные метки уже имелись.

«Подходящий» означало условие, а не абсолют. Протокол разрешал другие комбинации и гибриды. Экономия меток отказывалась от сохранённых альтернатив; сохранение альтернатив расходовало состояние. Раннее объявление меняло момент заявления вверх по пути, ожидание — зависимость установки. Документ давал пространство решений, не победителя для любой сети.

Обязательная способность всё равно могла быть выключена

Правило обнаружения петель прямо показывало различие способности и состояния. LDP определял защиту LSP, проходящих через MPLS-облака без TTL. Совместимый LSR обязан был её реализовать, но оператор мог отключить использование настройкой.

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

У расширений был тот же предел. LDP задавал введение новых сообщений и TLV, обнаружение неизвестных типов и ответ при отсутствии поддержки. RFC 3037 предупреждала, что не всякое будущее улучшение будет обратно совместимым. Корректная обработка неизвестного TLV делала развитие безопаснее; она не доказывала поддержку одного расширения обоими соседями.

Рассуждения о масштабе называли издержки, не ёмкость

Документ объяснял, почему инкрементальное распределение могло масштабироваться: привязки не требовали периодического обновления. Он называл и противоположные издержки. Режимы дефицита ограничивали выделение меток. Либеральное хранение уменьшало перераспределение после смены следующего узла. Число поддерживаемых TCP-соединений ограничивало соседей. Вектор пути для поиска петель расходовал память, процессор и управляющий трафик.

Ни одно утверждение не давало численной ёмкости продукта. Оператору всё ещё нужны были измерения числа соседей, пространства меток, памяти, CPU, частоты сообщений, повторной сходимости и результатов пересылки. Свойство протокола подсказывает важный счётчик, но не является его показанием.

Защита тоже была узкой. Необязательный TCP MD5 мог затруднить внедрение поддельных сегментов в поток LDP-сессии. Он не подтверждал законность FEC, не разрешал маршрут, не доказывал истинность привязки и не защищал приложение внутри LSP.

Позднейший консенсус не переписал прежний снимок

RFC 3037 запечатлела момент, когда CR-LDP и RSVP-TE были возможными ответами для явно заданных LSP и технический победитель не получил консенсуса. Затем RFC 3209, RFC 3212 и RFC 3213 подробнее описали обе ветви.

В феврале 2003 года RFC 3468 зафиксировала последующее решение рабочей группы и IESG сосредоточить новую работу по сигнализации MPLS на RSVP-TE и не начинать новую работу группы по CR-LDP. Статус существующих RFC был намеренно сохранён, индивидуальные предложения не запрещены. Это свидетельство распределения будущей работы в более позднюю дату. Оно не доказывает миграцию каждого оператора, исчезновение каждой реализации или ошибочность январского снимка 2001 года.

Исторический урок — дисциплина глаголов. Орган стандартизации рекомендует. Производитель реализует. Оператор включает. Соседи обнаруживают друг друга, соединяются и договариваются. Плоскость управления распределяет. Оборудование устанавливает. Пакеты проходят. RFC 3037 ясно говорила о первом глаголе. Остальным всё ещё требовались квитанции.

Источники

Лу Хэн не писал и не одобрял RFC 3037 или связанные стандарты. Его эссе используются здесь как явно раскрытые аналитические линзы.