AAA

RFC 4384 — Группы BGP для сбора данных

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

Этот документ описывает практический опыт (Internet Best Current Practices) для сообщества Internet и является приглашением к дискуссии в целях развития и совершенствования. Документ может распространяться свободно.

Тезисы

Группы BGP (RFC 1997) используются сервис-провайдерами для разных целей, включая метки маршрутов в соответствии с заказчиком, партнером или географией исходной точки. Такие метки обычно служат для контроля за областью распространения маршрутов в сети провайдера, а также среди его партнеров и заказчиков. Из результатов крупномасштабного сбора данных BGP (и связанных с этим исследований) становится ясно, что передаваемая в таких группах весьма важна для более глубокого понимания глобальной системы маршрутизации. В этом документе определяются стандартные (исходящие — outbound) группы и их представление для экспорта в системы сбора маршрутной информации BGP.

Оглавление

1. Введение

Группы BGP [RFC1997] используются сервис-провайдерами для разных целей, включая метки маршрутов в соответствии с заказчиком, партнером или географией исходной точки. Такие метки обычно служат для контроля за областью распространения маршрутов в сети провайдера, а также среди его партнеров и заказчиков. Группы также используются для широкого спектра других приложений, таких, как предоставление потребителям возможности установки атрибутов типа LOCAL_PREF [RFC1771] путем передачи соответствующих групп своему провайдеру. К числу приложений относится также сигнализация различных типов VPN (например, VPLS [VPLS]), и передача информации о ширине полосы для систем управления трафиком [RFC4360].

Из результатов крупномасштабного сбора данных BGP [RV] [RIS] (и связанных с этим исследований) становится ясно, что географическая и топологическая информация, а также отношение провайдера к исходной точке маршрута (например, транзитный узел, партнер или потребитель), содержащиеся в таких группах, весьма важны для более глубокого понимания глобальной системы маршрутизации. В этом документе определяются стандартные группы для экспорта с системы сбора маршрутной информации BGP. Эти группы представляют существенную часть информации, передаваемой сервис-провайдерами, и данные могут быть полезными для решения внутренних задач сервис-провайдеров. Однако такое использование данных выходит за пределы настоящего документа. Тем, кто вовлечен в анализ данных BGP, рекомендуется проверить какие из их источников данных реализуют эту схему (поскольку существует большое количество данных, а также множество унаследованных партнерских отношений).

Оставшаяся часть документа организована следующим образом — глава 2 содержит определения терминов, которые применяются как семантика групп, используемых для сбора данных BGP, а глава 3 определяет соответствующее кодирование групп RFC 1997 [RFC1997]. Наконец, в главе 4 определяется кодирование для использования с расширенными группами [RFC4360].

2. Определения

В этой главе мы определим используемые термины и категории маршрутов, которые могут помечаться с помощью групп. Такие метки часто называют «окрашиванием» и мы будем говорить о «цветах» маршрутов, задаваемых принадлежностью к группам. Определенные здесь категории напоминают описанные в работах [WANG] и [HUSTON].

2.1. Партнеры и партнерство

Рассмотрим двух сервис-провайдеров, A и B. Эти провайдеры считаются партнерами, если (i) A и B обмениваются маршрутами по протоколу BGP и (ii) обмен трафиком между A и B происходит на бесплатной основе. Такое соглашение обычно называют партнерством. Партнеры обычно обмениваются между собой только маршрутами к своим клиентам (см. следующий параграф) и, следовательно, обмениваются между собой только клиентским трафиком. Более детальное обсуждение бизнес-моделей, близких к партнерству, можно найти в работе [HUSTON].

2.2. Маршруты потребителей

Маршруты потребителей (Customer route) — это те маршруты, которые получены от заказчиков через протокол BGP и распространяются партнерам и другим потребителям. Отметим, что потребителем (заказчиком) может быть организация или другой сервис-провайдер. Такие маршруты иногда называют клиентскими (client route) [HUSTON].

2.3. Маршруты партнеров

Маршруты партнеров (Peer route) — это те маршруты, которые были получены от партнеров по протоколу BGP и не распространяются другим партнерам. Однако такие маршруты распространяются потребителям данного провайдера.

2.4. Внутренние маршруты

Внутренние маршруты (Internal route) — это маршруты, исходящие от данного сервис-провайдера и передаваемые партнерам и заказчикам. Эти маршруты зачастую выбираются из выделенного провайдеру адресного пространства.

2.5. Внутренние более специфичные маршруты

Внутренние более специфичные маршруты (Internal more specific route) — это маршруты, которые часто используются в целях балансировки нагрузки и снижения числа маршрутов IGP. Они могут также соответствовать службам, которые недоступны за пределами сети данного провайдера. Такие маршруты не экспортируются никаким внешним партнерам.

2.6. Маршруты специального назначения

Маршруты специального назначения (Special purpose route) — это те маршруты, которые не могут быть отнесены ни к одному из описанных здесь классов. В тех случаях, когда такие маршруты требуется как-то выделить, сервис-провайдер может окрасить их с использованием уникального цвета. Примерами маршрутов специального назначения являются anycast-маршруты и маршруты для перекрывающихся сетей (overlay network).

2.7. Восходящие маршруты

Восходящие маршруты (Upstream route) обычно получают от вышестоящего сервис провайдера как часть транзитного обслуживания, выполняемого вышестоящим провайдером в рамках контракта.

2.8. Национальные маршруты

Набор маршрутов, начинающихся и/или полученных из определенной страны.

2.9. Региональные маршруты

Некоторые глобальные магистрали реализуют региональную политику, основанную на географии развернутой ими сети, а также на их стратегии и требованиях бизнеса. Сервис-провайдеры часто имеют в одном регионе бесплатные (settlement-free) соединения с AS, которые в другом регионе являются потребителями. Это вынуждает использовать региональную политику, включающую атрибуты групп, устанавливаемые сетью, для того, чтобы можно было легко различать маршруты разных регионов. Например, сервис-провайдер может трактовать набор маршрутов, полученных от другого сервис-провайдера в Европе, совсем не так, как тот же набор маршрутов, полученный в северной Америке, поскольку повсеместно может устанавливаться платный транзит для одних регионов и бесплатное партнерство — для других.

3. Кодирование и значения групп RFC 1997

В этой главе приводятся значения групп (community) RFC 1997 [RFC1997] для описанных выше категорий. Группы RFC 1997 кодируются как BGP Type Code 8 и трактуются как 32битовые значений из диапазона 0x0000000 - 0xFFFFFFF. Значения от 0x0000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.

Среди современных провайдеров принято использовать два старших октета для номера AS, а двумя младшими октетами задавать классификацию маршрута, как показано ниже:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            <AS>               |         <Value>               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<AS> представляет собой 16-битовый номер автономной системы. Например, значение 0x2A7C029A будет представлять AS 10876 и значение 666.

4. Значения Community для сбора данных BGP

В этой главе мы определим для описанных выше категорий маршрутов кодирование групп RFC 1997, которые используются для сбора данных BGP. Предполагается, что используемые сервис-провайдерами внутренние значения будут приведены в соответствие с этими стандартными значениями для вывода в системы сбора маршрутных данных (route collector).

Этот документ следует общепринятой на сегодняшний день практике использования базового формата <AS>:<Value>. Значения для разных категорий маршрутов приведены в таблице.

КатегорияЗначение
Резерв<AS>:0000000000000000
Маршруты потребителей<AS>:0000000000000001
Маршруты партнеров<AS>:0000000000000010
Внутренние маршруты<AS>:0000000000000011
Внутренние более специфичные маршруты<AS>:0000000000000100
Маршруты специального назначения<AS>:0000000000000101
Восходящие маршруты<AS>:0000000000000110
Резерв<AS>:0000100000000000 - <AS>:0000011111111111
Национальные и региональные маршруты Кодируются как<AS>:1111111111111111
<AS>:<R><X><CC>
Зарезервированные национальные и региональные маршруты<AS>:0100000000000000 - <AS>:1111111111111111

где

Идентификатор <R> может принимать значения:

Формат значения для национального или регионального маршрута показан ниже:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            <AS>               |   <R>   |X|        <CC>       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Например, кодирование национального маршрута через наземный канал в AS 10876 с островов Фиджи (Fiji) будет иметь вид:

В этом случае младшие 16 битов будут иметь значение 0001000011110010 = 0x10F2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           0x2A7C              |           0x10F2              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Отметим, что конфигурационный язык может позволять спецификацию этой группы в форме 10876:4338 (4338 — десятичное представление 0x10F2).

Отметим, что эти категории не являются взаимоисключающими и допускается указание множества групп в тех случаях, где это подходит.

4.1. Расширенные группы

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

Атрибут Extended Communities является необязательным переходным атрибутом BGP с кодом типа (Type Code) 16. Атрибут содержит в себе набор расширенных групп в показанном ниже формате.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type high    |  Type low(*)  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Для сбора данных BGP мы кодируем описанные в параграфе 4 группы с использованием типа «two-octet AS specific extended community», который имеет следующий формат:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |   Sub-Type    |    Global Administrator       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Administrator                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Группа two-octet AS specific extended community attribute содержит 2-октетный номер автономной системы провайдера (присвоенный ему региональным регистратором или RIR) в поле Global Administrator, а поле Local Administrator может кодировать любую информацию.

В этом документе выделяется значение субтипа (Sub-Type) 0x0008 для сбора данных BGP и задается значение поля <Value> (в соответствии с параграфом 3.1) для двух младших октетов поля Local Administrator. Два старших октета поля Local Administrator зарезервированы — они устанавливаются в 0x00 при передаче и игнорируются на принимающей стороне.

Например, кодирование расширенной группы 10876:4338, представляющей наземный маршрут в AS 10876 с островов Фиджи, будет иметь вид:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |      0x0008   |           0x2A7C              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |      0x00     |           0x10F2              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. 4-октетные расширенные группы уровня AS

Группы four-octet AS specific extended community кодируются следующим образом:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x02     |    0x0008     |    Global Administrator       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.)  |           0x10F2              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В этом случае 4-октетное субполе Global Administrator содержит четырехоктетный номер AS, выделенный IANA.

5. Замечание по упаковке сообщений BGP UPDATE

Отметим, что используемые для сбора данных группы могут делать набор атрибутов конкретного маршрута уникальным (поскольку каждый маршрут собирает данные, специфические для его пути через одну или множество AS), что не происходило бы при отсутствии атрибута группы. Это, в свою очередь, может оказывать влияние на группировку маршрутов при упаковке обновлений BGP и приводить к повышенному расходу полосы каналов, ресурсов процессора в маршрутизаторах, а также оперативной памяти.

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

Описанное в этом документе кодирование групп порождено интересным предложением от Akira Kato из WIDE. В частности, ему принадлежит идея использовать набор значений групп для выбора путей, которые будут (к счастью) повышать эффективность доступа к различным типам сервиса. Например, для сервиса DNS на основе RFC 3258 [RFC3258] маршрутизаторы BGP могут видеть множество путей к одному префиксу. Эти маршруты могут иметь общее происхождение, но разные пути через сеть, а некоторые могут различаться по странам и регионам (с той же самой исходной AS).

Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay Gill, John Heasley, Geoff Huston, Steve Huter, Michael Patton, Olivier Marce, Ryan McDowell, Rob Rockell, Rob Thomas, Pekka Savola, Patrick Verkaik и Alex Zinin внесли множество полезных комментариев в ранние варианты этого документа. Henk Uijterwaal предложил использовать коды стран ISO-3166-2.

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

Хотя этот документ не порождает дополнительных вопросов безопасности для протокола BGP, содержащаяся в группах информация, которая определена в данном документе, может в некоторых случаях раскрывать структуру сети, которая до этого не была видна за пределами сети провайдера. В связи с этим следует соблюдать предосторожности при экспорте таких групп в системы сбора маршрутной информации (route collector). Маршруты, экспортируемые в route collector, следует помечать атрибутом группы NO_EXPORT (0xFFFFFF01).

7.1. Общий размер атрибутов

Описанные в этом документе группы предназначены для использования на выходе в систему сбора маршрутной информации (route collector). Следовательно, оператор может заменить свои внутренние группы на заданные этим документом значения при экспорте маршрутов в route collector. Однако операторам следует быть уверенными в том, что их реализация BGP корректно будет вести себя в тех случаях, когда в результате добавления атрибутов размер PDU превысит 4096 октетов. Например, поскольку общепринятой практикой является использование групп для реализации политики (скажем, обеспечения потребителям возможности установки таких атрибутов, как LOCAL_PREF), поведение реализации в случаях переполнения пространства атрибутов может играть критическую роль. Некоторые реализации могут в таких случаях захватывать данные атрибута или вызывать неопределенные отказы. Такое поведение может привести к установке неожиданных наборов атрибутов community и, следовательно, оказать нежелательное влияние на политику.

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

Данный документ определяет новый субтип (Sub-Type) для типа AS specific extended community в категории расширенных переходных значений, распределяемой на основе правила First Come First Served. Агентство IANA выделило для Sub-Type значение 0x0008, как определено в парашрафе 4.1.

В дополнение к сказанному агентство IANA создало два реестра для BGP Data Collection Communities — один для стандартных, а второй для расширенных групп. Оба эти реестра в своем исходном состоянии включают значения, описанные в параграфе 4. Для выделения новых значений в этих реестрах (в частности, для <Value> или <R> в таблице значений для категорий маршрутов, описанных в параграфе 4) используется процедура IETF Consensus, как описано в [RFC2434]. Обычно это делается через рабочую группу GROW.

9. Литература

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

  1. [RFC1771] Rekhter, Y. and T. Li (Editors), "A Border Gateway Protocol (BGP-4)", RFC 1771, March 1995.
  2. [RFC1997] Chandra, R. and P. Traina, "BGP Communities Attribute", RFC 1997, August 1996.
  3. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, January 2006.

9.2. Дополнительная литература

  1. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  2. [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002.
  3. [VPLS] Kompella, K., et al., "Virtual Private LAN Service", Work in Progress, April 2005.

Адрес автора

David Meyer, EMail: ten.5-4-1@mmd

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

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