Протоколы компьютерных сетей и сетевые операционные системы

Описанную процедуру управления потоком I-кадров по звену реализует ПС. Однако может случиться так, что ВС в силу каких-то событий, наступивших на ее стороне, потребуется прекратить поток I-кадров. Например, при стратегии “возврат-к-N” повторных передач окно поступлений равно 1 и поэтому не трудно обеспечить наличие у получателя достаточного объема буферной памяти. При использовании же режима выборочной повторной передачи возможна ситуация, при которой у ВС не хватит объема памяти для приема новых кадров. В такой ситуации ВС направит ПС супервизорный кадр ПНГ, сообщая ей о необходимости прекратить посылку I-кадров. Конечно, это не влияет на извещающие кадры, следовательно, как только буферная память освободится до заранее установленного предела, ВС возвратит ПС кадр ПГ, в котором установлен N(R), указывающий ПС, с какого кадра она должна возобновить повторную передачу.

Рассмотрим на примере передачу кадров в РНО и АСР.

Режим нормального ответа. Первичная станция передает 13 кадров. Окно передач от 0 до 7. Ошибки в 3 и в 6 кадрах.

Запрос каждые 4 кадра.

Сквозная передача. (При сквозной передаче передаются все 7 кадров, а только в последнем запрос.)

Диаграмма передачи кадров в режиме нормального ответа протокола HDLC приведена на рисунке 16.

Асинхронно сбалансированный режим. От станции А передается 10 кадров, во 2 ошибка. Окно передач от 0 до 7. Сквозная передача. От станции В передается 6 кадров. Ошибок нет. Сквозная передача.

Диаграмма передачи кадров в асинхронно сбалансированном режиме показана на рисунке 17. В СПД могут использоваться иные протоколы информационного канала, отличающиеся структурой кадра и составом процедур управления взаимодействия станций и передачею данных. Для разделения данных на кадры используются различные схемы. В процедуре HDLC кадр выделяется флагами “01111110”, отмечающими начало и конец кадра. Эта схема построения кадра предполагает использование битстаффинга для обеспечения прозрачности канала. Другая схема - указание в заголовке кадра длины поля данных. В этом случае приемник принимает n байтов, следующих за заголовком, как данные, вложенные в кадр. В протоколе двоичной синхронной связи (BSC) кадр формируется парами специальных знаков начала и окончания кадра. При передаче данных станция анализирует последовательность символов и, если встречается пара символов, тождественных окончанию кадра, разделяет эти символы, вставляя между ними первый из них. При приеме кадра выполняется обратное преобразование данных.



Рисунок 15 - Процедура извещения с прицепом



Рисунок 16 - Диаграмма передачи кадров в РНО протокола HDLC. 1. Запрос каждые 4 кадра. 2. Сквозная передача



Рисунок 17 - Диаграмма передачи кадров в АСР протокола HDLC

Контрольные вопросы

Назначение протокола HDLC.

Назначение I - кадра.

Назначение U - кадра.

Назначение S - кадра.

Может ли вторичная станция передавать сообщение первичной станции в режиме РНО?

Зарисовать порядок передачи кадров в РНО, если от первичной станции передается 12 кадров (сквозная передача от 0-7), в 4 и 6 кадре ошибка.

Зарисовать порядок передачи кадров в АСР, если от станции А передается 12 кадров (сквозная передача от 0-7), в 2 и 5 кадре ошибка, от станции В передается 8 кадров (сквозная передача от 0-7), ошибок нет.

Что определяет поле S - в супервизорном кадре?

Раздел 5. Протоколы нижнего уровня сети INTERNET

Составная сеть (internetwork, или internet) - это совокупность нескольких сетей, называемых также подсетями (subnet), которые соединяются между собой маршрутизаторами. В настоящее время стек ТСР/IР является самым популярным средством организации составных сетей.

Стек ТСР/IР был разработан до появления модели взаимодействия открытых систем ISO/OSI. Он также имеет многоуровневую структуру, но соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.

Идеологическим отличием архитектуры стека ТСР/IP является интерпретация функций самого нижнего уровня - уровня сетевых интерфейсов (network interface). Так, например, нижние уровни модели OSI (канальный и физический) нагружены функциями по доступу к среде передачи, формированию кадров и согласованию уровней электрических сигналов, кодированию и синхронизации и другими весьма конкретными действиями.

У нижнего уровня стека ТСР/IP задача существенно проще - он отвечает только за организацию интерфейса с частными технологиями подсетей. Для каждой технологии, включаемой в составную сеть подсети, должны быть разработаны собственные интерфейсные средства. К таким интерфейсным средствам относится протокол ARP, который служит для преобразования сетевых адресов в МАС-адреса и RARР, который служит для определения IP-адреса по МАС-адресу.

5.1 Протокол ARP

Поскольку IP-адреса - лишь логические адреса, необходимо установить соответствие между ними и физическими адресами устройств, например, адресами сетевых адаптеров Ethernet или TokenRing. Протокол преобразования адресов (Address Resolution Protocol, ARP) предоставляет средства для поиска физического адреса устройства при известном его IP-адресе. Этот процесс называют разрешение адреса (address resolution).

Протокол преобразования адресов ARP. Internet-протокол семейства TCP/IP, используемый для преобразования IP-адреса в МАС-адрес. Описан в RFC 826.

Объекты протокола ARP классифицируются либо как клиенты разрешения адреса (address resolution clients), либо как услуги разрешения адреса (address resolution services). Клиенты разрешения адреса обычно реализуются в узлах клиентов, в то время как услуги разрешения адреса обычно обеспечиваются узлами обслуживания.

Протоколы определяют, передаются ли данные через сетевой уровень к верхним уровням эталонной модели OSI. В основном, для того чтобы это произошло, необходимо, чтобы пакет данных содержал МАС - и IP-адрес пункта назначения. Если в пакете данных отсутствует один из этих адресов, данные не будут переданы на верхние уровни. Таким образом, МАС - и IP-адрес служат для своего рода проверки и дополнения друг друга.

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

Когда какой-нибудь клиент приступает к работе, клиенты и услуги ARP реализуют следующий алгоритм. Сначала данный клиент отправляет широкой рассылкой пакеты запросов-заявок. Затем каждая услуга, которая является соседом данного клиента, отвечает пакетом ответа об услуге. Далее данный клиент выдает пакет запроса о присваивании адреса в первую услугу, которая ответила на его пакет запроса-заявки. Услуга отвечает пакетом ответа о присваивании адреса, содержащим присвоенный адрес объединенной сети.

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

5.1.1 Формат протокола ARP

В отличие от большинства протоколов, данные в пакетах ARP не имеют фиксированного формата заголовка. Вместо этого его сообщения были разработаны так, чтобы их можно было использовать для различных сетевых технологий. Поэтому, первые поля заголовка содержат счетчики, которые указывают длину следующих полей. Фактически, ARP можно использовать с произвольными физическими адресами и произвольными протокольными адресами. Пример на рисунке 18 показывает 28-октетный формат сообщения ARP, используемый для оборудования Ethernet (у которого физические адреса являются 48-битовыми или 6-октетными) при разрешении протокольных адресов IP (имеющих длину 4 октета).



Рисунок 18- Пример формата сообщения ARP/RARP для разрешения адресов IP-Ethernet

Длины полей зависят от длин аппаратных и протокольных адресов, которые имеют значение соответственно 6 октетов для адреса Ethernetа и 4 октета для IP-адреса.

Рисунок 18. показывает сообщение ARP по 4 байта в строке. К сожалению, в отличие от большинства остальных протоколов, поля переменной длины в пакетах ARP не выровнены на границу 32 бит, что приводит к трудности восприятия диаграммы. Например, аппаратный адрес отправителя, помеченный как отправитель АА, занимает 6 непрерывных октетов, что приводит к появлению его на двух строках диаграммы.

Поле тип оборудования определяет тип аппаратного интерфейса, для которого отправитель ищет ответ; оно содержит значение 1 для Ethernetа. Аналогичным образом, поле тип протокола указывает тип адреса протокола более высокого уровня, который использует отправитель. Поле операция указывает запрос ARP(1), ответ ARP(2), запрос RARP(3), или ответ RARP(4) RARP, другой протокол, использующий тот же самый формат сообщения. Поля HLEN и PLEN позволяют использовать ARP в любых сетях, так как они указывают длину аппаратного адреса и адреса протокола верхнего уровня. Отправитель передает свой аппаратный адрес и IP-адрес, если они известны ему, в полях отправитель АА и отправитель IP.

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

5.1.2 Работа протокола ARP

Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети или же протокол глобальной сети (Х.25, Frame Relay), как правило, не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу - нахождение IP-адреса по известному локальному адресу. Он называется реверсивным ARP (Reverse Address Resolution Protocol, RARP) и используется при старте бездисковых станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.

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

Для осуществления коммуникации в сети Ethernet станция-источник должна знать IP- и МАС-адреса станции-получателя. После того как станция-отправитель определила IP-адрес станции-получателя, Internet-протокол источника использует таблицу ARP для нахождения соответствующего МАС-адреса получателя.

Когда отправитель определил IP-адрес получателя (рисунок 19.), он смотрит в свою ARP-таблицу, для того чтобы узнать его МАС - адрес. Если источник обнаруживает, что МАС - и IP-адрес получателя присутствуют в его таблице, он устанавливает соответствие между ними, а затем использует их в ходе инкапсуляции данных. После этого пакет данных по сетевой среде отправляется адресату.

Рисунок19- Источник сверяется со своей ARP-таблицей после того, как определит IP-адрес пункта назначения

Таблица 2 - Пример ARP-таблицы

IP-адрес	МАС-адрес	Тип записи
197.15.22.33	008048ЕВ7Е60	Динамический
197.15.22.44	08005А21А722	Динамический
197.15.22.4	008048ЕВ7567	Статический

Работа протокола ARP (рисунок 20) начинается с просмотра ARP-таблицы. Каждая строка таблицы устанавливает соответствие между IP-адресом и МАС-адресом. Для каждой сети, подключенной к сетевому адаптеру компьютера или к порту маршрутизатора, строится отдельная ARP-таблица.

Поле “Тип записи” может содержать одно из двух значений - “динамический” или “статистический”. Статистические записи создаются вручную с помощью утилиты arp и не имеют срока устаревания, точнее, они существуют до тех пор, пока компьютер или маршрутизатор не будут выключены. Динамические же записи создаются модулем протокола ARP, использующим широковещательные возможности локальных сетевых технологий. Динамические записи должны периодически обновляться. Если запись не обновлялась в течение определенного времени (порядка нескольких минут), то она исключается из таблицы. Таким образом, в ARP-таблице содержатся записи не обо всех узлах сети, а только о тех, которые активно участвуют в сетевых операциях.

В глобальных сетях администратору сети чаще всего приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети Х.25, который имеет для протокола Ip смысл локального адреса. В последнее время наметилась тенденция автоматизации работы протокола ARP ив глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети. При таком централизованном подходе для всех узлов и маршрутизаторов вручную нужно знать только IP-адрес и локальный адрес выделенного маршрутизатора. Затем каждый узел и маршрутизатор регистрирует свои адреса в выделенном маршрутизаторе, а при необходимости установления соответствия между IP-адресом и локальным адресом. Узел обращается к выделенному маршрутизатору с запросом и автоматически получает ответ без участия администратора. Работающий таким образом маршрутизатор называют ARP-сервером.



Рисунок 20 - Данные принимаются получателем, после того как установлено соответствие между МАС - и IP- адресами и инкапсулированы данные

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

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

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

Если отправитель хочет отправить данные другому устройству, и он знает IP-адрес получателя, но МАС-адрес получателя в его ARP-таблице отсутствует, то устройство инициирует процесс, называемый ARP-запросом, который позволяет определить этот МАС-адрес. Сначала устройство создает пакет ARP-запроса и посылает его всем устройствам в сети. Для того чтобы пакет ARP-запроса был замечен всеми устройствами в сети, источник использует МАС-адрес широковещания. Адрес широковещания, используемый в схеме МАС-адресации, имеет значение F во всех разрядах. Таким образом, МАС-адрес широковещания имеет вид FF-FF-FF-FF-FF-FF.

В примере, показанном на рисунке 21, отправитель не может обнаружить МАС-адрес получателя в своей ARP-таблице.

ARP-запросы структурированы определенным способом. Поскольку протокол ARP функционирует на нижних уровнях эталонной модели OSI, сообщение, в котором содержится ARP-запрос, должно быть инкапсулировано внутри кадра протокола аппаратных средств. Таким образом, кадр ARP-запроса состоит из двух частей: заголовка и ARP-сообщения. Кадр ARP-запроса показан на рисунке 22. Кроме того, заголовок кадра может быть затем разделен на МАС - и IP-заголовок. Заголовок кадра показан на рисунке 23.



Рисунок 21 - Отправитель не может обнаружить МАС-адрес получателя в своей ARP-таблице

Рисунок 22 - Кадр ARP-запроса состоит из заголовка и ARP-сообщения

Рисунок 23 - Заголовок кадра ARP-запроса

Поскольку пакет ARP-запроса посылается в режиме широковещания, его принимают все устройства в локальной сети и передают для анализа на сетевой уровень. Если IP-адрес устройства соответствует IP-адресу пункта назначения, содержащемуся в ARP-запросе, устройство откликается путем отправки источнику своего МАС-адреса. Этот процесс называется ARP-ответом. В примере, показанном на рисунке 21, источник 197.15.22.33 запрашивает МАС-адрес получателя, имеющего IP-адрес 197.15.22.126. Получатель 197.15.22.126 принимает ARP-запрос и откликается путем отправки ARP-ответа, содержащего его МАС-адрес. Структура ARP-ответа приведена на рисунке 24.

Рисунок 24- Структура ARP-ответа

Когда устройство, создавшее ARP-запрос, получает ответ, оно извлекает МАС-адрес из МАС-заголовка и обновляет свою ARP-таблицу. Теперь, когда устройство имеет всю нужную ему информацию, оно может добавить к данным МАС - и IP-адрес пункта назначения. Устройство использует эту новую структуру кадра для инкапсуляции данных перед отправкой их по сети. Новая структура кадра для инкапсуляции данных перед отправкой их по сети показана на рисунке 25.

Когда данные достигают адресата, производится сравнение на канальном уровне. Канальный уровень убирает МАС-заголовок и передает данные на следующий уровень эталонной модели OSI - сетевой. Сетевой уровень анализирует данные и обнаруживает, что его IP-адрес соответствует IP-адресу назначения, содержащемуся в IP-заголовке данных. Сетевой уровень убирает IP-заголовок и передает данные следующему более высокому уровню - транспортному (уровень 4). Этот процесс повторяется, пока остаток пакета не достигнет приложения, где данные будут прочитаны.



Рисунок 25 - Новая структура кадра для инкапсуляции данных перед отправкой их по сети.

5.2 Протокол RARP

Для того чтобы сетевое устройство могло отправить данные на транспортный уровень эталонной модели OSI, необходимы и МАС -, и IP-адрес. Таким образом, МАС - и IP-адрес служат для проверки и дополнения друг друга. Чтобы получатель, принимающий данные, знал, кто их отправил, пакет данных должен содержать МАС - и IP-адреса источника. А что произойдет, если источник знает свой МАС-адрес, но не знает своего IP-адреса? Протокол, который используют устройства, не знающие своего IP-адреса, называется протоколом обратного преобразования адреса (Reverse Address Resolution Protocol, RARP). Протокол семейства TCP/IP, представляющий собой метод определения IP-адресов по МАС-адресу. Как и ARP, RARP связывает МАС-адреса с IP-адресами, чтобы сетевое устройство могло использовать их для инкапсуляции данных перед отправкой в сеть. Для использования данного протокола в сети должен присутствовать RARP-сервер, отвечающий на RARP-запросы. Использование RARP-сервера показано на рисунке 26.

Представим, что источник хочет послать данные другому устройству. Однако источник знает свой МАС-адрес, но не может обнаружить собственный IP-адрес в своей ARP-таблице. Чтобы получатель мог оставить у себя данные, передать их на верхние уровни эталонной модели OSI и распознать устройство, которое отправило данные, источник должен включить в пакет данных свои МАС - и IP-адреса. Поэтому источник инициирует процесс, называемый RARP-запросом, позволяющий ему определить собственный IP-адрес. Для этого устройство создает пакет RARP-запроса и посылает его в сеть. Для того чтобы пакет RARP-запроса был замечен всеми устройствами в сети, источник использует IP-адрес широковещания.

RARP-запросы имеют такую же структуру, как и ARP-запросы. Структура пакета RARP-запроса приведена на рисунке 27. Следовательно, RARP-запрос состоит из МАС - и IP-заголовка, а также сообщения RARP-запроса. Единственное отличие в формате RARP-пакета заключается в том, что заполнены МАС-адреса источника и получателя, а поле IP-адреса источника - пустое. Поскольку сообщение передается в режиме широковещания, то есть всем устройствам в сети, адрес назначения записывается в виде всех двоичных единиц.

Так как RARP-запрос посылается в режиме широковещания, его видят все устройства в сети. Однако только специальный RARP-сервер может отозваться на RARP-запрос. RARP-сервер служит для отправки RARP-ответа, в котором содержится IP-адрес устройства, создавшего RARP-запрос (рисунок 27.).



Рисунок 26 - Для ответов на RARP-запросы необходим RARP-сервер

Рисунок 27 - Формат пакета RARP-запроса

RARP-ответы имеют такую же структуру, как и ARP-ответы. RARP-ответ состоит из сообщения RARP-ответа, МАС- и IP-заголовка. Когда устройство, создавшее RARP-запрос, получает ответ, оно обнаруживает свой IP-адрес. На рисунке 28 показано, что происходит в ситуации, когда сервер с IP-адресом 197.15.22.126 откликается на IP-запрос от бездисковой рабочей станции с МАС-адресом 08-00-20-67-92-89.



Рисунок 28 - RARP-сервер откликается на IP-запрос от рабочей станции с МАС-адресом 08-00-20-67-92-89

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

Недостаток RARP в том, что он использует адреса всех первых получателей (ограниченное транслирование), чтобы достигнуть RARP сервера. Однако такие широковещательные передачи не пересылаются маршрутизаторами. Таким образом, RARP-сервер нужен в каждой сети.

Протокол RARP используется в бездисковых компьютерах. Бездисковая рабочая станция считывает собственный адрес уровня соединения из сетевой интерфейсной карты. Дальше передается широковещательный запрос с просьбой к другому компьютеру определить и передать IP-адрес станции на основании ее адреса уровня соединения. Получив IP-адрес, рабочая станция передает широковещательный запрос к другому компьютеру с просьбой загрузить ее операционную систему. Таким образом, протокол RARP позволяет подсоединять бездисковые рабочие станции к Интернет и загружать их из удаленных сетевых компьютеров.

Контрольные вопросы

Назначение протокола ARP.

Назначение протокола RARP.

Когда какой-нибудь клиент приступает к работе, какой алгоритм реализуют клиенты и услуги ARP?

От чего зависит длина полей протокола ARP?

Что определяет в формате протокола поле «тип оборудования»?

Когда у протокола Ip возникает необходимость обращения к протоколу ARP?

Назначение МАС - адреса.

Как создаются статические и динамические записи в ARP- таблице?

Какое устройство называют ARP - сервером и почему?

Что произойдет, если IP - адрес в ARP- таблице не будет обнаружен?

Что произойдет, если отправитель хочет отправить данные другому устройству и он знает IP-адрес получателя, но МАС-адрес получателя в его ARP-таблице отсутствует?

Какой вид имеет широковещательный МАС-адрес?

Что происходит, когда устройство, создавшее ARP-запрос, получает ответ?

Раздел 6. IP - протокол

6.1 IP - протокол версии 4

6.1.1 Основы протокола IPv4

В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791)

IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP).

Поле «Версия» характеризует версию IP-протокола (например, 4 или 6)

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

Длина заголовка, измеряемая в 32-разрядных словах, обычно содержит 20 октетов (HLEN=5, без опций и заполнителя).

Поле «полная длина» определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные.

Одно-октетное поле (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей (рисунок 30.):

Приоритет	D	T	R	C	Не используется

Рис. 30. Формат поля TOS

Субполе «приоритет» (3 бита) предоставляет возможность присвоить код приоритета каждой дейтограмме (в настоящее время это поле не используется).

Биты C, D, T, R характеризуют пожелания относительно способа доставки дейтограммы. Так D=1 требует минимальной задержки, T=1 - высокую пропускную способность, R=1 - высокую надежность, а C=1 - низкую стоимость. TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP).

Идентификатор, флаги (3 бита) и указатель фрагмента. Поля управляют процессом фрагментации и последующей "сборки" дейтограммы. Идентификатор представляет собой уникальный код дейтограммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтограмм. Бит 0 поля «флаги» является резервным, бит 1 служит для управления фрагментацией пакетов (0 - фрагментация разрешена; 1 - запрещена), бит 2 определяет, является ли данный фрагмент последним (0 - последний фрагмент; 1 - следует ожидать продолжения).

Время жизни (TTL - Time To Life). Задает время жизни дейтограммы в секундах, то есть предельно допустимое время пребывания дейтограммы в системе. При каждой обработке дейтограммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтограмма из системы удаляется.

Поле «Протокол» определяет структуру поля данные

Поле «Контрольная сумма заголовка» вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтограммы.

Поле «Опции» не обязательно присутствует в каждой дейтограмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, используется заполнитель. Структура октета кода опции отражена на рисунке 31

Рисунок 31 - Формат описания опций

Флаг копия равный 1 говорит о том, что опция должна быть скопирована во все фрагменты дейтограммы

При равенстве этого флага 0 опция копируется только в первый фрагмент. В таблице 3 приведены значения разрядов 2 - битового поля класса опции:

Таблица 3. Значения разрядов 2-битового поля класса опций

Значение поля класс опции	Описание
0	Дейтограмма пользователя или сетевое управление
1	Зарезервировано для будущего использования
2	Отладка и измерения (диагностика)
3	Зарезервировано для будущего использования

Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут создает дейтограмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, утилита traceroute). Формат опции «записать маршрут в дейтограмме» представлен ниже на рисунке 32:



Рисунок 32 - Формат опций «записать маршрут в дейтограмме»

Поле «код» содержит номер опции (7 в данном случае).

Поле «длина» определяет размер записи для опций, включая первые 3 октета.

«Указатель» отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса).

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

Рисунок 33 - Формат опций маршрутизации

Жесткая маршрутизация означает, что адреса определяют точный маршрут дейтограммы. Проход от одного адреса к другому может включать только одну сеть.

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

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

Просмотр маршрутной таблицы происходит в три этапа:

1) Ищется полное соответствие адресу места назначения. В случае успеха, пакет посылается соответствующему маршрутизатору или непосредственно интерфейсу адресата. Связи точка-точка выявляются именно на этом этапе.

2) Ищется соответствие адресу сети места назначения. В случае успеха система действует так же, как и в предшествующем пункте. Одна запись в таблице маршрутизации соответствует всем ЭВМ, входящим в данную сеть.

3) Осуществляется поиск маршрута по умолчанию и, если он найден, дейтограмма посылается в соответствующий маршрутизатор.

Опция «временные метки» работает так же, как и опция «запись маршрута». Каждый маршрутизатор на пути дейтограммы делает запись в одном из полей дейтограммы (два слова по 32 разряда). Формат этой опции отображен на рисунке 34.



Рисунок 34 - Формат опции "временные метки"

Смысл полей «длина» и «указатель» идентичен тому, что сказано о предыдущих опциях. 4-битовое поле «переполнение» содержит число маршрутизаторов, которые не смогли записать временные метки из-за ограничений выделенного места в дейтограмме.

6.1.2 Общие принципы адресации протокола IPv4

Основы IP-адресации. IP-адрес представляет собой уникальную четырехоктетную (32-битовую) величину, выраженную в десятичных числах, разделенных точками в форме W.X.Y.Z, где точки используются для разделения октетов (например, 10.0.0.1). Поле адреса размером 32 бита состоит из двух частей: адрес сети или связи (который представляет собой сетевую часть адреса) и адрес хоста (идентифицирующий хост в сетевом сегменте). Разграничение сетей по количеству хостов в них традиционно осуществляется на основе так называемых классов IP-адресов. Сегодня существует 5 классов IP-адресов (три из которых используются для уникальной адресации сетей и хостов): A, B, C, D и E.

Только адреса классов А, В и С могут использоваться как уникальные. Адреса класса D применяются для обращения к набору узлов, а адреса класса Е зарезервированы для исследовательских целей и в настоящее время не используются. Несколько адресов во всех классах зарезервированы для специальных целей.

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

Адреса класса А. Сети класса А определяются значением 0 самого старшего (левого) бита в адресе. Первый октет (биты с 0 по 7), начинаются с левого бита в адресе. Этот октет определяет количество подсетей сети, в то время как оставшиеся три октета (биты с 8 по 31) представляют количество хостов в сети. Возьмем для примера адрес в сети класса А 124.0.0.1. Здесь 124.0.0.0 представляет собой адрес сети, а единица в конце адреса обозначает первый хост в этой сети. В результате такого представления (рисунок 35) в сетях класса А можно адресовать 128 (27) подсетей

Рисунок 35 - Общий вид IP-адреса класса А

После определения в сети, первый и последний адреса хостов в ней выполняют специальные функции. Так, первый адрес 124.0.0.0 (из приведенного выше примера) используется в качестве адреса сети, а последний адрес (124.255.255.255) представляет собой широковещательный адрес для этой сети. Таким образом, с помощью адресов класса А можно представить только 16777214 (216-1) хостов в каждой сети.

Адреса класса B. Сети класса В определяются значениями 1 и 0 в старших битах адреса. Первые два октета в адресе (биты с 0 по 15) служат для представления адресов сетей, а оставшиеся два октета представляют номера хостов в этих сетях. В результате мы получим 16384 (214) адреса сетей с 65534 (216-2) хостов в каждой (рисунок 36). Так, например, в адресе класса В 172.16.0.1, адрес сети - 172.16.0.0, 1 - номер хоста



Рисунок 36 - Общий вид IP-адреса класса B

Адреса класса C. Сети класса С определяются значениями 1, 1 и 0 старших битов в адресе. Первые три октета (биты с 0 по 23) используются для представления номеров сетей, а последний октет (биты с 24 по 31) представляет собой номера хостов в сети. Таким образом, получаем 2097152 (221) сетей, в каждой из которых находится 254 (28-2) хоста (рисунок 37). Для примера возьмем адрес в сети класса С 192.11.1.1, где 192.11.1.0 представляет собой адрес сети, а номер хоста в сети - 1.

Рисунок 37 - Общий вид IP-адреса класса C

Адреса класса D. Сети класса D определяются значениями 1, 1, 1 и 0 в первых четырех битах IP - адреса. Адресное пространство класса D зарезервировано для представления групповых IP - адресов, которые используются для адресации набора узлов. Это означает, что данный пакет должен быть доставлен сразу нескольким узлам, которые образуют группу с номером, указанным в поле адреса.

Адреса класса E. Сети класса E определяются значениями 1, 1, 1 и 1 в старших четырех битах IP - адреса. В настоящее время адреса этого диапазона не используются. Они зарезервированы для экспериментальных целей.

Адресация подсетей. Как и номера хост-машин в сетях класса A, класса B и класса C, адреса подсетей задаются локально. Обычно это выполняет сетевой администратор. Так же, как и другие IP - адреса, каждый адрес подсети является уникальным. Использование подсети никак не отражается на том, как внешний мир видит эту сеть, но в пределах организации подсети рассматриваются как дополнительные структуры.

Для примера, сеть 172.16.0.0 (рисунок 38) разделена на 4 подсети: 172.16.1.0, 172.16.2.0, 172.16.3.0 и 172.16.4.0. Маршрутизатор определяет сеть назначения, используя адрес подсети, тем самым ограничивая объем трафика в других сегментах сети.

Рисунок 38 - Сеть 172.16.0.0 состоит из четырех подсетей

С точки зрения адресации, подсети являются расширением сетевого номера (рисунок 39). Сетевые администраторы задают размеры подсетей, исходя из потребностей организации и роста.



Рисунок 39 - Адресация подсетей расширяет сетевой номер путем создания подсетей

Адрес подсети включает номера сети, подсети и хост-машины внутри подсети. Благодаря этим трем уровням адресации подсети обеспечивают сетевым администраторам повышенную гибкость настройки.

Чтобы создать адрес подсети, сетевой администратор "заимствует" биты из поля хост-машин и переопределяет их в качестве поля подсетей (рисунок 40). Количество "заимствованных" битов можно увеличивать до тех пор, пока не останется 2 бита. Поскольку в поле хостов сетей класса B имеются только 2 октета, для создания подсетей можно заимствовать до 14 бит. Сети класса C имеют только один октет в поле хостов. Следовательно, в сетях класса C для создания подсетей можно заимствовать до 6 бит.

Рисунок 40 - Биты заимствуются из поля хост-машины и переопределяются в качестве поля подсети

Чем больше бит заимствуется из поля хоста, тем меньше бит в октете можно использовать для задания номера хоста. Таким образом, каждый раз, когда заимствуется 1 бит из поля хоста, число адресов хостов, которые могут быть заданы, уменьшается на степень числа 2.

Чтобы понять смысл вышесказанного, рассмотрим сеть класса C. Все 8 бит в последнем октете используются для поля хостов. Следовательно, возможное количество адресов равно 28 или 256.

Представим, что эту сеть разделили на подсети. Если из поля хостов заимствовать 1 бит, количество бит, которое можно использовать для адресации хостов, уменьшится до 7. Если записать все возможные комбинации нулей и единиц, можно убедится, что число хостов, которые можно адресовать, стало равно 27 или 128.

Если в сети класса C из поля хостов заимствовать 2 бита, то количество бит, которое можно использовать для адресации хостов, уменьшится до 6. Общее число хостов, которое можно адресовать, станет равным 26 или 64.

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

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

6.1.3 Маскирование подсетей

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

Маски подсетей используют тот же формат, что и IP - адресация. Другими словами, маска имеет длину 32 бита и разделена на 4 октета. Маски подсетей имеют все единицы в части, отвечающей сети и подсети, и все нули в части, отвечающей хост - машине. По умолчанию, если нет заимствованных битов, маска подсети сети класса B будет иметь вид 255.255.0.0. Если же заимствовано 8 бит, маской подсети той же сети класса B будет 255.255.255.0 (рисунок 41). Поскольку для сетей класса B только 2 октета относится к полю хост - машин, то для создания подсетей может быть задействовано до 14 бит. В сетях класса C только один октет относится к полю хост - машин, поэтому для создания подсетей может быть заимствовано до 16 бит.

Маски подсети также используют 32-битовые IP- адреса, которые содержат все двоичные единицы в сетевой и подсетевой части адреса, и все двоичные нули - в хостовой части адреса. Таким образом, адрес маски подсети класса B с 8 заимствованными битами из поля хостов будет иметь вид 255.255.255.0.

Рисунок 41 - Биты для создания подсети заимствуются из поля хост-машин, начиная со старших позиций

Теперь рассмотрим сеть класса B. Для создания подсети вместо 8 бит в третьем октете заимствуются только 7. в двоичном представлении маска подсети в этом случае будет иметь вид 11111111.11111111.11111110.00000000. Следовательно, адрес 255.255.255.0 не может больше использоваться в качестве маски подсети.

6.1.4 Планирование подсетей

Сети, изображенной на рисунке 42., присвоен адрес класса C 201.222.5.0. Предположим, необходимо организовать 20 подсетей по 5 хостов в каждой. Можно разделить последний октет на части подсети и хостов и определить, какой вид будет иметь маска подсети. Размер поля подсети выбирается исходя из требуемого количества подсетей. В этом примере выбор 29-битовой маски дает возможность иметь 221 подсеть. Адресами подсетей являются все адреса, кратные 8 (например, 201.222.5.16, 201.222.5.32 и 201.222.5.48).

Оставшиеся биты в последнем октете используются для поля хост - машин. Для данного примера требуемое количество хост - машин равно 5, поэтому поле хост - машин должно содержать минимум 3 бита. Номера хост - машин могут быть 1, 2, 3 и т.д. окончательный вид адресов формируется путем сложения начального адреса кабеля сети/подсети и номера хост - машины.

Рисунок 42 - Необходимо разделить сеть на 20 подсетей (по 5 хостов в каждой)

Таким образом, хост - машины подсети 201.222.5.16 будут адресоваться как 201.222.5.17, 201.222.5.18, 201.222.5.19 и т.д. номер хоста 0 зарезервирован в качестве адреса кабеля, а значение номера хоста, состоящее из одних единиц, резервируется для широковещания.

Пример планирования подсетей в сетях класса B. На рисунке 43 показано комбинирование входящих IP - адресов с маской подсети для получения номера подсети.



Рисунок 43 - Пример планирования подсетей в сети класса В

Выделение 8 бит для подсетей позволяет адресовать до 254 подсетей и 254 хостов.

6.2 IP - Протокол версии 6 (IPv6)

6.2.1 IPv6 представляет собой новую версию протокола Интернет, являющуюся преемницей версии 4. Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

Расширение адресации. В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.

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

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

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

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

6.2.2 Поле «Версия» 4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6).

Поле «Приоритет» 4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.

6.2.3 Предполагается, что чем больше код, тем выше приоритет данных, тем быстрее они должны быть доставлены. Так, для передачи мультимедийной информации, где управление скоростью передачи не возможно, уровень приоритета должен лежать в пределах 8-15. Практически уровни приоритета, выше или равные 8, зарезервированы для передачи данных в реальном масштабе времени.

Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью).

«Метка потока» - 24-битный код метки потока (для мультимедиа).

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая, например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

Поток - это последовательность пакетов, посылаемых отправителем определенному адресату, при этом предполагается, что все пакеты данного потока должны быть подвергнуты определенной обработке. Характер этой специальной обработки может быть передан маршрутизатору посредством протокола управления или внутри самих пакетов, например, в опции hop-by-hop.

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

6.2.4 Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации, но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

6.2.5 Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными.

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

Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд.

Отправитель не должен использовать старую метку для нового потока в пределах времени жизни любого потока. Так как режим обработки потока на 6 секунд может быть установлен для любого потока, минимальный интервал между последним пакетом одного потока и первым пакетом нового, использующего ту же метку, должно быть равно 6 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше.

Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой, еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память так, чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.

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

Размер поля данных - 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций.

При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина, полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено, как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

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

Предельное число шагов (максимальное время жизни пакета) - 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется.

В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения используют ограничения по TTL, так что фактически это не принципиальное изменение.

«Адрес отправителя» - 128-битовый адрес отправителя пакета.

«Адрес получателя» - 128-битовый адрес получателя пакета (возможно, не конечный получатель, если присутствует маршрутный заголовок).