Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§2.2.2. Протокол запроса адреса канального уровня (ARP-протокол) §2.2.2.1. Проверка актуальности ARP-записей в кэш-памяти Программный модуль ARP-протокола (RFC-826) обязан реализовывать способ удаления неактуальных (устаревших) записей из кэш-памяти. Если указанный способ предусматривает использование метода тайм-аута (“timeout”), то должна быть предусмотрена возможность настройки конкретного значения тайм-аута. Программный ARP-модуль в обязательном порядке должен быть способен нейтрализовать поступающий чрезмерный трафик ARP-сообщений (“flooding”, многократно передаваемый ARP-запрос, содержащий один и тот же IP-адрес, с высокой скоростью). Максимальная рекомендуемая скорость передачи — не более одного сообщение для конкретного получателя за 1 секунду. Стандарт RFC-826 предлагает, но не обязывает, использовать метод тайм-аута для удаления неактуальных записей из кэш-памяти, когда ГВМ обмениваются своими Ethernet-адресами. Распространённость уполномоченных ARP-серверов существенно повысило вероятность того, что записи в кэш-памяти ГВМ будут устаревать, и более того, в настоящее время существует обязательное требование к ГВМ — наличие некоего программного средства для аннулирования ARP-содержимого кэш-памяти. Даже в случае отсутствия уполномоченного ARP-сервера реализация метода долговременного тайм-аута при хранении ARP-записей в кэш-памяти является весьма полезной, что обеспечивает автоматическую корректировку любых неправильных ARP-данных, которые могли быть записаны в кэш-память. Для удаления устаревших данных из кэш-памяти использовались следующие четыре метода (иногда в определенных комбинациях): “Тайм-аут” — периодическое, по истечении определённого периода времени, удаление записей из кэш-памяти, даже если они используются. В момент обновления кэш-записи целесообразно начинать повторный отсчёт (рестарт) времени тайм-аута (путём отслеживания адресов отправителей, не взирая на адрес получателя, из широковещательных ARP-запросов, передаваемых сети). В случае использования уполномоченного ARP-сервера, время тайм-аута должно составлять порядка одной минуты; “Однонаправленный опрос”(“Unicast Poll”) — постоянный опрос удалённой ГВМ путём периодической передачи ей ARP-запросов с использованием сквозного соединения, и последующим удалением записи, если ARP-ответ не был получен после N следующих друг за другом опросов. В данном случае время тайм-аута также должно составлять порядка одной минуты, а N обычно равно двум; “Контроль со стороны канального уровня” (“Link-Layer Advice”) — если аппаратно-программный модуль канального уровня способен обнаруживать проблемы, связанные с доставкой кадров, то он способен удалять соответствующую ARP-запись из кэш-памяти; “Контроль со стороны сетевого (IP-)уровня” (“Higher-Layer Advice”) — реализация IP-уровнем (Internet-уровнем) функции “обращения” к канального уровню с целью указания возникновения проблемы, связанной с доставкой пакетов. Результатом такого вызова могло бы быть аннулирование соответствующей кэш-записи. Такое “обращение” могло бы быть аналогично функции “обращения” (“ADVISE_DELIVPROB()”) к IP-уровню, реализуемой транспортным уровнем, и в действительности процесс, выполняющий функцию “ADVISE_DELIVPROB()”, мог направить своё обращение к процессу контроля со стороны канального уровня с целью удаления соответствующей ARP-записи из кэш-памяти. В первом и втором методах, предусматривающих использование тайм-аута при удаление записей из кэш-памяти, значение времени тайм-аута должно быть порядка одной минуты или меньше. В случае отсутствия в системе уполномоченных ARP-серверов слишком малое значение тайм-аута могло привести к появлению чрезмерного служебного трафика в крупных Ethernet-сетях. Более того, могла возникнуть необходимость настраивать ГВМ с целью увеличения времени тайм-аута при хранении ARP-записи в кэш-памяти. §2.2.2.2. Очередь ARP-пакетов Программно-аппаратный модуль канального уровня должен хранить (а не удалять), по крайней мере, один (самый последний) ARP-пакет (пакет с ARP-сообщением) из всей совокупности пакетов, передаваемых с одним и тем же не назначенным IP-адресом получателя, а затем после того, как будет назначен IP-адрес, передать этот сохранённый пакет. Было бы не правильным следовать данной рекомендации в случаях потери первого пакета при каждой ПИнО. Несмотря не то, что протоколы верхних уровней, в целом, могли бы справиться с потерей пакета путём повторной передачи, потеря пакетов является серьёзной нештатной ситуацией. Например, потеря открытого TCP-запроса может быть вызвана чрезмерно завышенной начальной оценкой времени прохождения ТСР-блока по круговому маршруту (до ГВМ назначения и обратно). Прикладные системы, основывающиеся на UDP-протоколе (например, DNS-система), могут “понести ещё более тяжелые потери”. §2.2.3. Ethernet-сеть и IEEE-802-стандарт Процедура обрамления (конвертирования) и разобрамления канальных Ethernet-кадров на сетевом (IP-)уровне представлена в стандарте RFC-894, тогда как стандарт RFC-1042 описывает эту же процедуру для кадров ЛВС стандарта IEEE-802. Каждая ГВМ Ethernet-сети, подключенная к 10 Mбит/с сети с помощью кабеля,: должна быть способна (в обязательном порядке) передавать и принимать IP-пакеты, используя обрамление (конвертирование) и разобрамления канальных Ethernet-кадров (RFC-894); должна быть способна (в рекомендательном порядке) принимать IP-пакеты стандарта RFC-1042 “вперемешку” с IP-пакетами стандарта RFC-894; должна иметь возможность передавать IP-пакеты, используя обрамление (конвертирование) канальных кадров ЛВС стандарта IEEE-802 (RFC-1042). ГВМ Internet-сети, которая способна передавать IP-пакеты обоих стандартов RFC-894 и RFC-1042, используя процедуру обрамления (конвертирования), должна в обязательном порядке обеспечивать настройку функции коммутации пакетов для выбора, какой из них должен быть передан, а если используется режим “по умолчанию”, то тогда должна быть реализована функция коммутации пакетов в соответствие со стандартом RFC-894. Необходимо отметить, что в процедуре обрамления канальных IEEE-802-кадров на IP-уровне, представленная в стандарте RFC-1042, не используется для значение идентификатора протокола К1=6, которое американский IEEE-институт зарезервировал для IP-протокола шестой версии (IPv6). Вместо этого, используется значение К1=170, означающее расширение “SNAP”, которое может быть использовано для размещения поля “Ether-Type”. В Internet-системе запрещено передавать IP-пакеты, содержащие канальные IEEE-802-кадры и использующие значение идентификатора протокола К1=6. Преобразование IP-адресов в адреса канального уровня, которые используются в Ethernet-сетях и ЛВС стандарта IEEE-802, должно осуществляться под управлением ARP-протокола. Значение MTU-параметра должно быть: для Ethernet-сетей — 1500; для ЛВС стандарта IEEE-802.3 — 1492. Стандарт IEEE-802.3 описывает функционирование ЛВС на основе проводной (витая пара) Ethernet-сети со скоростью передачи 10 Mбит/с. В таком случае в физической среде передачи будут транслироваться “вперемешку” кадры канального уровня Ethernet- и IEEE-802.3-стандартов. Приёмник способен распознать Ethernet- и IEEE-802.3-кадры путём проверки значения в поле “размер” (“Length”) заголовка IEEE-802.3-кадра. Это двухоктетное поле совпадает с полем “Ether-Type” (“Тип Ethernet-кадра”) заголовка Ethernet-кадра. В частности, значение в поле “размер” заголовка IEEE-802.3-кадра должно быть меньше или равно 1500, а все допустимые значения в поле “Ether-Type” заголовка Ethernet-кадра — больше 1500. Другая проблема совместимости связана с широковещательным режимом передачи на канальном уровне. ГВМ-отправитель, функционирующая в широковещательном режиме, транслирует кадры определённой структуры, которые не будут восприниматься ГВМ, способными принимать кадры только другой структуры. Главная цель данного параграфа — обеспечение (максимально, на сколько это возможно) непосредственного (прямого) взаимодействия между ЛВС, функционирующими по стандартам RFC-894 и RFC-1042, и объединенными в одну корпоративную систему. Это означает необходимость поддержки существующей ситуации, при которой доминируют в основном только ЛВС стандарта RFC-894, и что в последующем возможен сравнительно лёгкий переход к наиболее перспективным ЛВС стандарта RFC-1042, получающим всё большее и большее распространение. Следует заметить, что ЛВС стандарта RFC-894 не могут напрямую взаимодействовать с ЛВС стандарта RFC-1042. Если эти две системы соединены с помощью одного кабеля как две различные логические сети, то они могут взаимодействовать только через IP-шлюз. Более того, это просто не полезно и даже не возможно при использовании двухформатной ГВМ в процессе автоматического определения формата переданного кадра канального уровня, так как существует проблема совместимости при передаче кадров в широковещательным режиме. §2.3. Канальный интерфейс (между сетевым и канальным уровнями) Канальный интерфейс, получивший IP-пакет от сетевого уровня, должен включать в заголовок соответствующий флаг с целью указания того, что поступивший IP-пакет необходимо транслировать в широковещательном режиме с использованием широковещательного адреса канального уровня. Несмотря на то, что сетевой (IP-)уровень, в принципе, не знает адреса канального уровня (так как каждая сеть, основанная на определённой среде передачи, как правило, имеет свой формат адресов), широковещательный адрес для среды передачи, реализующей широковещательный режим доставки, является очень важным частным случаем. По существу, проблема заключается в чрезмерности трафика, генерируемого при широковещательном режиме доставки. IP-пакет, проходящий через канальный интерфейс, должен включать 5-битовое поле “Тип обслуживания” (в составе поля “Категория обслуживания пакета”). Канальный уровень не должен информировать IP-уровень об ошибке “ГВМ-получатель не достижима” только потому, что в кэш-памяти не используется ARP-запись о ГВМ-получателе. §2.4. Требования к ГВМ на канальном уровне На рис.3 представлена таблица с общими требованиями к ГВМ на канальном уровне. III. СЕТЕВОЙ (IP-)УРОВЕНЬ §3.1. Общие положения Принцип надёжности и функциональной совместимости системы: “Beliberalinwhatyouaccept, andconservativeinwhatyousend” (“Будьте снисходительны к тому, что вы получаете, и требовательны к тому, что вы передаёте”), — является наиболее важным для сетевого уровня, на котором всего лишь одна некорректно функционирующая ГВМ может сделать недоступной Internet-службу для многих других ГВМ. Стандартными протоколами сетевого уровня являются: RFC-791 — описывает IP-протокол (Internetworking (или просто Internet) Protocol — протокол межсетевого взаимодействия) и содержит введение в Internet-архитектуру;
Рис.3. Требования к ГВМ на канальном уровне RFC-792 — описывает ICMP-протокол (Internet Control Message Protocol — Internet-протокол доставки управляющих сообщений), который реализует функции маршрутизации, диагностики и обнаружения и устранения ошибок в интересах IP-протокола. Несмотря на то, что ICMP-сообщения обрамляются в IP-пакеты (дейтаграммы), обработка ICMP-сообщений рассматривается (и как правило является) частью функций сетевого уровня; RFC-950 — описывает обязательные правила расширения систем за счёт присоединения подсетей с точки зрения архитектуры адресации; RFC-1112 — описывает IGMP-протокол (Internet Group Management Protocol — Internet-протокол для управления группами ГВМ), который является частью рекомендаций по расширению систем за счёт использования специализированного интерфейса в ГВМ и ГВМ/шлюзах, позволяющего реализовать на сетевом уровне режим групповой адресации в пределах глобальной Internet-системы. Цель групповой IP-адресации может заключаться в регулировании функционирования произвольной группы ГВМ в Internet-системе. Режим групповой IP-адресации был разработан как естественное дополнение к уже имеющимся средствам групповой адресации на сетевом уровне в некоторых сетях. Он также предоставляет стандартные средства локального доступа к таким средствам. Программный модуль, реализующий функции сетевого уровня, должен в обязательном порядке включать IP- и ICMP-субмодули. На программный модуль сетевого уровня возложена реализация двух основных функций: выбор следующего ретрансляционного участка до шлюза или ГВМ для передачи исходящих IP-пакетов (дейтаграмм), то есть их коммутация; повторная сборка входящих IP-пакетов (дейтаграмм). Кроме этого, программный IP-модуль может выполнять преднамеренную фрагментацию исходящих IP-пакетов (дейтаграмм), а также обязан реализовывать функции диагностики и обнаружения и устранения ошибок. Очевидно, что функциональность программного IP-модуля в перспективе будет расширяться, так как средства управления и контроля в Internet-системе продолжают совершенствоваться. обработка стандартных IP-пакетов заключается в их дальнейшем “продвижении” по сети. При поступлении IP-пакетов программный IP-модуль осуществляет: проверку того, что IP-пакет корректно сформатирован; проверку того, что IP-пакет предназначен для локальной ГВМ; реализацию дополнительных функций; повторную сборку IP-пакета, если это необходимо; отправку расконвертированного транспортного блока на соответствующий программный модуль транспортного уровня. При отправке исходящих IP-пакетов программный IP-модуль осуществляет: заполнение всех полей, какие не были заполнены на транспортном уровне; выбор первого ретрансляционного участка на присоединённой сети (этот процесс называется “маршрутизацией”); фрагментирование IP-пакета, если это необходимо, и если предусмотрена принудительная фрагментация; отправку IP-пакета(ов) на соответствующий программно-аппаратный модуль канального уровня. ГВМ называют многоадресной (multihomed) если ей присвоено несколько IP-адресов. Многоадресность привносит существенную “путаницу” и сложность в совокупность Internet-протоколов, и она является той областью, в которой Internet-архитектура имеет серьёзные недостатки при решении всех проблем. При использовании режима многоадресности возникают две определённые проблемные области: режим локальной многоадресности — сама ГВМ является многоадресной; режим удалённой многоадресности — локальной ГВМ необходимо установить соединение с удаленной многоадресной ГВМ. В настоящее время режим удалённой многоадресности должен быть в обязательном порядке контролируемым (управляемым) на прикладном уровне (RFC-1123). ГВМ может функционировать в режиме локальной многоадресности. Любая ГВМ, которая ретранслирует IP-пакеты, сформированные другой ГВМ, функционирует как шлюз (маршрутизатор) и поэтому должна удовлетворять требованиям представленным стандарте RFC-1009. ГВМ в Internet-сети, которая включает в своём программном обеспечении (ПО) программный модуль шлюза, должна иметь возможность выключения режима шлюза, а в режиме “по умолчанию” должна функционировать с выключенным режимом шлюза. В этом режиме IP-пакет поступивший на один из канальных интерфейсов не должен ретранслироваться на другую ГВМ или другой шлюз (если он не указан источником, определившим маршрут доставки), не взирая, является ли ГВМ одноадресной или многоадресной. ПО ГВМ запрещается в автоматическом режиме переходить в режим шлюза, если ГВМ имеет более одного интерфейса. Последнее объясняется тем, что пользователь ГВМ, либо может не пожелать предоставлять такую услугу, либо просто не будет знать как такую услугу предоставлять. В дальнейшем, при приёме IP-пакетов в определённых случаях используется процедура “удаление по умолчанию”. Это означает, что IP-пакет будет уничтожаться без проведения какой-либо последующей процедуры, и что после этого ГВМ не будет передавать никакого ICMP-сообщения об ошибке. Тем не менее, с целью диагностики возникшей проблемы целесообразно, чтобы ГВМ реализовывала функцию регистрации ошибок, включая запись содержания IP-пакета, удалённого “по умолчанию”. Кроме этого, целесообразно использовать счётчик нештатных событий, значение которого бы увеличивалось на единицу после каждого такого события. В общем, процедура “удаления по умолчанию” ошибочных IP-пакетов предназначена для “борьбы” с чрезмерным потоком IP-пакетов, передаваемых в широковещательном режиме (“broadcast storms”). |