Соседства RSVP-TE и приветственные сообщения
В своей первоначальной форме протокол RSVP не использовал концепцию смежности RSVP или соседства RSVP. RSVP интересовался только состоянием своих путей, которые постоянно обновлялись. Однако интервал обновления обычно довольно велик (30 секунд по умолчанию), и может потребоваться относительно много времени, чтобы обнаружить потерю соседа RSVP или отказ связанных LSP. Сокращение таймера обновления приводит к чрезмерным накладным расходам, поскольку маршрутизатору может потребоваться обновить большое количество LSP.
Для улучшения масштабируемости RSVP-TE и сокращения времени сходимости после сбоя в стандарт RSVP-TE (RFC 3209) были добавлены приветственные сообщения. Приветственные сообщения отслеживают состояние RSVP-TE между двумя соседними маршрутизаторами и, таким образом, косвенно, состояние LSP между ними.
Приветственные сообщения
Сообщение Hello содержит два объекта: объекты REQUEST и ACKNOWLEDGEMENT. Сообщение Hello отправляется с объектом REQUEST, а в ответ ожидается сообщение Hello с объектом ACKNOWLEDGEMENT. Каждая сторона независимо создаёт 4-байтовый идентификатор сессии. Неизменность идентификатора будет говорить о сохранении состояния RSVP-TE. Изменение идентификатора на одной из сторон будет свидетельствовать об утрате данным маршрутизатором актуального состояния RSVP-TE. Эти идентификаторы создаются в момент установления смежности и не меняются на протяжении всей сессии.
Поскольку для поддержания соседства между двумя маршрутизаторами требуется только одна Hello-сессия, которая не требует больших ресурсов (в отличии от множества сессий для LSP), сообщения Hello могут отправляться гораздо чаще, чем сообщения обновления пути. Интервал по умолчанию для сообщений Hello составляет 3 секунды. Смежность между двумя маршрутизаторами RSVP-TE считается нарушенной, когда:
- последовательные сообщения Hello не получены на интерфейсе в течение интервала Hello;
- или получено сообщение Hello, идентификатор сессии которого не соответствует установленному при создании сессии.
При потере смежности с соседним RSVP-TE состояния всех сессий RSVP-TE с соседним устройством очищаются, и сообщения PathTear и ResvTear отправляются по мере необходимости. Головной узел LSP продолжает отправлять сообщения Path, пытаясь восстановить LSP.
Механизм Refresh Reduction
Состояние каждого LSP должно обновляться на каждом маршрутизаторе посредством обмена сообщениями Path и Resv. В сети с сотнями или даже тысячами LSP это может привести к значительным накладным расходам на обмен управляющими данными.
RFC 2961 («Расширения для сокращения накладных расходов на обновление RSVP») определяет расширения RSVP, позволяющие сократить количество сообщений, необходимых для обновления LSP. В нём определено несколько новых объектов и сообщений RSVP, включая объект MESSAGE_ID и сообщение Summary Refresh.
Когда интерфейс RSVP-TE настроен на сокращение частоты обновлений, он добавляет MESSAGE_ID к сообщениям Path и Resv, отправляемым через этот интерфейс. Маршрутизатор также устанавливает младший бит поля Flags в заголовке RSVP-TE, чтобы сообщить соседу о возможности сокращения частоты обновлений.
Когда интерфейсы на обеих сторонах смежности настроены на сокращение частоты обновлений, маршрутизаторы отправляют сообщение Summary Refresh со списком LSP, которые необходимо обновить, вместо множества сообщений Path и Resv. Отдельные LSP однозначно идентифицируются IP-адресом отправляющего маршрутизатора и значениями идентификатора сообщения.
Когда маршрутизатор получает сообщение Summary Refresh, он ищет в своих PSB и RSB те, для которых получены сообщения Path или Resv с соответствующим идентификатором сообщения. Затем состояние этих LSP обновляется, как если бы было получено обычное сообщение Path или Resv.
Если маршрутизатор не находит сообщение, соответствующее одному из значений идентификатора сообщения, он отправляет своему соседу сообщение Summary Refresh с объектом MESSAGE_ID_NACK, указывающим неизвестный идентификатор сообщения. Затем сосед передаёт обычное сообщение Path или Resv, соответствующее неизвестному идентификатору сообщения.
Таймеры RSVP-TE
Таймер повторных попыток retry-timer устанавливается на отдельных LSP и управляет интервалом, с которым маршрутизатор пытается установить LSP. Если работающий LSP выходит из строя и не восстанавливается, маршрутизатор попытается установить LSP с интервалом, заданным таймером повторных попыток.
Значение таймера повтора по умолчанию составляет 30 секунд, с возможным диапазоном от 1 до 600. Параметр retry-limit также устанавливается на отдельном LSP и определяет, сколько раз маршрутизатор будет пытаться установить LSP, если он не работает. Значение по умолчанию — ноль, что означает отсутствие ограничений; маршрутизатор будет продолжать попытки установить LSP бесконечно, каждый раз после истечения retry-timer.