AAA

RFC 5291 — Возможность выходной фильтрации маршрутов для BGP-4

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

В этом документе содержится проект стандарта протокола Internet для сообщества Internet и приглашение к дискуссии в целях развития и совершенствования.

Текущее состояние стандартизации протокола и его статус можно узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Тезисы

В этом документе определен основанный на протоколе BGP механизм, позволяющий узлу BGP передавать своим партнерам набор фильтров ORF (Outbound Route Filters — выходные фильтры маршрутов), которые этот партнер будет использовать для ограничения/фильтрации исходящих маршрутных обновлений для данного узла.

1. Введение

В настоящее время обычной практикой для узлов BGP [BGP-4] является прием маршрутных обновлений от партнера с последующей фильтрацией нежелательных обновлений на основе локальной политики маршрутизации. Поскольку генерация и передача маршрутных обновлений отправителем, равно как их обработка получателем, потребляют ресурсы, отказ от генерации нежелательных маршрутных обновлений может давать преимущества.

В этом документе определен основанный на протоколе BGP механизм, позволяющий узлу BGP передать своему партнеру BGP набор фильтров ORF. Партнер будет применять полученные фильтры в дополнение к фильтрам, заданным в его локальной конфигурации (если таковые имеются), для ограничения/фильтрации маршрутных обновлений, передаваемых данному узлу.

2. Спецификация требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Фильтр ORF

В контексте этого документа термины «идентификатор семейства адресов» (AFI — Address Family Identifier) и «дополнительный идентификатор семейства адресов» (SAFI — Subsequent AFI) трактуются в соответствии с [BGP-MP].

Концептуально элемент ORF представляет собой последовательность полей <AFI/SAFI, ORF-Type, Action, Match, ORF-value> и ORF состоит из одного или множества элементов ORF с совпадающими значениями AFI/SAFI и ORF-Type. Фильтр ORF идентифицируется парой <AFI/SAFI, ORF-Type>.

Компонента AFI/SAFI обеспечивает грубый контроль за счет выбора только тех маршрутов, в которых значения NLRI (Network Layer Reachability Information — информация о доступности на сетевом уровне) соответствуют компоненте AFI/SAFI в фильтре ORF.

Компонента ORF-Type определяет содержимое поля ORF-value.

Компонента Action управляет обслуживанием запросов ORF Request удаленным партнером. В качестве действия могут служить операции ADD, REMOVE, REMOVE-ALL. Операция ADD добавляет элемент ORF в фильтр ORF удаленного партнера, REMOVE удаляет ранее установленный для удаленного партнера элемент ORF, а REMOVE-ALL удаляет все ранее установленные для заданного ORF элементы.

Компонента Match используется для управления действиями на уровне элемента ORF и может принимать значения PERMIT или DENY. Значение PERMIT используется для запроса у партнера передачи обновлений для маршрутов, соответствующих записи ORF. Значение DENY используется для запроса у партнера фильтрации (отказа от передачи) обновлений, соответствующих элементу ORF.

При определении ORF конкретные правила соответствия для данного ORF должны быть заданы так, чтобы не возникало неоднозначностей при определении элемента ORF, по отношению к которому проверяется соответствие при прохождении маршрута через ORF.

4. Передача элементов ORF в BGP

Элементы ORF передаются в сообщениях BGP ROUTE-REFRESH [BGP-RR].

Узел BGP может отличать входящие сообщения ROUTE-REFRESH с одним или несколькими элементами ORF от обычных сообщений ROUTE-REFRESH с помощью поля Message Length в заголовке сообщения BGP.

В одном сообщении ROUTE-REFRESH может содержаться множество элементов ORF для одного или множества фильтров ORF, при условии, что для всех этих элементов значения AFI/SAFI совпадают.

С точки зрения кодирования каждый элемент ORF состоит из общей части и зависимой от типа части, как показано на рисунках 1 и 2.

Общая часть включает поля <AFI/SAFI, ORF-Type, Action, Match> и представляется следующим образом:

Остальные компоненты общей части кодируются в первом октете каждого элемента ORF (отсчет от старшего бита), как показано на рисунке 2.

5. Возможность выходной фильтрации маршрутов

Узел BGP, желающий получать элементы ORF от своего партнера, или узел BGP, желающий передавать элементы ORF своему партнеру анонсирует поддержку Outbound Route Filtering Capability, как описано ниже.

Outbound Route Filtering Capability представляет собой новую возможность BGP [BGP-CAP], определяемую следующим образом:

Значения полей описаны ниже:

6. Функционирование

Узлу BGP, желающему получать элементы ORF от своего партнера или передавать элементы ORF своему партнеру следует анонсировать партнеру возможность фильтрации маршрутов (Outbound Route Filtering Capability) с использованием механизма BGP Capabilities [BGP-CAP].

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

Рассмотрим узел BGP, который анонсирует Outbound Route Filtering Capability, указывая свое желание получать от партнера определенный набор <AFI/SAFI, ORF-type>, и получает анонсы Outbound Route Filtering Capability, показывающие, что партнер передает определенный набор <AFI/SAFI, ORF-type> данному узлу. Если для данных значений AFI/SAFI пересечение двух анонсируемых множеств не пусто, узлу BGP не следует анонсировать своему партнеру никаких маршрутов с данными AFI/SAFI до получения от этого партнера сообщения ROUTE-REFRESH с данными AFI/SAFI; это сообщение может не включать элементов ORF или включать один или множество элементов ORF и поле When-to-refresh = IMMEDIATE. С другой стороны, если для данных AFI/SAFI пересечение двух множеств пусто, узел должен следовать обычным процедурам BGP.

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

Когда узел BGP получает от своего партнера сообщение ROUTE-REFRESH с одним или множеством элементов ORF, он выполняет перечисленные ниже операции. Если значения <AFI/SAFI, ORF-type> в сообщении не соответствуют значениям <AFI/SAFI, ORF-type>, которые узел желает получать от партнера (как было указано в анонсе Outbound Route Filtering Capability), соответствующие элементы ORF в полученном сообщении игнорируются. При совпадении значений узел изменяет соответствующие ORF, полученные ранее, согласно элементам ORF из принятого сообщения. Если любое из полей элемента ORF в сообщении содержит нераспознанное значение, соответствующий фильтр ORF, полученный ранее, полностью удаляется.

Если компонента Action элемента ORF имеет значение REMOVE, но полученный ранее фильтр ORF не содержит указанного элемента, запись ORF в сообщении игнорируется.

Элементы ORF со значениями REMOVE или REMOVE-ALL не могут удаляться локально сконфигурированными выходными фильтрами маршрутов.

Если поле When-to-refresh содержит значение IMMEDIATE, после обработки всех элементов ORF, содержащихся в сообщении, узел повторно анонсирует партнеру маршруты из Adj-RIB-Out, связанные с партнером, которые имеют такие же значения AFI/SAFI, какие были получены в сообщении, и принимает во внимание все элементы ORF для значений AFI/SAFI, принятых от партнера. Узел должен повторно анонсировать все маршруты, на которые оказывают влияние элементы ORF из принятого сообщения, и может также реанонсировать маршруты, на которые элементы ORF из сообщения не воздействуют.

Если When-to-refresh = DEFER, после обработки всех элементов ORF в сообщении узел отказывается от реанонсирования партнеру маршрутов из Adj-RIB-Out, связанных с партнером, который имеет такие же значения AFI/SAFI, что были получены в сообщении, и принимает во внимание все элементы ORF, полученные от партнера, до тех пор пока не будет принято следующее сообщение ROUTE-REFRESH с такими же значениями AFI/SAFI, но без элементов ORF или с одним или множеством элементов ORF и When-to-refresh = IMMEDIATE.

Если узел получает от партнера сообщение ROUTE-REFRESH без элементов ORF, этот узел передает партнеру все маршруты из Adj-RIB-Out, связанные с партнером, для которых значения AFI/SAFI совпадают с полученными в сообщении, и принимает во внимание все ранее принятые от партнера ORF (если таковые имеются).

Набор элементов ORF, которые узел передает партнеру, выражает локальные предпочтения узла, которые этот партнер может принимать или не принимать во внимание.

В течение сеанса BGP узел может передавать партнеру множество элементов ORF.

После того, как узел BGP меняет элементы ORF, переданные ранее партнеру, он должен передать этому партнеру обновленные элементы ORF с (a) When-to-refresh = IMMEDIATE или (b) When-to-refresh = DEFER с последующим обычным сообщением ROUTE-REFRESH. Второй вариант должен использоваться узлом в тех случаях, когда имеются другие изменения в политике (в дополнение к элементам ORF), требующие реанонсирования партнеру всех маршрутов.

Время жизни фильтров ORF ограничивается продолжительностью сессии BGP, в которой происходил обмен ORF.

Фильтр ORF удаляется при удалении последнего элемента ORF (с помощью REMOVE-ALL или последовательности REMOVE).

Если отдельный маршрут, поддерживаемый узлом BGP, не соответствует ни одному элементу ORF ни в одном из (непустых) фильтров ORF, связанных с определенным партнером, такой маршрут не следует анонсировать данному партнеру.

Если узел BGP поддерживает множество ORF с разными ORF-Type для одного партнера, решение об анонсировании маршрута такому партнеру принимается путем просмотра маршрута всеми ORF и объединения полученных результатов (при объединении PERMIT и DENY результатом будет DENY).

7. Согласование с IANA

В этом документе определяется новая возможность BGP — Outbound Route Filtering Capability. Значение Capability Code для Outbound Route Filtering Capability равно 3.

Как указано в этом документе, элемент ORF содержит поле ORF-Type, для которого агентство IANA создало и поддерживает реестр «BGP Outbound Route Filtering (ORF) Types».

IANA поддерживает и регистрирует значения поля ORF-Type в соответствии с приведенными ниже условиями:

8. Вопросы управления

Объекты управления для фильтров BGP ORF будут определены в отдельном документе. Однако предполагается, что будут определены следующие объекты:

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

Данное расширение BGP не отражается на вопросах безопасности, рассмотренных в [BGP-4].

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

Часть материалов этого документа является адаптацией предложения для селективных обновлений, подготовленного Yakov Rekhter, Kannan Varadhan и Curtis Villamizar.

11. Нормативные документы

  1. [BGP-4] Y. Rekhter, T. Li, S. Hares, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006
  2. [BGP-MP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, January 2007
  3. [BGP-CAP] R. Chandra, J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392, November 2002.
  4. [BGP-RR] E. Chen, «Route Refresh Capability for BGP-4», RFC 2918, September 2000.
  5. [RFC2119] S. Bradner, «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
  6. [RFC4020] K. Kompella, A. Zinin, «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 4020, February 2005.
  7. [RFC5226] T. Narten, H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: moc.ocsic@nehcekne

Yakov Rekhter
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: ten.repinuj@vokay

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

Николай Малых, moc.milib@hkylamn