Wayback Machine
APR Jun Jul
Previous capture 22 Next capture
2006 2008 2009
12 captures
28 Apr 05 - 22 Jun 08
sparklines
Close Help
полная версия

Замок Дракона

Б   Е   З       Б   А   Ш   Н   И

На главную
/ Архивы Замка Дракона / Лекции ВМиК / Сети / Канальный уровень

3. Канальный уровень


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

3.1 Проблемы, решаемые на уровне канала данных

На уровне канала данных решается ряд проблем, присущих только этому уровню: реализация сервиса для сетевого уровня, объединение битов, поступающих с физического уровня в кадры, обработка ошибок передачи, управление потоком кадров.

3.1.1 Сервис, предоставляемый сетевому уровню

Основной задачей канального уровня обеспечить сервис сетевому уровню. Назначение этого сервиса - помочь передать данные процесса на сетевом уровне одной машины процессу на сетевой уровень другой машины.

Так как это показано на рис.3-1 а. Фактически передача будет происходить так, как показано на рис.3-1 b. Однако, для простоты изложения мы будем считать, что это происходит как на рис.3-1 а.

Канальный уровень может создаваться для различного сервиса, который может варьироваться от системы к системе. Однако, есть три общие вида сервиса:

  1. Сервис без уведомления и без соединения.
  2. Сервис с уведомлением и без соединения.
  3. Сервис с уведомлением и с соединением.

Сервис без уведомления и без соединения не предполагает, что прием переданного кадра должен подтверждаться, что до начала передачи должно устанавливаться соединение, которое после передачи должно разрываться. Если в результате помех на физическом уровне кадр будет потерян, то никаких попыток его восстановить на канальном уровне не будет. Этот класс сервиса используется там, где физический уровень обеспечивает высокую надежность при передаче так, что восстановление при потери кадров можно оставить на верхние уровни. Он также применяется при передаче данных в реальном времени там, где лучше потерять часть данных, чем увеличить задержку в их доставке. Например, передача речи. Большинство ЛВС использует этот класс сервиса на канальном уровне.

Следующий класс сервиса - уведомление без соединения. В этом классе получение каждого посланного кадра должно быть подтверждено. Если подтверждения не пришло в течении определенного времени, то кадр должен быть послан опять. Этот класс сервиса используется над ненадежной физической средой передачи, например, беспроводной.

Можно конечно было бы подтверждать не кадры, а все сообщение на сетевом уровне. Однако, это было бы не выгодно для больших сообщений, при передаче которых разрушалось бы 10-20%. Повторная передача таких сообщений заняла бы больше времени, чем передача их отдельных фрагментов. Так что подтверждение на канальном уровне следует рассматривать как оптимизацию, а не необходимость.

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

При сервисе с подтверждение и соединением передача разбивается на три этапа. На первом этапе устанавливается соединение: инициируются переменные на обоих машинах и счетчики, отслеживающие какие кадры были приняты, а какие нет. На втором этапе один или несколько кадров передается. На третьем - соединение разрывается: переменные, счетчики, буфера и другие ресурсы, использованные для поддержки соединения, освобождаются.

На рис.3-2 показан типичный фрагмент WAN где два маршрутизатора соединены через телефонную линию. Когда кадр поступает в маршрутизатор, аппаратура проверяет контрольную сумму и передает кадр канальному уровню. Канальный уровень проверяет является ли поступивший кадр ожидаемым и если да, то передает пакет, расположенный в кадре, сетевому уровню на другой машине. Процесс на сетевом уровне выбирает надлежащую линию для передачи и посылает пакет на канальный уровень.

Не желательно на сетевом уровне заниматься пропажей кадров. Это задача канального уровня обеспечить надежный канал. Это особенно важно при беспроводной среде передачи.

3.1.2 Разбиение на кадры

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

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

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

Так как временные методы ненадежны, то применяются другие. Здесь мы рассмотрим четыре основных:

  1. счетчик символов
  2. вставка специальных стартовых и конечных символов
  3. вставка стартовых и концевых битов
  4. нарушение кодировки на физическом уровне

Первый метод показан на рис.3-3. В начало каждого кадра указывается сколько символов в кадре. При приеме число принятых символов подсчитывается опять. Однако, этот метод имеет существенный недостаток: счетчик символов может быть искажен при передаче. Тогда принимающая сторона не сможет обнаружить границы кадра. Даже обнаружив не совпадение контрольных сумм, принимающая сторона не сможет сообщить передающей какой кадр надо переслать, сколько символов пропало. Этот метод ныне используется редко.

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

Основным недостатком этого метода является то, что он жестко связан с размером байта и кодировкой ASCII. По мере развития сетей эта связь становилась все более и более обременительной.

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

Таким образом, кадр легко может быть распознан по флаг-байту. Если граница очередного кадра по какой-то причине была потеряна, то все что надо делать - ловить ближайший флаг-байт.

Последний метод используется там, где применяется специальная кодировка битов на физическом уровне. Например, для передачи одного бита используется два импульса. 1 кодируется как переход высокое-низкое, 0 - как низкое-высокое. Сочетания низкое-низкое или высокое-высокое не используются для передачи данных. Их то и используют для границ кадра. Так делают в стандарте IEEE 802 для ЛВС, который мы рассмотрим позже.

Наконец, на практике используют, как правило, комбинацию этих методов. Например, счетчик символов с одним из выше перечисленных. Тогда если число символов в кадру совпадает с кодировкой границы кадра, кадр считается переданным правильно.

3.1.3 Обнаружение ошибок

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

Для решения этой проблемы устанавливают обратную связь между отправителем и получателем в виде кадра подтверждения. Если кадр-подтверждение несет положительную информацию, то считается что переданные кадры прошли нормально, если там сообщение об ошибке, то переданные кадры надо передать заново.

Однако, возможны случаи когда из-за ошибок в канале кадр исчезнет целиком. В этом случае получатель не будет реагировать ни как, а отправитель будет сколь угодно долго ждать подтверждения. Для решения этой проблемы на канальном уровне вводят таймеры. Когда передается очередной кадр, то одновременно устанавливается таймер на определенное время. Этого времени должно хватать на то, чтобы получатель получил кадр, а отправитель получил подтверждение. Если отправитель не получит подтверждение раньше, чем истечет время, установленное на таймере, то он будет считать, что кадр потерян и повторит его еще раз.

Однако, если кадр-подтверждение был утерян, то вполне возможно, что один и тот же кадр получатель получит дважды. Как быть? Для решения этой проблемы каждому кадру присваивают порядковый номер. С помощью этого номера получатель может обнаружить дубли.

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

3.1.4 Управление потоком

Другой важной проблемой, которая решается на канальном уровне - управление потоком. Дело в том, что вполне может случиться, что отправитель будет слать кадры столь часто, что получатель не будет успевать их обрабатывать. Это может случиться если, например, машина-отправитель более мощная или загружена слабее, чем машина-получатель.

Для борьбы с такими ситуациями вводят управления потоком. Это управление предполагает обратную связь между отправителем и получателем, которая позволяет им урегулировать такие ситуации. Есть много схем управления потоком, но все они в основе своей используют следующий сценарий. Прежде чем отправитель начнет передачу он спрашивает у получателя сколько кадров тот может принять. Получатель сообщает ему определенное число кадров. Отправитель после того как передаст это число кадров, должен приостановить передачу и спросить получателя опять получателя опять как много кадров тот может принять и т.д. Позднее на конкретных примерах мы познакомимся с конкретными механизмами управления потоком.

3.2 Обнаружение и исправление ошибок

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

В разных средах характер ошибок разный. Ошибки могут быть одиночные, а могут возникать группами, сразу по несколько. У групповых ошибок есть свои достоинства и недостатки. Достоинство заключается в следующем. Пусть данные передаются блоками по 1000 бит, а уровень ошибки 0,001 на бит. Если ошибки изолированные и независимые, то практически каждый блок будет содержать ошибку в среднем. Если же они

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

3.2.1 Коды с исправлением ошибок

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

Пусть данные занимают m разрядов и мы добавляем r разрядов как контрольные разряды. Нам надо передать слово длины n, которое называют n-битовым кодословом. Пусть у нас есть два кодослова 10001001 и 10110001. С помощью операции EXCLUSIVE OR легко определить число различных разрядов. В данном случае их 3. Количество разных битов в двух кодословах называется расстоянием Хемминга. Поэтому если два кодослова находятся на расстоянии d по Хеммингу, это значит, что надо преобразовать ровно d разрядов, чтобы преобразовать одно кодослово в другое.

В силу избыточности не все 2n комбинаций возможны. Зная алгоритм установки контрольных разрядов, мы можем вычислить минимальное расстояние по Хеммингу между допустимыми кодословами. Способен код исправлять ошибки или только обнаруживать зависит от расстояния между его кодословами по Хеммингу. Если мы хоти обнаруживать d ошибок, то надо чтобы кодослова отстояли друг от друга на расстояние d+1. Тогда если принятый код отстоит на расстояние k <d, то принятое кодослово содержит k ошибок. Если мы хотим исправлять ошибки, то надо чтобы кодослова отстояли друг от друга на 2d+1. Поэтому даже если переданное кодослово содержит d ошибок, оно все равно ближе к правильному кодослову, чем к какому-либо еще, и следовательно можно определить, исходное слово.

Простым примеров кода с обнаружением одной ошибки является код с битом четности. Конструкция его такова: к исходному кодослову добавляется бит четности. Если число 1 в исходном кодослове четно, то значение этого бита 0. Если нечетно, то 0. Кодослова с битом четности имеют расстояние хемминга 2.

Для примера кода с исправлением ошибки рассмотрим код, у которого есть только четыре правильных кодослова: 0000000000, 0000011111, 1111100000, 1111111111. Расстояние по хеммингу у этого кода 5, следовательно он может исправлять двойные ошибки. Если получатель получит слово 0000000111, то ясно, что исходное слово имело вид 0000011111.

Оценим минимальное количество контрольных разрядов, необходимое для исправления одиночных ошибок. Пусть у нас есть код из m бит сообщения и r контрольных бит. Каждое из 2m правильных сообщений имеет n неправильных кодослов на расстоянии 1. Такими образом, с каждым из 2m сообщений связано n+1 кодослов. Так как общее число кодослов - 2n,то

(n+1)2m <= 2n, учитывая что n=m+r получаем

(m+r+1) <= 2r

Этот теоретический предел достижим при использовании метода, предложенного Хеммингом. Идея его в следующем: все биты, номера которых есть степень 2 (1,2,4,8,16 и т.д.) - контрольные, остальные - биты сообщения. Каждый контрольный бит отвечает за четность группы битов, включая себя. Один и тот же бит может относиться к разным группам. Значение бита сообщения определяется по значениям контрольных битов. Чтобы определить какие контрольные биты контролируют бит в позиции k надо представить значение k по степеням двойки. Например, 11= 1+2+8, 39=1+2+4+32.

Получив кодослово, получатель устанавливает специальный счетчик в ноль. Затем он проверят каждый контрольный бит на предмет правильности четности. Если четность нарушена, то порядковый номер этого бита заноситься в счетчик. Если после этой проверки счетчик ноль, то все в порядке. Если нет, то он содержит номер неправильного разряда. Например, 1, 2, 8 - ошибочные контрольные разряды, то ошибка в 11 разряде, так как только он связан одновременно с этими контрольными разрядами.

На рис.3-6 показан 7-разрядный ASCII код и соответствующий ему код хемминга.

Код хемминга может исправлять только единичные ошибки. Однако, есть прием, который позволяет распространить идеи Хемминга на случай групповых ошибок. Пусть нам надо передать k кодослов. Расположим их в виде матрицы одно слово - строка. Обычно, передают слово за словом. Но мы поступим иначе, передадим слово длины k, из 1-ых разрядов всех слов, затем - вторых и т.д. По приеме всех слов матрица восстанавливается. Если мы хотим обнаруживать групповые ошибки размера k , то в каждой строке восстановленной матрицы будет не более одной ошибки. А с одиночными ошибками код хемминга справиться.

3.2.2 Коды обнаруживающие ошибки

Начнем а небольшого примера. Пусть у нас есть канал с единичными ошибкой с частотой 10-6 на бит. Если мы хотим исправлять единичные ошибки при передаче блока в 1000 бит, то нам потребуется 10 контрольных бит. При передаче 1 Мбит данных, потребуется 10 000 контрольных бит. В тоже время для обнаружения единичной ошибки достаточно одного бита четности. Поэтому, если мы применим технику повторной передачи, то на передачу 1000 блоков надо будет потратить 1001 бит дополнительно или с повторной передачей 2002 бит, вместо 10,000 бит в случае кода с исправлением ошибки.

Применение техники четности "в лоб" в случае групповых ошибок не даст нужного результата. Однако, ее можно скорректировать. Пусть нам надо передать n слов по k бит. Расположим их в виде матрицы nk. Для каждого столбца вычислим бит четности и разместим его в дополнительной строке. Матрица затем передается по строкам. По получению матрица восстанавливается и если хоть один бит нарушен, то весь блок передается повторно.

Этот метод позволяет обнаружить групповые ошибки длины n. Против групповых ошибок длины n+1 он бессилен. В общем случае вероятность правильной передачи при длине групповой ошибке n, равна 2-n.

Поэтому на практике применяют другую технику, которая называется полиномиальными кодами или циклическим избыточным кодом (Cyclic Redundancy Code) или CRC кодом.

CRC коды построены на рассмотрении битовой строки как строки коэффициентов полинома. k битовая строка - коэффициенты полинома степени k-1. Самый левый бит строки - коэффициент при старшей степени. Например, строка 110001 представляет полином x5+x4+x0.

Полиномиальная арифметика выполняется по модулю 2. Сложение и вычитание происходит без переноса разрядов. Так, что обе это операции эквивалентны EXCLUSIVE OR. Например,

10011011 00110011 11110000 01010101
+11001010+11001101-10100110-10101111
-------- -------- -------- --------
01010001 11111110 01010110 11111010

Деление выполняется как обычно в двоичной системе с той лишь разницей, что вычитание выполняется по модулю два.

Использование полиномиальных кодов при передаче заключается в следующем. Отправитель и получатель заранее договариваются о конкретном генераторе полиномов G(x), у него коэффициенты при старшем члене и при младшем члене должны быть равны 1. Пусть степень G(x) равна r. Для вычисления контрольной суммы блока из m бит надо чтобы обязательно m>r. Идея состоит в том, чтобы добавить контрольную сумму к передаваемому блоку, рассматриваемому как полином М(х) так, чтобы передаваемый блок с контрольной суммой был кратен G(x). Когда получатель получает блок с контрольной суммой, он делит его на G(x). Если есть остаток, то были ошибки при передаче.

Алгоритм вычисления контрольной суммы:

  1. Добавить r нулей в конец блока так, что он теперь содержит m+r разрядов и соответствует полиному xrM(x);
  2. Разделить по модулю 2 полином xrM(x) на G(x);
  3. Вычесть остаток ( длина которого всегда не более r разрядов) из строки, соответствующей xrM(x), по модулю 2. Результат и есть блок с контрольной суммой ( назовем его Т(х)).

Рис.3-7 иллюстрирует этот алгоритм для блока 1101011011 и G(x) = х4+х+1.

Этот метод позволяет отлавливать одиночные ошибки. Групповые ошибки длины не более 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.3 Простейшие протоколы канала данных

Рассмотрение протоколов мы начнем с нескольких предположений, важных для представления модели функционирования. Будем предполагать, что физический уровень, уровень канала данных, сетевой уровень - это независимые процессы , взаимодействующие с помощью передачи сообщений. В некоторых случаях физический уровень и уровень канала данных могут выполняться на некотором вспомогательном процессоре ввода-вывода, внешнем по отношению к основному процессору: в некоторых случаях все процессы могут выполняться на основном процессоре. Возможны также разные реализации: Физический и канальный уровни могут быть реализованы в виде процедур, вызываемых сетевым уровнем и т.д. Однако, мы будем предполагать, что все три уровня представлены как наборы независимых процессов.

Мы также будем предполагать, что есть две машины А и В. У машины А есть бесконечно длинный набор данных, который надо передать машине В с помощью надежного сервиса, ориентированного на соединение. Передача всегда происходит от А к В, хотя позднее мы допустим одновременную передачу от В к А. Также будем предполагать, что если канальный уровень на машине А запрашивает данные для передачи от сетевого уровня, то они всегда есть и нет задержки на их подготовку.

Данные, которые канальный уровень получает от сетевого, рассматриваются им как данные, несмотря на то, что там есть заголовок сетевого уровня. Все эти данные должны быть переданы равнозначному сетевому уровню. Когда канальный уровень получает пакет, он погружает его в кадр, добавляя заголовок и концевик. Этот кадр затем передается по физическому уровню. Будем предполагать, что есть две библиотечные процедуры from_physical_layer - для получения кадра с физического уровня, и to_physical-layer - для передачи кадра на физический уровень. Предполагаем, что вычисление и добавление контрольных сумм происходит аппаратно.

Изначально получатель просто ожидает, ничего не делая, наступления какого-либо события. В наших примерах это будет выражаться в вызове процедуры wait_for_event(&event), где параметр event возвращает информацию о произошедшем событии. Ясно, что в действительности никто не будет ожидать в цикле, будут использованы прерывания, но мы для простоты будем считать так.

Когда кадр поступает к получателю, контрольная сумма вычисляется аппаратно. Если она неверна, то канальному уровню сообщается об этом event=cksum_err. Если кадр поступил без повреждений, то канальный уровень информируется об этом - event=frame_arrivel.

На рис.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 Симплекс старт стопный протокол

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

Основная проблема здесь как предотвратить ситуацию когда отправитель "заваливает" данными получателя. Если получателю требуется время чтобы исполнить from_physical_layer плюс to_network_layer , то отправитель
должен передавать данные со средней скоростью один кадр в D t

Решением такой проблемы может быть введение специальных коротких служебных сообщений. Получатель, получив один или несколько кадров, отправляет отправителю специальный короткий кадр, означающий, что отправитель может передавать следующий. Это , так называемый старт-стопный протокол, показанный на рис.3-10.

3.3.3 Симплексный протокол для канала с шумом

Основная проблема здесь состоит в том, что кадр с подтверждением о получении может потеряться целиком. Как отличить кадр, переданный первый раз, от переданного повторно?

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

На рис.3-11 показана программа для этого варианта протокола.

3.4 Протоколы скользящего окна

В рассмотренных выше протоколах канального уровня кадры передавались только в одном направлении. Для передачи в обоих направлениях можно потребовать на физическом уровне двух сиплексных каналов. Один для передачи кадров, другой - для передачи подтверждений. Однако, использование канала только для подтверждений довольно дорогое удовольствие. Можно смешивать трафик: кадры с данными и кадры с подтверждениями на одном канале. Это конечно решение проблемы, но по прежнему на подтверждения тратиться полезная пропускная способность канала.

Идея, а что если для подтверждения использовать полезные кадры с данными. Получатель не сразу отправляет подтверждение, а ожидает от сетевого уровня очередного пакета. Как только такой пакет возникает, то канальный уровень в кадр с пакетом также помещает информацию о подтверждении в поле ack . Такой прием позволяет полнее использовать имеющуюся пропускную способность канала. Меньше кадров - меньше прерываний канального уровня на их обработку, меньше затрат на буферизацию.

Однако, применение этой идеи усложняет протокол. Дело в том, что делать если time_out заканчивается и отправителя на получения подтверждения, а с сетевого уровня получателя не поступает запроса на передачу пакета? Поэтому на канальном уровне должен быть фиксированный интервал времени, в течение которого канальный уровень ждет от сетевого попутного кадра. Если до истечении этого срока пакет не поступил, то канальный уровень отправляет подтверждение отдельным кадром.

Рассмотренный здесь протокол является представителем класса протоколов скользящего окна. Протоколы этого класса кроме вышеперечисленных проблем решают еще одну. У отправителя и получателя есть определенная константа n - число кадров, которое отправитель может послать без ожидания подтверждения каждого. По мере получения подтверждений, отправленные кадры будут сбрасываться из буфера отправителя и буфер будет пополняться новыми.

Мы уже сталкивались с подобными протоколами - пример, старт-стопный протокол. Там n равно 1. Обычно n=2k-1. У получателя и отправителя есть набор последовательных чисел - номеров для кадров, которые отправитель может отправить, не ожидая подтверждения каждого. Эти кадры образуют окно отправки. Аналогично, у получателя есть буфер для получения и временного хранения получаемых кадров - окно получения.

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

Рис. 3-12 показывает работу такого протокола для n=1 в форме диаграммы.

На рис.3-13 показан текст протокола для этого простейшего случая. Как и все он начинается с определения переменных. Есть два случая: простой и наиболее удобный, когда только один из канальных уровней первым начинает передачу.

Случай когда оба канальных уровня начинаю передачу одновременно показан на рис.3-14 b. Там возникает много повторных передач одного и того же кадра.

До сих пор мы предполагали, что время доставки кадра и время доставки подтверждения пренебрежимо малы. В некоторых случаях это предположение очевидно не работает. Оно может приводить к серьезным бесполезным тратам пропускной способности канала. Рассмотрим пример, спутниковый канал на 50-Kbps с общей задержкой 500 mсек. Пусть мы хотим использовать протокол 4 для передачи кадров размера 1000 бит. В момент =0 отправитель отправляет первый кадр. В =20mсек кадр полностью отправлен, в =270mсек он принят и в =520mсек отправитель получил подтверждение. Эти цифры говорят о том, что отправитель был блокирован в течении 500/520, т.е. 96% времени. А это - потеря пропускной способности канала.

Эта проблема есть следствие правила, по которому отправитель ждет подтверждения прежде, чем пошлет следующий кадр. Это требование можно ослабить - разрешить отправителю отправлять до w кадров, не ожидая их подтверждения. Надлежащим выбором значения w отправитель может заполнить все время, необходимое на оправку кадра и получение его подтверждения. В вышеприведенном примере w должно быть по крайней мере 26. Это как раз то количество кадров, какое отправитель успеет отправить за 520 mсек. прежде, чем придет подтверждение на кадр 0. Таким образом, неподтвержденными будут 25 из 26 кадров, окно отправителя будет на 26 кадров.

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

Есть два приема для решения этих вопросов: откат и выборочный повтор. При откате все кадры, поступившие после поврежденного, сбрасываются и не подтверждаются. Отправитель по timeout повторно пошлет все кадры, начиная с не подтвержденного. Этот подход показан на рис.3-15 (а). В этом подходе окно у получателя длины 1.

При выборочном повторе у получателя окно длины как и у отправителя. Отправитель отмечает не подтвержденный кадр и перепосылает его. Получатель не передает на сетевой уровень последовательность пакетов, если в ней есть разрывы. Этот подход показан на рис.3-15 b).

3.5 Примеры протоколов канала данных

3.5.1 HDLC протокол

Здесь мы познакомимся с группой протоколов давно известных, но по-прежнему широко используемых. Все они имеют одного предшественника - 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 - указывает на повреждение управляющего кадра (например, контрольная сумма верная, а вот значения полей противоречивы).

3.5.2 Уровень канала данных в Internet

Здесь мы рассмотрим протоколы, которые используются для каналов точка-точка в Internet. Соединения точка точка-точка возникают между маршрутизаторами в Internet. Вторая часто встречающаяся ситуация для таких соединений - соединение из дома через модем с сервис провайдером в Internet. Эта ситуация показана на рис.3-26.

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

3.5.3 SLIP - Serial Line IP

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

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

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

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

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

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

3.5.4 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) на каждом поддерживаемом сетевом уровне.

Для того, чтобы лучше понять как это все работает вместе давайте рассмотрим типичный сценарий когда пользователь из дома по телефонной линии хочет подключить свой РС к 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 байт.

На диаграмме 3-28 показаны основные фазы установления соединения и его разрыв.

В таблице 3-29 приведены 11 типов LCP пакетов, допустимые по протоколу RFC 1661.

3.5.5 Frame Relay


3.5.6 Уровень канала данных в ATM.

Теперь вернемся к уровням АТМ протокола. Физический уровень в АТМ покрывает физический уровень и уровень канала данных в OSI. Поскольку АТМ физический уровень на подуровне физической зависимости не предъявляет каких-то специальных требований к физической среде, то мы сосредоточим наше внимание на ТС подуровне - подуровне преобразования при передаче.

Когда прикладная программа посылает сообщение, оно движется вниз по АТМ стеку, получая заголовки, концевики, разбивается на ячейки и т.д. Проследим что с ним происходит когда ячейки достигают ТС подуровня и далее.

Передача ячеек.
Первый шаг - вычисление контрольной суммы заголовка. Заголовок состоит из 5 байт - 4 байта идентифицируют виртуальное соединение и несут контрольную информацию, за ними следует 1 байт с контрольной суммой. Контрольная сумма защищает только первые четыре байта и не затрагивает данные в payload. Контрольная сумма вычисляется как остаток от деления содержимого 4 байтов на полином x8+x2+x+1. К этому остатку добавляется константа 01010101 для повышения надежности в случае если заголовок содержит много нулей.

Решение защищать контрольной суммой только управляющую информацию было принято с целью сократить затраты на обработку на нижних уровнях. Защиту собственно данных возложена на верхние уровни если это необходимо. Как мы уже отмечали для многих приложений реального времени - передача видео, аудио данных более критична к времени передачи, чем к степени искажения отдельных ячеек. Поскольку контрольная сумма покрывает только заголовок, то этот байт так и называется HEC - Header Error Control.

Другим важным фактором повлиявшим на выбор этой схемы контрольной суммы было то, что основной средой для АТМ является оптоволокно. Исследования АТ&Т показали, что оптоволокно высоконадежная среда и в ней происходят с частотой 99.64% единичные ошибки. Схема НЕС прекрасно справляется как с одно битными ошибками, так и множественными.

Для надежной передачи ячеек Шачем и Макинни предложили схему когда два последовательные ячейки объединяются через EXCLUSIVE OR, получается новая ячейка, которая добавляется в последовательность после первых двух. В результате если хоть одна ячейка была принята с ошибкой или потеряна, то она легко может быть восстановлена.

После того как НЕС вычислен и добавлен в заголовок, ячейка готова к передаче. Среда передачи может быть двух категорий - синхронной и асинхронной. При асинхронной среде ячейка посылается сразу как только она готова к передаче. При синхронной среде ячейка передается в соответствии с временными соглашениями. Если нет ячейки для передачи, то ТС подуровень должен сгенерировать специальную ячейку ожидания.

Другой вид служебных ячеек - OAM (Operation And Maintenance). Эти ячейки используются АТМ переключателями для проверки работоспособности системы.

Ячейки ожидания обрабатываются соответствующим ТС подуровнем, а вот ОАМ ячейки передаются на АТМ уровень.

Другой важной функцией ТС подуровня - генерирования ячеек в формате физической среду передачи. То есть ТС подуровень генерирует обычную АТС ячейку и упаковывает ее в кадр надлежащей среды передачи.

Прием ячеек
Итак, на выходе ТС подуровень формирует НЕС заголовок, преобразует ячейку в кадр, формирует ОАМ ячейки и передает поток битов на физический уровень. На противоположном конце ТС подуровень производит те же самые действия, но в обратном порядке: разбивает поток бит на кадры, выделяет ячейки, проверяет НЕС заголовки и передает ячейки на АТМ уровень.

Самое трудное - выделить кадр из потока битов. На уровне битов ячейка - это 53х8 = 424 бита. Нет маркеров ни начала ни конца кадра. Как определить границы кадра?

На ТС подуровне есть сдвиговый регистр на 40 бит. Если в этих 40 бит правые 8 представляют НЕС, то последующие 32 левых бита - заголовок ячейки. Если условие не выполнено, то все сдвигает на один бит и проверка повторяется. Этот процесс продолжается до тех пор, пока не будет обнаружен НЕС.

Эта схема распознавания в том виде, как она описана не надежна. 1/256 вероятность что случайный байт будет выглядеть как НЕС. Чтобы исправить эту схему используют автомат, схема состояний которого изображена на рис.3-30. Есть три состояния: HUNT, PRESYNCH, SYNCH/ В состоянии HUNT ищется НЕС. Как только найден похожий байт, автомат переходи в состояние PRESYNCH и отчитывает следующие 53 байта. Если предположение о том, что найденный НЕС - начало ячейки, то сдвиг на 53 байта приведет к следующему НЕС. Происходит проверка последовательно ячеек, после этого происходит переход в состояние SYNCH.

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

[Наверх: в начало разделаНазад: Концептуальные основы АТМВперед: DNS (Domain Name System)Здесь: Канальный уровень]