1 (1131253), страница 22

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

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

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

PPP - протокол «точка-точка».

Чтобы исправить указанные выше недостатки, комитет IETF (Internet Engineering Task Force) создал группу, которой было поручено разработать новый протокол. В результате ее усилий появился протокол РРР (Point-to-Point Protocol). Протокол РРР обеспечивает обнаружение ошибок, поддерживает разные протоколы, позволяет динамически выделять IP-адрес только на период соединения, выполняет аутентификацию абонентов и имеет ряд других преимуществ перед SLIP.

Протокол РРР обеспечивает три основных функции:

1. Распознавание кадров. Однозначно определяется конец кадра и начало нового. Здесь же происходит обнаружение ошибок.

1. Управление линией, т.е. активизация линии, ее проверка, определение основных параметров передачи в диалоге, корректное завершение передачи со сбросом параметров. Этот протокол называет LCP (Link Control Protocol).

1. Определение основных параметров соединения между сетевыми уровнями, чтобы обеспечить независимость от реализации сетевого уровня. Выбранный метод предполагает наличие разных NCP (Network Control Protocol) на каждом поддерживаемом сетевом уровне.

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

После этого следует обмен NCP-пакетами для настройки сетевого уровня. В частности, здесь происходит временное присваивание РС IP-адреса, который действует только на период соединения. Это происходит, если обе стороны хотят использовать TCP/IP-стек.

Теперь, когда РС стала полноправной машиной в Интернете, она может обмениваться IP-пакетами с другими машинами. Когда пользователь закончит работу, NCP разрывает соединение с сетевым уровнем и освобождает ранее занятый IP-адрес. После этого LCP-протокол разрывает соединение на канальном уровне. А затем компьютер говорит модему: «Положи трубку».

РРР-кадры имеют формат, очень близкий к HDLC-кадрам. Основное различие состоит в том, что РРР - байт-ориентированный, а HDLC - бит-ориентированный. Для HDLC возможен кадр размером в 30,25 байт, а для РРР - нет.

Рисунок 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-23. Типы LCP-пакетов, допустимых по протоколу RFC 1661

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3-24. Процедура поиска ячеек

Билет № 25.

Протоколы множественного доступа к каналу (динамическое vs статическое выделение канала). Модель системы ALOHA. Сравнение производительности систем: чистая ALOHA, слотированная ALOHA. Протоколы множественного доступа с обнаружением несущей (настойчивые и не настойчивые CSMA, CSMA с обнаружением коллизий).

ALOHA.

В 70-х годах Норман Абрамсон (Norman Abramson) со своими коллегами из университета Гавайи предложил простой способ распределения доступа к каналу. Абрамсон назвал систему, реализующую этот способ распределения канала, ALOHA, что по-гавайски означает что-то вроде «привет». Система состояла из наземных радиостанций, связывающих острова между собой. Идея была позволить в вещательной среде любому количеству пользователей неконтролируемо использовать один и тот же канал.

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

Чистая ALOHA.

Идея чистой ALOHA проста - любой пользователь, желающий передать сообщение, сразу пытается это сделать. Благодаря тому, что в вещательной среде он всегда имеет обратную связь, т.е. может определить, пытался ли кто-то еще передавать на его частоте, то он может установить возникновение конфликта при передаче. Такая обратная связь в среде LAN происходит практически мгновенно, в системах спутниковой связи задержка составляет около 270 мсек. Обнаружив конфликт, пользователь ожидает некоторый случайный отрезок времени, после чего повторяет попытку. Интервал времени на ожидание должен быть случайным, иначе конкуренты будут повторять попытки в одно и то же время, что приведет к их блокировке. Системы подобного типа, где пользователи конкурируют за получение доступа к общему каналу, называются системами с состязаниями.

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

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

Назовем временем кадра время, необходимое на передачу кадра стандартной фиксированной длины. Предполагаем, что число пользователей неограниченно, и они порождают кадры по закону Пуассона со средним S кадров за время кадра. Поскольку при S>1 очередь на передачу будет только расти и все кадры будут страдать от коллизий, то мы будем предполагать 0<S<1.

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

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