RFC 2918 — Возможность обновления маршрутов для BGP-4

Тезисы

В этом документе определена новая возможность протокола BGP (Border Gateway Protocol), обозначаемая термином «Route Refresh Capability», которая обеспечит возможность динамического обмена запросами на обновление маршрутов между узлами BGP и последующее реанонсирование соответствующей Adj-RIB-Out. Другим возможным применением новой функции является облегчение неразрушающего изменения политики маршрутизации.

1. Введение

В настоящее время в протоколе BGP-4 [BGP-4] отсутствует механизм запросов на повторное анонсирование Adj-RIB-Out партнером BGP. При изменении для партнера политики маршрутизации на входе (inbound routing policy) все префиксы от данного партнера требуется тем или иным способом сделать доступными и заново проверить с учетом новой политики. Для решения этой задачи общепринятым методом является «мягкая реконфигурация» («soft-reconfiguration»), которая заключается в постоянном хранении всех маршрутов от данного партнера даже при отсутствии частых изменений политики маршрутизации (обычно не более пары раз в день). Для поддержки таких маршрутов требуется дополнительная память и ресурсы CPU.

В этом документе предлагается другое решение, которое избавляет от дополнительный расходов на обслуживание. Точнее говоря, документ определяет новую возможность BGP, названную «Route Refresh Capability» (Функция обновления маршрутов), которая позволяет организовать динамический обмен запросами на обновление маршрутов между узлами BGP и последующее реанонсирование соответствующих Adj-RIB-Out.

2. Route Refresh Capability

Для анонсирования партнеру Route Refresh Capability узел BGP использует BGP Capabilities Advertisement [BGP-CAP]. Эта функция анонсируется с использованием Capability-кода 2 и размера Capability, равного 0.

Анонсируя Route Refresh Capability своему партнеру, узел BGP сообщает тому, что он способен принимать от него и корректно обрабатывать сообщения ROUTE-REFRESH (см. раздел 3).

3. Сообщение ROUTE-REFRESH

Сообщение ROUTE-REFRESH является новым типом сообщений BGP и определяется следующим образом:

• Тип:

  5 - ROUTE-REFRESH

• Формат сообщения:

  Одна пара <AFI, SAFI>, представляемая следующим образом

  0       7      15      23      31
  +-------+-------+-------+-------+
  |      AFI      | Res.  | SAFI  |
  +-------+-------+-------+-------+

Значение, использование и представление поля <AFI, SAFI> совпадает с аналогичным полем, определенным в [BGP-MP, разд. 7]. Поля имеют следующие значения:

• AFI (Address Family Identifier)

  Идентификатор семейства адресов (16 битов).

• Res.

  Резервное поле (8 битов). Отправитель устанавливает для этого поля значение 0, а получатель игнорирует его.

• SAFI (Subsequent Address Family Identifier)

  Дополнительный идентификатор семейства адресов (8 битов).

4. Механизм работы

Узлу BGP, который пожелал принимать сообщения ROUTE-REFRESH от своего партнера, следует анонсировать тому Route Refresh Capability, используя анонс BGP Capabilities [BGP-CAP].

Узел BGP может передать сообщение ROUTE-REFRESH своему партнеру, если он получил от этого партнера сообщение Route Refresh Capability. Паре <AFI, SAFI> в таком сообщении следует быть одной из пар <AFI, SAFI>, которые партнер анонсировал узлу во время организации сеанса при анонсировании своих возможностей.

Если узел BGP принимает от своего партнера сообщение ROUTE-REFRESH с парой <AFI, SAFI>, которую этот узел не анонсировал партнеру во время организации сеанса при анонсировании своих возможностей, узлу следует игнорировать такое сообщение. В остальных случаях узлу BGP следует заново анонсировать этому партнеру Adj-RIB-Out для пары <AFI, SAFI>, указанной в сообщении, основываясь на своей политике исходящей маршрутизации.

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

Данное расширение BGP не оказывает влияния на основные вопросы безопасности.

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

Предложенная концепция Route Refresh подобна одной из используемых в протоколе IDRP.

Автор благодарит Yakov Rekhter, Ravi Chandra, Srihari Ramachandra и Bruce Cole за просмотр документа и комментарии.

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