Geum.ru

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

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

Содержание


4.2. Схемы MPLS: поддерживаемые комбинации процедур
Подобный материал:
1   ...   51   52   53   54   55   56   57   58   59
4.1.6. Нижестоящий LSR: процедура отзыва

В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y меткой L.

Рассылка и отзыв ассоциаций меток осуществляется через протокол рассылки меток. Все протоколы рассылки меток требуют, чтобы был установлен контакт между партнерами рассылки меток (за исключением неявных партнеров). Если LSR R1 установил контакт по рассылке меток с LSR R2, и получил ассоциации меток от LSR R2 через это соединение, тогда если соединение будет разорвано одним из партнеров (либо в результате поломки, либо обычной работы), все ассоциации, полученные через это соединение, должны рассматриваться как отозванные.

Пока эффективное соединение по обмену метками остается в силе, отзыв ассоциаций меток должен производиться явно. Если вторая метка ассоциирована с адресным префиксом, первая метка при этом не отзывается, будут существовать обе ассоциации. Это необходимо, чтобы поддерживать маршрутизации с несколькими маршрутами. Если второй адресный префикс ассоциирован с меткой, ассоциация с первым префиксом при этом не отзывается, метка будет использоваться для обоих адресных префиксов.
4.2. Схемы MPLS: поддерживаемые комбинации процедур

Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd – нижестоящим.

Схема MPLS, которая управляет взаимодействием Ru и Rd может быть описана с помощью пяти процедур: . Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены, означает, что в данной категории возможна любая процедура; появление "N/A" в некоторой позиции указывает, что не нужна никакая процедура данной категории.

Только схемы MPLS, которые специфицированы ниже, поддерживаются архитектурой MPLS. Другие схемы могут быть добавлены в будущем, если их необходимость будет доказана.
4.2.1. Схемы для LSR, которые поддерживают объединение меток

Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем:

1.


Это не затребованная рассылка меток “вниз по течению” с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель.

2.


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

3.

Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и консервативным режимом удержанием меток. Детектирование петель опционно.

4.

Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и свободным режимом удержанием меток. Детектирование петель опционно.

5.


Это рассылка меток “вниз по течению по запросу” (downstream-on-demand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель.

6.


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

7.


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

4.2.2. Схемы для LSR, которые не поддерживают объединение меток

Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид , и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: , и .

Следовательно, если R1 и R2 являются MPLS-партнерами, и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек), или по какой то иной причине не способен осуществлять объединение меток, используемая схема MPLS между R1 и R 2 должна быть одной из следующих:

1.

Это рассылка меток “вниз по течению по запросу” с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием маршрутных петель.

Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X; R3 пошлет R22 метки для X, а R2 пошлет одну метку R1 для X.

2.


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

3.


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