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).

Тезисы

В этом документе определена новая возможность протокола BGP1, обозначаемая термином ‘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’2, которая позволяет организовать динамический обмен запросами на обновление маршрутов между узлами 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]. Поля имеют следующие значения:

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

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

SAFI4 – дополнительный идентификатор семейства адресов (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@protocols.ru

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

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

1Border Gateway Protocol

2Функция обновления маршрутов

3Address Family Identifier

4Subsequent Address Family Identifier