Кратко

  • RFC 2105 описал информационную архитектуру Cisco: короткая метка служила точным индексом Tag Information Base, заменялась на каждом переходе и выбирала выходной интерфейс.
  • Обычные протоколы маршрутизации и механизмы привязки заранее создавали это состояние; для маршрутов назначения выделение могла запускать топология, а не первый пакет трафика.
  • Единый механизм пересылки обслуживал unicast, multicast, иерархию, явные маршруты, ATM и QoS, но метка подтверждала лишь локальную исполнимую привязку.

За точным совпадением стояла цепочка решений

Получив маркированный пакет, коммутатор использовал входную метку как точный ключ в TIB. Запись содержала одну или несколько троек: выходную метку, интерфейс и канальную информацию. Устройство заменяло эти поля и передавало пакет. Короткий фиксированный поиск подходил для аппаратуры и мог выдать один unicast-выход или несколько multicast-выходов.

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

Стабильная пересылка под изменяемым управлением

Архитектура разделяла пересылку и управление. Первая всегда выполняла поиск и замену, а модули управления связывали метки с разными объектами маршрутизации и распространяли связи. Новая функция могла появиться без переделки и повторной оптимизации быстрого пути.

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

Сначала маршрут, затем его локальное имя

Для пересылки по назначению OSPF, BGP или другой протокол по-прежнему строил FIB. RFC разрешал downstream-распределение, downstream по запросу и upstream-распределение. В обычной downstream-схеме доступный маршрут вызывал выделение метки и объявление привязки; сосед помещал метку, полученную от следующего перехода, в исходящее поле своей записи.

Привязки могли передаваться вместе с маршрутизацией либо предложенным Tag Distribution Protocol. Нельзя задним числом считать TDP просто прежним названием LDP: RFC 5036 стандартизировал отдельный протокол со своими процедурами обнаружения, сессий, отображений и ошибок.

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

RFC называл распределение для маршрутов назначения topology driven. Запись FIB могла создать метку ещё до прихода пользовательского пакета. Объём состояния зависел от маршрутов, а не от числа краткоживущих разговоров; одна метка могла обозначать префикс или группу маршрутов.

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

Сетевой заголовок не исчез

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

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

Стек перемещал знание к границам

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

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

Один механизм обслуживал разные цели

Для multicast протокол маршрутизации сперва строил дерево, а затем модуль устанавливал в TIB несколько выходных троек. Явная маршрутизация могла проложить путь, отличный от маршрута по назначению. В ATM поля VPI и VCI могли нести метки, но коммутатор всё равно участвовал в маршрутизации и Tag Switching; традиционное управление ATM могло существовать рядом на разделённых ресурсах.

Для QoS входной классификатор назначал метку класса, чтобы следующие узлы находили состояние планировщика без повторной классификации. Такая метка не доказывала наличие полосы, нужной очереди, допустимых потерь, задержки или доставки. Класс и результат обслуживания оставались разными квитанциями.

Информационный документ не был квитанцией о консенсусе

RFC 2105 не был продуктом рабочей группы IETF, не находился на стандартизационном треке и не определял интернет-стандарт. Datatracker теперь помечает его как Legacy без формального статуса в процессе IETF. В документе не обсуждалась безопасность, а раздел об интеллектуальной собственности отмечал возможную патентную позицию Cisco.

Позднейшая стандартизированная архитектура MPLS в RFC 3031 также использовала локально значимые метки, FEC, стеки и замену на каждом переходе. Структурное сходство очевидно, однако RFC 3031 не ссылается на RFC 2105 ни номером, ни названием. Tag Switching был одним историческим путём к коммутации по меткам; одного текста недостаточно для доказательства прямой причинности, линии реализаций или всеобщего внедрения.

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

Источники