Nets2010 (1131259), страница 32

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 32)

Рисунок 4-27. Устройство маркера и кадра передачи данных

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

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

Байты Starting delimiter и Ending delimiter отмечают начало и конец кадра соответственно. Они содержат запрещенные в дифференциальных манчестерских кодах последовательности. Байт Access control содержит маркерный бит, Monitor bit, Priority bits, Reservations bits (они будут описаны позднее).

Поля Destination address и Source address такие же, как и в стандартах 802.3 и 802.4. За ними следует поле данных, которое может быть сколь угодно длинное, лишь бы его передача уместилась во время владения маркером. Поле контрольной суммы такое же, как и в 802.3 и 802.4.

Байт, которого нет ни в 802.3 ни в 802.4 - Frame status. В нем есть биты А и С. Когда кадр поступает к станции-получателю, ее интерфейс инвертирует бит А. Если кадр успешно скопирован, то инвертируется и бит С. Кадр может быть не скопирован в силу разных причин: задержки, отсутствия места в буфере и т.п.

Когда станция-получатель снимает ранее посланные биты с линии, она анализирует биты А и С. По их комбинации она может определить, успешно ли прошла передача. Возможны три комбинации значений этих битов:

1. А=0, С=0 - получатель отсутствует

2. А=1, С=0 - получатель есть, но кадр не принят

3. А=1, С=1 - получатель есть и кадр принят

Биты А и С обеспечивают автоматическое уведомление о получении кадра. Если кадр почему-то не был принят, то у станции есть несколько попыток передать его. Биты А и С дублируются в байте Frame status с целью повысить надежность, так как этот байт не подпадает под контрольную сумму.

Ending delimiter содержит специальный бит, который устанавливает интерфейс любой станции, если он обнаруживает ошибку. Там также есть бит, которым можно помечать последний кадр в логической последовательности кадров.

В 802.5 есть тщательно проработанная схема работы с приоритетами. В среднем байте 3-байтного маркера есть поле, отведенное для приоритета. Если станции надо передать кадр с приоритетом n, то ей придется ждать, пока появится маркер с приоритетом, меньшим или равным n. Кроме того, когда кадр с данными проходит по кольцу, станция может указать значение приоритета, который ей нужен. Для этого она записывает нужное значение в поле Reservation bits. Однако если в нем уже записан более высокий приоритет, станция не может этого делать. После завершения передачи кадра генерируется маркер с приоритетом, зарезервированном в этом кадре.

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

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

Поддержка кольца.

В стандарте 802.5 поддержка кольца организована иначе, чем это сделано в 802.4. Там был создан довольно длинный протокол для полностью децентрализованной поддержки. В 802.5 предусмотрено, что в кольце всегда есть станция-монитор, контролирующая кольцо. Если станция-монитор по какой-либо причине потеряет работоспособность, есть протокол выбора и объявления другой станции-монитора на кольце. Любая станция способна быть монитором.

При включении или если какая-то станция заметит отсутствие монитора, она посылает кадр CLAIM_TOKEN. Если она первая, кто послал такой кадр, то она и становится монитором. В таблице 4-28 показаны кадры для поддержки кольца.

Таблица 4-28. Кадры поддержки кольца

Контрольное поле	Название	Значение кадра
00000000	Duplicate address test	Проверка, имеют ли 2 станции одинаковый адрес
00000010	Beacon	Локализация разрыва кольца
00000011	Claim token	Попытка стать монитором
00000100	Purge	Реинициализация кольца
00000101	Active monitor present	Периодически рассылается монитором
00000101	Standby monitor present	Заявление о наличии потенциальных мониторов

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

При появлении грязи, т.е. кадра с неверным форматом или контрольной суммой, монитор снимает его с линии и генерирует маркер. Беспризорные кадры монитор обнаруживает с помощью Monitor bit в байте Access control. Когда кадр проходит через монитор первый раз, монитор устанавливает этот бит в единицу. Поэтому, если очередной кадр пришел с единицей в этом бите, то этот кадр не был принят и монитор должен его удалить из кольца.

Важной функцией монитора является установка задержки на кольце, достаточной, чтобы в кольце уместился 24-битный маркер.

Монитор не может определить, где произошел разрыв кольца. Поэтому, если какая-то станция заметит отсутствие соседа, она генерирует BEACON-кадр. По мере распространения этого кадра по кольцу определяется, какие станции живы, а какие нет, и последние удаляют из кольца с помощью кабельного центра.

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

43. Протокол LLC уровня управления логическим каналом (IEEE802.2)

Протокол LLC(Logical Link Control). обеспечивает нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. Протокол LLC занимает уровень между сетевыми протоколами и протоколами уровня MAC. Протоколы сетевого уровня передают через межуровневый интерфейс данные для протокола LLC - свой пакет (например, пакет IP, IPX или NetBEUI), адресную информацию об узле назначения, а также требования к качеству транспортных услуг, которое протокол LLC должен обеспечить. Протокол LLC помещает пакет протокола верхнего уровня в свой кадр, который дополняется необходимыми служебными полями. Далее через межуровневый интерфейс протокол LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня MAC, который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).

В основу протокола LLC положен протокол HDLC (см. раздел …). В спецификации IEEE 802.2 есть несколько небольших отличий от стандарта HDLC.

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

Три типа процедур уровня LLC

В соответствии со стандартом 802.2 уровень управления логическим каналом LLC предоставляет верхним уровням три типа процедур:

• LLC1 - процедура без установления соединения и без подтверждения;

• LLC2 - процедура с установлением соединения и подтверждением;

• LLC3 - процедура без установления соединения, но с подтверждением.

Этот набор процедур является общим для всех методов доступа к среде, определенных стандартами 802.3 - 802.5.

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

Процедура с установлением соединений и подтверждением LLC2 дает пользователю возможность установить логическое соединение перед началом передачи любого блока данных и, если это требуется, выполнить процедуры восстановления после ошибок и упорядочивание потока этих блоков в рамках установленного соединения. Протокол LLC2 во многом аналогичен протоколам семейства HDLC (LAP-B, LAP-D, LAP-M), которые применяются в глобальных сетях для обеспечения надежной передачи кадров на зашумленных линиях. Протокол LLC2 работает в режиме скользящего окна.

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

Использование одного из трех режимов работы уровня LLC зависит от стратегии разработчиков конкретного стека протоколов. Например, в стеке TCP/IP уровень LLC всегда работает в режиме LLC1, выполняя простую работу извлечения из кадра и демультиплексирования пакетов различных протоколов - IP, ARP, RARP(эти протоколы будут рассмотрены во втором томе). Аналогично используется уровень LLC стеком IPX/SPX.

Режим LLC2 используется также стеком протоколов фирмы IBM в том случае, когда на нижнем уровне применяется технология Token Ring.

Рисунок 4-29. Действие LCC-протокола: (а) его расположение; (b) форматы протокола

44. Структура кадров в протоколе IEEE802.2

Подобно протоколу HDLC, по своему назначению все кадры уровня LLC подразделяются на три типа - информационные, управляющие и ненумерованные.

• Информационные кадры (Information) предназначены для передачи информации в процедурах с установлением логического соединения LLC2 и должны обязательно содержать поле информации. В процессе передачи информационных блоков осуществляется их нумерация в режиме скользящего окна.

• Управляющие кадры (Supervisory) предназначены для передачи команд и ответов в процедурах с установлением логического соединения LLC2, в том числе запросов на повторную передачу искаженных информационных блоков.

• Ненумерованные кадры (Unnumbered) предназначены для передачи ненумерованных команд и ответов, выполняющих в процедурах без установления логического соединения передачу информации, идентификацию и тестирование LLC-уровня, а в процедурах с установлением логического соединения LLC2 -установление и разъединение логического соединения, а также информирование об ошибках. Все типы кадров уровня LLC имеют единый формат:

Кадр LLC обрамляется двумя однобайтовыми полями «Флаг», имеющими значение 01111110. Флаги используются на уровне MAC для определения границ кадра LLC. В соответствии с многоуровневой структурой протоколов стандартов IEEE 802, кадр LLC вкладывается в кадр уровня MAC: кадр Ethernet, Token Ring, FDDI и т. д. При этом флаги кадра LLC отбрасываются.

Кадр LLC содержит поле данных и заголовок, который состоит из трех полей:

• адрес точки входа службы назначения (Destination Service Access Point, DSAP);

• адрес точки входа службы источника (Source Service Access Point, SSAP);

• управляющее поле (Control).

Поле данных кадра LLC предназначено для передачи по сети пакетов протоколов вышележащих уровней, например, сетевых протоколов IP, IPX, AppleTalk. Поле данных может отсутствовать в управляющих кадрах и некоторых ненумерованных кадрах.

Характеристики

Список файлов ответов (шпаргалок)