Многоцелевое расширение почты Интернет

         

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


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



Содержание раздела