Адресация

Услуги сети OSI предоставляются транспортному уровню через концептуальную точку на границе сетевого и транспортного уровней, известную под названием "точки доступа к услугам сети" (network service access point - NSAP). Для каждого объекта транспортного уровня имеется одна NSAP.

Каждая NSAP может быть индивидуально адресована в об'единенной глобальной сети с помощью адреса NSAP (в обиходе существует неточное название - просто NSAP). Таким образом, любая конечная система OSI имеет, как правило, множество адресов NSAP. Эти адреса обычно отличаются только последним байтом, называемом n-selector.

Возможны случаи, когда полезно адресовать сообщение сетевому уровня системы в целом, не связывая его с конкретным объектом транспортного уровня, например, когда система участвует в протоколах маршрутизации или при адресации к какой-нибудь промежуточной системе (к роутеру). Подобная адресация выполняется через специальный адрес сети, известный под названием network entity title (NET) (титул объекта сети). Структурно NET идентичен адресу NSAP, но он использует специальное значение n-selector "00". Большинство конечных и промежуточных систем имеют только один NET, в отличие от роутеров IP, которые обычно имеют по одному адресу на каждый интерфейс. Однако промежуточная система, участвующая в нескольких областях или доменах, имеет право выборa на обладание несколькими NET.

Адреса NET и NSAP являются иерархическими адресами. Адресация к иерархическим системам облегчает как управление (путем обеспечения нескольких уровней управления), так и маршрутизацию (путем кодирования информации о топологии сети). Адрес NSAP сначала разделяется на две части: исходная часть домена (initial domain part - IDP) и специфичнaя часть домена (domain specific part - DSP). IDP далее делится на идентификатор формата и полномочий (authority and format identifier - AFI) и идентификатор исходного домена (initial domain identifier - IDI).

AFI обеспечивает информацию о структуре и содержании полей IDI и DSP, в том числе информацию о том, является ли IDI идентификатором переменной длины и использует ли DSP десятичную или двоичную систему счислений. IDI определяет об'ект, который может назначать различные значения части DSP адреса.

DSP далее подразделяется полномочным лицом, ответственным за ее управление. Как правило, далее следует идентификатор другого управляющего авторитета, чем обеспечивается дальнейшее делегирование управления адресом в подорганы управления. Далее идет информация, используемая для маршрутизации, такая, как домены маршрутизации, область (area) с доменом маршрутизации, идентификатор (ID) станции в пределах этой области и селектор (selector) в пределах этой станции. Рисунок иллюстрирует формат адреса OSI.

  <

Доступ к среде ИСО

Также, как и некоторые другие современные 7-уровневые комплекты протоколов, комплект OSI включает в себя многие популярные сегодня протоколы доступа к носителю. Это позволяет другим комплектам протоколов существовать наряду с OSI в одном и том же носителе. В OSI входят IEEE 802.2, IEEE 802.3, IEEE 802.5, FDDI, X.21, V.35, X.25 и другие. <

Иерарахическая связь.

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

Каждая из семи областей проблемы решалась с помощью одного из уровней модели. Большинство устройств сети реализует все семь уровней. Однако в режиме потока информации некоторые реализации сети пропускают один или более уровней. Два самых низших уровня OSI реализуются аппаратным и программным обеспечением; остальные пять высших уровней, как правило, реализуются программным обеспечением.

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

В качесте примера связи типа OSI предположим, что Система А на Рис. 1-1 имеет информацию для отправки в Систему В. Прикладная программа Системы А сообщается с Уровнем 7 Системы А (верхний уровень), который сообщается с Уровнем 6 Системы А, который в свою очередь сообщается с Уровнем 5 Системы А, и т.д. до Уровня 1 Системы А. Задача Уровня 1 - отдавать (а также забирать) информацию в физическую среду сети. После того, как информация проходит через физическую среду сети и поглащается Системой В, она поднимается через слои Системы В в обратном порядке (сначала Уровень 1 , затем Уровень 2 и т.д.), пока она наконец не достигнет прикладную программу Системы В.

Хотя каждый из уровней Системы А может сообщаться со смежными уровнями этой системы, их главной задачей является сообщение с соответствующими уровнями Системы В.

Т.е. главной задачей Уровня 1 Системы А является связь с Уровнем 1 Системы В; Уровень 2 Системы А сообщается с Уровнем 2 Системы В и т.д. Это необходимо потому, что каждый уровень Системы имеет свои определенные задачи, которые он должен выполнять. Чтобы выполнить эти задачи, он должен сообщаться с соответствующим уровнем в другой системе.

Уровневая модель OSI исключает прямую связь между соответствующими уровнями других систем. Следовательно, каждый уровень Системы А должен полагаться на услуги, предоставляемые ему смежными уровнями Системы А, чтобы помочь осуществить связь с соответствующим ему уровнем Системы В. Взаимоотношения между смежными уровнями отдельной системы показаны на Рис.1-2.



Предположим, что Уровень 4 Системы А должен связаться с Уровнем 4 Системы В. Чтобы выполнить эту задачу, Уровень 4 Системы А должен воспользоваться услугами Уровня 3 Системы А. Уровень 4 называется "пользователем услуг", а Уровень 3 - "источником услуг". Услуги Уровня 3 обеспечиваются Уровню 4 в "точке доступа к услугам" (SAP), которая представляет собой просто местоположение, в котором Уровень 4 может запросить услуги Уровня 3. Как видно из рисунка, Уровень 3 может предоставлять свои услуги множеству об'ектов Уровня 4.

Форматы информации.

Каким образом Уровень 4 Системы В узнает о том, что необходимо Уровню 4 Системы А? Специфичные запросы Уровня А запоминаются как управляющая информация, которая передается между соответствующими уровнями в блоке, называемом заголовком; заголовок предшествуют фактической прикладной информации. Например, предположим, что Система А хочет отправить в Систему В следующий текст (называемый "данные" или "информация"):

The small grey cat ran up the wall to try to catch the red bird.

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



Этот информационный блок передается в Уровень 6 Системы А, который может предварить его своей собственной управляющей информацией. Размеры сообщения увеличиваются по мере того, как оно проходит вниз через уровни до тех пор, пока не достигнет сети, где оригинальный текст и вся связанная с ним управляющая информация перемещаются к Системе В, где они поглащаются Уровнем 1 Системы В. Уровень 1 Системы В отделяет заголовок уровня 1 и прочитывает его, после чего он знает, как обрабатывать данный информационный блок. Слегка уменьшенный в размерах информационный блок передается в Уровень 2, который отделяет заголовок Уровня 2, анализирует его, чтобы узнать о действиях, которые он должен выполнить, и т.д. Когда информационный блок наконец доходит до прикладной программы Системы В, он должен содержать только оригинальный текст.

Концепция заголовка и собственно данных относительна и зависит от перспективы того уровня, который в данный момент анализирует информационный блок. Например, в Уровне 3 информационный блок состоит из заголовка Уровня 3 и следующими за ним данными. Однако данные Уровня 3 могут содержать заголовки Уровней 4, 5, 6 и 7. Кроме того, заголовок Уровня 3 является просто данными для Уровня 2. Эта концепция иллюстрируется на Рис. 1-3. И наконец, не все уровни нуждаются в присоединении заголовков. Некоторые уровни просто выполняют трансформацию фактических данных, которые они получают, чтобы сделать их более или менее читаемыми для смежных с ними уровней.



Проблемы совместимости.

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



Примером самого незначительного отличия могут быть гвозди, забитые в разных местах.

Чем об'ясняется разница в реализациях одного и того же плана корабля (или спецификации протокола)? Частично эта разница вызвана неспособностью любой спецификации учесть все возможные детали реализации. Кроме того, разные люди, реализующие один и тот же проект, всегда интерпретируют его немного по-разному. И наконец, неизбежные ошибки реализации приводят к тому, что изделия разных реализаций отличаются исполнением. Этим об'ясняется то, что реализация протокола Х одной компании не всегда взаимодействует с реализацией этого протокола, осуществленной другой компанией.

Уровни OSI.

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

Прикладной уровень



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

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

Представительный уровень

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



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

Сеансовый уровень

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

Транспортный уровень

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

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

Сетевой уровень

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



В данном случае "подсеть" - это по сути независимый сетевой кабель (иногда называемый сегментом).

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

Канальный уровень

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

Физический уровень

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

Эталонная модель

Перемещение информации между компьютерами различных схем является чрезвычайно сложной задачей. В начале 1980 гг. Международная Организация по Стандартизации (ISO) и Международный Консультативный Комитет по Телеграфии и Телефонии (МККТТ) признали необходимость в создания модели сети, которая могла бы помочь поставщикам создавать реализации взаимодействующих сетей. В тесном сотрудничестве была разработана  эталонная модель "Взаимодействие Открытых Систем" (ЭМВОС). Эта модель была описана в рекомендациях Х.200 (МККТТ) и ISO 7498  (ISO). Соответствие ЭМВОС МККТТ и ИСО.

ЭМВОС быстро стала основной архитектурной моделью для передачи межкомпьютерных сообщений. Несмотря на то, что были разработаны другие архитектурные модели (в основном патентованные), большинство поставщиков сетей, когда им необходимо предоставить обучающую информацию пользователям поставляемых ими изделий, ссылаются на них как на изделия для сети, соответствующей эталонной модели. И действительно, эта модель является самым лучшим средством, имеющемся в распоряжении тех, кто надеется изучить технологию сетей. Дальнейшее описание ЭМВОС будет базироваться на модели ISO.

Эталонная модель взаимодействия открытых систем

	Введение
	Эталонная модель OSI Иерархическая связь Форматы информации Проблемы совместимости Уровни OSI
	Важнейшие термины и концепции Адресация Блоки данных (фрэймы), пакеты и сообщения
	Основные организации.

Основные организации, занимающиеся стандартизацией объединенных сетей

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

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

Представительный уровень

Представительный уровень OSI, как правило, является просто проходным протоколом для информации из соседних уровней. Хотя многие считают, что Abstract Syntax Notation 1 (ASN.1) (Абстрактное представление синтаксиса) является протоколом представительного уровня OSI, ASN.1 используется для выражения форматов данных в независимом от машины формате. Это позволяет осуществлять связь между прикладными задачами различных компьютерных систем способом, прозрачным для этих прикладных задач.

Прикладной уровень

Прикладной уровень ОSI включает действующие протоколы прикладного уровня, а также элементы услуг прикладного уровня (application service elements - ASE). ASE обеспечивают легкую связь протоколов прикладного уровня с низшими уровнями. Тремя наиболее важными ASE являются Элемент услуг управления ассоциацией (Association Control Service Element - ACSE), Элемент услуг получения доступа к операциям отдаленного устройства (Remote Operations Service Element - ROSE) и Элемент услуг надежной передачи (Reliable Transfer Service Element - RTSE). При подготовке к связи между двумя протоколами прикладного уровня ACSE об'единяет их имена друг с другом. ROSE реализует родовой (generic) механизм "запрос/ответ", который разрешает доступ к операциям отдаленного устройства способом, похожим на вызовы процедуры обращений к отделенной сети (remote procedure calls - RPC). RTSE способствует надежной доставке, делая конструктивные элементы сеансового уровня легкими для использования. Наибольшего внимания заслуживают следующие пять протоколов прикладного уровня OSI:

Common Management Information Protocol (CMIP)

Протокол общей информации управления - протокол управления сети OSI Также, как и SNMP  и Net View, он обеспечивает обмен управляющей информацией между ES и станциями управления (которые также являются ES).

Directory Services (DS)

Услуги каталогов. Разработанная на основе спецификации Х.500 CITT, эта услуга предоставляет возможности распределенной базы анных, которые полезны для идентификации и адресации узлов высших ровней.

File Transfer,Access, and Management (FTAM)

Передача, доступ и управление файлами - услуги по передаче файлов. В дополнение к классической передаче файлов, для которой FTAM обеспечивает многочисленные опции, FTAM также обеспечивает средста доступа к распределенным файлам таким же образом, как это делает NetWare компании Novell, Inc или Network File System (NFS) компании Sun Microsystems, Inc.

Massage Handling Systems (MHS)

Системы обработки сообщений - обеспечивает механизм, лежащий в основе транспортировки данных для прикладных задач передачи сообщений по электронной почте и других задач, требующих услуг по хранению и продвижению данных. Хотя они и выполняют аналогичные задачи, MHS не следует путать с NetWare MHS компании Novell .

Virtual Terminal Protocol (VTP)

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

  <

Протоколы высших уровней ИСО

	Сеансовый уровень
	Представительный уровень
	Прикладной уровень

Основные протоколы высших уровней OSI представлены на рисунке.

Сеансовый уровень

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

Управление диалогом сеанса реализуется путем использования маркера (token), обладание которым обеспечивает право на связь. Маркер можно запрашивать, и конечным системам ES могут быть присвоены приоритеты, обеспечивающие неравноправное пользование маркером.

Сетевая архитектура ИСО

В первые годы появления межкомпьютерной связи программное обеспечение организации сетей создавалось бессистемно, для каждого отдельного случая. После того, как сети приобрели достаточную популярность, некоторые из разработчиков признали необходимость стандартизации сопутствующих изделий программного обеспечения и разработки аппаратного обеспечения. Считалось, что стандартизация позволит поставщикам разработать системы аппаратного и программного обеспечения, которые смогут сообщаться друг с другом даже в том случае, если в их основе лежат различные архитектуры. Поставив перед собой эту цель, ISO начала разработку эталонной модели Open Systems Interconnections (OSI) (Взаимодействие открытых систем). Эталонная модель OSI была завершена и выпущена в 1984 г. Данная модель разрабатывалась в тесном сотрудничестве с Международным Консультативным Комитетом  по Телефонии и Телеграфии (МККТТ). Соответствие рекомендаций МККТТ и ИСО вы найдете здесь.

В настоящее время эталонная модель OSI   является самой выдающейся в мире моделью архитектуры об'единенных сетей. Она также является самым популярным средством приобретения знаний о сетях. С другой стороны, у протоколов OSI был длинный период созревания. И хотя известно о некоторых реализациях OSI, протоколы OSI все еще не завоевали той популярности, которой пользуются многие патентованные протоколы (например, DECnet и АppleTalk) и действующие стандарты (например, протоколы Internet).

  <

Сетевой уровень ИСО

	Общее описание услуг сетевого уровня
	Услуги без установления соединения
	Услуги с установлением соединения
	Адресация

OSI предлагает услуги сетевого уровня как без установления соединения, так и ориентированные на установления логического соединения. Услуги без установления соединения описаны в ISO 8473 (обычно называемом Connectionless Network Protocol - CLNP - Протокол сети без установления соединения). Обслуживание, ориентированное на установление логического соединения (иногда называемое Connection-Oriented Network Service - CONS) описывается в ISO 8208 (X.25 Packet-Level Protocol - Протокол пакетного уровня X.25, иногда называемый Connection-Mode Network Protocol - CMNP) и ISO 8878 (в котором описывается, как пользоваться ISO 8208, чтобы обеспечить ориентированные на установление логического соединения услуги OSI). Дополнительный документ ISO 8881 описывает, как обеспечить работу Протокола пакетного уровня X.25 в локальных сетях IEEE 802. OSI также определяет несколько протоколов маршрутизации.

В дополнение к уже упоминавшимся спецификациям протоколов и услуг, имеются другие документы, связанные с сетевым уровнем OSI, в число которых входят:

ISO 8648

На этот документ обычно ссылаются как на "внутреннюю организацию сетевого уровня" (internal organization of the network level - IONL). Он описывает, каким образом можно разбить сетевой уровень на три отдельных различимых друг от друга подуровня, чтобы обеспечить поддержку для различных типов подсетей.

ISO 8348

Этот документ обычно называют "определение услуг сети" (network service definition). Он описывает ориентированные на установление логического соединения услуги и услуги без установления соединения, которые обеспечивает сетевой уровень OSI. Адресация сетевого уровня также определена в этом документе. Определение услуг в режиме без установления соединения и определение адресации раньше были опубликованы отдельным дополнением к ISO 8348; однако вариант ISO 8348 1993 года об'единяет все дополнения в отдельный документ.

ISO TR 9575

Этот документ описывает структуру, концепции и терминологию, использованную в протоколах маршрутизации OSI.

ISO TR 9577

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

Соответствие ЭМВОС МККТТ и ИСО

Рекомендация МККТТ	Стандарт или технический отчет ИСО/МЭК Системы обработки информации - Взаимосвязь открытых систем
X.200	ИСО 7498 "Системы обработки информации - Взаимосвязь открытых систем - Базовая эталонная модель" (1984 г.)
X.208	ИСО 8824 (ИСО 8824/доп1) " - Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)" (1987 г.)
X.209	ИСО 8825 (ИСО 8825/доп1) "Описание базовых правил кодирования для синтаксической нотации версии 1 (АСН.1)" (1987 г.)
X.210	ИСО/ТО 8509 "Соглашение по услугам" (1987 г.)
X.211	ИСО 10022 "Определение услуг физического уровня"
X.212	ИСО 8886 "Определение услуг уровня звена данных для взаимосвязи открытых систем"
X.213	ИСО 8348 (доп2,3) "Определение услуг сетевого уровня"  (1988 г.)
X.214	ИСО 8072 "Определение услуг транспортного уровня" (1988 г.)
X.215	ИСО 8326 "Определение базовых услуг сеансового уровня в режиме с установлением соединения" (1987 г.) ИСО 8826/доп2 "Определение базовых услуг сеансового уровня в режиме с установлением соединения. "
X.216	ИСО 8822 "Определение услуг уровня представления в режиме с установлением соединения" (1988 г.)
X.217	ИСО 8649 "Определение услуг для сервисных элементов управления ассоциацией"
X.218	ИСО 9066-1 "Системы обработки информации - Обмен текстовыми данными - Надежная передача - Часть 1: Модель и определение услуг"
X.219	ИСО 9072-1 "Системы обработки информации - Обмен текстовыми данными - Дистанционные операции - Часть 1: Модель, нотация и определение услуг"

Транспортный уровень ИСО

Как обычно для сетевого уровня OSI, oбеспечиваются услуги как без установления соединения, так и с установлением соединения. Фактически имеется 5 протоколов транспортного уровня OSI с установлением соединения: ТР0, ТР1, ТР2, ТР3 и ТР4. Все они, кроме ТР4, работают только с услугами сети OSI с установлением соединения. ТР4 работает с услугами сети как с установлением соединения, так и без установления соединения.  Все эти протоколы являются аналагом протокола МККТТ Х.224 с различными классами услуг (0,1,2,3,4 соответственно).

ТР0 является самым простым протоколом транспортного уровня OSI, ориентированным на установления логического соединения. Из набора классических функций протокола транспортного уровня он выполняет только сегментацию и повторную сборку. Это означает, что ТР0 обратит внимание на протокольную информационную единицу (protocol data unit - PDU) с самым маленьким максимальным размером, который поддерживается лежащими в основе подсетями, и разобьет пакет транспортного уровня на менее крупные части, которые не будут слишком велики для передачи по сети.

В дополнение к сегментации и повторной сборке ТР1 обеспечивает устранение базовых ошибок. Он нумерует все PDU и повторно отправляет те, которые не были подтверждены. ТР1 может также повторно инициировать соединение в том случае, если имеет место превышение допустимого числа неподтвержденных РDU.

ТР2 может мультиплексировать и демультиплексировать потоки данных через отдельную виртуальную цепь. Эта способность делает ТР2 особенно полезной в общедоступных информационных сетях (PDN), где каждая виртуальная цепь подвергается отдельной загрузке. Подобно ТР0 и ТР1, ТР2 также сегментирует и вновь собирает PDU.

ТР3 комбинирует в себе характеристики ТР1 и ТР2.

ТР4 является самым популярным протоколом транспортного уровня OSI. ТР4 похож на протокол ТСР из комплекта протоколов Internet; фактически, он базировался на ТСР. В дополнение к характеристикам ТР3, ТР4 обеспечивает надежные услуги по транспортировке. Его применение предполагает сеть, в которой проблемы не выявляются. <

Услуги без установления соединения

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

В то время как CLNP определяет действующий протокол, выполняющий типичные функции сетевого уровня, CLNS (Обслуживание сети без установления соединения) описывает услуги, предоставляемые транспортному уровню, в котором запрос о передаче информации реализуется доставкой, выполненной с наименьшими затратами (best effort). Такая доставка не гарантирует, что данные не будут потеряны, испорчены, что в них не будет нарушен порядок, или что они не будут скопированы. Обслуживание без установления соединения предполагает, что при необходимости все эти проблемы будут устранены в транспортном уровне. CLNS не обеспечивает никаких видов информации о соединении или состоянии, и не выполняет настройку соединения. Т.к. CLNS обеспечивает транспортные уровни интерфейсом услуг, сопрягающим с CLNP, протоколы CNLS и CLNP часто рассматриваются вместе.

Услуги с установлением соединения

Услуги сети OSI с установлением соединения определяются ISO 8208 и ISO 8878. OSI использует X.25 Racket-Level Protocol для перемещения данных и указателей ошибок с установлением соединения. Для об'ектов транспортного уровня предусмотрено 6 услуг (одна для установления соединения, другая для раз'единения соединения, и четыре для передачи данных). Услуги вызываются определенной комбинацией из 4 примитив: запрос (request), указатель (indication), ответ (response) и подтверждение (confirmation). Взаимодействие этих четырех примитив показано на рисунке.

В момент времени t1 транспортный уровень ES 1 отправляет примитив- запрос в сетевой уровень ES 1. Этот запрос помещается в подсеть ES 1 протоколами подсети низших уровней и в конечном итоге принимается ES 2, который отправляет информацию вверх в сетевой уровень. В мотент времени t2 сетевой уровень ES 2 отправляет примитив-указатель в свой транспортный уровень. После завершения необходимой обработки пакета в высших уровнях, ES 2 инициирует ответ в ES 1, используя примитив-ответ, отправленный из транспортного уровня в сетевой уровень. Отправленный в момент времени t3 ответ возвращается в ES 1, который отправляет информацию вверх в сетевой уровень, где генерируется примитив-подтверждение, отправляемый в транспортный уровень в момент t3.

Важнейшие термины и концепции.

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

Адресация

Существенным компонентом любой системы сети является оперделение местонахождения компьютерных систем. Существуют различные схемы адресации, используемые для этой цели, которые зависят от используемого семейства протоколов. Другими словами, адресация AppleTalk отличается от адресации TCP/IP, которая в свою очередь отличается от адресации OSI, и т.д.

Двумя важными типами адресов являются адреса канального уровня и адреса сетевого уровня. Адреса канального уровня (называемые также физическими или аппаратными адресами), как правило, уникальны для каждого сетевого соединения. У большинства локальных сетей (LAN) адреса канального уровня размещены в схеме интерфейса; они назначаются той организацией, которая определяет стандарт протокола, представленный этим интерфейсом. Т.к. большинство компьютерных систем имеют одно физическое сетевое соединение, они имеют только один адрес канального уровня. Роутеры и другие системы, соединенные с множеством физических сетей, могут иметь множество адресов канального уровня. В соответствии с названием, адреса канального уровня существуют на Уровне 2 эталонной модели ISO.

Aдреса сетевого уровня (называемые также виртуальными или логическими адресами) существуют на Уровне 3 эталонной модели OSI. В отличие от адресов канального уровня, которые обычно существуют в пределах плоского адресного пространства, адреса сетевого уровня обычно иерархические. Другими словми, они похожи на почтовые адреса, которые описывают местонахождение человека, указывая страну, штат, почтовый индекс, город, улицу, адрес на этой улице и наконец, имя. Хорошим примером одноуровневой адресации является номерная система социальной безопасности США, в соответствии с которой каждый человек имеет один уникальный номер, присвоенный ему службой безопасности.

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

Адреса сетевого уровня различаются в зависимости от используемого семейства протоколов, однако они, как правило, используют соответствующие логические разделы для нахождения компьютерных систем в об'единенной сети. Некоторые из этих логических разделов базируются на физических характеристиках сети (таких, как сегмент сети, в котором находится какая-нибудь система); другие логические разделы базируются на группировках, не имеющих физического базиса (например, "зона" AppleTalk).

Блоки данных, пакеты и сообщения

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

В настоящей работе термин "блок данных" (frame) обозначает блок информации, источником и пунктом назначения которого являются об'екты канального уровня. Термин "пакет" (packet) обозначает блок информации, у которого источник и пункт назначения - об'екты сетевого уровня. И наконец, термин "сообщение" (message) oбoзначает информационный блок, у которого об'екты источника и места назначения находятся выше сетевого уровня. Термин "сообщение" используется также для обозначения отдельных информационных блоков низших уровней, которые имеют специальное, хорошо сформулированное назначение.

В данном материале дается разъяснение

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

Функциональная модель.

Функциональная структура модели системы обработки сообщений приведена на рисунке 1.

Рис.1 Функциональная модель СОС

В этой модели пользователем является либо физическое лицо, либо вычислительный процесс. Пользователь рассматривается как отправитель ( при передачи сообщения ), либо как получатель ( при приёме сообщения).

Система обработки сообщениями Х.400 состоит из следующих составляющих:

	Агент пользователя (АП). Это прикладной процесс, обеспечивающий удобный интерфейс пользователя с системой управления сообщениями. АП помогает, в частности, составлять, отправлять, принимать архивировать сообщения. АП и, следовательно, пользователь, идентифицируется своим адресом, называемом адресом отправителя/получателя (О/П адресом, адресация рассматривается ниже).
	Система передачи сообщений (СПС). СПС обеспечивает транспортировку сообщений всех видов от АП отправителя до АП получателя. СПС содержит ресурсы для промежуточного хранения сообщений.
	Агент передачи сообщений (АПС). Это прикладной процесс, переправляющий приходящие ему сообщения адресатам - агентам пользователей или другим АПС.

	Хранилище сообщений (ХС). Факультативная универсальная возможность СОС, действующая в качестве посредника между АП и АПС. Основное назначение – хранить доставленные сообщения и допускать возможность их поиска. Кроме того, ХС позволяет осуществлять предоставление сообщений со стороны АП и выдавать в АП сигналы уведомления.
	Модуль доступа (МД). Это функциональный объект, который связывает другую систему обмена данными (например, систему почтовой связи или сеть телекса) с СПС и через который её клиенты участвуют в качестве косвенных пользователей в обработке сообщений.
	Модуль доступа физической доставки (МДФД). Это модуль доставки, который подвергает сообщения физическому преобразованию и переносит конечное физическое сообщение в систему физической доставки (система, управляемая регионом управления, транспортирующая и доставляющая физическое сообщение, примером является почтовая служба).

<

/p>

Описание модели СОС.



Система управления сообщениями на основе рекомендаций Х.400 предоставляет два основных вида услуг:

	Передача и хранение сообщений. Здесь обеспечивается надежность и промежуточное хранение сообщений.
	Отправка и вручение сообщений. Здесь обеспечивается единый формат для сообщений с компонентами разных типов и, при необходимости, преобразование из одного типа в другой. Здесь же обеспечивается взаимодействие с некомпьютерными средствами передачи сообщений (например: факс, телекс).

Отправитель готовит сообщение с помощью своего агента пользователя, взаимодействующий с системой передачи сообщений (СПС) или с хранилищем сообщений (ХС) для предоставления сообщений от имени одного пользователя. СПС доставляет предоставленные ей сообщения одному или нескольким принимающим АП, модулям доступа (МД) или ХС, и может выдавать уведомления отправителю. АП может воспринимать доставку сообщений непосредственно из СОС, либо использовать возможности ХС для получения доставленных сообщений с целью последующего их поиска агентом АП.

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



Информационная модель.



Системы СОС и СПС могут переносить информационные объекты трёх классов: сообщения, зонды и отчёты.



Сообщения.



Основное назначение передачи сообщения состоит в переносе информационных объектов, называемых сообщениями, от одного пользователя к другим. Базовая структура сообщений, передаваемых СПС, показана на рис.2.

Сообщение состоит из конверта и содержимого.





Рис.2 Базовая структура сообщений



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



Этот идентификатор даёт возможность СПС определять доставляемость сообщения конкретным пользователям и позволяет АП и ХС интерпретировать и обрабатывать содержимое. Другая часть информации, создаваемая конвертом, идентифицирует типы кодирования информации, представленной в содержимом.

Содержимое, в свою очередь, состоит из межперсонального заголовка и тела (см. рис.3).







Рис.3 Структура сообщения

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



Зонды.



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

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



Отчёты.



Третье назначение передачи сообщений состоит в переносе информационных объектов, называемых отчётами, к пользователям. Отчёт несёт информацию о результате и прогрессе передачи сообщения или зонда (отчёт о доставке или недоставке).

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

Модель системы передачи сообщений.

Обработка сообщений предназначена (как мы уже отмечали) для обмена сообщениями между пользователями на основе их передачи с промежуточным накоплением. Сообщение, предоставленное одним отправителем, передаётся через систему передачи сообщений (СПС) и доставляется одному или нескольким другим получателям. Модель СПС приведена на рис.4.







Рис. 4 Модель системы передачи сообщений.



СПС состоит из совокупности объектов агент передачи сообщений (АПС), которые совместно формируют СПС и обеспечивают услуги СПС для её пользователей. К ним относятся и АПС, которые выполняют активные функции в СПС, т.е. передают сообщения, зонды и отчёты, генерируя отчёты, преобразуя содержимое.

Объекты АПС имеют порты: порт - представления, порт - доставки, административный – порт.

Порт – доставки позволяет пользователю СПС воспринимать доставку сообщений из СПС и принимать отчёты о доставке или недоставке сообщений и зондов.

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

Порт – представления позволяет пользователю СПС представлять сообщения СПС для их передачи и доставки одному или нескольким получателям СПС и зондировать способность СПС доставлять сообщение. В общем случае сообщение, зонд или отчёт могут быть переданы несколько раз между различными АПС, чтобы достигнуть своего назначенного адресата.

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

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

Отчёты о доставке или недоставке сообщения одному или нескольким принимающим пользователям СПС вырабатываются в АПС в соответствии с запросами отправителя сообщения и АПС отправителя.



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

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

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



Адресация.



Адресация в пользовании Х.400 очень проста, является одной из самых мощных схем адресации и идентифицируется именами О/П (отправитель/получатель (Originator/Recipient или O/R)). Адрес О/П содержит информацию, позволяющую системе обработки сообщений однозначно идентифицировать пользователя для доставки ему сообщения или выдачи уведомления. Существует четыре формы адресации:

Мнемонический адрес О/П – обеспечивает удобное для пользователя средство идентификации пользователей при отсутствии справочника. (этот тип адресов используется наиболее часто) .

	Термический адрес О/П- обеспечивает средства идентификации пользователей с терминалами, относящиеся к различным сетям.
	Цифровой адрес О/П- обеспечивает средства идентификации пользователей с помощью цифровых клавиатур;
	Почтовый адрес О/П- обеспечивает средства идентификации отправителей и получателей физических сообщений

<



/p>

Атрибуты адресов в зависимости от формы приведены в таблице 1

Табл.1

Тип атрибута	Формы адреса О/П
Мневм.	Цифр.	Пчт.	Терм.
		Ф	Н
Общего назначения
Имя-административного-региона	О	О	О	О	У
Общее-имя	У	-	-	-	-
Имя-страны	О	О	О	О	У
Сетевой-адрес	-	-	-	-	О
Цифровой-идентиф.-пользователя	-	О	-	-	-
Имя-организации	У	-	-	-	-
Имена-организационных-модулей	У	-	-	-	-
Личное-имя	У	-	-	-	-
Имя-частного-региона	У	У	У	У	У
Идентиф.-оконечного-устройства	-	-	-	-	У
Тип-оконечного-устройства	-	-	-	-	У
Почтовая маршрутизация
Служба-физической-доставки	-	-	У	У	-
Имя-страны-физич.-доставки	-	-	О	О	-
Почтовый-код	-	-	О	О	-
Почтовая адресация
Компоненты-расширенного-почтового-адреса-О/П	-	-	У	-	-
Компоненты-расширенного-адреса-физической-доставки	-	-	У	-	-
Локальные-почтовые-атрибуты	-	-	У	-	-
Имя-учреждения-физической-доставки	-	-	У	-	-
Номер-учреждения-физической-доставки	-	-	У	-	-
Имя-организации-физической-доставки	-	-	У	-	-
Личное-имя-физической-доставки	-	-	У	-	-
Адрес-почтового-ящика	-	-	У	-	-
Адрес-до-востребования	-	-	У	-	-
Адрес-улицы	-	-	У	-	-
Неформатированный-почтовый-адрес	-	-	-	О	-
Уникальное-почтовое-имя	-	-	У	-	-
Региональный
Региональный	У	У	-	-	У

Мнем.-мневмонический Ф- форматированный

Циф - цифровой Н- не форматированный

Пчт - почтовый О- обязательный

Терм - терминальный У- условный

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

Рассмотрим структуру межперсонального заголовка.

Межперсональный заголовок состоит из следующих полей:

	Идентификатор сообщения –идентификатор, отличающий данное сообщение от других сообщений, посланных данным пользователем;
	Отправитель- идентификатор отправителя;
	Полномочные пользователи - идентифицируют от нуля до нескольких пользователей, которые являются полномочными пользователями МПС (например: руководитель даёт своему секретарю задание отправить от его имени МПС. В этом случае секретарь, отправитель МПС, может считать руководителя полномочным пользователем);
	Основные получатели – список пользователей кому адресовано и которые будут как-то реагировать на данное МПС;
	Получатели копий - список пользователей кому адресовано МПС, для информационных целей;
	Получатели тайных копий;
	Ответ на МПС- поле указывает, что данное МПС является реакцией на сообщение ранее полученное, явившееся причиной написания данного;
	Устарелые МПС - определяет те сообщения, которые данное МПС делает недействительными;
	Родственные МПС- ссылки на родственные МПС;
	Субъект- предмет МПС;
	Истекшее время - так называемое срок годности сообщения;
	Время ответа - срок реакции на данное сообщение получателей (срок ответа);
	Получатели ответа - перечень лиц, которым должен быть отправлен ответ на данное МПС;
	Важность- степень важности МПС, принимающее следующие значения: низкая, нормальная и высокая;
	Конфиденциальность - имеет следующие значения: персональная, частная, для компаний.

<



/p>

Допустимо преобразования старого адреса в формат X.400, но не всегда это будет просто. Для перевода форматов существуют рекомендации RFC 1327, 1506 по переводу адресов и сообщений X.400 в формат RFC 822, а также существуют программное обеспечение по переводу адресов.



Возможности СОС по защите информации.

Угроза защиты информации.



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

	Маскирование. Когда пользователь СПС, ХС или АПС могут замаскироваться под другого пользователя СПС, ХС или АПС;
	Нарушение последовательности сообщений. Имеет место, когда часть сообщения или всё сообщение повторяется, смещается во времени или переупорядочивается;
	Модификация информации. Искажения маршрутной и другой управляющей информации, разрушение сообщений;
	Отклонение услуги. Отклонение услуги происходит, когда объект не выполняет своей функции или препятствует другим объектам выполнять свои функции;
	Утечка информации. Информация может быть получена неполномочной стороной путём контроля передач, несанкционированного доступа к информации, хранимой у любого объекта СОС, либо путём маскирования;
	Отрицание. Отрицание может произойти, когда пользователь СПС отказываются от представления, приёма или отправки сообщения;
	Прочие угрозы СОС.

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

Существуют два способа защиты при обработке сообщений:

Управление и администрирование защитой доступа.

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

Защита обмена сообщениями.

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

и обработкой сообщениями. Под аббревиатурой

Х.400 – общий стандарт, для управления и обработкой сообщениями. Под аббревиатурой "Х.400" подразумевается следующие рекомендации как:

	Х.400- общее описание системы и службы обработки сообщений;
	Х.402- общая архитектура;
	Х.403- тестирования;
	Х.407- определение услуг;
	Х.408- правила кодирования информации;
	Х.411- система передачи данных: определение услуг и процедур;
	Х.413- хранилище сообщений: определение услуг;
	Х.419- спецификации протоколов;
	Х.420- система межперсональных сообщений.

Система обработки сообщений (СОС) построена в соответствии с принципами эталонной модели взаимосвязи открытых систем для применений МККТТ (Рек. Х.200) и использует услуги уровня представления, а также услуги, предлагаемые другими, более общими сервисными элементами прикладного уровня. СОС может быть построена с использованием любой сети, относящейся к области распространения взаимосвязи открытых систем.

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

Рекомендации Х.400 описывают протоколы взаимодействия между всеми компонентами системы управления сообщениями.

Основой кодирования сообщений СОС Х.400 является абстрактно синтаксическая нотация АСН.1.



Возможности.



Х.400 обладает многими необходимыми возможностями при передаче сообщений, а именно:

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

Возможности защиты СОС.

К возможности защиты СОС можно отнести следующие средства:

	Аутентификация отправителя сообщения - даёт возможность получателю или любому АПС, через который проходит сообщение, аутентифицировать подлинность отправителя сообщения.
	Аутентификация отправителя отчёта – позволяет отправителю аутентифицировать источник отчёта о доставке/недоставке.
	Аутентификация отправителя зонда – позволяет любому АПС, через который проходит зонд, аутентифицировать источник зонда.
	Подтверждение доставки – позволяет отправителю сообщения аутентифицировать доставленное сообщение, его содержимое, и подлинность получателя.
	Подтверждение предоставления – позволяет отправителю сообщения аутентифицировать предоставление сообщения СПС для доставки первоначально назначенному получателю.
	Защита управления доступом – предусматривает аутентификацию между смежными компонентами и установку контекста защиты.
	Целостность содержимого – даёт возможность получателю убедиться в том, что исходное содержимое сообщения не было изменено.
	Конфиденциальность содержимого – предотвращает несанкционированное раскрытие содержимого сообщения тому, кто не является заданным получателем.
	Конфиденциальность потока сообщений – позволяет отправителю сообщения скрыть поток сообщений через СОС.
	Целостность последовательности сообщений – позволяет отправителю обеспечить получателю подтверждение сохранности последовательности сообщений.
	Бесспорность отправителя – обеспечивает получателю сообщения подтверждения происхождения сообщения и его содержимого, которое должно предотвратить любую попытку отправителя ложно отрицать посылку сообщения или его содержимое.
	Бесспорность доставки – обеспечивает отправителю сообщения подтверждения доставки.
	Разметка защиты сообщениё – обеспечивает возможность определить категорию сообщения, указав его конфиденциальность, которая определяет обработку сообщения в соответствии с действующей политикой защиты.

 

Протокол LAPB

LAPB является наиболее популярным протоколом благодаря тому, что он входит в комплект протоколов Х.25. Формат и типы блока данных, а также функции поля у LAPB те же самые, что у SDLC и HDLC. Однако в отличие от любого из этих двух протоколов, LAPB обеспечивает только один режим передачи ABM, поэтому он подходит только для комбинированных станций. Кроме того, цепи LAPB могут быть организованы либо терминальным оборудованием (DTE), либо оборудованием завершения действия информационной цепи (DCE). Станция, инициирующая обращение, определяется как первичная, в то время как реагирующая станция считается вторичной. И наконец, использование протоколом LAPB бита P/F несколько отличается от его использования другими протоколами.

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

Также, как и аналогичные протоколы канального уровня, LAPB использует три типа форматов блоков данных:

Информационный блок данных ( Information (I) frame ) .

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

Блоки данных супервизора ( Supervisory (S) frames ) .

Эти блоки данных обеспечивают управляющую информацию. У них нет информационного поля. Блоки данных S запрашивают и приостанавливают передачу, сообщают о состоянии канала и подтверждают прием блоков данных типа I.

Непронумерованные блоки данных ( Unnumbered (U) frames

).

Как видно из названия, эти блоки данных непоследовательны. Они используются для управляющих целей. Например, они могут инициировать связи , используя стандартную или расширяемую организацию окон (modulo 8 versus 128), раз'единять канал, сообщать об ошибках в протоколе, и выполнять другие аналогичные функции.

Блок данных LAPB представлен на Рис. 13-5.

Поле flag ограничивает блок данных LAPB. Чтобы предотвратить появление структуры флага в пределах внутренней части блока данных, используется вставка битов, называемых битами стафингования. В качестве флага используется двоичная комбинация 01111110. В качестве бита стафингования используется логический 0, вставляемый после пяти единиц подряд. Таким образом если в теле кадра встречается комбинация 11111 то после нее вставляется 0.

Поле address указывает, что содержит блок данных-команду или ответный сигнал. Используются только  два значения адреса 00000001 и 00000011. Таким образом протокол в отличие от протокола HDLC не поддерживает режим "многоточка".

Поле control обеспечивает дальнейшую квалификацию блоков данных и блоков команд, а также указывает формат блока данных (U, I или S)), функции блока данных (например, receiver ready - "получатель готов", или disconnect - "отключение") и номер последовательности отправки/ приема. Данное поле кодируется как в протоколе SDLC.

Поле data содержит данные высших уровней. Его размер и формат меняются в зависимости от типа пакета Уровня 3. Максимальная длина этого поля устанавливается соглашением между администратором PSN и абонентом во время оформления абонентства.

Поле FCS обеспечивает целостность передаваемых данных. <

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

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

Размер поля в байтах	Назначение
6	MAC - адрес получателя
6	MAC - адрес отправителя
2	тип следующего протокола в соответсвии с RFC-1700
45 - 1500	данные
4	контрольная сумма

Значения поля "тип следующего протокола" определены в рекомендации RFC1700. Данное поле с теми же значениями используется также в протоколах Bridge* и Router* (название условное). Назначение полей приведено здесь. Кодировка поля следующая: первый байт старший, второй младший.

Протокол Ethernet отличается от протокола

Протокол Ethernet отличается от протокола IEEE802.3 практически только одним полем:

13-14 байты в Ethernet обозначают тип следующего протокола, а в протоколе IEEE802.3 - длину информационной части кадра (пакета). Поэтому для обеспечения согласования протоколов было принято следуююще правило кодирования -

Если значение данных полей лежит в диапазоне 0000-05DC то принимается решение, что текущий протокольный блок относится к протоколу IEEE802.3 и это поле является длиной информационной части кадра (пакета). А если значения данных полей лежит вне этого диапазона, то принимается решение, что текущий протокольный блок относится к протоколу Ethernet, и поле указывает тип следующего протокола. <

Основы технологии

Ethernet был разработан Исследовательским центром в Пало Альто (PARC) корпорации Xerox в 1970-м году. Ethernet стал основой для спецификации IEEE 802.3, которая появилась 1980-м году. После недолгих споров компании Digital Equipment Corporation, Intel Corporation и Xerox Corporation совместно разработали и приняли спецификацию (Version 2.0), которая была частично совместима с 802.3. На сегодняшний день Ethernet и IEEE 802.3 являются наиболее распространенными протоколами локальных вычислительных сетей (ЛВС). Сегодня термин Ethernet чаще всего используется для описания всех ЛВС работающих по принципу множественный доступ с обнаружением несущей (carrier sense multiple access/collision detection (CSMA/CD)), которые соотвествуют Ethernet, включая IEEE 802.3.

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

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

Разрешение первой проблемы оказалась достаточно простой, так как форматы протоколов Ethernet  и  IEEE802.3. отличаются только одним полем. Подробнее...

Для решения второй проблеммы потребовалось использование дополнительного протокола IEEE802.2 после протокола IEEE802.3. Содержащее идентификаторы точек доступа к услугам получателя и отправителя. Данные идентификаторы позволяют указывать тип следующего протокола. Однако перечень типов точек оказался достаточно узким, поэтому для его расширения стали использовать дополнительный протокол SNAP, содержащей поле тип следующего протокола, аналогичное полю протокола Ethernet. 

Возможные цепочки протоколов

приведены на рисунке.

В основном используется цепочка содержащая только протокол Ethernet. В случае  одновременного использования сети NetWare и TCP/IP применяются: протокол Ethernet для передачи трафика TCP/IP и цепочка протоколов IEEE802.3-IEEE802.2 для протокола IPX (NetWare). Используется механизм соглования протоколов Ethernet и IEEE802.3.

Однако возможно использование только единственной цепочки IEEE802.3 - IEEE802.2 - SNAP. <

Протокол IEEE802.2 LLC

IEEE 802.2 часто называют Logical Link Control (LLC)

(Управление логическим каналом связи). Он чрезвычайно популярен в окружениях LAN, где ониспользуется после протоколов IEEE 802.3, IEEE 802.4 и IEEE 802.5.

IEEE 802.2 предлагает три типа услуг. Тип 1 обеспечивает услуги без установления соединения и подтверждения о приеме. Тип 2 обеспечивает услуги с установлением соединения. Тип 3 обеспечивает услуги без установления соединения с подтверждением о приеме.

Являясь обслуживанием без установления соединения и подтверждения о приеме, Тип 1 LLC не подтверждает передачу данных. Т.к. большое число протоколов верхнего уровня, таких как Transmissin Control Protocol/ Internet Protocol (ТCP/IP), обеспечивают надежную передачу информации, которая может компенсировать недостаточную надежность протоколов низших уровней, Тип 1 является широко используемой услугой.

Обслуживание Типа 2 LLC (часто называемое LLC2) организует виртуальные цепи между отправителем и получателем и, следовательно, является обслуживанием с установлением соединения. LLC2 подтверждает получение информации; оно используется в системах связи IBM.

Обеспечивая передачу данных с подтверждением, обслуживание Типа 3 LLC не организует виртуальных цепей. Являясь компромиссом между двумя другими услугами LLC, Тип 3 LLC бывает полезным в окружениях фабричных автоматизированных систем, где обнаружение ошибок очень важно, однако область памяти контекста (для виртуальных цепей) чрезвычайно ограничена.

Конечные станции могут обеспечить множество типов услуг LLC. Устройство Класса 1 обеспечивает только услуги Типа 1. Устройство Класса II обеспечивает как услуги Типа 1, так и услуги Типа 2. Устройства Класса III обеспечивает услуги Типа 1 и Типа 3, в то время как устройства Класса IV обеспечивают все три типа услуг.

Процессы высших уровней используют услуги IEEE 802.2 через "точки доступа к услугам" (SAP). Заголовок IEEE 802.2 начинается с поля "точки доступа к услугам пункта назначения" (DSAP), которое идентифицирует принимающий процесс высшего уровня.

Другими словами, после того, как реализация IEEE 802.2 принимающего узла завершит свою обработку, процесс высшего уровня, идентифицированный в поле DSAP, принимает оставшиеся данные. За адресом DSAP следует адрес "точки доступа к услугам источника" (SSAP), который идентифицирует передающий процесс высшего уровня.

Структура протокольного блока IEEE802.2-LLC показана на рисунке.

Разряды 7 6 5 4 3 2 1 0

DSAP - точка доступа к услуге отправителя

SSAP - точка доступа к услуге получателя

управление

Данные . . .

Ниже приведено закрепление значений полей "точка доступа" (рекомендация RFC-1700).

IEEE Internet

binary binary decimal

00000000 00000000 0 Null LSAP

01000000 00000010 2 Indiv LLC Sublayer Mgt

11000000 00000011 3 Group LLC Sublayer Mgt

00100000 00000100 4 SNA Path Control

01100000 00000110 6 Reserved (DOD IP)

01110000 00001110 14 PROWAY-LAN

01110010 01001110 78 EIA-RS 511

01111010 01011110 94 ISI IP

01110001 10001110 142 PROWAY-LAN

01010101 10101010 170 SNAP

00000111 11100000 208 IPX (Nowell)

01111111 11111110 254 ISO CLNS IS 8473

11111111 11111111 255 Global DSAP

Как видно из данного списка, протокол позволяет указать тип следующего за ним протокола более верхнего уровня.

Поле "управление" равно 3 для передачи пакетов   IPX.

 

Протокол IEEE802.3-MAC

Назначение - передача МАС-кадров между абонентами ЛВС. Используется как непосредственно в Ethernet сетях, так и при связи сегментов сетей через другие среды (Frame Relay, ATM и др.).  Состав полей кадра пакета приведен в таблице. Первый байт каждого поля старший. При передаче через физическую среду передачи данных (кабель), упаковывается между стартовой преамбулой и хвостовиком кадра.

Размер поля в байтах	Назначение
6	MAC - адрес получателя
6	MAC - адрес отправителя
2	длина информационной части  дейтаграммы
45 - 1500	данные (802.2 заголовок и данные)
4	контрольная сумма

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

Протокол SNAP

Обеспечивает уточнение протокола дальнейшей обработки. Как правило используется после протокола IEEE 802.2.

Структура протокольного блока

Байты	Назначение
0 ... 2	резерв
3, 4	тип следующего протокола
. . .	данные

Значения поля "тип следующего протокола" определены в рекомендации RFC1700. Данное поле с теми же значениями используется также в протоколах Bridge* и Router* (название условное). Назначение полей приведено здесь.

Протоколы локальных сетей

На уровне физического взаимодействия локальных сетей используются различные протоколы доступа к физической среде и различные протоколы уровня звена передачи данных. (См. модель ЭМВОС)

Существует множество различных типов локальных сетей: Ethernet, FastEthernet, TokenRing и другие. Все они отличаются в основном только протоколами доступа к физической среды (физический уровень ЭМВОС). В то-же время протоколы звена передачи данных (канальный уровень ЭМВОС) достаточно одинаковы. По крайней мере все они содержат поля МАС-адресов.

В данном обзоре остановимся подробнее пока только на следующих протоколах канального уровня:

	Ethernet
	IEEE802.3
	IEEE802.2
	SNAP

Протоколы данного уровня достаточно разнообразны. Это многообразие сложилось исторически.

Сначало был внедрен протокол Ethernet в 1970 году. Это был достаточно прогрессивный протокол. Он уже тогда позволял передавать над собой различные сетевые протоколы, так как имел поле тип следующего протокола.

Затем на его основе был разработан протокол типа IEEE802.3, который начал активно использоваться в сетях фирмы Nowell. В отличие от протокола Ethernet он включал в свой состав поле длины дейтаграммы, что облегчало работу сети,   и упрощал функционирование сетевых карт, но было исключено поле - тип следующего протокола. На этом этапе развития локальные сети были достаточно просты, в них использовалась только одна сетевая архитектура, в основном Nowell NetWare. Тип протоколов канального уровня просто указывался в файле конфигурации сетевых карт. Проблем обеспечения мультипротокольности не возникало. В то время сетевый протоколы могли начинаться сразу после протокола IEEE802.3. По мере своего развития локальные сети стали гетерогенными, стали одновременно использовать различные сетевые архитектуры и типы физических сред.

Перечислим возникшие проблемы:

	в одном сетевом сегменте могли оказаться рабочие станции использующие как протокол Ethernet, так и протокол IEEE802.3.
	рабочие станции использовали одновременно несколько сетевых архитектур

Архитектура управления сети

Большинство архитектур управления сети используют одну и ту же базовую структуру и набор взаимоотношений. Конечные станции (managed devices - управляемые устройства), такие как компьютерные системы и другие сетевые устройства, прогoняют программные средства, позволяющие им посылать сигналы тревоги, когда они распознают проблемы. Проблемы распознаются, когда превышен один или более порогов, заданных пользователем. Management entities (управляющие об'екты) запрограммированы таким образом, что после получения этих сигналов тревоги они реагируют выполнением одного, нескольких или группы действий, включающих:

Уведомление оператора

Регистрацию события

Отключение системы

Автоматические попытки исправления системы

Управляющие об'екты могут также опросить конечные станции, чтобы проверить некоторые переменные. Опрос может быть автоматическим или его может инициировать пользователь. На эти запросы в управляемых устройствах отвечают "агенты". Агенты - это программные модули, которые накапливают информацию об управляемом устройстве, в котором они расположены, хранят эту информацию в "базе данных управления" и предоставляют ее (проактивно или реактивно) в управляющие об'екты, находящиеся в пределах "систем управления сети" (NMSs), через протокол управления сети. В число известных протоколов управления сети входят "the Simple Network Management Protocol (SPMP)" (Протокол Управления Простой Сети) и "Common Management Information Protocol (CMIP)" (Протокол Информации Общего Управления). "Management proxies" (Уполномоченные управления) - это об'екты, которые обеспечивают информацию управления от имени других об'ектов. Типичная архитектура управления сети показана на рисунке.

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

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

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

Модель управления сети ISO

ISO внесла большой вклад в стандартизацию сетей. Модель управления сети этой организации является основным средством для понимания главных функций систем управления сети. Эта модель состоит из 5 концептуальных областей:

Управление эффективностью

Управление конфигурацией

Управление учетом использования ресурсов

Управление неисправностями

Управление защитой данных

Управление эффективностью

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

Управление эффективностью включает несколько этапов:

Сбор информации об эффективности по тем переменным, которые предствляют интерес для администраторов сети.

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

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

Управляемые об'екты постоянно контролируют переменные эффективности. При превышении порога эффективности вырабатывается и посылается в NMS сигнал тревоги.

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

Управление конфигурацией

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

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

Каждое устройство сети располагает разнообразной информацией о версиях, ассоциируемых с ним. Например, АРМ проектировщика может иметь следующую конфигурацию:

	Операционная система, Version 3.2
	Интерфейс Ethernet, Version 5.4
	Программное обеспечение TCP/IP, Version 2.0
	Программное обеспечение NetWare, Version 4.1
	Программное обеспечение NFS, Version 5.1
	Контроллер последовательных сообщений, Version 1.1
	Программное обеспечение Х.25, Version 1.0
	Прoграммное обеспечение SNMP, Version 3.1

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

Управление учетом использования ресурсов

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

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



Управление неисправностями

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

Управление неисправностями включает в себя несколько шагов:

Определение симптомов проблемы.

Изолирование проблемы.

Устранение проблемы.

Проверка устранения неисправности на всех важных подсистемах.

Регистрация обнаружения проблемы и ее решения.

Управление защитой данных

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

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

Подсистемы управления защитой данных выполняют следующие функции:

	Идентифицируют чувствительные ресурсы сети (включая системы, файлы и другие об'екты)
	Определяют отображения в виде карт между чувствительными источниками сети и набором пользователей
	Контролируют точки доступа к чувствительным ресурсам сети
	Регистрируют несоответствующий доступ к чувствительным ресурсам сети.

<

Основы управления сетями

	Библиографическая справка
	Архитектура управления сети
	Модель управления сети ISO Управление эффективностью Управление конфигурацией Управление учетом использования ресурсов Управление неисправностями Управление защитой данных

Адреса

Source Address (адрес отправителя) 32 бита

Destination Address (адрес получателя) 32 бита

Адресация

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

Форматы адресации

Старшие биты	Формат	Класс
0	7 бит в сети, 24 бита для хостов	А
10	14 бит в сети, 16 бит для хостов	В
110	21 бит для сети, 8 бит для хостов	С
111	переход в расширенный режим адресации

Нулевое значение в поле сети означает данную сеть. Этот режим используется только в определенных ICMP сообщениях. Расширенный режим адресации неопределен. Обе эти возможности зарезервированы для будущих реализаций. Реальные значения, присваиваемые сетевым адресам, даны в документе "Assigned Numbers".

Локальный адрес, присвоенный локальной сети, должен позволять одиночному физическому хосту работать как несколько отдельных Internet хостов. А именно, должен существовать промежуток между адресами Internet хостов и должны присутствовать интерфейсы между сетью и хостом, которые позволили бы нескольким Internet адресам соответствовать одному интерфейсу. Хост должен иметь возможность для поддержки нескольких физических интерфейсов и для обработки датаграмм с любого из них, как если бы они были адресованы к единственному хосту.

Карта соответствия между Internet адресами и адресами таких сетей, как ARPANET, SATNET, PRNET и др. описаны в документе "Address Mapping".

Автоматизация процесса назначения IP-адресов узлам сети - протокол DHCP

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

Протокол Dynamic Host Configuration Protocol (DHCP) был разработан для того, чтобы освободить администратора от этих проблем. Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

В ручной процедуре назначения адресов активное участие принимает администратор, который предоставляет DHCP-серверу информацию о соответствии IP-адресов физическим адресам или другим идентификаторам клиентов. Эти адреса сообщаются клиентам в ответ на их запросы к DHCP-серверу.

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

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

DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.

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

Протокол DHCP использует модель клиент-сервер. Во время старта системы компьютер-клиент DHCP, находящийся в состоянии "инициализация", посылает сообщение discover (исследовать), которое широковещательно распространяется по локальной сети и передается всем DHCP-серверам частной интерсети. Каждый DHCP-сервер, получивший это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию.

Компьютер-клиент DHCP переходит в состояние "выбор" и собирает конфигурационные предложения от DHCP-серверов. Затем он выбирает одно из этих предложений, переходит в состояние "запрос" и отправляет сообщение request (запрос) тому DHCP-серверу, чье предложение было выбрано.

Выбранный DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для этого адреса. Кроме того, DHCP-сервер посылает параметры сетевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние "связь", находясь в котором он может принимать участие в работе сети TCP/IP. Компьютеры-клиенты, которые имеют локальные диски, сохраняют полученный адрес для использования при последующих стартах системы. При приближении момента истечения срока аренды адреса компьютер пытается обновить параметры аренды у DHCP-сервера, а если этот IP-адрес не может быть выделен снова, то ему возвращается другой IP-адрес.

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

Однако использование DHCP несет в себе и некоторые проблемы. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS. Как известно, DNS служит для преобразования символьных имен в IP-адреса. Если IP-адреса будут динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.

Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов. Аналогичные проблемы возникают и при конфигурировании фильтров маршрутизаторов, которые оперируют с IP-адресами.

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

Flags (различные управляющие флаги) 16 бит

бит 0	зарезервирован, должен быть нуль
бит 1 (DF)	0 - возможно фрагментирование, 1 - запрет фрагментации
бит 2 (MF)	0 - последний фрагмент, 1 - будут еще фрагменты

0	1	2
0	DF	MF

Формат заголовка Internet

Межсетевые дейтаграммы (МД) содержат полные адреса и могут передаваться независимо друг от друга, в том числе по различным маршрутам. Межсетевая маршрутизация МД осуществляется в шлюзах (маршрутизаторах). Данные, поступившие для передачи, могут разбиваться на сегменты и передаваться в виде нескольких самостоятельных МД. Длина МД определяется характеристиками шлюзов, подключенных к сети. Рекомендуемые размеры МД - не более 576 байт, но возможна передача дейтаграмм длиной до 2048 байт (в последней спецификации Unix допускаются дейтаграммы до 64 кбайт).

Протокол IPv6 решает потенциальную проблему

Протокол IPv6 решает потенциальную проблему нехватки IP- адресов посредством использования 128- разрядных адресов вместо 32- разрядных адресов IPv4, благодаря чему адресное пространство расширяется в 296 раз. Формат заголовка приведен на рис.1.

0

8

16

31

Version	Prio	Flow Label
Payload Length	Next Header	Hop Limit
Source Address
Destination Address

Рис. 1. Основной заголовок протокола IPv6

Version (4 бита). Версия протокола. Значением этого поля равно 6.



Prio (4 бита). Приоритет. Поле приоритета позволяет отправителю назначать дейтаграмме определенный уровень приоритета по отношению к другим отправляемым пакетам. Возможные 16 значений этого поля разделены на две категории: значение поля от 0 до 7 используется для дейтаграмм, которые могут не передаваться при слишком переполненной линии. Сюда относится ТСР - трафик, передача e-mail, FTP, NFS, TELNET, X-interactive. Значения поля от 8 до 15 назначаются пакетам, которые должны быть отправлены при любом состоянии (кроме обрыва) линии. Например, приоритет 8 пользователь может назначить пакетам, которые он может позволить себе отправить в последнюю очередь при перегруженной линии, а приоритет 15 — в первую. Последние представляют пакеты реального времени с видео-, аудио- и аналогичными данными, которые должны передаваться с постоянной скоростью.


Метка потока. Это поле может использоваться отправителем для того, чтобы помечать пакеты, которые требуют специальной обработки сетевыми модулями IPv6. Хосты или шлюзы, не поддерживающие этой опции, должны установить это поле в 0 и игнорировать при обработке пакета.

Поток представляет собой последовательность пакетов, отправляемых определенному получателю (или группе получателей), на пути к которым пакеты должны пройти специальную обработку (например, информация о прохождении определенного потока будет регистрироваться). Таких потоков между одними и теми же хостами может быть несколько, и значение этого поля позволяет идентифицировать отдельный поток. Если значение этого поля установлено в 0, то считается, что дейтаграмма не принадлежит ни к какому потоку. Меткой потока служит псевдо-случайное число в диапазоне 1 — FFFFFF. Это число также может служить хеш-ключом для шлюзов-обработчиков определенного потока.

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



Payload Length (16 бит). Длина данных. Это длина данных пакета (в байтах), которые следуют за заголовком. Если величина этого поля равна 0, то длина данных дейтаграммы более 65535 и хранится в поле Jumbo Payload (сверхдлина) заголовка Hop-by-Hop Options (см. далее).

Поле протокола IPv4 Total Length было переименовано в протоколе IPv6 в поле Payload Length.



Эти два поля сходны между собой, но не тождественны, поскольку поле Payload Length содержит длину данных после заголовка, в то время как поле Total Length учитывает длину заголовка.



Next Header (8 бит). Поле следующего заголовка. Это поле содержит информацию типа заголовка, который следует за заголовком IPv6.

Еще одно переименованное и измененное поле IPv4 — это поле Protocol. Оно превратилось в поле Next Header в IPv6. В IPv4 значение поля Protocol, например 6 для TCP или 17 для UDP, определяет, данные какого транспортного протокола следуют за IP-заголовком. В IPv6 поле Next Header позволяет вставлять дополнительные заголовки между данными IP и TCP или UDP. Оно также сообщает тип транспортных данных, следующих за основным или дополнительным IP-заголовком. Кроме того, так как поле Next Header предоставляет информацию о наличии дополнительных заголовков, следующих за основным, данный механизм исключает необходимость в поле Internet Header Length, или IHL.



Hop Limit (8 бит). Поле ограничения пересылок. Величина этого поля уменьшается на 1 при прохождении дейтаграммой шлюза или хоста. Если величина этого поля равна 0, дейтаграмма уничтожается.

Единица измерения в поле Time to Live в IPv4 — секунды. Однако при прохождении пакета через маршрутизатор, ввиду трудности определения времени ожидания в очереди, значение этого поля уменьшается реально на 1 секунду. Признав эффективность использования числа транзитных маршрутизаторов в качестве способа определения срока жизни пакета, IPng Directorate заменил поле Time To Live на поле Нор Limit в IPv6.



Source Address (128 бит). Адрес отправителя.



Destination Address (128 бит). Адрес получателя. Если в заголовке присутствует вложенный заголовок маршрутизации (Routing header), это поле может и не быть адресом назначения.



Адресация IPv6



Адреса назначения и источника в IPv6 имеют длину 128 бит или 16 байт. Версия 6 обобщает специальные типы адресов версии 4 в следующих типах адресов:

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

<



/p>

Как и в версии IPv4, адреса в версии IPv6 делятся на классы, в зависимости от значения нескольких старших бит адреса.

Большая часть классов зарезервирована для будущего применения. Наиболее интересным для практического использования является класс, предназначенный для провайдеров услуг Internet, названный Provider-Assigned Unicast.

Адрес этого класса имеет следующую структуру:

0

3

8

N

64

127

010

Registry ID

Provider ID

Subscriber ID

Intra- Subscriber

Поле RegistryID идентифицирует ответственную за присвоение адреса регистратуру Internet, например, InterNIC в Северной Америке или APNIC в Азии. Поле ProviderID идентифицирует оператора Internet. Поле SubscriberID, ответственность за назначение которого несет оператор, идентифицирует конкретного пользователя. Оставшиеся 64 разряда в адресе по принадлежности к провайдеру идентифицируют сеть и хост во многом тем же образом, что и адреса IPv4 с класса А по класс С.

Каждому провайдеру услуг Internet назначается уникальный идентификатор, которым помечаются все поддерживаемые им сети. Далее провайдер назначает своим абонентам уникальные идентификаторы, и использует оба идентификатора при назначении блока адресов абонента. Абонент сам назначает уникальные идентификаторы своим подсетям и узлам этих сетей.

Абонент может использовать технику подсетей, применяемую в версии IPv4, для дальнейшего деления поля идентификатора подсети на более мелкие поля.



Описанная схема приближает схему адресации IPv6 к схемам, используемым в территориальных сетях, таких как телефонные сети или сети Х.25. Иерархия адресных полей позволит магистральным маршрутизаторам работать только со старшими частями адреса, оставляя обработку менее значимых полей маршрутизаторам абонентов.

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

Для обеспечения совместимости со схемой адресации версии IPv4, в версии IPv6 имеется класс адресов, имеющих 00000000 в старших битах адреса. Младшие 4 байта адреса этого класса должны содержать адрес IPv4. Маршрутизаторы, поддерживающие обе версии адресов, должны обеспечивать трансляцию при передаче пакета из сети, поддерживающей адресацию IPv4, в сеть, поддерживающую адресацию IPv6, и наоборот.

В IPv6 128-разрядные адреса записываются в виде восьми 16-разрядных целых чисел, разделенных двоеточием. Каждое целое число представлено четырьмя шестнадцатеричными цифрами; иными словами, вы будете вынуждены ввести 32 шестнадцатеричных цифры для задания IP-адреса. При задании адреса IPv6 разрешает опустить начальные нули в шестнадцатеричных числах, а также использовать пару двоеточий (::) внутри адреса для замены последовательности нулевых чисел.

В качестве иллюстрации мы рассмотрим следующий 128-разрядный адрес:

501А.-0000: 0000:0000:OOFC: ABCD: 3F1F:3D5A. Так как IPv6 позволяет пропустить начальные нули в каждом блоке из 4 шестнадцатеричных цифр в адресе, данный адрес можно записать в сокращенном виде следующим образом: 501A:0:0:0:FC:ABCD:3F1F:3D5A. Однако, если воспользоваться принятым соглашением об исключении последовательных блоков нулей, адрес можно записать еще короче 501A::FC: ABCD:3F1F:3D5A. Теперь адрес состоит всего из пяти шестнадцатеричных чисел вместо восьми. Таким образом, пара двоеточий представляет 3 целых числа, значение которых равно нулю.



Инкапсуляция заголовка



Протокол IPv6 предусматривает возможность помещения отдельных дополнительных заголовков между IP- заголовкам и заголовком транспортного уровня.



Каждый дополнительный заголовок содержит тип следующего за ним заголовка. В настоящее время спецификация IPv6 определяет шесть типов дополнительных заголовков. Ниже следует описание этих заголовков в том порядке, в каком их рекомендовано помещать друг за другом.

Протокол IPv6 организован таким образом, что часть информации, которая относится к Internet-уровню и носит дополнительный характер, может размещаться между основным заголовком IPv6 и заголовком пакета верхнего уровня (например,TCP). Эти заголовки представляют собой блоки данных, каждый из которых отвечает за выполнение собственных функций. В каждом из них содержится поле идентификатора следующего заголовка.

На рис. 2. представлена схема пакета IPv6 без дополнительных заголовков. За основным заголовком IPv6 идет структура TCP.

Ipv6 header Next header = TCP

TCP header + data

Рис. 2. Структура пакета Ipv6 без дополнительных заголовков.



На рис. 3 представлена структура пакета IPv6 с одним дополнительным заголовком пакета, определяющим маршрутизацию дейтаграммы, за ним идет структура TCP.

Ipv6 header Next header = Routing

Routing header Next header = TCP

TCP header + data

Рис. 3. Структура пакета Ipv6 с одним дополнительным заголовком пакета.



На рис. 4 представлена схема пакета IPv6 с двумя дополнительными заголовками, за которыми идет структура TCP.

Ipv6 header Next header = Routing

Routing header Next header = Fragment

Fragment header Next header = TCP

TCP header + data

Рис. 4. Структура пакета Ipv6 с двумя дополнительными заголовками.



Полная спецификация протокола IPv6 включает следующие заголовки (приводим их в порядке следования в дейтаграмме):

1. IPv6 header.

2. Hop-by-Hop Options header.

3. Destination Options header (опции получателя 1). Этот заголовок обрабатывается первым получателем, адрес которого указан в поле адреса назначения основного заголовками получателями, перечисленными в заголовке маршрутизации (Routing).

4. Routing header (маршрутизация).

5. Fragment header (фрагментация).

6. Authentication header (аутентификация).

7. Encapsulating Security Payload header (дополнительная аутентификация). Обсуждение этого протокола выходит за рамки данной книги.

8. Destination Options header (опции получателя 2). Этот заголовок обрабатывается только на хосте назначения. Заголовок Destination Option header-1 и заголовок Destination Option header-2 используются для передачи определенных параметров обработки пакета, обсуждение которых выходит за рамки данной книги.

<



/p>

9. Заголовок верхнего уровня (например, TCP).



Hop-by-Hop Options Header



Заголовок ( его формат представлен на рис. 5) содержит информацию, которая должна проверяться на каждом узле по пути следования пакета. Его идентификатор в основном заголовке — число 0.

0

8

16

31

Next Header	Hdr Ext Len	Options

Рис.4. Формат Hop-by-Hop Options Header

Next Header (8 бит). Поле идентифицирует тип следующего заголовка.



Hdr Ext Len (8 бит). Длина данного заголовка в 64-битных единицах (не считая первые 64 бита).



Options. Поле дополнительных параметров. Оно содержит параметры, определяющие некоторые стандартные операции над дейтаграммой. Кроме этих параметров, поле Options заголовка Hop-by-Hop Options содержит параметр Jumbo Payload (сверхдлина). Он используется IPv6 в тех пакетах, длина которых более 65535 байт. Значение этого параметра представляет собой длину пакета в байтах, включая длину заголовка Hop-by-Hop Options и должно быть больше 65535. При этом значение поля Payload Length в основном заголовке IPv6 должно содержать 0.



ПРИМЕЧАНИЕ.



Следует помнить, что опция Jumbo Payload не используется, если пакет содержит заголовок фрагментации (Fragment header).



Routing Header (заголовок маршрутизации)



Заголовок (рис. 6) используется отправителем IPv6 для того, чтобы указать пакету список (состоящий из одного или более) промежуточных хостов, через которые пакет должен пройти по пути к адресу назначения. Эта функция очень похожа на аналогичную (LSRR или SSRR) в IPv4.



Заголовок маршрутизации идентифицируется значением 43 в заголовке предыдущего заголовка.

0

8

16

24

31

Next Header	Hdr Ext Len	Routing Type	Segments Left
Type – specific data

 Рис.6. Заголовок Routing header



 Next Header (8 бит). Поле идентификатора следующего заголовка.



Hdr Ext Len (8 бит). Длина заголовка в 64-битных единицах.



Routing Type (8 бит). Поле идентификатора типа маршрутизации.



Segment Left (8 бит). Поле содержит количество тех промежуточных хостов (из указанных в списке), которые дейтаграмма посетила перед приходом к получателю.



Type-specific data. Поле данных. Структура этого поля определяется форматом типа маршрутизации (Routing Type). Поле выравнивается по 64-битной границе.

В качестве примера рассмотрим структуру этого заголовка Routing Type = 0 (рис.7).

0

8

16

24

31

Next Header	Hdr Ext Len	Routing Type = 0	Segments Left
Reserved	Strict/Loose Bit Map
Address [1]
. . .
Address [n]

<



/p>



Рис. 7. Заголовок маршрутизации (тип маршрутизации 0)



При значении поля Routing Type = 0, значение полей, описанных ранее не изменяется. Максимальное значение поля Segment Left будет равно 23. Если значение поля Segment Left равно 0, данный заголовок не учитывается и обработчик переходит к работе над заголовком, идентификатор которого указан в поле Next Header.

Reserved (8 бит). Поле не используется.

Strict/Loose Bit Map (24 бита). Каждый бит этого поля (слева направо) обозначает "видимость" каждого следующего сегмента маршрутизации (хост на пути к адресату) по отношению к предыдущему. Если соответствующий бит равен 1, это означает, что данный хост должен лежать в прямой видимости (быть следующим) от предшествующего хоста (шлюза). Если бит равен 0 — путь до следующего хоста может быть произвольным (сравните с полями опции IPv4 SSRR и LSRR). При обработке этого поля учитываются только биты с номерами до величины поля Segment Left.

Address[1..n]. 128-битные адреса.

Fragment header (заголовок фрагментации)



Заголовок фрагментации (рис. 8) используется в IPv6 для отправки пакетов, размер которых превышает допустимый размер дейтаграммы, которая может быть передана через хосты, расположенные на пути к получателю. (Обратите внимание, в версии IPv4 фрагментация могла производиться по пути следования дейтаграммы прозрачно для отправителя, в версии IPv6 фрагментировать дейтаграмму может только отправитель). Идентификатор заголовка равен 44.

0

8

16

28

31

Next Header	Reserved	Fragment Offset	Res	M
Identification

<



/p>



Рис. 8. Заголовок фрагментации

Next Header (8 бит). Поле идентификатора следующего заголовка.



Reserved (8 бит). Поле не используется.



Fragment Offset (13 бит). Поле смещения фрагмента. Смещение задается в 64-битных единицах по отношению к началу фрагментируемой части пакета.



Res (2 бита). Поле принимает значение 0 в случае передачи и игнорируется и случае приема пакета.



М (1 бит). Поле принимает значение 1, если имеется следующий фрагмент, и 0, если этот фрагмент последний.



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



Authentication header (заголовок аутентификации)



Заголовок аутентификации АН (Authentication Header) представляет собой механизм, который обеспечивает целостность передаваемых данных и аутентификацию отправителя на уровне IP-протокола как для IPv4, так и для IPv6. Он обеспечивает защиту передаваемой информации благодаря шифрованию данных на основе криптографического ключа с использованием асимметричных методов кодирования (например, RSA). Данный механизм безопасности более эффективен, чем ранее использовавшийся в IPv4.

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

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



Значения полей и опций дейтаграммы, изменяющиеся в процессе передачи, при вычислении информации аутентификации полагаются равными 0.

Информация аутентификации определяется отправителем дейтаграммы и проверяется только получателем данного пакета. Поскольку промежуточные хосты (или шлюзы) никак не контролируют безопасность передачи, наличие АН не сказывается на скорости обработки пакета. Кроме того, наличие АН ни к чему не обязывает уже сложившуюся инфраструктуру Internet. Данные АН расположены в отдельном заголовке (в случае IPv6 АН располагается после заголовка фрагментации, в случае IPv4 — сразу после основного заголовка IPv4) и, если система не работает с пакетами с АН, она их попросту может игнорировать.

Данные пакета шифруются криптостойким алгоритмом с использованием несимметричного секретного ключа. Структура пакета построена таким образом, что алгоритм работы с секретным ключом не интегрирован в механизм аутентификации IP.

Такое разделение позволяет использовать разные механизмы генерации ключа без изменений основных принципов IP-безопасности. Для того чтобы не передавать ключи и множество параметров алгоритма шифрования для каждого шифруемого пакета, механизм генерации ключа строит логическую таблицу соответствий SA (Security Association), хранящую параметры для каждой шифруемой пары (ключ-алгоритм). Механизм IP АН должен прочитать запись этой таблицы, чтобы определить алгоритм и ключ, используемый при аутентификации каждой дейтаграммы.

При формировании отправляемого IP АН-пакета, первым шагом является построение ассоциации в таблице SA для данной дейтаграммы. Выбор ассоциации в SA осуществляется на основе идентификатора отправителя и адреса получателя пакета. Выбранная SA ассоциация определяет алгоритм, тип алгоритма, ключ и другие параметры шифрования.

Своеобразным связующим звеном между механизмом построения ключа и выбором алгоритма является индекс соответствия параметров шифрования SPI (Security Parameters Index). Это своеобразный код таблицы ассоциаций SA (Security Association), передаваемый в IP АН, по которому (в совокупности с адресом получателя) и происходит поиск соответствия в таблице SA получателя, т.



е., при поступлении пакета, содержащего IP АН, получатель, на основании адреса назначения пакета и значения поля SPI заголовка АН дейтаграммы, определяет запись в таблице соответствий SA, тем самым определяет алгоритм и ключ дешифровки (дополнительную часть несимметричного ключа). Затем он проверяет целостность и дешифрует данные.

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

Например, его положение может быть таким IPv6 (рис. 9):

0

8

16

31

Next Header	Length	Reserved
Security Parameters Index
Authentication Data

Рис. 9. Формат АН-заголовка

Next Header (8 бит). Поле идентификатора следующего заголовка.



Length (8 бит). Добавочная длина. Это поле содержит длину данных аутентификации в 32-битных единицах. Минимальное значение этого поля равно 0, что означает отсутствие шифрования данных (нулевой алгоритм).



Reserved (16 бит). Поле не используется.



Security Parameters Index (SPI) (32 бита). Поле индекса параметра. Псевдослучайное число, определяющее индекс соответствия в SA (определяющей тип алгоритма, параметры шифрования и т. д.). Значение равное 0 используется при отсутствии соответствий, значения 1—255 зарезервированы.



Authentication Data. Данные аутентификации — это результат работы алгоритма шифрования на основании содержимого всей дейтаграммы (неизменяемых в процессе передачи полей). Данные аутентификации сохраняют свой формат (но не содержание) для определенной пары (SPI и адрес получателя).

Наряду с заголовком АН, для обеспечения секретности передаваемых данных используется другой "псевдопротокол" IP Encapsulating Security Payload (ESP). Он построен примерно по тем же принципам, что и IP АН. <



table border="0" cellpadding="0" cellspacing="0" width="100%">
Flow Label (24 бита).

Форматы сообщений ICMP

ICMP сообщения посылаются с помощью стандартного IP заголовка. Первый октет в поле данных датаграммы - это поле типа ICMP сообщения. Значение этого поля определяет формат всех остальных данных в датаграмме. Любое поле, которое помечено "unused", зарегистрировано для последующих разработок и должно при отправлении содержать нули. Однако получатель не должен использовать значения этих полей (за исключением процедуры вычисления контрольной суммы). Если обратное особо не оговорено при описании отдельных фрагментов, Internet заголовок должен иметь в своих полях следующие значения:

Версия

4

IHL

Длина Internet заголовка; единица измерения - 32-битное слово.

Тип сервиса

0

Общая длина

Длина Internet заголовка и поля данных в октетах.

Идентификация, флаги, смещение фрагмента

Используются в случае фрагментации.

Время жизни

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

Протокол

ICMP=1

Контрольная сумма заголовка

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

В дальнейшем этот алгоритм вычисления контрольной суммы должен быть изменен.

Адрес отправления

Адрес шлюза или хост-компьютера, который составил данное ICMP сообщение. Если не оговорено обратное, в этом поле может находиться любой из адресов шлюза.

Адрес получателя

Адрес шлюза или хост-компьютера, которому следует послать данное сообщение.

Сообщение о недостижимости порта

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
не используется
Internet заголовок + 64 бита данных из исходной датаграммы

Поля Internet протокола:

Адрес получателя

Локальная сеть и адрес компьютера, отправившего исходную датаграмму

Поля ICMP протокола

Тип

3

Код

0	невозможно передать датаграмму на локальную сеть, где находится адресат
1	невозможно передать датаграмму на хост-компьютер, являющийся адресатом
2	нельзя воспользоваться указанным протоколом
3	нельзя передать данные на указанный порт
4	для передачи датаграммы по сети требуется фрагментация, однако выставлен флаг DF.
5	сбой в маршрутизации при отправлении

Контрольная сумма

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

Internet заголовок + 64 бита данных из исходной датаграммы

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

Описание

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

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

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

Шлюз может послать сообщения с кодами 0, 1, 4 и 5. Хост-компьютер может послать сообщения с кодами 2 и 3.

Сообщение о превышении контрольного времени

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
не используется
Internet заголовок + 64 бита данных из исходной датаграммы

Поля IP заголовка

Заимствованы сеть и адрес отправителя из исходной датаграммы с данными. Поля ICMP сообщения

Тип

11

Код

0	при передаче превышено время жизни
1	превышено контрольное время при сборке фрагментов датаграммы

Контрольная сумма

Контрольная сумма является 16-битным дополнением до единицы суммы дополнений в ICMP сообщении, начиная с поля типа ICMP.

При вычислении суммы следует сперва обнулить поле контрольной суммы. В будущем алгоритм контрольной суммы может быть изменен.

Internet заголовок + 64 бита данных из исходной датаграммы

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

Описание

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

Шлюз может послать сообщение с кодом 0, а хост - с кодом 1.

Сообщение о проблемах с параметром

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
указатель	не используется
Internet заголовок + 64 бита данных из исходной датаграммы

Поля IP заголовка

Заимствованы сеть и адрес отправителя из исходной датаграммы с данными. Поля ICMP сообщения

Тип

12

Код

0 - указатель показывает ошибку

Контрольная сумма

Контрольная сумма является 16-битным дополнением до единицы суммы дополнений в ICMP сообщении, начиная с поля типа ICMP.

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

Указатель

Если код = 0, то он указывает на октет, где была обнаружена ошибка.




Internet заголовок + 64 бита данных из исходной датаграммы

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

Описание

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

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

Сообщение для приостановки отправителя

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
не используется
Internet заголовок + 64 бита данных из исходной датаграммы

Поля IP заголовка

Заимствованы сеть и адрес отправителя из исходной датаграммы с данными.

Поля ICMP сообщения

Тип

4

Код

0

Контрольная сумма

Контрольная сумма является 16-битным дополнением до единицы суммы дополнений в ICMP сообщении, начиная с поля типа ICMP. При вычислении контрольной суммы следует сперва обнулить поле контрольной суммы. В будущем алгоритм вычисления контрольной суммы может быть изменен.

Internet заголовок + 64 бита данных из исходной датаграммы

Internet заголовок плюс первые 64 бита данных из исходной датаграммы.



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

Описание

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

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

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

Сообщение о переадресации

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
Internet адрес шлюза
Internet заголовок + 64 бита данных из исходной датаграммы

Поля IP заголовка

Заимствованы сеть и адрес отправителя из исходной датаграммы с данными.

Поля ICMP сообщения




Тип

5

Код

0	- переадресация датаграмм для сети
1	- переадресация датаграмм для хост-компьютера
2	- переадресация датаграмм для типа услуг и сети
3	- переадресация датаграмм для типа услуг и хост-компьютера

Контрольная сумма

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнений в ICMP сообщении, начиная с поля типа ICMP. При вычислении контрольной суммы следует сперва обнулить поле контрольной суммы. В будущем алгоритм вычисления контрольной суммы может быть изменен.

Internet адрес шлюза

Адрес шлюза, на который должен быть проложен маршрут к сети, указанной в поле адреса в исходной датаграмме с данными.

Internet заголовок + 64 бита данных из исходной датаграммы

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

Описание

Шлюз посылает сообщение на хост-компьютер о переадресации в следующей ситуации: Шлюз G1 получает Internet датаграмму от хост-компьютера в сети, где он расположен. Шлюз G1 проверяет таблицу маршрутизации и находит адрес следующего шлюза G2 в качестве маршрута для датаграммы по пути в сеть X, где расположен ее адресат. Если G2 и исходный хост-компьютер идентифицируются Internet адресом как находящиеся в одной и той же сети, то на хост-компьютер следует послать сообщение о переадресации. Сообщение о переадресации заставляет хост-компьютер посылать датаграммы для сети X прямо на шлюз G2, поскольку это более короткий путь, нежели привлекать еще шлюз G1. Шлюз передает данные исходной датаграммы их адресату в системе Internet.

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



Шлюзом могут быть переданы сообщения с кодами 0, 1, 2 и 3.

Эхо-сообщение и сообщение в ответ на эхо

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
Идентификатор	Номер очереди
Данные .....

Поля IP заголовка

Адреса

Адрес отправителя в эхо-сообщении будет адресом получателя в ответном сообщении. Чтобы сформировать сообщение ответа, следует просто переставить местами адреса отправителя и получателя, код типа изменить на 0 и пересчитать контрольную сумму.

Поля ICMP сообщения

Тип

8	- эхо-сообщение
0	- сообщение в ответ на эхо

Код

0

Контрольная сумма

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнений для ICMP сообщения, начиная с поля типа ICMP.

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

Идентификатор

Если код = 0, то идентификатор для соотнесения эхо-сообщений и ответов на них, должен быть обнулен.

Номер очереди

Если код = 0, то номер очереди, служащий для соотнесения эхо-сообщений и ответов на них, должен быть обнулен.

Описание

Данные из эхо-сообщения должны быть переданы в ответе на это сообщение.

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

Как шлюз, так и хост-компьютер могут возвращать сообщение с кодом 0.

Сообщение со штампом времени и сообщение с ответом на штамп времени

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
Идентификатор	Номер очереди
Штамп времени отправления
Штамп времени получения
Штамп времени передачи

<



/p>

Поля IP заголовка

Адреса

Адрес отправителя в сообщении со штампом времени будет адресом получателя в сообщении с ответом. Чтобы сформировать ответ на сообщение, следует просто поменять местами адреса отправителя и получателя, выбрать код типа 14, а также пересчитать контрольную сумму.

Поля ICMP сообщения

Тип

13	для сообщения со штампом времени
14	для ответа на сообщение со штампом времени

Код

0

Контрольная сумма

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнений для ICMP сообщения, начиная с поля типа ICMP.

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

Идентификатор

Если код = 0, то идентификатор, служащий для соотнесения сообщений со штампом времени и ответов на них, должен быть обнулен.

Номер очереди

Если код = 0, то номер очереди, служащий для соотнесения сообщений со штампом времени и ответов на них, должен быть обнулен.

Описание

Данные из сообщения (штамп времени) возвращаются вместе с ответом, при этом в них добавляется еще один штамп времени. Штамп времени - это 32 бита, где записано время в миллисекундах, прошедшее после полуночи по единому времени (UT).

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

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

Идентификатор и номер очереди могут использоваться отправителем для соотнесения сообщений (запросов) и ответов на них. На пример, идентификатор может использоваться в качестве порта, аналогично протоколам TCP и UDP, для идентификации сессии.



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

Запрос информации и ответное сообщение с информацией

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Тип	Код	Контрольная сумма
Идентификатор	Номер очереди

Поля IP заголовка

Адреса

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

Поля ICMP сообщения

Тип

15	- сообщение с запросом информации
16	- ответное сообщение с информацией

Код

0

Контрольная сумма

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнений для ICMP сообщения, начиная с поля типа ICMP. При вычислении контрольной суммы следует предварительно обнулить поле самой контрольной суммы. В будущем алгоритм вычисления контрольной суммы может быть изменен.

Идентификатор

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

Номер очереди

Если код = 0, то номер очереди, служащий для соотнесения запросов и ответов, может быть обнулен.

Описание

Данное сообщение может быть послано, когда в IP заголовке в полях отправителя и получателя записаны нули (это означает "именно эту" локальную сеть). В ответ должен быть послан IP модуль с полностью заданными адресами. Данное сообщение является способом, с помощью которого хост-компьютер сможет определить номер сети, куда он подключен.

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



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

И хост-компьютер и шлюз могут возвращать сообщения с кодом 0.

Список типов сообщений

0	ответ на запрос эхо
3	адресат недостижим
4	приостановка отправителя
5	переадресация
8	эхо-запрос
11	превышение контрольного времени
12	проблемы с параметрами
13	штамп времени
14	ответ на запрос штампа времени
15	запрос информации
16	ответ на запрос информации

 

Fragment Offset (смещение фрагмента) 13 бит

Это поле показывает, где в датаграмме находится этот фрагмент. Смещение фрагмента изменяется порциями по 8 октет (64 бита).

Первый фрагмент имеет смещение нуль.

Фрагментация и сборка

Поле Internet идентификации (ID) используется вместе с адресами отправителя и получателя, полями протокола для идентификации фрагментов датаграммы при сборке.

Бит флага More Fragments (MF) устанавливается, если датаграмма не является последним фрагментом. Поле Fragment Offset идентифицирует расположение фрагмента относительно начала в первоначальной не фрагментированной датаграмме. Единица измерения - 8 октетов.

Стратегия фрагментации разработана так, чтобы не фрагментированная датаграмма имела нули во всех полях с информацией о фрагментации (MF=0, Fragment Offset=0). Если же Internet датаграмма фрагментируется, то выделение информации производится кусками и по границе 8 октет.

Данный формат позволяет использовать 2**32=8192 фрагментов по 8 октетов каждый, а в целом 65536 октетов. Заметим, что это совпадает со значением поля общей длины для датаграммы (конечно, заголовок учитывается в общей длине датаграммы, но не фрагментов).

Когда происходит фрагментация, то некоторые опции копируются, а другие остаются лишь в первом фрагменте.

Каждый Internet модуль должен быть способен передать датаграмму из 68 октетов без дальнейшей фрагментации. Это происходит потому, что Internet заголовок может включать до 60 октетов, а минимальный фрагмент - 8 октетов. Каждый Internet - получатель должен быть в состоянии принять датаграмму из 576 октетов в качестве единого куска, либо в виде фрагментов, подлежащих сборке.

Процесс фрагментации может повлиять на предыдущие поля

(1)	- поле опций
(2)	- флаг "more fragments"
(3)	- смещение фрагмента
(4)	- поле длины Internet заголовка
(5)	- поле общей длины
(6)	- контрольная сумма заголовка

Если бит флага запрета фрагментации (Don't Fragment - DF) установлен, то Internet фрагментация данной датаграммы запрещена, даже если она может быть разрушена. Данное средство может использоваться для предотвращения фрагментации в тех случаях, когда хост-получатель не имеет достаточных ресурсов для сборки Internet фрагментов.

Одним из примеров использования средства запрета фрагментации должна служить линия, ведущая к малому хосту. Маленький хост может иметь фиксированную загрузочную программу, которая принимает датаграмму, помещает в памяти, а затем исполняет ее.

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

В следующих псевдопрограммах принимается следующая нотация:

"=<" означает "меньше или равно",

"#" означает "не равно",

"=" означает "равно",

"<-" означает "устанавливается в".

Кроме этого,

"с x по y" означает включительно по x, но не включая y.

К примеру, выражение "с 4 по 7" означало бы включение 4,5 и 6, но не включало бы 7.

Функционирование протокола IP

Протокол Internet выполняет две главные функции: адресацию и фрагментацию.

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

Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.

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

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

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

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

Механизм времени жизни служит для указания верхнего предела времени жизни Internet датаграммы. Этот параметр устанавливается отправителем датаграммы и уменьшается в каждой точке на проходимом датаграммой маршруте. Если параметр времени жизни станет нулевым до того, как Internet датаграмма достигнет получателя, эта датаграмма будет уничтожена. Время жизни можно рассматривать как часовой механизм самоуничтожения.

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

Контрольная сумма заголовка обеспечивает проверку того, что информация, используемая для обработки датаграмм Internet, передана правильно. Данные могут содержать ошибки. Если контрольная сумма неверна, то Internet датаграмма будет разрушена, как только ошибка будет обнаружена.

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

Обнаруженные ошибки могут быть оглашены посредством протокола ICMP (Internet Control Message Protocol), который поддерживается модулем Internet протокола. <

Header Checksum (Контрольная сумма заголовка) 16 бит

Поскольку некоторые поля заголовка меняют свое значение (например, время жизни), это значение проверяется и повторно рассчитывается при каждой обработке Internet заголовка.

Алгоритм контрольной суммы следующий:

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

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

Идентификация

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

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

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

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

Интерфейсы

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

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

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

Контрольная сумма

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

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

Функции сетевого уровня ЭМВОС

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

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

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

Заголовок сетевого уровня должен содержать адрес назначения и другую информацию, необходимую для успешного перехода пакета из сети одного типа в сеть другого типа. К такой информации может относиться, например:

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

<

/p>

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

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

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

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

Транспортный уровень

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

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

Уровень сетевого взаимодействия

	Функции сетевого уровня ЭМВОС
	Функции транспортного уровня ЭМВОС

Уровень сетевого взаимодействия обеспечивает транспортировку данных, получаемых от верхнего (прикладного) уровня, решая при этом задачи сетевого и транспортного уровней ЭМВОС - адресование, доставку и обеспечения целостности данных. Существуют два типа объектов уровня сетевого взаимодействия - маршрутизаторы и пользователи. При этом пользователем является сетевой объект - получатель или отправитель, который обменивается данными с уровнем прикладного взаимодействия.

Маршрутизаторы являются основой сети и отвечают за адресование и доставку данных между собой и пользователями посредством уровня физического взаимодействия. Порядок, правила и принципы функционирования объектов уровня сетевого взаимодействия определяются типами используемых сетевых архитектур, к основным из которых относятся TCP/IP, DЕСnet, SNA, IDP Xerox, XNS Xerox и Novell NetWare, Apple Talk, ISO. Каждый тип разрабатывался независимо, поэтому они имеют совершенно независимые структуры и перечни протоколов. В настоящее время наибольшее распространение имеют архитектуры TCP/IP, ISO и Novell NetWare (XNS Xerox).

В настоящее время все сетевые архитектуры имеют механизмы взаимодействия. Используемые механизмы взаимодействия  более подробно будут показаны в описаниях сетевых архитектур.

Литература (ICMP)

[1]	Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981.
[2]	Cerf, V., "The Catenet Model for Internetworking," IEN 48, Information Processing Techniques Office, Defense Advanced Research Project Agency, July 1978.
[3]	Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman, April 1979.
[4]	Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
[5]	Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT Laboratories, April 1981.

 

---

---