Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача

Вид материала

Содержание

Подобный материал:

1 ... 49 50 51 52 53 54 55 56 ... 59

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

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

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

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

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

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

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

3.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 в области или домене маршрутизации. В этом случае, явное партнерство было бы слишком тяжеловесным, так как число партнеров стало бы слишком большим.

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

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

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

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

Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой , а путем шаг-за-шагом для P2 является . Давайте предположим, что 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, и , мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.

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