3. Канальный уровень 
В этой главе рассматриваются алгоритмы надежной и эффективной передачи данных между двумя соседними машинами. Под словом ?соседние? мы понимаем то, что эти машины физически соединены проводом. Под проводом мы будем понимать любую физическую среду передачи данных, для которой справедливо, что биты поступают получателю точно в той последовательности, в какой их послал отправитель. Эта, простая, на первый взгляд, задача при детальном рассмотрении оказывается весьма сложной, если учесть, что при передаче по каналу могут возникать ошибки, возникают задержки, которые могут вызывать дублирование данных, и т.д. 

3.1. Проблемы, решаемые на уровне канала данных 
На уровне канала данных решается ряд проблем, присущих только этому уровню: реализация сервиса для сетевого уровня, объединение битов, поступающих с физического уровня в кадры, обработка ошибок передачи, управление потоком кадров и другие. 
Основная задача канального уровня - обеспечить сервис сетевому уровню по передаче и приему данных. Назначение этого сервиса - передать данные от процесса на сетевом уровне одной машины процессу на сетевой уровень другой машины. Как это происходит, показано на рисунке 3-1 (а). Фактически процесс передачи сложнее, что проиллюстрировано на рисунке 3-1 (b). Однако для простоты изложения мы будем придерживаться первой схемы. 
Рисунок 3-1. Передача данных - виртуальная (a), фактическая (b) 

Канальный уровень может обеспечивать различный сервис. Хотя этот сервис может варьироваться от системы к системе, есть три общих видов сервиса: 
1.Сервис без уведомления и без соединения 
2.Сервис с уведомлением и без соединения 
3.Сервис с уведомлением и с соединением 
Сервис без уведомления и без соединения не предполагает, что до начала передачи должно быть установлено соединение, которое после передачи должно быть разорвано, что факт приема переданного кадра должен подтверждаться специальным сообщением. Если в результате помех на физическом уровне кадр будет потерян, то никаких попыток его восстановить на канальном уровне произведено не будет. Этот класс сервиса используется там, где физический уровень обеспечивает настолько высокую надежность при передаче, что потери кадров происходят редко и восстановление при потере кадров можно переложить на верхние уровни. Этот вид сервиса также применяют при передаче данных в реальном времени там, где лучше потерять часть данных, чем увеличить задержку при их доставке. Например, передача речи, видео изображения. Большинство ЛВС использует этот вид сервиса на канальном уровне. 
Следующий вид сервиса - сервис с уведомлением без соединения. В этом виде сервиса получение каждого посланного кадра должно быть подтверждено. Если подтверждения не пришло в течение определенного промежутка времени, то считают, что кадр не принят и должен быть послан опять. Этот вид сервиса используется в ненадежной физической среде передачи, например, беспроводной. 
Можно было бы, конечно, подтверждать не кадры, а все сообщение целиком на сетевом уровне. Однако это было бы невыгодно для больших сообщений. Например, если при передаче этих данных разрушалось бы 10-20% кадров, то повторная передача таких сообщений заняла бы больше времени, чем передача их отдельных фрагментов. Поэтому подтверждение на канальном уровне следует рассматривать как минимизацию затрат на передачу данных, а не необходимость. 
Наиболее сложный класс сервиса на канальном уровне - сервис с соединением и уведомлением. Этот класс сервиса предполагает, что до начала передачи между машинами устанавливают соединение и данные передают по этому соединению. Каждый передаваемый кадр нумеруется, и канальный уровень гарантирует, что он будет обязательно получен, причем только один раз, а также что все кадры будут получены в надлежащей последовательности. При сервисе без соединения этого гарантировать нельзя, потому что потеря подтверждения получения кадра приведет к его пересылке, что, в свою очередь, приведет к появлению нескольких идентичных кадров. Использование сервиса с соединением особенно полезно в том случае, когда канал образует СПД. Как мы уже видели, в СПД может быть достаточно сложная организация канала, при которой может происходить коммутация потоков данных самыми разными способами. Здесь полезно вспомнить структуру кадра в Х.25, рассмотренную в разделе 2.3. С точки зрения структуры, в Х.25 есть три вида кадров: с 3-битовым полем номера кадра, 7- и 12-битовым. Таким образом, в Х.25 предусмотрен сервис с соединением, причем, в зависимости от длины передаваемых данных, можно оптимизировать затраты на поддержку соединения. 
При сервисе с соединением и уведомлением передача данных разбивается на три этапа. На первом этапе устанавливают соединение: на обеих машинах инициируют переменные и счетчики, отслеживающие, кадры с какими номерами были приняты, а с какими нет. На втором этапе передают нужные кадры. На третьем - соединение разрывают: переменные, счетчики, буферы и другие ресурсы, использованные для поддержки соединения, освобождают. 
На рисунке 3-2 показан типичный фрагмент WAN, где два маршрутизатора соединены через телефонную линию. Когда кадр поступает на маршрутизатор, аппаратура проверяет контрольную сумму и передает кадр канальному уровню. Канальный уровень проверяет, является ли поступивший кадр ожидаемым, и если да, то передает пакет, расположенный в кадре, сетевому уровню на другой машине. 
Рисунок 3-2. Размещение протокола канального уровня 

Сервис, создаваемый канальным уровнем для сетевого уровня, опирается на сервис, создаваемый физическим уровнем. На физическом уровне принимают и передают потоки битов. Отправленное количество битов не обязательно должно быть равно принятому количеству битов, значение посланного бита также не обязательно должно быть равно принятому значению бита. Поэтому на канальном уровне нужны специальные действия по обнаружению и исправлению таких ошибок. 
Типовой подход к решению подобных проблем - разбиение потока битов на кадры, подсчет контрольной суммы для каждого кадра и передача этой суммы вместе с кадром данных. При приеме контрольная сумма вычисляется для каждого кадра заново и сравнивается с той, что хранится в кадре. Если они различаются, то это признак ошибки передачи. На канальном уровне должны быть приняты меры к исправлению ошибки, например, сбросить плохой кадр и послать сообщение об ошибке тому, кто прислал этот кадр. 
Разбиение потока битов на кадры - задача не простая. Один из способов - делать паузу между битами разных кадров. Однако в сети, где нет единого таймера, нет гарантии, что эта пауза всегда будет одинаковой, или, наоборот, не появится новая пауза там, где ее не должно было быть. 
Так как методы, использующие временные задержки, не надежны, применяются другие методы. Здесь мы рассмотрим четыре основных метода: 
1.счетчик символов 
2.вставка специальных стартовых и конечных символов 
3.вставка стартовых и концевых битов 
4.нарушение кодировки на физическом уровне 
Первый метод показан на рисунке 3-3. В начале каждого кадра указывают, сколько символов в кадре. При приеме кадра вновь подсчитывают число принятых символов. Если число полученных символов отлично от ожидаемого числа, то этот факт воспринимают как ошибку. Однако этот метод имеет существенный недостаток: счетчик символов может быть искажен при передаче. Тогда принимающая сторона не сможет обнаружить границы кадра. Даже обнаружив несовпадение контрольных сумм, принимающая сторона не сможет сообщить передающей, какой кадр надо переслать и сколько символов пропало. Этот метод сейчас используется редко. 
Рисунок 3-3. Поток символов: (а) без ошибок; (b) с одной ошибкой 

Второй метод построен на вставке специальных символов. Обычно для этого используют последовательность символов DLE STX для начала кадра и DLE ETX для конца кадра. DLE (Data Link Escape), STX (Start TeXt), ETX (End TeXt) - это специальные символы, имеющие специальную кодировку. При этом методе, если даже была потеряна граница текущего кадра, нужно просто найти ближайшую последовательность DLE STX или DLE ETX. Однако здесь есть одна опасность: при передаче чисел или программы в объектном коде такие последовательности могут уже содержаться в передаваемых данных. Для решения этой проблемы используют прием экранирования: каждая последовательность DLE или STX просто дублируется в передаваемых данных. Поэтому, если при приеме есть два последовательных DLE, то один удаляется. Этот метод проиллюстрирован на рисунке 3-4. 
Рисунок 3-4. Метод экранирования 

Основным недостатком только что рассмотренного метода является то, что он жестко связан с размером байта и конкретным методом кодировки символов - ASCII. По мере развития сетей эта связь становилась все более и более обременительной. Кроме этого, на стороне отправителя надо было просматривать кадр, чтобы обнаружить недопустимые последовательности. 
Был предложен иной прием, позволяющий использовать любое число битов на символ и любую кодировку. Его идея состоит в том, что каждый кадр начинается и заканчивается специальным флаг-байтом: 01111110. Чтобы избежать аналогичной последовательности, внутри кадра поступают следующим образом. Посылающая сторона, встретив последовательно 5 единиц, обязательно вставит 0. Принимающая сторона, приняв 5 последовательных единиц, обязательно удалит следующий за ними 0. Таким образом, если в передаваемых данных встретится конфигурация флаг-байта, то она будет преобразована в конфигурацию 011111010. Этот метод иллюстрирует рисунок 3-5. Этот метод прозрачен для сетевого уровня так же, как и метод вставки байтов. 
Рисунок 3-5. Замена шестой единицы нулем 

Таким образом, кадр легко может быть распознан по флаг-байту. Если граница очередного кадра по какой-то причине была потеряна, то все что надо делать - ?ловить? ближайший флаг-байт. 
Последний метод - нарушение кодировки используется там, где применяется специальная кодировка битов на физическом уровне. Например, пусть для передачи одного бита используется два импульса. ?1? кодируется как переход ?высокое-низкое?, ?0? - как переход ?низкое-высокое?. Сочетания ?низкое-низкое? или ?высокое-высокое? не используются для передачи данных. Их и используют для границ кадра. Так делают в стандарте IEEE 802 для ЛВС, который мы рассмотрим позже. 
На практике используют, как правило, комбинацию этих методов. Например, счетчик символов с одним из выше перечисленных. Тогда, если число символов в кадре совпадает с кодировкой границы кадра, кадр считается переданным правильно. 
3.1.3. Обнаружение ошибок 
Решив проблему разбиения на кадры, мы приходим к следующей проблеме: как обеспечить, чтобы кадры попадали на сетевой уровень в надлежащей последовательности? Если для отправляющей стороны все равно, в какой последовательности поступают кадры, то этой проблемы нет. Например, если нам нужен сервис без уведомления и без соединения. Однако как быть, если нам нужен сервис с уведомлением и с соединением? 
Для решения этой проблемы устанавливают обратную связь между отправителем и получателем в виде кадра подтверждения. Если кадр-подтверждение несет положительную информацию, то считается, что переданные кадры прошли нормально, если же в нем сообщение об ошибке, то переданные кадры надо передать заново. 
Однако возможны ситуации, когда из-за ошибок в канале кадр исчезнет целиком. В этом случае получатель не будет никак реагировать, а отправитель будет сколь угодно долго ждать подтверждения. Для решения этой проблемы на канальном уровне вводят таймеры. Когда передается очередной кадр, то одновременно устанавливается таймер на определенное время. Этого времени должно хватать на то, чтобы получатель получил кадр и отправил уведомление, а отправитель получил его. 
Если отправитель не получит уведомление раньше, чем истечет время, установленное на таймере, то он будет считать, что кадр потерян и повторит его еще раз. 
Однако если кадр-подтверждение был утерян, то вполне возможно, что один и тот же кадр получатель получит дважды. Как быть? Для решения этой проблемы каждому кадру присваивают порядковый номер. С помощью этого номера получатель может обнаружить дубли. 
Итак, таймеры и нумерация кадров - основные средства на канальном уровне, обеспечивающие доставку каждого кадра до сетевого уровня в единственном экземпляре и в нужном порядке. 
3.1.4. Управление потоком 
Другая важная проблема, которую надо решать на канальном уровне - управление потоком. Вполне может случиться, что отправитель будет посылать кадры столь часто, что получатель не будет успевать их обрабатывать. Это может произойти, если, например, машина-отправитель более мощная или загружена слабее, чем машина-получатель. 
Для борьбы с такими ситуациями вводят специальный механизм управления потоком. Этот механизм предполагает обратную связь между отправителем и получателем, которая позволяет им урегулировать темп передачи. 
Существует много схем управления потоком, но все они в основе своей используют следующий сценарий. Прежде чем отправитель начнет передачу, он спрашивает у получателя, сколько кадров тот может принять. Получатель сообщает ему определенное число. Отправитель, после того как передаст это число кадров, должен приостановить передачу и спросить у получателя еще раз, сколько кадров тот может принять, и т.д. Позднее на примерах мы познакомимся с конкретными механизмами управления потоком. 
3.2. Обнаружение и исправление ошибок 
При рассмотрении физической среды мы отмечали, что у беспроводных систем связи и аналоговых каналов, например, абонентской линии в телефонных сетях, достаточно высокий уровень ошибок в канале. Поэтому ошибки при передаче на физическом уровне - это реальность, которую надо обязательно учитывать. 
В разных средах характер ошибок разный. Ошибки могут быть одиночные, а могут возникать группами, сразу по несколько штук. У групповых ошибок есть свои достоинства и недостатки. Достоинство заключается в следующем. Пусть данные передаются блоками по 1000 бит, а частота ошибки - 10-3 на бит, т.е. одна на каждые 1000 бит. 
Если ошибки изолированные и независимые, то практически каждый блок в среднем будет содержать ошибку. Если же они возникают группами по 100 сразу, то ошибки будут содержать в среднем 1-2 блока из каждых 100. Недостатком групповых ошибок является то, что их труднее обнаруживать и исправлять, чем одиночные. 
3.2.1. Коды с исправлением ошибок 
Для надежной передачи кодов было предложено два основных метода. Первый - внести избыточность в форме дополнительных битов в передаваемый блок данных так, чтобы, анализируя полученный блок, можно было бы указать, где возникли искажения. Это так называемые коды с исправлением ошибок. Второй метод - внести избыточность, но лишь настолько, чтобы, анализируя полученные данные, можно было сказать: есть в переданном блоке ошибки или нет. Это так называемые коды с обнаружением ошибок. 
Пусть данные занимают m разрядов, и мы добавляем r избыточных, контрольных разрядов. Нам необходимо передать слово длины n = m+r, которое называют n-битовым кодословом. Пусть у нас есть два кодослова - 10001001 и 10110001. С помощью операции EXCLUSIVE OR легко определить число различных разрядов в двух кодословах. В данном случае таких разрядов 3. Количество разных битов в двух кодословах называется расстоянием Хемминга между этими словами. Поэтому, если два кодослова находятся на расстоянии d по Хеммингу, это значит, что надо преобразовать ровно d разрядов, чтобы преобразовать одно кодослово в другое. 
В силу того, что избыточные контрольные разряды могут принимать только вполне определенные значения, то не все 2n кодовых слов возможны. Зная алгоритм установки контрольных разрядов, мы можем вычислить   минимальное расстояние по Хеммингу между двумя правильными кодословами.      
Способен код исправлять ошибки или только обнаруживать их - зависит от расстояния между кодословами по Хеммингу. Если мы хотим обнаруживать d ошибок, то необходимо, чтобы два кодослова отстояли друг от друга на расстоянии d+1. Тогда, если принятый код отстоит на расстоянии k<d, то принятое кодослово содержит k ошибок. Если мы хотим исправлять d ошибок, то нужно, чтобы кодослова отстояли друг от друга на 2d+1. Поэтому, даже если переданное кодослово содержит d ошибок, оно все равно ближе к правильному кодослову, чем к какому-либо еще, и, таким образом, можно определить исходное слово. 
Простым примером кода с обнаружением одной ошибки является код с битом четности. Конструкция его такова: к исходному кодослову добавляется бит четности. Если число единиц в исходном кодослове четно, то значение этого бита - 0. Если нечетно, то - 1. Кодослова с битом четности имеют расстояние Хемминга 2, так как любая ошибка в одном бите породит ошибку четности. Однако, если возможны двойные ошибки, то бит четности проблему не решит. 
Для примера кода с исправлением ошибки рассмотрим код, у которого есть только четыре правильных кодослова: 0000000000, 0000011111, 1111100000, 1111111111. Расстояние по Хеммингу у этого кода 5, следовательно, он может исправлять двойные ошибки. Если получатель получит слово 0000000111, то ясно, что исходное слово имело вид 0000011111. Однако, если допустимы тройные ошибки, то 0000000111 может означать 0000000000. 
Оценим минимальное количество контрольных разрядов, необходимое для исправления одиночных ошибок. Пусть у нас есть код из m бит сообщения и r контрольных бит. Каждое из 2n правильных сообщений имеет n неправильных кодослов на расстоянии 1.   Таким образом, с каждым из 2m кодослов связано   n+1 кодослов. Так как общее число кодослов - 2n, то (n+1)2m≤2, учитывая, что n=m+r, получаем:   
(m+r+1) ≤ 2r 
Для заданного m эта формула задает минимальное число контрольных разрядов, необходимых для исправления единичных ошибок. Этот теоретический предел достижим при использовании метода, предложенного Хеммингом. Идея его в следующем: 
Разряды кодослова нумеруются слева направо, начиная с 1. 
Все биты, номера которых являются степенью 2 (1, 2, 4, 8, 16 и т.д.) - контрольные, остальные - биты сообщения. 
Каждый контрольный бит отвечает за четность группы битов, включая себя. Чтобы определить группу битов, за четность которой отвечает определенный контрольный бит, нужно представить номер позиции каждого бита по степеням двойки. Те биты, в номера которых входит степень двойки, равная номеру контрольного бита, и есть искомая группа. Например, 11=1+2+8, 39=1+2+4+32. Таким образом, бит в позиции 11 входит в группу, контролируемую битом в позиции 2. 
Получив кодослово, получатель устанавливает специальный счетчик в ноль. Затем он проверят каждый контрольный бит на предмет правильности четности. Если четность нарушена, то порядковый номер этого бита заносится в счетчик. Если после этой проверки счетчик на нуле, то все в порядке. Если нет, то он содержит номер неправильного разряда. Например, если 1, 2, 8 - ошибочные контрольные разряды, то ошибка содержится в 11-м разряде, так как только он связан одновременно с этими контрольными разрядами. 
На рисунке 3-6 показан 7-разрядный ASCII-код и соответствующий ему 11-разрядный код Хемминга. В этом коде Хемминга разряды 1, 2, 4, 8 - контрольные. 3-й разряд в этом коде соответствует 1-му разряду исходного кода, разряды 5, 6, 7, 9, 10, 11 - разрядам 2, 3, 4, 5, 6, 7 соответственно. 1-й разряд в коде Хемминга контролирует группу, в которую входят разряды с номерами 3, 5, 7, 9, 11, что соответствует разрядам 1, 2, 4, 5, 7 в исходном коде. Так как число 1 в этих разрядах в исходном коде четно, то 1-й разряд в коде Хемминга равен 0. Аналогично определяем значение остальных контрольных разрядов. 
Рисунок 3-6. Использование кода Хемминга для исправления ошибок передачи 

Код Хемминга может исправлять только одиночные ошибки. Однако есть прием, который позволяет распространить идеи Хемминга на случай групповых ошибок. Пусть нам надо передать k кодослов. Расположим их в виде матрицы: одно слово - строка. Обычно передают слово за словом. Но мы поступим иначе, передадим слово длины k из первых разрядов всех слов, затем - вторых, и т.д. После приема всех слов матрица восстанавливается. Если мы хотим обнаруживать групповые ошибки размера k, то в каждой строке восстановленной матрицы будет не более одной ошибки. А с одиночными ошибками код Хемминга справится.
Рассмотрение кодов, обнаруживающих ошибки, начнем с небольшого примера. Пусть у нас есть канал с одиночными ошибками с частотой 10-6 на бит. Если мы хотим исправлять единичные ошибки при передаче блока в 1000 бит,   то нам потребуется 10 контрольных бит ((m+r+1) ≤ 2rr, где m =1000; (1001+r) ≤ 2rr, следовательно, r = 10).   
При передаче 1 Мбит данных потребуется 10 000 контрольных бит. В то же время для обнаружения единичной ошибки достаточно одного бита четности. Поэтому, если мы применим технику повторной передачи, то на передачу 1000 блоков надо будет потратить 1001 бит дополнительно или с повторной передачей 2002 бит, вместо 10000 бит в случае кода с исправлением ошибки. 
Применение техники четности ?в лоб? в случае групповых ошибок не даст нужного результата. Однако ее можно скорректировать. Пусть нам требуется передать n слов по k бит. Расположим их в виде матрицы n х k. Для каждого столбца вычислим бит четности и разместим его в дополнительной строке. Матрица затем передается по строкам. При получении матрица восстанавливается, и если хоть один бит нарушен, то весь блок передается повторно. 
Этот метод позволяет обнаружить групповые ошибки длины n. Против групповых ошибок длины n+1 он бессилен. В общем случае вероятность правильной передачи при длине групповой ошибки n равна 2-n. Поэтому на практике применяют другую технику, которая называется циклическим избыточным кодом   (Cyclic Redundancy Code), или CRC-кодом.   
CRC-коды построены на рассмотрении битовой строки как строки коэффициентов полинома. Битовую строку длины k рассматривают как коэффициенты полинома степени k-1. Самый левый бит строки - коэффициент при старшей степени. Например, строка 110001 представляет полином x5+x4+x0. 
Использование полиномиальных кодов при передаче заключается в следующем. Отправитель и получатель заранее договариваются о конкретном генераторе полиномов G(x), у которых коэффициенты при старшем члене и при младшем члене должны быть равны 1. Пусть степень G(x) равна r. Для вычисления контрольной суммы блока из m бит должно быть r<m. Идея состоит в том, чтобы добавить контрольную сумму к передаваемому блоку, рассматриваемому как полином М(х), так, чтобы передаваемый блок с контрольной суммой был кратен G(x). Когда получатель получает блок с контрольной суммой, он делит его на G(x). Если есть остаток, то были ошибки при передаче. Полиномиальная арифметика выполняется по модулю 2. Сложение и вычитание происходит без переноса разрядов. Таким образом, обе эти операции эквивалентны EXCLUSIVE OR. Например, 
   10011011     00110011     11110000     01010101 
+ 11001010  + 11001101   - 10100110   - 10101111 
  -----------   ----------   -----------   ----------- 
   01010001     11111110      01010110      11111010 
Деление выполняется, как обычно в двоичной системе, с той лишь разницей, что вычитание выполняется по модулю два. 
Алгоритм вычисления контрольной суммы: 
Здесь r - степень G(x). 
1.Добавить r нулей в конец блока так, что он содержал m+r разрядов и соответствовал полиному xr M(x). 
2.Разделить по модулю 2 полином xr M(x) на G(x). 
3.Вычесть остаток (длина которого всегда не более r разрядов) из строки, соответствующей xr M(x), по модулю 2. Результат и есть блок с контрольной суммой (назовем его Т(х)).   
Рисунок 3-7 показывает этот алгоритм для блока 1101011011 и G(x) = х4+х+1. 
Рисунок 3-7. Расчет контрольной суммы для полиномиального кода   

Данный метод позволяет обнаруживать одиночные ошибки. Групповые ошибки длины не более r. Нечетное число отдельных ошибок. Существует три международных стандарта на вид G(x): 
CRC-12 = x12+x11+x3+x2+x+1 
CRC-16 = x16+x15+x2+1 
CRC-CCITT = x16+x12+x5+1 
CRC-12 используется для передачи символов из 6 разрядов. Два остальных - для 8-разрядных. CRC-16 и CRC-CCITT ловят одиночные, двойные ошибки, групповые ошибки длины не более 16 и нечетное число изолированных ошибок с вероятностью 99,997%. 
.3. Простейшие протоколы канала данных 
Рассмотрение протоколов уровня канала данных мы начнем с нескольких предположений. Будем предполагать, что физический уровень, уровень канала данных, сетевой уровень - реализованы в виде независимых процессов, взаимодействующих с помощью передачи сообщений. В некоторых случаях физический уровень и уровень канала данных могут выполняться на некотором вспомогательном процессоре ввода-вывода, внешнем по отношению к основному процессору; в некоторых случаях все процессы могут выполняться на основном процессоре. Возможны также разные реализации: физический и канальный уровни могут быть реализованы в виде процедур, вызываемых сетевым уровнем, и т.д. Однако мы будем предполагать, что все три уровня представлены как независимые процессы. 
Также мы предположим, что есть две машины: А и В. У машины А есть бесконечно длинный набор данных, который надо передать машине В с помощью надежного сервиса, ориентированного на соединение. Передача всегда происходит от А к В, хотя позднее мы допустим одновременную передачу от В к А. Также будем предполагать, что если канальный уровень на машине А запрашивает данные для передачи от сетевого уровня, то они всегда есть и нет задержки на их подготовку. 
Канальный уровень рассматривает данные, которые он получает от сетевого, как неструктурированные, несмотря на то, что там есть хотя бы заголовок сетевого уровня. Все эти данные должны быть переданы равнозначному сетевому уровню. Когда канальный уровень получает пакет, он погружает его в кадр, добавляя заголовок и концевик. Этот кадр затем передается по физическому уровню. Будем предполагать, что есть две библиотечные процедуры: from_physical_layer - для получения кадра с физического уровня, и to_physical_layer - для передачи кадра на физический уровень. Предполагаем, что вычисление и добавление контрольных сумм происходит аппаратно. 
Изначально получатель просто ожидает, ничего не предпринимая, наступления какого-либо события. В наших примерах это будет выражаться в вызове процедуры wait_for_event(&event), где параметр event возвращает информацию о произошедшем событии. Ясно, что в действительности никто не будет ожидать в цикле (будут использованы прерывания), но мы для простоты будем считать так. 
Когда кадр поступает к получателю, контрольная сумма вычисляется аппаратно. Если она неверна, то канальному уровню сообщается: event=cksum_err. Если кадр поступил без повреждений, то канальный уровень информируется так: event=frame_arrivel. 
На рисунке 3-8 приведены многие структуры, используемые позднее. Там же указаны процедуры, которые используются при построении протоколов. 
Рисунок 3-8. Перечень функций, используемых в описании протокола канального уровня 

Как мы уже отмечали, для того чтобы обнаруживать случаи потери кадров, уровень канала, отправляя кадр, должен устанавливать таймер. Если подтверждение не придет раньше, чем истечет время таймера, то считается, что кадр не дошел. В этом случае event=timeout. Процедуры start_timer и stop_timer используют для пуска и остановки таймера. Процедуру запуска таймера можно вызывать, не ожидая окончания предыдущего запуска. Подобное обращение будет означать перезапуск таймера на новый интервал. 
Процедуры start_act_timer и stop_act_timer используются для управления дополнительным таймером, используемым в определенных случаях для уведомления. 
Процедуры enable_network_layer и disable_network_layer используются в сложных протоколах, когда предполагается, что на сетевом уровне нет пакетов для передачи. Когда канальный уровень разрешит сетевому уровню снова передавать пакеты, сетевой информирует об этом событием event=network_layer_ready. Если канальный уровень выполнил процедуру disable_network_layer, то event=network_layer_ready может и не последовать. Таким способом канальный уровень может управлять потоком от сетевого уровня. 
3.3.1. Симплекс-протокол без ограничений 
На рисунке 3-9 представлен простейший протокол канального уровня. Данные передаются только в одном направлении. Получатель и отправитель всегда готовы к отправке и получению данных. Время обработки данных игнорируется. Предполагается, что буфер неограниченного размера. Данные в канале не теряются и не искажаются. 
Рисунок 3-9. Симплексный протокол канального уровня 

3.3.2. Симплексный старт-стопный протокол 
Теперь снимем одно из ограничений предыдущего протокола - способность сетевого уровня обрабатывать поступающие данные сколь угодно быстро. Все остальные предположения остаются в силе: канал абсолютно надежный, трафик однонаправленный. 
Основная проблема - как предотвратить ситуацию, когда отправитель ?заваливает? данными получателя. Если получателю требуется время ?t, чтобы исполнить from_physical_layer плюс to_network_layer, то отправитель должен передавать данные со средней скоростью один кадр в ?t. 
Решением такой проблемы может быть введение коротких специальных служебных сообщений. Получатель, получив один или несколько кадров, отправляет отправителю короткий специальный кадр, означающий, что отправитель может передавать следующий. Это так называемый старт-стопный протокол, показанный на рисунке 3-10. 
Рисунок 3-10. Однонаправленный старт-стопный протокол канального уровня 

3.3.2. Симплексный старт-стопный протокол 
Теперь снимем одно из ограничений предыдущего протокола - способность сетевого уровня обрабатывать поступающие данные сколь угодно быстро. Все остальные предположения остаются в силе: канал абсолютно надежный, трафик однонаправленный. 
Основная проблема - как предотвратить ситуацию, когда отправитель ?заваливает? данными получателя. Если получателю требуется время ?t, чтобы исполнить from_physical_layer плюс to_network_layer, то отправитель должен передавать данные со средней скоростью один кадр в ?t. 
Решением такой проблемы может быть введение коротких специальных служебных сообщений. Получатель, получив один или несколько кадров, отправляет отправителю короткий специальный кадр, означающий, что отправитель может передавать следующий. Это так называемый старт-стопный протокол, показанный на рисунке 3-10. 
Рисунок 3-10. Однонаправленный старт-стопный протокол канального уровня 

3.3.3. Симплексный протокол для канала с шумом 
Основная проблема при передаче состоит в том, что кадр с подтверждением о получении может потеряться целиком. Как отличить кадр, переданный первый раз, от кадра, переданного повторно? 
Одно из очевидных решений - нумерация передаваемых кадров. Однако сколько места отводить под эту нумерацию? Поскольку проблема различения стоит для кадров m и m+1, то достаточно одного разряда. 0 - для только что посланного кадра и 1 - для следующего ожидаемого. Все кадры, не содержащие корректной нумерации, просто сбрасываются при приеме. 
На рисунке 3-11 показана программа для этого варианта протокола. 
Рисунок 3-11. Протокол с подтверждением и восстановлением 

4. Протоколы скользящего окна 
В рассмотренных выше протоколах канального уровня кадры передавались только в одном направлении. Для передачи в обоих направлениях можно потребовать на физическом уровне двух симплексных каналов. Один для передачи кадров, другой - для передачи подтверждений. Однако использование канала только для подтверждений - довольно дорогое удовольствие. Можно смешивать кадры с данными и кадры с подтверждениями на одном канале. Это, конечно. решение проблемы, но по-прежнему на подтверждения будет тратиться полезная пропускная способность канала. 
А что, если для подтверждения использовать полезные кадры с данными? Получатель не сразу отправляет подтверждение, а ожидает от сетевого уровня очередного пакета. Как только такой пакет возникает, то канальный уровень помещает в кадр с пакетом также уведомление о получении в специальное поле ack. Такой прием позволяет полнее использовать имеющуюся пропускную способность канала. Меньше кадров - меньше прерываний на канальном уровне на их обработку, меньше затрат на буферизацию. 
Однако применение этой идеи усложняет протокол. Что делать, если тайм-аут у отправителя на получения подтверждения заканчивается, а с сетевого уровня получателя не поступает запроса на передачу пакета? Поэтому на канальном уровне должен быть фиксированный интервал времени, в течение которого канальный уровень ждет от сетевого попутного кадра. Если до истечения этого срока пакет с сетевого уровня не поступил, то канальный уровень отправляет подтверждение отдельным кадром. 
Рассмотренный здесь протокол является представителем класса протоколов скользящего окна. Кроме вышесказанного, протоколы этого класса делают следующее: у отправителя и получателя есть определенная константа n - число кадров, которое отправитель может послать, не ожидая подтверждения для каждого кадра. По мере получения подтверждений отправленные кадры будут сбрасываться из буфера отправителя, и буфер будет пополняться новыми кадрами. 
Мы уже сталкивались с подобными протоколами (старт-стопный протокол). В них n было равно 1. Обычно n=2k-1. У получателя и отправителя есть набор последовательных чисел - номеров кадров,   которые отправитель может отправить, не ожидая подтверждения каждого.   Эти кадры образуют окно отправки.   Аналогично, у получателя есть буфер для получения и временного хранения получаемых кадров - окно получения.      
Хотя в этих условиях у отправителя есть определенная свобода в порядке отправления кадров, мы по-прежнему будем считать, что кадры отправляют в соответствии с порядковыми номерами. У окон отправки и получения есть верхняя и нижняя границы. Порядковые номера кадров в окне отправки - кадры отправленные, но не подтвержденные. Как только от сетевого уровня поступил еще один пакет, ему присваивают первый свободный наибольший номер, и верхняя граница окна отправителя поднимается. Как только приходит подтверждение, нижняя граница окна поднимается. Таким образом, в окне все время находятся неподтвержденные кадры. 
Рисунок 3-12 показывает работу такого протокола для n=1 в форме диаграммы. 
Рисунок 3-12. Протокол скользящего окна 

Прежде чем переходить к общему случаю, рассмотрим протокол скользящего окна с максимальным размером окна в 1 бит. Такой протокол использует старт-стопный режим и, послав кадр, не шлет другой, пока не придет подтверждение на первый. 
На рисунке 3-13 показан текст протокола для этого простейшего случая. Как и все, он начинается с определения переменных. Next_frame_to_send указывает, какой кадр посылается. Переменная frame_expected определяет, какой кадр получатель ожидает. Есть только два значения - 0 или 1. 
Рисунок 3-13. Протокол скользящего окна в 1 бит 

Есть два случая: первый - простой и наиболее удобный, когда только один из канальных уровней первым начинает передачу. В этом случае вне тела основного цикла одной из программ канального уровня есть обращения к процедурам to_phisical_layer и start_timer. Случай, когда оба уровня одновременно могут начинать передачу, описывается позже, поскольку он требует более детального рассмотрения. 
Машина, инициирующая обмен, берет пакет от сетевого уровня, формирует кадр и посылает его. Когда он (или любой другой кадр) поступает, канальный уровень-получатель проверяет: не является ли этот кадр дубликатом. Если поступивший кадр тот, что ожидался, то он передается на сетевой уровень и окно получателя сдвигается вверх. 
Поле уведомления содержит номер последнего кадра, полученного без ошибок. Если этот номер согласуется с номером кадра, который уровень-отправитель старается послать, то он считает, что кадр, хранящийся в буфере, послан, и сбрасывает его оттуда, забирая новый с сетевого уровня. Если номера не согласуются, то отправитель старается послать тот же кадр еще раз. В любом случае, после получения кадра отправляется новый кадр. 
На рисунке 3-14 показан протокол 4. Если у А очень короткий тайм-аут, то все дубликаты кадра пойдут с одним и тем же значением полей seq и ask. Поэтому, получив исправный кадр, В установит значение переменной frame_expected равным 1 и пошлет подтверждение. Все последующие дубликаты будут им отвергнуты, так как он будет ожидать кадра с 1, а не 0. 
Случай, когда оба канальных уровня начинаю передачу одновременно, показан на рисунке 3-14 (b). В нем возникает много повторных передач одного и того же кадра даже при отсутствии ошибок в передаче. 
Рисунок 3-14. Два сценария для протокола 4 

.4.2. Протокол с возвратом на n кадров и протокол с выборочным повтором 
До сих пор мы предполагали, что время доставки кадра и время доставки подтверждения пренебрежимо малы. В некоторых случаях это предположение очевидно не работает. Оно может приводить к серьезным бесполезным тратам пропускной способности канала. Рассмотрим пример спутникового канала на 50 Кбит/сек. с общей задержкой 500 мсек. Пусть мы хотим использовать протокол 4 для передачи кадров размером 1000 бит по этому каналу. В момент t=0 отправитель отправляет первый кадр. В t=20 мсек. кадр полностью отправлен, в t=270 мсек он принят и в t=520 мсек. отправитель получил подтверждение. Эти цифры говорят о том, что отправитель был блокирован в течение 500/520, т.е. 96% времени. А это - потеря пропускной способности канала. 
Эта проблема есть следствие правила, по которому отправитель ждет подтверждения прежде, чем пошлет следующий кадр. Это требование можно ослабить - разрешить отправителю отправлять до w кадров, не дожидаясь их подтверждения. Надлежащим выбором значения w отправитель может заполнить все время, необходимое на отправку кадра и получение его подтверждения. В вышеприведенном примере w должно быть равным, по крайней мере, 26. Это то количество кадров, какое отправитель успеет отправить за 520 мсек., прежде чем придет подтверждение на кадр 0. Таким образом, неподтвержденными будут 25 из 26 кадров, размер окна отправителя будет равным 26 кадров. 
Эта техника известна как конвейер. Ее применение в случае ненадежного канала наталкивается на ряд проблем. Первая - что делать, если в середине потока пропадет или попадется поврежденный кадр? Получатель уже получит большое количество кадров к тому моменту, когда отправитель обнаружит, что что-то произошло. Когда получатель получил поврежденный кадр, он его должен сбросить, что делать с последующими кадрами? Помните, что канальный уровень обязан передавать пакеты на сетевой уровень в том порядке, в каком их отправлял отправитель. 
Есть два приема для решения этих вопросов: откат и выборочный повтор. При откате все кадры, поступившие после поврежденного кадра, сбрасываются и не подтверждаются. Отправитель по тайм-ауту повторно отправляет все кадры, начиная с первого неподтвержденного кадра. Этот подход показан на рисунке 3-15 (а), где размер окна у получателя - 1. 
Рисунок 3-15. Влияние ошибки при окне размером 1 (a) и окне большого размера (b) 

При выборочном повторе у получателя длина окна такая же, как и у отправителя. Отправитель отмечает неподтвержденный кадр и посылает его еще раз. Получатель не передает на сетевой уровень последовательность пакетов, если в ней есть разрывы. Этот подход показан на рисунок 3-15 (b). 
3.5.1. Протокол 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-16. Типовая структура кадра протокола HDLC 

На рисунке 3-16 показана типовая структура кадра протокола HDLC. 
Поле Address используют для адресации терминала, если их несколько на линии. Для линий точка-точка это поле используется для того, чтобы отличать команду от ответа. 
Поле Control используется для последовательных номеров кадров, подтверждений и других нужд. 
Поле Data может быть сколь угодно большим и используется для передачи данных. Надо только иметь в виду, что чем длиннее это поле, тем больше вероятность повреждения кадра на линии. 
Поле Checksum - это поле используется для передачи CRC-кода. 
Флаговые последовательности 01111110 используются для разделения кадров и постоянно передаются по незанятой линии в ожидании кадра. Существует три вида кадров: Information, Supervisory, Unnumbered. Организация поля Control для этих трех видов кадров показана на рисунке 3-17. Как видно из размера поля Seq, в окне отправителя может находиться до 7 неподтвержденных кадров. Поле Next используется для отправки подтверждения вместе с передаваемым кадром. Подтверждение может быть в форме номера последнего правильно переданного кадра, а может быть в форме первого, еще не переданного кадра. Какой вариант будет использован - зависит от параметров протокола. 
Рисунок 3-17. Поле Control для кадров: Information (a), Supervisory (b), Unnumbered (c) 

Разряд 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 не используют  кадры этого типа. 
Третий класс кадров - Unnumbered. Кадры этого класса иногда используются для целей управления, но чаще для передачи данных при ненадежной передаче без соединения. 
Все протоколы имеют команду DISConnect - для сообщения о разрыве соединения. Команды SNRM и SABM используются для установки счетчиков кадров в ноль, сброса соединения в начальное состояние, установки соподчиненности на линии. Команда FRMR указывает на повреждение управляющего кадра (например, когда контрольная сумма верна, а значения полей противоречивы). 
3.5.2.1. Проблемы стандартизации 
Ретрансляция кадров (Frame Relay, FR) - это метод доставки сообщений в сетях передачи данных (СПД) с коммутацией пакетов. Первоначально разработка стандарта FR ориентировалась на цифровые сети интегрированного обслуживания (ISDN - Integrated Services Digital Networks), однако позже стало ясно, что FR применим и в других СПД (здесь под данными понимается любое сообщение, представленное в цифровой форме). К числу достоинств рассматриваемого метода прежде всего необходимо отнести малое время задержки, простой формат кадров, содержащих минимум управляющей информации, и независимость от протоколов верхних уровней модели OSI. 
В настоящее время разработкой и исследованием стандартов FR занимаются три организации: 
Frame Relay Forum (FRF) - международный консорциум, включающий в себя свыше 300 поставщиков оборудования и услуг, среди которых 3Com, Northern Telecom, Digital, Cisco, Netrix, Ascom Timeplex, Newbridge Networks, Zilog и др.; American National Standards Institute (ANSI, Американский национальный институт по стандартизации); Международный союз электросвязи (ITU-T). 
Любой международный стандарт имеет (и всегда будет иметь) множество прикладных реализаций, что зачастую приводит к несовместимости аппаратно-программных средств разных производителей. Международные организации неоднократно пытались решить данную проблему. Результатом одной из таких попыток (предпринятой FRF) стал проект стандарта, включающего в себя спецификации ANSI, которые обязательны для выполнения членами FRF. В январе 1992 г. этот проект был доработан Техническим комитетом FRF и утвержден собранием членов FRF. 

3.5.2.2. Логическая характеристика протокола FR 
FR является бит-ориентированным синхронным протоколом и использует кадр в качестве основного информационного элемента - в этом смысле он очень похож на протокол HDLC (High Level Data Link Control), рассмотренного нами в предыдущем разделе. Однако FR обеспечивает не все функции протокола HDLC. Многие элементы кадра HDLC исключены из основного формата кадра FR (в последнем адресное поле и поле управления HDLC совмещены в едином адресное поле), что привело к сокращению набора функций в этом протоколе. 
Рисунок 3-18. Структура и формат кадра Frame Relay 

Структура кадра FR (рисунок 3-18) включает в себя следующие элементы: 
1.Флаг. Все кадры начинаются и заканчиваются комбинацией "флаг": "01111110". 
2.Заголовок: 
Адрес в пределах кадра FR (стандарт FRF), состоит из шести бит первого байта и четырех бит второго байта заголовка кадра (стандарты ANSI и ITU-T допускают размер заголовка до 4 байтов). Эти 10 бит представляют собой идентификатор канала передачи данных (Data Link Connection Identifier, DLCI) и определяют абонентский адрес в сети FR. 
Бит ?опрос/финал? (Command/ Response - CR) зарезервирован для возможного применения в различных протоколах более высоких уровней управления OSI. Этот бит не используется протоколом FR и ?прозрачно? пропускается аппаратно-программными средствами сети FR. 
Бит расширения адреса (Extended Address - EA). DLCI содержится в 10 битах, входящих в два байта заголовка. Однако возможно расширение заголовка на целое число дополнительных байтов с целью указания адреса, состоящего более чем из 10 бит. Бит EA устанавливают в конце каждого байта заголовка; если он имеет значение ?1?, то это означает, что данный байт в заголовке последний. Стандарт FRF рекомендует использовать заголовки, состоящие из двух байтов. В этом случае значение бита EA первого байта будет соответствовать ?0?, а второго - ?1?. 
Бит уведомления (сигнализации) приемника о явной перегрузке (Forward Explicit Сongestion Notification - FECN) устанавливается в ?1?, если надо информировать получателя о том, что произошла перегрузка в направлении передачи данного кадра (рисунок 3-19). 
Бит уведомления (сигнализации) отправителя о явной перегрузке (Backward Explicit Сongestion Notification - BECN). Этот бит  устанавливают в ?1? для уведомления отправителя сообщения о том, что произошла перегрузка в направлении, обратном направлению передачи содержащего этот бит кадра. Бит BECN может не использоваться терминалами абонентов (см. рисунок 3-19), т.е. в этом направлении возник слишком большой поток кадров. 
Бит разрешения сброса (Discard Eligibility - DE) устанавливают в ?1? в случае явной перегрузки. Он указывает на то, что данный кадр может быть уничтожен в первую очередь, т.е. пользователю предоставлено право выбирать, какими кадрами он может ?пожертвовать?. Однако при перегрузках узлы коммутации сети FR уничтожают не только кадры с битом DE. 
Рисунок 3-19. Установка бит перегрузки 

3.Информационное поле содержит данные пользователя и состоит из целого числа байтов. Его максимальный размер определен стандартом FRF и составляет 1600 байтов (минимальный размер - 1 байт), но возможны и другие максимальные размеры (вплоть до 4096 байтов). Содержание информационного поля пользователя передается неизменным. 
4.Проверочная последовательность кадра (Frame Check Sequence - FCS) используется для обнаружения возможных ошибок при его передаче и состоит из двух байтов. Данная последовательность формируется аналогично циклическому коду HDLC. 
Все указанные поля должны присутствовать в каждом кадре FR, который передается между двумя оконечными пользовательскими системами. 
Одним из основных отличий протокола FR от HDLC является то, что он не предусматривает передачу управляющих сообщений (нет командных или супервизорных кадров, как в HDLC). Для передачи служебной информации используется специально выделенный канал сигнализации. Другое важное отличие - отсутствие нумерации последовательно передаваемых (принимаемых) кадров. Дело в том, что протокол FR не имеет никаких механизмов для подтверждения правильно принятых кадров.

3.5.2.3. Процедурная характеристика протокола FR 
Протокол FR является весьма простым по сравнению с HDLC и включает в себя небольшой свод правил и процедур организации информационного обмена. Основная процедура состоит в том, что если кадр получен без искажений, он должен быть направлен далее по соответствующему маршруту. При возникновении проблем, связанных с перегрузкой сети FR, ее узлы могут сбрасывать любой кадр. 
Узлам сети FR разрешено уничтожать искаженные кадры, не уведомляя об этом пользователя. Искаженным считается кадр, которому присущ какой-либо из следующих признаков: 
Нет корректного ограничения флагами. 
Имеется менее пяти байтов между флагами. 
Нет целого числа байтов после удаления бит обеспечения прозрачности. 
Присутствует ошибка контрольной суммы. 
Искажено поле адреса (для случая, когда проверка не выявила ошибки в FCS). 
Содержится несуществующий DLCI. 
Превышен допустимый максимальный размер (в некоторых вариантах реализации стандартов FR возможна принудительная обработка кадров, превышающих допустимый максимальный размер). 
Для FR характерно: 
заполнение канала связи комбинацией ?флаг? при отсутствии данных для передачи 
резервирование одного DLCI для интерфейса локального управления и сигнализации 
содержание поля данных пользователя в любом кадре не должно подвергаться какой-либо обработке со стороны аппаратуры канала данных (могут обрабатываться лишь данные в локальном канале управления) 
3.5.2.4. Управление доступом и защита от перегрузок 
Управление доступом к сети FR возлагается на интерфейс локального управления (Local Management Interface - LMI). Именно LMI (он будет рассмотрен ниже) реализует интерфейс UNI (Unified Network Interface). Доступ в сеть FR обеспечивают интерфейсы FR (?порты FR?) и FR-адаптеры - сборщики/разборщики кадров (FR assembler/disassembler, FRAD). 
Добиться высокой эффективности использования пропускной способности физических линий и каналов связи, а также исключения перегрузок узлов связи и всей сети FR позволяет метод статистического мультиплексирования кадров, который подразумевает: 
постоянное наблюдение за потоком заявок от пользователей на передачу сообщений и за текущей загрузкой сети (линий, каналов и узлов связи) 
перераспределение свободного (и высвобождающегося) ресурса пропускной способности в соответствии с реальными потребностями абонентов 
предоставление пользователям каналов информационного обмена, удовлетворяющих их требованиям 
Данный метод обеспечивает синхронный ввод сообщений пользователей в высокоскоростной канал связи на основе соглашений, заключенных между пользователем и поставщиком услуг сети FR. Услуги различаются по следующим параметрам: 
максимальный размер поля информации в кадре FR (в байтах) 
пропускная способность порта, посредством которого абонент подключается к сети FR 
гарантированная скорость передачи данных (Committed Information Rate, CIR) - при обеспечении требуемого качества доставки 
гарантированный объем передачи информации (Committed Burst Size, BC) - при обеспечении требуемого качества доставки 
дополнительный объем передачи информации (Excess Burst Size, BE) - при возможном снижении качества передачи данных 
Предварительные соглашения реализуются следующим образом. 
1.Абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для фиксированного виртуального соединения (PVC). 
2.Узел доступа к сети FR измеряет ?реальную потребность абонента? в ресурсе пропускной способности канала связи. 
3.Если этот ресурс (выраженный реальной скоростью передачи информации) не превышает CIR, то кадры передаются без изменений. Если требуемая скорость превышает CIR, но соответствует пропускной способности порта, то бит DE устанавливается в ?1?, что дает возможность удалять соответствующие кадры при возникновении перегрузок (абонент также имеет право решать, какие кадры для него менее важны). Наконец, если превышена пропускная способность порта, кадры уничтожаются вне зависимости от каких-либо условий. 
Абонент способен воспользоваться предварительным соглашением и для того, чтобы уменьшить свои затраты следующим оригинальным способом. Некоторые операторы сетей (поставщики услуг) предлагают значительные скидки при передаче кадров с битом DE, установленным в ?1?. При наличии в сети значительного запаса пропускной способности абонент может установить гарантированную скорость передачи, равную нулю. В этом случае во всех передаваемых кадрах бит DE будет установлен в ?1?. 

3.5.3. Уровень канала данных в Интернете 
Здесь мы рассмотрим протоколы, которые используются для каналов ?точка-точка? в Интернете. На уровне канала данных соединения ?точка-точка? возникают между маршрутизаторами либо коммутирующими элементами в СПД. Другой часто встречающийся случай для таких соединений - соединение из дома через модем с интернет-провайдером. Эта ситуация показана на рисунке 3-20. 
Рисунок 3-20. Доступ в Интернет 

Для упомянутых выше соединений: ?маршрутизатор-маршрутизатор? и ?хост-маршрутизатор? через телефонную линию было предложено два протокола: SLIP и PPP. 

3.5.3.1. SLIP - Serial Line IP 
SLIP - наиболее старый из этих двух протоколов. Он был создан в 1984 году для соединения рабочих станций SUN через модем. Этот протокол был описан в RFC 1055. Его работа очень проста: он вставляет специальные флаг-байты в начало и конец IP-пакета. 
Последние версии этого протокола осуществляют также сжатие заголовков TCP и IP у последовательных пакетов, так как они несут очень много одинаковой информации. Одна из последних версий этого протокола описана в RFC 1144. 
SLIP имеет ряд серьезных недостатков - он не занимается контролем и исправлением ошибок, оставляя это протоколам верхних уровней. Во-вторых, он работает только с IP-пакетами. В современных условиях, когда Интернет объединяет самые разнообразные сети, это серьезный недостаток. 
В-третьих, IP-адреса взаимодействующих сторон должны быть известны заранее. В условиях нехватки IP-адресов это недостаток, так как было бы удобнее задавать IP-адрес динамически, лишь на период действия соединения. 
В-четвертых, этот протокол не обеспечивает какой-либо проверки аутентичности взаимодействующих сторон. Так что вы не можете быть уверены, с кем вы общаетесь. 
В-пятых, для этого протокола нет стандарта, и существует множество его версий, не все из которых совместимы. 

3.5.3.2. PPP - протокол ?точка-точка? 
Чтобы исправить указанные выше недостатки, комитет IETF (Internet Engineering Task Force) создал группу, которой было поручено разработать новый протокол. В результате ее усилий появился протокол РРР (Point-to-Point Protocol), описанный в RFC 1661, 1662 и 1663. Протокол РРР обеспечивает обнаружение ошибок, поддерживает разные протоколы, позволяет динамически выделять IP-адрес только на период соединения, выполняет аутентификацию абонентов и имеет ряд других преимуществ перед SLIP. 
Протокол РРР обеспечивает три основных функции: 
1.Распознавание кадров. Однозначно определяется конец кадра и начало нового. Здесь же происходит обнаружение ошибок. 
2.Управление линией, т.е. активизация линии, ее проверка, определение основных параметров передачи в диалоге, корректное завершение передачи со сбросом параметров. Этот протокол называет LCP (Link Control Protocol). 
3.Определение основных параметров соединения между сетевыми уровнями, чтобы обеспечить независимость от реализации сетевого уровня. Выбранный метод предполагает наличие разных NCP (Network Control Protocol) на каждом поддерживаемом сетевом уровне. 
Чтобы лучше понять, как это все работает вместе, рассмотрим типичный сценарий, когда пользователь из дома по телефонной линии хочет подключить свой PC к Интернету. РС звонит на маршрутизатор сервис-провайдера. После того как маршрутизатор принял звонок и установил физическое соединение, РС посылает несколько LCP-пакетов в РРР-кадрах. Маршрутизатор отвечает LCP-пакетами в РРР-кадрах. В результате такого обмена определяются параметры соединения. 
После этого следует обмен NCP-пакетами для настройки сетевого уровня. В частности, здесь происходит временное присваивание РС IP-адреса, который действует только на период соединения. Это происходит, если обе стороны хотят использовать TCP/IP-стек. 
Теперь, когда РС стала полноправной машиной в Интернете, она может обмениваться IP-пакетами с другими машинами. Когда пользователь закончит работу, NCP разрывает соединение с сетевым уровнем и освобождает ранее занятый IP-адрес. После этого LCP-протокол разрывает соединение на канальном уровне. А затем компьютер говорит модему: ?Положи трубку?. 
РРР-кадры имеют формат, очень близкий к HDLC-кадрам. Основное различие состоит в том, что РРР - байт-ориентированный, а HDLC - бит-ориентированный. Для HDLC возможен кадр размером в 30,25 байт, а для РРР - нет. Формат РРР-кадра показан на рисунке 3-21. 
Рисунок 3-21. Формат PPP-кадра 

Все РРР-кадры начинаются со стандартного байта: 01111110. Поле ?Аddress? по умолчанию равно 11111111. Поле ?Control? по умолчанию равно 00000011, что означает ?Unnumbered-кадр?, т.е.  нумерация передаваемых кадров и подтверждений в их получении не предполагается. В случае ненадежной среды передачи данных есть вариант надежной передачи, описанный в RFC 1663. 
Так как значения полей ?Address? и ?Control? - константы, то LCP-протокол опускает их, экономя два байта на передаче. В поле ?Protocol? указывается, какой тип пакетов будет в поле ?Payload?. Там допускаются пакеты протоколов LCP, NCP, IP, IPX, Apple Talk и других. Поле ?Payload? имеет переменную длину, по умолчанию она равна 1600 байт. 
На рисунке 3-22 показаны основные фазы установления соединения и его разрыва. 
Рисунок 3-22. Основные фазы установления соединения и его разрыва 

В таблице 3-23 приведены 11 типов LCP-пакетов, допустимых по протоколу RFC 1661. 
Таблица 3-23. Типы LCP-пакетов 
Название 
Направление 
Значение 
Configure-request 
? 
Список предлагаемых параметров и их значений 
Configure-ack 
? 
Все параметры приняты 
Configure-nak 
? 
Некоторые параметры не приняты 
Configure-reject 
? 
Некоторые параметры недоступны 
Terminate-request 
? 
Требуется закрыть соединение 
Terminate-ack 
? 
ОК, соединение закрыто 
Code-reject 
? 
Получен неизвестный запрос 
Protocol-reject 
? 
Запрошен неизвестный протокол 
Echo-request 
? 
Пришлите кадр обратно 
Echo-reply 
? 
Вот ваш кадр 
Discard-request 
? 
Сбросьте этот кадр (для проверки) 

3.5.4. Уровень канала данных в ATM 
Теперь вернемся к уровням АТМ-протокола. Физический уровень в АТМ покрывает физический уровень и уровень канала данных в OSI. Поскольку физический уровень АТМ на подуровне физической зависимости не предъявляет каких-то специальных требований к физической среде, то мы сосредоточим наше внимание на ТС-подуровне - подуровне преобразования при передаче. 
Когда прикладная программа посылает сообщение, оно движется вниз по АТМ-стеку, получая заголовки, концевики, разбивается на ячейки и т.д. Проследим, что с ним происходит, когда ячейки достигают ТС-подуровня и далее. 
3.5.4.1. Передача ячеек 
Первый шаг - вычисление контрольной суммы заголовка. Заголовок состоит из 5 байт - 4 байта идентифицируют виртуальное соединение и несут контрольную информацию, за ними следует 1 байт с контрольной суммой. Контрольная сумма защищает только первые четыре байта и не затрагивает данные в ячейке. Контрольная сумма вычисляется как остаток от деления содержимого 4 байтов на полином x8+x2+x+1. К этому остатку добавляется константа 01010101 для повышения надежности, в случае если заголовок содержит много нулей.   
Решение защищать контрольной суммой только управляющую информацию было принято с целью сократить затраты на обработку на нижних уровнях. Защита собственно данных возложена на верхние уровни, если это необходимо. Как мы уже отмечали, многие приложения реального времени - передача видео-, аудиоданных - более критичны к времени передачи, чем к степени искажения отдельных ячеек. Поскольку контрольная сумма покрывает только заголовок, то этот байт так и называется - HEC (Header Error Control - контроль ошибки в заголовке). 
Другим важным фактором, повлиявшим на выбор этой схемы контрольной суммы, было то, что основной средой для АТМ является оптоволокно. Исследования, выполненные компанией АТ&Т, показали, что оптоволокно - высоконадежная среда и единичные ошибки происходят в ней с вероятностью менее 1%. Схема НЕС прекрасно справляется как с однобитными ошибками, так и множественными. 
Для надежной передачи ячеек была предложена схема, когда две последовательные ячейки объединяются через EXCLUSIVE OR, после чего получается новая ячейка, которая добавляется в последовательность после первых двух. В результате если хоть одна ячейка была принята с ошибкой или потеряна, то она легко может быть восстановлена. 
После того как НЕС вычислен и добавлен в заголовок, ячейка готова к передаче. Среда передачи может быть двух категорий - синхронной и асинхронной. В асинхронной среде ячейка посылается сразу, как только она готова к передаче. В синхронной среде ячейка передается в соответствии с временными соглашениями. Если нет ячейки для передачи, то ТС-подуровень должен сгенерировать специальную ячейку ожидания. 
Другой вид служебных ячеек - OAM (Operation And Maintenance). Эти ячейки используются АТМ-переключателями для проверки работоспособности системы. 
Ячейки ожидания обрабатываются соответствующим ТС-подуровнем, а ОАМ-ячейки передаются на АТМ-уровень. 
Другой важной функцией ТС подуровня является генерирование ячеек в формате физической среды передачи. Это значит, что ТС-подуровень генерирует обычную АТС-ячейку и упаковывает ее в кадр надлежащей среды передачи. 
3.5.4.2. Прием ячеек 
Итак, на выходе ТС-подуровень формирует НЕС-заголовок, преобразует ячейку в кадр, формирует АТМ-ячейки и передает поток битов на физический уровень. На противоположном конце ТС-подуровень производит те же самые действия, но в обратном порядке: разбивает поток бит на кадры, выделяет ячейки, проверяет НЕС-заголовки и передает ячейки на АТМ-уровень. 
Самое трудное - выделить кадр из потока битов. На уровне битов ячейка - это 53х8 = 424 бита. Нет маркеров ни начала, ни конца кадра. Как определить границы кадра? 
На ТС-подуровне есть сдвиговый регистр на 40 бит. Если в этих 40 бит правые 8 представляют собой НЕС, то последующие 32 левых бита - заголовок ячейки. Если условие не выполнено, то все сдвигается на один бит и проверка повторяется. Этот процесс продолжается до тех пор, пока не будет обнаружен НЕС. 
Схема распознавания в том виде, как она описана не надежна. Вероятность того, что случайный байт будет выглядеть как НЕС, равна 1/256. Чтобы исправить эту схему, используют автомат, схема состояний которого изображена на рисунке 3-24. Есть три состояния: HUNT, PRESYNCH, SYNCH. В состоянии HUNT ищется НЕС. Как только найден похожий байт, автомат переходит в состояние PRESYNCH и отчитывает следующие 53 байта. Если предположение о том, что найденный НЕС - начало ячейки, то сдвиг на 53 байта приведет к следующему НЕС. Происходит проверка последовательно ? ячеек, после этого происходит переход в состояние SYNCH. 
Рисунок 3-24. Процедура поиска ячеек 

Если в состоянии SYNCH ? последовательных ячеек оказались плохими, происходит переход в состояние HUNT.