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

5.1.3. LSR-маршрутизатор восходящего потока: процедура «недопустимо» (NotAvailable)

Если R_u и R_d являются LSR_ВП и LSR_НП , соответственно, и взаимодействующими сторонами при обмене маркерами относительно префикса адреса X , и R_d является для R_u противоположной стороной следующего ретрансляционного участка относительно X , а R_u запрашивает от R_d данные о привязке к X , но R_d отвечает, что в настоящий момент не может сформировать привязку, так как не обладает информацией о следующем ретрансляционном участке относительно X , то процедура «недопустимо» позволяет определить, как R_u следует ответить. Существуют две возможные субпроцедуры, которые определяют дальнейшее поведение R_u .

5.1.3.1. Субпроцедура «повторение запроса» (RequestRetry)

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

5.1.3.2. Субпроцедура «не повторять запрос» (RequestNoRetry)

R_u никогда не должен отправлять повторный запрос, а должен предполагать, что R_d предоставит данные о привязке автоматически, когда это будет возможно. Эта субпроцедура весьма полезна тогда, когда R_d использует субпроцедуру «безусловная вставка» или «условная вставка», т.е., если используется распространение невостребованных маркеров нисходящего потока.

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