RFC 9350 IGP Flexible Algorithm

Internet Engineering Task Force (IETF)                    P. Psenak, Ed.
Request for Comments: 9350                           Cisco Systems, Inc.
Category: Standards Track                                       S. Hegde
ISSN: 2070-1721                                   Juniper Networks, Inc.
                                                             C. Filsfils
                                                     Cisco Systems, Inc.
                                                           K. Talaulikar
                                                      Cisco Systems, Inc
                                                                A. Gulko
                                                            Edward Jones
                                                           February 2023

IGP Flexible Algorithm

Гибкий алгоритм IGP

PDF

Аннотация

Протоколы IGP исторически рассчитывают лучшие пути на основе метрики IGP, назначенной для каналов. Во многих сетях применяется RSVP-TE или SR-TE (Segment Routing – Traffic Engineering) для направления трафика по пути, рассчитанному с использованием иной метрики или ограничений, нежели для лучшего пути IGP. Этот документ предлагает решение, позволяющее протоколам IGP самостоятельно рассчитывать пути через сеть с учётом ограничений. Документ также задаёт способ использования SR Prefix-SID и локаторов SRv6 для направления пакетов по путям, рассчитанным на основе ограничений.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9350.

Авторские права

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Путь, вычисляемый IGP по кратчайшей метрике IGP, часто заменяется путём организации трафика из-за наличия требований, не отражаемых метрикой IGP. В некоторых сетях метрика IGP назначается так, чтобы она отражала пропускную способность или задержку. Например, если метрика IGP отражает пропускную способность канала, а пользовательский трафик чувствителен к задержкам, выбранный IGP путь может быть не лучшим для пользователя.

Для преодоления таких ограничений были развёрнуты различные виды организации трафика (Traffic Engineering или TE), включая RSVP-TE и SR-TE, где компонент TE отвечает за расчёт путей на основе дополнительных показателей и/или ограничений. Такие пути нужно поместить в таблицы пересылки в дополнение или на замену исходных путей, рассчитанных IGP. Часто применяются туннели для представления организованных путей и механизмов, подобных описанному в [RFC3906], служащие заменой для исходных путей IGP.

Этот документ задаёт набор расширений для IS-IS, OSPFv2 и OSPFv3, позволяющих маршрутизатору анонсировать TLV, которые указывают (a) тип расчёта и (b) метрики, а также (c) описывают ограничения топологии, применяемые при расчёте лучшего пути в топологии с ограничениями. Эту комбинацию типа расчёта, типа метрики и ограничений называют определением гибкого алгоритма (Flexible Algorithm Definition или FAD). Маршрутизатор, передающий такие TLV, задаёт значение Flex-Algorithm для выбранной комбинации FAD.

Этот документ также задаёт для маршрутизаторов способ использовать IGP для связывания конкретного Flex-Algorithm с Prefix-SID маршрутизации по сегментам (Segment Routing или SR) с плоскостью данных MPLS (SR-MPLS) [RFC8660] или локаторами SR через IPv6 (SRv6) [RFC8986]. Каждый такой Prefix-SID или локатор SRv6 тогда представляет путь, рассчитанный в соответствии с указанным Flex-Algorithm. В SRv6 это локатор, а не идентификатор сегмента (Segment Identifier или SID), держит привязку алгоритма.

2. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Терминология

В этом разделе даны определения часто используемых в документе терминов.

Flexible Algorithm Definition (FAD)

Определение гибкого алгоритма – (a) тип расчёта, (b) тип метрики, (c) набор ограничений.

Flex-Algorithm

Числовой идентификатор из диапазона 128-255, связанный через конфигурацию с FAD.

Flexible Algorithm Participation

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

IGP Algorithm

Значение из реестра IGP Algorithm Types в группе реестров Interior Gateway Protocol (IGP) Parameters. Алгоритмы IGP представляются триплетом (calculation-type, metric-type, constraints), где второй и третий элементы необязательны.

ABR

Area Border Router – граничный маршрутизатор области. В терминолонии IS-IS называется также маршрутизатором уровня 1 (L1) или уровня 2 (L2).

ASBR

Autonomous System Border Router – граничный маршрутизатор автономной системы.

4. Гибкий алгоритм

При вычислении пути через сеть можно применять много разных ограничений. Некоторые сети развёрнуты как несколько плоскостей и простая форма ограничений может быть связана с использованием конкретной плоскости. Более сложные ограничения могут включать ту или иную расширенную метрику, как описано в [RFC8570]. Возможны также ограничений связанные с выбором определённых каналов или исключением каналов с определённой близостью (affinity). Допускается сочетание разных ограничений.

Для максимальной гибкости предоставляется механизм, позволяющий маршрутизатору указать конкретный тип расчёт (calculation-type) и метрики (metric-type), описать набор ограничений и назначить числовой идентификатор (Flex-Algorithm) такой комбинации. Сопоставление Flex-Algorithm с его предназначением является гибким и задаётся пользователем. Пока у всех маршрутизаторов домена есть общее представление Flex-Algorithm, расчёт маршрутов будет согласованным и трафик не будет попадать в петли.

Набор из (a) типа расчёта, (b) типа метрики и (c) ограничений называют определением гибкого алгоритма (FAD). Flex-Algorithm – это числовой идентификатор из диапазона 128-255, связанный через конфигурацию с FAD.

В реестре IANA IGP Algorithm Types задан набор значений для алгоритмов IGP, где для гибких алгоритмов выделены значения 128-255.

5. Анонсирование определения гибкого алгоритма

Для гарантии отсутствия петель пересылке на путях, рассчитанных с конкретным Flex-Algorithm, все маршрутизаторы, (a) настроенные на участие в определённом Flex-Algorithm и (b) находящиеся в одной области анонсирования FAD, должны согласовать определение Flex-Algorithm, как описано в последующих параграфах.

5.1. IS-IS FAD Sub-TLV

IS-IS Flexible Algorithm Definition (FAD) sub-TLV применяется для анонсирования определения Flex-Algorithm. IS-IS FAD sub-TLV анонсируются как sub-TLV в IS-IS Router CAPABILITY TLV (242), определённом в [RFC7981]. Формат IS-IS FAD sub-TLV приведён ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |Flex-Algorithm |  Metric-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Calc-Type   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sub-TLVs                             |
   +                                                               +
   |                            ...                                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Число октетов в зависимости от включённых sub-TLV.

Flex-Algorithm

Номер гибкого алгоритма – 1-октетное значение от 128 до 255, включительно.

Metric-Type

Тип метрики из реестра IANA IGP Metric-Type (параграф 18.1.2) для использования в расчётах. Заданы 3 значения:

Метрика IGP

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC8570], представленная как определяемый приложением атрибут канала в соответствии с [RFC8919] и разделом 12 этого документа.

Traffic Engineering Default Metric в соответствии с параграфом 3.7 в [RFC5305], представленная как определяемый приложением атрибут канала в соответствии с [RFC8919] и разделом 12 этого документа.

Calc-Type

Тип расчёта – значение от 0 до 127 (включительно) из реестра IANA IGP Algorithm Types в группе реестрв Interior Gateway Protocol (IGP) Parameters. Алгоритмы IGP из диапазона 0-127 имеют триплет (cтип расчета, тип метрики, ограничения). При использовании для задания calculation-type в FAD sub-TLV применяется лишь calculation-type для соответствующего IGP Algorithm, наследование метрики и ограничений недопустимо. Если требуемым типом расчёта является Shortest Path First, в поле должно помещаться значение 0.

Priority

Значение от 0 до 255 (включительно), задающее приоритет анонса. Большее значение указывает более высокий приоритет. Использование приоритета описано в параграфе 5.3. Базовая обработка FAD TLV.

Sub-TLVs

Необязательные sub-TLV.

IS-IS FAD sub-TLV можно анонсировать в пути с коммутацией по меткам (Label Switched Path или LSP) с любым номером. Маршрутизатор IS-IS может анонсировать более 1 IS-IS FAD sub-TLV для данного гибкого алгоритма (см. 6. Sub-TLV для IS-IS FAD Sub-TLV).

IS-IS FAD sub-TLV имеет область (уровень) действия. В Router Capability TLV с FAD sub-TLV должен быть сброшен флаг S.

Маршрутизатор IS-IS L1/L2 можно настроить для регенерации выигравшего FAD с уровня 2 без изменений в область уровня 1. Регенерация FAD sub-TLV from с уровня 2 на уровень 1 определяется маршрутизатором L1/L2, а не источником анонса FAD на уровне 2. В таких случаях регенерированный FAD sub-TLV будет анонсироваться в Router Capability TLV уровня 1, исходящими от маршрутизатора L1/L2.

Маршрутизатору L1/L2 недопустимо регенерировать какие-либо FAD sub-TLV с уровня 1 на уровень 2.

5.2. OSPF FAD TLV

OSPF FAD TLV анонсируются как TLV верхнего уровня в Router Information (RI) Link State Advertisement (LSA), заданных в [RFC7770]. Формат OSPF FAD TLV показан на рисунке

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |   Metric-Type |   Calc-Type   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sub-TLVs                           |
   +                                                               +
   |                               ...                             |

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Число октетов в зависимости от включённых sub-TLV.

Flex-Algorithm

Номер гибкого алгоритма – 1-октетное значение от 128 до 255, включительно.

Metric-Type

Тип метрики из реестра IANA IGP Metric-Type (параграф 18.1.2) для использования в расчётах. Заданы 3 значения:

Метрика IGP

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC7471], представленная как определяемый приложением атрибут канала в соответствии с [RFC8920] и разделом 12 этого документа.

Traffic Engineering Default Metric в соответствии с параграфом 2.5.5 в [RFC3630], представленная как определяемый приложением атрибут канала в соответствии с [RFC8920] и разделом 12 этого документа.

Calc-Type

См. описание в параграфе 5.1.

Priority

См. описание в параграфе 5.1.

Sub-TLVs

Необязательные sub-TLV.

При получении нескольких OSPF FAD TLV для одного гибкого алгоритма от данного маршрутизатора получатель должен использовать первый экземпляр TLV в RI LSA. Если OSPF FAD TLV для одного Flex-Algorithm присутствуют в нескольких RI LSA с разными сферами лавинной рассылки, должен использоваться OSPF FAD TLV из RI LSA с лавинной рассылкой по области (area-scoped). Если OSPF FAD TLV для одного и того же алгоритма присутствует в разных RI LSA с одинаковой лавинной рассылкой, должен выбираться OSPF FAD TLV в RI LSA с численно наименьшим Instance ID, а последующие экземпляры OSPF FAD TLV должны игнорироваться.

RI LSA могут анонсироваться в любые определённые неинтерпретируемые (opaque) области лавинной рассылки (канал, область AS). Для анонсирования OSPF FAD TLV требуется лавинная рассылка в область (area-scoped). Лавинную рассылку в AS не следует применять, если локальная политика маршрутизатора-источника не указывает лавинную рассылку по домену (domain-wide.

5.3. Базовая обработка FAD TLV

В этом параграфе описана независимая от протокола обработка FAD TLV (OSPF) и FAD sub-TLV (IS-IS). В тексте используется обозначение FAD TLV, но содержимое параграфе применимо и к sub-TLV при использовании IS-IS.

Значение Flex-Algorithm должно быть от 128 до 255 (включительно), в ином случае FAD TLV должен игнорироваться. Анонсировать Flex-Algorithm нужно лишь части маршрутизаторов, участвующих в конкретном гибком алгоритме. Каждый маршрутизатор, настроенный на участие в определённом Flex-Algorithm должен выбрать определение Flex-Algorithm Definition на основе приведённых ниже правил с соблюдением их порядка. Это позволяет согласовать выбор FAD в случаях, когда разные маршрутизаторы анонсируют разные определения для данного Flex-Algorithm.

Из анонсов FAD в области (включая локально созданные и полученные) нужно выбрать анонс с наибольшим значением приоритета.
При наличии нескольких FAD с одинаковым приоритетом выбирается исходящее от маршрутизатора с наибольшим System-ID для IS-IS или Router ID для OSPFv2 и OSPFv3. Описание System-ID для IS-IS приведено в [ISO10589]. Для OSPFv2 и OSPFv3 стандартные Router ID описаны в [RFC2328] и [RFC5340].

Определение FAD, выбранное по этим правилам называют выигрышным (winning) FAD.

Маршрутизаторы, не настроенные на участие в конкретном Flex-Algorithm, должны игнорировать анонсы FAD TLV для таких Flex-Algorithm. Маршрутизатор, не участвующий в конкретном Flex-Algorithm, может анонсировать FAD для алгоритма. Принимающие маршрутизаторы должны рассматривать анонсы FAD независимо от участия их источника в Flex-Algorithm.

Любые изменения FAD могут приводить к временному нарушению трафика, передаваемого на основе путей, рассчитанных по этому Flex-Algorithm. Это похоже на влияние других событий, требующих схождения в масштабе сети.

Если узел настроен на участие в гибком алгоритме, но не имеет доступного FAD или выбранное определение включает не поддерживаемое узлом значение calculation-type, metric-type, constraint, flag или sub-TLV, узел должен прерывать участие в этом алгоритме. Это предполагает, что недопустимо анонсировать участие в алгоритме, как указано в разделе 11 и узел должен удалить все связанные с этим алгоритмом состояния пересылки.

Определение Flex-Algorithm не зависит от топологии и применяется во всех топологиях, где маршрутизатор участвует.

6. Sub-TLV для IS-IS FAD Sub-TLV

Одним из ограничений IS-IS [ISO10589] является размер TLV/sub-TLV – не более 255 октетов. Для FAD sub-TLV имеется множество sub-sub-TLVs (см. ниже). Для данного Flex-Algorithm может оказаться, что общее число октетов для FAD превосходит максимальный размер, поддерживаемый в одном FAD sub-TLV. В таком случае FAD можно разделить на несколько sub-TLV, содержимое которых будет объединяться для полного определения Flex-Algorithm. При этом фиксированная часть FAD (5.1. IS-IS FAD Sub-TLV) должна быть идентична во всех FAD sub-TLV для данного Flex-Algorithm из данной промежуточной системы (IS). Если фиксированные части таких FAD sub-TLV различаются, должна использоваться фиксированная часть FAD sub-TLV из первого появления в LSP с наименьшим номером от данной IS.

Любая спецификация, задающая новый IS-IS FAD sub-sub-TLV, должна указывать, может ли FAD sub-TLV присутствовать в нескольких экземплярах в наборе FAD sub-TLV для данного Flex-Algorithm из данной IS и как их обрабатывать, если несколько экземпляров разрешено.

6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для исключения каналов из расчёта пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Exclude Admin Group (FAEAG) sub-TLV служит для анонсирования правила исключения, применяемого при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS FAEAG sub-TLV является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS FAEAG sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS FAEAG sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS FAEAG sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для включения каналов в расчёт пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Include-Any Admin Group (FAEAG) sub-TLV служит для анонсирования правила включения любых каналов при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS Flexible Algorithm Include-Any Admin Group является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для включения каналов в расчёт пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Include-All Admin Group (FAEAG) sub-TLV служит для анонсирования правила включения всех каналов при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS Flexible Algorithm Include-All Admin Group является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS Flexible Algorithm Include-All Admin Group sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV

IS-IS Flexible Algorithm Definition Flags (FADF) sub-TLV – это sub-TLV для IS-IS FAD sub-TLV. Формат показан на нисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Число октетов в поле Flags.

Flags

                       0 1 2 3 4 5 6 7...
                      +-+-+-+-+-+-+-+-+...
                      |M| | |          ...
                      +-+-+-+-+-+-+-+-+...

При установленном флаге должна применяться связанная с Flex-Algorithm метрика для расчёта межобластных и внешних префиксов. Флаг не применим для префиксов, анонсируемых как локаторы SRv6.

Задан новый реестр IANA IGP Flexible Algorithm Definition Flags для выделения битов поля Flags (см. параграф 18.2).

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

IS-IS FADF sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS FADF sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS FADF sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

Если IS-IS FADF sub-TLV нет в IS-IS FAD sub-TLV, предполагается, что все биты флагов сброшены (0).

Если узел настроен на участие в конкретном гибком алгоритме, а выбранное определение Flex-Algorithm содержит в IS-IS FADF sub-TLV неподдерживаемый узлом флаг, узел должен выйти из участия в этом алгоритме. В будущем могут быть определены новые флаги и реализация должна проверять все биты в полученном IS-IS FADF sub-TLV, а не только определённые в данный момент.

M-flag недопустимо применять при расчёте достижимости префиксов SRv6 Locator.

6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV

FAD может задавать группы каналов с общим риском (Shared Risk Link Group или SRLG), которые оператор хочет исключить из расчёта пути по гибкому алгоритму. IS-IS Flexible Algorithm Exclude SRLG (FAESRLG) sub-TLV служит для анонсирования правила исключения при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS FAESRLG sub-TLV является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Shared Risk Link Group Value             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Определяется числом значений SRLG и должно быть кратно 4 октетам.

Shared Risk Link Group Value

Значение SRLG в соответствии с [RFC5307].

IS-IS FAESRLG sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

The IS-IS FAESRLG sub-TLV может неоднократно присутствовать в наборе FAD sub-TLV для данного гибкого алгоритма из данной IS. Это может потребоваться в случаях, когда общее число значение SRLG ведёт к превышению допустимого размера FAD sub-TLV. В таких случаях получатель должен объединять все значения из IS-IS FAESRLG sub-TLV в наборе.

7. Sub-TLV для OSPF FAD TLV

7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV

OSPF Flexible Algorithm Exclude Admin Group (FAEAG) sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF FAEAG sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV

OSPF Flexible Algorithm Include-Any Admin Group sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV

OSPF Flexible Algorithm Include-All Admin Group sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV

OSPF Flexible Algorithm Definition Flags (FADF) sub-TLV – это sub-TLV для OSPF FAD TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Число октетов в поле Flags. Должно быть кратно 4 октетам.

Flags

                       0 1 2 3 4 5 6 7...
                      +-+-+-+-+-+-+-+-+...
                      |M| | |          ...
                      +-+-+-+-+-+-+-+-+...

Задан новый реестр IANA IGP Flexible Algorithm Definition Flags для выделения битов поля Flags (см. параграф 18.2).

OSPF FADF sub-TLV недопустимо включать более 1 раза в один OSPF FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD sub-TLV.

Если OSPF FADF sub-TLV нет в OSPF FAD sub-TLV, предполагается, что все биты флагов сброшены (0).

Если узел настроен на участие в конкретном гибком алгоритме, а выбранное определение Flex-Algorithm содержит в OSPF FADF sub-TLV неподдерживаемый узлом флаг, узел должен выйти из участия в этом алгоритме. В будущем могут быть определены новые флаги и реализация должна проверять все биты в полученном OSPF FADF sub-TLV, а не только определённые в данный момент.

M-flag недопустимо применять при расчёте достижимости префиксов SRv6 Locator.

7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV

OSPF Flexible Algorithm Exclude SRLG (FAESRLG) sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Shared Risk Link Group Value                |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Определяется числом значений SRLG и должно быть кратно 4 октетам.

Shared Risk Link Group Value

Значение SRLG в соответствии с [RFC5307].

OSPF FAESRLG sub-TLV недопустимо включать более 1 раза в один OSPF FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD sub-TLV.

8. IS-IS Flexible Algorithm Prefix Metric Sub-TLV

IS-IS Flexible Algorithm Prefix Metric (FAPM) sub-TLV поддерживает анонсирование связанной с Flex-Algorithm метрики для анонса данного префикса. IS-IS FAPM sub-TLV – это sub-TLV для TLV 135, 235, 236, 237. Формат показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |Flex-Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

5 октетов

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Metric

4 октета сведений о метрике.

IS-IS FAPM sub-TLV может включаться в родительский TLV в нескольких экземплярах. При указании нескольких экземпляров с одним Flex-Algorithm должен применяться первый экземпляр, а остальные должны игнорироваться.

Если префикс анонсируется с метрикой префикса Flex-Algorithm, превышающей MAX_PATH_METRIC [RFC5305], этот префикс недопустимо учитывать при расчёте по гибкому алгоритму.

Применение метрики префиксов Flex-Algorithm описано в разделе 13. Расчёт путей по гибкому алгоритму.

IS-IS FAPM sub-TLV недопустимо анонсировать как sub-TLV для IS-IS SRv6 Locator TLV [RFC9352]. IS-IS SRv6 Locator TLV включает поля алгоритма и метрики, которые должны использоваться взамен. Если FAPM sub-TLV присутствует как sub-TLV в IS-IS SRv6 Locator TLV полученного LSP, такой FAPM sub-TLV должен игнорироваться.

9. OSPF Flexible Algorithm Prefix Metric Sub-TLV

The OSPF Flexible Algorithm Prefix Metric (FAPM) sub-TLV поддерживает анонсирование связанной с Flex-Algorithm метрики для анонса данного префикса. OSPF FAPM sub-TLV является sub-TLV для:

OSPFv2 Extended Prefix TLV [RFC7684];
указанных ниже OSPFv3 TLV, заданных в [RFC8362]:
- Inter-Area Prefix TLV;
- External-Prefix TLV.

Формат OSPF FAPM sub-TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |     Flags     |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Metric                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3 для OSPFv2, 26 для OSPFv3.

Length

8 октетов.

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Flags

1-октетное значение

                       0 1 2 3 4 5 6 7
                      +-+-+-+-+-+-+-+-+
                      |E|             |
                      +-+-+-+-+-+-+-+-+

Флаг в позиции 0, указывающий тип внешней метрики. Установленный бит указывает внешнюю метрику типа 2. Флаг применим лишь для внешних префиксов OSPF и «не вполне тупиковым» (Not-So-Stubby Area или NSSA) внешним префиксам. Это семантически эквивалентно биту E в Приложении A.4.5 к [RFC2328] и Приложении A.4.7 к [RFC5340] для OSPFv2 и OSPFv3, соответственно.

Биты 1 – 7

Должны сбрасываться инициатором и игнорироваться получателем.

Reserved

Должно устанавливаться в 0 и игнорироваться при получении.

Metric

4 октета сведений о метрике.

OSPF FAPM sub-TLV может включаться в родительский TLV в нескольких экземплярах. При указании нескольких экземпляров с одним Flex-Algorithm должен применяться первый экземпляр, а остальные должны игнорироваться.

Применение метрики префиксов Flex-Algorithm описано в разделе 13. Расчёт путей по гибкому алгоритму.

10. Гибкий алгоритм OSPF для анонсирования доступности ASBR

OSPF ABR анонсирует доступность ASBR в подключённых областях, чтобы позволить маршрутизаторам этих областей выполнять расчёт маршрутов для внешних префиксов, анонсируемых ASBR. Для расчётов внешних префиксов Flex-Algorithm нужны также расширения OSPF для анонсирования связанной с Flex-Algorithm доступности и метрики для ASBR, как описано в параграфе 13.1. Множество областей и доменов.

10.1. OSPFv2 Extended Inter-Area ASBR LSA

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA – это OSPF Opaque LSA [RFC5250], применяемый для анонсирования дополнительных атрибутов, связанных с доступностью OSPFv2 ASBR, который является внешним для области, но внутренним для домена OSPF. Семантически OSPFv2 EIA-ASBR LSA является эквивалентом summary-LSA типа 4 с фиксированным форматом [RFC2328]. В отличие от сводного LSA типа 4, Link State ID (LSID) в EIA-ASBR LSA не содержит ASBR Router ID, этот идентификатор передаётся в теле LSA. OSPFv2 EIA-ASBR LSA анонсируется маршрутизатором OSPFv2 ABR и рассылается лавинно внутри области (area-scoped).

OSPFv2 ABR генерирует EIA-ASBR LSA для ASBR когда он анонсирует для того summary-LSA типа 4 и нужно анонсировать 4 дополнительных атрибута для ASBR сверх передаваемых в Type 4 summary-LSA с фиксированным форматом. Маршрутизатору OSPFv2 ABR недопустимо анонсировать EIA-ASBR LSA для ASBR, которому он не анонсирует сводный LSA типа 4. Это гарантирует, что ABR не генерирует EIA-ASBR LSA для ASBR, к которому у него нет доступности при расчёте базовой топологии OSPFv2. OSPFv2 ABR не следует анонсировать EIA-ASBR LSA для ASBR при отсутствии дополнительных атрибутов для этого ASBR.

Формат OSPFv2 EIA-ASBR LSA показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |   LS Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Opaque Type  |                 Opaque ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

Поля LS age и Options определены в Приложении A.4.1 к [RFC2328].

Поле LS Type должно иметь значение 10, указывающее, что лавинная рассылка Opaque LSA происходит в локальной области [RFC5250].

Поле Opaque Type в OSPFv2 EIA-ASBR LSA имеет значение 11 и служит для разделения разных типов OSPFv2 Opaque LSA, описанных в разделе 3 [RFC5250].

Поле Opaque ID содержит произвольное значение , служащее для поддержки множества OSPFv2 EIA-ASBR LSA. Для OSPFv2 EIA-ASBR LSA поле Opaque ID не имеет семантического смысла кроме разделения OSPFv2 EIA-ASBR LSA, исходящих от одного OSPFv2 ABR. Если множество OSPFv2 EIA-ASBR LSA указывает один ASBR, следует использовать атрибуты из Opaque LSA с наименьшим Opaque ID.

Поля Advertising Router, LS sequence number и LS checksum определены в Приложении A.4.1 к [RFC2328].

Поле Length определено в Приложении A.4.1 к [RFC2328] и представляет общий размер (в октетах) Opaque LSA, включая заголовок LSA и все TLV (в том числе заполнение).

TLV в теле OSPFv2 EIA-ASBR LSA имеют такой же формат, который применяется расширениями OSPFv2 для организации трафика (TE) [RFC3630]. Переменный раздел TLV состоит из 1 или нескольких вложенных TLV, которые называют sub-TLV. Поле Length в TLV указывает размер поля значения в октетах (TLV без значения имеют Length = 0). TLV дополняются до 4-октетной границы, заполнение не учитывается в поле Length (т. е. при 3-октетном значении поле Length = 3, но общий размер TLV составит 8 октетов). Вложенные TLV также выравниваются по 32-битовым границам. Например при 1-октетном значении будет Length = 1 и 3 октета заполнения в конце поля значения. Для заполнения применяются нули (0).

10.1.1. OSPFv2 Extended Inter-Area ASBR TLV

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) TLV – это TLV верхнего уровня для OSPFv2 EIA-ASBR LSA и служит для анонсирования дополнительных атрибутов, связанных с достижимостью ASBR. Формат OSPFv2 EIA-ASBR TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ASBR Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Число октетов³.

ASBR Router ID

4 октета OSPF Router ID маршрутизатора ASBR, чья информация передается.

Sub-TLVs

Переменный набор sub-TLV.

В каждом анонсе OSPFv2 EIA-ASBR LSA должен содержаться только 1 OSPFv2 EIA-ASBR TLV, а получатель должен игнорировать все остальные экземпляры этого TLV.

OSPFv2 EIA-ASBR TLV должен присутствовать в OSPFv2 EIA-ASBR LSA и должен включать хотя бы 1 sub-TLV, в противном случае получатель должен игнорировать OSPFv2 EIA-ASBR LSA.

10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV

OSPF Flexible Algorithm ASBR Metric (FAAM) sub-TLV поддерживает анонсы связанной с Flex-Algorithm метрики, относящейся к доступности данного ASBR, маршрутизатором ABR.

OSPF FAAM sub-TLV является sub-TLV для:

OSPFv2 Extended Inter-Area ASBR TLV, заданного в параграфе 10.1. OSPFv2 Extended Inter-Area ASBR LSA;
OSPFv3 Inter-Area-Router TLV, заданного в [RFC8362].

Формат OSPF FAAM sub-TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Metric                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1 для OSPFv2, 33 для OSPFv3.

Length

8 октетов.

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Reserved

3 октета, которые должны устанавливаться в 0 и игнорироваться при получении.

Metric

4 октета сведений о метике.

OSPF FAAM sub-TLV может присутствовать в родительском TLV в нескольких экземплярах. При наличии нескольких экземпляров для одного Flex-Algorithm должен использоваться первый, в прочие должны игнорироваться.

Анонс доступности ASBR с использованием OSPF FAAM sub-TLV внутри OSPFv2 EIA-ASBR LSA соответствует параграфу 12.4.3 в [RFC2328], а внутри OSPFv3 E-Inter-Area-Router-LSA – параграфу 4.8.5 в [RFC5340]. Достижимость ASBR оценивается в контексте когкретного Flex-Algorithm.

Метрика FAAM, рассчитанная ABR, будет равна метрике достижения ASBR для данного Flex-Algorithm в исходной области или кумулятивной метрике через маршрутизаторы ABR, когда ASBR находится в удалённой области. Это по природе похоже на то, как устанавливается метрика при расчёте метрики достижимости ASBR с принятым по умолчанию алгоритмом для OSPFv2 Type 4 ASBR summary-LSA и OSPFv3 Inter-Area-Router-LSA.

OSPF ABR недопустимо включать OSPF FAAM sub-TLV с конкретным Flex-Algorithm в свой анонс доступности для ASBR между областями, пока ASBR не доступен в контексте этого Flex-Algorithm.

OSPF ABR должен включать OSPF FAAM sub-TLV как часть анонса достижимости ASBR между областями для любого Flex-Algorithm, где выигрышный FAD включает флаг M и ASBR доступен в контексте данного Flex-Algorithm.

Маршрутизаторы OSPF должны использовать OSPF FAAM sub-TLV для расчёта достижимости ASBR, если выигрышный FAD для конкретного Flex-Algorithm включает флаг M. Маршрутизаторам OSPF недопустимо использовать OSPF FAAM sub-TLV для расчёта достижимости ASBR для конкретного Flex-Algorithm, если выигрышный FAD для такого Flex-Algorithm не включает флаг M. Взамен должны применяться OSPFv2 Type 4 summary-LSA или OSPFv3 Inter-Area-Router-LSA, как указано в параграфе 16.2 [RFC2328] и параграфе 4.8.5 [RFC5340] для OSPFv2 и OSPFv3, соответственно.

Обработка нового или изменённого OSPF FAAM sub-TLV вызывает обработку внешних маршрутов, аналогично описанному в параграфе 16.5 [RFC2328] для OSPFv2 и параграфе 4.8.5 [RFC5340] для OSPFv3, с конкретным Flex-Algorithm. Расчёт внешнего маршрута OSPF и NSSA следует ограничивать гибкими алгоритмами, для которых выигрышные FAD включают флаг M.

Обработка OSPF FAAM sub-TLV не требует наличия эквивалентного OSPFv2 Type 4 summary-LSA или OSPFv3 Inter-Area-Router-LSA, анонсируемого тем же ABR внутри области. Наличие базового LSA не обязательно для применения расширенного LSA с OSPF FAAM sub-TLV.

11. Анонсирование участия узла в Flex-Algorithm

Алгоритм и IS, анонсирующие своё участие, принимают участие в данном Flex-Algorithm.

Пути для различных плоскостей данных могут рассчитываться с конкретным Flex-Algorithm. Каждая плоскость данных применяет свою пересылку по таким путям Flex-Algorithm. Для гарантиии наличия связанной с плоскостью данных пересылки для определённого Flex-Algorithm маршрутизатор должен анонсировать своё участие в данном Flex-Algorithm для каждой плоскости данных. Некоторые плоскости данных могут иметь общие анонсы участия (например, SR-MPLS и SRv6). Анонсирования участия в любом конкретном Flex-Algorithm в любой плоскости данных, регулируется условием, заданным в параграфе 5.3. Базовая обработка FAD TLV.

11.1. Анонсирование участия узла в SR

В [RFC8665], [RFC8666], [RFC8667] (расширения IGP SR) описывают применение алгоритма SR для расчёта лучшего пути IGP. Маршрутизаторы анонсируют поддержку SR-Algorithm как свойство узла в соответствии с упомянутыми выше расширениями IGP SR. Для анонсирования участия в конкретном Flex-Algorithm для SR, включая SR-MPLS и SRv6, должно анонсироваться значение Flex-Algorithm в SR-Algorithm TLV (OSPF) или sub-TLV (IS-IS).

Анонсы участия в гибком алгоритме маршрутизации по сегментам не зависят от топологии. Когда маршрутизатор анонсирует участие в SR-Algorithm, это применяется ко всем топологиям, в который участвует анонсирующий узел.

11.2. Анонсирование участия узла в других плоскостях данных

В этом параграфе рассмотрены соображения, связанные с возможностями других плоскостей данных объявить своё участие в конкретном Flex-Algorithm. Анонсы связанного с плоскостью данных участия в Flex-Algorithm могут зависеть от топологии и могут быть независимыми от неё в зависимости от самой плоскости данных. Связанные с плоскостью данных анонсы участия в Flex-Algorithm должны определяться для каждой плоскости данных, но в документе это не рассматривается.

12. Анонсирование атрибутов канала для Flex-Algorithm

При расчёте путей по гибкому алгоритму могут использоваться различные атрибуты каналов. Например, правила включения и исключения каналов по их близости (affinitY) может быть частью FAD, как указано в разделах 6 и 7.

Зависящие от приложения атрибуты каналов (заданные в [RFC8919] или [RFC8920]), которые применяются при расчёте Flex-Algorithm, должны использовать зависящие от приложения анонсы атрибутов канала (Application-Specific Link Attribute или ASLA), заданные в [RFC8919] или [RFC8920], если (для IS-IS) не установлен флаг L-flag в анонсе ASLA. Если флаг L установлен, должны применяться традиционные анонсы с учётом процедур и ограничений, заданных в параграфе 4.2 [RFC8919] и разделе 6. Sub-TLV для IS-IS FAD Sub-TLV.

Обязательное использование анонсов ASLA применяется к атрибутам каналов, специально отмеченным в этом документе (Min Unidirectional Link Delay, TE Default Metric, Administrative Group, Extended Administrative Group, Shared Risk Link Group), а также к любым другим атрибутам каналов, которые в будущем могут применяться для поддержки Flex-Algorithm.

Определён бит идентификатора приложения (Application Identifier Bit), указывающий, что анонс ASLA связан с приложением Flex-Algorithm. Этот бит устанавливается в маске стандартных битов приложения (Standard Application Bit Mask или SABM), определённой в [RFC8919] и [RFC8920]:

   Bit 3:  Flexible Algorithm (X-bit)

Анонсы ASLA Admin Group для использования гибким алгоритмом могут использовать кодирование Administrative Group или Extended Administrative Group.

Получатель, поддерживающий эту спецификацию, должен воспринимать ASLA Administrative Group и Extended Administrative Group TLV, как указано в [RFC8919] или [RFC8920]. В случае IS-IS при установленном флаге L в анонсе ASLA (см. параграф 4.2 с [RFC8919] получатель должен быть способен воспринимать Administrative Group TLV, заданные в [RFC5305], и Extended Administrative Group TLV, заданные [RFC7308].

13. Расчёт путей по гибкому алгоритму

Маршрутизатор должен быть настроен на участие в данном Flex-Algorithm и должен выбрать FAD на основе правил, заданных в параграфе 5.3. Базовая обработка FAD TLV, прежде чем он сможет рассчитывать пути по данному Flex-Algorithm.

При вычислении пути по гибкому алгоритму не применяется проверки двухсторонней связности, но при расчёте применяется результат независимой от Flex-Algorithm проверки двухсторонней связности.

Как указано в разделе 11, участие в любом конкретном Flex-Algorithm должно анонсироваться по плоскостям данных. Расчёт путей по любому конкретному гибкому алгоритму зависит от плоскости данных. Несколько плоскостей данных могут одновременно применять один гибкий алгоритм и FAD для него. Трафик каждой плоскости данных будет пересылаться на основе записей пересылки для этой конкретной плоскости данных. Определение FAD не зависит от плоскости данных и применяется всеми плоскостями данных Flex-Algorithm.

Обработка плоскостями данных узлов, не участвующих в гибком алгоритме, зависит от конкретной плоскости данных. Если плоскость данных желает при расчёте пути Flex-Algorithm учитывать лишь участвующие в алгоритме узлы, все узлы, которые не анонсируют своего участия в данном Flex-Algorithm для этой плоскости данных, должны вырезаться из топологии. Маршрутизация SR, включая SR-MPLS и SRv6, является плоскостью данных, которая должна применять такое вырезание при расчёте путей Flex-Algorithm.

При расчёте пути для данного Flex-Algorithm должны использоваться значения metric-type и calculation-type из FAD (5. Анонсирование определения гибкого алгоритма).

FAD может включать различные правила включения и исключения, а для указания конкретного бита в Admin Group или Extended Admin Group применяется термин color (цвет).

Для всех каналов топологии должны применяться указанные ниже правила (в приведённом порядке) вырезания каналов из топологии при расчётах Flex-Algorithm.

Проверяется наличие правил исключения Administrative Group в FAD. Если такие правила имеются, проверяется, не установлен ли для канала цвет, являющийся частью правила, и при обнаружении такого цвета канал должен исключаться из расчёта.
Проверяется наличие правил исключения SRLG в FAD. Если такие правила имеются, проверяется, входит ли канал в исключаемую SRLG, и при обнаружении вхождения канал должен исключаться из расчёта.
Проверяется наличие правил включения любой (include-any) Administrative Group в FAD. Если такие правила имеются, проверяется, установлен ли для канала цвет, являющийся частью правила, и при отсутствии такого цвета канал должен исключаться из расчёта.
Проверяется наличие правил включения всех (include-all) Administrative Group в FAD. Если такие правила имеются, проверяется, установлены ли для канала все цвета, являющиеся частью правила, и если не установлены все эти цвета, канал должен исключаться из расчёта.
Если в FAD применяется что-либо, отличное от метрики IGP (5. Анонсирование определения гибкого алгоритма), и такая метрика не анонсируется для конкретного канала в топологию, где выполняется расчёт, такой канал должен исключаться из расчёта. Метрику со значением 0 недопустимо учитывать в этом случае.

13.1. Множество областей и доменов

Любой расчёт дерева кратчайших путей IGP (Shortest Path Tree) ограничен одной областью. Это относится и к расчётам Flex-Algorithm. С учётом того, что рассчитывающий маршрутизатор не видит топологии следующих областей или домена, связанный с Flex-Algorithm путь к префиксу, проходящий через разные области или домены, будет рассчитываться лишь для локальной области. Выходной маршрутизатор L1/L2 (ABR в OSPF) или ASBR для разных доменов будет выбираться на основе лучшего пути для данного Flex-Algorithm в локальной области и такой выходной маршрутизатор ABR или ASBR будет отвечать за расчёт лучшего пути Flex-Algorithm через следующую область или домен. Это может привести к созданию пути, который будет неоптимальным из-за ограничений Flex-Algorithm. Если ABR или ASBR не имеет доступа к префиксу для данного Flex-Algorithm в следующей области или домене, трафик может отбрасываться таким ABR/ASBR.

Для расчёта оптимального сквозного пути через несколько областей или доменов для любого Flex-Algorithm в разделах 8 и 9 определена метрика префикса гибкого алгоритма (FAPM). При расчёте внешних маршрутов для префиксов от ASBR в удалённых областях OSPF в параграфе 10.2 определена метрика FAAM для ABR, указывающая доступность ASBR вместе с метрикой для конкретного Flex-Algorithm.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, маршрутизатор ABR или ASBR должен включать FAPM (разделы 8 и 9) при анонсировании префикса, доступного в данном Flex-Algorithm между областями или доменами. Такая метрика будет совпадать с метрикой для достижения префикса в исходной области или домене для этого Flex-Algorithm. Это похоже на задание метрики при анонсировании между областями или доменами метрики для принятого по умолчанию алгоритма. Когда префикс недоступен в исходной области или домене в конкретном Flex-Algorithm, маршрутизатору ABR или ASBR недопустимо включать FAPM для Flex-Algorithm при анонсировании префикса между областями или доменами.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, метрика FAPM должна применяться при расчёте доступности внешнего или междоменного префикса. Если FAPM для Flex-Algorithm не включается в анонс доступности межобластного или внешнего префикса, такой префикс должен считаться недоступным в этом Flex-Algorithm. В случае OSPF для ASBR при отсутствии FAAM в анонсе локальных ABR маршрутизатор ASBR должен считаться недоступным для этого Flex-Algorithm и анонсы внешних префиксов от такого ASBR не учитываются в данном Flex-Algorithm.

Метрику префикса Flex-Algorithm и метрику OSPF Flex-Algorithm ASBR недопустимо применять в расчёте Flex-Algorithm, если выбранное на основе правил параграфа 5.3 определение FAD не включает флаг M, описанный в параграфах 6.4 и 7.4.

Если для случая OSPF при расчёте внешних маршрутов в Flex-Algorithm выигрышный FAD включает флаг M и анонсирующий ASBR находится в удалённой области, метрика будет суммой указнных ниже значений:

метрика FAPM для Flex-Algorithm, анонсированная ASBR с внешним маршрутом;
метрика доступа к ASBR для Flex-Algorithm от локального ABR, т. е. метрика FAAM для этого Flex-Algorithm, анонсированная ABR в локальной области этого ASBR;
зависимая от Flex-Algorithm метрика для доступа к локальному ABR.

По своей природе это похоже на расчёт метрики для маршрутов, полученных от удалённых ASBR в принятом по умолчанию алгоритме с использованием OSPFv2 Type 4 ASBR summary-LSA и OSPFv3 Inter-Area-Router-LSA.

Если определение FAD, выбранное на основе правил из параграфа 5.3, не включает флаг M, для расчёта маршрутов Flex-Algorithm должна применяться метрика IGP, связанная с достижимостью префикса, используемая базовыми протоколами IS-IS и OSPF. При расчёте внешних маршрутов в OSPF достижимость ASBR определяется на основе OSPFv2 Type 4 summary-LSA и OSFPv3 Inter-Area-Router-LSA.

Использовать Flex-Algorithm для достижимости префиксов между областями или доменами при сброшенном флаге M не рекомендуется. Причина заключается в том, что без явного анонса метрики префикса Flex-Algorithm (и анонса метрики Flex-Algorithm ASBR при расчёте внешних маршрутов OSPF) невозможно сделать вывод о доступности ABR или ASBR для межсетевого или междоменного префикса в следующей области или домене для данного Flex-Algorithm. Передача трафика Flex-Algorithm для такого префикса в сторону ABR или ASBR может привести к петле или постоянному отбрасыванию трафика.

В процессе расчёта маршрутов связанная с Flex-Algorithm метрика может превысить максимальное значение, которое может быть выражено 32-битовым числом без знака. В таких случаях при расчёте и в анонсах должно приниматься значение 0xFFFFFFFF.

FAPM недопустимо анонсировать с маршрутами IS-IS L1 или L2 внутри области, OSPFv2 или OSPFv3 внутри области. Если FAPM анонсируется с маршрутами этих типов, такая метрика должна игнорироваться при расчёте достижимости префиксов.

Флаг M в FAD не применим к префиксам, анонсируемым как локаторы SRv6. IS-IS SRv6 Locator TLV [RFC9352] включает поля Algorithm и Metric. При анонсировании SRv6 Locator между областями или доменами должно применяться поле Metric в Locator TLV для IS-IS независимо от флага M в анонсе FAD.

Анонсы внешних префиксов OSPF и NSSA могут включать ненулевой адрес пересылки в анонсах префиксов базового протокола. В таком случае связанная с Flex-Algorithm достижимость внешнего префикса определяется связанной с Flex-Algorithm достижимостью адреса пересылки.

В OSPF процедуры преобразования анонсов внешних префиксов NSSA в анонсы внешних префиксов, выполняемые NSSA ABR [RFC3101], не зависят от Flex-Algorithm. Транслятор NSSA должен включать OSPF FAPM sub-TLV для всех Flex-Algorithm, которые были в исходном анонсе внешнего префикса NSSA от NSSA ASBR в преобразованный анонс внешнего префикса независимо от его участия в этих Flex-Algorithm или доступности NSSA ASBR в них.

Область может быть разделена с точки зрения Flex-Algorithm из-за ограничений и/или метрики, применяемых в ней, с сохранением неразрывности в базовом алгоритме. В таких случаях некоторые адресаты внутри разделённой области могут стать недоступными в этом Flex-Algorithm и не смогут использовать межобластной путь. Это является следствием того, что анонсы доступности межобластных префиксов станут недоступными для внутренних получателей этой области. Рекомендуется минимизировать риск такого разделения за счёт достаточной избыточности внутри области для каждого применяемого Flex-Algorithm.

14. Flex-Algorithm и плоскость пересылки

В этом разделе описано использование путей Flex-Algorithm для пересылки.

14.1. Пересылка MPLS SR для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SR MPLS.

Анонсы Prefix-SID включают значение SR-Algorithm и поэтому связаны с ним. Prefix-SID также связаны с конкретной топологией, которая наследуется от связанного анонса достижимости префикса. Когда анонсированное значение алгоритма является значением Flex-Algorithm, Prefix-SID связывается с путями, рассчитанными по этому Flex-Algorithm в соответствующей топологии.

Путь Flex-Algorithm должен быть установлен в плоскости пересылки MPLS с использования метки MPLS, соответствующей Prefix-SID, анонсированному для этого Flex-Algorithm. Если Prefix-SID для данного Flex-Algorithm неизвестен, соответствующий Flex-Algorithm путь не может быть установлен в плоскости пересылки MPLS.

Трафик, который предполагается маршрутизировать по путям Flex-Algorithm, должен отбрасываться, если такие пути недоступны.

Дополнительные пути без петель (Loop Free Alternate или LFA) paths ([RFC6571] и его варианты) для данного Flex-Algorithm должны рассчитываться с теми же ограничениями, какие применяются для расчёта основных путей с этим Flex-Algorithm. Пути LFA должны использовать только Prefix-SID, анонсированные специально для данного алгоритма. Путям LFA недопустимо использовать Adjacency SID, относящийся к каналу, который был исключён из расчётов Flex-Algorithm.

Если применяется защита LFA для пути данного алгоритма Flex-Algorithm, всем маршрутизаторам области, участвующим в этом алгоритме, следует анонсировать хотя бы один, связанный с Flex-Algorithm, идентификатор Node-SID. Эти Node-SID служат для направления трафика по резервному пути, рассчитанному LFA.

14.2. Пересылка SRv6 для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SRv6.

В SRv6 узлу предоставляется конкретный (топология, алгоритм) локатор для каждой пары топология-алгоритм, поддерживаемой этим узлом. Каждый локатор является агрегатным префиксом для всех SID с совпадающей топологией и алгоритмом, предоставляемых на этом узле.

Анонс локатора SRv6 в IS-IS [RFC9352] включает значение MTID (Multi-Topology Identifier), связывающее локатор с конкретной топологией. Кроме того, анонс SRv6 включает значение алгоритма, явно связывающее локатор с конкретным алгоритмом. Когда значение алгоритма анонсируется с локатором, представляющим Flex-Algorithm, пути к префиксу локатора должны рассчитываться с использованием указанного Flex-Algorithm в связанной топологии.

Записи пересылки для префикса локатора, анонсированного в IS-IS, должны быть установлены в плоскости пересылки принимающих маршрутизаторов с поддержкой SRv6, когда в них участвует соответствующая топология/алгоритм. Записи пересылки для локаторов, связанных с Flex-Algorithm, в которых узел не участвует, недопустимо устанавливать в плоскости пересылки.

Когда локатор связан с Flex-Algorithm, пути LFA к префиксу локатора должны рассчитываться с применением такого Flex-Algorithm в связанной топологии, чтобы гарантировать соблюдение тех же ограничений, что и в расчёте основного пути. Пути LFA должны использовать лишь SRv6 SID, анонсированные специально для данного Flex-Algorithm.

Если LFA применяется для защиты локаторов, связанных с данным Flex-Algorithm, всем маршрутизаторам области, участвующим в этом Flex-Algorithm, следует анонсировать хотя бы один связанный с Flex-Algorithm локатор и END SID на узел, а также один END.X SID для каждого канала, не исключённого из расчёта с этим Flex-Algorithm. Эти локаторы и SID применяются для направления трафика по резервному пути LFA.

14.3. Пересылка для Flex-Algorithm в других плоскостях данных

Любая плоскость данных, желающая применять связанную с Flex-Algorithm пересылку, должна установить ту или иную форму связанных с Flex-Algorithm записей пересылки. Зависящая от плоскости данных пересылка для Flex-Algorithm должна быть определена для каждой плоскости данных, но это определение выходит за рамки документа.

15. Эксплуатационные соображения

15.1. Работа в нескольких областях

Расчёты Flex-Algorithm и определение FAD действуют в рамках области. В IS-IS элемент Router Capability TLV, где анонсируется FAD sub-TLV, должен иметь сброшенный бит S, чтобы предотвратить лавинную рассылку за пределы уровня, где анонс создан. Хотя в OSPF можно лавинно рассылать FAD sub-TLV в RI LSA в рамках AS, выбор FAD происходит для каждой индивидуальной зоны, где алгоритм будет применяться.

Для конкретного Flex-Algorithm не требуется идентичность FAD во всех областях сети. Например, трафик для одного Flex-Algorithm может оптимизироваться по задержке (например, с метрикой задержки) в одной области и по доступной пропускной способности (например, с метрикой IGP) в другой области или уровне.

Как описано в параграфе 5.1, IS-IS позволяет регенерировать выигрышное определение FAD с уровня 2 на уровень 1 без каких-либо изменений. Это позволяет оператору настроить FAD на одном или нескольких маршрутизаторах уровня 2 без необходимости повторять настройку в каждой области уровня 1, если намерение состоит в использовании одного FAD для конкретного Flex-Algorithm на всех уровнях. Аналогичным способом это можно реализовать в OSPF путём использования лавинной рассылки в AS для RI LSA с анонсами FAD sub-TLV для определённого Flex-Algorithm.

Регенерация FAD с уровня 1 на уровень 2 не поддерживается в IS-IS, поэтому для регенерации FAD между уровнями IS-IS определение FAD должно задаваться на маршрутизаторах уровня 2. В OSPF определение FAD возможно в любой области и оно будет распространяться на весь домен маршрутизации OSPF с использованием лавинной рассылки RI LSA в масштабе AS.

15.2. Использование правила исключения SRLG с Flex-Algorithm

Имеется два разных способа использования информации SRLG с Flex-Algorithm.

В контексте одного Flex-Algorithm SRLG можно применять для расчёта резервных путей, как описано в [RTGWG-SEGMENT-ROUTING-TI-LFA]. Для этого не требуется связывать какое-либо ограничение SRLG с данным определением Flex-Algorithm.
В контексте нескольких Flex-Algorithm SRLG можно применять для создания непересекающихся наборов путей за счёт исключения каналов, относящихся к конкретной группе SRLG из топологии, где пути рассчитываются с конкретным Flex-Algorithm. Такое исключение:
- упрощает использование уже развёрнутых конфигураций SRLG для организации непересекающихся путей между двумя или более Flex-Algorithms;
- требует явного связывания данного Flex-Algorithm с конкретным набором ограничений SRLG, как указано в параграфах 6.5 и 7.5.

Эти варианты применения не связаны между собой.

15.3. Max-Metric

В IS-IS и OSPF имеются механизмы установки значения метрики IGP на канале, делающего этот канал недоступным или применяемым в самом крайнем случае (last resort). Аналогичные функции нужны и для показателей Min Unidirectional Link Delay и TE, поскольку они могут применяться в расчётах путей Flex-Algorithm.

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику Min Unidirectional Link Delay, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA Min Unidirectional Link Delay для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение задержки 16777215 (2²⁴ -1).

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику TE, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA TE для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение метрики TE (2²⁴ – 1) в IS-IS и (2³² – 1) в OSPF.

15.4. Задание и изменение гибкого алгоритма

При настройке узла для участия в конкретном Flex-Algorithm, следует внимательно рассмотреть компоненты FAD (calculation-type, metric-type, ограничения). Настройка участия в определённом Flex-Algorithm не гарантирует, что узел будет активно участвовать в алгоритме, поскольку он может не поддерживать calculation-type, metric-type или некоторые ограничения, анонсируемые выигрышным определением FAD (5.3. Базовая обработка FAD TLV). Изменения в конфигурации FAD также следует рассматривать в свете возможностей участвующих маршрутизаторов в области действия анонсов FAD.

Как отмечено в параграфе 5.3, изменение FAD может потребовать пересчёта SPF⁴ в масштабе сети и повторного схождения. Это следует учитывать при планировании и внесении изменений в FAD.

15.5. Число гибких алгоритмов

Максимальное число Flex-Algorithm определяется диапазоном 128-255, как указано в разделе 4. Гибкий алгоритм. Хотя такое возможно, но не предполагается, что все такие алгоритмы будут применяться одновременно. Обычно в сети будет использоваться лишь часть возможных Flex-Algorithms.

16. Совместимость с имеющимися расширениями

Это расширение не создаёт проблем совместимости с имеющимися протоколами и расширениями. В IS-IS, OSPFv2 и OSPFv3 чётко задана обработка нераспознанных TLV и sub-TLV, что позволяет создавать новые расширения, подобные описанным здесь, без возникновения проблем совместимости.

17. Вопросы безопасности

Этот документ добавляет две новых возможности нарушить работу сетей IGP.

Злоумышленник может захватить конкретный Flex-Algorithm, анонсируя FAD с приоритетом 255 (или иным значением выше, чем у легитимных узлов).
Злоумышленник может создать ложное впечатление о поддержке (или её отсутствии) маршрутизатором конкретного Flex-Algorithm.

Обе эти атаки можно предотвратить с помощью имеющихся защитных расширений, как описано в [RFC5304] и [RFC5310] для IS-IS, в [RFC2328] и [RFC7474] для OSPFv2, в [RFC4552] и [RFC5340] для OSPFv3.

Если аутентифицированный узел захвачен злоумышленником, такой мошеннический узел может анонсировать FAD для любого Flex-Algorithm. Это может привести к тому, что трафик для такого Flex-Algorithm будет направлен не туда или не доставлен совсем, например, за счёт использования неподдерживаемых metric-type, calculation-type или ограничений. Такую атаку не удастся предотвратить с помощью аутентификации и она ничем не отличается от других вариантов анонсирования ложных сведений через IS-IS или OSPF.

18. Взаимодействие с IANA

18.1. Взаимодействие с IANA для IGP

18.1.1. Реестр IGP Algorithm Types

Этот документ вносит указанную в таблице 1 запись в реестр IGP Algorithm Types.

Таблица 1. Реестр IGP Algorithm Types.

Значение	Описание	Документ
128-255	Гибкие алгоритмы	RFC 9350, раздел 4

18.1.2. Реестр IGP Metric-Type

Агентство IANA создало реестр IGP Metric-Type в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action [RFC8126] [RFC7120]. Выделенные здесь значения из диапазона 0-255 указаны в таблице 2.

Таблица 2. Реестр IGP Metric-Type.

Тип	Описание	Документ
0	IGP Metric	RFC 9350, параграф 5.1
1	Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC8570] и 4.2 в [RFC7471]	RFC 9350, параграф 5.1
2	Traffic Engineering Default Metric в соответствии с параграфом 3.7 в [RFC5305] и Traffic Engineering Metric в соответствии с параграфом 2.5.5 в [RFC3630]	RFC 9350, параграф 5.1

18.2. Реестр IGP Flexible Algorithm Definition Flags

Агентство IANA создало реестр IGP Flexible Algorithm Definition Flags в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action. Новые значения следует выделять по порядку битов (6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV). Исходное назначение показано в таблице 3.

Таблица 3. Реестр IGP Flexible Algorithm Definition Flags.

Бит	Имя	Документ
0	Флаг метрики префикса (M-flag)	RFC 9350, параграфы 6.4 и 7.4

18.3. Взаимодействие с IANA для IS-IS

18.3.1. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

Этот документ вносит указанную в таблице 4 запись в реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

Таблица 4. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

Значение	Описание	Документ
26	Определение гибкого алгоритма (FAD)	RFC 9350, параграф 5.1

18.3.2. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability

Этот документ вносит указанную в таблице 5 запись в реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.

Таблица 5. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.

Тип	Описание	27	135	235	236	237	Документ
6	Flexible Algorithm Prefix Metric (FAPM)	n	y	y	y	y	RFC 9350, раздел 8

18.3.3. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Агентство IANA создало реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV внутри группы реестров IS-IS TLV Codepoints. Для регистрации применяется процедура Expert Review (отметим, что группа IS-IS TLV Codepoints включает рекомендацию применять Expert Review для всех реестров в ней).

Записи sub-sub-TLV, заданных в этом документе для включения в реестр, показаны в таблице 6.

Таблица 6. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV.

Тип	Описание	Документ
0	Резерв	RFC 9350
1	Flexible Algorithm Exclude Admin Group	RFC 9350, параграф 6.1
2	Flexible Algorithm Include-Any Admin Group	RFC 9350, параграф 6.2
3	Flexible Algorithm Include-All Admin Group	RFC 9350, параграф 6.3
4	Flexible Algorithm Definition Flags	RFC 9350, параграф 6.4
5	Flexible Algorithm Exclude SRLG	RFC 9350, параграф 6.5
6-255	Не выделены

18.4. Взаимодействие с IANA для OSPF

18.4.1. Реестр OSPF Router Information (RI) TLVs

Этот документ вносит указанную в таблице 7 запись в реестр OSPF Router Information (RI) TLVs.

Таблица 7. Реестр OSPF Router Information (RI) TLVs.

Значение	Описание	Документ
16	Flexible Algorithm Definition (FAD) TLV	RFC 9350, параграф 5.2

18.4.2. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs

Этот документ вносит указанную в таблице 8 запись в реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

Таблица 8. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

Значение	Описание	Документ
3	Flexible Algorithm Prefix Metric (FAPM)	RFC 9350, раздел 9

18.4.3. Реестр OSPFv3 Extended-LSA Sub-TLVs

Этот документ вносит указанные в таблице 9 записи в реестр OSPFv3 Extended-LSA Sub-TLVs.

Таблица 9. Реестр OSPFv3 Extended-LSA Sub-TLVs.

Значение	Описание	Документ
26	Flexible Algorithm Prefix Metric (FAPM)	RFC 9350, раздел 9
33	OSPF Flexible Algorithm ASBR Metric	RFC 9350, параграф 10.2

18.4.4. Реестр OSPF Flex-Algorithm Prefix Metric Bits

Агентство IANA создало реестр OSPF Flex-Algorithm Prefix Metric Bits внутри реестра Open Shortest Path First (OSPF) Parameters. Регистрация выполняется по процедуре IETF Review. Биты 1-7 не выделены, исходное назначение показано в таблице 10.

Таблица 10. Реестр OSPF Flex-Algorithm Prefix Metric Bits.

Номер бита	Описание	Документ
0	E bit – External Type	RFC 9350, раздел 9

18.4.5. Реестр Opaque Link-State Advertisements (LSA) Option Types

Этот документ регистрирует указанное в таблице 11 значение в реестре Opaque Link-State Advertisements (LSA) Option Types внутри группы реестров Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types.

Таблица 11. Реестр Opaque Link-State Advertisements (LSA) Option Types.

Значение	Неинтерпретируемый тип	Документ
11	OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA	RFC 9350, параграф 10.1

18.4.6. Реестр OSPFv2 Extended Inter-Area ASBR TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR TLVs внутри группы реестров Open Shortest Path First v2 (OSPFv2) Parameters. Для реестра применяется процедура IETF Review или IESG Approval. Исходные значения приведены в таблице 12.

Таблица 12. Реестр OSPFv2 Extended Inter-Area ASBR TLVs.

Значение	Описание	Документ
1	Extended Inter-Area ASBR	RFC 9350

Значения 2-32767 не распределены, значения 32768-33023 выделены для экспериментов (Experimental Use), 0 и 33024-65535 являются резервными.

18.4.7. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs внутри реестра Open Shortest Path First v2 (OSPFv2) Parameters. Регистрация выполняется по процедуре IETF Review или IESG Approval. Исходные значения приведены в таблице 13.

Таблица 13. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs.

Значение	Описание	Документ
1	OSPF Flexible Algorithm ASBR Metric	RFC 9350

18.4.8. Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs

Агентство IANA создало реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs внутри группы реестров Open Shortest Path First (OSPF) Parameters. Для реестра применяется процедура IETF Review или IESG Approval.

Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs будет определять sub-TLV с любым уровнем вложенности для Flexible Algorithm TLV и новые значения могут выделяться по процедуре регистрации.

Регистрируемые документом sub-TLV указаны в таблице 14.

Таблица 14. Реестр OSPFv2 OSPF Flexible Algorithm Definition TLV Sub-TLVs.

Номер бита	Описание	Документ
0	Резерв	RFC 9350

1	Flexible Algorithm Exclude Admin Group	RFC 9350, параграф 7.1
2	Flexible Algorithm Include-Any Admin Group	RFC 9350, параграф 7.2
3	Flexible Algorithm Include-All Admin Group	RFC 9350, параграф 7.3
4	Flexible Algorithm Definition Flags	RFC 9350, параграф 7.4
5	Flexible Algorithm Exclude SRLG	RFC 9350, параграф 7.5

Значения 6-32767 не распределены, а значения 32768-33023 выделены для экспериментов (Experimental Use) и не требуют регистрации в IANA. Значения 33024-65535 в настоящее время не выделены. Для получения значений из этого диапазона должна быть выпущена спецификация IETF, с соответствующими запросами к IANA.

18.4.9. Реестр Link Attribute Application Identifiers

Этот документ регистрирует указанные в таблице 15 идентификаторы в реестре Link Attribute Application Identifiers.

Таблица 15. Реестр флагов IGP Flexible Algorithm Definition.

Бит	Описание	Документ
3	Гибкий алгоритм (X-bit)	RFC 9350, раздел 12

19. Литература

19.1. Нормативные документы

[ISO10589] ISO, “Information technology – Telecommunications and information exchange between systems – Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)”, Second Edition, ISO/IEC 10589:2002, November 2002.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, “The OSPF Opaque LSA Option”, RFC 5250, DOI 10.17487/RFC5250, July 2008, <https://www.rfc-editor.org/info/rfc5250>.

[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., “IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, “OSPFv2 Prefix/Link Attribute Advertisement”, RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, “Extensions to OSPF for Advertising Optional Router Capabilities”, RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.

[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, “IS-IS Extensions for Advertising Router Information”, RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, “OSPFv3 Link State Advertisement (LSA) Extensibility”, RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing with the MPLS Data Plane”, RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, “OSPF Extensions for Segment Routing”, RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.

[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., “OSPFv3 Extensions for Segment Routing”, RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>.

[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, “IS-IS Extensions for Segment Routing”, RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, “IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane”, RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/info/rfc9352>.

19.2. Дополнительная литература

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101] Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option”, RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

[RFC3906] Shen, N. and H. Smit, “Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels”, RFC 3906, DOI 10.17487/RFC3906, October 2004, <https://www.rfc-editor.org/info/rfc3906>.

[RFC4552] Gupta, M. and N. Melam, “Authentication/Confidentiality for OSPFv3”, RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC5304] Li, T. and R. Atkinson, “IS-IS Cryptographic Authentication”, RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5305] Li, T. and H. Smit, “IS-IS Extensions for Traffic Engineering”, RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, “IS-IS Generic Cryptographic Authentication”, RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6”, RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, “Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks”, RFC 6571, DOI 10.17487/RFC6571, June 2012, <https://www.rfc-editor.org/info/rfc6571>.

[RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, “OSPF Traffic Engineering (TE) Metric Extensions”, RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., “Security Extension for OSPFv2 When Using Manual Key Management”, RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, “IS-IS Traffic Engineering (TE) Metric Extensions”, RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, “Segment Routing over IPv6 (SRv6) Network Programming”, RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[ROUTING-PLANES-USING-SR] Hegde, S. and A. Gulko, “Separating Routing Planes using Segment Routing”, Work in Progress, Internet-Draft, draft-gulkohegde-routing-planes-using-sr-00, 13 March 2017, <https://datatracker.ietf.org/doc/html/draft-gulkohegde-routing-planes-using-sr-00>.

[RTGWG-SEGMENT-ROUTING-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, “Topology Independent Fast Reroute using Segment Routing”, Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-09, 23 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-09>.

Благодарности

В этом документе, среди прочего, рассматривается задача, которую пытаются решить в [ROUTING-PLANES-USING-SR]. Все авторы этого документа согласились присоединиться к данному документу.

Спасибо Eric Rosen, Tony Przygienda, William Britto A. J., Gunter Van de Velde, Dirk Goethals, Manju Sivaji, and Baalajee S. за их подробные рецензии и отличные комментарии.

Спасибо Cengiz Halit за его рецензию и отклики на начальном этапе решения.

Спасибо Kenji Kumaki за его комментарии.

Спасибо Acee Lindem за редакционные замечания.

Адреса авторов

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3В полях ASBR Router ID и Sub-TLVs. Прим. перев.

4Shortest Path First – сначала кратчайший путь.

1. Введение

2. Уровни требований

3. Терминология

4. Гибкий алгоритм

5. Анонсирование определения гибкого алгоритма

5.1. IS-IS FAD Sub-TLV

5.2. OSPF FAD TLV

5.3. Базовая обработка FAD TLV

6. Sub-TLV для IS-IS FAD Sub-TLV

6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV

6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV

6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV

6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV

6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV

7. Sub-TLV для OSPF FAD TLV

7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV

7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV

7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV

7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV

7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV

8. IS-IS Flexible Algorithm Prefix Metric Sub-TLV

9. OSPF Flexible Algorithm Prefix Metric Sub-TLV

10. Гибкий алгоритм OSPF для анонсирования доступности ASBR

10.1. OSPFv2 Extended Inter-Area ASBR LSA

10.1.1. OSPFv2 Extended Inter-Area ASBR TLV

10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV

11. Анонсирование участия узла в Flex-Algorithm

11.1. Анонсирование участия узла в SR

11.2. Анонсирование участия узла в других плоскостях данных

12. Анонсирование атрибутов канала для Flex-Algorithm

13. Расчёт путей по гибкому алгоритму

13.1. Множество областей и доменов

14. Flex-Algorithm и плоскость пересылки

14.1. Пересылка MPLS SR для Flex-Algorithm

14.2. Пересылка SRv6 для Flex-Algorithm

14.3. Пересылка для Flex-Algorithm в других плоскостях данных

15. Эксплуатационные соображения

15.1. Работа в нескольких областях

15.2. Использование правила исключения SRLG с Flex-Algorithm

15.3. Max-Metric

15.4. Задание и изменение гибкого алгоритма

15.5. Число гибких алгоритмов

16. Совместимость с имеющимися расширениями

17. Вопросы безопасности

18. Взаимодействие с IANA

18.1. Взаимодействие с IANA для IGP

18.1.1. Реестр IGP Algorithm Types

18.1.2. Реестр IGP Metric-Type

18.2. Реестр IGP Flexible Algorithm Definition Flags

18.3. Взаимодействие с IANA для IS-IS

18.3.1. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

18.3.2. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability

18.3.3. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

18.4. Взаимодействие с IANA для OSPF

18.4.1. Реестр OSPF Router Information (RI) TLVs

18.4.2. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs

18.4.3. Реестр OSPFv3 Extended-LSA Sub-TLVs

18.4.4. Реестр OSPF Flex-Algorithm Prefix Metric Bits

18.4.5. Реестр Opaque Link-State Advertisements (LSA) Option Types

18.4.6. Реестр OSPFv2 Extended Inter-Area ASBR TLVs

18.4.7. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs

18.4.8. Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs

18.4.9. Реестр Link Attribute Application Identifiers

19. Литература

19.1. Нормативные документы

19.2. Дополнительная литература

Благодарности

Адреса авторов

Добавить комментарий Отменить ответ

Рубрики

Свежие записи

Архивы

Мета