RFC 2918 Route Refresh Capability for BGP-4

Network Working Group                                        E. Chen
Request for Comments: 2918                          Redback Networks
Category: Standards Track                             September 2000

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

Route Refresh Capability for BGP-4

PDF

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

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

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

Copyright (C) The Internet Society (2000).

Аннотация

В этом документе определена новая возможность протокола BGP¹, обозначаемая термином ‘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³ – идентификатор семейства адресов (16 битов).

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

SAFI⁴ – дополнительный идентификатор семейства адресов (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. Литература

[BGP-4] Rekhter, Y. and T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 1771, March 1995.

[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 2858, June 2000.

[BGP-CAP] Chandra, R. and J. Scudder, “Capabilities Advertisement with BGP-4”, RFC 2842, May 2000.

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

Enke Chen

Redback Networks Inc.

350 Holger Way

San Jose, CA 95134

EMail: enke@redback.com

---

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

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

nmalykh@protokols.ru

9. Полное заявление авторских прав

Copyright (C) The Internet Society (2000). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.