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

До сих пор необходимые многим приложениям дифференцированные услуги и гарантии предоставляли только сети с коммутацией каналов. Однако с появлением технологии многопротокольной коммутации с заменой меток (Multiprotocol Label Switching, MPLS) ситуация должна измениться. MPLS позволяет поддерживать все упомянутые приложения в сети IP без необходимости вводить в значительных областях сети иные транспортные механизмы, протоколы маршрутизации и планы адресации. (Основные преимущества MPLS кратко суммируются во врезке «Семь причин отказаться от коммутации каналов».)

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

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

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

Часть MP в сокращении MPLS достаточно легко понять: она просто означает, что протокол может транспортировать множество других протоколов. Другими словами, MPLS — это инкапсулирующий протокол. Часть LS в аббревиатуре означает, что транспортируемые протоколы инкапсулируются с помощью метки, изменяемой на каждом транзитном узле.

Метки не являются чем-то новым. ATM, frame relay, X.25 и, до некоторой степени, TDM используют инкапсуляцию с помощью меток в течение многих лет. Однако MPLS реализует концепцию в общем, т. е. метки не привязаны к какой-либо конкретной технологии второго уровня.

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

Сильной стороной MPLS является то, что ATM-подобная концепция реализована в ней в обобщенном виде. MPLS позволяет переадресовать кадр из канала второго уровня любого типа в канал второго уровня любого другого типа независимо от конкретного управляющего протокола. Для сравнения, ATM позволяет коммутировать ячейки только между каналами ATM и использовать только сигнальные протоколы ATM, такие, как Private Network-to-Network Interface (PNNI) и Interim Interface Signaling Protocol (IISP).

Рабочая группа IETF MPLS решила, что всегда, когда возможно, MPLS должна задействовать имеющиеся форматы меток. По этой причине MPLS поддерживает три различных типа меток: на оборудовании ATM она использует метки идентификаторов виртуального канала (Virtual Circuit Identifier, VCI) и виртуального пути (Virtual Path Identifier, VPI); на оборудовании frame relay — метку идентификатора соединения канального уровня (Data Link Connection Identifier, DLCI); во всех остальных случаях MPLS использует новую общую метку, называемую прокладкой (Shim), которая вставляется между вторым и третьим уровнями (см. Рисунок 2).

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

MPLS-совместимый маршрутизатор, также называемый маршрутизатором с коммутацией меток (Label Switching Router, LSR), должен уметь принимать пакет со вставленной меткой на любом своем интерфейсе, отыскивать ее в таблице коммутации, вставлять новую метку в соответствующем формате и затем отправлять пакет через соответствующий интерфейс. Другими словами, LSR может коммутировать пакет с меткой с любого интерфейса на любой другой интерфейс с заменой метки. Этот подход гораздо гибче, чем в случае ATM, так как он не ограничен исключительно каналами передачи ячеек.

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

Благодаря тому, что MPLS позволяет иметь стеки с любым числом меток, она может поддерживать такие приложения, как VPN через туннель или вложенные туннели. Для сравнения, ATM предусматривает только два уровня меток — VPI и VCI.

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

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

После открытия туннеля LSP маршрутизатор на границе домена MPLS (Label Edge Router, LER) направляет трафик вдоль LSP посредством выполнения одной операции маршрутизации. Следующий транзитный пункт к адресату определяется на основании первой метки и канала LSP.

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

MPLS использует классы эквивалентной переадресации (Forwarding Equivalence Class, FEC), благодаря которым протокол может отображать трафик на LSP несколькими способами. Два пакета считаются принадлежащими к одному и тому же классу FEC, если они помещаются на один и тот же путь LSP. MPLS поддерживает отображения в соответствии с префиксами IP-адреса произвольной длины или полными 32-разрядными IP-адресами хостов. Более сложные преобразования позволяют осуществлять протоколы управления с явным образом задаваемой маршрутизацией, такие, как маршрутизируемый протокол распространения меток с маршрутизацией с учетом ограничений (Constraint-based Routed Label Distribution Protocol, CR-LDP) и расширенный протокол RSVP (Extended RSVP). Это достигается за счет того, что отображения осуществляются локально внутри маршрутизатора или коммутатора и поэтому могут не приниматься во внимание другими маршрутизаторами или коммутаторами вдоль контролируемого пути.

В случае протокола распространения меток (Label Distribution Protocol, LDP) и CR-LDP все начинается с обнаружения соседей с помощью пакета приветствия UDP. Получив такой пакет, протокол LDP/CR-LDP на другом устройстве посылает в ответ пакет приветствия UDP; в этот момент стороны открывают между собой коммуникационный канал TCP/IP для обслуживания данного конкретного пространства меток. Затем два соседа обмениваются информацией для инициализации, в том числе о желательной версии протокола, режимах функционирования, продолжительности тайм-аутов, диапазонах меток и поддерживаемых типах.

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

LDP предназначен главным образом для дублирования деревьев маршрутизации до получателя, которые IP использует для целей доставки пакетов. LDP преобразует эти деревья в деревья коммутации меток. OSPF, RIP и IS-IS вычисляют и распространяют дерево выбора кратчайшего пути (Shortest Path First, SPF) до данного адресата от любого источника. Как бы это дерево ни вычислялось, оно копируется LDP, и протокол выделяет метку для канала до данного адресата. Эта процедура повторяется для каждого канала в дереве SPF. В точках дерева, где ветви сходятся, метки объединяются.

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

Любой пакет, отправленный вдоль LSP, попадет к адресату вне зависимости от протокола — отсюда определение «многопротокольный» в MPLS. Как правило, инкапсулируемым протоколом является IP, хотя адреса в заголовке IP могут иметь смысл, а могут и не иметь смысла для промежуточных LSR, так как эти адреса могут быть внутренними. Вследствие наличия этой функции туннелирования многие производители рассматривают MPLS в качестве одного из архитектурных элементов VPN.

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

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

Наиболее полезный из этих режимов LDP, Down-Stream-On-Demand, предполагает выделение метки только при получении запроса, но на этот запрос он отвечает только при получении метки от следующего соседа вдоль пути к адресату. Эти запросы могут объединяться с выполненными или отложенными запросами в обратном направлении.

В режиме Down-Stream-On-Demand протокол LDP функционирует как ATM. Однако, в отличие от маршрутизации от источника в ATM, протокол LDP может только следовать таблицам переадресации IP. Для преодоления этого недостатка было предложено расширение LDP — CR-LDP.

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

Единственное, чего не хватает протоколу CR-LDP, — это способа динамического вычисления явно задаваемых маршрутов. Неудивительно, что механизмы для поддержки данной функции проходят процедуру стандартизации. Как рекомендуется в имеющихся проектах, сведения о динамическом резервировании пропускной способности должны включаться в широковещательную информацию OSPF и IS-IS или объявления о состоянии каналов (Link State Advertisement, LSA).

При наличии таких механизмов CR-LDP может занимать и резервировать пропускную способность в соответствии с доступной пропускной способностью. Величина доступной пропускной способности изменяется в соответствии с запросом, и ее новое значение рассылается другим узлам с помощью расширений OSPF/IS-IS. Новые маршруты затем можно вычислить с помощью модифицированного алгоритма Дейкстры с учетом принятых ограничений, таких, как доступная пропускная способность; в результате протокол CR-LDP получает в свое распоряжение явный маршрут для прокладывания реального пути LSP. Путь создается посредством отправки запроса о предоставлении метки, содержащего динамически вычисляемый явный маршрут.

Возможности резервирования пропускной способности в CR-LDP очень схожи с имеющимися в ATM. Однако обращение с пакетами в CR-LDP ближе к DiffServ, чем к PNNI, — они определяют не сквозной сервис, а серию различных операций с пакетами; в сочетании с обработкой на границе эти операции и составляют сервис. Например, ATM позволяет сигнализировать о предоставлении сервиса с постоянной (Constant Bit Rate, CBR) или переменной (Variable Bit Rate, VBR) скоростью. В случае CR-LDP один параметр трафика сообщает о том, насколько срочным является пакет, в то время как другой, независимый параметр указывает на приоритет обслуживания LSP. Как следствие, CR-LDP рассматривает срочность и важность как различные, несвязанные концепции. В сети же ATM срочный пакет всегда является важным.

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

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

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

ITU уже сделала первый шаг в этом направлении. На сентябрьском заседании в Женеве ITU-T SG13 (ведущая группа ITU в области IP) приняла CR-LDP в качестве основного протокола управления MPLS для передачи IP поверх ATM. Это решение должно сыграть ключевую роль в принятии MPLS в качестве основной технологии передачи IP поверх ATM. Кроме того, оно служит свидетельством того, что во всем мире провайдеры услуг и операторы отдают предпочтение масштабируемости, обеспечиваемой CR-LDP.

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

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

В сетях многих операторов IP накладывается на ATM, для чего требуются новый адресный план на базе узлов доступа к сетевым сервисам (Network Service Access Point) и введение множества постоянных виртуальных каналов (Permanent Virtual Circuit, PVC) через облако ATM. Что касается маршрутизаторов, то для них облака ATM как бы не существует — они просто воспринимают его как средство соединения с другими маршрутизаторами. Несмотря на множество преимуществ такого подхода, MPLS идет еще дальше.

MPLS предполагает наделение устройств ATM функциями маршрутизаторов и таким образом, по сути, превращает их в маршрутизаторы, осуществляющие также коммутацию. Такие устройства называются ATM LSR. Мы вполне можем ожидать появления и других MPLS-совместимых мультисервисных коммутаторов, так как MPLS помимо ATM поддерживает и другие интерфейсы, в том числе frame relay, Ethernet и PPP. Эти устройства смогут сосуществовать со специализированными ATM LSR и тем самым обеспечить плавный переход от наложенных сетей поверх ATM. Имеющиеся устройства ATM могут быть дополнены MPLS, в результате чего другие мультисервисные устройства смогут взаимодействовать как маршрутизаторы и коммутаторы с использованием одного адресного плана на базе IP.

Во время перехода к MPLS сетевые технологии и адресацию ATM ликвидировать не потребуется. Наоборот, две системы могут сосуществовать на одних и тех же интерфейсах при использовании простой политики выделения виртуальных каналов (Virtual Circuit, VC). В частности, свободный пул VC с политикой по принципу «первым пришел, первым обслужен» вполне подойдет, но механизмы могут быть и более сложными, например обеспечивать справедливое распределение пулов виртуальных канальных соединений (Virtual Channel Connection, VCC) и пропускной способности. Возможно, что PNNI будет интегрирован с LDP/CR-LDP; разговоры ведутся даже о предоставлении сервисов ATM и frame relay на основе MPLS.

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

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

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

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

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

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

Другие новшества направлены на решение проблем маршрутизации с учетом ограничений через границы автономных систем (Autonomous System, AS). В настоящее время они пронизываются туннелями CR-LDP или RSVP, но с потерей преимущества динамического вычисления пути по обеим сторонам AS. Это связано с тем, что в целях транспортировки информации о пропускной способности через сеть имеющиеся протоколы используют OSPF и IS-IS, но за пределы AS данная информация не передается.

Питер Эшвуд-Смит, Билель Джамаусси и Дон Федик — ведущие технические специалисты по разработкам в области MPLS в Nortel Networks. С ними можно связаться по адресам: petera@nortelnetworks.com, jamoussi@nortelnetworks.com и dwfedyk@nortelnetworks.com, соответственно.

До сих пор только сети с коммутацией каналов могли предоставлять качество обслуживания, гарантированную пропускную способность и надежность, столь необходимые многим высококритичным современным приложениям. Но с появлением многопротокольной коммутации с заменой меток (Multiprotocol Label Switching, MPLS) ситуация изменилась, так как эта технология позволяет предоставить сравнимый уровень сервиса в сетях IP. Ниже мы приводим семь возражений против реализации MPLS и их опровержения.

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

2. Голос и видео наилучшим образом поддерживаются именно транспортом с коммутацией каналов, потому что он сводит к минимуму вариацию задержки. MPLS должен позволить упростить контроль за качеством передачи аудио и видео за счет определения надлежащего обслуживания чувствительного к задержкам трафика на транзитных узлах. Вдобавок возможности резервирования и динамического размещения протокола распространения меток с учетом ограничений (Constraint-based Label Distribution Protocol, CR-LDP) должны помочь держать этот потенциально опасный трафик под контролем (для сравнения, передача видео на базе UDP способна внести настоящий хаос в другой трафик при отсутствии надлежащего контроля).

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

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

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

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

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