RFC: 2453
Оригинал: RIP Version 2
Предыдущие версии: RFC 1388, RFC 1723
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Сергей Кедров

RFC 2453, Страница 19 из 25

Во-вторых, как правило нет необходимости включать в triggered update полную таблицу маршрутизации. Достаточно включить информацию только о той записи, которая изменилась, то есть только для тех записей, у которых установлен флаг «запись (маршрут) изменена». Это первое. Второе. В triggered update должны включаться все непосредственно подключенные сети. Третье. При генерации triggered update должен использоваться механизм split horizon. Если после применения механизма split horizon оказывается, что метрика маршрута не изменилась (то есть был 16, и осталась 16), то запись о таком маршруте в triggered update не включается. Если после применения split horizon новых записей для посылки не оказалось, triggered update не посылается. Если triggered update был послан, и в него были включены записи из таблицы маршрутизации, то для таких записей флаг «запись изменена» снимается. Если input processing и output processing наложились по времени, то флаг «запись изменена» не должен изменяться процессом input processing до завершения output processing.

Реально говоря разницы между генерацией обычного — регулярного — update’а и triggered update’а нет, за исключением того, что первый включает всю таблицу маршрутизации, второй — только часть ее. Механизм генерации сообщения, описанный в следующем разделе, применим и к тому, и к другому.

3.10.2. Генерация сообщения Response

Данный раздел описывает механизм генерации сообщений Response. Сообщение Response создается отдельно для каждой непосредственно — подключенной сети.

Ниже изложена последовательность действий по созданию Response.

  • Установить номер версии. Номер устанавливаемой версии определяется конкретной реализацией протокола и настройками устройства; однако если Response формируется в ответ на конкретный Request, версии Response и Request должны совпадать.

  • Установить код команды в «Response».

  • Установить байты, которые должны быть равны нулю, в ноль.

  • Начать заполнение RTE. Напомним, что в один пакет возможно поместить не более 25 RTE. Если вся посылаемая информация не помещается в один RTE, послать полностью заполненный пакет и затем начать формировать новый, с дополнительной информацией. Количество пакетов с RTE не ограничивается.

  • При заполнении RTE обрабатывать каждую запись в таблице маршрутизации. В случае генерации triggered update обрабатывать только те записи, у которых установлен флаг «запись изменена» (route change). В процессе обработки записи реализуется алгоритм split horizon. Если после работы последнего выясняется, что запись не должна помещаться в Response, RTE для нее не формируется. Если запись должна быть включена в Response, ее адрес назначения и метрика включаются в RTE. Записи включаются в Response даже в том случае, если их метрика равна 16.

Страница 19 из 25

2007 - 2022 © Русские переводы RFC, IETF, ISOC.