RFC: 3031
Оригинал: Multiprotocol Label Switching Architecture
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Мельников Дмитрий Анатольевич

Оглавление

2. Введение в MPLS

Этот стандарт определяет архитектуру многопротокольной коммутации на основе маркеров потока (Multiprotocol Label Switching — MPLS). Данный стандарт не рассматривает системы с групповой адресаций (multicast).

2.1. Общие вопросы

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

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

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

В MPLS-системах «отнесение» соответствующего IP-пакета к определённому FEC-классу выполняется только один раз, т.е. сразу после того, как IP-пакет поступил в сеть. FEC-класс, к которому был «приписан» IP-пакет, кодируется с помощью величины, имеющей небольшой фиксированный размер (длину), который именуется как «маркер потока» (или просто «маркер»). Когда IP-пакет доставляется на следующий ретрансляционный участок, то маркер передаётся вместе с ним. Т.е. IP-пакеты помечаются (маркируются) ещё до начала их доставки.

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

Парадигмой доставки данных в MPLS-системах является то, что после «приписки» IP-пакета к FEC-классу все последующие маршрутизаторы больше не обрабатывают IP-заголовок. Вся доставка осуществляется на основе маркеров. Такой способ обладает рядом следующих преимуществ по сравнению с обычной доставкой данных (коммутацией пакетов на сетевом уровне):

  • Доставка данных в MPLS-системах может быть осуществлена с помощью коммутаторов, которые способны проанализировать и обновить (заменить) поступивший маркер, но которые, либо вообще не способны анализировать IP-заголовки (заголовки сетевого уровня), либо не способны анализировать IP-заголовки (заголовки сетевого уровня) с необходимой скоростью обработки.

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

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

  • Анализ, на основе которого определяется FEC-класс IP-пакета, может становиться всё более и более сложным, но без каких-либо последствий для всех тех маршрутизаторов, которые доставляют только маркированные IP-пакеты.

  • Иногда весьма желательно «принуждать» IP-пакет следовать по соответствующему маршруту, который был однозначно выбран в момент поступления IP-пакета в сеть или раньше, точнее ещё до того, как стандартный алгоритм динамической маршрутизации «сделает свой выбор» относительно продвижения IP-пакета по сети. Такое решение может основываться на положениях сетевой политики (например, доставки или безопасности), либо зависеть от стратегии управления потоками (трафиком) в сети. При стандартной коммутации и доставке IP-пакетов это означает, что IP-пакет должен быть снабжён кодом, определяющим его маршрут доставки (так называемый «маршрут, определяемый источником»). При MPLS-коммутации маркер потока может использоваться для указания маршрута, и при этом нет необходимости указывать в IP-пакете УИД точного маршрута доставки.

Некоторые маршрутизаторы анализируют IP-заголовок (заголовок сетевого уровня) не только для определения следующего ретрансляционного участка доставки пакета, но и для определения приоритета (precedence) или категории обслуживания (class of service) IP-пакета. Более того, они могут использовать различные правила обслуживания или пороговые значения для уничтожения разных IP-пакетов. MPLS-системы позволяют (но не требуют) определять приоритет или категорию обслуживания IP-пакета полностью или частично из самого маркера потока. В этом случае говорят, что маркер потока представляет собой сочетание FEC-класса и приоритет или категорию обслуживания IP-пакета.

Аббревиатура «MPLS» означает «Multiprotocol Label Switching» — многопротокольная коммутация на основе маркеров потока. Термин «многопротокольный» (multiprotocol) означает, что этот вариант способа коммутации пакетов приемлем для любого протокола сетевого уровня. В данном стандарте речь пойдёт о IP-протоколе (Internetworking Protocol — протокол межсетевого взаимодействия), как протоколе сетевого уровня. Маршрутизатор, который поддерживает MPLS-коммутацию, именуется как «Label Switching Router» или LSR-маршрутизатор.

2.2. Термины и определения

Рассмотрим наиболее общие термины и определения. В дальнейшем некоторые из них будут описаны более подробно.

  • Идентификатор канала передачи данных (DLCI — Data Link Connection Identifier)

    Используется сетях ретрансляции кадров (Frame Relay) для идентификации соединений канального уровня.

  • Эквивалентный класс доставки (Forwarding Equivalence Class — FEC)

    Группа (последовательность) IP-пакетов, которые доставляются одним и тем же способом (например, доставляются по одному и тому же маршруту и обрабатываются одним и тем же способом).

  • Слияние идентификаторов канала передачи данных (frame merge)

    Слияние маркеров, когда MPLS-маркер представляет собой поле, содержащее идентификатор канала передачи данных при доставке данных по сети c ретрансляцией кадров (Frame Relay), и при этом проблема чередования ячеек не возникает.

  • Маркер потока (маркер) (label)

    Идентификатор, как правило, локального значения, связанный с физической средой передачи, имеющий небольшую фиксированную длину (размер) и который используется для обозначения FEC-класса.

  • Слияние маркеров (label merging)

    Замена нескольких входящих маркеров соответствующего FEC-класса на один исходящий маркер.

  • Замена маркера (label swap)

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

  • Процедура замены маркера (label swapping)

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

  • Ретрансляционный участок с MPLS-коммутацией (label switched hop)

    Ретрансляционный участок между двумя MPLS-узлами, по которому доставляются данные с использованием маркеров потока.

  • Маршрут с MPLS-коммутацией (label switched path — LSP-маршрут)

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

  • Маршрутизатор с MPLS-коммутацией (Label Switching Router — LSR-маршрутизатор)

    MPLS-узел, который обеспечивает доставку реальных IP-пакетов (сетевого уровня).

  • Уровень 2 (layer 2)

    Канальный уровень ЭМВОС или Интернет-архитектуры, расположенный под сетевым (3-им) уровнем, и соответствующий протокол этого уровня. Доставка осуществляется на канальном уровне, невзирая на то, является ли анализируемый маркер потока АТМ-идентификатором (VPI/VCI), FR-идентификатором (DLCI) или MPLS-маркером. При этом в процессе доставки реализуется процедура замены маркеров, имеющих небольшую фиксированную длину.

  • Уровень 3 (layer 3)

    Сетевой уровень ЭМВОС или Интернет-архитектуры и соответствующий протокол этого уровня. На этом уровне функционируют IP-протокол и соответствующие протоколы маршрутизации, которые инициализируют функционирование канального (2-го) уровня.

  • Выявление петлевого маршрута (loop detection)

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

  • Блокировка петлевого маршрута (loop prevention)

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

  • Набор маркеров потока (label stack)

    Упорядоченная совокупность маркеров потока.

  • Точка слияния (merge point)

    Узел, в котором осуществляется слияние маркеров потока.

  • MPLS-сегмент (MPLS domain)

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

  • Граничный MPLS-узел (MPLS edge node)

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

  • Выходной MPLS-узел (MPLS egress node)

    Граничный MPLS-узел, роль которого заключается в управлении трафиком, когда последний «покидает» MPLS-сегмент.

  • Входной MPLS-узел (MPLS ingress node)

    Граничный MPLS-узел, роль которого заключается в управлении трафиком, когда последний «поступает» в MPLS-сегмент.

  • MPLS-маркер (MPLS label)

    Маркер, который содержится в заголовке транслируемого IP-пакета, и который определяет FEC-класс этого IP-пакета.

  • MPLS-узел (MPLS node)

    Сетевой узел, который реализует MPLS-коммутацию. MPLS-узел способен реализовать несколько протоколов управления MPLS-коммутацией, один или несколько протоколов маршрутизации сетевого уровня и доставлять IP-пакеты на основе маркеров потока. Дополнительно MPLS-узел способен реализовать доставку простых IP-пакетов (сетевого уровня).

  • Виртуальное соединение (virtual circuit)

    Соединение протокола канального уровня, ориентированного на установление соединения, например, АТМ-протокол или FR-протокол, требующие обмена информацией о состоянии соединения между коммутаторами канального уровня.

  • Слияние маркеров виртуального соединения (VC merge)

    Слияние маркеров, когда MPLS-маркер представляет собой поле, содержащее идентификатор виртуального соединения, АТМ-протокола (либо комбинацию идентификатор виртуального соединения/маршрута), которое позволяет объединить несколько идентификаторов виртуального соединения в один единственный идентификатор виртуального соединения.

  • Слияние маркеров в рамках виртуального маршрута (VP merge)

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

  • Идентификатор виртуального соединения/маршрута (VPI/VCI)

    Идентификатор, используемый в АТМ-сетях для обозначения виртуальных соединений.

2.3. Сокращения и аббревиатуры

ATM Asynchronous Transfer Mode (асинхронный режим доставки)
BGP Border Gateway Protocol
DLCI Data Link Circuit Identifier
FEC Forwarding Equivalence Class
FTN FEC to NHLFE Map
IGP Interior Gateway Protocol
ILM Incoming Label Map
IP Internet Protocol
LDP Label Distribution Protocol
L2 Layer 2 (канальный уровень)
L3 Layer 3 (сетевой уровень)
LSP Label Switched Path
LSR Label Switching Router
MPLS MultiProtocol Label Switching
NHLFE Next Hop Label Forwarding Entry
SVC Switched Virtual Circuit
SVP Switched Virtual Path
TTL Time-To-Live
VC Virtual Circuit
VCI Virtual Circuit Identifier
VP Virtual Path
VPI Virtual Path Identifier

3. Концептуальные основы MPLS-систем

Далее рассматриваются основные концепции (концептуальные понятия) и принципы использования MPLS-систем.

3.1. Маркеры

Маркер представляет собой идентификатор локального значения, имеющий небольшую фиксированную длину и используемый для обозначения FEC-класса. Маркер, размещённый в соответствующем IP-пакете, представляет собой FEC-класс (эквивалентный класс доставки), к которому «приписан» этот IP-пакет.

Как правило, IP-пакет приписывается к FEC-классу (полностью или частично) на основе имеющегося в его заголовке адреса получателя сетевого уровня (IP-адреса). Однако сам маркер никогда не кодируется (формируется) на основе этого адрес.

Обозначим два LSR-маршрутизатора как «Ru » и «Rd », тогда они могут согласовать параметры доставки следующим образом: когда Ru транслирует IP-пакет Rd , первый будет маркировать IP-пакет, используя величину L , только в том случае, если IP-пакет принадлежит соответствующему FEC-классу F . Т.е. они могут согласовать «связку» маркера L с FEC-классом F только для тех IP-пакетов, которые транслируются от Ru к Rd . В результате такого согласования маркер L становится «исходящим маркером» для Ru , и «входящим маркером» для Rd , отображая, таким образом, FEC-класс F .

Следует заметить, что маркер L не обязательно представляет FEC-класс F в каких-либо других IP-пакетах, которые отличаются от IP-пакетов, транслируемых от Ru к Rd . Маркер L является произвольно выбранным значением, «связываемым» с F , которое, в свою очередь, является локальным по отношению к Ru и Rd .

Когда речь идёт о «доставке» IP-пакетов от Ru к Rd , это совсем не означает, что Ru является источником IP-пакета или Rd является его конечным получателем. В дальнейшем предполагается, что все IP-пакеты, являющиеся «транзитными», также относятся к IP-пакетам, обрабатываемым одним или обоими LSR-маршрутизаторами.

Иногда весьма трудно или почти невозможно сказать, что в IP-пакет, поступивший в Rd и содержащий маркер L , последний был помещён именно Ru , а никаким другим LSR-маршрутизатором. (Это типичный случай, когда Ru и Rd не являются напрямую связанными соседями.) В таких ситуациях Rd должен гарантировать, что привязка маркера к FEC-классу является взаимно однозначной. Т.е., Rd обязан не согласовывать с R u 1 привязку маркера L к FEC-классу F 1 , а также — привязку маркера L к другому FEC-классу F 2 с некоторым другим LSR-маршрутизатором R u 2 , но до тех пор, пока Rd не сможет в любой момент сказать, когда он получил IP-пакет с входящим маркером L , и был ли маркер помещён в IP-пакет R u 1 или был ли помещён R u2 .

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

3.2. LSR-маршрутизаторы нисходящего и восходящего потоков

Предположим, что Ru и Rd согласовали привязку маркера L к FEC-классу F для пакетов, передаваемых от Ru к Rd . Тогда, в соответствие с указанной привязкой, маршрутизатор Ru — «LSR-маршрутизатор восходящего потока» (LSRВП ), а Rd — «LSR-маршрутизатор нисходящего потока» (LSRНП ).

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

3.3. Промаркированный (помеченный) IP-пакет

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

3.4. Назначение и распределение маркеров потока

В MPLS-архитектуре решение о привязке определённого маркера L к соответствующему FEC-классу F принимается LSR-маршрутизатором, который является LSRНП относительно данной привязки. Затем, LSRНП информирует LSRВП о наличии привязки. Таким образом, маркеры потоков назначаются LSRНП , а информация о привязке маркеров распространяется в направлении «LSRНП ⇒ LSRВП ». Если LSR-маршрутизатор имеет «полномочия» только для поиска маркеров, которые попадают в некоторый численный диапазон, то ему следует просто гарантировать, что он только «привязывает» маркеры из указанного диапазона.

3.5. Атрибуты для процедуры привязки маркеров потока

Соответствующая процедура привязки маркера L к FEC-классу F , который доставляется от Rd к Ru , может быть связана с использованием определённых «атрибутов». Если Ru выступает в роли LSRНП , который также доставляет данные о привязке маркера L к FEC-классу F , то при определённых условиях он может быть востребован и для доставки соответствующего атрибута, полученного им от Rd .

3.6. Протоколы доставки (распределения) маркеров потока

Протокол доставки (распределения) маркеров потока (label distribution protocol, LDP-протокол) представляет собой совокупность процедур (правил проведения информационного обмена), с помощью которых один LSR-маршрутизатор информирует другого о проведённой им процедуре привязки «маркер/FEC-класс». Два LSR-маршрутизатора, использующие LDP-протокол для обмена информацией о привязке «маркер/FEC-класс», называются «сторонами доставки маркеров потока» (label distribution peers),что соответствует обмену между ними информацией о процедуре привязки. Если два LSR-маршрутизатора являются «сторонами доставки маркеров потока», то говорят, что они являются «смежными (соседями) относительно доставки маркеров потока».

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

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

В рамках MPLS-архитектуры рассматриваются несколько возможных LDP-протоколов, которые в настоящее время стандартизированы.

Тем не менее, в данном документе речь пойдёт о стандарте LDP-протокола, представленного в RFC-3036 (RFC-5036).

3.7. Незапрашиваемый или нисходящий поток по требованию

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

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

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

3.8. Режим сохранения маркера потока

LSR-маршрутизатор Ru , может получить (или уже получил) от LSR-маршрутизатор Rd маркер потока, привязанный к определённому FEC-классу, даже если Rd не расположен на следующем ретрансляционном участке по отношению к Ru (или не является его продолжением) для этого FEC-класса. После этого Ru осуществляет процедуру выбора: сохранить или удалить полученные данные о привязке. Если Ru сохранит полученные данные о привязке, то он может сразу начать использовать эти данные повторно, если конечно Rd располагается на следующем ретрансляционном участке по отношению к Ru для FEC-класса, о котором идёт речь. Если Ru удалит полученные данные о привязке, то данные о привязке должны быть получены повторно, если конечно в дальнейшем Rd будет располагаться на следующем ретрансляционном участке по отношению к Ru .

Если LSR-маршрутизатор поддерживает «свободный режим сохранения маркера потока» (liberal label retention mode), то он сохраняет данные о привязках «маркер/FEC-класс», которые получил от других LSR-маршрутизаторов, не расположенных на следующем ретрансляционном участке по отношению к нему для конкретного FEC-класса. Если же LSR-маршрутизатор поддерживает «консервативный режим сохранения маркера потока» (conservative label retention mode), то он удаляет данные о привязках «маркер/FEC-класс».

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

3.9. Набор маркеров потока

До сих пор речь шла о помеченных IP-пакетах, которые доставляли только один маркер потока (в каждом). Однако в дальнейшем речь пойдёт о более общей модели, в которой помеченные IP-пакетах доставляют несколько маркеров потока (в каждом). При этом маркеры структурированы в «набор магазинного типа» (last-in, first-out stack — LIFO). В дальнейшем такая структура будет именоваться «набором маркеров потока» (label stack).

Несмотря на то, что MPLS-архитектура определяет некоторую логическую и процедурную иерархии, обработка помеченных IP-пакетов совершенно не зависит от уровня иерархии. Обработка всегда начинается с самого верхнего маркера (top label), невзирая на возможность того, что, либо в прошлом некоторое количество других маркеров могло располагаться «выше его» («above it»), либо в настоящий момент некоторое количество других маркеров может располагаться ниже его.

Непомеченный IP-пакет может рассматриваться как IP-пакет, содержащий «пустой» набор маркеров потока (т.е. «глубина» набора маркеров равна нулю).

Если набор маркеров потока, содержащийся в IP-пакете, имеет глубину m , то самый нижний маркер в наборе является маркером первого уровня (level 1), маркер, расположенный над ним (если конечно такой существует), является маркером второго уровня (level 2), а самый верхний маркер в наборе является маркером уровня m (level m).

3.10. Запись о доставке маркера на следующий ретрансляционный участок

Такая запись («Next Hop Label Forwarding Entry» — NHLFE) используется тогда, когда доставляется помеченный IP-пакет. NHLFE-запись содержит следующую информацию:

  1. Следующий ретрансляционный участок IP-пакета.

  2. Процедура обработки набора маркеров потока из IP-пакета. Т.е. одна из следующих:

    1. Замена маркера самого верхнего уровня набора на новый указанный маркер.

    2. «Выталкивание» (удаление) набора маркеров (или самого верхнего маркера в наборе маркеров).

    3. Замена маркера самого верхнего уровня набора на новый указанный маркер с последующей вставкой («проталкиванием») одного или более новых указанных маркеров в набор маркеров потока.

    4. (Дополнительно) Повторное обрамление на канальном уровне, используемое при передаче IP-пакета.

    5. (Дополнительно) Способ кодирования набора маркеров потока при передаче IP-пакета.

    6. (Дополнительно) Любая другая необходимая информация для корректной обработки IP-пакета.

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

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

Если в обрабатываемом IP-пакете указан LSR-маршрутизатор, «расположенный на следующем ретрансляционном участке», и который является текущим LSR-маршрутизатором, то далее должна следовать процедура обработки набора маркеров потока, заключающаяся в «выталкивании» (удалении) маркера или всего набора маркеров (pop the stack).

3.11. Отображение входящего маркера

Эта процедура («Incoming Label Map» — ILM) обеспечивает отображение входного (входящего) маркера в совокупность NHLFE-записей. ILM-процедура используется при доставке IP-пакетов, которые поступают как помеченные IP-пакеты.

Если ILM-процедура отображает определённый маркер в совокупность NHLFE-записей, которая включает более одного элемента, то перед отправкой IP-пакета из набора маркеров должен быть выбран ровно один элемент. Сами процедуры выбора элемента из набора в данном стандарте не рассматриваются. Наличие ILM-процедуры отображения маркера в совокупность из более чем одной NHLFE-записи может быть весьма полезным, если, например, необходимо сбалансировать нагрузку между несколькими эквивалентными, с точки зрения затрат, маршрутами.

3.12. Отображение FEC-класса в совокупность NHLFE-записей

Эта процедура («FEC-to-NHLFE» — FTN) обеспечивает отображение FEC-класса в совокупность NHLFE-записей. FTN-процедура используется при доставке IP-пакетов, которые поступают непомеченными, но которые должны быть помечены перед их дальнейшей отправкой.

Если FTN-процедура отображает определённый маркер в совокупность NHLFE-записей, которая включает более одного элемента, то перед отправкой IP-пакета из набора маркеров должен быть выбран ровно один элемент. Сами процедуры выбора элемента из набора в данном стандарте не рассматриваются. Наличие FTN-процедуры отображения маркера в совокупность более чем из одной NHLFE-записи может быть весьма полезным, если, например, необходимо сбалансировать нагрузку между несколькими эквивалентными, с точки зрения затрат, маршрутами.

3.13. Замена маркеров

Замена маркеров (label swapping) предполагает использование следующих процедур при доставке IP-пакета:

  1. При доставке помеченного IP-пакета.

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

  2. При доставке не помеченного IP-пакета.

    LSR-маршрутизатор анализирует заголовок сетевого уровня с целью определения FEC-класса. После этого он использует FTN-процедуру для отображения FEC-класса в совокупность NHLFE-записей. Используя информацию в NHLFE-записях, он определяет, куда направить IP-пакет, и обрабатывает набор маркеров для IP-пакета. (В данной ситуации вполне возможно, что процедура «выталкивания» (popping) маркера или набора маркеров будет недопустимой.) Затем он кодирует и размещает новый набор маркеров в IP-пакете, а потом транслирует итоговый IP-пакет.

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

3.14. Назначение и уникальность маркеров

Положим, что LSR-маршрутизатор Rd может связать маркер L 1 с FEC-классом F и отправить данные об этой связке субъекту распределения маркеров R u 1 . Rd также может связать маркер L 2 с FEC-классом F и отправить данные об этой связке субъекту распределения маркеров R u 2 . MPLS-архитектура не определяет должны ли такие маркеры L 1 и L 2 быть одинаковыми. Эта задача должна решаться локально.

Положим, что LSR-маршрутизатор Rd может связать маркер L с FEC-классом F 1 и отправить данные об этой связке субъекту распределения маркеров R u 1 . Rd также может связать маркер L с FEC-классом F 2 и отправить данные об этой связке субъекту распределения маркеров R u 2 . Если (и только если) Rd после получения IP-пакета, в котором самый высший маркер является маркером L , может определить какой из субъектов R u 1 или R u 2 разместил маркер в этом IP-пакете, то MPLS-архитектура не требует, чтобы FEC-классы F 1 и F 2 были одинаковыми. В таких случаях говорят, что Rd использует различные «диапазоны (пространства) маркеров» для тех маркеров, которые он транслирует субъекту R u 1 , и для тех, которые он транслирует субъекту R u 2 .

Обобщая сказанное выше, Rd может определить, какой из субъектов R u 1 или R u 2 разместил соответствующий маркер L на самом верхнем уровне набора маркеров только при соблюдении следующих условий:

  • R u 1 и R u 2 являются лишь субъектами распределения маркеров, которым Rd транслирует данные о привязке маркера L ;

  • R u 1 и R u 2 напрямую соединены с Rd через сквозной интерфейс (point-to-point interface).

Если эти условия соблюдены, то LSR-маршрутизатор может использовать маркеры, которые предназначены для обозначения конкретного интерфейса (per interface), т.е. каждый маркер соответствует только одному уникальному интерфейсу. В этом случае говорят, что LSR-маршрутизатор использует пространство маркеров, предназначенных для обозначения конкретного интерфейса (per-interface label space).

Если эти условия не соблюдены, то маркеры должны быть уникальны по отношению LSR-маршрутизатору, за которым они закреплены. В этом случае говорят, что LSR-маршрутизатор использует пространство маркеров, предназначенных для обозначения конкретного сетевого объекта (per-platform label space).

Если определённый LSR-маршрутизатор Rd присоединён к соответствующему LSR-маршрутизатору Ru с помощью двух сквозных интерфейсов, то Rd может отправить Ru данные о привязке маркера L к FEC-классу F 1 , а также данные о привязке маркера L к FEC-классу F 2 . При этом FEC-классы F 1 и F 2 считаются эквивалентными, но только тогда (и только тогда), если каждый элемент данных о привязке может быть доставлен только в тех IP-пакетах, которые Ru транслирует Rd через один из двух сквозных интерфейсов. Во всех других случаях Rd не должен транслировать Ru данные о привязке маркера с одним и тем же значением к двум различным FEC-классам.

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

Вопрос заключается как раз в том, может ли LSR-маршрутизатор для одного и того же интерфейса использовать несколько диапазонов маркеров, предназначенных для обозначения конкретного, либо сетевого объекта, либо интерфейса. MPLS-архитектура этого не запрещает. Тем не менее, в таких случаях LSR-маршрутизатор обязан иметь специализированные средства (которые MPLS-архитектурой не стандартизованы), позволяющие определить, к какому диапазону маркеров принадлежит соответствующий входящий маркер. Например, в стандарте RFC-3032 установлено, что для однонаправленных и IP-пакетов с групповой адресацией должны использоваться различные диапазоны маркеров. Более того, в стандарте RFC-3032 вводится специализированный код канального уровня, предназначенный для разграничения этих двух диапазонов маркеров.

3.15. LSP-маршрут, вход LSP-маршрута, выход LSP-маршрута

LSP-маршрут m -уровня иерархии (LSPm ) по отношению к определённому IP-пакету P представляет собой последовательность маршрутизаторов <R 1 ,...,Rn > обладающих следующими свойствами:

  1. R 1 , вход LSP-маршрута (LSP Ingress), представляет собой LSR-маршрутизатор, который вставляет маркер в набор маркеров IP-пакета P , формируя таким образом набор маркеров глубины m ;

  2. Если LSR-маршрутизатор получает IP-пакет P , то последний содержит набор маркеров глубины m для всех i , 1 < i < n ;

  3. В период времени, когда IP-пакет P не передаётся от R 1 к R n -1 , P уже имеет набор маркеров с глубиной менее m ;

  4. Для всех i , 1 < i < n : Ri отправляет IP-пакет P R i +1 с помощью средств MPLS-коммутации, т.е. с помощью маркера самого верхнего уровня в наборе маркеров (маркер m -уровня), аналогичного индексу в ILM-процедуре;

  5. Для всех i , 1 < i < n : если система S принимает и ретранслирует IP-пакет P после его передачи LSR-маршрутизатором Ri , но ещё до того, как IP-пакет P будет принят R i +1 (например, Ri и R i +1 могут быть связаны через подсеть с коммутацией кадров (коммутация на канальном уровне), а S может быть одним из коммутаторов канального уровня), то система S принимает решение о доставке, не основываясь на маркере m -уровня или заголовке сетевого уровня. Это может быть следствием того, что:

    1. Принимаемое решение вообще не основывается на наборе маркеров или заголовке сетевого уровня;

    2. Принимаемое решение основывается на наборе маркеров, в который могут быть вставлены дополнительные маркеры (т.е. маркер на (m +k )-уровне, где k > 0).

Другими словами, LSPm при доставке IP-пакет P представляет собой последовательность маршрутизаторов:

  1. Которая начинается с LSR-маршрутизатора (вход LSP-маршрута), вставляющего маркер m -уровня;

  2. В которой все промежуточные LSR-маршрутизаторы принимают решение о доставке с помощью процедуры коммутации маркеров, расположенных на m -уровне;

  3. Которая заканчивается (выход LSP-маршрута, LSP Egress) тогда, когда решение о доставке принимается, либо с помощью процедуры коммутации маркеров, расположенных на (m - k )-уровне (где k > 0), либо «стандартным» образом, когда при доставке не используется MPLS-коммутация.

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

Последовательность LSR-маршрутизаторов называется LSP-маршрутом определённого FEC-класса F (LSP for a particular FEC F), если она представляет собой LSPm для соответствующего IP-пакета P , в котором маркер m -уровня является маркером, отображающий FEC-класс F .

Предположим, что имеет место совокупность узлов, которые могут быть узлами входа LSP-маршрута для FEC-класса F . Тогда существует LSP-маршрут для FEC-класса F , который начинается в каждом из указанных узлов. Если все такие LSP-маршруты имеют один и тот же выход LSP-маршрута, то можно предположить, что совокупность таких LSP-маршрутов образует дерево, корнем которого является выход LSP-маршрута. (Так как данные транслируются по этому дереву маршрутов, которое сходится в один корневой узел, то такое дерево называется «сходящимся» (multipoint-to-point tree).) Таким образом, можно говорить о «дереве LSP-маршрутов» относительно определённого FEC-класса F .

3.16. «Выталкивание» на предпоследнем ретрансляционном участке

Если последовательность маршрутизаторов <R 1 , …,Rn > является LSPm для IP-пакета P , последний может быть доставлен из R n -1 в Rn , имея в своём составе набор маркеров с (m -1)-глубиной. Т.е., скорее всего набор маркеров может быть «вытолкнут» в предпоследнем (penultimate) LSR-маршрутизаторе LSP-маршрута, чем на выходе LSP-маршрута.

С точки зрения архитектуры, это вполне приемлемо. Целевое назначение маркера m -уровня является получение IP-пакета LSR-маршрутизатором Rn . После того, как R n -1 примет решение о передаче IP-пакета Rn , маркер больше не выполняет никакой функции, и поэтому нет смысла доставлять его дальше.

Существует только одно реальное преимущество реализации «выталкивания» на предпоследнем ретрансляционном участке. Если предпоследний LSR-маршрутизатор не сделает этого, то после того, как на выходе LSP-маршрута будет получен IP-пакет, выходной LSR-маршрутизатор проанализирует маркер самого верхнего уровня и в результате этого анализа установит, что он действительно является выходом LSP-маршрута. После этого он должен «вытолкнуть» (удалить) маркер самого верхнего уровня из набора маркеров и проверить, что осталось в IP-пакете. Если в наборе существует другой маркер, выходной LSR-маршрутизатор обнаружит его и отправит IP-пакет, основываясь на результате этой проверки. (В таком случае, выходом LSPm для IP-пакета также будет являться промежуточный сетевой узел по отношению к своему LSPm -1 .) Если же в наборе нет другого маркера, то IP-пакет доставляется в соответствие с IP-адресом получателя (адресом сетевого уровня).

Если, с другой стороны, «выталкивание» на предпоследнем ретрансляционном участке осуществляется, то после того, как предпоследний LSR-маршрутизатор проанализирует маркер самого верхнего уровня, он установит:

  • что он «является» предпоследним ретрансляционным участком;
  • и какой следующий ретрансляционный участок.

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

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

Формирование «быстрейшего маршрута» (fast path) доставки в результате обработки маркера MPLS-коммутации может быть весьма эффективной «помощью», если известно, что всегда требуется только одна процедура анализа, а именно:

  • Код (листинг) программы может быть значительно упрощён, если можно предположить, что всегда необходима только одна процедура анализа.

  • Код (листинг) программы может основываться на «ресурсе времени» (time budget), что предполагает необходимость всего лишь одной процедуры анализа.

Фактически, когда на предпоследнем ретрансляционном участке проводится процедура «выталкивания», то выходом LSP-маршрута не обязательно должен быть LSR-маршрутизатор.

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

  • это специально востребовано выходным сетевым узлом;
  • следующий сетевой узел в LSP-маршруте не реализует функции MPLS-коммутации.

(Если следующий сетевой узел в LSP-маршруте реализует функции MPLS-коммутации, но не запрашивает выполнение «выталкивания» маркера или всего набора маркеров, то предпоследний сетевой узел не способен узнать, что он фактически является предпоследним сетевым узлом.)

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

Процедура предварительного согласования LDP-протокола должна предоставить каждому LSR-маршрутизатору возможность определить, способны ли соседние LSR-маршрутизаторы удалять набор маркеров. LSR-маршрутизатор не должен требовать от противоположной стороны выполнения процедуры удаления набора маркеров до тех пор, пока она не будет способна её выполнить.

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

3.17. Следующий ретрансляционный участок LSP-маршрута

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

Следующий ретрансляционный участок LSP-маршрута для соответствующего FEC-класса представляет собой следующий ретрансляционный участок, который был выбран с помощью NHLFE-записи, помеченной маркером потока, соответствующим этому FEC-классу.

Примечание. Следующий ретрансляционный участок LSP-маршрута может отличаться от следующего ретрансляционного участка, который мог быть выбран алгоритмом маршрутизации сетевого (3-го) уровня. Если в дальнейшем пойдёт речь о таком алгоритме, то будет использоваться термин «следующий ретрансляционный участок сетевого (3-го) уровня» («L3 next hop»).

3.18. Недействительные входящие маркеры потоков

Что должен делать LSR-маршрутизатор, если он получил помеченный IP-пакет с соответствующим входящим маркером потока, но который не имеет привязки к этому маркеру? Первое, что «приходит на ум»: такие маркеры могут быть просто удалены, а сам IP-пакет может доставляться далее, как непомеченный. Однако, в некоторых случаях, это может привести к петлевому маршруту доставки. Если LSRВП «думает», что маркер был привязан к явному маршруту (explicit route), а LSRНП «не думает», что маркер был привязан к чему-либо другому, и если ретрансляционный маршрут непомеченного IP-пакета «доставил» его обратно в LSRВП , то очевидно, что сформировался петлевой маршрут.

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

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

3.19. Управление LSP-маршрутом: регулируемое или независимое

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

  • независимое управление LSP-маршрутом;
  • регулируемое управление LSP-маршрутом.

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

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

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

Регулируемое управление может быть установлено по инициативе, либо входного сетевого узла, либо выходного сетевого узла.

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

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

3.20. Агрегирование

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

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

Пусть имеет место совокупность FEC-классов, которая может быть агрегирована в один FEC-класс, тогда возможно:

  1. агрегировать их в один FEC-класс;
  2. агрегировать их в совокупности FEC-классов;
  3. никак их не агрегировать.

Таким образом, можно говорить об «уровне разделения» агрегированных FEC-классов, т.е. «разделение на самые крупные (по числу FEC-классов) подгруппы» (coarsest granularity) и «разделение на самые маленькие (по числу FEC-классов) подгруппы» (finest granularity).

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

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

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

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

  • Можно адаптировать более мелкий уровень разделения у Rd . Это могло бы потребовать от него изъятия распределённых им m маркеров, и распределения n маркеров. Такой подход наиболее предпочтителен;

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

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

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

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

  1. «поузловая» маршрутизация (hop by hop routing);
  2. «явная (точная)» маршрутизация (explicit routing).

Поузловая маршрутизация позволяет каждому сетевому узлу независимо выбирать следующий ретрансляционный участок для каждого FEC-класса. На сегодня этот вариант маршрутизации является наиболее распространенным в существующих IP-сетях. «LSP-маршрут на основе поузловой маршрутизации» (hop by hop routed LSP) представляет собой LSP-маршрут, который «прокладывается» с использованием поузловой маршрутизации.

В случае «LSP-маршрута на основе явной маршрутизации» (explicitly routed LSP) каждый LSR-маршрутизатор не может независимо выбирать следующий ретрансляционный участок. Как правило, одиночный LSR-маршрутизатор, обычно выходной или выходной LSP-маршрута, определяет несколько или все LSR-маршрутизаторы на LSP-маршруте. Если одиночный LSR-маршрутизатор определяет весь LSP-маршрут, то такой LSP-маршрут представляет собой «точно» (strictly) проложенный маршрут на основе явной маршрутизации. Если одиночный LSR-маршрутизатор определяет только часть некоторого LSP-маршрут, то такой LSP-маршрут представляет собой «неточно» (loosely) проложенный маршрут на основе явной маршрутизации.

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

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

Процедуры выбора «точно» или «неточно» прокладываемого маршрута на основе явной маршрутизации в данном стандарте не рассматриваются.

3.22. Отсутствие исходящего маркера

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

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

  • Если IP-пакет следует по LSP-маршруту на основе явной маршрутизации, то в результате мог бы образоваться петлевой маршрут;

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

До тех пор, пока не определено, что делать в указанных ситуациях (а это в данном документе не рассматривается), самым надёжным и безопасным способом является удаление IP-пакета.

3.23. Время жизни IP-пакета (Time-to-Live, TTL)

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

Такой подход обеспечивает некоторый уровень защиты от возникновения петлевых маршрутов, которые могут появиться, либо вследствие ошибочных настроек, либо вследствие ошибки в алгоритме маршрутизации, либо вследствие медленной сходимости последнего. Иногда TTL-поле используется и в других целях, например, в целях применения групповой IP-адресации и поддержки управляющей команды «traceroute» (трассировка (прокладка) маршрута). Из этого следует, что существуют две проблемы, связанные с использованием TTL-поля, которые необходимо решить в рамках MPLS-архитектуры:

  1. TTL-поле используется для предотвращения петлевых маршрутов;

  2. TTL-поле используется для реализации других функций, например, ограничение времени существования IP-пакета.

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

Способ контроля значения в TTL-поле может варьироваться в зависимости от того, каким образом доставляется значение MPLS-маркера, либо с помощью специализированного подзаголовка MPLS-коммутации («shim», RFC-3032), либо с помощью заголовка канального уровня (например, ATM-заголовок, RFC-3035, или FR-заголовок, RFC-3034).

Если значения маркеров потока закодированы и размещены в специализированном MPLS-подзаголовке, находящемся между заголовками канального и сетевого уровней, то в MPLS-подзаголовке должно содержаться TTL-поле, значение которого должно быть первоначально установлено путём копирования значения из TTL-поля заголовка сетевого уровня, должно уменьшаться на единицу при прохождении каждого ретрансляционного (промежуточного) LSR-маршрутизатора, и должно копироваться в TTL-поле заголовка сетевого уровня, когда IP-пакет «покидает» свой LSP-маршрут.

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

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

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

3.24. Контроль возникновения петлевого маршрута

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

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

И даже если можно обеспечить беспрепятственный доступ к буферной памяти, то всё равно следует иметь определённые средства обнаружения петлевых маршрутов, которые «явно длиннее допустимых». Более того, даже если применение TTL-поля и/или соблюдение очерёдности для каждого виртуального соединения предоставляют средства обнаружения оставшихся циклических маршрутов, то по-прежнему такое обнаружение не возможно даже там, где специально запрещена настройка LSP-маршрутов, которые являются петлевыми. Все LSR-маршрутизаторы, которые могут быть связаны с участком LSP-маршрута без обработки TTL-поля, всё равно будут запрашивать необходимую системную поддержку для обнаружения петлевых маршрутов. Тем не менее, применение определённого способа выявления петлевых маршрутов является не обязательным (дополнительным). Такой способ представлен в стандартах RFC-3035 и RFC-3036 (RFC-5036).

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

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

3.25.1. ПАК (или программный комплекс) для MPLS-коммутации

Если ПАК (или программный комплекс) для MPLS-коммутации обеспечивает доставку помеченных IP-пакетов, то наиболее приемлемым способом кодирования набора маркеров является использование «вставки» (shim[?] ) между заголовками канального и сетевого уровней. Такой способ мог быть описан независимым протоколом, а сама вставка могла использоваться на любом сетевом уровне. В последующем будет использоваться термин «универсальная MPLS-вставка» (generic MPLS encapsulation).

В свою очередь, само размещение универсальной MPLS-вставки могло бы осуществляться на канальном уровне. Использование универсальной MPLS-вставки представлено в стандарте RFC-3032.

3.25.2. АТМ-коммутаторы как LSR-маршрутизаторы

Следует отметить, что процедуры MPLS-доставки аналогичны тем существующим коммутаторам, которые реализуют процедуры «смены маркеров» (label swapping), например, АТМ-коммутаторы. Последние используют входной физический интерфейс и значение входного идентификатора VPI/VCI (идентификатор виртуального соединения/маршрута) в качестве индекса в таблице связности (cross-connect), по которой они определяют выходной физический интерфейс и значение выходного идентификатора VPI/VCI. Более того, если один или более маркеров могут быть непосредственно закодированы в полях заголовков протокольных сообщений, и которые будут доступны для обработки ныне существующими коммутаторами, то последние (с необходимым программным обеспечением) могут использоваться в качестве LSR-маршрутизаторов. В дальнейшем такие ПАК будут именоваться ATM/LSR-маршрутизаторы (ATM-LSR).

Существуют три очевидных способов кодирования маркеров в заголовке АТМ-ячейки (ATM cell header), полагая использование АТМ-уровня адаптации «AAL5», а именно:

  1. Кодирование коммутируемого виртуального соединения (SVC encoding).

    Этот способ предусматривает использование VPI/VCI-поля для кодирования маркера, который является самым верхним в наборе маркеров. Такой способ может использоваться в любой сети. При использовании этого способа кодирования каждый LSP-маршрут представляет собой АТМ/SVC-соединение, а протоколом доставки (распределения) маркеров выступает протокол ATM-сигнализации (signaling). Если используется этот способ, то ATM/LSR-маршрутизаторы не могут реализовать функции «проталкивания» или «удаления» (выталкивания) набора маркеров.

  2. Кодирование коммутируемого виртуального маршрута (SVP encoding).

    Этот способ предусматривает использование VPI-поля для кодирования маркера, который является самым верхним в наборе маркеров и VCI-поля для кодирования второго маркера из набора, если конечно он представлен. Этот способ имеет ряд преимуществ по сравнению с первым, рассмотренным выше, в частности, он позволяет использовать коммутацию виртуального АТМ-маршрута. Т.е. LSP-маршруты настраиваются как коммутируемые виртуальные АТМ-маршруты на основе применения протокола доставки (распределения) маркеров, а именно протокола ATM-сигнализации.

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

  3. Многоузловое кодирование коммутируемого виртуального маршрута (SVP multipoint encoding).

    Этот способ предусматривает использование VPI-поля для кодирования маркера, который является самым верхним в наборе маркеров, VCI-поля для кодирования второго маркера из набора, если конечно он представлен, и оставшуюся часть VCI-поля для идентификации начала LSP-маршрута. Если используется данный способ, то стандартные свойства коммутируемых виртуальных АТМ-маршрутов могут применяться для многоузловых виртуальных маршрутов. Ячейки, формируемые на основе заголовков различных IP-пакетов, будут включать различные значения VCI-идентификаторов. Как мы увидим в дальнейшем, такой подход позволяет осуществлять процедуру слияния маркеров АТМ-коммутаторами (причём без каких-либо проблем, связанных с «чередованием» ячеек), которые могут поддерживать многоузловые виртуальные маршруты, но которые не способны совмещать виртуальные соединения. Данный способ зависит от наличия процедуры присвоения 16-битового значения VCI-идентификатора каждому АТМ-коммутатору, причём такого, чтобы ни одно такое значение не было присвоено двум разным коммутаторам. (Если требуемого числа таких идентификаторов не достаточно для присвоения каждому коммутатору, то можно использовать значение VCI-идентификатора в качестве второго маркера в наборе.)

Если на практике используется гораздо больше маркеров в наборе, чем можно закодировать с использованием АТМ-заголовка, то АТМ-кодирование должно дополняться (или комбинироваться с) универсальной MPLS-вставкой.

3.25.3. Обеспечение функциональной совместимости способов кодирования

Если <R 1 , R 2 , R 3 > представляет собой участок LSP-маршрута, то существует возможность того, что R 1 будет использовать один способ кодирования набора маркеров при передаче IP-пакета P R 2 , в то время как R 2 будет использовать другой способ кодирования при передаче IP-пакета P R 3 . Вообще, MPLS-архитектура рассматривает LSP-маршруты с различными способами кодирования наборов маркеров, используемыми на разных ретрансляционных участках. Более того, когда рассматриваются процедуры обработки помеченного IP-пакета, то используются абстрактные термины для описания применения набора маркеров при доставке IP-пакета. После получения помеченного IP-пакета LSR-маршрутизатор должен декодировать его, чтобы определить текущее значение набора маркеров, затем он должен обработать сам набор маркеров, чтобы определить новое значение набора, и затем закодировать соответствующим образом новое значение, и только после этого отправить помеченный IP-пакет на его следующий ретрансляционный участок.

К сожалению, АТМ-коммутаторы не способны преобразовывать один способ кодирования в другой. Более того, MPLS-архитектура требует, чтобы два АТМ-коммутатора, там, где возможно, корректно выполняли функции LSR-маршрутизаторов по доставке некоторого IP-пакета по LSP-маршруту с уровнем m , также необходимо, чтобы эти два АТМ-коммутатора применяли один и тот же способ кодирования.

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

3.26. Процедура слияния маркеров потоков

Предположим, что LSR-маршрутизатор привязал к соответствующему FEC-классу несколько входящих маркеров. При доставке IP-пакетов, принадлежащих одному FEC-классу, последний мог бы иметь один исходящий маркер, который применялся бы ко всем таким IP-пакетам. Факт получения двух разных IP-пакетов, относящихся к одному FEC-классу, с различными входными маркерами вообще не рассматривается, он просто неуместен. Желательно, чтобы такие IP-пакеты доставлялись с одним и тем же исходящим маркером. Процедура, обеспечивающая сказанное выше, называется «слиянием (объединением) маркеров» (label merging).

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

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

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

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

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

3.26.1. LSR-маршрутизаторы с функцией и без функции слияния маркеров

MPLS-процедуры доставки очень похожи на процедуры доставки, которые реализуются в АТМ- и FR-сетях. Т.е., при поступлении протокольного элемента данных осуществляется поиск маркера (VPI/VCI- или DLCI-идентификатора) в таблице связности («cross-connect table»), по итогам такого поиска выбирается выходной интерфейс и перезаписывается значение маркера. Фактически, такие способы доставки данных можно использовать в MPLS-системах. А LDP-протокол можно использовать в качестве протокола сигнализации (signaling protocol) в процедуре настройки таблиц связности.

К сожалению, эти способы делают не нужной процедуру слияния маркеров. Если в АТМ-сетях попытаться осуществить слияние маркеров, то в результате может последовать чередование ячеек с различными IP-пакетами. А если ячейки с различными IP-пакетами стали чередоваться, то в такой ситуации просто невозможно осуществить повторную сборку IP-пакетов. Некоторые FR-коммутаторы совмещают FR- и АТМ-коммутацию (коммутацию ячеек) на основе своих объединённых плат (задних панелей, backplane). Такие коммутаторы могут быть также не способны реализовывать процедуру слияния маркеров, причём по той же самой причине — чередование ячеек с различными IP-пакетами и отсутствие, в таких условиях, способа повторной сборки IP-пакетов.

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

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

3.26.2. Маркеры для LSR-маршрутизаторов с функцией и без функции слияния маркеров

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

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

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

Является ли процедура слияния маркеров применимой к LSP-маршруту на основе явной маршрутизации? Этот вопрос требует дальнейшего исследования.

3.26.3. Процедура слияния маркеров в АТМ-сетях

3.26.3.1. Методы предотвращения чередования ячеек

Существует несколько методов решения проблемы чередования ячеек в АТМ-системах, которые позволяют АТМ-коммутаторам реализовать процедуру слияния маркеров:

  1. Слияние маркеров в рамках виртуального маршрута с использованием кодирования коммутируемого виртуального маршрута с групповой адресацией.

    Если используется слияние маркеров в рамках виртуального маршрута, то несколько виртуальных объединяются в один виртуальный маршрут, но при этом IP-пакеты из различных источников распознаются на основе проверки различных значений VCI-идентификаторов в пределах конкретного виртуального маршрута.

  2. Слияние маркеров виртуальных соединений.

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

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

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

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

Функциональная совместимость при использовании различных процедур слияния маркеров в АТМ-сети определяется весьма просто, во-первых, путём определения совместимости режима использования процедуры слияния маркеров виртуальных соединений с режимом отсутствия такой процедуры.

Если сетевые узлы, использующие и не использующие процедуру слияния маркеров виртуальных соединений, взаимосвязаны, то во всех случаях доставка АТМ-ячеек основана организации виртуальных соединений (т.е. VPI- и VCI-идентификаторы используются в режиме «сцепления», concatenation). Для каждого сетевого узла, если соседний АТМ/LSRВП реализует процедуру слияния маркеров виртуальных соединений, то данный «сосед» запрашивает только одиночную пару VPI/VCI-идентификаторов для соответствующего потока (т.е. по аналогии с запросом одиночного маркера потока в случае FR-сети). Если же соседний АТМ/LSRВП не реализует процедуру слияния маркеров, то он запрашивает только одну пару VPI/VCI-идентификаторов для каждого потока в собственных интересах, и дополнительно — необходимое число VPI/VCI-идентификаторов для передачи своим соседним АТМ/LSRВП . Требуемое число VPI/VCI-идентификаторов будет определяться количеством АТМ/LSRВП , которым разрешено запрашивать дополнительные VPI/VCI-идентификаторы от своих соседних АТМ/LSRНП (т.е. опять аналогично методу, используемому при слиянии маркеров в FR-сетях).

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

Для того, что бы обеспечить одновременное функционирование всех режимов работы (слияние маркеров в рамках виртуального маршрута, виртуальных соединений и без слияния маркеров), дополнительно следует разрешить АТМ/LSRВП запрашивать совокупность (от нуля и более) VCI-идентификаторов (состоящих из VPI/VCI-идентификаторов), совокупность (от нуля и более) виртуальных маршрутов (определяемых VPI-идентификаторами), причём каждый будет включать определённое число виртуальных соединений (определяемых совокупностью VCI-идентификаторов, которые, в свою очередь, указывают на виртуальный маршрут). Более того, сетевые узлы, реализующие процедуру слияния маркеров в рамках виртуального маршрута, могли бы запросить один виртуальный маршрут, содержащий VCI-идентификатор, по которому транслируется трафик (если необходимо), а также VCI-идентификатор для каждого виртуального соединения, запрошенных «сверху» (не обращая внимания на то, является или не является виртуальное соединение частью виртуального маршрута). Сетевой узел, реализующий процедуру слияния маркеров виртуальных соединений, мог бы запросить только один VPI/VCI-идентификатор (так как такие узлы могут реализовать процедуру слияния маркеров всего восходящего трафика в одно виртуальное соединение). Сетевые узлы, не реализующие процедуру слияния маркеров, могли бы направить любые запросы, которые они получат «сверху», а также запрос VPI/VCI-идентификатора трафика, который они ретранслируют (если необходимо).

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

Иногда маршрутизатор Ru выполняет вполне конкретную процедуру по определению, какой IP-пакет должен быть доставлен на другой маршрутизатор Rd , даже если Ru и Rd не являются следующими друг за другом маршрутизаторами на поузловом маршруте доставки этого IP-пакета, а Rd не является конечным пунктом назначения этого IP-пакета. Например, это можно сделать путём вставки транслируемого пакета в IP-пакет сетевого уровня, у которого адрес получателя является IP-адресом этого маршрутизатора Rd . Такая процедура формирует «туннель» (tunnel) от Ru до Rd . В дальнейшем любой пакет, прошедший такую процедуру обработки, именуется «туннелированным» (tunneled packet).

3.27.1. Туннель с поузловой маршрутизацией

Если туннелированный пакет (ТП) следует по поузловому маршруту от Ru до Rd , то такой маршрут называется «туннелем с поузловой маршрутизацией» (hop-by-hop routed tunnel), в котором Ru — «крайняя точка передачи» (transmit endpoint), а Rd — «крайняя точка приёма» (receive endpoint).

3.27.2. Туннель с точной (явной) маршрутизацией

Если ТП следует по маршруту от Ru до Rd , но отличному от поузлового маршрута, то такой маршрут называется «туннелем с точной маршрутизацией» (explicitly routed tunnel), в котором Ru — «крайняя точка передачи» (transmit endpoint), а Rd — «крайняя точка приёма» (receive endpoint). Пакет сетевого уровня можно передать по туннелю с точной маршрутизацией путём его размещения (вставки) в пакет, который был передан источником.

3.27.3. Туннели на основе LSP-маршрутов

Туннель можно представить как LSP-маршрут, и лучше всего использовать коммутацию на основе маркеров потока, чем размещать IP-пакет в кадре канального уровня и, таким образом, транслировать его по туннелю. Пусть туннелем будет LSP-маршрут <R 1 , ..., Rn >, в котором R 1 , — крайняя точка передачи в туннеле, а Rn — крайняя точка приёма в туннеле. Такой маршрут называется «LSP-туннель».

Совокупность IP-пакетов, которая транслируется по LSP-туннелю, образует FEC-класс, а каждый LSR-маршрутизатор в туннеле обязан присваивать маркер такому FEC-классу (т.е. обязан присваивать маркер к туннелю). Выбор критерия, по которому соответствующий IP-пакет «закрепляется» за LSP-туннелем, определяется локально в крайней точке передачи туннеля. Для того, чтобы доставить IP-пакет по LSP-туннелю, в крайней точке передачи вставляется маркер туннеля в набор маркеров, а затем помеченный IP-пакет доставляется по следующему ретрансляционному участку туннеля.

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

«LSP-туннель, сформированный на основе поузловой маршрутизации» (hop-by-hop routed LSP tunnel), представляет собой туннель, сформированный как LSP-маршрут с поузловой маршрутизацией между крайней точкой передачи и крайней точкой приёма.

«LSP-туннель, сформированный на основе точной маршрутизации» (explicitly routed LSP tunnel), представляет собой туннель, сформированный как LSP-маршрут на основе точной маршрутизацией.

3.27.4. Иерархия: LSP-туннели в рамках LSP-маршрутов

Пусть имеет место LSP-маршрут <R 1 , R 2 , R 3 , R 4 >. Теперь предположим, что R 1 принял непомеченный IP-пакет P и поместил в его набор маркеров свой маркер, чтобы направить его по данному маршруту. Фактически, такой маршрут является поузловым. Однако в дальнейшем полагаем, что R 2 и R 3 не имеют прямого соединения между собой, но считаются «соседями» в силу того, что являются оконечными (крайними) точками LSP-туннеля. Таким образом, реальной последовательностью LSR-маршрутизаторов, по которым доставляется IP-пакет P , является <R 1 , R 2 , R 21 , R 22 , R 23 , R 3 , R 4 >.

Когда P следует по маршруту от R 1 до R 2 , он имеет глубину набора маркеров равную 1. R 2 , осуществляющий коммутацию по маркеру, определяет, что P должен следовать далее по туннелю. R 2 первым заменяет входящий маркер на маркер, который является значимым для R 3 . Затем он «заталкивает» новый маркер. Этот маркер второго уровня имеет значение, которое является значимым для R 21 . Далее коммутация осуществляется R 21 , R 22 и R 23 , с использованием маркера второго уровня. R 23 , который является предпоследним коммутатором в туннеле R 2 ⇒ R 3 , перед тем, как отправить IP-пакет R 3 , выталкивает набор маркеров. Когда R 3 проанализирует IP-пакет P , он установит, что в P содержится только один маркер первого уровня, что указывает на выход из туннеля. Так как R 3 является предпоследним коммутатором в LSP-маршруте первого уровня при доставке IP-пакет P , он выталкивает набор маркеров, а R 4 принимает P непомеченным.

Использование набора маркеров позволяет формировать LSP-туннели любой глубины.

3.27.5. Информационный обмен при доставке маркеров и иерархия

Предположим, что IP-пакет P доставляется по LSP-маршруту первого уровня <R 1 , R 2 , R 3 , R 4 >, а когда он будет доставляться от R 2 до R 3 , то будет следовать по LSP-маршруту второго уровня <R 2 , R 21 , R 22 , R 3 >. С точки зрения LSP-маршрута второго уровня, противоположной стороной доставки (распределения) маркеров для R 2 является R 21 . С точки зрения LSP-маршрута первого уровня, противоположными сторонами доставки (распределения) маркеров для R 2 являются R 1 и R 3 . R 2 может проводить процедуры распределения маркеров с соседними коммутаторами на любом уровне иерархии. В дальнейшем будут рассмотрены некоторые способы использования такой иерархии. Следует заметить, что в представленном выше примере коммутаторы R 2 и R 21 должны быть соседями с точки зрения IGP-протокола, в то время как для коммутаторов R 2 и R 3 такое требование не обязательно.

Когда два LSR-маршрутизатора являются соседями с точки зрения IGP-протокола, то говорят, что они являются «взаимодействующими сторонами локальной процедуры распределения маркеров» (local label distribution peers). Когда два LSR-маршрутизатора не являются соседями с точки зрения IGP-протокола, то говорят, что они являются «взаимодействующими сторонами при проведении удалённой процедуры распределения маркеров» (remote label distribution peers). В рассмотренном ранее примере коммутаторы R 2 и R 21 являются взаимодействующими сторонами локальной процедуры распределения маркеров, а коммутаторы R 2 и R 3 — взаимодействующими сторонами удалённой процедуры распределения маркеров.

MPLS-архитектура рассматривает два способа распределения (доставки) маркеров на различных уровнях иерархии: явная (точная) процедура доставки маркеров (explicit peering) и неявная процедура доставки маркеров (implicit peering).

Коммутатор (сетевой узел) проводит процедуру распределения (доставки) маркеров с другой взаимодействующей стороной (другим коммутатором, сетевым узлом) путём передачи сообщений LDP-протокола, которые адресованы этой стороне. Коммутатор (сетевой узел) может организовать распределение (доставку) маркеров с удалённой взаимодействующей стороной (другим коммутатором, сетевым узлом) одним из следующих двух способов:

  1. Явная (точная) процедура доставки маркеров.

    При реализации этой процедуры коммутатор (сетевой узел) доставляет маркеры взаимодействующей с ним стороне путём передачи сообщений LDP-протокола, которые адресованы данной стороне, причём точно так же, как если бы они были сторонами локального обмена маркерами (local label distribution peers). Этот способ наиболее приемлем там, где число удаленных сторон, которые обмениваются маркерами, — мало, или тогда, когда число привязок маркеров верхнего уровня — большое, или тогда, когда удаленные стороны, которые обмениваются маркерами, расположены в определённых маршрутизационных областях или сегментах. Естественно, коммутатору необходимо знать, какие маркеры и каким сторонам следует доставлять.

  2. Неявная процедура доставки маркеров.

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

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

3.28. Доставка данных о LDP-протоколе

LDP-протокол используется между узлами MPLS-сети для формирования и обработки привязок маркеров. Для корректного функционирования MPLS-сети информация о доставке маркеров должна передаваться надёжно, а сообщения LDP-протокола, принадлежащие определённому FEC-классу, должны транслироваться последовательно. Также для этого необходимо обеспечить управление потоком, так как оно обеспечит доставку сообщений с несколькими маркерами в одной дейтаграмме.

Одним из решений указанных выше проблем является использование протокола транспортного уровня с установлением соединения, в частности ТСР-протокола (RFC-3107 / RFC-4271), RFC-3036 / RFC-5036).

3.29. Один или несколько LDP-протоколов?

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

3.29.1. BGP- и LDP-протоколы

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

Например, такие маршруты устанавливает BGP-протокол, и если активному программному BGP-модулю (BGP-серверу) также необходимо доставить маркеры своим «BGP-коллегам», то применение BGP-протокола для доставки маркеров имеет ряд несомненных преимуществ. Соответственно, BGP-протокол допускает использование аналогичных BGP-маршрутов для доставки (распределения) маркеров, обеспечивая, таким образом, преимущество необходимого масштабирования по сравнению LDP-протоколом, если бы последний использовался для распределения маркеров между BGP-серверами.

3.29.2. Описание маркеров для RSVP-протокола, регулирующего трафик

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

3.29.3. Описание маркеров для явно устанавливаемых LSP-маршрутов

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

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

  • Начать с существующего протокола и использовать его для проведения резервирования ресурсов, а затем применить его для установления точного маршрута и распределения маркеров (RFC-3209, -3210);

  • Начать с существующего протокола, используемого для распределения маркеров, а затем применить его для установления точного маршрута и проведения резервирования ресурсов (RFC-3212).

4. Реализационные аспекты MPLS-архитектуры

4.1. MPLS-архитектура и трафик с поузловой маршрутизацией

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

4.1.1. Маркеры для префиксов адресов

Как правило, маршрутизатор R определяет следующий ретрансляционный участок для пакета P путём поиска в своей маршрутной таблице префикса адреса Х , который максимально (с точки зрения длины в битах) совпадает с адресом получателя в Р . Т.е., к пакетам определённого FEC-класса относятся только те пакеты, у которых адрес (часть адреса) совпадает префиксом адреса, указанного в маршрутной таблице R . В данном случае FEC-класс может идентифицироваться префиксом адреса.

Следует заметить, что пакет P может быть отнесён в FEC-классу F , а FEC-класс F может быть идентифицирован префиксом адреса X , даже если адрес получателя в пакете P не совпадает с X .

4.1.2. Распределение (доставка) маркеров для префиксов адресов

4.1.2.1. Взаимодействующие стороны при распределении маркеров для префиксов адресов

LSR-маршрутизаторы R 1 и R 2 рассматриваются как взаимодействующие стороны при распределении маркеров для префикса адреса X тогда и только тога, когда выполняется одно из следующий условий:

  1. Маршрут от R 1 до X является маршрутом, который стал известен, в частности, при проведения процедуры информационного обмена с использованием IGP-протокола (Interior Gateway Protocol), а R 2 является соседом R 1 и также использует данный протокол при взаимодействии с тем же сетевым объектом;

  2. Маршрут от R 1 до X является маршрутом, который стал известен после проведения процедуры информационного обмена при реализации некоторого алгоритма маршрутизации A 1 , и этот маршрут был перенаправлен к иному сетевому объекту, использующего другой алгоритм маршрутизации A 2 , а R 2 является соседом R 1 и также использует алгоритм маршрутизации A 2 ;

  3. R 1 является оконечной точной приёма LSP-туннеля, который располагается внутри другого LSP-маршрута, а R 2 является крайней точкой передачи этого же туннеля, и R 1 и R 2 являются участниками единого информационного взаимодействия с использованием IGP-протокола, а также входят в один сетевой IGP-сегмент (если конечно такой сегмент существует), и маршрут от R 1 до X стал известен с помощью проведения процедуры информационного обмена с использованием IGP-протокола или этот маршрут был перенаправлен R 1 в указанный сетевой IGP-сегмент;

  4. Маршрут от R 1 до X является маршрутом, который стал известен после проведения процедуры информационного обмена с использованием BGP-протокола (Border Gateway Protocol), а R 2 взаимодействует с R 1 на основе данного протокола.

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

4.1.2.2. Распределение (доставка) маркеров

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

  1. Прикреплять один или несколько маркеров к префиксу каждого адреса, который представлен в его маршрутной таблице;

  2. Для префикса X каждого такого адреса, использовать LDP-протокол для доставки каждой взаимодействующей с ним при распределении маркеров стороне привязки маркера к X ;

Кроме того, имеет место случай, когда LSR-маршрутизатор обязан доставлять привязку маркера для префикса адреса, даже если отсутствует LSR-маршрутизатор, который «привязал» этот маркер к данному префиксу адреса:

  1. Если R 1 применяет BGP-протокол для установления маршрута до X , именуя некоторый другой LSR-маршрутизатор R 2 как следующий ретрансляционный BGP-участок до X , и если R 1 знает, что R 2 «привязал» маркер L к X , то R 1 обязан доставить связку между L и X каждой взаимодействующей с ним на основе BGP-протокола стороне, через которую проложен данный маршрут.

Эти правила гарантируют то, что маркеры, соответствующие префиксам адресов, которые, в свою очередь, соответствуют BGP-маршрутам, будут доставлены IGP-соседям тогда и только тогда, когда BGP-маршруты будут доставлены в зону действия IGP-протокола. В противном случае, маркеры, привязанные к BGP-маршрутам, будут доставлены только другим активным BGP-модулям (серверам).

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

4.1.3. Использование маршрута с поузловой маршрутизацией в качестве LSP-маршрута

Если маршрут с поузловой маршрутизацией, по которому должен проследовать IP-пакет P , представляет собой <R 1 , ..., Rn >, то <R 1 , ..., Rn > может быть LSP-маршрутом до тех пор, пока:

  1. Существует одиночный префикс адреса X , причём такой, что для всех i , 1 ≤ i < n , X является самым длинным совпадением (с точки зрения длины в битах) при сравнении значения префикса адреса из маршрутной таблицы с IP-адресом получателя из заголовка IP-пакета;

  2. Для всех i , 1 < i < n , R 1 присвоил маркер к X и доставил этот маркер R i -1 .

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

Предположим, например, что IP-пакет P с IP-адресом получателя «10.2.153.178» необходимо доставить от R 1 до R 2 и до R 3 . Также предположим, что R 2 извещает R 1 о префиксе адреса «10.2/16», а R 3 извещает R 2 о «10.2.153/23», «10.2.154/23» и «10.2/16». Т.е., R 2 извещает R 1 об «агрегированном маршруте». В такой ситуации транслируемый IP-пакет P может коммутироваться на основе маркера, но до тех пор, пока он не достигнет R 2 , а так как R 2 осуществил агрегирование маршрута, то он обязан запустить процедуру поиска максимально длинного совпадения (по определённому алгоритму) с целью определения FEC-класса P .

4.1.4. Выход LSP-маршрута и уполномоченный узел выхода LSP-маршрута

LSR-маршрутизатор R считается «выходом LSP-маршрута» (LSP egress) для префикса адреса X тогда и только тогда, когда выполняется одно из следующих условий:

  1. R имеет IP-адрес Y , причем такой, что X , являясь префиксом адреса, указанным в маршрутной таблице R , максимально совпадает (с точки зрения длины в битах) с Y ;

  2. R содержит в своей маршрутной таблице один или несколько префиксов адресов Y , причём таких, что X является характерной начальной субпоследовательностью Y , но, в то же время, предшествующие ретрансляционные участки LSP-маршрута до R и относительно X не содержат каких-либо префиксов адресов Y . Т.е., R является «узлом (точкой) деагрегации» (deaggregation point) по отношению к префиксу адреса X .

LSR-маршрутизатор R 1 считается «уполномоченным узлом выхода R 1 » (LSP proxy egress) для префикса адреса X , если:

  1. Следующим ретрансляционным участком от R 1 относительно X является R 2 , а R 1 и R 2 не являются взаимодействующими сторонами при распределении (доставке) маркеров, что касается X (возможно из-за того, что R 2 не поддерживает MPLS-коммутацию);

  2. R 1 был настроен в качестве уполномоченного узла выхода LSP-маршрута относительно X .

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

4.1.5. Неявно выраженный нулевой маркер

Такой маркер (implicit NULL label) представляет собой маркер со специальным семантическим содержанием, который может быть привязан LSR-маршрутизатором к префиксу адреса. Если LSR-маршрутизатор Ru , после проведённой им ILM-процедуры, установит, что помеченный IP-пакет P должен быть доставлен по следующему ретрансляционному участку до Rd , а последний распространил информацию о привязке неявно выраженного нулевого маркера к соответствующему префиксу адреса, то вместо перемещения маркера на самый верх набора маркеров, Ru удаляет набор маркеров и после этого транслирует скорректированный IP-пакет Rd .

LSR-маршрутизатор Rd передаёт информацию о привязке не явно выраженного нулевого маркера к префиксу адреса X LSR-маршрутизатору Ru тогда и только тогда, когда:

  1. Правила, представленные в параграфе 4.1.2, указывают на то, что Rd передаёт Ru информацию о привязке маркера к X ;

  2. Rd знает, что Ru может обработать не явно выраженный нулевой маркер (т.е., что он может удалить («вытолкнуть») набор маркеров);

  3. Rd является выходом LSP-маршрута (а не уполномоченным узлом выхода LSP-маршрута) по отношению к X .

Сказанное выше означает, что предпоследний LSR-маршрутизатор на LSP-маршруте будет удалять набор маркеров. Такой подход вполне приемлем по следующим соображениям. Если выходом LSP-маршрута является выход MPLS-соединения для X , и если предпоследний LSR-маршрутизатор не удаляет набор маркеров, то на выходе LSP-маршрута надо будет найти маркер, удалить набор маркеров, а затем найти следующий маркер (или найти адрес третьего (сетевого) уровня, если, конечно, больше маркеров не представлено). Наличие предпоследнего LSR-маршрутизатора, который «выталкивает» набор маркеров, избавляет узел на выходе LSP-маршрута от процедуры поиска двух маркеров, необходимых для принятия решения о последующей ретрансляции IP-пакета.

Тем не менее, если предпоследний LSR-маршрутизатор является ATM-коммутатором, то он может быть не способен удалить набор маркеров. Следовательно, данные о привязке не явно выраженного нулевого маркера могут доставляться только LSR-маршрутизаторам, которые могут реализовать такую функцию.

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

4.1.6. Дополнительная функция: назначение целевого маркера выхода

Существуют ситуации, когда входной узел LSP-маршрута Ri (вход LSP-маршрута) знает, что все IP-пакеты, причём нескольких различных FEC-классов, должны следовать по одному и тому же LSP-маршруту, который прерывается на Re , являющимся выходом LSP-маршрута. В таком случае, соответствующая процедура маршрутизации может быть реализована на основе применения только одного маркера, но используемого для всех различных FEC-классов. Т.е., нет необходимости иметь индивидуальный маркер для каждого FEC-класса. Когда (и только когда) выполняются следующие условия:

  1. Сам адрес LSR-маршрутизатора Re представлен в маршрутной таблице в качестве «главного маршрута» (host route);

  2. Существует некоторый способ, с помощью которого Ri может определить, что Re является выходом LSP-маршрута для всех IP-пакетов, относящихся к некоторой совокупности FEC-классов.

Тогда Ri может установить привязку одного маркера ко всей совокупности FEC-классов. Такая процедура называется «назначение целевого маркера выхода» (egress-targeted label assignment).

Возникает справедливый вопрос: «А как LSR-маршрутизатор Ri может определить, что Re является выходом LSP-маршрута для всех IP-пакетов соответствующего FEC-класса?». Существует несколько возможных способов, а именно:

  • Если сеть функционирует с использованием алгоритма маршрутизации на основе состояния линий (каналов) связи, и все узлы этой сетевой зоны поддерживают MPLS-коммутацию, то алгоритм маршрутизации предоставляет Ri достаточно информации для определения маршрутизаторов, через которые IP-пакеты, относящиеся к определённому FEC-классу, должны покидать сетевой маршрутизационный сегмент (или зону).

  • Если функционирует с использованием BGP-протокола, то Ri имеет возможность определить, что IP-пакеты, относящиеся к определённому FEC-классу, должны покинуть сеть через конкретный маршрутизатор, который является началом следующего ретрансляционного участка с точки зрения BGP-протокола (BGP next hop) для данного FEC-класса.

  • Если допускается применение LDP-протокола для доставки информации о тех префиксах адресов, которые «закреплены» за конкретными выходными LSR-маршрутизаторами. Этот метод имеет преимущество, так как не зависит от наличия протоколов маршрутизации на основе состояния линий (каналов) связи.

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

Одним из возможных способов сетевой реализации назначения целевого маркера выхода может быть настройка на использование этой процедуры в режиме «по-умолчанию» (by default), но одновременно с этим следует настроить соответствующие LSR-маршрутизаторы так, чтобы они не использовали указанную процедуру по отношению к одному или нескольким префиксам адресов, которые соответствуют выходу LSP-маршрута. В таких случаях существует следующее правило:

  • Если некоторый LSR-маршрутизатор не является выходным узлом LSP-маршрута по отношению к некоторой совокупности префиксов адресов, то он должен назначать маркеры префиксам адресов тем же самым способом, как если бы он это делал в случае следующего ретрансляционного участка LSP-маршрута по отношению к этим же префиксам адресов. Т.е., предположим, что Rd является следующим ретрансляционным участком LSP-маршрута для Ru по отношению к префиксам адреса X 1 и X 2 . Если Rd назначил один и тот же маркер префиксам адреса X 1 и X 2 , то Ru должен сделать также. Если Rd назначил разные маркеры X 1 и X 2 , то Ru должен сделать также.

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

Очень важно отметить, что если Ru и Rd являются соседними LSR-маршрутизаторами в LSP-маршруте по отношению к X 1 и X 2 , и Ru присваивает индивидуальные маркеры X 1 и X 2 , в то время как Rd присваивает только один маркер обоим этим префиксам адресов, то доставка IP-пакетов будет по-прежнему корректной. Это означает лишь только то, что Rd будет отображать входящие маркеры в один и тот же исходящий маркер, т.е. самая заурядная ситуация.

Аналогично, если Rd присваивает индивидуальные маркеры X 1 и X 2 , а Ru присваивает им обоим только один маркер, соответствующий адресу их выходного узла LSP-маршрута или уполномоченного узла выхода LSP-маршрута, то доставка IP-пакетов будет по-прежнему корректной. Ru будет только отображать входящий маркер в другой маркер, который Rd присвоил адресу этому выходному узлу LSP-маршрута.

4.2. MPLS-архитектура и точно настраиваемый LSP-маршруты

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

4.2.1. Точно настраиваемые LSP-туннели

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

В рамках MPLS-архитектуры это легко выполнимо с помощью точно настраиваемых LSP-туннелей. Всё, что необходимо для этого, следующее:

  1. Средства селектирования IP-пакетов, которые должны быть доставлены по точно настраиваемому LSP-туннелю;

  2. Средства установки точно настраиваемого LSP-туннеля;

  3. Средства, гарантирующие, что IP-пакеты, транслируемые по туннелю, не попадут на петлевой маршрут, т.е. из крайней точки приёма — обратно в крайнюю точку передачи.

Если крайняя точка передачи в туннеле «желает» направить помеченный IP-пакет в туннель, она обязана, во-первых, заменить значение самого верхнего маркера в наборе маркеров на значение маркера, которое было передано ей крайней точкой приёма в туннеле. Затем она обязана вставить маркер, который соответствует её месту в туннеле, и который был ей передан с противоположной точки следующего ретрансляционного участка, входящего в туннель. Чтобы реализовать всё сказанное выше крайние точки туннеля должны быть непосредственно взаимодействующими сторонами при проведении процедуры доставки (распределения) маркеров. Данные о привязках маркеров, которые им необходимы для обмена, не входят в круг интересов LSR-маршрутизаторов, расположенных вдоль туннеля.

4.3. Наборы маркеров и процедура неявного информационного обмена маркерами

Предположим, что некоторый LSR-маршрутизатор Re является уполномоченным узлом выхода LSP-маршрута по отношению к 10 префиксам адресов, и он связан с каждым префиксом адреса через индивидуальный интерфейс.

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

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

Альтернативой всему сказанному выше может быть привязка всех 10 префиксов адресов к одному и тому же маркеру 1-го уровня (который также связан с адресом самого LSR-маршрутизатора), а затем — привязка каждого префикса адреса к индивидуальному маркеру 2-го уровня. Маркер 2-го уровня можно рассматривать как атрибут привязки маркера 1-го уровня, который именуется «атрибутом набора (маркеров)» (stack attribute). Для таких случаев существуют следующие правила:

  • Когда LSR-маршрутизатор Ru в начальной стадии помечает всё ещё не помеченный IP-пакет, и если максимально длинная битовая последовательность, совпавшая с адресом получателя заголовка IP-пакета, является X , и если противоположным узлом следующего ретрансляционного участка LSP-маршрута для Ru по отношению к X является Rd , и если Rd передал Ru данные о привязке маркера L 1 к X и атрибуте набора маркеров L 2 , тогда:

    1. Ru обязан вставить L 2 , а затем L 1 в набор маркеров IP-пакета, и после этого ретранслировать IP-пакет Rd .

    2. Когда Ru распространяет информацию о привязках маркера к X среди взаимодействующих с ним сторон по доставке маркеров, он обязан включить в эти данные L 2 , как атрибут набора маркеров.

    3. Всякий раз, когда атрибут набора маркеров изменяется (возможно, в результате изменения на следующем ретрансляционном участке LSP-маршрута для Ru по отношению к X ), Ru обязан распространить информацию о новом атрибуте набора маркеров.

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

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

4.4. MPLS-архитектура и многонаправленная маршрутизация

Если LSR-маршрутизатор «предоставляет» несколько маршрутов для некоторого потока, то он может присвоить несколько маркеров к потоку, т.е. по одному на каждый маршрут. Соответственно, получение от определённого соседа привязки второго маркера к некоторому префиксу адреса должно рассматриваться следующим образом: тот или иной маркер может использоваться для представления этого префикса адреса.

Если для некоторого префикса адреса установлено несколько привязок маркеров, то они могут иметь индивидуальные атрибуты.

4.5. Сходящиеся деревья из LSP-маршрутов

Рассмотрим случай доставки двух IP-пакетов P 1 и P 2 , каждый из которых имеет адрес получателя, а в соответствующем сегменте маршрутизации эти адреса имеют максимально длинную одинаковую битовую последовательность, образующую префикс адреса X . Предположим, что для P 1 маршрутом с поузловой маршрутизацией является <R 1 , R 2 , R 3 >, а для P 2 — <R 4 , R 2 , R 3 >. Теперь предположим, что R 3 привязывает маркер L 3 к X , и сообщает об этой привязке R 2 . R 2 привязывает маркер L 2 к X , и сообщает об этой привязке R 1 и R 4 . Когда R 2 получает IP-пакет P 1 , его входящим маркером будет L 2 . R 2 заменит L 2 на L 3 и отправит P 1 в R 3 . Когда R 2 получает IP-пакет P 2 , его входящим маркером снова будет L 2 . И R 2 опять заменит L 2 на L 3 и отправит P 2 в R 3 .

Заметим, что когда P 1 и P 2 транслируются от R 2 в R 3 , то они содержат один и тот же маркер, причём так долго, насколько продолжительна MPLS-система, и поэтому их невозможно различить. Таким образом, вместо анализа двух индивидуальных LSP-маршрутов <R 1 , R 2 , R 3 > и <R 4 , R 2 , R 3 > можно рассмотреть одно «сходящееся дерево из LSP-маршрутов (сходящийся граф)» (multipoint-to-point LSP tree), и обозначить его как <{R 1 , R 4 }, R 2 , R 3 >.

Такой подход создаёт определённые трудности, особенно при использовании стандартных ATM-коммутаторов в качестве LSR-маршрутизаторов. Так как обычные ATM-коммутаторы на поддерживают сходящиеся виртуальные соединения (multipoint-to-point connections), должны существовать процедуры, которые гарантируют, что каждый LSP-маршрут представляет собой сквозное виртуальной соединение (point-to-point VC). Тем не менее, если используются ATM-коммутаторы, которые поддерживают сходящиеся виртуальные соединения, то LSP-маршруты могут быть более эффективно реализованы как сходящиеся виртуальные соединения. С другой стороны, если можно использовать многоузловое кодирование коммутируемого виртуального маршрута (параграф 3.25.2, SVP multipoint encoding), то LSP-маршруты могут быть реализованы как сходящиеся коммутируемые виртуальные маршруты (multipoint-to-point SVP).

4.6. Формирование LSP-туннелей между граничными BGP-маршрутизаторами

Рассмотрим случай функционирования автономной системы A (autonomous system), которая транслирует трафик между другими автономными системами. Автономная система A будет несколько граничных BGP-маршрутизаторов и совокупность BGP-соединений между ними, а на основе этих BGP-соединений формируются BGP-маршруты. Во многих подобных ситуациях весьма нежелательно прокладывать BGP-маршруты до маршрутизаторов, которые не являются граничными BGP-маршрутизаторами. Если всё-таки это можно избежать, то объём данных о распределённых маршрутах, хранящихся в памяти таких маршрутизаторов, значительно снижается. Тем не менее, должны предусматриваться средства, которые бы гарантировали, что транзитный трафик будет доставлен от одного граничного маршрутизатора к другому граничному маршрутизатору с помощью внутренних маршрутизаторов.

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

  1. Каждый граничный BGP-маршрутизатор транслирует (каждому другому граничному BGP-маршрутизатору в рамках одной автономной система) маркер для каждого префикса адреса, которые он передал каждому такому маршрутизатору с помощью BGP-протокола;

  2. IGP-протокол в интересах всей автономной системы устанавливает главный маршрут до каждого граничного BGP-маршрутизатора. Каждый внутренний маршрутизатор транслирует свои маркеры по этим главным маршрутам каждому своему IGP-соседу;

  3. Предположим, что:

    1. граничный BGP-маршрутизатор B 1 получает непомеченный IP-пакет P ;

    2. префикс адреса X в маршрутной таблице B 1 является максимально длинной последовательностью, совпадающей с адресом получателя P ;

    3. маршрут до X является BGP-маршрутом;

    4. следующий ретрансляционный участок BGP-маршрута по отношению к X является B 2 ;

    5. B 2 «привязал» маркер L 1 к X , а также передал B 1 данные об этой привязке;

    6. следующий ретрансляционный участок IGP-маршрута по отношению к адресу B 2 является I 1 ;

    7. адрес B 2 указан в IGP-маршрутных таблицах B 1 и I 1 как главный маршрут;

    8. I 1 «привязал» маркер L 2 к адресу B 2 , а также передал B 1 данные об этой привязке.

    Затем, перед отправкой IP-пакета P в I 1 , B 1 обязан сформировать набор маркеров для P , и после этого вставить поочередно вначале маркер L 1 и потом маркер L 2 ;

  4. Предположим, что граничный BGP-маршрутизатор B 1 получил маркированный IP-пакет P , в котором маркер верхнего уровня в наборе маркеров соответствует префиксу адреса X , и который следует по BGP-маршруту, и что выполняются все условия 3.b), 3.c), 3.d), и 3.e). Затем, перед отправкой IP-пакета P в I 1 , B 1 обязан заменить самый верхний маркер в наборе маркеров на L 1 и потом вставить маркер L 2 .

После всех описанных процедур данный IP-пакет P следует по LSP-маршруту 1-го уровня, все узлы которого являются граничными BGP-маршрутизаторами, а между каждой парой граничных BGP-маршрутизаторов, расположенных на LSP-маршруте 1-го уровня, этот IP-пакет P следует по LSP-маршруту 2-го уровня.

Рассмотренные процедуры позволяют эффективно сформировать LSP-туннель с поузловой маршрутизацией между граничными BGP-маршрутизаторами. Так как граничные BGP-маршрутизаторы обмениваются данными о привязках маркеров к префиксам адресов, которые остаются неизвестными при IGP-маршрутизации, BGP-маршрутизаторы должны переходить в режим прямого двустороннего информационного обмена маркерами, причём каждый с каждым.

Иногда бывает, что можно сформировать LSP-туннели с поузловой маршрутизацией между двумя граничными BGP-маршрутизаторами, даже если они не входят в одну и ту же автономную систему. Предположим, например, что B 1 и B 2 принадлежат одной автономной системе AS 1 . Также считаем, что B 3 является EBGP-соседом B 2 . И последнее, полагаем, что B 2 и B 3 входят в некоторую сеть, которая является общей для обеих автономных систем (так называемая демилитаризованная зона, demilitarized zone). В этом случае LSP-туннель может быть установлен между B 1 и B 3 напрямую следующим образом:

  • B 3 прокладывает маршруты до B 2 (используя EBGP-протокол), и дополнительно назначает маркеры префиксам адресов;

  • B 2 продлевает эти маршруты до B 1 (используя IBGP-протокол), указывая на то, что следующим ретрансляционным участком для каждого такого BGP-маршрута является B 3 . Если B 3 присваивает маркеры префиксам адресов, то B 2 транслирует дальше эти маркеры до B 1 без изменений;

  • AS 1 , реализующей IGP-протокол, известен главный маршрут до B 3 .

4.7. Другие варианты применения LSP-туннелей с поузловой маршрутизацией

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

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

4.8. MPLS-архитектура и системы с групповой адресацией

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

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

IP-пакет может быть передан на все вершины дерева (графа).

5. Процедуры распределения (доставки) маркеров (при поузловой маршрутизации)

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

5.1. Процедуры для оповещения о маркерах и для использования маркеров

Существует несколько процедур, которые можно использовать для доставки (распределения) данных о привязках маркеров. Некоторые процедуры используются LSRНП , а некоторые используются LSRВП .

LSRНП обязаны выполнять следующие процедуры:

  • процедура «доставки/распределения» (distribution procedure);
  • процедура «изъятия» (withdrawal procedure).

LSRВП обязаны выполнять следующие процедуры:

  • процедура «запроса» (request procedure);
  • процедура «недопустимо» (not available procedure);
  • процедура «расцепления» (release procedure);
  • процедура «использования маркера» (label use procedure).

MPLS-архитектура включает несколько вариантов каждой из процедур.

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

5.1.1. LSR-маршрутизатор нисходящего потока: процедура «доставки/распределения»

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

Независимо от того, какая процедура используется, если информация о привязке маркера по отношению к некоторому префиксу адреса был направлена LSRНП Rd в LSRВП Ru , и если в какой-то момент времени атрибуты (как было сказано выше) этой привязки изменились, то Rd обязан сообщить Ru новые атрибуты.

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

5.1.1.1. Субпроцедура «безусловная вставка» (PushUnconditional)

Пусть Rd будет LSR-маршрутизатором. Предположим, что:

  1. X представляет собой префикс адреса в маршрутной таблице Rd ;

  2. Ru является взаимодействующей с Rd стороной в процедуре обмена маркерами, что касается X .

Всякий раз, когда эти условия соблюдены, Rd обязан привязать маркер к X и направить данные об этой привязке Ru . Rd несёт ответственность за хранение переданных Ru данных (записи) об этой привязке, а также за обеспечение гарантий того, что Ru всегда будет имеет данные о новых привязках.

Данной субпроцедурой могут воспользоваться LSR-маршрутизаторы, которые осуществляют анализ невостребованных маркеров нисходящего потока в режиме независимого контроля LSP-маршрута (independent LSP control mode).

5.1.1.2. Субпроцедура «условная вставка» (PushConditional)

Пусть Rd будет LSR-маршрутизатором. Предположим, что:

  1. X представляет собой префикс адреса в маршрутной таблице Rd ;

  2. Ru является взаимодействующей с Rd стороной в процедуре обмена маркерами, что касается X ;

  3. Rd является, либо входом, либо выходом LSP-маршрута по отношению к X , или противоположной стороной следующего ретрансляционного участка на 3-м (сетевом) уровне для Rd по отношению к X является Rn , а последний привязал маркер к X и отправил данные об этой привязке Rd .

Далее, как только все эти условия выполнены, Rd обязан привязать маркер к X и направить данные об этой привязке Ru .

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

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

5.1.1.3. Субпроцедура «безусловное извлечение» (PulledUnconditional)

Пусть Rd будет LSR-маршрутизатором. Предположим, что:

  1. X представляет собой префикс адреса в маршрутной таблице Rd ;

  2. Ru является взаимодействующей с Rd стороной в процедуре обмена маркерами, что касается X ;

  3. Ru в явной форме затребовал, чтобы Rd привязал маркер к X и передал данные об это привязке Ru .

Затем, Rd должен привязать маркер к X и направить данные об этой привязке Ru . Следует отметить, что если X отсутствует в маршрутной таблице Rd , или если Rd не является взаимодействующей с Ru стороной в процедуре обмена маркерами, что касается X , то Rd обязан проинформировать Ru о том, что он не может обеспечить привязку в настоящее время.

Если Rd уже передал Ru данные о привязке по отношению к префиксу адреса X , и он получил от Ru новый запрос на привязку по отношению к префиксу адреса X , то он выполнить привязку второго маркера и направит Ru данные о новой привязке. Привязка первого маркера остаётся в действии.

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

5.1.1.4. Субпроцедура «условное извлечение» (PulledConditional)

Пусть Rd будет LSR-маршрутизатором. Предположим, что:

  1. X представляет собой префикс адреса в маршрутной таблице Rd ;

  2. Ru является взаимодействующей с Rd стороной в процедуре обмена маркерами, что касается X ;

  3. Ru в явной форме затребовал, чтобы Rd привязал маркер к X и передал данные об это привязке Ru ;

  4. Rd является, либо входом, либо выходом LSP-маршрута по отношению к X , или противоположной стороной следующего ретрансляционного участка на 3-м (сетевом) уровне для Rd по отношению к X является Rn , а последний отличается от Ru , и Rn привязал маркер к X и отправил данные об этой привязке Rd .

Далее, как только все эти условия выполнены, Rd должен привязать маркер к X и направить данные об этой привязке Ru . Следует заметить, что если в маршрутной таблице Rd отсутствует X , а данные о привязке к X не доступны со стороны следующего ретрансляционного участка по отношению к X , или если Rd не является взаимодействующей с Ru стороной в процедуре обмена маркерами, что касается X , то Rd обязан проинформировать Ru , что в настоящий момент он не способен обеспечить привязку. Тем не менее, если только какое-либо условие не выполнимо, и это привело к тому, что Rn всё ещё не может предоставить маркер Rd , то последний обязан отложить передачу Ru какого-либо ответа до тех пор, пока он не получит данные о привязке от Rn .

Если Rd отправил Ru данные о привязке маркера к префиксу адреса X , а через некоторое время изменился какой-либо атрибут привязки маркера, то Rd обязан повторно направить Ru данные о привязке маркера с новым атрибутом. Он должен это сделать даже тогда, когда Ru не направил новый запрос.

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

5.1.2. LSR-маршрутизатор восходящего потока: процедура «запроса»

Процедура «запроса» используется LSRВП с целью определения префикса адреса, т.е. когда следует направить запрос в явной форме, чтобы LSRНП привязал маркер к этому префиксу и передал данные об этой привязке. Существуют три субпроцедуры, которые могут быть использованы.

5.1.2.1. Субпроцедура «никогда не направлять запрос» (RequestNever)

Процедура «никогда не направлять запрос» полезна тогда, когда LSRНП использует субпроцедуру «условная вставка» или «безусловная вставка», но не допустима тогда, когда LSRНП использует субпроцедуру «безусловное извлечение» или «условное извлечение».

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

5.1.2.2. Субпроцедура «направлять запрос, когда необходимо» (RequestWhenNeeded)

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

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

5.1.2.3. Субпроцедура «направление запроса в ответ на запрос» (RequestOnRequest)

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

Если Rd получил такой запрос от Ru относительно префикса адреса, для которого Rd уже направил маркер Ru , то Rd должен выделить новый (индивидуальный) маркер и привязать последний к X , а затем распространить данные об этой привязке. (Либо Rd может направить данные о такой привязке непосредственно Ru , либо независимо от того, используется или нет процедура доставки/распределения.)

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

5.1.3. LSR-маршрутизатор восходящего потока: процедура «недопустимо» (NotAvailable)

Если Ru и Rd являются LSRВП и LSRНП , соответственно, и взаимодействующими сторонами при обмене маркерами относительно префикса адреса X , и Rd является для Ru противоположной стороной следующего ретрансляционного участка относительно X , а Ru запрашивает от Rd данные о привязке к X , но Rd отвечает, что в настоящий момент не может сформировать привязку, так как не обладает информацией о следующем ретрансляционном участке относительно X , то процедура «недопустимо» позволяет определить, как Ru следует ответить. Существуют две возможные субпроцедуры, которые определяют дальнейшее поведение Ru .

5.1.3.1. Субпроцедура «повторение запроса» (RequestRetry)

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

5.1.3.2. Субпроцедура «не повторять запрос» (RequestNoRetry)

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

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

5.1.4. LSR-маршрутизатор восходящего потока: процедура «расцепления»

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

5.1.4.1. Субпроцедура «расцепление при изменениях» (ReleaseOnChange)

Ru должен удалить («расцепить») привязку и проинформировать Rd о том, что он это осуществил. Данной субпроцедурой можно воспользоваться при реализации «консервативного режима сохранения маркера потока».

5.1.4.2. Субпроцедура «не удалять привязку при изменениях» (NoReleaseOnChange)

Ru должен сформировать привязку, причём такую, чтобы он смог её использовать повторно и сразу после того, как Rd станет для Ru следующим ретрансляционным участком 3-го уровня относительно префикса адреса X . Данной субпроцедурой можно воспользоваться при реализации «свободного режима сохранения маркера потока».

5.1.5. LSR-маршрутизатор восходящего потока: процедура «использования маркера»

Предположим, что Ru является LSR-маршрутизатором, который получил от LSR-маршрутизатора Rd данные о привязке маркера L к префиксу адреса X , а Ru является LSRВП по отношению к Rd , что касается X , и, фактически, Rd является для Ru следующим ретрансляционным участком 3-го уровня относительно префикса адреса X .

Ru будет использовать привязку, если Rd является для Ru следующим ретрансляционным участком 3-го уровня относительно префикса адреса X . Если в некоторый момент времени Ru получает привязку, а Rd не является для Ru следующим ретрансляционным участком 3-го уровня относительно префикса адреса X , то в это время Ru не использует каким-либо образом привязку. Тем не менее, по прошествии некоторого времени Ru может начать использование привязки, если Rd станет для Ru следующим ретрансляционным участком 3-го уровня относительно префикса адреса X .

Процедура «использование маркера» определяет только, как Ru использует привязку Rd .

Существуют только две субпроцедуры, которые может использовать Ru .

5.1.5.1. Субпроцедура «незамедлительное использование» (UseImmediate)

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

5.1.5.2. Субпроцедура «использование, если не выявлен петлевой маршрут» (UseIfLoopNotDetected)

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

5.1.6. LSR-маршрутизатор нисходящего потока: процедура «изъятия»

В данном случае, существует только одна процедура.

Когда LSR-маршрутизатор Rd принимает решение об аннулировании привязки маркера L к префиксу адреса X , то данные об изъятии привязки должны быть направлены всем LSR-маршрутизаторам, которым были ранее направлены данные о сформировании привязки.

Это требует, чтобы данные об изъятии привязки L к X были направлены Rd LSR-маршрутизатору Ru ещё до того, как Rd направит Ru данные о какойлибо новой привязке L к любому другому префиксу адреса Y (где X ≠ Y ). Если Ru был бы оповещён о новой привязке L к Y ещё до того, как он узнал об изъятии привязки L к X , и если бы адреса IP-пакетов совпадали, и с X , и с Y , то на протяжении некоторого периода времени Ru мог бы помечать, и IP-пакеты, адреса которых совпадают с X , и IP-пакеты, адреса которых совпадают Y , с помощью маркера L .

Распределение и изъятие привязок маркеров осуществляется с помощью LDP-протокола. Все LDP-протоколы требуют, чтобы две стороны обмена маркерами были смежными (соседями) при доставке/распределении маркеров (за исключением, сторон неявной процедуры обмена маркерами). Если LSR-маршрутизатор R 1 и LSR-маршрутизатор R 2 являются соседями (смежными узлами) при распределении маркеров между собой, и R 1 получил от R 2 данные о привязках маркеров, используя «соседство» с ним, и если затем такое «соседство» будет нарушено (разорвано вследствие, либо нештатной ситуации, либо выполнения штатной процедуры, предусматривающей такой разрыв) одной из сторон (одним из LSR-маршрутизаторов), то все полученные за счёт «соседства» данные о привязках должны рассматриваться как изъятые.

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

5.2. MPLS-схемы: допустимые комбинации процедур

Рассмотрим два LSR-маршрутизатора Ru и Rd , которые являются взаимодействующими сторонами в процедуре обмена маркерами относительно некоторой совокупности префиксов, и при этом Ru является LSRВП , а и Rd — LSRНП .

MPLS-схема, которая управляет взаимодействием Ru и Rd , может быть определена как кортеж из пяти процедур: <DistributionProcedure, RequestProcedure, NotAvailableProcedure, ReleaseProcedure, LabelUseProcedure> (<доставка/распределение, запрос, недопустимо, расцепление, использование маркера>). (Так как существует только одна процедура «изъятия» (WithdrawProcedure), то нет необходимости её указывать.) Символ «*», расположенный на одной из позиций, является универсальным свободно замещаемым символом (wild-card), означающий, что в этом месте может быть представлена любая субпроцедура из этой категории. Символ «N/A», расположенный на соответствующей позиции, указывает на то, что субпроцедура в данной категории не нужна.

MPLS-архитектура рассматривает только следующие MPLS-схемы.

5.2.1. Схемы для LSR-маршрутизаторов, которые реализуют слияние маркеров

Если Ru и Rd являются взаимодействующими сторонами в процедуре обмена маркерами, и оба реализуют функцию слияния маркеров, то должна использоваться одна из следующих MPLS-схем:

  1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate>

    Данная схема представляет собой распределение невостребованных маркеров нисходящего потока с независимым контролем (анализом), при реализации «свободного режима сохранения маркера потока» и без процедуры выявления петлевого маршрута.

  2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

    Данная схема представляет собой распределение невостребованных маркеров нисходящего потока с независимым контролем (анализом), при реализации «свободного режима сохранения маркера потока» и процедуры выявления петлевого маршрута.

  3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>

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

  4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

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

  5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

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

  6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>

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

  7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected >

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

5.2.2. Схемы для LSR-маршрутизаторов, которые не реализуют слияние маркеров

Предположим, что R 1 , R 2 , R 3 и R 4 являются ATM-коммутаторами, которые не реализуют слияние маркеров, но используются в качестве LSR-маршрутизаторов. В дальнейшем будем считать, что <R 1 , R 2 , R 3 , R 4 > является маршрутом с поузловой маршрутизацией 3-го уровня относительно префикса адреса X , и что IP-пакеты, предназначенные для X , могут поступить в сеть через любой из этих LSR-маршрутизаторов. Так как не существует предпосылок для появления сходящихся маршрутов, LSP-маршруты должны представлять собой сквозные виртуальные соединения, а это означает, в сети должны три таких виртуальных маршрута относительно префикса адреса X: <R 1 , R 2 , R 3 , R 4 >, <R 2 , R 3 , R 4 >, и <R 3 , R 4 >.

Более того, если R 1 и R 2 являются MPLS-узлами, а также один из них является LSR-маршрутизатором, который встроен в стандартный программно-аппаратный ATM-коммутатор (т.е., в котором не блокируется перемежение ячеек), или по какой-либо другой причине не возможно реализовать функцию слияния маркеров, то между R 1 и R 2 должна использоваться одна из следующих MPLS-схем:

  1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

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

    В результате использования субпроцедуры «направление запроса в ответ на запрос» (RequestOnRequest) R 4 направит R 3 три маркера относительно X , R 3 направит R 2 два маркера относительно X и R 2 направит R 1 один маркер относительно X .

  2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>

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

  3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

5.2.3. Условия функциональной совместимости

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

  • <PulledUnconditional, RequestNever, *, *, *> и <PulledConditional, RequestNever, *, *, *>

    В данных MPLS-схемах LSRНП Rd направляет LSRВП Ru данные о привязках маркеров только по запросу Ru , но Ru никогда не направляет такие запросы. Очевидно, что эти схемы не жизнеспособны, так как они не обеспечат надлежащую доставку данных о привязках маркеров.

  • <*, RequestNever, *, *, ReleaseOnChange>

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

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

  1. Каждый обязан явно продемонстрировать свою способность осуществлять слияние маркеров.

  2. Если Rd не обеспечивает слияние маркеров, то он обязан выбрать одну из двух субпроцедур, либо «безусловное извлечение» (PulledUnconditional), либо «условное извлечение» (PulledConditional). Если Rd выбрал субпроцедуру «условное извлечение», то он вынужден использовать субпроцедуру «повторение запроса» (RequestRetry). Т.е., если LSRНП не поддерживает слияние маркеров, то его предпочтения являются приоритетными при выборе MPLS-схемы.

  3. Если Ru не обеспечивает слияние маркеров, а Rd обеспечивает, то Ru обязан выбрать одну из двух субпроцедур, либо «повторение запроса» (RequestRetry), либо «не повторять запрос» (RequestNoRetry). Это вынуждает Rd использовать из двух субпроцедур, либо «условное извлечение» (PulledConditional), либо «безусловное извлечение» (PulledUnconditional), соответственно. Т.е., если только один из LSR-маршрутизаторов не поддерживает слияние маркеров, то его предпочтения являются приоритетными при выборе MPLS-схемы.

  4. Если оба, Rd и Ru , реализуют процедуру слияния маркеров, выбор одного их двух режимов сохранения маркеров, свободного или консервативного режима, принадлежит Ru . Т.е., Ru предоставляется выбор использования субпроцедур, либо «RequestWhenNeeded/ReleaseOnChange» (консервативный режим), либо «RequestNever/NoReleaseOnChange» (свободный режим). Однако, право выбора «вставка» или «извлечение» и «условный» или «безусловный» принадлежит Rd . Если Ru выбирает свободный режим сохранения маркеров, то Rd может выбрать одну из двух субпроцедур, либо «безусловная вставка», либо «условная вставка». Если Ru выбирает консервативный режим сохранения маркеров, то Rd может выбрать одну из трёх субпроцедур, либо «условная вставка», либо «условное извлечение», либо «безусловное извлечение». Все вместе эти варианты выбора определяют используемую MPLS-схему.

6. Вопросы информационной безопасности

Некоторые маршрутизаторы могут использовать специализированные процедуры обеспечения информационной безопасности (ИБ), которые зависят заголовка сетевого уровня, который размещается в конкретном месте, связанным с заголовком канального уровня. Универсальная MPLS-процедура повторного обрамления подразумевает размещение дополнительного поля между заголовками канального и сетевого уровней. Такая вставка может повлечь за собой нарушение процедур обеспечения ИБ.

MPLS-маркер имеет собственное значение на основе действующего соглашения между LSR-маршрутизатором, который вставляет маркер в набор маркеров («автор маркера», label writer), и LSR-маршрутизатором, который интерпретирует этот маркер («считыватель маркер», label reader). Если помеченные IP-пакеты поступают из ненадёжных источников, или если некоторый входящий маркер был получен от LSR-маршрутизатора, который, в свою очередь, такой маркер не получал, то такие IP-пакеты могут ретранслированы нелегитимным способом.

Ссылки

[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. и P. Doolan, «Применение MPLS-коммутации в сетях с асинхронным режимом доставки», RFC 3035, Январь 2001.
[MPLS-BGP] «Carrying Label Information in BGP-4», Rekhter, Rosen, Work in Progress.
[MPLS-CR-LDP] «Constraint-Based LSP Setup using LDP», Jamoussi, Editor, Work in Progress.
[MPLS-FRMRLY] Conta, A., Doolan, P. и A. Malis, «Применение MPLS-коммутации в сетях с ретрансляцией кадров», RFC 3034, Январь 2001.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. и B. Thomas, «LDP Specification», RFC 3036, Январь 2001.
[MPLS-RSVP-TUNNELS] «Extensions to RSVP for LSP Tunnels», Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. и A. Conta, «Кодирование набора маркеров в MPLS-системах», RFC 3032, Январь 2001.
[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. и J. McManus, «Requirements for Traffic Engineering Over MPLS», RFC 2702, Сентябрь 1999.
2007 - 2022 © Русские переводы RFC, IETF, ISOC.