RFC 4384 BGP Communities for Data Collection

Network Working Group                                       D. Meyer
Request for Comments: 4384                             February 2006
BCP: 114
Category:  Best Current Practice

 

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

BGP Communities for Data Collection

PDF

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

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

Авторские права

Copyright (C) The Internet Society (2006).

Аннотация

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

1. Введение

Группы BGP [RFC1997] используются сервис-провайдерами для разных целей, включая метки маршрутов в соответствии с заказчиком, партнером или географией исходной точки. Такие метки обычно служат для контроля за областью распространения маршрутов в сети провайдера, а также среди его партнеров и заказчиков. Группы также используются для широкого спектра других приложений, таких, как предоставление потребителям возможности установки атрибутов типа LOCAL_PREF [RFC1771] путем передачи соответствующих групп своему провайдеру. К числу приложений относится также сигнализация различных типов VPN3 (например, VPLS4 [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 происходит на бесплатной основе. Такое соглашение обычно называют партнерством5. Партнеры обычно обмениваются между собой только маршрутами к своим клиентам (см. следующий параграф) и, следовательно, обмениваются между собой только клиентским трафиком. Более детальное обсуждение бизнес-моделей, близких к партнерству, можно найти в работе [HUSTON].

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

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

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

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

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

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

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

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

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

Маршруты специального назначения (Special purpose route) – это те маршруты, которые не могут быть отнесены ни к одному из описанных здесь классов. В тех случаях, когда такие маршруты требуется как-то выделить, сервис-провайдер может окрасить их с использованием уникального цвета. Примерами маршрутов специального назначения являются anycast-маршруты7 и маршруты для перекрывающихся сетей (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

где

<AS> – 16-битовый номер AS;

<R> – 5-битовый идентификатор региона;

<X> – 1-битовая индикация спутниковых каналов (X = 1 для спутниковых каналов, 0 – для прочих);

<CC> – 10-битовый код страны ISO-3166-2 [ISO3166]

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

Африка (AF) 00001

Океания (OC) 00010

Азия (AS) 00011

Антарктика (AQ) 00100

Европа (EU) 00101

Латинская Америка и Карибские острова (LAC) 00110

Северная Америка (NA) 00111

Резерв 01000 – 11111

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

    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) будет иметь вид:

<AS> = 10876 = 0x2A7C

<R> = 00010

<X> = 0

<CC> = код страны для островов Фиджи 242 = 0011110010

В этом случае младшие 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 community8, который имеет следующий формат:

    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-октетный номер автономной системы провайдера (присвоенный ему региональным регистратором или RIR9) в поле 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 Served10. Агентство IANA выделило для Sub-Type значение 0x0008, как определено в парашрафе 4.1.

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

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

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

[ISO3166] “ISO 3166 Maintenance agency (ISO 3166/MA)”, http://www.iso.org/iso/en/prods-services/iso3166ma/index.html, 2004.

[RFC1771] Rekhter, Y. and T. Li (Editors), “A Border Gateway Protocol (BGP-4)”, RFC 1771, March 1995.

[RFC1997] Chandra, R. and P. Traina, “BGP Communities Attribute”, RFC 1997, August 1996.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute”, RFC 4360, January 2006.

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

[HUSTON] Huston, G., “Interconnection, Peering, and Settlements”, http://www.isoc.org/inet99/proceedings/1e/1e_1.htm

[RFC2434] Narten, T., and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[RFC3258] Hardie, T., “Distributing Authoritative Name Servers via Shared Unicast Addresses”, RFC 3258, April 2002.

[RIS] “The RIPE Routing Information Service”, http://www.ripe.net/ris, 2004.

[RV] Meyer, D., “The Routeviews Project”, http://www.routeviews.org, 2002.

[VPLS] Kompella, K., et al., “Virtual Private LAN Service”, Work in Progress, April 2005.

[WANG] Wang, F. and L. Gao, “Inferring and Characterizing Internet Routing Policies”15, ACM SIGCOMM Internet Measurement Conference 2003.

Адрес автора

David Meyer

EMail: dmm@1-4-5.net


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

Николай Малых

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1BGP community.

2BGP route collector.

3Virtual Private Network – виртуальная частная сеть.

4Virtual Private LAN Service.

5Или «пирингом», от английского peering. Прим. перев.

6Interior Gateway Protocol – протокол внутренней маршрутизации.

7Маршрут ко всем.

8Двухоктетная расширенная группа уровня AS

9Regional Internet Registry

10Распределение в порядке поступления запросов.

11Данные этого реестра доступны по ссылке http://www.iana.org/assignments/bgp-data-collection-communities-std. Прим. перев.

12Global Routing Operations

13Этот документ заменен RFC 4271. Прим. перев.

15Эта статья доступна по ссылке http://rio.ecs.umass.edu/~gao/paper/imc_final.pdf.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.