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

         

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


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

1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate >

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

2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

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

3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*>

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

4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

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

5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

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

6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>

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

7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

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

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

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

1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

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

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

2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>

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

3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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



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