Уровень канала данных в Интернет
Протокол HDLC
Спецификации протокола высокоуровневого управления каналом (High Level Data Link Control, HDLC) описывают базовые процедуры целой группы протоколов канального уровня, используемых в сетях терминалов и на двухточечных соединениях в распределенных сетях передачи данных.
Предшественником и прототипом HDLC был протокол управления синхронным каналом (Synchronous Data Link Control Protocol, SDLC), который был предложен фирмой IBM и использовался, прежде всего для организации сетей терминалов. В свою очередь,
принятие в 1993 году ISO базовых спецификаций HDLC (ISO 3309, 4335, 7478 и т.д.) заложило прочную основу для реализации целого ряда его вариантов, управляющих передачей данных на канальном уровне в сетях с коммутацией пакетов X25 (Link Access Procedure, LAP) и в IP-сетях (PPP), в цифровых сетях с коммутацией каналов (Link Access Procedure Balanced, LAPD) и, даже, в локальных сетях (подуровень LLC в стеке IEEE 802.3).
Перечисленные протоколы имеют много общего: все содержат функции управления двухточечными и многоточечными звеньями передачи данных, обеспечивают надежную передачу в полудуплексном и дуплексном режимах связи, все являются бит–ориентированными.
Представляя передачу данных между двумя узлами как процесс обмена командами и ответами, протокол HDLC оперирует понятиями первичной, вторичной и комбинированной станций. Первичная станция управляет каналом; она имеет право посылать команды вторичным станциям и получает ответы от них; если управляемый канал является многоточечным, то первичная станция отвечает за поддержание сеанса связи с каждой из вторичных станций. Вторичная станция только отвечает на команды первичной и не выполняет функций управления каналом. Комбинированная станция может отправлять команды и ответы, а также получать их от других комбинированных станций. Подчеркнем, что все эти станции являются логическими сущностями и могут быть реализованы на одном физическом узле (рис.4.33).
 |
Существуют три логических состояния, в которых могут находиться станции, а именно, инициализации соединения, передачи данных и разъединения. В свою очередь, в состоянии передачи обмен кадрами между станциями возможен в одном из трех режимов.
1. Режим обычного ответа (Normal Response Mode, NRM) предусматривает неравноправие узлов и используется для организации взаимодействия терминалов с хост-компьютером. В этом режиме первичная станция, реализуемая на хосте, генерирует команды опроса соединенных с ней вторичных станций (терминалов); последние отвечают на запросы своими кадрами данных, но сами никогда не инициируют их передачу. В одном ответе вторичная станция может передать несколько кадров.
2. Режим асинхронного ответа (Asynchronous Response Mode, ARM) отличается от NRM тем, что вторичная станция имеет право начать передачу по собственной инициативе (обычно, в состоянии свободного канала), или по инициативе другой вторичной станции, например, в сетях кольцевой топологии. Могут передаваться один, или несколько кадров, несущих, в первом случае, информацию об изменении состояния вторичной станции, или, в кольцевых топологиях, – кадры данных. Ясно, что режимы NRM и ARM используются в несбалансированных топологических архитектурах (рис. 4.34), которые предполагают наличие определенного механизма опроса вторичных станций. Передача данных может вестись как в полудуплексном, так и в дуплексном режимах.
3. Асинхронный сбалансированный режим (Asynchronous Balance Mode, ABM) используется только комбинированными станциями и предусматривает возможность каждой из них инициировать обмен данными. Этот режим чаще всего используется в современных сетях для управления каналами двухточечных соединений между маршрутизаторами. Если физическая линия двухпроводная, то данные передаются в полудуплексном режиме, по четырехпроводной линии данные передаются в дуплексном режиме.
Формат кадра HDLC (рис.4.35) определен достаточно гибко и предоставляет возможность реализации всех перечисленных режимов передачи данных.
 |
Каждый кадр ограничивается 8-битными старт-стопными последовательностями 01111110 (флаги). Предупреждение ошибочного определения границ кадра требует исключить возможность появления в поле данных последовательности бит такой же, как и последовательность флага. Это достигается процедурой вставки нулевого бита после любой последовательности из пяти «1», встречающейся в поле данных. Приемник просматривает принимаемую последовательность битов и определяет начало кадра по последовательности из шести «1», за которой следует «0»; далее он «вычеркивает» в оставшейся части кадра любой «0», следующий за пятью единицами, восстанавливая тем самым исходную информационную последовательность. Флаговая последовательность может постоянно передаваться в промежутке между кадрами, поддерживая синхронизацию задающих генераторов взаимодействующих узлов. В этом случае, обнаружение последовательности бит, не являющейся флагом, будет свидетельствовать о начале кадра.
Кроме стартовой последовательности HDLC использует флаг (сигнал) аварийного завершения (abort), который представляется последовательностью не меньше семи и не больше четырнадцати единиц. Этот флаг может помещаться в кадр в процессе его передачи. Приемник, обнаружив сигнал аварийного завершения, отбрасывает принятую часть кадра.
Поле «Адрес» (8 бит) важно для управления передачей на многоточечных соединениях, например между хостом и несколькими терминальными устройствами, подключенными к одной физической линии. В соединениях «точка-точка» необходимость адресации кадров отсутствует, и это поле иногда используется для передачи признака «команда», «ответ». В несбалансированных режимах (NRM и ARM) в поле «Адрес» всегда указывается адрес вторичной станции; в режиме ABM – командный кадр имеет адрес получателя, а кадр ответа – адрес отправителя.
Протокол HDLC определил три типа кадров: информационный (I-кадр), управляющий (S-кадр) и ненумерованный (U-кадр). Кадры первых двух типов обеспечивают сервис надежной передачи (с предварительным установлением соединения и подтверждением доставки); ненумерованные кадры используются для передачи команд и ответов в фазах установления и ликвидации соединений, а также для передачи данных в режиме без установления соединения и без подтверждений. Структура управляющего поля для кадров разных типов представлена на рис. 4.36.
Информационный кадр в первом бите управляющего поля содержит «0»; «10» в первых двух битах этого поля определяют кадр управления и «11» в этих же битах указывают, что это ненумерованный кадр.
 |
Во всех типах кадров поле "Управление" содержит бит P/F (Poll/Final). В несбалансированных режимах (NRM, ARM) первичная станция, отсылая кадр с установленным в «1» битом P/F, предлагает терминалу ответить; последний во всех кадрах своего ответа (их может быть несколько) этот бит устанавливает в «0», а в последнем кадре – в «1». В сбалансированном режиме (ABM) «1» в этом поле используется для передачи «приказа» другой машине немедленно, т.е. не ожидая «попутного» информационного кадра, отправить управляющий кадр (это может быть использовано механизмом ARQ).
Исправление ошибок протокол HDLC реализует посредством алгоритмов ARQ, а управление потоком - посредством механизма скользящего окна. Поле N(S) в информационном кадре предназначено для записи порядкового номера отправляемого кадра ( 
в процедурах ARQ); поле N(R) в информационном и управляющем кадрах предназначено для записи номера следующего кадра, "ожидаемого" приемником ( 
). В базовом варианте спецификации протокола для полей N(S) и N(R) отведено по 3 бита; это ограничивает максимальный размер окна передачи для ARQ с возвратом на N значением 
, а для ARQ с выборочным повторением - 
. В более позднем варианте протокола поле «Управление» расширено до 16 бит, а поле порядкового номера - до 7 бит. Соответственно, окно передачи 
может принимать значения от 0 до 127 или до 63.
Биты SS (поле «Type») управляющего кадра используются для передачи следующих служебных сообщений:
| SS = 00 | К приему готов (Receive ready, RR); используется как сообщение АСК на кадр с номером N(R)-1. |
| SS = 01 | Кадр отброшен (Reject, REJ), соответствует сообщению NAK; уведомляет отправителя о наличии ошибки в очередном принятом кадре и необходимости повторения передачи всех кадров, начиная с кадра N(R); (Go-To- Back N). |
| SS = 10 | К приему не готов (Receive not ready, RNR). Этим сообщением подтверждается прием всех кадров с номерами до N(R)-1 и получатель сообщения информируется о возникновении временных проблем (нет свободного буферного пространства, например). Это сообщение может использоваться для управления потоком. |
| SS = 11 | Выборочное уничтожение кадра (Selective reject, SREJ). Этим сообщением указывается, что кадр с номером N(R) отброшен (не получен) и должен быть передан повторно. Используется процедурой ARQ с выборочным повторением. |
Ненумерованные кадры используются, прежде всего, для установления и ликвидации соединения. Например, сообщения SNRM (Set NRM) и SABM (Set ABM) используются отправителем для согласования желаемого режима (нормального ответа, асинхронный балансный) информационного обмена; сообщения SNRME и SABME указывают на использование расширенного формата поля «Управление»; для подтверждение приема ненумерованного кадра используется сообщение UA (Unnumbered Acknowledgement), а об отбрасывании такого кадра извещается сообщением FRMR(Frame Reject). Для индикации необходимости разъединения используется ненумерованный кадр DISC(Disconnect). Для различения этих и ряда других сообщений, представляемых ненумерованными кадрами, зарезервированы пять бит (биты M на рис. 4.36), что позволяет определить 32 вида различных команд/ответов; реально используется значительно меньшее их число. Ненумерованные кадры также используются для передачи протокольных блоков сетевой службы, не требующей сервиса надежной передачи.
Размер поля «Данные» не определен, но обычно оно имеет некоторое максимально допустимое значение, задаваемое одной из конфигурационных переменных.
16- или 32-битное поле FCS (Frame Checking Sequence) содержит контрольные биты, вычисленные посредством алгоритма CRC, и защищает как заголовок, так и поле данных.
Рисунок 4.37 представляет схему обмена кадрами в фазах установления–ликвидации соединения, а рис. 4.38. – обмен кадров в фазе передачи данных в асинхронном сбалансированном режиме и при дуплексном режиме связи.
Станция A направляет ненумерованный кадр SABM, сообщая им станции В, что она желает установить соединение в асинхронном сбалансированном режиме (подразумевает двунаправленный обмен). Станция В кадром UA подтверждает установление соединения. Поскольку кадры управления никогда не передаются "пачками", то необходимости нумерации их не возникает. Далее осуществляется передача данных (последовательности кадров) и по инициативе станции В, направившей кадр DISC, соединение, после получения подтверждения UA, ликвидируется.
В фазе передачи данных используются I-кадры, которые всегда являются командами, поскольку они требуют подтверждения приема, и управляющие кадры (RR и RNR) которые могут быть и командами и ответами, а кадр REJ– всегда является ответом. При этом, поле «Адрес» в команде содержит адрес получателя, а в ответе – адрес отправителя.
Обратим внимание на отсутствие в структуре заголовка кадра HDLC поля, идентифицирующего протокол 3-го уровня, которому предназначается размещенная в поле «Данные» информация. Исходная спецификация предполагает, что на станциях работает лишь один такой протокол и вопроса «Кому передать поле данных» не возникат в принципе. Вместе с тем, это конечно, заметное ограничение возможностей HDLC. В ряде фирменных его реализаций (например, Cisco) поле «Протокол» введено в явном виде за счет сокращения поля Данные»; существует оно и в протоколах семейства HDLC, например, в протоколе PPP.
Уровень канала данных в Интернет
Здесь будут рассмотрены протоколы, используемые для управления передачей данных по каналам «точка-точка» в Интернет. Такие соединения создаются между узлами коммутации трафика в сети (маршрутизаторами); необходимы они и для подключения домашнего ПК к узлу сервис-провайдера. Во всех этих случаях требуется протокол, который бы занимался формированием кадров, проверкой корректности их передачи и другими задачами, решаемыми на канальном уровне. Нередко, в составе канального протокола реализуется еще целый ряд контрольных и управляющих функций. В настоящее время основным канальным протоколом Интернет является Point-to-Point Protocol (РРР), который может работать, используя сервис физических протоколов как асинхронных так и синхронных полнодуплексных линий передачи. Его предшественником был протокол SLIP (Serial Line Internet Protocol).
Протокол SLIP
Serial Line Internet Protocol был создан в 1984 Р. Адамсом (Rick Adams) для соединения рабочих станций SUN посредством аналоговых линий связи. Этот протокол был описан в RFC 1055. Он очень прост - вставляет специальные флаг-байты в начало и в конец IP пакета. Последние версии этого протокола также осуществляли сжатие TCP и IP заголовков у последовательных пакетов, так как они несут очень много одинаковой информации. Этот протокол имеет ряд серьезных недостатков.
· Он не контролирует правильность передачи данных, оставляя это протоколам верхних уровней;
· Он работает только с IP пакетами; в условиях, когда Internet объединяет самые разнообразные сети, это становится серьезным ограничением;
· Протокол не выполняет аутентификацию взаимодействующих устройств;
· Он плохо стандартизирован и не все его версии совместимы.
С целью преодоления этих недостатков комитетом IETF (Internet Engineering Task Force) был разработан Point-to-Point Protocol (РРР), описанный в RFC 1661, 1662,1663 и еще в целом ряде (более 40) других документов.
PPP-протокол
Point-to-Point Protocol осуществляет инкапсуляцию пакетов сетевого протокола в кадры канального уровня и их передачу по двухточечному соединению, которое может работать как в асинхронном, так и в синхронном режиме передачи. Кроме формирования кадров и обнаружение в них ошибок протокол РРР выполняет еще:
· конфигурирование и тестирование соединений канального уровня (группа процедур Link Control Protocol, LCP),
· передачу конфигурационных параметров протоколов сетевого уровня (группа процедур Network Control Protocol, NCP).
Вместе с тем, выполняя широкий набор сервисных и управляющих процедур (LCP и NCP), протокол PPP не содержит механизмов реализации сервиса надежной доставки кадров.
Структура кадра РРР (рис.4.39) является производной от структуры кадра HDLC. Кадр всегда начинается и заканчивается стандартными HDLC-флагами. Однако, PPP, в отличие от HDLC, является байт-ориентированным и поле данных кадра выравнивается по границам байта посредством битов заполнения. Для предотвращения ошибочного определения границ кадра в случае появления флагового символа в поле данных, перед ним добавляется специальный символ (ESC-последовательность), размер которого равен 1 байту и шестая единица в информационном символе инвертируется; когда приемник встречает такой ESC-символ, то в следующем за ним байте шестой бит инвертируется.
 | |||
|
Поле адреса, обычно, содержит все «1», что означает широковещательный адрес (но в соединении участвует лишь два узла и это проблем не вызывает).
Поле управления заполняется последовательностью 11000000, т.е. содержит указание на использование ненумерованных кадров HDLC. Соответственно, надежная передача кадров не гарантируется (протокол IP и не требует ее). Вместе с тем, на зашумленных каналах существует возможность организации управляемого по правилам HDLC соединения (RFC 1663). В этом случае поля «Адрес» и «Управление» интерпретируются по правилам HDLC, а установление и разрыв соединения реализуются специальными сигналами на физическом уровне стека.
Поскольку РРР часто используется для связи маршрутизаторов, а последние обычно являются мультипротокольными, то потребовалось поле «Протокол», в котором указывается код сетевого протокола (IP, IPX и т.д.), модулю которого необходимо передать поле данных кадра.
Для генерации битов CRC используются полиномиальные коды CCITT-16 или CCITT-32.
В поле данных PPP-кадра может быть вложен пакет сетевого уровня, одно LCP-, или NCP-собщение. В двух последних случаях в поле «Протокол» указываются соответствующие коды, - LCP (0xC021) и NCP (0x8021). Процедуры LCP решают задачи конфигурирования канала связи между узлами, его тестирования и ликвидации. В таблице 4.6 приведены некоторые из описанных в документе RFC 1661 LCP-кадров. В колонке «Направление передачи» символом «И» обозначен инициатор соединения, а символом «О» - ответчик. Также отметим, что команды, названия которых содержат Echo и Discard, используются для тестирования линий.
Таблица 4.6
| № п/п | Название кадра | Направление передачи | Описание |
| Configure-Request | И à О | Список предлагаемых параметров соединения | |
| Configure-ACK | И ß О | Согласие с предлагаемыми параметрами соединения | |
| Configure-NAC | И ß О | Отказ от предлагаемых параметров соединения | |
| Configure-Reject | И ß О | Параметры соединения не согласуемы | |
| Terminate- Request | И à О | Запрос разрыва соединения | |
| Terminate- ACK | И ß О | Согласие с разрывом соединения | |
| Code-Reject | И ß О | Получен неизвестный запрос | |
| Protocol- Reject | И ß О | Запрашивается неизвестный протокол | |
| Echo- Request | И à О | Просьба отослать этот же кадр назад | |
| Echo-Replay | И ß О | Это возвращаемый кадр | |
| Discard-Request | И à О | Указание уничтожить кадр |
Для установления логического соединение "точка-точка" по протоколу PPP, оба участника сначала посылают кадры LCP, чтобы сконфигурировать и протестировать канал. Далее, одноранговые объекты могут быть подвергнуты взаимной аутентификации. При ее положительном результате PPP посылает кадры NCP для выбора и конфигурирования протокола сетевого уровня. После успешного завершения этой фазы, пакеты протокола сетевого уровня могут приниматься и пересылаться по логическому каналу в виде кадров PPP. Канал будет оставаться сконфигурированным для связи до тех пор, пока специальные кадры LCP или NCP явно не закроют его, или пока не произойдет некоторое внешнее событие (срабатывание таймера неактивности, вмешательство администратора).
Работа протокола РРР при подключении ПК по модемному соединению к узлу доступа провайдера IP-сети иллюстрируется рис. 4.40. Установление логического канала производится по сценарию, приведенному на рис. 4.37; в этой фазе узлы обмениваются сообщениями процедур LCP; затем реализуется этап аутентификации пользователя в соответствии с выбранным в фазе установления соединения протоколом аутентификации - Password Authentication Protocol (PAP), или Challenge-Handshake Authentication Protocol (CHAP). При успешном завершении фазы аутентификации управление передается NCP-процедурам. Задачи, решаемые ими, зависят от типа сетевого протокола. В частности, когда ПК подключается к IP-сети, именно NCP обеспечивает присвоение персональному компьютеру IP-адреса и конфигурацию его IP-стека.
 |
Протокол PPP способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно для увеличения пропускной способности соединения за счет организации нескольких параллельных каналов (MP - MultiLink Protocol).
Итак, PPP входит в семейство HDLC-протоколов и обеспечивает управление передачей данных по асинхронным и синхронным каналам связи. Он выполняет согласование параметров соединения, обнаружение ошибок, а также, при необходимости, и стандартные для HDLC процедуры ARQ и управления потоком (RFC 1663).
Дальнейшим развитием этого протокола стал PPPoE (Point-to-Point Protocol over Ethernet). Вследствие широкого использования технологии Ethernet для подключения индивидуальных пользователей к Интернет (рис. 4.41) стали актуальными задачи управления такими соединениями, в том числе, задачи аутентификации, конфигурирования сетевого стека пользовательского компьютера, подсчета объема трафика. Механизмами Ethernet эти задачи не решаются, в то время, как PPP содержит процедуры установления соединения на канальном уровне и процедуры конфигурирования сетевых соединений. Таким образом, PPPoE, являясь протоколом туннелирования для PPP, предоставляет дополнительные (в сравнении с Ethernet) сервисы (аутентификация, сжатие данных, шифрование, назначение сетевого адреса).
 |
Кадр PPPoE размещается в поле данных кадра Ethernet и имеет формат, представленный на рис. 4.42. Поле «Версия» имеет значение 1; 4-битовое поле «Тип» также имет значение 0x1 для данной версии спецификации PPPoE.
 | |||
|
Значения 8-битового поле «Код» определяется конкретными этапами функционирования протокола PPPoE. Существуют две стадии работы протокола – стадия обнаружения сервера соединений (создания сессии) и стадия собственно PPP (рис.4.43). Стадия создания сессии реализуется по модели «клиент-сервер» посредством обмена сообщениями, каждое из которых идентифицируется полем «Код». PPPoE-клиент инициирует поиск PPPoE-сервера посредством широковещательной рассылки Ethernet-кадра с протокольным кодом 0x8863; в поле данных этого кадра помещается специальный запрос PADI (Active Discovery Initiation) протокола PPPoE, который идентифицируется значением 0x09 в поле «Код» заголовка PPPoE. Все PPPoE-серверы, получающие этот широковещательный запрос, отвечают кадром PADO (Active Discovery Offer, значение кода 0x07), предлагая свои «услуги». Клиент получает эти ответы, содержащие адрес отправившего их сервера, и выбирает какой-то один для дальнейшей работы. Свой выбор он подтверждает запросом PADR (Active Discovery Request код 0x19) к выбранному серверу. Согласие на установление сессии этот сервер заявляет кадром PADS (Active Discovery Session-confirmation, код 0x65), в котором отправляет и уникальный идентификатор сессии – 16-битное число; этот код будет включаться в заголовок PPPoE всех кадров, отправляемые между клиентом и сервером. Тем самым, появляется возможность уникально идентифицировать весь обмен между конкретными устройствами, подключенными к широковещательной совместно используемой многими станциями среде.
Установление PPPoE-соединения продолжается типичными для PPP процедурами: согласованием параметров линии, например, максимально допустимого размера поля данных (MTU), типа аутентификации и тому подобного. В фазе аутентификации PPPoE-сервер средствами протокола PPP запрашивает логин и пароль пользователя и отправляет их серверу AAA (Authentication, Authorization, Accounting) для проверки и определения полномочий пользователя. Далее реализуются процедуры предусмотренные протоколом PPP для контроля и управления соединением по двухточечной линии.
 |
Пример структуры заголовка кадров PPP-over-Ethernet и значений некоторых его полей представлена ниже. Факт инкапсуляции в Ethernet-фрейм кадра PPPoE указывается значением в поле Protocol заголовка Ethernet соответствующего кода (0х8863 на этапе установления соединения или 0х8864 - при передаче данных. Данные, необходимые для установления соединения (идентификаторы узлов, имя сервиса, имя PPPoE-сервера и т.п.), представляются структурой «метка» («тег»), формата "тип, размер, значение", занимающие, соответственно, 2 байта, 2 байта, сколько надо.
Ethernet Header
SrcAdr: 00:50:da:42:d7:df,
DstAdr: ff:ff:ff:ff:ff:ff
Protocol: 0x8863 (Discovery Stage) или 0x8864 (PPP Session Stage).
PPoE Header
Version (4b): 1
Type (4b): 1
Code (8b): Active Discovery Initiation (0x09)
Session ID (16b): 0000
Payload Length (16b): 24
PPoE Payload
(Discovery Stage)
PPPoE Tags
TagType: Service-Name {других ее параметров нет}
TagType: Host-Uniq (16 b)
TagLenght: (Binary Data, 16 b) - {размер поля TagValue в байтах}
TagValue: 11000111 01011100
(PPP Session Stage)
PPP PROTOCOL-ID = 0xc021 (2 bytes) - код IP-протокола
PPP payload (<= 1492 bytes)
Метка "Service-Name" может содержать имя поставщика сервиса, или требуемый класс обслуживания. Если значение TagLenght для этой метки равно нулю, то это означает приемлемость любого вида сервиса. Метка "Host-Uniq" задается хостом для уникальности ассоциации ответов сервера соединения на его запросы (PADO c PADI). Поле "TAG VALUE" в этом случае может содержать любую последовательность бит, заданную хостом; сервер соединений просто копирует ее в свои ответы.
Заметим, что MTU для кадра PPPoE составляет 1492 байта, в отличие от 1500 байт, характерных для Ethernet. «Потерянные» 8 байт использованы для: 6 байт - заголовок PPPoE и 2 байта - поле Протокол из заголовка PPP (в этом случае, поля «Адрес» и «Управление» из заголовка РРР не используются).
Заключение
· Придание физическому каналу между двумя узлами сети свойств надежной системы доставки информации является основной задачей протоколов канального уровня.
· Канальные протоколы выполняют следующие процедуры:
§ формирование кадров, т.е. указание границ и контроль допустимых размеров
§ обеспечение кадров адресной информацией,
§ обнаружение ошибок и восстановление поврежденных кадров,
§ управление интенсивностью генерации кадров с учетом возможности их обработки получателем.
· Во многих сетевых технологиях канальные протоколы являются вариантом бит-ориентированного протокола HDLC.
o В таких протоколах используются флаговые байты (01111110) для указания границ кадра.
o Вставка нулевых битов, или ESC-символов, в информационные последовательности предотвращает ошибки при определении границ кадра.
o Для управления потоком используется механизм скользящего окна.
· Канальным протоколом в Интернет является протокол PPP, представляющий собой один их вариантов протокола HDLC, оперирующий ненумерованными кадрами.