Кратко

  • RFC 3477 объединила стабильный Router ID с локальным для конечной точки Interface ID, чтобы RSVP-TE мог задавать и записывать ненумерованные каналы «точка — точка».
  • Оба конца могли выбирать несвязанные значения; намерение ERO, разрешение IF_ID, запись RRO и фактическая пересылка оставались разными свидетельствами.

Слово «ненумерованный» создаёт образ канала без идентичности. В RFC 3477 всё было интереснее: у канала имелось два имени. Каждый LSR на конце назначал своё, и ни одно число нельзя было отделить от устройства, в области которого оно возникло.

Канал должен был быть соединением «точка — точка». Каждый LSR выбирал ненулевое 32-битное значение и обеспечивал его уникальность только в собственных границах. Спецификация прямо говорила: между значениями на противоположных концах нет заранее заданной связи. Для A его значение было локальным, а значение B — удалённым; с точки зрения B определения менялись местами. Точка наблюдения входила в смысл данных.

Поэтому полезным именем являлась пара. Interface ID сопровождался Router ID назначившего его LSR. Router ID понимался как стабильный IP-адрес, обычно loopback, который оставался доступным, пока существовал какой-либо путь к устройству. Область действия превращала местное число в переносимую ссылку, не выдавая его за глобальный идентификатор.

Два маршрутизатора могли повторно использовать одинаковое число без конфликта, поскольку их Router ID различались. В то же время один физический канал мог иметь разные числа на концах. База, которая принудительно сводит их к одному «каноническому» значению, удаляет не шум, а происхождение каждого имени.

Конечным точкам всё равно требовалось обмениваться назначениями. RFC перечисляла конфигурацию, LMP, RSVP или CR-LDP для Forwarding Adjacency, а также расширения IS-IS либо OSPF. Если IGP поддерживал traffic engineering, его модуль и RSVP в одном LSR должны были согласовать идентификаторы. Правильный формат пары не исправлял устаревшую карту соседей.

Первым применением было намерение маршрута. В Explicit Route Object появился подобъект Unnumbered Interface ID типа 4 и длиной 12. Он переносил Router ID и назначенный этим маршрутизатором Interface ID. В ERO пара указывала ненумерованный канал, который планировалось использовать. Она не подтверждала, что канал уже был пройден.

Затем следовало разрешение у соседа. Выбирая ненумерованный выход, узел помещал свой Router ID и локальное значение в IF_ID RSVP_HOP. Принимающий LSR обязан был знать числа, назначенные соседями, и искать совпадение. Если его не было, RFC рекомендовала IF_ID ERROR_SPEC с кодом 24 и значением 16 — Unknown Interface Index.

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

Record Route Object использовал такой же тип 4 и длину 12, но выполнял иную доказательную функцию. ERO выражал желаемый путь; RRO накапливал маршрут, записанный состоянием RSVP по мере прохождения Path. Одинаковая кодировка не превращала намерение в наблюдение, а запись плоскости управления — в независимую физическую телеметрию.

Флаги защиты подчёркивали разделение. Один означал, что локальная защита ниже по пути доступна. Другой — что локальная защита используется, обычно потому, что механизм восстановления поддерживает туннель после отказа. Возможность защитить и активированное переключение были разными событиями. Общее состояние «защищён» стирает важную временную границу.

Модель распространялась и на ненумерованные Forwarding Adjacencies. LSP, объявленный как канал, получал идентификатор на головном и ещё один на хвостовом узле. Объект LSP_TUNNEL_INTERFACE_ID класса 193 и C-Type 1 мог переносить прямую идентичность в Path и обратную в Resv. Даже сконструированный поверх LSP канал сохранял две административные перспективы.

Более поздние документы по GMPLS, OSPF, IS-IS и объединению каналов расширили распространение либо применение этих идентификаторов. RFC 6107 позже обновила RFC 3477 для Path Key. Они объясняют техническую генеалогию, но не доказывают возможности реализации января 2003 года или работу конкретного пути.

Разделение слоёв реальности из заметок Heng Lu задаёт верную проверку. Router ID ограничивает имя, но не доказывает текущую достижимость. ERO описывает намерение, но не прохождение. RRO хранит состояние RSVP, но не физическую непрерывность. Выделение метки не подтверждает программирование оборудования, а оно не подтверждает доставку трафика.

Аудит должен сохранять исходное сообщение RSVP, сессию, отправителя, направление и время; порядок ERO, пару IF_ID, источник карты соседей, результат поиска, состояния Path и Resv, операцию с меткой, порядок RRO и флаги. Лишь затем эти данные связываются с инвентарём, смежностями, таблицами пересылки, авариями и счётчиками, причём каждый слой имеет собственное происхождение.

Главное практическое правило — никогда не отделять Interface ID от назначившего его Router ID. Нельзя и превращать два значения на концах в выдуманное общее число. Их различие — не дефект, а след распределённого права именовать.

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

Источники