Кратко

  • RFC 3473 позволял Notify RSVP-TE напрямую достигать зарегистрированного несмежного узла и подтверждать приём механизмом ACK из RFC 2961.
  • Notify не заменял PathErr или ResvErr: ACK доказывал доставку тревоги, но не сходимость состояния, защитное переключение или возврат услуги.

Тревога может обогнать исправление, о котором сообщает. RFC 3473 закрепил этот разрыв в протоколе.

Документ стандартного потока вышел в январе 2003 года и выразил функции GMPLS из RFC 3471 средствами RSVP-TE. Обобщённые метки, двунаправленные LSP, ограничения, защита, раздельные каналы управления и данных, административное состояние и восстановление получили объекты. RFC 3472 делал параллельную работу для CR-LDP. Notify решал узкую задачу: быстро известить способный действовать узел, когда тот не соседствует с местом отказа.

Notify Request в Path запрашивал уведомление вверх, а в Resv — вниз. Объект содержал IPv4- или IPv6-адрес Notify Node. Получатель сохранял его в соответствующем состоянии, транзитный узел обычно передавал дальше.

Адрес не был неизменной сквозной идентичностью. Локальная политика могла заменить его при отправке. Из нескольких объектов значим был только первый. И наличие запроса не гарантировало, что Notify вообще будет создан.

При подходящей ошибке детектор мог адресовать несмежный узел. Остальные узлы пересылали сообщение неизменным, либо отправитель помещал его в новый IP-заголовок до цели. Router Alert не использовался. Путь свидетельства отличался от места отказа и от обычной цепочки PathErr/ResvErr.

ERROR_SPEC называл ошибку и детектор или отказавший канал; дескрипторы ограничивали затронутые сеансы. Одно событие могло уведомить оба направления, но без предварительного Notify Request генерация запрещалась.

RFC 2961 предоставлял Message ID и ACK. Целевой узел должен был подтвердить Notify. Обмен отвечал на ограниченный вопрос: пришло ли это идентифицированное RSVP-сообщение выбранному получателю?

Он не подтверждал физическую истинность отказа, удаление состояния на каждом переходе, ёмкость обхода, переключение оптики, возврат пакетов или приложения. RFC 3473 прямо говорил, что Notify не заменяет существующие сообщения об ошибках. Это был дополнительный канал доказательств, а не commit всей машины RSVP.

Path_State_Removed ещё сильнее отделял сообщение от действия. Узел мог отметить в PathErr, что действительно удалил связанное состояние Path. ACK тревоги и локальная квитанция удаления были разными фактами; ни один не описывал весь маршрут.

Уведомления с общей целью и ERROR_SPEC могли объединяться. Событийный, таймерный и другой метод зависел от реализации; таймер по умолчанию составлял одну миллисекунду. Объединение снижало нагрузку, но время конверта не становилось временем каждого события, а сеансы не получали общей атомарной судьбы.

Административная процедура требовала следующего подтверждения. После Notify с Down отправитель должен был увидеть Path с Down за настраиваемый срок, по умолчанию тридцать секунд. Иначе он запускал удаление и дополнительные tear/error. Первое предупреждение не считалось завершением.

Мог отказать только канал управления. Во время ожидания перезапуска RSVP- и MPLS-состояние разрешалось сохранить. «Канал ухудшен» не доказывал потерю данных; «канал активен» не доказывал полную синхронизацию, сигнал или услугу.

Прямая доставка меняла безопасность. RSVP обычно защищал сообщения переход за переходом. RFC 3473 предлагал IPsec для несмежного Notify либо отключение режима. Даже аутентифицированная и подтверждённая тревога доказывала ограниченные факты об отправителе, содержимом и приёме, а не физический результат.

RFC 4090, RFC 4872 и RFC 4873 позднее описали быстрое, сквозное и сегментное восстановление. Они добавили действия и области, но не объединили уведомление, решение, переключение и наблюдаемую услугу.

Принцип Heng Lu о работающем коде оставляет Notify символом до наблюдения ожидаемого изменения. Минимальная спецификация сохраняет агрегацию и политику локальными. Уровни реальности не дают ACK присвоить авторитет реально восстановленной услуги.

Полная запись хранит Path/Resv запроса, эффективную цель, детектор, ERROR_SPEC, сеансы, Message ID, отправку, приём и ACK. Отдельно — PathErr/ResvErr, удаление состояния, защиту или снятие, аппаратуру, сигнал, трафик и приложение. Слово «восстановлено» допустимо только в конце цепочки.

Источники