RFC: 1191
Оригинал: Path MTU Discovery
Предыдущие версии: RFC 1063
Категория: Проект стандарта
Дата публикации:
Авторы: ,
Перевод: Игорь Шеваров

RFC 1191, Страница 9 из 15

6.2. Сохранение информации PMTU

В общем, уровень IP должен ассоциировать каждое значение PMTU, которое было им получено, с определенным путем. Путь идентифицируется с адресом отправителя, адресом получателя и типом сервиса IP. (Некоторые реализации не записывают адрес источника, это применимо для хостов с одним интерфейсом, которые имеют только один возможный адрес отправителя).

Замечание: Некоторые пути могут быть далее отличены по различным классификациям защиты. Детали таких классификаций не рассматриваются в данном документе.

Очевидное место для хранения этой ассоциации — поле в таблице маршрутизации. Хост не будет иметь маршрута для любого возможного адресата, но он будет иметь возможность кэшировать маршрут на хост для каждого активного адресата. (Это требование уже налагает необходимость обрабатывать ICMP сообщения по перенаправлении).

Когда первый пакет послан на хост и отсутствует маршрут на хост (per-host route), то маршрут выбирается и маршрутов на сеть (per-network routes) или из набора маршрутов по умолчанию. Поля PMTU в этих маршрутах должны быть инициализированы значением MTU для первого хопа и не должны изменяться в процессе определения PMTU. (При определении PMTU создаются или изменяются маршруты на хост). До того, как получено сообщение «датаграмма слишком большая» значение, соответствующее изначально выбранному маршруту, является точным.

После того как получено сообщение «датаграмма слишком большая», уровень ICMP определяет новую оценку PMTU (или из ненулевого значения MTU следующего хопа или с помощью методов, описанных разделе 5). Если маршрут на хост для этого пути не существует, то он создается (почти как при обработке ICMP Redirect; новый маршрут использует тот же маршрутизатор, как и текущий маршрут). Если оценка PMTU ассоциированная с маршрутом на хост выше, чем новая оценка, то ее значение изменяется.

Уровни пакетирования должны быть извещены об уменьшении PMTU. Любой уровень пакетирования (например, ТСР соединение) который активно использует путь, должен быть уведомлен об уменьшении оценки PMTU.

Замечание: когда сообщение «датаграмма слишком большая» содержит заголовок исходной датаграммы, который ссылается на UDP пакет, уровень ТСР должен быть уведомлен, если любое из этих соединений использует этот путь.

Также, протокол, который послал датаграмму, вызвавшую появление сообщения «датаграмма слишком большая», должен быть уведомлен, что эта датаграмма была отброшена, даже если оценка PMTU не изменилась, так чтобы он мог вызвать повторную отправку отброшенной датаграммы.

Замечание: механизм уведомления должен быть аналогичен механизму, используемому для предоставления уведомлений ICMP Source Quench. В некоторых реализациях (таких как системы, построенные на основе BSD 4.2) существующий механизм уведомлений не способен идентифицировать вовлеченное ТСР соединение, что требует наличия дополнительного механизма.

В качестве альтернативы, реализация может избегать использования асинхронного механизма уведомления об уменьшении PMTU, откладывая уведомление до следующей попытки послать датаграмму большее, чем оценка PMTU. При таком подходе, когда сделана попытка ПОСЛАТЬ датаграмму с установленным битом DF, и датаграмма больше чем оценка PMTU, функция SEND должна закончиться сбоем и вернуть соответствующий признак ошибки. Этот подход может быть более подходящим для уровня пакетирования без установления соединения (какие как UDP), который (в некоторых реализациях) трудно «уведомлять» от уровня ICMP. В этом случае, обычные механизмы, основанные на таймаутах, использовались бы, чтобы восстановить отброшенные датаграммы.

Важно понять, что уведомление уровней пакетирования, использующих путь для изменения PMTU, отличается от уведомления специфичных уровней, о том, что пакет был отброшен. Последнее должно быть сделано только практически (т.е. асинхронно с точки зрения уровня пакетирования), в то время как первое может быть отсрочено до того момента, когда уровень пакетирования будет создавать пакет. Повторная передача должна быть сделана только для тех пакетов, о которых известно, что они отброшены, на что указывает сообщение «датаграмма слишком большая».

Страница 9 из 15

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