Кратко

  • RFC 5420 переносит расширение атрибутов RSVP-TE из восьмибитного поля Flags объекта SESSION_ATTRIBUTE в TLV, поскольку прежнего поля недостаточно для продолжающихся расширений. Правила относятся к MPLS и GMPLS, а также к пакетным и непакетным LSP.
  • Attribute Flags TLV может находиться и в LSP_ATTRIBUTES, и в LSP_REQUIRED_ATTRIBUTES. Но сам TLV или бит не делает атрибут обязательным: режим определяет несущий объект — прозрачную передачу либо проверку на всём пути.
  • Три контрфактических случая таковы: неизвестный TLV или бит в LSP_ATTRIBUTES пересылается без изменений; неизвестный объект, TLV или установленный бит в LSP_REQUIRED_ATTRIBUTES отклоняет установление; распознанный, но неподдерживаемый атрибут следует RFC, который его определяет, а не универсальному правилу.
  • Requester выбирает границу применения. Транзитный LSR распознаёт и, когда это предписано объектом или определяющим RFC, отклоняет содержимое; после принятия он отдельно пересылает его следующему узлу. Поэтому успешная optional-установка не доказывает применение атрибута.

Граница полномочий

LSP_ATTRIBUTES класса 197 в форме C-Num задаёт необязательную или селективную передачу. LSR, не поддерживающий объект, пересылает его без изменений; неизвестный TLV или установленный неизвестный бит внутри него также проходит без изменения. LSP_REQUIRED_ATTRIBUTES класса 67 требует, чтобы каждый транзитный LSR проверил содержимое и действовал согласно ему. Неизвестный объект, тип TLV или установленный бит приводит к PathErr с Unknown Attributes TLV либо Unknown Attributes Bit и к отказу в установлении.

Это не универсальная реакция на известный, но неподдерживаемый атрибут. Её задаёт RFC, определяющий данный TLV или бит. Requester может потребовать проверку на всём пути, но не может одним словом required навязать одинаковое поведение для всех атрибутов. Транзитный LSR обладает полномочиями распознавания и отказа в пределах правил объекта и определяющего RFC, однако не вправе придумывать семантику. После принятия сообщения содержание отдельно передаётся следующему транзитному LSR.

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

В режиме egress-only важным может быть только выходной LSR. В режиме key-transit зависимость относится к выбранной транзитной точке или набору точек. В режиме all-LSR способность интерпретации каждого транзитного LSR становится условием установки. Выигрывают сервисы, чья реальная зависимость совпадает с выбранной границей. Источники не устанавливают наличие конкретных поставщиков, реализаций или распространённости.

LSP_REQUIRED_ATTRIBUTES не используется в Resv. LSP_ATTRIBUTES в Resv может передавать состояние всего LSP, тогда как подобъект RRO Attributes сообщает состояние конкретного перехода. Он привязан к идентификатору LSR, находящемуся непосредственно перед ним в адресном или интерфейсном подбъекте RRO; добавлять его без такого идентификатора нельзя. Отчёт о соответствии или несоответствии уместен только при смысле, заданном определяющим RFC.

Отчётность по каждому переходу имеет явную цену. Она может раскрывать операционное состояние: распознанную поддержку, несоответствие или особенности локальной политики. Она также потребляет место в RRO и в сообщениях Path или Resv, может сделать RRO больше допустимого размера; в таком случае применяются правила обработки oversized RRO из RFC 3209. Поэтому состояние всего LSP в Resv следует отделять от отчёта о конкретном переходе в RRO, а пересылку нельзя считать доказательством выполнения.

На границе региона LSP forwarding-adjacency LSP может унаследовать подмножество TLV атрибутов по локальной политике, если граница поддерживает соответствующие объекты. В противном случае объекты атрибутов копируются вместе с унаследованным ERO. RFC 5420 использует единое пространство номеров битов, управляемое IANA, для Attribute Flags TLV и подобъекта RRO Attributes; каждый определяющий RFC должен указать смысл бита и обработку нулевого значения.

RFC 7570 — более позднее общее расширение механизма RFC 5420 и рекомендаций по регистрации TLV атрибутов RSVP-TE и hop-specific атрибутов в ERO и RRO. Это не доказательство универсального внедрения и не механизм, предназначенный только для защиты. Указанная страница errata — замороженная запись исправлений RFC 5420; данный материал не утверждает конкретного исправления сверх этой записи.

Проверочные фикстуры

  1. Передайте через legacy LSR Path с неизвестным TLV или битом внутри LSP_ATTRIBUTES. Проверьте неизменную пересылку, но не делайте вывода о применении атрибута.
  2. Повторите тест с LSP_REQUIRED_ATTRIBUTES. Проверьте PathErr, соответствующий Unknown Attributes TLV и отсутствие установленного LSP.
  3. Установите неизвестный бит в обязательном объекте и проверьте Unknown Attributes Bit. Затем испытайте известный, но неподдерживаемый бит и зафиксируйте реакцию, которую требует определяющий RFC.
  4. Разделите Resv и RRO: проверьте статус всего LSP в Resv, а hop-статус — в RRO. Разместите RRO Attributes сразу после идентификатора и учтите раскрытие состояния и расход места сообщения.
  5. Отдельно протестируйте границу региона FA-LSP с частичным наследованием и сопоставьте реестр с RFC 7570, не превращая его общую регистрацию hop-атрибутов в доказательство повсеместного внедрения или защитную специализацию.

Источники не подтверждают поставщиков, конкретные внедрения, инциденты, частоту отказов, задержки установки, измеренную производительность, коммерческие значения или результаты клиентов. Они также не определяют, какие будущие атрибуты должны быть optional, required, egress-only или key-transit: это выбор определяющего RFC и политики оператора.

Источники