
- •Семенов ю.А. (гнц итэф) Общие принципы построения сетей Оглавление
- •Распределения визитов сайта book.Itep.Ru по регионам за месяц (данные Rambler)
- •1 Введение (общие принципы построения сетей) Семенов ю.А. (гнц итэф)
- •2 Преобразование, кодировка и передача информации Семенов ю.А. (гнц итэф)
- •2.1 Передача сигналов по линиям связи Семенов ю.А. (гнц итэф)
- •2.2 Представление электрических сигналов в цифровой форме Семенов ю.А. (гнц итэф)
- •2.3 Цифровые каналы t1 и е1 Семенов ю.А. (гнц итэф)
- •2.4 Методы преобразования и передачи звуковых сигналов Семенов ю.А. (гнц итэф)
- •2.4.1 Дельта-модуляция Семенов ю.А. (гнц итэф)
- •2.4.2 Кодировщики голоса (Vocoder) Семенов ю.А. (гнц итэф)
- •2.4.3 Передача голоса по каналам Интернет Семенов ю.А. (гнц итэф)
- •2.5 Методы преобразования и передачи изображения Семенов ю.А. (гнц итэф)
- •Стандарт mpeg-1 и -2
- •Часть 1 mpeg-2 относится к объединению одного или более элементарных аудио или видео потоков, а также прочих данных в один или несколько потоков, удобных для записи или передачи.
- •Интерактивное телевидение
- •2.5.1 Стандарт mpeg-4 Семенов ю.А. (гнц итэф)
- •1. Особенности стандарта mpeg-4
- •1.1. Кодированное представление медийных объектов
- •1.2. Состав медийных объектов
- •1.3. Описание и синхронизация потоков данных для медийных объектов
- •1.4. Доставка потоков данных
- •1.5. Взаимодействие с медийными объектами
- •1.6. Менеджмент и идентификация интеллектуальной собственности
- •2. Основные функции в mpeg-4 версия 1
- •2.2. Системы
- •2.3. Аудио-система
- •2.4. Видео-система
- •2.4.1. Поддерживаемые форматы
- •2.4.2. Эффективность сжатия
- •2.4.3. Функции, зависящие от содержимого (Content-Based)
- •2.4.4. Масштабируемость текстур изображений и видео
- •2.4.5. Кодирование формы и Alpha-представление
- •2.4.6. Надежность в средах, подверженных ошибкам
- •2.4.7. Анимация лица
- •3.2.2. Анимация тела
- •3.2.3. Кодирование 3-d полигональных сеток
- •3.3. Звук
- •4. Расширения mpeg-4 за пределы версии 2
- •4.1. Визуальная область системы
- •4.2. Системы
- •4.2.2. Текстуальный формат
- •4.2.3. Улучшенная модель синхронизации
- •5. Профайлы в mpeg-4
- •5.1. Визуальные профайлы
- •5.2. Аудио профайлы
- •5.3. Профайлы графики
- •5.4. Графические профайлы сцены
- •5.5. Профайлы mpeg-j
- •5.6. Профайл дескриптора объекта
- •6. Верификационное тестирование: проверка работы mpeg
- •6.1. Видео
- •6.1.1. Тесты эффективности кодирования 6.1.1.1. Низкие и средние скорости передачи бит (версия 1)
- •6.1.1.2. Кодирование, базирующееся на содержимом (версия 1)
- •6.1.1.3. Профайл продвинутой эффективности кодирования ace (Advanced Coding Efficiency) (версия 2)
- •6.1.2. Тесты устойчивости к ошибкам 6.1.2.1. Простой профайл (версия 1)
- •6.1.2.2. Простой продвинутый профайл реального времени arts (Advanced Real-Time Simple) (версия 2)
- •6.1.3. Тестирование стабильности временного разрешения 6.1.3.1. Простой продвинутый профайл реального времени arts (Advanced Real-Time Simple) (версия 2)
- •6.1.4. Проверки масштабируемости 6.1.4.1. Простой масштабируемый профайл (версия 1)
- •6.1.4.2. Центральный профайл (core profile версия 1)
- •6.2. Звук
- •7. Промышленный форум mpeg-4
- •8. Детальное техническое описание mpeg-4 dmif и систем
- •8.1.1. Вычислительная модель dmif
- •8.2. Демультиплексирование, синхронизация и описание потоков данных
- •8.2.1. Демультиплексирование
- •8.2.2. Синхронизация и описание элементарных потоков
- •8.2.3. Управление буфером
- •8.2.4. Идентификация времени
- •8.3. Улучшенная модель синхронизации (FlexTime)
- •8.3.1. Гибкая длительность
- •8.3.2. Относительное время начала и конца
- •8.3.3. Поддержка FlexTime в mpeg-4
- •8.3.3.1. Узел TemporalTransform
- •8.3.3.2. Узел TemporalGroup
- •8.3.3.3. Дескриптор сегмента (SegmentDescriptor)
- •8.3.4. Модель исполнения
- •8.4. Описание синтаксиса
- •8.5. Двоичный формат описания сцены bifs (Binary Format for Scene description)
- •8.5.1. Продвинутый формат bifs
- •8.6. Взаимодействие с пользователем
- •8.7. Ipr идентификация и защита
- •8.8. Информация содержимого объекта
- •8.9. Формат файлов mpeg-4
- •9. Детальное техническое описание визуальной секции mpeg-4
- •9.1. Приложения видео-стандарта mpeg-4
- •9.2. Натуральные текстуры, изображения и видео
- •9.3. Синтетические объекты
- •9.4. Масштабируемое кодирование видео-объектов
- •9.5. Устойчивость в среде, предрасположенной к ошибкам
- •9.6. Улучшенная стабильность временного разрешения с низкой задержкой буферизации
- •9.7. Кодирование текстур и статические изображения
- •9.8. Кодирование нескольких видов и большого числа вспомогательных компонентов
- •9.8.1. Анимация лица
- •9.8.2. Анимация тела
- •9.8.3. Анимируемые 2-d сетки
- •9.8.5. Масштабируемость, зависящая от изображения
- •9.9. Структура средств для представления натурального видео
- •9.10. Поддержка обычной функциональности и зависящей от содержимого
- •9.11. Видео изображение mpeg-4 и схема кодирования
- •9.11.1. Эффективность кодирования в V.2
- •9.12. Кодирование текстур в статических изображениях
- •9.13. Масштабируемое кодирование видео-объектов
- •9.14. Устойчивость в среде, предрасположенной к ошибкам
- •9.14.1. Ресинхронизация
- •9.14.2. Восстановление данных
- •9.14.3. Сокрытие ошибок
- •10. Подробное техническое описание mpeg-4 аудио
- •10.1. Натуральный звук
- •10.2. Улучшения mpeg-4 аудио V.2
- •10.2.1. Устойчивость к ошибкам
- •10.2.2. Аудио-кодирование с малыми задержками
- •10.2.3. Масштабируемость гранулярности
- •10.2.4. Параметрическое кодирование звука
- •10.2.5. Сжатие тишины celp
- •10.2.6. Устойчивое к ошибкам hvxc
- •10.2.7. Пространственные характеристики среды
- •10.2.8. Обратный канал
- •10.2.9. Транспортный поток звука
- •10.3. Синтетический звук
- •10.3.1. Синтез с множественным управлением (Score Driven Synthesis).
- •11. Приложение. Словарь и сокращения
- •2.5.2 Стандарт mpeg-7 Семенов ю.А. (гнц итэф)
- •1. Введение
- •1.1. Контекст mpeg-7
- •1.2. Цель mpeg-7
- •1.3. Область действия стандарта
- •1.4. Область применения mpeg-7
- •1.5. План и метод работы
- •1.6. Части mpeg-7
- •1.7. Структура документа
- •2. Главные функции mpeg-7 2.1. Системы mpeg-7
- •2.2. Язык описания определений mpeg-7
- •2.3. Аудио mpeg-7
- •2.4. Визуальный mpeg-7
- •2.5. Основные объекты и схемы описания мультимедиа mpeg-7
- •2.6. Эталонные программы mpeg-7: модель экспериментов (eXperimentation Model)
- •3. Детальное техническое описание стандарта mpeg-7 3.1. Системы mpeg-7
- •3.1.1. Архитектура терминала
- •3.1.2. Нормативные интерфейсы 3.1.2.1. Описание нормативных интерфейсов
- •3.1.2.2. Верификация стандарта
- •3.2. Язык описания определений mpeg-7 (ddl)
- •3.2.1. Разработка контекста
- •3.2.2. Обзор схемы xml
- •3.2.3. Схема xml: Структуры
- •3.2.4. Схема xml: Типы данных
- •3.2.5. Расширения схемы xml mpeg-7
- •3.3. Аудио mpeg-7
- •3.3.1. Описание системы аудио mpeg-7
- •3.3.2. Средства описания аудио верхнего уровня (d и ds)
- •3.3.2.1. Средства описания тембра музыкальных инструментов
- •3.3.2.2. Средства распознавания звука
- •3.3.2.3. Средства описания содержимого сказанного
- •3.3.2.4. Средства описания мелодии
- •3.4.1.3. Временные ряды
- •3.4.1.4. Пространственные координаты 2d
- •3.4.1.5. Временная интерполяция
- •3.4.2. Описатели цвета
- •3.4.2.1. Цветовое пространство
- •3.4.2.2. Оцифровка цвета
- •3.4.2.3. Доминантный цвет(а)
- •3.4.2.4. Масштабируемый цвет
- •3.4.2.5. Описатель структуры цвета
- •3.4.2.6. Выкладка цвета
- •3.4.2.7. Цвет GoF/GoP
- •3.4.3. Описатели текстуры
- •3.4.3.1. Описатели однородной текстуры
- •3.4.3.2. Просмотр текстуры
- •3.4.3.3. Краевая гистограмма
- •3.4.4. Описатели формы
- •3.4.4.1. Форма, базирующаяся на областях (Region-Based)
- •3.4.4.2. Форма, основанная на контуре
- •3.4.5. Дескрипторы перемещения
- •3.4.5.1. Движение камеры
- •3.4.5.2. Траектория движения
- •3.4.5.3. Параметрическое движение
- •3.4.5.4. Двигательная активность
- •3.4.6. Локализация 3.4.6.1. Локатор области
- •3.4.6.2. Пространственно-временной локатор
- •3.4.7. Прочие 3.4.7.1. Распознавание лица
- •3.5. Схемы описания мультимедиа mpeg-7
- •3.5.1. Средства организации mds
- •3.5.1.1. Базовые элементы
- •3.5.1.2. Управление содержимым
- •3.5.1.3. Описание содержимого
- •3.5.1.4. Навигация и доступ
- •3.5.1.5. Организация содержимого
- •3.5.1.6. Интеракция с пользователем
- •3.5.2. Управление содержимым
- •3.5.2.1. Средства описания среды
- •3.5.2.2. Создание и производство средств описания
- •3.5.2.3. Средства описания использования содержимого
- •3.5.3. Описание содержимого 3.5.3.1. Описание структурных аспектов содержимого
- •3.5.3.2. Описание концептуальных аспектов содержимого
- •3.5.4. Навигация и доступ
- •3.5.4.1. Резюме
- •3.5.4.2. Разделы и декомпозиции
- •3.5.4.3. Вариации содержимого
- •3.5.5. Организация содержимого
- •3.5.5.1. Собрания (Collections)
- •3.5.5.2. Модели
- •3.5.6. Взаимодействие с пользователями
- •3.6. Эталонные программы: экспериментальная модель
- •3.6.1. Цели
- •3.6.2. Извлечение и приложения клиента
- •3.6.3. Модульность xm-программ
- •3.6.4. Модули приложения 3.6.4.1. Медийные декодеры
- •3.6.4.2. Мультимедийные данные
- •3.6.4.3. Средства выборки
- •3.6.4.4. Класс дескрипторов
- •3.6.4.5. Схема кодирования
- •3.6.4.6. Средство поиска
- •3.6.5. Типы приложений в xm-программах 3.6.5.1. Извлечение из среды
- •3.6.5.2. Приложение поиска и извлечения
- •3.6.5.3. Приложение транскодирования среды
- •3.6.5.4. Приложение описания фильтрации
- •3.6.6. Модель ключевого приложения mpeg-7 3.6.6.1. Определение ключевых приложений
- •3.6.6.2. Модель интерфейса
- •3.6.7. Ключевые приложения против приложений реального мира
- •Приложение а. Словарь и сокращения
- •2.5.3 Архитектура мультимедиа mpeg-21 Семенов ю.А. (гнц итэф)
- •Обзор цифровых объектов
- •Декларация цифрового объекта
- •Контейнер
- •Компонент
- •Идентификация цифрового объекта
- •Идентификация цифровых объектов
- •Идентификация различных схем описания
- •Идентификация различных типов цифровых объектов
- •Защита и управление правами интеллектуальной собственности (ipmp)
- •Язык описания прав
- •Модель данных mpeg rel
- •Принципал
- •Условие
- •Соотношение с терминологией mpeg
- •Адаптация цифрового объекта
- •Формат файлов
- •Устойчивая ассоциация идентификации и описания с цифровыми объектами
- •2.6 Методы сжатия информации Семенов ю.А. (гнц итэф)
- •2.6.1 Алгоритм Зива-Лемпеля Семенов ю.А. (гнц итэф)
- •2.6.2 Локально адаптивный алгоритм сжатия Семенов ю.А. (гнц итэф)
- •2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера Семенов ю.А. (гнц итэф)
- •2.6.4 Метод Шеннона-Фано Семенов ю.А. (гнц итэф)
- •2.6.5 Статический алгоритм Хафмана Семенов ю.А. (гнц итэф)
- •2.7 Обнаружение ошибок Семенов ю.А. (гнц итэф)
- •2.8 Коррекция ошибок Семенов ю.А. (гнц итэф)
- •Циклические коды
- •Линейные блочные коды
- •Метод коррекции ошибок fec (Forward Error Correction)
- •Введение в коды Рида-Соломона: принципы, архитектура и реализация
- •Свойства кодов Рида-Соломона
- •Ошибки в символах
- •Декодирование
- •Преимущество кодирования
- •Архитектура кодирования и декодирования кодов Рида-Соломона
- •Арифметика конечного поля Галуа
- •Образующий полином
- •Архитектура кодировщика
- •Архитектура декодера
- •Вычисление синдрома
- •Нахождение позиций символьных ошибок
- •Нахождение значений символьных ошибок
- •Реализация кодировщика и декодера Рида-Соломона Аппаратная реализация
- •Программная реализация
- •2.9 Видеоконференции по каналам Интернет и isdn Семенов ю.А. (гнц итэф)
- •2.9.1 Используемые стандарты Семенов ю.А. (гнц итэф)
- •2.10 Статистическая теория каналов связи Семенов ю.А. (гнц итэф)
- •2.10.2. Канал связи с изменяющимися состояниями
- •2.10.3. Симметричный канал без памяти
- •3 Каналы передачи данных Семенов ю.А. (гнц итэф)
- •3.1 Кабельные каналы связи Семенов ю.А. (гнц итэф)
- •3.2 Оптоволоконные каналы и беспроводные оптические связи Семенов ю.А. (гнц итэф)
- •Беспроводные оптические каналы
- •3.3 Беспроводные (радио) каналы и сети Семенов ю.А. (гнц итэф)
- •3.4 Протокол slip и rs-интерфейсы Семенов ю.А. (гнц итэф)
- •3.4.1. Протоколы rs
- •3.4.1 Интерфейсная шина FireWire (ieee1394) Семенов ю.А. (гнц итэф)
- •Особенности ieee - 1394
- •Архитектура ieee-1394
- •.5 Протокол ppp Семенов ю.А. (гнц итэф)
- •3.6 Протокол g.703 Семенов ю.А. (гнц итэф)
- •3.7 Дерево Штайнера Семенов ю.А. (гнц итэф)
- •4 Сети передачи данных. Методы доступа Семенов ю.А. (гнц итэф)
- •Топология
- •Метод доступа к сети
- •Принципы построения сетевых программных интерфейсов
- •Очереди fifo
- •Приоритетное обслуживание очередей (pq)
- •Обычное обслуживание очередей (сq)
- •Справедливые очереди (wfq)
- •Справедливые очереди базирующиеся на классах (cbwfq)
- •Очереди с малой задержкой (llq)
- •Методы работы в условиях перегрузки
- •Алгоритм leaky bucket ("дырявое ведро")
- •Алгоритм Token Bucket ("маркерное ведро")
- •4.1 Локальные сети (обзор) Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •4.1.1.1 Архитектура сетей Ethernet Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •Гигабитный Ethernet (ge)
- •40 Гигабит/сек технологии
- •4.1.1.3 Интернет в Ethernet Семенов ю.А. (гнц итэф)
- •4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы Семенов ю.А. (гнц итэф)
- •4.1.1.5 Алгоритмы и применения сетей p2p Семенов ю.А. (гнц итэф)
- •Определения:
- •Р2р файлообменные сети
- •P2p телевидение
- •Проблемы безопасности
- •Семенов ю.А. (гнц итэф)
- •4.1.3 Ieee 802.4 (Маркерная шина) Семенов ю.А. (гнц итэф)
- •4.1.4 Сети управления и сбора данных в реальном масштабе времени (can) Семенов ю.А. (гнц итэф)
- •4.1.5 Локальные сети ArcNet Семенов ю.А. (гнц итэф)
- •4.1.6 Сети fddi Семенов ю.А. (гнц итэф)
- •4.1.7 Параллельный сетевой интерфейс hippi Семенов ю.А. (гнц итэф)
- •4.1.8 Сети ieee 802.11 Семенов ю.А. (гнц итэф)
- •Безопасность в режиме pre-shared key
- •4.1.8.1 Мобильные телекоммуникации Семенов ю.А. (гнц итэф)
- •4.1.8.2 Стандарт широкополосной беспроводной связи ieee 802.16 Семенов ю.А. (гнц итэф)
- •1. Краткие характеристики стандарта 802.16
- •2. Сообщения управления мас
- •3. Сообщение дескриптора нисходящего канала (dcd)
- •Идентификатор нисходящего канала
- •4. Сообщение привязки нисходящего канала (dl-map)
- •6. Сообщение привязки восходящего канала(ul-map)
- •7. Сообщение запроса диапазона (rng-req)
- •Идентификатор нисходящего канала
- •Ожидание до завершения
- •8. Сообщение отклика на запрос диапазона (rng-rsp)
- •9. Сообщение запроса регистрации (reg-req)
- •10. Сообщение отклика регистрации reg-rsp
- •Возможности ss
- •11. Сообщения управления ключами конфиденциальности (pkm-req/pkm-rsp)
- •Атрибуты
- •12. Сообщение добавления ассоциации безопасности (sa Add)
- •13. Сообщение запроса авторизации (Auth Request)
- •14. Сообщение отклика авторизации (Auth Reply)
- •15. Сообщение отклонения авторизации (Auth Reject)
- •16. Сообщение запроса ключа
- •17. Сообщение отклика на запрос ключа
- •18. Сообщение отклонение ключа
- •19. Сообщение недействительности авторизации
- •20. Сообщение tek Invalid
- •21. Информационное сообщение аутентификации (Authent Info)
- •22. Сообщение запроса динамического добавления сервиса dsa-req)
- •Id транзакции
- •Id транзакции
- •Последовательность hmac
- •26. Dsa, инициированное ss
- •27. Dsa, инициированное bs
- •28. Сообщение подтверждения для динамического добавления сервиса (dsa-ack)
- •Id транзакции
- •29. Сообщение запроса dsc-req
- •30. Сообщение отклика динамического изменения сервиса (dsc-rsp)
- •Параметры сервисного потока
- •31. Сообщение подтверждения для динамического изменения сервиса (dsc-ack)
- •32. Сообщение запроса динамического аннулирования сервиса (dsd-req)
- •Id сервисного потока
- •33. Сообщение отклика на запрос динамического аннулирования сервиса (dsd-rsp)
- •Id сервисного потока
- •34. Сообщение запроса включения/удаления из списка мультикастного запроса (mca-req)
- •35. Сообщение отклика на запрос включения/удаления из списка мультикастного запроса (mca-rsp)
- •36. Сообщение запроса изменения профайла нисходящего канала (dbpc-req)
- •37. Сообщение отклика на изменение профайла нисходящего канала (dbpc-rsp)
- •38. Сообщение команды сброса (res-cmd)
- •39. Сообщение запроса базовых возможностей ss (sbc-req)
- •40. Сообщение отклика на запрос базовых возможностей (sbc-rsp)
- •41. Сообщение сверки часов (clk-cmp)
- •Порядковый номер
- •Результат сверки часов
- •42. Сообщение команды De/Re (dreg-cmd)
- •43. Сообщение о получении dSx (dsx-rvd)
- •44. Сообщение завершения копирования посредством tftp конфигурационного файла (tftp-cplt)
- •45. Сообщение отклика на уведомление о завершении копирования конфигурационного файла (tftp-rsp)
- •Специфические расширения поставщика
- •46. Сообщение запроса ключа
- •47. Сообщение отмены arq
- •48. Сообщение сброса arq
- •49. Формат сообщения (req-req) запроса результата измерения для канала
- •50. Формат сообщения (rep-req) о результате измерения для канала
- •51. Формат сообщения конфигурирования сеточной (mesh) сети (msh-ncfg)
- •Xmt Holdoff Exponent (показатель)
- •Id узла bs
- •52. Сообщение входа в сеточную сеть (msh-nent)
- •Id узла инициатора
- •53. Сообщение распределенной сеточной диспетчеризации (msh-dsch)
- •Флаг координации
- •Флаг запрос/отклик
- •Следующий Xmt Mх соседа
- •Показатель Xmt Holdoff соседа
- •Id узла соседа
- •Информационный элемент диспетчеризации msh-dsch
- •55. Информационный элемент запроса msh-dsch
- •Id канала
- •56. Информационный элемент возможностей msh-dsch
- •57. Информационный элемент предоставления msh-dsch
- •58. Сообщение централизованной диспетчеризации сетки (msh-csch)
- •Порядковый номер конфигурации
- •59. Сообщение конфигурации централизованной маршрутизации сетки (msh-cscf)
- •60. Запрос/отклик обратной связи канала aas (aas-fbck-req/rsp)
- •Литература
- •Семенов ю.А. (гнц итэф)
- •Литература
- •4.1.9 Сети dqdb (двойная шина с распределенной очередью) Семенов ю.А. (гнц итэф)
- •4.1.10 Сети с многокаскадными соединениями Семенов ю.А. (гнц итэф)
- •4.1.11 Сети 100Base-vg Семенов ю.А. (гнц итэф)
- •4.1.12 Канальный протокол Fibre Channel Семенов ю.А. (гнц итэф)
- •4.1.14 Адаптивные, кольцевые, высокоскоростные сети ieee 802.17 Семенов ю.А. (гнц итэф) Обзор
- •4.2 Наложенные сети Семенов ю.А. (гнц итэф)
- •4.2.1 Протоколы Novell (ipx/spx) Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •4.2.1.3 Протокол ядра NetWare (ncp) Семенов ю.А. (гнц итэф)
- •4.2.1.4 Протокол межсетевой передачи больших пакетов (lip) Семенов ю.А. (гнц итэф)
- •4.2.1.5 Служба каталогов NetWare (nds) Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •Семенов ю.А. (гнц итэф)
- •Протокол wins
- •4.3 Региональные сети Семенов ю.А. (гнц итэф)
- •4.3.1 Эталонная сетевая модель iso Семенов ю.А. (гнц итэф)
- •4.3.2 Протоколы сетей X.25 Семенов ю.А. (гнц итэф)
- •4.3.3 Интегрированные сети isdn Семенов ю.А. (гнц итэф)
- •4.3.4 Протокол Frame Relay Семенов ю.А. (гнц итэф)
- •4.3.5 Протоколы сетей atm Семенов ю.А. (гнц итэф)
- •4.3.6 Синхронные каналы sdh/sonet Семенов ю.А. (гнц итэф)
- •4.3.7 Модемы Семенов ю.А. (гнц итэф)
- •4.4 Интернет Семенов ю.А. (гнц итэф)
- •4.4 Интернет Семенов ю.А. (гнц итэф)
Семенов ю.А. (гнц итэф)
Сети Token Ring были разработаны фирмой IBM в 1970-х годах и рассчитана на скорость обмена 4.16 Мбит/c при числе сегментов до 250. По своей популярности она уступает лишь Ethernet/IEEE 802.3. Спецификация IEEE 802.5 практически идентична ей и полностью совместима (см. [13], или, например, bbs.uniinc.msk.ru/product/bay/routers/interf/toking.htm или www.oil.unh.edu/training/vganylan/teach/vgconcept/frame/802.-5). Сеть Token Ring имеет топологию звезды, все оконечные станции которой подключаются к общему устройству (MSAU - MultiStation Access Unit). В IEEE 802.5 топология не оговаривается, не регламентирована здесь и сетевая среда. В Token Ring сеть базируется на скрученных парах. Обе эти разновидности сети используют схему передачи маркера (небольшой пакет - token).
В отличие от сетей с csma/cd доступом (например, Ethernet) в IEEE 802.5 гарантируется стабильность пропускной способности (нет столкновений). Сети Token Ring имеют встроенные средства диагностики, они более приспособлены для решения задач реального времени, но в то же время более дороги.
Маркер содержит лишь поля стартового разделителя(sdel), управления доступом (AC) и оконечного разделителя (EDEL, всего 3 байта). Если узел получил маркер, он может начать передачу информации, в противном случае он просто передает маркер следующему узлу. Каждая станция может захватить маркер на определенное время. Станция, намеревающаяся что-то передать, захватывает маркер, меняет в нем один бит, который преобразует маркер во флаг начала кадра, вносит в кадр информацию, подлежащую пересылке, и посылает его следующей станции. Передающая станция ответственна за изъятие из кольца переданных ею кадров (станция не ретранслирует собственные кадры). Введенный в сеть кадр будет двигаться по сети, пока не попадет в узел, которому он адресован и который скопирует необходимую информацию. При этом устанавливается флаг копирования (FCI), что свидетельствует об успешной доставке кадра адресату. Кадр продолжает движение, пока не попадет в узел отправитель, где он будет уничтожен. При этом проверяется, подключена ли к сети станция-адресат. Это делается путем контроля API (индикатора распознавания кадра адресатом). Сеть Token Ring идеальна для приложений, где задержка получения информации должна быть предсказуемой, и требуется высокая надежность.
Сетевые станции подключаются к MSAU, которые объединяются друг с другом, образуя кольцо. Если станция отключилась, MSAU шунтирует ее, обеспечивая проход пакетов. Стандарт Token Ring использует довольно сложную систему приоритетов, которая позволяет некоторым станциям пользоваться сетью чаще остальных. Кадры Token Ring имеют два поля, которые управляют доступом приоритет и резервирование. Только станции с приоритетом равным или выше, чем приоритет маркера, могут им завладеть. Если маркер уже захвачен и преобразован в информационный кадр, только станции с приоритетом выше, чем у станцииё отправителя, могут зарезервировать маркер на следующий цикл. Станции, которые подняли приоритет маркера, должны его восстановить после завершения передачи.
Сети Taken Ring имеют несколько механизмов для обнаружения и предотвращения влияния сетевых сбоев и ошибок. Например, пусть одна из станций выбрана в качестве активного монитора. Эта станция работает как центральный источник синхронизации для других станций сети и выполняет ряд других функций. Одной из таких функция является удаление из кольца бесконечно циркулирующих кадров (маркеров). Если отправитель ошибся, установив, например ошибочный адрес места назначения, это может привести к зацикливанию кадра. Ведь кадр может быть поврежден в пути и отправитель его уже не узнает. А это в свою очередь блокирует работу остальных станций. Активный монитор должен обнаруживать такие кадры, удалять их и генерировать новый маркер. Функции активного монитора часто выполняют MSAU. Попутно msau может контролировать, какая из станций является источником таких дефектных кадров, и вывести ее из кольца. Если станция обнаружила серьезную неполадку в сети (например, обрыв кабеля), она посылает сигнальный кадр (beacon). Такой кадр несет в себе идентификатор отправителя и имя соседа-предшественника (NAUN - nearest active upstream neighbour). Такой кадр инициализирует процедуру автореконфигурации, при которой узлы в районе аварии пытаются реконфигурировать сеть так, чтобы ликвидировать влияние поломки. Топологическая схема сети ieee 802.5 представлена на рис. 4.1.2.1.
Рис. 4.1.2.1 Топология сети Token Ring
Периферийные ЭВМ подключаются к блокам msau по схеме звезда, а сами MSAU соединены друг с другом по кольцевой схеме. Возможна реализация схемы звезда и иным способом, показанным на рис. 4.1.2.2. Здесь объединяющую функцию выполняет блок концентратора.
Рис. 4.1.2.2. Реализация Token Ring по схеме звезда
Концентратор может шунтировать каналы, ведущие к ЭВМ, с помощью специальных реле при ее отключении от питания. Аналогичную операцию может выполнить и блок msau. Управление сетью возлагаются на пять функциональных станций, определенных протоколом. Некоторые контрольные функции выполняются аппаратно, другие реализуются с помощью загружаемого программного обеспечения. Каждая из функциональных станций имеет свои логические (функциональные) адреса. Функциональные станции должны реагировать как на эти функциональные, так и на свои собственные аппаратные адреса. Ниже в таблице представлен список функциональных станций и их функциональных адресов (таблица 4.1.2.1).
Таблица 4.1.2.1 Типы и адреса функциональных станций
Функциональная станция |
Адрес |
1. Активный монитор |
c0 00 00 00 00 01 |
2. Резервный монитор |
адрес не определен |
3. Сервер конфигурации (необязательное устройство) |
c0 00 00 00 00 02 |
4. Монитор ошибок (необязательное устройство) |
c0 00 00 00 00 08 |
5. Сервер параметров кольца (необязательное устройство) |
c0 00 00 00 00 10 |
В сети используются кадры управления доступом к среде (УДС, код типа кадра = 00) и информационные кадры (код типа кадра =01). Имеется 25 разновидностей УДС-кадров (см. приложение 10.6 Управление доступом). Сюда входят кадры инициализации, управления средой, сообщения об ошибках и кадры управления рабочими станциями. Общий формат заголовка кадра Token Ring представлен на рис. 4.1.2.3. Размер поля данных, следующего за адресом отправителя, может иметь произвольную длину, в том числе и нулевую. В это поле может быть вложен пакет другого протокола, например, LLC.
Рис. 4.1.2.3. Формат информационного кадра для IEEE 802.5
В начале поля данных может размещаться LLC-заголовок, который содержит в себе 3-8 байт. Собственно этот заголовок, да поле управления кадром и отличают информационный кадр от кадра управления доступом (см. рис. 4.1.2.4).
Рис. 4.1.2.4. Формат кадра управления доступом для IEEE 802.5 (цифрами обозначены размеры полей в байтах)
Вслед за адресом отправителя следует информация управления доступом к среде. Кадры управления доступом служат исключительно для целей управления сетью и не передаются через бриджи и маршрутизаторы. Управляющая информация включает в себя основной вектор и несколько субвекторов. Основной вектор задает тип УДС-кадра (или команду) и типы (или классы) станций отправителя и получателя, всего 4 байта. Субвекторы содержат информацию об адресе соседа-предшественника, номер физического отвода кабеля и пр. (3 и более байт). На рис. 4.1.2.5. представлен формат основного вектора.
Рис. 4.1.2.5. Формат основного вектора
Субполе длина определяет полную протяженность информационного поля УДС-кадра и равна сумме длин основного вектора и всех субвекторов. Субполе класс характеризует станции отправителя и получателя. Каждой из станций выделено по 4 двоичных разряда, которые описывают типы этих станций. Ниже в таблице 4.1.2.2 представлены эти коды и их значения.
Таблица 4.1.2.2 Таблица кодов класса
Код класса |
Функциональный тип станции |
0x0 |
Рабочая станция кольца |
0x1 |
Администратор канального уровня |
0x4 |
Администратор сети или сервер конфигурации |
0x5 |
Сервер параметров кольца |
0x6 |
Сервер ошибок |
Субполе команда содержит код, передаваемой УДС-кадром команды (см. таблицу 10.6 в приложении Управление доступом). Кадр управления доступом может содержать любое, в том числе нулевое число субвекторов. Некоторые субвектора являются обязательными. Таблица обязательных субвекторов приведена в приложении 10.7 Типы субвекторов. В результате декодирования субвекторов можно локализовать нестабильную ошибку. Ниже на рис. 4.1.2.6 приведен формат субвектора.
Рис. 4.1.2.6. Формат субвектора
Поля длина определяет длину субвектора (ведь она переменная). Поля тип содержит код типа субвектора. Поле значение хранит данные, например, код 0x0b характеризует номер отвода и т.д..
Разряды начального и конечного разделителей кадра содержат как обычные нули и единицы, так и закодированные дифференциальным манчестерским кодом. На рис. 4.1.2.7 приведен формат начального разделителя SDEL.
Рис. 4.1.2.7. Формат начального разделителя SDEL
"e" и "Н" - представляет собой единицу и нуль, закодированные манчестерским кодом. Оконечный разделитель (EDEL) имеет формат, показанный на рис. 4.1.2.8.
Рис. 4.1.2.8. Формат оконечного разделителя EDEL
Бит - индикатор промежуточного кадра (IF) равен нулю, если кадр является последним или единственным кадром в последовательности. Единица в этом бите указывает на то, что этот кадр не является последним. Бит индикатор обнаруженной ошибки (ED) устанавливается равным единице первой станцией, которая выявила ошибку в контрольной последовательности кадра (CRC). Таким образом, crc контролируется всеми станциями, через которые проходит пакет. crc - гарантирует корректность пересылке части кадра, начиная от поля управление кадром кончая полем данные. Последним полем кадра является октет состояния (рис. 4.1.2.9). Первые и последние четыре бита этого поля должны повторять друг друга, что повышает достоверность записанной там информации.
Рис. 4.1.2.9. Формат поля состояния кадра
Бит распознавания адреса (ARI) служит в качестве флага распознавания получателем своего адреса. Если распознавание произошло, получатель перед ретрансляцией кадра далее устанавливает этот бит в единичное состояние.
Бит- индикатор копирования кадра (FCI) служит для индикации успешного копирования информации из полученного кадра. Если получатель распознал свой адрес, имеет достаточно место в буфере и благополучно скопировал туда информацию из полученного пакета, он устанавливает этот бит в единичное состояние. Биты ARI и FCI активно используются управляющими станциями кольца. Для отправителя они носят второстепенный характер, ибо решение о повторной пересылке при утере кадра принимается обычно на транспортном (более высоком) уровне. При недостатке буферного пространства в памяти станция не всегда может скопировать кадр, повторная же передача сокращает пропускную способность сети. Если же перегружающаяся станция является частью инфраструктуры сети (сервер), это может ухудшить свойства сети в целом. Улучшению ситуации может способствовать увеличение числа буферов на плате сетевого адаптера, увеличение быстродействия канала и расширения объема буферной памяти в самой ЭВМ.
Флаг начала потока (SSD - start of stream delimiter) позволяет сетевому уровню, независящему от физической среды (PMI - physical media independent) детектировать начало потока кодов. Получение неверного SSD не прерывает прием данных, а передает сигнал ошибки субуровням MAC или RMAC.
SSD высокого приоритета: |
0101 111100 000011 |
SSD обычного приоритета: |
0101 100000 111110 |
Флаг окончания потока (ESD - end of stream delimiter) позволяет сетевому уровню PMI завершить прием пакета и переслать полученные данные субуровню mac. Детектирование неверного IPM (invalid packet marker) разделителя приводит к ошибке на уровне MAC или RMAC.
Правильный флаг окончания потока (ESD):
ESD высокого приоритета: |
111111 000011 000001 |
ESD обычного приоритета: |
000000 111100 111110 |
Маркер неправильного пакета: |
110000 011111 110000 |
Сигнатура преамбулы позволяет PMI определить место, с которого следует начинать прием данных. Код преамбулы имеет вид:
010101 010101 010101 010101 010101 010101 010101 010101
Рис. 4.1.2.10. Формат поля управления доступом
Поле управления доступом служит для определения приоритета кадра, это единственное поле, которое присутствует в маркере (помимо SDEL и EDEL). Субполе приоритета (PPP) указывает на приоритет маркера в 802.5. Предусмотрено восемь уровней приоритета, начиная с 000 (низший) до 111 (высший). В 802.12 здесь записывается всегда 000. Субполе бит маркера позволяет отличить обычный кадр от маркера. Для маркера поле несет в себе 0, а для кадра 1 (802.5). Так как в 100VG-anylan передаются только маркерные кадры, этот бит всегда равен 1. Бит мониторинга препятствует бесконечной циркуляции кадра по кольцу. В исходный момент все кадры и маркеры имеют этот бит равный 0. Приемник игнорирует этот бит. Биты rrr разрешают приоритетным пакетам запрашивать маркер того же уровня приоритета. Стандарт 802.12 не использует непосредственно октет управления доступом, а для обеспечения совместимости с 802.5 по умолчания записывает туда 0001000.
Рис. 4.1.2.11. Формат поля управления кадра
Значения кодов субполя тип кадра представлено в таблице 4.1.2.3, они определяют формат данных информационного поля кадра. Для обычной передачи поле равно 01000yyy.
Таблица 4.1.2.3 Коды типа кадра
Код поля типа |
Функция |
00 |
MAC-кадр (УДС) |
01 |
LLC-кадр (данные) |
1x |
Резерв на будущее |
Поле физического управления (pcf) имеет смысл только для УДС-кадров и служит для оповещения станций о типе кадра управления средой. Это поле служит также для указания приоритета передачи кадра из буфера адаптера в ЭВМ. В таблице 4.1.2.4.
Таблица 4.1.2.4 Коды поля pcf
Описание |
Код поля pcf |
Нормальный буфер |
0 |
Экспресс буфер |
1 |
Очистка кольца |
2 |
Требование маркера |
3 |
Аварийная сигнализация |
4 |
Наличие активного монитора |
5 |
Наличие резервного монитора |
6 |
Для llc-кадров поле резервированные биты и далее имеет формат rrryyy, где биты rrr зарезервированы для будущего использования (000), а yyy - код приоритета пакетов пользователя. (MAC-кадры не используются в IEEE 802.12). Формат поля адреса получателя отображен на рис. 4.1.2.12.
Рис. 4.1.2.12. Формат адреса места назначения
I/G =0 индивидуальный адрес (I); I/G=1 групповой адрес (g). U/L=0 универсальный адрес (U); U/L=1 локальный адрес (L).
Индивидуальный адрес - адрес конечного узла, уникальный для данной локальной сети (в случае локального администрирования) или отличный от любого другого адреса в глобальной сети в случае универсального администрирования. Существует две разновидности индивидуального адреса: уникастный и нулевой. Уникастный адрес - индивидуальный адрес, идентифицирующий один из узлов сети. Нулевой адрес равен нулю и означает, что кадр не адресован ни одному из узлов сети. Такой адрес не может быть присвоен ни одному из оконечных узлов сети. Описываемые далее разновидности адресов используются только в полях адреса места назначения.
Групповой адрес ассоциируется с (нулем или более) некоторым числом оконечных узлов данной сети, обычно это группа логически связанных узлов. Широковещательные и мультикастинг-адреса относятся к групповым адресам.
Широковещательный адрес подразумевает обращение ко всем узлам данной сети, такой адрес содержит 1 во всех своих разрядах. Мультикастинг-адрес подразумевает обращение к некоторой, выделенной группе адресов данной локальной сети. Существуют также функциональные адреса (FA), которые идентифицируют некоторые известные функциональные объекты с помощью групповых адресов. Формат функционального адреса представлен на рис. 4.1.2.13.
Рис. 4.1.2.13. Структура функционального адреса
Ниже приведена таблица 4.1.2.5 некоторых зарезервированных функциональных адресов.
Таблица 4.1.2.5. Зарезервированные функциональные адреса
6-октетный адрес (fa) |
Назначение |
С0 00 00 00 00 01 |
Активный монитор |
С0 00 00 00 00 02 |
Кольцевой сервер параметров (rps) |
Функциональные адреса являются отличительной особенностью сетей Token Ring. В этих сетях маршрутная информация распределена между устройствами сети. Рабочие станции создают и поддерживают собственные маршрутные таблицы. Формат поле адреса отправителя показан на рис. 4.1.2.14.
Рис. 4.1.2.14. Формат адреса отправителя
Субполе RII является индикатором маршрутной информации, функция субполя U/L идентична с вариантом формата адреса получателя. Если RII=1, в поле данных содержится маршрутная информация.
Формат поля маршрутной информации отображен на рис. 4.1.2.15.
Рис. 4.1.2.15. Формат поля маршрутной информации (RI)
Разновидности сетей, не использующие маршрутную информацию, берут код из субполя LTH (длина), чтобы обойти поле RI. Субполе RT (код типа маршрутизации) имеет 3 бита и говорит о том, должен ли данный кадр быть переадресован. Ниже приведена таблица (4.1.2.6) возможных значений кода rt.
Таблица 4.1.2.6. Значения кода rt
Код rt |
Описание |
0xx |
Передача по определенному маршруту |
10x |
Широковещательная передача по всем маршрутам |
11x |
Широковещательная передача по одному маршруту |
Субполе LTH (длина) имеет 5 бит и хранит в себе длину поля RI в октетах. LTH должно быть четным и лежать в пределах 2-30, включительно. Обычно маршрутная информация занимает от 2 до 16 байт (cпецификация IBM требует, чтобы кадр проходил не более 7 мостов). Если субполе бит направления (d) равно нулю, обход кольца маркером осуществляется в порядке записи дескрипторов маршрута, при d=1 - в обратном порядке (RDN, RDn-1, ... RD1). Субполе максимальная длина кадра (LF) имеет 3 бита и указывает наибольший размер информационного поля MAC. Значение поля устанавливается мостами при определении маршрута и указывает максимальную длину кадра, передаваемого мостом. Допустимы следующие значения:
Таблица 4.1.2.7. Возможные значения поля LF
Код поля lf |
Длина кадра в байтах |
000 |
516 |
001 |
1500 |
010 |
2052 |
011 |
4472 |
100 |
8144 |
101 |
11407 |
110 |
17800 |
Субполя дескрипторов маршрута состоят из 12 бит идентификатора сети (номер кольца, назначается сетевым администратором) за которым следует 4 бита номера моста. Эти дескрипторы определяют порядок обхода сети кадром. В сетях 100VG-anylan это поле не используется, так как порядок обхода задается аппаратно повторителями.
При построении больших сетей token ring приходится использовать большое число колец. Отдельные кольца связываются друг с другом, как и в других сетях, с помощью мостов (рис. 4.1.2.16). Мосты бывают "прозрачными" (IEEE 802.1d) и с маршрутизацией от источника. Последние позволяют связать в единую сеть несколько колец, использующих общий сетевой IPX- или IP-адрес.
Рис. 4.1.2.16 Соединение колец с помощью прозрачного моста
Использование мостов позволяет преодолеть и ограничение на число станций в сети (260 для спецификации ibm и 255 для IEEE). Мосты могут связывать между собой фрагменты сетей, использующих разные протоколы, например, 802.5, 802.4 и 802.3. Пакеты из кольца 1 адресованные объекту этого же кольца никогда не попадут в кольцо 2 и наоборот. Через мост пройдут лишь пакеты, адресованные объектам соседнего кольца. Фильтрация пакетов осуществляется по физическому адресу и номеру порта. На основе этих данных формируется собственная база данных, содержащая информацию об объектах колец, подключенных к мосту. Схема деления сети с помощью мостов может способствовать снижению эффективной загрузки сети.
Мосты с маршрутизацией от источника могут объединять только сети token ring, а маршрутизация пакетов возлагается на все устройства, посылающие информацию в сеть (отсюда и название этого вида мостов). Это означает, что в каждом из сетевых устройств должно быть загружено программное обеспечение, позволяющее маршрутизировать пакеты от отправителя к получателю (в случае netware это route.com). Эти мосты не создают собственных баз данных о расположении сетевых объектов и посылают пакет в соседнее кольцо на основе маршрутного указания, поступившего от отправителя самого пакета. Таким образом, база данных о расположении сетевых объектов оказывается распределенной между станциями, хранящими собственные маршрутные таблицы. Программы маршрутизации используют сетевой драйвер адаптера. Мосты с маршрутизацией от источника просматривают все поступающие кадры и отбирают те, которые имеют индикатор информации о маршруте RII=1. Такие кадры копируются, и по информации о маршруте определяется, следует ли их посылать дальше. Мосты с маршрутизацией от источника могут быть настроены на широковещательную передачу по всем маршрутам, либо на широковещательную передачу по одному маршруту. Формат информации о маршруте показан на рис. 4.1.2.15.
В сетях со сложной топологией маршруты формируются согласно иерархическому протоколу STP (spanning tree protocol). Этот протокол организует маршруты динамически с выбором оптимального маршрута, если адресат достижим несколькими путями. При этом минимизируется транзитный трафик. Для решения задачи мосты обмениваются маршрутной информацией. Формат этих пакетов показан на рис. 4.1.2.17.
Рис. 4.1.2.17. Формат кадра маршрутных данных, рассылаемых мостом
Поле идентификатор протокола характеризует используемый мостом протокол (для STP это код равен 0x000). Поле версия протокола хранит текущую версию протокола. Поле тип протокольного блока данных моста может принимать следующие значения:
0x00 |
протокольный блок данных моста конфигурации; |
0x80 |
протокольный блок данных моста объявления об изменении топологии. |
В настоящее время протоколом STP используются только два флага:
0x01 |
флаг изменения топологии; |
0x80 |
флаг подтверждения изменения топологии. |
Поле идентификатор корня содержит идентификатор корневого моста. В поле метрика маршрута до корня хранится оценка маршрута до корневого моста. В поле идентификатор моста записывается 8-байтовый код-идентификатор моста, передающего протокольный блок данных. Содержимое двух старших байт задается администратором сети, остальные 6 байт хранят универсальный или локальный адрес порта моста. Идентификатор порта представляет собой двух-байтовый код, присвоенный порту моста. Поле возраст сообщения содержит время в секундах, прошедшее с момента формирования конфигурационного сообщения. При ретрансляции протокольного блока конфигурации каждый мост увеличивает код в этом поле на величину, заданную протоколом управления. Величину кода в поле максимальный возраст задает корневой мост так, чтобы все остальные мосты имели согласованные значения возраста информации о конфигурации. Поле период актуализации определяет длительность периода посылки протокольных блоков конфигурации в секундах. Поле задержки передачи указывает на заданную корневым мостом величину времени в секундах, в течение которого порт не должен начинать передачу кадров после окончания реконфигурации сети.
Длина поля данных ограничивается временем, на которое станция может захватить маркер и не превышает 4502 октетов. Поле CRC служит для контроля целостности кадра при транспортировке. При расчете CRC используется образующий полином вида:
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
Алгоритм вычисления аналогичен тому, что используется в сетях Ethernet, контрольное суммирование охватывает поля адрес места назначения, адрес отправителя, управление кадром, маршрутная информация и данные.
Стартовый разделитель должен иметь уникальную сигнатуру, которая не может встретиться ни в одном из последующих полей. Оконечный разделитель нужен для того, чтобы обозначить конец кадра (или маркера), ведь длина пакетов переменна.
На физическом сетевом уровне используется дифференциальный манчестерский код с уровнями сигналов положительной и отрицательной полярности в диапазоне 3,0-4,5 В (сравните с +0,85 и -0,85 В для IEEE 802.3).