Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.sao.ru/hq/vch/RusDoc/ito/12.htm
Дата изменения: Tue Mar 17 15:19:24 1998 Дата индексирования: Tue Oct 2 05:15:03 2012 Кодировка: koi8-r Поисковые слова: п п п п п п п п п п п |
![]() |
Сервер поддерживается Центром Информационных Технологий (095) 932-9212, 932-9213, 939-0783 E-mail: info@citforum.ru |
Сервер Информационных Технологий содержит море(!) аналитической информации
|
---|
IBM разработала протокол Synchronous Data-Link Control (SDLC) (Управление синхронным каналом передачи данных) в середине 1970 гг. для применения в окружениях Systems Network Architecture (SNA) (Архитектура системных сетей). SDLC был первым из протоколов канального уровня нового важного направления, базирующегося на синхронном бит-ориентированном режиме работы. По сравнению с синхронным, ориентированным по символам (например, Bisynk фирмы IBM) и синхронным, с организацией счета байтов (например, Digital Data Communications Message Protocol - Протокол Сообщений Цифровой Связи) протоколами, бит-ориентированные синхронные протоколы являются более эффективными и гибкими, и очень часто более быстродействующими.
После разработки SDLC компания IBM представила его на рассмотрение в различные комитеты по стандартам. Международная Организация по Стандартизации (ISO) модифицировала SDLC с целью разработки протокола HDLC (Управление каналом связи высокого уровня). Впоследствии Международный консультативный комитет по телеграфии и телефонии (CCITT) модифицировал HDLC с целью создания "Процедуры доступа к каналу" (LAP), а затем "Процедуры доступа к каналу, сбалансированной" (LAPB). Институт инженеров по электротехнике и радиоэлектронике (IEEE) модифицировал HDLC , чтобы разработать IEEE 802.2. Kaждый из этих протоколов играет важную роль в своей области. SDLC остается основным протоколом канального уровня SNA для каналов глобальных сетей.
SDLC поддерживает разнообразные типы соединений и топологий. Он может применяться в сетях с двухточечными (непосредственными) и многоточечными связями, со связанным и несвязанным носителем, с полностью и наполовину дублированными средствами передачи, с коммутацией цепей и коммутацией пакетов.
SDLC идентифицирует два типа сетевых узлов:
Первичные и вторичные узды SDLC могут быть соединены в соответствии со следующими четырьмя основными конфигурациями:
Формат блока данных SDLC представлен на Рис. 12-1.
Как видно из рисунка, блоки данных SDLC ограничены уникальной структурой "флага" (flag). Поле "адрес" (address) всегда содержит адрес вторичного узла, задействованного в текущей связи. Т.к. первичный узел является либо источником связи, либо пунктом назначения, нет необходимости включать его адрес - он заранее известен всем вторичным узлам.
"Управляющее" (control) поле использует три разных формата в зависимости от использованного типа блока данных SDLC. Описание трех типов блока данных SDLC дается ниже в следующем перечне:
Последовательность проверки блока данных (frame check sequence) (FCS) предшествует ограничителю завершающего флага. FCS обычно является остатком расчета "проверки при помощи циклического избыточного кода" (cyclic redundency check) (CRC). Расчет CRC выполняется повторно получателем. Если результат отличается от значения, содержащегося в блоке данных отправителя, считается, что имеет место ошибка.
Типичная конфигурация сети, базирующейся на SDLC, представлена на Рис. 12-2. Как показано на рисунке, контроллер организации связи IBM (раньше называвшийся групповым контроллером) на отдаленном пункте подключен к "немым" терминалам и к сети Token Ring. На местном вычислительном центре главная вычислительная машина IBM подключена (через оборудование подключения каналов) к фронтальному процессору (FEP), который может также иметь связи с местными локальными сетями Token Ring и стержнем SNA. Оба пункта соединены с помощью арендуемой, базирующейся на SDLC, 56-Kb/сек линии.
Несмотря на то, что в HDLC не вoшли несколько характеристик, используемых в SDLC, он повсеместно считается некой суперразновидностью SDLC, совместимой с ним. LAP считается подразновидностью HDLC. LAPB был разработан, чтобы обеспечить продолжение совместимости с HDLC, который был изменен в начале 1980 гг. IEEE 802.2 является модификацией HDLC для окружений LAN.
Формат блока данных HDLC такой же, как у SDLC; поля HDLC обеспечивают те же функциональные возможности, что и соответствующие поля SDLC. Кроме того, также, как и SDLC, HDLC обеспечивает синхронный режим работы с полным дублированием.
HDLC имеет несколько незначительных отличий от SDLC. Во-первых, HDLC имеет вариант для 32-х битовых контрольных сумм. Во-вторых, в отличие от SDLC, HDLC не обеспечивает конфигурации "loop" и "hub go-ahead". Главным различием между HDLC и SDLC является то, что SDLC обеспечивает только один режим передачи, в то время как HDLC обеспечивает три. HDLC обеспечивает следующие три режима передачи:
LAPB является наиболее популярным протоколом благодаря тому, что он входит в комплект протоколов Х.25. Формат и типы блока данных, а также функции поля у LAPB те же самые, что у SDLC и HDLC. Однако в отличие от любого из этих двух протоколов, LAPB обеспечивает только один режим передачи ABM, поэтому он подходит только для комбинированных станций. Кроме того, цепи LAPB могут быть организованы либо терминальным оборудованием (DTE), либо оборудованием завершения действия информационной цепи (DCE). Станция, инициирующая обращение, определяется как первичная, в то время как реагирующая станция считается вторичной. И наконец, использование протоколом LAPB бита P/F несколько отличается от его использования другими протоколами. Подробности смотри в Главе 13 "Х.25".
IEEE 802.2 часто называют Logical Link Control (LLC) (Управление логическим каналом связи). Он чрезвычайно популярен в окружениях LAN, где он взаимодействует с такими протоколами, как IEEE 802.3, IEEE 802.4 и IEEE 802.5.
IEEE 802.2 предлагает три типа услуг. Тип 1 обеспечивает услуги без установления соединения и подтверждения о приеме. Тип 2 обеспечивает услуги с установлением соединения. Тип 3 обеспечивает услуги без установления соединения с подтверждением о приеме.
Являясь обслуживанием без установления соединения и подтверждения о приеме, Тип 1 LLC не подтверждает передачу данных. Т.к. большое число протоколов верхнего уровня, таких как Transmissin Control Protocol/ Internet Protocol (ТCP/IP), обеспечивают надежную передачу информации, которая может компенсировать недостаточную надежность протоколов низших уровней, Тип 1 является широко используемой услугой.
Обслуживание Типа 2 LLC (часто называемое LLC2) организует виртуальные цепи между отправителем и получателем и, следовательно, является обслуживанием с установлением соединения. LLC2 подтверждает получение информации; оно используется в системах связи IBM.
Обеспечивая передачу данных с подтверждением, обслуживание Типа 3 LLC не организует виртуальных цепей. Являясь компромиссом между двумя другими услугами LLC, Тип 3 LLC бывает полезным в окружениях фабричных автоматизированных систем, где обнаружение ошибок очень важно, однако область памяти контекста (для виртуальных цепей) чрезвычайно ограничена.
Конечные станции могут обеспечить множество типов услуг LLC. Устройство Класса 1 обеспечивает только услуги Типа 1. Устройство Класса II обеспечивает как услуги Типа 1, так и услуги Типа 2. Устройства Класса III обеспечивает услуги Типа 1 и Типа 3, в то время как устройства Класса IV обеспечивают все три типа услуг.
Процессы высших уровней используют услуги IEEE 802.2 через "точки доступа к услугам" (SAP). Заголовок IEEE 802.2 начинается с поля "точки доступа к услугам пункта назначения" (DSAP), которое идентифицирует принимающий процесс высшего уровня. Другими словами, после того, как реализация IEEE 802.2 принимающего узла завершит свою обработку, процесс высшего уровня, идентифицированный в поле DSAP, принимает оставшиеся данные. За адресом DSAP следует адрес "точки доступа к услугам источника" (SSAP), который идентифицирует передающий процесс высшего уровня.