Для обеспечения информационного взаимодействия на сетевом уровне необходимо установление однозначного соответствия логического (сетевого) и физического (канального) адресов взаимодействующих узлов. Протокол ARP используется для того, чтобы установить значение физического адреса хоста по известному логическому адресу. Для решения обратной задачи – определения сетевого адреса для конкретной станции используется протокол, который имеет название RARP (Reverse ARP). Оба эти протокола предполагают выполнение информационного обмена между узлами с использованием кадров одинакового типа.
Структура кадра ARP
|
|||||||
| 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 не имеет фиксированной длины. Его длина определяется значением одного из полей.
|
||||||||||||
| 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
В данном поле размещается проверочная контрольная сумма заголовка кадра.
Источник : lectures.net.ru/tcpip/2/
RSS & RSS to Email