В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 18
Текст из файла (страница 18)
ПРотокол 1Р 77 3 бита 1 бит Старшинство Тмп елуэкбы Подполе «Тип службы» 1000 Минимизация задержи« 0100 Максимиэакия пропускной способности 00 10 Максимизация надежности 0001 Минимизация финансовой стоимости 0000 Обычная служба Старшинство 111 Управление сетью 110 Управление объединенной сетью 101 Критично 100 Отмена групповой операции 111 Групповая операция 110 Немедленна 001 Приоритет 000 Процедура Рис.
3.1. Поле «Тип службы» заголовка пакета! Рк4 В оставшейся части этого раздела мы обсудим фрагментацию, а затем более подробно рассмотрим поля адресов, типа службы и параметров. Фрагментация и восстановление У различных сетей, составляк>щих объединенную сеть, могут различаться максимальные размеры пакетов. Было бы неэффективно и неудобно пытаться диктовать единый раамер пакетов для всех сетей.
Таким образом, маршрутизаторам может понадобиться разбить получаемые дейтаграммы на более мелкие фрагменты, прежде чем передать их дальше в следующую сеть. Если дейтаграммы могут фрагментировазъся (возможно, неоднократно) за время следования по маргпруту, возникает вопрос, где их восстанавливать. Самое простое решение — вгюстапавливать дейтаграммы только у получателя. Основной недостаток такоп> подхода состоит в том, что пакеты, проходя через сети, могут только уменьшаться. Это может негативно сказаться на эффективности некоторых сетей.
С другой стороны, если разрешить промежуточное восстановление фрагментированных дейтаграмм на маршрутизаторах, это может привести к некоторым нежелателыгым результатам: + 1>1аршрутизаторам для работы потребуются большие буферы, к тому же есть риск, что все буферное пространство окажется аанятым фрагментами дейтаграмм. + Все фрагменты дейтаграммы должны будут проходить через один и тот же шлюз. Это требование снижает преимущества динамической маршрутизации. В протоколе 1Р фрагменты дейтаграммы собираются на оконечной системе получателя. Алгоритм фрагментации 1Р использует следующую информаци>о 1Р-заголовка: + идентификатор (П>); + длина данных (разность между полной длиной и длиной Интернет-заголовка); + смещение фрагмента; + дополнительные флаги.
Оконечная система источника сгх>дает дейтаграмму со значением поля «Длина данных», равным полной длине поля данных, значением поля «Смещение фраг- згепта», равным нулю, и значением поля «Дополнительные флаги», также установленным на ноль (ложь). При фрагментации длинной дейтаграммы П>-модуль ьгаршрутизатора выполняет перечисленные ниже задачи: 1 Создает две новые дейтаграммы и копирует поля заголовка поступив>пей дейтаграммы в заголовки обеих дейтаП>амм, 2.
Делит полученное поле данных пользователя на две примерно равные части по 64-битовой границе и помещает каждую часть в отдельную дейтаграмму. Размер первой чанги должен быть кратен 64 битам. 3. Устанавливает значение поля «Длина данных» первой дейтаграммы равным длине вставленных данных, а также устанавливает значение поля «Дополнительные флаги» равным 1 (истина). Поле >Слгещение фрагмента» остается без изменений. 4.
Устанавливает значение поля «Длина данных» второй дейтаграммы равным длине вставленных данных, а также прибавляет к значении поля «Смещение фрагмента» длину первой части данных, деленнук> па 8. Поле «Дополнительные флаги» остается без изменений. На рис. 3.2 показан пример. Эта процедура может быть легко приведена к общему случаю деления дейтаграммы на п частей. Второй фрагмент длина данных равна 1ВВ байт С»мщение фпап«енга равно 20 единиц о 04 Кбиг каждая Попе дополнительных флагов Равна 0 Исходная дейтаграмма длина данных равна 404 байт Смещение фрагмента Равно 0 Поле дополнительных флагов равно 0 Рио 3 2 Пример фрагментации 7В Глава 3. Протоколы ТСР и (Р З.З.
Протокол (Р 79 Хост (24 бита) Клесс А 1 О,. -~'~в+,в' ' $.4фов)мг"!',",, к'. Хост (1б бит) К<асс В АдРеса 1РЧ4 Групповви рассылка 1110 Ковос й Зарезервировано нв будущее 1 1 1 1 О Ковос Е Рио. З.З. форматы адресов протокола <Рт4 Поле типа службы Ч тобы восстановить дейтаграмму, необходимо и достаточно буферного пространства. По мере прибытия фрагментов с одним и тем же идентификатором их поля данных накапливаются в буфере, пока поле данных не будет собрано целиком, Однако один или несколько фрагментов могут не дойти до получателя, поскольку служба 1Р не гарантирует доставки.
Поэтому требуется некий способ принятия решения о прекращении сборки и освобождении буфера. Обычно применяются два метода. В первом случае по прибытии первого фрагмента запускается локальный таймер. Если интервал ожидания истекает прежде, чем заверп<ается сборка, все полученные фрагменты отбрасываются.
Второй подход заключается в использовании поля времени жизни дейтаграммы, содержащегося в заголовке каждого фрагмента, и продолжении уменьшения этого поля функцией сборки. Как и при первом подходе, если время жизни истекает прежде, чем завершается сборка, все полученные фрагменты отбрасываются. Поля адресов отправителя и получателя заголовка 1Р содержат 32-разрядные глобальные межсетевые адреса, как правило, состоящие из идентификатора сети н идентификатора хоста. Адрес кодируется таким образом, чтобы для обозначения сети и хоста можно было задействовать переменное число битов, как это показано на рис. 3.3. Такой способ кодирования обеспечивает гибкость прн назначении адресов хостам и позволяет использовать различные размеры сетей в объединенной сети.
Для следующих условий лучше всего подходят три основных класса сетей: + класс А — немного сетей с большим количеством хостов; + класс  — среднее количество сетей со средним количеством хостов; + класс С вЂ” большое количество сетей с небольшим количеством хостов. В некотором окружении, возможно, лучп<е всего использовать адреса всех классов. Например, для корпоративной объединенной сети, состоящей из болыпого количества локальных сетей отделов, может потребоваться адрес класса С. Однако формат адреса позволяет смешивать все трн класса адресов в одной и той же обьединенной сети.
Смешивание классов приемлемо для объединенной сети, состоящей из нескольких больших сетей, большого числа маленьких сетей плюс некоторого количества сетей среднего размера. 1Р-адреса обычно записываются в виде четырех десятичных чисел, разделенных точками. Каждое число представляет один байт 32-разрядного адреса. Например, 1Р-адрес 11000000 11100100 00010001 00111001 записывается как 192.228.17.57. Обратите внимание на то, что все адреса сетей класса А начинаются с двоичного нуля. Сетевые адреса, первый байт которых равен 0 (двоичное 00000000) н 127 (двоичиое 01111111), зарезервированы; таким образом, существует 126 номеров сеген класса А у которых первый десятичный номер адреса может находиться в диапазоне от 1 до 126. Адреса сетей класса В начинаются с двоичной комбинации 10, поэтому днапаюн первого байта в адресе класса  — от 128 до 191 (от 10000000 до 10111111 в двоичной системе счисления).
Второй байт адреса класса В также тносится к номеру сети, поэтому может существовать 2и = 16 384 сетей с адре- ами класса В. Для адресов кт<асса С первое десятичное число варьируется в пределах от 192 до 223 (от 11000000 до 11011111). Суммарное количество адресов класса С составляет 2" - 2 097 152. Поле «Тип службые состоит из двух подполеи: 3-битового подполя сгаршннства и 4-битового подполя типа службы.
Эти подполя выполняют взаимодополняющие Функции. Подполе типа службы помогает 1Р-сущности (в источнике или маршрутизаторе) выбирать выходную линию для дейтаграммы, а подполе старшинства пред<тставляет информацию об относительном приоритете дейгаграл<мьт, что позволяет более оптимально выделять ресурсы для дейтаграмм, Подполе типа службы Подполе типа службы устанавливается отправителем, чтобы указать уровень ка'<ества обслуживания, который должен быть, по возможности, предоставлен этой дейтаграмме. Однако маршрутизатор может прореап<ровать па значение подпола типа службы (еслн он учитывает зто значение) тремя способами: + Выбор ма)ии)врпа. Решение о выборе маршрута можст быть сделано на основе типа службы.
Например, если дейтаграмма запрашивает минимальную задержку, ее не следует направлять по подсети, в которую входит спутниковая линия связи. 80 Глава 3. Протоколы ТОР и !Р З.З. Протокол 1Р 81 + Служба подсети. Для следующего транзитного участка маршрутизатор может потребовать у подсети тип службы, наиболее соответствующий указанному в подполе типа службы, Многие сети (например, АТМ) поддерживают различные типы служб.
+ Порядок обслуживания (дисциплина) очередей. Маршрутизатор может учесть значения подполей типа службы и старшинства при обслуживании очередей. Например, маршрутиаатор может предоставить первоочередное обслуживание дейтаграммам, требующим минимального времени задержки, или попь<таться избежать удаления дейтаграмм, требующих максимальной надежности. В документе КЕС 1349 определены текущая интерпретация поля типа службы, а в документе КГС 1812' перечислены требования к маршрутизаторах<. Оба документа сфокусированы на первой альтернативе, а именно на влиянии поля типа службы на выборе маршрута. Способ, которым маршрутизатор узнает, какими маршрутами какие типы служб поддерживаются, выходит за рамки данных спецификаций. В целом„существует две возможности. Во-первых, в домене маршрутизатора администратор домена может заранее связать разные значения полей с различными маршрутами.
Во-вторых, протокол маршрутизации может динамически следить за характеристиками различных маршрутов, учитывая время задержки, пропускную способность и количество отброшенных дейтаграмм. Алгоритм ОВРР (Ореп 81>от<ел< Рагй Гплг — первоочередное открытие кратчайших маршрутов) представляет собой пример протокола, поддерживающего данную способность (см. главу 15). При реализации маршрутизации с учетом значений поля типа службы документом КГС 1812 определяются следующие правила продвижения дейтаграмм с ненулевым значением этого поля: 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
