RFC: 3031
Оригинал: Multiprotocol Label Switching Architecture
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Мельников Дмитрий Анатольевич

RFC 3031, Страница 63 из 68

5.1.6. LSR-маршрутизатор нисходящего потока: процедура «изъятия»

В данном случае, существует только одна процедура.

Когда LSR-маршрутизатор Rd принимает решение об аннулировании привязки маркера L к префиксу адреса X , то данные об изъятии привязки должны быть направлены всем LSR-маршрутизаторам, которым были ранее направлены данные о сформировании привязки.

Это требует, чтобы данные об изъятии привязки L к X были направлены Rd LSR-маршрутизатору Ru ещё до того, как Rd направит Ru данные о какойлибо новой привязке L к любому другому префиксу адреса Y (где XY ). Если Ru был бы оповещён о новой привязке L к Y ещё до того, как он узнал об изъятии привязки L к X , и если бы адреса IP-пакетов совпадали, и с X , и с Y , то на протяжении некоторого периода времени Ru мог бы помечать, и IP-пакеты, адреса которых совпадают с X , и IP-пакеты, адреса которых совпадают Y , с помощью маркера L .

Распределение и изъятие привязок маркеров осуществляется с помощью LDP-протокола. Все LDP-протоколы требуют, чтобы две стороны обмена маркерами были смежными (соседями) при доставке/распределении маркеров (за исключением, сторон неявной процедуры обмена маркерами). Если LSR-маршрутизатор R 1 и LSR-маршрутизатор R 2 являются соседями (смежными узлами) при распределении маркеров между собой, и R 1 получил от R 2 данные о привязках маркеров, используя «соседство» с ним, и если затем такое «соседство» будет нарушено (разорвано вследствие, либо нештатной ситуации, либо выполнения штатной процедуры, предусматривающей такой разрыв) одной из сторон (одним из LSR-маршрутизаторов), то все полученные за счёт «соседства» данные о привязках должны рассматриваться как изъятые.

До тех пор, пока соответствующее «соседство» при распределении маркеров сохраняется, привязки маркеров, которые подлежат изъятию, должны всегда «изыматься» в явном виде. Если к префиксу адреса привязан второй маркер, то в результате первый маркер не будет изыматься в неявном виде, а будут привязаны оба маркера, а это необходимо для обеспечения многомаршрутной маршрутизации. Если к маркеру привязан второй префикс адреса, то в результате привязка этого маркера к первому префиксу адреса не будет изыматься в неявном виде, а данный маркер будет использоваться в интересах обоих префиксов адресов.

Страница 63 из 68

2007 - 2022 © Русские переводы RFC, IETF, ISOC.