Порядок создания СЗПДн. Требования к сетевым устройствам

Название	Требования к сетевым устройствам
Анкор	Порядок создания СЗПДн
Дата	11.10.2021
Размер	1.38 Mb.
Формат файла
Имя файла	rfc1122_HOST1_tr.doc
Тип	Протокол #245378
страница	7 из 11

1 2 3 4 5 6 7 8 9 10 11

§3.3.2. Повторная сборка IP-пакетов

Программный IP-модуль обязан выполнять процедуру повторной сборки IP-пакетов.

Обозначим размер (длину) наибольшего IP-пакета, который может пройти процедуру повторной сборки, как EMTU_R (“Effective MTU to receive”, эффективный для приёма MTU-размер). Этот параметр иногда называют “длина буфера для повторной сборки” (“reassembly buffer size”). Длина EMTU_R должна быть всегда больше или равна 576 октета. Целесообразно, чтобы параметр EMTU_R был, либо настраиваемым, либо неограниченным, а также был больше или равен MTU-размеру присоединённой(ых) сети(ей). Нецелесообразно, чтобы фиксированное предельное значение параметра EMTU_R встраивалось в код программы, так как некоторые протоколы прикладного уровня требуют использовать значение этого параметра более 576 октетов.

Некоторая реализация программного IP-модуля может использовать буфер для непрерывной сборки каждого IP-пакета, или она может использовать более сложную структуру данных, которая позволяет собирать IP-пакеты неограниченной длины (в этом случае говорят, что значение параметра EMTU_R “неограниченно”).

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

“Сложной” частью процедуры повторной сборки является учёт используемых системных ресурсов (bookkeeping) с целью определения когда все байты IP-пакета были собраны. Данный стандарт рекомендует использовать представленный в RFC-815 алгоритм, который не требует дополнительного информационного пространства для учёта используемых системных ресурсов. Тем не менее, указанный алгоритм требует сохранения первого фрагмента, который может понадобиться для включения в возможное ICMP-сообщение “время просрочено” (истёк тайм-аут для повторной сборки, Reassembly Timeout)

Программный IP-модуль должен иметь средство, с помощью которого транспортный уровень мог бы определить значение параметра MMS_R (то есть максимальная длина сообщения, которое может быть принято и повторно собрано в IP-пакет). Если значение параметра EMTU_R ограничено, то:

MMS_R = EMTU_R — 20 ,

так как минимальная длина заголовка IP-пакета составляет 20 октетов.

Кроме того, программный IP-модуль должен иметь средство для контроля времени тайм-аута для повторной сборки. Целесообразно, чтобы время тайм-аута для повторной сборки было фиксированной величиной. Рекомендуемое значение времени: 60-120 сек. Если тайм-аут просрочен, то частично собранный IP-пакет должен быть уничтожен, а ГВМ-отправителю направляется ICMP-сообщение “время просрочено” (если не был принят начальный фрагмент).

(Замечание. В описании IP-протокола (RFC-791) указано, что значение времени тайм-аута для повторной сборки должно составлять оставшееся время, указанное в поле TTL заголовка IP-пакета. Но это положение в настоящее время неприемлемо, так как все современные шлюзы воспринимают значение в поле TTL IP-заголовка как число оставшихся ретрансляционных участков на маршруте доставки IP-пакета, а не как оставшееся значение времени в секундах. Каждый шлюз, ретранслирующий IP-пакет, уменьшает значение в поле TTL IP-заголовка на единицу.)

Если время тайм-аута для повторной сборки слишком мало, то IP-пакеты будут уничтожаться как ненужные, а соединение может быть нарушено. Поэтому время тайм-аута должно быть, по крайней мере, большим и сравнимо с обычной максимальной задержкой доставки IP-пакета через Internet-сеть. Наиболее приемлемым минимальным значением времени тайм-аута могло бы быть 60 секунд.

Рекомендуется, чтобы в кэш-памяти могло храниться время прохождения нескольких петлевых маршрутов, измеренное транспортным протоколом для различных ГВМ-получателей, а также чтобы эти значения могли использоваться для динамического определения приемлемого значения времени тайм-аута для повторной сборки. Исследования (поиск решения) данной проблемы продолжаются.

Если время тайм-аута для повторной сборки слишком продолжительное, то буфер ГВМ-получателя будет слишком долго занят хранимыми в нём ресурсами, и кроме этого значение параметра MSL (Maximum Segment Lifetime, максимальной время жизни блока транспортного протокола, RFC-793) будет существенно превышать необходимое. Параметр MSL управляет максимальной скоростью, с которой могут быть переданы IP-пакеты/фрагменты, используя конкретные значения в 16-битовом поле “Идентификатор передаваемого исходного “большого” пакета” IP-заголовка. Значение параметра MSL, существенно превышающее необходимое, снижает максимальную скорость передачи. Описание стандарта ТСР-протокола (RFC-793) без каких-либо обоснований устанавливает для параметра MSL значение 2 минуты. Это значение параметра является верхним приемлемым пределом для времени тайм-аута при повторной сборке.
§3.3.3. Фрагментация

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

Обозначим как EMTU_S (“Effective MTU for sending”, эффективный для передачи MTU-параметр) максимальный размер (длину) IP-пакета, который может быть передан, а в его заголовке представлена пара IP-адресов (отправитель/получатель) и возможно категория обслуживания.

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

MMS_S = EMTU_S — <IPheadersize> ,

а значение параметра EMTU_S должно быть меньше или равно MTU-размеру, который принят в сети, логический интерфейс которой соответствует IP-адресу получателя, содержащемуся в заголовке IP-пакета. Значение <IPheadersize> в этом равенстве будет равно 20 октетам, но до тех пор, пока не используется переменное поле “Услуги” в заголовке IP-пакета.

ГВМ, в которой не реализована функция локальной фрагментации, должна гарантировать, что транспортный уровень (для ТСР-протокола) или прикладной уровень (для UDP-протокола) будут осведомлены программным IP-модулем о значении параметра MMS_S, и что она не будет передавать блоки транспортного уровня, имеющие длину более MMS_S.

Вообще рекомендуется исключить функцию локальной фрагментации и выбрать уменьшенное значение параметра EMTU_S, но достаточное для того, чтобы исключить фрагментацию в любом шлюзе, расположенном на маршруте доставки IP-пакета. При отсутствии актуальной информации о минимальном значении MTU-параметра на всём маршруте доставки, программный IP-модуль должен использовать значение EMTU_S576 всякий раз когда IP-адрес получателя не идентифицирует присоединённую сеть, а в противном случае он должен использовать MTU-параметр присоединённой сети.

MTU-параметр каждого физического интерфейса должен быть настраиваемым.

Программный IP-модуль может использовать имеющийся у него флаг настройки “All-Subnets-MTU”, который указывает на то, что MTU-параметр присоединённой сети используется для всех ГВМ-получателей в различных подсетях в пределах одной и той же сети, но не для других сетей. Таким образом, этот флаг, скорее всего, повлечёт за собой определение адресной маски класса сетей, а не адресной маски подсети, и будет использоваться для определения значения параметра EMTU_S. Для многоадресной ГВМ необходимо использовать флаг настройки “All-Subnets-MTU” в каждом физическом интерфейсе.

Выбор корректного размера IP-пакета для последующего использования при передаче данных является сложной и многоаспектной проблемой:

вообще, от ГВМ не требуется принимать и обрабатывать IP-пакеты длиной более 576 октетов (включая заголовок и данные), и поэтому ГВМ не обязана передавать более длинные IP-пакеты в условиях отсутствия необходимой информации или предварительного соглашения с ГВМ-получателем. Следовательно, параметр MMS_S является только верхней границей для длины транспортных блоков, которые может передать протокол транспортного уровня. Даже когда значение параметра MMS_S составляет 556 октетов, программный модуль транспортного уровня может ограничить свои транспортные блоки до 556 октетов при отсутствии других данных о ГВМ-получателе;

Протокол транспортного уровня, который допускает использование значение параметра EMTU_R больше 576 октетов, может передавать транспортные блоки длиной, превышающей это значение, но только тем ГВМ-получателям, в которых реализован точно такой же протокол;

целесообразно, чтобы ГВМ ограничивали значения своих параметров EMTU_S для конкретной ГВМ-получателя до минимального значения MTU-параметра, принятого для всех сетей, расположенных на маршруте до этой ГВМ-получателя, с целью предотвращения какой-либо процедуры фрагментации. IP-фрагментация, несмотря на то, что с формальной точки зрения это вполне корректная процедура, может породить серьёзную проблему при функционировании протокола транспортного уровня. Это связано с тем, что потеря одного фрагмента приводит к необходимости повторной передачи всех фрагментов, относящихся к одному блоку транспортного уровня.

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

Также рекомендуется, чтобы ГВМ могла определить значение MTU-параметра для конкретного маршрут путём передачи фрагмента IP-пакета с нулевым смещением и ожидания приёма в течении тайм-аута для повторной сборки (которое не может завершиться!) и последующей передачи ответного ICMP-сообщения “время просрочено”. Это сообщение могло бы содержать в поле полезной нагрузки заголовок наибольшего оставшегося фрагмента. В стандарте RFC-1191 представлены способы определения значений MTU-параметра для конкретных маршрутов.
§3.3.4. Многоадресная ГВМ в рамках локальной сети

§3.3.4.1. Предисловие

Многоадресная ГВМ имеет несколько IP-адресов, которые можно трактовать как логические интерфейсы. Эти логические интерфейсы могут быть связаны с одним или несколькими физическими интерфейсами, а к этим физическим интерфейсам могут быть подключены одна и та же сеть или различные сети.

Наиболее важные случаи использования многоадресности следующие:

несколько логических сетей. Разработчики Internet-архитектуры полагали, что каждая физическая сеть могла бы иметь один уникальный сетевой IP-адрес (либо IP-адрес для подсети). Тем не менее, администраторы локальных сетей иногда считают полезным нарушить это предположение, так как локальная сеть функционирует с несколькими логическими сетями в рамках одной присоединённой физической сети.

Если ГВМ, подключённая к такой физической сети, была настроена для управления трафиком в каждой из N различных логических сетей, то ГВМ будет иметь N логических интерфейсов. Последние могли бы совместно использовать один физический интерфейс, или они могли бы использовать N физических интерфейсов, к которым был бы подключена одна и та же сеть;

несколько логических ГВМ. Когда ГВМ имеет несколько IP-адресов, причём у всех одинаковая часть <Network-number> (или <Subnet-number>, если не указанно иного), то логические интерфейсы именуются как “логические ГВМ”. Логические интерфейсы могут обозначать один физический интерфейс или могут обозначать несколько физических интерфейсов, принадлежащих одной и той же физической сети;
- простая множественная адресация. В данном случае каждый логический интерфейс отображается в отдельный физический интерфейс, а каждый физический интерфейс присоединён к отдельной физической сети. Термин “множественная адресация” был ранее использован именно для такого случая, но теперь имеет более общее значение.

ГВМ со встроенной функцией шлюза в случае простой множественной адресации, как правило, выйдет из строя. Тем не менее, ГВМ может быть просто многоадресной без реализации функции шлюза, то есть не ретранслировать IP-пакеты из одной присоединённой сети в другую.

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

И в заключении, следует рассмотреть случай — противоположный множественной адресации: один логический интерфейс может отображаться на несколько физических интерфейсов с целью повышения надёжности или пропускной способности между непосредственно связанными между ГВМ за счёт выбора альтернативных физических маршрутов между ними. Например, две системы могут быть соединены между собой с помощью нескольких сквозных каналов связи. Это называется мультиплексированием на канальном уровне. Что касается мультиплексирования на канальном уровне, то протоколы, лежащие над канальным уровнем, “не осведомлены” относительно наличия нескольких физических интерфейсов. Драйвер устройства канального уровня отвечает за мультиплексирование и маршрутизацию IP-пакетов через физические интерфейсы.

В Internet-архитектуре программный модуль, реализующий функции транспортного протокола (“субъект”), не имеет своего собственного адреса, но вместо него использует IP-адрес (адрес IP-протокола). Это касается сетевого, транспортного и прикладного уровней, а также интерфейсов между ними. Соответственно, прикладной программный модуль скорее всего должен быть осведомлён о нескольких IP-адресах многоадресной ГВМ. В других случаях, выбор может быть сделан самим сетевым программным модулем.
§3.3.4.2. Требования к множественной адресации

Далее приводятся правила выбора IP-адреса источника при передаче многоадресной ГВМ IP-пакета:

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

В противном случае, IP-адрес источника должен выбираться;

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

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

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

Разработчики ГВМ для Internet-сети использовали две различные концептуальные модели множественной адресации. Данный стандарт не отдаёт предпочтение какой-либо из этих моделей. Каждая из них имеет право на существование. Такая двойственность дополнительно отражается в двух рассмотренных ранее ключевых проблемах:

Устойчивая модель оконечной системы. В такой модели (strong es (End System) model, SESM) оконечной системы (например, ГВМ) основной акцент сделан на распознавании ГВМ/шлюза (ES/IS, End System/ Intermediate System), и SESM-модель могла бы заменить возможное условие (MAY) на обязательное требование (MUST) в обеих рассмотренных ранее проблемах А и В. Из этого следует, что модель многоадресной ГВМ может рассматриваться как совокупность логических ГВМ в рамках одной и той же физической ГВМ.

Что касается проблемы А, то сторонники SESM-модели заявляют, что способы автоматической маршрутизации в Internet-сети не способны направить IP-пакет на физический интерфейс, который не совпадает с IP-адресом получателя.

Согласно SESM-модели вычисление маршрута для исходящего IP-пакета представляет собой следующее соответствие:

route(src IP addr, dest IP addr, TOS)  gateway .

В данном случае IP-адрес источника включён в качестве параметра для выбора шлюза, непосредственно подключён к соответствующему физическому интерфейсу. Следует заметить, что SESM-модель, с точки зрения логики, требует наличие хотя бы одного шлюза “по умолчанию” на каждый IP-адрес источника (а лучше, чтобы было несколько шлюзов “по умолчанию”);

Слабая модель оконечной системы. В такой модели (weak es model — WESM) основное внимание не акцентируется на распознавании ГВМ/шлюза, и WESM-модель могла бы заменить возможное условие (MAY) на обязательное отрицательное требование (MUST NOT) в обеих рассмотренных ранее проблемах А и В. Данная WESM-модель может быть более приемлемой для ГВМ, которые перехватывают сообщения протоколов маршрутизации, реализуемых в шлюзах, и уж точно необходимой для ГВМ, которые включают в своём ПО программный модуль шлюза.

WESM-модель может нарушить реализацию функции перенаправления IP-пакетов (Redirect). Если IP-пакет был передан через физический интерфейс, который не соответствует IP-адресу получателя, то шлюз на противоположенной стороне первого ретрансляционного участка не будет “понимать” когда ему необходимо передать ICMP-сообщение “перенаправление”. С другой стороны, если ГВМ включает в своём ПО программный модуль шлюза, то она имеет маршрутную информацию без мониторинга ICMP-сообщений “перенаправление”.

Согласно WESM-модели вычисление маршрута для исходящего IP-пакета представляет собой следующее соответствие:

route(dest IP addr, TOS)  gateway, interface .
§3.3.4.3. Выбор IP-адреса источника

Когда передаётся запрос на установление соединения (например, ТСР-блок, в котором бит “SYN” равен единице), или запрос дейтаграммной службы (например, запрос UDP-протокола), то программному модулю транспортного уровня, входящему в состав ПО многоадресной ГВМ, необходимо знать какой IP-адрес источника следует использовать. Если прикладной программный модуль не решает эту задачу, то программный модуль транспортного уровня должен обратиться к программному IP-модулю для получения адреса, используя при этом следующее абстрактное соответствие:

GET_SRCADDR(remote IP addr, TOS)  local IP address .

При реализации этого соответствия рекомендуется придерживаться следующих правил:

Если удалённый IP-адрес принадлежит одной из (под)сетей, к которой ГВМ подключён напрямую, то соответствующий IP-адрес источника может выбираться но, до тех пор, пока конкретный интерфейс известен и зафиксирован в памяти;
Если существует возможность “прочтения” кэш-записи о маршруте, то следует проверить наличие действующего маршрута для конкретной сети-получателя через какой-либо локальный (физический) интерфейс. Если проверка дала положительный результат, то для такого интерфейса может быть выбран соответствующий локальный IP-адрес;
Если существует таблица статических маршрутов, то IP-адрес источника может быть выбран аналогичным способом;
Если существует возможность “прочтения” списка шлюзов “по умолчанию”, то следует проверить к каким интерфейсам “прикреплены” такие шлюзы. Если проверка дала положительный результат, то для самого приоритетного шлюза может быть выбран соответствующий интерфейс.

В дальнейшем, может будет найден некоторый способ в интересах многоадресных ГВМ, позволяющий запрашивать шлюзы во всех присоединённых сетях с целью получения о них уведомления о “наилучшей” сети, которую можно использовать с целью установления соединения до ГВМ-получателя.

Необходимо заметить, что, по-существу, этот способ во многом совпадает с маршрутизацией IP-пакетов, и поэтому ГВМ могут комбинировать и использовать оба способа.

1 2 3 4 5 6 7 8 9 10 11