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

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

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

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

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

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

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

• Ru1 и Ru2 являются партнерами, которые обмениваются метками и которым Rd пересылает значение метки L, и
• Ru1 и Ru2 соединены с Rd непосредственно через интерфейс по схеме точка-точка.

Когда эти условия выполнены, 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> со следующими свойствами:

1. R1, вход LSP, является LSR, который вносит метку в стек пакета P, в результате формируется стек глубиной m ;
2. для всех i, 1<i<n, P (когда он приходит в LSR Ri) имеет стек меток глубиной m ;
3. никогда за время передачи P от R1 к R[n-1] глубина стека не будет меньше m ;
4. для всех i, 1<i<n: Ri передает P в R[i+1] посредством MPLS, т.e. путем использования метки в верхней позиции стека (метка уровня m) в качестве индекса в ILM;
5. для всех i, 1<i<n: если система S получает и переадресует P после того, как P передан Ri, но до того, как P получен, R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую субсеть и S может быть одним из переключателей информационного канала); далее решение переадресации S не базируется на метке уровня m или на основе заголовка сетевого уровня. Возможные причины этого:

   a) решение не основано на содержимом стека или заголовка сетевого уровня;

   b) решение основано на содержимом стека, куда положены другие метки (т.e., на метке уровня m+k, где k>0 ).

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

1. начинается с LSR (вход LSP), заносящий метку на уровень m ;
2. содержит все маршрутизаторы, чьи промежуточные LSR принимают решение о переадресации согласно метке на уровне m ;
3. завершается (выход LSP), когда решение переадресации делается на основе коммутации меток на уровне m-k, где k>0, или когда решение переадресации делается традиционно, посредством не-MPLS процедур.

Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы 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-заголовка.

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