3.3.1.3 Кэш маршрутов
Каждая запись в кэше маршрутов должна содержать следующие поля:
- локальный IP-адрес (для многодомных хостов)
- IP-адрес получателя
- тип(ы) обслуживания ToS
- IP-адрес следующего маршрутизатора
Поле (2) может содержать полный адрес получателя или только адрес сети, в которую тот входит. Поле TOS (3) должно присутствовать в записи.
Процедуры работы с кэшем маршрутов описаны в параграфе 3.3.4.2.
- Обсуждение:
Включение поля Type-of-Service в кэш маршрутов и его рассмотрение в алгоритме маршрутизации будет обеспечивать механизм для применения в будущем маршрутизации по типу обслуживания в сети Internet (см. параграф 3.2.1.6).
Каждая запись в кэше определяет конечную точку пути через Internet. Хотя маршрут между двумя точками может динамически изменяться, характеристики пути передачи остаются почти неизменными в течение продолжительного времени для каждого транспортного соединения между парой хостов.
Следовательно, запись в кэше маршрутов является естественным местом для хранения информации о свойствах пути. Примером такого свойства может служить максимальный размер нефрагментируемой дейтаграммы (см. параграф 3.3.3) или средняя задержка на круговом пути, измеренная транспортным протоколом.
Эти данные в общем случае собираются и используются протоколами вышележащих уровней (например, TCP) или приложениями, использующими протокол UDP. В настоящее время ведутся эксперименты по кэшированию свойств путейописанным здесь способом.
Существуют разногласия по вопросу использования ключей для кэша — только адрес получателя или оба адреса (получателя и отправителя). Сторонники использования только адресов получателей приводят следующие аргументы:
В соответствии с требованиями параграфа 3.3.1.2 сообщения Redirect будут порождать записи, ключами к которым являются адреса получателей; простейшая и наиболее общая схема всегда будет использовать адреса хостов.
Уровень IP не всегда может знать адресную маску для сети получателя в сложной среде с подсетями.
Использование только адресов хостов-получателей позволит применять полные 32-битовые адреса, обеспечивая восприимчивость к изменению архитектуры Internet.
Сторонники использования в качестве ключей адресов отправителей и получателей также приводят свои аргументы:
Экономия памяти.
Упрощение структуры данных, простота объединения с таблицами принятых по умолчанию и статических маршрутов (см. ниже).
Обеспечивается больше полезного места для хранения информации о свойствах пути, как было упомянуто выше.
- Реализация
Кэш должен быть достаточно велик и обеспечивать возможность включения записей для максимального числа хостов-получателей, которое может использоваться в каждый момент времени.
Маршрутная запись в кэше может также включать управляющую информацию, используемую для выбора заменяемой записи. Это может быть реализовано, например, в форме бита recently used (недавно использована) или временной метки для последнего обращения. В целях диагностики рекомендуется сохранять время последнего изменения записи.
При реализации может возникнуть желание снизить издержки на сканирование кэша маршрутов для каждой передаваемой дейтаграммы. Это можно реализовать с помощью хэш-таблицы для ускорения просмотра или путем предоставления ориентированными на соединения протоколами транспортного уровня «советов» или временных указателей на подходящую запись в кэше уровню IP с каждой последовательной дейтаграммой.
Хотя мы рассматривали здесь кэш маршрутов и список используемых по умолчанию шлюзов по-отдельности, на практике их часто объединяют в одну структуру данных — routing table (таблица маршрутизации).