Сети и телекоммуникации
.pdf531
Термин «входящее TTL-время» (incoming TTL) помеченного пакета опре-
деляет значение в TTL-поле самой верхней записи набора маркеров в момент получения пакета.
Термин «исходящее TTL-время» (outgoing TTL) помеченного пакета оп-
ределяет значение, которое должно быть больше:
a)входящего TTL-времени, уменьшенного на единицу;
b)нуля.
Независимые от протоколов правила. Если значение исходящего TTL-
времени помеченного пакета равно нулю, то, либо помеченный пакет не дол-
жен больше никуда доставляться, либо из такого пакета должен быть удалѐн набор маркеров, а сам пакет должен доставляться как не помеченный. Время жизни пакета в сети определяется его предельным значением.
В зависимости от значения маркера в записи набора маркеров пакет мо-
жет быть просто уничтожен, либо может быть направлен на сетевой уровень для его последующей обработки (например, для формирования ICMP-сооб-
щения об ошибке). Когда помеченный пакет доставлен, тогда в TTL-поле самой верхней записи в наборе маркеров должно быть установлено значение исходя-
щего TTL-времени.
Следует заметить, что исходящее TTL-время является исключительно функцией значения исходящего TTL-времени, и не зависит ни от каких-либо маркеров, которые были вставлены или удалены перед отправкой пакета. Со-
вершенно неважно, какое значение содержится в TTL-поле любой записи набо-
ра маркеров, если она не расположена на самом верху набора маркеров.
Зависимые от IP-протокола правила. Введѐм обозначение «IP/TTL-
поле». Значение этого поля должно быть равно значению, которое содержится в
TTL-поле заголовка IPv4-пакета или в поле «Hop Limit» (максимальное число РУ, RFC-2460) заголовка IPv6-пакета (в зависимости от того, какая версия IP-
протокола используется).
532
Когда IP-пакет маркируется впервые, тогда значение в TTL-поле записи набора маркеров должно быть равно значению IP/TTL-поля. (Если значение
IP/TTL-поля следует уменьшить на единицу, как часть обработки IP-пакета, то подразумевается, что это уже было сделано.)
Если маркер «удаляется», и в результате набор маркеров остаѐтся пустым,
то значение IP/TTL-поля должно быть заменено на значение исходящего TTL-
времени, как было рассмотрено выше. В IPv4-протоколе это потребует измене-
ния контрольной проверочной суммы IPv4-заголовка пакета.
Это указывает на то, что могут возникнуть ситуации, в которых сетевая администрация предпочитает уменьшать на единицу значение в TTL-поле заго-
ловка IPv4-пакета, как это осуществляется в сетевом MPLS-сегменте, вместо уменьшения значения в TTL-поле заголовка IPv4-пакета на число РУ LSP-
маршрута, в границах сетевого сегмента.
Трансляция между узлами, реализующими различные типы процедуры повторного обрамления. Иногда LSR-маршрутизатор может получить поме-
ченный пакет, который, например, был передан с выходного интерфейса
ATM/LSR-коммутатора (LC/ATM-интерфейс, RFC-30353), и может понадобить-
ся передать такой пакет по сквозному соединению канального уровня (PPP-
протокол), либо через ЛВС. Тогда входящий пакет не будет обработан с ис-
пользованием процедуры повторного обрамления, устанавливаемой данным стандартом, в то время как исходящий пакет будет обработан с использованием такой процедуры.
В таком случае, значение входящего TTL-времени определяется с помо-
щью процедур, используемых при доставке помеченных пакетов, например, с
помощью ATM/LSR-коммутаторов. А обработка TTL-поля осуществляется, как было описано ранее.
3MPLS using LDP and ATM VC switching. Стандарт, устанавливающий правила использования ATM-коммутаторов в качестве LSR-маршрутизатора.
533
Иногда LSR-маршрутизатор может получить помеченный пакет, который,
например, был передан по сквозному соединению канального уровня (PPP-
протокол), либо через ЛВС, и может понадобиться передать такой пакет, ска-
жем, на входной интерфейс ATM/LSR-коммутатора.
Тогда входящий пакет будет обработан с использованием процедуры по-
вторного обрамления, устанавливаемой данным стандартом, в то время как ис-
ходящий пакет будет не обработан с использованием такой процедуры. В таком случае, процедура доставки значения исходящего TTL-времени определяется процедурами, используемыми при доставке помеченных пакетов, например, с
помощью ATM/LSR-коммутаторов.
Фрагментация и определение маршрута с минимальным MTU-значением
Если возможно принять немаркированный IP-пакет, обладающий разме-
ром, превышающим разрешѐнное допустимое значение, и который следует транслировать дальше, то, по аналогии, можно принять маркированный IP-
пакет, обладающий размером, также превышающим разрешѐнное допустимое значение, и который также следует транслировать дальше.
Кроме того, можно получить пакет (маркированный или нет), который при отправке имел размер, не превышающий разрешѐнное допустимое значе-
ние для передачи по линии связи, но который стал намного длиннее благодаря одному или нескольким дополнительным маркерам, вставленным в набор мар-
керов. В MPLS-системах размер пакетов может увеличиваться за счѐт встав-
ленных дополнительных маркеров. Таким образом, если получен помеченный пакет, который был обрамлѐн в кадр (frame) канального уровня с полем полез-
ной нагрузки (payload), имеющим длину 1500 байт, то после вставки дополни-
тельного маркера понадобиться отправить кадр канального уровня с полем по-
лезной нагрузки, имеющим длину 1504 байта.
Вообще IPv4-узлы, которые не используют процедуру поиска маршрута с минимальным MTU-значением (path MTU discovery, RFC-1191, далее — MTU-
534
маршрут), транслируют 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). Этот размер допускается стандар-
535
тами передачи по линиям/каналам связи (например, для ЛВС «Ethernet»
этот размер составляет 1500 байт);
реальный (действительный) максимальный размер поля полезной нагруз-
ки кадра (true maximum frame payload size). Это максимальный размер по-
ля полезной нагрузки, который может быть передан и получен через под-
ключѐнный к каналу передачи данных физический интерфейс сетевого программно-аппаратного комплекса. В ЛВС «Ethernet» и стандарта 802.3
считается, что реальный максимальный размер поля полезной нагрузки кадра на 4…8 байт больше, чем стандартный максимальный размер поля
(если не используются заголовки стандартов 802.1Q и 802.1p, и если ком-
мутатор или мост не могут ничего добавить, когда кадр транслируется на свой следующий РУ). Например, считается, что большая часть современ-
ного Ethernet-оборудования способна корректно передавать и принимать кадры, содержащие в поле полезной нагрузки 1504 байта или даже 1508
байт, по крайней мере, до тех пор, пока Ethernet-заголовок не содержит полей, предусмотренных стандартами 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-маршрутизаторе;
538
Если помеченный 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):
539
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-пакет;
540
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-маршрута будет «рабо-
тать» корректно, если только в точке, в которой необходимо провести фрагмен-