Geum.ru

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

Вид материалаЗадача
Подобный материал:
1   ...   48   49   50   51   52   53   54   55   ...   59
3.1.5.  Неявная метка NULL

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

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

1. Правила раздела 3.1.2 указывают, что 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.
3.1.6.  Опция: присвоение метки Egress Targeted

Существуют ситуации, в которых начало LSP Ri, знает, что пакеты нескольких разных FEC должны следовать одним и тем же LSP, завершающимся, скажем, конечным Re. В этом случае, корректная маршрутизация может быть реализована использованием одной метки для всех таких FEC, необязательно иметь отличающиеся метки для каждого FEC. Если и только если выполняются следующие условия:

1. Адрес LSR Re сам находится в маршрутной таблице (host route), и

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

Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется "Egress-Targeted 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., для тех адресных префиксов, которые являются multi-homed). Можно сконфигурировать все LSR для использования присвоения меток egress-targeted, и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multi-homed. Для конкретного адресного префикса multi-homed X, было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X.

Важно заметить, что если Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной.

Аналогично, если Rd присваивает разные метки X1 и X2, но Ru присваивает им обоим метку, соответствующую адресу их конца LSP или прокси конца, переадресация будет, тем не менее, осуществляться корректно. Ru будет лишь устанавливать соответствие между входной меткой и меткой, которую сформировал Rd для адреса конца LSP .