1. Введение
1.1. Частные виртуальные сети

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

Субнаборы, которые создаются, являются "Частными виртуальными сетями" (VPN). Два сайта имеют IP коннективность через опорную сеть, только если существует VPN, которая содержит в себе оба эти сайта. Два сайта, которые не имеют общих VPN, не имеют связи через опорную сеть.

Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной "интранет". Если разные сайты в VPN принадлежат различным компаниям, VPN считается "экстранетом". Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты, как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами.

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

Механизмы, обсуждаемые в данном документе, допускают реализацию широкого диапазона политик. Например, в пределах данной VPN, каждому сайту позволяется иметь прямой маршрут до любого другого сайта ("полная сетка"), или можно выделить определенные пары сайтов, которые будут связаны друг с другом ("частичная сетка").

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

1.2. Оконечные устройства

Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge).

Если конкретный сайт имеет одну ЭВМ, эта машина может быть оконечным устройством CE. Если конкретный сайт имеет одну субсеть, оконечным устройством CE может стать сетевой переключатель. Вообще, устройством CE может быть маршрутизатор, который называется в этом случае CE-маршрутизатором.

Будем говорить, что PE-маршрутизатор подключен к определенной VPN, если он подключен к оконечному устройству CE, которое находится в VPN. Аналогично, будем считать, что маршрутизатор PE подключен к определенному сайту, если он подсоединен к устройству CE, которое находится в пределах этого сайта. Когда в качестве CE выступает маршрутизатор, он является маршрутным партнером PE, к которому подключен, но не является маршрутным партнером CE-маршрутизаторов в других сайтах. Маршрутизаторы в различных сайтах непосредственно не обмениваются маршрутной информацией. В действительности, они даже могут не знать о существовании друг друга (за исключением случая, когда это необходимо из соображений безопасности, смотри раздел 9). Как следствие, очень большие VPN (т.e., VPN с большим числом сайтов) хорошо поддерживаются, в то же время маршрутные стратегии каждого индивидуального сайта существенно упрощаются.

Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, а клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP).

1.3. VPN с перекрывающимися адресными пространствами

Предположим, что любые две не пересекающиеся VPN (т.e., VPN, не имеющих общих сайтов) могут иметь перекрывающиеся адресные пространства. Один и тот же адрес может использоваться повторно для разных систем в различных VPN. Поскольку оконечное устройство имеет уникальный адрес в области VPN, которой оно принадлежит, оконечное устройство не нуждается в какой-либо дополнительной информации о VPN.

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

1.4. VPN с разными маршрутами до одной и той же системы

Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе в сайте будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C, а также экстранет, включающий в себя A, B, C и “чужой" сайт D. Будем считать, что сайт A является сервером, и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так что может контролироваться доступ трафика из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет.

Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, он затем рассматривается как трафик, приходящий из сайта B, и следует маршрутом до узла A.

1.5. Таблицы переадресации в PE

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

1.6. Маршрутизаторы опорной сети SP

Опорная сеть SP состоит из PE-маршрутизаторов, а также их других маршрутизаторов (P-маршрутизаторы), которые не подключены к CE устройствам.

Если каждый маршрутизатор в опорной сети SP должен поддерживать маршрутную информацию для всех VPN, поддерживаемых SP, такая модель будет иметь серьезные проблемы с масштабируемостью. Число поддерживаемых сайтов, будет лимитировано объемом маршрутной информации, хранимой одним маршрутизатором. Важно, следовательно, потребовать, чтобы маршрутная информация о конкретном VPN присутствовала только в тех PE-маршрутизаторах, которые соединены с этой VPN. В частности, P-маршрутизаторы не должны иметь какой-либо маршрутной информации о любых VPN.

VPN может пользоваться услугами нескольких сервис-провайдеров. Предполагается, что когда путь между PE-маршрутизаторами пересекает границу между сетями SP, это делается согласно пиринговому соглашению, в рамках которого существует договоренность между двумя провайдерами. В частности, каждый провайдер должен доверять друг другу пересылку только корректной маршрутной информации, и передавать ее, в помеченных (в значении MPLS [9]) пакетах, только если эти пакеты были помечены отправителями, достойными доверия. Предполагается, что для маршрутов, коммутируемых по меткам, разрешается пересекать границы между сервис провайдерами.

2. Сайты и CE

С точки зрения конкретной опорной сети, набор IP-систем представляет собой сайт, если эти системы имеют взаимную коннективность, а коммуникации между ними происходят без использования опорной сети. Вообще, сайт образуется из набора систем, которые географически близки. Однако это не является верным всегда; две географические позиции, соединенные через выделенную линию и отстоящие друг от друга сколь угодно далеко, будут представлять собой один сайт, так как коммуникация между ними не предполагает применение опорной сети.

CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя как мы это увидим, сайт может состоять из множества "виртуальных сайтов"). Сайт, однако, может принадлежать многим VPN.

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

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

3. Таблицы переадресации сайта в PE

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

Как заполняются таблицы переадресации сайтов?

В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами, и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает, от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V.

Если сайт является множественной VPN, таблица переадресации, ассоциированная с этим сайтом, может содержать маршруты от полного набора сетей VPN, членом которого является сайт.

PE содержит вообще только одну таблицу переадресации на сайт, даже если он соединен с сайтом несколькими путями. Различные сайты могут использовать одну и ту же таблицу переадресации, если они намерены пользоваться одним и тем же набором маршрутов.

Предположим, что пакет получен PE-маршрутизатором от определенного сайта, соединенного с ним непосредственно, но место назначения пакета не связано ни с одной из записей таблицы переадресации данного сайта. Если SP не предоставляет доступа к Интернет для данного сайта, тогда пакет отбрасывается. Если SP предоставляет доступ к Интернет для данного сайта, тогда просматривается таблица переадресации PE.

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

1. метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и
2. маршрутизатор опорной сети может определить, что использование этой метки вызовет уход пакета из опорной сети, до того как будет рассмотрена какая-либо ниже лежащая в стеке метка, и до того как будет проанализирован IP-заголовок. Эти ограничения необходимы, для того чтобы препятствовать попаданию пакетов в VPN, которой они не принадлежат.

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

3.1. Виртуальные сайты

В некоторых случаях, конкретный сайт может быть поделен клиентом на несколько виртуальных, возможно с привлечением техники VLAN. Виртуальные сайты могут быть членами различных наборов VPN. PE должен тогда содержать разные таблицы переадресации для каждого виртуального сайта. Например, если CE поддерживает VLAN, и нужно установить соответствие между VLAN и VPN, пакеты, пересылаемые между CE и PE, могут инкапсулироваться с использованием техники VLAN внутри сайта, это может осуществляться PE, совместно с интерфейсом, через который получен пакет, чтобы установить соответствие пакета и определенного виртуального сайта.

В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов, (в частности, если интерфейс следует стандарту Frame Relay или ATM), и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. В любом случае, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные маршрутизаторы CE для каждого виртуального сайта.

Заметим, что во всех случаях, механизмы, как и политика для управления того, какой трафик пропускать и для какого VPN, находится в руках клиента.

Если желательно иметь определенную ЭВМ в составе нескольких виртуальных сайтов, тогда эта машина должна определять для каждого пакета, с каким виртуальным сайтом следует его ассоциировать. Это можно сделать, например, путем посылки пакетов из разных виртуальных сайтов в различные VLAN, или через разные сетевые интерфейсы.

Эти схемы не требуют от CE поддержки MPLS. Раздел 8 содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS.

4. Распределение маршрутов VPN посредством BGP

Маршрутизаторы PE используют BGP для рассылки маршрутов между VPN (точнее, для вынуждения VPN обмениваться маршрутами между собой).

Отправитель BGP может анонсировать и разослать маршрут для данного адресного префикса. Каждая VPN может иметь свое адресное пространство, это означает, что некоторые адреса могут использоваться в любом числе VPN, где в каждой VPN адрес соотносится с разной системой. Отсюда следует, что нужно позволить BGP инсталлировать и рассылать по несколько маршрутов для одного IP-адресного префикса. Более того, нужно гарантировать, что для определения того, какой маршрут из списка, предоставленного BGP, может использовать сайт и какой из них будет прописан в таблице переадресации, служит политика.

4.1. Адресное семейство VPN-IPv4

Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими "адресными семействами". Введем обозначение "VPN-IPv4 address family". Адрес VPN-IPv4 имеет 12-байт и начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса по одному для каждого VPN.

RD не предполагает какой-либо семантики, он не содержит информации о происхождении маршрута или о наборе VPN, куда маршруты следует рассылать. Целью RD является позволить формирование пути к общему адресному префиксу IPv4.

RD может также использоваться для формирования множественных путей к одной и той же системе. В разделе 3, приводится пример, где маршрут к определенному серверу должен быть разным для интранет и экстранет. Это может быть достигнуто путем создания двух разных VPN-IPv4 маршрутов, которые имеют идентичную IPv4 часть, но разные RD. Это позволяет BGP установить несколько разных путей к одной и той же системе и разрешить использование политики (смотри раздел 4.2.3), чтобы решить, какие пакеты будут пользоваться данным маршрутом.

RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number), и чье поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, для того, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые.

Данная таблица переадресации сайта будет иметь только один маршрут VPN-IPv4 для любого заданного адресного префикса IPv4. Когда место назначения пакета соответствует маршруту VPN-IPv4, это соответствие касается только IPv4-части.

PE должен быть сконфигурирован так, чтобы установить соответствие между маршрутами, ведущими к конкретному CE, и их RD. PE может быть сконфигурирован так, чтобы установить соответствие между всеми маршрутами, ведущими к одному CE и имеющими данный RD. Он может быть сконфигурирован и так, чтобы установить соответствие между разными маршрутами, имеющими различные RD даже если они ведут к одному и тому же CE.

4.2. Управление рассылкой маршрутов

В данном разделе, обсуждается способ управления рассылкой маршрутов VPN-IPv4.

4.2.1. Атрибут Target VPN

Каждая таблица переадресации соответствует одному или более атрибутам "Target VPN". Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами " Target VPN". Они рассматриваются протоколом BGP как атрибуты маршрута.

Любой маршрут, ассоциированный с Target VPN T должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов.

Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны, и не должны быть идентичны.

Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities Attribute. Однако формат последнего не является адекватным, так как он позволяет только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities. Должно быть также возможно структурировать формат, аналогично тому, как это описано для RD (смотри раздел 4.1), так что поле тип определит длину поля администратор, а оставшаяся часть атрибута является номером из пространства нумерации администратора.

Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов.

Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами. Можно пренебречь атрибутом Target VPN, создавая больше маршрутов (т.e., используя большее число RD), но тогда свойства масштабируемости окажутся менее привлекательными.

Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом? Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретному сайту с одним Target VPN, а к другому с другим. Или CE-маршрутизатор, когда он рассылает маршруты (смотри раздел 6), может специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если используется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая согласно его конфигурации является обязательной. Более точно было бы называть этот атрибут " Route Target" вместо "VPN Target".

4.2.2. Расылка маршрутов между PE посредством BGP

Если два сайта VPN подключены к PE, которые размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP.

Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), тогда PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router), или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден использовать EBGP, чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам.Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет.

Если имеется много VPN, содержащих сайты, подсоединенные к различным автономным системам, не обязательно иметь только один ASBR между двумя AS, которые содержат все маршруты для всех VPN; могут быть несколько ASBR, каждый из которых содержит только маршруты для конкретного субнабора VPN.

Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве " BGP next hop". Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек, и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого он узнал о маршруте. Метка может также определить инкапсуляцию данных в канале.

В большинстве случаев, метка присвоенная PE, заставит послать пакет непосредственно к CE, а PE, который получает пакет с меткой, не будет искать адрес места назначения пакета в какой-либо таблице переадресации. Однако для PE возможно также присвоить метку, которая неявно идентифицирует некоторую таблицу переадресации. В этом случае, PE, получающий пакет, будет искать адрес места назначения пакета с меткой в одной из его таблиц переадресации.

Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно, или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут ("best effort"), или это может быть маршрут созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно с разными характеристиками QoS.

Доступны все обычные методы использования отражателей маршрутов [2] для улучшения масштабируемости, например, иерархии отражателей маршрутов. Если используются отражатели маршрута, нет нужды иметь отражатель маршрутов, который знает все VPN-IPv4 маршруты для всех VPN, поддерживаемых опорной сетью. Можно иметь отдельные отражатели маршрута, которые не взаимодействуют друг с другом, каждый из которых поддерживает субнабор общего набора VPN.

Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE или рефлекторы маршрута, которые посылают ему маршруты должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, ни анонсируя и не пересылая его.

Маршрутизатор, который не подключен к какой-либо VPN, т.e., P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4.

Эти правила рассылки маршрутной информации гарантируют, что не будет устройства, которое должно знать все VPN-IPv4 маршруты, которые поддерживаются через опорную сеть. В результате полное число таких маршрутов, которые могут поддерживаться через опорную сеть не ограничивается емкостью какого-либо отдельного устройства, и, следовательно, может увеличиваться виртуально беспредельно.

4.2.3. Атрибут VPN of Origin

Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и идентифицирует соответствующий маршрут, как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут, он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities.

В ситуации, в которой необходимо идентифицировать источник маршрута, используется именно этот атрибут, а не RD. Этот атрибут может использоваться при формировании VPN, как это описано ниже.

Возможно более корректно называть этот атрибут "Начало маршрута", а не " VPN of Origin". Он в действительности идентифицирует маршрут, приходящий из определенного набора сайтов вне зависимости оттого, составляет ли этот набор VPN.

4.2.4. Построение VPN, используя атрибуты Target и Origin

Путем соответствующей установки атрибутов Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа.

Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов.

В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа "hub and spoke" (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением " Hub" а другой со значением "Spoke". Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении.

Предположим, имеется определенное число сайтов, размещенных в интранет и экстранет, и некоторое число сайтов, принадлежащих только интранет. Далее могут существовать маршруты интранет и экстранет, которые имеют Target VPN, идентифицирующий весь набор сайтов. Сайты, которые содержат маршруты только интранет, могут отфильтровывать все маршруты с некорректным VPN of Origin.

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

5. Переадресация в опорной сети

Если промежуточные маршруты в опорной сети не имеют никакой информации о маршрутах в VPN, как пакеты будут переадресованы из одного сайта VPN к другому? Это делается с помощью MPLS с двумя уровнями в стеке меток.

Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPN-IPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS, в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.)

Когда PE получает пакет от CE-устройства, он выбирает определенную таблицу переадресации сайта, в которой ищется адрес места назначения пакета. Предположим, что такой адрес найден. Если пакет адресован устройству CE, подключенному к тому же самому PE, пакет посылается непосредственно устройству CE.

Если пакет адресован не устройству CE, подключенному к тому же PE, важен "BGP Next Hop" пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага, и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же что и для IGP, вторая метка может не извлекаться из стека).

В этой точке MPLS будет транспортировать пакет через опорную сеть и в соответствующее CE-устройство. То есть, все решения о переадресации в P- и PE-маршрутизаторах принимаются на уровне MPLS, а IP-заголовки пакетов не анализируются повторно до тех пор, пока они не достигнут устройства CE. Оконечный маршрутизатор PE прежде чем посылать пакет устройству CE, извлекает из стека MPLS очередную метку, таким образом, устройство CE получит обычный IP-пакет.

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

Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это в свою очередь важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE).

6. Как PE узнают о маршрутах от CE

Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN.

В случае, когда CE-устройство является ЭВМ или сетевым переключателем, этот набор адресов будет конфигурироваться в маршрутизаторе PE, подключающем данное устройство. В случае, когда CE-устройство является маршрутизатором, существует много способов, с помощью которых PE-маршрутизатор может получить этот набор адресов.

PE транслирует эти адреса в адреса VPN-IPv4, используя сконфигурированный RD. PE далее рассматривает эти маршруты в качестве входной информации протокола BGP. Ни при каких обстоятельствах маршруты из сайта не должны уходить в IGP опорной сети.

Какой из методов рассылки маршрутов PE/CE возможен, зависит от того, является ли конкретное устройство CE "транзитным VPN" или нет. "Транзитная VPN" - это сеть, которая содержит маршрутизатор, получающий маршруты от "третей стороны" (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором), и который перераспределяет эти маршруты в маршрутизатор PE. VPN, которая не является транзитной VPN, представляет собой "частичную VPN". Подавляющее большинство VPN, включая практически все корпоративные сети, следует считать такими. Возможные механизмы рассылки PE/CE:

1. Может использоваться статическая маршрутизация (т.e., конфигурация).
2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE, скажем PE1, получает VPN-IPv4 маршрут R1, и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE, скажем PE2, (где PE1 и PE2 может быть тем же маршрутизатором или разными маршрутизаторами), если только PE2 не ставит в соответствие R2 и маршрут VPN-IPv4, который отличается от (т.e., содержит другой RD) R1.
3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае, сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора кроме тех, что существуют до CE, размещенном в том же сайте. (Этот метод должен использоваться только в частичных VPN.)
4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP (В частности, EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. (Эта технология может использоваться в частичных или транзитных VPN).

С чисто технической точки зрения это далеко не совершенная методика:

С другой стороны, использование BGP вероятно является чем-то новым для CE администраторов, за исключением случая, когда клиент сам является Интернет сервис-провайдером. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже).

Если набор сайтов представляет собой транзитную VPN, удобно представить их как BGP конфедерацию, так что внутренняя структура VPN окажется спрятанной от любого маршрутизатора, который находится вне VPN. В этом случае, каждый сайт в VPN потребует двух BGP-соединений с опорной сетью, одно будет внутренним по отношению к конфедерации, а другое - внешним. Обычные интра-конфедерационные процедуры должны будут слегка модифицированы, для того чтобы учесть возможность того, что опорная сеть и сайты могут иметь разную политику. Опорная сеть является членом конфедерации на одном из соединений, но не будет членом конфедерации на другом. Такие методики могут быть полезны, если клиентом для услуг VPN является ISP. Эта методика позволяет клиенту, который является ISP, получить услуги опорной сети VPN от одного из партнеров ISP.

Когда нам не нужно различать разные пути, которыми PE может быть проинформирован об адресном префиксе, который существует в данном сайте, мы просто говорим, что PE узнал маршруты от сайта.

Прежде чем PE сможет передать VPN-IPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута:

• Исходный сайт (Site of Origin)

Этот атрибут однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE, или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities (раздел 4.2.1).

• VPN of Origin

Смотри раздел 4.2.1.

• Target VPN

Смотри раздел 4.2.1.

7. Как CE узнает маршруты от PE

В данном разделе мы предполагаем, что устройством CE является маршрутизатор. Вообще, PE может послать любой маршрут в CE, который PE поместил в таблицу переадресации, которую он использует для маршрутизации пакетов из CE. Существует одно исключение: если атрибут маршрута Site of Origin идентифицирует конкретный сайт, такой маршрут не должен никогда посылаться какому-либо CE этого сайта.

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

Какая бы из процедур ни использовалась для рассылки маршрутов от CE к PE, она же может служить для передачи маршрутов от PE к CE.

8. Если CE поддерживает MPLS?

В случае, когда CE поддерживает MPLS, и хочет импортировать весь набор маршрутов из своего VPN, PE может разослать метку для каждого такого маршрута. Когда PE получает пакет от CE с такой меткой, он (a) замещает эту метку соответствующей меткой, которую он получил через BGP, и (b) заносит метку в стек поверх метки, соответствующей BGP следующего шага для заданного маршрута.

8.1. Виртуальные сайты

Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутом Origin and Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет должен просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел.

8.2. Представление ISP VPN в качестве части VPN

Если определенная VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес, обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE.

9. Безопасность

При выполнении следующих условий:

1. Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников не внушающих доверия, если только не известно, что такие пакеты покинут опорную сеть до того как будут проанализированы IP-заголовки или какие-либо метки в стеке, и
2. помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия, безопасность предоставляемая этой архитектурой виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

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

Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

Для пользователя VPN возможно также обеспечить себя повышенной безопасностью путем применения туннельного режима IPSEC [5].

Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC.

Однако процедуры, описанные до сих пор, не позволяют маршрутизатору CE, посылающему пакет, определить идентичность следующего маршрутизатора CE, через который пройдет пакет. Эта информация необходима, для того чтобы использовать туннельный режим IPSEC. Итак, мы должны расширить данные процедуры, чтобы сделать эту информацию доступной.

Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, который идентифицирует следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, может использоваться стандартный туннельный режим IPSEC.

Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

Каждый CE, который должен использовать IPSEC, должен быть так сконфигурирован, чтобы запретить посылку небезопасного трафика по любому из оговоренных адресов. Это блокирует посылку небезопасного трафика CE, если по какой-то причине ему не удалось получить необходимую информацию.

Когда MPLS используется для переноса пакетов между двумя конечными точками туннеля IPSEC, внешний заголовок IPSEC не выполняет в действительности никакой функции. Может быть желательно разработать форму туннеля IPSEC, которая позволяет отбрасывать внешний заголовок, в тех случаях, когда используется MPLS.

9.2. Многокомпонентные безопасные ассоциации

Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE, может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации, все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, оно должно знать какой сети VPN предназначена эта информация. CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

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

Другим преимуществом является то, что исключена необходимость внешнего IP-заголовка, так как инкапсуляция MPLS берет на себя эту функцию.

10. Качество обслуживания

Качество обслуживания (QoS) является ключевым компонентом любой системы VPN. В MPLS/BGP VPN, существующие возможности L3 QoS могут быть применены к помеченным пакетам посредством использования "экспериментальных" битов в промежуточном заголовке [10], или, в случае применения в качестве опорной сети ATM, за счет использования QoS-возможностей самой сети ATM. Управление трафиком, обсуждаемое в работе [1], также применимо к сетям VPN MPLS/BGP. Управление трафиком, если это желательно, может использоваться даже для установления LSP с конкретными параметрами QoS между определенными парами сайтов. Когда MPLS/BGP VPN охватывает нескольких SP, может быть применена архитектура, описанная в [7]. SP может реализовать либо intserv или diffserv возможности конкретной сети VPN.

11. Масштабируемость

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

1. PE-маршрутизаторов,
2. BGP отражателей маршрута,
3. P-маршрутизаторов (которые являются либо PE-маршрутизаторами, либо рефлекторами маршрута), и в случае мульти-провайдерской VPN,
4. ASBR.

P-маршрутизаторы не поддерживают никакие VPN маршруты. Для того чтобы правильно маршрутизовать VPN трафик, P-маршрутизаторы должны поддерживать только маршруты до PE-маршрутизаторов и ASBR. Использование двух уровней пометки позволяет увести маршруты VPN от P-маршрутизаторов.

Маршрутизатор PE поддерживает VPN маршруты, но только для тех VPN, с которыми связан непосредственно.

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

В результате ни один компонент в сети сервис-провайдера не должен поддерживать все маршруты для всех VPN. Итак, полная возможность сети для поддержания увеличивающегося числа участников VPN не ограничивается возможностями одного компонента.

12. Ссылки

[1]   Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.

[2]   Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.

[3]   Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.

[4]   Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.

[5]   Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[6]   Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.

[7]   Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC2430, October 1998.

[8]   Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.

[9]   Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.

[10]   Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.