О документе
Network Working Group D. Meyer
Request for Comments: 4384 February 2006
BCP: 114
Category: Best Current Practice
BGP Communities for Data Collection
1. Введение
Сообщества BGP [RFC1997] используются поставщиками услуг для многих
целей, включая маркировку клиентских маршрутов, маршрутов пиров и
маршрутов географического происхождения. Такая маркировка обычно
используется для управления областью перераспространения маршрутов в
сети поставщика, а также его клиентам и пирам. Сообщества также
используются для широкого спектра других применений, например для
предоставления клиентам возможности устанавливать такие атрибуты, как
LOCAL_PREF [RFC1771], путём отправки соответствующих сообществ своему
поставщику услуг. Другие применения включают сигнализацию различных
типов виртуальных частных сетей (VPN) (например, Virtual Private LAN
Service (VPLS) [VPLS]) и перенос пропускной способности канала для
приложений организации трафика [RFC4360].
С появлением крупномасштабного сбора данных BGP [RV] [RIS] (и
связанных с ним исследований) стало ясно, что географическая и
топологическая информация, а также характер отношений поставщика с
источником маршрута (например, транзит, пиринг или клиент),
переносимые такими сообществами, существенны для более глубокого
понимания глобальной системы маршрутизации. Этот меморандум
определяет стандартные сообщества для экспорта в сборщики маршрутов
BGP. Эти сообщества представляют значительную часть информации,
переносимой поставщиками услуг на момент
написания данного документа, и поэтому могут быть полезны для
внутреннего использования поставщиками услуг. Однако такое
использование находится за пределами области действия этого
меморандума. Наконец, лицам, участвующим в анализе данных BGP,
рекомендуется уточнить у своих источников данных, какие пиры реализуют
эту схему (поскольку существует большой объём уже имеющихся данных, а
также множество устаревших пирингов).
Остальная часть этого меморандума организована следующим образом.
В разделе 2 приводятся определения используемых терминов, а также
семантика сообществ, используемых для сбора данных BGP; раздел 3
определяет соответствующие кодировки для сообществ RFC 1997
[RFC1997]. Наконец, раздел 4 определяет кодировки для использования
с расширенными сообществами [RFC4360].
2. Определения
В этом разделе мы определяем используемые термины и категории
маршрутов, которые могут маркироваться сообществами. Эту маркировку
часто называют окрашиванием, а «цветом» маршрута мы называем значение
его сообщества. Определённые здесь категории приблизительно
моделируются на основе категорий, описанных в [WANG] и [HUSTON].
2.1. Пиры и пиринг
Рассмотрим двух поставщиков сетевых услуг, A и B. Поставщики услуг A
и B определяются как пиры, когда (i) A и B обмениваются маршрутами
через BGP и (ii) обмен трафиком между A и B осуществляется без
взаиморасчётов. Такая договорённость также обычно известна как
«пиринг». Пиры обычно обмениваются только маршрутами соответствующих
клиентов (см. «Маршруты клиентов» ниже), а следовательно, обмениваются
только соответствующим клиентским трафиком. Более подробное
обсуждение бизнес-моделей, связанных с пирами и пирингом, см. в
[HUSTON].
2.2. Маршруты клиентов
Маршруты клиентов — это маршруты, полученные от клиента через BGP и
распространяемые пирам и другим клиентам. Обратите внимание, что
клиентом может быть предприятие или другой поставщик сетевых услуг.
Эти маршруты иногда называют маршрутами клиентов [HUSTON].
2.3. Маршруты пиров
Маршруты пиров — это маршруты, полученные от пиров через BGP и не
распространяемые другим пирам. В частности, эти маршруты
распространяются только клиентам поставщика услуг.
2.4. Внутренние маршруты
Внутренние маршруты — это маршруты, которые поставщик услуг создаёт и
передаёт своим пирам и клиентам. Эти маршруты часто выделяются из
адресного пространства, назначенного поставщику.
2.5. Внутренние более специфичные маршруты
Внутренние более специфичные маршруты — это маршруты, которые часто
используются для балансировки нагрузки каналов и сокращения маршрутов
Interior Gateway Protocol (IGP). Они также могут соответствовать
услугам клиентов, которые не видны за пределами сети поставщика услуг.
Внутренние более специфичные маршруты не экспортируются ни одному
внешнему пиру.
2.6. Маршруты специального назначения
Маршруты специального назначения — это маршруты, не относящиеся ни к
одному из других описанных здесь классов. В случаях, когда такие
маршруты необходимо различать, поставщик услуг может маркировать
такие маршруты уникальным значением. Примеры маршрутов специального
назначения включают маршруты anycast и маршруты для оверлейных сетей.
2.7. Восходящие маршруты
Восходящие маршруты обычно получаются от вышестоящего поставщика услуг
как часть договора на транзитные услуги, заключённого с вышестоящим
поставщиком.
2.8. Национальные маршруты
Это наборы маршрутов, источником которых является и/или которые
получены в пределах конкретной страны.
2.9. Региональные маршруты
Несколько глобальных магистральных сетей реализуют региональную
политику на основе своей развёрнутой инфраструктуры, а также
стратегических и коммерческих императивов. Поставщики услуг часто
имеют межсоединения без взаиморасчётов с автономной системой (AS) в
одном регионе, тогда как эта же AS является клиентом в другом регионе.
Это требует использования региональной маршрутизации, включая
атрибуты сообществ, устанавливаемые рассматриваемой сетью для лёгкого
различения региональных маршрутов. Например, поставщики услуг могут
обрабатывать набор маршрутов, полученный от другого поставщика услуг
в Европе, иначе, чем тот же набор маршрутов, полученный в Северной
Америке, поскольку обычной практикой является продажа транзита в одном
регионе при пиринге в другом.
3. Кодировка и значения сообществ RFC 1997
В этом разделе мы приводим значения сообществ RFC 1997 [RFC1997] для
описанных выше категорий. Сообщества RFC 1997 кодируются как код типа
BGP 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-битный номер AS. Например, кодировка
0x2A7C029A представляет AS 10876 со значением 666.
4. Значения сообществ для сбора данных BGP
В этом разделе мы определяем кодировку сообществ RFC 1997 для
описанных выше типов маршрутов для использования при сборе данных
BGP. Предполагается, что внутренние значения сообществ поставщика
услуг будут преобразованы в эти стандартные значения для вывода в
сборщик маршрутов.
Этот меморандум следует лучшей современной практике использования
базового формата <AS>:<Value>. Значения для категорий маршрутов
описаны в следующей таблице:
Категория Значение
===============================================================
Зарезервировано <AS>:0000000000000000
Маршруты клиентов <AS>:0000000000000001
Маршруты пиров <AS>:0000000000000010
Внутренние маршруты <AS>:0000000000000011
Внутренние более специфичные маршруты <AS>:0000000000000100
Маршруты специального назначения <AS>:0000000000000101
Восходящие маршруты <AS>:0000000000000110
Зарезервировано <AS>:0000000000000111-
<AS>:0000011111111111
Национальные и региональные маршруты <AS>:0000100000000000-
<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 с островов Фиджи будет следующей:
<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 (0x10F2 == 4338 в десятичной системе).
Наконец, обратите внимание, что эти категории не предназначены быть
взаимоисключающими, и при необходимости может быть присоединено
несколько сообществ.
4.1. Расширенные сообщества
В некоторых случаях значения и их кодирование, описанные в разделе 4,
могут конфликтовать с существующими назначениями сообществ поставщика
услуг. Расширенные сообщества [RFC4360] предоставляют удобный механизм,
который можно использовать для предотвращения таких конфликтов.
Атрибут Extended Communities является транзитивным необязательным
атрибутом BGP с кодом типа 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,
используя тип расширенного сообщества, специфичный для двухоктетной 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | Sub-Type | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Атрибут расширенного сообщества, специфичного для двухоктетной AS,
кодирует в поле Global Administrator двухоктетный номер автономной
системы поставщика услуг (назначенный региональным интернет-регистратором,
или RIR), а поле Local Administrator может кодировать любую информацию.
Этот документ назначает подтип 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. Расширенные сообщества, специфичные для четырёхоктетной AS
Расширенное сообщество, специфичное для четырёхоктетной 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В этом случае подполе Global Administrator длиной четыре октета содержит
четырёхоктетный номер автономной системы, назначенный IANA.
5. Примечание об упаковке BGP UPDATE
Следует отметить, что сообщества сбора данных потенциально могут сделать
набор атрибутов конкретного маршрута более уникальным, чем он был бы в
противном случае (поскольку каждый маршрут собирает данные, специфичные
для его пути внутри одной или нескольких AS). Это, в свою очередь, может
влиять на то, могут ли несколько маршрутов быть сгруппированы в одном
сообщении обновления BGP, и может привести к увеличению использования
пропускной способности, процессорных циклов маршрутизатора и памяти.
6. Благодарности
Кодирование сообществ, описанное в этом документе, возникло благодаря
интересному предложению Акиры Като из WIDE. В частности, идея состояла в
использовании значений сообществ сбора данных для выбора путей, которые
приводили бы к (предположительно) более эффективному доступу к различным
службам. Например, в случае службы DNS anycast на основе RFC 3258
[RFC3258] маршрутизаторы BGP могут видеть несколько путей к одному и тому
же префиксу, причём некоторые могут происходить из одного источника с
разными путями, а другие — из другого региона/страны (с той же исходной
AS).
Джо Эйбли, Рэнди Буш, Шон Донелан, Ксенофонтас Димитропулос, Виджай Гилл,
Джон Хисли, Джефф Хьюстон, Стив Хьютер, Майкл Паттон, Оливье Марсе, Райан
Макдауэлл, Роб Рокелл, Роб Томас, Пекка Савола, Патрик Веркайк и Алекс
Зинин сделали много содержательных замечаний к ранним версиям этого
документа. Хенк Эйтерваал предложил использовать коды стран ISO-3166-2.
7. Соображения безопасности
Хотя этот документ не вводит в протокол BGP дополнительных соображений
безопасности, информация, содержащаяся в определённых в этом документе
сообществах, в некоторых случаях может раскрывать структуру сети, которая
ранее не была видна за пределами сети поставщика. Вследствие этого при
экспорте таких сообществ коллекторам маршрутов следует проявлять
осторожность. Наконец, маршруты, экспортируемые коллектору маршрутов,
также следует помечать сообществом NO_EXPORT (0xFFFFFF01).
7.1. Общая длина атрибута пути
Сообщества, описанные в этом документе, предназначены для использования
при исходящем направлении к коллектору маршрутов. Поэтому оператор может
выбрать замену своих внутренних сообществ значениями, указанными в этом
документе, при экспорте маршрутов коллектору маршрутов. Однако операторам,
как правило, следует обеспечивать, чтобы поведение их реализации BGP было
чётко определено, когда добавление атрибута приводит к превышению PDU 4096
октетов. Например, поскольку обычной практикой является использование
атрибутов сообществ для реализации политики (среди прочей функциональности,
такой как предоставление клиентам возможности устанавливать атрибуты,
например LOCAL_PREF), поведение реализации при переполнении пространства
атрибутов имеет решающее значение. Помимо прочего, реализация может
неправомерно завладеть предназначенными данными атрибута либо иным образом
вызвать неопределённые сбои. Такое поведение может приводить к
непредвиденным наборам атрибутов сообществ и, следовательно, к
непреднамеренным последствиям для политики.
8. Соображения IANA
Этот документ назначает новый подтип для типа расширенного сообщества,
специфичного для AS, в категории расширенных транзитивных сообществ First
Come First Served. IANA назначила подтип 0x0008, определённый в разделе
4.1.
Кроме того, IANA создала два реестра сообществ сбора данных BGP: один для
стандартных сообществ и один для расширенных сообществ. Оба этих реестра
первоначально будут заполнены значениями, описанными в разделе 4. Для
назначения новых значений в этих реестрах требуется консенсус IETF, как
описано в [RFC2434], обычно через рабочую группу Global Routing Operations
(grow) (в частности, для <Value> или <R> в таблице значений для категорий
маршрутов в разделе 4).
9.1. Нормативные ссылки
[ISO3166] "ISO 3166 Maintenance agency (ISO 3166/MA)", Web
Page: 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", Web Page:
http://www.ripe.net/ris, 2004.
[RV] Meyer, D., "The Routeviews Project", Web Page:
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", ACM SIGCOMM Internet
Measurement Conference 2003.