- •Содержание
- •Введение
- •5. Основные сведения о сетях ip
- •5.1. Многоуровневая модель tcp/ip
- •5.1.1. Network Access Layer (Уровень доступа к среде передачи)
- •5.1.2. Internet Layer (Межсетевой уровень) и протокол ip
- •5.1.3. Протокол icmp
- •5.1.4. Transport Layer (Транспортный уровень)
- •5.1.5. Протокол udp
- •5.1.6. Протокол tcp
- •5.2.1. Классовая модель
- •5.2.2. Бесклассовая модель
- •Запись адресов в бесклассовой модели
- •5.2.3. Установка ip-адреса хоста
- •5.3. Маршрутизация
- •5.3.1. Пример маршрутизации
- •5.3.2. Пример подключения локальной сети организации к Интернет
- •5.3.3. Динамическая маршрутизация
- •5.3.4. Перечень задач по подключению сети предприятия к Интернет
- •5.4. Работа с утилитами tcp/ip
- •5.4.1. Основные утилиты tcp/ip
- •5.4.2. Поиск информации об ip-сетях и автономных системах (служба whois)
- •5.5. Динамическое присвоение ip-адресов
- •5.6. Получение информации из баз данных dns
- •5.6.1. Конфигурирование клиента dns
- •5.6.2. Порядок выполнения dns-запроса
- •5.6.3. Программа nslookup
- •6. Ретрансляция кадров (Frame Replay). Характеристики протокола информационного обмена и интерфейса «пользователь-сеть»
- •6.1. Логическая характеристика протокола fr
- •6.2. Процедурная характеристика протокола fr
- •6.3. Адресация в сетях fr
- •6.4. Общая характеристика lmi
- •6.5. Логическая характеристика lmi
- •6.6. Процедурная характеристика lmi
- •6.6.1. Синхронное симплексное управление
- •6.6.2. Синхронное дуплексное управление
- •6.6.3. Асинхронное управление
- •6.6.4. Процедурная характеристика lmi при возникновении ошибок
- •6.7. Параметры для синхронизации процедур управления lmi
- •7. Ретрансляция кадров (Frame Relay). Характеристики интерфейса «сеть - сеть» и коммутируемых виртуальных каналов
- •7.2. Коммутируемые виртуальные каналы
- •7.2.1. Фаза установления соединения (запрос соединения)
- •7.2.2. Параметры канального уровня
- •7.2.3. Фаза установления соединения (подтверждение вызова и соединения)
- •7.2.4. Фаза разъединения
- •8. Интеграция fr сетей
- •8.1. Характеристика fr протокола для интеграции сетей, функционирующих по различным сетевым протоколам
- •8.2. Интеграция fr и х.25 сетей
- •8.3. Ретрансляция кадров и речевой трафик
- •9. Организация доставки сообщений в широкополосных цифровых сетях интегрального обслуживания (атм - Asynchronous Transfer Mode)
- •9.1. Широкополосная цифровая сеть интегрального обслуживания (ш1-1сио, b-isdn - Broadband Integrated Services Digital Network)
- •9.2. Асинхронный режим доставки
- •9.3. Эталонная модель шисио
- •9.4. Процедурная и логическая характеристики протокола ард
- •9.5. Управление доступом
- •9.6. Идентификаторы виртуального пути и виртуального канала
- •9.7. Служба приоритетов
- •9.8. Зашита заголовка ячейки ара (циклическая проверка)
- •9.9. Принципы информационного обмена и синхронизация в ара
- •10. Сравнение сетевых архитектур
- •10.1. Требования к современным компьютерным сетям
- •10.2. Примеры сетевых архитектур
- •10.3. Методика оценки сетевых архитектур
- •10.4. Корреляционный анализ
- •10.5. Совместная обработка изображений
- •10.6. Моделирование окружающей среды
- •10.7. Построение сетей
- •Список использованных источников
6.6.2. Синхронное дуплексное управление
При ССУ, одностороннем по своей природе, ответственность за генерацию сообщения "Запрос состояния" лежит полностью на ООД пользователя, а за генерацию сообщения "Состояние" - на АКД сети. Такая процедура приемлема для многих приложений, однако предпочтительнее, что5а эта процедура была сбалансирована между двумя сторонами интерфейса LMI и каждая из сторон могла поддерживать параметры противоположной стороны, а также требуемый коэффициент готовности.
СДУ - необязательная часть стандарта FR и может использоваться только при обоюдном соглашении сторон (абонент - сеть). Очевидно СДУ будет наиболее актуальным при взаимодействии коммутаторов FR или различных сетей FR (через интерфейс межсетевого взаимодействия "Network-Network Interface" - NNI), так как обеим сетям "нужна возможность опроса" другой.
СДУ отличается от ССУ только в одном: сообщения "Запрос состояния" и "Состояние" имеют право передавать обе стороны интерфейса.
При СДУ обе стороны интерфейса FR передают сообщение "Запрос состояния" через определенный интервал (Т391), обе "требуют" ответ - сообщение "Состояние" (Т392), а также запрашивают информацию о полном состоянии (N391). При использовании этих процедур обе стороны могут запрашивать различные параметры. Вместе с тем обе стороны "ведут учет" номеров принимаемых и передаваемых кадров для каждого направления.
6.6.3. Асинхронное управление
Главный недостаток ССУ и СДУ - потенциальная задержка информирования ООД пользователя (или сети) об изменениях сетевых ПВК. Например, при задержке 60 с и CIR, равной 64 Кбит/с, ООД пользователя "направит" в сеть приблизительно 3,5 Мбит данных до того, как получит информацию о состоянии ПВК.
По этой причине была предложена стратегия АУ, когда используются стандартные сообщения "Запрос состояния" и "Состояние", которые могут передаваться сразу в случае изменения ПВК сети FR. Эти сообщения содержат информацию только об отдельных ПВК, которые изменили свое состояние. Проверка целостности соединения также основана на генерации последовательности специальных пронумерованных кадров и проверке корректности этой последовательности с помощью специального процесса.
АУ может использоваться совместно с ССУ и СДУ. Однако, когда в сети FR применяются одновременно КВК и ПВК, то рекомендуется использовать только АУ.
6.6.4. Процедурная характеристика lmi при возникновении ошибок
Интерфейс локального управления предназначен для передачи минимального количества управляющей информации, чтобы гарантировать нормальное функционирование интерфейса FR. Вместе с тем существуют и специальные процедуры управления при возникновении следующих возможных ошибок в интерфейсе FR (обнаруживаемых сетью):
прием кадра LMI о целостности соединения с неправильным порядковым номером принятого кадра (не равен порядковому номеру последнего переданного кадра);
неприем сообщения "Запрос состояния" по истечении тайм-аута (этот интервал имеет международное обозначение - Т392 и всегда должен быть больше, чем Т391);
прием кадра LMI с ошибкой FCS.
В этих случаях АКД сети FR в сообщении "Состояние" устанавливает бит "активный ПВК" в "0", указывая тем самым временную неготовность канала. Когда ошибка устранена, АКД сети устанавливает бит "активный ПВК" в "1". Однако данные действия АКД сети происходят не сразу при возникновении ошибок, а только при превышении установленного «порога». Этот порог определяется протоколом FR. Сеть осуществляет подсчет ошибок (максимальное значение этого числа имеет международное обозначение - N392), возникающих в пределах установленного периода (этот интервал имеет международное обозначение N393). Если за интервал N393 порог N392 превышен, то АКД сети переводит ПВК в неактивное состояние. Выход из него - получение сетью безошибочного сообщения "Запрос состояния".
Оборудование пользователя может также обнаруживать следующие возможные ошибки:
прием кадра LMI о целостности соединения с неправильным порядковым номером принятого кадра (не равен порядковому номеру последнего переданного кадра);
неприем сообщения "Состояние" по истечении интервала вр Т391 после передачи сообщения "Запрос состояния";
прием кадра LMI с ошибкой FCS.
Действия ООД пользователя аналогичны действиям АКД сети, в основе которых лежит тот же самый пороговый принцип: когда за интервал N393 порог N392 превышен, ООД пользователя прекращает передачу. Выход из него - передача ООД абонента сообщения "Запрос состояния".
Однако стандарт FR не вводит процедур, на основе которых однозначно определяется, что ошибочная ситуация устранена и ООД абонента может передать сообщение "Запрос состояния". Существует лишь одна возможность определения устранения ошибки, когда N392 событий происходят без ошибки. Необходимо также обратить внимание на то, что невозможно обнаружить ошибки в пределах отдельного ПВК интерфейса FR, то есть ошибки затронут все сконфигурированные ПВК.
Окончанием ошибочных ситуаций, которые могут произойти в LMI, являются:
получение сообщения о состоянии ПВК для существующих ПВК (и для которых бит "новый ПВК" в кадрах LMI не устанавливался);
получение кадра LMI с информацией о полном состоянии, который не включает ПВК, используемый в настоящее время.
Возможно, что выход ошибочных ситуаций будет происходить тогда, когда:
сообщения о состоянии LMI были потеряны на линии связи;
процедуры инициализации ПВК были некорректными. В этих случаях ООД абонента должно в кадрах LMI отмечать соответственно, что ПВК "активен" или "недоступен".