Каждая автономная система имеет, как минимум, один маршрутизатор называемый «внешним» или «пограничным» (exterior или border), который соединяет ее с равнозначной другой автономной системой (в англоязычной литературе для определения равнозначности отношений используется термин peer-to-peer). Протокол ERP реализуется и функционирует на внешних маршрутизаторах, и с помощью него осуществляется распределение информации между автономными системами о существующих в них сетях. В отличие от протоколов класса IRP, протокол ERP не относится ни к типу DVP, ни LSP.

Невозможность использования принципов построения протоколов IRP, в первую очередь, объясняется отсутствием возможности определения единой метрики для всех маршрутов в рамках функционирования протоколов класса ERP, в связи с тем, что в разных автономных системах используются различные метрики. Поэтому протокол класса ERP лишь использует некоторые общие принципы функционирования DVP.

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

На сегодня стандартным протоколом рассматриваемого класса и, одновременно, наиболее широко используемым на реальных сетях, является протокол «пограничного шлюза четвертой версии» (Border Gateway Protocol version 4, далее - BGP4) [RFC 1771], основной особенностью которого является поддержка архитектуры межклассовой междоменной маршрутизации CIDR (Classless Inter-Domain Routing). Далее ознакомимся с BGP4 подробнее.

Это необходимо сделать, в первую очередь, для последующего понимания, каким образом в настоящее время осуществляется маршрутизация пакета «из-конца-в-конец» и что делается для того, чтобы поддержка качества обслуживания была доступна уже в обозримом будущем. Отметим, что поддержка качества обслуживания при использовании протокола ВОР может быть реализована следующим образом:

• путем внесения модификаций в сам протокол, как, например, предложено в [Li02];

• путем использования протоколом ВОР политики (BGP policy) классификации пакетов, как, например, предложено фирмой Cisco [CiscoBGP];

• путем использования незадействованных полей сообщений протокола ВОР для переноса информации о качестве обслуживания, как, например, предложено в [BonavOl].

BGP4 осуществляет выполнение трех основных функциональных процедур:

• Получение информации о соседнем внешнем маршрутизаторе (neighbor acquisition): выполняется, например, во время инсталляции сетевого оборудования. Два соседних внешних маршрутизатора, принадлежащих разным автономным системам, договариваются о поддержке «отношений», т.е. обмене маршрутной информацией. Формально эта процедура должна быть выполнена обязательно, т.к. один из маршрутизаторов теоретически может не желать поддержки «отношений» вследствие, например, своей перегруженности или отсутствия свободных ресурсов для поддержки трафика от другой автономной системы.

Таким образом, описываемая процедура заключается в посылке инициирующим «отношения» маршрутизатором сообщения Open соседнему внешнему маршрутизатору, который может, как поддержать запрос, отвечая сообщением Keepalive, так и отвергнуть его. Здесь необходимо заметить, что определение существования, а также адреса этого соседнего маршрутизатора не является функцией протокола BGP4. Как правило, эти вопросы решаются администратором сети во время конфигурирования оборудования.

• Определение доступности соседнего внешнего маршрутизатора (neighbor reachability): если первая процедура выполнена успешно, т.е. существуют «отношения» внешних маршрутизаторов, относящихся к разным автономным системам, они поддерживаются при помощи этой функциональной процедуры, заключающейся в регулярном обмене сообщениями Keepalive. Таким образом, каждый из двух рассматриваемых маршрутизаторов осведомлен о том, что его сосед находится в состоянии поддержки «отношений» с ним.

• Определение доступности сети (network reachability): каждый внешний маршрутизатор обладает таблицей - базой данных о доступных удаленных сетях и направлениях оптимального выхода на них. В случае изменения этой информации, маршрутизатор должен послать сообщение Update в широковещательном (broadcast) режиме всем маршрутизаторам, работающим по протоколу BGP4. При получении подобного сообщения маршрутизаторы обновляют свои маршрутные базы данных.

Сообщения протокола BGP4 Таблица 3.2

Примечание.

Под термином «соседний внешний маршрутизатор» будем подразумевать внешний маршрутизатор, принадлежащий другой автономной системе и имеющий непосредственное соединение с рассматриваемым внешним маршрутизатором.

На рис. 3.2 приведены форматы сообщений рассматриваемого протокола. Каждое сообщение начинается с заголовка длиной 19 октетов. Заголовок включает в себя следующие поля:

• маркер (Marker): поле зарезервировано для аутентификации. Отправитель может включить в это поле некоторое значение, при помощи которого приемник сможет идентифицировать отправителя, алгоритм генерирования маркера представлен в [ RFС1267];

• длина (Length): определяет длину сообщения в октетах;

• тип (Туре): задает тип сообщения: Open, Update, Keepalive, Notification.

С целью выполнения первой функциональной процедуры, один внешний маршрутизатор должен инициировать TCP-соединение к порту номер 179 другого маршрутизатора, с которым собирается установить «отношения». Далее посылается сообщение Open, которое идентифицирует автономную систему, к которой принадлежит маршрутизатор-отправитель сообщения, его IP-адрес а также версию используемого протокола. Сообщение также включает в себя поле Hold Time, в котором передается максимальное значение промежутка времени в секундах между поступлением сообщений Update или Keepalive.

В случае если приемник готов поддержать «отношения» с отправителем, он вычисляет параметр Hold Time путем определения минимального значения из двух возможных: поступившего от отправителя и собственного. «Отношения» двух внешних маршрутизаторов считаются установленными успешно, если эти маршрутизаторы обменялись сообщениями Open, и достигнуты соглашения по версии протокола, а также, значению поля Hold Time.

Существует достаточно много причин, по которым «отношения» не могут быть установлены, это, например, и различие версий реализации протокола, и неправильная аутентификация, и одновременная попытка установления «отношений» при помощи разных TCP-соединений. Отметим, что в случае, если версии протоколов не совпали, то в сообщении об ошибке Notification посылается причина, по которой произошла эта ошибка, и номер более ранней версии протокола, с которой может работать этот маршрутизатор. Это позволит повторить попытку установления «отношений» с большей вероятностью успеха.

Сообщение Keepalive состоит только из заголовка. Каждый внешний маршрутизатор посылает это сообщение своим соседям, с которьгми установлены «отношения», в целях их поддержания. Промежуток времени между посылкой сообщений не должен превышать значения Hold Time.

Сообщение update предназначено для переноса следующей информации:

• информации в рамках глобальной сети о конкретном маршруте (любой маршрутизатор-приемник может внести эту информацию в свою базу данных);

• списка удаляемых маршрутов, в список включаются только те маршруты, о которых маршрутизатор-отправитель уже распространял информацию ранее.

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

• поле «информация сетевого уровня о доступности» (Network Layer Reachability Information, далее - NLRI), содержащее список идентификаторов сетей (префикс IP-адреса), к которым существует доступ через этот конкретный маршрут;

• поле «суммарная длина атрибутов маршрута» (Total Path Attributes Length);

• поле «атрибуты маршрута» (Path Attributes, далее - РА), которое содержит список атрибутов конкретного маршрута.

Поле NLRI содержит список идентификаторов сетей (префикс IP-адреса), к которым существует доступ через этот маршрут. Поле РА содержит список атрибутов конкретного маршрута:

• origin: определяет, каким протоколом была сгенерирована данная информация, IRP (например, OSPF) или ERP (например, BGP4);

• as_path: список автономных систем, через которые проходит этот маршрут;

• next_hop: IP-адрес внешнего или внутреннего маршрутизатора, который должен быть использован в качестве следующего шага для выхода на направления, определенные в поле NLRI;

• multi_exit_ disc: используется для передачи информации о внутренних параметрах автономной системы (объясняется ниже на примере);

• local pref: используется для информирования внешним маршрутизатором остальных, принадлежащих той же самой автономной системе маршрутизаторов, о степени предпочтения конкретного маршрута (чем больше значение, тем выше степень предпочтения).

Значение вычисляется при получении внешним маршрутизатором от соседнего внешнего маршрутизатора, принадлежащего другой автономной системе, сообщения Update, в котором содержится информация о новом маршруте, об изменении параметров существующего маршрута или об удалении маршрута;

• atomic_aggregate, aggregator: эти поля позволяют реализовать концепцию агрегирования маршрутов и, следовательно, существенно снизить объем информации при работе с перекрывающимися префиксами, указанными в поле NLRI.

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

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

Для объяснения необходимости существования атрибута next_hop обратимся к рис. 3.3. На нем представлены маршрутизатор R1, относящийся к автономной системе AS 1 и маршрутизатор R5, относящийся к автономной системе AS2. Предположим, что указанные маршрутизаторы взаимодействуют по протоколу BGP4 и между ними установлены «отношения». Также предположим, что на R2 протокол BGP4 не реализован. Пусть R1 посылает сообщение Update маршрутизатору R5. Это сообщение содержит информацию о том, к каким сетям существует доступ через R1 и, соответственно, расстояния до них. Таким образом получается, что R1 еще предоставляет R5 и информацию от R2, т.е. информацию о том, к каким сетям существует доступ через R2.

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

• «ошибка заголовка сообщения» (message header error): ошибки аутентификации и синтаксиса;

• «ошибка сообщения Open» (Open message error): ошибки синтаксиса, также используется для индикации неприемлемости предложенного в сообщении Open значения параметра Hold Time;

• «ошибка сообщения Update» (Update message error): ошибки синтаксиса и правильности заполнения сообщения Update;

• «истечение значения параметра Hold Timer» (Hold Timer expired): если маршрутизатор не получает Update и/или Keepalive и/или Notification в ответ на свое сообщение в течение определенного Hold Timer промежутка времени, формируется сообщение об ошибке, и TCP-соединение разрушается;

• «ошибка автомата конечных состояний» (Finite state machine error): любые процедурные ошибки;

• «прекращение функционирования» (Cease): используется для инициализации закрытия соединения с другим маршрутизатором в случае отсутствия ошибок.

⇐Классификация существующих протоколов класса irp - общие сведения | Управление трафиком и качество обслужевания в сети | Пример функционирования протокола класса erp⇒