HDLC (High Level Data Link Control) протокол

Здесь мы познакомимся с группой протоколов давно известных, но по-прежнему широко используемых. Все они имеют одного предшественника - SDLC - Synchronous Data Link Control - протокол управления синхронным каналом, предложенным фирмой IBM в рамках SNA. ISO модифицировало этот протокол и выпустило под название HDLC - High level Data Link Control. МКТТ модифицировало HDLC для X.25 и выпустило под именем LAP - Link Access Procedure. Позднее он был модифицирован в LAPB.

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

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

Поле Control используется для последовательных номеров кадров, подтверждений и других нужд.

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

Поле Checksum - это поле используется CRC кодом.

Флаговые последовательности 01111110 используются для разделения кадров и постоянно передаются по незанятой линии в ожидании кадра. Существуют три вида кадров: Information, Supervisory, Unnumbered. Организация поля control для этих трех видов кадров показана на рис.3.25.Как видно из размера поля Seq в окне отправителя может быть до 7 неподтвержденных кадров. Поле Next используется для посылки подтверждения вместе с передаваемым кадром. Подтверждение может быть в форме номера последнего правильно переданного кадра, а может быть в форме первого не переданного кадра. Какой вариант будет использован - это параметр.

Разряд P/F использует при работе с группой терминалов. Когда компьютер приглашает терминал к передаче, он устанавливает этот разряд в P. Все кадры, посылаемые терминалами, имеют здесь P. Если это последний кадр, посылаемый терминалом, то здесь стоит F.

Supervisory кадры имеют четыре типа кадров. Тип 0 - уведомление в ожидании следующего кадра (RECEIVE READY). Используется когда нет встречного трафика, чтобы передать уведомление в кадре с данными.

Тип 1 - негативное уведомление (REJECT) - указывает на ошибку при передаче. Поле Next указывает номер кадра, начиная с которого надо пере послать кадры.

Тип 2 - RECEIVE NOT READY. Подтверждает все кадры, кроме указанного в Next. Используется, чтобы сообщить источнику кадров о необходимости приостановить передачу в силу каких-то проблем у получателя. После устранения этих проблем получатель шлет RECEIVE REDAY, REJECT или другой надлежащий управляющий кадр.

Тип 3 - SELECTIVE REJECT - указывает на необходимость пере послать только кадр, указанный в Next. LAPB и SDLC не используют этого типа кадров.

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

Все протоколы имеют команду DISConnect - для указания о разрыве соединения. SNRM и SABM - для установки счетчиков кадров в ноль, сброса соединения с начальное состояние, установки соподчиненности на линии. Команда FRMR - указывает на повреждение управляющего кадра (например, контрольная сумма верная, а вот значения полей противоречивы).

SLIP - Serial Line IP.

SLIP - наиболее старый из этих двух протоколов. Он был создан в 1984 Rick Adams для соединения SUN рабочих станций через модем. Этот протокол был описан в RFC 1055. Этот протокол очень прост: он вставляет специальные флаг-байты в начало и конец IP пакета.

Последние версии этого протокола также осуществляют сжатие TCP и IP заголовков у последовательных пакетов, так как они несут очень много одинаковой информации. Последняя версия этого протокола описана в RFC 1144.

Этот протокол имеет ряд серьезных недостатков - он не занимается контролем и исправлением ошибок, оставляя это протоколам верхних уровней. Во вторых, он работает только с IP пакетами и не может работать ни с какими другими. В современных условиях, когда Internet объединяет самые разнообразные сети - это серьезное припятствие.

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

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

В пятых, нет стандарта на этот протокол и существует много его версий, не все из которых совместимы.