PulledConditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию.
Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.
Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.
В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.
