Схемы для 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>
Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и с детектированием петель.
