RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых
3.3.1.3 Кэш маршрутов

Каждая запись в кэше маршрутов должна содержать следующие поля:

  1. локальный IP-адрес (для многодомных хостов)
  2. IP-адрес получателя
  3. тип(ы) обслуживания ToS
  4. IP-адрес следующего маршрутизатора

Поле (2) может содержать полный адрес получателя или только адрес сети, в которую тот входит. Поле TOS (3) должно присутствовать в записи.

Процедуры работы с кэшем маршрутов описаны в параграфе 3.3.4.2.

  • Обсуждение:
  • Включение поля Type-of-Service в кэш маршрутов и его рассмотрение в алгоритме маршрутизации будет обеспечивать механизм для применения в будущем маршрутизации по типу обслуживания в сети Internet (см. параграф 3.2.1.6).

    Каждая запись в кэше определяет конечную точку пути через Internet. Хотя маршрут между двумя точками может динамически изменяться, характеристики пути передачи остаются почти неизменными в течение продолжительного времени для каждого транспортного соединения между парой хостов.

    Следовательно, запись в кэше маршрутов является естественным местом для хранения информации о свойствах пути. Примером такого свойства может служить максимальный размер нефрагментируемой дейтаграммы (см. параграф 3.3.3) или средняя задержка на круговом пути, измеренная транспортным протоколом.

    Эти данные в общем случае собираются и используются протоколами вышележащих уровней (например, TCP) или приложениями, использующими протокол UDP. В настоящее время ведутся эксперименты по кэшированию свойств путейописанным здесь способом.

    Существуют разногласия по вопросу использования ключей для кэша — только адрес получателя или оба адреса (получателя и отправителя). Сторонники использования только адресов получателей приводят следующие аргументы:

    1. В соответствии с требованиями параграфа 3.3.1.2 сообщения Redirect будут порождать записи, ключами к которым являются адреса получателей; простейшая и наиболее общая схема всегда будет использовать адреса хостов.

    2. Уровень IP не всегда может знать адресную маску для сети получателя в сложной среде с подсетями.

    3. Использование только адресов хостов-получателей позволит применять полные 32-битовые адреса, обеспечивая восприимчивость к изменению архитектуры Internet.

    Сторонники использования в качестве ключей адресов отправителей и получателей также приводят свои аргументы:

    1. Экономия памяти.

    2. Упрощение структуры данных, простота объединения с таблицами принятых по умолчанию и статических маршрутов (см. ниже).

    3. Обеспечивается больше полезного места для хранения информации о свойствах пути, как было упомянуто выше.

  • Реализация
  • Кэш должен быть достаточно велик и обеспечивать возможность включения записей для максимального числа хостов-получателей, которое может использоваться в каждый момент времени.

    Маршрутная запись в кэше может также включать управляющую информацию, используемую для выбора заменяемой записи. Это может быть реализовано, например, в форме бита recently used (недавно использована) или временной метки для последнего обращения. В целях диагностики рекомендуется сохранять время последнего изменения записи.

    При реализации может возникнуть желание снизить издержки на сканирование кэша маршрутов для каждой передаваемой дейтаграммы. Это можно реализовать с помощью хэш-таблицы для ускорения просмотра или путем предоставления ориентированными на соединения протоколами транспортного уровня «советов» или временных указателей на подходящую запись в кэше уровню IP с каждой последовательной дейтаграммой.

    Хотя мы рассматривали здесь кэш маршрутов и список используемых по умолчанию шлюзов по-отдельности, на практике их часто объединяют в одну структуру данных — routing table (таблица маршрутизации).

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