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

Основная задача канального уровня - обеспечить сервис сетевому уровню. Назначение этого сервиса - помочь передать данные от процесса, на сетевом уровне одной машины, процессу, на сетевой уровень другой машины. Как это происходит показано на рис.3-1 а. Фактически передача будет происходить так, как показано на рис.3-1 b. Однако, для простоты изложения мы будем считать, что это происходит как на рис.3-1а.

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

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

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

Сервис с уведомлением и с соединением.

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

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

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

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

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

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

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

 

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

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

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

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

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

счетчик символов

вставка специальных стартовых и конечных символов

вставка стартовых и концевых битов

нарушение кодировки на физическом уровне

Первый метод показан на рис.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 для ЛВС, который мы рассмотрим позже.

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

 

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

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

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

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

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

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

 

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

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

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

 

Протоколы канала данных