Вообще, существуют следующие виды L2VPN:
Возможность инкапсулировать трафик любого канального уровня в MPLS называется AToM — Any Transport over MPLS.
Вот список поддерживаемых AToM протоколов:
- ATM Adaptation Layer Type-5 (AAL5) over MPLS
- ATM Cell Relay over MPLS
- Ethernet over MPLS
- Frame Relay over MPLS
- PPP over MPLS
- High-Level Data Link Control (HDLC) over MPLS
Для построения любого L2VPN существуют два концептуально разных подхода.


PE — Provider Edge — граничные маршрутизаторы MPLS-сети провайдера, к которым подключаются клиентские устройства (CE).
CE — Customer Edge — оборудование клиента, непосредственно подключающееся к маршрутизаторам провайдера (PE).
AC — Attached Circuit — интерфейс на PE для подключения клиента.
VC — Virtual Circuit — виртуальное однонаправленное соединение через общую сеть, имитирующее оригинальную среду для клиента. Соединяет между собой AC-интерфейсы разных PE. Вместе они составляют цельный канал: AC→VC→AC.
PW — PseudoWire — виртуальный двунаправленный канал передачи данных между двумя PE — состоит из пары однонаправленных VC. В этом и есть отличие PW от VC.
VPWS — Virtual Private Wire Service.
В основе любого решения MPLS L2VPN лежит идея PW — PseudoWire — виртуальный кабель, прокинутый из одного конца сети в другой. Но для VPWS сам этот PW и является уже сервисом.
Эдакий L2-туннель, по которому можно беззаботно передавать всё, что угодно.
Ну, например, у клиента в Котельниках находится 2G-базовая станция, а контроллер — в Митино. И эта БС может подключаться только по Е1. В стародавние времена пришлось бы протянуть этот Е1 с помощью кабеля, радиорелеек и всяких конвертеров.
Сегодня же одна общая MPLS-сеть может использоваться, как для этого Е1, так и для L3VPN, Интернета, телефонии, телевидения итд.
(Кто-то скажет, что вместо MPLS для PW можно использовать L2TPv3, но кому он нужен с его масштабируемостью и отсутствием Traffic Engineering'а?)
VPWS сравнительно прост, как в части передачи трафика, так и работы служебных протоколов.
0. Между R1 и R6 уже построен транспортный LSP с помощью протокола LDP или RSVP TE. То есть R1 известна транспортная метка и выходной интерфейс к R6.
1. R1 получает от клиента CE1 некий L2 кадр на AC интерфейс (то может оказаться Ethernet, TDM, ATM итд. — не имеет значения).
2. Этот интерфейс привязан к определённому идентификатору клиента — VC ID — в некотором смысле аналогу VRF в L3VPN. R1 даёт кадру сервисную метку, которая сохранится до конца пути неизменной. VPN-метка является внутренней в стеке.
3. R1 знает точку назначения — IP-адрес удалённого PE-маршрутизатора — R6, выясняет транспортную метку и вставляет её в стек меток MPLS. Это будет внешняя — транспортная метка.
4. Пакет MPLS путешествует по сети оператора через P-маршрутизаторы. Транспортная метка меняется на новую на каждом узле, сервисная остаётся без изменений.
5. На предпоследнем маршрутизаторе снимается транспортная метка — происходит PHP. На R6 пакет приходит с одной сервисной VPN-меткой.
6. PE2, получив пакет, анализирует сервисную метку и определяет, в какой интерфейс нужно передать распакованный кадр.
Если вы читали предыдущий выпуск про L3VPN, то в вопросе передачи пользовательского трафика не увидите ничего нового — пара MPLS-меток и передача по транспортному LSP. Ingress PE проверяет какие метки поставить и в какой интерфейс отправить, P меняет транспортную метку, а Egress PE по метке VPN принимает реш