4.4.28 Сервис виртуальной локальной сети VPLS (RFC-4761)

Использование BGP для автоматического детектирования и управления

Аннотация

Сервис частной виртуальной локальной сети (VPLS), известен также как сервис прозрачной LAN, а виртуальный сервис частных коммутируемых сетей является полезной опцией, которую может предложить сервис-провайдер. Данная технология предлагает VPN на уровне L2; однако, в случае VPLS, клиент в VPN подключается к многоточечной локальной сети Ethernet LAN, в отличии от обычной VPN L2, которая обеспечивает соединение точка-точка.

Актуальность обеспечения QoS (качества обслуживания) в локальных сетях с тем, чтобы получить требуемый уровень сервиса точка-точка, диктовала необходимость разработки протокола, сходного с MPLS-TE, но работающего в LAN. Данная статья является переводом документа RFC-4761, где базовые функции работы с метками возложены на протокол BGP. Аналогичным документом, где аналогичная задача решается с привлечением протокола LDP, является RFC-4662.

1. Введение

Частные виртуальные локальные сети (VPLS) известны также как прозрачные LAN Service и виртуальные частные коммутируемые сети.

Однако, в VPLS, клиенты оказываются подключены не к одной LAN; они могут быть разбросаны по региональной сети (MAN или даже WAN). По существу, VPLS объединяет вместе несколько индивидуальных LAN в рамках сети с коммутацией пакетов, превращая их в единую LAN [9].

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

2. Функциональная модель

Модель работы VPLS демонстрируется на рис. 1.

CE - Оконечное устройство клиента;
PE - Пограничный маршрутизатор провайдера;
u-PE - агрегация уровня L2;
A<n> - Сайт клиента n
Рис 1. Пример VPLS

2.1. Терминология

Здесь используется терминология, сходная с [6]: сетевой сервис-провайдер (SP), P (только провайдер), PE (пограничный маршрутизатор), и клиенты со своими CE (оконечное оборудование пользователя). Здесь, однако, существует дополнительное соображение, имеется в виду "u-PE", устройство PE уровня L2, используемое для агрегации на уровне L2. Понятие u-PE описано ниже в разделе 5. Устройства PE и u-PE имеют непосредственное отношение к VPLS, что означает, что они знакомы с услугами VPLS. Термин VE относится к оконечному оборудованию VPLS, которое может быть либо PE, либо u-PE.

Напротив, устройство CE (которое может принадлежать и использоваться, как SP, так и клиентом) является независящим от VPLS; что касается CE, оно соединяется с другими CE в VPLS посредством уровня L2 коммутируемой сети. Это означает, что для обеспечения работы VPLS не должно быть каких-либо изменений в устройстве CE, ни на аппаратном, ни на программном уровне.

CE-устройство может быть соединено с PE или u-PE на уровне переключателей L2, которые не имеют отношения к VPLS. С точки зрения VPLS, эти переключатели L2 невидимы, и, следовательно, в дальнейшем не будут обсуждаться. Кроме того, u-PE может быть соединено с PE посредством устройств L2 и L3.

Термин "демультиплексор" относится к идентификатору пакета данных. В данной статье под демультиплексором подразумевается MPLS-метка.

Термин "VPLS" относится к сервису, а также к конкретной инсталляции услуги (напр., эмулированная локальная сеть).

2.2. Предположения

Сеть сервис-провайдера использует коммутацию пакетов. Предполагается, что приборы PE соединяются (логически) с помощью туннелей, через которые передаются пакеты, относящиеся к данному виду сервиса (VPLS). Эти туннели могут быть IP-туннелями, такими как GRE (Generic Routing Encapsulation), или MPLS-туннелями, сформированными протоколом RSVP-TE или LDP. Эти туннели формируются независимо от предлагаемых для них сервисов.

Функции "Передача на все порты" (flooding) и выявление MAC-адресов (см. раздел 4) являются частью VPLS. Однако, эти операции являются частными по отношению к устройству SP, т.е., в VPLS, описанном ниже, ни одно SP-устройство не запрашивает другое SP-устройство переадресовать пакеты на другие порты или выяснить MAC-адрес.

Все PE, участвующие в VPLS, предполагаются информационно связанными, т.e., существует двунаправленное псевдопроводное соединение между любыми двумя PE, участвующими в этой VPLS, и таким образом каждый (входной) PE может послать VPLS-пакет выходному PE непосредственно, без необходимости наличия промежуточного PE (см. раздел 4.2.5.). Это требует, чтобы VPLS PE были полностью логически связаны в рамках плоскости управления, так что PE могут послать сообщение другому PE, чтобы сформировать псевдопроводное соединение.

2.3. Взаимодействия

VPLS является "сервисом локальной сети", в котором устройства CE, которые принадлежат данному VPLS-варианту V могут взаимодействовать через сеть SP, так как, если бы были подключены к локальной сети. VPLS является "частной" и CE-устройства, которые принадлежат к различным VPLS, не могут взаимодействовать. VPLS является "виртуальной" и разные VPLS могут взаимодействовать через общую сеть с коммутацией пакетов.

PE-устройства взаимодействуют друг с другом, чтобы "выявить" все прочие PE, подключенные к той же VPLS. Эти взаимодействия управляются командами, а не данными.

u-PE взаимодействуют с PE, для того чтобы сформировать соединение с удаленными PE или u-PEs той же VPLS. Это взаимодействие также управляется командами.

PE-устройства могут участвовать одновременно как в VPLS, так и в IP VPN [6]. Существуют независимые сервисы, а информация, пересылаемая в рамках каждого типа, является независимой и представляет собой NLRI (Network Layer Reachability Information). Для каждого из обменов используются свои адресные идентификаторы AFI (Address Family Identifiers) и дополнительные адресные идентификаторы SAFI (Subsequent Address Family Identifiers). Следовательно, программная реализация должна поддерживать отдельное запоминание маршрутов для каждого сервиса. Однако, несколько сервисов могут использовать одни и те же туннели; метки VPLS или VPN используются для демультиплексирования пакетов для разных сервисов.

3. Плоскость управления

Существует две базовые функции для плоскости управления VPLS: автоматическое выявление адресов, а также формирование и ликвидация псевдопроводных соединений, которые образуют VPLS, эти функции относятся к управляющим процедурам (signaling). Обе эти функции реализуются с помощью уведомлений об обновлениях протокола BGP.

3.1. Автоматическое определение адреса

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

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

3.2. Алгоритм управления

Когда выявление партнеров осуществлено, каждая пара PE в VPLS должна быть способна установить (и разорвать) псевдопроводное соединение друг с другом, т.е., обмен (и прерывание) процессов демультиплексирования. Этот процесс называется управлением (signaling). Управление используется также для передачи определенных характеристик псевдопроводных соединений, которые PE сформировал для данной VPLS.

Обратный вызов, который демультиплексор использует, чтобы различать различные потоки трафика, проходящие через туннель, и, возможно, представляющие разные сервисы. В случае VPLS, демультиплексор определяет не только то, к какой VPLS принадлежит пакет, но идентифицирует входной PE. Для переадрeсации пакетов используется информация о VPLS; а идентификатор PE служит для определения MAC-адресов. Демультиплексор, описанный здесь, является MPLS-меткой. Однако, заметим, что туннели PE-PE не обязательно являются MPLS-туннелями.

При использовании сообщения BGP Update для посылки демультиплексора каждому удаленному PE исходному PE необходимо послать N таких сообщений для N удаленных PE. Решение, описанное в данной статье, позволяет PE послать одно (общее) Update-сообщение, которое содержит демультиплексоры для всех удаленных PE, вместо N индивидуальных сообщений. Это уменьшает загрузку плоскости управления, как для исходного PE, так и для BGP отражателей маршрутов, которые могут быть вовлечены в рассылку этих сообщений обновления другим РЕ.

3.2.1. Блоки меток

Для реализации этого мы вводим обозначение "Блок меток". Блок меток, определенный базовой меткой LB и VE-блоком с размером VBS, представляет собой непрерывный набор меток {LB, LB+1, ..., LB+VBS-1}. Всем PE в рамках данного VPLS приписывается уникальный VE ID (идентификатор) в качестве части его конфигурации. PE X, желающий послать VPLS-сообщение обновления, посылает одну и ту же информацию блока меток всем остальным PE. Каждый PE-приемник воспринимает эти данные в качестве метки для PE X, добавляя (уникальный) VE ID к базе меток. Таким образом, каждый принимающий PE получает уникальный демультиплексор для PE X этой VPLS. Эта простая нотация расширена с помощью концепции VE VBO (block offset). Блок меток, определенный с помощью <LB, VBO, VBS>, представляет собой набор {LB+VBO, LB+VBO+1, ..., LB+VBO+VBS-1}. Таким образом, вместо одного большого блока меток, покрывающего все VE ID в VPLS, можно иметь несколько блоков меток, каждый с отдельной базой меток. Это упрощает управление блоком меток, и позволяет также обслуживать PE X, интегрируя его в VPLS с VE ID, который не перекрывается с набором блока меток, который PE X уже анонсировал.

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

3.2.2. VPLS BGP NLRI

VPLS BGP NLRI, описанное ниже с новыми AFI и SAFI (смотри [4]) используется для обмена членством в VPLS и демультиплексорами.

VPLS BGP NLRI имеет следующие информационные элементы: VE ID, VE Block Offset (смещение блока), VE Block Size (размер блока) и базу меток (label base). Формат VPLS NLRI представлен ниже. AFI является L2VPN AFI (25), а SAFI является VPLS SAFI (65). Длины полей измеряются в октетах.

Рис. 2. BGP NLRI для VPLS-информации

PE, участвующее в VPLS должно иметь по крайней мере один VE ID. Если PE является VE, он имеет обычно один идентификатор VE ID. Если PE соединен с несколькими u-PEs, он имеет определенные VE ID для каждого u-PE. Он может иметь дополнительный VE ID для самого себя, если он функционирует в качестве VE для этой VPLS. Далее мы будем называть PE, анонсирующий VPLS NLRI PE-a, и мы будем предполагать, что PE-a имеет VE ID V (принадлежащий PE-a самому или u-PE, подключенному к PE-a).

Идентификаторы VE ID обычно присваиваются сетевым администратором. Их областью действия является локальная VPLS. Данный VE ID должен принадлежать только одному PE, если только CE не является многодомным (см. раздел 3.5).

Блок меток представляет собой набор меток демультиплексоров, используемых для того, чтобы достичь заданного VE ID. VPLS BGP NLRI с VE ID V, смещение блока VE VBO, размер блока VE VBS, и база меток LB передаются их партерам в следующем порядке:

Блок меток для V: метки от LB до (LB + VBS - 1), и
удаленный VE-набор для V: от VBO до (VBO + VBS - 1).

Существует соответствие один к одному между удаленным набором VE и блоком меток: VE ID (VBO + n) соответствует метке (LB + n).

3.2.3. Формирование PW и аннулирование

Предположим, что PE-a является частью некоторой сети VPLS и осуществляет анонсирование VE ID V, смещение блока VE VBO, размер блока VE VBS, и база меток LB. Если PE-b является также частью некоторой VPLS и имеет VE ID W, PE-b выполняет следующее:

1. проверяет, является ли W частью PE ('удаленный набор VE'): если VBO <= W < VBO + VBS, тогда W является частью PE удаленного набора VE. Если нет, PE-b игнорирует это сообщение и прерывает эту процедуру.
2. формирует PW до PE-a: метка - демультиплексор, чтобы пересылать трафик из PE-b к PE-a вычисляется как (LB + W - VBO).
3. проверяет, является ли V частью какого-либо 'удаленного набора VE', который анонсировался PE-b, т.e., PE-b проверяет, принадлежит ли V какому-либо набору удаленного VE, который был анонсирован PE-b, со смещением блока VE VBO', размером блока VE VBS' базой метки LB'. Если нет, то PE-b должен произвести новое анонсирование, как это описано в разделе 3.3.
4. формирует PW от PE-a: метка - демультиплексор, посредством которой PE-b должен получить трафик от PE-a, вычисляется как: (LB' + V - VBO').

Если Y отзывает NLRI для V, который использует X, тогда X должен ликвидировать концы своего псевдопроводного соединения между X и Y.

3.2.4. Возможности управления PE

Следующий атрибут, "Layer2 Info Extended Community" (информационно расширенная комюнити уровня L2), используется для управления информацией о псевдопроводном соединении, которое нужно сформировать для данной VPLS. Расширенное значение комюнити должно быть присвоено IANA (в настоящее время используется значение 0x800A). Эта информация включает в себя тип Encaps (тип инкапсуляции для псевдопроводного соединения), Флаги управления (управляющая информация, относящаяся к псевдопроводному соединению), и MTU (Maximum Transmission Unit), которое будет использоваться в псевдопроводном соединении.

Тип Encaps (инкапсуляции) для VPLS равен 19.

Рис. 3 Уровень L2 для расширенной комюнити

Рис. 4. Бит-вектор флагов управления

Согласно рисунку 4, определены только два бита флагов управления; остальные биты, обозначенные MBZ, должны быть сделаны равными нулю при отправке и игнорироваться при получении этого комюнити.

Значение имени

C - Управляющее слово (Control word) [7] должно или не должно присутствовать при посылке VPLS-пакетов данному PE, в зависимости от того, равно ли C 1 или 0
S - последовательная доставка кадров должна или не должна осуществляться при отправке VPLS-пакетов этому PE, в зависимости от того, равно ли S 1 или 0.

3.3. Работа BGP VPLS

Чтобы сформировать новую VPLS, скажем VPLS foo, сетевой администратор должен сформировать RT для VPLS foo, скажем RT-foo. Оно будет использоваться всеми PE, которые обслуживают VPLS foo. Чтобы сконфигурировать данный PE, скажем PE-a, который будет частью VPLS foo, сетевой администратор должен только выбрать VE ID V для PE-a. (Если PE-a соединено с u-PEs, PE-a может быть сконфигурирован с более чем одним VE ID; в этом случае, для каждого VE ID следует сделать следующее). PE может быть также сконфигурирован с помощью RD (Route Distinguisher); если нет, то генерируется уникальный RD для VPLS foo. Скажем RD равен RD-foo-a. PE-a тогда генерирует исходный блок меток, а удаленный VE устанавливается для V, заданный смещением блока VE VBO, размером блока VE VBS, и базой меток LB.

Затем PE-a формирует VPLS BGP NLRI с RD соответствующим RD-foo-a, VE ID V, смещением блока VE VBO, размером блока VE VBS и базе меток LB. К этому он дополняет Info Extended Community уровня L2 и RT = RT-foo. Он устанавливает значение следующего шага BGP для данного NLRI соответствующим самому себе, и анонсирует это NLRI своим партнерам. Протокол сетевого уровня, соответствующий сетевому адресу следующего шага для комбинации <AFI=L2VPN AFI, SAFI=VPLS SAFI> является IP; такая ассоциация необходима при [4], раздел 5. Если значение длины поля следующего шага равно 4, тогда поле следующего шага содержит адрес IPv4. Если его значение равно 16, тогда поле следующего шага содержит адрес IPv6.

Если PE-a получает от другого PE, скажем PE-b, уведомление VPLS BGP с RT-foo и VE ID W, тогда PE-a знает, что PE-b является членом той же самой сети VPLS (автоматическое выявление). PE-a затем должен сформировать свою часть псевдопроводного соединения VPLS между PE-a и PE-b, используя механизм, описанный в разделе 3.2. Аналогично, PE-b узнает, что PE-a находится в той же сети VPLS, и PE-b должен формировать свою часть псевдопроводного соединения VPLS. Таким образом, управление и формирование псевдопроводного соединения осуществляется в рамках того же сообщения Update.

Если W не содержится ни в одном из удаленных наборов VE, которые анонсировал PE-a для VE ID V в VPLS foo, PE-b не сможет сформировать свою часть псевдопроводного соединения до PE-a. Для осуществления адресации, PE-a может отозвать старые анонсирования, выполненные для VPLS foo, и анонсировать новый Update с большим набором удаленных VE и соответствующим блоком меток, который покрывает все VE ID, которые содержатся в VPLS foo. Это, однако, может вызвать сбой некоторых услуг. Альтернативой для PE-a является создание нового удаленного набора VE и соответствующего блока меток, и анонсировать их в новом запросе Update, без отзыва предыдущего анонсирования.

Если конфигурация PE-a в отношении удаленного VE ID V из VPLS foo изменилась, тогда PE-a должен отозвать все свои анонсирования для VPLS foo, которые содержат VE ID V. Если все связи PE-a до его CE в VPLS foo стали недоступны, тогда PE-a должен либо отозвать все свои NLRI для VPLS foo или позволить другим PE в VPLS foo выяснить аналогичным образом, что PE-a более не подключены к его CE.

3.4. VPLS для нескольких автономных систем

Как это выполнено в [14] и [6], описанные выше функции автоматического выявления и управления обычно реализуются через I-BGP. Это предполагает, что все сайты в VPLS подключены к PE в рамках одной автономной системы (AS).

Однако, сайты в VPLS могут быть подключены к PE из разных автономных систем. Это приводит к ряду последствий: 1) не будет I-BGP-соединений между этими PE, таким образом, потребуются некоторые средства управления для прохождения AS; и 2) может не быть туннелей PE-PE между автономными системами.

Аналогичная проблема решается в [6], раздел 10. Предлагается три метода решения задачи (1); все эти методы имеют сходство с VPLS, работающей с несколькими AS.

Ниже приведена схема соединений:

Рис. 5. VPLS между AS

Так как в приведенных выше ссылках предложено три метода управления сетями VPLS, охватывающими несколько AS; они представляются в порядке роста их масштабируемости. Метод (a) является самым простым для понимания, и легким для реализации; однако, он требует Ethernet-соединения между автономными системами, а также реализации плоскостей управления и данных VPLS в пограничных маршрутизаторах AS (ASBR). Метод (b) требует, чтобы плоскость управления при соединении AS-AS находилась в VPLS ASBR и MPLS маршрутизаторах (которые не обязательно работают с Ethernet). Метод (c) требует MPLS для соединения AS-AS, но не позволяет реализовать VPLS для любого типа ASBR.

3.4.1. Метод (a): соединение VPLS-VPLS через ASBR

В этом методе, пограничный маршрутизатор AS (ASBR1) работает как PE для всех VPLS, которые охватывают AS1 и AS, к которым подключен ASBR1 (в данном примере AS2). ASBR соседней AS (ASBR2) просматривается ASBR1, который выполняет функцию CE для VPLS, охватывающей AS1 и AS2; аналогично, ASBR2 действует как PE для этой VPLS с точки зрения AS2, и рассматривает ASBR1 в качестве CE. Этот метод не требует MPLS в канале ASBR1-ASBR2, но требует, чтобы этот канал передавал Ethernet-трафик и, чтобы существовал отдельный VLAN интерфейс для каждой VPLS, через которую этот канал проходит. Он кроме того требует, чтобы ASBR1 выполнял PE операции (выявление, управление, определение MAC-адреса, переадресацию на все порты, инкапсуляцию и т.д.) для всех VPLS ASBR1. Это возлагает серьезную нагрузку на ASBR1, как в плоскости управления так и в плоскости данных, что ограничивает число VPLS охватывающих большое число AS.

Заметим, что вообще, здесь имеется много соединений между парами AS, для обеспечения избыточности. В этом случае, протокол STP (Spanning Tree Protocol) [15], или другое средство выявления и предотвращения петлевых маршрутов, должен работать в каждой сети VPLS, которая перекрывает эти AS, так что для каждой VPLS формируется древовидная топология. Это накладывает дополнительную ношу на ASBR и PE, участвующих в этих VPLS, так как эти устройства будут должны отслеживать отсутствие петель трафика в каждой такой VPLS.

3.4.2. Метод (b): EBGP-редистрибуция данных VPLS между ASBR

Этот метод требует от I-BGP пиринг-обмена между PE в AS1 и ASBR1 в AS1 (возможно через рефлекторы маршрута), E-BGP пиринг между ASBR1 и ASBR2 в AS2, и I-BGP пиринги между ASBR2 и PE в AS2. В выше представленном примере PE1 посылает VPLS NLRI в ASBR1 с блоком меток и себя в качестве следующего шага маршрута; ASBR1 посылает NLRI в ASBR2 с новыми метками, предлагая себя в качестве BGP следующего шага; а ASBR2 посылает NLRI в PE2 с новыми метками, предлагая себя в качестве следующего шага. Соответственно, имеется три туннеля: T1 от PE1 до ASBR1, T2 от ASBR1 до ASBR2, и T3 от ASBR2 до PE2. Внутри каждого туннеля должна использоваться VPLS-метка, определяющая приемное устройство; напр., VPLS-метка внутри T1 является меткой из блока меток, которые ASBR1 послал PE1. ASBR ответственны за получение VPLS-пакетов, инкапсулированных в туннель, и за выполнение соответствующих манипуляций с метками, определяющими идентичность пакетов и направление их переадресации.

VPLS NLRI, которые посылает ASBR1 в ASBR2 (и NLRI, которые посылает ASBR2 в PE2) идентичны VPLS NLRI, которые PE1 посылает в ASBR1, за исключением блока меток. Чтобы быть точным, Длина, Идентификатор маршрута, VE ID, смещение блока VE и размер блока VE должны совпадать; базы метки могут быть различны. Кроме того, ASBR1 должен также обновить свой маршрут переадресации следующим образом: если база меток, посланная PE1 равна L1, размер блока меток равен N, база меток, посланная ASBR1 равна L2, а метка туннеля между ASBR1 и PE1 равна T, тогда ASBR1 должен инсталлировать следующий маршрут переадресации:

меняются местами метки L2 и L1, вводится в стек T,
меняются местами L2+1 и L1+1, вводится в стек T, ...
меняются местами L2+N-1 и L1+N-1, вводится в стек T.

ASBR2 должен действовать аналогично, за исключением того, что ему не нужна метка туннеля, если он непосредственно соединен с ASBR1.

Когда PE2 хочет послать VPLS-пакет в PE1, PE2 использует свой VE ID, чтобы получить правильную VPLS-метку из блока меток ASBR2 для PE1, и использует метку туннеля, чтобы достичь ASBR2. ASBR2 меняет местами метку VPLS и метку от ASBR1; ASBR1 далее меняет местами метку VPLS и метку PE1, и заносит в стек метку туннеля, чтобы достичь PE1.

В этом методе нужен MPLS в интерфейсах ASBR1-ASBR2, но здесь не нужно, чтобы на канальном уровне работал Ethernet, кроме того, ASBR принимают участие в получении VPLS-информации. Однако, требования плоскости данных ASBR сходны с используемыми в методе (a), и ограничиваются операциями с метками. Наконец, гарантия отсутствия петлевых маршрутов в VPLS осуществляется на уровне маршрутизации, а именно выбором пути и следующего шага в BGP, таким образом здесь нет нужды использовать протокол Spanning Tree для каждой VPLS. Данный метод является более масштабируемым по сравнению с методом (a).

3.4.3. Метод (c): Многошаговая EBGP-редистрибуция VPLS-информации между AS

В этом методе, осуществляется многошаговый E-BGP пиринг между PE (или предпочтительно, отражатель маршрута (Route Reflector) в AS1 и PE (или Route Reflector) в AS2. PE1 посылает VPLS NLRI с метками и следующим шагом в PE2; если путь идет через отражатель маршрута, при этом следующий шаг BGP не изменяется. Это требует, чтобы существовал LSP-туннель от PE1 до PE2. Этот LSP-туннель может формироваться, как это описано в [6], раздел 10 (c), например, с использованием E-BGP.

Когда PE1 хочет послать VPLS-пакет в PE2, он заносит в стек VPLS-метку, соответствующую его собственному VE ID. Он затем заносит в стек метку туннеля, чтобы достичь PE2.

Этот метод не требует никакой VPLS-информации (как в плоскости управления, так и в плоскости данных) в ASBR. ASBR нужно только сформировать LSP-туннель PE-PE в плоскости управления, и выполнять операции с метками в плоскости данных. Здесь, как и в случае метода (b), создание VPLS-топологии лишенной петель осуществляется на уровне маршрутизации, т.e., это BGP-путь и выбор следующего шага, здесь не требуется использовать протокол STP для каждой из VPLS. Эта опция, судя по всему, является наиболее масштабируемой.

3.4.4. Присвоение VE ID в сетях с несколькими AS

Для того чтобы облегчить присвоение идентификаторов VE ID для VPLS, которые бы работали для нескольких AS, можно выделить диапазоны идентификаторов для каждой AS. Например, AS1 использует VE ID в диапазоне 1 - 100, AS2 от 101 до 200, и т.д.. Если имеется 10 сайтов, включенных в AS1 и 20 в AS2, выделенными VE ID могут быть 1-10 и 101 - 120. Это минимизирует число VPLS NLRI, которыми нужно обменяться, чтобы убедиться в уникальности VE ID.

В выше приведенном примере, если AS1 нужно больше чем 100 сайтов, тогда для AS1 может быть зарезервирован другой диапазон идентификаторов. Единственным требованием является то, чтобы не было перекрытия VE ID диапазонов для разных AS. Исключением из этого правила является многодомность, которая будет рассмотрена ниже.

3.5. Многодомность и выбор маршрута

Часто бывает желательно иметь многодомный VPLS сайт, т.e., иметь подключение к нескольким PE, возможно даже в разных AS. В таком случае PE, подключенные к одному и тому же сайту, могут быть сконфигурированы либо с тем же VE ID либо с разными VE ID. В последнем случае необходимо использовать протокол STP для устройства CE, и, возможно, для PE, чтобы сформировать VPLS с топологией свободной от петель. Заметим, что многодомность для SP и STP на CE могут сосуществовать; таким образом рекомендуется, чтобы клиент VPLS использовал STP, если CE может это делать.

В случае, когда PE, подключенным к тому же сайту, присваиваются те же VE ID, топология свободная от петель обеспечивается механизмами маршрутизации, в частности, путем выбора пути посредством BGP. Когда оператор BGP получает два эквивалентных NLRI, он осуществляет стандартную процедуру выбора маршрута, такую как Local Preference и длину пути в AS, чтобы определить, какой NLRI выбрать; он должен оставить только одну. Если выбранная NLRI впоследствии отзывается, оператор BGP использует выбор маршрута для оставшегося эквивалента VPLS NLRI, чтобы выбрать другой вариант; если не осталось ни одного, информация переадресации, ассоциированная с этим NLRI, удаляется.

Два VPLS NLRI считаются эквивалентными с точки зрения выбора маршрута, если Route Distinguisher, VE ID и смещение блока VE совпадают. Если двум PE присвоен один и тот же VE ID в данной VPLS, они должны использовать один и тот же Route Distinguisher, и они должны анонсировать тот же самый размер блока VE для заданного смещения VE.

3.6. Иерархическая BGP VPLS

Существует три аспекта масштабирования плоскости управления:

1. ослабление требований полной коннективности для операторов VPLS BGP;
2. ограничение передачи сообщений BGP VPLS только определенным операторам, а не всем BGP-операторам; и
3. упрощение добавления и ликвидации операторов BGP, либо для VPLS, либо другим приложениям.

К счастью, использование BGP для маршрутизации Internet, а также для IP VPN дает несколько полезных решений для всех этих проблем. Базовой техникой является иерархия, использующая BGP рефлекторы маршрутов RR (Route Reflectors) [8]. Идея заключается в том, чтобы выделить небольшой набор отражателей маршрутов, которые образуют полный граф, и затем запустить BGP сессию между каждым BGP-опрератором и одним или более RR. Таким способом, нет нужды для прямой всеобщей коннективности для всех BGP-операторов. Если масштабирование требует от провайдера иметь большое число RR, тогда эта техника может быть применена рекурсивно: полная коннективность для RR может быть переложена уже на другой уровень RR. Использование RR решает проблемы 1 и 3, названные выше.

Важно заметить, что RR, так как они используются для VPLS и VPN, представляют собой в чистом виде плоскость управления. Использование RR не вводит понятий плоскости данных или информационных требований переадресации в отношении RR. Это находится в контрасте по отношению к технике иерархических VPLS описанной в [10].

Другим следствием этого подхода является то, что он требует, чтобы RR обрабатывали все BGP-сообщения, или чтобы конкретный RR обрабатывал все сообщения от заданного PE. Можно определить несколько наборов RR, например, один набор обрабатывает VPLS, другой - IP VPN, а третий служит для Internet-маршрутизации. Другое распределение функций может быть связано с субнаборами VPLS и IP VPN, когда один набор обслуживается одним набором RR, а другой субнабор VPLS и IP VPN обслуживается другим набором RR. Использование RTF (Route Target Filtering), описанное в [12], может сделать это проще и эффективнее.

Наконец, проблема 2 (которая ограничивает передачу сообщений BGP VPLS только заинтересованными операторами BGP) сопряжена с использованием RTF. Эта техника ортогональна использованию RR, но работает хорошо в контакте с RR. RTF является также очень эффективной в сетях VPLS, объединяющих несколько AS; более подробно о преимуществах RTF можно найти в [12]. Полезно упомянуть об аспектах управления, которые часто становятся причиной неудач. MAC-адреса не могут передаваться через посредство BGP. Процедуры узнавания и устаревания MAC-адресов лежат в плоскости данных и имеют индивидуальный характер для каждого PE. Единственной задачей обмена сообщениями в BGP VPLS является автоматическое выявление партнеров и обмен метками.

Таким образом, BGP-обслуживание для VPLS происходит когда

1. PE присоединяется или покидает VPLS; или
2. происходит отказ в сети, приводящий к прерыванию PE-PE туннеля или канала PE-CE.

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

4. Плоскость данных

В этом разделе описывается два аспекта, сопряженные с плоскостью данных для PE и u-PEs, использующих VPLS: инкапсуляция и переадесация.

4.1. Инкапсуляция

Кадры Ethernet, полученные от устройств CE инкапсулируются для передачи через сети с коммутацией пакетов, соединяющие PE. Инкапсуляция производится согласно описанию в [7].

4.2. Переадресация

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

4.2.1. Определение MAC-адреса

Как было упомянуто ранее, ключевой отличительной чертой VPLS является то, что это многоточечный сервис. Это означает, что вся сеть сервис-провайдера выступает в качестве логического моста для каждой VPLS, которую поддерживает сеть SP. Логическими портами для SP "моста" являются порты клиентов, а также псевдопроводные каналы VE. Таже как обычный мост узнает MAC-адреса для своих портов, SP-мост должен узнавать MAC-адреса своих VE. Процесс выяснения адресов состоит в ассоциировании MAC-адресов отправителя в пакетах с логическими портами, через которые они пришли; эта ассоциация и формирует таблицу переадресации FIB (Forwarding Information Base). FIB используется для перадресации пакетов. Например, предположим, что мост получил пакет с МАС-адресом отправителя S через логический порт P. Если далее мост получит пакет с адресом места назначения S, он будет знать, что нужно переслать его через порт P.

Если VE узнает MAC-адрес отправителя S на логическом порту P, а позднее видит S на порту P', тогда VE должен обновить свою FIB с учетом полученной информации о P'. VE может применить механизм распечатки вариаций портов отправителей для данного MAC-адреса.

4.2.2. Старение

VPLS PE должны иметь механизм старения, чтобы удалять MAC-адреса, ассоциированные с логическим портом, точно также как это делает обычный мост. Это необходимо для того, чтобы отследить случаи, когда MAC-адрес переместится с одного логического порта на другой, либо в результате того, что станция с этим МАС-адресом действительно переместилась, либо из-за изменения топологии локальной сети Кроме того старение уменьшает размер МАС-таблицы VPLS, сохраняя лишь активные, а не все МАС-адреса VPLS.

"Возраст" МАС-адреса отправителя S на логическом порту P равен времени с момента его последнего появления на порту P. Если возраст превышает порог T, S должен быть удален из FIB. Это конечно означает, что каждый раз, когда S появляется на порту P, возраст S обнуляется.

Программная реализация должна обеспечить конфигурацию и, например, возможность поменять предельный возраст T записи в FIB для каждой VPLS. Кроме того, реализация может ускорять старение всех МАС-адресов в VPLS, если детектирует определенную ситуацию, такую как изменение топологии Spanning Tree в данной VPLS.

4.2.3. Передача на все порты

Когда мост получает пакет, адрес места назначения которого отсутствует в его FIB, он направляет такой пакет на все прочие порты. Аналогично, VE переадресует пакеты на все порты в случае неизвестного адреса места назначения всем прочим VE в VPLS.

На рисунке 1 выше, если CE2 посылает Ethernet-кадр PE2, а MAC-адрес места назначения отсутствует в FIB PE2 (для данной VPLS), тогда PE2 должен быть способен переадресовать кадр через все порты всем прочим PE данной VPLS. При получение такого кадра PE1 будет нести ответственность за последующую переадресацию пакета в CE1 и CE5 (если PE1 не знает, какому CE "принадлежит" этот MAC-адрес).

С другой стороны, если PE3 получает кадр, он может делегировать последующую переадресацию кадра на все порты (flooding) своему u-PE. Если PE3 был подключен к двум u-PE, он должен анонсировать, что у него два u-PE. PE3 может либо анонсировать, что не может осуществить переадресацию на все порты, в таком случае он получит два кадра, по одному для каждого u-PE, или он может анонсировать, что он может это сделать, в этом случае он получит одну копию кадра, который будет переслан обоим u-PEs.

4.2.4. Бродкастинг и мультикастинг

Существует хорошо известный широковещательный MAC-адрес. Ethernet-кадр, чей адрес места назначения является широковещательным MAC-адресом, должен быть послан всем станциям данной VPLS. Это может быть реализовано тем же способом, что и переадресация на все порты (flooding).

Существуют также известные "мультикастные" MAC-адреса. Ethernet-кадры с мультикатным адресом места назначения могут быть широковещательно переданы всем рабочим станциям; VE может также использовать определенную технику, чтобы ограничить передачу мультикастинговых кадров к ограниченному набору приемников, к тем, которые проявляют интерес к соответствующей мультикастной группе.

4.2.5. Переадресация по алгоритму "Split Horizon"

Когда PE, способный перадресовать пакет всем (скажем PEx), получает широковещательный Ethernet-кадр, или пакет с неизвестным MAC-адресом места назначения, он должен перадресовать его всем. Если кадр приходит от подключенного CE, PEx должен копировать этот кадр всем прочим подключенным CE, а также всем прочим PE, членам сети VPLS. Если, с другой стороны, кадр пришел от другого PE (скажем PEy), PEx должен послать копию пакета только подключенным к нему CE. PEx не должен посылать кадр другим PE, так как PEy уже сделал это. Такой алгоритм называется "split horizon", из чего следует, что для VPLS все PE оказываются логически соединенными друг с другом.

Правила переадресации по алгоритму Split horizon применяются к широковещательным и мультикастным пакетам, а также к пакетам с неизвестным MAC-адресом.

4.2.6. Квалифицированное и неквалифиуцированное распознавание адресов

Ключевым для нормального распознавания MAC Ethernet является (6-октетный) MAC-адрес. Распознавание таких адресов называется неквалифицированным. Однако, возможно также, что процедура распознавания включает в себя метку VLAN; такая процедура называется "квалифицированным распознаванием".

В случае VPLS, распознавание адресов происходит в контексте конкретной сети VPLS, что зависит от клиента. Если клиент использует VLAN-метки, можно использовать квалифицированное или неквалифицированное распознавание адресов. Если ключом для распознавания в пределах VPLS является MAC-адрес, тогда эта VPLS работает в режиме неквалифицированного распознавания. Если ключом для распознавания является (метка VLAN клиента + MAC-адрес), тогда данная VPLS работает в режиме квалифицированного распознавания.

Выбор между квалифицированным и неквалифицированным распознаванием включает в себя несколько факторов, наиболее важным из которых является, желателен ли один глобальный широковещательный домен (неквалифицированный) или используется отдельный широковещательный домен для каждой VLAN (квалифицированный). Последний вариант делает переадресацию на все порты и широковещательную адресацию более эффективной, но требует больших MAC-таблиц. Эти соображения приложимы как к обычной Ethernet-переадресации, так и к VPLS.

4.2.7. Класс услуг

Для того чтобы предложить разные классы сервиса в рамках VPLS, программная реализация может выбрать схему соответствия битов 802.1p в кадре Ethernet клиента с меткой VLAN, чтобы соответствовать установки битов EXP в псевдопроводной метке туннеля, допуская различную обработку кадров VPLS в сети с коммутацией пакетов.

Чтобы быть полезной, реализация должна допускать функции установления соответствия (mapping), разные для каждой VPLS, так как каждый клиент VPLS может иметь свое собственное мнение относительно приемлемого поведения при заданных значениях бит 802.1p.

5. Использование опций

При работе с сетью, которая поддерживает VPLS, SP должен решить, какая из функций VPLS наиболее важна для клиента. По умолчанию, в данной статье это VE = PE. Однако, существует много причин того, что VE может быть устройством, реализующим все функции L2 (такие как выявление MAC-адреса и переадресация на все порты), и ограниченный набор функций L3 (таких как коммуникации со своим PE), но, например, не поддерживает полноценное выявление адресов и управление PE-PE. Такие устройства называются "u-PE".

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

6. Соображения безопасности

Центральным аспектом сервисов виртуальных частных локальных сетей (VPLS)является конфиденциальность данных, т.e., данные в VPLS рассылаются только узлам из VPLS, и ни при каких обстоятельствах не каким-либо внешним агентам или другим VPLS. Заметим, VPLS сама по себе не гарантирует конфиденциальности, целостности или аутентичности: пакеты VPLS посылаются открыто через сети с коммутацией пакетов, и человек по середине без труда может перехватить, исказить или вставить любые данные. Если секретность желательна, туннели PE-PE могут быть заменены туннелями IPsec. Для обеспечения большей безопасности оконечные устройства в VPLS-сайтах могут использовать подходящие средства криптографии.

Имеется два аспекта обеспечения конфиденциальности в VPLS: обеспечение безопасности плоскости управления и защита пути переадресации. Компрометация плоскости управления может привести к тому, что данные, посылаемые PE, принадлежащие некоторой VPLS, могут попасть в другую VPLS, или будет осуществлена передача информации злоумышленнику. Так как все обмены в плоскости управления происходят через BGP, методики, описанные в [2], помогут аутентифицировать BGP-сообщения, что затруднит их искажение (которые могут приводить к ответвлению VPLS-трафика в сомнительную VPLS или реализовать DoS-атаку). В методах работы с несколькими автономными системами (b) и (c), описанных в разделе 3,это означает защиту BGP-сессий, реализуемых между разными AS (между ASBR, PE или RR. Можно использовать методики, описанные в разделе 10(b) и (c) [6], и предназначенные для плоскостей управления и данных. Заметим, что [2] не поможет сохранить конфиденциальность VPLS меток.Однако, это требует доступа к потоку данных в сети сервис-провайдера.

Могут иметь место ошибки в конфигурации, приводящие к непреднамеренному соединению CE, принадлежащих к разным VPLS. Это может быть вызвано,например, при ассоциации неверного адреса места назначения (Route Target) для некоторой VPLS. Защита плоскости данных требует гарантии того, что туннели PE-PE работают адекватно, и что метки VPLS воспринимаются только от легальных интерфейсов. Для PE, легальными интерфейсами являютсяканалы от маршрутизаторов P. Для ASBR, легальным интерфейсом является канал от ASBR в AS, которая является частью данной VPLS. Особенно важно для VPLS-сетей с несколькими AS, чтобы воспринимались пакеты только от легальных интерфейсов.

MPLS-в-IP и туннелирование MPLS-в-GRE специфицированы в [3]. Если желательно использовать такие туннели, для передачи VPLS-пакетов, тогда надо использовать соображения безопасности, описанные в разделе 8 того же документа. Любая реализация VPLS, которая позволяет туннелировать VPLS-пакеты так, как это описано в данной статье, должна содержать реализацию IPsec. Если безопасность туннеля не обеспечена IPsec, тогда следует применить методику фильтрации по IP-адресам в пограничном маршрутизаторе, описанную в разделе 8.2 [3]. Это является единственным средством, которое может гарантировать то, что пакет на выходе туннеля был туда направлен туда легальным узлом (т.e., что пакет не содержит фальсифицированного адреса отправителя). Так как пограничные маршрутизаторы часто фильтруют только адреса отправителя, фильтрация пакетов может быть неэффективной, если только выходной PE не может проверить IP-адрес отправителя для любого пакета, который он получает, и сравнить его со списком IP-адресов, которые являются легальными для данного туннеля. Любая реализация, которая допускает туннелирование MPLS-в-IP и/или MPLS-в-GRE без IPsec должна позволять выходному PE проверять IP-адрес отправителя для любого пакет, полученного из туннеля.

Техника VPLS используется для подключения к информационным центрам (см. [9]), так как она может гарантировать определенный уровень CoS.

7. Ссылки

7.1. Нормативные ссылки

1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
2. Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
3. Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
4. Bates, T., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
5. Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
6. Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
7. Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.

7.2. Информативные ссылки