Мультиплексирование протоколов
Другим подходом к согласованию коммуникационных протоколов является технология мультиплексирования. Этот подход состоит в установке нескольких дополнительных стеков протоколов на одной из конечных машин, участвующих во взаимодействии (рисунок 1.2). Компьютер с несколькими стеками протоколов использует для взаимодействия с другим компьютером тот стек, который понимает этот компьютер.
Для того, чтобы запрос от прикладного процесса был правильно обработан и направлен через соответствующий стек, необходимо наличие специального программного элемента - мультиплексора протоколов. Мультиплексор должен уметь определять, к какой сети направляется запрос клиента.
При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной: мультиплексирование осуществляется не на уровне стеков, а на уровне отдельных протоколов. В общем случае на каждом уровне может быть установлено несколько протоколов, и для каждого уровня может существовать собственный мультиплексор, выполняющий коммутацию между протоколами соседних уровней. Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, IPX через один сетевой адаптер. Аналогично сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.
Рис. 1.2. Мультиплексирование протоколов
Мультиплексирование протоколов в конечных узлах
При наличии многопротокольных конечных узлов, даже в отсутствие шлюзов, образуется общая интерсеть, если конечные узлы принимают и понимают сетевые пакеты разных типов.
Мультиплексирование протоколов в конечных узлах может осуществляться на нескольких уровнях, обычно это уровни канальных протоколов (называемый также уровнем драйверов сетевых адаптеров), сетевых протоколов (этот уровень часто называют транспортным) и прикладных протоколов (уровень сетевых сервисов).
Для того, чтобы один сетевой протокол мог использовать несколько канальных протоколов, реализованных в виде драйверов сетевых адаптеров, и, наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, необходимо стандартизовать интерфейс между этими уровнями. Примерами таких стандартных интерфейсов и их программных реализаций являются NDIS (Network Driver Interface Specification)
и ODI (Open Driver Interface). Эти продукты выполняют не только функции мультиплексоров, но и функции программной среды, изолирующей драйверы сетевых адаптеров от аппаратуры, то есть самих сетевых адаптеров. NDIS, например. Предоставляет разработчику драйвера функции управления сетевым адаптером, например, функции ввода-вывода, или обработки прерываний. Что делает код драйвера более мобильным.
Аналогичные соображения можно привести в пользу стандартизации интерфейса уровней сетевых и прикладных протоколов. Стандартный интерфейс позволяет не только осуществлять произвольные связи между протоколами двух соседних уровней, но и предоставляет разработчикам приложений доступ к различным протоколам транспортного уровня, обеспечивая тем самым совместимость приложений.
В большинстве современных сетей конечные узлы и маршрутизаторы почти всегда поддерживают несколько протоколов сетевого уровня, что облегчает построение гетерогенных сетей. Чем больше протоколов сетевого уровня поддерживает маршрутизатор, тем лучше он подходит для использования в корпоративной сети.
В зависимости от типа маршрутизатора, его роли в сети, он может обладать различными возможностями работы в многопротокольной среде.
Практика применения маршрутизаторов разделяет их по областям применения на три класса:
 | Магистральные маршрутизаторы (backbone routers) предназначены для построения центральной сети корпорации и соединения ее с помощью магистральных высокоскоростных и многопротокольных связей с сетями региональных отделений корпораций. |
| Маршрутизаторы региональных отделений - соединяют региональные отделения между собой и с центральной сетью. Сеть регионального отделения, также как и центральная сеть, может состоять из нескольких локальных сетей. |
| Маршрутизаторы удаленных офисов - соединяют, как правило, единственную локальную сеть удаленного офиса с центральной сетью или сетью регионального отделения. |
Маршрутизаторы удаленных офисов поддерживают один-два протокола локальных сетей и низкоскоростные глобальные сервисы.
Маршрутизаторы региональных отделений занимают промежуточное положение, и поэтому их иногда не выделяют в отдельный класс устройств.
Наряду с функцией маршрутизации, интеллектуальные маршрутизаторы могут установить приоритеты для различных протоколов сетевого уровня. Это бывает полезно в случае недостаточной полосы пропускания кабельной системы и существования трафика, чувствительного к временным задержкам, например, трафика SNA. <
table border="0" cellpadding="0" cellspacing="0" width="100%">
Несовместимость оборудования разных производителей
Проблемы несовместимости оборудования разных производителей, возникают чаще всего по трем причинам:
| неточная (с ошибками) реализация стандартов; |
| использование фирменных стандартов; |
| улучшение стандартов - введение дополнительных функций и свойств. |
Для компаний, являющихся лидерами рынка коммуникационного оборудования, ошибочная реализация стандартов - событие маловероятное, так как их представители всегда составляют основу комитетов, разрабатывающих стандарты.
Однако оставшиеся две причины часто порождают проблемы. На первый взгляд может показаться, что нет ничего страшного в том, что в коммуникационной аппаратуре имеются дополнительные функции или что эта аппаратура поддерживает наряду с общепринятыми и свои, фирменные протоколы. В любом случае остается возможность организовать совместную работу двух устройств разных производителей на основе стандартных протоколов. Тем не менее, на практике этой возможностью удается воспользоваться не всегда. Примером служит история с протоколом DLSw, первая стандартная версия которого была описана в документе RFC 1434. Затем компания Cisco выпустила фирменную улучшенную версию этого протокола, названную ею DLSw+, обратно совместимую со стандартной версией. Затем появилась новая стандартная версия DLSw, описанная в RFC 1795, которая также была обратно совместима с прежним стандартом. Однако, версия DLSw по RFC 1795 оказалась несовместимой с версией DLSw+, что породило необходимость модификации программного обеспечения в маршрутизаторах Cisco в тех организациях, которые стали устанавливать новые маршрутизаторы от других фирм.
Использование фирменных стандартов может приводить и к тому, что администраторы сетей в какой-то момент при очередной модернизации сети оказываются перед нелегким выбором - либо устанавливать новое оборудование только от одного производителя, даже если есть более подходящие варианты, либо переконфигурировать все установленное оборудование для работы по стандартному протоколу, чтобы оно стало совместимо с оборудованием других производителей. Понятно, что каждый из этих вариантов является мало привлекательным. <
Поддержка нескольких независимых сетей с помощью многопротокольных маршрутизаторов
При наличии многопротокольных маршрутизаторов, то есть таких маршрутизаторов, которые одновременно могут обрабатывать пакеты с различными сетевыми заголовками, и конечных узлов, которые поддерживают тот или иной протокол, интерсеть представляет собой совокупность непересекающихся интерсетей, использующих общие каналы связи и общие кадры канального уровня, но никак не взаимодействующих между собой.
На рисунке 3.1 схематически показан маршрутизатор, поддерживающий два сетевых протокола IP и IPX. При конфигурации маршрутизатора должна быть определена принадлежность каждого его порта к той или иной сети. Каждому порту должен быть присвоен адрес соответствующей сети. Очевидно, что все узлы присоединяемые к некоторому порту относятся к сети, назначенной для этого порта.
Трафик, порождаемый узлами, которые принадлежат разным сетям, не смешивается, и влияние сетей друг на друга выражается только тем, что они разделяют общий маршрутизатор и каналы связи, а значит могут взаимно ограничивать доступную им пропускную способность линий связи.
Рис. 3.1. Мультипротокольные сети - сети с несколькими сетевыми протоколами
Вполне допустима ситуация, когда один и тот же порт относится к разным сетям и имеет два сетевых адреса. Тогда компьютеры, выходящие на такой порт, могут принадлежать как одной, так и другой сети. Очевидно, что для каждого сетевого протокола конечный узел будет адресоваться оригинальным способом. Так, для протокола IP у него будет один номер сети и узла, а для протокола IPX это будет совсем другая пара чисел. Для того, чтобы иметь возможность получать и отправлять пакеты обоих типов (в данном примере IP и IPX), конечный узел должен поддерживать мультиплексирование протоколов сетевого уровня. <
Подходы к интеграции неоднородных сетей
Источники и типы неоднородностей в транспортной подсистеме
| Использование различных базовых сетевых технологий |
| Использование нескольких протоколов сетевого уровня (IP, IPX, X.25) |
| Комбинирование разных протоколов сбора маршрутной информации (RIP, OSPF, NLSP) |
| Несовместимость оборудования разных производителей |
Примеры многопротокольных и инкапсулирующих маршрутизаторов
| Мост/маршрутизатор NETBuilder II компании 3Com |
| Семейство маршрутизаторов компании Bay Networks/Wellfleet |
| Маршрутизаторы компании Cisco |
Семейство маршрутизаторов компании Bay Networks/Wellfleet
Это семейство состоит из моделей, разработанных для удовлетворения потребностей в объединении сетей самых разных размеров и технологий.
Модели Access Node (AN) и Access Node Hub (ANH)
представляют собой недорогое решение для небольших удаленных офисов, имеющих локальные сети Ethernet или Token Ring и нуждающихся в связи с корпоративной магистральной сетью. Модель AN может поддерживать как Ethernet, так и Token Ring, в то время как модель ANH предназначена для соединения только сетей Ethernet.
Access Stack Node (ASN) - это первый в промышленности стековый маршрутизатор, с помощью которого можно строить легко расширяемые сети, включающие сегменты Ethernet, Token Ring и FDDI, связанные с центральной сетью через глобальные связи. По мере роста сети в стек можно добавлять дополнительные устройства ASN (до 4-х), обеспечивая до 24 сетевых интерфейсов в стеке с общей скоростью продвижения пакетов до 200000 пакетов в секунду.
Модель Backbone Link Node (BLN) предназначена для крупных сетей за счет поддержки до 16 сетевых интерфейсов (Ethernet, Token Ring, FDDI, WAN) с общей производительностью продвижения пакетов 250000 пакетов в секунду.
Разработанный для наиболее ответственных применений, маршрутизатор старшей модели Backbone Concentrator Node (BCN) поддерживает до 52 сетевых интерфейсов с общей производительностью до 760000 пакетов в секунду.
Почти все модели маршрутизаторов (кроме AN и ANH) основаны на симметричной мультипроцессорной архитектуре Wellfleet, которая иллюстрируется рисунком.
Симметричная мультипроцессорная структура маршрутизаторов Wellfleet
Эта архитектура основана на элементах трех типов: процессорных модулях, модулях связи и высокоскоростной шине межпроцессорных соединений.
Модуль связи (Link module) является интерфейсным модулем, поддерживающим специфический стандартный сетевой интерфейс локальных или глобальных связей (Ethernet, FDDI, RS-232, T1 и т.д.). Каждый модуль связи непосредственно соединен с обслуживающим его процессорным модулем через специальный интерфейс Processor-Link.
Модуль связи выполняет три основные функции:
| физический интерфейс к специфической сети (Ethernet, Token Ring, ...), |
| передачу пакета через интерфейс Processor-Link в процессорный модуль, |
| фильтрацию пакетов по алгоритму моста, разгружающую процессорный модуль от обработки ненужных пакетов. |
Структура процессорного модуля
(интеллектуальный интерфейс модуля связи с процессорным модулем)
Центральный процессор принимает решения по фильтрации/продвижению пакетов, модифицирует заголовки пакетов, если это необходимо, передает пакеты непосредственно присоединенному модулю связи или другому процессорному модулю, обновляет базу данных адресной и топологической информации, поддерживает SNMP-управление и выполняет другую административную работу.
Локальная память хранит маршрутные и адресные таблицы, а также другие данные, которые используются или были выработаны процессором данного модуля.
Глобальная память представляет собой буфер, который хранит пакеты, передаваемые от модуля связи данного процессорного модуля или от другого процессорного модуля. Память называется глобальной, так как она видна из любого процессорного модуля и доступна ему. Пакеты передаются в глобальную память с помощью процессора прямого доступа к памяти (DMA processor).
Процессорные модули поддерживают все основные сетевые протоколы: TCP/IP, OSI, DECnet Phase IV, Novell IPX, Banyan VINES, AppleTalk Phase 2, IBM SNA, X.25, Frame Relay, SMDS, ATM.
Высокоскоростная шина межпроцессорных соединений PPX (Parallel Packet Express) обеспечивает скорость передачи данных 1 Гб/с. Используется 4 независимых, избыточных шины 256 Мб/с, нагрузка между которыми может балансироваться динамически. Шина обеспечивает высокую производительность и одновременно высокую отказоустойчивость.
Каждый процессорный модуль подсоединен ко всем четырем шинам и может выбирать любую для передачи данных (рисунок 3.6). Определенная шина выбирается случайным образом для каждого пакета отдельно. Если одна из шин отказывает, то нагрузка перераспределяется между остальными.
Программное обеспечение маршрутизаторов Wellfleet имеет распределенную архитектуру.
Связь процессорных модулей по шине PPX
Функции продвижения пакетов, их фильтрации и управления маршрутизатором распределены по симметричной схеме между процессорными модулями маршрутизатора. Это обеспечивает высокую производительность и отказоустойчивость, так как при отказе одного из процессорных модулей остальные продолжают выполнять свои функции.
Вся обработка пакетов для интерфейсного модуля выполняется присоединенным к нему процессорным модулем. Каждый процессорный модуль имеет свою копию программного обеспечения, выполняющего функции моста и маршрутизатора, а также свои таблицы маршрутизации. При получении пакетов с обновленной маршрутной информацией все вычисления новых значений таблиц маршрутизации выполняются на одном процессорном модуле, а затем эти пакеты передаются остальным процессорным модулям для обработки.
Распределенная архитектура программных средств
Многоуровневая структура программных средств
Исключения делаются только для протоколов, требующих интенсивных вычислений, таких как OSPF. Программный модуль OSPF активизируется только на одном процессорном модуле, который находит оптимальные маршруты, а затем распространяет их по всем процессорным модулям.
Программное обеспечение маршрутизаторов Wellfleet организовано в соответствии с многоуровневым принципом, как и любая современная операционная система, что позволяет ее легко модифицировать.
Интерфейсные модули (модули связи)
Существует 5 типов интерфейсных модулей связи:
| Ethernet Intelligent Link Interface - 2/4 порта Ethernet с возможностью высокоскоростной фильтрации (29000 п/с), поддержкой алгоритмов Transparent Bridging и Spanning Tree, конфигурирование с помощью системы Optivity; |
| Token Ring Intelligent Link Interface - 2/4 порта Token Ring 4/16 Мб/с; |
| FDDI Intelligent Link Interface - 2 порта, поддерживающие два соединения SAS или одно соединение DAS, фильтрация со скоростью до 500000 п/с; |
| ATM Intelligent Link Interface - обеспечивает маршрутизаторы BLN и BCN возможностями соединения локальных сетей через частные или общественные сети ATM. Предоставляет мультипротокольные возможности для ATM-рабочих групп. Поддерживает спецификации RFC-1483 и RFC-1577, определяющие работу протокола IP через сети ATM. Обеспечивает интерфейс SONET/SDH со скоростью 155 Мб/с, поддерживая до 1024 виртуальных каналов SVC. Поддерживает сервис для уровней AAL 3/4 и AAL 5. Для других маршрутизаторов интерфейс с сетями ATM обеспечивается модулями глобальных связей; |
| Serial Intelligent Link Interface - обеспечивают глобальные связи для всех основных видов глобальных интерфейсов и протоколов: V.35, RS-449/422, RS-232, X.21 со скоростью до 6 Мб/с, HSSI для связи с линиями T3/E3 со скоростью до 52 Мб/с; поддерживаются протоколы Frame Relay, SMDS и ATM, T1/E1 со скоростью до 2.048 Мб/с, ISDN BRI и PRI. |
Шлюзы как средство трансляции сетевых протоколов
Если в разных частях составной сети используются разные сетевые протоколы, то для того, чтобы она функционировала как единая сеть, все узлы которой имели бы возможность обмениваться информацией, может быть использован стандартный прием - трансляция.
Трансляция сетевых протоколов является более сложной задачей, чем трансляция канальных протоколов, хотя бы потому, что в отличие от канального уровня, на котором имеется единая система уникальных адресов узлов, каждый сетевой протокол имеет собственный, свойственный только ему, формат адресов. Кроме различий в системе адресации, в каждом сетевом протоколе имеется еще много других специфических особенностей, которые могут выражаться в различии как количественных параметров (например, для разных протоколов могут быть определены разные величины тайм-аутов, времен жизни пакета или максимальных размеров пакетов), так и в структуре пакетов. Протоколы могут отличаться и функциональными возможностями, например, одни из них реализованы с установлением соединений, а другие - без установления соединений, в одних - предусмотрена возможность фрагментации, в других - нет.
Все эти специфические особенности делают задачу трансляции сетевых протоколов нетривиальной, требующей привлечения программных средств. Устройство, реализующее трансляцию одного сетевого протокола в другой, называется шлюзом. (Некоторые шлюзы решают и более сложную задачу согласования стеков протоколов, включающих протоколы всех уровней.)
Шлюз чаще всего представляет собой программный продукт, устанавливаемый на универсальном компьютере, в таком случае он называется программным шлюзом. Существуют шлюзы, реализованные на специализированной аппаратной платформе, они называются аппаратными шлюзами. <
Сравнение трансляции и мультиплексирования
Использование техники трансляции связано со следующими достоинствами:
| Не требуется устанавливать дополнительное программное обеспечение на рабочих станциях. |
| Сохраняется привычная среда пользователей и приложений, транслятор полностью прозрачен для них. |
| Все проблемы межсетевого взаимодействия локализованы, следовательно упрощается администрирование, поиск неисправностей, обеспечение безопасности. |
Недостатки согласования протоколов путем трансляции состоят в том, что:
| Транслятор замедляет работу из-за относительно больших временных затрат на сложную процедуру трансляции, а также из-за ожидания запросов в очередях к единственному элементу, через который проходит весь межсетевой трафик. |
| Централизация обслуживания запросов к "чужой" сети снижает надежность. Однако можно предусмотреть резервирование - использовать несколько трансляторов. |
| При увеличении числа пользователей и интенсивности обращений к ресурсам другой сети резко снижается производительность - плохая масштабируемость. |
Достоинства мультиплексирования по сравнению с трансляцией протоколов заключаются в следующем:
| Запросы выполняются быстрее, за счет отсутствия очередей к единственному межсетевому устройству и использования более простой, чем трансляция, процедуры переключения на нужный протокол. |
| Более надежный способ - при отказе стека на одном из компьютеров доступ к ресурсам другой сети возможен посредством протоколов, установленных на других компьютерах. |
Недостатки данного подхода:
| Сложнее осуществляется администрирование и контроль доступа. |
| Высокая избыточность требует дополнительных ресурсов от рабочих станций, особенно если требуется установить несколько стеков для доступа к нескольким сетям. |
| Менее удобен для пользователей по сравнению с транслятором, так как требует навыков работы с транспортными протоколами "чужих" сетей. |
Средства согласования сетей на сетевом уровне
| Шлюзы как средство трансляции сетевых протоколов | |
| Поддержка нескольких независимых сетей с помощью многопротокольных маршрутизаторов | |
| Мультиплексирование протоколов в конечных узлах | |
| Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP | |
| Примеры многопротокольных и инкапсулирующих маршрутизаторов |
Стратегии межсетевого взаимодействия
| Трансляция протоколов |
| Мультиплексирование протоколов |
| Сравнение трансляции и мультиплексирования |
| Инкапсуляция (туннелирование) протоколов |
Средства взаимодействия компьютеров в сети организованы в виде многоуровневой структуры - стека протоколов. В однородной сети все компьютеры используют один и тот же стек. В контексте межсетевого взаимодействия понятие "сеть" можно определить как совокупность компьютеров, общающихся друг с другом с помощью единого стека протоколов. Проблема возникает тогда, когда требуется организовать взаимодействие компьютеров, принадлежащих разным сетям (в указанном выше смысле), то есть организовать взаимодействие компьютеров, на которых установлены разные стеки коммуникационных протоколов.
Задачи устранения неоднородности имеют некоторую специфику в зависимости от того, к какому уровню модели OSI (информация о модели OSI приведена в приложении) они относятся, и даже имеют разные названия. Задача объединения транспортных подсистем, отвечающих только за передачу сообщений, обычно называется internetworking.
Несколько другая проблема, называемая interoperability,
возникает при объединении сетей, использующих разные протоколы более высоких уровней. Как сделать, например, возможным для клиентов сети Novell NetWare доступ к файловому сервису Windows NT или работу с сервисом telnet ОС Unix?
Очевидно, что подобные проблемы весьма характерны для корпоративных сетей, где в разных подразделениях часто работают разные сетевые операционные системы.
Проблема межсетевого взаимодействия может иметь разные внешние проявления, но суть ее одна - несовпадение используемых коммуникационных протоколов. (Подробнее о стеках коммуникационных протоколов читайте в приложении.) Например, эта проблема возникает в сети, в которой используется только одна сетевая ОС, но в которой транспортная подсистема неоднородна из-за того, что сеть включает в себя фрагменты Ethernet, объединенные кольцом FDDI. Здесь в качестве взаимодействующих сетей выступают группы компьютеров, использующие различные протоколы канального и физического уровня, например, сеть Ethernet, сеть FDDI.
Равным образом проблема межсетевого взаимодействия может возникнуть в однородной сети Ethernet, в которой установлено несколько сетевых ОС. В этом случае, все компьютеры и все приложения используют для транспортировки сообщений один и тот же набор протоколов, но взаимодействие клиентских и серверных частей сетевых сервисов осуществляется по разным протоколам. Здесь компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы верхних уровней, например, сеть Windows NT, сеть NetWare. Конечно, эти сети могут спокойно сосуществовать, не мешая друг другу и мирно пользуясь общим транспортом. Однако, если потребуется обеспечить доступ к данным файл-сервера NetWare для клиентов Windows NT, администратор сети столкнется в необходимостью согласования сетевых сервисов.
Существует три основных подхода к согласованию разных стеков протоколов:
| трансляция; |
| мультиплексирование; |
| инкапсуляция. |
Трансляция протоколов
Трансляция обеспечивает согласование двух протоколов путем преобразования (трансля-
ции) сообщений, поступающих от одной сети, в формат другой сети. Транслирующий элемент в качестве которого могут выступать, например, программный или аппаратный шлюз, мост, коммутатор или маршрутизатор, размещается между взаимодействующими сетями и служит посредником в их "диалоге" (рисунок 1.1).
В зависимости от типа транслируемых протоколов процедура трансляции может иметь разную степень сложности. Так, преобразование протокола Ethernet в протокол Token Ring сводится к нескольким несложным действиям, главным образом благодаря тому, что в обоих протоколах используется единая адресация узлов. А вот трансляция протоколов сетевого уровня IP и IPX представляет собой гораздо более сложный, интеллектуальный процесс, включающий не только преобразование форматов сообщений, но и отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах.
Рис. 1.1. Пример трансляции протоколов
Следует отметить, что сложность трансляции зависит не от того, насколько высокому уровню соответствуют транслируемые протоколы, а от того, насколько сильно они различаются. Так, например, весьма сложной представляется трансляция протоколов канального уровня ATM-Ethernet, именно поэтому для их согласования используется не трансляция, а другие подходы.
К частному случаю трансляции протоколов может быть отнесен широко применяемый подход с использованием общего протокола сетевого уровня (IP или IPX). Заголовок сетевого уровня несет информацию, которая, дополняя информацию заголовка канального уровня, позволяет выполнять преобразование протоколов канального уровня. Процедура трансляции в данном случае выполняется маршрутизаторами, причем помимо информации, содержащейся в заголовках транслируемых кадров, то есть в заголовках канального уровня, дополнительно используется информация более высокого уровня, извлекаемая из заголовков сетевого уровня.
Трансляцию протоколов могут выполнять различные устройства - мосты, коммутаторы, маршрутизаторы, программные и аппаратные шлюзы. Часто транслятор протоколов называют шлюзом в широком смысле, независимо от того, какие протоколы он транслирует. В этом случае подчеркивается тот факт, что трансляция осуществляется выделенным устройством, соединяющим две разнородные сети.
Бесклассовая стратегия маршрутизации CIDR
В связи с быстрым ростом Internet за последние несколько лет, стали проявляться серьезные недостатки в организации увеличения адресного пространства:
 | Проблема нехватки адресов. Она заключается в том, что размеры существующих классов сетей не отражают требований средних организаций на количества хостов. |
| Проблема обработки таблиц маршрутизации. Рост размеров таблиц маршрутизации в Internet- роутерах приводит к тому, что их становиться крайне сложно администрировать а ресурсы программного и аппаратного обеспечения исчерпывают свои возможности. |
Поэтому в июне 1992 года IETF (Internet Engineering Task Force) принял решение об использовании технологии бесклассовой внутридоменной маршрутизации CIDR (Classless Inter-Domain Routing) для решения этих проблем. CIDR может применяться в любой группе доменов Internet, работающих как с IPv4, так и с IPv6 и успешно взаимодействовать со старыми технологиями адресации.
В основе CIDR лежит принцип использования маски сети переменной длины (VLSM — variable length subnet masks) и отказ от деления Internet на сети классов А, В и С. Тогда все организации, предоставляющие услуги Internet, будут разделяться не по классам своих сетей, а по маске предоставленного им адреса. Например, провайдер Internet "ABC", которому NIC делегировал адреса с 198.24.0.0 по 198.31.255.255 (маска 255.248.0.0) может назначить своему клиенту "СВА" группу адресов с 198.24.8.0 до 198.24.11.255 (маска 255.255.252.0). Ясно, что сеть "СВА" не принадлежит ни к какому классу, и, тем не менее, может успешно работать в Internet.
Очевидно, что новая структура адресного пространства позволит значительно сэкономить адреса для тех организаций, которым они действительно нужны, и взять лишние у других. Если организация желает получить пул адресов для работы в Internet, она заказывает кортеж <адрес, маска>, исходя из своих потребностей. Если, к примеру, ей нужно подсоединить к Internet 999 хостов, не нужно заказывать четыре сети класса С или одну класса В, достаточно заказать адрес и маску, позволяющие работать такому количеству хостов, например < 198.24.8.0, 255.255.252.0> — 1024 хоста.
Это удобно, во-первых, из экономических соображений — не нужно платить за неиспользованные адреса, во-вторых, сетевым администраторам не нужно хлопотать о настройке маршрутизации между группами хостов, принадлежащих разным классам, в третьих, значительно упрощается управление единой сетью.
Как всякий переход на новую технологию, изменение иерархии Internet, видимо, будет осуществляться одновременно с переходом на новый тип адресации (128-битной) и новый сетевой протокол IPv6. К тому времени значительно изменятся и стандарты и принципы управления сетями. В настоящее время CIDR поддерживается некоторыми протоколами внутридоменной (OSPF, RIP-2, E-IGRP) и междоменной маршрутизации (BGP-4). <
Библиографическая справка
Протокол маршрутизации внутренних роутеров (Interior Gateway Routing Protokol-IGRP) является протоколом маршрутизации, разработанным в середине 1980 гг. компанией Cisco Systems, Inc. Главной целью, которую преследовала Cisco при разработке IGRP, было обеспечение живучего протокола для маршрутизации в пределах автономной системы (AS), имеющей произвольно сложную топологию и включающую в себя носитель с разнообразными характеристиками ширины полосы и задержки. AS является набором сетей, которые находятся под единым управлением и совместно используют общую стратегию маршрутизации. Обычно AS присваивается уникальный 16-битовый номер, который назначается Центром Сетевой Информации (Network Information Center - NIC) Сети Министерства Обороны (Defence Data Network - DDN).
В середине 1980 гг. самым популярным протоколом маршрутизации внутри AS был Протокол Информации Маршрутизации (RIP). Хотя RIP был вполне пригоден для маршрутизации в пределах относительно однородных об'единенных сетей небольшого или среднего размера, его ограничения сдерживали рост сетей. В частности, небольшая допустимая величина числа пересылок (15) RIP ограничивала размер об'единенной сети, а его единственный показатель (число пересылок) не обеспечивал достаточную гибкость в сложных средах (смотри Главу 23 "RIP"). Популярность роутеров Cisco и живучесть IGRP побудили многие организации, которые имели крупные об'единенные сети, заменить RIP на IGRP.
Первоначальная реализация IGRP компании Cisco работала в сетях IP. Однако IGRP был предназначен для работы в любой сетевой среде, и вскоре Cisco распространила его для работы в сетях использующих Протокол Сет без Установления Соединения (Connectionless Network Protocol - CLNP) OSI.
Формат пакета
Первое поле пакета IGRP содержит номер версии (version number). Этот номер версии указывает на используемую версию IGRP и сигнализирует о различных, потенциально несовместимых реализациях.
За полем версии идет поле операционного кода (opcode). Это поле обозначает тип пакета. Операционный код, равный 1, обозначает пакет корректировки; равный 2-пакет запроса. Пакеты запроса используются источником для запроса маршрутной таблицы из другого роутера. Эти пакеты состоят только из заголовка, содержащего версию, операционный код и поля номера AS. Пакеты корректировки содержат заголовок, за которым сразу же идут записи данных маршрутной таблицы. На записи данных маршрутной таблицы не накладывается никаких ограничений, за исключением того, что пакет не может превышать 1500 байтов, вместе с заголовком IP. Если этого недостаточно для того, чтобы охватить весь об'ем маршрутной таблицы, то используются несколько пакетов.
За полем операционного кода идет поле выпуска (edition). Это поле содержит последовательный номер, который инкрементируется, когда маршрутная таблица каким-либо образом изменяется. Это значение номера выпуска используется для того, чтобы позволить роутерам избежать обработки корректировок, содержащих информацию, которую они уже видели.
За полем выпуска идет поле, содержащее номер AS (AS number). Это поле необходимо по той причине, что роутеры Cisco могут перекрывать несколько AS. Несколько AS (или процессов IGRP) в одном роутере хранят информацию маршрутизации AS отдельно.
Следующие три поля обозначают номер подсетей, номер главных сетей и номер внешних сетей в пакете корректировки. Эти поля присутствуют потому, что сообщения корректировки IGRP состоят из трех частей: внутренней для данной подсети, внутренней для текущей AS и внешней для текущей AS. Сюда включаются только подсети сети, связанной с тем адресом, в который отправляется данная корректировка. Главные сети (т.е. не подсети) помещаются во "внутреннюю для текущей AS" часть пакета, если только они не помечены четко как внешние.
Сети помечаются как внешние, если информация о них поступает во внешней части сообщения из другого роутера.
Последним полем в заголовке IGRP является поле контрольной суммы (checksum). Это поле содержит какую-нибудь контрольную сумму для заголовка IGRP и любую информацию корректировки, содержащуюся в данном пакете. Вычисление контрольной суммы позволяет принимающему роутеру проверять достоверность входящего пакета.
Сообщения о корректировке содержат последовательность из семи полей данных для каждой записи данных маршрутной таблицы. Первое из этих полей содержит три значащих байта адреса (address) (в случае адреса IP). Следующие пять полей содержат значения показателей. Первое из них обозначает задержку (delay), выраженную в десятках микросекунд. Диапазон перекрывает значения от 10 мксек. до 167 сек. За полем задержки следует поле ширины полосы (bandwidth). Ширина полосы выражена в единицах 1 Кбит/сек и перекрывает диапазон от линии с шириной полосы 1200 бит/сек до 10 Гбит/сек. Затем идет поле MTU, которое обеспечивет размер MTU в байтах. За полем MTU идет поле надежности (reliability), указывающее процент успешно переданных и принятых пакетов. Далее идет поле нагрузки (load), которое обозначает занятую часть канала в процентном отношении. Последним полем в каждой записи данных маршрутизации является поле числа пересылок (hop count). И хотя использование числа пересылок не явно выражено при определении показателя, тем не менее это поле содержится в пакете IGRP и инкрементируется после обработки пакета, обеспечивая использование подсчета пересылок для предотвращения петель.
Формат заголовка
Поля Тип и Код совместно определяют тип сообщения, а поле Статус - информацию, зависящую от типа сообщения. Поле Номер автономной системы - это номер, назначенный той автономной системе, к которой присоединен данный внешний шлюз. Поле Номер последовательности служит для синхронизации процесса запросов и ответов.
Поле IP-адрес исходной сети в сообщениях запроса и обновления маршрутной информации обозначает сеть, соединяющую два внешних шлюза (рисунок 8.5).
Сообщение об обновленной маршрутной информации содержит список адресов сетей, которые достижимы в данной автономной системе. Этот список упорядочен по внутренним шлюзам, которые подключены к исходной сети и через которые достижимы данные сети, а для каждого шлюза он упорядочен по расстоянию до каждой достижимой сети от исходной сети, а не от данного внутреннего шлюза. Для примера, приведенного на рисунке 8.5, внешний шлюз R2 в своем сообщении указывает, что сеть 4 достижима с помощью шлюза R3 и расстояние ее равно 2, а сеть 2 достижима через шлюз R2 и ее расстояние равно 1 (а не 0, как если бы шлюз измерял ее расстояние от себя, как в протоколе RIP).
Другие поля заголовка:
| EGP Version (8 бит). Первым полем в заголовке пакета EGP является поле номера версии EGP. Поле обозначает текущую версию EGP и проверяется приемными устройствами для определения соответствия между номерами версий отправителя и получателя. |
| Type (8 бит). Поле типа. Оно обозначает тип сообщения. EGP выделяет 5 отдельных типов сообщений. |
| Code (8 бит). Это поле определяет различие между подтипами сообщений. |
| Status (8 бит). Поле состояния. Оно содержит информацию о состоянии, зависящую от сообщения. В число кодов состояния входят коды недостатка ресурсов (insufficient resources), неисправных параметров (parameter problem), нарушений протокола (protocol violation) и др. |
| Checksum (16 бит). Поле контрольной суммы. Это поле используется для обнаружения возможных проблем, которые могли появиться в пакете в результате транспортировки. |
| Autonomous system number (16 бит). Поле номера автономной системы. Оно обозначает AS, к которой принадлежит шлюз-отправитель. |
| Sequence number (16 бит). Поле номера последовательности. Это поле позволяет двум роутерам EGP, которые обмениваются сообщениями, соотносить сообщения запросов с сообщениями ответов. Когда определен какой-нибудь новый сосед, номер последовательности устанавливается в исходное нулевое значение и увеличивается на единицу с каждой новой транзакцией типа запрос-ответ. |
/p>
За заголовком EGP идут дополнительные поля. Содержимое этих полей различается в зависимости от типа сообщения.
<
table border="0" cellpadding="0" cellspacing="0" width="100%">
Характеристики стабильности
IGRP обладает рядом характеристик, предназначенных для повышения своей стабильности. В их число входят временное удерживание изменений, расщепленные горизонты и корректировки отмены.
Временные удерживания изменений
Временное удерживание изменений используется для того, чтобы помешать регулярным сообщениям о коррректировке незаконно восстановить в правах маршрут, который возможно был испорчен. Когда какой-нибудь роутер выходит из строя, соседние роутеры обнаруживают это через отсутствие регурярного поступления запланированных сообщений. Далее эти роутеры вычисляют новые маршруты и отправляют сообщения о корректировке маршрутизации, чтобы информировать своих соседей о данном изменении маршрута. Результатом этой деятельности является запуск целой волны корректировок, которые фильтруются через сеть.
Приведенные в действие корректировки поступают в каждое сетевое устройство не одновременно. Поэтому возможно, что какое-нибудь устройство, которое еще не было оповещено о неисправности в сети, может отправить регулярное сообщение о корректировке (указывающее, что какой-нибудь маршрут, который только что отказал, все еще считается исправным) в другое устройство, которое только что получило уведомление о данной неисправности в сети. В этом случае последнее устройство будет теперь содержать (и возможно, рекламировать) неправильную информацию о маршрутизации.
Команды о временном удерживании изменений предписывают роутерам удерживать в течение некоторого периода времени любые изменения, которые могут повлиять на маршруты. Период удерживания изменений обычно рассчитывается так, чтобы он был больше периода времени, необходимого для корректировки всей сети в соответствии с каким-либо изменением маршрутизации.
Расщепленные горизонты
Понятие о расщепленных горизонтах проистекает из того факта, что никогда не бывает полезным отправлять информацию о каком-нибудь маршруте обратно в том направлении, из которого она пришла. Для иллюстрации этого положения рассмотрим рисунке.
Роутер 1 (R1) первоначально об'являет, что у него есть какой-то маршрут до Сети А. Роутеру 2 (R2) нет оснований включать этот маршрут в свою корректировку, отправляемую в R1, т.к. R1 ближе к Сети А. В правиле о расщепленных горизонтах говорится, что R2 должен исключить этот маршрут независимо от того, какие корректировки он отправляет в R1.
Правило о расщепленных горизонтах помогает предотвращать зацикливание маршрутов. Например, рассмотрим случай, когда интерфейс R1 с Сетью А отказывает. Без расщепленных горизонтов R2 продолжал бы информировать R1, что он может попасть в Сеть А (через R1!). Если R1 не располагает достаточным интеллектом, он действительно может выбрать маршрут, предлагаемый R2, в качестве альтернативы своему отказавшему прямому соединению, что приводит к образованию маршрутной петли. И хотя удерживание изменений должно помешать этому, в IGRP реализованы также расщепленные горизонты, т.к. они обеспечивают дополнительную стабильность алгоритма.
Корректировки отмены маршрута
В то время как расщепленные горизонты должны препятствовать зацикливанию маршрутов между соседними роутерами, корректировки отмены маршрута предназначены для борьбы с более крупными маршрутными петлями. Увеличение значений показателей маршрутизации обычно указывает на появление маршрутных петель. В этом случае посылаются корректировки отмены, чтобы удалить этот маршрут и перевести его в состояние удерживания. В реализации IGRP компании Cisco корректировки отмены отправляются в том случае, если показатель маршрута увеличивается на коэффициент 1.1 или более.
Таймеры
IGRP обеспечивает ряд таймеров и переменных, содержащих временные интервалы. Сюда входят таймер корректировки, таймер недействующих маршрутов, период времени удерживания изменений и таймер отключения. Таймер корректировки определяет, как часто должны отправляться сообщения о корректировке маршрутов. Для IGRP значение этой переменной, устанавливаемое по умолчанию, равно 90 сек. Таймер недействующих маршрутов определяет, сколько времени должен ожидать роутер при отсутствии сообщений о корректировке какого-нибудь конкретного маршрута, прежде чем об'явить этот маршрут недействующим. Время по умолчанию IGRP для этой переменной в три раза превышает период корректировки. Переменная величина времени удерживания определяет промежуток времени удерживания. Время по умолчанию IGRP для этой переменной в три раза больше периода таймера корректировки, плюс 10 сек. И наконец, таймер отключения указывает, сколько времени должно пройти прежде, чем какой-нибудь роутер должен быть исключен из маршрутной таблицы. Время по умолчанию IGRP для этой величины в семь раз превышает период корректировки маршрутизации. <
Маршрутизация в Internet
Устройства маршрутизации в сети Internet традиционно называются шлюзами (gateway), что является очень неудачнным термином, т.к. повсеместно в индустрии сетей этот термин применяют для обозначения устройства с несколько иными функциональными возможностями. Шлюзы (которые мы с этого момента будем называть роутерами) в сети Internet организованы в соответствии с иерархическим принципом. Некоторые роутеры исползуются для перемещения информации через одну конкретную группу сетей, находящихся под одним и тем же административным началом и управлением (такой об'ект называется автономной системой - autonomous system). Роутеры, используемые для обмена информацией в пределах автономных систем, называются внутренними роутерами (interior routers); они используют различные протоколы для внутренних роутеров (interior gateway protocol - IGP) для выполнения этой задачи. Роутеры, которые перемещают информацию между автономными системами, называются внешними роутерами (exterior routers); для этого они используют протоколы для внешних роутеров. Архитектура Internet представлена на рисунке.
Протоколы маршрутизации IP-это динамичные протоколы. При динамичной маршрутизации (dynamic routing) запросы о маршрутах должны рассчитываться программным обеспечением устройств маршрутизации через определенные интервалы времени. Этот процесс противоположен статической маршрутизации (static routing), при которой маршруты устанавливаются администратором сети и не меняются до тех пор, пока администратор сети не поменяет их. Таблица маршрутизации IP состоит из пар "адрес назначения/следующая пересылка". Образец записи данных, показанный на рисунке, интерпретируется как имеющий значение "добраться до сети 34.1.0.0. (подсеть 1 сети 34), следующей остановкой является узел с адресом 54.34.23.12."
Маршрутизация IP определяет характер перемещения дейтаграмм IP через об'единенные сети (по одной пересылке за раз). В начале путешествия весь маршрут не известен. Вместо этого на каждой остановке вычисляется следующий пункт назначения путем сопоставления адреса пункта назначения, содержащегося в дейтаграмме, с записью данных в маршрутной таблице текущего узла. Участие каждого узла в процессе маршрутизации состоит только из продвижения пакетов, базируясь только на внутренней информации, вне зависимости от того, насколько успешным будет процесс и достигнет или нет пакет конечного пункта назначения. Другими словами, IP не обеспечивает отправку в источник сообщений о неисправностях, когда имеют место аномалии маршрутизации. Выполнение этой задачи предоставлено другому протоколу Internet, а именно Протоколу управляющих сообщений Internet (Internet Control Message Protocol - ICMP).
<
Протокол BGP
Протокол граничных роутеров BGP является попыткой решить самую серьезную проблему EGP. В отличие от EGP, протокол BGP предназначен для обнаружения маршрутных петель. BGP является протоколом маршрутизации между AS, специально созданным для применения в Internet. BGP можно назвать следующим поколением EGP. Как и EGP, протокол BGP относится к классу "междоменных протоколов".
BGP, в отличие от предшествующих протоколов маршрутизации, которые взаимодействуют напрямую с протоколом IP, работает поверх протокола транспортного уровня. Например, при работе поверх TCP BGP использует порт 179. Это позволяет не нагружать сервисы обработки протокола BGP механизмами фрагментации или обеспечения достоверности доставки пакетов. Схемы аутентификации протоколов транспортного уровня также могут быть использованы BGP в дополнение к собственной системе аутентификации. Кроме того, хотя BGP разработан как протокол маршрутизации между AS, он может использоваться для маршрутизации и внутри AS.
Основным предназначением BGP является обеспечение обмена информацией с другими BGP-системами о досягаемости определенных сетей или хостов. Эта информация должна содержать набор маршрутов к данной сети, т. е. должны быть указаны все промежуточные AS. Такой информации вполне достаточно для того, чтобы построить граф соединений между AS и проконтролировать возможные маршрутные петли. На основании этих данных BGP выбирает оптимальный маршрут и передает эту информацию своим соседям.
Периодически хосты отправляют друг другу сообщения подтверждения своей работоспособности, например, при возникновении ошибочных ситуаций передаются сообщения об ошибках. BGP не требует периодического обновления всей маршрутной таблицы, хотя BGP поддерживает маршрутную таблицу всех возможных трактов к какой-нибудь конкретной сети, в своих сообщениях о корректировке он объявляет только об основных — оптимальных маршрутах.
Показатели оптимальности — "метрики" BGP представляет собой числа, характеризующее степень предпочтения какого-нибудь конкретного маршрута.
Эти показатели обычно определяются администратором сети с помощью конфигурационных файлов. Степень предпочтения может базироваться на любом числе критериев, включая число промежуточных AS (например, тракты с меньшим числом AS, как правило, лучше), тип канала, стабильность, быстродействие, надежность канала и другие факторы.
Необходимо отметить, что если в традиционных дистанционно-векторных протоколах маршрутизации рассматривается только один параметр "оптимальности" и процедура сравнения сводится к сравнению двух чисел, то в системах междоменного взаимодействия, где каждая из AS, встречающаяся на пути пакета, может определять маршрут по своим собственным критериям, необходимо учитывать несколько параметров, одновременно влияющих на оптимизацию маршрута.
Для установления соединения, коррекции маршрутов, уведомления друг друга BGP-роутеры использует систему сообщений.
| Открывающие сообщения (open message). После того, как организовано соединение протокола транспортного уровня, первым сообщением, отправляемым каждой стороной, является открывающее сообщение. Пакет открывающего сообщения содержит, в дополнение к основному заголовку BGP (рис. 4), несколько дополнительных параметров. Параметр версия (version) — номер версии BGP дает возможность получателю проверять, совпадает ли его версия с версией отправителя. Параметр автономная система (autonomous system) содержит номер AS отправителя. Параметр время удерживания (hold time) указывает максимальное число секунд, которые могут пройти без получения какого-либо сообщения от передающего устройства, прежде чем считать его отказавшим. Параметр код аутентификации (authentication code) указывает на используемый код удостоверения, если, конечно, таковой имеется- Параметр данных аутентификации (authentication data) содержит возможные данные аутентификации. |
| 0 | 16 | 24 | 31 |
/p>
| Marker |
| Length | type |
Рис. 4. Заголовок BGP-пакета
| Сообщения о корректировке (update message). Сообщения о корректировках BGP обеспечивают корректировки маршрутизации для других систем BGP. Информация этих сообщений используется для построения графа, описывающего взаимоотношения между различными AS. |
 | Источник (origin). Может иметь одно из трех значений: 1GP, EGP и incomplete (незавершенный). Атрибут 1GP означает, что данная сеть является частью данной AS. Атрибут EGP означает, что первоначальные сведения о данной информации получены от протокола EGP. Реализации BGP склонны отдавать предпочтение маршрутам 1GP перед маршрутами EGP, так как маршрут EGP отказывает при наличии маршрутных петель. Атрибут incomplete используется для указания того, что о данной сети известно через какие-то другие средства. |
| Путь (path). Путь AS. Обеспечивает фактический перечень AS на пути к пункту назначения. |
| Следующая пересылка (next hop). Содержит адрес IP-роутера, который должен быть использован в качестве следующей пересылки к сетям, перечисленным в сообщении о корректировке. |
| Недосягаемый (unreachable). Указывает, что какой-нибудь маршрут больше не является досягаемым. |
| Показатель оптимальности маршрута между AS (inter-AS metric). Обеспечивает для какого-нибудь роутера BGP возможность тиражировать свои затраты на маршруты к пунктам назначения, находящимся в пределах его AS. Эта информация может быть использована роутерами, которые являются внешними по отношению к AS тиражирующего роутера, для выбора оптимального маршрута к конкретному пункту назначения, находящемуся в пределах данной AS. |
| Сообщения "продолжай действовать" (keepalive message). Эти сообщения не содержат каких-либо дополнительных полей помимо тех, которые содержатся в заголовке BGP. |
| Уведомления об ошибках (error message). Уведомления отправляются в том случае, если была обнаружена сбойная ситуация и один роутер хочет сообщить другому, почему он закрывает соединение между ними. В сообщении содержится код ошибки (error code), подкод ошибки (error subcode) и данные ошибки (error data). |
Протокол EGP
Для реализации своих функций протокол использует систему следующих сообщений:
| Приобретение соседа (Neighbor Acquisition). Прежде чем начать получать информацию от внешних маршрутизаторов, необходимо установить, какой маршрутизатор является соседним. Эта операция состоит из обмена сообщениями типа "приобретение соседа" (соответственно запрос/ ответ/ отказ и др.) через стандартный механизм трехходового квитирования. Ясно, что маршрутизатор предполагаемого соседа также должен поддерживать механизм сообщений типа "приобретение соседа". Сообщение "приобретение соседа" включает в себя поле интервала приветствия (hello interval) и поле интервала опроса (poll interval). Поле интервала приветствия определяет период интервала проверки работоспособности соседей. Поле интервала опроса определяет частоту корректировки маршрутизации. |
| Досягаемость соседа (Neighbor reachability). Для маршрутизаторов, выполняющих функции связи различных доменов сетей, важно располагать самой последней информацией о работе своих соседей. Если маршрутизатор обнаруживает, что какой-либо шлюз не функционирует, ему необходимо немедленно приостановить поток данных к этому шлюзу. Для этих целей и используется данный тип сообщений. |
| Опроса (Poll). Чтобы обеспечить правильную маршрутизацию между AS, EGP должен знать об относительном местоположении отдаленных хостов. Сообщения опроса позволяют роутерам EGP получать информацию о досягаемости сетей, в которых находятся эти машины. Такие сообщения имеют помимо обычного заголовка только одно поле — поле сети источника IP (source network). Это поле определяет сеть, которая должна использоваться в качестве контрольной точки запроса. |
| Корректировки маршрутизации (Routing update).
Сообщения о корректировке маршрутизации дают роутерам EGP возможность указывать местоположение различных сетей в пределах своих AS. |
/p>
| О неисправностях (Error). Сообщения о неисправностях указывают на различные сбойные ситуации. В дополнение к общему заголовку EGP сообщения о неисправностях обеспечивают поле причины (reason), за которым следует заголовок сообщения о неисправности (message header). В число типичных неисправностей EGP входят неправильный формат заголовка EGP (bad EGP header format), неисправный формат поля данных EGP (bad EGP data field format), чрезмерная скорость опроса (excessive polling rate) и невозможность достижения информации (unavailability of reachability information). |
Протокол IGRP
| Библиографическая справка | |||||||||
| Технология | |||||||||
| Формат пакета | |||||||||
| Характеристики стабильности
|
Протоколы EGP и BGP сети Internet
Большинство протоколов маршрутизации, применяемых в современных сетях с коммутацией пакетов, ведут свое происхождение от сети Internet и ее предшественницы - сети ARPANET. Для того, чтобы понять их назначение и особенности, полезно сначала познакомится со структурой сети Internet, которая наложила отпечаток на терминологию и типы протоколов.
Internet изначально строилась как сеть, объединяющая большое количество существующих систем. С самого начала в ее структуре выделяли магистральную сеть (core backbone network), а сети, присоединенные к магистрали, рассматривались как автономные системы (autonomous systems).
Магистральная сеть и каждая из автономных систем имели свое собственное административное управление и собственные протоколы маршрутизации. Общая схема архитектуры сети Internet показана на рисунке. Далее маршрутизаторы будут называться шлюзами для следования традиционной терминологии Internet.
Архитектура сети Internet
Шлюзы, которые используются для образования подсетей внутри автономной системы, называются внутренними шлюзами (interior gateways), а шлюзы, с помощью которых автономные системы присоединяются к магистрали сети, называются внешними шлюзами (exterior gateways). Непосредственно друг с другом автономные системы не соединяются. Соответственно, протоколы маршрутизации, используемые внутри автономных систем, называются протоколами внутренних шлюзов
(interior gateway protocol, IGP), а протоколы, определяющие обмен маршрутной информацией между внешними шлюзами и шлюзами магистральной сети - протоколами внешних шлюзов (exterior gateway protocol, EGP). Внутри магистральной сети также может использоваться любой собственный внутренний протокол IGP.
Смысл разделения всей сети Internet на автономные системы в ее многоуровневом представлении, что необходимо для любой крупной системы, способной к расширению в больших масштабах. Внутренние шлюзы могут использовать для внутренней маршрутизации достаточно подробные графы связей между собой, чтобы выбрать наиболее рациональный маршрут.
Однако, если информация такой степени детализации будет храниться во всех маршрутизаторах сети, то топологические базы данных так разрастутся, что потребуют наличия памяти гигантских размеров, а время принятия решений о маршрутизации непременно возрастет.
Поэтому детальная топологическая информация остается внутри автономной системы, а автономную систему как единое целое для остальной части Internet представляют внешние шлюзы, которые сообщают о внутреннем составе автономной системы минимально необходимые сведения - количество IP-сетей, их адреса и внутреннее расстояние до этих сетей от данного внешнего шлюза.
При инициализации внешний шлюз узнает уникальный идентификатор обслуживаемой им автономной системы, а также таблицу достижимости (reachability table), которая позволяет ему взаимодействовать с другими внешними шлюзами через магистральную сеть.
Затем внешний шлюз начинает взаимодействовать по протоколу EGP с другими внешними шлюзами и обмениваться с ними маршрутной информацией, состав которой описан выше. В результате, при отправке пакета из одной автономной системы в другую, внешний шлюз данной системы на основании маршрутной информации, полученной от всех внешних шлюзов, с которыми он общается по протоколу EGP, выбирает наиболее подходящий внешний шлюз и отправляет ему пакет.
В протоколе EGP определены три основные функции:
| установление соседских отношений, |
| подтверждение достижимости соседа, |
| обновление маршрутной информации. |
Так как каждая автономная система работает под контролем своего административного штата, то перед началом обмена маршрутной информацией внешние шлюзы должны согласиться на такой обмен. Сначала один из шлюзов посылает запрос на установление соседских отношений (acquisition request)
другому шлюзу. Если тот согласен на это, то он отвечает сообщением подтверждение установления соседских отношений (acquisition confirm), а если нет - то сообщением отказ от установления соседских отношений (acquisition refuse), которое содержит также причину отказа.
После установления соседских отношений шлюзы начинают периодически проверять состояние достижимости друг друга. Это делается либо с помощью специальных сообщений (привет (hello) и Я-услышал-тебя (I-heard-you)), либо встраиванием подтверждающей информации непосредственно в заголовок обычного маршрутного сообщения.
Обмен маршрутной информацией начинается с посылки одним из шлюзов другому сообщения запрос данных (poll request) о номерах сетей, обслуживаемых другим шлюзом и расстояниях до них от него. Ответом на это сообщение служит сообщение обновленная маршрутная информация
(routing update). Если же запрос оказался некорректным, то в ответ на него отсылается сообщение об ошибке.
Все сообщения протокола EGP передаются в поле данных IP-пакетов. Сообщения EGP имеют заголовок фиксированного формата.
Протокол EGP имеет достаточно много ограничений, связанных с тем, что он рассматривает магистральную сеть как одну неделимую магистраль.
Развитием протокола EGP является протокол BGP (Border Gateway Protocol), имеющий много общего с EGP и используемый наряду с ним в магистрали сети Internet.
Пример автономной системы
Протоколы обмена маршрутной информацией стека TCP/IP
| RIP и OSPF |
| Протоколы EGP и BGP сети Internet |
Все протоколы обмена маршрутной информацией стека TCP/IP относятся к классу адаптивных протоколов, которые в свою очередь делятся на две группы, каждая из которых связана с одним из следующих типов алгоритмов:
| дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA), |
| алгоритм состояния связей (Link State Algorithms, LSA). |
В алгоритмах дистанционно-векторного типа
каждый маршрутизатор периодически и широковещательно рассылает по сети вектор расстояний от себя до всех известных ему сетей. Под расстоянием обычно понимается число промежуточных маршрутизаторов через которые пакет должен пройти прежде, чем попадет в соответствующую сеть. Может использоваться и другая метрика, учитывающая не только число перевалочных пунктов, но и время прохождения пакетов по связи между соседними маршрутизаторами. Получив вектор от соседнего маршрутизатора, каждый маршрутизатор добавляет к нему информацию об известных ему других сетях, о которых он узнал непосредственно (если они подключены к его портам) или из аналогичных объявлений других маршрутизаторов, а затем снова рассылает новое значение вектора по сети. В конце-концов, каждый маршрутизатор узнает информацию об имеющихся в интерсети сетях и о расстоянии до них через соседние маршрутизаторы.
Дистанционно-векторные алгоритмы хорошо работают только в небольших сетях. В больших сетях они засоряют линии связи интенсивным широковещательным трафиком, к тому же изменения конфигурации могут отрабатываться по этому алгоритму не всегда корректно, так как маршрутизаторы не имеют точного представления о топологии связей в сети, а располагают только обобщенной информацией - вектором дистанций, к тому же полученной через посредников. Работа маршрутизатора в соответствии с дистанционно-векторным протоколом напоминает работу моста, так как точной топологической картины сети такой маршрутизатор не имеет.
Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP.
Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. Широковещательная рассылка используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто.
Для того, чтобы понять, в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами со своими ближайшими соседями. Этот трафик также широковещательный, но он циркулирует только между соседями и поэтому не так засоряет сеть.
Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF.
Технология
IGRP является протоколом внутренних роутеров (IGP) с вектором расстояния. Протоколы маршрутизации с вектором расстояния требуют от каждого роутера отправления через определенные интервалы времени всем соседним роутерам всей или части своей маршрутной таблицы в сообщениях о корректировке маршрута. По мере того, как маршрутная информация распространяется по сети, роутеры могут вычислять расстояния до всех узлов об'единенной сети.
Протоколы маршрутизации с вектором расстояния часто противопоставляют протоколам маршрутизации с указанием состояния канала, которые отправляют информацию о локальном соединении во все узлы об'единенной сети.
IGRP использует комбинацию (вектор) показателей. Задержка об'единенной сети (internetwork delay), ширина полосы (bandwidth), надежность (reliability) и нагрузка (load) - все эти показатели учитываются в виде коэффициентов при принятии маршрутного решения. Администраторы сети могут устанавливать факторы весомости для каждого из этих показателей. IGRP использует либо установленные администратором, либо устанавливаемые по умолчанию весомости для автоматического расчета оптимальных маршрутов.
IGRP предусматривает широкий диапазон значений для своих показателей. Например, надежность и нагрузка могут принимать любое значение в интервале от 1 до 255, ширина полосы может принимать значения, отражающие скорости пропускания от 1200 до 10 гигабит в секунду, в то время как задержка может принимать любое значение от 1-2 до 24-го порядка. Широкие диапазоны значений показателей позволяют производить удовлетворительную регулировку показателя в об'единенной сети с большим диапазоном изменения характеристик производительности. Самым важным является то, что компоненты показателей об'единяются по алгоритму, который определяет пользователь. В результате администраторы сети могут оказывать влияние на выбор маршрута, полагаясь на свою интуицию.
Для обеспечения дополнительной гибкости IGRP разрешает многотрактовую маршрутизацию. Дублированные линии с одинаковой шириной полосы могут пропускать отдельный поток трафика циклическим способом с автоматическим переключением на вторую линию, если первая линия выходит из строя. Несколько трактов могут также использоваться даже в том случае, если показатели этих трактов различны. Например, если один тракт в три раза лучше другого благодаря тому, что его показатели в три раза ниже, то лучший тракт будет использоваться в три раза чаще. Только маршруты с показателями, которые находятся в пределах определенного диапазона показателей наилучшего маршрута, используются для многотрактовой маршрутизации.
Атрибуты сообщений системы IMAP
Каждое сообщение в почтовой системе для работы с IMAP имеет уникальный идентификатор, по которому можно получить доступ к этому сообщению. Уникальный идентификатор UID представляет собой 32-битное число, которое идентифицирует сообщение в данной папке. Каждому сообщению, попавшему в папку, присваивается максимальное число из UID-сообщений, попавших в данную папку ранее. Уникальные идентификаторы сообщений сохраняются от сессии к сессии и могут использоваться, например, для синхронизации каталогов мобильных пользователей.
Каждая папка в системе также имеет уникальный действительный идентификатор (UIDVALIDITY). Вместе с UID-сообщение эта пара образует 64-битное число, идентифицирующее каждое сообщение. Если UID-сообщение сохраняется постоянным, то UIDVALIDITY данной папки в текущей сессии Должен быть больше, чем в предыдущей сессии.
Кроме уникального идентификатора, сообщение в системе IMAP имеет порядковый номер, т. е. все сообщения в данном почтовом ящике последовательно нумеруются. Если в почтовый ящик добавляется новое сообщение, ему присваивается номер на 1 больше количества сообщении в почтовом ящике. При удалении какого-либо сообщения из данной папки порядковые номера всех сообщений пересчитываются, поэтому порядковый номер сообщения может меняться во время сессии. Большинство команд IMAP4 работают с порядковыми номерами сообщений, а не с UID.
Помимо числовых идентификаторов, сообщениям назначаются флаги. Одни флаги могут быть действительны для данного сообщения постоянно от сессии к сессии, другие — только в данной сессии. Наиболее употребительные из них:
 | "\Seen" — обозначает, что данное сообщение было прочитано |
| "\Answered" — на сообщение был дан ответ |
| "\Deleted" — сообщение помечено на удаление |
| "\Draft" — формирование данного сообщения еще не завершено |
| "\Recent" — сообщение "только что" поступило в почтовый ящик, т. е. данная сессия — первая, которая может прочитать это сообщение. |
Кроме того, на сервере IMAP хранятся дата и время получения сообщения сервером. Например, если сообщение получено по SMTP, то фиксируется дата и время доставки по адресу назначения, общий размер сообщения, состав конверта (заголовка) сообщения (не путать с конвертом SMTP), структура сообщения (MIME-структура).
Основные команды
IMAP4 — гибкий и многофункциональный протокол с широкими возможностями. Он обслуживает более 20 различных команд клиента по управлению состоянием своей почты. Подробное описание всех команд и ответов IМАР4-сервера вы можете найти, в RFC-2060. Далее будут описаны только некоторые из клиентских команд, и на примерах их обработки показана общая схема взаимодействия клиента и сервера IMAP4.
IMAP4 поддерживает текстовые команды и ответы сервера, т. е. ASCII-последовательности символов. Строка команды или данных завершается последовательностью <CRLF>. 8-битные данные, в соответствии с спецификацией MIME, не могут передаваться по IMAP4 в "открытом" виде. Как правило, реализации IMAP4 перед передачей двоичных данных кодируют их base64.
Так же как и РОРЗ-сервер, 1МАР4-сервер обрабатывает команды в зависимости от одного из четырех состояний, в котором он находится:
Состояние вне аутентификации, в котором клиент должен для начала работы зарегистрироваться в сервере.
Состояние аутентификации, в котором клиент может выбрать для работы папку с сообщениями.
Состояние работы с почтовой папкой, в котором клиент производит основную работу с сообщениями.
Состояние отсоединения, в котором сервер завершает транзакцию работы клиента.
Далее при описании команд, символом "S:" будет обозначаться поток данных от сервера IMAP4, а символом "С:" — поток данных от клиента.
| Команда LOGIN. После того как по транспортному протоколу (например, TCP), было установлено соединение, и от сервера пришла строка приветствия, клиент должен зарегистрироваться в системе. Для этого чаще всего используется команда LOGIN. Аргументом команды является строка с идентификатором и паролем клиента: |
/p>
| После регистрации в системе клиент должен выбрать каталог (папку) сообщений, с которым он будет работать. Выбор каталога осуществляется командой SELECT. Аргументом команды является имя почтового каталога: |
S * OK [PERMANENT FLAGS (\Deleted \Seen \*)] Limited
S А142 OK [READ-WRITE] SELECT completed
Сервер IМАР4, прежде чем подтвердить завершение обработки команды, передает клиенту атрибуты данного каталога. В показанном выше примере:
| Команда SELECT устанавливает текущий каталог для работы клиента. Если пользователю необходимо получить информацию о состоянии какого-либо каталога, достаточно воспользоваться командой EXAMINE с именем каталога в качестве аргумента команды, например: |
| Если необходимо запросить статус какой-либо папки, не меняя текущий каталог, можно воспользоваться командой STATUS. В качестве параметров данной команде придаются : имя папки и тип запрашиваемой информации. В зависимости от указанного типа, команда может возвращать: количество сообщений в папке, количество новых сообщений, количество непрочитанных сообщений, UIDVALIDITY каталога, UID следующего сообщения, которое будет добавлено в данную папку, например: |
/p>
| Чтобы получить список папок (подкаталогов), находящихся в определенной папке и доступных клиенту, можно воспользоваться командой LIST. Аргументами команды являются: имя каталога, список подкаталогов которого хотим получить (пустая строка — " " означает текущий каталог) и маска имен подкаталогов. Имена каталогов и маски имен подкаталогов могут интерпретироваться по-разному, в зависимости от реализации почтовой системы и структуры описания иерархии папок. Например, список папок, находящихся в корне, можно получить так: |
| После получения информации на каталог, пользователь может прочитать любое сообщение или определенную группу сообщений, часть сообщения или определенные атрибуты сообщения. Для этого используется команда FETCH. Аргументами данной команды являются порядковый номер сообщения и критерии запроса. Критерии содержат описание вида возвращаемой информации. Например, можно запросить части заголовков или UID-сообщений в папке, или сообщения, имеющие или не имеющие определенные флаги. Так запрос заголовков сообщений, находящихся в INBOX с порядковыми номерами от 10 до 12, будет выглядеть так: |
/p>
| После просмотра сообщения, пользователь может сохранить его с другими флагами, добавить или удалить флаги сообщения (например, пометить данное сообщение на удаление). Для этого используется команда STORE. Аргументами команды являются: номера сообщении, идентификатор операции и перечень флагов. Например, операция добавления флага удаления ("\Deleted") трем сообщениям выглядит следующим образом: |
| Пользователь также может организовать поиск сообщений по определенным критериям. Для этого используется команда SEARCH. Критерий поиска состоит из комбинации нескольких условий поиска, а результатом поиска будет множество сообщений, находящихся в пересечении указанных условий. Условия могут налагаться на состав, структуру тела или (и) заголовка сообщений, а также на флаги, размер, идентификаторы, периоды дат сообщений. Результатом работы команды является строка, состоящая из последовательных номеров сообщений, удовлетворяющих критерию поиска. Например, поиск всех непрочитанных сообщений, поступивших от "Smith" с 1-03-96 будет выглядеть так: |
| IMAP4 позволяет не только искать и читать сообщения в каталогах, этот протокол позволяет добавлять, копировать и перемещать сообщения в каталоги. Добавление сообщения в папку можно осуществить командой APPEND: |
/p>
| Команда COPY копирует сообщения с заданными порядковыми номерами в указанный каталог, например: |
Пример сценария
Далее приведен простейший сценарий сессии работы IМАР4-клиента с сервером.
S: * OK IMAP4revl Service Ready
С: aOOl login alladin sesam
S: aOOl OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
С: аООЗ fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {350}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: gray@cac.Washington.edu
S: Subject: IMAP4revl WG mtg summary and minutes
S: To: imap@cac.Washington.edu
S: Message-Id: <B27397-0100000@cac.Washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: аООЗ OK FETCH completed
С: а004 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: а004 OK +FLAGS completed
С: а005 logout
S: * BYE IMAP4revl server terminating connection
S: а005 OK LOGOUT completed
Пример сценария
Ниже приведена стандартная сессия работы с РОРЗ -протоколом.
S: <wait for connection on TCP port 110>
C: <open connection>
S: +OK РОРЗ server ready
С: USER mrose
S: +OK mrose is a real hoopy frood
С: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
С: STAT
S: +OK 2 320
С: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
С: RETR 1
S: +OK 120 octets
S: <the РОРЗ server sends message 1>
S: .
С: DELE 1
S: +OK message 1 deleted
С: RETR 2
S: +OK 200 octets
S: <the РОРЗ server sends message 2>
S: .
С: DELE 2
S: +OK message 2 deleted
С: QUIT
S: +OK dewey РОРЗ server signing off (maildrop empty)
С: <close connection>
S: <wait for next connection>
Простота протокола POP, которая послужила росту его популярности вначале, обернулась затем отсутствием гибкости и невозможности выполнять другие операции управления почтовыми ящиками. На смену РОРЗ пришло новое поколение протоколов работы с электронной почтой — протоколы IMAP.
Литература
Информацию о протоколе РОРЗ можно найти в: RFC-1081, RFC-1082, RFC-1225, RFC-1725, RFC-1939.
<
Принципы работы
Протокол IMAP4 работает поверх транспортного протокола, который обеспечивает надежный и достоверный канал передачи данных между клиентом и сервером IMAP4. При работе по TCP, IMAP4 использует 143-й порт. Команды и данные IMAP4 передаются по транспортному протоколу в том виде, в каком их отправляет сервер или пользователь.
Принцип передачи данных IMAP4 такой же, как и у других подобных протоколов. Сначала клиент и сервер обмениваются приветствиями. Затем клиент отправляет на сервер команды и данные. Сервер, соответственно, передает клиенту ответы на обработку команд и данных. После завершения обмена канал закрывается.
Если сервер использует таймер контроля времени соединения, он должен быть установлен не менее чем на 30-минутный промежуток "неактивности" клиента, т. е. если сервер в течение 30 минут получает хотя бы одну команду, таймер сбрасывается.
Весь обмен данными между клиентом и сервером организован в виде строк, завершающихся символами <CRLF>, либо в виде последовательности байт заданной длины. Каждая команда клиента начинается с идентификатора или тега команды. Тег, как правило, представляет собой короткую строку, состоящую из букв и цифр, (например, А0001, А0002 и т. д.). Тег является уникальным идентификатором данной команды клиента. Ответы сервера или следующие команды клиента могут ссылаться на данную команду по ее тегу.
Каждая команда клиента начинается с новой линии. В тех случаях, когда команда передает поток данных заданной длины или когда команда требует ответа с сервера, для того чтобы продолжить работу (например, при аутентификации), она может занимать несколько строк.
Строки данных, передаваемые с сервера в ответ на команду клиента, могут не содержать тег, а содержать символ "*". Это означает, что они являются
промежуточными строками потока данных ответа, а идентификатор их команды содержится в последней строке потока. В такой поток данных не может вклиниться другая команда.
Если сервер обнаружил ошибку в команде, он отправляет уведомление BAD клиенту с тегом неправильной команды.
Если команда успешно обработана — возвращается уведомление ОК с тегом команды. Если команда вернула отрицательный результат, например, в случае невозможности выполнить данную команду — возвращается уведомление NO с тегом невыполненной команды.
Важной особенностью протокола IMAP является то, что взаимодействие клиента с сервером не строится по принципу "запрос-ответ", в котором каждая из сторон "ходит" по очереди. Клиент может отправить новую команду на сервер, не дожидаясь ответа на предыдущую, естественно, когда эти команды не взаимосвязаны или ответ одной не повлияет на результат другой. Сервер может обрабатывать несколько команд одновременно и отвечать на каждую из них по ее окончанию. При этом ответ на более позднюю команду может поступить раньше, поэтому ответ сервера всегда содержит тег той команды, к которой он относится.
Для работы в таком режиме, клиент и сервер должны фиксировать весь поток данных обмена, поскольку как сервер так и клиент в своих запросах и ответах могут ссылаться на команды и данные, введенные на предыдущих стадиях сессии обмена.
Для того чтобы обеспечить гибкость и многофункциональность операций работы с сообщениями, почтовые системы IMAP присваивают сообщениям определенные атрибуты.
Internet Message Access Protocol, Version
Протокол IМАР4 ( Internet Message Access Protocol, Version 4, Протокол доступа к электронной почте Internet, версия 4) позволяет клиентам получать Доступ и манипулировать сообщениями электронной почты на сервере.
Существенным отличием протокола IMAP4 от протокола РОРЗ является то, что IMAP4 поддерживает работу с системой каталогов (или папок) сообщений. IMAP4 позволяет управлять каталогами (папками) удаленных сообщений так же, как если бы они располагались на локальном компьютере. IMAP4 позволяет клиенту создавать, удалять и переименовывать почтовые ящики, проверять наличие новых сообщений и удалять старые. Благодаря тому что IMAP4 поддерживает механизм уникальной идентификации каждого сообщения в почтовой папке клиента, он позволяет читать из почтового ящика только сообщения, удовлетворяющие определенным условиям или их части, менять атрибуты сообщений и перемещать отдельные сообщения.
Структура папок в значительной степени зависит от типа почтовой системы, но в любой системе у клиента есть специальный каталог INBOX, куда попадают поступающие клиенту сообщения.
Для небольших организаций невыгодно держать
| Принципы работы |
| Протокол работы, основные команды |
| Пример сценария |
Для решения этой проблемы был разработан почтовый протокол для работы в офисе — POP (Post Office Protocol). Его наиболее распространенный вариант — РОРЗ (Протокол почтового отделения версия 3). Этот протокол позволяет рабочим станциям динамически получать доступ к своим почтовым ящикам, расположенным на сервере, предназначенном для обслуживания электронной почты в данной организации.
РОРЗ — это простейший протокол для работы пользователя с содержимым своего почтового ящика. Он позволяет только забрать почту из почтового ящика сервера на рабочую станцию клиента и удалить ее из почтового ящика на сервере. Всю дальнейшую обработку почтовое сообщение проходит на компьютере клиента.
РОРЗ -сервер не отвечает за отправку почты, он работает только как универсальный почтовый ящик для группы пользователей. Когда пользователю необходимо отправить сообщение, он должен установить соединение с каким-либо SMTP-сервером и отправить туда свое сообщение по SMTP. Этот SMTP-сервер может быть тем же хостом, где работает РОРЗ -сервер, а может располагаться совсем в другом месте.
Как правило, при работе с электронной почтой небольшие организации используют для получения своей корреспонденции РОРЗ -сервер, установленный на каком-либо компьютере в офисе, а отправляют почту по SMTP на один из хорошо доступных общеизвестных SMTP-серверов города (найти такие совсем несложно).
Протокол работы, основные команды
При открытии TCP-соединения РОРЗ -клиентом, РОРЗ -сервер отправляет сообщение приветствия (далее во всех примерах РОРЗ -протокола используются следующие обозначения: С —клиент, S — сервер РОРЗ):
Теперь РОРЗ -сессия находится в состоянии аутентификации (AUTHORIZATION), и клиент должен зарегистрировать себя на РОРЗ -сервере. Это может быть выполнено либо с помощью команд USER и PASS — ввод открытых пользовательского идентификатора и пароля (именно этот способ используется чаще), либо командой АРОР — аутентификация цифровой подписью, на базе секретного ключа. Любой РОРЗ -сервер должен поддерживать хотя бы один из механизмов аутентификации.
Команда USER имеет следующий формат:
USER name
Аргументом — "name" является строка, идентифицирующая почтовый ящик системы. Этот идентификатор должен быть уникальным в данной почтовой системе РОРЗ -сервера. Если ответом на эту команду является строка индикатора "+OK", клиент может отправлять команду PASS — ввод пароля или QUIT — завершить сессию. Если ответом является строка "-ERR", клиент может либо повторить команду USER, либо закрыть сессию. Примеры использования команды:
ИЛИ
Примечание
Сервер может вернуть отрицательный ответ, если почтовый ящик существует, но по каким-либо причинам не доступен.
Команда PASS используется только после положительного ответа на команду USER:
PASS string
Аргументом команды является строка пароля данного почтового ящика. После получения команды PASS, РОРЗ -сервер, на основании аргументов команд USER и PASS, определяет возможность доступа к заданному почтовому ящику. Если РОРЗ -сервер ответил "+OK", это означает, что аутентификация клиента прошла успешно и он может работать со своим почтовым ящиком, т. е. сессия переходит в состояние TRANSACTION. Если РОРЗ- сервер ответил "-ERR", то либо был введен неверный пароль, либо не найден указанный почтовый ящик:
С: USER mrose
S: +OK mrose is a real hoopy frood
С: PASS secret
S: -ERR maildrop already locked
ИЛИ
С: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
Команда аутентификации пользователя АРОР
не входит в список обязательно реализуемых команд РОРЗ -сервера. Эта команда предоставляет значительно больший (по сравнению с командами USER или PASS) уровень защиты аутентификации пользователя при открытии сессии AUTHORIZATION и используется только тогда, когда к обеспечению конфиденциальности доступа к информации почтовых ящиков предъявляются повышенные требования. Эта команда может быть передана клиентом РОРЗ -сервера после получения приветственного сообщения или после ошибки обработки команд USER/PASS.
АРОР name digest
Аргументами команды являются: name — имя пользователя (то же, что и в команде USER), digest — шифрованная (по алгоритму MD5) строка пароля. Применяемый здесь алгоритм необратимого шифрования для построения секретного ключа использует открытый ключ и временную метку. Временные метки передаются хосту клиента вместе с сообщением приветствия. Например, для UNIX-машин временная метка может иметь вид: <process-ID.clock@hostname>, где process-ID — это идентификатор процесса, clock — состояние таймера на момент установления соединения, hostname — имя компьютера РОРЗ -сервера. Этот механизм позволяет достичь очень высокой степени защищенности. Далее показан пример работы команды АРОР.
S: +OK РОРЗ server ready 1896.697170952@dbc.mtview.ca.us
С: АРОР mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
Алгоритм на основании открытого ключа "tanstaaf и временной метки
< 1896.697170952@dbc.rnt.view.ca.us> построил шифрованную строку "c4c9334bac560ecc979e5800Ib3e22fb".
К командам состояния AUTHORIZATION может относиться команда закрытия РОРЗ- сессии — QUIT, если она была отправлена в режиме AUTHORIZATION (например, при вводе неправильного пароля или идентификатора пользователя):
Эта команда отправляется без аргументов и всегда имеет единственный ответ "+ОК", например:
Команда STAT (без аргументов) используется для просмотра состояния текущего почтового ящика.
В ответ РОРЗ- сервер возвращает строку, содержащую количество и общий размер в байтах сообщений, которые клиент может получить с РОРЗ- сервера. Сообщения, помеченные на удаление, не учитываются. Формат ответа: "+ОК nn mm", где nn — количество сообщений, mm — их общий объем:
С: STAT
S: +ОК 2 320
В этом примере РОРЗ -сервер сообщает, что в данном почтовом ящике находятся два сообщения общим объемом 320 байт.
После того как РОРЗ -сервер открыл почтовый ящик, он присваивает каждому сообщению номер и устанавливает его размер в байтах. Первому сообщению присваивается число 1, второму — 2 и т. д. Далее во всех командах, относящихся к сообщениям, РОРЗ -сервер ссылается на сообщения по их номерам и указывает их размер только в десятичном виде.
Команда LIST может передаваться как с аргументом msg — номером сообщения, так и без аргумента:
LIST [msg]
Если команда содержит аргумент, и сообщение с указанным номером существует, ответом на нее будет "информационная строка", которая содержит номер сообщения и размер сообщения в байтах. Если аргумент не указан — ответом будет список информационных строк обо всех сообщениях в данном почтовом ящике. Сообщения, помеченные на удаление не фигурируют в этом списке:
С: LIST
S: +ОК 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
ИЛИ
С: LIST 2
S: +ОК 2 200
ИЛИ
С: LIST 3
S: -ERR no such message, only 2 messages in maildrop
Следующая команда — команда RETR — используется для передачи клиенту запрашиваемого сообщения:
RETR msg
Аргумент команды — номер сообщения. Если запрашиваемого сообщения нет, возвращается отрицательный индикатор "-ERR".
С: RETR 1
S: +ОК 120 octets
S: <text message>
S: .
После получения, сообщение, как правило, помечается на удаление из почтового ящика, при этом используется команда DELE:
DELE msg
Аргумент команды— номер сообщения. Сообщения, помеченные на удаление, реально удаляются только после закрытия транзакции, на стадии UPDATE.
С: DELE 1
S: +ОК message 1 deleted
ИЛИ
С: DELE 2
S: -ERR message 2 already deleted
Для проверки состояния соединения с РОРЗ- сервером используется команда NOOP. При активном соединении ответом на нее будет положительный индикатор "+ОК":
С: NOOP
S: +ОК
Для отката транзакции внутри сессии используется команда RSET (без аргументов). Если пользователь случайно Пометил на удаление какие-либо сообщения, он может убрать эти пометки, отправив эту команду:
РОРЗ- сервер может поддерживать еще несколько команд, которые предоставляют пользователю большую свободу в манипулировании сообщениями, но которые не входят в список обязательных для реализации команд, т. е. ваш РОРЗ- сервер может их и не поддерживать. Одной из таких команд является команда ТОР:
TOP msg n
По этой команде пользователь может получить "n" первых строк сообщения с номером "msg". РОРЗ- сервер по запросу клиента отправляет заголовок сообщения, затем пустую строку, затем требуемое количество строк сообщения (если количество строк в сообщении меньше указанного в параметре "n", пользователю передается все сообщение).
С ТОР 1 10
S +OK
S <header>
S <blank>
S <message body>
S .
Различные расширения РОРЗ- протокола могут включать в себя другие команды или поддерживать расширения описанных команд. Эту или другую дополнительную информацию вы можете найти в соответствующих RFC, но большинство РОРЗ- систем работают только с набором описанных выше команд.
Протокол SMTP
Главной целью протокола Simple Mail Transfer Protocol (SMTP, RFC-821, -822) является надежная и эффективная доставка электронных почтовых сообщений. SMTP - это довольно независимая субсистема, требующая только надежного канала связи. Средой для SMTP может служить отдельная локальная сеть, система сетей или вся сеть Internet.
Протокол SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть оконечный или промежуточный адресат. SMTP-eiiaiau генерируются отправителем и посылаются получателю. Для каждой команды должен быть получен отклик.
Когда канал организован, отправитель посылает команду MAIL, идентифицируя себя. Если получатель готов к приему сообщения, он посылает положительный отклик. Далее отправитель посылает команду RCPT, идентифицируя получателя почтового сообщения. Если получатель может принять сообщение для оконечного адресата, он снова выдает положительный отклик. В противном случае он отвергает получение сообщения для данного адресата, но не вообще почтовой посылки. Взаимодействие с почтовым сервером возможно и в диалоговом режиме, например:
| tn dxmint.cern.ch 25 220 dxmmt.cern.ch Sendmail ready at Sun, 9 Jul 1995 11:13:57+200 | связь установлена |
| ehlo dxmint.cern.ch | поддерживает ли сервер расширение MIME? |
| 500 Command unrecognized helo crnvma.cern.ch | не поддерживает |
| 250 dxmint.cern.ch Hello crnvma.cern.ch, pleased to meet you | команда выхода на конкретный сервер |
| MAIL From <Alex@aha.ru> | от кого |
| 250 <>... Sender ok | команда прошла успешно |
| RCPT To:<ysemenov@cernvm.cern.ch> | указываем адрес места назначения |
| 250 <ysemenov@cernvm.cero.ch>... Recepient ok | команда прошла успешно |
| DATA | начало ввода текста сообщения |
| . . . . . . | текст сообщения |
| . | знак конца сообщения |
| quit | завершение процедуры |
| 221 dxmint.cern.ch closing connection |
SMTPсервера могут вести диалог с несколькими оконечными пользователями.
Любое почтовое сообщение завершается специальной последовательностью символов. Если получатель успешно завершил прием и обработку почтового сообщения, он посылает положительный отклик.
Протокол SMTP обеспечивает передачу почтового сообщения непосредственно конечному получателю, когда они соединены друг с другом. В противном случае пересылка может выполняться через одну (или более) промежуточную “почтовую станцию”.
Для решения поставленной задачи SMTP-сервер должен знать имя конечного получателя и название почтового ящика места назначения. Аргументом команды MAIL является адрес отправителя (обратный адрес); аргументом команды RCPT - адрес конечного получателя. Обратный адрес используется для посылки сообщения в случае ошибки.
Все отклики имеют цифровые коды. Команды, отклики и имена ЭВМ не чувствительны к тому, строчные или прописные символы использованы при их написании. Это не относится к написанию имен и адресов получателя.
Многие почтовые системы работают только с кодами ASCII. Если транспортный канал работает с октетами, 7-битовые коды будут дополнены нулевым восьмым битом. Для пересылки файлов через SMTP традиционно используется стандартная процедура преобразования данных UUCODE/UUDECODE, которая преобразует двоичный файл в массив символов, допустимых для передачи через SMTP.
Как уже было сказано, процедура отправки почтового сообщения начинается с посылки команды MAIL, которая имеет формат:
MAIL <SP> FROM:<reverse-path> <CRLF>,
где <SP> - пробел, <CRLF> - комбинация кодов возврата каретки и перехода на новую строку, a <reverse-path> - обратный путь.
Эта команда сообщает, что стартует новая процедура и следует сбросить в исходное состояние все статусные таблицы, буферы и o.a. Если команда прошла, получатель реагирует откликом: 250 ОК.
Аргумент <reverse-path> может содержать не только адрес почтового ящика: <reverse-path> в общем случае является списком адресов ЭВМ-серверов, через которые пришло данное сообщение, включая, разумеется, и адрес почтового ящика отправителя.
Первым в списке <reverse-path> стоит адрес ЭВМ-отправителя. После прохождения команды MAIL посылается команда:
RCPT <SP> T0:<forward-path> <CRLF>.
Эта команда указывает адрес конечного получателя <forward-path>. При благополучном прохождении команды получатель посылает код-отклик 250 OK и запоминает полученный адрес. Если получатель неизвестен, SMTP-na?aa? пошлет отклик 550 Failure reply. Команда RCPT может повторяться сколько угодно раз, если адресат не один.
Аргумент <forward-path> может содержать не только адрес почтового ящика, но и маршрутный список ЭВМ по пути к нему. Первым в этом списке должно стоять имя ЭВМ, получившей данную команду. По завершении этого этапа посылается собственно сообщение:
DATA <CRLF>.
При правильном приеме этого сообщения SMTP-сервер реагирует посылкой отклика 354 Intermediate reply (промежуточный отклик) и рассматривает все последующие строки в качестве почтового текста. При получении кода конца текста отправляется отклик: 250 ОК.
Признаком конца почтового сообщения является точка в самом начале строки, за которой следует <CRLF>.
В некоторых случаях адрес места назначения может содержать ошибку, но получатель знает правильный адрес. Тогда возможны два варианта отклика:
| 251 User not local; will forward to <forward-path> (получатель берет на себя ответственность за доставку сообщения. Это случается, когда адресат, например, мигрировал в другую субсеть в пределах зоны действия данного почтового сервера); |
| 551 User not local; please try <forward-path> (получатель знает правильный адрес и предлагает отправителю переадресовать сообщение по адресу <forward-path>). |
Реакция на команду VRFY зависит от аргумента. Так, если среди клиентов почтового сервера имеется два пользователя с именем Ivanov, откликом на команду “VRFY Ivanov” будет “553 User ambiguous”. В общем случае команда “VRFY lvanov” может получить в качестве откликов следующие сообщения:
| 250 Vasja lvanov <lvanov@cUtep.ru>; |
| 251 User not local; will forward to <lvanov@cUtep.ru>; |
| 550 String does not match anything (данная строка ничему не соответствует); |
| 551 User not local; please try <Vasja@ns.itep.ru>; |
| VRFY Chtozachertovchina 553 User ambiguous (несуществующее имя). |
EXPN Example-People 250-Juri Semenov <Semenov@ns.itep.ru> 250-Alexey Sher <Sher@suncom.itep.ru> 250-Andrey Bobyshev <Bobyshev@ns.itep.ru> 250-lgor uursky <Gursky@ns.itep.ru>.
В некоторых системах аргументом команды EXPN может быть имя файла, содержащего список почтовых адресов.
Основной задачей почты служит доставка сообщений в почтовый ящик адресата. Сходную форму услуги оказывают некоторые ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP). Для посылки сообщений на экран терминала адресата предусмотрено три команды:
| SEND <SP> FROM:<reverse-path> <CRLF> - команда SEND требует, чтобы почтовое сообщение было доставлено на терминал. Если терминал адресата не активен в данный момент, то откликом на команду RCPT будет код 450; |
| SОML <SP> FROM:<reverse-path> <CRLF> - команда Send Or MaiL (SOML) пересылает сообщение на экран адресата, если он активен, в противном случае сообщение будет уложено в его почтовый ящик; |
| SAML <SP> FROM:<reverse-path> <CRLF> - команда Send And MaiL (SAML) предполагает доставку сообщения на экран терминала адресата и занесение в его почтовый ящик. |
HELO <SP> <domain> <CRLF>, где <domain> - имя запрашивающего домена, QUIT <CRLF>.
Выражение <forward-path> может быть маршрутом, имеющим вид "@ONE,@TWO:VANJA@THREE", где ONE, TWO и THREE - имена ЭВМ. Концептуально элементы из <forward-path> переносятся в <reverse-path> при пересылке сообщений от одного SMTP-na?aa?a к другому.
Если SMTP-na?aa? обнаружит, что доставка сообщения по адресу <forward-path> невозможна, то он формирует сообщение о “недоставленном письме”, используя <reverse-path>.
Тот факт, что электронная почта является наиболее популярным видом сервиса, делает ее объектом непрерывных доработок и усовершенствований. Так, в документах RFC-1425, -1426, -1427 предлагается вариант расширения возможностей протокола SMTP (ESMTP). Эта модификация сохраняет совместимость со старыми версиями. Клиент, желающий воспользоваться расширенными возможностями, посылает субкоманду EHLO вместо HELO. Если сервер поддерживает ESMTP, он выдаст код-отклик 250. Этот вид отклика является многострочным, что позволяет серверу сообщать о видах сервиса, которые он поддерживает. Например:
250-8В1ТМ1МЕ (rfc-1426)
250-EXPN ( rfc-821 )
250-SIZE (rfc-1427)
250-HELP (rfc-821)
Ключевое слово 8В1ТМ1МЕ говорит о том, что клиент может добавить ключевое слово BODY к субкоманде MAIL FROM и определить тип символов, используемых в сообщении (ASCII или 8-битовые). Ключевое слово XADR указывает на то, что любые ключевые слова, начинающиеся с X, относятся к местным модификациям SMTP. Документ RFC-1522 определяет способ включения не ASCII-код в заголовок почтового сообщения, например:
набор_символов кодировка закодированный_текст =”.
Здесь набор_символов - это спецификация набора символов us-ascii или iso-8859-X, где Х - одиночная цифра, например iso-8859-1. Поле кодировки содержит один символ, характеризующий метод кодировки. В настоящее время используются два метода:
| Q - набор печатных символов, в кодах которых восьмой бит не равен нулю; каждый символ набора отображается тремя символами: знаком равенства (”), за которым следует два шестнадцатеричных числа (например, ”AD). Так, символ пробела будет иметь кодировку ”20; |
| В - 64-символьный набор (Base64, латинские буквы, 10 цифр, а также символы + и /). Метод кодирования подробно описан ниже. |
/p>
Интересным дополнением к традиционной электронной почте является ее расширение MIME (Multupurpose Internet Mail Extentions, RFC-1521). MIME не требует каких-либо переделок в почтовых серверах, это расширение определяет пять новых полей-заголовков (расширение RFC-822):
| MIME-Version: (версия MIME, в настоящее время 1.0); |
| Content-Type: (тип почтового сообщения); |
| Content-Transfer-Encoding: (кодирование почтового сообщения); |
| Content-ID: (идентификатор почтового сообщения) |
| Content-Description: (описание почтового сообщения). |
| 7-битовый набор (NVT ASCII, по умолчанию); |
| набор печатных символов (полезен, когда только небольшая часть символов использует восьмой бит); |
| 64-символьный набор Base64; |
| 8-битовый набор символов, включающий псевдографику с использованием построчного представления; |
| двоичная кодировка (8-битовая кодировка без разбивки на строки). |
Таблица 1.
|
Тип почтового сообщения |
Субтип почтового сообщения |
Описание |
| text | plainrichtext enriched |
Неформатированный текст. Текст с простым форматированием: курсив, жирный, с подчеркиванием и т.д. Упрощение, прояснение и усовершенствование richtext. |
| multipart | mixedparrallel digest alternative |
Сообщение содержит несколько частей, которые обрабатываются последовательно.Сообщение содержит несколько частей, обрабатываемых параллельно. Краткое содержание сообщения. Сообщение содержит несколько частей с идентичным семантическим содержимым |
| message | rfc822patial external-body |
Почтовое сообщение в стандарте RFC-822.Фрагмент почтового сообщения. Указатель действительного текста сообщения |
| application | octet-stream postscript |
Произвольная двоичная информация. Программа PostScript |
| image | jpeg gif |
Формат ISO 10918. Формат обмена CompuServe (Graphic Interchange Format) |
| audio | basic | Формат ISO 11172 |
Адресация
Услуги сети 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, как правило, является просто проходным протоколом для информации из соседних уровней. Хотя многие считают, что 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- система межперсональных сообщений. |
Назначение системы обработки сообщений (СОС) состоит в том, чтобы дать возможность пользователям обмениваться сообщениями на основе их промежуточного накопления.
Рекомендации Х.400 описывают протоколы взаимодействия между всеми компонентами системы управления сообщениями.
Основой кодирования сообщений СОС Х.400 является абстрактно синтаксическая нотация АСН.1.
Возможности.
Х.400 обладает многими необходимыми возможностями при передаче сообщений, а именно:
| определение для сообщений различных уровней приоритетов; |
| подтверждение приёма сообщения; |
| простановка даты и времени; |
| поддержка многих получателей; |
| защита и конфиденциальность сообщений; |
| передача сообщений любых форматов. |
Возможности защиты СОС.
К возможности защиты СОС можно отнести следующие средства:
| Аутентификация отправителя сообщения - даёт возможность получателю или любому АПС, через который проходит сообщение, аутентифицировать подлинность отправителя сообщения. |
| Аутентификация отправителя отчёта – позволяет отправителю аутентифицировать источник отчёта о доставке/недоставке. |
| Аутентификация отправителя зонда – позволяет любому АПС, через который проходит зонд, аутентифицировать источник зонда. |
| Подтверждение доставки – позволяет отправителю сообщения аутентифицировать доставленное сообщение, его содержимое, и подлинность получателя. |
| Подтверждение предоставления – позволяет отправителю сообщения аутентифицировать предоставление сообщения СПС для доставки первоначально назначенному получателю. |
| Защита управления доступом – предусматривает аутентификацию между смежными компонентами и установку контекста защиты. |
| Целостность содержимого – даёт возможность получателю убедиться в том, что исходное содержимое сообщения не было изменено. |
| Конфиденциальность содержимого – предотвращает несанкционированное раскрытие содержимого сообщения тому, кто не является заданным получателем. |
| Конфиденциальность потока сообщений – позволяет отправителю сообщения скрыть поток сообщений через СОС. |
| Целостность последовательности сообщений – позволяет отправителю обеспечить получателю подтверждение сохранности последовательности сообщений. |
| Бесспорность отправителя – обеспечивает получателю сообщения подтверждения происхождения сообщения и его содержимого, которое должно предотвратить любую попытку отправителя ложно отрицать посылку сообщения или его содержимое. |
| Бесспорность доставки – обеспечивает отправителю сообщения подтверждения доставки. |
| Разметка защиты сообщениё – обеспечивает возможность определить категорию сообщения, указав его конфиденциальность, которая определяет обработку сообщения в соответствии с действующей политикой защиты. |
