Александр Филимонов

Сети ЭВМ и телекоммуникации




Начало > Основы TCP/IP

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

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

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

0 8 16 24 31
Hardware Type Protocol Type
HLEN PLEN Operation
Sender HA
Sender HA Sender IP
Sender IP Sender HA
Sender IP
Sender HA

Поле Hardware Type

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

Поле Protocol Type

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

Поля HLEN и PLEN

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

Поле Operation

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

Operation Значение
ARP Request 1
ARP Response 2
RARP Request 3
RARP Response 4

Поля IP (Network Address)

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

Поля HA (Hardware Address)

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

Частные применения протокола ARP

Скрытые сети

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

Протокол RARP

Протокол 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 – сервер формирует кадр RARP – reply

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

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

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

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

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

Уровни информационного взаимодействия в сетях Internet

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

Структура дейтаграммы IP

Дейтаграмма состоит из двух частей:

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

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

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

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

0 4 8 16 19 24 31
VERS HLEN SERVICE TYPE TOTAL LENGTH
IDENTIFICATION FLAGS FRAGMENT OFFSET
TIME TO LIVE PROTOCOL HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS PADDING
DATA

Поле VERS

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

Поле HLEN

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

Поле SERVICE TYPE(TOS)

Это поле занимает один байт в заголовке дейтаграммы и, в свою очередь, подразделяется на несколько полей:

PRECEDENCE D T R Unused

Поле PRECEDENCE

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

Биты D, T, R

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

Поле TOTAL LENGTH

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

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

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

Фрагментация и дефрагментация IP дейтаграмм

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

Поле IDENTIFICATION

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

Поле FLAGS

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

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

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

Поле FRAGMENT OFFSET

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

Поле TIME TO LIVE

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

Поле PROTOCOL

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

Поле HEADER CHECKSUM

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


< Предыдущая лекция
Организация информационного взаимодействия на сетевом уровне модели OSI
Следующая лекция
Доставка дейтаграмм в сетях TCP/IP
>

Поиск

Поиск документов на RFC.net



© 2000— Александр Филимонов
© 2001— Алексей Бусыгин

Top.Mail.Ru