21. Протоколы канала данный.

 

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 адрес динамически лишь на этапе установки соединения. В четвертых, этот протокол не обеспечивает какой-либо проверки аутентичности взаимодействующих сторон. Так что вы не можете быть уверено с кем вы общаетесь. В пятых, нет стандарта на этот протокол и существует много его версий, не все из которых совместимы. PPP - протокол точка-точка Чтобы исправить это положение IETF (Internet Engineering Task Force) создало группу, которой было поручено разработать новый протокол. В результате ее усилий появился протокол РРР (Point-to-Point Protocol), определенный в RFC 1661, 1662,1663. РРР обеспечивает обнаружение ошибок, поддерживает разные протоколы, позволяет динамически выделять IP адрес только на период соединения, выполняет аутентификацию абонентов и имеет ряд других преимуществ перед SLIP. РРР обеспечивает три протокола: · Распознавание кадров, т.е. однозначно определяет начало нового и конец кадра. Здесь же происходит обнаружение ошибок. · Протокол управления линией, т.е. активизация линии, ее проверка, определение основных параметров передачи в диалоге, корректное завершение передачи со сбросом параметров. Этот протокол называет LCP( Link Control Protocol). · Протокол для определения основных параметров между сетевыми уровнями, который обеспечивает независимость от реализации сетевого уровня. Выбранный метод предполагает наличие разных NCP (Network Control Protocol) на каждом поддерживаемом сетевом уровне. Для того, чтобы лучше понять как это все работает вместе давайте рассмотрим типичный сценарий когда пользователь из дома по телефонной линии хочет подключить свой РС к Internet. РС звонит на маршрутизатор сервис провайдера. После того, как маршрутизатор принял звонок и установил физическое соединение, РС посылает несколько LCP пакетов в РРР кадрах. Маршрутизатор отвечает LCP пакетами в РРР кадрах. В результате такого обмена определяются параметры соединения. После этого следует обмен NCP пакетами для конфигурирования сетевого уровня. В частности здесь происходит временное присваивание РС IP адреса, который действует только на период соединения. Это происходит если обе стороны хотят использовать TCP/IP стек. Теперь когда РС стала полноправной машине в Internet она может обмениваться IP пакетами с другими машинами. Когда пользователь закончит работу, NCP разрывает соединение с сетевым уровнем и освобождает ранее занятый IP адрес. После этого LCP протокол разрывает соединение на канальном уровне. А затем компьютер говорит модему "Положи трубку". РРР кадры имеют формат очень близкий к HDLC кадрам. Основное различие в том, что РРР байт ориентированный, а HDLC - бит ориентированный. Для РРР не возможен кадр в 30,25 байт, а у HDLC такое может быть. РРР кадр показан на рис. 3.27. Все РРР кадры начинаются со стандартного 01111110 байта. Поле Адрес также по умолчанию равно 11111111. Поле Control по умолчанию равно 00000011, что означает - Unnumbered кадр, т.е. не предполагается нумерации передаваемых кадров и подтверждений в их получении. В случае ненадежной среды передачи данных есть вариант надежной передачи, описанный в RFC 1663/ Так как поля Address и Control - константы, то LCP протокол опускает их, экономя два байта на передаче. В поле Protocol указывается какой тип пакетов будет в поле Payload. Там допускаются LCP, NCP, IP, IPX, Apple Talk и другие. Поле Payload имеет переменную длину, по умолчанию она равна 1600 байт.