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

11.4. Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

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

При обычной IP-переадресации маршрутизатор рассматривает два пакета как принадлежащие к одному FEC, если существует адресный префикс X в таблицах маршрутизации маршрутизатора, такой, что Х, соответствует каждому адресу места назначения. Когда пакет проходит через сеть, на каждом шагу он последовательно просматривается и ему присваивается FEC.

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

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

Некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только с целью выбора следующего шага, но и для определения приоритета и класса услуг. Они могут затем применить различные пороги отсева или графика обслуживания пакетов. MPLS допускает (но не требует) приоритетность или класс обслуживания, зависящие полностью или частично от метки. В этом случае можно сказать, что метка представляет собой комбинацию FEC, приоритета или класса обслуживания. В MPLS Multiprotocol означает многопротокольный, так как его техника применима к любому протоколу сетевого уровня. Здесь, однако, внимание сконцентрировано на использовании IP в качестве протокола сетевого уровня. Маршрутизатор, который поддерживает MPLS, называется Label Switching Router, или LSR (маршрутизатором с коммутацией по меткам).

Терминология

(FEC) forwarding equivalence class

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

Label merging — объединение меток

Замещение множественных приходящих меток для определенного FEC одной выходной меткой

Label swap — инверсия меток

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

Label swapping

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

Label switched hop

Шаг между двумя узлами MPLS, на которые осуществляется переадресация с привлечением меток

Label switched path — путь с коммутацией меток

Путь через один или более LSR на одном уровне иерархии для пакетов с определенным FEC

Label switching router

Узел MPLS, который способен переадресовывать пакеты L3 согласно их меткам

Loop detection — детектирование петель

Метод, при котором разрешено формирование петлевых маршрутов; такие структуры позднее выявляются

Loop prevention — предотвращение петель

Метод, при котором данные никогда не передаются по петлевым маршрутам

Merge point

Узел, в котором произведено объединение меток

MPLS domain — домен MPLS

Непрерывный набор узлов, реализующих MPLS-маршрутизацию и находящихся в одном маршрутном и административном домене

MPLS edge node — пограничный узел MPLS

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

MPLS egress node — выходной узел MPLS

Пограничный узел MPLS, если через него трафик выходит из домена MPLS

MPLS ingress node — входной узел MPLS

Пограничный узел MPLS, если через него трафик входит в домен MPLS

MPLS label — метка MPLS

Метка, которая содержится в заголовке пакета и которая представляет FEC пакета

MPLS node — узел MPLS

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

VC merge — объединение VC

Объединение меток, когда метка MPLS переносится в поле ATM VCI (или в комбинации полей VPI/VCI), чтобы позволить объединение нескольких VC в один VC

VP merge — объединение VP

Объединение меток, когда метка MPLS переносится в поле ATM VPI, чтобы позволить объединение нескольких VP в один. В этом случае две ячейки будут иметь одно и то же значение VCI, только если отправлены из одного узла. Это позволяет различать ячейки разных отправителей с помощью VCI

VPI/VCI

Метка, используемая в сетях ATM для идентификации виртуального канала

Акронимы и аббревиатуры

DLCI — Data Link Circuit Identifier — идентификатор канала передачи данных

FEC — Forwarding Equivalence Class — класс переадресации

FTN — FEC to NHLFE Map — соответствие FEC и NHLFE

IGP — Interior Gateway Protocol — внутренний протокол маршрутизации

ILM — Incoming Label Map — таблица соответствия входящих меток

LDP — Label Distribution Protocol — протокол пересылки меток

LSP — Label Switched Path — путь с коммутацией меток

LSR — Label Switching Router — маршрутизатор c коммутацией меток

NHLFE — Next Hop Label Forwarding Entry — запись, содержащая адрес следующего шага при коммутации меток

SVC — Switched Virtual Circuit — переключаемая виртуальная схема

SVP — Switched Virtual Path — переключаемый виртуальный путь

VC — Virtual Circuit — виртуальная схема

VCI — Virtual Circuit Identifier — идентификатор виртуальной схемы

VP — Virtual Path — виртуальный путь

VPI — Virtual Path Identifier — идентификатор виртуального пути.

Основы MPLS

Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет собой класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующийся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает с этим адресом.

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

Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной.

Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR.

Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеется соответствие между меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR.

Вышестоящие и нижестоящие LSR

Предположим, что Ru и Rd договорились о соответствии метки L и FEC F для пакетов, посланных из Ru в Rd. Тогда, с учетом этого соответствия, Ru является вышестоящим LSR, а Rd — нижестоящим LSR.

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

Помеченные пакеты

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

Метод кодирования метки должен быть согласован субъектом, ее формирующим, и субъектом-адресатом.

Присвоение меток и рассылка

В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются снизу-вверх.

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

Атрибуты ассоциации меток (Label Binding)

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

Протоколы рассылки меток

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

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

Архитектура не предполагает, что должен существовать только один протокол рассылки меток (см. описание протокола LDP). В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылку меток можно было совместить с ними (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы, предназначенные специально для задач рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]).

Unsolicited Downstream против DownstreamonDemand

Архитектура MPLS позволяет LSR посылать запросы узлу следующего шага для конкретного FEC и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstreamondemand).

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

Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstreamondemand, другие — только в режиме unsolicited downstream, а некоторые — в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена.

Режим удержания меток (Retention Mode)

LSR Ru может получить (или уже получил) от LSR Rd ассоциацию метка-FEC, несмотря на то, что Rd не является следующим шагом для Ru (для данного FEC).

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

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

Стек меток

До сих пор мы обсуждали проблему в предположении, что помеченные пакеты несут в себе только одну метку. Как мы увидим, полезно иметь более обобщенную модель, в которой помеченные пакеты несут в себе несколько меток, уложенных в порядке последний_вошел-первым_вышел (LIFO). Мы будем называть это стеком меток.

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

Непомеченный пакет может рассматриваться как пакет, чей стек меток пуст (т.e., глубина стека которого равна 0).

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

На вход сети MPLS пакет попадает в узле А1. Здесь пакету присваивается метка, и он переадресуется далее. После передачи пакета из узла сетевого провайдера SPA в узел провайдера SPB, в стек пакета добавляется еще одна метка. Далее пакет передается по сети SPB (узлы B1 -> B4 ). После передачи пакета из узла В4 в узел С1 в стек меток добавляется еще одна метка. Когда пакет покидает сеть SPC, одна из меток из стека удаляется (С5?B5). Аналогичная операция осуществляется после передачи пакета из узла В6 в А3. Стек меток ликвидируется в узле А5 ("Выход" – это не обязательно узел места назначения). От отправителя до узла А1 пакет доставляется с применением маршрутизации по IP места назначения. Аналогичный метод используется при транспортировке пакета из узла А5 адресату.

Запись Next Hop Label Forwarding (NHLFE)

Запись Next Hop Label Forwarding (NHLF Entry) применяется при переадресации помеченных пакетов. Здесь содержится информация о:

Она может также содержать:

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

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

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

Установление соответствия для входных меток ILM (Incoming Label Map)

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

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

Установление соответствия между FEC и NHLFE (FTN)

Методика FEC-to-NHLFE (FTN) устанавливает соответствие между каждым FEC и набором NHLFE. Она используется при переадресации непомеченных пакетов, при необходимости их пометки до переадресации. Если FTN устанавливает соответствие между конкретной меткой и набором NHLFE, который содержит более одного элемента, только один из них должен быть выбран, прежде чем пакет будет переадресован.

Обмен меток

Обмен меток (Label swapping) представляет собой использование следующих процедур для переадресации пакетов. Чтобы переадресовать помеченный пакет, LSR рассматривает метку на верху стека. Он применяет ILM для установления соответствия этой метки набору NHLFE. Взяв информацию из NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета, затем записывает новую метку в стек пакета и переадресует его.

Чтобы переадресовать непомеченный пакет, LSR анализирует заголовок сетевого уровня, чтобы определить FEC пакета. Затем он использует FTN, устанавливая соответствие с NHLFE. Используя информацию NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета. (Извлечение метки из стека в этом случае будет нелегальным).

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

Область действия и уникальность меток

Данный LSR Rd может связать метку L1 с FEC F и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L2 с FEC F и переправить эту ассоциацию партнеру Ru2. Является ли L1 == L2, не определяется архитектурой, это вопрос исключительно локальный.

Данный LSR Rd может связать метку L с FEC F1 и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L с FEC F2 и переправить эту ассоциацию партнеру Ru2. Если и только если Rd может сообщить, когда он получает пакет с меткой на верху стека равной L, занесена ли она в стек RU1 или RU2, архитектура не требует равенства F1 == F2. В таких случаях мы можем сказать, что Rd использует другое пространство меток, которые он пересылает Ru1, по отношению меток, посылаемых Ru2. Вообще, Rd может лишь сообщить, Ru1 или Ru2 положил данную метку со значением L на верх стека, если выполнены следующие условия:

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

Если конкретный LSR Rd связан с некоторым LSR Ru через два интерфейса по схеме точка-точка, тогда Rd может пересылать Ru ассоциацию метки L с FEC F1, так же, как ассоциацию метки L с FEC F2, F1 != F2, если и только если каждая ассоциация корректна для пакетов, которые Ru посылает Rd через один из интерфейсов. Во всех других случаях Rd не должен посылать ассоциации Ru, сопрягающие одну и ту же метку с двумя разными FEC.

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

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

Маршрут с коммутацией меток (LSP), входной и выходной LSP

Маршрут с коммутацией меток (LSP) уровня m для определенного пакета P представляет собой последовательность маршрутизаторов <R1, ..., Rn> со следующими свойствами:

Другими словами, мы можем описать уровень m LSP для пакета P как последовательность маршрутизаторов, которая:

Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы LSR ни занес метку в стек уже помеченного пакета, он должен быть уверен, что новая метка соответствует FEC, чьим выходом LSP служит LSR, сформировавший метку, которая сейчас является второй в стеке. Мы будем называть последовательность LSR "LSP для определенного FEC F", если он является LSP уровня m для заданного пакета P, когда уровень метки P соответствует FEC F.

Рассмотрим набор узлов, которые могут быть входными LSP-узлами для FEC F. Тогда существует LSP для FEC F, который начинается с каждого из этих узлов. Если некоторое число этих LSP имеет идентичный выходной LSP, тогда можно рассматривать набор таких LSP как дерево, чьим корнем является выход LSP. Так как данные переносятся вдоль этого дерева по направлению к корню, эта структура может быть названа деревом мультиточка-точка. Мы можем, таким образом, говорить о дереве LSP для определенного FEC F.

Извлечение предпоследнего шага

Заметим, что согласно стандартным определениям, если <R1, ..., Rn> является LSP уровня m для пакета P, P может быть передан от R[n-1] к Rn с глубиной стека меток m-1. То есть, может быть выполнена операция pop для стека меток в предпоследнем LSR LSP, а не на выходе LSP.

С архитектурной точки зрения это вполне приемлемо. Целью метки уровня m является доставка пакета в Rn. Раз R[n-1] решил послать пакет Rn, метка не имеет более значения и не должна далее транспортироваться.

Имеется также практическое преимущество извлечения данных о предпоследнем шаге. Если так не сделать, тогда при получении пакета выходной LSP сначала просматривает верхнюю метку из стека и определяет, что это действительно выходной LSP. Затем он должен извлечь из стека метку и проверить, что осталось в стеке пакета. Если в стеке имеется другая метка, выходное устройство анализирует метку и осуществляет пересылку пакета на основе этого анализа. (В этом случае выходное устройство для пакетов уровня m является промежуточным узлом для его уровня m1 LSP). Если в стеке нет других меток, тогда пакет переадресуется согласно его адресу места назначения сетевого уровня. Заметим, что это потребует от выходного устройства двух просмотров: либо просмотра двух меток, либо просмотра метки с последующим анализом сетевого адреса.

Если, с другой стороны, используется извлечение предпоследнего шага из стека, тогда предпоследний узел просматривает метку и определяет:

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

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

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

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

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

Начальное согласование протокола рассылки меток должно позволять каждому LSR определить, способны ли соседние LSR извлекать метки из стека. LSR НЕ ДОЛЖЕН запрашивать своего партнера по обмену метками извлекать метку из стека, если только он не способен делать это.

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

LSP следующего шага

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

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

Мы будем использовать термин "следующий шаг L3", когда будем иметь в виду такой маршрут.

Неверные входные метки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транспортировка протокольных сообщений рассылки меток

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

Одним из способов достижения цели является использование TCP в качестве базового транспортного протокола, как это делается в [MPLSLDP] и [MPLSBGP].

Зачем нужно более одного протокола рассылки меток?

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

BGP и LDP

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

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

Метки для RSVP Flowspecs

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

Метки для явно маршрутизируемых LSP

В некоторых приложениях MPLS, в частности, сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода.

Первый подход реализован в протоколе, описанном в [MPLSRSVPTUNNELS], второй специфицирован в [MPLSCRLDP].

Некоторые применения MPLS. MPLS и трафик, маршрутизируемый шаг-за-шагом

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

Метки для адресных префиксов

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

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

Рассылка меток для адресных префиксов. Партнеры рассылки меток для адресного префикса

LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий:

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

Рассылаемые метки

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

Эти правила гарантируют, что метки, ассоциированные с адресным префиксом, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам.

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

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

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

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

Предположим, например, что пакет P, с адресом места назначения 10.2.153.178 должен двигаться от R1 к R2 и далее к R3. Предположим также, что R2 анонсирует адресный префикс 10.2/16 для R1, но R3 анонсирует 10.2.153/23, 10.2.154/23 и 10.2/16 до R2. То есть, R2 анонсирует агрегатный маршрут для R1. В этой ситуации пакет P может быть коммутируемым по метке до тех пор, пока он не достигнет R2, но так как R2 осуществил агрегатирование маршрутов, он должен запустить алгоритм поиска наилучшего соответствия, чтобы найти FEC для P.

Конец LSP и прокси конец LSP

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

LSR R1 считается "прокси концом LSP" LSR для адресного префикса X, если и только если:

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

Неявная метка NULL

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

LSR Rd рассылает ассоциацию неявной метки NULL и адресного префикса X в LSR Ru, если и только если:

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

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

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

Опция: присвоение метки Egress Targeted

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

Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется EgressTargeted Label Assignment (присвоение метки по концу маршрута).

Как может LSR Ri определить, что LSR Re является концом LSP для всех пакетов в конкретном FEC? Существует несколько возможных способов.

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

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

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

Например, предположим, что желательно присвоить метку egress-targeted по умолчанию, но также присвоить разные метки тем адресным префиксам, для которых существует несколько возможных концов LSP (т.e., для тех адресных префиксов, которые являются multihomed). Можно сконфигурировать все LSR для присвоения меток egress-targeted и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multihomed. Для конкретного адресного префикса multihomed X было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X.

Важно заметить, что, когда Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной.

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

MPLS и LSP, маршрутизируемые явно

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

LSP-туннели, маршрутизируемые явно

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

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

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

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

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

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

Альтернативой может быть объединение всех 10 адресных префиксов вокруг одной общей метки уровня 1 (которая ассоциирована также с адресом самого LSR), после чего можно связать каждый адресный префикс с отдельной меткой уровня 2. Метка уровня 2 будет рассматриваться как атрибут ассоциации метки уровня 1, который мы будем называть атрибутом стека. Мы вводим следующие правила:

Когда LSR Ru помечает ранее непомеченные пакеты, если наилучшим соответствием адресу места назначения пакета является X, а следующим шагом Ru LSP для X является Rd, и Rd послал Ru ассоциацию метки L1 и X, наряду с атрибутом стека L2, тогда

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

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

MPLS и маршрутизация при нескольких путях

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

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

Деревья LSP как объекты мультиточка-точка

Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой <R1, R2, R3>, а путем шаг-за-шагом для P2 является <R4, R2, R3>. Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3 и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3 и пошлет P2 в R3.

Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и, с точки зрения MPLS, они не различимы. Таким образом, вместо того, чтобы говорить о двух разных LSP, <R1, R2, R3> и <R4, R2, R3>, мы можем говорить об одном дереве LSP мультиточка-точка (MultipointtoPoint LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.

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

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

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

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

Далее, прежде чем послать пакет P в I1, B1 должен сформировать стек меток для P, затем занести туда метку L1, а на верх стека записать L2.

Эти процедуры эффективно формируют LSP-туннель, маршрутизируемый шаг-за-шагом, между пограничными маршрутизаторами BGP.

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

Иногда можно сформировать LSP-туннель, маршрутизированный шаг-за-шагом, между двумя пограничными маршрутизаторами BGP, даже если они не принадлежат общей автономной системе. Предположим, например, что B1 и B2 находятся в AS1. Предположим также, что B3 является EBGP-соседом B2 и находится в AS2. Наконец, предположим, что B2 и B3 находятся в некоторой сети, которая является общей для обеих автономных систем (демилитаризованная зона). В этом случае LSP-туннель может быть сформирован непосредственно между B1 и B3 следующим образом:

Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом

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

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

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

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

Процедуры пересылки меток (шаг-за-шагом)

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

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

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

Вышестоящий LSR должен выполнить:

Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов.

Нижестоящий LSR: Процедура рассылки

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

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

PushUnconditional

Пусть Rd является LSR. Предположим, что:

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

Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.

PushConditional

Пусть Rd является LSR. Предположим, что:

Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.

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

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

PulledUnconditional

Пусть Rd является LSR. Предположим, что:

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

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

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

PulledConditional

Пусть Rd является LSR. Предположим, что:

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

Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.

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

Вышестоящий LSR: процедура запроса

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

RequestNever

Никогда не делай запросов. Эта процедура полезна, если нижестоящий LSR использует процедуры PushConditional или PushUnconditiona l, но она бесполезна, если нижестоящий LSR использует процедуры PulledUnconditional или PulledConditional.

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

RequestWhenNeeded

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

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

RequestOnRequest

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

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

Вышестоящий LSR: процедура NotAvailable

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

RequestRetry

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

RequestNoRetry

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

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

Вышестоящий LSR: процедура Release

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

ReleaseOnChange

Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Conservative Label Retention Mode).

NoReleaseOnChange

Ru должен поддерживать ассоциацию, так что он сможет использовать ее немедленно, если Rd станет позднее следующим шагом Ru L3 для X . Эту процедуру следует применять для реализации свободного режима удержания меток (Liberal Label Retention Mode).

Вышестоящий LSR: процедура labelUse

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

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

UseImmediate

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

UseIfLoopNotDetected

Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd.

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

Нижестоящий LSR: процедура отзыва

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

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

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

Схемы MPLS: поддерживаемые комбинации процедур

Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd — нижестоящим.

Схема MPLS, которая управляет взаимодействием Ru и Rd, может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены означает, что в данной категории возможна любая процедура; появление N/A в некоторой позиции указывает, что не нужна никакая процедура данной категории.

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

Схемы для LSR, которые поддерживают объединение меток

Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем.

Схемы для LSR, которые не поддерживают объединение меток

Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4> и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.

Следовательно, если R1 и R2 являются MPLS-партнерами и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек) или по какой-то иной причине не способен осуществлять объединение меток, то используемая схема MPLS между R1 и R 2 должна быть одной из перечисленных ниже.

Соображения совместимости

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

<PulledUnconditional, RequestNever, *, *, *>

<PulledConditional, RequestNever, *, *, *>

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

<*, RequestNever, *, *, ReleaseOnChange>

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

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

Соображения безопасности

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

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

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

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

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

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

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

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

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

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

Определение протокола сетевого уровня

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

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

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

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

Генерация ICMP-сообщений для помеченных пакетов

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

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

Туннелирование через транзитную область маршрутизации

Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадают к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF и могут знать только, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Router), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, а LSR, которые не являются ASBR, поддерживают BGP.

В этом примере только ASBR будет знать, как проложить маршрут до отправителя некоторого произвольного пакета. Если внутренний маршрутизатор должен послать сообщение ICMP отправителю IP-пакета, он не будет знать, как маршрутизовать это ICMP-сообщение.

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

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

Туннелирование частных адресов через общедоступную опорную сеть

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

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

Эта технология может быть весьма полезной, если ICMP-сообщением является Time Exceeded (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1 ).

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

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

Обработка поля времени жизни. Определения

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

a) входное значение TTL минус один,

b) нуль.

Протокольно независимые правила

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

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

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

Правила, зависящие от IP

Мы определяем поле IP TTL равным величине поля IPv4 TTL или значению поля IPv6 Hop Limit, в зависимости от того, что используется.

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

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

Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.

Преобразование различных инкапсуляций

Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [11.9] и должен послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, а должен будет послан уже с применением такой инкапсуляции.

В этом случае значение входного TTL определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет — послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения выходного TTL определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.

Фрагментация и определение MTU пути

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

Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток.

При коммутации меток пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта, что может привести, в конце концов, к превышению MTU для сети Ethernet.

В этом разделе специфицируются правила обработки помеченных пакетов, которые являются слишком большими. В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [11.4], и ЭВМ, работающие с IPv6 [11.7,11.8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.

Вообще, ЭВМ IPv4, которые не используют определение MTU пути [11.4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.

Некоторые ЭВМ, которые не используют определение MTU пути [11.4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя находятся в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы и, следовательно, не будут фрагментироваться

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

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

Что касается конкретного канала данных, можно использовать следующие термины:

Максимальный исходный размер помеченной IP-дейтограммы

Каждый LSR, который способен

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

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

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

Когда помеченная IP-дейтограмма слишком велика?

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

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

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

Обработка помеченных дейтограмм IPv4, которые слишком длинны

Если помеченная IPv4 дейтограмма слишком велика и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.

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

Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должна быть выполнена следующая последовательность операций.

Обработка помеченных дейтограмм IPv6, которые слишком длинны

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

Восстановление сообщения из фрагментов осуществляется конечным получателем.

Реализация с учетом определения MTU пути

Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются слишком большими, связаны с процедурами определения MTU пути RFC-1191 [11.4]. ЭВМ, которые применяют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n меток, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.

Другими словами, дейтограммы от ЭВМ, которые применяют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1 и, таким образом, не могут быть фрагментированы в любом случае.

Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна доставка отправителю ICMP сообщения Destination Unreachable. Если невозможна посылка ICMP-сообщения отправителю из MPLS туннеля, но конфигурация сети предоставляет возможность LSR конца туннеля получать пакеты, которые должны проходить через туннель, но слишком велики для этого, тогда:

Передача помеченных пакетов через PPP

Протокол PPP (Point-toPoint Protocol) [11.6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.

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

Для того, чтобы установить связь через канал точка-точка, каждый конец PPP канала должен сначала послать LCP-пакеты, чтобы сконфигурировать и протестировать канал. После того как канал установлен и согласованы опционные возможности, PPP должен послать пакеты MPLS Control Protocol, чтобы разрешить посылку помеченных пакетов. Канал будет оставаться сконфигурирован для коммуникаций, пока управляющие протокольные пакеты LCP или MPLS его не закроют или пока не произойдет какое-то внешнее событие (сработает таймер пассивности или вмешается сетевой администратор).

Протокол управления PPP для MPLS

Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться.

Протокол управления MPLS тождественен протоколу управления каналом [11.6] за следующими исключениями:

Посылка помеченных пакетов

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

В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же, что и максимальная длина информационного поля инкапсулированного пакета PPP.

Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.

Пересылка помеченных пакетов в среде LAN

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

Шестнадцатеричный код Ethertype 8847 применяется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.

Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов.

11.6. Требования для управления трафиком

Введение

Мультипротокольная коммутация пакетов по меткам (MPLS) [11.1,[11.2] интегрирует в себе технику операций с метками и сетевую маршрутизацию. Базовой идеей является присвоение меток фиксированной длины пакетам на входе облака MPLS (базирующегося на концепции переадресации классов эквивалентности [11.1,[11.2]). Всюду внутри домена MPLS метки, присвоенные пакету, используются для принятия решения о переадресации (обычно без рассмотрения исходных заголовков пакета).

Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [11.1,2,3]).

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

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

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

Управление трафиком

В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами.

Управление трафиком (TE) связано с оптимизацией рабочих характеристик сетей. Вообще, ТЕ включает в себя технологию и научные принципы измерения, моделирования, описание, управление трафиком Интернет и приложение таких знаний и техники для получения определенных рабочих характеристик.

Главной целью управления трафиком в Интернет является достижение эффективной и надежной работы сети. Управление трафиком стало непременной функцией многих автономных систем — из-за высокой стоимости услуг Интернет.

Объективные характеристики управления трафиком

Ключевые характеристики, сопряженные с управлением трафиком, могут относиться к следующим категориям:

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

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

Первый тип проблем перегрузки может быть решен путем:

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

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

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

Управление трафиком и ресурсами

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

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

Ограничения механизмов управления IGP

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

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

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

Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких, как IP поверх ATM или IP поверх Frame Relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загру женные каналы.

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

MPLS и управление трафиком

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

Концепция каналов передачи данных MPLS используется достаточно широко. Согласно Li и Rekhter [11.3], канал передачи данных представляет собой объединение потоков данных одного и того же класса, которые следуют маршруту с коммутацией пакетов по меткам. Канал передачи данных представляет собой абстракцию трафика, с которой могут быть ассоциированы определенные характеристики. Полезно рассматривать каналы передачи данных как объекты, которые можно маршрутизировать, — то есть, путь, по которому транспортрируются данные, может меняться. С этой точки зрения, каналы передачи данных подобны виртуальным каналам в сетях ATM и Frame Relay. Важно, однако, подчеркнуть, что существует фундаментальное отличие между каналом передачи данных и путем. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит трафик. На практике термины LSP и канал передачи данных часто используются синонимично.

Привлекательность MPLS для управления трафиком может быть ассоциирована со следующими факторами.

Кроме того, через механизм коммутации меток MPLS позволяет наложить на современную модель маршрутизации Интернет квазиканальную коммутацию. Многие существующие предложения для управления трафиком посредством MPLS концентрируются на возможности формирования LSP. Хотя такая возможность является фундаментальной для управления трафиком, реально этого недостаточно.

Наведенный MPLS-граф

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

Наведенный MPLS-граф состоит из набора LSR, которые представляют собой узлы графа, и набора LSP, которые предоставляют логические соединение точка-точка между указанными LSR и, следовательно, служат в качестве каналов наведенного графа. Имеется возможность сформировать иерархический наведенный MPLS-граф, базирующийся на концепции стеков меток (смотри [11.1]).

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

Пусть G = (V, E, c) является графом, отражающим физическую топологию сети. Здесь, V — набор узлов сети и E — набор каналов; то есть, для v и w из V объект (v,w) содержится в E, если v и w являются непосредственно связанными в рамках G. Параметр "c" представляет собой набор емкостей и других ограничений, сопряженных с E и V. Мы будем рассматривать G как основу сетевой топологии.

Пусть H = (U, F, d) является наведенным MPLS-графом, где U — субнабор V, представляющй набор LSR в сети, или более точно — набор LSR, которые являются конечными точками, по крайней мере, одного LSP. Здесь F представляет собой набор LSP, так что для x и y из U, объект (x, y) находится в F, если существует LSP с x и y в качестве конечных точек. Параметр d представляет собой набор требований и ограничений, ассоциированных с F. Очевидно, H является ориентированным графом. Можно видеть, что H зависит от переходных характеристик G.

Фундаментальные проблемы управления трафиком в MPLS

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

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

Расширенные возможности управления трафиком с помощью MPLS

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

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

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

Атрибуты и характеристики канала передачи данных

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

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

Имеется два пункта особой важности: (1) параметризация каналов передачи данных и (2) положение маршрута и правила управления каналом передачи данных.

Двунаправленные каналы передачи данных

Хотя каналы передачи данных являются концептуально однонаправленными, во многих практических контекстах полезно одновременно анализировать два канала передачи данных с идентичными конечными точками, но с разным направлением потоков. Два канала передачи данных логически связаны друг с другом. Один канал, называемый прямым, транспортирует трафик от исходного узла к узлу места назначения. Другой канал, называемый обратным, транспортирует трафик от узла места назначения к исходному узлу. Объединение двух таких каналов называется двунаправленным каналом передачи данных BTT (bidirectional traffic trunk), если выполняются следующие два условия:

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

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

Базовые операции для канала передачи данных

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

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

Мониторирование аккоунтинга и работы

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

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

Базовые атрибуты управления трафиком каналов передачи данных

Атрибут канала передачи данных является параметром, который влияет на рабочие характеристики канала.

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

Основные атрибуты каналов передачи данных наиболее важные для управления трафиком перечислены ниже.

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

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

Атрибуты параметров трафика

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

Атрибуты управления и выбора пути

Атрибуты управления и выбора пути определяют правила выбора пути канала передачи данных, а также правила работы с маршрутами, которые уже существуют.

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

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

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

Административно специфицированные маршруты

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

Атрибут path preference rule (правило предпочтения пути) должен быть ассоциирован с административно специфицированными путями. Атрибут "правила предпочтения пути" представляет собой двоичную переменную, которая указывает, является ли административно сконфигурированный путь обязательным или нет.

Если административно сконфигурированный путь выбран с обязательным атрибутом, должен использоваться этот (и только этот) путь. Если обязательный путь недопустим (например, конечные пункты топологически разделены) или если путь не может быть использован, так как его ресурсы неадекватны, тогда процесс установки пути (setup) потерпит неудачу. Другими словами, если путь специфицирован как обязательный, то альтернативный путь не может использоваться ни при каких обстоятельствах. Обязательный путь, который успешно приписан, является неявно закрепленным. Раз путь присвоен, его нельзя изменить, а можно только ликвидировать или заменить новым.

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

Иерархия предпочтений для мультимаршрутов

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

Атрибуты сродства классов ресурсов (Resource Class Affinity)

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

<resourceclass, affinity>; <resourceclass, affinity>;

Параметр resource-class идентифицирует класс ресурса, для которого определено соотношение сродства в отношении канала передачи данных. Параметр affinity указывает на соотношение сродства; то есть, включены или исключены члены класса ресурсов для канала передачи данных. В частности, параметр affinity может быть двоичной величиной, которая принимает одно из следующих значений: (1) явное включение и (2) явное исключение.

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

Если не специфицировано никакого атрибута сродства класса, тогда предполагается значение отношения сродства "don't care" (безразлично) между каналом передачи данных и ресурсами. То есть, не существует никаких требований по включению или исключению каких-либо ресурсов для пути канала передачи данных. На практике — это режим по умолчанию.

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

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

Атрибут адаптивности

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

Атрибут адаптивности ( adaptivity ) является частью блока параметров пути, ассоциированного с каналом передачи данных. Атрибут адаптивности, ассоциированный с каналом передачи данных, указывает на то, является ли канал субъектом реоптимизации. То есть, атрибут адаптивности представляет собой двоичную переменную, которая принимает одно из следующих значений: (1) разрешить реоптимизацию и (2) запретить реоптимизацию.

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

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

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

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

Распределение нагрузки в параллельных каналах передачи данных

Распределение нагрузки по нескольким параллельным каналам передачи данных между двумя узлами является крайне важным.

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

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

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

Атрибут приоритета

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

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

Атрибут Preemption

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

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

Атрибут preemption может использоваться для спецификации четырех режимов приоритетного замещения для канала передачи данных: (1) замещающий объект активирован (preemptor enabled), (2) nonpreemptor (не является замещающим объектом), (3) допускающий подмену и (4) не допускающий подмены. Канал передачи данных, где разрешено приоритетное замещение (preemptor enabled), может заменять каналы с более низким приоритетом, признанные как приемлемые для замены. Канал передачи, специфицированный как не подлежащий подмене, не может быть замещен каким-либо иным каналом, вне зависимости от их относительных приоритетов. Канал передачи данных, допускающий замещение, может быть замещен другим каналом с более высоким приоритетом, который имеет атрибут preemptor enabled.

Достаточно просто понять, что некоторые режимы замещения являются взаимно исключающими. Используя схему нумерации, описанную выше, можно назвать допустимые комбинации режимов для канала передачи данных: (1, 3), (1, 4), (2, 3) и (2, 4). Комбинация (2, 4) является режимом по умолчанию.

Канал передачи данных, скажем "A", может заместить другой канал, скажем "B", только если все следующие пять условий будут выполнены:

Атрибут preemption не рассматривается как обязательный атрибут современной модели обслуживания в Интернет (best effort service), хотя и является полезным. Однако, в сценарии с дифференциальными услугами необходимость подмены становится очевидной. Более того, в появляющихся архитектурах оптического Интернет, где функции защиты и восстановления, чтобы уменьшить цену, могут быть перенесены с оптического уровня на информационные сетевые элементы (такие, как гигабитные и терабитные маршрутизаторы с коммутацией по меткам), стратегии приоритетного замещения могут использоваться для сокращения времени восстановления канала в условиях сбоев.

Атрибут устойчивости (Resilience)

Атрибут resilience определяет поведение канала передачи данных в случае возникновения ошибок — то есть, когда ошибка происходит на пути, через который проходит канал. При таких обстоятельствах должны быть рассмотрены следующие проблемы: (1) детектирование ошибки, (2) уведомление об ошибке, (3) восстановление после сбоя. Очевидно, реализация MPLS должна содержать механизмы для решения всех этих задач.

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

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

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

Атрибут Policing

Атрибут policing определяет действия, которые следует предпринять в рамках базовых протоколов, когда канал передачи данных становится нерабочим — то есть, когда какие-то параметры канала отклонились за оговоренные пределы. Вообще, атрибуты policing могут указывать, является ли неуправляемый канал передачи данных лимитированным по полосе пропускания или он просто переадресуется без каких-либо действий, учитывающих местную политику. Если используется политика, тогда для реализации таких функций могут применяться адаптации алгоритмов, таких, как ATM GCRA [11].

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

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

Атрибуты ресурсов

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

Максимально выделяемая доля (MAM)

Максимально выделяемая доля MAM (maximum allocation multiplier) ресурса является административно задаваемым атрибутом, который определяет долю ресурса, доступную для канала передачи данных. Этот атрибут нужен в основном для распределения полосы пропускания. Однако он может быть применен также для резервирования ресурсов LSR. Концепция MAM аналогична концепции параметров подписки и резервирования в сетях Frame Relay и ATM.

Значения MAM могут быть выбраны так, чтобы ресурс был недораспределен или перераспределен. Ресурс считается недораспределенным, если суммарные требования всех каналов передачи данных, которые могут его использовать, меньше емкости ресурса. В противном случае ресурс считается перераспределенным.

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

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

Атрибут класса ресурса

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

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

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

Вообще, ресурс может быть ассоциирован более чем с одним атрибутом класса ресурса. Например, все каналы OC-48 в заданной сети могут быть приписаны определенному атрибуту класса ресурса. Субнаборы каналов OC-48, могут быть приписаны к дополнительным атрибутам класса, чтобы реализовать специальную политику или построить нужную вам сеть.

Маршрутизация, базирующаяся на ограничениях

В современной терминологии маршрутизация, основанная на ограничениях, часто называется QoS-маршрутизацией (смотри [11.5,6,11.7,[11.10]).

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

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

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

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

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

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

Базовые характеристики маршрутизации на основе ограничений

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

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

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

Соображения реализации

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

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

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

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