Модель OSI (CCNA1 2.4.1.1 – 2.4.2.1) – ЧАСТЬ 4

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

Теперь, когда мы с вами ознакомились с моделью OSI, мы можем попробовать разобраться,

что именно происходит с информацией при ее передаче в рамках данной модели .

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

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

Изобразим эти две системы графически, выделив важные уровни.

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

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

специалистами. Абсолютно точно так же происходит физическое движение информации в рамках модели OSI: физически информация передается между соседними уровнями одной системы – отправителя –  сверху вниз, далее по линии связи к другой системе, далее между физическими уровнями другой системы – получателя – снизу вверх. Логическое же взаимодействие происходит строго между уровнями.

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

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

Набор формальных правил и соглашений, регламентирующих взаимодействие между одинаковыми уровнями различных систем, называется протоколом (CCNA1 2.3.2.x – 2.3.5.x).

ITU-T определяет протокол соответствующего уровня следующим образом: протоколом уровня N называется набор правил и форматов (семантических и синтаксических), который определяет характер взаимодействия между сущностями уровня N при исполнении функций уровня N. («(N)-protocol: A set of rules and formats (semantic and syntactic) which determines the communication behavior of (N)-entities in the performance of (N)-functions»)

Определение же интерфейса в рекомендациях ITU-T звучит так: с точки зрения OSI взаимодействие между службой-пользователем и службой провайдером представляет собой абстрактный интерфейс на границе уровня OSI и определяется в терминах набора примитивов, которые обеспечивают обмен данными между службами, вместе с последовательностью правил, определяющих этот обмен. («The interactions between the OSI-service-user and the OSI-service- provider constitute an abstract interface at the OSI service boundary. This abstract interface is the OSI- local view. The OSI-local view is defined in terms of the set of OSI service primitives which the OSI- service user and the OSI-service-provider are allowed to exchange, together with the sequencing rules which apply to these exchanges»)

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

Перейдем теперь непосредственно к вопросу о передаче информации в модели OSI.

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

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

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

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

На сетевом уровне каждый блок данных должен быть снабжен адресной информацией,

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

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

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

Мы видим, что каждый уровень модели OSI считает данные, пришедшие к нему с верхнего уровня, неструктурированными, и дополняет эти данные своей служебной информацией. Эта служебная информация, необходимая для корректной обработки данных получателем, носит название заголовков соответствующего уровня   (например, заголовок прикладного уровня, заголовок сетевого уровня и т. д.). Процесс же добавления этих заголовков при движении информации  называется  инкапсуляцией  (CCNA1  2.4.5.1  –  2.4.6.1).  Очевидно,  что  каждый заголовок имеет смысл только для соответствующего уровня системы-получателя, верхние уровни не нуждаются в заголовках нижних уровней. Поэтому каждый уровень системы-получателя, обработав соответствующий заголовок, отбрасывает его, и передает на верхний уровень данные уже без своего заголовка. Этот   процесс отбрасывания заголовков называется декапсуляцией (термин используется реже, чем «инкапсуляция»)

Автора: © Виталий Бочаров, Владимир Недеркин, Александр Трофимов

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100