Internet Engineering Task Force (IETF) H. Gredler, Ed.
Request for Comments: 7752 Individual Contributor
Category: Standards Track J. Medved
ISSN: 2070-1721 S. Previdi
Cisco Systems, Inc.
A. Farrel
Juniper Networks, Inc.
S. Ray
March 2016
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
Северное распространение сведений о состоянии каналов и организации трафика через BGP
PDF
Аннотация
В ряде сред вызываются внешние по отношению к сети компоненты для выполнения расчётов на основе топологии сети и текущего состояния соединений в ней, включая сведения об организации трафика (Traffic Engineering или TE). Эта информация обычно распространяется внутри сети протоколами маршрутизации IGP.
Этот документ описывает механизм, с помощью которого сведения о состоянии каналов (link-state) и TE могут собираться из сетей и использоваться совместно с внешними компонентами с помощью протокола маршрутизации BGP. Это достигается за счёт применения нового формата кодирования сведений о доступности сетей BGP (Network Layer Reachability Information или NLRI). Этот механизм подходит для физических и виртуальных каналов IGP и находится под управлением правил (политики).
Применения этого метода включают серверы оптимизации трафика на уровне приложений (Application-Layer Traffic Optimization или ALTO) и элементы расчёта путей (Path Computation Element или PCE).
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc7752.
Авторские права
Copyright (c) 2016. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Содержимое базы данных о состояниях каналов (Link-State Database или LSDB) или базы данные организации трафика протокола IGP (Traffic Engineering Database или TED) описывает лишь каналы и узлы в области IGP. Некоторым приложениям, таким как сквозная организация трафика (Traffic Engineering или TE), была бы полезна видимость за пределы области или автономной системы (Autonomous System или AS) для принятия более эффективных решений.
В IETF задан элемент расчёта пути (Path Computation Element или PCE) [RFC4655] в качестве механизма для расчёта сквозных путей TE, проходящих через области видимости множества TED, требующих интенсивного использования CPU или скоординированных расчётов. Определён также сервер ALTO [RFC5693] в качестве объекта, генерирующего абстрактную топологию сети и предоставляющего её сетевым приложениям. PCE и серверу ALTO нужно собирать сведения о топологии и возможностях сети для выполнения своих функций.
Этот документ описывает механизм, с помощью которого можно собрать из сетей сведения о состоянии каналов и TE и обобщить их с внешними компонентами по протоколу маршрутизации BGP [RFC4271]. Это достигается с помощью нового формата кодирования BGP NLRI (Network Layer Reachability Information — сведения о доступности на сетевом уровне). Механизм применим как для физических, так и для виртуальных каналов и может управляться по правилам.
Маршрутизатор поддерживает 1 или несколько баз данных для хранения сведений о состоянии каналов для узлов и каналов в любой заданной области. Атрибуты каналов в этих базах включают локальный и удалённый адрес IP, идентификаторы локального и удалённого интерфейса, метрику канала и TE, пропускную способность канала, резервируемую пропускную способность, состояния резервирования по классам обслуживания (Class-of-Service или CoS), вытеснение и группы общего риска (Shared Risk Link Group или SRLG). Процесс BGP в маршрутизаторе может извлекать топологические сведения из этих LSDB и распространять их клиентам напрямую или через партнера BGP (обычно выделенный Route Reflector), используя заданное в этом документе кодирование.
Набор сведений о состояниях каналов и TE, а также их распространение потребителям показаны на рисунке 1.
+-----------+
|Потребитель|
+-----------+
^
|
+-----------+ +-----------+
| Узел BGP | |Потребитель|
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| Узел BGP | | Узел BGP | . . . | Узел BGP |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
Рисунок 1. Набор сведений Link-State и TE.
Узел BGP может применять настраиваемые правила (политику) к распространяемой им информации. Таким образом, он может распространять реальную физическую топологию из LSDB или TED. Кроме того, он может создавать абстрактную топологию, где виртуальные агрегированные узлы соединены виртуальными путями. Агрегированный узел можно создать, например, из нескольких маршрутизаторов в точке присутствия (Point of Presence или POP). Абстрактная топология может включать физические и виртуальные узлы и каналы. Кроме того, узел BGP может применять правила для определения момент обновления сведений у потребителя, чтобы сократить объем информации, передаваемой из сети потребителям. Механизмы агрегирования и виртуализации топологии выходят за рамки документа.
1.1. Уровни требований
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].
2. Мотивация и применимость
В этом разделе представлены примеры использования, из которых можно вывести требования.
2.1. MPLS-TE с PCE
Как описано в [RFC4655], PCE можно применять для расчёта путей can MPLS-TE внутри «домена» (например, области IGP) или через несколько доменов (AS с несколькими областями или множество AS).
-
Внутри одной области PCE предлагает расширенные возможности вычислений, которых может не быть у отдельных маршрутизаторов, изощрённые правила и алгоритмы, координацию всех расчётов внутри области.
-
При расчёте маршрутизатором пути MPLS-TE через области IGP его TED может не видеть всю топологию. Это означает, что маршрутизатор не может определить сквозной пути и даже выбрать выходной маршрутизатор (Area Border Router или ABR) для оптимального пути. Это проблема больших сетей, которым нужно разделить своё ядро на отдельные области, сохраняя преимущества MPLS-TE.
В прежних решениях применялся расчёт путей по доменам [RFC5152]. Исходный маршрутизатор может рассчитать путь лишь для первой области, поскольку он полностью видить только её топологию. В таком расчёте пути применяется метод loose-hop-expansion [RFC3209] и выбирается выходной ABR, а также другие ABR или граничные маршрутизаторы AS (AS Border Router или ASBR) с использованием рассчитаной IGP топологии кратчайшего пути для остального пути. Это может давать неоптимальные пути, усложнять расчёт дополнительного (резервного) пути и даже невозможности найти реально существующий путь TE.
+----------+ +--------+
| ----- | | Узел |
| | TED |<-+--------------------------->| BGP |
| ----- |Механизм синхронизации TED: +--------+
| | | BGP с Link-State NLRI
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Запрос -
| отклик
v
Запрос +----------+ Сигнальный +----------+
услуги | Узел | протокол | Смежный |
-------->| Head-End |<------------>| узел |
+----------+ +----------+
Рисунок 2. Внешний узел PCE, использующий синхронизацию TED.
PCE представляет собой расчетный сервер, который может видеть более одной области IGP или AS, а также может взаимодействовать с другими PCE для выполнения распределенных расчётов. PCE обычно нужен доступ к TED для обслуживаемых областей, но в [RFC4655] не указано, как это достигается. Во многих реализациях PCE является пассивным участником IGP, чтобы знать свежее состояние сети, но это может быть неоптимальным при высоком уровне нестабильности сети или при обслуживании PCE нескольких областей.
На рисунке 2 показано, как PCE получает сведения из TED с использованием описанного в документе механизма. Этот механизм позволяет собрать требуемые сведения TED из IGP внутри сети с фильтрацией в соответствии с настраиваемой политикой и распределить информацию нужным PCE.
2.2. Сетевой API сервера ALTO
Сервер ALTO [RFC5693] — это объект, который генерирует абстрактную топологию сети и предоставляет её сеетвым приложениям через web-интерфейс API. Примером таких приложения являются одноранговын (peer-to-peer или P2P) клиенты или трекеры, сети распространения содержимого (Content Distribution Network или CDN). Абстрактная топология сети представлена двумя отображениями — картой сети (Network Map), которая указывает назначение префиксов для идентификаторов разделов (Partition Identifier или PID), и картой стоимости (Cost Map), которая указывает стоимость пути между PID, указанными картой сети. Дополнительные сведения приведены в [RFC7285].
Абстрактные топологии ALTO могут создаваться автоматически по физической топологии базовой сети. Генерация обычно основана на политике и правилах, заданных оператором сети. Нужны префиксы и данные TE, префиксы требуются для создания ALTO Network Map, а данные TE (топология) — для создания ALTO Cost Map. Сведения о префиксах создаются и передаются в BGP, а данные TE — в IGP. Заданные в этом документе механизмы обеспечивают единый интерфейс, через который сервер ALTO может извлечь все нужные сведения о префиксах и топологии из базовой сети. Отметим, что сервер ALTO может применять иные механизмы для получения сетевых данных, например, организуя партнёрство с множеством узлов IGP и BGP.
На рисунке 3 показано, как сервер ALTO может получить сведения о сетевой топологии из базовой сети, используя заданный в этом документе механизм.
+--------+
| Клиент |<--+
+--------+ |
| Протокол +--------+ BGP с +--------+
+--------+ | ALTO | Сервер | Link-State NLRI | Узел |
| Клиент |<--+------------| ALTO |<----------------| BGP |
+--------+ | +--------+ +--------+
|
+--------+ |
| Клиент |<--+
+--------+
Рисунок 3. Сервер ALTO, использующий сведения о топологии сети.
3. Передача сведений о состоянии каналов в BGP
Эта спецификация состоит из 2 частей: определения нового BGP NLRI для описания каналов, узлов и префиксов, составляющих сведения IGP о состояниях каналов, и нового атрибута пути BGP (BGP-LS), передающего свойства и атрибуты каналов, узлов и префиксов, такие как метрика каналов и префиксов, дополнительные Router-ID для узлов и т. п. Желательно зависимость атрибута от протокола-источника к минимуму и представлять любое содержимое независимым от IGP способом, чтобы приложениям, желающим узнать топологию link-state, не требовалась какая-либо специфика протокола OSPF или IS-IS.
3.1. Формат TLV
Информация в новых Link-State NLRI и атрибутах представляется триплетами тип, размер, значение (Type/Length/Value или TLV), формат показан на рисунке 4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 4. Формат TLV.
Поле Length указывает размер поля Value в октетах (TLV без поля значения будет указывать размер 0). TLV не дополняются до 4-октетной границы. Нераспознанные типы должны сохраняться и распространяться. Для сравнения NLRI с неизвестными TLV все TLV должны опорядочиваться по росту TLV Type. При наличии нескольких TLV одного типа они должны упорядочиваться в порядке роста значения TLV, трактуемого как необрабатываемая (opaque) шестнадцатеричная строка, по расположенным слева октетам, независимо от размера этой строки. Все TLV, не указанные как обязательные, считаются необязательными.
3.2. Link-State NLRI
Атрибуты MP_REACH_NLRI и MP_UNREACH_NLRI являются контейнерами BGP для переноса неинтерпретируемых сведений. Каждый Link-State NLRI описывает узел, канал или перфикс.
Все сведения о каналах, узлах и префиксах, не связанные с VPN, нужно кодировать с использованием AFI 16388 / SAFI 71. Сведения об узлах, каналах и префиксах VPN нужно кодировать с использованием AFI 16388 / SAFI 72.
Чтобы два узла BGP могли обмениваться Link-State NLRI, они должны использовать BGP Capabilities Advertisement для согласования подобающей обработки таких NLRI. Это делается в соответствии с [RFC4760] путём использования кода возможности 1 (multi-protocol BGP) с AFI 16388 / SAFI 71 для BGP-LS и AFI 16388 / SAFI 72 для BGP-LS-VPN.
Формат Link-State NLRI показан на рисунках 5 и 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (переменный) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 5. Формат Link-State NLRI AFI 16388 / SAFI 71.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (переменный) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 6. Формат Link-State VPN NLRI AFI 16388 / SAFI 72.
Поле Total NLRI Length указывает общий размер (в октетах) остальной части NLRI без учёта себя и поля NLRI Type. Для приложений VPN учитывается также размер Route Distinguisher.
Таблица 1. Типы NLRI.
|
Тип
|
Тип NLRI
|
|
1
|
Node NLRI
|
|
2
|
Link NLRI
|
|
3
|
IPv4 Topology Prefix NLRI
|
|
4
|
IPv6 Topology Prefix NLRI
|
Определение и обсуждение Route Distinguisher приведено в [RFC4364].
Формат Node NLRI (NLRI Type = 1) показан на рисунке 7.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 7. Формат Node NLRI.
Формат Link NLRI (NLRI Type = 2) показан на рисунке 8.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 бита) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 8. Формат Link NLRI.
Prefix NLRI для IPv4 и IPv6 (NLRI Type = 3 и Type = 4) используют одинаковый формат, показанный на рисунке 9.
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 бита) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 9. Формат IPv4/IPv6 Topology Prefix NLRI.
Поле Protocol-ID может содержать одно из значений, приведённых в таблице 2.
Таблица 2. Идентификаторы протоколов.
|
Protocol-ID
|
Протокол-источник сведений для NLRI
|
|
1
|
IS-IS Level 1
|
|
2
|
IS-IS Level 2
|
|
3
|
OSPFv2
|
|
4
|
Прямое соединение
|
|
5
|
Статическая конфигурация
|
|
6
|
OSPFv3
|
Типы протоколов «прямое соединение» и «статическая конфигурация» следует применять, когда BGP-LS берет локальные сведения. Для информации, полученной от других протоколов, должен применяться соответствующий Protocol-ID. Если BGP-LS имеет прямой доступ к информации интерфейса и хочет анонсировать локальный канал, следует использовать Protocol-ID 4. Для моделирования виртуальных каналов, как описано в разделе 4, следует применять Protocol-ID 5.
Протоколы OSPF и IS-IS могут запускать несколько своих экземпляров на одном канале (см. [RFC6822] и [RFC6549]). Эти экземпляры называют пространствами маршрутизации (routing universes). 64-битовое поле Identifier служит для идентификации пространства, к которому относится NLRI. NLRI, представляющие объекты состояния канала (узлы, каналы, префиксы) из одного пространства маршрутизации, должны иметь одинаковые значения Identifier. NLRI с разными значениями Identifier должны относиться к разным пространствам маршрутизации. В таблице 3 показано значение Identifier, заданное этим документом как общеизвестное.
Таблица 3. Общеизвестный идентификатор экземпляра.
|
Идентификатор
|
Пространство маршрутизации
|
|
0
|
Принятая по умолчанию топология маршрутизации L3
|
Если данный протокол не поддерживает несколько пространств маршрутизации, следует установить Identifier 0. Однако реализация может сделать значение Identifier настраиваемым для данного протокола.
Каждый дескриптор узла (Node Descriptor) или канала (Link Descriptor) содержит 1 или несколько TLV, описанных ниже.
3.2.1. Дескрипторы узлов
Каждый канал привязан к паре Router-ID, используемых базовым IGP, — 48-битовое значение ISO System-ID для IS-IS и 32-битовое значение Router-ID для OSPFv2 и OSPFv3. IGP может использовать дополнительные Router-ID, в основном для организации трафика. Например, IS-IS может иметь 1 или несколько IPv4 и IPv6 TE Router-ID [RFC5305] [RFC6119]. Эти дополнительные Router-ID должны включаться в атрибут канала, описанный в параграфе 3.3.2.
Желательно, чтобы значения Router-ID внутри Node Descriptor были глобально уникальными. Однако могут быть пространства Router-ID (например, ISO) без глобального реестра или, что хуже, Router-ID могут быть выделены приватно в соответствии с RFC 1918 [RFC1918]. BGP-LS использует номер автономной системы (Autonomous System или AS) и BGP-LS Identifier (см. параграф 3.2.1.4) для устранения неоднозначности Router-ID (см. параграф 3.2.1.1).
3.2.1.1. Глобально уникальные идентификаторы узлов, каналов, префиксов
Одной из требующих решения проблем является возможность глобальной идентификации узлов IGP (глобальной здесь считается база данных BGP-LS, собранная всеми взаимодействующими узлами BGP-LS). Это можно выразить двумя требованиями:
-
один узел недопустимо представлять двумя ключами (иначе он будет выглядеть двумя узлами);
-
два разных узла недопустимо представлять одним ключом (иначе они будут выглядеть одним узлом).
«Доменом IGP» здесь считается набор узлов (следовательно, каналов и префиксов), в котором каждый узел имеет уникальное представление IGP с использованием комбинации Area-ID, Router-ID, Protocol-ID, Multi-Topology ID, Instance-ID. Проблема заключается в том, что BGP может получать сведения об узлах, каналах и префиксах от множества независимых «доменов IGP» и нужно различать их. Кроме того, нельзя считать, что в каждой AS имеется лишь один домен IGP. При изменениях IGP могут возникать одновременно два IGP.
В параграфе 3.2.1.4 описан набор sub-TLV, позволяющий гибко задать ключ для любой данной информации об узле/канале, чтобы гарантировать глобальную уникальность NLRI.
3.2.1.2. Дескрипторы локального узла
Local Node Descriptors TLV (Рисунок 10) содержит дескрипторы для узла, связанного с локальной стороной канала. Этот TLV обязателен для всех 3 типов NLRI (узел, канал, префикс) и имеет переменный размер. Поле значения содержит 1 или несколько Node Descriptor Sub-TLV, заданных в параграфе 3.2.1.4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (переменный) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 10. Формат TLV дескрипторов локального узла.
3.2.1.3. Дескрипторы удалённого узла
Remote Node Descriptors TLV (Рисунок 11) содержит дескрипторы для узла, связанного с удалённой стороной канала. Этот TLV обязателен для Link NLRI и имеет переменный размер. Поле значения содержит 1 или несколько Node Descriptor Sub-TLV, заданных в параграфе 3.2.1.4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (переменный) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 11. Формат TLV дескрипторов удалённого узла.
3.2.1.4. Sub-TLV дескриптора узла
Коды и размеры Node Descriptor Sub-TLV указаны в таблице 4.
Таблица 4. Sub-TLV дескриптора узла.
|
Код Sub-TLV
|
Описание
|
Размер
|
|
512
|
Автономная система
|
4
|
|
513
|
Идентификатор BGP-LS
|
4
|
|
514
|
OSPF Area-ID
|
4
|
|
515
|
IGP Router-ID
|
Переменный
|
Ниже указаны значения sub-TLV в Node Descriptor TLV.
Autonomous System
Неинтерпретируемое значение (32-битовый номер AS).
BGP-LS Identifier
Неинтерпретируемый 32-битовый идентификатор, совместно с номером автономной системы (Autonomous System Number или ASN) однозначно указывающий домен BGP-LS. Сочетание ASN и BGP-LS ID должно быть глобально уникальным. Все узлы BGP-LS в IGP flooding-set (набор узлов IGP, в котором выполняется лавинная рассылка LSP/LSA) должны использовать одну пару ASN и BGP-LS ID. Если домен IGP содержит несколько flooding-set, всем узлам BGP-LS в домене IGP следует использовать одну пару ASN и BGP-LS ID.
Area-ID
32-битовый идентификатор области, к которой относится NLRI. Этот идентификатор позволяет различать NLRI от одного маршрутизатора.
IGP Router-ID
Неинтерпретируемое значение (обязательный TLV). Для узла (не псевдо) IS-IS это 6-октетный ISO Node-ID (ISO system-ID), для псевдоузла IS-IS, соответствующего ЛВС, это 6-октетный ISO Node-ID назначенной промежуточной системы (Designated Intermediate System или DIS), за которым следует ненулевой 1-октетный идентификатор PSN (итого 7 октетов). Для узла (не псевдо) OSPFv2 или OSPFv3 это 4-октетный Router-ID, для псевдоузла OSPFv2, представляющего ЛВС, это 4 октета Router-ID назначенного маршрутизатора (Designated Router или DR), за которыми следует 4 октета адреса IPv4 интерфейса DR в ЛВС (итого 8 октетов). Для псевдоузла OSPFv3 это 4 октета Router-ID назначенного маршрутизатора, за которыми следует 4 октета адреса IPv4 интерфейса DR в ЛВС (итого 8 октетов). Размер TLV в сочетании с идентификатором протокола позволяет декодеру определить тип узла.
В любом Node Descriptor может присутствовать не более 1 экземпляра каждого типа sub-TLV. Внутри sub-TLV должны упорядочиваться по росту значений типа sub-TLV. Это нужно для сравнения NLRI даже в случаях, когда реализация встречает неизвестный sub-TLV. Используя стабильную сортировку, реализация может выполнить двоичное сравнение NLRI, что позволяет поэтапно внедрять новые важные sub-TLV.
3.2.1.5. Multi-Topology ID
Multi-Topology ID (MT-ID) TLV содержит 1 или несколько IS-IS или OSPF Multi-Topology ID для канала, узла или префикса. Семантика IS-IS MT-ID определена в параграфе 7.2 [RFC5120], семантика OSPF MT-ID в параграфе 3.7 [RFC4915]. В MT-ID TLV выведенных из OSPF старшие 9 битов должны иметь значение 0. Биты R являются резервными и их следует устанавливать в 0 при создании и игнорировать при получении. Формат MT-ID TLV показан на рисунке 12.
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=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 12. Формат Multi-Topology ID TLV.
Type = 263, Length = 2*n, где n — число MT-ID в TLV.
MT-ID TLV может присутствовать в Link Descriptor, Prefix Descriptor или атрибуте BGP-LS в Node NLRI. В дескрипторах каналов и префиксов разрешён лишь 1 MT-ID TLV с MT-ID топологии, в которой достижим канал или префикс. Если нужно анонсировать несколько топологий для данного Link Descriptor или Prefix Descriptor, нужно создавать NLRI для каждой, помещая туда уникальный MT-ID. В атрибуте BGP-LS для Node NLRI разрешён 1 MT-ID TLV с массивом MT-ID для всех топологий, в которых узел доступен.
3.2.2. Дескрипторы каналов
Поле Link Descriptor содержит набор TLV, формат которых описан в параграфе 3.1. Link Descriptor TLV однозначно указывают канал среди множества параллельных соединений между парой маршрутизаторов. Канал, описываемый Link Descriptor TLV, фактически является «полуканалом» — однонаправленным представлением логического канала. Для полного описания одного логического канала два маршрутизатора анонсируют полуканалы, т. е. для соединения «точка-точка» анонсируется двумя Link NLRI.
Формат и семантика полей Value в большинстве Link Descriptor TLV соответствуют формату и семантике полей Value в IS-IS Extended IS Reachability sub-TLV, определённых в [RFC5305], [RFC5307] и [RFC6119]. Хотя кодирование Link Descriptor TLV изначально определено для IS-IS, эти TLV могут содержать данные от протокола IS-IS или OSPF. В таблице 5 указаны TLV, которые могут указываться как Link Descriptor в Link NLRI.
Таблица 5. TLV дескрипторов каналов.
|
Код TLV
|
Описание
|
IS-IS TLV/Sub-TLV
|
Документ (RFC/параграф)
|
|
258
|
Идентификатор локального или удалённого канала
|
22/4
|
[RFC5307]/1.1
|
|
259
|
Адрес IPv4 для интерфейса
|
22/6
|
[RFC5305]/3.2
|
|
260
|
Адрес IPv4 для соседа
|
22/8
|
[RFC5305]/3.3
|
|
261
|
Адрес IPv6 для интерфейса
|
22/12
|
[RFC6119]/4.2
|
|
262
|
Адрес IPv6 для соседа
|
22/13
|
[RFC6119]/4.3
|
|
263
|
Идентификатор Multi-Topology
|
—
|
параграф 3.2.1.5
|
Сведения о канале в LSA/LSP от локального узла канала определяет набор TLV в Link Descriptor для канала.
При наличии адреса (IPv4 или IPv6) интерфейса или соседа в Link Descriptor включаются TLV адресов IP, а не Identifier TLV (локальный или удалённый), которые могут помещаться в атрибут канала. При отсутствии адреса интерфейса или соседа и наличии идентификаторов (локальных или удалённых) в Link Descriptor включается Identifier TLV (локальный или удалённый). Multi-Topology Identifier TLV помещается в Link Descriptor, если эти сведения имеются.
3.2.3. Дескрипторы префиксов
Поле Prefix Descriptor содержит набор TLV, однозначно указывающих префиксы IPv4 или IPv6, происходящие от узла. Набор TLV, пригодных в качестве Prefix Descriptor в IPv4/IPv6 Prefix NLRI указан в таблице 6.
Таблица 6. TLV дескрипторов префиксов.
|
Код TLV
|
Описание
|
Размер
|
Документ (RFC/параграф)
|
|
263
|
Идентификатор Multi-Topology
|
переменный
|
Параграф 3.2.1.5
|
|
264
|
OSPF Route Type
|
1
|
Параграф 3.2.3.1
|
|
265
|
IP Reachability Information
|
переменный
|
Параграф 3.2.3.2
|
3.2.3.1. Тип маршрута OSPF
Необязательные OSPF Route Type TLV могут включаться в Prefix NLRI для указания типа маршрута OSPF к префиксу в доменах OSPF с несколькими типами маршрутов. Формат OSPF Route Type TLV показан на рисунке 13.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type |
+-+-+-+-+-+-+-+-+
Рисунок 13. Формат OSPF Route Type TLV.
Поля Type и Length описаны в таблице 6. Значение поля Route Type определены протоколом OSPF и показаны ниже.
-
Intra-Area (0x1)
-
Inter-Area (0x2)
-
External 1 (0x3)
-
External 2 (0x4)
-
NSSA 1 (0x5)
-
NSSA 2 (0x6)
3.2.3.2. Сведения о доступности IP
Обязательный IP Reachability Information TLV содержит префикс адреса IP (IPv4 или IPv6), исходно анонсированный в топологии IGP. Он «склеивает» NLRI конкретной службы BGP по BGP next hop с данным узлом в LSDB. Маршрутизаторам следует анонсировать IP Prefix NLRI для каждого из своих BGP next hop. Формат IP Reachability Information TLV показан на рисунке 14.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 14. Формат IP Reachability Information TLV.
Поля Type и Length описаны в таблице 6. Следующие два поля содержат сведения о доступности семейства адресов. Поле Prefix Length указывает размер префикса в битах, поле IP Prefix содержит старшие октеты префикса, т. е. 1 октет при Prefix Length от 1 до 8, 2 октета при размере от 9 до 16, 3 при размере от 17 до 24, 4 при размере от 25 до 32 и т. д.
3.3. Атрибут BGP-LS
BGP-LS является необязательным, непереходным атрибутом BGP, служащим для передачи параметров и атрибутов узла, канала или префикса. Он содержит набор TLV, описанных ниже. Этот атрибут следует включать лишь в Link-State NLRI, в остальных случаях атрибут должен игнорироваться.
3.3.1. TLV атрибутов узла
TLV атрибутов узла могут помещаться в атрибут BGP-LS с Node NLRI. Node Attribute TLV приведены в таблице 7.
Таблица 7. TLV атрибутов узла.
|
Код TLV
|
Описание
|
Размер
|
Документ (RFC/параграф)
|
|
263
|
Идентификатор Multi-Topology
|
переменный
|
параграф 3.2.1.5
|
|
1024
|
Биты флагов узла
|
1
|
параграф 3.3.1.1
|
|
1025
|
Неинтерпретируемый атрибут узла
|
переменный
|
параграф 3.3.1.5
|
|
1026
|
Имя узла
|
переменный
|
параграф 3.3.1.3
|
|
1027
|
Идентификатор области IS-IS
|
переменный
|
параграф 3.3.1.2
|
|
1028
|
IPv4 Router-ID локального узла
|
4
|
[RFC5305]/4.3
|
|
1029
|
IPv6 Router-ID удалённого узла
|
16
|
[RFC6119]/4.1
|
3.3.1.1. Node Flag Bits TLV
Node Flag Bits TLV содержит битовую маску (Рисунок 15), описывающую атрибуты узла (Таблица 8).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+
Рисунок 15. Формат Node Flag Bits TLV.
Таблица 8. Флаги узла.
|
Бит
|
Описание
|
|
O
|
Перегрузка (Overload)
|
|
T
|
Присоединение (Attached)
|
|
E
|
Внешний (External)
|
|
B
|
Граничный (ABR)
|
|
R
|
Маршрутизатор (Router)
|
|
V
|
V6
|
|
Rsvd
|
Резерв на будущее
|
3.3.1.2. IS-IS Area Identifier TLV
Узел IS-IS может входить в одну или несколько областей IS-IS. Каждый из адресов этих областей передаётся в IS-IS Area Identifier TLV. При наличии нескольких обласетй для их кодирования применяется несколько TLV. IS-IS Area Identifier TLV может присутствовать в атрибуте BGP-LS лишь при анонсировании в Link-State Node NLRI.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 16. Формат IS-IS Area Identifier TLV.
3.3.1.3. Node Name TLV
Структура и кодирование необязательных Node Name TLV заимствованы из [RFC5301]. Поле Value указывает символическое имя маршрутизатора, которым может быть полное доменное имя (Fully Qualified Domain Name или FQDN) или его часть (например, hostname), а также заданная оператором строка. Настоятельно рекомендуется применять FQDN или его часть. Максимальный размер Node Name TLV составляет 255 октетов.
Поле Value содержит 7-битовые символы ASCII. Если пользовательский интерфейс позволяет настраивать или отображать символы Unicode, этот интерфейс отвечает за применение алгоритма ToASCII и/или ToUnicode, описанного в [RFC5890], для обеспечения корректного формата передачи.
Хотя в [RFC5301] описано расширение для IS-IS, использование Node Name TLV возможно для всех протоколов. Вывод и внедрение имён узлов (например, узлов OSPF) маршрутизаторами выходит за рамки этого документа.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 17. Формат имени узла.
3.3.1.4. TLV локальных Router-ID IPv4 и IPv6
Локальные IPv4/IPv6 Router-ID TLV служат для описания дополнительных Router-ID, которые могут применяться в IGP, например для TE или в процессе перехода, таком как сопоставление Node-ID разных протоколов. При наличии нескольких Router-ID данного типа каждый представляется своим TLV.
3.3.1.5. Opaque Node Attribute 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 18. Формат Opaque Node Attribute.
Opaque Node Attribute TLV служит для «прозрачной» передачи необязательных Node Attribute TLV, анонсируемых маршрутизатором. Порождающему маршрутизатору нужно применять этот TLV для кодирования сведений, относящихся к протоколу, анонсируемому в поле Protocol-ID заголовка NLRI, или новым расширениям протокола, указанного в поле Protocol-ID заголовка NLRI, для которых нет нейтрального к протоколу представления в BGP Link-State NLRI. Основным применением Opaque Node Attribute TLV является преодоление задержки между, например, определением атрибута IGP link-state и публикацией нейтральных к протоколу расширений BGP-LS. Маршрутизатор, например, может применять это расширение для анонсирования естественных для протокола Node Attribute TLV, таких как OSPF Router Informational Capabilities TLV из [RFC7770] или IGP TE Node Capability Descriptor TLV из [RFC5073].
3.3.2. TLV атрибутов канала
Link Attribute TLV могут кодироваться в атрибуте BGP-LS для Link NLRI и представляют собой TLV в формате, описанном в параграфе 3.1. Формат и семантика полей Value в Link Attribute TLV соответствуют формату и семантике Value в IS-IS Extended IS Reachability sub-TLV, заданных в [RFC5305] и [RFC5307]. Другие Link Attribute TLV заданы в этом документе. Хотя кодирование Link Attribute TLV исходно определено для IS-IS, эти TLV могут передавать данные от IS-IS или OSPF. Link Attribute TLV, действительные в атрибуте BGP-LS с Link NLRI, показаны в таблице 9.
Таблица 9. TLV атрибутов канала.
|
Код TLV
|
Описание
|
IS-IS TLV/Sub-TLV
|
RFC/параграф
|
|
1028
|
IPv4 Router-ID локального узла
|
134/-
|
[RFC5305]/4.3
|
|
1029
|
IPv6 Router-ID локального узла
|
140/-
|
[RFC6119]/4.1
|
|
1030
|
IPv4 Router-ID удалённого узла
|
134/-
|
[RFC5305]/4.3
|
|
1031
|
IPv6 Router-ID удалённого узла
|
140/-
|
[RFC6119]/4.1
|
|
1088
|
Административная группа (цвет)
|
22/3
|
[RFC5305]/3.1
|
|
1089
|
Максимальная пропускная способность канала
|
22/9
|
[RFC5305]/3.4
|
|
1090
|
Максимальная резервируемая пропускная способность канала
|
22/10
|
[RFC5305]/3.5
|
|
1091
|
Нерезервируемая пропускная способность канала
|
22/11
|
[RFC5305]/3.6
|
|
1092
|
Принятая по умолчанию метрика TE
|
22/18
|
параграф 3.3.2.3
|
|
1093
|
Тип защиты канала
|
22/20
|
[RFC5307]/1.2
|
|
1094
|
Маска протокола MPLS
|
—
|
параграф 3.3.2.2
|
|
1095
|
Метрика IGP
|
—
|
параграф 3.3.2.4
|
|
1096
|
Группа общего риска (SRLG)
|
—
|
параграф 3.3.2.5
|
|
1097
|
Неинтерпретируемый (opaque) атрибут канала
|
—
|
параграф 3.3.2.6
|
|
1098
|
Имя канала
|
—
|
параграф 3.3.2.7
|
3.3.2.1. Router-ID TLV IPv4 и IPv6
IPv4 и IPv6 Router-ID TLV (локальные и удалённые) служат для описания дополнительных Router-ID, которые IGP может применять, например, для TE. Все дополнительные Router-ID локального и удалённого узла должны включаться в атрибуты канала для каждого Link NLRI. При наличии нескольких Router-ID данного типа они кодируются в нескольких TLV.
3.3.2.2. MPLS Protocol Mask TLV
MPLS Protocol Mask TLV содержит битовую маску для разрешённых сигнальных протоколов MPLS. Поле Length имеет значение 1, поле Value является массивом из 8 флагов, представляющих возможности протокола MPLS. Генерировать MPLS Protocol Mask TLV следует лишь при понимании источником наличия локального канала, например, Protocol-ID 4 или 5 (Таблица 2). MPLS Protocol Mask TLV недопустимо включать в NLRI для других Protocol-ID из таблицы 2.
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 = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved |
+-+-+-+-+-+-+-+-+
Рисунок 19. Формат MPLS Protocol Mask TLV.
Таблица 10. Коды MPLS Protocol Mask TLV.
|
Бит
|
Описание
|
Описание
|
|
L
|
Протокол распространения меток (Label Distribution Protocol или LDP)
|
[RFC5036]
|
|
R
|
Расширение RSVP для туннелей LSP (RSVP-TE)
|
[RFC3209]
|
|
Reserved
|
Резерв на будущее
|
|
3.3.2.3. TE Default Metric TLV
TE Default Metric TLV передаёт метрику TE для данного канала. TLV имеет размер 4 октета. Если протокол-источник использует метрику размером меньше 32, старшие биты этого поля должны заполняться 0.
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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 20. Формат TE Default Metric TLV.
3.3.2.4. IGP Metric TLV
IGP Metric TLV передаёт метрику для данного канала и имеет переменный размер, зависящий от размера метрики в базовом протоколе. Сокращенная метрика IS-IS занимает 1 октет (2 старших бита игнорируются), метрика OSPF — 2, широкая метрика IS-IS — 3 октета.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 21. Формат IGP Metric TLV.
3.3.2.5. Shared Risk Link Group TLV
Shared Risk Link Group (SRLG) TLV передаёт сведения группы общего риска (см. параграф 2.3 Shared Risk Link Group Information в [RFC4202]) и содержит структуру, состоящую из (переменного) списка значений SRLG, где каждый элемент занимает 4 октета, как показано на рисунке 22. Размер TLV равен 4 * (число значений SRLG).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 22. Формат Shared Risk Link Group TLV.
SRLG TLV для OSPF-TE определены в [RFC4203]. В IS-IS сведения SRLG передаются в двух разных TLV — IPv4 (SRLG) TLV (тип 138) задан в [RFC5307], IPv6 SRLG TLV (тип 139) — в [RFC6119]. В Link-State NLRI сведения IPv4 и IPv6 SRLG передаются в одном TLV.
3.3.2.6. Opaque Link Attribute TLV
Opaque Link Attribute TLV служит для «прозрачной» передачи необязательных Link Attribute TLV, анонсируемых маршрутизатором. Порождающему маршрутизатору нужно применять этот TLV для кодирования сведений, относящихся к новым расширениям протокола, указанного в поле Protocol-ID заголовка NLRI, для которых нет нейтрального к протоколу представления в BGP Link-State NLRI. Основным применением Opaque Link Attribute TLV является преодоление задержки между, например, определением нового атрибута IGP link-state и публикацией нейтральных к протоколу расширений BGP-LS.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 23. Формат Opaque Link Attribute TLV.
3.3.2.7. Link Name TLV
Link Name TLV необязательны. Поле Value указывает символическое имя маршрутизатора, которым может быть полное доменное имя (Fully Qualified Domain Name или FQDN) или его часть (например, hostname), а также заданная оператором строка. Настоятельно рекомендуется применять FQDN или его часть. Максимальный размер Link Name TLV составляет 255 октетов.
Поле Value содержит 7-битовые символы ASCII. Если пользовательский интерфейс позволяет настраивать или отображать символы Unicode, этот интерфейс отвечает за применение алгоритма ToASCII и/или ToUnicode, описанного в [RFC5890], для обеспечения корректного формата передачи.
Вывод и внедрение имён узлов (например, узлов OSPF) маршрутизаторами выходит за рамки этого документа.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 24. Формат Link Name TLV.
3.3.3. TLV для атрибутов префикса
Префиксы извлекаются из топологии IGP (IS-IS или OSPF) с набором атрибутов IGP (метрика, теги маршрутов и т. п.), которые должны отражаться в атрибуте BGP-LS для NLRI префикса. В этом параграфе описаны атрибуты, относящиеся к префиксам IPv4 и IPv6. Prefix Attribute TLV следует применять лишь при анонсировании NLRI типа 3 и 4. Набор Prefix Attribute TLV представлен в таблице 11.
Таблица 11. TLV атрибутов префикса.
|
Код TLV
|
Описание
|
Размер
|
RFC/параграф
|
|
1152
|
Флаги IGP
|
1
|
параграф 3.3.3.1
|
|
1153
|
Тег маршрута IGP
|
4*n
|
[RFC5130]
|
|
1154
|
Расширенный маршрут IGP
|
8*n
|
[RFC5130]
|
|
1155
|
Метрика префикса
|
4
|
[RFC5305]
|
|
1156
|
Адрес пересылки OSPF
|
4
|
[RFC2328]
|
|
1157
|
Неинтерпретируемый (opaque) атрибут префикса
|
переменный
|
параграф 3.3.3.6
|
3.3.3.1. IGP Flags TLV
IGP Flags TLV содержит флаги IS-IS или OSPF и биты, исходно установленные для префикса. Формат IGP Flags TLV показан на рисунке 25.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
Рисунок 25. Формат IGP Flag TLV.
Поле Value содержит биты, показанные в таблице 12.
Таблица 12. Определения флагов IGP.
|
Бит
|
Описание
|
Документ
|
|
D
|
IS-IS Up/Down
|
[RFC5305]
|
|
N
|
OSPF «no unicast»
|
[RFC5340]
|
|
L
|
OSPF «local address»
|
[RFC5340]
|
|
P
|
OSPF «propagate NSSA»
|
[RFC5340]
|
|
Reserved
|
Резерв на будущее
|
|
3.3.3.2. IGP Route Tag TLV
IGP Route Tag TLV передаёт исходные теги IGP (IS-IS [RFC5130] или OSPF) для префикса (Рисунок 26).
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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (1 или несколько) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 26. Формат IGP Route Tag TLV.
Поле Value содержит 1 или несколько тегов, полученных из топологии IGP.
3.3.3.3. Extended IGP Route Tag TLV
Extended IGP Route Tag TLV передаёт расширенные теги маршрутов IS-IS [RFC5130] для префиксов (Рисунок 27).
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 Route Tag (1 или несколько) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 27. Формат Extended IGP Route Tag TLV.
Поле Length имеет значение кратное 8. Поле Extended Route Tag содержит 1 или несколько тегов, полученных из топологии IGP.
3.3.3.4. Prefix Metric TLV
Prefix Metric TLV является необязательным и может включаться лишь однократно, а при наличии передаёт метрику префикса, известную топологии IGP, как описано в разделе 4 [RFC5305] (представляет стоимость доступности префикса). В случае отсутствия префикс анонсируется без оценки доступности.
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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 28. Формат Prefix Metric TLV.
3.3.3.5. OSPF Forwarding Address TLV
OSPF Forwarding Address TLV [RFC2328] [RFC5340] передаёт адрес пересылки OSPF (IPv4 или IPv6), известный из исходного анонса OSPF.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 29. Формат OSPF Forwarding Address TLV.
Поле Length имеет значение 4 для адреса IPv4 и 16 для IPv6.
3.3.3.6. Opaque Prefix Attribute TLV
Opaque Prefix Attribute TLV служит для «прозрачной» передачи необязательных Prefix Attribute TLV, анонсируемых маршрутизатором. Порождающему маршрутизатору нужно применять этот TLV для кодирования сведений, относящихся к протоколу, анонсируемому в поле Protocol-ID заголовка NLRI, или новым расширениям протокола, указанного в поле Protocol-ID заголовка NLRI. Основным применением Opaque Prefix Attribute TLV является преодоление задержки между, например, определением атрибута IGP link-state и публикацией нейтральных к протоколу расширений BGP-LS. Формат TLV показан на рисунке 30.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (переменный) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 30. Формат Opaque Prefix Attribute TLV.
Значения Type приведены в таблице 11, поле Length имеет переменное значение.
3.4. Информация BGP Next-Hop
Сведения BGP о состоянии каналов для сетей IPv4 и IPv6 могут передаваться в сессиях IPv4 BGP или IPv6 BGP. Ели применяется сессия IPv4 BGP, в качестве next hop в MP_REACH_NLRI следует указывать адрес IPv4, для сессии IPv6 BGP — следует указывать адрес IPv6. Обычно в качестве следующего узла (next hop) указывается адрес локальной конечной точки сессии BGP. Адрес next-hop должен кодироваться в соответствии с [RFC4760]. Поле Length в адресе next-hop будет указывать семейство адресов — значение 4 для IPv4, 16 для глобальных адресов IPv6 и 32 для глобальных адресов IPv6, за которыми следует адрес IPv6 link-local. Адрес IPv6 link-local следует использовать в соответствии с [RFC2545]. Для VPN SAFI в соответствии с обычаями перед адресом следующего узла помещается 8-байтовое значение Route Distinguisher.
Атрибут BGP Next Hop применяется каждым узлом BGP-LS для проверки получаемых NLRI. Если идентичные NLRI приходят из нескольких источников, атрибут BGP Next Hop применяется для разрыва привязок (tie break) в соответствии со стандартным процессом выбора пути BGP. Эта спецификация не задаёт каких-либо правил перезаписи атрибута BGP Next Hop.
3.5. Каналы между AS
Основным источником сведений TE являются протоколы IGP, которые не применяются на каналах между AS. Иногда IGP может иметь данные о каналах между AS [RFC5392] [RFC5316], а в иных случаях реализации следует обеспечивать способы внедрения каналов между AS в BGP-LS. Механизмы для этого выходят за рамки документа.
3.6. Пример привязки Router-ID — псевдоузел ISO
Кодирование широковещательных ЛВС в IS-IS является хорошим примером представления Router-ID. Рассмотрим рисунок 31, где показана широковещательная ЛВС между парой маршрутизаторов. Реальные маршрутизаторы (не псевдоузлы) имеют IPv4 Router-ID и IS-IS Node-ID, а у псевдоузла нет IPv4 Router-ID. Node1 является DIS для ЛВС. Создаются два односторонних канала — (Node1, Pseudonode1) и (Pseudonode1, Node2).
Link NLRI для (Node1, Pseudonode1) включает IGP Router-ID TLV с 6-октетным Node Descriptor локального узла и ISO-ID узла Node1 (1920.0000.2001). IGP Router-ID TLV включает 7-октетный Node Descriptor удалённого узла и ISO-ID узла Pseudonode1 (1920.0000.2001.02). Атрибут BGP-LS для этого канала содержит локальный IPv4 Router-ID TLV (TLV типа 1028) со значением 192.0.2.1 для IPv4 Router-ID узла Node1.
Link NLRI для (Pseudonode1, Node2) включает IGP Router-ID TLV с 7-октетным Node Descriptor локального узла и ISO-ID узла Pseudonode1 (1920.0000.2001.02). IGP Router-ID TLV включает 6-октетный Node Descriptor удалённого узла и ISO-ID узла Node2 (1920.0000.2002). Атрибут BGP-LS для этого канала содержит удалённый IPv4 Router-ID TLV (TLV типа 1030) со значением 192.0.2.2 для IPv4 Router-ID узла Node2.
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
Рисунок 31. Псевдоузел IS-IS.
3.7. Пример привязки Router-ID — псевдоузел OSPF
Кодирование широковещательной ЛВС в OSPF является хорошим примером представления Router-ID и локальных Interface IP. Рассмотрим рисунок 32, где представлена широковещательная ЛВС между парой маршрутизаторов. Реальные маршрутизаторы (не псевдоузлы) имеют IPv4 Router-ID и Area Identifier, а псевдоузел — IPv4 Router-ID, адрес интерфейса IPv4 (для однозначности) и OSPF Area. Node1 является DR для ЛВС, поэтому его локальный адрес IP 10.1.1.1 служит Router-ID и Interface IP для ключей псевдоузла. Создаются два односторонних канала — (Node1, Pseudonode1) и (Pseudonode1, Node2).
Link NLRI для (Node1, Pseudonode1) кодируется, как показано ниже.
Link NLRI для (Pseudonode1, Node2) кодируется, как показано ниже.
3.8. Пример привязки Router-ID — псевдоузел переход от OSPFv2 к IS-IS
Для аккуратного перехода от одного протокола IGP к другому нужна согласованная работа обоих протоколов в переходный период. Такое согласование требует идентификации данного физического канала в обоих IGP. IPv4 Router-ID обеспечивает «склейку», имеющуюся в дескрипторах узлов OSPF Link NLRI и атрабутах каналов IS-IS Link NLRI.
Рассмотрим канал «точка-точка» между двумя маршрутизаторами A и B, которые исходно поддерживали лишь OSPFv2, а затем на них был включён протокол IS-IS. Узел A имеет IPv4 Router-ID и ISO-ID, B — IPv4 Router-ID, IPv6 Router-ID и ISO-ID. Каждый протокол создаёт 1 Link NLRI для канала (A, B) и оба передаются в BGP-LS. OSPFv2 Link NLRI для канала кодируется с IPv4 Router-ID узлов A и B, а также с дескрипторами локального и удалённого узла. IS-IS Link NLRI для канала кодируется с ISO-ID узлов A и B, а также с дескрипторами локального и удалённого узла. Кроме того, атрибут BGP-LS в IS-IS Link NLRI включает TLV типа 1028 с IPv4 Router-ID узла A, TLV типа 1030 с IPv4 Router-ID узла B и TLV типа 1031 с IPv6 Router-ID узла B. В этом случае с помощью IPv4 Router-ID канал (A, B) могут идентифицировать оба протокола (IS-IS и OSPF.
4. Агрегирование каналов в путь
Распространение всех имеющихся в Internet каналов, конечно, возможно, однако это нежелательно с точки зрения масштабирования и приватности. Поэтому реализация может поддерживать агрегирование каналов в путь. Вместо анонсирования всех каналов домена маршрутизатор ASBR может анонсировать агрегатный канал (путь) между парой несмежных узлов. Такой агрегатный канал представляет объединённый набор свойств каналов между этими маршрутизаторами. Фактические методы расчёта свойств пути (пропускная способность, метрика и т. п.) выходят за рамки этого документа. Решение об анонсировании всех каналов или только агрегированных путей определяет политика оператора. Для лучшего понимания ниже рассмотрено несколько примеров.
4.1. Пример без агрегирования каналов
В примере на рисунке 33 операторы AS1 и AS2 хотят защитить свои каналы между AS {R1, R3}, {R2, R4} с помощью RSVP-FRR LSP. Если R1 хочет рассчитать LSP с защитой канала до R3, ему нужно «увидеть» дополнительный путь к R3, поэтому оператор AS2 раскрывает свою топологию. Все маршрутизаторы с поддержкой BGP-TE в AS1 «видят» всю топологию AS2 и могут рассчитать резервный путь. Отметим, что рассчитывающий путь маршрутизатор выбирает для использования прямой канал {R3, R4} или путь {R4, R5, R3}.
AS1 : AS2
:
R1-------R3
| : | \
| : | R5
| : | /
R2-------R4
:
Рисунок 33. Без агрегирования каналов.
4.2. Пример с агрегированием ASBR в путь ASBR
Незначительное отличие этого примера от предыдущего состоит в том, что здесь не раскрываются конкретные каналы. На рисунке 34 AS2 анонсирует лишь 1 агрегированный канал между R3 и R4. Этого достаточно, чтобы показать AS1 наличие резервного пути, однако фактические каналы для этого не раскрываются.
AS1 : AS2
:
R1-------R3
| : |
| : |
| : |
R2-------R4
:
Рисунок 34. Агрегирование канала ASBR.
4.3. Пример с агрегированием в путь через множество AS
Сервис-провайдеры, управляющие несколькими AS, могут не раскрывать свои внутренние каналы между AS. На рисунке 35 AS3 представлена как 1 узел, соединённый с граничными маршрутизаторами агрегированного домена.
AS1 : AS2 : AS3
: :
R1-------R3-----
| : : \
| : : vR0
| : : /
R2-------R4-----
: :
Рисунок 35. Агрегирование через несколько AS.
5. Взаимодействие с IANA
Агентство IANA выделило номер семейства адресов 16388 (BGP-LS) в реестре Address Family Numbers со ссылкой на этот документ.
Выделены значения SAFI 71 (BGP-LS) и 72 (BGP-LS-VPN) в субреестре SAFI Values реестра Subsequent Address Family Identifiers (SAFI) Parameters.
Выделено значение 29 (BGP-LS Attribute) в субреестре BGP Path Attributes реестра Border Gateway Protocol (BGP) Parameters.
Агентство IANA создало новый реестр Border Gateway Protocol — Link State (BGP-LS) Parameters <http://www.iana.org/assignments/bgp-ls-parameters>, где доступны указанные ниже реестры, связанные с BGP-LS.
-
BGP-LS NLRI-Types
Значение 0 является резервным. Максимальное значение — 65535. В реестр включены значения, указанные в таблице 1. Для включения в реестр нужно документировать предполагаемое использование (Specification Required) и одобрение эксперта, назначенного IESG (см. [RFC5226]).
-
BGP-LS Protocol-IDs
Значение 0 является резервным. Максимальное значение — 65535. В реестр включены значения, указанные в таблице 2. Для включения в реестр нужно документировать предполагаемое использование (Specification Required) и одобрение эксперта, назначенного IESG (см. [RFC5226]).
-
BGP-LS Well-Known Instance-IDs
В реестр включены значения, указанные в таблице 3. Новые значения из диапазона 1-31 выделяются по процедуре Specification Required после одобрения эксперта, назначенного IESG (см. [RFC5226]). Значения из диапазона 32 — 264-1 предназначены для частных применений (Private Use) и не регистрируются IANA.
-
BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
Значения 0-255 являются резервными. Значения 256-65535 будут служить кодами. В реестр включены значения, указанные в таблице 13. Для включения в реестр нужно документировать предполагаемое использование (Specification Required) и одобрение эксперта, назначенного IESG (см. [RFC5226]).
5.1. Рекомендации для назначенных экспертов
Во всех описанных здесь случаях рецензирования назначенным экспертом (Designated Expert или DE) предполагается, что DE убедится в наличии подходящей документации (спецификации), как описано в [RFC5226], и проверит открытость и постоянную доступность документа. Предполагается также, что DE проверит ясность назначения и применения кодов. Кроме того, DE должен убедиться, что любая спецификация, созданная в IETF, которая запрашивает один из таких кодов, доступна для рассмотрения рабочей группой IDR, а спецификации, созданные вне IETF, не конфликтуют с опубликованными и продолжающимися работами в рамках IETF.
6. Вопросы управляемости
Этот раздел структурирован в соответствии с [RFC5706].
6.1. Эксплуатационные соображения
6.1.1. Операции
Применимы имеющиеся рабочие процедуры BGP и документ не задаёт новых процедур. Следует отметить, что представленные в документе сведения NLRI содержат лишь данные прикладного уровня, которые не влияют напрямую на состояние пересылки. Таким образом, любое «возмущение» (churn) сведений о доступности отличается от воздействия обычных обновлений BGP, которые требуют менять состояние пересылки для всего маршрутизатора. Кроме того, предполагается, что распространение этих NLRI будет обслуживаться выделенными рефлекторами маршрутов, обеспечивающими изоляцию и сдерживание отказов, связанных с разными типами NLRI.
6.1.2. Установка и начальная настройка
Параметры конфигурации, указанные в параграфе 6.2.3, следует инициализировать принятыми по умолчанию значениями:
6.1.3. Внедрение
Предложенное расширение активируется между партнёрами BGP лишь после согласования возможностей. Кроме того, расширения можно включать и отключать индивидуально для каждого партнёра (см. параграф 6.2.3), что обеспечивает поэтапное внедрение в сети.
6.1.4. Требования к другим протоколам и функциональным компонентам
Заданное здесь расширение не вносит новых требований к другим протоколам и функциональным компонентам.
6.1.5. Влияние на работу сети
Частые обновления Link-State NLRI могут помешать обычному распространению префиксов BGP. Оператор сети может использовать инфраструктуру выделенных рефлекторов маршрутов (Route-Reflector) для распространения Link-State NLRI. Распространение Link-State NLRI следует ограничивать одним административным доменом, который может включать множество областей в AS или множество AS.
6.1.6. Проверка корректности работы
Применимы имеющиеся процедуры BGP. В дополнение к этому реализации следует разрешать оператору перечислять соседей, с которыми узел обменивается Link-State NLRI.
6.2. Вопросы управления
6.2.1. Данные управления
Рабочая группа IDR задокументировала и продолжает документировать части базы управляющей информации (Management Information Base или MIB) и модели YANG для мониторинга и управления узлами BGP и сессиями между ними. В настоящее время считается, что сессия BGP с BGP-LS не отличается существенно от других сессий BGP и может управляться по тем же моделям данных.
6.2.2. Контроль отказов
Если реализация BGP-LS обноруживает неверно сформированный атрибут, она должна использовать действие Attribute Discard (отбрасывание атрибута) в соответствии с разделом 2 в [RFC7606]. Реализация BGP-LS должна выполнять указанные ниже синтаксические проверки для обнаружения некорректных сообщений.
-
Соответствие суммы размеров TLV в атрибуте BGP-LS размеру атрибута BGP-LS.
-
Соответствие суммы размеров TLV в атрибуте BGP MP_REACH_NLRI размеру BGP MP_REACH_NLRI.
-
Соответствие суммы размеров TLV в атрибуте BGP MP_UNREACH_NLRI размеру BGP MP_UNREACH_NLRI.
-
Соответствие суммы размеров TLV в атрибуте Node, Link или Prefix Descriptor NLRI полю Total NLRI Length в Node, Link или Prefix Descriptor.
-
Соответствие фиксированного размера TLV указанному в этом документе значению поля TLV Length.
6.2.3. Управление конфигурацией
Реализации следует разрешать оператору:
-
задавать соседей, которым будут анонсироваться и от которых будут восприниматься Link-State NLRI;
-
задавать максимальную скорость, с которой Link-State NLRI будут анонсироваться соседу и отзываться;
-
задавать максимальное число Link-State NLRI, сохраняемых в базе маршрутной информации (Routing Information Base или RIB) маршрутизатора;
-
создавать абстрактные топологии, анонсируемые соседям, и задавать разные абстракции для разных соседей;
-
настраивать 64-битовые Instance-ID;
-
настраивать пары ASN и идентификаторов BGP-LS (параграф 3.2.1.4) для набора лавинной рассылки, в который узел входит.
6.2.4. Управление учётными данными
Неприменимо.
6.2.5. Управление производительностью
Реализации следует предоставлять указанную ниже статистику.
-
Общее число переданных/принятых обновлений Link-State NLRI.
-
Число переданных/принятых обновлений Link-State NLRI по соседям.
-
Число принятых обновлений Link-State NLRI с ошибками по соседям.
-
Общее число созданных локально Link-State NLRI.
Значения статистики следует учитывать с момента запуска системы или сессии. Реализация может расширить статистику, записывает для каждого параметра пиковые значения в секунду.
6.2.6. Управление безопасностью
Оператору следует задать политику импорта для ограничения входящих обновлений путём отбрасывания всех обновлений от партнёров-потребителей. Реализация должна иметь средства ограничения числа входящих обновлений.
7. Сводка кодов TLV и Sub-TLV
В этом разделе приведена сводная таблица заданных в этом документе TLV и sub-TLV.
Таблица 13. Таблица кодов TLV и Sub-TLV.
|
Код TLV
|
Описание
|
IS-IS TLV/Sub-TLV
|
RFC/параграф
|
|
256
|
Дескрипторы локального узла
|
—
|
параграф 3.2.1.2
|
|
257
|
Дескрипторы удалённого узла
|
—
|
параграф 3.2.1.3
|
|
258
|
Локальные и удалённые идентификаторы канала
|
22/4
|
[RFC5307]/1.1
|
|
259
|
Адрес интерфейса IPv4
|
22/6
|
[RFC5305]/3.2
|
|
260
|
Адрес соседа IPv4
|
22/8
|
[RFC5305]/3.3
|
|
261
|
Адрес интерфейса IPv6
|
22/12
|
[RFC6119]/4.2
|
|
262
|
Адрес соседа IPv6
|
22/13
|
[RFC6119]/4.3
|
|
263
|
Multi-Topology ID
|
—
|
параграф 3.2.1.5
|
|
264
|
Тип маршрута OSPF
|
—
|
параграф 3.2.3
|
|
265
|
Сведения о достижимости IP
|
—
|
параграф 3.2.3
|
|
512
|
Автономная система
|
—
|
параграф 3.2.1.4
|
|
513
|
Идентификатор BGP-LS
|
—
|
параграф 3.2.1.4
|
|
514
|
OSPF Area-ID
|
—
|
параграф 3.2.1.4
|
|
515
|
IGP Router-ID
|
—
|
параграф 3.2.1.4
|
|
1024
|
Флаги узла
|
—
|
параграф 3.3.1.1
|
|
1025
|
Неинтерпретируемый (opaque) атрибут узла
|
—
|
параграф 3.3.1.5
|
|
1026
|
Имя узла
|
variable
|
параграф 3.3.1.3
|
|
1027
|
Идентификатор области IS-IS
|
variable
|
параграф 3.3.1.2
|
|
1028
|
IPv4 Router-ID локального узла
|
134/-
|
[RFC5305]/4.3
|
|
1029
|
IPv6 Router-ID локального узла
|
140/-
|
[RFC6119]/4.1
|
|
1030
|
IPv4 Router-ID удалённого узла
|
134/-
|
[RFC5305]/4.3
|
|
1031
|
IPv6 Router-ID удалённого узла
|
140/-
|
[RFC6119]/4.1
|
|
1088
|
Административная группа (цвет)
|
22/3
|
[RFC5305]/3.1
|
|
1089
|
Максимальная пропускная способность канала
|
22/9
|
[RFC5305]/3.4
|
|
1090
|
Максимальная резервируемая пропускная способность канала
|
22/10
|
[RFC5305]/3.5
|
|
1091
|
Нерезервируемая пропускная способность канала
|
22/11
|
[RFC5305]/3.6
|
|
1092
|
Принятая по умолчанию метрика TE
|
22/18
|
параграф 3.3.2.3
|
|
1093
|
Тип защиты канала
|
22/20
|
[RFC5307]/1.2
|
|
1094
|
Маска протокола MPLS
|
—
|
параграф 3.3.2.2
|
|
1095
|
Метрика IGP
|
—
|
параграф 3.3.2.4
|
|
1096
|
Группа общего риска (SRLG)
|
—
|
параграф 3.3.2.5
|
|
1097
|
Неинтерпретируемый (opaque) атрибут канала
|
—
|
параграф 3.3.2.6
|
|
1098
|
Имя канала
|
—
|
параграф 3.3.2.7
|
|
1152
|
Флаги IGP
|
—
|
параграф 3.3.3.1
|
|
1153
|
Тег маршрута IGP
|
—
|
[RFC5130]
|
|
1154
|
Расширенный тег маршрута IGP
|
—
|
[RFC5130]
|
|
1155
|
Метрика префикса
|
—
|
[RFC5305]
|
|
1156
|
Адрес пересылки OSPF
|
—
|
[RFC2328]
|
|
1157
|
Неинтерпретируемый (opaque) атрибут префикса
|
—
|
параграф 3.3.3.6
|
8. Вопросы безопасности
Процедуры и расширения протокола, заданные в этом документе, не влияют на модель безопасности BGP. Общие соображения по безопасности BGP приведены в [RFC4271], а в [RFC4272] и [RFC6952] анализируются проблемы безопасности BGP.
В контексте партнёрства BGP, связанного с этим документом, узлу BGP недопустимо воспринимать обновления от партнёров-потребителей. Т. е. участвующему узлу BGP следует знать природу своих взаимоотношений в плане состояний каналов и следует защищать себя от партнёров, передающих обновления, которые представляют ошибочные контуры обратной связи или ложный ввод. Такая защита может быть обеспечена указанием вручную потребляющих партнёров на узле BGP.
Оператору следует внедрить механизм защиты узлов BGP от DDoS-атак со стороны клиентов. Основной атакой со стороны потребителя является попытка запустить множество сессий последовательно или в параллель. Защиту можно обеспечить путём ограничения частоты таких попыток.
Кроме того, экспорт сведений о состоянии каналов и TE, описанный в этом документе, может быть сочтён риском для конфиденциальности критически важных или коммерческих сведений о сети. Партнёрство BGP не создаётся автоматически и требует настройки, поэтому оператор отвечает за получение такой информации лишь доверенными партнёрами.
9. Литература
9.1. Нормативные документы
[ISO10589] International Organization for Standardization, «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)», ISO/IEC 10589, 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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2545] Marques, P. and F. Dupont, «Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing», RFC 2545, DOI 10.17487/RFC2545, March 1999, <http://www.rfc-editor.org/info/rfc2545>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., «Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[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, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, «Multi-Topology (MT) Routing in OSPF», RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., «LDP Specification», RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, «M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)», RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>.
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, «A Policy Control Mechanism in IS-IS Using Administrative Tags», RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5301] McPherson, D. and N. Shen, «Dynamic Hostname Exchange Mechanism for IS-IS», RFC 5301, DOI 10.17487/RFC5301, October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5305] Li, T. and H. Smit, «IS-IS Extensions for Traffic Engineering», RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[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, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, «OSPF for IPv6», RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, «IPv6 Traffic Engineering in IS-IS», RFC 6119, DOI 10.17487/RFC6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, «OSPFv2 Multi-Instance Extensions», RFC 6549, DOI 10.17487/RFC6549, March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, «IS-IS Multi-Instance», RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, «Revised Error Handling for BGP UPDATE Messages», RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.
9.2. Дополнительная литература
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC5073] Vasseur, JP., Ed. and JL. Le Roux, Ed., «IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities», RFC 5073, DOI 10.17487/RFC5073, December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, «A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)», RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, «ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering», RFC 5316, DOI 10.17487/RFC5316, December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, «OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering», RFC 5392, DOI 10.17487/RFC5392, January 2009, <http://www.rfc-editor.org/info/rfc5392>.
[RFC5693] Seedorf, J. and E. Burger, «Application-Layer Traffic Optimization (ALTO) Problem Statement», RFC 5693, DOI 10.17487/RFC5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5706] Harrington, D., «Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions», RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, «Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide», RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, «Application-Layer Traffic Optimization (ALTO) Protocol», RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[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, <http://www.rfc-editor.org/info/rfc7770>.
Благодарности
Авторы признательны Nischal Sheth, Alia Atlas, David Ward, Derek Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, Ben Campbell за их комментарии.
Участник работы
Спасибо Robert Varga за значительный вклад в этот документ.
Адреса авторов
Перевод на русский язык
Николай Малых
nmalykh@protokols.ru
