Таким образом, кроме маршрутов, поступающих от непосредственно подсоединенных к РЕ сайтов, каждая таблица VRF дополняется маршрутами, получаемыми от других сайтов данной VPN по прото-] колу MP-BGP. Целенаправленное распространение маршрутов между маршрутизаторами РЕ обеспечивается надлежащим выбором атрибутов протокола MP-BGP.

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

Ограничение области распространения маршрутной информации пределами отдельных VPN изолирует адресные пространства каждой VPN, позволяя применять в ее пределах как адреса Internet общего пользования, так и частные (private) адреса, зарезервированные в соответствии с RFC 1819.

Почему же в таком случае не сделать выбор адресов в пределах VPN совершенно произвольным и офаниченным только общими пра- вилами адресации стека TCP/IP? Дело в том, что во многих случаях клиенты не хотят полной изоляции VPN: в частности, они нуждаются в{ выходе в Интернет. Независимое же, не согласованное с регламенти-; рующими органами Интернет, назначение адресов узлам VPN может привести к совпадению внутренних адресов сайтов с уже выделенными адресами общего пользования, в результате чего связь с Интернет общего пользования станет невозможной. При использовании зарезервированных частных адресов проблема связи клиентов VPN cj внешним миром решается с помощью стандартной техники трансляции адресов (Network Address Translator, NAT), описанной в RFC 3022. В любом случае должно соблюдаться требование уникальности адресов в пределах VPN.

Использование в разных VPN одного и того же адресного пространства создает проблему для маршрутизаторов РЕ. Протокол BGP изначально был разработан в предположении, что все адреса, которыми он манипулирует, во-первых, относятся к семейству адресов IPv4 и, во-вторых, однозначно идентифицируют узлы сети, т.е. являются глобально уникальными в пределах всей составной сети. Ориентация на глобальную уникальность адресов выражается в том, что, получив очередное маршрутное объявление, протокол BGP анализирует его, не обращая внимания на то, какой VPN принадлежит этот маршрут. Если на вход BGP поступают описания маршрутов к узлам разных VPN, но с совпадающими адресами IPv4, то BGP считает, что все они ведут к одному и тому же узлу, а, следовательно, как и полагается в таком случае, он помещает в соответствующую таблицу VRF только один кратчайший маршрут.

Проблема решается за счет применения вместо потенциально неоднозначных адресов IPv4 расширенных и однозначных адресов нового типа, а именно, адресов VPN-IPv4, получаемых в результате преобразования исходных адресов IPv4. Преобразование заключается в том, что ко всем адресам IPv4, составляющим адресное пространство той или иной VPN, добавляется префикс, называемый раз-личителем маршрутов (Route Distinguisher, RD), который уникально идентифицирует эту VPN. В результате на маршрутизаторе РЕ все адреса, относящиеся к разным VPN, обязательно будут отличаться друг от друга, даже если они имеют совпадающую часть - адрес IPv4.

Именно здесь оказалась полезной способность расширенного протокола MP-BGP переносить в маршрутных объявлениях адреса разных типов, в том числе IPv6, IPX, а, главное, VPN-IPv4. Адреса VPN-Pv4 используются только для маршрутов, которыми маршрутизаторы РЕ обмениваются по протоколу BGP. Преяоде чем передать своему напарнику некоторый маршрут, входной маршрутизатор РЕ добавляет к его адресу назначения IPv4 префикс RD для данной VPN, тем самым преобразуя его в маршрут VPN-IPv4.

Как уже было сказано, различители маршрута должны гарантированно уникально идентифицировать VPN, чтобы избежать дублирования адресов. Упростить выбор RD, не создавая для этих целей дополнительных централизованных процедур (например, распределения RD органами Интернет подобно распределению адресов IPv4), предлагается за счет использования в качестве основы для RD заведомо уникальных чисел - либо номеров автономных систем, либо глобальных адресов интерфейсов РЕ с магистральной сетью провайдера (в сети провайдера всегда необходимы глобальные адреса для взаимодействия с сетями других провайдеров).

Различитель маршрутов RD имеет длину 8 байтов и состоит из трех полей. Первое поле Туре длиной 2 байта определяет тип и разрядность второго поля, которое называется Administrator и однозначно идентифицирует провайдера. Значение О поля Туре говорит о том, что в поле Administrator указывается IP-адрес интерфейса маршрутизатора РЕ, и длина данного поля составляет, естественно, 4 байта. Если же значение Туре равно 1, то в качестве идентификатора провайдера выбрано значение номера его автономной системы, так что длина поля Administrator составит уже 2 байта. Третье поле носит название Assigned Number, его назначение - обеспечить уникальность адресов VPN в пределах сети провайдера. Значения поля Assigned Number выбирает сам провайдер, при этом использование в качестве поля Administrator IP-адресов интерфейса РЕ более удобно, так как Офаничивает требование уникальности значений Assigned Number пределами отдельного РЕ.

Документ RFC 2547bis не требует, чтобы все маршруты внутри одной VPN индексировались одним и тем же значением RD. Более того, один и тот же сайт, подключенный к разным интерфейсам одного РЕ или к разным РЕ, может иметь различающиеся RD. Благодаря этому путь к одному и тому же узлу может описываться разными маршрутами, что дает возможность выбора того или иного маршрута для различных пакетов. Однако принципиально важно, чтобы RD разных VPN не совпадали.

Пересылка пакета по сети MPLS VPN. Пусть, например, из сайта 1 в VPN А узел с адресом 10.2.1.1/16 (16 - класс эквивалентности при доставке FEC) отправляет пакет узлу сайта 2 этой же VPN, имеющему адрес 10.1.0.3/16 (рис. 4.9). Стандартными транспортными средствами IP-пакет доставляется на пограничный маршрутизатор сайта СЕ1А, в таблице которого для номера сети 10.1.0.0 в качестве следующего маршрутизатора указан РЕ1. На маршрутизатор РЕ1 пакет поступает с интерфейса int2, поэтбму для выбора дальнейшего продвижения пакета он обращается к таблице VRF 1А, связанной с данным интерфейсом.

В таблице VRF 1А адресу 10.1.0.0 соответствует запись протокола BGP, которая указывает, 4to очередным маршрутизатором для пакета определен РЕ2. Следующее поле записи содержит значение метки

Узел 10.2.1.1 отправляет пакет по адресу 10.1.0.3 Глобальная таблица РЕ1

VRF 1А

Сайт1VPNA

CaTlVPNB

Сайт 2yPNB

РШ4Л.Щтшесгв1ле пакета между caйтжшMPN №?;9дд

Lvpn = 7, определяющей интерфейс выходного маршрутизатора РЕ, которое должно быть присвоено пакету для того, чтобы он попал в нужную VPN. Здесь также указывается, что запись была сделана протоколом BGP, а не 1GP. На этом основании маршрутизатор РЕ понимает , что очередной маршрутизатор не является непосредственным соседом, и путь к нему надо искать в глобальной таблице маршрутизации.

В глобальной таблице для адреса РЕ2 указывается начальное значение метки L пути LSP, равное 3. Способ его прокладки между маршрутизаторами РЕ1 и РЕ2 не имеет в данном случае принципиального значения - главное, чтобы такой путь существовал.

Технология MPLS VPN использует иерархические свойства путей MPLS, за счет чего пакет может быть снабжен несколькими метками, помещаемыми в стек. На входе во внутреннюю сеть провайдера, образуемую маршрутизаторами Р (LSR), пакет будет снабжен двумя метками - внутренней Lvpn = 7 и внешней L = 3. Метка Lvpn интерпретируется как метка нижнего уровня - оставаясь на дне стека, она не используется, пока пакет путешествует по туннелю РЕ1-РЕ2. Продвижение пакета происходит на основании метки верхнего уровня, роль которой отводится метке L. Каждый раз, когда пакет проходит очередной маршрутизатор Р вдоль туннеля, метка L анализируется и заменяется новым значением. И только после достижения конечной точки туннеля маршрутизатора РЕ2 из стека извлекается метка Lvpn. В зависимости от ее значения пакет направляется на тот или иной выходной интерфейс маршрутизатора РЕ2.

Из таблицы VRF 2А, связанной с данным интерфейсом и содержащей маршруты VPNA, извлекается запись о маршруте к узлу назначения, указывающая на СЕ2 в качестве следующего маршрутизатора. Заметим, что она была помещена в таблицу VRF 2А протоколом 1GP. Последний отрезок путешествия пакета от СЕ2 до узла 10.1.0.3 осуществляется традиционными средствами IP.

Несмотря на достаточно громоздкое описание механизмов MPLS VPN, процесс конфигурирования новой VPN или модификации существующей достаточно прост, поэтому он хорошо формализуется и автоматизируется. Для исключения возможных ошибок конфигурирования - например, приписывания сайту ошибочной политики импорта/экспорта маршрутных объявлений, что может привести к присоединению сайта к чужой VPN, - некоторые производители разработали автоматизированные программные системы конфигурирования MPLS. Примером может служить Cisco VPN Solution Center, который снабжает администратора средствами графического интерфейса для формирования состава каждой VPN, а затем переносит полученные конфигурационные данные в маршрутизаторы РЕ.

Повысить степень защищенности MPLS VPN можно с помощью традиционных средств: например, применяя средства аутентифика-

ции и шифрования IPSec, устанавливаемые в сетях клиентов или в сети провайдера. Услуга MPLS VPN может легко интефироваться с другими услугами IP, например, с предоставлением доступа к Интернет для пользователей VPN с защитой их сети средствами межсетевого экрана, установленного в сети провайдера. Провайдер также может предоставлять пользователям MPLS VPN услуги, базирующиеся на других возможностях MPLS: в частности, услуги с предоставлением гарантированного качества обслуживания на основе методов MPLS ТЕ. Что же касается сложностей ведения в маршрутизаторах провайдера таблиц маршрутизации пользователей, на которые указывают некоторые аналитики, то они несколько преувеличены, так как таблицы создаются автоматически, с помощью стандартных протоколов маршрутизации, и только на пограничных маршрутизаторах РЕ. Механизм виртуального маршрутизатора полностью изолирует эти таблицы от глобальных таблиц маршрутизации провайдера, что обеспечивает необходимые уровни надежности и масштабируемости решений MPLS VPN [5].

4.5. Обобщенная многопротокольная коммутация ПО меткам (GMPLS)

Технология обобщенной (универсальной) многопротокольной коммутации по меткам (Generalized Multi-Protocol Label Switching, GMPLS) была разработана технической комиссией Интернет (Internet Engineering Task Force, IETF) [6-8]. В проекте стандарта GMPLS говорится: Сети будущего будут состоять из таких систем, как маршрутизаторы, DWDM системы, Add-Drop мультиплексоры (ADMs), фотонные (PXCs) или оптические коммутаторы (OXCs), которые будут использовать GMPLS .

В GMPLS используются концепции и протоколы, разработанные применительно к MPLS. В GMPLS принцип коммутации по меткам расширен применительно к оптическим сетям. Здесь, в отличие от MPLS, вместе с меткой необходимо передавать информацию о ее типе, поскольку в качестве меток могут быть выбраны различные компоненты -длина волны X, номер оптического волокна в канале, номер SDH-контейнера и т.д. В настоящий момент предложены следующие базовые типы меток:

- Packet - метка, идентифицирующая Ethernet (GE, FE);

-f PDH - метка, идентифицирующая кадры ETSI/ANSI РОН fTI, Е1, ЕЗ); -< SONET/SDH - метка, идентифицирующая контейнеры SONET/SDH -I (VT, VC, STS-n, STM-n);

- Digital Wrapper - метка OTN G.709 (2,5,10, 40 Гбит/с);

Я, - длина волны при использовании фотонных Л-коммутаторов ОХС;

К Fiber - метка, идентифицирующая номер оптического волокна; ф Fiber Channel - метка, идентифицирующая оптический канал.

Перечисленные выше типы меток описывают тип устанавливаемого соединения LSP, а не транспортной технологии, через которую данный LSP устанавливается. Например, использование метки Я. означает, что устанавливаемое соединение LSP следует обеспечивать прозрачно без оптико-электрических преобразований. Тип метки Ethernet означает, что следует также обеспечить синхронизацию и, возможно, согласование скоростей на транзитных коммутаторах.

В свою очередь, при запросе, например метки SONET/SDH, необходимо указывать тип и количество контейнеров.

GMPLS эволюционировала от MPLS (через MPAS) путем расширения существующей парадигмы коммутации по меткам, от технологий коммутации пакетов/ячеек/фреймов к технологиям, ориентированным на установление соединения. Хотя принцип коммутации по меткам был изначально внедрен для повышения скорости маршрутизации в IP-сетях (посредством исключения трудоемкого сравнения полных префиксов), акцент сместился в сторону увеличения стабильности, улучшению QoS и более гибким и эффективным механизмам управления (возможных благодаря улучшенному планированию трафика).

GMPLS охватывает всю сферу коммутационных возможностей: от коммутации пакетов до коммутации оптических волокон. GMPLS не только использует концепцию MPLS (например, планирование трафика MPLS и восстановление), но и базируется на тех же протоколах маршрутизации (например, OSPF-TE) и сигнализации (RSPV-TE).

Фундаментальная концепция GMPLS (интегрированная плоскость управления, (многоуровневое) восстановление, и распределенное управление) могут быть применены для устранения недостатков существующих технологий для многоуровневых сетей. Повышенная гибкость сети, обеспечиваемая GMPLS, может повысить доходы операторов, так как они могут предложить и твердо придерживаться более строгих (и более прибыльных) соглашений об уровне обслуживания (SLA). А благодаря оптимизированному распределению ресурсов восстановления и эффективным (многоуровневым) механизмам восстановления, можно снизить капитальные затраты (САРЕХ). К тому же, автоматическое восстановление - с исключением необходимости в дорогостоящих и вносящих ошибки ручных вмешательствах - может снизить эксплуатационные расходы (ОРЕХ).

Улучшенные возможности QoS позволяют эффективно передавать через единую сеть сообщения с различными классами обслуживания (Class of Service, CoS), такие, как голос, видео, и данные с их специфическими требованиями в плане задержки, джиттера и доступности. Гибкое и эффективное сетевое управление, предоставленное унифицированной плоскостью управления GMPLS, позволяет быстрее и проще