Построение виртуальной частной сети на базе MPLS. Технология MPLS

Спецификация кодирования стека меток MPLS определена в RFC3032 "MPLS Label Stack Encoding". Данный документ содержит детальную информацию о метках и о том, как они используются с различными сетевыми технологиями, а также определяет ключевое для технологии MPLS понятие – стек меток. Возможность иметь в пакете более одной метки в виде стека позволяет создавать иерархию меток, что открывает дорогу многим приложениям.

MPLS может выполнить со стеком следующие операции:

помещать метку в стек;

удалять метку из стека;

и заменять метку.

Эти операции могут использоваться для слияния и разветвления информационных потоков. Операция помещения метки в стек (push operation) добавляет новую метку поверх стека, а операция удаления метки из стека (pop operation) удаляет верхнюю метку стека.

Функциональные возможности стека MPLS позволяют объединять несколько LSP в один. К стеку меток каждого из этих LSP сверху добавляется общая метка, в результате чего образуется агрегированный тракт MPLS. В точке окончания такого тракта происходит его разветвление на составляющие его индивидуальные LSP. Так могут объединиться тракты, имеющие общую часть маршрута. Следовательно, MPLS способна обеспечивать иерархическую пересылку, что может стать важной и востребованной функциональной возможностью. При ее использовании не нужно переносить глобальную маршрутную информацию, и это делает сеть MPLS более стабильной и масштабируемой, чем сеть с традиционной маршрутизацией.

Согласно рассматриваемым ниже правилам инкапсуляции меток, за меткой MPLS в пакете всегда должен следовать заголовок сетевого уровня. Так как MPLS начинает работу верхнего уровня стека, этот стек используется по принципу LIFO "последним пришел, первым ушел".

Пример четырехуровневого стека меток представлен на рис. 2.

Заголовок MPLS № 1 был первым заголовком MPLS, помещенным в пакет, затем в него были помещены заголовки № 2, № 3 и, наконец, заголовок № 4. Коммутация по меткам всегда использует верхнюю метку стека, и метки удаляются из пакета так, как это определено выходным узлом для каждого LSP, по которому следует пакет. Рассмотренный в предыдущем параграфе бит S имеет значение 1 в нижней метке стека и 0 – во всех остальных метках. Это позволяет привязывать префикс к нескольким меткам, другими словами – к стеку меток (Label Stack). Каждая метка стека имеет собственные значения поля EXP, S-бита и поля TTL.

Рис. 2. Четырехуровневый стек меток

Инкапсуляция меток

При использовании протоколов коммутации на уровне звена данных, таких как ATM и Frame Relay, верхняя MPLS-метка вписывается в поле идентификаторов этих протоколов. Далее будет показано, как при применении ATM для размещения MPLS-метки используется поле VPI/VCI, а при применении Frame Relay – поле DLCI (Data LinkConnection Identifier). В тех случаях, когда MPLS обеспечивает пересылку IP-пакетов сетевого уровня и когда технология уровня звена данных не поддерживает собственное поле меток, MPLS-заголовок должен инкапсулироваться между заголовками уровня звена данных и сетевого уровня.

Механизм инкапсуляции переносит один или более протоколов верхних уровней внутри полезной нагрузки дейтаграммы инкапсулирующего протокола. В сущности, вводится новый заголовок, который делает из инкапсулированного заголовка и поля данных новое поле данных. Общая модель инкапсуляции представлена на рис. 10.3, где подразумевается, что инкапсуляция MPLS может быть использована с любой технологией уровня 2. Метка MPLS может быть помещена в существующий формат заголовка уровня 2, как в случае АТМ или FR, или вписана в специальный заголовок MPLS, как в случае Ethernet или PPP. Bo всех случаях любые дополнительные метки находятся между верхней меткой стека и IP-заголовком уровня 3.

Показанный на рис 3 заголовок MPLS часто называют shim header ("заголовком - клином"), подчеркивая в метафорической форме тот факт, что этот заголовок "уровня 2.5" вклинивается в пакет между заголовками уровня данных и сетевого уровня.

Рис. 3. Принцип инкапсуляции заголовка MPLS

Одной из самых сильных сторон технологии MPLS (и потому отраженной в ее названии) является то, что она может использоваться совместно с различными протоколами уровня 2. Среди этих протоколов – ATM , Frame Relay , PPP и Ethernet , FDDI и другие, предусмотренные документами по MPLS .

Покажем, как метка может вписываться в заголовок уровня звена данных (VCI/VPI для сети ATM, DLCI для сети Frame Relay и т.п.) или "вставляться" между заголовками уровня звена данных и сетевого уровня. С самого начала рабочая группа IETF MPLS решила, что во всех случаях, когда это возможно, MPLS должна использовать имеющиеся форматы. По этой причине информация метки MPLS может передаваться в пакете несколькими разными методами:

как часть заголовка второго уровня ATM, когда информация метки передается в идентификаторах виртуального канала VCI и виртуального тракта VPI, что показано на рис. 10.4;

как часть кадра AAL5 уровня адаптации ATM (ATM Adaptation Layer 5) перед сегментацией и сборкой SAR (Segmentation and Reassembly), что выполняется в ATM-окружении в случае, когда эта информация содержит данные о стеке меток (несколько полей MPLS-меток);

как часть заголовка второго уровня Frame Relay, когда информация метки передается в идентификаторах DLCI, что изображено на рис. 10.5;

как новая 4-байтовая метка, называемая клином или прокладкой (shim), которая вставляется между заголовками второго и третьего уровней, что показано на рис. 10.5, – во всех остальных случаях.

Размещение метки MPLS в заголовке ATM представлено на рис. 4.

Рис. 4. MPLS-метка, передаваемая в полях VPI/VCI заголовка АТМ

Использование MPLS поверх ATM сейчас довольно распространено, особенно для транспортировки по сетям ATM трафика IP. АТМ-коммутаторы, которые конфигурированы для поддержки MPLS (ATM-LSR), выполняют протоколы маршрутизации TCP/IP и используют пересылку данных в ATM фиксированной длины 53 байта. Внутри этих ATM-LSR верхняя метка MPLS помещается в поля VCI/VPI заголовка ячейки ATM, а данные о стеке меток MPLS - в поле данных ячеек ATM.

MPLS в сетях Frame Relay была развернута рядом крупных поставщиков услуг и до сих пор широко используется. Подобно ATM, FR-коммутаторы, поддерживающие MPLS, применяют протоколы маршрутизации TCP/IP для пересылки данных под управлением FR. При использовании FR текущая метка помещается в поле идентификатора канала звена данных DLCI в заголовке FR. Любые дополнительные записи в стек меток MPLS переносятся после заголовка FR, но до заголовка сетевого уровня, содержащегося в поле данных кадра FR. Стандарт MPLS позволяет FR использовать адрес Q.922 длиной либо 2 октета, либо 4 октета. Формат представлен на рис. 5.

Рис. 5. Размещение метки MPLS в кадре FR

Примечание. Длина поля DLCI может составлять 10, 17 или 23 бита

В отношении ячеек ATM и кадров Frame Relay договорились использовать для MPLS имеющиеся форматы заголовков, а во всех остальных случаях – собственную метку MPLS, "прокладку" между заголовками второго и третьего уровней. Отсюда видно, что MPLS позволяет создавать новые форматы меток без изменения протоколов маршрутизации, а потому распространение этой технологии на вновь появляющиеся виды оптического транспорта, такие как плотное мультиплексирование с разделением по длине волны DWDM (Dense Wave Division Multiplexing) и оптическая коммутация, представляет собой относительно простую задачу.

Принцип, представленный на рис. 10.3, подходит для каналов типа "точка-точка" (Point-to-Point – РРР) и для локальных сетей Ethernet (всех типов). Подобным методом можно передать одну MPLS-метку или стек меток.

Протокол РРР фактически представляет собой семейство родственных протоколов IETF, используемое для передачи многопротокольных дейтаграмм по двухточечным каналам связи. РРР определяет метод инкапсуляции дейтаграмм разных протоколов сетевого уровня, протокола управления звеном данных LCP и набора протоколов управления сетью NCP. Для использования MPLSCP с управлением коммутацией по меткам через звено РРР был определен специальный протокол, который управляет передачей пакетов MPLS по каналу РРР. Этот протокол обозначается аббревиатурой MPLSCP. Формат показан на рис. 6.

Рис. 6. Формат для введения MPLS-метки в пакет РРР и в кадр Ethernet

Когда пакеты MPLS передаются по Ethernet, в каждом кадре Ethernet переносится только один снабженный меткой пакет. Метка помещается между заголовком уровня звена данных и заголовком сетевого уровня. Использование MPLS в сетях Ethernet, особенно в городских сетях, является еще одной перспективной возможностью MPLS. В стандарт Ethernet вносятся изменения, позволяющие увеличить скорость и дальность передачи Ethernet-пакетов. В настоящее время начинают применяться Ethernet-интерфейсы на скоростях 10 Гбит/с, а в скором времени появятся Ethernet-интерфейсы и на еще больших скоростях.

К сожалению, добавление MPLS-метки или стека меток к 1492-байтовому пакету может привести к необходимости его фрагментации. При передаче пакетов MTU-размера (Maximum Transmission Unit – максимально возможный размер передаваемого блока данных) с MPLS-меткой протокол управления передачей TCP определяет, что в MPLS-сети нужно произвести фрагментацию. Однако следует отметить, что многие Ethernet-каналы поддерживают передачу 1500-байтовых или 1508-байтовых пакетов. Более того, в большинстве сетей пакеты с метками обычно передаются по ATM- или РРР-каналам, а не по сегментам локальных сетей.

Итак, метка может быть помещена в пакет разными способами – вписывается в специальный заголовок, помещаемый либо между заголовками уровня 2 и уровня 3, либо в свободное и доступное поле заголовка одного из этих двух уровней, если, конечно, таковое имеется. Очевидно, что вопрос о том, куда следует помещать заголовок, содержащий метку, должен согласовываться между объектами, ее использующими.

Таблицы пересылки

Ранее отмечалось, что когда пакет MPLS попадает в маршрутизатор коммутации по меткам LSR, этот маршрутизатор просматривает имеющуюся у него таблицу с так называемой информационной базой меток LIB (Label Information Base) для того, чтобы принять решение о дальнейшей обработке пакета. Эту информационную базу иногда называют также Next Hop Label Forwarding Entry (NHLFE), и, согласно RFC 3031, в нее обычно входит следующая информация:

операция, которую надо произвести со стеком меток пакета (заменить верхнюю метку стека, удалить верхнюю метку, поместить поверх стека новую метку);

следующий маршрутизатор в LSP, причем "следующим" может быть тот же самый LSR;

используемая при передаче пакета инкапсуляция на уровне звена данных;

способ кодирования стека меток при передаче пакета;

другая информация, относящаяся к пересылке пакета.

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

Таблица 1 Таблица пересылки LIB

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

Запись в таблице может также содержать информацию, указывающую, какие ресурсы имеет возможность использовать пакет, например, определенную выходную очередь.

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

Привязка "метка-FEC"

Каждая запись в таблице пересылки, которую ведет LSR, содержит одну входящую метку и одну или более исходящих меток. В соответствии с этими двумя типами меток обеспечивается два типа привязки меток к FEC:

первый тип – метка для привязки выбирается и назначается в LSR локально. Такая привязка называется локальной;

второй тип – LSR получает от некоторого другого LSR информацию о привязке метки, которая соответствует привязке, созданной на этом другом LSR. Такая привязка называется удаленной.

Средства управления коммутацией по меткам используют для заполнения таблиц пересылки как локальную, так и удаленную привязку меток к FEC . Это может делаться в двух вариантах : upstream и downstream . Первый: когда метки на локальной привязке используются как входящие метки, а метки из удаленной привязки - как исходящие. Второй вариант – прямо противоположный, т.е. метки из локальной привязки используются как исходящие метки, а метки из удаленной привязки – как входящие. Рассмотрим каждый из этих вариантов.

Первый вариант называется привязкой метки к FEC "снизу" (downstream label binding), потому что в этом случае привязка переносимой пакетом метки к тому FEC, которому принадлежит этот пакет, создается нижестоящим LSR, т.е. LSR, расположенным ближе к адресату пакета, чем LSR, который помещает метку в пакет. При привязке "снизу" пакеты, которые переносят определенную метку, передаются в направлении, противоположном направлению передачи информации о привязке этой метки к FEC.

Второй вариант называется привязкой метки к FEC "сверху" (upstream label binding ) , потому что в этом случае привязка переносимой пакетом метки к тому FEC, которому принадлежит этот пакет, создается тем же LSR, который помещает метку в пакет; т.е. создатель привязки расположен "выше" (ближе к отправителю пакета), чем LSR, к которому пересылается этот пакет. При привязке "сверху" пакеты, которые переносят определенную метку, передаются в том же направлении, что и информация о привязке этой метки к FEC.

LSR обслуживает также пул "свободных" меток (т.е. меток без привязки). При начальной установке LSR пул содержит все метки, которые может использовать LSR для их локальной привязки к FEC. Именно емкость этого пула и определяет, в конечном счете, сколько пар "метка-FEC" может одновременно поддерживать LSR. Когда маршрутизатор создает новую локальную привязку, он берет метку из пула; когда маршрутизатор уничтожает ранее созданную привязку, он возвращает метку, связанную с этой привязкой, обратно в пул.

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

LSR создает или уничтожает привязку метки к FEC вследствие определенного события. Такое событие может инициироваться либо пакетами данных, которые должны пересылаться маршрутизатором LSR, либо управляющей (маршрутной) информацией, которая должна обрабатываться LSR. Когда создание или уничтожение привязки инициируется пакетами данных, эта привязка называется привязкой под воздействием данных (data-driven). Когда создание или уничтожение привязки инициируется управляющей информацией, данная привязка называется привязкой под воздействием управляющей информации (control-driven).

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

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

В меньшей степени это относится к схемам, работающим под воздействием управляющей информации. Пока топология остается стабильной, весь трафик, который поступает в непограничный маршрутизатор LSR, может коммутироваться по меткам без обработки пакетов управляющим процессором. Схемы, работающие под воздействием управляющей информации, могли получить информацию о привязке маршрутов от соседних LSR, которые не являлись следующими участками этих маршрутов. Когда топология изменится так, что эти "соседи" станут следующими участками маршрутов, коммутация по меткам будет продолжаться без прерывания. Но на производительность схем, работающих под воздействием данных, изменение топологии влияет. Если изменяется маршрут прохождения потока, новые LSR на этом маршруте воспринимают это так, как если бы был создан новый поток. Любой такой новый поток должен вначале пересылаться традиционно. Таким образом, изменение топологии может налагать очень тяжелое бремя на LSR, который только что стал новым следующим маршрутизатором для некоторого другого LSR. Во-первых, он внезапно получает большое число потоков, которые ранее шли по другому маршруту. Кроме того, не прекращается поступление новых потоков от вновь запущенных приложений. Все эти потоки должны пересылаться и анализироваться алгоритмами обнаружения потоков. Это в свою очередь создает дополнительную нагрузку как на средства пересылки при традиционной маршрутизации, так и на средства управления коммутацией по меткам. Во время таких переходных процессов производительность средств пересылки LSR может приблизиться к производительности его средств пересылки при традиционной маршрутизации, т.е. стать примерно на порядок ниже, чем максимальная производительность LSR.

21.09.2006 Энно Рей, Петер Фирс

MPLS используется в магистральных сетях практически всех операторов и находит все большее распространение в территориальных локальных сетях. Однако при определенных условиях из-за MPLS могут возникнуть серьезные проблемы с безопасностью. Поэтому

перед использованием VPN на базе MPLS или магистральных структур необходимо провести анализ рисков, в особенности в отношении передаваемого трафика.

Многопротокольная коммутация меток (Multi-Protocol Label Switching, MPLS) представляет собой специфицированную RFC 3031 и другими документами технологию продвижения пакетов. Разработчики стремились избежать неэффективной маршрутизации IP, когда маршрут каждого пакета определяется по его адресу назначения посредством объемных таблиц маршрутизации. В случае MPLS продвижение пакетов происходит на основании так называемых «меток». Для этого в заголовок добавляется блок данных размером 32 бит. Большую его часть составляет «тег» длиной 20 бит - собственно метка, на основании которой и принимается решение о дальнейшем перемещении пакета. Кроме того, имеется еще три поля, в том числе время жизни пакета (Time-To-Live, TTL).

Когда пакет IP достигает магистрали на базе MPLS, он в первую очередь классифицируется - по адресу назначения или по принадлежности к определенной клиентской виртуальной частной сети (Virtual Private Network, VPN), затем снабжается одной или несколькими метками и направляется дальше. На каждом транзитном узле верхняя метка заменяется на новую, после чего пакет передается следующему соседу. О метках и их значениях два соседних маршрутизатора договариваются при помощи специального протокола - в большинстве случаев протокола распределения меток (Label Distribution Protocol, LDP). Благодаря согласованию между соседними устройствами отпадает необходимость в централизованном механизме управления метками.

Когда пакет покидает магистраль, он направляется дальше в соответствии с традиционными механизмами маршрутизации.

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

Наряду с базовой функцией - эффективной обработкой пакетов - метки служат для решения и других задач. В сети на базе MPLS есть ряд прочих функций, которые часто называют «службы MPLS» (см. Рисунок 1).

К таковым относятся:

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

Некоторые из перечисленных технологий, к примеру формирование трафика (Traffic Engineering, TЕ), имеют значение только для операторов магистральных сетей. Другие, в особенности технологии VPN, играют важную роль для многих организаций - когда подобная услуга приобретается у оператора или соответствующая служба используется в собственной территориальной локальной сети, к примеру для разделения трафика разных дочерних предприятий. Эти технологии будут представлены и подробно описаны ниже.

ОСНОВЫ ВИРТУАЛЬНОЙ ЧАСТНОЙ СЕТИ MPLS

В случае виртуальной частной сети MPLS речь идет о самостоятельной технологии на основе меток с собственной терминологией, описанной главным образом в RFC 2547 и 2917. Она часто сравнивается с ретрансляцией кадров и АТМ, поскольку в рамках одной сетевой инфраструктуры организуется несколько раздельных логических маршрутов, по которым передается трафик отдельных (клиентских) виртуальных частных сетей. Технология очень гибка в отношении возможных топологий VPN, поскольку благодаря использованию так называемых «целей маршрута» можно определять, какие сети и в каких таблицах маршрутизации упоминаются.

В первую очередь различие проводится между провайдерской сетью, где применяется MPLS, и клиентской, которая использует соответствующую службу, но не имеет никакого отношения к выделению меток или соответствующему продвижению данных. Транзитный пункт между клиентом и провайдером со стороны провайдера называют пограничным устройством провайдера (Provider Edge, PE), а со стороны клиента - пограничным устройством клиента (Customer Edge, CE).

Устройство РЕ обычно обслуживает нескольких клиентов, для чего помимо своей таблицы маршрутизации, которая в этом случае называется «глобальная», ведет дополнительные, специфичные для каждой VPN виртуальные экземпляры маршрутизации и продвижения данных (Virtual Routing and Forwarding Instance, VRF). Благодаря подобной виртуализации можно сделать так, чтобы разные клиенты пользовались одним и тем же адресным пространством или разными протоколами маршрутизации (см. Рисунок 2 и 3).

Устройства РЕ, к которым подключаются клиенты, обмениваются информацией о том, какую именно сеть (префикс) и какого клиента они обслуживают посредством многопротокольного BGP (Multiprotocol BGP, MP-BGP) - расширенного варианта пограничного шлюзового протокола (Border Gateway Protocol, BGP). Передаваемая информация выглядит примерно так: «Через меня (устройство РЕ) при помощи следующей метки можно достичь следующие префиксы (сети) таких-то клиентов».

Функциональность VPN можно обобщить следующим образом:

• маршрутизатор РЕ назначает индивидуально сконфигурированную метку при помощи так называемого «различителя маршрутов» каждой клиентской виртуальной частной сети;
• устройство РЕ при помощи MP-BGP передает данные о «различителе маршрутов», префиксе сети и соответствующей метки.

В результате каждое устройство РЕ узнает, через какие устройства РЕ можно достичь сети указанного клиента, и что за метка при этом используется - при условии отсутствия фильтрации информации о маршрутизации на основании конечного маршрута.

Если устройство РЕ получает от клиентского устройства пакет, оно снабжает его (минимум) двумя метками и направляет дальше: одна метка определяет, какому устройству РЕ ретранслируется пакет; вторая - к какому клиенту (клиентской сети) он относится. Таким образом, вся функциональность VPN реализуется при помощи двух меток.

При оценке безопасности этой технологии VPN часто цитируется старое исследование компании Miercom, главная мысль которого заключается в том, что технологию можно рассматривать как надежную, поскольку злоумышленник не в состоянии получить доступ к клиентским VPN или магистрали (см. Рисунок 4). Даже если придерживаться аргументации этого исследования - а Miercom часто обвиняют в чрезмерной близости к его заказчику, компании Cisco, - необходимо учитывать некоторые особенности:

• трафик в виртуальных частных сетях MPLS не шифруется. Если в представлении читателя понятие «виртуальная частная сеть» обязательно включает в себя шифрование, то от этого базового допущения придется отказаться. В данном случае VPN не означает ничего более, кроме разделения трафика;
• маршрутизатор РЕ обычно «делится» между различными клиентами и - при определенных условиях - задачами. Поэтому атаки, к примеру «отказ в обслуживании» (Denial of Service, DoS), из клиентской сети или - при условии соответствующей достижимости - из Internet могут иметь побочное негативное воздействие на безопасность или доступность других клиентов;
• авторы статьи в ходе оценки операторов столкнулись с тем, что технический персонал не проводит предписанной технической проверки устройств РЕ (сканирование), «чтобы отрицательно не повлиять на достижимость других клиентов».

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

МЕТОДЫ АТАК

При атаках на VPN первоочередная цель злоумышленника - чтение трафика или неавторизованный доступ. Атаки DoS в этом случае не рассматриваются. Все атаки можно разделить на атаки «извне» (из клиентской сети или Internet) и атаки «изнутри» (с магистрали MPLS).

Инжекция (ввод) предварительно маркированного трафика из клиентской сети. Злоумышленник, находящийся в клиентской сети, может попытаться проникнуть в другую виртуальную частную сеть, передав «своему» устройству РЕ пакеты, уже содержащие метку. Речь идет о метке, на основании которой пакет направляется в другую VPN. Но как написано в RFC 2547: «Пакеты с метками из не заслуживающих доверия источников не принимаются магистральными маршрутизаторами».

С точки зрения провайдера, клиентская сеть никогда «не заслуживает доверия», а значит, такие пакеты должны отклоняться маршрутизатором РЕ.

Инжекция (ввод) уже маркированного трафика из Internet. Злоумышленник может попытаться отправить на маршрутизатор РЕ уже маркированные пакеты из Internet, с целью передать их в клиентскую сеть. Для этого ему необходимо узнать или угадать используемые метки и IP-адреса, что вполне возможно. IP-адрес 10.1.1.1, к примеру, встречается в большинстве сетей, а кроме того, зная производителя оборудования, метки довольно легко угадать. Между тем уже имеется инструмент, который служит для автоматического определения используемых в сети меток (см. ссылку в ). Инструмент предназначен только для магистрали и не рассчитан на применение из Internet, и поэтому он не подходит для описанной атаки. Тем не менее его наличие - показатель того, что атаки на MPLS попали в сферу интересов хакеров. В ближайшем будущем наверняка появятся новые средства для автоматического проведения описанных здесь атак.

Маркированные соответствующим образом пакеты необходимо доставить до атакуемой точки (что маловероятно), а атакуемый маршрутизтор PЕ должен быть достижим из Internet (что зависит от организации конкретной сети провайдера) - только тогда атака будет успешной. Но благодаря тенденции к концентрации все большего количества функций на все меньшем числе многофункциональных устройств, такие условия нельзя полнос-тью исключать. Как уже упоминалось, RFC 2547 предписывает, чтобы пакеты с метками из не заслуживающих доверия источников, к каковым, безусловно, относится Internet, отбрасывались. В том, что это требование выполняется, мы могли убедиться, проведя различные тесты. Однако cоставители книги «Безопасность виртуальных частных сетей MPLS», выпущенной компанией Cisco, утверждают: такая атака на маршрутизаторы может быть успешной при использовании некоторых (старых) версий операционной системы IOS.

АТАКИ С МАГИСТРАЛИ

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

Атаки с магистрали. Если злоумышленник контролирует один из узлов магистрали, то у него появляется возможность для проведения целого ряда различных атак. Конечно, прежде всего весь проходящий через этот узел трафик, если он дополнительно не зашифрован, подвергается угрозе считывания. Как правило, такое шифрование обеспечить довольно просто, однако нередко от него отказываются ради экономии и простоты администрирования виртуальной частной сети MPLS, чего не скажешь о VPN на базе IPsec, - как известно, MPLS VPN призваны заменить IPSec VPN. При обсуждении безопасности виртуальных частных сетей MPLS магистраль, за эксплуатацию которой отвечает провайдер, принимается как надежная и безопасная. Авторы, имеющие обширный практический опыт в вопросах безопасности, не готовы считать что бы то ни было изначально надежным и безопасным. В случае следующих сценариев не исключается атака на виртуальную частную сеть MPLS с магистрали.

Скомпрометированные провайдерские устройства. Необходимо помнить, что провайдерские устройства могут быть взломаны. Опубликованная в 2003 г. на собрании Группы североамериканских сетевых операторов (North American Network Operators" Group, NANOG) статистика упоминает о подобных инцидентах с более чем 5000 маршрутизаторами в сетях провайдеров услуг Internet.

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

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

Атаки на транзитные узлы между провайдерами. Для того чтобы предлагать виртуальные частные сети MPLS в мировом масштабе, многие операторы заключают между собой контракты, благодаря которым они могут строить виртуальные частные сети MPLS, простирающиеся за пределы их собственной сети, и одновременно обмениваться маркированными пакетами. RFC 2547 описывает разные модели, и среди них по меньшей мере одна - по иронии судьбы, наиболее масштабируемая - может быть по сути своей ненадежной. Кроме того, в точках обмена трафика (Internet Exchange Points, IXP) операторы часто организуют межсоединения на базе Ethernet, в результате чего потенциально создаются условия для атак на интерфейс данных на втором уровне.

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

Неправильно сконфигурированные устройства провайдеров. В большинстве случаев устройства провайдеров обслуживаются людьми, сверх меры загруженными различными обязанностями, из-за чего совершаются непредумышленные ошибки. При определенных условиях даже становится возможным нарушение целостности магистрали MPLS. Если же виртуальные частные сети MPLS используются в рамках корпоративных сетей, как это чаще всего и происходит, тогда нет почти никакой разницы между «клиентскими устройствами» и «безусловно надежными провайдерскими устройствами» - по меньшей мере в том, что касается обслуживающего персонала. На часто приводимую в оправдание ссылку на уязвимость «изнутри» структуры на базе ретрансляции кадров и АТМ авторы хотели бы возразить, указав на два значительных отличия:

• как ретрансляция кадров, так и АТМ предполагают наличие специализированных устройств (коммутаторов), которые недостижимы из Internet. Виртуальные частные сети MPLS, для которых ключевыми словами являются консолидация и оптимизация затрат, часто реализуются на базе имеющихся платформ, а они, помимо прочего, берут или могут взять на себя дополнительные функции в сети провайдера услуг Internet и вследствие этого потенциально достижимы из Internet;
• многообразие протоколов на разных уровнях (второй уровень: АТМ/ретрансляция кадров, третий уровень: IP) повышает сложность эксплуатации (а значит, и затраты на нее), но затрудняет проведение атак.

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

АТАКИ ИЗ ЯДРА MPLS

Модификация маршрутизации MP-BGP. Когда злоумышленник в состоянии вмешаться в первоначальный информационный обмен в Multiprotocol BGP, он может добавлять в виртуальную частную сеть «дополнительные филиалы», и уже через них получить неавторизованный доступ к системам. Причем надо не только находиться на магистрали, но и иметь в наличии дополнительные инструменты для точечного доступа к трафику BGP, что требует значительных усилий.

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

Варианты атак различны. К примеру, в той, что показана на Рисунке 5, в двух разных VPN («альфа» и «бета») используется одно и то же адресное пространство. Поступающие на устройство PE пакеты для адресного пространства 172.31.1.0 различаются по их меткам (17 для «альфа» и 20 для «бета»):

pe_7204vxr>sh ip vp vpnv4 vrf alpha labels

Network Next HopIn label/Out label

Route Distinguisher: 100:1 (alpha)

20.20.20.21/32 10.10.10.25 nolabel/17

20.20.20.40/32 172.31.2.2 19/nolabel

172.31.1.0/29 10.10.10.25 nolabel/18

172.31.2.0/29 0.0.0.0 17/aggregate(alpha)

192.168.5.0 10.10.10.25 nolabel/19

Pe_7204vxr>sh ip bgp vpnv4 vrf beta labels

Network Next Hop In label/Out label

Route Distinguisher: 100:2 (beta)

172.31.1.0/29 10.10.10.25 nolabel/20

172.31.2.0/29 0.0.0.0 16/aggregate(beta)

Если теперь злоумышленник сможет читать пакеты (на Рисунке 6 простой ping), то он в состоянии изменить метку, ввести пакеты в сеть заново и таким образом проникнуть в VPN. В результате пакет будет транслироваться устройством в «не ту VPN» (перевод входящего пакета ping устройством в VPN «бета»):

01:55:45.993783 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17408

01:55:45.993815 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17408

01:55:46.995175 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17664

01:55:46.995211 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17664

01:55:47.996723 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17920

01:55:47.996756 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17920

01:59:14.136855 IP 172.31.1.2 > 172.31.2.2: icmp

80: echo request seq 5725

01:59:14.136906 IP 172.31.2.2 > 172.31.1.2: icmp

80: echo reply seq 5725

Таким образом, взломщику удастся проникнуть за пределы виртуальных частных сетей. Однако сначала это работает лишь в одном направлении, и потенциальный ответный трафик снова окажется в VPN «альфа». Впрочем, атакующий может изменить и обратный трафик, построив полноценное двунаправленное соединение между сервером в VPN «бета» и контролируемым им клиентом в VPN «альфа».

Хотя для проведения подобных атак инструментов (пока!) не существует, даже односторонняя инжекция пакетов в виртуальную частную сеть может иметь серьезные последствия. Ее оказывается достаточно, к примеру, для атак на основе SNMP - среди которых есть сброс конфигурационного файла устройства - или для запуска «червей» на основе UDP («черви» SQL).

Такая замена меток не будет замечена системами обнаружения вторжений в VPN «бета», поскольку пакеты попадают туда уже без них и изменение меток (в отличие от изменения IP-адреса) не влечет за собой ошибки вследствие несовпадения контрольных сумм.

VPN ВТОРОГО УРОВНЯ

Под термином «виртуальная частная сеть второго уровня» в контексте MPLS обычно понимается передача произвольного трафика по MPLS (Any Transport over MPLS, AToM). Тогда по магистрали MPLS передаются не пакеты, а целые блоки второго уровня, к примеру ячейки АТМ, кадры Ethernet или frame relay.

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

Но у технологии AToM имеется две модификации, которые представляют особый интерес в рамках разговора о безопасности: Ethernet поверх MPLS (Ethernet over MPLS, EoMPLS) и служба виртуальной частной локальной сети (Virtual Private LAN Service, VPLS).

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

EoMPLS представляет собой двухточечную технологию соединения. Подключение дополнительного филиала предполагает построение от него нового туннеля ко всем уже имеющимся офисам, что ограничивает масштабируемость ЕоMPLS. Именно этот недостаток и должна исправить служба виртуальной частной локальной сети. При ее применении любое количество филиалов образуют общую сеть Ethernet с многоточечными соединениями. При добавлении филиала «псевдопровода» создаются автоматически посредством специальной системы сигнализации - однако необходимая протокольная база еще не специфицирована полностью. Все филиалы соединяются друг с другом «будто бы» напрямую, поэтому облако MPLS/VPLS часто характеризуют как «большой виртуальный коммутатор». Авторы, напротив, предпочитают рассматривать это облако MPLS/VPLS как «большой виртуальный канал» (в представлении Cisco), поскольку устройства VPLS в общем и целом не воспринимаются такими протоколами, как STP, DTP или VTP, для которых они совершенно прозрачны. Пограничными устройствами на стороне клиента в EoMPLS или VPLS чаще всего служат коммутаторы.

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

СВЯЗУЮЩЕЕ ДЕРЕВО

Поскольку разные филиалы образуют теперь общую сеть (Ethernet), на каждую виртуальную сеть выбирается лишь один корень STP (только в одном филиале). При избыточном подключении филиала (к примеру, из соображений повышения готовности) это потенциально ведет к тому, что внутренние каналы филиала между коммутаторами оказываются заблокированными (см. Рисунок 7).

Рисунок 7. Избыточные соединения иногда оказываются открытыми.

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

ВИРТУАЛЬНЫЕ ЛОКАЛЬНЫЕ СЕТИ

Проблемы с безопасностью возникают и в связи с виртуальными локальными сетями. Если, к примеру, в двух филиалах существуют одинаковые номера виртуальных сетей, то эти VLAN после соединения филиалов посредством EoMPLS/VPLS будут «видеть» друг друга. Когда в одном филиале имеется VLAN 10 для серверов, а в другом - VLAN 10 для беспроводной сети, все пользователи беспроводной сети второго филиала будут получать широковещательный трафик Windows первого филиала, и у находящегося в беспроводной сети злоумышленника появится доступ к серверу другого филиала.

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

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

Энно Рей и Петер Фирс занимаются сетевыми протоколами и их безопасностью. Эта статья базируется на докладе Энно Рея на конференции Blackhat 2006.

Ресурсы

Инструменты для проведения атак на MPLS: http://www.irmc.com/tools/irm-mpls-tools-1.0.tar.bz2 .

Майкл Берингер/Моник Морроу: «Безопасность виртуальных частных сетей MPLS» (Индианаполис, 2005).

Статистика взломов маршрутизаторов: http://www.nanog.org/tg-0306/pdf/thomas.pdf .

VPN (Virtual Private Network) - это виртуальная частная сеть или логическая сеть, которая создается поверх незащищённых сетей (сетей оператора связи или сервис-провайдера Интернет). VPN – это технология, которая обеспечивает защиту данных при передаче их по незащищенным сетям. Виртуальная частная сеть позволяет организовать туннель в незащищённых сетях (между двумя точками сети), например в ATM, FR или IP-сетях.

С помощью VPN можно осуществить соединения: сеть-сеть, узел-сеть или узел-узел. Такие свойства технологии VPN предоставляют возможность объединить территориально удаленные друг от друга локальные сети офисов компании в единую корпоративную информационную сеть. Необходимо отметить, что корпоративные вычислительные сети (КВС) можно организовывать и на базе выделенных (частных или арендованных) каналов связи. Такие средства организации используются для небольших КВС (предприятий с компактно расположенными офисами) с неизменяющимся во времени трафиком.

Известны основные виды VPN и их комбинации:

• Intranet VPN (внутрикорпоративные VPN);
• Extranet VPN (межкорпоративные VPN);
• Remote Access VPN (VPN с удаленным доступом);
• Client/Server VPN (VPN между двумя узлами корпоративной сети).

В настоящее время для построения корпоративных территориально распределенных сетей в разделяемой инфраструктуре сервис-провайдеров и операторов связи применяются следующие технологий:

• IP-туннели с использованием технологий GRE или IPSec VPN;
• SSL, к которой относятся OpenVPN и SSL VPN (SSL/TLS VPN) для организации безопасных каналов связи;
• MPLS в сети оператора (L3 VPN) или VPN в сети BGP/MPLS;
• Metro Ethernet VPN в сети оператора (L2 VPN). Наиболее перспективная технология, используемая в Metro Ethernet VPN, - это VPN на базе MPLS (MPLS L2 VPN) или VPLS.

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

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

• модель IP VPN (GRE, IPSec VPN, OpenVPN) через WAN сеть, в которой настройка VPN обеспечивается заказчиком;
• модель L 3 VPN или MPLS L3 VPN через WAN сеть, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи;
• модель L2 VPN через MAN сеть, в которой настройка VPN обеспечивается провайдером или оператором связи:
  • point-to-point (AToM, 802.1Q, L2TPv3);
  • multipoint (VPLS и H-VPLS).

Технологии VPN можно классифицировать и по способам их реализации с помощью протоколов: аутентификации, туннелирования и шифрования IP-пакетов. Например, VPN (IPSec, OpenVPN, PPTP) основаны на шифровании данных заказчиков, VPN (L2TP и MPLS) базируются на разделении потоков данных между заказчиками VPN, а SSL VPN основана на криптографии и аутентификации трафика. Но, как правило, VPN используют смешанные варианты, когда совместно используются технологии: аутентификации, туннелирования и шифрования. В основном организация VPN-сетей осуществляется на основе протоколов канального и сетевого уровней модели OSI.

Необходимо отметить, что для мобильных удаленных пользователей была разработана технология SSL VPN (Secure Socket Layer - уровень защищенных сокетов), которая основана на ином принципе передачи частных данных (данных пользователей) через Интернет. Для организации SSL VPN используется протокол прикладного уровня HTTPS. Для HTTPS используется порт 443, по которому устанавливается соединение с использованием TLS (Transport Layer Security - безопасность транспортного уровня).

TLS и SSL (TLS и SSL- протоколы 6 уровня модели OSI) - это криптографические протоколы, которые обеспечивают надежную защиту данных прикладного уровня, так как используют асимметричную криптографию, симметричное шифрование и коды аутентичности сообщений. Но поскольку в стеке TCP/IP определены 4 уровня, т.е. отсутствуют сеансовый и представительский уровни, то эти протоколы работают над транспортным уровнем в стеке TCP/IP, обеспечивая безопасность передачи данных между узлами сети Интернет.

Модель IP VPN, в которой настройка VPN обеспечивается заказчиком

Модель IP VPN может быть реализована на базе стандарта IPSec или других протоколов VPN (PPTP, L2TP, OpenVPN). В этой модели взаимодействие между маршрутизаторами заказчика устанавливается через WAN сеть сервис-провайдера. В этом случае провайдер не участвует в настройке VPN, а только предоставляет свои незащищённые сети для передачи трафика заказчика. Сети провайдеров предназначены только для инкапсулированного или наложенного (прозрачного) соединения VPN между офисами заказчика.

Настройка VPN осуществляется телекоммуникационными средствами заказчика, т.е. заказчик сам управляет маршрутизацией трафика. VPN соединение – это соединение поверх незащищённой сети типа точка-точка: «VPN шлюз - VPN шлюз» для объединения удаленных локальных сетей офисов, «VPN пользователь - VPN шлюз» для подключения удаленных сотрудников к центральному офису.

Для организации VPN-сети в каждый офис компании устанавливается маршрутизатор, который обеспечивает взаимодействие сети офиса с VPN-сетью. На маршрутизаторы устанавливается программное обеспечение для построения защищённых VPN, например, бесплатный популярный пакет OpenVPN (в этом случае пакет OpenVPN надо сконфигурировать для работы в режиме маршрутизации). Технология OpenVPN основана на SSL стандарте для осуществления безопасных коммуникаций через Интернет.

OpenVPN обеспечивает безопасные соединения на основе 2-го и 3-го уровней OSI. Если OpenVPN сконфигурировать для работы в режиме моста - он обеспечивает безопасные соединения на основе 2 уровня OSI, если в режиме маршрутизации - на основе 3-го уровня. OpenVPN в отличие от SSL VPN не поддерживает доступ к VPN-сети через web-браузер. Для OpenVPN требуется дополнительное приложение (VPN-клиент).

Маршрутизатор головного офиса компании настраивается в качестве VPN-сервера, а маршрутизаторы удаленных офисов в качестве VPN-клиентов. Маршрутизаторы VPN-сервер и VPN-клиенты подключаются к Интернету через сети провайдера. Кроме того, к главному офису можно подключить ПК удаленного пользователя, настроив на ПК программу VPN-клиента. В итоге получаем модель IP VPN (скриншот представлен на рис. 1).

Рис. 1. Модель сети IP VPN (Intranet VPN + Remote Access VPN)

Модель MPLS L3 VPN или L3 VPN, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи (поставщиком услуг)

Рассмотрим процесс организации VPN-сети для трех удаленных локальных сетей офисов заказчика услуг (например, корпорации SC-3), размещенных в различных городах, с помощью магистральной сети MPLS VPN поставщика услуг, построенной на базе технологии MPLS L3 VPN. Кроме того, к сети корпорации SC-3 подключен ПК удаленного рабочего места и ноутбук мобильного пользователя. В модели MPLS L3 VPN оборудование провайдера участвует в маршрутизации клиентского трафика через сеть WAN.

В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к магистральной сети MPLS VPN поставщика услуг осуществляется с помощью технологии IP. Для организации VPN-сети в каждый офис компании устанавливается периферийный или пограничный CE-маршрутизатор (Customer Edge router), который соединяется физическим каналом с одним из пограничных РЕ-маршрутизаторов (Provider Edge router) сети MPLS провайдера (оператора). При этом на физическом канале, соединяющем CE и PE маршрутизаторы, может работать один из протоколов канального уровня (PPP, Ethernet, FDDI, FR, ATM и т.д.).

Сеть поставщика услуг (сервис-провайдера или оператора связи) состоит из периферийных РЕ-маршрутизаторов и опорной сети (ядра сети) с коммутирующими по меткам магистральными маршрутизаторами P (Provider router). Таким образом, MPLS L3 VPN состоит из офисных локальных IP-сетей заказчика и магистральной сети MPLS провайдера (домена MPLS), которая объединяет распределенные локальные сети офисов заказчика в единую сеть.

Удаленные локальные сети офисов заказчика обмениваются IP-пакетами через сеть провайдера MPLS, в которой образуются туннели MPLS для передачи клиентского трафика по опорной сети поставщика. Скриншот модели сети MPLS L3 VPN (Intranet VPN + Remote Access VPN) представлен на рис. 2. С целью упрощения схемы сети приняты следующие начальные условия: все ЛВС офисов относятся к одной VPN, а опорная (магистральная) сеть является доменом MPLS (MPLS domain), находящаяся под единым управлением национального сервис-провайдера (оператора связи).

Необходимо отметить, что MPLS L3 VPN может быть организована с помощью нескольких доменов MPLS разных сервис-провайдеров. На рисунке 2 представлена полносвязная топология VPN.

Рис. 2. Модель сети MPLS L3 VPN (Intranet VPN + Remote Access VPN)

Периферийные маршрутизаторы CE и PE (заказчика и провайдера) обмениваются друг с другом маршрутной информацией одним из внутренних протоколов маршрутизации IGP (RIP, OSPF или IS-IS). В результате обмена маршрутной информацией каждый РЕ-маршрутизатор создает свою отдельную (внешнюю) таблицу маршрутизации VRF (VPN Routing and Forwarding) для локальной сети офиса заказчика, подключенной к нему через CE-маршрутизатор. Таким образом, маршрутная информация, полученная от CE, фиксируется в VRF-таблице PE.

Таблица VRF называется виртуальной таблицей маршрутизации и продвижения. Только РЕ-маршрутизаторы знают о том, что в сети MPLS организована VPN для заказчика. Из модели сети MPLS L3 VPN следует, что между CE-маршрутизаторами заказчика не осуществляется обмен маршрутной информацией, поэтому заказчик не участвует в маршрутизации трафика через магистраль MPLS, настройку VPN (РЕ-маршрутизаторов и Р-маршрутизаторов) осуществляет провайдер (оператор).

К РЕ-маршрутизатору могут быть подключены несколько VPN-сетей разных заказчиков (рис.3). В этом случае на каждый интерфейс (int1, int2 и т.д.) PE-маршрутизатора, к которому подключена локальная сеть офиса заказчика, устанавливается отдельный протокол маршрутизации. Для каждого интерфейса РЕ-маршрутизатора один из протоколов IGP создает таблицу маршрутизации VRF, а каждая таблица маршрутизации VRF соответствует VPN-маршрутам для каждого заказчика.

Например, для заказчика SC-3 и его сети LAN0 (главного офиса), подключенной через CE0 к PE0, на PE0 будет сформирована таблица VRF1 SC-3, для LAN1 заказчика SC-3 на PE1 будет создана VRF2 SC-3, для LAN2 на PE2 - VRF3 SC-3 и т.д., а принадлежат они одной VPN SC3. Таблица VRF1 SC-3 является общей для маршрутной информации CE0 и CE4. Необходимо отметить, что таблицы VRF пополняются информацией об адресах локальных сетей всех других офисов данного заказчика с помощью протокола MP-BGP (multiprotocol BGP). Протокол MP-BGP используется для обмена маршрутами непосредственно между РЕ-маршрутизаторами и может переносить в маршрутной информации адреса VPN-IPv4.

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

Маршрутная информация, которой обмениваются РЕ-маршрутизаторы по протоколу MP-BGP через глобальный или внутренний интерфейс:

• Адрес сети назначения (VPN-IPv4);
• Адрес следующего маршрутизатора для протокола (next hop);
• Метка Lvpn – определяется номером интерфейса (int) РЕ-маршрутизатора, к которому подключена одна из ЛВС офиса заказчика;
• Атрибут сообщения RT (route-target) – это атрибут VPN, который идентифицирует все ЛВС офисов, принадлежащие одной корпоративной сети заказчика или одной VPN.

Рис. 3. РЕ-маршрутизатор

Кроме того, каждый РЕ-маршрутизатор обменивается маршрутной информацией с магистральными P-маршрутизаторами одним из внутренних протоколов маршрутизации (OSPF или IS-IS) и создает также отдельную (внутреннюю) глобальную таблицу маршрутизации (ГТМ) для магистральной сети MPLS. Внешняя (VRF) таблица и внутренняя (ГТМ) глобальная таблицы маршрутизации в РЕ-маршрутизаторах изолированы друг от друга. P-маршрутизаторы обмениваются маршрутной информацией между собой и PЕ-маршрутизаторами с помощью традиционных протоколов внутренней IP-маршрутизации (IGP), например OSPF или IS-IS, и создают свои таблицы маршрутизации.

На основе таблиц маршрутизации с помощью протоколов распределения меток LDP или протоколов RSVP на основе технологии Traffic Engineering строятся таблицы коммутации меток на всех маршрутизаторах P (на PE создаются FTN), образующих определенный маршрут LSP (Label Switched Paths). В результате формируются маршруты с коммутацией по меткам LSP, по которым IP-пакеты продвигаются на основе значений меток заголовка MPLS и локальных таблиц коммутации, а не IP-адресов и таблиц маршрутизации.

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

Необходимо отметить, что PE направляет входной трафик в определенный виртуальный путь LSP на основании FEC (Forwarding Equivalence Class – класса эквивалентности продвижения). FEC – это группа пакетов к условиям, транспортировки которых предъявляются одни и те же требования. Пакеты, принадлежащие одному FEC, перемещаются по одному LSP. Классификация FEC может осуществляться различными способами, например: по IP-адресу сети (префиксу сети) назначения, типу трафика, требованиям инжиниринга и т.д.

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

Таблица 1. FTN (FEC To Next hop) на маршрутизаторе PE1

Из таблицы 1 следует, что значение внешней метки назначает входной маршрутизатор PE1 на основании IP-адреса локальной сети офиса. Внутренняя метка или метка нижнего уровня стека в процессе коммутации пакета по LSP от входного до выходного PE не участвует, а она определяет VRF или интерфейс на выходном PE, к которому присоединена ЛВС офиса заказчика.

Обмен информацией о маршрутах VPN по протоколу MP-BGP

Маршрутная информация (информация о маршрутах VPN), которую передает маршрутизатор PE1 маршрутизатору PE2 по протоколу BGP (красные линии):

• Адрес VPN-IPv4: 46.115.25.1:106:192.168.1.0;
• Next Hop = 46.115.25.1;
• Lvpn=3;
• RT= SC-3.

Различитель маршрутов RD=46.115.25.1:106 добавляется к IPv4-адресу сети LAN1 регионального офиса 1. Где 46.115.25.1 – это IP-адрес глобального интерфейса маршрутизатора PE1, через который PE1 взаимодействует с P-маршрутизаторами. Для данного маршрута VPN SC-3 администратор сети провайдера в маршрутизаторе PE1 или PE1 назначает метку (номер), например 106.

Когда маршрутизатор PE2 получает от PE1 адрес сети назначения VPN-IPv4, он отбрасывает разграничитель маршрутов RD, помещает адрес 192.168.1.0 в таблицу VRF3 SC-3 и отмечает, что запись была сделана протоколом BGP. Кроме того, он объявляет этот маршрут, подключенному к нему маршрутизатору заказчика CE2 для данной VPN SC-3.

Таблица VRF3 SC-3 также пополняется протоколом MP-BGP – об адресах сетей других ЛВС офисов данной VPN SC-3. Маршрутизатор PE1 направляет по протоколу MP-BGP маршрутную информация также другим маршрутизаторам: PE0 и PE3. В итоге, все маршруты в таблицах VRF маршрутизаторов (PE0, PE1, PE2 и PE3) содержат адреса всех сетей ЛВС офисов данного заказчика в формате IPv4.

Рис. 4. Таблицы VRF маршрутизаторов (PE0, PE1, PE2 и PE3)

Маршрутная информация, которую передает маршрутизатор PE2 маршрутизатору PE1 по протоколу MP-BGP (красные линии):

• Адрес VPN-IPv4: 46.115.25.2:116:192.168.2.0;
• Next Hop = 46.115.25.2;
• Lvpn=5;
• RT=SC-3.

Рассмотрим, как происходит обмен данными между ПК 2 (IP: 192.168.1.2) сети LAN1 и ПК 1 (IP: 192.168.3.1) сети LAN. Для доступа к файлам, размещенным в директориях или логических дисках ПК 1 (LAN) с общим доступом, необходимо на ПК 2 (LAN1) в строке "Найти программы и файлы" (для ОС Win 7) ввести \\192.168.3.1 и нажать клавишу Enter. В результате на экране ПК 2 будут отображены директории с общим доступом ("расшаренные" директории или папки), которые размещены на ПК 1. Как это происходит?

При нажатии клавишу Enter в ПК 2 (LAN1) на сетевом уровне сформировался пакет с IP-адресом назначения 192.168.3.1. В первую очередь пакет поступает на маршрутизатор CE1 (рис. 5), который направляет его в соответствии с таблицей маршрутизацией на интерфейс int3 маршрутизатора PE1, так как он является следующим маршрутизатором для доступа к сети 192.168.3.0/24, в которой находятся ПК 1 (LAN ГО) с IP-адресом 192.168.3.1. С интерфейсом int3 связана таблица маршрутизации VRF2 SC-3, поэтому дальнейшее продвижение пакета осуществляется на основе ее параметров.

Как следует из таблицы VRF2 SC-3, следующим маршрутизатором для продвижения пакета к сети 192.168.3/24 является PE0 и эта запись была выполнена протоколом BGP. Кроме того, в таблице указано значение метки Lvpn=2, которая определяет интерфейс выходного маршрутизатора PE0. Отсюда следует, что дальнейшее продвижение пакета к сети 192.168.3/24 определяется параметрами глобальной таблицы маршрутизации ГТМ PE1.

Рис. 5. Передача данных между ПК2 (192.168.1.2) и ПК1 (192.168.3.1) сетей LAN1 и LAN главного офиса КС SC-3

В глобальной таблице (ГТМ PE1) адресу следующего маршрутизатора (NH - Next Hop) PE0 соответствует начальное значение внешней метки L=105, которая определяет путь LSP до PE0. Продвижение пакета по LSP происходит на основании L-метки верхнего уровня стека (L=105). Когда пакет проходит через маршрутизатор P3, а затем через маршрутизатор P1, метка L анализируется и заменяется новыми значениями. После достижения пакетом конечной точки LSP, маршрутизатор PE0 удаляет внешнюю метку L из стека MPLS.

Затем маршрутизатор PE0 извлекает из стека метку нижнего уровня стека Lvpn=2, которая определяет интерфейс int2, к которому присоединен маршрутизатор CE0 локальной сети главного офиса заказчика (LAN ГО). Далее из таблицы (VRF1 SC-3), содержащей все маршруты VPN SC3, маршрутизатор PE0 извлекает запись о значении метки Lvpn=2 и о связанном с ней маршруте к сети 192.168.3/24, который указывает на CE0 в качестве следующего маршрутизатора. Из таблицы следует, что запись о маршруте была помещена в таблицу VRF1 SC-3 протоколом IGP, поэтому путь движения пакета от PE0 до CE0 осуществляется по IP-протоколу.

Дальнейшее движение пакета от CE0 к ПК 1 с IP-адресом 192.168.3.1 осуществляется по MAC-адресу, так как CE0 и ПК 1 (192.168.3.1) находятся в одной ЛВС. После получения пакета-запроса от ПК 2 операционная система компьютера ПК 1 отправит копии своих директорий с общим доступом для ПК 2. Операционная система ПК 2, получив копии директорий с общим доступом от ПК 1, отображает их на экране монитора. Таким образом, через общественные сети MPLS провайдера по виртуальным каналам LSP осуществляется обмен данными между двумя ПК, принадлежащим разным ЛВС офисов одного заказчика.

Что касается подключения удаленного мобильного пользователя к ресурсам территориально распределенной корпоративной сети, то его можно реализовать с помощью одной из технологий Remote Access VPN (Remote Access IPSec VPN и SSL VPN). Необходимо отметить, что технология SSL VPN поддерживает два типа доступа: полный сетевой доступ и clientless. Технология clientless SSL VPN обеспечивает удаленный доступ к сети через стандартный веб-браузер, но в этом случае доступны только сетевые приложения с web-интерфейсом. Технология SSL VPN с полным сетевым доступом, после установки на ПК дополнительного приложения (VPN-клиента) обеспечивает доступ ко всем ресурсам территориально распределенной корпоративной сети.

Как правило, подключение удалённого пользователя к MPLS L3 VPN производится посредством сервера удаленного доступа (RAS), который подключается к одному из PE-маршрутизаторов MPLS сети. В нашем случае мобильный пользователь через сеть доступа (Интернет) подключен с помощью Remote Access IPSec VPN к RAS, который соединен с маршрутизатором PE0. Таким образом, мобильный пользователь через IPSec VPN подключается к своей корпоративной сети (корпорации SC-3), организованной на основе MPLS L3 VPN.

Модель MPLS L2 VPN, в которой настройка VPN обеспечивается провайдером или оператором связи (поставщиком услуг)

Организовать единое информационное пространство в трех офисах (например, корпорации SC-3), расположенных в пределах одного города можно на базе широкополосной Metro Ethernet сети оператора связи (L2 VPN). Одной из услуг сетей Metro Ethernet является организация корпоративных сетей через магистральные сети MAN (сети оператора связи в масштабах города). Для организации Metro Ethernet VPN (L2 VPN) используются различные технологии, например AToM (в основном EoMPLS), 802.1Q, L2TPv3 и так далее, но наиболее перспективной является технология MPLS L2 VPN или VPLS. В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к опорной сети MPLS VPN поставщика услуг осуществляется с помощью технологии второго уровня (Ethernet, Frame Relay или ATM).

Операторы связи предоставляют два типа услуг Ethernet сетей для организации виртуальных частных сетей на втором уровне модели OSI, которые формируются на базе технологии MPLS - это VPWS (Virtual Private Wire Services) и VPLS (Virtual Private LAN Services). Эти VPN строятся на базе псевдоканалов (pseudowire), которые связывают пограничные PE-маршрутизаторы сети провайдера (MPLS domain). Туннели LSP или логические каналы создаются при помощи меток, внутри которых прокладываются псевдоканалы (эмулированные VC) и по этим псевдоканалам передаются пакеты MPLS. VPWS основана на Ethernet over MPLS (EoMPLS). Но в VPLS в отличие от сетей point-to-point (P2P) VPWS организация псевдоканалов осуществляется с помощью многоточечных соединений (P2M).

В VPLS существует два способа установления псевдоканалов между любыми двумя PE, которые входят в состав данной VPLS (с помощью протокола BGP и протокола рассылки меток LDP). Расширенный протокол BGP (MP-BGP) обеспечивает автоматическое определения PE, которые взаимодействуют при построении территориально распределенной ЛВС на основе сервиса VPLS, и сигнализацию меток (vc-labels) виртуальных каналов. Для сигнализации vc-labels можно использовать и расширенный протокол LDP. В этом случае выявление всех PE-маршрутизаторов, которые входят в состав данной VPLS, осуществляется в режиме ручной настройки.

Можно также использовать системы управления, которые автоматизируют поиск и настройку PE устройств для организации VPLS сервисов. Для передачи кадров использует стек меток, верхняя метка предназначена для туннелей LSP, которая используется для достижения выходного PE. Нижняя метка - это метка VC Label, которая используется для демультиплексирования виртуальных каналов (pseudowires), передаваемых внутри одного туннеля. В одном туннеле может быть проложено множество псевдоканалов для разных экземпляров VPLS.

Для каждого экземпляра VPLS на PE создаются отдельные виртуальные коммутаторы VSI. Коммутаторы VSI изучают MAC-адреса и строят таблицы продвижения MPLS-пакетов. На основании данных таблицы продвижения коммутаторы VSI, получив кадры, инкапсулированные в пакеты MPLS, направляют их в псевдоканалы ведущие к пограничным PE, к которым подключены пограничные коммутаторы CE сегментов ЛВС офисов заказчика.

На базе VPWS (point-to-point) можно объединить две подсети офисов корпорации в одиную сеть, с единой сквозной IP-адресацией. VPLS – это технология, которая обеспечивает многоточечные соединения поверх пакетной сетевой инфраструктуры IP/MPLS. VPLS позволяет объединить несколько территориально распределенных локальных сетей офисов корпорации в единую локальную сеть. В этом случае магистральная сеть MPLS сервис-провайдера представляет собой виртуальный Ethernet-коммутатор (L2-коммутатор), который пересылает Ethernet-фреймы между сегментами ЛВС отдельных офисов заказчика. Схема территориально распределенной (в пределах города) локальной сети корпорации представлена на рис. 6.

Рис. 6. Схема территориально распределенной (в пределах города) локальной сети корпорации

Суть концепции VPLS заключается в прозрачной передаче Ethernet-фреймов ПК локальных сетей офисов (сегментов сетей офисов заказчика) заказчика по магистральной сети MPLS провайдера. Пограничными устройствами на стороне заказчика VPLS 1 служат коммутаторы CE0, CE1, CE2, которые соединены с устройствами PE0, PE1, PE2. PE-маршрутизаторы взаимодействуют друг с другом, с целью выявления всех PE, подключенных к VPLS 1. Устройства PE и P строят таблицы маршрутизации, на основе которых создаются каналы LSP и псевдоканалы.

В качестве протоколов сигнализации могут использоваться как BGP, так и LDP. Виртуальные коммутаторы VSI 1 устройств PE0, PE1, PE2 строят таблицы продвижения MPLS-пакетов. Например, VSI 1 устройства PE0 формирует таблицу коммутации, представленную на рис. 6. При поступлении Ethernet-фрейма c одного из ПК сети LAN главного офиса на вход устройства PE0 он инкапсулирует Ethernet-фрейм в MPLS пакет и, используя таблицу коммутации, направляет его в туннель, по которому пакет поступает на выходное устройство PE1.

Для продвижения пакета через MPLS сеть (через псевдоканалы в туннелях LSP) используется стек меток, который состоит из метки туннеля LSP и метки псевдоканала VC Label, например, 15. На выходном устройстве PE1 пакеты MPLS преобразуются в Ethernet-фреймы и направляются на коммутатор С1, к которому подключен ПК назначения с MAC-адресом 90:5C:E7:C8:56:93. В документах RFC 4761 и RFC 4762 подробно изложены методы сигнализации на базе протоколов BGP и LDP для локальных сетей организованных с помощью услуг VPLS.

Список источников информации:

1. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд. / В.Г. Олифер, Н.А. Олифер –СПб. Питер, 2010. – 944 с.

2. Олвейн, Вивек. Структура и реализация современной технологии MPLS.: Пер. с англ. – М. : Издательский дом «Вильямс», 2004. – 480 с.

Сети с коммутацией каналов, сети с коммутацией пакетов

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

• коммутация каналов (circuit switching);

• коммутация пакетов (packet switching).

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

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

Рисунок 1 Инкапсуляция пакетных сервисов в SDH.

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

Особенности сети с коммутацией пакетов

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

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

Задачи, которые стояли перед пакетной (нашем случае - IP ) сетью были со временем успешно решены, но «за все приходится платить».

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

IP -сеть оперирует «пульсирующим» трафиком. Ее основное достоинство в том, что она умеет перераспределять ресурсы между различными сеансами связи. Но, у всего есть физический предел, и без потери пакетов в IP -сети не обходится. Потери пакетов происходят либо из-за переполнения буферов ожидания при больших всплесках трафика, при значениях нагрузки выше пиковой, либо при авариях на сети. Кроме того, IP -сеть не гарантирует того, что пакеты достигнут адресата назначения в том же порядке, в котором они вышли от источника.

Поиски решения проблем сетей передачи данных

В поисках решений, призванных минимизировать или исключить минусы пакетных сетей появились технологии X .25, а затем Frame Relay . Была разработана и долгое время применялась технология ATM . Они были призваны повысить надежность и скорость доставки пакетов в пакетных сетях. Совершенствовались механизмы QoS . Эти усовершенствования решили много проблем. С применением этих технологий качество передачи данных по пакетным сетям стало приемлимым для использования в телефонной связи, при передаче факсов и телекса, банковском секторе, электронной торговле и на транспорте.

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

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

Проблемы сетей с коммутацией каналов

Сеть SDH /SONET является классическим примером сети с коммутацией каналов. И все ее проблемы на сегодняшний день - это типовые проблемы, общие для всех сетей такого типа.

Список основных проблем для сетей такого типа состоит из трех пунктов.

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

Вторая проблема - обязательная задержка перед началом пропуска трафика из-за фазы установления соединения.

Третье - низкая эффективность использования полосы пропускания физической линии связи. Ресурс полосы пропускания выделяется каналу передачи данных на все время его существования. То есть даже в те моменты, когда нет данных для передачи, ресурс сети «занят», закреплен за назначенным ему каналом.

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

Сервис пакетных сетей инкапсулировали в потоки сети SDH , выделяя под пакетную передачу диапазоны от 64 кбит/с до нескольких потоков Е1.

Естественно, эффективность использования ресурса пропускной способности сети падала еще больше. Но, это была «плата за качество связи».

Развитие сервисов

С течением времени новые потребности в области передачи данных формировались в основном в технологиях с пакетной коммутацией. Голосовые и видео сервисы активно освоили пакетные сети, и добились высокого качества при достаточно скромных требованиях в полосе пропускания. Кодеки научились эффективно бороться с задержкой пакетов и джиттером. Бизнес-приложения, получившие широкое применение во всех отраслях промышленности, тоже ориентированы на использование сетей IP . IP - приложения быстро развиваются, и требуют все больше и больше ресурсов транспортной сети. Вслед за потребностями сервисов, пакетные сети перешли к применению высокопроизводительных магистральных линий связи, со скоростями nx 1G , 10G и 40G .Скорости SDH сетей остались на прежнем уровне.

Для предприятий потребителей сети SDH определилась проблема. В количественном отношении, объем информации передаваемый по IP -сетям намного превысил объем информации SDH . Магистральные каналы SDH -сетей стали уступать по производительности абонентским портам IP -сети. Стало физически невозможно пропустить весь пакетный трафик внутри SDH . Немаловажно, что цифровые каналы SDH -сети, при заказе у операторов связи, стоят заметно дороже IP -каналов, и поддерживать связность региональных SDH -сетей с производительными магистральными каналами становится все дороже.

Рисунок 2 Схема сети предприятия с раздельным обслуживанием сервисов.

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

Идея MPLS , наращиваем возможности

Предпосылками для создания такой сети явилась разработка компанией Cisco технологии CEF (Cisco Express Forwarding ) и, основанной на этой технологии, сети MPLS (Multi Protocol Label Switching ).

Сеть MPLS разрабатывалась для передачи различного вида трафика, включая IP -пакеты, ячейки ATM , фреймы SDH и кадры Ethernet . Сама технология MPLS преследует цель ускорить передачу пакетов через устройства маршрутизации. Для этого в рамках одного MPLS- домена, на основании информации протоколов маршрутизации, и таблиц FIB созданных CEF , MPLS формирует таблицу меток (LIB /LFIB ). Эта таблица заполняется для всех интерфейсов, на которых включен MPLS . Таблица LFIB содержит информацию о том, куда направить входящий трафик с каждого из подключенных интерфейсов, и какую операцию выполнить с заголовком меток. С этого момента все операции с пакетами производятся в соответствии с этими таблицами, на уровне коммутации. В прикладном смысле это в разы, а иногда и на порядки ускоряет прием, обработку и отправку пакетов. Теперь для обработки пакета не надо разбирать пакет, получать из него адреса назначения, искать информацию о маршрутах в таблицах маршрутизации. Все манипуляции с трафиком сводятся к тому, чтобы приняв пакет с одного интерфейса сразу отправить его в выходной интерфейс и изменить у него метку MPLS . Со всеми пакетами вошедшими в определенный интерфейс производится одно и то же действие. Эта модель очень напоминает проключение каналов в SDH .

Выделение MPLS -TP

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

Но в то же время, MPLS по ряду причин все еще не устраивала потребителей, чьи требования фокусировались на гарантированной доставке информации и бесперебойности работы. Тому было несколько причин.

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

В 2006 году компания Nortel предложила технологию PBB -TE , затем была предложена концепция T -MPLS . Эти технологии развивались разными институтами, T -MPLS поддерживалась ITU -T , а PBB -TE основывалась на стандартах IEEE . В 2009 году эти ветки объединились в одну концепцию MPLS -TP , за развитие архитектуры MPLS отвечает объединенная рабочая группа инженеров ITU -T и IETF В настоящее время MPLS -TP хорошо документирован, вышли документы RFC 5654 (Requrements of MPLS -TP ), 5921 (A Framework for MPLS in Transport Profile ), 5659 (Architecture for Multu -Segment Pseudowire Emulation Edge -2-Edge ), 5960 (MPLS -TP Data Plane Architecture ). Па рынке появился список вендоров, предлагающих законченные решения, основанные на технологии MPLS -TP . Линейки оборудования есть у Cisco , Olencom , xTran , Nateks и других производителей. На сегодняшний день технология полностью сформировалась, прошла проверку на большом количестве инсталлированных сетей в режиме реального производства.

Что добавил MPLS -TP

Основное отличие MPLS -TP от MPLS -сети является ее близость к SDH идеологии. Из маршрутной информации было исключено влияние динамических протоколов маршрутизации, автоматическое изменение таблиц маршрутизации в момент изменения структуры или состава сети.

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

MPLS -TP состоит из 3-х уровней логических соединений для организации пользовательского канала. Предполагается, что до начала программирования сервисов все приборы сети объединены между собой в некую топологию через высокоскоростные каналы Ethernet .

Первый логический уровень организации сервиса сети MPLS -TP - создание LSP (Label Switched Path ) маршрута коммутируемых меток. Это логическое соединение между двумя узлами сети MPLS -TP . LSP определяет метки и входные/выходные магистральные интерфейсы для доставки трафика от одного узла сети к другому.

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

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

Для обеспечения управления, миллисекундной реакции на аварийные события все уровни организационной иерархии MPLS -TP контролируются протоколами BFD и OAM .

Рисунок 3. Логика организации сервисов в MPLS-TP.

В части управления и мониторинга системы управления MPLS -TP поддерживают аварийные события стандарта SDH в части организации канала, синхронизации и мониторинга состояний линков. Для управления пакетными каналами передачи поддерживаются события стандартов E 802.3ag , Y .1731. Достоинством NMS -систем сетей MPLS -TP является то, что они легко читаются и обслуживаются специалистами, подготовленными для сетей SDH .

Что можно поручить сети MPLS -TP

В итоге, с сетью MPLS -TP мы получили рабочую и проверенную технологию, которая может объединить сервисы пакетной и SDH сетей в одной инфраструктуре. Наработки, которые были реализованы в технологии MPLS -TP , предоставляют пользователям получить на пакетной сети каналы передачи данных по качеству не уступающие каналам SDH . При этом MPLS -TP сеть легко справляется с пиковыми нагрузками, оптимальным образом распределяет физические ресурсы сети между различными сервисами на основании назначенных приоритетов QoS . Умеет обслуживать большое количество сессий нерегулярного трафика, такого как видео, голос или прикладные сервисы (почта, ftp , торренты, задачи бэкапирования).

Основные характеристики сети MPLS-TP :

• Организация двунаправленных каналов по заданным пользователем маршрутам.
• Контроль за состоянием канала передачи данных на всех логических и физических уровнях с помощью протоколов BFD и OAM .
• Отсутствие неопределенностей, связанных с динамической маршрутизацией.
• Управление приоритетами трафика, минимизация очередей.
• Выделение полосы пропускания при организации канала, гарантированный ресурс полосы для всех сервисов.
• Резервирование маршрутов, сервисов и портов.
• Скорости восстановления трафика до 50 ms (требования SDH ).
• Высокоскоростные магистральные интерфейсы (Nx 1G , 10G , 40G ).
• Интерфейсы STM , совместимость с существующими сетями SDH .

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

Поскольку пакетная сеть может поддерживать любые топологии, а не только «кольцо», возможно проектировать сети с связанной и частично связанной топологией, что приводит к дополнительным ресурсам резервирования каналов передачи данных. Идеология управления сетью MPLS -TP легко понятна специалистам, подготовленным для работы с сетями SDH , это исключает необходимость в длительной переподготовке обслуживающего сеть персонала. Сеть MPLS -TP на уровне физических интерфейсов совместима с сетями IP /MPLS , а значит для присоединения сегментов сети предприятия, можно заказывать у операторов связи не дорогостоящие каналы цифровой иерархии, но обычные IP -подключения уровня L 2.

Основные выгоды от внедрения MPLS -TP

В результате внедрения на предприятии магистральной сети технологии MPLS -TP достигаются следующие цели:

• Вместо 2-х различных сетей для IP и SDH сервисов все потребности предприятия обслуживает 1 сеть.
• Повышается управляемость и надежность сети за счет применения новой топологии, расширенных механизмов управления и мониторинга.
• Снижение стоимости владения за счет оптимизации работы обслуживающего персонала сети.
• Снижение платежей за аренду выделенных каналов за счет использования каналов MPLS вместо TDM на магистральных участках сети.