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

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-туннели могут использоваться следующим образом.

1. Каждый пограничный маршрутизатор BGP посылает каждому пограничному маршрутизатору BGP в пределах автономной системы метку для каждого адресного префикса, которую он пересылает в рамках протокола BGP.
2. IGP для автономной системы поддерживает маршрут для каждого BGP-маршрутизатора. Каждый внутренний маршрутизатор рассылает свои метки для этих маршрутов каждому своему IGP-соседу.
3. Предположим, что:
   • пограничный маршрутизатор BGP B1 получает непомеченный пакет P;
   • адресный префикс X в маршрутной таблице B1 является наилучшим соответствием для адреса места назначения пакета P;
   • маршрут до X является маршрутом BGP;
   • следующим шагом BGP для X является B2;
   • B2 имеет ассоциацию метки L1 и X и посылает эту ассоциацию в B1;
   • следующий шаг IGP для адреса B2 является I1;
   • адрес B2 содержится в маршрутных таблицах B1 и I1 IGP, а
   • I1 связывает метку L2 с адресом B2 и посылает эту ассоциацию B1

   Далее, прежде чем послать пакет P в I1, B1 должен сформировать стек меток для P, затем занести туда метку L1, а на верх стека записать L2.
4. Предположим, что пограничный BGP-маршрутизатор B1 получает помеченный пакет P, где на верху стека размещена метка, соответствующая адресному префиксу X, и что условия 3b, 3c, 3d и 3e выполнены. Тогда, прежде чем посылать пакет P в I1, B1 должен заменить метку на верху стека на метку L1 и затем записать в стек метку L2.

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

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

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

• B3 посылает маршруты B2 (используя EBGP), опционно присваивая метки адресным префиксам;
• B2 перераспределяет маршруты к B1 (используя IBGP), указывая, что следующим шагом BGP для каждого такого маршрута является B3. Если B3 присвоил метки адресным префиксам, B2 передает эти метки далее без изменений вплоть до B1;
• IGP автономной системы AS1 имеет маршрут для B3.

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

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

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

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

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

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

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

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

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

• процедуру рассылки и
• процедуру отзыва.

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

• процедуру Request (запрос) и
• процедуру NotAvailable (не доступен) и
• процедуру Release (отзыв) и
• процедуру labelUse.

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

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

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

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

PushUnconditional

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

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

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

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

PushConditional

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

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

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

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

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

PulledUnconditional

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

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

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

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

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

PulledConditional

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

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

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