RFC 3031 — Архитектура многопротокольной коммутации на основе маркеров потока (MPLS)

5.1.1.4. Субпроцедура «условное извлечение» (PulledConditional)

Пусть R_d будет LSR-маршрутизатором. Предположим, что:

1. X представляет собой префикс адреса в маршрутной таблице R_d ;

2. R_u является взаимодействующей с R_d стороной в процедуре обмена маркерами, что касается X ;

3. R_u в явной форме затребовал, чтобы R_d привязал маркер к X и передал данные об это привязке R_u ;

4. R_d является, либо входом, либо выходом LSP-маршрута по отношению к X , или противоположной стороной следующего ретрансляционного участка на 3-м (сетевом) уровне для R_d по отношению к X является R_n , а последний отличается от R_u , и R_n привязал маркер к X и отправил данные об этой привязке R_d .

Далее, как только все эти условия выполнены, R_d должен привязать маркер к X и направить данные об этой привязке R_u . Следует заметить, что если в маршрутной таблице R_d отсутствует X , а данные о привязке к X не доступны со стороны следующего ретрансляционного участка по отношению к X , или если R_d не является взаимодействующей с R_u стороной в процедуре обмена маркерами, что касается X , то R_d обязан проинформировать R_u , что в настоящий момент он не способен обеспечить привязку. Тем не менее, если только какое-либо условие не выполнимо, и это привело к тому, что R_n всё ещё не может предоставить маркер R_d , то последний обязан отложить передачу R_u какого-либо ответа до тех пор, пока он не получит данные о привязке от R_n .

Если R_d отправил R_u данные о привязке маркера к префиксу адреса X , а через некоторое время изменился какой-либо атрибут привязки маркера, то R_d обязан повторно направить R_u данные о привязке маркера с новым атрибутом. Он должен это сделать даже тогда, когда R_u не направил новый запрос.

Данной субпроцедурой могут воспользоваться LSR-маршрутизаторы, которые осуществляют распределение востребованных маркеров нисходящего потока в режиме упорядоченного контроля LSP-маршрута.