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

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

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

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

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

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

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

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

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

Для ответа на этот вопрос в 1978 году Международная Организация по Стандартизации

(ISO – International Organization for Standardization) приступила к созданию эталонной модели OSI

– Open System Interconnection. Специалистами ISO была создана универсальная общепринятая модель сетевого взаимодействия, которая позволяет сетевым специалистам всего мира разговаривать на одном языке (документацию и стандарты, описывающие модель OSI можно бесплатно загрузить с http://www.itu.int/rec/T-REC-X/en как часть рекомендаций X.200).

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

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

Модель OSI состоит из семи уровней:

Уровни нумеруются снизу вверх, с первого по седьмой, и носят следующие названия: Layer 7: Application Layer

Layer 6: Presentation Layer Layer 5: Session Layer Layer 4: Transport Layer Layer 3: Network Layer Layer 2: Data Link Layer Layer 1: Physical Layer

Соответствующие русские названия выглядят следующим образом:

Уровень 7: Прикладной Уровень 6: Представительский Уровень 5: Сеансовый

Уровень 4: Транспортный Уровень 3: Сетевой Уровень 2: Канальный Уровень 1: Физический

В литературе по сетям вы сможете увидеть другие русские названия, так, например, 7-й уровень может называться уровнем приложений, 6-й – уровнем представлений. Не стоит задумываться, какой из вариантов правильный, это всего лишь проблема корректного перевода, и главное, чтобы вы сами понимали, о чем идет речь. Поэтому на вопрос «а как правильно» смело отвечайте: «а правильно – по-английски»

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

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

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

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

г) Собирать аналогичные функции на одном уровне.

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

ранее была выбрана успешно.

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

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

(См. ITU-T Recommendation X. 200; INFORMATION TECHNOLOGY – OPEN SYSTEMS INTERCONNECTION – BASIC REFERENCE MODEL: THE BASIC MODEL)

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

Подробно рассмотрим функции каждого уровня.

По определению ITU-T, физический уровень (CCNA1 8.x.x.x) прозрачным образом обеспечивает передачу потока бит между сущностями (объектами) канального уровня через физические соединения («The Physical Layer provides for the transparent transmission of bit streams between data- link-entities across physical-connections»)

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

Это легче будет понять, если в качестве систем, обменивающихся данными, мы представим двух беседующих людей. Что будет иметь отношение к физическому уровню? Громкость голоса, тембр голоса, передатчик-генератор сигнала – голосовые связки, приемник-преобразователь – барабанные перепонки. Среда передачи сигнала – воздух, сигнал – звуковая волна, распространяющаяся в среде передачи данных, представляющая изменения громкости и тембра голоса.

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

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

Теперь   зададимся   вопросом   –   достаточно   ли   ТОЛЬКО   физического   уровня      для организации успешного обмена данными? Очевидно, нет. Представьте себе ситуацию, когда в

комнате находится несколько человек, и каждый из них хочет вести диалог с кем-то другим из присутствующих. Что получится в результате? Только шум, не содержащий практически никаких полезных данных. Эта ситуация вам знакома, с задачей совместного использования разделяемой среды передачи данных («разделением среды») вы должны были ознакомиться ранее: вспомните методы разделения среды «вежливые люди», «парламент» и «трубка мира».

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

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

Вы можете следить за любыми ответами на эту запись через 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