Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 18)

Первоначально предполагалось организовать связь через два КА отечественного производства «Купон», первый из которых был выведен на орбиту в конце 1997 г. Однако отказ первого КА после четырех месяцев работы (сбой в системе частотообразования) радикально изменил ситуацию. ЦБ РФ решил приостановить работы по разработке собственных КА и арендовать частотный ресурс на других спутниках (таблица 2-81). В настоящее время заключено соглашение с международной организацией Intelsat на предоставление частотной емкости КА lntelsat-704 (три ствола) для сетей «Банкир-1» и «Банкир-2», а частотный ресурс для сети «Банкир-3» арендуется на отечественных КА «Горизонт-33» и «Ямал-100».

Система С2 «Банкир» предоставляет следующие услуги: передача данных по протоколам Frame Relay и Х.25; телефонная связь через учрежденческие АТС; проведение видеоконференций. Передача данных (электронные платежи) осуществляется через спутник: на магистральном уровне (между ЦЗС и УЗС) – каналы FDMA/SCPC/PAMA (скорость 256 кбит/сек.), на региональном уровне (между УЗС и АЗС) – каналы FDMA/SCPC/PAMA (скорость 64 кбит/сек.) и FDMA/TDM, FDMA/TDMA (скорость 128 и 64 кбит/сек.). Для передачи речи используется спутниковый канал FDMA/SCPC/DAMA (скорость 16 кбит/с). Сегодня состояние сети ЦБ таково:

• Развернуто 47 региональных подсистем, установлено около 600 ЗС для ССС «Банкир-1», «Банкир-2» и «Банкир-3» (50% от общего числа).

• Находится в эксплуатации 27 региональных подсистем, около 300 ЗС подсетей «Банкир-1» и «Банкир-3» (50% от числа развернутых и 25% от общего числа). Полное развертывание сетей «Банкир-1» и «Банкир-3» завершилось в 2001 г., а сети «Банкир-2» — в конце 2001 г.

Билет № 20.

Проблемы передачи данных на канальном уровне (Сервис, предоставляемый сетевому уровню, Разбиение на кадры, Контроль ошибок, Управление потоком). Простейшие протоколы канала данных (Симплекс протокол без ограничений, Симплекс старт стопный протокол, Симплексный протокол для канала с шумом).

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

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

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

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

Рисунок 3-1. Передача данных - виртуальная (a), фактическая (b)

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

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

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

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

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

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

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

Наиболее сложный класс сервиса на канальном уровне - сервис с соединением и уведомлением. Этот класс сервиса предполагает, что до начала передачи между машинами устанавливают соединение и данные передают по этому соединению. Каждый передаваемый кадр нумеруется, и канальный уровень гарантирует, что он будет обязательно получен, причем только один раз, а также что все кадры будут получены в надлежащей последовательности. При сервисе без соединения этого гарантировать нельзя, потому что потеря подтверждения получения кадра приведет к его пересылке, что, в свою очередь, приведет к появлению нескольких идентичных кадров. Использование сервиса с соединением особенно полезно в том случае, когда канал образует СПД. Как мы уже видели, в СПД может быть достаточно сложная организация канала, при которой может происходить коммутация потоков данных самыми разными способами. Здесь полезно вспомнить структуру кадра в Х.25, рассмотренную в разделе 2.3. С точки зрения структуры, в Х.25 есть три вида кадров: с 3-битовым полем номера кадра, 7- и 12-битовым. Таким образом, в Х.25 предусмотрен сервис с соединением, причем, в зависимости от длины передаваемых данных, можно оптимизировать затраты на поддержку соединения.

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

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

Рисунок 3-2. Размещение протокола канального уровня

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

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

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

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

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

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

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

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

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

Первый метод (счетчик символов)показан на рисунке 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. Обнаружение ошибок

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

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

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

Если отправитель не получит уведомление раньше, чем истечет время, установленное на таймере, то он будет считать, что кадр потерян и повторит его еще раз.

Характеристики

Список файлов ответов (шпаргалок)