1 (1131253), страница 21
Текст из файла (страница 21)
Разряд 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 указывает на повреждение управляющего кадра (например, когда контрольная сумма верна, а значения полей противоречивы).
Frame Relay.
Ретрансляция кадров (Frame Relay, FR) - это метод доставки сообщений в сетях передачи данных (СПД) с коммутацией пакетов. Первоначально разработка стандарта FR ориентировалась на цифровые сети интегрированного обслуживания (ISDN - Integrated Services Digital Networks), однако позже стало ясно, что FR применим и в других СПД (здесь под данными понимается любое сообщение, представленное в цифровой форме). К числу достоинств рассматриваемого метода прежде всего необходимо отнести малое время задержки, простой формат кадров, содержащих минимум управляющей информации, и независимость от протоколов верхних уровней модели OSI.
В настоящее время разработкой и исследованием стандартов FR занимаются три организации: Frame Relay Forum (FRF) - международный консорциум, включающий в себя свыше 300 поставщиков оборудования и услуг, American National Standards Institute (ANSI, Американский национальный институт по стандартизации), Международный союз электросвязи (ITU-T).
В январе 1992 г. этот проект стандарта, включающего в себя спецификации ANSI, которые обязательны для выполнения членами FRF, был доработан Техническим комитетом FRF и утвержден собранием членов FRF.
FR является бит-ориентированным синхронным протоколом и использует кадр в качестве основного информационного элемента - в этом смысле он очень похож на протокол HDLC. Однако FR обеспечивает не все функции протокола HDLC. Многие элементы кадра HDLC исключены из основного формата кадра FR (в последнем адресное поле и поле управления HDLC совмещены в едином адресное поле), что привело к сокращению набора функций в этом протоколе.
Рисунок 3-18. Структура и формат кадра Frame Relay
Структура кадра FR (рисунок 3-18) включает в себя следующие элементы:
-
Флаг. Все кадры начинаются и заканчиваются комбинацией "флаг": "01111110".
-
Заголовок:
-
Адрес в пределах кадра 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. Установка бит перегрузки
-
Информационное поле содержит данные пользователя и состоит из целого числа байтов. Его максимальный размер определен стандартом FRF и составляет 1600 байтов (минимальный размер - 1 байт), но возможны и другие максимальные размеры (вплоть до 4096 байтов). Содержание информационного поля пользователя передается неизменным.
-
Проверочная последовательность кадра (Frame Check Sequence - FCS) используется для обнаружения возможных ошибок при его передаче и состоит из двух байтов. Данная последовательность формируется аналогично циклическому коду HDLC.
Все указанные поля должны присутствовать в каждом кадре FR, который передается между двумя оконечными пользовательскими системами.
Одним из основных отличий протокола FR от HDLC является то, что он не предусматривает передачу управляющих сообщений (нет командных или супервизорных кадров, как в HDLC). Для передачи служебной информации используется специально выделенный канал сигнализации. Другое важное отличие - отсутствие нумерации последовательно передаваемых (принимаемых) кадров. Дело в том, что протокол FR не имеет никаких механизмов для подтверждения правильно принятых кадров.
Протокол FR является весьма простым по сравнению с HDLC и включает в себя небольшой свод правил и процедур организации информационного обмена. Основная процедура состоит в том, что если кадр получен без искажений, он должен быть направлен далее по соответствующему маршруту. При возникновении проблем, связанных с перегрузкой сети FR, ее узлы могут сбрасывать любой кадр.
Узлам сети FR разрешено уничтожать искаженные кадры, не уведомляя об этом пользователя. Искаженным считается кадр, которому присущ какой-либо из следующих признаков:
-
Нет корректного ограничения флагами.
-
Имеется менее пяти байтов между флагами.
-
Нет целого числа байтов после удаления бит обеспечения прозрачности.
-
Присутствует ошибка контрольной суммы.
-
Искажено поле адреса (для случая, когда проверка не выявила ошибки в FCS).
-
Содержится несуществующий DLCI.
-
Превышен допустимый максимальный размер (в некоторых вариантах реализации стандартов FR возможна принудительная обработка кадров, превышающих допустимый максимальный размер).
Для FR характерно:
-
заполнение канала связи комбинацией «флаг» при отсутствии данных для передачи
-
резервирование одного DLCI для интерфейса локального управления и сигнализации
-
содержание поля данных пользователя в любом кадре не должно подвергаться какой-либо обработке со стороны аппаратуры канала данных (могут обрабатываться лишь данные в локальном канале управления)
Управление доступом к сети 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) - при возможном снижении качества передачи данных
Предварительные соглашения реализуются следующим образом.
-
Абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для фиксированного виртуального соединения (PVC).
-
Узел доступа к сети FR измеряет «реальную потребность абонента» в ресурсе пропускной способности канала связи.
-
Если этот ресурс (выраженный реальной скоростью передачи информации) не превышает CIR, то кадры передаются без изменений. Если требуемая скорость превышает CIR, но соответствует пропускной способности порта, то бит DE устанавливается в «1», что дает возможность удалять соответствующие кадры при возникновении перегрузок (абонент также имеет право решать, какие кадры для него менее важны). Наконец, если превышена пропускная способность порта, кадры уничтожаются вне зависимости от каких-либо условий.
Абонент способен воспользоваться предварительным соглашением и для того, чтобы уменьшить свои затраты следующим оригинальным способом. Некоторые операторы сетей (поставщики услуг) предлагают значительные скидки при передаче кадров с битом DE, установленным в «1». При наличии в сети значительного запаса пропускной способности абонент может установить гарантированную скорость передачи, равную нулю. В этом случае во всех передаваемых кадрах бит DE будет установлен в «1».
Билет № 24.
Проблемы передачи данных на канальном уровне (Сервис, предоставляемый сетевому уровню, Разбиение на кадры, Контроль ошибок, Управление потоком). Примеры протоколов канального уровня в Internet (протоколы SLIP, PPP, Уровень канала данных в АТМ).
Рассмотрим протоколы, которые используются для каналов «точка-точка» в Интернете. На уровне канала данных соединения «точка-точка» возникают между маршрутизаторами либо коммутирующими элементами в СПД. Другой часто встречающийся случай для таких соединений - соединение из дома через модем с интернет-провайдером.
Для упомянутых выше соединений: «маршрутизатор-маршрутизатор» и «хост-маршрутизатор» через телефонную линию было предложено два протокола: SLIP и PPP.
SLIP - Serial Line IP.
SLIP - наиболее старый из этих двух протоколов. Он был создан в 1984 году для соединения рабочих станций SUN через модем. Этот протокол был описан в RFC 1055. Его работа очень проста: он вставляет специальные флаг-байты в начало и конец IP-пакета.
Последние версии этого протокола осуществляют также сжатие заголовков TCP и IP у последовательных пакетов, так как они несут очень много одинаковой информации. Одна из последних версий этого протокола описана в RFC 1144.
SLIP имеет ряд серьезных недостатков - он не занимается контролем и исправлением ошибок, оставляя это протоколам верхних уровней. Во-вторых, он работает только с IP-пакетами. В современных условиях, когда Интернет объединяет самые разнообразные сети, это серьезный недостаток.
В-третьих, IP-адреса взаимодействующих сторон должны быть известны заранее. В условиях нехватки IP-адресов это недостаток, так как было бы удобнее задавать IP-адрес динамически, лишь на период действия соединения.
В-четвертых, этот протокол не обеспечивает какой-либо проверки аутентичности взаимодействующих сторон. Так что вы не можете быть уверены, с кем вы общаетесь.















