Смекни!
smekni.com

Технологии создания сетей (стр. 30 из 62)

стандарт 802.2, и, ориентированным на применение неэкранированной витой

пары. Предполагается, что спецификации 802.9 будет придан статус стандарта

IEEE в конце 1991, начале 1992 года.

Подкомитет IEEE 802.10 образует рабочую группу, занимающуюся разнообразными

вопросами обеспечения защиты в ЛС. Рассматриваются вопросы обеспечения

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

архитектурной совместимости с Моделью OSI в плане обеспечения безопасности.

[КС 16-5]

[1]Итоги

[5]Стандарты IEEE специфицируют наиболее популярные архитектуры ЛС. Рабочие

группы и консультативные комитеты ведут работы по постоянному

совершенствованию стандартов в рамках проекта 802, что обеспечивает и

гарантирует их актуальность в течение длительного периода времени.

[КС 16-6]

[1]Упражнение 16

[5]1. В какой комитет IEEE вам следует обратиться за консультацией по

вопросу применения оптоволокна?

а. IEEE 802.2

b. IEEE 802.8

c. IEEE 802.4

d. IEEE 802.1

2. Каким комитетом IEEE рассматриваются вопросы оптимального использования

услуг (сервисы) интегрированных цифровых сетей (ISDN)?

a. IEEE 802.9

b. IEEE 802.8

c. IEEE 802.7

d. IEEE 802.6

3. Какой функциональный уровень Модели OSI не затрагивают спецификации

проекта 802?

а. MAC подуровень

b. LLC подуровень

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

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

[КС 16-7]

[КС 16-8]

[ IEEE 802.2 (LLC) ]

[0]Раздел 17 [2] IEEE 802.2 (LLC)

[1]Цели

[5]В результате изучения данного раздела вы сможете определять основные

характеристики стандарта 802.2 и его взаимосвязи со всеми другими стандартами

серии 802.

[1]Введение

[5]В разделе 16 была введена в рассмотрение серия стандартов IEEE 802 и

было показано, что эти стандарты функционально охватывают два нижних уровня

Модели OSI. В данном разделе обсуждается один из основных элементов серии

стандарт IEEE 802.2, называемый также LLC. Обсуждение касается определения

функций стандарта 802.2, его взаимосвязи с другими стандартами серии и

Моделью OSI. Рассматривается основной формат кадра и функциональные

особенности.

[КС 17-1]

[ IEEE 802.2 и Модель OSI ]

[ Модель ] [ Модель ] [ Стандарты ]

[ OSI ] [ IEEE 802] [ IEEE 802 ]

[ Уровни ]

[ 4-7 ]

[ Сетевой ] [ 802.1 Создание интерсетей, Обзор, Системное управление]

[ Канальный] [ Управление] [ CSMA/CD] [Маркерная] [Маркерное] [Другие]

[логическим ] [шина] [кольцо] [Стандарты]

[ каналом ] [802]

[ 802.3 ] [ 802.4 ] [ 802.5 ]

[ Физический][Физический] [Физический] [Физический] [Физический]

[ к рис. на стр. 17-2 (в поле рисунка) ]

[1] Обзор 802.2

[5]Как уже указывалось в разделе 16, в стандартах IEEE Канальный уровень

Модели OSI представлен в виде двух подуровней. Подуровень Управления

логическим каналом или звеном (LLC) несет ответственность за обеспечение

надежной передачи данных в интересах Сетевого уровня. Причем исполняемые при

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

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

специфицированным в стандарте IEEE 802.2. Услуги LLC совместимы с различными

стандартными методами доступа к среде (MAC). Стандарты MAC для конкретных

сред определены в остальных документах серии 802.

Стандарт LLC был разработан на основе протокола HDLC, рассмотренного в

разделе 15. Однако существуют некоторые различия между двумя протоколами.

[КС 17-2]

[ Формат кадра LLC ]

[число восьми- ]

[битовых байтов] [1 или 2]

[ MAC ] [DSAP] [SSAP] [Управление] [информация] [ MAC KC ]

[заголовок] [адрес] [адрес]

[1]Формат кадра LLC

[5]Формат кадра LLC состоит из 4-х полей, показанных на рисунке. Ниже

приведено краткое обсуждение полей кадра.

Кадр LLC в соответствии с Моделью OSI называется протокольным элементом

данных (PDU - Protocol Data Unit). При рассмотрении структуры PDU точный

битовый порядок полей не конкретизируется, внимание уделяется семантике

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

элементами PDU.

Аналогично всем другим канальным протоколам стандарт 802.2 предназначен для

обслуживания протоколов Сетевого уровня. Канальные услуги предоставляются

в так называемых сервисных точках доступа (SAP - Service Access Points).

Точки доступа подобны "почтовым ящикам". Протоколы сетевого уровня и

собственно LLC имеют доступ к этим "почтовым ящикам" и соответственно могут

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

точка доступа имеет некоторый адрес. В случае LLC точки доступа уникально

идентифицируют процессы сетевого уровня. Для процессов сетевого уровня точки

доступа являются местами, в которых обеспечивается требуемый набор услуг по

передаче сообщений.

[КС 17-3]

[5]Первым полем 802.2 PDU является DSAP (Destination Service Access Point,

Целевая Сервисная точка доступа). В DSAP указывается адрес целевого процесса

Сетевого уровня (процесса-приемника). Аналогично во втором поле PDU,

называемом SSAP (Source Service Access Point, Сервисная точка доступа

инициатора передачи), содержится адрес передающего процесса Сетевого уровня.

Оба поля имеют размер в 1 байт, а назначение адресов определено стандартами

IEEE. В полях SSAP и DSAP семь битов отведены под представление адреса, а

восьмой - для управления. В поле DSAP восьмой бит использутся для указания

типа адреса: групповой или индивидуальный. В SSAP бит управления

специфицирует содержимое PDU: запрос или ответ. В LLC эти биты используются

для определения алгоритма обработки поля управления PDU.

Поле Управления содержит один или два байта в зависимости от того, какая

услуга исполняется для данного PDU. Структура поля управления также зависит

от типа запрашиваемой услуги.

Четвертым полем, которого может и не быть, является информационное поле, в

котором переносится информация более высоких уровней.

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

выполняемые LLC функции. Функции LLC рассматриваются в последующих

подразделах. Рассматриваются также типы и классы выполняемых соединений, но

примитивы специальных услуг не приводятся.

[1]Защита от ошибок

[5]Защита от ошибок в LLC не имеет форму подсчета контрольной суммы или

определения паритета. В таком виде эта функция выполняется на подуровне MAC,

и предназначается для защиты LLC подуровня от искаженных пакетов. В рамках

LLC функция защиты от ошибок заключается в обеспечении целостности сквозной

передачи данных между двумя взаимодействующими станциями.

Например, запрос на установление канала может быть отклонен из-за того, что

запрашивающая сторона не располагает определенными правами. При этом

формируется PDU с целью оповестить Сетевой уровень о том, что соединение

не установлено с указанием соответствующей причины.

Другой пример функции защиты от ошибок - это обеспечение переустановки

соединения. Если канальное соединение по какой-либо причине прерывается

(напрмер, из-за повышенного уровня шумов в среде передачи данных), то может

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

некоторое начальное состояние. При этом часть данных, находящихся в стадии

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

фиксируется и исправляется соответствующим высокоуровневым протоколом.

[КС 17-4]

[1]Управление потоком.

[5]Подобно другим канальным протоколам в LLC принимаются меры, предотвращающие

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

метода. В первом, называемом старт-стоповым (stop-and-wait), передатчику

запрещается передавать очередной кадр до тех пор, пока не будет получено от

приемника положительное подтверждение на предыдущий кадр. Этот метод

обеспечивает хорошую устойчивую передачу данных. Однако из-за того, что

всякий раз в передаче находится только один PDU, старт-стоповая передача не

обладает достаточной эффективностью. Второй метод, называемый "метод передачи

в окне" (sliding window), разрешает проблему эффективности. Метод передачи в

окне (рассматриваемый в разделе 24) позволяет передатчику передавать большое

число PDU, не дожидаясь подтверждения на каждый PDU. Разрещенное число

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

если размер окна 5, то передатчик передает 5 PDU, но затем должен ожидать

подтверждение приема прежде, чем продолжить передачу. Приемник при этом в

одном подтверждении может подтвердить прием более одного PDU. Протоколы,

реализующие метод окна, являются полнодуплексными.

[КС 17-5]

[ Типы услуг LLC ]

[ Тип 1 ]

[ Тип 2 ]

[ Тип 3 ]

[ к рис. на стр. 17-6 (в поле рисунка)]

[1]Типы и классы

[5]LLC протокол обеспечивает исполнение трех типов услуг, каждый из которых,

как минимум, позволяет вести передачу и прием данных. Ниже рассматриваются

эти типы услуг, их некоторые свойства и ограничения.

Тип 1 - Услуга неподтверждаемой передачи данных без установления соединения.

Данная услуга не поддерживает механизмы подтверждения передачи данных. Из-за

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

передачи данных услуга обеспечивает наиболее высокую скорость передачи. По

этим же причинам она является наименее сложной в реализации. Но с другой

стороны услуга Типа 1 ненадежна. Несмотря на этот недостаток, Тип 1

применяется довольно широко совместно с использованием надежных транспортных

протоколов, для которых не требуется высокая надежность звеньев (каналов

передачи данных).

Тип 2 - Услуга, ориентированная на соединение. Для обмена данными между

передатчиком и приемником устанавливается соединение Канального уровня. После

установления соединения осуществляется передача данных до тех пор, пока одна

из сторон не завершит соединение. В ходе передачи данных применяется