Семейство протоколов TCP/IP. Протоколы ARP и RARP. Структура дейтаграммы IP.

Протоколы ARP и RARP. Структура дейтаграммы IP

Для обеспечения информационного взаимодействия на сетевом уровне необходимо установление однозначного соответствия логического (сетевого) и физического (канального) адресов взаимодействующих узлов. Протокол ARP используется для того, чтобы установить значение физического адреса хоста по известному логическому адресу. Для решения обратной задачи – определения сетевого адреса для конкретной станции используется протокол, который имеет название RARP (Reverse ARP). Оба эти протокола предполагают выполнение информационного обмена между узлами с использованием кадров одинакового типа.

Структура кадра ARP

Таблица 2.2.1.

В поле Hardware Type помещается признак типа используемого протокола канального уровня. Протоколу Ethernet соответствует значение 1 данного поля.

В поле Protocol Type помещается признак типа используемого протокола сетевого уровня. Протоколу IP соответствует значение 0800 данного поля.

Содержимое полей HLEN и PLEN определяет размер адреса канального и сетевого уровня соответственно. Наличие данных полей обеспечивает возможность использования протокола ARP для определения физического адреса в различных сетях второго и третьего уровня.

В поле Operation размещается признак типа информационного кадра ARP

Таблица 2.2.2.

Поля IP (Network Address). В полях Target IP и Sender IP кадров ARP и RARP размещаются сетевые адреса станции назначения и передающей станции, соответственно.

Поля HA (Hardware Address). В полях Target HA и Sender HA кадров ARP и RARP размещаются физические адреса станции назначения и передающей станции, соответственно.

Скрытые сети. Протокол ARP может быть использован для построения закрытых фрагментов локальных сетей. В качестве устройства, которое используется для разделения открытого и закрытого фрагментов локальной сети в данном случае может быть применён двух портовый сервер Proxy ARP.

Протокол RARP (Reverse ARP) предназначен для выполнения функции, которая диаметрально противоположна функции протокола ARP. Протокол RARP предназначен для определения логического сетевого адреса для узла сети, который определен своим физическим МАС- адресом. Необходимость в использовании такого протокола возникает в тех случаях, когда в локальной сети используются бездисковые рабочие станции. Поскольку специальных запоминающих устройств для хранения сетевого адреса на бездисковой рабочей станции нет и быть не может, следовательно, этот адрес должен быть присвоен ей динамически. Для динамического присвоения сетевого адреса бездисковым рабочим станциям используется протокол RARP. Отличие кадров RARP и ARP заключается только в значении поля Ether TYPE:

•  RARP 8035;

•  ARP 0806.

Организация RARP-взаимодействия компонентов сети. Для того, чтобы кадр RARP мог достичь всех абонентов данной сети, в качестве МАС- адреса назначения этого пакета используется адрес типа broadcast. Сформированный таким образом кадр называется RARP – запрос (RARP request). На кадр данного типа может ответить только устройство, которое выполняет функцию RARP – сервер.

Функцию RARP – сервера в сети выполняет специальная станция, которая может установить соответствие между физическим и математическим адресами станций. Обычно это соответствие устанавливается при помощи специальных динамических таблиц, в которых каждой станции по её физическому адресу ставится в соответствие логический – сетевой адрес. Таким образом, информационное взаимодействие при выполнении протокола RARP состоит из следующих этапов:

•  Получение RARP – запроса от рабочей станции;

•  RARP – сервер определяет значение МАС- адреса;

•  RARP – сервер определяет по таблице значение сетевого адреса;

•  RARP – сервер формирует кадр RARP – reply.

Очевидно, что использование одной рабочей станции в качестве RARP – сервера не может обеспечить достаточной надежности. Станция, которая выполняет данную функцию в сети, может выйти из строя, или может быть слишком перегружена для того, чтобы вовремя ответить на RARP – запрос. Поскольку ответ на запрос не будет получен, станция, которая сформировала запрос, будет вынуждена повторять его снова и снова. Единственным выходом из данной ситуации может быть резервирование RARP – сервера.

Простое резервирование (например - дублирование) этих устройств может привести к возникновению дополнительных трудностей. К таким трудностям, в частности, относится возможность возникновения коллизий при одновременном ответе на RARP – запрос двумя RARP – серверами. Для разрешения этой проблемы должно быть проведено ранжирование серверов на первичный и вторичные. Для предотвращения коллизий в данном случае может быть использовано две схемы:

•  Задержка ответа вторичного RARP – сервера на такт;

•  Задержка ответа вторичного RARP – сервера на случайный отрезок времени.

При использовании первой схемы в сети может только один вторичный RARP–сервер, который отвечает на RARP–запрос только в том случае, если он был послан повторно. Очевидно, что использование данной схемы не позволяет избежать возникновения коллизии в том случае, когда первый запрос был потерян из-за временной перегрузки первичного RARP – сервера или вследствие возникновения проблем в канале передачи на физическом уровне.

При использовании второй схемы в сети могут находиться несколько вторичных RARP–серверов. Каждый из этих вторичных серверов отвечает на RARP – запрос по прошествии интервала времени, величина которого определяется случайным образом. Очевидно, что в данном случае, вероятность возникновения коллизий при ответе вторичных серверов существенно уменьшается.

Помимо обеспечения адресации узлов сети, определения маршрута, по которому должны быть доставлены пакеты, протокол сетевого уровня IP (Internet Protocol) обеспечивает доставку дейтаграмм между узлами данной сети. Поскольку в этом протоколе не предусмотрено никаких дополнительных механизмов для обеспечения гарантированной доставки дейтаграмм, этот вид сервиса называется ненадежным (unreliable). Но, тем не менее, данный сервис может быть успешно использован в тех случаях, когда гарантированная доставка либо не требуется совсем, либо обеспечивается использованием дополнительных механизмов протоколов верхних уровней.

Структура дейтаграммы IP. Дейтаграмма состоит из двух частей:

•  Заголовок дейтаграммы (Datagram Header)

•  Поле данных дейтаграммы (Datagram Data Area)

Информация пользователя размещается в поле данных дейтаграммы. В это поле могут быть помещены в частности блоки данных протоколов верхних уровней. В заголовке дейтаграммы размещается информация, которая необходима для того, чтобы доставить содержимое полезной нагрузки в требуемый узел назначения сети.

Заголовок дейтаграммы IP не имеет фиксированной длины. Его длина определяется значением одного из полей.

Формат заголовка дейтаграммы IP

Таблица 2.2.3.

В поле VERS заголовка дейтаграммы IP размещается номер версии протокола IP, который был использован для формирования данной дейтаграммы.

В поле HLEN , которое занимает 4 бита в заголовке дейтаграммы IP, размещается длина этого заголовка, которая выражена в 32 – битовых словах.

Поле SERVICE TYPE(TOS) занимает один байт в заголовке дейтаграммы и, в свою очередь, подразделяется на несколько полей:

Поле PRECEDENCE (превосходство) занимает три бита в поле TOS и предназначено для явного указания степени важности информации, которая размещается в поле полезной нагрузки данной дейтаграммы.

Биты D, T, R используются для того, чтобы указать, какой тип каналов передачи данных должен быть использован для обеспечения доставки полезной нагрузки данной дейтаграммы. Бит D указывает на то, что при передаче данной дейтаграммы должно отдаваться предпочтение каналам с минимальной задержкой. Наличие бита T указывает на то, что при передаче данной дейтаграммы должно отдаваться предпочтение каналам с максимальной пропускной способностью задержкой. Бит R устанавливается в том случае, если для передачи дейтаграммы должны использоваться преимущественно надежные каналы.

Поле TOTAL LENGTH занимает 16 бит в заголовке дейтаграммы и предназначено для указания размера поля данных, которое выражено в байтах. Максимальный размер поля полезной нагрузки составляет, таким образом, 65535 байт. Однако при передаче такой дейтаграммы через сеть IEEE 802.3 неминуемо возникнет необходимость в её преобразовании в совокупность дейтаграмм, каждая из которых не превышает 1518 байт.

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

Процесс восстановления исходного вида передаваемого сообщения путем соединения переданных фрагментов называется дефрагментацией .

Одной из важных характеристик протокола канального уровня, является параметр MTU (maximum transfer unit) - максимальная длина передаваемого блока данных. Ограничение этого размера, как правило, определяется типом используемой процедуры доступа к каналу и не может быть изменено. В процессе передачи дейтаграммы по сети, она может проходить через каналы с различными значениями MTU. Очевидно, что для успешной передачи дейтаграммы в данном случае необходимо, чтобы она была фрагментирована на части, размер которых соответствует минимальному значению MTU среди всех используемых в данном случае каналов передачи данных. Каждая из полученных таким образом дейтаграмм называется фрагмент. Каждый фрагмент снабжается своим заголовком и передается по сети независимо от других фрагментов этого же сообщения. При поступлении первого фрагмента на станцию назначения включается специальный таймер фрагментации, который определяет максимальную величину временного интервала и в течение которого на данную станцию должны поступить все фрагменты передаваемого сообщения. В том случае, если по истечении установленного интервала на станцию поступят не все фрагменты сообщения, исходная дейтаграмма не будет считаться принятой данной станцией.

Поле IDENTIFICATION занимает 2 байта в заголовке дейтаграммы. В данном поле должен быть расположен уникальный идентификатор, который формируется передающей станцией для того, чтобы обеспечить отличие фрагментов одной дейтаграммы от фрагментов другой такой – же дейтаграммы.

Поле FLAGS занимает 3 бита в заголовке дейтаграммы. Два бита (младший и средний) данного поля предназначены для указания отношения данной дейтаграммы к процессу фрагментации. Третий бит в данном случае не используется.

Значение младшего бита определяет, возможно, или нет выполнение фрагментации данной дейтаграммы.

Средний бит имеет название MF (More Fragments). Значение этого бита определяет порядок данного фрагмента в общей цепочке фрагментов данного сообщения. У всех, кроме последнего, фрагментов одного сообщения бит MF должен быть установлен в 1.

Содержимое поля FRAGMENT OFFSET определяет смещение, которое выражено в 8 байтовых отрезках и соответствует месту данного фрагмента в исходном сообщении. Для первого фрагмента сообщения содержимое данного поля должно быть равно 0.

Содержимое поля TIME TO LIVE используется для того, чтобы ограничить возможность бесконечного перемещения в сети ошибочно адресованных дейтаграмм. Значение данного поля формируется при первой передаче каждой дейтаграммы. При перемещении этой дейтаграммы по сети значение поля TIME TO LIVE уменьшается на время, которое было затрачено на её обработку в каждом активном узле. В том случае, если значение этого поля становится равным 0, дейтаграмма считается просроченной и уничтожается. Маршрутизатор, который уничтожил дейтаграмму, должен послать соответствующее сообщение в адрес её источника.

Содержимое поля PROTOCOL определяет тип протокола, который был использован при формировании полезной нагрузки данной дейтаграммы.

В поле HEADER CHECKSUM размещается проверочная контрольная сумма заголовка кадра.