Передача данных с коммутацией по меткам

LSP-управление: Ordered против Independent

Некоторые FEC соответствуют адресным префиксам, которые рассылаются алгоритмом динамической маршрутизации. Начальная установка LSP для этих FEC может быть выполнена двумя способами: независимым управлением LSP (Independent LSP Control) или упорядоченным управлением LSP (Ordered LSP Control).

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

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

Упорядоченное и независимое управление полностью совместимы. Однако если только не все LSR в LSP используют упорядоченное управление, результирующее влияние на поведение сети более существенно, чем в случае независимого управления, так как нельзя быть уверенным, что LSP не будет использован до того, как будет полностью сконфигурирован.

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

Агрегатирование

Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS это может вызвать определенные последствия для набора FEC — в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае в пределах домена MPLS объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC или следует ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, которое само является FEC (внутри некоторого домена), и применения меток для трафика в объединении называется агрегатированием. Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.

Данный набор FEC, который является агрегатируемым в одном FEC, можно (a) агрегатировать в один FEC, (b) агрегатировать в набор FEC или (c) не агрегатировать совсем. Таким образом, мы можем говорить о гранулярности агрегатирования, начиная с (a) грубой гранулярности и кончая (c) тонкой гранулярностью.

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

Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.

Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. В этой ситуации, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru. Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение, делать это или нет, является исключительно локальным.

Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m ), имеется два варианта.

• Можно принять более тонкий уровень гранулярности для Rd. Это потребовало бы отзыва разосланных m и рассылки n меток. Это предпочтительная опция.
• Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора и если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.

В любом случае, каждый LSR должен знать (при конфигурации), какую гранулярность применять для формируемых меток. Когда используется упорядоченное управление, требуется, чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления наилучший результат может быть получен путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой, как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").

Выбор маршрута

Выбор маршрута сопряжен с методом, используемым при выборе LSP для определенного FEC. Предлагаемая архитектура протокола MPLS поддерживает две опции выбора маршрута: (1) маршрутизация шаг-за-шагом и (2) явная маршрутизация.

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

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

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

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

Отсутствие выходной метки

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

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

• Если пакет попадает в LSP, маршрутизируемый явно, это может привести к образованию петель.
• Заголовок пакета сетевого уровня не может содержать достаточно информации, чтобы позволить данному конкретному LSR переадресовать пакет корректно.

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

Время жизни (TTL)

При традиционной IP-переадресации каждый пакет имеет в заголовке значение поля TTL (Time To Live). Когда бы пакет ни проходил через маршрутизатор, его TTL уменьшается на 1. Если TTL достигает 0 прежде, чем пакет достигнет места назначения, он отбрасывается.

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

(i) TTL как способ подавления зацикливания;

(ii) TTL как метод реализации других функций, например, ограничения области распространения пакета.

Когда пакет движется по LSP, он должен появляться с тем же значением TTL, которое он имел бы, если бы проходил через ту же последовательность маршрутизаторов, без коммутации меток. Если пакет проходит через иерархию LSP, полное число пройденных шагов-LSR должно быть отражено в его значении TTL.

Способ, которым обрабатывается поле TTL, может варьироваться в зависимости от того, размещены ли значения меток MPLS в прослойке между заголовками [MPLS-SHIM] или метки MPLS транспортируются в заголовке L2, таком, как заголовок ATM [MPLS-ATM] или Frame Relay [MPLSFRMRLY].

Если значения меток вставлены в прослойку, которая размещается между канальным и сетевым заголовками, тогда эта прослойка должна иметь поле TTL, которое должно заполняться так же, как аналогичное поле заголовка сетевого уровня, декрементироваться при каждом шаге LSR и копироваться в TTL-поле заголовка сетевого уровня, когда пакет покидает LSP.

Если значения меток записаны в заголовке канального уровня (например, поле VPI/VCI в заголовке AAL5 ATM), помеченные пакеты переадресуются переключателем уровня L2 (например, ATM-переключателем), а канальный уровень сам не имеет поля TTL, тогда будет невозможно декрементировать TTL при каждом шаге LSR. Сегмент LSP, который состоит из последовательности LSR, не способных декрементировать TTL пакетов, будет называться сегментом non-TTL LSP.

Когда пакет выходит из сегмента non-TTL LSP, он должен получить TTL, отвечающее числу шагов LSR, которые он проходит. В уникастном случае это может быть достигнуто путем транспортировки длины LSP входным узлам, позволяя входным устройствам декрементировать значение TTL прежде, чем переадресовывать пакеты в non-TTL LSP сегмент.

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

Контроль петель

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

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

Даже в случае хорошего доступа к буферу, целесообразно иметь некоторые средства детектирования петель, которые имеют длину больше определенной. Кроме того, даже когда TTL и/или справедливая организация очередей в виртуальных каналах предоставляет возможности для сохранения петель, может быть желательно по возможности избегать установления LSP с петлями. Все LSR, которые могут быть связаны с сегментами nonTTL LSP, будут должны поддерживать общую методику детектирования петель; однако использование детектирования петель является опционным. Методика детектирования петель специфицирована в [MPLSATM] и [MPLSLDP].

Кодирование меток

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

MPLS-специфичное оборудование и/или программное обеспечение

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

MPLS-инкапсуляция будет, в свою очередь, инкапсулирована с привлечением протокола канального уровня. Общая MPLS-инкапсуляция специфицирована в [MPLSSHIM].

ATM-коммутаторы в качестве LSR

Процедуры переадресации MPLS подобны тем, что применяются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (crossconnect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства ATM-LSR. Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно работать с AAL5).

1. SVC-кодирование

   Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может применяться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды push или pop для стека меток.
2. SVP-кодирование

   Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI — для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей: здесь возможно переключение виртуальных каналов с помощью ATM VPswitching. То есть, LSP реализуются как ATM SVP.

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

   Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию pop.
3. Многоточечное кодирование SVP

   Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, — часть поля VCI, остальная часть поля VCI служит для идентификации входа LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Можно осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но не имеющих возможностей объединения VC.

   Эта методика зависит от того, можно ли присвоить 16-битовые значения VCI каждому ATM-коммутатору так, что ни одно значение VCI не будет соответствовать двум разным коммутаторам.

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

Совместимость методов кодирования

Если <R1, R2, R3> является сегментом LSP, возможно, что R1 будет использовать одно представление стека меток при передачи пакета P в R2 — но R2 будет использовать другое представление при передаче пакета P в R3.

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

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

К сожалению, ATM-коммутаторы не имеют возможности осуществлять преобразование из одного представления стека меток в другое. Архитектура MPLS требует, чтобы, когда два ATM-коммутатора оказываются последовательными LSR на уровне m LSP, эти два ATM-коммутатора использовали одно и то же представление стека меток.

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

Объединение меток

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

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

Когда некоторый LSR не может выполнить объединение меток, тогда, если два пакета в одном и том же FEC приходят с разными входными метками, они должны быть переадресованы с разными выходными метками. При объединении меток число выходных меток на один FEC должно быть равно 1. Без объединения меток число выходных меток на один FEC может равняться числу узлов в сети.

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

Архитектура MPLS приспосабливает как объединяющие, так и не объединяющие LSR, но допускает также возможность, что имеются LSR, не поддерживающие коммутацию меток.

Не объединяющие LSR

Процедура переадресации MPLS очень схожа с используемой в ATM и Frame Relay. То есть, приходит блок данных, отыскивается метка в коммутационной таблице (VPI/VCI или DLCI), на основе результата поиска выбирается выходной порт, а значение метки переписывается.

В действительности, можно использовать такие технологии для переадресации MPLS. Протокол рассылки меток может быть использован в качестве сигнального протокола для формирования коммутационных таблиц. К сожалению, эти технологии не обязательно поддерживают возможности объединения меток. В ATM, если попытаться осуществить объединение меток, в результате можно получить перекрытие ячеек от различных пакетов. Если ячейки от разных пакетов оказываются перекрытыми, невозможно осуществить сборку пакетов. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на своих внутренних шинах (backplane). Эти коммутаторы могут также быть неспособными поддерживать объединение меток, по той же причине: ячейки разных пакетов могут перекрываться и сборка исходных пакетов станет невозможной.

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

Так как MPLS поддерживает объединяющие и не объединяющие LSR, MPLS содержит также процедуры, которые гарантируют корректное взаимодействие такого оборудования и программ.

Метки для объединяющих и не объединяющих LSR

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

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

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

Объединение потоков в ATM. Методы исключения перекрытия ячеек

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

1. Объединение VP, использующее мультиточечное представление SVP

   Когда применяется объединение VP, несколько виртуальных путей объединяются в один путь, но пакеты от разных отправителей отличаются разными VCI в пределах данного VP.
2. Объединение VC

   Когда используется объединение VC, коммутаторы должны буферизовать ячейки пакета до тех пор, пока не будет принят весь пакет (это может быть определено путем просмотра индикатора конца кадра для AAL5).

Объединение VP имеет преимущество в том, что оно совместимо с подавляющим числом реализаций ATM-коммутаторов. Благодаря этому, объединение VP может с большей вероятностью использоваться в существующих сетях. В отличие от объединения VC, объединение VP не приводит к каким-либо задержкам в точках объединения, а также не накладывает никаких требований на буферы, — однако требует координации пространства VCI в пределах VP. Существует несколько способов реализации этого требования.

Компромисс между совместимостью с существующим оборудованием, сложностью протокола и масштабируемостью предполагает, что желательна поддержка протоколом MPLS объединения как VP, так и VC. Для того, чтобы реализовать это, каждый ATM-коммутатор, участвующий в MPLS, должен знать, могут ли ближайшие ATM соседи осуществлять объединение VP или VC.

Взаимодействие: объединение VC, объединение VP и отсутствие объединения

Взаимодействие различных форм объединения в ATM наиболее просто описать на примере взаимодействия систем с объединением VC и без него.

В случае, когда соединены узлы, поддерживающие и не поддерживающие объединение VC, переадресация ячеек базируется во всех вариантах на VC (т.e., на соединении VPI и VCI). Для каждого вышестоящего узла, осуществляющего объединение VC, нужен только один набор VPI/VCI (это сходно с требованиями для одиночной метки в случае работы в среде кадров). Если вышестоящий сосед не может осуществлять объединение, то он будет требовать одного VPI/VCI на поток для себя плюс достаточное число VPI/VCI, чтобы осуществить передачу вышестоящему соседу. Необходимое число будет определено путем разрешения вышестоящим узлам посылать запросы дополнительных VPI/VCI своим нижестоящим соседям.

Аналогично можно поддержать узлы, которые выполняют объединение VP. В этом случае объединяющий VP узел, вместо посылки запроса одного или нескольких VPI/VCI нижестоящему соседу, может запросить один VP (идентифицируемый посредством VPI), но несколько VCI в пределах VP. Кроме того, предположим, что узел, не поддерживающий объединение, расположен ниже по отношению к двум другим узлам VP. Этот узел может нуждаться в запросе одного VPI/VCI (для трафика, исходящего именно из этого узла) плюс два VP (по одному для каждого вышестоящего узла), ассоциированные со специфицированными наборами VCI (в соответствии с запросом от вышестоящего узла).

Чтобы поддерживать узлы, объединяющие и не объединяющие VP и VC, необходимо разрешить вышестоящим узлам запрашивать комбинацию из нуля или более идентификаторов VC (состоящих из VPI/VCI) плюс нуль или более VP (идентифицируемых VPI), каждый из которых содержит специфицированное число VC (идентифицированное набором VCI, которые работают в пределах VP). Узлы, объединяющие VP, затребовали бы один VP, содержащий VCI, для исходящего трафика (если таковой имеется) плюс VCI для каждого VC, запрошенного свыше (вне зависимости от того, является или нет VC частью, содержащей VP). Узлы, объединяющие VC, затребовали бы только один VPI/VCI (так как они могут объединить весь трафик от вышестоящих узлов в один VC). Узлы, не поддерживающие объединение, передали бы любые запросы, полученные сверху, плюс запрос VPI/VCI для трафика, генерируемого ими самими (если таковой имеется).

Туннели и иерархия

Иногда маршрутизатор Ru предпринимает действия, чтобы доставить определенный пакет другому маршрутизатору Rd, даже если Ru и Rd не являются смежными углами на пути пакета, а Rd не является местом назначения пакета. Это может быть сделано, например, путем инкапсуляции пакета в пакет сетевого уровня, местом назначения которого является Rd. Так создается туннель от Ru к Rd .

Если туннелированный пакет следует маршрутом шаг-за-шагом от Ru к Rd , мы говорим, что это "туннель, маршрутизированный шаг-за-шагом", чье начало находится в Ru и чьим концом является Rd.

Если туннелированный пакет транспортируется из Ru в Rd по пути, отличному от маршрута шаг-за-шагом, мы говорим, что это туннель, маршрутизированный явно с начальной точкой в Ru и конечной — в Rd. Например, мы можем послать пакет через туннель, маршрутизированный явно, путем инкапсуляции его в пакет, маршрутизируемый отправителем.

Имеется возможность реализовать туннель в виде LSP и использовать коммутацию меток, а не инкапсуляцию сетевого уровня, чтобы заставить пакет идти через туннель. Туннель будет иметь вид LSP <R1, ..., Rn >, где R1 является началом туннеля, а Rn — его концом. Это называется LSP-туннелем.

Набор пакетов, которые посланы через LSP-туннель, представляет FEC, а каждый LSR в туннеле должен установить ассоциацию между меткой и FEC (т.e., нужно присвоить туннелю определенную метку). Критерий установления соответствия пакета LSP-туннелю является внутренним вопросом начальной точки туннеля. Чтобы направить пакет в LSP-туннель, передающий конец туннеля вводит метку туннеля в стек и посылает помеченный пакет узлу следующего шага туннеля.

Если для конечной точки туннеля не нужно определять, какой пакет получен через туннель, как это обсуждалось выше, то стек меток может быть очищен на предпоследнем LSR туннеля.

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

Иерархия: LSP туннели в LSP

Рассмотрим LSP <R1, R2, R3, R4>. Предположим, что R1 получил непомеченный пакет P и заносит метку в его стек, чтобы пакет следовал заданным путем шаг-за-шагом. Предположим далее, что R2 и R3 не связаны непосредственно, но являются виртуальными соседями, так как представляют собой конечные точки LSP-туннеля. Итак, действительная последовательность LSR, через которые проходит P, соответствует <R1, R2, R21, R22, R23, R3, R4>. Когда P транспортируется из R1 в R2, он имеет глубину стека, равную 1. R2, коммутирующий метки, определяет, что P должен войти в туннель. R2 сначала замещает входную метку меткой, имеющей смысл для R3, и затем заносит ее в стек. Эта метка второго уровня имеет значение, понятное R21. Коммутация осуществляется для метки на уровне 2 устройствами R21, R22, R23. R23, который является предпоследним узлом в туннеле R2-R3, удаляет метку из стека до того, как будет выполнена переадресация пакета в R3. Когда R3 видит пакет P, P имеет только метку уровня 1 — и покидает ту ннель. Так как R3 является предпоследним шагом P в LSP, он удаляет метку из стека, а R4 получает P непомеченным. Механизм стека меток допускает любую глубину вложения LSP-туннелей.

Иерархия и партнерство в рассылке меток

Предположим, что пакет P транспортируется на уровне 1 LSP <R1, R 2, R3, R4> и при транспортировке из R2 в R3 движется по LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделе "LSP-туннелирование между пограничными BGP маршрутизаторами" рассмотрены некоторые способы реализации этой иерархии.Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются.

Когда два LSR являются соседними IGP, мы называем их локальными партнерами рассылки меток. Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их удаленными партнерами рассылки меток. В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток.

Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering).

Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это делается одним из двух способов.

1. Явное партнерство

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

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

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