Общая схема сетевого взаимодействия

1. ОБЩАЯ СХЕМА СЕТЕВОГО ВЗАИМОДЕЙСТВИЯ 1.1. Классы компьютерных сетей Каждый из терминов «компьютерная сеть», «коммуникационная сеть», «сеть передачи данных» имеет своё специфическое содержание, которое следует уточнять в случае необходимости, но в целом, все они обозначают техническую систему, т. е. совокупность аппаратных и программных компонент с определёнными физическими и информационными связями, которая способна выполнять потребительскую функцию – передавать информацию между конечными узлами системы. Структура компьютерной сети включает две базисные составляющие: 1. конечные узлы, создающие и получающие информацию, 2. коммуникационную среду, т. е. подсистему, создающую физические связи между конечными узлами. Приведённое определение компьютерной сети справедливо в отношении весьма отличающихся по своему назначению и масштабу систем. Сети внутри процессорного чипа и на системной плате поддерживают функционирование аппаратных средств вычислительного узла (регистры процессора, АЛУ, кэш-память) и его периферийных устройств. Сеть, объединяющая вычислительные узлы распределённой информационной системы, обеспечивает обмен сообщениями между программными модулями операционных систем узлов и между взаимно удалёнными приложениями обработки данных. Несмотря на то, что функция этих сетей одна и та же (транспорт данных между конечными узлами), их организация заметно отличается. В целом, по критериям числа объединяемых конечных узлов и их взаимной удаленности можно определить четыре класса сетей. 1. Сети систем на кристалле (On-Chip Networks, OCN), объединяют микроархитектурные функциональные модули реализованного на одном кристалле устройства. Число модулей – несколько десятков; расстояния между ними – не более нескольких миллиметров. Особенность сети – 14 предельная компактность и устойчивость физических связей компонент. Для взаимосвязи модулей используются линии и коммутаторы, формируемые непосредственно на чипе. Примером такой сети является сеть многоядерного процессора KNL (Intel Xeon Phi), объединяющая до 72 вычислительных ядер (рис.1.1). Рисунок 1.1. Процессор Intel Xeon Phi Knights Landing 72 ядра (по два в 36 модулях) объединены сетью с топологией 2D-решетка. 2. Системные сети и сети хранения данных (System/storage area networks, SANs) – это сети суперкомпьютеров, вычислительных центров и центров обработки данных. Они обеспечивают взаимосвязь нескольких сотен или тысяч вычислительных узлов и устройств хранения данных, расположенных в пределах телекоммуникационного шкафа или вычислительного центра (несколько десятков метров). Отличительными чертами системных сетей являются предельно низкая задержка передачи сообщений и высокая степень координации работы узлов. Очень часто такие сети строятся на основе закрытых фирменных протоколов, но в последнее десятилетие сильные позиции в этом секторе заняла технология Infiniband, реализуемая в оборудовании доступном на открытом рынке. Для сетей систем хранения успешно используются технологии Fibre Chanel и высокоскоростные варианты Ethernet (10, 100 Гбит/с). 15 3. Локальные (кампусовые) сети обеспечивают потребности предприятий и организаций в информационном обеспечении их деятельности. В состав таких сетей могут входить до нескольких тысяч вычислительных узлов, находящихся на расстояниях до нескольких десятков километров. Они должны поддерживать обмен сообщений между разными приложениями; структура связей в сети изменчива. Доминирующей технологией в таких сетях является Ethernet. 4. Глобальные сети (Wide area networks, WANs) – их задачей является обеспечение взаимосвязи локальных сетей, работающих на основе разных технологий, а масштабы хорошо понятны из названия. Схематически рассмотренная классификация сетей передачи данных представлена на рис. 1.2. Как и всякая классификация, она условна и в выбранных метриках классы сетей могут перекрываться. Системные сети по числу узлов и расстояниям между ними могут быть отнесены и к локальным сетям. Одни и те же технологи могут использоваться в сетях разных классов; так, технологии Infiniband и Ethernet успешно работают и в системных, и локальных сетях. Диаметр сети (м) 5x106 WAN 5x103 LAN 5x100 SAN OCN 5x10-3 100 101 102 103 104 Число компьютеров 105 Рисунок 1.2. Основные классы сетей передачи данных Несмотря на разнообразие функциональных свойств и масштабов сетей, существуют общие проблемы их построения, в том числе: выбор способа преобразования сообщений в сигналы, обеспечение надежности их доставки, устойчивость сети к нарушениям работы отдельных её компонент, 16 определение метрик качества функционирования и т.д. Обсуждение этих вопросов начнём с определения функций, выполняемых сетью и конечными узлами для организации взаимодействия распределённых приложений. 1.2. Функции конечных узлов Для простоты рассмотрения представим сеть обобщённым каналом связи и в конечных узлах выделим лишь буферы, в которых размещаются сообщения приложений (рис. 1.3). Канал передачи данных, связывающий пару конечных узлов, является частью сети и включает в себя: − аппаратные средства преобразования данных в физические сигналы, их передачи и приема, − среду распространения физических сигналов, Узел А RX TX TX RX Узел Б NIC NIC − программные компоненты протокола связи. Рисунок 1.3. Два узла соединены дуплексным каналом Данные по каналу могут передаваться только в одном направлении (симплексный канал), попеременно в обоих направлениях (полудуплексный) и одновременно в обоих направлениях (дуплексный канал). В рассматриваемом примере будем считать канал дуплексным. Предположим, что приложению 1 на узле А, необходимо получить данные (например, файл), находящиеся на узле Б. Для этого: 1. Приложение 1 на узле А: − формирует специальное сообщение – запрос, в котором указывает имя, адрес местонахождения требуемого файла и предполагаемое действие с ним (в данном случае, копирование); − поручает своей операционной системе (ОС) отправить это сообщение. 17 2. ОС узла А дополняет полученное от приложения сообщение адресной и контрольной информацией, формируя блок данных коммуникационного протокола (БДКП), и размещает его в буфере сетевого адаптера. 3. Сетевой адаптер (NIC) копирует биты из буфера отправки и преобразует их в физические сигналы, передаваемые по линии к узлу Б. 4. Узел Б: − Средствами сетевого адаптера принимает сигналы, преобразует их в биты и размещает в приёмном буфере NIC; − Средствами ОС обрабатывает сообщение–запрос (проверяет целостность и адресную информацию) и передает его приложению 2; − При положительном результате обработки запроса приложение 2 на узе Б копирует запрошенный файл в свой буфер, создаёт сообщение – ответ, в котором размещает данные этого файла, передаёт его своей ОС и далее — сетевому адаптеру; последний преобразует биты БДКП в физические сигналы, которые по каналу связи передаются к узлу А. 5. Узел А принимает сообщение-ответ; при положительном результате его обработки узлу Б будет отправлено сообщение-подтверждение о получении файла. В рассмотренном примере по умолчанию считалось, что любое сообщение может быть размещено в одном БДКП. Однако, в общем случае, это не так, и каждая сетевая технология накладывает свои ограничения на размеры единичного блока данных коммуникационного протокола. Поэтому, операционная система узла на этапе передачи сообщения сетевому адаптеру выполняет его фрагментацию на блоки приемлемого размера (пока для простоты будем называть их пакетами), а при приёме – объединяет пакеты в исходное сообщение и передаёт его приложению. Для выполнения операций фрагментации и сборки сообщений в состав служебной информации, которой дополняется каждый пересылаемый пакет, включаются идентификатор сообщения, порядковый номер пакета в нём и ряд других служебных данных. 18 Пространство пользователя Приложение 1 Буфер 1 Приложение 2 Буфер 1 Ядро ОС Узел Б ОС Аппаратные ресурсы Узел А СА Буфер 2 ОС СА Буфер 3 Буфер 2 Буфер 3 Рисунок 1.4. Схема взаимодействия сетевых приложений Из приведенного описания коммуникационной операции, структурная схема которой представлена на рис.1.4, видно, что: − необходимо взаимодействие между приложением, операционной системой и сетевым адаптером каждого конечного узла; − сообщения имеют определенный тип (запрос, ответ, подтверждение); − операционная система выполняет формирование сообщений, их фрагментацию и сборку; − сетевые адаптеры конечных узлов, располагая средствами взаимодействия с физическими линиями, формируют канал передачи данных. Последовательность действий, выполняемых для пересылки сообщений, называется коммуникационным протоколом. На конечных узлах он реализуется программными компонентами операционной системы и аппаратными средствами сетевого адаптера. Например, преобразование сообщения в машинно-независимое представление, формирование из сообщения протокольных блоков данных, определение пути их передачи выполняются операционной системой, а фрагментация (при необходимости) и сборка сообщений, вычисление и проверка контрольных признаков целостности пакетов, их преобразование в физические сигналы, ряд других 19 вычислительно затратных операций выполняются аппаратными средствами сетевого адаптера. Следует отметить, что передача всё большего числа операций коммуникационного протокола сетевому адаптеру является одним из эффективных способов сокращения времени обработки сообщений на конечном узле — важного, а для системных сетей — критического, фактора производительности сетевого соединения. Конечные узлы ответственны за надежность доставки сообщений в том смысле, что приложение должно получать все адресованные ему сообщения, и они не содержат ошибок. Для этого конечные узлы должны: − уметь восстанавливать искаженные и потерянные пакеты, − не допускать отправки пакетов с интенсивностью, превышающей возможность приёмного узла их обрабатывать. Первая задача решается посредством расчета передатчиком и проверки приёмником контрольных признаков целостности пакета, с последующим, если необходимо, запросом к передающей стороне о повторной его пересылке. Наряду с этим, могут применяться и специальные методы кодирования, позволяющие исправлять ошибки в пакете непосредственно в месте приёма. Вторая задача – это задача управления потоками. При чрезмерно высокой интенсивности поступления пакетов приёмник вынужден уничтожать избыточную их часть; в этих условиях механизмы повторной передачи положение не спасают. Единственный способ борьбы с этим явлением — это установление обратной связи с передающим приложением и генерация сигналов перегрузки. Принципиально возможны два механизма управления. Первый — генерировать сигнал переполнения приёмного буфера посредством отправки передатчику специального сообщения с указанием остановить генерацию пакетов, а после освобождения буфера приёмника – сообщения, разрешающее возобновить передачу (механизм Xon/Xoff). Основным достоинством этого способа управления является относительно малый объём порождаемого служебного трафика, а основным 20 недостатком — сложность определения пороговых значений заполнения приёмного буфера. Второй способ регулирования интенсивности потока заключается в информировании передающей стороны об объеме свободного буферного пространства приёмника; располагая этими данными, передающее приложение не отправит данных больше, чем их может обработать приёмник. Реализуется эта идея посредством специального счетчика на передающей стороне, начальное значение которого устанавливается равным объёму буферного пространства приёмника (естественно, эти сведения передатчиком должны быть предварительно получены от приемного узла). Передатчик уменьшает значение этого счётчика при отправке каждого пакета, а приёмник, обработав пакет и передав его приложению, вновь информирует передатчик о пространства. Очевидно, что кредитного механизма текущем этот объёме алгоритм, регулирования свободного получивший (credit-based flow буферного название control), предупреждает перегрузку приёмного буфера в принципе, но порождает больший (в сравнении с методом Xon/Xoff) объём служебного трафика. Для сетей на кристалле и системных сетей кредитный механизм регулирования является более предпочтительным в силу его способности минимизировать задержки транспортировки пакетов, в то время как в локальных и глобальных сетях применяются оба механизма в различных их сочетаниях. Кроме рассмотренных задач (восстановление испорченных и потерянных пакетов, управление потоками) коммуникационные протоколы на конечных узлах выполняют трансформацию сообщений из машинно-зависимого представления в абстрактное и обратно, определяют принадлежность пакетов определенным приложениям, предпринимают меры к повышению защищённости сообщений. 1.3. Функции сетевой инфраструктуры Когда десятки, сотни и тысячи конечных узлов объединяются в сеть, организовать прямые физические связи каждого с каждым крайне сложно технически и совершенно неприемлемо экономически. Следовательно, сеть 21 должна располагать возможностями коммутации сообщений (составляющих их пакетов) между любыми парами своих конечных узлов в условиях неполносвязной топологии. Способ, каким это обеспечивается, существенно зависит топологии сети. Формально, она описывается графом, вершины которого соответствуют конечным узлам и портам коммутационных устройств, а рёбра отражают физические или информационные связи между ними. Задание топологии сети позволяет ответить на вопрос: "Какие пути существуют между любой парой конечных узлов?" При наличии определенного множества возможных путей между парой узлов актуальным становится вопрос: "Какие из возможных путей допустимы?". Ответ на него требует наличия механизма выбора одного из возможных путей, удовлетворяющего каким–то дополнительным ограничениям. Это и является сутью задачи маршрутизации. В зависимости от топологии сети и ряда других факторов эта задача может решаться целиком на узле-источнике и определять последовательности адресов узлов коммутации на всём пути к узлу назначения; она может решаться и на каждом отдельном устройстве коммутации в смысле определения следующего узла коммутации, на который следует отправить пакет. Поскольку пути между разными парами конечных устройств могут частично, а иногда и полностью, совпадать, то совершенно реальной становится ситуация, когда пакеты разных пар станций одновременно будут нуждаться в доступе к каналам связи, формирующим совпадающие фрагменты пути. Одновременная передача сигналов (пакетов) разных станций в общем канале невозможна. Следовательно, необходим механизм арбитража запросов доступа к общему ресурсу. Здесь же возникает вопрос о судьбе «проигравшего» пакета (пакетов). Очевидное решение – его временная буферизация – ставит проблему управления потоками внутри сети. Пакет, получивший право использования требуемого канала, должен быть размещен в соответствующем выходном буфере устройства, и 22 преобразован в физический сигнал. Это копирование пакета из входного буфера в выходной буфер требуемого порта устройства и составляет задачу коммутации. Её решение в отношении продвижения каждого пакета на каждом парциальном участке маршрута, является содержанием технологии коммутации пакетов. Вместе с этим, в определенных ситуациях требуется согласованное выделение ресурсов группы каналов, формирующих полный путь между парой конечных станций, для передачи всех пакетов конкретного потока; в этом случае задача решается методами технологии коммутации каналов. Решение задачи арбитража и маршрутизации существенным образом зависит от характеристик «совместно используемого ресурса» и топологии сети. Пусть, например, таким ресурсом является физическая среда передачи сигналов. В некоторых классах сетей все конечные узлы непосредственно подключаются к общей среде передачи (рис. 1.5), а процедуры централизованного или распределенного арбитража предоставляют узлам право временного её использования. С ростом числа конечных станций и диаметра сети эффективность распределенного арбитража уменьшается, следовательно, растет вероятность «порчи» пакетов и необходимости их повторной передачи. В свою очередь, централизованный арбитраж при большом числе конечных станций порождает высокий уровень служебного трафика и создает единую точку отказа. Очевидно, что производительность сети будет падать при обоих способах арбитража и он становится фактором ограничения масштабируемости сети. Ст.2 Ст.1 Ст.2 Ст.1 Ст.N Ст.3 а) б) Ст.N Рисунок 1.5. Сети с общей физической средой передачи 23 Задача маршрутизации в таких сетях практически снимается - каждая станция получает все пакеты (среда общая) и самостоятельно решает вопрос о необходимости их дальнейшей обработки. Но в этом есть и очевидный недостаток - все станции тратят свои ресурсы на обработку ненужных им пакетов. Очевидно, что такой способ организации сетевой инфраструктуры может быть использован только при малом числе конечных узлов и в сетях небольшого диаметра (OCN и LAN). В современных условиях он используется только в беспроводных локальных сетях. Таким образом, именно решения задачи арбитража ограничивают область использования этой, привлекательной своей простотой, сетевой архитектуры. Дополнение сетевой инфраструктуры устройствами коммутации (рис. 1.6), позволяющими одновременно связать любые непересекающиеся пары своих портов, радикально увеличивает не только производительность сети, но и возможности её масштабирования. УК2 УКn Ст. 1 узел коммутации Ст. 2 УК1 УКk линия связи Сеть передачи данных Коммутационная фабрика Ст. 3 Ст. n Ст. k Рисунок 1.6. Структура коммутируемой сети передачи данных Наличие в коммутируемой сети нескольких путей между конечными узлами требует эффективных алгоритмов маршрутизации и не снимает проблему арбитража запросов к ресурсам физических линий. Определенная регулярность межузловых соединений позволяет решать эти задачи более эффективно (за меньшее время). 24 Таким образом, задачи маршрутизации, арбитража и коммутации дополняют перечень рассмотренных применительно к конечным узлам «забот» коммутационного протокола. Их решения зависят от класса сетей и их топологии, но содержат также много общих идей. 1.4. Показатели эффективности сети Выбор критериев эффективности функционирования сети определяется прежде всего её функциональным назначением. В одном случае таким показателем может быть объем данных, которые могут быть надёжно переданы приложениями конечных узлов, в других случаях – уровень потерь пакетов, в третьих – задержка доставки сообщений, в четвертых – степень равномерности загрузки связных каналов и т. д. Для оценки достоинств собственно сетевой технологии существуют два очевидных показателя эффективности – задержка доставки сообщений между конечными станциями и производительность в режиме максимальной нагрузки. Для простоты рассмотрим эти показатели применительно к взаимодействию непосредственно связанных конечных станций (рис. 1.3). TProp TTransp TReс THandl Приёмник Время Передатчик Tpr.Send Время TTransm TTotal Рисунок 1.7. Структура сетевой задержки доставки пакетов Диаграмма, компоненты представленная задержки, на рис. возникающие при 1.7, отражает доставке сетью основные одного протокольного блока (пусть, пакета). Некоторые компоненты задержки могут иметь свою внутреннюю структуру, но все указанные на диаграмме составляющие будут актуальны для любых сетей – от коммуникаций внутри чипа, до передачи сообщений в глобальных сетях. Конечно, их величины в 25 разных сетевых структурах будут различными, но их физическая природа и логическая сущность останутся неизменными. Указанные на рис. 1.7 составляющие сетевой задержки доставки пакетов имеют следующее содержание. − T pr.Send – время, затрачиваемое станций и сетевыми узлами на подготовку блока данных к отправке; оно включает время копирования данных из буфера приложения в буфер сетевого интерфейса, время вычисления контрольной суммы, ожидание доступа к каналу, задержки прерываний операционной системы и некоторые другие составляющие. − T Handl – время обработки блока данных приёмниками и доставки его приложению; обычно, этот интервал несколько больше T pr.Send , поскольку может включать, задержки упорядочивания и сборки фрагментированных блоков данных. Отметим, что как T Handl , так и T pr.Send содержат некоторые составляющие, определяемые сетевыми стеками, и относительно небольшие компоненты, зависящие от размера пакета. Для OCN и SAN стековые составляющие меньше, чем для LAN и WAN (как в силу особенностей технологий, так и по причине существенно меньшего числа промежуточных узлов между конечными станциями). − T Transm – время, затрачиваемое на преобразование битов пакета в физические сигналы; определяется размером пакета и скоростью интерфейса (потенциальной пропускной способностью канала). − T Prop – сумма времени распространения электромагнитных колебаний в среде передачи и задержек в сетевом оборудовании (повторители, коммутаторы); при его вычислении необходимо учитывать скорость распространения электромагнитных колебаний в конкретной среде; значение этой составляющей существенно только для глобальных и очень больших локальных сетей. − T Reс – время, затрачиваемое приёмником на преобразование физических сигналов в битовый поток и формирование кадра; можно считать его равным времени T Trans . 26 − T Transp – время транспортировки пакета сетью, т. е. интервал от инжекции в канал первого бита пакета передатчиком, до получения последнего бита пакета приёмником. − T Total – полная сетевая задержка пакета. TTotal = T pr .Send + T prop + TRec + THandl . Для иллюстрации значимости отдельных компонент полной задержки в сетях разных классов, в таблице 1.1 представлены их численные значения, полученные при следующих исходных данных: − размер пакета 1000 байт; − скорость интерфейсов конечных станций – 10 Гбит/с; − T pr .Send = a + 0.05нс / байт, где: а=0 для OSN, а=0.3 мкс для SAN, a=3.0 мкс для LAN и a=30.0 мкс для WAN; − THandl = 1.33a + 0.05нс / байт ; − T prop = l , c = 3 ⋅ 108 м/с, l - расстояние между конечными узлами: 0.66 ⋅ c 0.5 см (OSN), 5м (SAN), 5000 м (LAN), 5000 км (WAN). Таблица 1.1 Сеть OCN SAN LAN WAN T pr .Send T prop TRec = Ttransm THandl TTotal (нс) 50 350 3 050 30 050 (нс) 0.0249 24.9 24 900 24 900 000 (нс) 800 800 800 800 (нс) 50 450 4050 40 050 (мкс) 0,9 1,602 32,76 24 970 Существенный рост времени распространения электромагнитных колебаний в локальных и глобальных сетях повышает вероятность искажения сигнала, что, в свою очередь, вызывает необходимость применения более надежных коммуникационных протоколов, которые затрачивают больше времени на подготовку пакета к отправке и его приём. Также хорошо видно, что составляющая задержки распространения (T Prop ) в 27 системных сетях и сетях на кристалле может не учитываться в сравнении с другими компонентами задержки. Второй важный показатель эффективности сети – производительность при максимальной нагрузке, вычислить, и даже определить, весьма непросто, поскольку общего определения «полезных» данных, переданных через сеть, не существует. В рассмотренном нами модельном примере взаимодействия двух приложений, предполагались отправка запроса на передачу файла, его передача и подтверждения приёма. Сообщения запроса и подтверждения включать в «полезные» данные? Ответ может быть различным, в зависимости от цели исследования. С другой стороны, если приложение имеет много данных, то позволяет ли ему коммуникационный протокол отправлять много блоков подряд? Если позволяет, то может ли использоваться их конвейерная передача? В последнем случае, если T pr.Send < T Transm то передача очередного блока данных может быть начата практически сразу после завершения передачи предыдущего и интервал (T pr.Send ) n+1 может перекрываться с интервалами (T Reс ) n и (T Handl ) n ; тем самым задержка распространения сигнала в линии может быть полностью исключена из времени сетевой задержки. При этом, эффективная производительность сетевого соединения приближается к номинальной. Однако, если T pr.Send > T Transm , то эффективная производительность останется ниже её номинального значения. В конечном итоге, эффективная производительность процесса инжекции пакетов в линию составит Bin = L max[T pr .send , TTransm ] , где L — размер пакета. Необходимо учесть также, что приёмник может иметь время обработки пакетов T Handl больше времени подготовки пакетов к отправке T pr.Send (рис. 1.8). В этом случае может возникнуть переполнение входного буфера, вступит в действие механизм регулирования потоков и эффективность 28 конвейерной передачи будет утеряна. Производительность соединения будет определяться уже выражением Brecept = TProp L max[THandl , TTransm ] . THandl TReс Время Приёмник Tbuf Передатчик Tpr.Send Время TTransm Рисунок 1.8. Необходимости буферизации блоков данных приёмником Учитывая дуплексный взаимодействующих узла, характер максимальная канала, соединяющего агрегированная два эффективная производительность определиться выражением Bch.eff = 2L . max[T pr .Send , THandl , TTransm ] Рисунок 1.9. Эффективная производительность сетевых соединений На рис. 1.9 представлены зависимости Bch.eff ( L) , полученные в условиях рассмотренного выше примера. Хорошо видно, что для сетей на кристалле, в которых время инжекции пакета в линию (T Transm ) всегда больше 29 всех остальных компонент задержки, эффективная производительность канала достигает своего потенциального максимума. Для сетей SAN время обработки пакетов приемником (T Handl ) становится меньше времени T Transm только при L > 600 байт, когда и достигается максимальное значение агрегированной производительности канала. Для сетей LAN и WAN, в которых время обработки пакета (T Handl ) оказывается существенно больше остальных компонент, агрегированная производительность соединения остаётся заметно меньшей её потенциального значения. Этот пример демонстрирует важность принятия мер к сокращению задержек, связанных с подготовкой пакета к отправке и обработки его на приёмном узле. Проведенный выше анализ показывает, что, сформировав модель, которая рассматривает всю сеть из конца в конец как последовательность каналов, можно идентифицировать самый узкий его участок, и определить верхнюю границу эффективной пропускной способности всего сетевого канала. Заключение к разделу 1 Функционирование сетевых приложений требует согласованной работы конечных узлов, на которых они выполняются, и сетевых компонентов (линий связи и узлов коммутации). Это взаимодействие организуется коммуникационным протоколом. Основными задачами конечных узлов, решаемых ими в процессе сетевого взаимодействия, являются: − преобразование сообщений в машинно-независимый формат, − недопущение передачи приложению сообщений, содержащих ошибки, и − управление интенсивностью генерируемых потов сообщений. Сетевые узлы, в свою очередь, решают задачи определения оптимальных путей передачи сообщений, арбитража при конкурентном 30 использовании сетевых ресурсов и продвижения пакетов по определённым маршрутам. Вместе с этим, преобразование сообщений из битового представления в физические сигналы, надёжная их передача, приём сигналов и обратное преобразование в биты – являются задачами, которые выполняются на всех узлах (конечных и сетевых). 2. МОДЕЛЬ МЕЖСЕТЕВОГО ВЗАИМОДЕЙСТВИЯ 2.1. Общие предпосылки разработки Информационный обмен в сетевых системах имеет два принципиальных аспекта: − данные должны быть переданы от одного конечного устройства сети к другому определенному конечному устройству; − принятые данные должны быть верными и распознаваемыми конечным приложением в синтаксическом и семантическом отношениях. Для успешного информационного обмена, в котором участвуют три объекта (два конечных узла и сеть), необходимы чётко определённые правила представления информации и взаимодействия сетевых узлов на всех этапах её обработки. Определение содержания и числа этих этапов формирует определённую модель взаимодействия сетевых приложений. Такая модель строится из иерархически упорядоченных функциональных блоков, выполняющих операции отдельных этапов трансформации информации от сообщения до физического сигнала. Она также включает описание межмодульных потоков (интерфейсов) и правил логического взаимодействия модулей одного уровня, функционирующих на разных сетевых устройствах (протоколов). Их программные реализации становятся модулями операционных систем узлов. Как уже отмечалось выше, вся совокупность этапов сетевого информационного обмена естественно делится на группу задач транспорта данных, в решении которых основную роль играет сеть, и группу процедур 31 распознавания и представления данных, которые решаются только на конечных узлах. Внутри каждой из групп, руководствуясь принципом инженерного компромисса исполняемых процедур. выполняется Выбор более конкретного тонкая числа группировка подгрупп этой классификации (этапов преобразования информации) производится с учётом следующих ограничений: − взаимодействие уровней через их границы должно быть минимизировано; − каждый уровень не должен быть слишком сложным для реализации, и его модификация не должна приводить к необходимости изменения других уровней; − число уровней не должно быть слишком большим, чтобы их интеграция не стала чрезмерно сложной. Ясно, что независимые коллективы разработчиков строили оригинальные информационно-функциональные модели обмена данными в компьютерных сетях. Сетевые операционные системы, создаваемые на базе разных моделей, часто оказывались несовместимыми, что сдерживало развитие отрасли. Относительно удачная попытка нормализовать модель сетевого обмена была реализована в начале 80-х годов ХХ века. 2.2. Эталонная модель взаимодействия открытых систем В 1983 году Международной организацией по стандартизации (МОС, International Standards Organization, и ISO) Международным консультативным комитетом по телекоммуникациям (МККТ, International Telecommunications взаимодействия Union, открытых была ITU) систем принята (модель эталонная ВОС, Open модель Systems Interconnection, OSI). Процесс сетевого информационного обмена в модели ВОС разбит на семь этапов, каждый из которых отражает определенную стадию преобразования информации (рис. 2.1). Каждый этап такого преобразования 32 выполняют программные объекты (модули), которые далее называются N-объектами. Процесс взаимодействия сетевых приложений описывается в формате правил обмена сообщениями между семью парами одноуровневых N-объектов взаимодействующих узлов. Эти правила и являются уровневыми протоколами. Конечный узел А Конечный узел Б Приложение Б Сообщение Прикладной уровень Уровень представлен. Уровень представлен. Сеансовый уровень Сеансовый уровень Транспорт. уровень Транспорт. уровень Сетевой уровень Сетевой уровень Сетевой уровень Сетевой уровень Канальный уровень Канальный уровень Канальный уровень Канальный уровень Физический уровень Физический уровень Физический уровень Физический уровень Физический сигнал Сетевой слой Прикладной уровень Прикладной слой Приложение А Сеть передачи данных Рисунок 2.1. Эталонная модель взаимодействия открытых систем Хотя протокол уровня N описывает взаимодействие двух равноранговых сущностей, модель не предполагает их непосредственного общения, что является отражением объективной реальности, - взаимодействие между сетевыми устройствами осуществляются только посредством физических сигналов, представляющих биты сообщения. Содержание данных, передаваемых от верхнего (N-го) к нижележащему (N-1) уровню, составляют описание интерфейса. Модель не содержит ограничений на способы реализации уровневых протоколов и межуровневых интерфейсов (это дело разработчиков). Но соблюдение разработчиками унифицированных 33 требований к входным данным и выходным реакциям уровневых программных модулей обеспечивает их совместимость вне зависимости от ОС и аппаратных платформ выполнения. Передача данных между сетевыми узлами в модели представлена тремя нижними уровнями, поэтому соответствующие им протоколы и интерфейсы должны поддерживаться каждым конечным и сетевым узлом. Три верхних уровня модели обеспечивают интерпретацию данных, т. е. выполняют преобразования формы представления информации, связанные с особенностями конечных систем, а не с сетью передачи данных; еще один уровень (транспортный) играет исключительно важную роль в обеспечении надежности работы конечных приложений. Все эти четыре уровня реализуются только на конечных станциях. Прикладной уровень включает в себя процедуры, посредством которых приложение формирует «правильный» запрос к определенному сетевому сервису (доступ к информационным ресурсам Интернет, электронная почта, доступ к файлам и т. д.). Блок данных протокола – сообщение. Например, при обращении к удаленному файловому хранилищу прикладной уровень сформирует корректное в синтаксическом отношении сообщение, содержащее адрес и имя требуемого файла, информацию о действии, которое надо выполнить с ним (копировать, создать, удалить, модифицировать) и, при необходимости, информацию, которую надо добавить в файл; процедуры этого уровня обеспечивают проверку прав пользователя в отношении требуемой операции. Уровень представлений определяет преобразование машиннозависимого представления сообщения приложения А в абстрактный синтаксис данных и далее в определенный синтаксис передачи, который предварительно согласуется с одноуровневым модулем на другом узле. Функции этого уровня хорошо иллюстрируются функциями переводчиков между субъектами, ведущими диалог на разных языках, например, на французском и русском, при условии, что единственным общим языком 34 переводчиков является английский. Тогда, французский и русский языки – это локальные машинно-зависимые синтаксисы, английский – синтаксис передачи. При этом должен существовать механизм, посредством которого будет согласовано применение обоими переводчиками английского языка (абстрактный синтаксис). Примером абстрактного синтаксиса является язык ASN.1 (Abstract Syntax Notation One), являющимся стандартом ISO. На этом уровне часто реализуются шифрование данных (протокол Secure Sockets Layer, SSL) и (или) их сжатие. Информационной единицей протокола уровня представлений остается сообщение. Сеансовый уровень объединяет процедуры, повышающие надежность обмена между уровнями представления. В частности, он обеспечивает выбор требуемого режима связи (дуплексный или полудуплексный). Также в него включаются средства расстановки в передаваемом сообщении некоторых контрольных точек, по достижении которых выполняется фиксация состояния процесса передачи-приема; эта информация в случае кратковременного разрыва соединения используется для возобновления выполнения задачи из последнего зафиксированного состояния. Транспортный уровень управляет связью приложений, экранируя их от всех особенностей коммуникационной инфраструктуры. Здесь выполняется адресация приложений, фрагментация сообщений на блоки, размер которых учитывает возможности сети. Здесь же решается задача регулирования приложением. интенсивности Вместе с этим, потоков отвечая сегментов, требованиям генерируемых приложения, транспортный уровень может организовать несколько соединений для обслуживания его потоков. Транспортный уровень модели ВОС предусматривает два режима передачи данных – с предварительным установлением соединения и без установления соединения. Первый из них используется для обеспечения сервиса виртуального канала (надёжная доставка данных в правильной их 35 последовательности и управление передачей из конца в конец). Режим передачи без предварительного установления соединения обеспечивает сервис ненадежной доставки (без восстановления потерянных и испорченных сегментов). Такой сервис используется, главным образом, для передачи отдельных коротких сообщений, а задачи транспортного уровня в этом случае сокращаются до корректной адресации приложений. Уровни «сетевой» группы модели обеспечивают «прозрачность» общения транспортных объектов взаимодействующих конечных устройств при любой, сколь угодно сложной, коммуникационной среде. Функции трех нижних уровней реализуются всеми узлами сети. Верхним в этом блоке модели является уровень межсетевого взаимодействия, который предоставляет услугу связи транспортному уровню. Протокол этого уровня решает задачи логической группировки конечных узлов в адресуемые сообщества (сети), логической адресации всех узлов, выбора маршрута между расположенными в разных сетях конечными узлами и, при необходимости, сегментации блоков данных транспортного протокола. Информационной единицей межсетевого протокола является пакет. На сетевом уровне также реализуются некоторые функции обнаружения ошибок, а при предварительное реализации установление в сети служб, соединения, и ориентированных функции на создания виртуального канала. На сетевом уровне могут быть также реализованы механизмы предупреждения перегрузок коммутирующих устройств и механизмы обеспечения заданных параметров качества обслуживания (пропускная способность, задержка передачи, уровень ошибок). Под сетевым уровнем находится уровень канала передачи, который предоставляет услугу безошибочной передачи блоков данных (кадров) между сетевыми устройствами, непосредственно связанными физической линией. Содержание этой услуги для глобальных и локальных сетей несколько различаются. В глобальных сетях главной заботой канальных протоколов является надежность передачи данных (обнаружение ошибок и повторная 36 передача); примером такой процедуры является протокол HDLC – High-level Data Link Control Protocol. В локальной сети, как правило, имеется высоконадежная физическая инфраструктура связи и вероятность битовых ошибок заметно меньше. Поэтому канальные протоколы обязательно фиксируют ошибки, но не занимаются их исправлением, что упрощает их реализацию и уменьшает задержки передачи. Физический уровень решает задачу формирования из кадров канального уровня битовой последовательности { X i } (символы, блоки), обладающей требуемыми свойствами помехозащищенности, преобразование её в физические сигналы S(t), передачу их в среду, соединяющую взаимодействующие сетевые устройства, и обратное преобразование сигналов S(t) в последовательность битов { Yi }. Физической средой передачи могут быть медный коаксиальный или многопроводный кабель, волоконнооптическая линия, открытое пространство. Преобразования { X i }→ S(t) и S(t) → { Yi } реализуются модемами или цифровыми контроллерами сопряжения, которые в совокупности с физической средой передачи образуют дискретный канал связи (рис. 2.2). ζ (t ) {X i } М/К S(t) Физическая среда передачи М/К { Yi } Дискретный канал связи Рисунок 2.2. Структура дискретного канала связи Последовательность { Yi }, в общем случае, может отличаться от исходной последовательности { X i } в силу свойств физического канала и воздействия помехи ζ (t ) на сигнал S(t). Помехозащищенность дискретного канала определяется только потенциальной помехоустойчивостью используемых методов кодирования и модуляции. Физический уровень в модели ВОС освобожден от решения задачи обнаружения и исправления 37 искаженных бит. Им определяются метод кодирования битового потока, характеристики физических сигналов, типы разъемов и т.п. Он также выполняет диагностику определенного класса неисправностей (обрыв провода, отключение питания, потеря контакта и т.п.). Информация об этих неисправностях используется приложениями мониторинга состояния канала для принятия мер, устраняющих последствия нарушений, и канальным уровнем для организации повторной передачи кадра, если она предусмотрена протоколом. 2.3. Абстрактная модель межуровневого взаимодействия Модель ВОС определила не только содержание услуг каждого уровня, но и характер их взаимодействия, а именно - уровень N обязан предоставлять полный набор услуг, необходимых для связи объектов уровня (N+1). Поэтому вышестоящий уровень называют пользователем N–услуги, а нижестоящий – её поставщиком. При этом, реализация N–услуги является задачей N–объекта и ее пользователь (уровень N+1) ничего об этой реализации «не знает». Концепция взаимодействия уровней по схеме «Поставщик- пользователь» представлена на рис. 2.3. Наличие двух объектов уровня N+1 на узле А может отражать, например, выполнение на нём двух независимых прикладных процессов. Доступ к услуге каждого уровня осуществляется через программный порт, называемый точкой доступа к N–услуге (N-SAP). У каждой точки доступа есть адрес, однозначно её идентифицирующий. Каждый объект (N+1) уровня должен иметь «свою» N-SAP. В приведенном на рис. 2.3. примере уровень N предоставил для каждого (N+1)–объекта отдельную точку доступа к своим услугам. В общем случае, межуровневое взаимодействие может выполняться по схемам «один к одному», «один ко многим» и «многие к одному». Обмен данными между одноуровневыми объектами взаимодействующих узлов управляется протоколами этого уровня. Но этот обмен данными является только логически непосредственным, физически же 38 он выполняется в форме последовательной передачи протокольных блоков данных от уровня N к уровню N-1 одного узла. Узел Б Узел А Уровень N+1 (N+1) объект_1 (N+1) объект_2 (N+1) объект_2 Протоколы уровня (N+1) N–SAP N–SAP Уровень N N–объект N–объект Протоколы уровня N (N-1)–SAP (N-1)–SAP Уровень N-1 (N+1) объект_1 (N-1)–объект Протоколы уровня N-1 (N-1)–объект Рисунок 2.3. Абстрактная модель взаимосвязи уровней Блок данных протокола уровня N+1, поступая на уровень N становится для него блоком данных услуги (БДУ–N). БДП–N содержит часть или весь БДП N+1 уровня и управляющую информацию (заголовок), добавляемую протоколом уровня N (рис. 2.4). Уровень N+1 БДП-N+1 N-SAP Уровень N УИП-N_1 БДУ-N_1 БДУ-N_2 БДП-N_1 УИП-N_2 БДП-N_2 Рисунок 2.4. Модель формирования блоков данных уровневых протоколов 39 В общем случае, услуга уровня N включает в себя прием блока данных от уровня N+1 узла А, его фрагментацию (при необходимости), включение в заголовки фрагментов сведений, содержащих необходимые указания по их обработке, передачу результирующего блока данных N-объекту узла Б, проверку признаков целостности принятого блока и доставку его поля данных указанному в заголовке объекту уровня N+1. Эти операции могут реализовываться с предварительным установлением соединения между точками доступа к N–услугам, или без такового. В первом случае протокол N–уровня решает три задачи. 1. Установление соединения между точками доступа к N–услуге (N-SAP) взаимодействующих объектов, что означает согласование N–объектами узлов параметров будущей передачи (допустимые величины протокольных блоков, начальные значения их нумерации, используемые механизмы управления потоком, и т.п.). Всё это приводит к выделению определённых ресурсов узла, обслуживающих данное соединение. 2. Передача блоков N-протокола взаимодействующему равноуровневому объекту. 3. Ликвидация соединения и освобождение всех зарезервированных для него ресурсов. Услуга без предварительного установления соединения содержит лишь второй из перечисленных выше этапов; вся управляющая информация, необходимая для передачи блоков данных между N–сущностями, должна быть получена от уровня N+1. Еще одной характеристикой N–услуги передачи данных является её подтверждаемость. В этом отношении возможны два варианта: − подтверждаемый сервис (confirmed service): объект–получатель подтверждает каждый или группу полученных блоков данных; − неподтверждаемый сервис (unconfirmed service): поставщик услуги не получает подтверждений о переданных блоках данных. 40 Обычно, сервис N–уровня предоставляется в форматах надежной передачи (с установлением соединения и подтверждениями) и/или, передачи «как получится», без установления соединения и без подтверждений, часто называемой, дайтаграмным сервисом. Два других возможных варианта реализации N–услуг используются редко. В заключение отметим, что модель ВОС, выполнив важную задачу описания основных этапов сетевого взаимодействия, не стала концептуальной моделью построения сетей передачи данных и не получила ожидаемого практического воплощения. Она была реализована лишь единожды в стеке протоколов ВОС (не путать с моделью ВОС). На физическом и канальном уровнях этот стек включает спецификации протоколов известных локальных сетей Ethernet, Token Ring, FDDI, 100 VG AnyLAN, а также глобальных сетей ISDN, PSDN, PSTN, т. е. использует все популярные канальные протоколы. Уровень межсетевого взаимодействия в стеке представлен оригинальными протоколами Connection-oriented Network Protocol (CONP) и Connectionless Network Protocol (CLNP). В других стеках они не используются. Более удачными оказались протоколы маршрутизации ES–IS (End System – Intermediate System) и IS–IS (Intermediate System – Intermediate System). Наиболее удачными протоколами стека стали прикладные протоколы ISO 8571 (File Transfer Access and Management, FTAM), ISO 9040 (Virtual Terminal), Х.500 (Directory Services), X.400 (Message Handling Services) и ряд других. Полностью стек ВОС был реализован в компьютерных сетях правительственных учреждений США и Великобритании. Однако, дальнейшего распространения он не получил в силу сложности и неоднозначности его описаний. Модель сетевого взаимодействия в Интернет (модель TCP/IP) содержит четыре уровня, из которых достаточно полно описаны только три: прикладной, транспортный и межсетевого взаимодействия. Четвертый уровень, лишь определен как уровень, способный передавать IP пакеты от узла к узлу и по своим функциям он соответствует канальному и 41 физическому уровням в модели ВОС. Ещё одной особенностью этой модели являлся только дейтаграммный режим предоставления сервисов сетевого уровня, т. е. отсутствие всяких гарантий безошибочной доставки пакетов. Однако, несмотря на эти «слабости» модели, протокольный стек TCP/IP получил всеобщее признание и стал стандартом де-факто для сетей самых разных масштабов. Вероятно, это произошло в силу его гибкости и хорошо продуманных механизмов межсетевого взаимодействия. Что касается модели стека, то изначально она накладывала лишь самые общие ограничения на уровневые сервисы; её оформление шло параллельно с разработкой соответствующих протоколов и учитывало опыт их внедрения. Для образовательных целей более естественной является пятиуровневая модель, в которой явно выделены физический и канальный уровни, а функции уровней представления и сеансового считаются «заботой» прикладного протокола и приложения. Такой подход к изложению принципов функционирования компьютерных сетей стал общепринятым [1, 2] и в настоящем пособии автор также следуют ему. 2.4. Типичные требования сетевых приложений Для эффективного взаимодействия сетевых приложений необходимы механизмы адаптации их требований к возможностям сетевой среды. Наиболее типичными требованиями приложений при этом являются: − отсутствие ограничений объема передаваемой информации, − надежная и эффективная адресация узлов и приложений, − отсутствие ошибок в получаемых блоках данных и правильная их последовательность. Выполнение этих требований обеспечивается уровневыми протоколами. Первое из требований относительно просто выполняется посредством разбиения больших информационных единиц (сообщений) на блоки приемлемого размера. В целом, процедуры сегментации и сборки являются 42 типичными адаптационными процедурами и выполняются протоколами разных уровней, как правило, транспортными и межсетевыми. Вся система сетевой адресации должна строиться во имя однозначной идентификации конкретного приложения, работающего на конкретном сетевом узле. Для этого на каждом уровне модели сетевого взаимодействия необходимо однозначно адресовать пары взаимодействующих модулей. При этом, система адресации должна учитывать необходимость масштабирования сетей (размер адресного пространства), возможности их объединений (проблема уникальности адресов) и реализации эффективного механизма поиска устройства (приложения) среди множества им подобных. Для придания уровневым протоколам свойств безошибочной доставки блоков данных используются специальные средства обнаружения ошибок (контрольные суммы в заголовках пакетов, недопустимые кодовые комбинации) и их коррекции (автоматическая повторная передача, коды с исправлением ошибок). Еще одним нетривиальным вопросом является схема реализации функций адаптации. В принципе, возможны две базисные схемы, а именно, «из конца в конец» (рис. 2.5.а) и «от узла к узлу» (рис. 2.5.б). Ст–А Ст–Б АСК – положительное подтверждение о приеме АСК / NAК а) NАК – отрицательное уведомление о приеме УК 1 Ст–А УК 3 УК 2 Ст–Б АСК / NAК б) Данные УК 1 АСК/NАК Данные УК 2 АСК/NАК УК 3 Рисунок 2.5. Схемы реализации функций адаптации: а) «из конца в конец», б) «от узла к узлу» 43 Первая из этих схем, очевидно, выигрывает в смысле сложности сети передачи данных, коммуникационного а вторая тракта, обеспечивает поскольку большую корректирует надежность ошибки и «отрабатывает» перегрузки непосредственно в местах их возникновения. Вместе с тем, вторая схема не гарантирует безошибочную передачу, поскольку не располагает механизмом выявления ошибок, возникающих собственно в узлах коммутации. Выбор той или иной схемы, или их комбинации, всегда является результатом учета требований приложений и характеристик сети. Примером реализации схемы «из конца в конец» является транспортный протокол ТСР, а схема «от узла к узлу» нашла своё место в канальном протоколе HDLC. Заключение к разделу 2 Разработка сетевых приложений требует принятия определенной модели взаимодействия конечных узлов с сетью и сетевых узлов коммутации трафика между собой. Следование общей модели такого взаимодействия является залогом совместимости создаваемых приложений. Модель взаимодействия открытых систем (модель ВОС) определила одну из возможных иерархий процедур межсетевого взаимодействия. Её достоинство заключено в полноте описания содержания услуг каждого уровня иерархии и их взаимодействия. В этой модели уровень N обязан предоставлять полный набор услуг, необходимых для связи объектов уровня N+1 взаимодействующих узлов. При этом, уровень N предоставляет свои услуги, выполняя определённые действия внутри себя и используя услуги, предоставляемые ему уровнем N-1. Модель исключает необходимость взаимодействия процедур уровня N с процедурами уровней N-2, N-3 и т.д. Так как каждый уровень N предлагает вполне определённые услуги, то изменение его реализации не затрагивает всю остальную систему. Для больших сложных систем способность изменять реализацию отдельных сервисов, не затрагивая функциональность системы и реализацию всех 44 остальных её компонент, является одним из важнейших свойств, обеспечивающих возможность её модернизации и обновления. Основная ценность модели ВОС заключена в скрупулёзном описании набора услуг каждого уровня, обеспечивающих потребности любых приложений. Эта универсальность модели, чрезвычайно полезная в образовательном и системном аспектах, ограничила возможности её практической реализации в стеках действующих протоколов. Модель Интернет (стек TCP/IP) в части функций транспортного и, частично, межсетевого уровней хорошо согласуется с моделью ВОС; прикладной уровень TCP/IP интегрирует три верхних уровня модели ВОС, а механизмы межуровневых взаимодействиях допускают большую гибкость. Контрольные вопросы 1. Какой из уровней в модели ВОС ответственен за: a. определение маршрута передачи пакетов? b. надежную передачу данных между конечными узлами? c. надежную передачу данных между узлами на маршруте? 2. Что представляют собой адреса SAP в сети радиовещания? 3. Каково содержание процедуры установления соединения? 4. Сервис установления соединения является подтверждаемым, или нет? 5. Необходим ли канальный уровень в стеке протоколов, если физический канал является абсолютно надежным (не вносит ошибок)? 6. Почему процедуры транспортного уровня не реализуются в узлах межсетевой коммутации? 7. Можно ли надежную передачу реализовать в дейтаграммной сети? 45 4. АДАПТАЦИОННЫЕ ПРОЦЕДУРЫ УРОВНЕВЫХ ПРОТОКОЛОВ Наиболее общими требованиями, выполнение которых необходимо для корректной работы сетевых приложений, являются: − надежная и эффективная адресация сетевых устройств и приложений, − отсутствие ограничений объема передаваемой информации, − безошибочность передачи и отсутствие нарушений последовательности доставки отдельных составляющих информационного сообщения; − приемлемый уровень задержки доставки сообщений и его отдельных составляющих. Для удовлетворения этих требований приложений сетевые протоколы практически всех уровней стека выполняют определенные адаптационные процедуры. Основными среди них являются: − сегментирование информационных сообщений (формирование блоков данных протокола, БДП), − назначение оригинальных адресов сетевым устройствам и приложениям, − обнаружение ошибок в принимаемых блоках данных, − обработка принятых с ошибками блоков данных, − управление интенсивностью потоков данных (управление источником). 4.1. Формирование блоков данных протокола Формирование блоков данных (кадров, пакетов, сегментов) является уровнезависимой операцией, поскольку форматы заголовков, содержание их полей, предельные размеры блоков данных и т. п., существенно зависят от уровневого протокола. При всем многообразии структур протокольных блоков обязательными элементами процедуры их создания являются: − задание границ протокольного блока, − формирование протокольного заголовка, управляющую и контрольную информацию. 164 содержащего адресную, Задание границ имеет особую важность в отношении блоков данных канального уровня (кадров). Действительно, кадр является первой логически структурированной единицей сообщения, восстанавливаемой приёмником узла из последовательности физических сигналов. Поэтому его границы должны быть надёжно определяемыми. Блоки данных протоколов всех остальных вышестоящих N+1 уровней легко формируются посредством исключения заголовков блоков N–го уровня, размер которых априорно известен или указан в этом заголовке. Соответственно, необходимы специальные признаки границ кадров. Существуют несколько методов их задания. Метод стартстопных последовательностей с символьным заполнением применялся для формирования кадров при передаче текстовой информации; после небольшой модификации он был распространён и на кадры информации произвольного типа. Этот метод предусматривает обрамление протокольного блока двумя парами специальных символов кодовой таблицы ASCII (American Standard Code for Information Interchange). Для обозначения начала блока использовалась комбинация символов DLE (Dana Link Escape, x10) + STX (Start of TeXt, x02) и для признака окончания кадра – DLE + ETX (End of TeXt, x03). Заметим, что символ DLE указывает на то, что следующий за ним символ не является текстом, а имеет специальный управляющий смысл. При таком обозначении границ потеря одного из кадров не вызывает нарушения кадровой синхронизации пары «передатчик–приемник», поскольку достаточно обнаружить в битовом потоке следующую пару разделительных символов и синхронизация будет восстановлена. При передаче текстовой информации такой принцип формирования ограничителей вполне надежен (символы начала и окончания блока оригинальны, в передаваемом тексте они встретиться не могут). Однако, использование этого метода для формирования кадров информационного потока произвольной природы (исполняемые файлы приложений, например) может привести к ошибкам в определении границ 165 блоков данных, поскольку вероятность появления в произвольном информационном битовом потоке последовательности, соответствующей символу отлична DLE, интерпретации такой от нуля. комбинации Для бит, предотвращения перед нею неверной передатчиком осуществляется вставка еще одного символа DLE (отсюда и название метода «…с символьным заполнением»). Очевидно, что вероятность появления в информационной последовательности комбинации бит, соответствующей двум подряд идущим символам DLE, исчезающе мала. Приемное устройство устраняет один символ DLE из каждой их пары, обнаруженной в принятом битовом потоке (рис. 4.1), а последующие символы интерпретирует как последовательность данных. С P DLE A С P DLE DLE A A …… …… Кадр DLE STX С P DLE Данные пакета передающего узла …… DLE ETX Данные пакета приёмного узла Рисунок 4.1. Определение границ блока данных посредством стартстопных последовательностей с символьным заполнением Основным недостатком этого метода разметки кадров является его тесная связь с вполне определённым методом кодирования информационных символов (таблицей ASCII). Поскольку входной поток обрабатывается побайтно (для простоты будем считать, что каждый символ — это байт), то при передаче несимвольной информации требуется выравнивание протокольного блока данных на границу байта, т.е. вставка передатчиком и исключение приемником дополнительных бит. Это увеличивает накладные расходы протокола, усложняет процедуру приема и ограничивает возможности передачи трафика произвольной природы. Метод стартстопных последовательностей с битовым заполнением в качестве указателя начала и конца блока использует определённую 166 последовательность, например, {0,1,1,1,1,1,1,0}. Выбор таких последовательностей определяется двумя требованиями: малой вероятностью их появления в информационных данных и возможностью их использования для подстройки частоты тактового генератора приёмника. При этом, всегда предпринимаются меры к 100% исключению появления граничных флагов в информационном потоке. Так, оригинальность приведенной выше последовательности обеспечивается вставкой «0» после пяти единиц подряд, появляющихся в информационном потоке. Соответственно, приемник исключает каждый нуль, следующий после пяти единиц. Очевидно, что при таком способе формирования блока данных, его размер не обязательно должен быть кратен байту и число «дополнительных» бит оказывается меньшим в сравнении с символьным заполнением (меньше «накладные расходы» процедуры). Для определения конца кадра используется либо такая же флаговая последовательность, либо передача специальных символов отсутствия информации (idle–символы), либо отсутствие физического сигнала на входе приёмника в течение интервала времени, большем определённого порога. В последнем случае, окончание кадра может фиксироваться и на основании информации о его размере, содержащейся в одном из полей заголовка. Метод специальных символов логического кодирования может быть просто реализован в случае, когда число возможных состояний кодера передатчика больше, чем необходимо для создания алфавита передачи. Например, помехоустойчивое логическое кодирование по схеме 4B/5B каждые четыре информационных бита представляет 5-ти битовым словом. При этом, для передачи любой из шестнадцати возможных четырёхбитовых комбинаций, требуется использовать шестнадцать из тридцати двух возможных пятибитовых комбинаций, а из оставшихся шестнадцати можно выбрать две для индикации начала и конца кадра. По существу, это вариант стартстопной последовательности, но без вставки битов в информационный поток, что несколько упрощает процедуру приема. 167 4.2. Обнаружение ошибок Достоверность передачи данных обеспечивается, как минимум, двумя адаптационными процедурами. Первая из них – обнаружение ошибок и вторая – обработка блоков данных с ошибками. Обнаружение ошибок, очевидно, возможно лишь в случае конечности величины блока данных и наличия в нём информации (признака), не очень трудоемкий анализ которой может дать основание для принятия решения о наличии/отсутствии ошибок. В отношении блока данных, содержащего ошибку, возможны три решения. Первое из них обязывает приемник уничтожить его. Второе – требует уничтожить ошибочный блок и выполнить запрос его повторной передачи (метод Automatic Retransmission reQuest, ARQ). Такое решение предполагает наличие обратного канала, по которому передающему хосту может быть доставлен указанный запрос. Метод ARQ широко используется протоколами компьютерных сетей. Третье решение, в отличие от ARQ, предполагает коррекцию выявленных ошибок на месте, что требует большего объема избыточной информации, включаемой в передаваемый блок данных, и дополнительных вычислительных ресурсов приёмника. Этот метод (Forward Error Correction, FEC) предпочтительнее, когда организация обратного канала оказывается затруднительной (симплексный режим связи), либо в случае, когда повторная передача испорченных блоков не имеет смысла (например, при передаче видео реального времени). Некоторые коммуникационные протоколы применяют оба метода. Отметим принципиальные отличия этих методов исправления ошибок: ARQ тратит пропускную способность канала на передачу запросов повторной передачи и собственно повторную передачу кадра, а FEC вносит большую, в сравнении с ARQ, избыточность в передаваемый кадр и требует больших вычислительных затрат для обработки информационных блоков. 168 4.2.1. Модель механизма обнаружения ошибок В любом коммуникационном цифровом канале существует отличная от нуля вероятность искажения битов. Например, типичный уровень битовых ошибок в физической среде передачи, колеблется от 10-11 (волоконнооптический кабель) до 10-3 (радиоканал). Приемлемость того или иного уровня ошибок, равно как и степень надежности их обнаружения, определяются требованиями приложения. Так, аудио- и видеоприложения весьма терпимы к единичным и даже групповым битовым ошибкам, в то время, как системы электронных платежей (банкомат, например) и служба передачи файлов требуют абсолютной безошибочности. Основная иллюстрируется генерируемый идея рис. детектирования Прежде 4.2. приложением, должен ошибки всего, быть весьма проста информационный разбит на и поток, относительно небольшие порции (кадры, пакеты, сегменты), поскольку обнаружение ошибок в бесконечной (очень большой) последовательности либо невозможно, либо будет чрезмерно трудоёмко. Способы такого разбиения были рассмотрены выше. Информационный блок, k бит Кодер Кодовое слово, n бит, n > k Принятое кодовое слово, n бит Условие выполнено? Канал Нет Кодовые слова на входе канала удовлетворяют определенному «условию» Да Декодер Информационный блок, k бит сообщение об ошибке Рисунок 4.2. Обобщенная модель механизма обнаружения ошибок Информационный блок данных, размером k бит, используется как аргумент некоторой функции F 1 . Значение этой функции является n-битным словом (n > k) и удовлетворяет вполне определенному условию. По принятому массиву из n бит вычисляется проверочная функция F 2 и её 169 значение сравнивается с множеством допустимых её значений. Результат такого сравнения позволяет, с определенной степенью достоверности, зафиксировать наличие, или отсутствие ошибок в принятом блоке данных. Таким образом, принципиальным условием обнаружения ошибки является предварительное помехоустойчивое кодирование протокольного блока данных, т. е. придание ему свойств, позволяющих с высокой вероятностью обнаружить факт его искажения. Очевидно, что k бит информационного потока могут представлять один из 2k информационных блоков (информационных слов) и все они – равновероятны. кодирования После выполнения информационного слова операции число бит помехоустойчивого в кодовом слове увеличивается до n. Кодер должен быть построен так, чтобы не все 2n кодовых слов были возможны, т.е. должны существовать «запрещенные» n-битовые кодовые слова, вероятность появления которых при кодировании любых информационных слов равна нулю. Зная алгоритм кодирования, всегда можно составить перечень таких «запрещенных» кодовых слов и указать правило их обнаружения. Тогда, появление «запрещенных» кодовых слов на приемной стороне канала будет свидетельствовать о наличии ошибки в принятом блоке. Вместе с тем, ошибки в канале могут так преобразовать исходное кодовое слово, что оно превратится в другое допустимое слово. Метод кодирования должен минимизировать вероятность такого события. Каждый алгоритм кодирования расстоянием, измеряемым характеризуется минимальным минимальным числом битов, кодовым поразрядно отличающих одно допустимое кодовое слово от другого. Пусть эта величина равна d. Тогда ошибка на приемном конце канала может быть обнаружена, если в принятом кодовом слове окажутся инвертированными не более (d-1) бит. Более того, используя критерий минимума расстояния между принятым кодовым словом и множеством допустимых слов, можно исправлять ошибочные кодовые слова. Последнее будет иметь успех лишь при 170 искажении менее d/2 бит. Например, пусть допустимыми кодовыми словами являются: 00000 00000, 00000 11111, 11111 00000, 11111 11111. В этом случае минимальное кодовое расстояние между ними d=5. Кодовые слова, с искаженными двумя битами, могут быть интерпретированы верно по критерию близости их к допустимым. Пусть передается слово 00000 11111, а принимается A=01000 11011. Расстояния между ним и допустимыми кодовыми словами, измеренные числом единичных битов в суммах этих слов по модулю 2 без переноса, будут равны: A − A1 = N1 (01000 11011 ⊕ 00000 00000) = N1 (01000 11011) = 5 , A − A2 = N1 (01000 11011 ⊕ 00000 11111) = N1 (01000 00100) = 2 , A − A3 = N1 (01000 11011 ⊕ 11111 00000) = N1 (10111 11011) = 8 , A − A4 = N1 (01000 11011 ⊕ 11111 11111) = N1 (10111 00100) = 5 . Таким образом, принятое кодовое слово должно быть интерпретировано как 00000 11111, и ошибка исправлена. Вместе с тем, наличие в слове 00000 11111 трех, т.е. более d 2 , ошибок (принимается, например, слово А=00000 11000) даст: A − A1 = N1 (00000 11000) = 2 , A − A2 = N1 (00000 00111) = 3 , A − A3 = N1 (11111 11000) = 7 , A − A4 = N1 (11111 00111) = 8 . Такое слово будет ошибочно интерпретировано как 00000 00000, т.е. исправление ошибки оказывается невозможным. Далее будут рассмотрены несколько методов обнаружения ошибок и дана оценка их эффективности. 4.2.2. Методы расчёта контрольных признаков 4.2.2.1. Контроль четности Простейшим кодом, создающим условия обнаружения ошибок, является код с проверкой четности. При этом кодировании, для 171 формирования кодового слова каждые k информационных бит дополняются одним контрольным битом. Этот контрольный бит таков, что общее число «1» в кодовом слове всегда четное. (Контрольный бит в этом случае называют битом четности). Приемник проверяет число «1» в пришедшем слове и, если оно оказывается нечетным, фиксирует наличие ошибки. Таким образом, этот метод позволяет обнаружить ошибочные слова, если они сформировались в результате искажения нечетного числа битов. Уровень избыточности кода составляет 1/(k+1). Эффективность такого кодирования, в смысле вероятности пропуска ошибочных слов, будет существенно зависеть от статистических характеристик ошибок, которые вносит канал. Рассмотрим две модели этих ошибок. Модель 1 – случайная групповая ошибка Пусть длина кодового слова равна n бит. Определим вектор ошибки  e = (e1, e2 ,..., en ) , где 1, при наличии ошибки в i - м бите ei =  0 , при правильном i - м бите. В предельном варианте плохой помеховой обстановки можно считать, что любой из 2 n векторов ошибок равновероятен. В этих условиях, код с контролем четности не обнаруживает ошибки при четном числе единиц в  векторе e . Следовательно, Р[пропуска ошибки] ≤ 0.5. (4.1) Видим, что вероятность «неудачи» обнаружения указанных групповых ошибок для этого кода оказывается очень высокой. Модель 2 – случайная битовая ошибка Будем считать, что ошибки в битах кодового слова являются взаимно независимыми и пусть p – вероятность ошибки передачи одного бита. Тогда, вероятность искажения j произвольных битов из последовательности n бит будет равна 172 P[ j , n] = p j (1 − p) n − j . Представим это выражение в виде j p  P [ j , n] = (1 − p)   . p − ( 1 )   n (4.2) Если учесть, что j – это число искаженных бит и p < ½, то из (4.2) хорошо видно, что вероятность появления на выходе канала слов далеко «отстоящих» от исходного кодового слова, быстро уменьшается с ростом этого «расстояния» (с ростом j). Таким образом, слова на выходе такого канала группируются вблизи исходных кодовых слов. Рассматриваемый метод искаженных бит, (т. е. при j = 2k, терпит неудачу при k = 1, 2,…, n 2 ). четном числе Следовательно, для рассматриваемой модели, вероятность пропуска ошибки может быть представлена в виде n n Р[пропуска ошибки] =   p 2 (1 − p) n − 2 +   p 4 (1 − p) n − 4 + ... , 2 4 (4.3) n n! где   = .  j  j!(n − j )! Поскольку обычно p << 1, то в выражении (4.3) можно учитывать лишь первое слагаемое уже при p = 10−3 . Так, при n = 32 и p = 10 −4 , P[пропуска ошибки] ≈ 4,5 ⋅ 10−6 . Если бы проверочного бита не было, то P[пропуска ошибки] была бы равна вероятности искажения кадра, которая не меньше вероятности искажения в нем одного произвольного бита. Последняя равна, примерно, 32 p = 3.2 ⋅ 10 −3 . Таким образом, добавление одного бита четности позволило в 1000 раз уменьшить вероятность пропуска ошибки. Эффективность обнаружения групповых ошибок существенно увеличивается, если информационное слово представить в виде матрицы n x k. (для этого его размер должен быть кратен n). Вычислив биты чётности 173 для каждого столбца и добавив их в качестве (k + 1) строки, получим кодовое слово размером (n + 1) x k. Это кодовое слово передаётся в канал по строкам и на приёмной стороне выполняется проверка битов чётности по столбцам. Ясно, что групповая ошибка длиной не более n бит будет обнаружена. В целом, вероятность пропуска ошибки в этом случае не превышает 2-n. 4.2.2.2. Контрольная сумма в протокольных блоках стека TCP/IP Идея контрольной суммы, как признака целостности блока данных, иллюстрируется простым примером. Пусть информационная последовательность содержит числа: {12, 1, 7, 0, 3, 9}. Их сумма равна 32. Сформируем кодовое слово {12, 1, 7, 0, 3, 9, -32}. Если приёмник выполнит суммирование чисел переданного кодового слова, то нулевое значение результата может говорить о высокой вероятности отсутствия ошибок). Функция вычисления контрольного признака (контрольной суммы), добавляемого в блоки данных протоколами стека TCP/IP, следует этой же логике. В протоколах этого стека размер блока данных по условиям его формирования всегда кратен 16 и ограничен величиной 216 - 1. Следовательно, блок данных можно представить последовательностью 16– битных слов b i (i = 0, 1, …, L), где b L – контрольная сумма. Алгоритм вычисления контрольной суммы содержит простые операции побитного суммирования с переносом переполнения старшего разряда результата в младший (круговое суммирование) и инвертирования результата: bL = 0, x = (b0 + b1 + ⋅ ⋅ ⋅ + bL ), bL = − x Приемник выполняет этот алгоритм (за исключением операции b L = 0) над словами полученного протокольного блока и появление хотя бы одной 1 в любом из разрядов инвертированного результата является сигналом наличия ошибки. Приведем, в качестве примера, кодовые комбинации, вычисленные по рассмотренному алгоритму, для двухразрядных слов. В этом случае блок 174 данных может содержать не более 22 – 1 = 3 слов (два информационных и одно контрольное). В таблице ниже: b 0 и b 1 – двухбитные информационные слова , а b 2 – вычисляемая контрольная сумма. b0 b1 b2 b0 b1 b2 0, 0 0, 0 1, 1 1, 0 0, 0 0, 1 0, 0 0, 1 1, 0 1, 0 0, 1 0, 0 0, 0 1, 0 0, 1 1, 0 1, 0 1, 0 0, 0 1, 1 0, 0 1, 0 1, 1 1, 1 0, 1 0, 0 1, 0 1, 1 0, 0 0, 0 0, 1 0, 1 0, 1 1, 1 0, 1 1, 0 0, 1 1, 0 0, 0 1, 1 1, 0 0, 1 0, 1 1, 1 1, 0 1, 1 1, 1 0, 0 Нетрудно видеть, что S = – (b 0 + b 1 + b 2 ) = 0. Применение 16-битной контрольной суммы позволяет обнаруживать все одиночные ошибки и пакетные ошибки размером не более 16 бит. Одной из слабостей алгоритма является его нечувствительность к изменению порядка 16-битных слов в защищаемом блоке данных. 4.2.2.3. Контрольный признак на основе циклического избыточного кода Разнообразные циклические избыточные коды (Cyclic Redundancy Cod, CRC) используются почти всеми канальными протоколами для формирования контрольных последовательностей кадров. Определение этих кодов как циклических связано с тем, что если B k = (b 0 , b 1 , …, b n-1 ) является кодовым словом, то и B i = (b n-1 , b 0 , …, b n-2 ) — также допустимое кодовое слово. Эти коды относится к классу полиномиальных. Такое название они получили потому, что формирование кодовых слов реализуется посредством алгебры полиномов с двоичными коэффициентами. Особенности используемой алгебры двоичных иллюстрируются следующими примерами. − Сложение ( x 7 + x 6 + 1) + ( x 6 + x5 ) = x 7 + (1 + 1) x 6 + x5 + 1 = = x 7 + 0 x 6 + x5 + 1 = x 7 + x5 + 1 175 полиномов − Деление x3 + x + 1 x 6 + x5 x6 + x 4 + x3 x3 + x 2 + x - частное x5 + x 4 + x3 + x3 + x 2 x5 + x2 x4 x4 + x2 + x x ← остаток − Умножение ( x + 1)( x 2 + x + 1) = x3 + x 2 + x + x 2 + x + 1 = = x3 + (1 + 1) x 2 + (1 + 1) x + 1 = x3 + 1 Итак, k информационных бит ( i0 , i1 ,, ik −1 ) используются для формирования информационного полинома степени k-1 i ( x) = ik −1x k −1 + ik − 2 x k − 2 + ... + i1x + i0 . В результате кодирования последовательности ( i0 , i1 ,, ik −1 ) формируется кодовое слово из n бит. Из битов кодового слова можно сформировать полиномом b(x) степени n-1 > k-1. Правило кодирования строится так, что полином b(x) удовлетворяет вполне определенному условию, именно – он делится без остатка на заранее определенный (известный передатчику и приемнику) полином g(x), который называется порождающим. Одним из обязательных свойств этого полинома является отличие от нуля коэффициентов при старшей и нулевой степенях переменной x . Будем считать, что формируется кодовое слово длиной n бит, из которых k – информационные и (n - k) – контрольные биты. Такой код обозначают дуплетом (n, k). Для формирования кодового слова используется порождающий полином степени n – k g ( x) = x n − k + d n − k −1 x n − k −1 + ... + d1 x + 1 , 176 где g i – двоичные числа. Формирование полинома b(x), т. е. вычисление проверочных битов (битов CRC), производится по следующему алгоритму. Ш1. Умножить i (x) на x n − k . В результирующем полиноме степени (n - 1) коэффициенты при x n − k −1 ,, x 0 положить равными нулю. Ш2. Разделить полином x n − k ⋅ i (x) на порождающий полином g(x) и определить остаток r (x) . x n − k ⋅ i ( x) = g ( x) ⋅ q ( x) + r ( x) . Ш3. Прибавить остаток r (x) к x n − k ⋅ i (x) , т. е. добавить биты в (n – k) младших разрядов представления полинома x n − k ⋅ i (x) . Полином b( x ) = x n − k ⋅ i ( x ) + r ( x ) делится без остатка на g (x) . Действительно b( x) = x n − k ⋅ i ( x) + r ( x) = [ g ( x) ⋅ q( x) + r ( x)] + r ( x) = g ( x) ⋅ q( x) . Здесь учтена особенность арифметики по модулю 2, при которой r ( x) + r ( x) = 0 . Коэффициенты полинома b(x) образуют кодовое слово, подлежащее передаче по коммуникационному каналу. При этом, любое кодовое слово кратно порождающему полиному. Проиллюстрируем процесс формирования CRC-последовательности на примере кода (7,4) с порождающим полиномом g ( x) = x3 + x + 1 и информационной последовательностью вида (1, 1, 0, 0). Информационный полиномом в этом случае имеет вид i ( x) = x3 + x 2 . Ш1. n – k = 3 x3 ⋅ i ( x) = x 6 + x5 Коэффициенты этого полинома (1, 1, 0, 0, 0, 0, 0). 177 образуют последовательность Ш2. x 6 + x5 = g ( x)( x3 + x 2 + x) + x (смотри приведенный выше пример деления полиномов). Следовательно, r ( x) = x . Ш3. b( x) = x 6 + x5 + x , что соответствует кодовому слову (1, 1, 0, 0, 0, 1, 0). Заметим, что в полученном кодовом слове старшие четыре разряда соответствуют информационным битам, а младшие три — биты CRC. Приемное устройство, сформировав на основе принятой последовательности из n бит полином b' ( x) и выполнив операцию его деления на порождающий полином g (x) , по признаку ненулевого остатка от деления сможет индицировать наличие ошибки в принятом блоке данных (рис. 4.3). Рисунок 4.3. Схема обнаружения ошибки посредством CRC кода Рассмотрим виды ошибок, которые не могут быть обнаружены описанным способом. Представим канал связи аддитивной моделью (рис. 4.3), в которой кодовое слово b(x) суммируется с полиномом ошибок e(x) . Тогда b ' ( x ) = b ( x ) + e( x ) = g ( x ) q ( x ) + e( x ) . Из этого выражения хорошо видно, что если полином e(x) делится без остатка на g (x) , то ошибки обнаружены не будут. 178 Построение порождающего полинома, прежде всего, подчиняется условию обнаружения определенного вида ошибок. Пусть таким условием является обнаружение всех единичных ошибок. Будем считать, что искажен j-й бит. Полином ошибки в этом случае является одночленом вида e( x ) = x j . Поскольку порождающий полином g (x) содержит, как минимум, два слагаемых (коэффициенты при x n− k и x 0 равны 1), то при умножении его на любой другой полином результат будет содержать не менее двух слагаемых. Следовательно, полином e( x) = x j не может нацело делиться на любой порождающий полином, и все единичные ошибки полиномиальными кодами будут обнаруживаться.  В случае парных ошибок полином e (x) имеет вид e( x) = xi + x j = xi (1 + x j −i ) , Как отмечено выше, xi j >i . не делится без остатка на g (x) . Следовательно, e(x) разделится на g (x) только в случае, когда g (x) будет кратен 1 + x j −i . Таким образом, необходимо использовать порождающий полином g (x) , не являющийся делителем полинома 1 + x m , 1 ≤ m ≤ n − 1 . Существует класс, так называемых, примитивных полиномов, одним из свойств которых является их невозможность быть делителями полиномов вида 1 + x m , при m ≤ 2 N − 1 , где N – степень примитивного полинома. Следовательно, для обнаружения всех парных ошибок в кодовых словах длинной n, порождающий полином g (x) следует выбрать из класса примитивных полиномов степени N, удовлетворяющей неравенству 2 N > n . Если в принятом слове окажутся инвертированными нечетное число бит, то полином e(x) будет содержать нечетное число слагаемых ( x5 + x 2 + x , например). В системе операций по модулю 2 нет многочленов с нечетным числом членов, делящихся на многочлен 179 x + 1. Следовательно, если порождающий полином будет кратен такому полиному, то с его помощью будут обнаружены все слова с нечетным числом ошибок. Таким образом, удовлетворяющий перечисленным критериям порождающий полином имеет вид g ( x) = (1 + x) p N ( x) , где p N (x) - примитивный полином. В частности, порождающий полином 16 порядка вида (1 + x)( x15 + x + 1) позволяет детектировать все одинарные и парные ошибки, а также ошибки в нечетном количестве бит в кодовых словах, длина которых не превосходит 215 − 1 = 32767 бит. Заметим, что в последовательности из 32767 бит контрольными являются не более 16 бит, т. е. избыточность такого кода оказывается весьма низкой. Еще одним важным видом ошибок является поражение последовательности L бит в кодовом слове длиной n бит. Если степень порождающего полинома n − k ≥ L , то все ошибки будут обнаружены. При n − k < L не будет обнаружена (1/2n-k) часть всех возможных ошибок. Примеры порождающих полиномов, используемых некоторыми коммуникационными протоколами, приведены в таблице 4.1. Таблица 4.1 Название Полином Используется в CRC-8 x8 + x 2 + x + 1 ATM CRC-10 x10 + x9 + x5 + x 4 + x + 1 ATM CRC-16 x16 + x12 + x 5 + 1 = (1 + x)( x15 + x + 1) CRC-32 x 32 + x 26 + x 23 + x 22 + x16 + x12 + x11 + x10 + x8 + x 7 + x5 + x 4 + x 2 + x + 1 HDLC, V.41 IEEE 802, V.42 Заключение к разделу 4.2 − Адаптационные процедуры уровневых протоколов преобразуют подверженный ошибкам физический дискретный канал связи в надежную систему передачи данных. 180 − Разбиение информационного сообщения на блоки данных (кадры, пакеты и т.д.) обеспечивает неограниченность объемов информационного обмена и, одновременно, является обязательным условием обнаружения ошибок в принимаемых данных. − Алгоритмы помехоустойчивых кодов на передающем узле определенным образом обрабатывают информационный блок, добавляя к нему группу бит, благодаря чему весь протокольный блок приобретает легко проверяемое свойство; получатель, выполнив соответствующий проверочный алгоритм над принятым протокольным блоком, может выявить наиболее вероятные ошибки. 4.3. Методы повторной передачи Повторная передача испорченных и потерянных блоков данных является широко используемой адаптационной процедурой и основным механизмом обеспечения безошибочной передачи данных в сетях самых разных технологий. Повторная передача используется протоколами разных уровней сетевого стека, но не обязательно всеми. В стеке TCP/IP, например, она предусмотрена только на транспортном уровне и в ряде прикладных протоколов. В общем случае, передающий и принимающий модули уровневого протокола, в котором предусмотрен механизм автоматического запроса повторной передачи (Automatic Retransmission ReQuest, ARQ) обмениваются своими протокольными блоками (для краткости будем называть их кадрами), типы которых представлены на рисунке 4.4. I-кадр N-передатчик CRC H N-приемник БД уровня N+1 Узел А N-приёмник H N-передатчик CRC БД уровня N+1 без ошибок Узел B С-кадр Рисунок 4.4. Схема ARQ–процедуры 181 Узел А, отправляя какую-то порцию сообщения узлу B, формирует I-кадр, в котором кроме информации содержатся заголовок (Н) и контрольная последовательность (CRC). Уровневый протокол узла B информирует отправителя о результатах проверки целостности I-кадра посылкой управляющего кадра (С-кадр), содержащего только заголовок и контрольный признак. В случае фиксации ошибки в принятом I-кадре инициируется автоматический запрос его повторной передачи. Далее (для простоты) будем считать, что информационные кадры передаются только в одном направлении, а обратный канал используется лишь для доставки контрольных сообщений. Примем также допущение о сохранении последовательности прибывающих кадров, т. е. если они приходят, то в том же порядке, в каком были отправлены; нарушение естественной последовательности принимаемых кадров свидетельствует о потере одного или нескольких предшествующих кадров. Существует три основных варианта реализации процедуры ARQ: ARQ с остановкой и ожиданием, ARQ с возвратом на N и ARQ с выборочным повторением. Общая схема работы этих механизмов следующая. Отправитель при посылке каждого кадра сохраняет его копию в буфере и запускает таймер time out обратного отсчета. Получатель направляет подтверждение о каждом принятом без ошибок кадре (положительное подтверждение, Acknowledgement, АСК). Если кадр подтверждения не пришел к отправителю до момента достижения таймером time out нулевого значения, потерянным то неподтвержденный (испорченным) и информационный подлежащим кадр считается повторной отправке. Перечисленные варианты ARQ отличаются дисциплиной передачи кадров данных, правилами их обработки приёмником и правилами отправки подтверждений. Заметим, что кадры подтверждений также могут приходить с ошибками, но они никогда не подтверждаются и не повторяются. 182 4.3.1. ARQ с остановкой и ожиданием Протокол, использующий механизм ARQ с остановкой и ожиданием (Stop-and-Wait ARQ, SW-ARQ), организует работу передатчика и приемника так, что в любой момент времени в канале связи находится не более одного кадра; поэтому, такой метод ARQ может использоваться и при полудуплексном режиме связи. Рисунок 4.5 показывает, каким образом механизм тайм-аута и только положительные подтверждения (АСК) принятых без ошибок кадров обеспечивают надежную передачу данных. За время Tout узел А не получил подтверждения приема кадра 1 и отправил его повторно Tout Tout A t Кадр 0 Кадр 1 Кадр 1 АСК Кадр 2 АСК В t Рисунок 4.5. ARQ с остановкой и ожиданием На первый взгляд, такая процедура никаких требований к нумерации ни I-, ни С-кадров не предъявляет. Однако, на рисунках 4.6.а и 4.6.б представлены ситуации, когда отсутствие нумерации отправляемых кадров приводит к потере работоспособности этого механизма ARQ. Tout A Кадр 0 Кадр 1 АСК B t Кадр 1 АСК Кадр 2 АСК t а) АСК кадра 1 поврежден и узел В принял две копии кадра 1 АСК дубликата кадра 0 интерпретируется как АСК 1 Кадр 0 B T < Tout Tout A t Кадр 0 Кадр 1 АСК 0 АСК 0 Кадр 2 t б) малое значение Tout и отсутствие нумерации кадров приводит к ошибкам их интерпретации Рисунок 4.6. ARQ с остановкой и ожиданием: возможные ошибки 183 Ошибки в доставке кадров, возникающие в ситуациях, представленных на рисунках 4.6.а и 4.6.б, оказались возможными по причине отсутствия нумерации информационных кадров. В условиях ограниченности числа битовых позиций в заголовке кадра, отводимых для его номера, важно определить требования к длине нумерующей последовательности, обеспечивающей корректную работу алгоритма. Для рассматриваемого механизма ARQ даже двоичная нумерация отправляемых кадров является достаточной. Действительно, пусть передатчик в однобитовой переменной Slast сохраняет номер (0 или 1) последнего отправленного кадра, а приемник в двоичной переменной Rnext записывает значение на единицу большее номера последнего принято кадра (т. е. номер следующего ожидаемого кадра). В целом, состояние системы «передатчик–приемник» описывается вектором ( Slast , Rnext ). В начальном состоянии – это вектор (0, 0). Такое состояние системы не может измениться до тех пор, пока приемник не получит без ошибок кадр с номером 0, т. е. до этого момента станция А (передатчик) с периодичностью, определяемой значением тайм-аута, будет отсылать кадр с номером 0. Получив кадр 0 и убедившись, что указанный в нем порядковый номер совпадает с текущим значением Rnext , станция В устанавливает Rnext = 1 и отсылает управляющий кадр АСК, в специальном поле заголовка которого передает значение этой переменной. Так система переходит в состояние (0, 1). Начиная с этого момента любой кадр данных, имеющий порядковый номер 0, будет восприниматься станцией В как дубликат уже принятого кадра и уничтожаться; при этом, на каждый уничтоженный дубликатный кадр приемником будет отсылаться АСК со значением Rnext = 1 (рис. 4.7). Как только станция А получит АСК с Rnext = 1, она установит значение своей переменной Slast = 1 и отправит очередной кадр номер 1. Тем самым, система переходит в состояние (1, 1). После успешного приема 1-го кадра состояние системы будет описываться вектором (1, 0), а получение 184 хостом А кадра АСК со значением Rnext = 0 установит значение вектора состояния протокола в (0, 0). Таким образом, SW-ARQ с двоичной нумерацией кадров обеспечивает актуальной информацией обе стороны о «правильном» очередном событии приёма и гарантирует корректную последовательность отправки и приема всех информационных кадров. Slast = 1 Slast = 0 A Slast = 0 Tout Кадр А Кадр Б Кадр Б АСК АСК Rnext = 0 Rnext = 1 Rnext = 0 B t Кадр В АСК t Rnext = 0 Кадр Б отбрасывается как дубликат, но его приём подтверждается Рисунок 4.7. Организация нумерации кадров в SW ARQ Описанный механизм нумерации кадров является простейшей реализацией алгоритма «скользящего окна», широко используемого уровневыми протоколами для управления передачей. Сущность алгоритма заключается в том, что передающий узел всегда «знает» диапазон последовательных номеров кадров, которые он имеет право отправить. Нижняя (левая) граница этого диапазона на единицу больше максимального номера кадра, благополучная доставка которого подтверждена, а верхняя граница определяется величиной окна передачи, которую пока будем считать постоянной. При отсылке каждого кадра увеличивается значение специального указателя – он смещается от значения левой граница вправо на единицу; когда указатель достигает правой границы, передача кадров останавливается. Получение подтверждения успешной доставки очередного из отправленных кадров увеличивает значение левой границы окна передачи, сохраняя при этом его величину, т. е. окно «скользит» вправо. В свою очередь, получатель поддерживает приемное окно, т. е. диапазон номеров кадров, которые он имеет право принять. Получение кадра без ошибок и с номером, равным нижней границе окна, приводит к увеличению её значения 185 на единицу; передача кадра модулю протокола вышестоящего уровня смещает вправо верхнюю границу окна приема. Любой пришедший кадр с порядковым номером, не попадающим в окно приема, игнорируется (уничтожается) без каких-либо дополнительных действий. Таким образом, входящие в диапазон окна передачи номера, соответствуют кадрам, которые передатчик имеет право отослать, а номера, входящие в окно приема, являются номерами кадров, которые при получении не будут уничтожены. Размеры окон передачи и приема не обязаны быть одинаковыми; более того, они могут изменяться и, тем самым, регулировать интенсивность потока кадров. В SW-ARQ размеры окон фиксированы и равны единице. Рассмотренный вариант ARQ становится весьма неэффективным на линиях с высокой пропускной способностью и/или с большим суммарным временем доставки в обоих направлениях. Пусть, например, время передачи кадра в 1000 бит и получение подтверждения его приема по каналу с номинальной пропускной способностью 1.5 Мбит/с составляет 40 мс. Использование механизма SW-ARQ приведет к тому, что коэффициент использования этого канала (отношение числа переданных за определенный интервал времени бит Q к номинальному числу бит, которые могли бы быть переданы за тот же интервал времени, Q nom ) составит Q 103 1 . = = Qnom 1.5 ⋅ 10 6 ⋅ (40 ⋅ 10 −3 ) 60 Ситуация становится еще более неудовлетворительной, если учесть затраты на возможные повторные передачи испорченных кадров. Тем не менее, SW-ARQ успешно используется протоколами, управляющими передачей данных по линиям с низкой номинальной пропускной способностью, в частности, он применялся модемным протоколом передачи файлов XMODEM. Используется этот механизм повторной передачи и для линий с малым временем полного оборота, например, в беспроводных локальных сетях. 186 4.3.2. ARQ c возвратом на N Невысокая производительность алгоритма ARQ с остановкой и ожиданием на относительно высокоскоростных линиях может быть преодолена, если разрешить передатчику посылать кадры «пачками», не ожидая получения подтверждения успешной доставки каждого из них. Именно это и предусматривает протокол ARQ с возвратом на N (GO-Back-N ARQ, GBN-ARQ). Будем считать, что все кадры снабжены порядковыми номерами 0, 1, 2, … Пусть также задана величина окна передачи, т. е. максимальное число кадров Ws , которое передатчик имеет право отослать, не дожидаясь получения подтверждения успешного приема первого из них. Значение Ws обычно выбирается примерно равным величине (τ ⋅ C) n , где τ - интервал времени между отправкой первого бита информационного кадра и получением последнего бита кадра АСК, С – номинальная пропускная способность канала (битовая скорость его интерфейса) и n – средняя величина кадра (бит). Такой выбор величины Ws гарантирует полную загрузку канала при условии наличия кадров для передачи. Окно приёма WR устанавливается равным единице (одному кадру). WS S last Подтвержденные кадры S recent … S last + Ws -1 Переданные кадры Rnext Принятые кадры Буфер Timer [Slast] Приемник принимает кадры, не содержащие ошибок и лишь те, чей порядковый номер равен Rnext (окно приема WR =1) Slast Slast+1 Timer [Slast +1] ::::::::: ‫׃‬ Timer [Srecent] Srecent Приемник Передатчик Рисунок 4.8. Функциональная схема алгоритма ARQ с возвратом на N 187 Алгоритм с ARQ возвратом на N управляет передатчиком посредством механизма скользящего окна (рис. 4.8). Передатчик ведет учет кадров, разрешенных к отправке. Начальный номер этого списка Slast является порядковым номером кадра, следующего за тем, чья успешная доставка была уже подтверждена и, одновременно, этот номер – левая граница окна передачи. Правой границей окна передачи является значение Slast + Ws − 1 . Номер S recent соответствует последнему из отправленных кадров. Каждый отосланный, но еще не подтвержденный кадр сохраняется в специальной буферной памяти передатчика. Когда счетчик S recent достигает значения Slast + Ws − 1 , т. е. верхней границы окна передачи, отправка кадров прекращается до момента получения сообщения ACK, подтверждающего доставку кадра с номером большим, или равным Slast . Это увеличивает значение Slast на единицу или более и, тем самым, смещает вправо верхнюю границу диапазона разрешенных к передаче кадров. Для того, чтобы обеспечить строго последовательный приём кадров и соответствующее информирование передатчика, приёмное устройство формирует окно приёма WR , размер которого равен 1, а указателем, хранящим номер очередного ожидаемого кадра, является переменная Rnext . Очередной принятый кадр, в котором не обнаружены ошибки и порядковый номер которого равен Rnext , записывается в буфер протокола вышестоящего уровня, а значение Rnext увеличивается на единицу. Каждый кадр АСК, отправляемый приемником, несёт текущее значение Rnext , чем и подтверждается успешный прием всех кадров, номера которых меньше Rnext . Передатчик, получив такой АСК, фиксирует успешный прием всех кадров с номерами 0, 1, 2,…, Rnext − 1 даже, если подтверждение о приеме какого-то из этих блоков подтверждений ранее им важна, получены поскольку не были. доставка (Эта кумулятивность подтверждений не подтверждается). Фиксация успешной передачи кадра осуществляется 188 передатчиком посредством модификации значения своей переменной Slast . Устанавливая S last = Rnext передатчик перемещает указатель обеих границ диапазона разрешенных к передаче кадров на единицу или более вправо. Если за время тайм–аута, отсчитываемого по кадру с номером Slast , кадр АСК с Rnext > Slast не получен, то передатчик считает ранее переданные кадры с номерами от Slast и выше (вплоть до Slast + Ws − 1 ) утерянными и повторяет их передачу. Время тайм–аута должно несколько превосходить среднее время, необходимое для пересылки кадра максимального размера и получения положительного подтверждения (время полного оборота, Round Trip Time, RTT). С учетом возможности пересылки подтверждения в составе заголовка информационного кадра, передаваемого в обратном направлении, продолжительность тайм-аута должна включать в себя удвоенное время передачи кадра максимального размера ( 2TF ), удвоенное время распространения электромагнитных колебаний в среде передачи ( 2T p ) и удвоенное время обработки кадра принимающим модулем ( 2T pr ), т. е.: Tout ≥ 2T p + 2TF + 2T pr . 3-6 2-5 WS 1-4 0-3 A К0 К1 К2 Time-out К3 К4 К5 К6 Повторная передача К6 К3 К4 К5 t WS = 4 t B Rnext =1 Rnext =2 Rnext =3 Rnext =3 Rnext =3 Rnext =4 Rnext =5 Rnext =3 Рисунок 4.9. Схема работы алгоритма GBN-ARQ Пусть передатчик отправил кадры с номерами 0, 1, …, Ws − 1 (рис. 4.9.). Если к моменту готовности отсылки кадра с номером Ws (или 189 раньше) подтверждение успешной доставки кадра № 0 было получено, то кадр с номером Ws отсылается. В общем случае, если в моменту готовности к отправке кадра с номером L+1 оказывается, что доставка кадра с номером L + 1 − Ws не подтверждена, то передатчик останавливается, ожидает истечения тайм-аута и считает все последние Ws кадров утерянными (следствие единичного окна приема). Далее выполняется повторная отсылка кадров с номерами L +1 − Ws , L + 2 − Ws и т. д. Go Back-4, m = 2, WS = 2m 4 T Передатчик возвращается к кадру 0 out K0 A K1 K3 K2 K0 K1 K2 K3 t WS а) t B Rnext = 1 Rnext = 2 Rnext = 3 Rnext = 0 и SN = 0 Принимается кадр-дубликат Rnext = 0 Go Back-3, m = 2, WS = 3 < 2m Передатчик возвращается к кадру 0 Tout A K0 K1 K2 K0 K2 K1 K3 t б) t B Rnext = 1 Rnext = 2 Rnext = 3 Rnext = 3 и К0, К1 и К2 уничтожаются как дубликаты Рисунок 4.10. Размер окна передачи GBN-ARQ должен быть меньше 2m Для корректной работы протокола очень важна нумерация кадров. Пусть число двоичных разрядов, отведенных в заголовке кадра для его порядкового номера, равно m. Это позволяет пронумеровать не более 2 m кадров. Ясно, что в передаваемом потоке будут присутствовать серии кадров, порядковые номера которых повторяются с периодом 2 m . В таких условиях для исключения ошибочной интерпретации кадров необходим запрет отправки в канал кадра с номером равным номеру еще не подтвержденного 190 кадра предыдущего цикла (приемник не должен получать кадры с одинаковыми номерами в пределах одного окна передачи). Это требование накладывает ограничения на величину окна передачи Ws < 2 m , ибо при Ws = 2 m уже возможна ошибка приёмника (рис. 4.10.а). В условиях, когда Tout >> 2T p + 2TF + 2T pr = RTT (т.е. время тайм-аута заметно больше времени полного оборота между передатчиком и приемником) потеря кадра и повторная его передача через Tout будет сопровождаться интервалом бездействия канала. Для ослабления этого негативного эффекта в качестве сигнала потери кадра с номером k принимается получение нескольких кадров АСК с неизменным (равным k) значением параметра Rnext (так называемые, дубликатные АСК). Обычно, надежной индикацией потери кадра считается получение трех АСК с неизменным Rnext . При этом, следует иметь ввиду, что если величина Ws мала (меньше трёх сегментов), или данные от приложения в необходимом числе сегментов еще не сформированы, то передатчик до истечения таймаута, связанного с неподтвержденным кадром, не сможет возвратиться к повторной передаче утерянного блока данных. Очевидно, что ARQ с возвратом на N для реализации своих преимуществ в части исключения «простоя» линии связи требует организации обратного канала и может применяться лишь при дуплексном режиме связи. Если между взаимодействующими сетевыми узлами осуществляется взаимный информационный обмен, то объем пересылаемых управляющих кадров может быть уменьшен посредством включения сообщений АСК в заголовок информационных кадров, направляемых в обратном направлении. Если в момент получения корректного информационного кадра станция В не располагает своим информационным кадром для станции А, то она запускает АСК-таймер, определяющий максимально допустимое время ожидания от своего вышестоящего уровня 191 такого кадра. По истечении АСК-таймера станция B отправляет подтверждение посредством обычного АСК-кадра. Несколько иначе в случае двунаправленного информационного обмена реализуется и контроль последовательности принимаемых кадров. Тот из них, который приходит с ошибками, уничтожается. Последующие кадры, прибывающие уже с нарушением непрерывности их нумерации, даже если они безошибочны, уничтожаются тоже, но только после проверки и A считывания содержимого поля АСК, в котором содержится значение Rnext ( A) другой стороны. (По этому значению переменной Rnext устанавливается (B ) ). значение переменной Slast ARQ с возвратом на N является базисным механизмом обеспечения надежности передачи данных в ряде канальных протоколов; используется он и протоколом TCP. 4.3.3. ARQ c выборочным повторением Механизм ARQ с возвратом на N может повторно передавать кадры, которые были благополучно доставлены получателю. Например, пусть кадр 1 оказался ошибочным и был уничтожен, а последующие кадры 2, 3, …, WS - 1 доставлялись без ошибок. Тем не менее, приемник должен был уничтожать их, а передающий узел после истечения тайм-аута кадра 1 вместе с ним должен отправлять кадры 2, 3, … , WS - 1. Очевидно, что такие повторные передачи снижают эффективную производительность уровневого протокола, использующего механизм GBN-ARQ. Механизм ARQ с выборочным повторением (Selective Repeat, SR-ARQ) исключает такие повторные передачи. Для этого потребовалось: − использовать приемное окно размером более одного кадра для приёма кадров, пришедших без ошибок, но с нарушением их последовательности; − сделать возможной повторную передачу отдельного кадра, т. е. проинформировать передатчик, какой именно кадр не был принят. 192 На рис. 4.11 представлена функциональная схема рассматриваемого алгоритма. Размер окна приёма Wr позволяет принимать кадры с номерами от Rnext до Rnext + Wr − 1 . Принятые без ошибок кадры из этого диапазона помещаются в буфер; объем такого буфера должен быть не меньше окна передачи. Кадры из буфера передаются вышестоящему протоколу в соответствии с определенной дисциплиной и только в их исходной последовательности. WS S recent S last … Принятые кадры S last + Ws -1 Подтвержденные кадры WR Rnext Rnext+p Timer [Slast] Timer [Slast +1] Rnext+k Буфер Буфер Slast :::::: Rnext + p Slast+1 Rnext + p + 1 :::::: :::::: Srecent Timer [Srecent] Rnext+WR -1 Rnext + k :::::: Передатчик Приемник Рисунок 4.11. Алгоритм ARQ с выборочным повторением При получении кадра, нарушающего непрерывность их нумерации (пусть кадр с номером Rnext + p ), но принадлежащего диапазону [ Rnext , Rnext + Wr − 1 ], приемник сохраняет его в буфере и отсылает специальное сообщение NAK (Negative Acknowledgement), которым подтверждает успешный прием кадра Rnext + p и, как и ранее, передает значение Rnext . Последнее говорит передатчику о недоставке кадра с номером Rnext и не позволяет ему изменить значение Slast . Наличие в буфере передатчика всех отправленных, но еще неподтвержденных кадров, позволяет повторить передачу любого из них. Следуя сообщению NAK, передатчик выполняет повторную отправку кадра 193 Rnext и, если он благополучно принимается, то группа кадров Rnext , Rnext + 1, Rnext + 2 ,…, Rnext + k , находящихся в буфере приемника, передаётся модулю вышестоящего протокола. В примере на рис. 4.12 предполагается, что окно передачи W S = 6 и кадры K0, K1, … , K5 могут передаваться. Получив кадр К3, вместо ожидавшегося К2, приемник буферизирует его и отправляет сообщение NAK с Rnext = 2 ; на последующие принимаемые кадры K4, K5 отсылает АСК с Rnext = 2 . Получив отрицательное подтверждение (NAK с Rnext = 2 ), передатчик повторно отправляет кадр К2. В момент, когда кадр 2 оказывается принятым, в буфере приемника уже находятся кадры 3, 4, 5. Поэтому старое значение Rnext = 2 изменяется на Rnext = 6 . Передатчик возвращается к кадру 2 A K0 K1 K2 K3 K4 K5 K2 K6 K7 t Ws=6 B ACK0 Rnext = 1 ACK1 Rnext = 2 NAK3 Rnext = 2 ACK4-5 Rnext = 2 ACK2 Rnext = 6 t ACK7 Rnext = 8 Рисунок 4.12. Восстановление потерянного кадра алгоритмом ARQ с выборочным повторением Возможность буферизации кадров в пределах окна приема усложняет задачу различения кадров с одинаковыми номерами, принадлежащих разным циклам нумерующей последовательности. Её решение потребовало более строгого, в сравнении с GBN-ARQ, ограничения величины окна передачи. Рассмотрим пример, в котором величина окна передачи устанавливается по правилу алгоритма GBN, т. е. при m = 2, Ws = Wr = 2m − 1 = 3 (рис. 4.13). Передатчик отправил полное окно кадров, они были благополучно приняты, но все подтверждающие их прием ACK-кадры были утеряны. Кадры К0, К1 и К2 будут переданы приложению (ведь они пришли без 194 ошибок и в должном порядке). После истечения тайм-аута передатчик повторно отправит неподтвержденные кадры. На рис. 4.13 в фигурных скобках приведены списки номеров окна приёма в моменты получения очередного кадра. Из них видно, что приемник будет воспринимать повторно отправленный кадр К0, как кадр с номером 0 следующей серии нумерации и не уничтожит его. m=2 WS = WR =2m – 1 = 3 Tout A K1 K0 K2 K0 t Номера кадров окна приёма B {0,1,2} {1,2,3} ACK0 Rnext = 1 {2,3,0} {3,0,1} ACK2 Rnext = 0 ACK1 Rnext = 2 t Нераспознаваемый дубликат Рисунок 4.13. Окно передачи размером 2m -1 для SR-ARQ приводит к ошибкам распознания дублей Для верного распознания дублей необходимо, чтобы длина нумерующей последовательности m удовлетворяла условию 2m ≥ 2Ws . Иными словами, величина окна передачи не должна превосходить половину длины нумерующей последовательности, т. е. максимальное значение окна передачи и минимальное окна приёма должно составлять Ws ≤ 2 m −1 ≤ Wr (рис. 4.14). m=2 WS = WR = 2m-1 = 2 Tout A B K0 K1 {0,1} {1,2} ACK0 Rnext = 1 t K1 K0 {2,3} ACK1 Rnext = 2 ACK0 Rnext = 2 Номера кадров окна приёма {2,3} t ACK1 Rnext = 2 Распознаваемые дубликаты Рисунок 4.14. SW-ARQ при размере окна передачи 2m -1 распознает дубли В сравнении с алгоритмом GO-Back-N рассматриваемый метод повторной передачи более эффективно использует пропускную способность 195 канала; однако он сложнее в реализации и требует больших ресурсов конечных узлов (буферная память, в частности). Этот алгоритм используется современными версиями протокола ТСР. 4.3.4. Анализ эффективности алгоритмов повторной передачи Эффективную скорость передачи протокольного блока данных определим выражением: Ref = количество бит в поле данных n F − nh , = t0 полное время доставки где: nh - число бит, отведенных для заголовка кадра; nF - число бит в протокольном блоке (далее, для краткости, в кадре). Производительность алгоритма управления передачей оценим отношением эффективной скорости к номинальной пропускной способности канала R, т. е. η0 = Ref R . Для упрощения анализа примем следующие допущения: − передача информации (I-кадров) осуществляется в одном направлении, а обратный канал используется только для доставки подтверждений; − ошибки и повторные передачи отсутствуют; − все I-кадры имеют одинаковый размер, − передатчик всегда располагает кадрами, нуждающимися в отправке. t0 I- кадр ACK t A I- кадр ACK t B tp tF tpr tack tp tpr Рисунок 4.15. Компоненты времени доставки кадра протоколом, использующим SW_ARQ, при отсутствии ошибок 196 Диаграмма на рис. 4.15 иллюстрирует компоненты задержки t 0 , вносимой в информационный обмен алгоритмом ARQ с остановкой и ожиданием. Полное время доставки одного протокольного блока представимо выражением: t o = 2t p + 2t pr + t F + t ack = 2t p + 2t pr + n F nack + , R R (4.4) где: nF и nack - число бит в I- и С-кадрах соответственно. Тогда, производительность алгоритма определится выражением: nF − nh R t0 η0 = ef = = R R nh nF . 2(t p + t pr ) R 1− n 1 + ack + nF (4.5) nF Полученное соотношение ясно показывает факторы, отрицательно влияющие на эффективность алгоритма SW-ARQ. В их числе: «расход» бит на заголовок кадра ( nh / n F ), необходимость служебных кадров ( nack / nF ) и произведение (t p + t pr ) R . Таблица 4.2 nh = 64, nack = 64 nF = 8192 бит t p + t pr (с) R 5∙10-3 30 кбит/с 0,95 1.5 Мбит/с 0,35 45 Мбит/с 1,77∙10-2 2.4 Гбит/с 3,39∙10-4 5∙10-2 0,72 5,14∙10-2 1,80∙10-3 3,39∙10-5 5∙10-1 0,21 5,39∙10-3 1,81∙10-4 3,39∙10-6 5∙10-3 0,99 0,97 0,53 2,1∙10-2 5∙10-2 0,99 0,77 1,04∙10-1 2,18∙10-3 5∙10-1 0,21 0,26 1,15∙10-2 2,18∙10-4 nF = 524288 бит (64 кбайт) t p + t pr (с) В таблице 4.2 представлены значения η 0 алгоритма SW-ARQ при применении его на различных линиях передачи. При получении этих данных было принято, что (t p + t pr ) = 5мс, 50мс и 500мс. Эти задержки являются 197 характерными для национальных, межконтинентальных и спутниковых линий связи. Номинальная пропускная способность линий R = 30 кбит/с (модемное соединение), 1.5 Мбит/с, 45 Мбит/с (цифровые региональные линии) и 2.4 Гбит/с (линия современной базовой сети). Выражение (4.5) и приведенные в таблице 4.2 значения показывают, что ARQ с остановкой и ожиданием эффективен лишь при условии (t p + t pr ) R nF ≤ 1, которое выполняется для низкоскоростных линий с относительно небольшим временем распространения сигнала (линия малой протяженности). Выражение (4.5) не учитывает повторные передачи испорченных кадров. Рассмотрим эффективность протокола SW-ARQ в условиях наличия ошибок передачи. Напомним, что при повреждении кадра для его повторной передачи используется только механизм тайм-аута. Будем считать появление ошибочных кадров случайными независимыми событиями, вероятность которых равна PF . Тогда, вероятность доставки кадра за i попыток составит P[nt = i ] = (1 − PF ) PFi −1 i = 1,2,3,... . Пусть nt - число передач одного кадра, необходимое для его безошибочной доставки. Учтем, что при этом ( nt − 1 ) неудачных попыток потребовали задержек длительностью, равной тайм-ауту. Полное среднее время передачи кадра определяется выражением: ∞ E[ttot ] = t0 + ∑ (i − 1)tout ⋅ P[nt = i ] = i =1 ∞ (4.6) t P = t0 + ∑ (i − 1)tout ⋅ (1 − PF ) PFi −1 = t0 + out F . 1 − PF i =1 Пусть, для упрощения, tout = t0 , тогда E[ttot ] = t0 . 1 − PF Соответственно, эффективная скорость передачи информации составит 198 ′ = Rэф n F − nh n − nh = (1-PF ) F = (1-PF ) Rэф . E[ttot ] to Окончательно, эффективность коммуникационного протокола с SW-ARQ в условиях наличия ошибок описывается выражением ′ Rэф η= Теперь R обратимся к = (1 − PF )η0 . оценке (4.7) эффективности протокола, использующего ARQ с возвратом на N. Будем считать, что размер окна передачи Ws выбран так, что канал оказывается постоянно занятым. При отсутствии ошибок в кадрах это дает возможность получить η ≈ 1. Однако, такое предположение не очень реалистично. Как и прежде, пусть nt – число передач одного кадра, требуемое для его успешной доставки. Если nt = i , то это означает, что потребовалась (i-1) повторная передача Ws кадров и одна удачная пересылка кадра. Следовательно, среднее общее время доставки кадра составит: ∞ E[ttot ] = t F [1 + Ws ∑ (i − 1) ⋅ P[nt = i ]] = i =1 ∞ = t F {1 + Ws ∑ (i − 1)(1 − PF ) PFi −1} = (4.8) i =1 = t F {1 + Ws PF 1 + (Ws − 1) PF } = tF . 1 − PF 1 − PF Эффективная скорость передачи информации, при этом, будет равна n 1- nh nF − nh nF − nh F = (1-PF ) = (1-PF ) Rэф = R. 1 + (Ws − 1) PF E[ttot ] t F [1 + (Ws − 1) PF ] Производительность же протокола с GBN-ARQ описывается выражением nF − nh n 1− h E[ttot } nF . η= = (1 − PF ) R 1 + (WS − 1) PF (4.9) Из этого выражения хорошо видно, что увеличение окна передачи ведет к снижению производительности протокола. 199 Для коммуникационного протокола с выборочным повторением каждая неудачная передача кадра влечет за собой повторную передачу лишь одного кадра. Следовательно, среднее время, затрачиваемое на передачу кадра, составляет: ∞ E[ttot ] = t F [1 + ∑ (i − 1)(1 − PF ) PFi −1 ] = t F i =1 1 . 1 − PF (4.10) Соответственно, эффективная скорость передачи равна Rэф = (1-PF ) (1 - nh )R , nF а производительность протокола: η = (1-PF ) (1 - nh ). nF (4.11) Отметим, что выражения (4.9) и (4.11) не содержат в явном виде произведение (t p + t pr ) ⋅ R , которое, как показано выше, существенно влияет на эффективность работы алгоритма с остановкой и ожиданием. Это является следствием предположения об отсутствии «простоев» в работе передатчика, что требует вполне определенной величины окна передачи. В таблице. 4.3 приведены такие значения Ws , обеспечивающие постоянную занятость канала на линиях, для которых были получены результаты, представленные в таблице 4.2. Таблица 4.3 nF = 1024 байт t p + t pr R 30 кбит/с 1.5 Мбит/с 45 Мбит/с 2.4 Гбит/с 5∙10-3 2 4 57 2932 5∙10-2 2 20 551 29299 5∙10-1 6 185 5495 292971 5∙10-3 2 2 3 48 5∙10-2 2 2 11 460 5∙10-1 2 5 88 4550 nF = 64 кбайт t p + t pr 200 Видно, что приемлемая величина окна, при котором канал полностью загружается, может быть получена лишь для относительно низкоскоростных каналов. Уже для канала 45 Мбит/с разумный размер окна можно получить только для очень больших кадров. Однако такие кадры сильно подвержены влиянию помех, поэтому «разумный» размер кадра должен выбираться с учетом закона распределения вероятности ошибок в канале. Для канала с равномерным распределением ошибок по битам и при вероятности их возникновения равной p получаем PF = 1 − (1 − p) n F ≈ 1 − (1 − nF ⋅ p) ≈ nF ⋅ p . Требование PF << 1 , очевидно, накладывает ограничение на размер кадра nF . η 1,0 0,8 SR GBN 0, 0,4 SW 0,2 1∙10-3 p 5∙10 -4 -4 10 5∙10 -5 -6 10 5∙10 -6 Рисунок 4.16. Сравнительная эффективность механизмов ARQ Рис. 4.16 дает сравнительную картину эффективности рассмотренных протоколов при работе их на каналах с ошибками. Эти кривые получены при следующих значениях t p + t pr = 5 ⋅ 10 −3 с, Ws = 4 . параметров: n F = 1024 байт, R = 1,5 Мбит/с, Из приведенных графиков хорошо видно, что эффективность алгоритма повторной передачи с остановками и ожиданием остаётся малой (η < 0.33) даже при очень низкой вероятности битовых ошибок. При вероятностях ошибок, превышающих значение 10-4, эффективность любого механизма ARQ оказывается достаточно низкой, что 201 является следствием растущего числа повторных передач. Действительно, PF ≈ n F ⋅ p = 8192 ⋅ 10 −4 = 0.82 , т. е. более 80% кадров могут содержать ошибки! Заключение к разделу 4.3 Надежность передачи данных между взаимодействующими станциями обеспечивается вычислением и последующей проверкой контрольных признаков протокольных блоков, а также механизмами автоматического запроса повторной передачи (ARQ). Алгоритмы предполагают автоматического наличие между запроса повторной взаимодействующими передачи узлами полудуплексного (ARQ c остановками и ожиданием) или дуплексного (ARQ с возвратом на N и ARQ с выборочным повторением) канала. Механизмы ARQ используют таймеры повторной передачи, нумерацию передаваемых блоков данных и кадры–подтверждения. Алгоритм ARQ с остановками и ожиданием, – простейший из алгоритмов повторной передачи, – может работать на полудуплексном канале связи и удовлетворяется двоичным счетчиком кадров. Алгоритм эффективен лишь на линиях, где время полного оборота сравнимо с временем передачи кадра. Алгоритм ARQ с возвратом на N работает только на дуплексных каналах и позволяет отправлять группу из W s кадров подряд (окно передачи); кадр с номером L+W s не может быть передан, пока не получено подтверждение приема кадра с номером L; в случае если отправитель к моменту истечения тайм–аута не получает подтверждения успешной доставки этого кадра, то он повторно передает все кадры начиная с L; кадры нумеруются по модулю 2m (m – число бит в поле номера кадра) и размер окна передачи не должен превышать 2m – 1. Алгоритм ARQ с выборочным повторением более производителен в сравнении с алгоритмом GBN-ARQ. Это достигается благодаря возможности повторной передачи только тех кадров, подтверждения правильного приема 202 которых не были получены своевременно; получатель подтверждает правильно полученные кадры отсылкой «АСК» с указанием номера подтверждаемого кадра, а кадр, принятый не по порядку, подтверждается управляющим кадром «NAK» с указанием номера кадра, подлежащего повторной отправке; получатель сохраняет в буферной памяти до W r принятых кадров и доставляет их приложению только строго упорядочено; нумерация кадров производится по модулю 2m, но размер окна передачи W s не должен превышать 2m-1. Эффективность алгоритмов ARQ оценивается величиной, равной той части пропускной способности канала, которая используется для передачи информационного содержания кадров. Алгоритмы автоматической повторной передачи приводят к определённому уменьшению (в сравнении с номинальным значением) эффективной производительности канала связи; эти потери меньше для ARQ с выборочным повторением. Эффективная производительность каналов с ARQ существенно зависит от оптимальности регулирования величины тайм–аута. Во всех механизмах ARQ сообщения о подтверждении успешной доставки блока данных не подтверждаются. Следовательно, их потеря будет вызывать повторную передачу успешно принятых информационных кадров и снижать эффективность использования канала. Кумулятивный принцип подтверждения приёма в некоторой степени ослабляет влияние таких потерь. 4.4. Управление сетевым трафиком Основной задачей любой коммуникационной системы является передача данных между взаимодействующими приложениями с требуемой надёжностью и с приемлемой задержкой их доставки. На первый взгляд, для этого необходимо, чтобы производительность сети всегда превосходила суммарную интенсивность обрабатываемых ею потоков. Однако, стохастический характер сетевого трафика, являющегося суммой потоков 203 данных большого числа самых разных приложений, с его резко выраженной временной неравномерностью интенсивности делает выполнение этого условия крайне затруднительным. Даже наличие механизмов контроля характеристик входящих в сеть потоков и внедрение сложных дисциплин их обслуживания не всегда защищает сеть от локальных и глобальных перегрузок, при которых нормальная работа приложений становится невозможной. Вместе с тем, предупреждение перегрузок является не единственной целью управления трафиком. В общем случае, её можно определить как достижение эффективного использования и справедливого распределения ресурсов сети (пропускной способности линий связи, процессорного времени и буферов узлов коммутации). Эффективное использование ресурсов означает, что пропускная способность каналов связи используется почти полностью (до 80% номинала), но буферы сетевых коммутирующих устройств не переполнены и требования к задержкам транспортировки информационных потоков удовлетворяются. Справедливость распределения ресурсов определить сложнее. Одним из вариантов может быть следующая формулировка: «Распределение ресурсов сети может считаться справедливым, если оно оптимизирует качество передачи потоков данных всех обслуживаемых сетевых приложений». Совершенно очевидно, что реализация этого принципа требует построения математической модели потока, строгого определения качества их передачи и задания критерия оптимальности. Эти вопросы являются предметом проектирования сетей. Здесь же будут рассмотрены только методы управления интенсивностью потоков и дисциплины обслуживания очередей в сетевых узлах, являющиеся рабочими инструментами управления сетевым трафиком. Фундаментальное значение в этом наборе имеет управление интенсивностью потоков, основной целью которого является предупреждение перегрузок, поскольку их возникновение нарушает любую справедливость и делает недоступными сетевые ресурсы. 204 4.4.1. Перегрузки: источники возникновения и следствия Перегрузка – это состояние сети, при котором ее производительность неограниченно и неуправляемо падает. Вычисление номинального значения производительность сети, в общем случае, является достаточно сложной задачей, и здесь этот вопрос не рассматривается. В контексте материала этого раздела номинальной производительностью сети будем считать максимально достижимый объем данных, передаваемых ею в единицу времени, при приемлемом уровне задержки их доставки. Эта формулировка позволяет определить идеальную сеть как систему, сохраняющую свою производительность на номинальном уровне при сколь угодно большой суммарной интенсивности поступающих в неё потоков данных (на графиках рис. 4.16 нагрузка и производительность сети нормированы к их номинальным значениям). Однако, требование ограниченности задержки доставки блоков данных (пакетов) при любой нагрузке приводит к требованию неограниченности вычислительной мощности узлов маршрутизации и коммутации трафика. Очевидным следствием конечности этого ресурса является необходимость в неограниченной ёмкости буферов, позволяющих сохранять «избыточные» блоки данных и, следовательно, бесконечный рост задержки доставки пакетов (рис. 4.16.б). Производительность Задержка 1 Допустимая задержка 1 а) Нагрузка L 1 Нагрузка L б) Рисунок 4.16. Реакция идеальной сети на рост нагрузки В условиях конечности ресурсов (процессорное время и оперативная память) рост нагрузки неизбежно приведёт к падению производительности сети (рис. 4.17). Действительно, рост 205 производительности вначале замедляется при уровнях нагрузки, превышающих некоторое значение L A . Это является следствием увеличения объёма служебного трафика сетевой системы управления потоками, необходимостью изменения маршрутов доставки пакетов через сеть и т. д. Состояние сети при нагрузках LA ≤ L ≤ LБ часто называют состоянием управляемой перегрузки. При уровнях нагрузки, больших L Б , производительность сети начинает падать, поскольку буферы узлов коммутации уже заполнены и прибывающие блоки данных уничтожаются. Последнее вызывает их повторную передачу, что только усугубляет состояние перегрузки, и производительность сети стремится к нулю. Производительность 1 LА LБ Нагрузка L Рисунок 4.17. Реакция реальной сети на рост нагрузки Состояние перегрузки может возникать как из-за чрезмерного роста интенсивности входящего трафика, так и по причинам внутреннего характера, например, вследствие ошибок внутрисетевой маршрутизации, несбалансированности нагрузки линий связи и т. п. Ограничимся лишь одним примером. На рис. 4.18 представлена достаточно реальная ситуация, когда интенсивность одного из поступающих на узел коммутации потоков (поток А) оказывается существенно больше интенсивности другого потока и оба они должны передаваться через один выходной порт. Если в сети отсутствует механизм приоритезации потоков, то с высокой степенью вероятности интенсивный поток полностью займет буферную память выходного порта коммутатора и, следовательно, блокирует поток Б. Последнее, неминуемо приведет к переполнению буфера входного порта этого потока и может заблокировать порт предшествующего коммутатора. 206 Такие явления могут достаточно быстро парализовать работу других узлов коммутации, что и приведёт к коллапсу всей сети. Возможность их возникновения в сетях коммутации пакетов предсказывалась еще на заре Интернет [J. Nagle, RFC 896, 1984] и они, действительно, многократно фиксировались. А, Б А Б Рисунок 4.18. Блокирование потока Б интенсивным потоком А Описанное состояние является предельным вариантом перегрузки участка сети и его называют затором. В этих случаях увеличение объема буферной памяти коммутатора не решает проблему, и ведёт лишь к увеличению сетевой задержки. Единственным выходом остается уничтожение «избыточных» пакетов и информирование источников потоков о необходимости уменьшения их интенсивности. Нарушение информационного обмена может возникать не только вследствие перегрузки сети, но и по «вине» приемного узла, не успевающего обрабатывать прибывающие данные, которые либо уничтожаются, либо накапливаются в сети, что рано или поздно приводит к исчерпанию ее ресурсов. В такой ситуации также необходимо уменьшение интенсивности генерации трафика. Таким образом, для предупреждения перегрузок необходимо: − или поддерживать на границе сети условия, при которых перегрузки в сети не возникают в принципе, − или располагать механизмами, позволяющими приемнику и сетевым узлам сформировать и быстро передать источникам потоков требования об уменьшении интенсивности; при этом, источник должен иметь возможность адекватно и своевременно отреагировать на это требование. 207 Первый подход требует надёжных схем учета имеющихся сетевых ресурсов, мониторинга их расходования и сложно формализуемых алгоритмов пересчета характеристик потока (прежде всего, его допустимой интенсивности) в параметры сетевых ресурсов. Управление потоком на входе в сеть реализуется генерацией специальных служебных кадров (токенов, маркеров), каждый из которых является разрешением передачи в сеть одного блока данных. Поступающий в сеть пакет потока «уносит» с собой один токен; если данные есть, а свободных токенов нет, то пакеты этого потока в сеть не поступают. В силу отмеченных выше принципиальных сложностей, такой метод не гарантирует исключение перегрузок. Более гибким методом предупреждения перегрузок является управление интенсивностью отдельных потоков узлом–источником на основании сигналов обратной связи от сети и приемника. В этом случае, содержанием процедур предупреждения перегрузок являются генерация сигнала перегрузки и реакция на него источника трафика. 4.4.2. Регулирование интенсивности потоков на основе обратной связи 4.4.2.1. Сигналы перегрузки Строго говоря, обратной связью является именно сигнал о возникновении перегрузки, который генерируется либо узлом маршрутизации, либо узлом назначения потока (рис. 4.19). Такой сигнал может иметь явную (explicit) или неявную (implicit) форму. Источник потока Rk-1 R1 Rk Сообщение сдерживания Получатель потока «Кредит» Rn ECN=1 ECN=1 Явный сигнал «вперёд» Рисунок 4.19. Сигналы управления потоками 208 Явный сигнал перегрузки формируется в виде специального «сдерживающего» сообщения, которое отправляется маршрутизатором непосредственно узлу-отправителю. Для уменьшения объёма служебного трафика сигнал явной обратной связи может быть включен в состав заголовка очередного пакета, маршрутизируемого к получателю, а от него, в составе пакета-подтверждеия, отправлен к хосту-источнику. В сетях TCP/IP, например, реализованы оба способа генерации таких сигналов: специальное сообщение протокола ICMP (Internet Control Message Protocol) и установка бита ECN (Explicit Congestion Notification) в заголовке IP-пакета. Сдерживающее сообщение ICMP-протокола «Sоurce Quench» («Гашение» источника») может генерироваться маршрутизатором как реакция на состояние перегрузки; оно отсылается источнику потока, извещая его о необходимости уменьшить интенсивность передачи. Недостатком метода является генерация дополнительного служебного трафика в периоды перегрузки сети. Однако, при реализации в сети неподтверждаемого сервиса доставки, этот способ является едва ли не единственной возможностью для включения источника в решении задачи предупреждения перегрузок. При ECN-сигнализации маршрутизатор, испытывающий перегрузку, устанавливает значение определенного бита в заголовке обрабатываемого пакета от узла А и отправляет его далее узлу Б. Узел Б копирует этот бит в отдельное поле заголовка пакета ответного сообщения узлу А, который получив это сообщение, уменьшает интенсивность генерируемого потока. Конечно, эта схема работает только для потоков подтверждаемого сервиса. Оба явных метода формирования сигнала перегрузки возлагают на маршрутизаторы дополнительную нагрузку, но обеспечивают достаточно корректную информацию о состоянии сети. Узел-источник потока, в условиях подтверждаемого сервиса его передачи, может интерпретировать потери отправленных пакетов и рост RTT как неявные сигналы перегрузки сети или узла-приёмника. Однако, этот способ не всегда адекватно индицирует возникновение заторов; например, 209 высокий уровень потерь пакетов может быть следствием не перегрузки маршрутизатора, а плохого качества линий связи (характерно для беспроводных сред). Значительное увеличение полного времени доставки пакета (RTT) является хорошим сигналом возникновения перегрузки в сети, но измерение этого параметра с требуемой частотой и точностью является нетривиальной перегрузки процедур задачей. является управления Основным отсутствие на достоинством необходимости сетевых узлах; неявных сигналов реализации каких-то последние занимаются исключительно только распределением собственных ресурсов (задача арбитража) и, конечно, маршрутизацией. 4.4.2.2. Управление источником на основе явных сигналов обратной связи Наличие обратной связи между сетью и узлом-отправителем позволяет последнему адаптировать интенсивность генерируемого потока к изменяющейся сетевой обстановке. Собственно управление генерацией трафика реализуется посредством либо прямого адаптивного регулятора интенсивности отправки пакетов, либо на базе кредита, выдаваемого отправителю узлом получателем. Прямое управление Прямое управление интенсивностью — это превращение явного сигнала обратной связи в команду XOFF для передатчика узла. С целью уменьшения времени реакции системы (постоянная петли обратной связи) предпочтительны сигналы «назад», т.е. непосредственно к источнику. Возобновление передачи производится либо на основании получения команды XON от сети, либо на основании параметров регулятора (задания величины timeout). Недостаток этого способа регулирования потока очевиден – резкие колебания трафика, необходимость дополнительных сигналов от сети. Более интеллектуальным вариантом является регулирование межпакетных интервалов в генерируемом потоке. Это решает проблему 210 резких колебаний трафика, но требует повышения интеллекта сетевых узлов, поскольку информация о заполнении буферной памяти есть только у них. Некоторой компенсацией этого усложнения может быть возможность уменьшения размера буферной памяти при использовании таких методов управления потоками. Кредитное регулирование Кредитное управление потоками предполагает генерацию приёмным узлом сигнала обратной связи, содержащим величину объёма данных, который он может принять от источника потока в текущий момент времени. Такое информирование относися к группе явных сигналов обратной связи. Информация о кредите отражает размер свободного буферного пространства приёмного узла и она должна им периодически обновляться. Передающий узел контролирует использование предоставленного ему кредита и останавливает отправку данных при его исчерпании. С некоторыми упрощениями функционирование кредитного регулятора представлено на рис. 4.20 и может быть описано следующим образом. Буферное пространство приёмника Доставленные байты Байты в буфере приемника Доступное буферное пространство Байты в «линии» BR TBS «Кредит» CL Рисунок 4.20. Счётчики механизма кредитного управления потоком Приёмник: − Ведет счётчик BR (Byte Received) числа принятых байт; − Вычисляет значение переменной CL (Credit Limit): CL = BR + размер свободного буферного пространства; − Отправляет передатчику значение CL в специальном сообщении. 211 Передатчик: − Ведет переменную TBS (Total Bytes Sent), отражающую объём отправленных с момента его инициализации данных; TBS инкрементально пересчитывается при отправке очередного блока; − ЕСЛИ [TBS + размер очередного кадра ≤ CL] ТО отправляет очередной блок, ИНАЧЕ ждёт получения нового значения CL. Вообще говоря, значения переменных TBS и BR после приёма очередного блока должны совпадать. Однако, блоки данных могут приходить с ошибками или не приходить вообще, что будет вызывать рассогласование значений этих счётчиков. Для компенсации их ресинхронизации приёмник периодически переопределяет значение TBS, переданное ему передатчиком, значением BR и возвращает его передатчику с очередным управляющим кадром. В каноническом виде метод реализован в протоколах канального уровня сетей Fibre Channel, Infiniband и АТМ. Очевидно, что будучи реализованным на канальном уровне он исключает возможность отправки данных в объёме, превышающем возможности их приёма, и эффективно предупреждает возникновение локальных перегрузок. Но такое жесткое управление интенсивностью потока сопряжено с активным обменом узлами управляющими сообщениями и применение этого алгоритма ограничено сетями, где перегрузки должны быть практически исключены. В сетях TCP/IP механизм кредитного управления реализован на транспортном уровне протокольного стека. Оба взаимодействующих узла в заголовках отправляемых сегментов (поле "Window") указывают предельный размер объёма данных, который они могут принять без риска переполнения буферов. Эти данные используются для управления размером окна передачи и, следовательно, интенсивности генерируемых потоков. Напомним, что величина окна передачи — это объём данных, который передатчик может отправить подряд без остановки. Значение поля "Window" является, в этом случае, явным сигналом обратной связи приёмника. 212 4.4.2.3. Управление источником на основе неявных сигналов ОС Источник трафика, если он предоставляет подтверждаемый сервис, способен обнаружить перегрузку сети по чрезмерной задержке получения подтверждений доставки ранее отправленных блоков или по росту уровня их потерь. Эти события являются неявными сигналами обратной связи сети и источник реагирует на них уменьшением окна передачи. При этом, величина окна передачи определяется передающим узлом самостоятельно (с учётом ограничений, сообщаемых приёмной стороной) и регулируется адаптивно (нет сигналов перегрузки – окно передачи может увеличиваться). Регулирование окна передачи по потерям В условиях низкого уровня ошибок в физических средах передачи, потери пакетов могут служить неявным сигналом о перегрузке сетевых устройств коммутации, либо премного узла. Конечно, эта возможность существует только для подтверждаемого сервиса коммуникаций. На рис. 4.21 представлена упрощенная модель, в которой соединение использует один узел коммутации, обрабатывающий С пакетов/с. RTT=tR Узел А Узел B R1: Производительность С пакетов/с Буфер Z пакетов Рисунок 4.21. Маршрутизатор является «узким местом» канала Регулирование окна передачи W S подчиняется консервативной стратегии «увеличивать осторожно, уменьшать быстро». В соответствии с этим принципом, отправитель, пока потерь нет, увеличивает свое окно передачи по определённому закону; обнаружив потерю блока данных (истек тайм-аут получения подтверждения) – уменьшает размер окна до значения WS = 1. В непрерывном времени этот алгоритм описывается простым логическим выражением: 213 Если потерь нет То WS (t ) = 1 + ut Иначе W S = 1. Здесь t - текущее время, u – скорость роста величины окна передачи. Проанализируем характер изменение величины окна. Время реакции передатчика на потерю пакета равно времени тайм–аута, минимальное значение которого составляет время полного оборота ( t R ). За это время передатчик отправит WS пакетов. Маршрутизатор успевает обработать C ⋅ t R пакетов и еще Z пакетов могут находиться в его буферной памяти. Следовательно, величина окна передачи WS может расти до значения WS = Ct R + Z , не приводя к потерям. Потери возникают, когда буферная память полностью заполняется. Поскольку факт возникновения потери пакета будет зафиксирован передатчиком через время тайм-аута (RTO), то текущее значение окна передачи к этому моменту достигает значения WS max = Ct R + Z + u ⋅ RTO . От этого значения размер окна уменьшается до W = 1 (рис. 4.22). WS(t) WS max CtR +Z RTO ≥ t R tR 1 t RTO Рисунок 4.22. Регулирование размера окна передачи Результат не очень хорош – средняя величина окна передачи далека от значения, необходимого для номинальной загрузки канала; одновременно, WS max > WS доп = Ct R + Z , т. е. создаются условия для перегрузки сети. Ослабить влияние этих недостатков можно: − модификацией закона изменения величины окна, предупреждающего как его чрезмерное увеличение, так и чрезмерное уменьшение; − уменьшением времени обратной передатчика на факт потери кадра. 214 связи, т.е. времени реакции Эти усовершенствования реализуются в алгоритмах Тахо и Рино. Алгоритм Tахо (Tacho). Размер окна от единичного значения увеличивается достаточно быстро (интенсивная загрузка имеющейся пропускной способности), но при достижении некоторого порогового значения скорость роста окна существенно уменьшается (аккуратная дозагрузка остающейся свободной пропускной способности). Так, например, если в предыдущем цикле регулирования потеря кадра была зафиксирована при WS = WS max , то в следующем цикле величина W S быстро увеличивается от 1 до значения WS max / 2 (например, по закону W (t ) = 2t / t R ). После достижения указанного значения и до момента фиксации потери пакета окно WS растет медленно (например, на единицу за время полного оборота). При фиксации потери, окно уменьшается до единичного значения и цикл регулирования повторяется (рис. 4.23). «Медленный» старт WS WS max.1 Предупреждение перегрузки Зафиксирована потеря 8 7 WS max.2 6 5 WS sh.1 4 WS sh.2 3 2 1 tR 2tR 3tR 4tR 5tR 6tR 7tR 8tR 9tR 10tR t Рисунок 4.23. Эволюция окна передачи, регулируемого алгоритмом Тахо Описанный механизм регулирования получил название алгоритма медленного старта и предупреждения перегрузок (Slow start with congestion avoidance). На интуитивном уровне этим фазам можно дать следующую интерпретацию. Фаза медленного старта — это экспериментальная оценка «ёмкости» канала, т. е. количества блоков данных, которые одновременно могут находиться «в пути» между конечными узлами. Эта оценка должна 215 быть проведена аккуратно (отсюда отказ от установления величины окна сразу в значение Wmax ), но достаточно быстро (отсюда удвоение текущего значения окна за время RTT). Фаза предупреждения перегрузки — это очень аккуратная попытка заполнить канал максимально возможным числом блоков данных (пока ACK-и приходят можно канал «догружать»). Дальнейшим развитием алгоритма Tacho явилось ускорение повторной передачи. Сигналом для повторной передачи блока до истечения тайм-аута служит получение трех подтверждений с неизменным значением Rnext . Это сокращает время «простоя» передатчика и способствует лучшему использованию пропускной способности канала. Индикация потери блока данных по истечению таймера повторной передачи также сохраняется. Алгоритм Рино исключает фазу медленного старта и вводит быстрое восстановление окна передачи после потери. В каждом цикле алгоритм стартует при WS max / 2 , увеличивает окно до Wi (фаза предупреждения перегрузки) и сбрасывает его значение к Wi / 2 после фиксации потери пакета на основании трёх дубликатных ACK. При определении потери блока данных по признаку истечения тайм–аута величина окна устанавливается равной 1. В алгоритме Рино введено еще одно усовершенствование – быстрое восстановление размера окна передачи (Fast Recovery). Оно имеет целью уменьшить задержки пакетов в канале и повысить коэффициент использования его пропускной способности. Пусть потеря кадра произошла в момент, когда W S = M (рис. 4.24). Зафиксировав этот факт (по третьему АСК с неизменным Rnext = A ), отправитель уменьшает значение WS до (M/2) (а не до 1) и дублирует кадр А (предположение о SR-ARQ). Поскольку к этому моменту не на все ранее отосланные сегменты были получены подтверждения, то при получении каждого нового АСК с Rnext = A окно передачи увеличивается на 1 (быстрое восстановление окна передачи). Это позволяет передать еще ряд пакетов и более полно загрузить канал. Здесь 216 реализуется логика: «АСК получен, один блок успешно покинул сеть и можно послать еще один». WS=M/2 + k WS=M SA-1 Передатчик SA+1 WS=M/2 WS=M/2 SA+M-1 t Сегменты, отсылка которых была невозможна в Tahoe SA SA Приемник ACK (RNEXT=A) 3 дубликатных ACKА ACK (RNEXT=A) t ACK (RNEXT=A+M) Рисунок 4.24. Алгоритм управления Рино По завершению передачи блоков, разрешенных окном WS = M 2 + k , отправитель ожидает прибытия подтверждения повторной отправки сегмента А. Этот момент является границей фазы быстрого восстановления. После получения подтверждения на кадр с номером А значение окна передачи устанавливается равным WS =M/2 и далее реализуется режим регулирования, предотвращающий возникновение перегрузок (т. е. режим медленного роста величины окна). В случае невозможности повторной передачи утерянного сегмента до истечения тайм-аута (получено менее 3 дубликатных АСК) окно передачи устанавливается в 1. Достоинством алгоритма Рино, в сравнении с Тахо, является лучшее использование пропускной способности канала в фазе повторной передачи и почти полное исключение фазы медленного старта. Транспортный протокол ТСР в своих ранних версиях для регулирования окна передачи использовал алгоритм Тахо (медленный старт, предотвращение перегрузки и быстрая повторная передача). В последующих версиях ТСР применяется алгоритм Рино. Регулирование окна передачи по задержке Алгоритмы Тахо и Рино изменяют значение окна передачи, реагируя на факт возникновения перегрузки (блоки данных начинают уничтожаться), но они не индицируют состояния, близкие к перегрузке. Алгоритм Вегас регулярно измеряет ожидаемую и действительную производительности 217 соединения и на основе их сопоставления регулирует величину окна передачи так, чтобы объём данных, подлежащих буферизации в сети, оставался в «разумных» пределах. При возникновении потери блока данных текущая величина окна передачи уменьшается в два раза. Пусть в модели рис. 4.21 при низкой интенсивности потока и, следовательно, отсутствии необходимости буферизации пакетов маршрутизатором, время полного оборота RTT = t0 . Алгоритм оценивает эту величину как min RTT j , 1 ≤ j ≤ WS . Здесь предполагается, что какой-то блок, j из числа переданных по соединению при малой интенсивности их генерации, будет подтвержден через время RTT ≈ t0 . В i-м цикле регулирования в соединение будет отправлено WS , i блоков данных по L байт; ожидаемая производительность канала составит η exp = WS , i L t0 . На основании измерения времени прихода подтверждений на эти блоки вычисляется текущее значение RTTi = t R . Его значение, как правило, больше t0 (обратное является свидетельством необходимости обновления оценки t0 ). Соответственно, текущая производительность соединения составляет η act = WS , i L tR . Разница значений ηexp и η act отражает факт буферизации сетью какой–то части отправленных данных и может служить сигналом регулирования окна передачи. Для этого может быть использован следующий простой алгоритм. Ш1. Установить значения «порогов» α и β объёма буферизируемых сетью данных. Ш2. Вычислить t0 218 Ш3. Вычислить ∆ = ηexp − ηact Ш3. Если ∆ ⋅ t R ≥ β То WS , i +1 = WS , i − 1 Иначе Если ∆ ⋅ t R ≤ α То WS , i +1 = WS , i + 1 Иначе WS , i +1 = WS , i Ш4. Конец. Значения порогов α и β отражают допустимые границы числа буферизированных данных в соединении. Например, если установить α = 20 L и β = 40 L , то алгоритм будет поддерживать не менее 20 и не более 40 протокольных блоков потока в буферах сетевого соединения, что с одной стороны обеспечивает достаточную утилизацию ресурса соединения, а с другой – не допускает возникновения потерь и перегрузки. Заметим также, что этот алгоритм при малых отличиях порогов стабилизирует задержку передачи, что весьма важно для приложений с изохронным характером трафика. Вместе с тем, значения этих параметров существенно влияют на общую производительность соединения (рис. ), а вычисление значений t 0 и tR с достаточной точностью требует наличие таймеров с высоким разрешением. 4.4.3. Управление очередями Необходимость буферизации протокольных блоков данных (далее, пакетов) возникает, когда сетевой узел получает их быстрее, чем он может обработать и отправить их через исходящий канал. «Избыточные» пакеты помещаются в специальную область оперативной памяти, называемую очередью. Оттуда они считываются в соответствии с определенными правилами и направляются в выходную линию. Такое промежуточное хранение пакетов позволяет избежать потерь данных при кратковременных вспышках интенсивности трафика, сформировать сигнал обратной связи для управления потоками, организовать дифференцированное обслуживание различных потоков. Для реализации перечисленных функций с каждым интерфейсом маршрутизатора связывается одна или несколько очередей. 219 Механизм их обслуживания (планировщик очередей) определяет порядок обработки буферизированных пакетов, а при необходимости, и порядок их уничтожения. Существуют несколько способов обслуживания очередей. 4.4.3.1. FIFO и приоритетные очереди Простейшим механизмом обслуживания буферизированных пакетов является очередь с дисциплиной «Первый пришел – первый ушел» (First-In, First-Out, FIFO). В этом случае все пакеты помещаются в одну общую очередь и обрабатываются последовательно в порядке прибытия (рис 4.25.а). Пекеты, приходящие в моменты полной занятости буферной памяти, уничтожаются. Прибывающие пакеты Буфер Если буфер заполнен – пакеты уничтожаются а) Выходная линия Прибывающие пакеты б) Буфер Выходная линия Пакеты высшего класса обслуживания уничтожаются, если буфер заполнен Пакеты низшего класса обслуживания уничтожаются при достижении порога Рисунок 4.25. Модель очереди FIFO без приоритезации (а) и с приоритезацией (б) Такая организация очередей имеет несомненное преимущество простоты реализации. Однако, ей сопутствуют ряд недостатоков. Время обработки, его вариации и уровень потерь пакетов в FIFO-очереди зависят от интенсивности их поступления и размеров. Наличие потока высокой интенсивности, который мгновенно заполняет буферную память, приводит к монополизации очереди FIFO и делает недоступным соответствующий порт маршрутизатора для всех остальных потоков. Кроме этого, поскольку в состоянии перегрузки уничтожаются пакеты разных потоков, то все «пострадавшие» приложения почти синхронно выполняют их повторную 220 передачу, что вызывает импульсное увеличение трафика на данном участке сети. Такие синхронизированные импульсы трафика усугубляют состояние перегрузки сети. Очевидно, что посредством простой FIFO-очереди невозможно обеспечить разные уровни обслуживания разных потоков. Очередь FIFO может быть модифицирована для предоставления различного уровня обслуживания пакетов, содержащих признак приоритета (приоритетная очередь). Этот механизм предполагает разделение входного трафика на два класса (по наличию в пакете признака приоритета, по типу протокола, по адресу источника, по типу приложения и т. п.). При достижении определенного порога загруженности буфера пакеты более низкого класса будут уничтожаться, сохраняя тем самым возможность обработки пакетов более высокого класса обслуживания (рис. 4.25.б). Последние будут обрабатываться до момента полной загруженности буфера. Другим вариантом решения задачи дифференцирования классов обслуживания пакетов является организация нескольких очередей FIFO (по одной для каждого класса обслуживания), конкурирующих за доступ к ресурсам (CPU и пропускная способность выходного порта) марщрутизатора. Буфер заполнен – пакеты уничтожаются Буфер Прибывающие пакеты высокого приоритета Прибывающие пакеты низкого приоритета Буфер Переключается, если высокоприоритетный буфер пуст Выходная линия Буфер заполнен – пакеты уничтожаются Рисунок 4.26. Модель очереди FIFO с приоритезацией на основе отдельных буферов Как показано на рис 4.26, выходная линия в любой момент является доступной для пакетов из буфера, соответствующего самому высокому классу обслуживания (например, пакетам потока, чувствительного к 221 величине задержек) и лишь когда он пуст – обслуживается буфер низшего приоритета. Размер буферов в такой архитектуре может быть различным, что позволяет удовлетворить требования к уровню вероятности потери пакетов. Ресурсы маршрутизатора всегда ограниченны и ситуация, когда разные информационные потоки вынуждены конкурировать за доступ к ним, является типичной. обеспечения разных При этом, классов рассмотренные обслуживания выше не два решают варианта проблему «справедливого» распределения ресурсов. Действительно, при достаточно высоком трафике высшего приоритета остальные потоки могут вообще не получить доступ к ресурсам маршрутизатора; не решается также проблема распределения ресурсов между потоками одного класса сервиса, что приводит к монополизации их (ресурсов) более «жадными» приложениями. 4.4.3.2. «Справедливая» очередь Дисциплина «справедливой очереди» нацелена на преодоление ассиметрии распределения ресурсов маршрутизататора. Пусть каждый поток обслуживается своей очередью. В идеальной системе (поток данных рассматривается как некая непрерывная и всегда существующая субстанция) пропускная способность выходной линии (С бит/сек) может быть разделена поровну между всеми очередями посредством их циклического подключения на строго определенные и равные промежутки времени (рис. 4.27). Такая «карусельная» дисциплина обслуживания в англоязычной литературе носит название round-robin fashion. При наличии n очередей, каждая из них получает возможность передавать свои пакеты в выходную линию со скоростью С/n бит/с. Эффективная скорость передачи может быть и выше, поскольку некоторые очереди становятся время от времени пустыми, и в это время могут передаваться данные из других очередей. Такая организация очереди предупреждает монополизацию ресурсов выходной линии «жадными» потоками. Размер буфера для каждого потока может быть 222 выбран таким, чтобы удовлетворялись требования к уровню потерь и вариации задержек пакетов конкретного потока. Поток 1 Сброс при заполнении Очередь 1 Подключает линию циклически на равные интервалы времени Очередь 2 Выходная линия Поток 2 Сброс при заполнении Поток n C бит/сек ……………. Очередь n Сброс при заполнении Рисунок 4.27. Модель «справедливой» очереди Однако, рассматриваемая очередь является справедливой в предположении идеальности (непрерывности) входных потоков. В этом случае, пропускная способность выходной линии действительно равномерно распределяется между всеми непустыми очередями. В силу же дискретной природы потока и различия размеров составляющих его пакетов, обеспечить строгую «справедливость» не удается. Если каждая из входных очередей циклически получает доступ к выходной линии на равные промежутки времени, в течение которых может быть передано строго определенное количество бит, то длинный пакет не будет передан, а при передаче короткого пакета часть времени доступа к линии этой очередью будет потрачена впустую. Поэтому, обслуживание очередей ведётся на пакетной основе. Однако, в случае неравенства средних размеров пакетов разных приоритетов распределение пропускной способности выходной линиии не будет справедливым. Например, если средний размер пакетов первой очереди вдвое больше средней величины пакетов второй очереди, то при достаточной длине очередей эффективная пропускная способность выходной линии для первого потока будет вдвое больше, чем для второго. 223 Определенную возможность ослабления такой несправедливости предоставляет выбор очередности обслуживания очередей. Для этого, каждый пакет в очереди снабжается меткой прогнозируемого времени окончания его обслуживания, и очередность обслуживания входных буферов в каждом цикле определяется значениями этих меток по принципу «пакет с меньшим значением метки обслуживается первым». Такую дисциплину обслуживания можно назвать «пакетная справедливая очередь». Рассмотрим процедуру вычисления метки. Пусть существуют n потоков, каждый из которых обслуживается отдельной очередью на побитной основе (модель, максимально близкая к непрерывному потоку). Циклом обслуживания назовем период времени, в течение которого каждая очередь обслуживается по одному разу, а R(t) – число циклов обслуживания n очередей, реализованных за время t. Будем считать, что k-й пакет i-го потока прибывает в свою пустуют очередь в момент tki и размер этого пакета равен L(i,k) бит. Этот пакет на побитовой основе будет обработан за L(i,k) циклов, т.е в момент t*, когда число циклов обслуживания станет равным R (t ∗ ) = R (t ki ) + L(i, k ) = F (i, k ) . Величина F(i,k) будет использована как финишная метка обслуживания пакета. Если пакет прибывает не в пустой буфер, то F (i, k ) = F (i, k − 1) + L(i, k ) . Заметим еще раз, что величина F(i,k) не определяет реальное время завершения обработки k-го пакета; она служит лишь признаком очередности, в которой будут обслуживаться очереди в пределах одного цикла. В качестве примера рассмотрим буфер из двух очередей. В каждую из них прибывают по одному пакету: в первую очередь - пакет единичного размера, а во вторую – пакет удвоенного размера (рис. 4.28). В идеальной «карусельной» системе обслуживание очередей производилось бы со скоростью ½ сек-1 в течении времени пока обе обе очереди имеют данные 224 (т. е. на интервале от 0 до 2 единиц времени) и со скоростью 1 сек-1 – на интервале от 2-й до 3-й единиц времени (рис. 4.28.а). Таким образом, поток с короткими пакетами передавался бы с эффективной скоростью ½ с-1, а поток с более динными пакетами – со скоростью 2/3 с-1; показатель асимметрии распределения ресурса K UNF = 11/ 3 . Размер пакетов в очередях Больший пакет ожидает обслуживания Размер пакетов в очередях 2 2 KUNF = 11/3 KUNF = 11/2 1 1 1 2 3 1 t а) Побитовое обслуживание 3 2 t б) Пакетное обслуживание Рисунок 4.28. «Справедливое» обслуживание очередей Для пакетной дисциплины обслуживания потоков значения финишних меток будут равны F(1,1)= R(0)+1=1 и F(2,1)= R(0)+2=2. Поскольку F(1,1) a 1 а) б) ' Gmax Gmax 1 G Рисунок 5.5. Типичные зависимости производительности (а) и задержки передачи (б) от нагрузки в сети со случайным доступом к среде Действительно, если рост параметра a связан с уменьшение величины кадра, то следствием этого будет увеличение числа попыток получения доступа к среде в единицу времени; следовательно, будут увеличиваться как 242 доля времени, затрачиваемого на доступ к каналу, так и число коллизий. Соответственно, среднее время доставки кадра достигнет своих предельных значений при меньших значениях предлагаемой нагрузки. Если же рост параметра a связан с увеличением битовой скорости интерфейса (R), то при неизменных остальных параметрах это увеличивает долю времени простоя ( 2t p ) в общей длительности цикла передачи кадра L R + 2t p , что также приводит к увеличению нормированного среднего времени передачи кадра. 5.1.1.2. Алгоритм ALOHA Впервые метод случайного доступа к среде передачи был реализован в компьютерной сети университете штата Гавайи (США). Кампус университета располагался на нескольких островах архипелага, и терминальные пункты вычислительных лабораторий кампуса необходимо было соединить с хост-компьютером. Для этого был использован общий радиоканал, а каждому терминалу разрешалось начинать передачу в любой момент, когда у него появлялся кадр. Поскольку терминалы находились на значительном взаимном удалении, то контролировать состояние друг друга и, следовательно, занятость канала они не могли. Это имело два следствия. 1. Любой терминал мог начать свою передачу в период передачи кадра другим терминалом, что приводило к искажениям обоих кадров в точке приема. 2. Индикация факта возникновения/отсутствия коллизии передающими терминалами способом оказывалась получения невозможной. передатчиком Поэтому, информации единственным о «судьбе» отправленного им кадра оставалась отправка принимающим узлом кадра-подтверждения. Неполучение его передатчиком в определенном интервале времени интерпретировалось как потеря переданного кадра. Очевидно, что пока интенсивность генерации кадров терминалами оставалась относительно невысокой, вероятность их «столкновений» в месте приёма была малой, и система работала вполне удовлетворительно. Однако, 243 рост интенсивности трафика неизбежно вел к росту вероятности коллизий, увеличению числа повторных передач и к падению производительности сети. В этих условиях, вопрос о предельно допустимых нагрузках в таких системах приобрёл очевидную актуальность. Н. Абрамсон (1971) провел анализ производительности алгоритма ALOHA, который в основных чертах излагается ниже. Пусть размер кадров постоянен и равен L, а битовая скорость их передачи равна R. Тогда, время передачи одного кадра составит X = L R . Интервал уязвимости Фиксация факта потери Случайная задержка Тайм-аут t0 -X t0 t0 +X Повторная передача tout > t0 +X+2tр tout +B t Рисунок 5.6. К анализу эффективности алгоритма ALOHA На рис. 5.6 приведен один из возможных сценариев, когда после передачи кадра выдерживается тайм-аут длительностью, превышающей X + 2t р , и при отсутствии подтверждения успешной доставки, со случайной задержкой В секунд производится повторная передача кадра. Из рис. 5.6 хорошо видно, что вероятность передачи кадра без коллизии равна вероятности отсутствия передачи двумя, тремя и т. д. терминалами в интервале времени [ t0 − X , t0 + X ], т. е. в интервале, равном 2Х. Вычисление этой вероятности требует определенных допущений о статистических характеристиках процесса поступления кадров. Пусть S – среднее количество кадров, успешно переданных в сети за время X = L / R . Значение S > 1 означало бы возможность одновременной передачи в среде нескольких кадров без их коллизий, что невозможно. Поэтому, S ≤ 1 . Для передачи этих S кадров, время канала затрачивалось и на повторные передачи «испорченных» кадров, т. е., среднее число кадров, переданных в канале за время X, будет больше S. Рассматривая величину G как нагрузку среды передачи, величину S можно трактовать как показатель 244 уровня «полезного» ее использования (производительность протокола доступа). В общем случае, взаимосвязь величин S и G установить трудно. Вместе с тем, есть достаточно оснований считать, что поток кадров, поступающих в MAC-модули сетевых узлов, является пуассоновским случайным процессом. Допускается также, что и поток повторно передаваемых кадров является пуассоновским. Вообще говоря, это не так, поскольку повторные передачи являются зависимыми случайными событиями. Тем не менее, можно считать, что допущение о пуассоновском характере потока вторичных передач справедливо при умеренной их интенсивности. Это позволяет рассматривать и полный поток кадров, поступающих в среду передачи, пуассоновским со средним значением интенсивности G/X. Тогда, среднее число кадров, поступающих в канал за время уязвимости 2X составит 2G, а вероятность поступления в канал за это же время k кадров будет равной ( 2G )k − 2G , e P[k ] = k! k = 0,1,2.... . Кадр, передача которого началась в момент t 0 , будет успешно получен, если за время [ t0 − X , t0 + X ] другими станциями не будет отправлено ни одного кадра. Вероятность такого события вычисляется из приведенного выше выражения при k = 0 . Поскольку производительность S равна предлагаемой нагрузке, умноженной на вероятность отсутствия коллизии, то среднее количество успешно доставленных получателю кадров за время X составит S = P[0]G = e −2G G . (5.2) Зависимость S(G) представлена на рис. 5.7 (кривая «чистая ALOHA»). Экстремум этой функции, очевидно, соответствует значению G = 0.5 и равен 0.184. Это очень скромная величина, но не будем забывать, что она достигнута при минимальных затратах на управление доступом к каналу. 245 Рисунок 5.7. Производительность алгоритмов ALOHA как функция нагрузки канала Важной характеристикой алгоритма является среднее время доставки кадра. Среднее число попыток, предпринимаемых для пересылки одного кадра, составляет n= G = e 2G . S (5.3) Следовательно, число неудачных попыток n− = e 2G − 1 . Считая, что время распространения сигнала от передающей станции к приемной равно t р , для среднего времени доставки кадра можно записать очевидное соотношение E[t d ] = X + t р + (e 2G − 1)( X + 2t р + B). Соответственно, нормированное к длительности передачи кадра, время доставки будет tр tр B   E[td ] B  = 1 + + (e 2G − 1)1 + 2 +  = 1 + a + (e 2G − 1)1 + 2a +  . X X X X X   (5.4) Полученное выражение показывает, что время доставки может расти экспоненциально с ростом нагрузки (см. рис. 5.5) и большие значения параметра a, будут негативно сказываться на времени доставки кадра. Производительность алгоритма ALOHA можно заметно увеличить, если дополнить его ограничением, позволяющим станциям начинать 246 передачу своих кадров не в произвольный момент времени, а только в моменты, кратные длительности кадра, т. е. в моменты X, 2X, 3X, и т. д. Это дало основание назвать такой алгоритм «тактированная ALOHA» (дискретная, синхронная ALOHA). Эта простая мера позволяет сократить интервал уязвимости (рис. 5.5) вдвое, т.к. в момент t 0 в канал отправятся кадры, сформированные за время (t 0 – Х). Соответственно, уменьшается и вероятность коллизий кадров в канале P[k ] = (G )k e −G , k! k = 0,1,2.... , а производительность канала будет описываться выражением S = P(0)G = Ge −G . Экстремум такой функция S(G) (5.5) достигает при G=1 и ее максимальное значение равно 0.368 (рис. 5.7). Это примерно вдвое больше, чем для «чистого» алгоритма ALOHA. Таким образом, введение большей упорядоченности в систему (дополнительные усилия по управлению доступом к среде) сказалось благоприятно на ее производительности. «Цена» такой упорядоченности — необходимость стабильных тактовых генераторов и общесетевой системы их синхронизации. Низкие значения максимально достижимой производительности при рассмотренном методе доступа к среде является следствием почти полной асинхронности поведения передатчиков станций, отсутствия возможности взаимной их координации. В локальных сетях такая координация поведения станций оказывается возможной, что и позволяет повысить эффективность используемых в них алгоритмов случайного доступа. 5.1.1.3. Множественный доступ с контролем несущей В сетях, где расстояния между станциями достаточно малы (LAN, SAN), возникает возможность контроля ими состояния занятости общей среды передачи (эта операция получила название «контроль несущей»). Кроме этого, в проводных линиях (медный и оптический кабели) 247 посредством непрерывного мониторинга их аналогового состояния можно фиксировать и факт коллизии. Эти обстоятельства позволяют существенно, в сравнении с алгоритмом сократить ALOHA, период уязвимости. Действительно, как было показано в разделе 5.1.1.1, период времени, в течение которого может возникнуть коллизия (период уязвимости), в таких условиях не превышает 2t p с момента начала передачи. 5.1.1.3.1. Алгоритмы множественного доступа с контролем несущей В общем случае, любая реализация множественного доступа с контролем несущей (МДКН) должна обеспечивать: − индикацию состояния среды (занята/свободна/коллизия), − выбор момента начала передачи очередного кадра и − управление поведением станции при обнаружении коллизии. Существующие алгоритмы метода МДКН отличаются, главным образом, логикой управления поведением станции, имеющей кадр для передачи, в условиях обнаружения занятости канала. Настойчивый алгоритм МДКН (рис. 5.8) предусматривает, что станция, обнаружив занятость среды, будет продолжать непрерывно «слушать» ее и начнет передачу своего кадра в момент освобождения среды. Ясно, что если в состоянии ожидания доступа к среде находились несколько станций, то возникновение коллизии неминуемо. Контроль среды Занята? Да Нет Передача Колл-я? Да Нет Откат ts Обратный счет от ts ts=0 ? Нет Рисунок 4.8. Информационная схема настойчивого алгоритма МДКН 248 Да Для вовлеченные уменьшения в неё, вероятности выполняют повторных специальную коллизий, станции, процедуру «отката», результатом которой является вычисление каждой из них длительности задержки (t s ), до истечения которой они не проводят прослушивание среды. Время ожидания является псевдослучайной величиной, равномерно распределенной в некотором интервале. В целом, настойчивые алгоритмы характеризуются довольно высоким уровнем вероятности коллизий даже при не очень высокой интенсивности трафика. Ненастойчивый алгоритм МДКН (рис. 5.9) старается уменьшить вероятность возникновения коллизии. Если станция обнаружила занятость канала, она сразу выполняет «откат» и вычисляет время задержки до начала следующей попытки прослушивания среды (t s ). Благодаря немедленному выполнению отката и псевдослучайному характеру выбора значения t s , риск возникновения коллизий уменьшается. В сравнении с настойчивым алгоритмом МДКН, производительность этого алгоритма при высоких нагрузках выше, но среднее время задержки передачи (t d ) в условиях даже низких нагрузок оказывается большим. Контроль среды Занята? Нет Передача Колл-я? Да Откат ts Обратный счет от ts Нет Да ts=0? Откат ts Обратный счет от ts ts=0? Да Нет Да Нет Рисунок 5.9. Информационная схема ненастойчивого алгоритма МДКН Алгоритм МДКН, комбинирующий элементы рассмотренных выше подходов, получил наименование р-настойчивого (рис. 5.10). Обнаружив, что среда занята, станция продолжает её прослушивание. Зафиксировав, что среда свободна, станция с заданной вероятностью р начинает передачу кадра и с вероятностью (1-р) делает паузу длительностью t p , по истечению 249 которой вновь начинает прослушивать среду. Если среда остается свободной, то с вероятностью p передача кадра начнется и с вероятностью (1-р) будет отложена еще на t p . Так продолжается пока кадр не будет передан. Этот алгоритм стремится распределить во времени попытки начала станциями своих передач и увеличивает вероятность того, что начавшая передачу станция благополучно ее завершит. Контроль среды Занято? Да Нет p Передача Колл-я? 1-p Да Нет Задержка на tp Откат ts Обратный счет от ts ts=0? Да Нет Рисунок 5.10. Информационная схема p-настойчивого алгоритма МДКН Представленные на рис. 5.11 зависимости S(G) позволяют сравнить производительность настойчивого и ненастойчивого алгоритмов МДКН. Параметром графиков является значение нормированной задержки распространения сигнала в среде передачи a = t р R / L = t р / X . а) б) Рисунок 5.11. Производительности настойчивого (а) и ненастойчивого (б) алгоритмов МДКН Кривые рис. 5.11 иллюстрируют весьма высокую чувствительность алгоритмов случайного доступа к величине задержки распространения 250 сигнала «из конца в конец» (интервал уязвимости). Так, при значении а = 1, максимальная производительность канала не превышает 16% его пропускной способности, в то время, как при a = 10 −2 производительность алгоритма уже достигает 81%. При малых значениях параметра а как настойчивые, так и ненастойчивые алгоритмы, благодаря механизму контроля состояния среды, позволяют получить относительно высокую (в сравнении с алгоритмом ALOHA) производительности. Но с увеличением этого параметра максимально достижимая производительность алгоритмов МДКН заметно падает. Отметим также, что ненастойчивые алгоритмы МДКН имеют более широкий диапазон нагрузок, при которых их производительность остается приемлемой. Быстрое прекращение передачи кадров, вовлеченных в коллизию, сокращает время непроизводительной занятости среды и, тем самым, повышает эффективность MAC-алгоритма. Используемый в сетях Ethernet алгоритм множественного доступа с контролем несущей и обнаружением коллизий (МДКН/ОК, CSMA/CD) реализует стратегию p-настойчивого доступа с быстрым прекращением передачи коллизионных кадров (рис .5.10). 5.1.1.3.2. Предельная эффективность МДКН При использовании МДКН и предположении отсутствия коллизий среда передачи может находиться в одном из трех состояний: занята передачей кадра, свободна, захватывается какой-либо из станций. Минимальное время захвата среды (время, необходимое для фиксации того, что никакая другая станция не начала передачу), как отмечено выше, составляет не меньше 2t p . Анализ производительности алгоритма ALOHA показал целесообразность «привязки» доступа к среде к началу определённых временных интервалов. В данном случае, вполне естественно значения такого тайм-слота принять равным 2t p . Пренебрегая особенностями 251 механизма отката, вычислим среднее время, затрачиваемое станцией на захват канала. Пусть n станций совместно используют среду передачи и с вероятностью р каждая из них может начать передачу кадра в интервале 2t p . Тогда вероятность успешного захвата канала одной из станций в течение одного произвольного тайм-слота определится выражением P+ = n ⋅ p (1 − p ) n −1 . Множитель n в этом выражении учитывает равновероятность захвата среды одной из n станций. Найдем экстремум зависимости P+ ( p ) , т. е. p∗ = arg max P+ . dP+ = (1 − p) n − 2 (1 − pn) = 0 . dp Отсюда p∗ = 1 . Соответственно, n P+ max  1 = 1 −   n n −1 1 . n →∞ e → (5.6) Минимальное значение n = 2 и P+ max (2) = 0.5 . Таким образом, P+ max не очень сильно падает с ростом n (но при условии уменьшения интенсивности попыток передачи каждой из станций). Из этого следует, что даже при очень большом числе станций вероятность захвата канала одной из них в течение одного тайм-слота не становится слишком малой. Возможно, что за время одного тайм-слота среда не будет захвачена ни одной из станций. Вероятность того, что для захвата канала какой-либо станцией сети потребуются j тайм-слотов (j попыток), составляет P[ j ] = (1 − P+ max ) j −1 ⋅ P+ max , j = 1,2,3,... . (5.7) Соответственно, среднее число тайм-слотов, необходимое для захвата канала, определится выражением ∞ E[ j ] = ∑ j (1 − P+ max ) j −1 ⋅ P+ max = j =1 252 1 P+ max . (5.8) Здесь использовано соотношение ∞ 1 ∑ (k + 1)q k = (1 − q) 2 . k =0 Таким образом, среднее количество попыток захвата канала, необходимых для передачи кадра, даже при больших n, не превышает E[j] = e = 2.718. Еще раз обратим внимание на то, что эта оценка справедлива лишь в предположении асимптотического поведения станций ( p ∗ = n −1 ) и наличия у них возможности предпринимать попытки доступа в каждом тайм-слоте (особенностями механизма «отката» пренебрегли). В реальных условиях, время захвата канала будет зависеть от числа станций, интенсивности генерации ими кадров и особенностей используемых механизмов «отката». Полученная оценка длительности состояния захвата среды позволяет оценить предельную производительность алгоритмов МДКН. Она будет достигнута при условии, что станции всегда имеют кадры для передачи (состояния захвата среды будут следовать непосредственно за состояниями передачи кадров). Пусть Е[Х] — среднее время передачи кадра; среднее время захвата канала, как показано выше, не превышает 2t p e , а время, необходимое для того, чтобы все станции убедились, что очередная передача кадра завершена, не превышает t p (минимальное время индикации состояния незанятости среды). Тогда, предельная эффективность использования среды передачи определится выражением: η max = 1 E[ X ] = . E[ X ] + t p + 2t p e 1 + (2e + 1)a (5.9) Ясно, что величина a= tp E[ X ] = tp E[ L] / R = d /V dR = , E[ L] / R VE[ L] являясь функцией скорости интерфейса (R), диаметра сети (d), свойств среды передачи (V) и средней длины кадра (E[L]), может изменяться в широких пределах. Соответственно, эффективность использования среды изменяется от величин, близких к 1 при а = 0.01, до 0.17 при а = 1. 253 На рисунке 5.12 приведены зависимости η max (a ) для рассмотренных алгоритмов случайного доступа к среде, полученные с учетом их особенностей (среднее время захвата канала). Из приведенных графиков хорошо видна желательность ограничения параметра а значениями из интервала [0.01, 0.1]. ηmax p – настойчивый 1,0 ненастойчивый настойчивый 0,8 0,6 ALOHA 0,4 0,2 0,01 0,1 1,0 a Рисунок 5.12. Предельная производительность алгоритмов множественного доступа В заключение отметим, что механизм случайного отката и случайный характер возникновения коллизий неблагоприятно сказываются на изохронности потока кадров, поскольку величина задержки передачи испытывает значительные случайные колебания. В следующем разделе будет рассмотрен детерминированный метод доступа к среде передачи, обеспечивающий более стабильную задержку передачи. 5.1.2. Регулярный доступ к общей среде передачи Существует несколько методов управления, обеспечивающих регулярный доступ станций к совместно используемой среде передачи. Мы рассмотрим один из них, а именно, метод маркерного доступа, который нашел наиболее широкое применение в ЛС кольцевой топологии. Компьютеры в такой сети подключаются посредством двухпортовых интерфейсных устройств (устройств подключения к магистрали, Trunk Coupling Unit, TCU), которые последовательно соединены между собой линиями передачи (рис. 5.13). 254 Интерфейсные устройства выполняют, в частности, роль повторителей. В режиме прослушивания сети каждый бит, поступающий на входной порт интерфейса, копируется в буфер и транслируется на выходной порт. Ясно, что на выходе интерфейса каждый бит, воспроизводится с задержкой, равной, как минимум, длительности битового интервала. Скопированные интерфейсом биты, в их определенной совокупности, подвергаются проверкам, позволяющим определить тип кадра в кольце, адрес его назначения и т.п. шина данных компьютера K2 K1 Ключ замкнут +, разомкнут – Кольцо: К1 +, К2 –, К3 – Приём: К1 –, К2 +, К3 – Передача: К1 –, К2 –, К3 + K3 сетевой интерфейс, TCU Рисунок 5.13. Логическая схема сети с кольцевой топологией Входной поток бит проверяется, прежде всего, на предмет обнаружения в нем специальной последовательности, называемой маркером (token). Маркер является кадром управления MAC–протокола; он может находиться в двух состояниях: «свободен», «занят». Если сетевой интерфейс получает маркер в состоянии «Занят», то это означает, что за ним будут следовать биты кадра, отправленного одной из станций. После приема определенной части заголовка кадра вычисляется его адрес назначения и если он совпадает с адресом подключенной к этому интерфейсу станции, то этот кадр бит за битом копируется в память сетевого узла. В противном случае интерфейс просто копирует биты с входного порта в выходной. Получение интерфейсом маркера в состоянии «Свободен» предоставляет право станции передать в кольцо свои кадры. Если в этом есть 255 необходимость, то интерфейс изменяет состояние маркера на «Занят», отправляет его далее в кольцо и переключается в состояние отсылки кадра «своей» станции. В сетях с большим диаметром кольца (несколько километров и более) время обращения бита по кольцу может превосходить время, необходимое интерфейсу для инжекции кадра в кольцо; следовательно, существует потенциальная возможность «разместить» в кольце несколько кадров (это могут быть кадры одной станции, или кадры разных станций). В таком режиме, в интервале времени, необходимом для инжекции кадра в кольцо, на входной порт станции могут поступать биты кадра, ранее отправленного в кольцо другой станцией. Они буферизируются и после завершения передачи станцией «своего» кадра, отправляются по кольцу далее (эта буферизация и является источником случайной компоненты задержки доставки кадра). Если же время передачи бита по кольцу меньше времени инжекции кадра (что характерно для относительно небольших сетей), то на входе интерфейса передающей станции появятся ранее инжектированные ею биты этого же кадра (т.е. все кольцо оказывается заполненным битами одного кадра). Повторная передача их в кольцо редко бывает необходимой и такие биты должны выводиться из кольца. Таким образом, кроме механизмов инжекции кадра и продвижения его по кольцу, необходим и механизм удаления кадра из кольца. Здесь существует два варианта действий. Первый из них возлагает эту задачу на станцию назначения. Второй, более предпочтительный, позволяет кадру возвратиться к отославшему его интерфейсу. Такая процедура решает задачу подтверждения доставки кадра, а при необходимости, и повторной его передачи с минимальной задержкой. Механизмы управления кольцом включают правила генерации маркеров, управления их состоянием, восстановления в случае потери и т. д. Именно правилами освобождения маркера станцией, захватившей его, определяются три возможных режима работы маркерного кольца. 256 1. Первый режим предусматривает генерацию маркера в состоянии «свободен» сразу же после передачи станцией последнего бита своего кадра. Это минимизирует время, требуемое для получения свободного маркера другой станцией, и позволяет, если кадры короткие и кольцо большое, инжектировать в него несколько кадров, которые локализуются в разных участках кольца. Очевидно, что в таком режиме требуется наличие в кольце нескольких маркеров; поэтому, он и получил название многомаркерного. 2. Во втором режиме, – одномаркерном, – свободный маркер генерируется станцией, инжектировавшей в кольцо кадр, сразу по прибытию на её входной интерфейс первого бита этого кадра, т. е. до удаления кадра из кольца. Очевидно, что в этом режиме маркер совершает полный оборот по кольцу, находясь в состоянии «Занят». Отличия первого и второго режимов работы кольца проявляются, когда время кольца больше времени передачи кадра. В такой ситуации будет возникать некоторый временной интервал между передачей в кольцо последнего бита кадра и появлением в кольце свободного маркера. Этот режим допускает одновременное наличие в кольце битов двух кадров, но лишь одного маркера. 3. Третий режим, обычно называемый однокадровым, также является одномаркерным, но предполагает освобождение маркера лишь после удаления станцией-отправителем всех битов переданного ею кадра; в этом случае возникает возможность проверки целостности прошедшего по кольцу кадра. Если ошибки обнаруживаются, то производится повторная передача этого кадра. Ясно, что такой алгоритм обеспечивает наличие в кольце в любой момент лишь одного кадра, а маркер совершает полный оборот по кольцу, находясь в состоянии «Занят». Все технологии маркерного доступа тем или иным образом ограничивают возможность вести передачу станции, которая завладела маркером. Эти ограничения накладываются либо на число кадров, которые могут быть переданы (например, только один кадр), либо на время, в течение которого станция может вести передачу. Так, спецификация IEEE 802.5 257 (Token Ring, 4 и 16 Mбит/с) ограничивает время передачи 10 мс. Конечно, эти ограничения оказывают свое влияние на производительность алгоритма доступа и задержки передачи кадров. Получим выражения для оценки предельной производительности маркерного метода доступа к среде в определённых выше трех режимах. При этом будем считать, что только один кадр может быть передан станцией в кольцо за время владения маркером. Обозначим: τ ′ - полное время кольцевой задержки (секунд), a′ - нормированное время кольцевой задержки. τ ′ =τ + Mb R , a′ = τ′ . E [X ] В этих выражениях: τ - время распространения сигнала в линиях кольца; b - задержка в интерфейсе, измеренная количеством битовых интервалов; M – число интерфейсов в кольце; Е[X] – средняя длительность интервала инжекции кадра в кольцо; R - скорость интерфейса (бит/с). Определим эффективность режима доступа к среде как отношение времени, в течение которого среда занята передачей бит М кадров, к полному времени передачи всех этих кадров, учитывающему особенности режима доступа к кольцу. При этом будем считать, что станции всегда имеют кадры для передачи, т. е. кольцо не «простаивает» по причине отсутствия данных. В этих условиях эффективность режима доступа (использование среды передачи) достигает своей максимальной величины. В многомаркерном режиме станция передает кадр (время E[X]) и генерирует свободный маркер, время передачи которого к следующей станции равно ∆τ i′ . Следовательно, общее время, затрачиваемое всеми станциями на передачу M кадров, будет равно M ME[ X ] + ∑ ∆τ i′ = ME[ X ] + τ ′ . i =1 Соответственно, максимальная эффективность кольца определится соотношением 258 η max = 1 1 ME[ X ] . = = ME[ X ] + τ ′ 1 + τ ′ / ME[ X ] 1 + a′ / M (5.10) В одномаркерном режиме время недоступности кольца равно τ ′ , если длительность инжекции кадра меньше времени кольца (короткий кадр), и – E[X], для «длинного» кадра; в общем случае, время кольца, затрачиваемое на передачу кадра, равно максимальной из величин {τ ′, E[ X ]} . Следовательно, η max = 1 ME[ X ] 1 . (5.11) = = M ⋅ max{E[ X ],τ ′} + τ ′ max(1, a′) + τ ′ / ME[ X ] max(1, a′) + a′ / M Слагаемое τ ′ в знаменателе выражения (5.11) отражает совокупные затраты времени на передачу освобожденного маркера следующей станции кольца. Наконец, в однокадровом режиме эффективное время передачи кадра всегда равно Е[X] + τ ′ . Следовательно, η max = ME[ X ] 1 = M ( E[ X ] + τ ′) + τ ′ 1 + a′(1 + 1 / M ) (5.12) Второе слагаемое τ ′ в знаменателе выражения (5.12) – это совокупные затраты времени на передачу освобожденного маркера следующей станции кольца. η max Рисунок 5.14. Эффективность режимов маркерного кольца На рис.5.14 представлены зависимости η max (a′) для рассмотренных режимов маркерного доступа. Самой высокой производительностью 259 обладает алгоритм многомаркерного доступа, что вполне ожидаемо. Наиболее низкую производительность демонстрирует однокадровый алгоритм, предусматривающий наличие в кольце в любой момент времени не более одного кадра. При этом, для больших значений a′ , т. е. когда кольцевая задержка производительность много больше однокадрового и времени инжекции одномаркерного кадра, алгоритмов становится почти одинаковой и приближается к значению 1 / a′ . Такая ситуация возможна либо при очень большой протяжённости кольца, либо при очень высокой скорости передачи. Обратим также внимание на то, что при малых значениях нормированной задержки передачи ( a′ ≤ 1 ) производительность многомаркерного и одномаркерного режимов становятся одинаковыми (в обоих режимах кольцо полностью «занято» битами одного передаваемого кадра). Рассмотрение характеристик алгоритмов маркерного доступа завершим результатами исследования среднего времени ожидания доступа к среде. Приведенные ниже выражения получены в предположении, что время передачи кадра (Х) включает в себя и полное время передачи маркера (последнее пренебрежимо мало). Для кольца, работающего в многомаркерном режиме, и при ограничении «один кадр/маркер» среднее время ожидания доступа к среде (E[t w]), нормированное к средней продолжительности передача кадра, описывается [24] выражением E[t w ] η + a′(1 + η / M ) = a′   E[ X ]   2 1 − 1 +  ⋅ η    M  (5.13) Из выражения (5.13) хорошо видно, что когда нагрузка кольца η −1 a′ становится близкой к 1 +  нормированное время ожидания существенно  M увеличивается; это является достаточно естественным, т.к. стремление η к η max означает все более полную загрузку кольца кадрами. Эта предельная 260 нагрузка хорошо согласуется с выражением (5.10). Рисунок 5.15 отражает зависимость времени задержки от величин η и a ′ . 50 E[tw ] E[ X ] 40 a’= 10 a’= 1,0 30 a’= 0,0 20 10 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 η 1,0 Рисунок 5.15. Средняя задержка передачи кадра в многомаркерном режиме при ограничении 1 кадр/1маркер и М = 32 В однокадровом режиме кольца маркер не освобождается до момента прибытия последнего бита кадра на интерфейс станции, с которой он был отправлен и это увеличивает задержку передачи кадра, которая описывается выражением (5.14); соответствующие графики приведены на рис. 5.16. E[t w ] = E[ X ] E[tw ] E[ X ] 40   η  (1 + a′) M . 1   2 1 − [1 + a′(1 + )]η  M   η[1 + 2a′ + (a′) 2 ] + a′1 + a ′ = 10 a′ = 1 (5.14) a′ = 0 М = 32 30 20 10 0,5 1,0 η Рисунок 5.16. Среднее время ожидания передачи в однокадровом режиме Сравнение рис. 5.15 и рис.5.16 показывает, что нормированное время ожидания передачи в однокадровом режиме оказывается существенно более чувствительным к величине нормированной кольцевой задержки ( a′ ) и когда 261 она становится больше 1, многомаркеный режим кольца является предпочтительным. Оценим максимальное время доступа к среде в режиме многомаркерного доступа. Напомним, что максимальное время доступа к среде по методу МДКН может быть бесконечно большим, поскольку станция может оказаться «неудачливой» настолько, что любая ее попытка начать передачу будет приводить к коллизии. Для регулярных алгоритмов время доступа к среде всегда является конечной величиной. Узел А (для определенности) будет максимально долго ждать разрешение на доступ к среде в ситуации, когда: 1. он получает кадр для передачи сразу после начала передачи предыдущего кадра и 2. все станции кольца имеют кадры для передачи. Ясно, что этот узел должен будет завершить передачу текущего кадра, затратив на это X=L/R секунд, выпустить в кольцо свободный маркер и ждать пока все остальные (М-1) станций кольца передадут свои кадры. Таким образом (tw ) max = M L +τ ′ . R При τ ′ = 8 мкс, M = 32, L = 4 кбайт и R = 16 Mбит/с получаем (tw ) max = 64 мс; это величина вполне приемлемая даже для аудиотрафика. Заключение к разделу 5.1 Для достижение высоких показателей производительности все алгоритмы доступа к общей физической среде требуют определённой координации поведения станций (управление маркерами, разрешение коллизий). Общей чертой случайного и регулярного (маркерного) методов доступа к среде является расходование ими части времени канала на выполнение процедур управления доступом к среде. 262 Характеристики всех алгоритмов доступа к среде чувствительны ко времени реакции системы «среда – станция»; параметром этой реакции является произведение скорости интерфейса на время распространения сигнала в среде передачи между наиболее удаленными станциями. Основное отличие рассмотренных методов множественного доступа к среде передачи отражается в их названиях – случайный (нерегулярный) доступ и регулярный (предопределенный расписанием). Регулярные методы обеспечивают более высокую нагрузочную способность сети и стабильность времени задержки доставки кадров, следовательно, они лучше подходят для передачи изохронного трафика и для работы в высоконагруженных сетях. Однако, методы случайного доступа при умеренном уровне предлагаемой нагрузки демонстрируют весьма незначительный уровень задержки кадров, а их эффективная производительность нередко оказывается выше производительности сетей с регулярным доступом. На определенной стадии развития технологий локальных сетей оба способа доступа к общей среде передачи нашли свое место. Однако, развитие технологии коммутации кадров вытеснило метод случайного доступа в область беспроводных сетей, а маркерный узкоспециализированных решений. 263 доступ - в область 5.2. Коммутируемый сети Совместное передачи использование конечными станциями единой среды для физических сигналов является основным ограничением масштабируемости сети. Оно полностью снимается при предоставлении физической среды в монопольное владение каждой станции и организации их взаимосвязи на логическом, а не на физическом уровне (рис. 5.17). Такие 236 логические каналы, прозрачным для конечных станций образом, создаются специализированными устройствами (коммутаторами). Биты, байты, кадры .... Ст.N Ст.1 Физические сигналы Физические сигналы Ст.2 Ст.4 Ст.3 Рисунок 5.17. Коммутатор оперирует логическими сущностями (кадрами) Принимая на одном из своих портов физические сигналы от конечной станции 1, коммутатор преобразует их в логические сущности (битовые блоки, кадры), которые после определенной обработки (проверки отсутствия ошибок, например) и обратного преобразования битов в физический сигнал отправляет станции 2, подключенной к другому его порту. Конечно, на эти операции преобразования затрачивается определённое время, но при взаимосвязи станций на уровне физических сигналов сравнимое, а часто и большее, время уходит на конкурентную «борьбу» за доступ к среде. Кроме того, коммутатор способен одновременно поддерживать до N/2 (N - число портов) логических каналов, исключает коллизии и необходимости повторных передач. Конечно, проблема конкурентного доступа к ресурсам физических линий для передачи кадров от разных источников к одному получателю остаётся актуальной, но решается она не на физическом, а на логическом уровне (задача арбитража). В целом, коммутаторы – это следующий шаг на пути упорядочения доступа конечных станций к физической среде. В сравнении с многопортовыми концентраторами, обеспечивающими коммутаторы единую более среду сложны, передачи однако, 237 физических исключение сигналов, коллизий и дополнительные возможности управления потоками данных обеспечили им практически полное доминирование во всех классах сетей. Сеть коммутаторов, располагая многосвязной топологией, также обеспечивает рост надёжности коммуникационной инфраструктуры. 5.2.1. Модели коммутации Будем считать, что процедура маршрутизации определила путь между конечными станциями. Задачей процедуры коммутации является организация передачи кадра между сетевыми узлами этого пути. Она может решаться на основе двух принципиально отличных моделей. 1. Создание сквозного логического канала между конечными станциями до начала передачи данных и сохранение его столь долго, сколько это необходимо приложению (модель коммутации каналов); эта модель предполагает выделение определенных ресурсов всеми коммутаторами на пути между конечными узлами на всё время существования канала и определённые признаки идентификации потока данных этой пары станций. 2. Создание логических каналов между смежными коммутаторами маршрута только в момент прибытия кадра и только на время, необходимое для определения порта, на который его следует передать, и выполнения передачи кадра на входной порт «соседа» (модель коммутации кадров). Модель коммутации каналов при многопереходной структуре пути интересна тем, что процедуры маршрутизации и арбитража выполняются лишь один раз при создании канала; следовательно, в заголовках информационных кадров становятся лишними поля, несущие информацию для этих процедур, что уменьшает как накладные расходы коммуникационного протокола, так и время передачи данных. Вместе с тем, если информационный поток приложения имеет многочисленные временные паузы, то ресурсы коммутаторов, выделенные для этого потока, не будут использоваться. Это обстоятельство 238 в условиях реального трафика системных и локальных сетей приводит к неэффективному использованию их ресурсов. Модель коммутации кадров требует решения задачи арбитража в отношении каждого кадра и на каждом узле маршрута, что сопряжено с дополнительными задержками и может порождать локальные перегрузки. В обеих моделях собственно передача кадра между входным и выходным портами реализуется в двух основных вариантах: «сохранить и передать» (store-and-forward) и «на лету» («сut-through»). Вариант «сохранить и передать» предполагает передачу кадра на выходной порт коммутатора после полного его сохранения в буферной памяти. Это позволяет выполнить проверку целостности кадра и прекратить дальнейшую его транспортировку при обнаружении ошибки. Последнее повышает достоверность и эффективность передачи информации, но вносит дополнительную задержку передачи и требует наличия буферной памяти размером не менее размера самого большого кадра. Вариант коммутации кадров по принципу «сut-through» («на лету») позволяет выполнять трансляцию кадра на выходной порт сразу после обработки его управляющей информации (заголовка). Поле данных кадра также обрабатывается по частям, размер которых примерно равен размеру заголовка. Такой способ коммутации позволяет организовать конвейерную обработку кадра и сократить сетевую задержку. Tpr Trec TRA Tsend t TSW.sf Tpr Trec.h TRA Tsend.h t Trec.pl Tsend.pl t TSW.cth ΔTSW Trec – время приема и записи кадра в буфер; TRA – время маршрутизации и арбитража; Tpr – время прочих составляющих обработки кадра; Tsend –время передачи кадра в линию; Trec.h, Tsend.h – времена приёма и передачи заголовка кадра; Trec.pl, Tsend.pl – времена приёма и передачи поля данных кадра; TSW.sf – время коммутации по схеме «Store and Forward» TSW.cth – время коммутации по схеме «CutThrough». Рисунок 5.18. Коммутация по схемам «Сохранить и передать» и «на лету» 239 Представленное на рис. 5.18 сравнение этих вариантов коммутации иллюстрирует сокращение времени обработки кадра по схеме «на лету»; при этом предполагается наименее выгодный для конвейера случай малых кадров с размером их поля данных (Lpl) не более размера заголовка (Lh ). Преимущества коммутации на лету в сравнении с коммутацией store-and-forward могут заметно ослабляться рядом факторов. Существенная доля в трафике кадров малого размера, разные скорости входного и выходного портов, необходимость коммутации с разных входных на один выходной порт, — всё это приводит к применению режима «сохрани и передай». В коммутаторах для локальных сетей и центров обработки данных режим коммутации на лету используется редко. Чаще он реализуется в коммутаторах сетей на кристалле и в коммутаторах сетей суперкомпьютеров. 5.2.2. Архитектура коммутаторов Укрупнённая структура коммутатора (рис. 5.19) содержит три функциональных элемента: линейные карты, коммутационную фабрику и контроллер соединений. Первая обеспечивает связь с физической линией, функции PHY и MAC протоколов, определение порта, через который кадр должен быть отправлен далее, его буферизацию, удовлетворение требований качества обслуживания. 1 R PHY и MAC Буферизация, опр. вых. порта Линейная карта 1 Коммутационная фабрика N·R (б/с) Буферизация, QoS R ... R 1 Линейная карта 1 ... N PHY и MAC PHY и MAC Буферизация, QoS Буферизация, опр. вых. порта PHY и MAC Линейная карта N Линейная карта N Контроллер соединений Рисунок 5.19. Укрупнённая структура коммутатора 240 N R Коммутационная фабрика отвечает за надёжную и быструю передачу кадра с входного порта на выходной. Контроллер соединений координирует работу входных и выходных интерфейсов, генерирует сигналы управления состоянием коммутационной фабрики. Характеристики коммутаторов определяется, главным образом, архитектурой коммутационной фабрики и организацией буферизации кадров. Возможные их варианты представлены схемой на рис. 5.20. Коммутационная фабрика Архитектура коммутатора С пространственным разделением путей «вход – выход» С временным разделением путей «вход – выход» Матрица NxN Каскадирование малоразмерных матриц Общая среда (шина) Общая память Буферизация На входах КФ (IQ) На выходах КФ (OQ) Виртуализация OQ на входах КФ (VOQ) Рисунок 5.20. Классификация архитектур коммутаторов 5.2.2.1. Коммутаторы с временным разделением Коммутаторы этого класса обладают физическим ресурсом для передачи кадров с любого входного порта на любой выходной порт, но предоставляется он каждому кадру в разные интервалы времени. Таким ресурсом является либо физическая среда передачи (шина), либо внутренняя общая память. 241 Коммутаторы с общей шиной Доступ к ресурсу шины регулируется контроллером соединений на основании информации входных портов о принятых кадрах и портах, на которые они должны быть отправлены (рис. 5.21). Преобразов. послед.→ парал. ШИНА TDM N 1 Преобразов. парал.→ послед. Фильтр адреса Данные Метка .... Преобразов. послед.→ парал. .... 1 Преобразов. парал.→ послед. Фильтр адреса N Контроллер соединений Рисунок 5.21. Коммутатор с общей шиной Последовательный битовый поток кадра преобразуется в кодовые слова (ячейки), размер которых определяется разрядностью шины. В ячейке также размещается метка выходного порта. Шина работает в режиме разделения времени и её ресурс предоставляется каждому порту для передачи ячейки кадра. Каждый порт содержит адресный фильтр и ячейки, удовлетворяющие условию фильтрации, им принимаются, при необходимости буферизируются и далее преобразуются в последовательный битовый поток, формирующий сигналы выходной линии. В целом, можно констатировать, что:  все поступающие кадры разделяются на ячейки, которые снабжаются меткой выходного порта;  только одна ячейка кадра в каждом временном слоте может передаваться по шине;  производительность шины должна быть не менее, чем в N раз выше скорости порта (считаем, что все порты одинаковы). Масштабируемость способностью и архитектуры физической ограничивается протяженностью 242 пропускной многопортовой шины, увеличению которых препятствуют трудности согласования линейных модулей и шины, взаимные наводки в проводниках шины, отражения в местах подключения разъемов и ряд других физических факторов. Также, в отличие от архитектуры с общей памятью, организация буферов на выходных портах требует сравнительно большего их размера для достижения заданного уровня вероятности их переполнения. Коммутаторы с общей памятью В коммутаторах с общей разделяемой памятью (рис. 5.22) принимаемый портом кадр преобразуется в поток ячеек разрядностью, равной разрядности шины памяти. Заголовки каждого кадра передаются в контроллер памяти, который определяет выходной порт и задаёт адрес очереди, в которую необходимо поместить кадр. Ячейки кадров с каждого входа мультиплексируются в общий поток и записываются в динамически выделяемых областях двухпортовой RAM памяти. В каждом временном слоте все входные порты должны получать возможность записи в память по одной ячейке и все выходные порты – возможность чтения из неё по одной ячейке. Порядок, в котором обслуживаются выходные очереди, определяется контроллером памяти, реализующим также и механизм арбитража. Поток считываемых ячеек демультиплексируется по соответствующим выходным интерфейсам, где они преобразуются в последовательный битовый поток. Заголовки кадров Контроллер памяти 1 Преобразов. послед.→ парал. M U X ОБЩАЯ ПАМЯТЬ Преобразов. послед.→ парал. D E M U X Преобразов. парал.→ послед. Рисунок 5.22. Коммутатор с общей памятью 243 1 .... .... N Преобразов. парал.→ послед. Адреса записи/чтения N Архитектура коммутатора с общей памятью позволяет минимизировать задержки коммутации. Объём памяти, необходимый для обеспечения заданного уровня вероятности её переполнения, в таких коммутаторах существенно меньше общего объёма памяти коммутаторов других архитектур. Однако, реализация указанных достоинств этой архитектуры сопряжена с рядом трудностей.  Размер кадра крайне редко бывает кратен разрядности шины памяти и это усложняет её дизайн;  Поскольку данные входных портов мультиплексируются на основе разделения времени и в каждом тайм–слоте необходимы две операции обращения к памяти (для записи и чтения), то коммутационные операции должны выполняться со скоростью в 2N раз выше скоростей входных потоков, т.е. за время ΔT ≤ L/(2NR), где R – скорость интерфейса, L – размер ячейки;  Коммутация выполняется в форме операций чтения/записи, а уменьшение времени доступа к памяти имеет свои достаточно жесткие физические ограничения;  Требуемый объём памяти увеличивается как с ростом числа портов, так и с увеличением их номинальной скорости. 5.2.2.2. Коммутаторы с пространственным разделением Коммутаторы этого класса обеспечивают возможность одновременной передачи кадров между любой парой «входной порт → выходной порт» по взаимно независимым физическим путям. Это открывает возможности существенного повышения производительности коммутаторов и уменьшения задержек передачи кадров. Такие коммутационные фабрики реализуются в формах:  коммутационной матрицы, обеспечивающей между любой парой портов физический автономный путь, создание и существование которого не зависит от наличия путей между другими парами портов, и 244  многокаскадных сетей коммутационных матриц малой размерности, эквивалентных матрицам произвольной размерности. Коммутационная матрица Большинство современных высокопроизводительных коммутаторов имеют в своём ядре коммутационную матрицу с N входами и N выходами (рис. 5.23). Eё линии входов и выходов взаимно изолированы, а N2 коммутационных элементов (рис. 5.23.б) могут обеспечить соединения любого входа с любым выходом. Состояние коммутационных элементов определяется контроллером соединений на основании адресов назначения коммутируемых блоков данных. Контроллер соединений Сигналы управления ключами In_0 In_1 In_2 In_3 In_4 In_5 In_6 In_7 Out_0 Out_1 Out_2 Out_3 Out_4 Out_5 Out_6 Out_7 Рисунок 5.23. Коммутационная матрица 8 х 8 и состояния её ключей Возможность соединения любых пар «вход-выход» является следствием возможности организации в такой матрице N! путей. Более того, связь непересекающихся пар входных и выходных портов может быть реализована одновременно, т. е. коммутационная матрица - неблокирующая система. Задержка передачи «вход – выход» зависит только от времени коммутации одного ключа, и она весьма мала. Возможность одновременного 245 создания N независимых путей и малые задержки коммутации являются основными и неоспоримыми достоинствами такой структуры. Сложность коммутационной матрицы (число коммутирующих элементов и занимаемая ими площадь микросхемы) растёт пропорционально квадрату числа входов (выходов), что затрудняет построение матриц для больших N. Многокаскадные сети коммутационных матриц Общим подходом к решению проблемы масштабируемости коммутационной матрицы (актуально создание коммутаторов с несколькими сотнями портов) является реализация её функциональных свойств многокаскадными структурами, содержащими определенное число матриц малой размерности, схема соединений которых обеспечивает пути между каждой парой "вход-выход". Такая структура называется многокаскадной коммутационной фабрикой (multistage switch fabric) или многокаскадной сетью (multistage interconnection networks, MIN). Таким способом коммутационную матрицу N x N можно построить объединением матриц k x k (k < N) в структуру из, как минимум, logkN каскадов, содержащих каждый (N/k) матриц. In_0 Out_0 In_1 Out_1 In_2 Out_2 In_3 Out_3 In_4 Out_4 In_5 Out_5 In_6 Out_6 In_7 Out_7 1 1 Состояния коммутационного элемента Рисунок 5.24. Многокаскадная сеть Омега 8 х 8 Примером каскадного построения коммутационной матрицы 8 х 8, на базе матричных коммутаторов 2х2 является сеть Омега (рис. 5.24). Действительно, в этой сети есть log28 = 3 каскада, содержащих каждый по 246 8/2 = 4 матрицы. Эта сеть, обеспечивая возможность коммутации каждого входного порта с любым выходным, содержит меньше коммутационных элементов (12), чем классическая коммутационная матрица (64). Также, существенным достоинством этой структуры является присущее ей свойство самомаршрутизации, т. е. адрес узла назначения является сигналом, управляющим состоянием каждой коммутационной матрицы 2 х 2. Число бит в адресе равно числу ступеней сети и каждый бит управляет состоянием (1 - соединение на нижний выход, 0 - соединение на верхний выход) матриц определенного каскада (старший бит - самого левого, младший – выходного). Например, поступление на любой вход кадра с адресом назначения 110 = 610 обеспечит коммутацию ключей, необходимую для доставки его на выход 6. Однако, уменьшение сложности многокаскадных структур может сопровождаться снижением их производительности. Последнее является следствием роста конкуренции за доступ к взаимно пересекающимся частям путей между парами коммутируемых портов, т. е. такие структуры могут оказаться блокирующими. Например, в представленной сети ОМЕГА при наличии соединения (In_4 → Out_0) создание соединения (In_0 → Out_1) будет заблокировано в первом каскаде, поскольку его верхний коммутационный элемент, обеспечивая соединение (In_4 → Out_0), не в состоянии создать независимый путь для соединения (In_0 → Out_1). Этот эффект, в свою очередь, связан с наличием в сети Омега лишь одного пути между любой парой «вход-выход». Уменьшение вероятности внутренних блокировок в коммутационных структурах требует увеличения числа возможных путей между любыми парами вход-выход. Теоретическим фундаментом для создания неблокирующих многокаскадных коммутационных матриц стал результат, полученный в 1953 году Клозом (Close); им была показана принципиальная возможность построения неблокирующих сетей коммутационных матриц при наличии в них не менее трёх каскадов (рис. 5.25). При этом, матрицы промежуточного (второго) каскада должны иметь число входов и выходов, 247 достаточное для подключения к ним всех коммутаторов входного и выходного каскадов. 1 n2 … 2 n2+1 n2+2 2n2 …. r2 1 2 m r2 … m 1 2 … m … r1 1 2 … … m 1 2 … 1 2 r1 r2 1 2 …. …. … N=r1 х n1 2 m … r1 1 2 1 2 … m r2 … 2 1 1 2 … 1 2 r1 … m 1 2 2 … … n1+1 n1+2 2n1 1 1 … n1 1 2 … … 1 2 M=r2 х n2 Рисунок 5.25. Сеть с топологией Клоза Параметры n1 , r1 , n2 , r2 , m полностью определяют такую сеть; число входов N  r1n1 , число выходов M  r2 n2 . Будет ли сеть неблокирующей, зависит от числа матриц в промежуточном (втором) каскаде. Клоз доказал, что для отсутствия блокировок условие m  n1  n2  1 является необходимым и достаточным, а при m  n2 сеть будет реконфигурируемо неблокирующей, т. е. располагающей возможностью сформировать непересекающиеся пути для требуемого в определенный момент набора соединений. Все остальные соотношения между параметрами n1 , n2 , m дают сеть с блокировками. Отметим, что в реконфигурируемо неблокирующей сети все пути передачи должны формироваться одновременно, а создание нового пути без реконфигурации уже функционирующих соединений в таких сетях не гарантируется. Для коммутатора с N  M  32 и n  2, получаем r1  r2  16, m  2n  1  3 , т. е. матрицы входного каскада должны быть размерностью 2 х 3, выходного – 3 х 2, а промежуточного каскада – 16 х 16. Для коммутатора с N  M  8 , размерность входных и выходных матриц сохраняется, а в промежуточном каскаде потребуются матрицы 4 х 4. 248 Условия Клоза обобщаются на структуры с произвольным нечетным числом каскадов; при этом, коммутаторы промежуточного каскада замещаются трехкаскадной сетью, построенной по тем же правилам. Это позволяет уменьшить размерность коммутаторов в этом каскаде. Пятикаскадная реконфигурируемо неблокирующая сеть такого типа с n1  n2  n  2 , r1  r2  n  2 для коммутатора с N  M  8 представлена на рис. 5.26. Эта топология известна как сеть Бенеша. Входы 1-8 Выходы 1-8 Рисунок 5.25. Пятикаскадная сеть Клоза (сеть Бенеша) 8 х 8 Отметим коммутатора еще возможность посредством увеличения параллельного производительности включения коммутационных матриц. Кадр, поступивший на входной порт, разделяется (например, побайтно) на определенное число потоков, каждый из которых коммутируется отдельной матрицей. На выходных портах потоки вновь объединяются. Поскольку линейные размеры парциальных матриц весьма малы, и они конструктивно идентичны, то риск рассинхронизации парциальных потоков во время их коммутации сводится к минимуму. 5.2.2.3. Буферизация кадров и блокировки Несмотря на то, что коммутационная фабрика может быть внутренне неблокирующей структурой, конкуренция за ресурс выходного порта, когда через него должны передаваться два или более кадра с разных входов, может 249 приводить к деградации её производительности. Для сохранения кадров, конкурирующих за доступ к одному и тому же выходному порту, в оперативной памяти коммутаторов создаются буферные очереди. Варианты их организации представлены на рис. 5.27. Кадр для занятой выходной линии 1 2 1 2 1 1 2 2 k k а) ... .... .... .... k k б) VOQ11 1 1 ... .... .... 2 VOQ1k VOQk1 k k ... в) VOQkk Рисунок 5.27. Буферизация в коммутаторах: а) на входах, б) на выходах, в) виртуализация выходных очередей на входах Коммутаторы с буферной памятью на входных линиях портов (Input Queueing, IQ, рис. 5.27.а) требуют, чтобы производительность канала доступа к памяти была в два раза выше скорости интерфейса (за один такт коммутации кадр должен быть записан в буфер и считан из него), а коммутационная матрица может работать на скорости интерфейса. Эти свойства являются достоинством буферизации на входе. Однако, в силу FIFO-дисциплины обслуживания в таких очередях возникают HOL-блокировки (Head-Of-Line blocking): если передача кадра, находящегося в вершине очереди, оказывается невозможной в силу занятости выходной 250 линии, то и все остальные кадры в этой очереди, адресуемые на другие выходные порты, также не передаются. Это обстоятельство, даже при статистически равномерном распределении трафика по портам, приводит к существенному (почти вдвое) падению общей производительности коммутаторов [25]. Организация очередей на выходных линиях (Output Queueing, OQ, рис. 5.27.б) исключает HOL-блокировки, поскольку все кадры в буфере конкретного выходного порта должны быть переданы именно по этой линии и именно в том порядке, в котором они находятся в очереди. Однако, для такой организации буферизации проблемной является ситуация, когда кадры от многих входных портов одновременно должны передаваться на один выходной порт. В этом случае требуется не только большой объём буферной памяти, но и увеличенные, в сравнении с битовой скоростью интерфейсов, скорость коммутации и скорость записи в память. В пределе, производительность коммутационной матрицы и канала доступа к памяти должны в k и k  1 раз (k – число портов коммутатора) выше скорости интерфейса. коммутатора Если будет эти условия равна выполнены, сумме то номинальных производительность скоростей входных интерфейсов, а задержки коммутации не будут превосходить номинальное значение. Конечно, указанные требования затрудняют практическую реализацию такого способа буферизации в многопортовых коммутаторах, особенно, в условиях быстро увеличивающихся скоростей интерфейсов и более медленного роста производительности операций доступа к памяти. Расщепление буферного пространства входного порта (рис. 5.27.в) на k очередей, в каждую из которых записываются кадры, подлежащие коммутации на определенный выходной порт, принципиально исключает HOL-блокировки. Указанное преобразование входных очередей получило название виртуализации выходной очереди (Virtual Output Queueing, VOQ), поскольку j-е парциальные очереди на i-х входах (VOQij) представляют части очереди j-го выходного порта. Заметим, что виртуальные очереди на каждом 251 входе имеют один общий канал связи с коммутационной матрицей, следовательно, за один тайм-слот может считываться только один кадр (или одна ячейка кадра) из какой-либо виртуальной очереди порта. Выбор этой очереди осуществляет централизованный диспетчер очередей. При удачной его настройке производительность такого коммутатора может достигать почти 100% (т. е., равняться сумме скоростей всех входных интерфейсов). Недостатком метода виртуализации выходных очередей является квадратичный рост их общего числа при увеличении числа портов. 5.2.2.4. Диспетчеризация очередей Процедура диспетчеризации, определяющая порядок обслуживания виртуализированных очередей при наличии нескольких одновременных запросов к ресурсу конкретного выходного порта (задача арбитража), существенно влияет на производительность коммутатора. Кроме собственно критерия «справедливости» выбора очереди, которой предоставляется ресурс, на эффективность арбитража оказывает влияние и полнота входной информации о существующих потребностях в этих ресурсах. На рис. 5.28.а приведена простейшая схема арбитража, предполагающая возможность каждой входной очереди отправлять запрос на обслуживание только одного пакета, находящегося в её вершине. Запросы на обслуживание направляются арбитрам выходных портов. Видно, что в течение текущего тайм-слота обслуживания загружены только два из четырех выходных портов. Если позволить каждой очереди отправлять запросы на обслуживание двух пакетов (рис. 5.28.б), то в одном тай-слоте будут загружены уже три выходных порта и производительность коммутатора возрастет. Конечно, это потребует от процедуры управления очередями дополнительного интеллекта, поскольку отправка двух запросов от одной очереди предполагает возможность получения двух удовлетворительных решений и необходимости задания критерия выбора одного из них; также необходимо уметь отправлять кадр, находящийся не в голове очереди. 252 Порт 1 Арб. 2 Порт 2 Арб. 3 Порт3 4 Арб. 4 Арб. 1 Входные буферы выходных портов Входные буферы выходных портов Арб. 1 Порт 4 Порт 1 Арб. 2 Порт 2 Арб. 3 Порт3 4 Арб. 4 Порт 4 а) б) Рисунок 5.28. Алгоритмы арбитража: с одним запросом (а) и с двумя запросами (б) от каждой очереди Однако, вполне вероятно, что в течение тайм-слота обслуживания очередь не получает доступ ни к одному из требуемых выходных портов, хотя какой-то из них останется свободным. Эту ситуацию иллюстрирует рис. 5.28.б: запросы второй очереди не были удовлетворены, а третий выходной порт, необходимый для коммутации кадра этой очереди, остался свободным. Приведённые примеры показывают, что алгоритм арбитража оказывает влияние на производительность коммутатора, на величину и неравномерность задержки передачи кадров. В целом, алгоритм арбитража должен:  обеспечивать высокую производительность коммутатора, т. е. поддерживать низким уровень заполнения виртуальных очередей;  быть справедливым, т. е. не допускать неопределенно долгого пребывания кадров в какой-либо из очередей;  решать задачу максимально быстро;  допускать эффективную аппаратную реализацию. Арбитраж, чтобы быть эффективным, должен выполняться централизовано с учётом текущего состояния выходов и содержания входных очередей. Эффективность выполнения и адекватность результатов такого анализа будут выше, если принять предположение о фиксированном 253 размере коммутируемых блоков данных (как и ранее, называть их будем ячейками). Ясно, что размер ячейки должен быть не больше минимального размера кадра, т. е. его заголовка. Фиксированный размер ячеек позволяет слотировать время и контролировать состояние всех выходных портов и очередей в строго определённые моменты времени, кратные времени приёма/передачи ячейки портом. В целом, такой синхронный режим обработки ячеек малого фиксированного размера позволяет обеспечить более справедливое распределение ресурсов коммутационной фабрики и создаёт благоприятные условия для аппаратной реализации алгоритма арбитража. Поэтому, несмотря на определённые издержки разбиения кадров переменного размера на фиксированные ячейки, синхронный режим коммутации часто признаётся хорошим выбором. Универсальным критерием подбора арбитром пар "вход-выход" является критерий максимизации степени согласования запросов на ресурсы и уровня их использования (Maximum Weight Matching, MWM). Этот критерий предполагает назначение всем i-м претендентам на доступ к ресурсу j-го выходного порта определенных весовых коэффициентов (wij), которые отражают меру конкуренции за этот ресурс. Алгоритм арбитража отбирает пары (i, j) по критерию максимизации сумы весов wij. Содержательное определение весов даёт разные стратегии решения задачи. Так, принятие в качестве веса очереди числа кадров в ней, обеспечивает приоритет «наиболее длинной очереди», а вычисление веса как времени ожидания обслуживания первого пакета в очереди приводит к стратегии приоритета «наиболее задержанной очереди». Строго доказано [26], что алгоритм MWM для весьма широкого класса статистик входящего трафика даёт почти 100% уровень утилизации ресурсов матрицы при весьма низких показателях задержки коммутации. Однако, необходимость вычисления весов всех запросов в интервале временного слота (время передачи ячейки на скорости интерфейса порта) делает его трудно реализуемым при современных скоростях интерфейсов. Действительно, для коммутатора с 254 портами 40 Гб/с при фиксированном размере ячейки кадра 64 байта, время тайм-слота составляет 12.8 нс; даже с учетом возможности конвейерной обработки ячейки решение задачи арбитража должно уложиться в половину этого интервала, т.е. всего в 6.4 нс. Алгоритм iSLIP (iterative round robin matching with slip, итерационное карусельное согласование с пропусками) [27] является одним из наиболее удачных алгоритмов централизованного арбитража. Его «справедливость» поддерживается тем, что соединения i-го входа с j-м выходом, реализованные в текущем тайм-слоте, получают низший приоритет в следующем интервале обслуживания. На каждой итерации текущего тайм-слота ищется согласование только тех пар «вход-выход» (i, j), которые не были согласованы на предыдущей итерации. Алгоритм может выполняется параллельно в отношении каждого выходного порта. Иллюстрационная схема первой итерации алгоритма представлена на рис. 5.29. Каждая итерация содержит три этапа. Этап 1. Запрос. Каждый входной порт, нуждающийся в соединении с каким-либо выходным портом, направляет запросы арбитрам выходных портов, для которых в его виртуальных очередях в текущий момент есть кадры. Этап 2. Выделение ресурса. Выделение ресурса j-го выходного порта осуществляется в форме предоставления кредита выбранному (i-му) входному порту; выбор i-го порта производится как следующего по порядку за портом, которому последним предоставлялся ресурс этого j-го выхода. Учёт обслуженных портов ведётся указателем gj, значение которого устанавливается на единицу большее номера последнего обслуженного входного порта. Решение об удовлетворении запроса направляется i-му входному порту в форме кредита. Значение gj обновляется только после подтверждения входным портом принятия выделенного кредита. Этап 3. Подтверждение приёма кредита. Входной i-й порт может получить кредиты от арбитров нескольких выходных портов. Из них он 255 выбирает кредит порта, следующего по порядку за портом, которому он отправлял предыдущий кадр. Учет этих уже состоявшихся соединений ведется указателя aj, значение которого на единицу больше номера этого выходного порта. Решение о принятии кредита направляется порту, кредит которого принят, и указатель aj обновляется значением на единицу большим номера этого выходного порта. Входы Выходы g1 1 2 3 4 Непустые VQO Q11, Q12 1 a1 1 2 3 4 Запрос ресурса Кредит Положительное подтверждение кредита g2 1 2 3 4 2 a2 1 2 3 4 g3 1 2 3 4 Q32, Q34 3 a3 1 2 3 4 g4 1 2 3 4 Q44 4 a4 1 2 3 4 1 1 2 2 3 3 4 4 б) а) Рисунок 5.29. Схема первой итерации алгоритма iSLIP (а) и её результат (б) Критерием необходимости повторения итерации является наличие отрицательно подтверждённых (неиспользованных) кредитов, т. е, несогласованных соединений при наличии ресурсов выходных портов. Если очередная итерация не привела к увеличению количества согласованных соединений, то это является сигналом завершения итерационного процесса в данном тайм-слоте. Число итераций, которые могут потребоваться алгоритму iSLIP для максимально полного согласования входов и выходов, не превышает числа портов (N). Однако, исследование алгоритма при разных статистиках коммутируемого трафика показало, что среднее число итераций не превышает значения log2N, и в большинстве случаев только в первом тайм-слоте обслуживания алгоритм выполняется более одного раза. 256 5.2.2.5. Синхронный коммутатор Выше было установлено, что коммутация с буферизацией на выходных портах показывает максимальную производительность и минимальную задержку поскольку прибывший кадр сразу помещается в очередь выходного порта; также, буферизация OQ позволяет относительно просто реализовать разные классы обслуживания. Однако, условием успешного функционирования буферизации на выходных линиях является N-кратное ускорение матрицы и соответствующее увеличение производительности канала доступа к памяти. Буферизация на входных портах свободна от этих недостатков, но HOL-блокировки снижают почти вдвое производительность фабрики. Виртуализация выходных очередей на входах матрицы при хорошо настроенном алгоритме арбитража позволяет получить производительность коммутации лишь немного уступающую производительности коммутации с буферизацией на выходе; к сожалению, этот подход требует организации N2 очередей, сложных алгоритмов арбитража и приводит к заметному росту задержки передачи кадров. К перечисленным проблемам следует добавить и трудности поддержки такими коммутаторами разных классов обслуживания. В этих условиях компромиссным решением является комбинация виртуальных очередей на входе, буферизация на выходе и умеренное (не более четырехкратного) увеличение скорости работы коммутационной матрицы. Такая комбинированная архитектура (Combined Input/Output Queueing, CIOQ) коммутатора оказалась и достаточно производительной и гибкой в отношении предоставления разных классов обслуживания. В предположении использования коммутации «на лету» и наличия сформированной таблицы коммутации, можно выделить пять этапов обработки кадра синхронным коммутатором CIOQ (рис. 5.30), а именно: I. II. приём заголовка кадра i-м портом; передача адреса назначения кадра модулю управления, определение по таблице коммутации номера выходного порта (j) и запись заголовка в 257 соответствующую виртуальную очередь VOQij ; III. выполнение процедуры арбитража доступа порта i-го к коммутационной матрице для передачи содержимого виртуальной очереди VOQij на выход j; IV. V. коммутация заголовка кадра на требуемый выходной порт; буферизация в очереди выходного порта и подготовка к передаче в физическую линию. Этап I Этап III Этап II Этап IV 1 VOQi1 1 .... i Этап V i PLC ... j PLC OQj .... .... VOQik k k Управление коммутацией PLC – Physical Link Control сопряжения с физ. линией. Заголовок FDB № вых. порта FDB – таблица коммутации Модуль арбитража Рисунок 5.30. Схема базовой архитектуры синхронного коммутатора Очевидно, что второй этап обработки необходим только в отношении заголовка кадра, а все последующие его части будут сразу записываться в ту же виртуальную очередь VOQij и обрабатываться в три этапа (арбитраж, коммутация, выход). Таким образом, вся обработка кадра может быть выполнена по конвейерной схеме (рис. 5.31). Заголовок I II 1-я ячейка данных III IV V I III IV V I III IV V I III IV 2-я ячейка данных Последняя ячейка кадра V Рисунок 5.31. Конвейерная обработка кадра коммутатором 258 5.2.2.6. Асинхронный коммутатор Коммутация кадров ячейками равного размера упростила алгоритмы управления (прежде всего, арбитража), позволила поднять производительность и уменьшить вариации задержки передачи. Однако, существуют и негативные последствия такого деления кадра. Прежде всего, при любом выборе размера ячейки размеры кадров не будут кратны этой величине; это означает, что одна ячейка будет дополняться до заданного размера незначащими байтами, передача которых уменьшает эффективную производительность коммутации. Второй серьёзной проблемой является восстановление кадра из ячеек, которые «по вине» механизма арбитража могут приходить в очередь выходного порта будучи «перемешанными» с ячейками других кадров. Восстановление кадра в таких условиях требует включения в каждую ячейку идентификатора исходного кадра, что опять снижает эффективную производительность коммутации и увеличивает задержку передачи. Со всеми этими издержками соглашались во имя непрерывности приёма данных на входах и их беспрепятственного перемещения на выход коммутационной фабрики (это и есть высокая производительность коммутации). Для обеспечения такого режима при виртуализации выходных очередей потребовались алгоритмы арбитража, которые были эффективны только при работе в слотированном времени. Вместе с тем, предупредить появление кадра на ещё занятом выходе возможно, если временно сохранить его непосредственно в матрице. Появление промежуточной точки хранения ячеек даёт также возможность разделить арбитраж на две независимые части: одна определяет из какой входной очереди VQOij каждый i-й порт может отправлять данные матрице, а вторая занимается согласованием внутренних буферов матрицы с очередями выходных портов использовать (рис. простую 5.32). Обе карусельную арбитражные дисциплину процедуры обслуживания могут или дисциплину приоритета очереди наибольшей длины. Комбинированная архитектура очередей совместно с буферизированной матрицей (Combined 259 Input and Crosspoint Queueing, CICQ) даёт, по крайней мере, два полезных результата:  децентрализация арбитража, который может теперь работать отдельно на каждом входе и на каждом выходе, что упрощает его логику и сокращает задержки;  возможность в одном цикле обслуживания коммутировать ячейки от разных входов на один выход. In_0 In_1 In_2 Out_0 Out_1 Out_2 Рисунок 5.32. Архитектура CICQ с буферизированной матрицей Буферизация матрицы и децентрализация процедуры арбитража позволяют отказаться от дробления кадров на ячейки и реализовать асинхронный режим коммутации. Это исключило указанные выше накладные расходы и позволило уменьшить размер оперативной памяти (операция сборки кадров требовала дополнительного буфера). Функциональные свойства (производительность и задержка) асинхронных коммутаторов оказались лучше большинства их синхронных аналогов (рис. 5.33, график заимствован из работы [28]). Необходимость размещения в микросхеме матрицы не только N2 коммутирующих элементов, но и N2 буферов не является фактором, серьёзно ограничивающим возможность реализации такой архитектуры. Технологии микроэлектроники еще в начале 2000 годов позволяли решать эту задачу для 260 матриц размерности N≈30–50 при скоростях передачи до 10 Гб/с на порт. Практически, организация большого числа выводов микросхемы матрицы значительно сильнее ограничивает возможность создания коммутационных Задержка коммутации (мкс) матриц очень большой размерности. Рисунок 5.33. Задержки коммутации от нагрузки для коммутатора с 32 портами 10 Гб/с. (Зависимости для синхронного режима с алгоритмом I-SLIP приведены при ускорении матрицы 1, 1.2, 1.4, 1.6 и 2.0) Основные достоинства и недостатки рассмотренных архитектур матричных коммутаторов представлены в таблице 5.1. Таблица 5.1 Архитектура OQ VOQ CIOQ CICQ Достоинства Недостатки 100% производительность для любого вида трафика; поддержка классов обслуживания. Исключение HOL-блокировки; матрица работает на скорости интерфейса. Высокая производительность Необходимость повышения скорости работы матрицы в N раз по отношению скорости интерфейсов Отсутствие гарантий задержки; сложно обеспечить поддержку классов обслуживания Необходимость повышения скорости работы матрицы; Сложный алгоритм арбитража. Зависимость производительности от размера буферов в матрице Упрощение логики арбитража; Высокая производительность Заключение к разделу 5.2.2 Сети на основе коммутаторов, формируя множество одновременно существующих логических каналов, позволяют конечным станциям осуществлять обмен данными на скоростях, близких скорости их физических 261 интерфейсов, и создают благоприятные условия для управления потоками сетевого трафика. Формирование «долгоживущих» логических каналов (модель коммутации каналов) представляет интерес в условиях относительно стабильной интенсивности передаваемых потоков. Такая модель коммуникаций используется в территориальных и глобальных сетях; она требует выделения каждому каналу определённой части ресурсов на всех коммутаторах, формирующих путь между конечными узлами, и несёт риск недоиспользования выделенных ресурсов в периоды уменьшения активности источников трафика. Модель коммутации кадров (ресурсы коммутатора динамически выделяются на время передачи одного блока данных) хорошо соответствует резко неравномерному характеру трафика системных и локальных сетей. Производительность коммутаторов и вносимые ими задержки передачи кадров определяются архитектурой их коммутационных фабрик и организацией управления буферной памятью. Все рассмотренные архитектуры коммутационных фабрик (общая шина, общая память, коммутационная матрица и многокаскадные сети матриц) имеют свои достоинства и недостатки. В современных высокопроизводительных коммутаторах они используются в определенном сочетании. При этом, высокопроизводительным ядром коммутационной фабрики, чаще всего является коммутационная матрица. Трудности реализации многопортовых матриц, связанные с квадратичным ростом их сложности при увеличении числа портов, преодолеваются объединением матриц приемлемой размерности в неблокирующую сеть Клоза или соединением их посредством высокоскоростной шины. Конкуренция за доступ к выходным портам матрицы требует буферизации кадров и порождает проблему диспетчеризации очередей. Создание очередей на входных портах (IQ) несёт опасность блокировки их первым кадром; очереди на выходных портах (OQ) требуют N-кратного, по 262 отношению к номинальной производительности порта, увеличения скорости коммутации и скорости доступа к памяти; виртуализация выходных очередей на входных портах (VOQ) является компромиссным решением, но квадратично увеличивает число очередей и требует высокоэффективных алгоритмов их диспетчеризации. Процедура диспетчеризации определяет порядок обслуживания очередей (задача арбитража) и существенно влияет на производительность коммутатора. Алгоритм арбитража должен:  поддерживать низкий уровень заполнения виртуальных очередей;  не допускать неопределенно долгого пребывания кадров в какой-либо из очередей;  решать свою задачу максимально быстро;  иметь эффективную аппаратную реализацию. Синхронный режим обработки кадров как совокупности ячеек малого фиксированного размера позволяет обеспечить справедливое обслуживание коммутируемых потоков кадров и создает благоприятные условия для аппаратной реализации алгоритма централизованного арбитража. Алгоритм iSLIP является одной из наиболее удачных процедур централизованного арбитража. Комбинированная архитектура буферизации (VOQ + OQ) синхронного коммутатора (Combined Input/Output Queueing, CIOQ) при умеренном увеличении скорости коммутации матрицы оказалась и достаточно производительной и гибкой в отношении поддержки разных классов обслуживания. Буферизация самой коммутационной матрицы позволяет отказаться от дробления кадра на ячейки и разделить задачу арбитража на взаимно независимые процедуры диспетчеризации входных и выходных очередей и, в конечном итоге, реализовать асинхронный режим обработки кадров. Функциональные свойства (производительность и задержка) асинхронных коммутаторов оказались лучше большинства их синхронных аналогов. 263 Контрольные вопросы к разделу 5 1. К каким классам методов управления доступом к среде относятся алгоритмы ALOHA, CSMA, маркерного доступа. 2. Какой алгоритм доступа к среде передаче в условиях локальной сети будет иметь более высокую эффективность ALOHA или CSMA? Почему? 3. Какова максимальная производительность протокола ALOHA (в пакетах/с), при передаче кадров величиной 1000 бит по каналу с пропускной способностью 64 кбит/с? 4. Пусть станция А подключена в одном конце совместно используемой для передачи сигналов шины, а станции В и С включены на другом ее конце. Время распространения сигнала в линии равно  секунд. Станция А получает кадр для передачи в момент t  0 , станция В – в момент t B   / 2 и станция С – в момент tC  3 / 2 . Время передачи кадра составляет 4 . Нарисуйте временные диаграммы передачи этих кадров если доступ к среде управляется алгоритмами ALOHA, ненастойчивым CSMA и настойчивым CSMA. 5. Как влияет изменение битовой скорости передачи кадров на эффективность алгоритма случайного доступа к среде передаче? 6. При каких условиях передача голосового трафика в локальной сети, использующей для доступа к среде алгоритм CSMA, будет успешной? 7. Вычислите топологии, максимальную использующей производительность алгоритм CSMA, при сети всех шинной возможных комбинациях параметров:  скорость интерфейсов станций: R1=10 Мбит/с, R2=10 Гбит/с;  диаметр сети: d1 = 25 м., d2 = 2500 м.  размер кадров: L1 = 12000 бит, L2 = 512 бит  скорость распространения сигнала в линии 2.5·108 м/с. 8. Почему производительность маркерного доступа в сети кольцевой топологии падает при большом диаметре кольца? 264 9. В чём состоит принципиальное отличие коммутируемого доступа к физической среде передачи от методов совместного её использования? 10. Какие достоинства и недостатки присущи двум основным моделям коммутации кадров? 11. Чем отличаются неблокирующая и реконфигурируемо неблокирующая архитектуры коммутационной фабрики? При каком условии возможно построение неблокирующей коммутационной фабрики? 12. На какие показатели функционирования коммутатора оказывает влияние способ буферизации обрабатываемых им кадров? Какой из её видов оптимален по критериям производительности и задержки коммутации? 265 6. КАНАЛЬНЫЕ ПРОТОКОЛЫ Физические линии сетевой инфраструктуры (рис.6.1.а), подвержены влиянию помех и не являются надежной системой передачи. Придание физическому каналу свойств надежной транспортной системы обеспечивается канальным уровнем сетевого стека. Рисунок 6.1.а. Локализация уровневых служб в сетевых узлах На языке уровневой модели сетевого взаимодействия, канальный протокол предоставляет коммуникационный сервис сетевому уровню, используя для этого службы физического уровня (рис. 6.1.б). Пакеты Сетевой уровень Сетевой уровень NL PDU DL SAP DL SDU Канальный уровень Физический уровень Кадры DL PDU Сигналы NL - Network Layer, сетевой уровень DL - Data Link Layer, канальный уровень Канальный уровень Физический уровень Кадры DL PDU Сигналы Канальный уровень Физический уровень SAP - Service Access Pont, точка доступа к услугам PDU - Protocol Data Unit, блок данных протокола SDU - Service Data Unit, блок данных сервиса Рисунок 6.1.б Канальный уровень в сетевом стеке 315 Модель OSI также предусматривает возможность канального уровня обеспечивать все виды коммуникационного сервиса, а именно: передачу данных с предварительным установлением соединения и без него, с подтверждением доставки блоков данных и без подтверждений. В «зону ответственности» канальных протоколов входит:  адресация устройств;  формирование кадров из битового потока, поступающего от физического уровня, или из пакетов сетевого уровня;  обнаружение ошибок;  восстановление поврежденных кадров (при необходимости);  управление потоком, т. е. регулирование интенсивности отправки кадров с учетом возможности их обработки принимающим устройством. Канальные протоколы управляют передачей данных либо по линиям, непосредственно соединяющим взаимодействующие устройства, либо по сетевым соединениям, в которых гарантирован единый путь кадров между парой устройств (в сетях коммутации каналов, например). В силу этого, они не выполняют восстановление приемником исходной последовательности кадров, а всякое нарушение порядка их прибытия рассматривается ими как признак потери. В разделах 3 – 5 пособия были рассмотрены основные адаптационные функции уровневых протоколов. В этом разделе будет показано, как они могут объединяться в конкретных протоколах, управляющих передачей данными между двумя непосредственно связанными узлами, с учётом свойств линий и требований приложений. 6.1. Управление двухточечным каналом - протокол HDLC Спецификация протокола высокоуровневого управления каналом (High Level Data Link Control, HDLC), обеспечивающего надёжную последовательную передачу блоков данных по двухточечному физическому каналу, описывает базовые процедуры целой группы сетевых канальных протоколов. Предшественником и прототипом HDLC был протокол 316 управления синхронным каналом (Synchronous Data Link Control Protocol, SDLC), разработанный фирмой IBM для сетей терминалов. В свою очередь, принятие в 1979 году ISO базовых спецификаций HDLC (ISO 3309, 4335 и т. д.) стало основой для целого ряда его вариантов в сетях с коммутацией пакетов X25 (Link Access Procedure, LAP), в IP-сетях (PPP), в цифровых сетях с коммутацией каналов ISDN (Link Access Procedure Balanced, LAPD). Перечисленные протоколы имеют много общего: все содержат функции управления каналами передачи на последовательных линиях, все являются бит-ориентированными, все обеспечивают надежную и ненадёжную передачу в полудуплексном и дуплексном режимах связи. Текущая версия HDLC описана в документе ISO/IEC 13239:2002. Представляя передачу данных между двумя узлами как процесс обмена командами и ответами, протокол HDLC оперирует понятиями первичной, вторичной и комбинированной станций. Первичная станция управляет каналом; она имеет право посылать команды вторичным станциям и получает ответы от них; если управляемый канал является многоточечным, то первичная станция отвечает за поддержание сеанса связи с каждой из вторичных станций. Вторичная станция только отвечает на команды первичной и не выполняет функций управления каналом. Комбинированная станция может отправлять команды и ответы, а также получать их от других комбинированных станций. Подчеркнем, что станции всех типов являются логическими сущностями и могут быть реализованы на одном физическом узле (рис. 6.2). А В Первичная станция Команды Вторичная станция Ответы Ответы Вторичная станция Команды Первичная станция Рисунок 6.2. Взаимодействие станций HDLC Существуют три логических состояния, в которых могут находиться станции: инициализация соединения, передача данных и разъединение. В 317 свою очередь, в состоянии передачи обмен кадрами между станциями возможен в одном из трёх режимов. 1. Режим обычного ответа (Normal Response Mode, NRM) предусматривает неравноправие узлов и используется для взаимодействия терминалов с хост-компьютером. В этом режиме первичная станция, реализуемая на хосте, генерирует команды опроса соединенных с ней вторичных станций (терминалов); последние отвечают на запросы своими кадрами данных, но сами никогда не инициируют их передачу. Находясь в состоянии ответа, вторичная станция может передать несколько кадров. 2. Режим асинхронного ответа (Asynchronous Response Mode, ARM) отличается от NRM тем, что вторичная станция имеет право начать передачу по собственной инициативе (обычно, в состоянии свободного канала), или по инициативе другой вторичной станции, например, в сетях кольцевой топологии. Вторичная станция может передать один, или несколько кадров, несущих, в первом случае, информацию об изменении её состояния или, в кольцевых топологиях, – кадры данных. Ясно, что режимы NRM и ARM используются в несбалансированных топологических архитектурах (рис. 6.3), и предполагают наличие механизма опроса вторичных станций. Передача данных может вестись как в полудуплексном, так и в дуплексном режимах. Первичная станция Команда Ответ Вторичная станция Вторичная станция Вторичная станция Рисунок 6.3. Несбалансированная архитектура станций HDLC 3. Асинхронный сбалансированный режим (Asynchronous Balance Mode, ABM) используется только комбинированными станциями и предусматривает возможность каждой из них инициировать обмен данными. Этот режим чаще всего используется в современных сетях для управления каналами двухточечных соединений 318 между маршрутизаторами. По двухпроводным линиям данные передаются в полудуплексном режиме, по четырёхпроводным – в дуплексном режиме. Формат кадра HDLC (рис. 6.4) определен достаточно гибко и даёт возможность реализации всех перечисленных режимов передачи данных. Для некоторых из полей предусмотрены два варианта размеров – первый для обычного режима и второй – для опционального, устанавливаемого по соглашению сторон. 8 8/16 8/16 Флаг Адрес Управление 16/32 Данные FCS Флаг Рисунок 6.4. Формат кадра HDLC Каждый кадр ограничивается 8-битными стартстопными последовательностями 01111110 (флаги). Предупреждение ошибочного определения границ кадра требует исключения возможности появления в поле данных флаговой последовательности бит. Это достигается вставкой нулевого бита после любой последовательности из пяти «1» в поле данных. Приемник просматривает принимаемую последовательность битов и определяет начало кадра по последовательности из шести «1», за которой следует «0»; далее он «вычеркивает» в оставшейся части кадра любой «0», следующий за пятью единицами, восстанавливая тем самым исходную информационную последовательность. Флаговая последовательность может постоянно передаваться в промежутке между кадрами, поддерживая синхронизацию задающих генераторов взаимодействующих узлов. В этом случае, обнаружение последовательности бит, не являющейся флагом, будет свидетельствовать о начале кадра. В HDLC определён также флаг (сигнал) аварийного завершения (abort), который представляется последовательностью не менее семи и не более четырнадцати единиц. Этот флаг может помещаться в кадр в процессе его передачи. Приемник, обнаружив сигнал аварийного завершения, отбрасывает принятую часть кадра. 319 Поле «Адрес» занимает 8 или 16 бит (опционально). Оно актуально для управления передачей на линиях с многоточечными подключениями, например, при организации связи хост-компьютера с терминальными устройствами, подключенными к одной физической линии. В несбалансированных архитектурах (режимы NRM и ARM) в поле «Адрес» всегда указывается адрес вторичной станции; в режиме ABM командный кадр имеет адрес получателя, а кадр ответа – адрес отправителя. Для двухточечных каналов и режиме ABM это поле не актуально и его заполнение оговаривается отдельно. Адрес, состоящий только из единиц (11111111) называется глобальным. Он используется только в кадрах–командах и означает «все станции». Принимающие станции должны ответить на него, указав в кадрах ответов свои индивидуальные адреса. Адрес, первые восемь бит которого содержат только 0, используется в тестовых целях; он не назначается станциям, и они не должны отвечать на командный кадр с таким адресом. В HDLC возможно использование 16-битной адресации. При этом, нулевое значение младшего бита первого байта адреса означает, что следующий байт также относится к полю адреса и во втором байте младший бит устанавливается в 1. Таким образом можно назначить 16 382 адреса. Протокол HDLC определил три типа кадров: информационный (I-кадр), управляющий (S-кадр) и ненумерованный (U-кадр). Кадры первых двух типов обеспечивают сервис надежной передачи (с предварительным установлением соединения и подтверждением доставки); при этом I-кадр всегда интерпретируется как команда, а S-кадры могут быть и командами, и ответами. Ненумерованные кадры используются для передачи команд и ответов в фазах установления и ликвидации соединений, а также для передачи данных в режиме без установления соединения и без подтверждений. Структура управляющего поля для кадров разных типов представлена на рис. 6.5. 320 Информационный кадр в первом бите управляющего поля содержит «0»; «10» в первых двух битах этого поля определяют кадр управления и «11» в этих же битах указывают, что это ненумерованный кадр. 1 2-4 5 N(S) P/F P/F S 6 - 8 биты биты 2-7 N(R) N(S) P/F N(R) I-кадр N(R) 1 0 S S 0 0 0 P/F N(R) S-кадр 1 S 1 1 M M P/F M M M U-кадр 8 9 - 16 1 б) а) Рисунок 6.5. Управляющие поля кадров HDLC а) базисный формат и б) расширенный Во всех типах кадров поле "Управление" содержит бит P/F (Poll/Final). В несбалансированных режимах (NRM, ARM) первичная станция, отсылая кадр с установленным в «1» битом P/F, предлагает терминалу ответить; терминал во всех, кроме последнего, кадрах своего ответа (их может быть несколько) этот бит устанавливает в «0», а в последнем кадре – в «1». В сбалансированном режиме (ABM) «1» в этом поле несёт указание другой машине немедленно, т.е., не ожидая «попутного» информационного кадра, отправить ответ (это может быть использовано механизмом ARQ); при этом, в ответе бит P также устанавливается в 1. Надёжность передачи протокол HDLC обеспечивает процедурами повторной передачи кадров (ARQ), а управление потоком – посредством механизма скользящего окна. Поле N(S) в информационном кадре предназначено для записи порядкового номера отправляемого кадра ( S recent в процедурах ARQ); поле N(R) в информационном и управляющем кадрах предназначено для записи номера следующего кадра, «ожидаемого» приемником ( Rnext ). В базовом варианте спецификации протокола для полей N(S) и N(R) отведено всего по 3 бита; это ограничивает максимальный размер окна передачи для ARQ с возвратом на N значением Ws  7 , а для ARQ с выборочным повторением – Ws  4 . В более позднем варианте 321 протокола поле «Управление» расширено до 16 бит, из которых для порядковых номеров выделены по 7 бит. Соответственно, окно передачи Ws может принимать значения до 127 (ARQ GBN) или до 64 (ARQ SR). Биты SS управляющего кадра используются для индикации сообщений, поддерживающих надёжный сервис передачи данных. SS = 00 К приему готов (Receive ready, RR); используется как сообщение АСК на кадры с номерами N(R) - 1 и менее. SS = 01 Кадр отброшен (Reject, REJ), соответствует сообщению NAK; уведомляет отправителя о наличии ошибки в принятом кадре и необходимости повторения передачи всех кадров, начиная с кадра N(R); (Go-Back-N ARQ). SS = 10 К приему не готов (Receive not ready, RNR). Этим сообщением подтверждается прием всех кадров с номерами до N(R) - 1 и получатель сообщения информируется о возникновении временных проблем (нет свободного буферного пространства, например). Это сообщение может использоваться для управления потоком. SS = 11 Выборочное уничтожение кадра (Selective reject, SREJ). Этим сообщением указывается, что кадр с номером N(R) отброшен и должен быть передан повторно. Используется процедурой ARQ с выборочным повторением. Ненумерованные кадры используются, прежде всего, для установления и ликвидации соединения. Например, сообщениями SNRM (Set NRM) и SABM (Set ABM) отправитель информирует о желаемом режиме информационного обмена; сообщения SNRME и SABME указывают на использование расширенного формата поля «Управление»; для подтверждения приема ненумерованного кадра используется сообщение UA (Unnumbered Acknowledgement), а об отбрасывании кадра извещается сообщением FRMR (Frame Reject). Для индикации необходимости разъединения используется ненумерованный кадр DISC (Disconnect). Для различения этих и ряда других сообщений, переносимых ненумерованными 322 кадрами, зарезервированы пять бит (биты M на рис. 6.5), что позволяет определить 32 различных команд/ответов; реально используется значительно меньшее их число. Ненумерованные кадры (UI) также используются для передачи протокольных блоков сетевой службы, не требующей сервиса надежной передачи. Размер поля «Данные» строго не определен; его максимально допустимое значение задаётся конфигурационной переменной протокола. 16- или 32-битное контрольное поле (Frame Checking Sequence, FCS) содержит контрольные биты, вычисленные посредством алгоритма CRC; оно защищает как заголовок, так и поле данных. Рисунок 6.6 представляет схему обмена кадрами в фазах установления–ликвидации соединения, а рис. 6.7 иллюстрирует дуплексную передачу данных в асинхронном сбалансированном режиме. А SABM t Передача данных UA DISC UA t B Рисунок 6.6. U-кадры в фазах установления и ликвидации соединения Станция A направляет ненумерованный кадр SABM, сообщая станции В, что она желает установить соединение в асинхронном сбалансированном режиме (подразумевает двунаправленный обмен). Станция В кадром UA подтверждает установление соединения. Поскольку кадры управления никогда не передаются «пачками», то необходимости их нумерации нет. Далее осуществляется передача данных (последовательности кадров) и по инициативе станции В, направившей кадр DISC, соединение, после получения подтверждения UA, ликвидируется. В фазе передачи данных (рис. 6.7) используются I-кадры, которые всегда являются командами, поскольку они требуют подтверждения приема, и управляющие кадры (RR и RNR), которые могут быть и командами, и ответами, а кадр REJ – всегда является ответом. При этом, поле «Адрес» в команде содержит адрес получателя, а в ответе – адрес отправителя. В 323 рассмотренном выше примере предполагалось, что величина окна передачи составляет 4 кадра. A B (B, I,0,0 (B, )I,1,0 (B, I,2,0) (B, )I,3,1 ) Сдвиг окна вправо на 1 и (B, I, 4,3) передача кадра № 4 (A, I, 0, 0) (A, I, 1, 0 Кадры в пределах окна передачи Повторная отправка кадров № 1 – 4 и ACK (3) для B ) (A, I, 2, 1 ) (B, REJ, 1) (A, I, 3, 1 ) (B, I, 1, 4 (B, I,) 2, 4 (B, I,) 3, 4) (B, I, 4, 4) (B, RR, 2) (B, RR, 3) (B, RR, 5) t Получен (B, I, 2, 0), ожидался (B, I, 1, 0); отсылается REJ (1); (B, I, 2, 0), (B, I, 3, 1) и (B, I, 4, 1) уничтожаются У В нет данных для А; подтверждение приема кадрами RR. t Рисунок 6.7. Передача данных, режим ABM Обратим внимание на отсутствие в структуре заголовка кадра HDLC поля, идентифицирующего протокол, которому предназначается размещенная в поле «Данные» информация. Исходная спецификация HDLC предполагает, что на станциях работает лишь один сетевой протокол и вопрос «Кому передать поле данных?» не актуален. Это, конечно, заметное ограничение возможностей HDLC. В ряде фирменных его реализаций (например, в операционных системах Cisco) поле «Протокол» введено в явном виде за счет сокращения поля «Данные»; существует оно и в протоколе PPP. 6.2. Протоколы PPP и PPPoE Здесь будут рассмотрены протоколы, управляющие передачей данных по каналам «точка-точка» в Интернет. Такие соединения создаются между узлами маршрутизации трафика в сети или для подключения домашнего ПК к узлу сервис–провайдера. Применение для этих целей протокола HDLC в некоторых отношениях идентификации недостаточно протоколов сетевого 324 (отмеченное уровня, уже отсутствие ограниченность его мониторинговых функций), а в других – избыточно (потребность в надежном канальном сервисе возникает относительно редко). Эти и ряд других соображений послужили основанием создания канального протокола, который работает на двухточечных соединениях поверх любых последовательных полнодуплексных линий. Этот протокол получил название Point-to-Point Protocol (РРР). Point–to–Point Protocol инкапсулирует пакеты сетевого протокола в поле данных своих кадров и организует их передачу. Кроме формирования информационных кадров и обнаружения в них ошибок, протокол выполняет:  конфигурирование и тестирование канала (группа процедур Link Control Protocol, LCP),  передачу конфигурационных параметров протоколов сетевого уровня (группа процедур Network Control Protocol, NCP). В отличие от HDLC, протокол PPP не содержит механизмов надежного сервиса. Он обеспечивает неподтверждаемый коммуникационный сервис с предварительным установлением соединения. 8 8 8 16/32 16 Флаг Адрес Управление 11000000 01111110 11111111 Протокол Данные FCS Флаг HDLC–кадр UI Рисунок 6.8. Формат кадра РРР Структура кадра РРР (рис. 6.8) является производной от структуры кадра HDLC. Кадр всегда начинается и заканчивается HDLC–флагами. Однако, в отличие от HDLC, PPP является байт–ориентированным; его поле данных выравнивается по границам байта посредством битов заполнения. В случае появления флагового байта в поле данных, перед ним добавляется специальная ESC-последовательность (01111101) и шестая единица в байте информационного потока инвертируется; когда приемник встречает такой ESC-символ, то в следующем за ним байте шестой бит инвертируется. Аналогично, комбинация информационных 325 бит, совпадающая с ESC-символом, предваряется ещё одним ESC-символом, а в информационной последовательности третий бит устанавливается в ноль. Поле адреса, обычно, содержит все «1», что для HDLC служит признаком глобального адреса, но поскольку в соединении участвует лишь два узла, то это поле особого смысла не имеет. Поле управления заполняется последовательностью 11000000, т. е. содержит указание на использование ненумерованных кадров HDLC. Соответственно, надежная передача кадров не выполняется (сетевой уровень редко требует её от канального уровня). Поскольку РРР часто используется для связи маршрутизаторов, а последние обычно являются мультипротокольными, то потребовалось поле «Протокол», в котором указывается соответствующий код (0x0021 – IP, 0x002b – IPX и т. д.). Для генерации битов поля FCS используются полиномиальные коды CCITT-16 или CCITT-32. В поле данных PPP-кадра может быть вложен пакет сетевого протокола, одно LCP– или NCP–сообщение. В двух последних случаях в поле «Протокол» указываются соответствующие коды: LCP – 0xC021 и NCP – 0x8021. Процедуры LCP решают задачи установления соединения, конфигурирования канала между узлами и его ликвидации. На этапе конфигурирования согласуются параметры, независящие от особенностей сетевого протокола. Каждое LCP–сообщение имеет заголовок, содержащий поля «Код», «Идентификатор» и «Размер». Код определяет допустимый набор управляющих сообщений. В таблице 6.1 приведены некоторые из описанных в RFC 1661 LCP–сообщений. В колонке «Направление передачи» таблицы 6.1 символом «И» обозначен инициатор соединения, а символом «О» - ответчик. Поле «Идентификатор» согласованность запросов и ответов конфигурации. 326 обеспечивает взаимную Таблица 6.1 Код Сообщение Направл. передачи Описание содержания сообщения 1 Configure-Request И→О Запрос соединения и предлагаемые параметры 2 Configure-ACK И←О Согласие с предлагаемыми параметрами 3 Configure-NAC И←О Отказ от предлагаемых параметров соединения 4 Configure-Reject И←О Параметры соединения не приемлемы 5 Terminate-Request И→О Запрос разрыва соединения 6 Terminate-ACK И←О Согласие с разрывом соединения 7 Code-Reject И←О Получен запрос с неизвестным кодом 8 Protocol-Reject И←О Запрашивается неизвестный протокол 9 Echo-Request И→ О Запрос эха (тестирование линии) 10 Echo-Replay И←О Эхо-ответ (тестирование линии) 11 Discard-Request И→ О Уничтожить кадр (тестирование линии) Жизненный цикл PPP-соединения включает все стадии от тестирования и настройки физического канала до передачи данных и освобождения ресурсов, задействованных в соединении (рис. 6.9) Соединение закрыто 1.Соединение отсутствует Запуск 1. Соединение отсутствует 2. Согласование параметров соединения (LCP-процедуры) логического 3. Проверка прав доступа. соединения 4. NCP-процедуры конфигурации Отключение Соединение сетевого протокола (IP-адрес, …). Неудача согласовано 5. Информационный обмен (пакеты 5. Предоставление IP в кадрах PPP). 3. Аутентификация сервиса 6. NCP-процедура ликвидации соединения. Успех 4. NCP конфигурация Подключение 6. Ликвидация логического соединения Неудача 2. Установление Рисунок 6.9. Сценарий установления /ликвидации РРР–соединения Для установления логического соединения «точка-точка» по протоколу PPP оба участника сначала посылают LCP–сообщения, чтобы сконфигурировать и протестировать канал. Далее, сетевые объекты могут быть подвергнуты взаимной аутентификации. При её положительном результате PPP посылает сообщение NCP для выбора и конфигурирования 327 протокола сетевого уровня. Для каждого поддерживаемого сетевого протокола существует свой NCP, например, IP Control Protocol (IPCP), NetBIOS Frames Control Protocol (NBFCP), IPv6 Control Protocol (IPV6CP) и т.д. Все они настраивают сетевые адреса и включают / выключают модули соответствующих протоколов на обоих концах канала PPP. Сообщения NCP аналогичны первым семи LCP–сообщениям (табл. 6.1). После успешного завершения этой фазы, пакеты протокола сетевого уровня могут приниматься и пересылаться по логическому каналу в кадрах PPP. Канал будет оставаться сконфигурированным для связи до тех пор, пока специальные кадры LCP или NCP явно не закроют его, или пока не произойдет некоторое внешнее событие (срабатывание таймера неактивности, вмешательство администратора и т. п.). Протокол PPP способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно для увеличения пропускной способности логического канала за счет организации нескольких параллельных физических каналов. Итак, PPP входит в семейство HDLC-протоколов и обеспечивает управление передачей данных по асинхронным и синхронным физическим линиям связи. Он выполняет установление и согласование параметров соединения, обнаружение ошибок, а также, конфигурирование протоколов сетевого уровня. Сервис надёжной передачи им не поддерживается. PPP в сетях Ethernet Одной из весьма востребованных ветвей PPP стал протокол PPPoE (Point-to-Point Protocol over Ethernet). Вследствие широкого использования технологии Ethernet для подключения индивидуальных пользователей к узлам провайдеров Интернет-сервиса (рис. 6.11) стали актуальными задачи управления индивидуальными соединениями, в том числе, аутентификация и авторизация пользователей, подсчет объема переданного и принятого трафика. Механизмами протоколов Ethernet эти задачи не решаются, а PPP содержит почти все эти функции, но работает на двухточечных соединениях. 328 Протокол PPPoE предоставил механизм идентификации PPP-сессий в широковещательной Ethernet-среде. Сообщение PPPoE размещается в поле данных кадра Ethernet и имеет формат, представленный на рис. 6.10. 4 8 15 Код Тип Версия Идентификатор сессии Размер Данные Рисунок 6.10. Формат сообщения PPPoE Поля «Версия» и «Тип» в настоящее время имеют значение 0x1. Значения поля «Код» зависят от типа сообщений, пересылаемых в поле «Данные». Сервер AAA G Sw 100E GE Сеть ISP GE R Сервер DHCP G - шлюз пользователя (PPPoE – клиент) Sw – Ethernet-коммутатор R – граничный маршрутизатор сети провайдера (PPPoE – сервер) Сервер ААА – сервер аутентификации и авторизации 100E G PPPoE Eth-h PPPoE-h PPP-h PPP-Data Eth FCS Кадр Ethernet Рисунок 6.11. Применение PPPoE в Ethernet-сети Существуют две стадии работы протокола – стадия обнаружения сервера соединений (создания сессии) и стадия собственно PPP (рис. 6.12). Стадия создания посредством сессии обмена реализуется сообщениями по PPPoE, модели «клиент-сервер» каждое из которых идентифицируется полем «Код». PPPoE-клиент инициирует поиск PPPoEсервера посредством широковещательной 329 рассылки Ethernet-кадра с протокольным кодом 0x8863. В поле данных этого кадра помещается сообщение протокола PPPoE Active Discovery Initiation (PADI), которое имеет в поле «Код» значение 0x09. Все PPPoE-серверы, получающие этот широковещательный запрос, отвечают сообщением PADO (Active Discovery Offer, код 0x07), предлагая свои «услуги». Клиент получает эти ответы, содержащие адреса отправивших их серверов, и выбирает какой-то один для дальнейшей работы. Свой выбор он подтверждает сообщением PADR (Active Discovery Request, код 0x19), отправляемом выбранному серверу. Согласие на установление сессии этот сервер заявляет сообщением PADS (Active Discovery код Session-confirmation, уникальный 16-битный 0x65), идентификатор в котором формируемой отправляет сессии. и Этот идентификатор будет включаться в заголовок PPPoE всех сообщений, отправляемых между клиентом и сервером. Тем самым, появляется возможность уникально идентифицировать весь обмен между конкретными устройствами, подключенными к широковещательной канальной инфраструктуре. G Сервер AAA R PPPoE (AD) Создание соединения «точка-точка» и получение его идентификатора PPP LCP Конфигурирование соединения (MTU,..) PPP LCP Аутентифиация PPP NCP Конфигурирование IP стека PADI PADO PADR PADS (SId) Config. Request Config. ACK Challenge Response Success RADIUS-Request RADIUS-Response IP-Addr.-Request IP-Addr.-Response Данные PPP NCP Мониторинг соединения Echo-Request Echo-Replay Рисунок 6.12. Реализация PPPoE-соединения 330 Установление PPPoE-соединения продолжается стадией PPP, на которой выполняются типичные для этого протокола процедуры согласования параметров канала, например, максимально допустимого размера поля данных (MTU), типа аутентификации и тому подобного. Все необходимые на этой стадии сообщения инкапсулируются в кадры Ethernet c протокольным реализуется PPPoE-сервер кодом по 0x8864 схеме, средствами (PPP). Фаза предусмотренной протокола PPP аутентификации обычно рекомендациями 802.1х. запрашивает логин/пароль пользователя и ответ клиента отправляет серверу AAA (Authentication, Authorization, Accounting) для проверки и определения полномочий пользователя. При положительном исходе проверки реализуются процедуры, предусмотренные протоколом PPP для управления соединением и, наконец, для передачи данных. Пример структуры кадра Ethernet, переносящего сообщения PPP-overEthernet и PPP, представлен ниже. Об инкапсуляции в Ethernet-кадр сообщения PPPoE говорит наличие в поле Protocol заголовка Ethernet соответствующего идентификатора (0х8863 на стадии создания сессии или 0х8864 – на всех остальных). Ethernet Header SrcAdr: 00:50:da:42:d7:df DstAdr: ff:ff:ff:ff:ff:ff Protocol: 0x8863 {Discovery Stage или PPP Session Stage (0x8864)}. PPoE Header Version (4b): 1 Type (4b): 1 Code (8b): 0x09 {Active Discovery Initiation} Session ID (16b): 0x0000 Payload Length (16b): 24 PPoE Payload {Discovery Stage} PPPoE Tags TagType: Service-Name {других ее параметров нет} TagType: Host-Uniq (16 b) TagLenght: 2 (Binary Data, 16 b) - {размер поля TagValue в байтах} TagValue: 11000111 01011100 331 {PPP Session Stage} PPP PROTOCOL-ID = 0x0021 (2 bytes) – {код IP-протокола} PPP payload (<= 1492 bytes) Данные, необходимые для установления соединения (идентификаторы узлов, наименование сервиса, имя сервера PPPoE и т. п.), представляются структурой «Метка» («Tag»). Её поля «Тип, Размер, Значение» занимают, соответственно, 2 байта, 2 байта и сколько надо. Метка типа «Service-Name» может содержать имя поставщика сервиса, или требуемый класс обслуживания; полей «Размер» и «Значение» у неё нет. Если значение TagLenght для этой метки равно нулю, то это означает приемлемость любого вида сервиса. Метка "Host-Uniq" задается хостом для уникальности ассоциации ответов сервера соединения на его запросы (PADI и PADO). Поле "TAG VALUE" в этом случае может содержать любую последовательность бит, заданную хостом; сервер соединений просто копирует ее в свои ответы. Заметим, что MTU для кадра PPPoE составляет 1492 байта а не 1500 байт, обычных для Ethernet. «Потерянные» 8 байт это: 6 байт - заголовок PPPoE и 2 байта - поле «Протокол» из заголовка PPP. Поля «Адрес» и «Управление» из заголовка РРР в заголовке PPoE не используются. Заключение к разделам 6.1 и 6.2 Придание физической линии между двумя узлами сети свойств надежной транспортной системы является основной задачей протоколов канального уровня. Канальные протоколы, в общем случае, выполняют следующие процедуры:  формирование кадров,  адресацию устройств,  обнаружение ошибок и восстановление поврежденных кадров,  управление интенсивностью генерации кадров. Во многих сетевых стеках канальные протоколы являются вариантом протокола HDLC, который обеспечивает:  сервисы передачи данных с установлением соединения, 332  управления потоком посредством механизма скользящего окна,  генерацию сигналов On/Off для регулирования интенсивности потока. Канальным протоколом в Интернет является протокол PPP; он оперирует ненумерованными кадрами HDLC и предоставляет ориентированный на соединения ненадежный сервис. Этот протокол также содержит определённые функции автоконфигурирования сетевых интерфейсов конечных станций. Применение протокола PPPoE позволило в среде Ethernet решить задачи аутентификации и управления пользователями, обеспечить изоляцию трафика их станций. 333  сервисы передачи данных с установлением соединения,  управления потоком посредством механизма скользящего окна,  генерацию сигналов On/Off для регулирования интенсивности потока. Канальным протоколом в Интернет является протокол PPP; он оперирует ненумерованными кадрами HDLC и предоставляет ориентированный на соединения ненадежный сервис. Этот протокол также содержит определённые функции автоконфигурирования сетевых интерфейсов конечных станций. Применение протокола PPPoE позволило в среде Ethernet решить задачи аутентификации и управления пользователями, обеспечить изоляцию трафика их станций. 6.3. Протоколы локальных сетей IEEE 802.3 Базовые спецификации современных локальных сетей разработаны комитетом 802 Американского института электро- и радиоинженеров (Institute of Electrical and Electronic Engineers, IEEE). Эти спецификации имеют статус рекомендаций и описывают сети Ethernet, Token Ring, FDDI, группу беспроводных сетей и ряд смежных технологий. В них определен стек уровневых протоколов (рис. 6.13), который соответствует канальному и физическому уровням в стеке протоколов ВОС. Сетевой уровень Сетевой уровень 802.2 Logical Link Control ⋯ 802.15.4 ⋯ OFDM DSSS FHSS STP16 802.11.xx 802.5 802.15.xx Token Ring Wireless LAN Wireless PAN STP4 ⋯ 100BaseLX 10BaseT 802.3.xx Ethernet Канальный уровень Физический уровень ВОС IEEE 802 Рисунок 6.13. Соотношение уровневых протоколов моделей IEEE 802 и ВОС 333 Первые спецификации протоколов семейства IEEE 802 были разработаны и приняты в начале 1980 годов; они обобщали ряд существовавших отраслевых и фирменных протоколов локальных сетей (варианты Ethernet, Token Ring и т. д.). В этих сетях использовались различные дисциплины доступа к среде передачи и их МАС–уровни были существенно разными. Учитывая это обстоятельство и заинтересованность потребителей в сетях разных технологий, комитет 802 образовал ряд подкомитетов, результатом работы которых стали спецификации основных вариантов ЛС: 802.3 зафиксировала основные механизмы технологии Ethernet, 802.4 – маркерной шины, 802.5 – маркерного кольца и т. д. Разработка спецификаций новых технологий ЛС продолжается и в настоящее время (в основном, в области высокоскоростных, беспроводных и сенсорных сетей). Общим свойством MAC-протоколов локальных сетей, принятых комитетом 802, являлось предоставление ими только одного вида сервиса, а именно, сервиса передачи без предварительного установления соединения и без подтверждений. Для расширения функциональности канальных протоколов до уровня модели ВОС в стек IEEE 802 был введен подуровень управления логическим каналом (Logical Link Control, LLC). Он также нивелировал некоторые особенности механизмов взаимодействия сетевого и канальных уровней, присущие отдельным MAC–протоколам. Разнообразие используемых в локальных сетях сред передачи, битовых скоростей интерфейсов, схем преобразования битов в сигналы и т. п. привело к необходимости определения в спецификации каждой ЛС набора физических уровней. Таким образом, основными особенностями протокольной модели IEEE 802.х, в сравнении с эталонной моделью ВОС, можно считать:  расщепление канального уровня на независящий от метода доступа к среде передачи LLC–подуровень и МАС–подуровень, определяющий правила доступа к среде; 334  множественность MAC–протоколов;  зависящая от вида среды передачи множественность протоколов физического уровня. 6.3.1. Управление логическим каналом Подуровень LLC является общим для всех сетей IEEE 802.x и, по замыслу его разработчиков, позволяет унифицировать взаимодействие канального и сетевого уровней. В результате, именно LLC-подуровень стал ответственным за формирование логического канала между узлами сети (рис.6.14); непосредственное же взаимодействие МАС–подуровней спецификации 802.х не предусматривают. Пакеты Сетевой уровень Сетевой уровень NL PDU DL SDU DL SDU Кадры LLC DL PDU Кадры LLC DL PDU LLC MAC MAC MAC Физический уровень Физический уровень Физический уровень Сигналы Сигналы Рисунок 6.14. Канальный уровень в сетевом стеке IEEE 802 Концептуально IEEE 802.2 базируется на HDLC. У него такая же форма организации обмена данными в виде команд и ответов, те же три типа кадров (I, S, U). Как и всякий канальный протокол, LLC должен однозначно адресовать свой сервис (источник и получатель SDU должны знать, как воспользоваться службами канального уровня). Для этого, модули LLC на каждом узле получают адреса точек доступа к сервису (Service Access Point, SAP), которые указываются в заголовке протокольного блока LLC (рис. 6.15); это позволяют логически обособить потоки данных разных потребителей канального сервиса. Так, например, 0х06 является адресом точки доступа для протокола IP, а 0хE0 – для IPX. 335 Система адресации LLC предусматривает назначение индивидуальных и групповых адресов (младший бит в поле «SAP получателя»). Например, 01000000 и 11000000 являются индивидуальным и групповым адресами службы управления протокола LLC. Кадры команд и ответов индицируются младшим битом в поле «SAP отправителя». 1 байт 1 байт 1 / 2 байта SAP SAP получателя отправителя Управление Данные В формате HDLC SAP SAP I/G получателя C/R отправителя 1 бит 7 бит 1 бит 7 бит I/G – индивидуальный (0)/групповой (1) адрес C/R – команда/ответ SAP отправителя – всегда индивидуальный Рисунок 6.15. Структура блока данных протокола LLC Следует отметить странность наличия двух SAP в одном кадре; это подразумевает, что услугу канального уровня инициирует один протокол (например, IP), а обрабатывать доставленные получателю данные должен модуль другого протокола (например, IPX), или на двух узлах одинаковые протоколы имеют разные имена (коды). Всё это крайне мало вероятно. В целом, уровень LLC дополняет возможности адресации МАС–подуровней стека IEEE 802.x, оперирующих аппаратными адресами сетевых узлов и не имеющих, как и HDLC, возможности указать в заголовке своих протокольных блоков конкретного получателя поля «Данные». Основной задачей подуровня LLC является дополнение традиционно предоставляемого МАС–уровнями локальных сетей сервиса ненадёжной передачи сервисами, предусмотренными канальным уровнем модели ВОС. Для этого необходимы процедуры восстановления ошибочных кадров и управления соединениями. Их реализацию обеспечивает 8– или 16–битное поле «Управление» LLC-заголовка. Его структура и содержание практически полностью аналогичны одноимённому полю заголовка кадра HDLC. 336 Протокол LLC также оперирует тремя типами кадров: I–, S–кадры с 16-битным и U–кадры с 8-битным полем «Управление». Используя эти типы кадров подуровень LLC предоставляет три вида сервиса. 1. Неподтверждаемый без предварительного установления соединения, сервис типа 1 и LLC-кадр типа 1; реализуется кадрами типа UI, у которых поле управления содержит последовательность 11000000. Этот сервис наиболее востребован в ЛС; он хорошо соответствует требованиям дейтаграммных сетей IP и IPX. 2. Сервис надежной доставки данных с предварительным установлением соединения (сервис и кадр LLC2). Реализуется I– и S–кадрами c 16-битным полем «Управление». Этот тип сервиса в ЛС применяется редко. Он востребован в сетях, транспортный протокол которых не поддерживает надежную доставку. Примерами могут служить:  сети SNA (System Network Architecture) корпорации IBM, в которых рабочие станции сети Token Ring взаимодействуют с хост-компьютером;  одноранговые сети Windows с протоколами NetBIOS / NetBEUI; Сервис LLC2 используется также для непосредственного подключения принтеров Hewlett-Packard к сети Ethernet. 3. Сервис подтверждаемой доставки кадров без предварительного установления соединения (сервис и кадр LLC3). Подтверждается приём каждого кадра. Этот сервис актуален для систем управления техническими объектами, когда дополнительные временные задержки на установление соединений неприемлемы, но подтверждение приема команд необходимо. 6.3.2. Управление доступом к среде в сетях Ethernet В этом разделе будут рассмотрены несколько спецификаций, на базе которых строятся современные ЛС. Рассмотрение каждой из них будет затрагивать МАС–протокол, структуру кадра и некоторые особенности физического уровня. Напомним, что обязательной службой канального уровня в стеке протоколов ЛС является служба доставки данных без 337 предварительного установления соединения. Для её поддержания функции подуровня LLC, вообще говоря, не нужны, поскольку этот сервис обеспечивают все MAC–протоколы. Протокол Ethernet был разработан в начале 1970-х годов фирмой Xerox для объединения рабочих станций. В последующие 10 лет были созданы ряд фирменных реализаций технологии, отличающихся в некоторых деталях, что приводило к несовместимости оборудования основных производителей. В начале 1980-х годов корпорации DEC, Intel и Xerox завершили совместную разработку стандарта Ethernet DIX (Ethernet II) для сетей со скоростью передачи данных 10 Мбит/с и «толстым» (диаметром 12 мм) коаксиальном кабелем в качестве среды передачи. Первая из спецификаций комитета 802.3, опубликованная в 1983 году, в качестве MAC–подуровня приняла Ethernet DIX с некоторыми изменениями в заголовке кадра. На физическом уровне для преобразования бит в сигналы, как и в Ethernet II, был принят метод манчестерского кодирования. Основным достоинством этого кода, как уже обсуждалось в разделе 3.3.1, является его хорошая самосинхронизация. Несмотря на то, что код порождает сигнал с относительно широким спектром, рабочая полоса частот используемых кабелей (не менее 20 МГц) позволяла вести надежную передачу с битовой скоростью 10 Мбит/с. Спецификации семейства IEEE 802.3 регулярно пересматриваются и расширяются каждые несколько лет. Так, были разработаны спецификации для различных сред передачи: «тонкого» коаксиала (6 мм), «витой пары», многомодового и одномодового волоконно-оптических кабелей. В 1995 году было одобрено описание технологии Fast Ethernet (100 Мбит/с), в 1998 – Gigabit Ethernet (1000 Мбит/с), в 2004 - 10Gigabit Ethernet, а в 2010 г. – 40/100 Gigabit Ethernet. Перечисленные спецификации отличаются, главным образом, реализацией физического уровня, сохраняя неизменным формат кадра и основные операции MAC–протокола, что и обеспечивает их совместимость. 338 6.3.2.1. Особенности алгоритма доступа к среде и его эффективность Спецификация IEEE 802.3 предусматривала шинную топологию сети и общую среду передачи. Для управления доступом станций к среде передачи применяется алгоритм МДКН/ОК. Напомним схему его функционирования. Станция, имеющая кадр для передачи, контролирует состояние среды и, если обнаруживает её свободной, то с некоторой случайной задержкой начинает передачу кадра, продолжая при этом контролировать состояние среды. Отсутствие коллизии в течение интервала 2t p свидетельствует об успешном захвате среды передачи и передача кадра продолжается до завершения. Отправленный кадр получают все станции сети и, в зависимости от его типа, обрабатывают. При этом, если адрес назначения кадра индивидуальный, то все, кроме целевой станции, кадр уничтожают. Если адрес широковещательный – кадр обрабатывают все станции. Однако, если в интервале времени 2t p от начала передачи кадра фиксируется коллизия, то обе вовлечённые в неё станции прекращает передачу. Далее, посредством случайного выбора из определенного интервала находится величина задержки до начала следующей попытки передачи (процедура «отката»). Если (n - 1)-я попытка передачи кадра оказалась неудачной, то значение задержки (измеряемое числом тайм-слотов, длительностью 2t p ) до следующей, n-й попытки захвата среды выбирается из диапазона [0, 2k  1], k  min{n, 10} . Удвоение верхней границы этого диапазона при каждой неудачной попытке передачи кадра увеличивает вероятность последующего успеха доступа, поскольку случайные задержки начала очередной передачи конфликтующие станции выбирают из более широкого диапазона. Максимальное количество попыток повторных передач равно 16, после чего кадр уничтожается. Тайм-слот в алгоритме доступа к среде принимается равным 2t p . Этот параметр является критически важным для систем, использующих алгоритм МДКН/ОК. Разработчики технологии Ethernet DIX приняли битовую 339 скорость передачи в канале 10 Мбит/с и максимальный диаметр сети 2500 м. Построение сети такого диаметра с учетом потерь в толстом коаксиальном кабеле требовало включения 4 повторителей. В этих условиях, максимальное удвоенное время распространения сигнала между двумя станциями (с учетом задержек в повторителях) могло составлять 51.2 мкс. Этот интервал времени при скорости передачи 10 Мб/с соответствует 512 битовым интервалам (длительность битового интервала чуть меньше 0.1 мкс). Отсюда было получено ограничение на минимальный размер кадра – 64 байта. При его меньшем размере существовала бы опасность пропуска коллизии. Действительно, отправитель должен «владеть» каналом в момент получения потенциально возможного сигнала коллизии, иначе у него не будет достаточных оснований считать этот сигнал результатом столкновения его кадра, а не кадра какой-то другой станции, захватившей канал уже после завершения им передачи. Максимальное значение величины кадра было принято равным 1518 байт. При нагрузке канала близкой к предельной (т. е., в любой момент есть кадр, ожидающий передачу), распределение во времени состояний канала представлено на рис. 6.16. L /R передача кадра Tc IFG захват канала передача кадра t Рисунок 6.16. Состояния канала при случайном методе доступа Среднее время захвата канала очень изменчиво и определяется многими факторами. Найденное в разделе 5.1.1.3.2 значение Tc  2e  t p может рассматриваться лишь как его оценка снизу. Межкадровый интервал (InterFrame Gap, IFG), t p необходимый для того, чтобы все станции могли зафиксировать завершение передачи предыдущего кадра, также зависит от расстояния между станциями; его оценкой сверху может быть интервал t p . Но в спецификации Ethernet DIX оно принято равным 96 битовым интервалам (~ 9.6 мс). С учётом этих задержек отправки кадров 340 максимальная эффективность использования среды определяется выражением max  L/ R 1 .  L / R  t p  2et p 1  6,44a (6.1) При минимальном размере кадра параметр a  t p / X  25.6 / 51.2  0.5 , что обеспечивает величину max  0.237 . Для кадров максимального размера (1518 байт) a  0.02 , и метод МДКН/ОК обеспечивает весьма высокую эффективность использования пропускной способности среды, max  0.88 . С ростом нагрузки увеличивается среднее время задержки доставки кадров. В монографии [31] проведен анализ этой характеристики Ethernet канала. По причине громоздкости здесь он не приводится, а выражение (6.2) представляет его результат для случая, когда все кадры имеют одинаковый размер L, интервалы времени между поступлениями кадров случайны с экспоненциальным законом распределения, а моменты поступления кадров взаимно независимы. E[td ] 1  (4e  2)a  5a 2  4e(2e  1)a 2   X 2[1   (1  (2e  1)a ] (6.2) (1  e  2 a )(2 1  2ae 1  6a ) a    1  2ea 2 2(e e  a 1  1  e 2 a ) E[td]/X 20 a = 0,01 a = 0,2 10 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1,0 η Рисунок 6.17. Зависимость задержки передачи кадра от нагрузки для сети Ethernet Графики, соответствующие зависимости (6.2), для двух значений параметра а, представлены на рис. 6.17. Из (6.2) хорошо видно, что при 341 приближении нагрузки канала к  max  (1  6,44  a)-1 средняя задержка передачи растет очень быстро. Заметим также, что в силу случайного характера явлений коллизий и задержек повторной передачи время доставки кадра может испытывать значительные вариации. 6.3.2.2. Структура MAC кадра Структура кадра протокола доступа к среде, определенная спецификацией IEEE 802.3, приведена на рисунке 6.18. Кадр начинается семибайтовой преамбулой, каждый байт которой имеет вид 10101010. Эта последовательность генерирует сигнал, позволяющий синхронизировать тактовые генераторы сетевых станций. Далее следует стартовый байт 10101011. Эти два поля добавляются к кадру при передаче его физическому уровню и, обычно, в размере MAC-кадра они не учитываются. 7 байт 1 байт 6 байт 6 байт 2 байта Преамбула Старт Адрес получателя Адрес источника Размер (Тип) 4 байта Данные Заполнитель FCS от 64 до 1518 байт Младший бит старшего байта Поле «Адрес» xxxxxxx0 Индивидуальный адрес xxxxxxx1 Групповой адрес xxxxxx1x Локальный адрес xxxxxx0x Глобальный адрес 5 байт Рисунок 6.18. Структура кадра IEEE 802.3 и Ethernet II МАС протокол оперирует 48-битными адресами физических сетевых интерфейсов (Extended Unique Identifier, EUI–48), но процедура их назначения не является его задачей. Соответственно, адресные поля MAC кадра имеют размер 6 байт. Значение двух младших бит старшего байта этого поля определяет тип адреса (рис. 6.18). Кадры с индивидуальными адресами обрабатываются строго определённой 342 станцией, с групповыми и широковещательными – определенной группой станций и всеми станциями, соответственно. Нулевое признаком локального значение второго адреса, который младшего бита является назначен администратором самостоятельно и только им гарантируется его уникальность. Глобальная уникальность адресов обеспечивается централизованным назначением каждому производителю сетевых карт определенного идентификатора (выполняет IEEE). Этот идентификатор записывается в остальных битах старших (левых) трёх байт (00-00-0С — Cisco и т. п.); три младших байта задаются производителем и уникальны для каждого устройства. Таким образом, всё адресное пространство содержит 246 адресов. Поле «Размер» несет информацию о числе байт, содержащихся в поле. «Данные». Поскольку общий размер кадра не должен быть меньше 64 байт, то при величине информационного поля менее 46 байт кадр дополняется битами заполнения. Последние 4 байта содержат контрольную последовательность (FCS), вычисляемую как 32-битный полиномиальный код CRC; на время расчёта это поле заполняется нулями. Контрольная последовательность защищает все поля кадра, начиная от адреса получателя. Приёмный МАС–модуль проверяет допустимость размера кадра и выполняет расчет контрольной последовательности по тому же алгоритму, что и передатчик. При несовпадении результата расчета со значением поля FCS кадр уничтожается. В кадре Ethernet II на месте поля «Размер» находится поле «Тип», которое определяет модуль протокола (IP, IPX, ARP, PPPoE,…), которому необходимо передать содержимое поля «Данные» кадра. Идентификаторы этих протоколов имеют значения от 0х0600 и больше (в шестнадцатеричном формате). Вместе с тем, в кадре IEEE 802.3 в этом поле помещается размер поля «Данные», которое не может превосходить 0х05DC (1500). Таким образом, по значению, содержащемуся в этом поле, можно определить тип кадра (Ethernet II или IEEE 802.3) и, тем самым, смысл этого поля. Спецификация IEEE 802.3, не определяя в заголовке МАС-кадра тип 343 протокола вышестоящего уровня, предполагает использование подуровня LLC, который и обеспечивает идентификацию протоколов верхнего уровня посредством полей SAP в LLC-заголовке (рис. 6.14). Спецификация 802.3 не отменила Ethernet II и только программист решает какой протокол канального уровня будет использовать приложение. Остановив свой выбор на 802.3, разработчик должен сформировать заголовок LLC. При этом возможно, что среди доступных кодов SAP не окажется необходимого (для них отведено всего 7 бит и, например, для протокола ARP из стека TCP/IP, значение SAP не определено). В таких условиях, привлекается ещё и SubNetwork Access Protocol (SNAP), лежащий в стеке выше LLC. Он дополняет блок данных протокола сетевого уровня своим заголовком, содержащим двухбайтовое поле «Тип», значения которого совпадают с кодами протоколов, используемыми Ethernet II. Так, для IPX в этом поле должен быть записан код x8138, для IP - x0800, для ARP - x0806. Еще одно трехбайтовое поле этого заголовка «Код организации» (Organizationally Unique Identifier, OUI) используется для указания той организации по стандартизации, которая отвечает за числовые значения поля «Тип» (если OUI = x000000, то это комитет IEEE 802.3, если OUI = x00000С – то Cisco и т.д.). При использовании функции протокола SNAP в поля DSAP и SSAP заголовка LLС помещаются значения 0xAA. На рис. 6.19 приведена информационная схема алгоритма определения типа MAC-кадра. В поле «Длина/Тип» значение больше x05DC ? Кадр Ethernet II Нет За полем «Длина/Тип» есть 0xAA ? Кадр 802.3+SNAP Нет Кадр IEEE 802.3 Рисунок 6.19. Схема алгоритма идентификации типа кадра Ясно, что обеспечение совместимости спецификаций версий Ethernet и расширение типов сервиса канального уровня ЛС было достигнуто за счет 344 уменьшения поля «Данные», т. е. за счет уменьшения производительности протокола. 6.3.3. Коммутация в сетях Ethernet Применение коммутаторов для формирования ЛС принципиально устраняет проблему коллизий в сетях Ethernet и обеспечивает существенный рост их производительности. Для построения таблиц коммутации в сетях Ethernet процедура маршрутизации не используется поскольку древовидная топология сети не оставляет возможностей существования нескольких путей между конечными узлами. В таких условиях, каждый коммутатор формирует свою таблицу передачи кадров между портами (Forwarding Database, FDB) на основании анализа адресов источников поступающих на его порты кадров. Этот процесс называют обучающим исследованием и его результатом является совокупность записей вида «MAC-адрес – порт». Записи, появившиеся в таблице коммутации в результате обучающего исследования имеют определенное «время жизни» и если в течение этого интервала времени кадры с этим адресом источника на данном порте не появляются, то запись уничтожается. Вместе с тем, записи, внесённые в таблицу коммутации вручную, имеют статус статических и удаляются из неё также вручную. Собственно коммутация кадра выполняется очень просто: он копируются в выходную очередь порта, указанного в строке таблицы коммутации, соответствующей MAC-адресу назначения обрабатываемого кадра. Если в FDB такой записи нет, или адрес назначения кадра является широковещательным, то кадр копируется в выходные очереди всех портов коммутатора, кроме порта, через который он поступил. В результате, его получат все станции сети и обработают по принципу «адрес назначения мой - беру, нет – уничтожаю». широковещательной рассылки Поскольку кадров с необходимость подобной индивидуальными адресами назначения возникает только на стадии обучения, т. е., относительно редко, то это не приводит к сколько-нибудь заметному уменьшению эффективной производительности сети. 345 Свойство коммутаторов Ethernet отправлять кадры с неизученными адресами назначения на все порты является критически важным, но это работает только при отсутствии в топологии сети замкнутых контуров. Однако, вследствие непредвиденных обстоятельств или преднамеренным вводом резервных линий связи между коммутаторами, в сети могут образовываться замкнутые цепочки коммутаторов. Сеть отдела К1 1 2 …. 9 …. 10G 22 23 24 1G Лаб-я 1 1G 1 Коммутационный узел 2 …. 9 …. 14 15 16 К2 1G К3 Лаб-я 2 1 2 …. 9 …. 10G 2 …. 9 …. 10 11 12 К5 1G К4 Лаб-я 3 10 11 12 1 1 2 …. 9 …. 10 11 12 10G Рисунок 6.20. Коммутируемая сеть Ethernet с резервными связями На рис. 6.20 представлен пример сети отдела, в составе которого есть 3 лаборатории. Линии между коммутаторами лабораторий (К1, К3, К4) к коммутатору К5 связывают на канальном уровне лабораторные фрагменты в сеть отдела и, одновременно, обеспечивают коммуникацию с сетями других структурных подразделений организации. Линии 1G между коммутаторами лабораторий являются резервными. Поскольку Ethernet – широковещательная технология, то образование контуров (петель) в рассматриваемой сети пагубно сказывается на её работоспособности. Предположим, что какая-либо станция из лаборатории 2 (рис. 6.20) посылает широковещательный кадр. Он будет получен коммутатором К3 и его копии будут отправлены через все порты, в том числе 346 к коммутаторам К2, К4 и К5. Копия кадра, отправленного коммутатору К5, через коммутатор K4 вновь окажется на коммутаторе К3; аналогично, копия кадра, отправленного коммутатору К2, породит 2 кадра на входе коммутатора К3 (один от K1 и один еще от К5. Таким образом, уже 3 кадра с широковещательными адресами получены в ответ на один отправленный. Далее циклы генерации таких кадров повторяются, образуя, так называемый, «широковещательный шторм». Очевидно, что пересылка всё увеличивающегося числа широковещательных кадров очень быстро займет все ресурсы коммутаторов и работа сети окажется парализованной. Алгоритм остовного дерева Для поддержания работоспособности объединенных мостами сетей (а коммутатор – это усовершенствованный мост), комитет IEEE 802 разработал спецификацию IEEE 802.1d, в которой определил в качестве механизма устранения сетевых петель предложенный корпораций DEC алгоритм остовного (покрывающего) дерева (Spanning Tree Algorithm, STA). Если представить сеть в виде графа, то действие алгоритма STA заключается в формировании одного из возможных деревьев графа. Исключение петель реализуется переводом определенных портов коммутаторов в заблокированное состояние. Всего определены 5 состояний портов:  заблокирован (Blocked) – начальное состояние всех портов, обрабатываются только кадры управления (Bridge Protocol Data Unit, BPDU), генерируемые STA–протоколом;  прослушивание (Listening) – переходное состояние, когда все коммутаторы считают себя корневыми; обрабатываются только кадры BPDU;  обучение (Learning) – ретранслируются только кадры BPDU, поступающие кадры данных не коммутируются, но таблица коммутации начинает заполняться;  продвижение (Forwarding) – основной рабочий режим коммутатора;  отключен (Disabled). 347 Алгоритм STA требует, чтобы все коммутаторы и их порты имели уникальные идентификаторы (BrID и PoID). Поскольку, реализация алгоритма предполагает обмен между коммутаторами управляющими сообщениями, то все коммутаторы сети должны иметь уникальные индивидуальные и общий групповой MAC-адреса. В целом, коммутаторы, выполняя этот алгоритм, реализуют следующие процедуры. 1. Выбор корневого коммутатора. Корневым назначается устройство, имеющее наименьший идентификатор BrID. 2. Определение корневого порта для всех коммутаторов кроме корневого. Корневым назначается порт, путь от которого до корневого коммутатора имеет наименьшую «стоимость». «Стоимость» пути определяется суммой «стоимостей» портов (кроме корневого) на пути до корневого моста. Одним из возможных критериев назначения стоимости порта может быть его битовая скорость. В спецификации 802.1d определены следующие значения стоимости портов, принимаемые по умолчанию. Возможно также назначение параметра «стоимости» порта администратором сети. В случае наличия портов, пути от которых до корневого коммутатора имеют одинаковую минимальную «стоимость», в качестве корневого выбирается порт с меньшим значением PoID. Таблица 6.2 Битовая скорость порта 10 Мб/с 100 Мб/с 1 Гб/с 10 Гб/с 40 Гб/с 100 Гб/с Стоимость порта (условных единиц) 100 19 4 2 1 1 3. Выбор назначенного коммутатора для каждого сегмента сети. В сетях с общей средой передачи сегментом является группа станций, образующих общий коллизионный домен. К сегменту могут иметь подключения несколько мостов, соединяющих его с другими сегментами сети. В такой ситуации, выбор (по критерию минимальной стоимости пути до корня) 348 одного из мостов в качестве шлюза сегмента к остальной сети имел своё очевидное содержание. При этом, порт этого моста, принадлежащий рассматриваемому сегменту, становился назначенным портом моста. В коммутируемой сети коллизионный домен (сегмент) сокращен до одной конечной станции и порта коммутатора, к которому она подключена; поэтому всякая множественность коммутаторов в таком сегменте исключается и выбор назначенного коммутатора теряет смысл; точнее, все коммутаторы, кроме корневого, следует считать назначенными, а все порты, к которым подключены конечные станции или линии связи, ведущие к корневым портам других коммутаторов, считать назначенными портами. 4. Перевод всех корневых и назначенных портов в состояние передачи (forwarding state) и блокировка всех остальные портов. Проиллюстрируем работу алгоритма STA на примере сети, топология которой представлена на рис. 6.20. Идентификаторами коммутаторов и портов будем считать их номера. Шаг 1. Выбор корневого коммутатора. K1 становится корневым, поскольку имеет минимальный Id. Шаг 2. Определение корневых портов коммутаторов К2 – К5. Для коммутатора K2 - это порт 14, поскольку его PoId меньше Id порта 15, также связывающего К2 c корнем по пути равной стоимости, а путь через порт 16 к корню более «дорогой». Для коммутатора К3 - это порт 12, поскольку стоимость пути от него до корневого коммутатора через коммутатор К5 составляет 4, а от порта 11 через К2 – 8 условных единиц. Для коммутатора К4 – это порт 12 по тем же соображениям. Для коммутатора К5 корневым является порт 1. Шаг 3. Выбор назначенных портов. Для корневого коммутатора (К1) все порты являются назначенными. Для коммутаторов K2, К3 и К4 – это порты, к которым подключены конечные станции. 349 Для коммутатора К5 – это порты 2, 9 и 12. Шаг 4. Задание состояний портов Корневые и назначенные порты переводятся в состояние передачи (Forwarding); все остальные – в состояние блокировки. В результате получаем топологию сети без петель, которая представлена на рис. 6.21. В таком состоянии отправка широковещательного кадра из сегмента лаборатории 2 уже не приведёт к «шторму», его копии просто будут доставлены всем станциям во всех сегментах сети отдела. Сеть отдела К1 1 2 …. 9 …. 10G 22 23 24 1G Лаб-я 1 1G 1 Коммутационный узел 2 …. 9 …. 14 15 16 К2 1G К3 Лаб-я 2 1 2 …. 9 …. 2 …. 9 …. 10 11 12 К5 10G 1G К4 Лаб-я 3 10 11 12 1 1 2 …. 9 …. 10G 10 11 12 Рисунок 6.21. Коммутируемая сеть Ethernet с избыточными связями после исполнения алгоритма STA Реализация процедуры построения остовного дерева предполагает обмен информацией между коммутаторами. Такой обмен организуется посредством рассылки сообщений протокола Bridge Protocol Data Unit (BPDU), которые инкапсулируются в кадры канального уровня. При этом, наличие у коммутаторов, входящих в объединенную сеть, общего группового MAC-адреса 01-80-C2-00-00-00, назначенного именно для поддержки STP, позволяет делать это достаточно экономично. (Обратите внимание на 350 значение младшего бита старшего байта этого адреса – он равен 1, что говорит о групповом адресе). Формат сообщения BPDU для протокола STP (Spanning Tree Protocol) представлен на рис. 6.22. 2 1 1 ПротоТип Версия кол сообщен. 1 Флаги Размер поля в байтах 4 8 2 8 ID Стоимость корневого пути до BrID моста корня PoID 2 2 Возраст Предельный сообщения возраст 2 2 Интервал рассылки Задержка релаксации Рисунок 6.22. Формат сообщения BPDU Уточним смысл полей этого сообщения:  Протокол: равно 0х00-00.  Версия: равно 0х00-00.  Тип: значение 0х00 соответствует конфигурационному сообщению, 0х01– извещению об изменении топологии (TCN).  Флаги: единичное значение первого бита является сигналом об изменении топологии; установленный в единицу 8-й бит – это подтверждение приёма информации об изменении топологии.  Идентификатор коневого моста, идентификатор порта и стоимость пути до корня: смысл полей соответствует их названию.  Идентификатор моста (BrID): формируется как сочетание задаваемого администратором двухбайтного значения приоритета устройства и 6байтного МАС-адреса модуля управления коммутатора.  Возраст сообщения: начальное значение устанавливается равным 0 и увеличивается на единицу каждым коммутатором при ретрансляции сообщения; сообщение уничтожается при достижении значения этого поля величины, указанной в поле «максимальный возраст».  Максимальный возраст: предельное значение поля «Возраст сообщения»; значение по умолчанию 20.  Интервал рассылки (Hello Time): интервал повторения рассылок сообщений корневым коммутатором; значение по умолчанию – 2 с; все 351 коммутаторы сети устанавливают свои таймеры по значению, указанному в этом поле сообщений от корневого коммутатора.  Задержка релаксации: задержка перехода коммутатора в состояние Forwarding (основное рабочее состояние) после включения или изменения сетевой топологии; значение по умолчанию составляет 15 с; введена для предотвращения возникновения случайных петель при смене состояния мостов. Первым шагом работы протокола STP является выбор корневого коммутатора. При инициализации каждый коммутатор считает себя корневым и все порты получают статус назначенных; в отправляемых сообщениях BPDU в поле «Корневой ID» указывается значения BrID; эти сообщения рассылаются коммутаторами с периодичностью Hello Time (2 секунды) через все порты. При получении сообщения, содержащего в поле «Корневой ID» значение меньшее, чем его собственный BrID, коммутатор записывает ID корневого коммутатора в свою конфигурацию и прекращает генерировать сообщения BPDU; ретрансляция сообщений других коммутаторов им продолжается. Через некоторое время сообщения BPDU будет отправлять только один коммутатор, который и становится корневым. Выбранный корневой коммутатор продолжает рассылку пакетов BPDU каждые 2 с через все свои порты. В этих сообщениях поле «Стоимость пути до корня» устанавливается равной нулю. Каждый коммутатор, ретранслируя эти сообщения, добавляет к значению этого поля стоимость своего порта, через который сообщение отправляется дальше. На этом этапе определяются корневые порты всех коммутаторов. В приведенном выше примере, коммутатор К3 через свой порт 11 получит BPDU со значением поля «Стоимость пути до корня» равным 4 и на порт 12 – со значением равным 1. Соответственно, порт 12 получит статус корневого порта и будет переведен в состояние коммутации (forwarding), а порт 11 будет заблокирован (потеряет статус назначенного и перейдет в состояние 352 Blocked); остальные порты сохраняют статус назначенных и по истечению задержки Forward Delay перейдут в состояние коммутации (Forwarding). После завершения работы алгоритма корневой коммутатор с периодом Hello Time продолжает рассылать пакеты BPDU. Каждый коммутатор будет на единицу увеличивать значение поля «Возраст сообщения» и передавать их дальше. При достижении этим параметром значения «Максимальный возраст» сообщение уничтожается. Протокол STP производит реконфигурирование сетевой топологии в случае выхода из строя корневого моста, обрыва линий связи, отключении назначенных портов и т.п. Так если корневой мост вышел из строя, то остальные мосты перестанут получать от него конфигурационные пакеты. Если этот интервал «молчания» продлиться более времени «Максимальный возраст», то все коммутаторы прекращают передачу кадров данных, очищают свои адресные таблицы, перевыбирают корневой коммутатор и вновь начинают передачу кадров данных. Приостановка передачи кадров данных на время реконфигурации топологии сети (удвоенное значение таймера «Задержка релаксации») производится во избежание образования петель в этот период. В целом алгоритм STP позволяет: 1. обеспечить лишь один путь передачи данных между сетевыми станциями в сложных сегментированных сетях, что необходимо для исключения широковещательных «штормов» и доставки данных в том порядке, в котором они были переданы; 2. строить отказоустойчивые крупномасштабные локальные сети. Заметим, что алгоритм STA строит минимальное дерево и может рассматриваться как алгоритм маршрутизации, определяющий кратчайший и единственный путь в сети. Таким образом, задача маршрутизации в коммутируемой сети Ethernet решается, но в завуалированной форме. Протокол STP имеет слишком большой для современных сетей интервал реконфигурирования топологии (порядка 50 с). В версии 353 спецификации 802.1d 2004 года был определен более совершенный в этом отношении протокол Rapid Spanning Tree Protocol (RSPTP). Существенным его отличием от базовой версии STP является ускоренный перевод портов из состояния Discarding, заменившего состояния Blocked, Listening и Learning, в состояние коммутации (Forwarding); до 3-х интервалов Hello Time сокращено время индикации неработоспособности корневого коммутатора. Также, в перечне статусов портов кроме корневого и назначенного появились статусы альтернативный и резервный. Первый обозначает порт, реализующий резервный путь от конкретного коммутатора к корню. Второй – резервирует соединение от назначенного порта к нижележащему сегменту. Это ускоряет реконфигурирование сети при возникновении нарушений её связности. В целом, RSTP изменил поведение системы управления топологией на проактивное, предусмотрев возможные резервные связи на её критически важных участках. Эти меры позволяют более чем на порядок сократить время изменения топологии. 6.3.4. Эволюция сетей Ethernet 6.3.4.1. Fast Ethernet Спецификация IEEE 802.3u (Fast Ethernet), обеспечивающая битовую скорость передачи 100 Мбит/с, предусматривает полную совместимость с сетями 802.3 (10 Мбит/с) на МАС-уровне стека протоколов, т. е. она сохраняет процедуру МДКН/ОК для доступа к среде передачи и структуру кадра. Напомним, что производительность алгоритма МДКН/ОК определяется величиной отношения времени распространения сигнала между наиболее удаленными сетевыми станциями ( t p ) ко времени передачи кадра. Для корректной работы алгоритма доступа к среде необходимо надежное обнаружение коллизий; последнее возможно, если время передачи кадра минимального размера будет не менее 2t p . Увеличение скорости передачи данных до 100 Мбит/с сократило время передачи кадра в 10 раз и во столько же раз увеличило значение параметра a в выражении (6.1). Следовательно, 354 для сохранения приемлемой производительности протокола доступа к среде при передаче коротких кадров, необходимо либо увеличить в 10 раз (до 640 байт) минимальный размер кадра, либо уменьшить в 10 раз значение 2t p (до 5.1 мкс) и, тем самым, сократить до 250 метров максимально допустимый диаметр сетевого сегмента. Разработчики спецификации 802.3u сохранили минимальный размер кадра (64 байта) и согласились с уменьшением предельного диаметра сети. На рис. 6.23 приведены структуры сетевых стеков 10BaseT и 100BaseTX. Канальные уровни у них одинаковы, однако физический уровень Fast Ethernet имеет более сложную структуру. К А Н А Л Ь Н Ы Й IEEE 802.3u 100BaseTX IEEE 802.3i 10BaseT У Р О В Е Н Ь Подуровень LLC 802.2 Подуровень доступа к среде MAC Подуровень LLC 802.2 Подуровень доступа к среде MAC Интерфейс MII Ф И З И Ч Е С К И Й У Р О В Е Н Ь Подуровень кодирования (Physical Coding) Подуровень кодирования Подуровень физического присоединения (Physical Medium Attachment) Интерфейс AUI Подуровень физической среды (Physical Medium Dependent) Подуровень физического присоединения (Physical Medium Attachment) Подуровень автосогласования (Auto-Negotiation) Разъем (Medium Dependent Interface) Разъем (Medium Dependent Interface) P H Y Рис. 6.23. Уровневая структура сетей 10BaseT и 100BaseTX В качестве среды передачи допустимыми остались только кабель «витая пара» и волоконно-оптические линии. Отличия физических свойств этих сред передачи привели к необходимости применения разных методов 355 физического кодирования и определения трех вариантов Fast Ethernet: 100BaseTX, 100BaseFX и 100BaseТ4 (табл. 6.3). Таблица 6.3 IEEE 802.3u Среда передачи 100BaseТ4 витая пара кат. 3 и 5 4 пары Вариант 100BaseTX витая пара кат. 5 2 пары 100 м 100 м Максимальная длина сегмента Спецификацией IEEE 802.3u определены 100BaseFX многомод. ВОЛС 2 волокна 400 м в полудупл. реж. 2000 м в дупл. реж. различные варианты физического уровня, отличающиеся не только типом кабеля, как в 10мегабитном Ethernet, но и методами сигнального кодирования. Ряд процедур физического уровня спецификации IEEE 802.3u являются общими для всех её вариантов, т. е. не зависят от среды передачи (подуровень согласования и Media Independent Interface, MII), но большая их часть определяется типом применяемого кабеля и реализуются в устройстве PHY. Интерфейс MII поддерживает независимый от используемой физической среды способ обмена данными между MAC-подуровнем и устройством PHY. Этот интерфейс аналогичен по назначению интерфейсу AUI классического Ethernet за исключением того, что AUI располагался между подуровнем физического кодирования сигнала (для любых вариантов кабеля использовался манчестерский код) и подуровнем физического присоединения к среде, а интерфейс MII располагается между MAC-подуровнем и подуровнем кодирования сигнала, которых в стандарте Fast Ethernet три: FX, TX и T4. Устройство физического уровня (PHY) обеспечивает логическое и сигнальное кодирование данных, поступающих от MAC-подуровня для передачи их по кабелю определенного типа, синхронизацию приемника и передатчика, а также прием и декодирование данных в приемнике. Это устройство принимает данные в параллельном формате от MAC-подуровня, транслирует их в один (для TX и FX) или три (для T4) последовательных потока бит, осуществляет их сигнальное кодирование и передает физические 356 сигналы через разъем в кабель. На приемном узле устройство PHY выполняет обратные преобразования. Спецификации PHY-FX и PHY-TX имеют много общих свойств, при рассмотрении которых будет использоваться ссылка PHY FX/TX. Повышение скорости передачи до 100 Мбит/с предъявило более жесткие требования к полосе пропускания используемых кабелей, поэтому актуальными были любые меры, позволяющие уменьшить верхнюю границу требуемой полосы частот. Для этого, в частности, были использованы потенциальные коды, имеющие более узкий, в сравнении с манчестерским кодом, спектр. Однако, использование потенциальных кодов, по причине их плохой самосинхронизации, повлекло применение логического кодирования по схеме 4В/5В. Этот код гарантируют не более трех нулей подряд при любом сочетании бит в исходной информации, что и создает условия для надежной синхронизации приемника. Так как исходные биты MAC подуровня должны передаваться со скоростью 100 Мбит/c, то представление каждых четырёх информационных бит пятибитным символом потребовало увеличить скорость интерфейса до 125 Мбит/c. Наличие 16 дополнительных пятибитных символов позволило использовать в спецификациях 100BaseFX/TX схему непрерывного обмена сигналами между передатчиком и приемником при свободном состоянии среды, что отличает их от спецификации 10Base-T, где незанятое состояние среды обозначается отсутствием сигналов. В устройствах 100Base FX/TX незанятое состояния среды индицируется служебным символом Idle (11111); их передача поддерживает синхронизацию задающих генераторов станций, а также позволяет контролировать физическое состояние линии. Биты потока, прошедшего процедуру логического кодирования, представляются оптическими или электрическими сигналами в кабеле, соединяющем узлы сети. Спецификации PHY-FX и PHY-TX используют для этого различные методы сигнального кодирования: NRZI и MLT-3 соответственно. Напомним, что в методе NRZI (Non Return to Zero Invert to 357 ones, метод без возврата к нулю с инвертированием для единиц) используется два уровня сигнала, но потенциал кодирования текущего бита, зависит от потенциала кодирования предыдущего бита. Если кодируемый бит имеет значение 1, то ему соответствует потенциал, являющийся инверсией потенциала предыдущего бита, независимо от значения последнего. Если же кодируемый бит имеет значение 0, то ему соответствует потенциал предыдущего бита. Частота основной гармоники сигнала NRZI будет максимальной при битовой последовательности, в которой не встречаются подряд нескольких нулей или единиц. В этом случае период основной гармоники равен временному интервалу двух битов, и при скорости передачи 125 Мбит/с частота основной гармоники будет немного выше 62 МГц. Спецификация PHY-ТX предусматривает еще одно дополнительное логическое кодирование битового потока посредством скремблирования, что способствует более равномерному распределению энергии сигнала в его спектре и позволяет уменьшить побочное электромагнитное излучение кабеля. Для сигнального кодирования применяется код MLT-3. Этот код (многоуровневый троичный с чередованием полярности единиц) попеременно использует уровни +V, 0, -V для представления логических 1 и не изменяет полярность сигнала при представлении логических 0 (рис. 6.24). В коде MLT-3 максимальная частота основной гармоники достигается при подаче на вход кодера длинных последовательностей логических единиц. В этом случае период основной гармоники соответствует временному интервалу четырех битов. Следовательно, при скорости передачи 125 Мбит/с максимальная частота первой гармоники будет около 31 МГц, а первые три гармоники укладываются в полосу менее 100 МГц. Передача с такой скоростью оказывается возможной по медному кабелю «витая пара» 5 категории. Обратим внимание на то, что сохранение манчестерского кода, потребовало бы существенно более широкополосной среды, поскольку тактовая частота в этом случае составляла бы 200 МГц. 358 1 1 1 1 1 1 1 Рисунок 6.24. Метод сигнального кодирования MLT-3 Несмотря на то, что спецификации Fast Ethernet разрабатывалась в предположении использования общей среды передачи, концентраторы, в качестве устройств объединения станций, быстро уступили своё место коммутаторам. Спецификации PHY-FX/TX описывают механизм реализации полнодуплексного режима связи. Управление потоком, предупреждающее потерю кадров при кратковременных вспышках интенсивности трафика, обычно, выполняется методом XOFF / XON (раздел 4.4.2). Спецификации PHY-TX и PHY-T4 определяют также функцию автосогласования (Autonegotiation), с помощью которой два взаимодействующих устройства PHY могут автоматически выбрать наиболее эффективный режим обмена данными. Всего определены 10 различных режимов работы, которые могут поддерживать устройства PHY TX или PHY T4, а именно: 100BASE-TX full duplex, 100BASE-T4 half duplex, 100BASE-TX half duplex, 10BASE-T full duplex, 10BASE-T half duplex. Режим 10BaseT half duplex имеет самый низкий приоритет в переговорном процессе, а режим 100BaseTX full duplex самый высокий. Переговорный процесс реализуется при включении питания устройства, но также может быть инициирован в любой момент модулем управления. 6.3.4.2. Gigabit Ethernet Если отличия между Ethernet и Fast Ethernet минимальны и не затрагивают MAC-уровень, то при разработке спецификации сетей Gigabit Ethernet пришлось внести изменения не только в физический, но и в MAC уровень. Повышение скорости передачи данных до 1000 Мбит/с при сохранении минимального размера кадра и достаточно малого значения 359 параметра a, привело бы к необходимости сокращению окна коллизий 2t p до неприемлемо малой величины 0.52 мкс. Значение t p  0.26 мкс при скорости 1000 Мбит/с соответствует, примерно, времени распространения сигнала в 50-метровом отрезке кабеля. Ясно, что уменьшение до 20–25 метров диаметра сети практического смысла не имело. По этой причине минимальный размер кадра был увеличен до 512 байт (в Ethernet и Fast Ethernet – 64 байта). С учетом всех аппаратных задержек было принятого ограничение 2t p  1 мкс, что позволило увеличить максимальный диаметр сети 1GE до 200 метров, т. е. до стандартного для Fast Ethernet значения. Чтобы обеспечить совместимость с MAC-протоколами Ethernet и Fast Ethernet, вынужденное увеличение минимального размера кадра было реализовано посредством включения в его заголовок опционального поля, получившего название "Расширение" (рис. 6.25). Правила формирования остальных полей были сохранены, в том числе, и ограничение 64 байтами минимального размера кадра без поля «Расширение». от 64 до 1518 байт 46 – 1500 байт 6 байт 2 байта 6 байт 4 байта Адрес Адрес ЗаполниПреамбула Старт Размер Данные CRC получателя источника тель 7 байт 1 байт Расширение от 512 до 1518 байт Рисунок 6.25. Структура кадра Gigabit Ethernet Если станция передает короткий (меньше 512 байт) кадр, то в его заголовок включается поле «Расширение», дополняющее кадр до 512 байт. При этом, контрольная сумма вычисляется для кадра без учета поля расширения. При приеме кадра поле «Расширение» отбрасывается еще до передачи его в MAC-модуль, алгоритм работы которого не отличается от алгоритмов обработки кадров Ethernet и FastEthernrt. При трансляции кадра из Ethernet 10/100 в Gigabit Ethernet также производится описанная процедура, что и обеспечивает их совместимость на канальном уровне. Наличие поля расширения приводит к снижению коэффициента полезного использования пропускной способности среды передачи ( max ). 360 Для сокращения накладных расходов протокола, связанных с использованием больших кадров при передаче коротких сообщений, МАСпротокол Gigabit Ethernet допускает возможность передачи нескольких кадров подряд в режиме монопольного владения средой. Такой режим владения каналом называется Burst Mode (режим пакетной передачи). В этом режиме станция может передавать подряд (в пакете) несколько кадров при общем размере «пакета» не более 8192 байт (рис. 6.26). Если у станции имеется несколько небольших кадров для отправки, то первый из них дополняется полем расширения до 512 байт, и отправляется. Остальные кадры передаются вслед без поля расширения и с минимальным межкадровым интервалом длительностью 96 BT (96 нс). 512 < 512 I MAC кадр 1 с полем расширения F G МАС кадр 2 I F G МАС кадр 3 I F G ……….. I F G МАС кадр N 8192 Передача в пакетном режиме Рисунок 6.26. Пакетный режим передачи (Burst Mode) В режиме пакетной передача межкадровый интервал заполняется символами расширения, благодаря чему и между посылками коротких оригинальных кадров остальными станциями сети среда индицируется как занятая, а для физического уровня приемника, вся посылка выглядит как один кадр. Начавшаяся передача последнего в пакете кадра всегда завершается. В режиме пакетной передачи уменьшается и вероятность коллизий, поскольку они могут возникать только на этапе передачи первого кадра пакета, что также увеличивает производительность сети. В 1999 году компанией Alteon Networks, Inc было внесено предложение об увеличении максимального размера кадра Gigabit Ethernet с 1500 до 9000 Байт (Jumbo Frames). Применение «гигантских» кадров ограничивалось только полнодуплексным режимом и сопровождалось введением специальной процедуры согласования возможностей станций обрабатывать такие кадры. Очевидно, что реализация этого предложения 361 привела бы к определенному росту производительности сегментов Gigabit Ethernet, но одновременно породила бы и серьезную проблему совместимости с сегментами Fast Ethernet и внесла бы нарушения в алгоритм определения типа кадра (Ethernet II, 802.3, 802.3+SNAP). Рабочая группа IEEE 802.3z не приняла это предложение, но некоторые из производителей сетевого оборудования его поддержали и выпускают соответствующее оборудование. Все указанные выше модификации МАС-уровня связаны с методом множественного доступа к среде передачи, и они актуальны лишь для сетей, построенных на концентраторах. Практически, сети Gigabit Ethernet строятся на коммутаторах, где проблемы коллизий нет, а ограничение диаметра сети определяется лишь допустимым уровнем затухания сигнала в среде передачи (таблица 6.4). Таблица 6.4 Спецификация PMD Среда передачи Максимальная длина сегмента 1000BaseSX многомодовое волокно IEEE 802.3z 1000BaseLX одномодовое волокно 1000BaseCХ экраниров. медн. кабель IEEE 802.3ab 1000BaseТ витая пара кат. 5е, 6 550 м 5000 – 10 000 м 25 м 100 м Технология Gigabit Ethernet описывается спецификациями IEEE 802.3z (1000BaseSX, 1000BaseLX, 1000BaseСX) и IEEE 802.3ab (1000BaseT), которые были одобрены в 1998-1999 годах. В стандартах IEEE 802.3z предусмотрено логическое кодирование 8В/10В, тактовая частота составляет 1,25 ГГц и сигнальное кодирование производится по схеме NRZ. В сетях IEEE 802.3ab (1000BaseT) логическое кодирование 8В/10В заменяется скремблированием, а сигнальное кодирование выполняется по методу РАМ-5 (Pulse Amplitude Modulation). Это пятиуровневый полярный код, в котором пара информационных бит, в зависимости от предыстории, представляется одним из четырёх возможных уровней потенциала. Пятый уровень сигнала используется для механизма упреждающей коррекции ошибок (Forward Error Correction, FEC). Очевидно, что передача данных дибитами позволяет в два 362 раза уменьшить бодовую скорость. Полоса пропускания кабеля 5-й категории позволяет передавать данные со скоростью до 125 МБод/с, т.е. информационная скорость по одной витой паре может достигать 250 Мбит/с. Параллельная передача данных по четырем парам обеспечивает требуемую скорость передачи 1000 Мбит/с. Механизм FEC реализован алгоритмами кодирования Треллиса и декодирования Витерби. Его применение позволяет увеличить помехоустойчивость приемника на 6 дБ. Дуплексный режим связи, являющийся основным для стандарта 1000BaseT, реализуется передачей сигналов одновременно в двух направлениях по четырем парам кабеля. Техническая реализация дуплексной передачи по витой паре категории 5 оказалась значительно сложней, чем в стандарте 100Base-TX. Влияние помех от трех соседних линий на каждую пару в четырехпарном кабеле потребовало разработки специальной схемы скремблирования и применения сигнальных процессоров для вычитания приёмными модулями сигналов передатчиков. В 2001 году была принят ещё один вариант спецификации IEEE 802.3ab - спецификация 1000Base-TX (ANSI/TIA-854), которая также предполагает использование всех четырех пар витой пары, но передача в каждом направлении производится раздельно по двум парам. Очевидно, что это потребовало увеличения сигнальной скорости по каждой паре кабеля до 250 МБод и применения кабельной системы категории не ниже 6. При этом, сложность технической реализации приёмных устройств и их энергопотребление, в сравнении с 1000BaseT, оказались существенно ниже за счёт отсутствия в них прецизионных схем цифровой компенсации наводок и взаимных помех. 6.3.4.3. 10G Ethernet В 1999 году в комитете IEEE 802.3 была создана отдельная группа Higher Speed Study Group для разработки Спецификации Ethernet производительностью 10 Гбит/с (10GE). Достижение этой цели требовало решения следующих задач: 363  определение физических интерфейсов, обеспечивающих построение сетевых сегментов протяженностью не менее 200 м на многомодовых и не менее 3 км на одномодовых ВОЛС;  создание МАС уровня, сохраняющего формат и предельные значения размеров кадра IEEE 802.3; поддерживающего работу на скорости 10 Гбит/с в локальных и на скорости 9.95328 Гб/с (STM-64) в глобальных сетях SDH;  обеспечение совместимости со всеми предыдущими версиями Ethernet;  разработку технических решений, при которых оборудование сетей 10 Гб/с имело бы приемлемую стоимость (не более, чем в 2-3 раза дороже аналогов 1GE). К концу 2002 года спецификация IEEE 802.3ae, ставшая стандартом де-факто для всех производителей оборудования и компонент сетей 10GE, была принята. Основным её отличием от всех предыдущих спецификаций подкомитета 802.3 является зафиксированный в ней отказ поддержки алгоритма множественного доступа к среде передачи CSMA/CD. В этих условиях, максимальный диаметр сетевого сегмента определяется не особенностями процедуры детектирования коллизий, а исключительно свойствами физической среды передачи, энергетическим бюджетом приемопередатчиков и свойствами применяемых методов сигнального кодирования. Принятие Спецификации 802.3ae знаменовало превращение Ethernet в технологию построения крупных городских и региональных сетей. Её почти бесшовная интеграция с сетями SDH существенно упростила решение задачи доступа к сервисам глобальных сетей. Вместе с тем, в сетях 10GE сохранялся присущий всем вариантам Ethernet недостаток средств поддержки классов качества обслуживания, что должно компенсироваться протоколами вышестоящих уровней. 6.3.4.3.1. Структура сетевого стека 10G Ethernet Уровневая структура сетевого стека 10GE представлена на рис. 6.27. MAC-уровень в новой спецификации претерпел минимальные изменения в 364 сравнении с базовой спецификацией семейства 802.3 – были сохранены формат кадра, его минимальный (64 байта) и максимальный (1518 байт) размеры. Full Duplex MAC Reconciliation Sublayer (RSL) XGMII PCS 4 линии Кодиров. 8B/10B PCS 1 последов. лин. Кодиров. 64B/66B WAN Interface Sublayer (WIS) XSBI XAUI PMA MUX/DEMUX 16x644Mb/s PMD 10GBASE-X PMD 10GBASE-R 4x3,125 Gb/s 10.3125 Gb/s PCS 1 последов. линия Кодирование 64B/66B XSBI PMA MUX/DEMUX 16x622Mb/s PMD 10GBASE-W 9,95 Gb/s WAN PHY LAN PHY Рисунок 6.27. Уровневая архитектура 10G Ethernet Физический уровень в Спецификации 802.3ae представлен в трёх основных вариантах: 10GBase-X, 10GBase-R и 10GBase-W. Первый из них (Х) выполняет разделение бит МАС-кадра на четыре потока, формируемых на побайтной основе и подвергаемых логическому кодированию по схеме 8В/10В. Два других варианта физического уровня (R и W) сохраняют последовательный поток бит МАС-кадра, подвергая его кодированию по схеме 64В/66В. Важной особенностью спецификации 802.3ae является определение в ней двух вариантов физического уровня – LAN PHY и WAN PHY. Для работы в локальных сетях физический уровень сетевых устройств (LAN PHY) может быть реализован в вариантах 10GBASE-X и 10GBASE-R, в то время как для интеграции с сетями SDH WAN PHY должен быть построен в 365 соответствии с вариантом W. В этом случае в составе физического уровня WAN PHY создаётся подуровень адаптации WAN Interface Sublayer (WIS), формирующий кадры STM-64 с их специальными управляющими сигналами, позволяющими SDH-менеджеру воспринимать линию Ethernet как стандартную STS-линию. Наличие порта 10GBASE-W даёт возможность непосредственного подключения коммутаторов 10GE к устройствам доступа сетей SDH. Отличие битовых скоростей LAN канала (10 Гб/с) и WAN SDH канала STM-64 (9.95328 Гб/с) потребовало специальной процедуры регулирования скорости битовых потоков, которую выполняет MAC-уровень. Уменьшение скорости потока, передаваемого на физический уровень, до 9.95328 Гбит/с достигается приостановкой МАС-уровнем на определенный период времени передачи данных. Существуют два алгоритма такого регулирования. В соответствии с первым из них приостановка отправки кадра производится по сигналу от физического уровня. Длительность паузы равна периоду тактовой последовательности, а ее включение в битовый поток возможно в любой момент времени, кратный периоду передачи 32 битного слова (алгоритм Word-by-Word). Достоинством алгоритма является его инвариантность к используемому методу кодирования и возможность тонкой подстройки скорости потока. Вместе с тем, определение необходимого размера буфера и синхронизация «приемник-передатчик» становятся довольно сложными. Второй алгоритм уменьшает скорость битового потока посредством увеличения межкадровых интервалов (IFG), которые варьируется в зависимости от величины последнего переданного кадра. Достоинствами такого варианта являются упрощение схемы взаимодействия МАС-PHY, но он требует достаточно большого буфера, поскольку функционирует на уровне кадров. 366 6.3.4.3.2. Физический уровень 10G Ethernet Обобщенная схема физического уровня представлена на рис. 6.28. Подуровень согласования (RSL) осуществляет преобразование последовательного потока байт кадра MAC-уровня в параллельный 32битный поток интерфейса XGMII (10-Gigabit Media Independent Interface). Этот и ещё два межуровневых интерфейса (XAUI и XSBI) являются нововведениями Спецификации 802.3ae. MAC (Full duplex) RSL Reconciliation Sublayer Подуровень согласования XGMII - 10Gigabit Media Independent Interface Независящий от сред передачи MAC-PHYинтерфейс XGXS XAUI - 10Gigabit Attachment Unite Interface XGXS PCS PMA PMD Medium XGXS - 10Gigabit Extender Sublayer Опциональный подуровень преобразования XGMII XGMII XAUI Physical Coding Sublayer (Encoder/Decoder) Подуровень физического кодирования XSBI - 10Gigabit Sixteen-Bit Interface Зависящий от сред передачи MAC-PHYинтерфейс Physical Medium Attachment Sublayer (SER/DESER) Подуровень подсоединения к физической среде Physical Medium Dependent Sublayer Процедуры, зависящие от среды передачи MDI - Medium Dependent Interface Зависящий от среды предачи интерфейс (XFI, SFI...) Рисунок 6.28. Детализированная структура физического уровня 10GE Интерфейс XGMII построен на базе интерфейса GMII (1GE) Рисунок 6.27. Детализированная структура физического уровня 10G Ethernet посредством наращивания числа линий для увеличения битовой скорости в 10 раз; он используется на микросхемном уровне и не требует физического разъема. XGMII содержит 74 линий (рис. 6.29). Передача-прием данных по 32-битным линиям интерфейса XGMII поддерживается 4-битными линиями управления (по 1 биту на каждый байт). Управляющий бит устанавливается в 1 для байта разделителей и специальных символов (Hold, StartOfPacket, EndOfPacket, Error); нулевое его значение соответствует байту данных. 367 MAC + RSL PCS Tx_W_Hold Rx_Clock 4 b_Contr 32b_Data Tx_Clock 4 b_Contr 32b_Data XGMII PCS Receiver PCS Transmitter Tx_Data [15…0] Rx_Data [15…0] XSBI PMA Рисунок 6.29. Схема интерфейса XGMII Перечисленные синхронизации специальные операций символы необходимы для мультиплексирования/демультиплексирования, реализуемых подуровнем PMA. Шины данных и управляющих сигналов анализируются в моменты каждого фронта синхросигнала. Тактовая частота шины данных составляет 156.25 МГц (156.25·32·106·2=1010). Линия Tx_Word_Hold собственно в интерфейс не входит; она включена для поддержки портами WAN PHY стандартной битовой скорости потока STM-64 (алгоритм Word-by-Word). Отметим, что интерфейс XGMII масштабируется как по ширине шины данных, так и по скорости. Например, при 8-битной шине данных с одним управляющим битом, он обеспечивает передачу 4-х параллельных потоков. Благодаря этому XGMII поддерживает как последовательную (10GBASE-R, 10GBASE-W), так и параллельную (10GBASE-X) архитектуры физического уровня. Однако, протяженность линий интерфейса XGMII не превосходит несколько десятков сантиметров. Поэтому для связи компонентов физического уровня, находящихся на больших расстояниях, предусмотрена возможность преобразования XGMII в интерфейс XAUI. Соответствующее преобразование выполняется процедурами подуровня XGXS (10Gigabit Extender Sublayer). Этот подуровень распределяет получаемые данные на побайтной основе в 4 последовательных потока, которые кодируются по 368 схеме 8В/10B и передаются далее по отдельным линиям с битовой скоростью 3,125 Гбит/с. Благодаря избыточному кодированию, битовые последовательности становятся самосинхронизируемыми, что исключает надобность в отдельных линиях синхросигналов. Уменьшенная в 4 раза скорость парциальных потоков позволяет сохранить целостность сигналов при передаче их по достаточно длинным медным печатным проводникам интерфейсной платы сетевого устройства, снизить уровень побочных электромагнитных излучений и потребляемую мощность. Отметим, что интерфейс XAUI эквивалентен интерфейсам, применяемым в других высокоскоростных сетях (Infiniband, 10G Fibre Chanel) и в объединительных платах сетевых коммутаторов. Это позволяет использовать для его аппаратной реализации серийные микросхемы. Тем не менее, многие производители приемопередатчиков 10GE первоначально (в середине 2000 годов) поддерживали только интерфейс XGMII, в силу его близости к хорошо знакомому интерфейсу GMII. Создатели Спецификации 802.3ae для большей гибкости в реализации способа передачи данных между подуровнями PCS и PMA (или дабы совсем уж запутать разработчиков) определили возможность применять в качестве сервисного интерфейса подуровня PMA 16-разрядный интерфейс XSBI (10Gigabit Sixteen-Bit Interface), который ведёт своё происхождение от интерфейса SPI-4, используемого в сетях SDH. Такое решение достаточно логично, поскольку процедуры подуровня PCS устройств PHY 10GBASE-W/R очень близки процедурам аналогичного подуровня сетей SDH. В целом, можно рассматривать XSBI как компромисс между интерфейсами XGMII и XAUI (таблица 6.5). Таблица 6.5 XGMII Разрядность (число линий) 32 Тактовая частота (MГц) 156.25 Битовая скорость на линию (Мбит/с) 312.5 Способ синхронизации Отдельная линия XSBI 16 644.53 или 622.08 644.53 или 622.08 Отдельная линия XAUI 4 3125.0 3125.0 Самосинхронизац. Интерфейс 369 Интерфейс подключения передающей физические сигналы среды (MDI) спецификацией 802.3ae не определён. В этом качестве для подключения оптических модулей наиболее широко используются интерфейсы XFI, SFI. Представленная на рисунках 6.27 и 6.28 уровневая структура сетевого стека 802.3ae отражает группировку основных операций, необходимых для превращения битовых конструкций MAC-кадров в физические сигналы различных линий и их обратного преобразования в МАС-кадры. Кратко перечислим эти операции. Подуровень логического кодирования (PCS) 10GBASE-X PCS  Перекодирование потока 32-битных слов данных и 4-битных символов управления интерфейса XGMII в четыре потока 10-битных кодовых групп (8B/10B) для передачи их подуровню PMA;  Синхронизация, устранение временного сдвига парциальных потоков и определение границ кодовых групп;  Управление и получение информации о статусе линий. 10GBASE-R/W PCS  Перекодирование потока 32-битных слов данных и 4-битных символов управления интерфейса XGMII в поток 64-битных кодовых групп и скремблирование их;  Кодирование по схеме 64B/66B;  Передача 66-битных кодовых слов по 16 битному XSBI интерфейсу. Подуровень адаптации WAN (10GBASE-W WIS) При передаче:  Получение блоков данных от подуровня PCS  Размещение данных в поле полезной нагрузки (Synchronous Payload Envelope, SPE) кадра STM-64 370  Формирование путевого заголовка (POH) и вставка фиксированного числа пустых байт для компенсации разницы скоростей поступления данных и стандартной скорости кадров STM;  Формирование заголовков линии (LOH) и секции (SOH)  Скремблирование  Передача кадра STM подуровню PMA Перечисленные операции выполняются каждые 125 мкс, т. е. формируются 8000 кадров в секунду без всяких интервалов между ними. При приёме потока от подуровня PMA:  Выполнение кадровой и байтовой синхронизации;  Дескремблирование кадра;  Удаление заголовков SOH и LOH;  Чтение значения указателя начала поля данных PTR;  Нахождение начала поля данных и удаление заголовка POH;  Исключение балластного заполнения и передача оставшихся байт PCS. Подуровень присоединения к среде передачи (PMA)  Преобразование потоков данных от PCS (WIS) в последовательный поток и обратное преобразование от PMD в 16-битный код интерфейса XSBI;  Выполнение функции закольцовывающего интерфейса. Подуровень процедур, зависящих от типа среды передачи (PMD)  Битовая синхронизация, сигнальное кодирование;  Учёт характеристик кабеля, оптического волокна и т.п.;  Взаимодействие с физической средой, детектирование сигналов и фиксация нарушений подключения к среде. Особенности сред передачи учитываются отдельными спецификациями подуровня PMD (символ Y в названии спецификации обобщает варианты X, R, W физического уровня):  10GBASE-EY - одномодовый ВОК, передача сигнала в окне 1550 нм;  10GBASE-LY - одномодовый ВОК, передача сигнала в окне 1330 нм; 371  10GBASE-SY - многомодовый ВОК, передача сигнала в окне 850 нм;  10GBASE-LX4 – 4 лазера, WDM, многомодовый и одномодовый ВОК;  10GBASE-СX4 – 4 медных твинаксиальных кабеля. Как отмечено выше (рис. 6.27), физический тракт может быть организован по однопоточной последовательной (10BASE-R/W) и четырёхпоточной параллельной (10BASE-X) архитектурам. Физический уровень с последовательной архитектурой для логического кодирования использует процедуру скремблирования и к каждому 64-битному блоку добавляет лишь два контрольных бита: 01 – если передаваемый блок состоит только из битов данных, 10 – если в блоке есть контрольные биты и биты данных. Дибиты 11 и 00 не используются, и их появление интерпретируется как ошибка. Кодовые 66-битные блоки от подуровня PCS по 16-битному интерфейсу XSBI передаются уровню PMA, который преобразует их в последовательный поток битов для подуровня PMD. Таким образом, вносимая кодером избыточность оказывается лишь немногим больше 3% и скорость работы последовательной линии после сериализации потока составляет 10.3125 Гбит/с. Реализация последовательной архитектуры (рис. 6.30) требует высокочастотных электронных компонент, но предъявляет менее строгие требования к синхронизации частот тактовых генераторов и использует один комплект лазерного оборудования. 66b 100101 Scrambler Encoder 64b Laser Driver SER Laser Optical Signals 64b 66b Decoder Descrambler PCS DESER 100101 Resynchronization, Signal restoration PMA PMD Photo diode MDI Рисунок 6.30. Распределение уровневых функций 10GE-R/W 372 Параллельная архитектура (10BASE-X) предполагает разделение битового потока MAC-уровня на 4 парциальных потока интенсивностью 2.5 Гбит/с и реализацию всех компонент PMD подуровня для каждого из них (рис. 6.31). Encoder 8B/10B Opt. Transmit. MUX WDM Opt. Transmit. Optical Signals 4x10b RETAIMING Opt. Transmit. 64b Opt. Transmit. 4x10b Opt. Receiver 4x10b Decoder 8B/10B RETAIMING 64b Opt. Receiver Opt. Receiver DEMUX WDM Opt. Receiver PCS MDI PMD Рисунок 6.31. Распределение уровневых функций 10GE-X Логическое кодирование парциальных потоков выполняется по схеме 8B/10B, а сигнальное – по схеме NRZ. Передача физических сигналов парциальных потоков осуществляется либо по четырём оптическим волокнам в каждую сторону (8 волокон), либо по одному волокну с использованием техники волнового мультиплексирования (WDM). Оптические несущие располагаются в четырёх поддиапазонах шириной 13.4 нм каждый: (1269.0 – 1282.4) нм, (1293.5 – 1306.9) нм, (1318.0 – 1331.4) нм, (1342.5 –1355.9) нм; защитный интервал между поддиапазонами составляет 11.1 нм. Модулированные оптические несущие мультиплексором WDM (4:1) объединяются в агрегированный транспортный сигнал, который по интерфейсу MDI вводится в волоконно-оптический кабель. Основным преимуществом параллельной архитектуры является возможность использования менее высокочастотных электронных компонент и более простых лазеров. Однако, процедуры формирования парциальных потоков и 373 их объединения на приемной стороне предъявляют очень высокие требования к стабильности частоты генераторов синхронизации и к точности выравнивания задержек транспортировки парциальных потоков. Аппаратная реализация устройств PHY обычно разделяется на 2 части. Одна из них выполняет операции, независящие от среды передачи, и размещается на плате сетевого интерфейса. Вторая часть содержит компоненты, реализация которых определяется видом среды передачи; она представляет собой отдельный сменный модуль разных форм-факторов (XENPACK, FXP, SXP+). Модули XENPACK имеют весьма большие размеры, высокое энергопотребление и в настоящее время практически не используются. XFI XFP Module Host Ethernet Card 10GE MAC XGMII PCS 64B/66B PCS XSBI Hard PMA SERDES RETIMER Optical Transmitter RETIMER Optical Receiver PMD PMA SFI SFP Module Host Ethernet Card PCS PCS 64B/66B XSBI Hard PMA SERDES PMA RETIMER 10GE MAC XGMII Optical Transmitter Optical Receiver PMD Рисунок 6.32. Блок-схемы аппаратной реализации устройств PHY 10GBASE-R/W Структурные отличия модулей малых форм-факторов (XFP и SFP) представлены на рисунке 6.32. Эволюция сменных модулей идёт в направлении минимизации обработки в них электрических сигналов. Это 374 способствует уменьшению их энергопотребения и, как следствие, габаритов, что позволяет создавать сетевые устройства (коммутаторы, прежде всего) с большим числом портов. Интерфейсы XFI и SFI являются одними из простейших последовательных 10-гигабитных электрических интерфейсов между микросхемой сетевой платы и сменными оптическими модулями. Оба используют две дифференциальные пары (одна пара для передачи, другая – для приёма). Эти интерфейсы очень близки по своим электрическим характеристикам и обеспечивают передачу сигналов на скоростях от 9.95 ГБод до 11.10 ГБод. (XFI) и от 8.5 ГБод до 11.10 ГБод (SFI). В заключение отметим, что предусмотренный Спецификацией 802.3ae «медный» вариант физического уровня 10GBASE-CX4, как экономичная альтернатива его оптическому аналогу, не нашёл сколько-нибудь широкой поддержки у производителей и потребителей. Он оказался не столь экономичным, как ожидалось, и обеспечивая протяженность соединений не более 20 м, мог быть полезен при объединении коммутаторов в пределах одной-двух стоек, что не представляло серьёзной альтернативы всем прочим «оптическим» вариантам этой технологии. В 2006 году была завершена разработка Спецификации IEEE 802.3at «Physical Layer and Management Parameters for 10 Gb/s Operation, Type 10GBASE­T», определившая технологические основы создания 10-гигабитных сетей с привычной медной витой парой в качестве среды передачи сигналов. Следует отметить, что эта технология воплощала практически предельные возможности электронных и коммуникационных компонентов соответствующего периода. Использование сигнального кодирования по схеме PAM16, достаточно сложных методов логического кодирования и кодов с упреждающей коррекцией ошибок (FEC), тщательная компенсация взаимных наводок в парах кабеля и динамическая оптимизация канала связи позволили каждым состоянием сигнала передавать 3.125 информационных бита. Требуемая битовая скорость достигалась при сигнальной скорости передачи по каждой из четырёх пар кабеля 800 МБод, 375 (800∙106∙4∙3.125=1010 бит/с). Такая скорость может быть достигнута в кабельной системе категории 6А и выше. Функция автосогласования скоростей взаимодействующих портов позволяет использовать коммутаторы 10GE-T совместно с устройствами 1GE и проводить модернизацию сети поэтапно, не требуя одновременной замены всего оборудования и сетевых карт серверов. В целом, совокупная стоимость порта 10GBASE-T (вместе с кабельной системой и эксплуатационными расходами) составляет (20-25) % стоимости порта 10GBASE-R на многомодовом волокне. Эти экономические и технологические достоинства технологии объясняют существующую тенденцию расширения применения оборудования 10GBASE-T. Таким образом, технология 10G Ethernet имеет сегодня хорошо апробированные реализации для всех секторов сетевой индустрии - от системных сетей ЦОД и локальных сетей зданий до сетей масштаба города и региона (табл. 6.6). Таблица 6.6 Спецификац. IEEE 802.3ae Вариант PMD 10GBase-SY 10GBase-LY Среда передачи Многомод. волокно Макс. длина сегмента (м) 100 - 300 IEEE 802.3at 10GBase-ЕY 10GBase-CX4 Одномод. Одномод. волокно, волокно, окно 1300 нм окно 1500 нм 15 000 40 000 10GBase-T 4 медных твинакс. кабеля 4 пары, UTP и STP, кат. 6A, 7 15-20 100 Заключение к разделу 6.3 За время существования и активного использования сетей Ethernet их технология очень сильно изменилась. Благодаря развитию архитектур и совершенствованию аппаратных средств коммутаторов, принцип множественного доступа к среде передачи физических сигналов и соответствующий ему протокол (CSMA/CD) потеряли свою актуальность, а задачи MAC-протокола существенно упростились. Благодаря успехам микрои оптоэлектроники, развитию методов цифровой обработки сигналов, скорость передачи битовых потоков возросла более, чем в 10000 раз. Но 376 формат кадра, его предельные размеры и семантика полей заголовка остались неизменными, что и позволяет сохранять совместимость сетей Ethernet разных поколений. Важнейшим результатом эволюции технологии Ethernet является превращение её в технологию построения не только локальных сетей, но и крупных сетей центров обработки данных, интеграции их с территориальными сетями. Контрольные вопросы к разделу 6 1. Как приемная станция различает P- и F-кадры при установленном в 1 бите P/F в заголовке кадра HDLC? 2. Какие из утверждений ошибочны в отношении HDLC: a. передающая станция включает свой адрес в командный кадр; b. принимающая станция ищет свой собственный адрес в кадре ответе; c. кадр-ответ содержит адрес отправившей его станции. 3. Приведенная ниже диаграмма соответствует обмену кадров под управлением протокола HDLC в режиме AMB. Замените символ «x» в идентификаторах кадров. А t 1 2 4 5 6 7 8 3 B 1: BI00; 2: AI00; t 3: xIxx; 4: xIxx; 5: xхx; 6: xIxx; 7: xxxx; 8: xxxx; 4. Можно ли рассматривать HDLC, работающий на многоточечной линии в режиме NRM, в качестве канального протокола ЛВС? Если да, то к какому типу по признаку управления доступом к среде, его можно отнести? 5. Укажите общие и отличительные свойства протоколов PPP и Ethernet. 6. Какие виды коммуникационного сервиса обеспечивает Ethernet II? 7. Зачем в спецификации IEEE 802.3 введён подуровень LLC? 8. Чем определяются нижняя и верхняя границы размера кадра во всех вариантах Ethernet (от Ethernet II до 100GE)? 377 9. В каких версиях Ethernet (от Ethernet II до 100G Ethernet) сохраняется возможность доступа к среде на основе алгоритма CSMA/CD? 10. Требования к характеристикам среды передачи («витая пара», волоконно-оптический кабель) в спецификации Fast Ethernet не изменились относительно требований спецификации Ethernet II. Какие меры позволили при этом в 10 раз увеличить скорость передачи битового потока? 11. Какой параметр канального протокола должны учитывать протоколы вышестоящего уровня при формировании своих протокольных блоков? Какое значение этого параметра для протоколов семейства Ethernet? 12. Что изменилось бы в формате кадра 1G Ethernet, если бы его разработчики отказались от поддержки алгоритма CSMA/CD? 13. Какое топологическое условие обязательно для коммутируемой сети Ethernet? Какова его природа и как обеспечивается его выполнение? 14. Требуется ли решение задачи маршрутизации для построения таблиц коммутации коммутаторов сети Ethernet? Почему да/нет? 15. Какие механизмы спецификации интеграцию сетей 10GE и сетями SDH? 378 IEEE 802.3ae обеспечивают 7. СЕТЕВЫЕ СЛУЖБЫ И МЕЖСЕТЕВОЕ ВЗАИМОДЕЙСТВИЕ 7.1. Задачи сетевого протокола В этом разделе термин «локальная сеть» будет использоваться для обозначения совокупности узлов, обмен данными между которыми может быть обеспечен протоколами и устройствами физического и канального уровней. Для сетей Ethernet – это совокупность узлов, для которых широковещательный трафик канального уровня является общим. Локальные сети, даже коммутируемые, плохо масштабируются, поскольку при увеличении числа станций растёт уровень широковещательного трафика, MAC-таблицы коммутаторов становятся настолько большими, что их хранение занимает слишком много места в памяти коммутатора, а время поиска требуемой записи становится существенной компонентой общего времени сетевой задержки. Кроме этого, масштаб ЛС ограничивается и организационно-административными факторами. Вместе с тем, взаимодействие станций, принадлежащих разным локальным сетям, является совершенно обязательной предпосылкой формирования информационной среды предприятий, регионов, стран и т.д. Для решения этой интеграционной задачи необходимы достаточно гибкие механизмы межсетевой связи, способные:  адресовать не физические узлы, а логические сущности, представляющие разномасштабные совокупности физических сетевых узлов (сети); при этом, и отдельное физическое устройство должно быть логически представимо в этой адресной иерархии;  ограничить широковещательный трафик пределами локальных сетей. Механизмы взаимосвязи (адресация и правила обмена трафиком) между сетями реализуются процедурами сетевых уровней стека и одноимёнными протоколами (рис. 7.1). Эти процедуры объединяются в специальные модули операционных систем конечных маршрутизаторов (устройств коммутации межсетевого трафика). 390 станций и Локальная сеть D, Станция 1 Станция 1, Локальная сеть А Сегменты данных Транспортный уровень Транспортный уровень Точки доступа к сетевому сервису Сетевой уровень межсетевые протоколы Сетевой уровень пакеты Сетевой уровень Канальный уровень Канальный уровень Канальный уровень Канальный уровень Канальный уровень Физический уровень Физический уровень Физический уровень Физический уровень Физический уровень Коммутатор Маршрутизатор Рисунок 7.1. Схема межсетевой взаимосвязи конечных станций В соответствии с моделью взаимодействия открытых систем сетевой уровень обеспечивает сервис передачи данных приложений в среде, являющейся совокупностью физически связанных локальных сетей. Механизмы реализации этого сервиса должны быть прозрачными для транспортных протоколов и не должны зависеть от технологий канального уровня, которые могут быть разными в разных локальных сетях. Разнообразие приложений обусловливает разные требования к сервису межсетевого взаимодействия. Нетрудно привести примеры сетевых приложений, которые могут требовать:  передачу блоков данных с качеством «по возможности наилучшим», т.е. с ненормированной задержкой и без гарантий упорядоченности отдельных его частей приложениях, (например, когда короткие каждое транзакции сообщение в клиент-серверных "упаковывается" в один протокольный блок);  доставку данных с ограниченной и постоянной задержкой (приложения передачи аудио- и видеоинформации в реальном времени); 391  доставку данных с высокой надежностью (передача файлов, транзакции в банковских системах) и с ограниченной задержкой передачи. Конечно, перечисленные требования приложений удовлетворяются протоколами не только уровня межсетевой связи. Но есть совокупность задач, которые они должны обязательно решать. В их числе:  логическая адресация сетевых узлов и, главное, их совокупностей,  определение маршрута передачи пакета в объединенной сети произвольной топологии,  продвижение пакета по выбранному маршруту,  управление интенсивностью межсетевых потоков с целью предотвращения перегрузок. Решение большей части этих задач имеет определенную специфику, связанную с наличием или отсутствием постоянного логического канала между конечными узлами в распределенной сети. В сети, не располагающей механизмами установления соединений, задача продвижения решается индивидуально в отношении каждого пакета на каждом узле маршрутизации. Сеть, в которой предусмотрена возможность предварительного установления соединения взаимодействующих узлов, этой процедурой решает задачу определения и фиксации полного маршрута между ними, что упрощает механизм продвижения по нему пакетов соответствующего потока. Наличие или отсутствие постоянного логического канала между конечными узлами и уровень надежности передачи (гарантированная или "как получится"), в общем случае, позволяют определить четыре варианта сетевого сервиса, из которых, в большинстве случаев, реализуются два: 1. передача пакетов без предварительного установления соединения и с надежностью «как получится» (дейтаграммный сервис); 2. передача пакетов с предварительным установлением соединения и с гарантированной надежностью их доставки (сервис виртуального канала). Дейтаграммный сервис (рис. 7.2.б) проще в реализации и более устойчив к изменениям топологии сети. В силу простоты, он может быть 392 использован приложением в любой момент, поскольку не требует предварительного информирования сетевого уровня о намерении передавать данные. Дейтаграммный сервис предъявляет минимальные требования и к сервису канального уровня; задержка передачи пакетов одного потока является случайной величиной и может существенно изменяться в зависимости от интенсивности других потоков, обрабатываемых каждым из маршрутизаторов пути; надежность передачи данных между конечными системами в такой сети обеспечивают процедуры транспортного или прикладного уровней. S S D R2 R1 Tcon ~ RTT а) D R2 R1 1 TS 1 1 2 2-1 3 2 k 1 3 1 2 2 3 k+1 2-1 2-2 3 1 3 T D > TS Запрос 2-2 соединения Подтверждение приемлемости Установление соединения Подтверждение соединения 2-2 3 б) в) Рисунок 7.2. Схема дейтаграмного сервиса (б) и сервиса виртуального канала (в) на уровне межсетевого соединения Сервис виртуального канала (рис. 7.2.в) предполагает получение сетевым протоколом конечного узла предварительного запроса на передачу данных и, возможно, требований к качеству их доставки. Вычислив маршрут доставки, сетевой протокол передаёт этот запрос последовательно всем 393 маршрутизаторам пути, которые, подтверждают (или не подтверждают) наличие у них ресурсов для такого соединения. Конечный узел, получив такой «подтверждённый» запрос, выполняет отправку сообщения установления соединения по тому же маршруту, закрепляет это соединение на всех промежуточных узлах пути за определенным потоком (устанавливает сквозное логическое соединение). Такая процедура гарантирует в дальнейшем упорядоченную доставку пакетов приёмному приложению и способствует стабилизации их задержки. На этапе установления соединения сетевой протокол производит согласование параметров источника данных и требуемых параметров качества доставки его пакетов с возможностями сети. Между парой конечных узлов могут быть созданы несколько виртуальных каналов для обслуживания потоков пакетов разных приложений или их групп. На этапе установления соединения все коммутационные устройства, принимающие участие в формировании маршрута между конечными станциями, производят резервирование своих ресурсов (буферная память, процессорное время и т. д.), необходимых соединению. Для учета задействованных ресурсов и контроля открытых соединений сетевой протокол на каждом узле ведет специальную таблицу соединений. Очевидно, что протокол также должен выполнять ликвидацию соединения при завершении работы обслуживаемой им пары приложений и освобождать зарезервированные ресурсы. Даже из этого краткого перечня хорошо видно, что сервис виртуального канала, придавая сети большую адаптивность к запросам приложений, требует от сетевых узлов заметно большего, в сравнении с дейтаграммным сервисом, интеллекта. Сетевой уровень должен также выполнять свою часть работы по предупреждению перегрузок сети. Для этого создаются протоколы мониторинга и управления интенсивностью потоков. Их механизмы будут более сложными в сети, которая должна не только доставлять пакеты, но и гарантировать определенный уровень (надежность, задержку). 394 качества их транспортировки 7.2. Межсетевая маршрутизация Обычно, в объединенной сети существуют множество путей между любой парой её парциальных сетей. Так, в примере, приведенном на рис. 7.3, между сетями 1 и 4 можно указать маршруты: М1 ̶ М3 ̶ М6, М1 ̶ М4 ̶ М5 ̶ М6, М1 - М2 - М5 - М6 и т. д. Множественность путей между сетями, обеспечивая отказоустойчивость телекоммуникационной среды, ставит вопрос о выборе «наилучшего» из них. Этот вопрос может решаться либо на основе «правил» (политик), учитывающих административные и организационные ограничения, либо на основе принципа «кратчайшего» пути. F А М1 М3 Базовая сеть Сеть 1 Сеть 3 М6 М4 С B Сеть 4 М2 D М5 Сеть 6 Сеть 2 Рисунок 7.3. Пример многосвязной объединенной сети Маршрутизация «по правилам» трудно алгоритмизируема и применяется в условиях ограниченного числа возможных вариантов пути. Её применение становится неизбежным при организации передачи трафика с использованием юридическими инфраструктуры лицам, сетей, взаимоотношения управляемых которых в этой разными области регулируются специальными соглашениями. Более подробно особенности маршрутизации «по правилам» будут рассмотрены далее на примере протокола BGP (Border Gateway Protocol). Критерий минимума протяжённости (длины) маршрута выдвигает на первый план выбор метрики, используемой для вычисления расстояний между сетевыми узлами. Если их измерять количеством переходов (числом промежуточных узлов межсетевой 395 коммутации), необходимых для прохождения пути от узла А к узлу B, то оптимальным в сети рис. 7.3 будет маршрут М1– М3– М6. В условиях же когда необходимо обеспечить минимальное время передачи пакета (для этого потребуется информация о возможной задержке передачи пакета каждым из маршрутизаторов), наилучшим может оказаться другой путь, например, М1 – М2 – М5 – М6. Возможна постановка задачи выбора маршрута и по критерию максимизации доступной пропускной способности соединения в условиях различной загрузки сетевых каналов в базовой сети. Таким образом, алгоритмы маршрутизации образовывают некоторое множество, в котором возможна определённая классификация. Классификация методов маршрутизации Для классификации методов маршрутизации можно использовать несколько критериев. Пожалуй, главными классификационными признаками можно считать свойство реактивности процедуры маршрутизации, т.е. способности учета состояния сети при определении маршрута передачи пакетов, и её локализацию в сети (рис. 7.4). Маршрутизация Реактивность Распределенная Централизованная Локализация Динамическа я Статическая Кратчайшего пути По правилам Алгоритм «Длины» вектора расстояния» Алгоритм «Состояния канала» Рисунок 7.4. Классификация методов маршрутизации 396 По этому критерию выделяют статическую и динамическую (адаптивную) маршрутизацию. При статической маршрутизации пути ко всем парциальным сетям определяются на этапе конфигурирования объединённой сети. Они фиксируются в маршрутных таблицах всех узлов и не изменяются относительно длительное время. Ясно, что статическая маршрутизация может быть удовлетворительной лишь в сетях с достаточно стабильной топологией и мало изменяющейся статистикой трафика. Главным её достоинством является отсутствие затрат вычислительных ресурсов, необходимых сетевым узлам для поддержания актуальности маршрутных таблиц. Такой способ маршрутизации также сохраняет исходную последовательность в потоке пакетов, прибывающих в конечную точку маршрута. Очевидным же недостатком статической маршрутизации является невозможность оперативного изменения путей пакетов в ответ на изменения состояния сети, вызванных вариациями загруженности маршрутизаторов и или нарушениями работоспособности линий. При динамической (адаптивной) маршрутизации каждый коммутирующий узел объединенной сети на основании имеющейся у него информации о текущем рассчитывает пути парциальным сетям её состоянии продвижения и пакетов фиксирует (топология ко результаты всем и/или загрузка) известным расчёта в ему таблице маршрутизации. Благодаря периодическому обновлению информации о сети и повторению расчёта, обеспечиваются наилучшие в определённом временном интервале пути продвижения пакетов. Очевидно, что «изучение» состояния сети вызывает обмен служебной информацией между её узлами (дополнительный служебный трафик), а вычисление путей требует определённых вычислительных ресурсов. Еще одним классификационным критерием является локализация процедуры вычисления маршрутов в объединенной сети. При централизованной маршрутизации пути между сетями вычисляются в едином «центре управления» на основании получаемой им информации о 397 топологии и состоянии коммутационных узлов объединенной сети. Рассчитанные таблицы маршрутизации периодически рассылаются всем маршрутизаторам. Такой подход способствует упрощению программного обеспечения узлов маршрутизации, но масштабируемость сети ограничивается достаточно высокими требованиями к вычислительной мощности узла управления и скорости получения им информации о её состоянии. Распределённая маршрутизация, когда соответствующий алгоритм выполняется на каждом узле сети, менее требовательна к вычислительным ресурсам, но предполагает интенсивный межузловой обмен информацией, необходимой для выполнения алгоритма. Такая схема лучше масштабируема, чем централизованная, но порождает значительный служебный трафик, а время расчёта новых маршрутов при изменении состояния сети может оказаться значительным. В такие переходные периоды возрастает вероятность возникновения петель маршрутизации (рис. 7.5) или попыток продвижения пакетов по уже несуществующим путям. А С В Рисунок 7.5. Возникновение маршрутной петли Так, например, пусть в сети на рис. 7.5 маршрутизатор А определил, что лучший путь к сети, присоединённой к узлу С, проходит через узел В; спустя некоторое время линия BC вышла из стоя; маршрутизатор B первым узнаёт об этом и вычисляет маршрут к С через А. Очевидно, что пока узел А не получит информацию о неработоспособности линии BC, все пакеты к узлу C он будет продолжать отправлять к B, создавая маршрутную петлю. Рассмотренная ситуация отражает переходное состояние сети, но если его длительность будет велика, то возникновения заторов избежать не удастся. 398 7.2.1. Таблицы маршрутизации Задача маршрутизации в объединённой сети имеет две составляющие:  вычисление кратчайших путей от каждого узла ко всем известным парциальным сетям и фиксация их в таблице маршрутизации;  определение для каждого поступающего пакета адреса сети, в которой находится получатель, поиск в таблице маршрутизации адреса следующего узла маршрута и передача пакета на соответствующий выходной порт. Информация, включаемая в таблицу маршрутизации, определяется типом сетевого сервиса. При реализации сервиса виртуального канала наилучший путь между конечными системами находится на этапе установления соединения. При этом, каждый узел пути назначает создаваемому виртуальному каналу свой идентификатор (Virtual Channel Identifier, VCI) и выделяет необходимые ресурсы для его обслуживания. В таблице маршрутизации узла фиксируются входной и выходной VCI канала и номера портов (входного и выходного), которые участвуют в формировании пути (рис. 7.6). В заголовке пакета указывается значение VCI VCI выходного порта предыдущего на маршруте узла. Узел 1 Вход Выход узел VCI узел VCI A 1 3 2 A 5 3 3 3 2 A 1 3 3 A 5 Узел 2 Вход Выход узел VCI узел VCI С 6 4 3 4 3 С 6 Узел 3 Вход Выход узел VCI узел VCI 1 2 6 7 1 3 4 4 4 2 6 1 6 7 1 2 6 1 4 2 4 4 1 3 Узел 4 Вход Выход узел VCI узел VCI 2 3 3 2 3 4 5 5 3 2 2 3 5 5 3 4 Узел 6 Вход Выход узел VCI узел VCI 3 7 B 8 3 1 B 5 B 5 3 1 B 8 3 7 Узел 5 Вход Выход узел VCI узел VCI 4 5 D 2 D 2 4 5 Рисунок 7.6. Таблицы маршрутизации в сети с виртуальными каналами 399 Таблицы на рис. 7.6 соответствуют сети рис. 7.3, в которой сформированы виртуальные каналы для трех путей: «А ̶ М1 ̶ М3 ̶ М6 ̶ B», «А ̶ М1 ̶ М3 ̶ М4 ̶ М5 ̶ D» и «C ̶ М2 ̶ М4 ̶ М3 ̶ М6 ̶ B». При их построении предполагалось, что линии связи работают в дуплексном режиме и узловые идентификаторы каналов одинаковы для обоих направлений передачи. Каждый сквозной виртуальный канал формируется совокупностью логических каналов между парами маршрутизаторов. При этом, значения идентификаторов VCI этого канала назначаются автономно в каждом узле коммутации. В рассматриваемом примере для первого виртуального канала идентификатор VCI = 1, назначенный ему исходным узлом A, преобразуется маршрутизатором M1 в VCI = 2, который, в свою очередь, маршрутизатором M3 будет заменен на VCI = 7 и маршрутизатором M6 – на VCI = 8. Использование локальной нумерации виртуальных каналов дает два преимущества. Прежде всего, это позволяет поддерживать в сети большее число виртуальных каналов при неизменной (обычно, 1–2 байта) длине поля, отводимого для записи идентификатора VCI в заголовке пакета. Во-вторых, при локальной нумерации в таблице маршрутизации отражаются только каналы, поддерживаемые этим узлом в текущий момент времени. В случае же глобальной нумерации при назначении идентификатора очередного канала необходимо было бы проверить, что выбранный идентификатор не используется на других узлах – весьма трудоемкая задача для больших сетей; размеры таких таблиц и время поиска в них были бы также несравненно большими. Наличие зафиксированного в таблицах маршрутизации виртуального канала позволяет продвигать пакеты соединения по постоянному пути. Так, например, любой пакет, имеющий VCI=6 и прибывший от хоста С в узел 2, передаётся на выходной порт, связанный с узлом 4, а значение идентификатора виртуального канала, которое указывается в заголовке пакета, становится равным 3. В узле 4 этот пакет будет передан на порт, к 400 которому подключена линия, связывающая его с узлом 5; при этом пакет получит VCI = 5. Наконец, в узле 5 этот пакет будет передан на порт, к которому подключена сеть 6, и в неё он попадет со значением идентификатора VCI = 2. Заметим, что VCI в неявном виде содержит как путь, так и все требования к обслуживанию пакетов, а размер идентификатора заметно меньше размера сетевого адреса, что сокращает накладные расходы протокола, ускоряет поиск требуемой записи в таблице и уменьшает время обслуживания пакетов. При реализации в объединённой сети дейтаграммного сервиса лучшие пути до её парциальных сетей каждым маршрутизатором вычисляются и фиксируются в таблицах маршрутизации на этапе инициализации. Строки этих таблиц содержит, как минимум, три атрибута: «Адрес сети назначения», «Выходной порт», «Адрес следующего узла». Следовательно, пакеты всех приложений, между парой станций разных парциальных сетей, будут следовать по одному маршруту, а индивидуализация их обслуживания потребует анализа других полей заголовка пакета. Узел 1 Сеть Следующий назначения узел 1 присоедин. 2 М2 3 M3 4 M4 6 M2 Узел 2 Сеть Следующий назначения узел 1 M1 2 присоедин. 3 M1 4 M4 6 M5 Узел 3 Сеть Следующий назначения узел 1 M1 2 M4 3 присоедин. 4 M4 6 M6 Узел 4 Сеть Следующий назначения узел 1 M1 2 M2 3 M3 4 присоедин. 6 M3 Узел 6 Сеть Следующий назначения узел 1 M3 2 M5 3 M3 4 присоедин. 6 M5 Узел 5 Сеть Следующий назначения узел 1 M2 2 M2 3 M6 4 M4 присоедин. 6 Рисунок 7.7. Таблицы маршрутизации узлов в дейтаграммной сети 401 Если в качестве метрики длины пути принять число переходов до сети назначения, то таблицы маршрутизации в узлах сети рис. 7.3 будут иметь вид, приведенный на рис. 7.7. Пусть пакет, адресованный в сеть 6 (узел D), которая непосредственно присоединена к маршрутизатору M5, прибывает на узел M1. В соответствии с его таблицей маршрутизации, этот пакет будет далее направлен узлу M2, далее – к узлу M5 и в сеть 6, которой принадлежит узел D. Таблица каждого узла должна содержать записи маршрутов ко всем парциальным сетям объединенной сети, которых может быть много и, следовательно, как расчёт путей, так и поиск требуемой записи в таблице могут занимать значительное время. Поля адресов парциальных сетей имеют размер заметно больший размера поля VCI, следовательно, хранение таблиц потребует больших затрат оперативной памяти маршрутизаторов. Эти два обстоятельства увеличивают трудоемкость продвижения пакетов в дейтаграммных сетях. Однако, отсутствие необходимости фиксации потоков и резервирования ресурсов для их обслуживания, возможность относительно быстро адаптировать маршруты к изменению состояния сети, делают этот вид сервиса вполне конкурентоспособным при решении задачи межсетевой связности. 7.2.2. Алгоритмы нахождения кратчайшего пути Задача маршрутизации в коммутируемых сетях (раздел 4.2.4), решаемая при построении таблиц коммутации, имеет много общего в математическом отношении с рассматриваемой здесь. Но построение межсетевых путей выполняется в условиях произвольной распределенной и подверженной частым изменениям топологии объединенной сети. В силу этого, алгоритмы межсетевой маршрутизации должны быть максимально универсальными. Большинство из них являются алгоритмами кратчайшего пути в том смысле, что они определяют оптимальный маршрут на основе минимизации выбранной целевой функции. При этом, они должны: 1. вычислять маршрут за приемлемое время (сходимость); 402 2. обладать достаточной адаптивностью к изменениям топологии сети и к состоянию её каналов связи (сходиться при разных начальных условиях); 3. генерировать служебный трафик, объем которого мал относительно объема данных, содержащихся в маршрутизируемых пакетах. «Длинной» каждого элемента маршрута может быть:  условная единица; в этом случае, кратчайшим будет маршрут, сформированный из наименьшего числа таких элементов (переходов);  величина, обратная маршрутизаторами; пропускной в этом способности случае, линии кратчайшим связи будет между маршрут, сформированный на линиях с максимально возможной пропускной способностью;  величина, пропорциональная средней задержке обработки маршрутизатором пакетов на конкретном выходном интерфейсе; в этом случае кратчайшим становится маршрут с наименьшими суммарными задержками доставки пакетов до узла назначения;  величина, пропорциональная степени загруженности участка сети (например, относительный средний уровень трафика на соответствующем интерфейсе, размер выходной очереди и т. д.); в этом случае, кратчайший маршрут не будет включать участки, уже испытывающие перегрузки. Протокол маршрутизации должен поддерживать, как минимум, один способ измерения «длин» («стоимостей») линий связи между узлами сети, а все маршрутизаторы в объединённой сети должны поддерживать, по крайней мере, одну общую метрику. Вычисление «кратчайших» маршрутов производится на основе алгоритмов двух классов, различающихся исходной информацией. 1. В алгоритмах «длины вектора расстояния» (distance vector routing) соседние маршрутизаторы (непосредственно связанные на канальном уровне) обмениваются своими таблицами маршрутизации, содержащими сведения о достижимых сетях и расстояниях до них. Получив эту 403 информацию, каждый маршрутизатор корректирует свою маршрутную таблицу так, чтобы минимизировать длину пути до всех известных сетей посредством выбора «лучшего» следующего узла–маршрутизатора из числа своих соседей. Эти алгоритмы адаптируется к изменениям топологии сети настолько быстро, насколько часто маршрутизаторы обмениваются своими маршрутными таблицами. В крупных сетях такой обмен порождает значительный служебный трафик и поэтому он не может выполняться часто. 2. В алгоритмах «состояния канала» (link state routing) каждый маршрутизатор передает через все свои интерфейсы информацию о состоянии каналов, которыми он соединен с соседями, и о сетях, непосредственно подключенных к его интерфейсам. Получатели этих сообщений, дополнив их информацией о свои каналах и сетях, транслируют её дальше своим соседям и т. д. В конце концов, все маршрутизаторы получают информацию о существующих в объединённой сети узлах, каналах связи и парциальных сетях. На основании этой информации каждый маршрутизатор строит граф сети и в автономном режиме вычисляет наилучший, в заданном смысле, маршрут от себя до всех парциальных сетей. Отметим, что протоколы, базирующиеся на таких алгоритмах, лучше масштабируемы, поскольку предполагают обмен информацией только о состоянии каналов и не передают свои таблицы маршрутизации; они обладают еще несколькими преимуществами, которые будут рассмотрены при анализе конкретных реализаций. Наиболее широкое применение в протоколах маршрутизации по принципу кратчайшего пути нашли алгоритмы Беллмана–Форда и Дейкстры. 7.2.2.1. Алгоритм Беллмана–Форда Алгоритм Беллмана–Форда (называемый также алгоритмом Форда– Фулкерсона) относится к классу алгоритмов длины вектора расстояния. Он базируется на следующем очевидном принципе (рис. 7.8). Если маршрутизатор А непосредственно связан линиями «длинной» C Aj с 404 маршрутизаторами j  ( B, C , F ) , а расстояния от последних до целевой сети Z равны соответственно DB, DC и DF, то кратчайший маршрут от маршрутизатора A до сети Z будет проходить через узел j  ( B, C , F ) , для которого DA  min (C Aj  D j ) . j R2 C12 = 4 R1 C13 = 3 Сеть АСМ D Z ⋯ ? ⋯ ? ⋯ R3 C14 = 2 R4 Сеть АСМ D Z ⋯ R5 ⋯ 7 ⋯ Сеть АСМ D Z ⋯ R7 ⋯ 4 ⋯ Сеть АСМ D Z ⋯ R8 ⋯ 6 ⋯ Сеть Z Рисунок 7.8. Идея алгоритма Беллмана – Форда Например, определим кратчайший путь от маршрутизатора R1, к сети Z в объединённой сети, фрагмент которой представлена на рис. 7.8. Для того, чтобы пакет, поступивший на входной интерфейс R1, мог достичь узла назначения в сети Z, он должен быть передан одному из трех соседям R2, R3 или R4. Предположим, что «длины» путей от каждого из этих маршрутизаторов до сети назначения Z уже известны и составляет 4, 3 и 2 условные единицы соответственно. Тогда полная «длина» путей R1 – Z равна: 11 через маршрутизатор R2, 7 через маршрутизатор R3 и 8 через маршрутизатор R4. Таким образом, кратчайший путь от R1 до сети Z пролегает через маршрутизатор R3, который и становится следующим узлом маршрута. Проведем формальное рассмотрение алгоритма на примере объединённой сети, представленной на рис. 7.9. Пусть Dj – текущая оценка кратчайшего пути от маршрутизатора j до сети назначения и Cij «длина» («стоимость») линии между маршрутизаторами i и j. При этом, Cii = 0 и Cij = Cji и Сij   , если узлы i и j непосредственно не связаны. 405 В этих обозначениях, выражение для кратчайшего пути от узла М2 к сети 4 (узел М6) имеет вид: D2  min C21  D1, C24  D4 , C25  D5   C24  D4  4 . (7.1) F А 2 М1 Сеть 1 2 М6 М4 1 С Сеть 3 1 5 3 М3 М2 4 Сеть 4 2 3 М5 B D Сеть 6 Сеть 2 Рисунок 7.9. Объединённая сеть с назначенными «длинами» линий Одним из существенных условий таких вычислений является предположение о том, что длины кратчайших путей (D1, D4, D5) от маршрутизаторов М1, М4 и М5 до целевой уже вычислены. Но при инициализации сети или при изменении её топологии значений (D1, D4, D5) ещё нет. Это требует дополнения (7.1) уравнениями относительно D1, D4, D5. Например, D1  min C21  D2 , C13  D3 , C14  D4 , (7.2) D4  min C41  D1, C42  D2 , C43  D3 , C45  D5 . (7.3) Аналогичные уравнения можно записать и для расстояний D3 и D5. Хорошо видно, что эти выражения в своей совокупности образуют систему линейных уравнений относительно D1 ÷ D5. Алгоритм Беллмана–Форда, собственно, и является итерационной процедурой решения этой системы. В общем виде он записывается следующим образом. 1. {Инициализация } Di0  , i  d {d  номер маршрутизатора сети назначения} Dd  0; k  0 {N - общее число маршрутизаторов в сети} 2. {Обновление оценок расстояний до сети назначения} 406 Для i  1,2....N , i  d вычислить Dik 1  min{Cij  D kj }, j  i, j  1,2....N j 3. ЕСЛИ Dik 1  Dik , i То конец ИНАЧЕ k  k  1 и перейти к шагу 2. Проиллюстрируем работу алгоритма на примере представленной выше сети. Вычислим кратчайшие пути от каждого маршрутизатора к сети 4, непосредственно подключенной к узлу M6. Дуплетом (n, Di) будем обозначать номер следующего узла n на кратчайшем пути от узла i к сети 4 и текущее значение длины этого пути Di. Если следующий узел на текущей итерации не определен, то n  1 . Результаты вычислений на каждом шаге алгоритма представлены в таблице 7.1. Таблица 7.1. k 1 2 3 Узел M1 (-1, ∞) (-1, ∞) (3,3) (3,3) Узел M2 (-1, ∞) (-1, ∞) (4,4) (4,4) Узел M3 (-1, ∞) (6,1) (6,1) (6,1) Узел M4 (-1, ∞) (3,3) (3,3) (3,3) Узел M5 (-1, ∞) (6,2) (6,2) (6,2) Видим, что алгоритм сошелся достаточно быстро и его результат позволяет записать в таблице маршрутизации узла М1 строку Сеть назначения 4 Следующий узел М3 Расстояние 3 Аналогично, узел М2 запишетет в своей маршрутной таблице строку Сеть назначения 4 Следующий узел М4 Расстояние 4 Приведенный пример наглядно иллюстрирует важнейшее свойство алгоритма Беллмана-Форда, а именно, его распределенный характер – каждый маршрутизатор для проведения расчета текущей оценки Dik 1 требует информацию о результатах вычислений расстояний до целевой сети D kj , выполненных другими маршрутизаторами. Вместе с тем, результаты 407 этих вычислений (вектор Dik 1 ) должны быть доставлены только к соседям, т. е. маршрутизаторы используют неполную информацию о связях в сети. Изменения в маршрутных таблицах инициируются любым маршрутизатором посредством рассылки им через все свои порты нового вектора минимальных расстояний до известных ему сетей. Этот механизм называют инициированным обновлением, а его реализуемость является следствием сходимости алгоритма Беллмана-Форда к верным результатам при весьма мягких начальных условиях. Можно показать, что алгоритм сходится за конечное число шагов при неотрицательных оценках Di0  0, i  d , т. е. если ситуация в сети изменилась («стоимости» путей изменились), то это не помешает вычислению правильных кратчайших путей. Обратимся к сети, рассматренной выше (рис. 7.9) и предположим, что после завершения работы алгоритма (состояние, представленное таблицей 7.1) линия, соединяющая маршрутизаторы М3 и М6 вышла из строя. Вычислим минимальные расстояния от всех остальных маршрутизаторов к сети 4 (узлу М6) в этих новых условиях. Будем считать, что каждый из маршрутизаторов после получения информации от своих соседей об изменении их расстояний к парциальным сетям немедленно приступит к пересчету своих оценок этих расстояний и будет незамедлительно сообщать каждое их значение своим соседям. Как только маршрутизатор М3 обнаружит выход из строя линии 3-6, он вычислит новое минимальное расстояние к маршрутизатору М6 (равное 5) и следующий узел на пути (М4). М3 отправит это обновленное значение вектора расстояний своим соседям (М1 и М4). Эти узлы пересчитают свои минимальные расстояния до целевой сети (до маршрутизатора М6) и разошлют их своим соседям. Получение этих сообщений инициализирует пересчет минимального расстояния маршрутизаторами М2 и М5. Описанный процесс первой итерации алгоритма представлен во второй строке таблицы 7.2 (k = 1). Далее, для простоты, будем считать, что процессы пересчета происходят синхронно на всех узлах. Как видно, алгоритм сошелся за 4 итерации. 408 Таблица 7.2. Узел M1 (3, 3) k 1 Узел M2 (4, 4) Узел M3 (6, 1) (4, 5) Узел M4 (3, 3) (2, 7) 2 3 4 (3, 7) (2, 9) (2, 9) Узел M5 (6, 2) (2, 5) (5, 6) (4, 6) (4, 6) (4, 6) (4, 7) (4, 7) (4, 7) (6, 2) (6, 2) (6, 2) (6, 2) (5, 5) (5, 5) (5, 5) Хотя алгоритм Беллмана Форда и сходится к правильным значениям кратчайших расстояний, этот процесс может быть в определенных условиях чрезвычайно медленным. На рис. 7.10 приведен простейший пример возникновения такой ситуации. М1 1 1 М2 1 М3 М1 1 100 1 М2 ∞ М3 100 Рисунок 7.10. Иллюстрация возможности медленной сходимости алгоритма Беллмана-Форда Сеть назначения здесь подключена к узлу М3. Если линия М2 - М3 выходит из строя, то алгоритм дает последовательность значений минимального расстояния от узла М2: 1, 3, 5, ⋯, 101, сходящуюся лишь на 49 итерации. Для узла М1 получаем аналогичную последовательность минимальных расстояний до М3: 2, 4, 6, 8, 10, ⋯, 100. Следствиями медленной сходимости алгоритма могут быть:  увеличение объема данных, которыми обмениваются маршрутизаторы и, соответственно, уменьшение реальной производительности сети;  образование петель маршрутизации. Для предотвращения подобных явлений были предложены несколько усовершенствований алгоритма Беллмана–Форда, но эффект их применения ограничен конкретными топологиями. Одно из таких усовершенствований получило название ассиметричного объявления. Часто его называют «расщепление горизонта», что является 409 буквальным переводом англоязычного названия этого приема split horizon (не очень удачное название, по крайней мере, для говорящих на русском языке). Суть этого усовершенствования заключается в запрещении узлу транслировать информацию о минимальном расстоянии до сети назначения через порт, с которого этот минимальный маршрут начинается. Это ограничение упрощенно может быть сформулировано следующим образом: «Не надо сообщать узлу K о расстояни до целевой сети, если он является следующим узлом на этом пути, поскольку имено на основе его информации это расстояние и было вычислено». Другой прием, называемый ложной неудачей (poison reverse), служит тем же целям и заключается в отсылке на этот порт заведомо неверной информации, а именно, бесконечного расстоянии до целевой сети. Проиллюстрируем принципиальную применимость последнего приема для ускорения процедуры сходимости алгоритма Беллмана–Форда в ситуаци, представленной рис. 7.10. 1. После возникновения разрыва канала М2 – М3 узел М2 вычислит: D2  {C21  D1}  {1  2}  3 и следующий узел М1. Однако, на порт, связывающий его с узлом М1, будет передано D2 = ∞. 2. Узел М1 в свою очередь определит: D1  min{C12  D2 , C13  D3}  min{1  , 100  0}  100 и следующий узел М3. Эта информация будет передана узлу М2 и он пересчитает свое минимальное расстояние. 3. D2  min{C21  D1, C23  D3}  min{1  100,   0}  101 и следующий узел М1, куда снова будет передано D2 = ∞. 4. В узле М1 снова вычисляется D1  min{C12  D2 , C13  D3}  min{1  , 100  0}  100 и следующий узел М3. 5. В свою очередь, узел М2 вновь вычислит D2  min{C21  D1, C23  D3}  min{1  100,   0}  101 , т. е. величина D2 не изменилась, процесс сошелся. Описаные итерации алгоритма представлены в таблице 7.3. 410 Таблица 7.3 Узел M2 Вычислено Объявлено D3 k Узел M1 До выхода из строя линии М2-М3 (2,2) (3,1) 1 1 2 3 (3,100) (3,100) (3,100) (1, 3) (1,101) (1,101)   Применение алгоритма Белмана-Форда в протоколах маршрутизации Алгоритм длины вектора расстояния применяется рядом протоколов маршрутизации, в том числе протоколами Интернет RIPv1, RIPv2, фирменными протоколами Cisco IGRP, Novell RIP for IPX и т.д. Из описания алгоритма, приведенного выше, ясно, что маршрутизатор, обнаружив изменения состояния своих интерфейсов, должен начать пересчёт свей таблицы маршрутов и это иницирует обновление состояния таблиц соседей. Очевидно, что работоспособность описанного механизма существенно зависит от количества маршрутизаторов в сети. Прежде всего, при их большом числе объем служебного трафика также оказывается значительным. Кроме этого, несмотря на принципиальную сходимость алгоритма Белмана-Форда, этот процесс занимает тем большее время, чем более масштабна сеть. Это плохо, поскольку в течение периода сходимости будет рассылаться не вполне достоверная информация о возможных маршрутах. Её использование может приводить к вычислению неэффективных, а иногда и несуществующих маршрутов. В больших сетях лучшими показателями скорости сходимости и меньшим объемом порождаемого служебного трафика обладают протоколы, базирующиеся на алгоритме Дейкстры. 7.2.2.2. Алгоритм Дейкстры Алгоритм Дейкстры поиска кратчайшего пути между парциальными сетями отноится к классу алгоритмов состояния каналов (link state routing). Он, как и алгоритм Белламана–Форда, требует задания неотрицательной «стоимости» каждой линии, связывающей маршрутизаторы в сети, что принципиально реализуемо. Но в отличие от рассмотренного выше 411 алгоритма, алгоритм Дейкстры предполагает, что вся топологическая информация (идентификаторы маршрутизаторов, матрица их связей, «стоимость» линий, адреса непосредственно присоединенных сетей) известна всем маршрутизаторам. На основании этой информации каждый узел самостоятельно строит граф сети и, считая себя корневым, находит его минимальное дерево (дерево с минимальными длинами путей до всех своих вершин). Построение минимального дерева заключается в последовательном определении узлов, ближайших к корневому. Этому условию удовлетворяют узлы, связанных с каким-то из ранее найденных ближайших соседей так, что полное расстояние от них до корневого оказывается минимальным. Иллюстрацией алгоритма может служить следующая модель. Пусть существует множество связанных между собой нитями различной длины шаров, лежащих на горизонтальной поверхности. Длины нитей моделируют различную «стоимость» линий связи между маршрутизаторами сети (шарами). Множество ближайших соседей можно определить поднимая «корневой» шар и фиксируя номера шаров, последовательно отрывающихся от поверхности стола; нити, связывающие очередной такой шар с множеством уже поднятых шаров дают связи в минимальном дереве. Пусть корневым является шар 1. При его подъеме, в какой-то момент от поверхности оторвется шар, который связан с шаром 1 нитью минимальной длины. Пусть его номер 2 (здесь важно то, что мы узнали номер этого шара), а расстояние между ними равно длине нити 1-2. По мере дальнейшего подъема шара 1 расстояние между ним и шаром 2 уже не изменится. Когда от поверхности оторвется следующий шар, пусть шар 3, расстояние между ним и корневым шаром 1 определится либо длиной нити 1-3 (а она известна), либо суммой длин нитей 1-2 и 2-3, которые также известны. Минимальная из этих величин даст расстояние от корня до шара 3. Как видим, агоритм построения минимального дерева должен решать задачу: «шар с каким номером будет очередным ближайшим к корневому и 412 какая нить, из числа связывающих его с множеством ранее найденных ближайших соседей, обеспечит минимальную длину связи его с корневым шаром?». Пусть последним из оторвавшихся от поверхности был шар с номером k и расстояние между ним и корневым шаром 1 равно Dk. Пусть существуют оценки Dk+i расстояний от шара 1 ко всем шарам с номерами k+i, i=1, 2, … . Возможно, что после отрыва от поверхности стола шара с номером k какие-то из Dk+i надо будет заменить на величины Dk + Cki, (Cki – длины нитей, связывающих шар k с еще остающимися на поверхности шарами). Так, если расстояние Dk+Cki окажется меньше, чем ранее вычисленная оценка Dk+i, то последняя заменяется этим меньшим значением, в противном случае величина Dk+i остаётся неизменной. Сравнение обновленных значений Dk+i по критерию минимума даст номер шара (k + i), который оторвется от поверхности следующим и, следовательно, станет очередным «ближайшим соседом». Алгоритм реализуется как итерационная процедура формирования множества узлов «ближайших соседей» (множество N). На каждой итерации алгоритма это множество пополняется одним узлом. При этом вычисляется и «длина» пути к нему от корневого узла. Алгоритм завершается, когда в множество N будут включены номера всех узлов сети. Пусть узел s является корневым; оценки минимального расстояние от узла s до узлов i обозначим Di, а «длины» линий, непосредственно связывающих узлы i и j, обозначим Cij. Если узлы i и j не имеют непосредственной связи, то Cij   . В этих обозначения алгоритм Дейкстры записыввается следующим образом. 1. {Инициализация} N={s} D j  Csj , j  s; D s  0 . 2. {Нахождение «ближайшего соседа»}   Вычислить i  indexmin D j  .  j N  413 Добавить вершину i в N. 3. {Найти новую ветвь (i, k) минимального дерева}   k  index min L j  ( D j  Cij ) .  j N , j  i  4. ЕСЛИ N содержит все вершины, ТО «Конец» 5. {Обновление оценок минимальных расстояний} Для всех j  N вычислить D j  min{ D j , Di  Cij } . Перейти к шагу 2. Проиллюстрируем работу алгоритма на примере сети, граф которой представлен на рис. 7.9, предполагая, что узел 1 является корневым. Таблица 7.4 содержит результаты всех шагов алгоритма. Её первая строка соответствует выполнению процедуры инициализации алгоритма. Жирным шрифтом выделено найденное на текущей итерации значение длины пути от «ближайшего соседа» до корневого узла. Последняя строка содержит набор кратчайших расстояний от узла 1 до всех узлов сети. Таблица 7.4 Итерация N D2 D3 D4 D5 D6 {1} 3 2 5  1 {1, 3} 3 2 4   2 {1, 3, 2} 3 2 4 7 3 3 {1, 3, 2, 6} 3 2 4 5 3 4 {1, 3,2, 6, 4} 3 2 4 5 3 5 {1, 3, 2, 6, 4, 5} 3 2 4 5 3 3 В ходе реализаци алгоритма ведется построение дерева кратчайших путей с корнем в узле 1 (в рассматриваемом примере). На каждой итерации определяется линия, которая связывает найденный очередной «ближайший» узел (пусть узел i) с узлом k из множества N, для которого Dk+Cki имеет минимальное значение (рис. 7.11). Заметим, что путь от корневого узла к узлу i полностью проходит через узлы множества N. 414 1 итерация 1 2 2 итерация 3 1 3 2 3 итерация 3 1 2 3 1 4 итерация 6 3 2 1 3 1 1 6 2 3 2 2 5 итерация 4 3 1 6 2 3 2 4 2 2 2 5 Рисунок 7.11. Последовательность формирования дерева кратчайших путей на графе сети рис. 7.5 алгоритмом Дейкстры Так, на второй итерации в качестве «ближайшего соседа» определен узел 2, который становится очередной вершиной минимального дерева. В множестве N уже находятся узлы 1 и 3 и найденный новый узел может быть соединен с деревом посредством линий 2-1, или 2-3. Проверив D1+C21 и D3+С23 определяем, что узел 2 должен соединятся с минимальным деревом посредством линии 2-1. Наконец на 5-й итерации найден ближайший сосед – узел 5. К этому моменту в множестве N уже содержатся узлы 1, 2, 3, 4, 6. Узел 5 не имеет непосредственной связи с узлом 1. Проверка значений Dk+С5k, где k=1, 2, 3, 4, 6 показывает, что в дерево должна быть включена линия 5-6, как обеспечивающая минимальное расстояние от узла 1 до узла 5. Таким образом, на каждой итерации минимальное дерево пополняется одной ветвью, как это показано на рис. 7.11. На основании построенного минимального дерева узел M1 формирует таблицу маршрутизации, которая будет иметь вид представленный ниже. Таблица 7.5. Сеть назначения 2 3 4 6 Следующий узел M2 M3 M3 M3 Длина маршрута 3 2 3 5 Перечислим существенные характеристики алгоритма Дейкстры. 1. Необходимость получения каждым узлом информации о топологии, «длинах» линий и о парциальных сетях, входящих в объединённую сеть. 2. Автономность расчета кратчайших путей каждым узлом. 415 3. Для инициализации обновления таблиц маршрутизации узлу достаточно сообщить своим соседям об изменении состояния какой-то из его линий линии и/или состава непосредственно присоединенных сетей. 4. Отсутствие необходимости обмена таблицами маршрутизации существенно сокращает объем служебного трафика, а знание всей топологии сети способствует повышению скорости сходимости алгоритма и гарантирует нахождение действительно кратчайших путей. Применение алгоритма Дейкстры в протоколах маршрутизации Построения маршрутной таблицы на базе алгоритма Дейкстры требует, чтобы каждый маршрутизатор, кроме собственно реализации алгоритма, выполнял следующие процедуры:  оповещение о присутствии в сети, обнаружение соседей и получение их имен (адресов);  измерение «стоимости» линий связи с соседями;  создание и рассылка сообщений с информацией о состоянии линий, связывающих его с соедями, о присоединенных сетях, о ставших ему известными сетях и линиях связи других маршрутизаторов;  формирование полной топологической схемы объединенной сети. Рассмотрим кратко содержание перечисленных процедур. Оповещение о присутствии и обнаружение соседей При включении маршрутизатор отправляет специальное сообщение HELLO через все свои интерфейсы, помещая в него собственное имя (адрес). Каждый маршрутизатор, получив это сообщение, считывает с него адрес отправителя, записывает его в свою топологическую базу данных и отвечает собственным пакетом HELLO. Ясно, что используемые имена (адреса) маршрутизаторов должны быть глобально уникальны. Измерение «стоимости» линий связи «Стоимость» линий может определяться различными метриками, в том числе: величиной задержки передачи, номинальной пропускной 416 способностью, доступной пропускной способностью, какой-либо сверткой этих критериев. Метрика выбирается администратором сети, и все маршрутизаторы должны использовать единую метрику. Заметим, что в сети могут использоваться одновременно несколько метрик, благодаря чему каждый узел может располагать маршрутными таблицами, оптимальными в смысле разных критериев, и применяться для маршрутизации конкретного пакета будет та из их, которая лучше соответствует параметрам качества обслуживания, указанным в его заголовке. Измерение соответствующих «стоимостей» («длин») линий является отдельной оригинальной задачей, и методы её решения протоколами маршрутизации не регламентируются. Примером одного из таких методов может служить использование специального ICMP-сообщения ECHO для измерения времени задержки передачи. Каждый соседний узел, получив такое сообщение, обязан в срочном порядке дать на него ответ отсылкой аналогичного сообщения. Тем самым, инициатор этого обмена получает время двойного оборота, половина которого и даст оценку времени задержки передачи по данной линии. Для повышения достоверности измерений проводится несколько обменов пакетами ECHO и результаты измерения усредняются. В метрике пропускной способности «стоимостью» линии может служить целая часть отношения 10000/R, R – скорость интерфейса линии в Мбит/с. Важными вопросами при расчёте значений любых метрик является периодичность параметров, требующие их повторения, оповещения пороговые «соседей», значения трудоемкость этих таких измерений и т. п. Формирование пакета состояния линий Маршрутизатор формирует сообщения состояния линий, включая в него поля, представленные на рис. 7.12. «Характеристиками линии» могут быть скорость интерфейса, адреса присоединенных сетей и т.д. 417 Имя Порядковый Возраст отправителя номер сообщения Имя «Характерист. Имя «Характерист. линии» линии» м-ра 1 м-ра 2 м-ра 2 м-ра 1 ⋯ Рисунок 7.12. Примерный формат сообщения состояния линий Сообщения «состояния линий» рассылаются каждым узлом в режиме «заливки». Каждый узел, получив такое сообщение, сохраняет у себя ранее неизвестную ему информацию и отправляет его дальше через все свои интерфейсы, кроме того, с которого оно было получено. Благодаря этому, информация о маршрутизаторах сети, о парциальных сетях и к каким узлам они непосредственно присоединены, о состояниях линий становится известной всем. При этом, множественность путей в многосвязной сети делает возможным получение маршрутизаторами собственных сообщений, либо сообщений-дубликатов; и те, и другие должны удаляться. Получив сообщение состояния, маршрутизатор сравнивает его номер с номером ранее полученного сообщения от этого же узла. Если номер прибывшего сообщения меньше, либо равен номеру сообщения, информация из которого уже зафиксирована в топологической базе узла, то прибывшее сообщение уничтожается. Хотя переполнение 32-разрядного счетчика отсылаемых сообщений едва ли возможно (232=4294967296 и при отсылке 1 сообщения в секунду счетчика «хватит» на 136.2 года), но при перезагрузке маршрутизатора нумерация начнется с нуля и сообщения, не являющиеся дубликатами, могут интерпретироваться как таковые. Для предотвращения таких ошибок в заголовке сообщения введено поле «Возраст сообщения». В него при формировании сообщения записывается достаточно большая величина (например, 3600), которая уменьшается на единицу каждым получившим сообщение маршрутизатором. При получении двух сообщений состояния с одинаковыми порядковыми номерами то из них, в котором значение поля «Время жизни» меньше, чем в ранее полученном с тем же номером, удаляется; в противном случае – информация из него считывается и пакет ретранслируется «соседям». 418 В заключение отметим, что в сети, состоящей из m узлов, каждый из которых имеет p соседей, хранение таблицы состояния линий потребует выделение памяти, размер которой пропорционален величине mp. В очень больших сетях это может стать проблемой. Эта и ряд других трудностей масштабирования привели к тому, что большие сети, в которых решение задачи маршрутизации административно управляется одним центром, разбиваются на отдельные домены, размер которых оказывается приемлемым для эффективного решения этой задачи, даже с учетом необходимости междоменного обмена информацией о маршрутах. Заключение к разделу 7 Задачу объединения в единую информационно-коммуникационную структуру разных локальных сетей, при сколь угодно сложной топологии физических связей между ними, решают процедуры уровня межсетевого взаимодействия. Для этого, протоколы сетевого уровня поддерживают:  иерархически организованную систему логической адресации, позволяющую единообразно и независимо от технологий парциальных локальных сетей идентифицировать узлы и их разномасштабные совокупности;  вычисление наилучших, в определённом смысле, путей передачи пакетов между взаимодействующими узлами из разных сетей (задача маршрутизации). Свои функции уровень межсетевого взаимодействия может выполнять как в форме дейтаграммного сервиса, так и сервиса виртуального канала. Задача маршрутизации – это поиск либо пути минимальной «длины» («стоимости»), либо пути, удовлетворяющего набору административных и организационно–технических ограничений. Принцип «кратчайшего пути» реализуем в сетях, имеющих единое административное управление, а маршрутизация «по правилам» используется, в основном, при организации передачи трафика между сетями юридически самостоятельных субъектов. 419 Для поиска «кратчайших» путей применяются алгоритмы БеллманаФорда (длины вектора расстояния) и Дейкстры (алгоритм состояния каналов). Первый из них требует ограниченный объём топологических данных о сети, но его исполнение носит распределённый характер и порождает значительный объём служебного трафика, что и ограничивает масштаб сети, в которой он может применяться. Алгоритм Дейкстры требует наличия полной топологической информации о сети. Её формирование связано с интенсивным обменом данными между маршрутизаторами сети и является самой «затратной» частью протокола маршрутизации. Выполняется алгоритм Дейкстры автономно на каждом узле, что сокращает время расчёта маршрутов и не генерирует дополнительный служебный трафик. В целом, сети с маршрутизацией на основе алгоритмов состояния каналов масштабируются существенно лучше сетей с маршрутизацией на базе алгоритмов длины вектора расстояния. Результатом решения задачи построения маршрутов являются таблицы маршрутизации, которые служат инструментом коммутации пакетов между портами маршрутизатора. Контрольные вопросы к разделу 7 1. Укажите задачи межсетевого взаимодействия, выполняемые только конечной станции и только узлами маршрутизации трафика. 2. Почему локальные сети нельзя масштабировать до глобальных сетей? 3. Чем адресация сетевого уровня должна отличаться от адресации, используемой канальными протоколами? 4. Можно ли в сети с предварительным установлением соединения реализовывать ненадёжный сервис передачи данных? 5. Осуществим ли сервис виртуального канала в сети не поддерживающей установление соединения? 6. Какие преимущества обеспечивает статический метод маршрутизации в объединённой сети? 420 7. Алгоритмы Беллмана-Форда и Дейкстры строят маршрут, оптимальный в смысле какого критерия? 8. Что является результатом работы протокола маршрутизации? 9. Почему метрика числа переходов не является лучшим выбором в современных сетях? 10. Какие метрики следовало бы использовать для того, чтобы маршрутизация стала одновременно инструментом предупреждения перегрузок в сети? 11. Какие преимущества можно получить из наличия двух (трёх, …) маршрутов между сетями с одинаковыми показателями их «длины»? Какие проблемы может вызвать включение их в таблицу маршрутизации? 12. Какой из алгоритмов кратчайшего пути обеспечивает протоколу маршрутизации лучшие свойства масштабирования? Почему? 421 8. СЕТИ TCP/IP 8.1. Состав стека протоколов TCP/IP В состав стека протоколов TCP/IP (рис. 8.1), кроме давших название этим сетям протоколов транспортного уровня Transmission Control Protocol и уровня межсетевого взаимодействия Internet Protocol, входят: User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), ARP (Address Resolution Protocol), RARP (Reverse Address Resolution Protocol) и ряд протоколов прикладного уровня, в частности DNS, TELNET, FTP, SMTP, SNMP, HTTP и т. д. Прикладные протоколы TCP ICMP UDP IP ARP RARP Физическая сеть Рисунок 8.1. Состав стека протоколов TCP/IP В отличие от семиуровневой модели ВОС (OSI) протокольный стек TCP/IP содержит 4 уровня, верхним из которых является уровень прикладных протоколов. Разнообразие требований приложений к сетевому сервису обусловило наличие в стеке двух протоколов транспортного уровня. Так, например, приложения передачи файлов и web-приложения для пересылки своих сообщений используют протокол ТСР, в то время как приложения управления сетевыми устройствами (Simple Network Management Protocol, SNMP), служба доменных имён (DNS), сетевая 422 файловая система (Network File System, NFS), потоковые приложения реального времени работают с транспортным протоколом UDP. Уровень межсетевого взаимодействия представлен протоколом IP. Он обеспечивает логическую иерархическую адресацию совокупностей узлов (сетей), а также обеспечивает продвижение пакетов между конечными стациями по определённым путям через произвольную комбинацию взаимосвязанных сетей. Определение же наилучших в определённом смысле путей до сетей и узлов–получателей выполняют протоколы маршрутизации (RIP, OSPF, BGP и т. д.). По выполняемым функциям их следовало бы отнести к сетевым, но, по сути, они являются прикладными протоколам (поэтому и не представлены отдельно в схеме рис. 8.1). Протокол IP предоставляет транспортному уровню лишь один вид сервиса – передачу пакетов без предварительного установления соединения и настолько хорошо, насколько получится (дейтаграммный сервис). Пути пакетов в IP-сети определяются исключительно на основании адреса назначения, указанного в их заголовке. Изменение состояния сети и вызванное им изменение маршрутных таблиц могут быть причиной доставки узлу назначения частей одного сообщения с нарушением исходного порядка их отправки. В свою очередь, узлы маршрутизации могут испытывать перегрузки и уничтожать поступающие в периоды перегрузки пакеты. В таких условиях, восстановление (при необходимости) утерянных пакетов и надлежащий порядок их передачи приложению обеспечивают протоколы транспортного уровня. После определения по таблице маршрутизации сетевого адреса следующего узла маршрута, пакет передается модулю, представляющему физическую сеть (модулю канального протокола). У этого модуля при формировании канального кадра возникает необходимость определения физического (МАС) адреса следующего на маршруте устройства. Если соответствие этих адресов (IP и МАС) в таблице канального модуля отправителя не представлено, то для его нахождения используется протокол 423 ARP (Address Resolution Protocol). Иногда возникает и обратная задача определения логического сетевого адреса устройства по заданному физическому адресу. В частности, это необходимо для процедуры загрузки бездисковых станций, при выполнении которой такая станция рассылает в широковещательном режиме запрос, содержащий её физический адрес и «просьбу» сообщить ей логический сетевой адрес. Этот запрос обрабатывается специализированным сервером службы Reverse Address Resolution (RAR), который и передает станции требуемую информацию. Протокольные блоки верхних уровней инкапсулируются в протокольные блоки смежных с ним нижележащих уровней, как показано на рис. 8.2. При этом, блок протокола каждого уровня содержит специфическую информацию, позволяющую точно адресовать его происхождение и назначение. Так, сегмент TCP (UDP) содержит в своем заголовке номер порта, однозначно сформировал определяющий переносимое прикладной сегментом сообщение протокол, и номер который порта, соответствующий модулю принимающего приложения. IP-пакет имеет логические адреса узлов, однозначно определяющие их в объединённой сети. Кадр канального уровня всегда включает физический адрес узла, которому необходимо передать кадр. Включает номера портов источника и назначения Включает IP-адрес узла назначения и код обслуживаемого протокола Включает физические адреса узлов и код обслуживаемого протокола (IP, ICMP…) HTTP-запрос TCP/UDP заголовок SDU IP заголовок Заголовок канал. протокола Контр. сумма сегмента SDU SDU Контр. сумма кадра Рисунок 8.2. Инкапсуляция протокольных блоков в стеке TCP/IP 424 В стеке TCP/IP уровень физической сети выполняет функции канального и физического уровней модели OSI. Физический уровень TCP/IP-сети может использовать любую технологию канального уровня – Ethernet, Token Ring, РРР и т.д. Для обеспечения прозрачности физического уровня протокол сетевого уровня содержит процедуры фрагментации пакетов до размера, разрешенного соответствующим протоколом канального уровня (до значения его MTU). Обратная процедура, т. е. объединение пакетов малых размеров в блоки, величины которых приемлемы на канальном уровне, не выполняется. 8.2. Межсетевое взаимодействие. IP-протокол Основной протокол стека TCP/IP, – Internet Protocol (IP), предоставляя лишь ненадёжный сервис, по своим функциям частично соответствует уровню межсетевого взаимодействия модели OSI. Наиболее известной и широко используемой стала его четвёртая версия (IPv4, RFC 791, 1981). Версия 5 описывает экспериментальный протокол ST2, разработанный для передачи данных потоковых приложений реального времени. В 1998 году была опубликована шестая версия протокола (IPv6, RFC 2460). До сих пор она не стала доминирующей и в 2019 году доля трафика IPv6 в общемировом IP-трафике составляла 28,6%. Особенности протокола IPv6 будут рассмотрены отдельно; ниже, если не оговаривается особо, рассматриваются свойства четвертой версии этого протокола. Основными функциями протокола IP являются:  логическая адресация сетей и узлов;  формирование пакетов из сегментов транспортного уровня или сообщений прикладных протоколов;  продвижение пакетов через сколь угодно сложную комбинацию транзитных сетей, вне зависимости от применяемых в них технологий канального уровня. 425 8.2.1. Адресация в сетях IP Масштаб объединённой сети, в которой IP-протокол должен выполнять свои функции, варьируется от нескольких конечных станций и одного маршрутизатора, до всей сети Интернет с её десятками тысяч парциальных локальных сетей и миллионами конечных узлов. В этих условиях необходима единая общесетевая система логической адресации разномасштабных совокупностей сетевых узлов. Кроме этого и любой интерфейс узла объединённой сети должен иметь уникальный адрес. Принятая в протоколе IP система адресации предполагает, что каждое сетевое устройство обязательно имеет два адреса:  Физический адрес, формат которого определяется используемой технологией канального уровня. Для Ethernet и Token Ring – это шестибайтный аппаратный адрес интерфейсной карты, назначаемый её производителем;  Уникальный интерфейсу логический сетевого сетевой устройства адрес (IP-адрес), администратором назначаемый или получаемый автоматически от специальной сетевой службы. Наряду с уникальным логическим IP-адресом (unicast address), устройству (интерфейсу) может назначаться один или несколько групповых адресов (multicast address). Групповая адресация позволяет доставлять пакеты, генерируемые множеству получателей, объединённой сети. в единственном находящихся Используется экземпляре, в в разных определённому локальных архитектуре сетях IP-сети и широковещательная адресация в двух её формах – локальной, когда пакеты доставляются всем узлам локальной сети, в которой находится источник, и направленная, когда пакеты доставляются всем узлам локальной сети получателя. Спецификация IP–протокола (RFC 791) для уникальных адресов определила двухуровневую структуру, объединяющую в себе адрес сети и номер устройства в ней. Разделение адреса на 2 части имело большой 426 практический смысл, ибо позволяло маршрутизаторам существенно сократить размер своих таблиц, формируя их на основании адресов сетей. Для адресации сетей различного масштаба была построена иерархия их классов, отличающихся размерами полей, отводимых для задания адресов сетей и устройств (рис. 8.3). Классы A, B и C представляют индивидуальные адреса. Все групповые адреса вошли в класс D. Вне зависимости от класса, размер поля полного адреса всегда равен 32 битам. 8 31 Адрес сети 16 8 31 Адрес сети 1 0 Класс А Номер устройства 31 24 Номер устройства Класс C Адрес сети 1 1 0 Класс B Номер устройства Класс D Адрес группы 1 1 1 0 Рисунок 8.3. Классовая архитектура адресов IPv4 Для упрощения восприятия IP-адреса обычно записываются в форме четырёх трехразрядных десятичных целых чисел, разделяемых точкой. Каждое из этих десятичных чисел представляет соответствующий байт адреса. Так, например, адрес 10000000 10000111 01000100 00000101 в десятичном представлении имеет вид 128.135.68.5 и он является полным адресом устройства. Поскольку первые два бита этого адреса равны 10, то, как видно из рис. 8.3, устройство принадлежит сети класса B, его левые 16 бит задают адрес сети (128.135.0.0), а правые 16 бит – определяют номер интерфейса устройства в этой сети (17 413). Заметим, что иногда для формата «десятичный с точками» в IPv4 допускается сокращенная запись, при указании адресов как входных параметров каких-то прикладных утилит. Наиболее известный, а возможно, и единственный случай таких «вольностей» сокращает запись адреса 10.0.0.1 до 10.1, а 192.168.0.1 до 192.168.1. Однако все подобные 427 расширения адресной нотации IPv4 являются нестандартными и зависят от реализации. Некоторые адреса являются зарезервированными и не могут присваиваться сетевым устройствам. Так, адрес 127.х.х.y (х, y – любые числа, обычно x = 0, y = 1) является адресом приёмного модуля IP-протокола для пакета, сформированного передающим IP модулем этого же узла (адрес обратной связи); он используется при тестировании на одной станции взаимодействия сетевых процессов. Когда приложение использует этот адрес в качестве адреса назначения, модуль IP узла копирует данные из своего передающего буфера в приемный и не передает пакет физическому интерфейсу. Другим зарезервированным адресом является, так называемый, широковещательный адрес, содержащий 1 во всех битах определённой части адреса. Так, пакет с адресом назначения 255.255.255.255 будет доставлен всем устройствам сети, к которой принадлежит узел-отправитель; маршрутизаторы пакеты с такими адресами в другие сети не передают. Существует и направленное широковещание, при котором один пакет, отосланный в определенную сеть, будет доставлен всем её узлам. Такой пакет должен содержать корректный адрес сети и иметь все единичные биты в узловой части адреса. Так, например, пакет с адресом 184.90.255.255 будет доставлен всем станциям сети класса В 184.90.0.0. Из рис. 8.3. хорошо видно, что значения первых четырёх бит адреса однозначно определяют границы его сетевой части. Нетрудно сосчитать, что максимальное число сетей класса А равно 26 + 25 + ··· +20 – 1=126 (адрес сети, состоящий из одних нулей, недопустим). Каждая сеть класса А может содержать 224 - 2 = 16 777 214 устройств (вычитание двух адресов учитывает адрес самой сети и её широковещательный адрес). В целом, адресный блок сетей класса А занимает около 50% общего адресного пространства. Таблица 8.1. содержит аналогичные показатели для сетей класса B и C. 428 Таблица 8.1 Класс сети Значения сетевых байтов адреса Количество сетей А В С D 001.x.x.x – 126. x.x.x 128.0. x.x – 191.254. x.x 192.0.0.x – 223.255.254.x 224.0.0.0 – 239.255.255.255 126 16 384 2 097 152 - Количество узлов в сети 16 777 214 65 534 254 - Удельный вес класса (%) 50 25 12,5 - Для обеспечения уникальности назначаемых сетевых адресов их распределение производится специальными взаимосвязанными центрами, которыми руководит профильная организация Интернет - Internet Assigned Numbers Authority (IANA). IANA делегирует часть своих полномочия по распределению адресов региональным регистраторам (Regional Internet Registry, RIR), выделяя им определенные группы сетей. Региональные регистраторы, в свою очередь, выделяют более мелкие диапазоны адресных пространств локальным регистратурам (Local Internet Registry, LIR), которые и обеспечивают запросы конечных пользователей (провайдеров услуг и организаций). Подсети Рассмотренная выше двухуровневая схема адресации оказалась недостаточно гибкой в части как расходования адресного пространства, так и в части группировки сетей в логические подмножества. Для устранения этих недостатков в 1985 году была определена трехуровневая схема адресации (RFC 950). Необходимость перехода к ней можно проиллюстрировать следующим примером. Организация получила сеть класса В, позволяющую адресовать 65534 узлов. Пока в сети работало относительно немного станций, она функционировала благополучно. Но с ростом их числа неизбежно растет и широковещательный трафик, поскольку этот тип пакетов активно используется в служебных целях многими протоколами. Это обстоятельство неизбежно снижает эффективную производительность сети. Кроме того, управление несколькими десятками тысяч подключений из 429 единого административного центра является очень трудной задачей. К этим проблемам следует добавить и то, что развитие любой организации сопровождается ростом самостоятельности ее подразделений, в том числе и в части управления сетевыми подключениями. Возможность структурирования сети организации за счет получения множества классовых сетей была быстро исчерпана, и нехватка адресного пространства стала реальностью еще во второй половине 80-х годов. Кроме того, рост числа используемых малых сетей (класса С) вел к росту таблиц маршрутизации магистральных маршрутизаторов и, следовательно, к снижению их производительности. В значительной степени эти сложности были преодолены введением в иерархию адресации третьего уровня. Этот уровень, получивший название «уровень подсети», был выделен в узловой части адреса (рис. 8.4). Поля адреса сети и адреса подсети в совокупности получили название расширенного сетевого префикса. Расширенный сетевой префикс 1 0 Адрес сети Номер подсети Номер узла Рисунок 8.4. Трехуровневая схема адресации Выделение, например, в пространстве адресов узлов сети класса B шестибитного поля адреса подсети позволяет организовать 62 подсети, содержащих по 1022 адреса каждая. Такое разбиение классовой сети на подсети не требует согласования со структурами IANA и выполняется администратором сети самостоятельно. Отрицательным следствием введения уровня подсетей стало усложнение процедуры определения границы расширенного сетевого префикса. Действительно, при двухуровневой системе адресации на основании анализа четырех старших бит адреса легко определяется класс сети и граница между битами адреса сети и адреса узла. В трехуровневой системе адресации этот прием не работает. Для определения адреса подсети 430 и адреса узла потребовалось ввести сетевую маску – дополнительный 32-битный адрес, в котором биты, соответствующие битам расширенного сетевого префикса, устанавливаются в 1, а биты, соответствующие битам адреса узла – в 0 (рис.8.5). 16 8 1 1 111111 11111111 111111 00 00000000 Адрес сети 1 0 31 Номер подсети Номер узла Расширенный сетевой префикс Рисунок 8.5. Сетевая маска и сетевой адрес в 3-уровневой иерархии Так, например, пусть в сети класса В 132.10.0.0 необходимо сформировать подсети, самая большая из которых содержит не более 100 узлов. Для адресации такого числа сетевых устройств достаточно располагать 7 битами (27 = 128), которые и отводятся в нижней части битового пространства поля адреса. Оставшиеся 9 бит из «узлового» диапазона классовой адресации, будут использованы для задания номера подсети (их можно организовать 29 – 2 = 510). Старшие 16 бит, как и в двухуровневой иерархии, адресуют сеть. Таким образом, подсеть 132.10.12.128, в которой находятся хосты с адресами: 132.10.12.129, 132.10.12.130, ..., 132.10.12.254, будет иметь маску вида 11111111 11111111 11111111 10000000 (255.255.255.128). Если маршрутизатор получит пакет с адресом назначения 132.10.12.176, в двоичной нотации имеющий вид 10000100 00001010 00001100 10110000, и ему будет известна маска сети назначения (255.255.255.128), то выполнение в отношении адреса и сетевой маски операции логического И даст расширенный сетевой префикс (адрес подсети). В данном случае результат этой операции имеет вид: 10000100 00001010 00001100 10000000 = 132.10.12.128 431 Таким образом, в таблицах маршрутизации кроме адресов подсетей необходимо указание и их масок. В документах, описывающих современные протоколы маршрутизации, часто делается ссылка на длину расширенного сетевого префикса, а не на маску подсети. В такой нотации сетевой адрес устройства в рассмотренном выше примере имеет вид 132.10.12.176/25. Заметим, что ни маска, ни длина расширенного сетевого префикса подсети IP-пакетом не переносится (узел-источник о структуре сети, в которой находится получатель, ничего не знает). Передача информации о сетях (подсетях) является задачей протоколов маршрутизации; последние получают эту информацию из конфигурации интерфейсов узлов. Очевидно, что необходимость кроме адреса сети передавать и её маску ведет к росту объема служебного трафика протоколов маршрутизации. В качестве примера нумерации подсетей в таблице 8.2. приведено разбиение сети класса С на подсети (). Указанное в таблице число узлов в каждой из подсетей на два меньше полного числа адресов в соответствующем диапазоне, поскольку адреса, в которых все биты поля адреса узла установлены в ноль и в единицу, являются зарезервированными и используются как адрес подсети и ее широковещательный адрес, соответственно. Так, при подсетях, приведенных в таблице 8.2, адрес во второй строке 193.10.1.0 является адресом подсети 193.10.1.0/26, а не всей сети класса С 193.10.1.0. Аналогично, адрес 193.10.1.255 является широковещательным только для подсети 193.10.1.192/26. Таблица 8.2 Сети Исходная сеть Подсеть 1 Подсеть 2 Подсеть 3 Подсеть 4 Адрес 193.10.1.0 193.10.1.0 193.10.1.64 193.10.1.128 193.10.1.192 Способы задания подсети Маска Адрес/длина с.п. 255.255.255.0 193.10.1.0/24 255.255.255. 192 193.10.1.0/26 255.255.255. 192 193.10.1.64/26 255.255.255. 192 193.10.1.128/26 255.255.255. 192 193.10.1.192/26 Аббревиатура «с.п.» – сокращение от «сетевой префикс». 432 Адресов в подсети 254 62 62 62 62 Исходным документом о подсетях (RFC 950) предусматривалось, что «классовая» сеть может быть разделена на подсети фиксированного размера (подсети с общей маской). Однако, это существенно ограничивало возможность рационального использования адресного пространства. Поэтому, дальнейшим развитием трехуровневой модели адресации стала концепция масок переменной длины (Variable Length Subnet Mask, VLSM) и отказ от классовой архитектуры адресного пространства (RFC 1878, 1995). Исключение необходимости в использовании крайних левых битов для определения класса сети дало дополнительно 33.5 млн. адресов, а маски переменной длины придали максимальную гибкость в организации сетей, поскольку любая из них может содержать 2n адресов ( 0  n  31 ). В таблице 8.3 представлены возможные варианты их выделения. Таким образом, применением технологии VLSM привело к двухуровневой адресной иерархия с любым распределением числа бит (в пределах [1–31]), отводимых для представления сетевого префикса и номер хоста. Таблица 8.3 Длина сетевого префикса 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Количество адресов Маска сети 2 147 483 648 128.0.0.0 1 073 741 824 192.0.0.0 536 870 912 224.0.0.0 268 435 456 240.0.0.0 134 217 728 248.0.0.0 67 108 864 252.0.0.0 33 554 432 254.0.0.0 16 777 216 255.0.0.0 8 388 608 255.128.0.0 4 194 304 255.192.0.0 2 097 152 255.224.0.0 1 048 576 255.240.0.0 524 288 255.248.0.0 262 144 255.252.0.0 131 072 255.254.0.0 65 536 255.255.0.0 32 768 255.255.128.0 16 384 255.255.192.0 8 192 255.255.224.0 4 096 255.255.240.0 433 Количество "классовых" сетей 128 A 64 A 32 A 16 A 8A 4A 2A 1 A (256 B) 128 B 64 B 32 B 16 B 8B 4B 2B 1 B (256 C) 128 C 64 C 32 C 16 C Длина сетевого префикса 21 22 23 24 25 26 27 28 29 30 31 Количество адресов Маска сети 2 048 1 024 512 256 128 64 32 16 8 4 2 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252 255.255.255.254 Количество "классовых" сетей 8C 4C 2C 1C 1/2 C 1/4 C 1/8 C 1/16 C 1/32 C 1/64 C 1/128 C Бесклассовая маршрутизация Использование масок переменной длины (VLSM) дало возможность разделения адресного пространства сети на подсети переменного размера. Это улучшило использование выделенного адресного пространства, повысило гибкость формирования сетевой инфраструктуры, но не решило (даже усугубило) проблему размера таблиц магистральных маршрутизаторов (подсети увеличили число адресуемых объектов). В 1993 году была предложена технология бесклассовой маршрутизации (Classless Inter-Domain Routing, CIDR). Она базируется на использовании масок переменной длины, но уже не для разбиения сетей на подсети, а для объединения их в бесклассовые блоки (суперсети). По сути, CIDR – это констатация необходимости выделять сети непрерывными блоками в соответствии с каким-то административным или географическим принципом; такое выделение сетей создаёт возможность последующего «суммирования» записей о них в таблицах маршрутизаторов. Рассмотрим пример. Документ RFC 1466 рекомендует выделять Европейским потребителям адреса сетей класса С из диапазона 194.0.0.0 - 195.255.255.255. В него входят более 131 000 сетей класса С и все их адреса имеют одинаковые 7 старших бит. Следовательно, в таблицах маршрутизаторов неевропейских узлов обмена трафиком все эти сети могут быть представлены единственным префиксом 194.0.0.0/7. Дальнейшая 434 последовательность битов в адресе (это биты, следующие за 194 или 195), в свою очередь, может быть распределена в иерархическом порядке по отдельным странам Европы или по крупным сетевым операторам. Это позволяет в таблицах европейских узлов маршрутизации объединять записи маршрутов к региональным сетям с использованием масок, длиной 8, 9, …20 и т.д. бит. Такая группировка записей к большому массиву сетей не препятствует заданию в таблицах маршрутизации альтернативных путей к какой-то её части, поскольку при выборе маршрута используется принцип «лучшее совпадение – это наиболее длинное совпадение» (longest match). Это означает, что из нескольких записей, удовлетворяющих условию совпадения битов сетевого префикса с битами адреса назначения, выбирается та, у которой это совпадение более длинное. Предположим, что сети одного из европейских провайдеров (пусть провайдер Z) подключены к магистрали Интернет иначе, чем все остальные европейские сети. Провайдеру Z принадлежат 16 сетей класса С, адреса которых образуют непрерывный блок 194.0.16.0 - 194.0.31.0. Запись в таблицах маршрутизаторов для этой группы сетей имеет вид: 194.0.16.0/20 (маска 255.255.240.0). Адрес назначения 194.0.22.1 конкретного пакета в пределах первых 20 бит совпадает с адресом блока сетей провайдера Z и, в пределах первых 7 бит с адресом блока, определенного записью (194.0.0.0, 254.0.0.0), представляющей маршрут ко всем сетям Европы (в том числе, возможно, он может привести и к сетям провайдера Z). Однако, так как адрес пакета совпадает с записью, 194.0.16.0/20 в большем числе бит, чем с записью 194.0.16.0/7, то будет использован индивидуальный маршрут к блоку сетей провайдера Z. Введение подсетей, позволив рационализировать использование адресного пространства, потребовало определенного усложнения протоколов маршрутизации, которые должны переносить не только адрес сети (подсети), но и её маску. 435 8.2.2. Структура IP-пакета Функции IP-протокола реализуются посредством заголовка пакета, формат которого приведен на рис. 8.6. Заголовок содержит поля фиксированного размера (первые 20 байт) и два поля переменной длины: поле «Опции», размер которого может достигать 40 байт, и поле «Выравнивание» (Padding), которое дополняет нулями поле «Опции» до величины, кратной 32 битам. Рассмотрим назначение полей заголовка. 8 4 Версия IHL 31 16 Тип сервиса Полный размер пакета Идентификатор Время жизни Флаги Протокол Смещение фрагмента Контрольная сумма Адрес отправителя Адрес получателя Опции (не более 40 Байт) Выравнивание Рисунок 8.6. Формат заголовка IP-пакета Версия (Version): поле содержит номер версии протокола, указывающей правила, по которым следует интерпретировать структуру заголовка и смысл значений отдельных его полей. Пакеты, заголовок которых имеет несогласующуюся с протокольным модулем узла версию, отбрасываются. Размер заголовка (Internet Header Length, IHL): поле содержит размер заголовка в 32-битных словах. Корректный заголовок имеет длину не менее 20 байт (5 слов). Размер поля опций (в 32-разрядных словах) может быть определен как значение этого поля минус 5. Тип сервиса (Type of service, ToS): В ранних (до 1998 г.) версиях протокола это поле определяло приоритет обслуживания пакета и одну, предпочтительную, характеристику качества доставки. Первые три бита (0, 1, 2) поля задают уровень приоритета (0 – 7); 3 – 5 биты определяют желательную характеристику качества доставки, а именно: минимальную сетевую задержку (третий бит), максимальную пропускную способность пути (четвертый бит) и минимальный уровень потерь (пятый бит); 6 –7 биты не использовались. Механизмом приоритетной обработки пакетов являются 436 приоритетные очереди, создающиеся на маршрутизаторе; механизм же удовлетворения указанных классов качества доставки в явном виде не был определён. В принципе, эти «пожелания» могут удовлетворяться при наличии таблиц метрикам маршрутизации, (минимум задержки, построенных максимум по соответствующим пропускной способности, минимума потерь). Очевидно, что построение и поддержание актуальности нескольких таблиц маршрутизации требует значительных вычислительных ресурсов узла, увеличивает служебный трафик в сети и сопряжено со значительными трудностями в вычислении таких метрик. Маршрутизаторы в IP сетях часто не располагают требуемыми ресурсами и механизмами, да и выполнение требований качества доставки выходит за пределы сервиса «как получится». Поэтому, информация, содержащаяся в 3 – 5 битах этого поля, часто игнорируется. В процессе развития IP-сетей были разработаны несколько моделей поддержки в них требований качества обслуживания и все модели используют поле TOS. Но семантика его заметно различна. В частности, в модели дифференцированного сервиса первые 6 бит поля задают класс сервиса доставки (Differentiated Services Code Point, DSCP; RFC 2474, 2475, 2597). Отметим, что 3 старших бита кода DSCP непосредственно отражаются в биты приоритета, чем достигается совместимость кодов данной модели сервиса с уровнями приоритетного обслуживания, определённого предшествующими моделями сервиса. Значение поля ToS задаётся приложением узла-источника, но оно может быть переопределено граничным маршрутизатором транзитной сети в соответствии с определённой в ней политикой и возможностями обеспечения качества обслуживания. По сути, значение этого поля является результатом применения правил классификации пакетов, заданных на граничных маршрутизаторах транзитных сетей. С целью унификации трактовок кодирования классов обслуживания инженерная группа Интернет разработала рекомендации, в которых определены 23 типа обслуживания. 437 Механизмом реализации моделей дифференцированного обслуживания служат дисциплины обслуживания очередей. Наиболее гибкими в отношении QoS являются Class-Based Weighted Fair Queuing (CBWFQ) и Priority-Based Deficit Weighted Round Robin. Биты 6 и 7 в модели DSCP также не используются. В современной трактовке протокола IP (RFC 3168, 2001) они реализуют функцию управления потоком (Explicit Congestion Notification, ECN). Бит 6 устанавливается отправителем для индикации его способности реагировать на сигналы ECN (бит ECN). Бит 7 является собственно сигналом перегрузки (СЕ-бит, Congestion Experienced); он устанавливается маршрутизатором, если при обработке конкретного пакета размер его очереди достигает порогового значения. Поскольку IP протокол не располагает механизмами управления интенсивностью потока, то этот сигнал должен обрабатываться протоколом транспортного уровня. Полный размер (Total length): поле содержит общий размер пакета, величина которого не может превышать 65535 байт. Практически, пакеты такой величины никогда не передаются, поскольку технологии канального уровня, в абсолютном большинстве своем не выполняющие фрагментацию, накладывают свои ограничения на размер принимаемых блоков данных. Так, Ethernet не допускает кадров больше 1518 байт, FDDI – 4096 байт и т. д. Максимальная величина поля данных кадра (Maximim Transmission Unit, MTU) является параметром технологии канального уровня и, следовательно, может отличаться на разных сетевых интерфейсах даже одного устройства. В соответствии с MTU интерфейса, через который пакет должен быть отправлен на следующий узел, модуль IP выполняет фрагментацию поступающих к нему сегментов. В RFC 791 было установлено, что IP- протокол должен доставлять без фрагментации пакеты, размер которых не превышает 576 байт (с передачей таких пакетов «справляется» любая канальная технология). Следует отметить, что маршрутизатор не выполняет объединение пакетов, даже если MTU выходного интерфейса допускает 438 кадры такого размера. Сборка фрагментированных пакетов производится станцией назначения. Поля «Идентификатор», «Флаги» и «Смещение фрагмента» управляют процессом сборки фрагментированного пакета. Идентификатор (порядковый номер пакета) назначается узлом-источником (отправителем пакета); он остается неизменным на всем пути пакета и при фрагментации устанавливается одинаковым у всех его частей. Флаг «Don’t Fragment» - это запрещение фрагментации пакета узлами его обработки, а флаг «More Fragment» свидетельствует о наличии других фрагментов данного пакета; в последнем фрагменте этот флаг устанавливается в 0. Заметим, что размер фрагментов (без IP заголовков) должен быть кратен 8 байтам для всех фрагментов, кроме последнего. Поэтому и значение смещения задается в 8-байтовых словах; оно указывает положение поля данных текущего фрагмента в поле данных исходного (нефрагментированного) пакета. Применение всех этих полей иллюстрирует рис.8.7. Пакет 1 Total Length 2700 байт Пакет 1/1 Flags Offset ID Total Length 1500 0xD57D 0 0 1 (0 – 1479) Flags Offset ID Total Length 1220 0xD57D 0 0 0 1480 (1480 – 2679) Data ID 0xD57D Flags Offset 000 Data 2680 (0 – 2679) Data Пакет 1/2 MTU вых. интерфейса 1500 байт Рисунок 8.7. Связь полей заголовков фрагментируемого пакета и пакетов–фрагментов Время жизни (Time to live, TTL): поле ограничивает время, которое пакет может существовать в сети. Его наличие помогает избежать длительных перегрузок сети при возникновении ошибок маршруизации, приводящих к образованию путевых петель. Значение этого поля устанавливается при 439 отправке пакета и уменьшается на единицу по мере прохождения им каждого маршрутизатора (конечные узлы значение этого поля не проверяют и не уменьшают). При достижении нулевого значения этого поля пакет уничтожается. Максимальное значение TTL – 255. Начальное же его значение определяется операционной системой отправителя (Lunix – 64, Win10 – 128, WinXP – 255). Протокол (Protocol): поле указывает модулю какого протокола (TCP, ICMP, OSPF,…) следует передать данные, содержащиеся в полученном IP-пакете. Ниже приведены значения этого поля для некоторых протоколов. Таблица 8.4 Значение поля 1 4 6 17 89 Ключевое слово Reserved ICMP IP TCP UDP OSPF Протокол Зарезервировано Internet Control Message Protocol Internet Protocol Transmission Control Protocol User Datagram Protocol Open Shortest Path First Обратим внимание на относительно малый размер поля (всего 1 байт) и присущие только IP протоколу значения кодов. Контрольная сумма (Header checksum): поле содержит значение контрольной суммы, рассчитанной только по заголовку. Значения некоторых полей заголовка пакета изменяются по мере его прохождения по маршруту (TTL, например), следовательно, значение контрольной суммы пересчитываются на каждом маршрутизаторе. Этот механизм является единственным средством обеспечения достоверности передачи, содержащимся в протоколе IP. Адрес отправителя (Source IP address) и адрес получателя (Destination IP address): поля (32 бита), содержащие соответствующие адреса. Опции (Options): необязательное поле, используемое для запроса и реализации определенных специфических процедур обработки пакета. Максимальный размер составляет 40 байт. Обработка этого поля пакета 440 обязательна для всех узлов. Обобщённая структура задания отдельных опций представлена на рис. 8.8. Размер опциональных полей переменный, поэтому в заголовке каждой опции наряду с её типом и значением предусматривается поле «Размер». Формат задания опций Тип 1 байт Копия 1 бит Размер 1 байт Значение N байт Код опции 5 бит Класс 2 бита 0 – Дейтограмма пользователя или сетевое управление 2 – Диагностика Рисунок 8.8. Структура задания опций IP пакета Всего документом RFC 791 были определены восемь опций; в настоящее время их уже почти три десятка, но широкое применение нашли не многие их них. В частности, используются опции задающие обязательный маршрут пакета от источника, записывающие реализуемый маршрут (трассировка), фиксирующие временные метки обработки пакета узлом. 8.2.3. Разрешение IP-адресов в физические адреса сетевых интерфейсов На каждом участке пути пакет передаётся от одного сетевого узла к непосредственно с ним связанному соседнему узлу. Эту услугу предоставляет канальный протокол сети, управляющий передачей кадров между интерфейсами смежных маршрутизаторов. Канальные же протоколы «умеют» доставлять кадры только по физическим адресам интерфейсов. Задачу установления соответствия логического сетевого адреса и физического адреса интерфейса решает протокол ARP (Address Resolution Protocol). Идея его функционирования иллюстрируется рис. 8.9. Пусть канальный протокол узла Н1 получил от своего сетевого протокола пакет, который необходимо переслать хосту Н3, MAC-адрес 441 которого узлу Н1 не известен. Канальный протокол узла Н1 обращается к модулю протокола ARP с поручением установить МАС адрес узла, имеющего заданный IP адрес. ARP протокол генерирует сообщение–запрос, в котором указывает IP-адрес узла Н3. Этот запрос помещается в поле данных МАС-кадра с широковещательным адресом назначения и значением кода ARP (0x0806) в поле «Протокол». 149.100.1.151 Н1 149.100.1.153 Н2 Н3 Н4 149.100.1.152 149.100.1.154 ARP-запрос: «Какой МАС-адрес у станции 149.100.1.153?» 149.100.1.151 Н1 149.100.1.153 Н2 Н3 Н4 ARP-ответ: «МАС-адрес станции 149.100.1.153: 10-7b-ed-5f-d9-11» Рисунок 8.9. ARP процедура определение MAC-адреса узла Каждый узел локальной сети, получив такой кадр, сравнивает указанный в нем IP-адрес со своим сетевым адресом. Узел H3 обнаружит их совпадение и его модуль ARP сформирует сообщение-ответ, содержащий его физический адрес. Это сообщение будет отправлено станции H1 в кадре с индивидуальным адресом назначения и значением кода ARP (0x0806) в поле «Протокол». Все остальные станции локальной сети, получив кадр, содержащие ARP-запрос о «чужом» IP-адресе, прежде чем удалить его, проверят наличие в своих ARP-таблицах (см. ниже) записи с IP- и MAC-адресом станции H1: при её отсутствии – добавят, а при наличии, но с другим MAC-адресом, – откорректируют такую запись. Для уменьшения количество передаваемых в сети ARP–запросов, каждое сетевое пополняется узел каждый ведёт раз, специальную когда хост ARP–таблицу. получает Последняя ARP–ответ, или широковещательный ARP–запрос, в котором указаны сетевой и физический адреса станции-отправителя, о которой в его таблице нет данных. В 442 ARP-таблице могут быть как статические, так и динамические записи. Статические записи добавляются администратором и сохраняются в таблице до перезагрузки устройства. В таблице также всегда содержится широковещательный адрес (FF:FF:FF:FF:FF:FF), который соотносится с широковещательным IP-адресом сети, в которую входит данный узел. Ниже приведен фрагмент ARP-таблицы маршрутизатора с двумя сетевыми интерфейсами. Таблица 8.5 IP-address Port Type Media Address Address Source 20.0.0.15 2 Broadcast FF:FF:FF:FF:FF:FF Static 10.0.0.15 1 Broadcast FF:FF:FF:FF:FF:FF Static 10.0.0.10 1 Local 08:00:02:14:5D:E6 Static 20.0.0.10 2 Local 08:00:02:14:5D:E5 Static 10.0.0.1 1 External 08:00:02:A5:6B:C0 ARP 20.0.0.1 2 External 08:00:02:A7:19:DD ARP Динамические записи добавляются и удаляются программно. Каждая такая запись имеет потенциальное время жизни. После её добавления в таблицу включается специальный таймер и, если в течение первых двух минут запись не используется (соответствующий узел не отправлял и не получал кадры, содержащие указанный MAC-адрес), то запись удаляется; в противном случае, время жизни такой записи составляет некое предустановленную величину (обычно 5 - 10 минут). Требования к хостам (Host Requirements, RFC 1122) говорит, что запись из ARP-таблицы должна удаляться по тайм-ауту, даже если она используется, однако большинство реализаций протокола не делают этого – они обновляют значения времени жизни записи каждый раз, когда происходит обращение к ней. Протокол ARP достаточно универсален, и его можно применять в сетях различных технологий. ARP–сообщения имеют формат, представленный на рис. 8.10; они переносятся кадром канального протокола в его поле «Данные». В поле «Тип сети» указывается код канального протокола: Ethernet - 1, Frame Relay - 15, HDLC - 17, Fibre Channel - 18, 443 ATM - 19. Поле «Тип протокола» определяет протокол сетевого уровня: IPv4 - 0x0800 (совпадает с кодом IPv4 в заголовке Ethernet). Эти поля совместно с полями «Длина аппаратного адреса» и «Длина сетевого адреса» обеспечивают отмеченную выше универсальность протокола ARP. В поле «Тип операции» для ARP-запроса указывается 1, для ARP-ответа – 2. 8 16 31 Тип сети Тип протокола Размер апп. адреса Размер сет. адреса Тип операции Аппаратный адрес отправителя Аппаратный адрес отправителя Сетевой адрес отправителя Сетевой адрес отправителя Аппаратный адрес получателя Аппаратный адрес получателя Сетевой адрес получателя Рисунок 8.10. Формат ARP-сообщения Устройство, отправляющее ARP запрос, заполняет в сообщении все поля, кроме искомого аппаратного адреса. Значение этого поля заполняется в ARP-ответе узлом, опознавшим свой IP-адрес в поле «Сетевой адрес получателя» запроса. Протокол ARP не содержит средств аутентификации своих сообщений, не контролирует он и связность пар «запрос-ответ». Эти его свойства могут использоваться для преднамеренного искажения содержания ARP-таблицы маршрутизатора посредством отправки ему поддельного ARP-ответа от станции-нарушителя, заменившей в нём свой IP-адрес в поле «Сетевой адрес отправителя» на IP-адрес станции-жертвы, но указав свой MAC-адрес в поле «Аппаратный адрес отправителя». Напомним, что в соответствии с требованиями RFC 1122, узел ОБЯЗАН обновить свою ARP-таблицу при получении любого ARP–сообщения, содержащего сведения, отличающиеся от уже имеющихся в ней. Это создаёт условия для перенаправления трафика, адресуемого маршрутизатором узлу-жертве, на узел злоумышленника. 444 В заключение отметим, что протокол ARP применим только в сетях, поддерживающих канальное широковещание. Если канальная технология сети его не поддерживает, то функции ARP выполняют специальные серверы; могут использоваться и алгоритмические отражения сетевых адресов в аппаратные адреса. Протокол ARP решает задачу в отношении индивидуальных IP адресов, а для пакетов с групповыми адресами получателей используется другой механизм. Групповые IP-адреса назначаются узлу либо административно, либо автоматически в ходе процедуры присоединения его к группе (выполняется по запросу приложения на станции). При этом, IP-адрес группы отражается в ещё один аппаратный адрес узла по следующим правилам. Три его старших байта такого MAC–адреса всегда равны 01-00-5Е. В остающиеся 24 младших бита записываются 23 младших бита IP-адреса, а 24-й бит устанавливается в 0. Полученная пара «групповой IP-адрес, групповой МАС-адрес» заносится в ARP-таблицу (пример в таблице 8.6). Таблица 8.6 IP-адрес МАС-адрес Тип записи Принадлежность МАС-адреса 192.168.1.1 10-7b-ef-5a-d9-14 динамическая Маршрутизатор сети 192.168.1.0/24 192.168.1.74 00-1f-c6-0c-db-56 динамическая Узел сети 192.168.1.0/24 192.168.1.255 ff-ff-ff-ff-ff-ff статическая 224.0.0.2 01-00-5e-00-00-02 статическая 224.0.0.22 01-00-5e-00-00-16 статическая 224.0.0.5 01-00-5e-00-00-05 статическая Все OSPF маршрутизаторы 255.255.255.255 ff-ff-ff-ff-ff-ff статическая Широковещание в пределах сети данного узла Направленное широковещание в сети 192.168.1.0/24 Все маршрутизаторы группового трафика в подсети узла-отправителя IGRPv3 – протокол управления группами Очевидно, что описанный алгоритм отражает IP-адреса 32 групп в один групповой МАС адрес. Как следствие, станция может принимать кадры, 445 несущие пакеты тридцати одной не интересной ей группы. Это необходимо учитывать при назначении IP адресов источникам многоадресной рассылки. 8.2.4. ICMP - протокол управляющих сообщений Функцию передачи специальных управляющих и диагностирующих сообщений в сетях TCP/IP выполняет Internet Control Message Protocol (ICMP), описание которого дано в документе RFC 792. По выполняемым функциям ICMP является протоколом сетевого уровня; он не использует сервис транспортного уровня, а его сообщения инкапсулируются в IP-пакеты. Диагностические сообщения ICMP генерируются сетевыми узлами при обнаружении ими отклонений от предусмотренного штатного режима обработки пакетов. Однако, протокол не содержит никаких средств коррекции состояния узла, его задача – сформировать и доставить сигнал обратной связи. Единственным получателем такого сообщения является узел-источник обрабатываемого пакета. Эти сообщения не используются и для информирования промежуточных узлов, поскольку маршрут передачи IP-пакета c ICMP-сообщением может отличаться от маршрута пакета, при обработке которого возникли проблемы; следовательно, ценность этой информации для промежуточных узлов обратного маршрута не гарантирована. Управляющие сообщения ICMP имеют характер предписания определённых действий, которые должен выполнить модуль IP. Сообщения ICMP содержат три обязательных поля: «Тип», «Код» и «Контрольная сумма». Кроме этого, многие сообщений об ошибках включают в своё поле данных заголовок и первые 64 бита поля данных IP-пакета, при обработке которого ошибка возникла. Это сделано для более точной идентификации узлом-отправителем причины ошибки. Тип сообщения отражает его содержание и определяет дополнительные поля сообщения. В таблице 8.7. приведены примеры некоторых типов сообщений. 446 Таблица 8.7 Содержание сообщения Ответ на эхо Получатель недостижим Подавление источника Изменение маршрута Запрос эха Тип 3 4 5 8 Тип 11 12 13-14 17 18 Содержание сообщения Превышено время жизни пакета Ошибка параметров в пакете Запрос/Ответ метки времени Запрос маски адреса Ответ на запрос маски адреса Сообщения «Запрос эха» и «Ответ на эхо» используются для комплексной проверки работоспособности физических, канальных и сетевых компонент стека устройств, формирующих путь до целевого узла. Поскольку они передаются в то IP-пакетах, успешный прием ответа на соответствующий запрос свидетельствует о работоспособности сетевой транспортной системы. На рис. 8.11. представлен формат этих сообщений. 8 Тип=8 или 0 31 16 Код = 0 Контрольная сумма Идентификатор Порядковый номер Необязательные данные Рисунок 8.11. Формат сообщений «Запрос эха» и «Ответ на эхо» Поля «Идентификатор» и «Порядковый номер» используются отправителем для установления соответствия между запросом и ответом. В unix-системах поле «Идентификатор» содержит системный идентификатор процесса, отправляющего запрос. Значения в поле «Порядковый номер» начинаются с 0 и увеличиваются на единицу каждый раз, когда соответствующий процесс посылает следующий запрос. Значение этих полей копируются в одноименные поля сообщения-ответа, что позволяет установить его связь с запросом и определить как время полного оборота (RTT) на маршруте, так и потерю какого-либо из запросов. В приложениях для Windows поле «Идентификатор» содержит постоянное значение, которое может изменяться в зависимости от версии ОС (в Win10 оно равно 0x00-01). Поле «Порядковый номер» в каждом запросе и вне зависимости от генерирующих их приложений изменяется на единицу; начальное значение 447 этой нумерующей последовательности устанавливается только при перезагрузке системы. Эти соглашения позволяют ICMP-модулю верно сопоставлять пары «запрос, ответ» в условиях, когда на одном и том же узле одновременно выполняются несколько разных приложений (или несколько экземпляров одного приложения), порождающих ICMP-запросы. Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю. Сообщение «Получатель недостижим» (Тип = 3) генерируется маршрутизатором в ситуации, когда он не может доставить пакет по назначению. Формат сообщения представлен на рис. 8.12. Это сообщение содержит поле «Код», которое уточняет причину невозможности доставки пакета. Некоторые из кодов представлены в таблице 8.8. 8 Тип = 3 31 16 Код (0 – 12) Контрольная сумма Не используется (должно быть 0) Next-hop MTU Заголовок IP-пакета и первые 64 бита его поля данных Рисунок 8.12. Формат сообщения «Получатель недостижим» Таблица 8.8 Код 1 2 3 4 5 6 9 Причина Сеть недостижима Устройство недостижимо Протокол неизвестен Порт недостижим Требуется фрагментация Ошибка при маршрутизации от источника Сеть назначения неизвестна Взаимодействие с сетью назначения административно запрещено Сообщение «Подавление источника» (Тип = 4) является сигналом обратной связи для механизма управления потоками. Его формат аналогичен формату сообщения типа 3, но значение поля «Код» в нем всегда равно 0. Сообщение отправляется маршрутизатором узлу-отправителю в ответ на каждый, полученный в состоянии перегрузки маршрутизатора, пакет. 448 Отправители этих пакетов, получая такие ICMP-сообщения, уменьшают интенсивность их генерации, что способствует устранению перегрузки. Сообщение маршрутизатором «Изменение маршрута» узлу-отправителю, (Тип = 5) находящемуся с отправляется ним в одной физической сети, для того, чтобы сообщить об использовании узлом неоптимального первого шага маршрута к узлу назначения. 8 Тип = 5 31 16 Код (0 – 3) Контрольная сумма IP-адрес маршрутизатора Заголовок IP-пакета и первые 64 бита его поля данных Рисунок 8.13. Формат сообщения «Изменение маршрута» В сообщении (рис. 8.13) указывается адрес маршрутизатора, также находящегося в этой локальной сети, но использование которого является предпочтительным. Из поля «Заголовок IP-пакета…» узел узнает, для какой сети/узла необходимо направлять пакеты указанному в сообщении маршрутизатору. Значения поля «Код» (0-3) уточняют условия применения рекомендуемого маршрута: 0 – для всей сети, 1 – для данного узла, 2 – для данной сети при заданном в IP-пакете требовании к обслуживанию, 3 - для данного узла при заданном в IP-пакете требовании к обслуживанию. Таким образом, начиная работу, отправитель может знать лишь один маршрут. В дальнейшем, его таблица маршрутизации посредством этих сообщений ICMP будет дополнена более точной информацией об оптимальных маршрутах. Сообщения «Превышено время жизни» (Тип = 11) посылается отправителю в двух ситуациях. При обнулении поля TTL в заголовке пакета (код = 0) и при превышении времени ожидания фрагмента при сборке пакета узлом назначения (код = 1). Сообщения «Запрос/Ответ метки времени» (Тип = 13/14, код = 0) используется для синхронизации таймеров узлов сети Интернет. Формат сообщений представлен на рис. 8.14. В 32-битных полях «Время ...» 449 записываются показания системных часов узлов, представленные в числе миллисекунд после полуночи по шкале универсального координированного времени (Coordinated Universal Time, UСT). 8 Тип = 13 (14) 31 16 Код =0 Контрольная сумма Идентификатор Порядковый номер Время отправления Время получения Время отправления ответа Рисунок 8.14. Формат сообщения «Запрос/ответ метки времени» «Время отправления» (Originate timestamp) – это время, которое отправитель фиксировал последний раз перед посылкой сообщения. «Время получения» (Receive timestamp) – это время, когда запрос «увидел» его получатель. Эти два поля копируются в сообщение-ответ и дополняются полем «Время отправки ответа» (Transmit timestamp) - это последний отсчёт времени, которое фиксировал компьютер, отправляющий ответное сообщение. Располагая этими тремя временными отсчетами и дополнив их временной меткой получения ответа, хост, инициировавший этот обмен, имеет возможность вычислить сетевую задержку ответа. Прибавив ее к метке «Время отправления ответа», узел получает текущее значение часов запрашиваемого хоста и может синхронизовать с ним свои часы. Использование данного метода синхронизации часов не может обеспечить высокую точность хотя бы потому, что задержки распространения сигналов в прямом и обратном направлении могут заметно отличаться. Для компенсации этого источника возможной погрешности должны быть использованы несколько обменов такими сообщениями. 8.2.5. Транспорт IP пакетов Каждый узел (станция, маршрутизатор) содержит маршрутные таблицы, которые и определяют передачу IP-пакетов с входного на выходной 450 интерфейсы. Каждая строка в таблице маршрутизации содержит, как минимум, следующую информацию:  IP-адрес сети назначения и её маску,  IP-адрес следующего маршрутизатора на пути в указанную сеть,  «стоимость» маршрута до целевой сети,  имя (идентификатор) выходного интерфейса. Также в таблице маршрутизации могут содержаться флаговые поля, уточняющие информацию о записи в таблице. Так, например, флаг H определяет маршрут к хосту; флаг G уточняет, что в строке записан маршрут к другому маршрутизатору. Поиск в таблице маршрутизации ведется, по строкам. Прежде всего, в записях первого столбца ищется запись, точно соответствующая адресу назначения пакета. Если такая запись обнаруживается, то пакет отправляется узлу, чей адрес указан в столбце «Следующий маршрутизатор». Если такая запись не обнаруживается, то ищется запись, максимально полно соответствующая адресу назначения пакета (по принципу наиболее длинного совпадения). Если адрес назначения не совпадает ни с одной из записей таблицы, то ищется строка, определяющая маршрут по умолчанию (адрес узла с более полной информацией о возможных межсетевых связях). В случае, когда ни один из перечисленных вариантов не реализуется, пакет уничтожается и узлу-отправителю отправляется ICMP-сообщение «Сеть недостижима». Передача пакетов между конечными станциями, требует взаимодействия IP-модулей станций и маршрутизаторов, обеспечивающих связность с внешними сетями. Если адрес назначения в пакете принадлежит IP-подсети, в которой находится отправитель, то пакет может быть доставлен адресату средствами канального протокола. Для этого МАС-модуль отправителя из своей ARP-таблицы извлекает физический адрес узла назначения, и кадр канального протокола с инкапсулированным в него IP-пакетом передается станции назначения. 451 В случае нахождения отправителя и станции назначения в разных IP-сетях, пакет средствами канального протокола отправляется по адресу маршрутизатора, который был указан в таблице маршрутизации отправителя в качестве адреса следующего узла в целевую сеть, или по адресу маршрутизатора, указанного в качестве шлюза по умолчанию (default gateway). Эти устройства обязательно имеют физический интерфейс в той же ЛС, что и отправитель. При получении пакета маршрутизатор проверяет совпадение адреса назначения пакета с собственным IP-адресом. Если это так, то пакет передается модулю протокола, указанного в поле «Протокол» заголовка пакета. В противном случае, маршрутизатор по своей таблице определяет адрес следующего узла, которому он должен передать этот пакет, и свой интерфейс, посредством которого он связан с этим узлом. В качестве примера, рассмотрим процедуру маршрутизации в сети, представленной на рис. 8.12. Она содержит три подсети: 149.100.1.0/25, 149.100.1.128/26 и 149.100.2.0/24, связанные двумя маршрутизаторами М1 и М2; последний является и шлюзом к внешним сетям. Адреса станций и интерфейсов маршрутизаторов показаны на рисунке. 149.100.1.158 149.100.1.159 С1 С2 149.100.2.20 149.100.2.21 С5 С6 149.100.1.128/26 149.100.1.129 149.100.1.14 149.100.1.13 С3 149.100.2.0/24 M1 149.100.2.1 M2 С4 149.100.1.1 149.100.1.2 149.100.0.2 149.100.0.1 Внешние сети 149.100.1.0/25 Рисунок 8.15. Пример объединенной IP-сети Предположим, что станция С6 сформировала пакет с адресом назначения 149.100.1.159. Таблица 8.9 в упрощённом виде представляет маршруты, известные узлу С6. 452 Таблица 8.9 Адрес назначения 127.0.0.0 0.0.0.0 149.100.2.0 Маска сети 255.0.0.0 0.0.0.0 255.255.255.0 Следующий узел 127.0.0.1 149.100.2.1 149.100.2.21 Флаг Н G Интерфейс Имя Адрес lo0 127.0.0.0 Eth0 149.100.2.21 Eth0 149.100.2.21 Первая строка таблицы определяет закольцовывающий интерфейс. Вторая строка описывает маршрут по умолчанию и флаг G уточняет, что адрес 149.100.2.1 принадлежит интерфейсу маршрутизатора. Третья запись таблицы не имеет флага Н, следовательно, она определяет сеть; нет в ней и флага G и это говорит о том, что определяется маршрут к непосредственно подключенной сети и интерфейсом к ней является интерфейс станции С 6, имеющий адрес 149.100.2.21. Станция С6 производит поиск в своей маршрутной таблице записи с адресом станции С2 или сети, к которой С2 принадлежит. Поскольку ни тот, ни другой в ней не представлены, то пакет отправляется маршрутом по умолчанию к узлу М2 с адресом 149.100.2.1 через интерфейс Eth0. Таблица маршрутизации М2 имеет следующий вид. Таблица 8.10 Адрес назначения Маска Следующий узел 127.0.0.0 0.0.0.0 149.100.2.0 149.100.1.0 149.100.1.128 255.0.0.0 0.0.0.0 255.255.255.0 255.255.255.128 255.255.255.192 127.0.0.1 149.100.0.2 149.100.2.1 149.100.1.2 149.100.1.1 Флаг Н G G Интерфейс имя адрес lo0 Serial 01 Eth0 Eth1 Eth1 149.100.0.1 149.100.2.1 149.100.1.2 149.100.1.2 Заметим, что для непосредственно присоединенных сетей адресом следующего узла всегда является адрес одного из интерфейсов маршрутизатора. Находящемуся в такой сети получателю обрабатывай пакет может быть доставлен посредством канального протокола и ARP-службы. Выполнив поиск в своей таблице маршрутизатор М2 найдет, что наиболее полно согласуется с адресом назначения маршрут, определенный в 453 строке 5; следовательно, пакет уйдет к маршрутизатору М1 через интерфейс Eth1. В таблице маршрутизации М1 (табл. 8.11) представлен маршрут к узлу, адрес которого точно соответствующим адресу назначения пакета. Поэтому последний передается на интерфейс Eth0 и доставляется станции С2. Таблица 8.11 Адрес назначения 0.0.0.0 149.100.2.0 149.100.1.0 149.100.1.159 149.100.1.128 Маска 0.0.0.0 255.255.255.0 255.255.255.192 255.255.255.255 255.255.255.192 Следующий узел 149.100.1.2 149.100.1.2 149.100.1.1 149.100.1.159 149.100.1.129 Флаг G G Н Интерфейс Eth1 Eth1 Eth1 Eth0 Eth0 8.2.6. Обобщенная схема обработки пакетов маршрутизатором Маршрутизатор можно рассматривать как межсетевой коммутатор, управляемый информацией о связях между логическими сущностями (парциальными сетями), входящими в объединенную сеть. При этом, он выполняет три основные функции: 1. расчёт оптимальных путей ко всем парциальным сетям, 2. определение адреса очередного узла на маршруте пакета и 3. коммутацию пакета с входного физического интерфейса на выходной. Выполнение первой из них требует получения информации о топологии объединённой сети, выбора метрики «стоимости» линий связи и построения минимального дерева на графе объединённой сети; всё перечисленное выполняют протоколы маршрутизации (RIP, OSPF, IS-IS...). Вторая функция предполагает наличие в оперативной памяти узла таблиц маршрутизации. Поиск строки с сетевым префиксом, наиболее полно совпадающим с адресом назначения пакета, даёт адрес следующего маршрутизатора и имя (адрес) выходного интерфейса. Именно в этом смысле, маршрутизатор – это коммутатор, управляемый информацией о связях логических компонент сети. Поиск «наилучшей» записи в таблице маршрутизации выполняется по следующему алгоритму. 1. Прочитать адрес назначения пакета. 2. i:=1; p[ ]:=0. 454 3. Прочитать маску сети из i-й записи таблицы маршрутизации. 4. Выполнить операцию логического «И» в отношении адреса назначения пакета и маски. 5. Определить длину (k) непрерывной последовательности старших бит результата операции п.4, совпадающих с соответствующими битами адреса назначения; записать p[i]:=k. 6. Если в таблице есть следующая i+1 запись, То i:= i+1 и перейти к п. 3; 7. Найти m  index max( p[i]  0 и передать пакет на указанный в строке  i  m интерфейс; 8. Если (все p[i]=0) И (default route задан), То отправить пакет на интерфейс, указанный в его описании, Иначе: 9. Уничтожить пакет и отправить ICMP сообщение «Получатель недостижим» узлу с адресом, указанным в поле «Source Address» обрабатываемого пакета. Третья функция – коммутация пакета с входной очереди в очередь выходного порта выполняется так же, как и коммутация канального кадра. Специфические для уровня межсетевого взаимодействия операции обработки IP-пакетов иллюстрируются информационной схемой на рис. 8.16. Обратим внимание на разрешение проблемы, которая может возникать при выполнении проверки «MTU < TotLenght». Маршрутизатор, как устройство межсетевой связи, может иметь интерфейсы в сетях с разными канальными технологиями и разными значениями параметра MTU. В общем случае, IP-протокол может выполнить передачу пакета размером L байт в сеть с MTU < L посредством предварительной его фрагментации. Но, поскольку фрагментация снижает эффективную производительность сети, то многие приложения требуют установки в заголовках «своих» IP-пакетов флага «DF». 455 Заголовок поврежден? Да Удаление пакета TTL:=TTL - 1 TTL > 0 Нет Сообщение ICMP «Превышено время жизни» Удаление пакета Поиск маршрута Маршрут найден? Нет Да Передача пакета на выходной интерфейс MTU < TotLenght? Да Сообщение ICMP «Получатель недостижим» Маршрут по умолчанию есть? Флаг DF = 0 Нет Удаление пакета Сообщение ICMP (3:4) «Требуется фрагментация, но она запрещена» Фрагментация Поиск в ARP-таблице MAC-адреса следующего узла MAC-адрес найден? Нет Отправка ARP-запроса Запись ответа в ARP-таблицу Отправка пакета на следующий узел маршрута Рисунок 8.16. Обобщенная схема обработки IP-пакета маршрутизатором 456 Запрет фрагментации заставляет маршрутизатор, который должен перенаправить пакет через интерфейс с MTU меньшим размера пакета, отбрасывать его и отправлять узлу-источнику сообщение ICMP (3:4), означающее "Узел недоступен, поскольку требуется фрагментация, но она запрещена". В соответствии с процедурой Path MTU Discoverу (RFC 1191, 1998) в заголовок ICMP такого сообщения (рис. 8.12, поле «Next-hop MTU») маршрутизатор включается размер MTU не принявшего пакет интерфейса. ICMP-модуль отправителя, получив такое сообщения, передает указанное в нём значение MTU своему транспортному модулю, который уменьшает размер формируемых им сегментов. В итоге, IP-модуль промежуточного узла пересылает пакет дальше по маршруту. Кроме перечисленных выше, маршрутизатор выполняет еще целый ряд важных функций, в частности:  проверку целостности принятого пакета;  фиксацию невозможности дальнейшей пересылки пакета и информирование источника о возникших проблемах;  обработку пакетов в соответствии с кодом поля ToS в его заголовке;  отказ в пересылке пакетов с адресами назначения 255.255.255.255;  фильтрацию пакетов, удовлетворяющих заданным критериям;  генерацию сигналов о перегрузке и т. д. Программное обеспечение маршрутизатора включает модули поддерживаемых им сетевых протоколов, модули обработки сообщений ICMP, модули протоколов маршрутизации и ряда других сервисов (QoS, например). Очевидно, что маршрутизатор также выполняет процедуры канального и физического уровней, которые управляются соответствующими протоколами (Ethernet, PPP и т. д.). 457 Заключение к разделу 8.2 В стеке протоколов Интернет представлены прикладной, транспортный и межсетевой уровни. Канальный и физический уровни стека документами Интернет не регламентированы. Принятая в протоколе IPv4 схема логической адресации позволяет создавать сети, размер которых может варьироваться в очень широких пределах (методы VLSM и бесклассовой адресации), а адрес узла (его сетевой префикс) однозначно определяет и адрес сети, к которой он принадлежит. Протокол межсетевого взаимодействия IPv4 предоставляет только дейтаграммный сервис (без установления соединения и без гарантий доставки). Более того, контрольная сумма в IP-пакете защищает только его заголовок. IP-протокол обеспечивает продвижения пакетов между конечными станциями через взаимосвязанных сколь угодно транзитных сложную сетей, и выполняя, неоднородную при среду необходимости, фрагментацию пакетов; сборка фрагментированных пакетов производится только сетевым модулем узла назначения. Межуровневое взаимодействие IP-протокола обеспечивается:  трансляцией логических IP адресов интерфейсов в их физические адреса процедурами протокола ARP;  возможностью задания значения поля ToS прикладными протоколами и приложениями, а также трансляцией его канальному протоколу (если он может учесть эти требования, как, например IEEE 802.1Q);  фрагментацией пакетов в соответствии с размером MTU протокола канального уровня;  возможностью управления фрагментацией (да/нет) со стороны приложений и прикладных протоколов. Протокол ICMP формирует сигналы обратной связи о проблемах продвижения пакетов через сеть, о возникновении перегрузок и т. п., но 458 механизмы разрешения этих проблем в протоколах сетевого уровня (IP и ICMP) не представлены. Все базовые протоколы уровня межсетевого взаимодействия (IPv4, ICMP, ARP) не содержат средств аутентификации пользователей и узлов, в силу чего IP-трафик подвержен многочисленным злонамеренным воздействиям. Информационная безопасность IP сетей обеспечивается средствами специальных протоколов (IP Security, например). 459 механизмы разрешения этих проблем в протоколах сетевого уровня (IP и ICMP) не представлены. Все базовые протоколы уровня межсетевого взаимодействия (IPv4, ICMP, ARP) не содержат средств аутентификации пользователей и узлов, в силу чего IP-трафик подвержен многочисленным злонамеренным воздействиям. Информационная безопасность IP сетей обеспечивается средствами специальных протоколов (IP Security, например). 8.3. Транспортные протоколы Адрес назначения в заголовке IP пакета определяет целевой сетевой узел, на котором могут одновременно выполняться несколько приложений (для операционной системы узла – процессов). Протокол межсетевого взаимодействия IP «умеет» доставлять пакеты взаимодействующим конечным узлам, но ничего не «знает» о приложениях, сообщения которых он переносит; он также не имеет почти никаких средств обеспечения надежности доставки сообщений, даже контрольная сумма в IP–пакете защищает лишь его заголовок. Прозрачное взаимодействие прикладных процессов, выполняющихся на различных конечных станциях в IP–сети и предупреждение доставки приложениям данных с ошибками обеспечивают протоколы транспортного уровня UDP и TCP. 8.3.1. Сокеты и порты Для взаимодействия двух прикладных процессов на одной станции необходим строго индивидуальный логический канал, обеспечиваемый операционной системой узлов. Для его создания необходимы: − правила именования, − определённые ресурсы памяти; − библиотека функций, реализующих операции ввода/вывода (send, recv, sendto, recvfrom, sendmsg, recvmsg, write, read...). Всё перечисленное образует интерфейс взаимодействия прикладной программы и ядра ОС (API); этот программный интерфейс получил 461 специальное название — СОКЕТ (Socket). Посредством механизма сокетов организуется как внутриузловое, так и сетевое взаимодействие прикладных процессов. Очевидно, что для организации межпроцессного канала необходимы два сокета. Если с прикладным процессом, создавшим сокет c именем A, взаимодействуют прикладные процессы, создавшие свои сокеты D, B 1 , B 2 (рис. 8.18), то каждый канал взаимодействия прикладных процессов идентифицируется Пространство пользователя парой сокетов (A, D) и (A, B i ) Программа А Программа D Сокет А Сокет D Узел 2 Программа В1 Программа В2 Сокет В1 Сокет В2 Пространство ядра ОС Узел 1 Файловая система ввода/вывода Транспортный протокол Файловая система ввода/вывода Транспортный протокол Рисунок 8.18. Сокет – это интерфейс «прикладная программа – ОС» Кроме имени, сокет должен получить определённый адрес. Операционные системы могут поддерживать разные типы адресов, но обязательными являются типы INET-адрес и UNIX-адрес. Сокеты, создаваемые для связи локальных процессов, получают локальные адреса; для них создается специальный файл (файл сокета), посредством операций чтения/записи которого и реализуется обмен данными. Если взаимодействующие процессы выполняются на разных вычислительных узлах, то к имени каждого сокета надо добавить еще и уникальный адрес узла. Получается, что сетевые логические каналы связи приложений адресуются структурой вида {(NetADDR j , A), (NetADDR k , Bi)}. Адресные 462 комбинации вида (NetADDR j , имя сокета) нередко называют сетевыми сокетами. Здесь видна некоторая терминологическая путаница, ставшая следствием экономии числа произносимых слов. Повторим еще раз, СОКЕТ – это интерфейс взаимодействия (ввода-вывода) конкретного процесса с ОС, и он, кроме имени и адреса, содержит определенные методы и ресурсы. Для полноты картины следует добавить, что семантика данных, которые сокет отправляет в канал, может существенно различаться для разных прикладных процессов, что и нашло своё отражение в определении трёх типов сетевых сокетов. Так, SOCK_STREAM предназначен для передачи данных, рассматриваемых как байтовый поток; он используется для формирования поля данных TCP-сегментов. SOCK_DGRAM передаёт сообщения прикладного протокола в поле данных UDP-приложения. Заголовки сегментов формируются модулями соответствующих протоколов. В отличие от них, SOCK_RAW отправляет данные прямо в поле полезной нагрузки пакета IP. При этом, ответственность за создание и анализ заголовка блока данных такого транспортного уровня и логики его обработки несёт программист. В частности, этот тип сокета используется для приложений, непосредственно взаимодействующих с сетевым уровнем (ping, например). Таким образом, полное описание логического канала между парой сетевых приложений имеет вид {Protocol, (NetADDR j , A), (NetADDR k , B)}. Имена сокетов (А, B, …), создаваемых для сетевых приложений в стеке TCP/IP имеют форму цифровых идентификаторов, получивших название «порт» (опять игра слов). Для широко используемых сетевых приложений IANA были выделены постоянные значения этих идентификаторов из диапазона [1-1024], например: 53 порт UDP всегда назначается сокету сервера доменных имён (DNS), 80 порт TCP – сокету web-сервер, 25 порт TCP – сокету служб пересылки почтовых сообщений (SMTP) и т. д. Порты из диапазона [1025–6535] используются для назначения пользовательским 463 процессам; некоторые из них, применяемые для доступа к широко используемым серверам (например, MS SQL, Lotus IBM и т.п.) IANA публикует в своих объявлениях для всеобщего сведения. Многим приложениям значения портов задаются программистами (уникальность этих назначений уже не гарантирована). Номера портов могут назначаться и динамически операционной системой при запуске приложений. Таким образом (рис. 8.19), сокет сервера WWW на узле с IP-адресом 197.23.45.11 имеет адрес (tcp, 197.23.45.11, 80); в свою очередь, сокеты двух браузеров, открытых на узле с IP-адресом 172.123.5.11, имеют адреса (tcp, 172.123.5.11, 43999) и (tcp, 172.123.5.11, 44000), а логические каналы связи этих браузеров с www-сервером определяются структурами: {(tcp, 197.23.45.11, 80), (tcp, 172.123.5.11, 43999)} и Прикладной Порт 43999 Порт 44000 {(tcp, 197.23.45.11, 80), (tcp, 172.123.5.11, 44000)}. Прикладной {(tcp, 172.123.5.11, 43999), (tcp, 197.23.45.11,80)} {(tcp, 172.123.5.11, 44000), (tcp, 197.23.45.11,80)} Порт 80 TCP TCP IP IP 197.23.45.11 172.123.5.11 Рисунок 8.19. Логические каналы TCP Для компактности, адреса сокетов часто задаются в форме «IP-адрес: номер порта», например, «172.123.5.11: 43999». 8.3.2. Протокол UDP Транспортный протокол UDP (User Datagram Protocol) описан в документе RFC 768. Он предоставляет приложению сервис передачи данных без предварительного установления соединения и не гарантирует надежную их доставку. Это очень простой протокол, который развивает возможности 464 протокола IP лишь в части демультиплексирования входящего потока пакетов по признаку наличия в них данных определенных приложений и в части контроля наличия ошибок в доставленных блоках. Протокол UDP не выполняет фрагментации сообщений, поступающих от приложения, и каждое сообщение прикладного процесса представляет одним сегментом, т. е. для протокола UDP сообщение является блоком сервиса (SDU). Отсюда также следует, что прикладной процесс, использующий службу UDP, должен сам заботиться о размере генерируемых им сообщений. Формально, IP-протокол может принять от UDP сегмент размером (65535 - 20) байт; заголовок UDP занимает 8 байт и для данных приложения в сегменте остаётся 65507 байт. Однако, предупреждая нежелательную фрагментацию пакетов протоколом IP, большинство приложений, использующих сервис UDP, ограничивают свои сообщения размером 504 байта. Так действует протокол маршрутизации RIP, служба доменных имён DNS, протоколы TFTP (упрощённая передача файлов) и SNMP (управление сетевыми устройствами). С учётом заголовка, размер сегмента UDP обычно не превышает 512 байт, а IP-пакет размером 572 байт всегда будет передан без фрагментации через любую комбинацию сетей. Сегмент данных протокола UDP, как и любой другой протокольный блок, состоит из двух частей: заголовка и области данных (рис. 8.20). Заголовок имеет четыре 16-битных поля, в которых указываются порт отправителя, порт получателя, размер сегмента и контрольная сумма. Поле «Размер UDP-сегмента» несет информацию о количестве байт в сегменте с учетом ее заголовка. 31 16 Порт источника Порт назначения Размер UDP-сегмента Контрольная сумма Данные ……. Данные Рисунок 8.20. Формат UDP-сегмента 465 Расчет значения контрольной суммы выполняется по тому же алгоритму, что и расчет контрольной суммы (побитное IP-пакета суммирование с переносом переполнения старшего разряда результата в младший и инвертирование результата). Поскольку сообщение приложения может иметь размер, не кратный 16 битам, то процедура расчета контрольной суммы выполняет дополнение сегмента нулевыми битами до размера, кратного 16. Это делается только на время вычисления контрольной суммы и незначащие нули не передаются. Поле «Контрольная сумма» заголовка сегмента на время ее вычисления заполняется нулями. Особенностью расчета контрольной суммы является дополнение заголовка сегмента псевдозаголовком. Его формат представлен на рис. 8.21. 16 8 31 IP-адрес источника IP-адрес узла назначения 00000000 Протокол = 17 Размер UDP-сегмента Рисунок 8.21. Формат псевдозаголовка UDP-сегмента Псевдозаголовок включается перед заголовком исходного сегмента; его поле «Протокол» содержит код UDP, используемый сетевым протоколом. Значения полей с IP-адресами источника и узла-назначения известны приложению и передаются транспортному протоколу. Такое дополнение UDP-сегмента выполняется обеими конечными станциями. Поскольку в псевдозаголовке есть информация о сетевых адресах, а в заголовке сегмента – о портах взаимодействующих процессов, то совпадение рассчитанного приемником значения с записанной в заголовке сегмента контрольной суммой служит гарантией доставки сегмента нужной станции и нужному приложению. Если их значения не совпадают, то UDP-сегмент уничтожается, и уведомление передающей станции об этом не передаётся. Псевдозаголовок, как и дополнение поля данных, в канал не передаются. Вычисление контрольной суммы в некоторых реализациях UDP является опциональным. В конце 1980-х годов в некоторых стеках 466 протоколов по умолчанию функция расчета контрольной суммы UDP стала отключаться. Делалось это во имя уменьшения издержек работы сетевой файловой системы, которая использует сервис UDP. Такое решение еще можно было считать допустимым для обмена данными между системами в одной локальной сети, где кадры канального уровня защищаются контрольной суммой, рассчитанной на основании циклического избыточного кода (CRC). Однако, отключение вычисления контрольной суммы при обмене данными в распределенных территориальных и глобальных сетях существенно понижает надежность транспортной услуги; документами RFC 1122 и 1123 (Host Requirements) включение её признано обязательным. В общих чертах, взаимодействие приложений, использующих услугу UDP-протокола, выглядит следующим образом. Сообщение прикладного процесса упаковывается в UDP-сегмент, в заголовке которого указываются номера портов, назначенных приложениям. Заметим, что порт узла назначения должен быть либо стандартным (хорошо известным), либо как-то передан приложению, формирующему передаваемый сегмент. Эта адресная информация дополняется IP-адресами взаимодействующих станций. Модуль сетевого протокола приемной станции, получив пакет, в адресе назначения которого указан его IP-адрес и в поле «Протокол» - код UDP (17), передаёт содержимое поля данных IP-пакета своему UDP-модулю. Последний проверяет наличие зарегистрированного в операционной системе приложения, связанного с номером порта, указанным в поле «Порт назначения» заголовка полученного сегмента. Если такого приложения не оказывается, то узлу-источнику отправляется сообщение ICMP(3:3) «Порт недоступен», приложение с а соответствующий блок данных указанным номером порта уничтожается. Если в операционной системе зарегистрировано, то модуль протокола UDP, проверив контрольную сумму полученного сегмента, добавляет его в очередь, из которой эта прикладная программа читает данные. Если очередь порта переполнена, то сегмент уничтожается. 467 8.3.3. Протокол TCP Задачей протокола TCP является организация и поддержание надёжного логического дуплексного канала между двумя приложениями, выполняющимися на конечных станциях в дейтаграммной IP сети. Этот логический канал должен обеспечить приложению два безошибочных и упорядоченных байтовых потока управляемой интенсивности. В число механизмов, посредством которых протокол TCP выполняет эту задачу, входят: установление и ликвидация соединения, алгоритмы ARQ с возвратом на N или, в более поздних версиях, ARQ с выборочным повторением, механизмы тайм-аута и управление потоками на основе сигналов обратной связи. Протокол описан в RFC 793 и дополнен в RFC 1122, 3168, 6093. Аналогично UDP, каждый прикладной процесс сетевого приложения для TCP-модуля адресуется номером порта. Логический канал между взаимодействующими прикладными процессами однозначно определяется двумя STREAM–сокетами: {tcp, IP-адрес: порт отправителя} и {tcp, IP-адрес: порт получателя}. 8.3.3.1. Сегменты TCP ТСР не сохраняет границы сообщений прикладного процесса и рассматривает поступающие ему от приложения данные как поток байтов. Свои сегменты он формирует с учетом свойств протоколов сетевого и канального уровней, а также с учётом загрузки сети. Формально, размер сегмента ТСР не должен превосходить (65 535 - заголовок IP) байт. Однако, сегменты столь большого размера никогда не формируются, поскольку: − не всегда таким объёмом данных располагает приложение, − велики потери при нарушении целостности сегмента, − для линий, по которым передаётся пакет на пути к получателю, есть ограничения максимальной величины поля данных кадра канального уровня (MTU), превышение которой потребует нежелательной фрагментации пакетов IP. 468 TCP-передатчик при формировании сегмента учитывает значение параметра MSS (Maximum Segment Size), который является переменной протокола; максимальное значение этого параметра модули TCP могут оценить в соответствии с выражением: MSS = MTU – (maxIPHdrLen + maxTCPHdrLen). Но ценность такого способа определения величины MSS не очень велика. Действительно, узел-отправитель «знает» величину MTU канального протокола только той сети, к которой подключён «его» узел; следовательно, он не может сформировать сегменты, размер которых гарантировал бы отсутствие необходимости фрагментации сетевых пакетов на всех участках маршрута. Если размер IP-пакета, переносящего конкретный TCP-сегмент, оказывается больше MTU выходного интерфейса очередного маршрутизатора, то его модуль IP выполнит фрагментацию. Эти фрагменты собираются в исходный пакет IP-модулем приемного узла. Существуют достаточно веские причины, по которым фрагментация сегментов транспортного протокола на IP-уровне является нежелательной. Для её предотвращения модуль IP должен получить от приложения указание о запрете фрагментации пакетов этого соединения. Последнее, в условиях отсутствия сведений о минимальном на маршруте значении MTU, приводит к необходимости вспомогательного механизма адаптации значения MSS. ТСР-передатчик, выполняя процедуры регулирования сетевой нагрузки, может формировать сегменты, размер которых будет меньше MSS. Например, если приложение передает ТСР-передатчику 1000 байт данных (что меньше MSS), то в зависимости от текущего состояния сети и приёмного приложения, они могут быть переданы в одном или в нескольких сегментах. 8.3.3.2. Адаптационные механизмы протокола Надежную доставку данных протокол ТСР обеспечивает посредством своих адаптационных механизмов. Этот протокол работает поверх сетевой среды, в которой пакеты могут теряться, дублироваться, приходить в узел 469 назначения с нарушением порядка их отправки. Для идентификации таких нарушений в протоколе введена последовательная нумерация байтов данных соединения. Диапазон нумерации ограничен значениями [0, 232-1]. Порядковый номер первого байта поля данных считается порядковым номером сегмента. Начальное значение нумерующей последовательности для каждого соединения выбирается в период его установления случайным образом из допустимого диапазона. Управление передачей данных и надёжность их доставки протокол ТСР обеспечивает механизмом «скользящего окна», положительными подтверждениями приема, алгоритмами ARQ с возвратом на N или ARQ с выборочным повторением. Подтверждения приема имеют накопительный характер, т. е. подтверждение приема байта с номером N означает, что все байты с номерами N-1, N-2, … также успешно доставлены. Поскольку каждый байт сегмента оказывается пронумерованным, то достаточно просто решается задача опознания на приемной стороне нарушений последовательности их доставки. Однако, поскольку нумеруются байты, то размера нумерующей последовательности (232 -1) может не хватать для работы в высокоскоростных сетях с достаточно большими окнами передачи. При скорости передачи 100 Мбит/с полный цикл однократного использования номеров байтов из допустимого диапазона [0, (232-1)] составляет не менее 5.7 минуты, что вполне достаточно для того, чтобы любой сегмент был либо получен приемной станцией, либо уничтожен (продолжительность жизни IP-пакета существенно меньше пяти минут). При высоких битовых скоростях (порядка 10 Гбит/с), принципиально возможно появление в буфере приёмника двух сегментов, имеющих одинаковые порядковые номера. Но это может быть следствием не только малости диапазона нумерации, но и результатом повторной отправки уже принятого, но непереданного ещё приложению сегмента. Ясно, что действия приёмника в отношении этих сегментов должна быть разной. Неоднозначность интерпретации сегментов с одинаковыми номерами разрешается включением 470 в их заголовок временной метки отправки. В случае несовпадении временных меток, два сегмента с одинаковыми номерами будут интерпретированы как разные протокольные блоки. В то же время, дубликатные сегменты передаются со значением временной метки исходного блока данных. Заметим, что для работы этого механизма не требуется синхронизация сетевого времени, достаточно и того, что временные метки в отправляемых сегментах образуют возрастающую последовательность. Для надежной работы описанного механизма в высокоскоростных сетях требуется (RFC 1323) гранулированность отсчётов системных часов узлов, не превышающая одной миллисекунды. Передача данных в протоколе ТСР управляется механизмом скользящего окна (рис. 8.22). Регулирование величины окна передачи (Ws ) имеет целью, во-первых, максимально полно использовать пропускную способность соединения и, во-вторых, не допустить перегрузок сети. Передатчик S last Приемник WS S recent … WR S last + Ws -1 Подтвержденные байты Rlast Rnext Rnext+p Rlast+WR -1 RNew Принятые байты Рисунок 8.22. Окна передачи и приема в ТСР-модулях Для управления потоком данных передающий ТСР-модуль фиксирует значения трех указателей: − Slast , наименьший номер в последовательности отправленных, но еще неподтвержденных байтов, − S resent , номер последнего отправленного байта, − ( Slast + WS − 1) , наибольший номер байта, который передающий модуль может отправить в сеть до изменения значения указателя S last . В свою очередь, ТСР-приемник фиксирует значения следующих указателей: 471 − Rlast , наименьший номер в последовательности уже принятых, подтверждённых, но еще не переданных приложению байт, − Rnext , число на единицу больше номера последнего подтвержденного байта, − Rnew , наибольший номер корректно принятого байта. Обычно Rnew = Rnext − 1 . Однако, Rnew может оказаться и больше Rnext когда приемный модуль сохраняет в своем буфере байты, принятые в сегментах без ошибок, но пришедших с нарушением естественного порядка их следования. Если размер буферной памяти приемного модуля равен WR байт, то всегда существует возможность принять байты с номерами, не превышающими Rlast + WR − 1 . При этом учитывается, что приложение не обязательно «забирает» байты немедленно после их поступления в буфер. Прибывший сегмент проверяется на целостность данных и, при положительном результате такой проверки, его байты записываются в соответствующую область памяти приемника. Если первый байт принятого сегмента имел номер Rnext , то значение указателя Rnext обновляется, увеличиваясь на число байт поля данных сегмента. Обновленное значение Rnext отсылается передающему приложению как положительное подтверждение успешного приема всех байт с порядковыми номерами меньшими этого значения. Передающий модуль устанавливает Slast = Rnext и, тем самым, окно передачи смещается вперед, позволяя отправлять очередные сегменты данных. Протокол ТСР обеспечивает управление интенсивностью потока передаваемых данных, что необходимо для эффективного использования пропускной способности соединения, для предотвращения переполнения буфера приёмника и для недопущения перегрузки сети. Информирование передатчика о степени заполнения приемного буфера обеспечивает, так называемое, объявляемое окно (advertised window). Его значение, передаваемое в специальном поле заголовка сегмента, несет информацию о 472 доступной величине буферной памяти приемника. Эта величина определяется выражением WA = WR − ( Rnew − Rlast ) . Получив значение WA , передающий модуль из накопленных в его буфере данных может отправить не более W A байт. С учетом ограничения величины MSS, размер очередного сегмента не может превосходить min{WA , MSS} . При этом, если текущая величина окна передачи WS позволяет отправить несколько сегментов, то их совокупный размер никогда не превышает значение WA . Для иллюстрации эффекта регулирования интенсивности генерируемого приложением потока с учётом возможностей приемника, рассмотрим ситуацию, когда приложение на приемной стороне прекращает читать данные из буфера своего модуля TCP. Ясно, что величина Rnew будет увеличиваться, а Rlast оставаться постоянной; такая динамика приводит к уменьшению величины объявляемого окна и передающий модуль TCP вынужден уменьшать сначала количество, а затем и размер отправляемых сегментов. В конце концов, окно WA станет равным нулю и передающий модуль ТСР прекратит отправку данных. Формирование передатчиком малых сегментов увеличивает накладные расходы протокола и снижает эффективную производительность соединения. Поэтому передатчик отправляет блок данных в сеть лишь при условии, что текущее значение WA превышает установленный порог (защита от отправки мелких сегментов). С этой же целью в условиях низкой активности приложения передатчик накапливает байты и отправляет сегмент размером меньше этого порога лишь при истечении определенного интервала времени (500 мс) после отправки предыдущего сегмента. Если величина объявляемого окна приема WA является механизмом адаптации интенсивности потока к возможностям приемника, то величина окна передачи WS выполняет функции адаптации интенсивности потока к 473 возможностям сети. Неявными сигналами о перегрузке в сети являются: отсутствие подтверждения приема сегмента в течение заданного интервала времени (timeout), несколько подряд полученных подтверждений с неизменным значением Rnext , увеличение времени полного оборота; явным сигналом обратной связи является установленного бита ECN в заголовке сегмента, пришедшего от узла-приёмника. Получение этих сигналов вызывает уменьшение окна передачи WS ; при их отсутствии окно передачи либо сохраняет своё значение, либо увеличивается. Ясно, что исключительную важность имеет алгоритм регулирования величины окна передачи (рис. 8.23). Протокол TCP использует для этого различные варианты рассмотренных в разделе 4.4.2.2 алгоритмов Тахо, Рино, реже Вегас. WS Рисунок 8.23. Регулирование окна передачи по алгоритму Рино Значение таймера повторной передачи существенно влияет на производительность соединения. Его слишком малое значение ведёт к неоправданному росту числа повторных передач, а слишком большое – к увеличению времени бездействия соединения. Время доставки сегментов в сетевой среде является индикатором состояния её загруженности и может изменяться в значительных пределах даже в течение коротких интервалов времени. Поэтому, значение таймера повторной передачи должно выбираться с учётом как текущего значения времени доставки сегментов, так и его изменчивости. В протоколе ТСР для этого предусмотрена адаптивная 474 процедура, базирующаяся на периодическом измерении интервала времени от посылки сегмента до получения подтверждения его приема (RTT i ). Это измерение обычно выполняется в отношении одно сегмента из окна отправки. Получаемые значения усредняются с весовыми коэффициентами, уменьшающимися от последнего к предшествующим замерам. В результате получают текущее усреднённое временя полного оборота (RTT avg,i ) RTTavg ,i = αRTTavg ,i −1 + (1 − α ) RTTi , где 0 < α ≤ 1 , типичное значение α = 7 8 . Значение таймера повторной передачи (RTO) учитывает также дисперсию измерений RTT RTO = RTTavg ,i + kσ RTT , где k - некоторая константа. Таким образом, если девиация значений времени полного оборота значительна, то и значения таймера повторной передачи будут увеличены. Поскольку вычисление значения стандартного среднеквадратического отклонения относительно трудоемко, то оценка вариации значений RTT базируется на вычислении абсолютного отклонения RTTi − RTTavg ,i . Таким образом, получаем: RTO = RTTavg ,i + 4di , di = βdi −1 + (1 − β ) | RTTi − RTTavg ,i | , при β = 0.25 . 8.3.3.3. Формат сегмента TCP Заголовок сегмента (рис. 8.24) содержит 20-байтную фиксированную часть и опциональную составляющую, размером не более 40 байт. Рассмотрим назначение отдельных полей заголовка. «Порт источника» и «Порт назначения»: содержат номера портов передающего и приёмного приложений, соответственно. «Порядковый номер сегмента»: в фазе установления соединения (флаг SYN = 1) в этом поле содержится начальное значение нумерующей последовательности байтов данных потока соединения (Initial Sequence Number, ISN); значение номера первого байта потока будет ISN+1. В режиме 475 передачи (флаг SYN = 0) значение в этом поле определяет позицию первого байта поля данных сегмента в байтовом потоке канала. Напомним, что ТСР нумерует байты, а не сегменты, и если порядковый номер текущего сегмента равен 567, а поле данных содержит 12 байт, то следующий сегмент будет иметь порядковый номер 579. Поскольку ТСР-канал является дуплексным, то в каждом из направлений передачи ведётся своя нумерация. 10 4 Порт источника 31 24 16 Порт назначения Порядковый номер сегмента Порядковый номер подтверждения Смещен. данных Резерв Флаги Размер окна Контрольная сумма Указатель срочных данных Опции … … … …. Заполнитель Данные Рисунок 8.24. Формат ТСР-сегмента «Порядковый номер подтверждения»: при установленном флаге ACK (см. ниже) это поле содержит значение на единицу большее порядкового номера старшего байта в непрерывной их последовательности, полученной приемником без ошибок; тем самым подтверждается правильность приема всех предыдущих байт. В фазе установления соединения (SYN = 1, ACK = 0) значение этого поля не обрабатывается. «Смещение данных»: поле определяет длину заголовка ТСР-сегмента в 32-битных словах; эта информация позволяет приемному модулю определить начало поля данных, т. к. заголовок может содержать опциональное поле переменной длины. «Резерв»: поле в настоящее время не используется и заполняется нулями. «Размер окна»: поле, в котором объявляется величина (в байтах) приемного буфера TCP (WА ); WA, max = 65535 байт. 476 «Флаги»: поле длиной 6 бит, каждый из которых является флагом; они имеют следующий смысл. SYN – флаг установления соединения; при SYN = 1 поле «Порядковый номер сегмента» содержит начальное значение нумерующей последовательности байт в данном соединении. ACK – флаг, указывающий на актуальность значения в поле «Порядковый номер подтверждения». PSH – включение функции «проталкивания» сегмента. В исходной спецификации протокола ТCP предполагалось, что приложение должно располагать возможностью передать «своему» передатчику ТСР указание установки этого флага; одновременно это требовало от TCP-передатчика немедленной (т. е. без ожидания получения объема даных, достаточного для формирования сегмента максимального размера) отправки содержимого буфера передатчика. Таким образом, наличие флага PSH означает, что буфер передатчика отправкой этого сегмента полностью очищается. Получив сегмент с установленным флагом PSH приемник TCP отправит приложению сигнал о необходимости срочного чтения данных из буфера. Следует отметить, что все реализации TCP в отношении установки этого флага ведут себя по разному, а общих правил его применения так и не было выработано. URG – флаг, индицирующий наличие срочных данных в сегменте. В ряде случаев, возникает необходимость передачи срочных данных (например, команду прервать передачу большого файла). Такие данные помещаются передатчиком в очередной формируемый сегмент и дополняются обычными данными, т. е. в таком сегменте будут байты как срочных, так и обычных сообщений. Флаг URG=1 приносит приемнику сигнал о наличии в сегменте срочных данных и необходимости запуска процедуры срочной их передачи приложению. Поле «Указатель срочных данных» определяет номер последнего байта этих срочных данных в данном сегменте; после приема срочных байтов приложение переходит в обычный режим чтения приемного буфера. Флаг в сегменте устанавливается по тебованию приложения 477 (например, ftp и telnet требуют его установки при аврийном завершении сессии). Сегмент с установленным флагом URG отправляется даже в случае, когда противоположная сторона объявила нулевое окно приема. RST – информирование приёмного модуля другого участника соединения о разрыве связи по причине каких-то аномалий; используется для перезагрузки соединения. FIN – флаг, индицирующий, что у передатчика нет больше данных для этого соединения; тем не менее соединенение не ликвидируется и по нему передаются данные от другого участника. В 2001 году (RFC 3168) перечень флагов был расширен (за счёт резервных битов) введением флагов ECN-echo и CWR (Congestion Window Reduce). Эти флаги используются механизмами предупреждения перегрузок. Единичные знначения битов ECN-echo и CWR при устанавленном флаге SYN (т. е. на этапе установления соединения) информируют другого участника соединения о способности TCP-передатчика узла обрабатывать биты ECN в IP пакете, т. е. адекватно реагировать на явный сигнал перегрузки. Принимающий соединение узел, соглашаясь с использованием этого механиза, отвечает своим сегментом SYN+ACK с установленным только флагом ECN-echo. При флаге SYN = 0 (в фазе передачи данных) установкой бита ECN-echo = 1 узел сообщает, что им был получен IP-пакет с флагом ECN = 1, т. е. в сети где-то возникла перегрузка. Далее в течение RTT во всех отправляемых принимающим узлом сегментах флаг ECN-echo устанавливается в 1. Флаг CWR устанавливается в 1 узлом-источником потока для индикации его реакции на сигнал о перегрузке: узел сообщает, что он уменьшил окно передачи и TCP приёмник может далее не устанавливать бит ECN-echo в 1. «Указатель срочных данных»: значение этого поля при установленном флаге URG, будучи добавленным к значению поля «Порядковый номер сегмента», определяет последний байт срочных данных. 478 «Контрольная сумма»: значение поля рассчитывается по всему сегменту с дополнением его нулями до размера, кратного 16 битам, и с 12-байтным псевдозаголовком; псевдозаголовок содержит сетевые адреса отправителя и получателя, тип протокола (6) и размер ТCP сегмента. Эти дополнения используются только для расчета контрольной суммы и не передаются. «Опции»: поле используется для расширения семантики заголовков сегментов. Опции задаются тремя атрибутами: тип (1 байт), общий размер в байтах (1 байт) и значение (от 0 до 38 байе); некоторые из опций определяются только типом. Опция Тип 1 байт Размер 1 байт Значение до 38 байт Рисунок 8.25. Формат задания опций Из 26 определённых различными RFC опций TCP наиболее активно используются следующие. Опция «Максимальный размер сегмента» (Maximum segment size, позволяет MSS) узлу проинформировать противоположную сторону о величине максимального размера поля данных в сегментах, который он способен отправлять и принимать. Опция MSS Тип 2 Размер 4 байта Значение 2 байта Рисунок 8.26. Формат опции «Максимальный размер сегмента» Соответственно, противоположная сторона для уменьшения вероятности фрагментации своих сегментов, не будет формировать их больше указанной величины, даже в том случае, когда ее MSS превышает полученной значение. Опция MSS может появляться только в сегментах с установленным флагом SYN. В современных высокоскоростных сетях ограничение величины окна передачи и приёма величиной 65535 байт может приводить к существенному недоиспользованию потенциальной 479 производительности соединения. Применение окон большего размера позволяет опция «Коэффициент масштабирования окна» (Window Scale, WS). Её значение – это показатель степени числа 2k (от 20 до 214), которое является множителем к размеру объявляемого окна. Опция может появляться только в сегменте с установленным флагом SYN и она информирует другого участника соединения о возможности использования этой функции. Если в ответном сегменте SYN эта опция не представлена, то это означает неспособность модуля TCP противоположной стороны интерпретировать показатель увеличения окна. Появление опции в ответном сегменте SYN с любым значением от 0 до 14 говорит о возможности работы с масштабируемым окном обоих участников соединения. При этом, у взаимодействующих сторон коэффициент масштабирования может быть разным. Опция «Временная метка» (Time Stamp) используется, в основном, для измерения RTT; наличие её в сегментах позволяет также детектировать повторное использование их порядковых номеров. Значения опции – два четырёхбайтовых поля (рис. 8ю27). В поле Time Stamp Value (TSval) записывается значение системного времени узла-источника сегмента данных, зафиксированное при его отправке. Оно копируется в поле Time Stamp Echo Reply (TSecr) сегмента, подтверждающего доставку этих данных. Если несколько принятых сегментов подтверждаются одним сегментом ACK, то в его поле TSecr записывается значение TSval, представленное в подтверждаемом сегменте с минимальным порядковым номером. Опция Time Stamp (TS) Тип 8 Размер 10 байт Значение TSval Значение TSecr 4 байта 4 байта Рисунок 8.27. Формат опции «Временная метка» По умолчанию, когда опция не используется, RTT измеряется один раз на интервале обработки сегментов, разрешённых к отправке величиной окна передачи. Отправка первого в пределах окна передачи сегмента запускает специальный таймер и при отправке других сегментов он уже не может быть 480 использован. Если окно невелико (например, 8–10 сегментов), то такая периодичность измерения RTT оказывается достаточной для корректного вычисления значения RTO. Однако, при больших окнах передачи, для корректного определения RTO требуются более частые измерения времени полного оборота. В этом случае и используется опция Time Stamp. Естественно, значение метки времени должно изменяться при отправке каждого сегмента, что требует таймеров с малым шагом (1 мс и менее). Поле «Порядковый номер подтверждения» обеспечивает реализацию механизма ARQ с возвратом на N. Все реализации протокола TCP поддерживают этот алгоритм. Выборочная повторная передача (Selective Repeat ARQ) реализуется как дополнительная возможность TCP и для её поддержки используются две опции. Первая, «SACK permitted», применяется для объявления узлом возможности использования им режима выборочной повторной передачи. Эта опция передается при установлении соединения в сегменте SYN (RFC 2018). Очевидно, что применение режима выборочной повторной передачи возможно только при участии в этом процессе обеих конечных станций, т. е. в фазе установления соединения обе станции должны в сегментах SYN указать опции «SACK permitted». Вторая опция «SACK» (расширенное подтверждение доставки) используется в фазе передачи данных. Алгоритм ARQ с выборочным повторением позволяет принимать сегменты, поступающие с нарушением их последовательности передачи (рис. 8.28). Принятые байты WR Rnext Rnext+p Rnext+k Rnext+ Rnext+j Rnext+WR -1 Рисунок 8.28. Состояние буфера приёмника TCP с SR ARQ Получатель, приняв такой сегмент, опцией SACK уведомляет отправителя о его буферизации и значениями опции идентифицируют диапазоны «внеочередных» байт потока, сохранённых в буфере приемника (рис. 8.29). В одной опции может указываться до 4 таких диапазонов. 481 Опция SACK NOP NOP Тип = 5 Размер Значение Rnext + p 4 байта Значение Rnext + k + 1 Значение Rnext + m Значение Rnext + j + 1 Рисунок 8.29. Формат опции SACK На основании значений поля «Порядковый номер подтверждения» и полей опции SACK, содержащих порядковые номера начального байта «внеочередных» сегментов, передатчик TCP определяет диапазоны байт, который должен быть передан повторно. 8.3.3.4. Функционирование соединения TCP Фаза установления соединения Основной задачей фазы установления соединения является согласование сторонами определенного набора параметров, определяющих режим последующей передачи данных. Только при успешном выполнении процедур создания соединения за ним закрепляется определённые ресурсы узла и соединение регистрируется в ОС. В этой фазе выполняются следующие действия (рис. 8.30). 1. Узел А отправляет узлу B запрос соединения, представляющий собой ТСР-сегмент с нулевым полем данных, с установленным флагом SYN и случайным начальным значением нумерующей последовательности ISN = m. Случайный характер выбора значения ISN является достаточно надежной мерой, предупреждающей ошибки интерпретации сегментов из двух соединений, закрытого и нового, созданного с малой задержкой между теми же сокетами. 2. Узел B, если он готов принять запрашиваемое соединение, отвечает отправкой сегмента с нулевым полем данных и установленным флагом ACK. 482 Поле «Порядковый номер подтверждения» содержит значение на единицу больше значения m (AN = m + 1). Этим же сегментом узел B запрашивает соединение с узлом A в противоположном направлении (SYN = 1) и также инициализирует начальное значение своей нумерующей последовательности (ISN = k). Если узел B не готов принять соединение или он получает команду ABORT от прикладного протокола, то отправляется TCP-сегмент с установленным флагом RST. 3. Узел А отвечает на запрос соединения от узла B отправкой сегмента, в котором «Порядковый номер сегмента» устанавлен в значение m+1 (SN = m + 1), флаг ACK = 1 и AN = k + 1 (подтверждение «понимания» начала нумерующей последовательности байт от узла B). A B SYN=1, ISN = m RTT ACK=1, SYN=1, SN= k, AN = m+1 ACK=1, SN = m+1, AN = k+1 RTT Рисунок 8.30. Процедура установления TCP-соединения Такая трехэтапная процедура установления дуплексного логического канала гарантирует согласование параметров ISN, MSS, механизма ARQ, правил интерпретации значений поля Window и т.д., принципиально важных для последующего функционирования соединения. Также на этой фазе каждая из сторон получает первую оценку значения RTT, необходимую для определения разумной величины RTO. В числе параметров, которыми обмениваются стороны, есть как требующие согласия обоих участников, так и просто принимаемые ими во внимание. Так, инициатор соединения, в своём SYN-сегменте может «предложить» использование опции time stamp и заполнит поле TSval в ней, 483 но реализация возможностей этой опции будет возможно, если и другая сторона в своем SYN-сегменте также включит опцию Time Stamp. В отношении опции WS сама возможность масштабрования окна подтверждается включением её в оба сегмента SYN, но значения коэффициентов масштабирования, указываемых каждой из сторон, носит информационный характер. Из двух значения MSS, указанных в сегментах SYN, для передачи данных в соединении выбирается минимальное. Более того, впоследствии этот параметр может переопределяться в соответствии с процедурой Path MTU Discoverу (см. раздел 8.2.6). Все операционные системы с 1988 года поддерживают эту процедуру. Однако, ее применение может столкнуться с проблемой Path MTU Discovery Black Hole (RFC 2923, 1999). Источником этой проблемы является чрезмерная осторожность некоторых администраторов, блокирующих отправку маршрутизаторами сообщений ICMP, включая и сообщения ICMP (3:4). В результате, соединение между хостами устанавливается, но IP-пакеты данных с установленным флагом DF и с размером большим, чем неизвестный отправителю в такой ситуации минимальный MTU пути, будут отбрасываться без соответствующего информирования отправившего пакет узла. Протокол ТСР поддерживает два режима создания соединения – активный и пассивный. В приложениях, построенных по клиент-серверной архитектуре, модуль ТСР сервера, выполняя системный вызов приложения PASSIVE-OPEN, формирует соответствующий сокет и переходит в режим «прослушивания» (режим готовности принять запрос соединения, состояние «полусоединения»). При этом логический канал не создаётся. Когда клиент устанавливает связь с сервером, он выполняет процедуру активного соединения. В нее входит создание сокета на клиентской стороне и выполнение описанной выше трехэтапной процедуры. В определённых ситуациях, сервер также может выполнять активное соединение, адресуя свой запрос к заранее согласованному порту на стороне клиента. 484 Фаза передачи данных Сервис надежной доставки данных в протоколе ТСР обеспечивается механизмом скользящего окна и процедурой ARQ с возвратом на N (режим по умолчанию) или ARQ с выборочным повторением (опционально, в современных реализациях протокола). Протокол также обеспечивает управление потоком при передаче данных посредством изменения величин объявляемого окна и окна передачи. Рассмотрим пример обмена данными в логическом TCP–канале (рис. 8.31). Пусть в момент t 0 ТСР-модуль узла B объявил величину своего приёмного буфера WA = 2048 байт и номер старшего подтвержденного байта 2000 - 1. Такой размер окна позволяет TCP-передатчику узла А отправить 2048 байт данных. Поскольку согласованное на этапе установления соединения значение MSS = 1024 , то узел А отправляет подряд два сегмента, нумеруя байты начиная с 2000. В этих сегментах, он объявляет величину своего окна WA = 1024 байта и подтверждает, что им приняты все байты узла A до байта с номером 0. Узел B задерживает выдачу подтверждения на прибывший от А сегмент с SN=2000, например, в силу использования им стратегии накопительного подтверждения. A B SN=0, AN=2000 t1 SN=2000, AN=1 t2 SN=3024, AN=1 Win=2048, No data Win=1024, Data=2000-3023 Win=1024, Data=3024-4047 Win=512, Data=1-128 SN=1, AN=4048 t4 t0 t3 SN=4048, AN=129 Win=1024, Data=4048-4559 Рисунок 8.31. Фаза передачи данных TCP-соединения 485 В момент t3 модуль ТСР узла B получил от приложения 128 байт данных для отправки; вместе с ними он отправляет подтверждение получения двух сегментов данных, указывая AN= 4048. К этому моменту в буферной памяти приёмного модуля ТСР узла B оказывается свободными лишь 512 байт, поэтому он объявляет величину W A = 512 . Когда узел А получит этот сегмент, он, несмотря на то, что в момент t 4 в его буфере имеется достаточно большой объем данных, сможет отослать только 512 байт и не перегрузит буфер узла B. В общем случае, TCP модуль, получив сегмент, в котором WA = 0, прекращает передачу данных и ждет следующий сегмент от противоположной стороны, в котором величина этого окна будет ненулевой. Этим следующим сегментом может быть сегмент ACK на ранее отправленные им данные либо сегмент данных, отправляемый противоположной стороной. Вместе с этим, протокол TCP предпринимает и самостоятельные действия в случае, когда приемная сторона длительное время после объявления нулевого буфера приема не присылает свои сегменты (нет данных для отправки или сегмент-подтверждение с отличным от нуля окном был потерян). Чтобы предотвратить подобную тупиковую ситуацию, ТСР использует специальный persist-таймер, который инициализирует периодический опрос получателя о размере его приемного буфера. Сегменты, которые при этом посылаются, называются window probes. Они содержит 1 байт данных (TCP всегда позволяет послать 1 байт данных, после того как приёмный буфер был закрыт). Если подтверждения этих сегментов возвращаются с размером окна WA = 0 , то отправленный байт считается не подтвержденным. Значения persist-таймера удваиваются при каждой последующей отправке сегмента window probes и достигнув максимального значения (60 сек) далее не изменяются. TCP не прекращает отправку сегментов window probes до тех пор, пока не будет получен сегмент ACK c WA ≠ 0 , или приложение примет решение о разрыве соединения. 486 В фазе передачи данных возможна ситуация, в которой механизм объявляемого окна может приводить к неэффективному использованию пропускной способности канала связи. Пусть передающее приложение имеет большой объем данных для передачи, а принимающее приложение может читать буфер своего ТСР приемника лишь небольшими порциями. В конце концов, это приведет к объявлению приемным модулем малого значения окна WA ; соответственно, передающий модуль будет формировать маленькие сегменты, что увеличит «накладные» расходы протокола при их передаче. Это явление часто называют «синдромом ленивого окна». Для уменьшения его негативного влияния ограничивают возможность объявления малых значений WA . А именно, пока размер свободного буферного пространства приемника не достигнет половины его объема либо значения MSS, размер окна WA объявляется равным нулю. Данные на передающей стороне буферизируются и отправляются после объявления WA достаточно большого размера. Фаза ликвидации соединения Протокол ТСР реализует процедуру поэтапной ликвидации соединения независимо в каждом направлении (рис. 8.32). Необходимость в закрытии соединения возникает, когда приложение сообщает своему модулю TCP об отсутствии у него данных для отправки. А FIN=1, SN=4386 Получены 150 байт Data=303-452, AN=4387 ACK=1, AN=453 FIN=1, SN=453, AN=4387 Запуск TIME-WAIT B Запуск TIME-WAIT AN=454 Рисунок 8.32. Ликвидация TCP-соединения 487 ТСР-модуль узла А, получив от приложения информацию о завершении сессии, отправляет находящихся в его буфере данные, ожидает получения подтверждения их успешного приема и после этого отправляет узлу B сегмент SN=4386 c установленным флагом FIN. Модуль ТСР узла B подтверждает прием этого сегмента и передает извещение о запросе на закрытие соединения своему приложению. Располагая данными для узла А, модуль ТСР узла B отправляет ему сегмент со 150 байтами данных и получает подтверждение их приема. Получив от своего приложения подтверждение разрыва соединения протокольный модуль узла B отправляет встречный сегмент FIN и ждёт получения его подтверждения. Получив FIN от узла B модуль TCP А переходит в состояние ожидания и запускает таймер TIME_WAIT с значением задержки равным удвоенному максимальному времени жизни сегмента (MSL, Maximum Segment Live, от 30 до 300 с, конфигурационный параметр). В этот период единственным сегментом, который может прийти узлу А, является повторный сегмент FIN от узла B (если соответствующий сегмент ACK от А был утерян). Если такой сегмент приходит, то узел А повторно отсылает сегмент АСК и вновь перезапускает таймер TIME_WAIT. При достижении этим таймером значения нуль, узел А ликвидирует соединение и удаляет запись о нем из таблицы соединений. Состояние ожидания обеспечивает защиту будущих соединений между этими же прикладными процессами от обработки задержавшихся в сети сегментов предыдущего соединения. За двойное время жизни все, недоставленные сегменты этого соединения, будут уничтожены. Протокол ТСР располагает также механизмом срочной ликвидации соединения посредством отправки RST-сегмента. Его генерация является реакцией на исполнение приложением примитива ABORT или получение сегмента, адресованного приложению, которое на данном порте не зарегистрировано. Передающий модуль ТСР, отправив сегмент с флагом RST, уничтожает все данные, находящиеся в его буфере. Приемный модуль 488 ТСР, получив сегмент RST, информирует о ликвидации соединения соответствующий прикладной процесс. Заключение к разделу 8.3 Транспортные протоколы обеспечивают адресацию приложений в пределах операционной системы узла; для этого используется механизм сокетов, именами которых служат номера портов. Протоколы транспортного уровня UDP и ТСР полностью экранируют приложения от сетевой инфраструктуры и обеспечивают прозрачное их взаимодействие в сколь угодно сложной сетевой среде. Контрольные суммы протокольных блоков (сегментов) UDP и ТСР учитывают не только содержание и заголовки сегментов, но и адреса сетевых сокетов логического канала между взаимодействующими приложениями; тем самым обеспечивается строгий контроль как верности доставляемых данных, так и проверка их адресатов. Протокол UDP каждое сообщение приложения представляет одним сегментом; для приложения этот протокол обеспечивает сервис ненадёжной передачи данных без предварительного установления логического соединения. ТСР не учитывает границы сообщений приложения и рассматривает любую их последовательность как байтовый поток, упаковываемый им в сегменты; приложениям TCP предоставляет сервис надежной передачи. Надежность передачи данных протоколом ТСР обеспечивается: a. выполняемым в фазе установления соединения согласованием режимов и параметров функционирования передающего и приёмного модулей на взаимодействующих узлах; b. защитой сегментов контрольными суммами, учитывающих кроме содержания TCP-сегмента и адреса сокетов соединения; c. автоматической повторной передачей утерянных и испорченных сегментов; применяются процедуры ARQ_GBN и ARQ_SR; 489 d. регулированием интенсивности передачи сегментов с учётом текущей загруженности сети и состояния приёмного буфера приложения. Регулирование интенсивности передачи данных протоколом TCP выполняется на основании сигналов обратной связи от сети, – превышение времени ожидания подтверждения приёма, дубликатные ACK, флаги ECN, и явного сигнала от приёмного узла (WA ). Исполнительным механизмом регулирования интенсивности потока сегментов является окно передачи, изменяющееся в соответствии с алгоритмами Tacho или Reno. Создание и поддержание работоспособности TCP-соединений требует закрепления за каждым из них определенных ресурсов узла (прежде всего – выделения памяти). Освобождение этих ресурсов выполняется в фазе закрытия соединения. 490 9 МАРШРУТИЗАЦИЯ В ИНТЕРНЕТ 9.1 Автономные системы Интернет является глобальной сетью, объединяющей громадное количество локальных, корпоративных и территориальных сетей. Каждая из таких сетей кому-то принадлежит и управляется её владельцем. Администраторы этих сетей независимы в решении вопросов их внутренней структуры, технологий канального уровня, выбора протоколов маршрутизации, обеспечивающих внутренние связи между парциальными сетями. Но, наряду с этой автономностью, принцип глобальности Интернет требует обеспечения связности любой пары узлов, каким бы сетям каждый из них не принадлежал. В условиях громадного числа входящих в Интернет сетей, их административной самостоятельности и разнообразия физических взаимосвязей решение этой задачи посредством маршрутизации на базе алгоритмов кратчайшего пути становится не только недопустимо трудоёмким, но и не удовлетворяющим политикам безопасности и административным ограничениям собственников сетей. Проблема решается на основании заложенного в исходном проекте архитектуры Интернет принципа организационной структуризации глобальной сети, выражением которого является понятие автономной системы (Autonomous System, AS). В документе RFC 827 (1982) автономная система определена как:  группа взаимосвязанных IP-сетей,  имеющих единую администрацию, которая  реализует единые правила обмена трафиком с другими автономными системами (маршрутную политику). Главное в этом определении – единство политики маршрутизации в AS. Также следует обратить внимание на отсутствие требований к внутренней организации автономной системы и на необходимость регулирования взаимодействия с другими AS только в части правил передачи/приёма пакетов. Такая высокая степень взаимной независимости автономных систем 491 способствовала быстрому росту Интернет, но, одновременно, затрудняет реализацию в нём сквозных сервисов (поддержку качества обслуживания IPпотоков, например). В AS могут входить несколько административно независимых, но использующих для доступа к Интернет услугу одного провайдера, сетей. В этом случае провайдер и осуществляет единую политику обмена трафиком с другими AS. Крупные корпоративные сети сами могут регистрироваться как отдельные AS, но реальная необходимость в этом возникает только в случае подключения такой сети к Интернет посредством услуг нескольких провайдеров, имеющих разные политики маршрутизации, недостаточно полно соответствующие политике корпоративной сети. Среди АS особое место занимают те, для которых главной и часто единственной задачей является посредничество между другими АS. Но современный Интернет не является древовидной структурой со стволом, сформированным объединением посреднических AS. Сегодня Интернет – это объединение AS с произвольной топологией связей (рис. 9.1). При этом любая AS может иметь несколько связей (multihomed) с соседними AS. АS2 АS5 АS1 АS3 АS6 АS4 Граничные маршрутизаторы AS Рисунок 9.1. Совокупность автономных систем В зависимости от своей политики маршрутизации автономная система может быть тупиковой (stub) или транзитной. В первом случае она принимает объявления маршрутов, но не ретранслируют их в другие автономные системы. Например, АS3 будет тупиковой, если, получая объявления о маршрутах от AS1 не будет объявлять их в АS4. Такая ситуация характерна для AS организаций. Напротив, транзитная AS передаёт информацию о маршрутах в другие AS и, тем самым, позволяет транзит 492 трафика через свою сетевую инфраструктуру; такой режим обычен для AS поставщиков сервиса (АS2, АS4, АS5). Регистрация и учет автономных систем ведется специальными органами Интернет: Internet Assigned Numbers Authority, Regional Internet Registry (для Европы - это RIPE, фр. Réseaux IP Européens), Local Internet Registry (локальные провайдеры, крупные корпоративные сети). Для учета и однозначной идентификации автономных систем введен специальный цифровой идентификатор (ASN); его длина до 2007 года ограничивалась 16 битами, что позволяло зарегистрировать немногим меньше 65535 АS (некоторые номера были зарезервированными). Предупреждая возникновение нехватки диапазона нумерации АS, в 2007 году был принят стандарт на 32-битные номера AS (RFC 4893), которые стали назначать с 1 января 2009 г. При этом, в RFC 4893 описан и механизм совместимости новых номеров автономных систем со старым программным обеспечением маршрутизаторов. В 2020 году число зарегистрированных AS превысило 69 000 (https://stat.lookinglass.org/). Информацию о принадлежности какойлибо IP-сети к автономной системе, равно как и описание автономных систем можно получить посредством службы Whois, которая поддерживается всеми органами регистрации сетей Интернет, в частности, региональным регистратором в Европе (RIPE). Доступ к службе возможен по адресу https://apps.db.ripe.net/search/query.html. В каждой АS, в силу их умеренных масштабов, построение маршрутов осуществляется протоколами внутренней маршрутизации (Interior Gateway Protocol, IGP), применяющими алгоритмы кратчайшего пути (БеллманаФорда, Дейкстры). В больших AS могут существовать несколько групп взаимосвязанных маршрутизаторов (зоны или области маршрутизации), внутри каждой из которых маршруты строятся независимо; метрики к внутренним сетям через граничные маршрутизаторы зоны объявляются в другие зоны и используются в них для вычисления маршрутов между сетями разных зон в дистанционно-векторном смысле. Естественно, что все 493 протоколы, выполняемые на маршрутизаторах AS, должны использовать как минимум одну общую метрику, посредством которой может вычисляться маршрут между любой парой сетей (подсетей, узлов) AS. Обмен трафиком между АS обеспечивают граничные маршрутизаторы, на которых выполняется какой-либо протокол внешней маршрутизации (Exterior Gateway Protocol, EGP). Каждая автономная система имеет, как минимум, один такой маршрутизатор, связывающий её с другой AS. Для EGP-протоколов внутреннее строение автономной системы скрыто, им интересны только адреса сетей, входящих в АS. Эту информацию им поставляют протоколы внутренней маршрутизации. Ретрансляция векторов (AS, внутренние сети) граничными маршрутизаторами автономных систем доставляет им полный состав сетей Интернет и позволяет устанавливать пути передачи трафика между любой парой узлов. Информация о достижимости сетей внешних АS EGP-протоколом транслируется модулю IGP-протокола граничного маршрутизатора. Последний распространяют её внутри автономной системы и все внутренние маршрутизаторы рассчитывают свои пути к внешним сетям. Протоколы внешней маршрутизации управляют обменом данными о входящих в AS сетях и о сетях, достижимых через транзитные AS. Принципиальное отличие внешней маршрутизации от внутренней заключается в том, что EGP-протокол при определении маршрута к целевой сети учитывает не столько значение какой-либо его метрики, сколько административные ограничения, накладываемые на обмен трафиком между автономными системами. Это обстоятельство не позволяет решать задачу внешней маршрутизации на базе алгоритмов кратчайшего пути, применяя их к графу Интернет, составленному из вершин – AS и рёбер – каналов связи между их граничными маршрутизаторами, подобно тому, как это делают на графе сети протоколы внутренней маршрутизации. Допустим, что, используя какой-либо алгоритм кратчайшего пути, был определён маршрут от АS1 к АS6, проходящий через автономные системы 1-2-5-6. Это означает 494 оптимальность пути и от АS2 до АS6 через АS5. Но в АS2 могут считать, что АS5 не является доверенной автономной системой и свой трафик предпочитают передавать по маршруту 2–4–6. Таким образом, для функционирования Интернет как целостной системы необходим протокол маршрутизации, управляющий распространением информации о достижимости сетей всех AS и реализующий выбор возможных путей доставки трафика между AS с учётом ограничений организационного, финансового и т. д. характера. В этом разделе будут рассмотрены два наиболее часто используемых IGP-протокола, – Routing Information Protocol (RIP) и Open Shortest Path First (OSPF), а также Border Gateway Protocol v.4 (BGP4), являющийся стандартом де-факто в классе протоколов внешней маршрутизации. 9.2 Протокол RIP Routing Information Protocol (RIP, RFC 1058, 1988) относится к классу протоколов внутренней маршрутизации. Для построения маршрута он использует алгоритм длины вектора расстояния Беллмана-Форда (см. раздел 7.2.3.1) и в качестве метрики - число переходов от сети-источника до сетиназначения. Даже при наличии нескольких маршрутов одинаковой минимальной длины, RIP оставляет в таблице маршрутизации только один из них (критерий отбора в этой ситуации определяется реализацией). Максимальное число переходов на любом пути ограничено пятнадцатью и сеть, маршрут к которой содержит 16 и более переходов, считается недостижимой. Для поддержания актуальности маршрутной информации протокол RIP каждые 30 секунд (таймер обновления, TUpdate) отсылает таблицу маршрутизации непосредственным соседям узла, на котором он исполняется. Учитывая возможные повреждения линий связи и потерю работоспособности маршрутизаторов, c каждой записью таблицы связывается таймер неактивности (TInactive), начальное значение которого, обычно, равно 180 секундам. Если в этом временном интервале сообщение от «соседа» Rk не 495 поступает, то длина маршрутов, для которых он являлся следующим узлом, устанавливается равной 16. То, что интервал тайм-аута выбран 180 секунд (а не 31 с), является, в частности, следствием использования протоколом RIP услуг транспортного протокола UDP (порт 520), обеспечивающего только ненадежную доставку данных; здесь справедливо считается, что отсутствие сообщений от узла в течение времени, достаточного для шести потенциально возможных попыток сообщить о себе, является убедительным подтверждением его неработоспособности. Отправляя свою маршрутную таблицу соседям, протокол увеличивает на единицу значения количества переходов во всех представленных в ней записях (учитывается один переход до соседа). При получении этой информации модули RIP соседних маршрутизаторов обновляют свои таблицы с соблюдением следующих правил:  запись добавляется, если получена информация о ранее неизвестной сети;  запись корректируется, если полученная информация позволяет построить маршрут с меньшим числом переходов до целевой сети или в объявлении, полученном от узла NH (Next Hop), указано новое (пусть и большее) значение расстояния до целевой сети. В условиях динамической сетевой топологии возникают интервалы времени, когда маршрутная информация оказывается некорректной (период сходимости алгоритма). Длительность этого переходного состояния таблиц является конечной, но далеко не всегда малой. Медленная сходимость алгоритма Беллмана-Форда имеет следующие негативные последствия:  увеличение трафика служебных сообщений в сети,  возможность образование петель маршрутизации,  увеличение трафика в сети вследствие неоптимальной маршрутизации. Для ускорения сходимости алгоритма Беллмана-Форда в протоколе RIP используются несколько дополнительных процедур. В их числе:  ассиметричные объявления (Split horizon); 496  ложной неудачи (Poison reverse);  быстрое обновление (Triggered Update);  временный отказ от приема обновлений. Первый две процедуры были рассмотрены в разделе 7.2.3.1. Быстрое обновление и пауза в их приёме связаны с распределенным характером алгоритма Беллмана-Форда и зависимостью длительности пересчета таблиц от стратегии рассылки сообщений об обновлениях маршрутов. Рассылка может быть периодической (по истечению таймера обновления) и/или событийной (Triggered Update). В последнем случае, при обнаружении изменения значения метрики какого-то маршрута, обновление с данными этого маршрута (а не вся таблица) посылается немедленно. Но триггерная рассылка маршрутных таблиц способна породить резкий всплеск служебного трафика в сети, что предотвращается случайной задержкой отправки таких обновлений на 1 - 5 сек. Однако, даже механизм немедленной рассылки не исключает возможность получения неверной информации от других маршрутизаторов, еще не «знающих» о возникшей недостижимости целевой сети по рассчитанным ранее маршрутам и отправляющих уже некорректные данные. Одно из решений этой проблемы заключается в применении таймера временного отказа от обновления определённых записей в таблице маршрутизации. Этот таймер запускается сразу после отправки маршрутизатором Ri экстренного обновления маршрута Mk. До истечения этого таймера обновление Mk на основании данных, поступающих от «соседей», маршрутизатором Ri не производится. Запись в таблице маршрутизации может находиться в одном из двух возможных состояний: Up (актуальная) и Garbage Collection (подготовка к удалению недействительной записи). В реализациях протокола ряда ведущих производителей введено ещё состояние Hold–Down (удержание недействительного маршрута). Диаграмма состояний записи представлена на рис. 9.2. 497 Таймер THD = 0 И есть новый NH Таймер THD = 0 И нет нового NH THD > 0 И от NH-марш. получено обновление с метрикой < 16 Таймер Tinactiv= 0 GC Up HD Таймер TGC = 0 Маршрут удален Получено обновление с метрикой < 16 От NH-маршрутизатора получено обновление с метрикой = 16 Рисунок 9.2. Диаграмма состояний записи о маршруте В состоянии Up находится запись о маршруте, длина которого меньше 16 переходов и время, прошедшее с момента последнего обновления, меньше времени тайм-аута неактивности (Tinactive ≤ 180 с). Hold–Down (HD) – это состояние, в которое переводится запись после получения от маршрутизатора, указанного в ней как NH (Next Hop), информации о том, что расстояние до целевой сети стало равным 16. Маршрутные записи в состоянии HD будет включаться в рассылаемые обновления с метрикой 16. Длительность состояния Hold–Down определяется специальным таймером THD (от четырёх до шести интервалов обновления). Информация о маршруте к данной сети, получаемая от других маршрутизаторов в течение времени таймера THD, игнорируется (она может отражать уже неактуальное состояние, которое её отправителю пока представляется верным). Если до истечения таймера Hold–Down от «соседа», указанного как NH, будет получено обновление этого маршрута с расстоянием меньше 16, то эта запись вновь перейдет в состояние Up. Если к моменту завершения времени таймера THD от других маршрутизаторов будет получена информация о маршруте к той же сети, то запись с модифицированным полем NH перейдёт в состояние 498 Up, в противном случае она поступит на удаление (перейдёт в состояние Garbage Collection). Состояние Garbage Collection устанавливается для всякой записи, время жизни которой истекло. Таймер этого состояния (таймер удаления записи, TGC=) равен двухкратному интервалу обновления (60 с). В этом состоянии запись включается во все рассылаемые обновления с метрикой равной 16, что приводит к переводу маршрутов к указанной в нём сети через данный узел в таблицах других маршрутизаторов в состояние Hold–Down. По истечению времени таймера TGC запись из таблицы маршрутизации удаляется. Если до истечения этого таймера будет получена информация о маршруте к этой сети с расстоянием, меньше 16, то запись перейдет в актуальное состояние, а таймер удаления ее будет обнулен. В уровневой иерархии модели ВОС протокол RIP, как и все протоколы маршрутизации, следует отнести к прикладному уровню, поскольку он решает вполне определённую прикладную задачу. Его сообщения переносятся в сегментах транспортного протокола UDP. Сообщения состоят из 32 битного заголовка и следующего за ним списка достижимых сетей (рис. 9.3). 8 Команда 16 Версия 31 Ноль (Автономная система в v.2) Ноль (Метка маршрута в v.2) Идентификатор типа адреса IP-адрес сети / узла Ноль (Маска подсети в v.2) Ноль (Следующий узел в v.2) Метрика Идентификатор типа адреса Ноль IP-адрес сети / узла . . . Рисунок 9.3. Формат RIP-сообщения Группа полей от «Идентификатор типа адреса» до поля «Метрика» могут повторяться в сообщении до 25 раз, что позволяет каждому сообщению переносить информацию о 25 маршрутах. Если таблица 499 маршрутизации содержит более 25 записей, то она будут передаваться несколькими такими сообщениями. Общий размер сообщения RIP не превышает 504 байт. Поскольку размер IP-пакета, в который включается это сообщение, не превысит 572 байта и он не будет фрагментирован на любом маршруте, то проблема упорядоченной сборки пакетов с сообщениями протокола на приемной стороне отсутствует. Так учли особенность используемого для доставки этих сообщений транспортного протокола UDP. Поля в RIP-сообщении имеют следующий смысл: «Команда»: RIP-запрос — 1, RIP-ответ — 2. RIP-запрос отправляется в период инициализации протокола или в диагностических целях; любой маршрутизатор, получив RIP-запрос обязан срочно отправить запрашиваемую информацию. «Версия»: определяет версию протокола 1, или 2. «Метка маршрута»: поле, которое используется во второй версии протокола для идентификации внешних маршрутов, информация о которых поступила от EGP-протокола. При этом, поле содержит номер AS, из которой этот внешний маршрут был получен. Сам RIP это поле не использует, но оно может быть полезным для распространения информации между EGP–узлами, находящимися в том же домене внутренней маршрутизации. «Идентификатор типа адреса»: указывает тип адреса для каждой записи; вообще говоря, RIP может использоваться для маршрутизации в сетях различных стандартов; идентификатор IP-адреса — 2. «IP-адрес»: в пакете RIP-запроса это поле содержит или ноль (запрос полной таблицы маршрутизации), или адрес сети, запись о маршруте к которой отправляющий узел хотел бы получить. В пакете RIP-ответа это поле может содержать адрес сети назначения, устройства, либо ноль, что означает маршрут по умолчанию. «Метрика»: расстояние (в количестве переходов) до сети назначения. 500 Отметим, что RIP v1 является типичным классовым протоколом – в заголовке его сообщений нет информации о маске сети и границы адресных пространств сетей он определяет по их «классовому» признаку. Применение этого протокола в распределённых сетях с трехуровневой адресной иерархией невозможно вследствие эффекта автосуммирования маршрутов к подсетям, объявленных соседями (рис. 9.4). 10.1.0.0/16 R1 10.2.0.0/16 172.12.2.0/24 172.12.1.0/24 R2 R3 Рисунок 9.4. Автосуммирование маршрутов протоколом RIP v1 Здесь маршрутизатор R2, получив информацию о подсети 10.2.0.0/16 и 10.1.0.0/16, зафиксирует наличие в своей таблице двух маршрутов в сеть 10.0.0.0/8 и, в конечном итоге, оставит лишь один из них (пусть через R3). Соответственно, узлы сети 10.1.0.0/16 окажутся недоступными для пакетов, следующих через R2. Нулевые поля в пакетах сообщений протокола RIP v1 появились как способ обеспечения совместимости его стандартной версии с более ранними «фирменными» реализациями. Данные, содержащиеся в этих полях, протоколом RIP v1 игнорируются. Во вторую версию протокола (RIP v2, RFC 2453, 1998) были внесены ряд полезных и необходимых дополнений. Основными из них являются:  возможность адресации подсетей и поддержка бесклассовой маршрутизации,  возможность аутентификации источника сообщения и  групповая, а не широковещательная, рассылка RIP-сообщений. Для передачи данных аутентификации используются поля первой маршрутной записи. Если эта возможность активирована, то сообщение протокола RIPv2 может переносить не более 24 маршрутных записей. 501 Формат сегмента аутентификации сообщения протокола RIP v2 представлен на рис. 9.5. От других записей сообщения его отличает код FFFF в поле «Идентификатор типа адреса». В следующем поле указывается тип аутентификации; как правило, это аутентификация на основе пароля (тип = 2). Обычный текстовый пароль записывается в следующих четырех 32 битных полях. Отметим, что многие современные маршрутизаторы передают не текстовое значение пароля, а его хеш, полученный посредством алгоритма md5; но собственно пароли на маршрутизаторах хранятся в открытом виде. Тип аутентификации (2) Идентификатор типа адреса = FFFF Пароль (хеш MD5) Пароль (хеш MD5) Пароль (хеш MD5) Пароль (хеш MD5) Рисунок 9.5. Формат сегмента аутентификации в сообщении RIPv2 Поле заголовка RIP-сообщения «Следующий узел» содержит IP-адрес маршрутизатора–соседа, через который следует отправлять данные к указанной сети. Естественный вопрос: «А почему по умолчанию не использовать в качестве этого узла маршрутизатор, отправивший объявление с лучшей метрикой?» Обычно так и происходит, но существуют ситуации, когда отправитель обновления «знает», что к данной сети лучше отправлять пакеты к другому маршрутизатору, находящемуся с ним в одной сети, о чем он и информирует получателей своих сообщений. С целью экономии ресурсов сетевых узлов в широковещательных сетях RIP v2 стал применять групповую адресацию (224.0.0.9). Несмотря на перечисленные улучшения, протокол RIP остается инструментом внутренней маршрутизации для небольших автономных систем и их доменов маршрутизации. Наряду с несомненным достоинством простоты реализации, его неустранимыми недостатками являются:  отсутствие поддержки маршрутов с числом переходов более 15;  применение единственной метрики длин путей (число переходов), т. е. протокол не может поддержать требования качества обслуживания пакетов; 502  высокий уровень служебного трафика;  относительно медленная сходимость алгоритма вычисления маршрута;  отсутствие механизма балансировки сетевой нагрузки. Указанные недостатки в значительной мере преодолены в более позднем протоколе внутренней маршрутизации OSPF. 9.3 Протокол OSPF Протокол Open Shortest Path First является протоколом внутренней маршрутизации. Заметим, что определение «Open» в его названии отражает открытость спецификации протокола (RFC 1247, 1991 и RFC 2178, 1998 – OSPF v.2; RFC 2740, 1999 – OSPF v.3). Словосочетание «Shortest Path First» отражает применение алгоритма Дейкстры (алгоритм SPF) для расчёта таблицы маршрутизации. В отличие от протокола RIP, в котором каждый маршрутизатор «знает» о топологии сети AS лишь то, что он связан с некоторым числом его непосредственных топологической соседей, протокол информацией (ID OSPF обеспечивает маршрутизаторов, обмен описание их интерфейсов и непосредственно подключенных сетей) между всеми маршрутизаторами сети AS. Это позволяет каждому из них построить граф сети и выполнить расчёт маршрутов самостоятельно, без обмена сообщениями с другими узлами. В результате, общий объем служебного трафика и время генерации маршрутных таблиц, в сравнении с RIP, заметно сокращаются, что позволяет протоколу OSPF работать в больших сетях. В целом, протокол OSPF свободен от многих недостатков RIP и обладает следующими достоинствами.  Возможность использования более совершенных, чем число переходов, метрик маршрутов, в частности, пропускной способности линии связи; «стоимость» маршрутов может варьироваться в пределах (0 – 65535).  Хорошая масштабируемость, основой которой является высокая сходимость алгоритма Дейкстры и возможность организации двухуровневой топологической структуры автономной системы OSPF. 503  Возможность поддержки нескольких маршрутов между одной и той же парой сетей (узлов) для потоков пакетов, отличающихся требованиями качества обслуживания.  Способность балансировки загрузки сетевых путей, достигаемой направлением трафика одновременно по нескольким путям одинаковой «стоимости». Протокол решает свои задачи в пределах объединения сетей, образующих автономную систему OSPF. 9.3.1 Структура автономной системы OSPF Автономная система OSPF, как правило, совпадает с AS Интернет. Для улучшения свойств масштабируемости в OSPF предусмотрена возможность деления автономной системы на произвольное число зон (рис. 9.6), связь между которыми обеспечивается базовой зоной (backbone area). В отличие от AS Интернет, в разных группах сетей которой возможно применение разных протоколов внутренней маршрутизации (важно лишь использование ими общей метрики), во всех зонах автономной системы OSPF должен использоваться одноимённый протокол. Обычно, область (зона) OSPF представляет собой логически самостоятельную часть автономной системы - это может быть сеть крупного корпуса, подразделения, организации и т. п. Каждой области OSPF присваивается 32-битный идентификатор; базовая область имеет ID = 0.0.0.0. В двухуровневой структуре автономной системе OSPF определены четыре типа маршрутизаторов. 1. Внутренний маршрутизатор – все его порты подключены к сетям, принадлежащим одной зоне. Для AS, представленной на рис. 9.6, внутренними являются маршрутизаторы М1, М2, М7, М8, М10. 2. Граничный маршрутизатор зоны – узел, имеющий интерфейсы связи с сетями, разных сетевых зон (М3, М6, М9, М11 на рис. 9.6). 3. Магистральный маршрутизатор – узел, имеющий, по крайней мере, один интерфейс в сети базовой зоны. 504 4. Граничный маршрутизатор автономной системы – узел, обеспечивающий связь с другими автономными системами (М6). К другой AS М1 С1 С6 IDA=0.0.0.0 С2 М6 М3 М4 М2 М7 С4 М5 С3 IDA=0.0.0.2 М11 М9 IDA=0.0.0.1 С5 М8 IDA=0.0.0.3 Ci – сеть Мj – маршрутизатор IDA – идентификатор зоны С7 С8 М10 Рисунок 9.6. Двухуровневая структура автономной системы OSPF Очевидно, что граничные маршрутизаторы зон и кроме AS организации внутризонной маршрутизации выполняют функции межзонного обмена маршрутами и организации связи с внешними AS. Поэтому они должны обеспечиваться значительными ресурсами (память, производительность процессора) для хранения и обработки топологической информации двух (одной из внутренних и базовой) сетевых областей. Важную роль в описании механизмов OSPF играет понятие соседних маршрутизаторов. Соседними называют маршрутизаторы, имеющие интерфейсы в одной и той же сети. В структуре AS OSPF на рис. 9.6 соседними являются маршрутизаторы М1, М2 и М3, поскольку все они имеют интерфейсы в сети С2. Только соседние маршрутизаторы обмениваются топологической информацией (находятся в состоянии смежности). Вместе с тем, отношения смежности не обязательно устанавливаются между всеми соседями. Так, к сети, построенной на каналах с множественным доступом, могут быть подключены несколько (n) маршрутизаторов. Все они являются соседями и, в общем случае, должны передавать друг другу свою топологическую информацию, что создает n(n-1)/2 двунаправленных связей в 505 графе сети. С ростом n число этих связей и, соответственно, объем служебного трафика увеличивается пропорционально n2, что ограничивает масштабируемость сети. Это ограничение ослабляется посредством организации обмена информацией всех соседних маршрутизаторов в сети с множественным доступом только с одним из соседей – назначенным маршрутизатором (Designated Router, DR). Все соседи сообщают свою топологическую информацию только этому устройству и получают от него аналогичные сведения об известных ему сетевых объектах и связях. При этом общее число логических связей в графе сети уменьшается до (n  1) , соответственно уменьшается и объем служебного трафика протокола. Реализация описанной схемы не вызывает проблем в сетях с множественным доступом, поддерживающих широковещательную и групповую адресацию (например, Ethernet, FDDI). В сетях с множественным доступом без широковещания (ATM, например) определение назначенного маршрутизатора несколько сложнее, но также реализуемо. Описание внутренней структуры области (зоны) её граничными маршрутизаторами в другие зоны не передаётся, а информация о достижимости сетей области транслируется в базовую зону в дистанционновекторной форме. При этом, IP-сети зоны, по возможности, суммируются посредством объявления сетевого префикса с максимально короткой маской, а «стоимость» маршрута к ним устанавливается равной минимальной из стоимостей путей до просуммированных сетей. Зонная организация автономной системы позволяет существенно сократить объем служебного трафика и уменьшить размер таблиц маршрутизации, но она требует от протокола OSPF поддержки двух типов маршрутизации – внутризонной и межзонной. 9.3.2 Функционирование протокола Протокол OSPF не содержит алгоритмов расчёта «стоимости» линий – это забота административного процесса, который каждому интерфейсу маршрутизатора назначает определенную 506 «стоимость», возможно, в нескольких метриках. Функционирование протокола OSPF, в его основных чертах, может быть описано следующим образом. Маршрутизаторы «следят» за состоянием своих интерфейсов и «знают» адреса непосредственно присоединённых к ним сетей. Значения параметров, характеризующих каждый такой объект (интерфейс, сеть) записываются в специальную структуру данных Link State (LS). Совокупность записей (объектов) LS формирует базу топологической информации узла. Каждый внутренний маршрутизатор зоны определяет своих соседей и посредством рассылки сообщений с записями LS (сообщения Link State Advertisement, LSA) «делится» с соседями известной ему топологической информацией. Благодаря этому обмену каждый маршрутизатор получает полную информацию о наличии других маршрутизаторов, их связях и сетях зоны, к которой он принадлежит. Граничные маршрутизаторы зон для обеспечения межзонного обмена информацией должны располагать сведениями и о структуре базовой зоны. В базовую область ими передаются LSA специального типа, содержащие дистанционно–векторную информацию о внутренней области (список сетей зоны и расстояний до них). Эти сведения каждый граничный маршрутизатор транслирует внутренним маршрутизаторам зоны для расчета ими путей к сетям других зон. Граничный маршрутизатор AS распространяет информацию о всех известных ему сетях других AS (он получает её от протокола внешней маршрутизации), в том числе и о маршруте по умолчанию. Эта информация внутри AS распространяется без всяких изменений. OSPF для внешних маршрутов поддерживает метрики двух типов. Метрика первого типа совпадает с метрикой по умолчанию, используемой внутри AS. При отсутствии данных о «стоимости» внешних маршрутов в такой метрике, им назначаются стоимости, превосходящие внутренних маршрутов AS. 507 максимальную стоимость В конечном итоге, все маршрутизаторы формируют полную топологическую карту зоны, получают данные о достижимости сетей других зон своей и внешних автономных систем. На основании этой информации каждый маршрутизатор, считая себя корнем графа сети зоны, по алгоритму Дейкстры формирует дерево кратчайших путей ко всем её сетям. Таких деревьев и таблиц маршрутизации может быть построено столько, сколько метрик «стоимости» линий используются в области. Стоимости внезоновых маршрутов определяются суммированием стоимости внутризоновых со стоимостью межзоновых и внешних путей. 9.3.3 Основные операции протокола OSPF и его сообщения Протокол OSPF может работать:  в сетях двухточечных соединений интерфейсов маршрутизаторов и  в сетях с множественным доступом, все маршрутизаторы которых могут «общаться» непосредственно (например, в сетях Ethernet). 16 8 Версия 31 Тип Размер сообщения OSPF Тип аутентификации З А Г О Л О В О К Id маршрутизатора Id области Контрольная сумма Аутентификация Аутентификация Данные OSPF сообщение . . . Рисунок 9.7. Формат OSPF-сообщения В отличие от протокола RIP, OSPF не использует услугу транспортного уровня, и свои сообщения (рис. 9.7) передаёт непосредственно IP-модулю. В заголовках IP-пакетов с этими сообщениями в поле «Тип» записывается код 89, а адресом назначения их в сетях, поддерживающих групповую адресации, OSPF-маршрутизаторы»), указывается либо адрес 224.0.0.6 224.0.0.5 (группа (группа «Все назначенных маршрутизаторов). В сетях, не поддерживающих групповую адресацию, пакеты с OSPF-сообщениями адресуются на уникальные (unicast) IP-адреса 508 интерфейсов маршрутизаторов. Формат OSPF-сообщения представлен на рис. 9.7, а значения полей его заголовка определены в таблице 9.1. Поля заголовка OSPF-сообщения Поле Версия Тип Размер сообщения Id маршрутизатора Id области Контрольная сумма Тип аутентификации Поля аутентификации Таблица 9.1 Описание поля Версия протокола OSPF; текущая версия 2 (IPv4) и 3 (IPv6). Код типа пакета, 1÷5: Hello (1), Database Description (2), и т. д. Размер в байтах, включая заголовок. Идентифицирует отправителя; обычно устанавливается равным IP-адресу одного из интерфейсов (лучше, логического loopback). Идентификатор зоны OSPF Защищает весь пакет. 2 – с шифрованием пароля, 1 – простая; 0 – без аутентификации. Содержит пароль (8 символов) аутентификации или его хеш. Содержимое поля «OSPF-сообщение» зависит от типа сообщения. Существуют пять их типов: Hello, Database Description, Link–state Request, Link–state Update и Link–state ACK. Сообщения каждого из перечисленных типов служат для реализации определенных операций протокола, основными из которых являются: - обнаружение соседей и выбор назначенного маршрутизатора; - начальная синхронизация структур баз топологической информации (формирование отношений смежности); - обмен экземплярами LS, поддержание актуальности записей топологических БД; - построение минимального дерева графа сети зоны, вычисление маршрутов. Обнаружение соседей и выбор назначенного маршрутизатора Эта задача решается рассылкой OSPF-сообщений «Hello» (поле «Тип» = 1 в общем заголовке OSPF) с групповым адресом назначения 224.0.0.5 и TTL = 1 в переносящих их IP-пакетах. Соответственно, их получают только маршрутизаторы, находящиеся в том же канальном сегменте сети, что и отправитель. Структура сообщения Hello представлена на рис. 9.8, а смысловое содержание его полей приведено в таблице 9.2. 509 16 24 31 Основной заголовок OSPF, 24 байта Маска сети Опции Hello-интервал Приоритет Время жизни Назначенный маршрутизатор (DR) Резервный назначенный маршрутизатор (BDR) Сосед 1 . . . Сосед N Рисунок 9.8. Формат сообщения Hello Поля сообщения Hello Таблица 9.2 Поле Описание поля Маска Hello-интервал Опции Приоритет Время жизни, с DR BDR Соседи Сетевая маска логического сетевого интерфейса, посредством которого этот пакет был отправлен. Период (в секундах) рассылки пакетов Hello (10 сек.) Особые возможности, поддерживаемые маршрутизатором Используется для выбора DR и BDR. Если это поле установлено в нуль, то маршрутизатор никогда не будет выбран DR или BDR Интервал, в течение которого информация маршрутизатора, переставшего рассылать пакеты Hello, будет считаться актуальной (обычно 40 с). Адрес назначенного маршрутизатора. Значение 0.0.0.0 означает его отсутствие в сети. Адрес резервного назначенного маршрутизатора. Поля содержат Id-маршрутизаторов, от которых были получены пакеты Hello, и записи о которых к моменту отправки данного сообщения актуальны. Для поддержания актуальности данных о взаимосвязях в зоне, сообщения Hello рассылаются маршрутизаторами через все свои интерфейсы каждые 10 секунд. Интерфейс маршрутизатора-соседа, получив такое сообщение, отвечает на него своим пакетом Hello, в котором указывает Id всех известных ему соседей. Отправив первое Hello-сообщение интерфейс переходит в состояние инициализации, а получив ответное Hello, содержащее среди прочих и его собственный идентификатор, он приобретает состояние «two-way», фиксируя двухстороннюю связь с соседом. Маршрутизаторы приобретают логический статус соседей, если у них есть 510 интерфейсы, принадлежащие одной сети, и в их Hello-сообщениях совпадают значения полей: маска, Id области, Hello-интервал, время жизни, тип аутентификации. Выше отмечалось, что в сетях с множественным доступом объем служебной информации протокола может быть уменьшен посредством выбора назначенного маршрутизатора. Для проведения такого выбора средствами протокола Hello служит поле «Приоритет», содержащее число из диапазона от нуля до 255. Сосед, у которого это поле имеет наибольшее значение, становится назначенным маршрутизатором (DR), а тот, у которого значение этого поля ближайшее к наибольшему, приобретает статус резервного назначенного маршрутизатора (Backup Designated Router, BDR). Отношения смежности устанавливаются между соседями, связанными линиями «точка-точка», а также между назначенным маршрутизатором и его соседями в сетях с множественным доступом. Начальная синхронизация структур баз топологической информации Установление отношений смежности для маршрутизаторов заключается в синхронизации структур (не содержания!) их баз данных топологической информации. Каждый маршрутизатор отправляет серию сообщений типа 2, содержащих имена объектов (каналов в терминологии OSPF), описанных в его топологической базе. Получая такие сообщения, маршрутизатор может сравнить перечень объектов, данными о которых располагают его «смежники», со своими данными. В результате, маршрутизатор формирует список объектов, сведения о которых в его базе топологической информации отсутствуют или устарели. Важно, что этот список содержит адреса соседей, у которых следует запросить отсутствующие и более «свежие» сведения. Описанная процедура реализуется внутренним OSPF-протоколом Exchange. Его работу можно разделить на два этапа. На первом этапе определяются роли (ведущий/ведомый, сервер/клиент) соседей, синхронизирующих свои базы. На втором этапе ведущим маршрутизатором 511 производится отправка описания базы данных (Database Description Packet DDP), являющихся пакетами OSPF типа 2 и содержащих заголовки экземпляров LS из его топологической базы. Формат пакета DDP представлен на рис. 9.9, а смысл его полей – в таблице 9.3. 16 24 31 Основной заголовок OSPF, 24 байта Опции MTU-интерфейса Нуль I M MS Порядковый номер пакета DDP Заголовок описания объекта (LSA Header) J, 20 байт Заголовок описания объекта (LSA Header) I, 20 байт . . . Заголовок описания объекта (LSA Header) N, 20 байт Рисунок 9.9. Сообщение описания структуры топологической базы Описание структуры большой базы данных может пересылаться по частям, т. е. несколькими пакетами DDP; для различения начального и последующих пактов одного описания используются биты I и М в их заголовках. Поля сообщения DDP Таблица 9.3 Поле Описание поля MTU интерфейса Максимальный размер IP-пакета, который можно отправить с соответствующего интерфейса без фрагментации. Опции Особые возможности, поддерживаемые маршрутизатором. I-бит Устанавливается в 1, если пакет является первым последовательности пакетов описания топологической базы M-бит Устанавливается в 1, если пакет не является последним в последовательности пакетов описания топологической базы MS-бит Бит Master/Slave. Устанавливается в 1, если маршрутизатор выполняет роль сервера в процессе обмена топологической информацией. Порядковый номер DDP Последовательная нумерация пакетов правильного различения их приемником. LSA Headers Заголовок LSA; описан ниже. DDP необходима в для Узел, получающий эти сообщения, подтверждает каждое из них; ведущий маршрутизатор не отправляет следующую порцию описаний до 512 получения подтверждения предыдущего сообщения (SW ARQ). Эти подтверждения представляют собой сообщения того же типа, содержащие описание структуры топологической базы ведомого маршрутизатора. Порядковый номер сообщения-подтверждения равен номеру подтверждаемого сообщения, биты I и MS нулевые, бит М = 1 во всех сообщениях, кроме последнего. Если один из маршрутизаторов завершил передачу описания своей топологической базы, то он продолжает передавать пустые сообщения со сброшенным битом М (АСК-пакеты), пока другая сторона также не закончит передачу всех данных и не передаст сообщение со сброшенным битом М. Пакеты DDP содержат только описание структуры топологической базы маршрутизатора (его видения архитектуры зоны), представленное перечнем заголовков экземпляров LS. Формат заголовка экземпляра LS приведён на рис. 9.10, а смысл его полей представлен в таблице 9.4. 31 24 16 Основной заголовок OSPF, 24 байта Возраст Опции Тип LS Идентификатор объекта описания (LS ID) Маршрутизатор – источник информации Порядковый номер LS-сообщения Контрольная сумма LS сообщения Размер Рисунок 9.10. Формат заголовка сообщения LSA Получив описание структур баз топологической информации от соседей, с которыми были установлены отношения смежности, маршрутизатор формирует список объектов, записи о которых в его топологической базе устарели либо отсутствуют. В дальнейшем он отправит запросы «Link-state Request» и получит актуальные данные об этих объектах. В результате обмена пакетами Hello и DDP, т. е. по завершению обнаружения соседей и начальной синхронизации структур баз данных, каждый узел формирует таблицу смежных маршрутизаторов (например, таблица 9.5). 513 Описание полей заголовка сообщений LSA Поле Таблица 9.4 Описание Возраст, с Время, прошедшее с момента обновления данных экземпляра Опции Особые возможности, поддерживаемые маршрутизатором. Тип LS Тип описываемого объекта: 1 – внутренний маршрутизатор области (интерфейсы и соседи); 2 – все маршрутизаторы сети с множественным доступом, включая DR, и маска сети, за которую отвечает DR; 3 - сети других зон данной AS; 4 – граничный узел AS; 5 - маршрут к сетям других AS (распространяется ASBR и ретранслируется ABR). Значение этого поля определяет формат собственно сообщения LSA. Идентификатор объекта описания, LS ID В зависимости от значения поля «Тип LSA» в данном поле указывается идентификатор объекта: ID маршрутизатора (Тип = 1), IP-адрес DR (Тип = 2), IP-адрес сети за пределами области (Тип = 3), ID ASBR (Тип = 4), IP-адрес сети за пределами AS (Тип = 5). Маршрутизатористочник ID маршрутизатора-источника информации Порядковый номер сообщения Последовательная нумерация сообщений необходима для правильного различения их приемником (определение дубликатов и устаревших сообщений). Контрольная сумма сообщения Рассчитывается по всему сообщению, исключая поле «Возраст сообщения». Размер Размер сообщения LS в байтах, включая этот заголовок. Таблица смежных маршрутизаторов Таблица 9.5 Адрес соседа № порта к нему ID Состояние соседа связи 167.28.34.8 1 03D76B4A Full 1 167.28.34.2 1 03D27C47 Full 2 167.28.66.2 2 03A15E22 2-Way 1 167.28.66.9 2 03A4A4C2 2-Way 3 Приоритет Примечания BDR DR Смысл первых трех колонок таблицы 9.5. очевиден. Колонка «Состояние» содержит код одного из 8 возможных состояний связи с соседом; эти состояния определены документом RFC 1583. Например, состояние «Full» индицирует полностью 514 завершенную процедуру синхронизации баз топологической информации, состояние «2-Way» указывает, что установлено соседство и возможен двухсторонний обмен между маршрутизаторами, состояние Init – ожидается ответ на отправленное сообщение Hello. Поле «Приоритет» используется при выборе назначенного маршрутизатора и его дублера. Обновление информации о состоянии сетевых объектов Маршрутизатор, установив необходимость обновления какой-либо записи в своей топологической базе, формирует сообщение «Link-state Request» (пакет OSPF третьего типа) и отсылает его в IP-пакете по адресу смежного узла. Формат сообщения представлен на рис. 9.11. Каждый запрос специфицируется комплексным идентификатором записи LS, которую необходимо получить или обновить. Этот идентификатор является сочетанием полей: «Link-state Type» (тип объекта), «Link-state Id» (идентификатор записи) располагающего и актуальной «Advertising router» информацией); (Id эти маршрутизатора, поля надёжно идентифицируют один из заголовков LSA (таблица 9.4), собранных на предыдущем этапе. 8 16 24 31 Основной заголовок OSPF, Type=3, 24 байта Тип объекта, состояние которого запрашивается Идентификатор записи указанного объекта Маршрутизатор – источник информации ……. Рисунок 9.11. Формат запроса о состоянии объекта зоны Если число записей, подлежащих обновлению посредством обращения к топологической базе конкретного смежного маршрутизатора, оказывается большим и их запрос не может быть помещен в один OSPF-пакет, то формируются несколько таких пакетов. При этом, каждый следующий пакет-запрос посылается только после получения всех записей, запрошенных в предыдущем пакете. При отсутствии такого подтверждения в течение тайм-аута запрос посылается повторно. 515 Подтверждением приема запроса является отправка OSPF-сообщения типа 4 «Link-state Update» (Обновление состояния объекта), формат которого приведен на рис. 9.12. Это сообщение отправляется в IP-пакете с групповым адресом назначения 224.0.0.5 или 224.0.0.6, поэтому получают его маршрутизаторы только одной локальной подсети. Сообщение «Link-state Update» отправляется маршрутизатором и при обнаружении изменения состояния какого-то из его объектов. Кроме этого каждый маршрутизатор, являющийся источником записи LSA, должен отправлять сообщение «Linkstate Update» с данными о ней не реже одного раза в 30 минут (если, конечно, в этом интервале не было изменений состояния этого объекта). Это предохраняет базы маршрутной информации всех маршрутизаторов в сети от хранения устаревших и, возможно, уже неактуальных сведений. 31 Основной заголовок OSPF, Type = 4 Количество LSA в пакете LSA1 LSA2 ……. Рисунок 9.12. Формат сообщения о состоянии линии «Link-state Update» Принятое маршрутизатором сообщение «Link-state Update» подвергается анализу и, если оно содержит более «свежие» данные о какихто связях, то маршрутизатор обновляет соответствующие записи в своей топологической базе. Сообщения «Link-state Update» распространяются в AS в режиме затопления (веерной рассылки), т.е. каждый получивший это сообщение маршрутизатор отправляет его дальше через все интерфейсы, кроме того, с которого он его получил. Формат сообщений LSA Сообщение «Link-state Update» содержит информацию, извлекаемую из базы данных запрашиваемого маршрутизатора, о состоянии конкретного сетевого объекта. Как отмечалось выше (таблица 9.4), существует несколько типов сообщений LSA, которые описывают разные объекты домена OSPF. 516 LSA-сообщение типа 1 и 2 распространяются внутри зоны; описывают маршрутизаторы (их интерфейсы) и сети зоны. LS-сообщения типа 3 и 4 в сжатой форме распространяют информацию о внутризоновых и внешних маршрутах между областями AS. Сообщения типа 5 распространяют информации о маршрутах к внешним по отношению к AS сетям. Каждое из LS-сообщений состоит из заголовка (см. рис. 9.9) и тела. Сообщение типа 1, Router links advertisements (RLA), описывает интерфейсы маршрутизатора (термины канал и интерфейс здесь эквивалентны) и их «стоимости» в определённых метриках. Пакеты RLA направляются всем маршрутизаторам области, но не за ее пределы. Формат тела LS-сообщения типа 1 представлен на рис. 9.13. 8 24 16 31 Заголовок пакета описания канала (LSA Header) Нуль VE B Количество описанных каналов Нуль ID канала Тип TOS 1 Описание канала (Link Data) Метрика TOS 0 К-во TOS Нуль Метрика TOS 1 . . . TOS k Нуль Метрика TOS k ID канала Описание канала (Link Data) Тип К-во TOS Метрика TOS 0 TOS 1 Нуль Метрика TOS 1 . . . Рисунок 9.13. Сообщение описания внутреннего маршрутизатора (LS тип 1) Поля «Идентификатор канала» и «Описание канала» характеризуют объект, с которым соединен маршрутизатор посредством описываемого интерфейса. Значения этих полей зависят от поля «Тип»: Тип = 1: для 2-х точечного соединения «маршрутизатор-маршрутизатор», Тип = 2 – для соединений «маршрутизатор - транзитная сеть», Тип = 3 – для соединений «маршрутизатор - тупиковая сеть». Тип = 4 – для виртуального канала «маршрутизатор-маршрутизатор». 517 Возможные значения полей «Идентификатор канала» и «Описание канала», в зависимости от значения поля «Тип», представлены в таблице 9.6. Таблица 9.6 Тип канала Идентификатор канала Описание канала 1 ID смежного маршрутизатора IP-адрес интерфейса смежного маршрутизатора 2 ID назначенного маршрутизатора IP-адрес интерфейса назначенного маршрутизатора 3 IP-адрес сети (подсети) Маска IP-сети 4 ID смежного маршрутизатора IP-адрес интерфейса смежного маршрутизатора Поле «Количество TOS» определяет число метрик, поддерживаемых данным каналом и в поле «TOS j» указывается код OSPF типа сервиса (табл. 9.7) и в соответствующем поле – величина метрики канала. Таблица 9.7 TOS OSPF TOS IP (RFC 1349) 2 4 6 8 10 0000 0001 0010 0011 0100 0101 ... ... 16 ... 20 1000 ... 1111 LS-сообщение типа 2, Network Links Advertisement (NLA), содержит список маршрутизаторов, включая DR, подключенных к сети с множественным доступом. Формат сообщения показан на рис. 9.14. Эти сообщения распространяются назначенным маршрутизатором внутри области. 8 16 24 31 Заголовок пакета описания канала (LSA Header), 20 байт ID канала = Маска сети (адрес сети вычисляется по значению в поле "Link State ID" заголовка LSA) Описание канала (Link Data): ID маршрутизатора 1 . . . Описание канала (Link Data): ID маршрутизатора k Рисунок 9.14. Формат описания внутренних маршрутизаторов-соседей в сети с множественным доступом (LSA типа 2) По сути, сообщение этого типа заменяет сообщение типа 1. Сообщения типа 2 генерирует лишь DR и объём данных, описывающих 518 соседей, в сообщении типа 2 меньше, поскольку в этом случае расстояния между соседями равно нулю во всех метриках, соответственно, поля кодов TOS и метрик в сообщениях отсутствуют. Сводные LSA типа 3 (рис. 9.15) распространяются граничными маршрутизаторами областей и анонсируют в других областях AS информацию о внутренних сетях зон. В свою очередь, сообщения этого типа, распространяемые граничными маршрутизаторами внутри областей, содержат информацию о достижимости сетей других зон, об их граничных маршрутизаторах и о достижимости ASBR. Каждое сообщение содержит объявление только об одной IP-сети. Адрес объявляемой сети, или идентификатор ее граничного маршрутизатора, указывается в поле "Link State ID" заголовка LSA. 8 16 31 Заголовок пакета описания состояния (LSA Header) Описание канала (Link Data) – Сетевая маска Ноль Ноль Метрика TOS 0 TOS 1 Ноль Метрика TOS 1 . . . TOS k Ноль Метрика TOS k Рисунок 9.15. Формат анонсирования внутренних сетей зоны в других зонах AS (LSA тип 3) Поле «Описание канала» содержит значение маски сети. Далее следует 32-битное слово, два последних октета которого содержат маршрутную метрику по умолчанию (тип сервиса 0). Остальные 32-битные слова, объявляют метрики расстояний до объявляемой сети в других метриках (для маршрутизации по типам сервиса), аналогично LSA типа 1. Внутренний маршрутизатор, получив LSA тип 3 от пограничного маршрутизатора, не запускает процедуру перечёта своей таблицы маршрутизации, а просто увеличивает стоимость маршрута к сети, указанной в LSA, на величину стоимости рассчитанного им ранее пути к граничному маршрутизатору зоны. 519 Сообщение LSA типа 4, ASBR Summary LSA, отличается от LSA типа 3 тем, что распространяет информацию не о сети, а о пограничном маршрутизаторе автономной системы. В поле "Link State ID" заголовка LSA указывается ID ASBR Объявление маршрутов к внешним по отношению к AS узлам осуществляется посредством LS-сообщений пятого типа. Они рассылаются граничными маршрутизаторами автономной системы. Информация о каждом внешнем адресате, известном маршрутизатору, посылается независимо. Такой вид описания используется и для маршрутов по умолчанию, для которых идентификатор канала устанавливается равным 0.0.0.0 (такое же значение принимает и сетевая маска). Формат пакета сообщения рассматриваемого типа представлен на рис. 9.16. 8 24 16 31 Заголовок сообщения описания канала (LSA Header) ID канала = Маска Внешней Сети (адрес этой сети указан в поле "Link State ID" заголовка LSA) Метрика TOS 0 Ноль Ноль Адрес пересылки (Forwarding address) Метка внешнего маршрута (External Route Tag) TOS j E Ноль Метрика TOS j Адрес пересылки (Forwarding address) ….. Рисунок 9.16. Формат описания сообщения LSA тип 5 Внешние маршрутизаторы, поставляющие данные о сетях, не принадлежащих данной AS, могут использовать метрики, отличные от метрик OSPF. Значение бита E = 1 означает, что внешний маршрут измеряется в метрике, которая не совместима с метрикой OSPF; в этом случае метрика, указанная для соответствующего TOS, должна считаться больше любой метрики в OSPF-системе. Если бит Е = 0, то метрика внешнего маршрута может суммироваться с метриками внутренних маршрутов. Поле «Адрес пересылки» («Forwarding Address») содержит адрес маршрутизатора, которому следует пересылать дейтаграммы, адресованные в 520 объявляемую внешнюю сеть. Это поле используется, когда граничный маршрутизатор AS считает, что он сам не является лучшим "следующим маршрутизатором" на пути в данную внешнюю сеть. Например, в одной IPсети с ASBR находится другой маршрутизатор G, не поддерживающий протокол OSPF, а поддерживающий, например, протокол BGP; при этом, через маршрутизатор G проходит кратчайший маршрут к определенным внешним сетям. ASBR, который кроме OSPF, поддерживает и BGP, узнаёт от G об этих маршрутах и объявляет их в автономной системе, однако, с помощью «Forwarding Address» он тут же указывает, что дейтаграммы, адресованные в эти сети, лучше сразу же направлять маршрутизатору G. Если поле «Forwarding Address» обнулено, то дейтаграммы следует пересылать тому ASBR, который явился источником данного LS-сообщения. Поле используется «Метка внешнего граничным маршрута» маршрутизатором («External AS для Route целей Tag») внешней маршрутизации и модулем OSPF игнорируется. Каждое корректно принятое обновление «Link-state Update» должно быть подтвержден OSPF-сообщением типа 5 «Link-state ACK» (рис. 9.17). Получение нескольких сообщений LSA может быть подтверждено в одном IP-пакете c OSPF ACK. Основной заголовок OSPF, Type=5, 24 байта Заголовок LSA, 20 байт Рисунок 9.17. Формат пакета подтверждения «Link-state ACK» Посредством рассмотренных сообщений данные топологических баз маршрутизаторов поддерживаются в актуальном состоянии. На их основании каждый маршрутизатор самостоятельно строит граф сети и, используя алгоритм Дейкстры, рассчитывает оптимальные маршруты ко достижимым сетям. Маршрутная таблица OSPF содержит:  IP-адрес и маску сети назначения;  признак места назначения: сеть, граничный маршрутизатор и т.д.;  тип метрики: возможны маршруты для каждой из метрик TOS; 521 всем  область: идентифицирует зону AS, связь с которой ведет к цели;  тип пути: внутризонный, межзонный или внешний;  стоимость маршрута до цели;  адрес очередного маршрутизатора пути;  идентификатор объявляющего маршрутизатора: для межзонных обменов и для протокола внешней маршрутизации. В заключение отметим, что, несмотря на очевидную сложность протокола OSPF, свойства масштабирования, умеренный объем служебного трафика, возможность применения различных метрик, делают его предпочтительным выбором для внутренней маршрутизации в больших автономных системах. 9.4 Протокол внешней маршрутизации BGP 9.4.1 Назначение и функции Протокол внешней маршрутизации должен решать две взаимосвязанные задачи: 1. объявлять за пределы автономной системы существующие в ней сети (их префиксы) и принимать аналогичные объявления от других AS; 2. формировать маршруты для входящего и исходящего трафика AS с учётом организационно-административных ограничений. Для AS важны обе задачи. Но возможность объявить свои сети имеет первостепенное значение. Это делает их принципиально достижимыми из сетей других AS Интернет и обеспечивает его глобальную связность. При наличии очень большого числа AS и астрономического числа входящих в них сетей такой протокол маршрутизации должен:  не иметь принципиальных ограничений масштабирования:  отказаться от принципа кратчайшего пути;  эффективно взаимодействовать с протоколами внутренней маршрутизации;  иметь гибкую систему фильтрации принимаемых и объявляемых маршрутов; 522  иметь защиту от образования петлевых маршрутов;  обладать высокой стабильностью. Протокол BGP (Border Gateway Protocol) разрабатывался с учётом перечисленных требований; в настоящее время актуальна его четвертая версия, описанная в RFC 4271. Этот протокол:  не нуждается в информации о внутренней топологии AS и топологии её связей с остальной частью Интернет;  вместо вычисления кратчайших путей он выбирает их из ограниченного числа вариантов, удовлетворяя при этом требованиям «политик» в отношении объявляемых и принимаемых маршрутов;  благодаря функции синхронизации таблиц маршрутов на всех граничных маршрутизаторах AS он обеспечивает реализацию принципа единства маршрутной политики в пределах AS. В настоящее время BGP справляется c задачей распространения информации о более 600 тысяч сетей, входящих в состав 69 тысяч AS современного Интернета. Хорошей иллюстрацией особых свойств протокола является его способность управлять анонсируемыми и принимаемыми маршрутами. Первые определяют пути входящего трафика, а вторые – исходящего. Уникальной особенностью протокола внешней маршрутизации является сама возможность задать разные пути для трафика к сети и от неё. Протоколы внутренней маршрутизации при неизменной топологии сети определят тождественные кратчайшие пути в обоих направлениях. BGP также позволяет гибко настраивать объём объявляемой и принимаемой информации. Так, в тупиковой AS можно ограничиться приёмом от соседних AS только маршрутов по умолчанию. При необходимости, можно принимать ещё маршруты к тем внешним сетями, в которых размещены сервисы, важные для принимающей AS. Но для BGP возможен и режим Full View, когда граничный маршрутизатор получает (и объявляет) все известные ему маршруты, т. е. маршруты ко всем сетям Интернет. Конечно, полное знание возможных путей в любую сеть позволяет 523 гибко выстраивать маршруты к ним, оптимизировать использование резервных путей и т. д. Но уменьшение объёма принимаемых и объявляемых маршрутов важно для снижения требований к аппаратным ресурсам узлов, поддерживающих BGP. Кроме этого, отказ от режима Full View предохраняет протоколы внутренней маршрутизации в тупиковых AS от совершенно непомерной нагрузки обработки полного перечня путей ко всем сетям Интернет, что может быть следствием некорректной настройки правил взаимодействия IGP с BGP. Однако, для маршрутизаторов BGP в транзитных AS обработка объявлений в режиме Full View является практически неизбежной. Существуют два варианта протокола BGP:  Exterior BGP (eBGP, внешний BGP), обеспечивающий обмен маршрутной информацией между граничными маршрутизаторами разных AS, и  Interior BGP (iBGP, внутренний BGP), выполняющий синхронизацию данных на BGP-маршрутизаторах одной AS. Граничные маршрутизаторы смежных AS, прежде чем обмениваться маршрутной информацией, должны приобрести статус BGP-соседей. Поскольку это не столько технический, сколько, административный вопрос, то и «соседство» граничных маршрутизаторов задаётся явно при их конфигурировании. Заметим, что поскольку сообщения BGP передаются с применением службы TCP, то eBGP-сосед может работать на каком-либо внутреннем узле AS, откуда рассчитанная таблица маршрутизации будет передаваться на граничный маршрутизатор (режим MultiHop BGP). Следовательно, eBGP-соседям не обязательно иметь непосредственную связь на канальном уровне. Однако, обычно все функции eBGP выполняются граничными маршрутизаторами AS, которые непосредственно связаны физическими линиями. Далее будем считать, что это всегда так. iBGP является вариантом протокола BGP, созданным для обмена информацией о внешних маршрутах между всеми граничными узлам AS. В принципе, информация о маршрутах, принятая по eBGP одним из граничных 524 маршрутизаторов топологической AS (ASBR), информации может быть протокола отражена внутренней в его базе маршрутизации (например, OSPF, IS-IS) и средствами этого протокола распространена в пределах AS. Из баз протоколов внутренней маршрутизации всех других граничных маршрутизаторов AS информация о внешних маршрутах может транслироваться в маршрутные базы протокола eBGP и в их объявлениях передаться в соседние AS. Однако, при такой схеме трансляции нескольких десятков тысяч маршрутов BGP есть риск перегрузки протокола внутренней маршрутизации и потери работоспособности всей сети AS. Протокол iBGP обеспечивает более эффективное управление обменом информацией о внешних маршрутах внутри AS между её граничными узлами. Свои сообщения другим BGP-маршрутизаторами автономной системы он передаёт в IP-пакетах по маршрутам, формируемым протоколом внутренней маршрутизации (OSPF, RIP, …), работающим параллельно с ним. Применение iBGP требует:  организации логических связей между соседями iBGP по схеме «каждый с каждым»,  блокирования объявлений внутренним BGP-соседям маршрутов, полученных от других внутренних соседей,  наличия модуля iBGP на всех маршрутизаторах, обеспечивающих логические каналы между соседями. Подчеркнём ещё раз, протоколы внутренней маршрутизации и iBGP работают совместно, но каждый из них выполняет свою работу:  IGP обеспечивает внутреннюю IP-связность объединённой сети AS, оперативную реакцию на изменения в составе парциальных сетей AS; он знает перечень парциальных сетей AS, которые следует анонсировать в другие AS;  iBGP занимается только распространением внешних маршрутов в AS. Для описания маршрута BGP использует структуру, которую можно назвать вектором пути. В отличие от вектора расстояния, содержащего 525 адрес сети и расстояние до неё, вектор пути содержит адрес сети и список атрибутов, описывающих различные характеристики маршрута в целевую сеть. Каждый граничный BGP-маршрутизатор транслирует в соседние AS используемые им векторы пути к своим сетям и к сетям, для которых объявляющая AS является транзитной. Принимающие эти объявления BGP-соседи на основании политики маршрутизации своих AS и данных, содержащихся в атрибутах путей, принимают решения о возможности использования тех или иных объявляемых маршрутов. 9.4.2 Атрибуты пути В терминологии BGP маршрутом является совокупность адреса сети (сетевого префикса) и атрибутов пути. Атрибуты пути должны нести информацию, достаточную для принятия маршрутизатором-получателем решения о допустимости, с точки зрения политики его AS, объявляемого маршрута. Всего определены 3 обязательных и 4 опциональных атрибута пути. Наиболее информативным из обязательных является атрибут AS_PATH, являющийся списком идентификаторов автономных систем, через которые должен пройти пакет на пути в указанную сеть. Атрибут AS_PATH используется для:  вычисления метрики маршрута – числа транзитных АS;  применения маршрутной политики, например, если AS_PATH содержит номера неприемлемых АS, то данный маршрут не принимается;  обнаружения циклов – если номер одной и той же автономной системы встречается в AS_PATH дважды, то маршрут не используется. Анонсируя маршрут, eBGP-маршрутизатор добавляет в атрибут AS_PATH номер своей автономной системы. Такое правило нельзя применять при передаче маршрутов внутри AS, поскольку это приведёт к двукратному упоминанию её номера в анонсе пути, отправляемого граничным маршрутизатором в другую AS. Поэтому, iBGP атрибут AS_PATH не модифицирует. 526 Обязательный атрибут NEXT_HOP используется узлами BGP для определения реального выходного интерфейса и адреса ближайшего маршрутизатора, по которому следует пересылать пакеты в указанные в объявлении сети. По умолчанию, это IP-адрес интерфейса, с которого передается анонс маршрута конкретному соседу, но может быть и адресом другого маршрутизатора, имеющего интерфейс в той же сети. При ретрансляции внешнего маршрута внутренним BGP-узлам посредством объявлений iBGP атрибут NEXT_HOP сохраняется, указывая «точку выхода» из своей AS для трафика к объявляемой сети. При ретрансляции объявлений eBGP в другие AS, атрибут NEXT_HOP изменяется, указывая «точку входа» в AS для трафика объявляемой сети. Наконец, обязательный атрибут ORIGIN идентифицирует источник информации о маршруте, а его значения ранжируют эти источники по степени надёжности. Этот атрибут принимает следующие значения: 0 - информация получена от протокола внутренней маршрутизации или введена администратором; 1 - информация получена посредством протокола BGP; 2 - информация получена другим образом. Атрибут ORIGIN устанавливается маршрутизатором, который генерирует исходную информацию о маршруте, и при последующих его анонсах другими маршрутизаторами не изменяется. Таким образом, вектор пути к сети 193.20.12.0/23, объявляемый граничным маршрутизатором AS3, может иметь вид: 193.20.12.0/23 AS_PATH = AS3 AS7 AS12 NEXT_HOP = 10.10.1.2 ORIGIN = 0. В качестве примера опциональных атрибутов вектора пути приведем атрибут LOCAL_PREF. Автономная система может иметь несколько граничных маршрутизаторов и от них могут быть получены разные маршруты к какой-либо внешней сети (рис. 9.18). В этой ситуации задание значения LOCAL_PREF позволяет установить приоритет определенного 527 маршрута из числа известных внутри AS маршрутов к целевой сети (это пример взаимодействия протоколов внешней и внутренней маршрутизации). Другими словами, значением LOCAL_PREF можно задать путь исходящего трафика. Очевидно, что этот атрибут имеет смысл только в рамках одной автономной системы. Алгоритм задания значения этого атрибута определяется политикой приема маршрутов. На рис. 9.18 представлена иллюстрация использования атрибута LOCAL_PREF для определения маршрута к сети 172.10.0.0/14 внутренними маршрутизаторами AS4. Маршрут к этой сети BGP C объявил с LOCAL_PREF=150, а BGP D - с LOCAL_PREF=200. Соответственно, внутренние маршрутизаторы AS 4 примут объявление маршрутизатора BGP D. AS 3 BGP F AS 1 AS 2 172.10.0.0/14 BGP A BGP B 1.1.0.1/30 2.2.0.1/30 IGP 2 1.1.0.2/30 BGP C 2.2.0.2/30 132.2.1.2 132.2.1.3 AS 5 BGP D BGP E iBGP IGP 1 AS 4 Router C router bgp 4 neighbor 1.1.0.1 remote-as 1 neighbor 132.2.1.2 remote-as 4 bgp default local-preference 150 Router D router bgp 4 neighbor 2.2.0.1 remote-as 2 neighbor 132.2.1.3 remote-as 256 bgp default local-preference 200 Рисунок 9.18. Применение атрибута LOCAL_PREF В процессе отбора анонсированных маршрутов, в соответствии с политикой приёма маршрутов конкретной AS, им может быть назначен «административный вес» (еще один опциональный атрибут, используется только в реализации Cisco). Строго говоря, этот параметр не является 528 атрибутом пути и его можно трактовать как степень доверия к объявлениям от разных AS. Его значение является локальным в пределах маршрутизатора и не передается при анонсировании маршрутов. При наличии нескольких принятых объявлений для одной и той же сети этот параметр позволяет отдать предпочтение одному из них (с большим значением "WEIGHT"). Ещё один опциональный атрибут ATOMIC_AGGREGATE, указывает на то, что объявляемый сетевой префикс был получен объединением нескольких сетевых адресов с более длинной маской. Например, AS 300 принадлежит сеть 140.11.0.0/16; граничный маршрутизатор AS 300 (R3) анонсирует эту сеть в автономную систему AS 200, которой принадлежит сеть 140.12.0.0/16. В свою очередь, граничный маршрутизатор AS 200 (R2) может в AS 100 передать объявление о сети 140.0.0.0/8, объединяющей указанные две сети. Это объявление должно содержать параметр ATOMIC_AGGREGATE. 9.4.3 Обработка маршрутной информации Выше отмечалось, что важнейшей функцией протокола BGP является объявление им сетей своей AS. Однако, объявляются не только свои сети, но и маршруты к сетям других AS, которые могут проходить через объявляющую AS. Эти объявления – мощнейшие средства обеспечения глобальной связности Интернет, но обращаться с ними надо предельно внимательно, поскольку ошибки в объявлениях могут повлиять на работоспособность всей глобальной сети. Первая фатальная ошибка BGP – это объявление маршрутов, по которым из данной AS ХХ трафик реально не может быть доставлен в объявляемую сеть. Такие маршруты часто называют «черной дырой» и их организация является одной из форм хакинга маршрутов. Непреднамеренно это может произойти при объявлении AS ХХ некоторой части пространства адресов IP (подсети), принадлежащей другой AS ZZ, более конкретно (т. е. с более длинной маской), чем в объявлении, сделанном администратором AS ZZ. Тогда во всех AS, получающих оба эти объявления, все пакеты, предназначенные для узлов с адресами подсети из 529 диапазона AS ZZ, будут направлены на пограничный маршрутизатор AS ХХ, что надёжно отключит их от остальной части Интернет. Если таким образом объявить маршрут для серверов Instagram, то доступ к их сервисам для многих пользователей окажется невозможным. Вторая фатальная ошибка BGP – отсутствие строгой фильтрации принимаемых маршрутов. Если среди них окажутся маршруты, подобные описанному выше, и их входной отбор выполнен недостаточно строго, то передавая их далее своим BGP соседям, AS становится непреднамеренным пособником нарушения маршрутизации в Интернете. На рис. 9.19 представлена информационная схема обработки маршрутной информации протоколом eBGP. Полученные от BGP-соседей объявления, помещаются в базу данных БД-вход. Для каждого из них вычисляется значение параметра WEIGHT, учитываемое при последующем отборе маршрутов; этот параметр может получить и значение, являющееся признаком неприемлемости маршрута (например, WEIGHT=0). BGP-сосед Политика приема Политика анонсирования Фильтр Фильтр BGP-сосед BGP-сосед BGP-сосед БД-вход Локальная БД БД-выход Менеджер маршрутов Протокол внутренней маршрутизации Таблица маршрутизации Рисунок 9.19. Информационная схема обработки маршрутной информации На основании политики приема для каждого маршрута определяется значение атрибута LOCAL_PREF. Если полученное значение показывает, что маршрут является неподходящим, то он не передаётся на следующий этап процесса отбора; в противном случае это значение LOCAL_PREF должно использоваться в любом последующем анонсе iBGP. Также 530 исключаются из рассмотрения маршруты, содержащие в атрибуте AS_PATH повторяющиеся номера AS (петлевые маршруты). Очевидно, что в результате этого этапа обработки в БД-вход для одной целевой сети могут остаться несколько маршрутов. Далее, для каждой сети из оставшихся вариантов маршрутов по критериям предпочтения выбирается единственный, и информация о нем заносится в локальную базу данных, заменяя любой хранящийся в ней маршрут к сети такого же префикса. Из этой базы менеджер маршрутов берет BGP-модуля сведения для формирования своей таблицы маршрутизации. Из неё же протокол внутренний маршрутизации (OSPF, например) получает сведения о достижимых внешних сетях, которые он распространяет сообщениями внутренней к узлам (OSPF и своей тип внешней 5). автономной Важность маршрутизации системы специальными взаимодействия уже протоколов отмечалось выше и иллюстрируется схемой на рис. 9.20. АS700 OSPF Router С BGP-Router А iBGP BGP-Router B eBGP eBGP BGP-Router D 170.10.0.0 OSPF BGP-Router E АS300 АS400 Рисунок 9.20. Синхронизации таблиц маршрутизации BGP Маршрутизатор B в транзитной AS700 не сможет принять по протоколу iBGP маршрут от узла А к сети 170.10.0.0 до тех пор, пока это сообщение не будет доставлено ему по пути, определённому протоколом внутренней маршрутизации (RIP, OSPF). В свою очередь, модуль OSPF узла 531 A, выполнив импорт из таблицы BGP, распространит данные о сети 170.10.0.0 всем модулям IGP-протокола внутри AS700. Также, в локальную БД протокола BGP из таблиц протокола внутренней маршрутизации заноситься информация о сетях AS, объявление о которых в других автономных системах политика AS признаёт необходимым. Отбор из локальной БД маршрутов для анонсирования их соседям производится процедурой, учитывающей требования политики анонсирования (можно иметь разные политики для каждого соседа). Результат отбора помещается в базу БД-выход, содержимое которой рассылается BGP-соседям. Важным в этой процедуре является то, что BGPмаршрутизатор объявляет в другие AS только те маршруты, которые сам использует для передачи пакетов в соответствующие сети. 9.4.4 Маршрутные политики Протокол BGP не определяет синтаксис описания маршрутных политик, и их представления отличаются в различных реализациях протокола. В общем случае, политики включают в себя критерии отбора маршрутов и действия по модификации их атрибутов. Политика приема, т.е. отбор маршрутов из базы БД-вход, может учитывать:  принадлежность целевой сети к определенной АS;  номер АS соседа, от которого получен маршрут;  содержание атрибута AS_PATH;  происхождение маршрута (атрибут ORIGIN);  адрес сети, в которую ведет маршрут;  адрес узла, приславшего маршрут (является ли он соседом). По отношению к маршрутам, удовлетворяющим установленным требованиям к перечисленным характеристикам, политика предписывает выполнять какие-либо действия, например:  назначение административного веса,  задание значения атрибута LOCAL_PREF, 532  принятие маршрута в качестве маршрута по умолчанию. Политика должна описывать и критерии отбора, если в базе БД-вход остается несколько альтернативных маршрутов в одну целевую сеть. Список таких критериев включает в себя:  наибольший административный вес,  наибольшее значение LOCAL_PREF,  наименьшая длина атрибута AS_PATH,  наименьшее значение ORIGIN,  идентификатор (IP-адрес) соседа, от которого получен маршрут. Эти критерии применяются последовательно, в порядке их перечисления, пока не останется единственный маршрут в целевую сеть. Политика объявления маршрутов имеет своей целью повлиять на процесс отбора маршрутов, объявляемых соседям и, соответственно, на потоки входящего в AS трафика. Важно, что отбор маршрутов для анонсирования производится лишь из числа используемых в данной AS. Он может производиться по тем же критериям, что и запись в локальную БД. С маршрутами, удовлетворяющими установленным критериям, могут быть выполнены следующие действия:  фильтрация (маршрут не объявляется);  агрегирование маршрутов;  модификация AS_PATH;  замена маршрута на маршрут по умолчанию. В качестве примера ниже приведена формулировка политики внешней маршрутизации для AS 100, имеющей 2 внешних канала связи и принимающей анонсы от двух поставщиков ISP(A) и ISP(B). Политика исходящего трафика  исходящий трафик для AS 200 передаётся по каналу R1-ISP(A);  исходящий трафик для AS 400 передаётся по каналу R2-ISP(B);  весь остальной исходящий трафик должен направляться по маршруту 0.0.0.0 по каналу R1-ISP(A); 533  при неработоспособности канала R1-ISP(A) весь трафик должен проходить через канал R2-ISP(B). Политика входящего трафика  трафик к сети 10.10.10.0/24 из Интернета должен поступать по каналу ISP(A)-R1.  трафик к сети 10.10.20.0/24 из Интернета должен поступать по каналу ISP(B)-R2.  при выходя из строя любого из внешних каналов ISP-RX весь входящий трафик AS 100 должен поступать по работоспособному каналу. 9.4.5 Функционирование протокола BGP В процессе начальной конфигурации BGP-маршрутизатору присваивается номер AS, для которой он является граничным, и задаются его соседи. Протокол не располагает процедурой автоматического определения соседей (сообщения Hello не предусмотрены) и сведения о соседях (номер AS каждого соседа и его IP-адрес) задаются в явном виде. Отношения соседства могут устанавливаться как с BGP-маршрутизаторами одной AS, так и с маршрутизаторами разных AS. Соседи, принадлежащие разным АS, как правило, имеют непосредственное соединение на канальном уровне; требуемые маршруты между соседей из одной АS обеспечивает протокол внутренней маршрутизации. Маршрутная представляет передаются информация, собой по которой последовательности TCP-соединению; порт обмениваются BGP-соседи, BGP-сообщений, назначения в которые сегменте TCP-SYN = 179. Максимальный размер сообщений составляет 4096 байт, минимальный – 19 байт. Сообщения BGP несут информацию о новых маршрутах, о маршрутах, потерявших свою актуальность, о возникающих ошибках. Все BGP-сообщения имеют фиксированный заголовок (рис. 9.21). Поле «Маркер», 16 байт, до 2006 года использовалось для аутентификации входящих BGP-сообщений. В современных реализациях поле осталось для целей совместимости и заполняется единицами (RFC 4271, 2006). При этом, 534 задача защиты BGP-сообщений от подмены решается посредством включения в опциональное поле заголовка TCP-сегмента 16-байтной электронной подписи, рассчитанной алгоритмом MD5 по всему сегменту и его псевдозаголовку (RFC 2385, 1998). Значение в поле «Размер сообщения» включает в себя и 19 байт размера заголовка. BGP оперирует сообщениями четырёх типов. Сообщение OPEN (рис. 9.22) посылается после установления TCP-соединения и служит средством согласования сторонами параметров BGP-сеанса. 8 4 31 16 Маркер 16 байт Размер сообщения Тип «OPEN» Номер АС Версия Интервал мониторинга Идентификатор BGP-маршрутизатора Опции Размер опций Опции Рисунок 9.22. Формат сообщения OPEN Поле «Номер АС» идентифицирует АС, которой принадлежит маршрутизатор, отправивший это сообщение. Поле «Интервал мониторинга» (Hold time) – это максимальное время (в секундах) между сообщениями KEEPALIVE, свидетельствующими об активности соединения; значение Hold time = 0 означает, что сообщения KEEPALIVE не посылаются (мониторинг не производится). Маршрутизатор принимает для данного соединения значение Hold Time, равное минимуму из того, что он получил в сообщении OPEN, и значения, указанного в его собственной конфигурации. Если очередное сообщение KEEPALIVE не было получено в течение Hold Time секунд, соединение считается закрытым и связанная с ним маршрутная информация ликвидируется. Поле «Идентификатор BGP-маршрутизатора» содержит: либо статически заданный при конфигурировании ID, либо IP-адрес старшего из находящихся в состоянии UP loopback интерфейсов отсылающего сообщение 535 маршрутизатора, либо IP-адрес старшего из его физических интерфейсов в состоянии UP. Это значение используется для идентификации BGP маршрутизатора во всех его сообщениях, вне зависимости от того, посредством какого интерфейса он соединен с конкретным соседом. Поле «Опции» содержит перечень опциональных параметров в формате «тип, размер, значение». Один из таких параметр — «Возможности» (Capabilities), тип 2, определен в документе RFC 3392 и используется для согласования, например, приемлемость 4-байтных номеров AS, поддержки кроме IPv4 и других (IPv6, IPX,…) межсетевых протоколов, возможность динамического запроса обновления маршрутов и т. д. Для установления BGP-сеанса необходимо:  совпадение указанного в сообщении OPEN номера AS с одноимённым параметром в описании этого соседа на принимающем маршрутизаторе;  несовпадение идентификатора BGP-маршрутизатора в этом сообщении с аналогичным идентификатором принимающего узла;  совпадение версий протокола, что в настоящее время гарантированно;  взаимная приемлемость опциональных параметров. Ответом на сообщение OPEN является сообщение KEEPALIVE, если вторая сторона согласна открыть сеанс; в противном случае посылается сообщение NOTIFICATION с кодом, уточняющим причину отказа, и ТСР-соединение разрывается. Сообщение KEEPALIVE. BGP-соседи осуществляют постоянный мониторинг взаимной достижимости, для чего периодически обмениваются сообщениями KEEPALIVE. Эти сообщения содержит только BGP-заголовок (рис. 9.20). Период рассылки сообщений KEEPALIVE устанавливается равным трети интервала мониторинга, что гарантирует доставку сообщения соседу до истечения таймера указанного интервала даже в условиях переменной сетевой задержки. Сообщение NOTIFICATION. Это сообщение (рис. 9.23) отправляет BGP-маршрутизатор при обнаружении им ошибки в получаемых сообщениях 536 или как извещение о невозможности установить BGP-сессию из-за несовместимости параметров. Благодаря этому, обе стороны не тратят свои ресурсы на поддержание соответствующего TCP-соединения или на попытки повторно установить связь. Процедура закрытия BGP-сеанса также гарантирует, что обе стороны до закрытия соединения ТСР получат все сообщения об ошибках. 8 31 16 Маркер 16 байт Общий размер сообщения Тип NOTIFICAT. Данные Код ошибки Тип ошибки Данные Рисунок 9.23. Формат сообщения NOTIFICATION После отправки этого сообщения соответствующее TCP-соединение закрывается. Поля «Тип ошибки» и «Код ошибки» информируют о природе ошибки (таблица 9.8), а поле «Данные» содержит уточняющие сведения об обстоятельствах возникновения ошибки. Таблица 9.8 Тип Знач. 1 2 3 Описание Код Знач. Описание Знач. Ошибка заголовка 1 Отсутствие синхрониз. 3 Неверный тип 2 Неверный размер Ошибка сообщения OPEN 1 Неподдерживаемая версия 4 Неподдерживаемые опцион. параметры 2 Неверная АС 5 Ошибка аутентификации 3 Неверный BGP-идентификатор 6 Неприемлемое значения интервала мониторинга 1 Ошибка списка атрибутов 7 Петля в маршруте АС 2 Неопознаны атрибуты 8 Неверен NEXT_HOP 3 Ошибки обязательных атрибутов 9 Ошибки опциональных атрибутах 4 Ошибки флагов атрибутов 10 Неверный атрибут 5 Ошибочный размер атрибутов 11 Плохо сформированный AS_PATH 6 Неверен атрибут Ошибка сообщения UPDATE 537 Описание Тип Знач. 4 5 6 Код Описание Знач. Описание ORIGIN Знач. Описание Истёк интервал мониторинга Ошибка последовательности состояний протока Закрытие соединения участником Сообщение UPDATE. После установления сеанса, BGP-соседи обмениваются маршрутной информацией, которая переносится сообщениями UPDATE. Это сообщение (рис. 9.24) может объявлять один новый маршрут и (или) отменять несколько маршрутов. 31 16 Маркер 16 байт Общий размер сообщения Размер списка недействительных маршрутов Тип «UPDATE» Список недействительных маршрутов Список недействительных маршрутов (var) Размер списка атрибутов пути Список атрибутов пути Список атрибутов пути Достижимые сети Рисунок 9.24. Формат сообщения UPDATE Поля сообщения UPDATE могут содержать перечень неактуальных маршрутов, атрибуты одного нового пути и перечень достижимых посредством этого пути сетей. Как первая часть сообщения, так и две последние могут отсутствовать. Когда сообщение не несет информацию о недействительных маршрутах в поле «Размер списка недействительных маршрутов» указывается 0, а следующее поле отсутствует. Если маршруты в несколько сетей имеют одинаковые атрибуты, то они объединяются в одном 538 сообщении UPDATE. При этом адреса сетей, если возможно, агрегируются в общем сетевом префиксе. Поле «Список атрибутов пути» имеет переменную длину и описывает каждый атрибут пути в формате <Тип, Размер, Значение>. Тип атрибута занимает два байта, первый из которых – флаги, а второй код типа атрибута (рис. 9.25). OT P E Код типа атрибута Рисунок 9.25. Формат поля типа атрибута Биты O, T, P, E - флаги атрибута, а именно:  бит O = 1: атрибут обрабатывается любым BGP-процессом (такими атрибутами всегда являются ORIGIN, AS_PATH, NEXT_HOP, LOCAL_PREF, ATOMIC_AGGREGATE);  бит T = 1: атрибут транзитивный, т. е. должен передаваться при объявлении маршрута другому соседу; может быть равен 0 только для опциональных атрибутов;  бит P: имеет смысл только для опциональных транзитивных атрибутов; значение 1 свидетельствует, что какой-то из маршрутизаторов, через который передавалась эта маршрутная информация, проигнорировал его;  бит Е: если установлен в 1, то поле «Размер данных атрибута» занимает 2 байта, иначе – 1 байт. Поля «Достижимые сети» и «Список недействительных маршрутов» содержат сетевые префиксы. Для отмены маршрута достаточно указать только адрес целевой сети (префикс), по которому сосед найдет и удалит из своей базы все данные этого маршрута. В одном сообщении могут быть отменены несколько маршрутов. Объявляемый маршрут представляется префиксом сети назначения и списком атрибутов пути. Только один список атрибутов передается в каждом сообщении, но указанные атрибуты могут относиться к нескольким сетям, список которых приводится за списком атрибутов. 539 Заключение к разделу 9 Принцип глобальной связности любых конечных узлов является одним из фундаментальных свойств Интернет. Для его реализации необходима универсальная и всеобъемлющая система маршрутизации. Проблема масштабируемости этой системы решена благодаря организации глобальной сети в форме совокупности автономных систем, каждая из которых имеет относительно небольшое число ЛС и единую администрацию. При этом, в пределах каждой из AS маршруты вычисляются по критерию кратчайшего пути, а между автономными системами – формируются на основе политик. Инструментом реализации такой иерархической системы маршрутизации стала взаимно согласованная совокупность протоколов внутренней (RIP, OSPF) и внешней (BGP) маршрутизации. Протокол RIP остаётся востребованным и вполне удовлетворительным инструментом в относительно небольших объединенных сетях. Его главным преимуществом является простота реализации, а основными недостатками – плохая масштабируемость и защищенность. Вторая версия протокола (RIP v2) принципиально эти проблемы не решила. Зонирование сетей крупных автономных систем позволила протоколу OSPF сохранить принцип кратчайшего пути при расчёте маршрутов внутри AS. Важными достижениями этого протокола стал механизм компактного межзонного обмена маршрутной информацией и принципиальная возможность использования нескольких метрик при расчёте «длин» маршрутов. Астрономическое число сетей, входящих в состав Интернет, и необходимость учёта трудно формализуемых административных требований при передаче трафика между AS заставило отказаться от принципа кратчайшего пути при построении маршрутов между ними. Протокол внешней маршрутизации распространяет информацию о составе сетей своей AS, определяет приемлемость транзита трафика других AS, обеспечивает информирование протоколов внутренней маршрутизации о составе сетей 540 других AS и решает другие «политические» вопросы. Главное, этот протокол практически ничего не вычисляет, что и позволяет ему работать в масштабах всей сети Интернет. В современном Интернете протоколом внешней маршрутизации является BGP4, который в настоящее время справляется c задачей согласованного информирования 69 тысяч AS о более чем 600 тысяч сетей, входящих в их состав. Контрольные вопросы к разделу 9 1. Глобальная сеть Интернет представляет собой совокупность автономных систем. Дайте определение автономной системы. 2. Могут ли локальные сети разных организаций принадлежать одной автономной системе? 3. При каких условиях регистрация AS целесообразна? 4. Чем обосновывается необходимость иерархической организации маршрутизации в Интернет? Какие критерии построения маршрутов используют протоколы внутренней и внешней маршрутизации? 5. Есть ли необходимость использования во всех автономных системах Интернет по крайней мере одного общего протокола внутренней маршрутизации? Если да, то почему? 6. Что включают в себя маршрутные политики? 7. Какие метрики маршрута используются протоколом RIP? 8. Какие изменения внесены в RIPv2 в сравнении с RIPv1? 9. При каких условиях обновляется запись в таблице маршрутизации? 10. Какие метрики длины маршрута используются протоколом OSPF? Может ли он построить таблицы маршрутов в разных метриках? 11. Почему время расчёта маршрута протоколом RIP обычно больше, чем протоколом OSPF? 12. Как организован межзонный обмен информацией в OSPF? 13. Получая информацию о сетях других AS от протокола внешней маршрутизации, OSPF должен распространять её внутренним маршрутизаторам. Как решается вопрос о "стоимости" внешних маршрутов? 541 14. Какие меры надёжности доставки своих сообщений применяются RIP и OSPF? 15. Чем отличаются задачи и механизмы eBGP и iBGP? 16. Имеет ли право маршрутизатор BGP анонсировать маршрут, информация о котором отсутствует в его собственной таблице маршрутизации? 17. Каким образом протокол BGP предотвращает возникновение маршрутных петель? 18. Как протоколом BGP определяются пути входящего и исходящего трафика автономной системы? 19. Почему протокол BGP не использует сообщения "Hello"? 20. Получив из объявлений разных AS несколько маршрутов к одной сети, использует ли их протокол BGP принимающей AS для балансировки исходящих потоков к этой сети? 542 10 СЛУЖБА ДОМЕННЫХ ИМЁН ИНТЕРНЕТ Компьютеры в сети Интернет объединяются в логические группы не только по признаку совпадения их сетевых префиксов, но и по признаку определённой общности их имён, обращение с которыми более привычно подавляющему числу пользователей. Однако, протоколы Интернет оперируют не именами, а сетевыми адресами и между ними должно существовать определённое соответствие. Учитывая масштаб глобальной сети, система именования должна быть распределённой, но хорошо согласованной, а поиск в ней требуемой записи «имя  IP-адрес» должен выполняться очень быстро. Основой удовлетворения этих требований является иерархический принцип построения системы имён Интернет. 10.1 Иерархия пространства имён Полные имена компьютеров содержат собственно имя узла (простое имя) и имена групп (доменов), в которые он входит. Поскольку большинство доменов являются частью других, более крупных доменов, то имена конечных узлов представляются цепочкой имён доменов. В целом, система именования доменов (Domain Name System, DNS) имеет древовидную иерархическую структуру (рис. 10.1). · com edu yandex phnt hsep ru Корневой домен (root) uk scc net ⋯ spbstu tv ⋯ TLD Домены верхнего уровня SLD Домены второго уровня nLD Домены n уровня (n=3, 4, ⋯ ) ⋯ tornado.scc.spbstu.ru numa.scc.spbstu.ru ⋯ Рисунок 10.1. Иерархия системы имён Интернет 543 Узлами дерева являются имена доменов и конечных станций; они группируются по уровням включенности в вышестоящие домены. Имена доменов уровней k, k-1, ⋯, 1 являются составляющими частями абсолютного имени интернет–узла, принадлежащего домену уровня k: namenod.namek.namek-1.namek-2. ⋯ nameSLD.nameTLD. Крайняя правая точа в абсолютном имени узла является именем домена корневого (нулевого) уровня. Число символов в простом имени не должно превышать 63, число простых имён в полном имени неограниченно, но его длина не должна превышать 255 символов. В целом, домен (domain) – это часть дерева DNS с одной вершиной в именованном узле, включающая все дочерние узлы дерева на всех нижележащих уровнях. Управление этой системой имён (запись, поиск и т. п.) осуществляется специальными серверами имён. Каждый из них поддерживает определённую часть пространства имён конкретного домена; эта часть называется зоной (zone); зона получает имя домена высшего уровня этой зоны. Целью организации отдельных зон является придание всей системе именования необходимой гибкости и масштабируемости. Зону следует трактовать как «зону ответственности» за корректность описания соответствий «имя  адрес» в выделенной части именного пространства. Делегирование – это операция передачи ответственности за часть дерева доменных имен (зону) другому юридическому или физическому лицу. Это базовый механизм системы DNS, обеспечивающий её масштабируемость и согласованность содержания зон при распределенном их администрировании. Технически, делегирование заключается в выделении части именного пространства домена уровня n в отдельную зону, присвоении ей имени и размещении описания этой зоны на DNS-сервере, управляемом другим лицом или организацией. При этом, в описание родительской зоны включаются ресурсные записи, указывающие на авторитетные DNS–серверы дочерней зоны. Например, корневой домен делегирует полномочия доменам 544 первого уровня (Top Level Domain, TLD) edu, com, ru и т.д. В свою очередь, TLD делегируют полномочия управления своими дочерними зонами владельцам доменных имён второго делегирование простирается до уровня и т. д. (бывает, что 5-го уровня). Если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем дочерней зоне, в ответ будет предоставлен список DNS-серверов, которые поддерживают требуемую дочернюю зону. root ru com edu spbstu yandex Домен spbstu.ru hsep scc mail Comp1 Comp2 numa tornado Зона spbstu.ru Зона scc.spbstu.ru Рисунок 10.2. К определению домена и зоны DNS Различие между зоной и доменом иллюстрирует следующий пример (рис. 10.2). Домен spbstu.ru включает имена всех компьютеров в политехническом университете, в то время как зона spbstu.ru включает только те имена, которые определённы непосредственно на сервере имён этой зоны (например, mail.spbstu.ru или comp2.hsep.spbstu.ru). В то же время, имена сетевых узлов суперкомпьютерного центра университета принадлежат зоне scс.spbstu.ru, которая была делегирована Центру и на сервере DNS которой они зарегистрированы. Соответственно, компьютер numa Центра будет иметь имя numa.scс.spbstu.ru, которое не принадлежит зоне spbstu.ru, но входит в домен spbstu.ru. 545 10.2 Корневая зона DNS Зону root мировой системы DNS поддерживают 13 серверов: A.ROOT-SERVERS.NET.; B.ROOT-SERVERS.NET.; ⋯ M.ROOT-SERVERS.NET. Надёжность и доступность сервиса зоны обеспечивается размещением её описания на множестве серверов-зеркал (рис. 10.3), рассредоточенных по всему миру; на декабрь 2020 года функционируют 1345 таких серверов. Рисунок 10.3. География системы корневых серверов Описание корневой зоны 10.2.1 Каждый корневой сервер (КС) содержит информацию о всех серверах имён доменов первого уровня (ru, net, org, …). Их адреса содержатся в файле named.root, публикуемом на сайте ftp://ftp.internic.net/domain/named.root. Файл включает информацию, необходимую для инициализации каждого сервера доменных имен Интернета, и его копия обязательно размещается в одном из их каталогов. Фрагмент этого файла приведён ниже. ; ; ; ; ; ; ; ; This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache . " configuration file of BIND domain name servers). This file is made available by InterNIC under anonymous FTP as file /domain/named.cache; 546 on server FTP.INTERNIC.NET ; -ORRS.INTERNIC.NET ; ; last update: December 05, 2019 ; related version of root zone: 2019120501 ; ; FORMERLY NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30 ; ; FORMERLY NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201 B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b ; 10.2.2 Управление корневой зоной В зоне root существует «скрытый» мастер-сервер и 13 публичных равноправных КС, получающих идентичные копии описания корневой зоны от мастера. Корневые серверы управляется организациями-операторами (всего их 12). В их число входят университеты, государственные структуры (NASA), IT-компании, некоммерческие ассоциации; их полный список можно найти на сайте http://www.root-servers.org. Операторы финансово и юридически независимыми как взаимно, так и в отношении ICANN/IANA (Internet Corporation for Assigned Names and Numbers, Internet технологических Assigned решений Numbers они Authority). руководствуются При их принятии технической целесообразностью и существующими стандартами. Примером такого серьёзного решения, принятого самостоятельно оператором сервера f.root-servers.net (компания ISC), является переход к технологии anycast для адресации своих зеркалирующих серверов. Это решение не было регламентировано ICANN или каким-либо из её Советов, но оно прошло 547 тщательную экспертную проверку и впоследствии стало применяться и другими операторами. Вместе с тем, внесения изменений в процедуры сопровождения корневых серверов обусловлено строгим регламентом, предусматривающем участие операторов, администратора корневой зоны (в настоящее время, это некоммерческая организация Public Technical Identifiers, PTI), IANA и ICANN, являющейся аудитором корневой зоны (рис. 10.4). Рисунок 10.4. Схема принятия решений о внесении изменений в корневую зону Типичным примером запроса оператора корневого сервера является предложение об изменении состава зеркалирующих серверов. После обработки запроса IANA (проверка его обоснованности, оценка возможных последствий реализации и других содержательных аспектов) он направляется для авторизации Аудитору и далее передаётся организации, ответственной за фактическое редактирование и публикацию зоны в DNS. Эту задачу выполняет компания VeriSign. Обновлённая редакция файла описания корневой зоны вначале публикуется на скрытом мастер-сервере и затем распространяется на все 13 рабочих серверов. 548 Следует отметить, что правительство США играло довольно значительную роль в управлении Интернет вплоть до середины 2010 годов. Но в 2016 году, по крайней мере формально, оно полностью вышло из этого проекта, передав все ранее принадлежащие ему функции общественным организациям ICANNA, IANA и IETF. В сочетании с независимостью операторов КС это является основой технической и политической стабильности системы DNS в целом, исключает возможность узурпации управления корневой зоной какой-либо из сторон, участвующей в поддержании её функционирования. 10.3 Описание зоны DNS Описания зон на серверах DNS разных производителей несколько различаются синтаксисом и форматами. Ниже приводятся примеры, следующие спецификации сервера BIND версии 9 (разработчик – ISC, Internet System Consortium Inc.). В файле конфигурации DNS сервера named.conf задаётся мета–описание зон (имя, тип, глобальные атрибуты). Два примера таких описаний приведены ниже. zone "." // зона указателей на корневые серверы { type hint; file "db.root"; }; Зона указателей на корневые серверы типа hint нужна для начального заполнения кэша сервера BIND IP-адресами корневых серверов. Содержание файла db.root (возможны и другие его названия) приведено выше. zone "sstu.ru" //доменное имя корневого узла зоны уровня n { type master;// возможны типы "slave", "forward"… file "/etс/bind/db.sstu.ru "; //файл описания зоны allow-transfer {193.108.251.254;}; //узел, на который разрешено передавать зону notify yes; //все вторичные DNS серверы получат извещение при изменении зоны }. 549 Эти записи говорят, что для зоны sstu.ru данный сервер будет основным (master), описание зоны хранится в файле /etс/bind/db.sstu.ru и вторичный сервер зоны располагается на узле с адресом 193.108.251.254. Записи в файлах описания зоны DNS имеют общий формат: [имя] [TTL] [класс] <тип> <данные> Параметр имя Заканчивающееся может точкой принимать имя любое считается символьное абсолютным значение. (полностью определённым), иначе после него добавляется имя зоны; последнее может быть задано:  директивой zone в конфигурационном файле (named),  директивой $ORIGIN непосредственно в файле описания зоны, например, директива $ORIGIN scc.sspu.ru. переопределяет имя зоны по умолчанию sspu.ru на scc.sspu.ru. Символ «@» является указателем на текущее имя зоны. Параметр TTL в записях DNS обычно опускается и задается глобально директивой $TTL в самом начале файла описания зоны. В поле данных этой директивы задается время (в секундах), в течение которого запись в кэше может считаться достоверной. В приведённом ниже примере это 86400 с. Параметр класс принимает единственное значение IN (Интернет); сети других классов системой DNS могут поддерживаться, но пока их нет. Основными в описании зоны являются ресурсные записи (Resource Record, RR), которые могут быть более 20 типов. Чаще других используются записи следующих типов:  SOA (Start of Authority), указывает начало описания зоны;  NS, определяет имя сервера DNS зоны;  A, задаёт соответствие «имя  IP-адрес» (прямое преобразование);  MX, указывает почтовый сервер зоны;  CNAME, определяет альтернативные имена узлов; 550  PTR, задаёт соответствие «IP-адрес  имя» (обратное преобразование), употребляется в описании «обратной» зоны. Запись типа SOA в описании зоны может быть только одна. Её поле данных содержит сведения об имени первичного сервера DNS зоны (Primary Name Server), почтовом адресе администратора зоны и далее в скобках разделённые пробелами приводятся:  серийный номер файла зоны (Serial number), который необходимо увеличивать при каждой его модификации;  значения таймеров: Refresh – интервал запроса от вторичного сервера о необходимости обновления; Retry – задержка повторного запроса обновления после неудачной попытки; Expire – максимальное время, в течение которого вторичный сервер может считать информацию о полученной зоне актуальной; Minimum TTL – минимальное время, в течение которого данные остаются в кэше вторичного сервера. Приведённый ниже пример содержания файла db.sstu.ru иллюстрирует описание зоны sstu.ru. Всё, что указывается в строке после знака ; является комментарием. $TTL 86400 ; интервал достоверности записей в кэше сервера зоны, 24 часа. @ IN SOA ns1.sstu.ru. admin.sstu.ru. ( 2010123101 3600 900 3600000 86400) ; DNS серверы (записи типа NS) @ IN NS ns1.sstu.ru. ; Имя основного сервера имён зоны. ; Для собственного сервера должна быть A-запись (см. ниже). @ IN NS ns2.mypartner.com. ; Почтовые серверы зоны (записи типа MX) @ IN MX 10 mail ; сервер mail.sstu.ru предпочтителен @ IN MX 20 mail-2 ; Адреса, соответствующие именам конечных хостов (записи типа A) www IN A 82.207.87.36 ns1 IN A 82.207.87.38 localhost IN A 127.0.0.1 ; localhost.sstu.ru разрешается в 127.0.0.1 @ IN A 82.207.87.36 ; запрос по имени sstu.ru разрешается в 82.207.87.36 mail IN A 82.207.87.37 mail-2 IN A 82.207.87.151 comp1 IN A 82.207.87.2 сomp2 IN A 82.207.87.4 551 ; Псевдонимы (записи типа CNAME) loopback IN CNAME localhost ; loopback.sstu.ru будет отвечает как и localhost.sstu.ru pop IN CNAME mail ; у mail.sstu.ru есть имена pop.sstu.ru и smtp.sstu.ru smtp IN CNAME mail ftp IN CNAME www ; сервер ftp работает на том же узле, что и www ; Дочерняя зона scc IN NS ns.scc ns.scc 282.207.88 IN A ; запросы типа «www.scc.sstu.ru» перенаправляются для разрешения на сервер ns.scc.sstu.ru В поле данных стартовой записи описания зоны SOA указаны, в частности, имя первичного DNS сервера зоны и адрес электронной почты администратора домена; точка в конце имени сервера «ns1.sstu.ru.» предотвращает его трансформацию в имя поддомена «ns1.sstu.ru.sstu.ru»; в почтовом адресе администратора вместо традиционного символа @ после имени получателя ставится точка, но этот параметр сохраняет смысл почтового адреса admin@sstu.ru. 10.4 Схема выполнения запроса на разрешение имени в IP-адрес Для определения IP–адреса узла по его доменному имени необходимо просмотреть все DNS-серверы зон, имена которых входят в полное имя узла. Служба DNS построена по архитектуре клиент– сервер. Клиент DNS (resolver), работает в составе ОС конечного узла, а роль сервера выполняет вся распределённая система имён Интернет. Клиент DNS, по поручению прикладного процесса или модуля IP-протокола формирует предусмотренные протоколом DNS необходимые запросы, анализирует получаемые ответы и передаёт результат запросившему эту услугу процессу. В запросе кроме содержательной информации определяется и желательная схема (рекурсивная или итеративная) его выполнения. В рекурсивной схеме клиент «перепоручает» всю работу «своему» рабочему DNS-серверу (серверу, указанному в настройках клиента DNS). Практически все DNS-клиенты заявляют рекурсивную процедуру выполнения запросов. Однако, полнота её реализации ограничивается настройками DNS-серверов. Так, корневые серверы и серверы зон первого уровня работают только по 552 итеративной схеме, которая предусматривает возвращение содержательного ответа только о ресурсах, для которых в описании зоны существуют ресурсные записи. Серверы зон второго, третьего и т.д. уровней чаще Какой IP у c1.scc.spbstu.ru ? Клиент DNS поддерживают рекурсивную схему. c1.scc.spbstu.ru ? Рабочий DNS DNS зоны ru DNS корневой зоны c1.scc.spbstu.ru ? DNS зоны spbstu.ru c1.scc.spbstu.ru 105.209.232.15 DNS зоны spbstu.ru DNS зоны scc.spbstu.ru c1.scc.spbstu.ru ? c1.scc.spbstu.ru ? c1.scc.spbstu.ru 105.20.232.15 DNSзоны ru Рисунок 10.5. Схема разрешения имени в IP–адрес Работу по поиску IP-адреса ресурса, необходимого конечной станции, координирует рабочий DNS–сервер, устанавливаемый, как правило, в локальной сети; информационная схема поиска представлена на рис. 10.5. 1. DNS-клиент обращается с запросом о разрешении имени удалённого узла в его ip-адрес к рабочему серверу DNS, который, почти наверняка, не имеет А-записи о требуемом имени и в его кэше эти сведения также отсутствуют. 2. Рабочий сервер DNS обращается к корневому DNS-серверу с запросом, в котором содержится полное искомое доменное имя. 3. Корневой DNS-сервер, конечно, не имеет требуемой записи и отвечает рабочему серверу сообщением, содержащим адрес DNS–сервера домена верхнего уровня, название которого указано в старшей части искомого имени. 4. Рабочий DNS-сервер делает запрос по указанному адресу к авторитетному DNS-серверу зоны домена верхнего уровня; этот DNSсервер возвращает ему адрес DNS-сервера нижестоящего домена второго 553 уровня, имя которого совпадает со второй частью полного имени искомого адреса. 5. Рабочий DNS-сервер делает запрос к указанному DNS-серверу второго уровня, который находит у себя запись о делегировании зоны, имя которой совпадает с третьей частью искомого адреса. 6. DNS-сервер второго уровня пересылает запрос по адресу сервера имён этой зоны (домен третьего уровня), где и хранится А-запись запрошенного имени. 7. DNS-сервер третьего уровня отправляет cерверу второго уровня DNS ответ, содержащий ip-адрес, соответствующий имени искомого узла, или сообщение об отсутствии записи с требуемым именем. 8. DNS-сервер второго уровня отправляет рабочему cерверу ответ, полученный от сервера уровня три. 9. Рабочий DNS кэширует ответ и направляет его клиенту конечного узла. В данной схеме возникает вопрос о критерии выбора рабочим DNS-сервером одного из 13 серверов корневой зоны, которому он направляет свой запрос. Таким критерием является минимальная задержка ответов на ранее направляемые к корневой зоне запросы. Если к её серверам ранее запросы не направлялись, то соответствующий сервер выбирается случайным образом, а начальные значения задержек ответов от других серверов корневой зоны назначаются случайными и меньшими задержки, полученной при первом обращении к случайно выбранному серверу зоны. Такой подход гарантирует, что будут реально испытаны все серверы зоны и по завершению этого этапа выбор сервера для запроса будет базироваться на принципе минимума задержек ответов. 10.5 Обратное преобразование адрес  имя Существует значительное число сервисов, реализация которых требует решения обратной задачи, а именно, определение имени узла по его IP-адресу. Типичный пример – это сервис электронной почты, в котором 554 принимающий сервер располагает данными об имени почтового сервера, установившего с ним соединение. Принимая доставленное в ip–пакете сообщение, сервер узнаёт адрес отправителя и пытается проверить является ли он тем узлом, с которым была установлена связь для приёма почты. Технология преобразования адреса хоста в его имя инструментами системы DNS базируется на отражении IP-адресов в специальное пространство имён, построенное по принципам доменных имён. Заметим также, что при формировании дерева в этом пространстве никаких предположений о содержании имён его узлов не делается (имя может не относиться к хосту, а обозначать множество почтовых адресов, записи MX). Пространство IP-адресов при их символьном представлении в десятично-точечной нотации содержит четыре уровня иерархии. Но в отличие от иерархии доменных имен старшие составляющие IP-адреса записываются слева. Следовательно, простым изменением порядка их записи можно взаимно однозначно отобразить пространство IP-адресов на множество специально сформированных имён, и объединить их в отдельный домен имён. Название этого домена, in-addr.arpa, произошло от имени сети ARPA, родоначальника Интернет, и от предположения, что система доменных имён будет обслуживать и другие глобальные сети; так в название попало обозначение IN-ADDR. В этот домен в качестве поддоменов входят узлы с именами, совпадающими с символьным представлением старшего октета IP-адреса. В свою очередь, каждый из таких поддоменов вида X.in-addr.arpa, где X = (0, ..., 255), имеет 256 поддоменов следующего уровня с именами узлов, совпадающими с символьным представлением второго справа октета IP-адреса. Таким образом, IP-адрес 212.16.5.9 представляется узлом пространства имён 9.5.16.212.in-addr.arpa, а адреса сети 212.16.5.0 – вышестоящим родительским узлом 5.16.212.in-addr.arpa (рис. 10.6). 555 · edu ru com yandex Корневой домен (root) uk tv arpa in-addr spbstu ⋯ scc 0 1 5 0 1 0 1 16 0 1 numa.scc.spbstu.ru 212.16.5.9 9 ⋯ ⋯ 212 212 ⋯ 212 ⋯ TLD SLD 255 212 255 255 255 9.5.16.212.in-addr.arpa numa.scc.spbstu.ru Рисунок 10.6. Домен in-addr.arpa в системе доменных имён Интернет Благодаря иерархической модели управления именами появляется возможность делегировать управление зонами обратных имён владельцам соответствующих диапазонов IP адресов, а в ресурсных записях авторитетного DNS-сервера прямой зоны указывают имена и адреса серверов обратных зон, представляющих интерес для обслуживаемой прямой зоны. Так, например, в конфигурационном файле сервера DNS прямой зоны, содержащей ссылки на адреса из сети 212.16. 5.0/24, должна описываться зона: {zone ˝5.16.212.in-addr.arpa˝ type master; file ˝/etc/bind/db.5.16.212 ˝;}, где файл db.5.16.212 содержит описания ресурсов обратной зоны для соответствующей сети. Для описания ресурсов обратной зоны в основном используются записи типа PTR. Структура этих записей описывается шаблоном: 556 [ip_address #4] IN PTR [имя домена], где ip_address #4 – последнее из 4-х десятичных чисел IP-адреса (от 0 до 255). Первые три компоненты адреса для данного файла обратной зоны задаются в файле named.boot или директивой $ORIGIN. Запись PTR устанавливает соответствие между обратной записью десятичного представления IP-адреса и доменным именем хоста. $TTL 172800 $ORIGIN 23.17.192.IN-ADDR.ARPA @ IN SOA ns.zz.com. admin.zz.com. (1998022300 14400 3600 1209600 345600 ) IN NS ns.zz.com. IN NS ns3.faaa.ru. 1 IN PTR ns. zz.com. 2 IN PTR c1. zz.com. 16 IN PTR www. zz.com. Запрос к обратной зоне практически не отличается от запроса к прямой зоне. Единственное отличие в типе запрашиваемого ресурса (Type: PTR и Type: А, соответственно). Пример Internet Protocol Version 4, Src: 192.168.1.34, Dst: 192.168.1.1 User Datagram Protocol, Src Port: 63240, Dst Port: 53 Domain Name System (query) Transaction ID: 0xae89 Flags: 0x0100 Standard query 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data: Unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries 198.231.209.195.in-addr.arpa: type PTR, class IN Name: 198.231.209.195.in-addr.arpa [Name Length: 28] [Label Count: 6] Type: PTR (domain name PoinTeR) (12) Class: IN (0x0001) 557 Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.34 User Datagram Protocol, Src Port: 53, Dst Port: 63240 Domain Name System (response) Transaction ID: 0xae89 Flags: 0x8180 Standard query response, No error 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 1 Authority RRs: 0 Additional RRs: 0 Queries 198.231.209.195.in-addr.arpa: type PTR, class IN Name: 198.231.209.195.in-addr.arpa [Name Length: 28] [Label Count: 6] Type: PTR (domain name PoinTeR) (12) Class: IN (0x0001) Answers 198.231.209.195.in-addr.arpa: type PTR, class IN, cndb.spbstu.ru 10.6 Технологическое развитие системы корневых серверов Корневой уровень DNS весьма консервативен, поскольку любые изменения в нём затрагивают функционирование всей глобальной системы доменных имен. Тем не менее, модернизация её технологических основ с целью повышения надёжности, защищённости и производительности проводится постоянно. Рассмотрим два нововведения последнего десятилетия. Anycast-адресация Количество КС, а точнее, их имён и адресов равно 13, что связано с ограничением размера DNS-сообщения 512 байтами (RFC 1035, 1987). В своё время, это ограничение обеспечивало передачу сегментов UDP с сообщениями DNS без фрагментации в любой IP-сети. С учётом его и было 558 определено число корневых серверов – в 512 байт умещается информация (имена, адреса и прочее) именно 13 корневых серверов (от a.root-servers.net до m.root-servers.net). Если бы их стало больше, то в ответ на запрос о составе корневой зоны пришлось бы отправлять уже 2 сегмента, а UDP - ненадёжный протокол и увеличение числа сегментов с информацией о составе корневой зоны могло негативно сказаться на производительности и, главное, надёжности системы. Несмотря на появление новых сетевых протоколов (IPv6) и наличие усовершенствованного стандарта DNS (EDNS0: RFC 2671, 1999 и RFC 6891, 2013), предусматривающего механизм согласования клиентом и сервером приемлемого размера сообщений, это ограничение сохраняется и едва ли будет снято в ближайшем будущем. Размещение тринадцати КС, в основном, на территории США и Западной Европы было фактором, сдерживающим развитие Интернет в других регионах мира. Кроме этого, система из всего 13 серверов оказалась весьма уязвимой к DDOS атакам – в октябре 2002 года, в результате такой атаки большинство КС были недоступны в течение нескольких часов. Решению этих проблем помогла технология anycast, известная с 1993 года (RFC 1546), но не применявшаяся в глобальном масштабе и для таких ответственных приложений. Суть её заключается в BGP-анонсировании одной и той же сети (сетевой IP префикс и номер AS) в различных частях Интернета. Благодаря взаимодействию BGP с протоколами внутренней маршрутизации, использующих критерий кратчайшего пути, во внутренних сетях AS будет рассчитан маршрут к наиболее близкому в топологическом смысле узлу DNS с anycast-адресом (ничем не отличается от unicast-адреса). Технология anycast хорошо подходит для приложений, использующих протокол UDP. В 2003 году, после тщательной экспертизы и тестирования, оператором сервера f.root-servers.net (компания Internet Software Consortium, ISC) была введена anycast-адресация для зеркалирующих серверов. Примеру ISC последовали и ряд других операторов, благодаря чему география КС существенно расширилась, на декабрь 2020 их общее число достигло 1345. 559 DNSSEC Основным недостатком системы DNS является слабая защита, циркулирующих в ней данных. Сообщения DNS на пути от сервера к клиенту могут быть модифицированы, а запросы DNS могут перехватываться и направляться к ложным DNS-серверам. Возможно также использование инспирированных запросов к большому числу DNS-серверов с поддельным адресом источника (адресом жертвы) для подавления её активности. Спецификация DNSSEC (Domain Name System Security Extensions, RFC 4033 - 4035, 2005), является расширением стандарта DNS; она содержит описание механизмов, решающих проблему «третьей стороны» путем удостоверения данных цифровой подписью администратора зоны, от сервера которой приходят данные. В свою очередь, подпись администратора зоны удостоверяется администратором родительской зоны. Такая цепочка удостоверений продолжается вплоть до корневой зоны и DNS-клиент может проконтролировать, что само имя отвечающего сервера и вся цепочка делегаций достоверны и не были модифицированы. Подчеркнём, что DNSSEC не защищает сообщения от искажений, но предоставляет средство их обнаружения и, тем самым, исключает риск вторжения «третьей стороны». В 2010 году в результате сотрудничества ICANN и компании VerySign механизмы DNSSEC были внедрен в корневой зоне и в зонах первого уровня. Практически все версии программного обеспечения серверов DNS поддерживают этот протокол и его повсеместное использование зависит лишь от администраторов доменов. Конечно, применение DNSSEC увеличивает объём трафика DNS; так средний размер ответа от серверов корневой зоны при включении DNSSEC увеличился примерно на ~75%. 560