Network Working Group Request for Comments: 2918 Category: Standards Track
E. Chen
Redback Networks
September 2000
Возможность обновления маршрутов для BGP-4
Route Refresh Capability for BGP-4
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу 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 AFI
15
---+-
|
23
--+-|
31
--+ |
----Res.
SAFI
+----
------
---+-
-------
--+-
--------
--+
Значение, использование и представление поля <AFI, SAFI> совпадает с аналогичным полем, определенным в [BGP-MP, разд. 7]. Поля имеют следующие значения:
AFI3 - идентификатор семейства адресов (16 битов).
Res. - резервное поле (8 битов). Отправитель устанавливает для этого поля значение 0, а получатель игнорирует его.
SAFI4 – дополнительный идентификатор семейства адресов (8 битов).
1Border Gateway Protocol 2Функция обновления маршрутов 3Address Family Identifier 4Subsequent Address Family Identifier
Перевод RFC 2918
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 за просмотр документа и комментарии.
Предложенная концепция 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 17715, March 1995.
[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 28586, June 2000.
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4"7, RFC 2842, May 2000.
8. Адрес автора
Enke Chen
Redback Networks Inc. 350 Holger Way San Jose, CA 95134 EMail: enke@redback.com
Перевод на русский язык Николай Малых
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.
5Этот документ заменен заменен RFC 4271. Перевод имеется на сайте http://rfc.com.ru. Прим. перев.
6Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
7Этот документ признан устаревшим и заменен RFC 3392. Перевод имеются на сайте http://rfc.com.ru. Прим. перев.
rfc.com.ru                                                                                     2                                                            rfc.com.ru