Фрагментация и определение маршрута с минимальным MTU-значением

Если возможно принять немаркированный IP-пакет, обладающий размером, превышающим разрешённое допустимое значение, и который следует транслировать дальше, то, по аналогии, можно принять маркированный IP-пакет, обладающий размером, также превышающим разрешённое допустимое значение, и который также следует транслировать дальше.

Кроме того, можно получить пакет (маркированный или нет), который при отправке имел размер, не превышающий разрешённое допустимое значение для передачи по линии связи, но который стал намного длиннее благодаря одному или нескольким дополнительным маркерам, вставленным в набор маркеров. В MPLS-системах размер пакетов может увеличиваться за счёт вставленных дополнительных маркеров. Таким образом, если получен помеченный пакет, который был обрамлён в кадр (frame) канального уровня с полем полезной нагрузки (payload), имеющим длину 1500 байт, то после вставки дополнительного маркера понадобиться отправить кадр канального уровня с полем полезной нагрузки, имеющим длину 1504 байта.

Вообще IPv4-узлы, которые не используют процедуру поиска маршрута с минимальным MTU-значением (path MTU discovery, RFC-1191, далее — MTU-маршрут), транслируют IP-пакеты, которые содержат не более 576 байт. Так как в большинстве Internet-сетей используется процедура поиска MTU-марш­рута, то в своём большинстве современные линии связи позволяют передавать кадры канального уровня с 1500-байтовой полезной нагрузкой, и поэтому вероятность использования процедуры фрагментации пакетов, в том числе и помеченных, чрезвычайна мала.

Некоторые IP-узлы, которые не используют процедуру поиска MTU-маршрута, формируют IP-пакеты, включающие 1500 байт, пока IP-адреса отправителя и получателя принадлежат одной и той же подсети. Такие IP-пакеты не будут доставляться через маршрутизаторы, и поэтому не будут фрагментироваться.

К сожалению, некоторые IP-узлы формируют IP-пакеты, включающие 1500 байт, пока IP-адреса отправителя и получателя имеют один и тот же определённый номер сети. В таких случаях существует риск фрагментации, особенно когда такие IP-пакеты маркируются. (Даже при таких условиях, фрагментация не возможна до тех пор, пока IP-пакет должен транслироваться через ЛВС «Ethernet» (некоторой разновидности) в период между начальным маркированием и удалением последнего маркера.)

В дальнейшем используются следующие термины, касающиеся канального уровня Internet-архитектуры:

§ поле полезной нагрузки кадра (frame payload). Кадр канального уровня включает заголовок канального уровня и концевик (например, MAC-заголовок, PPP-заголовок, поле проверочной суммы кадра и др.). Когда кадр переносит не помеченный IP-пакет, то поле полезной нагрузки переносит только этот IP-пакет. Когда кадр переносит помеченный IP-пакет, то поле полезной нагрузки включает записи набора маркеров и этот IP-пакет;

§ стандартный максимальный размер поля полезной нагрузки кадра (conventional maximum frame payload size). Этот размер допускается стандартами передачи по линиям/каналам связи (например, для ЛВС «Ethernet» этот размер составляет 1500 байт);

§ реальный (действительный) максимальный размер поля полезной нагрузки кадра (true maximum frame payload size). Это максимальный размер поля полезной нагрузки, который может быть передан и получен через подключённый к каналу передачи данных физический интерфейс сетевого программно-аппаратного комплекса. В ЛВС «Ethernet» и стандарта 802.3 считается, что реальный максимальный размер поля полезной нагрузки кадра на 4…8 байт больше, чем стандартный максимальный размер поля (если не используются заголовки стандартов 802.1Q и 802.1p, и если коммутатор или мост не могут ничего добавить, когда кадр транслируется на свой следующий РУ). Например, считается, что большая часть современного Ethernet-оборудования способна корректно передавать и принимать кадры, содержащие в поле полезной нагрузки 1504 байта или даже 1508 байт, по крайней мере, до тех пор, пока Ether­net-заголовок не содержит полей, предусмотренных стандартами 802.1Q и 802.1p.

В сквозных PPP-соединениях канального уровня реальный максимальный размер поля полезной нагрузки кадра практически неограничен;

§ эффективный максимальный размер поля полезной нагрузки кадра для помеченных IP-пакетов (effective maximum frame payload size for labeled packets). Это, либо стандартный, либо реальный максимальный размер поля полезной нагрузки кадра, в зависимости от технических параметров оборудования передачи данных по каналу связи или от длины используемого заголовка канального уровня;

§ впервые помеченный IP-пакет (initially labeled IP datagram). Предположим, что некоторый LSR-мар­ш­­ру­тизатор получил непомеченный IP-пакет, и что этот LSR-мар­ш­­ру­тизатор перед отправкой IP-пакета вставляет в него маркер. Такой IP-пакет именуется впервые помеченным IP-пакетом в этом LSR-мар­ш­­ру­тизаторе;

§ ранее помеченный IP-пакет (previously labeled IP datagram). Это IP-пакет, который был помечен до того, как поступил на вход некоторого LSR-мар­ш­­ру­тизатора.

Максимальный размер впервые помеченного IP-пакета

Каждый LSR-мар­ш­­ру­тизатор, который способен:

a) принимать не помеченный IP-пакет;

b) добавлять набор маркеров в IP-пакет;

c) доставлять итоговый помеченный IP-пакет,

должен поддерживать конфигурационный параметр (параметр настройки), известный как «максимальный размер впервые помеченного IP-пакета» (maximum initially labeled IP datagram size), который может иметь не отрицательное значение.

Если этот параметр настройки имеет нулевое значение, то это не имеет никакого эффекта.

Если этот параметр настройки имеет положительное значение, то он используется следующим образом. Если:

a) получен не помеченный IP-пакет;

b) в заголовке этого IP-пакета бит «DF[4]» (Don't Fragment) имеет нулевое значение («можно фрагментировать»);

и

c) этот IP-пакет необходимо пометить, прежде чем он будет отправлен;

d) размер IP-пакета (перед маркированием) превышает значение этого параметра;

то

a) IP-пакет должен быть поделён на фрагменты, причём длина каждого фрагмента не должна превышать значение этого параметра;

b) каждый фрагмент должен быть помечен ещё до его отправки.

Например, если параметр настройки имеет значение 1488, то любой не помеченный IP-пакет, длиной более 1488 байт, должен быть фрагментирован ещё до его маркирования. Каждый фрагмент можно будет транслировать по 1500-байтовому каналу передачи данных (т.е., использовать кадр, у которого длина поля полезной нагрузки составляет 1500 байт) без последствий, даже если в его набор маркеров будет вставлено несколько маркеров, например, три.

Другими словами, установка этого параметра в ненулевое значение позволяет исключить фрагментацию ранее помеченных IP-пакетов, но это может привести, в некотором смысле, к ненужной фрагментации впервые маркируемых IP-пакетов.

Следует заметить, что установка этого параметра не даёт эффекта при обработке IP-пакетов, в которых бит «DF» имеет значение «1» («не фрагментировать»). Следовательно, при установке этого параметра результат процедуры поиска MTU-маршрута остаётся неизменным.

Если размер помеченного IP-пакета слишком большой

Помеченный IP-пакет, размер которого превышает стандартный максимальный размер поля полезной нагрузки кадра, передаваемого по определённому каналу передачи данных, может считаться «слишком большим» (too big).

Помеченный IP-пакет, размер которого превышает реальный максимальный размер поля полезной нагрузки кадра, передаваемого по определённому каналу передачи данных, должен считаться «слишком большим».

Помеченный IP-пакет, размер которого не является «слишком большим», должен транслироваться без фрагментирования.

Обработка помеченных IPv4-пакетов, которые являются

«слишком большими»

Если помеченный IPv4-пакет является слишком большим, а бит «DF» в IP-заголовке имеет значение «0» («можно фрагментировать»), то LSR-мар­ш­­ру­тизатор может по-умолчанию удалить этот IPv4-пакет.

Следует заметить, что уничтожение таких пакетов является весьма востребованной процедурой, если только в каждом LSR-мар­ш­­ру­тизаторе сети, который способен добавлять набор маркеров в помеченный IP-пакет, установлено не нулевое значение максимального размера впервые помеченного IP-пакета.

Если LSR-мар­ш­­ру­тизатор принял решение не уничтожать помеченный IPv4-пакет, являющийся слишком большим, или если в этом пакете бит «DF» имеет значение «1», то он обязан выполнить следующую процедуру (алгоритм):

1. очистить записи набора маркеров до получения IPv4-пакета;

2. пусть N будет числом (количество) байт в наборе маркеров (т.е., число записей в наборе маркеров кратное 4);

3. если в заголовке IPv4-пакета бит «DF» имеет значение «0» («можно фрагментировать»), то:

a. фрагментировать IPv4-пакет, и при этом каждый фрагмент должен иметь длину, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля полезной нагрузки кадра;

b. в начало каждого фрагмента поместить один и тот же заголовок с маркером (набором маркеров), который мог бы присутствовать в оригинальном IPv4-пакете, не нуждающемся во фрагментации;

c. транслировать фрагменты;

4. если в заголовке IPv4-пакета бит «DF» имеет значение «1» («не фрагментировать»), то:

a. IPv4-пакет не должен транслироваться далее;

b. сформировать ICMP-сообщение «Узел-получатель не достижим» (destination unreachable):

i. в поле «Код ошибки» заголовка этого ICMP-сообщения установить значение «4» (требуется фрагментация, и установка бита «DF», fragmentation required and DF set);

ii. в поле «MTU-значение следующего РУ» (next-hop MTU, RFC-1191) заголовка этого ICMP-сообщения установить значение, равное разнице между значением эффективного максимального размера поля полезной нагрузки кадра и значением N;

c. если возможно, то передать это ICMP-сообщение «Узел-получатель не достижим» отправителю уничтоженного IPv4-пакета.

Обработка помеченных IPv6-пакетов, которые являются

«слишком большими»

При обработке помеченного IPv6-пакета, являющегося слишком большим, LSR-мар­ш­­ру­тизатор обязан выполнить следующую процедуру (алгоритм):

1. очистить записи набора маркеров до получения IPv6-пакета;

2. пусть N будет числом (количество) байт в наборе маркеров (т.е., число записей в наборе маркеров кратное 4);

3. если IPv6-пакет содержит более 1280 байт (не включая записи набора маркеров), или если IPv6-пакет не содержит заголовок расширения «Фрагментация», то:

a. сформировать ICMP-сообщение «Сообщение слишком большое» (too big message), и установить в поле «MTU-значение следующего РУ» заголовка этого ICMP-сообщения значение, равное разнице между значением эффективного максимального размера поля полезной нагрузки кадра и значением N;

b. если возможно, то передать это ICMP-сообщение «Сообщение слишком большое» отправителю уничтоженного IPv6-пакета;

c. удалить помеченный IPv6-пакет;

4. если IPv6-пакет содержит не более 1280 байт, или если IPv6-пакет содержит заголовок расширения «Фрагментация», то:

a. фрагментировать IPv6-пакет, и при этом каждый фрагмент должен иметь длину, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля полезной нагрузки кадра;

b. в начало каждого фрагмента поместить один и тот же заголовок с маркером (набором маркеров), который мог бы присутствовать в оригинальном IPv6-пакете, не нуждающемся во фрагментации;

c. транслировать фрагменты.

Повторная сборка фрагментов будет проведена в узле-получателе.

Последствия, вызванные процедурой поиска MTU-маршрута

Рассмотренные выше процедуры обработки IP-пакетов, содержащих бит «DF» со значением «1», но являющихся «слишком большими», влияют на процедуры поиска MTU-маршрута (RFC-1191). IP-узлы, которые применяют эти процедуры, будут устанавливать MTU-маршрут, в котором MTU-значение достаточно мало, что позволит вставить в IP-пакет n маркеров, и при этом не возникнет необходимости в процедуре фрагментации (где n — число маркеров, которые фактически вставлены в пакет, доставляемому по выбранному маршруту).

Другими словами, для IP-пакетов, переданных IP-узлами, которые применяют процедуру поиска MTU-маршрута, никогда не понадобится процедура фрагментации по причине необходимости вставки заголовка с маркерами, или добавления новых маркеров в уже существующий заголовок с маркерами. (Кроме того, IP-пакеты, переданные IP-узлами, которые применяют процедуру поиска MTU-маршрута, как правило, содержат бит «DF» со значением «1», и поэтому, в любом случае, никогда не будут фрагментироваться.)

Следует заметить, что процедура поиска MTU-маршрута будет «работать» корректно, если только в точке, в которой необходимо провести фрагментирование помеченных IP-пакетов, можно добиться, чтобы ICMP-сообщение «Узел-получатель не достижим» было направлено по адресу узла-отправителя.

Если невозможно направить ICMP-сообщение «Узел-получатель не достижим» по адресу узла-отправителя в рамках MPLS-туннеля, но настройка сети позволяет LSR-мар­ш­­ру­тизатору в крайней точке передачи туннеля принимать IP-пакеты, которые должны быть переданы по туннелю, но, в тоже время, эти IP-пакеты являются слишком большие, чтобы их транслировать по туннелю не фрагментируемыми, то:

· LSR-мар­ш­­ру­тизатор в крайней точке передачи туннеля должен обладать способностью определения MTU-значение туннеля в целом. Он это может сделать путём передачи IP-пакетов по туннелю в крайнюю точку приёма этого туннеля, и путём выполнения процедуры поиска MTU-маршрута в интересах таких IP-пакетов;

· каждый раз, когда в крайней точке передачи туннеля необходимо отправить в туннель IP-пакет, а последний в своём заголовке содержит бит «DF» со значением «1», и он превышает MTU-значение туннеля, то в крайней точке передачи туннеля должно быть передано ICMP-сообщение «Узел-получатель не достижим» узлу-отправителю этого IP-пакета, содержащее код ошибки «Требуется фрагментация, и установка бита «DF» и установленное значение (как это было описано выше) в поле «MTU-значение следующего РУ».