Метки и механизмы MPLS

Рассмотрены структура метки, стек меток, инкапсуляция меток, режимы операции с метками.

Метка

Метка представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 4.7.

Запись меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно – последним. Сетевой заголовок следует сразу за записью стека меток с битом S=1 . Каждая запись стека меток содержит в себе следующие поля.

Дно стека (S)Является средством поддержки иерархической структуры стека меток MPLS. В заголовке последней (т. е. самой глубокой или нижней) метки бит S=1, а во всех остальных метках в стеке бит S=0. Подробнее стек меток рассматривается ниже.

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

Рис. 4.7. Формат записи стека меток

Экспериментальное поле (CoS)Это 3-битовое поле зарезервировано для экспериментальных целей ( QoS ). В настоящее время проводится работа на создание согласованного стандарта использования этих битов для поддержки дифференцированного обслуживания разнотипного трафика и идентификации класса обслуживания. Первоначально это поле так и называлось – "Класс обслуживания" (CoS), и это название до сих пор широко распространено. При предоставлении дифференцированных услуг MPSL-сети это поле может указывать определенный класс обслуживания, например аналогичный классам DiffServ.

Значение меткиЭто 20-битовое поле несет в себе код метки. Может быть любым числом в диапазоне от 0 до 220- 1, за исключением резервных значений (0, 1, 2, 3 и др.), определением использования которых занимается рабочая группа MPLS в составе комитета IETF.

Когда получен помеченный пакет, анализируется значение метки наверху стека. В результате этого анализа определяется:

следующий шаг, куда должен быть переадресован пакет;

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

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

Существует несколько зарезервированных значений меток.

Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен и переадресация пакета должна основываться на IPv4-заголовке.

Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток, за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставляется локальному модулю для обработки. Действительная переадресация пакета определяется меткой в его стеке. Однако если пакет переадресовывается дальше, еще до переадресации в стек должна быть занесена метка "Router Alert". Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.

Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.

Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую и эта новая метка является "Implicit NULL", LSR очистит стек, вместо того чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.

Значения 4–15 зарезервированы.

Стек меток MPLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.10. 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 октета. Формат представлен на рис. 4.11.

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

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

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

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

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

Рис. 4.12. Формат для введения 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 представлен в таблице 4.6.

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

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

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.