RFC 1965 Autonomous System Confederations for BGP

Network Working Group                                      P. Traina
Request for Comments: 1965                             cisco Systems
Category: Experimental                                     June 1996

Конфедерации автономных систем в BGP

Autonomous System Confederations for BGP¹

PDF

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

В этом документе определяется экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ не задает каких-либо стандартов. Принимаются предложения и комментарии. Документ может распространяться свободно.

Аннотация

Протокол BGP² [1] представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP.

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

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

Описанное здесь расширение широко используется в сети Internet.

Введение

Может оказаться полезным деление автономных систем с большим числом узлов BGP на более мелкие домены в целях управления политикой маршрутизации с помощью данных, содержащихся в атрибуте BGP AS_PATH. Например, можно рассматривать все узлы BGP в неком географическом регионе как единый объект.

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

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

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

И, наконец, деление больших AS может привести к неоправданному увеличению размера упорядоченной части атрибута AS_PATH. Некоторые распространенные реализации BGP могут использовать число «интервалов между AS» до данного адресата, как часть критерия выбора пути. Хотя такой метод определения предпочтительного маршрута не является оптимальным, при нехватке других данных он обеспечивает разумное поведение «по умолчанию», широко используемое в сети Internet. Следовательно, деление автономной системы на отдельные фрагменты может оказать существенное влияние на уровень оптимальности маршрутизации пакетов через Internet.

Однако обычно не возникает необходимости в раскрытии внутренней топологии таких поделенных на части автономных систем и это означает, что возможно представление множества автономных систем с единым администрированием как единого объекта или AS с точки зрения находящихся за пределами данной конфедерации автономных систем.

Термины и определения

AS Confederation

Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию.

AS Confederation Identifier

Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

Member-AS

Автономная система, включенная в данную конфедерацию AS.

Обзор

IDRP [2] представляет собой концепцию создания конфедераций в системах междоменной маршрутизации. Конфедерация маршрутных доменов IDRP представляется узлам IDRP, не входящим в эту конфедерацию, как единый административный объект. Описываемое здесь расширение основано на этой работе.

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

Расширение AS_CONFED для типа сегмента

В действующей спецификации BGP сказано, что атрибут AS_PATH является хорошо известным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <type/length/value>.

В соответствии с [1] тип сегмента пути задается однооктетным полем, для которого определены следующие значения:

Значение	Имя	Описание
1	AS_SET	Неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.
2	AS_SEQUENCE	Упорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

В настоящем документе определены два дополнительных типа сегментов пути:

Значение	Имя	Описание
3	AS_CONFED_SET	Неупорядоченный набор номеров Member AS в локальной конфедерации, через которую передается сообщение UPDATE.
4	AS_CONFED_SEQUENCE	Упорядоченный набор номеров Member AS в локальной конфедерации, через которую передается сообщение UPDATE.

Принцип работы

Член конфедерации BGP будет использовать свой идентификатор конфедерации во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Идентификатор конфедерации рассматривается как видимый извне номер AS, этот номер используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH.

Член конфедерации BGP будет использовать свой идентификатор домена маршрутизации (routing domain identifier³) во всех транзакциях с партнерами, входящими в данную конфедерацию.

Узлу BGP, получившему атрибут AS_PATH с идентификатором конфедерации, соответствующим его конфедерации, следует трактовать путь так же, как это делается для путей, содержащих номер AS этого узла.

Правила изменения AS_PATH

Параграф 5.1.2 документа [1] заменяется приведенным ниже текстом:

Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, ему следует изменить атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

a) Когда данный узел BGP анонсирует маршрут другому узлу BGP, расположенному в той же автономной системе, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.

b) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, анонсирующему узлу следует изменить связанный с этим маршрутом атрибут AS_PATH как показано ниже:

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, локальной системе следует поместить свой номер AS как последний элемент списка (в крайнюю левую позицию).

2) если первый сегмент AS_PATH имеет тип, отличный от AS_CONFED_SEQUENCE, локальной системе следует поместить новый сегмент типа AS_CONFED_SEQUENCE в путь AS_PATH, включив свой идентификатор конфедерации в этот сегмент.

c) Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе и не являющемуся членом конфедерации (в которую входит данный узел), анонсирующему узлу следует изменить атрибут AS_PATH как показано ниже:

1) если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, данный сегмент и все непосредственно следующие за ним сегменты типа AS_CONFED_SET или AS_CONFED_SEQUENCE удаляются из атрибута AS_PATH и после этого для атрибута выполняется этап 2 или 3 (см. ниже).

2) если первый оставшийся сегмент AS_PATH имеет тип AS_SEQUENCE, локальной системе следует поместить свой идентификатор конфедерации в качестве последнего элемента (поместить идентификатор в крайнюю левую позицию).

3) если после удаления сегментов AS_CONFED_SET/AS_CONFED_SEQUENCE не остается других сегментов пути или первый сегмент оставшейся части AS_PATH имеет тип AS_SET, локальной системе следует включить (prepend) в атрибут AS_PATH новый сегмент типа AS_SEQUENCE, указав в нем свой идентификатор конфедерации.

Когда узел BGP является источником маршрута, этому узлу следует:

a) включать пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в Member AS Number (пустой атрибут AS_PATH содержит нулевое значение в поле размера);

b) включать свой Member AS Number в сегмент AS_CONFED_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, являющихся членами конфедерации (т. е., значение Member AS Number исходного отправителя будет единственным элементом атрибута AS_PATH);

c) включать номер AS своей конфедерации в сегмент AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, которые не являются членами данной конфедерации; в этом случае номер AS конфедерации будет единственным элементом атрибута AS_PATH.

Общие вопросы администрирования

Вполне разумно в рамках конфедерации использовать единое администрирование и информацию IGP.

Узлам BGP следует разрешить анонсирование неизмененных атрибутов NEXT_HOP и MULTI_EXIT_DISCRIMINATOR (MED)партнерам из соседних AS, входящих в ту же конфедерацию. В дополнение к этому отменяется ограничение на передачу атрибута LOCAL_PREFERENCE партнерам из соседних AS своей конфедерации. Критерии выбора пути для информации, полученной от членов конфедерации могут быть такими же, как для партнеров из своей автономной системы.

Совместимость

Все включенные в конфедерацию узлы BGP должны распознавать расширения типа сегмента AS_CONFED_SET и AS_CONFED_SEQUENCE в атрибутах AS_PATH.

Любой узел BGP, не поддерживающий эти расширения, будет генерировать сообщение NOTIFICATION с кодом ошибки UPDATE Message Error и субкодом Malformed AS_PATH.

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

Проблемы совместимости

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

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

Литература

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

[2] Kunzinger, C. Editor, “Inter-Domain Routing Protocol”, ISO/IEC 10747, October 1993.

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

В этом документе не рассматриваются вопросы безопасности.

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

Автор благодарит Ravi Chandra и Yakov Rekhter за просмотр документа и конструктивные, полезные замечания.

Адрес автора

Paul Traina

cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: pst@cisco.com

---

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

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

nmalykh@protokols.ru