AAA

RFC 4760 — Многопротокольные расширения для BGP-4

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

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

Тезисы

В этом документе определяется расширение протокола BGP-4, позволяющее передавать информацию для различных протоколов сетевого уровня (например, IPv6, IPX, L3VPN и т. п.). Расширение обеспечивает обратную совместимость — маршрутизаторы, поддерживающие это расширение, смогут нормально работать с маршрутизаторами, которые его не поддерживают.

1. Введение

Только три компоненты информации, передаваемой с помощью BGP-4 [BGP-4], непосредственно связаны с IPv4: (a) атрибут NEXT_HOP (указывается адресом IPv4), (b) AGGREGATOR (содержит адрес IPv4) и (c) NLRI (выражается префиксом адреса IPv4). В этом документе предполагается, что любой узел BGP (включая те, которые поддерживают описанное здесь расширение) имеет адрес IPv4 (который будет вместе с другими параметрами использоваться в атрибуте AGGREGATOR). Следовательно, для того, чтобы BGP-4 поддерживал маршрутизацию для множества протоколов сетевого уровня, в BGP-4 требуется добавить только два элемента: (a) возможность связывания отдельного протокола сетевого уровня с информацией о следующем интервале (next hop) и (b) возможность связывания протокола сетевого уровня с NLRI. Для идентификации протоколов сетевого уровня данный документ использует значение Address Family (семейство адресов), определенное в [IANA-AF], и Subsequent Address Family (описано в этом документе).

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

Для обеспечения совместимости с предыдущими спецификациями и упрощения перехода к поддержке многопротокольного расширения в BGP-4 в данном документе используются два новых атрибута — MP_REACH_NLRI и MP_UNREACH_NLRI. Первый атрибут (MP_REACH_NLRI) используется для передачи набора доступных адресов с информацией о следующем интервале, который будет использоваться для пересылки по этим адресам. Второй атрибут (MP_UNREACH_NLRI) служит для передачи наборов недоступных адресатов. Оба эти атрибута являются необязательными и нетранзитивными. Таким образом, узел BGP, не поддерживающий многопротокольное расширение, просто будет игнорировать содержащуюся в этих атрибутах информацию и не станет передавать ее другим узлам BGP.

2. Описание требований

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

3. MP_REACH_NLRI (тип 14)

Этот необязательный и нетранзитивный атрибут может использоваться с двумя целями:

Формат представления атрибута показан на рисунке:

+---------------------------------------------------------+
| Address Family Identifier (2 octets)                    |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)          |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet)            |
+---------------------------------------------------------+
| Network Address of Next Hop (variable)                  |
+---------------------------------------------------------+
| Reserved (1 octet)                                      |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable)       |
+---------------------------------------------------------+

Назначение полей описано ниже:

Информация о следующем интервале (next hop), передаваемая в атрибуте пути MP_REACH_NLRI, определяет адрес сетевого уровня маршрутизатора, который следует использовать в качестве следующего этапа пересылки адресатам, указанным в атрибуте MP_NLRI сообщения UPDATE.

Правила для информации о следующем интервале совпадают с правилами для информации, передаваемой в атрибуте BGP NEXT_HOP (см. параграф 5.1.3 документа [BGP-4]).

Сообщение UPDATE, содержащее MP_REACH_NLRI, должно также включать атрибуты ORIGIN и AS_PATH (как для EBGP, так и для IBGP). Более того, в обменах IBGP такие сообщения должны также включать атрибут LOCAL_PREF.

В сообщения UPDATE, не содержащие NLRI, кроме значения в атрибуте MP_REACH_NLRI, не следует включать атрибут NEXT_HOP. Если такое сообщение содержит атрибут NEXT_HOP, получившему это сообщение узлу BGP следует игнорировать данный атрибут.

В сообщение UPDATE не следует включать один префикс (одну пару <AFI, SAFI>) более одного раза для полей WITHDRAWN ROUTES, NLRI, MP_REACH_NLRI и MP_UNREACH_NLRI. Обработка сообщений UPDATE с дубликатами префиксов не определена.

4. MP_UNREACH_NLRI (тип 15)

Этот дополнительный нетранзитивный атрибут может использоваться для отзыва невозможных маршрутов.

Формат атрибута показан на рисунке:

+---------------------------------------------------------+
| Address Family Identifier (2 octets)                    |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)          |
+---------------------------------------------------------+
| Withdrawn Routes (variable)                             |
+---------------------------------------------------------+

Назначение полей атрибута описано ниже:

Сообщение UPDATE, содержащее MP_UNREACH_NLRI, может не включать других атрибутов пути.

5. Представление NLRI

Информация о доступности на сетевом уровне (NLRI) представляется в форме одной или множества пар <length, prefix>, показанных на рисунке:

+---------------------------+
|   Length (1 octet)        |
+---------------------------+
|   Prefix (variable)       |
+---------------------------+

Назначение каждого поля пар описано ниже:

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

Этот документ определяет следующие значения поля Subsequent Address Family Identifier для атрибутов MP_REACH_NLRI и MP_UNREACH_NLRI:

Реализация может поддерживать все или часть определенных в этом документе значений SAFI или не поддерживать их совсем.

7. Обработка ошибок

Если узел BGP получает от соседа сообщение UPDATE с атрибутом MP_REACH_NLRI или MP_UNREACH_NLRI и видит, что атрибут указан некорректно, он должен удалить все маршруты BGP, полученные от данного соседа, в которых значения AFI/SAFI совпадают с одним из содержащихся в некорректном атрибуте MP_REACH_NLRI или MP_UNREACH_NLRI. До завершения сеанса BGP, в котором получено сообщение UPDATE, узлу следует игнорировать все последующие маршруты с AFI/SAFI, принятыми в этой сессии.

В дополнение к сказанному узел может прервать сеанс BGP, в котором было получено сообщение UPDATE. Сессию следует прерывать с помощью сообщения NOTIFICATION, содержащего код/субкод ошибки Update Message Error/Optional Attribute Error.

8. Использование анонсирования возможностей BGP

Узлу BGP, использующему описанное здесь расширение, следует применять процедуры анонсирования возможностей (Capability Advertisement) [BGP-CAP] для определения возможности использования данного расширения при работе с тем или иным партнером.

Для полей дополнительного параметра Capabilities следует установить приведенные здесь значения. Поле Capability Code должно содержать значение 1 (указывает на Multiprotocol Extensions). Поле Capability Length должно иметь значение 4.

Формат поля Capability Value показан на рисунке:

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

Компоненты этого поля описаны ниже:

Узел, поддерживающий множество пар <AFI, SAFI>, включает их как множество возможностей в дополнительный параметр Capabilities.

Чтобы организовать двухсторонний обмен маршрутной информацией для той или иной пары <AFI, SAFI> между двумя узлами BGP, каждый из этих узлов должен анонсировать партнеру (с помощью механизма Capability Advertisement) возможность поддержки маршрутов для соответствующей пары <AFI, SAFI>.

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

Как указано выше, атрибуты MPL_REACH_NLRI и MP_UNREACH_NLRI содержат поле дополнительного идентификатора семейства адресов (SAFI). Пространство имен SAFI определено в данном документе. IANA поддерживает и регистрирует значения SAFI, как описано ниже.

10. Сравнение с RFC 2858

Этот документ согласует использование информации о следующем интервале с информацией, передаваемой в атрибуте пути BGP NEXT_HOP.

Из документа удалено определение SAFI 3 и отменено использование SAFI 3.

В этом документе изменено распределение пространства значений SAFI. В частности, RFC 2858 определял значения SAFI от 128 до 240 для приватного использования. В данном документе распределение этого блока передается IANA и неиспользуемые значения 130, 131, 135 - 139 и 141 - 240 из этого диапазона следует рассматривать в качестве резервных.

В этом документе поле Number of SNPA переведено в состояние резервного, а последующие поля атрибута MP_REACH_NLRI, , связанные с SNPA, удалены.

11. Сравнение с RFC 2283

Этот документ ограничивает атрибут MP_REACH_NLRI передачей единственного экземпляра <AFI, SAFI, Next Hop Information, ...>.

Этот документ ограничивает атрибут MP_UNREACH_NLRI передачей единственного экземпляра <AFI, SAFI, ...>.

Этот документ разъясняет обработку сообщений UPDATE, не содержащих NLRI, кроме значения в атрибуте MP_REACH_NLRI.

Этот документ разъясняет обработку ошибок при наличии атрибутов MP_REACH_NLRI или MP_UNREACH_NLRI.

Этот документ содержит спецификацию использования анонсов возможностей BGP вместе с многопротокольными расширениями.

Этот документ включает раздел 9. Согласование с IANA.

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

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

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

Авторы благодарят членов рабочей группы IDR за обзор и комментарии к документу.

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

  1. [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
  2. [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006
  3. [IANA-AF] "Address Family Numbers", Reachable from http://www.iana.org/numbers.html
  4. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  5. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  6. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.

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

Tony Bates
Cisco Systems, Inc.
EMail: moc.ocsic@setabt

Ravi Chandra
Sonoa Systems
EMail: moc.smetsysaonos@ardnahcr

Dave Katz
Juniper Networks, Inc.
EMail: ten.repinuj@ztakd

Yakov Rekhter
Juniper Networks, Inc.
EMail: ten.repinuj@vokay

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

Николай Малых, ur.slocotorp@hkylamn