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

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

Протокол рассылки меток используется между узлами в сети 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, если и только если выполнено одно из следующих условий:

1. маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP;
2. маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2;
3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля. R1 и R2 являются клиентами IGP и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP или в результате рассылки R1 данному IGP;
4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1.

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

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

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

1. связать одну или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице;
2. для каждого такого адресного префикса X использовать протокол рассылки меток для уведомления партнеров (в рамках Х ) о существовании ассоциации метки с данным префиксом.

   Существует также обстоятельство, при котором LSR должен рассылать ассоциации меток для адресного префикса, даже если он не является LSR, который установил связь между меткой и префиксом:
3. если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут.

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

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

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

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

1. существует один адресный префикс X, такой, что для всех i, , X является наилучшим соответствием в маршрутной таблице Ri для адреса места назначения P ;
2. для всех i, 1<i<n, Ri установил соответствие метки и X и разослал эту метку всем R[i-1].

Заметим, что 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, если и только если выполнено одно из следующих условий:

1. R имеет адрес Y, такой, что X является адресным префиксом в маршрутной таблице R, который наилучшим образом соответствует Y; или
2. R содержит в своей маршрутной таблице один или более адресных префиксов Y, таких, что X является подходящей начальной субстрокой Y, но "предыдущие шаги LSP" R для X не содержат никакого адресного префикса Y. То есть, R является точкой ликвидации агрегатирования для адресного префикса X .

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

1. следующим шагом R1 для X служит R2, а R1 и R2 не являются партнерами по рассылке меток с точки зрения X (возможно, потому, что R2 не поддерживает MPLS); или
2. R1 был сконфигурирован, чтобы работать в качестве прокси конца LSP для X

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

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

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

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

1. Rd посылает Ru ассоциацию метки для X, и
2. Rd знает, что Ru может поддерживать неявные метки NULL (т.e., что он может очистить стек меток), и
3. Rd является концом LSP (а не прокси концом) для X.

Это заставляет предпоследний 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, если и только если выполняются следующие условия:

1. адрес LSR Re сам находится в маршрутной таблице (host route), и
2. существует некоторый способ для Ri определить, что Re является концом LSP для всех пакетов в конкретном наборе FEC.

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

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

• Если сеть реализует алгоритм маршрутизации состояния канала, а все узлы в области поддерживают MPLS, тогда алгоритм маршрутизации предоставляет Ri достаточно информации, чтобы определить маршрутизаторы, через которые пакеты с данным FEC должны покинуть домен маршрутизации или область.
• Если сеть реализует BGP, Ri может определить, какие пакеты с заданным FEC должны покинуть сеть через некоторый конкретный маршрутизатор, который является BGP Next Hop для этого FEC.
• Можно использовать протокол рассылки меток, чтобы передать информацию о том, какие адресные префиксы подключены к какому концевому LSR. Преимущество этого метода: отсутствие зависимости от наличия маршрутизации по состоянию канала.

Если используется присвоение меток 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-туннели, маршрутизируемые явно

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

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

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

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

Предположим, что конкретный 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, тогда

1. Ru должен занести в стек меток L2, а затем L1, а после этого переадресовать пакет Rd;
2. когда Ru посылает ассоциацию метки для X своим партнерам по рассылке меток, он должен включить L2 в качестве атрибута стека;
3. когда атрибут стека изменится (возможно, в результате изменения следующего шага Ru LSP для X ), Ru должен разослать новый атрибут стека.

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

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