Модель ссылок OSI: Оборудование второго уровня

Published on Февраль 18, 2009 by   ·   Комментариев нет

В своей предыдущей статье, я познакомил вас с моделью ссылок взаимодействия открытых систем (Open System Interconnect (OSI)), а также рассказал о ее первом уровне; физическом уровне. В этой части мы обсудим второй уровень, канальный уровень, с точки зрения оборудования.

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

  • Управление логической связью (Logical Link Control)
  • Осуществление сетевого доступа и обнаружение конфликтов (Media Access Control)
  • Кадрирование данных (Data Framing)
  • Адресация (Addressing)
  • Обнаружение ошибок (Error Detection)

Управление логической связью

Управление логической связью (LLC) обычно считается подуровнем канального уровня (DLL), в противоположность функции DLL. Этот LLC подуровень в первую очередь отвечает за отправку мультиплексированных протоколов на Media Access Control (MAC) подуровень. LLC осуществляет это путем разбивания данных, которые необходимо отправить, на более мелкие фреймы (блоки) и добавления описательной информации, именуемой заголовками, этим блокам.

Уровень сетевой архитектуры Media Access Control

Как и LLC, Media Access Control (MAC) считается подуровнем DLL, в противоположность функции DLL. В этот уровень включает то, что известно под названием MAC адреса. MAC адрес обеспечивает данный подуровень уникальным идентификатором, в результате чего каждая точка доступа сети может взаимодействовать с сетью. Подуровень MAC также отвечает за действительный доступ к сетевому кабелю, или другому средству соединения.

Кадрирование данных

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

Структура наложения фреймов на протокол Ethernet показана ниже на рисунке 1.

48922

Рисунок 1: Структура Ethernet фрейма (Предоставлено: Wikipedia)

Адресация

Адресация на втором уровне происходит, как уже отмечалось, с MAC адресом на MAC подуровне. Очень важно не путать эту адресацию с IP адресацией. Очень полезно ассоциировать MAC адрес с определенной точкой доступа сети, а сетевой или IP адрес ассоциируется со всем устройством (то есть компьютером, сервером или маршрутизатором).

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

Определение и исправление ошибок

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

Биты четности являются примером протокола обнаружения ошибок, который прост и, несмотря на его ограниченную эффективность, довольно широко используется. Бит четности, если говорить простым языком, представляет собой дополнительный бит, добавленный к посланию. Существует два вида значения этого бита. Какое значение выбрано, зависит от типа определения бита четности, который используется. Эти два типа представляют собой четную и нечетную разрядность определения. Если используется четная разрядность, то бит четности задает значение (‘1’ или ‘0’), необходимое чтобы уровнять количество ‘1’ в послании. Подобным образом, если используется нечетная разрядность, то бит четности задает значение, необходимое чтобы сделать количество единиц в послании нечетным (неравным).

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

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

Одним из самых строгих методов обнаружения ошибок является контроль циклическим избыточным кодом (cyclic redundancy check (CRC)). CRC преобразует послание в полином, где значение коэффициентов соответствует битам в послании, после чего этот полином делится на предопределенный или стандартный полином, называемый ключом. Результат, или если говорить более точно, оставшаяся часть результата – это то, что отправляется с посланием получателю. Получатель осуществляет такое же многочленное деление с помощью такого же ключа, а затем сверяет результат. Если результат совпадает, то шансы того, что ошибки отсутствуют, довольно высоки. Я сказал «довольно высоки», потому что существует множество всевозможных полиномов, которые можно использовать в качестве ключа, и не все полиномы обеспечивают одинаково хорошее определение ошибок. Как правило, более длинные полиномы обеспечивают более хорошее обнаружение ошибок, но математика, используемая здесь, довольно сложна, и, как и в случае со многими аспектами технологии, продолжаются споры по поводу того, какой тип использования этого метода обеспечивает наиболее хорошее обнаружение ошибок.

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

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

www.windowsnetworking.com


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]