/
Author: Столлингс В.
Tags: компьютерные технологии оргсвязь информационные технологии интернет компьютерные сети
ISBN: 5-94723-327-4
Year: 2003
Text
СОВРЕМЕННЫЕ
КОМПЬЮТЕРНЫЕ
СЕТИ
2-Е ИЗДАНИЕ
В. СТОЛЛИНГС
[^ППТЕР
PH
PTR
В. СТОЛЛИНГС
СОВРЕМЕННЫЕ
КОМПЬЮТЕРНЫЕ СЕТИ
2-Е ИЗДАНИЕ
КНИГИ, КОТОРЫЕ НЕ СТАРЕЮТ!
КЛАССИКА COmPUTEA SCIENCE
Эта книга посвящена современным компьютерным сетям. В ней рассматривается
весь круг вопросов, связанных с проектированием двух типов сетей:
объединенных сетей, основанных на наборе протоколов TCP/IP, а также
сетей ATM. Эти две сетевые технологии доминируют в сфере высокоскоростных
сетей и для них характерно множество общих идей и подходов.
Во втором издании книги:
• обзор сетей ретрансляции кадров, сетей ATM и высокоскоростных
локальных сетей;
• моделирование трафика и оценка производительности;
• перегрузка и управление трафиком;
• маршрутизация в объединенных сетях;
• качество обслуживания в IP-сетях, протоколы RSVP, MPLS и RTP;
• сжатие данных.
Вильям Столлингс — доктор философии, признанный эксперт в области
компьютерных сетей и архитектуры компьютеров, автор более 30 книг
по этой тематике, к его советам прислушиваются производители компьютеров
и сетевого оборудования, разработчики программного обеспечения, ведущие
государственные исследовательские институты.
Посетите наш web-магазин: www.piter.comx
ISBN 5-94723-327-4
Ь^ППТЕР
WWW.PITER.COM
PH
PTR
HIGH-SPEED
NETWORKS
AND INTERNETS
PERFOMANCE
AND QUALITY OF SERVICE
2d edition
William Stallings
PH
PTR
Prentice Hall PTR
Upper Saddle River, New Jersey 07458
www.phptr.com
КЛАССИКА COmPUTEA SCIENCE
В. СТОЛЛИНГС
СОВРЕМЕННЫЕ
КОМПЬЮТЕРНЫЕ
СЕТИ
2-Е ИЗДАНИЕ
С^ППТЕР
Москва Санкт-Петербург Нижний Новгород • Воронеж
Ростов-на-Дону * Екатеринбург Самара
Киев Харьков Минск
2003
ББК 32.988.02
УДК 681.324
С81
С81 Современные компьютерные сети. 2-е изд. / В. Столлингс. — СПб.: Питер,
2003. — 783 с.: ил. — (Серия «Классика computer science»).
ISBN 5-94723-327-4
Эта книга посвящена современным аспектам развития высокоскоростных объединенных TCP/IP
и ATM сетей. В ней рассматривается широкий круг вопросов: от обработки одиночного пакета нли
ячейки в очереди иа маршрутизаторе или коммутаторе до универсальных методов резервирования
сетевых ресурсов для определенного типа трафика; от определения характеристик потока данных до
способов их сжатия, позволяющих снизить нагрузку на сеть. Книга будет интересна всем, кто хотел
бы получить представление о современном уровне развития, архитектуре и разработке высоко-
скоростных компьютерных сетей.
ББК 32.988.02
УДК 681.324
Информация, содержащаяся а данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не
менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарвнтировать абсолютную точ-
ность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
© Copyright 2002
ISBN 0-13-032221-0 (англ.) © Перевод на русский язык, ЗАО Издательский дом «Питер», 2003
ISBN 5-94723-327-4 © Издание на русском языке, оформление, ЗАО Издательский дом «Питер», 2003
Краткое содержание
Предисловие ............................................... 18
Часть I. История вопроса
Глава 1. Введение ......................................... 24
Глава 2. Архитектура протоколов ........................... 50
Глава 3. Протоколы TCP и IP ............................... 70
Часть II. Высокоскоростные сети
Глава 4. Ретрансляция кадров............................... 99
Глава 5. Сети ATM .................................................. 118
Глава 6. Высокоскоростные локальные сети ........................... 153
Часть III. Моделирование и оценка производительности
Глава 7. Обзор вероятностных и стохастических процессов... 193
Глава 8. Анализ очередей ..................................218
Глава 9. Самоподобный трафик ............................. 259
Часть IV. Перегрузка и управление трафиком
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях ...294
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных . 316
Глава 12. Управление трафиком в потоколе TCP ....................352
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM.402
Часть V. Маршрутизация в объединенных сетях
Глава 14. Теория графов и поиск путей с минимальной стоимостью...452
Глава 15. Протоколы внутренней маршрутизации.....................471
Глава 16. Протоколы внешней маршрутизации и групповая рассылка ..498
Часть VI. Качество обслуживания в IP-сетях
Глава 17. Интегрированные и дифференцированные службы .......... 527
Глава 18. Протоколы поддержания качества обслуживания .......... 571
6 Краткое содержание
Часть VII. Сжатие данных
[лава 19. Теоретические основы сжатия данных ....................616
[лава 20. Сжатие без потерь .....................................630
Глава 21. Сжатие с потерями......................................660
Приложение А. Стандарты и организации по стандартизации .........698
Приложение В. Сокеты ............................................708
Словарь специальных терминов.....................................740
Сокращения ......................................................747
Список литературы ...............................................754
Алфавитный указатель ............................................767
Содержание
Предисловие............................................................18
История вопроса ....................................................... 18
Назначение книги...................................................... 18
Предполагаемая аудитория.............................................. 19
План книги............................................................ 19
Веб-сайт для преподавателей и студентов ................................20
Программирование сокетов .............................................. 20
Что нового во втором издании.......................................... 20
Благодарности ..........................................................22
От издателя перевода.................................................. 22
Часть I. История вопроса
Глава 1. Введение.......................................................24
1.1. Краткая история сетей..............................................25
Рост Интернета и Всемирной паутины.................................25
Появление ATM......................................................30
1.2. Потребность в скорости и качестве обслуживания................... 35
Появление высокоскоростных локальных сетей.........................35
Корпоративные потребности в глобальных сетях.......................37
Цифровая электроника...............................................37
Качество обслуживания в Интернете .................................38
1.3. Усовершенствованные сети TCP/IP и ATM ............................41
Объединенные IP-сети ..............................................42
Сети ATM ..........................................................44
1.4. Обзор книги........................................................46
Фундаментальные понятия протоколов и сетей ........................46
Высокоскоростные сети .............................................46
Моделирование и оценка производительности .........................46
Перегрузка и управление трафиком...................................47
Маршрутизация в объединенных сетях ................................47
Качество обслуживания в IP-сетях ..................................47
Сжатие.............................................................47
1.5. Ресурсы Интернета .................................................48
Веб-сайты для этой книги...........................................48
Другие веб-сайты...................................................49
Группы новостей USENET.............................................49
Глава 2. Архитектура протоколов.........................................50
2.1. Необходимость в архитектуре протоколов ........................... 50
2.2. Архитектура протоколов TCP/IP......................................51
Уровни набора протоколов TCP/IP ....................................51
8 Содержание
Протоколы TCP и UDP ..............................................53
Протоколы IP и IPv6 ..............................................54
Работа протоколов TCP и IP ...................................... 56
Приложения TCP/IP ................................................58
2.3. Модель OSI ...................................................... 59
2.4. Объединение сетей ................................................61
Маршрутизаторы ...................................................63
Пример объединения сетей......................................... 64
2.5. Рекомендуемые литература и веб-сайты............................. 66
2.6. Задания ......................................................... 68
Глава 3. Протоколы TCP и IP............................................70
3.1. Протокол TCP .....................................................70
3.2. Протокол UDP .................................................... 73
3.3. Протокол IP ......................................................74
Фрагментация и восстановление ....................................76
Адреса IPv4 ......................................................78
Поле типа службы .................................................79
Поле параметров IPv4..............................................83
3.4. Протокол IPv6 ....................................................83
Форматы IPv6 .....................................................84
Заголовок IPv6 ...................................................86
Заголовок параметров ретрансляционных участков ...................90
Заголовок фрагмента ..............................................92
Заголовок маршрутизации...........................................93
Заголовок параметров получателя ..................................94
3.5. Рекомендуемые литература и веб-сайты............................. 94
3.6. Задания ......................................................... 94
Часть II. Высокоскоростные сети
Глава 4. Ретрансляция кадров............................................99
4.1. Сети с коммутацией пакетов ....................................... 99
Базовые операции................................................. 100
Техника коммутации .............................................. 104
Маршрутизация ................................................... 106
Стандарт X. 25................................................... 107
4.2. Сети с ретрансляцией кадров ..................................... 109
История вопроса ................................................. 109
Архитектура ретрансляции кадров ................................. 111
Передача данных пользователя..................................... 113
Управление соединением ретрансляции кадров ...................... 115
4.3. Рекомендуемые литература и веб-сайты............................. 115
4.4. Задания ......................................................... 116
Глава 5. Сети ATM .....................................................118
5.1. Архитектура протоколов ATM ...................................... 119
5.2. Логические соединения ATM ....................................... 120
Применение соединения виртуального канала ....................... 123
Характеристики виртуального пути и виртуального канала .......... 124
Управляющие сигналы ............................................. 125
5.3. Ячейки ATM ...................................................... 126
Формат заголовка ................................................ 126
Содержание
9
Общее управление потоком........................................ 128
Контрольная сумма заголовка......................................130
5.4. Категории служб ATM............................................. 132
Службы реального времени........................................ 133
Службы не реального времени .................................... 134
5.5. Уровень адаптации ATM .......................................... 136
Службы AAL...................................................... 137
Протоколы AAL .................................................. 138
5.6. Рекомендуемые литература и веб-сайты............................ 149
5.7. Задания ........................................................ 150
Глава 6. Высокоскоростные локальные сети .............................153
6.1. Появление высокоскоростных локальных сетей ..................... 154
6.2. Ethernet ....................................................... 155
Классическая сеть Ethernet ..................................... 156
Варианты стандарта IEEE 802.3 со скоростью передачи данных 10 Мбит/с .... 160
Хабы и коммутаторы ............................................. 162
Коммутаторы 3-го уровня......................................... 165
Fast Ethernet .................................................. 167
Gigabit Ethernet................................................ 170
10-гигабитная сеть Ethernet......................................173
6.3. Fibre Channel .................................................. 174
Элементы архитектуры Fibre Channel ............................. 176
Архитектура протоколов Fibre Channel ........................... 177
Физические носители и топологии Fibre Channel .................. 178
Перспективы развития Fibre Channel ............................. 179
6.4. Беспроводные локальные сети .................................... 180
Применение беспроводных локальных сетей ........................ 180
Требования к беспроводным локальным сетям ...................... 182
Архитектура IEEE 802.11 ........................................ 183
Службы IEEE 802.11 ............................................. 185
Уровни протокола IEEE 802.11 ................................... 185
Физический уровень IEEE 802.11 ................................. 186
6.5. Рекомендуемые литература и веб-сайты............................ 188
6.6. Задания ........................................................ 189
Часть III. Моделирование и оценка производительности
Глава 7. Обзор вероятностных и стохастических процессов ..............193
7.1. Вероятность .................................................... 193
Определение вероятности ........................................ 193
Условная вероятность и независимость............................ 196
Теорема Байеса ................................................. 197
7.2. Случайные переменные ........................................... 198
Функции распределения и плотности............................... 199
Важные распределения ............................................200
Множественные случайные переменные...............................203
7.3. Стохастические процессы ........................................ 205
Статистики первого и второго порядка ............................206
Стационарные стохастические процессы ............................207
Спектральная плотность.......................................... 208
Независимые приращения...........................................209
Эргодичность ....................................................213
10 Содержание
7.4. Рекомендуемые литература и веб-сайты............................ 214
7.5. Задания .........................................................215
Глава 8. Анализ очередей..............................................218
8.1. Простой пример поведения очередей ...............................219
8.2. Цели анализа очередей............................................224
8.3. Модели очередей..................................................226
Очередь к одному серверу ........................................226
Очередь к нескольким серверам....................................229
Основные соотношения теории очередей.............................230
Допущения .......................................................232
8.4. Очередь к одному серверу ........................................233
8.5. Очередь к нескольким серверам .................................. 237
8.6. Примеры .........................................................238
Серверы баз данных ..............................................238
Вычисление процентилей...........................................239
Примеры очереди к серверам ......................................240
8.7. Очереди с приоритетами ......................................... 243
8.8. Сети очередей .................................................. 245
Разделение и объединение потоков данных..........................245
Цепочки очередей ................................................246
Теорема Джексона.................................................247
Приложение для сетей с коммутацией пакетов ......................247
8.9. Другие модели очередей ..........................................249
8.10. Оценка параметров модели .......................................250
Выбор дискретных данных .........................................250
Ошибки выборки ..................................................252
8.11. Рекомендуемые литература и веб-сайты............................253
8.12. Задания ........................................................254
Глава 9. Самоподобный трафик..........................................259
9.1. Самоподобие .....................................................259
9.2. Самоподобный трафик данных .................................... 263
Определение непрерывного во времени процесса.....................265
Определение дискретного во времени процесса......................268
Долгосрочная зависимость ........................................270
Медленно затухающие распределения ...............................271
9.3. Примеры самоподобного трафика .................................. 273
Трафик сетей Ethernet............................................273
Трафик Всемирной паутины.........................................276
Трафик SS7 ......................................................277
Трафики TCP, FTP и TELNET .......................................277
VBR-видео........................................................278
Детерминированная передача данных................................278
9.4. Влияние самоподобия на производительность........................279
Анализ сетей Ethernet/ISDN ......................................279
Ethernet-трафик .................................................279
Модель запоминающего устройства с самоподобными входными данными ... 281
Применимость самоподобных моделей трафика........................281
9.5. Моделирование и оценка самоподобного трафика данных .............283
График зависимости дисперсии от времени..........................283
График R/S ......................................................284
Оценочная формула Уиттла ........................................285
Содержание
11
9.6. Параметр Херста .................................................286
9.7. Рекомендуемые литература и веб-сайты.............................289
9.8. Задания .........................................................289
Часть IV. Перегрузка и управление трафиком
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях . . 294
10.1. Следствия перегрузки............................................295
Идеальная производительность ....................................297
Практическая производительность..................................297
10.2. Борьба с перегрузкой ...........................................300
Противодавление..................................................300
Сдерживающий пакет ..............................................301
Неявная сигнализация о перегрузке................................302
Явная сигнализация о перегрузке..................................302
10.3. Управление трафиком.............................................303
Справедливость...................................................304
Качество обслуживания ...........................................304
Резервирование ................................................. 304
10.4. Борьба с перегрузкой в сетях с коммутацией пакетов..............305
10.5. Борьба с перегрузкой в сетях ретрансляции кадров ...............306
Управление скоростью трафика ....................................307
Предотвращение перегрузки при помощи явной сигнализации .........311
10.6. Рекомендуемые литература и веб-сайты............................312
10.7. Задания ........................................................313
Глава 11. Управление потоком и контроль ошибок
на уровне передачи данных...........................................316
11.1. Необходимость управления потоком и контроля ошибок .............317
Управление потоком ..............................................317
Контроль ошибок .................................................320
11.2. Механизмы управления каналом....................................321
Остановка с ожиданием ...........................................321
Технология скользящего окна .....................................324
11.3. Производительность схемы ARQ....................................330
Схема ARQ с остановкой и ожиданием...............................331
Параметра ...................................................... 333
Еще раз про схему с остановкой и ожиданием ......................336
Схема ARQ для скользящего окна...................................337
11.4. Протокол HDLC...................................................341
Структура кадра протокола HDLC ..................................341
Работа протокола HDLC ...........................................344
11.5. Рекомендуемая литература .......................................349
11.6. Задания ........................................................349
Глава 12. Управление трафиком в протоколе TCP ........................352
12.1. Управление потоком в протоколе TCP .............................352
Влияние размера окна на производительность ......................355
Стратегия повторных передач......................................358
Адаптивный таймер повторной передачи ............................359
Параметры политики реализации протокола TCP .....................362
12.2. Борьба с перегрузкой в TCP......................................365
Управление потоком и контроль ошибок в TCP.......................366
12
Содержание
Управление повторными передачами при помощи таймера .............370
Управление окном ................................................375
12.3. Производительность протокола TCP в сетях ATM....................385
Архитектура протоколов...........................................386
TCP поверх UBR ..................................................388
TCP поверх ABR ..................................................396
12.4. Рекомендуемые литература и веб-сайты............................399
12.5. Задания ....................................................... 399
Глава 13. Управление трафиком и борьба
с перегрузкой в сетях ATM..........................................402
13.1. Требования к управлению трафиком и борьбе с перегрузкой в сетях ATM.403
Значение задержки и скорости передачи данных ....................404
Непостоянство времени доставки ячеек ............................405
13.2. Атрибуты трафика сетей ATM......................................408
Параметры трафика................................................410
Параметры качества обслуживания .................................412
Атрибуты борьбы с перегрузкой ...................................414
Другие атрибуты .................................................414
13.3. Структура управления трафиком...................................414
13.4. Управление трафиком.............................................416
Управление ресурсами при помощи виртуальных путей................416
Управление допуском к соединению ................................418
Контроль параметров использования ...............................420
Выборочное отбрасывание ячеек ...................................427
формирование трафика ............................................428
Явное прямое уведомление о перегрузке ...........................429
13.5. Управление трафиком в службе ABR................................429
Контроль скорости в службе ABR ..................................430
Формат ячейки управления ресурсами ..............................434
Распределение ресурсов в службе ABR..............................437
13.6. Управление трафиком в службе GFR................................442
Механизм обеспечения гарантий скорости...........................442
Согласованное определение для службы GFR ........................444
Механизм проверки приемлемости качества обслуживания ............445
13.7. Рекомендуемая литература .......................................446
13.8. Задания ........................................................448
Часть V. Маршрутизация в объединенных сетях
Глава 14. Теория графов и поиск путей
с минимальной стоимостью ..........................................452
14.1. Элементарные понятия теории графов .............................452
Ориентированный граф и взвешенный граф...........................454
Деревья .........................................................456
14.2. Поиск кратчайшего пути ........................................ 460
Алгоритм Дейкстры ...............................................462
Алгоритм Веллмана—Форда .........................................465
Сравнение алгоритмов ............................................466
14.3. Рекомендуемая литература .......................................467
14.4. Задания .............................................................
Содержание
13
Глава 15. Протоколы внутренней маршрутизации........................471
15.1. Принципы маршрутизации в объединенных сетях...................471
Функция маршрутизации ..........................................472
Автономные системы .............................................477
15.2. Протокол RIP..................................................479
Дистанционно-векторная маршрутизация ...........................479
Детали алгоритма RIP ...........................................482
формат RIP-пакета ..............................................485
Ограничения протокола RIP ......................................486
15.3. Протокол OSPF ................................................486
Маршрутизация с учетом состояния линий..........................487
Протокол OSPF...................................................489
Стоимость линий ................................................493
Области ........................................................494
Формат OSPF-пакета..............................................494
15.4. Рекомендуемые литература и веб-сайты..........................496
15.5. Задания ......................................................496
Глава 16. Протоколы внешней маршрутизации
и групповая рассылка..............................................498
16.1. Протоколы BGP и IDRP .........................................498
Маршрутно-векторная маршрутизация ..............................499
Протокол BGP....................................................500
Протокол IDRP ..................................................506
16.2. Групповая рассылка............................................507
Необходимые условия для групповой рассылки......................510
Протокол IGMP...................................................513
Расширение протокола OSPF для групповой рассылки................515
Протокол PIM ...................................................519
16.3. Рекомендуемые литература и веб-сайты..........................523
16.4. Задания ......................................................523
Часть VI. Качество обслуживания в IP-сетях
Глава 17. Интегрированные и дифференцированные службы .... 527
17.1. Архитектура интегрированных служб ............................528
Трафик в объединенных сетях ....................................529
Назначение архитектуры ISA .....................................531
Компоненты архитектуры ISA......................................533
Службы архитектуры ISA..........................................534
17.2. Дисциплина очередей...........................................537
Справедливая организация очередей ..............................538
Разделение процессора...........................................539
Справедливая организация очередей с побитовым циклом ...........540
Обобщенная схема разделения процессора..........................543
Взвешенная справедливая организация очередей ...................544
17.3. Случайное раннее обнаружение .................................546
Мотивация.......................................................547
Цели разработки метода случайного раннего обнаружения ..........548
Алгоритм RED ...................................................548
17.4. Дифференцированные службы ................................... 553
Службы .........................................................
Поле DS ........................................................557
14
Содержание
Конфигурирование и работа дифференцированных служб ..............558
Поведение на ретрансляционном участке............................560
17.5. Трафик реального времени ...................................... 563
Характеристики трафика реального времени.........................564
Требования к взаимодействию в реальном времени...................566
Жесткие и гибкие приложения реального времени ...................566
17.6. Рекомендуемые литература и веб-сайты............................567
17.7. Задания ........................................................568
Глава 18. Протоколы поддержания качества обслуживания.................571
18.1. Протокол RSVP ..................................................572
Цели разработки и характеристики протокола RSVP..................575
Потоки данных ...................................................578
Работа протокола RSVP ...........................................579
Механизмы протокола RSVP ........................................584
18.2. Многопротокольная коммутация по меткам .........................586
История вопроса .................................................586
Функционирование архитектуры MPLS ...............................590
Организация стека меток .........................................593
Формат и размещение меток........................................594
ЕЕС-классы, LSP-пути и метки.....................................596
18.3. Протокол RTP ...................................................600
Архитектура протокола RTP .......................................601
Протокол передачи данных RTP ....................................603
Управляющий протокол RTP.........................................607
18.4. Рекомендуемые литература и веб-сайты............................613
18.5. Задания ........................................................613
Часть VII. Сжатие данных
Глава 19. Теоретические основы сжатия данных
.............616
19.1. Информация и энтропия...........................................616
Информация ......................................................617
Энтропия.........................................................619
Свойства функции энтропии .......................................621
19.2. Кодирование.....................................................622
Код Хаффмана ....................................................622
Энтропия и эффективность кодирования ............................625
Характеристики кода Хаффмана.....................................625
19.3. Рекомендуемая литература .......................................628
19.4. Задания ........................................................628
Глава 20. Сжатие без потерь .........................630
20.1. Методы группового кодирования .................................631
Подавление нулей ...............................................631
Групповое кодирование ..........................................632
20.2. Факсимильное сжатие............................................635
Модифицированный код Хаффмана...................................636
Модифицированный код READ ......................................639
Дважды модифицированный код READ ...............................641
20.3. Арифметическое кодирование.....................................642
Основная концепция .............................................643
Чистое арифметическое кодирование...............................646
Инкрементное арифметическое кодирование ........................649
Содержание 15
20.4. Алгоритмы совпадения строк.......................................650
Алгоритм LZ77 .................................................... 652
Алгоритмы LZ78 и LZW ..............................................654
20.5. Рекомендуемые литература и веб-сайты.............................657
20.6. Задания .........................................................658
Глава 21. Сжатие с потерями............................................660
21.1. Дискретное косинусное преобразование ............................660
Одномерное дискретное косинусное преобразование....................661
Двумерное дискретное косинусное преобразование ....................665
21.2. Волновое сжатие .................................................668
Элементарная волна ................................................669
Одномерное сжатие с помощью элементарных волн Хаара................671
Двумерное сжатие с помощью элементарных волн Хаара ................676
21.3. Стандарт JPEG ...................................................678
Последовательный режим DCT ........................................679
Прогрессивный режим DCT ...........................................683
Режим без потерь ..................................................686
Иерархический режим................................................687
JPEG 2000 ...................................................... 688
21.4. Стандарт MPEG....................................................690
Знакомство с алгоритмом видеосжатия ...............................690
Компенсация движения ..............................................691
Упорядочивание кадров .............................................694
Стандарты MPEG ....................................................695
21.5. Рекомендуемые литература и веб-сайты.............................696
21.6. Задания .........................................................697
Приложение А. Стандарты и организации по стандартизации .. . .698
А. 1. Важность стандартов..............................................698
А.2. Стандарты и регулирование.........................................699
А.З. Стандарты Интернета и Общество Интернета .........................700
Организации Интернета и публикация RFC.............................700
Процесс стандартизации ............................................702
Категории стандартов Интернета ....................................703
Другие типы RFC ...................................................704
А.4. Союз ITU..........................................................704
Сектор ITU-T ......................................................704
Расписание.........................................................705
А.5. Стандарты IEEE 802 .............................................. 705
Приложение Б. Сокеты...................................................708
6.1. Версии сокетов....................................................709
6.2. Сокеты, дескрипторы сокетов, порты и соединения ..................710
6.3. Коммуникационная модель клиент—сервер ............................712
Запуск программы с сокетами на изолированной машине под Windows ...713
Запуск программы с сокетами на одной сетевой машине под Windows....713
6.4. Элементы сокетов .................................................713
Создание сокета ...................................................713
Адрео сокета.......................................................714
Привязка к локальному порту........................................714
Представление данных и порядок следования байтов ..................715
Установление соединения с сокетом .................................716
Функция gethostbyname() ...........................................717
16 Содержание
Прослушивание входящих запросов на соединение от клиентов .....719
Согласие на установку соединения с клиентом ...................720
Передача и прием сообщений через сокет ........................721
Закрытие сокета................................................721
Коды ошибок....................................................722
Пример клиентской программы TCP/IP ............................723
Пример серверной программы TCP/IP..............................724
Б.5. Потоковые и дейтаграммные сокеты .............................726
Пример клиентской программы UDP ...............................727
Пример серверной программы UDP.................................728
Б.6. Управление программой во время выполнения ....................730
Неблокирующие обращения к сокетам .............................730
Асинхронный ввод-вывод.........................................731
Б.7. Удаленное выполнение консольного Windows-приложения ..........733
Локальная программа ...........................................734
Удаленная программа ...........................................736
Словарь специальных терминов ......................................740
Сокращения.........................................................747
Список литературы..................................................754
Алфавитный указатель...............................................767
А., моей жене и другу
Предисловие
Назначение этой книга состоит в том, чтобы помочь из
огромной массы материала вычленить ключевые вопро-
сы и важнейшие решения. На протяжении всего изло-
жения я старался честно и в меру своих сил объяснять,
что и почему происходило.
Уинстон Черчилль. Мировой кризис
История вопроса
В настоящее время высокоскоростные сети доминируют на рынке как глобальных,
так и локальных сетей. На рынке глобальных сетей появились две связанные друг
с другом тенденции. Вместо сетей с коммутацией пакетов, работающих на скорос-
тях в десятки и сотни килобайт в секунду, в качестве общественных и частных
сетей применяются сети ретрансляции кадров, передающие данные со скоростью
до 2 Мбит/с, а в последнее время появились сети ATM, работающие на скорости
155 Мбит/с и выше. В Интернете и частных корпоративных объединенных сетях
скорости передачи данных также выросли. Достаточно упомянуть создание в 1996 г.
магистрали с пропускной способностью 155 Мбит/с.
В течение многих лет наиболее распространенной локальной сетью была сеть
Ethernet с общей шиной, данные по которой передавались со скоростью 10 Мбит/с.
Ей на смену пришла коммутируемая сеть Ethernet, предоставляющая выделенную
линию с той же пропускной способностью каждой оконечной системе. За ней по-
следовала так называемая быстрая сеть Ethernet со скоростью 100 Мбит/с, затем
гигабитная сеть Ethernet и 10-гигабитная сеть Ethernet. В последние годы также
появились оптоволоконные локальные сети Fibre Channel, работающие на скоро-
стях до 3,2 Гбит/с, и беспроводные локальные сети со скоростями до 54 Мбит/с.
Столь быстрый рост высокоскоростных сетей стимулировал появление новых
приложений, популярность которых, в свою очередь, придала дополнительный
толчок ускоренному развитию сетей. Ключевыми движущими силами явились все
более широкое применение в приложениях фото- и видеоматериалов, а также рас-
тущая популярность Всемирной паутины.
Назначение книги
Книга посвящена высокоскоростным сетям. В центре нашего внимания будут на-
ходиться вопросы проектирования двух типов сетей: объединенных сетей, осно-
План книги
19
ванных на протоколе IP (объединенных IP-сетей) и наборе протоколов TCP/IP,
а также сетей ATM. Эти две сетевые технологии доминируют в сфере высокоско-
ростных сетей, и для них характерно множество общих идей и подходов.
Назначение книги — представить читателям соответствующий современным
требованиям обзор разработок в этой области. Центральные проблемы, с которы-
ми сталкивается разработчик сетей, — это поддержка трафика реального времени
и мультимедийного трафика, борьба с перегрузкой и предоставление разным при-
ложениям разных уровней качества обслуживания.
Предполагаемая аудитория
Книга предназначена как для профессионалов, так и для студентов. Для профес-
сионалов, занятых в данной области, она послужит справочником по основным
вопросам и будет полезна для самостоятельного изучения.
В качестве учебного пособия книга подойдет для выпускного или предпоследнего
курса. В ней углубленно исследуется множество важных тем и одновременно дается
краткий обзор необходимых элементарных вопросов. Части книги, начиная с треть-
ей, являются относительно независимыми и могут читаться в любом порядке.
План книги
Книга разделена на семь частей.
4 Часть I. История вопроса. Краткий обзор фундаментальных принципов с
рассмотрением набора протоколов TCP/IP и вопросов объединения сетей.
4 Часть II. Высокоскоростные сети. Обзор сетей ретрансляции кадров, се-
тей ATM и высокоскоростных локальных сетей.
4 Часть III. Моделирование и оценка производительности. Моделирование
трафика очень важно как при разработке и конфигурировании сетей, так и
для получения сетевых услуг. В этой части представляется учебный мате-
риал по анализу систем массового обслуживания в целях определения про-
пускной способности, задержки и размера буферов методами моделирова-
ния. Появляется все больше данных, свидетельствующих о самоподобии
большей части трафика высокоскоростных сетей, поэтому традиционный
анализ систем массового обслуживания для них непригоден. Исследуются
природа самоподобного трафика и методы моделирования.
4 Часть IV. Перегрузка и управление трафиком. Эта часть начинается с обсуж-
дения вопросов борьбы с перегрузкой и методов проектирования, применяе-
мых в обычных и объединенных сетях. С темой сквозного управления потоком
читатель знакомится на относительно простом примере управления пото-
ком на уровне передачи данных. Затем обсуждаются параметры производи-
тельности и методы, применяемые в протоколе TCP для достижения высо-
кой пропускной способности и борьбы с перегрузкой. Наконец, исследуются
вопросы управления трафиком и борьбы с перегрузкой в сетях ATM.
20
Предисловие
♦ Часть V. Маршрутизация в объединенных сетях. Посвящена основным
методам маршрутизации, включая дистанционно-векторную маршрутиза-
цию с учетом состояния линий и маршрутно-векторную маршрутизацию.
В этой части рассматривается также групповая маршрутизация.
♦ Часть VI. Качество обслуживания в IP-сетях. В сетях, основанных на про-
токоле IP, необходимы методы борьбы с перегрузкой и предоставления ак-
тивным приложениям обслуживания требуемого уровня качества. Начина-
ется рассмотрение этих методов с интегрированных и дифференцированных
служб. Затем исследуются важные протоколы, относящиеся к качеству об-
служивания, включая RSVP, MPLS и RTP.
♦ Часть VII. Сжатие данных. Завершающая часть книги посвящена методам
сжатия данных с потерями и без потерь.
В книгу также включены подробный словарь специальных терминов, список
часто используемых сокращений и список литературы. В каждой главе содержат-
ся задания, рекомендации по дальнейшему чтению и ссылки на веб-сайты по дан-
ной теме.
Веб-сайт для преподавателей и студентов
Этой книге посвящена веб-страница, призванная помочь студентам и преподавате-
лям. На этой странице содержатся ссылки на сайты по теме, рисунки и таблицы к дан-
ной книге в формате PDF (Adobe Acrobat), слайды для PowerPoint, а также спи-
сок рассылки. Эта веб-страница расположена по адресу http://WillianiStaHings.com/
HsNet2e.html. Список рассылки составлен таким образом, чтобы преподаватели,
использующие эту книгу, могли обмениваться информацией, предложениями
и вопросами друг с другом, а также с автором. Когда будут обнаружены опечатки
и другие ошибки, на сайте WilliamStallings.com будет опубликован их список. Нако-
нец, я занимаюсь поддержкой сайта Computer Science Student Resource, доступного
по адресу http://WiUiamStallings.com/StudentSupport.htmL
Программирование сокетов
В этой книге имеется описание сокетов (приложение Б), включая конспективный
обзор, дискуссию о важности этого средства, а также примеры использования со-
кетов и ссылки на дополнительную информацию в Паутине. Программирование
сокетов представляет собой «легкую* тему, благодаря которой можно создать весь-
ма практичные проекты для студентов.
Что нового во втором издании
За четыре года, прошедших с выхода первого издания книги, в рассматриваемой
области продолжался рост инноваций и усовершенствований. Я по мере возмож-
Что нового во втором издании
21
ности пытался отразить эти изменения, не сбившись на детали и сохранив гло-
бальность темы. Первое издание книги широко обсуждалось многими профессо-
рами, преподающими данный предмет, и профессионалами, работающими в этой
области. В результате во многих местах повествование было сделано более понят-
ным и насыщенным, были улучшены иллюстрации. Кроме того, появился ряд но-
вых тем, проверенных «в полевых условиях».
Помимо подобных усовершенствований, нацеленных на улучшение педагоги-
ческих характеристик книги, технические аспекты книги были приведены в соот-
ветствие с сегодняшним днем. Кроме того, книга была реорганизована, части и гла-
вы книги были сгруппированы по-новому. Ниже перечислены некоторые из
наиболее важных изменений.
4- Борьба с перегрузкой. Теперь этой теме посвящена отдельная глава, что по-
зволило более отчетливо представить соответствующие вопросы.
4- Дифференцированные службы. С момента публикации первого издания по-
явилось множество разработок в области поддержки различного мультиме-
дийного и чувствительного к временным параметрам трафика в Интернете.
Наиболее важной разработкой и, возможно, наиболее важным средством
предоставления обслуживания различного уровня качества в IP-сетях яв-
ляются дифференцированные службы. В этом издании имеется детальное
обсуждение дифференцированных служб.
♦ Гарантированная скорость кадров (GFR). С момента выхода первого изда-
ния для ATM была стандартизирована новая служба — GFR. Служба GFR
специально разработана для поддержки подсетей IP-магистрали. В данном
издании предоставляется описание службы GFR, а также исследуются ее
базовые механизмы.
-4 Многопротокольная коммутация пометкам (MPLS). Архитектура MPLS,
описываемая в данном издании, представляет собой чрезвычайно важную
новую технологию, применяемую в Интернете.
4- Детали TCP/IP. Была добавлена новая глава по истории протоколов ТСР/
IP, в которую вошел материал, в первом издании «разбросанный» по всей
книге. Этот материал жизненно важен для понимания темы качества обслу-
живания и вопросов производительности в 1Р-сетях.
4- Высокоскоростные локальные сети. Глава о высокоскоростных локальных
сетях была в значительной степени обновлена и пересмотрена. Был добав-
лен материал о сети Ethernet с пропускной способностью 10 Гбит/с. Кроме
того, теперь эта глава содержит информацию о сети Fibre Channel и высоко-
скоростных беспроводных локальных сетях.
4- Сети ретрансляции кадров. Несмотря на важность и растущую популяр-
ность сетей ATM ретрансляция кадров остается наиболее распространенной
технологией высокоскоростных глобальных сетей. Соответственно, в дан-
ном издании уделено внимание протоколу ретрансляции кадров и методам
борьбы с перегрузкой в сетях ретрансляции кадров.
4- Волновое сжатие. Волновое сжатие становится все более популярной тех-
нологией, поэтому эта тема также затронута в данном издании.
22
Предисловие
Благодарности
Эта книга обязана своим появлением многим людям, уделившим ей свое драго-
ценное время и внимание. Это Чунминг Циао (Chunming Qiao, университет шта-
та Нью-Йорк, Баффало), Кен Кристенсен (Ken Christensen, университет Южной
Флориды), Джордж Полизоа (George Polyzoa, Калифорнийский университет в
Сан-Диего), Йинг Сун (Ying Sun, университет Род-Айленда) и Джордж Шитс
(George Scheets, штат Оклахома).
Я также хотел бы поблагодарить тех, кто предоставил детальные технические
обзоры отдельных глав. Это Дэвид Банд (David Bande), Дан Ли (Dan Li), Йен Сазер-
лэнд (Ian Sutherland), Вэй Жоу (Wei Zhou), Марк Тимме (Marc Timme), Брайан
Борчерз ( Brian Borchers), Балбир Сингх (Balbir Singh), Дин Ньютон (Dean Newton),
Пол А. Уоттерс (Paul A. Watters), Питер Рабинович (Peter Rabinovitch), Стивен
Кэмпбел-Робсон (Stephen Campbell-Robson), Роджер Л. Багула (Roger L. Bagula),
Дайэт Остри (Diet Ostry), Ларс Кристенсен (Lars Kristensen), Сан Скулраттана-
кулчай (San Skulrattanakulchai), Ливен Маршал (Lieven Marchand), Роберт Коль-
тер (Robert Kolter), Крис Полет (Chris Pollett) и Стефан Катценбайсер (Stefan
Katzenbeisser).
Я также должен выразить благодарность Дину Ньютону (Dean Newton), раз-
работавшему слайды PowerPoint для этой книги, и Зорнице Геновой (Zornitza
Genova) за предоставление материала по сокетам и программным проектам с ис-
пользованием сокетов.
Кроме того, я признателен тем, кто внес свой вклад в разработку заданий. Это
Ахмед А-Г Хелми (Ahmed A-G Helmy, университет Южной Калифорнии) и Фран-
клин Мендивил (Franklin Mendivil, университет Ватерлоо).
Наконец, я бы хотел поблагодарить всех тех, кто отвечает за публикацию кни-
ги, кто просто великолепно делает свою повседневную работу. Это штат сотруд-
ников издательства Prentice Hall: мои редакторы Тони Холм (Toni Holm) и Алан
Апт (Alan Apt), менеджер Роуз Ксрнан (Rose Kernan). Также я хочу поблагодарить
Джейка Уорда (Jake Warde) из Warde Publishers, занимавшегося приложениями
и рецензиями; Джоанну В. Померанц (Joanna V. Pomeranz) из V&M, ответствен-
ную за выход книги в печать, и редактора Патрицию М. Дэйли (Patricia М. Daly).
Благодаря этой помощи в книге почти не осталось того, за что я нес бы полную
единоличную ответственность. Тем не менее я могу с гордостью заявить, что со-
вершенно самостоятельно, безо всякой посторонней помощи расставил все ссыл-
ки на литературу.
От издателя перевода
Ваши замечания, предложения, вопросы отправляйте по адресу электронной поч-
ты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на веб-сайте издательства
http://www.piter.com.
Часть I
История вопроса
Назначение части I — дать базовые сведения и контекст для остальных частей кни-
ги. Здесь представлены фундаментальные концепции протоколов обмена данны-
ми между компьютерами.
♦ Глава 1. Введение. Глава 1 представляет собой обзор всей книги. По суще-
ству, в книге затрагиваются два вопроса: производительность и качество
обслуживания в компьютерных сетях. Производительность и качество об-
служивания — это ключевые понятия для высокоскоростных сетей, вклю-
чая сети ретрансляции кадров и сети ATM, а также объединенные сети, такие
как Интернет и интранет.
♦ Глава 2. Архитектура протоколов. В основе обмена данными в компьютер-
ных сетях и в основе работы распределенных приложений лежит программ-
ное обеспечение связи, которое не зависит от приложений и избавляет их от
большей части задач, связанных с обеспечением надежного обмена данны-
ми. Это программное обеспечение связи организовано в архитектуру про-
токолов, основу которой составляет набор протоколов TCP/IP. В главе 2
вводится понятие архитектуры протоколов и предоставляется обзор набора
протоколов TCP/IP. Кратко описывается также другая архитектура — эта-
лонная модель OSI. Наконец, обсуждаются концепция объединения сетей
и вопросы использования для этой цели набора протоколов TCP/IP.
♦ Глава 3. Протоколы TCP и IP. В главе 3 протоколы TCP и IP рассматрива-
ются более подробно, включая форматы их заголовков и механизмы рабо-
ты. Для протокола IP описываются текущие версии IPv4 и IPv6.
Глава 1
Введение
Если читатель хочет понять эту историю и точку зрения, с которой
она изложена, он должен следовать за мыслью автора во всех прин-
ципиальных аспектах причинно-следственных отношений. Ему сле-
дует познакомиться не только с положением дел в армии и флоте на
момент начала войны, по также и с событиями, послужившими ему
причиной. Он должен познакомиться с адмиралами и генералами; он
должен изучить организацию флотов и армий, а также основные
принципы их стратегий на море и на суше; он не должен уклоняться
даже от изучения устройства кораблей и пушек; он должен понимать
все нюансы объединения современных государств в союзы и медлен-
но растущего антагонизма между ними; он должен сопоставить этот
антагонизм с более скромной, но. тем не менее, неизбежной борьбой
партий и с взаимодействием политических сил и личностей.
Уинстон Черчилль, Мировой кризис
Предмет данной книги охватывает очень широкий круг вопросов: от таких дета-
лей, как обработка одиночного пакета или ячейки в очереди на маршрутизаторе
или коммутаторе, до универсальных методов резервирования сетевых ресурсов для
заданного типа трафика; от определения характеристик потока данных до спосо-
бов сжатия данных, позволяющих снизить нагрузку на сеть. Если вы взглянете на
оглавление книги, то увидите, что эти и подобные им темы будут рассматриваться
на протяжении всей книги.
Центральная тема книги связана с необходимостью поддерживать трафик боль-
шого объема с различными требованиями качества обслуживания в сетях, рабо-
тающих на очень высоких скоростях передачи данных. В качестве платформ, на
которых будут рассматриваться соответствующие аспекты дизайна, мы будем
использовать объединенные IP-сети и сети ATM (Asynchronous Transfer Mode —
асинхронный режим передачи)1.
В сетях обоих типов (как в объединенных сетях, так и в сетях ATM) в настоя-
щее время наблюдаются кардинальные перемены. В объединенных сетях трафик
1 Мы будем использовать термин объединенная IP-сеть (IP-based internet) для обозначения набора
любых сетей, взаимодействующих через .маршрутизаторы по протоколу IP (Internet Protocol — Ин-
тернет-протокол) из набора протоколов TCP/IP (Transmission Control Protocol/Internet Protocol —
протокол управления передачей/Интернет-протокол). В сетях ATM применяются протоколы ATM
и близкие им протоколы.
1.1. Краткая история сетей
25
вырос во много раз и теперь включает в себя мультимедиа и данные реального вре-
мени. В случае ATM присущая этой сети высокая скорость передачи данных по-
служила причиной использования ее не только для передачи звука и изобра-
жений, но также и в последнее время во все большей степени неравномерного
трафика на базе стека TCP/IP (Transmission Control Protocol/Internet Protocol —
протокол управления передачей/Интернет-протокол). С технической точки зре-
ния такие быстрые и беспрецедентные изменения представляют массу интерес-
ных проблем в области протоколов, борьбы с перегрузкой, управления трафиком
и определения его параметров.
С другой стороны, для владельца корпоративных информационных систем или
для конечного потребителя интересы фокусируются на удовлетворении потреб-
ностей приложений. Хотя темой этой книги не является управление и она не ад-
ресована конечным пользователям, мы все же осветим вопросы управления высо-
коскоростными сетями и трафиком, кратко обсудив требования, формируемые
пользователями. Эго и является целью данной главы.
Глава начинается с обзора тенденций в эволюции объединенных IP-сетей и сетей
ATM. Далее рассматриваются некоторые из движущих факторов, формирующих
спрос на высокоскоростные сети с гарантиями качества обслуживания (Quality of
Service, QoS). Затем мы обсудим типы служб, предоставляемых объединенными
IP-сетями и сетями ATM. Завершается эта вводная глава кратким описанием
остальных глав книги и перечислением ресурсов Интернета, которые могут ока-
заться полезными читателям и преподавателям.
1.1. Краткая история сетей
За последние годы появилось множество новых протоколов и технологий как для
объединенных IP-сетей, так и для сетей ATM. Они будут кратко рассмотрены
в разделе 1.2. В данном разделе мы рассмотрим некоторые из факторов, служащих
движущей силой этих новых разработок.
Рост Интернета и Всемирной паутины
Доминирующим фактором развития новых протоколов и механизмов передачи
данных является рост Интернета. Этот рост, в свою очередь, в основном обуслов-
лен ростом Всемирной паутины (World Wide Web, WWW). Сомнительно, чтобы
кто-либо, где-либо, пользующийся компьютерным оборудованием, не слышал бы
об этих важных изменениях. Интернет, Всемирная паутина и связанные с ними
приложения изменили способ использования вычислительных ресурсов и способ
использования персональных компьютеров их владельцами.
Интернет
Сегодняшний Интернет обязан своему появлению объединенной сети ARPANET,
которая начиналась как скромный эксперимент в новой тогда технологии комму-
тации пакетов (табл. 1.1). Сеть ARPANET была развернута в 1969 г. и состояла
поначалу всего из четырех узлов с коммутацией пакетов, используемых для взаи-
26 Глава 1. Введение
модействия горстки хостов и терминалов. Первые линии связи, соединявшие узлы,
работали на скорости всего 50 Кбит/с. Сеть ARPANET финансировалась управлени-
ем перспективного планирования научно-исследовательских работ ARPA (Advanced
Research Projects Agency) министерства обороны США и предназначалась для
изучения технологии и протоколов коммутации пакетов, которые могли бы ис-
пользоваться для кооперативных распределенных вычислений.
Таблица 1.1. Хронология развития Интернета
Год Событие
1966 1969 1972 1973 1975 1980 1981 1983 1986 1990 1991 1991 1991 1992 1995 1996 1998 2000 Эксперимент с коммутацией пакетов управления ARPA Первые работоспособные узлы сети ARPANET Изобретение распределенной электронной почты Первые компьютеры, подключенные к сети ARPANET за пределами США Сеть ARPANET передана в ведение управления связи министерства обороны США Начинаются эксперименты с TCP/IP Каждые 20 дней к сети добавляется новый хост Завершен переход на TCP/IP Создана магистраль NSFnet Сеть ARPANET прекратила существование Появление Gopher Изобретение Всемирной паутины Выпущена система PGP Появление Mosaic Приватизация магистрали Интернета Построена магистраль ОС-3 (155 Мбит/с) Число зарегистрированных доменных имен превысило 2 млн Количество индексируемых веб-страниц превысило 1 млрд
Некоторые ранние приложения, разработанные для сети ARPANET, обладали
новой функциональностью. Первыми двумя важными приложениями были TELNET
и FTP. Приложение TELNET предоставило язык для общения терминалов с уда-
ленными компьютерами. Когда появилась сеть ARPANET, для каждой компью-
терной системы требовались собственные терминалы. Приложение TELNET ста-
ло общим знаменателем для терминалов. Достаточно было написать для каждого
компьютера программное обеспечение, поддерживающее «терминал TELNET»,
чтобы один терминал мог взаимодействовать с компьютерами всех типов. Прото-
кол FTP (File Transfer Protocol — протокол передачи файлов) предложил сходную
открытую функциональность, обеспечивая прозрачный перенос файлов с одного
компьютера на другой по сети. Это не так тривиально, как может показаться, так как у
разнотипных компьютеров могут различаться размеры слов, биты в словах могут
храниться в неодинаковом порядке или использоваться разные форматы слов.
Хотя TELNET и FTP были (и остаются) полезными, первым приложением,
совершившим переворот в сознании пользователей компьютеров сети ARPANET,
стала электронная почта. До сети ARPANET существовали системы электронной
почты, но все они были однокомпыотерными системами. В 1972 г. Рэй Томлин-
сон (Ray Tomlinson) из компании BBN (Bolt Beranek and Newman) написал пер-
1.1. Краткая история сетей
27
вый пакет, предоставляющий распределенные почтовые услуги в компьютерной
сети из нескольких компьютеров. Уже к 1973 г. исследования управления ARPA
показали, что три четверти всего трафика сети ARPANET составляла электронная
почта [107]. Польза электронной почты оказалась столь велика, что все больше
пользователей желало подключиться к сети ARPANET, в результате чего возрас-
тала потребность в добавлении новых узлов и использовании высокоскоростных
линий. Таким образом, появилась тенденция, сохраняющаяся по сей день.
По мере того как сеть ARPANET росла, она стала привлекать не только иссле-
дователей государственных и академических учреждений, но также и сотрудни-
ков министерства обороны США. Конфигурация сети и управление сетью стали
важными вопросами, так же как и надежность, и доступность сети. Соответствен-
но, в 1975 г. управление сетью ARPANET было передано от исследовательского
управления ARPA управлению связи министерства обороны США (Defense
Communications Agency).
Технология коммутации каналов оказалась столь успешной, что управление
ARPA применило ее в тактической радиосвязи (Packet Radio) и в спутниковой
связи (SATNET). Поскольку все три сети работали в принципиально различных
средах, значения таких параметров, как, например, максимальный размер пакета,
сильно различались в каждом случае. Столкнувшись с проблемой объединения этих
сетей, Винт Серф (Vint Cerf) и Боб Кан (Bob Kalin) из управления ARPA начали
работы по разработке методов и протоколов объединения сетей, то есть передачи
сообщений через произвольные многочисленные сети с коммутацией пакетов.
В мае 1974 г. они опубликовали весьма важную статью [44], кратко описывающую
их подход к созданию протокола TCP. Их предложения были скорректированы
и дополнены сообществом ARPANET. Основной вклад в эту работу был внесен
Европейским сетевым сообществом, в частности такими объединениями, как Cyclades
(Франция) и EIN. В результате были разработаны протоколы TCP и IP, сформиро-
вавшие основу набора протоколов TCP/IP, являющегося базисом сети Интернет,
в которую ARPANET вошла всего лишь как одна из множества объединенных
сетей. В 1982-1983 гг. сеть ARPANET была переведена со своего оригинального
протокола NCP на TCP/IP. Многие сети по всему миру были объединены в те вре-
мена с помощью этой технологии. Тем не менее, доступ к сети ARPANET был ог-
раничен организациями, заключившими контракт с управлением ARPA.
Подключение Национального научного фонда США
В 1980-1981 гг. Национальный научный фонд США (National Science Foundation,
NSF) расширил поддержку на другие группы исследователей в области кибернети-
ки, организовав сеть CSNET (Computer+Science Network). В 1986 г. Национальный
научный фонд расширил Интернет-поддержку, охватив также и другие научные
дисциплины, основав магистраль NSFNET. Изначально магистраль NSFNET была
спроектирована для того, чтобы объединить шесть основанных Национальным
научным фондом суперкомпьютерных центров, расположенных в различных штатах
США, друг с другом, а также связать сами центры с пользователями суперкомпь-
ютеров по всей стране. Наконец, Национальный научный фонд предоставил воз-
можность соединения со своей магистралью региональных сетей с коммутацией
пакетов по всей стране. В 1990 г. сеть ARPANET прекратила свое существование.
28
Глава 1. Введение
Политика приемлемого использования
Удивительный рост Интернета не остался незамеченным в мире коммерции. Тем
не менее, правительства многих государств (включая США вплоть до 1995 г.) про-
должали субсидировать магистраль Интернета в собственных странах. Многие из
этих государств проводили политику приемлемого использования (acceptable use),
ограничивающую коммерческую активность. Зачастую использование Интернета
ограничивалось исследовательским и учебным применением. Поскольку в США
магистраль Интернета финансировалась Национальным научным фондом, сложи-
лось убеждение, что использование магистрали не должно выходить за рамки ис-
следовательских, образовательных и государственных целей. Это мнение было
утверждено в принятой политике приемлемого использования Интернета. «Куль-
тура» Интернета также наложила дополнительные информационные ограничения
на его коммерческое использование.
Точки доступа в Интернет
В 1991 г. всего три компании: General Atomics, управлявшая сетью CERFnet
(региональной сетью Калифорнии), Performance Systems International, управляв-
шая сетью PSINet (коммерческим отделением Нью-Йоркской региональной сети
NYSERnet), и UUNET Technologies, коммерческий поставщик услуг Интернета,
владевший сетью Alternet, — предоставляли практически все услуги TCP/IP на тер-
ритории США. На своих собственных сетях они не были обязаны подчиняться
требованиям политики приемлемого использования, установленной Национальным
научным фондом, так как эти сети не задействовали магистраль NSF. Однако чтобы
соединить свои сети, им приходилось пользоваться магистралью NSF, подпадая
в результате под требования политики. Чтобы решить эту проблему, они сформи-
ровали службу коммерческого информационного обмена (Commercial Information
eXchange, CIX). Изначально это был механизм для обмена трафиком между тремя
сетями компаний-основателей, работавший на маршрутизаторе Западного Бере-
га, так что пользователи каждой сети могли связываться с пользователями других
сетей без дополнительной платы. По мере того как на рынке появлялись новые
поставщики услуг, они также находили эту концепцию полезной и присоединялись
к CIX. К 1996 г. в CIX входило 147 сетей. Одна из особенностей CIX заключается
в том, что обмен данными между сетями не облагается платой, пропорциональной
трафику. В 1994 г. аналогичный пункт связи, LINX (London Internet Exchange),
был сформирован в Англии. В 1996 г. к нему было подключено 24 сети. В 1991 г.
правительство США объявило, что после 1995 г. оно более не будет финансиро-
вать Интернет. Как часть плана приватизации правительство объявило о форми-
ровании пунктов связи, названных точками доступаксети (network access points).
Сейчас существует три таких пункта, около Нью-Йорка, Чикаго и Сан-Францис-
ко. Кроме того, есть два региональных обменных узла (Metropolitan Area Exchange,
МАЕ), Восточный (МАЕ East) и Западный (МАЕ West). Когда в 1995 г. прави-
тельство США приватизировало государственную магистраль, то, по крайней мере,
часть Интернета, находящаяся на территории США, оказалась открытой для тео-
ретически ничем не ограниченной коммерческой активности. На протяжении не-
скольких последних лет в коммерческом домене .сот наблюдался самый высокий
рост, превышающий рост образовательного домена .edu, ранее доминировавшего
по скорости регистрации хостов в Интернете.
1.1. Краткая история сетей
29
Всемирная паутина
Весной 1989 г. в Европейском центре ядерных исследований (Conseil Europeen
pour la Recherche Nucleaire, CERN) Тим Бернерс-Ли (Tim Berners-Lee) предложил
идею распределенной гипертекстовой технологии для упрощения обмена по Ин-
тернету информацией о научных исследованиях. Почти ровно через два года в цен-
тре CERN был разработан прототип Паутины, для которой в качестве платформы
использовался компьютер NeXT. К концу 1991 г. центр CERN выпустил браузер
с интерфейсом командной строки, предназначенный для ограниченного числа
пользователей. Взрывоподобный технологический прорыв произошел с появле-
нием первого браузера с графическим интерфейсом, Mosaic, разработанного в цен-
тре NCSA (National Center for Supercomputing Applications — Национальный центр
по применению суперкомпьютеров) в университете штата Иллинойс Марком
Андреассоном (Mark Andreasson) и другими в 1992 г. За короткое время по Интер-
нету разошлось два миллиона копий браузера Mosaic. За несколько лет формат
веб-адресов в виде URL (Uniform Resource Locator — унифицированный указатель
информационного ресурса) стал повсеместным. Теперь адреса в Паутине можно
встретить повсюду — и в газете, и на телевидении. На рис. 1.1, л показан экспонен-
циальный рост Паутины1.
Рис. 1.1. Рост Интернета
1 Обратите внимание па использование логарифмической шкалы. Начальные сведения по логарифми-
ческим шкалам можно найти на сайте ресурсов для студентов, специализирующихся в области кибер
нетики, по адресу WilliamStallings.com/StudentSupport.html.
30
Глава 1. Введение
Подобно тому как электронная почта способствовала быстрому росту сети
ARPANET, Паутина вызвала стремительный рост Интернета. Рисунок 1.1, б иллю-
стрирует этот впечатляющий подъем. Сегодня количество хостов, соединенных с
сетями Интернета, превышает 100 млн, количество пользователей исчисляется
сотнями миллионов, а количество стран с доступом к Интернету исчисляется сот-
нями. Уже одно только огромное число пользователей диктует увеличение мощ-
ностей Интернета. Но что еще важнее, природа трафика, все более состоящего из
графики и трафика реального времени, ложится тяжким бременем на Интернет.
Рост Интернета и эволюция природы его трафика как в зеркале отражается в
бесчисленных корпоративных сетях, развившихся из простых выделенных линий
или каналов с коммутацией пакетов между сайтами в сложные, связанные с Ин-
тернетом частные сети с поддержкой интранет-приложений. Таким образом, тре-
бования производительности, накладываемые на Интернет, отражаются в этих
частных сетях, поэтому и протоколы, и методы, обсуждаемые в этой книге, приме-
нимы как к Интернету, так и к частным сетям.
Появление ATM
Примерно столь же важное влияние, как технология TCP/IP, на развитие сетей
оказала технология ATM. Как и о TCP/IP и Интернете, о технологии ATM можно
рассказать много интересного. Здесь предлагается очень краткое описание.
Первые телефонные и телеграфные сети основывались на технологии аналого-
вой коммутации и передачи, а также на коммутации каналов. В таком виде они
сохранялись много десятилетий. Однако, в конце концов, в этих сетях стали при-
меняться цифровые компьютеризованные коммутаторы и технологии цифровой
передачи, хотя при этом сами сети оставались сетями с коммутацией каналов.
Такие сети обычно называют интегрированными цифровыми сетями (Integrated
Digital Network, IDN). В этом названии отражается интеграция коммутации и пере-
дачи при помощи цифровых технологий. Идея IDN была предложена еще в 1959 г.
[225]. Вскоре последовала и реализация. Первая цифровая система с Т-носителем
была предложена на рынке корпорацией AT&T в 1962 г., а первый крупномас-
штабный цифровой коммутатор с разделением времени 4ESS был представлен
компанией Western Electric в 1976 г.
Эволюция общественных телефонных линий от аналоговых к цифровым была
вызвана необходимостью предоставления экономичных услуг голосовой связи.
Таким образом, IDN объединила протяженность телефонной сети со способно-
стью передачи данных цифровых сетей в структуру, получившую название ISDN
(Integrated Services Digital Network — цифровая сеть с интегрированными служ-
бами). В данном контексте слово «интегрированными» означает, что по одним и
тем же линиям передачи через одни и те же цифровые узлы обмена одновременно
передается оцифрованный голос и разнообразный цифровой трафик. Основной
особенностью сети ISDN является незначительная плата за предоставление услуг
передачи данных по цифровой телефонной сети, при этом никакой дополнительной
платы за передачу голоса не взимается, так как сеть IDN изначально предназнача-
лась для предоставления подобной услуги.
1.1. Краткая история сетей
31
ISDN и ретрансляция кадров
Развитие ISDN направлялось набором рекомендаций, выпускаемых сектором
ITU-T* Международного союза телекоммуникаций. Эти рекомендации, или стан-
дарты, были впервые выпущены в 1984 г., более полные версии появились в по-
следующие годы.
Интересно рассмотреть историю интереса Международного союза телеком-
муникаций к сетям ISDN. В 1968 г. Международный консультативный комитет
по телефонии и телеграфии (CCITT) создал специальную исследовательскую
группу D (предшественницу сегодняшней группы XVIII, отвечающую за ISDN
в ITU-T), чтобы рассмотреть широкий спектр вопросов, связанных с использо-
ванием цифровых технологий в общественных телефонных сетях. На каждой
пленарной ассамблее исследовательская группа получала задание на следующий
четырехлетний период. Принципиальные вопросы каждого периода показаны
в табл. 1.2. Эти вопросы отражают эволюцию интереса Международного союза
телекоммуникаций к сетям ISDN. Фокус смещается с цифровой технологии на
сети IDN, а затем на сети ISDN.
Таблица 1.2. Основной вопрос, задаваемый специальной исследовательской
группе D (1969-1976) и исследовательской группе XVIII (1977-1992)
Период исследований
1969-1972 Планирование цифровых систем
1973-1976 Планирование цифровых систем и интеграции услуг
1977-1980 Общие аспекты IDN
1981-1984 Общие сетевые аспекты IDN
1985-1988 Общие аспекты ISDN
1989-1992 Общие сетевые аспекты ISDN
Представление о сетях ISDN сформировалось уже в течение первого периода
исследований. Выпущенная в 1972 г. рекомендация G.702 содержала следующее
определение ISDN: «Интегрированная цифровая сеть, в которой для установки
соединений для различных служб, например телефонии и передачи данных, ис-
пользуются одни и те же цифровые коммутаторы и цифровые пути». В тот момент
не было информации о типе сети, способной интегрировать цифровые коммутато-
ры и пути, или о том, как сеть может интегрировать различные службы. Тем не
менее, это было осознание эволюции, которая могла произойти с помощью циф-
ровой технологии.
В период исследований с 1977 по 1980 г. комитет CCITT осознал, что эволюция
в направлении к цифровой сети идет полным ходом, и ее важность превосходит
значимость стандартизации индивидуальных цифровых систем и оборудования.
Таким образом, основное внимание было обращено на интеграционные аспекты
1 International Telecommunications Union-Telecommunications (Международный союз телекомму-
никаций, сектор телекоммуникаций). Ранее эта организация была известна под именем CCITT
(Consultative Committee for International Telephone and Telegraphy — Международный консультатив-
ный комитет по телефонии и телеграфии). Новое сокращение на 20 % короче, но, увы, новое название
на 22 % длиннее.
32
Глава 1. Введение
цифровой сети и на интеграцию услуг в сети IDN. Во время данного периода ис-
следований сформировались два основных направления разработок.
♦ Интеграция услуг основывается на предоставлении стандартизированного
интерфейса UNI (User-to-Network Interface — интерфейс пользователь-
сеть), позволяющего пользователю запрашивать различные службы при
помощи унифицированного набора протоколов.
♦ Телефонная сеть будет преобразовываться в сеть ISDN.
К концу этого периода появился первый стандарт ISDN. Рекомендация G.705
была всего лишь обшей декларацией принципов и целей для ISDN. С началом сле-
дующего периода (1981-1984) сеть ISDN была провозглашена главной заботой
комитета CCITT. К концу этого периода был опубликован набор рекомендаций,
названный серией I. Этот начальный набор был неполон и в некоторых случаях
внутренне противоречив. Тем не менее, к 1984 г. для производителей и поставщи-
ков услуг спецификация была достаточна, чтобы начать разработку оборудования,
имеющего отношение к ISDN, и чтобы продемонстрировать связанные с ISDN
службы и сетевые конфигурации.
К 1988 г. рекомендации серии I были достаточно детализированы, чтобы стала
возможной предварительная реализация ISDN. Сеть ISDN появилась и получила
широкое распространение только в первой половине 90-х гг.
Среди достижений ISDN следует особо отметить разработку спецификации
ретрансляции кадров. Ретрансляция кадров (frame relay) представляет собой
модернизированную форму коммутации пакетов, годящуюся для использования
в высокоскоростных (до 2 Мбит/с) сетях. Хотя изначально ретрансляция кадров
была стандартизирована в контексте ISDN, но вскоре она переросла этот контекст
и стала популярной в качестве основы общественных и частных сетей. Сегодня
ретрансляция кадров уверенно присутствует в самых разных контекстах, не име-
ющих отношения к ISDN.
Широкополосная сеть ISDN
В 1988 г. как часть серии I рекомендаций по ISDN комитет CCITT издал две реко-
мендации, относящиеся к широкополосной сети ISDN (Broadband ISDN, В-ISDN):
1.113, «Словарь терминов для широкополосных аспектов ISDN», и 1.121, «Широко-
полосные аспекты ISDN». Эти документы демонстрировали уровень достигнутого
участниками консенсуса по вопросам, касающимся природы будущей широкопо-
лосной сети ISDN на 1988 г. Они составили предварительное описание и основу
для последующей стандартизации и работы по совершенствованию системы. Неко-
торые важные идеи, высказанные в этих документах, перечислены ниже.
Широкополосная сеть — это служба или система, для которой требуются ка-
налы передачи, способные поддерживать скорость, превышающую исходную.
♦ Термин «В-ISDN» используется для удобства, чтобы подчеркнуть широко-
полосные аспекты ISDN. На самом деле имеется нотация единой сети ISDN,
предоставляющей широкополосные услуги, а также другие услуги ISDN.
♦ ATM представляет собой режим передачи для реализации сети В-ISDN и не
зависит от средств транспортировки физического уровня.
1.1. Краткая история сетей
33
4- В основе сети В-ISDN будут лежать понятия, разработанные для ISDN,
и сеть В-ISDN может развиваться путем прямого внедрения в сеть допол-
нительных функций широкополосной сети В-ISDN, обеспечивающих новые
и передовые услуги.
♦ Поскольку В-ISDN основывается на общих концепциях ISDN, базовая кон-
фигурация доступа ISDN также является базовой и для B-ISDN.
Далее перечислены факторы, определяющие направление работ сектора ITU-T
над сетью В-ISDN:
♦ Появление спроса на широкополосные услуги.
4- Наличие технологий высокоскоростной передачи данных, коммутации и об-
работки сигналов.
♦ Доступные пользователю усовершенствованные технологии обработки дан-
ных и изображений.
4 Прогресс в программной обработке, имеющий место в компьютерной про-
мышленности и индустрии телекоммуникаций.
4- Необходимость в интеграции интерактивных служб и служб распределения.
4- Необходимость в интеграции канального режима и режима переноса паке-
тов в универсальную широкополосную сеть.
♦ Необходимость в обеспечении гибкости в удовлетворении потребностей как
пользователей, так и операторов.
♦ Необходимость в освещении широкополосных аспектов ISDN в рекоменда-
циях ITU-T.
Обратите внимание на зависимость В-ISDN от ATM. Как и ретрансляция кад-
ров, ATM представляет собой модернизированную форму коммутации пакетов,
подходящую для высокоскоростных сетей. В сетях ATM используются пакеты
фиксированного размера, называемые ячейками (cells), в результате чего достигается
еще большая эффективность, чем при ретрансляции кадров. Технология ATM может
использоваться на скоростях более 100 Мбит/с и даже в гигабитном диапазоне.
Решение использовать ATM в качестве режима передачи для В-ISDN замеча-
тельно. В результате В-ISDN оказывается сетью, основанной на коммутации па-
кетов, причем как с точки зрения интерфейса пользователь—сеть, так и в терминах
внутреннего механизма коммутации. Хотя рекомендация 1.121 утверждает, что
В-ISDN будет поддерживать приложения, работающие в режиме коммутации ка-
налов, достигается это на базе транспортного механизма, в основе которого лежит
передача пакетов. Таким образом, сеть ISDN, начавшая свою эволюцию от те-
лефонной сети с коммутацией каналов, развилась в сеть с коммутацией пакетов,
в которой используются широкополосные службы.
С 1988 г. работа в секторе ITU-T направлялась перечисленными ранее концеп-
циями. Результатом этой работы явились публикации многочисленных рекомен-
даций в серии I, специально относящихся к B-ISDN.
Следует упомянуть ATM-форум (ATM-Forum), играющий центральную роль
в разработке стандартов ATM. В Международном союзе телекоммуникаций (ITU)
и составляющих его членах из заинтересованных стран процесс разработки стан-
34
Глава 1. Введение
дартов характеризуется широким участием представителей правительств, пользо-
вателей и промышленности, а также принятием решения по консенсусу. Этот про-
цесс может занимать очень много времени. Несмотря на то что сектор ITU-T ра-
ционализировал свою работу, задержки, связанные с разработкой стандартов в
области В-ISDN, в которой доминирует быстро развивающаяся технология ATM,
остаются особенно значительными. Благодаря большому интересу к технологии
ATM был создан ATM-форум с целью ускорения разработки стандартов ATM. На
ATM-форуме наблюдалось более активное участие со стороны производителей
компьютеров, чем это было в случае с ITU-T. Поскольку решения на форуме при-
нимаются на основании большинства голосов, а не консенсусом, он смог быстрее
определяться с деталями, необходимыми для реализации ATM. Этот успех, в свою
очередь, способствовал ускорению процесса стандартизации, которой занимался
сектор ITU-T.
ATM
Подобно тому как ретрансляция кадров развивалась в ходе работ по созданию
ISDN и теперь широко применяется в приложениях, не имеющих отношения к
ISDN, ATM представляет собой технологию, разрабатывавшуюся как часть про-
екта В-ISDN, а теперь широко применяющуюся в самых разных приложениях.
Для технологии ATM существует три основных сегмента рынка.
♦ Инфраструктура общественных сетей соответствует В-ISDN и состоит из
общественных телекоммуникационных сетей, предоставляющих услуги
телефонной связи, кабельного телевидения и глобальных компьютерных
сетей.
+ Локальная, сеть ATM. Технология ATM может использоваться для объеди-
нения локальных сетей несколькими способами. Один АТМ-коммутатор
или сеть из ATM-коммутаторов может служить магистралью для объедине-
ния традиционных локальных сетей (например, Ethernet). В качестве аль-
тернативы оконечные системы, такие как серверы и высокопроизводитель-
ные рабочие станции, могут напрямую соединяться с локальной сетью ATM.
4- Глобальная сеть ATM. Этот сегмент рынка включает сети предприятий, ра-
ботающие по выделенным линиям, инфраструктуры, находящиеся в част-
ном владении, такие как оптоволоконные кабели и беспроводные каналы
связи, а также линии, предоставляемые общественным сетевым оператором
как виртуальные частные сети.
Как видно из рис. 1.2, составленного по данным ATM-форума, рынок локаль-
ных сетей появился как коммерчески жизнеспособный сектор для оборудования,
основанного на ATM-технологии. Движущей силой на этом рынке была потреб-
ность в высокоскоростной недорогой поддержке локальных сетей, что будет обсуж-
даться в разделе 1.2. Такие сегменты рынка, как общественная инфраструктура
и глобальная сеть ATM, развивались медленнее, потому что испытывали конку-
ренцию со стороны технологии ретрансляции кадров и в связи с огромными рас-
ходами, необходимыми для перехода на новую систему с уже имеющейся конфи-
гурации. Оба эти сегмента становятся основными на рынке сетей.
1.2. Потребность в скорости и качестве обслуживания
35
• Широкая доступность услуг глобальных сетей ATM
• Развертывание технологии ATM в общественной инфраструктуре
• Начало испытаний инфраструктуры ATM
I I
• Выпуск оборудования для локальных сетей
I I
• Начаты работы по разработке спецификации B-1SDH
I_____Z-J___________________I
1985 1990 1995 2000
Рис. 1.2. Важнейшие этапы в развитии рынка ATM
1.2. Потребность в скорости и качестве
обслуживания
Важные изменения в том, как корпорации ведут свои дела и обрабатывают инфор-
мацию, были вызваны изменениями в сетевых технологиях, и в то же самое время
сами корпорации вызывали изменения в сетевых технологиях. В этой области
сложно определить, где курица, а где яйцо. Эта же взаимозависимость отражается
в использовании Интернета как предприятиями, так и индивидуальными пользо-
вателями. Доступность новых графических услуг в Интернете (то есть Паутина)
привела к увеличению общего числа пользователей и объема трафика, формируе-
мого каждым пользователем. Это, в свою очередь, вызвало необходимость в уве-
личении скорости и эффективности Интернета. С другой стороны, только эта уве-
личенная скорость и делает веб-приложения привлекательными для конечного
потребителя.
В этом разделе мы рассмотрим некоторые из факторов, формируемых конеч-
ным потребителем, участвующих в этом уравнении. Мы начнем с потребности в
высокоскоростных локальных сетях в деловой среде, так как эта потребность воз-
никла первой и задала темп развитию сетей. Затем мы обсудим требования бизне-
са к глобальным сетям. После этого мы скажем несколько слов о влиянии перемен
в коммерческой электронике на требования к сетям. Наконец, мы расскажем о тре-
бованиях к качеству обслуживания в Интернете.
Появление высокоскоростных локальных сетей
Широкое распространение персональных компьютеров и микрокомпьютерных
рабочих станций в бизнесе началось в начале 80-х годов. В настоящее время это
оборудование представляет собой столь же неотъемлемую принадлежность любо-
го офиса, как, например, телефон. До относительно недавних пор офисные локаль-
ные сети предоставляли в основном услуги соединения — они соединяли персо-
нальные компьютеры и терминалы с мэйнфреймами и системами промежуточного
звена, на которых работали корпоративные приложения, а также обеспечивали
36
Глава 1. Введение
соединение для рабочих групп па уровне отделов или цехов. В обоих случаях объ-
емы передаваемых по сетям данных были невелики. Трафик в основном состоял
из файлов и электронной почты. Локальные сети, предназначенные для обслужи-
вания подобного трафика, а это в первую очередь Ethernet и Token Ring, отлично
подходят для такого окружения.
В 90-е годы роль персонального компьютера (а вместе с ней и требования к ло-
кальной сети) изменилась благодаря двум важным тенденциям:
+ Вычислительная мощь персональных компьютеров продолжает радовать
экспоненциальным ростом. Все более мощные платформы поддерживают
приложения, интенсивно использующие графику, и все усложняющиеся
графические интерфейсы пользователя с операционными системами.
♦ Организации, занимающиеся административными информационными систе-
мами, увидели в локальных сетях жизнеспособные и важные вычислитель-
ные платформы. Начало этой тенденции положили системы «клиент-сер-
вер», ставшие доминирующей архитектурой в деловой среде, а также более
недавнее веяние — технология интранет.
Результатом этих тенденций стала необходимость обеспечения роста переда-
ваемого по локальным сетям объема данных и, так как приложения стали более
интерактивными, уменьшения времени задержки при передаче данных. Первые
поколения сетей Ethernet, работавшие со скоростью 10 Мбит/с, и сетей Token ring
со скоростью 16 Мбит/с просто не могли соответствовать новым требованиям.
Ниже перечислены примеры, для которых могут потребоваться высокоскорост-
ные сети:
♦ Централизованные серверные фермы. Во многих приложениях необходимо
поддерживать возможность загрузки больших объемов данных пользовате-
лем или клиентом с многочисленных централизованных серверов, называе-
мых серверными фермами (server farms). В качестве примера можно назвать
издательскую работу с цветными изображениями, когда серверы содержат
десятки гигабайтов изображений, загружаемых на рабочие станции. С тех
пор как производительность серверов увеличилась, узким местом стала сеть.
Эта проблема не может быть решена при помощи коммутируемой сети
Ethernet, так как пропускная способность каждой линии связи с клиентом
ограничена значением 10 Мбит/с.
♦ Мощные рабочие группы. Эти группы, как правило, состоят из небольшого
числа сотрудничающих пользователей, которым необходимо перемещать по
сети массивные файлы данных. Например, это может быть группа разработчи-
ков программного обеспечения, тестирующих новую версию программы, или
компания, занимающаяся автоматизированным проектированием (Computer-
Aided Design, CAD) и регулярно запускающая свои новые модели. В таких
случаях большие объемы данных распределены по нескольким рабочим
станциям. Они обрабатываются и обновляются на очень высоких скоростях,
так как процесс формирования модели требует множества итераций.
♦ Высокоскоростная локальная магистраль. По мере роста потребности в об-
работке данных локальных сетей становится все больше, что требует высо-
коскоростного взаимодействия.
1.2. Потребность в скорости и качестве обслуживания
37
Корпоративные потребности в глобальных сетях
В начале 90-х годов во многих организациях была популярной модель централизо-
ванной обработки данных. В типичном окружении вычислительные мощности мо-
гут быть сконцентрированы в нескольких региональных офисах, например в виде
мэйнфреймов или хорошо оснащенных систем промежуточного звена. Эти центра-
лизованные вычислительные мощности могут поддерживать большую часть корпо-
ративных приложений, включая приложения для финансового и бухгалтерского
учета, персональные программы, а также разнообразные приложения, специфич-
ные для данного бизнеса. Меньшие удаленные офисы в транзакционном окруже-
нии (например, филиалы банка) могут быть оснащены терминалами или обычны-
ми персональными компьютерами, связанными с одним из региональных центров.
Эта модель начала меняться в начале 90-х годов, а в середине 90-х изменения
ускорились. Многие организации стали распределять своих сотрудников по мно-
жеству небольших офисов. Продолжился рост распределенных вычислений. Из-
менилась сама природа приложений. Сначала технология клиент-сервер, а позднее
интранет полностью изменили структуру среды обработки данных. Теперь гораз-
до чаще используются распределенные системы, в которых вычисления выполня-
ются персональными компьютерами, рабочими станциями и серверами, и все мень-
ше встречаются централизованные системы, например мэйнфреймы и системы
промежуточного звена. Более того, практически универсальное развертывание гра-
фических интерфейсов пользователя на рабочих столах позволяет конечному
пользователю применять графические приложения, мультимедиа и другие прило-
жения, интенсивно использующие данные. Кроме того, большинству организаций
требуется доступ к Интернету. Когда несколько щелчков мышью способны при-
вести в движение огромные массивы данных, модели трафика стали более непред-
сказуемыми, а средняя нагрузка на линии связи увеличилась.
Все эти тенденции означают, что все больше данных требуется передавать из
замкнутых структур в глобальные сети. Довольно долго считалось, что в типич-
ной деловой среде около 80 % трафика остается локальным, а 20 % проходит по
глобальным линиям связи. Но это правило более не применимо к большинству
компаний, и все больший процент трафика составляет передача данных по глобаль-
ным сетям [55]. Это смещение в модели трафика ложится все большим бременем
на магистрали локальных сетей и, конечно, на глобальные мощности, используе-
мые корпорацией. Таким образом, как и на локальном уровне, перемены в модели
корпоративного трафика являются стимулом для создания высокоскоростных гло-
бальных сетей.
Цифровая электроника
Быстрый переход бытовой электроники на цифровые технологии оказывает вли-
яние как на Интернет, так и на корпоративные интранет-сети. С распространени-
ем этих технических новинок объем фото- и видеотрафика, переносимого сетями,
вырастет во много раз.
В качестве примеров этой тенденции можно назвать цифровые видеодиски и
Цифровые фотокамеры.
38
Глава 1. Введение
Цифровые видеодиски
С появлением лазерных дисков высокой емкости, то есть DVD (Digital Video
Disk — цифровой видеодиск), электронная промышленность наконец нашла при-
емлемую замену аналоговой видеокассете формата VHS. Диски DVD заменят ви-
деоленту, применяемую в кассетных видеомагнитофонах, и, что более важно в кон-
тексте данного обсуждения, заменят компакт-диски в персональных компьютерах
и серверах. DVD выведет видео в эпоху цифровых технологий. Технология DVD
позволяет распространять фильмы с качеством изображения, превосходящим
качество лазерных дисков, кроме того, диски DVD, как и компакт-диски, обеспе-
чивают произвольный доступ к данным, причем дисководы для DVD способны
воспроизводить также и обычные компакт-диски. С применением DVD с их ги-
гантской емкостью и высоким качеством игры для персональных компьютеров
станут более реалистичными, а обучающее программное обеспечение будет содер-
жать больше видеоматериала. Развитие этих технологий приведет к еще больше-
му росту трафика в Интернете и корпоративных сетях, так как все больше видео-
материала будет размещаться на веб-страницах.
Следует также упомянуть прогресс в области цифровых видеокамер. Относи-
тельно мало известный в США (на момент написания этой книги), этот продукт
уже достаточно серьезно заявил о себе в Японии. Цифровые видеокамеры упрос-
тят создание отдельными пользователями и компаниями цифровых видеофайлов,
которые могут быть размещены на веб-сайтах Интернета или корпоративных
сетей, что опять же увеличит нагрузку на сети.
Цифровые фотокамеры
Хотя цифровые фотокамеры используются уже около 15 лет, заметный эффект они
начинают оказывать только теперь, так как цены на них снизились до разумных
значений. Качество цифровых фотокамер еще не достигло уровня традиционных
пленочных аппаратов, но удобство их применения в сетях ни с чем не сравнимо.
Индивидуальный пользователь может сделать фотографию любимого человека
или домашнего животного и мгновенно поместить ее на веб-страницу. Компании
могут быстро создать каталоги продуктов для Интернет-магазинов с цветными
фотографиями каждого товара. Таким образом, в ближайшие годы можно ожидать
значительного роста фото- и видеотрафика в Интернете.
Качество обслуживания в Интернете
Интернет и IP-протокол были разработаны, чтобы предложить службу доставки
с максимальными усилиями (best effort). В схеме с максимальными усилиями Ин-
тернет (или частная сеть) обращается со всеми пакетами одинаково. С увеличени-
ем трафика в сети возникают перегрузки. При этом доставка всех пакетов замед-
ляется. Если перегрузка значительна, для борьбы с ней маршрутизаторы начинают
отбрасывать пакеты, выбирая их более или менее случайным образом. При этом
нс производится никакого различия между пакетами ни по относительной важно-
сти, ни по временным требованиям.
С радикальным ростом трафика и появлением новых приложений реального
времени, мультимедийных приложений и приложений, использующих групповую
1.2. Потребность в скорости и качестве обслуживания
39
рассылку, традиционные протоколы и службы Интернета стали неадекватными.
Но и потребности пользователей изменились. Компания может потратить милли-
оны долларов на установку объединенной IP-сети, предназначенной для транс-
портировки данных между локальными сетями, и обнаружить, что новые при-
ложения, такие как приложения мультимедиа, приложения реального времени и
приложения групповой рассылки, поддерживаются данной конфигурацией дале-
ко не оптимальным образом. Единственной сетевой схемой, с первого дня спро-
ектированной для поддержания как традиционных TCP- и UDP-трафиков, так
и трафика реального времени, является ATM. Однако переход на ATM означает
либо создание второй сетевой инфраструктуры для трафика реального времени,
либо замену имеющейся IP-конфигурации на ATM, что в обоих случаях требует
существенных капитальных затрат.
Трафик в обычной или объединенной сети можно разделить на две большие
категории: эластичный и неэластичный. Если рассмотреть их, то станет ясна необ-
ходимость в улучшенной архитектуре объединенных сетей.
Эластичный трафик может приспосабливаться в широких пределах к задерж-
кам и изменениям в пропускной способности объединенной сети и, тем не менее,
удовлетворять потребностям приложений. Таков традиционный тип трафика, под-
держиваемый объединенными сетями, основанными на наборе протоколов ТСР/
IP. Именно для такого типа трафика и проектировались объединенные сети. В слу-
чае протокола TCP трафик индивидуального соединения приспосабливается к
перегрузке в сети путем снижения скорости передачи данных.
К эластичным приложениям относятся обычные Интернет-прпложения, такие
как приложения передачи файлов, электронной почты, удаленной регистрации,
управления сетью и доступа к Паутине. Но в требованиях к работе сети у этих при-
ложений имеются различия:
♦ Электронная почта совершенно нечувствительна к задержкам.
♦ При передаче файлов в режиме подключения (on-line), как это часто быва-
ет, пользователь ожидает, что задержка будет пропорциональна размеру фай-
ла; таким образом, такие приложения чувствительны к изменениям в про-
пускной способности.
♦ При управлении сетью задержка обычно не является серьезной проблемой.
Однако если причиной сетевых перегрузок являются неисправности в объ-
единенной сети, тогда необходимость прохождения управляющих сообще-
ний возрастает с ростом нагрузки.
♦ К задержке весьма чувствительны интерактивные приложения, такие как
приложения удаленной регистрации и доступа к Паутине.
Таким образом, даже если мы остановимся на эластичном трафике, наличие
межсетевой службы, основанной на качестве обслуживания, будет очень полезным.
Без такой службы маршрутизаторы одинаково относятся ко всем прибывающим
IP-пакетам, не учитывая ни тип приложения, ни размер файла, частью которого
является пакет. При таких условиях в случае возникновения перегрузки малове-
роятно, что ресурсы будут распределены так, чтобы справедливо удовлетворить
требования всех приложений. Если к этой путанице добавится еще и неэластич-
ный трафик, ситуация станет еще хуже.
40
Глава 1. Введение
Неэластичный трафик плохо адаптируется (если вообще адаптируется) к за-
держкам и изменениям в пропускной способности объединенной сети. Основным
примером здесь является трафик реального времени, например передача по сети
голоса или видеосигнала. Некоторые требования к неэластичному трафику пере-
числены ниже:
+ Пропускная способность может быть минимальной. В отличие от большин-
ства видов эластичного трафика, способных продолжать доставку данных,
возможно, с пониженным качеством обслуживания, для многих неэластич-
ных приложений требуется твердая минимальная пропускная способность.
♦ Наличие задержки. Пример чувствительного к задержке приложения пред-
ставляет собой игра на бирже. Тот, кто постоянно получает информацию с
опозданием, будет постоянно опаздывать со своими действиями и в резуль-
тате действовать менее успешно.
4- Изменение задержки. Чем больше задержка, тем больше реальная пауза в
доставке данных и тем больше должен быть накопительный буфер на при-
емной стороне. Интерактивные приложения реального времени, такие как
приложения телеконференций, могут иметь ограничения на максимальное
время задержки.
4- Потеря пакетов. Приложения реального времени различаются по количе-
ству потерянных пакетов, без которых они смогут продолжать функциони-
ровать без значительного снижения качества.
Все эти требования сложно удовлетворить в среде с переменными задержками
в очередях и потерей данных при перегрузке. Соответственно, неэластичный тра-
фик выдвигает два новых требования к архитектуре объединенных сетей. Во-пер-
вых, необходимы средства, отдающие преимущество приложениям с более высо-
кими требованиями. Приложения должны иметь возможность заявить о своих
требованиях либо заблаговременно, при помощи некой служебной функции, либо
«на лету», с помощью полей в заголовке IP-пакета. Предпочтительным является
первый подход. Он обеспечивает большую гибкость в выдвижении требований
и позволяет сети заранее учитывать требования и отказывать в предоставлении
обслуживания, если требуемые ресурсы недоступны. Для этого подхода необхо-
дим специальный протокол резервирования ресурсов.
Второе требование в области поддержки неэластичного трафика в архитектуре
объединенных сетей заключается в том, что эластичный трафик по-прежнему дол-
жен поддерживаться. В отличие от TCP-приложений, неэластичные приложения,
как правило, при перегрузке не отключатся и не снижают требований. Поэтому
при возникновении перегрузки неэластичный трафик будет продолжать оказывать
высокую нагрузку на сеть, тогда как эластичный трафик окажется полностью вы-
тесненным из объединенной сети. В управлении такой ситуацией может помочь
протокол резервирования, отказывающий запросам, обслуживание которых может
привести к тому, что в сети останется слишком мало ресурсов, чтобы обслуживать
текущий эластичный трафик.
Другой взгляд на требования к организации трафика иллюстрирует рис. 1.3.
Приложения можно разбить на две большие категории. Требование чувствитель-
1.3. Усовершенствованные сети TCP/IP и ATM
41
ности к времени задержки может быть удовлетворено при помощи класса служб,
уделяющих особое внимание своевременной доставке и/или обеспечивающих
высокую скорость передачи данных. Требование критичности может быть удов-
летворено с помощью класса служб, ставящих во главу угла надежность.
Чувствительность
Архивирование'
сервера
Нечувствительность
Низкая важность--------------------------------
Критичность задачи
► Высокая важность
Рис. 1.3. Сравнение приложений по чувствительности к задержкам
и по важности для предприятия
1.3. Усовершенствованные
сети TCP/IP и ATM
В прессе часто можно встретить упоминания о «битве между IP и АТМ». Одни
авторы заявляют, что окончательным победителем будет 1Р, другие утверждают,
что победит ATM. Сторонники IP говорят, что ATM представляет собой слиш-
ком дорогую, слишком сложную и в определенной степени устаревшую техноло-
гию. Вместо нее корпорации будут использовать коммутаторы локальных сетей
42
Глава 1. Введение
Ethernet, обеспечивающие высокую скорость передачи данных для рабочих групп
и серверов, и полагаться на объединенные сети, основанные на усовершенствован-
ном протоколе IP, обеспечивающем приоритетное обслуживание чувствительного
к временным параметрам трафика и предоставляющем достаточно мощностей всем.
Сторонники ATM заявляют, что установка ATM стоит затраченных времени
и средств и будет представлять собой сетевой эквивалент нирваны. Технология
ATM предлагает эффективную высокоскоростную службу, которая может быть
масштабирована практически до любой скорости передачи данных, обеспечиваю-
щую «бесшовное» соединение между компьютерами через локальные и глобаль-
ные сети ATM.
Эта книга написана в предположении, что как у ATM, так и у IP впереди еще
много лет жизни. Маловероятно, что организации, управляющие сетями, откажут-
ся от огромных вложений в IP-оборудование и программное обеспечение. С дру-
гой стороны, технология ATM обладает огромной движущей силой.
В оставшейся части этой главы мы предоставим краткий обзор некоторых важ-
ных тем, связанных с этими двумя сетевыми технологиями.
Объединенные IP-сети
Доминирующей парадигмой компьютерных сетей является их взаимодействие,
в которое вовлекается как гигантский Интернет, так и бесчисленные корпора-
тивные сети. В процессе взаимодействия важную роль играют четыре ключевых
технологии.
♦ TCP и IP. Исходный протокол взаимодействия сетей, разрабатывавшийся
в ходе исследовательских работ по ARPANET, совместил в себе логику
определения маршрута через объединенную сеть со сквозным контролем.
Переломный момент наступил с разделением его на два протокола. Прото-
кол IP служит для определения маршрутов в объединенных сетях и доставки
пакетов, а протокол TCP — для надежного сквозного транспорта. Для при-
ложений, которым не нужна надежная доставка, поверх протокола IP может
применяться более эффективный протокол UDP (User Datagram Protocol —
пользовательский протокол дейтаграмм). Теперь для трафика реального
времени поверх протокола IP может использоваться новый протокол RTP
(Real-time Transport Protocol — транспортный протокол реального време-
ни). Гибкость и универсальность модели TCP/IP стала главным фактором
в ее доминировании.
♦ Динамическая маршрутизация выполняет две жизненно важные функции.
Она делает возможной динамическое обнаружение маршрутов, так что не
требуется предварительная настройка конечных систем и маршрутизаторов
между ними при каждом изменении топологии. Динамическая маршрути-
зация также позволяет изменять маршруты при возникновении перегрузок
или неисправностей на линии, в результате чего может быть достигнута
эффективная балансировка нагрузки. За последние 20 лет основные прин-
ципы практически не изменились, хотя технология маршрутизации разви-
1.3. Усовершенствованные сети TCP/IP и ATM
43
валась (например, для ускорения поиска маршрутов в таблицах маршрути-
зации применяется более совершенная аппаратура, а для обработки огром-
ных таблиц применяются более сложные алгоритмы). Динамическая мар-
шрутизация позволяет создавать большие развивающиеся объединенные
сети, а также предоставляет пользователям высокую степень гибкости.
♦ Коммутация пакетов. Исследования в области TCP/IP и объединенных се-
тей восходят к исследованиям коммутации пакетов, финансировавшимся
управлением ARPA. Многие из концепций, используемых в объединенных
сетях и основанных на протоколе IP, включая сквозные протоколы и дина-
мическую маршрутизацию, сначала были разработаны для сетей с коммута-
цией пакетов. Для глобальных сетей передачи данных коммутация пакетов
остается доминирующей технологией.
+ Ethernet. Подобно тому как коммутация пакетов доминирует в сфере гло-
бальных сетей передачи данных, Ethernet доминирует в области локальных
сетей. Оригинальная экспериментальная сеть Ethernet работала на коак-
сиальном кабеле со скоростью 3 Мбит/с. Эта замечательная схема теперь
применяется на витой паре и оптическом кабеле, а также на коаксиальном
кабеле. Первый коммерческий выпуск работал уже со скоростью 10 Мбит/с,
а позднее скорость этой локальной сети была увеличена до 100 Мбит/с,
1 Гбит/с и 10 Гбит/с. Локальные сети Ethernet входят в состав большинства
конфигураций объединенных сетей.
Скажем в заключение еще несколько слов о приведенном выше списке. Тех-
нология Ethernet в большой степени ответственна за успех набора протоколов
TCP/IP. В конце 70-х — начале 80-х применение набора протоколов TCP/IP было
ограничено главным образом министерством обороны США, а также организация-
ми, заключившими с ним контракт и связанными с ним исследовательскими инсти-
тутами. Остальной мир приветствовал разработку модели протоколов OSI (Open
Systems Interconnection — взаимодействие открытых систем) и набора протоколов,
определенных в качестве международного стандарта в рамках данной модели. Но
в течение этого периода набора протоколов TCP/IP вырвался из военной среды
и быстро завоевал коммерческий рынок. Этому способствовало то, что TCP/IP
был уже сформировавшимся работоспособным набором протоколов, обеспечива-
ющим возможность взаимодействия сетей и высокий уровень функциональности,
тогда как протоколы OSI все еше находились в стадии развития и по большей час-
ти не проверялись в «полевых» условиях. Толчком к успеху протоколов TCP/IP
послужила сеть Ethernet: многие производители оборудования для локальных
сетей стали включать TCP/IP в свои продукты, которые поставлялись не только
военным США, но и широкому кругу покупателей. Успех Ethernet помог обеспе-
чить успех набора протоколов TCP/IP.
Но времена меняются, и появляются новые требования. Интернет и корпора-
тивные объединенные сети теперь столкнулись с необходимостью поддерживать
мультимедиа и трафик реального времени. В ответ на эти потребности на го-
ризонте появляются две радикальные перемены в архитектуре объединенных
сетей: архитектура интегрированных служб (Integrated Services Architecture, ISA)
44 Глава 1. Введение
и дифференцированные службы (Differentiated Services, DS). Обе технологии
подразумевают применение более совершенной аппаратуры маршрутизаторов для
обслуживания трафика, чувствительного к временным параметрам, а также для
предоставления более высокого качества обслуживания и поддержания ряда но-
вых протоколов:
♦ IPv6. Новая версия протокола IP была разработана в связи с необходимос-
тью расширения адресного пространства Интернета, но она также обладает
свойствами, полезными для ISA и DS.
♦ RSVP. Протокол RSVP (Resource reSerVation Protocol — протокол резерви-
рования ресурсов) позволяет пользователям резервировать мощности объ-
единенной сети и указывать требования трафика в терминах желаемых ха-
рактеристик пропускной способности и задержки.
+ RTP. Протокол RTP (Real-time Transport Protocol — транспортный про-
токол реального времени) предоставляет механизмы доставки по объеди-
ненным сетям трафика реального времени, например видео, аудио и т. д., та-
ким образом, чтобы он мог быть эффективно воспроизведен получающей
стороной.
♦ Маршрутизирующие протоколы групповой рассылки. Во многих случаях
мультимедийный трафик или другой трафик реального времени передает-
ся одновременно нескольким получателям, то есть применяется групповая
рассылка. Для поддержания маршрутизации при групповой рассылке было
разработано несколько протоколов динамической маршрутизации.
С помощью этих новых протоколов основанная на службах ISA и DS объеди-
ненная сеть способна эффективно поддерживать как традиционный «пульсирую-
щий» трафик, так и мультимедийный трафик и трафик реального времени. Суть
различий между этими двумя подходами заключается в следующем: при исполь-
зовании службы ISA приложение запрашивает у объединенной сети определен-
ный уровень качества обслуживания. Если маршрутизаторы объединенной сети
совместно приходят к выводу, что для удовлетворения данного запроса в объеди-
ненной сети достаточно ресурсов, тогда объединенная сеть резервирует эти ресур-
сы и позволяет приложению их использовать. Когда применяется служба DS, при-
ложение указывает свои требования к качеству обслуживания, помечая каждый
пакет соответствующим кодом. Основываясь на этих кодах, сеть предоставляет
различным пакетам разные уровни обслуживания. Заблаговременного резервиро-
вания ресурсов при использовании службы DS нет.
Сети ATM
Коммерческого признания сети ATM, по-видимому, будут добиваться еще долго,
но за технологию теперь уже можно не опасаться. Далее перечислены некоторые
ключевые технические ингредиенты, необходимые для успешной работы сети ATM:
♦ Внутренняя сигнализация. Система SS7 (Signaling System 7), разработанная
союзом CCITT в ходе работ по проектированию IDN и ISDN, предоставля-
ет набор протоколов, с помощью которого можно эффективно управлять
1 .^Усовершенствованные сети TCP/IP и ATM
45
сетью ATM. Система SS7 включает механизмы определения, установки
и разрыва логических соединений для управления сетевыми ресурсами.
♦ Внешняя сигнализация. Интерфейс UNI (User-to-Network Interface — интер-
фейс пользователь—сеть) для сетей ATM включает в себя механизмы для
установки и разрыва соединений. Протокол позволяет пользователю опре-
делять ожидаемые характеристики трафика и запрашивать у сетевых служб
определенный уровень качества обслуживания.
♦ Спецификация физического уровня. Сеть ATM разработана для работы на
скоростях от 100 Мбит/с и выше. Для поддержания таких скоростей пере-
дачи данных необходим мощный физический уровень. Самая известная спе-
цификация физического уровня, поддерживающего такие высокие скоро-
сти, — это спецификация сектора ITU-T, известная в Европе под названием
стандарт SDH (Synchronous Digital Hierarchy — синхронная цифровая
иерархия). Его эквивалент в США называется сетью SONET (Synchronous
Optical NETwork — синхронная оптическая сеть). Разработано отображение
уровня передачи данных ATM на уровень SDH/SONET.
♦ Адаптация ATM. ATM представляет собой универсальную службу передачи
данных, способную поддерживать широкий спектр услуг по передаче дан-
ных и протоколов верхнего уровня. Ключом к этой поддержке является уро-
вень AAL (ATM Adaptation Level — уровень адаптации ATM), отображаю-
щий различные протоколы и службы верхнего уровня на уровень ATM.
Выдающейся вехой в истории развития технологии ATM был выход версии 3.1
спецификации UNI, выпущенной ATM-форумом в 1994 г. [ 17]. В разработке этой
спецификации участвовали сотни компаний. В ней предоставлено достаточно де-
талей, чтобы использовать эту спецификацию в качестве основы для реализации.
Помимо определения сигналов интерфейса UNI и логических соединений ATM
эта спецификация предоставляет достаточно детальное определение методов опи-
сания трафика и управления трафиком, включая алгоритм «дырявого ведра».
Так же как Интернет, сети ATM столкнулись с новыми требованиями. Техно-
логия ATM успешно удовлетворяла потребности трафика реального времени и
мультимедийного трафика, но до недавних пор почти не обеспечивала эффектив-
ной поддержки трафика, характерного для Интернета, — пульсирующего трафика,
использующего протоколы TCP и UDP. Чтобы удовлетворить эти потребности,
ATM-форум в 1996 г. выпустил версию 4.0 своей спецификации управления тра-
фиком. Эта спецификация определяет две новых службы с названиями ABR
(Available Bit Rate — доступная битовая скорость) и UBR (Unspecified Bit Rate —
неуказанная битовая скорость) вместе с протоколами, позволяющими определять
трафик для этих служб и управлять им. Службы ABR и UBR предназначались для
удовлетворения требований IP-трафика по производительности. В 1999 г. эта
спецификация была обновлена [18], при этом в нее была включена служба GFR
(Guaranteed Frame Rate — гарантированная скорость кадров), обеспечивающая
более эффективную службу для IP-трафика. Таким образом, в настоящее время
сеть ATM способна предоставлять пользователям полный набор услуг, охватывая
широкий спектр типов трафика.
46
Глава 1. Введение
1.4. Обзор книги
В этом разделе содержится краткое описание остальных глав книги.
Фундаментальные понятия протоколов и сетей
Назначение части I заключается в предоставлении базовых знаний и контекста для
остальных частей книги. Здесь представлены основные понятия из области про-
токолов, обеспечивающих взаимодействие компьютеров.
Глава 2 посвящена сетевым протоколам, в частности набору протоколов TCP/IP.
В этой главе также рассматривается работа TCP/IP в окружении объединенных
сетей. В главе 3 обсуждаются дополнительные детали протоколов TCP и IP.
Читатель с хорошей подготовкой в области компьютерных сетей почти всего
часть I может пропустить.
Высокоскоростные сети
Часть II представляет собой обзор высокоскоростных сетей. В главе 4 рассматри-
вается широко применяемая технология ретрансляции кадров. В главе 5 содержит-
ся учебный материал по теме сетей ATM. В этой главе обсуждается ключевой ме-
ханизм уровня ATM и службы, предоставляемые уровнем ATM. Рассматриваются
также вопросы использования уровня AAL для реализации этих служб.
Хотя в центре внимания данной книги остаются объединенные сети, основан-
ные на протоколах TCP/IP, и сети ATM, знакомство с высокоскоростными локаль-
ными сетями также будет полезным. Оно предоставляется в главе 6, посвященной
наиболее важным типам высокоскоростных локальных сетей, то есть сетям Ethernet.
Эта глава также знакомит читателя с волоконно-оптическими каналами и высо-
коскоростными беспроводными сетями.
Моделирование и оценка производительности
Моделирование и оценка производительности представляет собой тему, важную
по двум причинам. Во-первых, имея характеристики ожидаемой нагрузки на сеть,
исследователь может определить требуемые скорости передачи данных и размеры
буферов. Во-вторых, резервируя сетевые ресурсы, пользователи могут задать
характеристики ожидаемого трафика данных. Часть III начинается главой 7 с обзо-
ра основных понятий вероятностного и стохастического процессов, используемых
в остальных главах этой части книги. В главе 8 предоставлен учебный материал
по теме анализа очередей — наиболее широко применяемого метода моделирова-
ния и оценки. В формулах анализа очередей, используемых при моделировании
производительности, как правило, предполагается, что трафик описывается рас-
пределением Пуассона. Однако было показано, что в высокоскоростных сетях
большая часть трафика является по своей природе самоподобной, или фракталь-
ной. Результаты этого изучаются в главе 9.
Часть III самая сложная в математическом отношении, и читатель с недостат-
ком либо времени, либо интереса может смело пропустить главу 7 и «по диагона-
ли» просмотреть главы 8 и 9, чтобы получить представление о сделанных выводах.
1.4. Обзор книги
47
Перегрузка и управление трафиком
Для достижения большей производительности в высокоскоростных сетях оконеч-
ные системы должны регулировать свои потоки данных, чтобы эффективно ис-
пользовать сетевые ресурсы, не оказывая чрезмерного давления на систему, в ре-
зультате которого может произойти ее перегрузка и даже полный крах. Этой теме
посвящена часть IV. Для начала глава 10 предоставляет обзор проблемы перегруз-
ки и методов борьбы с ней. В главе 11 обсуждаются ключевые параметры задерж-
ки распространения, скорости передачи данных и пропускной способности на про-
стом примере протоколов борьбы с перегрузкой уровня передачи данных. В этом
контексте отчетливо видны взаимосвязи между параметрами. Глава 12 посвящена
протоколу TCP. В ней изучаются алгоритмы борьбы с перегрузками, реализо-
ванные как часть TCP, а также производительность протокола TCP в сети ATM.
В главе 13 рассматриваются вопросы борьбы с перегрузками и управления трафи-
ком в сетях ATM.
Маршрутизация в объединенных сетях
Часть V посвящена ключевой роли, которую играют протоколы маршрутизации
в работе объединенных сетей. Исторически маршрутизация применялась, во-пер-
вых, как метод минимизации ожидаемого времени задержки путем нахождения со-
ответствующего пути и, во-вторых, для балансировки нагрузки в объединенной
сети, благодаря чему минимизировалось суммарное время задержки, а также сни-
жалась вероятность перегрузки. Позднее маршрутизация стала применяться для
удовлетворения запросов по качеству обслуживания.
В главе 14 дан обзор теории графов и методов нахождения наименее затратно-
го по стоимости пути. В главах 15 и 16 рассматривается ряд протоколов маршру-
тизации, предназначенных для поддержания целевой рассылки для трафика «точ-
ка-точка», а в заключение обсуждается маршрутизация при групповой рассылке.
Качество обслуживания в IP-сетях
Сами по себе протокол TCP и другие сквозные протоколы могут только исполь-
зовать обычную или объединенную сеть как «черный ящик» и пытаться угадать
наличие в ней перегрузки. В части VI рассматриваются протоколы и механиз-
мы, используемые внутри объединенной сети, чтобы бороться с перегрузками
и поддерживать различные уровни качества обслуживания. В главе 17 читатель
знакомится с важными понятиями интегрированных и дифференцированных
служб. В главе 18 обсуждаются различные протоколы поддержания качества
обслуживания.
Сжатие
Спрос на высокоскоростные сети растет так же быстро, как предложение. В час-
ти VII изучается техника сжатия, дополняющая обсуждавшиеся ранее методы
борьбы с перегрузкой и управления трафиком. Сжатие может помочь уменьшить
48
Глава 1. Введение
объем трафика, необходимый для обслуживания данного приложения. В главе 19
дается краткий обзор соответствующих концепций теории информации примени-
тельно к сжатию данных.
Алгоритмы сжатия можно разделить на две большие группы: методы сжатия
без потерь, годящиеся для передачи и хранения файлов и сообщений, и методы
сжатия с потерями, применяемые для передачи видео- и аудиоданных. Эти методы
описываются в главах 20 и 21 соответственно.
1.5. Ресурсы Интернета
В Интернете доступны ресурсы, дополняющие материал данной книги и полезные
тем, кто работает в данной области.
Веб-сайты для этой книги
Для этой книги есть специальная веб-страница по адресу WilliamStallings.com/
HsNet2e.html, на которой можно найти много интересного:
4- Полезные веб-сайты. По указанному адресу есть ссылки на другие веб-сай-
ты по той же теме, организованные по главам, включая сайты, перечислен-
ные в этом разделе и упоминаемые в остальных разделах книги.
4- Список опечаток из этой книги будет поддерживаться и обновляться по мере
надобности. Пожалуйста, отправляйте мне информацию обо всех обнару-
женных вами ошибках по электронной почте. Списки опечаток других моих
книг можно найти на сайте Wilb’amStalh’ngs.com.
4- Рисунки. Все рисунки к книге хранятся в формате PDF (Adobe Acrobat).
•4 Таблицы. Все таблицы к книге хранятся в формате PDF.
4- Слайды. Набор слайдов, организованных по главам, хранится в формате пре-
зентаций (PowerPoint).
4- Список Интернет-рассылки. На сайте имеется информация о подписке на
список рассылки, связанный с тематикой книги.
4- Курсы по высокоскоростным сетям. На сайте есть ссылки на главные стра-
ницы веб-сайтов, посвященных курсам, основанным на материале данной
книги. Эти веб-страницы могут оказаться полезными для преподавателей
при составлении собственных курсов.
Я также поддерживаю сайт ресурсов для студентов, специализирующихся
в области кибернетики. Этот сайт расположен по адресу WilliamStalb’ngs.com/
StudentSupport.html и предназначен для предоставления документов, информации
и ссылок для студентов, изучающих кибернетику, и профессионалов. Ссылки орга-
низованы по четырем категориям:
4- Математика. Эти сайты содержат материалы, позволяющие освежить зна-
ния основ математики, учебник по теории анализа очередей, учебник по си-
стемам счисления и ссылки на многочисленные математические сайты.
1.5. Ресурсы Интернета
49
+ Ноу-хау. Советы и руководства по решению домашних заданий, написанию
технических отчетов и подготовке технических презентаций.
+ Исследовательские ресурсы. Ссылки на важные собрания стат ей, техниче-
ских отчетов и библиографии.
+ Разное. Разнообразные полезные документы и ссылки.
Другие веб-сайты
В Интернете есть множество веб-сайтов, содержащих информацию, относящуюся
к теме данной книги. В последующих главах указатели на соответствующие веб-
сайты можно найти в разделах рекомендуемой литературы и веб-сайтов. Посколь-
ку адреса веб-сайтов имеют тенденцию часто меняться, я не включил их в книгу.
Эти адреса можно найти на веб-сайте книги. Другие ссылки, не упомянутые в э той
книге, будут добавляться на веб-сайт постепенно.
Ниже перечислены веб-сайты, которые содержат материалы по теме высоко-
скоростных сетей, представляющие общий интерес:
4- Network World. Хорошая отправная точка для поиска информации и ссылок
на сайты, посвященные обмену данными и сетям.
+ IETF Directory and Database. Архивы, относящиеся к Интернету и деятель-
ности IETF (Internet Engineering Task Force — проблемная группа инженер-
ной поддержки Интернета). Включает индексированную по ключу библио-
теку документов RFC и проектов, а также множество других документов,
касающихся Интернета и его протоколов.
+ Vendors. Ссылки на сайты тысяч производителей аппаратного и программ-
ного обеспечения, а также список номеров телефонов тысяч компьютерных
и сетевых компаний.
4- IEEE Coimnunications Society. Хороший источник информации, позволяющий
быть в курсе конференций, публикаций и т. д.
4- ACM Special Interest Group on Communications. Еще один хороший источник
информации, позволяющий быть в курсе конференций, публикаций и т. д.
Группы новостей USENET
Большое число групп новостей USENET посвящено тому или иному аспекту пере-
дачи данных и сетям. Как и практически в любой группе новостей USENET, в пере-
численных группах велико отношение шума к сигналу, но, тем не менее, имеет
смысл попробовать. Возможно, вы найдете здесь что-нибудь интересное для себя.
4- comp.dcom.cell-relay. Посвящена ATM и локальным сетям ATM.
4- comp.protocols.tcp-ip. Посвящена набору протоколов TCP/IP.
4- comp.compression.research. Посвящена сжатию с потерями и без.
4- sci.nonlinear. Посвящена всем аспектам нелинейности, включая самоподобие.
Глава 2
Архитектура протоколов
Чтобы связь полностью была невозможной, у прием-
ника и передатчика не должно быть никаких общих
правил — ни алфавита, ни синтаксиса.
Копии Черри. О человеческом общении
Мы начинаем эту главу с введения понятия многоуровневой архитектуры прото-
колов. Затем мы изучим наиболее важную архитектуру подобного рода — набор
протоколов TCP/IP, который ориентирован на Интернет и является основой для
разработки широкого диапазона стандартов в области связи между компьютера-
ми. Практически все производители компьютеров теперь поддерживают эту архи-
тектуру. Другой хорошо известной архитектурой является эталонная модель OSI
(Open Systems Interconnection — взаимодействие открытых систем), представля-
ющая собой стандартизированную архитектуру, часто используемую для описа-
ния функций связи, но редко реализуемую в настоящее время.
Следом за обсуждением архитектур протоколов исследуется важная концеп-
ция объединения сетей. Организациям часто приходится использовать несколько
сетей. Поэтому возникает необходимость их объединения, что поднимает вопро-
сы, связанные с архитектурой протоколов.
2.1. Необходимость в архитектуре
протоколов
Когда компьютеры, терминалы или другие устройства обработки данных обмени-
ваются данными, участвующие в этом процессе процедуры могут быть довольно
сложными. Рассмотрим, к примеру, процесс переноса файла между двумя компь-
ютерами. Между этими двумя компьютерами должен существовать путь передачи
данных либо напрямую, либо через сеть. Но этого недостаточно. Как правило, тре-
буется выполнить некоторые задачи:
1. Система-источник должна либо активизировать прямой путь передачи дан-
ных, либо информировать сеть о той системе, с которой она хочет устано-
вить связь.
2. Система-источник должна убедиться, что система-приемник готова к полу-
чению данных.
2.2. Архитектура протоколов TCP/IP
51
3. Приложение передачи файлов системы-источника должно быть уверено, что
программа управления файлами принимающей системы готова принять
и сохранить файл для пользователя.
4. Если форматы файлов, используемые двумя системами, несовместимы, одна
из систем должна выполнить функцию преобразования формата.
Ясно, что между этими двумя компьютерными системами должна быть высо-
кая степень сотрудничества. Вместо того чтобы реализовывать всю эту лотку в виде
единого модуля, задача разбивается на подзадачи, каждая из которых реализуется
отдельно. В архитектуре протоколов модули организуются в виде вертикального
стека. Каждый уровень стека выполняет соответствующее подмножество функций,
требуемое для общения с другой системой. Каждый уровень доверяет выполне-
ние более примитивных функций расположенному ниже уровню, что позволяет
скрывать детали реализации этих функций. Каждый уровень предоставляет услу-
ги более высокому уровню. В идеальном случае все уровни должны быть строго
определены, так что в результате изменений в одном уровне не требуется менять
другие уровни.
Конечно, для общения нужны двое, поэтому одинаковый набор многоуровне-
вых функций находится на двух системах. Взаимодействие двух систем реализу-
ется соответствующими друг другу, или одноранговыми (peer), уровнями стека
протоколов. Их общение происходит путем обмена форматированными блоками
данных, подчиняющимися набору правил, называемому протоколом (protocol).
Ключевыми чертами протокола являются:
4- синтаксис — описывает формат блоков данных;
4 семантика — включает управляющую информацию для координации и об-
работки ошибок;
4 синхронизация — включает согласование скоростей и установку последова-
тельности операций.
2.2. Архитектура протоколов TCP/IP
Архитектура протоколов TCP/IP представляет собой результат эксперименталь-
ных исследований сети с коммутацией пакетов ARPANET, основанной управле-
нием ARPA (Advanced Research Projects Agency — управление перспективного
планирования научно-исследовательских работ) при министерстве обороны США.
Обычно эту архитектуру называют набором, или стеком, протоколов TCP/IP. Этот
набор состоит из большого количества протоколов, стандартизированных советом
IAB (Internet Activities Board — совет по функционированию Интернета).
Уровни набора протоколов TCP/IP
В общих чертах во взаимодействии участвуют три агента: приложения, компьюте-
ры и сети. Примеры приложений включают передачу файлов и электронную поч-
ту'. Нас здесь будут интересовать распределенные приложения, занимающиеся
52
Глава 2. Архитектура протоколов
обменом данными между двумя компьютерами. Эти приложения выполняются на
компьютерах, часто способных поддерживать несколько одновременно работаю-
щих приложений. Компьютеры соединены сетями, и данные передаются по сети с
одного компьютера на другой. Таким образом, при передаче данных от одного при-
ложения к другому данные сначала передаются компьютеру, па котором распола-
гается приложение, а затем, уже внутри компьютера, передаются приложению-
получателю.
Учитывая все сказанное, кажется естественным организовать взаимодействие
с помощью пяти относительно независимых уровней:
♦ физического уровня;
♦ уровня доступа к сети;
♦ межсетевого уровня;
♦ транспортного уровня;
♦ прикладного уровня.
К физическому уровню (physical layer) относится интерфейс между устройством
(например, компьютером или рабочей станцией) и средой, по которой передаются
данные, или сетью. Этот уровень имеет дело с характеристиками передающей сре-
ды, природой сигналов, скоростью передачи данных и т. п.
К уровню доступа к сети (network access layer) относится обмен данными
между оконечной системой (сервером, рабочей станцией и т. д.) и сетью, с кото-
рой она соединена. Передающий компьютер должен предоставить сети адрес
компьютера-получателя, чтобы сеть могла направить данные по назначению.
Передающий компьютер может также по желанию вызвать определенные служ-
бы, предоставляемые сетью. Используемое на этом уровне программное обеспе-
чение зависит от типа сети. Разработано множество стандартов для коммутации
каналов, коммутации пакетов (например, ретрансляции кадров), локальных се-
тей (например, Ethernet) и т. д. Таким образом, имеет смысл выделить функции,
относящиеся к вопросам доступа в сеть, в отдельный уровень. В результате ос-
тавшаяся часть программного обеспечения связи, располагающаяся над уровнем
доступа к сети, не должна заниматься вопросами, характерными для используе-
мой сети. Одно и то же программное обеспечение высокого уровня должно пра-
вильно работать независимо от того, к какой сети присоединен компьютер, на
котором оно работает.
Уровень доступа к сети решает задачи доступа и маршрутизации данных меж-
ду двумя оконечными системами, соединенными одной сетью. В тех случаях, ког-
да два устройства соединены с разными сетями, требуются процедуры, позволяю-
щие предавать данные между такими сетями. Эту задачу решает межсетевой
уровень (internet layer). Для маршрутизации пакетов по объединенным сетям на
данном уровне используется протокол IP (Internet Protocol — Интернет-прото-
кол). Этот протокол реализуется не только оконечными системами, но также и
маршрутизаторами. Маршрутизатор представляет собой соединяющий две сети
процессор, чья основная функция заключается в ретрансляции данных из одной
сети в другую по определенному маршруту от источника к приемнику.
2.2. Архитектура протоколов TCP/IP
53
Независимо от природы обменивающихся данными приложений, как правило,
требуется, чтобы обмен данными происходил надежно. Это значит, что мы долж-
ны быть уверены в том, что все переданные данные достигли получателя, и имен-
но в том порядке, в котором они были отправлены. Как мы увидим, механизмы
обеспечения надежности в значительной мере независимы от природы приложе-
ний. Таким образом, имеет смысл собрать эти механизмы в общем уровне, совмест-
но используемом всеми приложениями. Этот уровень обычно называют транс-
портным уровнем (transport layer), или уровнем связи между хостами (host-to-host
layer). На этом уровне чаще всего применяется протокол TCP (Transmission
Control Protocol — протокол управления передачей).
Наконец, на прикладном уровне (application layer) поддерживается логика ра-
боты разнообразных пользовательских приложений. Для каждого типа приложе-
ний, например передачи файлов, требуется отдельный модуль, специфический для
данного приложения.
Протоколы TCP и UDP
Для большинства приложений, входящих в архитектуру TCP/IP, в качестве прото-
кола транспортного уровня используется протокол TCP. Он обеспечивает надеж-
ное соединение для передачи данных между двумя приложениями. Соединение
представляет собой временную логическую связь двумя сущностями различных
систем. На время соединения каждая сущность отслеживает входящие и исходя-
щие протокольные модули данных (Protocol Data Unit, PDU), чтобы регулиро-
вать поток модулей данных и обеспечивать восстановление в случае потери пли
повреждения модуля данных.
На рис. 2.1, а показан формат заголовка пакета протокола TCP, состоящего как
минимум из 20 байт, или 160 бит. Поля «Порт источника» и «Порт приемника»
идентифицируют приложения в принимающей и передающей системах, использу-
ющих соединение1. Поля «Порядковый номер», «Номер подтверждения» и «Окно»
обеспечивают управление потоком и контроль ошибок. Поле «Контрольная сумма»
размером 16 разрядов используется для обнаружения ошибок в ТСР-сегменте.
Детальное описание этих полей имеется в главе 3.
Помимо TCP существует еще один протокол транспортного уровня, часто ис-
пользуемый как часть набора TCP/IP, — протокол UDP (User Datagram Protocol —
пользовательский протокол дейтаграмм). Протокол UDP не гарантирует достав-
ки, очередности передачи пакетов пли защиты от дублирования. Протокол UDP
позволяет процедурам отправлять сообщения другим процедурам при помощи
минимума протокольного механизма. Некоторые приложения, ориентированные
на транзакции, используют протокол UDP. Одним из примеров является прото-
кол SNMP (Simple Network Management Protocol — простой протокол сетевого
управления), стандартный протокол сетевого управления для сетей TCP/IP. По-
скольку этот протокол не создает соединений, у протокола UDP немного работы.
1 Термин по/mi (port) имеет то же значение, что и термин точка доступа к службе (Service Access Point,
SAP), используемый в документах OS1.
54
Глава 2. Архитектура протоколов
По существу, он добавляет к протоколу IP способность адресации к порту. Легче
всего в этом убедиться, взглянув на заголовок UDP, показанный на рис. 2.1, б.
Порт источника Порт приемника
Порядковый номер
Номер подтверждения
Длина Не . Флаги заголовка используется Окно
Контрольная сумма Срочный указатель
Параметры и заполнение
Бит: О
31
Порт источника
Порт приемника
Длина сегмента
Контрольная сумма
б
Рис. 2.1. Заголовки пакетов TCP и UDP
Протоколы IP и IPv6
В течение десятилетий основой архитектуры TCP/IP был протокол IP. На рис. 2.2, а
показан формат заголовка IP (в версии IPv4), состоящего как минимум из 20 байт,
или 160 бит. Заголовок содержит 32-разрядные адреса отправителя и получателя.
Поле «Контрольная сумма» используется для обнаружения ошибок в заголовке,
чтобы избежать неверной доставки. Поле «Протокол» указывает, какой протокол,
например TCP, UDP или другой протокол высокого уровня, использует IP. Поля
«Флаги» и «Смещение фрагмента» используются в процессе фрагментации и по-
вторной сборки, при котором одна IP-дейтаграмма при передаче делится на не-
сколько IP-дейтаграмм, а затем снова собирается в пункте назначения.
В 1995 г. проблемная группа инженерной поддержки Интернета (Internet
Engineering Task Force, IETF), разрабатывающая стандарты для Интернета, вы-
пустила под именем IPng (Internet Protocol, next generation — Интернет-прото-
кол нового поколения) спецификацию для протокола IP следующего поколения.
В 1996 г. эта спецификация была преобразована в стандарт, получивший назва-
ние IPv6. По сравнению с существующим протоколом IP, IPv6 предоставляет ряд
функциональных усовершенствований, разработанных для лучшего соответствия
высоким скоростям современных сетей и смешанным потокам данных, включаю-
щим графику и видео, все более превалирующим в настоящее время. Но главная
2.2. Архитектура протоколов TCP/IP
55
причина создания новой версии протокола заключалась в необходимости поддер-
жания большего числа адресов. В применяемом сегодня протоколе IP для обо-
значения отправителя и получателя пакета используется 32-разрядпый адрес. При
экспоненциальном росте Интернета и частных сетей, соединенных с Интернетом,
такая длина адресного поля уже сейчас стала недостаточной, чтобы предоставить
адреса всем системам, которым нужно подключение к Интернету. Как видно из
рис. 2.2, б, заголовок пакета формата IPv6 содержит 128-разрядные поля адресов
отправителя («Адрес источника») и получателя («Адрес приемника»).
31
Бит:
О 4 8 16 19
Версия IHL Тип службы Полная длина
Идентификатор Флаги Смещение фрагмента
Время жизни Протокол Контрольная сумма заголовка
Адрес источника
Адрес приемника
Параметры и заполнение
Рис. 2.2. Заголовки пакетов IP
Наконец, предполагается, что все системы, использующие архитектуру прото-
колов TCP/IP, перейдут с текущей версии протокола IP на IPv6, хотя этот про-
цесс может занять много лет, если не десятилетий. Детали протоколов IPv4 и IPv6
обсуждаются в главе 3.
56
Глава 2. Архитектура протоколов
Работа протоколов TCP и IP
На рис. 2.3 показано, как при связи конфигурируются протоколы TCP и IP. Отдель-
ные сети, составляющие объединенную сеть, обычно называют подсетями (sub-
networks). Для соединения компьютера с подсетью используется некий протокол
доступа к сети, например Ethernet. Если хост находится в другой подсети, этот
протокол позволяет хосту посылать данные по подсети другому хосту или марш-
рутизатору. Протокол IP реализован во всех оконечных системах и маршрутиза-
торах. Он действует как ретранслятор для передачи блока данных от одного хоста
через несколько маршрутизаторов к другому хосту. Протокол TCP реализован
только на оконечных системах. Он отслеживает блоки данных, обеспечивая их
надежную доставку соответствующему приложению.
ХостА
Приложение X
Приложение Y
TCP
Протокол доступа к сети 1
_ Глобальный
сетевой адрес
Хост В
Логическое соединение
(ТСР-соединение)
Порт, или точка доступа
к службе (SAP)
IP
Физический уровень
Сеть 1
Логическое соединение
(например,
виртуальный канал)
Адрес точки соединения подсети
IP
Точка входа
в сеть 1
Протокол доступа к сети 2
Физический уровень
Маршрутизатор J
Точка входа
в сеть 2
Сеть 2
Рис. 2.3. Концепция TCP/IP
Для успешного взаимодействия каждая сущность в системе в целом должна
иметь уникальный адрес. Чтобы данные могли быть доставлены правильному хосту,
у каждого хоста должен быть уникальный глобальный межсетевой адрес. У каж-
дого процесса хоста должен быть адрес, уникальный в пределах данного хоста. Это
позволит транспортному протоколу (TCP) доставить данные нужному процессу.
Эти адреса обычно называют портами.
Проследим выполнение простой операции. Предположим, что процесс, ассоции-
рованный с портом 1 хоста А, хочет послать сообщение другому процессу, ассо-
2.2. Архитектура протоколов TCP/IP
57
циированному с портом 3 хоста В. Процесс хоста А передает сообщение протоко-
лу TCP с указанием переслать его хосту В. Обратите внимание на то, что протоко-
лу IP не нужно знать номер порта получателя. Все, что ему нужно знать, — то что
данные направляются хосту В. Затем протокол IP передает сообщение уровню
доступа к сети (например, логическому уровню Ethernet) с наставлением пере-
слать его маршрутизатору J (первый промежуточный участок на пути к хосту В).
Для управления этими действиями вместе с данными пользователя должна
передаваться также управляющая информация, как показано на рис. 2.4. Допустим,
передающий процесс формирует блок данных и передает его уровню TCP. TCP
может для удобства разбить этот блок на фрагменты меньшего размера. К каждо-
му такому фрагменту уровень TCP добавляет управляющие данные, называемые
заголовком TCP, в результате чего получается TCP-сегмент (TCP-segment). Эта
управляющая информация используется одноранговой сущностью протокола TCP
на хосте В. Ниже перечислены поля этого заголовка:
♦ Порт приемника. Когда TCP-сущность хоста В получает сегмент, она долж-
на знать, кому следует доставить эти данные.
♦ Номер сегмента. Протокол TCP нумерует отправляемые сегменты по по-
рядку, так что если они прибывают не в том порядке, TCP-сущность хоста В
может восстановить порядок.
+ Контрольная сумма. Отправляющая TCP-сущность добавляет к сегменту
код, представляющий собой функцию содержимого остальной части сегмен-
та. Получающая TCP-сущность выполняет те же вычисления и сравнивает
результат с полученным кодом. Несоответствие является признаком ошиб-
ки при передаче.
Рис. 2.4. Протокольные модули данных в архитектуре TCP/IP
58
Глава 2. Архитектура протоколов
Далее уровень TCP передает каждый сегмент уровню IP с инструкциями пере-
дать его хосту В. Эти сегменты должны быть переданы по одной или нескольким
подсетям и пройти через несколько промежуточных маршрутизаторов. Для этой
операции также требуется управляющая информация. Таким образом, уровень IP
добавляет к каждому сегменту заголовок с управляющей информацией, в резуль-
тате чего получается IP-дейтаграмма. В заголовке IP хранится, например, адрес
хоста-получателя (в данном примере — хоста В).
Наконец, каждая IP-дейтаграмма передается уровню доступа к сети для пере-
дачи по первой подсети на пути к пункту назначения. Уровень доступа к сети до-
бавляет свой собственный заголовок, создавая пакет, или кадр. Пакет передается
по подсети маршрутизатору J. В заголовке пакета содержится информация, необ-
ходимая для передачи данных по подсети. Например, заголовок содержит следу-
ющие поля:
♦ локальный адрес получателя пакета — подсеть должна знать, какому присо-
единенному устройству следует доставить пакет;
♦ запрос характеристик — протокол доступа к сети может запросить у подсе-
ти определенные характеристики, например приоритет.
На маршрутизаторе J заголовок пакета удаляется и изучается заголовок IP.
Опираясь на информацию об адресе получателя в заголовке IP, IP-модуль марш-
рутизатора направляет дейтаграмму по подсети 2 хосту В. Для этого к дейтаграм-
ме снова добавляется заголовок протокола доступа к сети.
Когда данные прибывают на хост В, происходит обратный процесс. На каждом
уровне соответствующий заголовок удаляется, а остаток передается следующему
более высокому уровню до тех пор, пока исходные данные пользователя не дос-
тавляются процессу-получателю.
Блок данных на каждом протокольном уровне называют протокольным моду-
лем данных (Protocol Data Unit, PDU). Таким образом, TCP-сегмент является про-
токольным модулем данных для протокола TCP.
Приложения TCP/IP
Для работы поверх протокола TCP было разработано множество стандартных при-
ложений. Мы упомянем только три самых популярных.
Протокол SMTP (Simple Mail Transfer Protocol — простой протокол элект-
ронной почты) обеспечивает базовую службу электронной почты. Он предос-
тавляет механизм передачи сообщений между отдельными хостами. Функции
протокола SMTP включают списки рассылки, квитанции о получении и про-
движении данных. Протоколом SMTP не определяется способ создания сооб-
щений. Для этого требуется локальный текстовый редактор или другое средство
создания сообщений. После того как сообщение создано, протокол SMTP при-
нимает сообщение и с помощью протокола TCP посылает его SMTP-модулю
на другом хосте. Принимающий SMTP-модуль сохраняет полученное сообщение
в локальном почтовом ящике пользователя при помощи локального пакета элект-
ронной почты.
2.3. Модель OSI
59
Протокол FTP (File Transfer Protocol — протокол передачи файлов) использу-
ется для отправки файлов из одной системы в другую по команде пользователя.
Протокол позволяет пересылать как текстовые, так и двоичные файлы. Кроме того,
протокол предоставляет средства управления доступом пользователя. Когда пользо-
ватель желает начать передачу файла, протокол FTP устанавливает ТСР-соедине-
ние с получающей системой для обмена управляющими сообщениями. Такое
сообщение позволяет передать идентификатор и пароль пользователя, а также по-
зволяет пользователю указать файл и желаемое действие с файлом. После того как
передача файла одобрена, устанавливается второе TCP-соединение для пересыл-
ки данных. Пересылка файла выполняется без затрат на передачу заголовков или
управляющей информации на прикладном уровне. Когда передача файла завер-
шается, используется управляющее соединение, чтобы сигнализировать о завер-
шении операции и принять новые команды передачи файлов.
Протокол TELNET предоставляет возможность удаленной регистрации, с помо-
щью которой пользователь терминала или персонального компьютера может за-
регистрироваться на удаленном компьютере и работать с ним, как если бы он был
напрямую соединен с этим компьютером. Этот протокол был разработан для рабо-
ты с простыми алфавитно-цифровыми терминалами. Протокол TELNET фактиче-
ски реализуется в двух модулях: пользовательский модуль TELNET взаимодейству-
ет с модулем терминального ввода-вывода, что обеспечивает связь с локальным
терминалом. Он преобразует символы реального терминала в сетевой стандарт
и наоборот. Серверный модуль TELNET взаимодействует с приложением, действуя
как обработчик суррогатного терминала, так что удаленные терминалы выглядят
для приложения как локальные. Терминальный трафик между серверным и пользо-
вательским модулями TELNET переносится по ТСР-соединению.
2.3. Модель OSI
Эталонная модель OSI (Open Systems Interconnection — взаимодействие откры-
тых систем) была разработана международной организацией по стандартизации
ISO1 (International Organization for Standardization) в качестве модели для архи-
тектуры компьютерных протоколов и как основа для разработки стандартов про-
токолов. Модель OSI состоит из семи уровней:
♦ прикладного уровня;
♦ уровня представления;
♦ сеансового уровня:
♦ транспортного уровня;
♦ сетевого уровня;
♦ уровня передачи данных;
♦ физического уровня.
' ISO — нс сокращение (в последнем случае оно выглядело бы как IOS), а слово, образованное от гре-
ческого слова «исос», что означает «равный».
60
Глава 2. Архитектура протоколов
На рис. 2.5 показана модель OSI, а также предоставлено краткое описание функ-
ций, выполняемых на каждом уровне. Цель модели OSI состоит в том, чтобы раз-
рабатываемые протоколы выполняли функции каждого уровня.
Прикладной уровень
Обеспечивает доступ пользователей к окружению OSI,
а также предоставляет распределенные
информационные службы.
Уровень представления
Обеспечивает прикладному процессу независимость
от различий в представлении данных (синтаксисе).
Сеансовый уровень
Предоставляет структуру управления
для взаимодействия приложений; устанавливает
и разрывает соединения (сеансы) между приложениями,
а также управляет соединениями.
Транспортный уровень
Обеспечивает надежный и прозрачный перенос данных
между конечными точками; обеспечивает сквозное
восстановление после ошибок и управление потоком.
Сетевой уровень
Обеспечивает независимость верхних уровней
от технологий передачи данных и коммутации, применяемых
для соединения систем; отвечает за установку и разрыв
соединений, а также за управление соединениями.
Уровень передачи данных
Обеспечивает надежную передачу информации
по физической линии; посылает блоки (кадры) с необходимой
синхронизацией, контролем ошибок и управлением потоком.
Физический уровень
Обеспечивает передачу неструктурированного потока битов
по физическому носителю; имеет дело с механическими,
электрическими, функциональными и процедурными
характеристиками доступа к физическому носителю.
Рис. 2.5. Уровни модели 0SI
Разработчики модели OSI предполагали, что эта модель и протоколы, разраба-
тываемые в ее рамках, будут доминировать в средствах компьютерной связи и в
конце концов вытеснят фирменные протоколы и конкурирующие модели, такие
как TCP/IP. Этого не произошло. Хотя в контексте OS1 было создано много по-
лезных протоколов, сама семиуровневая модель не получила всеобщего призна-
ния. Напротив, доминирующей стала архитектура TCP/IP. У этого результата
было несколько причин. Возможно, самая важная из них заключалась в том, что
на момент разработки основных протоколов OSI аналогичные протоколы TCP/IP
были уже работоспособными и хорошо отлаженными. Когда компании начали
2.4. Объединение сетей
61
ощущать необходимость в межсетевой связи, только архитектура TCP/IP была
готова к применению. Другая причина состояла в том, что модель OSI излишне
сложна, в ней семь уровней делают то же, что в архитектуре TCP/IP обеспечива-
ется меньшим количеством уровней.
Рисунок 2.6 иллюстрирует приблизительное соответствие уровней в архитек-
турах TCP/IP и OSI.
OSI TCP/IP
Прикладной уровень Прикладной уровень
Уровень представления
Сеансовый уровень
Транспортный уровень (уровень связи между хостами)
Транспортный уровень
Сетевой уровень Интернет
Уровень сетевого доступа
Уровень передачи данных
Физический уровень Физический уровень
Рис. 2.6. Сравнение архитектур OSI и TCP/IP
2.4. Объединение сетей
В большинстве случаев локальная или глобальная сеть не является чем-то изо-
лированным. У организации может быть несколько близко расположенных ло-
кальных сетей различных типов для удовлетворения широкого спектра требова-
ний. У организации может быть несколько близко расположенных локальных
сетей одного типа для повышения производительности или для поддержания бо-
лее высокого уровня безопасности. У организации может быть несколько далеко
расположенных локальных сетей, которые необходимо объединить при помощи
глобальных сетей для централизованного управления распределенным информа-
ционным обменом.
Далее перечислены некоторые часто используемые термины, относящиеся
к объединению сетей:
♦ Компьютерная сеть (communication network). Оборудование, предостав-
ляющее услуги по передаче данных между устройствами, присоединен-
ными к сети.
62
Глава 2. Архитектура протоколов
♦ Объединенная сеть (internet). Набор компьютерных сетей, соединенных
мостами и/или маршрутизаторами.
> Интранет (intranet). Объединенная сеть, используемая одной организа-
цией, обеспечивающая работу ключевых Интернет-приложений, в основном
Всемирной паутины. Интранет функционирует в организации для внутрен-
них целей и может существовать как изолированная самостоятельная объ-
единенная сеть или иметь соединения с Интернетом.
♦ Подсеть (subnetwork). Отдельная сеть объединенной сети. Этот термин по-
зволяет избежать двусмысленности, так как, с точки зрения пользователя,
вся объединенная сеть представляет собой! единую сеть.
+ Оконечная система (End System, ES). Устройство, присоединенное к одной
из сетей объединенной сети и используемое для поддержания приложений
конечного пользователя или служб.
♦ Промежуточная система (Intermediate System, IS). Устройство, соединен-
ное с двумя сетями и обеспечивающее связь оконечных систем, присоеди-
ненных к различным сетям.
+ Мост (bridge). Промежуточная система, используемая для объединения двух
локальных сетей со сходными протоколами. Мост работает как фильтр адре-
сов, передавая пакеты из одной сети в другую. Мост не изменяет содержи-
мого пакетов и ничего не добавляет к пакету. Мост работает на уровне 2 мо-
дели OSI.
♦ Маршрутизатор (router). Промежуточная система, используемая для объ-
единения двух локальных сетей, протоколы которых могут быть схожими,
но могут и различаться. Маршрутизатор применяет межсетевой протокол,
поддерживаемый каждым маршрутизатором и каждой оконечной систе-
мой. Маршрутизатор функционирует на уровне 3 модели OSI.
С точки зрения пользователя, объединенный набор сетей может выглядеть про-
сто как сеть большего размера. Однако в случае, если каждая сеть сохраняет свою
индивидуальность, а для передачи данных по нескольким сетям нужны специ-
альные механизмы, тогда вся конфигурация часто называют объединенной сетью,
а составляющие ее сети — подсетями. Самая крупная объединенная сеть называ-
ется Интернетом. Интернет развился из скромной экспериментальной сети с ком-
мутацией пакетов и послужил основой для разработки технологии объединения
сетей и в качестве модели для частных объединенных сетей, функционирующих
в пределах своих организаций. Последние часто называют интранетом.
Каждая подсеть объединенной сети поддерживает связь между соединенными
с ней устройствами. Эти устройства называют оконечными системами. Кроме того,
подсети соединены с устройствами, называемыми в документах ISO промежуточ-
ными системами. Промежуточные системы обеспечивают путь для связи и вы-
полняют необходимые функции ретрансляции и маршрутизации, что позволяет
обмениваться данными устройствам, присоединенным к разным подсетям объ-
единенной сети.
2.4. Объединение сетей
63
Два типа промежуточных систем представляют особый интерес. Это мосты
и маршрутизаторы. Различия между ними заключаются в используемых ими для
объединения сетей типах протоколов. По сути, мост функционирует на уровне 2
семиуровневой модели OS1 и действует как ретранслятор кадров между однотип-
ными сетями. Маршрутизатор работает на уровне 3 подели OSI и переправляет
пакеты между потенциально разнотипными сетями. Как мост, так и маршрутиза-
тор предполагают использование одних и тех же протоколов верхнего уровня.
О роли и функциях маршрутизаторов рассказывалось в контексте протокола
IP ранее в этой главе. Однако поскольку в общей сетевой схеме маршрутизаторы
играют важную роль, о них следует сказать особо.
Маршрутизаторы
Объединение сетей, состоящих из подсетей различных типов, достигается при по-
мощи маршрутизаторов. Ниже перечислены функции маршрутизатора:
+ Обеспечивать связь между сетями.
Обеспечивать маршрутизацию и доставку данных, которыми обменивают-
ся процессы на оконечных системах, присоединенных к разнотипным сетям.
Предоставлять эти функции таким образом, чтобы для этого не требовалось
менять архитектуру любой из присоединенных подсетей.
Последний пункт предполагает способность маршрутизатора приспосабливать-
ся к многочисленным различиям в сетях, некоторые из которых перечислены ниже:
♦ Схемы адресации. Сети могут использовать различные схемы присвоения ад-
ресов устройствам. Например, локальная сеть IEEE 802 использует 48-би-
товые адреса для каждого присоединенного устройства. В сетях ATM обыч-
но применяются 15-значные десятичные адреса (каждая десятичная цифра
отдельно кодируется четырьмя битами, в результате получается 60-битовый
адрес). Кроме того, должна предусматриваться некая форма глобальной ад-
ресации, а также служба каталогов.
♦ Максимальный размер пакета. Пакеты из одной сети, возможно, потребует-
ся разбить на фрагменты меньшего размера, чтобы передать их по другой
сети. Этот процесс называется сегментацией (segmentation). Например, по
сети Ethernet могут передаваться пакеты размером до 1500 байт. В сетях
ретрансляции кадров (frame relay) максимальный размер пакета составля-
ет, как правило, 1600 байт. Пакет, переправляемый маршрутизатором из
сети ретрансляции кадров в сеть Ethernet, возможно, нужно будет разбить
на два меньших фрагмента.
♦ Интерфейсы. Аппаратные и программные интерфейсы разных сетей разли-
чаются. Маршрутизатор не должен зависеть от этих различий.
♦ Надежность. Разные сетевые службы могут варьироваться от надежного
сквозного виртуального канала до ненадежной службы. Работа маршрути-
заторов не должна зависеть от предположений о надежности сети.
64
Глава 2. Архитектура протоколов
Перечисленные выше требования лучше всего удовлетворяются межсетевым
протоколом, например IP, реализованным на всех оконечных системах и маршру-
тизаторах.
Пример объединения сетей
На рис. 2.7 показана конфигурация, с помощью которой мы будем иллюстриро-
вать взаимодействие протоколов в плане объединения сетей. В данном случае мы
сконцентрируем наше внимание на сервере, соединенном с глобальной сетью
ATM, и рабочей станции, присоединенной к локальной сети IEEE 802. Две сети
соединены маршрутизатором1. Маршрутизатор предоставляет соединение между
сервером и рабочей станцией, благодаря которому эти оконечные системы могут
игнорировать детали расположенных между ними сетей.
Сервер
Прикладной
уровень
TCP
-« . IP
Рабочая станция
ATM
Физический
уровень
Локальная сеть IEEE 802
Рис. 2.7. Пример конфигурации TCP/IP
Рисунки 2.8-2.10 иллюстрируют типичные этапы передачи блока данных, напри-
мер файла или веб-страницы, с сервера приложению на рабочей станции через
объединенную сеть. В данном примере сообщение проходит всего через один мар-
шрутизатор. Прежде чем данные могут быть отправлены, прикладной и транспорт-
1 Архитектуру протокола IEEE 802 образует физический уровень, уровень управления доступом к но-
сителю (Medium Access Control, МАС), ответственный за адресацию и обработку ошибок, а также
уровень управления логическим соединением (Logical Link Control, LLC), ошетстпениьш за логи-
ческие соединения и идентификацию пользователя этого уровня.
2.4. Объединение сетей
65
ный уровни сервера договариваются с соответствующими уровнями рабочей
станции о приемлемых правилах сеанса обмена данными. Эти правила включают
используемый набор символов, метод проверки ошибок и т. п. Для этой цели на
каждом уровне используется соответствующий протокол.
Диалог одноранговых
сущностей. Перед
отправкой данных
передающее и принимающее
приложения договариваются
\ о формате и способе
т.______кодирования, а также
Прикладной Решают обменяться данными,
уровень ►
1. Подготовка данных.
Прикладной протокол подготавливает
блок данных для передачи.
Например, письмо (SMTP), файл (FTP)
или блок введенных пользователем
данных (TELNET).
2. Применение общего синтаксиса
(при необходимости данные
конвертируются в формат, ожидаемый
получателем). Это может быть другой набор
символов, шифр и/или сжатие.
3. Сегментирование данных. Протокол TCP
может разбить блок данных на несколько
сегментов, отслеживая их
последовательность. Каждый ТСР-сегмент
включает заголовок, содержащий
порядковый номер и контрольную сумму
кадра для обнаружения ошибок.
[ Данные
TCP
Диалог одноранговых
сущностей.
Две ТСР-сущности
договариваются
установить соединение.
4. Дублирование сегментов. Создается
копия каждого TCP-сегмента на случай
его потери или повреждения. Когда приходит
подтверждение от другой ТСР-сущности,
сегмент удаляется.
[ Т| Данные
5. Фрагментация сегментов. Протокол IP
может разбить TCP-сегмент на несколько
дейтаграмм, чтобы их размер
соответствовал требованиям сети,
по которой предстоит передать
дейтаграммы. Каждая дейтаграмма
включает заголовок, содержащий адрес
получателя, контрольную сумму кадра
и другую управляющую информацию.
Диалог одноранговых
сущностей. Каждая
1Р-дейтаграмма
переправляется через
сети и маршрутизаторы
получающей системе.
| I |Т | Данные
6. Формирование кадров. К каждой
IP-дейтаграмме добавляется заголовок,
в результате получается ячейка ATM.
Заголовок содержит идентификатор
соединения и контрольную сумму
заголовка.
ATM
Диалог одноранговых
сущностей. Каждая ячейка
переправляется через
сеть ATM.
Физический
уровень
| А | I | Т | Данные ~|
*• 7. Передача.
Каждая ячейка
передается
по носителю в виде
последовательности
битов.
Рис. 2.8. Работа протоколов TCP/IP, действия отправителя
66
Глава 2. Архитектура протоколов
10. Маршрутизация пакета.
Протокол IP изучает
заголовок IP и принимает
решение о выборе
маршрута. Он определяет,
какую исходящую линию
следует использовать,
а затем возвращает
дейтаграмму уровню
передачи данных
для транспортировки
по выбранному каналу.
|~| | Т | Данные
9. Обработка ячейки.
Уровень ATM удаляет
заголовок ячейки
и обрабатывает его.
Для обнаружения ошибок
используется контрольная
сумма заголовка. Номер
соединения идентифицирует
источник. _____
| А | I | Т| Данные |
8. Прибытие х;
на маршрутизатор. ’
Получен пришедший
по передающей среде сигнал
и интерпретирован как
ячейка битов.
Диалог одноранговых
сущностей. Маршрутизатор
----► передаст эту дейтаграмму
другому маршрутизатору
или получающей системе.
LLC
[ L | I |Т| Данные [
ATM
МАС
11. Формирование
протокольного модуля
данных LLC. К каждой
IP-дейтаграмме
добавляется заголовок
протокола LLC,
в результате получается
протокольный модуль
данных LLC. Заголовок
содержит порядковый номер
и адресную информацию.
12. Формирование кадра.
К каждому протокольному
модулю данных LLC добавляется
заголовок и концевик
протокола МАС, в результате
получается кадр протокола МАС.
Заголовок содержит адресную
информацию, а концевик —
контрольную сумму кадра.
Физический
уровень
Физический
уровень
Т I М I L I I I Т [ Данные [ М |
13. Передача. Каждый кадр
передается по передающей
среде в виде
последовательности битов.
Рис. 2.9. Работа протоколов TCP/IP, действия маршрутизатора
2.5. Рекомендуемые литература и веб-сайты
Для читателя, интересующегося деталями работы протоколов TCP/IP, суще-
ствует два более чем адекватных трехтомных труда. Книги [58), [59] и [60] стали
классическими и считаются наиболее полными. Труды [216], [217] и [240] столь
же значимы и более подробно описывают работу протоколов. Более компактной
и очень полезной книгой является [160], в которой конспективно, но досконально
рассказывается о многих протоколах, относящихся к архитектуре TCP/IP. Так,
например, в ней описываются два протокола, пропущенные в предыдущих двух
трудах.
Рекомендуемый веб-сайт — NetworkingLinks. На этом сайте имеется замечатель-
ная коллекция ссылок, относящихся к TCP/IP.
2.5. Рекомендуемые литература и веб-сайты
67
20. Доставка данных.
Приложение выполняет все
необходимые преобразования,
включая распаковку и дешифрацию,
и направляет данные
по назначению, например в файл.
19. Повторная сборка данных
пользователя. Если протокол TCP
разбил данные пользователя
на множество сегментов, они снова
собираются, а блок
передается приложению.
18. Обработка ТСР-сегмента.
Уровень TCP удаляет заголовок.
Он проверяет контрольную
сумму кадра и отправляет
подтверждение при ее соответствии
либо отбрасывает кадр, если
контрольная сумма не совпадает.
Также выполняется управление
потоком.
17. Обработка IP-дейтаграммы.
Уровень IP удаляет заголовок.
Обрабатываются порядковый
номер кадра и другая
управляющая информация.
16. Обработка протокольного
модуля данных LLC.
Уровень LLC удаляет заголовок
и обрабатывает его.
Порядковый номер используется
для управления потоком
и контроля ошибок.
Прикладной
уровень:
15. Обработка кадра.
Уровень МАС удаляет заголовок
и концевик и обрабатывает их.
Для обнаружения ошибок
используется контрольная
сумма кадра.
| L | I | Т | Данные |
| М | L | I | Т | Данные | М | |
14. Прибытие в пункт назначения.
Пришедший сигнал получен
по передающей среде
и интерпретирован как набор битов.
МАС
Физический
уровень
Рис. 2.10. Работа протоколов TCP/IP, действия получателя
68
Глава 2. Архитектура протоколов
2.6. Задания
1. С помощью многоуровневых моделей, представленных на рис. 2.11, опиши-
те процесс заказа и доставки пиццы, указав взаимодействие всех уровней.
Рис. 2.11. Архитектура для задания 1
2. Французскому и китайскому премьер-министрам нужно добиться соглаше-
ния по телефону, но никто не говорит на языке партнера. Более того, ни
у кого нет переводчика, говорящего на языке другой стороны. Для каждого
из перечисленных ниже случаев нарисуйте диаграмму, сходную с рис. 2.11
и иллюстрирующую данную ситуацию, а также опишите взаимодействие
всех уровней:
а) у каждого премьер-министра в штате есть английский переводчик;
б) переводчик китайского премьер-министра может переводить только на
японский, а у французского премьер-министра есть переводчик, говоря-
щий по-немецки. Переводчика с немецкого на японский можно найти
в Германии.
3. Перечислите основные недостатки многоуровневого подхода к протоколам.
4. Две армии синих, располагающиеся на противоположных холмах, готовят-
ся атаковать одну армию красных, дислоцирующуюся в долине. Красная
армия может разбить поодиночке любую из синих армий, но не сможет побе-
дить, если синие нападут одновременно. Армии синих общаются при помо-
щи ненадежной системы связи (вестового пешего солдата). Командир од-
ной из синих армий хотел бы атаковать в полдень. Его проблема заключается
в следующем. Если он отправит сообщение другой армии синих с приказом
атаковать, ои не может быть уверен, что оно будет получено. Он может зап-
росить подтверждение, по оно также может не дойти до получателя. Существу-
ет ли протокол, позволяющий двум армиям синих избежать поражения?
5. Сеть широковещательной рассылки — это сеть, в которой данные, переда-
ваемые по используемому совместно каналу связи любой присоединенной
к сети станцией, принимаются всеми остальными станциями. Примером
такой сети является локальная сеть с топологией общей шины, например
2.6. Задания
69
Ethernet, и беспроводная радиосеть. Обсудите необходимость или отсут-
ствие необходимости в сетевом уровне (уровень 3 модели OS1) в сети
hi ироковещательной рассылки.
6. Ниже перечислены некоторые принципы, использованные ISO для опреде-
ления уровней модели OSI. Опираясь на эти принципы, разработайте архи-
тектуру с восемью уровнями и придумайте для нее пример работы. Спроекти-
руйте также архитектуру с шестью уровнями и придумайте пример для нее.
♦ Число уровней должно быть достаточно мало, чтобы избежать громозд-
кости проекта и реализации, но достаточно велико, чтобы отдельные уров-
ни выполняли функции, различающиеся по процессу или технологии.
♦ Границы между уровнями следует выбрать таким образом, чтобы мини-
мизировать число операций между уровнями.
7. На рис. 2.4 протокольный модуль данных уровня N инкапсулирован в про-
токольный модуль данных уровня (N - 1). Протокольный модуль данных
уровня N можно также разбить (сегментировать) на несколько протоколь-
ных модулей данных уровня (N - 1) или сгруппировать (объединить) несколь-
ко протокольных модулей данных уровня Nb протокольном модуле данных
уровня (N - 1).
а) в случае сегментации обязательно ли каждый сегмент уровня (N - 1) дол-
жен содержать копию заголовка уровня N?
б) в случае объединения обязательно ли каждый протокольный модуль
данных уровня N должен сохранять свой заголовок или данные могут
быть консолидированы в едином протокольном модуле данных уровня N
с одним заголовком уровня N?
Глава 3
Протоколы TCP и IP
— Да слушайте же. — страстно продолжал Сайм. — Всякий раз,
когда поезд приходит к станции, я чувствую, что он прорвал
засаду, победил в битве с хаосом. Вы брезгливо сетуете на то,
что после Слоун-Сквер непременно будет Виктория. О нет!
Может случиться многое другое, н, доехав до станции, я чув-
ствую, что был на волосок от гибели. И когда кондуктор кричит:
«Виктория!». — это не пустое слово. Для меня это крик героль-
да, возвещающего победу. Да это и впрямь виктория, победа
адамовых сынов.
Г. К. Честертон. Человек, который был четвергом
В этой главе более детально рассматриваются ключевые протоколы транспортно-
го и межсетевого уровней Интернета. Несомненно, наиболее важным протоколом
транспортного уровня является TCP, который мы изучим первым. Затем мы крат-
ко исследуем другой полезный протокол транспортного уровня — UDP. На меж-
сетевом уровне мы обсудим как протокол IPv4, представляющий собой текущую
версию межсетевого протокола, применяемую в Интернете и частных объединен-
ных сетях, так и протокол IPv6, который должен заменить IPv4.
3.1. Протокол TCP
Текущая версия протокола TCP официально определена в RFC 793‘. Впослед-
ствии к этому документу было добавлено множество спецификаций, описыва-
ющих усовершенствования и реализацию. Те документы, которые требуются
для реализации протокола TCP, согласующегося с требованиями 1989 г., собраны
в RFC 11222. С тех пор появилось множество других документов, отражающих раз-
личные дополнительные изменения. Ссылки на них будут приводиться при необ-
ходимости.
Проще всего начать описание протокола TCP с формата заголовка. TCP ис-
пользует только один тип протокольного модуля данных, который называется
TCP-сегментом (его заголовок показан на рис. 2.1 в главе 2). Поскольку один
1 RFC 793, Transmission Control Protocol, сентябрь 1981 г.
- RFC 1122, Requirements of Internet Hosts — Communication Layers, октябрь 1989 r.
3.1. Протокол TCP
71
заголовок реализует все механизмы протокола, он довольно велик (минимальная
длина 20 байт). Ниже перечислены поля заголовка.
♦ Порт источника (16 бит). Пользователь TCP — источник.
♦ Порт приемника (16 бит). Пользователь TCP — приемник.
♦ Порядковый номер (32 бита). Порядковый номер первого в этом сегменте
байта данных, если не установлен флаг SYN. Если же флаг SYN установлен,
это поле содержит начальный порядковый номер (Initial Sequence Number,
ISN), а номер первого байта данных равен ISN + 1.
♦ Номер подтверждения (32 бита). Возвращаемое подтверждение. Содержит
порядковый номер следующего байта данных, который ожидает получить
ТСР-сущпость.
+ Смещение данных (4 бита). Количество 32-разрядных слов в заголовке.
♦ Резерв (6 бит): Зарезервировано на будущее.
♦ Флаги (6 бит):
♦ URG — признак поля срочного указателя;
♦ АСК — признак поля подтверждения;
♦ PSH — функция продвижения;
♦ RST — сброс соединения;
♦ SYN — синхронизировать порядковые номера;
♦ FIN — признак отсутствия данных от отправителя.
♦ Окно (16 бит). Кредит управления потока в байтах. Содержит количество
байтов данных, указываемое в поле подтверждения, которые получатель
желает принять.
♦ Контрольная сумма (16 бит). Код для обнаружения ошибок.
♦ Срочный указатель (16 бит). Идентифицирует последний байт в последо-
вательности срочных данных. Таким образом получатель узнает, сколько
срочных данных пришло.
♦ Параметры (длина переменная). Описывает дополнительные характеристики.
Поля «Порядковый номер» и «Номер подтверждения» означают байты, а не
целые сегменты. Например, если сегмент содержит порядковый номер 1001 и вклю-
чает 600 байт данных, то порядковый номер относится к первому байту поля дан-
ных. У следующего сегмента поле порядкового номера будет содержать число 1601.
Таким образом, протокол TCP ориентгцюван на поток. Он принимает от пользо-
вателя поток байтов, группирует их в сегменты так, как ему удобно, и нумерует
каждый байт потока.
Флаги PUSH и URGENT реализуют две службы протокола TCP.
♦ Продвижение потока данных (data stream push). Обычно протокол TCP сам
решает, достаточно ли он аккумулировал данных, чтобы сформировать сег-
мент для передачи. Но пользователь TCP может потребовать, чтобы прото-
кол TCP передал все не отправленные на данный момент данные и пометил
их флагом PUSH. На принимающем конце протокол TCP доставит эти
72
Глава 3. Протоколы TCP и IP
данные пользователю. Пользователь может потребовать это, если он дошел
до логического конца данных.
♦ Сигнализация о срочных данных (urgent data signaling). Средство информи-
рования получателя о том, что важные, или «срочные», данные находятся в
поступившем потоке данных. Какое действие следует предпринять, решает
получающий пользователь.
Пользователь TCP (как правило, приложение, например протокол FTP) гене-
рирует команду SEND (передать), чтобы направить блок данных протоколу TCP,
который помешает данные в буфер передачи. Если установлен флаг PUSH, то
любые неотправленные данные в буфере, включая только что туда помещенные,
немедленно посылаются в виде одного или нескольких сегментов, причем послед-
ний сегмент помечается флагом PUSH. В противном случае (если флаг PUSH не
установлен) протокол TCP может накапливать данные в буфере передачи и по-
сылать их в виде одного или нескольких сегментов в зависимости от того, как удоб-
нее протоколу. Например, TCP может подождать, пока накопится больше данных,
чтобы передать их в виде сегментов большего размера, таким образом повышая
эффективность. Пользователь может при обращении к команде SEND установить
флаг URGENT (срочный). В этом случае сегмент маркируется флагом URGENT.
Данные в сегментах, прибывающие по соединению к TCP-сущности, также
хранятся в приемном буфере, связанном с этим соединением. Если пришедшие
данные помечены флагом PUSH, эти данные вместе со всеми данными, находя-
щимися в приемном буфере, немедленно доставляются получателю по команде
RECEIVE (принять). Если пришедшие данные помечены флагом URGENT,
пользователь сигнализируется о наличии срочных данных.
Поле «Контрольная сумма» относится ко всему сегменту вместе с псевдозаго-
ловком, предваряющим заголовок. Псевдозаголовок содержит следующие поля из
заголовка IP: Интернет-адреса отправителя и получателя, используемый прото-
кол, а также длину поля сегмента. Таким образом, протокол TCP защищается от
неверной доставки сегмента протоколом IP. То есть если протокол IP доставит
сегмент не тому хосту, то даже при отсутствии повреждений в сегменте получаю-
щая TCP-сущность обнаружит ошибку в доставке. Контрольная сумма TCP
вычисляется как сложение в дополнительном коде всех 16-разрядных слов псев-
дозаголовка, заголовка TCP и тела сегмента TCP. Перед вычислением само поле
контрольной суммы обнуляется.
Документом RFC 793 определяется только одно значение для поля «Парамет-
ры» — максимальный размер сегмента. Этот 16-разрядный параметр может ис-
пользоваться только в сегментах запроса начального соединения. Он идентифи-
цирует максимальный размер сегмента в байтах, который будет приниматься
соединением. С момента публикации RFC 793 широкое применение получили два
других параметра:
♦ Масштабный множитель окна (window scale factor). Обычно поле «Окно»
в заголовке TCP содержит информацию о кредите в байтах. Когда исполь-
зуется параметр «Масштабный множитель окна», значение в поле «Окно»
умножается на 2f, где F— значение этого параметра. Максимальное допус-
тимое значение F, принимаемое протоколом TCP, равно 14. Этот параметр
используется только в сегментах запроса начального соединения.
3.2. Протокол UDP
73
♦ Временной штамп (timestamp). Этот параметр может использоваться в лю-
бом сегменте данных. Он определяет два дополнительных поля. Протокол
TCP может включать поле «Значение временного штампа» в каждый исхо-
дящий сегмент. Когда другая сторона подтверждает получение этого сегмен-
та, отвечающая TCP-сущность включает поле «Эхо-ответ на временной
штамп» с тем же значением, что и в поле «Значение временного штампа»
в полученном сегменте. Этот параметр позволяет протоколу TCP постоян-
но отслеживать время прохождения сигнала в обе стороны.
3.2. Протокол UDP
Помимо TCP существует еще один протокол транспортного уровня, часто приме-
няемый как часть набора TCP/IP. Это протокол UDP (User Datagram Protocol —
пользовательский протокол дейтаграмм), описанный в RFC 768. Протокол UDP
предоставляет не требующую соединения службу для процедур прикладного уров-
ня. Таким образом, протокол UDP, как правило, является ненадежной службой.
Доставка и отсутствие дубликатов не гарантируется. Однако это не снижает на-
кладных расходов протокола, и он может быть адекватным во многих случаях.
Преимущества протоколов, ориентированных на соединение, очевидны. Они
предоставляют такие возможности, как управление потоком, контроль ошибок и
сохранение исходной очередности доставки. Однако в определенном контексте
служба, не требующая соединения, оказывается более подходящей. На нижних
уровнях (на межсетевом и сетевом) не требующая соединения служба является
более устойчивой. Кроме того, служба, не требующая соединения, представляет
собой «наименьший общий знаменатель» службы, ожидаемой на более высоких
уровнях. Более того, даже на транспортном и более высоких уровнях есть оправ-
дание для не требующей соединения службы. Бывают случаи, когда накладные
расходы на установку и поддержание соединения нежелательны и даже противо-
показаны. Ниже перечислены некоторые примеры:
> Внутренний сбор данных. Включает периодические операции по активному
или пассивному сканированию источников данных, например сенсоров, или
приему автоматических докладов от охранного оборудования или сетевых
компонентов. В ситуации мониторинга реального времени потеря случай-
ного пакета данных, как правило, не представляет проблемы, так как немно-
го позднее поступит следующий доклад.
♦ Распространение данных. Включает сообщения, передаваемые сетевым
пользователям путем широковещательной рассылки, например объявления
о появлении нового узла в сети или изменения в адресе службы, а также рас-
пространение значений реального времени.
♦ Запрос-ответ. Это приложения, в которых служба транзакций предоставля-
ется одним сервером нескольким пользователям распределенной транспорт-
ной службы, а последовательность из единственного запроса и единственно-
го ответа на него является типичной. Использование службы регулируется
на прикладном уровне, а соединения нижних уровней часто оказываются не-
нужными и избыточными.
74
Глава 3. Протоколы TCP и IP
♦ Приложения реального времени. Это приложения речевой связи и телемет-
рии, содержащие определенную избыточную информацию, и/или прило-
жения, к которым предъявляются требования передачи в реальном време-
ни. В таких приложениях бессмысленны функции ориентированных на
соединение служб, например повторная передача.
Таким образом, на транспортном уровне найдется место как для ориентирован-
ных на соединение служб, так и для служб, не требующих соединения.
Протокол UDP работает поверх протокола IP. Поскольку протокол UDP не
требует соединения, ему не так уж много приходится делать. По существу, он всего
лишь добавляет к протоколу IP способность адресации к порту. Это проще всего
заметить, рассмотрев заголовок UDP, показанный на рис. 2.1, б в главе 2. Заголовок
включает номера портов источника и приемника. Поле длины содержит длину все-
го сегмента UDP, включая заголовок и данные. Контрольная сумма вычисляется
по тому же алгоритму, что и в протоколах TCP и IP. В протоколе UDP контрольная
сумма охватывает весь UDP-сегмент вместе с псевдозаголовком, формат которого
полностью совпадает с форматом псевдозаголовка TCP. При обнаружении ошиб-
ки сегмент отбрасывается и никаких более действий не предпринимается.
Поле контрольной суммы в заголовке UDP используется по желанию. Если это
поле не используется, оно устанавливается равным нулю. Однако следует отметить,
что контрольная сумма IP относится только к заголовку IP, а не к полю данных,
которое в этом случае состоит из заголовка UDP и данных пользователя. Таким
образом, если подсчет контрольной суммы выполняется уровнем UDP, тогда дан-
ные пользователя не проверяются.
3.3. Протокол IP
В данном разделе мы рассмотрим версию 4 протокола IP (Internet Protocol — Ин-
тернет-протокол), официально определенного в RFC 7911. Хотя предполагается,
что протокол IPv4 наконец будет заменен версией IPv6, на сегодняшний день
именно IPv4 представляет стандарт протокола IP, применяемый в сетях TCP/IP.
Проще всего описать протокол обмена между двумя IP-сущностями с помощью
формата IP-дейтаграммы, показанной на рис. 2.2 в главе 2. Поля дейтаграммы пе-
речислены ниже:
♦ Версия (4 бита). Номер версии. Это поле позволяет развивать протокол; те-
кущее значение равно 4.
♦ Длина Интернет-заголовка (Internet Header Length, IHL) (4 бита). Длина
заголовка в 32-разрядных словах. Минимальное значение длины равно 5, что
соответствует 20-байтовому заголовку.
♦ Тип службы (Type Of Service, TOS) (8 бит). Обеспечивает управление IP-
модулями оконечной системы и маршрутизаторами на пути дейтаграммы.
На рис. 3.1 показана структура этого поля, определяемая стандартом RFC 13492.
1 RFC 791, Internet Protocol, сентябрь 1981 г.
2 RFC 1349, Type of Service in the Internet Protocol Suite, июль 1992 г.
3.3. Протокол IP
75
♦ Полная длина (16 бит). Полная длина этого фрагмента в байтах.
♦ Идентификатор (16 бит). Порядковый номер, который вместе с адресом
отправителя, адресом получателя и протоколом пользователя должен уни-
кально идентифицировать дейтаграмму. Таким образом, идентификатор
должен быть уникальным для адреса отправителя, адреса получателя и про-
токола пользователя на то время, в течение которого дейтаграмма будет на-
ходиться в объединенной сети.
4- Флаги (3 бит). На текущий момент определены только два бита. Бит MF
означает More Fragments (продолжение следует). Он устанавливается у всех
фрагментов, кроме последнего. По этом}' биту получатель узнает, полу-
чил ли он все фрагменты дейтаграммы. Бит Обозначает Don’t Fragment (не
фрагментировать), то есть команду маршрутизатору не фрагментировать
дейтаграмму, так как получатель не сможет восстановить ее из фрагментов.
Когда этот бит установлен, дейтаграмма будет отброшена, если ее размер
превысит максимально допустимый в данной подсети. Поэтому при уста-
новке этого бита рекомендуется применять маршрутизацию от источника,
чтобы избегать сетей с маленьким максимальным размером пакета.
♦ Смещение фрагмента (13 бит). Положение фрагмента в оригинальной дейта-
грамме, измеряемое в 64-битовых единицах. Это означает, что длина всех фраг-
ментов в байтах, кроме длины последнего фрагмента, должна быть кратна 8.
♦ Время жизни (8 бит). Количество секунд, в течении которого пакету разре-
шено оставаться в объединенной сети. На каждом маршрутизаторе это зна-
чение должно уменьшаться как минимум на единицу, поэтому этот счетчик
обычно просто считает количество маршрутизаторов.
♦ Протокол (8 бит). Следующий протокол высокого уровня, который должен
получить поле данных дейтаграммы. Таким образом, это поле идентифици-
рует тип следующего заголовка в пакете после заголовка IP.
♦ Контрольная сумма заголовка (16 бит). Код обнаружения ошибок защища-
ет от ошибок только заголовок. Поскольку некоторые поля заголовка могут
изменяться при передаче дейтаграммы (например, время жизни и поля, от-
носящиеся к сегментации), эта сумма перепроверяется и пересчитывается
на каждом маршрутизаторе. Контрольная сумма вычисляется как сумма
16-разрядных слов заголовка, сложенных в дополнительном коде. Перед вы-
числением контрольной суммы само поле контрольной суммы обнуляется.
♦ Адрес источника (32 бит). Позволяет по-разному кодировать сеть и оконечную
систему, подсоединенную к указанной сети (7+24 бит, 14+16 бит или 21+8 бит).
♦ Адрес приемника (32 бит). Те же характеристики, что и у адреса источника.
♦ Параметры (длина переменная). Параметры, устанавливаемые отправителем.
♦ Заполнитель (длина переменная). Используется, чтобы гарантировать крат-
ность длины заголовка дейтаграммы 32 битам.
4 Данные (длина переменная). Длина поля данных в байтах должна быть це-
лым числом. Максимальный размер дейтаграммы (данные плюс заголовок)
. может составлять 65 535 байт.
76
Глава 3. Протоколы TCP и IP
3 бита 4 бита 1 бит
Старшинство Тип службы 0
Старшинство Подполе «Тип службы»
111 Управление сетью 1000 Минимизация задержки
110 Управление объединенной сетью 0100 Максимизация пропускной способности
101 Критично 0010 Максимизация надежности
100 Отмена групповой операции 0001 Минимизация финансовой стоимости
111 Групповая операция 0000 Обычная служба
110 Немедленно
001 Приоритет
000 Процедура
Рис. 3.1. Поле «Тип службы» заголовка пакета IPv4
В оставшейся части этого раздела мы обсудим фрагментацию, а затем более
подробно рассмотрим поля адресов, типа службы и параметров.
Фрагментация и восстановление
У различных сетей, составляющих объединенную сеть, могут различаться макси-
мальные размеры пакетов. Было бы неэффективно и неудобно пытаться диктовать
единый размер пакетов для всех сетей. Таким образом, маршрутизаторам может
понадобиться разбить получаемые дейтаграммы на более мелкие фрагменты, преж-
де чем передать их дальше в следующую сеть.
Если дейтаграммы могут фрагментироваться (возможно, неоднократно) за время
следования по маршруту, возникает вопрос, где их восстанавливать. Самое простое
решение — восстанавливать дейтаграммы только у получателя. Основной недостаток
такого подхода состоит в том, что пакеты, проходя через сети, могул только уменьшать-
ся. Это может негативно сказаться на эффективности некоторых сетей. С другой сто-
роны, если разрешить промежуточное восстановление фрагментированных дейтаграмм
на маршрутизаторах, это может привести к некоторым нежелательным результатам:
♦ Маршрутизаторам для работы потребуются большие буферы, к тому же есть
риск, что все буферное пространство окажется занятым фрагментами дей-
таграмм.
4 Все фрагменты дейтаграммы должны будут проходить через один и тот же
шлюз. Это требование снижает преимущества динамической маршрутизации.
В протоколе IP фрагменты дейтаграммы собираются на оконечной системе по-
лучателя. Алгоритм фрагментации IP использует следующую информацию 1Р-за-
головка:
♦ идентификатор (ID);
♦ длина данных (разность между полной длиной и длиной Интернет-заголовка);
♦ смещение фрагмента;
♦ дополнительные флаги.
Оконечная система источника создает дейтаграмму со значением поля «Длина
данных», равным полной длине поля данных, значением поля «Смещение фраг-
3.3. Протокол IP
77
мента», равным нулю, и значением поля «Дополнительные флаги», также установ-
ленным на ноль (ложь). При фрагментации длинной дейтаграммы IP-модуль мар-
шрутизатора выполняет перечисленные ниже задачи:
1. Создает две новые дейтаграммы и копирует поля заголовка поступившей
дейтаграммы в заголовки обеих дейтаграмм.
2. Делит полученное поле данных пользователя на две примерно равные час-
ти по 64-битовой границе и помещает каждую часть в отдельную дейтаграм-
му. Размер первой части должен быть кратен 64 битам.
3. Устанавливает значение поля «Длина данных» первой дейтаграммы равным
длине вставленных данных, а также устанавливает значение поля «Допол-
нительные флаги» равным 1 (истина). Поле «Смещение фрагмента» оста-
ется без изменений.
4. Устанавливает значение поля «Длина данных» второй дейтаграммы равным
длине вставленных данных, а также прибавляет к значению поля «Смеще-
ние фрагмента» длину первой части данных, деленную па 8. Поле «Допол-
нительные флаги» остается без изменений.
На рис. 3.2 показан пример. Эта процедура может быть легко приведена к об-
щему случаю деления дейтаграммы на п частей.
Заголовок
Данные
Исходная дейтаграмма
Длина данных равна 404 байт
Смещение фрагмента равно 0
Поле дополнительных флагов равно 0
Рис. 3.2. Пример фрагментации
78 Глава 3. Протоколы TCP и IP
Чтобы восстановить дейтаграмму, необходимо и достаточно буферного про-
странства. По мере прибытия фрагментов с одним и тем же идентификатором их
поля данных накапливаются в буфере, пока поле данных не будет собрано целиком.
Однако один или несколько фрагментов могут не дойти до получателя, посколь-
ку служба IP не гарантирует доставки. Поэтому требуется некий способ принятия
решения о прекращении сборки и освобождении буфера. Обычно применяются два
метода. В первом случае по прибытии первого фрагмента запускается локальный
таймер. Если интервал ожидания истекает прежде, чем завершается сборка, все
полученные фрагменты отбрасываются. Второй подход заключается в исполь-
зовании поля времени жизни дейтаграммы, содержащегося в заголовке каждого
фрагмента, и продолжении уменьшения этого поля“функцией сборки. Как и при
первом подходе, если время жизни истекает прежде, чем завершается сборка, все
полученные фрагменты отбрасываются.
Адреса IPv4
Поля адресов отправителя и получателя заголовка IP содержат 32-разрядные гло-
бальные межсетевые адреса, как правило, состоящие из идентификатора сети и
идентификатора хоста. Адрес кодируется таким образом, чтобы для обозначения
сети и хоста можно было задействовать переменное число битов, как это показано
на рис. 3.3. Такой способ кодирования обеспечивает гибкость при назначении ад-
ресов хостам и позволяет использовать различные размеры сетей в объединенной
сети. Для следующих условий лучше всего подходят три основных класса сетей:
♦ класс А — немного сетей с большим количеством хостов;
♦ класс В — среднее количество сетей со средним количеством хостов;
♦ класс С — большое количество сетей с небольшим количеством хостов.
В некотором окружении, возможно, лучше всего использовать адреса всех клас-
сов. Например, для корпоративной объединенной сети, состоящей из большого
количества локальных сетей отделов, может потребоваться адрес класса С. Одна-
ко формат адреса позволяет смешивать все три класса адресов в одной и той же
объединенной сети. Смешивание классов приемлемо для объединенной сети, со-
стоящей из нескольких больших сетей, большого числа маленьких сетей плюс не-
которого количества сетей среднего размера.
IP-адреса обычно записываются в виде четырех десятичных чисел, разделенных
точками. Каждое число представляет один байт 32-разрядного адреса. Например,
IP-адрес 11000000 11100100 00010001 00111001 записывается как 192.228.17.57.
Обратите внимание на то, что все адреса сетей класса А начинаются с двоичного
нуля. Сетевые адреса, первый байт которых равен 0 (двоичное 00000000) и 127
(двоичное 01111111), зарезервированы; таким образом, существует 126 номеров
сетей класса А, у которых первый десятичный номер адреса может находиться в ди-
апазоне от 1 до 126. Адреса сетей класса В начинаются с двоичной комбинации 10,
поэтому диапазон первого байта в адресе класса В — от 128 до 191 (от 10000000 до
10111111 в двоичной системе счисления). Второй байт адреса класса В также
3.3. Протокол IP
79
относится к номеру сети, поэтому может существовать 2й = 16 384 сетей с адре-
сами класса В. Для адресов класса С первое десятичное число варьируется в пре-
делах от 192 до 223 (от 11000000 до 11011111). Суммарное количество адресов
класса С составляет 221 = 2 097 1 52.
Хост (24 бита)
Класс А
Хост (16 бит)
1 О
Класс В
V > “Сеть (14 битов)
......... ............ ............
—I I 1 1 о 1-1 • - >« СетьИат) . _ , Хост (8 бит)
Класс С
I 1 1— 1110 i i I Групповая рассылка
Класс D
Til I 11110 I I I I Зарезервировано на будущее
Класс Е
Рис. 3.3. Форматы адресов протокола IPv4
Поле типа службы
Поле «Тип службы» состоит из двух подполей: 3-битового подполя старшинства
и 4-битового подполя типа службы. Эти подполя выполняют взаимодополняющие
функции. Подполе типа службы помогает IP-сущности (в источнике или маршру-
тизаторе) выбирать выходную линию для дейтаграммы, а подполе старшинства
предоставляет информацию об относительном приоритете дейтаграммы, что по-
зволяет более оптимально выделять ресурсы для дейтаграмм.
Подполе типа службы
Подполе типа службы устанавливается отправителем, чтобы указать уровень ка-
чества обслуживания, который должен быть, по возможности, предоставлен этой
Дейтаграмме. Однако маршрутизатор может прореагировать па значение подполя
типа службы (если он учитывает это значение) тремя способами:
♦ Выбор маршрута. Решение о выборе маршрута может быть сделано на ос-
нове типа службы. Например, если дейтаграмма запрашивает минимальную
задержку, ее не следует направлять по подсети, в которую входит спутнико-
вая линия связи.
80
Глава 3. Протоколы TCP и IP
4- Служба подсети. Для следующего транзитного участка маршрутизатор мо-
жет потребовать у подсети тип службы, наиболее соответствующий указан-
ному в подполе типа службы. Многие сети (например, ATM) поддержива-
ют различные типы служб.
♦ Порядок обслуживания (дисциплина) очередей. Маршрутизатор может учесть
значения подполей типа службы и старшинства при обслуживании очере-
дей. Например, маршрутизатор может предоставить первоочередное об-
служивание дейтаграммам, требующим минимального времени задержки,
или попытаться избежать удаления дейтаграмм, требующих максимальной
надежности.
В документе RFC 1349 определены текущая интерпретация поля типа служ-
бы, а в документе RFC 1812’ перечислены требования к маршрутизаторам. Оба
документа сфокусированы на первой альтернативе, а именно на влиянии поля
типа службы на выборе маршрута. Способ, которым маршрутизатор узнает, какими
маршрутами какие типы служб поддерживаются, выходит за рамки данных спе-
цификаций. В целом, существует две возможности. Во-первых, в домене марш-
рутизатора администратор домена может заранее связать разные значения полей
с различными маршрутами. Во-вторых, протокол маршрутизации может динами-
чески следить за характеристиками различных маршрутов, учитывая время задерж-
ки, пропускную способность и количество отброшенных дейтаграмм. Алгоритм
OSPF (Open Shortest Path First — первоочередное открытие кратчайших маршру-
тов) представляет собой пример протокола, поддерживающего данную способ-
ность (см. главу 15).
При реализации маршрутизации с учетом значений поля типа службы доку-
ментом RFC 1812 определяются следующие правила продвижения дейтаграмм
с ненулевым значением этого поля:
1. Маршрутизатор определяет все доступные маршруты к пункту назначения;
если доступных маршрутов нет, дейтаграмма отбрасывается.
2. Если у одного или нескольких маршрутов тип службы соответствует запра-
шиваемому, тогда маршрутизатор выбирает маршрут с лучшей метрикой1 2
(этот выбор обсуждается в части VI этой книги).
3. В противном случае, если у одного или нескольких маршрутов значение
поля типа службы равно 0 (обычная служба), тогда выбирается лучший из
этих маршрутов.
4. В противном случае маршрутизатор отвергает дейтаграмму.
При таком наборе правил маршрутизатор может отказаться от дейтаграммы,
даже если имеется доступный маршрут, но нет маршрута с требуемым типом служ-
бы или с обычной службой. На практике для любого доступного пункта назначе-
ния алгоритмы маршрутизации всегда поддерживают маршрут с полем типа служ-
бы, равным 0.
1 RFC 1349. Requirements for IP Version 4 Routers, июнь 1995 г.
2 Метрика маршрутизации представляет собой измерение «стоимости» маршрута. Примером метрики
является количество транзитных участков (подсетей) на маршруте, а также полное время задержки
маршрута.
3.3. Протокол IP
81
В табл. 3.1 показаны рекомендованные значения поля типа службы, которые
следует запрашивать обычным протоколам.
Таблица 3.1. Рекомендованные значения поля типа службы
Протокол Минимальная задержка Максимальная пропускная способность Максимальная Минимизировать Обычная
надежность финансовые затраты служба
TELNET X
FTP Управление X
Данные X
TFTP X
SMTP Общая фаза фаза данных X X
DNS Запрос UDP Запрос ТОР Перенос зон NNTP X X X
ICMP Ошибки Запросы Ответы* Любой IGP X X X
EGP SNMP ВООТР X X X
* Сообщение ICMP может быть послано со значением поля типа службы, отличным от 0000. В этом
случае ответ должен содержать то же значение поля типа службы.
Подполе старшинства
Подполе старшинства устанавливается, чтобы указать степень срочности или прио-
ритет дейтаграммы. Значение индикатора старшинства может изменяться от наи-
высшего уровня управления сетью до наименьшего уровня процедуры. Уровень
Управления сетью предназначается только для использования внутри подсети.
Например, если сущности управления подсетью необходимо послать управляю-
щую информацию хосту, соединенному с той же подсетью, будет использоваться
этот уровень старшинства. Причем данный уровень может поддерживаться дей-
ствиями отправляющей IP-сущности. Уровень управления объединенной сетью
Предназначается для передачи управляющих сообщений маршрутизаторов, напри-
МеР Для обмена информацией о маршрутах. Названия остальных уровней наво-
дят на размышления, но для их использования нет точного определения1.
-—.—_____
Эти термины имеют смысл в приложениях министерства обороны США и представляют собой стан-
дартные названия сообщений оборонных приложений.
82
Глава 3. Протоколы TCP и IP
На практике маршрутизаторы могут игнорировать это поле. Как и с подполем
типа службы, если маршрутизатор поддерживает подполе старшинства, он может
прореагировать тремя способами: выбором маршрута, службой подсети и дисцип-
линой очереди. Из маршрутов с одинаковыми параметрами выбирается тот, у ко-
торого меньше длина очереди, или тот, следующий транзитный участок которого
поддерживает старшинство или приоритет па уровне подсети (например, локаль-
ная сеть Token ring поддерживает приоритеты). Независимо от выбранного мар-
шрута, если подсеть следующего транзитного участка поддерживает старшинство,
вызывается эта служба.
Однако предполагается, что основной эффект подполя старшинства связан с
дисциплиной очередей маршрутизатора. Более подробно вопрос обработки поля
старшинства маршрутизатором обсуждается в главе 17. Здесь мы рассмотрим ре-
комендации RFC 1812, распадающиеся на две категории:
♦ Обслуживание очередей па маршрутизаторах имеет некоторые тонкости:
♦ На маршрутизаторах должно быть реализовано обслуживание очередей
с учетом значения подполя старшинства. Это означает, что для отправки
по выходящей (логической) линии связи выбирается пакет с максималь-
ным уровнем старшинства.
+ На любом маршрутизаторе могут быть реализованы другие связанные с
политикой процедуры управления пропускной способностью, отличные
от простой обработки пакетов в порядке старшинства. Однако все марш-
рутизаторы должны разрешать подавление своих алгоритмов и ограни-
чиваться обработкой пакетов в порядке старшинства.
♦ Борьба с перегрузкой. Когда маршрутизатор получает пакет, для хранения
которого у него не хватает буферной памяти, он должен отбросить его либо
какой-нибудь другой пакет или несколько пакетов:
♦ Маршрутизатор может отбросить только что полученный пакет. Такая
политика является самой простой, по не самой лучшей.
+ В идеале маршрутизатор должен выбрать пакет, относящийся к сеансу,
сильнее других загружающему линию связи, при условии, что соот-
ветствующая политика качества обслуживания позволяет это. В дей-
таграммном окружении с применением очередей FIFO (First In First
Out — первым прибыл, первым обслужен) рекомендованная полити-
ка заключается в том, чтобы отбрасывать пакет, случайно выбираемый
из очереди. Эквивалентный алгоритм в маршрутизаторах, использующих
справедливое регулирование очередей, заключается в отбрасывании
пакета из самой длинной очереди или имеющей максимальное вирту-
альное время (эта стратегия разъясняется в главе 16). Маршрутизатор.
может применять эти алгоритмы, чтобы определить, какой пакет от-
бросить.
♦ Если реализован и включен алгоритм обслуживания очередей в порядке
старшинства, маршрутизатор не должен отбрасывать пакет, значение под-
поля старшинства которого в заголовке IP выше, чем у пакета, оставлен-
ного в очереди.
3.4. Протокол IPv6
83
♦ Маршрутизатор может защищать пакеты, чьи заголовки IP требуют тип
службы с максимальной надежностью, если это не противоречит преды-
дущему правилу.
«. Маршрутизатор может защищать фрагментированные IP-пакеты, так
как, теоретически, отбрасывание фрагмента дейтаграммы может увели-
чить нагрузку маршрутизатора, потому что отправитель повторно вышлет
все фрагменты этой дейтаграммы.
♦ Чтобы избежать помех или полного распада функций управления, мар-
шрутизатор может защищать пакеты, используемые для управления
процедурами выбора маршрутов, управления линиями связи или сетево-
го управления. Выделенные маршрутизаторы (то есть маршрутизаторы,
не являющиеся одновременно универсальными хостами, терминальны-
ми серверами и т. д.) могут реализовать эту возможность, защищая паке-
ты, отправляемые или получаемые самими маршрутизаторами.
Поле параметров IPv4
Поле параметров представляет собой поле переменной длины, которое, если оно
присутствует, определяет один или несколько параметров дейтаграммы:
4- Безопасность. Позволяет присоединять к дейтаграмме метку безопасности.
♦ Маршрутизация от источника. Последовательный список адресов марш-
рутизаторов, составляющих маршрут, по которому должна следовать дей-
таграмма. Маршрутизация может быть строгой (при этом дейтаграмма
должна посещать только указанные маршрутизаторы) или свободной (дей-
таграмма может посещать также произвольные промежуточные маршру-
тизаторы).
♦ Запись маршрута. Адреса маршрутизаторов, через которые прошла дейта-
грамма, добавляются к полю заголовка дейтаграммы.
♦ Временной штамп. IP-сущность источника и некоторые или все промежу-
точные маршрутизаторы добавляют к пакету временной штамп (с точно-
стью до миллисекунды) при его прохождении.
3.4. Протокол IPv6
На протяжении десятилетий краеугольным камнем архитектуры протоколов
TCP/IP был протокол IPv4. В 1995 г. проблемная группа инженерной поддержки
Интернета (Internet Engineering Task Force, IETF) выпустила спецификацию
Для следующего поколения протокола IP, названного IPng (Internet Protocol, next
generation — Интернет-протокол нового поколения). В 1996 г. эта спецификация
была преобразована в стандарт, получивший название IPv6. По сравнению с суще-
ствующим протоколом IP, IPv6 предоставляет ряд функциональных усовершен-
84
Глава 3. Протоколы TCP и IP
ствований, разработанных для лучшего соответствия высоким скоростям совре-
менных сетей и смешанным потокам данных, включающим графику и видео, все
более превалирующим в настоящее время. Но главная причина создания новой
версии протокола заключалась в необходимости поддержания большего числа
адресов. В применяемом сегодня протоколе IP для обозначения отправителя и по-
лучателя пакета используется 32-разрядный адрес. При экспоненциальном росте
Интернета и частных сетей, соединенных с Интернетом, такая длина адресного
поля уже сейчас стала недостаточной, чтобы предоставить адреса всем системам,
которым нужно подключение к Интернету. Чтобы удовлетворить этим все расту-
щим требованиям, заголовок пакета формата IPv6 содержит 128-разрядные поля
адрсов отправителя и получателя.
Предполагается, что в конечном итоге все системы, использующие архитекту-
ру протоколов TCP/IP, перейдут с текущей версии протокола IP на IPv6, хотя этот
процесс может занять много лет, если не десятилетий.
В табл. 3.2 перечислены некоторые из ключевых документов, описывающих
протокол IPv6. В данном разделе мы рассмотрим эту версию протокола, делая осо-
бый упор на аспектах, относящихся к управлению трафиком.
Таблица 3.2. Некоторые рекомендации RFC для IPv6
RFC Название Дата
1752 Рекомендации для протокола IPng Январь 1995 г.
1809 Использование метки потока в IPv6 Июнь 1995 г.
1881 Управление предоставлением адресов в IPv6 Декабрь 1995 г.
1886 Расширения службы DNS для поддержания IPv6 Декабрь 1995 г.
1887 Архитектура для целевого распределения адресов IPv6 Декабрь 1995 г.
2373 Архитектура адресации IPv6 Июль 1998 г.
2460 Интернет-протокол, спецификация версии 6 Декабрь 1998 г.
2463 Спецификация протокола ICMP версии 6 для IPv6 Декабрь 1998 г.
2675 Джамбограммы протокола IPv6 Август 1999 г.
2711 Параметр предупреждений маршрутизатору IPv6 Октябрь 1999 г.
2893 Механизмы передачи для хостов и маршрутизаторов IPv6 Август 2000 г.
Форматы IPv6
Протокольный модуль данных IPv6 (называемый пакетом) имеет следующий
обобщенный вид:
<—40 байт -><------------ 0 ------------->
или больше
Заголовок IPv6 Заголовок расширения • • • Заголовок расширения Протокольный модуль данных транспортного уровня
Единственный необходимый заголовок называется просто заголовком IPv6.
Этот заголовок имеет фиксированный размер 40 байт, что вдвое превышает
3.4. Протокол IPv6
85
обязательную часть заголовка IPv4. Определены следующие заголовки расши-
рения:
♦ заголовок параметров ретрансляционных участков определяет специальные
параметры, требующие обработки на уровне ретрансляционных участков;
♦ заголовок маршрутизации обеспечивает расширенную маршрутизацию, сход-
ную с маршрутизацией от источника в IPv4;
4- заголовок фрагмента содержит информацию о фрагментации и повторной
сборке;
♦ заголовок аутентификации обеспечивает целостность и аутентификацию
пакета;
4 заголовок инкапсуляции защищенных данных обеспечивает секретность;
4- заголовок параметров получателя содержит дополнительную информацию
для узла получателя.
При применении нескольких заголовков расширения стандартом IPv6 реко-
мендовано использовать их в следующем порядке:
1. Заголовок IPv6 обязательный, он всегда должен быть первым.
2. Заголовок параметров ретрансляционных участков.
3. Заголовок параметров получателя для параметров, которые будут обра-
ботаны первым получателем, указанным в адресе получателя IPv6, а так-
же последующими получателями, перечисленными в заголовке маршру-
тизации.
4. Заголовок маршрутизации.
5. Заголовок фрагмента.
6. Заголовок аутентификации.
7. Заголовок инкапсуляции защищенных данных.
8. Заголовок параметров получателя для параметров, которые должен обрабо-
тать только конечный получатель пакета.
На рис. 3.4 показан пример пакета IPv6, содержащий по одному экземпляру
каждого заголовка. Обратите внимание на то, что заголовок IPv6 и каждый заголо-
вок расширения включают поле «Следующий заголовок» (кроме заголовка инкап-
суляции защищенных данных). Это поле идентифицирует тип заголовка, следую-
щего непосредственно за текущим. Если следующий заголовок является заголовком
расширения, тогда это поле содержит признак типа этого заголовка. В противном
случае это поле содержит идентификатор протокола верхнего уровня, использую-
щего протокол IPv6 (как правило, протокола транспортного уровня). В этом слу-
чае указываются те же значения, что и в протоколе IPv4. На рисунке протоколом
верхнего уровня является протокол TCP, поэтому данные верхнего уровня, пере-
носимые пакетом IPv6, состоят из заголовка TCP, за которым следует блок дан-
ных приложения.
Мы сначала рассмотрим основной заголовок IPv6, а затем по очереди изучим
все заголовки расширения.
86
Глава 3. Протоколы TCP и IP
Обязательный _
заголовок IPv6
г
Необязательные
заголовки <
расширения
Тело <
пакета IPv6
Заголовок IPv6
Заголовокпараметров
ретрансляционных участков
;; Заголовок маршрутизатора
Заголовок фрагмента
Заголовок параметров
получателя
Заголовок TCP
Прикладные данные
Байтов:
40
Переменная
Переменная
8
Переменная
20 (необязательная
переменная часть)
Поле следующего заголовка
Рис. 3.4. Пакет протокола IPv6 с заголовками расширения (содержащий сегмент TCP)
Заголовок IPv6
Заголовок IPv6 имеет фиксированную длину 40 байт и состоит из перечисленных
ниже полей (см. рис. 2.2 в главе 2):
4- Версия (4 бита). Номер версии протокола IP; значение равно 6.
4 Класс трафика (8 бит). Может быть использовано узлами-отправителями
и/или продвигающими данные маршрутизаторами для идентификации и
разделения разных классов или приоритетов пакетов IPv6. Вопрос исполь-
зования этого поля все еще изучается.
4 Метка потока (20 бит). Может быть использовано хостом для пометки па-
кетов, для которых запрашивается специальная обработка маршрутизато-
рами сети (подробнее см. ниже).
4 Полезная длина (16 бит). Длина остатка пакета IPv6, следующая за заголов-
ком, в байтах. Другими словами, зто суммарная длина всех заголовков рас-
ширения плюс модуль данных транспортного уровня.
4 Следующий заголовок (8 бит). Идентифицирует тип заголовка, следующе-
го непосредственно за заголовком IPv6; это может быть заголовок расши-
рения IPv6 или заголовок протокола более высокого уровня, например TCP
или UDP.
3.4. Протокол IPv6
87
+ Предел количества ретрансляционных участков (8 бит). Оставшееся число
допустимых ретрансляционных участков (хопов) для данного пакета. Пре-
дел количества ретрансляционных участков устанавливается отправителем
на некоторое желаемое максимальное значение и уменьшается на единицу
на каждом узле, ретранслирующем пакет. Если значение этого поля дости-
гает нуля, пакет отбрасывается. Этот алгоритм представляет собой упрощен-
ный вариант алгоритма учета времени жизни пакета, как это предполагалось
в IPv4. По общему мнению, дополнительные усилия по подсчету интер-
валов времени не влияют существенно на протокол. В действительности,
большинство маршрутизаторов IPv4 обрабатывают поле времени жизни как
обычный счетчик ретрансляционных участков.
♦ Адрес источника (128 бит). Адрес отправителя пакета.
♦ Адрес приемника (128 бит). Адрес предполагаемого получателя пакета. Как
будет показано далее, при наличии заголовка маршрутизации этот адрес не
обязательно означает последнего получателя пакета.
Хотя заголовок IPv6 длиннее, чем обязательная часть заголовка IPv4 (40 байт
против 20 байт), он содержит меньшее количество полей (8 вместо 12). Таким об-
разом, маршрутизаторы тратят меньше времени на обработку заголовка, что уско-
ряет процесс маршрутизации.
Класс трафика
8-битовое поле класса трафика позволяет источнику указать желаемые характерис-
тики трафика каждого пакета относительно других пакетов от того же источника.
Назначение этого поля — поддержка различных форм дифференцированного обслу-
живания, обсуждаемого в главе 17. На момент написания книги использование
этого поля не было определено, а рекомендации имеются в документе RFC 2460:
♦ Служебный интерфейс протокола IPv6 должен позволять протоколам бо-
лее высокого уровня устанавливать значение поля класса трафика.
♦ Узлам, поддерживающим особое использование поля класса трафика, раз-
решается изменять значение тех битов в пакетах, которые они отправляют,
ретранслируют или получают, как это необходимо для данного варианта
использования.
4- Протокол верхнего уровня не должен предполагать, что значение битов поля
класса трафика в полученном пакете совпадает со значением, установлен-
ным в этом поле отправителем пакета.
Метка потока
Стандартом IPv6 поток определяется как последовательность пакетов, отправлен-
ных одним источником одному (или нескольким в случае целевой или групповой
рассылки) получателю, для которой отправителю требуется специальная обработ-
ка промежуточными маршрутизаторами. Поток однозначно идентифицируется
комбинацией адреса отправителя, адреса получателя и ненулевой 20-разряднои
меткой потока. Таким образом, всем пакетам, которые должны быть частью одно-
го и того же потока, отправителем присваивается одна и та же метка потока.
88
Глава 3. Протоколы TCP и IP
С точки зрения отправителя поток, как правило, представляет собой последо-
вательность пакетов, которые формируются одним экземпляром приложения, ра-
ботающего на компьютере отправителя, и у которых имеются одинаковые требо-
вания к службе связи. Поток может обслуживаться одним TCP-соединением или
даже несколькими TCP-соединениями. Пример второго варианта — приложение
передачи файлов, у которого может быть одно управляющее соединение и несколь-
ко соединений для данных. Одно приложение может сформировать один поток
или несколько потоков, как, например, мультимедийная конференция, у которой
может быть один поток для звука и один для графики, у каждого из которых могут
быть различные требования, касающиеся скорости передачи данных, задержки и
изменения значения задержки.
С точки зрения маршрутизатора поток представляет собой последовательность
пакетов с общими атрибутами, влияющими на то, как пакеты будут обрабатывать-
ся маршрутизатором. Эти атрибуты включают путь, распределение ресурсов,
данные, влияющие на решение о том, какой пакет будет отвергнут в случае пере-
грузки маршрутизатора, атрибуты учета и безопасности. Маршрутизатор может
по-разному обрабатывать пакеты из разных потоков, например выделять для них
буферы разного размера, давая различный приоритет при ретрансляции и запра-
шивая у сетей различные уровни качества обслуживания.
Сами значения меток потока не имеют особого смысла. Напротив, специальная
обработка, предоставляемая потоку пакетов, должна декларироваться каким-то
другим способом. Например, источник может потребовать специального обслужи-
вания или вступить в переговоры на эту тему при помощи управляющего протоко-
ла заблаговременно или непосредственно во время передачи, указав необходимую
для этого информацию в одном из заголовков расширения пакета, например заголов-
ке параметров ретрансляционных участков. Примеры специального обслуживания,
которое можно запросить, включают некоторые, не предоставляемые по умолчанию
классы качества обслуживания или некоторые виды служб реального времени.
В принципе, все требования пользователя, касающиеся определенного потока,
могут быть определены в заголовке расширения и включены в каждый пакет. Если
мы хотим оставить понятие потока открытым, чтобы оно могло передать широкий
спектр требований, размер заголовка пакета может стать очень большим. Альтер-
нативный подход, принятый в протоколе IPv6, заключается в метке потока, в ко-
торой требования для потока определяются до начала передачи пакетов, а потоку
присваивается уникальная метка потока. В этом случае маршрутизатор должен
хранить информацию о требованиях для каждого потока.
К метке потока применимы следующие правила:
4- Хосты или маршрутизаторы, не поддерживающие поля метки потока, долж-
ны устанавливать значение этого ноля в отправляемых ими пакетах рав-
ным нулю, оставлять это поле неизменным при ретрансляции чужого паке-
та и игнорировать это поле, получая пакет.
4- У всех пакетов, отправляемых одним и тем же источником с одинаковым
ненулевым значением поля метки потока, должно быть одинаковое содер-
жимое полей адресов отправителя и получателя, заголовка параметров ре-
трансляционных участков (если этот заголовок присутствует) и заголовка
маршрутизации (если этот заголовок присутствует). Делается это для того,
3.4. Протокол IPv6
89
чтобы маршрутизатор мог решать, как обрабатывать пакет просто по метке
потока пакета, находя ее в своей таблице и не просматривая остальную ин-
формацию в заголовке.
♦ Источник назначает потоку метку потока. Новые метки потока должны
выбираться (псевдо-) случайным образом равномерно в диапазоне от 1
до 220 - 1. Кроме того, источник не должен повторно использовать пре-
жнюю метку для нового потока, пока не истекло время жизни потока с этой
меткой. Нулевое значение метки потока означает, что она не используется.
Последний пункт требует некоторого уточнения. По-видимому, маршрутиза-
тор должен хранить информацию о характеристиках каждого активного потока,
который может проходить через него, в некоторой таблице. Чтобы маршрутизатор
мог быстро ретранслировать пакеты, поиск в таблице должен быть эффективным.
Один из вариантов заключается в том, чтобы иметь таблицу с 220 (около одного
миллиона) записей, по одной для каждого возможного значения метки потока. При
таком варианте маршрутизатору требуется очень большой объем памяти. Другой
подход состоит в том, чтобы хранить в таблице информацию только об активных
потоках, хранить саму метку потока в записи таблицы и искать эту метку в табли-
це при каждом прибытии пакета. При таком подходе потребуются дополнитель-
ные затраты времени на поиск метки потока в таблице. В большинстве современ-
ных маршрутизаторов используется метод хэширования. При этом достаточно
таблицы умеренного размера, а каждое значение метки потока отображается на
таблицу при помощи хэш-функции. Эта функция может просто маскировать млад-
шие разряды метки потока (например, 8 или 10 бит) или выполнять некоторую
несложную операцию с 20 разрядами метки потока. В любом случае эффектив-
ность метода хэширования, как правило, зависит от равномерности распределения
значений меток потоков в их диапазоне. Отсюда последнее требование в приве-
денном выше списке.
Адреса IPv6
Адреса IPv6 имеют размер 128 бит. Адреса назначаются отдельным интерфей-
сам узлов, но не самим узлам1. У одного интерфейса может быть несколько уни-
кальных адресов для целевой передачи. Любой такой адрес, ассоциированный
с интерфейсом узла, может быть использован для уникальной идентификации
этого узла.
Комбинация длинных адресов и возможности иметь несколько адресов для од-
ного интерфейса обеспечивает более высокую эффективность маршрутизации по
сравнению с протоколом IPv4. В протоколе IPv4 адреса, как правило, не обладают
структурой, помогающей маршрутизации, и поэтому маршрутизатору может по-
требоваться огромная таблица для хранения путей. Более длинные межсетевые
адреса позволяют объединять адреса по сетевым иерархиям, поставщикам услуг,
географическому расположению, корпорациям и т. д. Благодаря этому можно ис-
пользовать таблицы маршрутизации меньшего размера и ускорить процедуру по-
иска в таблице. Возможность назначать несколько адресов одному интерфейсу
1 В протоколе IPv6 узлом (node) называется любое устройство, реализующее протокол IPv6; узлами
являются хосты и маршрутизаторы.
90
Глава 3. Протоколы TCP и IP
позволяет подписчику, пользующемуся услугами нескольких поставщиков с одним
и тем же интерфейсом, иметь для каждого адресного пространства поставщика
отдельные адреса.
Протокол IPv6 позволяет использовать три типа адресов:
4 Целевая рассылка (unicasting). Адрес целевой рассылки — это идентифика-
тор одного интерфейса. Пакет, посланный по такому адресу, доставляется
конкретному интерфейсу, идентифицированному этим адресом.
4- Выборочная рассылка (anycasting). Адрес выборочной рассылки — это иден-
тификатор группы интерфейсов (как правило, принадлежащих разным
узлам). Пакет, отправленный по такому адресу, доставляется одному из
интерфейсов, с которым связан этот адрес («ближайшему» интерфейсу,
в единицах измерения протокола маршрутизации).
4 Групповая рассылка (multicasting). Адрес групповой рассылки — это иден-
тификатор группы интерфейсов (как правило, принадлежащих разным
узлам). Пакет, отправленный по такому адресу, доставляется всем интер-
фейсам, с которым связан этот адрес.
Заголовок параметров ретрансляционных
участков
Заголовок параметров ретрансляционных участков (хопов) содержит необязатель-
ную информацию, которая, если она присутствует, должна исследоваться каждым
маршрутизатором на пути следования пакета. Этот заголовок состоит из перечис-
ленных ниже полей (рис. 3.5, а):
4 Следующий заголовок (8 бит). Идентифицирует тип заголовка, следующего
непосредственно после данного заголовка.
4 Длина заголовка расширения (8 бит). Длина данного заголовка в 64-битовых
единицах, не считая первых 64 бит.
4 Параметры. Поле переменной длины, состоящее из одного или нескольких
определений. Каждое определение состоит из трех полей:
♦ Тип параметра (8 бит) — идентифицирует параметр;
♦ Длина (8 бит) — длина поля данных параметра в байтах;
+ Данные параметра (переменной длины) — сам параметр.
Для описания параметра используются пять младших разрядов. Два старших
бита указывают, какое действие должен предпринять узел, не распознающий дан-
ный тип параметра:
4 00 — пропустить этот параметр и продолжить обработку заголовка;
4 01 — отбросить пакет;
4 10 — отбросить пакет и послать отправителю пакета сообщение о нераспоз-
наваемом типе параметра по протоколу ICMP (Internet Control Message
Protocol — протокол управления сообщениями в объединенных сетях);
3.4. Протокол IPv6
91
♦ 11 — отбросить пакет и послать отправителю пакета сообщение о нераспоз-
наваемом типе параметра по протоколу ICMP, только если адрес получате-
ля не является адресом групповой рассылки.
о
^йедующий. ;
‘ заголовок -•
Длина заголовка
расширения
Один или несколько параметров
О
29 31
Следующий Т' 1 >цгаповок^ * Резерв Смещение фрагмента м Резерв
Идентис эикатор
31
Длина заголовка расширения Тип маршрутизации Остаток сегментов
Данные, специфические для указанного типа
0 6 16 24 31
: ;Слёдующий’; . 'ч ® заголовок 11 Длина заголовка расширения 0 Остаток сегментов
Резерв
Адрес (1)
Адрес (2)
• •
• •
• •
Адрес (л)
Рис. 3.5. Заголовки расширения протокола IPv6
92
Глава 3. Протоколы TCP и IP
Третий по старшинству бит указывает, является ли поле данных параметра не-
изменным (0) или может изменяться (1) на пути от отправителя к получателю.
Данные, способные изменяться, должны быть исключены из вычислений для
аутентификации.
Эти соглашения для поля типа параметра также применимы к заголовку пара-
метров получателя.
К настоящему времени определено два параметра ретрансляционных участков:
параметр Джамбо (Jumbo) и параметр предупреждений маршрутизатору. Пара-
метр Джамбо используется для пересылки пакетов IPv6 с полезной нагрузкой, раз-
мер которой превышает 65 535 байт. Поле данных этого параметра имеет размер
32 бита и хранит длину пакета в байтах, включая заголовок IPv6. Для таких паке-
тов поле полезной длины в заголовке IPv6 должно быть установлено в ноль и не
должно быть заголовком фрагмента. Таким образом, протокол IPv6 поддерживает
пакеты размером до 4 Гбайт, что упрощает пересылку больших видеопакетов и
позволяет протоколу IPv6 оптимально использовать доступную для данного ка-
нала пропускную способность.
Параметр предупреждений маршрутизатору, если он присутствует, инфор-
мирует маршрутизатор о том, что содержимое пакета представляет интерес для
самого маршрутизатора. Если дейтаграмма IPv6 не содержит этого параметра, зто
означает, что пакет не содержит информации, интересной для маршрутизатора,
и поэтому данный пакет можно переслать дальше без дополнительной обработки.
Хосты, отправляющие пакеты IPv6, должны включать этот параметр в определен-
ных обстоятельствах. Этот параметр предназначен для эффективной поддержки
таких протоколов, как RSVP (Resource reSerVation Protocol — протокол резерви-
рования ресурсов), который будет обсуждаться в главе 17. Такие протоколы фор-
мируют пакеты, контролируемые промежуточными маршрутизаторами в целях
регулирования трафика. Параметр предупреждений маршрутизатору сразу обра-
щает внимание маршрутизатора на пакет, поэтому ему не нужно тщательно про-
верять заголовки расширения.
Заголовок фрагмента
В протоколе IPv6 фрагментация может производиться только узлами-источни-
ками, но не маршрутизаторами по пути следования пакета. Чтобы использовать
все преимущества объединенной сети, узел должен реализовать алгоритм обнару-
жения пути, позволяющий ему узнать минимальный размер максимальной еди-
ницы передачи (Maximum Transmission Unit, MTU), поддерживаемой всеми под-
сетями па этом пути. Другими словами, алгоритм обнаружения пути позволяет
узлу узнать размер максимальной единицы передачи подсети, представляющей
собой «узкое место» данного маршрута. Зная этот размер, узел-источник фрагмен-
тирует, как требуется, пакеты для каждого получателя. Если такая информация
почему-либо недоступна, отправитель должен ограничить размер всех пакетов
размером 576 байт, что представляет собой минимальный размер максимальной
единицы передачи, который должны поддерживать все подсети.
3.4. Протокол IPv6
93
Ниже перечислены поля заголовка фрагмента (см. рис. 3.5, б):
+ Следующий заголовок (8 бит). Идентифицирует тип заголовка, следующего
непосредственно после этого заголовка.
+ Резерв (8 бит). Зарезервировано на будущее.
4- Смещение фрагмента (13 бит). Указывает, к какой части исходного пакета
принадлежит полезная нагрузка этого фрагмента. Она измеряется в едини-
цах по 64 бита. Это означает, что длина всех фрагментов в байтах, кроме дли-
ны последнего фрагмента, должна быть кратна 8.
4- Резерв (2 бита). Зарезервировано на будущее.
4- Флаг Л/ (1 бит). Если этот флаг равен 1 — есть еще фрагменты, если 0 — это
последний фрагмент.
4 Идентификатор (32 бита). Предназначен для уникальной идентификации
исходного пакета. Идентификатор должен быть уникальным для адреса
отправителя, адреса получателя и протокола пользователя на то время, в те-
чение которого дейтаграмма будет находиться в объединенной сети. Все
фрагменты с одинаковыми идентификатором, адресом отправителя и адре-
сом получателя собираются вместе, чтобы сформировать исходный пакет.
Заголовок маршрутизации
Заголовок маршрутизации содержит список из одного пли нескольких промежу-
точных узлов, которые пакет должен посетить на пути к пункту назначения. Все
заголовки маршрутизации начинаются с 32-битового блока, состоящего из четы-
рех 8-битовых полей, за которыми следуют данные маршрутизации, специфиче-
ские для данного типа маршрутизации (см. рис. 3.5, в):
4 Следующий заголовок. Идентифицирует тип заголовка, следующего непо-
средственно после данного заголовка.
4 Длина заголовка расширения. Длина данного заголовка в 64-битовых едини-
цах, не считая первых 64 бит.
4 Тип маршрутизации. Идентифицирует вариант заголовка маршрутизации.
Если маршрутизатор не распознает значение этого поля, он должен отбро-
сить пакет.
4- Остаток сегментов. Количество оставшихся сегментов маршрута; то есть
число явно указанных промежуточных узлов, которые пакет должен посе-
тить, прежде чем отправиться к конечному получателю.
Стандартом RFC 2460 определен единственный вариант формата заголовка
маршрутизации — заголовок маршрутизации типа 0 (см. рис. 3.5, г). При исполь-
зовании заголовка маршрутизации типа 0 узел-источник не помещает адрес ко-
нечного получателя в заголовок IPv6. Вместо этого он помещается в конец списка
адресов, перечисленных в заголовке маршрутизации (адрес (п) на рис. 3.5, г), а за-
головок IPv6 содержит адрес получателя первого маршрутизатора на этом пути.
Заголовок маршрутизации не исследуется до тех пор, пока пакет не достигнет узла,
94
Глава 3. Протоколы TCP и IP
указанного в заголовке IPv6. В этот момент содержимое заголовка IPv6 и заголов-
ка маршрутизации обновляется, после чего пакет направляется дальше. Обновле-
ние заключается в помещении в заголовок IPv6 нового адреса, который следует
посетить, и уменьшении па единицу поля «Остаток сегментов» в заголовке мар-
шрутизации.
Заголовок параметров получателя
Заголовок параметров получателя содержит необязательную информацию, которая,
если она присутствует, исследуется только получателем пакета. Формат этого за-
головка совпадает с форматом заголовка параметров ретрансляционных участков
(см. рис. 3.5, а).
3.5. Рекомендуемые литература и веб-сайты
В [120] имеется детальное обсуждение механизмов и служб транспортного прото-
кола, а [ 117] представляет собой непосредственное техническое описание различных
рекомендаций RFC, составляющих спецификацию протокола IPv6. Здесь обсуж-
даются различные особенности протоколам его функционирование. Книга [152]
в большей степени посвящена практическим вопросам реализации протокола IPv6.
Ниже перечислены рекомендуемые веб-сайты:
4 IPng. Информация о протоколе IPv6 и т. п.
4- IPv6 Information Page. На этом веб-сайте содержатся вводный материал, но-
вости о недавних разработках, касающихся протокола IPv6, а также соот-
ветствующие ссылки.
4- IPv6 Forum. Сайт промышленного консорциума, занимающегося продвиже-
нием 1Р\'6-продуктов. Содержит множество документов и статей.
3.6. Задания
1. В большинстве транспортных протоколов (на самом деле в большинстве
протоколов всех уровней), как правило, управляющая информация и дан-
ные передаются по одному и тому же логическому каналу. Альтернативный
вариант заключается в создании одного управляющего транспортного со-
единения между каждой парой транспортных сущностей. Это соединение
будет использоваться для передачи сигналов, относящихся ко всем пользо-
вательским транспортным соединениям между двумя сущностями. Обсуди-
те результат применения этой стратегии.
2. Зачем нужен протокол UDP? Почему программа пользователя не может
напрямую обратиться к протоколу IP?
3. Значения полей «Идентификатор» и «Время жизни», а также флага DF
(отсутствие фрагментации), как правило, задаются пользователем прото-
3.6. Задания
95
кола IP, переносятся в IP-дейтаграмме через объединенную сеть к получа-
ющей IP-сушности, но не доставляются получающему пользователю IP, так
как они интересуют только сам протокол IP. Для каждого из этих значений
укажите, интересует оно IP-сущность источника, IP-сущности промежуточ-
ных маршрутизаторов или IP-сущность получающей системы. Обоснуйте
свои ответы.
4. Укажите достоинства и недостатки промежуточного восстановления фрагмен-
тированных дейтаграмм по сравнению со сборкой конечным получателем?
5. Чему равны накладные расходы на заголовок протокола IP?
6. При каких обстоятельствах может потребоваться использовать маршрути-
зацию от источника вместо того, чтобы предоставить маршрутизаторам воз-
можность самим принимать решения?
7. Благодаря фрагментации IP-дейтаграмма может прибыть по частям, не обя-
зательно в правильном порядке. IP-сущность принимающей оконечной си-
стемы должна хранить эти фрагменты, пока не будет восстановлена исход-
ная дейтаграмма.
а) представьте, что IP-сущность создает буфер для сборки поля данных
оригинальной дейтаграммы. В процессе сборки буфер будет содержать
блоки данных и «дыры» между ними. Опишите алгоритм сборки, осно-
ванный на этой концепции;
б) алгоритм пункта а должен контролировать «дыры». Опишите простой
механизм для этого.
8. Следует передать 4480-байтовую дейтаграмму. Она должна быть фрагмен-
тирована, так как ей предстоит преодолеть сеть Ethernet, максимальный раз-
мер полезной нагрузки в которой равен 1500 байт. Укажите значения полей
«Полная длина», «Смещение фрагмента» и флага More (признак наличия
дополнительных фрагментов) для каждого из получающихся в результате
фрагментов.
9. Контрольную сумму IP приходится рассчитывать заново на каждом марш-
рутизаторе, так как IP-заголовок (например, поле времени жизни) постоян-
но меняется. Имеется возможность пересчитать контрольную сумму полно-
стью. Предложите процедуру, требующую меньше вычислений. Считайте,
что значение А-го байта изменяется па величину (скажем, Z), равную ново-
му значению за вычетом прежнего значения. Рассмотрите влияние этого
изменения на контрольную сумму.
10. Требуется фрагментировать IP-дейтаграмму. Какие параметры в поле пара-
метров следует скопировать в заголовок каждого фрагмента, а какие долж-
ны быть помещены только в первый фрагмент? Обоснуйте свой ответ для
каждого параметра.
И. Сообщение транспортного уровня, состоящее из 1500 бит данных и 160 бит
заголовка, посылается межсетевому уровню, добавляющему еще 160 бит
заголовка. Затем это сообщение отправляется через две сети, каждая из
96 Глава 3. Протоколы TCP и IP
которых использует 24-битовый заголовок пакета. Максимальный размер
пакета в сети получателя равен 800 бит. Сколько битов, включая заголовки,
доставляется протоколу сетевого уровня получателя?
12. Сравните соответствующие поля заголовков IPv4 и IPv6. Опишите функ-
циональность, предоставляемую каждым полем IPv4, показывая, как обес-
печивается та же функциональность в IPv6.
13. Объясните рекомендованный порядок, в котором должны появляться заго-
ловки расширения IPv6 (то есть почему заголовок параметров ретрансля-
ционных участков должен идти первым, а заголовок маршрутизации нахо-
диться перед заголовком фрагментов и т. д.).
Часть II
Высокоскоростные сети
Оригинальная экспериментальная сеть Ethernet работала на скорости 3 Мбит/с.
Вскоре после того, как сеть Ethernet вышла на рынок, был разработан вариант этой
сети под названием StarNet, который работал на скорости 1 Мбит/с, передавая
данные по витой паре. Также существовало несколько других мегабитных локаль-
ных сетей, использующих витую пару. Популярным конкурентом сети Ethernet
была сеть с топологией маркерного кольца (token ring), работавшая на скоростях
1 Мбит/с и 4 Мбит/с. В мире глобальных сетей между узлами с коммутацией па-
кетов когда-то вполне обычной была скорость передачи данных 56 Кбит/с. Сегод-
ня такие скорости считаются устаревшими и неэффективными.
Ряд факторов, включая увеличение мощности настольных компьютеров, боль-
шую популярность графических приложений и простоту доступа к мультиме-
дийному содержанию, требуют сетей с все большей и большей пропускной спо-
собностью. Эти требования проявляются как на уровне локальных сетей, которые
вынуждены поддерживать все большее число персональных компьютеров и рабо-
чих станций, а также обеспечивать возрастающую зависимость от серверов, так и
на уровне глобальных сетей, которым приходится обслуживать выросший корпо-
ративный и частный трафик в разнообразных сетевых конфигурациях. Часть II
призвана подвести итоги теме технологий высокоскоростных сетей.
♦ Глава 4. Ретрансляция кадров. Глава 4 начинается с обзора темы коммута-
ции пакетов, представляющей собой одно из наиболее важных нововве-
дений в сфере сетевых коммуникаций. Сохраняющие свою актуальность
основные концепции технологии коммутации пакетов находят применение
в таких компьютерных сетях, как сети ретрансляции кадров и ATM, а также
в Интернете. После этого вступления в оставшейся части главы описывает-
ся ретрансляция кадров, наиболее широко применяемая технология высо-
коскоростных сетей. Ретрансляция кадров предоставляет более эффектив-
ные средства поддержания традиционных методов коммутации пакетов,
основанных на прежнем стандарте Х.25. В этой главе рассматриваются про-
токол передачи данных и протокол управления для ретрансляции кадров.
♦ Глава 5. Сети ATM. Хотя по историческим причинам технология ретранс-
ляции кадров применяется гораздо шире, чем ATM, в будущем доминирую-
щей сетевой технологией для высокоскоростных глобальных сетей, скорее
всего, станет ATM. Глава 5 начинается с описания ключевых элементов тех-
нологии ATM, включая ее архитектуру протоколов, логические соединения
98
Часть II. Высокоскоростные сети
и структуру ячеек. Затем мы опишем типы служб, предоставляемых ATM.
Наконец, мы рассмотрим важный уровень адаптации ATM, с помощью кото-
рого протоколы высокого уровня отображаются на ATM.
4- Глава 6. Высокоскоростные локальные сети. Высокоскоростные локаль-
ные сети стали критически важным элементом корпоративных информа-
ционных систем. Такие сети нужны не только для того, чтобы служить ме-
стной резервной магистралью для объединения локальных сетей отделов,
но также для поддержания требований по увеличению производительности
графических приложений клиент-сервер и интранет-приложений.
Для большинства приложений в мире высокоскоростных локальных сетей
доминируют технологии Fast Ethernet (быстрая сеть Ethernet) и Gigabit
Ethernet (гигабитная сеть Ethernet). Эти системы по ряду причин, среди
которых проработанность лежащей в основе технологии и совместимость
с существующим программным обеспечением сетевого управления, предла-
гают менеджерам минимальные риск и издержки.
После обзора приложений, давших толчок развитию высокоскоростных
локальных сетей, в главе 6 обсуждаются технология Ethernet и ее варианты,
доступные на сегодняшний день. Также рассматриваются две других тех-
нологии высокоскоростных локальных сетей, пользующихся достаточной
популярностью. Технология Fibre Channel (волоконно-оптический канал)
представляет собой технологию коммутируемой сети, широко применяемую
в архитектуре SAN и других приложениях распределенных баз данных. Бес-
проводные локальные сети, основанные на стандарте IEEE 802.11, также
становятся все более популярными как дополнение к системам Ethernet.
Глава 4
Ретрансляция кадров
На станции Уимблдон Парк он сел в поезд, идущий по
линии Дистрикт, пересел на линию Виктория на стан-
ции Виктория, а затем на линию Джубили на станции
Грин Парк, направившись в сторону Уэст Хампстед.
Это было долгое и утомительное путешествие, но оно
ему нравилось.
Барбара Байн (Рут Ренделл). Ковер царя Соломона
Опубликованные в 1988 г. рекомендации 1.122, озаглавленные «Структура для
предоставления дополнительных служб канала, работающего в пакетном режиме»,
определили новую форму передачи пакетов, ставшую одним из самых значимых
вкладов в дело разработки узкополосной сети ISDN. Сейчас эта новая технология
обычно называется службой поддержания режима передачи кадров (frame-mode
bearer service), ретрансляцией кадров (frame relay). Первый термин выдвигает
на первый план службу, предоставляемую пользователю, тогда как второй обра-
щает внимание на протокол, реализующий данную службу. Несмотря на рост
популярности технологии ATM ретрансляция кадров остается, возможно, самой
популярной технологией глобальных сетей.
В данной главе предоставляется обзор некоторых основных принципов компь-
ютерных сетей. Глава начинается с описания сетей с коммутацией пакетов, знако-
мя читателя с фундаментальными понятиями дейтаграмм и виртуальных каналов,
а также с освещения стандарта интерфейса коммутации каналов Х.25. Затем мы
рассмотрим сети с ретрансляцией кадров, в которых используется упрощенный
механизм коммутации пакетов.
4.1. Сети с коммутацией пакетов
Около 1970 г. были начаты исследования в области новых форм архитектуры для
передачи цифровых данных на большие расстояния: коммутации пакетов. Хотя
с тех пор технология коммутации пакетов существенно эволюционировала, заме-
чательно, что, во-первых, эта технология в своей основе остается той же, что и в нача-
ле 70-х, и, во-вторых, коммутация пакетов остается одной из немногих эффек-
тивных технологий передачи данных на большие расстояния. Две более поздние
100
Глава 4. Ретрансляция кадров
технологии глобальных сетей, ретрансляция кадров и ATM, представляют собой,
по существу, вариации основного метода коммутации каналов. Кроме того, техно-
логия коммутации каналов также лежит в основе работы Интернета, маршру-
тизаторы и подсети которого аналогичны узлам коммутации пакетов и каналам
связи между узлами в сети с коммутацией пакетов. В этой главе предоставляется
обзор оригинальной, но все еще широко распространенной схемы коммутации
пакетов, а также схемы ретрансляции кадров. Технология ATM обсуждается в сле-
дующей главе.
Технология коммутации пакетов обладает многими достоинствами (такими как
гибкость, совместное использование ресурсов, устойчивость, оперативность). Но
ничто не дается даром. Сеть с коммутацией пакетов представляет собой распреде-
ленный набор узлов коммутации пакетов. В идеале всем узлам коммутации паке-
тов известно состояние всей сети. Однако поскольку узлы распределенные, всегда
есть временная задержка между изменением состояния одной части сети и распро-
странением информации об этом по остальной сети. Более того, передача инфор-
мации о состоянии создает дополнительную нагрузку на сеть. В результате произ-
водительность сети с коммутацией пакетов никогда не может достичь «оптимума»,
и для того чтобы справиться с временной задержкой и накладными расходами,
применяются сложные алгоритмы. Те же алгоритмы применяются в Интернете.
Базовые операции
Протяженные компьютерные сети с коммутацией каналов изначально создавались
для поддержания голосового трафика (телефонных разговоров), и большая часть
трафика, передаваемого по этим сетям, остается голосовой. Ключевое свойство
сетей с коммутацией каналов заключается в том, что ресурсы сети выделяются со-
единению. При передаче голоса коэффициент использования канала достаточ-
но высок, так как большую часть времени один из участников телефонного разго-
вора говорит. Однако когда сети с коммутацией каналов стали применяться для
передачи цифровых данных, очевидными стали два недостатка:
4- При типичном соединении хост—терминал большую часть времени линия
простаивает. Таким образом, для передачи данных метод коммутации кана-
лов оказывается неэффективным.
♦ В сети с коммутацией каналов соединение обеспечивает передачу данных с
постоянной скоростью. Таким образом, каждое из пары соединенных уст-
ройств должно передавать и принимать данные с одинаковой скоростью. Это
ограничивает возможность использования сети для соединения разнотип-
ных хостов и терминалов.
При коммутации пакетов данные передаются в виде коротких блоков, называе-
мых пакетами. Как правило, размер пакетов не превышает 1000 байт. Если отпра-
вителю требуется передать сообщение большего размера, оно разбивается на не-
сколько пакетов (рис. 4.1). В каждый пакет помещается часть данных пользователя
(или все сообщение, если оно короткое), а также некоторая управляющая инфор-
мация. Управляющая информация содержит, как минимум, данные, необходимые
для того, чтобы сеть смогла доставить пакеты получателю. На каждом узле по пути
4.1. Сети с коммутацией пакетов
101
следования пакет принимается, хранится короткое время, после чего передается
следующему узлу.
Рис. 4.1. Использование пакетов
Рисунок 4.2 призван проиллюстрировать основную операцию. Передающий
компьютер или другое устройство посылает сообщение в виде последовательно-
сти пакетов (рис. 4.2, а). Каждый пакет включает в себя управляющую инфор-
мацию, идентифицирующую станцию назначения (компьютер, терминал и т. д.).
Вначале пакеты посылаются узлу, к которому присоединена станция-источник.
Этот узел в течение короткого времени хранит прибывающие пакеты, опреде-
ляет следующую ветвь маршрута и ставит пакет в очередь на данную исходящую
линию связи. Когда линия освобождается, пакет передается следующему узлу
(рис. 4.2, 6). В конце концов все пакеты доставляются предполагаемому получате-
лю (рис. 4.2, в, г и д').
На рис. 4.3 показана простая сеть с коммутацией пакетов. Рассмотрим пакет,
который следует передать со станции А на станцию Е. В пакет включается управ-
ляющая информация, указывающая, что получателем является станция Е. Пакет
отправляется со станции А на узел 4. Узел 4 сохраняет пакет, определяет следую-
щую ветвь маршрута (например, 5) и устанавливает пакет в очередь на данную
исходящую линию связи (линия 4-5). Когда линия освобождается, паке! переда-
ется узлу 5, который затем передает пакет узлу 6, и, наконец, станции Е. Этот под-
ход обладает рядом преимуществ по сравнению с коммутацией каналов:
♦ Эффективность использования линии выше, так как одна линия связи мо-
жет совместно использоваться для передачи нескольких пакетов. Пакеты
устанавливаются в очередь и передаются по линии максимально быстро.
При коммутации каналов, напротив, время использования линий, связыва-
ющих узлы, резервируется путем синхронного мультиплексирования с раз-
делением времени. Большую часть времени такая линия может простаивать,
так как может оказаться предоставленной соединению, по которому в дан-
ный момент не передаются данные.
♦ Сеть с коммутацией пакетов может адаптировать скорости передачи данных.
Две станции с различными скоростями передачи данных могут обменивать-
ся пакетами, так как каждая станция соединяется со своим узлом на подхо-
дящей скорости.
102 Глава 4. Ретрансляция кадров
Рис. 4.2. Коммутация пакетов: метод дейтаграмм
♦ Когда в сети с коммутацией каналов трафик становится слишком напряжен-
ным, некоторые соединения могут оказаться блокированными. То есть сеть
будет отказываться устанавливать новые соединения до тех пор, пока нагруз-
ка на нее не уменьшится. Сеть с коммутацией пакетов продолжает принимать
пакеты даже в случае перегрузки, но время доставки пакетов возрастает.
4.1. Сети с коммутацией пакетов
103
4 В сети с коммутацией пакетов может использоваться механизм приоритетов.
То есть если у узла есть несколько пакетов, стоящих в очереди на передачу,
он может передать первыми пакеты с наивысшим приоритетом. Эти пакеты
будут доставлены с меньшей задержкой, чем низкоприоритетные пакеты.
Рис. 4.3. Простая сеть с коммутацией пакетов
По сравнению с коммутацией каналов коммутация пакетов имеет не только
достоинства, но и недостатки:
4 Каждый узел сети с коммутацией пакетов увеличивает задержку в доставке
пакета, отсутствующую при коммутации каналов. Как минимум, эта задерж-
ка равна длине пакета в битах, деленной на скорость принимающего канала
узла. Это время требуется, чтобы принять пакет во внутренний буфер узла.
Кроме того, задержка переменной величины может быть связана с обработ-
кой и нахождением в очереди.
4 Поскольку пакеты, пересылаемые между данными отправителем и получа-
телем, могут различаться по длине, доставляться различными маршрутами
и подвергаться разным задержкам в коммутаторах, суммарное время задер-
жки доставки пакета может существенно варьироваться. Этот феномен, на-
зываемый флуктуацией (jitter), может быть нежелателен в некоторых при-
ложениях, например в приложениях реального времени, включая цифровую
телефонную связь и видео реального времени.
104
Глава 4. Ретрансляция кадров
♦ Для доставки пакета получателю к каждому пакету необходимо добавлять
служебную информацию, включающую адрес получателя, а часто и поряд-
ковые номера пакетов. Эти накладные расходы снижают пропускную спо-
собность, доступную для передачи данных пользователя. Все это не нужно
при коммутации каналов, после того как канал связи установлен.
При передаче информации методом коммутации пакетов на каждом узле
требуется выполнить больший объем работы, чем при коммутации каналов.
В случае коммутации каналов после того, как канал связи установлен, на
промежуточных коммутаторах практически не требуется никакой обработ-
ки данных.
Техника коммутации
У станции есть сообщение для отправки по сети с коммутацией пакетов, и размер
этого сообщения превосходит максимальный размер пакета для данной сети. По-
этому станция разбивает сообщение на пакеты и посылает их по одному в сеть.
В результате возникает вопрос: как сеть будет обрабатывать данный поток паке-
тов, чтобы направить их нужному получателю. В современных сетях применяется
два подхода: дейтаграммы и виртуальный канал.
В случае дейтаграмм каждый пакет обрабатывается независимо, без связи с па-
кетами, отправленными ранее. Такой подход проиллюстрирован на рис. 4.2. Каж-
дый узел выбирает следующий узел пути пакета, принимая во внимание инфор-
мацию, полученную от соседних узлов, состояние линий и т. д. Поэтому пакеты
с одинаковыми адресами получателя не следуют по одному и тому же маршруту
(см. рис. 4.2, в) и могут прийти к получателю в произвольном порядке. В данном
примере последний узел сети восстанавливает порядок следования пакетов, преж-
де чем доставить их получателю. В некоторых дейтаграммных сетях задача вос-
становления порядка пакетов ложится на плечи получателя. Кроме того, любой
из пакетов может быть поврежден во время передачи его по сети. Например, если
на коммутаторе пакетов произойдет сбой, все пакеты, хранящиеся на нем в дан-
ный момент, могут быть потеряны. Обнаружить потерю пакета и решить, как его
восстанавливать, должен либо выходной узел сети, либо сам получатель. При ис-
пользовании данного метода каждый пакет, обрабатываемый независимо, называ-
ется дейтаграммой (datagram).
В случае виртуальных каналов (рис. 4.4) маршрут рассчитывается заранее,
прежде чем будет отправлен первый пакет с данными. Как только маршрут уста-
новлен, все пакеты между парой компьютеров следуют по одному и тому же мар-
шруту. Поскольку на время действия логического соединения маршрут фиксиро-
ван, он в чем-то схож с каналом в сети с коммутацией каналов, и его называют
виртуальным каналом (virtual circuit). Каждый пакет помимо данных содержит
идентификатор виртуального канала. Каждый узел, входящий в заранее установ-
ленный маршрут, знает, куда направлять такие пакеты. Принимать решение о вы-
боре маршрута не требуется. В любой момент времени у каждой станции может
быть несколько виртуальных каналов с любой другой (другими) станцией.
4.1. Сети с коммутацией пакетов
105
Рис. 4.4. Коммутация пакетов: метод виртуальных каналов
Таким образом, главная особенность техники виртуальных каналов заклю-
чается в том, что маршрут между станциями устанавливается до передачи сами?
Данных. Обратите внимание на то, что это не означает выделенный путь, как прг
коммутации каналов. Пакеты все так же сохраняются в буферах узлов и устанав-
ливаются в очередь на передачу. Отличие от метода дейтаграмм состоит в том, чтс
106
Глава 4. Ретрансляция кадров
при использовании виртуальных каналов узлу не требуется принимать решение
о выборе маршрута для каждого пакета. Это решение принимается всего один раз
для всех пакетов, использующих данный виртуальный канал.
Если две станции желают обмениваться данными в течение длительного вре-
мени, то метод виртуальных каналов дает определенные преимущества. Во-пер-
вых, сеть может предоставить услуги, связанные с виртуальным каналом, вклю-
чая сохранение порядка доставки пакетов и контроль ошибок. Сохранение порядка
доставки пакетов достигается автоматически, так как все пакеты следуют по одно-
му маршруту. Контроль ошибок обеспечивается службой, гарантирующей не толь-
ко доставку пакетов в правильном порядке, но и отсутствие повреждений пакетов.
Например (см. рис. 4.3), если какой-либо пакет не был доставлен с узла 4 на узел 6
или был доставлен с повреждениями, узел 6 может запросить у узла 4 повторную
передачу этого пакета. Другое преимущество виртуальных каналов заключается
в том, что узлы не должны тратить дополнительное время на принятие решения
о выборе маршрута, в результате доставка пакетов должна происходить быстрее.
Одно из преимуществ метода дейтаграмм состоит в том, что не требуется фаза
установки соединения. Таким образом, если станции нужно отправить всего один
или небольшое количество пакетов, дейтаграммная доставка будет быстрее. Дру-
гое преимущество метода дейтаграмм заключается в том, что служба дейтаграмм
обладает большей гибкостью. Например, в случае возникновения перегрузки на
одном участке сети любой узел может изменить маршрут получаемых им дейта-
грамм в обход перегруженного участка. При использовании виртуальных каналов
все пакеты следуют по заранее определенному маршруту, поэтому сети значитель-
но труднее приспособиться к перегрузке. Третье преимущество метода дейтаграмм
состоит в том, что дейтаграммная доставка обладает большей надежностью. При
использовании виртуальных каналов, если один из узлов выходит из строя, все
виртуальные каналы, проходящие через этот узел, теряются. При дейтаграммной
доставке в случае выхода из строя одного из узлов последующие пакеты могут най-
ти альтернативный маршрут в обход аварийного узла.
С точки зрения пользователя, внешних различий между методами дейтаграмм
и виртуальных каналов должно быть очень немного. Если менеджер оказывается
перед выбором, то в первую очередь, вероятно, следует учитывать такие факторы,
как цена и производительность, а не способ доставки пакетов.
Маршрутизация
Для работы сети с коммутацией пакетов важны такие две связанные друг с другом
функции, как борьба с перегрузками и маршрутизация. Борьба с перегрузками
обсуждается в главе 10. Здесь мы скажем несколько слов о маршрутизации.
Практически во всех сетях с коммутацией пакетов используется некоторая раз-
новидность адаптивной маршрутизации. Это значит, что решения о выборе марш-
рута изменяются при изменении состояния сети. Основными причинами, влияю-
щими на принятие решений о выборе маршрутов, являются:
♦ неисправность — когда узел или канал связи выходит из строя, он более не
может использоваться в качестве части маршрута;
4.1. Сети с коммутацией пакетов
107
♦ перегрузка — когда какой-либо участок сети оказывается перегруженным,
желательно направлять пакеты в обход.
Чтобы адаптивная маршрутизация была возможна, узлы должны обменивать-
ся информацией о состоянии сети. Ради качества информации приходится мирить-
ся с определенными накладными расходами. Чем больше объем информации, ко-
торой обмениваются узлы, и чем чаще происходит обмен информацией, тем выше
качество принимаемых узлами решений о выборе маршрутов. С другой стороны,
сама эта информация оказывает определенную нагрузку на сеть, вызывая сниже-
ние производительности.
Стандарт X. 25
Остается рассмотреть один технический аспект сетей с коммутацией пакетов: ин-
терфейс между сетью и присоединенными к ней устройствами. Первым коммер-
ческим стандартом сетевого интерфейса был Х.25. Сейчас стандарт Х.25 редко при-
меняется в развитых странах, но все еще используется в различных уголках мира.
Мы приведем здесь краткий обзор стандарта Х.25, чтобы объяснить причины при-
нятия некоторых решений для сетей ретрансляции кадров и ATM.
Х.25 представляет собой стандарт сектора ITU-T', определяющий интерфейс
между хостом и сетью с коммутацией пакетов. Функциональность стандарта Х.25
определяется на трех уровнях;
♦ физическом уровне;
+ канальном уровне1 2;
4- пакетном уровне.
Физический уровень имеет дело с физическим интерфейсом между присоеди-
ненной станцией (компьютером, терминалом) и каналом, соединяющим станцию
с узлом коммутации пакетов. Для этого уровня используется спецификация стан-
дарта Х.21, хотя во многих случаях применяются другие стандарты, например стан-
дарт EIA-232 (Electronics Industries Association — Ассоциация электронной про-
мышленности). Канальный уровень обеспечивает надежную передачу данных по
физическому каналу, пересылая данные в виде последовательности кадров. Стан-
дарт канального уровня называют LAPB (Link Access Protocol-Balanced — сбалан-
сированный протокол доступа к каналу связи). Протокол LAPB представляет со-
бой подмножество стандарта HDCL, описываемого в главе И.
Пакетный уровень предоставляет службу виртуального канала. Эта служба
позволяет всем подписчикам сети устанавливать логические соединения, называ-
емые виртуальными каналами, с другими подписчиками. Пример использования
виртуальных каналов показан на рис. 4.5 (сплошными линиями показаны физичес-
кие каналы связи, а штриховыми — виртуальные). Сравните его с рис. 4.3. В данном
примере станцией А установлен виртуальный канал со станцией С; станцией В
Установлены два виртуальных канала, один со станцией С, другой со станцией D;
кроме того, станции Е и F соединены виртуальными каналами со станцией D.
1 Международный союз телекоммуникаций, сектор телекоммуникаций (International Telecommunica-
tionsUnion-Telecoinmunications).
2 Также называется уровнем передачи данных и уровнем управления каналом связи. — Примеч. перво.
108 Глава 4. Ретрансляция кадров
Рис. 4.5. Использование виртуальных каналов
В данном контексте термин виртуальный канал означает логическое соедине-
ние между двумя станциями сети. Возможно, такое соединение лучше называть
внешним виртуальным каналом. Ранее мы использовали термин виртуальный ка-
нал для обозначения заранее спланированного маршрута между двумя станциями
сети. Этот маршрут можно назвать внутренним виртуальным каналом. Как пра-
вило, имеется однозначное соответствие между внешними и внутренними вир-
туальными каналами. Однако стандарт Х.25 может быть использован и в дей-
таграммной сети. Для внешнего виртуального канала важно то, что между двумя
станциями устанавливается логическая связь, или логический канал, и все данные,
связанные с этим логическим каналом, рассматриваются как часть единого пото-
ка данных между двумя станциями. Например, на рис. 4.5 станция D различает
пакеты, прибывающие с трех разных рабочих станций (В, Е, F), по номеру вирту-
ального канала, связанного с каждым приходящим пакетом.
Рисунок 4.6 иллюстрирует связь между уровнями протоколов стандарта Х.25.
Данные пользователя передаются вниз на уровень 3 стандарта Х.25, который добав-
ляет управляющую информацию в виде заголовка, создавая таким образом пакет.
Эта управляющая информация служит нескольким целям:
4- Содержит номер виртуального канала, служащий идентификатором.
4- Предоставляет порядковые номера, которые могут использоваться для управ-
ления потоком и контроля ошибок в каждом виртуальном канале.
4.2. Сети с ретрансляцией кадров 109
Пакет Х.25
Кадр LAPB
Рис. 4.6. Данные пользователя и управляющая информация протокола Х.25
Затем весь пакет Х.25 передается вниз LAPB-сушности, которая добавляет уп-
равляющую информацию в начало и в конец пакета, формируя таким образом кадр
LAPB. Эта управляющая информация необходима для работы протокола LAPB.
4.2. Сети с ретрансляцией кадров
История вопроса
При традиционном подходе к коммутации пакетов используется стандарт Х.25,
который не только определяет интерфейс пользователь—сеть, но также оказывает
влияние на внутреннее строение сети. Некоторые ключевые особенности подхода
Х.25 перечислены ниже:
♦ Пакеты, управляющие соединением, то есть необходимые для установки
и разрыва виртуального канала, передаются по тому же самому каналу, что
и пакеты данных. В результате используется внутренняя сигнализация.
Мультиплексирование виртуальных каналов происходит на уровне 2.
♦ Механизмы управления потоком и контроля ошибок поддерживаются как .
на уровне 2, так и на уровне 3.
Применение стандарта Х.25 связано со значительными накладными расхо-
дами. На каждом ретрансляционном участке сети протокол канального уровня
подразумевает обмен пакетами данных и подтверждения. Кроме того, на каждом
промежуточном узле должны содержаться таблицы состояния для каждого вир-
туального канала, чтобы обеспечивать управление вызовами, а также управление
потоком и контроль ошибок. Все эти накладные расходы оправданы, если имеется
Довольно высокая вероятность ошибки на любой линии связи сети. Для современ-
ных цифровых средств связи приемлемым этот подход назвать нельзя. В сегодняш-
них сетях используются надежные цифровые технологии передачи данных ио
надежным каналам связи высокого качества, многие из которых представляют
собой оптоволоконные кабели. Кроме того, благодаря волоконной оптике и циф-
110 Глава 4. Ретрансляция кадров
ровым технологиям могут быть достигнуты высокие скорости передачи данных.
В таком окружении накладные расходы протоколов Х.25 представляются не толь-
ко ненужными, но и снижающими производительность сетей.
Технология ретрансляции кадров разработана, чтобы устранить большую часть
накладных расходов стандарта Х.25, возникающих как в оконечных пользователь-
ских системах, так и в сетях с коммутацией пакетов. Ключевые различия между
ретрансляцией кадров и обычной службой коммутации пакетов стандарта Х.25
перечислены ниже:
♦ Сигналы управления соединением передаются по отделенному от данных
пользователя логическому соединению. Таким образом, промежуточным уз-
лам не нужно хранить таблицы состояния или обрабатывать сообщения, от-
носящиеся к управлению соединением для каждого отдельного соединения.
♦ Мультиплексирование и коммутация логических соединений осуществля-
ется на уровне 21, а не на уровне 3, что позволяет устранить целый уровень.
> При ретрансляции кадров не производится управления потоком и контро-
ля ошибок. При необходимости эти вопросы решаются на более высоком
уровне.
Таким образом, при ретрансляции кадров одиночный кадр данных пользовате-
ля посылается от источника приемнику, а подтверждение, формируемое на более
высоком уровне, переносится обратно в кадре. Обмена кадров данных и подтвер-
ждений между отдельными узлами сети нет.
Рассмотрим преимущества и недостатки данного подхода. Основной потенци-
альный недостаток ретрансляции кадров по сравнению со стандартом Х.25 заклю-
чается в том, что теряется возможность управления потоком и контроля ошибок.
(Хотя ретрансляция кадров не предоставляет сквозного управления потоком и
контроля ошибок, они могут осуществляться на более высоком уровне.) В стан-
дарте Х.25 несколько виртуальных каналов формируются на одной физической
линии связи, а на канальном уровне возможно использование протокола LAPB для
обеспечения надежной передачи данных от источника до сети с коммутацией па-
кетов и от сети с коммутацией пакетов до получателя. Кроме того, на каждом ре-
трансляционном участке сети для надежности может быть использован протокол
передачи данных. В случае ретрансляции кадров этот канальный протокол на уров-
не ретрансляционных участков теряется. Однако благодаря выросшей надежнос-
ти физических каналов связи и коммутаторов этот недостаток не является таким
уж существенным.
Преимущество ретрансляции кадров заключается в том, что процесс взаи-
модействия значительно упрощается. Интерфейс между сетью и пользователем
становится существенно проще, так же как и внутренняя сетевая обработка.
В результате можно ожидать снижения задержек и увеличения производитель-
ности. Изучения показывают (см. [111]), что при использовании механизма
ретрансляции кадров вместо стандарта Х.25 производительность улучшается
на порядок или даже более. В рекомендации 1.233 сектора ITU-T указывается, что
ретрансляцию кадров следует применять на скоростях доступа до 2 Мбит/с.
’ Видимо, ошибка, так как (см. выше) Х.25 также мультиплексирует виртуальные каналы на уровне 2. —
Примеч. перев.
4.2. Сети с ретрансляцией кадров
111
Однако в настоящее время уже доступна служба ретрансляции кадров на более
высоких скоростях.
Архитектура ретрансляции кадров
На рис. 4.7 структура протокола ретрансляции кадров сравнивается со структурой
протокола Х.25. Как уже упоминалось, стандарт Х.25 определяет три уровня. Физи-
ческий уровень ответствен за детали передающей среды и передачу битов с заданной
скоростью при помощи определенного метода кодирования (например, EIA-232).
Протокол LAPB предоставляет надежный протокол управления каналом. Пакетный
уровень позволяет устанавливать виртуальные каналы. Отношение между протоко-
лом LAPB и пакетным уровнем иллюстрирует рис. 4.8, а. Между устройством подпис-
чика, также называемым терминальным оборудованием (Data Terminal Equipment,
DTE), и оконечным оборудованием линии передачи данных (Data Circuit-terminating
Equipment, DCE), к которому оно присоединено, используется протокол LAPB,
обеспечивающий надежную передачу кадров. Каждый кадр содержит пакет, в за-
головке которого хранится номер виртуального канала. Таким образом, «труба»
LAPB может содержать в себе несколько виртуальных каналов. Как показано на
рис. 4.8, а, у этих виртуальных каналов могут быть различные маршруты к разным
пунктам назначения. Таким образом, подписчик может управлять несколькими
виртуальными каналами, связывающими его с другими подписчиками сети.
Реализуется
оконечной
системой и сетью
Пакетный
уровень
, -Х.25
Реализуется
оконечной
системой,
но не сетью
I-........J
; Управление .
I LAPF
Физический
" уровень
Реализуется
оконечной
системой и сетью
Физический
уровень
Реализуется
оконечной
системой,
но не сетью
I
t
Реализуется
оконечной
системой и сетью
Упр&ВЛ^иё
LAPF
Ядро. LAPP
Физический.
уров^|
4
Х.25
Ретрансляция
кадров
Коммутация
кадров
Рис. 4.7. Сравнение стеков протоколов Х.25 и ретрансляции кадров
Ретрансляция кадров, напротив, включает протокол LAPF (Link Access Pro-
cedure for Frame mode bearer services — процедура доступа к каналу для каналь-
ных служб в режиме кадров), представляющий собой протокол одновременно фи-
зического уровня и уровня управления каналом. На самом деле определены две
версии протокола LAPF. Все сети с ретрансляцией кадров содержат реализацию
протокола ядра LAPF(LAPF core) на всех системах подписчиков и всех узлах ре-
трансляции кадров. Протокол ядра LAPF предоставляет минимальный набор функ-
ции управления каналом данных, включая:
♦ определение границ кадра, выравнивание кадра и прозрачность;
♦ мультиплексирование и демультиплексирование с помощью адресного поля;
112 Глава 4. Ретрансляция кадров
4 изучение кадра, чтобы перед добавлением или извлечением нулевых битов
гарантировать, что кадр состоит из пелого числа байтов;
♦ изучение кадра, чтобы гарантировать, что его длина правильная;
4 обнаружение ошибок передачи;
♦ борьбу с перегрузками.
б
Рис. 4.8. Виртуальные каналы и виртуальные соединения ретрансляции кадров
Кроме того, пользователь может выбрать дополнительные сквозные функции
канального или сетевого уровня. Одну из возможностей предоставляет управляю-
щий протокол LAPF (LAPF control). Этот протокол не является частью службы
ретрансляции кадров, но он может быть реализован только в оконечных системах
для обеспечения управления потоком и контроля ошибок.
Служба ретрансляции кадров, использующая протокол ядра LAPF, обеспечи-
вает следующие характеристики передачи данных:
4- сохранение порядка следования кадров при передаче их из одного конца
сети в другой;
♦ небольшую вероятность потери кадра.
4.2. Сети с ретрансляцией кадров
113
Как и стандарт Х.25, ретрансляция кадров требует логических соединений, на-
зываемых в данном случае не виртуальными каналами, а виртуальными соедине-
ниями. На рис. 4.8, б показано, что кадры, передаваемые по этим виртуальным
соединениям, не защищаются системой управления каналом данных с помощью
механизмов управления потоком и контроля ошибок.
Другое различие между стандартом Х.25 и ретрансляцией кадров заключается
в том, что при ретрансляции кадров для управления соединением используется
выделенное виртуальное соединение. Установка и разрыв остальных виртуальных
соединений осуществляются с помощью этого виртуального соединения, предназ-
наченного специально для управления.
Архитектура ретрансляции кадров существенно снижает объем работ, который
должна выполнять сеть. Данные пользователя передаются в виде кадров прак-
тически без обработки на промежуточных узлах сети. Они только проверяют
контрольную сумму и направляют их в соответствии с номерами соединений.
Поврежденный кадр просто отбрасывается. Исправлением ошибок занимаются бо-
лее высокие уровни.
Передача данных пользователя
Работу механизмов ретрансляции кадров по передаче данных пользователя луч-
ше всего можно объяснить, начав с формата кадра, показанного на рис. 4.9. Здесь
используются следующие обозначения:
♦ ЕА (Extension Address) — бит расширения поля адреса;
♦ C/R (Command/Response) — бит команда/ответ;
+ FCS (Frame Check Sequence) — контрольная последовательность кадра;
Флаг | Адрес | Информация | FCS | Флаг |
< — <--- 2—4 ----><--------- Переменное----------><----- 2----- > < — 1 ->
Байт
Формат кадра
8 7 6 5 4 3 2 1
Верхний идентификатор DLCI C/R EAO
Нижний идентификатор FECN BECN DE EA1
Поле адреса — 2 байта (по умолчанию)
8 7 6 5 4 3 2 1
Верхний идентификатор DLCI C/R EAO
DLCI I FECN I BECN DE EAO
DLCI EAO
Управляющее поле нижнего индикатора D/C D/C EA1
Поле адреса — 4 байта
8 7 6 5 4 3 2 1
Верхний идентификатор DLCI C/R EAO
DLCI | FECN | BECN DE EAO
Управляющее поле нижнего индикатора D/C D/C EA1
Поле адреса — 3 байта
Рис. 4.9. Форматы кадров протокола ядра LAPF
114 Глава 4. Ретрансляция кадров
4 FECN (Forward Explicit Congestion Notification) — уведомление о перегруз-
ке впереди;
4 BECN (Backward Explicit Congestion Notification) — уведомление о пере-
грузке позади;
4- DLCI (Data Link Connection Identifier) — идентификатор соединения уров-
ня передачи данных;
4 D/C — индикатор управления DLCI или DL-CORE;
4 DE (Discard Eligibility) — отвергнуть пригодность.
Этот формат схож с форматами других протоколов передачи данных, например
HDLC или LAPB, с одним отличием: кадр не содержит управляющего поля. В тра-
диционных протоколах передачи данных управляющее поле выполняет перечис-
ленные ниже функции:
4 Часть управляющего поля идентифицирует тип кадра. Кроме кадров, перено-
сящих данные пользователя, существует множество управляющих кадров. Они
не переносят данных пользователя, но требуются для различных управляющих
функций протокола, таких как установка и разрыв логических соединений.
4 Управляющее поле кадров с данными пользователя включает порядковые
номера отправителя и получателя. Порядковый номер отправителя исполь-
зуется для последовательной нумерации всех передаваемых кадров. Поряд-
ковый номер получателя используется для предоставления положительного
или отрицательного подтверждения входящих кадров. С помощью поряд-
ковых номеров получатель может управлять скоростью получения кадров
(управление потоком), а также сообщать о поврежденных кадрах, которые
могут быть переданы повторно (контроль ошибок).
Отсутствие управляющего поля в формате кадра означает, что процесс уста-
новки и разрыва соединения должен осуществляться по отдельному каналу на бо-
лее высоком уровне программного обеспечения. Это также означает невозмож-
ность управления потоком и контроля ошибок.
Поля «Флаг» и «FCS» (Frame Check Sequence — контрольная последователь-
ность кадра) работают так же, как в протоколе HDLC. Поле «Флаг» представляет
собой уникальную последовательность битов, ограничивающую начало и конец
кадра. Поле «FCS» используется для обнаружения ошибок. При передаче счита-
ется контрольная сумма и сохраняется в поле «FCS». При приеме контрольная
сумма считается снова и сравнивается со значением, хранящимся в поле «FCS».
Если эти значения не совпадают, кадр считается поврежденным и отбрасывается.
Поле «Информация» содержит данные более высокого уровня. Это могут быть
данные пользователя или сообщения, управляющие соединением, о которых бу-
дет рассказано позднее.
Поле «Адрес» по умолчанию имеет длину 2 байта и может быть увеличено до
3 или 4 байт. Оно содержит идентификатор соединения уровня передачи данных
(Data Link Connection Identifier, DLCI), который может иметь длину 10, 17 или
24 бита. Идентификатор DLC1 выполняет ту же функцию, что и номер виртуаль-
ного канала в протоколе Х.25: он позволяет мультиплексировать несколько логи-
ческих соединений ретрансляции кадров в одном канале.
4,3. Рекомендуемые литература и веб-сайты
115
Длина адресного поля и, таким образом, идентификатора DLCI определяется
битами расширения адресного поля (ЕА). Бит C/R является специфичным для
приложения и не используется стандартным протоколом ретрансляции кадров.
’ Остал ьные биты поля адреса относятся к борьбе с перегрузками.
Управление соединением ретрансляции кадров
Детали процедуры управления соединением для ретрансляции кадров зависят от кон-
' текста ее использования. Разработанные на сегодняшний день стандарты предпола-
гают работу механизмов ретрансляции кадров поверх сети ISDN (Integrated Services
v Digital Network — цифровая сеть с интегрированными службами). Когда ретрансля-
ция кадров выполняется поверх линии «точка—точка» (между парой мостов или мар-
| шрутизаторов), может быть достаточным использование более простого протокола.
С Как и стандарт Х.25, ретрансляция кадров поддерживает несколько соедине-
$ ний по одной линии связи. В случае ретрансляции кадров они называются соеди-
»' нениями уровня передачи данных, и у каждого соединения есть свой уникальный
> идентификатор этого соединения (DLCI). Передача данных выполняется в несколь-
ко этапов:
1. Установка логического соединения между двумя конечными точками и на-
значение соединению уникального идентификатора DLCI.
2. Обмен информацией в виде кадров. Каждый кадр содержит поле DLCI для
идентификации соединения.
3. Разрыв логического соединения.
Установка и разрыв логического соединения осуществляются путем обмена
сообщениями по выделенному для управления соединению с идентификатором
DLCI=0. Кадр с DLCI=0 содержит в информационном поле управляющее со-
общение. Как минимум, требуются четыре типа сообщений: SETUP (установка),
CONNECT (соединение), RELEASE (разрыв соединения) и RELEASE COMPLETE
(соединение разорвано).
Каждая сторона может запросить установку логического соединения, отправив
сообщение SETUP. Получив сообщение SETUP, другая сторона должна ответить
сообщением CONNECT, если она согласна установить соединение. В противном
случае она отвечает сообщением RELEASE COMPLETE. Сторона, посылающая
сообщение SETUP, может присвоить соединению идентификатор DLCI, выбрав
неиспользуемое значение и включив его в сообщение SETUP. В противном слу-
чае значение DLCI назначается принимаемой стороной в сообщении CONNECT.
Каждая сторона может запросить разрыв логического соединения, отправив
сообщение RELEASE. Получив сообщение, другая сторона должна ответить сооб-
щением RELEASE COMPLETE.
4.3. Рекомендуемые литература и веб-сайты
Книг о коммутации пакетов очень и очень много. Этот вопрос хорошо освещается
в [209], [28] и [211]. Также большое количество литературы посвяшено вопросу
производительности; хорошие обзоры можно найти в [218], [199] и [137].
116 Глава 4. Ретрансляция кадров
Более детальное рассмотрение механизмов ретрансляции кадров можно найти
в [213]. Отличной книгой, посвященной этому вопросу, является [40].
Ниже перечислены рекомендуемые веб-сайты:
4 Frame Relay Fonmi. Сайт ассоциации производителей, операторов связи,
пользователей и консультантов, являющихся приверженцами технологии
ретрансляции кадров в соответствии с национальными и международными
стандартами. Сайт содержит список технической документации, которую
можно приобрести.
4 Frame Relay Resources. Исчерпывающий источник информации по ретранс-
ляции кадров.
4.4. Задания
1. Найдите ошибку в следующей логике. Коммутация пакетов требует добав-
ления к каждому пакету управляющих и адресных битов. В результате ис-
пользование коммутации пакетов связано с существенными накладными
расходами. При коммутации каналов устанавливается прозрачный канал.
Дополнительные биты не требуются. Таким образом, при коммутации ка-
налов нет накладных расходов. Поскольку при коммутации каналов нет на-
кладных расходов, использование линии должно быть более эффективным,
чем при коммутации пакетов.
2. Ниже перечислены параметры сети с коммутацией пакетов. Используя эти
параметры, выполните два задания. Во-первых, а) для значений N= 4,L = 3200,
Б = 9600,Р = 1024, Н= 16,5 = 0,2 и D = 0,001 вычислите сквозную задержку для
коммутации каналов, коммутации пакетов с виртуальными каналами и дей-
таграммной коммутации пакетов. Предположите, что подтверждений нет.
Игнорируйте задержку на обработку пакетов в узлах. Во-вторых, б) выве-
дите общие формулы для всех трех методов задания а). Рассмотрите три
метода попарно. При каких условиях задержки будут одинаковыми:
+ Л/— количество ретрансляционных участков между двумя данными око-
нечными системами;
♦ L — длина сообщения в битах;
♦ В — скорость передачи данных в битах в секунду по всем линиям;
♦ Р — фиксированный размер пакетов в битах;
♦ Н — накладные расходы (заголовок) в битах на пакет;
♦ S — время установки соединения (время коммутации канала или уста-
новки виртуального канала) в секундах;
♦ D — задержка распространения сигнала в секундах на ретрансляционный
участок?
3. Используя параметры из предыдущего задания, определите, при каком зна-
чении Р (при фиксированных N, L11Н) сквозная задержка в дейтаграммной
сети будет минимальной? Предполагается, что L много больше, чем Р, а £>
равно нулю.
4.4. Задания
117
4. Рассмотрите состоящую из N узлов сеть с коммутацией пакетов, обладаю-
щую следующей топологией, и для каждого случая сосчитайте среднее ко-
личество ретрансляционных участков между станциями:
а) звезда — один центральный узел, у которого нет прямых соединений со
станциями; все остальные узлы соединены с центральным узлом;
б) кольцо — каждый узел соединен с двумя другими узлами;
в) полное соединение — каждый узел напрямую соединен со всеми осталь-
ными узлами.
5. Рассмотрите сеть с коммутацией пакетов и топологией двоичного дерева.
Корневой узел соединен с двумя другими узлами. Все промежуточные узлы
соединены с одним узлом в направлении корня дерева и двумя узлами в про-
тивоположном направлении. Внизу располагаются узлы, имеющие только
одно соединение в направлении корня. Вычислите среднее количество ре-
трансляционных участков на пакет для сети с 2Л’-1 узлами для больших зна-
чений N, предполагая, что пересылки между всеми парами узлов равнове-
роятны. Подсказка: следующие уравнения могут оказаться полезными:
со Л Л со Л Л
; УгХ‘ =-------т.
ft 1-Х £ (1-Х)2 6 7 8
6. Стандарт Х.25 не содержит механизма обнаружения ошибок (контрольной
суммы кадра). А нужен ли он, чтобы гарантировать, что все пакеты достав-
лены верно?
7. Когда терминальное оборудование (DTE) и оконечное оборудование линии
передачи данных (DCE) одновременно решают установить соединение по
одной и той же линии, происходит коллизия и соединение не устанавлива-
ется. Когда обе стороны пытаются одновременно разорвать один и тот же
виртуальный канал, коллизия разрешается мирно и виртуальный канал раз-
рывается. Пакет Х.25 Reset обеспечивает восстановление в случае ошибки
путем повторной инициализации виртуального канала, которая означает,
что порядковые номера на обоих концах устанавливаются на 0. Как вы по-
лагаете, одновременные попытки повторной инициализации обрабатывают-
ся как коллизия установки соединения или как коллизия разрыва канала?
8. Почему в стандарте Х.25 номер виртуального канала, используемый одной
из пары взаимодействующих станций, отличается от номера виртуального
канала, используемого второй станцией? В конце концов, это один и тот же
дуплексный виртуальный канал.
Глава 5
Сети ATM
У одного человека была мечта соединить все железнодорожные
терминалы железнодорожными путями. Его имя было Чарльз
Пирсон и, будучи сыном обивщика, он стал главным прокуро-
ром Лондона. Вначале существовал план прокладки освещае-
мых газовыми фонарями туннелей, по которым могли бы дви-
гаться повозки на конной тяге. Этот план был отвергнут на том
основании, что мрачные туннели станут пристанищем воров.
За двадцать лет до того, как его система была построена, Пир-
сон обдумывал создание линии, проходящей под «просторными
сводами», хорошо освещаемыми и хорошо вентилируемыми.
Это была схема железнодорожного туннеля.
Барбара Байн (Рут Ренделл). Ковер царя Соломона
Технология ATM (Asynchronous Transfer Mode — асинхронный режим передачи),
также иногда называемая ретрансляцией ячеек (cell relay), концептуально схо-
жа с ретрансляцией кадров. Обе технологии (ретрансляции кадров и ATM) опи-
раются на возможности современных средств связи в плане надежности и точности,
обеспечивая более быструю коммутацию пакетов, чем стандарт Х.25. Функцио-
нально сеть ATM проще, чем сеть ретрансляции кадров, и способна поддерживать
скорости передачи данных на несколько порядков выше.
Помимо технической близости у технологий ATM и ретрансляции кадров схо-
жие истории развития. Разработка схемы ретрансляции кадров проводилась как
часть работ над ISDN, но сегодня она находит широкое применение в частных
сетях и в других, не связанных с ISDN, приложениях, в частности в мостах и марш-
рутизаторах. Технология ATM развивалась в ходе работ над широкополосной
сетью ISDN, но используется в не связанном с ISDN окружении, где требуются
высокие скорости передачи данных.
В главе содержится обзор технологии ATM, включая архитектуру протоколов,
логические соединения и структуру ячеек. Затем мы рассмотрим важное понятие
уровня AAL (ATM Adaptation Level — уровень адаптации ATM).
Прежде чем перейти к изучению ATM, следует отметить, что спецификация
ATM была разработана сектором ITU-T и ATM-форумом. Сектор ITU-T в пер-
вую очередь заботился о разработке стандартов ATM как части работ по стандай
тизации широкополосной сети ISDN, тогда как ATM-форум был заинтересова|
в широком спектре АТМ-приложений. ATM-форум представляет собой некой
5.1. Архитектура протоколов ATM
119
мерческий международный промышленный консорциум. Его роль, а также роль
сектора ITU-T в создании ATM-приложений обсуждаются в приложении А. За
исключением особо оговариваемых случаев, материал этой книги основан на
самых последних документах ATM-форума, включающих версию 3.1 специфика-
ции интерфейса пользователь—сеть [17] и версию 4.1 спецификации управления
трафиком [18].
5.1. Архитектура протоколов ATM
Технология ATM в некоторых аспектах схожа с коммутацией пакетов, со стандар-
том Х.25 и с ретрансляцией кадров. Как и при коммутации пактов и ретрансляции
кадров, в ATM поддерживается мультиплексирование нескольких логических
соединений в одном физическом интерфейсе. В случае ATM поток информации
в каждом логическом соединении организован в пакеты фиксированного размера,
называемые ячейками (cells).
ATM представляет собой упрощенный протокол с минимальными возможнос-
тями контроля ошибок и управления потоком. Это позволяет снизить накладные
расходы на обработку ячеек ATM и уменьшить количество дополнительных
служебных битов в каждой ячейке, в результате чего сеть ATM может работать на
более высоких скоростях передачи данных. Более того, использование ячеек фик-
сированного размера упрощает обработку, требующуюся на каждом узле ATM, что
также способствует большим скоростям.
Стандарты для ATM, выпущенные сектором ITU-T, основаны на архитектуре
протоколов, показанной на рис. 5.1. Физический уровень включает спецификацию
передающей среды и схему кодирования сигнала. Скорости передачи данных,
указанные в стандарте, включают 155,52 Мбит/с и 622,08 Мбит/с. Также доступ-
ны и другие скорости, как более высокие, так и более низкие.
Рис. 5.1. Архитектура протоколов ATM
120
Глава 5. Сети ATM
Два уровня архитектуры протоколов относятся к функциям ATM. Уровень
ATM, общий для всех служб, обеспечивает перенос пакетов, а уровень AAL зави-
сит от служб. Уровень ATM обеспечивает передачу данных в виде ячеек фиксиро-
ванного размера, а также использование логических соединений. Наличие уровня
ATM создает потребность в уровне адаптации, поддерживающем протоколы
передачи информации, не относящиеся к ATM. Уровень AAL преобразует ин-
формацию высокого уровня в ячейки ATM, чтобы ее можно было переносить по
сети ATM, а затем собрать эту информацию из ячеек ATM для доставки более вы-
соким уровням.
Помимо уровней эталонная модель протоколов описывает три слоя:
♦ Слой пользователя (user plane) обеспечивает транспортировку данных пользо-
вателя, управление потоком, коррекцию ошибок и другие функции.
♦ Слой контроля (control plane) осуществляет управление соединениями.
4 Слой управления (management plane) реализует управление слоями. Функ-
ции слоя управления относятся к системе в целом и включают управление
ресурсами и межуровневую и межслойную координацию.
5.2. Логические соединения ATM
Логические соединения в сетях ATM называют соединениями виртуальных кана-
лов (Virtual Channel Connection, VCC). Соединение виртуального канала анало-
гично виртуальному каналу стандарта Х.25 или соединению уровня передачи дан-
ных в схеме ретрансляции кадров; это основная единица коммутации в сети ATM.
Соединение VCC устанавливается по сети между двумя конечными пользова-
телями, и по этому соединению производится обмен ячейками фиксированного
размера, образующий дуплексный поток с переменной скоростью. Кроме того, со-
единения виртуальных каналов используются для обмена информацией между
пользователем и сетью (для управляющих сигналов), а также обмена информаци-
ей между сетями (сетевое управление и маршругизация).
В сетях ATM был введен второй подуровень обработки, относящийся к кон-
цепции виртуального пути (рис. 5.2). Соединение виртуального пути (Virtual Path
Connection, VPC) представляет собой группу соединений VCC с одинаковыми
конечными точками. Таким образом, все ячейки, передаваемые по всем соедине-
ниям виртуальных каналов одного соединения виртуального пути, следуют по од-
ному и тому же маршруту.
Рис. 5.2. Соединения в сети ATM
5.2. Логические соединения ATM 121
Понятие виртуального пути стало ответом на постоянное увеличение доли за-
трат на управление сетью в суммарных сетевых затратах, характерное для высоко-
скоростных сетей. Метод виртуального пути позволяет ограничивать затраты на
управление, объединяя соединения, пользующиеся общим путем, в единую груп-
пу. В результате вместо огромного количества отдельных соединений сети доста-
точно управлять небольшим количеством групп соединений.
Использование виртуальных путей имеет ряд достоинств:
4 Упрощенная архитектура сети. Транспортные функции сети могут быть
разделены на относящиеся к индивидуальному логическому соединению
(виртуальному каналу) и относящиеся к группе логических соединений
(виртуальному пути).
♦ Более высокие производительность и надежность сети. Сеть имеет дело
с меньшим количеством групповых сущностей.
♦ Более простая обработка и меньшее время установления соединения. Основ-
ная часть работы выполняется в процессе установки виртуального пули.
Благодаря резервированию ресурсов соединения виртуального пути с уче-
том возможных запросов соединений новые виртуальные каналы могут быть
установлены при помощи простых функций управления на конечных точках
виртуального пути. На промежуточных узлах не требуется никакой обра-
ботки. Таким образом, для добавления новых виртуальных каналов к суще-
ствующему виртуальному пути требуется минимум обработки.
♦ Усовершенствованные сетевые службы. Виртуальный путь используется
внутри сети, но он также видим для конечного пользователя. Таким обра-
зом, пользователь может определять закрытые пользовательские группы
или закрытые сети из групп виртуальных каналов.
Рисунок 5.3 иллюстрирует процесс установления соединения с использовани-
ем виртуальных каналов и виртуальных путей. Процесс установления соединения
виртуального пули отделен от процесса установления соединения отдельного вир-
туального канала.
♦ Механизмы управления виртуальным путем включают вычисление марш-
рутов, резервирование ресурсов и сохранение информации о состоянии со-
единения.
♦ Для установки отдельного виртуального канала требуется проверить, что
имеется соответствующее соединение виртуального пути с количеством ре-
сурсов, достаточным для поддержания виртуального канала с приемлемым
качеством обслуживания. После установки виртуального канала сохраня-
ется информация о состоянии соединения (то есть о соответствии виртуаль-
ных каналов и виртуальных путей).
Перечисленные далее термины, используемые в стандартах и относящиеся
к виртуальным путям и виртуальным каналам, представляются несколько путан-
ными. В то время как большинство протоколов сетевого уровня, упоминаемые
в этой книге, относятся только к интерфейсу между пользователем и сетью, кон-
цепции виртуального пути и виртуального канала определены с учетом как интер-
фейса пользователь—сеть, так и чисто сетевой работы.
122
Глава 5. Сети ATM
♦ Виртуальный канал (Virtual Channel, VC). Обобщенный термин, использу-
емый для описания однонаправленного переноса ячеек ATM, объединенных
общим значением уникального идентификатора.
Запрос
на соединение VCC
Нет
Нет
_______*________
Установить новое
соединение VPC
Заблокировать
соединение VCC
или запросить
дополнительную
пропускную способность
Да
Нет
Установить
соединение
________V
Отклонить запрос
на соединение VCC
Рис. 5.3. Установление соединения с использованием виртуальных путей
5.2. Логические соединения ATM
123
+ Линия виртуального канала (virtual channel link). Средство однонаправлен-
ного переноса ячеек ATM между точкой, в которой назначается значение
идентификатора виртуального канала (VCI), и точкой, в которой это значе-
ние транслируется или аннулируется.
4- Идентификатор виртуального канала (Virtual Channel Identifier, VCI). Уни-
кальная числовая метка, идентифицирующая конкретную линию виртуаль-
ного канала для данного соединения VPC.
4- Соединение виртуального канала (Virtual Channel Connection, VCC). Кон-
катенация линий виртуальных каналов, связывающая две конечные точки,
в которых пользователи службы ATM обращаются к уровню ATM. Соеди-
нения виртуальных каналов обеспечивают перенос информации между дву-
мя пользователями, сетью и пользователем или между сетями. Для ячеек,
принадлежащих одному соединению виртуального канала, сохраняется це-
лостность последовательности ячеек.
4 Виртуальный путь (virtual path). Обобщенный термин, используемый для
описания однонаправленного переноса ячеек ATM, принадлежащих вир-
туальным каналам, объединенным общим значением уникального иденти-
фикатора.
4 Линия виртуального пути (virtual path link). Группа линий виртуальных
каналов, идентифицируемая общим значением идентификатора виртуаль-
ного пути (VPI), между точкой, в которой значение VPI назначается, и точ-
кой, в которой это значение транслируется или аннулируется.
+ Идентификатор виртуального пути (Virtual Path Identifier, VPI). Число-
вая метка, идентифицирующая определенную линию виртуального пути.
+ Соединение виртуального пути (Virtual Path Connection, VPC). Конкатена-
ция линий виртуальных каналов от точки, в которой значения VCI назнача-
ются, до точки, в которой эти значения транслируются или аннулируются,
то есть объединение всех групп линий виртуальных каналов с общим значе-
нием VPI. Соединения VPC обеспечивают перенос информации между дву-
мя пользователями, сетью и пользователем или между сетями.
Применение соединения виртуального канала
Конечными точками соединения VCC могут быть конечные пользователи, сете-
вые сущности или конечный пользователь и сетевая сущность. Во всех случаях
Целостность последовательности ячеек внутри соединения VCC сохраняется, то
есть ячейки доставляются в том же порядке, в котором они были отправлены. Рас-
смотрим примеры использования трех возможных вариантов соединения VCC:
♦ Соединение VCC между конечными пользователями может применяться для
передачи пользовательских данных. Также может применяться для обмена
управляющими сигналами между конечными пользователями, о чем будет
рассказано подробнее далее в этой главе. Соединение VPC между конечны-
ми пользователями обеспечивает их всеми ресурсами. Организация соеди-
нения VCC полностью зависит от двух конечных пользователей при усло-
вии, что пропускной способности соединения VPC достаточно.
124
Глава 5. Сети ATM
♦ Соединение VCC между конечным пользователем и сетевой сущностью ис-
пользуется для передачи управляющих сигналов от пользователя в сеть, о
чем будет рассказано позднее. Соединение VPC пользователь — сеть может
применяться для агрегирования трафика от конечного пользователя к сете-
вому коммутатору или сетевому серверу.
4 Соединение VCC между двумя сетевыми сущностями используется для уп-
равления сетевым трафиком и маршрутизации. Соединение VPC сеть — сеть
может потребоваться для определения общего маршрута для обмена инфор-
мацией управления сетью.
Характеристики виртуального пути
и виртуального канала
Характеристики соединений виртуальных каналов перечисляются в рекомендаци-
ях 1.150 сектора ITU-T:
4 Качество обслуживания. Пользователю соединения VCC предоставляется
качество обслуживания, определяемое такими параметрами, как процент
потерянных ячеек (отношение потерянных ячеек к переданным) и значение
задержки ячейки.
4 Коммутируемые и полу постоянные соединения виртуальных каналов. Ком-
мутируемое соединение VCC представляет собой соединение по запросу,
для установки и завершения которого требуются управляющие сигналы.
Полу постоянное соединение VCC устанавливается на длительный срок с
помощью специальной сетевой операции или при конфигурировании сети.
4 Целостность последовательности ячеек. Порядок следования ячеек, пере-
данных по соединению VCC, сохраняется.
4 Определение параметров трафика и мониторинг. Параметры трафика для
каждого соединения VCC являются предметом переговоров между пользо-
вателем и сетью. Сеть выполняет мониторинг поступающих в соединение
VCC ячеек, чтобы гарантировать соблюдение договоренностей.
Типы параметров трафика, о которых могут вестись переговоры, включают
среднюю скорость, максимальную скорость, неравномерность скорости передачи
и длительность передачи с максимальной скоростью. Для борьбы с перегрузками,
а также для управления существующими и запрашиваемыми соединениями VCC
сеть может использовать различные стратегии. На самом примитивном уровне сеть
может просто отказывать в установке новых соединений, чтобы избежать перегруз-
ки. Кроме того, ячейки могут отбрасываться, если нарушаются параметры догово-
ренностей или если перегрузка становится серьезной. В крайней ситуации могут
разрываться существующие соединения.
В рекомендациях 1.150 также перечисляются характеристики соединений VPC.
Первые четыре характеристики идентичны характеристикам соединений VCC.
Это качество обслуживания, коммутируемые и полупостоянные соединения вир-
туальных каналов, целостность последовательности ячеек, а также переговоры для
определения параметров трафика и мониторинг соединения. Такому дублирова-
5.2. Логические соединения ATM
125
f НИЮ есть ряд причин. Во-первых, таким образом обеспечивается определенная
К гибкость в том, как сеть выполняет предъявляемые к ней требования. Во-вторых,
г сеть должна заниматься общими для соединения VPC запросами и оговаривать
параметры установки виртуальных каналов с заданными характеристиками в пре-
‘ делах данного соединения VPC. Наконец, как только соединение VPC установ-
i- лено, конечные пользователи могут начать переговоры о создании новых соеди-
нений VCC. Характеристики VPC накладывают на выбор, предоставляемый
конечным пользователям, определенные ограничения.
Кроме перечисленных для соединений VPC определена пятая характеристи-
ка _ ограничение на значение идентификатора виртуального канала в пределах
соединения VPC. Один или несколько идентификаторов, или номеров, виртуаль-
ных каналов могут быть зарезервированы для сети и недоступны для пользова-
телей соединения VPC. В качестве примера можно упомянуть соединения VCC,
используемые для сетевого управления.
Управляющие сигналы
В сетях ATM для установки и разрыва соединений VPC и VCC нужен специаль-
ный механизм. Данные, которыми обмениваются участники этого процесса, назы-
вают управляющими сигналами (control signaling). Эти сигналы передаются по вы-
деленным соединениям отдельно от соединений, которыми они управляют.
Для соединений VCC рекомендациями 1.150 определяются четыре подхода
к установке и разрыву соединений. Один или несколько из них обязательно ис-
пользуются в любой сети.
♦ Полупостоянные соединения VCC (semipermanent VCCs) могут применять-
ся для обмена данными между пользователями. В этом случае не требуется
никаких управляющих сигналов.
♦ Если канал управления соединением не установлен заранее, он должен быть
установлен. Для этой цели по некоторому каналу пользователь и сеть долж-
ны обменяться управляющими сигналами. То есть требуется постоянный
канал, возможно, с низкой скоростью передачи данных, который можно ис-
пользовать для установки соединения VCC, необходимого для управления
вызовом. Такой канал называется метасигнальным каналом (metasignaling
channel), так как он используется для установки сигнальных каналов.
♦ Метасигнальный канал может потребоваться для установления соединения
VСС между пользователем и сетью с целью передачи управляющих сигна-
лов. Впоследствии этот сигнальный виртуальный канал пользователь — сеть
может использоваться для установки соединений VCC с целью передачи
пользовательских данных.
♦ Метасигнальный канал также может использоваться для установки сигналь-
ного виртуального канала пользователь-пользователь. Такой канал дол-
жен быть установлен в заранее установленном соединении VPC. Затем с его
помощью два конечных пользователя могут устанавливать и разрывать
соединения VCC друг с другом для передачи данных пользователя без
Помощи сети.
126
Глава 5. Сети ATM
Для соединений VPC в рекомендациях L150 определены три метода:
4- Соединение VPC может быть установлено на полупостоянной основе по
договоренности. В этом случае сигнальный канал не требуется.
4- Установкой и разрывом соединения VPC может управлять пользователь. В этом
случае пользователь обращается к сети по сигнальному соединению VCC.
4 Установкой и разрывом соединения VPC может управлять сеть. В этом слу-
чае сеть устанавливает соединение VPC для собственных нужд. Это соеди-
нение может связывать двух пользователей, пользователя с сетью или сете-
вое устройство с сетевым устройством.
5.3. Ячейки ATM
В сети ATM используются ячейки фиксированного размера, состоящие из 5-бай-
тового заголовка и 48-байтового информационного поля. Небольшие ячейки фик-
сированного размера дают ряд преимуществ. Во-первых, небольшой размер ячеек
позволяет снизить время задержки для ячеек с высоким приоритетом, так как ячей-
ке придется меньше ждать, если она прибудет несколько позже низкоприоритет-
ной ячейки. Во-вторых, оказывается, коммутация ячеек фиксированного размера
может осуществляться более эффективно, что весьма важно для сверхвысоких
скоростей ATM. Фиксированный размер ячеек упрощает аппаратную реализацию
коммутирующего механизма.
Формат заголовка
На рис. 5.4, а показан формат заголовка ячейки на уровне интерфейса пользова-
тель — сеть. Рисунок 5.4, б иллюстрирует формат заголовка ячейки для интер-
фейса сеть — сеть.
Поле общего управления потоком (Generic Flow Control, GFC) присутствует
только в заголовке ячейки интерфейса пользователь — сеть. Таким образом, оно
может использоваться для контроля потока ячеек только в локальном интерфейсе
пользователь — сеть для того, чтобы помочь пользователю управлять потоком
в целях получения различных уровней качества обслуживания. В любом случае
механизм GFC применяют для борьбы с кратковременной перегрузкой сети.
В рекомендациях 1.150 записано требование, относящееся к механизму GFC
и заключающееся в том, что все терминалы должны иметь возможность полу-
чать доступ к гарантированным ресурсам. К ним, в частности, относятся терми-
налы с постоянной битовой скоростью (Constant Bit Rate, CBR) и терминалы с
переменной битовой скоростью (Variable Bit Rate, VBR), о которых рассказыва-
ется в разделе 5.4. Современный механизм GFC описывается в следующем под-
разделе.
В идентификатор виртуального пути (Virtual Path Identifier, VPI) входит поле
сетевой маршрутизации. Это поле состоит из 8 бит в интерфейсе пользователь — сеть
и из 12 бит в интерфейсе сеть — сеть. 12-битовое поле обеспечивает поддержку рас-
ширенного количества соединений VPC внутри сети. Для маршрутизации ячеек/
5.3. Ячейки ATM
127
направляемых к конечному пользователю и от конечного пользователя, использу-
ется идентификатор виртуального канала (Virtual Channel Identifier, VCI).
8 7 6
Общее
управление
потоком
2
2
CLP
Контрольная сумма заголовка
Контрольная сумма заголовка
5-баитовыи
заголовок
нтификатор ... . .
?го канала '' * «®
Тип полезной
нагрузки
53-бвйтовая
ячейка
Информационное полв (48 байт)
Информационное поле (48 байт)
а
б
Рис. 5.4. Формат ячайки ATM
Поле «Тип полезной нагрузки» определяет тип информации, содержащейся
в информационном поле. Интерпретация битов поля «Тип полезной нагрузки»:
♦ ООО — ячейка с данными пользователя, перегрузки нет, тип SDU=0;
♦ 001 — ячейка с данными пользователя, перегрузки нет, тип SDU=1;
♦ 010 — ячейка с данными пользователя, перегрузка есть, тип SDU=0;
♦ 011 — ячейка с данными пользователя, перегрузка есть, тип SDU= 1;
♦ 100 — ассоциированная ячейка сегмента О AM1;
♦ 101 — сквозная ассоциированная ячейка О AM;
♦ НО ячейка управления ресурсами;
♦ И1 — зарезервировано на будущее.
Аббревиатура OAM означает Operations (операции), Administration (администрирование) и Main-
tenance (поддержка).
128
Глава 5. Сети ATM
Ноль в первом бите указывает на то, что это данные пользователя (то есть ин-
формация от более высокого уровня). В этом случае второй бит указывает, испы-
тывала ли ячейка при передаче перегрузку в сети. Третий бит, называемый битом
типа SDU1 (Service Data Unit — служебный модуль данных), позволяет различать
два типа служебных модулей данных ATM, ассоциируемых с соединением. Тер-
мин служебный модуль данных (SDU) означает 48-байтовую полезную нагрузку
ячейки. Значение 1 в первом бите поля «Тип полезной нагрузки» говорит о том,
что эта ячейка содержит информацию, относящуюся к сетевому управлению. Этот
бит позволяет вставлять ячейки управления сетью в соединения VCC пользова-
теля, не влияя на данные пользователя. Таким образом, поле «Тип полезной на-
грузки» позволяет передавать управляющую информацию прямо внутри инфор-
мационного канала.
Бит CLP (Cell Loss Priority — приоритет потери ячеек) используется для управ-
ления сетью в случае перегрузки. Значение 0 указывает на ячейку с относительно
высоким приоритетом, которая не должна отбрасываться, если есть другая альтер-
натива. Значение 1 указывает на то, что эта ячейка может быть отброшена сетью
в случае перегрузки. Пользователь может задействовать это поле для передачи в сеть
ячеек сверх оговоренного количества. Для этого он должен установить значение
этого поля в 1, и, если сеть не перегружена, ячейки будут доставлены по указанно-
му адресу. Сеть сама может установить значение этого поля равным 1 для любой
ячейки, нарушающей договоренность о параметрах трафика между пользователем
и сетью. Это делается в том случае, если у коммутатора достаточно ресурсов для
пересылки дополнительных ячеек, но коммутатор понимает, что эта ячейка превы-
шает договорные параметры трафика. Если на одном из следующих коммутаторов
сети возникнет перегрузка, то такая ячейка отбрасывается в первую очередь.
Поле контрольной суммы заголовка используется для контроля ошибок, о чем
будет рассказано далее.
Общее управление потоком
В рекомендациях 1.150 определяется использование поля GFC для управления
потоком ячеек на уровне интерфейса пользователь — сеть (User-to-Network Interface,
UNI) для борьбы с кратковременными перегрузками. Сам механизм борьбы с пе-
регрузками определен в рекомендации 1.361. Управление потоком GFC представ-
ляет собой часть системы управляемой передачи ячеек (Controlled Cell Transfer,
ССТ), предназначенной для удовлетворения требований локальных сетей, исполь-
зующих отличные от ATM технологии и соединенных с глобальной сетью ATM
[148]. В частности, технология ССТ должна обеспечивать приемлемые параметры
обслуживания для пульсирующего трафика с большим объемом данных и сооб-
щениями переменной длины. В оставшейся части данного подраздела мы рассмот-
рим стандартизированный механизм GFC.
Этот термин используется в документах ATM-форума. В документации ITU-T этотбит назван битом
индикации AAU (ATM — user-to-ATM — user — пользователь ATM — пользователю ATM). Смысл
этого бита тот же.
/
5.3. Ячейки ATM
129
Когда оборудование интерфейса пользователь — сеть поддерживает механизм
GFC, используется два набора процедур: неуправляемая передача и управляемая
передача. По сути, для каждого соединения указывается, допустимо в нем управ-
ление потоком или нет. По умолчанию управляемые соединения могут образовы-
вать одну группу (группа А) либо разделяться на две группы управляемых со-
единений (группа А и группа В). Эти модели называются, соответственно, моделью
с одной очередью и моделью с двумя очередями. Управление потоком осуществ-
ляется сетью в направлении от подписчика к сети.
Сначала мы рассмотрим работу механизма GFC при наличии всего одной груп-
пы соединений. Управляемое оборудование, называемое терминальным, инициа-
лизирует две переменных: переменная TRANSMIT (передача) представляет собой
флаг, устанавливаемый в 1, а переменная GO_CNTR является счетчиком кредита
и устанавливается в 0. Третьей переменной, GO VALUE, присваивается значе-
ние 1 (или больше) в процессе конфигурирования. Правила для терминального
оборудования перечислены ниже:
♦ Если TRANSMIT=1, то по неуправляемому соединению ячейки могут
пересылаться в любое время. Если TRANSMIT=0, то никакие ячейки не
могут пересылаться ни по неуправляемому, ни по управляемому соеди-
нению.
♦ Если от управляющего оборудования получен сигнал HALT, значение пе-
ременной TRANSMIT устанавливается равным 0 и остается нулевым до тех
пор, пока не будет получен сигнал NO_HALT, после чего значение перемен-
ной TRANSMIT устанавливается равным 1.
♦ Если TRANSMIT=1 и нет ячеек для передачи по неуправляемым соедине-
ниям, тогда:
♦ если GO_CNTR > 0, терминальное оборудование помечает ячейку как
предназначенную для передачи по управляемому соединению и умень-
шает на единицу значение счетчика GO_CNTR;
♦ если GO_CNTR = 0, терминальное оборудование не может посылать
ячейки по управляемому соединению.
♦ Получив сигнал SET, терминальное оборудование устанавливает значения
переменных GO_CNTR и GO_VALUE. Нулевое значение сигнала не ока-
зывает никакого эффекта па счетчик GO_CNTR.
Сигнал HALT используется логически для ограничения эффективной скоро-
сти передачи данных ATM и должен быть циклическим. Например, для снижения
скорости передачи данных по каналу вдвое управляющее оборудование может
генерировать команду HALT периодически, по предсказуемому регулярному гра-
фику, функционирующему в течение существования физического соединения.
Для модели с двумя очередями используются два счетчика, у каждого из ко-
торых есть текущее значение, а также значение, которым счетчик инициализиру-
ется: GO CNTR A, GO VALUE A, GO_CNTR_B и GO_VALUE_B. Это позво-
ляет NT2 управлять двумя раздельными группами соединений.
В табл. 5.1 обобщены правила установки битов GFC.
130
Глава 5. Сети ATM
5.3. Ячейки ATM
131
Таблица 5.1. Кодирование поля общего управления потоком (GFC)
Неуправ- ляемое соединение Управляющий управляемый Модель с одной очередью i -> Модель с двумя очередями Управляемый —> управляющий Модель с одной очередью Модель с двумя очередями
Первый бит 0 HALT(0)/NO_ HALT(1) HALT(0)/NO_ HALT(1) 0 0
Второй бит 0 SET(1)/ NULL(O) SET(1)/ NULL(O) для группы A Ячейка принадлежит управляемому(1)/ управляемому(О) Ячейка принадлежит группе А( 1)/ или нет(О)
Третий бит 0 0 SET(1)/ NULL(O) для группы В 0 Ячейка принадлежит группе В( 1)/ или нет(О)
Четвертый бит 0 0 0 Оборудование является неуправ- ляемым(О)/ управляемым^) Оборудование является неуправ- ляемым(О)/ управ- ляемым^)
Контрольная сумма заголовка
Каждая ячейка ATM включает 8-битовое поле контрольной суммы заголовка
(Header Error Control, НЕС), которое вычисляется по остальным 32 битам заголов-
ка. Для формирования кода используется многочлен Xs + X2 + X + 1. В большин-
стве существующих протоколов, включающих поле контрольной суммы, таких как
HDLC и LAPB, размер данных, служащих входными параметрами для вычисле-
ния контрольной суммы, как правило, значительно больше, чем размер результи-
рующей контрольной суммы. Это позволяет обнаружить ошибку. В случае ATM
входные 32 бита преобразуются в 8 бит на выходе. Тот факт, что входные данные
относительно короткие, позволяет использовать контрольную сумму не только для
обнаружения, но в некоторых случаях и для исправления ошибок. Это достигается
благодаря достаточному количеству избыточной информации в контрольной сумме.
На рис. 5.5 показана схема работы алгоритма НЕС у получателя. После ини-
циализации алгоритм исправления ошибок получателя находится в режиме по
умолчанию, заключающемся в исправлении однократных ошибок. При получении
каждой ячейки вычисляется контрольная сумма заголовка и сравнивается с содер-
жимым поля НЕС. Пока ошибки не обнаруживаются, алгоритм продолжает оста-
ваться в режиме исправления однократных ошибок. В случае обнаружения ошиб-
ки алгоритм исправляет однократную ошибку или, если ошибка произошла сразу
в нескольких битах, сигнализирует о неисправимой ошибке. В любом случае полу-
чатель перейдет в режим обнаружения ошибок. В этом режиме алгоритм не пред-
принимает попыток исправления ошибки. Такое поведение алгоритма связано
с тем, что ошибки часто группируются в пакеты, а для надежного исправления
ошибок 8-разрядного поля контрольной суммы явно недостаточно. Получатель
эстается в режиме обнаружения ошибок до тех пор, пока не будет получена ячейка
без ошибок. В этом случае получатель переключается обратно в режим исправле-
ния ошибок. Варианты действий с ячейкой показаны в виде блок-схемы на рис. 5.6.
Ошибки не обнаружено
(никаких действий
не предпринимается)
Обнаружена многократная
ошибка (ячейка отбрасывается)
Обнаружена ошибка
Режим
исправления
Режим
обнаружения
Ошибки не обнаружено
Обнаружена однократная
ошибка (исправление)
(ячейка отбрасывается)
(никаких действии
не предпринимается)
Рис. 5.5. Обработка контрольной суммы у получателя
Входящая ячейка
Корректная ячейка
(предусмотренная
услуга)
Видимо, корректная ячейка
с неверным заголовком
(непредусмотренная услуга)
Отброшенная
ячейка
Рис. 5.6. Результат ошибки в заголовке ячейки
132 Глава 5. Сети ATM
Функция защиты от ошибок обеспечивает как восстановление от однократных
ошибок, так и низкую вероятность доставки ячеек с ошибочными заголовками в
случае многократных ошибок. В системах оптоволоконной передачи встречаются
как однократные, так и многократные ошибки. В некоторых системах передачи
данных могут использоваться более сложные алгоритмы исправления ошибок.
На рис. 5.7, основанном на рисунке из рекомендации 1.432 сектора ITU-T, пока-
зано, как при использовании алгоритма НЕС случайные однократные ошибки влия-
ют на вероятность появления отброшенных ячеек и корректных ячеек с ошибочным
заголовком.
Рис. 5.7. Влияние случайных ошибок на производительность алгоритма НЕС
5.4. Категории служб ATM
Сеть ATM рассчитана на одновременный перенос трафика различных типов,
включая такие потоки реального времени, как речь, видеоизображение, а также
TCP-потоки с непостоянной скоростью передачи данных. Хотя каждый такой тра-
фик обрабатывается как поток 53-байтовых ячеек, передаваемый по виртуально-
му каналу, способ, которым управляется каждый поток данных, зависит от харак-
теристик потока и требований приложения. Например, видеотрафик реального
времени должен доставляться с минимальными вариациями задержки.
Мы рассмотрим способы управления различными типами трафика в сетя>
ATM в главе 13. В данном разделе мы кратко перечислим категории служб, исполь-
зуемые конечной системой для идентификации типа требуемой службы. ATM
форумом определены следующие категории служб: /
5.4. Категории служб ATM 133
> Службы реального времени:
♦ постоянная битовая скорость (Constant Bit Rate, CBR);
♦ переменная битовая скорость реального времени (real-time Variable Bit
Rate, rt-VBR).
4- Службы не реального времени:
♦ переменная битовая скорость не реального времени (non-real-time Variable
Bit Rate, nrt-VBR);
♦ доступная битовая скорость (Available Bit Rate, ABR);
♦ неуказанная битовая скорость (Unspecified Bit Rate, UBR);
♦ гарантированная скорость кадров (Guaranteed Frame Rate, GFR).
Службы реального времени
Самое главное различие между приложениями заключается в допустимых вели-
чинах задержки и вариации задержки, называемой флуктуацией (jitter). Прило-
жения реального времени, как правило, имеют дело с потоком данных, направляе-
мым пользователю, который должен воспроизводить этот поток приходящих от
источника данных. Например, пользователь ожидает, что поток аудио- и видеоин-
формации будет непрерывным и плавным. Значительная неравномерность или
большой процент потерянных кадров приведут к существенному снижению ка-
чества. Интерактивные приложения, напрямую общающиеся с пользователями,
обладают строгими ограничениями по задержке. Как правило, любая задержка,
превышающая несколько десятых секунды, становится заметной и раздражает
пользователя. Соответственно, в сети ATM предъявляются высокие требования
к коммутации и доставке данных реального времени.
Служба CBR
Служба CBR, видимо, представляет собой простейшую службу, какую только мож-
но определить. Она используется приложениями, которым требуется передача дан-
ных с фиксированной скоростью в течение существования соединения и жестким
ограничением сверху на длительность задержки. Служба CBR, как правило, ис-
пользуется для передачи несжатых аудио- и видеоданных. К примерам приложе-
ний CBR относятся:
♦ видеоконференции;
♦ интерактивный аудиообмен (например, телефония);
♦ аудио/видеовещание (например, телевидение, дистанционное обучение,
платные телевизионные каналы);
аудио/видеопоиск (например, видео по заказу, аудиобиблиотека).
Служба rt-VBR
Категория служб rt-VBR предназначена для приложений, чувствительных к вре
Менным параметрам, то есть для приложений с высокими требованиями к величи-
Йе и вариациям задержки. Основное отличие приложений, использующих службу
134
Глава 5. Сети ATM
rt-VBR, от CBR-приложений заключается в том, что приложения rt-VBR переда-
ют данные с непостоянной скоростью. Таким образом, источник данных rt-VBR
формирует пульсирующий трафик. Например, как мы увидим в главе 20, приме-
нение стандартных методов сжатия видеоданных приводит к формированию
последовательности кадров различного размера. Поскольку для видео реального
времени требуется постоянная скорость кадров, фактическая скорость передачи
данных оказывается непостоянной.
Служба rt-VBR обеспечивает сети большую гибкость, чем служба CBR. Сеть
может статически мультиплексировать несколько соединений по одному и тому
же выделенному ресурсу и, тем не менее, предоставлять требуемую службу каж-
дому соединению.
Службы не реального времени
Службы не реального времени предназначены для приложений, имеющих дело
с пульсирующим трафиком и не предъявляющих жестких требований к величине
и вариациям задержки. Соответственно, сети предоставляется большая свобода
действий в отношении подобного трафика, и она может лучше использовать ста-
тическое мультиплексирование для улучшения производительности.
Служба nrt-VBR
Для некоторых приложений не реального времени ожидаемый поток данных
таков, что сеть может обеспечить существенно более высокий уровень качества
обслуживания в области потери данных и задержки. Для подобных приложений
предусмотрена служба nrt-VBR. При ее использовании оконечные системы ука-
зывают максимальную скорость передачи ячеек, а также описывают, насколько
неравномерным может быть поток ячеек. С помощью этой информации сеть может
зарезервировать необходимые ресурсы, чтобы обеспечить относительно низкую
задержку и минимальную потерю ячеек.
Служба nrt-VBR может использоваться для передачи данных с критичными
требованиями ко времени отклика. Среди примеров можно назвать резервирова-
ние авиабилетов, банковские транзакции и мониторинг процессов.
Служба UBR
Службы CBR и два типа служб VBR в любой момент времени потребляют опре-
деленный объем сетевых ресурсов. Однако есть две причины, по которым в сети
могут оставаться неиспользуемые ресурсы. Во-первых, если не все сетевые ре-
сурсы были выделены для трафиков CBR и VBR, и во-вторых, благодаря не-
равномерности трафика VBR. Все неиспользованные ресурсы могут быть предос-
тавлены для службы UBR. Эта служба годится для приложений, допускающих
значительные задержки и потерю некоторых ячеек, что, как правило, характерно
для TCP-трафика. Служба UBR доставляет ячейки на основе правила FIFO (First
In First Out
— первым прибыл, первым обслужен), задействуя ресурсы,
не заня
тые другими службами. При этом возможны как задержки в доставке, так и пот»
5.4. Категории служб ATM
135
ри ячеек. Источник трафика U BR не получает никаких гарантий, также не обеспе-
чивается обратной связи в случае перегрузки — подобную схему обычно называ-
ют обслуживанием с максимальными усилиями (best-effort service). Примеры при-
ложений UBR:
4- обмен текстом, данными или изображениями;
♦ удаленный терминал (то есть общение на расстоянии).
Служба ABR
Приложения с неравномерным трафиком, использующие надежный сквозной про-
токол, например TCP, могут обнаружить наличие перегрузки в сети по возросше-
му времени прохождения сигнала в оба конца и потерянным пакетам. Эта тема
обсуждается в главе 12. Однако протокол TCP не обладает механизмом, при по-
мощи которого сетевые ресурсы можно было справедливо распределить между
различными TCP-соединениями. Более того, протокол TCP не может эффектив-
но минимизировать нагрузку, даже имея информацию, полученную от перегру-
женных узлов сети.
Для улучшения качества обслуживания приложений, генерирующих неравно-
мерный трафик, определена служба ABR. Приложение, пользующееся службой
ABR, указывает максимальную и минимальную скорости передачи данных, кото-
рые ему потребуются. Эти скорости называются, соответственно, пиковой скорос-
тью ячеек (Peak Cell Rate, PCR) и минимальной скоростью ячеек (Minimum Cell
Rate, MCR). Сеть резервирует ресурсы таким образом, чтобы все ABR-прило-
жения получили, по меньшей мере, ресурсы, соответствующие указанным ими
значениям MCR. Затем все свободные ресурсы справедливым образом распреде-
ляются между всеми пользователями ABR. Механизм ABR использует явную
обратную связь с источниками, гарантируя справедливое распределение ресурсов.
Все ресурсы, не занятые источниками ABR, остаются доступными для UBR-
трафика.
Примером приложения, использующего службу ABR, является соединение
локальных сетей. В этом случае конечными системами, присоединенными к сети
ATM, являются маршрутизаторы.
На рис. 5.8 схематично показано распределение ресурсов, если состояние сети
не меняется (нет добавления и удаления виртуальных каналов).
Рис. 5.8. Службы битовой скорости ATM
136
Глава 5. Сети ATM
Служба GFR
Последней к набору категорий служб ATM была добавлена служба GFR, разрабо-
танная специально для поддержки подсетей IP-магистрали. Для трафика кадров,
включая IP и Ethernet, служба GFR предоставляет лучшее качество обслужива-
ния, чем UBR. Основное назначение службы GFR заключается в оптимизации
управления трафиком кадров, проходящим от локальной сети через маршрутиза-
тор в магистральную сеть ATM. В последнее время такие сети ATM все чаще ис-
пользуются на больших предприятиях, а также в сетях операторов связи и постав-
щиков услуг Интернета для объединения IP-служб на большой территории. Хотя
ABR представляет собой службу ATM, предназначенную для обеспечения боль-
шей производительности с гарантированной доставкой пакетов по магистралям
ATM, службу ABR довольно трудно реализовать между маршрутизаторами сети
ATM. Учитывая все возрастающую роль ATM в поддержке IP-трафика, особенно
трафика, исходящего из локальных сетей Ethernet, служба GFR может предложить
наиболее привлекательную альтернативу службы ATM.
Один из методов, используемых службой GFR для обеспечения более высокой
производительности по сравнению со службой UBR, заключается в требовании
того, чтобы элементы сети знали о границах пакетов, или кадров. Таким образом,
в случае возникновения перегрузки элемент сети может отвергнуть не произволь-
ные ячейки, а все ячейки, относящиеся к одному пакету. Служба GFR также по-
зволяет пользователю резервировать ресурсы для каждого виртуального канала
GFR. Пользователь получает гарантию, что минимальная требуемая производи-
тельность будет поддерживаться, а дополнительные кадры могут передаваться по
сети, если сеть не перегружена.
5.5. Уровень адаптации ATM
В результате использования ATM возникает необходимость в уровне адаптации
ATM (ATM Adaptation Level, AAL) для поддержки протоколов передачи инфор-
мации, не относящихся к технологии ATM. Среди примеров можно назвать циф-
ровую телефонию и протокол LAPF (Link Access Procedure for Frame mode bearer
services — процедура доступа к каналу для канальных служб в режиме кадров).
Цифровая телефония представляет собой приложение, формирующее поток би-
тов от голосового источника сигнала. Чтобы это приложение могло функциони-
ровать в сети ATM, нужно сгруппировать биты в ячейки для передачи, азатем про-
читать их па принимающей стороне таким образом, чтобы снова сформировать из
них непрерывный постоянный поток битов. Протокол LAPF представляет собой
стандартный протокол передачи данных для ретрансляции кадров. В смешанном
окружении, в котором сети ретрансляции кадров соединены с сетями ATM,
простой способ интеграции двух сетей заключается в преобразовании кадров
LAPF в ячейки ATM. Как правило, при передаче это означает разбиение одного
кадра LAPF на несколько ячеек и восстановление кадра из этих ячеек при полу-
чении. Применение протокола LAPF поверх сети ATM позволяет использовать
в сетях ATM все существующие приложения для ретрансляции кадров, а такж^
управляющие сигнальные протоколы. /'
5.5. Уровень адаптации ATM
137
« Службы AAL
В рекомендации 1.362 сектора ITU-T перечислены несколько обобщенных приме-
ров служб, предоставляемых уровнем AAL:
♦ Обработка ошибок передачи.
4- Сегментация и повторная сборка для передачи больших блоков данных.
4 Обработка ситуаций потери и неверной доставки ячеек.
4 Управление потоком и синхронизация.
Чтобы минимизировать количество стандартизируемых протоколов AAL, сек-
тор ITU-T определил четыре класса служб, охватывающих широкий спектр тре-
бований. Классификация основывалась на следующих положениях:
4 требуется ли синхронизация источника и приемника;
4 требуется ли приложению постоянная битовая скорость;
4 требуется ли устанавливать соединение для передачи данных или возмож-
на передача без установления соединения.
Систему классификации уже нельзя найти в документах сектора ITU-T, но кон-
цепция была использована для разработки протоколов AAL. По сути, уровень AAL
предоставляет механизмы для отображения на уровень ATM широкого спектра
приложений, а также предоставляет протоколы, построенные поверх средств
управления трафиком уровня ATM. Следовательно, устройство протоколов AAL
должно соответствовать категориям служб, обсуждавшихся в разделе 5.4.
В табл. 5.2 (см. [151]) показано соответствие четырех протоколов AAL катего-
риям служб, определенным ATM-форумом. Элементами таблицы являются пе-
речисленные ниже типы приложений, поддерживаемых совместными усилиями
ATM и AAL:
♦ Эмуляция канала. Относится к поддержке синхронных структур мульти-
плексирования с временным разделением (Time Division Multiplexing, TDM),
таких как Т-1 поверх сети ATM.
♦ Службы VBR для передачи аудио- и видеоданных. Это приложения реально-
го времени, в которых данные передаются в сжатом формате и для которых
в связи с этим требуется переменная битовая скорость.
♦ Общие службы данных. К ним относятся службы передачи сообщений и
службы транзакций, которым не требуется обслуживание в реальном
времени.
♦ IP поверх ATM. Передача IP-пакетов в ячейках ATM.
♦ Многопротокольная инкапсуляция поверх ATM (MultiProtocol encapsulation
Over ATM, МРОА). Поддержка поверх ATM широкого спектра протоколов,
отличных от IP (например, IPX, AppleTalk, DECNET).
♦ Эмуляция локальной сети. Поддержка обмена данными между локальными
ц сетями по сети ATM с эмуляцией способности локальной сети к широкове-
щательной рассылке (сообщение, посланное одной станцией, принимается
многими другими станциями).
138
Глава 5. Сети ATM
Таблица 5.2. Протоколы и службы AAL
CBR rt-VBR n rt-VBR ABR UBR
AAL1 Эмуляция канала, ISDN, цифровая телефония AAL2 AAL3/4 VBR речь и видео Общие службы данных
AAL 5 Эмуляция локальной сети Голос по запросу, эмуляция локальной сети Ретрансляция кадров, ATM, эмуляция локальной сети Эмуляция локальной сети IP поверх ATM
Протоколы AAL
Для поддержки различных классов служб был определен набор протоколов на
уровне AAL. Уровень AAL разбивается на два подуровня: подуровень конвер-
генции (Convergence Sublayer, CS) и подуровень сегментации и восстановления
(Segmentation And Reassembly sublayer, SAR). Подуровень конвергенции предо-
ставляет функции, требующиеся для поддержания специфичных для уровня AAL
приложений. Каждый пользователь AAL соединяется с уровнем AAL в точке до-
ступа к службе (Service Access Point, SAP), представляющей собой просто адрес
приложения. Таким образом, этот подуровень зависит от службы.
Подуровень SAR отвечает за упаковку информации, получаемой от подуровня
CS, в ячейки при передаче и распаковке информации на другом конце. Как мы
видели, на уровне ATM каждая ячейка состоит из 5-байтового заголовка и 48-бай-
тового информационного поля. Таким образом, подуровень SAR должен упаковать
заголовки и концевики SAR, а также данные уровня CS в 48-байтовые блоки.
На рис. 5.9 показана обобщенная архитектура протокола для ATM и AAL. Как
правило, блок данных высокого уровня инкапсулируется в один протокольный
модуль данных, состоящий из данных верхнего уровня и, возможно, заголовка и
концевика, содержащих протокольную информацию подуровня CS. Затем этот
протокольный модуль данных подуровня CS передается подуровню SAR и разби-
вается на несколько блоков. Каждый такой блок помещается в один 48-байтовый
протокольный модуль данных подуровня SAR, в который кроме блока данных,
полученного от подуровня CS, могут также входить заголовок и концевик. Нако-
нец, каждый протокольный модуль данных подуровня SAR образует поле полез-
ной нагрузки для одной ячейки ATM.
Изначально сектор ITU-T определил по одному типу протокола для каждого клас-
са службы и назвал их от типа 1 (Туре 1) до типа 4 (Туре 4). В действительности
каждый тип протокола состоит из двух протоколов, одного на подуровне CS и одного
на подуровне SAR. Позднее типы 3 и 4 были объединены в тип 3/4, а также добавлен
новый тип 5. В табл. 5.3 перечислены определенные на данный момент функциональ-
ные детали получившихся четырех типов. Во всех этих случаях блок данных верхне-
го уровня инкапсулируется в модуль данных на подуровне конвергенции, который
фактически называют подуровнем CPCS (Common Part Convergence Sublayer —
общая часть подуровня конвергенции), оставляя открытой возможность выпол-
нения дополнительных специализированных функций на подуровне CS. Затем
5.5. Уровень адаптации ATM
139
протокольный модуль данных подуровня CPCS передается подуровню SAR, где
он разбивается на блоки. Каждый блок может соответствовать одному протокольно-
му модулю данных подуровня SAR с полной длиной 48 байт. Каждый 48-байтовый
протокольный модуль данных подуровня SAR помещается в одной ячейке ATM.
э
Пользователь AAL
ч - ПодуРовень
конвергенции (CS)
Подуровень
| сегментации
и восстановления
*<" ' (SAR)
Ячейка ATM Ячейка ATM Ячейка ATM Ячейка ATM
Уровень ATM
Физический
уровень
Рис. 5.9. Протоколы и модули данных уровня AAL
Таблица 5.3. Типы протоколов AAL
Тип Предоставляемые службы Общие функции Функции SAR Функции CS
1 Передача модулей данных с постоянной битовой скоростью; синхронизация отправителя и получателя; обмен информацией о структуре между отправителем и получателем; индикация потерянной или поврежденной информации, не восстанавливаемой средствами типа 1 Сегментация и восстановление; обработка вариаций задержки ячейки; обработка задержки сборки данных ячеек; обработка потерянных и неверно доставленных ячеек; синхронизация часов у получателя; восстановление исходной структуры данных у получателя; мониторинг и обработка однократных ошибок PCI; мониторинг информации пользователя на предмет обнаружения однократных ошибок и аозможных действий по их исправлению Преобразование модулей данных подуровней CS и SAR; индикация существования функции CS; порядковая нумерация; защита от ошибок Обработка вариаций задержки ячейки; обработка потерянных и неверно доставленных ячеек; для некоторых служб синхронизация часов у получателя; перенос структурной информации; исправление ошибок доставки для аудио- и видеоданных высокого качества; сквозные сообщения о состоянии производительности
продолжение &
140
Глава 5. Сети ATM
Таблица 5.3 {продолжение)
Тип П редоста вляе мы е службы Общие функции Функции SAR Функции CS
2 Перенос модулей Сегментация Исследования Исследования
данных с переменной битовой скоростью; синхронизация отправителя и получателя; индикация потерянной или поврежденной информации, не восстанавливаемой средствами типа 2 и восстановление; продолжаются обработка вариаций задержки ячейки; обработка потерянных и неверно доставленных ячеек; синхронизация у получателя; восстановление исходной структуры данных у получателя; мониторинг и обработка однократных ошибок в заголовке и концевике; мониторинг информации пользователя на предмет обнаружения однократных ошибок и возможных действий по их исправлению продолжаются
3/4 Служба потокового режима; гарантированная операция; негарантированная операция Сегментация и повторная сборка; обнаружение ошибок; сохранение очередности доставки; мультиплек- сирование Обнаружение и обработка ошибок; индикация размера буфера
5 Служба режима сообщений; служба потокового режима; гарантированная операция; негарантированная операция Сегментация и повторная сборка; обработка информации о перегрузке; обработка информации о приоритете потерь Обнаружение и обработка ошибок; заполнение; обработка информации о перегрузке; обработка информации о приоритете потерь
На рис. 5.10 показаны форматы модулей данных на подуровне SAR (кроме
типа 2, который пока не определен) с использованием следующих обозначений:
♦ SN (Sequence Number) — последовательный номер (4 бита);
♦ SNP (Sequence Number Protection) — защита последовательного номера
(4 бита);
♦ ST (Segment Type) — тип сегмента (2 бита);
♦ MID (Multiplexing IDentification) — идентификатор мультиплексирования
(10 бит);
5.5. Уровень адаптации ATM
141
♦ LI (Length Indication) — индикация длины (6 бит);
♦ CRC (Cyclic Redundancy Check) — контроль с помощью циклического из-
быточного кода (10 бит).
Заголовок 2 байта
44 байта
Тип 3/4 уровня AAL
б
Концевик 2 байта
48 байт
Тип 5 уровня AAL
в
Рис. 5.10. Протокольные модули данных подуровня SAR
Тип 1 уровня AAL
Службы типа 1 имеют дело с источником данных, посылающим их с постоянной
скоростью. В этом случае протоколу SAR нужно только упаковать биты в ячейки
для передачи и распаковать их при приеме. Каждый блок сопровождается поряд-
ковым номером (Sequence Number, SN), что позволяет отслеживать поврежденные
модули данных. 4-битовое поле порядкового номера состоит из бита индикации
подуровня конвергенции (Convergence Sublayer Indication, CSI), а также 3-бито-
вого порядкового счетчика (Sequence Count, SC). При передаче подуровень CS
предоставляет подуровню SAR значение бита CSI, которое нужно поместить в поле
SN. При приеме подуровень SAR передает это значение вверх подуровню CS. Бит
CSI используется для обмена информацией следующим образом: 3-битовый по-
рядковый номер определяет структуру кадра из 8 последовательных ячеек ATM,
пронумерованных от 0 до 7. Значения бита CSI в четырех последовательных ячей-
ках с нечетными номерами интерпретируются как 4-битовые значения синхро-
низации. Эти значения используются для предоставления разницы частот между
сетевыми эталонными часами и часами отправителя. В четных ячейках бит CSI
может использоваться для разбиения на блоки информации, получаемой от более
высокого уровня. Если бит CSI установлен в единицу в четной ячейке (0, 2, 4, 6),
тогда первый байт поля полезной нагрузки модуля данных подуровня SAR пред-
ставляет собой указатель на начало следующего структурного блока в поле по-
лезной нагрузки текущей и следующей ячеек. Таким образом, пары ячеек (0—1,2—3,
^~5, 6—7) содержат однобайтовый указатель и 93-байтовую полезную нагрузку,
142
Глава 5. Сети ATM
а указатель определяет, где среди этих 93 байт находится первый байт следую-1
щего блока данных. Значение смещения 93 требуется, чтобы указать, что конец
93-байтовой полезной нагрузки совпадает с концом структурного блока. Смеще-
ние 127 применяется, когда структурная граница не указана.
3-битовое поле SC, как мы только что видели, обеспечивает структуру кадра из
8 ячеек. Оно также предоставляет средство обнаружения потерянных или невер-
но доставленных ячеек.
Поле защиты порядкового номера (Sequence Number Protection, SNP) представ-
ляет собой код, обеспечивающий обнаружение ошибок в поле порядкового номера,
а также, возможно, их исправление. Оно состоит из 3-битового поля CRC, рассчи-
тываемого на основании 4-битового поля SN и бита четности. Бит четности уста-
навливается таким образом, чтобы сумма 8-битового заголовка S AR была четной.
Для службы типа 1 протокольного модуля данных не определено. Функции
подуровня CS для типа 1 в первую очередь должны заниматься синхронизацией,
поэтому отдельный заголовок подуровня CS не требуется.
Тип 2 уровня AAL
Оставшиеся типы протоколов (2, 3/4 и 5) имеют дело с переменной битовой ско-
ростью. Тип 2 предназначен для аналоговых приложений, таких как приложения
передачи видео- и аудиоданных, которым требуется синхронизация, но не требу-
ется постоянная битовая скорость. Изначальная спецификация протоколов типа 2
(SAR и CS) была аннулирована, а текущая версия, определенная в рекомендациях
1.363 сектора ITU-T, просто перечисляет службы и функции (см. табл. 5.3).
Тип 3/4 уровня AAL
Оригинальные спецификации типа 3 и 4 уровня AAL были очень близки функцио-
нально и в плане формата модуля данных. Соответственно, члены ITU-T решили
объединить их в одну спецификацию протокола на подуровнях SAR и CS, извест-
ную сегодня как тип 3/4.
Типы служб, предоставляемых типом 3/4 уровня AAL, можно рассматривать
в двумерном пространстве параметров:
♦ Служба может не требовать или требовать установления соединения. В пер-
вом случае каждый блок данных, передаваемый подуровню S AR, обрабаты-
вается независимо. Во втором случае можно определить несколько логичес-
ких соединений подуровня SAR поверх одного соединения ATM.
+ Служба может работать в режиме передачи сообщений и в потоковом режи-
ме. Служба режима сообщений переносит разбитую на кадры информацию.
Таким образом, любой из протоколов и приложений OSI попадает в эту ка-
тегорию. В частности, протокол LAPF или ретрансляция кадров представ-
ляет собой службу режима сообщений. Одиночный блок данных с уровня
выше AAL переносится в одной или нескольких ячейках. Служба потоково-
го режима поддерживает низкоскоростную передачу непрерывных данных,
к которой предъявляются требования маленькой задержки. Данные пре-
доставляются уровню AAL в виде блоков фиксированной длины, начиная
от одного байта.
5.5. Уровень адаптации ATM
143
Тип 3/4 уровня AAL предоставляет услуга по передаче данных, принимая ин-
формационные блоки от следующего верхнего уровня и передавая каждый блок
пользователю уровня AAL. Поскольку уровень ATM ограничивает размер поля
полезной нагрузки 48 байтами, уровень AAL должен, как минимум, предоставлять
функции сегментации и восстановления.
Методы, используемые типом 3/4, иллюстрирует рис. 5.11. Блок данных с более
высокого уровня, например протокольный модуль данных, инкапсулируется в мо-
дуль данных подуровня CPCS. Затем модуль данных подуровня CPCS передает-
ся подуровню SAR, где он разбивается на 44-байтовые блоки. Каждый такой блок
помещается в один модуль данных подуровня SAR, к которому добавляются заго-
ловок и концевик, так что общая длина составляет 48 байт. Каждый 48-байтовый
модуль данных подуровня SAR помещается в одну ячейку ATM. На рисунке ис-
пользуются следующие обозначения:
♦ CPCS (Common Part Convergence Sublayer) — общая часть подуровня кон-
вергенции;
♦ SAR (Segmentation And Reassembly sublayer) — подуровень сегментации и
восстановления;
Рис. 5.11. Пример передачи типа 3/4 уровня AAL
144
(лава 5. Сети ATM
♦ PDU (Protocol Data Unit) — протокольный модуль данных;
4 CPCS-H (CPCS header) — заголовок CPCS;
4 CPCS-T (CPCS trailer) — концевик CPCS;
4 SAR-H (SAR header) — заголовок SAR;
4 SAR-T (SAR trailer) — концевик SAR;
4 ATM-H (ATM header) — заголовок ATM;
4 BOM (Beginning Of Message) — начало сообщения;
4 COM (Continuation Of Message) — продолжение сообщения;
4 EOM (End Of Message) — конец сообщения.
Чтобы понять функционирование двух подуровней типа 3/4 уровня AAL, рас-
смотрим соответствующие модули данных. Модуль данных подуровня CPCS типа
3/4 показан на рис. 5.12, а, на котором используются следующие обозначения:
4 CPI (Common Part Indicator) — индикатор общей части (1 байт);
4 Btag (Beginning tag) — начальный тег (1 байт);
4 BAS (Buffer Allocation Size) — размер буфера (2 байта);
4 AL (ALignment) — выравнивание (1 байт);
4 Etag (End tag) — конечный тег (1 байт);
4 CPCS-UU — (CPCS User-to-User indication) — сквозной индикатор под-
уровня CPCS (1 байт);
4 CRC (Cyclic Redundancy Check) — контроль с помощью циклического из-
быточного кода (4 байта).
Полезная нагрузка PDU подуровня CPCS Заполнитель Концевик PDU подуровня CPCS
CPCS-UU CPI Длина CRC
б
Рис. 5.12. Протокольный модуль данных CPCS
5.5. Уровень адаптации ATM
145
Заголовок модуля данных типа 3/4 подуровня CPCS состоит из трех полей,
которые перечислены далее:
♦ Индикатор общей части (1 байт). Обеспечивает интерпретацию остальных
полей в заголовке протокольного модуля данных CPCS. На сегодняшний
день определен один вариант интерпретации.
♦ Начальный тег (1 байт). Номер, ассоциированный с определенным прото-
кольным модулем данных CPCS. Одно и то же значение появляется в поле
начального тега (Btag) заголовка и в поле конечного тега (Etag) концевика.
Отправитель изменяет значение в каждом последующем протокольном мо-
дуле данных CPCS, что позволяет получателю корректно распознать заго-
ловок и концевик каждого протокольного модуля данных CPCS.
♦ Размер буфера (2 байта). Указывает получающей одноранговой сущности
максимальный размер буфера, необходимый для восстановления сегменти-
рованного служебного модуля данных (Service Data Unit, SDU) подуровня
CPCS. В режиме сообщений это значение равно длине протокольного мо-
дуля данных (Protocol Data Unit, PDU) подуровня CPCS. В потоковом ре-
жиме это значение больше или равно длине поля полезной нагрузки прото-
кольного модуля данных CPCS.
Полезная нагрузка, получаемая от более высокого уровня, дополняется до дли-
ны, кратной 32 битам. Концевик протокольного модуля данных CPCS содержит
следующие поля:
♦ Выравнивание (1 байт). Байт-заполиитель, единственное предназначение
которого заключается в том, чтобы длина протокольного модуля данных
CPCS была равна 32 битам.
♦ Конечный тег (1 байт). Используется совместно с полем начального тега за-
головка.
♦ Длина (2 байта). Длина поля полезной нагрузки протокольного модуля дан-
ных CPCS.
Таким образом, назначение подуровня CPCS заключается в предупреждении
получателя о том, что получаемый блок данных сегментирован и для его восста-
новления требуется буфер. Это позволяет получающим функциям CPCS прове-
рить правильность приема целого протокольного модуля данных CPCS.
Формат протокольного модуля данных для типа 3/4 подуровня SAR был пока-
зан на рис. 5.10, б. Информация со следующего верхнего уровня (подуровня CS)
прибывает в блоках, называемых служебными модулями данных (SDU) подуров-
ня SAR. Каждый служебный модуль данных передается в одном или нескольких
протокольных модулях данных (PDU) подуровня SAR. Каждый протокольный
Модуль данных, в свою очередь, передается в одной ячейке ATM. Поля заголовка
Протокольного модуля данных подуровня SAR используются для сегментации
служебных модулей данных при передаче и их восстановления при приеме.
♦ Тип сегмента. Существует четыре типа протокольных модулей данных под-
уровня SAR. Одиночное последовательное сообщение (Single Sequence
Message, SSM) содержит целый служебный модуль данных подуровня S AR.
Если служебный модуль данных разбит на два или более протокольных
146
Глава 5. Сети ATM
модулей данных подуровня SAR, то первый протокольный модуль данных
представляет собой начало сообщения (Beginning Of Message, BOM), пос-
ледний протокольный модуль данных является концом сообщения (End Of
Message, ЕОМ), а все промежуточные протокольные модули данных назы-
вают продолжением сообщения (Continuation Of Message, COM).
Порядковый номер используется при восстановлении сегментированного
служебного модуля данных подуровня SAR для проверки, что все прото-
кольные модули данных подуровня SAR получены и корректно состыкова-
ны друг с другом. Значение порядкового номера устанавливается в начале
сообщения (ВОМ) и увеличивается на единицу в каждом последующем про-
должении сообщения (СОМ) и в конце сообщения (ЕОМ) для каждого слу-
жебного модуля данных подуровня SAR.
♦ Идентификатор сообщения. Это уникальный идентификатор, назначаемый
набору протокольных модулей данных подуровня SAR, переносящих один
служебный модуль данных. Этот идентификатор требуется для корректно-
го восстановления сегментированного модуля данных.
Ниже перечислены поля концевика протокольного модуля данных подуров-
ня SAR:
♦ Индикатор длины определяет число байтов сегментированного служебного
модуля данных подуровня SAR, занимающих протокольный модуль данных
подуровня SAR. Это число может принимать значения от 4 до 44 байт и дол-
жно быть кратно 5. Для протокольных модулей данных подуровня SAR,
представляющих собой начало сообщения (ВОМ) и продолжение сообще-
ния (СОМ), это значение всегда равно 44. Если длина служебного модуля
данных меньше 44 байт, то это поле содержит меньшее число в одиночном
последовательном сообщении (SSM). Если длина служебного модуля дан-
ных не кратна 44 байтам, то это поле содержит меньшее число в конце сооб-
щения (ЕОМ). В этом случае остаток поля полезной нагрузки служебного
модуля данных дополняется заполнителем.
♦ CRC — это 10-битовый циклический избыточный код всего служебного мо-
дуля данных подуровня SAR.
Отличительная особенность типа 3/4 уровня AAL заключается в том, что он
может мультиплексировать различные потоки данных в одном виртуальном со-
единении ATM. Для службы, ориентированной на соединение, каждому логичес-
кому соединению между пользователями AAL назначается уникальное значение
идентификатора MID. Таким образом, по одному соединению ATM можно муль-
типлексировать до 210 различных соединений AAL. Для службы, не требующей
соединения, поле MID может использоваться для уникального идентификатора,
ассоциированного с каждым пользователем службы. При этом трафик нескольких
пользователей AAL также может мультиплексироваться.
Тип 5 уровня AAL
Тип 5 уровня AAL был разработан для предоставления ориентированным на со*
единение протоколам более высокого уровня упрощенной транспортной служб/
Предполагается, что соединением управляет более высокий уровень и что уроь у
5.5. Уровень адаптации ATM
147
ATM создает минимум ошибок, так что большинство полей в протокольных мо-
дулях данных подуровней SAR и CPCS не затребовано. Например, при использо-
вании ориентированной на соединение службы поле MID не требуется. Для типа
3/4 уровня AAL с помощью этого поля выполняется мультиплексирование раз-
личных потоков данных в одном виртуальном соединении ATM. Для типа 5 уров-
ня AAL предполагается, что подобное мультиплексирование обеспечивает про-
граммное обеспечение более высокого уровня.
Тип 5 был разработан:
♦ для уменьшения накладных расходов протокола по обработке;
♦ снижения накладных расходов при передаче данных;
♦ обеспечения адаптируемости к существующим транспортным протоколам.
На рис. 5.10, в и рис. 5.12, б показаны форматы протокольных модулей данных
типа 5 подуровней SAR и CPCS. Сравнение накладных расходов для типов 3/4 и 5
дано в табл. 5.4.
Таблица 5.4. Сравнение накладных расходов для типа 3/4 и типа 5
Тип 3/4 Тип 5
8 байт на служебный модуль 8 байт на служебный модуль
данных уровня AAL данных уровня AAL
4 байта на ячейку ATM 0 байт на ячейку ATM
Чтобы понять, как работает тип 5, начнем с подуровня CPCS. Протокольный
модуль данных подуровня CPCS (см. рис. 5.12, б) включает концевик со следую-
щими полями:
♦ Сквозной индикатор подуровня CPCS (1 байт) используется для прозрачной
передачи информации от пользователя пользователю.
♦ Индикатор общей части (1 байт) задает интерпретацию остальных полей
концевика протокольного модуля данных подуровня CPCS. На сегодняш-
ний день определен только один вариант интерпретации.
♦ Длина (2 байта). Длина поля полезной нагрузки протокольного модуля дан-
ных подуровня CPCS.
♦ CRC (4 байта) используется для обнаружения ошибок в протокольном мо-
дуле данных CPCS.
Обратите внимание на то, что поле «Размер буфера» больше не используется.
Если получатель должен зарезервировать под буфер память для сборки сегменти-
рованного модуля данных, то информацию об этом следует передавать получателю
на более высоком уровне. В самом деле, многие протоколы более высокого уровня
Договариваются о максимальном размере протокольного модуля данных. Эта инфор-
мация может быть использована получателем для резервирования буферов. 32-раз-
рядное поле CRC защищает весь протокольный модуль данных CPCS, тогда как
10-битовое поле CRC для типа 3/4 уровня AAL предоставляется для каждого про-
токольного модуля данных SAR. Циклический избыточный код для типа 5 обеспе-
чивает надежную защиту от однократных ошибок. Кроме того, как показано в [230],
148
Глава 5. Сети ATM
32-разрядный циклический избыточный код обеспечивает надежное обнаружение
неверно доставленных ячеек, что возможно при неустойчивой работе сети.
Поле полезной нагрузки более высокого уровня дополняется таким образом,
чтобы размер протокольного модуля данных CPCS был кратен 48 байтам. Прото-
кольный модуль данных S AR состоит просто из 48 байт полезной нагрузки, содер-
жащей часть протокольного модуля данных CPCS. Снижение накладных расхо-
дов протокола требует учитывать следующее:
♦ Из-за отсутствия порядковых номеров получатель должен исходить из пред-
положения, что все протокольные модули данных SAR прибывают в пра-
вильном порядке. Убедиться в этом поможет поле CRC протокольного мо-
дуля данных CPCS.
♦ Отсутствие поля идентификатора MID означает, что ячейки от различных
протокольных модулей данных CPCS при передаче не могут перемешивать-
ся. Поэтому каждый протокольный модуль данных SAR переносит часть
текущего протокольного модуля данных CPCS или первый блок следующего
протокольного модуля данных CPCS. Для распознавания этих двух слу-
чаев используется бит типа служебного модуля данных ATM в поле типа
полезной нагрузки заголовка ячейки ATM (см. рис. 5.4). Протокольный
модуль данных CPCS состоит из нуля или более последовательных про-
токольных модулей данных SAR (в которых бит типа служебного модуля
данных установлен в 0), непосредственно следующих за протокольным
модулем данных SAR, в котором бит типа служебного модуля данных
установлен в 1.
♦ Отсутствие поля LI (Length Indication — индикатор длины) означает, что
сущность подуровня SAR не может отличить байты протокольного модуля
данных CPCS от заполнителей в последнем протокольном модуле данных
S AR. Чтобы избежать такой ситуации, поле полезной нагрузки каждого про-
токольного модуля данных CPCS должно дополняться таким образом, что-
бы последний бит концевика CPCS был последним битом последнего про-
токольного модуля данных SAR.
Рисунок 5.13 иллюстрирует процесс передачи для типа 5 уровня AAL. Про-
токольный модуль данных CPCS, включая заполнитель и концевик, делится на
48-байтовые блоки. Каждый блок передается в отдельной ячейке ATM. На рисунке
используются следующие обозначения:
♦ CPCS (Common Part Convergence Sublayer) — общая часть подуровня кон-
вергенции;
♦ SAR (Segmentation And Reassembly sublayer) — подуровень сегментации и
восстановления;
♦ PDU (Protocol Data Unit) — протокольный модуль данных;
4 CPCS-T (CPCS Trailer) — концевик CPCS;
♦ ATM-H (ATM Header) — заголовок ATM;
♦ SDU (Service Data Unit type bit) — бит типа служебного модуля данных, у
5.6. Рекомендуемые литература и веб-сайты 149
Ячейка
ATM
PDU
подуровня
CPCS
PDU
подуровня
SAR
PDU
подуровня
SAR
PDU
подуровня
SAR
PDU
подуровня
SAR
Рис. 5.13. Передача типа 5 уровня AAL
5.6. Рекомендуемые
литература и веб-сайты
В [151] и [30] довольно подробно описывается технология ATM. Методы вирту-
альных каналов и виртуальных путей исследуются в [195], [196] и [42].
В [91] предоставляется логическое обоснование для категорий служб ATM,
а также обсуждается управление трафиком для каждой из них. В [12] и [219] рас-
сказывается об уровне AAL и сравниваются типы 3/4 и 5.
Ниже перечислены рекомендуемые веб-сайты:
♦ ATM Hot Links. Отличная коллекция официальных документов и ссылок,
которую содержит университет штата Миннесота.
♦ ATM Forum. Технические спецификации, официальные документы и доступ-
ные в режиме подключения (on-line) копии публикаций АТМ-форума.
♦ Cell Relay Retreat. Архивы списка рассылки ретрансляции ячеек, ссылки на
многочисленные документы, имеющие отношение к ATM, а также ссылки
на множество веб-сайтов, связанных с ATM.
150
Глава 5. Сети ATM
5.7. Задания
1. Перечислите все 16 возможных значений поля GFC и дайте интерпретацию
каждого значения (некоторые значения недопустимы).
2. Один из методов передачи ячеек ATM соответствует непрерывному потоку
ячеек, в котором отсутствует разбиение на кадры. Таким образом, передает-
ся просто поток битов, в котором все биты являются частью ячеек. Посколь-
ку внешнего кадра нет, требуется некоторая другая форма синхронизации,
которая достигается при помощи функции НЕС. Нужно обеспечить, чтобы
получатель знал, где находятся начало и конец ячеек, и не терял синхрони-
зации с отправителем. Нарисуйте диаграмму состояний для использования
функции НЕС в целях синхронизации ячеек и объясните, как она работает.
3. При разработке технологии ATM ключевым был выбор между ячейками
фиксированной и переменной длины. Рассмотрим этот вопрос с точки зре-
ния эффективности. Мы можем определить эффективность передачи дан-
ных следующим образом:
Количество байтов информации
п --------------------------------------------------------
Количество байтов информации + Количество накладных байтов
а) рассмотрите использование пакетов фиксированной длины. В данном слу-
чае накладные расходы дают байты заголовка. Пусть L — размер поля дан-
ных ячейки в байтах; Н — размер заголовка ячейки в байтах; X — количе-
ство байтов информации, которые должны быть переданы в виде одного
сообщения. Выведите формулу для п. Подсказка: в формуле потребуется
использовать оператор получения наименьшего или равного значения;
б) если размер ячеек не фиксирован, тогда накладные расходы определя-
ются заголовком, а также флагами, определяющими границы ячейки, или
дополнительным полем длины в заголовке. Пусть Hv — количество до-
полнительных байтов накладных расходов, требуемых для того, чтобы
можно было использовать ячейки переменного размера. Выведите фор-
мулу зависимости Nor X, Н и Hv,
в) пусть L = 48, Н = 5, Но =* 2. Начертите график зависимости Not размера
сообщения для ячеек фиксированного и переменного размера. Проком-
ментируйте результаты.
4. Еще один важный вопрос разработки технологии ATM заключается в вы-
боре размера поля данных для ячеек фиксированного размера. Рассмотрим
этот вопрос с точки зрения эффективности и задержки.
а) предположите, что передается большое количество информации, так что
все ячейки заполнены полностью. Выведите формулу зависимости эф-
фективности N как функцию от Н и L;
б) задержка пакетирования вызвана необходимостью буферизации битов
до тех пор, пока пакет не заполнится для передачи. Выведите формулу
зависимости времени задержки от L и скорости передачи данных источ-
ником R;
5.7. Задания
151
в) для кодирования речи обычно используются скорости передачи данных
32 Кбит/с и 64 Кбит/с. Начертите график зависимости времени задерж-
ки пакетирования от L для этих двух скоростей передачи данных. Ис-
пользуйте расположенную слева ось у с максимальным значением вре-
мени задержки, равным 2 мс. На том же графике начертите зависимость
эффективности от L. Для этого графика используйте расположенную
справа ось// с максимальным значением эффективности, равным 100 %.
Прокомментируйте результат.
5. Рассмотрите передачу по сети ATM сжатых видеоданных. Предположим,
что стандартные ячейки ATM должны преодолевать 5 коммутаторов. Ско-
рость передачи данных составляет 43 Мбит/с. Во всех представленных ниже
заданиях предполагайте, что случайные события не зависят друг от друга.
Например, можно игнорировать типичную для описанного трафика нерав-
номерность.
а) чему равно время прохождения одной ячейки через коммутатор;
б) каждый коммутатор может оказаться в состоянии передачи ячейки дру-
гого трафика с меньшим приоритетом. Если коммутатор занят переда-
чей ячейки, нашей ячейке придется ждать, пока коммутатор не закончит
передачу текущей ячейки. Если коммутатор свободен, наша ячейка пе-
редается немедленно. Чему равно максимальное время с момента, когда
типичная ячейка прибудет на первый коммутатор (и, возможно, будет
ждать) до того момента, когда последний, пятый, коммутатор закончит
ее передачу? Предположим, что вы можете игнорировать время распро-
странения сигнала, время коммутации и все остальное, кроме времени
передачи и времени ожидания освобождения коммутатора;
в) теперь предположим, что мы знаем, что каждый коммутатор в течение
60 % времени занят передачей другого трафика с низким приоритетом.
Под этим мы подразумеваем, что коммутатор в любой момент времени
с вероятностью 0,6 находится в занятом состоянии. Предположим, что
если коммутатор занят передачей ячейки, то средняя задержка ожидания
передачи ячейки коммутатором равна половине времени передачи ячей-
ки. Чему равно среднее время передачи ячейки от поступления на пер-
вый коммутатор до выхода ее с пятого коммутатора;
г) однако наиболее интересной величиной является не задержка, а флук-
туация, представляющая собой вариацию задержки. Используя данные
пунктов бив этого задания, вычислите максимальное и среднее значе-
ния вариации задержки.
6. Пусть используется тип 3/4 уровня AAL и получатель находится в состо-
янии простоя (нет входящих ячеек). В этом случае блок данных пользо-
вателя передается в виде последовательности протокольных модулей дан-
ных SAR.
а) предположим, что потерян протокольный модуль данных SAR с на-
чалом сообщения (ВОМ SAR PDU). Что произойдет на принимающем
конце;
152
Глава 5. Сети ATM
б) предположим, что потерян один из протокольных модулей данных SAR
с продолжением сообщения (COM SAR PDU). Что произойдет на при-
нимающем конце;
в) предположим, что потеряно 16 последовательных протокольных моду-
лей данных SAR с продолжением сообщения (COM SAR PDU). Что про-
изойдет на принимающем конце;
г) предположим, что многократно потеряно 16 последовательных прото-
кольных модулей данных SAR с продолжением сообщения (COM SAR
PDU). Что произойдет на принимающем конце?
7. Пусть снова используется тип 3/4 уровня AAL, получатель находится в со-
стоянии простоя (нет входящих ячеек) и передаются два блока данных
пользователя в виде последовательности протокольных модулей данных SAR.
а) предположим, что потерян протокольный модуль данных SAR с концом
первого сообщения (ЕОМ SAR PDU). Что произойдет на принимающем
конце;
б) предположим, что потерян протокольный модуль данных SAR с концом
первого сообщения (ЕОМ SAR PDU) и протокольный модуль данных
SAR с началом второго сообщения (BOM SAR PDU). Что произойдет на
принимающем конце?
8. Пусть используется тип 5 уровня AAL и получатель находится в состоянии
простоя (нет входящих ячеек). В этом случае блок данных пользователя пе-
редается в виде последовательности протокольных модулей данных SAR.
а) предположим, что в одном из протокольных модулей данных SAR проис-
ходит однократная ошибка. Что произойдет на принимающем конце;
б) предположим, что потерян один из протокольных модулей данных SAR
с битом типа служебного модуля данных SDU = 0. Что произойдет на
принимающем конце;
в) предположим, что потерян один из протокольных модулей данных SAR
с битом типа служебного модуля данных SDU = 1. Что произойдет на
принимающем конце?
Глава 6
Высокоскоростные
локальные сети
Вся эта операция в мельчайших деталях описана в офици-
альной истории Британского флота, и тем, кто интересует-
ся техническими аспектами операции, следует обратиться
к этому источнику с его замечательными картами. Вся ис-
тория настолько сложна, что непрофессиональный чита-
тель не сможет увидеть леса из-за деревьев. Я всего лишь
попытался прояснить основную идею.
Уинстон Черчилль. Мировой кризис
В последние годы наблюдались быстрые изменения в технологии, дизайне и ком-
мерческих приложениях для локальных сетей. Основная отличительная особен-
ность этой эволюции заключается в появлении широкого спектра новых алгорит-
мов для высокоскоростных локальных сетей. Хотя в центре внимания этой книги
находятся сети, объединенные на основе протокола IP, и сети ATM, полезно со-
ставить представление о требованиях, предъявляемых высокоскоростными ло-
кальными сетями как в объединенных сетях, так и сетях ATM.
В ответ на изменяющиеся потребности деловых кругов в локальных сетях на
рынке появилось множество вариантов реализации высокоскоростных локальных
сетей. Наиболее важные из них перечислены ниже.
♦ Fast Ethernet (быстрая сеть Ethernet) и Gigabit Ethernet (гигабитная сеть
Ethernet). Увеличение скорости протокола CSMA/CD (Carrier Sense Multiple
Access with Collision Detection — множественный доступ с контролем несу-
щей и обнаружением коллизий) представляет собой разумную стратегию,
так как позволяет сохранить вложения в существующие системы.
♦ Fibre Channel (волоконно-оптический канал). Эта технология предназначе-
на для предоставления недорогого легко масштабируемого способа дости-
жения очень высоких скоростей передачи данных по локальным сетям.
♦ Беспроводные локальные сети. Технология и стандарты беспроводных ло-
кальных сетей, наконец, достигли совершеннолетия, и появились высоко-
скоростные стандарты и продукты.
В табл. 6.1 перечислены некоторые характеристики этих технологий. Осталь-
ная часть этой главы посвящена их деталям.
154 Глава 6. Высокоскоростные локальные сети
Таблица 6.1. Характеристики некоторых высокоскоростных локальных сетей
Параметр Fast Gigabit Fibre Беспроводная
Ethernet Ethernet Channel локальная сеть
Скорость 100 Мбит/с 1 Гбит/с, 100 Мбит/с- 1 Мбит/с -
передачи 10 Гбит/с 3,2 Гбит/с 54 Мбит/с
данных
Передающая UTP, STP, UTP, Оптоволоконный Микроволны
среда ОПТОВОЛОКОННЫЙ экранированный кабель, 2,4 ГГц, 5 ГГц
кабель кабель. коаксиальный
ОПТОВОЛОКОННЫЙ кабель, STP
кабель
Метод CSMA/CD CSMA/CD Коммутация CSMA/Onpoc
доступа
Стандарт IEEE 802.3 IEEE 802.3 Fibre Channel IEEE 802.11
Association
6.1. Появление высокоскоростных
локальных сетей
Персональные компьютеры и микрокомпьютерные рабочие станции начали полу-
чать широкое распространение в бизнесе в начале 80-х и к сегодняшнему дню до-
стигли статуса телефона: трудно представить себе офис без персональных компь-
ютеров. До относительно недавних пор офисные локальные сети предоставляли
основные услуги связи — соединения персональных компьютеров и терминалов с
мэйнфреймами и системами промежуточного уровня, на которых работают кор-
поративные приложения, а также обеспечивали связь между рабочими группами
на уровне отделов. В обоих случаях нагрузка на линии передачи была относитель-
но небольшой, с упором на передачу файлов и электронной почты. Локальные сети,
соответствующие данному типу нагрузки, в первую очередь Ethernet и Token Ring,
хорошо подходят для данного окружения.
В последние годы две важные тенденции изменили роль персонального компь-
ютера и, таким образом, требования к локальной сети:
Скорость и вычислительная мощность персональных компьютеров про-
должают радовать экспоненциальным ростом. Сегодняшние более мощные
платформы поддерживают приложения, интенсивно использующие графи-
ку, и все более сложные графические интерфейсы пользователя для опера-
ционных систем.
♦ Производители информационных и управляющих систем распознали в локаль-
ных сетях жизнеспособную и, несомненно, важную компьютерную платфор-
му и стали уделять больше внимания локальным сетям. Эта тенденция на-
чалась с технологии клиент-сервер, ставшей доминирующей архитектурой
для делового окружения. Не так давно проявилась тенденция распростра-
нения интранет — сетей. Оба эти подхода подразумевают частый перенос
больших объемов данных с использованием механизма транзакций.
6.2. Ethernet
155
Эффект от этих тенденций проявился в увеличении объема переносимых ло-
кальными сетями данных, что позволило снизить задержку передачи данных —
необходимое условие работы распределенных интерактивных приложений. Пред-
шествующие поколения локальных сетей, такие как 10-мегабитная сеть Ethernet
и 16-мегабитная сеть с топологией маркерного кольца, просто не могли соответ-
ствовать этим требованиям.
Ниже перечислены некоторые примеры применений, требующие высокоско-
ростных локальных сетей.
4- Централизованные серверные фермы. Во многих приложениях необходимо
позволить системе пользователя, или клиенту, загружать огромные объемы
данных с нескольких централизованных серверов, называемых серверными
фермами. В качестве примера можно назвать подготовку цветного иллюст-
рированного журнала. При этом на серверах, как правило, хранятся десятки
гигабайтов данных, которые должны загружаться на графические рабочие
станции. По мере роста производительности серверов узким местом в локаль-
ных сетях стали линии связи. Эти проблемы невозможно решить при помо-
щи коммутируемой сети Ethernet в связи с ограничением скорости передачи
данных в 10 Мбит/с по одной линии.
4 Мощные рабочие группы. Эти группы обычно состоят из небольшого числа
работающих совместно пользователей, которым нужно перемещать по сети
массивные файлы данных. Среди примеров можно назвать группы разра-
ботчиков программного обеспечения, тестирующие новое программное
обеспечение, или компании, занимающиеся автоматизированным проекти-
рованием (Computer-Aided Design, CAD) и регулярно запускающие свои
компьютерные модели. В таких случаях большие объемы данных доставля-
ются на несколько рабочих станций, обрабатываются там и обновляются на
очень высоких скоростях на каждой итерации.
4 Высокоскоростная локальная магистраль. По мере роста потребностей в об-
работке количество локальных сетей на каждом предприятии увеличивает-
ся, и на первый план выходит необходимость их объединения высокоскоро-
стными линиями.
6.2. Ethernet
В основе наиболее часто применяемых сегодня локальных сетей лежит сеть Ethernet,
разработанная комитетом стандартизации IEEE 802.3. На сегодняшний день на
рынке высокоскоростных локальных сетей доминирует семейство 100-мегабитных
локальных сетей, известных под названием Fast Ethernet (быстрая сеть Ethernet).
Несколько позднее появилась сеть Gigabit Ethernet (гигабитная сеть Ethernet).
Прежде чем перейти к рассмотрению этих сетей, мы представим краткий обзор
оригинальной сети Ethernet, работающей на скорости 10 Мбит/с, и познакомим
“итателя с концепцией коммутируемых локальных сетей.
156 Глава 6. Высокоскоростные локальные сети
Классическая сеть Ethernet
Сеть Ethernet изначально была разработана корпорацией Xerox и использовалась
впоследствии в качестве основы для семейства стандартов комитета IEEE 802.3,
Классическая сеть Ethernet работает на скорости 10 Мбит/с в локальной сети
с топологией общей шины и использует протокол CSMA/CD (Carrier Sense Multiple
Access with Collision Detection — множественный доступ с контролем несущей
и обнаружением коллизий) для управления доступом к носителю. В этом подраз-
деле мы познакомимся с концепцией локальной сети с общей шиной и работой
протокола CSMA/CD.
Локальные сети с топологией общей шины
В локальных сетях с топологией общей шины все станции соединены при помощи
соответствующего аппаратного интерфейса, называемого отводом (tap), напрямую
с линейной передающей средой. Дуплексная связь между станцией и отводом поз-
воляет передавать данные на шину и получать их с шины. Данные, передаваемые
любой станцией, распространяются по всей длине носителя в обоих направлени-
ях и могут быть получены всеми станциями. На каждом конце шины находится
терминатор шины, поглощающий все сигналы шины, таким образом удаляя их
с шины.
При таком устройстве локальной сети возникают две проблемы. Во-первых,
поскольку передача любой станции может приниматься всеми остальными стан-
циями, требуется способ указывать, кому предназначаются данные. Во-вторых,
необходим механизм управления передачей. Чтобы понять, зачем это нужно, рас-
смотрим ситуацию, в которой две станции на шине попытаются начать передачу
одновременно — их сигналы перекрываются и искажаются. Или представьте себе
ситуацию, в которой одна станция решает передавать данные непрерывно в тече-
ние длительного периода времени, блокируя тем самым доступ к сети для других
пользователей.
Решение этих проблем заключается в том, что станции передают данные не-
большими блоками, называемыми кадрами. Каждый кадр состоит из порции дан-
ных, которые станция желает передавать, а также заголовка кадра, содержащего
управляющую информацию. Каждой станции на шине присваивается уникальный
адрес, называемый идентификатором, и адрес получателя включается в заголовок
каждого кадра.
Схема работы локальной сети с топологией общей шипы показана на рис. 6.1.
В данном примере станция С желает передать кадр данных станции А. Адрес
станции А включен в заголовок кадра. По мере того как кадр распространяется по
шине, он проходит мимо станции В. Станция В проверяет адрес и игнорирует кадр.
Станция А, напротив, определяет, что кадр предназначается ей, и копирует дан-
ные из кадра.
Таким образом, структура кадра позволяет решить первую из упоминавшихся
ранее проблем: она предоставляет механизм идентификации получателя данных.
Структура кадра также предоставляет основной инструмент для решения второй
проблемы — управления доступом. В частности, станции передают кадры поочеред-
но, сотрудничая друг с другом. Об этом будет рассказано в следующем подраздел0
6.2. Ethernet
157
Станция С передает кадр, адресованный станции А
Кадр не предназначается станции В, и станция В его игнорирует
Станция А копирует кадр, когда тот доходит до нее
Рис. 6.1. Передача кадра в локальной сети с общей шиной
CSMA/CD
При использовании протокола CSMA/CD (Carrier Sense Multiple Access with
Collision Detection — множественный доступ с контролем несущей и обнаруже-
нием коллизий) станция, желающая начать передачу, сначала прислушивается
к Носителю, определяя, не передает ли уже в этот момент какая-либо другая
станция. Это и есть контроль несущей (carrier sense). Если носитель свободен,
станция может передавать. Может случиться так, что две или более станций
Попытаются начать передачу почти одновременно. В этом случае произойдет
коллизия, данные обеих станций перемешаются, и другие станции не смогут
Правильно их принять. Таким образом, необходима процедура, определяющая,
158 Глава 6. Высокоскоростные локальные сети
что станция должна делать в случае, если несущая занята, и в случае, если имеет
место коллизия.
1. Если несущая свободна, можно передавать.
2. Если несущая занята, нужно продолжать прослушивать несущую до тех пор,
пока она не освободится, после чего немедленно начать передачу.
3. Если при передаче обнаружена коллизия, немедленно прекратить передачу.
4. После коллизии нужно подождать в течение случайного периода времени,
после чего повторить попытку передачи (начиная с шага 1).
Передача станции С
Сигнал на шине 77 7 7 7 7 7 7/777 S
Момент времени t2
Передача станции А Г77/77^/////////\
Передача станции С [TWXJS X\\\J
Сигнал на шине 77777777
Момент времени t3
Передача станции А 7/ 7///////////////////\
Передача станции С ["\ \ \ \|
Сигнал на шине
7 /У7//77777777777777777
Рис. 6.2. Работа протокола CSMA/CD
Работу этого алгоритма иллюстрирует рис. 6.2. В верхней части рисунка показа-
на схема шины локальной сети. Остальную часть рисунка занимает описание ра-
боты алгоритма в четыре последовательных момента времени. В момент времени ',
6.2. Ethernet
159
станция А начинает передачу пакета, адресованного станции D. В момент времени tx
обе станции, В и С, готовы к передаче. Станция В слышит ведущуюся передачу
и поэтому воздерживается от собственной передачи. Однако станция С еще не
знает о передаче, которую начала станция А, и начинает собственную передачу.
В момент времени t2, когда сигнал от станции А достигает станции С, станция С
обнаруживает факт коллизии и прекращает передачу. Результат коллизии распро-
страняется в сторону станции А, которая тоже обнаруживает факт коллизии в мо-
мент времени t3 и прекращает передачу.
Для поддержания устойчивой работы сети величина времени ожидания на
шаге 4 определяется с помощью метода, называемого двоичным экспоненциальным
откатом (binary exponential backoff). В случае повторной коллизии среднее зна-
чение случайной задержки удваивается. Удвоение выполняется для первых 10 по-
пыток. В течение следующих 6 дополнительных попыток это среднее значение ос-
тается неизменным. Если за 16 попыток станции не удалось отправить сообщение,
она прекращает попытки и сообщает об ошибке. Таким образом, при увеличении
перегрузки локальной сети станции ждут в течение все больших интервалов вре-
мени, чтобы снизить вероятность коллизии.
Достоинством протокола CSMA/CD является его простота. Логика этого про-
токола легко реализуется. Больше того, при выполнении этого протокола малове-
роятно, что что-то может пойти не так, как надо. Например, если по какой-либо
причине станции не удастся обнаружить коллизию, то самое худшее, что может
произойти, — станция будет продолжать передачу кадра, в результате некоторое
время будет потрачено зря. Как только передача кадра завершится, алгоритм сно-
ва продолжит свою обычную работу.
Кадр МАС
На рис. 6.3 показан формат кадра протокола 802.3. Он состоит из следующих полей:
4 Преамбула. 7-байтовая последовательность сменяющих друг друга битов 0
и 1, используемых получателем для синхронизации с отправителем.
4 Ограничитель начала кадра (Start Frame Delimiter, SFD). Последователь-
ность битов 10101011, обозначающая фактическое начало кадра и позво-
ляющая получателю' обнаружить местоположение первого бита остальной
части кадра.
♦ Адрес получателя идентифицирует станцию (или несколько станций), ко-
торой предназначается передаваемый кадр. Это может быть уникальный
физический адрес, группа адресов или глобальный адрес.
4 - Адрес отправителя идентифицирует станцию, посылающую кадр.
4 Длина/Тип. Длина поля данных LLC1 в байтах или поле «Тип Ethernet» в за-
висимости от того, соответствует ли кадр стандарту IEEE 802.3 или более
ранней спецификации Ethernet. В любом случае максимальный размер кад-
ра, не считая преамбулы и ограничителя начала кадра, составляет 1518 байт.
Logical Link Control — управление логическим соединением. Верхний подуровень канального уров-
Ня в соответствии со стандартом IEEE 802.2. — Примеч. перее.
160
Глава 6. Высокоскоростные локальные сети
4 Данные LLC. Модуль данных, предоставляемый подуровнем LLC.
♦ Заполнитель. Байты, добавляемые, чтобы гарантировать достаточную для
обнаружения коллизии длину кадра.
Контрольная последовательность кадра (Frame Check Sequence, FCS).
32-разрядный циклический избыточный код, в котором учитываются все
поля кадра, кроме преамбулы, ограничителя начала кадра и самого поля кон-
трольной последовательности кадра.
От 46 до 1500 байт
◄---------------------►
7 байт 1 6 6 2 > 0 >04
Преамбула SFD Адрес получателя Адрес отправителя Длина Данные подуровня LLC заполнитель i FCS
Рис. 6.3. Формат кадра IEEE 802.3
Варианты стандарта IEEE 802.3 со скоростью
передачи данных 10 Мбит/с
Комитет IEEE 802.3 определил несколько альтернативных физических конфигу-
раций. В этом есть свои положительная и отрицательная стороны. Положитель-
ная сторона состоит в том, что стандарт взял на себя ответственность за развитие
технологии. Недостаток заключается в том, что клиенту, не говоря уже о потен-
циальном производителе, приходится иметь дело с множеством вариантов, что
может привести в замешательство. Однако комитет постарался гарантировать
возможность интеграции различных параметров в конфигурации, способных удов-
летворить самый широкий спектр потребностей. Таким образом, пользователь со
сложным подбором требований может оценить гибкость и разнообразие стандар-
та 802.3.
Чтобы было удобно различать доступные варианты реализации, комитетом
была разработана следующая нотация:
<скорость передачи данных в мегабитах в секунду> <метод передачи сигнала>
<максимальная длина сегмента в сотнях метров>
В данном подразделе мы рассмотрим два варианта реализации IEEE 802.3, ра-
ботающих на скорости 10 Мбит/с, оригинальной скорости сети Ethernet (вариан-
ты реализации, работающие с большими скоростями, будут рассматриваться в сле-
дующих подразделах). Эти два варианта:
♦ 10BASE5;
♦ 10BASE-T.
Обратите внимание на то, что 10BASE-T не соответствует принятой нотации:
символ «Т» означает витую пару (twisted pair). /
6.2. Ethernet
161
Спецификация 10BASE5
Стандарт 10BASE5 представляет собой оригинальную спецификацию несущей
стандарта 802.3, основанную непосредственно на сети Ethernet. Спецификация
10BASE5 описывает применение в качестве шины 50-омного коаксиального кабе-
ля и использует Манчестерское кодирование1. Максимальная длина сегмента ка-
беля, установленная стандартом, равна 500 м. Длина сети может быть увеличена
при помощи повторителей. Для уровня передачи данных повторитель является
прозрачным, так как он не производит буферизации и не изолирует один сегмент
от другого. Таким образом, например, если две станции в различных сегментах
попытаются передавать одновременно, их передачи образуют коллизию. Чтобы
избежать циркуляции пакетов данных между сегментами локальной сети, между
двумя станциями разрешается только один путь, состоящий из сегментов и повтори-
телей. На пути между любыми двумя станциями стандартом разрешается максимум
четыре повторителя, таким образом, общая длина несущей может достигать 2,5 км.
Спецификация 10BASE-T
Если немного пожертвовать длиной шины, можно создать локальную сеть, рабо-
тающую на скорости 10 Мбит/с, используя в качестве несущей неэкранированную
витую пару. Многие офисы уже оснащены подобной проводкой благодаря те-
лефонной связи, и эта же проводка может использоваться для локальных сетей.
Такой подход описан в спецификации 10BASE-T, которой определена сеть с то-
пологией звезды. Простая система состоит из нескольких станций, соединенных
витыми парами с центральным узлом, называемым многопортовым повторителем
(multiport repeater). Центральный узел принимает кадр по любой из линий и вос-
производит (повторяет) его на всех остальных линиях.
Станции соединяются с многопортовым повторителем двухточечными линия-
ми. Обычно линия состоит из двух неэкранированных витых пар. В связи с высо-
кой скоростью передачи данных и невысоким качеством передачи по неэкраниро-
ванной витой паре длина линии ограничена до 100 м. В качестве альтернативы
может использоваться оптоволоконный кабель. В этом случае максимальная дли-
на линии может составлять 500 м.
В простейшей схеме сети 10BASE-T центральный элемент звезды представля-
ет собой активный элемент, называемый хабом (hub), или концентратором. Каж-
дая станция соединяется с хабом двумя витыми парами (для приема и передачи).
Хаб действует как повторитель: когда передает одиночная станция, хаб воспроиз-
водит сигнал на выходных линиях для всех станций. Обратите внимание на то, что
хотя физически эта схема представляет собой звезду, логически она является
шиной: передача каждой станции принимается всеми остальными станциями,
а если две станции передают одновременно, происходит коллизия.
Хабы могут быть упорядочены в виде многоуровневой иерархической струк-
туры. На рис. 6.4 показана двухуровневая конфигурация. Структура состоит из
одного головного хаба (Header Hub, HHUB) и одного или нескольких промежуточ-
ных хабов (Intermediate HUB, IHUB). К каждому хабу могут быть присоединены
как станции, так и другие хабы. Такая схема хорошо подходит для прокладки
Это форма представления цифрового сигнала, гарантирующая, по меньшей мере, одно изменение сиг-
нала за время передачи каждого бита.
162
Глава 6. Высокоскоростные локальные сети
локальных сетей в зданиях. Как правило, на каждом этаже здания есть специаль-
ное помещение, куда сходятся витые пары со всего этажа, и в каждом таком поме-
щении может быть размещен хаб, обслуживающий станции на своем этаже.
Рис. 6.4. Топология двухуровневой звезды
Хабы и коммутаторы
Мы использовали термин хаб в контексте стандарта 10BASE-T, но этот термин
также используется для обозначения множества устройств самых различных ти-
пов. Наиболее важное различие заключается между хабом с коллективным досту-
пом к несущей и хабом коммутируемой локальной сети, который обычно называ-
ют коммутатором 2-го уровня (layer 2 switch).
Чтобы различие между хабами и коммутаторами стало яснее, на рис. 6.5, а
показана типичная схема общей шины традиционной 10-мегабитной сети Ethernet.
Шина прокладывается таким образом, чтобы все присоединяемые к ней уст-
ройства находились на разумном расстоянии от точки подключения к шине.
Передача от любой станции распространяется по всей длине шины и может
приниматься всеми остальными станциями. На рисунке станция В передает. Сиг-
нал распространяется от станции В по линии, связывающей станцию с шиной,
а затем в обоих направлениях по шине и далее ко всем остальным присоеди-
ненным к шине станциям по их линиям доступа. В данной конфигурации все
станции должны делить между собой пропускную способность шины, которая со-
ставляет 10 Мбит/с. i
6.2. Ethernet
163
Рис. 6.5. Хабы и коммутаторы локальной сети
У хаба с коллективным доступом к несущей (shared-medium hub), который, на-
пример, указан в спецификации 10BASE-T, есть центральный хаб, часто размеща-
емый в соединительном шкафу. Для соединения всех станций с хабом использу-
ется схема соединений со звездообразной топологией. При этом передача от любой
164 Глава 6. Высокоскоростные локальные сети
станции принимается хабом и передается по всем исходящим линиям. Поэтому, • ~т=|
чтобы избежать коллизии, в каждый момент времени должна передавать только
одна станция. При такой схеме суммарная пропускная способность локальной сети
та же самая, что и у линий доступа от каждой станции, то есть 10 Мбит/с. У хаба с
коллективным доступом к несущей есть несколько преимуществ по сравнению с
обычной схемой общей шины. Во-первых, при этом используются стандартная схе-
ма прокладки кабелей и соединительные шкафы. Кроме того, хаб может быть на-
строен так, что сможет распознавать неверно работающую станцию, являющуюся
источником перегрузки в сети. Работу хаба с коллективным доступом к несущей
иллюстрирует рис. 6.5, 6. Здесь также станция В передает. Передаваемые данные
идут от станции В по линии передачи к хабу и от хаба по приемным линиям ко
всем остальным присоединенным станциям.
При помощи коммутатора 2-го уровня можно достичь большей производитель-
ности. В этом случае центральный хаб функционирует подобно коммутатору па-
кетов. Входящий пакет переправляется только по одной выходной линии получа-
ющей станции. В то же самое время остальные линии могут использоваться для
коммутации пакетов других станций. На рис. 6.5, в показан пример, в котором
станция В передает кадр станции А, а станция С в то же самое время передает кадр
станции D. Таким образом, в этом примере текущая пропускная способность ло-
кальной сети составляет 20 Мбит/с, хотя скорость передачи данных для каждого
отдельного устройства ограничена значением 10 Мбит/с. У коммутирующего хаба
есть несколько привлекательных особенностей:
♦ Чтобы преобразовать локальную сеть с топологией общей шины или локаль-
ную сеть с хабом в коммутируемую локальную сеть, не требуется измене-
ний программного или аппаратного обеспечения присоединенных устройств.
В случае локальной сети Ethernet каждое присоединенное устройство для
доступа к локальной сети продолжает использовать протокол Ethernet
управления доступом к несущей. С точки зрения присоединенного устрой-
ства в логике доступа ничего не меняется.
♦ У каждого присоединенного устройства есть выделенная пропускная спо-
собность, равная полной пропускной способности оригинальной локальной
сети при условии, что у коммутатора 2-го уровня достаточно пропускной
способности, чтобы поддерживать все присоединенные устройства. Напри-
мер, если коммутатор 2-го уровня (см. рис. 6.5, в) может поддерживать про-
пускную способность 20 Мбит/с, то у каждого присоединенного устройства
и для приема, и для передачи как бы появляется выделенная линия с про-
пускной способностью в 10 Мбит/с.
♦ Коммутатор 2-го уровня легко масштабируется. Дополнительные устрой-
ства могут добавляться к коммутатору 2-го уровня при одновременном уве-
личении его мощности.
Два типа коммутаторов 2-го уровня распространяются на коммерческой основе.
♦ Коммутатор с промежуточным хранением (store-and-forward switch). Ком-
мутатор 2-го уровня принимает кадр по входной линии, хранит его в буфер^
иедолгое время, после чего направляет по соответствующей выходной лик-ш
6.2. Ethernet
165
> Сквозной коммутатор (cut-through switch). Коммутатор 2-го уровня пользу-
ется тем преимуществом, что адрес получателя помещается в начале кадра
MAC (Medium Access Control — управление доступом к носителю). Комму-
татор 2-го уровня начинает передавать принимаемый кадр по нужной выход-
ной линии, как только коммутатор 2-го уровня распознает адрес получателя.
Сквозной коммутатор позволяет достичь максимально возможной пропускной
способности, ио при этом рискуя передать неверный кадр, так как он не может
проверить контрольную сумму перед передачей. Коммутатор с промежуточным
хранением вносит задержку во взаимодействие между отправителем и получате-
лем, но зато повышает общую целостность сети.
Коммутатор 2-го уровня можно рассматривать как дуплексный вариант хаба.
Он также может заключать в себе логику, позволяющую ему функционировать как
многопортовому мосту. В [38] перечислены различия между коммутаторами 2-го
уровня и мостами:
Обработка кадров осуществляется мостами программно. Коммутатор 2-го
уровня распознает адрес и пересылает кадр аппаратно.
♦ Как правило, мост может анализировать и переправлять в каждый момент
времени только один кадр, тогда как коммутатор 2-го уровня, обладая не-
сколькими параллельными линиями, может одновременно обрабатывать
несколько кадров.
♦ Мост использует схему промежуточного хранения. В коммутаторах 2-го
уровня могут использоваться как эта же, так и сквозная схемы.
Поскольку коммутатор 2-го уровня обладает более высокой производительно-
стью и может выполнять функции моста, на коммерческом рынке мосты потерпе-
ли поражение. В новых сетях, как правило, используются коммутаторы 2-го уров-
ня, обладающие функциональностью мостов.
Коммутаторы 3-го уровня
Коммутаторы 2-го уровня обеспечивают более высокую производительность,
удовлетворяя потребности в транспортировке трафика больших объемов, форми-
руемого персональными компьютерами, рабочими станциями и серверами. Одна-
ко по мере того, как количество подключенных к сети устройств в здании или ком-
плексе зданий растет, коммутаторы 2-го уровня перестают справляться со своей
задачей. В частности, возникают две проблемы: широковещательная перегрузка и
недостаток линий связи.
Считается, что у множества устройств и локальных сетей, соединенных ком-
мутаторами 2-го уровня, адресное пространство плоское. Термин плоское (flat)
означает, что все пользователи имеют общий широковещательный адрес МАС.
Ааким образом, если любое устройство отправляет кадр МАС с широковещательным
адресом, этот кадр должен быть доставлен всем устройствам сети, объединенной
При помощи коммутаторов 2-го уровня и/или мостов. В большой сети частая пе-
редача широковещательных кадров может вызвать огромную перегрузку. Что еще
хУЖе, неисправное устройство способно создать широковещательный шторм
166
Глава 6. Высокоскоростные локальные сети
(broadcast storm), при котором многочисленные широковещательные кадры запо-
лоняют сеть и вытесняют остальной трафик.
Вторая проблема, связанная с производительностью и относящаяся к использо-
ванию мостов и/или коммутаторов 2-го уровня, заключается в том, что современ-
ными стандартами для протоколов мостов предписывается отсутствие замкнутых
контуров в сети. То есть между любыми двумя устройствами может существовать
только один путь. Таким образом, оказывается невозможным соединить два уст-
ройства несколькими путями через несколько коммутаторов. Такое ограничение
негативно влияет как на производительность, так и на надежность.
Для решения этих проблем кажется логичным разбить большую локальную
сеть на несколько подсетей (subnetworks), соединенных маршрутизаторами. При
этом широковещательный кадр МАС доставляется только в пределах своей под-
сети. Кроме того, IP-маршрутизаторами применяются сложные алгоритмы марш-
рутизации, позволяющие использовать между подсетями несколько путей, прохо-
дящих через разные маршрутизаторы.
Однако недостаток использования маршрутизаторов вместо мостов и комму-
таторов 2-го уровня состоит в том, что маршрутизаторы, как правило, выполняют
всю обработку IP-уровня программно. Высокоскоростные локальные сети и высо-
копроизводительные коммутаторы 2-го уровня могут пропускать миллионы па-
кетов в секунду, тогда как пропускная способность работающих программно мар-
шрутизаторов значительно ниже миллиона пакетов в секунду. Для решения этой
проблемы некоторые производители разработали коммутаторы 3-го уровня, в ко-
торых логика маршрутизации пакетов реализована аппаратно.
Сегодня на рынке представлено несколько схем коммутаторов 3-го уровня, ио
фундаментально они распадаются на две категории: пакетный коммутатор и по-
токовый коммутатор. Пакетный коммутатор (packet-by-packet switch) работает так
же, как традиционный маршрутизатор. Поскольку логика маршрутизации пакет-
ного коммутатора реализована аппаратно, с его помощью производительность
может быть увеличена на порядок по сравнению с использованием программного
маршрутизатора. Потоковый коммутатор (flow-based switch) пытается увеличить
производительность, идентифицируя потоки IP-пакетов с одними и теми же от-
правителем и получателем. Это может быть реализовано путем наблюдения за
проходящим через коммутатор трафиком, а также с помощью специальной метки
потока в заголовке пакета (допустимо в IPv6, ио не в IPv4; см. рис. 2.2 в главе 2).
Когда поток идентифицирован, может быть выбран заранее установленный мар-
шрут, чтобы ускорить процесс доставки пакета. При помощи этого метода также
можно достичь многократного увеличения производительности по сравнению с
использованием программного маршрутизатора.
На рис. 6.6 показан типичный пример сетевой конфигурации в организации
с большим количеством персональных компьютеров и рабочих станций (от не-
скольких тысяч до нескольких десятков тысяч). Настольные компьютеры соеди-
нены с локальной сетью линиями с пропускной способностью от 10 Мбит/с до
100 Мбит/с, управляемыми коммутатором 2-го уровня. Для мобильных пользо-
вателей также может быть доступно беспроводное соединение с локальной сетью.
Коммутаторы 3-го уровня формируют локальную магистраль. Как правило, эти
коммутаторы связаны друг с другом линиями с пропускной способностью 1 Гбит/с,
а с коммутаторами 2-го уровня — линиями, работающими на скорости от 100 Мбит 'i
6.2. Ethernet
167
до 1 Гбит/с. Серверы соединяются напрямую с коммутаторами 2-го или 3-го уровня
линиями с пропускной способностью 1 Гбит/с или 100 Мбит/с. Недорогой про-
граммный маршрутизатор обеспечивает соединение с глобальной сетью. Окруж-
ности на рисунке соответствуют отдельным локальным подсетям, а любой широ-
ковещательный кадр МАС ограничен собственной подсетью.
Fast Ethernet
Fast Ethernet — это множество спецификаций, разработанных комитетом IEEE 802.3
Для формирования недорогой, совместимой со стандартом Ethernet локальной
сети, работающей на скорости 100 Мбит/с. Все эти стандарты соответствуют
168
Глава 6. Высокоскоростные локальные сети
спецификации 10BASE-T. Комитет также определил несколько альтернативных
вариантов для других носителей.
На рис. 6.7 показана схема, иллюстрирующая терминологию для специфика-
ции применяемых носителей. Все варианты 10BASE-T используют протокол и
формат кадров МАС стандарта IEEE 802.3.100BASE-X означает набор вариантов,
в которых имеются две физических линии между узлами, одна для приема и одна
для передачи. В 100BASE-TX описывается экранированная витая пара (Shielded
Twisted Pair, STP) или высококачественная (категории 5) неэкранированная ви-
тая пара (Unshielded Twisted Pair, UTP). 100BASE-FX использует оптоволокон-
ный кабель. Для всех этих схем максимальное расстояние между хабами и станци-
ями составляет от 100 до 200 м.
IEEE 802.3 (100 Мбит/с)
витые пары
категории 5
витые пары
витые пары
категории 3 или 5
Рис. 6.7. Варианты 100BASE-T IEEE 802.3
Во многих зданиях для использования спецификации 100BASE-X требуется
установка нового кабеля. Чтобы минимизировать затраты для зданий, в которых
не установлен требуемый кабель, стандарт 100BASE-T4 определяет недорогую
альтернативу, в которой в дополнение к высококачественной витой паре категории 5
может использоваться категория З1, представляющая собой неэкранированную
витую пару, применяемую для телефонной связи. Для достижения скорости пере-
дачи данных в 100 Мбит/с по кабелю низкого качества стандартом 100BASE-T4
1 Витая пара категории 3 представляет собой стандартный телефонный провод, обладающий ограничен-
ной скоростью передачи данных. Категория 5 предназначается для существенно больших скоростей
передачи данных. Главное различие между категориями 3 и 5 заключается в количестве витков кабе-
ля на единицу длины. Витая пара категории 5 свита значительно плотнее, как правило, 3-4 витка
на дюйм, по сравнению со значением 3-4 витка на фут для категории 3. Более тугая намотка дороже,
но такой кабель обеспечивает существенно более высокую п|юизводительность, чем категория 3.
6.2. Ethernet
169
предписывается использование между узлами четырех витых пар, данные по ко-
торым передаются по трем парам в одну сторону одновременно.
Спецификация 10OBASE-X
Для всех носителей, обозначенных спецификацией 100BASE-X, скорость переда-
чи данных 100 Мбит/с в одну сторону достигается по одной линии (одной витой
паре или одному оптоволоконному кабелю). Для всех этих носителей требуется
эффективная схема кодирования данных. Для данного носителя используется схе-
ма 4B/5B-NRZI. Этот метод кодирования более эффективен, чем Манчестерская
кодировка, используемая для 10-мегабитной сети Ethernet, и поэтому он предпоч-
тителен на более высоких скоростях передачи данных.
Обозначение 100BASE-X включает две спецификации физических носителей:
одну для витой пары, называемую 100BASE-TX, и одна для оптоволоконного кабе-
ля, известную под маркировкой 100BASE-FX. В 100BASE-TX используется две ви-
тых пары, одна для передачи, другая для приема. Может применяться как экраниро-
ванная витая пара, так и неэкраиироваииая витая пара категории 5. В 100BASE-FX
описываются два оптоволоконных кабеля, один для передачи и один для приема.
Спецификация 100BASE-T4
Спецификация 100BASE-T4 разработана для передачи данных со скоростью
100 Мбит/с по низкокачественному кабелю категории 3, что удобно ввиду распро-
страненности подобной проводки в офисных зданиях. В спецификации также
указывается, что в качестве альтернативы допускается использование витой пары
категории 5.
Для спецификации 100BASE-T4, описывающей передачу данных кабелем ка-
тегории 3, предназначенным для телефонных разговоров, неразумно ожидать до-
стижения скорости 100 Мбит/с по одной витой паре. Вместо этого в специфика-
ции 100BASE-T4 указано, что поток данных должен передаваться расщепленным
на три отдельных потока данных, каждый с эффективной скоростью передачи дан-
ных 33 Мбит/с. Всего используются четыре витых пары. Данные передаются по
трем витым парам и принимаются по одной витой паре. Таким образом, две пары
из четырех должны допускать передачу данных в обе стороны.
Полнодуплексная работа
Традиционная сеть Ethernet является полудуплексной. Станция может либо пе-
редавать, либо принимать кадр, ио не может делать этого одновременно. При пол-
нодуплексной работе прием и передача могут выполняться станцией одновремен-
но. Если бы 100-мегабитная сеть Ethernet работала в полнодуплексном режиме,
то теоретическая скорость передачи данных достигла бы 200 Мбит/с.
Для работы в полнодуплексном режиме необходимы определенные изменения.
У присоединенных станций должны быть полнодуплексные, а не полудуплексные
сетевые карты. Центральный узел звезды не может быть простым многопортовым
повторителем, а должен быть коммутирующим хабом. В этом случае каждая станция
образует отдельный домен коллизий. Фактически, коллизий вообще нет, и в алгорит-
ме CSMA/CD больше нет необходимости. Однако используется все тот же формат
170
Глава 6. Высокоскоростные локальные сети
кадра МАС стандарта IEEE 802.3, и присоединенные станции могут продолжать
работать по алгоритму CSMA/CD, хотя коллизий в такой сети быть не может.
Смешанная конфигурация
Одно из достоинств сети Fast Ethernet заключается в том, что она поддерживает
совместную работу существующих 10-мегабитных и новых 100-мегабитиых локаль-
ных сетей. Пример такой сети показан на рис. 6.8, где 100-мегабитная локальная
сеть используется в качестве магистрали. Многие станции соединены с 10-мега-
битными хабами линиями стандарта 10BASE-T. Эти хабы, в свою очередь, соеди-
нены с коммутирующими хабами, согласующимися со стандартом 100BASE-T
и поддерживающими как 10-мегабитные, так и 100-мегабитные линии. Дополни-
тельные высокопроизводительные рабочие станции и серверы присоединяются
напрямую к коммутаторам 10/100. Эти коммутаторы смешанной пропускной
способности, в свою очередь, соединены со 100-мегабитными хабами при помощи
100-мегабитиых линий. 100-мегабитные хабы формируют магистраль и соедине-
ны с маршрутизатором, обеспечивающим соединение с внешней глобальной сетью.
Рис. 6.8. Пример стратегии 100-мегабитной магистрали Ethernet
Gigabit Ethernet
В конце 1995 г. комитет IEEE 802.3 сформировал группу изучения высокоско-
ростных сетей для исследования возможностей передачи пакетов с гигабитными
скоростями. Сегодня выпущен набор стандартов, названия которых начинаются
с числа 1000 (1000 Мбит/с).
6.2. Ethernet
171
В сети Gigabit Ethernet (гигабитная сеть Ethernet) применяется та же самая
стратегия, что и в сети Fast Ethernet. Несмотря на то что в сети Gigabit Ethernet
определен новый носитель, в ней сохранен протокол CSMA/CD и формат кадра
ее 10-мегабитного и 100-мегабитного предшественников. Сеть Gigabit Ethernet
совместима со стандартами 10BASE-T и 100BASE-T, что облегчает переход на
более быстрый вариант Ethernet. По мере того как все больше организаций пере-
ходят на 100BASE-T, нагрузка на магистральные сети увеличивается и спрос на
Gigabit Ethernet возрастает.
На рис. 6.9 показано типичное приложение сети Gigabit Ethernet. Гигабит-
ный коммутатор локальной сети обеспечивает магистральное соединение для
центральных серверов и высокоскоростных коммутаторов рабочих групп. Каж-
дый коммутатор локальной сети рабочей группы поддерживает как гигабитные
линии, предназначенные для соединения с коммутатором магистральной локаль-
ной сети и обслуживания высокопроизводительных серверов рабочих групп,
так и 100-мегабитные линии, предназначенные для обслуживания высокопроиз-
водительных рабочих станций, серверов и 100-мегабитных коммутаторов локаль-
ных сетей.
--------- Линия с пропускной
способностью 100 Мбит/с
--------- Линия с пропускной
способностью 1 Гбит/с
Хаб
с пропускной
способностью
1 Гбит/с
Центральные
серверы
Рис. 6.9. Пример стратегии 100-мегабитной магистрали Ethernet
172
Глава 6. Высокоскоростные локальные сети
Текущая гигабитная спецификация стандарта IEEE 802.3 включает следующие
альтернативные варианты физического уровня (рис. 6.10):
♦ 1000BASE-LX. Длинноволновый вариант. Оптоволоконный многомодовый
кабель диаметром 62,5 мкм или 50 мкм, поддерживающий дуплексные ли-
нии длиной до 550 м или одиомодовый кабель диаметром 10 мкм длиной до
5 км. Используемые длины волн находятся в диапазоне от 1270 до 1355 нм.
1000BASE-SX. Коротковолновый вариант. Оптоволоконный многомодовый
кабель диаметром 62,5 мкм и длиной до 275 м или диаметром 50 мкм и дли-
ной до 550 м, поддерживающий дуплексные линии. Используемые длины
волн находятся в диапазоне от 770 до 860 нм.
♦ 1000BASE-CX. Этот вариант поддерживает гигабитные линии связи между
устройствами, расположенными в одном помещении или в одной аппаратной
стойке, для которых используются медные перемычки (специализирован-
ные экранированные кабели из витых пар протяженностью не более 25 м).
Каждая линия состоит из отдельной экранированной витой пары, данные
по которой передаются в обе стороны.
♦ 1000BASE-T. Этот вариант использует четыре неэкранированных витых
пары категории 5 для связи с устройствами на расстоянии до 100 м.
Максимальное расстояние
Рис. 6.10. Варианты носителя для гигабитной сети Ethernet (логарифмический масштаб)
Успех сетей Fast Ethernet и Gigabit Ethernet подчеркивает важность выбора
сетевой технологии при решении вопроса сетевого управления. Такие технологии,
как Fibre Channel (мы будем рассматривать ее позднее) и ATM, возможно, техни-
чески для высокоскоростной магистрали представляют собой более совершенные^
6.2. Ethernet
173
варианты благодаря их гибкости и масштабируемости. Однако Ethernet обеспе-
чивает совместимость с существующими локальными сетями, сетевым управляю-
щим программным обеспечением и приложениями. Эта совместимость позволила
технологии Ethernet отпраздновать свое 25-летие и выжить в сегодняшнем быст-
ро развивающемся сетевом окружении.
10-гигабитная сеть Ethernet
Хотя гигабитные сети появились еще относительно недавно, в последние годы
все большее внимание привлекают сети Ethernet со скоростью передачи данных
В 10 Гбит/с. Появление этих сетей вызвано иепрекращающимся ростом трафика
Интернета и интранета. Этот рост вызван рядом факторов, среди которых:
♦ увеличение количества сетевых соединений;
4- увеличение скорости соединения с каждой конечной станцией (например,
10-мегабитные пользователи переходят на скорость 100 Мбит/с, пользова-
тели аналоговых модемов со скорости 56 Кбит/с переходят на DSL и кабель-
ные модемы);
♦ рост популярности широкополосных приложений, таких как видео высоко-
го качества;
• 4 рост популярности веб-приложений и увеличение веб-трафика.
Сначала сетевые менеджеры будут использовать 10-гигабитную сеть Ethernet
для предоставления высокоскоростных локальных магистральных соединений
между коммутаторами большой мощности. По мере увеличения спроса на широ-
кополосную связь технология 10-гигабитной сети Ethernet будет использоваться
для всей сети и распространится на серверные фермы, магистрали и локальные
сети, охватывающие комплексы зданий. Эта технология позволяет поставщикам
услуг Интернета и поставщикам сетевых услуг создавать высокоскоростные ли-
нии по очень низким ценам, связывающие расположенные неподалеку друг от дру-
га коммутаторы и маршрутизаторы.
Эта технология также позволяет создавать региональные и глобальные сети,
соединяющие географически удаленные локальные сети. Таким образом, Ethernet
начинает соревноваться с ATM и другими технологиями глобальных сетей. В боль-
шинстве случаев там, где пользователю требуется перенос данных и транспорт
TCP/IP, технология 10-гигабитной сети Ethernet обладает определенными пре-
имуществами по сравнению с транспортными службами ATM как для конечных
сетевых пользователей, так и для поставщиков сетевых услуг:
♦ Не требуется дорогого съедающего значительную часть пропускной способ-
ности преобразования между пакетами Ethernet и ячейками ATM. Вся сеть
представляет собой Ethernet от одного конца до другого.
4 Комбинация протокола IP и сети Ethernet обеспечивает качество обслужи-
вания и возможности трафика, сходные с предоставляемыми сетью ATM.
Таким образом, пользователи и поставщики услуг получают доступ к пере-
довым технологиям.
174 Глава 6. Высокоскоростные локальные сети
4- Для 10-гигабитной сети Ethernet был определен широкий спектр стандарт-
ных оптических интерфейсов (длины волн и протяженность кабеля), что
позволило оптимизировать ее работу и стоимость для применения в каче-
стве локальных, региональных и глобальных сетей.
Максимальная длина линий связи варьируется от 300 м до 40 км. Линии связи
работают только в полнодуплексном режиме. Для них используется широкий спектр
оптоволоконных кабелей. На рис. 6.11 сравниваются максимальные длины кабе-
лей, определенные для различных скоростей передачи данных по сети Ethernet.
1 Гбит/с <
100 .
Мбиг/с
10
Гбит/с
10
Мбцт/с
Максимальное расстояние
Рис. 6.11. Скорости передачи данных и расстояния для сети Ethernet (логарифмический
масштаб)
6.3. Fibre Channel
По мере того как быстродействие и объем памяти персональных компьютеров, рабо-
чих станций и серверов все увеличиваются, а приложения становятся все сложнее
и все больше используют графику и видео, потребности в доставке процессору дан-
ных с большей скоростью также возрастают. Это требование оказывает влияние
на два аспекта обмена данными с процессором: канал ввода-вывода и сетевую связь.
Канал ввода-вывода представляет собой прямую двухточечную линию связи,
как правило, аппаратно реализованную и рассчитанную на передачу данных с очень
высокими скоростями на очень короткие расстояния. Канал ввода-вывода переда-
ет данные из буфера передающего устройства в буфер принимающего устройства.
При этом передаются только данные пользователя, независимо от формата или
6.3. Fibre Channel
175
назначения данных. Ассоциированная с каналом логика, как правило, обеспечи-
вает минимальное управление, требующееся для передачи данных, а также аппа-
ратное обнаружение ошибок. Обычно по каналам ввода-вывода передаются дан-
ные между процессором и периферийными устройствами, такими как дисководы,
графическое оборудование, устройства чтения компакт-дисков, видеооборудова-
ние ввода-вывода.
Сеть представляет собой набор связанных точек доступа с программной струк-
турой протоколов, обеспечивающей обмен данными. Сеть, как правило, предостав-
ляет множество разных типов служб передачи данных при помощи программно
реализованных сетевых протоколов, обеспечивающих управление потоком, обнару-
жение ошибок и восстановление. Как уже было сказано, сети, как правило, управ-
ляют передачей данных между конечным системами. В зависимости от размера
охватываемых сетями территорий сети подразделяются на локальные, региональ-
ные и глобальные.
Интерфейс Fibre Channel разработан для объединения лучших качеств обеих
технологий — простоты и скорости каналов ввода-вывода и гибкости и взаимосвя-
занности, присущих сетевым коммуникациям. Этот сплав технологий позволяет
разработчикам системы объединить традиционные периферийные соединения, се-
тевую связь между хостами, слабосвязанную кластеризацию процессоров и муль-
тимедийные приложения в едином многопротокольном интерфейсе. В архитектуру
протоколов Fibre Channel включены следующие типы канально-ориентированных
средств:
♦ описатели типов данных для направления полезной нагрузки кадра в интер-
фейсные буферы;
♦ конструкции канального уровня, связанные с индивидуальными операция-
ми ввода-вывода;
спецификации протокольных интерфейсов для поддержания существую-
щих архитектур каналов ввода-вывода, таких как интерфейс SCSI (Small
Computer Systems Interface — интерфейс малых компьютерных систем).
Архитектура протоколов Fibre Channel объединяет следующие возможности,
относящиеся к сетевой работе:
♦ полное мультиплексирование трафика, направляемого многочисленным
получателям;
♦ возможность однорангового соединения любых пар портов по сети Fibre
Channel:
♦ возможность объединения сетей при помощи других технологий соединения.
В зависимости от потребностей приложения для переноса данных может исполь-
зоваться либо канальный, либо сетевой подход. Ассоциацией Fibre Channel (про-
мышленным консорциумом, продвигающим технологию Fibre Channel) перечис-
лены следующие требования, которым должна удовлетворять архитектура Fibre
Channel [81]:
♦ полнодуплексные линии связи, состоящие из пары световодов;
♦ пропускная способность от 100 Мбит/с до 800 Мбит/с по одной линии (для
полнодуплексного канала, соответственно, от 200 Мбит/с до 1600 Мбит/с);
176 Глава 6. Высокоскоростные локальные сети
♦ поддержка расстояний до 10 км;
♦ маленькие коннекторы;
4 высокий коэффициент использования пропускной способности, не завися-
щий от расстояния;
♦ более высокая возможность соединения, чем у существующих многоточеч-
ных линий;
4- широкая доступность (то есть наличие стандартных компонентов);
4- поддержка нескольких уровней соотношения цена—производительность от
небольших систем до суперкомпьютеров;
4- возможность поддержки нескольких наборов интерфейсных команд для су-
ществующих канальных и сетевых протоколов.
Решением стала разработка простого общего транспортного механизма, осно-
ванного на двухточечных соединениях и коммутируемой сети. Эта лежащая в ос-
нове инфраструктура поддерживает широкий спектр канальных и сетевых прото-
колов.
Элементы архитектуры Fibre Channel
Ключевыми элементами сети Fibre Channel являются конечные системы, называ-
емые узлами (nodes), а также сама сеть, состоящая из одного или нескольких сете-
вых элементов. Этот набор коммутирующих элементов называют каркасом (fabric).
Элементы соединены двухточечными линиями между портами индивидуальных
узлов и коммутаторов. Взаимодействие состоит из передачи кадров по двухточеч-
ным линиям.
Для соединения с другими узлами у каждого узла есть один или несколько пор-
тов, называемых N-портами. Аналогично, у каждого элемента каркаса есть несколь-
ко портов, называемых F-портами. Соединение элементов каркаса осуществляет-
ся при помощи двунаправленных линий между портами. При помощи служб
каркаса любой узел может общаться с любым узлом, соединенным с тем же карка-
сом. Вся маршрутизация кадров между N-узлами выполняется каркасом. Каркас
может буферизовать кадры, что позволяет различным узлам соединяться с карка-
сом на разных скоростях передачи данных.
Каркас может быть реализова! i в виде одного элемента каркаса, к которому при-
соединены узлы (простая топология звезды), или в виде более общей топологии
сети, показанной на рис. 6.12. В любом случае каркас отвечает за буферизацию и
маршрутизацию кадров от передающего до получающего узла.
Сеть Fibre Channel существенно отличается от локальных сетей IEEE 802.3.
Она больше похожа на традиционную сеть с коммутацией каналов или коммута-
цией пакетов, чем на типичную локальную сеть с коллективным доступом к несу-
щей. Таким образом, в сети Fibre Channel не возникает вопроса доступа к несу-
щей. Поскольку сеть Fibre Channel основана на коммутирующей сети, она легко
масштабируется, то есть легко можно увеличить количество N-портов, скорость
передачи данных и покрываемые сетью расстояния. Такой подход обеспечивает
большую гибкость. Сеть Fibre Channel может приспосабливаться к новым носите
6.3. Fibre Channel
177
лям данных и скоростям передачи данных путем добавления к существующему
каркасу новых коммутаторов и F-портов. Таким образом, вложенные в эту сеть
инвестиции не теряются при появлении новых технологий и оборудования. Более
того, многоуровневая архитектура протоколов позволяет интерфейсам ввода-вы-
вода и сетевым протоколам приноравливаться к изменениям, сохраняя вложен-
ные ранее средства.
Рис. 6.12. Сеть Fibre Channel
Архитектура протоколов Fibre Channel
Стандарт Fibre Channel описывает пять уровней. На каждом уровне определена
функция или набор родственных функций. Стандартом не диктуется соответствие
Уровней их фактическим реализациям, а также интерфейсы между соседними
уровнями. Скорее, уровень в стандарте представляет собой «чисто бумажное изоб-
ретение», используемое для группирования родственных функций. Уровни стан-
дарта Fibre Channel перечислены ниже.
♦ FC-О. Физический носитель. Включает оптоволоконный кабель для переда-
чи данных на большие расстояния, коаксиальный кабель для высоких ско-
ростей передачи данных на короткие расстояния и экранированную витую
пару для более низких скоростей и коротких расстояний.
♦ FC-1. Протокол передачи данных. Определяет схему кодирования сигнала.
♦ FC-2. Кадровый протокол. Имеет дело с определением топологий, форматов
кадров, управлением потоком, контролем ошибок и группированием кадров
в логические объекты, называемые последовательностями и обменами.
178 Глава 6. Высокоскоростные локальные сети
♦ FC-3. Общие службы. Сюда относят групповую рассылку.
♦ FC-4. Отображение. Определяет отображение различных канальных и се-
тевых протоколов на протоколы Fibre Channel, включая IEEE 802, ATM, IP
и интерфейс SCSI.
Физические носители и топологии Fibre Channel
Одно из главных достоинств стандарта Fibre Channel состоит в том, что он предо-
ставляет широкий спектр вариантов использования физических носителей, ско-
ростей передачи данных по этим носителям и топологий сети.
Физические носители
К физическим носителям, поддерживаемым стандартом Fibre Channel, относятся
экранированная витая пара, коаксиальный видеокабель и оптоволоконный кабель.
Скорости передачи данных могут варьироваться от 100 Мбит/с до 3,2 Гбит/с. Дли-
на двухточечной линии связи может быть от 33 м до 10 км.
Топологии
Наиболее общая топология, поддерживаемая стандартом Fibre Channel, называ-
ется топологией каркаса (fabric), или коммутируемой (switched) топологией. Это
произвольная топология, требующая по меньшей мере одного коммутатора для
соединения нескольких конечных систем. Может быть и несколько коммутаторов,
образующих коммутируемую сеть, некоторые из которых (или все) также обслу-
живают конечные узлы.
Маршрутизация в топологии каркаса осуществляется прозрачно для узлов.
У каждого порта конфигурации есть уникальный адрес. Когда данные от узла
передаются в каркас, крайний коммутатор, с которым соединен узел, определяет
местонахождение порта получателя. Затем коммутатор либо доставляет кадр
другому узлу, присоединенному к тому же коммутатору, либо передает кадр со-
седнему коммутатору, тем самым начиная маршрутизацию кадра к удаленному
получателю.
Топология каркаса обеспечивает масштабируемость пропускной способности:
по мере добавления дополнительных портов суммарная пропускная способность
сети возрастает, минимизируя таким образом перегрузку и конкуренцию и уве-
личивая объем передаваемых данных. Каркас не зависит от протокола и в значи-
тельной степени нечувствителен к расстояниям. Сама технология коммутатора и
линий передачи, соединяющих коммутатор с узлами, может быть изменена, и это
не влияет па общую конфигурацию. Другое преимущество топологии каркаса за-
ключается в том, что нагрузка на узлы в такой топологии минимизируется. Инди-
видуальный узел сети Fibre Channel (оконечная система) ответствен только за
управление простым двухточечным соединением между собой и каркасом. Каркас
же отвечает за маршрутизацию между портами и обнаружение ошибок.
Помимо топологии каркаса стандартом Fibre Channel определены еще две то-
пологии. При двухточечной топологии существует только два порта, соединенных
6.3. Fibre Channel
179
напрямую, без промежуточных коммутаторов каркаса. В этом случае маршрутиза-
ции нет. Кольцо с арбитражной логикой представляет собой простую недорогую
топологию для соединения в кольцо до 126 узлов. Работа кольца с арбитражной
логикой в первом приближении эквивалентна работе протоколов уже обсуждав-
шегося ранее маркерного кольца.
Топологии, носители данных и скорости передачи данных могут комбиниро-
ваться, формируя оптимальную конфигурацию для данного сайта. На рис. 6.13
показан пример применения сети Fibre Channel.
Соединение
с кластерами
высокопроизводительных
рабочих станций
Кластеризация
дисковых ферм
Соединение
мэйнфреймов
друг с другом
Выделение высокоскоростных
каналов серверным фермам
Рис. 6.13. Пять вариантов применения сети Fibre Channel
Глобальная сеть
ATM
Присоединение
Коммутирующий
каркас Fibre Channel
локальных и глобальных
сетей к магистрали
Перспективы развития Fibre Channel
Технология Fibre Channel поддерживается промышленной группой, известной как
ассоциация Fibre Channel (Fibre Channel Association). Сегодня на рынке можно
приобрести самые разные интерфейсные карты для различных приложений.
Наиболее широкое распространение технология Fibre Channel получила как бо-
лее совершенное средство соединения периферийных устройств, предоставляя
Услуги, которые могут, в конечном итоге, заменить такие схемы, как интерфейс
SCSI. Это технически привлекательное решение для общих требований, предъяв-
ляемых высокоскоростными локальными сетями, но ему приходится конкури-
ровать с локальными сетями Ethernet и ATM. Принимая решение о выборе тех-
180 Глава 6. Высокоскоростные локальные сети
нологии, менеджер должен, в первую очередь, учитывать вопросы стоимости
и производительности.
6.4. Беспроводные локальные сети
В последние несколько лет беспроводные локальные сети заняли существенную
нишу на рынке локальных сетей. Организации все в большей степени осознают,
что беспроводные локальные сети представляют собой незаменимое дополнение
к традиционным проводным локальным сетям, обеспечивая мобильность, созда-
ние временных сетей, а также работу на местности, где прокладка обычных кабе-
лей затруднительна.
Как видно из названия, беспроводная локальная сеть — это локальная сеть, ис-
пользующая беспроводные каналы связи. До относительно недавнего времени бес-
проводные локальные сети почти не были распространены. Причиной тому были
высокие цены, низкие скорости передачи данных, профессиональные соображе-
ния безопасности и требования лицензирования. Когда эти проблемы были реше-
ны, популярность беспроводных локальных сетей стала быстро расти.
Применение беспроводных локальных сетей
Впервые беспроводные локальные сети, появившиеся в конце 80-х годов, были
представлены на рынке как замена традиционных локальных сетей. Беспроводная
локальная сеть позволяет сэкономить на прокладке кабелей и облегчает задачу
перемещения узлов сети, а также других изменений структуры сети. Однако со
временем мотивация изменилась. Во-первых, возросла осведомленность о потреб-
ностях в локальных сетях, в результате архитекторы, проектируя новые здания,
заранее включали в свои проекты достаточно кабелей для передачи данных. Во-
вторых, благодаря прогрессу в области технологии передачи данных линии связи
из витых пар (категорий 3 и 5) стали надежнее. В большей части старых зданий
уже в избытке имеется кабельная проводка категории 3, а многие более новые зда-
ния заранее оснащаются кабелями категории 5. Таким образом, вытеснения тра-
диционных локальных сетей беспроводными не произошло.
Однако в ряде ситуаций беспроводная локальная сеть может заменить кабель-
ную локальную сеть. Среди примеров можно назвать строения с большими откры-
тыми участками, например фабрики, торговые залы фондовых бирж и супермар-
кетов, складские помещения. Беспроводные локальные сети также незаменимы
в исторических зданиях, в которых традиционной проводки типа витой пары не-
достаточно, а прокладка новых кабелей запрещена. Эти сети удобны также в ма-
леньких офисах, в которых прокладка кабеля является экономически нецелесооб-
разной. Во всех подобных случаях беспроводная локальная сеть предоставляет
эффективную и более привлекательную альтернативу традиционным кабельным
сетям. В большинстве случаев у организации также есть и обычная кабельная ло-
кальная сеть для обслуживания серверов и некоторых стационарных рабочих стан-
ций. Например, у предприятия может быть офис, находящийся вдали от здания.
6.4. Беспроводные локальные сети
181
цеха, и этот офис нужно объединить с цехом в единую сеть. Поэтому обычно бес-
проводная локальная сеть соединяется с кабельной локальной сетью, и эта область
приложения называется расширением локальных сетей.
На рис. 6.14 показана типичная конфигурация простой беспроводной локальной
сети. В качестве магистрали в этой сети используется локальная сеть, например
Ethernet, обслуживающая серверы, рабочие станции и один или несколько мостов
или маршрутизаторов для связи с другими сетями. Кроме того, в этой локальной
сети используется управляющий модуль (Control Module, СМ), действующий в ка-
честве интерфейса с беспроводной локальной сетью. Управляющий модуль для
связи беспроводной локальной сети с магистралью реализует функциональность
моста или маршрутизатора. Он поддерживает определенную логику управления,
например схему опроса или передачи маркера для управления доступом конечных
систем к несущей. Обратите внимание на то, что конечные системы представляют
собой автономные устройства, такие как рабочая станция или сервер. В конфигу-
рацию беспроводной локальной сети также могут входить хабы или другие пользо-
вательские модули (User Modules, UM), управляющие станциями кабельной сети.
Рис. 6.14. Пример конфигурации одной ячейки беспроводной локальной сети
Конфигурацию, показанную на рисунке, можно назвать одной ячейкой беспро-
водной локальной сети. Все беспроводные конечные системы этой локальной
182
Глава 6. Высокоскоростные локальные сети
сети находятся в зоне действия одного управляющего модуля. Другой распрост-
раненной конфигурацией является беспроводная локальная сеть из множества
ячеек. В этом случае несколько управляющих модулей соединены кабельной ло-
кальной сетью. Каждый управляющий модуль поддерживает несколько беспровод-
ных конечных систем в своей зоне приема/передачи. Например, для инфракрас-
ных локальных сетей зона передачи ограничена одной комнатой. Поэтому каждая
комната офисного здания, в которой требуется поддержка беспроводной локаль-
ной сети, представляет собой одну ячейку.
Другое применение технологии беспроводных локальных сетей — обеспечение
доступа к локальной сети оснащенной антенной мобильной станции, например
лэптопа или ноутбука. Пример использования такого соединения — передача дан-
ных с персонального мобильного компьютера сотрудника, вернувшегося из коман-
дировки, на офисный сервер. Мобильный доступ также полезен для крупных от-
крытых пространств, таких как университетские кампусы или комплексы зданий
корпораций. В обоих случаях пользователи могут перемещаться по территории со
своими портативными компьютерами, и им может понадобиться доступ к серве-
рам кабельной локальной сети из самых разных мест.
Еще пример беспроводной локальной сети — временная локальная сеть без цен-
трализованного сервера, развертываемая для решения возникших в конкретный
момент задач. Например, группа сотрудников может собраться в конференц-зале
со своими портативными компьютерами. Эти сотрудники могут соединить свои
компьютеры в локальную сеть на время собрания.
Требования к беспроводным локальным сетям
Беспроводные локальные сети должны удовлетворять тем же требованиям, что и
любая локальная сеть, то есть обладать высокой пропускной способностью, спо-
собностью покрывать короткие расстояния, обеспечивать полную связность для
присоединенных станций, а также возможность широковещательной рассылки.
Кроме того, имеется ряд требований, специфических для окружения беспровод-
ных локальных сетей. Ниже перечислены самые важные требования:
♦ Пропускная способность. Протокол управления доступом к носителю (МАС)
должен как можно эффективнее использовать носитель.
♦ Количество узлов. Беспроводным локальным сетям может потребоваться
поддерживать сотни узлов во множестве ячеек.
♦ Соединение с магистральной локальной сетью. В большинстве случаев тре-
буется соединение со станциями на кабельной магистральной локальной
сети. Для локальных сетей, входящих в ту или иную инфраструктуру, это
легко достигается при помощи управляющих модулей, соединенных с ло-
кальными сетями обоих типов. Может также потребоваться возможность
обслуживания мобильных пользователей и поддержка временных беспро-
водных локальных сетей.
Зона обслуживания. Как правило, зона, покрываемая беспроводной локаль-
ной сетью, представляет собой круг диаметром от 100 до 300 м.
6.4. Беспроводные локальные сети
183
♦ Энергопотребление. Мобильные пользователи используют рабочие станции
с питанием от батарей, которые должны работать в течение довольно долго-
го периода. Это означает, что протокол МАС, предполагающий постоянный
опрос точек доступа мобильными узлами, является неприемлемым. Так-
же недопустимы частые «рукопожатия» с базовой станцией. Типичные
реализации беспроводных локальных сетей позволяют снижать энергопо-
требление станции в то время, когда станция не использует сеть, напри-
мер в режиме ожидания.
+ Устойчивость передачи и безопасность. Если не спроектировать беспровод-
ную локальную сеть должным образом, она может быть подвержена поме-
хам и легко прослушиваться.
♦ Работа нескольких сетей в одной области. По мере роста популярности бес-
проводных локальных сетей вероятность одновременной работы несколь-
ких сетей в одной и той же области или в соседних областях, в которых
возможна интерференция, становится все выше. Подобная интерференция
может нарушить нормальную работу алгоритма МАС, а также создать усло-
вия для несанкционированного доступа к локальной сети.
♦ Нелицензионное использование сети. Пользователи предпочли бы покупать
и применять такое программное и аппаратное обеспечение для беспровод-
ных локальных сетей, для которого не требуется получение лицензии на ча-
стотный диапазон.
♦ Роуминг. Протокол МАС, используемый в беспроводных локальных сетях,
должен позволять мобильной станции перемещаться из одной зоны приема
(ячейки) в другую.
♦ Динамическое конфигурирование. Вопросы адресации и сетевого управления
протокола МАС должны позволять динамическое и автоматизированное
добавление, удаление и перемещение конечной системы без нарушения ра-
боты других пользователей.
Комитетом IEEE802.il был разработан набор стандартов для беспроводной
локальной сети. Обзору этих стандартов посвящен остаток этой главы.
Архитектура IEEE 802.11
На рис. 6.15 показана модель, разработанная рабочей группой IEEE 802.11. Ми-
нимальным строительным блоком беспроводной локальной сети является базовый
набор служб (Basic Service Set, BSS), состоящий из некоторого количества станций,
выполняющих одинаковый протокол МАС и конкурирующих за доступ к одному
и тому же носителю коллективного доступа. Основной набор служб может быть
изолированным или соединяться с магистральной распределительной системой
(Distribution System, DS) через точку доступа (Access Point, АР). Точка доступа
Функционирует подобно мосту. Протокол МАС может быть полностью распреде-
ленным или централизованным, управляясь центральной функцией координации,
размещающейся в точке доступа. Базовый набор служб, как правило, соответству-
184 (лава 6. Высокоскоростные локальные сети
ет ячейке (cell). Распределительная система может быть коммутатором, кабельной
сетью или беспроводной сетью.
На рис. 6.15 показана наиболее простая конфигурация, в которой каждая стан-
ция принадлежит одному набору BSS, то есть каждая станция находится в зоне
приема/передачи только других станций того же набора BSS. Два набора BSS мо-
гут также перекрываться географически, так что одна станция может входить в не-
сколько наборов BSS. Более того, связь между станцией и набором BSS является
динамической. Станции могут отключаться, выходить из зоны приема и входить
в зону приема.
Рис. 6.15. Архитектура IEEE 802.11
Расширенный набор служб (Extended Service Set, ESS) состоит из двух или
более базовых наборов служб, соединенных распределительными системами. Как
правило, распределительная система представляет собой кабельную магистраль-
ную локальную сеть, но может также быть любой компьютерной сетью. Для уров-
ня LLC (Logical Link Control — управление логическим соединением) расширен-
ный набор служб представляется в виде единой локальной сети.
Как показано на рисунке, точка доступа (АР) реализована в качестве части
станции. Точка доступа поддерживает логику доступа к распределительной сис-
теме. Чтобы интегрировать архитектуру IEEE 802.11 с традиционной кабельной
локальной сетью, используется портал. Логика портала реализована в таком уст-
ройстве, как мост или маршрутизатор, являющемся частью кабельной локальной
сети и соединенном с распределительной системой.
6.4. Беспроводные локальные сети
185
Службы IEEE 802.11
Стандартом IEEE 802.11 определен ряд служб, которые должны предоставляться
беспроводными локальными сетями для обеспечения функциональности, эквива-
лентной функциональности кабельных локальных сетей. Наиболее важные служ-
бы перечислены ниже.
♦ Назначение ассоциации. Установление начальной связи между станцией и
точкой доступа. Прежде чем станция сможет передавать или принимать кад-
ры по беспроводной локальной сети, должны быть известны ее идентифи-
катор и адрес. Для этого станция должна быть ассоциирована с точкой до-
ступа. Затем точка доступа может передать эту информацию другой точке
доступа для упрощения маршрутизации и доставки кадров.
♦ Переназначение ассоциации. Передача назначенной ассоциации от одной
точки доступа к другой, что обеспечивает возможность перемещения мо-
бильных станций.
♦ Удаление ассоциации. Уведомление об удалении назначенной ассоциации,
посылаемое либо станцией, либо точкой доступа. Станция должна выдать
это уведомление, прежде чем покинет зону или выключится. Хотя средства
МАС защищают себя от станций, исчезающих без уведомления.
♦ Аутентификация используется для выяснения подлинности станций друг
для друга. В кабельной сети, как правило, предполагается, что физический
доступ к носителю является достаточным основанием для права доступа к
локальной сети. Это предположение неверно для беспроводной локальной
сети, в которой для присоединения достаточно соответствующим образом
настроенной антенны. Для установки подлинности друг друга общающиеся
станции используют службу аутентификации. Стандартами не определя-
ется схема аутентификации, поскольку она может варьироваться от от-
носительно ненадежного «рукопожатия» до схем шифрования с открытым
ключом.
♦ Секретность требуется для предотвращения чтения содержимого сообще-
ний не теми, кому они предназначаются. Для обеспечения секретности стан-
дарт разрешает использовать шифрование.
Уровни протокола IEEE 802.11
Стандартом IEEE802.il определена многоуровневая архитектура протоколов,
позволяющая реализовать только что описанные службы (рис. 6.16). На нижнем,
физическом уровне определяются частотный диапазон, скорость передачи данных
и другие детали фактической радиопередачи. Над ним располагается уровень
MAC (Medium Access Control — управление доступом к носителю), управляющий
Доступом к совместно используемому радиодиапазону, так что передачи станций
не мешают друг другу. Нижний подуровень уровня МАС представляет собой функ-
цию распределенной координации (Distributed Coordination Function, DCF).
186
Глава 6. Высокоскоростные локальные сети
Функция DCF использует состязательный алгоритм Ethernet для предоставления
доступа всему трафику. Обычный асинхронный трафик использует функцию DCF
напрямую. Функция точечной координации (Point Coordination Function, PCF)
реализует централизованный алгоритм МАС, используемый для предоставления
обслуживания без конкуренции, что достигается путем поочередного опроса стан-
ций. Функция PCF предоставляется трафику более высокого приоритета или тра-
фику с более высокими требованиями к параметрам времени. Наконец, уровень
LLC (Logical Link Control — управление логическим соединением) предоставляет
интерфейс с более высокими уровнями и выполняет такие базовые функции ка-
нального уровня, как контроль ошибок.
Функция точечной координации
Уровень
МАС
Фужция распределенной координации
Расширенный
спектр
со скачкообразной
перестройкой
частоты
2,4 ГГц
1 Мбит/с
2 Мбит/с
Расширенный
спектр прямого
распространения
2,4 ГГц, 1 Мбит/с
2 Мбит/с
Инфракрасные
волны
1 Мбит/с
2 Мбит/с
Мультиплексирование
путем
ортогонального
разделения
частоты 5 ГГц
6,9,12,18,
24,36,48,
5 Мбит/с
Расширенный
спектр прямого
распространения
2,4 ГГц, 5,5 Мбит/с
11 Мбит/с
IEEE 802,11
IEEE 802,11а
IEEE 802,11b
Рис. 6.16. Архитектура протоколов IEEE 802.11
Физический уровень IEEE 802.11
Спецификация физического уровня для сети IEEE 802.11 разрабатывалась в три
этапа: первая часть была выпущена в 1997 г., а остальные две части — в 1999 г. Пер-
вая часть, просто называвшаяся IEEE802.il, включала уровень МАС и три
спецификации физического уровня, две в диапазоне 2,4 ГГц и одна в инфракрас-
ном диапазоне, все работающие на скоростях от 1 до 2 Мбит/с. Беспроводная сеть
стандарта IEEE 802.1 la работает в диапазоне 5 ГГц на скоростях до 54 Мбит/.
6.4. Беспроводные локальные сети
187
Сеть стандарта IEEE 802.11b работает в диапазоне 2,4 ГГц на скоростях 5,5 Мбит/с
и 11 Мбит/с.
В оригинальном издании стандарта IEEE 802.11 определены три физических
носителя:
4- Расширенный спектр прямого распространения (Direct-Sequence Spread
Spectrum, DHSS), работающий в частотном диапазоне 2,4 ГГц со скоростью
передачи данных от 1 Мбит/с до 2 Мбит/с.
4- Расширенный спектр со скачкообразной перестройкой частоты (Frequency-
Hopping Spread Spectrum, FHSS), работающий в частотном диапазоне
2,4 Мбит/с со скоростью передачи данных от 1 Мбит/с до 2 Мбит/с.
4- Сигнал инфракрасного диапазона со скоростью передачи данных от 1 Мбит/с
до 2 Мбит/с с длиной волны от 850 до 950 нм.
Инфракрасный вариант не получил большого успеха на рынке. Остальные две
схемы работают с расширенным спектром. При этом используется значительно
больший частотный диапазон, чем это необходимо для поддержания требуемой
скорости передачи данных. В результате удается минимизировать взаимные
помехи и существенно снизить частоту ошибок. В случае FHSS рабочая частота
меняется скачкообразно. Таким образом, если на какой-либо частоте появляется
помеха или наблюдается снижение производительности, это затрагивает только
небольшую часть общего трафика. Метод DSSS эффективно увеличивает скорость
передачи данных, преобразуя каждый бит данных в строку битов, то есть для пе-
редачи двоичных 0 и 1 используются две разных битовых строки. Для более высо-
ких скоростей передачи данных задействуют более широкие диапазоны частот.
В результате протяженность каждого бита во времени увеличивается, что позво-
ляет минимизировать влияние помех и затухания сигнала. Более простой метод
FHSS был реализован в большинстве ранних сетей 802.11. Следом в схеме 802.11
был реализован более эффективный метод DSSS. Однако применение всех ранних
вариантов оригинальных сетей стандарта 802.11 было ограничено в связи с низки-
ми скоростями передачи данных.
Стандарт IEEE 802.11b представляет собой расширение схемы DSSS стан-
дарта IEEE 802.11. Он обеспечивает передачу данных на скоростях 5,5 Мбит/с
и 11 Мбит/с. Более высокие скорости передачи данных достигаются при помощи
более сложной техники модуляции сигнала. Выпуск спецификации IEEE 802.11b
привел к быстрому заполнению рынка соответствующими товарами, включая на-
боры микросхем, карты для персонального компьютера, точки доступа и системы.
Первой компанией, предложившей на рынке продукты 802.11b, была корпорация
Apple Computer со своим переносным компьютером iBook, использующим бес-
проводную сетевую связь AirPort. За ней последовали другие компании, вклю-
чая Cisco, ЗСот и Dell. Хотя все эти новые продукты основаны на одном и том же
стандарте, было не ясно, смогут ли успешно взаимодействовать устройства от раз-
ных производителей. Чтобы решить эту проблему, союз WEC A (Wireless Ethernet
Compatibility Alliance — союз совместимости беспроводных сетей Ethernet) соз-
дал тестовый набор для проверки возможности совместной работы продуктов
188
Глава 6. Высокоскоростныелокальные сети
стандарта 802.11b. Эти тесты проводятся, и некоторые продукты уже получил»
сертификаты.
Еще одна проблема, касающаяся как оригинальных продуктов 802.11, так и про-
дуктов стандарта 802.11b, заключается в возможности интерференции с другими
системами, работающими в частотном диапазоне 2,4 ГГц, такими как Bluetooth,
HomeRF и многими другими устройствами, использующими ту же часть спектра
(включая мониторы для слежения за детьми и дистанционные пульты для откры-
вания гаража). Этот вопрос изучается специальной исследовательской группой
IEEE 802.15.
Хотя система 802.11b имела определенный успех, спрос на нее в связи с огра-
ниченной скоростью не был большим. Чтобы удовлетворить спрос на действи-
тельно высокоскоростные локальные сети, был разработан стандарт IEEE 802.1 la.
В спецификации IEEE 802.11а задействуется частотный диапазон 5 ГГц. В отличие
от спецификаций, работающих в диапазоне 2,4 ГГц, стандартом 802.11 вместо схе-
мы расширенного спектра используется метод OFDM (Orthogonal Frequency
Division Multiplexing — мультиплексирование путем ортогонального разделения
частоты). В методе OFDM, также называемом многочастотной модуляцией, исполь-
зуется несколько несущих частот (до 52), по которым передаются биты каждого
канала. Стандартом IEEE 802.1 la определены допустимые скорости передачи дан-
ных 6, 9, 12, 18, 24, 36, 48 и 54 Мбит/с. Продукты первого поколения стандарта
IEEE 802.11b должны появиться в ближайшее время. Тестирование союза WECA
на совместимость и соответствие стандарту также скоро начнется.
6.5. Рекомендуемые
литература и веб-сайты
Все обсуждавшиеся в этой главе локальные сети подробно описаны в [214].
В [212] предоставляется краткий, но полный обзор всех систем спецификации
802.3, работающих на скоростях от 10 Мбит/с до 1 Гбит/с, включая советы по кон-
фигурации односегментной сети каждого типа носителя, а также директивы для
формирования многосегментной сети Ethernet на разных типах носителей. В [203]
и [129] представлены два замечательных описания 100-мегабитной и гигабитной
сетей Ethernet. Хорошую статью о Gigabit Ethernet представляет собой [87]. Офи-
циальный документ [1] дает полезное введение в сеть Ethernet, работающую на
скорости 10 Гбит/с.
В [191] содержится подробный обзор технологии Fibre Channel. В [92] име-
ется детальное описание технологии беспроводных локальных сетей, стандартов
IEEE802.il и многочисленных конкретных примеров. [65] представляет собой
детальную обзорную статью, посвященную стандартам 802.11.
Ниже перечислены рекомендуемые веб-сайты.
♦ Interoperability Lab. Сайт университета Нью-Гемпшира, посвященный тес-
тированию высокоскоростных локальных сетей.
♦ Charles Spurgeon’s Ethernet Web Site. Подробная подборка информации о сети
Ethernet, включая ссылки и документы.
6.6. Задания
189
♦ 10 Gigabit Ethernet Alliance. Сайт группы, которая занимается продвижени-
ем стандарта 10-гигабитной сети Ethernet.
♦ Fibre Channel Industry Association. У чебный материал, официальная докумен-
тация, ссылки на производителей и описания приложений Fibre Channel.
♦ Storage Network Industry Association. Сайт промышленного форума разработ-
чиков, интеграторов и профессионалов в сфере информационных техноло-
гий, развивающих и продвигающих технологию сетей с промежуточным
хранением.
♦ Wireless LAN Alliance. Сайт предоставляет введение в технологию, включая
обсуждение вопросов реализации и конкретных примеров использования.
На этом сайте также содержатся ссылки на другие сайты по этой же теме.
♦ Wireless Ethernet Compatibility Alliance. Сайт промышленной группы, занима-
ющейся взаимодействием сетей 802.11 друг с другом, а также с сетью Ethernet.
6.6. Задания
1. Рассмотрим локальную сеть с общей шиной, несколькими станциями, на-
ходящимися на равном друг от друга расстоянии, со скоростью передачи
данных 10 Мбит/с и длиной шины 1 км.
а) Чему равно среднее время передачи кадра из 1000 бит другой станции,
если измерять от начала передачи до конца получения? Предполагается,
что скорость распространения сигнала равна 200 м/мкс;
б) Если две станции одновременно начинают передачу, их пакеты переме-
шаются друг с другом. Сколько времени в секундах потребуется станции
для обнаружения этого факта, если станция опрашивает шину во время
передачи? Чему равно это время в битах?
2. Выполните задание 1 для скорости передачи данных 100 Мбит/с.
3. Недостаток конкурентного подхода в локальных сетях заключается в том,
что из-за одновременных попыток нескольких станций получить доступ к
каналу теряется часть пропускной способности сети. Предположим, что вре-
мя разделено на интервалы, при этом каждая из Мстанций пытается переда-
вать в течение одного интервала с вероятностью р. Какой процент интерва-
лов времени будет теряться из-за одновременных попыток передачи?
4. Простой протокол управления доступом к носителю мог бы заключаться в
использовании фиксированной схемы мультиплексирования с временным
разделением (Time Division Multiplexing, TDM). Каждой станции назнача-
ется одинаковый интервал времени. Для локальной сети с общей шиной
предполагается, что длительность каждого интервала составляет время, необ-
ходимое для передачи 100 бит, плюс время задержки прохождения сигнала
по всей сети. Станции прослушивают несущую в течение всех интервалов
времени для приема данных. Скорость распространения сигнала считайте
190
(лава 6. Высокоскоростные локальные сети
равной 2 108 м/с. Чему равны максимальное количество станций и макси-
мальная пропускная способность каждой станции для шины локальной сети
длиной 1 км со скоростью передачи данных 10 Мбит/с?
5. Алгоритм двоичного экспоненциального отката определен стандартом IEEE 802
следующим образом: «Задержка — это сумма нескольких интервалов време-
ни. Количество интервалов времени для ожидания перед n-й попыткой по-
вторной передачи выбирается как равномерно распределенное случайное
целое число в диапазоне от 0 до 2К, где К = min(n, 10)». Интервал времени
выбирается приблизительно равным удвоенной задержке распространения
сигнала по всей шине. Предполагается, что у двух станций всегда есть кадр
для передачи. Чему равно среднее количество попыток повторной переда-
чи после коллизии? Каков будет ответ, если кадр для передачи всегда есть
у трех станций?
Часть III
Моделирование и оценка
производительности
Читатель, без сомнения, стремится поскорее перейти к изучению важных вопро-
сов управления трафиком, маршрутизации и сжатия данных, ради которых и была
куплена эта книга. Однако назначение всех алгоритмов и протоколов, которые мы
будем обсуждать, — управление трафиком изолированных и объединенных сетей.
Поэтому мы должны понимать, как характеризовать трафик и как разные типы
трафика сказываются на производительности. Этой теме посвящена часть III.
Ключ к проектированию высокопроизводительных сетей заключается в способ-
ности моделировать и оценивать параметры производительности. Разработчик
должен быть способен на основании наблюдений оценить объем и характеристики
будущего трафика. Статистические характеристики трафика влияют на разнообраз-
ные аспекты проектирования и конфигурирования, включая протоколы маршрути-
зации, протоколы резервирования ресурсов, дисциплины очередей в маршрутиза-
торах и ATM-коммутаторах, а также размеры буферов. Более того, пользователь
должен уметь охарактеризовать планируемый трафик, чтобы принять верные ре-
шения в области резервирования ресурсов.
Для описания потока данных большое значение представляет ряд параметров.
♦ Характеристики пропускной способности:
♦ Средняя скорость. Средняя нагрузка на сеть, оказываемая источником,
представляет собой ключевой параметр в определении объема ресурсов,
которые должны быть выделены этому источнику. Средняя скорость пе-
редачи данных определяет тот поток, который источник может поддер-
живать в течение длительного периода времени.
♦ Пиковая скорость. Этот параметр определяет для сети максимальный
трафик, который она в состоянии поддерживать, либо выделяя соответ-
ствующие ресурсы, либо резервируя достаточный объем буферного про-
странства для сглаживания пульсаций.
♦ Неравномерность. Пиковая скорость представляет собой один из крите-
риев неравномерности. Более точным критерием является неравномер-
ность пропускной способности. Неравномерность характеризует непос-
тоянство трафика источника и представляет собой индикатор того, до
какой степени статистическое мультиплексирование может использо-
ваться для повышения эффективности.
♦ Характеристики задержки:
♦ Задержка передачи. Этот параметр представляет собой задержку, вноси-
мую сетью при передаче данных от отправителя к получателю. Макси-
192 Часть III. Моделирование и оценка производительности
мальное время задержки также может быть требованием, которое вы-
двигается приложением.
♦ Вариация задержки. Вариация задержки является важным параметром
приложений реального времени, в которых данные, воспроизводящиеся
получателем, должны прибывать с постоянной скоростью, равной ско-
рости, с которой отправитель эти данные передает.
Эти и подобные им параметры очень важны для конфигурации сети и устрой-
ства протоколов. Для принятия эффективных решений необходимо довольно точ-
но моделировать трафик данных.
Анализ очередей представляет собой простое и легко интерпретируемое сред-
ство получения полезных результатов для управления работой по проектирова-
нию сетей. В течение десятилетий анализ очередей основывался на предположе-
нии о соответствии типа трафика распределению Пуассона. Затем совершенно
неожиданно исследователи из Бостонского университета и лаборатории Bellcore
опубликовали удивительные результаты. Как оказалось, по крайней мере в неко-
торых случаях трафик описывается не распределением Пуассона, а является по
своей природе самоподобным, или фрактальным. При таком трафике производи-
тельность сети не подчиняется аккуратным формулам анализа очередей, а имеют
место большие задержки и снижение пропускной способности. С момента публи-
кации эти результаты были многократно подтверждены на трафиках самых раз-
ных типов. Все эти вопросы рассматриваются в части III.
♦ Глава 7. Обзор вероятностных и стохастических процессов. В этой главе
содержится обзор концепций, имеющих отношение к части III. Некоторым
читателям будет полезно освежить свои знания в этой области. Для читате-
лей, не знакомых с данным предметом, в этой главе содержится достаточно
информации для понимания материала глав 8 и 9.
♦ Глава 8. Анализ очередей. Анализ очередей очень важен для тех, кто инте-
ресуется передачей данных и компьютерными сетями. Многие вопросы про-
ектирования в этих областях, а также многие другие вопросы кибернетики
могут быть представлены при помощи модели очередей. Модель очередей
позволяет аналитику быстро получить приближенную оценку поведения
системы при разной нагрузке.
Назначение глав 8 и 9 — снабдить читателя базовыми инструментами ана-
лиза очередей. Акцент сделан, во-первых, на понимании допущений, лежа-
щих в основе анализа очередей, и, во-вторых, на предоставлении формул,
применимых в разных ситуациях. В этой главе обсуждаются очереди к од-
ному и нескольким серверам, а также сети очередей.
♦ Глава 9. Самоподобный трафик. Хотя анализ очередей, описанный в главе 8,
сохраняет свою полезность и даже важность для разработчиков сетей и прото-
колов, ряд недавних исследований свидетельствуют о том, что большая часть
трафика высокоскоростных сетей не проявляет тех случайных свойств, кото-
рые необходимы для справедливости уравнений теории очередей. Напротив,
этот трафик обладает самоподобными, или фрактальными, свойствами. В гла-
ве 9 читатель знакомится с концепцией самоподобия. Затем концепция само-
подобия применяется к трафику и изучаются вопросы производительности.
Глава 7
Обзор вероятностных
и стохастических процессов
Относительно поздний подъем теории вероятности показы-
вает, насколько трудна эта тема для понимания, и множе-
ство парадоксов ясно демонстрируют отсутствие у нас, лю-
дей, хорошо обоснованной интуиции в этой области.
В теории вероятности при решении задачи и при последу-
ющем применении результатов к реальному миру разработ-
ка модели в значительной степени является искусством.
Ричард Хамминг. Искусство вероятности
Прежде чем мы перейдем к изучению анализа очередей и самоподобного трафика,
познакомимся с основами теории вероятности и стохастических процессов. Чита-
тель, знакомый с этой темой, может безо всякого риска пропустить эту главу.
Глава начинается со знакомства с некоторыми элементарными понятиями тео-
рии вероятности и случайных переменных. Этот материал нужен для понимания
главы 8, посвященной анализу очередей. Вслед за этим мы обсудим тему стохас-
тических процессов, знание которой важно для понимания вопросов самоподоб-
ного трафика, рассматриваемых в главе 9.
7.1. Вероятность
Здесь будут описаны основы теории вероятности, очень кратко, но достаточно для
понимания остальной части главы.
Определение вероятности
Вероятность представляет собой некое число, поставленное в соответствие собы-
тию. Вероятность (probability) Рг[Л] события А представляет собой число в диа-
пазоне от 0 до 1, соответствующее правдоподобности того, что событие А произой-
дет. Обычно мы говорим об эксперименте и получении результата. Событие А
представляет собой один результат из множества возможных результатов, и веро-
ятность ставится в соответствие с этим событием.
194 Глава 7. Обзор вероятностных и стохастических процессов
Трудно добиться твердого понимания понятия вероятности. В различных при-
менениях теории вероятности вероятность предстает в разном свете. В самом деле
существует несколько определений вероятности. Здесь мы рассмотрим три из них.
Аксиоматическое определение
Формальный подход к определению вероятности заключается в формулировании
ряда аксиом, определяющих понятие вероятности, и вывода из них законов веро-
ятности, которые могут использоваться для выполнения полезных вычислений.
Аксиомы представляют собой утверждения, которые должны быть приняты без
доказательств. Как только аксиомы приняты, можно доказать каждый закон.
В аксиомах и законах используются следующие концепции теории множеств.
Достоверное событие (certain event) Q — это событие, случающееся в каждом экс-
перименте. Оно состоит из пространства выборок (sample space) всех возможных
результатов. Объединение (union) А и В двух событий Ап В представляет собой
событие, происходящее, когда происходит либо событие А, либо В, либо оба со-
бытия А и В. Пересечение (intersection) событий АпВ, также записываемое как
АВ, представляет собой событие, происходящее, когда происходят оба события:
и А, и В. События А и В называют взаимно исключающими (mutually exclusive), если
эти события не могут произойти одновременно, то есть одно событие исключает
другое. Событие А, называемое дополнением (complement) события А, представ-
ляет собой событие, происходящее, когда событие А не происходит, то есть это
множество всех результатов пространства выборок, не входящих в пространство
события А. Эти понятия легко представить наглядно при помощи диаграмм Венна
(Venn), представленных на рис. 7.1. На каждой диаграмме заштрихованная часть
соответствует выражению под диаграммой. Части на рис. 7.1, виг соответствуют
случаям, в которых события А и В не являются взаимно исключающими, то есть
некоторые результаты являются частью обоих событий: и А, и В. Части на рис. 7.1, д
и е соответствуют случаям, в которых события А и В являются взаимно исключа-
ющими. Обратите внимание на то, что в этих случаях пересечение этих двух собы-
тий является пустым множеством.
Обычно для определения понятия вероятности используется следующий на-
бор аксиом:
1. О < Pr[A] < 1 для любого события А.
2. Pr[Q] = l.
3. Рг[А и В]= Рг[А] + Рг[В], если события А и В являются взаимно исключа-
ющими.
Аксиому 3 можно сформулировать для более общего случая нескольких событий.
Например, Pr[A uBuCj = Рг[А] + Рг[В]+ Рг[С], если события А,ВнСявляются
взаимно исключающими. Обратите внимание на то, что в аксиомах ничего не сказа-
но о том, как вероятности ставятся в соответствие отдельным результатам или
событиям.
Опираясь на эти аксиомы, можно вывести много законов. Ниже перечислены
некоторые из наиболее значимых:
Рг[ А ] = 1 - Рг[А];
Рг[АоВ] = 0,
7.1. Вероятность
195
если события А и В являются взаимно исключающими;
Рг[Л и В] = Рг[Л] + Рг[В] - Рг[Л п В];
Рг[Л иВи С] = Рг[Л] + Рг[В]+ Рг[С] - Рг[Л пВ] - Рг[Д пС] -
- Pr[B п С] + Рг[Л п В п С].
В качестве примера рассмотрим бросание одной игральной кости. У этого экс-
перимента может быть шесть возможных результатов. Достоверным событием яв-
ляется выпадение любой из шести граней игральной кости. Объединение событии
{чет} и {меньше трех} представляет собой событие {или 1, или 2, или 4, или 6}. Пере-
сечение этих же событий является событием {2}. События {чет} и {нечет} являют-
ся взаимно исключающими. Если мы предположим, что каждый из шести резуль-
татов равновероятен, и присвоим каждому событию вероятность 1/6, то нетрудно
196 Глава 7. Обзор вероятностных и стохастических процессов
видеть, что все три аксиомы выполнены. Законы вероятности можно применить
следующим образом:
Рг{чет} = Рг{2} + Рг{4} + Рг{6} = 1/2;
Рг{меньше трех} = Рг{ 1} + Рг{2} = 1/3;
Рг[{чет} и {меньше трех}] = Рг{чет} +Рг{меньше трех} - Рг{2} =
= 1/2 + 1/3- 1/6 = 2/3.
Определение вероятности через относительную частоту
В методе относительной частоты используется следующее определение вероятности.
Выполните эксперимент несколько раз. Каждое проведение эксперимента называ-
ется попыткой (trial). При каждой попытке наблюдайте, происходит ли событие А.
В этом случае вероятность Рг[Л] события А представляет собой предел:
Pr[A] = lim —.
п—
Здесь п представляет собой общее число попыток, а па — число удачных попы-
ток, то есть попыток, результатом которых было событие А.
Например, мы могли бы подбрасывать монету много раз. Если после очень
большого количества бросков отношение выпавших орлов к общему числу брос-
ков монеты колеблется вокруг значения 0,5, тогда мы можем предположить, что
это правильная монета с равной вероятностью выпадения орла и решки.
Классическое определение
Пусть Nпредставляет собой количество возможных результатов, при этом все эти
результаты равновероятны, a NA — число результатов, при которых происходит
событие А. В этом случае вероятность события А определяется так:
РгмЛ.
Например, если мы бросаем одну игральную кость, тогда N равно 6 и событию
{чет} соответствуют три результата. Таким образом, получаем, что Р{чет} = 3/6 = 0,5.
Вот более сложный пример: мы бросаем две кости и хотим определить вероят-
ность р того, что сумма очков двух костей будет равна 7. Вы можете вычислить
количество различных вариантов сумм, которые можно получить этим способом
(от 2 до 12), то есть 11, и прийти к неверному умозаключению, что вероятность
такого события равна 1/11. Мы должны рассматривать равновероятные результаты.
Для этого следует учитывать все комбинации выпадения двух костей и различать
первую и вторую кости. Например, результаты (3, 4) и (4, 3) должны рассматри-
ваться как два отдельных события. При таком походе мы получим 36 равновероят-
ных результатов, из которых нас будут интересовать шесть пар: (1,6), (2, 5) (3,4),
(4,3), (5, 2), (6,1). Таким образом, получаем, что вероятность р = 6/36 =1/6.
Условная вероятность и независимость
Нам часто бывает нужно узнать вероятность события, зависимого от некоего дру-
гого события. Эффект условия состоит в удалении некоторых результатов из про
7. ^Вероятность
197
странства выборок. Например, чему равна вероятность того, что сумма выпадения
двух игральных костей равна 8 при условии, что хотя бы одна кость выпадает чет-
ной гранью? Мы можем рассуждать следующим образом. Поскольку одна кость
четная и сумма также четная, это значит, что вторая кость также должна показы-
вать четное число. Таким образом, нас устроят три следующих равновероятных
результата: (2,6), (4,4) и (6,2) из общего набора возможных результатов, которых
[36 _ (число событий, когда обе кости нечетные)] = 36 - 3 • 3 = 27. Итого, условная
вероятность равна 3/27 = 1/9.
формально условная вероятность (conditional probability) события А, предпо-
лагающая, что событие В произошло, обозначается как Рг[Л|В] и определяется
отношением
Здесь предполагается, что Рг[В] не равно нулю.
В нашем примере А = {сумма 8}, а В = {как минимум, одна кость четная}. Вели-
чина Рг[ЛВ] соответствует тем результатам, при которых сумма равна 8 и по мень-
шей мере одна кость четная. Как мы видели, таких результатов три. Таким обра-
зом, Рг|ЛВ] = 3/36 =1/12. Несложно убедиться, что Рг[23] = 3/4. Теперь мы можем
сосчитать:
Рг[Л | В] = = - .
1 1 ' 3/4 9
Этот результат согласуется с предыдущими вычислениями.
Два события Л и В называются независимыми (independent), если Рг[ЛВ] =
= Рг[Л]Рг[В]. Нетрудно видеть, что если события А и В являются независимыми,
то Рг[Л|В] = Рг[Л], а Рг[В|Л] = Рг[В].
Теорема Байеса
В завершение этого раздела мы рассмотрим один из важнейших результатов тео-
рии вероятности, известный как теорема Байеса (Bayes). Сначала нам необходимо
сформулировать формулу полной вероятности. Если имеется множество взаимно
Исключающих событий Eit Е2,..., Е„, так что объединение этих событий покрывает
все возможные результаты, и произвольное событие А, тогда можно показать, что
Рг[Л]=£рг[Л|Е;]Рг[Е,]. (7.1)
Г = 1
Теорема Байеса может быть сформулирована следующим образом:
Рг[£. | А] = РгИ1£.]Р№] = Рг[Л|Е;]Р[£,]
Рг[Л] £рг[Л|£7]Рг[£,]'
7=1
На рис. 7.2, а показана диаграмма, иллюстрирующая концепцию полной веро-
ятности и теорему Байеса.
198
Глава 7. Обзор вероятностных и стохастических процессов
W = R0: получено О
й = R0; получено О
0 = SO; передано О
□ = S1;передано 1
б
Рис. 7.2. Иллюстрация полной вероятности и теоремы Байеса
Теорема Байеса используется для вычисления «апостериорной вероятности»,
то есть вероятности того, что некое событие действительно имело место при усло-
вии наличия свидетельства в его пользу. Например, предположим, что мы передаем
по каналу с шумом последовательность нулей и единиц. Пусть SO и S1 представля-
ют собой события, соответствующие передаче в определенный момент 0 и 1, a R0
и R1 соответствуют событиям приема 0 и 1 получателем. Допустим, мы знаем ве-
роятность событий SO и S1 у отправителя, а именно Pr[Sl] =р, a Pr[SO] = 1-р.
Пусть производятся наблюдения за линией, чтобы определить, как часто проис-
ходит ошибка при передаче нуля и единицы. В результате вычисляются следую-
щие вероятности: Pr[R0|Sl] = ра и Pr[Rl|S0] =рь. Если получателем принимается
ноль, то при помощи теоремы Байеса мы можем вычислить условную вероятность
ошибки, а именно условную вероятность того, что была послана единица:
PrfSllROl =________Pr[RO|Sl]Pr[Sl]_______= рар________________
Pr[R0|Sl]Pr[Sl]+Pr[R0|S0]Pr[S0] РаР + (1 - А)(1 - р) '
Это уравнение иллюстрирует рис. 7.2, б. На рисунке пространство выборок i пред-
ставлено в виде квадрата. Одна половина квадрата соответствует событию SO, а дру-
гая — событию S1, так что Pr[S0] = Pr[S 1 ] = 0,5. Аналогично, половина квадрата соот-
ветствует событию R0, а другая — событию R1, так что Pr[R0] = Pr[Rl ] = 0,5. Внутри
половины, представляющей событие S0, 1/4 соответствует событию R1, так что
Pr[Rl|S0] = 0,25. Аналогично, очевидны другие условные вероятности.
7.2. Случайные переменные
Случайная переменная (random variable) представляет собой отображение множе-
ства всех возможных событий в пространстве выборок на пространство веществен-
ных чисел. Таким образом, случайная переменная связывает с каждым событи-
ем вещественное число. Эта концепция иногда выражается в виде эксперимента
с множеством возможных результатов. При этом случайная переменная при-
сваивает значение каждому результату. Таким образом, значение случайноs
7.2. Случайные переменные
199
переменной является случайной величиной. Мы дадим следующее формальное
определение. Случайная переменная X представляет собой функцию, ставящую
в соответствие каждому результату в пространстве выборок число, удовлетворя-
ющую следующим условиям:
1. Множество {X < х} является событием для каждого значения х.
2. Рг[Х = <х>] = Pr[X - -со] = 0.
Случайная переменная является непрерывной (continuous), если она может при-
нимать бесконечное множество различных значений. Случайная переменная яв-
ляется дискретной (discrete), если она может принимать конечное или ограничен-
ное множество различных значений.
функции распределения и плотности
Непрерывная случайная переменная Хможет быть описана либо с помощью функ-
ции распределения (distribution function) F(x), либо с помощью функции плотнос-
ти (density function)/(х):
♦ функция распределения:
F(x) = Рг[Х < х] F(-~) = 0;
F(co)= 1.
♦ функция плотности:
/(x) = ^F(x);
ах
F(x) = | f(y)dy\
f fWy = 1-
Для дискретной случайной переменной ее распределение вероятности харак-
теризуется следующими уравнениями:
/Ш) = Рг[Х=Л];
5Л(*)=1.
Все k
Часто нас интересует не все распределение, а какая-нибудь одна характеристи-
ка случайной переменной, например:
♦ Среднее значение (также называемое ожидаемым значением, или первым
моментом)
F[X] = рА. = | xf(x)dx—непрерывный случай;
£[Х] = р.А. = kPr[x = £]—дискретный случай.
200
Глава 7. Обзор вероятностных и стохастических процессов
♦ Второй момент:
£[Х] = цх = J xf(x)dx —непрерывный случай
= kPr[x- fe]—дискретный случай
Все*
•4 Дисперсия: Var[X] = Е[ (X - цх)2] = £[Х2] - ц2х-
4- Среднеквадратичное отклонение: or = ^Var[X].
Дисперсия (variance) и среднеквадратичное отклонение (standard deviation)
являются показателями рассеяния значений вокруг средней величины. Высокое
значение дисперсии переменной означает, что переменная чаще и дальше отклоня-
ется от среднего значения, чем переменная с низким значением дисперсии. Неслож-
но показать, что для любой постоянной а справедливы следующие уравнения:
£[аХ] = а£[Х];
Var[aX] = a2Var[X].
Среднее значение также называют статистикой первого порядка; второй мо-
мент и дисперсия представляют собой статистику второго порядка. Из функции
плотности вероятности также можно вывести статистики более высоких порядков.
Важные распределения
В данном разделе будут описаны некоторые распределения, играющие важную
роль в теории анализа очередей.
Экспоненциальное распределение
Экспоненциальное распределение с параметром X > 0 (рис. 7.3, а и б) описывает-
ся следующими функциями распределения и плотности:
F(x) = 1 - e)j;
/(х) = Хе,Л;
х>0.
Интересное свойство экспоненциального распределения состоит в том, что его
среднее значение равно среднеквадратичному отклонению:
£[х] = о, =1.
В случае применения к интервалу времени, например времени обслуживания,
такое распределение иногда называют случайным распределением. Это связано с
тем, что если интервал времени уже начался, то он может закончиться в произ-
вольный момент времени с равной вероятностью.
Важность этого распределения в теории очередей связана с тем, что мы часто
можем предположить, что время обслуживания распределено экспоненциально.
В случае телефонного трафика время обслуживания — это время, в течение которого
абонент занимает оборудование. В сети с коммутацией пакетов время обслуживания
7.2. Случайные переменные
201
представляет собой время передачи данных, и поэтому оно пропорционально дли-
не пакета. Трудно дать четкое теоретическое обоснование тому, почему время
обслуживания должно иметь экспоненциальное распределение, но во многих слу-
чаях его распределение близко к экспоненциальному. И это хорошо, так как зна-
чительно упрощает анализ очередей.
Распределение Пуассона
Другое важное распределение — распределение Пуассона (рис. 7.3, е) с парамет-
ром X > О, принимающее значения в точках 0,1,...:
Рг[Х = 6] = ^-еЛ k = 0,1,2...;
£[Х] = Var[X] = X.
202
Глава 7. Обзор вероятностных и стохастических процессов
Если А < 1, тогда Pr[X = &] достигает максимума при k = 0. Если А > 1, но не явля-
ется целым числом, тогда Рг[Х = £] достигает максимума при k, равном наибольше-
му целому числу, меньшему, чем А. Если Л представляет собой положительное целое
число, тогда у функции распределения Пуассона два максимума при £ = Аий = А-1.
Распределение Пуассона также представляет важность для анализа очередей,
так как мы должны предположить, что частота прибытия пакетов распределена по
Пуассону, для того чтобы вывести уравнения очередей (см. главу 8). К счастью,
предположение о подчинении распределения частоты прибывающих пакетов за-
кону Пуассона оказывается справедливым.
Распределение Пуассона может быть применено к частоте получения следую-
щим образом. Если элементы поступают в очередь в соответствии с распределени-
ем Пуассона, это может быть выражено следующим образом:
♦ Рг[& элементов прибывают в течение интервала Г] = —-—е"ЛГ ;
я!
♦ Дчисло элементов, прибывших в течение интервала Т] = АТ;
♦ средняя скорость прибытия, в элементах в секунду = А.
Пакеты, прибывающие в соответствии с законом Пуассона, часто называют слу-
чайно прибывающими. Это объясняется тем, что вероятность прибытия пакета в
течение короткого интервала времени пропорциональна длительности интервала
времени и не зависит от времени, прошедшего с момента прибытия последнего
пакета. Таким образом, если прибытие пакетов подчиняется распределению
Пуассона, пакет с равной вероятностью может прибыть в любой момент времени
независимо от того, в какие моменты времени прибывают другие пакеты.
Другое интересное свойство процесса Пуассона связано с его экспоненциаль-
ным распределением. Оказывается, что интервалы времени между прибывающи-
ми в соответствии с распределением Пуассона пакетами распределены экспонен-
циально:
Рг|Т„ < t] = 1 - е
ВД = |.
Л
Таким образом, как и следовало ожидать, среднее время между прибытием па-
кетов представляет собой обратную величину от частоты прибытия.
Нормальное распределение
Нормальное распределение с параметрами ц > 0 и о имеет следующие функцию
плотности (рис. 7.3, г) и функцию распределения:
/(л') = -Л=е-(х‘м)!/2о2;
<л/2л
F(x) = f e-^^dy.
i.
7.2. Случайные переменные
203
Причем
Е|А'] = ц;
VarfX] = ст2.
Большое значение представляет центральная предельная теорема, утверждаю-
щая, что средняя величина от большого количества независимых случайных пере-
менных будет распределена приблизительно нормально и почти не зависит от их
индивидуальных распределений. Одно ключевое требование заключается в конеч-
ности среднего значения и дисперсии. Центральная предельная теорема играет
в статистике ключевую роль.
Множественные случайные переменные
Когда имеются две или более случайных переменных, нас часто может интересо-
вать, отражаются ли изменения одной переменной на другой переменной. В этом
разделе определяются некоторые важные критерии зависимости.
В общем, для определения статистических характеристик множественных слу-
чайных переменных требуется определение их функции совместной плотности
или функции совместного распределения вероятности:
♦ распределение: F(x~i, х2,.... х„) = Pr[Xi < х\, Х2 < х2,..., Хп < л„];
Э”
+ плотность: f(xt,x2,...,x„) = ——--—F(xt,x2,...,x„);
OJi । . ..ОХп
4 дискретное распределение: P(xt, х2,.... х„) = Рг[Х( = лт, Х2 = х2,..., Х„ - Л'„].
Для любых двух случайных переменных X и Умы получаем
Е|Х+ У] = Е[Х] + Е[У].
Две непрерывные случайные переменные X и У называются (статистически)
независимыми (independent), если F(x, у) - F(x)F(y) и, следовательно, f(x,у) =f(x)f(y).
Если случайные переменные X и У дискретные, тогда они являются независимы-
ми, если Р(х, у) = Р(х)Р(у).
Для независимых случайных переменных справедливы следующие соотношения:
Е[ХУ] = Е[Х] х Е[У];
Var[X + У] = Var[X] + Var[ У].
Ковариация (covariance) двух случайных переменных X и У определяется сле-
дующим образом:
Cov(X, У) = Е[(Х- Цх)(У- вО1 = Е[ХУ] - Е[Х]Е[У].
Если дисперсия случайных переменных X и У конечна, тогда их ковариация
также конечна, но может быть положительной, отрицательной или нулевой.
Для конечных дисперсий случайных переменных X и У коэффициент корреля-
ции (correlation coefficient) переменных X и У определяется так:
г(Х,У) = -C-Ov(X,K) . (7.2)
стл°У
204 Глава 7. Обзор вероятностных и стохастических процессов
Коэффициент корреляции можно рассматривать как меру линейной зависим^,
ста между случайными переменными Хи К, нормализованную относительно ва
личины изменчивости Хи У. Справедливо следующее неравенство: '
- 1 < г(Х, У) < 1.
Говорят, что случайные переменные X и Уявляются позитивно коррелированны-
ми (positively correlated), если г (X, У) > 0, негативно коррелированными (negatively
correlated), если г (X, Y) < 0, и некоррелированными (uncorrelated), если г(Х, У) = 0.
Однако случайные переменные X и У могут быть некоррелированными и, тем не
менее, не являться независимыми (см. задание 7.12 в разделе 7.5).
Коэффициент корреляции демонстрирует степень линейной зависимости двух
случайных переменных. Если совместное распределение случайных переменных
X и У сконцентрировано на координатной плоскости вокруг прямой линии с поло-
жительным наклоном, тогда коэффициент корреляции г(Х, У), как правило, будет
близок к 1. Это указывает на то, что изменению переменной X будет соответство-
вать сходное по амплитуде и направлению изменение переменной У. Если совмест-
ное распределение случайных переменных X и У сконцентрировано на координатной
плоскости вокруг прямой линии с отрицательным наклоном, тогда коэффициент
корреляции г(Х, У), как правило, будет близок к -1.
Несложно доказать справедливость следующего равенства:
Var(X + У) = Var(X) + Уаг(У) + 2Cov(X, У).
Если случайные переменные X и У обладают одинаковой дисперсией о2, тогда
предыдущее равенство может быть записано в следующем виде:
Var(X + У) = 2ст2(1 + г(Х, У)).
Если случайные переменные X и У являются некоррелированными, то есть
г(Х, У) = 0, тогда Var(X + У) = 2о2. Эта результаты несложно распространить на
случаи более двух переменных. Рассмотрим множество случайных переменных
Хь..., Хдг с одинаковым значением дисперсии ст2. В этом случае можно записать:
Var £х;
I 1*1
= ст2 X + 2XXr(i,7) -
Здесь r(i,jy представляет собой сокращенную запись коэффициента корреля-
ции г(Х„ X/). С помощью равенства Var(X/N) = Var(X)/№ мы можем преобразо-
вать эту формулу для вычисления дисперсии среднего значения множества слу-
чайных переменных:
V ar(X) = ^[l + XE^7)
™ I i j<i
Если все переменные X, являются взаимно независимыми, тогда мы получим
__ _2
V ar(X) = ^.
7.3. Стохастическиепроцессы
205
7.3. Стохастические процессы
Стохастический процесс (stochastic process), также называемый случайным про-
цессом (random process), представляет собой семейство случайных переменных
{x(t)> t е индексированных параметром t на некотором множестве индексов Т.
Как правило, множество индексов интерпретируется как измерение времени, a х(0
является функцией времени. Другими словами, стохастический процесс представ-
ляет собой случайную переменную, являющуюся функцией времени. Непрерыв-
ный во времени стохастический процесс (continuous-time stochastic process) — это
стохастический процесс, в котором значение времени t изменяется непрерывно,
как правило, вдоль оси неотрицательных вещественных чисел {х(0. 0 < t < Т}, хотя
иногда оно может изменяться вдоль всей оси вещественных чисел. Дискретный во
времени стохастический процесс (discrete-time stochastic process) — это стохасти-
ческий процесс, в котором значение времени t принимает дискретные, как прави-
ло, положительные целые значения {x(t), t=l, 2,...}, хотя иногда оно может прини-
мать и целые значения во всем интервале от до +о°.
Вспомним, что случайная переменная определяется как функция, преобразу-
ющая результат эксперимента в некоторое значение. Учитывая это, выражение для
х(£) может быть интерпретировано по-разному:
1. Как семейство функций времени (переменная t, все возможные результаты).
2. Как отдельная функция времени (переменная t; один результат).
3. Как случайная переменная (переменная t фиксированная; все возможные
результаты).
4. Как отдельное число (переменная t фиксированная; один результат).
Конкретная интерпретация х(0 обычно ясна из контекста.
Следует сказать несколько слов о терминологии. Непрерывный по значениям
стохастический процесс (continuous-value stochastic process) — это стохастический
процесс, в котором случайная переменная х(£) с фиксированным t (случай 3)
принимает непрерывные значения. Дискретный по значениям стохастический про-
цесс (discrete-value stochastic process) — это стохастический процесс, в котором
случайная переменная в любой момент t принимает конечное или счетно-бес-
конечное количество значений. И непрерывный, и дискретный во времени стоха-
стические процессы могут быть как непрерывными, так и дискретными по значе-
ниям.
Как для любой случайной переменной, функцию х(0 с фиксированным значе-
нием t можно охарактеризовать функциями распределения вероятностей и плот-
ности вероятности. Для непрерывного по значениям стохастического процесса эти
функции принимают следующий вид:
функция распределения-.
F(x\ t) = Рг[х(0 < х];
Д(-оо; 0 = 0;
Д(<»; 0=1;
206 Глава 7. Обзор вероятностных и стохастических процессов
♦ функция плотности-.
ОХ
F(x;f) = J f(y,t)dy,
—DO
Для дискретного по значениям стохастического процесса:
Д.<о(*) = Рг[х(0 = 4
Все 6
Полная статистическая характеристика стохастического процесса должна учи-
тывать переменную времени. Используя первый вариант интерпретации из пре-
дыдущего списка, стохастический процесс x(t) включает в себя бесконечное коли-
чество случайных переменных, по одной для каждого значения t. Чтобы полностью
описать статистику процесса, нам потребуется указать функцию совместной плот-
ности вероятности переменных x(ti), х(Г2),x(t„) для всех значений п (1 < п < «=)
и всех возможных отсчетов времени (tb t2,.... t„). Но для задач нашей книги нет не-
обходимости углубляться в эту тему.
Статистики первого и второго порядка
Среднее значение и дисперсия стохастического процесса определяются обычным
образом:
E[x(t)] = g(t) = J yf(x\t)dy — случай непрерывных значений:
E[x(t)] = ц(Г) = У &Рг[х(О = k] — случай дискретных значений;
Все k
Е[х2(Г)] = J y2f(x,t)dy — случай непрерывных значений;
Е[х2(Г)] = У, £2Рг[х(Г) = — случай дискретных значений;
Всей
Var[x(t)] = <г) = Е[(х(О - ХО)2] = E[x2(f) - ц2(0.
Обратите внимание на то, что среднее значение и дисперсия стохастического
процесса представляют собой функции времени. Важным для нашего обсужде-
ния понятием является функция автокорреляции (autocorrelation function) R(t,, t2),
представляющая собой объединенный момент случайных переменных x(t() и x(t2):
R(ti, t2) = E[x(tt)x(t2)].
7.3. Стохастические процессы
207
Как и обсуждавшаяся ранее функция корреляции двух случайных перемен-
ных, автокорреляция представляет собой меру взаимосвязи двух временных от-
счетов стохастического процесса. Близкой величиной является автоковариация
(autocovariance):
С(Г„ Г2) = E[(x(ti) - p(ti))(x(t2) - р(г2))] = t2~) - Ц(?1)Ц(Г2). (7.3)
Обратите внимание на то, что дисперсия x(t) рассчитывается так:
Var[x(t)] = C(r, t) = R(t, t) - р2(Г).
Наконец (см. уравнение (7.2)), коэффициентом корреляции (correlation coeffici-
ent) случайных переменных x(ti) и х(г2) называется нормализованная функция
автокорреляции стохастического процесса, которая может быть выражена сле-
дующим образом:
г \ — Effort) ~ ))(-Г(^2 ) ~ НС2))] _ ^2) /7
Р(Л1>Г2/ ~ ~
^1^2 ^1^2
К сожалению, в некоторых статьях и книгах p(tb t2) называется функцией авто-
корреляции, так что читателю следует быть осторожным.
Стационарные стохастические процессы
Стационарным стохастическим процессом (stationary stochastic process) назы-
вается такой стохастический процесс, в котором вероятностные характеристики
процесса не изменяются со временем. Существует несколько определений этого
понятия, но одним из наиболее интересных здесь является концепция стационар-
ности в широком смысле (wide sense stationary). Процесс является стационарным
в широком смысле (или слабо стационарным), если его ожидаемое значение явля-
ется константой, а его функция автокорреляции зависит только от приращения
времени:
Е[х(г)] = ц;
R(t, t + т) = R(t + т, t) = 7?(т) = 7?(-т) для всех t.
Из этих равенств можно вывести следующие:
Var[x(t)] = R(t, t) - p2(t) = 7?(0) - ц;
C(t, t + т) = R(t + т, t) - p(t)|x(t + т) = R(t) - p2 = C(r).
Важной для 7?(т) является степень зависимости одного временного отсчета
стохастического процесса от другого. Если с увеличением т функция 7?(т) экс-
поненциально стремится к нулю, тогда имеет место зависимость одного отсче-
та стохастического процесса от другого отсчета, далеко отстоящего по времени.
Такой процесс называется процессом с короткой памятью (short memory process).
Если же величина 7?(т) остается большой и при больших значениях т (то есть
функция 7?(т) стремится к нулю медленнее, чем экспоненциально), то такой
стохастический процесс называется процессом с долгой памятью (long memory
process).
208 Глава 7. Обзор вероятностных и стохастических процессов
Спектральная плотность
Спектром мощности (power spectrum), или спектральной плотностью (spectral
density), стационарного случайного процесса называется преобразование Фурье
функции автокорреляции этого процесса:
5(w) = J /?(т)е“>отЛ.
Здесь w — угловая частота в радианах (w = 2л/), aj = .
Для детерминированной функции времени спектральная плотность представ-
ляет частотное распределение мощности сигнала. Для стохастического процесса
S(w) представляет собой среднюю плотность мощности частотных составляющих
x(t) в окрестности w. Вспомним, что одна из интерпретаций x(t) представляет со-
бой одиночную функцию времени (переменная t; один результат). В этом случае
эта функция времени, как и любая функция времени, состоит из суммы всех сво-
их частотных составляющих, и ее спектральная плотность представляет собой от-
носительную мощность каждой составляющей. Если мы рассматриваем x(t) как
семейство функций времени (переменная t; все возможные результаты), тогда
спектральная плотность представляет собой среднюю мощность каждой частот-
ной составляющей, усредненную по всем возможным функциям времени x(f).
Обратная формула Фурье позволяет получить функцию времени из ее спектра:
R(T) = ^-ls(W)e^.
Z71 Д
При т = 0 предыдущее равенство приобретает вид
~ J S(w)dw = Я(0) = Е[ | х(012 ].
Z71
Таким образом, суммарная площадь под кривой S(w)/2n равняется средней
мощности процесса x(t). Также следует заметить, что
5(0) = J R(x)dx.
Здесь 5(0) представляет собой постоянную составляющую спектра мощности
и соответствует интегралу от функции автокорреляции. Этот компонент будет
конечным, только если при т —> «> функция Д(т) уменьшается достаточно быстро.
Спектр мощности также может быть выражен для стохастического процесса,
определенного в дискретных моментах времени (дискретного во времени стохас-
тического процесса). В этом случае мы получим:
5(a) = £ /?(^)е-^;
5(0)= £ ВД.
7.3. Стохастические процессы
209
Здесь снова 5(0) представляет собой постоянную составляющую спектра мощнос-
ти и соответствует бесконечной сумме функции автокорреляции. Эта составляющая
будет конечной, только если при т —> •» функция Л(т) уменьшается достаточно быстро.
В табл. 7.1 показаны некоторые интересные соотношения между функцией ав-
токорреляции и спектральной плотностью.
Таблица 7.1. Функции автокорреляции и спектральные плотности
Стационарный случайный процесс Функция автокорреляции Спектральная плотность
Х(П ЯИт) Sx(w}
аХ(0 a2R*(t) a2Sx(w)
Х'(П -d2R*(t)/dt2 w2Sx(w)
X"’(t) (-ird^RXWdT2" w^Sxtw)
X(f)exp(jtVoO exp(jv¥ot)Rx(T) Sx(w-w0)
Независимые приращения
Говорят, что у непрерывного во времени стохастического процесса {х(£), 0 < t <
независимые приращения, если х(0) = 0, и для всех вариантов выборок to < Л <,..., < t„
будут независимыми п случайных переменных:
х(^) - х(£0), x(t2) - x(fi),..., x(i„) - x(t„.1).
Таким образом, величина «перемещения» в стохастическом процессе за один
интервал времени не зависит от перемещения за любой другой не перекрывающий-
ся интервал. Говорят, что у стохастического процесса стационарно независимые
приращения, если, кроме того, х(/2 + Л) - х(А + /г) обладает тем же распределени-
ем, что и x(i2) - x(£i) для всех i2 > Ц и для всех h > 0.
Следует отметить два свойства процессов со стационарно независимыми при-
ращениями. Если процесс х(£) обладает стационарно независимыми приращения-
ми и Е[х(£i)] = ji(t) представляет собой непрерывную функцию времени, тогда
р(£) = а + bi, где а и b — константы. Кроме того, если дисперсия Var[x(i) - х(0)]
является непрерывной функцией времени, тогда для всех s выполняется условие
Var[x(s +1) - x(s)] = o2i, где о2 является константой.
Два процесса, играющие центральную роль в теории стохастических процес-
сов, — процесс броуновского движения и процесс Пуассона — обладают независи-
мыми приращениями. Ниже приводится краткий обзор обоих процессов.
Процесс броуновского движения
Броуновское движение представляет собой случайное движение микроскопичес-
ких частиц, взвешенных в жидкости или газе, вызванное столкновениями с моле-
кулами окружающей среды. Этот физический феномен является основой для
определения стохастического процесса броуновского движения, также называемо-
го процессом Винера (Wiener) и процессом Винера — Леви (Wiener — Levy).
Рассмотрим функцию B(t) для частицы броуновского движения, означающую
зависимость смещения этой частицы от начальной точки в одном измерении от
ремени. Рассмотрим итоговое перемещение частицы за интервал времени (s, t),
210
Глава 7. Обзор вероятностных и стохастических процессов
достаточно долгий по сравнению со временем между соударениями частиц. Вели-
чина В(/) - B(s) может рассматриваться как сумма большого числа небольших пе-
ремещений. Полагаясь на центральную предельную теорему, мы можем предпо-
ложить, что эта величина обладает нормальным распределением вероятности.
Если допустить, что среда находится в равновесии, то можно считать, что ито-
говое перемещение зависит только от длительности интервала, а не от того момен-
та времени, в который начинается этот интервал. Таким образом, распределение
вероятности B(f) - B(s) должно быть таким же, как и у B(i + h) - B(s + h) для лю-
бого значения h > 0. Наконец, если перемещение частицы целиком вызвано час-
тыми случайными столкновениями, тогда итоговые перемещения за не перекры-
вающиеся временные интервалы должны быть независимыми, и поэтому B(t)
обладает независимыми приращениями.
Учитывая все сказанное, мы можем определить процесс броуновского движе-
ния B(i) как процесс, удовлетворяющий перечисленным ниже условиям:
1. (В(Г), 0 < t < оо} обладает независимыми приращениями.
2. Для любого t > 0 случайная переменная B(i) обладает нормальным распре-
делением.
3. Для всех t > 0 функция E[B(t)] = 0.
4. В(0) = 0.
Плотность вероятности процесса броуновского движения имеет вид
Л(х,0 = -^=е-?/2"2'.
Отсюда мы получаем:
Var[B(01 =«;
Var[B(t) - B(s)] = |t - s|.
Другой важной величиной является автокорреляция B(i), выраженная как
Rn(ti, t2). Мы можем получить эту величину следующим образом. Во-первых,
заметим, что для /;< > tj > t2 > it имеет место следующее соотношение:
E[(B(t4) - B(t3))(B(t2) - B(i,))] = E[B(i4) - B(i:i)] x E[B(t2) - B(t,)] =
= (E|B(i,)J - E[B(t:!)])x(E[B(t2)] - E[B(i,)D =
= (0-0)x(0-0) = 0.
Первая строка данного уравнения справедлива, так как два интервала не пере-
секаются, и поэтому величины (B(i4) - B(i3)) и (B(i2) - B(it)) являются независи-
мыми в силу предположения о независимых приращениях. Вспомним, что для не-
зависимых случайных переменных X и Y Е[ХУ] = Е[Х]Е[У]. Теперь рассмотрим
два интервала времени (0, G) и (it, t2), где 0 < it < t2. Это не перекрывающиеся ин-
тервалы времени, поэтому
0 = E|(B(i2) - B(i1))(B(t1) - В(0))1 =
= Ef(B(i2)-B(t1))B(t1)] =
= E|B(i2)B(/l)J - EfB^it)] =
= ElB(/2)B(it)] - Var[B2(it)] =
= E[B(i2)B(i,)l-i1.
7.3. Стохастические процессы
211
Поэтому
fe) = E[B(i2)B(«i)]В(6)] = Л, где t, < t2.
Таким образом, в общем случае автокорреляцию В(£) можно выразить как
f $) = m*n [б $]• Поскольку среднее значение B(t) равно нулю, автоковариация
W совпадает с автокорреляцией. Таким образом, CB(t, s) - min [£, s].
Для любого значения t > 0 и 5 > 0 приращение процесса броуновского движе-
f ния B(t + 5) - B(t) распределено нормально с нулевым средним значением и дис-
Персией, равной 5. Таким образом,
Рг[(В(« + 5) - В(0) < х] = -^2= J e^dy. (7.5)
V2n8 L.
Обратите внимание на то, что это распределение не зависит от t и зависит только
от 6, поскольку B(t) обладает стационарными приращениями.
Полезно представить себе процесс броуновского движения в виде предела дис-
кретного во времени процесса. Здесь мы последуем за рассуждениями, приводи-
мыми в [78]. Рассмотрим частицу, выполняющую случайные прыжки вдоль оси
i, вещественных чисел. Через небольшие интервалы времени т частица случайным
образом прыгает на небольшое расстояние влево или вправо. Обозначим поло-
?. жение частицы в момент времени kT как X/kt). Если прыжки в положительном и
отрицательном направлениях равновероятны, тогда Х((£ + 1)т) с равной вероят-
/ ностью равняется Хт(£т) + 8 или X/kt) - б. Если допустить, что Хт(0) = 0, тогда по-
ложение частицы в момент времени t будет равно
ХТ(О = 3(К1 + У2,... + У1(/,).
Здесь У1, У2 являются независимыми случайными переменными, с одинаковой
> вероятностью равными 1 или-1,а означает наибольшее целое число, мень-
шее или равное t/т. Как правило, длину шага 8 нормализуют как 4т, так что
xT(t) = ^(y,+y2... + yL//Tj).
Из центральной предельной теоремы следует, что для фиксированного значе-
ния t, если значение т достаточно мало, то сумма в предыдущем равенстве состоит
из нескольких случайных переменных. Поэтому Хт(г) обладает распределением,
близким к нормальному, со средним значением, равным 0, и дисперсией, равной t,
так как среднее значение У равно 0 и дисперсия равна 1. Кроме того, для фиксиро-
ванных значений t и h, если значение т достаточно мало, то значения Х(Г + А) -
- -VT(£) распределены приблизительно нормально с нулевым средним значением и
дисперсией, равной h. Наконец, отметим, что приращения Хт(0 являются незави-
симыми. Таким образом, X/t) представляет собой функцию, дискретную во вре-
мени, приближенно описывающую броуновское движение. Если разделить вре-
менную ось точнее, приближение можно увеличить. В пределе эта функция станет
процессом броуновского движения, непрерывным во времени.
Процесс Пуассона и связанные с ним процессы
Вспомним, что если прибытие пакетов является случайным, тогда число пакетов,
'рибывших в течение некоторого интервала времени, распределено по Пуассону:
м
212 Глава 7. Обзор вероятностных и стохастических процессов
Рг[прибытие
k элементов за время Г] =
(ХГ)*
k\
е *т
Мы можем определить считающий процесс Пуассона (Poisson counting process)
{N(t), t> 0} следующим образом:
1. N(t) обладает стационарно независимыми приращениями.
2. 7V(0) = 0.
3. Для 0 < £i < t2, величина N(t2) - N(tt) равняется количеству точек в интервале
(ti, £2) и распределена по Пуассону со средним значением, равным Х(£2 - А).
В этом случае мы получим следующие функции вероятности для N(t):
Pr[N(t) = k] = ^e-u;
ki
E[N(£)] = Var[N(£)]=Xt.
Ясно, что процесс N(t) является нестационарным, так как его среднее значение
зависит от времени. Каждая функция времени этого стохастического процесса (один
результат) имеет вид восходящей лестницы со ступеньками единичной высоты.
Увеличение функции происходит в случайные моменты времени £,. Пример фун-
кции N(t) показан на рис. 7.4, а.
Стационарный процесс, связанный со считающим процессом Пуассона, пред-
ставляет собой инкрементный процесс Пуассона (Poisson increment process). Для
считающего процесса Пуассона N(t} со средним значением Xt и для постоянной L
(L > 0) мы можем определить инкрементный процесс Пуассона X(t) следующим
образом:
Среднее значение функции X(f) равняется k/L, где k представляет собой коли-
чество точек в интервале (£, £ + £). Инкрементный процесс Пуассона, полученный
из считающего процесса на рис. 7.4, а, показан на рис. 7.4, б. Справедливо следую-
щее выражение:
1 1
£[X(t)] = A E[N(£ +1) - А£[ЛГ(£)] = X.
С постоянным средним значением X(t) представляет собой в широком смысле
стационарный процесс и поэтому имеет функцию автокорреляции одной перемен-
ной 7?(т). Можно показать, что эта функция выглядит следующим образом:
/?(т) =
X2, | т |> L,
(7.6)
Таким образом, корреляция достигает максимума, когда два временных отсче-
та находятся в пределах интервала времени друг от друга, и является небольшой
постоянной величиной для больших значений разницы времени.
7.3. Стохастические процессы
213
N(t)
Рис. 7.4. Процессы Пуассона
Эргодичность
Для стохастического процесса x(i) существует два типа «усредняющих» функций:
среднее по ансамблю и среднее по времени.
В первую очередь рассмотрим среднее по ансамблю (ensemble average). Для по-
стоянного значения t функция х(£) представляет собой одиночную случайную пе-
ременную, обладающую средним значением, дисперсией и другими распредели-
тельными свойствами. Для заданного постоянного значения времени t, равного С,
имеют место следующие величины:
Е[х(С)] = Цх(С) = J xf (х‘, C)dx — случай непрерывного значения;
Е[Х(С)] = Цх(С) = у ЛРг[х(С) = k] — случай дискретного значения;
Все£
214 Глава 7. Обзор вероятностных и стохастических процессов
Var[x(C)] = о2х(С) = Е[(х(С) - Ц.(С))2] = Е[х2(С)2] - цх2(С).
Каждая из этих величин вычисляется для всех значений х(/) и всех возмож-
ных результатов. Для заданной случайной переменной множество всех возмож-
ных результатов называется ансамблем (ensemble), и поэтому приведенные выше
величины называются средними значениями по ансамблю.
Для среднего по времени рассмотрим один результат x(t). Это одиночная де-
терминированная функция времени. Если рассматривать x(t) таким образом, мы
можем определить среднее значение функции по времени. Среднее по времени (time
average), как правило, выражается следующим образом:
1 г
= — J x(t)dt — случай непрерывного времени;
1 т
Мт = — У, x(t) — случай дискретного времени.
Т /=1
Обратите внимание, что Мт представляет собой случайную переменную, так как
результат вычисления Мт для одиночной функции времени является случайной
переменной для одиночного результата.
Говорят, что стационарный процесс является эргодическим (ergodic), если сред-
нее по времени равняется среднему по ансамблю. Поскольку Е[х(Г)] представляет
собой константу для стационарного процесса, мы получаем
Е[Л/Г] - E[x(t)] = М-
Говорят, что стационарный процесс является эргодическим, если выполняет
условие
lim Уаг(Л/г ) = 0.
Таким образом, если усреднять значение функции по все большим и большим
интервалам времени, среднее по времени будет стремиться к среднему по ансамблю.
Вопросы условий, при которых стохастический процесс является эргодическим,
выходят за рамки данной книги, но предположение об эргодичности процесса, как
правило, делается. Конечно, предположение об эргодичности процесса существен-
но почти для любой математической модели, используемой для стационарных сто-
хастических процессов. Практическое значение эргодичности заключается в том,
что в большинстве практических случаев нет доступа ко всему ансамблю резуль-
татов стохастического процесса или даже более чем к одному результату. Таким
образом, единственный способ получения оценки вероятностных параметров сто-
хастического процесса заключается в анализе одиночной функции времени в тече-
ние длительного периода времени.
7.4. Рекомендуемые литература и веб-сайты
Теме вероятности и случайных процессов посвящена огромная подборка книг,
начиная с XVII века. Моей любимой является [109]; это не только очень прак- I
тичная книга по теме вероятности, но и познавательное описание философии ']
7.5. Задания
215
юятности. Для самостоятельного обучения хорошо подойдет [96]. В этой книге
щржится множество задач с решениями.
Также существует много книг, посвященных стохастическим процессам. Моей
бимой книгой является [172]. Начиная с 1965 г. эта книга, выдержавшая много
даний, остается превосходным пособием по данной теме. Другая хорошая кни-
, подходящая для самостоятельного обучения, — [101]. В ней содержится мно-
ество задач, а у издателя можно получить также сборник решений.
Рекомендуемым веб-сайтом является Probability Web. Этот сайт посвящен тео-
ии вероятности и ее приложениям. На нем имеются ссылки на статьи, журналы
не все из них бесплатные), списки электронной рассылки, группы новостей, кон-
ференции, а также на сайты, посвященные людям, работе, обществам, программ-
юму обеспечению, книгам. Сайт снабжен базовым поисковым механизмом.
7.5. Задания
1. Вам предлагается сыграть со мной в игру, в которой в одной из трех коробочек
я прячу приз (с равной вероятностью для всех трех коробок) в то время,
когда вы выходите из комнаты. Когда вы возвращаетесь, вы должны угадать,
в которой коробочке хранится приз. Игра состоит из двух этапов. Сначала
вы указываете одну из трех коробочек. Как только вы это сделали, я откры-
ваю крышку пустой коробочки из двух оставшихся. Я могу это сделать, так
как знаю, где спрятан приз. В этот момент приз должен быть в одной из двух
оставшихся закрытыми коробочек. Вы можете продолжать упорствовать
в своем выборе или изменить свой выбор, указав на вторую оставшуюся за-
крытой коробочку. Вы получаете приз, если угадываете его во второй попытке.
Какая стратегия является лучшей? Должны ли вы: а) придерживаться свое-
го изначального выбора; б) выбрать другую коробочку; в) Выбрать любую
из двух коробочек, так как очередность не имеет значения?
2. Пациент проходит тест на некоторое заболевание. Результат теста оказыва-
ется положительным (у пациента есть это заболевание). Учитывая, что ре-
зультат теста оказался положительным, чему равна вероятность того, что
пациент действительно болен, если вам известно:
♦ точность теста составляет 87 % (то есть если пациент болен, то в 87 %
случаев тест выдает правильный результат, и если пациент здоров, тест
также в 87 % случаев выдает правильный результат);
* распространенность этого заболевания среди населения составляет 1 %.
3. В ночной инцидент на дороге оказалось вовлечено такси, скрывшееся с места
происшествия, чему' был свидетель. В городе работают два парка такси, Синие
и Зеленые. Суд проверил надежность свидетеля в следственном эксперимен-
те, при обстоятельствах, аналогичных ночному происшествию, и пришел к
заключению, что свидетель правильно указывал цвет машины в 80 % случа-
ев. Чему равна вероятность того, что машина, вовлеченная в ночное столк-
новение, была машиной Синих, а не Зеленых, если вам известно:
♦ 85 % машин такси в городе принадлежит Зеленым, а 15 % — Синим;
♦ свидетель утверждает, что машина принадлежала Синим.
216
Глава 7. Обзор вероятностных и стохастических процессов
4. Парадокс дней рождения представляет собой известную задачу по теори!
вероятности. Эта задача может быть сформулирована следующим образощ
Есть группа из К человек. Чему равно минимальное число К, такое, что ве-
роятность дня рождения в один и тот же день года у двух человек из группы
составляет больше 0,5? Игнорируйте 29 февраля и предположите, что все
дни рождения равновероятны. Разделим задачу на две части.
а) определите Q(K) как вероятность того, что в группе из К человек не бу-
дет совпадающих дат рождения. Выведите формулу для Q(K). Подсказ-
ка: сначала определите количество способов N, которыми можно полу-
чить К значений без совпадений;
б) определите Р(К) как вероятность того, что в группе из К человек по
меньшей мере у двух человек совпадают даты рождения. Выведите фор-
мулу. Чему равно минимальное значение К, при котором Р(К) > 0,5? Гра-
фик Р(Х) может оказаться полезным.
5. Бросаются пара «правильных» (с вероятностью каждого результата 1/6)
игральных костей. Пусть X — максимальное из выпавших чисел.
а) найдите распределение X;
б) найдите ожидание Е[Х], дисперсию Var[X] и среднеквадратичное откло-
нение о*.
6. Игрок бросает «правильную» игральную кость. Если выпадает простое чис-
ло, большее 1, он выигрывает соответствующее количество долларов. Если
же выпадает непростое число, то он проигрывает соответствующее количе-
ство долларов.
а) обозначьте выигрыш или проигрыш игрока случайной переменной X.
Подсчитайте распределение переменной X;
б) является ли игра честной, то есть Е[Х] = 0?
7. В ярмарочной игре chuck-a-luck игрок платит сумму Е за вход, после чего
выбирает число от 1 до 6 и бросает три кости. Если все три кости показыва-
ют выбранное игроком число, игрок получает учетверенную входную пла-
ту. Если две кости из трех показывают выбранное число, игрок получает
утроенную входную плату. Если только одна кость показывают выбранное
число, игрок получает удвоенную входную плату. Если ни одна кость не по-
казывает выбранное игроком число, игрок не получает ничего. Пусть пере-
менная X означает выигрыш игрока в одной игре. Предположим также, что
кости честные.
а) определите функцию вероятности X;
б) вычислите Е[Х].
8. Среднее значение случайной переменной X равно 50, а ее дисперсия равна 4.
а) найдите среднее значение X2;
б) найдите дисперсию и среднеквадратичное отклонение 2Х + 3;
в) найдите дисперсию и среднеквадратичное отклонение -X. I
i
7.5. Задания
217
9. Непрерывная случайная переменная R обладает постоянной плотностью в
диапазоне от 900 до 1100 и нулевой плотностью во всех остальных местах.
Определите вероятность того, что R находится между 950 и 1050.
10. Докажите, что при прочих равных условиях чем больше коэффициент кор-
реляции двух случайных переменных, тем больше дисперсия их суммы и тем
меньше дисперсия их разности.
И. Предположим, что случайные переменные X и У могут принимать только
два возможных значения, 0 и 1. Докажите, что если эти переменные явля-
ются некоррелированными, тогда они также являются независимыми.
12. Рассмотрим случайную переменную X со следующим распределением:
Рг[Л = -1] = 0,25; Рг[Х = 0] = 0,5; Рг[Х= 1] = 0,25; Пусть У=Х2.
а) являются ли X и У независимыми случайными переменными? Аргумен-
тируйте свой ответ;
б) сосчитайте ковариацию Cov(X, У);
в) являются ли переменные X и У некоррелированными? Аргументируйте
свой ответ.
13. Детерминированный сигнал x(t) =g(t) представляет собой искусственный
пример стохастического процесса. Определите среднее значение, дисперсию
и автокорреляцию х(0.
14. Определите среднее значение, дисперсию и ковариацию случайных пере-
менных Z = х(5) и W = х(8) в предположении, что х(Г) представляет собой
стохастический процесс, причем
Р(0 = 3;
7?(^,г2) = 9 + 4е-°А'Г21.
15. Пусть {Z„} представляет собой множество некоррелированных веществен-
ных случайных переменных. Каждая случайная переменная обладает нуле-
вым средним значением и дисперсией, равной 1. Для констант «о, <Хз,..., О-к
определите скользящее среднее по представленной ниже формуле и пока-
жите, что значение Y является стационарным, а также найдите его функцию
автоковариации:
к
Yn= XaZn-,-.
«=0
16. Пусть Х„ = A cos(wZ) + В sin(zzX), где А и В представляют собой некоррели-
рованные случайные переменные, причем среднее значение каждой пере-
менной равно 0, а дисперсия равна 1. Покажите, что переменная X стацио-
нарная со спектром, содержащим ровно одну точку.
Глава 8
Анализ очередей
Снова и снова прогнозы обеих разведок — армейской
и флотской — сбывались к удивлению друзей и к неудо-
вольствию врагов.
Уинстон Черчилль. Мировой кризис I
В области обмена данными и компьютерных сетей вам часто может понадобиться
умение предсказывать результат определенных изменений в системе, таких как
увеличение нагрузки или доработка конструкции. Например, организация поддер-
живает определенное количество терминалов, персональных компьютеров и ра-
бочих станций, подключенных к 100-мегабитной локальной сети. Предполагается
подключение к локальной сети дополнительного отдела в здании. Сможет ли су-
ществующая локальная сеть выдержать увеличение нагрузки или лучше создать
вторую локальную сеть и соединить ее с первой сетью мостом?
Бывают другие случаи, в которых сеть еще не существует, но на основе имею-
щихся требований нужно создать проект сети. Например, руководство собирается
установить в некоем отделе персональные компьютеры и создать из них локальную
сеть с файловым сервером. Основываясь на результатах эксперимента в другом
отделе компании, вы можете оценить нагрузку, создаваемую каждым персональ-
ным компьютером, и вычислить требуемые мощности локальной сети и файлового
сервера.
В каждом случае основной заботой является производительность системы.
В интерактивном приложении или в приложении реального времени это, как пра-
вило, означает время отклика. В других случаях главным вопросом является про-
пускная способность.
Для оценки производительности проектируемой системы требуется определен-
ный механизм предсказаний. Решение сетевых проблем и проблем связи, а также
многих других проблем из реального мира часто можно получить с помощью ана-
литических моделей, основанных на теории очередей.
Количество вопросов, которые можно решить путем анализа очередей, беско-
нечно. Круг этих вопросов охватывает практически все темы, обсуждаемые в дан-
ной книге. Таким образом, умение применять анализ крайне важно для разработ-
чиков, занимающихся любой из этих проблем.
Хотя математическая часть теории очередей сложна, применение самой теории/
в целях анализа производительности во многих случаях оказывается доволы f
8.1. Простой пример поведения очередей
219
простым. Все, что для этого требуется, — это знание элементарных статистических
понятий (средних значений и дисперсий), а также понимание в общих чертах ме-
тодов применения теории очередей. Вооружившись этими знаниями, разработчик
часто может выполнить расчеты на клочке бумаги, используя несложные таблицы
очередей, или с помощью простой компьютерной программы, занимающей всего
несколько строк кода.
В этой главе предлагается практический курс анализа очередей.
8.1. Простой пример поведения очередей
Прежде чем перейти к деталям анализа очередей, рассмотрим грубый пример, что-
бы «почувствовать» тему данной главы. Рассмотрим веб-сервер, способный обслу-
живать индивидуальные запросы в среднем за 1 мс. Чтобы упростить задачу, пред-
положим, что сервер обслуживает каждый запрос ровно за 1 мс. Если скорость
поступления запросов равна одному запросу в миллисекунду (1000 запросов в се-
кунду), то, как кажется, можно утверждать, что сервер справится с такой нагрузкой.
Предположим, что запросы прибывают с постоянной скоростью с интервалом
ровно в 1 мс. Сервер обрабатывает запрос сразу, как только он приходит. Как толь-
ко сервер завершает обработку текущего запроса, поступает новый запрос, п сер-
вер снова принимается за работу.
Теперь рассмотрим более реалистичный вариант, в котором средняя скорость
поступления запросов составляет также тысячу запросов в секунду, но эта скорость
не постоянна. В течение любого заданного миллисекундного интервала может не
поступить ни одного запроса, поступить один запрос или поступить несколько за-
просов, но в среднем за каждую миллисекунду приходит один запрос. В этом слу-
чае здравый смысл подсказывает, что сервер справится. В периоды высокой на-
грузки, когда поступает больше запросов, чем сервер способен обработать, сервер
может хранить избыточные запросы в буфере. Можно сказать, что поступающие
запросы ставятся в очередь на обработку. В спокойные периоды сервер может на-
верстать упущенное и очистить буфер. В данном случае важный вопрос проекти-
рования заключается в том, насколько большим должен быть буфер.
Таблицы 8.1-8.3 дают грубое представление о поведении такой системы.
В табл. 8.1 мы предполагаем, что в систему поступает в среднем 500 запросов в се-
КУНДУ, что соответствует половине производительности сервера. Записи в табли-
це показывают количество запросов, прибывающих каждую секунду, количество
запросов, обработанных в течение этой секунды, и количество избыточных запро-
сов, поставленных в очередь к концу секундного интервала. В таблице содержат-
ся данные о состоянии очереди на протяжении 50 с. Среднее по 50-секундным
интервалам значение числа запросов, стоящих в очереди, равняется 43. Пиковое
значение числа запросов, стоящих в очереди, составляет 600. В табл. 8.2 средняя
скорость поступления запросов увеличена до 95 % от производительности сервера
и составляет 950 запросов в секу] щу. При этом среднее коли чество запросов, ож ида ю-
щих обработки в буфере, увеличивается до 1859. Это может показаться удивитель-
ным. Скорость поступления запросов увеличилась менее чем в два раза, тогда как
средняя длина очереди выросла в 40 раз. В табл. 8.3 средняя скорость поступления
220
Глава 8. Анализ очередей
запросов еще немного увеличена — до 99 % от производительности сервера, — в ре-
зультате среднее количество запросов в буфере выросло до 2583. Таким образом,
совсем незначительное увеличение средней скорости поступления запросов при-
водит к почти 40-процентному росту числа запросов, ожидающих в очереди.
Таблица 8.1. Поведение очереди при нормализованной скорости прибытия, равной 0,5
Время Вход Выход Очередь
0 0 0 0
1 88 88 0
2 796 796 0
3 1627 1000 627
4 51 678 0
5 34 34 0
6 966 966 0
7 714 714 0
8 1276 1000 276
9 494 769 0
10 933 933 0
11 107 107 0
12 241 241 0
13 16 16 0
14 671 671 0
15 643 643 0
16 812 812 0
17 262 262 0
18 218 218 0
19 1378 1000 378
20 507 885 0
21 15 15 0
22 820 820 0
23 1253 1000 253
24 307 559 0
25 540 540 0
26 190 190 0
27 500 500 0
28 96 96 0
29 943 943 0
30 105 105 0
31 183 183 0
32 447 447 0
33 542 542 0
34 166 166 0
35 165 165 0
36 490 490 0
8.1. Простой пример поведения очередей
221
Время Вход Выход Очередь
37 510 510 0
38 877 877 0
39 37 37 0
40 163 163 0
41 104 104 0
42 42 42 0
43 291 291 0
44 645 645 0
45 363 363 0
46 134 134 0
47 920 920 0
48 1507 1000 507
49 598 1000 105
50 172 277 0
Среднее 499 499 43
Таблица 8.2. Поведение очереди при нормализованной скорости прибытия, равной 0,95
Время Вход Выход Очередь
0 167 167 0
2 1512 1000 512
3 3091 1000 2604
4 97 1000 1701
5 65 1000 765
6 1835 1000 1601
7 1357 1000 1957
8 2424 1000 3382
9 939 1000 3320
10 1773 1000 4093
11 203 1000 3269
12 458 1000 2754
13 30 1000 1784
14 1275 1000 2059
15 1222 1000 2281
16 1543 1000 2824
17 498 1000 2322
18 414 1000 1736
19 2618 1000 3354
20 963 1000 3317
21 29 1000 2346
22 1558 1000 2904
23 2381 1000 4285
продолжение^
222 Глава 8. Анализ очередей I ____________________________8.1. Простой пример поведения очередей___223
Таблица 8.2 (продолжение) 1 Время Вход Выход Очередь
Время Вход Выход Очередь | ' - - ю 1847 1000 4644
24 583 1000 3868 212 1000 3856
25 1026 1000 3894 № 12 477 1000 3333
26 361 1000 3255 И 13 32 1000 2365
27 950 1000 3205 W 14 1329 1000 2693
28 182 1000 2387 ‘Й 15 1273 1000 2967
29 1792 1000 3179 16 1608 1000 3574
30 200 1000 2378 17 519 1000 3093
31 348 1000 1726 18 432 1000 2525
32 849 1000 1575 19 2728 1000 4253
33 1030 1000 1605 20 1004 1000 4257
34 315 1000 921 21 30 1000 3287
35 314 1000 234 I 22 1624 1000 3910
36 931 1000 165 23 2481 1000 5391
37 969 1000 134 24 608 1000 4999
38 1666 1000 800 25 1069 1000 5068
39 70 871 0 26 376 1000 4445
40 310 310 0 ! 27 990 1000 4435
41 198 198 0 28 190 1000 3625
42 80 80 0 29 1867 1000 4492
43 553 553 0 30 208 1000 3700
44 1226 1000 226 31 362 1000 3062
45 690 915 0 32 885 1000 2947
46 255 255 0 33 1073 1000 3020
47 1748 1000 748 34 329 1000 2349
48 2863 1000 2611 35 327 1000 1676
49 1136 1000 2748 36 970 1000 1646
50 327 1000 2074 37 1010 1000 1656
Среднее 948 907 1859 38 1736 1000 2392
39 73 1000 1465
Таблица 8.3. Поведение очереди при нормализованной скорости прибытия, равной 0,99 40 323 1000 788
Время Вход Выход Очередь 41 206 994 0
0 0 0 0 42 83 83 0
1 174 174 0 43 576 576 0
2 1576 1000 576 44 1277 1000 277
3 3221 1000 2798 45 719 996 0
4 101 1000 1899 46 265 265 0
5 67 1000 966 47 1822 1000 822
6 1913 1000 1879 48 2984 1000 2805
7 1414 1000 2292 49 1184 1000 2990
8 2526 1000 3819 / 50 341 1000 2330
9 978 1000 3797 * Среднее 988 942 2583
224 Глава 8. Анализ очередей
Этот грубый пример наводит на мысль о том, что поведение системы с очере-
дью может не согласовываться с пашей интуицией.
8.2. Цели анализа очередей
Часто бывает необходимо рассчитать требуемую производительность на основе
имеющейся информации о нагрузке или на основе оценки нагрузки в новом окру-
жении. Для этого могут применяться различные подходы:
4- Выполнение анализа на уже готовом оборудовании на основе фактических
значений.
4 Выполнение простых прогностических расчетов на основе экстраполяции
данных, полученных на существующем оборудовании.
4 Разработка аналитической модели на основе теории очередей.
4 Создание и запуск программной модели.
Первый вариант вообще не является вариантом. Мы просто собираем систему
наугад и смотрим, что получится. Такой подход приведет лишь к появлению не-
довольных пользователей и к неразумному расходованию средств. Второй вари-
ант кажется более многообещающим. Аналитик может заявить, что спрогнозиро-
вать будущие требования с какой-либо степенью точности невозможно. Поэтому
нет смысла заниматься точным моделированием. Вместо этого простой и грубый
прогноз позволит получить приближенную оценку. Недостаток такого подхода
состоит в том, что поведение большинства систем при изменении нагрузки оказы-
вается довольно неожиданным, как было показано в разделе 8.1. Если имеется
окружение, в котором есть коллективно используемый ресурс (например, сеть, ли-
ния передачи данных или система разделения времени), тогда производительность
такой системы, как правило, отвечает на увеличение нагрузки экспоненциальным
увеличением времени отклика.
На рис. 8.1 показан соответствующий пример. Верхняя линия демонстрирует
увеличение времени отклика на запрос пользователя к общему ресурсу при уве-
личении нагрузки на этот ресурс. Нагрузка измеряется в долях от максимальной
производительности ресурса. Таким образом, если мы имеем дело с маршрутиза-
тором, способным обрабатывать и переправлять 1000 пакетов в секунду, то нагруз-
ка 0,5 соответствует средней скорости поступления 500 пакетов в секунду. Время
отклика представляет собой время, требуемое для пересылки любого входящего
пакета. Нижняя линия иллюстрирует экстраполяцию многочленом третьего по-
рядка экспериментального участка кривой времени отклика, соответствующего
нагрузке от 0 до 0,5 мощности ресурса. Обратите внимание на то, что данный спо-
соб экстраполяции работает более или менее удовлетворительно лишь на участке
от 0,5 до 0,7 от мощности ресурса, а когда нагрузка начинает «зашкаливать» за 0,8
или 0,9, наступает крах системы.
Таким образом, требуется более точный метод предсказаний. Третий вариант
заключается в использовании аналитической модели, представляющей собой на-
бор уравнений, которые могут быть решены для получения требуемых парамет-
ров (времени отклика, пропускной способности и т. д.). Аналитические модел*^
8.2. Цели анализа очередей
225
.снованные на теории очередей, обеспечивают довольно хорошее соответствие с
1еальностью в таких областях, как компьютеры, операционные системы и сети.
Недостаток теории очередей заключается в том, что для составления уравнений
относительно интересующих нас параметров приходится принимать ряд упроща-
ющих допущений.
Рис. 8.1. Фактическое время отклика и экстраполяция
Последний подход представляет собой численное моделирование. В данном
случае при наличии достаточно мощного и гибкого специализированного языка
программирования аналитик может очень подробно смоделировать реальную си-
стему, не прибегая к многочисленным допущениям, требуемым в теории очередей.
Однако в большинстве случаев численная модель не требуется или, по меньшей
мере, не рекомендуется на первом этапе анализа. Во-первых, и измерения суще-
ствующей системы, и прогностические оценки будущей нагрузки содержат опре-
деленные погрешности. Таким образом, независимо от того, насколько хорошей
будет модель, качество результатов ограничено качеством исходных данных. Во-
вторых, несмотря на то что в теории очередей требуется принять множество допу-
щений, получаемые результаты часто оказываются довольно близкими к тем, ко-
торые могут быть получены при более тщательном численном моделировании.
Более того, для четко поставленной задачи анализ очередей может быть выполнен
буквально за считанные минуты, тогда как создание, отладка и прогон моделиру-
ющей программы могут занять дни, недели и месяцы.
Именно по этим причинам аналитик обязан знать основы теории очередей.
226
Глава 8. Анализ очередей
8.3. Модели очередей
Очередь к одному серверу
Простейшая система с очередью показана на рис. 8.2. Центральный элемент сис-
темы представляет собой сервер, предоставляющий другим элементам системы
некоторые услуги. На сервер поступают запросы на обслуживание. Если сервер
ничем не занят, запрос обрабатывается незамедлительно. В противном случае посту-
пивший запрос помещается в очередь. Когда сервер завершает обработку запроса,
пакет с обработанным запросом покидает сервер. Если на этот момент в очереди
имеются необработанные запросы, один из них немедленно выбирается сервером.
Поступления
А — скорость
поступления |_
Очередь
Дисциплина
диспетчеризации
Отправления
w— число ожидающих запросов rs — время обслуживания
Av — время ожидания р — коэффициент использования
г — число запросов в системе с очередью
Тг — время пребывания в системе
Рис. 8.2. Структура и параметры системы очередей для очереди с одним сервером
Параметры очереди
На рис. 8.2 также показаны некоторые важные параметры, связанные с моделью
очередей. Запросы прибывают на обрабатывающее устройство с некоей средней
скоростью X (заказов в секунду). Среди примеров поступающих заказов можно
назвать пакеты, прибывающие на маршрутизатор, или звонки, поступающие на
телефонный коммутатор. В любой заданный момент времени определенное коли-
чество заказов (ноль или больше) будет ожидать в очереди. Среднее количество
ожидающих заказов равно w, а среднее время ожидания в очереди — Т№. Время Тю
усредняется по всем поступающим заказам, включая те, которые обрабатываются
без ожидания. Сервер обрабатывает поступающие заказы за среднее время обслу-
живания Г5. Это интервал времени от начала обработки заказа сервером до того
момента, когда обработанный пакет покидает сервер. Коэффициент использова-
ния сервера р означает долю времени, которую сервер занят работой. Наконец, два
параметра применяются ко всей системе в целом. Это г — среднее количество за-
казов в системе, включая обслуживаемый в данный момент заказ, плюс заказы,
ждущие своей очереди, а также Т, — среднее время, которое заказ проводит в сис-
теме, включая ожидание в очереди и обработку, называемое средним временем пре-
бывания в системе (mean residence time)’.
1 Иногда это время называют средним временем ожидания, хотя в других изданиях этим термином на-
зывают среднее время, которое заказ проводит в очереди.
8.3. Модели очередей
227
Если предположить, что емкость очереди бесконечна, тогда система никогда не
теряет заказов. Их обслуживание просто откладывается на более позднее время.
При увеличении скорости поступления заказов увеличивается коэффициент за-
грузки, а вместе с ним вероятность перегрузки. Очередь становится длиннее, время
ожидания в очереди возрастает. При р = 1 наступает насыщение, то есть сервер
работает 100 % времени. Пока коэффициент загрузки меньше 100 %, сервер справ-
ляется с обработкой поступающих заказов, таким образом, средняя скорость на
выходе сервера равняется средней скорости на входе. Как только сервер насыщается,
скорость на выходе сервера остается постоянной независимо от того, насколько боль-
шой является скорость на входе. Таким образом, теоретический максимум вход-
ной скорости, при которой система будет успевать обрабатывать все запросы, равен:
X =—.
max гр
Однако при приближении к точке насыщения очереди становятся очень длин-
ными и при р = 1 неограниченно растут. Из практических соображений, таких как
требования ко времени отклика или ограничения на размеры буферов, входная
скорость, как правило, ограничивается уровнем 70-90 % от теоретического мак-
симума.
Ключевые моменты
Полезно представить процессы, связанные с очередями, на примере. На рис. 8.3
показан пример реализации процесса функционирования очереди. На графике
изображена зависимость общего количества запросов в системе от времени. Зате-
ненные области обозначают периоды времени, когда сервер занят. На оси времени
отмечены два типа событий: поступление запроса i в момент времени Л, и завер-
шение обслуживания запроса i в момент времени Di. Время, которое запрос i про-
водит в системе, равно Та = Di - А,. Фактическое время обслуживания запроса i
обозначается как TSi.
Рис. 8.3. Иллюстрация процесса функционирования очереди
В данном примере время 7'рл, которое запрос 1 проводит в системе, полностью
состоит из времени обслуживания Tst, так как когда он прибывает в систему, сис-
тема пуста и поэтому может незамедлительно приступить к обслуживанию запро-
228
Глава 8. Анализ очередей
са. Время Тю состоит из времени, в течение которого запрос 2 ждет обслуживания
(Di - А2), и его времени обслуживания 7^2- Соответственно, Тю = (Оз - Лз) = (О3 -
- О2) + (О2 - Аз) = Ts3 + (D2 - Л3). Однако запрос п может покинуть систему, преж-
де чем поступит запрос и + 1 (например, £>й < А?), поэтому общая формула выгля-
дит как = Tsn+\ + МАХ[0, D„ - A„flJ.
Характеристики модели
Прежде чем выводить любые аналитические уравнения для модели очередей, сле-
дует выбрать определенные ключевые характеристики модели. Ниже приводятся
типичные характеристики, как правило, применяемые в контексте передачи данных.
♦ Совокупность запросов (item population). Предполагается, что запросы по-
ступают от источника совокупности настолько большой, что она может счи-
таться бесконечной. Результат этого допущения заключается в том, что ско-
рость поступления запросов в систему не изменяется. Если совокупность
конечна, тогда ее размер уменьшается по мере того, как запросы поступают
в систему. При этом, как правило, скорость поступления запросов пропор-
ционально уменьшается. Обычно сетевые и серверные проблемы могут ре-
шаться при допущении о бесконечной совокупности.
♦ Размер очереди (queue size). Предполагается бесконечный размер очереди,
то есть очередь может расти неограниченно. Если очередь конечна, некото-
рые запросы могут теряться системой — когда очередь заполнена и по-
ступает дополнительный запрос, система вынуждена отбросить один из за-
просов. На практике всякая очередь конечна, но во многих случаях это не
оказывает существенного влияния на анализ. Мы кратко рассмотрим во-
прос конечности очереди далее в этой главе.
4 Дисциплина диспетчеризации (dispatching discipline). Когда сервер заверша-
ет обработку очередного запроса, а в очереди содержится больше одного
запроса, должно быть принято решение о механизме выбора из очереди
следующего запроса. Простейший метод диспетчеризации представляет со-
бой метод FIFO (First in First Out — первым прибыл, первым обслужен).
Как правило, этот метод применяется, когда используется термин очередь.
Другой возможный вариант — метод LIFO (Last In First Out — последним
прибыл, первым обслужен). Общий подход заключается в использовании
дисциплины диспетчеризации, основанной на относительных приоритетах.
Например, маршрутизатор может учитывать информацию о качестве обслу-
живания.
Ниже перечислены некоторые полезные параметры, включая показанные на
рис. 8.2, а также некоторые другие (интерес, в частности, часто представляет вариа-
ция различных параметров, которая выражается среднеквадратичным отклоне-
нием):
♦ X — скорость поступления, то есть среднее количество поступающих в секун-
ду запросов;
4- К — среднее время обслуживания каждого запроса; в это время не входит
время ожидания в очереди;
8.3. Модели очередей
229
4- ст — среднеквадратичное отклонение времени обслуживания;
4- ст — коэффициент использования; доля времени, которую сервер (серверы)
занят;
4 и — интенсивность трафика;
4г— среднее количество запросов в системе, ожидающих и обслуживаемых;
4 R — количество запросов в системе, ожидающих и обслуживаемых;
4 7) — среднее время, которое запрос проводит в системе;
4 Тц — время, которое запрос проводит в системе;
4 стг — среднеквадратичное отклонение г,
4 стг — среднеквадратичное отклонение 7);
4 w — среднее количество запросов, ожидающих обслуживания;
4 ста — среднеквадратичное отклонение w\
4 Tw — среднее время ожидания (включая запросы с пулевым временем ожи-
дания);
4 Td — среднее время ожидания (исключая запросы с нулевым временем ожи-
дания);
4 N — количество серверов;
4 П2д(г/) — г/-й процентиль; это значение, ниже которого величина х встречает-
ся с частотой у.
Очередь к нескольким серверам
На рис. 8.4, а показано обобщение обсуждавшейся ранее простой модели для не-
скольких серверов с общей очередью. Если прибывает запрос и свободен хотя бы
один сервер, тогда этот запрос немедленно передается этому серверу. Предполага-
ется, что все серверы идентичны. Таким образом, если свободными одновременно
оказываются несколько серверов, то выбор конкретного сервера не влияет на вре-
мя обслуживания. Если все серверы заняты, начинает формироваться очередь. Как
только один из серверов освобождается, из очереди с использованием дисципли-
ны диспетчеризации выбирается запрос и передается серверу.
Все параметры, кроме коэффициента использования, показанные на рис. 8.2, с
тем же успехом применимы к случаю нескольких серверов. Если у нас есть Nиден-
тичных серверов, тогда р представляет собой коэффициент использования каж-
дого сервера, a N? можно рассматривать как коэффициент использования системы
в целом. Этот термин часто называют интенсивностью трафика (intensity traffic) и.
Таким образом, теоретический максимум коэффициента использования составля-
ет N • 100 %, а теоретический максимум для входной скорости равен
х =Л
,vmax j, •
Как правило, ключевые характеристики, выбираемые для очереди к несколь-
ким серверам, соответствуют характеристикам очереди к одному серверу. Это
230
Глава 8. Анализ очередей
означает, что мы предполагаем бесконечную совокупность и бесконечный размер
общей для всех серверов очереди. За исключением специально оговариваемых слу-
чаев, дисциплина диспетчеризации представляет собой порядок FIFO.
Рис. 8.4. Сравнение моделей одной очереди: а — к нескольким серверам,
б — к каждому серверу
На рис. 8.4, б, напротив, представлена структура из отдельной очереди к каж-
дому из нескольких серверов. Как будет показано ниже, это незначительное изме-
нение структуры оказывает существенное влияние на производительность.
Основные соотношения теории очередей
Чтобы продвинуться дальше, мы должны принять несколько упрощающих допу-
щений. Принимая эти допущения, мы рискуем сделать модель менее соответству-
ющей реальной ситуации. К счастью, во многих случаях результаты остаются до-
статочно точными для задач планирования и проектирования.
8.3. Модели очередей
231
Однако существуют соотношения, справедливые для общего случая. Эти соот-
ношения приведены в табл. 8.4. Сами по себе они не очень полезны, однако могут
использоваться для ответов на несколько основных вопросов. Вот пример, взятый
из [154]. Рассмотрим шпиона из закусочной «Королевские Гамбургеры», пытаю-
щегося вычислить количество людей в закусочной McDonald’s, расположенной на
противоположной стороне улипы. Он не может весь день сидеть в McDonald’s,
поэтому должен найти ответ, основываясь только на наблюдении входящих в
McDonald’s и выходящих оттуда людей. Пронаблюдав за дверью конкурирующей
фирмы в течение дня, он определяет, что за час в среднем эту закусочную посеща-
ют 32 посетителя. Он также замечает, что средний посетитель остается внутри 12
минут. С помощью формулы Литтла (Little) шпион определяет, что в каждый мо-
мент времени в McDonald’s находится в среднем 6,4 посетителя (6,4 = 32 посети-
теля в час • 0,2 часа/посетителя).
Таблица 8.4. Некоторые основные соотношения теории очередей
Общие Один сервер Несколько серверов
г = ТТ, — формула Литтла p = XTs Р = ^ N
г=АТ, — формула Литтла г= и/+ р и = XTS = pN
Тг=Т»+Та r = w + Np
На данном этапе было бы полезно получить интуитивное представление об
уравнениях из таблицы. Для формулы р = "kTs сосчитаем средний интервал време-
ни между поступлением заказов Т = 1/Х. Если значение Т больше, чем Ts, тогда в
течение интервала времени Т сервер оказывается занятым только на время Ts, так
что коэффициент использования равен Ts/T = TTs. Аналогичные рассуждения при-
менимы для случая очереди к нескольким серверам и формулы р = "kTs/N.
Чтобы понять формулы Литтла, рассмотрим следующий пример с одним за-
просом. Когда запрос поступает в систему, он обнаруживает, что в среднем w дру-
гих запросов ждут в очереди впереди него. Когда запрос покидает очередь, отправ-
ляясь на обработку, за ним в очереди остается в среднем все те же w ожидающих
запросов. Чтобы нагляднее представить это, обратите внимание на то, что пока за-
прос ждет своей очереди, очередь перед ним уменьшается, а позади него растет. Когда
запрос покидает очередь, среднее количество запросов позади него равно w, так как
w, по определению, равно среднему количеству запросов, ожидающих обслужива-
ния. Среднее время ожидания обслуживания равно Поскольку запросы при-
бывают со скоростью X, мы можем считать, что за время Т„ должно поступить ТТ„.
запросов. Таким образом, w = ХТ„. Путем аналогичных рассуждений можно выве-
сти формулу г=ХТг.
Теперь рассмотрим последнюю формулу в первом столбце таблицы. Несложно
видеть, что время, которое запрос проводит в системе, представляет собой сумму
времени ожидания и времени обслуживания. Таким образом, в среднем, Тг = Тю + Ts.
Последние формулы во втором и третьем столбцах можно легко проверить. В лю-
бой момент времени число запросов в системе представляет собой сумму коли-
232 Глава 8. Анализ очередей
честв ожидающих в очереди и обслуживаемых запросов. Для одного сервера сред-
нее число обслуживаемых запросов равно р, поэтому r=w+ р. Аналогично, для
N серверов г = w + Np.
Допущения
Входной информацией для очереди является:
4- скорость поступления запросов;
4 время обслуживания;
4 количество серверов.
Фундаментальная задача анализа очередей заключается в том, чтобы на осно-
вании такой входной информации получить следующую информацию на выходе:
4 количество ожидающих запросов;
4 время ожидания;
4 количество запросов в очереди;
4 время нахождения запроса в системе.
Что конкретно нам нужно знать об этих величинах? Во-первых, нам нужно
знать их средние значения (и\ Д„ г, Г,). Кроме того, было бы полезно кое-что
узнать об их изменчивости. То есть нам нужно знать среднеквадратичное откло-
нение каждой из этих величин (ст„ , аг, ог ). Также могут быть полезны и другие
величины. Например, при проектировании буфера маршрутизатора или мульти-
плексора, возможно, будет полезно знать размер буфера, вероятность переполне-
ния которого не превосходит 0,001. Другими словами, чему равно N, такое, что
Рг[число ожидающих запросов < Д''] = 0,999?
Чтобы отвечать на подобные вопросы, в общем случае требуется полное знание
распределения вероятности временных интервалов между поступлениями запро-
сов (интервалов времени между успешными поступлениями запросов) и времени
обслуживания. Более того, даже при наличии этой информации получающиеся
в результате формулы оказываются исключительно сложными. Поэтому, чтобы
двигаться дальше, мы должны принять некоторые упрощающие допущения.
Наиболее важное из этих допущений касается скорости поступления запросов.
Предполагается, что интервалы времени между поступлениями запросов распре-
делены экспоненциально. Это равносильно заявлению о подчинении числа посту-
пающих за период времени t запросов распределению Пуассона. Другими слова-
ми, это означает, что запросы поступают случайным образом и не зависят друг от
друга. Это допущение принимается почти всегда. Без него анализ очередей оказы-
вается невозможным или, в крайнем случае, довольно сложным. При таком до-
пущении оказывается, что, зная только среднее значение и среднеквадратичное
отклонение скорости поступления запросов, можно получить много полезных
результатов. Ситуацию можно упростить еше больше, если предположить, что вре-
мя обслуживания подчиняется экспоненциальному распределению или постоян-
но. При этом могут быть получены еще более точные результаты.
8.4. Очередь к одному серверу
233
Для обозначения основных допущений, принимаемых при моделировании оче-
редей, была разработана так называемая нотация Кендалла (Kendall’s notation).
Эта нотация имеет вид X/Y/N, где X обозначает распределение интервалов вре-
мени между поступлениями запросов, Y — распределение времени обслуживания,
N — количество серверов. Наиболее часто встречающиеся распределения обозна-
чаются следующим образом:
♦ G — произвольное распределение интервалов времени обслуживания за-
просов или интервалов времени между поступлениями запросов;
> GI — произвольное распределение интервалов времени между поступлени-
ями запросов с ограничением, заключающимся в независимости этих интер-
валов;
♦ М — отрицательное экспоненциальное распределение;
♦ D — детерминированное поступление запросов, или обслуживание фикси-
рованной длины.
Таким образом, запись М/М/1 означает модель с одним сервером, в которой
количество поступающих запросов распределено по Пуассону (интервалы време-
ни между поступлениями распределены экспоненциально), и с экспоненциальным
распределением интервалов времени обслуживания.
8.4. Очередь к одному серверу
Ниже приведены некоторые формулы для очереди к одному серверу при следую-
щих допущениях:
♦ частота поступления запросов подчиняется распределению Пуассона;
♦ дисциплина диспетчеризации не дает предпочтения запросам, основываясь
на времени обслуживания;
♦ в формулах для среднеквадратичного отклонения предполагается диспет-
черизация FIFO;
♦ запросы не выбрасываются из очереди.
Для первого случая частота поступления запросов распределена по Пуассону,
а интервалы времени обслуживания подчиняются произвольному распределению.
Использование коэффициента масштабирования А позволяет упростить форму-
лы для некоторых ключевых выходных переменных. Обратите внимание на то,
что масштабирующий коэффициент зависит от отношения среднеквадратичного
отклонения времени обслуживания к среднему значению. Никакой другой инфор-
мации о времени обслуживания не требуется. Итак, формулы для произвольного
распределения времени обслуживания (M/G/1):
р2Л
г^-р + ——
1-р
234
Глава 8. Анализ очередей
Р2Л .
® =---,
1-Р
т _т | р?И.
' ' 1-р’
т рГдЛ
в 1-р’
Интерес представляют два особых случая. Когда среднеквадратичное отклоне-
ние равно среднему значению, распределение времени обслуживания является
экспоненциальным (М/М/1). Это простейший случай, в котором легче всего по-
лучить результаты. Далее показаны упрощенные варианты формул для средне-
квадратичного отклонения г и Гг, а также некоторые другие интересные соотношения:
р р2
г = ; ю =---;
1-р 1-р
т - -т - рТ' •
' 1-р’ ю 1-р’
VP Ts
о,. = ~у—; Пт = ——;
1-р ' 1-р
Pr[/? = 1V] = (1 - p)pJV;
Рг[Я<М] = £ (l-p)p';
i=0
Рг[7/ <T] = l-e-(,-₽)1/^
тт(у) = Тг -In
100 \
100-у Г
™т_ {У) = — -In
Р
100р 1
100 -у ]•
Другой интересный случай, когда среднеквадратичное отклонение времени об-
служивания равно нулю, что означает постоянное время обслуживания (M/D/1):
Р2
2(1 —р) Р’
p2
w = —----•
2(1-P)’
Г _ГХ2-Р).
T 2(l-p) ’
8.4. Очередь к одному серверу
235
р'/;
Tw 2(1-р)’
1
1-рГ 2 6 12’
Ts |р_р!
°т' 1-рА/З 12’
На рис. 8.5 и 8.6 показаны графики зависимостей средних значений размера
очереди и времени присутствия запроса в системе для трех значений отноше-
ния ors / . Последняя величина называется коэффициентом изменчивости
(coefficient of variation) и представляет собой нормализованную меру изменчиво-
сти. Обратите внимание на то, что лучшая производительность достигается при
постоянном времени обслуживания, а худшая — при экспоненциально распределен-
ном. Во многих случаях можно считать экспоненциально распределенное время
обслуживания худшим случаем, поэтому консервативные результаты можно
получить путем анализа, основанного на этом допущении. Это очень удобно, так
как для случая М/М/1 существуют таблицы, в которых можно быстро найти
нужные значения.
0,5 Г.
Коэффициент использования (р)
Рис. 8.5. Среднее число запросов в системе для очереди к одному серверу
Какое отношение / Ts может встретиться на практике? Мы можем рассмат-
ривать четыре области значений:
236 Глава 8. Анализ очередей
8.5. Очередь к нескольким серверам
237
Коэффициент использования (р)
Рис. 8.6. Среднее резидентное время для очереди к одному серверу
4 Нулевое значение. Это редкий случай постоянного времени обслуживания.
Например, к этой категории может относиться случай, при котором разме-
ры всех передаваемых пакетов одинаковы.
♦ Отношение меньше 1. Поскольку этот случай лучше, чем экспоненциальное
распределение, с помощью формул для схемы М/М/1 можно получить зна-
чения размеров очереди и интервалов времени несколько большие, чем они
должны быть. Таким образом, схема М/М/1 позволяет рассчитать границы
безопасной зоны параметров. К этой категории относятся приложения с за-
полнением форм.
♦ Отношение близко к 1. Это довольно распространенный случай, соответствую-
щий экспоненциальному распределению, когда время обслуживания в значи-
тельной степени является случайным. Рассмотрим случай вывода сообщений
на алфавитно-цифровой экран компьютера. Полный экран может вместить
до 1920 символов, а в сообщении могут находиться от 0 до 1920 символов.
К этой категории относятся такие приложения, как заказ авиабилетов, по-
иск файлов, коллективно используемые локальные сети, а также сети с ком-
мутацией пакетов.
♦ Отношение больше 1. Для этого случая уже неприменима схема М/М/1,
и нужно использовать схему M/G/1. Наиболее распространенным вариан-
том данного случая является бимодальное распределение с далеко отстоя-
щими друг от друга пиками. Пример такого случая — система с большим ко-
личеством коротких сообщений, большим количеством длинных сообщений
и практически без сообщений промежуточного размера.
Те же соображения применимы к скорости поступления запросов. Если часто-
та поступления запросов распределена по Пуассону, то интервалы времени под-
чиняются экспоненциальному распределению, а отношение среднеквадратичного
отклонения к среднему значению равно 1. Если данное отношение существенно
меньше 1, тогда поступления стремятся к равноотстоящему варианту' (с невысо-
ким уровнем изменчивости), и приближение Пуассона позволяет получить оцен-
ку верхних границ размеров очереди и времени ожидания. С другой стороны, если
это отношение больше 1, тогда запросы поступают очень неравномерно и пробле-
ма перегрузки становится очень актуальной.
8.5. Очередь к нескольким серверам
Ниже перечислены формулы для некоторых ключевых параметров случая несколь-
ких серверов. Ряд ограничений накладывается в допущениях:
♦ частота поступления запросов подчиняется распределению Пуассона;
4 значения времени обслуживания распределены экспоненциально;
♦ все серверы загружены в равной мере;
4 среднее время обслуживания всех серверов одинаково;
4 используется диспетчеризация FIFO;
4 запросы не выбрасываются из очереди.
Для этой модели полезная статистика была получена только для схемы М/М/
N, в которой экспоненциальное распределение времени обслуживания идентично
для всех серверов:
V(Np)'
К = № у— функция отношения Пуассона;
S-FT
1-К
1-рК
— С-функция Эрланга;
г -С ——-1- Np ; W = C Р ;
l-Р 1-Р
Т =— Л_ + тт = --L_-
М1-р 5,7(0 ЛИ-р’
°*. = Jc<2-O+№(1-P>!;
СТЧ = j——-7Ср(1+ р) - Ср ;
238
Глава 8. Анализ очередей
Рг[7„ > tj = Ce~N(t~p)t/T‘;
f 100C 1
[100-r J’
Т
mT {г) =---J--In
% ЛЧ1-Р)
T
r - *__
" N(l-P)’
Обратите внимание на присутствие С-функции Эрланга практически во всех
уравнениях. Она означает вероятность того, что в данный момент времени заняты
все серверы. Другими словами, это вероятность того, что количество запросов в
системе (ожидающих и обслуживаемых) больше или равно количеству серверов.
Соответствующее уравнение имеет вид
1-рК(ЛЛр)
Здесь К — функция отношения Пуассона. Поскольку величина С представляет
собой вероятность, эта величина всегда находится в диапазоне от 0 до 1. Как можно
видеть, она является функцией от числа серверов и коэффициента использования.
Это выражение часто встречается при расчетах очередей. Можно воспользоваться
готовыми табличными значениями или компьютерной программой. Обратите вни-
мание на то, что для системы с одним сервером эта формула упрощается до С( 1, р) = р.
8.6. Примеры
Рассмотрим несколько примеров, чтобы понять, как работают эти уравнения.
Серверы баз данных
Рассмотрим локальную сеть, в которой имеется 100 персональных компьютеров,
и сервер, хранящий общую базу данных для приложений, посылающих ему зап-
росы. Среднее время, требующееся серверу для ответа на запрос, составляет 0,6 с,
а среднеквадратичное отклонение ожидается равным среднему значению. В мо-
менты пиковой нагрузки частота запросов в локальной сети достигает 20 запросов
в минуту. Мы хотели бы получить ответы на следующие вопросы:
♦ Чему равно среднее время отклика, если пренебречь накладными расхода-
ми линии?
♦ Если максимальное приемлемое время отклика считается равным 1,5 с, на
сколько процентов может вырасти нагрузка, прежде чем будет достигнут
максимум?
♦ Если ожидается увеличение коэффициента использования на 20 %, увели-
чится ли время отклика больше или меньше, чем на 20 %?
8.6. Примеры
239
Предположим, что система соответствует схеме М/М/1. Проигнорируем вли-
яние локальной сети, предполагая, что ее вклад в задержку является пренебрежи-
мо малым. Коэффициент использования вычисляется так:
р = ХГ, = (20 запросов в минуту)(0,6 с на передачу)/(60 с/мин) = 0,2.
Первое значение, среднее время отклика, легко вычислить:
77= 77/(1 - р) = 0,6/(1 - 0,2) = 0,75 с
Второе значение получить труднее. В самом деле, как было сказано, ответа нет,
так как существует ненулевая вероятность, что в некоторых случаях время откли-
ка превысит 1,5 с для любого значения коэффициента использования. Вместо
этого скажем, что нам хотелось бы, чтобы 90 % всех значений времени отклика
были меньше 1,5 с. В этом случае мы можем воспользоваться формулами для
схемы М/М/1 из раздела 8.4:
тгу = Т, ,1п(100/(100-г/));
тпт (90) = Тг 1п(100) = —• 2,3 = 1,5 с.
1-р
В нашем случае Ts = 0,6. Решая приведенное выше уравнение относительно р,
получаем р = 0,08. Таким образом, чтобы 90 % всех значений времени отклика были
меньше 1,5 с, коэффициент использования должен быть уменьшен с 20 до 8 %.
Третий вопрос заключается в том, чтобы определить соотношение между
увеличением нагрузки и увеличением времени отклика. Поскольку коэффици-
енту использования 0,2 соответствует нижний пологий участок кривой, время
отклика будет расти медленнее коэффициента использования. В этом случае,
если коэффициент использования увеличится с 20 до 40 %, что представляет
собой 100-процентный рост, значение Г, изменится с 0,75 с до 1,0 с, то есть выра-
стет на 33 %.
Вычисление процентилей
Рассмотрим конфигурацию, в которой пакеты посылаются от компьютеров, при-
соединенных к локальной сети, системам в других сетях. Все эти пакеты должны
пройти через маршрутизатор, соединяющий локальную сеть с глобальной сетью
и, тем самым, с внешним миром. Рассмотрим трафик от локальной сети через мар-
шрутизатор. Пакеты поступают со средней частотой 5 пакетов в секунду. Средняя
длина пакетов составляет 144 байт, и предполагается, что длины пакетов распре-
делены экспоненциально. Пропускная способность линии от маршрутизатора до
глобальной сети равна 9600 бит/с. В данном случае нас интересуют следующие
вопросы:
♦ Чему равно среднее время нахождения запроса на маршрутизаторе?
♦ Сколько в среднем запросов находится на маршрутизаторе, включая ожи-
дающие передачи и один, передаваемый в данный момент?
♦ Предыдущий вопрос для 90-го процентиля.
♦ Снова тот же вопрос, но теперь для 95-го процентиля.
240
Глава 8. Анализ очередей
Исходные данные:
+ А, = 5 пакетов/с;
♦ Ts = (144 байт • 8 бит/байт)/9600 бит/с = 0,12 с;
♦ р = XZi = 5 • 0,12 = 0,6;
+ Tr = 7j/( 1 - р) = 0,3 с — среднее время пребывания запроса на маршрути-
заторе;
♦ r= р/( 1 - р) = 1,5 пакетов — среднее число резидентных запросов.
Чтобы получить процентили, воспользуемся формулой для схемы М/М/1 из
раздела 8.4:
Pr[/? = N] = (1 -р)р*
Чтобы сосчитать г/-й процентиль длины очереди, напишем предыдущее равен-
ство в кумулятивном виде:
и
= 1 — p1+m'0'>
Здесь m,(y) представляет собой максимальное количество пакетов в очереди,
ожидаемое у процентов времени. Таким образом, т,{у) является значением, ниже
которого R остается у процентов времени. В данном случае мы можем определить
процентиль для любой длины очереди. Но нам же нужно обратное: по заданному
значению у определить т,(у). Таким образом, если прологарифмировать обе час-
ти равенства, получим:
тДу) =
In 1--^-
[ 100
In р
Если т,(у) дробное, округлим его до целого в большую сторону. Если т,(у) от-
рицательное, установим его равным нулю. В нашем примере р = 0,6, и мы хотим
найти 7т?г(90) и тд,(95):
90) = 1п(1 0,90) _ 1 =
1п(0,6)
mr(95)=
1п(1-0,95)
1п(0,6)
-1-4,8.
Таким образом, 90 % времени в очереди находится менее четырех пакетов, а 95 %
времени в очереди находится менее пяти пакетов. Если наш проект должен удов-
летворять 95-му процентилю, размер буфера должен вмещать по меньшей мере
пять пакетов.
Примеры очереди к серверам
Инженерная фирма предоставляет каждому своему аналитику по персональному
компьютеру, который может обращаться по локальной сети к серверу баз данных.
8.6. Примеры
241
Кроме того, в сети работает дорогая автономная графическая рабочая станция,
используемая для особых проектов. В течение обычного 8-часового рабочего
дня 10 инженеров пользуются рабочей станцией и проводят в среднем по 30 мин
за сеанс.
Модель с одним сервером
Инженеры жалуются своему менеджеру, что им приходится долго ждать, часто по
часу и более, пока рабочая станция освободится, и просят установить дополнитель-
ные рабочие станции. Это удивляет менеджера, так как коэффициент использова-
ния рабочей станции составляет всего 5/8 (10 1/2 = 5 часов из 8). Чтобы убедить
менеджера, один инженер выполняет анализ очереди. Инженер принимает обыч-
ные допущения о бесконечной совокупности, случайном поступлении запросов и
экспоненциальном распределении времени обслуживания, что вполне разумно для
приближенных вычислений. С помощью формул из разделов 8.3 (см. табл. 8.4)
и 8.4 (для схемы М/М/1) инженер получает:
♦ среднее время ожидания освобождения станции
Т„ = -^- = 50 мин;
1-р
90-й процентиль времени ожидания
Т
mr (90) = — • 1п(10р) = 146,6 мин;
Р
♦ частота поступления инженеров
10
Л = — = 0,021 инженеров в минуту;
♦ среднее количество ожидающих инженеров
w = =1,0416 инженеров.
Эти расчеты показывают, что инженерам в самом деле приходится ждать, пока
рабочая станция освободится, в среднем почти час, а в 10 % случаев инженер дол-
жен ждать больше двух часов. Даже допуская 20-процентную ошибку в оценках,
время ожидания все равно оказывается слишком долгим. Более того, если инже-
неру нечем заняться во время ожидания, тогда каждый день теряется более одного
«инженеродня».
Модель с несколькими серверами
Инженеры убедили менеджера в необходимости установки дополнительных рабо-
чих станций. Они бы хотели, чтобы среднее время ожидания не превышало 10 мин
с 90-м процентилем, не превосходящим 15 мин. Это беспокоит менеджера, который
полагает, что если одна рабочая станция приводит к времени ожидания в 50 мин,
то для снижения этого интервала до 10 мин потребуется пять рабочих станций.
Инженеры принимаются за работу, чтобы определить, сколько понадобит-
ся рабочих станций. Есть две возможности: установить дополнительные рабочие
242
Глава 8. Анализ очередей
станции в том же помещении, что и первая рабочая станция (общая очередь к не-
скольким серверам), или распределить их по различным помещениям на разных
этажах (отдельная очередь к каждому серверу). Сначала рассмотрим случай с об-
щей очередью к нескольким серверам, то есть установку второй рабочей стан-
ции в том же помещении. Допустим, что добавление второй станции не повлияет
на частоту поступления запросов (10 инженеров в день). В этом случае доступное
время обслуживания за 8-часовой рабочий день составит 16 часов при потребнос-
ти в 5 часах (10 инженеров - 0,5 ч). Таким образом, коэффициент использования
будет равен 5/16 = 0,3125. С помощью формул из раздела 8.5 получим:
4- вероятность того, что оба сервера заняты
С(2, р) = С(2, 0,3125) = 0,1488;
♦ среднее время ожидания инженерами освобождения рабочей станции
СТ
7' =------— = 3,247 мин;
а N(l-p)
+ 90-й процентиль времени ожидания
Т
тт. (90) = —- 1п(10С) = 8,67 мин;
♦ среднее число ожидающих инженеров
w = ЛД = 0,07 инженера.
При такой схеме вероятность того, что инженеру придется ждать, оказывает-
ся менее 0,15, а среднее время ожидания лишь ненамного превосходит 3 минуты
с 90-процентным процентилем, не превышающим 9 мин. Несмотря на сомнения
менеджера, схема с очередью к нескольким серверам (к двум рабочим станциям)
легко справляется с требованиями проекта.
Поскольку инженеры размещаются на двух этажах здания, менеджер думает,
не будет ли удобнее разместить по одной рабочей станции на каждом этаже. Если
допустить, что трафик к каждой из рабочих станций разбит приблизительно по-
ровну, тогда мы получаем две очереди М/М/1, в каждой из которых по 5 инжене-
ров в течение 8-часового рабочего дня. Соответственно получаем:
4- коэффициент использования сервера
р = ЛГ5 = 0,3125;
4 среднее время ожидания инженерами освобождения рабочей станции
Т = - 13,64 мин;
1-р
4- 90-й процентиль времени ожидания
тт (90) = • 1п(10р) = 49,73 мин;
Р
4- среднее число ожидающих инженеров
w = ХТ„. = 0,142 инженера.
8.7. Очереди с приоритетами 243
Производительность этой системы существенно ниже, чем у модели общей очере-
ди к нескольким серверам, и не соответствует проектным требованиям. В табл. 8.5
подводятся итоги приведенных выше расчетов, а также даются результаты для четы-
рех и пяти выделенных рабочих станций. Обратите внимание на то, что при исполь-
зовании схемы с отдельной очередью к каждому серверу для удовлетворения тре-
бований проекта потребуется пять рабочих станций по сравнению с двумя рабочими
станциями в схеме с общей очередью к нескольким серверам.
Таблица 8.5. Результаты расчетов для разных схем очередей к серверам
Число рабочих станций Схема Р Т„ ^г„(90)
1 М/М/1 0,625 50,00 146,61
2 М/М/2 0,3125 3,25 8,67
2 2 М/М/1 0,3125 13,64 49,73
4 4 М/М/1 0,15625 5,56 15,87
5 5 М/М/1 0,125 4,29 7,65
Хотя, возможно, вы не являетесь экспертом в теории очередей, теперь вы знае-
те достаточно, чтобы недостатки схем с отдельной очередью к каждому серверу
стали для вас очевидными.
8.7. Очереди с приоритетами
До сих пор мы рассматривали очереди, в которых запросы обслуживаются на основе
дисциплины FIFO (First in First Out — первым прибыл, первым обслужен). Однако
как в сетях, так и в операционных системах во многих случаях желательно исполь-
зовать приоритеты. Приоритеты могут назначаться по-разному, например на основе
типа трафика. Если оказывается, что среднее время обслуживания для трафиков
различного типа идентично, тогда общие формулы для системы не изменяются,
хотя производительность системы на разных классах трафика будет различаться.
Важным является случай назначения приоритета на основе среднего времени
обслуживания. Часто запросам с меньшим ожидаемым временем обслуживания
дается более высокий приоритет, чем запросам с большим ожидаемым временем
обслуживания. Например, маршрутизатор может назначить потоку пакетов, содер-
жащих оцифрованную речь, более высокий приоритет по сравнению с потоком
данных. Кроме того, как правило, пакеты с данными короче пакетов с оцифрован-
ным телефонным сигналом. При такой схеме производительность высокоприори-
тетного трафика увеличивается.
Ниже перечислены формулы для очередей с одним сервером, применимые при
наличии двух классов приоритетов с различным временем обслуживания для каж-
дого класса. Эти результаты нетрудно обобщить для любого числа классов при-
оритетов. Для перечисленных формул имеют место следующие допущения:
♦ частота поступления запросов распределена по Пуассону;
♦ запросы с приоритетом 1 обслуживаются прежде запросов с приоритетом 2;
244 Глава 8. Анализ очередей
4- для запросов с равным приоритетом применяется дисциплина диспетчери-
зации FIFO (First in First Out — первым прибыл, первым обслужен);
обслуживание запроса не прерывается;
♦ запросы не выбрасываются из очереди.
Итак, общие формулы:
X = Xi + Х2;
pi = XiTsl;
р2 = Х2Д2;
р — pi + Рг;
= КТ + ^ТЛ-
’ X '* X '2
т; =—/;.! +^-д2.
г X ” X rl
Теперь формулы для случая, когда время обслуживания распределено экспо-
ненциально:
Pi(Pi7L +р2т;2).
^(1-Р|) ’
w2 =
Х,(1-р)
Чтобы оценить эффект от использования приоритетов, рассмотрим простой
пример потока данных, состоящего из смеси длинных и коротких пакетов, переда-
ваемых узлом сети с коммутацией пакетов, причем частоты поступления пакетов
двух типов одинаковы. Предположим, что длины пакетов обоих типов распреде-
лены экспоненциально и что средний размер длинных пакетов в десять раз боль-
ше среднего размера коротких. Допустим также, что пропускная способность ли-
нии составляет 64 Кбит/с и что средние длины пакетов равны 80 и 800 байт. Затем
допустим, что среднее время обслуживания коротких и длинных пакетов равно
0,01 с и 0,1 с соответственно, а частота поступления пакетов каждого типа состав-
ляет 8 пакетов в секунду. Чтобы длинные пакеты не задерживали короткие, назна-
чим более коротким пакетам более высокий приоритет. Тогда
Pi = 8 • 0,001 = 0,08 р2 = 8 • 0,01 = 0,8 р = 0,88;
7}, = 0,01 +
0,08-0,01 + 0,8-0,1
1 - 0,08
= 0,098 с;
8.8. Сети очередей
245
„ п4 0,98-0,01 nc„„
г, = 0,1 + —-----— =0,833 с;
л 1-0,88
Тг= 0.5 • 0,098 + 0,5 0,833 = 0,4655 с.
Таким образом, мы видим, что обслуживание высокоприоритетных пакетов вы-
полняется значительно лучше, чем низкоприоритетных.
8.8. Сети очередей
К сожалению, в распределенном окружении аналитик может встретиться не толь-
ко с изолированными очередями. Часто анализируемая система состоит из не-
скольких соединенных друг с другом очередей. Эту ситуацию иллюстрирует
рис. 8.7, где рядом с узлами показаны очереди, а соединяющие их линии представ-
ляют потоки данных. По сравнению с уже рассматривавшимися случаями подоб-
ная сеть оказывается сложнее по двум причинам:
♦ Имеет место разделение и объединение трафика, как, например, соответ-
ственно, в узлах 1 и 5 на рисунке.
Существуют цепочки очередей, например цепочка, образованная узлами 3
и 4 на рисунке.
Общего метода анализа очередей, содержащих вышеупомянутые элементы, нет.
Однако если трафик подчиняется распределению Пуассона, а время обслужива-
ния распределено экспоненциально, существует точное и простое решение. В дан-
ном разделе мы сначала изучим два описанных выше элемента, а затем предста-
вим метод анализа системы очередей.
Разделение и объединение потоков данных
Предположим, что трафик прибывает в очередь со средней скоростью X и что есть
Два пути, А и В, по которым пакеты могут отправляться дальше, то есть имеет
Место разделение потоков (рис. 8.8, а). Когда запрос обслужен и покидает оче-
редь, он делает это по пути А с вероятностью Р и по пули В с вероятностью (1 - Р).
В общем случае распределение потоков А и В будет отличаться от распределе-
ния входящего потока. Однако если входящий поток подчиняется распределению
246 Глава 8. Анализ очередей
Пуассона, тогда два исходящих потока также будут подчиняться распределению
Пуассона со средними частотами РХ и (1 - P)Z.
е
Рис. 8.8. Элементы сетей очередей
Сходная ситуация возникает при объединении потоков (рис. 8.8, б). Если объ-
единяются два потока, подчиняющиеся распределению Пуассона, со средними ча-
стотами Л.1 и Л.2, получающийся в результате поток также подчиняется распределе-
нию Пуассона со средней частотой, равной Zi + Лг.
Приведенные выше результаты можно обобщить для любого количества объ-
единяемых или разделяемых потоков.
Цепочки очередей
На рис. 8.8, в показан пример цепочки очередей к одному серверу каждая. Вход
каждой очереди, кроме первой, является выходом предыдущей очереди. Допустим,
что на входе первой очереди поток подчиняется распределению Пуассона. В этом
случае, если время обслуживания каждой очереди подчиняется экспоненциально-
му распределению, а длина очередей не ограничена, на выходе каждой очереди
также будет поток, подчиняющиеся распределению Пуассона и статистически
идентичный входному. Когда этот поток подается на вход следующей очереди, за-
держки во второй очереди будут такими же, как если бы исходный поток миновал
первую очередь и направлялся напрямую во вторую очередь. Таким образом, оче-
реди являются независимыми, и их можно анализировать по отдельности. Поэто-
му средняя суммарная задержка для системы цепочек очередей равна сумме сред-
них задержек каждой очереди.
Этот результат можно расширить до случая, в котором отдельные или все узлы
цепочки представляют собой очереди к нескольким серверам.
8.8. Сети очередей
247
Теорема Джексона
| Для анализа сети очередей может использоваться теорема Джексона (Jackson). Эта
теорема основана на трех допущениях:
4- Сеть очередей состоит из т узлов, каждый из которых предоставляет неза-
висимое обслуживание с экспоненциально распределенным временем.
4- Запросы поступают в систему снаружи на любой из узлов с частотой, рас-
пределенной по Пуассону.
♦ После обслуживания на узле запрос немедленно с некоторой фиксирован-
ной вероятностью поступает на другой узел или покидает систему.
Теорема Джексона утверждает, что в подобной сети очередей каждый узел
представляет собой независимую очередь с распределенным по Пуассону входным
потоком, детерминированным в соответствии с принципами разделения, объеди-
нения и цепочек очередей. Таким образом, каждый узел может анализироваться
отдельно от остальных при помощи схем М/М/1 и М/М/М а результаты могут
комбинироваться с использованием обычных статистических методов. Средние
значения времени задержки на узлах можно складывать, но ничего нельзя сказать
о моментах более высокого порядка времени задержки (например, о среднеквад-
ратичных отклонениях).
Использование теоремы Джексона оказывается привлекательным для прило-
§ жений, работающих в сетях с коммутацией пакетов. Подобную сеть можно моде-
’t: лировать как сеть очередей. Каждый пакет представляет собой индивидуальный
! запрос. Предположим, что каждый пакет передается отдельно и что на каждом
узле с коммутацией пакетов на пути от отправителя до получателя пакет устанав-
ливается в очередь на передачу по следующей линии. Обслуживание на каждом
узле заключается в передаче пакета, а время обслуживания пропорционально дли-
не пакета.
Недостаток такого подхода состоит в том, что нарушается условие теоремы, а
& именно это не тот случай, в котором обслуживание при распределении независи-
к мо. Поскольку длина пакета не изменяется при его прохождении по маршруту,
Ё процесс поступления в каждую очередь оказывается коррелированным с процес-
* сом обслуживания. Однако в [ 137] показано, что благодаря усредняющему эффек-
ту объединения и разделения потоков предположение о независимых временах
К обслуживания вполне приемлемо.
f Приложение для сетей с коммутацией пакетов
> Рассмотрим сеть с коммутацией пакетов, состоящую из узлов, соединенных лини-
I ями передачи. Каждый узел действует как интерфейс для нескольких присоеди-
I ненных систем, а также как отправитель и получатель трафика. Внешняя нагрузка
на сеть может быть охарактеризована так:
К Л' Л'
7=1 Л=1
248
Глава 8. Анализ очередей
Здесь:
у — суммарная нагрузка в пакетах в секунду;
♦ — нагрузка между отправителем j и получателем k;
+ N— суммарное количество отправителей и получателей.
Поскольку пакет может на пути от отправителя к получателю преодолеть не-
сколько линий, суммарная внутренняя нагрузка будет выше предложенной:
i=i
Здесь:
у = суммарная нагрузка на всех линиях сети;
у; = нагрузка на линию i;
+ L = суммарное количество линий. ,
Внутренняя нагрузка будет зависеть от фактического пути через сеть, по ко-
торому идут пакеты. Мы будем предполагать, что используется такой алгоритм
маршрутизации, при котором нагрузка на индивидуальные линии Z,- может быть
определена по предлагаемой нагрузке у,т. Для любой схемы маршрутизации мы
можем по данным параметрам нагрузки определить среднее количество линий, по
которым пройдет пакет. Если немного’ подумать, то становится очевидным, что
среднюю длину всех путей можно найти при помощи формулы
Е[количество линий в пути] = - .
Y
Теперь наша задача заключается в том, чтобы определить величину средней
задержки Тпрохождения пакета через сеть. Для этого можно воспользоваться фор-
мулой Литтла (см. табл. 8.4 в разделе 8.3). Для каждой линии сети среднее число
ожидающих и обслуживаемых запросов равно
Ъ ~ KTri.
Здесь Т„ представляет собой задержку каждой очереди, которую еще предсто-
ит определить. Предположим, что мы суммируем эти величины. Таким образом,
мы получим среднее суммарное количество пакетов, ожидающих во всех очередях
сети. Оказывается, что формула Литтла работает для множества очередей. Таким
образом, число пакетов в сети, обслуживаемых и ожидающих обслуживания, мо-
жет быть выражено как уТ. Объединив эти две формулы, получаем:
Чтобы найти значение Г, нужно определить значения индивидуальных задер-
жек T,i. Поскольку мы предполагаем, что каждая очередь может рассматриваться
как независимая со схемой М/М/1, это несложно вычислить:
Т Т
'Т' _ Si __ S!
i
8.9. Другие модели очередей
249
Время обслуживания Tsi для линии i представляет собой всего лишь отноше-
ние длины пакета в битах (М) к скорости передачи данных по этой линии в битах
в секунду (Ri)- Таким образом,
М
Ri М
Т"~ 1- МХ’ R‘ ~ Ш'‘
R,
Собрав все эти элементы вместе, мы можем сосчитать среднее время задержки
пакетов, отправляемых по сети:
„ 1 v-
Т~
8.9. Другие модели очередей
В этой главе мы рассмотрели только модели очередей одного типа. В действитель-
ности существует множество моделей, различающихся ключевыми факторами:
способом обработки блокированных запросов;
4- количеством источников трафика.
Когда запрос прибывает на сервер и обнаруживает, что сервер занят, или по-
ступает на устройство с несколькими серверами и находит, что все серверы заня-
ты, тогда такой запрос называют блокированным (blocked). Блокированные за-
просы могут обрабатываться по-разному. Во-первых, запрос может быть помещен
в очередь и дожидаться, пока какой-либо сервер не освободится. В литературе,
посвященной телефонному трафику, такая политика называется отложенными
неуспешными вызовами (lost calls delayed), хотя в действительности эти вызовы
нельзя считать неуспешными. В качестве альтернативы запрос не ставится в оче-
редь. Это, в свою очередь, приводит к принятию двух предположений о действиях
запроса. Запрос может ожидать в течение некоторого случайного интервала вре-
мени, а затем повторить попытку. Такая стратегия называется очищенными неус-
пешными вызовами (lost calls cleared). Если запрос многократно без перерыва пы-
тается получить обслуживание, его относят к удерживаемым неуспешным вызовам
(lost calls held). Модель отложенных неуспешных вызовов более всего подходит
Для большинства компьютерных проблем и проблем передачи данных. Модель
очищенных неуспешных вызовов, как правило, более всего подходит для системы
коммутации телефонных каналов.
Второй ключевой элемент модели трафика заключается в том, предполагается
ли число источников конечным или бесконечным. Для модели с бесконечным ко-
личеством источников частота поступления запросов считается фиксированной.
Для модели с конечным количеством источников частота поступления запросов
будет зависеть от количества уже занятых источников. Таким образом, если
каждый из L источников посылает запросы с частотой Л/Е, тогда, если очередь
свободна, то частота поступления запросов равна Л. Однако если запросы от К
250 Глава 8. Анализ очередей
источников определенное время находятся в очереди, тогда мгновенная частота
поступления запросов в это время будет равна Х(£ - K)/L. С моделями с беско-
нечным количеством источников проще иметь дело. Допущение о бесконечном
количестве источников оправдано, когда количество источников по меньшей мере
в 5 или в 10 раз превосходит возможности системы.
8.10. Оценка параметров модели
Для анализа очередей нужно оценить значения входных параметров, а именно
среднее значение и среднеквадратичное отклонение частоты поступления за-
просов и времени обслуживания. Если мы обдумываем новую систему, то, воз-
можно, эти оценки должны быть основаны на анализе и оценке превалирующего
оборудования и работающих образцов. Однако часто для исследования доступна
существующая система. Например, у фирмы имеется множество терминалов, пер-
сональных компьютеров и хостов, соединенных при помощи прямых соединений
и мультиплексоров. Желательно заменить все подобные соединительные устрой-
ства локальной сетью. Чтобы оценить параметры проектируемой локальной сети,
можно измерить текущую нагрузку, генерируемую каждым устройством.
Выбор дискретных данных
Замеры производятся в виде дискретных отсчетов. Отдельные параметры, напри-
мер частота, с которой терминал генерирует пакеты, оцениваются путем наблюде-
ния за количеством пакетов в течение определенного периода времени.
Наиболее важной величиной, которую следует оценить, является среднее значе-
ние. Для многих формул из разделов 8.4 и 8.5 это единственная величина, которую
нужно оценить. Оценку среднего значения называют выборочным средним X
и вычисляют следующим образом:
_ 1 Л'
Х = — Ух,..
Здесь:
♦ 2V—размер выборки;
♦ X, — i-й элемент выборки.
Важно отметить, что выборочное среднее само является случайной переменной.
Например, если вы производите выборку некоторой совокупности и вычисляете
выборочное среднее, причем делаете это несколько раз, то полученные значения
будут различаться. Таким образом, мы можем говорить о среднем значении выбо-
рочного среднего и о его среднеквадратичном отклонении или даже о распределении
вероятностей выборочного среднего. Чтобы не путать эти понятия, обычно распреде-
ление вероятностей исходной случайной переменной X называют основным распре-
делением (underlying distribution), а распределение вероятностей выборочного сред-
него X — выборочным распределением (sampling distribution) среднего значения.
Выборочное среднее значение обладает замечательным свойством, заключаю-
щимся в том, что практически для всех основных распределений при увеличении
8.10. Оценка параметров модели
251
N распределение вероятностей выборочного среднего стремится к нормальному
распределению. Предположение о нормальности этого распределения неверно толь-
ко в том случае, если значение Nочень мало либо основное распределение в боль-
шой степени анормально.
Среднее значение и дисперсия X могут быть определены по следующим фор-
мулам:
Е[Х] = Е[Х] = ц;
2
Var[Xj=
Таким образом, если вычисляется выборочное среднее, его ожидаемая величина
совпадает со средним значением лежащей в основе случайной переменной, а диспер-
сия выборочного среднего при увеличении N уменьшается. Эти характеристики
иллюстрирует рис. 8.9. На графике изображено основное экспоненциальное распре-
деление со средним значением ц = 1. Это может быть распределение интервалов
времени обслуживания сервера или распределение интервалов времени поступления
запросов пуассоновского процесса. Если для оценки значения р используется выбор-
ка размера 10, тогда ожидаемое значение равно р, но фактическое значение вполне
может отличаться от ожидаемого на 50 %. Если размер выборки равен 100, тогда
разброс значений существенно сужается, так что мы можем ожидать величину фак-
тического выборочного среднего для любой заданной выборки гораздо ближе к р.
Определенное ранее выборочное среднее может напрямую использоваться для
оценки времени обслуживания сервера. Для определения частоты поступления
можно наблюдать интервалы между поступлениями Nзапросов, сосчитать выбо-
рочное среднее, а затем вычислить оценку частоты поступления. Более простой
способ определения частоты поступления запросов заключается в использовании
следующей формулы:
Здесь ДГпредставляет собой число поступивших запросов за период времени Т.
В большинстве случаев для анализа очередей достаточно определить оценку
среднего значения. Но для некоторых важных уравнений также требуется оценка
дисперсии, лежащей в основании случайной переменной ох. Выборочная диспер-
сия вычисляется следующим образом:
Ожидаемое значение S1 2 обладает желаемой величиной
Е[52]= ох.
Дисперсия 32 зависит от основного распределения, и, как правило, ее трудно вы-
числить. Однако, как и следовало ожидать, дисперсия S2 уменьшается с увеличением N.
1 В действительности это все тот же метод и та же формула, так как выборочное среднее для интерва-
Лов времени поступления вычисляется именно как T/N. — Примеч. перев.
252 Глава 8 Анализ очередей
Рис. 8.9. Выборочные средние значения для экспоненциально распределенной совокупности
В табл. 8.6 обсуждавшиеся в данном разделе понятия приведены вместе.
Таблица 8.6. Статистические параметры
Параметр Совокупность Выборочное среднее Выборочная дисперсия
Случайная переменная X — 1 Л' х = — Ух, 52 =—5— У (X, -X)2
Ожидаемое значение Е[Х] = р Е[Х]=ц E[S2] = О2-
Дисперсия Var[X] = E[(X-p)2] = О2 - Оу Var[ X ] = —у N
Ошибки выборки
При оценке на основе выборки таких значений, как среднее и среднеквадратичное
отклонение, мы из сферы вероятностей переходим в область статистики. Это слож-
ная тема, которую мы не станем здесь изучать, а лишь сопроводим ее некоторыми
ком ментариями.
8.11. Рекомендуемые литература и веб-сайты
253
Вероятностная природа оцениваемых значений является источником ошибок,
называемых ошибками выборки (sampling errors). В целом, чем больше размер
выборки, тем меньше среднеквадратичное отклонение выборочного среднего или
другой величины и, таким образом, тем ближе паша оценка к фактическому зна-
чению. Принимая определенные разумные предположения о природе исследуемой
случайной переменной и о случайности выборки, можно определить вероятность
того, что выборочное среднее или выборочное среднеквадратичное отклонение
находится в пределах определенного диапазона от фактической величины средне-
го значения или среднеквадратичного отклонения. Эта величина часто сообщает-
ся вместе с результатами выборки. Например, результат опроса общественного
мнения, как правило, сопровождается комментариями вида: «Погрешность резуль-
тата не превышает 5 % с вероятностью (доверительной) 99 %».
Однако существует другая разновидность ошибок, которую неспециалисты
часто упускают из виду, — систематическая ошибка (bias). Например, если при
проведении опроса общественного мнения опрашиваются только представители
определенной социально-экономической группы, результаты не обязательно будут
репрезентативны для всей популяции. В контексте передачи данных результаты
измерений, произведенные в разное время суток, могут сильно отличаться друг от
друга. Если мы собираемся проектировать систему, способную выдерживать ожи-
даемую пиковую нагрузку, тогда нам следует исследовать трафик в то время дня,
когда максимальная нагрузка наиболее вероятна.
8.11. Рекомендуемые литература
и веб-сайты
Книга [220] представляет собой хорошее практическое руководство. В ней содер-
жится детальное обсуждение приложений анализа очередей, а также множество
хорошо проработанных примеров. К этой книге также прилагается диск с исчер-
пывающей библиотекой подпрограмм на языке Pascal для расчета характеристик
многих ситуаций в очередях. Еще одно хорошее пракп i чес кое руководство — [106].
Для тех, кто желает глубже погрузиться в теорию очередей, существует огром-
ное количество книг. Книга [103] посвящена вопросам теории очередей и ее при-
менения к компьютерам и передаче данных. Книга [218] является замечательным
пособием, посвященным темам обмена данными и сетей. В [136] и [137] содержится
классическая интерпретация теории очередей с детальным обсуждением компью-
терных сетей. Возможно, лучшей книгой по моделированию производительности,
в которой обсуждаются анализ и моделирование систем очередей, является [125].
Книга [181] представляет собой хорошее введение в статистику. Существует
Множество книг, содержащих более детальное и тщательное обсуждение. Из них
[41] особенно хорошо подходит для самостоятельного изучения. Два замечательных
руководства по теме практического применения статистики были опубликованы
правительством США. Во все еще актуальном справочнике [165] содержатся таб-
лицы, формулы и примеры, полезные при выборе соответствующей процедуры
254
Глава 8. Анализ очередей
определения значений по выборкам и получении результатов. Книга [149] содер-
жит детальное пошаговое описание процедур для выполнения различных статисти-
ческих исследований, а также определенный объем учебной информации по этой
теме. Теории статистического вывода посвящено все еще доступное очень хоро-
шее издание [155].
Рекомендуемым веб-сайтом является Myron Hlynka’s Queueing Theory Page. Этот
сайт содержит ответы на часто задаваемые вопросы, примеры, ссылки на другие
сайты, посвященные теории очередей, и даже предложения о трудоустройстве.
8.12. Задания
1. В разделе 8.3 приводился интуитивный аргумент для подтверждения фор-
мулы Литтла. Сформулируйте аналогичный аргумент для подтверждения
равенства г = ХТГ.
2. На рис. 8.3 показана зависимость количества запросов в системе от време-
ни. Эта величина может рассматриваться как разность процессов поступле-
ния и отправления пакетов в виде n(t) = «(/) - d(t).
а) покажите на одном графике функции а(0 и d(t), образующие функцию
n(t), показанную на рис. 8.3;
б) с помощью графика, построенного в задании а, сформулируйте интуи-
тивный аргумент для подтверждения формулы Литтла. Подсказка: рас-
смотрите область между двумя ступенчатыми функциями, сначала сло-
жив вертикальные прямоугольники, а затем добавив горизонтальные
прямоугольники.
3. Владелец магазина замечает, что в среднем в магазин заходят 18 посетите-
лей и что, как правило, 8 посетителей в среднем постоянно находятся в ма-
газине. Чему равно среднее время пребывания клиента в магазине?
4. Программа, моделирующая многопроцессорную систему, начинает работу
без заданий в очереди и заканчивает работу без заданий в очереди. Програм-
ма сообщает, что среднее количество заданий в системе за время сеанса
равно 12,356, средняя скорость поступления заданий составляет 25,6 заданий
в минуту, а среднее время задержки для задания равно 8,34 мин. Правильно
ли работает программа?
5. В разделе 8.3 приводился интуитивный аргумент для подтверждения отно-
шения р = ТТХ для системы с одним сервером. Сформулируйте аналогичный
аргумент для подтверждения равенства р = TTS/Nдля системы с нескольки-
ми серверами.
6. Если в очередь М/М/1 запросы поступают со скоростью 2 запроса в минуту
и обслуживаются со скоростью 4 запроса в минуту, сколько клиентов в сред-
нем находятся в системе? Сколько клиентов в среднем обслуживаются?
7. Чему равен коэффициент использования очереди М/М/1, в которой в сред-
нем находятся четыре человека?
8.12. Задания
255
8. Среднее время транзакции установленного в супермаркете банкомата рав-
но 2 мин. Посетители обращаются к банкомату в среднем раз в 5 мин.
Чему равно среднее время ожидания клиента в этом случае? Чему равен
90-й процентиль резидентного времени? Сколько людей в среднем стоят
в очереди к банкомату? Предполагается использование схемы М/М/1.
9. Сообщения, которые следует отправить по линии связи со скоростью
9600 бит/с, прибывают случайным образом. Коэффициент использования
линии составляет 70 %. Средняя длина сообщения равна 1000 байт. Опре-
делите среднее время ожидания для сообщений с постоянной длиной и для
экспоненциально распределенной длины сообщений.
10. Сообщения трех различных размеров проходят через коммутатор сообще-
ний. Обслуживание 70 % сообщений занимает 1 мс, для обслуживания 20 %
сообщений требуется 3 мс, а 10 % сообщений обслуживаются за 10 мс. Сосчи-
тайте среднее время, которое сообщение проводит на коммутаторе, а также
среднее количество сообщений на коммутаторе, если сообщения прибыва-
ют со следующей сред! гей скоростью: а) одно за 3 мс, б) одно за 4 мс и в) одно
за 5 мс.
11. Сообщения поступают на коммутатор для последующей передачи по опре-
деленной линии в виде пуассоновского потока со средней скоростью 180 сооб-
щений в час. Длины сообщений распределены экспоненциально со средним
значением, равным 14 400 символов. Скорость передачи данных в линии
составляет 9600 бит/с.
а) чему равно среднее время ожидания на коммутаторе;
б) сколько сообщений в среднем ожидают передачи на коммутаторе?
12. Часто входные потоки систем очередей не являются независимыми и слу-
чайными, а запросы в них группируются в пакеты. При этом среднее время
ожидания оказывается большим, чем для пуассоновского потока. Рассмот-
рим эту проблему на простом примере. Допустим, запросы поступают в оче-
редь пакетами из М запросов фиксированного размера. Поток пакетов яв-
ляется пуассоновским со средней скоростью, равной Х/М, что соответствует
скорости поступления запросов X. Время обслуживания каждого запроса
равно Ts, а среднеквадратичное отклонение времени обслуживания равно o7-s.
а) если мы будем обращаться с пакетами заданий как с заданиями большо-
го размера, чему будут равны среднее значение и среднеквадратичное
отклонение времени обслуживания пакета? Чему равно среднее значе-
ние и среднеквадратичное отклонение времени обслуживания пакета;
б) чему равно среднее значение времени обслуживания запроса, после того
как началось обслуживание пакета, в котором он содержится? Предпо
ложим, что запрос с равной вероятностью может занимать любую из М
позиций. Чему равно среднее значение времени ожидания для одного
запроса;
в) проверьте результаты задания б, показав, что при М = 1 ситуация сводит-
ся к случаю М/G/1. Как варьируются результаты для значений М > 1?
256 Глава 8. Анализ очередей
13. Рассмотрим одну очередь с постоянным временем обслуживания, равным
4 с, и пуассоновским входным потоком со средней скоростью 0,2 запроса
в секунду.
а) определите среднее значение и среднеквадратичное отклонение размера
очереди;
б) определите среднее значение и среднеквадратичное отклонение време-
ни нахождения запроса в системе.
14. Рассмотрим узел сети ретрансляции кадров, обрабатывающий пуассоновс-
кий поток входящих кадров, которые должны передаваться по исходящей
линии с пропускной способностью 1 Мбит/с. Поток состоит из кадров двух
типов. Длины кадров обоих типов подчиняются одному и тому же экспо-
ненциальному распределению со средним значением 1000 бит.
а) предположим, что приоритеты не используются. Суммарная скорость
поступления кадров обоих типов равна 800 кадров в секунду. Чему рав-
но среднее время нахождения в системе (Г,) для всех кадров;
б) теперь допустим, что двум типам кадров присвоены разные приорите-
ты. Кадры типа 1 поступают со скоростью 200 кадров в секунду, а кадры
типа 2 — со скоростью 600 кадров в секунду. Рассчитайте среднее время
нахождения в системе для кадров типа 1, кадров типа 2 и для кадров обо-
их типов;
в) повторите расчеты задания б для = 400 кадров в секунду;
г) повторите расчеты задания б для Zi = 600 кадров в секунду и = 200 кад-
ров в секунду.
15. Протокол MLP (MultiLink Protocol — многоканальный протокол) представ-
ляет собой часть стандарта Х.25. Сходный протокол используется в архи-
тектуре SNA (System Network Architecture — системная сетевая архитекту-
ра). В протоколе MLP пара узлов сети соединена несколькими каналами
передачи данных, которые используются в качестве объединенного ресурса
для передачи пакетов независимо от номера виртуального канала. Когда
пакет предоставляется протоколу MLP для передачи, может выбираться
любая доступная линия. Например, если две локальные сети соединены па-
рой мостов, для увеличения производительности и коэффициента готов-
ности мосты могут соединяться несколькими двухточечными линиями. По
сравнению с простым протоколом передачи данных для метода MLP требу-
ется дополнительная обработка кадра. Для протокола необходим специаль-
ный заголовок MLP. Альтернативный подход заключается в том, чтобы
поочередно ставить каждый входящий кадр в очередь на одну исходящую
линию. Это упростит обработку, но какой эффект это окажет на производи-
тельность? Рассмотрим конкретный пример. Предположим, что два узла
соединены пятью линиями с пропускной способностью 9600 бит/с, средний
размер пакета равен 100 байт, размеры пакетов распределены экспоненци-
ально и пакеты прибывают со скоростью 48 пакетов в секунду.
i
8.12. Задания
257
а) для схемы с одним сервером вычислите р и Тг;
б) для схемы с несколькими серверами можно рассчитать, что С-функция
Эрланга имеет значение 0,554. Определите Тг.
16. Существует дополнение к стандарту Х.25, описывающему сети с коммута-
цией пакетов, представляющее собой набор стандартов для сборщика/раз-
борщика пакетов (Packet Assembler/Disassembler, PAD), определенного в
стандартах Х.З, Х.28 и Х.29. Сборщик/разборщик пакетов используется для
соединения асинхронных терминалов в сеть с коммутацией пакетов. Каж-
дый терминал, присоединенный к PAD, посылает данные посимвольно. Эти
данные буферизируются в PAD, а затем собираются в пакет Х.25, который
передается по сети с коммутацией пакетов. Размер буфера равен максималь-
ной длине поля данных пакета Х.25. Пакет собирается из накопленных сим-
волов и передается, когда заполняется буфер либо когда PAD получает спе-
циальный управляющий символ, например символ перевода каретки, либо
когда истекает интервал ожидания. В данной задаче мы будем игнорировать
последние два варианта. На рис. 8.10 показана модель системы очередей для
PAD. Первая очередь моделирует задержку для символа, ожидающего по-
мещения в пакет. Эта очередь полностью очищается при заполнении. Вто-
рая очередь моделирует задержку ожидания передачи пакета. Используйте
следующие обозначения: А — распределенная по Пуассону скорость поступ-
ления символов от каждого терминала; С — скорость передачи в выходном
канале в символах в секунду; М — количество символов данных в пакете;
Н — количество служебных символов в пакете; К — число терминалов.
Теперь собственно задания.
а) определите среднее время ожидания для символа во входной очереди;
б) определите среднее время ожидания для пакета в выходной очереди;
в) определите среднее время нахождения символа в PAD. Оформите ре-
зультат в виде графика зависимости от нормализованной нагрузки.
Рио. 8.10. Модель системы очередей для PAD
258 Глава 8. Анализ очередей
17. Часть трафика Р от одиночного экспоненциального сервера поступает на
вход, как показано на рис. 8.11. На рисунке символ Л обозначает пропуск-
ную способность системы, равную скорости на выходе сервера.
а) определите пропускную способность системы, коэффициент использо-
вания сервера и среднее время нахождения в системе для одного прохо-
да через сервер;
б) определите среднее количество проходов через сервер, совершаемых па-
кетом, и среднее суммарное время, которое пакет проводит в системе.
Рис. 8.11. Очередь с обратной связью
Глава 9
Самоподобный трафик
Мысли, в которых жил Сведенборг, — универсальность каждо-
го закона природы; доктрина Платона о шкале или степенях;
преобразования всех и вся одного в другое, и, таким образом,
соответствие всех частей; удивительная загадка о том, что ма-
лое объясняет большое, а большое объясняет малое. Эта теория
берет свое начало от древнейших философов, и, пожалуй, лучше
всего подтверждается новейшими исследованиями. Она состо-
ит в том, что природа вечно повторяет саму себя на последую-
щих витках. Как утверждает старый афоризм, природа всегда
подобна самой себе.
Ральф Вальдо Эмерсон. Представительные мужчины
Анализ очередей, представленный в главе 8, обладает огромным значением для
проектировщиков сетей и системных аналитиков и очень полезен при планирова-
нии ресурсов и предсказании производительности. Однако во многих реальных
случаях результаты, полученные на основе анализа очередей, существенно отли-
чаются от фактически наблюдаемой производительности. Вспомним, что анализ
очередей применим в том случае, если график данных подчиняется распределе-
нию Пуассона. В последние годы ряд исследований показал, что во многих ситуа-
циях характер трафика ближе к самоподобному, чем к пуассоновскому.
Концепция самоподобия (self-similarity) тесно связана с получившим большую
известность понятием фракталов и теорией хаоса. Мы начнем эту главу с описа-
ния явления самоподобия. Затем рассмотрим самоподобный трафик, включая сви-
детельства его существования и ключевые характеристики. Следующий раздел
посвящен влиянию самоподобного трафика на производительность в сравнении с
пуассоновским трафиком. Затем будут обсуждаться методы моделирования само-
подобного трафика и оценки его ключевых параметров. Во всех дискуссиях осо-
бое значение имеет параметр Херста (Hurst), описываемый также в разделе 9.6.
При обсуждении материала этой главы используются понятия из области сто-
хастических процессов. Для читателей, не знакомых с данным предметом, совету-
ем вернуться к разделу 7.3 в главе 7.
9.1. Самоподобие
Предположим, что вы наблюдаете за мегабитной линией ретрансляции кадров, по
. которой передаются кадры фиксированного размера 4000 бит, так что время пере-
260
Глава 9. Самоподобный трафик
дачи каждого кадра составляет 4 мс. Время прибытия кадров записывается на сто-
роне получателя (время, когда прибывает первый бит каждого кадра):
О 8 24 32 72 80 96 104 216 224 240 248 288 296 312 320
648 656 672 680 720 728 744 752 864 872 888 896 936 944 960 968
Таким образом, первый кадр прибывает в момент времени t = 0 мс, второй —
в момент t = 8 мс и т. д.
В данном случае трудно разглядеть какую-либо закономерность или сосчитать
статистические параметры. Однако трафик выглядит пульсирующим, как и сле-
довало ожидать от потока данных. Некоторые значения времени поступления кад-
ров группируются, а между группами (кластерами) есть промежутки. Максималь-
ный промежуток между кадрами составляет 328 мс с момента времени 320 мс до
момента времени 648 мс, но имеются также промежутки меньшей длительности,
включая многочисленные паузы по 40 мс и более, что эквивалентно, соответствен-
но, 10 кадрам и более. Сгруппируем трафик, считая кластером любую группу кад-
ров, в которой нет пауз больших, чем пять длительностей передачи кадра (20 мс),
и запишем начальное время каждого кластера. Мы получим:
0 72 216 288 648 720 864 936
Промежутки между кластерами неодинаковы, и понять закономерность трафи-
ка все также трудно. Попытаемся сгруппировать трафик на более высоком уров-
не. Определим кластер как группу кадров, в которой нет промежутков больших,
чем 10 интервалов передачи кадров (40 мс). Теперь мы получим следующие зна-
чения времени поступления групп:
0 216 648 864
В данном случае интервалы равны 216,432,216. Трафик выглядит как два кла-
стера с промежутком между ними, за которыми следует больший промежуток, а
затем снова два кластера с небольшим промежутком между ними. Теперь вернем-
ся и рассмотрим предыдущую группу из восьми кластеров, и мы снова увидим ту
же закономерность. Первые четыре значения времени прибытия следуют той же
схеме (прибытие, короткий интервал, прибытие, длинный интервал, прибытие,
короткий интервал, прибытие). Та же система наблюдается для четырех последних
кадров. Возвращаясь к исходному набору из 32 кадров, мы наблюдаем ту же по-
следовательность, повторенную восемь раз. Таким образом, у нас есть шаблон,
встречающийся на самом нижнем уровне и повторяющийся на более высоких
уровнях группирования. То есть временная последовательность проявляется в
виде одного и того же шаблона независимо от степени разрешения. В этом суть
самоподобия.
Самоподобие представляет собой настолько важное понятие, что просто уди-
вительно, что его совсем недавно стали применять при анализе передачи данных.
Всеобъемлющий характер самоподобия подчеркнул в своем достопамятном заяв-
лении Манфред Шрёдер (Manfred Schroeder) [198]:
9.1. Самоподобие
261
«Самоподобие представляет собой понятие, объединяющее фракталы, хаос и
степенные законы. Самоподобие, или инвариантность, относительно изменений
масштаба или размера представляет собой отличительную черту многих законов
природы и бесчисленных явлений в окружающем нас мире. Самоподобие являет-
ся в действительности одной из решающих симметрий, формирующих нашу все-
ленную и оказывающих влияние на наши попытки понять ее».
Явление, обладающее свойством самоподобия, выглядит одинаково или оди-
наково ведет себя при его рассмотрении с разной степенью «увеличения» или в
разном масштабе. Масштабируемой величиной может быть пространство (длина,
ширина) или время. В этой главе нас будут интересовать временные последова-
тельности и стохастические процессы, демонстрирующие свойство самоподобия
во времени.
Обсуждаемый в данном разделе шаблон проще увидеть на рисунке. На рис. 9.1, а
показана последовательность поступлений кадров в зависимости от времени. Каж-
дая вертикальная линия соответствует одному кадру. Ширина линии соответству-
ет 4 мс, то есть времени, необходимому для приема кадра целиком, от первого бита
до последнего. На рис. 9.1, б показаны данные, сгруппированные в четыре кластера.
Высота и ширина вертикальных линий в этом случае пропорциональна масштабу
группирования. На рисунке легко видеть, что один и тот же шаблон (прибытие,
короткий интервал, прибытие, длинный интервал, прибытие, короткий интервал,
прибытие) можно видеть при разной степени разрешения.
a Illi НИ Illi Illi Illi Illi 1111 1111
Данный пример получен из множества знаменитого конструктора Кантора
(Cantor). Его можно найти практически в любой книге, посвященной теме хаоса,
фракталов и нелинейной динамики. На рис. 9.2 показано устройство множества
Кантора, подчиняющегося следующим правилам:
1. Начните с закрытого интервала [0, 1], представленного линейным сегмен-
том.
2. Удалите открытую среднюю треть линии, то есть исключая концы удаляе-
мого интервала.
3. Для каждого следующего шага удалите среднюю треть линий, оставшуюся
после предыдущего шага.
262 Глава 9. Самоподобный трафик
Рис. 9.2. Множество Кантора для пяти уровней рекурсии
По существу, это рекурсивный процесс, который точнее можно определить сле-
дующим образом. Пусть 5, представляет множество Кантора после г уровней ре-
курсии. Тогда
So = [0,1];
St = [0,1/3] о [2/3,1];
S2 = [0,1/9] u [2/9,1/3] и [2/3, 7/9] и [8/9,1].
Если мы будем рассматривать линию Кантора как временную шкалу, тогда на
каждом последующем шаге масштаб временной шкалы увеличивается втрое. Об-
ратите внимание на то, что на каждом шаге левая (и правая) часть множества
является точной копией полного множества на предыдущем шаге. Канторово мно-
жество обладает двумя свойствами, наблюдаемыми во всех явлениях самоподобия.
4- Оно обладает структурой, обнаруживаемой при любом сколь угодно малом
масштабе. Если многократно увеличивать часть множества, мы будем про-
должать видеть сложный узор точек, разделенных интервалами разного раз-
мера. Подобно замысловатому шпионскому детективу со сложными взаи-
мосвязями, этот процесс кажется бесконечным. Это в корне отличается от
обычной непрерывной кривой, которая при увеличении становится все бо-
лее и более гладкой.
4- Структура повторяется. Самоподобная структура содержит уменьшенные
копии самой себя на всех уровнях масштабирования. Например, на каждом
шаге левая (и правая) часть канторова множества является точной копией
полного множества на предыдущем шаге.
Эти свойства не могут выполняться бесконечно для реальных объектов. При ка-
ком-то уровне разрешения структура и подобие разрушаются. Но многие явления
проявляют свойство самомподобия на большом количестве уровней разрешения.
9.2. Самоподобный трафик данных
263
Хотя наш пример является слишком простым и надуманным, изучая его, мы
можем лучше понять некоторые особенности самоподобного трафика. Возможно,
наиболее замечательной особенностью самоподобного трафика в контексте про-
изводительности сетей является устойчивость кластеризации. В пуассоновском
трафике кластеризация наблюдается в краткосрочном масштабе, но сглаживается
в долгосрочном1. Мы можем спроектировать систему из серверов и очередей с буфе-
рами в расчете на подобное долгосрочное сглаживание. В результате нам будет
достаточно буферов умеренного размера. Очередь может образоваться в кратко-
срочной перспективе, но за долгий период времени буферы очистятся. Однако если
неравномерное поведение трафика само по себе неравномерно — то есть кластеры
кластеризуются, — тогда могут образовываться очереди большей длины, чем мож-
но ожидать от пуассоновского потока. В результате оказывается, что традицион-
ный анализ очередей, в основе которого лежит предположение о пуассоновском
потоке, не может точно предсказывать производительность системы в условиях
самоподобного трафика. Мы увидим, что тому есть подтверждения.
9.2. Самоподобный трафик данных
Описанный в разделе 9.1 тип самоподобия может быть назван точным самоподоби-
ем: заданный шаблон точно воспроизводится при разном разрешении. Это точное
самоподобие может быть построено для детерминированных временных после-
довательностей. Однако трафик данных лучше всего рассматривать как стохас-
тический процесс, поэтому мы можем говорить лишь о статистическом самопо-
добии2.
Здесь может быть полезна аналогия. Детерминированный периодический сиг-
нал характеризуется неизменностью относительно времени. Сигнал является по-
добным самому себе, отстоящему на целое число периодов. Например, для детер-
минированной периодической функции g(t) с периодом Т можно написать:
g(0 =g(t + аГ),
а = 0, ±1, ±2...
Для стационарного стохастического процесса, напротив, инвариантом относи-
тельно времени являются статистические характеристики процесса. Среднее зна-
чение не зависит от времени, а функция автокорреляции зависит только от разно-
сти времен.
Детерминированный самоподобный сигнал инвариантен относительно изме-
нений масштаба. Для стохастического процесса мы можем сказать, что статисти-
ческие характеристики процесса не изменяются при изменении шкалы времени.
Среднее поведение процесса на коротком промежутке времени не отличается от
Точнее, кластеризация происходит на временной шкале, определяемой средним интервалом между
наступлениями пуассоновских событий. Термин краткосрочный (short term) является относительным.
2 Исключение представляет собой непрерывный поток блоков данных фиксированного размера, на-
пример поток ячеек ATM, переносящих несжатое видеоизображение с постоянной скоростью передачи
ячеек. Наиболее распространенным является случай, в котором ячейки или пакеты передаются с неко-
ей средней скоростью, но существует некоторая неравномерность вокруг этого среднего значения.
264
Глава 9. Самоподобный трафик
поведения за долгий период времени. Подобное недетерминированное самопо-
добие часто встречается как в естественных, так и в искусственных явлениях.
Его можно наблюдать в природных ландшафтах, в распределениях землетрясений,
в океанских волнах, в турбулентном потоке, во флуктуациях фондовых рынков,
в повторяющихся ошибках и трафиках данных каналов связи.
На рис. 9.3, а показан пример самоподобного стохастического процесса. Обрати-
те внимание на то, что функция времени не точно повторяется при разном времен-
ном разрешении, но ее внешний вид при различных временных масштабах похож.
Сравните это с графиком на рис. 9.3, б, изображающим типичный стационарный
случайный процесс. В этом случае мы видим, что при большем увеличении функ-
ция изменяется, становясь более прерывистой и менее регулярной. При переходе
к более длительным интервалам времени сигнал, напротив, становится более ре-
гулярным и содержит меньше флуктуаций.
Рис. 9.3. Сравнение самоподобного и несамоподобного стохастических процессов [239]
В данном разделе будут приведены некоторые определения самоподобных сто-
хастических процессов. В следующем разделе мы прокомментируем примеры,
встречающиеся в литературе, и обсудим причины этих явлений.
Самоподобные стохастические процессы определяются в литературе по-разно-
му. В данном разделе рассматриваются некоторые из наиболее важных подходов.
Возможно, проще всего понять эту концепцию, рассмотрев непрерывные во вре-
мени стохастические процессы, что мы сначала и сделаем. Затем мы перейдем к
9.2. Самоподобный трафик данных
265
дискретным но времени стохастическим процессам, более подходящим к нашей
теме обсуждения1.
Определение непрерывного во времени процесса
Общее определение самоподобного стохастического процесса (например, см. [239])
основано на прямом масштабировании непрерывной переменной времени. Стоха-
стический процесс х(/) является статистически самоподобным с параметром Н
(0,5<Н<1), если для любого вещественного значения а > 0 процесс a "x(af) об-
ладает теми же статистическими характеристиками, что и сам процесс х(£) Это
утверждение можно выразить тремя следующими условиями:
4- среднее:
Е[х(0] = ^^;
а
4- дисперсия:
.. I / ,1 Varfx(ot)]
V ar [х(01 =-;
4- автокорреляция:
а
Параметр Н, называемый параметром Херста (Hurst parameter), или парамет-
ром самоподобия (self-similarity parameter), представляет собой ключевую меру
самоподобия. Точнее, Н представляет собой меру устойчивости статистического
явления, или меру длительности долгосрочной зависимости стохастического про-
цесса. Значение Н= 0,5 указывает на отсутствие долгосрочной зависимости. Чем
ближе значение Н к 1, тем выше степень устойчивости долгосрочной зависимости2 *.
Процесс броуновского движения
Процессом, удовлетворяющим нашему определению самоподобия, является про-
цесс броуновского движения (определенный в разделе 7.3). Процесс броуновско-
го движения B(t) является самоподобным с параметром Н= 1/2. Рассмотрим все
три ранее перечисленных условия самоподобия.
4- По определению, Е[В(/)| = 0. Поэтому E[B(at)J = 0, таким образом, E[B(t) j =
= Е[В(яГ)]/а0-5, что удовлетворяет первому условию.
4- В разделе 7.3 мы видели, что Var[B(t)] = t. Следовательно, Var[B(at) | = at =
= aVar[B(t)], что удовлетворяет второму условию.
1 Непрерывный во времени стохастический процесс — это такой стохастический процесс, в котором
время t изменяется непрерывно, тогда как дискретный во времени стохастический процесс — это сто-
хастический процесс, в котором переменная времени t принимает только дискретные значения. Эта
тема обсуждалась в разделе 7.3.
2 Эти понятия станут яснее из последующего обсуждения. Более подробно параметр Н обсуждается в
заключении к этой главе.
266 Глава 9. Самоподобный трафик
♦ Опять же, в разделе 7.3 было показано, что RB(t, s') = min[t, 5]. Следователь-
но, Rn(at, as) = min[at, as] = a min[t, .s] = a RB(t, s), что удовлетворяет третье-
му условию.
Несложно привести аргумент в пользу самоподобия процесса броуновского
движения. Вспомним, что для любых значений t > 0 и б > 0 приращение процесса
броуновского движения B(t + 5) - B(t) распределено нормально со средним зна-
чением 0 и дисперсией 5. Таким образом,
1 А
Pr[B(t + б) - B(t) <х] = -/= Г eyi/№dy. (9.1)
V27t5 Д
По мере продвижения по оси t функция увеличивается и уменьшается на слу-
чайную величину за любой интервал времени. Эта величина определяется тем, в
каком масштабе вы рассматриваете функцию. Интеграл в уравнении (9.1) указы-
вает на то, что при рассмотрении все меньших интервалов времени изменения
функции становятся также все меньше. При рассмотрении меньших интерва-
лов времени обнаруживаются шаблоны, сходные с шаблонами, соответствующи-
ми поведению функции на больших интервалах, рассматриваемых с меньшим раз-
решением. Другими словами, процесс B{t) является самоподобным.
Процесс дробного броуновского движения
Процесс дробного броуновского движения (Fractional Brownain Motion, FBM)
представляет собой важный вариант процесса броуновского движения. Детальное
рассмотрение этого процесса выходит за рамки данного обсуждения, однако краткое
введение будет полезным, так как процесс FBM часто используется при анализе са-
моподобного трафика данных. По существу, процесс FBM получается из процесса
броуновского движения при ослаблении требования к независимости приращений.
Существует несколько равноценных определений процесса FBM. Здесь мы будем
следовать определению из [78]. Процесс дробного броуновского движения Bn(t)
с параметром Херста 77(0 < Н < 1) может быть определен следующим способом:
4- Функция Bn(t) непрерывна.
♦ Вн(0) = 0.
♦ Для любых t> 0 и б > 0 приращение ВДГ + б) - Вн(1) подчиняется нормально- >
му распределению со средним значением 0 и дисперсией б2н. Таким образом, -
/ e^^dy. (9.2) ' J
Обратите внимание на то, что формула (9.2) при Н = 0,5 приводится к форму-
ле (9.1). Кроме того, для Н= 0,5 можно показать, что процесс FBM обладает неза-
Pr[B„(t + б) - B^t)<x\ = -=L=
л/2лб2"
висимыми приращениями и поэтому действительно представляет собой процесс ;
броуновского движения. 2
Теперь мы покажем, что процесс FBM удовлетворяет трем условиям самопо- ЛЯ
добного процесса, перечисленным в начале этого подраздела.
Во-первых, если в формуле (9.2) мы будем использовать интервал, начинающий- f
ся в Дя(0), и вспомним, что Ви(0) = 0, то увидим, что B^t) подчиняется нормальному /
9.2. Самоподобный трафик данных
267
распределению со средним значением 0 и дисперсией Г2". Таким образом, мы полу-
чим Е[В//(£)] = °- Следовательно, Е[Вн(аг)] = 0, и поэтому Е[Вл(О] = E[Bn{at)]/aH,
что удовлетворяет первому условию.
Во-вторых, Var[BH(i) | = I2". Поэтому Var[B/z(at)] = (at)2H = (а)2Н Var[BH(t)], что
удовлетворяет второму условию.
Прежде чем перейти к рассмотрению третьего условия, нам нужно получить
автокорреляцию Вц{1), выраженную как RBii{t, s) = Е[Вн(О^н(5)]- Эту величину
можно получить следующим образом. Сначала, отметим, что
Е[(В,Х0 - В//0))2] = Е[В2и(О + Яф(л) - 2Вя(0Ви(х)].
Преобразуя это равенство, получим
Е[Вя(г)Вн(з)] = | (E[B2zz(t)] + Е[В2и(х)] - Е[(В,Х0 - Bh(s))2]) =
= | (Var[Bzz(t)] + Var[Bzz(x)] - Var[Bzz(t) - Bzz(s)]) =
Опять же, при Н= 0,5 эта формула приводится к автокорреляции процесса бро-
уновского движения.
Итак, третье условие удовлетворено, поскольку
RBn {at, as) = | ((at)211 + {as)2" - \at - atf") =
a2"
= ~{^H + s2"-\t-^2") =
= a2"RBu{t, s).
Наконец, отметим, что правая часть равенства (9.2) не зависит от t (таким об-
разом, BH{t) обладает стационарными приращениями) и что
VarlB/Xt) - B^s)]) = E[{B„{t) - Bh{s))2]) = |t - s|2"
Замечательное отличие процесса броуновского движения от процесса дробного
броуновского движения заключается в том, что первый обладает независимыми и
некоррелированными интервалами, тогда как последний обладает бесконечно дли-
тельными корреляциями. Это легко продемонстрировать, если рассмотреть корре-
ляцию между приращениями в прошлом и приращениями в будущем. Рассмотрим
корреляцию между приращением в интервале от —Г до 0 и в интервале от 0 до V.
Е[(Вн(0) - B,X-0)(W) - В//(0))] = E[-BH(-t)B«(0] =
= -|((-t)2« + ^-|-t-^) =
. ^{2t)2"-t2".
268
Глава 9. Самоподобный трафик
Обратите внимание на то, что при Н = 0,5 корреляция приращений в прошлом
и в будущем исчезает, как и требуется для процесса броуновского движения, об-
ладающего независимыми приращениями. Однако при Н > 0,5 у процесса появля-
ется замечательное свойство инерционности (persistence). В данном случае, если
где-то в прошлом у нас было положительное приращение, тогда в среднем у нас
будет положительное приращение и в будущем. Таким образом, тенденция к росту
(или к снижению) в прошлом предполагает такую же тенденцию и в будущем.
Эта корреляция применима к сколь угодно большим значениям t и становится
сильнее с увеличением значения Н.
Это инерционное поведение находится в конфликте с тем, что обычно понима-
ется под стохастическим явлением. Некоторые процессы, такие как броуновское
движение, обладают независимыми приращениями. Для многих других процессов
можно допустить, что события являются коррелированными, если их разделяет
небольшой интервал времени At, однако они определенно становятся некоррели-
рованными при At —> оо.
Определение дискретного во времени процесса
Теперь рассмотрим случай стохастического процесса, определенного в дискрет-
ных точках времени, так что стохастический процесс X(t) определяется как
{х„Г=0,1,2,...}.
Для стационарных временных серий х мы определим m-агрегированные вре-
менные серии x(m) = {x/m), k = 0,1, 2,...}, суммируя исходные временные серии по
неперекрывающимся соседним блокам размера т. Это может быть выражено так:
1 ~!Г!.
х/га) = — У, х,-
Например, х(3> определяется следующим образом:
Г31 _ Х3*-2 + Х3£-1 + X3t
‘ ” 3
Агрегированные временные серии можно рассматривать как метод сжатия вре-
менной шкалы. Мы можем считать х(1) максимальным увеличением или высочай-
шим возможным разрешением для этой временной серии. Процесс х(3) представ-
ляет собой тот же самый процесс, уменьшенный в три раза. Усредняя по каждому
множеству из трех точек, мы теряем мелкие детали, доступные при максимальном
увеличении. Если статистические характеристики процесса (среднее значение,
дисперсия, корреляция и т. д.) сохраняются при сжатии, тогда мы имеем дело с
самоподобным процессом.
Мы также можем рассматривать каждую точку в серии х(т) как среднее по вре-
мени процесса х. Для эргодического процесса (см. раздел 7.3) среднее по времени
должно быть равно среднему по ансамблю, а дисперсия среднего по времени отно-
сительно быстро должна стремиться к нулю при росте т. Этого не происходит в
самоподобном процессе. Дисперсия может стремиться к нулю, но в этом случае
она будет стремиться к нулю существенно медленнее, чем для стационарного эр-
годического процесса. Выразим последнее более точно.
9.2. Самоподобный трафик данных
269
Процесс х называется в точности самоподобным (exactly self-similar) с парамет-
ром (3 (0 < Р < 1), если для всех т = 1,2,... мы имеем:
♦ дисперсия:
Var(x..>)=y^;
т
4- автокорреляция:
/^(fc) = R*(k).
Можно показать, что параметр Р связан с определенным ранее параметром Хер-
ста как Н= 1 - (Р/2). Для стационарного эргодического процесса Р = 1, и средняя
дисперсия времени стремится к нулю со скоростью 1/т. Для самоподобного про-
цесса средняя дисперсия времени затухает медленнее.
Ослабленное условие выглядит так: процесс х называется асимптотически са-
моподобным (asymptotically self-similar) для всех достаточно больших k, если вы-
полняются условия:
♦ дисперсия:
, Var(x)
Var(x<m>)-----в—;
♦ автокорреляция:
Rx(m)(k) Rx(k) при т —> °°.
Таким образом, при этом определении самоподобия автокорреляция1 агреги-
рованного процесса имеет тот же вид, что и оригинальный процесс. Из этого мож-
но предположить, что степень изменчивости, или неравномерности, будет той же
самой при различных временных шкалах.
Интересное свойство предыдущего определения заключается в том, что авто-
корреляция агрегированного самоподобного процесса не стремится к нулю при
т —> оо Это отличает его от стохастического процесса, используемого, как прави-
ло, для моделирования передачи пакетов данных и удовлетворяющего следующе-
му соотношению:
Д<га)(т) 0 при т —°°.
Функция автокорреляции Д(т) равна нулю в случае белого шума (то есть чисто
стохастического процесса с однородным спектром мощности). Рисунок 9.3 явля-
ется полезной иллюстрацией к данной теме. На рис. 9.3, б при увеличении уровня
агрегации (т растет) процесс приближается к белому шуму. На рис. 9.3, а, напро-
тив, все графики обладают сходной структурой, явно отличной от белого шума.
Другая интересная особенность предыдущих определений заключается в том,
что дисперсия х(т) уменьшается медленнее, чем 1/т при т —> °°, то есть она умень-
шается пропорционально 1/етг(|. Для стохастических процессов, как правило, ис-
пользуемых при моделировании систем передачи пакетов данных, дисперсия
уменьшается пропорционально 1/т. Как было показано в главе 7, дисперсия вы-
борочного среднего равна дисперсии, лежащей в основании случайной перемен-
'. Определение автокорреляции см. в разделе 7.3.
270
Глава 9. Самоподобный трафик
ной, деленной на тп. Однако благодаря инерционности статистических характери-
стик во времени для самоподобного процесса агрегация с коэффициентом тп — это
не то же самое, что вычисление выборочного среднего при размере выборки т.
Теперь мы перейдем к рассмотрению двух понятий, относящихся к самоподобию;
долгосрочной зависимости и медленно затухающих распределений (распределе-
ний с «тяжелыми хвостами»). В действительности эти два понятия никак не свя-
заны ни друг с другом, ни с самоподобием. Однако все три понятия можно найти в
литературе по самоподобному трафику, что может запутать случайного читателя.
Долгосрочная зависимость
Определение долгосрочной зависимости основывается на поведении функции авто-
ковариации1 С(т) стационарного процесса при увеличении т. Для многих процессов
с ростом т автоковариация быстро уменьшается. Например, для пуассоновского
инкрементного процесса с приращением L и средним значением Л (определения
см. в разделе 7.3) автоковариация для значений т > L равна (см. формулу (7.5))
С(т) = К(т)-Л2 = Л2-Х2 = О.
В общем, краткосрочно зависимый (short-rang dependent) процесс удовлетво-
ряет условию, заключающемуся в том, что его автоковариация убывает по мень-
шей мере так же быстро, как экспонента:
С(т) - при |/?| —> оо^ 0 *•* 67 1.
Здесь символ - означает, что обе части формулы асимптотически пропорцио- i
нальны друг другу. 3
В моделях трафика данных, рассматриваемых в литературе, как правило, ис- Ц
пользуются только краткосрочно зависимые процессы. Глядя на следующее соот- 3
ношение, можно заметить, что для краткосрочно зависимого процесса сумма Z«C(fe) 1
является конечной; 1
Xх ~Т^х 1
k=G
У долгосрочно зависимого (long-rang dependent) процесса, напротив, автокова-
риация убывает гиперболически: >
C(k) ~ |/ф₽ при |/г| —> оо, 0 < Р < 1. |
Здесь р — тот же параметр, который был определен ранее и который связан с 11
параметром Херста как 11 = 1 - (Р/2). В этом случае S*C(fc) = о°. g
Обратите внимание на то, что условие 0 < Р < 1 в формуле (9.3) эквивалентно |
условию 0,5 < Н < 1. Ранее мы отмечали, что процесс может быть самоподобным
1 Некоторые свойства как самоподобного, так и долгосрочно зависимого процесса могут быть выраже-
ны при помощи функции автокорреляции 7?(т), тогда как другие свойства лучше всего описываются
функцией автоковариации С(т) — К(т) — р2, где р = Е[х(/)]. К сожалению, в литературе по самоподоб-
ному трафику термин автокорреляция (autocorrelation) иногда используется для обозначения авто- J
ковариации (autocovariance), а иногда для обозначения нормализованной автоковариации (normalized
autocovariance), называемой (см. формулу (7.4)) коэффициентом корреляции (correlation coefficient), Я
Читателю следует быть осторожным в этих случаях. f
9.2. Самоподобный трафик данных
271
при значении Н= 0,5. Для долгосрочной зависимости мы должны иметь Н > 0,5,
так что процесс броуновского движения является самоподобным, но не долгосроч-
но зависимым. Существуют также стохастические процессы, являющиеся долго-
срочно зависимыми, но не самоподобными. Однако в интересующих нас случаях
самоподобного трафика данных самоподобие подразумевает долгосрочную зависи-
мость, и наоборот [175]. Таким образом, эти два понятия часто взаимозаменяемы.
Долгосрочная зависимость интуитивно отражает явление инерционности в само-
подобных процессах, а именно существование кластеризации и непостоянство
характеристик во всех временных масштабах.
Спектральная плотность
Эквивалентная формулировка долгосрочной зависимости может быть выражена
в терминах частоты. В частности, плотность спектра мощности около начала ко-
ординат подчиняется закону мощности:
S(w) - гА? прик>->°°,0<у< 1.
I ® I
Как было показано в разделе 7.3, спектральная плотность дискретного во вре-
мени стохастического процесса определяется следующим образом:
5(®)=£W* 5(0)= X R(k).
Можно показать, что у = 1 — Р = 2Н - 1.
Краткосрочно зависимый процесс, напротив, характеризуется спектральной
плотностью, остающейся конечной при w —> °<>. Это происходит при у = 0, или, что
то же самое, при Н = 0,5. Применительно к функции автокорреляции 5(0) прини-
мает бесконечные значения, если функция R(k) не убывает достаточно быстро для
больших k.
Медленно затухающие распределения
Другой концепцией, связанной с самоподобием, являются медленно затухающие рас-
пределения, или распределения с «тяжелыми хвостами» (heavy-tailed distributions).
По существу, самоподобный стохастический процесс можно определить при помощи
таких распределений, причем подобный класс процессов подразумевает больше,
чем предыдущие формулировки. Одно из достоинств подхода медленно затухаю-
щих распределений заключается в том, что он позволяет получить управляемые
модели. В данном подразделе мы представим краткий обзор данной темы.
Медленно затухающие распределения могут использоваться для представле-
ния плотностей вероятностей, описывающих процессы передачи данных, такие как
интервалы между поступлениями пакетов и продолжительности пакетов. Говорят,
что распределение случайной переменной X медленно затухает, если
1 - F(x) = Рг[X> х| - при х—> °°, 0 < а.
В целом, случайная переменная с медленно затухающим распределением облада-
ет бесконечной дисперсией и, возможно, бесконечным средним значением. Случай-
272 Глава 9. Самоподобный трафик
ная переменная с медленно затухающим распределением может принимать очень
большие значения с вероятностью, которой нельзя пренебречь. Как правило, если
производится выборка такой случайной переменной, будет получено множество от-
носительно малых значений, хотя некоторые значения будут относительно велики
Самым простым медленно затухающим распределением является распределе-
ние Парето (Pareto) с параметрами k и a (k, а < 0) и следующими функциями плот-
ности, распределения вероятностей и среднего значения:
/(х) = Е(х) = 0 (x<k);
Рис. 9.4. Функции Парето и экспоненциальной плотности вероятностей
Параметр k определяет минимальное значение, которое может принимать слу-
чайная переменная. Параметр а определяет среднее значение и дисперсию случай-
ной переменной. Если а < 2, тогда распределение обладает бесконечной дисперси-
ей, а если ос < 1, тогда распределение обладает бесконечными средним значением
и дисперсией. На рис. 9.4 сравниваются функции распределения Парето и экспо-
ненциальной плотности вероятностей, представленные в полулогарифмическом
9.3. Примеры самоподобного трафика
273
масштабе. Обратите внимание на то, что в подобном масштабе функция экспо-
ненциальной плотности вероятностей представляет собой прямую линию. Хвост
распределения Парето убывает значительно медленнее, чем у экспоненциального
распределения. Отсюда и термин тяжелый хвост (heavy tail).
Распределение Парето можно наблюдать в широком спектре социальных и
физических явлений, а также в области передачи данных. Краткое обсуждение
этой темы можно найти в [176]. В [175] отмечается, что наличие тяжелого хвоста
у определенных сетевых переменных (например, размеров файлов и длительнос-
ти соединений) является основной причиной долгосрочной зависимости и само-
подобия сетевого трафика.
9.3. Примеры самоподобного трафика
С 1993 г. множество исследований, о которых сообщается в литературе, показало,
что тип трафика данных в широком спектре сетевых ситуаций реального мира хо-
рошо моделируется самоподобными процессами. Данный раздел содержит отрыв-
ки из этих статей, а также проливает свет на причины самоподобия.
Трафик сетей Ethernet
Множество плодотворных идей, касающихся темы самоподобного трафика, со-
держится в статье [143], впоследствии исправленной и дополненной [144]. Хотя
в некоторых предшествующих статьях описывалось поведение трафика данных,
хорошо описываемого самоподобными процессами, однако в них не вводилось
ключевое в данном случае понятие самоподобия1. Эта статья разрушила иллюзию
о том, что анализ очередей с использованием предположения о пуассоновском
потоке представляет собой адекватную модель сетевого трафика. Опираясь на
большое количество исходных данных и тщательный статистический анализ, ста-
тья утверждает, что для трафика в локальных сетях Ethernet требуется новый ме-
тод моделирования и анализа. Эта статья вызвала поток исследовательских работ
по данному вопросу. Месяц за месяцем появлялись новые статьи, подтверждав-
шие наличие самоподобия у трафиков других типов.
В оригинальной статье сообщается о результатах детальных измерений трафи-
ка в сетях Ethernet, выполненных между 1989 и 1992 гг. с высокой точностью
(точность измерения времени составляла 20 мкс). Данные состоят из четырех
множеств данных измерений Ethernet-трафика, произведенных на протяжении
от 20 до 40 последовательных часов и состоящих в общей сложности из более
чем 100 миллионов пакетов. Данные были собраны на различных локальных сетях
Ethernet лабораторией Bellcore.
На рис. 9.5, а показана зависимость числа передаваемых пакетов от времени.
Эти данные входят в блок измерений, произведенных в 1989 г., и состоящий из
27 часов непрерывных наблюдений за Ethernet-трафиком. Верхний график показы-
вает полный 27-часовой интервал, состоящий из 1000 100-секундных интервалов.
1 Пионер в области фракталов Мандельброт (Mandelbrot) очень давно показал самоподобную приро-
ду ошибок в линиях передачи данных [150], но никто не подумал о том, чтобы применить этот тип
анализа к самому трафику данных.
274
Глава 9. Самоподобный трафик
Каждый следующий график получен из предыдущего путем увеличения разреше-
ния шкалы времени в 10 раз и отображения случайным образом выбранного по-
дынтервала (он показан более темным цветом1). Таким образом, второй график
охватывает период около 2,7 ч, третий — 0,27 ч и т. д. Если рассматривать эти
графики снизу вверх, то точка в каждом следующем графике получается путем
усреднения 10 соответствующих точек из более низкого графика.
Пакетов в единицу
времени
40 000
20 000
Пакетов в единицу
времени
60 000
Пакетов в единицу
времени
60 000
20 000
40 000
0 200 400 600 800 1000
0 200 400 600 800 1000 0 200 400 600 800 1000
Единица времени — 100 с
Пакетов в единицу
времени
6000
4000
2000
0 200 400 600 800 1000
Единица времени — 100 с
Пакетов в единицу
времени
6000
4000
2000
0 200 400 600 800 1000
Единица времени — 100 с
Пакетов в единицу
времени
6000
4000
2000
0 200 400 600 800 1000
Единица времени — 100 с
Единица времени — 100 с
Единица времени — 100 с
Пакетов в единицу
времени
Пвкетов в единицу
времени
Пакетов в единицу
времени
0 200 400 600 800 1000
Единица времени — 100 с
800
200
0 200 400 600 800 1000 0 200 400 600 800 1000
Единица времени — 100 с Единица времени — 100 с
Пакетов в единицу
времени
100
80
60
40
20
Пакетов в единицу
времени
100
80
60
40
20
Пакетов в единицу
времени
100
80
60
40
20
0 200 400 600 800 1000
Единица времени — 100 с
0 200 400 600 800 1000
Единица времени —100 с
0 200 400 600 800 1000
Единица времени — 100 с
Пакетов в единицу
времени
Пакетов в единицу Пакетов в единицу
времени времени
0 200 400 600 800 1000
0 200 400 600 800 1000
0 200 400 600 800 1000
Единица времени — 100 с
Единица времени — 100 с
Единица времени — 100 с
а
б
в
Рис. 9.5. Сравнение фактического и полученного путем
моделирования Ethernet-трафиков [238]
1 Видимо, утерянным при печати. — Примеч. псрев.
9.3. Примеры самоподобного трафика
275
В связи с этими данными можно сделать несколько интересных наблюдений.
За исключением, возможно, верхнего графика, все графики похожи друг на друга
в смысле распределений1. То есть во всех графиках наблюдается определенная не-
। равномерность. Таким образом, Ethernet-трафик выглядит почти одинаково как
на больших интервалах времени (часы, сутки), так и на малых интервалах (секун-
ды, миллисекунды). Более того, обратите внимание на то, что не существует есте-
ственной длительности всплесков трафика. В каждом масштабе времени всплески
состоят из субпериодов активности, разделенных менее активными субпериодами.
Такое самоподобное поведение трафика в корне отличается от того, что можно
наблюдать в линиях передачи телефонного трафика, и от стохастических моделей,
традиционно используемых при анализе и проектировании компьютерных сетей.
Чтобы заметить это отличие, рассмотрим рис. 9.5, б. Этот набор графиков был
сформирован тем же образом, что и Ethernet-графики, но для него использовались
данные, полученные при помощи пуассоновской модели и сопоставимой с реаль-
ной системой передачи данных по среднему размеру и скорости появления паке-
тов. При высоком разрешении (единица времени = 0,1 с), как и следовало ожидать,
неравномерность трафика велика. По мере группирования данных с усреднением
скорости пакетов по большим интервалам времени трафик заметно сглаживается.
Такое поведение является нормальным для стационарного эргодического стохас-
тического процесса, определенного с помощью пуассоновской модели. Каждый
уровень агрегации представляет собой последовательность неперекрывающихся
выборок размером 10. Таким образом, мы можем ожидать уменьшение дисперсии
в 10 раз на каждом уровне агрегации. Разница между соответствующими графика-
ми на рис. 9.5, а и б просто поражает.
Опираясь на множество статистических тестов, авторы приходят к выводу, что
Ethernet-трафик является самоподобным с параметром Херста Н = 0,9. Графики
на рис. 9.5, в визуально подтверждают это предположение. Эти графики построены
при помощи самоподобной модели трафика с 11 = 0,9. Как можно видеть, характер
трафика на этих графиках довольно близок к данным, полученным в реальных
условиях.
Разумеется, интересна причина подобных результатов. Обоснование традици-
онной модели очередей, используемой при анализе трафика, заключалось в том,
что при объединении данных от нескольких источников (как это происходит в
локальных сетях при мультиплексировании) объединенные статистики различных
источников обладают характеристиками, пригодными для анализа в соответствии
с моделью очередей (что обсуждалось в главе 8). Авторы доклада об Ethernet-
сетях показали, что существует метод моделирования Ethernet-трафика, кото-
рый, во-первых, позволяет получить результаты, сходные с данными реального
Ethernet-трафика, во-вторых, для которого требуется определить совсем немного
параметров, и, в-третьих, правдоподобный физически.
Упоминаемый в [238] метод заключается в моделировании Ethernet-трафика
путем суперпозиции нескольких парето-подобных источников ON/OFF. Каждый
такой источник находится в одном из двух состояний: ON, в котором он активно
передает пакеты, и OFF, в течение которого он бездействует. Если предположить,
Отличия первого графика, возможно, связаны с эффектом времени суток.
276
Глава 9. Самоподобный трафик
что периоды активности являются независимыми идентично распределенными
случайными переменными и что каждый источник управляется одними и теми же
распределениями, тогда можно (хотя и непросто) определить поведение этой су-
перпозиции, или мультиплексирования, нескольких таких источников. В самом
деле, такой подход пригоден для формирования трафика, соответствующего тра-
диционным моделям трафика. Ключевой элемент заключается в использовании
распределения с конечной дисперсией, например экспоненциального или геомет-
рического, для описания времени периодов ON и OFF. Как было показано, такие
модели не отражают реального Ethernet-трафика.
Исследователи из Bellcore промоделировали периоды ON/OFF с помощью
распределений с бесконечной дисперсией, в частности, используя распределение
Парето с параметром а от 1 до 2. Как уже упоминалось, когда параметр а находит-
ся в этом диапазоне, случайная переменная обладает конечным средним значени-
ем и бесконечной дисперсией. В [238] показано, что суперпозиция нескольких ис-
точников ON/OFF, подчиняющихся распределению Парето, позволяет получить
самоподобный трафик с параметром Херста Н = (3 - а)/2. Обратите внимание
на то, что для 1 < а < 2 мы получим 0,5 < Н < 1, что представляет собой диапазон
самоподобия. Для изучаемого Ethemet-трафика исследователи обнаружили, что
параметр а индивидуальных источников равен 1,2, что соответствует самоподоб-
ному трафику с Н= 0,9.
В [238] показано, что медленно затухающее распределение, такое как рас-
пределение Парето, отражается на фактическом поведении индивидуального
Ethemet-источника. Интуитивно понятно, что высокая или бесконечная диспер-
сия медленно затухающего распределения проявляет крайнюю изменчивость и,
следовательно, непостоянство во всех масштабах времени. Приложение или рабо-
чая станция, как правило, формирует трафик всплесками с периодами бездействия
между ними. В распределении с высокой дисперсией диапазон временных интер-
валов может быть очень широким с очень большим количеством очень коротких
всплесков, большим количеством длинных всплесков и небольшим количеством
очень долгих всплесков. Мандельброт, математик, придумавший термин фрактал
(fractal), описывал это свойство как эффект Ноя (Noah effect), ссылаясь на отры-
вок из Библии (Книга Бытия 7:11-12): «В шестисотый год жизни Ноя небеса раз-
верзлись, и дождь был на земле сорок дней и сорок ночей».
Трафик Всемирной паутины
В [63] сообщается об исследовании трафика Всемирной паутины, включающем
более полумиллиона запросов к веб-документам. Данные были собраны на 37 веб-
браузерах, работавших на рабочих станциях факультета кибернетики Бостонско-
го университета. Используемая методология была сходной с той, что применялась
в обсуждавшемся ранее исследовании сети Ethernet. Исследование показало, что
трафик, формируемый веб-браузерами, является самоподобным. Сходные резуль-
таты были опубликованы в [10] и [11].
Исследователи моделировали каждый веб-браузер как источник ON/OFF
и обнаружили, что данные очень хорошо соответствуют распределению Парето.
Для различных наборов измерений исследователи нашли соответствующие рае
9.3. Примеры самоподобного трафика
277
пределения Парето с параметром а в диапазоне от 1,16 до 1,5. Исследователи по-
пытались выполнить дополнительные тесты в попытке объяснить самоподобное
поведение. Они рассматривали объем веб-данных, передаваемых серверами брау-
зерам, и обнаружили, что хвост распределения соответствовал распределению типа
Парето. Авторы выдвинули гипотезу о том, что веб-трафик отражает случайный
выбор файлов для передачи. В частности, если пользователи выбирали файлы, сле-
дуя по ссылкам и не обращая внимания на размер загружаемых файлов, то объем
передаваемых данных представлял, по сути, случайные выборки из распределения
веб-файлов. Продолжая анализ, исследователи обнаружили, что файлы, доступ-
ные в Интернете, обладают медленно затухающими распределениями. Это похо-
же на правду, так как хотя множество файлов в Интернете имеет небольшие раз-
меры, там также много довольно больших и очень больших файлов, например
мультимедийных, которые становятся все более популярными в Паутине.
Трафик SS7
Исследования, о которых сообщалось в [73], были посвящены трафику управляю-
щих сигналов, формируемых в цифровых телекоммуникационных сетях. В таких
сетях используется протокол SS7 (Signaling System Number 7 — сигнальная систе-
ма 7), характерный также для сетей ISDN и других цифровых сетей. Исследова-
ния охватывали около 170 миллионов сигнальных сообщений, собранных на мно-
жестве различных рабочих сетей, управляемых протоколом SS7. Протокол SS7
представляет собой сигнальный протокол общего канала, используемый внутрен-
ними коммутирующими узлами телекоммуникационной сети для обмена управ-
ляющими сообщениями. Управляющие функции включают выбор маршрутов
соединений, установку и разрыв соединений, а также передачу извещений о состоя-
нии трафика и об ошибках.
Исследования отчетливо показали, что традиционные модели, основанные на
пуассоновском распределении, не соответствовали поведению сетей с протоколом
SS7. Как и в двух описанных ранее исследованиях, в этой научной работе обнару-
жилось, что самоподобные модели трафика обеспечивают лучшее соответствие.
Более того, благодаря доступности управляющих сигналов авторы также могли
изучить шаблон трафика фактических запросов и, в частности, исследовать дли-
тельность соединений. Как выяснилось, длительность соединений лучше всего
описывается медленно затухающими распределениями.
Трафики TCP, FTP и TELNET
В [95] сообщается об исследовании широкого спектра TCP-трафика, а также об
изучении FTP- и TELNET-трафика, передаваемого по TCP-соединениям. Были
сделаны следующие общие выводы:
♦ В используемых обычно пуассоновских моделях существенно недооцени-
вается неравномерность TCP-трафика в широком диапазоне временных шкал.
♦ Для интерактивного TELNET-трафика поступления соединений хорошо
моделируются пуассоновским распределением. Однако предположение о
278
Глава 9. Самоподобный трафик
пуассоновском распределении поступления пакетов, а именно об экспо-
ненциальном распределении интервалов времени между поступлениями
пакетов, существенно недооценивает неравномерность трафика.
4- Для групповой пересылки данных, осуществляемой протоколом FTP, струк-
тура трафика, опять же, заметно отличается от пуассоновского. Как и с
TELNET-данными, поступления FTP-сеансов хорошо соответствуют пуас-
соновской модели, но скорость поступления данных по FTP-соединениям
оказывается существенно более неравномерной. Кроме того, распределение
количества байтов в каждом всплеске является медленно затухающим.
В другом исследовании [35] сообщается об использовании UDP-пакетов для
измерения задержки доставки пакетов в Интернете. Результат этого исследования
показывает, что задержки доставки пакетов являются долгосрочно зависимыми.
VBR-видео
Ряд исследований показали, что цифровой видеотрафик того типа, который пере-
дается по сетям ATM и Интернету, является самоподобным. Например, в [90]
сообщается об эксперименте, произведенном с двумя часами видеоинформации
с использованием фильма «Звездные войны» в качестве примера. Фильм был за-
кодирован при помощи стандарта JPEG (см. часть VII этой книги). В результате
был получен поток данных, состоящий из кадров переменной длины, в каждом из
которых содержится один видеокадр. Переменная длина кадров объясняется при-
родой алгоритма сжатия. Именно это непостоянство длины кадра является осно-
вой стохастического процесса.
Результат анализа заключается в том, что видеопередача проявляет самоподоб-
ный характер и что длина кадра соответствует распределению Парето, по крайней
мере, хвосту этого распределения. Авторы показывают, как высокая степень измен-
чивости связана с изображением в кадре. В фильме содержатся сцены, в которых
мало движения, сцены с небольшим количеством движения и сцены, в которых
изображение меняется очень быстро. Все это связано с медленно затухающим рас-
пределением кодированного видеосигнала.
В более широком исследовании [25] рассматриваются 20 различных последо-
вательностей VBR (Variable Bit Rate — переменная битовая скорость), формируе-
мых с помощью различных алгоритмов и покрывающих широкий спектр сцен,
включая только что упоминавшийся фильм «Звездные войны». Исследования
показали, что долгосрочная зависимость является неотъемлемой чертой видео-
трафика VBR, независимо от используемых кодеков и записанных сцен. О сход-
ных результатах сообщается в [224].
Детерминированная передача данных
В [67] сообщается об интересном исследовании, в котором рассматривалась обоб-
щенная маркерная сеть, которую можно использовать в качестве модели локаль-
ных сетей с топологией token ring (маркерное кольцо) или token bus (маркерная
9.4. Влияние самоподобия на производительность
279
шина). Авторы применяли детерминированные источники данных и варьировали
нагрузку на сеть, изменяя нагрузку, генерируемую каждым источником. Замеча-
тельно, что для умеренно сложных сетей (из нескольких сотен элементов) трафик
оказывается самоподобным. Авторы приходят к выводу, что в сетях, в которых
протоколы подразумевают обмен несколькими сообщениями между отправителем
и получателем, эти протоколы заставляют динамику потока данных проявлять са-
моподобные свойства.
9.4. Влияние самоподобия
на производительность
Хорошо, что современные высокоскоростные компьютеры и сети позволяют быс-
тро собрать и проанализировать достаточное количество данных, чтобы устано-
вить наличие самоподобия в превалирующих сегодня потоках данных и оценить
его параметры. Плохо, что самоподобие оказывает существенное негативное вли-
яние на производительность.
Анализ сетей Ethernet/ISDN
Мы начнем с результатов исследований, опубликованных в [77] и [75] учеными
из лаборатории Bellcore. В этом исследовании изучались данные, передаваемые по
сетям Ethernet и обсуждавшиеся в разделе 9.2, а также данные, передаваемые в се-
тях ISDN и состоящие из более чем 100 000 пакетов. В обоих случаях был постро-
ен график зависимости фактической задержки доставки пакета от коэффициента
использования сети. Кроме того, параметры, необходимые для анализа очередей,
были получены путем наблюдения за потоком данных и применены в формулах.
На рис. 9.6 показаны полученные результаты. Согласованность между факти-
ческим и ожидаемым временем нахождения в очереди, полученным при помощи
общепринятой теории очередей, очень плохая. Расчеты, основывающиеся на тра-
диционном анализе очередей, показывают, что эффективная мощность сервера
составляет около 80 %, тогда как в реальной ситуации задержка начинает резко
возрастать уже при коэффициенте использования в диапазоне от 50 до 60 %.
Сходные результаты были получены для каждого набора данных для сетей ISDN
и Ethernet.
Ethernet-трафик
В статье, посвященной трафику в сетях Ethernet [144], а также в сходных статьях
исследователи обратились к проблеме влияния самоподобия на производитель-
ность. Одно важное открытие заключалось в том, что чем выше нагрузка на сеть
Ethernet, тем выше оцениваемый параметр Херста Н и тем выше степень самопо-
добия. Этот результат важен, так как вопрос производительности приобретает зна-
чимость как раз при высокой нагрузке.
280
Глава 9. Самоподобный трафик
Столь же важным результатом анализа трафика в сетях Ethernet является не-
адекватность традиционных моделей очередей при оценке производительности.
Например, обычное предположение, касающееся трафика данных, заключалось в
том, что мультиплексирование большого количества независимых потоков данных
дает в результате пуассоновский процесс. Как указывается в [237], именно это
предположение и соответствующие результаты анализа очередей привели к тому,
что производители ATM-коммутаторов оснащали коммутаторы первого поколе-
ния слишком малыми буферами (от 10 до 100 ячеек). Когда эти коммутаторы про-
шли полевые испытания и подверглись реальной нагрузке, то количество потерян-
ных ячеек оказалось значительно больше ожидаемого. В результате коммутаторы
пришлось переделывать. Результаты анализа в 1144] показывают, что если входной
трафик является самоподобным, тогда при любом мультиплексировании самоподоб-
ных потоков длительность задержек будет высокой и потребуются буферы увели-
ченного размера. Это касается коммутаторов, например для сетей ATM, ретранс-
ляции кадров и 100BASE-T, маршрутизаторов глобальных сетей, локальных сетей
с общим носителем, например Ethernet, и статистических мультиплексоров.
9.4. Влияние самоподобия на производительность
281
Модель запоминающего устройства
с самоподобными входными данными
В основе двух обсуждавшихся ранее исследовательских работ лежало сравнение
результатов, полученных в результате наблюдений за реальными системами, с ре-
зультатами, рассчитанными по моделям, основанным на предположении о пуас-
соновском распределении потока данных. В данном подразделе мы рассмотрим
статью [168], в которой автор пытается разработать достоверные аналитические
модели с самоподобным поведением. Эта статья послужила толчком к появлению
множества других работ в этой области.
В качестве «строительного материала» использовался процесс дробного броу-
новского движения (FBM), описанный в разделе 9.2. Затем была разработана мо-
дель нагрузки на основе процесса FBM и бесконечного буфера с постоянным вре-
менем обслуживания. Математические выкладки данной статьи выходят за рамки
нашего обсуждения, но один простой результат является характерным для иссле-
дования влияния самоподобия на производительность. При определенных допу-
щениях зависимость необходимого размера буфера q от среднего коэффициента
использования р подчиняется следующему закону:
р1/2(1-Л)
Здесь Н представляет собой параметр Херста. При Н= 0,5 эта формула упро-
щается до q - р/( 1 — р), что представляет собой классический результат системы
массового обслуживания с экспоненциально распределенными временными ин-
тервалами между поступлениями запросов и экспоненциально распределенной
длительностью обслуживания (М/М/1). Для системы с постоянным временем
обслуживания (M/D/1) классический результат выглядит следующим образом:
1-р 2(1-р)
На рис. 9.7 показаны результаты для Н- 0,9 и 0,75 в сравнении с моделями
М/М/1 и M/D/1 (сравните эти результаты с графиками времени задержки на
рис. 9.6). Как можно видеть, для больших значений Н (при долгосрочной зависи-
мости высокой степени) потребности в буфере начинают стремительно расти уже
при незначительном коэффициенте использования. Это оказывает очевидные
воздействия на проектирование буферов. Если нужно достичь высокого уровня
коэффициента использования, для самоподобного трафика потребуются буферы
гораздо большего размера, чем предсказывает классический анализ очередей.
Применимость самоподобных моделей трафика
В ряде исследований, часть из которых упоминается в данном разделе, отмеча-
ется самоподобный вид трафика многих сетевых конфигураций. Возникает воп-
рос, насколько превалируют данные виды графика и при каких условиях анализ
производительности существенно зависит от того, принимается ли самоподобие
282
Глава 9. Самоподобный трафик
во внимание. В настоящий момент это активная область исследований. В данной
главе содержатся ссылки на ряд статей, демонстрирующих важность самоподобия
при различных условиях. Однако читатель должен помнить, что это не означает,
что традиционный анализ очередей утратил свою значимость.
В качестве примера отсутствия единого мнения по вопросу применимости мо-
дели самоподобия можно привести совещание на состоявшейся в 1995 г. конфе-
ренции SIGMETRICS, на котором рассматривалась данная тема [76]. Результаты,
о которых было сообщено на этом заседании, ясно демонстрируют, что наличие
самоподобных эффектов является существенным в одних сетевых конфигураци-
ях и не оказывает значительного влияния на производительность в других конфи-
гурациях. Это различие во влиянии эффекта самоподобия описано в некоторых
статьях. Например, в [190] предоставляется свидетельство того, что при вычисле-
нии размеров буферов самоподобием VBR-трафика в сетях ATM можно пренеб-
речь. В [ 147] показано, что во многих случаях наличие самоподобия либо в интер-
валах между поступлениями данных, либо во времени обслуживания может иметь
драматическое воздействие на производительность очередей. В [102] говорится
9.5. Моделирование и оценка самоподобного трафика данных
283
о том, что учитывать или не учитывать параметры самоподобия трафика данных
иногда важно, а иногда нет.
В [190] приводится, возможно, особо значимая точка зрения. Авторы указыва-
ют на различие между самоподобием на прикладном и сетевом уровнях. Самопо-
добный трафик прикладного уровня формируется источником, проявляющим
свойство самоподобия в широком диапазоне временной шкалы без какого-либо
взаимодействия с сетью. Другими словами, самоподобие присуще источнику по-
тока данных. Хорошим примером такого трафика является видеотрафик VBR.
Самоподобный трафик сетевого уровня проявляет свойства самоподобия в ши-
роком диапазоне временной шкалы в результате многочисленных взаимодействий
с сетью (или объединенной сетью). Хорошим примером является ТСР-трафик.
Это отличие важно по нескольким причинам. Во-первых, как указывалось в пре-
дыдущем абзаце, в других статьях утверждается, что при расчетах размеров буфе-
ров самоподобием VBR-трафика часто можно пренебречь, а также приводятся
аналитические и экспериментальные аргументы в поддержку данного утвержде-
ния. Таким образом, с самоподобным трафиком прикладного уровня, по крайней
мере, в некоторых случаях, можно обращаться не так, как с самоподобным тра-
фиком сетевого уровня. Во-вторых, поскольку поведение самоподобного трафика
прикладного уровня остается в большой степени независимым от текущего состо-
яния сети, этим трафиком можно эффективно управлять в контексте управления
доступом и выделения ресурсов для гарантирования требуемого класса обслужи-
вания. С другой стороны, самоподобный трафик сетевого уровня изменяет свое
поведение в зависимости от нагрузки, схемы повторной передачи (различных вер-
сий протокола TCP), количества конкурирующих пользователей, размеров запра-
шиваемых (в Паутине или по FTP) файлов и т. д. Все это усложняет эффектив-
ный расчет трафика для таких источников. Насколько важно это различие между
сетевым и прикладным уровнями на практике, является предметом продолжаю-
щихся исследований.
9.5. Моделирование и оценка
самоподобного трафика данных
Разработано несколько методов определения, является ли данная временная се-
рия данных самоподобной, и если да, то чему равен в этом случае параметр
самоподобия Н. В этом разделе обсуждаются некоторые из наиболее распростра-
ненных методов.
График зависимости дисперсии от времени
Вспомним, что для агрегированных временных серий х(га) самоподобного процес-
са дисперсия при больших значениях т подчиняется следующей формуле:
ПТ
284
Глава 9. Самоподобный трафик
Здесь параметр самоподобия Н= 1 - (₽/2). Если прологарифмировать эту фор-
мулу, то мы получим:
Iog[Var(x<m))] - log[Var(x)] - р log(m).
Поскольку log[Var(x)] является константой, не зависящей от т, то график за-
висимости Var(x<''l)) от т в логарифмическом масштабе будет представлять собой
прямую линию с наклоном, равным ~р. График легко построить1 по набору данных
х(Г), если сгенерировать агрегированный процесс на разных уровнях агрегации т
азатем вычислить дисперсию. Многие исследователи (например, [63], [144], [1081)
выполнили это и обнаружили, что экспериментальные результаты действительно
ложатся на прямую линию с отрицательным наклоном. После этого уже несложно
определить значение параметра Н. Тангенс угла наклона от -1 до 0 предполагает
наличие самоподобия.
График R/S
Для стохастического процесса х(Г), определенного в дискретные моменты време-
ни {х,, t = 0, 1,2,...}, диапазон x(t) в измененном масштабе шкалы за интервал вре-
мени N определяется как отношение R/S:
R
S
Л=1
V N л=1
Здесь M(N) представляет собой выборочное среднее за период времени N:
1 N
YV 7=1
В числителе этой дроби находится величина интервала процесса, а в знамена-
теле — выборочное среднеквадратичное отклонение (см. раздел 9.6). Для самопо-
добного процесса это отношение при больших значениях N обладает следующей
характеристикой:
R/S - (N/2)“ при Н > 0,5.
Если прологарифмировать обе части этого выражения, мы получим:
log[/?/5] - Hlog(A0 - Hlog(2).
Если построить график зависимости log[R/S] от N в логарифмическом масш-
табе, должна получиться прямая линия с наклоном, равным Н. Этот результат был
подтвержден рядом экспериментов.
’ Конечно, если мы строим график для фактических данных, нам придется использовать выборочную
дисперсию вместо самой дисперсии.
9.5. Моделирование и оценка самоподобного трафика данных
285
Оценочная формула Уиттла
Графики зависимости дисперсии от времени и R/S от Л7представляют собой эври-
стические, или визуальные, методы, и именно так к ним и следует относиться. То
есть их следует применять не для точной оценки параметра Н, а для получения
грубой оценки того, обладает ли этот набор данных самоподобными свойствами
(Н > 0,5) или он попадает в разряд традиционных моделей с краткосрочной зави-
симостью (Н =0,5). Теперь мы рассмотрим оценочную формулу, позволяющую
получить более точную статистическую оценку, но требующую принятия опреде-
ленных допущений о рассматриваемых данных. Для начала нам нужно рассмот-
реть оценочную формулу спектральной плотности.
График спектральной функции
Классическая задача теории стохастических процессов заключается в оценке спек-
тра мощности S(w) стационарного процесса x(t) в показателях отдельной реали-
зации конечного сегмента процесса. То есть у нас есть только один экземпляр x(t),
покрывающий конечный период времени. Как утверждалось в разделе 7.3, для дис-
кретного во времени стационарного стохастического процесса автокорреляция и
спектральная плотность определяются так:
R(k) = E[(x(t)x(i + k>\ S(w) = X R(k)e'Jkx-
k
Если предположить, что процесс является корреляционно эргодическим (сред-
нее по времени равно среднему по ансамблю), тогда мы можем оценить функцию
автокорреляции следующим образом:
RAk) = ^X(n + k)X(n).
Поскольку спектральная плотность S(w) представляет собой преобразование
Фурье функции автокорреляции R(k), то мы можем надеяться, что в результа-
те преобразования Фурье оценки функции автокорреляции получится хорошая
оценка спектральной плотности. И это при определенных условиях действитель-
но так.
Оценка спектральной плотности стохастического процесса x(t), определенно-
го в дискретные моменты времени {х(, t = 0,1,2,...}, может быть получена при по-
мощи ряда Фурье за период времени N следующим образом:
Эта оценочная формула в литературе обычно называется периодограммой
(periodogram), или функцией интенсивности1.
В большинстве книг по стохастическим процессам рассматриваются периодограммы пли спектральные
функции, но обсуждаются только формулировки с постоянным временем. Читатель, интересующийся
данным вопросом, может найти хорошее обсуждение формулировок дискретного времени в [37] и [215].
286
Глава 9. Самоподобный трафик
Оценка параметра Херста
Предположим, что наблюдаемая временная последовательность взята из самопо-
добного стохастического процесса с параметром Н и что выбрана конкретная фор-
ма процесса, например процесс дробного броуновского движения. Тогда спект-
ральная плотность выбранного процесса может быть выражена как S(w, If), где
форма плотности известна, но параметр Н неизвестен. В этом случае можно пока-
зать, что параметр Н можно оценить, если найти такое значение Н, которое мини-
мизирует следующее выражение:
40)
5(ю, Н)
dw.
Этот метод известен как оценочная формула Уиттла (Whittle). Подробно
она обсуждается в [24]. Если длина последовательности {х*} равна N, тогда опи-
санный выше интеграл можно заменить дискретным суммированием по частотам
w = 2n/N, 4л/М ..., 2л. Преимущество такого подхода заключается в том, что он
позволяет получить не только оценку параметра Н, но также еще и выборочную
дисперсию, что, в свою очередь, позволяет вычислить величины доверительных
интервалов. Это возможно, так как оценочная формула является асимптотически
нормальной. Выборочная дисперсия может быть получена при помощи следую-
щей формулы:
Var( Н ) = 4л
г О log5O) )
11 дН [
В отличие от графика зависимости дисперсии от времени и графика R/S, ис-
пользующихся для проверки временных последовательностей на самоподобие
и получения грубой оценки параметра Н, оценочная формула Уиттла предпола-
гает, что временная последовательность представляет собой самоподобный про-
цесс определенного вида, и позволяет оценить параметр II в доверительном
интервале.
9.6. Параметр Херста
11а протяжении всей главы мы использовали параметр самоподобия, или параметр
Херста, в качестве удобной единицы измерения самоподобия стохастического про-
цесса. Этот параметр был назван по имени X. Е. Херста (Н. Е. Hurst), посвятив-
шего свою жизнь изучению Нила и других рек, а также проблемам хранения воды
[1191. Среди прочих вопросов Херст обнаружил, что уровень воды в Ниле за
800-летний период проявляет признаки самоподобия. Этот раздел знакомит с ис-
торией создания параметра Н.
Гидролог по образованию, Херст исследовал долгосрочные характеристики
потоков воды различных рек. Он заметил, что некоторые реки (например, Рейн)
9.6. Параметр Херста
287
обладают относительно мягкими флуктуациями. Другие реки, такие как Нил,
являют собой совершенно иную картину. Херст заметил, что долгосрочные и крат-
косрочные характеристики сходны. В краткосрочной перспективе, как и следова-
ло ожидать, уровень воды в Ниле изменялся из года в год. Также можно было ожи-
дать, что эти флуктуации будут иметь тенденцию к усреднению, так что за более
долгий период уровень Нила должен был оставаться в довольно узком диапазоне
с хорошими и плохими периодами, часто сменяющими друг друга. Однако в дей-
ствительности Нил ведет себя не так. В долгосрочной перспективе длинные
периоды засухи следуют за долгими периодами высокой воды, в которые наводне-
ния происходили чуть ли не каждый год. Мандельброт назвал это явление эффек-
том Иосифа (Joseph effect), в соответствии с отрывком из Библии (Кнша Бытия
41:29-30): «И сказал Иосиф фараону — будут семь лет изобилия по всей земле
Египетской, и будут после них семь голодных лет». Возможно, это не лучший
термин, поскольку долгосрочное поведение Нила не проявляет такой регуляр-
ности. В действительности не наблюдается какой-либо устойчивой цикличности
в любом временном масштабе.
Херст занялся проблемой проектирования идеального резервуара для регули-
рования потока Нила на основании имеющейся записи наблюдений за уровнем
реки. Идеальный резервуар должен обеспечивать постоянный поток, равный сред-
нему входному потоку, который никогда не переполняется и никогда не иссякает.
Для решения данной задачи требуется получить данные об изменчивости потока
воды. Предположим, что уровень воды измеряется раз в год. Определим следую-
щие переменные:
4- Xj — входной поток за год j (1 < j < N); это изучаемые временные последова-
тельности;
♦ M(N) — постоянный ежегодный исходящий поток, основанный на наблю-
дениях в течение N лет;
4 — уровень воды в резервуаре к концу года j (1 <j < N);
4 N— число лет наблюдения.
Эти величины иллюстрирует рис. 9.8. Основываясь на записи Млет, мы хотели
бы получить значения минимального и максимального уровней воды в резервуа-
ре (Lmin(N), а также диапазон R(N) = Lmax(N) -
Рис. 9.8. Иллюстрация параметров для анализа Херста
288
Глава 9. Самоподобный трафик
Учитывая данные о входном потоке за интересующий нас период, требующ J
ся величины нетрудно вычислить:
2V 7=1
£, = £х,-Ж(Ю;
>=1
R(N) = max!,. - min
l<j<N J l<j<N 7
Таким образом, M(N) представляет собой средний входной поток за N лет, £, —
суммарный входной поток за первые) лет минус суммарный выходной поток за те
же годы, a R(N) — это разница между максимальным и минимальным значениями
Lj за эти годы. Очевидно, диапазон зависит от интервала времени N и представля-
ет собой неубывающую функцию N. Обратите внимание на то, что параметр R не
равен диапазону временной последовательности Xj, которая имеет следующий вид:
Диапазон(Х, N) = max А’. - min X,.
Z 1 1<J<N 1
Вместо этого мы можем рассматривать Lj как накапливаемую величину, на
которую временная последовательность отклоняется от среднего значения за вре-
мя j. Таким образом, R представляет собой величину, которая, в определенном
смысле, лучше характеризует изменчивость случайной переменной X.
Херст исследовал ряд явлений и разработал нормализованную безразмерную
величину R/S, характеризующую изменчивость, где S представляет собой выбо-
рочное среднее:
п N
В определенном смысле как R, так и 5 измеряют изменчивость данных. Вели-
чина R линейно зависит от данных, тогда как 5 учитывает квадраты исходных зна-
чений. Херст называл это отношение масштабированным диапазоном (rescaled
range).
Херст обнаружил, что для многих природных явлений, включая расход воды в
реках, отложения осадочных пород и годовые кольца деревьев, отношение R/S как
функция N хорошо описывается следующей эмпирической формулой для боль-
ших значений N:
R/S~(N/2)HnpnH>0,5.
Несложно убедиться в этом визуально, если построить график зависимости
R/S от N в логарифмическом масштабе. Херст обнаружил, что для многих наборов
данных точки ложатся на прямую линию; наклон этой линии представляет собой
параметр Н из предыдущей формулы.
Можно показать, что для любого краткосрочного процесса отношение R/S ста-
новится асимптотически пропорциональным М72, то есть // = 0,5. Однако Херст
9.8. Задания
289
нашел множество явлений со значениями Н, варьирующимися в диапазоне от 0,7
до 0,9. Большие значения параметра Н предполагают большую степень изменчи-
вости данных.
9.7. Рекомендуемые литература
и веб-сайты
Теме самоподобия, относящейся одновременно к теории фракталов и теории хао-
са, посвящено много книг. [198] представляет собой интересную книгу, посвящен-
ную самоподобию и его проявлениям во фракталах, хаосе и других областях.
Объем литературы по самоподобному трафику данных стремительно растет, и
здесь упоминалось только несколько ключевых статей. [ 144 ] является одной из
наиболее значимых статей по теме сетей за последнее десятилетие, с которой на-
чался новый метод исследования производительности трафика. В [ 176] содержит-
ся убедительный анализ самоподобного трафика на основе протокола TCP, а так-
же ряд полезных приложений, посвященных лежащим в основе математическим
понятиям, представляющим общий интерес при моделировании самоподобного
трафика. В центре внимания книги [77] находится тема влияния самоподобия на
производительность очередей, а также в ней содержится подробный обзор мето-
дов моделирования. В [104] также рассматривается вопрос производительности
очередей и обсуждаются методы управления самоподобным трафиком. [2] пред-
ставляет собой важную подборку глав различных авторов, обеспечивающую де-
тальное обозрение данной темы. [24] является еще одной подборкой глав различ-
ных авторов, посвященных вопросам моделирования и анализа данных.
В [82 ] содержится детальный анализ параметра Херста и отношения R/S, а так-
же обсуждение процесса дробного броуновского движения. В [78] также предо-
ставляется превосходное освещение процесса дробного броуновского движения.
В [169] обсуждается приложение дробного броуновского движения к анализу
трафика.
Рекомендуемым веб-сайтом является Modeling of Self-Similar Traffic. Это сайт
исследовательского проекта в области самоподобия.
9.8. Задания
1. Чему равна длина множества Кантора после N итераций?
2. Покажите, что множество Кантора состоит из всех точек в интервале [0,1 ],
не имеющих единиц в их троичном представлении.
3. В каком смысле представленная ниже последовательность является само-
подобной?
...1/8,1/4,1/2,1,2,4, 8...
290 Глава 9. Самоподобный трафик
4. Покажите, что если случайная переменная X подчиняется распределению
Парето с параметрами k и а, тогда случайная переменная Y = 1п(А/й) подчи-
няется экспоненциальному распределению с параметром а.
5. Непрерывное во времени определение самоподобного стохастического про-
цесса, описанное в разделе 9.2, включает равенства, связывающие Е[х(/)|
с Е[х(а£)| и Var[x(t)] с Var[x(af)J.
а) покажите уравнения для Н = 1 и Н = 0,5 и прокомментируйте результаты;
б) перепишите уравнения, связывающие Е[х(Г)] с E[x(at)| и Varfx(f)] с
Var[x(ai)];
в) покажите уравнения из задания б для Н= 1 и Н= 0,5 и прокомментируйте
результаты.
Часть IV
Перегрузка и управление
трафиком
Главная, а в действительности и единственная причина перехода на более быст-
рые сети заключается в том, чтобы поддерживать возросший трафик: больше ко-
нечных систем и более высокие скорости передачи данных для приложений око-
нечных систем. К сожалению, взаимодействие между протоколами в оконечных
системах и механизмами управления трафиком в сетях и маршрутизаторах могут
привести к существенной недогрузке высокоскоростной сети. Например, в [56]
сообщается об измерении FTP-трафика с удивительными результатами. При пе-
редаче по протоколу FTP 4,4-мегабайтного файла данных между двумя хостами,
присоединенными к одной и той же 10-мегабитной сети Ethernet, наблюдается
средняя пропускная способность в 1,313 Мбит/с. При использовании того же само-
го программного обеспечения и компьютеров для передачи этого файла по сети
ATM со скоростью передачи данных 100 Мбит/с была замерена средняя пропуск-
ная способность всего лишь в 0,366 Мбит/с. Таким образом, скорость передачи дан-
ных в сети увеличивается в 10 раз, а пропускная способность падает почти в 4 раза!
Ключ к пониманию данной проблемы заключается в механизмах управления
трафиком, используемых протоколами транспортного уровня оконечных систем,
как, например, TCP. Протокол TCP представляет собой наиболее распространен-
ный транспортный протокол, поддерживающий такие приложения, как передача
файлов, электронная почта, доступ к системам с удаленных терминалов, доступ
к Паутине, а также приложения клиент-сервер. Протокол TCP представляет со-
бой сквозной протокол, обращающийся с сетью, как с черным ящиком. У него нет
средств непосредственного определения состояния сети, поэтому ему приходится
выяснять состояние сети путем диалога с оконечными системами1.
Две оконечные системы, общающиеся по протоколу TCP, используют меха-
низм управления потоком с двумя ключевыми характеристиками. Во-первых, при-
няв данные, получатель посылает отправителю подтверждение, и, во-вторых, каж-
дое подтверждение сопровождается числом, указывающим, сколько еще данных
готов принять получатель. Такой механизм был разработан для того, чтобы позво-
лить получателю управлять потоком данных от отправителя так, чтобы избежать
перегрузки получателя, но тот же самый механизм используется как средство борь-
бы с перегрузкой в сети. Если отправителю не удается получить подтверждение
Существует несколько исключений, такие как служба ABR сети ATM, обсуждаемая в главе 13.
292 Часть IV. Перегрузка и управление трафиком
в ответ на отправленный сегмент данных в течение определенного периода време!
ни, он отправляет этот сегмент еще раз. Однако у отправителя нет способа опреде-]
лить, был ли неподтвержденный сегмент данных отвергнут сетью или он просто
сильно задержался в пути, но все-таки дошел до адресата. В любом случае отпра-
витель должен снизить скорость передачи, так как потерянный или задержав-
шийся сегмент данных свидетельствует о наличии перегрузки в сети. Во втором
случае протокол TCP не должен повторно передавать сегмент, так как это только
увеличит нагрузку на сеть.
Таким образом, в любой конфигурации обычной или объединенной сети у око-
нечной системы есть только грубый инструмент, при помощи которого можно опре-
делить наличие перегрузки в сети и должным образом отреагировать. Но с увели-
чением скорости передачи данных в сети важность борьбы с перегрузкой резко
возрастает по двум причинам:
♦ Единственная обратная связь, имеющаяся у отправителя, пользующегося
протоколом TCP, опаздывает на время, требующееся для прохождения дан-
ных в оба конца. При более высоких скоростях источник успевает передать
огромное количество дополнительных битов информации, прежде чем по-
лучает ответную информацию. Таким образом, если возникает перегрузка,
то прежде чем отправитель узнает об этом, он успевает существенно ухуд-
шить ситуацию, отправив большой объем данных.
♦ Пики трафика высокоскоростных сетей могут быть огромными, особенно
если трафик проявляет самоподобные свойства. В этом случае перегрузка
может быстро возникнуть и сохранятся, так что сети придется долго отбрасы-
вать сегменты, прежде чем источники отреагируют на возникновение пробле-
мы. В результате черный ящик грозит превратиться в черную дыру, засасы-
вающую все входящие сегменты, но мало что доставляющую получателям.
Для увеличения производительности в высокоскоростных сетях оконечные сис-
темы должны регулировать потоки данных, чтобы эффективно расходовать ресур-
сы, не перегружая систему. Теме перегрузки и борьбы с нею и посвящена часть IV.
♦ Глава 10. Борьба с перегрузкой в обычных и объединенных сетях. Борьба
с перегрузкой представляет собой критически важный вопрос разработки
коммутируемых компьютерных сетей. Глава 10 начинается с объяснения
природы перегрузки в компьютерных сетях, а также важности и сложности
борьбы с перегрузкой. Затем мы рассмотрим ра.зличные методы, применяемые
для борьбы с перегрузкой и управления трафиком. В этой главе также обсуж-
даются общие вопросы борьбы с перегрузкой в традиционных сетях с комму-
тацией пакетов и методы борьбы с перегрузкой в сетях ретрансляции кадров.
♦ Глава 11. Управление потоком и контроль ошибок на уровне передачи дан-
ных. Механизм оценки состояния сети и управления потоком трафика, дос-
тупный протоколам транспортного уровня, таким как TCP, представляет
собой механизм скользящего окна. Этот механизм сходен с тем, что исполь-
зуется в управляющих протоколах уровня передачи данных, например HDLC.
Чтобы прояснить природу этого механизма и его зависимость от таких ключе-
вых факторов, как скорость передачи данных и задержка распространения,
лучше всего сначала изучить вопросы управления потоком на уровне передачи
данных, где количество переменных меньше. Эта тема обсуждается в главе 11
Часть IV. Перегрузка и управление трафиком
293
4- Глава 12. Управление трафиком в протоколе TCP. В главе 12 исследуется
управление трафиком на уровне транспортного протокола. Объясняется
работа механизма управления потоком протокола TCP, а также то, как он
используется для борьбы с перегрузкой. Кроме того, показана неочевидная
взаимосвязь протоколов TCP и ATM.
♦ Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM. Осо-
бенность сетей ATM заключается в использовании логических соединений
(виртуальных каналов и виртуальных путей), а также соглашений о трафике,
позволяющих резервировать сетевые ресурсы для обслуживания индивиду-
альных соединений. В соглашении о трафике указываются характеристики
трафика, создаваемого источником в этом соединении, а также запрашиваемое
качество обслуживания, которое сеть должна обеспечить данному соедине-
нию. На основе ожидаемого типа трафика и требуемого качества обслужи-
вания сетевые коммутаторы должны зарезервировать ресурсы и обрабаты-
вать поток ячеек так, чтобы выполнить условия соглашения.
Глава 13 начинается с обзора уникальных требований управления трафиком
ячеек в сетях ATM, а затем рассматриваются специфические параметры (ха-
рактеристики трафика, параметры качества обслуживания), определяющие
соглашение о трафике. Следом за этим объясняется вся структура, разрабо-
танная для управления трафиком ATM. Далее исследуются методы управ-
ления трафиком, разработанные для трафика, чувствительного к задержкам
(например, CBR и VBR). Наконец, обсуждаются методы управления тра-
фиком ATM, позволяющие управлять неравномерным трафиком.
Глава 10
Борьба с перегрузкой
в обычных и объединенных
сетях
На Сент-Пол большая толпа запрудила платформу. Опа виде-
ла море лиц, на каждом из которых отчетливо читалась целе-
устремленность, страстная настойчивость и непоколебимая
решимость попасть в этот поезд. Как и ранее, на Нортерн Лайн,
она подумала, что должно быть некое правило, некий закон,
не позволяющий попасть внутрь большему, чем допустимо,
числу людей. Кто-то должен был появиться и остановить их.
Барбара Вайи (Рут Ренделл). Ковер царя Соломона
Перегрузка — это ключевая проблема, которую нужно решать при проектирова-
нии компьютерных сетей, таких как сети с коммутацией пакетов, сети ретрансля-
ции кадров и сети ATM, а также объединенные сети. В самом деле, борьба с пере-
грузкой представляет собой одну из центральных тем данной книги. Этой теме
посвящен основной материал частей IV-VI, она также затрагивается в части VII.
Перегрузка представляет собой сложное явление. Столь же непросто и бороть-
ся с ней. В двух словах, перегрузка возникает тогда, когда количество пакетов1,
передаваемых по сети, начинает приближаться к значению допустимой пропуск-
ной способности сети. Задача борьбы с перегрузкой состоит в том, чтобы поддер-
живать количество пакетов в сети ниже уровня, при котором пропускная способ-
ность начинает резко падать.
Чтобы понять вопросы, относящиеся к теме борьбы с перегрузкой, нам нужно
рассмотреть некоторые результаты теории очередей. Эта тема детально изучается
в главе 7, но основную мысль можно сформулировать кратко. По существу, ком-
пьютерная или объединенная сеть представляет собой сеть очередей. На каждом
узле (коммутаторе компьютерной сети, маршрутизаторе объединенной сети)
существует очередь пакетов, ожидающих передачи по каждой исходящей линии.
1 В этой главе мы будем использовать термин пакет (packet) в широком смысле, понимая под ним па-
кеты в сети с коммутацией пакетов, кадры в сети ретрансляции кадров, ячейки в сети ATM или IP-
дейтаграммы в объединенной сети.
10.1. Следствия перегрузки
295
Если скорость, с которой пакеты прибывают и становятся в очередь, превышает
скорость, с которой пакеты могут передаваться дальше, размер очереди растет нео-
граниченно, а задержка передачи пакета стремится к бесконечности. Даже если
скорость поступления пакетов меньше доступной скорости передачи, при прибли-
жении скорости поступления пакетов к скорости передачи длина очереди резко
увеличивается. Согласно традиционно применяемому грубому правилу, 80-про-
центное заполнение очереди считается предупреждением о перегрузке*. Такое уве-
личение длины очереди означает, что задержка каждого пакета на каждом узле
возрастает. Более того, поскольку размер очереди ограничен, в конце концов оче-
редь переполняется.
10.1. Следствия перегрузки
Рассмотрим ситуацию системы очередей на отдельном коммутаторе или маршру-
тизаторе пакетов (рис. 10.1). У каждого узла есть несколько присоединенных к
нему портов ввода-вывода* 2: не менее одного для связи с другими узлами и, воз-
можно, несколько портов, связывающих узел с оконечными системами. На каж-
дом порту пакеты прибывают и убывают. Мы можем считать, что у каждого порта
есть по два буфера, один для приема прибывающих пакетов и другой для хране-
ния пакетов, ожидающих отправки. На практике с каждым портом может быть ас-
социированы два буфера фиксированной длины или пул памяти, доступный для
любых действий с буферами. В последнем случае мы можем считать, что у каждого
порта есть два буфера переменной длины с постоянной суммарной вместимостью.
В любом случае прибывшие пакеты помещаются во входной буфер соответству-
ющего порта. Узел исследует каждый поступивший пакет, принимает решение о
выборе маршрута, а затем помещает пакет в соответствующий выходной буфер.
Пакеты, стоящие в очереди на передачу, передаются настолько быстро, насколько
это возможно. По сути, это статистическое мультиплексирование с разделением
времени. Если пакеты прибывают слишком быстро, а узел не успевает их обраба-
тывать (принимать решения о выборе маршрута) или не успевает удалять пакеты
из выходных буферов, тогда в конце концов поступят пакеты, для которых не най-
дется места в буферах.
При достижении подобной точки насыщения можно воспользоваться одной
или двумя общими стратегиями. Первая стратегия заключается в том, что любой
прибывающий пакет, для которого нет места, просто игнорируется. Альтернатив-
ный подход состоит в том, что узел, испытывающий подобные трудности, может
предпринять определенные действия по управлению потоком, проходящим через
него и его соседей. Однако, как показано на рис. 10.2, каждый из соседей узла так-
' Однако если трафик проявляет самоподобные свойства (см. главу 9), все .может оказаться намного
серьезней, и длинные очереди могут возникать даже при небольшой средней загруженности сети.
2 В случае коммутатора сети с коммутацией пакетов, сети ретрансляции кадров пли сети ATM каждый
порт ввода-вывода соединяется с линией передачи, присоединенной к другому узлу или оконечной
системе. В случае маршрутизатора объединенной сети каждый порт ввода-вывода соединяется либо
непосредственно с другим узлом, либо с подсетью.
296 Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
же управляет несколькими очередями. Если узел 6 ограничивает поток пакетов о!
узла 5, это приведет к тому, что выходной буфер узла 5 переполнится. Такил!
образом, перегрузка в одной части сети может быстро распространиться, переки-
дываясь на соседей, и даже охватить всю сеть. Управление потоком является весь-
ма мощным средством, поэтому им необходимо пользоваться так, чтобы управлять
трафиком всей сети.
К другому
коммутатору
или маршрутизатору
К оконечной
системе
Рис. 10.1. Входные и выходные очереди на коммутаторе или маршрутизаторе
10.1. Следствия перегрузки
297
Идеальная производительность
На рис. 10.3 показаны графики идеального использования сети. На верхнем гра-
фике представлена зависимость пропускной способности (количества пакетов,
доставленных оконечным станциям-получателям) сети от предлагаемой нагруз-
ки (количество пакетов, передаваемых оконечными системами-отправителями).
По обеим координатным осям графика откладываются значения, нормализо-
ванные относительно максимальной теоретической пропускной способности
сети. Например, если сеть состоит из одного узла и двух линий с пропускной спо-
собностью 1 Мбит/с, тогда теоретическая пропускная способность сети составит
2 Мбит/с. В идеальном случае суммарный трафик сети может увеличиваться, при-
нимая предлагаемую нагрузку, и достигать максимальной пропускной способно-
сти сети. При дальнейшем увеличении нагрузки нормализованный суммарный
трафик остается на отметке 1,0. Однако обратите внимание на то, что происходит
со сквозной задержкой среднего пакета даже в этом идеальном случае. При очень
низкой нагрузке существует некоторая постоянная задержка, состоящая из задерж-
ки распространения по сети от отправителя к получателю и задержки обработки
на каждом узле. По мере увеличения нагрузки на сеть к этой величине также до-
бавляются задержки ожидания в очередях на каждом узле. Когда нагрузка превы-
шает пропускную способность сети, задержка становится бесконечной.
Вот простое интуитивно понятное объяснение того, почему задержка должна
стремиться к бесконечности. Предположим, что каждый узел сети оснащен бу-
ферами бесконечного размера и что входная нагрузка превышает пропускную
способность сети. В идеальных условиях сеть будет продолжать поддерживать
нормализованную пропускную способность 1,0. Поскольку нормализованная ско-
рость поступления пакетов в сеть превышает 1,0, размеры внутренних очередей
растут. В установившемся режиме при входе, превышающем выход, очереди рас-
тут до бесконечности, в связи с чем также до бесконечности увеличивается вели-
чина задержки.
Прежде чем перейти от идеальных условий к реальным, важно понять значение
графиков, данных на рис. 10.3. На этом рисунке показана идеальная, недостижи-
мая цель всех схем управления трафиком и борьбы с перегрузкой. Ни одна схема
не может обладать производительностью большей, чем представленный на рисунке
идеал. Было показано (см. [125]), что конфигурация сети и схема борьбы с пере-
грузкой, обеспечивающие большую пропускную способность, как правило, также
дают более высокое время задержки. Там же было показано, что мощность пред-
ставляет собой лаконичную меру сравнения различных схем.
Практическая производительность
Идеальный случай, представленный на рис. 10.3, предполагает наличие бесконеч-
ных буферов и отсутствие накладных расходов, связанных с передачей пакетов и
борьбой с перегрузкой. На практике буферы конечны, что приводит к их перепол-
нению, а попытки борьбы с перегрузкой требуют части пропускной способности
сети на обмен управляющими сигналами.
298 Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
Рассмотрим, что произойдет в сети с буферами конечных размеров, если не
предпринимать никаких попыток борьбы с перегрузкой или ограничения трафика,
поступающего от оконечных систем. Разумеется, детали будут отличаться в зависи-
мости от конфигурации сети и от статистических характеристик трафика. Однако
графики на рис. 10.4 в общих чертах демонстрируют катастрофический результат.
При низкой нагрузке трафик, а вместе с ним и коэффициент использования
сети растут с ростом предлагаемой нагрузки. При дальнейшем увеличении нагруз-
ки в определенный момент достигается некая точка (точка А на графике), после
которой сетевой трафик увеличивается медленнее, чем нагрузка на входе. Этс
10.1. Следствия перегрузки
299
связано с тем, что сеть входит в состояние управляемой перегрузки. В этом районе
сеть еще справляется с нагрузкой, хотя и с увеличенной задержкой. Отклонение
от идеала вызвано рядом факторов. Во-первых, как правило, нагрузка распределя-
ется по сети неравномерно. Поэтому в то время, когда отдельные узлы испытыва-
ют управляемую перегрузку, другие могут быть серьезно перегружены и переста-
ют поддерживать трафик. Кроме того, по мере увеличения нагрузки сеть пытается
сбалансировать эту нагрузку, направляя пакеты через области, испытывающие
меньшую перегрузку. Чтобы изменение маршрутов было возможно, узлы должны
обмениваться большим количеством управляющих сообщений, предупреждая
друг друга о перегрузке. Эти накладные расходы снижают пропускную способ-
ность, доступную для пакетов с данными.
Нагрузка
Рис. 10.4. Эффект перегрузки
300 Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
При дальнейшем увеличении нагрузки на сеть очереди на различных узлах птГ
должают удлиняться. Наконец достигается точка (точка В на графике), за котй
рой с увеличением нагрузки пропускная способность сети падает. Причина этов»
явления заключается в том, что буферы каждого узла ограничены в размерах. Ко
да буферы узла наполняются, узел вынужден отбрасывать пакеты. Таким образом
отправитель помимо новых пакетов вынужден передавать потерянные пакеты по-
вторно. Это только усугубляет ситуацию. По мере того как все больше и больше
пакетов передается повторно, нагрузка на систему возрастает и все большее ко-
личество буферов переполняется. В то время как система безнадежно пытается
рассчитаться с долгами, оконечные системы продолжают закачивать в систему ста-
рые и новые пакеты. Даже успешно доставленные пакеты могут доставляться по-
вторно, так как их доставка и отсылка обратно подтверждений занимает слишком
много времени. В результате отправитель полагает, что пакету' не удалось дойти
до получателя, и посылает пакет еще раз. При таких обстоятельствах эффектив-
ная пропускная способность системы стремится к нулю.
10.2. Борьба с перегрузкой
Изучению различных методов борьбы с перегрузкой посвящена большая часть
книги. На рис. 10.5 даются общие пояснения к этим методам.
Рис. 10.5. Методы борьбы с перегрузкой
Противодавление
В методе противодавления (backpressure) использует эффект, сходный с противо-
давлением в жидкости, текущей по трубе. Когда конец трубы закрывается (или
сужается), давление в жидкости передается назад по трубе к точке истока, где по-
ток останавливается (или замедляется).
Противодавление может быть приведено в действие для каналов связи или ло-
гических соединений. Вернемся к рис. 10.2. Если узел 6 начинает испытывать пе-
регрузку1 (переполняются буферы), тогда поток всех пакетов от узла 5 (или узла 3,
i
10.2. Борьба с перегрузкой
301
или от обоих узлов, 3 и 5) через узел 6 может замедлиться или остановиться. Если
эта ситуация продлится, узел 5 будет вынужден замедлить или остановить потоки
данных на своих входящих линиях. Это ограничение потока распространяется на-
зад (навстречу потоку данных) к отправителям, которым придется ограничить
подачу новых пакетов в сеть.
Противодавление может быть применено выборочно к логическим соединени-
ям, так что поток данных между соседними узлами будет ограничен или останов-
лен только для некоторых соединений, как правило, для тех, которые поддержи-
вают большую часть трафика. В этом случае ограничение распространяется назад
по соединению к источнику.
Применение противодавления ограничено. Эта техника может использоваться
в ориентированных на соединение сетях, допускающих управление потоком на
уровне ретрансляционных участков (от одного узла к следующему). Как правило,
эта возможность имеется в сетях с коммутацией пакетов, основанных на стандар-
те Х.25. Однако ни сети ретрансляции кадров, ни сети ATM не позволяют ограни-
чивать поток на уровне ретрансляционных участков. В объединенных IP-сетях
также нет встроенных средств регулирования потока данных от одного маршру-
тизатора к следующему по пути через объединенную сеть, хотя мы увидим приме-
ры таких средств в части VI.
Сдерживающий пакет
Сдерживающий пакет (choke packet) представляет собой управляющий пакет,
формируемый на перегруженном узле и передаваемый назад узлу-источнику для
ограничения потока данных. Пример сдерживающего пакета — пакет Source Quench
(гашение источника) протокола ICMP (Internet Control Message Protocol — про-
токол управления сообщениями в объединенных сетях). Это сообщение с 'требова-
нием снизить скорость передачи данных может быть послано оконечной системе-
источнику либо маршрутизатором, либо оконечной системой. Получив сообщение
о гашении источника, хост-источник должен снижать скорость, с которой он от-
правляет данные указанному получателю, до тех пор пока не перестанет получать
подобные сообщения. Сообщение о гашении источника может использоваться
маршрутизатором или хостом, который вынужден отвергать IP-дейтаграммы, так
как его буфер переполнен. В этом случае маршрутизатор или хост будет посылать
сообщение о гашении источника в ответ на каждую отбрасываемую им IP-дейта-
грамму. Кроме того, система может посылать сообщения о гашении источника,
ожидая перегрузки, то есть когда ее буферы наполняются выше определенного
уровня. В этом случае дейтаграмма, вызвавшая передачу в ответ на сообщение
о гашении источника, может быть доставлена получателю. Таким образом, полу-
чение сообщения о гашении источника не означает, что соответствующая дейта-
грамма не была доставлена.
Сдерживающий пакет предлагает относительно грубый метод борьбы с пере-
грузкой. Многие более сложные формы явной сигнализации о перегрузке обсуж-
даются в следующих подразделах.
302 Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
Неявная сигнализация о перегрузке
При возникновении перегрузки могут случиться две вещи. Во-первых, может воз-
расти задержка передачи индивидуальных пакетов от отправителя к получателю
и стать заметно больше, чем фиксированная задержка распространения. Во-вторых
пакеты могут отбрасываться. Если отправитель способен обнаружить увеличив-
шееся время задержки и отброшенные пакеты, тогда у него появляется косвенное
свидетельство о наличии перегрузки. Если все отправители способны обнаружи-
вать перегрузку и соответственно снижать формируемый ими поток данных, тог-
да со временем перегрузка в сети «сойдет на нет». Таким образом, за борьбу с пе-
регрузкой на основе неявных сигналов отвечают оконечные системы, а от узлов
системы не требуется никаких действий.
Неявная сигнализация представляет собой эффективный метод борьбы с пе-
регрузкой в дейтаграммных (не требующих соединений) конфигурациях, таких
как объединенные IP-сети. В подобных случаях в сети не устанавливаются логичес-
кие соединения, в которых могут регулироваться потоки данных. Однако логичес-
кое соединение устанавливается между двумя оконечными системами на уровне
протокола TCP. Протокол TCP включает механизмы для подтверждения приема
TCP-сегментов и для регулирования потока данных между отправителем и полу-
чателем по TCP-соединению. Подробнее применяемые в протоколе TCP методы
борьбы с перегрузкой, основанные на способности обнаруживать увеличение вре-
мени задержки и потерю сегментов, обсуждаются в главе 10.
Неявная сигнализация может также применяться в сетях, ориентированных на
соединение. Например, в сетях ретрансляции кадров управляющий протокол
LAPF содержит средства, сходные со средствами управления потоком и контроля
ошибок в TCP. Управляющий протокол LAPF способен обнаруживать потерян-
ные кадры и соответственно настраивать поток данных.
Явная сигнализация о перегрузке
Желательно использовать максимум доступной пропускной способности сети, но
в то же время реагировать на перегрузку управляемым и справедливым образом.
В этом заключается цель методов явного предотвращения перегрузки. В общих
словах, для явного предотвращения перегрузки сеть предупреждает оконечные
системы о растущей нагрузке на сеть, а оконечные системы предпринимают меры
для ее снижения.
Как правило, методы явного предотвращения перегрузки применяются в ори-
ентированных на соединение сетях и управляют потоком пакетов по индивиду-
альным соединениям. Методы явного предотвращения nepei-рузки могут работать
в одном из двух направлений:
। 4 Назад. Уведомление источника о необходимости инициирования процеду-
ры предотвращения перегрузки, если это применимо для данного трафика,
в направлении, противоположном посылаемым пакетам. Таким образом,
отправителю сообщается, что передаваемые им по логическому соединению
пакеты могут столкнуться с перегруженными ресурсами. Встречная инфор-
мация передается либо путем изменения битов в пакетах с данными, направ-
10.3. Управление трафиком
303
ляемых обратно источнику, либо путем передачи ему специальных управ-
ляющих пакетов.
4- Вперед. Уведомление пользователя о необходимости инициирования про-
цедуры предотвращения перегрузки, если это применимо для данного тра-
фика, в том же направлении, в котором посылаются пакеты. Таким образом,
сообщается, что пакет встретил по пути перегруженные ресурсы. Эта инфор-
мация также может передаваться либо путем изменения битов в пакетах с
данными, либо в отдельных управляющих пакетах. В некоторых схемах, по-
лучив такой сигнал, оконечная система отправляет его назад по логическо-
му соединению источнику. В других схемах предполагается, что оконечная
система будет управлять потоком от источника на более высоком уровне
(например, TCP).
Методы явной сигнализации о перегрузке можно разделить на три общие кате-
гории:
+ Двоичные методы. В пакете данных, переправляемом далее перегруженным
узлом, устанавливается определенный бит. Получив по логическому соеди-
нению пакет с подобной индикацией перегрузки, отправитель снижает по-
ток данных.
4 Методы кредита. В основе этих схем лежит предоставление источнику дан-
ных явного кредита на использование логического соединения. Кредит ука-
зывает, сколько байтов или пакетов может передать источник. Когда кредит
исчерпан, источник должен ждать получения дополнительного кредита,
прежде чем сможет продолжить передачу данных. Схемы кредита, как пра-
вило, применяются при сквозном управлении потоком. При этом получа-
тель использует кредит, чтобы источник не вызвал переполнения его буфе-
ров, однако эти схемы также могут применяться для борьбы с перегрузкой.
♦ Методы регулирования скорости. Эти схемы основаны на установку явного
предела скорости передачи данных для источника по логическому соедине-
нию. Источник может передавать данные со скоростью, не превышающей
установленного предела. Для борьбы с перегрузкой каждый узел вдоль пути
передачи данных может уменьшить значение этого предела в управляющем
сообщении к источнику. Подобная схема, применяемая в сетях ATM, опи-
сывается в главе 12.
10.3. Управление трафиком
С темой борьбы с перегрузкой связан ряд вопросов, которые можно объединить
в общую категорию управления трафиком. В своей простейшей форме борьба с пе-
регрузкой подразумевает эффективное использование сети при высоком уровне
нагрузки. При возникновении перегрузки могут применяться различные методы,
обсуждавшиеся в предыдущем разделе, независимо от того, какой конкретно
отправитель или получатель затронут. Когда узел перегружен и вынужден от-
брасывать пакеты, он может это делать в соответствии с неким простым правилом,
304
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
например отбрасывать последний поступивший пакет. Однако могут применять-
ся и более сложные правила. Здесь мы кратко рассмотрим некоторые из них. Все
эти вопросы исследуются более детально далее в этой книге.
Справедливость
По мере развития перегрузки задержки пакетов между отправителем и получате-
лем будут расти, что при сильной перегрузке может вести к потере пакетов. В от-
сутствии других требований нам хотелось бы гарантировать, что различные по-
токи данных будут страдать от перегрузки в равной степени. При этом простое
отбрасывание последнего прибывшего пакета может оказаться несправедливым.
В качестве примера метода, способного гарантировать справедливое отношение к
различным потокам, узел может поддерживать отдельные очереди для каждого
логического соединения или для каждой пары отправитель — получатель. Если все
буферы очередей имеют равную длину, тогда очереди с наибольшим трафиком
будут отбрасывать пакеты чаще, что обеспечит справедливую долю пропускной
способности для соединений с меньшим трафиком.
Качество обслуживания
Разные потоки данных могут трактоваться по-разному. Например, как указывает-
ся в [126], некоторые приложения, такие как приложения для передачи голоса и
видео, чувствительны к задержкам, но нечувствительны к потерям данных. Дру-
гие, такие как системы передачи файлов и электронная почта, нечувствительны к
задержкам, но чувствительны к потерям. Имеются также приложения, например
приложения интерактивной графики и интерактивных вычислений, чувствитель-
ные как к задержкам, так и к потерям данных. Кроме того, разные потоки данных
обладают разными свойствами, например трафик управления сетью важнее тра-
фика приложений, особенно в случае перегрузок или сбоев.
В периоды перегрузок особенно важно, чтобы потоки данных с различными
требованиями к трафику трактовались по-разному и получали разное качество
обслуживания (Quality of Service, QoS). Например, узел мог бы передавать высо-
коприоритетные пакеты раньше низкоприоритетных, ожидающих в той же очере-
ди . Или узел мог бы поддерживать разную дисциплину очередей для разных уров-
ней качества обслуживания, отдавая предпочтение более высокому уровню.
Резервирование
Один из способов предотвращения перегрузки, а также предоставления прило-
жению гарантированного уровня качества обслуживания заключается в ис-
пользовании схемы резервирования. Подобная схема представляет собой важную
составляющую часть сетей ATM. При установке логического соединения сеть
и пользователь заключают соглашение о параметрах трафика, в котором указыва-
ется скорость передачи данных, а также другие характеристики потока данных.
Сеть соглашается предоставлять определенный уровень качества обслуживания
до тех пор, пока трафик находится в оговоренных в соглашении пределах. Избы-
10 4. Борьба с перегрузкой в сетях с коммутацией пакетов
305
точный трафик либо отвергается, либо доставляется при наличии такой возмож-
ности и без гарантий доставки. Если при попытке установки нового соединения
ресурсов оказывается недостаточно для гарантирования требуемого уровня каче-
ства обслуживания, в резервировании новых ресурсов и установке соединения от-
казывается. Сходная схема была разработана для объединенных 1Р-сстей.
Политика поддержания трафика представляет собой один из аспектов схемы
резервирования (см. рис. 10.5). Узел сети (как правило, это узел, к которому при-
соединена оконечная система) отслеживает поток данных и сравнивает его пара-
метры с параметрами, оговоренными в соглашении. Избыточный трафик либо не
поддерживается, либо помечается особым образом и обслуживается без гарантий.
10.4. Борьба с перегрузкой в сетях
с коммутацией пакетов
Для борьбы с перегрузкой в сетях с коммутацией пакетов было предложено н
опробовано множество методов. Ниже представлено несколько примеров.
4 Перегруженный узел отправляет управляющий пакет некоторым или всем
узлам-источникам. Источники, получившие такой пакет, останавливают или
замедляют передаваемый ими поток данных и таким образом ограничива-
ют общее количество пакетов в сети. При применении данного метода в сети
во время перегрузки требуется поддерживать дополнительный трафик.
4- Использование информации о маршрутах. Алгоритмы маршрутизации снаб-
жают соседние узлы, влияющие на принятие решений о выборе маршрутов,
информацией о времени задержки. Эта информация может также исполь-
зоваться для изменения скорости формирования новых пакетов. Посколь-
ку выбор маршрута оказывает влияние на величину задержек, эти задержки
могут изменяться слишком быстро, чтобы эффективно использоваться для
борьбы с перегрузкой.
4- Отправка пробного сквозного пакета. Такой пакет может содержать времен-
ную метку для измерения задержки между двумя определенными конечны-
ми точками. Недостаток этого метода также заключается в том, что он ока-
зывает дополнительную нагрузку на сеть.
♦ Разрешение узлам, коммутирующим пакеты, добавлять к проходящим через
них пакетам информацию о перегрузке. Существует два подобных метода.
Узел может добавлять эту информацию к пакетам, отправляющимся в направ-
лении, противоположном потоку данных. Эта информация быстро достига-
ет узла-источника, который может уменьшить поток пакетов, отправляемых
им в сеть. В качестве альтернативы узел может добавлять эту информацию
к пакетам самого потока данных. При этом получатель либо просит отпра-
вителя снизить нагрузку, либо возвращает сигнал источнику в пакетах (или
в подтверждениях), пересылаемых в обратном направлении.
Как будет показано далее, эти ранние методы борьбы с перегрузкой были адап-
тированы для использования в Интернете.
306
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
10.5. Борьба с перегрузкой в сетях
ретрансляции кадров
Стандарт 1.370 определяет цели борьбы с перегрузкой в сетях ретрансляции кад-
ров следующим образом:
♦ минимизация количества отброшенных кадров;
4 поддержка с высокой вероятностью и минимальной дисперсией условлен-
ного уровня качества обслуживания;
4 минимизация вероятности того, что один оконечный пользователь сможет
монополизировать сетевые ресурсы за счет других оконечных пользователей;
♦ простота реализации и небольшие накладные расходы, ложащиеся на око-
нечных пользователей или на сеть;
♦ минимальный дополнительный сетевой трафик;
4 справедливое распределение сетевых ресурсов между пользователями;
4 ограничение возможностей распространения перегрузки на другие сети и
элементы сетей;
4 эффективная работа независимо от трафика в любом направлении между
оконечными пользователями;
4 минимальное взаимодействие с другими системами и минимальное влия-
ние на другие системы в сети ретрансляции кадров;
4 минимизация отклонений в качестве обслуживания, предоставляемого ин-
дивидуальным соединениям при перегрузке (например, отдельные логиче-
ские соединения не должны ощущать внезапного ухудшения качества об-
служивания при приближении или наступлении перегрузки).
В сетях ретрансляции кадров борьба с перегрузкой сложнее, так как обработ-
чикам кадров (узлам, коммутирующим кадры) доступен ограниченный набор
средств. Протокол ретрансляции кадров был упрощен, чтобы максимизировать
пропускную способность и эффективность. В результате обработчик кадров не
может управлять потоком кадров, поступающих от подписчика или от соседнего
обработчика кадров, использующего типичный для управления потоком протокол
скользящего окна (sliding window), например HDLC (High-level Data Link Control —
высокоуровневый протокол управления каналом).
Борьба с перегрузкой является совместной сферой ответственности сети и конеч-
ных пользователей. Сеть (то есть совокупность обработчиков кадров) обладает
большими возможностями для определения степени перегрузки, тогда как конеч-
ным пользователям проще бороться с перегрузкой, ограничивая потоки данных.
В табл. 10.1 перечислены методы борьбы с перегрузкой, определенные различ-
ными документами ITU-T (International Telecommunications Union-Telecommuni-
cations — Международный союз телекоммуникаций, сектор телекоммуникаций)
и ANSI (American National Standards Institute — Американский национальный
институт стандартов). Стратегия отбрасывания (discard strategy) кадров пред-
ставляет собой основную реакцию на возникновение перегрузки. Когда перегруа-j
10.5. Борьба с перегрузкой в сетях ретрансляции кадров
307
ка становится достаточно серьезной, сеть вынуждена отбрасывать кадры. При этом
желательно, чтобы не нарушалась справедливость по отношению ко всем пользо-
вателям.
Таблица 10.1. Методы борьбы с перегрузкой в сети ретрансляции кадров
Метод Тип Функция Ключевые элементы
Управление отбрасыванием Стратегия отбрасывания Обеспечить сеть информацией о том, какие кадры отбрасывать Бит DE
Обратное явное Предотвращение Обеспечить оконечные Бит BECN
уведомление о перегрузке перегрузки системы информацией о перегрузке в сети или сообщение CLLM
Прямое явное уведомление о перегрузке Предотвращение перегрузки Обеспечить оконечные системы информацией о перегрузке в сети Бит FECN
Неявное Восстановление Оконечные системы Порядковые номера
уведомление о перегрузке после перегрузки сами догадываются о возникновении перегрузки по потерянным кадрам в модулях PDU более высокого уровня
Процедуры предотвращения перегрузки (congestion avoidance) используются
при приближении перегрузки, чтобы минимизировать ее влияние на сеть. Таким
образом, если вернуться к рис. 10.4, эти процедуры должны запускаться в точке А
или даже ранее, чтобы не допустить развития перегрузки до точки В. Около
точки А конечным пользователям будет еще трудно догадаться о том, что перегруз-
ка нарастает. Поэтому в сети должен работать некий механизм явной сигнализации
(explicit signaling), запускающий процедуру предотвращения перегрузки.
Процедуры восстановления после перегрузки (congestion recovery) используют-
ся, чтобы не допустить краха сети при наличии серьезной перегрузки. Эти проце-
дуры, как правило, запускаются, когда сеть начинает терять кадры из-за перегруз-
ки. О потерянных кадрах сообщают верхние уровни программного обеспечения
(например, управляющий протокол LAPF или TCP), таким образом, потерянные
кадры служат средством неявной сигнализации (implicit signaling) о перегрузке.
Процедуры восстановления после перегрузки работают (см. рис. 10.4) вокруг
точки В, а также в области высокой перегрузки.
Сектор ITU-T и институт ANSI рассматривают предотвращение перегрузки
при помощи явной сигнализации и восстановление после перегрузки при помощи
неявной сигнализации как взаимодополняющие формы борьбы с перегрузкой
в службе ретрансляции кадров.
Управление скоростью трафика
Чтобы справиться с перегрузкой, в качестве крайней меры сеть ретрансляции кад-
ров должна отбрасывать кадры. Избежать этого невозможно. Поскольку каждый
обработчик кадров в сети обладает конечными объемами памяти для хранения
кадров (см. рис. 10.1), очереди могут переполняться, в результате чего обработчик
308
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
кадров вынужден выбрасывать либо самый последний поступивший кадр, либн
какой-нибудь другой кадр.
Простейший способ борьбы с перегрузкой в сети ретрансляции кадров заклю-
чается в том, что кадры отбрасываются произвольно, независимо от источника кад-
ра. В этом случае, поскольку самоограничение никак не поощряется, лучшая стра-
тегия для каждой отдельной оконечной системы состоит в том. чтобы передать
кадры как можно быстрее. Разумеется, такое поведение оконечных систем лишь
усугубляет проблему перегрузки.
Для обеспечения более справедливого распределения ресурсов служба ре-
трансляции кадров поддерживает согласованную скорость передана информации
(Committed Information Rate, CIR). Это скорость в битах в секунду, которую сеть
соглашается поддерживать для конкретного соединения. Любые данные, переда-
ваемые сверх CIR, могут быть отвергнуты в случае возникновения перегрузки.
Несмотря на использование термина согласованная, не предоставляется никакой
гарантии, что даже эта скорость будет обеспечена. В случае высокой перегрузки
сеть может быть вынуждена предоставлять обслуживание для данного соединения
на скорости ниже CIR. Однако когда наступает время отбрасывать кадры, в пер-
вую очередь сеть выберет кадры соединений, скорость которых превосходит CIR.
Теоретически, каждый узел сети ретрансляции кадров должен вести себя так,
чтобы сумма скоростей CIR всех соединений всех оконечных систем, присоеди-
ненных к этому узлу, не превышала пропускной способности узла. Кроме того,
сумма скоростей CIR не должна превышать физической скорости передачи данных
в интерфейсе пользователь — сеть, называемой скоростью доступа. Ограничение,
накладываемое скоростью доступа, может быть выражено следующим образом:
У CI R,,j < Скорость/! осту па,. (10.1)
I
Здесь:
♦ CIR,j — согласованная скорость передачи для соединения i по каналу j;
♦ СкоростьДоступа, — скорость передачи данных между пользователем j и
сетью с фиксированной скоростью передачи данных по каналу, в котором
используется мультиплексирование с временным разделением (Time Division
Multiplexing, TDM).
Пропускная способность узла учитывается при выборе нижних значений не-
которых из скоростей CIR.
Для постоянных соединений в сети ретрансляции кадров скорость CIR для
каждого соединения должна устанавливаться в тот момент, когда пользователь и
сеть договариваются о параметрах соединения. Для коммутируемых соединений
параметр CIR является предметом переговоров; это делается на этапе установки
соединения протоколом управления соединением.
Параметр CIR предоставляет способ выбора кадров, которые будут отброшены
в случае перегрузки. Такие кадры помечаются битом DE (Discard Eligibility —
разрешение на отбрасывание) в кадре LAPF (см. рис. 4.9 в главе 4). Обработчик
кадров, к которому присоединена станция пользователя, измеряет скорость пере-
дачи данных (рис. 10.6). Если пользователь отправляет данные со скоростью ниже
CIR, обработчик входящих кадров не изменяет бита DE. Если же скорость переда-
чи данных превышает CIR, обработчик входящих кадров устанавливает значени'
10.5. Борьба с перегрузкой в сетях ретрансляции кадров
309
>ита DE для избыточных кадров, а затем переправляет эти кадры дальше. Такие
кадры могут дойти до получателя, но могут также отбрасываться в случае пере-
грузки. Наконец, определяется максимальная скорость, так что любой кадр, пре-
вышающий максимум, отбрасывается обработчиком входных кадров.
Рис. 10.6. Методы борьбы с перегрузкой
Скорость CIR не предоставляет большой гибкости при управлении скоростя-
ми трафика. На практике обработчик кадров измеряет скорость трафика по каж-
дому логическому соединению, считая количество кадров за интервал времени,
характерный для данного соединения, а затем принимает решение на основе ко-
личества данных, полученных в течение этого интервала. Необходимы также два
дополнительных параметра, назначаемых постоянным соединениям и оговарива-
емых для коммутируемых соединений:
♦ Согласованный размер всплеска (committed burst size) — В,. Максимальный
объем данных, который сеть соглашается передавать при нормальных усло-
виях за измеряемый интервал времени Т. Эти данные могут быть или не
быть непрерывными (например, они могут присутствовать только в одном
или в нескольких кадрах).
4 Избыточный размер всплеска (excess burst size) — Bt. Максимальный объем
данных, который сеть попытается передавать при нормальных условиях за
измеряемый интервал времени Т. Доставка этих данных не гарантируется,
то есть сеть не гарантирует их доставки при нормальных условиях. Други-
ми словами, данные, соответствующие Ве, доставляются с меньшей вероят-
ностью, чем данные в пределах Вс.
Величины Вс и CIR связаны друг с другом. Поскольку Вс представляет собой
гарантированный объем данных, которые могут быть переданы пользователем за
время Т, a CIR — это скорость, с которой данные могут передаваться, мы получаем:
Т =
Вс
CIR
(Ю.2)
Рисунок 10.7, основанный на рисунке из рекомендаций 1,370 сектора ITU-3,
иллюстрирует взаимосвязь этих параметров. На каждом графике сплошной линией
показано суммарное количество информационных битов, переданных по данному
соединению с момента времени 7’= 0. Штриховая линия с надписью Скорость
310
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
доступа представляет скорость передачи данных по каналу, по которому прохо-
дит данное соединение. Штриховая линия с надписью CIR представляет согла-
сованную скорость передачи данных. Обратите внимание на то, что во время
передачи кадра сплошная линия параллельна линии скорости доступа. Когда кадр
передается по каналу, этот канал выделяется для передачи этого кадра. Когда кадр
не передается по каналу, сплошная линия горизонтальна.
Число Число
переданных переданных
битов битов
Число
переданных
битов
в
Рис. 10.7. Соотношения между параметрами перегрузки
10.5. Борьба с перегрузкой в сетях ретрансляции кадров
311
На рис. 10.7, а показан пример, в котором в течение интервала измерения пере-
даются три кадра, при этом суммарное количество битов в трех кадрах меньше,
чем Вс. Обратите внимание на то, что во время передачи первого кадра фактическая
скорость передачи данных временно превышает CIR. Это остается без послед-
ствий, так как обработчик кадров интересует только суммарное количество битов,
переданное за весь интервал времени. На рис. 10.7, б последний кадр, переданный
за интервал времени, приводит к тому, что суммарное число переданных битов пре-
вышает Вс. Соответственно, обработчик кадров устанавливает в единицу бит DE
этого кадра. На рис. 10.7, в третий кадр превышает Вс и помечается для возможно-
го отбрасывания. Четвертый кадр превосходит Вс + Ве и поэтому отбрасывается.
Предотвращение перегрузки при помощи
явной сигнализации
В сети ретрансляции кадров желательно использовать максимальную пропускную
способность, но в то же время реагировать на перегрузку управляемым и справед-
ливым образом. В этом состоит цель методов явного предотвращения перегрузки.
В общих словах, для явного предотвращения перегрузки сеть предупреждает око-
нечные системы о нарастающей перегрузке в сети, а оконечные системы предпри-
нимают действия по снижению нагрузки на сеть.
При разработке стандартов явного предотвращения перегрузки рассматрива-
лись две общие стратегии [26]. Одна группа разработчиков полагала, что перегруз-
ка всегда нарастает постепенно и почти всегда во внешних узлах сети. Другая груп-
па видела случаи, в которых перегрузка развивалась очень быстро во внутренних
узлах, требуя быстрых и решительных действий по ее устранению. Как мы уви-
дим, эти два подхода нашли свое отражение в методах прямого и обратного явного
предотвращения перегрузки соответственно.
Для явной сигнализации в адресном поле каждого кадра предусмотрено два
бита. Любой бит может быть установлен в единицу любым обработчиком кадров,
обнаружившим перегрузку. Обработчики кадров не могут сбрасывать эти биты.
Таким образом, эти биты обеспечивают сигналы от сети конечному пользователю.
♦ BECN (Backward Explicit Congestion Notification — обратное явное уведомле-
ние о перегрузке). Извещает пользователя о необходимости запуска проце-
дуры предотвращения перегрузки, если это допустимо для данного трафика.
Посылается в направлении, противоположном полученному кадру. Указы-
вает, что кадры, передаваемые пользователем по логическому соединению,
могут встретить перегруженные ресурсы.
+ FECN (Forward Explicit Congestion Notification — прямое явное уведомле-
ние о перегрузке). Извещает пользователя о необходимости запуска проце-
дуры предотвращения перегрузки, если это допустимо для данного трафи-
ка. Посылается в том же направлении, что и полученный кадр. Указывает,
что этот кадр встретил перегруженные ресурсы.
Рассмотрим, как эти биты применяются сетью и пользователем. Во-первых, для
Реакции сети (network response) необходимо, чтобы каждый обработчик кадров
. отслеживал поведение очереди. Если длина очереди увеличивается до опасного
312
Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
уровня, тогда следует установить в единицу бит FECN, BECN или оба бита сразу,
чтобы попытаться снизить поток кадров через этот обработчик кадров. Выбор бита
зависит от того, готовы ли конечные пользователи или данное логическое со-
единение реагировать на тот или иной бит. Это может быть определено во время
настройки. В любом случае обработчик кадров должен выбрать логическое соеди-
нение, которое будет снижать свой поток данных в случае перегрузки. Если пере-
грузка становится серьезной, обработчик кадров может уведомить все логические
соединения, проходящие через него. На ранних стадиях перегрузки обработчик
кадров может просто уведомить пользователей тех соединений, которые создают
наибольший трафик.
Реакция пользователя (user response) определяется тем, какой сигнал, FECN
или BECN, он принял. Проще всего прореагировать на сигнал BECN. При этом
пользователь просто снижает скорость передачи кадров до тех пор, пока он не пе-
рестанет получать этот сигнал. Реакция на сигнал FECN является более сложной,
так как требует от пользователя уведомить однорангового пользователя этого со-
единения о необходимости снизить скорость передачи кадров. Такое уведомление
не поддерживается встроенными функциями протокола ретрансляции кадров,
поэтому его следует отправлять на более высоком уровне, например транспорт-
ном. Управление потоком также может осуществляться управляющим протоко-
лом LAPF или каким-либо иным управляющим канальным протоколом, реали-
зованным над подуровнем ретрансляции кадров. Управляющий протокол LAPF
является особенно полезным, так как представляет собой усовершенствованный
протокол LAPD, позволяющий пользователям настраивать размер окна.
10.6. Рекомендуемые литература
и веб-сайты
В [242] содержится всеобъемлющий обзор методов борьбы с перегрузкой. В [124]
и 1126] имеется превосходное освещение необходимых условий борьбы с перегруз-
кой, разных вариантов предпринимаемых действий, а также вопросов производи-
тельности. Прекрасное исследование вопросов производительности компьютер-
ных сетей содержится в [ 139]. В [93] можно найти хотя и несколько устаревшую,
но до сих пор наиболее полную справочную информацию по теме управления
потоком.
Интересное исследование вопросов борьбы с перегрузкой в сетях ретранс-
ляции кадров можно найти в [46] и [72]. Эта тема также хорошо освещена в [401,
[97] и [29].
Ниже перечислены рекомендуемые веб-сайты:
Frame Relay Forum. Сайт форума ретрансляции кадров, координирующего
предпринимаемые попытки расширения функциональности сетей ретранс-
ляции кадров.
♦ Frame Relay Technology. Источник всесторонней информации по ретрансля-
ции кадров.
10.7. Задания
313
10.7. Задания
1. Предлагаемый метод борьбы с перегрузкой известен под названием изарит-
мического контроля. При использовании этого метода суммарное количе-
ство передаваемых сетью кадров ограничено фиксированным числом мар-
керов-разрешений, циркулирующих по сети. Когда обработчик кадров
желает ретранслировать кадр, полученный от соединенного с ним пользова-
теля, он должен сначала захватить и уничтожить маркер-разрешение. Когда
кадр доставляется пользователю-получателю соединенным с ним обработ-
чиком кадров, этот обработчик кадров снова генерирует маркер-разрешение.
Перечислите три потенциальные проблемы данного метода.
2. Рассмотрите сеть ретрансляции кадров, представленную на рис. 10.8. С — это
пропускная способность линии в кадрах в секунду. Узел А оказывает па сеть
постоянную нагрузку в 0,8 кадра в секунду, отправляя их узлу А'. Узел В
оказывает на сеть постоянную нагрузку в Л кадров в секунду, отправляя их
узлу В'. У узла S есть общий буферный пул, который он использует для тра-
фика, направляемого узлам А' и В'. Когда буфер наполняется, кадры от-
брасываются, азатем пересылаются повторно пользователем-источником.
Сквозная пропускная способность узла S равна 2. Начертите график сум-
марного трафика (то есть суммы трафиков А—А' и В—В') как функции X.
Какую часть суммарного трафика составляет трафик А—А' для Л > 1?
Рис. 10.8. Сеть узлов
3. В протоколе IPv4 каждый маршрутизатор, обрабатывающий дейтаграммы,
уменьшает значение поля времени жизни (Time То Live, TTL) в ее заголовке
(см. рис. 2.2) на количество секунд, в течение которого дейтаграмма остается
на маршрутизаторе, или на 1, если это время меньше одной секунды. Когда
маршрутизатор получает дейтаграмму, чье поле TTL содержит 1, он не может
переправить ее далее, а должен отбросить ее. Получив такую дейтаграмму,
оконечная система может доставить ее IP-пользователю. Если дейтаграмма
314 Глава 10. Борьба с перегрузкой в обычных и объединенных сетях
задерж! 1вается на маршрутизаторе дольше, чем значение поля TTL, она долж-
на быть отброшена. Теперь представьте себе маршрутизатор с буфером бес-
конечного размера в установившемся состоянии перегрузки. Скорость
прибывающих пакетов превышает скорость, с которой пакеты могут пере-
даваться дальше. На маршрутизаторе не применяются другие методы борь-
бы с перегрузкой, кроме отбрасывания лишних пакетов. Что можно сказать
о количестве или доле пакетов, протекающих сквозь маршрутизатор, кото-
рым удается успешно достичь пункта назначения?
4. Спецификацией Q.933 для сетей ретрансляции кадров рекомендуется ис-
пользование процедуры для переговоров о размере скользящего окна для
управления потоком, который может составлять от 1 до 127. При перегово-
рах используется переменная k, вычисляемая по следующим параметрам:
♦ La — размер информационного кадра в байтах;
♦ Ru — пропускная способность в битах в секунду;
♦ Ttd — сквозная задержка в секундах;
♦ k — размер окна (максимальное количество ожидающих обработки 1-кад-
ров).
Процедура переговоров в спецификации Q.933 описывается следующим
образом.
Пользователь-инициатор должен сосчитать k при помощи приведенной1 фор-
мулы, заменив максимальное значение сквозной задержки и максимальный
размер исходящего кадра величинами Ttd и Ld соответственно. Сообщение
SETUР (настройка) должно включать параметры протокола и основные пара-
метры уровня передачи данных, а также информацию о сквозной задержке.
Пользователь-получатель должен с помощью той же формулы вычислить
собственное значение k, заменив значение суммарной сквозной задержки и
максимальный размер исходящего кадра величинами Ти и Ld соответственно.
Сообщение CONNECT (соединение) должно включать параметры протоко-
ла и основные параметры уровня передачи данных, а также информацию о
сквозной задержке, так чтобы пользователь-инициатор мог настроить свое
значение k, на основе информации, содержащейся в этих информационных
элементах. Пользователь-инициатор должен с помощью той же формулы
вычислить значение k, заменив значение суммарной сквозной задержки и
максимальный размер исходящего кадра величинами T„i и Ld соответственно.
Сообщениями SETUP и CONNECT стороны обмениваются по управляю-
щему каналу во время установки соединения в сети ретрансляции кадров.
Предложите формулу для вычисления k по значениям других переменных
и проверьте эту формулу.
5. Чтобы сеть ретрансляции кадров могла обнаруживать перегрузку и сигна-
лизировать о ней, каждый обработчик кадров должен отслеживать состоя-
ние очередей. Если длина очереди приближается к опасному уровню, тогда
следует установить один или оба уведомляющих бита (прямой и обратный),
В спецификации Q.933. — Примеч. ред.
10.7. Задания
315
чтобы попытаться снизить поток кадров, проходящий через обработчик кад-
ров. Обработчик кадров может выбрать логическое соединение, которое сле-
дует известить о возникновении перегрузки. Если перегрузка становится
серьезной, обработчик кадров может известить все логические соединения.
На ранних этапах перегрузки обработчик кадров может просто оповестить
пользователей соединений, создающих наибольший трафик.
В одной из спецификаций ретрансляции кадров предлагается алгоритм сле-
жения за длиной очередей, показанный ниже. Цикл начинается, когда исхо-
дящий канал переходит из состояния простоя (очередь пуста) в состояние
занятости (ненулевой размер очереди, включая текущий кадр). Если по-
роговое значение превышается, тогда канал находится в состоянии начи-
нающейся перегрузки, и в одном или во всех логических соединениях, ис-
пользующих этот канал, должны быть установлены биты предотвращения
перегрузки. Опишите алгоритм словами и объясните его преимущества.
Упомянутый алгоритм ретрансляции кадров выглядит следующим образом:
Используемые переменные'.
+ t — текущее время;
♦ U — время 7-го события получения или отправки;
♦ </, — число кадров, пришедших в систему после события;
♦ То — время начала предыдущего цикла;
♦ 7) — время начала текущего цикла.
Алгоритм:
1. Обновление. Вначале </, = (). Если г-м событием является получение, то
q, = q,-t + 1; если i-м событием является отправка, то q, = q, i - 1.
2- 4-i= Е 4 = Е
t,e(T„.T,y
3. £ = A-tA±.
t —Tg
Глава 11
Управление потоком
и контроль ошибок
на уровне передачи данных
Все это время меня не покидали сильнейшие опасения
по поводу спонтанного наступления французов, и эти
опасения противоречили успокаивающим результатам,
которыедавал простой подсчетчисел, расстояний и дат.
Уинстон Черчилль. Мировой кризис
Фундаментальными средствами, определяющими производительность каналов
связи обычных и объединенных сетей, являются управление потоком и контроль
ошибок. На протяжении всей книги обсуждаются методы борьбы с перегрузкой
и способы достижения более высоких уровней коэффициента использования, в ос-
нове которых лежат управление потоками протокольных модулей данных (Protocol
Data Unit, PDU), формируемыми источниками, а также проходящими сквозь про-
межуточные системы. С методами управления потоком тесно связана необходи-
мость восстановления протокольных модулей данных после потерь, вызванных
ошибками передачи или перегрузкой.
Таким образом, при разработке высокоскоростных обычных и объединенных
сетей важно осознавать влияние методов управления потоком и контроля ошибок
на производительность. Эти методы реализуются на уровне передачи данных в
некоторых протоколах сетевого уровня, например Х.25, на транспортном уровней
в некоторых протоколах прикладного уровня.
Моделирование производительности методов управления потоком и контроля
ошибок оказывается исключительно сложной задачей. Простейший случай заклю-
чается в использовании управляющего канального протокола, работающего между
двумя устройствами, соединенными двухточечным соединением. Здесь нас будут
интересовать только постоянная задержка распространения данных между двумя
устройствами, постоянная скорость передачи данных, вероятностная частота ошибок
и, возможно, статистические характеристики трафика. Даже простейшему случаю,
проанализированному в опубликованных исследованиях еще в начале 60-х гг.,
все еще посвящаются статьи, в которых представляются новые результаты (напри-
мер, [248]). Когда мы имеем дело с управлением потоком и контролем ошибок ”
11.1. Необходимость управления потоком и контроля ошибок
317
обычной или объединенной сети (например, на уровне TCP), анализ становится
значительно более сложным и требует учета таких факторов, как переменная за-
держка распространения, переменная скорость передачи данных, влияние перегруз-
ки, вызванной подключениями к сети других источников трафика, влияние дина-
мического принятия решений о выборе маршрутов, относительные приоритеты
нескольких логических соединений и т. д. Кроме того, при разработке деталей
механизмов управления потоком и контроля ошибок в таких протоколах, как TCP,
важно получить возможность влиять на производительность управления потоком
и контроля ошибок на уровнях выше уровня передачи данных.
Поскольку тема анализа производительности потока на уровне передачи данных
и механизмов контроля ошибок столь важна, ей посвящается целая глава. В этом
относительно простом контексте можно вывести некоторые заключения о влия-
нии различных факторов на производительность управления потоком и контроля
ошибок. Эти заключения дают понимание, необходимое при анализе и разработке
механизмов управления потоком и контроля ошибок на более высоких протоколь-
ных уровнях.
Эта глава начинается с краткого обзора концепций управления потоком и конт-
роля ошибок. Затем описываются основные механизмы, используемые практичес-
ки во всех протоколах уровня передачи данных. Наконец, обсуждаются некоторые
примеры непосредственного влияния этих механизмов на производительность.
Знание этого вопроса будет полезно при чтении главы 12.
11.1. Необходимость управления
потоком и контроля ошибок
Управление потоком
Механизм управления потоком позволяет получателю регулировать поток прото-
кольных модулей данных, посылаемых отправителем. Управление потоком огра-
ничивает количество или скорость передачи посылаемых данных. Получающей
системе может потребоваться ограничивать поток по одной из нескольких причин.
♦ По прибытии каждого протокольного модуля данных получатель должен
определенным образом обработать его заголовок. Источник может попы-
таться посылать протокольные модули данных быстрее, чем получатель смо-
жет их обрабатывать.
+ Получающая сторона протокола может буферировать входящие данные для
доставки пользователю протокола более высокого уровня. Если этот пользо-
ватель медленно извлекает данные, буфер может переполниться и получа-
тель будет вынужден временно остановить поток данных от отправителя.
♦ Получатель может буферизовать входящие данные для передачи их по дру-
гому порту ввода-вывода (например, в случае моста, маршрутизатора или
узла сети с коммутацией пакетов), для чего ему также может потребоваться
ограничить входящий поток, чтобы тот соответствовал исходящему потоку.
318
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Первые две причины играют роль между оконечными системами, соединенны-
ми либо на уровне передачи данных (две оконечные системы, соединенные напря-
мую) или по сети. Последний случай относится к пересылке протокольных моду-
лей данных по коммутируемой сети (например, через узлы сети с коммутацией
пакетов) или по объединенной сети (например, через мосты и маршрутизаторы).
Управление потоком может выполняться на различных уровнях протокола
(рис. 11.1). Одним примером этого является случай нескольких виртуальных ка-
налов Х.25 (уровень 3), мультиплексированных в канале данных с помощью про-
токола LAPB (представляющего уровень 2 спецификации Х.25). В качестве дру-
гого примера можно назвать мультиплексирование нескольких ТСР-соединений
по каналу HDLC. В данном случае управление потоком осуществляется вдоль каж-
дого логического соединения на более высоком уровне независимо от управления
потоком в других соединениях. Поток суммарного трафика всех соединений так-
же управляется на более низком уровне.
Рис. 11.1. Управление потоком на нескольких протокольных уровнях
Изучение вопроса управления потоком также усложняется тем фактом, что этот
вопрос может упоминаться в различных контекстах, как поясняется на рис. И-2.
На рисунке показаны две оконечные системы, соединенные обычной или объеди-
ненной сетью. В случае обычной сети промежуточные системы представляют со-
бой индивидуальные сетевые узлы, например коммутаторы пакетов, кадров или
ATM-ячеек. В случае объединенной сети промежуточными системами, как прави-
ло, являются маршрутизаторы. Теперь мы кратко обсудим соотношение между
уровнем протокола, на котором осуществляется управление потоком, и областью
этого управления.
Контекст ретрансляционного участка
Между соединенными напрямую промежуточными системами управление пото-
ком может осуществляться на уровне передачи данных. Например, в случае сосе )
11.1. Необходимостьуправления потоком и контроля ошибок
319
них узлов сети с коммутацией пакетов используется протокол LAPB. Каждый узел
сети с коммутацией пакетов буферизирует входящие пакеты и направляет их по
соответствующей исходящей линии. Чтобы гарантировать, что буферы не перепол-
нились, в узле может применяться управление потоком протокола LAPB, ограни-
чивая объем входящего трафика. У правление потоком на уровне передачи данных
может также использоваться между соединенными напрямую маршрутизаторами
в объединенной сети. Опять же, маршрутизатор может использовать протокол
уровня передачи данных, например HDLC, чтобы ограничить объем входящих
дейтаграмм и избежать переполнения буфера.
От входа до выхода
Сквозной маршрут
Рис. 11.2. Область управления потоком
Сетевой интерфейс
Протокол уровня передачи данных также часто используется в интерфейсных ли-
ниях, соединяющих оконечную систему и обычную или объединенную сеть. Опять
же, в случае сети с коммутацией пакетов Х.25 протокол LAPB позволяет сети
ограничить суммарный поток пакетов от оконечных систем в сеть. В других сетях,
таких как сети ретрансляции кадров и сети ATM, на уровне передачи данных
управление потоком не осуществляется.
Управление потоком также может осуществляться на уровне сетевого прото-
кола в линиях сетевого интерфейса, то есть для индивидуальных логических со-
единений. В качестве общего примера такого управления потоком можно назвать
сеть стандарта Х.25, в которой управление потоком может осуществляться между
оконечной системой и сетью в каждом отдельном виртуальном канале.
От входа до выхода
В некоторых сетях управление потоком реализуется между входным и выходным
узлами логических соединений, например виртуальных каналов. Назначение
320 Глава 11. Управление потоком и контроль ошибок на уровне передачи дани!
управления потоком в данном контексте заключается в регулировании вхоптУ
трафика, чтобы избежать переполнения буферов в точке выхода. Детали этого 1|
ханизма прозрачны для конечных пользователей, но могут влиять на поток 41
пых по сетевому интерфейсу.
Сквозной контекст
Управление потоком может осуществляться в логических соединениях между око-
печными системами. Здесь цель управления потоком заключается в том, чтобы
получающая оконечная система могла регулировать входящий поток, избегая пе-
реполнения буферов и удовлетворяя требования приложений. Протокол TCP пре-
доставляет такое сквозное управление потоком по индивидуальным ТСР-соеди-
иениям между оконечными системами. Сквозное управление потоком может
также осуществляться на основе виртуальных каналов Х.25.
Сквозное управление потоком также часто применяется на уровне передачи
данных. Ниже перечислены некоторые примеры.
♦ В сети с коммутацией пакетов или в сети ATM, если протокол управления
каналом, например HDLC, реализован в оконечных системах, тогда он ра-
ботает в сквозном режиме.
+ Протокол LLC (Logical Link Control — управление логическим соединени-
ем), работающий в локальной сети, реализуется между оконечными систе-
мами. В этом случае управление потоком работает по логическим соедине-
ниям между оконечными системами.
♦ Управляющий протокол LAPF (Link Access Procedure for Frame Mode Bearer
Services — процедура доступа к каналу для канальных служб в режиме
кадров) обеспечивает использование механизмов управления потоком в
логических соединениях между оконечными системами в сети ретрансля-
ции кадров.
В случаях LLC и LAPF задержка распространения между оконечными систе-
мами является непостоянной, и поэтому метод анализа, представленный в разде-
ле 11.3, в этих случаях неприменим.
Контроль ошибок
Методы контроля ошибок используются для восстановления после потери или
повреждения протокольных модулей данных при их прохождении от отправителя
к получателю. Как правило, контроль ошибок включает обнаружение ошибок на
базе контрольной последовательности кадра (Frame Check Sequence, FCS) и по-
вторную передачу протокольного модуля данных. Контроль ошибок и управление
пот оком реализуются вместе в едином механизме, регулирующем поток прото
кольных модулей данных и определяющем, когда следует повторить передачу од
ного или нескольких протокольных модулей данных. Таким образом, контрол
ошибок, как п управление потоком, представляет собой функцию, реализуемут
на различных протокольных уровнях. f
11.2. Механизмы управления каналом
321
11.2. Механизмы управления каналом
Для управления потоком и контроля ошибок на уровне передачи данных, как пра-
вило, используются три метода: остановка с ожиданием, возврат на Лгшагов и се-
лективный отказ. Последние два метода представляют собой специальные случаи
техники скользящего окна. Мы рассмотрим все эти методы в данном разделе.
Представьте себе две оконечные системы, соединенные напрямую каналом
связи. Передающая система собирается послать сообщение или блок данных
отправителю. Данные посылаются не единым блоком, а разбиваются на последо-
вательность кадров. Эта процедура выполняется по одной или по нескольким из
перечисленных ниже причин:
4- Конечность размеров буфера получателя.
4- Чем дольше время передачи, тем выше вероятность ошибки, в результате
которой потребуется повторная передача целого кадра. При меньшем раз-
мере кадров ошибки выявляются быстрее, и меньшее количество данных
приходится передавать повторно.
4- В носителях коллективного доступа, например в локальных сетях, как пра-
вило, желательно не позволять одной станции долго занимать носитель, тем
самым заставляя ждать другие станции.
Остановка с ожиданием
Простейшая форма управления потоком, называемая управлением потоком с ос-
тановкой и ожиданием (stop and wait), работает следующим образом. Отправитель
передает кадр. Приняв его, получатель сообщает о своем желании принять другой
кадр, отсылая обратно подтверждение в получении данного кадра. Прежде чем
посылать следующий кадр, отправитель должен ждать подтверждения. Таким об-
разом, получатель может остановить поток данных, просто «придержав» подтвер-
ждение.
При такой схеме нужно учитывать два типа ошибок. Во-первых, прибывший
кадр может быть поврежден. Это значит, что в нем изменены несколько битов.
Чтобы получатель мог распознать подобную ошибку, кадр протокола передачи
данных содержит контрольную сумму кадра. Для этой цели, как правило, исполь-
зуется схема CRC (Cyclic Redundancy Check — контроль с помощью цикличе-
ского избыточного кода). В случае обнаружения ошибки получатель отбрасывает
кадр. Чтобы работа протокола не останавливалась в случае потери кадра или под-
тверждения, станция-источник оснащается таймером. Передав кадр, отправитель
начинает ждать подтверждения. Если в течение условленного срока подтвержде-
ние не получено, кадр пересылается еще раз. Обратите внимание на то, что при
этом методе отправитель должен хранить копию переданного кадра до тех пор,
пока не получит подтверждение для этого кадра.
Вторая разновидность ошибки представляет собой повреждение подтверждения.
Рассмотрим следующую ситуацию. Станция А посылает кадр. Этот кадр успешно
принимается станцией В, отвечающей отправкой подтверждения (ACKnowledgement,
322 Глава 11. Управление потоком и контроль ошибок на уровне передачи дан||
АСК). При передаче подтверждение повреждается и не распознается станцией^
которая в результате «устает ждать» и посылает этот кадр еще раз. Дубликат JI
ра снова успешно принимается станцией В. Таким образом, станция В получ~
две копии одного и того же кадра, как если бы это были два разных кадра. Чтооы
избежать ошибки, кадры данных поочередно нумеруются одним битом 0 и 1, а по-
ложительные подтверждения имеют вид АС КО и АСК1. Принято следующее со-
глашение об использовании подтверждений АСКО и АСК1. Подтверждение АСКО
удостоверяет получение кадра с номером 1 и указывает, что получатель готов
к приему кадра с номером 0. Подтверждение АСК1 удостоверяет получение кадра
с номером 0 и указывает, что получатель готов к приему кадра с номером 1.
С помощью механизмов обнаружения ошибок, таймеров, подтверждений и по-
вторных передач реализуется то, что называется автоматическим запросом на по-
вторение (Automatic Repetition Query, ARQ). Таким образом, описанный прото-
кол реализует технологию ARQ для остановки с ожиданием. Та же технология
ARQ применяется во всех методах управления потоком и контроля ошибок.
На рис. 11.3 приведен пример использования метода ARQ для остановки с ожи-
данием. На рисунке показана передача последовательности кадров от источника А
к приемнику В с вертикально расположенной осью времени. Такая схема удобна
для иллюстрирования временных зависимостей и взаимоотношений между от-
правителем и получателем. Каждая стрелка изображает передачу одного кадра по
каналу между двумя станциями. Данные посылаются в виде последовательности
кадров, при этом в каждом кадре содержатся как часть данных, так и управляю-
щая информация. Время, требующееся станции для передачи всех битов кадра по
носителю, называется временем передачи. Это время пропорционально длине
кадра. Время распространения представляет собой время, необходимое для того,
чтобы один бит информации прошел по каналу от отправителя до получателя.
На рисунке отражены два описанных ранее типа ошибок. Третий кадр, пере-
данный станцией А, теряется или повреждается, поэтому станция В не отправля-
ет подтверждение в ответ. У станции А истекает время ожидания, и она передает
этот кадр еще раз. Позднее станция А передает кадр, помеченный 1, но подтверж-
дение АСКО для этого кадра теряется. У станции А истекает время ожидания, и
она передает этот кадр еще раз. Получив два одинаково помеченных кадра подряд,
станция В отбрасывает второй кадр, но отправляет подтверждения АСКО к обоим
кадрам.
Метод остановки с ожиданием применяется редко, так как он неэффективен.
Причина неэффективности заключается в том, что станция может передавать дан-
ные только по одному кадру за раз. Если время распространения сигнала велико
по сравнению с временем передачи, тогда линия большую часть времени будет
простаивать. Эта ситуация показана на рис. 11.4. Последовательность событий
выглядит следующим образом:
1. В момент времени t - 0 станция А начинает передавать кадр.
2. Время передачи кадра равно Ткад1„ Таким образом, в момент времени t = Ткада
передан последний бит кадра. Если время распространения от станции А ДО
станции В превышает Ткад1„ тогда в этот момент времени все биты кадмГ
находятся в канале связи. /
11.2. Механизмы управления каналом
323
Подтверждение АСКО у
потеряно; ствнция А
повторяет передачу
Интервал Л
ожидания
Интервал
ожидания
Кадр 0 потерян;
станция А
повторяет передачу
Время передачи *
кадра , г
Время iк
распространения У
Время передачи
подтверждения
Станция В отбрасывает
дубликат кадра
Рис. 11.3. Запрос ARQ для остановки с ожиданием
Время распространения от станции А до станции В равно Трас,1Р. В момент
времени t = Граи1р первый бит кадра только что прибыл на станцию В, а ос-
тальные биты следуют за ним по каналу.
В момент времени t = Гкадр + Т^ср станция В приняла кадр целиком.
Предположим, что станция В немедленно отправляет подтверждение и что
интервал времени между получением кадра и отправкой подтверждения
пренебрежимо мал. Время передачи подтверждения равно Гаск- В этом слу-
чае к моменту’ времени t = Т^р + ТрМЩ, + 7аск подтверждение передано цели-
ком. Как правило, подтверждение (на рисунке заштриховано) значительно
короче кадра данных.
324 Глава 11. Управление потоком и контроль ошибок на уровне передачи данньг
6. В момент времени t = Tmv + 27'pacup первый бит подтверждения только чтвг*”^
прибыл на станцию А, а остальные биты следуют за ним по каналу. |1
7. В момент времени Г = Twp + 2Грх„р + ТАск станция А приняла подтверждение
целиком.
f=0
7"кадр
Траспр
7"кадр + Траспр
Надо + ^распр + ТдсК
Л<адр + ^Траспр
Рис. 11.4. Использование канала в методе остановки с ожиданием
бсадр + 27pacnp + ^АСК
в-
При рассмотрении такого сценария становится ясно, что линия загружена не-
достаточно. При отсутствии ошибок станция А могла бы передавать кадры со ско-
ростью 1/^ВДр. Но из-за необходимости ждать подтверждения максимальная ско-
рость передачи кадров уменьшается до 1/( Гкадр + 27’рас„р + ГАСк). Если время 7])ВСпр
велико по сравнению с Т^р, тогда использование такой схемы будет сильно сни-
жать производительность канала.
Технология скользящего окна
Суть описанной ранее проблемы состоит в том, что в каждый момент времени в ка-
нале может находиться только один кадр. В этом случае, если длина канала в битах
(соответствующая времени Гр.к„р) больше длины кадра (соответствующей времени
Екалр), канал используется неэффективно. Эффективность можно значительно по-
высить, если позволить одновременно находиться в канале нескольким кадрам.
Рассмотрим, как это будет работать в случае двух станций А и В, соединенньш1’
дуплексной линией. Станция В резервирует буферное пространство для п кадр'у
11.2. Механизмы управления каналом
325
Таким образом, станция В может принять п кадров, а станции А разрешается от-
править п кадров, не дожидаясь прихода подтверждений. Чтобы не запутаться,
который кадр подтверждается, каждый кадр помечается порядковым номером.
Станция В удостоверяет получение кадра, отправляя подтверждение, содержащее
порядковый номер следующего ожидаемого кадра. Это подтверждение также служит
неявным объявлением о том, что станция В готова принять следующие п кадров,
Начиная с указанного номера. Такая схема также может применяться для подтвер-
ждения получения нескольких кадров. Например, станция В может принять кад-
ры 2,3 и 4, но придержать подтверждения до тех пор, пока не придет кадр 4. Затем,
отослав подтверждение с порядковым номером 5, станция В тем самым одновре-
менно подтверждает получение кадров 2, 3 и 4. Станция А ведет список порядко-
вых номеров кадров, которые ей разрешается отправить, а станция В ведет список
номеров кадров, которые она готова принять. Каждый такой список можно рас-
сматривать как окно кадров, а вся схема реализует управление потоком с помо-
щью так называемого скользящего окна (sliding window).
Поскольку порядковый номер занимает поле в заголовке кадра, то, очевидно,
его размер ограничен. Например, в случае 3-битового поля порядковый номер мо-
жет принимать значения в диапазоне от 0 до 7. Соответственно, кадры нумеруют-
ся по модулю 8, то есть после кадра с номером 7 идет кадр 0. В общем случае для
^-битового поля порядковый номер может принимать значения в диапазоне от 0
до 2* - 1, а кадры нумеруются по модулю 2*. Работу' алгоритма скользящего окна
иллюстрирует рис. 11.5. На рисунке предполагается наличие 3-битового порядко-
вого номера. Затененный прямоугольник обозначает кадры, которые могут быть
переданы. В данном случае отправитель может передать пять кадров, начиная
с кадра 0. При отправке каждого кадра затененная область (скользящее окно)
уменьшается. При получении подтверждений размер области увеличивается. Кад-
ры между вертикальной линией и затененной областью переданы, но подтвержде-
ния для них еще не получены. Как мы увидим, отправитель должен хранить эти
кадры в буфере на случай, если понадобится их повторная передача.
Фактический размер окна не обязательно равен максимально возможному раз-
меру для данной длины поля порядкового номера. Например, при 3-битовом по-
рядковом номере станций, использующих протокол скользящего окна для управ-
ления потоком, размер окна может быть равным 4.
Пример показан на рис. 11.6. Здесь используется 3-битовое поле порядкового
номера и максимальный размер окна в семь кадров. Изначально окна станций А и В
Указывают на то, что станция А может передать семь кадров, начиная с кадра 0 (F0).
После передачи трех кадров (F0, Fl, F2) станция А, не дожидаясь подтверждений,
Уменьшает размер своего окна до четырех кадров и сохраняет копии трех послан-
ных кадров. В окне указывается, что станция А может отправить еще четыре кад-
ра, начиная с кадра номер 3. Затем станция В передает сообщение RR (Receive
Ready — готовность к приему) 3, что означает1 получение всех кадров вплоть до
Сообщение RR представляет собой отдельный управляющий кадр. Большинство протоколов пере-
дачи данных также допускают передачу подтверждений вместе с информационными кадрами. При
атом в каждый кадр данных включается не только порядковый номер этого кадра, но также порядко-
вый номер подтверждения, выполняющий ту же функцию, что и кадр RR. Таким образом, при дуп-
лексном обмене кадрами данных отдельные кадры RR используются редко.
326 Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
кадра 2 и готовность к приему семи кадров, начиная с кадра 3. Получив это под-
тверждение, станция А снова может передать семь кадров, начиная с кадра 3
Кроме того, станция А может очистить буфер с кадрами, получение которых под-
тверждено. Станция А продолжает передавать кадры 3, 4, 5 и 6. Станция В воз-
вращает RR 4, что подтверждает получение кадра F3, а также разрешает переда-
чу кадров с F4 по F2. К тому моменту, когда RR 4 достигнет станции А, она уже
передаст кадры F4, F5 и F6, и поэтому станция А может послать только четыре
кадра, начиная с F7.
Кадры, хранящиеся в буфере
и ожидающие подтверждения
Переданные кадры
Скользящее окно с кадрами,
которые могут быть переданы
Передающая сторона
Порядковый
номер кадра
По мере получения
подтверждений окно
спереди раздвигается
Последний
подтвержденный
кадр
По мере передачи
кадров окно сзади
сжимается
Последний
переданный кадр
Полученные кадры
Скользящее окно с кадрами,
которые могут быть приняты
> <-------------------►
кадр
Получающая сторона
Рис. 11.5. Иллюстрация алгоритма скользящего окна
В протоколах уровня передачи данных применяются две схемы скользящего
окна: запрос ARQ с возвратом на N шагов и запрос ARQ с селективным отказом.
Эти схемы различаются способом обработки ошибок.
Рис. 11.6. Пример работы протокола скользящего окна
328
Глава 11, Управление потоком и контроль ошибок на уровне передачи данных
Схема ARQ с возвратом на Л/ шагов
Наиболее часто употребляемая форма контроля ошибок, основанная на управле-
нии потоком при помощи скользящего окна, называется автоматическим запро-
сом на повторение с возвратом на Лг шагов. В этом методе станция может послать
серию кадров, последовательно пронумерованных по модулю какого-либо макси-
мального значения. Количество неподтвержденных кадров определяется размером
окна с помощью метода скользящего окна для управления потоком. При отсут-
ствии ошибок получатель будет подтверждать принятые кадры как обычно (сооб-
щениями RR или подтверждениями «на попутных» модулях данных). Если полу-
чающая станция обнаруживает в кадре ошибку, она может послать отрицательное
подтверждение REJ (REJect — отказ) для этого кадра, как поясняется в следующих
правилах. Получающая станция отбросит этот кадр и все последующие входящие
кадры, пока не примет правильную копию ошибочного кадра. Таким образом, пе-
редающая станция, получив сообщение REJ, должна передать повторно ошибоч-
ный кадр, а также все последующие кадры, которые она уже успела передать.
Предположим, что станция А передает кадры станции В. После передачи каж-
дого кадра станция А запускает таймер ожидания подтверждения для только что
переданного кадра. Предположим, что станция В в последний раз успешно полу-
чила кадр с номером (г - 1), а станция А только что передала кадр с номером г.
В методе возврата на N шагов учитываются следующие обстоятельства:
1. Поврежден кадр данных. Если полученный кадр поврежден (например, стан-
ция В обнаруживает ошибку или кадр поврежден настолько, что станция В
даже не может определить, что приняла кадр), то станция В отбрасывает
кадр и более не предпринимает никаких действий. Здесь возможны два ва-
рианта действий:
а) через умеренный интервал времени станция А передает кадр с номером
(г + 1). Станция В получает кадр с номером (г + 1) и, так как он пришел с
нарушением порядка номеров, отвечает сообщением REJ г. Станция А
должна повторить передачу кадра i и всех последующих кадров;
б) станция А не посылает дополнительных кадров в течение данного ин-
тервала времени. Станция В ничего не получает и в результате ничего не
отправляет в ответ — ни RR, ни REJ. Когда у станции А истекает пери-
од ожидания, она передает кадр RR, в котором бит Р установлен в 1.
Станция В интерпретирует кадр RR с битом Р, установленным в 1, как
команду, в ответ на которую следует выслать сообщение RR с номером
следующего кадра, ожидаемого станцией, то есть кадра г. Получив кадр RR>
станция А повторяет передачу кадра г. В качестве альтернативы стан-
ция А может просто повторить передачу кадра г, когда ее интервал ожи-
дания истечет.
2. Поврежден кадр с сообщением RR. Тут может быть два варианта:
а) станция В получает кадр г и отвечает кадром с подтверждением RR (г + 1),
который повреждается при передаче. Поскольку подтверждения являют-
ся кумулятивными (например, RR 6 означает, что подтверждается полу-
чение всех кадров вплоть до кадра 5), может случиться так, что станция А
11.2. Механизмы управления каналом
329
получит более поздний кадр с подтверждением RR для более позднего
кадра и что этот кадр с подтверждением RR придет раньше, чем истечет
период ожидания подтверждения для кадра г;
б) если у станции А истекает период ожидания, она передает команду RR,
как в случае 16. При этом она запускает другой таймер, называемый
таймером бита Р. Если станция В не отвечает на команду RR или ответ
повреждается при передаче, тогда срабатывает таймер бита Р станции А.
В этом случае станция А повторяет попытку отправить команду RR, пе-
резапуская таймер бита Р. Таким образом, станция А повторяет попыт-
ку связаться со станцией В определенное количество раз. Если ответ от
станции В так и не приходит, станция А начинает процедуру установки
соединения.
3. Поврежден кадр с сообщением REJ. Если теряется кадр с негативным под-
тверждением REJ, то этот случай эквивалентен случаю 16.
На рис. 11.7, а показан пример потока кадров для метода ARQ с возвратом на N
шагов. В связи с задержкой распространения сигнала по линии к тому моменту,
когда подтверждение (положительное или отрицательное) прибывает к станции-
отправителю, эта станция уже успевает послать по меньшей мере еще один кадр
сверх подтвержденных. В данном примере кадр 4 поврежден. Кадры 5 и 6 прихо-
дят в обратном порядке и отбрасываются станцией В. Когда прибывает кадр 5,
станция В немедленно посылает кадр REJ 4. Когда станция А получает REJ 4, она
должна повторить передачу не только кадра 4, но и кадров 5 и 6. Обратите внима-
ние на то, что отправитель должен хранить копии всех неподтвержденных кадров.
Схема ARQ с селективным отказом
В схеме автоматического запроса на повторение с селективным отказом повторно
передаются только те кадры, для которых отправитель получает отрицательное
подтверждение, называемое в данном случае SREJ (Selective REJect — селектив-
ный отказ), а также кадры, время ожидания подтверждения для которых истекло.
Эту схему иллюстрирует рис. 11.7,6. Когда кадр 5 приходит с нарушением порядка,
станция В посылает команду SREJ 4, сообщая таким образом, что она не получила
кадр 4. Тем не менее, станция В продолжает принимать входящие кадры и разме-
щать их в буфере, пока не будет получен кадр 4. В этот момент станция В может
расположить все полученные кадры в правильном порядке для доставки их про-
граммному обеспечению более высокого уровня.
Алгоритм селективного отказа кажется более эффективным, чем схема с воз-
вратом на N шагов, так как он позволяет минимизировать количество повторно
передаваемых кадров. С другой стороны, получатель должен управлять буфером,
достаточно большим, чтобы сохранять все кадры, полученные после отправки им
команды SREJ, до тех пор пока ошибочный кадр не будет передан повторно. Так-
же получатель должен сам расставлять получаемые кадры в правильном порядке.
Отправитель также должен обладать более сложной логикой, позволяющей пе-
редавать кадры не по порядку. В связи с его большей сложностью алгоритм се-
лективного отказа получил значительно меньшее распространение, чем схема воз-
врата на N шагов.
330 Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Рис. 11.7. Протоколы скользящего окна для схемы автоматического запроса на повторение
11.3. Производительность схемы ARQ
В этом разделе мы исследуем вопросы производительности методов автоматичес-
кого запроса на повторение для двухточечной линии. Данный раздел начинается
с обзора алгоритма ARQ с остановкой и ожиданием. Затем мы определим важный
11.3. Производительность схемы ARQ
331
параметр, как правило, называемый параметром а, отражающий суть характерис-
тик производительности канала связи. Использование этого параметра упрощает
представление о производительности алгоритмов возврата на Nшагов и селектив-
ного отказа.
Схема ARQ с остановкой и ожиданием
Сначала мы рассмотрим вопросы производительности алгоритма управления по-
током с остановкой и ожиданием в предположении об отсутствии ошибок, а затем
учтем наличие ошибок.
Схема с остановкой и ожиданием при отсутствии ошибок
Нам требуется определить максимальную скорость, с которой можно передавать
кадры по линии с помощью схемы управления потоком с остановкой и ожидани-
ем при отсутствии ошибок. Предположим, что станция А передает станции В длин-
ное сообщение в виде последовательности кадров F,, F2,..., F„ следующим образом:
♦ Станция А посылает кадр F(.
♦ Станция В посылает подтверждение.
♦ Станция А посылает кадр F2.
♦ Станция В посылает подтверждение.
4- ...
♦ Станция А посылает кадр Fn.
♦ Станция В посылает подтверждение.
Суммарное время, необходимое для передачи данных, можно выразить как пТ,
где Т— это время, требующееся, чтобы передать один кадр, получить подтвержде-
ние и подготовиться к передаче следующего кадра. Формула для Т выглядит сле-
дующим образом (см. рис. 11.4):
Т= ГкаЛр + Траспр + Г(„',р + Tack + Грасир + Г/,р.
Здесь:
4 7кадр — время, требующееся для передачи кадра (время, за которое передат-
чик передает все биты кадра);
4- Грас,,., — время распространения сигнала между станциями А и В (в любом
направлении);
4- Г„бр — время обработки данных на каждой станции (время реагирования);
4- Гаск — время, требующееся для передачи подтверждения.
Предположим, что время обработки является относительно пренебрежимо ма-
лым и что кадр подтверждения очень мал по сравнению с кадром данных. Оба эти
предположения вполне обоснованны. Кроме того, предположим, что все кадры име-
ют фиксированный размер. В этом случае алгоритм управления потоком с оста-
новкой и ожиданием позволяет передавать данные со скоростью в один кадр каж-
дые Г секунд, где Г приблизительно равно
Г= Гкадр + 2Гобр.
332
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Таким образом, пропускную способность можно вычислить по формуле 1/Т=
= 1/(Т|<а,гР + 2ГобР) кадров в секунду. Для сравнения желательно выразить пропуск-
ную способность в нормализованном виде. Если кадр можно передать за ГкмР секунд
тогда фактическая скорость передачи данных в канале равна 1/Твд1р кадров в се-
кунду. Таким образом, нормализованная пропускная способность 5 может быть
выражена следующей формулой:
1/ГТ +2Т 1 Т
$ I \ кадр распр / кадр
~ 1/Т Т + 2Т
/ кадр кадр распр
Если этот вывод неясен, рассмотрим следующее. Пусть скорость передачи дан-
ных по каналу в битах в секунду равна R, а длина кадра в битах равна L. В этом
случае пропускная способность канала в битах в секунду будет равна (£ бит/кадр)
(1/Гкадров в секунду) = £/(Ткадр + 2ТовР). Чтобы нормализовать пропускную спо-
собность, разделим ее на фактическую скорость передачи данных:
с £/(7^ + 27^)
(ИЛ)
(И.2)
R
Заменив ТкаЛ}, = L/R, мы получим формулу (11.1). Полезно ввести параметр
а — Траспр/Ткадр* В этом случае
5 = —-^—
1 + 2д
Это максимально возможная нормализованная пропускная способность по ка-
налу при использовании алгоритма с остановкой и ожиданием. Поскольку кадр
содержит служебные биты, эффективная пропускная способность оказывается
ниже. Параметр а является константой, если оба значения, Грас11р и TKiVlf, — констан-
ты, что, как правило, соответствует действительности. Кадры фиксированной дли-
ны (кроме последнего кадра) часто применяются для передачи длинных сообще-
ний, а время распространения сигнала постоянно для двухточечных соединений.
Схема с остановкой и ожиданием при наличии ошибок
Рассмотрим еще раз рис. 11.4. Время, требующееся для успешной передачи кадра,
равно (Гкддр + 27'распр). Теперь предположим, что кадр потерян или его подтвержде-
ние потеряно и для успешной передачи кадра требуются две попытки. В этом слу-
чае время передачи кадра равно
Т = Ткалр + ВремяОжидания + Ткалр + 2Грас||р.
Чтобы упростить формулу, предположим, что значение времени ожидания рав-
но удвоенному времени распространения сигнала. Таким образом, если станция
не получает подтверждения в течение удвоенного времени распространения сиг-
нала, она повторяет передачу кадра. В действительности следует использовать не-
много больший интервал времени, чтобы учесть время обработки у получателя,
но наше приближение вполне приемлемо. Таким образом, время, требующееся для
передачи кадра, который должен быть передан дважды, равно
Т=2(ТК1Лр+2Грас|,Р).
11.3. Производительность схемы ARQ
333
\ В общем случае, если кадр повреждается или теряется (х - 1) раз подряд так,
\что он для успешной доставки должен быть передан х раз, время, затрачиваемое
да передачу этого кадра, равно х(Т'ка7,р + 27]^,,,,). Если ввести обозначение М, рав-
ное среднему количеству раз, которое приходится передавать каждый кадр, тогда
среднее время, требующееся для успешной передачи кадра, равно
Г=М(7'кадр + 27'распр).
Применяя те же преобразования, что и раньше, получим значение нормализо-
ванной пропускной способности:
________ кадр_______ ______________
Nx(TK^+2Tpxnp)~ Nx(l + 2a)'
(И.З)
Значение № несложно получить, зная значение вероятности Р повреждения
отдельного кадра. Если мы предположим, что подтверждения никогда не повреж-
даются, то вероятность ровно k попыток успешной передачи кадра равна вероят-
ности (k - 1) неуспешных попыток, за которыми последует одна успешная попыт-
ка. Вероятность этого равна произведению вероятностей отдельных событий:
Рг[ровно k попыток] = Рг| (k - 1) неуспешных попыток]Рг[успешпой
попытки] =Р*-’(1 - Р)
Таким образом1:
Nx = Е[передач] = (iPr[i передач]) = £ (гР‘ 1 (1 - Р) = -
1=1 1 = 1 1 — г
Если подставить это значение Nx в формулу (11.3), мы получим следующее
выражение для пропускной способности алгоритма остановки с ожиданием:
Параметр а
Ранее в этом разделе параметр а был определен следующим образом:
_ Время распространения (114)
Время передачи
Этот параметр очень полезен для оценки производительности различных ал-
горитмов уровня передачи данных, он также помогает понять, какие факторы вли-
яют на производительность. Формулу (11.4) можно записать иначе, используя сле-
дующие переменные:
♦ d — длина канала связи между двумя станциями;
♦ о — скорость распространения сигнала по каналу связи (при беспроводной
передаче по воздуху или в космосе это скорость света в вакууме, то есть
1 В этой формуле используется равенство 2}(тА"ч) = --— для
аад Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
3 • 108 м/с, при передаче по оптоволоконному кабелю эта скорость близка
к скорости света в вакууме, а при передаче по медному проводу она приблгн
зительно равна 0,67 скорости света в вакууме);
♦ L — длина кадра уровня передачи данных в битах (сейчас мы будем считать
что длина кадров постоянна);
♦ R — скорость передачи данных по каналу в битах в секунду.
Время распространения сигнала равно длине канала d, деленной на скорость
распространения п. Время передачи равно длине кадра в битах L, деленной на ско-
рость передачи данных R. Поэтому
d / v Rd
а -----------
L / R vL
Таким образом, для кадров фиксированной длины параметр а пропорционален
скорости передачи данных, умноженной на длину носителя. Параметр а удобно
представлять как отношение длины носителя в битах | R — ) к длине кадра (£)
I v)
В соответствии с этим представлением рис. 11.8 иллюстрирует формулу (11.2).
На рисунке время передачи кадра приравнено к 1, поэтому время распростране-
ния сигнала, согласно формуле (11.4), равно а. В случае, если а > 1, длина канала
в битах превосходит длину кадра. Это продемонстрировано на рис. 11.8, а, который,
по сути, повторяет рис. 11.4, но в данном случае время передачи подтверждения
игнорируется. Станция А начинает передавать кадр в момент времени 0. В момент
времени t = 1 станция А завершает передачу. В момент времени t = 1 + а станция В
принимает кадр целиком и тут же передает маленький кадр подтверждения. Это
подтверждение прибывает на станцию А в момент времени t = 1 + 2а. Таким обра-
зом, суммарное время, требующееся на передачу одного кадра, равно 1 + 2а, а ско-
рость передачи кадров равна 1/(1 + 2а). При а < 1 мы получим тот же результат,
как показано на рис. 11.8, б.
Рассмотрим несколько примеров. Пусть имеется глобальная сеть, использую-
щая технологию ATM, с двумя станциями, разнесенными на расстояние 1000 км.
Размер кадра стандарта ATM (называемого ячейкой) равен 424 бит. Одна из
стандартизированных скоростей передачи данных составляет 155,52 Мбит/с.
Таким образом, время передачи равно 424/(155,52 • 10е) = 2,7 • 10~6с. Если рас-
смотреть передачу данных по оптоволоконному каналу, то в этом случае время
распространения сигнала равно (10е м)/(2 • 108 м/с) = 0,5 • 10‘2 с. Таким образом,
а = (0,5 • 10 2)/(2,7 • 10 6) ~ 1850, а нормализованная пропускная способность со-
ставляет всего 1/3701 = 0,00027.
Другую крайность, в смысле расстояний, представляет собой локальная сеть.
Расстояния в локальных сетях варьируются от 0,1 км до 10 км, а скорости переда-
чи данных — от 10 Мбит/с до 1 Гбит/с. Как правило, более высокие скорости
используются на более коротких расстояниях. Если принять значение скоро-
сти R = 2 • 108 м/с, размер кадра равным 1000 бит и скорость передачи данных
10 Мбит/с, то мы получим параметр а в диапазоне от 0,005 до 0,5. Это соответ-
11-3. Производительность схемы ARQ
335
ствует нормализованной пропускной способности в диапазоне от 0,5 до 0,911. Для
100-мегабитной локальной сети возможно достижение сопоставимого коэффици-
ента использования при более коротких линиях связи.
а
а
Е
to + 1 + а
Е
б
а
Рис. 11.8. Временная диаграмма схемы остановки с ожиданием
Таким образом, локальные сети, как правило, довольно эффективны, тогда как
высокоскоростные глобальные сети — нет. В качестве последнего примера рассмот-
рим передачу данных по телефонной линии с помощью модема. Типичная скорость
передачи данных составляет 28,8 Кбит/с. Снова рассмотрим 1000-битовый кадр.
Длина линии может быть от нескольких десятков метров до тысяч километров.
Пусть расстояние будет коротким: d = 1000 м. Тогда
а = (28,800 бит/с 1000 м)/(2 • 10* * 8 м/с • 1000 бит) = 1,44 - 10Л
а нормализованная пропускная способность практически равна 1,0. Даже при боль-
ших расстояниях, например при d = 5000 км, мы получим
а = (28 800 • 5 • 10с)/(2 108 • 1000 бит) = 0,72
и нормализованную пропускную способность, равную 0,4.
В табл. 11.1 приводятся некоторые значения параметра а. Первая группа рядов
соответствует линии ISDN со скоростью передачи данных 64 Кбит/с. Расстояние
в 35 863 км соответствует спутниковому каналу связи. Во второй группе рядов
содержатся значения, типичные для линий сети ретрансляции кадров, и последняя
группа соответствует линиям локальных сетей.
336
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Таблица 11.1. Некоторые значения параметра а
Скорость передачи данных, Мбит/с Размер кадра, бит Расстояние,км а
Линии ISDN со скоростью передачи данных 64 Кбит/с ———
0,064 1000 0,1 0,0003
0,064 1000 1 0,003
0,064 1000 35 863 7.65
0,064 10 000 0,1 0,000003
0,064 10 000 1 0,00003
0,064 Линии сетей ретрансляции кадров 10 000 35 863 0,77
1 1000 1 0,005
1 1000 3000 15
1 1000 35 863 119,5
1 10 000 1 0,0005
1 10 000 3000 1,5
1 10 000 35 863 11,95
Линии локальных сетей
10 1000 0,05 0,0025
10 1000 0,5 0,025
10 10 000 0,05 0,00025
10 10 000 0,5 0,0025
100 1000 0,1 0,05
100 10 000 0,1 0,005
1000 1000 0,1 0,5
1000 10 000 0,1 0,05
Еще раз про схему с остановкой и ожиданием
Обе представленные диаграммы (см. рис. 11.8, а и б) состоят из последовательнос-
ти кадров, отражающих состояние процесса передачи данных. В обоих случаях пер-
вые три кадра показывают процесс передачи кадра с данными, а последние два —
возврат маленького кадра подтверждения. Обратите внимание на то, что для а > 1
линия всегда недоиспользуется, и даже для а < 1 линия используется неэффек-
тивно. В самом деле, при очень больших скоростях передачи данных и очень боль-
ших расстояниях между отправителем и получателем метод управления потоком
с остановкой и ожиданием не обеспечивает эффективного использования линии.
Чтобы понять, как параметр а влияет на нормализованную производительность,
мы можем начертить зависимость 5= (1 - Р)/(1 + 2а). Хотя значение S зависит от
Р, к счастью, параметр Р появляется только в выражении (1 - Р), так что Р не будет
оказывать заметного влияния на результат в широком диапазоне значений Р. Мы
будем использовать значение Р= 10~3.
На рис. 11.9 показан график производительности для схемы ARQ с остановкой
и ожиданием как функции параметра а. При а > 1 производительность резко па-
дает. При а > 10 алгоритм с остановкой и ожиданием настолько неэффективен, что
11.3. Производительность схемы ARQ
337
практически бесполезен. Этот график также иллюстрирует зависимость парамет-
ра а от скорости передачи данных, расстояния и размера кадра.
Рис. 11.9. Производительность протокола с остановкой и ожиданием (Р= 10 3)
Схема ARQ для скользящего окна
Как и ранее, мы начнем с рассмотрения работы алгоритма в отсутствие ошибок.
При этом работа данного алгоритма не отличается от работы алгоритмов ARQ
с возвратом на N шагов и с селективным отказом.
Управление потоком в схеме скользящего окна
при отсутствии ошибок
При управлении потоком по схеме скользящего окна пропускная способность ли-
нии зависит как от размера окна W, так и от значения параметра а. Для удобства
мы снова нормализуем время передачи кадра, приняв его за 1; при этом время рас-
пространения сигнала будет равно а. Рисунок 11.10 иллюстрирует эффективность
Дуплексной двухточечной линии. Станция А начинает передачу последовательно-
сти кадров в момент времени 0. Передний край первого кадра достигает станции В
338
Глава 11, Управление потоком и контроль ошибок на уровне передачи данных
в момент времени t = а. Первый кадр полностью принимается станцией В в момент
времени t = а + 1. Если предположить, что время обработки пренебрежимо мало
станция В может немедленно подтвердить получение первого кадра (АСК1)
W
W>2a+ 1
(=0
Кадр а
Кадр 3 Т
а + 1
А
Кадр УУ | Кадр(УУ-1) | |Кадр (W-а + 2)|Кадр (W-а + 1)
2а + 1
Г~Кадр (а > 2) j c
W<2a + 1
А
б
Рис. 11.10. Временная диаграмма протокола скользящего окна
11.3. Производительность схемы ARQ 339
Допустим также, что кадр подтверждения так мал, что время, требующееся для его
передачи, тоже пренебрежимо мало. В этом случае кадр подтверждения АСК1
достигнет станции А в момент времени t=2a+ 1. Чтобы рассчитать производи-
тельность, нам нужно рассмотреть два случая:
♦ W>2a+ 1. Подтверждение для кадра 1 достигает станции А прежде, чем у
станции А окно «сойдет на нет». Таким образом, станция А может переда-
вать без пауз, и нормализованная пропускная способность равна 1,0.
♦ W< 2а + 1. Окно станции А иссякает в момент времени t = W, поэтому она не
может передавать кадры до момента времени t = 2а + 1. Таким образом, норма-
лизованная пропускная способность равна размеру окна W, деленному на 2а + 1.
Итак, мы можем утверждать, что
l,W>2a + l,
W
2а +1
W<2a + 1.
(11-5)
Как правило, порядковый номер передается в «-битовом поле, и максимальный
размер окна равен W=2"~ 1. На рис. 11.11 показана зависимость максимальной
пропускной способности, достижимой для окон размером 1,7 и 127, от параметра а.
Окно размером 1 соответствует простому алгоритму остановки с ожиданием. Окно
размером 7 (3 бита) годится для многих приложений. Окно размером 127 (7 бит)
позволяет получить большую производительность для больших значений парамет-
ра а и применимо, например, для высокоскоростных глобальных сетей.
Рис. 11.11. Зависимость производительности протокола скользящего окна от параметра а
340
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Схема ARQ с селективным отказом
Для протокола скользящего окна формула (11.5) соответствует работе в отсут-
ствии ошибок. Для алгоритма ARQ с селективным отказом мы можем использо-
вать те же рассуждения, что и для алгоритма ARQ с возвратом на Nшагов. То есть
уравнения для случая без ошибок нужно разделить на №, где № = 1/(1 - Р). По-
этому мы должны умножить правую часть равенства (11.5) па (1 - Р), В результа-
те мы получим:
' 1 - Р, W > 2а + 1,
5= ИД1-Р)
, W<2a + i.
2а +1
Схема ARQ с возвратом на N шагов
Те же рассуждения применимы для алгоритма ARQ с возвратом на N шагов, но
мы должны быть осторожнее при определении №. Каждая ошибка вызывает по-
вторную передачу не одного кадра, а К кадров. Поэтому
Nr= Е[число кадров, переданных для успешной передачи
одного кадра] = 5}/(i)P'"'(l - Р).
Здесь /(г) представляет собой суммарное количество переданных кадров при
условии, что оригинальный кадр должен быть передан г раз. Это может быть вы-
ражено следующим образом:
f(i) = 1 + (г- 1)А'=(1- K) + Ki.
Если произвести подстановку, мы получим1:
= (1 - /С)£ Р'-1 (1 - Р) + К J гР'-1 (1-Р) = 1- ^ + -А_ = 1 Р_+рКР.
Изучая временную диаграмму на рис. 11.10, читатель может прийти к выводу,
что для W>2a+ 1 значение К приблизительно равно (2а + 1), а для W < 2а + 1 зна-
чение К равно IE. Таким образом,
1-Р
, „ .1У>2а + 1,
1 + 2аР
Обратите внимание на то, что при П/7= 1 как алгоритм селективного отказа, так
и алгоритм возврата на Атагов вырождаются в простую схему с остановкой и ожи-
данием. На рис. 11.12 сравниваются три зависимости пропускной способности от
параметра а для этих трех методов контроля ошибок. Во всех случаях использует-
ся значение Р= 10-3. Эти графики и формулы являются только приближениями.
ж 1
' В этой формуле используется равенство = -
11.4. Протокол HDLC
341
Например, мы игнорировали ошибки в кадрах подтверждений, а для алгоритма
возврата на N шагов игнорировались ошибки в кадрах, передаваемых повторно
вместе с оригинальным кадром. Однако результаты дают представление об отно-
сительной производительности трех методов.
Рис. 11.12. Зависимость производительности методов ARQ от параметра а
Наконец, на рис. 11.13 показана зависимость нормализованной пропускной
способности трех методов ARQ от размера окна 17 для а = 10 и а = 100.
11.4. Протокол HDLC
Наиболее важным протоколом уровня передачи данных является протокол HDLC
(High-level Data Link Control — высокоуровневый протокол управления каналом),
определенный международными стандартами ISO 3009 и ISO 4335. Протокол HDLC
не только широко применяется, но он также служит основой для многих других
протоколов, использующих те же или сходные форматы кадров и те же механиз-
мы, которые реализованы в протоколе HDLC.
Структура кадра протокола HDLC
Возможно, лучше всего начать обсуждение протокола HDLC с его структуры кад-
ра. Работа протокола HDLC включает обмен между двумя соединенными станци-
ями информацией двух видов. Во-первых, протокол HDLC принимает данные от
342 Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
более высокого уровня программного обеспечения н доставляет эти данные по ка-
налу другой стороне. На другой стороне канала протокол HDLC принимает дан-
ные из канала и доставляет их более высокому уровню программного обеспече-
ния этой стороны. Во-вторых, два модуля протокола HDLC должны обмениваться
управляющей информацией, обеспечивая управление потоком, контроль ошибок
и другие управляющие функции. Для этого служит метод, заключающийся в фор-
матировании информации, обмен которой выполняется в кадре (frame). Кадр пред-
ставляет собой заранее определенную структуру, в которой предусмотрены места
для разных видов управляющей информации и данных пользователя.
Рис. 11.13. Зависимость производительности методов ARQ от размера окна IV
Формат кадра HDLC, поля которого перечислены далее, представлен на рис. 11.14, а.
4 Флаг используется для синхронизации. Он имеется в начале и в конце кад-
ра и всегда содержит последовательность битов 01111110.
4 Адрес определяет станцию-получатель для этой передачи. Он нужен в слу-
чае многоточечной линии, в которой исходная станция может отправить
данные одной из многих станций, а одна из этих станций может направить
данные исходной станции. Как правило, размер этого поля составляет 8 бит,
но может использоваться и расширенное поле адреса (рис. 11.14, б).
4 Управляющее поле определяет назначение и функции кадра. Оно описыва-
ется далее в этом разделе.
4 Информационное поле содержит передаваемые данные пользователя.
4 Поле CRC содержит 16- или 32-разрядный код CRC (Cyclic Redundancy
Check — контроль с помощью циклического избыточного кода), используе-
мый для обнаружения ошибок.
11,4. Протокол HDLC
343
Помимо названий этих полей на рисунке используются следующие обозначения:
+ N(S) — порядковый номер передачи;
♦ N(R) — порядковый номер приема;
4- S — контрольные функциональные биты;
4- М — ненумерованные функциональные биты;
4 P/F — бит опроса либо последний бит.
4- 8 -Х- 8 X 8 или 16-X—Переменное ► <— 8 или 32—► 8 -►
Биты Расширяемое
Формат кадра
123456789 1011 1213141516
Расширенное поле адреса
б
Информационный кадр
Контрольный кадр
Ненумерованный кадр
Формат 8-разрядного управляющего поля
в
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Информационное поле
Управляющее поле J O S ООО 0 P/F N(R) , j
а
Формат 16-разрядного управляющего поля
а
Рис. 11.14. Структура кадра HDLC
Стандартом HDLC определены три типа кадров, каждый со своим форматом
управляющего поля. Информационные (information) кадры, или 1-кадры, содер-
жат данные пользователя, передаваемые другой станции. Кроме того, в информа-
344
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
ционных кадрах содержится управляющая информация для контроля ошибок и
управления потоком. Контрольные (supervisory') кадры, или S-кадры, обеспечива-
ют другие средства управления потоком и контроля ошибок. Ненумерованные
(unnumbered) кадры, или U-кадры, обеспечивают дополнительные функции по
управлению каналом.
Первые один или два бита управляющего поля служат для идентификации типа
кадра. Остальные биты организованы в подполя (см. следующий подраздел), как
показано на рис. 11.14, я и г. Обратите внимание на то, что в основном управляю-
щем поле для S-кадров и 1-кадров используются 3-битовые порядковые номера.
С помощью соответствующих команд режима настройки могут применяться рас-
ширенные управляющие поля с 7-битовыми порядковыми номерами.
Управляющее поле всех форматов содержит бит P/F. Его значение зависит от
контекста. Как правило, в управляющих кадрах он называется P-битом (poll —
опрос) и устанавливается в 1 для запроса кадра ответа от одноранговой сущности
протокола HDLC. В ответных кадрах этот бит называется F-битом (final — послед-
ний) и устанавливается в 1 для обозначения кадра, переданного в ответ на ко-
манду запроса.
Работа протокола HDLC
Работа протокола HDLC заключается в обмене 1-кадрами, S-кадрами и U-кадра-
ми между двумя станциями. Разные команды и ответы, определенные для этих
типов кадров, перечислены в табл. 11.2.
Таблица 11.2. Команды и ответы HDLC
Назаание Команда/ Ответ Описание
Информационный кадр Контрольный кадр К/О Обмен данными пользователя
RR (готов к приему) к/о Положительное подтверждение; готовность к приему I-кадра
RNR (не готов к приему) неготовность к приему 1-кадра К/О Положительное подтверждение;
REJ (отказ) к/о Отрицательное подтверждение; возврат на N шагов
SREJ (выборочный отказ) Ненумерованный кадр к/о Отрицательное подтверждение; селективный отказ
SNRM/SNRME (обычный режим ответа/расширенный режим) к Установка режима; для расширенного режима порядковые номера 7-битовые
SARM/SARME (асинхронный режим ответа/расширенный режим) к Установка режима; для расширенного режима порядковые номера 7-битовые
SABM/SABME (асинхронный сбалансированный режим/ расширенный режим) к Установка режима; для расширенного режима порядковые номера 7-битовые
11.4. Протокол HDLC
345
Название Команда/ Отает Описание
SIM (режим инициализации) К Инициализировать функции управления каналом на адресуемой станции
DISC (разрыв соединения) К Разорвать соединение уровня передачи данных
UA (ненумерованное подтверждение) О Подтверждение получения одной из команд установки режима
DM (разъединенный режим) О Станция-ответчик находится в разъединенном режиме
RD (запрос разъединения) О Запрос команды DISC
RIM (запрос режима инициализации) О Требуется инициализация; запрос команды SIM
UI (ненумерованный информационный кадр) к/о Используется для обмена управляющей информацией
UP (ненумерованный опрос) к Используется для запроса управляющей информации
RSET (сброс) к Используется для восстановления; сбрасывает поля N(R), N(S)
XID (обмен идентификаторами) к/о Используется для запроса/ответа состояния
TEST (тест) к/о Обмен идентичными информационными полями для проверки
FRMR (отказ от кадра) О Сообщение о получении неприемлемого кадра
Работа протокола HDLC включает три фазы. Сначала одна из сторон инициали-
зирует канал передачи данных, чтобы обмениваться кадрами регулярным образом.
На этом этапе стороны договариваются о параметрах, которые они будут исполь-
зовать. После инициализации две стороны обмениваются данными пользователя
и управляющей информацией для контроля ошибок и управления потоком. Нако-
нец, одна из станций сигнализирует о завершении работы.
Инициализация
Инициализация может быть запрошена любой стороной путем передачи одной из
шести команд установки режима. Эта команда служит трем целям:
4- Она сигнализирует другой станции о запросе инициализации.
4 Она сообщает, какой из трех режимов требуется. Эти режимы определяют,
является ли одна из двух станций главной, управляющей обменом, или обе
стороны соединения являются одноранговыми и сотрудничают при обмене.
4 Она указывает, какие (3-битовые или 7-битовые) порядковые номера долж-
ны использоваться.
Если другая сторона принимает запрос, тогда модуль HDLC на этом конце пе-
редает кадр UA (Unnumbered Acknowledgement — ненумерованное подтвержде-
ние) обратно стороне-инициатору. Если запрос отвергнут, тогда посылается кадр
DM (Disconnected Mode — разъединенный режим).
346
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
Перенос данных
Когда инициализация запрошена и принята, устанавливается логическое соеди-
нение. Обе стороны могут начинать передачу данных пользователя в 1-кадрах, на-
чиная с кадра с порядковым номером 0. Поля N(S) и N(R) 1-кадра представляют
собой порядковые номера, обеспечивающие управление потоком и контроль оши-
бок. Модуль HDLC, отправляющий последовательность 1-кадров, будет нуме-
ровать их последовательно по модулю 8 или 128 в зависимости от того, использу-
ются ли 3-битовые или 7-битовые порядковые номера, и помещать порядковые
номера в поле N(S). Поле N(R) представляет собой поле подтверждения полущен-
ного 1-кадра. Оно позволяет модулю HDLC указать, 1-кадр с каким номером он
ожидает получить следующим.
S-кадры также используются для управления потоком и контроля ошибок.
Кадр RR (Receive Ready — готовность к приему) используется для подтверждения
последнего принятого I-кадра, для чего указывается номер следующего ожидае-
мого 1-кадра. Кадр RR применяется в отсутствии встречного потока данных (1-кад-
ров) для переноса подтверждения. Кадр RNR (Receive Not Ready — неготовность
к приему), как и кадр RR, подтверждает получение 1-кадра, но также просит одно-
ранговую сущность приостановить передачу 1-кадров. Когда сущность, отправив-
шая кадр RNR, снова переходит в состояние готовности, она посылает кадр RR.
Кадр REJ (REJect — отказ) инициирует метод возврата на N шагов. Он указывает,
что последний полученный 1-кадр был отвергнут и требуется повторная передача
всех 1-кадров, начиная с кадра с номером N(R). Кадр SREJ (Selective REJect — селек-
тивный отказ) применяется для запроса повторной передачи всего одного кадра.
Разрыв соединения
Разрыв соединения может инициировать любой из модулей HDLC либо по соб-
ственной инициативе, в случае какой-то неисправности, либо по запросу более
высокого уровня. Модуль HDLC генерирует команду разрыва соединения, посы-
лая кадр DISC (DISConnect — разрыв соединения). Другая сторона обязана при-
нять эту команду, ответив на нее кадром UA.
Пример работы
На рис. 11.15 приведено несколько примеров, позволяющих лучше понять, как
работает протокол HDLC. На диаграммах каждая стрелка снабжена условным обо-
значением, включающим название кадра, значение бита P/F, а также, где возмож-
но, значения полей N(R) и N(S). Бит Р или F установлен в 1, если обозначение
присутствует, и в 0, если отсутствует.
На рис. 11.15, я показаны кадры, участвующие в установке и разрыве соединения.
Одна HDLC-сущность посылает другой стороне команду S ABM (Set Asynchronous
Mode Balanced — установить асинхронный сбалансированный режим)1 и запускает
таймер. Получив команду SABM, другая сторона отвечает кадром UA и инициали-
зирует локальные переменные и счетчики. Первая сущность получает ответ (кадр
1 Команда SABM инициирует обмен данными. Асинхронный сбалансированный режим (Asynchronous
Mode Balanced, ABM) представляет собой режим передачи данных, углубляться в детали которого
мы не станем.
11.4. Протокол HDLC
347
UA), устанавливает значения своих переменных и счетчиков и останавливает таймер.
Теперь логическое соединение активно, и обе стороны могут начинать передавать
кадры. Как показано на рисунке, в случае, если время ожидания истечет прежде,
чем получен ответ, инициирующая сторона будет повторять команду SABM, пока
не получит кадр UA или DM либо пока не пройдет определенное количество по-
пыток, после чего сущность, инициирующая соединение, «сдается» и сообщает об
ошибке управляющей сущности. В этом случае необходимо вмешательство более
высокого уровня. Там же (рис. 11.15, а) показана процедура разрыва соединения.
Одна из сторон генерирует команду DISC, а другая сторона отвечает кадром UA.
На рис. 11.15, б показан дуплексный обмен 1-кадрами. Когда сущность посыла-
ет подряд несколько 1-кадров, не получая входных данных, тогда порядковый но-
мер приема N(R) просто повторяется (например, I, 1,1; I, 2,1 в направлении от
станции А к станции В). Когда сущность принимает подряд несколько 1-кадров,
не отправляя выходных данных, тогда порядковый номер приема в следующем
исходящем кадре должен отражать суммарную активность (например, 1,1, Зв на-
правлении от станции В к станции А). Обратите внимание на то, что помимо 1-кад-
ров обмен данными может включать контрольные кадры (S-кадры).
На рис. 11.15,в показана работа при наличии состояния занятости. Одна из сто-
рон может быть занята, например в том случае, если HDLC-сущность не способна
обрабатывать 1-кадры с той скоростью, с которой они поступают, или если пользо-
ватель уровня передачи данных не может принимать данные с той скоростью, с
которой они прибывают в 1-кадрах. В любом случае входной буфер HDLC-сущ-
ности переполняется, в результате чего она вынуждена остановить входящий по-
ток 1-кадров при помощи команды RNR. В данном примере станция А генерирует
команду' RNR, которая требует от другой стороны приостановить передачу 1-кад-
ров. Станция, получившая команду RMR, как правило, начинает периодически
опрашивать занятую станцию, посылая ей кадр RR с установленным в 1 битом Р.
На это другая сторона должна ответить кадром RR или RNR. Когда станция А сно-
ва готова к приему, она посылает станции В кадр RR.
Пример восстановления протокола после ошибки при помощи команды REJ
показан на рис. 11.15, г. В данном примере станция А передает 1-кадры, пронумеро-
ванные числами 3,4 и 5. Кадр 4 повреждается. Станция В обнаруживает ошибку
и отбрасывает этот кадр. Получив 1-кадр с номером 5, станция В также отбрасывает
его, так как он пришел с нарушением порядка, и посылает кадр REJ с N(R) = 4. Это
заставляет станцию А начать повторную передачу всех посланных 1-кадров, начи-
ная с кадра 4. После этого станция А может продолжать передачу 1-кадров.
Пример восстановления протокола после ошибки при помощи тайм-аута пока-
зан на рис. 11.15, д. В этом примере станция А передает 1-кадр с номером 3, кото-
рый повреждается при переносе. Станция В обнаруживает ошибку и отбрасывает
этот кадр. Однако станция В не может послать кадр REJ, так как не в состоянии
определить, что это был 1-кадр. При ошибке все биты кадра попадают под подо-
зрение, и у принимающей стороны нет способа определить, что делать с этим кад-
ром. При его передаче станция А запустила таймер с достаточно большим време-
нем срабатывания, чтобы станция В успела принять этот кадр и подтвердить его
получение. Когда время ожидания истекает, станция А начинает процедуру вос-
становления после ошибки. Как правило, при этом другая сторона опрашивается
командой RR установленным в 1 битом Р, чтобы определить состояние другой сто-
348
Глава 11. Управление потоком и контроль ошибок на уровне передачи данных
роны. Поскольку на запрос должен быть послан ответ, сущность получит кадр, со-
держащий поле N(R), и сможет продолжать работу. В этом случае в ответе указы-
вается, что был потерян кадр 3, который станция А передаст повторно.
Рис. 11.15. Пример работы протокола HDLC
11.6. Задания
349
Эти примеры не являются исчерпывающими. Тем не менее, они должны дать
читателю представление о работе протокола HDLC.
11.5. Рекомендуемая литература
Производительности протоколов уровня передачи данных с автоматическим за-
просом на повторение посвящено огромное количество литературы. Имеет смысл
прочитать статьи [22], [141] и [43]. В [145] предоставляется удобочитаемое обо-
зрение с упрощенными расчетами производительности. В [248] содержится более
поздний анализ. Двумя книгами, в которых подробно описывается тема произво-
дительности протокола уровня передачи данных, являются [211] и [229].
[138] и [139] — две ключевые статьи, в которых рассматривается влияние гига-
битных скоростей передачи данных на производительность.
11.6. Задания
1. Рассмотрим полудуплексную двухточечную линию, в которой использует-
ся схема с остановкой и ожиданием. По линии передается последователь-
ность сообщений, каждое сообщение разбито на несколько кадров. Ошибки
и накладные расходы игнорируются.
а) какое влияние на коэффициент использования линии окажет увеличе-
ние размера сообщения, так что потребуется меньшее количество сооб-
щений? Остальные параметры не меняются;
б) какое влияние на коэффициент использования линии окажет увеличе-
ние количества кадров для постоянного размера сообщения;
в) какое влияние на коэффициент использования линии окажет увеличе-
ние размера кадра?
2. Скорость передачи данных в канале равна 4 Кбит/с, задержка распростра-
нения сигнала составляет 20 мс. Для какого диапазона размера кадров алго-
ритм остановки с ожиданием сможет обеспечить по меньшей мере 50-про-
центную эффективность?
3. Рассмотрим передачу 1000-битовых кадров по спутниковому каналу со ско-
ростью 1 Мбит/с и 270-миллисекундной задержкой. Чему равен максималь-
ный коэффициент использования для перечисленных далее алгоритмов?
а) управление потоком с остановкой и ожиданием;
б) непрерывное управление потоком с размером окна 7;
в) непрерывное управление потоком с размером окна 127;
г) непрерывное управление потоком с размером окна 255.
4. Кадры формируются в узле А и отправляются на узел С через узел В
(рис. 11.16). Определите минимальную скорость передачи данных между
узлами В и С, такую, чтобы буферы узла В не переполнялись, основываясь
на следующей информации (подсказка — чтобы буферы станции В не пере-
350
Глава 11, Управление потоком и контроль ошибок на уровне передачи данных
полнились, среднее количество кадров, поступающих на станцию В и поки!
дающих станцию В, должно быть одинаковым в течение большого интерва-1
ла времени):
♦ скорость передачи данных между узлами А и В равна 100 Кбит/с;
♦ задержка распространения сигнала в обеих линиях составляет 5 мкс/км-
* все узлы соединены дуплексными линиями;
♦ все кадры данных имеют размер 1000 бит, а подтверждения пересылают-
ся в отдельных кадрах пренебрежимо малой длины;
♦ между узлами А и В используется протокол скользящего окна с разме-
ром окна 3;
♦ между узлами В и С используется протокол с остановкой и ожиданием;
♦ предполагается отсутствие ошибок.
Рис. 11.16. Конфигурация сети для задания 4
5. Скорость передачи данных в канале составляет R бит/с, а задержка распро-
странения равна t секунд на километр. Расстояние между передающим и
принимающим узлами равно L км. Узлы обмениваются кадрами фикси-
рованного размера В бит. Составьте формулу зависимости минимального
размера поля порядкового номера кадра от параметров R, t, В и L (при
максимальном коэффициенте использования канала). Предполагается, что
размером кадров подтверждений можно пренебречь и что обработка данных
в узлах не занимает времени.
6. При обсуждении метода ARQ с остановкой и ожиданием кадры REJ не упо-
минались. Почему нет необходимости в кадрах REJO и REJ 1 при использо-
вании этого алгоритма?
7. Предположим, что используется схема ARQ с селективным отказом при
Лг= 4. Покажите, например, что необходим 3-битовый порядковый номер.
8. С помощью тех же допущений, которые были сделаны при построении гра-
фиков на рис. 11.12, постройте график зависимости коэффициента исполь-
зования линии от Р, то есть от вероятности того, что отдельный кадр будет
поврежден, для перечисленных далее методов контроля ошибок. Постройте
графики для значений параметра а 0,1, 1, 10, 100. Сделайте вывод о том,
какой метод лучше подходит для различных диапазонов параметра а.
а) остановка с ожиданием;
б) возврат на N шагов при N= 7;
в) возврат на N шагов при N = 127;
г) селективный отказ при N= 7;
д) селективный отказ при 127.
11.6. Задания
351
9. Два соседних узла (А и В) используют протокол скользящего окна с 3-бито-
вым полем порядкового номера. В качестве схемы ARQ используется алго-
ритм возврата на N шагов с окном размерам 4. Предполагая, что станция А
передает кадры, а станция В их принимает, покажите положения окна для
следующей последовательности событий:
а) перед тем как станция А передаст какие-либо кадры;
б) после того как станция А передаст кадры 0, 1, 2 и получит от станции В
подтверждения для кадров 0 и 1;
в) после того как станция А передаст кадры 3,4 и 5, а станция В подтвердит
получение кадра 4 и это подтверждение будет получено станцией А.
10. Для схемы ARQ с селективным отказом не может использоваться несвое-
временное подтверждение. Это значит, что если кадр i отброшен станцией X,
все последующие 1-кадры и RR-кадры, посылаемые станцией X, должны иметь
N(R) = г до тех пор, пока кадр i не будет успешно получен, даже если остальные
кадры с N(S) > i будут, между тем, получены успешно. Одно из возможных
усовершенствований этого алгоритма заключается в следующем: N(R) =j
в 1-кадре или RR-кадре интерпретируется как сигнал о том, что кадру - 1
и предыдущие кадры приняты, кроме тех, которые были явно отброшены
при помощи кадра SREJ. Какие недостатки могут быть у такой схемы?
И. Стандарт ISO, описывающий процедуры протокола HDLC (ISO 4335),
включает следующие определения. Во-первых, условие REJ считается вы-
полненным после получения кадра данных с N(S), равным N(R) исходяще-
го кадра REJ. Во-вторых, условие SREJ считается выполненным после по-
лучения кадра данных с N(S), равным N(R) кадра SREJ. Стандарт включает
правила, касающиеся взаимоотношения между кадрами REJ и SREJ. Эти
правила указывают, что является допустимым (в терминах передачи кадров
REJ и SREJ), если условие REJ еще не выполнено, и что является допусти-
мым, если еще не выполнено условие SREJ. Выведите правила и аргумен-
тируйте свой ответ.
12. Две станции обмениваются данными по спутниковому каналу со скоростью
передачи данных 1 Мбит/с и задержкой распространения 270 мс. Спутник
всего лишь ретранслирует данные, получаемые им от одной станции, дру-
гой станции, при этом задержкой переключения можно пренебречь. Чему
равна максимальная пропускная способность спутникового канала, если ис-
пользуются 1024-битовые кадры протокола HDLC с 3-битовыми порядковы-
ми номерами (48 накладными битами данных в кадре можно пренебречь)?
13. Веб-сервер, как правило, настраивается на прием от своих клиентов отно-
сительно коротких сообщений и на передачу им, возможно, очень больших
сообщений. Какой тип протокола ARQ (селективный отказ, возврат на N
шагов) обеспечит минимальную нагрузку' на популярный веб-сервер?
Глава 12
Управление трафиком
в протоколе TCP
Упомянутые выше наблюдения заставляют нас пересмот-
реть широко распространенную точку зрения о том, что
птицы живут только настоящим. В действительности пти-
цы осознают не только стимулы, существующие в данный
момент; они помнят прошлое и предвидят будущее.
Александр Скатч. Разум птиц
При достижении высокой производительности оконечных систем и сетей в целом
разработка и реализация транспортного протокола являются важными составля-
ющими. Транспортный протокол предоставляет интерфейс между приложениями
и сетевыми устройствами, позволяющими приложениям запрашивать требуе-
мое качество обслуживания. Ориентированные на соединение транспортные
протоколы, такие как TCP, разделяют суммарный поток прикладных данных
на отдельные логические потоки и могут по-разному распределять ресурсы для
различных потоков. Наконец, политики транспортного протокола для передачи
и повторной передачи блоков данных оказывают сильное влияние на уровень
перегрузки в сети.
В этой главе исследуется влияние протокола TCP на производительность сети.
Мы начнем с обзора особенностей управления потоком и контроля ошибок этого
протокола. Затем мы рассмотрим сложный вопрос борьбы с перегрузкой в прото-
коле TCP. За этим последует обсуждение вопросов производительности при ра-
боте протокола TCP/IP в сетях ATM.
12.1. Управление потоком в протоколе TCP
Как и в большинстве протоколов, осуществляющих управление потоком, в прото-
коле TCP используется разновидность механизма скользящего окна. Он отлича-
ется от механизмов, используемых в других протоколах, таких как LLC, HDLC
и Х.25, тем, что в нем подтверждения для полученных модулей данных не связаны
с разрешениями посылать дополнительные модули данных. Таким образом, в про- /
I
12.1. Управление потоком в протоколе TCP
353
коле TCP одна сторона соединения может подтвердить получение данных, не
1Вая разрешения на отправку дополнительных данных, тогда как в протоколе
; IDLC подтверждение получения модуля данных автоматически сдвигает сколь-
зящее окно, разрешая передачу дополнительных данных.
Используемый в протоколе TCP механизм управления потоком называется
схемой распределения кредитов. В этой схеме каждый отдельный байт переда-
ваемых данных рассматривается как порядковый номер. Помимо данных каждый
передаваемый сегмент включает в заголовке (см. рис. 2.1 в главе 2) три поля,
относящиеся к управлению потоком: SN (Sequence Number — порядковый номер),
AN (Acknowledgement Number — номер подтверждения) и IV (Window — окно).
Каждый сегмент, передаваемый TCP-сущностью, включает порядковый номер
первого байта поля данных. TCP-сущность подтверждает принятый сегмент от-
ветным сегментом, включающим поля (AN = г, W-j) со следующей интерпре-
тацией:
♦ подтверждается получение всех байтов вплоть до порядкового номера
SN = i - 1; номер следующего ожидаемого байта равен г;
4 дается разрешение послать дополнительное окно в W=j байтов данных; то
есть) байтов, соответствующих порядковым номерам с г-го по г +j - 1-й.
Работу механизма предоставления кредитов иллюстрирует рис. 12.1 (сравните
с рис. 11.6 в главе 11). Для простоты мы рассмотрим поток данных только в одном
направлении, а также предположим, что в каждом сегменте посылается 200 байт
данных. Сначала в процессе установки соединения синхронизируются порядко-
вые номера отправителя и получателя, и станция А получает начальный кредит
на передачу 1400 байт, начиная с байта с номером 1001. Отправив 600 байт в трех
сегментах, станция А уменьшает размер своего окна до 800 байт (с номерами
от 1601-го до 2400-го). Затем станция В подтверждает получение всех байтов
вплоть до 1600-го и выдает станции А кредит на 1000 байт. Это означает, что
станция А может послать байты с номерами от 1601-го до 2600-го (5 сегментов).
Однако к моменту', когда сообщение станции В прибывает на станцию А, станция А
уже отправила два сегмента, содержащие байты с 1600-го по 2000-й. Таким обра-
зом, у станции А остается кредит на всего лишь 400 байт (2 сегмента). В процесс
обмена данными станция А перемещает вперед задний фронт окна при каждой
передаче и передний фронт окна — при каждом получении кредита.
На рис. 12.2 показана работа этого механизма с обеих сторон, передающей и
принимающей (сравните с рис. 11.5 в главе 11). Как правило, данные передаются
в обе стороны, поэтому обе стороны соединения выступают в обеих ролях. Обра-
тите внимание на то, что получатель не обязан немедленно подтверждать получе-
ние сегментов, он может подождать и выслать общее подтверждение для несколь-
ких сегментов сразу.
Механизм предоставления кредитов довольно гибок. Например, допустим,
что последним сообщением, переданным станцией В, было (AN = г, IV=)) и что по-
следним байтом данных, принятым станцией В, был байт с номером г - 1.
♦ Чтобы увеличить кредит до количества k (k >)), когда не прибывает допол-
нительных данных, станция В передает сообщение (AN =i,W= k).
354
Глава 12. Управление трафиком в протоколе TCP
4- Чтобы подтвердить принятый сегмент данных, содержащий т байт данных
(т <j), не выдавая дополнительного кредита, станция В передает сообще-
ние (AN =i + т, W=j - rri).
Транспортная сущность А Транспортная сущность В
...loop 1001
Станция В готова получить 1400 байт
начиная с 1001-го
2400 2401...
Станция А может послать 1400 байт
Станция А уменьшает свое окно
с каждой передачей
1600 1601 2001 2601...
...1600 1601 2601,.,
Станция В подтверждает получение
3 сегментов (600 байт), но готова
принять только 200 дополнительных
байтов сверх оригинального бюджета
(например, станция В примет байты
с 1601-го по 2600-й)
Получив кредит, станция А
расширяет окно
1600 1601 2600|2601...
Станция А исчерпала кредит
Станция В подтверждает получение
5 сегментов (1000 байт)
и восстанавливает исходную
величину кредита
,2600 2601
4000 4001
Станция А получает новый кредит
Рис. 12.1. Пример работы механизма предоставления кредитов протокола TCP
Получатель должен придерживаться некоторой политики, касающейся объема
данных, которые он разрешает передавать отправителю. Консервативный подход
заключается в том, чтобы разрешать передачу такого количества новых сегментов,
которое может вместить буфер. Если на рис. 12.1 применялась эта политика, тогда
первое кредитное сообщение подразумевает, что у станции В есть 1000 свободных
байтов в буфере, а второе — что в буфере станции В есть 1400 свободных байтов.
Консервативная схема управления потоком может ограничивать пропускную
способность транспортного соединения в ситуации с большими задержками.
Получатель мог бы увеличить пропускную способность, оптимистично предоста-
вив кредит на место в буфере, которого у него пока нет. Например, буфер получа-
теля заполнен, но получатель полагает, что сможет освободить в нем место для
1000 байт за время, требующееся для распространения сигнала в оба конца соеди-
нения. В этом случае он может немедленно выдать кредит в 1000 байт. Если полу-
чатель поспевает за отправителем, то такая схема может позволить увеличить
производительность. Однако если отправитель быстрее получателя, некоторые
сегменты могут отбрасываться, в результате чего потребуется их повторная пере-
дача. В противном случае (при надежной сетевой службе) повторные передачи не /
12.1. Управление потоком в протоколе TCP 355
нужны (в отсутствие перегрузки объединенной сети), поэтому оптимистическая
схема управления потоком усложнит протокол.
Начальный
порядковый
номер (ISN)
Подтвержденные на данный Еще не подтвержденные
момент байты данных байты данных
— ► Окно байтов, которые
Уже переданные байты данных могут быть переданы
Передающая сторона
Уже принятые байты данных
Подтвержденные на данный Еще не подтвержденные
момент байты данных байты данных
Окно байтов, которые
могут быть приняты
По мере отправки
Последний
принятый байт
Начальный
порядковый
номер (ISN)
Последний
подтвержденный
байт (AN - 1)
По мере получения
байтов окно сзади кредитов окно спереди
сжимается раздвигается
Получающая сторона
Рис. 12.2. Схема управления потоком отправителя и получателя
Влияние размера окна на производительность
Как и в случае алгоритма скользящего окна протокола передачи данных (см. гла-
ву 11), мы можем определить максимально возможную пропускную способность
TCP-соединения. Как и ранее, пропускная способность зависит от размера окна,
задержки распространения и скорости передачи данных. В случае протоколов пе-
редачи данных как размер окна, так и порядковые номера обозначают кадры, а нор-
мализованная пропускная способность, помимо других только что упомянутых
факторов, зависит от размера кадра. В случае протокола TCP размер окна и по-
рядковые номера обозначают байты. Соответственно, мы должны пересмотреть
паши формулы, исключив из них размер сегмента.
356 Глава 12. Управление трафиком в протоколе TCP
Мы будем применять следующие обозначения:
4- IV — размер окна TCP, байт;
4 R — скорость передачи данных TCP-источником, доступная для данного
TCP-соединения, бит/с;
4 D — задержка распространения между отправителем и получателем для дан-
ного TCP-соединения, с.
Для простоты будем игнорировать служебные биты в TCP-сегменте. Пред-
положим, что передающая TCP-сущность начинает передавать получателю по-
следовательность байтов по TCP-соединению. Чтобы добраться до получателя
первому байту понадобится D секунд. Также потребуется D секунд, чтобы под-
тверждение вернулось к отправителю. За это время источник, если он ничем не
ограничен, сможет передать 2RD бит или RD/& байт. В действительности, источ-
ник ограничен размером окна в IV байт, пока не получит подтверждения. Соответ-
ственно, если W > RD/4, тогда для данного соединения можно достичь максималь-
ной пропускной способности. Если же IV< RD/&, тогда максимально достижимая
нормализованная пропускная способность представляет собой просто отношение
И7 к RD/4. Таким образом, нормализованную пропускную способность 5 можно
выразить так:
1, W>RD/4,
41V
—,IV< RD/i.
[RD
(12.1)
На рис. 12.3 показана максимально достижимая пропускная способность в виде
функции произведения RD (сравните с рис. 11.11 в главе 11). Максимальный раз-
мер окна равен 216 - 1 = 65 535 байт. Этого должно быть достаточно для большин-
ства приложений. Например, из рисунка видно, что произведение RD для сети
Ethernet со скоростью передачи данных в 1 Гбит/с и длиной кабеля в 100 м не пре-
вышает 103бит. Даже в случае спутникового канала Т-1 (1,544 Мбит/с) макси-
мальный размер окна обеспечивает хорошую производительность. Однако можно
представить сетевое соединение, для которого размера окна по умолчанию недо-
статочно. Один из таких примеров, показанный на рисунке, — оптический канал
SDH (Synchronous Digital Hierarchy — синхронная цифровая иерархия), работа-
ющий на скорости 155 Мбит/с, соединяя две удаленные точки. В таких случаях
для увеличения потенциальной пропускной способности может использоваться
масштабирование окна. На рисунке показано применение масштабного коэффи-
циента 4, увеличивающего размер окна до 220 - 1 = 106 байт.
Рисунок 12.3 дает представление о потенциальной производительности ТСР-со-
единения. Однако следует учитывать множество факторов, некоторые из которых
перечислены далее.
4 В большинстве случаев в одном и том же сетевом соединении мультиплек-
сировано несколько ТСР-соеди нений, так что каждому соединению выде-
ляется только часть доступной пропускной способности. Это снижает ско-
рость передачи данных R и поэтому повышает эффективность.
12.1. Управление потоком в протоколе TCP
357
Рис. 12.3. Результат масштабирования окна
♦ С другой стороны, многие TCP-соединения включают ретрансляционные
участки, проходящие через множество сетей. В этом случае задержка рас-
пространения D представляет собой сумму задержек в каждой сети плюс
задержки на каждом маршрутизаторе вдоль маршрута. Задержки маршрути-
заторов часто составляют наибольший вклад в D, особенно при перегрузке.
♦ Значение R в формуле (12.1) означает скорость передачи данных, доступную
для соединения у TCP-сущности источника. Если эта скорость превышает
максимальную скорость передачи данных для одного из ретрансляционных
участков, тогда попытка передачи данных с более высокой скоростью приве-
дет к перегрузке, вследствие чего увеличится задержка распространения D.
♦ Если какой-либо из сегментов теряется при передаче и требуется его повтор-
ная передача, пропускная способность снижается. Величина влияния поте-
рянных сегментов на производительность будет зависеть от политики по-
вторных передач, обсуждаемой в следующем разделе.
В большинстве современных объединенных сетей количество сегментов, теря-
ющихся в результате ошибок на линии, невелико1. Напротив, большая часть по-
1 По мере того как распространенность беспроводных каналов связи в Интернете растет, это утвержде-
ние становится все менее справедливым. Однако в большинстве беспроводных каналов па уровне
передачи данных применяется мощное помехоустойчивое кодирование.
358
Глава 12. Управление трафиком в протоколе TCP
терь сегментов вызвана тем, что маршрутизаторы или сетевые коммутаторы (на-
пример, коммутаторы пакетов или коммутаторы в сетях ретрансляции кадров) при
перегрузке вынуждены отбрасывать их. Управление потоком представляет собой
проблему, решение которой возможно в целом на уровне обычной или объединенной
сети. Однако меры по избежанию или облегчению перегрузки могут приниматься
и индивидуальными TCP-сущностями. Эти меры обсуждаются в разделе 12.2.
Стратегия повторных передач
Как и протоколы уровня передачи данных, протокол TCP должен включать схе-
мы контроля ошибок и управления потоком. В протоколе TCP не используются
явные отрицательные подтверждения, такие как REJ и SREJ, которые можно встре-
тить в протоколах уровня передачи данных. Вместо этого протокол TCP полагает-
ся исключительно на положительные подтверждения и повторную передачу в слу-
чае, если подтверждение не пришло в течение определенного интервала времени.
Повторная передача сегмента может быть вызвана двумя событиями. Во-пер-
вых, сегмент может быть поврежден при передаче, но, тем не менее, достичь полу-
чателя. Контрольная сумма, входящая в состав сегмента, позволяет получающей
транспортной сущности обнаружить ошибку' и отбросить сегмент. Более распрос-
траненный случай заключается в том, что сегменту' вообще не удается достичь по-
лучателя. В любом случае передающая транспортная сущность не знает о том, что
передача сегмента была неуспешной.
Если сегмент не был успешно принят получателем, подтверждение в ответ не
посылается, в результате требуется повторная передача сегмента. Для принятия
решения о повторной передаче у отправителя должен быть таймер, ассоциирован-
ный с каждым посылаемым сегментом. Если время ожидания истекает прежде, чем
подтверждается получение сегмента, отправитель должен повторить передачу.
Ключевой вопрос проектирования протокола TCP состоит в том, какой долж-
на быть величина времени ожидания. Слишком малое значение приведет к слиш-
ком большому числу повторных передач, то есть к расходованию пропускной спо-
собности сети. Если установить слишком большое значение периода ожидания,
протокол будет медленно реагировать на потерю сегментов. В таймере следует
устанавливать значение несколько большее, чем длительность задержки рас-
пространения сигнала в оба конца (между отправкой сегмента и получением под-
тверждения). Разумеется, величина этой задержки будет меняться при изменении
состояния объединенной сети. Что еще хуже, статистические параметры задерж-
ки также будут меняться при изменении состояния объединенной сети.
Соответственно, предлагаются две стратегии. Может применяться фиксирован-
ный таймер, основанный на понимании типичного поведения объединенной сети.
Недостаток такой стратегии заключается в неспособности реагирования на изме-
нение состояния сети. Если установить значение таймера слишком большим, об-
служивание всегда будет медленным. Если установить его слишком маленьким,
может возникнуть положительная обратная связь, то есть перегрузка объединен-
ной сети будет приводить к увеличению числа повторных передач, усугубляющих
перегрузку.
т
J r'’ 12.1. Управление потоком в протоколе TCP 359
.—-------------------------------------------------------------------
Адаптивная схема обладает собственными проблемами. Предположим, что
TCP-сущность отслеживает интервал времени, требующийся для подтверждения
сегмента данных, и устанавливает значение таймера повторной передачи на осно-
ве усреднения величины наблюдаемых задержек. Этому значению нельзя доверять
по трем причинам:
♦ Одноранговая TCP-сущность может подтвердить получение сегмента не
сразу. Вспомним, что мы предоставили ей привилегию кумулятивных под-
тверждений (см. далее описание параметров политики).
♦ В случае повторной передачи сегмента отправитель не может определить,
является ли полученное им подтверждение ответом на оригинальную или
на повторную передачу.
♦ Состояние объединенной сети может измениться внезапно.
У этих проблем нет простого решения. Всегда будет существовать определен-
ная неуверенность по поводу оптимального значения таймера повторной переда-
чи. В следующем подразделе мы рассмотрим, как вычисляется значение этого вре-
менного интервала в рекомендации RFC 793. В разделе 12.2 исследуются более
сложные стратегии выбора значения интервала периода ожидания.
Адаптивный таймер повторной передачи
При изменении состояния обычной или объединенной сети интервал статическо-
го таймера повторной передачи, скорее всего, окажется либо слишком коротким,
либо слишком длинным. Соответственно, практически во всех вариантах реализа-
ции протокола TCP предпринимаются попытки оценить значение текущего време-
ни задержки распространения сигнала в оба конца путем наблюдения за интервалом
задержки для недавно переданных сегментов. Значение таймера устанавливается
на основании этих наблюдений с небольшим запасом.
Один из методов заключается в том, чтобы просто взять среднее значение
задержки распространения сигнала в оба конца для некоторого количества сег-
ментов. Если среднее значение точно предсказывает будущие значения задержки,
тогда получаемое в результате значение таймера повторной передачи позволит
добиться хорошей производительности сети. Простой метод усреднения можно
выразить следующей формулой:
1 К+1
ARTT(A + 1) =-----£RTT(i). (12.2)
К + 1 ;=1
Здесь RTT(z) представляет собой время распространения сигнала в оба конца
(Round-Trip Time, RTT), наблюдаемое для г-го передаваемого сегмента, a ARTT(K)
является средним временем распространения сигнала в оба конца (Average Round-
Trip Time, ARTT) для первых К сегментов.
Это выражение может быть записано следующим образом:
ARTT(X +1) = ARTT(K) + RTT(A + 1). (12.3)
360
Глава 12. Управление трафиком в протоколе TCP
При такой формулировке нет необходимости выполнять полное суммирование
каждый раз.
Обратите внимание на то, что каждому слагаемому придан равный вес, то есть
каждое слагаемое умножено на одну и ту же константу 1/(К +1). Как правило
больший вес следует придавать более поздним измеренным значениям, так как они
с большей вероятностью отражают будущее поведение сети. Распространенный
метод предсказания следующего значения на основании последовательности пре-
дыдущих значений описан в спецификации RFC 793. Это метод экспоненциаль-
ного усреднения:
SRTT(K + 1) = а - SRTT(K) + (1 - а) RTT(K + 1). (12.4)
Здесь SRTT(K) называется сглаженной оценкой времени распространения сиг-
нала в оба конца (Smoothed Round-Trip Time estimate, SRTT). Сравните эту фор-
мулу с формулой (12.3). При помощи постоянной величины а (0 < а <1), незави-
симой от числа наблюдений, мы получаем формулу, в которой учитываются все
прошлые значения, но более отдаленные учитываются с меньшим весом. Чтобы
лучше понять это, рассмотрим формулу (12.4) в развернутом виде:
SRTT(K + 1) = (1 - a)RTT(X + 1) + а(1 - a)RTT(K) + а2(1 - a)RTT(X - 1) +
+ ... + ак(1 - a)RTT(l)
Поскольку как а, так и (1 - а) меньше единицы, каждое последующее слагае-
мое меньше предыдущего. Например, при а = 0,8 предыдущая формула принима-
ет вид
SRTT(K + 1) = 0,2 RTT(K + 1) + 0,16 RTT(K) + 0,128 RTT(K -1) +...
Чем раньше было наблюдение, тем меньше вес, с которым оно учитывается при
вычислении среднего значения.
График зависимости величины коэффициента от положения в формуле пока-
зан на рис. 12.4. Чем меньше значение а, тем с большим весом учитываются наи-
более поздние результаты измерений. Для а. = 0,5 практически весь вес приходит-
ся на первые четыре-пять элементов суммы, тогда как при а = 0,875 средняя
величина распределяется примерно по десятку наблюдений. Преимущество ис-
пользования небольшой величины коэффициента а заключается в том, что сред-
нее значение отражает быстрые изменения наблюдаемой величины. Недостаток
такого подхода состоит в том, что в случае кратковременного отклонения наблю-
даемой величины использование небольшого значения коэффициента а вызовет
резкое изменение среднего значения.
На рис. 12.5 сравниваются методы простого и экспоненциального (для двух
значений а) усреднения. На рис. 12.5, а наблюдаемая величина начинается в 1, за-
тем линейно растет до 10 и остается на этом уровне. На рис. 12.5, б наблюдаемая
величина начинается на уровне 20, затем линейно убывает до 10 и остается на этом
уровне. В обоих случаях мы начинаем с оценки SRTT(0) = 0. Обратите внимание
на то, что экспоненциальный метод быстрее отслеживает изменения процесса, чем
простое усреднение, и при небольших значениях коэффициента а реакция усред-
ненной величины быстрее.
12.1. Управление потоком в протоколе TCP
361
Рис. 12.4. Коэффициенты экспоненциального сглаживания
Для оценки текущего времени задержки распространения сигнала в оба конца
в рекомендациях RFC 793 используется формула (12.4). Как уже говорилось, тай-
мер повторной передачи следует установить несколько большим, чем оценивае-
мое время задержки распространения сигнала в оба конца. Одна из возможностей
сделать это заключается в использовании постоянной величины
RTO(X + 1) = SRTT(/< + 1) + A.
Здесь RTO — тайм-аут повторной передачи (Retransmission TimeOut), а A — по-
стоянная величина. Недостаток заключается в том, что величина А не пропорцио-
нальна SRTT. При больших значениях SRTT величина А оказывается относитель-
но малой, и флуктуации фактических значений RTT являются причиной лишних
повторных передач. При небольших значениях SRTT величина А оказывается
относительно большой, что приводит к избыточным задержкам при повторной пе-
редаче потерянных сегментов. Соответственно, в RFC 793 предписывается ис-
пользовать тайм-аут со значением, пропорциональным SRTT и вычисляемым по
следующей формуле:
RTO(K+ l) = MIN(UBOUND,MAX(LBOUND,p-SRTT(/C + 1))). (12.5)
362
Глава 12. Управление трафиком в протоколе TCP
Время
Время
Рис. 12.5. Пример экспоненциального сглаживания
Здесь UBOUND и LBOUND представляют собой выбранные заранее фик-
сированные значения верхней и нижней границ, а Р — константа. В RFC 793 не
указываются конкретные значения, но приводится список «примерных значений»:
а между 0,8 и 0,9, а р между 1,3 и 2,0.
Параметры политики реализации протокола TCP
Стандартом TCP предоставляется точная спецификация протокола, которая долж-
на использоваться TCP-сущностями при взаимодействии друг с другом. Однако
12.1. Управление потоком в протоколе TCP
363
определенные аспекты протокола предполагают несколько возможных вариантов
реализации. Хотя два разных варианта реализации протокола могут работать со-
вместно, но возможны проблемы с производительностью. Области проектирова-
ния, для которых указаны параметры политики, следующие:
♦ передача;
♦ доставка;
♦ прием;
♦ повторная передача;
подтверждение.
Политика передачи
В отсутствии данных, помеченных флагом PUSH, и при закрытом окне передачи
передающая TCP-сущность может передавать данные так, как ей удобнее. По-
ступившие от пользователя данные накапливаются в буфере передачи. Протокол
TCP может сформировать сегмент для каждого пакета данных, предоставляемого
пользователем, или подождать, пока не накопится определенный объем данных.
Применяемая политика зависит от соображений производительности. При пере-
даче данных большими порциями накладные расходы минимизируются. С дру-
гой стороны, если данные передаются часто и понемногу, минимизируется время
отклика системы.
Опасность частой передачи небольшими порциями известна как синдром «глу-
пого» окна (см. задания 12.6 и 12.7).
Политика доставки
В отсутствии данных, помеченных флагом PUSH, принимающая ТСР-сущность
может доставлять данные пользователю так, как ей удобнее. Она может достав-
лять их сразу, как только прибудет новый, поступивший в порядке очереди, сегмент
данных, или накапливать полученные сегменты в приемном буфере. Применяе-
мая политика зависит от соображений производительности. При доставке данных
пользователю большими порциями пользователь получает данные с некоторым
опозданием. С другой стороны, если данные доставляются пользователю часто и
небольшими порциями, могут возникнуть излишние затраты на обработку данных
как в самом протоколе TCP, так и программном обеспечении пользователя, а так-
же излишний рост числа прерываний операционной системы.
Политика приема
Когда все данные по TCP-соединению прибывают в правильном порядке, прото-
кол TCP помещает их в буфер приема для доставки пользователю. Однако сегмен-
ты могут прибывать в неверном порядке. В этом случае у принимающей ТСР-сущ-
ности есть два варианта действий:
♦ Прием по порядку. Принимаются только те сегменты, которые прибывают
в правильном порядке; любой сегмент, прибывающий с нарушением поряд-
ка, отбрасывается.
4- Прием в окне. Принимаются все сегменты, попадающие в приемное окно.
364
Глава 12. Управление трафиком в протоколе TCP
Политика приема по порядку проще в реализации, но она оказывает дополни-
тельную нагрузку на сетевое оборудование, поскольку после истечения периода
ожидания подтверждения отправляющая TCP-сущность должна повторить пере-
дачу сегментов, успешно доставленных, но отброшенных как прибывшие в невер-
ном порядке. Более того, если при передаче один из сегментов будет поврежден
придется передавать еще раз все последующие сегменты.
Политика приема сегментов, попадающих в окно, может снизить количество
передач, но требует более сложных алгоритмов приема и хранения данных.
Политика повторных передач
Протокол TCP поддерживает очередь сегментов, которые были переданы, но по-
лучение которых еще не было подтверждено. В спецификации протокола TCP
утверждается, что TCP передает сегмент повторно, если не получает подтвержде-
ния в установленный срок. В реализации протокола TCP может использоваться
одна из трех стратегий повторных передач:
♦ Повторная передача только первого сегмента. Поддерживается один таймер
для всей очереди. Если получается подтверждение, соответствующий сег-
мент или сегменты удаляются из очереди, а таймер переустанавливается.
Если период ожидания истекает, сегмент в начале очереди передается по-
вторно, а таймер переустанавливается.
♦ Пакетная повторная передача. Поддерживается один таймер для всей оче-
реди. Если приходит подтверждение, соответствующий сегмент или сег-
менты удаляются из очереди, а таймер переустанавливается. Если период
ожидания истекает, все сегменты, стоящие в очереди, передаются повторно,
а таймер переустанавливается.
♦ Индивидуальная повторная передача. Поддерживается по одному таймеру
для каждого сегмента в очереди. Если приходит подтверждение, соответ-
ствующий сегмент или сегменты удаляются из очереди и переустанавлива-
ется соответствующий таймер или таймеры. Если любой период ожидания
истекает, соответствующий сегмент передастся повторно, а его таймер пе-
реустанавливается.
Политика повторной передачи только первого сегмента эффективна с точки
зрения формируемого ею трафика, так как заново передаются исключительно
потерянные сегменты (или сегменты, чьи подтверждения потеряны). Однако по-
скольку таймер для второго сегмента в очереди не устанавливается до тех пор, пока
не будет получено подтверждение для первого сегмента, при работе данной схемы
могут иметь место существенные задержки. Эта проблема решается при помощи
индивидуальной политики за счет усложнения реализации. Пакетная политика
также снижает вероятность появления длительных задержек, но может привести
к излишним передачам.
Фактическая активность политики повторных передач частично зависит от
политики приема у получателя. Если получатель использует политику приема сег-
ментов в порядке очереди, тогда он будет отбрасывать сегменты, полученные пос-
ле потерянного сегмента. Такая стратегия лучше всего соответствует пакетной
политике повторных передач. Если получатель использует политику приема сег-
12.2. Борьба с перегрузкой в TCP
365
ментов, попадающих в окно, тогда ей лучшей всего соответствует политика повтор-
ных передач. Разумеется, в смешанной компьютерной сети могут применяться обе
политики приема сегментов.
Политика подтверждения
Когда прибывает сегмент данных, у получающей TCP-сущности есть две возмож-
ности действий, касающихся времени отправки подтверждения:
♦ Немедленное подтверждение. При приеме данных сразу же передается пус-
той (без данных) сегмент, содержащий соответствующий номер подтверж-
дения.
♦ Кумулятивное подтверждение. При получении данных TCP-сущность де-
лает себе на память заметку о необходимости отправки подтверждения, но
ждет, пока не будет передаваться исходящий сегмент данных, вместе с кото-
рым можно это подтверждение отправить. Во избежание долгих задержек
устанавливается таймер окна. Если период ожидания истекает прежде, чем
отправлено подтверждение, передается пустой сегмент, содержащий соот-
ветствующий номер подтверждения.
Политика немедленного подтверждения проста в реализации, кроме того, она
обеспечивает полную информированность отправляющей TCP-сущности, благо-
даря чему снижается количество лишних повторных передач. Однако применение
данной политики приводит к передаче дополнительных сегментов (а именно пус-
тых сегментов, используемых только для подтверждений). Кроме того, эта поли-
тика может привести к увеличению нагрузки на сеть. Допустим, ТСР-сущность
получает сегмент и тут же передает подтверждение. В этом случае данные в сег-
менте доставляются приложению, которое расширяет приемное окно, генерируя
другой пустой TCP-сегмент, предоставляющий дополнительный кредит передаю-
щей ТСР-сущности.
Так как политика немедленного подтверждения потенциально связана с наклад-
ными расходами, как правило, на практике используется кумулятивное подтвер-
ждение. При использовании этой политики на принимающей стороне требуется
дополнительная обработка, а также усложняется задача оценки времени распрос-
транения сигнала в оба конца для передающей ТСР-сущности.
12.2. Борьба с перегрузкой в TCP
Перегрузка в обычной или объединенной сети создает очевидные проблемы для
оконечных систем: приводит к снижению коэффициента готовности и пропускной
способности, а также к увеличению времени отклика. В коммутируемой сети, напри-
мер в сети с коммутацией пакетов или в сети ретрансляции кадров, может исполь-
зоваться динамическая маршрутизация для уменьшения перегрузки путем более
равномерного перераспределения нагрузки между коммутаторами и каналами. Ана-
логично, применяемые в объединенных сетях алгоритмы маршрутизации могут
перераспределить нагрузку между мультипроцессорами и сетями, чтобы уменьшить
перегрузку. Однако эти меры эффективны только для несбалансированной нагрузки
366
Глава 12. Управление трафиком в протоколе TCP
и кратковременных всплесков трафика. Наконец, перегрузкой можно управлять
только ограничивая общий объем данных, поступающих в объединенную сеть’
В этом состоит основная цель всех механизмов борьбы с перегрузкой.
Борьба с перегрузкой в объединенной сети, основанной на протоколах TCP/
IP, представляет собой сложную проблему, исследование которой в течение не-
скольких десятков лет породило множество экспериментальных реализаций и опуб-
ликованных статей. Сложность этой проблемы обусловлена следующими факто-
рами:
Протокол IP не требует соединений и не хранит информацию о своем со-
стоянии, а потому не имеет средств обнаружения перегрузки и предостав-
ляет очень мало средств борьбы с нею.
♦ Протокол TCP обеспечивает только сквозное управление потоком. Он поз-
воляет догадаться о наличии перегрузки в промежуточных объединенных
сетях только с помощью косвенных средств. Кроме того, поскольку время
задержки в обычной или объединенной сети непостоянно и может быть дли-
тельным (относительно размера сегмента), знание состояния сети, которым
обладает TCP-сущность, представляется ненадежным.
♦ Не существует кооперативного распределенного алгоритма, связывающего
вместе различные ТСР-сущности. Поэтому ТСР-сущности не могут сотруд-
ничать для поддержания определенного уровня суммарного потока, а, на-
против, склонны к эгоистичной конкуренции за доступные ресурсы.
Что касается не требующего соединения IP-окружения, сообщение Source Quench
(гашение источника) протокола ICMP (Internet Control Message Protocol — прото-
кол управления сообщениями в объединенных сетях) предоставляет грубый инст-
румент ограничения потока источника, но само по себе не является эффективным
средством борьбы с перегрузкой. Протокол RSVP (Resource reSerVation Protocol —
протокол резервирования ресурсов), описываемый в главе 17, может в будущем
помочь в борьбе с перегрузкой, но до его широкого применения еще очень далеко.
Единственный инструмент протокола TCP, имеющий отношение к борьбе с пе-
регрузкой, — это механизм управления потоком и контроля ошибок при помощи
скользящего окна. Хотя этот механизм разработан для управления сквозным
трафиком, было придумано несколько искусных технических приемов, делающих
возможным его применение для обнаружения и предотвращения перегрузки, а также
для восстановления в случае, если перегрузка возникла. В этом разделе рассмат-
риваются некоторые из наиболее важных и широко распространенных механиз-
мов. Мы начнем с обсуждения взаимосвязи между управлением потоком и конт-
ролем ошибок в TCP.
Управление потоком и контроль ошибок в TCP
В протоколе управления каналом передачи данных метод скользящего окна пре-
доставляет получателю возможность ограничения скорости передачи данных от-
правителя. Получатель будет подтверждать кадры и расширять окно, только если
у него есть достаточное количество свободного буферного пространства. Тот же
12.2. Борьба с перегрузкой в TCP
367
сдерживающий эффект получатель может оказывать на отправителя в протоколе
TCP. Скорость, с которой TCP-сущность может передавать данные, определяется
скоростью, с которой поступают подтверждения для предыдущих сегментов с но-
выми кредитами. Однако в случае протокола TCP скорость поступления подтвер-
ждений определяется узким местом на пути между источником и приемником, и
этим узким местом может быть либо получатель, либо объединенная сеть.
Рисунок 12.6, а, основанный на рисунке, опубликованном в [121], иллюстри-
рует случай, в котором узкое место находится где-то в объединенной сети. Конфи-
гурацию можно представить себе в виде трубы (канала), соединяющей источник и
приемник. Диаметр трубы пропорционален скорости передачи данных. Источник
и приемник подключены к высокоскоростным сетям и могут работать на высоких
скоростях. Более узкий центральный участок трубы представляет канал связи,
работающий с меньшими скоростями и являющийся узким местом. Каждый сег-
мент показан в виде прямоугольника, чья площадь пропорциональна количеству
битов в нем. Таким образом, когда сегмент сжимается, протискиваясь через узкое
место трубы, он удлиняется во времени. Время Pb представляет собой минимальное
расстояние между сегментами в самом медленном канале. Когда сегменты прибыва-
ют к пункту назначения, это расстояние сохраняется несмотря на то, что скорость
передачи данных увеличивается. Соответственно, расстояние между сегментами
у получателя Рг равно РЬ. Если получатель подтверждает получение сегментов
сразу, как только они прибывают, тогда скорость сегментов АСК, покидающих
получателя, определяется интервалами между поступающими сегментами, поэто-
му Аг = Рг. Наконец, если интервал времени РЬ достаточно велик для сегмента
данных, он будет достаточно велик для сегмента подтверждения, так что Ab = Аг.
Возвращающиеся от получателя подтверждения действуют как сигналы, зада-
ющие скорость передачи сегментов. При установившемся режиме после началь-
ного всплеска скорость сегментов отправителя будет соответствовать скорости
поступления подтверждений. То есть скорость сегментов отправителя равна ско-
рости сегментов на самом медленном участке пути следования сегментов. Таким
образом, протокол TCP автоматически чувствует узкое место сети и соответству-
ющим образом регулирует поток в ней. Такой режим работы протокола TCP на-
зывают самосинхронизирующимся (self-clocking).
Самосинхронизация работает так же хорошо при возникновении узкого места
у получателя. Предположим, что получатель может принимать сегменты данного
соединения только медленно, что может быть вызвано большой загруженностью
компьютера другими входящими соединениями или обработкой других данных.
Этот случай показан на рис. 12.6, б. Здесь предполагается, что пропускная способ-
ность самого медленного канала сети относительно велика, около половины от
скорости передачи данных источника, но «труба» около получателя узкая. В этом
случае подтверждения будут генерироваться со скоростью, равной скорости, с кото-
рой получатель может принимать сегменты данных, а поток подтверждений опре-
деляет скорость передачи данных отправителя. Таким образом, сегменты прибы-
вают именно с той скоростью, которую может выдержать получатель.
Рисунок 12.6 иллюстрирует один важный момент. У источника нет способа
определить, чье состояние отражает скорость получаемых им подтверждений, —
состояние объединенной сети (борьба с перегрузкой) или состояние получателя
368
Глава 12. Управление трафиком в протоколе TCP
(управление потоком). Если подтверждения прибывают относительно медленно
из-за перегрузки сети источнику, возможно, следует передавать сегменты еще мед-
леннее, чем та скорость, с которой он получает подтверждения, чтобы помочь уст-
ранить перегрузку. С другой стороны, если низкая скорость поступления подтвер-
ждений вызвана желанием получателя, управляющего потоком, тогда отправителю
следует придерживаться данной скорости.
Рис. 12.6. Пошаговое продвижение ТСР-сегментов
Узкое место на пути между отправителем и получателем может возникнуть в са-
мых разных местах, атакже может быть логическим или физическим. Рисунок 12.7
иллюстрирует эти варианты. В данном примере, если отправитель выделяет одно-
му TCP-соединению всю пропускную способность локальной сети, тогда оно об-
ладает потенциальной пропускной способностью в 10 Мбит/с. В этом случае ка-
налы с пропускной способностью в 1,5 Мбит/с между каждым маршрутизатором
и промежуточной объединенной сетью становятся узкими местами. Это физичес-
кое узкое место, и как только сеть выходит па установившийся режим, протокол
TCP может эффективно использовать доступную пропускную способность. Одна-
ко чаще узкое место бывает логическим, вызванным очередями на маршрутизаторе,
сетевом коммутаторе или у получателя. Подобные вызванные очередями задерж-
12.2. Борьба с перегрузкой в TCP
369
ки изменяются вместе с изменением суммарной нагрузки, в результате оказыва-
ется трудно достичь потока установившегося режима.
Рис. 12.7. Контекст управления потоком и борьбы с перегрузкой протокола TCP
Отклонения значений задержки, присущие объединенным IP-сетям, являются
серьезной проблемой при разработке политик потоков для TCP-источников. Если
TCP-потоки слишком медленны, тогда объединенная сеть загружена недостаточ-
но, а пропускная способность оказывается излишне низкой. Если один или не-
сколько TCP-источников неумеренно расходуют ресурсы, тогда остальные ТСР-
потоки будут переполнены. Если многие TCP-источники неумеренно расходуют
ресурсы, тогда сегменты будут теряться при переносе, в результате потребуется
их повторная передача, либо подтверждения будут прибывать с очень большим
опозданием, вследствие чего у отправителей будет истекать время ожидания и они
будут повторно передавать сегменты, не требующие повторной передачи. Более
того, подобные повторные передачи могут оказать эффект положительной обрат-
ной связи. Чем больше сегментов передается повторно, тем сильнее становится
перегрузка, в результате в сети возрастают задержки и количество потерянных сег-
ментов. Все это приводит к увеличению количества повторных передач, усугубля-
ющих проблему.
Хотя механизм скользящего окна TCP был разработан для сквозного управле-
ния потоком, он должен использоваться и для борьбы с перегрузкой. С момента
опубликования рекомендаций RFC 793 был реализован ряд методов, цель ко-
торых заключалась в улучшении характеристик борьбы с перегрузкой протоко-
ла TCP. В табл. 12.1 перечислены некоторые из наиболее популярных методов.
Ни один из них не расширяет оригинальный стандарт TCP и не противоречит
этому стандарту. Напротив, они представляют реализацию политик, входящих
в спецификацию TCP. В таблице указано, которые из этих методов рекомендова-
ны стандартом RFC 1122 и/или реализованы в популярной версии операционной
системы UNIX, разработанной в университете Беркли. Две следующих одна за
другой версии кода Berkeley TCP, называемые Tahoe и Reno, часто упоминаются
в литературе, посвященной различным методам борьбы с перегрузкой на уровне
протокола TCP.
370
Глава 12. Управление трафиком в протоколе TCP
Таблица 12.1. Реализация средств борьбы с перегрузкой TCP
Средство RFC 1122 TCP Tahoe TCP Reno
Оценка изменчивости RTT V V V
Экспоненциальный откат RTO V V V
Алгоритм Карна V V V
Затяжной пуск V V V
Динамическое изменение размера окна при перегрузке V V V
Быстрая повторная передача V V
Быстрое восстановление V
Управление повторными передачами
при помощи таймера
Первые три метода, которые мы изучим, относятся к вычислению тайм-аута по-
вторной передачи (RTO). Значение этого тайм-аута может оказать решающее дей-
ствие на реакцию протокола TCP на возникновение перегрузки. Этими методами
являются:
♦ оценка изменчивости RTT;
♦ экспоненциальный откат RTO;
♦ алгоритм Карна.
Оценка изменчивости RTT
Метод, указанный в спецификации стандарта TCP и описанный в формулах (12.4)
и (12.5), позволяет ТСР-сущности адаптироваться к изменениям времени прохож-
дения сигнала в оба конца (RTT). Однако этот метод плохо справляется с ситуа-
цией, в которой изменчивость времени прохождения сигнала в оба конца относи-
тельно высока. В [244] указывается на три источника этой высокой изменчивости:
♦ Если скорость передачи данных по TCP-соединению относительно низкая,
тогда задержка передачи будет относительно большой по сравнению с вре-
менем распространения сигнала и изменчивость задержки, вызванная из-
менчивостью размера IP-дейтаграмм, окажется существенной. Таким обра-
зом, на метод оценки SRTT оказывают сильное влияние характеристики
данных, а не сети.
♦ Нагрузка трафика и условия объединенной сети могут внезапно изменить-
ся из-за трафика от других источников, вызывая резкие изменения RTT.
♦ Одноранговая ТСР-сущность может не подтверждать получение каждого
сегмента немедленно после его поступления в связи с собственными задерж-
ками обработки и правом использовать кумулятивные подтверждения.
В оригинальной спецификации протокола TCP делаются попытки учиты-
вать эту изменчивость, умножая оцениваемое значение RTT на постоянную ве-
личину:
RTO(K + 1) = Р • SRTT(X + 1).
12.2. Борьба с перегрузкой в TCP
371
Как правило, используется величина р = 2. В стабильном окружении с низкой
изменчивостью RTT применение этой формулы приводит к излишне высоким зна-
чениям RTO, тогда как в нестабильном окружении коэффициент 2 может оказать-
ся недостаточным, чтобы защитить от излишних повторных передач.
Более эффективный метод заключается в оценке дисперсии RTT и использо-
вании этой величины для вычисления RTO. Один из вариантов заключается в вы-
числении выборочного среднеквадратичного отклонения (см. главу 8). Однако эти
расчеты подразумевают возведение в квадрат и вычисление квадратного корня.
Более простой оценкой изменчивости является среднее линейное отклонение,
определяемое так1:
MDEV(X) = Е[|Х-Е[Л]|].
Здесь Е[Х] представляет собой ожидаемое значение X.
Как и при оценке RTT, для оценки MDEV может использоваться среднее ариф-
метическое:
AERR(K + 1) = RTT(K + 1) - ARTT(K);
1 К 1
ADEV(K +1) = —£I AERR(i)| = ADEV(K) + | AERR(K +1)|.
K+1,=| K + l Л+1
Здесь ARTT(K) представляет собой среднее арифметическое, определенное
в формуле (12.2), a AERR(K) — выборочное среднее линейное отклонение, изме-
ренное в момент времени К.
Как и в случае определения ARTT, каждому слагаемому при вычислении ADEV
придается равный вес, то есть каждое слагаемое умножается на одну и ту же кон-
станту 1/(К +1). Опять же, нам хотелось бы придать больший вес более поздним
результатам измерений, так как они с большей вероятностью отражают будущее
поведение. Якобсон (Jacobson), предложивший динамическую оценку дисперсии
при оценке RTT 1121], предлагает задействовать тот же метод экспоненциального
сглаживания, который использовался при вычислении SRTT. Полный алгоритм,
предложенный Якобсоном, может быть выражен следующим образом:
SRTT(K + 1) = (1 - g) • SRTT(K) + g • RTT(K + 1);
SERR(K +1) = RTT(K +1) - SRTT(K);
(12.o)
SDEV(K +1) = (1 - h) • SDEV(K) + h | SERR(K + 1) |;
RTO(K +1) = SRTT(K + !) + /• SDEV(K +1).
Как и в спецификации RFC 793 (см. формулу (12.4)), SRTT представляет собой
экспоненциально сглаженную оценку RTT, где (1 - g) эквивалентно а. Однако
теперь, вместо умножения оценки SRTT на константу (см. формулу (12.5)) для
получения значения интервала ожидания подтверждения для повторной переда-
чи к SRTT прибавляется оценка среднего линейного отклонения, умноженная на
’ В [121] говорится, что среднее линейное отклонение представляет собой более консервативную оцен-
ку, так как оно больше среднеквадратичного отклонения. В общем случае это нс соответствует дей-
ствительности. Однако среднее линейное отклонение является приемлемой оценкой дисперсии.
372 Глава 12. Управление трафиком в протоколе TCP
некоторый коэффициент. На основе экспериментальных данных в статье [121 и
предложены следующие значения для используемых в вычислениях констант: 1
g= 1/8 = 0,125; I
Л = 1/4 = 0,25;
/=2.
После проведения дополнительных исследований в [ 122] рекомендуется зна-
чение /= 4. Именно оно используется в большинстве сегодняшних реализаций
В последней официальной спецификации алгоритма оценки интервала ожидания
подтверждения для повторной передачи, RFC 2988', формула вычисления этого
интервала была усовершенствована следующим образом:
RTO(K+ 1) = SRTT(K + 1) + MAX[G,/-SDEV(K + 1)].
Здесь/= 4, a G представляет собой степень детализации значений времени, ис-
пользуемых алгоритмом. Таким образом, нулевое или небольшое значение диспер-
сии округляется до G.
Рисунок 12.8 иллюстрирует использование формулы (12.6) с тем же набором
данных, что и па рис. 12.5. Как только значения времени прибытия стабилизиру-
ются, оцениваемая величина дисперсии SDEV начинает уменьшаться. Значения
RTO для/= 2 и/=4 являются консервативными, пока RTT изменяется, но они
начинают стремиться к RTT, когда оно стабилизируется.
Эксперименты показывают, что алгоритм Якобсона может существенно улуч-
шить производительность протокола TCP. Однако следует учитывать еще два
вопроса:
♦ Какое значение RTO следует использовать при повторной передаче сегмен-
та? Это определяет алгоритм экспоненциального отката.
+ Какие значение времени прохождения сигнала в оба конца следует исполь-
зовать в алгоритме Якобсона? Это определяется алгоритмом Карна.
Экспоненциальный откат RTO
Когда у отправителя TCP-сегмента истекает время ожидания подтверждения, он
должен повторить передачу этого сегмента. В рекомендации RFC 793 предполага-
ется, что для этого передаваемого повторно сегмента должно использоваться то
же самое значение RTO. Однако поскольку истечение тайм-аута, скорее всего, вы-
звано перегрузкой сети, проявляющейся в виде увеличения времени прохождения
сигнала в оба конца, поддерживать то же самое значение RTO не слишком хорошо.
Рассмотрим следующий сценарий. Существует несколько активных ТСР-со-
единепий от различных источников, посылающих потоки данных в объединенную
сеть. Возникает область перегрузки, из-за которой многие сегменты этих соедине-
ний теряются или подтверждаются слишком поздно (после истечения интервала
времени RTO). Поэтому приблизительно в то же самое время многие сегменты
будут повторно переданы в объединенную сеть, поддерживая или даже усугубляя
состояние перегрузки. Затем все источники выжидают в течение локального (для
каждого соединения) интервала времени RTO и снова передают свои сегменты.
Такое поведение источников может усугубить состояние перегрузки.
' RFC 2988. Computing TCP’s Retransmission Timer, ноябрь 2000.
12.2. Борьба с перегрузкой в TCP
373
б
Рис. 12.8. Вычисление интервала RTO по методу Якобсона
Более благоразумная политика заключается в том, что TCP-источник увели-
чивает значение своего интервала RTO каждый раз, когда передается повторно тот
же самый сегмент. Этот метод называется процессом отката (backoff). В сцена-
рии, обсуждавшемся в предыдущем абзаце, после первой повторной передачи сег-
мента по каждому соединению все TCP-источники будут ждать в течение более
долгого интервала времени, прежде чем пошлют свои сегменты в третий раз. Этого
времени может оказаться достаточно для того, чтобы объединенная сеть восстано-
374
Глава 12. Управление трафиком в протоколе TCP
вилась после перегрузки. Если же требуется еще одна передача сегмента, источниж
будет ждать в течение еще большего интервала времени, предоставляя объединен
ной сети еще больше времени для восстановления. ц
Простой вариант реализации механизма отката заключается в том, чтобы ум^
пожать RTO на постоянное значение после каждой повторной передачи:
RTO = #-RTO (12.7)
В соответствии с формулой (12.7) интервал RTO растет экспоненциально с каж-
дой повторной передачей. Чаще всего используется значение q = 2. При таком значе-
нии q этот метод называется двоичным экспоненциальным откатом (binary exponential
backoff). Тот же самый метод применяется в протоколе CSMA/CD сети Ethernet.
Алгоритм Карна
Если сегменты не передаются повторно, процесс отбора образцов для алгоритма
Якобсона довольно прост. В расчет может быть включено значение RTT для каж-
дого сегмента. Предположим, однако, что подтверждение для сегмента не прибы-
вает вовремя, и необходима повторная передача сегмента. Если впоследствии при-
ходит подтверждение, возможны два варианта.
♦ Это подтверждение первой передачи сегмента. В этом случае значение RTT
оказывается большим, чем ожидалось, но оно точно отражает состояние сети.
♦ Это подтверждение второй передачи.
TCP-источник не может различить эти два случая. Если получено подтвержде-
ние второй передачи (второй случай), а TCP-сущность просто измеряет интервал
RTT от первой передачи до получения подтверждения, результат измерения будет
слишком большим. Измеряемое значение RTT окажется приблизительно равным
настоящему значению RTT плюс RTO. Если использовать это неверное значение
RTT в алгоритме Якобсона, то мы получим слишком большое значение SRTT, а сле-
довательно, и RTO. Более того, этот эффект продолжается несколько итераций, когда
значение SRTT одной итерации является входным значением в следующей итерации.
Если измерять RTT с момента второй передачи до получения подтверждения,
то результат ошибки будет еще серьезнее. Если в действительности оно окажется
подтверждением первой передачи, тогда измеренное значение RTT будет слишком
малым, в результате чего будут получены слишком малые значения SRTT и RTO.
Это может вызвать эффект положительной обратной связи, что приведет к допол-
нительным повторным передачам и новым неверным измерениям.
Алгоритм Карна (Кат) решает данную проблему при помощи следующих пра-
вил [133]:
♦ Значение RTT, измеренное для повторно переданного сегмента, не исполь-
зуется для обновления значений SRTT и SDEV по формуле (12.6).
+ При повторной передаче вычисляется увеличенное значение RTO с помо-
щью формулы (12.7).
♦ Увеличенное значение RTO используется для последующих сегментов до
тех пор, пока не прибудет подтверждение для сегмента, переданного с пер-
вой попытки.
При получении подтверждения для сегмента, переданного с первой попытки,
снова активируется алгоритм Якобсона для вычисления будущих значений RTO.
12.2. Борьба с перегрузкой в TCP
375
Управление окном
В дополнение к техническим приемам, улучшающим эффективность работы тай-
мера повторной передачи, было изучено несколько методов управления окном пе-
редачи. Размер окна передачи протокола TCP оказывает ключевое влияние на то,
сможет ли протокол TCP эффективно использоваться, не вызывая перегрузки. Мы
обсудим пять важных методов:
♦ затяжной пуск;
♦ динамическое изменение размера окна при перегрузке;
4- быструю повторную передачу;
4- быстрое восстановление;
♦ ограниченную передачу.
Первые четыре метода из данного списка можно встретить практически во всех
современных реализациях протокола TCP'. Ограниченная передача представля-
ет собой не так давно разработанный метод, находящий применение в последнее
время* 2.
Затяжной пуск
Чем больше размер окна передачи, используемого в TCP, тем больше сегментов
TCP-источник сможет послать, прежде чем остановиться и ждать подтверждения.
При обычном ходе событий самосинхронизирующаяся природа TCP (см. рис. 12.6)
соответственно задает темп работы протокола. Однако когда соединение инициа-
лизируется в первый раз, у него нет такого направляющего начала.
Одна из стратегий состоит в том, что TCP-отправитель начинает передачу с от-
носительно большого окна, надеясь впоследствии приблизиться к размерам окна,
которые, в конце концов, будут предоставлены соединением. Это рискованно,
так как отправитель может «затопить» объединенную сеть своими сегментами
прежде, чем по тайм-аутам поймет, что отправленный им поток данных был чрез-
мерным. Вместо этого следует начинать с небольшого окна, постепенно увели-
чивая его.
В [121] рекомендуется использование процедуры, называемой затяжным пус-
ком (slow start). В протоколе TCP используется окно перегрузки, измеряемое не
в байтах, а в сегментах. В любой момент времени передача протокола TCP ограни-
чена следующим соотношением:
awnd - MIN[c?'edz£, cwnd], (12.8)
Здесь:
4- awnd — разрешенный размер окна в сегментах, то есть количество сегмен-
тов, которые ТСР-сущности разрешено послать без подтверждений;
4- cwnd — размер окна перегрузки в сегментах, то есть окна, используемого
протоколом TCP во время запуска, а также во время перегрузки для умень-
шения потока;
' Документирован в RFC 2581, TCP Congestion Control. Апрель 1999.
2 Определен в RFC 3042. Enhancing TCP’s Loss Recovery Using Limited Transmit. Январь 2001.
376 Глава 12. Управление трафиком в протоколе TCP
♦ credit — количество неиспользованных кредитов, измеряемых в сегментах!
предоставленных в самых последних подтверждениях; когда подтверждения
получено, это значение вычисляется как окно/размер_сегмента, где
представляет собой поле во входящем TCP-сегменте (количество данных
которое одноранговая ТСР-сущность желает принять).
При открытии нового соединения ТСР-сущность инициализирует значение
размера окна перегрузки cwnd - 1. Таким образом, ТСР-сущности разрешается
отправить только один сегмент, после чего она должна ждать подтверждения,
прежде чем сможет отправить второй сегмент. При получении каждого подтверж-
дения значение cwndувеличивается на единицу, пока не достигнет некоего макси-
мального значения.
В результате механизм затяжного пуска проверяет состояние объединенной
сети, чтобы гарантировать, что ТСР-сущность не отправляет слишком много
сегментов в уже и так перегруженной среде. Когда прибывают подтверждения,
ТСР-сущность получает возможность открыть свое окно до тех пор, пока поток
управляется поступающими подтверждениями, а не значением cwnd.
Термин затяжной пуск употребляется не совсем корректно, так как значение cwnd
растет экспоненциально. Когда прибывает первое подтверждение, TCP открывает
окно cwnd размером 2, после чего может отправить два сегмента. Когда приходят под-
тверждения к этим двум сегментам, TCP может для каждого принятого подтверж-
дения передвинуть окно на один сегмент и увеличить на единицу значение cwnd.
Поэтому после этого TCP сможет передать уже четыре сегмента. Когда прибудут
подтверждения для этих четырех сегментов, TCP сможет передать восемь сегментов.
Этот процесс иллюстрирует рис. 12.9. В данном примере станция А отправляет 100-
байтовые сегменты и приблизительно через четыре интервала времени прохождения
сигнала в оба конца способна заполнить канал непрерывным потоком сегментов.
Динамическое изменение размера окна при перегрузке
Как обнаружилось, алгоритм затяжного пуска эффективно работает при инициа-
лизации соединения. Он позволяет TCP-отправителю быстро определить ра-
зумный размер окна для этого соединения. Не будет ли полезен данный метод
в случае перегрузки? В частности, предположим, что ТСР-сущность инициирует
соединение и проходит через процедуру затяжного пуска. В определенный момент
времени либо до того, как размер окна перегрузки cwnd достигнет величины кре-
дита, выделенного другой стороной, либо после этого сегмент теряется. При этом
благоразумной процедурой было бы установить cwnd = 1 и начать процесс затяж-
ного пуска заново.
Такие действия выглядят как разумная консервативная процедура, однако в
действительности она недостаточно консервативна. В [121] указывается, что «сеть
легко приводится в состояние насыщения, но ее трудно вывести из этого состоя-
ния». Другими словами, если перегрузка наступила, может понадобиться много
времени, чтобы восстановить рабочее состояние сети1. Таким образом, экспонен-
1 В [137] это явление рассматривается детально и называется эффектом длинной очереди в час пик.
Этот эффект наблюдается для обычного пуассоновского трафика. Если трафик проявляет свойства
долгосрочной зависимости, эффект выражен еще более резко.
12.2. Борьба с перегрузкой в TCP
377
циальный рост размера окна перегрузки cwnd. при затяжном пуске может оказать-
ся слишком агрессивным и усугубить перегрузку. Вместо этого Якобсон предло-
жил после затяжного пуска начинать линейный рост cwnd. Когда истекает период
ожидания, используется следующая процедура.
1. Установить порог затяжного пуска равным половине текущего значения
окна перегрузки, то есть установить ssthresh = cwnd/?..
В
А
CWND = 3
CWND = 4
CWND = 5
CWND = 6
CWND = 7
CWND = 8
CWND = 9
CWND = 10
CWND = 11
CWND = 12
CWND = 13
CWND = 14
CWND = 15
CWND = 16
Рис. 12.9. Эффект работы алгоритма затяжного пуска
378
Глава 12. Управление трафиком в протоколе TCP
2. Установить значение размера окна перегрузки cwnd = 1 и выполнять процесс
до тех пор, пока значение cwnd не станет равным ssthresh. На этом этапе cwnd
увеличивается на единицу при получении каждого подтверждения.
3. Когда cwnd > ssthresh, cwnd увеличивается на единицу через каждый интер-
вал прохождения данных в оба конца.
CWND = 1
CWND = 2
CWND = 3
CWND = 4
CWND = 5
CWND = 6
CWND = 7
CWND = 8
CWND = 9
CWND = 10
CWND = 11
CWND = 12
CWND = 13
CWND = 14
CWND = 15
CWND = 16
Рис. 12.10. Затяжной пуск и предотвращение перегрузки
Алгоритм затяжного пуска иллюстрирует рис. 12.10. На рис. 12.10, а, повторя-
ющем рис. 12.9, показано начало работы соединения. К этому рисунку добавлен
12.2. Борьба с перегрузкой в TCP
379
один финальный сегмент, для которого истекает период ожидания подтверждения.
Поведение после тайм-аута показано на рис. 12.10, б. При этом значение ssthresh
устанавливается равным 8. Вплоть до этой границы протокол TCP выполняет про-
цедуру затяжного пуска, чтобы расширить окно перегрузки. После достижения
этой границы значение cwnd увеличивается линейно. Такое поведение хорошо
видно на рис. 12.11. Обратите внимание на то, что требуется 11 циклов прохожде-
ния данных в оба конца для восстановления уровня cwnd, для чего ранее требова-
лось всего 4 цикла.
Время распространения сигнала в оба конца
Рис. 12.11. Иллюстрация затяжного пуска и предотвращения перегрузки
Быстрая повторная передача
Интервал тайм-аута повторной передачи (RTO), используемого передающей ТСР-
сущностью для определения времени повторной передачи сегмента, как правило,
заметно больше, чем фактическое время распространения сигнала в оба конца (RTT),
требующееся для того, чтобы подтверждение достигло отправителя. Оба алгорит-
ма, оригинальный алгоритм RFC 793 и алгоритм Якобсона, устанавливают значе-
ние RTO несколько выше оценки времени распространения сигнала в оба конца
(SRTT). Это значение выбирается по нескольким причинам.
♦ Значение RTO вычисляется на основе предсказания следующего значения
RTT, оцениваемого по последним значениям RTT. Если время задержки в
сети изменяется, тогда оцениваемое значение RTT может оказаться мень-
ше, чем фактическое значение RTT.
♦ Аналогично, если время задержки у получателя непостоянно, оцениваемое
значение RTT становится ненадежным.
♦ Получающая система может не передавать подтверждение для каждого сег-
мента, а отправлять кумулятивные подтверждения для нескольких сегмен-
тов сразу, а также отправлять подтверждения с попутными данными. Такое
поведение системы является одним из факторов, вызывающих флуктуации
значения RTT.
380
Глава 12. Управление трафиком в протоколе TCP
Последствия этих факторов заключаются в том, что, когда сегмент теряется
протокол TCP может оказаться слишком неторопливым при повторной передаче
сегментов. Если получающая TCP-сущность применяет политику приема сегмен!
тов по порядку номеров (см. раздел 12.1), то могут быть потеряны многие сегмен-
ты. Даже в значительно чаще встречающемся случае использования политики при-
ема сегментов, попадающих в окно, медленная повторная передача может создать
проблемы. Предположим, станция А передает последовательность сегментов, пер-
вый из которых теряется. До тех пор пока ее окно передачи не пусто и интервал
ожидания RTO не истек, станция А может продолжать передачу, не получая под-
тверждения. Станция В получает все эти сегменты, кроме первого. Но станция В
должна хранить в буфере все поступающие сегменты, пока потерянный сегмент
не будет передан еще раз. Она не может освободить буфер, передав данные прило-
жению, пока не прибудет недостающий сегмент. Если повторная передача отсут-
ствующего сегмента откладывается на слишком долгий срок, станции В придется
начать отбрасывать поступающие сегменты.
В [123] предложено две процедуры, называемые быстрой повторной передачей
и быстрым восстановлением, улучшающие производительность при некоторых
обстоятельствах. В процедуре быстрой повторной передачи используется пре-
имущество следующего правила в протоколе TCP. Если TCP-сущность получает
сегмент не в том порядке, она должна немедленно передать подтверждение для
последнего сегмента, полученного в правильном порядке. TCP-сущность будет
продолжать повторять передачу этого подтверждения в ответ на получение каж-
дого входящего сегмента до тех пор, пока не прибудет недостающий сегмент и не
заткнет «дыру» в буфере. Когда дыра заткнута, TCP-сущность передает кумуля-
тивное подтверждение для всех полученных на данный момент сегментов, распо-
лагающихся в буфере по порядку.
Когда принимающая TCP-сущность получает дубликат подтверждения, это
означает один из двух возможных вариантов. Во-первых, следующий за под-
твержденным сегмент может задержаться настолько, что нарушается порядок его
прибытия. Во-вторых, этот сегмент может быть потерян. В первом случае сегмент
в конце концов прибывает к пункту назначения, и поэтому повторная передача не
требуется. Но во втором случае прибытие дубликата подтверждения выполняет
функцию системы раннего предупреждения, сообщающей отправителю, что сег-
мент потерян и требуется его повторная передача. Чтобы гарантировать, что ТСР-
сущность не спутает эти два случая, Якобсон рекомендует дожидаться трех до-
полнительных подтверждений, прежде чем повторно передавать сегмент (таким
образом, всего четыре подтверждения для одного и того же сегмента). При таких
условиях больше вероятность того, что сегмент был потерян, а не задержался,
и для него требуется повторная передача.
Рисунок 12.12 иллюстрирует процесс быстрой повторной передачи. Станция А
передает последовательность сегментов, в каждом из которых 200 байт. Сегмент 1201
теряется, но в обычных условиях станция А не реагирует на это, пока не истечет
период ожидания RTO, а продолжает передачу сегментов вплоть до закрытия ее
окна. Станция В получает сегмент 1001 (байты с 1001-го по 1200-го) и посылает
в ответ подтверждение с номером 1201. Затем она принимает сегмент 1401 (байты
с 1401-го по 1600-й). Поскольку этот сегмент приходит с нарушением порядка,
12.2. Борьба с перегрузкой в TCP
381
станция В повторяет передачу подтверждения 1201 и будет ее повторять при по-
лучении каждого сегмента, пока не прибудет сегмент 1201. К тому моменту, когда
станция А получает четыре подтверждения к сегменту 1001, она уже успела отпра-
вить семь сегментов после сегмента 1201. Станция А немедленно повторяет пере-
дачу сегмента 1201, а затем продолжает с того места, на котором ее прервали.
Рис. 12.12. Алгоритм быстрой повторной передачи
382
Глава 12. Управление трафиком в протоколе TCP
Обратите внимание на то, что станция А полагает, что сегменты после сегмен-
та 1201 добрались до получателя. В противном слу чае станция В не получила бы до-
полнительные сегменты, которые и вызвали передачу подтверждений-дубликатов
Быстрое восстановление
Когда ТСР-сущность повторяет передачу сегмента с помощью алгоритма быстрой
повторной передачи, она понимает (или, вернее, предполагает), что сегмент был
потерян даже несмотря на то, что у нее еще не истек период ожидания подтверж-
дения для этого сегмента. Соответственно, ТСР-сущность должна принять меры
по предотвращению перегрузки. Одна очевидная стратегия заключается в исполь-
зовании процедуры затяжного пуска/предотвращения перегрузки по истечении
периода ожидания подтверждения. Таким образом, ТСР-сущность может устано-
вить значения ssthresh - cwnd/2 и cwnd = 1 и начать экспоненциальный процесс
затяжного пуска, пока cwnd не станет равным ssthresh, после чего увеличивать cwnd
линейно. В [123] утверждается, что такая схема является излишне консервативной.
Как только что отмечалось, сам факт возвращения нескольких подтверждений
свидетельствует о том, что сегменты с данными достигают получателя достаточно
регулярно. Поэтому в [123] предлагается следующий метод быстрого восстанов-
ления: повторить передачу потерянного сегмента, уменьшить размер окна cwnd на-
половину, а затем начать линейно увеличивать cwnd. При таком подходе не требу-
ется начальный экспоненциальный процесс затяжного пуска.
Более точно алгоритм быстрого восстановления можно сформулировать сле-
дующим образом:
1 . Когда прибывает третий дубликат подтверждения:
♦ установить ssthresh = cwnd/2\
♦ повторить передачу недостающего сегмента;
♦ установить cwnd = ssthresh + 3 (число 3 добавляется к ssthresh, так как оно
соответствует количеству сегментов, покинувших сеть и буферизирован-
ных другой стороной).
2 . При получении каждого дополнительного дубликата подтверждения (для
того же сегмента) размер окна cwnd увеличивать на единицу и, по возможно-
сти, передавать сегмент. Таким образом, учитывается тот факт, что дополни-
тельный сегмент покинул сеть и вызвал передачу дубликата подтверждения.
3 . Когда прибывает подтверждение для новых данных (то есть кумулятивное
подтверждение для недостающего сегмента и более поздних сегментов),
установить cwnd = ssthresh.
Работа алгоритма иллюстрируется примером1 из [114], воспроизведенным на
рис. 12.13. Ось ординат на верхнем графике соответствует номерам сегментов2.
Каждый переданный сегмент представлен маленькой ступенькой, высота кото-
рой пропорциональна размеру сегмента. Эти сегменты ограничены двумя лини-
ями: нижняя линия соответствует порядковому номеру последнего подтвержде-
1 В данном примере cwnd выражается не в сегментах, а в байтах. Чтобы перевести эту величину в сег-
менты, разделите cwnd на максимальный размер сегмента, который предполагается равным 1024 байтам.
2 Для простоты помер сегмента представляет собой округленный до целого максимальный порядко-
вый номер, деленный на 1024.
12.2. Борьба с перегрузкой в TCP
383
ния (SND.UNA), а верхняя линия представляет этот порядковый номер плюс
(см. рис. 12.3) размер окна передачи (SND.UNA + SND.WND). Маленькие отмет-
ки на нижней линии обозначают дубликаты подтверждений. На нижнем графике
показано значение cwnd для того же интервала времени.
Рис. 12.13. Пример работы алгоритма быстрого восстановления
384 Глава 12. Управление трафиком в протоколе TCP
В начале этого интервала времени поддерживается постоянный поток дапньи
с постоянным размером окна и заполненным каналом. В течение этого период»
cwnd сохраняет максимальное значение, равное величине кредита получателя
(10 сегментов). Незадолго до момента времени 5,43 (обведенная область) начина*
ют поступать дубликаты подтверждения для сегмента 579. Когда прибывает тре-
тий дубликат, сегмент 580 передается повторно, a cwnd уменьшается по формуле
cwnd = ssthresh + 3. Затем мы входим в область, в которой источник может пере-
давать по одному дополнительному сегменту для каждого полученного дубликата
подтверждения. Обратите внимание на то, что в этой области значения SND.UNA
и SND.WND остаются постоянными. В данном примере источник не может пере-
дать ни одного сегмента, пока cwnd не достигнет своего прежнего значения. В этот
момент источник передает по одному сегменту в ответ на каждый получаемый дуб-
ликат подтверждения. При этом величина cwnd продолжает увеличиваться, что
соответствует буферизированным сегментам на принимающей стороне. Наконец,
незадолго до момента времени 5,6 с приходит кумулятивное подтверждение для
большого количества сегментов. Это подтверждение приходит через время RTT
после повторной передачи сегмента 580. В результате получения кумулятивного
подтверждения cwnd уменьшается до ssthresh, а отправитель входит в линейный
режим предотвращения перегрузки.
Ограниченная передача
Как мы видели, в реализациях протокола TCP применяются два механизма обна-
ружения потери сегмента: адаптивный тайм-аут повторной передачи и метод быст-
рой повторной передачи. Метод быстрой повторной передачи позволяет быстрее
реагировать на потерю сегмента, чем традиционное ожидание подтверждения.
Однако даже у этого метода есть свои недостатки. В частности, если окно пере-
грузки (cwnd) у передающей TCP-сущности мало, тогда механизм быстрой повтор-
ной передачи может не запуститься. Например, предположим, что у отправителя
cwnd = 3. Если один сегмент теряется сетью, тогда к отправителю поступят макси-
мум два дубликата подтверждений. Поскольку для запуска механизма быстрой
повторной передачи необходимы три дубликата подтверждений, отправитель будет
ждать, пока не истечет период ожидания подтверждения, после чего просто повтор-
но передаст потерянный сегмент. Возникают несколько вопросов:
4 При каких обстоятельствах у отправителя будет окно перегрузки малого
размера?
4 Насколько распространено это явление, то есть как часто передающая ТСР-
сущность вынуждена полагаться на тайм-аут повторной передачи, а не на
алгоритм быстрой повторной передачи?
4 Если эта ситуация встречается часто, то почему бы не уменьшить число под-
тверждений, требующихся для запуска механизма быстрой повторной пе-
редачи?
Что касается первого вопроса, в ряде исследований упоминаются три обстоя-
тельства, ведущих к уменьшению размера окна перегрузки ([156], [19], [146]):
4 Имеется только ограниченное количество данных для передачи. ,
12.3. Производительность протокола TCP в сетях ATM 385
4- Получатель накладывает ограничение на свое приемное окно (предоставля-
емый им кредит).
4- Сквозной метод борьбы с перегрузкой по соединению с небольшим произ-
ведением RD (см. обсуждение формулы (12.1)) приводит к уменьшению
размера окна перегрузки.
В ответ на второй вопрос в [19] сообщается об исследовании занятого веб-сер-
вера. Как выяснилось, 56 % повторных передач были вызваны истечением перио-
да RTO, и только 44 % инициированы алгоритмом быстрой повторной передачи.
Наконец (третий вопрос), уменьшение количества дубликатов подтверждений
с большой вероятностью приводит к лишним повторным передачам. Причина это-
го заключается в том, что дубликаты подтверждений могут также вызываться на-
рушением порядка получаемых сегментов. В [23] показывается, что нарушение
порядка следования сегментов является довольно распространенным явлением в
Интернете.
Таким образом, повторная передача после одного или двух дубликатов под-
тверждений представляет собой неудачное решение. Вместо этого в рекоменда-
ции RFC 3042 определяется механизм передачи новых сегментов, даже когда это
не диктуется текущим состоянием перегрузки. В частности, алгоритм ограничен-
ной передачи требует от передающей TCP-сущности отправки нового сегмента,
когда выполняются три условия:
1. Получены два дубликата подтверждений подряд. То есть всего получено три
подтверждения для переданного сегмента.
2. Объявленное окно получающей TCP-сущности допускает передачу сегмен-
та. Таким образом, у передающей TCP-сущности имеется достаточный кре-
дит для передачи нового сегмента.
3. После передачи нового сегмента объем неподтвержденных данных не пре-
восходит cwnd + 2. То есть отправитель может передать только два сегмента
сверх окна перегрузки.
Таким образом, метод ограниченной передачи позволяет передать немного дан-
ных сверх уровня, разрешенного механизмом борьбы с перегрузкой протокола TCP.
12.3. Производительность протокола
TCP в сетях ATM
До недавних пор практически весь опыт работы протоколов TCP и IP был на-
коплен в сетях с относительно новыми характеристиками борьбы с перегрузкой и
качеством обслуживания, такими как глобальные сети Х.25 и локальные сети
IEEE 802. Однако в последнее время стек протоколов TCP/IP все чаще использу-
ется в сетях ATM. Такие сети могут поддерживать сложные функции качества об-
служивания, а также обладают широким спектром средств борьбы с перегрузкой
и управления потоком. Кроме того, в сетях ATM используется небольшая транс-
портная единица, 53-байтовая ячейка, поэтому TCP-сегменты разбиваются на не-
сколько фрагментов.
386
Глава 12. Управление трафиком в протоколе TCP
Распространение протоколов TCP/IP в сетях ATM вызвало целый поток ис-
следований в области производительности таких конфигураций. По существу, воп-
рос заключается в том, как лучше всего управлять размером TCP-сегмента, осу-
ществлять управление окнами и политику борьбы с перегрузкой, с одной стороны,
и реализовывать политики качества обслуживания и управления потоком в сети
ATM, с другой стороны, чтобы достичь высокой пропускной способности ТСР-
трафика, справедливого распределения ресурсов между различными ТСР-соеди-
нениями, а также эффективно использовать базовую сеть ATM. Этот вопрос дья-
вольски сложен из-за множества факторов, которые нужно учитывать. Одним из
факторов является контекст, в котором протокол TCP работает в сети ATM. На-
бор протоколов ТCP/IP может работать в единственной сети ATM или вдоль мар-
шрута в объединенной сети, где помимо других сетей может встретиться одна или
несколько локальных или глобальных сетей ATM.
Поскольку этот вопрос так сложен и во все еще продолжающихся исследо-
ваниях было получено не так уж много результатов, по которым удалось достичь
согласованного мнения, мы не сможем уделить ему здесь много места. В этом раз-
деле мы познакомимся с некоторыми вопросами разработки, а также обсудим не-
которые полученные на данный момент результаты. Начнем с базового описания
работы протокола TCP в среде ATM. Затем рассмотрим некоторые механизмы
борьбы с перегрузкой в сетях ATM, переносящих TCP-трафик. Сначала мы обсудим
случай использования протокола TCP поверх службы UBR, обеспечивающий вза-
имодействие между механизмами борьбы с перегрузкой TCP и ATM. Затем мы
исследуем случай использования протокола TCP поверх службы ABR, при котором
уровень ATM может сигнализировать о состоянии перегрузки протоколам TCP/IP.
Архитектура протоколов
В типичном варианте реализации набора протоколов TCP/IP поверх ATM исполь-
зуется следующий стек протоколов:
♦ TCP;
♦ IP;
♦ AAL 5;
♦ ATM.
Вспомним, что уровень адаптации ATM (AAL) отвечает за преобразование
каждого модуля данных протокола более высокого уровня в ячейки ATM. Уро-
вень AAL, в свою очередь, состоит из двух подуровней: подуровня конверген-
ции (Convergence Sublayer, CS), предоставляющего функции для поддержания
специфических верхних уровней, и подуровня сегментации и восстановления
(Segmentation And Reassembly Sublayer, SAR), ответственного за упаковку инфор-
мации, получаемой от подуровня конвергенции, в ячейки и распаковку информа-
ции на другом конце. Каждый подуровень может применять заголовки и/или кон-
цевики для выполнения своих функций.
Для поддержания трафика TCP/IP чаще всего используется уровень AAL 5.
В этой версии уровня AAL нет служебных битов на подуровне S AR, который про-
12.3. Производительность протокола TCP в сетях ATM
387
сто разбивает данные подуровня конвергенции на 48-байтовые блоки. На подуров-
не конвергенции, чья основная задача состоит в вычислении контрольной суммы
блока данных CS, используется минимальный концевик.
На рис. 12.14 показан пример взаимоотношений между различными уровнями.
В данном примере в IP-дейтаграмме помещается целый TCP-сегмент При необ-
ходимости TCP-сегмент может быть разбит на несколько фрагментов, каждый из
которых помещается в отдельную IP-дейтаграмму. Однако между 1Р-дейта-
граммой и переносящим ее протокольным модулем данных подуровня CS должно
осуществляться преобразование один в один, то есть в каждом протокольном
модуле данных подуровня CS должна содержаться ровно одна 1Р-дейтаграмма.
Протокольный модуль данных подуровня CS включает 8-байтовый концевик,
а также байты, дополняющие его длину до числа, кратного 48 байтам.
SDU = 1
Рис. 12.14. Пример работы протоколов TCP/IP поверх AAL5/ATM
Протокольный модуль данных подуровня CS сегментируется на блоки по
48 байт, которые запаковываются в ячейки ATM (в нашем примере требуются пять
ячеек). В каждой ячейке, кроме последней, бит типа SDU (см. подраздел «Формат
заголовка» в разделе 5.3) устанавливается в ноль. Этот бит устанавливается в еди-
ницу в последней ячейке, чтобы сигнализировать подуровню SAR о том, что до-
ставлен весь протокольный модуль данных подуровня CS.
388
Глава 12. Управление трафиком в протоколе TCP
На рисунке показан наиболее простой и до настоящего времени наиболее рас-
пространенный способ передачи трафика TCP/IP по сети ATM. Возможны вари-
анты этой структуры, включающие частичное или полное устранение уровня IP.
Эти альтернативы описаны в RFC 19329.
TCP поверх UBR
При изучении вопроса производительности протокола TCP в сетях ATM мы долж-
ны рассмотреть два совершенно разных случая, соответствующих используе-
мым классам служб ATM: ABR (Available Bit Rate — доступная битовая скорость)
и UBR (Unspecified Bit Rate — неуказанная битовая скорость). Как упоминалось
в главе 5, обе службы, ABR и UBR, были разработаны для поддержки традиционных
приложений переноса данных в противоположность приложениям, связанным с
передачей видео- и аудиоданных. Как правило, трафик данных является значи-
тельно более неравномерным по сравнению с аудио- или видеотрафиком, а по-
стоянная или близкая к постоянной скорость доставки не требуется. Пользовате-
ля в основном интересует пропускная способность, тогда как у сети беспокойство
вызывает то, что одновременные всплески трафика от различных пользователей
могут вызвать перегрузку коммутаторов, в результате чего те начнут терять ячей-
ки. Служба ABR предназначается для приложений, в которых большое значение
имеет время задержки, как, например, сеансы в режиме подключения (on-line)
между пользователем и сервером. Служба UBR предназначена для приложений,
спокойно относящихся к большим задержкам, таким как приложения передачи
файлов и электронная почта.
Главное практическое различие между службами ABR и UBR заключается в
том, что при использовании службы ABR сеть предоставляет информацию о пере-
грузке пользователю, в результате чего пользователь может снизить или увеличить
скорость передачи данных для достижения большей эффективности. Служба UBR
не предоставляет такой обратной связи, что увеличивает риск появления отбро-
шенных ячеек, а следовательно, объем трафика, который приходится передавать
повторно.
Поскольку служба ABR является относительно новой и значительно более
сложной, чем служба UBR, для TCP-трафика обычно применяется служба UBR.
В этом подразделе мы обсудим, какой производительности можно ожидать при
работе протокола TCP поверх простой службы UBR, а затем рассмотрим вариан-
ты усовершенствования функциональности коммутатора ATM, позволяющие уве-
личить эффективность работы протокола TCP поверх службы UBR.
Производительность простой службы UBR
Прежде чем перейти к изучению вопросов производительности, мы можем сфор-
мулировать несколько очевидных выводов о работе протокола TCP поверх службы
UBR. В любом сетевом окружении протокол TCP сможет достичь максимальной
производительности в том случае, если сегменты не теряются, а следовательно,
1 RFC 1932, IP Over ATM: A Framework Document, апрель 1996.
12.3. Производительность протокола TCP в сетях ATM
389
не требуются повторные передачи. В сети ATM мы сможем гарантировать, что ни
один сегмент не будет потерян, только если у каждого ATM-коммутатора имеется
достаточно большое буферное пространство, равное сумме приемных окон всех
активных TCP-соединений сети. Сумма всех приемных окон протокола TCP опре-
деляет суммарное количество байтов, которые могут поступить в сеть в данный
момент времени. Если в сети достаточно буферов для размещения этого количе-
ства, тогда ни один сегмент не будет потерян.
Однако непрактично резервировать такое большое буферное пространство для
каждого коммутатора ATM, особенно учитывая тот факт, что суммарный размер
приемных окон динамично меняется. Таким образом, мы можем заключить, что
емкость буфера ATM-коммутаторов является критически важным параметром,
влияющим на пропускную способность протокола TCP. Другие факторы также
играют свою роль, но мы начнем изучение этой темы с емкости буфера.
О влиянии размера буфера на производительность протокола TCP сообщается
в статье f 189]. Авторы занимались моделированием сети ATM с простой конфигу-
рацией и следующими характеристиками:
4 Скорость передачи данных — 141 Мбит/с.
4 Сквозная задержка распространения сигнала, не считая задержки комму-
тации, — 6 мкс. Это соответствует двум ячейкам в канале TCP (время рас-
пространения сигнала в прямом и обратном направлениях равно четырем
ячейкам).
♦ Размеры IP-пакетов варьируются от 512 до 9180 байт. Пакеты размером
512 байт часто используются в 1Р-сетях. 1500 байт представляет собой мак-
симальный размер для сети Ethernet, а 9180 байт — размер IP-пакета по
умолчанию в сетях ATM (RFC 1626).
4- Размер окна TCP изменяется в пределах от 8 Кбайт до 64 Кбайт.
♦ Размер буфера ATM-коммутатора для каждого порта вывода варьируется
от 256 до 8000 ячеек. Этот диапазон охватывает большинство коммерческих
продуктов.
• 4 Преобразование TCP-соединений в виртуальные каналы ATM один в один.
♦ У всех TCP-источников есть бесконечные источники данных для переда-
чи. Таким образом, протокол TCP загружает сеть настолько, насколько
он способен в условиях ограничений борьбы с перегрузкой и заданных раз-
меров окон.
В [ 189] эта конфигурация сравнивается с другой, называемой авторами пакет-
ной TCP-конфигурацией. Обе конфигурации идентичны друг другу с той разни-
цей, что в TCP-конфигурации единицей передаваемых данных является IP-дей-
таграмма, а не ATM-ячейка. Предполагается использование сети с коммутацией
пакетов, способной передавать IP-дейтаграммы целиком, без фрагментации. На
рис. 12.15, а показаны результаты моделирования для пакетной ТСР-конфигу-
рации. Даже при небольшом размере буфера коммутатора пакетов возможно дос-
тижение пропускной способности, близкой к максимальной. При небольшом
значении времени RTT механизмам борьбы с перегрузкой и управления потоком
390
Глава 12. Управление трафиком в протоколе TCP
с помощью скользящего окна удается поддерживать очень низкий уровень повто]
ной передачи сегментов, в результате чего удается добиться относительно выс<
кой пропускной способности.
Размер буфера коммутатора. Кбайт
Размер буфера коммутатора, Кбайт
Размер буфера коммутатора, байт
е
Размер буфера коммутатора, байт
г
Рис. 12.15. Производительность работы протокола TCP поверх UBR
На рис. 12.15, б показаны результаты моделирования работы протокола TCP
поверх простой службы UBR. В то время как пакетная ТСР-конфигурация
12.3. Производительность протокола TCP в сетях ATM
391
демонстрирует пропускную способность, превышающую 90 % в широком диа-
пазоне параметров, при использовании протокола TCP поверх простой службы
UBR пропускная способность может падать даже до 34 %. Наблюдаются следую-
щие эффекты:
4 Буферы коммутаторов меньших размеров снижают пропускную способ-
ность. Обратите внимание на то, что в случае пакетной ТСР-конфигурации
этого снижения пропускной способности почти не наблюдается.
4 Использование TCP-сегментов большего размера также снижает пропуск-
ную способность.
Также были получены и другие результаты, не показанные на этих графиках:
4 Использование приемных окон TCP большего размера снижает пропускную
способность.
4 При росте перегрузки, вызванной увеличением количества ТСР-соединений
(а следовательно, большим числом виртуальных каналов), пропускная спо-
собность снижается.
Ключ к пониманию различий между пакетной и ячеечной конфигурациями
с точки зрения производительности прост. Когда из-за перегрузки приходится от-
брасывать отдельную ячейку, все остальные ячейки той же самой 1Р-дейтаграммы
становятся непригодными. Тем не менее сеть ATM продолжает пересылать эти
бесполезные ячейки получателю. Таким образом, наблюдается следующее:
4 Использование буферов меньшего размера увеличивает вероятность от-
брасывания ячеек, а следовательно, растрачивания впустую ресурсов в связи
с передачей бесполезных ячеек.
4 Увеличение размера сегментов приводит к увеличению количества беспо-
лезных ячеек, передаваемых по сети ATM в случае потери одной ячейки.
Кроме того, увеличение размера сегментов увеличивает агрессивность ал-
горитма увеличения TCP-окна, который на этапе предотвращения перегруз-
ки увеличивает размер окна на один сегмент за каждый интервал прохожде-
ния сигнала в оба конца.
Эти результаты подтверждаются другими исследованиями, в которых исполь-
зовались другие сетевые конфигурации. Например, в [202] сообщается об иссле-
довании, включающем спутниковые линии связи с очень большими значениями
RTT. Используя протокол TCP поверх простой службы UBR, авторы сумели до-
стичь коэффициента использования всего лишь 73 %. В [153] и [56] сообщается
о том, что при больших размерах сегментов определенные комбинации размеров
буферов приема и передачи могут привести к катастрофическому падению про-
пускной способности вплоть до нескольких процентов от нормы. В [223] вместо
моделирования ситуации с максимальной нагрузкой используется модель самопо-
добного трафика. Авторы статьи утверждают, что пропускная способность протокола
TCP в большой степени зависит от размера буфера ATM-коммутаторов. В [79]
сообщается о сходных результатах, а также демонстрируется, что увеличение пере-
грузки по-разному влияет на разные TCP-соединения, что приводит к несправед-
ливому распределению ресурсов.
392 Глава 12. Управление трафиком в протоколе TCP
Частичное и раннее отбрасывание пакетов
Результаты всех этих исследований привели к тому, что многие производители
коммутаторов увеличили размеры буферов ATM-коммутаторов. На некоторых
производителей также оказали влияние сделанные в [189] предложения о двух
методах усовершенствования поведения алгоритмов при отбрасывании пакетов
Обе стратегии нацелены на снижение количества повторных передач бесполезных
ячеек.
Метод частичного отбрасывания пакетов (Partial Packet Discard, PPD) рабо-
тает следующим образом. Если какая-либо ячейка отбрасывается, то все последую-
щие ячейки той же IP-дейтаграммы также отбрасываются. Чтобы коммутатор
на уровне ATM мог распознать, какие ячейки принадлежат этой 1Р-дейтаграмме,
алгоритм частичного отбрасывания пакетов должен работать на уровне виртуаль-
ных каналов. Когда коммутатор отбрасывает ячейку, передаваемую по некоему
виртуальному каналу, он начинает отбрасывать все последующие ячейки этого
виртуального канала, пока не встретит ячейку с установленным в единицу битом
SDU в заголовке. Эта ячейка помечает конец модуля данных протокола AAL 5, а
следовательно, конец IP-дейтаграммы. Эта последняя ячейка не отбрасывается.
Поскольку протокол AAL 5 не поддерживает мультиплексирования ячеек от раз-
ных протокольных модулей данных, бит типа SDU можно с успехом использовать
для разграничения 1Р-дейтаграмм.
На рис. 12.15, в показан график производительности алгоритма частичного от-
брасывания пакетов. Как видно, этот алгоритм обеспечивает производительность
лучшую, чем при использовании протокола TCP поверх ATM в чистом виде, но не
так эффективен, как хотелось бы. Улучшение является не столь значительным, так
как алгоритм частичного отбрасывания пакетов отбрасывает только «хвост» дей-
таграммы. В среднем, мы можем ожидать, что отбрасывается только половина по-
врежденной дейтаграммы. Об аналогичных результатах сообщается в [132] и [79].
Более эффективной схемой является метод раннего отбрасывания пакетов
(Early Packet Discard, EPD). В этом случае, когда заполненность буфера коммута-
тора достигает порогового значения, но прежде чем действительно потребуется
отбрасывать ячейки, отбрасывается целая IP-дейтаграмма. Таким образом, когда
коммутатор чувствует, что приближается перегрузка и скоро, возможно, понадо-
бится отбрасывать ячейки, он сам отбрасывает все ячейки I Р-дейтаграммы, начи-
ная с первой. Для этой цели коммутатор ищет в виртуальном канале первую вхо-
дящую ячейку с битом SDU, установленным в 0, следующую за ячейкой с битом
SDU, установленным в 1. Эта ячейка помечает начало новой дейтаграммы, и от-
брасывание ячеек начинается с этой ячейки. В результате стратегия раннего от-
брасывания пакетов эмулирует работу сети с коммутацией пакетов, в которой па-
кеты отбрасываются целиком.
На рис. 12.15, д показан график производительности алгоритма раннего отбра-
сывания пакетов с пороговым значением, установленным на половину от общего
размера буфера. Если не считать буферов очень малых размеров, использование
данного алгоритма позволяет достичь высокой эффективности. О сходных резуль-
татах сообщается в [80].
12.3. Производительность протокола TCP в сетях ATM 393
*
г*
Комбинация алгоритма раннего отбрасывания пакетов и механизма борьбы с
перегрузкой протокола TCP, как кажется, обеспечивает хороший уровень пропуск-
ной способности для среднего TCP-соединения. Алгоритм раннего отбрасывания
пакетов ориентирован на краткосрочные действия, заключающиеся в мгновенной
реакции в случае опасности перегрузки. Действия алгоритма дополняются долго-
срочной ориентацией протокола TCP, реагирующего на потерю пакетов резким
снижением скорости передачи и медленным ее восстановлением.
Алгоритм EPD со справедливым выделением буфера
Несмотря на эффективность алгоритма раннего отбрасывания пакетов, остается
еще одна серьезная проблема — справедливость. Активируясь, механизм EPD
выбирает первый попавшийся полный пакет и отбрасывает его. При этом не учи-
тывается, по которому виртуальному каналу (а следовательно, по которому ТСР-
соединению) переносится этот пакет. Можно предположить, что все ТСР-соеди-
нения будут затронуты в равной мере. Однако в ряде исследований (например,
[80], [98]) отмечается несправедливое обращение алгоритма EPD с ТСР-соедине-
ниями. Для этого есть несколько очевидных причин. Во-первых, обнаруживается,
что алгоритм раннего отбрасывания пакетов чаще отбрасывает короткие, чем длин-
ные IР-дейтаграммы. Когда ATM-коммутатор начинает искать начало пакета, что-
бы отбросить его и освободить буфер, с большей вероятностью он находит начало
одного из более мелких пакетов, и может случиться так, что ему никогда не при-
дется отбрасывать ячейки соединений с пакетами больших размеров. Кроме того,
алгоритм раннего отбрасывания пакетов хуже относится к соединениям, проходя-
щим через множество перегруженных коммутаторов, потому что пакеты в этих
соединениях чаще требуют его вмешательства.
Предложенное усовершенствование алгоритма EPD для достижения большей
справедливости называется методом справедливого выделения буфера (Fair Buffer
Allocation, FBA). О благоприятных результатах использования алгоритма EPD
совместно с методом FBA сообщается в [80] и [98]. Метод справедливого выделе-
ния буфера работает следующим образом. Когда начинает работать алгоритм ран-
него отбрасывания пакетов, коммутатор выбирает пакет из того виртуального ка-
нала, который использует большую, чем остальные виртуальные каналы, часть
буфера.
Чтобы объяснить работу алгоритма справедливого выделения буфера, опреде-
лим следующие параметры для данного ATM-коммутатора (рис. 12.16):
4- В — емкость буфера коммутатора, в ячейках;
♦ R — пороговое значение, запускающее механизм отбрасывания ячеек, R<B;
♦ N — текущее количество ячеек в буфере, N<B',
4- N(i) — текущее количество ячеек г-го виртуального канала в буфере;
♦ V — количество активных виртуальных каналов, то есть количество вирту-
альных каналов, у которых есть хотя бы одна ячейка в буфере.
Выполняется следующее соотношение:
N = ilW)-
394 Глава 12. Управление трафиком в протоколе TCP
могут быть отброшены _______________
Ячейки не отбрасываются
Рис. 12.16. Схема буфера ATM-коммутатора для алгоритма выборочного
отбрасывания и справедливого выделения буфера
Нам будет проще понять механизм справедливого выделения буфера, если мы
сначала рассмотрим более простую схему, называемую выборочным отбрасывани-
ем и предложенную в [98]. Если через коммутатор проходят V активных вирту-
альных каналов, а в буферах коммутатора в данный момент хранятся Мячеек, тог-
да выделение буфера будет справедливым, если для каждого виртуального канала
будет буферизироваться одинаковое количество ячеек. То есть, в идеале, для каж-
дого активного виртуального канала должно буферизироваться N/V ячеек. Для
каждого виртуального канала мы можем сосчитать вес W(z) как отношение фак-
тического количества буферизированных ячеек к идеальному количеству:
w N/V N
Например, если число активных виртуальных каналов V= 10, но виртуальному
каналу VC 1 принадлежит одна пятая всех буферизированных ячеек (N(i)/N = 0,2),
тогда вес виртуального канала VC 1 равен двум. Любое значение веса, большее
единицы, означает, что данный виртуальный канал владеет непропорционально
большой долей ресурсов буфера.
Правило выборочного отбрасывания (selective drop) основано на следующем
условии:
(N>R)W W(i)>Z. (12.9)
Если занятый объем буфера превышает пороговое значение, тогда следующий
входящий пакет по виртуальному каналу VC i отбрасывается, если W(i) превыша-
ет параметр Z. В [98] сообщается об экспериментах, в которых были получены хо-
рошие результаты для значений Z, несколько меньших единицы. Были сделаны
следующие выводы:
♦ Метод выборочного отбрасывания позволяет добиться более справедли-
вого отношения к виртуальным каналам по сравнению с простым алго-
ритмом EPD. Отбрасывание пакета вынуждает соответствующее ТСР-
соединение откатываться назад и уменьшать размер окна. В то же время
буферные ресурсы ATM высвобождаются, а другие TCP-соединения по-
лучают возможность увеличить размеры своих окон и пропускную способ-
ность. Таким образом, метод выборочного отбрасывания работает вместе
с алгоритмом борьбы с перегрузкой протокола TCP, позволяя балансиро-
вать нагрузку.
12.3. Производительность протокола TCP в сетях ATM
395
При увеличении размера буфера ATM-коммутатора увеличивается справед-
ливость и общая пропускная способность.
4- Справедливость снижается при увеличении количества источников.
Оба алгоритма раннего и выборочного отбрасывания пакетов начинают отбра-
сывать пакеты при достижении фиксированного порогового значения. Алгоритм
справедливого выделения буфера с ростом перегрузки начинает применять более
агрессивную политику. Правило FBA основано на следующем условии:
(N>R)H (12.10)
\ — .К j
Как и в случае выборочного отбрасывания (см. формулу (12.9)), метод справед-
ливого выделения буфера отбрасывает пакет виртуального канала VC i при вы-
полнении приведенного выше условия. В случае метода справедливого выделения
буфера W(i) сравнивается с величиной, уменьшающейся с ростом перегрузки.
Если считать последние (В - R) буферных гнезд для ячеек зоной безопасности,
тогда чем большая часть зоны безопасности будет занята, тем с меньшей величи-
ной будет сравниваться значение W(i). При увеличении перегрузки коммутатор
начинает терять пакеты, принадлежащие все большему числу виртуальных кана-
лов, кроме тех, у которых в буфере хранится мало ячеек.
В табл. 12.2, основанной на данных из [98], сравниваются простая служба UBR,
метод EPD, алгоритм выборочного отбрасывания пакетов и метод FBA. Результаты
основаны на моделировании конфигурации сети, состоящей из 10 ТСР-источни-
ков, потоки данных которых проходят через те же самые два АТМ-коммутатора.
Каждый источник посылает максимально разрешенное количество данных в виде
512-байтовых сегментов по одному TCP-соединению. Значение сквозной задерж-
ки равно 15 мкс для конфигурации локальной сети и 15 мс для глобальной сети.
Таблица 12.2. Производительность протокола TCP поверх службы UBR
Конфигурация Число источников Размер буфера, количество ячеек UBR EPD Выборочное отбрасывание FBA
Пропускная способность
Локальная сеть 5 1000 0,21 0,49 0,75 0,88
Локальная сеть 5 2000 0,32 0,68 0,85 0,84
Локальная сеть 5 3000 0,47 0,72 0,90 0,92
Локальная сеть 15 1000 0,22 0,55 0,76 0,91
Локальная сеть 15 2000 0,49 0,81 0,82 0,85
Локальная сеть 15 3000 0,47 0,91 0,94 0,95
Глобальная сеть 5 12 000 0,86 0,90 0,90 0,95
Глобальная сеть 5 24 000 0,90 0,91 0,92 0,92
Глобальная сеть 5 36 000 0,91 0,81 0,81 0,81
Глобальная сеть 15 12 000 0,96 0,92 0,94 0,95
Глобальная сеть 15 24 000 0,94 0,91 0,94 0,96
Глобальная сеть 15 36 000 0,92 0,96 0,96 0,95
продолжения^
396
Глава 12. Управление трафиком в протоколе TCP
Таблица 12.2 (продолжение)
Конфигурация Число источников Размер буфера, количество ячеек UBR EPD Выборочное отбрасывание FBA
Коэффициент справедливости
Локальная сеть 5 1000 0,68 0,57 0,99 0,98
Локальная сеть 5 2000 0,90 0,98 0,96 0,98
Локальная сеть 5 3000 0,97 0,84 0,99 0,97
Локальная сеть 15 1000 0,31 0,56 0,76 0,97
Локальная сеть 15 2000 0,59 0,87 0,98 0,96
Локальная сеть 15 3000 0,80 0,78 0,94 0,93
Глобальная сеть 5 12 000 0,75 0,94 0,95 0,94
Глобальная сеть 5 24 000 0,83 0,99 0,99 1
Глобальная сеть 5 36 000 0,86 1 1 1
Глобальная сеть 15 12 000 0,67 0,93 0,91 0,97
Глобальная сеть 15 24 000 0,82 0,92 0,97 0,98
Глобальная сеть 15 36 000 0,77 0,91 0,89 0,97
В верхней части таблицы приводится сравнение значений пропускной способ-
ности. Суммарная нормализованная пропускная способность вычисляется так:
Ух
Пропускная способность = у
Здесь:
4- X, — пропускная способность i-го ТСР-источника;
♦ V — количество TCP-источников (равно количеству виртуальных каналов);
♦ М — максимальная возможная пропускная способность TCP.
Как видно из таблицы, метод FBA совсем ненамного лучше, чем алгоритм вы-
борочного отбрасывания пакетов. В нижней части таблицы приведены значения
коэффициента справедливости, вычисляемого по следующей формуле:
с (Z^.)2
Справедливость = ——=-.
v-Xu2)
Это нормализованная дисперсия значений х,-. Как видно из таблицы, метод
выборочного отбрасывания значительно лучше, чем метод раннего отбрасывания
пакетов (EPD), а метод справедливого распределения буфера (FBA) лишь нена-
много лучше метода выборочного отбрасывания.
TCP поверх ABR
Как было показано, путем несложной настройки коммутирующих механизмов
можно достичь хорошей производительности при работе протокола TCP поверх
службы UBR. Эти результаты снижают потребность в более сложной и более
дорогостоящей службе ABR. Однако на сегодняшний день только служба ABR
12.3. Производительность протокола TCP в сетях ATM
397
полностью определена ATM-форумом и с большой вероятностью будет реализо-
вываться производителями ATM-коммутаторов. Соответственно, стоит изучить
производительность использования протокола TCP поверх службы ABR.
Оценка производительности работы протокола TCP поверх службы ABR еще
сложнее, чем случай TCP-UBR, и общие выводы трудно сформулировать. В дан-
ном подразделе мы обсудим некоторые вопросы разработки и результаты трех не-
давних исследований.
Влияние службы ABR на потоки TCP
Как уже обсуждалось в главе 5, служба ABR представляет собой протокол, инфор-
мирующий источник о доступных для него сетевых ресурсах (более подробно об
этом будет рассказываться в главе 13). Для каждого виртуального канала, пользу-
ющегося службой ABR, вначале устанавливаются минимальная скорость ячеек
(Minimum Cell Rate, MCR) и пиковая скорость ячеек (Peak Cell Rate, PCR). Меха-
низм ABR предоставляет источнику объем ресурсов, обеспечивающий, по мень-
шей мере, скорость MCR, а также дополнительный объем из ресурсов, совместно
используемых активными ABR-соединениями. При увеличении нагрузки в сети
все меньше ресурсов доступно отдельным виртуальным каналам, а следовательно,
отдельным ТСР-соединениям.
Алгоритм управления потоком ABR может работать в двух режимах: двоичном
режиме и режиме явного указания скорости. В двоичном режиме коммутатор сиг-
нализирует источнику о начале или конце перегрузки. При этом источник может
изменить скорость передачи данных в большую или меньшую сторону. В режиме
явного указания скорости ATM-коммутатор пользуется управляющим алгорит-
мом для распределения ресурсов виртуальным каналам, проходящим через дан-
ный коммутатор. Затем коммутатор посылает явное указание о скорости каждому
источнику. Получив такое сообщение, источник соответственно настраивает свою
скорость передачи. В обоих режимах поведения алгоритма ABR определяется
большим количеством параметров, что усложняет моделирование и анализ про-
изводительности.
В [130] отмечается, что протокол TCP поверх службы ABR работает в двух со-
вершенно разных режимах: режиме ограниченного окна и режиме ограниченной
скорости. В режиме ограниченного окна (window limited mode) TCP-источник
управляется TCP-потоком и средствами борьбы с перегрузкой. Когда устанавли-
вается TCP-соединение и ему назначается виртуальный канал, служба ABR, как
правило, выделяет источнику относительно высокую скорость, уменьшая ее толь-
ко в случае перегрузки. Таким образом, на какое-то время TCP-сущность может
отправлять столько данных, сколько ей нужно. То есть эта скорость определяется
окном перегрузки и механизмом затяжного пуска TCP. Как видно из рис. 12.9,
TCP-трафик начинается с короткого активного периода (один сегмент), за кото-
рым следует долгий (в один интервал RTT) период бездействия. Затем период ак-
тивности удваивается, а период бездействия уменьшается, пока TCP-сущность не
начинает передавать данные непрерывно. Поскольку протокол TCP готов отправ-
лять сегменты непрерывно, может возникнуть перегрузка, и соединение перехо-
дит в режим ограниченной скорости (rate limited mode). Механизм ABR оказывает
давление на TCP-источник, который, в свою очередь, может снизить скорость
398
Глава 12. Управление трафиком в протоколе TCP
передачи TCP-сегментов. Через один интервал RTT снижение скорости передачи
TCP-сегментов приводит к снижению скорости получения подтверждений.
Производительность работы протокола TCP поверх
службы ABR
Одно из наиболее всесторонних на сегодняшний день исследований производитель-
ности работы протокола TCP поверх службы ABR имеется в [79] и [80]. Авторы
изучили 15 параметров, связанных с алгоритмом ABR, и рассмотрели различные
размеры буфера коммутатора и различные значения задержки распространения
данных в сети. Затем они сравнили производительность двоичного режима ABR
с методами UBR-EPD и UBR-EPD-FBA в плане пропускной способности и спра-
ведливости. Глядя на впечатляющее количество вариантов параметров моделиро-
вания. авторы приходят к двум важным выводам.
♦ Производительность и справедливость службы ABR довольно чувствитель-
ны к некоторым параметрам ABR и в некоторых случаях оказываются очень
низкими. Это наводит на мысль о необходимости длительной настройки
параметров ABR в реальных сетевых конфигурациях.
♦ В целом, служба ABR не обеспечивает существенного улучшения по сравне-
нию с более простыми и менее дорогостоящими методами UBR-EPD и UBR-
EPD-FBA. В самом деле, во многих вариантах установки параметров служ-
ба ABR обеспечивает худшую производительность и/или справедливость.
О сходных выводах сообщается в [ 193]. Данное исследование показывает, что
для двоичного режима службы ABR (по сравнению с простой службой UBR) раз-
мер буфера является критически важным параметром. Служба ABR оказалась луч-
ше для одних значений размера буфера, тогда как служба UBR показывала луч-
шие результаты для других значений. Авторы также сравнивают работу службы
ABR в режиме явного указания скорости с двоичным режимом и с простой служ-
бой UBR. Они обнаружили, что режим явного указания скорости обеспечивает
лучшую или равную пропускную способность по сравнению с двоичным режимом
или простой службой UBR. Однако если измерять время прохождения ТСР-сег-
мента в оба конца с большей точностью, то это преимущество становится не столь
ощутимым. При этом протокол ТСР может быстрее обнаружить потерю пакета
и улучшить производительность работы TCP поверх службы UBR.
Наконец, в [ 130] сравнивается простая служба UBR с режимом явного указа-
ния скорости службы ABR. Авторы приходят к выводу, что производительность в
основном зависит от размера буфера ATM-коммутатора. Однако в случае службы
ABR требуемое количество буферов не зависит от количества ТСР-соединений.
Напротив, при использовании этой службы для гарантирования высокой пропус-
кной способности оказывается достаточно ABR-коммутаторов с небольшими бу-
ферами, емкость которых равна произведению пропускной способности на диа-
метральную задержку передачи в оба конца. С другой стороны, для службы UBR,
похоже, требуется буферное пространство, пропорциональное суммарному разме-
ру приемных окон всех TCP-источников. Обратите внимание, однако, на то, что
если на ABR-коммутаторах используются буферы небольшого размера, тогда
очереди на источниках могут стать длинными.
В целом, в вопросе использования службы ABR вместо службы UBR еще мно-
го неясного. Требуются дальнейшие эксперименты и исследования.
12.5. Задания
399
12.4. Рекомендуемые литература
и веб-сайты
Возможно, лучше всего различные стратегии TCP для управления потоком и борь-
бы с перегрузкой освещены в [216]. Классическая статья [121] является важней-
шей для понимания вопросов по данной теме. В [85] рассматриваются недавно
разработанные механизмы борьбы с перегрузкой на уровне TCP, многие из кото-
рых встречаются в реализациях протокола TCP. В [4] обсуждаются методы оцен-
ки производительности реализаций протокола TCP. В [222] описываются средства
анализа производительности протокола TCP на практике, а также предоставля-
ются полезные ссылки.
В [59] целая глава посвящена обсуждению вопросов работы протоколов TCP/IP
в сетях ATM, включая преобразование IP-адресов в адреса ATM и сегментацию
IP-дейтаграмм на АТМ-ячейки. [189] представляет собой классическую статью по
производительности работы протокола TCP поверх ATM. В ней рассматриваются
методы PPD и EPD, а также оцениваются различные факторы, влияющие на про-
пускную способность протокола TCP при работе поверх службы UBR. В [56] ис-
следуется работа протокола TCP поверх службы UBR. Эта книга разъясняет вза-
имоотношения между механизмами управления потоком и борьбы с перегрузкой
протокола TCP и механизмом отбрасывания ячеек коммутатором ATM. Еще од-
ной важной статьей является [179]. [130] представляет собой статью, полезную для
понимания взаимодействия протокола TCP со службой ABR.
Ниже перечислены рекомендуемые веб-сайты.
4- А Т&Т Center for Internet Research. Сайт одной из наиболее активных групп в
области, которой посвящена данная глава. На этом сайте содержится мно-
жество статей и полезных ссылок.
♦ Raj Jain’s home page. На этом сайте содержится множество статей, посвящен-
ных теме, обсуждающейся в этой главе, а также ряд полезных ссылок.
12.5. Задания
1. Две ТСР-сущности обмениваются информацией по надежной сети. Пусть
нормализованное время для передачи сегмента фиксированной длины рав-
но 1. Пусть сквозная задержка распространения равна 3, а для доставки
данных из полученного сегмента пользователю транспортного уровня тре-
буется время 2. Вначале отправитель получает кредит на семь сегментов.
Получатель применяет консервативную политику управления потоком и об-
новляет кредит при каждой возможности. Чему равна максимально доступ-
ная пропускная способность?
2. Рассмотрим транспортный протокол, использующий ориентированную на
соединение сетевую службу. Предположим, транспортным протоколом при-
меняется схема управления потоком путем выделения кредитов, а сетевой
протокол пользуется схемой скользящего окна. Какое взаимоотношение
должно быть между динамическим окном транспортного протокола и фик-
сированным окном сетевого протокола?
400
Глава 12. Управление трафиком в протоколе TCP
3. В схеме управления окном при помощи кредитов (например, в протоколе
TCP) какое резервирование может быть выполнено при распределении кре-
дитов для пакетов, потерянных или доставленных в неверном порядке?
4. Почему параметр масштаба окна ТСР ограничен максимальным значением 14?
5. В оригинальном алгоритме оценки времени SRTT, используемом в прото-
коле TCP, одна из проблем связана с выбором начального значения. В от-
сутствие специальной информации о состоянии сети общепринятый подход
заключается в том, чтобы выбрать произвольное значение, например 3 с
и надеяться, что сеть быстро скорректирует его до приемлемой величины
Заниженная оценка приведет к излишним повторным передачам. Резуль-
татом завышенной оценки будет слишком долгое время ожидания перед
повторной передачей. Кроме того, процесс сходимости оценки SRTT может
оказаться медленным.
а) выберем а = 0,85, SRTT(O) = 3 с, а также предположим, что все измеряемые
значения RTT = 1 с и нет потери пакетов. Чему равно SRTT(19)? Подсказ-
ка: чтобы упростить вычисления, с помощью выражения (1 - а")/(1 - а)
можно переписать формулу (12-4);
б) теперь пусть SRTT(O) = 1 с, а измеряемые значения RTT = 3 с и нет по-
тери пакетов. Чему равно SRTT(19)?
6. Неудачная реализация схемы скользящего окна в протоколе TCP может
привести к крайне низкой производительности. Существует явление, назы-
ваемое синдромом глупого окна (Silly Window Syndrome, SWS), способное
вызвать снижение производительности благодаря ряду факторов. В качестве
примера SWS рассмотрим приложение, занятое переносом длинного фай-
ла, и пусть протокол TCP передает этот файл в виде 200-байтовых сегмен-
тов. Вначале получатель предоставляет кредит в 1000 байт. Отправитель
использует это окно, передавая 5 сегментов по 200 байт. Теперь предполо-
жим, что получатель в ответ на каждый полученный сегмент отправляет
подтверждение и выдает кредит на 200 байт. С точки зрения получателя, это
должно восстанавливать размер окна в 1000 байт. Однако с точки зрения
отправителя, если первое подтверждение прибывает после того, как он от-
правил пять сегментов, он получает окно размером в 200 байт. Теперь допу-
стим, что получатель вычисляет размер окна в 200 байт, но у него есть толь-
ко 50 байт для передачи, после чего он достигает точки «push». Поэтому он
отправляет 50 байт в одном сегменте, после чего посылает 150 байт в следу-
ющем сегменте. Затем он возобновляет передачу данных в виде 200-байто-
вых сегментов. Какое событие теперь может вызвать резкое снижение про-
изводительности? Сформулируйте синдром SWS в более общих терминах.
7. Протоколом TCP предусматривается, что для борьбы с синдромом SWS
меры должны принимать обе стороны — и отправитель, и получатель.
а) предложите стратегию для получателя. Подсказка: пусть получатель
«лжет» о том, сколько буферного пространства доступно в определенных
обстоятельствах. Сформулируйте разумное приблизительное правило
для этого;
12.5. Задания
401
б) предложите стратегию для отправителя. Подсказка: рассмотрите взаимо-
связь между максимально возможным размером окна отправителя и те-
кущим, доступным для передачи объемом данных.
8. Сосчитайте среднеквадратическое отклонение и среднее линейное отклоне-
ние следующих случайных переменных:
а) X, с равной вероятностью принимающей одно из четырех значений: 1,
О, 0, 0;
б) Y, с вероятностью 0,7 принимающей значение 1 и с вероятностью 0,3 при-
нимающей значение 0.
9. Перепишите определение SRTT(К + 1) в формуле (12.6) в виде функции от
SERR(K +1). Поясните полученный результат.
10. ТСР-сущность устанавливает соединение и применяет алгоритм затяжного
пуска. Сколько примерно интервалов времени распространения сигнала в оба
конца пройдет, прежде чем ТСР-сущность сможет отправить W сегментов?
11. Хотя метод затяжного пуска с предотвращением перегрузки представляет
собой эффективное средство борьбы с перегрузкой, его применение в высо-
коскоростных сетях может привести к медленному восстановлению.
а) предположим, что задержка прохождения данных в оба конца составля-
ет 60 мс (например, в канале, пересекающем континент). Пусть использу-
ются линия связи с пропускной способностью 1 Гбит/с и сегменты разме-
ром 576 байт. Определите размер окна, необходимый для 100-процентной
занятости канала, и время, требующееся для достижения этого размера
окна после тайм-аута при использовании метода Якобсона;
б) повторите задание а для сегмента размером 16 Кбайт.
12. При обсуждении метода быстрой повторной передачи утверждалось, что
получатель, возможно, будет вынужден отбросить некоторые прибывшие с
нарушением порядка сегменты, так как его буфер переполнен. По разве окно
отправителя не управляется при помощи кредитов, выдаваемых получате-
лем, таким образом, что переполнение буфера невозможно?
13. В схеме частичного отбрасывания пакетов (PPD), описанной в разделе 12.3,
последняя ячейка дейтаграммы не отбрасывается. Почему?
Глава 13
Управление трафиком
и борьба с перегрузкой
в сетях ATM
Все было прекрасно, пока мы не дошли до арифметической задачи, в кото-
рой вода наливается в ванну по трубе и вытекает из нее через две дырки.
Надо было просто выяснить, сколько потребуется времени, чтобы напол-
нить ванну, но в этот момент мама отложила носки, которые она штопала,
и нетерпеливо защелкала языком.
— Какой дурак станет наполнять водой старую дырявую ванну?
— Это арифметика, девочка, — сказал отец. — Арифметика. Задачка для ума.
— Это означает забивать голову мальчику всякой чепухой, — сказала мама.
— Это не чепуха, Бет, — сказал отец. — Это арифметика. Вода втекает, и на
это требуется время. Она вытекает, и на это тоже нужно время. Сколько
потребуется времени, чтобы наполнить ванну? Вот и все.
— Но кто станет наливать воду в старую дырявую ванну? — упорствовала
мама. — Какому идиоту это придет в голову?
Ричард Левеллин. Как зелен был мой дол
Как и в объединенных IP-сетях, методы управления трафиком и борьбы с пере-
грузкой жизненно важны для успешной работы сетей ATM. Без использования
этих методов трафик, поступающий с узлов пользователя, может превысить про-
пускную способность сети, вызывая переполнение буферов ATM-коммутаторов и
потерю данных.
Из-за высокой скорости передачи данных в сетях ATM и небольшого размера
ячеек организовать эффективную борьбу с перегрузкой значительно труднее, чем
в сетях других типов, включая сети ретрансляции кадров и сети с коммутацией
пакетов. Сложность проблемы заключается в ограниченном количестве служебных
разрядов, с помощью которых можно осуществлять управление потоком ячеек
пользователя. В настоящее время в этой области ведутся интенсивные исследова-
ния, и методы управления трафиком и борьбы с перегрузкой продолжают разви-
ваться. Сектор ITU-T определил ограниченный начальный набор методов управ-
ления трафиком и борьбы с перегрузкой, предназначенных для создания простых
механизмов эффективной работы в реальных сетях. Эти методы описаны в стан-
дарте 1.371. ATM-форум опубликовал более полную версию этого набора в своей
13.1. Требования к управлению трафиком и борьбе с перегрузкой в сетях
403
спецификации управления трафиком 4.1 [18]. Спецификациям ATM-форума по-
священа данная глава.
Мы начнем с обзора проблемы перегрузки и общей структуры управления трафи-
ком, принятой сектором ITU-T и ATM-форумом. В основном структура ориенти-
рована на создание управляющих схем для чувствительного к задержкам трафика,
например трафика видео- и аудиоданных. Эти схемы не годятся для управления
неравномерным трафиком. Далее рассматриваются вопросы управления трафиком,
то есть набор действий, предпринимаемых сетью для предотвращения перегрузки.
Затем мы исследуем методы борьбы с перегрузкой, то есть набор действий, пред-
принимаемых сетью для минимизации интенсивности распространения и длитель-
ности перегрузки в том случае, если перегрузка уже началась. Наконец, мы рассмот-
рим схемы борьбы с перегрузкой, разработанные для управления неравномерным
трафиком и включенные, в службы ABR (Available Bit Rate — доступная битовая
скорость) и GFR (Guaranteed Frame Rate — гарантированная скорость кадров).
13.1. Требования к управлению трафиком
и борьбе с перегрузкой в сетях ATM
Сети ATM заметно отличаются от других коммутируемых сетей характером трафи-
ка, а также характеристиками передачи данных. Большинство сетей с коммутацией
пакетов и ретрансляции кадров поддерживают трафик, не являющийся трафиком
реального времени. Как правило, трафик в индивидуальных виртуальных каналах
или соединениях ретрансляции кадров является неравномерным по природе, и
получающая система ожидает, что входящий трафик в каждом соединении будет
неравномерным. В результате имеет место следующая ситуация:
♦ Сеть не обязана точно воспроизводить характер входящего трафика на вы-
ходном узле.
♦ Для поддержки трафика нескольких логических соединений по физическо-
му интерфейсу' между пользователем и сетью можно использовать простое
статистическое мультиплексирование. Средняя скорость передачи данных,
требующаяся для каждого соединения, меньше пиковой скорости для этого
соединения, и интерфейс пользователь — сеть (User-to-Network Interface,
UNI) должен быть рассчитан на пропускную способность, лишь ненамного
превосходящую среднюю скорость передачи данных для всех соединений.
Как мы видели, для борьбы с перегрузкой в сетях с коммутацией пакетов и сетях
ретрансляции кадров разработано множество средств. Схемы борьбы с перегруз-
кой этого типа не годятся для сетей ATM. В [94] приводятся следующие причины:
4 Большая часть трафика не поддается механизмам управления потоком. На-
пример, источники аудио- и видеотрафика не могут перестать генерировать
ячейки, даже когда сеть перегружена.
♦ Обратная связь является медленной, что вызвано очень небольшим време-
нем передачи ячейки по сравнению с задержкой распространения сигнала в
сети ATM.
404
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
♦ Сети ATM, как правило, поддерживают широкий спектр приложений, ддя
которых требуется пропускная способность, варьирующаяся в диапазоне от
нескольких килобитов в секунду до нескольких мегабитов в секунду. Отно-
сительно простые схемы борьбы с перегрузкой, как правило, кончают тем
что ограничивают тот или иной конец этого спектра.
4 Приложения, работающие в сетях ATM, могут сформировать трафик с самы-
ми различными характеристиками (например, с постоянной или перемен-
ной битовой скоростью). Опять же, традиционным методам борьбы с пере-
грузкой сложно справиться с таким разнообразием.
4 Различным приложениям, работающим в сетях ATM, требуются разные се-
тевые службы (например, чувствительная к задержке служба для передачи
видео- и аудиоданных или чувствительная к потерям служба передачи фай-
ловых данных).
4 Благодаря очень высоким скоростям коммутации и передачи сети ATM ока-
зываются более изменчивыми, что усложняет борьбу с перегрузкой и управ-
ление трафиком. Схема, призванная, главным образом, реагировать на из-
менение условий, будет подвержена сильным изменениям при проведении
политики маршрутизации и управлении потоком.
Два ключевых вопроса производительности, относящиеся к данной теме, — это
влияние отношения задержки к скорости передачи данных и непостоянство задер-
жки доставки ячеек.
Значение задержки и скорости передачи данных
Рассмотрим передачу ячеек ATM по сети со скоростью 150 Мбит/с. На такой скорос-
ти передача одной ячейки в сеть занимает (53 • 8 бит)/( 150 • 106 бит/с) ~ 2,8 • 10 е с.
Время, которое требуется для переноса ячейки от отправителя получателю, зави-
сит от количества промежуточных ATM-коммутаторов, времени коммутации на
каждом коммутаторе и времени распространения сигнала по линиям связи вдоль
пути от отправителя к получателю. Для простоты пренебрежем временем комму-
тации и будем полагать скорость распространения сигнала равной скорости света.
При этом если отправитель и получатель расположены на противоположных бе-
регах Соединенных Штатов, то задержка распространения сигнала в оба конца
составит около 48 • 10*3 с.
При таких условиях предположим, что отправитель А передает получателю В
длинный файл и что используется неявный метод борьбы с перегрузкой (то есть
явных уведомлений о перегрузке нет; отправитель делает вывод о наличии пере-
грузки по потере данных). Если из-за перегрузки сеть теряет ячейку, получатель
может вернуть отправителю сообщение REJECT (отказ). Получив такое сообще-
ние, отправитель должен повторить передачу потерянной ячейки и, возможно, всех
последующих ячеек. Но к тому моменту, когда уведомление доберется обратно до
отправителя, он уже успевает передать дополнительные N ячеек:
48-10~3с
2,8 • 1О'Лс/ячейка
= 1,7- 10' ячеек = 7,2 • 10в бит.
13.1- Требования к управлению трафиком и борьбе с перегрузкой в сетях
405
Таким образом, отправитель успевает передать более 7 Мбит данных, прежде
чем узнает о возникновении перегрузки.
Эти вычисления помогают понять, почему методы, удовлетворительные для
традиционных сетей, не подходят для глобальных сетей ATM.
Непостоянство времени доставки ячеек
Для передачи по сетям ATM аудио- и видеосигналы могут быть оцифрованы и пе-
реданы в виде потока ячеек. Ключевое требование, особенно при передаче речи,
заключается в том, чтобы задержка распространения сигнала по сети была неболь-
шой. Обычно сети ATM удовлетворяют этому требованию. Как уже упоминалось,
сети ATM разрабатывались для минимизации накладных расходов по обработке
и передаче данных в сети, в результате чего становятся возможные очень быстрыми
коммутация и маршрутизация ячеек.
Еще одно важное требование, в определенной степени противоречащее преды-
дущему, заключается в том, что скорость доставки ячеек получателю должна быть
постоянной. Однако скорость доставки ячеек неизбежно будет изменяться, что
вызвано различными событиями, происходящими как в сети, так и в интерфейсе
пользователь — сеть источника. Сначала обсудим, как получатель может справить-
ся с непостоянством времени доставки ячеек.
Общую процедуру достижения постоянной битовой скорости (Constant Bit
Rate, CBR) иллюстрирует рис. 13.1. Пусть D(i) представляет ожидаемое для г-й
ячейки значение сквозной задержки. Получающая система не знает точной вели-
чины этой задержки. Ячейки не снабжаются временными метками, но даже при
использовании временных меток невозможно точно синхронизировать часы
отправителя и получателя. Когда в момент времени to прибывает первая ячейка
соединения, получающая система дополнительно задерживает ее еще на неко-
торое время V(0), прежде чем доставить приложению. Интервал времени Е(0)
представляет собой оценку изменчивости задержки, скорее всего, вызванной сетью,
с которой способно справиться данное приложение.
Последующие ячейки задерживаются и поэтому доставляются пользователю
с постоянной скоростью R ячеек в секунду. Таким образом, интервал времени меж-
ду доставляемыми приложению ячейками (время от начала доставки одной ячей-
ки до начала доставки следующей ячейки) равен б = 1/7?. Чтобы добиться посто-
янной скорости доставки ячеек, следующая ячейка задерживается на время V(1),
удовлетворяющее соотношению
tt + V(l) = to+ V(0) + 5.
Таким образом,
V(l)= V(O)-[tt-(to + 5)].
В общем случае
V(i)= V(0)-[t,-(tb + i-5)].
Последнее уравнение можно также выразить так:
V(i) = V(i-l)-[t,-(tM + 6)].
406
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Время
Рис. 13.1. Временная диаграмма прибытия ячеек в службе CBR
Если сосчитанное значение V(i) отрицательное, тогда i-я ячейка отбрасывает-
ся. В результате данные доставляются более высокому уровню с постоянной ско-
ростью, но с пропусками, вызванными потерей ячеек.
Начальное значение дополнительной задержки Е(0), также являющейся сред-
ней задержкой, применяемой ко всем прибывающим ячейкам, представляет собой
функцию ожидаемой дисперсии задержки. Чтобы минимизировать эту задержку,
подписчик должен запросить минимальный разброс задержки у поставщика сете-
вых услуг. Разброс задержки может быть уменьшен за счет увеличения (по отно-
шению к нагрузке) скорости передачи данных в интерфейсе пользователь — сеть
и за счет увеличения ресурсов сети.
Вклад сети в изменение задержки доставки ячеек
Изменение задержки доставки ячеек, в частности, вызвано событиями внутри сети.
В сети с коммутацией пакетов изменение задержки доставки ячеек в основном
вызывается ожиданием ячеек в очередях на каждом из промежуточных коммути-
рующих узлов и временем обработки, что требуется для анализа заголовков паке-
тов и выбора маршрутов. В значительно меньшей степени это также справедливо
для изменений задержки доставки кадров в сети ретрансляции кадров. В случае
сетей ATM вызванное событиями в сети изменение задержки доставки ячеек
оказывается еще меньшим, чем в сетях ретрансляции кадров. Главные причины
этого указаны далее:
♦ Протокол ATM разработан для того, чтобы минимизировать накладные рас-
ходы на обработку на промежуточных коммутирующих узлах. Используют-
.1. Требования к управлению трафиком и борьбе с перегрузкой в сетях
407
ся ячейки фиксированного размера с заголовками фиксированного форма-
та, и для управления потоком или контроля ошибок обработки не требуется.
4- Чтобы поддерживать высокие скорости сетей ATM, АТМ-коммутаторы
обеспечивают очень высокую пропускную способность. Таким образом, вре-
мя обработки отдельной ячейки на узле оказывается пренебрежимо малым.
Единственный фактор, способный вызвать заметное изменение задержки дос-
тавки ячеек, — это перегрузка. Если в сети возникает перегрузка, она приведет
либо к потерям ячеек, либо к задержкам, вызванным ожиданием в очередях на
перегруженных узлах. Таким образом, важно, чтобы суммарная нагрузка на сеть
не была настолько большой, чтобы вызвать перегрузку.
Изменение задержки доставки ячеек в интерфейсе
пользователь — сеть
Даже если приложение генерирует данные с постоянной скоростью, изменение
задержки доставки ячеек может возникнуть на источнике из-за обработки данных,
производящейся на трех уровнях модели ATM.
Рисунок 13.2 иллюстрирует потенциальные причины изменения задержки до-
ставки ячеек. В данном примере ATM-соединениями А и В поддерживаются ско-
рости передачи данных пользователя X и У Мбит/с соответственно. На уровне
AAL данные разбиваются на 48-байтовые блоки. Обратите внимание на то, что на
временной диаграмме размеры блоков двух соединений кажутся разными; в част-
ности, время, необходимое для формирования 48-байтового блока данных, равно:
А л 48-8
♦ соединение А: ;
а г, 48-8
♦ соединение п: -
Уровень ATM помещает каждый сегмент в 53-байтовую ячейку. Эти ячейки
должны быть доставлены физическому уровню для передачи со скоростью пе-
редачи данных физической линии. В процесс чередования ячеек вмешивается
задержка. Если две ячейки из разных соединений прибывают на уровень ATM
в перекрывающиеся интервалы времени, одной из ячеек придется ждать. Кро-
ме того, уровень ATM генерирует ячейки ОАМ (Operations, Administration and
Maintenance — операции, администрирование и поддержка), которые также долж-
ны чередоваться с ячейками пользователя.
На физическом уровне могут возникнуть дополнительные задержки. Например,
если ячейки передаются в кадрах SDH (Synchronous Digital Hierarchy — синхрон-
ная цифровая иерархия), служебные биты для этих кадров доставляются в физи-
ческую линию, задерживая биты уровня ATM.
Ни одна из только что перечисленных задержек не может быть предсказана
с какой-либо степенью точности, и ни одна из них не следует какому-либо регуляр-
ному графику. Соответственно, в интервале времени между получением данных
уровнем ATM от уровня AAL и передачей этих данных по интерфейсу пользова-
тель — сеть есть случайная составляющая.
408 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
>. Время
48 байт, X Мбит/с
(Соединение А, X Мбит/с)
48 байт, Y Мбит/с
(Соединение В, У Мбит/с)
Уровень ATM
Уровень
ATM
Точка доступа
к службе
. физического уровня
САМ
Накладные расходы
физического уровня
Физический
уровень
Рис. 13.2. Причины изменения задержки доставки ячеек (1.371)
0 AM F5
13.2. Атрибуты трафика сетей ATM
Как уже сообщалось в главе 5, ATM-форумом определены шесть категорий служб
ATM:
4 CBR (Constant Bit Rate — постоянная битовая скорость) требует от постав-
щика услуг предоставления фиксированной скорости передачи данных. Сеть
должна гарантировать доступность этого ресурса, а также следить за тем, что
подписчик не превышает запрошенной скорости,
4 rt-VBR (real-time Variable Bit Rate — переменная битовая скорость реального
времени) предназначена для приложений, которым требуется не фиксиро-
ванная скорость передачи данных, как в случае CBR, а жестко ограниченные
значения задержки и изменения задержки. Соединение VBR определяется
не одним значением скорости, а двумя: значением установившейся скорос-
ти для обычного использования и большим значением пиковой скорости для
случайного использования в периоды пиковой нагрузки. Пиковая скорость
гарантируется, но подразумевается, что пользователь не будет постоянно
требовать пиковую скорость. Кроме того, оговариваются границы значений
задержки передачи ячеек и пределы изменений задержки.
13.2. Атрибуты трафика сетей ATM
409
♦ nrt-VBR (non-real-time Variable Bit Rate — переменная битовая скорость не
реального времени). То же, что и rt-VBR, но без ограничения на величину из-
менения задержки. Кроме того, допускается небольшой процент потерь ячеек.
4- UBR (Unspecified Bit Rate — неуказанная битовая скорость). Служба, рабо-
тающая по остаточному принципу. Пытается предоставить максимум воз-
можного в данной ситуации, но без каких-либо гарантий. Любая ячейка мо-
жет быть потеряна.
♦ ABR (Available Bit Rate — доступная битовая скорость) предоставляет пользо-
вателю гарантированный минимум ресурсов. При наличии дополнительных
ресурсов пользователь может превысить минимальную скорость передачи
данных с минимальным риском потери кадров.
♦ GFR (Guaranteed Frame Rate — гарантированная скорость кадров) предос-
тавляет пользователю гарантированный минимум ресурсов, выраженный
в терминах скорости передачи кадров. При наличии дополнительных ресур-
сов пользователь может превысить минимальную скорость передачи данных
с минимальным риском потери кадров.
Эти категории служб характеризуются рядом атрибутов ATM, распадающихся
на четыре категории:
♦ Описатели трафика описывают характеристики трафика источника и со-
единения. Сеть установит соединение для этого источника только в том слу-
чае, если для поддержания указанного трафика имеется достаточно ресурсов.
♦ Параметры качества обслуживания характеризуют производительность
ATM-соединения в показателях предоставляемого им качества обслужива-
ния. Для данного соединения пользователь запрашивает определенный уро-
вень качества обслуживания.
♦ Перегрузка. На сегодняшний день единственным атрибутом перегрузки
является атрибут обратной связи для службы ABR.
♦ Другие атрибуты. Несколько других атрибутов было определено для служ-
бы UBR.
В табл. 13.1 перечислены атрибуты ATM, а также указана их применимость
к каждой категории служб.
Таблица 13.1. Атрибуты категорий служб ATM
Атрибут Категории служб уровня ATM CBR rt-VBR nrt-VBR UBR ABR GFR
Параметры трафика*
PCR, CDVT5 Указана Указана2 Указана3 Указана
SCR, MBS, Отсутствует Указана Отсутствует
CDVT5
MCR Отсутствует Указана Отсутствует
MCR, MBS, Отсутствует Указана
MFS, CDVT5
продолжение^
410 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Таблица 13.1 (продолжение) GFR
Атрибут Категории служб уровня ATM UBR ABR
CBR rt-VBR nrt-VBR
Параметры качества обслуживания Диапазон CDV Указана Max CTD Указана CLR Указана Не указана Не указана Не указана См. прим. 1 См. прим. 6
Борьба с перегрузкой Обратная связь Не указана Другие атрибуты BCS Не указана MDCR7 Отсутствует Необязательная Необязательная Указана Не указана Отсутствует Не указана
1 Значение параметра CLR мало для источников, настраивающих поток ячеек в ответ на полученную
управляющую информацию. Количественное значение параметра CLR может быть указано пли не
указано в зависимости от конкретной сети.
2 Не может обрабатываться процедурами САС и UPC.
3 Представляет максимальную скорость, с которой ABR-источник может посылать данные. Фактичес-
кая скорость зависит от управляющей информации.
“ Эти параметры либо явно, либо неявно указаны для постоянных виртуальных каналов (Permanent
Virtual Circuit, PVC) или коммутируемых виртуальных каналов (Switched Virtual Circuit, SVC).
5 Атрибут CDVT не передается. В общем случае атрибут CDVTне обязан иметь уникального значения для
соединения. Могут применяться различные значения на каждом интерфейсе вдоль пути соединения.
° Значение параметра CLR мало для кадров, пригодных для гарантированного обслуживания. Количе-
ственное значение параметра CLR может быть указано или не указано в зависимости от конкретной сети.
7 Параме тр MDCR не считается параметром трафика, потому’ что эта спецификация не определяет обя-
зательств службы на основе MDCR.
Параметры трафика
ATM-форумом определен ряд параметров, характеризующих вид трафика ячеек,
передаваемых по ATM-соединению. Этот вид трафика должен рассматриваться с
двух различных точек зрения. Во-первых, существует внутренняя природа трафи-
ка, генерированного источником и переданного в сеть через интерфейс пользова-
тель — сеть. Во-вторых, в сети при движении по ATM-соединению этот поток ячеек
будет изменяться в связи с изменчивостью задержек и отбрасыванием ячеек, не
соответствующих виду трафика источника.
Характеристики источника потока ATM помещаются в описателе трафика
источника (source traffic descriptor), в который входят: пиковая скорость ячеек
(Peak Cell Rate, PCR), установившаяся скорость ячеек (Sustainable Cell Rate, SCR),
максимальный размер всплеска (Maximum Burst Size, MBS), минимальная ско-
рость ячеек (Minimum Cell Rate, MCR) и максимальный размер кадра (Maximum
Frame Size, MFS). He все эти характеристики используются для описания всех
потоков (см. табл. 13.1). Характеристики потока ATM по ATM-соединению поме-
щаются в описателе трафика соединения (connection traffic descriptor), в который
входят: описатель трафика источника, допуск на разброс задержек передачи ячеек
13.2, Атрибуты трафика сетей ATM
411
(Cell Delay Variation Tolerance, CDVT) и согласованное определение, непротиво-
речивым образом описывающее метод выяснения факта соответствия данной
ячейки соединения описателю трафика источника.
Таким образом, структура описателя трафика соединения имеет следующую
форму.
4 Описатель трафика источника:
♦ пиковая скорость ячеек (PCR);
♦ установившаяся скорость ячеек (SCR);
♦ максимальный размер всплеска (MBS);
♦ минимальная скорость ячеек (MCR);
♦ максимальный размер кадра (MFS).
♦ Допуск на разброс задержек передачи ячеек (CDVT).
♦ Согласованное определение.
Параметры PCR, SCR, MBS, MCR и MFS характеризуют трафик, переданный
в сеть, и являются достаточными для принятия сетью решений о резервировании
ресурсов. Как было показано, по меньшей мере частично неравномерность достав-
ки ячеек вызывается сетью, а потому не может быть описана источником. Теперь
мы по очереди рассмотрим эти описатели.
Описатель трафика источника
Пиковая скорость ячеек (PCR) определяет верхнюю границу трафика, которую
запрещено превышать источнику по ATM-соединению. Пиковая скорость ячеек
рассчитывается через период Т, представляющий собой минимальный интервал
между ячейками, таким образом, PCR = 1 /Т. Описатель PCR является обязатель-
ным для служб CBR и VBR.
Установившаяся скорость ячеек (SCR) определяет верхний предел средней ча-
стоты ATM-соединения, вычисляемой за больший, по сравнению с интервалом Г,
период времени. Параметр SCR необходим для спецификации источника VBR. Он
позволяет сети эффективно распределять ресурсы среди нескольких источников
VBR без выделения ресурсов, требуемых для поддержания постоянной скорости
PCR. Описатель SCR используется только в том случае, если SCR < PCR.
Максимальный размер всплеска (MBS) представляет собой максимальное ко-
личество ячеек, которое может быть послано подряд с пиковой скоростью. Если
ячейки посылаются в сеть пакетами по MBS штук, тогда интервалы между этими
пакетами должны быть достаточно большими, чтобы средняя скорость не превы-
шала SCR. Для VBR-источников должны указываться оба параметра, SCR и MBS.
Минимальная скорость ячеек (MCR), используемая для служб ABR и GFR,
определяет минимальное обязательство, требуемое от сети. Допустимо нулевое
значение. Назначение обеих служб, ABR и GFR, заключается в предоставлении
быстрого доступа к неиспользуемым сетевым ресурсам вплоть до скорости PCR,
если эти ресурсы доступны. Величина (PCR - MCR) представляет собой мини-
мальную эластичную составляющую потока данных, для которого сеть предос-
412 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
тавляет гарантию того, что сетевые ресурсы будут справедливо распределены меж-
ду потоками ABR или GFR.
Максимальный размер кадра (MFS) — это максимальный размер кадров или
ячеек, которые могут передаваться по GFR-соединению. Этот параметр имеет
смысл только для службы GFR.
Описатель трафика соединения
В дополнение к описателю трафика источника описатель трафика соединения
включает допуск на разброс задержек передачи ячеек (CDVT) и согласованное
определение. Допуск на разброс задержек передачи ячеек (CDVT) представляет
собой меру изменчивости задержки доставки ячеек, представляемой сетевым ин-
терфейсом (например, SDH) и интерфейсом пользователь — сеть. Другими слова-
ми, это предел изменчивости задержки, вызванной дискретной природой ATM,
накладными расходами физического уровня и функциями уровня ATM, такими
как мультиплексирование ячеек. CDVT выражается через переменную времени т.
Интерпретация переменной т обсуждается в разделе 13.4. Согласованное опре-
деление (conformance definition) используется, чтобы однозначно указать, какие
ячейки соединения в интерфейсе пользователь — сеть являются согласованными.
Сеть может добиваться согласования, отбрасывая помеченные ячейки, превыша-
ющие согласованное определение. Для нахождения согласованного определения
используется алгоритм GCRA (Generic Cell Rate Algorithm — общий алгоритм ско-
рости ячеек), описываемый в разделе 13.4.
Параметры качества обслуживания
ATM-форумом определены следующие параметры качества обслуживания ATM:
♦ диапазон CDV (Cell Delay Variation — разброс задержек передачи ячеек):
maxCTD (maximum Cell Transfer Delay — максимальная задержка передачи
ячеек);
♦ CLR (Cell Loss Ratio — коэффициент потерянных ячеек).
Сначала мы должны определить задержку передачи ячеек (Cell Transfer Delay,
CTD), представляющую собой интервал времени между двумя событиями. Как
правило, параметр CTD означает время с момента передачи первого бита ячейки
интерфейсом пользователь — сеть источника до момента приема последнего бита
ячейки интерфейсом пользователь — сеть получателя. В общем случае параметр
CTD представляет собой переменную, график функции плотности вероятности
которой, как правило, напоминает график, изображенный на рис. 13.3. Как видно
из рисунка, у задержки существует минимальное значение, называемое фиксирован-
ной задержкой. Эта величина включает в себя задержку распространения сигнала
по физическому носителю, задержку обработки данных в системе передачи и за-
держку обработки на коммутаторах. Переменная составляющая задержки, пред-
ставляющая собой разброс задержек передачи ячеек (CDV), вызвана ожиданием
в буферах и планированием.
13.2. Атрибуты трафика сетей ATM
413
Плотность
Рис. 13.3. Функция распределения вероятности задержки доставки ячеек
(для категорий служб реального времени)
Параметр inaxCTD определяет максимальное значение задержки, запрашиваемое
для данного соединения. Величина а представляет собой долю ячеек, задержка
доставки которых превысила пороговое значение. Такие ячейки либо отбрасывают-
ся, либо доставляются с опозданием. Оставшаяся часть ячеек (1 - а) удовлетво-
ряет запрашиваемому уровню качества обслуживания. Величина задержки таких
ячеек оказывается в интервале от фиксированной задержки до maxCTD. Этот интер-
вал называется диапазоном разброса задержек передачи ячеек (pear-to-pear CDV).
Параметр CDV качества обслуживания не следует путать с договорным па-
раметром трафика CDVT. Величина CDV обычно определяется при установке
соединения (для коммутируемых виртуальных соединений) путем переговоров,
тогда как параметр CDVT, как правило, явно устанавливается в интерфейсе
пользователь — сеть, и переговоры о нем не ведутся. Трафик источника должен
соответствовать значению CDVT. Соответствие проверяется и реализуется систе-
мой управления используемыми параметрами, описываемой в разделе 13.4. Нерав-
номерность задержки, описываемая параметром CDVT, вызвана самим трафиком
источника. Сеть пытается предоставить трафику источника значение CDV, о ко-
тором источник с ней договорился при установке соединения. Это значение CDV
представляет собой разность между лучшим и худшим ожидаемыми значениями
задержки сквозной передачи ячейки. Лучший случай соответствует фиксирован-
ной задержке. Худший случай соответствует значению maxCTD. Таким образом,
параметр CDVT представляет собой верхний предел величины CDV в интерфей-
се пользователь — сеть.
Наконец, процент потерянных ячеек представляет собой просто отношение
потерянных ячеек к общему количеству переданных через соединение ячеек.
414 Глава 13, Управление трафиком и борьба с перегрузкой в сетях ATM
Атрибуты борьбы с перегрузкой
Единственный атрибут борьбы с перегрузкой, определенный на сегодняшний
день, — это атрибут обратной связи (feedback), применяющийся в службах ABR
и GFR. Управление с помощью обратной связи определяется как набор действий
предпринимаемых сетью и оконечными системами для регулирования трафика
проходящего через ATM-соединения, в соответствии с состоянием элементов сети.
Спецификацией управления трафиком ТМ 4.1 определен один сетевой механизм
с применением обратной связи: управление потоком в службе ABR. Управление
потоком ABR может использоваться для динамического разделения пропускной
способности среди нескольких пользователей. В будущем также может быть до-
бавлен управляющий механизм обратной связи для службы GFR.
Другие атрибуты
Селектор класса поведения (Behavior Class Selector, BCS) был введен в дополне-
ние к спецификации управления трафиком ТМ 4.1 в июле 2000 г. Его цель со-
стоит в поддержании свойства дифференцированных служб протокола IP, о чем
будет говориться в главе 16. Параметр BCS позволяет сети ATM предоставлять
различным UBR-соединениям разные уровни обслуживания, ассоциируя каждое
соединение с одним из имеющихся классов поведения. Сетевые ресурсы, такие как
ресурсы очередей и планирования, могут быть ассоциированы с классом поведе-
ния. Как множество классов поведения, так и сетевые механизмы и ресурсы, отно-
сящиеся к классам поведения, в настоящий момент зависят от конкретной реали-
зации и в спецификации не определены.
Параметр минимальная желаемая скорость ячеек (Minimum Desired Cell Rate,
MDCR) был введен в другом дополнении к спецификации управления трафиком
ТМ 4.1 в июле 2000 г. Он позволяет UBR-приложению указать желаемую мини-
мальную пропускную способность. Один из примеров приложений, для которых
такое расширение спецификации может быть полезно, — это соединение 1Р-марш-
рутизаторов соединениями VСС и VPC, где желателен минимальный поток данных
с информацией о доступности ресурсов, диагностике и с другой системной инфор-
мацией. Параметр MDCR отличается от параметров, ассоциированных с другими
категориями служб ATM, тем что его семантика намеренно сделана зависящей от
реализации или от конкретной сети. Влияние параметра MDCR на сквозную служ-
бу в данной спецификации не определено. Эффект задания конкретного значения
параметра MDCR может различаться в разных сетях или в соединениях, связыва-
ющих несколько сетей.
13.3. Структура управления трафиком
В спецификации 1.371 перечислены следующие требования к механизмам управ-
ления трафиком и борьбы с перегрузкой, функционирующим на уровне ATM:
♦ Механизмы управления трафиком и борьбы с перегрузкой должны поддер-
живать набор классов качества обслуживания уровня ATM, достаточный
для всех обозримых сетевых служб. Спецификация этих классов качества
13.3. Структура управления трафиком
415
обслуживания должна соответствовать параметрам сетевой производитель-
ности, находящимся в настоящий момент в стадии изучения.
♦ Механизмы управления трафиком и борьбы с перегрузкой не должны пола-
гаться на протоколы AAL, специфические для каждой сетевой службы, а
также на протоколы более высокого уровня, специфические для каждого
приложения. Информация, предоставляемая уровнем ATM, может исполь-
зоваться протоколами уровня выше ATM для повышения коэффициента
использования сети.
♦ Оптимальный набор механизмов управления потоком и борьбы с перегруз-
кой па уровне ATM должен минимизировать сложность сети и оконечных
систем и в то же время максимизировать загрузку сети.
Для этих требований сектор ITU-T определил набор функций управления по-
током и борьбы с перегрузкой, работающих в широком спектре временных интер-
валов. Эти функции, сгруппированные в соответствии со временем отклика, пере-
числены в табл. 13.2. Рассматриваются четыре уровня временных интервалов:
♦ Время ввода ячейки. Функции этого уровня реагируют на ячейки немедленно.
♦ Время распространения сигнала в оба конца. На этом уровне сеть реагирует
в течение времени жизни ячейки в сети и может предоставить источнику
обратную связь.
♦ Время действия соединения. На этом уровне сеть определяет, может ли быть
установлено новое соединение с требуемым уровнем качества обслужива-
ния, и согласует уровни производительности.
♦ Долгосрочный период. Это управляющие механизмы, затрагивающие сразу
несколько ATM-соединений и устанавливаемые для долгосрочного исполь-
зования.
Таблица 13.2. Функции управления потоком и борьбы с перегрузкой
Время отклика Функции управления потоком Функции борьбы с перегрузкой
Долгосрочный период Время действия соединения Управление ресурсами при помощи виртуальных путей Управление допуском к соединению
Время распространения Быстрое управление Явное прямое уведомление
сигнала в оба конца ресурсами о перегрузке; управление потоком ABR
Время ввода ячейки Контроль параметров использования; Контроль приоритетов; формирование трафика Выборочное отбрасывание ячеек; отбрасывание кадров
В основе стратегии управления потоком лежат, во-первых, определение воз-
можности установки нового ATM-соединения и, во-вторых, договоренность с под-
писчиком о поддерживаемых параметрах производительности. В результате под-
писчик и сеть заключают соглашение о трафике. Сеть соглашается поддерживать
416 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
трафик на определенном для данного соединения уровне, а подписчик обязуется
не превышать определенного уровня пропускной способности. Функции управ,леВР"
ния трафиком занимаются установкой этих параметров и их поддержкой. Таки Л
образом, они обеспечивают предотвращение перегрузки. Если функции управ щЗ*"
ния трафиком в какой-либо момент времени допускают сбой, в сети может воз-
никнуть перегрузка. С этого момента запускаются функции борьбы с перегрузкой
13.4. Управление трафиком
Для поддержания определенных уровней качества обслуживания в АТМ-соеди-
нениях сектором ITU-T и ATM-форумом определен ряд функций управления тра-
фиком. Функцией управления трафиком ATM называется набор действий, пред-
принимаемых сетью, чтобы избежать перегрузки или минимизировать ее эффект.
Были определены следующие функции:
♦ управления ресурсами при помощи виртуальных путей;
управления допуском к соединению;
♦ контроля параметров использования;
♦ выборочного отбрасывания ячеек;
♦ формирования трафика;
♦ явного прямого уведомления о перегрузке.
Мы рассмотрим их все по очереди.
Управление ресурсами при помощи
виртуальных путей
Основная идея управления сетевыми ресурсами заключается в их распределении
таким образом, чтобы разделить потоки трафика в соответствии с характеристика-
ми служб. На сегодняшний день единственная определенная ATM-форумом функ-
ция управления трафиком, относящаяся к сетевым ресурсам, работает на основе
виртуальных путей.
Как говорилось в главе 5, соединение виртуального пути (VPC) предоставляет
удобное средство группирования близких по свойствам соединений виртуальных
каналов (VCC). Сеть предоставляет виртуальному пути совокупную пропускную
способность и обеспечивает нужные характеристики производительности, а эти ре-
сурсы коллективно используются виртуальными каналами. Можно рассмотреть
три случая;
♦ Приложение пользователь — пользователь. Соединение виртуального пути
связывает пару интерфейсов пользователь — сеть. В этом случае сеть не знает
о качестве обслуживания отдельных соединений виртуальных каналов, вхо-
дящих в данное соединение VPC. Гарантировать удовлетворение соедине-
нием VPC совокупных требований соединений VCC должен пользователь.
♦ Приложение пользователь — сеть. Соединение VPC связывает интерфейс
пользователь — сеть и сетевой узел. В этом случае сеть знает о качестве j
13.4. Управление трафиком
417
5
обслуживания соединений VCC, входящих в соединение VPC, и должна
обеспечивать соответствующий уровень качества обслуживания.
+ Приложение сеть — сеть. Соединение VPC связывает два сетевых узла.
И в этом случае сеть знает о качестве обслуживания соединений VCC, вхо-
дящих в соединение VPC, и должна обеспечивать соответствующий уровень
качества обслуживания.
Для управления сетевыми ресурсами самыми важными параметрами качества
обслуживания являются доля потерянных ячеек, максимальная задержка передачи
ячеек и диапазон изменения задержек передачи ячеек. Все эти параметры зависят от
объема ресурсов, выделенных соединению VPC сетью. Если соединение VCC про-
ходит через несколько соединений VPC, тогда пропускная способность каждого
соединения VCC зависит от пропускных способностей следующих друг за другом
соединений VPC и от того, как поддерживается соединение на каждом узле, выпол-
няющем функции, имеющие отношение к соединению VCC. Такой узел может
быть коммутатором, концентратором или сетевым устройством. Пропускная способ-
ность каждого соединения VPC зависит от ресурсов, которыми обладает данное
- соединение VPC, а также от характеристик трафика соединений VCC, входящих
в данное соединение VPC. Производительность каждой функции, имеющей отноше-
ние к соединению VCC, зависит от скорости коммутации/обработки на узле, а так-
же от относительных приоритетов, с которыми обрабатываются разные ячейки.
На рис. 13.4 показан пример. Пропускная способность соединений VCC 1 и VCC 2
зависит от соединений VPC b и VPC с, а также от того, как эти соединения VCC
обрабатываются промежуточными узлами. Их пропускная способность может от-
личаться от пропускной способности соединений виртуальных каналов VCC 3,
VCC 4 и VCC 5. На рисунке символами VP-Sw и VC-Sw обозначены, соответ-
ственно, функция коммутации виртуальных путей и функция коммутации вирту-
альных каналов.
Рис. 13.4. Конфигурация соединений VCC и VPC
418
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Соединения VСС могут по-разному группироваться и обладать разной пропуск-
ной способностью. Если все соединения VCC, входящие в одно соединение VPc
обрабатываются одинаково, тогда можно ожидать, что у них будет одинаковая про-
пускная способность, а также такие характеристики, как доля потерянных ячеек
задержка передачи ячеек и разброс задержек передачи ячеек. Однако если раз-
личным соединениям VCC, входящим в одно соединение VPC, требуются разные
уровни качества обслуживания, тогда при заключении договора между сетью и
подписчиком во время установки соединения должны учитываться потребности
соединения VCC, предъявляющего самые высокие требования.
В любом случае при использовании нескольких соединений VCC, входящих
в одно соединение VPC, у сети есть два общих варианта выделения ресурсов со-
единению VPC:
♦ Совокупный пиковый запрос. Сеть может выделить соединению VPC доста-
точный объем ресурсов для поддержания пропускной способности, равной
суммарной пиковой скорости передачи данных всех соединений VCC, вхо-
дящих в данное соединение VPC. Достоинство такого подхода заключается
в том, что каждому соединению VCC может быть предоставлен уровень ка-
чества обслуживания, соответствующий его пиковым требованиям, а недо-
статок — в том, что большую часть времени ресурсы соединения VPC будут
недогружены.
♦ Статистическое мультиплексирование. Если сеть выделяет соединению VPC
объем ресурсов, соответствующий средней скорости передачи данных всех
соединений VCC или несколько больший, но меньший, чем совокупный
пиковый запрос, то это означает предоставление услуги статистического
мультиплексирования. При статистическом мультиплексировании соедине-
ния VCC допускают больший разброс задержек и большую задержку пере-
дачи ячеек. В зависимости от размера буферов для хранения ячеек, ожида-
ющих очереди на передачу, соединения VCC могут также иметь больший
коэффициент потерянных ячеек. Достоинство — более эффективное исполь-
зование ресурсов. Такой подход может иметь место, если соединения VCC
допускают снижение уровня качества обслуживания.
При статистическом мультиплексировании желательно группировать соедине-
ния VCC в соединения VPC на основе сходных характеристик и сходных требова-
ний к качеству обслуживания. Если в одном соединении VPC объединить несхо-
жие соединения VCC и использовать статистическое мультиплексирование, то
будет сложно обеспечить справедливое распределение ресурсов между потоками
с высокими требованиями и потоками с низкими требованиями.
Управление допуском к соединению
Управление допуском к соединению представляет собой первую линию обороны,
предназначенную для защиты сетей от избыточной нагрузки. Запрашивая уста-
новку нового соединения VPC или VCC, пользователь должен указать (явно или
13.4. Управление трафиком
419
неявно) требуемую ему службу в обоих направлениях этого соединения. В запро-
се указывается следующая информация:
♦ Категория службы (CBR, rt-VBR, nrt-VBR, ABR, UBR).
4 Описатель трафика соединения, состоящий:
♦ из описателя трафика источника (PCR, SCR, MBS, MCR);
♦ CDVT;
♦ запрашиваемого согласованного определения.
♦ Запрашиваемое и приемлемое значения каждого параметра качества обслу-
живания (диапазон CDV, maxCTD, CLR).
Сеть принимает запрос на установку соединения только в том случае, если она
может выделить ресурсы, необходимые для поддержания запрашиваемого уровня
трафика и договорного уровня качества обслуживания уже существующих соеди-
нений. Принимая запрос на соединение, сеть заключает с пользователем договор о
трафике (traffic contract). Когда запрос на соединение принят, сеть продолжает
обеспечивать договорной уровень качества обслуживания, пока пользователь вы-
полняет условия договора о трафике.
Как показано в табл. 13.3, для данного соединения (VPC или VCC) параметры
договора о трафике могут указываться несколькими способами. Значения пара-
метров могут неявно задаваться правилами по умолчанию, установленными сете-
вым оператором. В этом случае всем соединениям или всем соединениям одного
класса назначаются одни и те же значения параметров. Сетевой оператор может
также ассоциировать значения параметров с данным подписчиком и назначать ему
эти параметры во время подписки. Наконец, значения параметров, сформирован-
ные для конкретного соединения, могут быть назначены во время установки со-
единения. В случае соединения для постоянного виртуального канала (PVC) эти
значения назначаются сетью при установке соединения. В случае соединения для
коммутируемого виртуального канала (SVC) параметры обсуждаются пользова-
телем и сетью при помощи сигнального протокола.
Таблица 13.3. Процедуры установки значений параметров договора о трафике
Канал Явно указываемые параметры Неявно указываемые параметры
Значения устанавливаются при установке соединения Значения Значения устанавливаются указываются с помощью правил при подписке по умолчанию
Запрашиваются пользователем или станцией управления сетью SVC Сигнализация Назначаются сетевым оператором По подписке Правила по умолчанию сетевого оператора
PVC Станция управления сетью По подписке Правила по умолчанию сетевого оператора
Другим аспектом договора о трафике, который может быть запрошен для со-
единения или назначен соединению, является приоритет потери ячеек. Пользова-
тель может запросить для соединения ATM два уровня приоритета потери ячеек.
420
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Приоритет указывается в каждой ячейке при помощи бита CLP в заголовке ячей-
ки (см. рис. 5.4 в главе 5). При использовании двух уровней приоритета необхо-
димо указать параметры трафика для обоих потоков ячеек. Как правило, для этого
указываются параметры высокоприоритетного трафика (CLP = 0), а также набор
параметров для всех трафиков (CLP = 0 + 1). На основе этих данных сеть может
более эффективно распределять ресурсы.
Контроль параметров использования
Когда запрос на установку соединения принят функцией управления допуском
к соединению, сетевая функция контроля параметров использования (Usage
Parameter Control, UPC) начинает следить за соединением, чтобы определить, со-
ответствует ли трафик договору о трафике. Основное назначение функции UPC
заключается в защите сетевых ресурсов, обнаружении факта превышения парамет-
рами назначенных уровней и выполнения соответствующих действий. Таким об-
разом, функция UPC не допускает перегрузки ресурсов одним соединением, что
могло бы повлиять на качество обслуживания других соединений.
Местоположение функции UPC
Функция U PC может быть реализована как на уровне виртуального пути, так и на
уровне виртуального канала. Более важным является уровень соединения вирту-
ального пути, так как сетевые ресурсы, как правило, распределяются на основе
виртуальных путей, в которых ресурсы совместно используются всеми входящи-
ми в виртуальный путь виртуальными каналами.
Как показано на рис. 13.5, место, в котором может быть реализована функция
UPC, зависит от конфигурации. Как и раньше, символами VP-Sw и VC-Sw обо-
значены, соответственно, функция коммутации виртуальных путей и функция ком-
мутации виртуальных каналов. Кроме того, символами NT (Network Termination)
обозначены сетевые оконечные устройства.
Случай А
Случай В
Случай С
UNI
Рис. 13.5. Размещение функции контроля параметров использования
13.4. Управление трафиком
421
Если первая конечная точка соединения VCC представляет собой узел сети,
выполняющий функции, относящиеся к соединению VCC (случай А), тогда функ-
ция UPC обрабатывает входящие ячейки до того, как выполняется функция ком-
мутации виртуальных каналов. Если соединение VCC проходит через одну или
более точек коммутации соединений VPC, прежде чем соединиться с точкой ком-
мутации соединения VCC в сети (случай В), тогда, во-первых, функция UPC об-
рабатывает входящие ячейки на основе виртуального пути в точках коммутации
соединения VPC, во-вторых, функция UPC выполняется на основе виртуального
канала в первой же точке, в которой выполняются функции, относящиеся к со-
единению виртуального канала.
Наконец, если соединение виртуального канала соединено с пользователем или
с другим поставщиком сетевых услуг (случай С), тогда эта сеть предоставляет
функцию U PC только на уровне виртуального пути.
Алгоритм пиковой скорости ячеек
До сих пор мы рассматривали функцию UPC в общих чертах, не указывая, как она
выясняет, выполняет ли пользователь договор о трафике. Функция UPC решает
две разные задачи:
4 Управление пиковой скоростью ячеек и связанным с ней параметром CDVT.
4 Управление установившейся скоростью ячеек и связанным с ней допусти-
мым максимальным всплеском.
Рассмотрим сначала пиковую скорость ячеек и связанный с ней параметр CDVT.
Поток трафика соответствует договору, если пиковая скорость ячеек не превыша-
ет указанной в договоре величины, что ограничивается вероятностью отклонения
задержки ячеек в оговоренных пределах.
В стандарте 1.371 и в спецификации управления трафиком ATM предоставля-
ется алгоритм, который, во-первых, служит рабочим определением взаимодействия
между пиковой скоростью ячеек и параметром CDVT и, во-вторых, может исполь-
зоваться функцией UPC, чтобы следить за выполнением договора о трафике.
На рис. 13.6 показаны две эквивалентные версии алгоритма. Этот алгоритм на-
зывается общим алгоритмом скорости ячеек (Generic Cell Rate Algorithm, GCRA),
так как он также применим для установившейся скорости ячеек, как будет по-
яснено ниже. В алгоритме используются два входных аргумента, приращение 1
и приращение L, что обозначается как GCRA(£, £). Кроме того, используются сле-
дующие обозначения:
4 ta(k) — время прибытия ячейки к\
4 X — счетчик «дырявого ведра»;
4 X' — вспомогательная переменная;
4 LCT (Last Compliance Time) — время последнего соответствия.
Чтобы лучше понять взаимоотношение между параметрами I и L, нужно исследо-
вать обе версии алгоритма. Предположим, что мы указали пиковую частоту ячеек R
и предел т для CDVT. В этом случае Т= 1/R представляет собой время между по-
ступлениями ячеек, если бы не было допуска CDVT. При наличии допуска CDVT
Т представляет собой среднее время между поступлениями ячеек с пиковой часто-
той. Поэтому алгоритм пиковой частоты ячеек обозначается как GCRA(T, т).
422
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
В момент прибытия первой ячейки
соединения время ТАТ = /о(1)
В момент прибытия первой ячейки
соединения X = 0 и LCT = fo(1)
б
а
Рис. 13.6. Эквивалентные версии общего алгоритма частоты ячеек GCRA(/, L)
Рассмотрим алгоритм виртуального планирования (virtual scheduling algorithm),
показанный на рис. 13.6, а. Алгоритм инициализируется при прибытии через со-
единение первой ячейки в момент времени /„(1). Алгоритм обновляет значение
теоретического времени прибытия (Theoretical Arrival Time, ТАТ), представляю-
щего собой планируемое время прибытия. Если ячейка прибывает позднее, чем
время ТАТ, тогда она не нарушает договора о трафике, а значение ТАТ для следу-
ющей ячейки вычисляется заново как время прибытия ячейки плюс Т. Если ячей-
ка прибывает раньше, чем время ТАТ, но в пределах т временных единиц от ТАТ,
тогда эта ячейка все равно считается удовлетворяющей договору о трафике, и зна-
чение ТАТ увеличивается на Т. В последнем случае ячейке разрешается прибы-
вать раньше срока, так как она укладывается в допуск CDVT. Наконец, если ячей-
ка прибывает еще раньше (до момента ТАТ - т), тогда она уже не укладывается
в допуск CDVT и объявляется нарушающей договор. В этом случае значение ТАТ
остается неизменным. Эти три зоны показаны рис. 13.7, а.
13.4. Управление трафиком
423
б
Рис. 13.7. Иллюстрация работы алгоритма GCRA(T, т)
Пример работы этого алгоритма показан на рис. 13.8. На этом рисунке время для
передачи одной 53-байтовой ячейки равно 8, а Т = 4,5 8. Таким образом, пиковая
скорость ячеек равна скорости передачи данных в интерфейсе пользователь — сеть,
деленной на 4,5. Например, если скорость передачи данных равна 150 Мбит/с, тог-
да пиковая скорость ячеек равна 150/4,5 = 33,33 Мбит/с. На рис. 13.8, а использу-
ется минимальная величина допуска CDVT (т = 8/2). Этого как раз достаточно,
чтобы приноровиться к тому, что данные передаются в ячейках, и поэтому каждое
время прибытия будет кратно 8, в то время как значение приращения окажется на
отметке 0,5. Поскольку величина допуска невелика, время прибытия ячейки ни-
когда не сможет сильно отклониться от ТАТ.
При увеличении CVDT и т время прибытия ячеек может сместиться от ТАТ на
большее значение. Что еще важнее, при этом увеличивается вероятность слипа-
ния ячеек, что создает дополнительное давление на сетевые ресурсы. Слипа-
ние ячеек достигает наибольшей степени, когда источник может передавать
много ячеек подряд (то есть с максимальной для данной линии связи скоростью
передачи данных). Это возможно при условии, что значение т превышает Т- 8.
В частности, при т > Г - 8 максимальное количество идущих впритык друг к дру-
гу ячеек, удовлетворяющих договору о трафике, можно вычислить по следующей
формуле:
N =
1 +
т
Т-8
(13.1)
424 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Ц1) fo(2) 1О(3) <о(4) fa(5)
t„(() -ф--------------------------------ф------------------
Время
Х+ LCT
(ТАТ)
Идеальное прибытие ячейки (т = 0,56)
а
X + LCT
Возможное прибытие ячейки (т = 1,56)
б
X+LCT
(ТАТ)
Возможное прибытие ячейки (т = 3,56)
в
Время
Х+ LCT
(ТАТ)
Возможное прибытие ячейки (т = 76)
г
Рис. 13.8. Поступление ячеек а интерфейс пользователь — сеть(Т=4,5 6)
Здесь [xj означает целую часть х. Передачу ячеек впритык друг к другу иллю-
стрируют рис. 13.8, в и г.
Возвращаясь к диаграмме потока на рис. 13.8, а, обратите внимание на то, что
такая схема не позволяет накапливать кредиты. Если ячейка прибывает поздно,
это означает, что в соединении был период бездействия. Однако следующее зна-
чение ТЛТ устанавливается относительно текущего времени прибытия ячейки,
а не относительно текущего значения ТАТ. Если бы этого правила не существо-
вало и к значению ТАТ просто прибавлялась величина Т после каждого прибытия
ячейки, тогда после долгого периода простоя источник мог бы отправить длинную
серию ячеек на максимальной скорости канала. Такая лавина ячеек могла бы вы-
звать серьезные проблемы в сети.
13.4. Управление трафиком
425
Общий алгоритм скорости ячеек (GCRA) может быть также выражен через
алгоритм дырявого ведра (leaky bucket algorithm), показанный на рис. 13.6, б. Прин-
цип работы алгоритма дырявого ведра иллюстрирует рис. 13.9. Алгоритм храпит
суммарное количество посланных данных в счетчике X. Счетчик уменьшается на
единицу через равные интервалы времени до нуля. Это эквивалентно дырявому
ведру, из которого вытекает жидкость с единичной скоростью. При поступлении
каждой ячейки значение счетчика увеличивается на I, но при этом не может пре-
высить I + L.
Увеличение на / для каждой ячейки,
соответствующей договору о трафике
-► Отбрасывается любая
входящая ячейка,
вызывающая
переполнение ведра
Размер ведра
(/. + /)
▼
Уменьшение
на 1 в единицу времени
Рис. 13.9. Работа алгоритма дырявого ведра
Как уже упоминалось, алгоритм, показанный на рис. 13.6, б, эквивалентен ал-
горитму, показанному на рис. 13.6, а; оба они являются вариантами алгоритма
GCRA. Алгоритм дырявого ведра определяет ведро конечной емкости, содержи-
мое которого вытекает с постоянной скоростью 1 за единицу времени и увеличи-
вается на величину Т при каждом получении ячейки, удовлетворяющей договору
о трафике. Объем ведра равен Т + т. После прибытия k-Й ячейки в момент време-
ни tB(k) алгоритм проверяет, не переполнилось ли ведро. Если нет, содержимое
ведра увеличивается. Величина, на которую увеличивается содержимое ведра,
зависит от того, было ли ведро полностью опустошено между поступлениями
ячеек. Работу этого алгоритма иллюстрирует рис. 13.7, б, в левой части которого
показано состояние ведра после обработки ячейки, а в правой — после прибытия
новой ячейки.
Алгоритм установившейся скорости ячеек
Алгоритм установившейся скорости ячеек, во-первых, служит для рабочего опре-
деления взаимоотношений между установившейся скоростью ячеек и допуском на
всплеск (Burst Tolerance, ВТ) ячеек и, во-вторых, может использоваться функцией
UPC, чтобы следить за соответствием договору о трафике.
426
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Тот же алгоритм, который используется для мониторинга пиковой скорости!
ячеек, подходит и для мониторинга установившейся скорости ячеек. В этом слу-И1"
чае при установившейся скорости ячеек 7< значение Ts = l//?s представляет собой И
интервал времени между поступающими с этой скоростью ячейками при отсутствии ’
всплесков. Допуск на всплеск обозначается как т„ Этот параметр соответствует
интервалу времени, в течение которого допускаются флуктуации скорости ячеек
Смысл допуска на всплеск должен проясниться по мере обсуждения. Алгоритм
установившейся скорости ячеек обозначается как GCRA(TS, тД.
В отличие от допуска CDVT, допуск ВТ не выбирается вслепую. Вместо этого
он выводится из понимания неравномерности потока данных. В частности, пусть
Тявляется временем между поступлениями ячеек с пиковой скоростью. Если поток
ограничен пиковой скоростью ячеек при помощи алгоритма GCRA(T, т) и устано-
вившейся скоростью ячеек при помощи алгоритма GCRA(7’„ т,), тогда максималь-
ный размер всплеска (Maximum Burst Size, MBS), по которому можно определить
пиковую скорость ячеек, вычисляется по формуле
1 +
MBS =
Ts-T
(13.2)
В сигнальном сообщении допуск ВТ передается в виде размера MBS, задавае-
мого количеством ячеек. Затем по значению MBS можно вычислить величину тм
которая, в свою очередь, используется в алгоритме GCRA для наблюдения за
установившейся скоростью ячеек. При заданных значениях MBS, Ти Д величина
т, может принимать любые значения в интервале
«Mbs - i)(7i- t),mbs(t:5- г)]. (1з.з)
Для однородности используется минимальное значение
вт = ts = (mbs -!)(?; - т) = (Mbs -1)
1 1
SCR PCR
(13.4)
Допуск на всплеск (ВТ), отражающий глубину ведра, не идентичен размеру
MBS. Это вызвано тем, что ведро опустошается со скоростью SCR. Формула (13.4)
показывает глубину ведра для MBS ячеек, наполняющих ведро со скоростью PCR
и вытекающих из него со скоростью SCR.
Действия функции UPC
Алгоритм GCRA или подобный ему алгоритм используется сетью, чтобы гаранти-
ровать соблюдение договора о трафике. Простейшая стратегия заключается в том,
что ячейки, удовлетворяющие соглашению, пропускаются дальше, а ячейки, на-
рушающие договор, отбрасываются прямо в точке приложения функции UPC.
Если для потока с CLP = 1 не выделяется дополнительных ресурсов, ячей-
ки с CLP = 0 считаются нарушающими соглашение о трафике и отбрасываются.
Если пользователь договорился о двух уровнях приоритетов потерт, ячеек, тогда
ситуация оказывается более сложной. Применяются следующие правила:
1. Ячейка с CLP = 0, соответствующая договору о трафике для CLP = 0, про-
пускается.
13.4. Управление трафиком
427
2. Ячейка с CLP = 0, не соответствующая договору о трафике для CLP = 0, но
соответствующая договору о трафике для (CLP = 0 + 1), помечается и про-
пускается.
3. Ячейка с CLP = 0, не соответствующая договору о трафике для CLP = 0 и не
соответствующая договору о трафике для (CLP = 0 + 1), отбрасывается.
4. Ячейка с CLP = 1, соответствующая договору о трафике для (CLP = 0+1),
пропускается.
5. Ячейка с CLP = 1, не соответствующая договору о трафике для (CLP = 0 +1),
отбрасывается.
Рисунок 13.10 иллюстрирует взаимоотношение между функцией UPC и зна-
чением бита CLP. Здесь Р? означает тест на соответствие договору о трафике для
параметра Р. Сначала функция UPC проверяет поток с CLP = 0 на соответствие
договору о трафике, а затем проверяется комбинированный поток (CLP = 0 +1).
Если используется режим пометки, то ячейки с CLP = 0, не соответствующие до-
говору о трафике, помечаются, но все еще считаются частью потока (CLP = 0+1)
и подлежат повторной проверке.
Пометка ячеек не выполняется
Пометка ячеек
Рис. 13.10. Возможные действия функции UPC
Выборочное отбрасывание ячеек
Метод выборочного отбрасывания ячеек задействуется, когда сеть в каком-то ме-
сте после точки применения функции UPC отбрасывает ячейки (CLP =1). Цель
этого действия заключается в том, чтобы, отбрасывая ячейки с низким приорите-
428 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
---_—_
том, сохранить пропускную способность для высокоприоритетных ячеек. Обрати-
те внимание на то, что у сети нет способа отличить ячейки, помеченные источником
как низкоприоритетные, от ячеек, приоритет которых понижен функцией UPC
Формирование трафика
Алгоритм GCRA называют формой регулирования трафика (traffic policing)
Регулирование трафика имеет место, когда ячейки (или кадры, или пакеты), пре-
вышающие определенный уровень пропускной способности, отбрасываются или
помечаются. Помимо политики регулирования трафика может потребоваться по-
литика формирования трафика (traffic shaping), которая позволила бы сглаживать
поток данных и уменьшать всплески пакетов. Формирование трафика может при-
вести к более справедливому распределению ресурсов и снижению среднего зна-
чения задержки.
Простой способ формирования трафика реализует одна из разновидностей
алгоритма дырявого ведра, называемая маркерным ведром (token bucket). В отли-
чие от дырявого ведра GCRA (см. рис. 13.9), просто следящего за трафиком и от-
брасывающего не соответствующие договору о трафике ячейки, алгоритм маркер-
ного ведра формирует трафик, управляя потоком ячеек в соответствии с договором
о трафике.
Рисунок 13.11 иллюстрирует основной принцип маркерного ведра. Генератор
маркеров создает маркеры с постоянной скоростью р маркеров в секунду и по-
мещает эти маркеры в ведро емкостью Р маркеров. Ячейки, поступающие от
источника, помещаются в буфер емкостью К ячеек. Для передачи одной ячейки
из ведра должен быть удален один маркер. Если маркерное ведро пусто, ячейка
помещается в очередь и ждет следующего маркера. В результате, если ведро пус-
то, а в очереди есть ячейки, ячейки передаются в виде постоянного потока со ско-
ростью р ячеек в секунду и нулевым разбросом задержки. Так продолжается до
тех пор, пока очередь не опустеет. Таким образом, маркерное ведро сглаживает
поток ячеек.
Генератор Скорость р
Рис. 13.11. Маркерное ведро в процессе формирования трафика
Й
Н
I
13.5. Управление трафиком в службе ABR 429
Явное прямое уведомление о перегрузке
Метод явного прямого уведомления о перегрузке (EFCI) в сети ATM работает так
же, как и в сетях ретрансляции кадров. Любой перегруженный узел сети ATM мо-
жет установить в заголовки ячейки, проходящей через этот узел, признак явного
прямого уведомления о перегрузке. Таким образом, пользователь извещается
о том, что следует инициировать процедуры предотвращения перегрузки для
трафика, направляющегося по тому же маршруту, которым шла полученная ячей-
ка с уведомлением. Это уведомление означает, что ячейка встретила по дороге
перегруженные ресурсы. При этом пользователь может инициировать действия
протоколов более высокого уровня, чтобы снизить скорость передачи ячеек через
это соединение.
Явное прямое уведомление о перегрузке кодируется сетью установкой первых
двух битов поля типа полезной нагрузки в состояние 01 (см. подраздел «Формат
заголовка» в разделе 5.3). После того как один из узлов сети установил эти биты
в данное положение, другие сетевые узлы не могут их изменять.
Обратите внимание на то, что поле общего управления потоком (см. рис. 5.4
в главе 5) не участвует в данной сигнальной системе. Это поле обладает только
локальным значением и не может передаваться по сети.
13.5. Управление трафиком в службе ABR
Качество обслуживания для сетевых служб CBR, rt-VBR и nrt-VBR основано, во-
первых, на договоре о трафике, в котором указаны характеристики потока ячеек,
и, во-вторых, на функции UPC, реализуемой сетью для регулировки потока. В про-
цессе установки соединения сеть на основе договора о предполагаемом трафике
определяет наличие ресурсов, необходимых для нового соединения. Если ресурсы
доступны, соединение устанавливается, после чего функция UPC может отбрасы-
вать ячейки, превышающие параметры договора, или понижать приоритет таких
ячеек. Обратной связи с источником в такой схеме не существует, поэтому этот
подход называют управлением в разомкнутом цикле (open-loop control).
Для многих приложений передачи данных метод управления в разомкнутом
цикле не годится. У типичных приложений, не являющихся приложениями реаль-
ного времени, таких как передача файлов, доступ к Всемирной паутине, вызов
удаленных процедур, службы распределенных файлов и т. д., нет четко опреде-
ленных характеристик, кроме, возможно, пиковой скорости. Самого значения
пиковой скорости ячеек (Peak Cell Rate, PCR) недостаточно, чтобы сеть могла
эффективно распределять ресурсы. Более того, как правило, такие приложения
допускают наличие непредсказуемых задержек и меняющейся со временем про-
пускной способности.
Такими приложениями можно управлять двумя способами. Одна возможность
состоит в том, чтобы позволить им распределить неиспользуемые ресурсы относи-
тельно неконтролируемым образом. При возникновении перегрузки начинаются
потери ячеек, тогда различные источники выполняют процедуру отката, снижая
430 Глава 13- Управление трафиком и борьба с перегрузкой в сетях ATM
скорость передачи данных. Такой стиль передачи хорошо подходит для обсуждае
мых в главе 12 методов борьбы с перегрузкой протокола TCP, и именно в этом
режиме работает служба UBR. Подобный подход называют обслуживанием с мак-
симальными усилиями (best-effort service). Его недостаток заключается в неэффек.
тивности: ячейки отбрасываются, что приводит к повторным передачам.
Другой способ состоит в том, чтобы также позволить нескольким источникам
совместно использовать ресурсы, не занятые службами CBR и VBR, но при этом
предоставить источникам обратную связь, позволяющую им динамически изме-
нять нагрузку на сеть. Таким образом можно избежать потери ячеек и справедли-
во распределить общие ресурсы. Этот метод, называемый управлением в замкну-
том цикле (closed-loop control), используется в службе ABR.
В данном разделе мы обсудим службу ABR и рассмотрим некоторые детали
механизма обратной связи, используемого для управления потоком ячеек.
Контроль скорости в службе ABR
В [47] перечисляются следующие основные характеристики службы ABR:
4- Соединения ABR совместно используют доступные ресурсы. У соединений
ABR есть доступ к ресурсам, не используемым соединениями CBR/VBR.
Таким образом, служба ABR может увеличить коэффициент использования
сети, не затрагивая качества обслуживания соединений CBR/VBR.
♦ Доля доступных отдельному соединению ABR ресурсов динамически изме-
няется в диапазоне согласованных в договоре значений от MCR до PCR.
Величина MCR, назначаемая соединению, может быть равна нулю. При нену-
левом значении MCR сеть предоставляет гарантию минимальной пропуск-
ной способности. Однако источник может в любой момент передавать дан-
ные с меньшей, чем MCR, скоростью.
4- Сеть предоставляет ABR-источникам обратную связь, так что поток ABR
ограничивается определенным уровнем. Поскольку обратная связь дости-
гает источника трафика с задержкой, вдоль пути передачи данных приходит-
ся использовать буферы. Эти буферы абсорбируют избыточный трафик,
посланный источниками прежде, чем до них добрались пакеты обратной
связи. Из-за большой скорости передачи данных в сетях ATM и относитель-
но большой задержки распространения сигнала эти буферы должны быть
значительных размеров, что ведет к большим задержкам. Соответственно,
служба ABR подходит для приложений, допускающих изменение скорости
передачи данных и непредсказуемые задержки доставки ячеек.
4- Для ABR-источников, подстраивающих свою скорость передачи данных
в соответствии с механизмом обратной связи, гарантируется низкий коэф-
фициент потерянных ячеек. В этом главное отличие службы ABR от UBR.
Механизмы обратной связи
Скорость передачи ячеек источником по ABR-соединению характеризуется четырь-
мя параметрами.
13.5. Управление трафиком в службе ABR
431
Допустимая скорость ячеек (Allowed Cell Rate, ACR) — это текущая скорость,
с которой источнику разрешается передавать ячейки. Источник может пе-
редавать ячейки с любой скоростью в диапазоне от пуля до ACR.
4- Минимальная скорость ячеек (Minimum Cell Rate, MCR) — минимальное
значение, которое может принимать ACR (то есть сеть не будет уменьшать
скорость передачи данных источника ниже MCR). Однако для данного кон-
кретного соединения значение MCR может быть равно нулю.
4- Пиковая скорость ячеек (Peak Cell Rate, PCR) — максимальное значение,
которое может принимать ACR.
♦ Начальная скорость ячеек (Initial Cell Rate, ICR) — начальное значение, на-
значаемое для ACR.
Источник начинает передавать ячейки со скоростью ACR = ICR, а затем дина-
мически подстраивает значение ACR с помощью обратной связи от сети. Обрат-
ная связь осуществляется в виде периодически посылаемых последовательностей
ячеек управления ресурсами (Resource Management, RM). Каждая ячейка содер-
жит три поля, обеспечивающих обратную связь с источником: бит индикащш пе-
регрузки (Congestion Indication, CI), бит запрета увеличения скорости (No Increase,
NI) и поля явной установки скорости ячеек (Explicit Rate, ER). На эту информа-
цию источник реагирует в соответствии со следующими правилами:
♦ если CI = 1, уменьшить ACR на величину, пропорциональную текущему зна-
чению ACR, но не меньшую, чем MCR;
♦ иначе если NI = 0, увеличить ACR на величину, пропорциональную PCR, но
не большую, чем PCR;
4 если ACR > ER, установить ACR <— max[ER, MCR],
Таким образом, источник сначала проверяет два бита обратной связи. Если
требуется увеличение скорости, скорость увеличивается на величину RIF PCR,
где RIF представляет собой фиксированный коэффициент увеличения скорости
(Rate Increase Factor). Если требуется уменьшение скорости, скорость уменьша-
ется экспоненциально, для чего значение ACR умножается на фиксированный ко-
эффициент уменьшения скорости (Rate Decrease Factor, RDF). При этом значе-
ние скорости ACR ограничивается верхним (PCR) и нижним (MCR) пределами.
Эти правила приведены в табл. 13.4.
Таблица 13.4. Правила регулирования скорости передачи данных
через ABR-соединение
Бит NI БитС1 Действие
0 0 ACR < max[MCR, min[ER, PCR, ACR + RIF • PCR]]
0 1 ACR < max[MCR, min[ER, ACR(1 - RDF)]]
1 0 ACR < max[MCR, min[ER, ACR]]
1 1 ACR < maxfMCR, min[ER, ACR(1 - RDF)]]
Рисунок 13.12 иллюстрирует влияние обратной связи на значение скорости ACR.
В данном примере используется значение RIF = 1/16, представляющее собой зна-
чение по умолчанию. Как можно видеть, каждый раз скорость увеличивается на
432 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
постоянную величину. Значение RDF по умолчанию также равно 1/16, но чтобы
продемонстрировать экспоненциальный эффект RDF, на рисунке используется
значение 1/4. Величина, на которую уменьшается скорость ACR, пропорциональ-
на текущему значению ACR. Благодаря линейному увеличению и экспоненциаль-
ному уменьшению источник медленно увеличивает свою скорость при отсутствии
признаков перегрузки, но на высоких скоростях, получив уведомление о перегруз-
ке, быстро снижает скорость.
ACR
Когда в полученной RM-ячейке
бит CI = 1, источник должен снизить
свою скорость ACR на RDF • ACR вплоть до скорости MCR
н ши
Когда получена RM-ячейка
с битами (Cl = NI = 0),
источник может увеличить
свою скорость ACR на RIF • PCR
вплоть до скорости PCR
Если ACR больше,
чем значение ER
в полученной RM-ячейке,
источник должен снизить
свою скорость ACR
до max(MCR, ER)
Рис. 13.12. Изменения допустимой скорости ячеек ACR (по [193])
Поток ячеек
Узнав, как источник реагирует на обратную связь, мы теперь познакомимся со спо-
собом предоставления этой обратной связи. На рис. 13.13 показан однонаправлен-
ный поток данных через ABR-соединение сети ATM.
По ABR-соединению передаются ATM-ячейки двух типов: ячейки с данными
и ячейки управления ресурсами (RM). Источник получает регулярную последо-
вательность RM-ячеек, обеспечивающих обратную связь, что позволяет регулиро-
13.5. Управление трафиком в службе ABR
433
вать скорость передачи. Большое количество RM-ячеек также формируется источ-
ником. Источник передает по одной ячейке FRM (Forward Resource Management —
прямое управление ресурсами) на каждые (Nrm - 1) ячеек с данными, где Nnn
представляет собой заранее установленный параметр (как правило, равный 32).
Приняв такую FRM-ячейку, получатель отсылает ее назад отправителю как ячейку
BRM (Backward Resource Management — обратное управление ресурсами).
Точка перегрузки:
установить признак EFCI
в ячейке с данными
' Скорость передачи
ячеек равна ACR
RM-ячейки передаются
после каждых (Nrm - 1)
ячеек с данными
Прямая
RM-ячейка
Изменить скорость ACR
в зависимости
от значений
полей Cl, NI и ER
ЙПППВПППВППП1ППП1ППП
’\ Обратная
Ячейка RM-ячейка
с данными /
Вернуть RM-ячейку.
В случае перегрузки
снизить ER.
Если установлен
признак EFCI,
установить бит CI
Адресат:
оконечная
система
Точка перегрузки:
снизить ER
или установить
бит CI или NI
Рис. 13.13. Поток ячеек с данными и ячеек управления ресурсами
через ABR-соединение (по [193])
В каждой FRM-ячейке содержатся поля CI, NI и ER. Источник, как правило,
устанавливает CI = О, NI = 0 или 1 и значение в поле ER, равное некоторому опре-
деленному уровню скорости передачи в диапазоне ICR < ER < PCR. Любое из этих
полей может быть изменено коммутатором ATM. Также эти поля может изменить
получающая система, перед тем как вернуть источнику соответствующую BRM-
ячейку.
Коммутатор ATM может предоставить источнику обратную связь нескольки-
ми способами.
♦ Маркировка EFCI. Коммутатор может установить в заголовке АТМ-ячейки
признак EFCI (Explicit Forward Congestion Indication — явное прямое
уведомление о перегрузке). В ответ получающая оконечная система может
установить в единицу бит CI в BRM-ячейке.
♦ Маркировка относительной скорости. Коммутатор может напрямую устано-
вить бит CI или NI в проходящей через него RM-ячейке. Если бит устанавли-
вается в FRM-ячейке, тогда он остается в установленном положении в соот-
ветствующей BRM-ячейке, которую в ответ отправляет получатель. Реакция
отправителя будет быстрее, если один из этих битов установить в BRM-ячей-
ке. Самых быстрых результатов коммутатор может достичь, если сам сформи-
рует BRM-ячейку, а не будет дожидаться, пока такая ячейка пройдет через него.
♦ Маркировка явным указанием скорости. Коммутатор может снизить значе-
ние поля ER в FRM-ячейке или BRM-ячейке.
434
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Подобным образом ATM-коммутатор может сигнализировать источнику о воз-
никновении перегрузки, а в ответ источник может снизить скорость передачи
Получатель также может подать сигнал о перегрузке. В нормальных условиях
получающая система просто преобразует каждую входящую FRM-ячейку в BRM-
ячейку, не меняя содержимого полей NI, CI и ER. При этом разве что бит CI
устанавливается получателем в случае, если в предыдущей ячейке с данными был
получен признак EFCI (явное прямое уведомление о перегрузке). Однако если
получатель испытывает перегрузку, то при преобразовании FRM-ячейки в BRM-
ячейку он может установить бит CI или NI либо снизить значение поля ER.
В первых ATM-коммутаторах для поддержки службы ABR использовались
биты EFCI, NI и CI, предоставляющие относительно простой механизм управле-
ния скоростью. Более сложный механизм управления, связанный с явным зада-
нием скорости, применяется в службе ABR второго поколения.
Обратите внимание на то, что общая структура потока, показанного на рис. 13.13,
напоминает передачу сегментов TCP с использованием подтверждений (см. рис. 12.6
в главе 12). Однако есть два ключевых различия. Во-первых, обратная связь служ-
бы ABR управляет скоростью передачи ячеек, тогда как обратная связь протокола
TCP регулирует размер окна. Таким образом, метод, применяемый в службе ABR,
реализует управление скоростью (rate control), в отличие от используемой в TCP
техники управления кредитом (credit control). Во-вторых, в службе ABR обратную
связь могут предоставлять как получатель, так и промежуточные АТМ-коммута-
торы, тогда как в TCP обратная связь предоставляется только получателем.
Формат ячейки управления ресурсами
На рис. 13.14 показан формат ячейки управления ресурсами (RM-ячейки), а ниже
перечислены составляющие ее элементы:
♦ Заголовок (5 байт). Поле РТ в заголовке ATM-ячейки содержит значение 110,
что обозначает RM-ячейку. Поля VPI и VCI, используемые для управления
скоростью в виртуальном канале, идентичны соответствующим полям в ячей-
ках с данными, передаваемыми через это соединение. Для регулирования
скорости передачи данных по виртуальному пути используется то же самое
поле VPI, a VCI = 6.
♦ Идентификатор протокола (1 байт). Обозначает службу, использующую
данную RM-ячейку. Для службы ABR ID = 1.
♦ Тип сообщения (1 байт). Содержит следующие 1-битовые индикаторы:
♦ направление (DIR) — FRM (DIR = 0) или BRM (DIR = 1);
+ ячейка ВЕСИ (BN) — обозначает ячейку, созданную источником (BN = 0)
либо коммутатором или получателем (BN = 1);
♦ индикатор перегрузки (CI) — (CI = 1) указывает на наличие перегрузки;
♦ запрет увеличения скорости (NI) — (NI = 1) обзначает, что увеличение
скорости не разрешается.
♦ Запрос/подтверждение (RA). Определено в стандарте 1.371; не использует-
ся в службе ABR, определенной АТМ-форумом.
13.5. Управление трафиком в службе ABR
435
♦ Явноуказанная скорость ячеек (2 байта). Применяется для ограничения ско-
рости ACR до указанной величины.
♦ Текущая скорость ячеек (2 байта). Устанавливается источником равной те-
кущему значению его скорости ACR. Эта информация может испол ьзовать-
ся сетевыми элементами для определения значения ER.
♦ Минимальная скорость ячеек (2 байта). Устанавливается источником. Может
использоваться сетевыми элементами при распределении ресурсов между
соединениями.
♦ Длина очереди (4 байта). Определено в стандарте 1.371; не используется
в службе ABR, определенной АТМ-форумом.
♦ Порядковый номер (4 байта). Определено в стандарте 1.371; не используется
в службе ABR, определенной АТМ-форумом.
+ CRC-10 (10 бит). Код для обнаружения ошибок, вычисляемый по значению
полезной нагрузки RM-ячейки (всей ячейки, не считая заголовка).
Байты
5
1
1
2
2
2
4
4
30,75
10 бит
Идентификатор
протокола
Биты
Тип сообщения
Явно указанная \
скорость ячеек
Текущая скорость
ячеек
Минимальная
скорость ячеек
Запрос/подтверждение 1
Направление 1
Ячейка BECN 1
Индикатор перегрузки 1
Запрет увеличения скорости 1
Длина очереди
Порядковый
номер
CRC-10
Рис. 13.14. Формат ячеек управления ресурсами службы ABR
436
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
В табл. 13.5 приведены начальные значения, назначаемые при формировании
первой RM-ячейки. Кроме полей RM-ячейки работой службы ABR управляет
множество других параметров, приведенных в табл. 13.6.
Таблица 13.5. Начальные значения полей RM-ячеек
Поле Если генерируется источником Если генерируется комму- татором или получателем
Направление (DIR) 0 1
Ячейка BECN (ВС) 0 1
Признак перегрузки (CI) 0 0 или 1
Запрет увеличения скорости (NI) 0 или 1 0 или 1
Явно указанная скорость ячеек (ECR) < PCR Любое значение скорости
Текущая скорость ячеек (CCR) Параметр ACR 0
Минимальная скорость ячеек (MCR) Параметр MCR 0
Таблица 13.6. Параметры службы ABR
Обозначение Название Описание Значение по умолчанию
PCR Пиковая скорость ячеек Фиксированный верхний предел скорости источника —
MCR Минимальная скорость ячеек Нижний предел скорости источника, гарантируемый сетью 0
ICR Начальная скорость ячеек Начальное значение ACR; скорость, с которой источник должен посылать ячейки сразу после установки соединения или после периода бездействия PCR
RIF Коэффициент увеличения скорости Значение, на которое может увеличиваться скорость передачи после получения RM-ячейки 1/16
Nrm Максимальное количество ячеек, которые источник может передать после каждой FRM-ячейки 32
Мгт Управляет распределением пропускной способности между FRM-ячейками, BRM-ячейками и ячейками с данными 2
RDF Коэффициент уменьшения скорости Множитель, управляющий уменьшением скорости передачи ячеек 1/16
ACR Разрешенная скорость ячеек Текущий верхний предел скорости источника; настраиваемый при помощи механизма обратной связи в диапазоне от MCR до PCR —
CRM Количество FRM-ячеек, которые могут быть посланы в отсутствии ответных BRM-ячеек 219-1
13.5. Управление трафиком в службе ABR
437
1 Л» Обозначение Название Описание Значение по умолчанию
V f ADTF Коэффициент времени уменьшения скорости ACR Допустимый интервал времени между передаваемыми RM-ячейками, прежде чем скорость будет снижена до ICR 0,5 мс
Тгт Верхняя граница интервала времени между последовательными RM-ячейками для активного источника 100 мс
FRTT Фиксированное время прохождения сигнала в оба конца Сумма фиксированной задержки и задержки распространения сигнала от отправителя до получателя и обратно —
ТВЕ Временное раскрытие буфера Договорное количество ячеек, которое источник может посылать изначально, прежде чем вернется первая RM-ячейка 22< -1
CDF Коэффициент уменьшения скорости Управляет уменьшением скорости ACR вместе с параметром CRM 1/16
TCR Целевая скорость ячеек Верхний предел скорости, с которой источник может отправлять избыточные FRM-ячейки 10 ячеек/с
Распределение ресурсов в службе ABR
Для поддержки службы ABR ATM-коммутаторы должны выполнять две функции:
♦ Борьба с перегрузкой. Поскольку служба ABR предназначена для минимиза-
ции потерь ячеек, коммутаторы должны использовать механизм управления
скоростью службы ABR для ограничения скорости прибывающих пакетов
до уровня, который может быть обработан сетью. Для этого коммутатор дол-
жен следить за размерами очередей и начинать снижать скорость, когда за-
полненность буферов достигает угрожающего уровня.
+ Справедливое распределение ресурсов. Коммутатор ATM должен выделять
каждому соединению, проходящему через него, справедливую долю своей
пропускной способности. Таким образом, при возникновении перегрузки
коммутатор должен снизить скорость передачи данных в соединениях, пользу-
ющихся неправомерно большой частью ресурсов коммутатора.
Эти требования сходны с аналогичными требованиями для маршрутизаторов
в IP-сетях, которые будут обсуждаться в главе 15. Различие заключается в том, что
в случае IP-маршрутизаторов источники могут получать только неявные сигналы
о возникновении перегрузки, выражающиеся в увеличении задержки и потере ячеек,
тогда как в службе ABR могут посылаться явные сигналы управления скоростью.
Коммутирующие алгоритмы для борьбы с перегрузкой и справедливого распре-
деления ресурсов можно разбить на две основные категории: схемы двоичного от-
ката, использующие только биты EFC1, CI и NI, и схемы явного задания скорости,
в которых используется поле ER. В этой области проводятся активные исследова-
ния. Здесь мы рассмотрим некоторые из наиболее важных схем обеих категорий.
438
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
Двоичные схемы обратной связи
Все двоичные схемы обратной связи обладают одной и той же общей структурой
ATM-коммутатор следит за уровнем использования своих буферов в каждом пор-
ту. При приближении перегрузки коммутатор устанавливает либо признак EFCI
в ячейке с данными, либо бит CI или NI в FRM- или BRM-ячейке. Разные схемы
различаются выбором соединения, которое уведомляется первым. Мы рассмотрим
три подхода: единая очередь FIFO, несколько очередей и уведомление о справед-
ливой доле.
Простейший подход заключается в том, чтобы выделить буфер в каждом вы-
ходном порту единой очереди FIFO (First In First Out — первым прибыл, первым
обслужен). Когда заполненность буфера превысит определенный уровень (на-
пример, 80 % от размера буфера), коммутатор начинает генерировать двоичные
уведомления до тех пор, пока заполненность буфера не снизится до безопасного
уровня. Уведомления могут генерироваться путем установки бита EFCI в каждой
входящей ячейке с данными или установки бита CI или NI в каждой проходящей
RM-ячейке. Незначительное усовершенствование такой схемы заключается в ис-
пользовании двух уровней управления. Когда длина очереди начинает превышать
верхнюю границу, запускается механизм двоичных уведомлений, отключающий-
ся, только когда заполненность буфера опустится до нижней границы. Это напо-
минает работу термостата и позволяет избежать частых переходов из одного со-
стояния в другое и обратно.
Такой подход кажется справедливым, так как соединение с большим относитель-
ным количеством ячеек, проходящих через коммутатор, с большей вероятностью
получит двоичное уведомление. Однако единая очередь FIFO может несправед-
ливо наказывать соединения, связывающие несколько коммутаторов. Предполо-
жим, что несколько сетевых коммутаторов перегружены. В этом случае соедине-
ния, связывающие большее количество коммутаторов, с большей вероятностью
получат двоичное уведомление, чем соединения с сопоставимым трафиком, но
с более коротким путем.
Справедливость может быть улучшена, если выделить каждому виртуальному
соединению или каждой группе виртуальных соединений отдельную очередь.
В каждой очереди используется свое пороговое значение, поэтому двоичное
уведомление выдается только виртуальным соединениям с длинными очередями.
Помимо того, что такой подход является более справедливым, у него есть еще два
преимущества. Во-первых, поскольку каждая очередь изолирована от остальных,
один плохо себя ведущий источник не влияет на другие виртуальные соедине-
ния. Во-вторых, задержки и потери ячеек в различных виртуальных соединениях
оказываются отделенными друг от друга, что позволяет предоставлять разным
виртуальным соединениям разные уровни качества обслуживания.
Более сложная схема называется выборочной обратной связью или разумной
маркировкой. Эта техника основана на попытке динамического предоставления
справедливой доли (fair share), которая может быть определена, например, следую-
щим образом:
Справедливая доля =
Целевая скорость
Количество соединений
13.5. Управление трафиком в службе ABR
439
Когда возникает перегрузка, коммутатор помечает ячейки любого виртуального
соединения, у которого текущая скорость ячеек CCR превышает справедливую долю.
Схемы обратной связи с явным указанием скорости
Во всех схемах обратной связи с явным указанием скорости испол!>зуется общая
последовательность действий:
1. Вычисление справедливой доли ресурсов для каждого виртуального соеди-
нения, которое может быть поддержано.
2. Определение текущего уровня нагрузки или степени перегрузки.
3. Вычисление значения ER (Explicit Rate — явная установка скорости ячеек)
для каждого соединения и передача этого значения источнику.
В оставшейся части этого раздела мы опишем следующие примеры схем обрат-
ной связи с явным указанием скорости:
4- EPRCA (Enhanced Proportional Rate Control Algorithm — усовершенство-
ванный пропорциональный алгоритм управления скоростью);
♦ ERICA (Explicit Rate Indication for Congestion Avoidance — явное указание
скорости для предотвращения перегрузки);
4 САРС (Congestion Avoidance using Proportional Control — предотвращение
перегрузки путем пропорционального управления).
При использовании алгоритма EPRCA коммутатор следит за средним значе-
нием текущей нагрузки в каждом соединении. Это значение называется средней
допустимой скоростью ячеек (Mean Allowed Cell Rate, MACR):
MACR(/) = (1 - a) MACR(7 - 1) + a • CCR(7)
Здесь CCR(Z) представляет собой значение поля CCR в 7-й прибывшей FRM-
ячейке. Подобные формулы для вычисления экспоненциального среднего значе-
ния уже неоднократно встречались в этой книге. Как правило, a = 1/16, поэтому
текущему значению придается относительно небольшой вес по сравнению с преды-
дущими значениями. Таким образом, MACR представляет собой оценку средней
нагрузки на коммутатор в текущий момент времени. Цель заключается в следую-
щем. При возникновении перегрузки коммутатор снижает допуст имую скорость
в каждом виртуальном соединении до величины, не превышающей DPF MACR,
где DPF означает коэффициент вертикального давления (Down Pressure Factor).
Поскольку во всех виртуальных соединениях допустимая скорость снижается до
одинакового уровня ER, считается, что торможение соединений выполняется спра-
ведливо. В частности, когда длина очереди у выходного порта превышает порого-
вую величину, значение поля ER во всех RM-ячейках проходящих через этот порт
соединений изменяется следующим образом:
ER <- min[ER, DPF • MACR]
Как правило, DPF = 7/8.
Схема EPRCA реагирует на возникновение перегрузки снижением значения
ER для виртуальных соединений, потребляющих больше ресурсов, чем им поло-
жейо по справедливости. Следующие две схемы представляют собой схемы пре-
дотвращения перегрузки, пытающиеся управлять значениями ER всех соедине-
440 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
ний, чтобы предотвратить наступление серьезной перегрузки. Подобные схемы за-
нимаются настройкой на основе коэффициента загрузки (Load Factor, LF), оп-
ределяемого следующим образом:
Lp Входная скорость
Целевая скорость 13.5)
Входная скорость измеряется и усредняется по фиксированному интервалу
времени, а целевая скорость устанавливается немного ниже пропускной способ-
ности линии (например, 85 или 90 %). Когда LF > 1, существует угроза перегруз-
ки, и для многих виртуальных соединений снижаются значения допустимой ско-
рости. Когда LF < 1, перегрузки нет, и в снижении скорости нет необходимости.
Коэффициент загрузки (LF) используется в обеих схемах, ERICA и С АРС, и в обо-
их случаях цель заключается в том, чтобы поддерживать коэффициент нагрузки
близким к 1.
В алгоритме ERICA справедливая доля для каждого соединения определяется
следующим образом:
_ Целевая скорость
Справедливая доля = —---------------------.
Количество соединений
Текущая доля, используемая конкретным виртуальным соединением, опреде-
ляется так:
Текущая доля =
CCR
LF
Такой способ вычисления доли может показаться странным. Попробуем вне-
сти ясность в этот вопрос при помощи формулы (13.5):
-г CCR
текущая доля =-----------------Целевая скорость.
Входная скорость
Первый элемент правой части формулы показывает, какая часть текущей на-
грузки, проходящей через этот выходной порт, приходится на данное виртуальное
соединение. Если умножить эту величину на целевую скорость, то мы получим
относительное значение целевой скорости, которое будет назначено этому вирту-
альному соединению, если мы просто увеличим или уменьшим скорости во всех
виртуальных соединениях так, чтобы суммарная входная скорость была равна
целевой скорости. Вместо того чтобы увеличивать или уменьшать скорости всех
виртуальных соединений, алгоритм ERICA избирательно изменяет скорости вир-
туальных соединений, так чтобы сумма всех значений ER была равна целевой ско-
рости и чтобы эта величина распределялась справедливо. Для этого используется
следующее распределение:
ER = шах[Справедливая доля, Текущая доля]. (13.6)
В результате при низких нагрузках (LF < 1) каждому виртуальному соедине-
нию назначается значение ER большее, чем его текущее значение CCR. При этом
каждое виртуальное соединение, чье значение текущей доли меньше его справед-
13.5. Управление трафиком в службе ABR
441
ливой доли, получает пропорционально большее увеличение скорости. При высо-
кой нагрузке (LF > 1) некоторым виртуальным соединениям назначается значение
ER большее, чем их текущее значение CCR, тогда как другим назначается более
низкое значение ER. Делается это так, чтобы дать преимущество виртуальным со-
единениям с меньшими долями.
Чтобы лучше понять работу алгоритма ERICA, рассмотрим случай, в котором
перегрузка невелика и все соединения начинают передачу на высоких скоростях
CCR. Алгоритм ERICA позволяет всем виртуальным соединениям изменить свои
скорости, установив их равными величине текущей доли для соединения, что долж-
но привести систему в состояние эффективной работы (LF =1). При такой нагруз-
ке, если некоторые виртуальные соединения снизят скорость (уменьшат значение
CCR), тогда коэффициент нагрузки LF уменьшится, а индивидуальные значения
текущей доли увеличатся. Однако независимо от нагрузки источникам разреша-
ется передавать данные со скоростью, по меньшей мере равной справедливой доле.
В результате алгоритм ERICA улучшает справедливость на каждом шаге даже при
наличии перегрузки [128].
В формуле (13.6) не учитываются ограничения, накладываемые на поток дру-
гими коммутаторами выше по течению. Ни одному коммутатору не разрешается
увеличивать значение ER в RM-ячейке, поэтому мы должны пересмотреть алго-
ритм распределения следующим образом:
ER„OBoe = min[ERcT4Mc> шах[Справедливая доля, Текущая доля]]. (13.7)
Здесь ERCTaPl)i; представляет собой значение поля ER во входящей RM-ячейке,
a ER11OBO1. — значение того же поля в исходящей RM-ячейке.
В алгоритме САРС для расчета значений ER также используется коэффициент
нагрузки LF. Вначале справедливая доля для каждого виртуального соединения
устанавливается, как и в алгоритме ERICA, равной целевой скорости, деленной
на количество соединений. Затем с каждой поступающей RM-ячейкой величина
справедливой доли изменяется следующим образом:
если LF < 1 Справедливая доля <— Справедливая доля min[ERU,
1 + (1 - LF) Rup];
если LF > 1 Справедливая доля <— Справедливая доля • max[ERU,
1 - (LF - 1) Rdn], ,
Здесь:
♦ ERU — максимальное увеличение, допустимое при распределении справед-
ливой доли (ERU > 1);
♦ Rup — параметр наклона графика, находящийся в пределах от 0,025 до 0,1;
♦ ERF — максимальное уменьшение, допустимое при распределении справед-
ливой доли (как правило, ERF = 0,5);
♦ Rdn — параметр наклона графика, находящийся в пределах от 0,2 до 0,8.
Если вычисленное значение справедливой доли меньше, чем значение ER в
RM-ячейке, тогда значение поля ER в RM-ячейке устанавливается равным вели-
чине справедливой доли.
442 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM I
Алгоритм САРС проще в реализации, чем алгоритм ERICA. Однако если ко!
эффициент увеличения скорости RIF установлен слишком высоко, при использо!
вании этого алгоритма наблюдается очень значительная осцилляция скорости!
Кроме того, алгоритм САРС иногда может приводить к несправедливому распре!
делению ресурсов [15].
13.6. Управление трафиком в службе GFR
Служба GFR с точки зрения оконечной системы столь же проста, как и служба
UBR, но в то же время предъявляет относительно скромные требования к элемен-
там сети ATM в плане сложности обработки и накладных расходов. По сути, при
использовании службы GFR оконечная система не занимается регулированием
или формированием передаваемого ею трафика, но может передавать данные со
скоростью линии ATM-адаптера. Как и в случае службы UBR, не предоставляет-
ся никаких гарантий доставки кадров. Обязанность реагировать на возникнове-
ние перегрузки, в результате которой происходит потеря кадров, возложена на
более высокий уровень, например TCP. Выполняет это более высокий уровень
при помощи алгоритмов управления окном и методов борьбы с перегрузкой, об-
суждавшихся в главе 12. В отличие от службы UBR служба GFR позволяет пользо-
вателю резервировать определенный объем ресурсов, измеряемых в количестве
ячеек, переданных в единицу времени для каждого виртуального соединения GFR.
Такое резервирование гарантирует, что приложение сможет передавать данные с
минимальной скоростью и без потерь. Если сеть не перегружена, пользователь
сможет передавать данные с большей скоростью.
Отличительной особенностью службы GFR является то, что она требует, что-
бы сеть распознавала не только ячейки, но и кадры. При возникновении перегруз-
ки сеть отбрасывает не отдельные ячейки, а целые кадры. Более того, для службы
GFR требуется, чтобы у всех ячеек одного кадра был одинаково установлен бит
CLP. Кадры уровня AAL5 с битом CLP = 1 считаются низкоприоритетными и пе-
редаются по каналу, только если для их передачи есть свободные ресурсы. Мини-
мальные гарантированные ресурсы касаются кадров с CLP = 0.
Договор о трафике для службы GFR состоит из следующих параметров:
♦ пиковой скорости ячеек (Peak Cell Rate, PCR);
♦ минимальной скорости ячеек (Minimum Cell Rate, MCR);
♦ максимального размера всплеска (Maximum Burst Size, MBS);
максимального размера кадра (Maximum Frame Size, MFS);
♦ допуска на разброс задержек передачи ячеек (Cell Delay Variation Tolerance,
CDVT).
Механизм обеспечения гарантий скорости
Существует три основных подхода, которые могут использоваться сетью, чтобы
предоставить гарантии скорости каждому виртуальному соединению, пользуюшеч
13.6. Управление трафиком в службе GFR
443
муся службой GFR, и позволить нескольким пользователям эффективно расходо-
вать сетевые ресурсы и справедливо распределять их между пользователями 199]:
+ маркировка и регулирование;
♦ управление буфером;
+ планирование.
Эти методы могут объединяться элементами сети ATM различными способа-
ми, в результате чего мы можем получить несколько вариантов реализации служ-
бы GFR. Их использование иллюстрирует рис. 13.15.
проверки
приемлемости
гарантии
согласованности
качества
обслуживания
Рис. 13.15. Основные механизмы службы GFR [7]
Маркировка и регулирование
Маркировка требуется для того, чтобы различать кадры, соответствующие и не
соответствующие договору о трафике службы GFR. Элемент сети, проверяющий
согласованность, устанавливает бит CLP = 1 во всех ячейках каждого кадра, не со-
ответствующих договору. Поскольку помеченные ячейки считаются нарушающи-
ми договор о трафике, последующими механизмами, например управления буфе-
рами или планирования, им предоставляется более низкое качество обслуживания,
чем немаркированным ячейкам. Маркировка может осуществляться сетью, в ос-
новном сетевыми элементами на входе в сеть ATM. Но маркировкой ячеек также
может заниматься передающая оконечная система, помечая, таким образом, менее
важные ячейки.
Входной элемент сети или коммутирующий элемент сети ATM может также
отбрасывать ячейки кадров, не соответствующие договору (то есть ячейки с битом
CLP =1). Отбрасывание ячеек считается функцией регулирования.
Управление буфером
Механизмы управления буфером имеют дело с ячейками, уже помещенными в
буфер сетевого коммутатора или поступающими на коммутатор и буферизуемые
Перед тем, как отправляться дальше по сети. При возникновении перегрузки, что
Проявляется высоким уровнем заполненности буфера, сетевой элемент будет от-
брасывать маркированные ячейки в первую очередь. В частности, сетевой элемент
444
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
может отбросить помеченную ячейку, уже находящуюся в буфере, чтобы освобо-
дить место для входящей непомеченной ячейки. Для обеспечения справедливого
и эффективного расходования буферных ресурсов сетевой элемент может раздельно
буферизовать каждое виртуальное соединение, выделяя ему определенный объем
буферного пространства. Кроме того, на основе договоров о трафике для каждого
виртуального соединения и степени заполненности буфера ячейками этого виртуаль-
ного соединения сетевой элемент может принимать решения, касающиеся отбрасы-
вания ячеек. Таким образом, отбрасывание ячеек для каждой очереди может про-
изводиться на основе соответствующего порогового значения заполненности буфера.
Планирование
Функции планирования, по меньшей мере, могут предоставить непомеченным
ячейкам преимущественное обслуживание по сравнению с помеченными ячейка-
ми. Сеть также может поддерживать несколько отдельных очередей для каждого
виртуального соединения и принимать решения, касающиеся планирования, от-
дельно для каждого виртуального соединения. Таким образом, в пределах каждой
очереди может применяться дисциплина FIFO, возможно, измененная с тем, что-
бы предоставить более высокий приоритет планированию кадров со значением
бита CLP = 0. Планирование очередей позволяет сетевому элементу контролиро-
вать выходную скорость отдельных виртуальных соединений и таким образом
гарантировать, что отдельное виртуальное соединение получит справедливую
долю ресурсов, в то же время выполняя требования договора о трафике в плане
минимальной скорости ячеек для каждого виртуального соединения.
Согласованное определение для службы GFR
Первая функция, показанная на рис. 13.15, — это функция UPC (Usage Parameter
Control — контроль параметров использования). Функция UPC отслеживает ра-
боту каждого виртуального соединения, чтобы гарантировать согласованность тра-
фика, то есть соответствие трафика каждого соединения договору о трафике, а так-
же помечает или отбрасывает ячейки, не соответствующие договору о трафике.
Кадр считается согласованным, если все его ячейки соответствуют договору.
Если хотя бы одна ячейка не соответствует договору, весь кадр считается не соот-
ветствующим. Чтобы ячейка соответствовала договору, необходимо выполнение
трех условий:
♦ Скорость ячеек должна соответствовать параметрам договора о скорости яче-
ек. Это определяется при помощи общего алгоритма скорости ячеек (рис. 13.6)
и параметров PCR и CDVT, указанных для этого соединения. В частности,
рассматриваемая ячейка должна удовлетворять алгоритму GCRA(1/PCR,
CDVT), где значение PCR определено для потока ячеек CLP = 0+1. Алго-
ритм GCRA применяется к каждой ячейке и таким образом обновляется для
каждой ячейки, удовлетворяющей тесту GCRA.
♦ Все ячейки кадра должны иметь одинаковое значение бита CLP. Таким
образом, бит CLP любой ячейки должен совпадать с битом CLP первой
ячейки кадра.
13.6. Управление трафиком в службе GFR
445
Ж
♦ Кадр, содержащий ячейку, должен удовлетворять параметру MFS, то есть
либо ячейка должна быть последней ячейкой кадра, либо количество ячеек
с начала кадра по указанную ячейку включительно должно быть меньше,
чем MFS.
Механизм проверки приемлемости качества
обслуживания
Первые два блока на рис. 13.15 иллюстрируют двухэтапный процесс фильтрации.
Сначала кадры проверяются на соответствие договору о трафике. Если кадр, ячей-
ки которого не соответствуют договору о трафике, не отбрасывается, его ячейки
маркируются (CLP = 1), в результате они могут быть отброшены сетью позже.
Поэтому на первом этапе проверки скорость потока сравнивается с верхней гра-
ницей скорости трафика и наказываются ячейки, скорость которых превышает эту
верхнюю границу.
На втором этапе механизм фильтрации определяет, какие кадры являются при-
емлемыми в плане обеспечения качества обслуживания, указанного в договоре о
трафике службы GFR для данного виртуального соединения. На этом этапе рас-
сматривается нижняя граница трафика. Кадры, составляющие поток трафика ниже
определенного порогового уровня за данный период времени, считаются пригод-
ными для обслуживания с оговоренным уровнем качества.
Таким образом, кадры, передаваемые по виртуальному соединению GFR, мож-
но разделить на три категории:
♦ Кадры, не соответствующие договору. Ячейки таких кадров будут маркиро-
ваны или отброшены.
♦ Кадры, соответствующие договору, но непригодные по критериям качества
обслуживания. Ячейки таких кадров получат обслуживание по остаточно-
му принципу (то есть с максимальными усилиями).
♦ Кадры, соответствующие договору и пригодные для обслуживания с согласо-
ванным уровнем качества. Ячейки таких кадров получат гарантии доставки.
Для определения пригодности ячеек для обслуживания с согласованным уров-
нем качества используется разновидность алгоритма GCRA, При управлении тра-
фиком службы GFR применяется параметр допуска на всплеск (Burst Tolerance,
ВТ), обсуждавшийся в разделе 13.4. Для проверки пригодности ячеек параметр ВТ
определяется следующим образом:
ВТ = (MBS-1)| —------— 1 (13.8)
\MCR PCR J
Эта формула полностью совпадает с формулой (13.4). В данном случае па-
раметр ВТ обозначает глубину ведра, требуемого для MBS ячеек, поступающих
в ведро со скоростью PCR и вытекающих из ведра со скоростью MCR. Для службы
GFR было бы желательно, чтобы всплеск ячеек мог вместить целый кадр. То есть
хотелось бы, чтобы источник мог передавать каждый кадр в виде непрерывного
пакета (всплеска) ячеек. Соответственно, спецификация ТМ4.1 накладывает на
446 Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
максимальный размер всплеска (MBS), измеряемый в ячейках, следующие огра-
ничения:
MBS > 1 +
MFS-PCR
PCR - MCR j
(13.9)
Значение данного ограничения становится ясным, если объединить формулы
(13.8) и (13.9). После некоторых преобразований мы получим:
ВТ>
MFS
MCR
(13.10)
Как видно из формулы (13.10), значение параметра ВТ должно быть достаточно
большим, чтобы принять кадр размером в MBS ячеек, переданный со скоростью MCR.
Используя данные формулы, мы можем определить тест пригодности для служ-
бы GFR с помощью модифицированного алгоритма GCRA, называемого F-GCRA
(Frame-based Generic Cell Rate Algorithm — общий алгоритм скорости ячеек для
кадров). В частности, для потока ячеек, соответствующих договору, мы будем ис-
пользовать алгоритм F-GCRA(7’, L) с параметрами Т = 1 /MCR и L = ВТ + CDVT.
На рис. 13.16 показана блок-схема алгоритма (сравните с рис. 13.6). Обратите вни-
мание на то, что пригодность ячеек определяется по первой ячейке кадра. Если эта
ячейка пригодна, то и все последующие ячейки этого кадра считаются пригодны-
ми. Как и на рис. 13.6, здесь используются следующие обозначения:
♦ Т — приращение;
♦ L — предел;
♦ tu(k) — время прибытия ячейки k;
♦ X — счетчик «дырявого» ведра;
4- X' — вспомогательная переменная;
4- ТАТ (Theoretical Arrival Time) — теоретическое время прибытия;
♦ LCT (Last Pass Time) — время последнего прохождения.
Сеть может отбросить или пометить любую не соответствующую договору ячей-
ку. Однако, как утверждается в спецификации ТМ 4.1, предполагается, что при
наличии свободных ресурсов реализация будет пытаться поддерживать трафик,
соответствующий договору, сверх ограничений алгоритма F-GCRA. При этом каж-
дому соединению предоставляется служба GFR со справедливой долей локальной
остаточной пропускной способности. В спецификации не определяется критерий,
при помощи которого следует определять, соответствует ли данная реализация
упомянутым ранее ожиданиям.
13.7. Рекомендуемая литература
В [91] предоставляется обоснование категорий служб ATM, а также обсуждаются
вопросы управления трафиком в каждой службе. В [151] содержится детальное
обсуждение темы управления ATM-трафиком в службах CBR и VBR. Характери-
стики и производительность трафика сетей ATM также обсуждается в [95] и [201]-
13.7. Рекомендуемая литература
447
В момент прибытия первой ячейки
соединения ТАТ = (,(1)
Виртуальный алгоритм планирования
В момент прибытия первой ячейки соединения
Х= 0 и LPT = Ц1)
Алгоритм «дырявого» ведра с устойчивым состоянием
Рис. 13.16. Упрощенный алгоритм F-GCRA(T, L)
448
Глава 13. Управление трафиком и борьба с перегрузкой в сетях ATM
[47] представляет собой подробное обсуждение службы ABR, причем эта
служба сравнивается со службами CBR и VBR, также рассматривается механизм
управления трафиком. В [127] предоставляется детальное разъяснение поведения
передающей и принимающей систем при передаче информационных и управляю-
щих ячеек. В [15] содержится детальный обзор схем распределения ресурсов Дчя
службы ABR. [193] представляет собой обсуждение влияния различных элемен-
тов механизма управления трафиком службы ABR на производительность. Ана-
лиз производительности также можно найти в [34] и [ 171 ]. В [131] приводится
всестороннее описание алгоритма ERICA и его реализации.
В [7] предоставляется понятное и подробное описание службы GFR. С этой
службой также можно познакомиться, прочитав [33].
13.8. Задания
1. При обсуждении времени задержки и скорости передачи данных в разде-
ле 13.1 был приведен пример, в котором отправитель успевал передать 7 Мбит,
прежде чем к нему приходил ответ от получателя. Но разве метод управле-
ния потоком при помощи скользящего окна, например, используемый в про-
токоле HDLC, не разработан специально для решения проблем больших за-
держек распространения данных?
2. Докажите следующее:
а) формула (13.1) правильна;
б) формула (13.2) правильна ;
в) формула (13.3) правильна.
3. Покажите, что за любой интервал времени t количество ячеек N(t), которые
могут быть переданы с интервалом, не меньшим чем Т, и, тем не менее, соот-
ветствовать тесту GCRA(7), т,), ограничено выражением
N(t) < min
t + i,
£
Т
4. Для алгоритма ERICA рассмотрите действие на коммутаторе, в котором
значение поля ER каждой входящей ячейки больше или равно входящему
значению CCR, так что мы можем использовать формулу (13.6) вместо фор-
мулы (13.7). Это соответствует случаю, в котором другие коммутаторы не
ограничивают потока. Перечислите условия (например, в показателях LF,
справедливой доли, текущей доли), при которых значение ER, назначаемое
виртуальному соединению, больше, чем текущее значение скорости CCR,
а также условия, при которых ER < CCR.
I
Часть V
Маршрутизация
в объединенных сетях
Архитектура сегодняшнего Интернета построена на основе небольшого количества
(около дюжины на момент написания книги) основных магистралей, которыми
управляют поставщики сетевых услуг. Каждая магистраль представляет собой сеть
с коммутацией пакетов, состоящую из высокоскоростных линий связи, к которой
по периферии присоединены высокопроизводительные маршрутизаторы. Постав-
щики сетевых услуг обмениваются трафиком в точках обмена. Локальные и ре-
гиональные поставщики услуг Интернета занимаются поддержкой собственно-
го сетевого оборудования, состоящего из маршрутизаторов и линий связи, а также
заключают контракты с владельцами магистралей, что позволяет их клиентам об-
мениваться информацией на больших расстояниях.
Частные сети, которыми владеют и управляют коммерческие фирмы, как пра-
вило, состоят из нескольких локальных сетей типа Ethernet, соединенных при по-
мощи выделенных линий или сетей с коммутацией пакетов, которые могут быть
как частными, так и общественными. Эти сети могут обладать одной или несколь-
кими точками доступа к Интернету.
В настоящее время трафик, который должны поддерживать Интернет и эти ча-
стные объединенные сети, продолжает расти и изменяться. Даже традиционных
приложений передачи данных, таких как электронная почта, новости USENET,
приложения передачи файлов и удаленной регистрации, достаточно, чтобы стать
источником серьезных проблем для этих систем. Но главным фактором, влияю-
щим на ситуацию в Сети, является Всемирная паутина, которой требуется предо-
ставление отклика в реальном времени, а также все увеличивающиеся объемы пе-
редаваемых изображений, а также аудио- и даже видеоданных.
Такие схемы объединенных сетей, по существу, реализуют дейтаграммную
технологию с коммутацией пакетов, с маршрутизаторами, функционирующи-
ми в роли коммутаторов. Эта технология изначально не предназначалась для пе-
редачи звука и видеоизображения, и ей трудно соответствовать предъявляемым
требованиям. Хотя кое-кто предсказывает замену этого конгломерата локальных
сетей типа Ethernet, пакетных глобальных сетей и маршрутизаторов, работающих
с IP-дейтаграммами, на бесшовную транспортную службу ATM, связывающую на-
стольный компьютер с магистралью, этот день наступит еще не скоро. Между тем,
существующие на данный момент объединенные сети должны совершенствовать-
ся, чтобы выдерживать все увеличивающуюся нагрузку.
450
Часть V. Маршрутизация в объединенных сетях
Проблемы производительности в окружении объединенных сетей проще всего
видеть на примере Интернета. На протяжении одного только 1996 г. поставщики
сетевых служб регулярно сообщали о потерях до 30 % пакетов. Кроме того, в этом
году наблюдался период, когда потери достигали 50 % [39]. Уже потеря 10 % паке-
тов заметно сказывается на производительности сети, тогда как при потере 50 %
пакетов сетевая служба становится фактически бесполезной. Более поздние ис-
следования продолжают свидетельствовать о подобном снижении производитель-
ности [36]. Большая часть проблем связана не столько с самим трафиком, сколько
с маршрутизаторами, не справляющимися с поддержанием таблиц маршрутизации
и выбором оптимальных маршрутов для данного класса трафика. Эти проблемы
также характерны для частных объединенных сетей, в частности при предоставле-
нии таких йнтранет-служб, как Паутина, а также при использовании сетей Ethernet
и глобальных сетей с коммутацией пакетов для передачи аудио- и видеоданных.
Доказавшие свою эффективность в сетях ATM методы борьбы с перегрузкой и
стратегии регулирования трафика невозможно напрямую перенести на не требу-
ющую соединений пакетную архитектуру объединенных сетей. В подобной архи-
тектуре отсутствуют сквозные виртуальные каналы, которыми можно управлять,
регулируя их пропускную способность и скорость передачи данных. Вместо этого
ключом к эффективному управлению производительностью в окружении пакет-
ных объединенных сетей является маршрутизатор.
♦ Маршрутизатор должен обладать обрабатывающими мощностями для пе-
ремещения IP-дейтаграмм со сверхвысокими скоростями.
♦ Маршрутизатор должен обладать достаточным знанием сетевой конфигу-
рации для выбора маршрута, соответствующего данному классу трафика, и
компенсации перегрузок и неисправностей в объединенной сети.
♦ Маршрутизатор должен пользоваться эффективной схемой обмена инфор-
мацией о маршрутах с другими маршрутизаторами, чтобы она не оказывала
существенной дополнительной нагрузки на сеть.
Первый пункт решается на уровне процессора и операционной системы и не
рассматривается в данной книге. Остальные пункты касаются функций маршру-
тизации и протоколов маршрутизации, поддерживающих эти функции. Этим воп-
росам и посвящена часть V.
♦ Глава 14. Теория графов и поиск путей с минимальной стоимостью. Цент-
ральная задача маршрутизатора заключается в пересылке IP-дейтаграмм по
маршруту, выбранному на основе какого-либо критерия. Для этого каждо-
му ретрансляционному участку между двумя маршрутизаторами для дан-
ного типа службы присваивается метрика маршрута, или ценовая функция.
Маршрутизатор должен выбрать маршрут с минимальной стоимостью пе-
ресылки дейтаграммы. В главе 14 представлены алгоритмы, как правило,
используемые для нахождения такого пути. В этой главе читатель также
знакомится с некоторыми элементарными понятиями теории графов, необ-
ходимыми для разработки алгоритмов маршрутизации.
♦ Глава 15. Протоколы внутренней маршрутизации. Для нахождения марш-
рута с минимальной стоимостью маршрутизатор должен обладать некото-
Часть V. Маршрутизация в объединенных сетях
451
рой информацией о стоимости альтернативных путей через объединенную
сеть, частью которой он является. В главах 15 и 16 рассматриваются важ-
ные протоколы, используемые для получения подобной информации. Гла-
ва 15 посвящена, главным образом, протоколам внутренней маршрутизации,
используемым маршрутизаторами в пределах одной автономной системы.
По сути, автономная система представляет собой набор соединенных друг с
другом маршрутизаторов и сетей, управляемых одной организацией и ис-
пользующих общий протокол маршрутизации. В главе 15 исследуются два
наиболее важных протокола внутренней маршрутизации: RIP и OSPF.
♦ Глава 16. Протоколы внешней маршрутизации и групповая рассылка. В то
время как маршрутизаторы внутри одной автономной системы, пользующи-
еся протоколом внутренней маршрутизации, должны обмениваться подроб-
ной информацией о топологии сети и состоянии трафика в автономной сис-
теме, протоколы внешней маршрутизации, используемые между автономными
системами, в основном обмениваются меньшими объемами данных об общих
маршрутах между сетями и автономными системами. В главе 16 исследуются
два протокола внешней маршрутизации: BGP и IDRP, — а также рассмат-
риваются вопросы групповой рассылки и применения протоколов маршру-
тизации при групповой рассылке.
Глава 14
Теория графов и поиск путей
с минимальной стоимостью
Карта лондонской подземки, развешенная во всех ваго-
нах, была своего рода моделью, произведением искус-
ства. Она представляла сеть подземных туннелей в виде
геометрической сетки. Линии метро, конечно, не распо-
лагаются друг к другу под прямыми углами, как улицы
Манхэттена. Они также не расходятся под острыми угла-
ми и не образуют прямоугольников.
Барбара Вайи (Рут Ренделл). Ковер царя Соломона
Компьютерные сети, как правило, представляются в виде графов, при этом ком-
мутаторы и маршрутизаторы сетей являются узлами графа, а линии связи пред-
ставляют собой ребра графа. Ряд понятий из теории графов оказываются полез-
ными при разработке сетей и алгоритмов маршрутизации.
Эта глава начинается со знакомства с некоторыми элементарными концепция-
ми из теории графов. Затем мы рассмотрим два алгоритма поиска кратчайшего
пути и протоколы маршрутизации в объединенных сетях.
В протоколах маршрутизации, обсуждающихся в главах 15 и 16, для выбора
маршрутов используются алгоритмы, описываемые в данной главе. Однако для
понимания работы этих протоколов маршрутизации исчерпывающее знание ал-
горитмов поиска кратчайшего пути не требуется. Соответственно, при первом зна-
комстве с книгой читатель может просто просмотреть эту главу или вообще ее про-
пустить.
14.1. Элементарные понятия теории графов
Граф G( V, Е) состоит из объектов двух типов: вершин (vertices), или узлов (nodes),
и ребер (edges), или связей (links), при этом каждое ребро графа определяется как
неупорядоченная пара вершин. Таким образом, ребро ( Уь V2) представляет собой
то же самое, что и ребро (14, Ц)- При изображении графов вершины представля-
ются точками или кружками, а ребра — линиями, соединяющими вершины. На-
пример, на рис. 14.1,о множество вершин V— это{Т1, V2, Уз, У4, V5, 14}, а множество
14.1. Элементарные понятия теории графов
453
ребер £- это {(Vj, V2), (V,, V3), (V,, V4), (V2, V3), (V2, V4), (V3, V4), (V3, Vs), (V3, V6),
(V4, Vs), (Vs, V6)}. Вершины i и j из множества вершин V называются смежными
(adjacent), если ребро (г, у) принадлежит множеству ребер Е. При этом ребро (г, /)
называется инцидентным (incident) вершинам г и j.
Рис. 14.1. Граф с матрицей смежности
Величина графа характеризуется количеством вершин |К|, называемым поряд-
ком (order) графа G, а число ребер |£| называется размером (size) графа G. Время
работы алгоритма, обрабатывающего граф, зависит, главным образом, от этих двух
параметров. У представленного на рисунке графа | V| = 6, а |£| = 10.
Граф также часто представляется в виде матрицы смежности (adjacency matrix).
Вершины нумеруются произвольным образом от 1 до |Vj. Затем матрица смежно-
сти А = (а,,) размерности |Vj х | V] определяется следующим образом:
1, если (г, /) е Е,
аи ~
[0 в противном случае.
На рис. 14.1, б приведен пример матрицы смежности. Обратите внимание на то,
что эта матрица является симметричной относительно диагонали, проходящей
от левого верхнего до правого нижнего угла. Это объясняется тем, что ребра графа
определены как неупорядоченные пары.
Два ребра, инцидентные одной и той же паре вершин, называются параллель-
ными (parallel). Ребро, инцидентное всего одной вершине, называется петлей (loop).
Граф, в котором отсутствуют петли и параллельные ребра, называется простым
графом (simple graph).
Путем (path) от вершины i до вершины j называется такая последователь-
ность вершин и ребер, начинающаяся с вершины i и закапчивающаяся вершиной
J, в которой каждое ребро является инцидентным двум вершинам, соседним с ним
в этой последовательности. Путь называется простым (simple path), если в по-
следовательности каждое ребро и каждая вершина присутствуют только однаж-
ды. В простом графе путь может быть определен как последовательность вершин,
в которой каждая вершина является смежной с предыдущей и следующей верши-
нами в последовательности и пи одна из вершин не повторяется.
454
Глава 14. Теория графов и поиск путей с минимальной стоимостью
Ниже перечислены пути от вершины Ц до вершины 14 (см. рис. 14.1):
Vt, V2, V3, 14, Vs, 14;
V i, V2, V3, V5, V6;
Уь 14, Из, 14;
Vt, V2, V4, V3, V5, Ve;
Vh 14, V4, Vs, V6;
V i, 14, V2, 14, v5, И;
V i, V3, V4, V5, 14;
V i, V3, Vs, 14;
Vb V3, 14;
V i, 14, V2,14, V5,14;
V i, V4, V2, Из, 14;
V i, V4, Из, И5> 14;
и„ V4, Из, 14;
Иь V4, Vs, VB.
Из этих 14 путей путь 14, Из, 14 является самым коротким, так как он состоит всего
из двух ребер. В общем случае расстояние (distance) между двумя вершинами рав-
но минимальному количеству ребер во всех путях, соединяющих эти вершины.
Циклом (cycle), или замкнутым маршрутом, называют путь, начинающийся и
заканчивающийся в одной и той же вершине. Например, 14, 14,14, 14 представляет
собой цикл графа, показанного на рис. 14.1.
Наконец, граф называется связным (connected graph), если существует путь
между двумя любыми его вершинами.
Ориентированный граф и взвешенный граф
Ориентированный граф (digraph) G(V,E) состоит из множества вершин Vи множе-
ства ребер Е, при этом каждое ребро определяется как упорядоченная пара вершин.
Вершины ориентированных графов также обозначаются точками или кружками,
а ребра — стрелками, соединяющими вершины. Как правило, в ориентированных
графах допускается наличие параллельных ребер при условии, что параллельные
ребра ориентированы в противоположном направлении. Такие ориентированные
графы хорошо подходят для представления компьютерных сетей, в которых каж-
дое ребро обозначает поток данных в одном направлении между узлами сети.
Для описания ориентированного графа также может использоваться матрица
смежности, но в данном случае эта матрица уже не будет симметричной, если толь-
ко каждая пара смежных вершин не соединена парой параллельных ребер.
Взвешенным графом (weighted graph) и взвешенным ориентированным графом
(weighted digraph) называется такой граф, в котором каждому ребру поставлено
в соответствие некоторое число. Пример взвешенного ориентированного графа
показан на рис. 14.2, а1. Матрица смежности А = (ап) определяется для такого гра-
фа следующим образом (14.2, б):
1 Этот взвешеныяй ориентированный граф часто используется для иллюстрации алгоритмов маршру-
тизации. Впервые он был опубликован в [200].
14.1. Элементарные понятия теории графов
455
, если (г, j) е Е,
О в противном случае.
Здесь Wjj представляет собой вес, поставленный в соответствие ребру
Рис. 14.2. Взвешенный ориентированный граф с матрицей смежности
Во взвешенном графе (обычном или ориентированном) длиной (length) пути
называется сумма весов всех ребер пути. В табл. 14.1 показаны длины путей между
вершинами Vt и У6 в графе, представленном на рис. 14.2, а также соответствующие
этим путям расстояния. Обратите внимание на то, что путь с кратчайшим расстоя-
нием, то есть с минимальным количеством ребер (Vi, Уз, 14), не совпадает с крат-
чайшим путем, то есть с путем с наименьшим весом ( Vi, V4, Vs, 14).
Таблица 14.1. Расстояния и длины путей от V до УБ в графе на рис. 14.2
Путь Расстояние Длина
Vi, У2, Уэ, Ул, У5, Уб 5 11
И, У2. Уз, У5, У6 4 8
И, У2, Уз, Уб 3 10
Vi, И>, У4, Уз, У6, Уб 5 10
Vi, Уз, Ул, Уб, Уб 4 7
Vi, Уз, Уз, Ул, Уб, Уб 5 16
У., Уз. Ул, Уб, Уб 4 11
И, Уз, Уб, Уб 3 8
И, Уз, Уб 2 10
У., У,, Уз, Уз, У5, Уб 5 9
Vi, У,, Уз, Уз, Уб 4 11
Vi, V4, V3, V5, Ve 4 7
Vi, Ул, Уз, Уб 3 9
У, Ул, Уб, Уб 3 4
456
Глава 14. Теория графов и поиск путей с минимальной стоимостью
Деревья
Деревья (trees) являются наиболее часто используемым подклассом графов. Дере-
вья находят множество применений в кибернетике и в компьютерных сетях. Ниже
приводятся несколько эквивалентных определений деревьев.
4- Дерево представляет собой простой граф, удовлетворяющий следующему
условию: если i и j являются вершинами дерева Т, то вершины г и j соединя-
ет единственный простой путь.
4 Простой граф из N вершин является деревом, если у него N - 1 ребер и нет
циклов.
4 Простой граф из N вершин является деревом, если у него N- I ребер и он
является связным.
На рис. 14.3 приведен пример дерева.
Одна из вершин дерева может быть назначена его корнем (root). Как правило,
она изображается вверху диаграммы. На рис. 14.3 корнем дерева является верши-
на Vi. Под вершиной на одном уровне располагаются вершины, смежные с корнем.
Это вершины, которые от корня дерева отделяет расстояние в 1 ребро. Под каждой
из этих вершин располагаются вершины, смежные с вершинами первого уровня.
Они удалены от корня дерева на расстояние 2. Так продолжается произвольное
количество уровней. У каждой вершины, кроме корня, есть единственная роди-
тельская (parent) вершина, смежная с ней со стороны корня. У каждой вершины
может быть ноль или больше дочерних (child) вершин, смежных с ней с противо-
положной стороны от корня. Вершина, не имеющая дочерних вершин, называется
концевой вершиной, или листом (leaf).
Для удобства корню дерева назначается уровень 0. Вершинам, располагающим-
ся непосредственно под корнем, назначается уровень 1. Вершины, являющиеся
дочерними по отношению к вершинам уровня 1, образуют уровень 2. Все эти вер-
шины соединены с корнем путями с расстоянием в два ребра.
Связующее дерево
Прежде чем дать определение важной концепции связующего дерева, нам требу-
ется определение подграфа. Подграфом (subgraph) графа G называется подмноже-
ство вершин и ребер графа G, выбранное таким образом, что для каждого ребра,
входящего в подграф, две инцидентные этому ребру вершины также входят в под-
14.1. Элементарные понятия теории графов
457
граф. Более формально, граф G'(V, Е) является подграфом графа G’(V, £), если,
во-первых, V a VnE' с Е, а во-вторых, для каждого ребра е', принадлежащего Е'
(то есть е' е Е') и инцидентного вершинам о' и w', выполняется условие v', И.
Подграф Т графа G называется связующим деревом (spanning tree) графа G, если
подграф Т представляет собой дерево и включает в себя все вершины графа G.
Другими словами, связующее дерево Т создается из графа G путем удаления из
него ребер таким образом, что в графе G исчезают все циклы, но он остается связ-
ным. Связность графа сохраняется, пока мы будем удалять по одному ребру из
одного существующего цикла. Таким образом, если у нас есть граф, по меньшей
мере, с одним циклом, то при удалении одного ребра из этого цикла цикл разрыва-
ется, но связность сохраняется. Повторяя эту операцию, можно удалить все цик-
лы, сохранив при этом связность.
Дерево, показанное на рис. 14.3, является связующим для графа, представленного
на рис. 14.1. а. В общем случае связующее дерево графа не является уникальным.
Например, на рис. 14.4 показаны два других связующих дерева для того же графа1.
Рис. 14.4. Связные деревья для графа, показанного на рис. 14.1
Поиск в ширину для создания связующего дерева
Нам может понадобиться найти связующее дерево для имеющегося графа. Эта за-
дача подробно исследовалась, так как автоматизированные методы поиска связу-
ющих деревьев применимы ко многим проблемам. В частности, один из наиболее
распространенных методов нахождения связующих деревьев известен под назва-
1 Для простоты сравнения с рис. 14.1 деревья, показанные на рис. 14.4, не соответствуют принятому
соглашению, по которому корень дерева изображается наверху.
458
Глава 14. Теория графов и поиск путей с минимальной стоимостью
нием поиска в ширину (Breadth-First Search, BFS1). Как мы увидим в разделе 14.2,
алгоритм нахождения кратчайшего маршрута Дейкстры (Dijkstra) использует ме-
тод поиска в ширину.
В основе метода поиска в ширину лежит идея обработки всех вершин данного
уровня, прежде чем перейти к следующему уровню. В ходе поиска мы разделяем
вершины графа па множества вершин разных уровней. Начнем с любой вершины х
и назначим ей уровень 0. Всем вершинам, смежным с вершиной х, назначается уро-
вень 1. Пусть Ит, Иг,..., И, являются вершинами уровня г. Рассмотрим все вершины,
смежные с вершиной Ит, не находящиеся на уровнях 0,1,2 i, и назначим этим вер-
шинам уровень (г + 1). Затем рассмотрим все вершины, смежные с вершиной Va, так-
же не принадлежащие уровням 0,1,2,..., г, и также назначим этим вершинам уровень
(г + 1). Будем продолжать этот процесс до тех пор, пока не переберем все вершины.
Проиллюстрируем этот процесс на примере, а затем рассмотрим алгоритм. Пример
поиска связного дерева для графа, показанного на рис. 14.1, а, представлен на рис. 14.5
(для простоты под каждым графом перечисляются только вершины дерева, без ребер).
Дерево включает вершины {1, 2, 3}
Дерево включает вершины {1, 2, 3, 4}
Дерево включает вершины {1.2, 3, 4, 5}
Рис. 14.5. Поиск в ширину вершин графа, представленного на рис. 14.1
Дерево включает вершины {1, 2, 3, 4, 5, 6}
' Не надейтесь, что это сокращение вам не понадобится. Мне известна по меньшей мере одна статья,
в которой это coKpauieinie применяется без расшифровки. Теперь вы знаете, что оно означает.
14.1. Элементарные понятий теории графов
459
Сначала следует выбрать порядок, в котором будут перебираться вершины графа.
Мы будем перебирать вершины по порядку их номеров: У, У2, У, V4, У5, У6. Затем
выберем из них первую вершину и пометим ее как корень дерева. Пусть сначала
дерево состоит из этой единственной вершины У и не имеет ребер. Затем добавим
к дереву все ребра ( У, х) и все вершины х, инцидентные этим ребрам. Таким обра-
зом, на первом этапе мы добавим к дереву ребра (У, У2), (У, У3), (У1( V4) и верши-
ны У, У, У- Добавленные на первом шаге элементы образуют первый уровень. На
каждом шаге добавляются только еще не входящие в дерево вершины графа и со-
ответствующие ребра. Таким образом гарантируется отсутствие в создаваемом
дереве циклов.
Повторим эту процедуру для всех вершин уровня 1, рассматривая все верши-
ны по очереди и добавляя их к дереву:
У : ничего,
У 3: ребра (У, Уз), (У, У) и вершины У5, У,
У : ничего.
К этому моменту к дереву оказываются добавленными все вершины графа.
В противном случае процедура бы повторялась с вершинами уровня 3 и так далее
до тех пор, пока к дереву не будут добавлены все вершины графа.
На рис. 14.5 каждая добавляемая к дереву вершина изображается черным цве-
том, а каждое добавляемое ребро — серым цветом. Перебираемые новые вершины
изображаются серым цветом. Серые вершины образуют своего рода границу меж-
ду деревом и остальным графом, являясь кандидатами на добавление. По завер-
шении работы алгоритма затененные ребра образуют связующее дерево.
Вот более формальное определение алгоритма BFS. На входе алгоритма мы
имеем связный граф G с пронумерованными вершинами У, У,..., Ул-, а на выходе
получаем связующее дерево. В алгоритме используется временное множество
вершин 5.
1. Инициализация. Множеству 5 присваивается значение {У}, а дерево пред-
ставляет собой граф, состоящий из вершины У и не имеющий ребер. Вер-
шина У назначается вершиной дерева.
2. Добавление ребер. Обрабатываются вершины множества 5 по порядку. Для
каждой вершины х из множества .S' обрабатывается каждая смежная верши-
на у из множества 5 по порядку. Затем к дереву добавляется ребро (х, г/),
а также вершина у при условии, что при этом в дереве не возникнет цикла.
Если на этом шаге к дереву не добавлено ни одного ребра, работа алгоритма
останавливается и результатом становится связующее дерево.
3. Обновление множества S. Вершины, образующие множество 5, заменяются
дочерними вершинами из дерева. Затем возвращаемся к шагу 2.
Результатом работы этого алгоритма является связующее дерево с корнем в
вершине У. Побочный эффект алгоритма поиска в ширину заключается в том, что
он находит расстояние с кратчайшим путем от данной вершины до всех осталь-
ных вершин. Расстояние с кратчайшим путем (shortest-path distance) 8(s, и) меж-
ду вершинами хин представляет собой минимальное количество ребер в любом
пути от х до о. Формальное доказательство этого утверждения довольно длинное,
460
Глава 14. Теория графов и поиск путей с минимальной стоимостью
и интересующийся читатель может найти его в [60] (полное доказательство зани-
мает три больших страницы). Но интуитивно понятный аргумент сформулировать
нетрудно. Начнем с вершины г графа G и построим при помощи алгоритма поиска
в ширину связующее дерево. Все вершины, смежные с вершиной г, становятся ча-
стью дерева на уровне 1. Ясно, что вершины этой части дерева обладают свойством
заключающимся в том, что дерево определяет кратчайший путь от каждой верши-’
ны уровня 1 до вершины г (корня дерева). 'Генерь рассмотрим вершину х на уров-
не 2 дерева. В дереве вершина х связана с вершиной г путем длины 2. Может ли в
графе G существовать более короткий путь от корня дерева до вершины х? Нет
так как это бы значило, что в графе G существует путь длины 1 от вершины х до
вершины г, то есть то, что эти вершины смежные.
Теперь зададим противоположный вопрос. В дереве на расстоянии 2 от верши-
ны г располагаются только вершины уровня 2. Возможно ли, что в графе G суще-
ствует некоторая вершина у, расположенная на уровне дерева с номером более 2,
но для которой существует путь до корня дерева (вершины г) длины 1 или 2? Дру-
гими словами, не пропустили ли мы какую-либо вершину графа к моменту фор-
мирования уровня 2 в дереве? Опять мы получим отрицательный ответ. Если бы
в графе G существовал путь длиной 1 от вершины г до вершины у, тогда вершина у
была бы смежной с вершиной г и потому была бы включена в уровень 1. Если бы
в графе G существовал от вершины гдо вершины у путь длиной 2, тогда вершина у
была бы смежной с вершиной первого уровня дерева и, следовательно, была бы
включена в уровень 2.
Используя такую цепочку рассуждений, можно показать, что в общем случае
на любом уровне i в дерево включаются все вершины, которые находятся на
расстоянии i от корня дерева.
Произведем оценку времени работы алгоритма поиска в ширину. После ини-
циализации каждая вершина помещается в множество 5 ровно один раз, а следо-
вательно, и удаляется из множества S ровно один раз. Таким образом, суммарное
время, затрачиваемое на операции с множеством 5, пропорционально количеству
вершин |V] (порядку графа). При обработке вершины перебираются все ее смеж-
ные вершины, то есть все ее ребра. Ребро, ведущее к вершине, уже принадлежащей
дереву, отбрасывается алгоритмом. В противном случае алгоритм должен решить,
создается ли при включении ребра цикл. Таким образом, основная обработка каж-
дого ребра производится только один раз, поэтому суммарное время обработки
ребер пропорционально числу ребер |Е| (размеру графа). Итак, мы можем заклю-
чить, что время работы алгоритма поиска в ширину линейно зависит от количе-
ства вершин | V) и числа ребер |Е|.
14.2. Поиск кратчайшего пути
Сеть с коммутацией пакетов (или сеть ретрансляции кадров, или сеть ATM) мож-
но рассматривать как ориентированный граф, в котором каждая вершина соответ-
ствует узлу коммутации пакетов, а линии связи между узлами соответствует пара
параллельных ребер, по каждому из которых данные передаются в одном направ-
лении. В такой сети для передачи пакета от узла-источника узлу-получателю по
14.2. Поиск кратчайшего пути
461
разным линиям через несколько коммутаторов пакетов требуется принять реше-
ние о выборе маршрута. Эта задача эквивалентна поиску пути в графе.
Для объединенной сети, такой как Интернет или интранет, представление ее
в виде ориентированного графа также является приемлемым. В этом случае каждой
вершине соответствует маршрутизатор. Если два маршрутизатора напрямую
присоединены к одной и той же локальной или глобальной сети, тогда это двусто-
роннее соединение соответствует паре параллельных ребер, соединяющих соответ-
ствующие вершины. Если к сети напрямую присоединены более двух маршрути-
заторов, тогда эта сеть представляется в виде множества пар параллельных ребер,
каждая из которых соединяет два маршрутизатора. В объединенной сети для пе-
редачи IP-дейтаграммы от маршрутизатора-источника к маршрутизатору-прием-
нику по разным линиям через разные сети и маршрутизаторы пакетов требует-
ся принять решение о выборе маршрута. Эта задача также эквивалентна поиску
пути в графе.
Практически во всех сетях с коммутацией пакетов и во всех объединенных се-
тях решение о выборе маршрута принимается на основе одной из разновидностей
критерия минимальной стоимости. Если выбирается маршрут с минимальным
количеством ретрансляционных участков (хопов), тогда каждому ребру, соответ-
ствующему ретрансляционному участку, назначается единичный вес. Эта задача
соответствует поиску кратчайшего пути в обычном (не взвешенном) графе. Но
чаще всего каждому ретрансляционному участку в соответствие ставится опреде-
ленная величина, называемая стоимостью (cost) передачи. Эта величина может
быть обратно пропорциональной пропускной способности линии, прямо пропор-
циональной текущей нагрузке на эту линию или представлять собой некую ком-
бинацию подобных параметров. При расчете стоимости могут учитываться также
такие критерии, как финансовая стоимость использования ретрансляционного
участка. В любом случае, стоимости использования ретрансляционных участков
являются входными данными для алгоритма поиска пути с минимальной стоимо-
стью, который может быть сформулирован следующим образом.
Пусть имеется сеть, состоящая из узлов, соединенных двунаправленными ли-
ниями связи, и каждой линии поставлена в соответствие стоимость пересылки дан-
ных в каждом направлении. Стоимость пути между двумя узлами определяется
как сумма стоимостей всех линий, входящих в данный путь. Задача состоит в том,
чтобы найти путь с наименьшей стоимостью для каждой пары узлов.
Обратите внимание на то, что стоимость использования ретрансляционного
участка может быть разной в разных направлениях. Например, это справедливо
в случае, если стоимость использования ретрансляционного участка пропорцио-
нальна длине очереди дейтаграмм, ждущих передачи. В теории графов задаче на-
хождения пути с наименьшей стоимостью соответствует задача поиска пути с наи-
меньшей длиной во взвешенном ориентированном графе.
Большинство алгоритмов поиска маршрута с наименьшей стоимостью, приме-
няющихся в сетях с коммутацией пакетов и объединенных сетях, представляют
собой вариации одного из двух общих алгоритмов, известных как алгоритм Дейк-
стры (Dijkstra) и алгоритм Веллмана — Форда (Bellman — Ford). В этом разделе
обсуждаются оба алгоритма.
462
Глава 14, Теория графов и поиск путей с минимальной стоимостью
Алгоритм Дейкстры
Алгоритм Дейкстры [71 ] может быть сформулирован следующим образом. Алгоритм
находит кратчайшие пути от данной вершины-источника до всех остальных вершин
перебирая пути в порядке увеличения их длин. Работа алгоритма проходит поэтапно
К /г-му шагу алгоритм находит k кратчайших (с наименьшей стоимостью) путей к k
вершинам, ближайшим к вершине-источнику. Эти вершины образуют множе-
ство Т. На шаге (k + 1) к множеству Т добавляется вершина, ближайшая к вершине-
источнику среди вершин, не входящих во множество Т. При добавлении каждой
новой вершины к множеству Топределяется путь к ней от источника. Формально
этот алгоритм может быть определен следующим образом. Введем обозначения:
4- А — множество вершин сети;
4- s — вершина-источник;
4- Т — множество вершин, уже обработанных алгоритмом;
4- Дерево — связующее дерево для вершин, принадлежащих множеству Т, вклю-
чая ребра, входящие в пути с наименьшей стоимостью от вершины s до каж-
дой вершины множества Г;
4- w(i,j) — стоимость линии от вершины г до вершины j, причем w(i, i) = 0 или
ro(i,j) = °°, если две вершины не соединены напрямую, и w(i, j) > 0, если две
вершины соединены напрямую;
4> L(ri) — минимальная стоимость пути от вершины s до вершины п, известно-
го на данный момент алгоритму (по завершении работы алгоритма это ми-
нимальная стоимость пути от вершины s до вершины п).
Алгоритм состоит из трех шагов. Шаги 2 и 3 повторяются до тех пор, пока
множество Тне совпадет с множеством N. Это значит, что шаги 2 и 3 повторяются,
пока для всех вершин сети не будут найдены окончательные пути.
1. Инициализация.
Т=Дерево = {s},
то есть множество исследованных вершин состоит пока что только из вер-
шины-источника.
£(п) = w(s, ri) для п * s,
то есть стоимости начальных путей к соседним вершинам представляют со-
бой просто стоимости линий связи.
2. Получить следующую вершину. Найти следующую вершину, не принадле-
жащую множеству Ти имеющую путь от вершины 5 с минимальной стоимо-
стью, и включить эту вершину во множество Г и в Дерево. Кроме того, к де-
реву добавляется ребро, инцидентное этой вершине и вершине множества Т,
входящей в путь с минимальной стоимостью. Это может быть сформулиро-
вано следующим образом. Найти вершину х g Т такую, что
£(х) = min Z(j).
yeT
Добавить вершину х к множеству Гик дереву; добавить к дереву ребро, ин-
цидентное вершине х, составляющее компонент пути L(x) с минимальной
стоимостью, то есть последний ретрансляционный участок пути.
14.2. Поиск кратчайшего пути
463
3. Обновить путь с минимальной стоимостью.
L(n) ~ шт[£(н), L(x) + w(x, n)] для всех n g T.
Если последняя величина минимальна, то с этого момента путь от вершины s
до вершины п представляет собой конкатенацию пути от вершины $ до вер-
шины х и пути от вершины х до вершины п.
Алгоритм завершает работу, когда все вершины добавлены к множеству Т. Таким
образом, для работы алгоритма требуется |Е| итераций. К моменту окончания ра-
боты алгоритма значение £(х), поставленное в соответствие каждой вершине х,
представляет собой минимальную стоимость (длину) пути от вершины s до верши-
ны х. Кроме того, Дерево представляет собой связующее дерево исходного ориен-
тированного графа, определяющее пути с минимальной стоимостью от вершины s
до всех остальных вершин.
На каждой итерации при выполнении шагов 2 и 3 к множеству Тдобавляет-
ся одна новая вершина, а также находится путь с минимальной стоимостью от
вершины s до этой вершины. Другими словами, на каждой итерации к множеству Т
добавляется вершина х, а значение £(л) на этот момент времени представляет
собой минимальную стоимость пути от вершины s до вершины х. Более того, путь
с минимальной стоимостью определяется уникальным путем от вершины s до
вершины х во множестве Т. Этот путь проходит только по вершинам, принадлежа-
щим множес ч'ву Т. Чтобы понять это, рассмотрим следующую цепочку рассуждений.
Вершина х, добавляемая на первой итерации, должна быть смежной с вершиной s,
и не должно существовать другого пути к вершине х с меньшей стоимостью. Если
вершина х не является смежной с вершиной s, тогда должна существовать другая
вершина, смежная с вершиной s, представляющая собой первый транзитный учас-
ток пути с минимальной стоимостью к вершине х. В этом случае при выборе вер-
шины, добавляемой к множеству Т, предпочтение будет отдано этой вершине, а не
вершине х. Если вершина х является смежной с вершиной s, но путь s—х не явля-
ется путем с наименьшей стоимостью от вершины s до вершины х, то это значит,
что существует другая смежная с вершиной s вершина у, находящаяся на пути с
минимальной стоимостью, и при выборе добавляемой к множеству Т вершины
предпочтение будет отдано вершине у, а не вершине х. После выполнения k итераций
во множество Т войдут k вершин и будет найден путь с минимальной стоимостью
от вершины 5 до каждой из этих вершин. Теперь рассмотрим все возможные пути
от вершины 5 до вершин, не входящих в множество Т. Среди этих путей существует
один путь с минимальной стоимостью, проходящий исключительно по вершинам,
принадлежащим множеству Т (см. задание 9), заканчивающийся линией, непос-
редственно связывающей некую вершину множества Т с вершиной, не принадле-
жащей множеству Т. Эта вершина добавляется к множеству Т, а соответствующий
путь считается путем с наименьшей стоимостью к данной вершине.
В табл. 14.2 и на рис. 14.6 показан результат применения данного алгоритма к
графу, представленному на рис. 14.2, а. В данном случае в качестве вершины s вы-
бирается вершина Е(. Затененные ребра показывают связующее дерево для этого
графа. Значения в каждой окружности представляют собой текущие оценки величи-
ны £(л) для каждой вершины х. Вершина затеняется при добавлении к множеству 7•
Обратите внимание на то, что на каждом шаге генерируется путь до каждой вер-
шины и вычисляется суммарная стоимость этого пути. После последней итерации
464 Глава 14. Теория графов и поиск путей с минимальной стоимостью
находится путь с минимальной стоимостью до каждой вершины и вычисляется
стоимость такого пути. Та же процедура может быть применена к вершине V2 и т д
Таблица 14.2. Пример работы алгоритма выбора маршрута с минимальной
стоимостью по Дейкстре (s = 1) для графа, показанного на рис. 14.2
Итера- Т ция 1(2) Путь L(3) Путь 1(4) Путь L(5) Путь 1(6) Путь
1 {1} 2 1-2 5 1-3 1 1—4 оо — ОО
2 {1,4} 2 1-2 4 1—4—3 1 1—4 2 1-4—5 оо —
3 {1.2, 4} 2 1—2 4 1—4—3 1 1-4 2 1—4—5 оо —
4 {1.2.4, 5} 2 1-2 3 1 —4—5—3 1 1-4 2 1—4—5 4 1-4-5-6
5 {1,2, 3,4, 5} 2 1-2 3 1-4-5—3 1 1—4 2 1—4—5 4 1-4-5-6
6 {1,2, 3,4, 5, 6} 2 1—2 3 1—4—5-3 1 1-4 2 1—4—5 4 1-4-5-6
Т={1,2, 3, 4,5}
Т={1.4}
Т={1,2, 3, 4, 5, 6}
Рис. 14.6. Применение алгоритма Дейкстры к графу, представленному на рис. 14.2
14.2. Поиск кратчайшего пути
465
Можно показать [60], что время работы алгоритма Дейкстры пропорциональ-
но |V]2. Чтобы почувствовать это интуитивно, обратите внимание на то, что алгоритм
выполняет |Е| - 1 итерацию, а количество операций, выполняемых на каждой ите-
рации, пропорционально | Е|.
Алгоритм Беллмана — Форда
Алгоритм Беллмана — Форда [86] может быть сформулирован следующим образом.
Требуется найти кратчайшие пути от заданной вершины при условии, что эти пути
состоят максимум из одного ребра, затем найти кратчайшие пути при условии, что эти
пути состоят максимум из двух ребер, и т. д. Этот алгоритм также работает поэтапно.
Формально он может быть определен следующим образом. Введем обозначения:
♦ s — вершина-источник;
♦ w(i,j) — стоимость линии от вершины г до вершины/ причем w(i, г) = 0 или
w(i, j) = «>, если две вершины не соединены напрямую, и w(i,j) > 0, если две
вершины соединены напрямую;
+ /? — максимальное количество ребер в пути на текущем шаге алгоритма;
♦ Ц{п) — минимальная стоимость пути от вершины s до вершины п при усло-
вии, что этот путь состоит не более чем из Л ребер.
Алгоритм состоит двух шагов. Шаг 2 повторяется до тех пор, пока стоимости
путей не перестанут изменяться.
1. Инициализация:
L0(n) = °° для всех n*s,
Lh(s) = 0 для всех h.
2. Обновление. Для каждого последовательного h > 0 и для каждого n^s вычислить
Д|+1 (и) - min[4(/) + w(j, n)].
Соединить вершину п с предыдущей вершиной), для которой находится
минимальное значение, и удалить любое соединение вершины п с предыду-
щей вершиной, образованное на более ранней итерации. Путь от вершины s
до вершины п заканчивается линией связи от вершины j до вершины п.
При h = К для каждой вершины-получателя п алгоритм сравнивает потенциальный
путь от вершины s до вершины п длиной К + 1 с путем, существовавшим к концу пре-
дыдущей итерации. Если предыдущий более короткий путь обладает меньшей сто-
имостью, то он сохраняется. В противном случае сохраняется новый путь от вер-
шины s до вершины п длиной К + 1. Этот путь состоит из пути длиной К от вершины
s до некоей вершины j и прямого участка от вершины) до вершины п. В этом случае
используемый путь от вершины s до вершины) представляет собой путь, состоящий
из К ретрансляционных участков, найденный на предыдущей итерации (см. зада-
ние 10). По завершении работы алгоритма вычисляется связующее дерево графа.
В табл. 14.3 и на рис. 14.7 показан результат применения этого алгоритма к гра-
фу, представленному па рис. 14.2, а, в котором в качестве вершины s выбирается
вершина 1). На каждом шаге алгоритм находит путь с минимальной стоимостью,
максимальное число ретрансляционных участков в котором равно h. После послед-
466
Глава 14. Теория графов и поиск путей с минимальной стоимостью
ней итерации алгоритм находит путь с минимальной стоимостью к каждой вер-
шине, а также вычисляется стоимость этого пути. Та же процедура может быть
применена к вершине У2 и т. д. Обратите внимание на то, что результаты работы
алгоритмов Дейкстры и Веллмана — Форда совпадают.
Таблица 14.3. Пример работы алгоритма выбора маршрута с минимальной сто-
имостью по Веллману — Форду (s = 1) для графа, показанного на рис. 14.2
h Ь(2) Путь М3) Путь 4(4) Путь 1Д5) Путь М(6) Путь
0 со — со — СО — СО — со —
1 2 1—2 5 1—3 1 1—4 со — ©о —
2 2 1—2 4 1—4—3 1 1—4 2 1-4-5 10 1—3—6
3 2 1—2 3 1—4—5—3 1 1—4 2 1—4—5 4 1-4—5-6
4 2 1—2 3 1-4-5-3 1 1—4 2 1—4—5 4 1—4—5—6
/7=3
Рис. 14.7. Применение алгоритма Веллмана — Форда к графу, представленному на рис. 14.2
/7 = 4
Можно показать [60], что время работы алгоритма Веллмана — Форда пропор-
ционально | V] х |£|. Чтобы почувствовать это интуитивно, обратите внимание на то,
что алгоритм выполняет | V| — 1 итерацию, а каждая итерация включает определе-
ние веса каждого ребра.
Сравнение алгоритмов
Интересно сравнить эти два алгоритма в плане информации, собираемой ими. Рас-
смотрим сначала алгоритм Веллмана — Форда. При рассмотрении вершины п тре-
14.4. Задания
467
буется знание стоимости использования линий, связывающей рассматриваемую
вершину со всеми соседними вершинами, то есть w(j, и), а также суммарную стоимость
пути к каждой из этих вершин от вершины-источника s, то есть Lh(j). Каждая вер-
шина может хранить информацию о путях к другим вершинам сети и стоимости
этих путей, а также время от времени обмениваться этой информацией со своими
непосредственными соседями. Таким образом, для обновления данных о путях и
их стоимостях каждая вершина может применять формулу из шага 2 алгоритма
Веллмана — Форда, используя информацию, полученную от своих соседей, и све-
дения о стоимости линий связи. С другой стороны, рассмотрим алгоритм Дейкст-
ры. На шаге 3 каждая вершина должна обладать полной информацией о топологии
сети. Это значит, что каждая вершина должна знать стоимость всех линий в сети.
В общем, для сравнения достоинств обоих алгоритмов следует учесть время
работы каждого алгоритма и объем информации, которую потребуется собрать у
других узлов обычной или объединенной сети. Также значение имеет выбранный
вариант реализации алгоритма.
И последнее. Известно, что оба алгоритма приводят к одному и тому же резуль-
тату при условии неизменности топологии и стоимости линий. Если стоимость
линий меняется со временем, алгоритм попытается приноровиться к этим изме-
нениям. Но если стоимость линий зависит от трафика, который, в свою очередь,
зависит от выбираемых маршрутов, тогда возникает обратная связь, которая мо-
жет привести к неустойчивой работе алгоритма.
14.3. Рекомендуемая литература
Превосходное элементарное введение в теорию графов можно найти в [170] и [45].
В обеих книгах содержатся многочисленные задачи и решения, что делает их при-
годными для самостоятельного изучения. Более полное описание теории графов с
детальным анализом связующих деревьев и алгоритмов поиска кратчайшего пути
содержится в [105].
В [60] имеется детальное описание алгоритмов перебора графов, включая де-
тальный анализ алгоритмов поиска кратчайших путей, обсуждавшихся в данной
главе. В [28] также подробно обсуждаются эти алгоритмы.
14.4. Задания
1. Граф К„, называемый полным графом, состоит из н вершин, каждая из кото-
рых напрямую соединяется ребрами со всеми остальными вершинами гра
фа. Выведите формулу для вычисления количества ребер в графе К„.
2. Рассмотрим граф с множеством вершин V = {a, b,c,d,e,f}nE = {(a, b), (a, d),
(b, с), (Ь, е), (с, е), (с,/), (d, е), (e,f)}.
а) начертите этот граф;
б) найдите все пути от вершины а до вершины Ь;
в) чему равна длина кратчайшего пути от вершины а до вершины /?
468
Глава 14. Теория графов и поиск путей с минимальной стоимостью
3. Найдите все связующие деревья для следующего графа:
4. Ребро графа G входит во все связующие деревья графа G. Что можно ска-
зать об этом ребре?
5. Докажите правильность алгоритма поиска в ширину. То есть покажите, что
этот алгоритм создает связующее дерево с корнем в вершине Vi.
6. Напишите алгоритм поиска в ширину, проверяющий связность графа.
7. В стиле рис. 14.5 проиллюстрируйте выполнение алгоритма поиска в шири-
ну на примере графа, представленного на рис. 14.8.
Рис. 14.8. Граф для задания?
8. Алгоритм Дейкстры для поиска пути с минимальной стоимостью от верши-
ны s может быть выражен в виде показанной ниже программы. В этой про-
грамме вначале каждой вершине присваивается временная метка. Когда алго-
ритм находит окончательный путь к вершине, ей присваивается постоянная
метка, равная стоимости пути от вершины s. Напишите подобную програм-
му для алгоритма Веллмана — Форда. Подсказка: алгоритм Веллмана-Фор-
да часто называется алгоритмом коррекции меток, в отличие от метода ус-
тановки меток Дейкстры.
for n := 1 to N do
begin
L[n] := finalln] := false:
{все вершины временно помечаются •*>}
pred[n] := 1
end:
L[s] : = 0; finalIs] := true: {вершина s временно помечается 0}
recent := s: {последняя временно помеченная вершина - это s}
path := true;
{инициализация закончена}
while finallt] = false do
begin
for In] :=1 to N do {найти новую метку}
if (wtrecent. n]< »=) AND (NOT final EnJ) then
14.4. Задания
469
{цикл по всем еще не помеченным вершинам, непосредственно следующим
за вершиной recent}
begin {обновить временные метки}
newlabel := L[recent] + w[recent.n];
if newlabel <L[n] tnen
begin L[n] = newlabel; pred[n] : = recent end
{если существует более короткий путь через вершину recent,
пометить вершину п заново, и пометить вершину recent как
предшествующую вершине п на кратчайшем пути от веошины s}
end;
temp := »:
for х := 1 to N do {найти вершину с наименьшей временной меткой}
if (NOT final[х]) AND (L(x) < temp) then
begin у := x; temp := L[x] end;
if temp < °° then {путь существует} then
begin final[y] := true; recent := у end
{временно помечается вершина у. следующая ближайшая вершина к вершине s}
else begin path ;= false; final[t] := true end
end
9. При обсуждении алгоритма Дейкстры утверждалось, что на каждой итера-
ции к множеству Тдобавляется новая вершина и что путь с наименьшей сто-
имостью проходит только через вершины, уже принадлежащие множеству Т.
Докажите справедливость этого утверждения. Подсказка: начните с начала.
Покажите, что первая вершина, добавленная к множеству Т, должна быть
связана с вершиной-источником напрямую. Затем покажите, что вторая
добавленная к множеству Твершина должна быть связана напрямую либо
с вершиной-источником, либо с вершиной, уже добавленной к множеству Т,
и т. д. Помните, что все стоимости линий являются неотрицательными
величинами.
10. При обсуждении алгоритма Веллмана — Форда утверждалось, что на итера-
ции, при которой h = K, если определяется путь длиной в К + 1 ребер, тогда
первые К ребер этого пути образуют путь, уже определенный на предыду-
щей итерации. Докажите справедливость этого утверждения.
11. На шаге 3 алгоритма Дейкстры значения путей с наименьшей стоимостью
обновляются только для вершин, еще не принадлежащих множеству Т. Воз-
можно ли, что может быть найден путь с меньшей стоимостью к вершине,
уже принадлежащей множеству Т? Если да, покажите это на примере. Если
нет, докажите невозможность такого события.
12. С помощью алгоритма Дейкстры создайте путь с минимальной стоимостью
ко всем остальным вершинам от вершин со 2-й по 6-ю на рис. 14.2. Оформи-
те результаты в таблице аналогично табл. 14.2.
13. Повторите задачу 12, используя алгоритм Веллмана — Форда и оформив
результаты в таблице аналогично табл. 14.3.
14. Примените алгоритм выбора маршрута Дейкстры к графам, представлен-
ным на рис. 14.9. Изображенные на рисунке веса ребер одинаковы в обоих
направлениях. Сформируйте таблицу, аналогичную табл. 14.2, и рисунок,
аналогичный рис. 14.6.
470
Глава 14. Теория графов и поиск путей с минимальной стоимостью
15. Повторите задачу 14, используя алгоритм Веллмана — Форда, оформив ре-
зультаты в таблице, аналогичной табл. 14.3, и в виде рисунка, аналогичного
рис. 14.7.
16. Всегда ли алгоритмы Дейкстры и Веллмана — Форда приводят к одинако-
вым результатам? Почему да или почему нет?
17. Как алгоритм Дейкстры, так и алгоритм Веллмана — Форда находят пути с
наименьшей стоимостью от одной вершины ко всем остальным вершинам.
Алгоритм Флойда — Уоршэлла (Floyd — Warshall) находит пути с наимень-
шей стоимостью между всеми парами вершин графа. Введем обозначения:
♦ N— множество вершин сети;
* №(г,у) — стоимость линии от вершины i до вершины j, причем w(i, i) = О
или = °°, если две вершины не соединены напрямую;
♦ L„(i,f) — стоимость пути с минимальной стоимостью от вершины i до
вершины j при условии, что путь может проходить только по верши-
нам 1, 2,..., п.
Алгоритм состоит из следующих шагов:
1. Инициализация:
= w (i,j) для всех i,j, i # j.
2. Для п = 0,1,..., N- 1
= min [L„(i, j), Ln(i, n + 1) + Ln(n + 1, j)] для всех г, j, i # j.
Объясните работу этого алгоритма. Используйте метод математической ин-
дукции для доказательства его работоспособности.
Глава 15
Протоколы внутренней
маршрутизации
Она изучала схему напротив, так как знала, что в опреде-
ленной точке ей придется пересесть на другой поезд. Такой
точкой должна была быть станция Тотепхэм Корт Роуд,
пересечение черной линии с красной. Поезд обязательно
доставит ее туда, он и сейчас быстро несет ее туда, а на стан-
ции она будет следовать указателям на Сентрал Лайн, по-
тому что там должны быть указатели.
Барбара Байн (Рут Ренделл). Ковер царя Соломона
Протоколы маршрутизации представляют собой существенную составную часть
механизмов обеспечения деятельности объединенных сетей. В основе работы
объединенных сетей лежат маршрутизаторы, переправляющие друг другу IP-дей-
таграммы по пути от хоста-источника к хосту-приемнику. Для выполнения сво-
их функций маршрутизатор должен обладать представлением о топологии объ-
единенной сети и способностью выбирать оптимальные маршруты. Назначение
протокола маршрутизации заключается в предоставлении необходимой инфор-
мации.
Мы начнем эту главу с обсуждения основных принципов маршрутизации в объ-
единенных сетях, включая вопросы маршрутизации в высокоскоростных сетях.
Затем мы рассмотрим два важных протокола маршрутизации, RIP и OSPF, оли-
цетворяющие два разных подхода к сбору информации о маршрутах.
15.1. Принципы маршрутизации
в объединенных сетях
Маршрутизация представляет собой один из наиболее сложных и критически важ-
ных аспектов разработки объединенных сетей. Этот раздел начинается с обсужде-
ния механизма маршрутизации. Затем мы рассмотрим общую архитектуру марш-
рутизации в объединенных сетях.
472
Глава 15. Протоколы внутренней маршрутизации
Функция маршрутизации
Маршрутизаторы в объединенной сети выполняют почти ту же самую функцию
что и узлы коммутации пакетов в сети с коммутацией пакетов. Так же как узел ком-
мутации пакетов ответственен за получение и дальнейшую пересылку пакетов по
сети с коммутацией пакетов, маршрутизатор отвечает за получение и пересылку
IP-дейтаграмм через объединенную сеть. Для этого маршрутизаторам объединен-
ной сети нужно принимать решения о выборе маршрутов, основываясь на знании
топологии и состояния объединенной сети.
Как упоминалось в главе 14, решения о выборе маршрутов принимаются на
основе некоторого критерия минимальной стоимости. Если этот критерий заклю-
чается в минимизации количества ретрансляционных участков, тогда каждому
ретрансляционному участку (ребру графа) назначается вес, равный единице. Чаще
каждому ретрансляционному участку в соответствие ставится определенная ве-
личина, называемая стоимостью. Стоимость может быть обратно пропорциональ-
на пропускной способности линии, прямо пропорциональна текущей нагрузке на
линию или представлять собой какую-либо комбинацию подобных параметров.
При расчете стоимости могут учитываться также такие критерии, как финансовая
стоимость использования ретрансляционного участка. В любом случае, подобно-
го рода стоимостные критерии являются входными данными для алгоритма поис-
ка пути с минимальной стоимостью. Два таких алгоритма описывались в главе 14.
Фиксированная маршрутизация
В простой конфигурации сети возможно использование фиксированной схемы
маршрутизации, в которой для каждой пары узлов определяется постоянный мар-
шрут. Эти маршруты являются фиксированными, поскольку изменяются только
при изменении топологии сети. Таким образом, значения стоимости линий при
прокладке маршрутов не могут основываться на каких-либо динамических пере-
менных, таких как объем трафика. Однако для их вычисления могут использовать-
ся оценки объемов трафика между различными парами узлов или пропускная спо-
собность каждой линии.
Рассмотрим конфигурацию, представленную на рис. 15.1 и состоящую из пяти
сетей и восьми маршрутизаторов. Каждой выходной линии маршрутизатора по-
ставлена в соответствие ее стоимость. При фиксированной схеме маршрутизации
эта стоимость может отражать ожидаемую нагрузку на линию между данным мар-
шрутизатором и данной сетью. На рис. 15.2 показан пример реализации схемы
фиксированной маршрутизации. Каждый маршрутизатор храпит таблицу, в кото-
рой есть запись для каждой сети конфигурации. Хранить в таблице записи для
каждого возможного хоста-получателя нет необходимости. Для маршрутизации
достаточно хранить сведения о сетях. Когда IP-дейтаграмма достигает марш-
рутизатора, соединенного с сетью получателя, этот маршрутизатор может дос-
тавить дейтаграмму соответствующему хосту-получателю в этой сети. К счас-
тью, IP-адрес, как правило, состоит из двух частей: номера сети и номера хоста
(см. рис. 3.3 в главе 3), так что номер сети получателя можно без труда извлечь из
1Р-дейтаграммы.
15.1. Принципы маршрутизации в объединенных сетях
473
Сеть 1
Сеть 3
Маршрутизатор А
3
Сеть 2
Сеть 4
Хост Y
Рис. 15.1. Конфигурация маршрутизаторов и сетей
Таблица маршрутизатора А
Сеть Маршрутизатор
1 D
2 D
3 D
4 —
5 F
Таблица маршрутизатора В
Сеть Маршрутизатор
1 —
2 —
3 G
4 D
5 G
Таблица маршрутизатора D
Сеть Маршрутизатор
Таблица маршрутизатора G
Сеть Маршрутизатор
1 В
2 —
3 —
4 D
5 Н
Таблица маршрутизатора Н
Сеть Маршрутизатор
1 С
2 G
3 —
4 G
5 —
Таблица маршрутизатора С
Сеть Маршрутизатор
—
2 в
3 —
4 А
5 Н
Таблица маршрутизатора F
Сеть Маршрутизатор
Н
2 Н
3 Н
4 —
5 —
Таблица хоста X
Сеть Маршрутизатор
2 В
3 В
4 А
5 А
Рис. 15.2. Таблицы маршрутизации для рис. 15.1
474
Глава 15. Протоколы внутренней маршрутизации
Каждая запись в таблице маршрутизации идентифицирует целевую сеть и сле-
дующий маршрутизатор, которому следует направлять дейтаграммы для данного
получателя. Маршрутизатору не нужно хранить полную информацию о маршрутах
к каждому возможному получателю. Вместо этого ему достаточно уметь по адресу
получателя определять выходную линию, по которой передавать дейтаграмму.
Предположим, что маршрут с наименьшей стоимостью от маршрутизатора X до
маршрутизатора Y начинается с линии X—А. Назовем оставшуюся часть марш-
рута Ri. Это часть маршрута от А до Y. Пусть маршрут R2 представляет собой мар-
шрут с наименьшей стоимостью от А до Y. Если стоимость маршрута R, больше
стоимости маршрута Rs, тогда маршрут X—Y можно усовершенствовать, выбрав
участок R2. Если же стоимость маршрута Ri меньше стоимости маршрута R2, тог-
да маршрут R2 не является маршрутом с наименьшей стоимостью от А до Y. По-
этому Ri = R2. Таким образом, в каждой точке вдоль маршрута необходимо знать
только идентификатор следующего ретрансляционного участка, но не весь марш-
рут. В нашем примере маршрут от маршрутизатора F до сети 2 проходит через
маршрутизатор Н. Далее маршрут проходит через маршрутизатор G, напрямую
соединенный с сетью 2. Таким образом, полный маршрут от маршрутизатора F до
сети 2 выглядит как F—Н—G.
Подобная таблица маршрутизации необходима каждому маршрутизатору. Кро-
ме того, может потребоваться настроить таблицы маршрутизации на хостах. Если
хост присоединен только к одной сети, а к этой сети присоединен лишь один мар-
шрутизатор, тогда хосту не требуется таблица маршрутизации. Весь трафик, от-
правляемый за пределы сети, следует направлять единственному маршрутизато-
ру. Однако если к сети присоединено несколько маршрутизаторов, тогда у хоста
должна быть таблица, указывающая, какой маршрутизатор использовать для каж-
дого получателя, находящегося за пределами сети. Альтернатива состоит в том,
чтобы назначить маршрутизатор по умолчанию, но это решение не является опти-
мальным. На рис. 15.2 показана таблица маршрутизации для хоста X.
Адаптивная маршрутизация
Практически во всех конфигурациях объединенных сетей маршрутизаторами
применяется некая разновидность адаптивной маршрутизации. При адаптивной
маршрутизации, когда состояние объединенной сети меняется, могут меняться
и маршруты передачи дейтаграмм. Ниже перечислены основные условия, влияю-
щие на решение о выборе маршрута:
♦ Неисправность. Когда сеть или маршрутизатор выходит из строя, они уже
не могут быть частью маршрута.
♦ Перегрузка. Когда определенная часть объединенной сети оказывается пе-
регруженной, желательно направлять дейтаграммы в обход этого участка.
Таким образом, с тратегия маршрутизации может помочь избежать перегруз-
ки или, по меньшей мере, предотвратить разрастание перегрузки, что очень
важно в высокоскоростных объединенных сетях.
Адаптивная маршрутизация имеет определенные недостатки:
♦ Усложняется выбор маршрута, поэтому маршрутизаторы должны больше
времени тратить на обработку.
15.1. Принципы маршрутизации в объединенных сетях
475
♦ В большинстве случаев адаптивная стратегия зависит от информации о со-
стоянии сети, собранной в одном месте, но используемой в другом. Возни-
кает проблема компромисса между качеством этой информации и величиной
накладных расходов. Чем больше объем информации, которой обменива-
ются маршрутизаторы, и чем чаще они ею обмениваются, тем лучше будут
решения о выборе маршрутов, принимаемых каждым узлом. С другой сто-
роны, эта информация сама оказывает нагрузку на сети, вызывая снижение
производительности.
♦ Реакция адаптивной стратегии может оказаться слишком быстрой, что мо-
жет привести к осцилляциям, вызывающим перегрузку, или слишком мед-
ленной, то есть не поспевающей за изменениями.
♦ Применение адаптивной стратегии может привести к патологиям, таким как
флаттер и зацикливание.
Следует детально исследовать последние два пункта. Если адаптивная страте-
гия реагирует слишком быстро, то незначительные флуктуации нагрузки в объ-
единенной сети могут заставить многое маршрутизаторы перенаправить трафик
в менее нагруженные регионы. В результате в новом регионе объединенной сети
появляется всплеск трафика, что, в свою очередь, может вызвать перенаправление
трафика из этого региона обратно. Если же реакция адаптивной стратегии будет
слишком медленной, то к тому времени, когда будут приняты решения о выборе
маршрутов, распределение нагрузки может измениться настолько значительно, что
новые решения о выборе маршрутов окажутся непригодными.
Флаттером (fluttering) называют быструю циклическую смену маршрута. Это
явление может быть вызвано попыткой маршрутизатора распределить или сбалан-
сировать нагрузку. В RFC 1812 распределение нагрузки описывается следующим
образом1: «К концу работы процесса выбора следующего ретрансляционного участка
могут остаться несколько маршрутов. Маршрутизатор может выбрать более одного
маршрута и пытаться разделить трафик между ними». Подобное распределение
нагрузки может привести к ненормальному поведению сети. Пример, о котором
сообщается в [177], иллюстрирует рис. 15.3. В данном случае маршрутизатор в Сент-
Луисе, штат Миссури, распределяет свой трафик, направляемый в университет
Майнхайма (Германия), передавая часть данных через Вашингтон (жирная линия;
17 ретрансляционных участков до Майнхайма), а другую часть — через Анахайм,
штат Калифорния (пунктирная линия; 29 ретрансляционных участков). В результа-
те направляемые в университет в Майнхайме пакеты передаются по совершенно
неравноценным маршрутам. Опубликованное в [177] исследование состоит из наблю-
дений за трафиком Интернета на выбранных участках на протяжении нескольких
дней. За период наблюдений было замечено несколько случаев флаттера.
Хотя флаттер действительно обеспечивает балансирование нагрузки, он может
вызвать ряд проблем:
4- Если флаттер происходит только в одном направлении, характеристики мар-
шрута в разных направлениях будут разными. Такая ситуация может запу-
тать приложения, пытающиеся измерить характеристики маршрута в целях
управления и устранения неисправностей.
RFC 1812, Requirements for IP Version 4 Routers, июнь 1995.
476
Глава 15. Протоколы внутренней маршрутизации
Рис. 15.3. Пример флаттера: смена маршрутов передачи пакетов, посылаемых из
университета Сент-Луиса в университет Маннхайма
♦ При наличии двух разных маршрутов между отправителем и получателем
усложняется оценка таких характеристик, как время прохождения сигнала
в оба конца или пропускная способность.
♦ Если время распространения сигнала по двум маршрутам различается, ТСР-
пакеты будут прибывать с нарушением порядка, что может привести к не-
нужным повторным передачам, дублированию подтверждений и растрачи-
ванию пропускной способности впустую.
Более серьезной патологией является зацикливание (looping), при котором паке-
ты, переданные маршрутизатором, возвращаются на тот же маршрутизатор. Алгорит-
мы маршрутизации пытаются избежать зацикливания, но такое явление может
возникнуть, если в объединенной сети происходит изменение связности и информа-
ция об этом изменении не успевает распространиться по всем маршрутизаторам.
В [177] сообщается о наблюдениях за поведением объединенной сети, проводивших-
ся на протяжении трех суток. За этот период было замечено 60 случаев зацикли-
вания, причем несколько раз это явление длилось несколько часов, а в отдельных
случаях даже полдня. Очевидно, что подобные крайне устойчивые циркулирующие
потоки данных весьма негативно сказываются на трафике некоторых источников.
Несмотря на все присущие им недостатки, стратегии адаптивной маршрутизации
существенно преобладают над фиксированной маршрутизацией по двум причинам:
♦ Стратегия адаптивной маршрутизации может повысить производительность
для пользователя сети.
♦ Стратегия адаптивной маршрутизации может помочь в борьбе с перегрузкой.
Будут ли реализованы эти преимущества, зависит от грамотности проекта сети
и природы нагрузки. В целом, адаптивная маршрутизация представляет собой ис-
ключительно сложную и трудновыполнимую задачу. По этой причине уже много
лет протоколы маршрутизации постоянно совершенствуются.
15.1. Принципы маршрутизации в объединенных сетях
477
Обычно стратегии адаптивной маршрутизации классифицируются в зависимос-
ти от того, какие источники информации ими используются: локальные источники,
смежные узлы или все узлы. Примером стратегии адаптивной маршрутизации,
полагающейся только на локальную информацию, может служить отправка марш-
рутизатором каждой дейтаграммы в ту сеть, для которой у него минимальная дли-
на очереди Q. Таким образом, нагрузка на сети будет сбалансирована. Однако при
этом некоторые пакеты могут направляться в неверном направлении. Ситуацию
можно улучшить, если учитывать предпочтительные направления. В этом случае
каждая сеть, присоединенная к маршрутизатору, будет иметь смещение В, для каж-
дой сети-получателя г. Для каждой входящей дейтаграммы, направляющейся в сеть i,
маршрутизатор выбирает исходящую линию с минимальным значением Q + В,.
Таким образом, маршрутизатор будет стараться посылать дейтаграммы в правиль-
ном направлении, учитывая текущее значение задержки доставки трафика.
Адаптивные схемы, основанные только на локальной информации, использу-
ются редко. В таких схемах не учитывается информация от смежных и удаленных
маршрутизаторов. В стратегиях, основанных на информации, полученной от смеж-
ных или от всех маршрутизаторов, учитывается информация о задержках и не-
исправностях каждого маршрутизатора. С тратегии, основанные на информации,
полученной от смежных маршрутизаторов, называют алгоритмами с дистанцион-
но-векторной маршрутизацией (distance-vector routing). Стратегии, основанные на
информации, полученной от всех маршрутизаторов, называют алгоритмами мар-
шрутизации с учетом состояния линий (link-state routing). В любом случае для
обмена этой информацией требуется протокол маршрутизации.
И последнее. Реальный механизм маршрутизации не зависит от типа протоко-
ла маршрутизации, а также от того, используется какой-либо протокол маршру-
тизации или имеет место фиксированная стратегия маршрутизации. Обратите
внимание на рис. 15.1 ирис. 15.2, призванные проиллюстрировать фиксированную
маршрутизацию. Стоимость использования линий, изображенных на рис. 15.1,
может меняться динамически, отражая факт текущих задержек в соответствую-
щих интерфейсах. Таблицы маршрутизации, показанные на рис. 15.2, могут быть
построены на основе данных, предоставляемых протоколом маршрутизации, а не
сформированы заранее.
Автономные системы
Для продолжения обсуждения алгоритмов маршрутизации нам необходимо ввес-
ти понятие автономной системы. Автономная система (Autonomous System, AS)
имеет следующие характеристики:
♦ состоит из группы маршрутизаторов, обменивающихся информацией при
помощи общего протокола маршрутизации;
♦ представляет собой множество маршрутизаторов и сетей, управляемых един-
ственной организацией;
♦ обладает связностью (в смысле теории графов), за исключением случаев
неисправностей.
Распространенный протокол маршрутизации, который мы будем называть прото-
колом внутренней маршрутизации (Interior Routing Protocol, IRP), поддерживает
478
Глава 15. Протоколы внутренней маршрутизации
обмен информацией о маршрутах между маршрутизаторами в пределах автономной
системы. Используемый внутри автономной системы протокол не нужно реализовы-
вать за пределами автономной системы. Подобная гибкость позволяет разрабатывать
протоколы внутренней маршрутизации специально для конкретных приложений
Однако может случиться, что объединенная сеть будет сформирована из не-
скольких автономных систем. Так, все локальные сети на одной территории на-
пример в офисном комплексе или на территории университета, можно соединить
маршрутизаторами, образовав единую автономную систему. Эта система может
быть соединена с другими автономными системами с помощью глобальной сети.
Такая ситуация показана на рис. 15.4. В данном случае алгоритмы маршрутизации
и информация в таблицах маршрутизации, используемые маршрутизаторами (обо-
значены символом R) в разных автономных системах, могут быть разными. Тем
не менее маршрутизаторам в одной автономной системе требуется, по меньшей
мере, минимальный уровень информации о сетях за пределами системы. Прото-
кол, используемый для передачи маршрутной информации между маршрутизато-
рами из различных автономных систем, называется протоколом внешней марш-
рутизации (Exterior Routing Protocol, ERP)1.
Протокол внутренней маршрутизации ч------>
Протокол внешней маршрутизации ч---------►
Рис. 15.4. Применение протоколов внешней и внутренней маршрутизации
' В литературе термины протокол внутреннего шлюза (Interior Gateway Protocol, IGP) и протокол внеш-
него шлюза (Exterior Gateway Protocol, EGP) часто употребляют в том же контексте, что и протоколы
внешней и внутренней маршрутизации. Однако поскольку аббревиатуры IGP и EGP, так же как IRP
и ERP, относятся к вполне конкретным протоколам, мы будем избегать их использования при об-
суждении общих концепций.
/
15.2. Протокол RIP
479
Можно ожидать, что для протокола внешней маршрутизации потребуется пе-
редавать меньший объем информации, чем для протокола внутренней маршрути-
зации. Причина этого в следующем. Если дейтаграмма должна быть передана от
хоста в одной автономной системе хосту в другой автономной системе, марш-
рутизатор в первой системе должен определить только целевую автономную сис-
тему и рассчитать маршрут к ней. Как только дейтаграмма попадает в автономную
систему получателя, заниматься доставкой дейтаграммы начнут маршрутизаторы
автономной системы. Протокол внешней маршрутизации не интересуется такими
деталями, как маршрутизация в пределах автономной системы.
В оставшейся части этой главы мы рассмотрим, возможно, наиболее важные
примеры протоколов внутренней маршрутизации: RIP и OSPF. В главе 16 иссле-
дуются два важных протокола внешней маршрутизации: BGP и IDRP.
15.2. Протокол RIP
Протокол RIP (Routing Information Protocol — протокол маршрутной информа-
ции) представляет собой относительно простой протокол внутренней маршру-
тизации1. Несмотря на свою простоту, он вполне пригоден для небольших объ-
единенных сетей и остается одним из наиболее распространенных протоколов
маршрутизации.
Ключевая характеристика протокола RIP заключается в методе дистанционно-
векторной маршрутизации, который в нем применяется. Мы начнем с общего опи-
сания данного метода. Затем покажем, как этот метод адаптирован для использо-
вания в протоколе RIP. Наконец, мы определим формат RIP-пакета и обсудим
ограничения протокола RIP.
Дистанционно-векторная маршрутизация
Для дистанционно-векторной маршрутизации требуется, чтобы каждый узел (мар-
шрутизатор или хост, на котором реализован протокол RIP) обменивался инфор-
мацией с соседними узлами. Два узла называются соседними, если они напрямую
соединены с одной и той же сетью.
Алгоритм
Для работы протокола каждый узел хранит три вектора. Во-первых, в каждом узле
хранится вектор стоимости линий следующего вида:
ю(л', 1)
Wr =
w(x, М)
Определен в RFC 1058. Routing Information Protocol, июнь 1988. Существует более новая версия, изве-
стная как RIP-2, но она никогда не использовалась широко и в данной главе не обсуждается.
480
Глава 15. Протоколы внутренней маршрутизации
Здесь М представляет собой количество сетей, с которыми напрямую соединен
узел х. Стоимость линии ы(х, г) ассоциируется с выходом каждого узла для каждой
присоединенной сети i. Например, в конфигурации, показанной на рис. 15.1, перечис-
лены все стоимости линий. Хост X соединен только с одной сетью, и поэтому у него
есть только одно значение стоимости линий, равное 1. Маршрутизатор А соединен
с сетями 1 и 4. Значения стоимости его линий равны гт>(А, 1) = 7 и к>(А, 4) = 1.
Кроме вектора стоимостей линий, узлами поддерживаются еще два вектора:
L(x,N)
R(x,N)
(15.1)
Здесь:
♦ Lr — вектор расстояний для узла х;
♦ L(x,j) — текущая оценка минимальной задержки от узла х до сети у;
+ N — количество сетей в конфигурации;
♦ R, — вектор следующего ретрансляционного участка узла х;
4- R(x,j) — следующий маршрутизатор на текущем маршруте от узлах до сети у.
Периодически (каждые 30 секунд) каждый узел обменивается своим вектором
расстояний с соседями. На основе всех входящих векторов расстояний узелх
обновляет оба своих вектора следующим образом:
L(x, J) = min [L(y, j) + w(x, N ).
Здесь:
+ y = R(x,j) — значение, минимизирующее предыдущее выражение;
♦ А — множество узлов, соседних с узлом х;
4- N1V — сеть, соединяющая узел х с узлом у.
На рис. 15.5, а показана таблица маршрутизации для хоста X в момент време-
ни, отражающий стоимости линий сети, показанной на рис. 15.1. Для каждой
получающей сети указывается задержка распространения сигнала в пути, а также
следующий маршрутизатор на этом маршруте. Предположим, что в определенный
момент времени стоимость линии (то есть значение задержки в наблюдаемой ли-
нии) изменяется следующим образом: стоимости обеих линий маршрутизатора Е
становятся равными 1, и стоимости обеих линий маршрутизатора F становятся
равными 1. Предположим, что соседи маршрутизатора X (маршрутизаторы А, В
и С) узнают об этой перемене. Каждый из них обновляет свое значение векто-
ра расстояний и отправляет его копию всем своим соседям, включая маршрутиза-
тор X (рис. 15.5, б). Маршрутизатор X изменяет содержимое своей таблицы мар-
шрутизации только на основе полученного им вектора расстояний и собственной
оценки задержки в линиях с каждым из своих соседей. В этом случае задержку
15.2. Протокол RIP
481
в линиях ко всем трем соседям одинаковая, так как со всеми тремя соседними
маршрутизаторами маршрутизатор X связывается через сеть 1. Результат по-
казан на рис. 15.5, в.
F
Следующий маршрутизатор Сеть-получатель R(X, j) Метрика L(X, j) в С
1 — 1 3 8
2 в 2 1 8
3 в 5 4 5
4 А 2 3 6
5 А 8 4 6
а Следующий маршрутизатор Сеть-получатель Л?(Х. /) Метрк 1ка Г(Х .Л б
1 — 1
2 в 2
3 А 3
4 А 2
5 А 3
А
6
3
2
1
2
в
Рис. 15.5. Дистанционно-векторный алгоритм, примененный к сети на рис. 15.1
Распределенный алгоритм Беллмана — Форда
В только что показанном примере алгоритм, вроде бы, работает. Чтобы понять,
почему, сравните формулу (15.1) с шагом обновления алгоритма Беллмана — Фор-
да, обсуждавшегося в главе 14. По существу, зта формула точно такая же. Исполь-
зуемый в протоколе RIP алгоритм маршрутизации представляет собой распреде-
ленную версию алгоритма Беллмана — Форда, который был первым алгоритмом
маршрутизации в сети с коммутацией пакетов ARPANET.
Возможно, прояснить природу алгоритма Беллмана — Форда поможет его син-
хронная версия. Предположим, что каждый маршрутизатор начинает свою работу
со следующей операции присваивания:
А(х, j) =
w(x, j), если узел х напрямую соединен с сетью,
оо в противном случае.
(15.2)
Затем все маршрутизаторы одновременно обмениваются своими векторами
расстояний и рассчитывают время задержки с помощью формулы (15.1). Когда
расчеты закончены, все маршрутизаторы снова одновременно обмениваются сво-
ими векторами расстояний и применяют формулу (15.1). Каждая итерация экви-
валентна одной итерации алгоритма Беллмана — Форда (увеличение параметра h
на единицу), выполняемой параллельно на каждом узле графа. Рассмотрим отдель-
ный узел s. После первой итерации узел s получает сведения обо всех кратчайших
482
Глава 15. Протоколы внутренней маршрутизации
путях длиной максимум в один ретрансляционный участок. После второй итера-1
ции узел s получает сведения обо всех кратчайших путях длиной максимум в два
ретрансляционных участка и т. д., пока он не обнаружит все кратчайшие пути.
Было бы сложно координировать работу всех маршрутизаторов, так чтобы алго-
ритм выполнялся синхронно. Вместо этого в протоколе RIP и во всех остальных
основанных на дистанционно-векторной маршрутизации протоколах применяется
асинхронный метод. При запуске узел инициализируется в соответствии с форму-
лой (15.2). Получая новые дистанционные вектора от всех своих соседей, узел об-
новляет свои сведения при помощи формулы (15.1). Через каждые 30 секунд по
собственному таймеру каждый маршрутизатор передает свой вектор расстояний сво-
им соседям. Можно доказать работоспособность данного метода, то есть что он обес-
печивает все узлы правильными результатами. Если изменится стоимость одной
или нескольких линий в конфигурации, тогда узел сможет рассчитать новые кратчай-
шие маршруты за конечное время, пропорциональное количеству маршрутизаторов.
Доказательство работоспособности алгоритма длинное, его можно найти в [28].
Детали алгоритма RIP
В предыдущем общем описании алгоритма дистанционно-векторной маршрути-
зации игнорируются некоторые практические детали его работы, распределенной
между несколькими сотрудничающими друг с другом узлами. В данном подразде-
ле мы рассмотрим эти детали.
Инкрементное обновление
При использовании формулы (15.1) предполагается, что узел за короткий интер-
вал времени получает обновленные вектора расстояний от всех своих соседей, а
затем на основании полученной информации производит полный перерасчет сво-
их векторов. Это требование является непрактичным по нескольким причинам.
Поскольку алгоритм работает асинхронно, нет гарантии, что все обновления бу-
дут получены в течение любого заданного интервала времени. Более того, пакеты
протокола RIP посылаются при помощи протокола UDP, представляющего собой
ненадежный транспортный протокол, так что некоторые RIP-пакеты могут не дой-
ти до получателя.
Поэтому протокол RIP работает инкрементно, обновляя свою таблицу марш-
рутизации после получения любого вектора расстояний. При этом применяются
следующие правила:
♦ Если полученный вектор расстояний содержит информацию о новой сети,
эти сведения добавляются к таблице маршрутизации.
♦ Если узел получает данные о маршруте с меньшим значением времени за-
держки, информация о текущем маршруте заменяется новыми сведениями.
Например, предположим, что у нас есть конфигурация, представленная на
рис. 15.1, и таблица маршрутизации для хоста X, показанная на рис. 15.5, а.
Теперь допустим, что хост X получает только одно обновление, а именно
от хоста В, показанное на рис. 15.5, б. В этом случае единственное изме-
нение таблицы маршрутизации хоста X заключается в том, что £(Х, 5) = 5,
a R(X, 5) = В. Если впоследствии прибывает вектор расстояний от хоста Aj
15.2. Протокол RIP
483
также показанный на рис. 15.5, б, тогда таблица маршрутизации хоста X обнов-
ляется до состояния, показанного на рис. 15.5, в.
♦ Если узел получает обновленный вектор от маршрутизатора R и у этого узла
есть одна или несколько записей в таблице маршрутизации, в которых марш-
рутизатор R представляет следующий ретрансляционный участок, тогда все
эти записи обновляются, чтобы отразить новые данные от маршрутизатора R.
Чтобы понять, зачем нужно третье правило, предположим, что на рис. 15.5, в
показано текущее состояние таблицы маршрутизации хоста X, соответствующее
конфигурации на рис. 15.1, с той разницей, что стоимости всех линий, исходящих
от маршрутизаторов Е и F, равны 1. Предположим теперь, что маршрутизатор F
выходит из строя и это обнаруживает маршрутизатор А. Вскоре после этого
маршрутизатор А посылает маршрутизатору X вектор расстояний, в котором со-
общается о новом расстоянии до сети 5, равном 3. В данном случае хост X должен
увеличить значение £(Х, 5) с 3 до 4.
Изменения топологии
В предыдущем абзаце мы предположили, что маршрутизатор А узнал о том, что
маршрутизатор F вышел из строя. Как это возможно? Механизм, используемый в
протоколе RIP, следующий. Предполагается, что каждые 30 секунд каждый мар-
шрутизатор посылает обновленный вектор своим соседям. Пусть в таблице марш-
рутизации узла К есть запись для сети i, в которую он отправляет пакеты через
маршрутизатор N. В этом случае, если маршрутизатор К в течение 180 секунд
не получает обновленного вектора от маршрутизатора N, он помечает этот мар-
шрут как недействительный. Можно предположить, что либо маршрутизатор N
вышел из строя, либо сеть, соединяющая узлы К и N, стала нестабильной. Когда
маршрутизатор К узнает от любого своего соседа, что у него есть действитель-
ный маршрут к сети г, он заменяет недействительную запись о маршруте дей-
ствительной.
Маршрут помечается как недействительный установкой расстояния для этого
маршрута, равного бесконечности. На практике по причинам, которые будут
объяснены ниже, в протоколе RIP бесконечность обозначается числом 16.
Проблема счета до бесконечности
Одним из наиболее серьезных недостатков протокола RIP является его медленная
реакция на изменение топологии. Рассмотрим конфигурацию на рис. 15.6, в которой
стоимости всех линий равны 1. Расстояние от маршрутизатора В до сети 5 равно 2,
при этом маршрут от маршрутизатора В до сети 5 проходит через маршрутизатор D.
В то же время расстояние от маршрутизаторов А и С до сети 5 равно 3, а маршру-
ты проходят через маршрутизатор В. Теперь предположим, что маршрутизатор D
выходит из строя. Далее события могут развиваться по следующему сценарию:
1. Маршрутизатор В через маршрутизатор D обнаруживает, что сеть 5 стала
недоступной, и устанавливает расстояние до нее равным 4, основываясь на
сведениях, полученных от маршрутизаторов А или С. Это происходит, пото-
му что маршрутизатор В недавно получил от маршрутизаторов А и С сооб-
484
Глава 15. Протоколы внутренней маршрутизации
щение о доступности маршрутизатора D, в котором указывалось, что рассто-
яние до сети 5 равно 3. Когда подходит срок, маршрутизатор В передает эту
информацию в виде векторов расстояний маршрутизаторам А и С.
2. Маршрутизаторы А и С получают информацию об увеличении расстояния
до маршрутизатора D и корректируют свои данные о расстоянии до сети 5
увеличивая его до 5 (4 от маршрутизатора В до маршрутизатора D плюс 1
от маршрутизаторов А и С до маршрутизатора В).
3. Маршрутизатор В получает от маршрутизаторов А и С сообщение о том, что
расстояние до сети 5 равно 5, в связи с чем заключает, что теперь расстоя-
ние до этой сети равно 6.
Рис. 15.6. Проблема счета до бесконечности
Маршрутизаторы продолжают обмениваться подобными сообщениями до тех
пор, пока значение расстояния не достигнет бесконечности, для обозначения ко-
торой в протоколе RIP используется число 16. При 30-секундных интервалах меж-
ду сообщениями этот процесс займет от 8 до 16 минут.
Раздвоенный горизонт и негодный встречный маршрут
Проблема счета до бесконечности вызвана взаимным непониманием между марш-
рутизаторами В и А (и между маршрутизаторами В и С). Каждый полагает, что он
может достичь сети 5 через другого. Правило раздвоенного горизонта (split horizon),
применяемое в алгоритме RIP, утверждает, что нет смысла посылать информацию
о маршруте в том направлении, откуда она пришла, так как маршрутизатор, посы-
лающий вам информацию, находится ближе к получателю, чем вы. Это правило
ускоряет процесс обнаружения разрыва сети. Данные о недействительном пути
будут удалены из таблиц маршрутизации по истечении 180-секундного интервала
ожидания.
За счет незначительного увеличения размера сообщений, которыми обменива-
ются маршрутизаторы, протокол RIP позволяет еще быстрее решить данную про-
15.2. Протокол RIP
485
блему, используя правило негодного встречного маршрута (poisoned reverse). Это
правило отличается от простого правила раздвоенного горизонта отправкой сосе-
дям обновлений с равным 16 счетчиком ретрансляционных участков для маршру-
тов, выясненных этими соседями. Если у двух маршрутизаторов есть маршруты,
указывающие друг на друга, объявление о встречных маршрутах с расстояни-
ем 16 немедленно прерывает цикл.
формат RIP-пакета
На рис. 15.7 показан формат пакета протокола RIP. Каждый пакет содержит заго-
ловок с двумя полями:
♦ Команда. 1 означает запрос, 2 — ответ. Обновления о маршрутах посылаются
в виде ответов независимо от того, поступал ли запрос. Когда узел инициали-
зирует протокол RIP, он рассылает RIP-запросы путем широковещательной рас-
сылки. Каждый маршрутизатор, получая запрос, немедленно отправляет ответ.
♦ Версия. 1 означает оригинальный протокол RIP, 2 — протокол RIP-2.
О 8 16 31
Команда Версия ‘ о "< О О
Идентификатор семейства адресов 0 - Расстояние Расстояние до адреса 2 до адреса 1
IP-адрес 1
0
0
Метрика для адреса 1
Идентификатор семейства адресов 0
IP-адрес 2
0
0
Метрика для адреса 2
1 1
Идентификатор семейства адресов 0 Всего до 25 адресов
IP-адрес N
0
0
Метрика для адреса N
Рис. 15.7. Формат RIP-пакета
486
Глава 15. Протоколы внутренней маршрутизации
За заголовком следуют один или несколько блоков, в каждом из которых сооб-
щается длина пути до сети-получателя. В этих блоках содержатся следующие поля-
♦ Семейство адресов. Всегда 2 для IP-адресов.
IP-адрес. В этом поле указывается IP-адрес сети, то есть IP-адрес с ненуле
вым номером сети и нулевым номером хоста, уникально идентифицирую-
щий сеть.
♦ Метрика. Длина пути от данного маршрутизатора до указанной сети.
Как правило, используется стоимость линии, равная 1, так что метрика пред-
ставляет собой просто число ретрансляционных участков. Если допускаются боль-
шие значения стоимости линий, тогда количество ретрансляционных участков в
пути соответственно уменьшается.
Ограничения протокола RIP
Протокол RIP продолжает оставаться популярным благодаря своей простоте и удоб-
ству для небольших объединенных сетей, которых сегодня довольно много. Одна-
ко у него есть несколько ограничений:
♦ По мере роста объединенных сетей получатели, расстояния до которых пре-
вышают 15, становятся недоступными, что делает протокол RIP непригод-
ным для больших конфигураций. С другой стороны, если разрешить исполь-
зование больших метрик, время сходимости протокола после инициализации
или изменения топологии может оказаться большим.
♦ Использование чрезмерно упрощенной метрики приводит к созданию не-
оптимальных таблиц маршрутизации, в результате пакеты будут посылать-
ся по более медленным (или по более дорогим) путям в то время, когда до-
ступны лучшие пути.
♦ Устройства, поддерживающие протокол RIP, принимают обновления от лю-
бого устройства. Это может привести к тому, что неверно сконфигурирован-
ное устройство нарушит всю конфигурацию.
15.3. Протокол OSPF
По мере роста Интернета и других объединенных сетей, а также увеличения ско-
рости передачи данных ограничения протокола RIP становятся все большей про-
блемой. Хотя протокол RIP все еще широко применяется, в настоящее время в
объединенных сетях, работающих на основе набора протоколов TCP/IP, в ка-
честве протокола внутренней маршрутизации все чаще используется протокол
OSPF1 (Open Shortest Path First — первоочередное открытие кратчайших марш-
рутов).
1 RFC 2328, OSFP Version 2, апрель 1998.
I
/
15.3. Протокол OSPF
487
Центральное место в работе протокола OSPF занимает маршрутизация с уче-
том состояния линий. Мы начнем с общего описания этого подхода, затем пока-
жем, как он адаптируется для протокола OSPF.
Маршрутизация с учетом состояния линий
При дистанционно-векторной маршрутизации каждый маршрутизатор должен
передавать значительный объем информации, посылая всем своим соседям век-
тор расстояний, содержащий оценку стоимости путей ко всем сетям в конфигура-
ции. Когда происходит существенное изменение в стоимости линии или линия
становится недоступной, может потребоваться значительное время, чтобы инфор-
мация об этом распространилась по объединенной сети. Назначение маршрутиза-
ции с учетом состояния линий — справляться со всеми этими проблемами.
Общее описание
Во время инициализации маршрутизатор определяет стоимость линии для каж-
дого из своих сетевых интерфейсов. Затем маршрутизатор передает эту информа-
цию всем остальным маршрутизаторам в объединенной сети, а не только сосед-
ним. Далее маршрутизатор следит за состоянием своих линий. При значительном
изменении (радикально меняется стоимость линии, создается новая линия, стано-
вится недоступной существующая линия), маршрутизатор снова объявляет о сто-
имости своих линий всем маршрутизаторам конфигурации.
Поскольку каждый маршрутизатор получает информацию о стоимости линий
от всех маршрутизаторов, каждый маршрутизатор должен рассчитать топологию
всей конфигурации, а затем вычислить кратчайший путь к каждой сети. Выполнив
это, маршрутизатор может сформировать таблицу маршрутизации с данными о пер-
вом ретрансляционном участке в направлении каждого потенциального получателя.
Поскольку у маршрутизатора есть представление обо всей сети, он не пользуется
распределенной версией алгоритма маршрутизации, применяемой при дистанци-
онно-векторной маршрутизации. Вместо этого маршрутизатор может воспользо-
ваться любым алгоритмом определения кратчайшего пути. На практике исполь-
зуется алгоритм Дейкстры.
В табл. 15.1 сравнивается дистанционно-векторная маршрутизация и маршру-
тизация с учетом состояния линий.
Таблица 15.1. Сравнение стратегий маршрутизации
Дистанционно-векторная маршрутизация Маршрутизация с учетом состояния линий
Каждый маршрутизатор посылает сведения о маршрутах своим соседям Посылаемая информация представляет собой оценку стоимости путей ко всем сетям Информация посылается регулярно через определенный период времени Каждый маршрутизатор посылает сведения о маршрутах всем остальным маршрутизаторам Посылаемая информация представляет собой точное значение стоимости линий к смежным сетям Информация посылается в случае значительных изменений
продолжение#
488
Глава 15. Протоколы внутренней маршрутизации
Таблица 15.1 (продолжение)
Дистанционно-векторная маршрутизация Маршрутизация с учетом состояния линий
Маршрутизатор выбирает следующий ретрансляционный участок с помощью распределенного алгоритма Веллмана — Форда на основе полученных оценок стоимости путей Маршрутизатор сначала строит описание топологии объединенной сети, а затем может пользоваться любым алгоритмом маршрутизации для выбора маршрута
Лавинная маршрутизация
При маршрутизации с учетом состояния линий применяется простая техника, на-
зываемая лавинной маршрутизацией (flooding). Этот метод, не требующий знания
топологии сети, работает следующим образом. Маршрутизатор-источник посыла-
ет пакет всем своим соседям. Каждый получивший пакет маршрутизатор передает
его дальше по всем своим выходным линиям, кроме той, по которой этот пакет при-
был. Лавинную маршрутизацию для конфигурации, представленной на рис. 15.1,
иллюстрирует рис. 15.8. После первой передачи пакет получают все маршрутиза-
торы на расстоянии одного ретрансляционного участка от отправителя. После вто-
рой передачи пакет получают все маршрутизаторы на расстоянии двух ретрансля-
Рис. 15.8. Пример лавинной маршрутизации
Если не предпринять специальных мер, пакеты, передаваемые путем лавинной
маршрутизации, будут множиться и распространяться бесконечно. В нашем приме-
ре при первой передаче формируются два пакета, при второй передаче — четыре
пакета, при третьей — двенадцать, что в данном примере уже является излишним.
Один из способов избежать этого заключается в том, что каждый узел запоминает
идентификаторы отправленных им пакетов. Полученные дубликаты этих пакетов
отбрасываются. Этот метод применяется в протоколе OSPF.
Метод лавинной маршрутизации обладает тремя замечательными свойствами:
♦ Перебираются все маршруты между отправителем и получателем. Таким
образом, независимо от того, какие узлы или линии вышли из строя, пакет
всегда будет доставлен, если сохранился по меньшей мере один путь между
отправителем и получателем.
15.3. Протокол OSPF
489
4- Поскольку перебираются все маршруты, то по меньшей мере одна копия
пакета пройдет по маршруту, имеющему минимальную задержку.
Посещаются все узлы, прямо или косвенно соединенные с узлом-источником.
Благодаря первому свойству метод лавинной маршрутизации обладает высо-
кой устойчивостью. Благодаря второму свойству рассылаемая путем лавинной
маршрутизации информация быстро достигает всех маршрутизаторов. Благодаря
третьему свойству все маршрутизаторы получают информацию, необходимую для
создания таблиц маршрутизации.
Главный недостаток метода лавинной маршрутизации заключается в оказыва-
емом им на сеть высоком уровне нагрузки, пропорциональном количеству линий
связи в сети.
Протокол OSPF
Каждый маршрутизатор хранит описание состояния своих локальных линий, свя-
зывающих его с подсетями, и время от времени передает обновленные данные всем
известным ему маршрутизаторам. Каждый маршрутизатор, получающий пакет
обновления, должен подтвердить его получение. Подобные обновления создают
значительный трафик, так как описание состояния линий, хотя занимает и немно-
го места, но должно посылаться часто.
На каждом маршрутизаторе хранится база данных, отражающая топологию
объединенной сети. Топология выражается в виде ориентированного графа. Ниже
перечислены элементы графа.
4 Вершины, или узлы, двух типов:
♦ маршрутизатор;
» сеть, которая, в свою очередь, может быть транзитной, если она может
переносить данные и не заканчивается оконечной системой, и заглушкой,
если это не транзитная сеть.
4- Ребра двух типов:
♦ ребра графа, соединяющие две вершины-маршрутизатора, в случае, если
соответствующие маршрутизаторы соединены друг с другом прямой
двухточечной линией связи;
♦ ребра графа, соединяющие вершину-маршрутизатор с вершиной-сетью,
в случае, если маршрутизатор напрямую соединен с сетью.
На рис. 15.9, в основу которого положена иллюстрация из рекомендации
RFC 2328, показан пример конфигурации объединенной сети, а на рис. 15.10 —
соответствующий ориентированный граф. Маршрутизаторы обозначены симво-
лом R, хосты — символом Н, сети — символом N. При построении графа использо-
вались следующие преобразования:
4- Два маршрутизатора, соединенные двухточечной линией, представлены на
графе в виде пары вершин, напрямую соединенной парой ребер, по одному
в каждом направлении (например, маршрутизаторы 6 и 10).
4- Когда к сети (например, локальной сети или сети с коммутацией пакетов)
присоединены несколько маршрутизаторов, на ориентированном графе все
490 Глава 15. Протоколы внутренней маршрутизации
маршрутизаторы показаны соединенными с вершиной-сетыо двунаправлен-
ными линиями (например, маршрутизаторы 1,2,3 и 4 соединены с сетью 3).
♦ Если одиночный маршрутизатор соединен с сетью, сеть изображается на
графе в виде концевой заглушки (например, сеть 7).
4 - Оконечная система, называемая хостом, может быть напрямую соединена с
маршрутизатором. В этом случае хост изображается на графе (например, хост 1).
4 Если маршрутизатор соединен с остальными автономными системами, тогда
стоимость пути к каждой сети в другой системе должна получаться с помощью
какого-либо протокола внешней маршрутизации (ERP). Каждая такая сеть
представляется на графе в виде заглушки и связывающего ее с маршрутизато-
ром ребра с указанием известной стоимости пути (например, сети с 12 по 15).
Рис. 15.9. Пример автономной системы
15.3. Протокол OSPF
491
Стоимость пути ставится в соответствие с выходом интерфейса маршрутиза-
тора. Эта стоимость задается системным администратором. Дуги графа помечают-
ся стоимостью соответствующего выходного интерфейса маршрутизатора. Непо-
меченные дуги имеют нулевую стоимость. Обратите внимание на то, что дуги,
ведущие от сетей к маршрутизаторам, всегда имеют нулевую стоимость.
База данных, соответствующая ориентированному графу, хранится в каждом
маршрутизаторе. Она создается на основании сообщений, полученных от других
маршрутизаторов объединенной сети. С помощью алгоритма Дейкстры (см. гла-
ву 14) маршрутизатор рассчитывает путь с минимальной стоимостью до каждой
сети. Результат для маршрутизатора 6 (см. рис. 15.9) показан на рис. 15.11 в виде
связующего дерева, на котором маршрутизатор 6 является корнем. Это дерево
позволяет получить полный маршрут к каждой сети и к каждому хосту. Однако
в процессе переправки пакета используется только следующий ретрансляцион-
ный участок. Как и на предыдущих рисунках, маршрутизаторы обозначены сим-
волом R, хосты — символом Н, сети — символом N. Получающаяся в результате
таблица маршрутизации соответствует табл. 15.2. В таблицу в качестве получа-
телей включены записи для маршрутизаторов, объявляющих о внешних марш-
рутах (маршрутизаторы 5 и 7). В таблице также хранятся записи для известных
внешних сетей.
492
Глава 15. Протоколы внутренней маршрутизации
Рис. 15.11. Связующее дерево для маршрутизатора 6
Таблица 15.2. Таблица маршрутизации для маршрутизатора 6
Пункт назначения Следующий ретрансляционный участок Расстояние
N1 R3 10
N2 R3 10
N3 R3 7
N4 R3 8
N6 R10 8
N7 R10 12
N8 R10 10
N9 R10 11
N10 R10 13
N11 R10 14
Н1 R10 21
R5 R5 6
R7 R10 8
N12 R10 10
N13 R5 14
N14 R5 14
N15 R10 1Z 7
15.3. Протокол OSPF
493
Стоимость линий
Значения стоимости, поставленные в соответствие каждому ретрансляционному
участку в обоих направлениях, называют метрикой маршрутизации. Протокол
OSPF предоставляет гибкую схему метрики маршрутизации, основанную на кон-
цепции типа службы (Type Of Service, TOS).
♦ Обычная служба (TOS 0). Это метрика маршрутизации по умолчанию, на-
значаемая системным администратором для проведения любой админист-
ративной политики. Метрики по умолчанию понимаются каждым маршру-
тизатором. Значения могут назначаться произвольно. Простейший метод
заключается в назначении каждому ретрансляционному участку постоян-
ной величины, равной 1, в результате чего минимизируется объем вычисле-
ний. Но, как правило, каждому ретрансляционному участку в соответствие
ставится определенная метрика, тем или иным образом отражающая про-
пускную способность линии.
♦ Минимизация финансовой стоимости (TOS 2). Эта метрика может исполь-
зоваться, если для линий сети может быть назначена реальная денежная
сумма.
♦ Максимизация надежности (TOS 4). Эта метрика может быть настроена за-
ранее либо основываться на недавней истории неисправностей или на из-
меренной частоте ошибок пакетов.
♦ Максимизация пропускной способности (TOS 8). Эта метрика настраивает-
ся заранее на основе скорости передачи данных в интерфейсе. Как правило,
метрика представляет собой длительность бита в 10-наносекундных интер-
валах. Таким образом, 10-мегабитной линии Ethernet присваивается значе-
ние 10, а 56-килобитная линия получает значение 1785.
♦ Минимизация задержки (TOS 16). Это мера времени пересылки, или задерж-
ки передачи данных, по конкретному ретрансляционному участку. Как
правило, эта величина состоит из задержки распространения сигнала и за-
держки стояния в очереди на маршрутизаторе и измеряется динамически
каждым маршрутизатором для каждого из своих сетевых интерфейсов.
Это те же самые категории, которые используются в поле TOS протокола IPv4
(см. рис. 3.1 в главе 3). Когда маршрутизатор рассылает объявления о стоимости
своих линий, он предоставляет эти сведения для каждой категории типа службы.
Если метрика для какого-либо типа службы не указана, по умолчанию ее стоимость,
как правило, приравнивается к стоимости категории службы TOS 0.
Таким образом, каждый маршрутизатор может сформировать до пяти раз-
личных таблиц маршрутизации, по одной для каждой категории службы. В ре-
зультате каждый маршрутизатор формирует для конфигурации объединенной
сети пять связующих деревьев. Затем на основе этих категорий служб для IP-дей-
таграмм вычисляются маршруты. В каждой IP-дейтаграмме может быть указано
значение требующейся для нее категории TOS. Если в заголовке дейтаграммы
значение TOS не указано, тогда для маршрутизации используется значение TOS 0
по умолчанию.
494
Глава 15. Протоколы внутренней маршрутизации
Области
Чтобы сделать большие объединенные сети более управляемыми, в протокол OSPF
включено понятие области. Любая объединенная сеть может быть сконфигури-
рована таким образом, чтобы состоять из магистрали и нескольких областей:
4 Область (area) — множество соседних сетей и хостов, вместе с маршрутиза-
торами обладающих интерфейсами к одной из этих сетей.
4- Магистраль (backbone) — непрерывное множество не включенных ни в одну
из областей сетей, присоединенных к этим сетям маршрутизаторов, а также
маршрутизаторов, принадлежащих сразу нескольким областям.
Каждая область управляет отдельной копией основного алгоритма маршрутиза-
ции с учетом состояния линий и таким образом поддерживает топологическую базу
данных и соответствующий граф, отражающий топологию только этой области.
Информация о состоянии линий передается путем широковещательной рассылки
только маршрутизатором в той же самой области. Таким образом, в больших объеди-
ненных сетях существенно снижается объем трафика протокола OSPF. Если отпра-
витель и получатель IP-дейтаграммы находятся в одной и той же области, тогда
требуется только внутриобластная маршрутизация. В этом случае для маршрутиза-
ции достаточно информации о состоянии линий, формируемой внутри этой области.
Если отправитель и получатель IP-дейтаграммы находятся в разных областях,
тогда выбираемый маршрут состоит из трех участков. Первый участок пути нахо-
дится в области отправителя, а третий участок — в области получателя. При рас-
четах этих двух участков маршрута применяется внутриобластная маршрутиза-
ция. Для второго участка пути требуется передача дейтаграммы по магистрали из
области отправителя в область получателя. Сама магистраль обладает всеми свой-
ствами области и использует алгоритм маршрутизации с учетом состояния линий
для внутриобластной маршрутизации.
На верхнем уровне протокол OSPF рассматривает объединенную сеть как звез-
дообразную конфигурацию. В центре звезды располагается магистраль, а все при-
соединенные к ней области соответствуют лучам звезды.
Формат OSPF-пакета
В то время как RIP-пакеты передаются при помощи протокола UDP, работающе-
го поверх протокола IP, OSPF-пакеты передаются непосредственно протоколом
IP. Таким образом, OSPF-пакет представляет собой полезную нагрузку IP-паке-
та. В сети «точка — точка» или в широковещательной сети (например, в локальной
сети) IP-пакет помимо OSPF-пакета содержит стандартный групповой 1Р-адрес
224.0.0.5, обозначающий маршрутизаторы OSPF. В сетях, не поддерживающих
широковещательную рассылку, используются конкретные IP-адреса получателей,
настраиваемые в маршрутизаторе заранее.
Во всех OSPF-пакетах имеется один и тот же 24-байтовый заголовок (рис. 15.12),
поля которого перечислены далее:
4 Номер версии. Текущая версия протокола OSPF имеет номер 2.
4 Тип. Один из пяти типов пакетов, обсуждаемых далее.
15.3. Протокол OSPF
495
♦ Длина пакета. Длина OSPF-пакета в байтах, включая заголовок.
♦ Идентификатор маршрутизатора. Идентифицирует источник пакета. Каж-
дому маршрутизатору внутри области присваивается уникальный 32-раз-
рядный идентификатор.
4- Идентификатор области. Идентифицирует область, к которой принадлежит
маршрутизатор-источник. Все OSPF-пакеты ассоциируются с одной областью.
♦ Контрольная сумма. Стандартная контрольная сумма протокола IP для всего
содержимого OSPF-пакета, кроме 64-битового поля аутентификации. Вы-
числяется как сумма 16-разрядных слов пакета в дополнительном коде.
4 Тип аутентификации. Идентифицирует процедуру аутентификации, кото-
рая должна использоваться для этого пакета. Среди возможных вариантов:
отсутствие аутентификации, простой пароль, шифрование.
4 Данные аутентификации. 64-разрядное поле, используемое процедурой аутен-
тификации.
Бит Я
16
31
Номер версии
Тип
Длина пакета
8
Идентификатор маршрутизатора
Идентификатор области
сч
Контрольная сумма
Тип аутентификации
Данные аутентификации
Рис. 15.12. Заголовок OSPF-пакета
Следом за заголовком OSPF-пакета располагается тело пакета, содержимое кото-
рого зависит от типа пакета. В протоколе OSPF поддерживается пять типов пакета:
4 Приветствие. Используется для обнаружения соседей. Каждый маршрути-
затор периодически посылает подобные пакеты по всем своим интерфейсам.
Пакет содержит идентификаторы соседних маршрутизаторов, чьи пакеты-
приветствия уже получены.
4 Описание базы данных. Используется в процессе обмена базами данных.
Маршрутизаторы обмениваются не содержимым баз данных, а описани-
ем их структуры. Это позволяет маршрутизаторам синхронизировать свои
сетевые топологии.
4 Запрос о состоянии линий. Используется для получения из баз данных о со-
стоянии линий, хранящихся на соседних маршрутизаторах, определенной
части информации.
4 Подтверждение состояния линий. Подтверждает обновление состояния ли-
ний при условии надежного распространия информации о состоянии линии.
496
Глава 15. Протоколы внутренней маршрутизации
15.4. Рекомендуемые литература
и веб-сайты
Детальное описание различных алгоритмов маршрутизации можно найти во мно-
гих книгах ([118], [31], [180] и [210]). В [158] предоставляется подробное обсуж-
дение протокола OSPF.
В [134] описаны история и перспективы маршрутизаторов. В [164] анализи-
руются различные динамические версии алгоритмов Дейкстры и Беллмана —
Форда, оптимизирующие эффективность маршрутизаторов.
Рекомендуемый веб-сайт — OSPF working group. Это сайт группы IETF, зани-
мающейся разработкой протокола OSPF и относящихся к нему стандартов. Сайт
включает все документы RFC и проекты документов Интернета по данной теме.
15.5. Задания
1. Должна ли маршрутизация в объединенных сетях заниматься внутренней
маршрутизацией в сетях? Почему да или почему нет?
2. При неисправностях в сетевых линиях для TCP-соединений можно ожидать
потери одного или нескольких сегментов. Обнаружив потерю сегментов,
протокол TCP уменьшает размер окна. Целевая рассылка адаптируется к
неисправности линии (входящей в кратчайший путь), выбирая другой мар-
шрут (длиннее неисправного пути). Опишите поведение ТСР-соединения,
когда снова становится доступным прежний маршрут. Рассмотрите случай,
при котором размер TCP-окна таков, что канал связи между отправителем
и получателем по более длинному пути заполнен сегментами. Предполага-
ется одинаковая скорость передачи данных по всем линиям.
3. Начертите взвешенный граф, соответствующий рис. 15.1.
4. Для каждой записи в каждом векторе на рис. 15.5, б покажите путь, соответ-
ствующий указанной стоимости.
5. Составьте таблицу маршрутизации для маршрутизатора А (см. рис. 15.1).
Предположим, что в течение 30-секундного интервала стоимость всех ли-
ний, исходящих из маршрутизаторов Е и F, становятся равной 1, и обнов-
ленные векторы с маршрутизаторов Е и F прибывают на маршрутизатор А.
Допустим также, что обновленные векторы расстояний с других маршрути-
заторов еще не успели прибыть. Покажите обновленную таблицу маршрУ'
тизации маршрутизатора А.
6. При обсуждении алгоритма дистанционно-векторной маршрутизации, ис-
пользуемого в протоколе RIP, утверждалось, что «было бы сложно коорди-
нировать работу всех маршрутизаторов, так чтобы алгоритм выполнялся
синхронно». Назовите две причины данной проблемы.
7. Проблема счета до бесконечности, обсуждавшаяся при рассмотрении рис. 15.6,
может возникнуть не только в случае недоступности сети. Добавим к рис. 15.6
15.5. Задания
497
глобальную сеть, соединяющую маршрутизаторы С и D при помощи линии
стоимостью 10 в каждом направлении.
а) вычислите расстояние L(x, 5) и следующий ретрансляционный участок
R(x, 5) до сети 5 для каждого маршрутизатора;
б) предположим, что сеть 3 вышла из строя. Теперь маршрутизаторы долж-
ны использовать линии маршрутизаторов С и D. Новая маршрутизация
требуется, когда маршрутизатор В замечает, что маршрут до маршрути-
затора D более не пригоден. Сосчитайте значения L(x, 5) и R(x, 5) для
каждого маршрутизатора в зависимости от времени, пока не установит-
ся устойчивое состояние.
8. В протоколе RIP правила раздвоенного горизонта и негодного встречного
маршрута хорошо работают в линиях «точка — точка» между двумя маршру-
тизаторами. Но в широковещательной сети, такой как Ethernet, сообщения
протокола RIP рассылаются всем остальным узлам, в которых реализован
протокол RIP, а не адресуются конкретному узлу. Предположим, что А, В
и С — маршрутизаторы, соединенные с одной и той же сетью Ethernet, и
маршрутизатор А посылает сообщение о негодном встречном маршруте мар-
шрутизатору С, так как у маршрутизатор А есть данные о маршруте, прохо-
дящем через маршрутизатор С. То же самое сообщение будет также получе-
но маршрутизатором В. Вызовет ли это проблему? Если нет, то почему?
9. Предположим, что у маршрутизатора есть 30 маршрутов, о которых он
объявляет при помощи протокола RIP. Информация о первых 25 маршру-
тах передается в первой дейтаграмме, а об остальных 5 маршрутах — во вто-
рой. Что произойдет, если раз в час будет теряться первая дейтаграмма?
10. Почему в OSPF-пакете есть поле контрольной суммы, а в RIP-пакете ее нет?
11. Когда существуют несколько маршрутов с равной стоимостью до одного
получателя, протокол OSPF может разделить трафик на равные части меж-
ду маршрутами. Это называется балансированием нагрузки. Какой эффект
на протокол транспортного уровня, например TCP, оказывает подобное
балансирование нагрузки?
Глава 16
Протоколы внешней
маршрутизации
и групповая рассылка
До недавней лавины сложнейших исследований ученые пола-
гали, что птицам не требуются специальные знания или умения
для навигации и возвращения домой при ежегодных миграциях.
Однако собранные наблюдения показывают, что для решения
таких сложных задач, как корректировка отклонений от марш-
рутов (вызванных любыми причинами, включая ветры, грозы,
горы и т. д.), во время сезонных миграций птицы пользуются
поражающими воображение своим разнообразием источниками
информации, среди которых астрономические, атмосферные,
геологические. В двух словах, навигация птиц характеризуется
способностью собирать самую разнообразную информацию
и интерпретировать ее для достижения цели.
Теодор Барбер. Разум птиц
В этой главе мы продолжим изучение протоколов маршрутизации. Сначала мы
рассмотрим два маршрутно-векторных протокола маршрутизации BGP и IDRP.
Эта глава завершается обсуждением групповой рассылки в объединенных сетях И
изучением протоколов маршрутизации, необходимых для поддержки групповой
рассылки.
16.1. Протоколы BGP и IDRP
Протокол BGP (Border Gateway Protocol — протокол пограничного шлюза) пред-
ставляет собой протокол внешней маршрутизации, разработанный для объединен-
ных сетей, использующих набор протоколов TCP/IP, хотя сама концепция при-
менима к любой объединенной сети. В настоящее время в Интернете при выборе
протокола внешней маршрутизации предпочтение отдается протоколу BGP.
Ключевая особенность протокола BGP заключается в том, что в нем использу-
ется технический прием, называемый маршрутно-векторной маршрутизацией
(path-vector routing). Мы начнем с общего описания этого метода. Затем рассмот-
16.1. Протоколы BGP и IDRP
499
рим некоторые детали протокола BGP. Наконец, мы познакомимся с протоколом
IDRP, предназначенным для использования с протоколом IPv6.
Маршрутно-векторная маршрутизация
Ни дистанционно-векторная маршрутизация, используемая в протоколе RIP, ни
маршрутизация с учетом состояния линий, применяемая в протоколе OSPF, не
эффективны для внешней маршрутизации.
В протоколе дистанционно-векторной маршрутизации каждый маршрутизатор
рассылает своим соседям вектор, в котором перечисляются все сети, доступные для
данного маршрутизатора, вместе с некоторой мерой длины путей к этим сетям.
На основе получаемых от соседей обновлений каждый маршрутизатор строит базу
данных маршрутизации, но маршрутизаторам не известно, через какие конкрет-
но маршрутизаторы и сети проходят маршруты. Если попытаться использовать
такой подход для протокола внешней маршрутизации, то мы столкнемся с двумя
проблемами:
♦ В дистанционно-векторном протоколе предполагается, что всеми маршру-
тизаторами используется единая метрика расстояний, на основе которой
отдаются предпочтения тому или иному маршрутизатору. Однако в разных
автономных системах могут использоваться разные системы измерения рас-
стояний. Если разные маршрутизаторы по-разному интерпретируют одно и
то же значение расстояния, то могут возникнуть сложности при попытке
создать стабильные маршруты без зацикливания.
4 - У данной автономной системы могут быть различные приоритеты по отно-
шению к другим автономным системам. Могут даже существовать ограни-
чения, запрещающие использование некоторых автономных систем. Дистан-
ционно-векторный алгоритм не дает информации об автономных системах,
через которые пройдет маршрут.
При использовании протокола маршрутизации с учетом состояния линий каж-
дый маршрутизатор рассылает данные о своих линиях всем остальным марш-
рутизаторам. Каждый маршрутизатор составляет картину полной топологии объ-
единенной сети, а затем рассчитывает маршруты. У такого подхода также есть
проблемы, если пытаться использовать его для внешней маршрутизации.
♦ Опять у разных автономных систем могут быть разные метрики и разные
ограничения. Хотя протокол с учетом состояния линий позволяет маршру-
тизатору воссоздать полную картину топологии сети, наличие разных мет-
рик в разных автономных системах не позволит разработать работоспособ-
ный алгоритм маршрутизации.
♦ Рассылка для реализации протокола внешней маршрутизации информации
о состоянии линий всем маршрутизаторам в разных автономных системах
путем лавинной маршрутизации может оказаться невыполнимой.
Альтернативный подход, называемый маршрутно-векторной маршрутизацией,
заключается в отказе от метрики маршрутизации. В этом случае маршрутизаторы
просто обмениваются информацией о том, к каким сетям у них есть доступ и какие
500 Глава 16. Протоколы внешней маршрутизации и групповая рассылка
автономные системы нужно пересечь, чтобы попасть туда. Этот подход отличает-
ся от алгоритма дистанционно-векторной маршрутизации двумя аспектами.
Во-первых, маршрутно-векторный метод не включает оценок расстояния или сто-
имости. Во-вторых, в каждом блоке информации о маршрутах перечисляются все
автономные системы, которые требуется пройти, чтобы достичь сети получателя
Поскольку в векторе пути перечисляются все автономные системы, которые
должна пересечь дейтаграмма, маршрутизатор, обладая данной информацией, может
осуществлять политику маршрутизации. То есть маршрутизатор может избегать
некоторых маршрутов, чтобы не пересекать определенные автономные системы.
Например, перемещения конфиденциальной информации могут быть ограничены
заданными автономными системами. Либо у маршрутизатора может быть инфор-
мация о производительности или качестве части объединенной сети, входящей в
автономную систему, что может заставить маршрутизатор выбрать путь в обход
данной автономной системы. Среди примеров метрик производительности или
качества можно назвать скорость, пропускную способность, склонность к перегруз-
кам и общее качество работы. Кроме того, при выборе маршрута может использо-
ваться такой критерий, как минимизация числа пересекаемых автономных систем.
Протокол BGP
Протокол BGP1 (Border Gateway Protocol — протокол пограничного шлюза) был
разработан для того, чтобы позволить маршрутизаторам в разных автономных си-
стемах, называемым в стандарте шлюзами, сотрудничать друг с другом при обме-
не информацией о маршрутах. Протокол работает с помощью сообщений, посыла-
емых по TCP-соединениям. Возможные сообщения перечислены ниже. Текущая
версия протокола BGP называется BGP-4.
♦ Открытие. Используется для установки соседских отношений с другим
маршрутизатором.
♦ Обновление. Используется, во-первых, для передачи информации об одном мар-
шруте и/или, во-вторых, для перечисления нескольких удаляемых маршрутов.
♦ Подтверждение. Используется, во-первых, для подтверждения сообщения
об открытии сотрудничества и, во-вторых, для периодического подтверж-
дения соседских отношений.
+ Уведомление. Посылается в случае обнаружения ошибки.
В протокол BGP включены три процедуры:
4- приобретение соседей;
♦ проверка доступности соседей;
4- проверка доступности сетей.
Два маршрутизатора считаются соседями, если они присоединены к одной
и той же подсети. Если два маршрутизатора находятся в разных автономных
системах, им может понадобиться обменяться информацией о маршрутах. Для это-
го необходимо сначала выполнить процедуру приобретения соседей (neighbor
1 RFC 1771, A Border Gateway Protocol (BGP-4), март 1995.
16.1. Протоколы BGP и IDRP
501
acquisition). По существу, приобретение соседей происходит тогда, когда два со-
седних маршрутизатора в разных автономных системах соглашаются регулярно
обмениваться информацией о маршрутах. Необходимость формальной процедуры
объясняется тем, что некоторые маршрутизаторы могут быть не заинтересованны-
ми в сотрудничестве. Например, маршрутизатор может быть перегружен и отка-
заться отвечать за трафик, поступающий в автономную систему извне. В процессе
приобретения соседей один маршрутизатор посылает сообщение с запросом о со-
трудничестве другому маршрутизатору, который может принять предложение или
отвергнуть его. Протокол не выясняет, как один маршрутизатор узнает об адресе
или даже просто о существовании другого маршрутизатора, а также то, как марш-
рутизатор принимает решение о необходимости обмена информацией с другим
маршрутизатором. Эти вопросы должны решаться во время настройки сети или
при активном вмешательстве сетевого администратора.
Для выполнения процедуры приобретения соседей один маршрутизатор посы-
лает другому маршрутизатору сообщение об открытии сотрудничества. Если мар-
шрутизатор принимает запрос, он отвечает сообщением подтверждения сотрудни-
чества.
После того как соседские отношения установлены, для их поддержания исполь-
зуется процедура проверки доступности соседей (neighbor reachability). Каждый
партнер должен быть уверен, что другой партнер все еще существует и все еще
поддерживает с ним соседские отношения. Для этого маршрутизаторы периоди-
чески посылают друг другу сообщения подтверждения сотрудничества.
Последней процедурой, определенной спецификацией протокола BGP, явля-
ется процедура проверки доступности сети (network reachability). Каждый мар-
шрутизатор поддерживает базу данных доступных ему подсетей и маршрутов к
этим подсетям. Когда в этой базе данных производятся изменения, маршрутиза-
тор рассылает сообщение об обновлении другим маршрутизаторам, реализующим
протокол BGP. С помощью рассылаемых сообщений об обновлении все BGP-мар-
шрутизаторы могут собрать и поддерживать информацию, необходимую для мар-
шрутизации.
Сообщения протокола BGP
На рис. 16.1 показаны форматы всех сообщений протокола BGP. Каждое сообще-
ние начинается с 19-байтового заголовка, содержащего три поля (затененных на
рисунке):
♦ Маркер. Зарезервировано для аутентификации. Отправитель может запол-
нить это поле значением, которое будет использоваться как часть механиз-
ма аутентификации, позволяющего получателю проверить подлинность от-
правителя.
4- Длина. Длина сообщения в байтах.
♦ Тип. Тип сообщения (открытие, обновление, подтверждение или уведомление).
Чтобы приобрети соседа, маршрутизатор сначала устанавливает с интересующим
его соседним маршрутизатором TCP-соединение. Затем он посылает сообщение
об открытии сотрудничества. Это сообщение содержит идентификатор автономной
системы, к которой принадлежит отправитель, а также IP-адрес маршрутизатора.
Кроме того, сообщение об открытии сотрудничества включает предполагаемое
502
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
отправителем время поддержания (в секундах), представляющее собой максималь-
ный интервал времени между последовательными сообщениями об обновлении
и/или подтверждении сотрудничества. Если получатель согласен на установку
соседских отношений, он вычисляет новое значение времени поддержания, пред-
ставляющее собой минимальное значение из полученной величины времени под-
держания и собственного аналогичного параметра.
Байты
Байты
16
2
1
1
2
2
4
1
Переменное
поле
Версия
Автономная система
автора сообщения
Время
поддержания
Идентификатор
BGP
Длина
необязательных
параметров
Необязательные ;
параметры >
16
2
1
2
Переменное
поле
2
Переменное
поле
Переменное
поле
Сообщение
об обновлении
Сообщение об открытии
сотрудничества
Сообщение подтверждения
сотрудничества
Сообщение
с уведомлением об ошибке
Рис. 16.1. Формат сообщений протокола BGP
16.1. Протоколы BGP и IDRP
503
Сообщение подтверждения сотрудничества состоит просто из заголовка. Каж-
дый маршрутизатор посылает такие сообщения каждому из своих партнеров не
позднее, чем истечет очередной интервал времени поддержания.
Сообщение об обновлении позволяет обмениваться данными двух типов:
4 Информацией об одном маршруте через объединенную сеть. Эта информация
может быть добавлена к базе данных любого маршрутизатора-приемника.
4 Списком удаленных маршрутизаторов, о которых ранее объявлял этот мар-
шрутизатор.
Сообщение об обновлении может содержать данные одного или обоих типов.
Рассмотрим сначала данные первого типа. Информация об одном маршруте через
объединенную сеть попадает в три поля: NLRI (Network Layer Reachability Info-
rmation — информация о доступности сетевого уровня), TPAL (Total Path Attributes
Length — полная длина атрибутов пути) и поля атрибутов пути. Поле NLRI состоит
из списка идентификаторов подсетей, к которым можно получить доступ с помо-
щью этого маршрута. Каждая подсеть идентифицируется по своему IP-адресу, яв-
ляющемуся в действительности частью полного IP-адреса. Как уже упоминалось
в разделе 11.1, IP-адрес представляет собой 32-разрядное число вида {сеть, оконеч-
ная система}. Левая часть адреса (префикс) идентифицирует конкретную подсеть.
Поле атрибутов пути содержит список атрибутов конкретного маршрута. Ниже
приводится перечень определенных стандартом атрибутов.
4- Origin (происхождение). Указывает, была ли эта информация сформирова-
на протоколом внутренней маршрутизации (например, OSPF) или прото-
колом внешней маршрутизации (в частности, BGP).
4 AS_Path (автономные системы на пути). Список всех автономных систем,
пересекаемых данным маршрутом.
4- Next lloj) (следующий ретрансляционный участок). IP-адрес погранично-
го маршрутизатора, который должен использоваться в качестве следую-
щего ретрансляционного участка на пути к получателям, перечисленным
в поле NLRI.
4- Multi Exit Disc. Используется для обмена информацией о внутренних мар-
шрутах автономной системы. Это поле будет обсуждаться далее в этом раз-
деле.
4- Local_Pref (локальные предпочтения). Используется маршрутизатором для
информирования других маршрутизаторов, принадлежащих той же самой
автономной системе, о своих предпочтениях в отношении определенных
маршрутов. Это поле не имеет значения для маршрутизаторов из других
автономных систем.
4 Atomic_Aggregate, Aggregator. Эти два поля реализуют концепцию агреги-
рования маршрутов. По существу, объединенная сеть и соответствующее
ей адресное пространство могут быть организованы иерархически, то есть
в виде дерева. В данном случае адреса подсети разбиваются на две или более
частей. Все подсети, относящиеся к данному поддереву, используют об-
щую часть адреса. С помощью общего частичного адреса объем информации
в поле NLRI может быть значительно уменьшен.
504
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
Читателя, возможно, заинтересует назначение атрибута Next_Hop. Посылаю-
щему запрос маршрутизатору необходимо знать, к каким сетям можно получить
доступ через запрашиваемый маршрутизатор, но зачем предоставлять информа-
цию о других маршрутизаторах? Легче всего это можно объяснить при помощи
рис. 15.4 в главе 5. В данном примере маршрутизатор 1 в автономной системе 1 и мар-
шрутизатор 5 в автономной системе 2 реализуют протокол BGP и устанавливают
соседские отношения. Маршрутизатор 1 посылает маршрутизатору 5 сообщение
об обновлении, указывающее, к каким сетям у него имеется доступ, и расстояния
(количество ретрансляционных участков) до этих сетей. Маршрутизатор 1 также
предоставляет ту же самую информацию от имени маршрутизатора 2. То есть
маршрутизатор 1 сообщает маршрутизатору 5 о том, какие сети доступны через
маршрутизатор 2. В данном примере на маршрутизаторе 2 протокол BGP не реа-
лизован. Только несколько маршрутизаторов ответственны за общение с другими
маршрутизаторами из других автономных систем. Наконец, маршрутизатор 1 об-
ладает необходимой информацией о маршрутизаторе 2, так как маршрутизаторы 1
и 2 совместно используют протокол внутренней маршрутизации.
Информация об обновлении второго типа касается удаления одного или не-
скольких маршрутов. В этом случае маршрут идентифицируется по IP-адресу
подсети получателя.
Наконец, сообщение с уведомлением посылается в случае обнаружения ошиб-
ки. Отправитель может известить о следующих ошибках:
4 Ошибка в заголовке сообщения. Включает ошибки аутентификации и син-
таксиса.
♦ Ошибка в сообщении об открытии. Включает синтаксические ошибки и не-
распознаваемые параметры в сообщении об открытии сотрудничества. Это
сообщение также может использоваться, чтобы указать, что предложенное
значение интервала времени поддержания в сообщении об открытии явля-
ется неприемлемым.
♦ Ошибка в сообщении об обновлении. Включает синтаксические и смысловые
ошибки в сообщении об обновлении.
4- Истекло время поддержания. Если отправляющий маршрутизатор не полу-
чил очередного сообщения подтверждения и/или обновления в течение вре-
мени поддержания, то он передает данное сообщение об ошибке и разрыва-
ет соединение.
♦ Ошибка конечного автомата. Включает любые процедурные ошибки.
♦ Остановка. Используется маршрутизатором для разрыва соединения с дру-
гим маршрутизатором при отсутствии любых других ошибок.
Обмен информацией о маршрутах в протоколе BGP
Суть протокола BGP заключается в обмене информацией о маршрутах сотрудни-
чающими друг с другом маршрутизаторами в нескольких автономных системах.
Этот процесс может быть довольно сложным. Далее будет представлен упрощен-
ный обзор.
16.1. Протоколы BGP и IDRP
505
Рассмотрим маршрутизатор 1 в автономной системе 1 на рис. 15.4. Чтобы на-
чать действовать, маршрутизатор, на котором реализован протокол BGP, должен
воспользоваться протоколом внутренней маршрутизации, например OSPF. С помо-
щью протокола OSPF маршрутизатор 1 может обмениваться информацией о марш-
рутах с другими маршрутизаторами, находящимися в той же автономной системе 1,
получить представление о топологии подсетей и маршрутизаторов в автономной
системе 1 и сформировать таблицу маршрутизации. Затем маршрутизатор 1 может
послать сообщение об обновлении маршрутизатору 5 в автономной системе 2 со
следующими полями:
♦ AS Path — идентификатор автономной системы 1;
♦ Next_Hop — IP-адрес маршрутизатора 1;
4- NLRI — список всех подсетей в автономной системе 1.
Это сообщение информирует маршрутизатор 5 о том, что ко всем перечислен-
ным в поле NLRI подсетям можно получить доступ через маршрутизатор R1 и для
этого нужно пересечь всего одну автономную систему — автономную систему 1.
Предположим теперь, что у маршрутизатора 5 также установлены соседские
отношения с еще одним маршрутизатором в другой автономной системе, скажем,
с маршрутизатором 9 в автономной системе 3. В этом случае маршрутизатор 5 пе-
реправит только что полученные от маршрутизатора 1 сведения маршрутизатору 9
в виде нового сообщения об обновлении. Это сообщение будет включать следую-
щие поля:
4 AS Path — идентификаторы автономных систем {AS 1, AS2};
4- Next_Hop — IP-адрес маршрутизатора 5;
4- NLRI— список всех подсетей в автономной системе 1.
Это сообщение информирует маршрутизатор 9 о том, что ко всем перечислен-
ным в поле NLRI подсетям можно получить доступ через маршрутизатор 5 и для
этого нужно пересечь две автономные системы, AS1 и AS2. Теперь маршрутиза-
тор 9 должен решить, устраивает ли его предлагаемый ему маршрут к перечислен-
ным подсетям. Возможно, у него есть информация об альтернативном маршруте к
некоторым из этих подсетей или ко всем подсетям, которому он может отдать пред-
почтение по причине производительности или на основе какого-либо другого кри-
терия. Если маршрутизатор 9 решает, что маршрут, предлагаемый в полученном
от маршрутизатора 5 сообщении об обновлении, предпочтительнее, тогда он поме-
щает полученные данные в свою базу данных маршрутизации, а затем переправля-
ет эту информацию остальным соседям. Передаваемое им новое сообщение будет
включать поле ASPath с идентификаторами автономных систем {AS1, AS2, AS3}.
Подобным образом маршрутная информация распространяется по объединен-
ной сети большего размера, состоящей из множества соединенных друг с другом
автономных систем. Поле ASPath используется, чтобы гарантировать, что такие
сообщения не будут циркулировать бесконечно. Если сообщение об обновлении
получено маршрутизатором из автономной системы, включенной в поле AS Path,
то этот маршрутизатор не переправляет обновленную информацию другим марш-
рутизаторам, избегая таким образом зацикливания сообщений.
506
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
В предыдущем обсуждении были опущены некоторые детали, которые мы крат-
ко рассмотрим здесь. Маршрутизаторы, находящиеся в одной автономной систе-
ме и называемые внутренними соседями, могут обмениваться данными протокола
BGP. В данном случае отправляющий маршрутизатор не добавляет идентифика-
тора общей автономной системы к полю AS_Patli. Когда маршрутизатор выбира-
ет оптимальный путь к внешнему пункту назначения, он передает информацию
об этом маршруте всем своим внутренним соседям. При этом каждый получив-
ший эту информацию маршрутизатор решает, является ли новый маршрут лучше
уже известного ему. Если новый маршрут предпочтительнее предыдущего, данные
о нем добавляются в базу данных и передается новое сообщение об обновлении.
Если пограничному маршрутизатору в одной автономной системе доступны
несколько точек входа в другую автономную систему, для выбора точки входа
может использоваться атрибут MultiExitDisc. Этот атрибут содержит число, от-
ражающее некоторую внутреннюю меру расстояния до получателя в пределах дан-
ной автономной системы. Например, предположим, что на обоих маршрутизато-
рах 1 и 2 на рис. 15.4 реализован протокол BGP и оба поддерживают соседские
отношения с маршрутизатором 5. Оба маршрутизатора передают маршрутизато-
ру 5 сообщение об обновлении для подсети 1.3, содержащее метрику маршрутов,
используемую внутри автономной системы 1, например, связанную с протоколом
внутренней маршрутизации OSPF. Затем маршрутизатор 5 может на основе этих
двух метрик выбрать оптимальный маршрут.
Протокол IDRP
Протокол IDRP (Inter-Domain Routing Protocol — протокол внутридомеиной мар-
шрутизации)1 представляет собой протокол внешней маршрутизации, предназна-
ченный для использования совместно с протоколом IPv6. Кроме того, стандарт
ISO включает протокол IDRP в семейство протоколов OSI. Однако протокол
IDRP не зависит ни от семейства OSI, ни от межсетевых протоколов OSI и может
использоваться с любым другим межсетевым протоколом, а также в объединен-
ной сети, в которой применяется сразу несколько межсетевых протоколов.
Подобно протоколу BGP протокол IDRP основан на маршрутно-векторной
маршрутизации и предоставляет расширенный набор функций протокола BGP.
Далее перечислены ключевые различия этих двух протоколов:
♦ Протокол BGP работает поверх протокола TCP, тогда как протокол IDRP
работает поверх межсетевого протокола, используемого в текущей конфи-
гурации. Протокол IDRP включает собственную процедуру «рукопожатия»,
гарантирующую доставку сообщений.
♦ В протоколе BGP используются 16-разрядные номера автономных систем.
В протоколе IDRP применяются идентификаторы переменной длины.
♦ Протокол IDRP может работать с несколькими межсетевыми протоколами
и с несколькими схемами межсетевых адресов. Одно сообщение протокола
IDRP с рекомендованным маршрутом может содержать несколько форма-
тов сетевых адресов.
* ISO 10747, Protocolfor Exchange of Inter-Domain Routinginformation among Intermediate Systems to Support
Forwarding of ISO 8473 PDUs.
16.2. Групповая рассылка
507
♦ Протокол BGP сообщает информацию о маршруте, указывая полный спи-
сок автономных систем вдоль маршрута. Протокол IDRP может агрегиро-
вать эту информацию в соответствии с концепцией конфедераций доменов.
Наконец, возможно, наиболее важное различие между протоколами BGP и
IDRP заключается в том, что в протоколе IDRP несколько соединенных автоном-
ных систем могут объединяться в конфедерацию. Системный администратор мо-
жет настроить автономные системы, входящие в конфедерацию, таким образом,
что они будут выглядеть для окружающих как одна автономная система. При этом
любой маршрут, заканчивающийся в конфедерации или проходящий через нее,
идентифицируется единственной записью в векторе маршрута, а не несколькими
записями, по одной для каждой автономной системы. Этот процесс является
рекурсивным, так что группы соединенных друг с другом конфедераций также
могут объединяться в конфедерацию. В результате получается стратегия маршру-
тизации, допускающая эффективное масштабирование при увеличении размера и
сложности объединенной сети.
16.2. Групповая рассылка
Как правило, IP-адрес идентифицирует отдельный хост в некоторой сети. Прото-
колом IP также поддерживаются адреса, обозначающие группу хостов в одной или
нескольких сетях. Такие адреса называются групповыми (multicast addresses),
а передача пакета от источника членам такой группы называется групповой рас-
сылкой (multicasting).
У групповой рассылки может быть несколько практических приложений:
♦ Мультимедиа. Несколько пользователей могут «настроиться» на радио или
телепередачу мультимедийной станции.
♦ Телеконференции. Группа рабочих станций образует группу рассылки, в ко-
торой передаваемый любому члену группы пакет получают все остальные
члены группы.
♦ База данных. Все копии реплицируемого файла или базы данных обновля-
ются одновременно.
♦ Распределенные вычисления. Промежуточные результаты посылаются всем
участникам.
♦ Рабочие группы, работающие в режиме реального времени. Активные члены
группы обмениваются файлами, графикой и сообщениями в режиме реаль-
ного времени.
Групповая рассылка в пределах одной локальной сети реализуется предельно
просто. Многими протоколами локальных сетей, например IEEE 802, поддержи-
ваются групповые адреса на подуровне MAC (Medium Access Control — управле-
ние доступом к носителю). Пакет с групповым адресом передается в локальную
сеть. Станции, являющиеся членами соответствующей группы, распознают груп-
повой адрес и принимают пакет. В данном случае передается только одна копия
пакета. Этот метод работает благодаря широковещательной природе локальных
508
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
сетей, в которых данные, передаваемые одной станцией, принимаются всеми ос-
тальными станциями локальной сети.
В условиях объединенной сети групповую рассылку реализовать гораздо слож-
нее. Для наглядности рассмотрим конфигурацию на рис. 16.2, где несколько ло-
кальных сетей (обозначены символом N) соединены через маршрутизаторы либо
высокоскоростными линиями (обозначены символом L), либо глобальной сетью
(сеть 4). Каждой линии связи или сети сопоставлена стоимость, указанная ря-
дом с линией, исходящей из маршрутизатора. Пусть сервер групповой рассылки
в сети 1 передает пакеты по групповому адресу, соответствующему группе рабочих
станций, подключенных к сетям 3,5 и 6. Предположим, что сервер не знает располо-
жения членов группы. В этом случае один из способов обеспечить передачу паке-
тов всем членам группы заключается в том, чтобы передать копию каждого пакета
в каждую сеть конфигурации по пути с минимальной стоимостью к каждой сети.
Такой метод называется широковещательной рассылкой (broadcasting). Например,
один пакет будет адресован сети 3, куда он попадет через сеть 1 и линию 3. Преж-
де чем передать пакет в сеть 3, маршрутизатор В преобразует групповой адрес
уровня IP в групповой адрес уровня МАС. По табл. 16.1 можно судить о том, ка-
кое количество пакетов, сгенерированных в разных линиях и сетях путем широ-
ковещательной рассылки, требуется для передачи одного пакета группе. В данном
случае источником является сервер групповой рассылки в сети 1. Групповой
адрес охватывает участников, принадлежащих сетям 3, 5 и 6. Каждый столбец
таблицы соответствует пути от хоста-источника к маршрутизатору, соединенно-
му с получающей сетью. Каждая строка таблицы соответствует сети или линии
связи в конфигурации, показанной на рис. 16.2. В каждой ячейке таблицы содер-
жится количество пакетов, пересекающих данную линию или сеть по данному
пути. Таким образом, для доставки пакета всем членам группы путем широкове-
щательной рассылки потребовалось 13 копий пакета.
Таблица 16.1. Трафик, генерируемый разными методами множественной рассылки
Сети и линии Широковещательная рассылка S—>N2 S—>N3 S-»N5 S >N6 Итого Множественная целевая рассылка Итого Групповая рассылка
S—>N3 S—>N5 S->N6
N1 1 1 1 1 4 1 1 1 3 1
N2
N3 1 1 1 1 1
N4 1 1 2 1 1 2 2
N5 1 1 1 1 1
N6 1 1 1 1 1
L1 1 1
L2
L3 1 1 1 1 1
L4 1 1 2 1 1 2 1
L5
Итого 2 3 4 4 13 3 4 4 11 8
16.2. Групповая рассылка
509
Теперь предположим, что передающей системе известно расположение каждо-
го члена группы. То есть у отправителя есть таблица, преобразующая групповой
адрес в список сетей, в которых находятся члены группы. В этом случае источни-
ку достаточно выслать пакеты только этим сетям. Такая стратегия называется мно-
жественной целевой рассылкой (multiple unicasting). Как видно из таблицы, при
использовании этого метода в конфигурации, показанной на рис. 16.2, требуется
только И пакетов.
Рис. 16.2. Пример сетевой конфигурации
Обе эти стратегии неэффективны, так как создают лишние копии пакетов.
В настоящей стратегии групповой рассылки используется следующий метод:
1. Определяется маршрут с наименьшей стоимостью от источника до каждой
сети, включающей членов группы. В результате строится связующее дере-
во. Обратите внимание на то, что это не полное связующее дерево для дан-
ной конфигурации. Построенное связующее дерево включает только сети,
в которых находятся члены группы.
2. Источник передает по связующему дереву всего один пакет.
3. Этот пакет реплицируется маршрутизаторами только в точках ветвления
связующего дерева.
На рис. 16.3, а показано связующее дерево для передачи пакетов от источника груп-
пе, а рис. 16.3, б иллюстрирует сам метод групповой рассылки (символом N обозначе-
510
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
ны сети, символом L — линии, символом R — маршрутизаторы). Источник передает
единственны!'! пакет через сеть 1 маршрутизатору D. Маршрутизатор D делает две
копии пакета и передает их по линиям 3 и 4. Маршрутизатор В получает пакет по
линии 3 и передает его в сеть 3, где пакет читается членами группы. Между тем
маршрутизатор С получает пакет, посланный по линии 4. Он должен доставить
этот пакет маршрутизаторам Е и F. Если бы сеть 4 была сетью с широковещательной
рассылкой (например, локальной сетью Ethernet), тогда маршрутизатору С было
бы достаточно передать всего один экземпляр пакета, который смогли бы прочитать
оба маршрутизатора. Но поскольку сеть 4 представляет собой глобальную сеть
маршрутизатор С вынужден создать две копии пакета и послать одну маршрути-
затору Е, а вторую — маршрутизатору F. Каждый из этих маршрутизаторов, в свою
очередь, пересылает полученный пакет по сетям 5 и 6 соответственно. Как видно
из табл. 16.1, при групповой рассылке требуется только 8 копий пакета.
Необходимые условия для групповой рассылки
В случае обычной целевой рассылки через объединенную сеть, при которой каж-
дая дейтаграмма направляется в уникальную сеть назначения, задача каждого мар-
шрутизатора заключается в том, чтобы переправить дейтаграмму по кратчайшему
пути в соответствующую сеть. В случае групповой рассылки маршрутизатору
может потребоваться отправить две или более копий полученной дейтаграммы.
В нашем примере маршрутизаторы С и D должны передать по две копии исход-
ной дейтаграммы.
Таким образом, следует ожидать, что маршрутизация при групповой рассылке яв-
ляется функционально более сложной, чем при обычной целевой рассылке с одним
получателем. Далее перечислены необходимые для маршрутизации процедуры.
♦ Требуется соглашение для идентификации группового адреса. В протоколе
IPv4 для этой цели зарезервированы адреса класса D (см. рис. 3.3 в главе 3).
Это 32-разрядные адреса, старшие 4 бита которых равны 1110, а оставшиеся
28 разрядов содержат идентификатор группы. В протоколе IPv6128-разрядный
групповой адрес состоит из 8-разрядного префикса из 8 единиц, 4-разрядпого
поля флагов, 4-разрядного поля области и 112-разрядного идентификатора
группы. На сегодняшний день поле флагов указывает только, является ли этот
адрес постоянным или нет. Поле области идентифицирует сферу применимос-
ти этого адреса, варьирующуюся от отдельной подсети до глобальной сети.
♦ Каждый узел (маршрутизатор или источник, участвующий в алгоритме
маршрутизации) должен преобразовывать групповой IP-адрес в список
сетей, содержащих членов этой группы. Эта информация позволяет узлу
создать связующее дерево кратчайших путей к каждой сети, содержащей
членов группы.
♦ Маршрутизатор должен преобразовывать групповой IP-адрес в групповой
адрес подсети, чтобы обеспечить доставку в сеть назначения IP-дейтаграм-
мы, отправленной методом групповой рассылки. Например, в сетях стандар-
та IEEE 802, включая сети Ethernet, длина адреса подуровня МАС равна
48 бит. Если старший бит установлен в 1, тогда этот адрес групповой. Для
доставки маршрутизатор, соединенный с сетью IEEE 802, должен преобра-
16.2. Групповая рассылка
511
зовать 32-разрядный адрес протокола IPv4 или 128-разрядный адрес прото-
кола IPv6 в 48-разрядный адрес подуровня МАС.
N1
Рис. 16.3. Пример групповой рассылки
512
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
♦ Хотя некоторые групповые адреса должны назначаться на постоянной осно-
ве, более распространена практика динамического назначения групповых
адресов. Таким образом, необходим механизм, при помощи которого отдель-
ный хост информирует присоединенные к его сети маршрутизаторы о сво-
ем членстве в группе.
♦ Маршрутизаторы должны обмениваться информацией двух типов. Во-пер-
вых, маршрутизаторы должны знать, какие подсети содержат членов дан-
ной группы. Во-вторых, маршрутизаторам требуется достаточный объем
информации для определения кратчайшего пути к каждой сети, содержащей
членов группы. Эти требования подразумевают наличие протокола марш-
рутизации.
♦ Необходим алгоритм маршрутизации для вычисления кратчайших путей ко
всем членам группы.
- 4 Каждый маршрутизатор должен определять маршруты групповой рассыл-
ки на основе адресов отправителя и получателя.
Последний пункт является следствием использования групповых адресов. Чтобы
проиллюстрировать этот пункт, вернемся к рис. 16.2. Если сервер груповой рассыл-
ки передает обычный пакет, адресованный хосту в сети 5, пакет маршрутизатором D
переправляется маршрутизатору С, который затем переправляет его маршрутиза-
тору Е. Аналогично, пакет, адресованный хосту в сети 3, маршрутизатором D пе-
реправляется маршрутизатору В. Теперь предположим, что сервер передает пакет
с групповым адресом, который должен быть доставлен хостам в сетях 3, 5 и 6. Как
уже говорилось ранее, маршрутизатор D создает две копии пакета и посылает одну
копию маршрутизатору В, а другую — маршрутизатору С. Пока что все нормаль-
но. Но что будет делать маршрутизатор С, получив пакет с групповым адресом?
Маршрутизатору С известно, что этот пакет предназначается для сетей 3, 5 и 6.
Проще всего было бы вычисление маршрутизатором С кратчайших маршрутов к каж-
дой из этих трех сетей. В результате маршрутизатор С получил бы связующее дерево
кратчайших путей, показанное на рис. 16.4 (как и ранее, символом N обозначены
сети, символом L — линии, символом R — маршрутизаторы). После этого марш-
рутизатор С посылал бы две копии пакета через глобальную сеть 4, одну в сеть 5,
а вторую в сеть 6. Но ему также нужно отправить копию пакета маршрутизатору В
для доставки сети 3! Таким образом, маршрутизатор В получил бы две копии па-
кета: одну от маршрутизатора D и вторую от маршрутизатора С. Ясно, что это не
то, что предполагал хост из сети 1, отправляя пакет.
Чтобы избежать ненужного дублирования пакетов, каждый маршрутизатор
должен направлять пакеты, учитывая не только групповой адрес получателей, но
и адрес отправителя. Когда маршрутизатор С получает пакет, направляемый ме-
тодом групповой рассылки группе отправителем из сети 1, он должен рассчитать
связующее дерево с корнем в сети 1 (см. рис. 16.3, о) и выбрать маршрут на основе
этого связующего дерева.
В оставшейся части этого раздела изучаются три важных протокола, относя-
щиеся к групповой рассылке. Сначала мы рассмотрим протокол 1GMP, позволя-
ющий хосту присоединяться к группам и выходить из них. Затем мы изучим про-
токол MOSPF, являющийся расширением обсуждавшегося в главе 15 протокола
OSPF и обеспечивающий маршрутизацию при групповой рассылке в пределах
16.2. Групповая рассылка
513
автономной системы. Наконец, мы обсудим протокол PIM, предназначенный для
внутридоменной групповой рассылки.
Рис. 16.4. Связующее дерево от маршрутизатора С до группы рассылки
Протокол IGMP
Протокол IGMP (Internet Group Management Protocol — протокол управления
группами в объединенных сетях), определенный в RFC 22361, используется хос-
тами и маршрутизаторами для обмена информацией по локальной сети о членстве
в группах. В протоколе IGMP используется широковещательная природа локаль-
ных сетей, обеспечивающая эффективный метод обмена информацией между хо-
стами и маршрутизаторами.
Формат сообщения протокола IGMP
Все сообщения протокола IGMP посылаются в IP-дейтаграммах и имеют формат,
показанный на рис. 16.5. Далее перечислены поля этих сообщений:
♦ Тип. Существуют следующие четыре типа:
♦ Запрос о членстве. Посылается маршрутизатором групповой рассылки.
Имеется два подтипа: во-первых, общий запрос, позволяющий узнать, у
каких групп есть члены в присоединенной к маршрутизатору сети; во-
вторых, запрос, касающийся конкретной группы и позволяющий узнать,
есть ли члены этой группы среди хостов сети, присоединенной к марш-
рутизатору.
♦ Объявление о членстве. Посылается хостом, чтобы объявить о своем член-
стве в группе.
♦ Выход из группы. Посылается хостом, чтобы объявить о своем выходе из
группы.
♦ Максимальное время отклика. Имеет значение только в сообщении зап-
роса о членстве. В нем указывается измеряемый в десятых долях секун-
ды максимальный интервал времени, в течение которого должен быть
послан ответ.
1 RFC 2236, Internet Group Multicast Protocol, Version 2, ноябрь 1997.
514
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
4 Контрольная сумма. Код обнаружения ошибок, вычисляемый как сумма
четырех 16-разрядных слов сообщения в дополнительном коде. Перед сум-
мированием само поле контрольной суммы обнуляется. Тот же алгоритм
используется в протоколе IPv4.
4 Групповой адрес. Ноль в запросе и действительный IP-адрес группы в объяв-
лении о членстве или в извещении о выходе из группы.
О 8 16 31
Тип Максимальное время отклика Контрольная сумма
Групповой адрес (адрес класса D протокола IPv4)
Рис. 16.5. Формат сообщения IGMPv2
Функционирование протокола IGMP
Назначение протокола IGMP состоит в том, чтобы каждый хост, использующий
этот протокол, мог сообщить о своем членстве в группе другим хостам локальной
сети и всем маршрутизаторам локальной сети. Чтобы стать членом группы, хост
посылает объявление о членстве, в котором указывает адрес группы. Это сообще-
ние отправляется в IP-дейтаграмме с тем же групповым адресом получателя. Дру-
гими словами, поле «Групповой адрес» в сообщении IGMP совпадает с полем «Ад-
рес получателя» в заголовке IP-дейтаграммы. Это сообщение получат все хосты,
являющиеся в данный момент членами группы, и узнают о появлении нового чле-
на группы. Каждый маршрутизатор, присоединенный к данной локальной сети,
должен «слушать» все IP-дейтаграммы, отправленные путем групповой рассыл-
ки, чтобы знать обо всех объявлениях.
Маршрутизатор групповой рассылки поддерживает список действительных па
данный момент активных групповых адресов, для чего он периодически рассыла-
ет общий запрос IGMP, отправляемый в IP-дейтаграмме с групповым адресом,
соответствующим всем хостам. Каждый хост, желающий оставаться членом одной
или нескольких групп, должен читать дейтаграммы с групповым адресом всех хо-
стов. Когда такой хост получает запрос, он должен послать в ответ объявление о
членстве в каждой группе, членом которой он себя считает.
Обратите внимание на то, что маршрутизатору групповой рассылки не нужно
знать идентификатор каждого хоста в группе. Достаточно знать, что существует
хотя бы один все еще активный член группы. Поэтому каждый хост группы, полу-
чающий запрос, запускает таймер со случайным интервалом времени. Любой хост,
слышащий, как другой хост объявляет о своем членстве в группе, воздерживается
от подачи собственного объявления. Если по истечении интервала ожидания никто
не передал объявления, то хост сам передает объявление. При такой схеме марш-
рутизатору групповой рассылки отвечает только один из членов каждой группы.
Покидая группу, хост посылает соответствующее сообщение, используя стати-
ческий групповой адрес, охватывающий все маршрутизаторы. Получив такое со-
общение, маршрутизатор сначала проверяет, относится ли это сообщение к нему,
то есть числится ли данная группа в его списке, и если да, то остались ли в зтой
16.2. Групповая рассылка
515
группе еще члены. Для этого маршрутизатор использует специфический для дан-
ной группы запрос.
Группы в протоколе IPv6
Протокол IGMP был разработан для взаимодействия с протоколом IPv4. В нем
используются 32-разрядные адреса. Аналогичная схема адресации требуется для
работы в объединенных сетях по протоколу IPv6. Вместо того чтобы разрабаты-
вать отдельную версию протокола IGMP для IPv6, его функции были встроены
в протокол ICMPv6 (Internet Control Message Protocol, Version 6 — протокол
управления сообщениями в объединенных сетях, версия 6). В протоколе ICMPv6
реализованы все функции протоколов ICMPv4 и 1GMP. Для поддержки группо-
вой рассылки в протокол ICMPv6 включены сообщения с запросом членства в
группе и объявлением о членстве в группе, используемые тем же самым образом,
что и в протоколе IGMP. К ним добавлено новое сообщение о завершении член-
ства в группе, позволяющее хосту объявить о том, что он покидает группу.
Расширение протокола OSPF для групповой
рассылки
Протокол MOSPF (Multicast OSPF — протокол OSPF для групповой рассыл-
ки) представляет собой расширение обсуждавшегося в главе 15 протокола OSPF
(Open Shortest Path First — первоочередное открытие кратчайших маршрутов),
обеспечивающее маршрутизацию IP-дейтаграмм групповой рассылки. Протокол
MOSPF предназначен для работы в пределах одной автономной системы1.
Протокол MOSPF следует стратегии, упоминавшейся в предыдущем обсужде-
нии групповой рассылки в объединенных сетях. Каждый присоединенный к ло-
кальной сети маршрутизатор использует протокол IGMP для формирования кар-
тины членства в локальных группах. Периодически каждый маршрутизатор путем
лавинной маршрутизации рассылает информацию о членстве в локальных груп-
пах всем остальным маршрутизаторам в данной области. В результате все марш-
рутизаторы в данной области могут составить детальное представление обо всех
членах всех групп. С помощью алгоритма Дейкстры каждый маршрутизатор соз-
дает связующее дерево кратчайших путей от сети-источника до всех сетей, содер-
жащих членов групп. Поскольку подобные вычисления отнимают очень много
времени, они выполняются только по требованию. То есть маршрутизатор не стро-
ит связующего дерева для данного источника и данной группы получателей до тех
пор, пока в ходе групповой рассылки он не получит IP-дейтаграмму именно от это-
го источника и именно для данной группы получателей.
Получив пакет групповой рассылки, маршрутизатор выполняет следующие
действия:
1. Если групповой адрес не идентифицируется, дейтаграмма отбрасывается.
2. Если маршрутизатор присоединен к сети, содержащей по меньшей мере од-
ного члена этой группы, он передает в эту сеть копию данной дейтаграммы.
1 RFC 1584, Multicast Extensions to OSPF, март 1994.
516 Глава 16. Протоколы внешней маршрутизации и групповая рассылка
----------------------------------------“ ~ --------------------—
3. С помощью связующего дерева, построенного им для данной пары источ-
ник — получатель, маршрутизатор определяет количество копий дейтаграм-
мы, которые он пересылает другим маршрутизаторам.
При пересечении широковещательной сети, например локальной, IP-дейтаг-
рамма групповой рассылки находится внутри кадра групповой рассылки подуров-
ня МАС, адресованного всем маршрутизаторам локальной сети.
Работа только что описанного алгоритма может быть осложнена некоторыми
особыми обстоятельствами, с которыми протокол MOSPF должен справляться
Мы рассмотрим эти обстоятельства по очереди.
Наличие нескольких путей равной стоимости
Может случиться так, что между данным источником и данной сетью-получате-
лем будет несколько путей равной стоимости. В этом случае алгоритм Дейкстры
построит связующее дерево, в которое войдет один из этих путей. Который имен-
но, зависит от порядка, в котором будут обрабатываться узлы. В случае маршру-
тизации для целевой рассылки не важно, что на каждом маршрутизаторе алгоритм
Дейкстры будет работать одинаково и построит одно и то же связующее дерево,
так как каждый узел находит кратчайший от себя маршрут ко всем сетям. Однако
в случае маршрутизации для групповой рассылки каждый узел определяет крат-
чайший маршрут ко всем покрываемым групповым адресом сетям-получателям
от некоей сети-источника. Соответственно, важно, чтобы маршрутизаторы до-
говорились о едином связующем дереве для данного узла-источника. Для этого
в протокол MOSPF включена специальная схема разрешения конфликтов.
Групповая рассылка между областями
Как упоминалось в главе 15, протокол OSPF включает понятие области. Объеди-
ненная сеть может быть организована в виде двухуровневой иерархии. На верх-
нем уровне находится магистраль, ниже располагаются несколько областей. Каж-
дая область представляет собой непрерывное множество сетей и хостов, а также
маршрутизаторов, присоединенных к этим сетям. Магистраль представляет собой
непрерывное множество сетей и маршрутизаторов, не входящих ни в одну из об-
ластей, а также маршрутизаторов, принадлежащих одновременно нескольким об-
ластям. Алгоритм OSPF с учетом состояния линий реализуется внутри каждой
области. То есть у маршрутизаторов внутри области есть детальное представле-
ние о топологии их области, и они могут выполнять алгоритм Дейкстры в пре-
делах их области. Пакеты, направляемые за пределы области, пересылаются по-
граничному маршрутизатору, который переправляет дейтаграммы по магистрали
в область получателя.
При групповой рассылке использование областей усложняется, так как члены
группы могут находиться сразу в нескольких областях. Чтобы минимизировать
размеры баз данных, поддерживаемых маршрутизаторами, каждый маршрутиза-
тор хранит сведения только о тех группах, члены которых находятся в его облас-
ти. Обменом информацией о членстве в группах между областями и групповой
рассылкой из одной группы в другую занимается подмножество пограничных
16.2. Групповая рассылка
517
маршрутизаторов, называемых передатчиками межобластной групповой рассыл-
ки (interarea multicast forwarders). Далее перечислены их ключевые функции.
4- Поскольку каждый передатчик межобластной групповой рассылки соеди-
нен с некоторой областью, он получает из этой области сообщения о состоя-
нии линий и таким образом знает все группы этой области. И наоборот,
поскольку в каждую область входит по меньшей мере один передатчик меж-
областной групповой рассылки, информация о группах этой области стано-
вится известной хотя бы одному магистральному маршрутизатору.
♦ Магистральные маршрутизаторы обмениваются информацией о группах,
так что все магистральные маршрутизаторы знают, в каких областях содер-
жатся члены каждой группы.
♦ Каждый передатчик межобластной групповой рассылки также играет роль
полномочного получателя групповой рассылки (wild-card multicast receiver).
Такие маршрутизаторы автоматически получают все дейтаграммы, генери-
руемые при групповой рассылке в этой области независимо от того, какой
группе они предназначаются. Полномочный получатель групповой рассыл-
ки при необходимости отбрасывает дейтаграмму групповой рассылки или
переправляет ее дальше. Таким образом он гарантирует, что весь трафик
групповой рассылки, возникающий в одной области, доставляется передат-
чику межобластной групповой рассылки, а затем, если это необходимо, на-
правляется в магистраль.
Рисунок 16.6 иллюстрирует ключевые концепции маршрутизации при группо-
вой рассылке между областями и между автономными системами. Если источник
дейтаграммы групповой рассылки располагается в той же области, что и маршру-
тизатор, выполняющий расчеты связующего дерева (рис. 16.6, я), то этот марш-
рутизатор должен быть уверен, что связующее дерево включает ветви подсетей
этой области с членами групп, а также ветви к каждому полномочному получате-
лю групповой рассылки в этой области. Локальный маршрутизатор не знает, ка-
кие из членов групп располагаются в других областях, поэтому он должен пользо-
ваться услугами полномочных получателей групповой рассылки.
Если источник дейтаграммы групповой рассылки и маршрутизатор, занимающий-
ся расчетами связующего дерева, располагаются в разных областях (рис. 16.6, б),
это значит, что дейтаграмма поступила в область через передатчик межобластной
групповой рассылки. В этом случае маршрутизаторы области, рассчитывающие
связующие деревья, используют передатчик межобластной групповой рассылки
в качестве корня дерева.
Групповая рассылка между автономными системами
Протокол OSPF и его расширение MOSPF функционируют в пределах автоном-
ной системы или домена объединенной сети. Детальная информация о маршрутах
не посылается за пределы автономной системы. Как мы видели, в случае целевой
рассылки для маршрутизации дейтаграмм через несколько автономных систем
требуется некий междоменный протокол маршрутизации, например BGP. Желатель-
но расширить возможности этого протокола, чтобы он мог поддерживать групповую
рассылку, и в следующем подразделе мы рассмотрим пример междоменного прото-
кола маршрутизации с поддержкой групповой рассылки, а именно протокол PIM-
518
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
(JT) S-подсеть источника Регулировщик межобластной групповой рассылки
(23) Подсеть членов группы ^J) Регулировщик межсистемной групповой рассылки
• Внутриобластной маршрутизатор Г 1 Полномочный получатель групповой рассылки
Рис. 16.6. Иллюстрация работы протокола MOSPF [204]
Хотя протокол MOSPF не несет ответственности за групповую рассылку за
пределами своей автономной системы, он отвечает за предоставление информа-
ции о группах рассылки внешним сущностям и за прием дейтаграмм групповой
рассылки, направляемых группам в его автономной системе. Таким образом, про-
токол MOSPF поддерживает групповую рассылку между автономными система-
ми следующим образом:
♦ Определенные пограничные маршрутизаторы (то есть маршрутизаторы
данной автономной системы, соседние маршрутизаторам, находящимся вне
ее) конфигурируются как передатчики межсистемной групповой рассылки
(inter-AS multicast forwarders). Помимо протоколов MOSPF и OSPF на этих
маршрутизаторах также работает межсистемный протокол маршрутизации
групповой рассылки.
♦ Протокол MOSPF гарантирует получение передатчиками межсистемной
групповой рассылки всех дейтаграмм, отправляемых при групповой рассыл-
ке источниками, находящимися в той же автономной системе. Другими ело-
16.2. Групповая рассылка
519
вами, каждый передатчик межсистемной групповой рассылки функциони-
рует как полномочный получатель групповой рассылки (см. рис. 16.6, в).
Основываясь на межсистемном протоколе маршрутизации групповой рас-
сылки, каждый такой маршрутизатор определяет, нужно или нет передавать
дейтаграмму другим автономным системам.
♦ Вспомним, что для внутренней маршрутизации групповой рассылки требу-
ется знание источника дейтаграммы. Для этой цели в протоколе MOSPF
используется прием, называемый встречной маршрутизацией (reverse-path
routing). При его применении предполагается, что дейтаграмма, отправляе-
мая при групповой рассылке источником X (находящимся за пределами
автономной системы), попадает в автономную систему протокола MOSPF
в точке, предлагающей (с помощью протокола OSPF) лучший маршрут
обратно к источнику X. Основываясь на этом предположении, протокол
MOSPF вычисляет маршрут дейтаграммы через автономную систему. Дру-
гими словами, предположим, что маршрутизатор внутри автономной системы
получает дейтаграмму, отправленную путем групповой рассылки хостом X,
расположенным за пределами автономной системы (см. рис. 16.6, г). Марш-
рутизатор сначала определяет, по какому маршруту он отправил бы дейта-
грамму хосту X (это подразумевает отправку дейтаграммы пограничному
маршрутизатору автономной системы). Затем в предположении, что эта дей-
таграмма попадает в автономную систему именно через этот пограничный
маршрутизатор, маршрутизатор решает задачу о выборе маршрута.
Протокол PIM
Большинство протоколов маршрутизации групповой рассылки обладают двумя
характеристиками:
♦ Протокол маршрутизации групповой рассылки представляет собой расши-
рение существующего протокола маршрутизации целевой рассылки, и для
его работы требуется, чтобы на маршрутизаторе был реализован протокол
маршрутизации целевой рассылки. Так, например, протокол MOSPF пред-
ставляет собой расширение протокола OSPF.
♦ В большинстве случаев протокол маршрутизации групповой рассылки пред-
назначен для эффективной работы при относительно высокой концентра-
ции членов в группах рассылки.
Использование группового расширения протокола маршрутизации целевой
рассылки приемлемо в пределах одной автономной системы, в которой, как
правило, реализован только один протокол маршрутизации целевой рассылки.
Предположение о высокой концентрации членов групп часто оказывается верным
в пределах одной автономной системы и для таких приложений, как программное
обеспечение коллективного пользования. Однако для работы в большой объ-
единенной сети или с несколькими автономными системами, а также для таких
приложений, как мультимедиа, в которых размер группы получателей может быть
относительно небольшим, а члены группы могут находиться далеко друг от друга,
требуется другой подход.
520 Глава 16. Протоколы внешней маршрутизации и групповая рассылка
---------------------------------------------------------------—.
Новый протокол, называемый протоколом PIM (Protocol Independent Multicast —
независимая от протокола групповая рассылка), предоставляет более общее реше-
ние проблемы маршрутизации при групповой рассылке. Как можно догадаться по
названию, протокол PIM не зависит от существующих протоколов маршрутиза-
ции целевой рассылки. Он предназначен для извлечения информации, необходи-
мой для маршрутизации, из любого протокола маршрутизации целевой рассылки
Протокол PIM может работать в нескольких автономных системах, поддержива-
ющих разные протоколы маршрутизации целевой рассылки.
Стратегия протокола PIM
При разработке протокола PIM учитывалось, что для решения задачи маршрути-
зации при групповой рассылке может потребоваться применение различных под-
ходов в зависимости от концентрации членов групп рассылки. Если в конфигура-
ции находится много членов групп рассылки и многие подсети конфигурации
содержат членов данной группы рассылки, тогда частый обмен информацией
о членстве в группах является оправданным. В таком окружении желательно
строить совместно используемые связующие деревья, подобные показанному на
рис. 16.3, чтобы дублирование пакета происходило как можно реже. Однако когда
членов данной группы рассылки немного и они значительно удалены друг от дру-
га, требуется другая стратегия. Во-первых, рассылка информации о группах всем
маршрутизаторам в этом случае неэффективна, так как большинство маршрути-
заторов окажутся вне путей к членам данной группы. Во-вторых, при такой ситуа-
ции будет относительно мало возможностей воспользоваться общими связующими
деревьями, и поэтому в центре внимания должно быть предоставление множества
кратчайших маршрутов для целевой рассылки.
Чтобы учесть эти требования, в протоколе PIM определено два режима рабо-
ты: плотный (dense mode) и разреженный (sparse mode). По существу, эти режимы
реализуют два отдельных протокола. Протокол плотного режима хорошо подхо-
дит для маршрутизации при групповой рассылке внутри автономных систем и
может рассматриваться как альтернатива протоколу MOSPF. Протокол разрежен-
ного режима годится для маршрутизации при групповой рассылке между автоном-
ными системами. Оставшаяся часть данного обсуждения посвящена работе про-
токола PIM в разреженном режиме1.
Разреженный режим протокола PIM
Спецификацией протокола PIM разреженная группа рассылки определена следу-
ющим образом:
♦ количество сетей/доменов, содержащих членов группы, существенно мень-
ше общего количества сетей/доменов в объединенной сети;
♦ объединенная сеть, в которой располагается группа, не обладает достаточ-
ными ресурсами, чтобы можно было игнорировать накладные расходы те-
кущей схемы маршрутизации для групповой рассылки.
1 RFC 2362, Protocol Independent Multicast — Sparse Mode, июнь 1998.
16.2. Групповая рассылка
521
Прежде чем продолжить, определим маршрутизатор группы назначения как
маршрутизатор, через который члены группы соединяются с подсетью. Маршру-
тизатор становится маршрутизатором группы назначения, когда по меньшей мере
один локальный хост связывается через него с этой группой по протоколу IGMP
или подобному ему. Маршрутизатор источника групповой рассылки — это марш-
рутизатор, присоединенный к сети, в которой есть хотя бы один хост, передающий
через этот маршрутизатор пакеты по групповому адресу. Для некоторых групп
один и тот же маршрутизатор может быть маршрутизатором источника группо-
вой рассылки и маршрутизатором группы назначения. Однако для приложений
широковещательного типа, таких как передача видео по сети, как правило, бывает
один (или немного) маршрутизатор источника групповой рассылки и множество
маршрутизаторов группы назначения.
Процедура работы протокола PIM в разреженном режиме выглядит следую-
щим образом:
1. Для группы рассылки один маршрутизатор назначается точкой встречи
(Rendezvous Point, RP).
2. Маршрутизатор группы назначения посылает маршрутизатору точки встречи
(RP-маршрутизатору) сообщение о привязке, требуя добавить своих членов
в группу рассылки. Это сообщение маршрутизатор отправляет по кратчай-
шему с позиций целевой рассылки пути к RP-маршрутизатору. Обратный
путь становится частью дерева распределения от точки встречи к членам
группы рассылки.
3. Любой узел, желающий передавать пакеты группе рассылки, отправляет их
RP-маршрутизатору по кратчайшему с позиций целевой рассылки пути.
Передача данных по описанной выше схеме выполняется следующим образом.
Отдельный пакет следует по кратчайшему с позиций целевой рассылки пути от
передающего узла до RP-маршрутизатора. От RP-маршрутизатора передача осу-
ществляется вниз по дереву слушателям, при этом каждый пакет реплицируется
на каждом ветвлении дерева. Использование такой схемы позволяет минимизи-
ровать объем маршрутной информации, которой обмениваются узлы, поскольку
эта информация передается только от маршрутизаторов, поддерживающих членов
группы, к RP-маршрутизатору. Эта схема обеспечивает разумную эффективность,
в частности, для передачи пакетов от RP-маршрутизатора к адресатам групповой
рассылки используется общее дерево, что минимизирует количество дублируемых
пакетов.
В сильно разреженной группе любая точка встречи находится далеко от мно-
гих членов группы, и пути ко многим членам группы оказываются значительно
длиннее путей с наименьшей стоимостью. Чтобы справится с этими проблемами,
не теряя достоинств схемы PIM, протокол PIM позволяет маршрутизатору груп-
пы назначения заменять общее для группы дерево деревом кратчайшего пути для
каждого источника групповой рассылки. Когда маршрутизатор назначения полу-
чает пакет, он может по кратчайшему (с позиций целевой рассылки) пути от-
править сообщение о привязке обратно маршрутизатору источника этого пакета.
С этого момента пакеты, пересылаемые путем групповой рассылки из этого источ-
522
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
ника всем членам данной группы (эти члены являются соседними для маршрути-
затора назначения), следуют по кратчайшему с позиций целевой рассылки пути
Рисунок 16.7 иллюстрирует последовательность событий (маршрутизаторы
обозначены символом R, а RP-маршрутизатор — символами RP). Когда получа-
тель начинает принимать пакеты от источника через маршрутизатор, принадле-
жащий кратчайшему пути, он посылает RP-маршрутизатору сообщение об отсечении
источника, которое велит RP-маршрутизатору больше не передавать пакеты груп-
повой рассылки отданного источника данному получателю. Получатель будет про-
должать принимать пакеты групповой рассылки от других источников по дереву
с корнем в точке встречи (в RP-маршрутизаторе), пока он не отсечет и эти источники
Любой маршрутизатор источника групповой рассылки должен продолжать посы-
лать пакеты RP-маршрутизатору для доставки другим членам группы рассылки.
Управляющее
сообщение
Маршрутизатор R1 посыпает сообщение
о привязке RP-маршрутизатору;
RP-маршрутизатор добавляет
путь к дереву распределения
Управляющее
сообщение
Маршрутизатор R2 отправляет
RP-маршрутизатору сообщение
о регистрации; RP-маршрутизатор
возвращает сообщение о привязке;
маршрутизатор R2 строит путь
к RP-маршрутизатору
Маршрутизатор R1 отправляет
маршрутизатору R2 сообщение
о привязке; маршрутизатор R2
отсекает путь к RP-маршрутизатору
Маршрутизатор-Р6 отправляет
RP-маршрутизатору сообщение
об отсечении; RP-маршрутизатор
отсекает путь к маршрутизатору R1
Рис. 16.7. Пример работы протокола PIM
16.4. Задания
523
Выбор точки встречи (RP-маршрутизатора) для данной группы рассылки пред-
ставляет собой динамический процесс. Инициатор образования группы рассылки
выбирает первичный RP-маршрутизатор и небольшой упорядоченный набор аль-
тернативных RP-маршрутизаторов. В любом случае замена RP-маршрутизатора
не является критически важной, так как дерево с корнем в RP-маршрутизаторе
перестанет использоваться для большинства получателей с того момента, когда
данные начнут поступать через маршрутизаторы, находящиеся на кратчайших путях.
16.3. Рекомендуемые литература
и веб-сайты
В [192] содержится всеобъемлющее обсуждение алгоритмов маршрутизации для
групповой рассылки, а также обзор протоколов такой маршрутизации. [68] пред-
ставляет собой конструктивную статью, в которой описывается общий подход
и большинство используемых сегодня механизмов групповой рассылки в объ-
единенных сетях. В [5] сообщается о разработке протоколов групповой рассылки
и рассматриваются перспективы их развития. [184] представляет собой детальное
и исчерпывающее обозрение протоколов маршрутизации для групповой рассылки.
Большая часть ссылок на литературу, упоминавшуюся в главе 15, также годит-
ся для протоколов BGP и IDRP. Дополнительную информацию по протоколу IDRP
можно получить в [188].
В [157] описывается философия и общий подход, применяемый в протоколе
MOSPF. В [118] предоставляется обзор обоих режимов работы протокола PIM.
В [69] детально обсуждается разреженный режим протокола PIM.
Рекомендуемый веб-сайт — IP Multicast Initiative. Это сайт группы, производя-
щей самое разнообразное оборудование. Он посвящен групповой рассылке при
помощи протокола IP и включает технические документы, коммерческую инфор-
мацию, сведения о продуктах, а также информацию о состоянии дел в области
стандартизации.
16.4. Задания
1. Стандарт протокола IGMP указывает, что сообщения с запросами посыла-
ются в IP-дейтаграммах, у которых значение поля времени жизни установ-
лено равным 1. Почему?
2. При обсуждении рис. 16.2 упоминалось о трех альтернативных способах пере-
дачи пакета группе получателей: широковещательная рассылка, множествен-
ная целевая рассылка и «истинная» групповая рассылка. Еще одна альтер-
натива представляет собой лавинную маршрутизацию. Источник передает
по одному пакету всем соседним маршрутизаторам. Каждый маршрутизатор,
получив пакет, передает его по всем исходящим линиям, кроме той, по кото-
рой он этот пакет получил. Каждый пакет помечается уникальным иденти-
фикатором, так что маршрутизатор не пересылает дважды один и тот же пакет.
Заполните таблицу, подобную табл. 16.1, и прокомментируйте результат.
524
Глава 16. Протоколы внешней маршрутизации и групповая рассылка
3. На рис. 16.4 показано связующее дерево от маршрутизатора С до группы
рассылки. Нарисуйте аналогичное связующее дерево от маршрутизатора В
4. Большинство протоколов маршрутизации групповой рассылки, например
MOSPF, минимизируют стоимость пути до каждого члена группы, но не
обязательно оптимизируют использование объединенной сети в целом.
а) суммируйте стоимость ретрансляционных участков, преодолеваемых
каждым пакетом, в случае групповой рассылки с использованием пред-
ставленного на рис. 16.3, а связующего дерева;
б) постройте альтернативное связующее дерево, минимизирующее суммар-
ную стоимость. Покажите дерево и суммарную стоимость.
5. Объясните, почему протокол MOSPF неэффективен для разреженного ре-
жима групповой рассылки.
6. «При работе протокола Р1М в разреженном режиме для маршрута от дан-
ного источника к данному получателю дерево с корнем в RP-маршрутиза-
торе может быть заменено кратчайшим с позиций целевой рассылки путем
от источника к получателю». Что неверно в данном утверждении?
7. Некоторые исследователи утверждают, что оптимальное размещение корня
совместно используемого дерева (то есть точки встречи в протоколе PIM)
является критически важным для достижения приемлемых характеристик
задержки трафика групповой рассылки. Приведите аргументы за или про-
тив этого утверждения.
Часть VI
Качество обслуживания
в IP-сетях
Потребности в объединенных IP-сетях растут, и это касается как объемов, так
и типов служб. Изначально эти сети, для которых использовались линии с отно-
сительно низкой пропускной способностью, поддерживали достаточно скромные
запросы и предназначались для приложений, в определенной степени нечувстви-
тельных к задержкам, изменениям пропускной способности и потере пакетов. Се-
годня от объединенных IP-сетей требуется передача больших объемов данных по
высокоскоростным линиям связи, а также обслуживание приложений реального
(или почти реального) времени, чувствительных к задержкам, изменениям про-
пускной способности и потере пакетов. Ключевые требования к объединенным
IP-сетям перечислены далее.
♦ Борьба с перегрузкой. Перегрузка опасна для любой коммутируемой сети.
Именно перегрузка не позволяет сети удовлетворять запросы трафика. Если
не бороться с перегрузкой, буферы коммутаторов или маршрутизаторов пере-
полнятся и пакеты начнут отбрасываться. Для приложений, допускающих
потерю пакетов, отбрасывание пакета означает, что пакет придется переда-
вать повторно, что усугубит перегрузку. Для приложений, не допускающих
потери пакетов, это означает снижение качества обслуживания.
♦ Снижение задержек. Задержки минимизируются, когда отсутствует пере-
грузка и невелики размеры очередей. Однако для многих приложений ко-
эффициент использования сети должен быть относительно высоким. Это
предполагает, по меньшей мере, определенную степень перегрузки и, следо-
вательно, некоторую задержку.
♦ Обеспечение высокой пропускной способности. Высокая пропускная способ-
ность может быть достигнута путем резервирования ресурсов. Однако для
эффективного использования сети необходимо применять статистическое
мультиплексирование, до определенной степени конфликтующее с требо-
ванием высокой пропускной способности.
4- Поддержание качества обслуживания. Для предоставления различным по-
токам данных разных уровней качества обслуживания требуется разумное
дифференцирование пакетов при их перемещении по сети.
526
Часть VI. Качество обслуживания в 1Р-сетях
4- Справедливое обслуживание. Еще одним требованием является справедли-
вость. В общих словах, справедливость означает предоставление приблизи-
тельно одинаковых ресурсов конкурирующим потокам данных с одним и
тем же уровнем качества обслуживания.
В часть VI включены две главы.
♦ Глава 17. Интегрированные и дифференцированные службы. До относи-
тельно недавнего времени управление трафиком IP-маршру газаторами за-
ключалось в отбрасывании пакетов при переполнении буферов. При этом
разбираться с результатами должно было программное обеспечение око-
нечных систем, в основном протокол TCP. В ответ на новые требования,
предъявляемые объединенным IP-сетям, разрабатываются новые сложные
механизмы и протоколы. В новых протоколах удалось реализовать две взаи-
модополняющие структуры управления трафиком: интегрированные служ-
бы и дифференцированные службы. В этой главе также обсуждаются два
важных управляющих механизма: дисциплина очередей и стратегия отбра-
сывания пакетов.
♦ Глава 18. Протоколы поддержания качества обслуживания. В главе 18 изу-
чаются три важных подхода к проблеме обеспечения требуемого уровня
качества обслуживания в объединенных сетях. Глава начинается с обсуж-
дения протокола RSVP, разработанного для поддержки архитектуры интег-
рированных служб путем резервирования ресурсов в дейтаграммном окру-
жении. Затем описывается протокол MPLS, обеспечивающий возможность
пометки трафика и благодаря этому дифференцированную маршрутизацию
потоков трафика. Главу завершает обсуждение протокола RTP, призванно-
го поддерживать приложения реального времени на транспортном уровне.
Глава 17
Интегрированные
и дифференцированные
службы
Таким образом, система управления должна быть на-
столько гибкой, чтобы дело можно было распылить над
океаном, сконцентрировать вдоль определенных марш-
рутов или в одних местах распылить, а в других скон-
центрировать; причем так, чтобы в любой момент при
необходимости можно было перейти от одной полити-
ки к другой.
Уинстон Черчилль. Мировой кризис
По мере роста Интернета и частных объединенных сетей на передний план выхо-
дит множество новых требований. На смену протоколу TELNET, обслуживающе-
му обмен данными небольшого объема, пришли приложения клиент-сервер с вы-
соким уровнем трафика. Позднее к этому трафику добавились огромные объемы
веб-трафика, все в большей степени включающего в себя графику. Сегодня свой
вклад в нагрузку вносят такие приложения реального времени, как передача видео-
и аудиоданных.
Для удовлетворения новых требований недостаточно просто увеличить пропуск-
ную способность объединенных сетей. Необходимы чувствительные и эффектив-
ные методы управления трафиком и борьбы с перегрузкой. Этой теме посвящена
данная глава. В последние годы группой IETF были разработаны два новых стан-
дарта, представляющих собой взаимодополняющие структуры управления трафи-
ком: интегрированные службы (Integrated Services, IS) и дифференцированные
службы (Differentiated Services, DS).
По существу, структура интегрированных служб для удовлетворения требова-
ний трафика призвана предоставлять интегрированные, или коллективные, услу-
ги в данном домене (то есть части Интернета, в которой реализован определенный
экземпляр архитектуры интегрированных служб). Поставщиком интегрированных
услуг можно считать сетевые элементы внутри домена. Поставщик интегрирован-
ных услуг изучает суммарные требования трафика и, во-первых, ограничивает
поддерживаемый трафик объемами, соответствующими текущим возможностям
528
Глава 17. Интегрированные и дифференцированные службы
сети, во-вторых, резервирует ресурсы домена для предоставления определенного
уровня качества обслуживания в соответствии с конкретными требованиями.
Структура дифференцированных служб, напротив, не пытается рассматри-
вать суммарные запросы трафика в каком-либо глобальном, или интегрированном
смысле, а также не пытается заранее резервировать сетевые ресурсы. Вместо этого
в структуре дифференцированных служб трафик классифицируется по группам
Каждая группа соответствующим образом помечается, а услуга, предоставляемая
сетевыми элементами, зависит от членства в той или иной группе, при этом отно-
сящиеся к разным группам пакеты обслуживаются по-разному.
Глава начинается с обсуждения архитектуры ISA (Integrated Services Archi-
tecture — архитектура интегрированных служб), представляющей собой определен-
ную структуру, в пределах которой предоставляются интегрированные услуги.
Затем в терминах дисциплины очередей и политики отбрасывания пакетов в этой
главе рассматриваются механизмы резервирования важных ресурсов и борьбы с пе-
регрузкой, которые могут быть встроены в архитектуру интегрированных служб.
17.1. Архитектура интегрированных служб
Исторически объединенные IP-сети могли предоставлять всем приложениям, тра-
фик которых они переносили, простую услугу по доставке пакетов с максималь-
ными усилиями (то есть по остаточному принципу). Хотя заголовок протокола
IPv4 содержит поля, с помощью которых можно указать уровень приоритета и тип
услуги, как правило, эта информация игнорируется маршрутизаторами как при
выборе маршрутов, так и при обработке отдельных пакетов.
Но нужды пользователей изменились. Компания может затратить милли-
оны долларов на установку объединенной IP-сети, предназначенной для передачи
данных между локальными сетями, и неожиданно обнаружить, что новые муль-
тимедийные приложения, приложения групповой рассылки или приложения ре-
ального времени недостаточно хорошо поддерживаются такой конфигурацией.
Единственной сетевой схемой, с первого дня предназначенной для поддержки как
традиционного TCP- и UDP-трафика, так и трафика реального времени, является
сеть ATM. Однако установка сети ATM означает либо создание второй инфра-
структуры для трафика реального времени, либо замену существующей IP-кон-
фигурации ATM-структурой, при этом для реализации обоих вариантов требуют-
ся большие финансовые затраты.
Таким образом, в архитектуре TCP/IP существует необходимость в поддержа-
нии разных видов трафика с разными уровнями качества обслуживания. Однако
основное требование заключается в добавлении маршрутизаторам новой функци-
ональности и получении информации о запрашиваемом уровне качества обслужи-
вания непосредственно из объединенных сетей. Б рамках удовлетворения всех
этих требований группа IETF занимается разработкой набора стандартов под
общим названием Integrated Services Architecture (архитектура интегрирован-
ных служб). Эта архитектура предназначена для предоставления в объединенных
IP-сетях транспортной службы с гарантированным уровнем качества обслужива-
17.1. Архитектура интегрированных служб
529
ния. Архитектура ISA в общих чертах определена в RFC 1633', тогда как детали
уточняются в других документах. Отдельные фрагменты архитектуры интегриро-
ванных служб реализованы несколькими производителями в программном обес-
печении маршрутизаторов и оконечных систем.
В этом разделе предоставляется обзор архитектуры интегрированных служб.
Трафик в объединенных сетях
Трафик в обычной или объединенной сети можно разделить на две большие катего-
рии: эластичный и неэластичный. Понимание различий между этими категориями
проясняет необходимость в усовершенствованной архитектуре объединенных сетей.
Эластичный трафик
Эластичным (elastic) называют трафик, способный приспосабливаться к измене-
ниям задержки и пропускной способности в широком диапазоне значений, про-
должая удовлетворять потребности приложения. Это традиционный тип трафи-
ка, поддерживаемый IP-сетями, и именно для такого трафика разрабатывались
объединенные сети. Приложения, создающие подобный трафик, в качестве транс-
портного протокола, как правило, используют протокол TCP или UDP. В случае
протокола UDP приложение расходует столько ресурсов, сколько имеется в нали-
чии, вплоть до скорости, с которой приложение генерирует данные. В случае про-
токола TCP приложение расходует столько ресурсов, сколько имеется в наличии,
вплоть до максимальной скорости, с которой оконечный получатель способен при-
нимать данные. Кроме того, при использовании протокола TCP трафик, передава-
емый по отдельным соединениям, реагирует на перегрузку снижением скорости
передачи данных в сеть. Для этого включаются описывавшиеся в разделе 12.2 меха-
низмы отката и затяжного пуска, связанные с задержкой RTT (Round-Trip Time —
время распространения сигнала в оба конца).
К эластичным приложениям относятся обычные приложения, работающие
с помощью протоколов TCP и UDP, включая передачу файлов (FTP), электрон-
ную почту (SMTP), удаленную регистрацию (TELNET), управление сетью (SNMP)
и доступ к Паутине (HTTP). Требования, предъявляемые данными приложения-
ми, различаются.
♦ Электронная почта, как правило, нечувствительна к изменениям задержки.
♦ Когда передача файлов осуществляется в режиме подключения (on-line),
как это обычно бывает, пользователь ожидает, что задержка будет пропор-
циональна размеру файла, то есть передача файлов чувствительна к скорос-
ти передачи данных.
4- При управлении сетью задержка, как правило, не представляет серьезной
проблемы. Однако если неисправности в объединенной сети являются при-
чиной перегрузки, тогда необходимость в прохождении сообщений прото-
кола SNMP с минимальной задержкой с ростом перегрузки растет.
4- Интерактивные приложения, такие как удаленная регистрация и доступ к
Паутине, обладают высокой чувствительностью к задержке.
1 RFC 1633, Integrated Services in the Internet Architecture: An Overview, июль 1994.
530
Глава 17. Интегрированные и дифференцированные службы
Важно понимать, что особый интерес представляет не задержка отдельных па-
кетов. Как отмечается в [53], наблюдения за реальной задержкой в Интернете на-
водят на мысль о том, что изменений задержки в широком диапазоне не происхо-
дит. Благодаря механизмам борьбы с перегрузкой, реализованным в протоколе
TCP, когда возникает перегрузка, происходит только умеренное увеличение задерж-
ки, после чего скорость поступления данных от различных TCP-соединений снижа-
ется. С точки зрения пользователя уровень качества обслуживания определяется не
величиной задержки отдельного пакета, а суммарным интервалом времени, необхо-
димым для передачи элемента данного приложения. Для интерактивного TELNET-
приложения элементом может быть отдельный символ или одна текстовая строка.
Для веб-браузера элементом является веб-страница, размеры которой могут изме-
няться в очень широких пределах от нескольких килобайтов до нескольких десят-
ков и сотен килобайтов для страниц с большим количеством графики. В научных
приложениях один элемент может состоять из нескольких мегабайтов данных.
Для очень маленьких элементов суммарное время передачи данных в основном
состоит из длительности задержки передачи данных по объединенной сети. Одпа-
ко для больших элементов суммарное время передачи данных зависит от про-
изводительности алгоритма скользящего окна протокола TCP и, следовательно,
в основном определяется пропускной способностью ТCP-соединения. Таким об-
разом, при передаче больших объемов данных время передачи пропорционально
размеру файла и степени торможения источника из-за перегрузки.
Должно быть ясно, что даже если ограничиваться только эластичным трафи-
ком, нам была бы весьма полезна какая-нибудь служба поддержания качества об-
служивания в объединенной сети. Без такой службы маршрутизаторы одинаково
относятся к прибывающим пакетам, не учитывая ни тип приложения, ни то, явля-
ется ли данный пакет частью большого элемента приложения или маленького. При
таких условиях в случае перегрузки маловероятно, что ресурсы будут распределе-
ны так, чтобы справедливо удовлетворить потребности приложений. А когда к эла-
стичному трафику добавляется неэластичный, ситуация еще более усложняется.
Неэластичный трафик
Неэластичный трафик (inelastic traffic) плохо приспосабливается, если вообще
способен приспосабливаться, к изменениям задержки и пропускной способности
объединенной сети. Примером неэластичного трафика является трафик реального
времени, обсуждающийся в разделе 17.5. Неэластичный трафик предъявляет к объ-
единенной сети различные требования, среди которых можно назвать следующие:
4- Пропускная способность. Может быть предъявлено требование обеспечения
некоторой минимальной пропускной способности. В отличие от большей
части приложений эластичного трафика, способных продолжать доставку
данных, возможно, со сниженным уровнем качества обслуживания, многим
неэластичным приложениям абсолютно необходим определенный минимум
пропускной способности.
♦ Задержка. В качестве примера приложения, чувствительного к задержкам,
можно назвать игру на бирже. Пользователь, постоянно получающий инфор-
мацию с задержкой, будет постоянно запаздывать в своих действиях, и, сле-
довательно, его действия будут менее успешными.
17.1. Архитектура интегрированных служб
531
♦ Флуктуация. Как разъясняется в разделе 17.5, диапазон изменений задерж-
ки критически важен для приложений реального времени. Чем больше допу-
стимое изменение задержки, тем больше будет реальная задержка доставки
данных и тем больших размеров потребуются буферы получателей. Инте-
рактивные приложения реального времени, такие как телеконференции,
могут требовать разумных ограничений на флуктуацию.
4 Потеря пакетов. Некоторые приложения реального времени допускают
потерю пакетов. Допустимое количество потерянных пакетов может быть
разным для разных приложений.
Эти требования трудновыполнимы в окружении, в котором имеют место вызван-
ная очередями переменная задержка и потеря пакетов из-за перегрузки. Соответ-
ственно, неэластичный трафик предъявляет два новых требования к архитектуре
объединенных сетей. Во-первых, необходимы определенные средства для предос-
тавления предпочтений приложениям с более высокими пожеланиями. Приложе-
ние должно иметь возможность заявить о своих пожеланиях либо заранее, с помо-
щью некоторой функции, запрашивающей нужную услугу, либо «на лету», при
помощи полей в заголовке IP-пакета. Первый подход предпочтительнее. Он пре-
доставляет большую гибкость в пожеланиях, позволяя сети заранее о них узнавать
и отказывать в обслуживании, если требуемые ресурсы недоступны. Этот подход
предполагает наличие некоторого протокола резервирования ресурсов.
Второе требование, относящееся к поддержке неэластичного трафика в архи-
тектуре объединенных сетей, заключается в том, что эластичный трафик также
должен поддерживаться. В отличие от TCP-приложений, неэластичные приложе-
ния, как правило, не снижают требований в случае перегрузки. Поэтому при пере-
грузке неэластичный трафик будет продолжать оказывать высокое давление на
объединенную сеть, и эластичный трафик окажется просто вытесненным. Про-
токол резервирования ресурсов может помочь справиться с ситуацией, отказывая
в обслуживании запросов, если в случае их обслуживания в объединенной сети
останется слишком мало ресурсов для эластичного трафика.
Назначение архитектуры ISA
Назначение архитектуры ISA заключается в поддержании разных уровней каче-
ства обслуживания в объединенных IP-сетях. Центральный вопрос разработки
архитектуры ISA состоит в том, как совместно использовать доступные ресурсы
в периоды перегрузки.
В объединенных IP-сетях, выполняющих обслуживание по остаточному прин-
ципу, набор средств борьбы с перегрузкой и предоставления услуг ограничен. По
существу, у маршрутизаторов есть два инструмента.
4 Алгоритм маршрутгаации. Большинство протоколов маршрутизации, приме-
няемых в объединенных сетях, позволяют маршрутизаторам выбирать мар-
шруты с минимальной задержкой. Маршрутизаторы обмениваются инфор-
мацией, чтобы получить представление о задержках в объединенной сети.
Маршрутизация с минимизацией задержки позволяет балансировать на-
грузку, тем самым снижая локальные перегрузки и задержки в отдельных
Т СР-соединениях.
532
Глава 17. Интегрированные и дифференцированные службы
♦ Отбрасывание пакетов. Когда буфер маршрутизатора переполняется, маршру-
тизатор отбрасывает пакет. В результате передающая ТСР-сущность снижа-
ет скорость передачи, помогая устранить перегрузку в объединенной сети.
Ранее эти средства достаточно хорошо справлялись со своими задачами, осо-
бенно в случае применения усовершенствований методов борьбы с перегрузкой
описанных в разделе 12.2. Однако, как было показано ранее, они неадекватны но-
вым разновидностям трафика в объединенных сетях.
Архитектура интегрированных служб (ISA) представляет собой глобальную
архитектуру, в рамках которой разрабатывается ряд усовершенствований тради-
ционных механизмов обслуживания по остаточному принципу. В архитектуре ISA
каждый IP-пакет может быть ассоциирован с потоком. В RFC 1633 поток опреде-
ляется как распознаваемая цепочка взаимосвязанных IP-пакетов, вызванных дей-
ствиями одного пользователя, для которых требуется один и тот же уровень каче-
ства обслуживания. Например, поток может состоять из одного транспортного
соединения или одного потока видеоданных, распознаваемого архитектурой ISA.
Поток отличается от TCP-соединения двумя ключевыми особенностями. Во-пер-
вых, поток является однонаправленным, во-вторых, у потока может быть несколь-
ко получателей (группа рассылки). Как правило, IP-пакет идентифицируется как
экземпляр потока по IP-адресам отправителя и получателя и номерам портов, а
также по типу протокола. Идентификатор потока в заголовке IPv6 не обязательно
однозначно соответствует потоку ISA, по в будущем идентификатор потока IPv6
может использоваться в архитектуре ISA.
Ниже перечислены некоторые функции архитектуры ISA, ориентированные на
борьбу с перегрузкой и предоставление транспортных услуг с различными уров-
нями качества:
♦ Контроль допуска. Для транспорта с гарантированным уровнем качества
обслуживания (в отличие от транспорта, обслуживаемого по остаточному
принципу) архитектура ISA требует резервирования ресурсов для нового
потока. Если маршрутизаторы совместно придут к соглашению о недоста-
точности ресурсов для гарантий запрашиваемого уровня качества обслужи-
вания, тогда потоку отказывается в доступе. Для резервирования ресурсов
используется протокол RSVP, обсуждаемый в главе 18.
+ Алгоритм маршрутизации. Решение о выборе маршрута может принимать-
ся на основе различных параметров качества обслуживания, а не только ми-
нимального значения задержки. Например, протокол маршрутизации OSPF
(см. главу 15) может выбирать маршруты, основываясь на параметрах каче-
ства обслуживания.
♦ Дисциплина очередей. Жизненно важным элементом архитектуры интегри-
рованных служб является эффективная политика очередей, учитывающая
различающиеся требования различных потоков. Политика очередей обсуж-
дается в разделе 17.2.
♦ Политика отбрасывания пакетов. Политика очередей определяет, какой
пакет будет передан следующим, если несколько пакетов стоят в очереди к
одному и тому же выходному порту. Отдельным вопросом является выбор
отбрасываемого пакета. Политика отбрасывания пакетов может быть важ-
ным элементом борьбы с перегрузкой и обеспечения гарантий качества об-
служивания. Политика отбрасывания пакетов обсуждается в разделе 17.3.
17.1. Архитектура интегрированных служб
533
Компоненты архитектуры ISA
На рис. 17.1 показана общая схема реализации архитектуры ISA на маршрутиза-
торе. Нод жирной горизонтальной линией располагаются функции продвижения
данных маршрутизатора. Эти функции выполняются для каждого пакета, и поэто-
му они должны быть тщательно оптимизированы. Остальные функции (выше ли-
нии) являются вспомогательными и формируют структуры данных, используемые
функциями продвижения данных.
Протокол
резервирования
Протокол(ы)
Щ маршрутизации
Ж *
»
I р I
Очередь QOS
'X -
а
Очередь
«по остаточному
принципу»
Управляющий
агент
->
л <
•V «и
Ж
Классификация у j
и выбор --------\
маршрута | Я
л, В Л * г
Контроль
доступа
| Я
;%; База данных
Ц маршрутизации V..
База данных
управления
трафиком
О Планирование И,
пакетов
1
г': t
Рис. 17.1. Архитектура интегрированных служб ISA, реализованная на маршрутизаторе
Ниже перечислены принципиально вспомогательные функции:
♦ Протокол резервирования. Этот протокол используется между маршрутиза-
торами и между маршрутизаторами и оконечными системами в целях ре-
зервирования ресурсов для нового потока и данного уровня качества обслу-
живания. Протокол резервирования отвечает за поддержку данных потока
на оконечных системах и на маршрутизаторах вдоль пути следования пото-
ка. Для этой цели применяется протокол RSVP, обсуждаемый в главе 18.
Протокол резервирования обновляет базу данных управления трафиком,
используемую функцией планирования пакетов для определения услуг, пре-
доставляемых пакетам каждого потока.
♦ Контроль доступа. Когда запрашивается новый поток, протокол резервиро-
вания вызывает функцию контроля доступа. Эта функция определяет, дос-
таточно ли имеется ресурсов для нового потока с запрашиваемым уровнем
качества обслуживания. Принятие решения основывается на текущем уров-
не обязательств по отношению к другим потокам и/или на текущем уровне
нагрузки в сети.
♦ Управляющий агент. Сетевой управляющий агент способен модифициро-
вать базу данных управления трафиком и управлять модулем контроля до-
ступа в соответствии с политикой контроля доступа.
534
Глава 17. Интегрированные и дифференцированные службы
4- Протокол маршрутизации. Протокол маршрутизации отвечает за поддержа-
ние базы данных маршрутизации, в которой для каждого адреса получателя
и каждого потока содержатся данные о следующем ретрансляционном участке
Эти вспомогательные функции поддерживают основную задачу маршрутиза-
ции, заключающуюся в продвижении пакетов. Следующие две принципиально
основные функции осуществляют продвижение пакетов:
♦ Классификация и выбор маршрута. В целях продвижения пакетов и управ-
ления трафиком входящие пакеты должны классифицироваться. Класс мо-
жет соответствовать отдельному потоку или набору потоков с одинаковы-
ми требованиями к качеству обслуживания. Например, пакеты всех потоков
с видеоданными или все потоки, относящиеся к одной организации, могут
обрабатываться одинаково в плане распределения ресурсов и дисциплины
очередей. Выбор класса основывается на полях в заголовках IP-пактов. Зная
класс пакета и IP-адрес получателя, функция классификации и выбора мар-
шрута определяет адрес следующего ретрансляционного участка для этого
пакета.
4 Планирование пакетов. Функция планирования пакетов управляет одной
или несколькими очередями для каждого выходного порта. Она определяет
порядок, в котором передаются стоящие в очереди пакеты, а также, при не-
обходимости, выбирает пакеты, выбрасываемые из очереди. Решения при-
нимаются на основе класса пакета, содержимого базы данных управления
трафиком, а также текущей и прошлой активности этого выходного порта.
Часть задачи планирования пакетов заключается в проведении политики,
определяющей, превышает ли трафик пакетов данного потока запрошенный
уровень пропускной способности, и, если превышает, решающей, как посту-
пить с лишними пакетами.
Службы архитектуры ISA
Службы ISA для потока пакетов определены на двух уровнях. Во-первых, служ-
бы предоставляют ряд общих категорий обслуживания, каждая из которых обес-
печивает определенный обобщенный тип гарантий обслуживания. Во-вторых,
в каждой категории обслуживание конкретного потока определяется заданными
параметрами. Вместе эти параметры называются спецификацией трафика (Traffic
SPECification, TSpec). На сегодняшний день определены три категории обслу-
живания:
♦ гарантированное обслуживание;
♦ обслуживание с контролируемой нагрузкой;
♦ обслуживание с максимальными усилиями (то есть по остаточному прин-
ципу).
Приложение может потребовать зарезервировать для потока ресурсы для его
обслуживания с гарантированным или контролируемым уровнем качества. При
этом точные параметры требуемого обслуживания указываются в спецификацШ^
i
17.1. Архитектура интегрированных служб
535
трафика. Если запрос на резервирование принимается, тогда спецификация тра-
фика становится частью договора между потоком данных и службой. Служба со-
глашается предоставлять обслуживание с запрашиваемым уровнем качества до тех
пор, пока поток данных соответствует спецификации трафика. Пакетам, превы-
шающим параметры, указанные в спецификации трафика, по умолчанию предос-
тавляется обслуживание по остаточному принципу.
Прежде чем перейти к рассмотрению категорий служб архитектуры ISA, сле-
дует определить одну общую концепцию: спецификацию трафика маркерного вед-
ра (token bucket). В контексте архитектуры интегрированных служб этот способ
описания трафика обладает тремя преимуществами:
♦ Большое количество источников трафика могут быть просто и точно описа-
ны с помощью схемы маркерного ведра.
♦ Схема маркерного ведра предоставляет лаконичное описание нагрузки,
оказываемой потоком, позволяя службе легко определить требуемый объем
ресурсов.
♦ Схема маркерного ведра предоставляет входные параметры для функции
регулирования.
Спецификация трафика маркерного ведра включает два параметра: скорость
пополнения маркеров 2? и объем ведра В. Значение R определяет постоянную, уста-
новившуюся скорость передачи данных, то есть усредненную за относительно дол-
гий период времени. Значение В определяет величину, на которую скорость переда-
чи данных может превышать R в течение короткого интервала времени. В результате
в течение любого интервала времени Т количество переданных данных не может
превышать RT + В.
На рис. 17.2 показана данная схема и разъясняется использование термина вед-
ро (bucket). Этим термином называют счетчик, указывающий количество байтов
IP-данных, которые могут быть переданы в любой момент времени. Ведро запол-
няется байтовыми маркерами (octet tokens) со скоростью R (то есть счетчик уве-
личивается на единицу R раз в секунду). Содержимое счетчика не может превы-
шать определенного максимального значения, соответствующего объему ведра В.
IP-пакеты прибывают и устанавливаются в очередь на обработку. IP-пакет может
быть обработай, если в ведре есть достаточное количество маркеров (не менее раз-
мера IP-пакета). Если маркеров в ведре достаточно, пакет обрабатывается, а соот-
ветствующее количество маркеров вытекает из ведра. Если пакет прибывает, а в
ведре нет достаточного количества маркеров, то это значит, что данный пакет пре-
высил параметры спецификации трафика для данного потока. Что делать с таким
пакетом, в документации архитектуры ISA не указывается. Обычно подобный па-
кет либо обслуживается по остаточному принципу (при наличии ресурсов), либо
отбрасывается, либо особым образом помечается, чтобы его можно было отбросить
позднее.
Средняя скорость передачи IP-данных, разрешенная маркерным ведром, рав-
на R. Однако если возникает период простоя или период относительно низкой ско-
рости поступления данных, ведро наполняется маркерами, что позволяет передать
дополнительно до В байт сверх установленной скорости. Таким образом, объем
ведра В представляет собой меру допустимой неравномерности потока данных.
536
Глава 17. Интегрированные и дифференцированные службы
Скорость маркеров составляет
R IP-байт в секунду
Размер ведра
составляет В байт
Поступающие.
данные
Рис. 17.2. Схема маркерного ведра
Отправляемые
данные
Гарантированное обслуживание
Ниже перечислены ключевые характеристики гарантированного обслуживания:
♦ Поддерживается гарантированный уровень пропускной способности или
гарантированная скорость передачи данных.
4- Определен верхний предел величины задержек пакетов в очередях. Эта ве-
личина, сложенная с задержкой распространения, дает суммарную верхнюю
границу задержки прохождения данных через сеть.
4- Нет потерь в очередях. То есть ни один пакет не теряется из-за переполне-
ния буфера. Пакеты могут теряться только из-за неисправностей в сети или
изменений в маршрутах.
Этот класс обслуживания предназначен для приложений, которым необходи-
ма верхняя граница задержки, например для приложений, использующих входной
буфер для накапливания и воспроизведения в режиме реального времени поступа-
ющих данных, не допускающих потери пакетов, так как потеря данных приводит
к снижению качества воспроизведения на выходе. Среди других примеров можно
назвать приложения реального времени с жесткими ограничениями на задержку.
Гарантированное обслуживание предоставляется наиболее требовательной
службой в архитектуре ISA. Поскольку задержка жестко ограничена, значение верх-
ней границы задержки следует устанавливать довольно высоко, чтобы редкие
случаи больших задержек в очередях не выходили за допустимые пределы.
Контролируемая нагрузка
Ниже перечислены ключевые характеристики обслуживания с контролируемой
нагрузкой:
♦ Обслуживание с контролируемой нагрузкой очень напоминает обслужива-
ние с максимальными усилиями в условиях низкой загруженности сети.
17.2. Дисциплина очередей
537
♦ Не существует указанного верхнего предела задержек в очередях. Однако
гарантируется, что очень большой процент пакетов пройдет без задержек,
значительно превышающих минимальную задержку прохождения данных
по сети (то есть задержку, складывающуюся из времени распространения
сигнала по сети и времени обработки пакетов на маршрутизаторе без потерь
времени на ожидание в очередях).
4- Очень большой процент передаваемых пакетов будет успешно доставлен (то
есть потери в очередях почти отсутствуют).
Как уже упоминалось, в объединенной сети, предоставляющей приложени-
ям реального времени гарантии качества обслуживания, существует риск вы-
теснения из сети трафика, обслуживаемого по остаточному принципу. Это связа-
но с тем, что приложения, обслуживаемые по остаточному принципу, используют
протокол TCP, снижающий скорость передачи данных при возникновении пе-
регрузки и увеличении задержек. При обслуживании с контролируемой нагруз-
кой гарантируется, что сеть зарезервирует достаточно ресурсов для того, чтобы
с точки зрения приложения, пользующегося данной службой, сеть выглядела
так, будто в ней не работают приложения реального времени, конкурирующие
за ресурсы.
Обслуживание с контролируемой нагрузкой хорошо подходит для адаптив-
ных приложений реального времени [52]. Такие приложения не требуют зара-
нее установленного верхнего ограничения на задержки в сети. Вместо этого по-
лучатель измеряет флуктуацию во входящих пакетах и устанавливает точку
воспроизведения на такую минимальную задержку, при которой темп потери кад-
ров достаточно низок. Например, приложение воспроизведения видеоданных
можно адаптировать, отбросив кадр или слегка задержав выходной поток; при-
ложение передачи речи можно адаптировать, подбирая длительность пауз (на-
пример, см. [185]).
17.2. Дисциплина очередей
Важным компонентом реализации архитектуры интегрированных служб являет-
ся дисциплина очередей, используемая на маршрутизаторах. Традиционно мар-
шрутизаторами на каждом выходном порту применяется дисциплина очередей
FIFO (First in First Out — первым прибыл, первым обслужен) и поддерживается
отдельная очередь. Когда прибывает новый пакет и направляется к выходному
порту, он помещается в конец очереди. Пока очередь не опустеет, маршрутизатор
передает пакеты из очереди, выбирая из нее самый старый пакет.
У дисциплины очередей FIFO есть несколько недостатков.
4 Пакетам, принадлежащим потокам с более высоким приоритетом или пото-
кам, в большей степени чувствительным к задержке, не предоставляется спе-
циального обслуживания. Если несколько пакетов из различных потоков
готовы к передаче, они посылаются строго в порядке FIFO, то есть в том же
порядке, в котором они поступили в очередь.
538
Глава 17. Интегрированные и дифференцированные службы
♦ Если несколько меньших по размеру пакетов стоят в очереди позади боль-
ших пакетов, тогда результат применения схемы FIFO будет выражаться
в большей средней задержке пакета, чем в случае, если бы более короткие
пакеты передавались прежде больших пакетов. В целом получается, что по-
токи из пакетов большего размера получают лучшее обслуживание.
♦ Более эгоистичное ТCP-соединение может вытеснить более альтруистичес-
кие TCP-соединения. Если возникает перегрузка и одно из ТСР-соедине-
ний по какой-то причине не снизит скорость передачи данных, тогда дру-
гим TCP-соединениям придется пойти на большие уступки, чем в случае
если бы все TCP-соединения снизили свои скорости.
Справедливая организация очередей
В [163] предложена схема, названная справедливой организацией очередей (Fair
Queuing, FQ) и призванная преодолеть некоторые недостатки дисциплины очере-
дей FIFO. В такой схеме маршрутизатор обслуживает несколько очередей для каж-
дого выходного порта. При этом можно поддерживать по одной очереди для каж-
дого источника, как предложено в [163], или по одной очереди для каждого потока,
как показано на рис. 17.3.
Мультиплексированный
выход
Справедливая организация очередей
Рис. 17.3. Очереди FIFO и FQ
17.2. Дисциплина очередей
539
При справедливой организации очередей каждый входящий пакет помещает-
ся в соответствующую очередь. Очереди обслуживаются в циклическом порядке,
то есть из каждой очереди поочередно выбирается один пакет. Пустые очереди
пропускаются.
Такая схема является справедливой в том смысле, что каждому непустому по-
току удается послать ровно один пакет за цикл. Кроме того, эта схема представля-
ет собой форму балансировки нагрузки между потоками. Также обратите внимание
на то, что при такой схеме потоку нет смысла быть жадным. Единственное, что по-
лучит эгоистичный поток, это удлинение своей очереди и соответствующее уве-
личение задержки в доставке пакетов, при этом его поведение никак не скажется
на других потоках.
Разделение процессора
Серьезный недостаток схемы справедливой организации очередей заключается
в том, что короткие пакеты получают менее качественное обслуживание. Пото-
ки с большим средним размером пакета получают большую долю пропускной спо-
собности по сравнению с потоками с меньшим средним размером пакетов. Причи-
на этого в том, что каждая очередь передает по одному пакету за цикл.
Этот недостаток можно преодолеть с помощью схемы справедливой организа-
ции очередей с побитовым циклом (Bit-Round Fair Queuing, BRFQ), в которой при
планировании пакетов учитываются не только идентификаторы пакетов, но и дли-
на пакетов. Эта техника описывается в [70].
Чтобы понять, как работает метод справедливой организации очередей с по-
битовым циклом, рассмотрим сначала идеальную политику, которая на практике
не применяется. Сформируем несколько очередей, как в схеме справедливой орга-
низации очередей, но будем передавать в каждом цикле не целый пакет, а всего
один бит. Таким образом, более длинные пакеты не получат преимущества, и каж-
дому источнику будет предоставлена равная пропускная способность. В частно-
сти, если имеются N очередей и в каждой из этих очередей всегда есть пакет для
передачи, тогда каждая очередь получает ровно 1 /N доступной пропускной спо-
собности.
Такой идеальный побитовый подход известен также как разделение процессо-
ра (Processor Sharing, PS). Чтобы дальнейшее обсуждение было понятнее, введем
следующие обозначения:
4 R(t) — количество циклов обслуживания с разделением процессора, кото-
рые произошли к моменту времени t, нормализованное относительно выход-
ной скорости передачи данных;
♦ N(t) — количество непустых очередей в момент времени С;
♦ Р,'1 — время передачи для пакета г в очереди а, приведенное к выходной ско-
рости передачи данных;
4 т“ — время прибытия пакета г в очередь а;
4 S" — значение R(t) в момент начала передачи пакета г в очереди а;
4 F“ — значение R(f) в момент завершения передачи пакета г в очереди а.
540
Глава 17. Интегрированные и дифференцированные службы
Значение R(t) можно рассматривать как виртуальное время, соответствующее
скорости обслуживания пакета, находящегося в начале очереди. Эквивалентное
определение выглядит следующим образом:
*<‘>4ВД = Ж(0Г
Для примера рассмотрим три очереди, трафик которых описывается табл. 17.1
Таблица 17.1. Трафик трех очередей, обслуживаемый по схеме PS
Очередь а Очередь р Пакет 1 Пакет 2 Пакет 1 Пакет 2 Очередьу Пакет 1
Реальное время прибытия т, 0 2 1 2 Время передачи Pi 3 114 Виртуальное время начала S/ 0 3 1 2 Виртуальное время конца F, 3 4 2 6 3 3 2 5
Значения т,- и Р, задаются; значения 5, и Ft определяются политикой разделения
процессора. На рис. 17.4 тонкие черные линии иллюстрируют обслуживание трех
очередей. Первый прибывший в очередь а пакет получает одну единицу обслужи-
вания в реальном интервале времени [0,1 ] с виртуальным временем 7?( 1) = 1 к кон-
цу этого интервала. В реальном интервале времени [1,3] биты передаются из двух
очередей, в результате чего каждая очередь получает скорость обслуживания
R ' = 1/2 и аккумулирует за этот интервал одну единицу обслуживания, так что
R(3) = R(l) + 1/2 (3 - 1) = 2. Аналогично, в течение интервала времени [3,9] все
три очереди сохраняют активность, поэтому каждая получает обслуживание со
скоростью R '= 1/3 и аккумулирует две единицы обслуживания за этот интервал.
Этого достаточно, чтобы были целиком переданы два пакета из очереди а и один
пакет из очереди Р; к моменту времени t = 9 дополнительный пакет из очереди Р
и один пакет из очереди у находятся в стадии обработки.
Следующее рекуррентное соотношение показывает, как система разделения
процессора развивается в виртуальном времени:
F“ = S" + Р“,
S? = тах[Г“„ £(?“)]•
(17.1)
Обратите внимание на то, что по этим соотношениям мы можем сосчитать вир-
туальное время окончания передачи пакета в момент прибытия пакета. Однако мы
не можем вычислить реальное время окончания передачи пакета в момент его при-
бытия, потому что реальное время окончания передачи пакета зависит от прибы-
тия других пакетов.
Справедливая организация очередей
с побитовым циклом
Упоминавшаяся ранее схема справедливой организации очередей с побитовым
циклом (BRFQ), эмулирующая побитовую дисциплину, позволяет передавать не
17.2. Дисциплина очередей
541
отдельные биты, а пакеты целиком. Эта схема реализуется путем вычисления «на
лету» значений виртуального времени начала и окончания передачи пакета, как
если бы применялось разделение процессора. Правило очереди BRFQ формули-
руется просто: когда завершается передача очередного пакета, для передачи выби-
рается пакет с наименьшим значением
t
Очередь а
Очередь р
Очередь у
0 0
1 1
2
3 2
4
_а Л
Si —0
^ = 3
_а Л
Sj - 3
₽2 = 1
£=4
S?=T
^=1
Х = 2
S]=2
P] = 3
X=5
ff=4
5
6 3
7
8
9 4
10
11 5
12 6
Рис. 17.4. Пример работы схем PS и BRFQ (по [100])
Рисунок 17.4 позволяет сравнить схемы PS и BRFQ. Тонкие черные линии пока-
зывают время передачи при использовании схемы разделения процессора, а серые
линии — при использовании схемы справедливой организации очередей с поби-
товым циклом. Обратите внимание на то, что очередность передачи пакетов, осно-
ванная либо на реальном времени начала, либо на реальном времени окончания,
не совсем совпадает. Тем не менее, схема BRFQ довольно точно соответствует
схеме разделения процессора по производительности. В самом деле, в [100] по-
казано, что при увеличении интервала времени наблюдения значения средней
пропускной способности и средней задержки каждого потока в схеме BRFQ стре-
мятся к соответствующим значениям схемы PS.
542
Глава 17, Интегрированные и дифференцированные службы
На рис. 17.5, а показаны временные диаграммы трех потоков на выходном пор-
ту маршрутизатора. В первых трех рядах вертикальными стрелками обозначены
времена прибытия пакетов, при этом значения длины стрелок пропорциональны
размеру пакетов. Пакеты первого потока в два раза больше пакетов остальных пото-
ков. В следующих трех строках показаны времена передачи пакетов при использо-
вании различных дисциплин организации очередей1. Затенения позволяют увидеть
соответствие между временными диаграммами поступления пакетов и временны-
ми диаграммами передачи пакетов. В данном случае использование дисциплин
очередей FIFO и FQ приводит к одинаковому рисунку выходного трафика. Подоб-
но другим дисциплинам, схема BRFQ предоставляет всем потокам одинаковый
объем обслуживания, но при одновременном прибытии нескольких пакетов пред-
почтение отдается более коротким пакетам. Соответственно, в схеме BRFQ пото-
ки 2 и 3 получают меньшие средние задержки, чем в схеме FIFO или FQ.
Поток1 Т i i i i iteiiiitf i i i i IltriiaM
поток2 4 4 I I I 4-4^4 J2*l'j;4 4 I_______I l
Поток 3 4 I I I I 4. I I I I 4 Illi 4 I I I I i
FIFO | 1 | 2 j 3 । 2 j 1 =| 2 | 3 } 2 | 1 । 2 j 3 j 2. | -j | 2 j. 3 | 2 |
FQ | 1 I 2 | 3 | 2 | .Г | 2 I 3 ! 2 | 1 | 2 | 3 | I 2 | 3 | 2 |
BRFQ
Поток 1
Поток 2
Поток 3
Поток 4
FIFO | 1 | 2 | 3 | 4 | 2 | ' 1 | 2 | 3 | 4 |,2-1 1 | 2 | 3 | 4 | 2 |.V j I; I
FQ I 1 I 2 I 3 I 4 ; 1 ' 2 i 3 | 4 | 1 | 2 ] 3 | 4 | 1 | 2.:j 3 | 4 |
BRFQ |2 |3|4| 1 | 2 | 2 | 3|4| 1 |2 | 2| 3।4 । 1 j 2j2{3|
6
Рис. 17.5. Сравнение схемы FIFO и двух схем справедливой организации очередей
1 Мы будем использовать соглашение, по которому спорные случаи разрешаются в пользу потока
минимальным номером потока.
17.2. Дисциплина очередей
543
При добавлении дополнительного потока (рис. 17.5, б) маршрутизатор уже не
успевает обрабатывать запросы. По мере роста очередей задержки увеличивают-
ся. Если все источники представляют собой «правильные» ТСР-сущности, тогда
скорость передачи данных в потоках будет снижена, и перегрузка «сойдет на нет».
В то же время, очевидны различия политик. В схеме FIFO задержки всех потоков
равномерно растут со скоростью, равной одной временной единице за каждые пять
единиц времени. В схеме FQ страдает только поток 2, для остальных потоков за-
держки не увеличиваются. Соответственно, растет только очередь потока 2, пока
наконец поток 2 не обнаружит увеличение задержки и не снизит скорость передачи
данных. В определенном смысле это справедливо, так как каждому потоку разре-
шается посылать только один пакет за цикл. Однако потоки 1 и 2 хотят передавать
данные с одинаковой скоростью передачи данных, и поток 1 получает преимуще-
ство, поскольку использует пакеты больших размеров. Схема BRFQ также спра-
ведлива, но в плане объема переданных данных, а не количества переданных паке-
тов. Подобно FIFO, схема BRFQ вызывает увеличение всех задержек, но в случае
BRFQ преимущество получают небольшие пакеты.
Обобщенная схема разделения процессора
Схема BRFQ является более совершенной по сравнению со схемами FIFO и FQ
в том смысле, что она справедливо распределяет доступные ресурсы среди всех ак-
тивных потоков, протекающих через узел. Однако схема BRFQ не способна пре-
доставлять различным потокам разный объем ресурсов. Для передачи трафика
с различными уровнями качества обслуживания необходима способность диффе-
ренцированного выделения ресурсов. Метод, получивший самое широкое приме-
нение, представляет собой усовершенствованную схему BRFQ и называется взве-
шенной справедливой организацией очередей (Weighted Fair Queuing, WFQ)1.
Опять же, описание метода будет понятнее, если мы сначала рассмотрим побито-
вую версию.
Для учета различающихся требований разных ресурсов мы можем обобщить
дисциплину разделения процессора, наделив ее способностью произвольного пре-
доставления ресурсов. В схеме обобщенного разделения процессора (Generalized
Processor Sharing, GPS) каждому потоку а назначается вес (ри, определяющий ко-
личество битов, передаваемых из очереди в каждом цикле. Таким образом, если
вес данного потока равен 5, тогда, если очередь не пуста, в каждом цикле будет
передано 5 бит. Мы можем смоделировать этот процесс, модифицируя форму-
лу (17.1) следующим образом:
Ра
Fia=S,a+^~,
Ф<х
5“ = шах[Д“ , Д(т“)].
(17.2)
1 Впервые концепция схемы WFQ была представлена в [70], причем там она упоминается лишь
вскользь, а аббревиатура WFQ не используется. Первый подробный анализ схемы WFQ появился в
статьях [173] и [174], в которых она называется попакетны.м обобщенным разделением процессора
(Packet-by-packet Generalized Processor Sharing, PGPS).
544
Глава 17. Интегрированные и дифференцированные службы
В результате мы установим эффективную длину пакета равной 1 /<ра от настояв
щей длины пакета. Нетрудно видеть, что в любой момент времени скорость обслув
живания g, для непустого потока ? равна и
<р
g = (17.3)
Здесь сумма вычисляется по всем активным очередям, а С представляет собой
скорость передачи данных по выходящей линии.
Привлекательность схемы GPS объясняется тем, что она предоставляет сред-
ство удовлетворения запросов с различными уровнями обслуживания. Если источ-
ник запрашивает для потока обслуживание со скоростью g,-, узел может удовлет-
ворить этот запрос при наличии достаточного объема доступных ресурсов. В этом
случае для гарантированного обслуживания потоку назначается соответствующий
вес. Кроме того, потоку с правильным поведением схема GPS предоставляет гаран-
тии того, что величины задержек не превысят определенного уровня. Рассмотрим
множество потоков, обслуживаемых в соответствии со спецификацией маркерно-
го ведра, описанной в разделе 17.1, где В, и 77, представляют собой, соответственно,
объем ведра и скорость маркеров для потока i. Пусть теперь вес, назначенный каж-
дому потоку, будет равен скорости маркеров, то есть (р,- = R,. В этом случае задерж-
ка D, потока г ограничивается в соответствии со следующей формулой:
D<^-. (17.4)
'7?,
Доказательство этого соотношения приводится в [174]; здесь мы ограничимся
лишь интуитивно понятным аргументом. Рассмотрим ситуацию, в которой все
потоки в течение некоторого времени бездействовали или работали не на полную
мощность, а все пакеты полны. Затем все пакеты начинают передаваться с мак-
симальной скоростью. Сеть сконфигурирована так, чтобы для каждого потока
поддерживать максимальную скорость R,. На этой скорости маркеры добавляют-
ся в ведро с той же скоростью, с которой они из него вытекают. Если узел успевает
обрабатывать поток, тогда длина очереди на узле не превысит объема ведра. Поэто-
му задержка каждого потока, проходящего через узел, не превысит объема ведра,
деленного на скорость маркеров, что и утверждается в формуле (17.4).
Взвешенная справедливая организация очередей
Как и ранее, желательно перейти от передачи отдельных битов к передаче целых
пакетов. Так же как схема BFRQ эмулирует схему PS, упомянутая выше схема
WFQ эмулирует схему GPS. Применяется та же самая стратегия. Каждый раз, кого
завершается передача пакета, для передачи выбирается пакет с наименьшим значе
пнем 7;"-В этом случае для вычисления значения F" используется формула (17.2
Рисунок 17.6, основанный на примерах из [246], иллюстрирует схему WF‘
в сравнении со схемой FIFO. У всех пакетов одинаковый размер 1, и скорость пер'
дачи данных в линии также равна 1. Гарантированная скорость передачи данны
для соединения 1 равна 0,5, а для остальных 10 соединений — 0,05. На рис. 17.0
17.2. Дисциплина очередей
545
поток 1 посылает подряд 11 пакетов, начиная в момент времени 0, а остальные по-
токи в момент времени 0 посылают по одному пакету. В схеме FIFO пересылается
один пакет из каждого потока, а затем передаются оставшиеся 10 пакетов потока I1.
В схеме WFQ, поскольку у первых 10 пакетов потока 1 время окончания передачи
меньше, чем у пакетов других соединений, узел передаст эти пакеты первыми.
В обоих случаях каждый поток получает гарантированную скорость передачи
данных за интервал 20 единиц времени, но в схеме WFQ относительные задержки
изменяются в пользу потока 1. На рис. 17.6, б пакеты потока 1 прибывают равно-
мерно с нужной скоростью. В схеме FIFO все пакеты, кроме первого, задерживают-
ся другим трафиком, который должен получить определенную часть пропускной
способности. Схема WFQ является близким приближением к ситуации получения
каждым потоком однородного и приемлемого обслуживания.
поток 1 44444444444! I I I I I | i | । ।
Поток 2 4 I I I I I I I I I I I I I I I I I I I I I
Поток 11 4 I I I I I I I I I I I I I I I I I I I I I
FIFO | 1 ! 2|з|4|5|б|7|8|9 110! 111 | 1 | 1 | 1 j Л j 1 I Л ] 1 1.1 | 1 |
WFQ [ 1 I 1 Г?1 I 1 I 1 1 I 1:| .1 I 1 I 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 |10|11|Я
а
поток 1 4i4i4i4i4i4i4i4i4i4i4i
Поток 2 4 I I I I I I I I I I I I I I I I I I I I I
Поток 11 4 I I I I I I I I I I ! I I I I I I I I I I
FIFO | 1 | 2|3|4|5|6|7|8|9 11 о| 111 1 | 1: j 1 | 1 ( 1 | 1 | 4 j 1 | 1 |~-П
WFQ | Т | 2 | 1 I 3 | 1 | 4 1.1 | Ь ! 1 | 6 | 1 | 7 | 1 ! 8 | 1 | 9 | 1J101 1 ! 11 |Sb]
б
Рис. 17.6. Сравнение схем FIFO и WFQ
Как было отмечено, привлекательность схемы GPS связана с тем, что для гаран-
тированного обслуживания она позволяет маршрутизатору назначать каждому
' Обратите внимание на то, что тот же результат можно получить в схеме FQ. Это верно и для рис. 17.6, б.
546
Глава 17. Интегрированные и дифференцированные службы
(П.5)
потоку соответствующий вес, а также с возможностью гарантировать верхнюю гра-
ницу задержки. Этими качествами также обладает и аппроксимация схемы GPS
которой является схема WFQ. В этом случае формула (17.4) должна быть измене-
на следующим образом:
р<Д+(К,-1)£,+Д^
' Д д, с,„
Здесь:
♦ D, — максимальная задержка потока г;
♦ В, — объем маркерного ведра для потока г;
4- Д; — скорость маркеров для потока г;
♦ Ki — количество узлов на пути потока г через объединенную сеть;
♦ L, — максимальный размер пакета для потока г;
♦ Дтах — максимальный размер пакета для всех потоков, проходящих по всем
узлам пути потока г;
♦ Сга — пропускная способность исходящей линии в узле т.
Первое слагаемое взято из схемы GPS и учитывает задержку, вызванную раз-
мерами ведра, что то же самое, что и задержка, вызванная перегрузкой. Второе сла-
гаемое пропорционально задержке каждого пакета этого потока на каждом узле.
Последнее слагаемое отражает применение попакетной передачи вместо побитовой.
Мы снова приведем интуитивно понятное разъяснение. В обеих схемах (BRFQ
и WFQ) пакет может покинуть узел несколько позднее, чем при побитовой обра-
ботке (PS или GPS). Причина заключается в том, что узел может выбирать пакет
для передачи только из уже прибывших пакетов. Если следующий выбранный па-
кет оказывается относительно большим и во время его передачи прибывает ма-
ленький пакет, может случиться, что в схеме GPS у этого маленького пакета ока-
жется меньшее значение времени окончания передачи, и поэтому в схеме WFQ он
должен быть передан первым. А если пакет еще не прибыл, то и его передачу при-
ходится откладывать, но не больше чем на полную длину самого большого пакета,
проходящего через этот узел.
Формула (17.5) важна для разработки архитектуры ISA. Утверждается, что суще-
ствует простой способ установки параметров в маршрутизаторе, гарантирующий
заданную скорость обслуживания. Более того, па этой скорости пользователю может
быть предоставлен верхний предел задержки. Наконец, в [174] показано, что макси-
мальный размер очереди, необходимый для каждого узла, пропорционален макси-
мальной величине задержки, определенной в формуле (17.5); в частности, он стре-
мится KgiDi. Таким образом, узел может легко определить резервируемые ресурсы.
17.3. Случайное раннее обнаружение
Другой подход к борьбе с перегрузкой в объединенных сетях представляет собой
упреждающее отбрасывание пакетов. При этом подходе в целях повышения про-
изводительности сети маршрутизатор отбрасывает один или несколько входящих
17.3. Случайное раннее обнаружение
547
пакетов прежде, чем переполнится выходной буфер. Эта техника разработана для
одной очереди FIFO и может применяться в любой архитектуре объединенных
сетей. В контексте архитектуры ISA в целях повышения производительности
эластичного трафика упреждающее отбрасывание пакетов может быть реализова-
но в одной или нескольких очередях на каждом маршрутизаторе.
Наиболее важный вариант схемы упреждающего отбрасывания пакетов впер-
вые упоминается в [83] как случайное раннее обнаружение (Random Early Detection,
RED). Схема случайного раннего обнаружения была реализована многими про-
изводителями. В данном разделе мы сначала обсудим побудительные причины для
применения схемы RED и цели ее разработки, после чего перейдем к деталям.
Мотивация
Когда в сети возникает перегрузка, буферы маршрутизаторов переполняются
и маршрутизаторы начинают терять пакеты. Для TCP-трафика это является сиг-
налом о необходимости перехода в фазу затяжного пуска для снижения нагрузки
на сеть и устранения перегрузки. У данного сценария есть два недостатка. Во-пер-
вых, потерянные пакеты необходимо передавать повторно, что увеличивает на-
грузку на сеть и является причиной значительных задержек в TCP-потоках. Более
серьезный феномен называется глобальной синхронизацией (global synchronization),
при которой имеет место следующая ситуация. В случае резкого увеличения объ-
емов трафика очереди переполняются, и множество пакетов теряется. Как прави-
ло, это затрагивает многие TCP-соединения, в результате они переходят в фазу
затяжного пуска, суммарный объем сетевого трафика резко падает и в течение
определенного периода сеть используется не в полной мере. Поскольку многие
TCP-соединения переходят в фазу затяжного пуска примерно в одно и то же вре-
мя, они и выходят из этого режима также приблизительно одновременно, что вы-
зывает очередное резкое увеличение объемов трафика в сети и новый цикл «изо-
билия и голодания».
Одно из решений заключается в использовании на каждом маршрутизаторе
буферов большего размера для снижения вероятности потери пакетов. У такого
подхода есть два недостатка. Во-первых, когда эти большие буферы заполняются,
задержки во всех соединениях возрастают во много раз. Еще хуже ситуация в слу-
чае самоподобного трафика (что весьма вероятно). Тогда построить достаточно
большие буферы невозможно в принципе. Большие всплески активности отпра-
вителей могут возникать друг за другом, поддерживая состояние перегрузки, и
потребности в буферах при этом будут расти до бесконечности.
Лучшее решение состоит в том, чтобы предвидеть наступление перегрузки и
предлагать то одному, то другому TCP-сообщению снизить скорость передачи дан-
ных. Затем определяется эффект этого замедления, после чего, в случае необ-
ходимости, замедляется другое соединение. Подобным образом, когда начинается
перегрузка, торможение трафика осуществляется постепенно, с минимальным воз-
действием на TCP-соединения и без глобальной синхронизации. Именно такое
решение реализовано в методе RED.
548 Глава 17. Интегрированные и дифференцированные службы
Цели разработки метода случайного раннего я
обнаружения Ip-
Цели, которые преследовались при разработке метода случайного раннего обна- Т—
ружения, перечислены далее [83]: 1
♦ Предупреждение перегрузки. Метод случайного раннего обнаружения пред- [
назначен не для реагирования на возникновение перегрузки, а для ее пре-
дотвращения.
♦ Предотвращение глобальной синхронизации. Когда маршрутизатор обнару-
живает перегрузку, он должен решить, которому соединению (или соеди-
нениям) предложить снизить скорость передачи данных. В применяемом
сегодня варианте этого метода данное уведомление является неявным и про-
является в потере пакетов. Обнаруживая перегрузку заранее и уведомляя
о ней только те соединения, которые требуется, этот метод позволяет избе-
жать глобальной синхронизации.
♦ Предотвращение дискриминации источников неравномерного трафика. С боль-
шой вероятностью перегрузка в сети начинается с поступления большого
объема данных от одного или нескольких источников. Этот всплеск актив- I
ности добавляется к текущей нагрузке на маршрутизатор. Если для отбра-
сывания выбираются только прибывающие пакеты, тогда велика вероят-
ность того, что алгоритм отбрасывания пакетов будет направлен в основном
против источников с непостоянной скоростью передачи данных.
♦ Ограничение средней длины очередей. Метод случайного раннего обнаруже-
ния должен уметь контролировать среднюю длину очередей и, следователь-
но, среднюю задержку.
Алгоритм RED
В общих чертах алгоритм случайного раннего обнаружения для каждого прибыв-
шего пакета выглядит следующим образом:
вычислить среднюю длину очереди avg
если avg < ТН.,П
установить пакет в очередь
иначе если 7Н,Г. < avg < ТН„>.
вычислить вероятность Ра
с вероятностью Р.,
отбросить пакет
иначе с вероятностью 1-8,
установить пакет в очередь
иначе если avg <
отбросить пакет
Каждый раз, когда новый пакет поступает в выходную очередь с дисциплиной
FIFO, этот алгоритм выполняет две функции. Первый шаг заключается в вычис-
лении средней длины очереди avg. Средняя длина очереди сравнивается с двумя
уровнями (рис. 17.7). Если средняя длина очереди avg меньше нижнего предела
то перегрузка считается минимальной или отсутствующей и пакет помеша-
i
17.3. Случайное раннее обнаружение
549
ется в очередь. Если значение avg больше или равно верхнему пределу ТИ„т, то
перегрузка считается серьезной и пакет отбрасывается. Если значение avg нахо-
дится между двумя предельными значениями, тогда мы попадаем в область пе-
регрузки. В этой области вычисляется вероятность выбрасывания пакета Ри, зави-
сящая от точного значения средней длины очереди avg и увеличивающаяся при
приближении значения avg к верхнему пределу. Когда средняя длина очереди
находится в этой области, пакет отбрасывается с вероятностью Ра и ставится в оче-
редь с вероятностью 1 - Р„.
Рис. 17.7. Буфер маршрутизатора при использовании алгоритма RED
По сути, первая часть алгоритма (вычисление средней длины очереди) опреде-
ляет допустимый уровень неравномерности трафика, а вторая часть алгоритма —
частоту отбрасывания пакетов при данном уровне перегрузки.
Теперь можем подробнее изучить алгоритм случайного раннего обнаружения.
Инициализация
avg <— О
count <—1
Для каждого прибывающего пакета
Вычислить среднюю длину очереди
если очередь не пуста (то есть q > 0)
avg <— (1 - Hfc) avg + woq
иначе
m <—
avg <— (1 - w0)” avg + w„q
Определить необходимость отбрасывания пакета
если avg <
пакет ставится в очередь
count <— -1
иначе если TH„r, < avg < ТНК,
увеличить count
Рь v— Ряы (.avg - /(ТН^, - THmn)
Ре <— Рь/(1 count X Ро)
с вероятностью Ра
отбросить пакет
count <— 0
иначе с вероятностью 1 - Ра
установить пакет в очередь
иначе если avg >
отбросить пакет
count <— 0
Когда очередь опустеет
q_time <— time
550 Глава 17. Интегрированные и дифференцированные службы
Далее перечислены обозначения, использованные в этом алгоритме:
4- Сохраняемые переменные:
♦ avg — средний размер очереди;
♦ q_time — время освобождения очереди;
♦ count — счетчик пакетов, начиная с последнего отброшенного пакета
4 Константы:
♦ w4 — вес очереди;
♦ THmtn — минимальное для очереди пороговое значение;
♦ ТНтах — максимальное для очереди пороговое значение;
♦ Рmax — максимальное значение Рь.
+ Другие обозначения:
♦ Ра — текущая вероятность отбрасывания пакета;
♦ Рь — временная расчетная вероятность;
♦ q — текущий размер очереди;
♦ time — текущее время;
♦ f(t) — линейная функция времени t.
Вычисление среднего размера очереди
Средний размер очереди вычисляется методом экспоненциально взвешенного
среднего значения предыдущих размеров очередей. В инструкции если учитыва-
ются периоды, в течение которых очередь пуста, путем оценки количества неболь-
ших пакетов т, которые мог бы передать маршрутизатор за время простоя.
Может возникнуть вопрос, почему используется среднее значение размера оче-
реди, тогда как проще было бы использовать ее текущий размер. Цель использова-
ния среднего значения заключается в том, чтобы отфильтровать кратковременные
периоды перегрузки маршрутизатора. Вес w4 определяет скорость изменения сред-
него размера очереди avg в ответ на изменения фактического размера очереди. В [83]
рекомендуется совсем небольшая величина 0,002. В результате значение avg
значительно отстает от изменений фактического размера очереди. Использование
небольшого весового коэффициента не позволяет алгоритму реагировать на крат-
ковременную перегрузку.
Принятие решения об отбрасывании пакета
Если средний размер очереди avg меньше нижнего предела THmin, то поступивший
пакет помещается в очередь, а если значение avg больше или равно верхнему пре-
делу ТН,тх, то поступивший пакет автоматически отбрасывается. Критическая об-
ласть для значения avg находится между этими двумя предельными значениями.
В этой области алгоритм случайного раннего обнаружения назначает каждому
поступившему пакету вероятность отбрасывания в зависимости от двух факторов:
♦ Чем ближе значение avg к верхнему пределу ТНт„х, тем выше вероятность
отбрасывания пакета.
i
17.3. Случайное раннее обнаружение
551
♦ Пока значение avg находится в критической области, в счетчике count учи-
тывается, сколько последовательных пакетов избежали отбрасывания. Чем
выше значение счетчика count, тем выше вероятность отбрасывания пакета.
Кратко поясним работу описанного алгоритма RED. Сначала вычисляется вре-
менная вероятность Рь, линейно увеличивающаяся от 0 при avg = THmi„ до некого
максимального значения РП1ах при avg = ТНтлх. Для большей ясности введем вели-
чину F, представляющую собой относительную долю критической области от ее
нижней границы до значения avg:
г_ avg-THmin
TJ-f — TH
1 п max 111 mm
При этом мы получаем:
Pb = FPmax,0<F<l.
Вероятностные явления характеризуются тем, что создают кластеры. Напри-
мер, если мы будем много раз подбрасывать монету, то мы не можем ожидать рав-
номерного чередования орлов и решек. Вместо этого будут возникать кластеры из
следующих подряд орлов, кластеры из почти одних решек и т. д., но при усредне-
нии за большой период доля выпадающих орлов и решек будет одинаковой. В ал-
горитме RED желательно отбрасывать пакеты относительно равномерно, чтобы
неравномерный источник пакетов не был наказан строже равномерного. Поэтому
вместо использования вероятности Рь напрямую она учитывается в вычислении
второй вероятности Ра, которая и применяется для принятия решения об отбра-
сывании пакета. Подставляя значение F в формулу Ра, имеющуюся в алгоритме,
получим следующее выражение:
FP
шах
р -
1 - count FPmm
Р,.
1 _ ft _ 1
--------count 1 collnt Pb count
FPm^----Pt
На рис. 17.8 показан график этой функции. Для заданного значения счетчика
count, величина Р„ равномерно увеличивается от ft = О при avg = ТН,„.„ до макси-
мального значения при avg= ТН„ЮХ. Такая схема разумна. Вероятность Р„ плавно
возрастает по мере приближения avg к ТНтлх. Но истинная природа этой функции
раскрывается, если при постоянной величине F построить зависимость вероят-
ности Ра от значения счетчика count. Значение Ра сначала медленно увеличи-
вается, а затем резко возрастает, пока не достигнет значения Рв - 1 при счетчике
count = (l/FP„rM) - 1. Таким образом, для большинства значений count вероят-
ность отбрасывания пакета крайне низка и стремительно приближается к 1, когда
значение счетчика подходит очень близко к максимальному значению. В резуль-
тате пакеты отбрасываются более или менее равномерно. Можно показать, что
если Ра представляет собой вероятность отбрасывания пакета, а X — количество
пакетов, прибывающих между двумя отброшенными пакетами, тогда величина
X представляет собой равномерно распределенную случайную переменную из
набора {1, 2,..., 1/Рь}:
552
Глава 17. Интегрированные и дифференцированные службы
Рг[Х = и] =
1
FPm., 1 < п <----------,
max ’ рр
1 \шах
1
FP
max
1__
2FP
max
2
(avg = 7/imin) (avg = 77imax)
Рис. 17.8. Параметр вероятности алгоритма RED
В качестве примера в [83] рекомендуется значение Р,„ах = 0,02. Когда средний
размер очереди находится ровно между TH„lin и Щ„„к (F= 0,5), отбрасывается при-
близительно один из 50 (один из 1/Р1|ИХ) прибывающих пакетов.
а
17.4. Дифференцированные службы
553
На рис. 17.9 показан результат эмуляции, в которой алгоритм RED сравнива-
ется с политикой обрубания хвостов (drop-tail policy), когда прибывающий пакет
просто отбрасывается, если в очереди нет свободного места. При высоких уровнях
перегрузки алгоритм RED заметно превосходит политику обрубания хвостов,
обеспечивая более высокую пропускную способность.
Рис. 17.9. Сравнение производительности политики обрубания хвостов и алгоритма RED
17.4. Дифференцированные службы
Архитектура интегрированных служб ISA и протокол RSVP (Resource reSerVation
Protocol — протокол резервирования ресурсов) предназначаются для поддержа-
ния в Интернете и в частных объединенных сетях служб с различными уровнями
качества обслуживания. Хотя архитектура ISA в целом и протокол RSVP в част-
ности, являются в этом отношении полезными инструментами, их довольно труд-
но реализовать. Более того, может оказаться, что для больших объемов трафика
они будут плохо масштабироваться из-за большого количества управляющих сиг-
налов, требуемого для координирования интегрированных предложений об уров-
не качества обслуживания, а также в связи с необходимостью поддерживать в мар-
шрутизаторах информацию о состоянии.
По мере того как нагрузка на Интернет и разнообразие приложений растут, рас-
тет и неотложная необходимость в предоставлении различных уровней качества
обслуживания разным потокам трафика. Архитектура дифференцированных
служб (Differentiated Services, DS), описываемая в RFC 2475, предназначена для
предоставления простого и легкого в реализации механизма поддержания ряда
сетевых служб, различающихся по производительности.
554
Глава 17. Интегрированные и дифференцированные службы
Несколько ключевых характеристик дифференцированных служб способству-
ют их эффективности и простоте реализации:
♦ Для предоставления различных классов обслуживания IР-пакеты помечаются
соответствующим образом, для чего используется поле типа службы прото-
кола IPv4 (см. рис. 2.2, а в главе 2) или поле класса трафика (см. рис. 2 2 б
там же). Таким образом, не требуется никаких изменений в протоколе IP
♦ Перед использованием дифференцированной службы между поставщиком
услуг (доменом объединенной сети) и пользователем устанавливается со-
глашение об уровне обслуживания. Это позволяет избежать необходимости
встраивания механизмов дифференцированных служб в приложения. Таким
образом, для использования дифференцированных служб не нужно изменять
существующие приложения.
4 Дифференцированные службы предоставляют встроенный механизм агре-
гирования. Весь трафик с одинаковым полем DS обрабатывается сетевой
службой одинаково. Например, несколько голосовых соединений не обра-
батываются индивидуально, а обслуживаются вместе. Это обеспечивает хо-
рошую масштабируемость для сетей большего размера и большей нагрузки.
♦ Дифференцированные службы реализуются на отдельных маршрутизаторах
при установке пакетов в очередь и переправке их дальше в сеть на основе
значения поля DS. Маршрутизаторы индивидуально обрабатывают каждый
пакет, и у них нет необходимости сохранять информапию о состоянии по-
токов пакетов.
Несмотря на то что дифференцированные службы предназначены для предо-
ставления простых услуг, основанных на относительно простых механизмах, набор
документов RFC, в которых описываются дифференцированные службы, весьма
запутан. Далее приводятся некоторые ключевые термины из этих спецификаций:
♦ Агрегат поведения (Behavior Aggregate, ВА). Набор пакетов с одинаковым
значением поля DS, проходящий по линии связи в определенном направлении.
4 Классификатор (classifier). Механизм отбора пакетов на основании поля DS
(BA-классификатор) или нескольких полей заголовка пакета (MF-класси-
фикатор).
4 Пограничный DS-узел (DS boundary node). DS-узел, соединяющий один до-
мен дифференцированных служб с узлом из другого домена.
4 DS-код (DS codepoint). Определенное значение 6-битовой части DSCP
8-битового поля DS в IP-заголовке.
4 DS-домен (DS domain). Непрерывный (связный) набор узлов, способный
поддерживать дифференцированные службы, действующие в рамках обще-
го набора политик предоставления услуг и определений поведения каждого
ретрансляционного участка.
4 Внутренний DS-узел (DS interior node). DS-узел, не являющийся пограничным.
4 DS-узел (DS node). Узел, поддерживающий дифференцированные службы.
Как правило, это маршрутизатор, хотя хост, предоставляющий дифферен-
цированные услуги своим приложениям, также является DS-узлом.
17.4. Дифференцированные службы
555
♦ Отбрасывание пакетов (dropping). Процесс, в котором по специальным пра-
вилам происходит отбрасывание пакетов. Этот процесс также называется
регулированием (policing).
♦ Маркировка (marking). Процесс установки в пакете специального DS-кода.
Пакеты могут маркироваться во время инициации или заново маркировать-
ся DS-узлом при следовании по маршруту.
♦ Измерение (metering). Процесс измерения временных свойств (например,
скорости) потока пакетов, выбранного классификатором. Мгновенное со-
стояние этого процесса может повлиять на работу функций маркировки,
формирования и отбрасывания.
♦ Поведение на ретрансляционном участке (Per-Нор Behavior, РНВ). Внеш-
нее проявление поведения, связанного с продвижением данных и назначен-
ного на узле агрегату поведения.
♦ Соглашение об уровне обслуживания (Service Level Agreement, SLA). Дого-
вор об обслуживании между клиентом и поставщиком услуг, в котором ука-
зывается услуга по продвижению данных, предоставляемая клиенту.
♦ Формирование (shaping). Процесс, в котором пакеты задерживаются внут-
ри потока в целях получения трафика, соответствующего некоторому опре-
деленному профилю.
4- Согласование трафика (traffic conditioning). Управляющие функции, выпол-
няемые для ввода в действие правил, указанных в соглашении о согласова-
нии трафика, включая функции измерения, маркировки, формирования и
отбрасывания пакетов.
4- Соглашение о согласовании трафика (Traffic Conditioning Agreement, ТСА).
Соглашение, в котором указываются правила классификации и правила со-
гласования трафика, применяемые к пакетам, выбранным классификатором.
Службы
В домене дифференцированных служб (определяемом как непрерывная часть
объединенной сети, в которой реализован непротиворечивый набор политик пре-
доставления дифференцированных услуг) предоставляются разные типы диффе-
ренцированных услуг. Как правило, домен дифференцированных служб находит-
ся под управлением единого администратора. Услуги, предоставляемые в домене
дифференцированных служб, определяются в соглашении об уровне обслужива-
ния (SLA), представляющем собой договор об обслуживании между пользовате-
лем и поставщиком услуг. В договоре указываются услуги по продвижению дан-
ных, предоставляемые пользователю для различных классов пакетов. Клиентом
может быть организация пользователей или другой домен дифференцированных
служб. Как только соглашение об уровне обслуживания достигнуто, пользователь
начинает поставлять пакеты, в которых в поле DS указывается класс пакета. По-
ставщик услуг должен гарантировать, что пользователь получит по меньшей мере
договорный уровень качества обслуживания для каждого класса пакетов. Для пре-
556
Глава 17. Интегрированные и дифференцированные службы
доставления данного уровня качества обслуживания поставщик услуг на каждом
маршрутизаторе должен сконфигурировать соответствующие политики продви-
жения данных (на основе значения поля DS) и измерять производительность каж-
дого класса.
Если пользователь поставляет пакеты, направляемые получателям, находя-
щимся в том же домене дифференцированных служб, тогда от домена ожидается
предоставление указанных в договоре услуг. Если же получатель находится за пре-
делами DS-домена пользователя, тогда домен попытается переправить пакеты че-
рез другие домены, запросив обслуживание, лучше всего соответствующее запра-
шиваемому уровню.
Далее перечислены параметры производительности, которые могут быть вклю-
чены в соглашение об уровне обслуживания:
4 Ожидаемая пропускная способность, вероятность отбрасывания пакета, за-
держка.
♦ Ограничения на входные и выходные точки, в которых предоставляется
услуга, указывающие на область ее применения.
♦ Профили трафика, которые должны выдерживаться для запрашиваемой
услуги, например параметры маркерного ведра.
4 - Размещение трафика, поставляемого сверх указанного профиля.
В рамочном документе также приводятся некоторые примеры предоставляе-
мых услуг:
4 Трафик, предлагаемый на уровне обслуживания класса А, будет доставлен
с низкой задержкой.
♦ Трафик, предлагаемый на уровне обслуживания класса В, будет доставлен
с низкими потерями.
4 Задержки для 90 % трафика, предлагаемого на уровне обслуживания клас-
са С, не превысят 50 мс.
4 Получателю будет доставлено 95 % трафика, предлагаемого на уровне об-
служивания класса D.
♦ Трафику, предлагаемому на уровне обслуживания класса Е, будет предос-
тавлена в два раза большая пропускная способность, чем трафику, предла-
гаемому на уровне обслуживания класса F.
♦ Трафик с очередностью отбрасывания X доставляется с большей вероятно-
стью, чем трафик с очередностью отбрасывания Y.
Первые два примера являются качественными и имеют смысл только при срав-
нении с другим трафиком, например трафиком по умолчанию, получающим об-
служивание с максимальными усилиями (то есть по остаточному принципу). Сле-
дующие два примера являются количественными и предоставляют определенные
гарантии, соблюдение которых можно проверить путем измерения самого трафи-
ка, а не сравнивая данную услугу с другими услугами, предоставляемыми в то же
самое время. Последние два примера представляют собой сочетание качественных
и количественных характеристик.
17.4. Дифференцированные службы
557
Поле DS
В целях получения того или иного обслуживания пакеты маркируются при помо-
щи поля DS, располагающегося в поле типа службы заголовка IPv4 или в поле
класса трафика заголовка IPv6. В документе RFC 2474 определяется следующий
формат поля DS. Первые 6 бит образуют DS-код, а последние 2 бита временно не
используются. DS-код представляет собой метку, используемую для классифика-
ции пакетов. На рис. 17.10 показано поле DS и более ранняя интерпретация поля
типа службы протокола IPv4. Ниже перечислены значения подполей очередности
и типа службы для протокола IPv4.
Подполе очередности:
4 111 — управление сетью;
♦ 110 — управление объединенной сетью;
4 101 — критически важный пакет;
4 100 — отмена групповой операции;
4 011 — групповая операция;
4 010 — пакет требует немедленной реакции;
4 001 — приоритет;
4 000 — регулярный пакет.
Подполе типа службы:
4 1000 — минимизировать задержку;
4 0100 — максимизировать пропускную способность;
4 0010 — максимизировать надежность;
4 0001 — минимизировать денежную стоимость;
4 0000 — обычное обслуживание.
Рис. 17.10. Поле DS и поле Тип службы IPv4
С помощью 6-битового кода, в принципе, можно определить 64 различных клас-
са трафика. Эти 64 кода разделены на три пула:
4 Коды вида хххххО, где х обозначает произвольное значение бита (0 или 1),
зарезервированы для назначения в качестве стандартов.
4 Коды вида xxxxl 1 зарезервированы для экспериментального или локально-
го использования.
558
Глава 17. Интегрированные и дифференцированные службы
4 Коды вида xxxxOl также зарезервированы для экспериментального или ло-
кального использования, но также могут быть, в случае необходимости, вы
делены для будущих стандартов.
В документе RFC 2474 определены некоторые коды из первого пула. Код 000000
объявлен классом пакетов по умолчанию. Этот класс обслуживается маршрутиза-
торами с максимальными усилиями (по остаточному принципу). Такие пакеты
переправляются в том же порядке, в котором они были получены, как только ли-
ния связи становится доступной. Пакеты более высоких классов получают пре-
имущество по сравнению с пакетами класса 000000.
Коды вида хххООО зарезервированы для обратной совместимости со службой
очередности протокола IPv4. Как упоминалось в разделе 3.3 главы 3, поле типа
службы (Type Of Service, TOS) состоит из двух подполей: 3-разрядного подполя
очередности и 4-разрядного подполя TOS. Эти подполя выполняют взаимодо-
полняющие функции. Подполе TOS позволяет IP-сущности (источнику или мар-
шрутизатору) выбрать для данной дейтаграммы следующий ретрансляционный
участок, а подполе очередности предоставляет сведения об относительном распре-
делении ресурсов маршрутизатора для данной дейтаграммы. Коды DS вида хххООО
должны обеспечивать обслуживание, по меньшей мере, эквивалентное тому, что
предоставлялось при помощи подполя очередности протокола IPv4.
Конфигурирование и работа
дифференцированных служб
Рисунок 17.11 иллюстрирует тип конфигурации, представленный в документации
дифференцированных служб. Домен дифференцированных служб состоит из не-
прерывного множества связанных друг с другом маршрутизаторов; то есть можно
попасть из любого маршрутизатора домена на любой другой маршрутизатор до-
мена по пути, в который не входят маршрутизаторы за пределами домена. В пре-
делах домена DS-код интерпретируется одинаково, таким образом, предоставля-
ется однородное непротиворечивое обслуживание.
Маршрутизаторы в домене дифференцированных служб представляют собой
либо пограничные узлы, либо внутренние узлы. Как правило, внутренними уз-
лами реализуются простые механизмы обработки пакетов на основе значений
их полей DS. Эти механизмы включают дисциплину очередей, предоставляющую
преимущественное обслуживание в зависимости от значений поля DS, а также пра-
вила отбрасывания пакетов, определяющие, которые пакеты должны быть отбро-
шены в первую очередь в случае наполнения буфера. В спецификации дифферен-
цированных служб обработка пакетов на маршрутизаторе называется поведением
на ретрансляционном участке (). Любой вариант поведения на ретрансляционном
участке должен быть доступен на всех маршрутизаторах, и, как правило, РНВ пред-
ставляет собой единственный атрибут дифференцированных служб, реализован-
ный на внутренних маршрутизаторах.
На пограничных узлах также реализованы механизмы РНВ, но кроме них они
содержат более сложные механизмы согласования, необходимые для предостав-
ления требуемой услуги. Таким образом, внутренние маршрутизаторы обладают
17.4. Дифференцированные службы
559
минимальной функциональностью, тогда как наиболее сложные механизмы реа-
лизованы на пограничных узлах. Функции пограничного узла также могут предо-
ставляться хостом, присоединенным к домену, от имени приложений этого хоста.
Классификатор
Измеритель
Пограничный DS-узел
Внутренний DS-узел
Рис. 17.11. Домены дифференцированных служб
Функция согласования трафика состоит из пяти элементов:
4- Классификатор. Разделяет поставляемые пакеты на различные классы. Это
основа предоставления дифференцированных услуг. Классификатор может
разделять трафик только на основе значения кода DS (ВА-классификатор)
или на основе нескольких полей заголовка пакета, или даже по содержимо-
му полезной нагрузки пакета (MF-классификатор).
♦ Измеритель. Измеряет предоставляемый трафик на предмет соответствия
профилю. Измеритель определяет, находится ли данный класс потока па-
кетов в установленных пределах или превосходит уровень обслуживания,
гарантированный для этого класса.
• 4 Маркировщик. Управляет трафиком, при необходимости заново маркируя
пакеты различными кодами. Например, если для определенного класса
обслуживания гарантируется некоторая пропускная способность, любые
пакеты этого класса, превышающие пропускную способность в течение
определенного интервала времени, могут быть маркированы заново для
обслуживания по остаточному принципу. Кроме того, изменение маркиров-
ки может потребоваться на границе между двумя доменами дифференциро-
ванных служб. Например, пусть данный класс трафика должен получать
наивысший поддерживаемый приоритет. Предположим, что максимальный
560
Глава 17. Интегрированные и дифференцированные службы
приоритет в одном домене — 3, а в другом — 7. В этом случае при переходе
из первого домена во второй пакеты с приоритетом 3 должны маркировать
ся заново как пакеты с приоритетом 7.
♦ Формирователь. Управляет трафиком, задерживая при необходимости па-
кеты таким образом, чтобы поток пакетов данного класса не превышал ско-
рости трафика, указанного в профиле данного класса.
4 Отбрасывателъ. Отбрасывает пакеты, когда скорость пакетов данного клас-
са превышает скорость, указанную в профиле данного класса.
Рисунок 17.12 иллюстрирует взаимосвязи между элементами согласования тра-
фика. После того как поток классифицирован, следует измерить, сколько ресур-
сов он потребляет. Функция измерения определяет суммарный объем пакетов за
определенный период времени, чтобы выяснить, соответствует ли поток соглаше-
нию о трафике. Если хост посылает данные неравномерно, то просто измерить ско-
рость передачи данных, или скорость пакетов, для оценки характеристик трафика
может быть недостаточно. Схема маркерного ведра, такая как показана на рис. 17.2,
реализующая один из возможных механизмов определения профиля трафика, по-
зволяет учесть как частоту поступления пакетов, так и неравномерность трафика.
Рис. 17.12. Схема согласования трафика дифференцированных служб
Если трафик превышает определенный профиль, могут предприниматься раз-
личные действия. У отдельных пакетов, превышающих профиль, может быть из-
менена маркировка в сторону понижения класса обслуживания, после чего таким
пакетам будет разрешено войти в домен дифференцированных служб. Формиро-
ватель трафика может поглотить всплеск трафика с помощью своего буфера и рас-
пределить принятые пакеты на более длительный период времени. Отбрасывателъ
может отбросить пакеты, если используемый для регулирования скорости буфер
заполнен.
Поведение на ретрансляционном участке
При стандартизации дифференцированных служб следует определить некоторые
типы поведения на ретрансляционном участке (РНВ), которые могут ассоцииро-
ваться с различными дифференцированными службами. На текущий момент вы-
пущено два стандарта, описывающих типы поведения на ретрансляционном участ-
ке: срочное продвижение данных (RFC 2598) и гарантированное продвижение
данных (RFC 2597).
17.4. Дифференцированные службы
561
Срочное продвижение данных
В документе RFC 2598 срочное продвижение данных (Expedited Forwarding, EF)
определено как механизм, который может использоваться для предоставления так
называемой премиальной услуги (premium service). Премиальная услуга в доменах
дифференцированных служб представляет собой сквозное обслуживание с низкими
потерями, низкой задержкой, низкими флуктуациями и гарантированной пропуск-
ной способностью. По существу, с точки зрения конечных потребителей гаранти-
рованная услуга выглядит как соединение «точка — точка» или выделенная линия.
В объединенной сети или сети с коммутацией пакетов предоставить премиаль-
ную услугу чрезвычайно сложно. По своей природе объединенная сеть включает
очереди на каждом узле или маршрутизаторе, когда пакеты помещаются в буфер,
ожидая, пока освободится выходная линия коллективного доступа. Именно от по-
ведения этих очередей зависят такие параметры соединения, как потери, задержки
и флуктуация. Таким образом, при управлении трафиком, которому предоставля-
ется премиальная услуга, должны предприниматься специальные меры, гаранти-
рующие, что ожидание пакетов в очередях не приведет к превышению заданных
пределов значениями задержки, потерь и флуктуации. В документе RFC 2598 отме-
чается, что премиальная услуга подразумевает выполнение двух условий:
♦ Конфигурирование узлов таким образом, чтобы у агрегата трафика1 была
четко определенная (то есть независимая от динамического состояния узла,
в частности, от интенсивности остального трафика на этом узле) минималь-
ная скорость отправления.
♦ Согласование агрегата (путем регулирования и формирования) таким об-
разом, чтобы скорость его прибытия на любой узел всегда была ниже мини-
мальной скорости отправления, сконфигурированной для данного узла.
Срочное продвижение данных позволяет выполнить первое из этих условий,
тогда как второе условие выполняется сетевыми пограничными формирователями.
Общая концепция, представленная в RFC 2598, заключается в следующем. Погранич-
ные узлы управляют агрегатом трафика, чтобы ограничить его характеристики
(скорость, неравномерность) до некоторого заранее определенного уровня. Внутрен-
ние узлы должны обращаться с входящим трафиком таким образом, чтобы не воз-
никало длинных очередей. В общих словах, требование, предъявляемое к трафику
на каждом внутреннем узле, заключается в том, что максимальная скорость прибы-
тия агрегата должна быть меньше минимальной скорости отправления агрегата.
В RFC 2598 не указывается конкретная политика организации очередей на
внутренних узлах, позволяющая достичь срочного продвижения данных (EF)
в качестве типа поведения на ретрансляционном участке. В RFC 2598 отмечается,
что желаемого эффекта можно добиться с помощью простой приоритетной схе-
мы, в которой EF-трафику предоставляется абсолютный приоритет по сравнению
с остальным трафиком. До тех пор пока сам EF-трафик не переполнит внутрен-
ний узел, эта схема будет предоставлять приемлемые задержки для службы сроч-
ного продвижения данных. Однако в простой приоритетной схеме есть риск унич-
1 Термин агрегат трафика (traffic aggregate) обозначает поток пакетов, ассоциированный с определен-
ным обслуживанием конкретного пользователя.
562
Глава 17. Интегрированные и дифференцированные службы
тожеиия потоков пакетов других видов трафика. Таким образом, может потребо-
ваться более сложная политика организации очередей.
Гарантированное продвижение данных
Гарантированное продвижение данных (Assured Forwarding, AF) призвано предо-
ставлять обслуживание, лучшее, чем обслуживание по остаточному принципу, но
не требующее резервирования ресурсов в объединенной сети, а также не требующее
детального разграничения потоков разных пользователей. В основе гарантирован-
ного продвижения данных лежит понятие явного выделения ресурсов (explicit
allocation), впервые предложенное в [54]. Гарантированное продвижение данных
сложнее, чем явное выделение ресурсов, но будет полезным сначала рассмотреть
ключевые элементы схемы явного выделения ресурсов:
1. Пользователям предоставляется выбор из нескольких классов обслуживания
для их трафика. Каждый класс описывается отдельным профилем трафика
в терминах скорости передачи и неравномерности агрегированных данных.
2. Поступающий от пользователя трафик наблюдается на пограничном узле.
Каждый пакет трафика маркируется в зависимости от того, соответствует
он профилю трафика или нет.
3. В сети не производится разграничения трафика разных пользователей и раз-
ных классов обслуживания. Вместо этого весь трафик обрабатывается как
единое множество пакетов, отличающихся друг от друга только маркиров-
кой (соответствует пакет профилю трафика или нет).
4. В случае возникновения перегрузки внутренние узлы задействуют схему
отбрасывания пакетов, в первую очередь отбрасывающую пакеты, маркиро-
ванные как не соответствующие профилю трафика.
5. Различные пользователи получат разные уровни обслуживания, так как
в очередях на обслуживание у них будет разное количество пакетов, марки-
рованных как соответствующие профилю трафика.
Преимущество такого подхода заключается в его простоте. От внутренних уз-
лов требуется минимум усилий. Маркировка трафика на пограничных узлах на
основе профилей трафика обеспечивает предоставление разным классам различ-
ных уровней обслуживания.
Определенная в RFC 2597 схема гарантированного продвижения данных рас-
ширяет предыдущий подход в нескольких направлениях:
♦ Определяются четыре класса гарантированного продвижения данных, что по-
зволяет указать четыре разных профиля трафика. Пользователь может выбрать
один или несколько из этих классов для удовлетворения своих требований.
♦ В каждом классе пакеты маркируются клиентом или поставщиком услуг
одним из трех значений очередности отбрасывания. При возникновении
перегрузки по маркировке очередности отбрасывания определяется относи-
тельная важность пакета в пределах класса гарантированного продвижения
данных. Перегруженный DS-узел пытается защитить пакеты с более низким
значением очередности отбрасывания от потерь, отбрасывая в первую оче-
редь пакеты с более высоким значением очередности отбрасывания.
i
17.5. Трафик реального времени
563
Такой подход еще проще реализовать, чем любую разновидность схемы ре-
зервирования ресурсов, и, тем не менее, он обеспечивает значительную гибкость.
На внутреннем DS-узле трафик четырех различных классов может обрабатывать-
ся раздельно, при этом четырем классам будет выделяться разный объем ресурсов
(буферное пространство, скорость передачи данных). Таким образом, как отмеча-
ется в RFC 2597, уровень гарантий продвижения IP-пакета зависит от следующих
факторов:
♦ объема ресурсов, выделенных AF-классу, которому принадлежат пакеты,
для их продвижения;
4 текущей нагрузки AF-класса;
4 очередности отбрасывания пакета.
В RFC 2597 не указывается определенного механизма, применяемого на внут-
ренних узлах для управления AF-трафиком. В нем упоминается алгоритм RED
(Random Early Detection — случайное раннее обнаружение) в качестве возможно-
го средства борьбы с перегрузкой.
Ниже перечислены рекомендованные DS-коды для гарантированного продвиже-
ния данных (AF) в качестве типа поведения на ретрансляционном участке (рис. 17.13).
Селектор класса:
4 100 - класс 4 (наилучшее обслуживание);
♦011— класс 3;
4 010 — класс 2;
4 001 — класс 1.
Очередность отбрасывания:
4 010 — низкая (наиболее важные пакеты);
4 100 — средняя;
4 110 — высокая (наименее важные пакеты).
3 бита 3 бита 2 бита
Селектор класса Очередность отбрасывания Не используется
DS-код
Поле DS
Рис. 17.13. Поле DSflnn службы гарантированного продвижения данных
17.5. Трафик реального времени
Развертывание высокоскоростных локальных и глобальных сетей и увеличение
пропускной способности линий Интернета и других объединенных сетей сделало
возможным использование IP-сетей для переноса трафика реального времени.
564
Глава 17. Интегрированные и дифференцированные службы
Однако важно понимать, что требования трафика реального времени отличаются
от требований обычного высокоскоростного трафика.
В традиционных Интернет-приложениях, таких как приложения передачи фай-
лов, электронная почта и приложения клиент-сервер, включая веб-приложения
как правило, важны такие характеристики, как пропускная способность и задержка
Также важна надежность, поэтому применяются специальные методы, гарантирую-
щие, что данные не будут потеряны или повреждены при передаче, а также будут
доставлены в правильном порядке. В отличие от подобных приложений, для прило-
жений реального времени важнее временные параметры. В большинстве случаев
имеется требование доставки данных с постоянной скоростью, равной скорости их
передачи. В других случаях у каждого блока данных есть крайний срок доставки, то
есть по истечении определенного срока такие данные становятся бесполезными.
Характеристики трафика реального времени
На рис. 17.14 показано типичное окружение реального времени. Сервер генериру-
ет аудиоданные, которые должны передаваться со скоростью 64 Кбит/с. Оцифро-
ванный аудиосигнал передается в пакетах, содержащих по 160 байт данных, так
что передается по одному пакету через каждые 20 мс. Эти пакеты пропускаются
через объединенную сеть и доставляются на мультимедийный персональный ком-
пьютер, воспроизводящий этот аудиосигнал в режиме реального времени сразу,
когда пакеты прибывают. Однако поскольку объединенная сеть задерживает пе-
редаваемые по ней пакеты на непостоянные интервалы времени, пакеты не будут
прибывать через фиксированные интервалы времени в 20 мс. Чтобы компенсиро-
вать неравномерность поступления данных, входящие пакеты буферизируются,
слегка задерживаются, а затем с постоянной скоростью передаются программно-
му обеспечению, воспроизводящему звук.
Возможности компенсации при помощи буфера ограничены. Чтобы понять это,
нам нужно дать определение понятию флуктуации задержки (delay jitter), под
которой понимается максимальное изменение величины задержки пакетов в те-
чение одного сеанса. Например, если минимальная сквозная задержка каждого па-
кета равна 1 мс, а максимальная задержка — 6 мс, тогда флуктуация задержки рав-
на 5 мс. До тех пор пока буфер задерживает входящие пакеты, по меньшей мере,
на 5 мс, в выходной поток буфера попадут все входящие пакеты. Однако если буфер
задерживает пакеты только на 4 мс, тогда любой пакет, запаздывающий относи-
тельно остальных пакетов более чем на 4 мс (с абсолютной задержкой более 5 мс),
отбрасывается, так как пакеты нельзя воспроизводить в неверном порядке.
Описание трафика реального времени подразумевает последовательность па-
кетов равного размера, генерируемых с постоянной частотой. Данное описание не
всегда соответствует профилю трафика. На рис. 17.15 показаны некоторые воз-
можные варианты.
♦ Источник монотонных данных. Пакеты фиксированного размера генери-
руются через фиксированные интервалы времени. Такая характеристика
соответствует приложениям, непрерывно генерирующим данные, облада-
ющие невысокой избыточностью и слишком важные, чтобы применять к
ним алгоритм сжатия с потерями. Среди примеров можно назвать данные
17.5. Трафик реального времени
565
радара, управляющего движением самолетов, а также симуляторы реаль-
ного времени.
Пакеты прибывают через неравные интервалы
Пакеты доставляются
с исходными интервалами
(некоторые пакеты могут теряться)
Получатель — мультимедийный
персональный компьютер
Рис. 17.14. Трафик реального времени
♦ Двухпозиционный источник. Периоды активности источника, в течение кото-
рых он генерирует пакеты фиксированного размера через фиксированные ин-
тервалы времени, чередуются с периодами бездействия. Данному профилю со-
ответствует такой источник, как телефонный аппарат или аудиоконференция.
♦ Источник пакетов переменного размера. Источник генерирует пакеты пере-
менного размера через равные интервалы времени. Примером такого источ-
ника данных является оцифрованное видео, в котором разные пакеты могут
быть сжаты с разным коэффициентом сжатия при одном и том же уровне
качества выходных данных1.
' Сжатие видеоданных описывается в главе 21.
566
Глава 17. Интегрированные и дифференцированные службы
Рис. 17.15. Передача пакетов реального времени (по [8])
Требования к взаимодействию
в реальном времени
В [8] перечисляются следующие желательные свойства взаимодействия в реаль-
ном времени:
♦ небольшая флуктуация;
♦ небольшая задержка;
♦ способность легко объединять службы реального времени с прочими служ-
бами;
♦ адаптируемость к динамически изменяющимся условиям сети и трафика;
+ хорошая производительность в больших сетях, а также при большом коли-
честве соединений;
скромные требования к размерам буферов в сети;
+ высокий коэффициент использования сети;
♦ низкие накладные расходы в битах заголовка на пакет;
♦ низкие расходы на обработку в сети и на оконечных системах в единицах
обработки на пакет.
Эти требования трудно выполнить в глобальной или объединенной 1Р-сети.
Протоколы TCP и UDP сами по себе не соответствуют данным требованиям. Как
мы увидим, разумную основу для их решения предоставляет протокол RTP.
Жесткие и гибкие приложения реального времени
Следует разграничить жесткие и гибкие приложения реального времени. Гибкие
приложения реального времени могут выдержать потерю некоторой части данных,
17.6. Рекомендуемые литература и веб-сайты
567
тогда как жесткие приложения реального времени не допускают потери данных.
В общем, гибкие приложения реального времени предъявляют меньшие требо-
вания к сети и поэтому допускают оптимизацию использования сети даже за
счет потери некоторых пакетов или доставки некоторых пакетов в неверном
порядке. В жестких приложениях реального времени соображения относительно
соответствия трафика ограничениям на флуктуацию и соображения относи-
тельно его высокой надежности преобладают над проблемой оптимизации исполь-
зования сети.
17.6. Рекомендуемые литература
и веб-сайты
Возможно, самое понятное и наиболее всеобъемлющее описание материала дан-
ной главы — это [13]. В [205] содержится прекрасный анализ логического обосно-
вания архитектуры объединенных сетей, основанной на дифференцированном
обслуживании. В [241] предоставляются обзор и общая система взглядов относи-
тельно качества обслуживания в Интернете, а также интегрированных и диффе-
ренцированных служб. Вполне доступное для читателя обозрение многих вопро-
сов, относящихся к предоставлению обслуживания с гарантированным качеством
в Интернете, содержится в [74].
RFC 1633 представляет собой определяющий для архитектуры интегрирован-
ных служб документ, в котором содержится прекрасный обзор данной темы. В [52]
и [53] обсуждаются вопросы обслуживания в объединенных сетях приложений
реального времени, а также эластичных приложений соответственно. [236] представ-
ляет собой подробный обзор архитектуры интегрированных служб. Книга [246]
посвящена теме дисциплин очередей, которые могут применяться в архитектуре
ISA, включая анализ схем справедливой организации очередей FQ и WFQ. В [52]
имется анализ схемы WFQ, а также некоторых альтернативных дисциплин. В [84]
рассматривается проблема влияния на возможность перегрузки растущего трафи-
ка, обслуживаемого с максимальными усилиями (по остаточному принципу), для
которого не применяются механизмы борьбы с перегрузкой протокола TCP, а так-
же меры, которые могут предпринимать маршрутизаторы, включая стратегии орга-
низации очередей и отбрасывания пакетов, обсуждавшиеся в данной главе.
В [233] содержится поучительное обсуждение дифференцированных служб,
тогда как в [142] рассматриваются дифференцированные службы и механизмы
поддержки маршрутизаторов, не описанные в текущих документах RFC. Деталь-
ное обсуждение дифференцированных служб имеется в [135].
Две статьи, в которых сравниваются интегрированные и дифференцированные
службы в терминах обслуживания и производительности, — это [27] и [112].
Рекомендуемые веб-сайты перечислены ниже:
♦ QoS Forum. Сайт группы, производящей самое разнообразное оборудование.
Посвящен продвижению стандартов качества обслуживания, относящих-
ся к Интернету. Включает полезные ответы на часто задаваемые вопросы
и массу технической документации.
568
Глава 17. Интегрированные и дифференцированные службы
♦ Differentiated services working group. Сайт рабочей группы, созданной с раз-
решения IETF для разработки стандартов, относящихся к дифференциро-
ванным службам. Включает все относящиеся к данной теме документы RFC
а также проекты Интернет-документов.
♦ Integrated services working group. Сайт рабочей группы, созданной с разреше-
ния LETF для разработки стандартов, относящихся к интегрированным
службам. Включает все относящиеся к данной теме документы RFC, а так-
же проекты Интернет-документов.
17.7. Задания
1. Стандарт IPv6 утверждает, что если на маршрутизатор прибывает пакет с
ненулевой меткой потока, а у маршрутизатора нет информации для этой
метки потока, тогда маршрутизатор должен игнорировать метку потока и пе-
реправить пакет.
а) каковы недостатки обработки данного события как ошибки, отбрасыва-
ния пакета и передачи ICMP-сообщения;
б) существуют ли ситуации, в которых маршрутизация пакета, как если бы
его метка потока была нулевой, приведет к неверному результату? Аргу-
ментируйте свой ответ.
2. Механизм управления потоком IPv6 предполагает, что информация о состо-
янии, ассоциированная с данной меткой потока, хранится на маршрутиза-
торах, так что маршрутизаторы знают, как обрабатывать пакеты с данной
меткой потока. Стандарт требует удалять информацию о метках потока, ко-
торые более не используются (устаревших метках потока).
а) предположим, что, заканчивая работу с потоком и удаляя метку потока,
источник всегда посылает управляющее сообщение всем маршрутизато-
рам, которых это касается. Как могла бы в этом случае сохраниться уста-
ревшая метка потока;
б) предложите механизмы для маршрутизатора и источника, позволяющие
решить проблему устаревших меток потока.
3. Возникает вопрос, какие пакеты, генерируемые источником, должны нести
ненулевые метки протокола IPv6. Для некоторых приложений ответ оче-
виден. При обмене небольшими порциями данных пакеты должны иметь
нулевые метки, так как не имеет смысла создавать потоки для нескольких
пакетов. Снабжаться метками должны потоки реального времени, для ко-
торых, в первую очередь, и создавались метки потоков. Более сложный
вопрос заключается в том, что делать с хостами, посылающими большие
объемы трафика, обслуживаемого по остаточному принципу (например,
TCP-соединений). Приведите доводы в пользу назначения каждому долго-
срочному TCP-соединению уникальной метки потока. Приведите аргумен-
ты в пользу того, Чтобы этого не делать.
17.7. Задания
569
4. В оригинальной спецификации протокола IPv6 ноля класса трафика и мет-
ки потока объединены в одно 28-разрядное поле метки потока. Это позво-
ляет потоку переопределить интерпретацию различных классов трафика.
Выскажите предположение, по какой причине в окончательную специфи-
кацию было включено поле класса трафика в качестве отдельного поля.
5. Ясно, что если маршрутизатор выполняет предпочтительное обслуживание
одного потока или одного класса потоков, тогда этот поток или класс пото-
ков получит обслуживание более высокого качества. Не столь очевидным
является улучшение обслуживания в объединенной сети в целом. Рассмот-
рим сеть с одной линией связи, моделируемой экспоненциальным сервером
со скоростью Т, = 1. Также рассмотрим два класса потоков с распределенны-
ми по Пуассону скоростями прибытия XI = Х2 = 0,25, функции использова-
ния которых равны [Д = 4 - 2Тд и U2 = 4 - Тч2, где Тч, обозначает среднюю
задержку ожидания в очереди для класса г. Таким образом, трафик класса 1
является более чувствительным к задержке, чем трафик класса 2. Опреде-
лим суммарный коэффициент использования сети как V= Ui + U2.
а) предположим, что оба класса обслуживаются одинаково и что приме-
няется дисциплина организации очереди FIFO. Чему равен суммарный
коэффициент использования сети V;
б) предположим, что применяется простое обслуживание в соответствии
с приоритетами, так что пакеты класса 1 всегда передаются прежде паке-
тов класса 2. Чему равен суммарный коэффициент использования сети V?
Прокомментируйте полученный результат.
6. Схема маркерного ведра устанавливает ограничение на интервал времени,
в течение которого трафик может передаваться с максимальной скоростью
передачи данных. Пусть определено маркерное ведро размером Ь байт со
скоростью поступления маркеров г байт в секунду и пусть максимальная
выходная скорость передачи данных равна М байт в секунду.
а) выведите формулу для вычисления длительности интервала передачи
данных с максимальной скоростью S. То есть в течение какого интервала
времени поток передает данные с максимальной скоростью, если пото-
ком управляет маркерное ведро;
б) чему равно значение S для b = 250 Кбайт, г= 2 Мбайт/с, а М= 25 Мбайт/с?
Подсказка: формула для S не так проста, как это может показаться, пото-
му что за время передачи данных с максимальной скоростью прибывают
дополнительные маркеры.
7. Дисциплину организации очередей GPS, описываемую в разделе 17.2, мож-
но определить следующим образом. Пусть 5,(т, Г) представляет собой объем
потока z, переданного за интервал времени |т, Г]. В этом случае GPS-сервер
определяется как сервер, для которого выполняется показанная далее фор-
мула. Подтвердите правильность этого определения, показав, что из него
можно вывести формулу (17.3).
=112..N
Ф,
570 Глава 17. Интегрированные и дифференцированные службы
8. В алгоритме RED нужно установить ряд параметров. Рассмотрим некото-
рые вопросы разработки данного алгоритма.
а) как связаны выбираемое значение THmin и степень неравномерности тра-
фика;
б) как связаны значение (ТНтях - THmm) и типичное время прохождения
сигнала в оба конца, наблюдаемое ТСР-сущностью?
9. Один источник видеоданных передает в секунду 30 кадров, в каждом из
которых содержится по 2 Мбайт данных. Флуктуация задержки данных
составляет 1 с. Какого размера буфер требуется для устранения флукту-
ации?
Глава 18
Протоколы поддержания
качества обслуживания
Читатель, дочитавший кишу до этого места, сможет оце-
нить все трудности, которые пришлось преодолеть, опас-
ности, встретившиеся па пути, ошибки, которые были
допущены, и труд, который был вложен.
Уинстон Черчилль. Мировой кризис
Как уже отмечалось в этой книге, требования, предъявляемые к компьютерным
сетям, постоянно ужесточаются. Традиционные информационно-ориентирован-
ные приложения, такие как передача файлов, электронная почта, новости USENET
и приложения клиент-сервер, оказывают все большую нагрузку на локальные сети,
Интернет и частные объединенные сети. Эта возрастающая нагрузка вызвана не
только увеличением количества пользователей и увеличением времени, которое
они проводят в сетях, но также все более широким использованием графики. В то
же время, в последние годы все увеличивающуюся долю сетевого трафика зани-
мают аудио- и видеоданные. Для обслуживания таких мультимедийных приложе-
ний в качестве одного из вариантов можно использовать сочетание выделенных
линий с технологией ATM. Однако потребности в передаче мультимедийных дан-
ных растут столь стремительно, что для создания полноценной инфраструктуры
ATM, объединяющей конечных пользователей, просто нет времени. В Интернете
и корпоративных объединенных сетях наблюдается экспоненциальный рост доли
аудио- и видеоданных на веб-страницах. Кроме того, эти сети применяются для
аудио- и видеоконференций, а также для обслуживания других приложений с груп-
повой рассылкой аудио- и видеоданных.
Таким образом, бремя выполнения новых требований ложится на плечи архи-
тектуры TCP/IP, реализуемой поверх инфраструктуры сетей с пакетной передачей
данных. Центральные вопросы, которые необходимо решить, касаются пропуск-
ной способности и неравномерности. Аудио- и видеоприложения генерируют ог-
ромное количество битов в секунду, при этом трафик должен передаваться в виде
равномерного постоянного потока. Все это разительно отличается от передачи тра-
диционных данных, таких как текст, файлы и графика, для которых вполне при-
емлемым является неравномерный поток пакетов.
572
Глава 18. Протоколы поддержания качества обслуживания
В отсутствие универсальной службы ATM разработчики искали способы под-
держки в архитектуре TCP/IP как неравномерного трафика, так и постоянного
потока данных. Для решения проблемы были испробованы различные взаимодо-
полняющие методы:
Для поддержания увеличивающегося объема трафика корпоративные ло-
кальные и глобальные сети, а также магистрали Интернета и корпоратив-
ные объединенные сети были усовершенствованы путем установки более
высокопроизводительных коммутаторов и маршрутизаторов, а также высо-
коскоростных линий передачи данных. Однако такой подход является не-
экономичным. Кроме того, учитывая самоподобную природу большей час-
ти трафика (см. главу 9), практически невозможно простым наращиванием
мощностей обрабатывать трафик в периоды пиковых нагрузок. Соответствен-
но, разумные политики маршрутизации (см. часть V) совместно со сквозны-
ми методами управления потоками (см. главу 12) крайне важны для обра-
ботки больших объемов данных в этих сетях.
Мультимедийные приложения неизбежно подразумевают групповую рас-
сылку. Соответственно, необходимы эффективные методы групповой рас-
сылки данных в объединенных сетях. Эта тема обсуждалась в главе 15.
Пользователи должны иметь возможность разумно резервировать сетевые
ресурсы, а также назначать приоритеты различным типам трафика. По сути,
в объединенных сетях необходима поддержка разных уровней качества об-
служивания.
♦ Необходим транспортный протокол, соответствующий требованиям видео-
трафика или другого трафика реального времени.
Первые два подхода рассматривались в других главах. В этой главе обсужда-
ются некоторые ключевые протоколы, поддерживающие различные уровни каче-
ства обслуживания в Интернете. Мы начнем с протокола RSVP (Resource reSerVation
Protocol — протокол резервирования ресурсов), разработанного в качестве составной
части архитектуры интегрированных служб (ISA). Затем мы рассмотрим архитек-
туру MPLS (MultiProtocol Label Switching — многопротокольная коммутация по
меткам) и закончим протоколом RTP (Real-time Transport Protocol — транспорт-
ный протокол реального времени).
18.1. Протокол RSVP
Ключевая задача объединенной сети заключается в доставке данных от источника
одному или нескольким получателям с желаемым уровнем качества обслуживания
(пропускной способностью, задержкой, изменением задержки и т. д.). Сложность
этой задачи в любой объединенной сети возрастает с увеличением количества
пользователей и скоростей передачи данных приложениями, а также с использо-
ванием групповой рассылки. Как мы видели, один из методов удовлетворения этих
растущих требований заключается в динамической маршрутизации. Схема динами-
ческой маршрутизации, поддерживаемая такими протоколами, как OSPF и BGP.
18.1. Протокол RSVP
573
способна быстро реагировать на возникновение неисправностей в объединенной
сети, выбирая маршруты в обход проблемных точек. Что более важно, схема ди-
намической маршрутизации может до определенной степени бороться с пере-
грузкой, во-первых, балансируя нагрузку, то есть равномерно распределяя нагруз-
ку в объединенной сети, и, во-вторых, выбирая пути в обход областей, в которых
возникла перегрузка, с помощью алгоритмов определения маршрутов с наименьшей
стоимостью. В случае групповой рассылки схемы динамической маршрутизации
были дополнены методами групповой маршрутизации, использующими преиму-
щество разделяемых путей от источника до групп получателей и позволяющими
минимизировать дублирование пакетов.
Кроме того, маршрутизаторы имеют возможность обрабатывать пакеты на
основе метки качества обслуживания. Как мы видели, маршрутизаторы могут,
во-первых, использовать дисциплину очередей, отдающую предпочтение пакетам
с более высокими значениями меток качества обслуживания; во-вторых, выбирать
маршруты на основе характеристик качества обслуживания каждого пути; в-тре-
тьих, по возможности вызвать службу поддержания качества обслуживания в под-
сети следующего ретрансляционного участка.
Все эти методы позволяют справляться с трафиком, поступающим в объеди-
ненную сеть, но они ни в коей мере не являются профилактическими. Используя
только динамическую маршрутизацию и различные уровни качества обслужива-
ния, маршрутизатор не может предвидеть возникновение перегрузки и не допус-
тить, чтобы приложение вызвало эту перегрузку. Вместо этого маршрутизатор
просто предоставляет обслуживание по остаточному принципу, когда некоторые
пакеты могут быть потеряны, а остальные пакеты доставлены с уровнем качества
обслуживания ниже запрашиваемого.
По мере роста требований к объединенным сетям оказывается, что необходимо
не только реагировать на возникшую перегрузку, но и предотвращать ее возник-
новение. Как показано в данном разделе, стратегия предотвращения перегрузки
может быть реализована путем резервирования ресурсов.
Превентивные меры могут быть полезны как при целевой, так и при групповой
рассылке. В случае целевой рассылки два приложения договариваются об опреде-
ленном уровне качества обслуживания в данном сеансе связи и ожидают, что объ-
единенная сеть поддержит этот уровень. Если объединенная сеть сильно загруже-
на, она не сможет предоставить желаемого уровня качества обслуживания и будет
доставлять пакеты со сниженным уровнем качества. В этом случае приложения
могут предпочесть подождать, прежде чем инициировать сеанс, или изменить
режим работы, приспосабливаясь к сниженному уровню качества обслуживания.
В подобной ситуации, чтобы получить обслуживание желаемого уровня качества,
можно резервировать ресурсы. Маршрутизаторы, расположенные вдоль пути сле-
дования пакетов, могут заранее зарезервировать ресурсы (пространство в очере-
дях, выходящую пропускную способность), чтобы гарантировать требуемое каче-
ство обслуживания. Если маршрутизатор не может зарезервировать необходимый
объем ресурсов, он должен информировать приложения, запрашивавшие данную
услугу. При этом приложения могут запросить услугу, требующую меньших ре-
сурсов, или попытаться получить нужное обслуживание позднее.
574
Глава 18. Протоколы поддержания качества обслуживания
Групповая рассылка представляет собой значительно более сложный случай
в плане резервирования ресурсов. Если приложение при групповой рассылке
генерирует большие объемы данных (например, видеоданных) или группа получа-
телей насчитывает большое число членов и сильно разбросана, то групповая рассыл-
ка может породить огромные объемы сетевого трафика. Вопрос резервирования
ресурсов для групповой рассылки усложняется тем, что большую часть потенциаль-
ной нагрузки, генерируемой источником групповой рассылки, можно предотвра-
тить. Этому есть две причины:
4 Некоторым членам существующей группы рассылки может не требоваться
доставка данных от определенного источника в течение некоторого задан-
ного времени. Например, может существовать два «канала» (два источника
групповой рассылки), одновременно ведущих передачу для определенной
группы рассылки. Некоторые из получателей могут пожелать «настроить-
ся» только на один канал.
♦ Возможно, некоторые члены группы рассылки способны обрабатывать толь-
ко часть передаваемых источником данных. Например, источник видеодан-
ных может передавать видеопоток, состоящий из двух составляющих: основ-
ного компонента, предоставляющего изображение пониженного качества, и
дополнительного компонента, позволяющего получить картинку более вы-
сокого качества1. Некоторые приемники могут не обладать достаточной
мощностью для обработки дополнительной составляющей или их соедине-
ние с объединенной сетью через подсеть или через канал может не обладать
достаточной пропускной способностью для полного сигнала.
Таким образом, резервирование ресурсов может позволить маршрутизаторам
заранее решить, смогут ли они удовлетворить запрашиваемые требования по дос-
тавке групповых пакетов всем членам группы рассылки и зарезервировать необ-
ходимые ресурсы.
Резервирование ресурсов в объединенных сетях отличается от резервирования
ресурсов, которое может быть реализовано в сетях, ориентированных на соедине-
ние, таких как сети ATM или сети ретрансляции кадров. Схема резервирования
ресурсов в объединенных сетях должна взаимодействовать со схемой изменения
маршрутов пакетов. При изменении маршрута должна меняться и схема резерви-
рования ресурсов. Чтобы справиться с этой динамической ситуацией, использу-
ется концепция гибкого состояния (soft state). Гибким состоянием называют ин-
формацию о состоянии маршрутизатора, актуальность которой истекает, если ее
регулярно не обновлять. Если маршрут для данной передачи изменяется, тогда
некоторые гибкие состояния становятся недействительными и для нового резер-
вирования ресурсов требуются гибкие состояния новых маршрутизаторов вдоль
маршрута. Таким образом, оконечные системы, запрашивающие ресурсы, во время
работы приложений должны периодически повторять свои запросы о состоянии.
Теперь мы рассмотрим протокол RSVP2, разработанный для резервирования
ресурсов в объединенных сетях.
1 Например, такую возможность предоставляет стандарт видеосжатня MPEG, который будет обсуж-
даться в главе 21.
2 RFC 2205, Resource reSerVation Protocol (RSVP) Version 1 Functional Specification, сентябрь 1997.
18.1. Протокол RSVP
575
Цели разработки и характеристики протокола RSVP
Возможно, лучший способ познакомиться с протоколом RSVP (Resource reSerVation
Protocol — протокол резервирования ресурсов) заключается в том, чтобы перечис-
лить цели создания и характеристики протокола. В [245] разработчики протокола
RSVP перечисляют следующие цели, преследовавшиеся при его разработке:
♦ Предоставление разнородным получателям возможности резервировать ре-
сурсы специально под собственные нужды. Как упоминалось, некоторые
члены группы рассылки могут иметь возможность или желание обрабаты-
вать только часть передаваемых данных, например только тот компонент
видеосигнала, который позволяет получать изображение низкого разреше-
ния. Протокол должен допускать дифференцированное резервирование ре-
сурсов для членов одной группы рассылки.
♦ Протокол должен адекватно реагировать на изменения в составе групп рас-
сылки. Членство в группе может быть динамическим. Таким образом, ре-
зервирование также должно быть динамическим, и это снова предполагает
необходимость раздельного динамического резервирования для каждого
члена группы рассылки.
♦ Требования по резервированию ресурсов должны указываться таким обра-
зом, чтобы агрегированные ресурсы, зарезервированные для группы рассыл-
ки, отражали реальные потребности. Групповая рассылка осуществляется
по дереву, так что дублирование пакетов сводится к минимуму. Поэтому
когда ресурсы резервируются для отдельных членов группы рассылки, за-
явки на предоставление ресурсов должны рассматриваться вместе, чтобы
учесть возможность дублирования пакетов.
♦ Протокол должен позволять получателям выбирать один источник из не-
скольких доступных, передающих данные группе рассылки. Это упомяну-
тая ранее возможность смены канала.
♦ Протокол должен адекватно реагировать на изменения в маршрутах, авто-
матически заново резервируя ресурсы вдоль новых маршрутов при условии,
что соответствующие ресурсы доступны. Поскольку маршруты могут изме-
няться в процессе работы передающего приложения, резервирование ресур-
сов также должно меняться таким образом, чтобы маршрутизаторы, распо-
ложенные вдоль текущего маршрута, получали заявки на резервирование
ресурсов.
♦ Протокол должен следить за собственными накладными расходами. Подоб-
но тому, как собираются вместе заявки на предоставление ресурсов, что по-
зволяет экономить ресурсы за счет общих сегментов маршрута у несколь-
ких членов группы рассылки, также и сообщения с запросами протокола
RSVP должны объединяться, чтобы минимизировать трафик самого прото-
кола в объединенной сети.
♦ Протокол резервирования ресурсов не должен зависеть от протокола марш-
рутизации. Протокол RSVP не является протоколом маршрутизации. Его
назначение — резервирование ресурсов вдоль маршрута или дерева достав-
ки независимо от того, как был создан этот маршрут или это дерево.
576 Глава 18. Протоколы поддержания качества обслуживания
В документе RFC 2205 перечислены характеристики протокола RSVP: Я
4 Целевая и групповая рассылки. Протокол RSVP позволяет резервировать
ресурсы как для целевой, так и для групповой рассылки, динамически при- и
спосабливаясь к изменению состава групп, маршрутов и индивидуальных
требований членов групп рассылки.
4 Симплексная передача. Протокол RSVP позволяет резервировать ресурсы
для однонаправленных потоков данных. Для обмена данными между двумя
оконечными системами необходимо раздельное резервирование ресурсов
в двух направлениях.
4 Резервирование, инициированное получателем. Получатель потока данных
инициирует резервирование ресурсов для этого потока и управляет этим
резервированием.
4 Поддержка гибкого состояния в объединенной сети. Протокол RSVP поддер-
живает гибкое состояние на промежуточных маршрутизаторах.
4 Предоставление различных стилей резервирования. Благодаря различным
стилям резервирования пользователи протокола RSVP могут указывать, как
следует агрегировать заказы на резервирование ресурсов на промежуточных
коммутаторах. Это позволяет более эффективно использовать ресурсы объ-
единенной сети.
4 Прозрачное функционирование маршрутизаторов, не использующих про-
токол RSVP. Поскольку резервирование ресурсов и протокол RSVP не за-
висят от протоколов маршрутизации, в смешанном окружении, в котором
некоторые маршрутизаторы могут не использовать протокол RSVP, конф-
ликта не возникает. Такие маршрутизаторы просто передают данные по ос
таточному принципу.
4 Поддержка протпоколов IPv4 и IPv6. Протокол RSVP может использовать
поле типа службы в заголовке IPv4 и поле метки потока в заголовке IPv6.
Такие две характеристики протокола, как резервирование, инициированное
получателем, и гибкое состояние, стоит обсудить особо.
Резервирование, инициированное получателем
Рассматривавшиеся ранее методы резервирования ресурсов, а также подход, при-
меняемый в сетях ATM и сетях ретрансляции кадров, позволяют источнику пото-
ка данных запросить определенный набор ресурсов. Приложение получает воз-
можность передавать данные с определенной скоростью и получать обслуживание
определенного уровня качества, причем эти характеристики встраиваются в схе-
му передачи данных. Однако такой подход не годится для групповой рассылки.
Как уже упоминалось, у различных членов одной и той же группы рассылки могут
быть разные потребности в ресурсах. Если передаваемый источником поток дан-
ных может быть разделен на составляющие подпотоки, тогда отдельные члены
группы рассылки могут удовлетвориться приемом только одного из подпотоков.
Если трансляцию для группы получателей ведут одновременно несколько источ-
ников, то, возможно, некоторые члены группы захотят принимать передачу тольу
/
18.1. Протокол RSVP
577
ко от одного источника или от подмножества источников. Наконец, требования к
качеству обслуживания у разных получателей также могут различаться в зависи-
мости от оконечного оборудования, обрабатывающих мощностей и пропускной
способности канала получателя.
Таким образом, резервировать ресурсы имеет смысл скорее для получателей,
чем для отправителей. Отправитель обязан предоставить маршрутизаторам харак-
теристики трафика (скорость передачи данных, ее неравномерность), но желаемый
уровень качества обслуживания должны указывать получатели. Затем маршрути-
заторы могут проанализировать совокупные заявки на предоставление ресурсов,
чтобы учесть общие участки маршрута в дереве распределения.
Гибкое состояние
В протоколе RSVP используется концепция гибкого состояния. Это понятие, пред-
ложенное в [50], его стоит процитировать1.
Хотя дейтаграмма очень хорошо служила для решения самых важных задач
Интернета, оказалось, что решить такие задачи, как управление ресурсами и учет,
весьма непросто. Большинство дейтаграмм на прикладном уровне представляют
собой часть некоторой последовательности пакетов от источника до получателя, а
не изолированные блоки данных. Однако шлюз не может сам определить факт на-
личия данной последовательности, так как работает с каждым пакетом отдельно.
Поэтому и решение об управлении ресурсами или учете принимается для каждо-
го пакета отдельно.
Таким образом, можно предположить, что для архитектуры следующего поко-
ления должен использоваться более подходящий «строительный блок», нежели
дейтаграмма. Общая характеристика этого строительного блока заключается в том,
что он будет идентифицировать последовательность пакетов, направляющуюся от
источника к получателю. Для данного строительного блока я использовал термин
«поток» (flow). На шлюзах должна храниться информация о состоянии текущих
через них потоков, но эта информация не должна быть критичной для поддержа-
ния типа обслуживания, ассоциированного с потоком. Напротив, тип обслужива-
ния должны заказывать оконечные точки путем периодической отправки сообще-
ний, гарантирующих, что с данным потоком будет ассоциирован соответствующий
тип обслуживания. Таким образом, ассоциированная с потоком информация о со-
стоянии этого потока может быть потеряна в случае сбоя, не вызвав окончатель-
ной недоступности выбранного типа обслуживания. Я называю эту концепцию
гибким состоянием.
По существу, в ориентированных на соединение схемах применяется подход
жесткого состояния, в котором природа соединения вдоль фиксированного марш-
рута определяется информацией о состоянии, хранящейся на промежуточных ком-
мутирующих узлах. В протоколе RSVP используется метод гибкого состояния, то
есть метод, не требующий соединения, в котором состояние зарезервированных
1 Термин шлюз используется вместо термина маршрутизатор в большинстве ранних документов RFC
и в литературе, посвященной протоколам TCP/IP; иногда этот термин используется в этом значении
до сих пор (например, протокол BGP — Border Gateway Protocol, дословно «пограничный шлюзовый
протокол»).
578
Глава 18. Протоколы поддержания качества обслуживания
ресурсов представляет собой информацию, кэшируемую на маршрутизаторе, но
записываемую и периодически обновляемую оконечными системами. Если состо-
яние не обновляется в течение определенного интервала времени, маршрутизатор
удаляет эту информацию. Если для данного потока выбирается новый маршрут
оконечные системы посылают заявки на предоставление ресурсов новым марш-
рутизаторам, находящимся на пути следования данных.
Потоки данных
Три концепции, относящиеся к потокам данных, являются базовыми для работы
протокола RSVP. Это сеанс, спецификация потока и спецификация фильтра.
Сеансом называют поток данных, идентифицируемый по его месту назначе-
ния (то есть адресату, или получателю). Причина использования термина сеанс
(session) вместо термина место назначения (destination) заключается в том, что
данный термин отражает основанную на гибком состоянии природу функциони-
рования протокола RSVP. Когда на маршрутизаторе в определенном направлении
резервируются ресурсы, маршрутизатор рассматривает эти действия как сеанс
и выделяет ресурсы только на время сеанса. В частности, сеанс определяется сле-
дующими характеристиками:
♦ IP-адресом получателя;
♦ идентификатором IP-протокола;
♦ портом назначения.
IP-адрес получателя может быть одиночным или групповым. Идентификатор
протокола указывает на пользователя протокола IP (то есть на протокол TCP или
UDP), а порт назначения представляет собой порт пользователя протокола TCP
или UDP. Если адрес групповой, порт назначения является необязательным, так
как у различных приложений групповые адреса, как правило, различаются.
Запрос на резервирование ресурсов, посылаемый получающей оконечной сис-
темой, называется описателем потока (flow descriptor) и состоит из спецификации
потока (flow specification) и спецификации фильтра (filter specification). Специ-
фикация потока содержит информацию о запрашиваемом уровне качества обслу-
живания и используется для установки параметров планировщика пакетов узла.
Таким образом, маршрутизатор будет передавать пакеты с заданным набором пред-
почтений, основываясь на текущей спецификации потока. Спецификация фильт-
ра определяет множество пакетов, для которых запрашивается резервирование
ресурсов. Таким образом, спецификация фильтра вместе с сеансом определяю'!
множество пакетов (то есть поток), которые должны приниматься с указанным
уровнем качества обслуживания. Любые другие пакеты, адресуемые тому же по-
лучателю, обслуживаются по остаточному принципу.
Содержимое спецификации потока не относится к протоколу RSVP, кото-
рый представляет собой всего лишь транспортное средство для передачи запро-
сов. В общем случае спецификация потока содержит следующие элементы:
класс службы;
♦ спецификацию резервирования;
♦ спецификацию трафика.
18.1. Протокол RSVP
579
Класс службы представляет собой идентификатор типа запрашиваемой служ-
бы. Он включает информацию, используемую маршрутизатором для объединения
запросов. Остальные два параметра представляют собой численные значения. Спе-
цификация резервирования определяет желаемый уровень качества обслужива-
ния, а спецификация трафика описывает поток данных. Содержимое этих пара-
метров является непрозрачным для протокола RSVP.
В принципе, спецификация фильтра позволяет идентифицировать произволь-
ное подмножество пакетов одного сеанса (то есть пакетов, прибывающих адресату'
данного сеанса). Например, спецификация фильтра может указывать только осо-
бые источники или конкретные протоколы источника либо только пакеты, в заго-
ловках которых совпадают определенные поля. В текущей версии протокола RSVP
используется спецификация фильтра, состоящая из следующих элементов:
4- адреса отправителя;
♦ порта UDP или TCP отправителя.
Рисунок 18.1 иллюстрирует взаимоотношения между сеансом, спецификацией
потока и спецификацией фильтра. Каждый прибывающий пакет является частью,
самое большее, одного сеанса и обрабатывается в соответствии с логическим пото-
ком для этого сеанса. Если пакет не принадлежит ни одному' из сеансов, он обслу-
живается по остаточному' принципу.
Планировщик пакетов
Рис. 18.1. Обработка пакетов одного сеанса на одном маршрутизаторе
Работа протокола RSVP
Протокол RSVP, в основном, предназначен для управления групповой рассыл-
кой. Целевая рассылка обрабатывается как специальный случай. В дальнейшем
мы будем рассматривать работу протокола RSVP в условиях резервирования
ресурсов для групповой рассылки. В обсуждении используется конфигурация
объединенной сети, показанная на рис. 18.2, а. Эта конфигурация состоит из
четырех соединенных друг с другом маршрутизаторов (RI, R2, R3 и R4). Каналы
580
Глава 18. Протоколы поддержания качества обслуживания
связи между маршрутизаторами, изображенные в виде линий, могут быть двухто-
чечными соединениями или подсетями. Три хоста (Gl, G2 и G3) являются членами
группы рассылки и могут получать дейтаграммы с соответствующим групповым
адресом получателя. Два хоста (S1 и S2) передают данные по этому групповому
адресу. Жирные черные линии обозначают дерево маршрутов для источника S1
и этой группы получателей, а жирные серые линии указывают дерево маршрутов
для источника S2 и этой группы. Линии со стрелками обозначают передачу паке-
тов от источника S1 (черные) и от источника S2 (серые).
Рис. 18.2. Работа протокола RSVP
Как видно, все четыре маршрутизатора должны знать о том, какие ресурсы за-
резервированы для каждой группы получателей. Таким образом, запросы на пре-
доставление ресурсов должны распространяться вверх по дереву маршрутов к каж-
дому потенциальному хосту.
Фильтрация
На рис. 18.2, б показан случай, при котором хост G3 резервирует ресурсы, указы-
вая в спецификации фильтра оба источника, S1 и S2, тогда как хосты G1 и G2 за-
прашивают передачу только от источника S1. Маршрутизатор R3 продолжает до-
ставлять пакеты с данным групповым адресом от источника S2 хосту G3, но не
переправляет их маршрутизатору R4 для доставки хостам Gin G2. Ресурсы при
этом резервируются следующим образом. Оба хоста, G1 и G2, посылают RSVP-за-
прос со спецификацией фильтра, в которой не значится источник S2. Поскольку
18.1. Протокол RSVP
581
хосты G1 и G2 являются единственными членами группы рассылки, доступными
для маршрутизатора R4, маршрутизатору R4 более не нужно переправлять пакеты
в этом сеансе. Поэтому он может объединить два запроса спецификации фильтра
и отправить их в RSVP-сообщении маршрутизатору R3. Получив это сообщение,
маршрутизатор R3 более не станет в этом сеансе переправлять пакеты маршрути-
затору R4. Однако он все еще должен переправлять такие пакеты хосту G3. Соот-
ветственно, маршрутизатор R3 сохраняет данную заявку на предоставление ресур-
сов, но не посылает ее дальше маршрутизатору R2.
В протоколе RSVP не указывается, как следует обрабатывать отфильтрован-
ные пакеты. Маршрутизатор R3 может переправлять их маршрутизатору R4 по
остаточному принципу или просто отбрасывать их, как это показано на рис. 18.2, б.
Пример фильтрации на более глубоком уровне иллюстрирует рис. 18.2, в. Здесь
для большей ясности рассматриваются только данные, передаваемые источни-
ком S1. Предположим, что по одному и тому же групповому адресу передаются два
типа пакетов, представляющих два подпотока (например, две части видеосигнала).
Эти подпотоки изображены на рисунке в виде черных и серых стрелок. Хосты G1
и G2 послали источнику запросы на резервирование ресурсов без ограничения,
тогда как хост G3 использует спецификацию фильтра, устраняющую один из двух
подпотоков. Этот запрос распространяется от маршрутизатора R3 на маршрути-
затор R2, а от него — на маршрутизатор R1. Затем маршрутизатор R1 блокирует
передачу части потока хосту G3. Это позволяет сберечь ресурсы на линиях от
маршрутизатора R1 к маршрутизатору R2, от R2 к R3 и от R3 до хоста G3, а также
ресурсы па маршрутизаторах R2 и R3 и на хосте G3.
Стили резервирования
Способ, которым агрегируются требования предоставления ресурсов от множества
получателей, входящих в одну и ту же группу, определяется стилями резервиро-
вания. Эти стили, в свою очередь, характеризуются двумя различными парамет-
рами запроса на предоставление ресурсов:
♦ Атрибут резервирования. Получатель может указать резервируемые ресур-
сы, которые будут использоваться совместно несколькими отправителями,
а также ресурсы, которые должны быть выделены определенным отправи-
телям. В первом случае получатель в спецификации фильтра характеризу-
ет весь поток данных, который он собирается получать по данному груп-
повому адресу от всех источников. Во втором случае получатель заявляет
о своей способности одновременно получать указанные потоки данных от
каждого отправителя, указанного в спецификации фильтра.
♦ Выбор отправителя. Получатель может либо предоставить список источ-
ников (явно) или неявно выбрать все источники, не указав спецификации
фильтра.
На основе этих двух параметров в протоколе RSVP определены три стиля ре-
зервирования, как показано в табл. 18.1. Стиль фильтра WF (Wild Card — главная
карта, джокер) определяет единственный запрос на предоставление ресурсов все-
ми отправителями, посылающими данные по этому адресу. Если этот стиль ис-
пользуется всеми получателями, тогда его можно представить себе в виде общего
582
Глава 18. Протоколы поддержания качества обслуживания
канала, пропускная способность (или качество) которого соответствует макси-
мальному значению, призванному удовлетворить запросы всех получателей вниз
от любой точки на дереве распределения. Длина канала не зависит от количества
отправителей. Этот стиль резервирования распространяется вверх ко всем отпра-
вителям. Символически он изображается в виде WF(*{Q}), где звездочка обозна-
чает выбор всех отправителей, a Q — спецификацию потока.
Таблица 18.1. Атрибуты и стили резервирования
Способ выбора отправителя Атрибут резервирования
Индивидуальный Совместный
Явный Стиль FF Стиль SE
Неявный (выбираются все отправители) Стиль WF
Чтобы оценить результат использования стиля WF, рассмотрим конфигурацию
маршрутизатора, взятую из спецификации протокола RSVP и представленную на
рис. 18.3, а. Это маршрутизатор, входящий в дерево распределения, по которому
переправляются пакеты из порта у для получателя R1 и из порта z для получате-
лей R2 и R3. Данные, передаваемые для этой группы, прибывают в порт w от ис-
точника S1 и в порт х от источников S2 и S3. Данные от всех источников пере-
правляются через маршрутизатор всем получателям.
Рисунок 18.3, б иллюстрирует способ, которым данный маршрутизатор обра-
батывает запросы в стиле WF. Для простоты спецификация потока представляет-
ся в виде скалярной величины, кратной некоторой единице измерения ресурса В.
В колонке Прием показаны запросы, прибывающие от получателей. В колонке
Резерв отображается состояние ресурсов в результате резервирования для каждого
выходного порта. В колонке Передача показаны запросы, посланные против тече-
ния предыдущим узлам. Обратите внимание на то, что маршрутизатор должен заре-
зервировать канал с пропускной способностью 4В для порта у и с пропускной спо-
собностью ЗВ для порта г. В последнем случае маршрутизатор объединяет запросы
от маршрутизаторов R2 и R3 для поддержания максимального для этого порта тре-
бования. Однако при передаче запросов вверх против течения маршрутизатор дол-
жен объединить все исходящие запросы и отправить запрос в канал с пропускной
способностью 4В для обоих портов, w и х.
Теперь предположим, что дерево распределения такое, что данный маршрутиза-
тор переправляет пакеты от источника S1 из обоих портов, у и 2, но пакеты от источ-
ников S1 и S2 отправляет только из порта 2, так как топология объединенной сети
предоставляет более короткий путь от источников S1 и S2 к маршрутизатору R1
На рис. 18.3, в показан способ, которым объединяются запросы ресурсов в данном
случае. Единственное изменение состоит в том, что вверх по дереву через порт х
посылается запрос на пропускную способность ЗВ. Это объясняется тем, что паке-
ты, прибывающие через этот порт, должны переправляться дальше только через
порт 2, для которого максимальная спецификация потока равна ЗВ.
Хорошим примером использования стиля WF является аудиотелеконференция.
Как правило, одновременно говорит только один собеседник, поэтому все участ-
ники могут совместно задействовать общий ресурс.
18.1. Протокол RSVP
583
а
Передача I Резерв Прием
I
WF(*{4B}) <- (W) ;| *{4В} |(у)<- WF(*{4B})
WFr{4B})^(x)im(Z)^^™
Рис. 18.3. Примеры стилей резервирования
Стиль FF (Fixed Filter — фиксированный фильтр) означает раздельное ре-
зервирование для каждого отправителя с предоставлением списка отправителей.
584
Глава 18. Протоколы поддержания качества обслуживания
Символически этот стиль обозначается как FF(S1 {QI}, SI{Q.1},...), где Si означает
запрашиваемого отправителя, a Qi — запрос ресурсов для него. Суммарный объем
резервируемых ресурсов для данного сеанса представляет собой сумму величин
Qi для всех запрашиваемых отправителей.
На рис. 18.3, г продемонстрировано применение стиля FF. В колонке Резерв
каждый прямоугольник представляет один зарезервированный канал в исходящей
линии. Все входящие запросы для источника S1 объединяют ся в запрос на 4В, по-
сылаемый через порт w. Описатели потоков для отправителей S2 и S3 упаковыва-
ются (но не объединяются) в запрос, посылаемый через порт х. В этом запросе ис-
пользуется максимальная величина спецификации потока дня каждого источника.
Хороший пример использования стиля FF — распределение видеосигнала. Для
одновременного получения видеосигнала от различных источников требуется от-
дельный канал для каждого потока. Объединение и упаковка запросов на марш-
рутизаторе гарантируют доступность соответствующих ресурсов. Например, на
рис. 18.2, а маршрутизатор R3 должен резервировать ресурсы для двух различных
видеопотоков, направляемых хосту G3, но ему требуется только один канал из по-
тока, идущего к маршрутизатору R4, даже несмотря на то, что этот поток снабжает
двух получателей (G1 и G2). Таким образом, при использовании стиля FF допус-
кается совместное расходование ресурсов несколькими получателями, но недопу-
стимо совместное расходование ресурсов несколькими отправителями.
Стиль SE (Shared-Explicit — совместный явный) указывает, что один ресурс
должен совместно использоваться отправителями, явно перечисленными в спис-
ке. Условно этот стиль обозначается следующим образом: SE(S1, S2, ...{£)}). Рису-
нок 18.3, д иллюстрирует работу этого стиля. При объединении запросов на резер-
вирование ресурсов в стиле SE образуемая в результате спецификация фильтра
представляет собой объединение исходных спецификаций фильтра, а получающая-
ся спецификация потока представляет собой максимальную спецификацию потока.
Как и стиль WF, стиль SE годится для приложений групповой рассылки с не-
сколькими источниками данных, которые, как правило, не выполняют передачу
одновременно.
Механизмы протокола RSVP
В протоколе RSVP используются сообщения двух основных типов: о резервиро-
вании и о маршруте. Сообщения о резервировании формируются членами группы
получателей и распространяются вверх по дереву распределения. По пути эти со-
общения могут упаковываться и объединяться на каждом узле. Эти сообщения
образуют информацию гибкого состояния на маршрутизаторах дерева распределения,
описывая ресурсы, зарезервированные для данного сеанса (для данного группового
адреса). В конце концов, объединенные сообщения о резервировании достигают
передающих хостов, позволяя хостам установить соответствующие параметры
управления трафиком для первого ретрансляционного участка. Поток сообщений
о резервировании показан на рис. 18.2, г. Обратите внимание на то, что сообщения
объединяются таким образом, что по каждой ветви объединенного дерева распре-
деления только одно сообщение отправляется вверх по дереву. Однако для под-
держания гибких состояний эти сообщения должны периодически повторяться.
18.1. Протокол RSVP
585
Сообщение о маршруте используется для передачи маршрутной информации
вверх по дереву. Во всех ныне используемых протоколах групповой маршрутиза-
ции информация о маршруте передается только вниз по дереву распределения.
Однако сообщения о резервировании должны распространяться навстречу пото-
ку через все промежуточные маршрутизаторы ко всем передающим хостам. От-
сутствие сведений о встречной маршрутизации, не предоставляемых протоколом
маршрутизации, компенсируется протоколом RSVP, поставляющим эту инфор-
мацию в сообщении о маршруте. Каждый хост, желающий быть передатчиком для
групповой рассылки, посылает сообщение о маршруте по распределительному
дереву группе получателей. По пути каждый маршрутизатор и каждый хост-полу-
чатель создает состояние маршрута, указывающее обратный ретрансляционный
участок, который следует использовать этому источнику. На рис. 18.2, а маршруты,
по которым следуют эти сообщения, совпадают с маршрутами, по которым следуют
пакеты с данными.
Рисунок 18.4 иллюстрирует работу протокола с точки зрения хоста.
1. Получатель вступает в группу рассылки, посылая соседнему маршрутиза-
тору IGMP-сообщение с запросом о включении в группу.
2. Потенциальный отправитель передает сообщение о маршруте по группово-
му адресу.
3. Получатель принимает сообщение о маршруте, идентифицирующее отпра-
вителя.
4. Теперь, когда у получателя есть информация об обратном пути, он может
начать отправлять сообщения о резервировании, указывая в них специфи-
кации потоков, которые он хотел бы принимать.
5. Сообщение о резервировании распространяется по объединенной сети и дос-
тавляется отправителю.
6. Отправитель начинает передавать пакеты с данными.
7. Получатель начинает принимать пакеты с данными.
Первый и второй шаги могут происходить в любом порядке.
Рис. 18.4. Работа протокола RSVP
586
Глава 18. Протоколы поддержания качества обслуживания
18.2. Многопротокольная коммутация
по меткам
В частях V и VI мы рассмотрели ряд основанных на протоколе IP механизмов
предназначенных для улучшения производительности IP-сетей и для предостав-
ления разным пользователям различных уровней качества обслуживания. Хотя
протоколы маршрутизации, обсуждавшиеся в части V, в первую очередь предназ-
начены для динамического поиска маршрута от отправителя к получателю через
объединенную сеть, они также позволяют повысить производительность двумя
способами:
♦ Поскольку эти протоколы являются распределенными и динамическими,
они могут реагировать на возникновение перегрузки, избегая областей с боль-
шим трафиком путем изменения маршрутов. Подобные действия позволя-
ют сгладить и сбалансировать нагрузку в объединенной сети, повышая сум-
марную производительность.
♦ Маршрутизаторы могут использовать различные метрики, например коли-
чество ретрансляционных участков или величину задержки. Таким образом,
алгоритм маршрутизации готовит информацию, которая позволяет определить,
как обрабатывать пакеты с различными требованиями к обслуживанию.
Описанные в части VI механизмы (IS, DS, RSVP) позволяют усовершенство-
вать объединенные IP-сети, явно поддерживающие обслуживание с разными уров-
нями качества. Однако ни один из до сих пор обсуждавшихся механизмов и про-
токолов не относится непосредственно к повышению пропускной способности и
снижению задержек в объединенной сети. Архитектура MPLS (MultiProtocol Label
Switching — многопротокольная коммутация по меткам) представляет собой мно-
гообещающую попытку ускорить продвижение IP-пакетов и сохранить гибкость,
характерную для IP-сетей, с помощью механизмов управления трафиком и под-
держания качества обслуживания, применяющихся в сетях ATM.
История вопроса
История создания архитектуры MPLS началась с ряда попыток объединения тех-
нологий IP и ATM в середине 90-х гг. Первым продуктом на рынке стала IP-ком-
мутация, разработанная компанией Ipsilon. О выпуске собственных аналогичных
продуктов объявили многие другие компании, среди которых следует отметить
Cisco Systems (тег-коммутация), IBM (IP-коммутация, основанная на агитиро-
ванных маршрутах) и Cascade (IP-навигатор). Целью всех этих продуктов было
повышение пропускной способности и улучшение характеристик задержки
протокола IP. Во всех продуктах применяется один и тот же основной метод: для
нахождения маршрутов между конечными точками используется стандартный
протокол маршрутизации, например OSPF; при поступлении пакетов в сеть им на-
значаются соответствующие маршруты; для перемещения этих пакетов по марш-
рутам применяются ATM-коммутаторы. Когда эти продукты вышли на рынок,
ATM-коммутаторы были значительно быстрее IP-маршрутизаторов, поэтому цель
|3аключалась в том, чтобы повысить производительность, переместив как можно
18.2. Многопротокольная коммутация по меткам
587
большую часть трафика вниз, на уровень ATM, и использовать коммутационное
оборудование ATM.
В ответ на эти частные инициативы группа IETF создала в 1997 г. рабочую груп-
пу MPLS для разработки общего стандартизированного подхода. Рабочая 1-руппа
выпустила свой первый набор предложений в 2001 г.’ Однако тем временем ры-
нок не стоял на месте. В конце 90-х г. появились маршрутизаторы, не уступающие
по скорости коммутаторам ATM, что избавило от необходимости поддерживать
в одной и той же сети одновременно технологии ATM и IP. Тем не менее, архитек-
тура MPLS играет важную роль, снижая объем необходимой обработки каждого
пакета на каждом маршрутизаторе в IP-сети, что еще в большей степени увеличи-
вает производительность маршрутизаторов. Что еще важнее, архитектура MPLS
предоставляет важные новые возможности в четырех популярных областях: поддер-
жании качества обслуживания, конструировании трафика, виртуальных частных
сетей и многопротокольной поддержки. Прежде чем перейти к обсуждению дета-
лей архитектуры MPLS, мы поочередно кратко рассмотрим эти четыре области.
Поддержание качества обслуживания
с ориентацией на соединение
Менеджерам и пользователям сетей по ряду причин требуется все более сложная
система поддержания качества обслуживания. В [206] перечисляются основные
требования:
♦ Гарантирование фиксированной пропускной способности для конкретных
приложений, таких как аудио- и видеоконференции.
♦ Управление характеристиками задержки и флуктуации задержки, а также
гарантирование пропускной способности для передачи голоса.
♦ Предоставление специфических, гарантированных и поддающихся количе-
ственному определению соглашений об уровне обслуживания, называемых
договорами о трафике.
♦ Конфигурирование разных уровней качества обслуживания для разных
пользователей.
Сеть, не требующая соединений, такая как IP-сеть, не может предоставлять дей-
ствительно твердых обязательств относительно качества обслуживания. Архитек-
тура дифференцированных служб работает прямолинейно и только с агрегатами
трафика от нескольких источников. Архитектура интегрированных служб, исполь-
зующая протокол RSVP, напоминает подход с установлением соединения, но не
допускает настройки в плане гибкости и масштабируемости. Для таких служб, как
голос и видео, требующих сетей с высокой предсказуемостью, подходы, характер-
ные для дифференцированных и интегрированных служб, в сильно загруженных
сетях могут оказаться неадекватными. Напротив, ориентированная на соединение
сеть, как мы видели, обладает мощными средствами управления трафиком и предос-
тавления обслуживания с различными уровнями качества. Архитектура MPLS на-
кладывает на объединенную IP-сеть структуру, ориентированную на соединение, и
таким образом формирует основу для подробного и надежного договора о трафике.
RFC 3031, Multiprotocol Label Switching Architecture, январь 2001.
588
Глава 18. Протоколы поддержания качества обслуживания
Конструирование трафика
Архитектура MPLS упрощает предоставление сетевых ресурсов, меняя нагрузку в
соответствии с запросом, а также упрощает предоставление дифференцированных
уровней поддержки, удовлетворяя разнообразные требования пользователей к тра-
фику. Способность динамически выбирать маршруты, планировать ресурсы на
основе известных требований и оптимизировать использование сети называется
конструированием трафика (traffic engineering).
Основной механизм протокола IP обладает примитивными формами автома-
тизированного конструирования трафика. В частности, протоколы маршрути-
зации, например OSPF, позволяют маршрутизаторам в целях балансирования
нагрузки динамически менять маршруты пакетов для данного получателя. Но по-
добный метод динамической маршрутизации реагирует на возникновение пере-
грузки весьма примитивно и не предоставляет обслуживания с разными уровня-
ми качества. Весь трафик между двумя конечными точками следует по одному
и тому же маршруту, который может быть изменен только в случае перегрузки.
С другой стороны, архитектура MPLS обладает информацией не только об инди-
видуальных пакетах, но и о потоках пакетов, у каждого из которых есть опреде-
ленные требования к качеству обслуживания и предсказуемые потребности тра-
фика. В архитектуре MPLS возможен выбор маршрутов на основе этих отдельных
потоков, причем различные потоки, связывающие одну и ту же пару конечных то-
чек, могут следовать по разным маршрутам. Кроме того, при возникновении пере-
грузки проложенные архитектурой MPLS маршруты могут быть разумно измене-
ны. То есть вместо простого изменения маршрутов отдельных пакетов архитектура
MPLS позволяет изменять маршруты потоков, пользуясь данными о требованиях
к графику каждого потока. Эффективное конструирование трафика может суще-
ственно увеличить пропускную способность сети.
Поддержка виртуальных частных сетей
Архитектура MPLS предоставляет эффективный механизм поддержки виртуальных
частных сетей (Virtual Private Network, VPN). При этом трафик данного предпри-
ятия или группы прозрачно проходит через объединенную сеть, причем можно
легко отделять этот трафик от остальных пакетов объединенной сети, предостав-
ляя гарантии производительности и безопасности.
Многопротокольная поддержка
Архитектура MPLS может использоваться на базе различных сетевых технологий.
Однако главной областью применения архитектуры MPLS будут, вероятно, объеди-
ненные IP-сети. Архитектура MPLS представляет собой шаг вперед по сравнению
с архитектурой объединенной IP-сети. Для ее использования требуется замена
существующих IP-маршрутизаторов соответствующей аппаратурой. Маршрутиза-
торы с поддержкой MPLS могуч сосуществовать с обычными 1Р-маршрутизаторами,
что упрощает переход на схему MPLS. Архитектура MPLS также предназначается
для работы в сетях ATM и сетях ретрансляции кадров. В этих сетях коммутаторы
с поддержкой MPLS также могут сосуществовать с обычными коммутаторами. Более
того, архитектура MPLS может использоваться в «чистой» объединенной 1Р-сети,
«чистой» сети ATM, «чистой» сети ретрансляции кадров или в объединенной сети,
включающей две или даже все три технологии. Эта универсальная природа архи-
18.2. Многопротокольная коммутация по меткам
589
W"
тектуры MPLS должна быть привлекательной для пользователей, обладающих
сетями смешанного состава и ищущих способы оптимизации использования ресур-
сов и расширения поддержки различных уровней качества обслуживания.
В оставшейся части данного обсуждения мы сфокусируем наше внимание на
использовании архитектуры MPLS в объединенных IP-сетях и кратко прокоммен-
тируем тему форматирования в сетях ATM и сетях ретрансляции кадров. Далее
перечислены ключевые термины, относящиеся к архитектуре MPLS.
4- Класс эквивалентности продвижения данных (Forwarding Equivalence Class,
FEC). Группа IP-пакетов, продвигаемых в одной и той же манере (напри-
мер, по одному и тому же маршруту, с одним и тем же обслуживанием).
+ Объединение кадров (frame merge). Объединение меток в случае работы с
носителем, передающим данные в виде кадров, так что проблем с чередова-
нием ячеек не возникнет.
4- Метка (label). Короткий физически непрерывный идентификатор фикси-
рованной длины, используемый для идентификации FEC-класса, как пра-
вило, имеющий локальное значение.
4- Объединение меток (label merge). Замена нескольких входных меток конк-
ретного FEC-класса одной выходной меткой.
4- Обмен меток (label swap). Основная операция продвижения, заключающа-
яся в поиске входной метки, чтобы определить выходную метку, инкапсу-
ляцию, порт и другую информацию, относящуюся к обработке данных.
+ Замена меток (label swapping). Парадигма, упрощающая продвижение дан-
ных при помощи меток, идентифицирующих классы пакетов данных, когда
они при продвижении не различаются.
4- Ретрансляционный участок, коммутируемый пометкам (label switched hop).
Ретрансляционный участок между двумя узлами MPLS, продвижение дан-
ных на которых выполняется при помощи меток.
4- Путь, коммутируемый пометкам (label switched path). Путь, проходящий
через один или несколько LSR-маршрутизаторов на одном иерархическом
уровне, по которому следуют пакеты конкретного FEC-класса.
♦ Маршрутизатор, коммутирующий пометкам (Label Switching Router, LSR).
MPLS-узел, способный продвигать «родные» ЬЗ-пакеты.
♦ Стек меток (label stack). Упорядоченный набор меток.
4- Точка объединения (merge point). Узел, на котором выполняется объедине-
ние меток.
4^ MPLS-домен (MPLS domain). Непрерывное множество узлов, осуществля-
ющих MPLS-маршрутизацию и продвижение и находящихся в одном доме-
не маршрутизации или административном домене.
4- Пограничный MPLS-узел (MPLS edge node). MPLS-узел, соединяющий MPLS-
домен с узлом, расположенным вне домена, либо потому, что он не исполь-
зует архитектуру MPLS, либо потому, что он находится в другом домене.
Обратите внимание на то, что если у LSR-маршрутизатора есть соседний
хост, на котором не работает архитектура MPLS, тогда этот LSR-маршрути-
затор является пограничным MPLS-узлом.
590
Глава 18. Протоколы поддержания качества обслуживания
4- Выходной MPLS-узел (MPLS egress node). Пограничный MPLS-узел, управ-
ляющий трафиком, покидающим MPLS-домен.
4- Входной MPLS-узел (MPLS ingress node). Пограничный MPLS-узел, управ-
ляющий трафиком, поступающим в MPLS-домен.
♦ MPLS-метка (MPLS label). Короткий физически непрерывный идентифи-
катор фиксированной длины, используемый для идентификации FEC-клас-
са, как правило, имеющий локальное значение. Метка переносится в заго-
ловке пакета.
4- MPLS-узел (MPLS node). Узел, на котором реализована архитектура MPLS.
MPLS-узел обладает информацией об управляющих протоколах MPLS
поддерживает работу одного из протоколов маршрутизации L3 и способен
продвигать пакеты по меткам. Дополнительно узел MPLS может продвигать
«родные» ЕЗ-пакеты.
Функционирование архитектуры MPLS
Обычная или объединенная MPLS-сеть1 состоит из множества узлов, называемых
LSR-маршрутизаторами. Эти узлы способны коммутировать и маршрутизировать
пакеты с помощью меток, добавленных к каждому пакету. Метки определяют по-
ток пакетов между двумя конечными точками или, в случае групповой рассылки,
между конечной точкой-источником и группой конечных точек-получателей. Для
каждого отдельного потока, называемого классом эквивалентности продвижения
данных, или FEC-классом, определяется маршрут через сеть LSR-маршрутизато-
ров. Таким образом, архитектура MPLS представляет собой ориентированную на
соединение технологию. С каждым FEC-классом ассоциируется характеристика
трафика, определяющая требования к качеству обслуживания этого потока. LSR-
маршрутизаторам не нужно изучать или обрабатывать IP-заголовок. Вместо этого
они просто продвигают каждый пакет на основе значения его метки. Таким обра-
зом, процесс продвижения оказывается проще, чем в случае 1Р-маршрутизатора.
Рисунок 18.5, основанный на рисунке из [187], иллюстрирует работу архитек-
туры MPLS в домене из маршрутизаторов. Вот ключевые элементы функциони-
рования архитектуры MPLS:
1. Перед маршрутизацией и доставкой пакетов данного FEC-класса должен
быть определен маршрут через сеть, называемый LSP-путем, а также уста-
новлены параметры качества обслуживания вдоль этого пути. Параметры
качества обслуживания определяют, во-первых, объем ресурсов, выделяе-
мых пути, и, во-вторых, политику организации очередей и политику от-
брасывания пакетов, устанавливаемую на каждом LSR-маршрутизаторе
для пакетов данного FEC-класса. Для выполнения этих задач требуются два
протокола, реализующие обмен информацией между маршрутизаторами.
♦ Протокол внутренней маршрутизации, такой как OSPF, используется
для обмена сведениями о достижимости и маршрутах.
1 Для 1 ipocTOTW в оставшейся части данного раздела мы будем использовать термин сеть. В с лучае объ-
единенной IP-сети мы будем иметь в виду объединенную сеть, в которой IP-маршрутизаторы играют
роль MPLS-узлов.
18.2. Многопротокольная коммутация по меткам
591
♦ Пакетам должны назначаться метки определенного FEC-класса. Посколь-
ку использование глобальных меток привело бы к дополнительным
расходам на управление и ограничило бы количество доступных меток,
метки обладают только локальным значением, что будет обсуждаться
далее. Сетевой оператор может явно указать маршруты и назначить им
соответствующие значения меток. В качестве альтернативы для опреде-
ления маршрута и установки меток между соседними LSR-маршрутиза-
торами может использоваться либо протокол LDP (Label Distribution
Protocol — протокол распределения меток), либо усовершенствованная
версия уже упоминавшегося протокола RSVP.
2. Пакет входит в MPLS-домен через входной пограничный LSR-маршрути-
затор, на котором он обрабатывается, чтобы определить, какие службы сете-
вого уровня ему требуются и таким образом пакету назначается определен-
ный уровень качества обслуживания. LSR-маршрутизатор назначает этому
пакету определенный FEC-класс и, следовательно, определенный LSP-путь;
добавляет к пакету соответствующую метку и продвигает пакет. Если для
данного FEC-класса еще не существует LSP-пути, пограничный LSR-мар-
шрутизатор должен, взаимодействуя с другими LSR-маршрутизаторами,
выбрать новый LSP-путь.
3. Получая меченый пакет в MPLS-домене, каждый LSR-маршрутизатор:
♦ удаляет входную метку и прикрепляет к пакету соответствующую выход-
ную метку;
+ переправляет этот пакет следующему LSR-маршрутизатору на LSP-пути.
4. Выходной пограничный LSR-маршрутизатор удаляет метку, читает заголо-
вок IP-пакета и переправляет пакет конечному получателю.
Рис. 18.5. Функционирование архитектуры MPLS
592
Глава 18. Протоколы поддержания качества обслуживания
Следует отметить несколько ключевых особенностей функционирования ар-
хитектуры MPLS.
4- MPLS-домен состоит из непрерывного (или связного) множества маршру-
тизаторов, поддерживающих архитектуру MPLS. Трафик может поступать
в домен и покидать его через конечную точку, подключенную непосред-
ственно к сети, как показано в правом верхнем углу рис. 18.5. Трафик может
также поступать от обычного маршрутизатора, соединенного с частью объ-
единенной сети, не использующей архитектуру MPLS, как показано в левом
верхнем углу рис. 18.5.
♦ FEC-класс пакета может определяться по одному или по нескольким пара-
метрам, указанным сетевым администратором. Среди возможных парамет-
ров можно назвать следующие:
♦ IP-адреса отправителя и/или получателя или IP-адреса сетей;
номера портов отправителя и/или получателя;
♦ идентификатор IP-протокола;
♦ код дифференцированной службы;
♦ метка потока 1 Pv6.
4 Продвижение данных выполняется просто путем поиска в заранее опреде-
ленной таблице, устанавливающей соответствие между значениями меток
и адресами следующих ретрансляционных участков. Нет необходимости
изучать или обрабатывать IP-заголовок, а также принимать решения о вы-
боре маршрутов на основе IP-адреса получателя.
4 Определенный тип РНВ (Per-Нор Behavior — поведение на ретрансляци-
онном участке) для данного FEC-класса может быть определен на LSR-марш-
рутизаторе. Тип РНВ для данного FEC-класса указывает очередность обра-
ботки пакета в очереди и политику отбрасывания пакетов.
4 Пакеты, посылаемые между одной парой конечных точек, могут принадле-
жать разным FEC-классам. При этом они по-разному помечаются, обраба-
тываются в соответствии с разными типами РНВ на каждом LSR-маршру-
тизаторе и могут следовать через сеть разными маршрутами.
Рисунок 18.6 более детально иллюстрирует обработку меток и продвижение
пакета. Каждый LSR-маршрутизатор поддерживает таблицу продвижения данных
для каждого LSP-пути, проходящего через данный LSR-маршрутизатор. Когда
прибывает помеченный пакет, LSR-маршрутизатор индексирует таблицу продви-
жения данных, чтобы определить следующий ретрансляционный участок. Как уже
отмечалось, для масштабирования метки имеют только локальную значимость.
Таким образом, LSR-маршрутизатор удаляет из пакета входную метку и, прежде
чем переправить его дальше, присоединяет к нему соответствующую выходную
метку. Входной пограничный LSR-маршрутизатор определяет FEC-класс для
каждого непомеченного входящего пакета, на основе этого класса назначает паке-
ту определенный LSP-путь, прикрепляет соответствующую метку и продвигает
пакет дальше.
18.2. Многопротокольная коммутация по меткам
593
Рис. 18.6. Продвижение пакетов MPLS
Организация стека меток
Стек меток представляет собой одну из особенностей архитектуры MPLS, имеющую
большие возможности. Помеченный пакет может переносить несколько меток, орга-
низованных в виде стека LIFO (Last in First Out — последним прибыл — первым
обслужен). Обработка пакета всегда определяется верхней меткой. На любом LSR-
маршрутизаторе метка может быть добавлена к стеку (операцией помещения в
стек) или метка может быть удалена из стека (операцией извлечения из стека).
Хранение меток в виде стека позволяет агрегировать несколько LSP-путей в единый
LSP-путь на участке маршрута через сеть, создавая туннель. В начале туннеля LSR-
маршрутизатор назначает пакетам из разных LSP-путей одинаковую метку, поме-
щая метку в стек каждого пакета. В конце туннеля другой LSR-маршрутизатор
извлекает верхний элемент из стека меток, обнаруживая внутреннюю метку. Это
похоже на технологию ATM, в которой используется структура одноуровневого
стека (виртуальные каналы внутри виртуальных путей), но архитектура MPLS
поддерживает неограниченную вложенность уровней стека.
594
Глава 18. Протоколы поддержания качества обслуживания
Организация меток в виде стека обеспечивает значительную гибкость. Пред-
приятие может установить сети с поддержкой архитектуры MPLS на различных
участках, и на каждом участке установить несколько LSP-путей. В этом случае
предприятие может использовать организацию меток в виде стека для агрегирова-
ния нескольких потоков собственного трафика перед тем, как передать их органи-
затору доступа. Организатор доступа может агрегировать трафик от нескольких
предприятий, прежде чем передать его более крупному поставщику услуг. Постав-
щики услуг могут объединить несколько LSP-путей в относительно небольшом
числе туннелей между входными точками. Меньшее число туннелей означает мень-
ший размер таблиц, что упрощает поставщику задачу масштабирования ядра сети.
Формат и размещение меток
MPLS-метка представляет собой 32-разрядное поле, состоящее из следующих эле-
ментов (рис. 18.7)1:
4- значение метки — 20-разрядное локальное значение;
4- Ехр (экспериментальные биты) — 3 бита, зарезервированные для экспери-
ментов (например, эти биты могут использоваться для обмена информаци-
ей дифференцированных служб или для управления в соответствии с типом
РНВ);
♦ S — бит дна стека, устанавливаемый в единицу для самой старой записи в
стеке и в ноль для всех остальных записей;
4- время жизни (Time То Live, TTL) — 8 бит, используемых для кодирования
количества ретрансляционных участков или времени жизни.
Биты
3 1 8
' ' Значение метки ; f Д Exp Время жизни
Рис. 18.7. Формат метки MPLS
Обработка поля времени жизни
Ключевым полем в заголовке IP-пакета является поле времени жизни или счет-
чика ретрансляционных участков (см. также рис. 2.2 в главе 2). Обычно в объеди-
ненной IP-сети это поле уменьшается на единицу на каждом маршрутизаторе, и
когда значение счетчика достигает нуля, пакет отбрасывается. Это делается для
того, чтобы избежать зацикливания пакета или слишком долгого пребывания па-
кета в объединенной сети из-за неверной маршрутизации. Поскольку LSR-марш-
рутизатор не исследует IP-заголовка, поле времени жизни включается в метку, что
позволяет сохранить функциональность этого поля. Правила обработки поля вре-
мени жизни в метке следующие:
1. Когда IP-пакет прибывает на входной пограничный LSR-маршрутизатор
MPLS-домена, в стек пакета помещается одна метка. Значение поля време-
ни жизни этой метки устанавливается равным значению поля времени жиз-
1 RFC 3032, MPLS Label Stack Encoding, январь 2001.
18.2. Многопротокольная коммутация по меткам
595
пи IP-заголовка. Если значение поля времени жизни IP-заголовка должно
быть уменьшено на единицу как часть IP-обработки, то подразумевается, что
это уже сделано.
2. Когда MPLS-пакет прибывает на внутренний LSR-маршрутизатор MPLS-
домена, значение поля времени жизни в метке, находящейся на вершине сте-
ка, уменьшается на единицу.
♦ Если получившееся значение времени жизни нулевое, MPLS-пакет даль-
ше не передается. В зависимости от значения метки в стеке пакет либо
просто отбрасывается, либо передается соответствующему «обычному»
сетевому уровню для обработки ошибки (например, для формирования
сообщения об ошибке протокола ICMP).
* Если получившееся значение времени жизни положительное, оно поме-
шается в поле времени жизни в верхней записи стека для исходящего
MPLS-пакета, после чего сам MPLS-пакет переправляется дальше. Ис-
ходящее значение поля времени жизни является функцией только вхо-
дящего значения поля времени жизни и не зависит от того, были ли по-
мещены в стек или извлечены из стека какие-либо метки до того, как
переправить пакет дальше. Значения полей времени жизни в записях, не
находящихся на вершине стека, на ход обработки не влияют.
3. Когда MPLS-пакет прибывает на выходной пограничный LSR-маршрути-
затор MPLS-домена, значение поля времени жизни единственной находя-
щейся в стеке записи уменьшается на единицу, после чего метка извлекает-
ся из стека и стек меток становится пустым.
+ Если получившееся значение равно нулю, IP-пакет дальше не передает-
ся. Пакет либо просто отбрасывается, либо передается соответствующе-
му «обычному» сетевому уровню для обработки ошибки.
♦ Если получившееся значение положительное, оно помещается в поле
времени жизни IP-заголовка, после чего IP-пакет переправляется даль-
ше путем обычной IP-маршрутизации. Обратите внимание на то, что до
того как переправить пакет дальше, должна быть пересчитана заново кон-
трольная сумма IP-заголовка.
Стек меток
Записи стека меток располагаются после заголовков уровня передачи данных, но
до заголовков сетевого уровня. Верхняя метка в стеке находится ближе к заго-
ловку сетевого уровня, а нижняя метка располагается ближе к заголовку уровня
передачи данных. Пакет сетевого уровня следует сразу за записью стека с уста-
новленным в единицу битом S. В кадре протокола передачи данных (рис. 18.8, а),
например протокола PPP (Point-to-Point Protocol — протокол двухточечного
соединения), стек меток располагается между IP-заголовком и заголовком уров-
ня передачи данных. В кадре сети стандарта IEEE 802 (рис. 18.8, б) стек меток рас-
полагается между IP-заголовком и заголовком уровня LLC (Logical Link Control —
управление логическим соединением).
596
Глава 18. Протоколы поддержания качества обслуживания
Заголовок уровня передачи данных (например, РРР) . Стек ‘ : MPLS-меток •’ ;"« V.- 5 IP-заголовок Данные — Концевик уровня передачи данных
Заголовок
МАС
Заголовок
LLC
? ' Стёк
MPLS-меток
IP-заголовок
Данные
Концевик МАС
Поле VPI/VCI
Верхняя MPLS-метка ” .... ;; / Стек MPLS-меток ..... Л -. IP-заголовок Данные
Заголовок АТМ-ячейки
Поле DLCI
Верхняя МР LS-метка Стек ' ' : MPLS-меток IP-заголовок Данные Концевик FR
Заголовок FR
г
Рис. 18.8. Положение метки MPLS
Если архитектура MPLS используется поверх ориентированной на соедине-
ние сетевой службы, может применяться другой подход, который иллюстриру-
ют рис. 18.8, в и г. В ячейках ATM верхняя метка помещается в поле VPI/VCI
(см. рис. 5.4) в заголовке ячейки ATM (рис. 18.8, в). Вся верхняя метка остается
на вершине стека меток, вставляемого между заголовком ячейки и IP-заголовком.
Помещение значения метки в заголовок АТМ-ячейки упрощает работу АТМ-ком-
мутатора, которому по-прежнему достаточно просмотреть только заголовок ячей-
ки. Подобным же образом значение самой верхней метки может быть помещено в
поле DLCI (см. рис. 4.9) или в заголовке кадра ретрансляции кадров (рис. 18.8, г).
Обратите внимание на то, что в обоих случаях поле времени жизни остается неви-
димым для коммутатора и поэтому не уменьшается на единицу. Детали обработки
данной ситуации можно узнать в спецификации MPLS.
FEC-классы, LSP-пути и метки
Для понимания механизмов функционирования архитектуры MPLS необходимо
понять взаимосвязь между FEC-классами, LSP-путями и метками. Документация,
/
18.2. Многопротокольная коммутация по меткам
597
описывающая все детали этих взаимоотношений, довольно объемна. В оставшей-
ся части этого раздела мы приведем краткое описание.
Сущность функциональности архитектуры MPLS заключается в том, что тра-
фик группируется в FEC-классы. Трафик одного FEC-класса пересекает MPLS-
домен по LSP-пути. Отдельные пакеты FEC-класса однозначно идентифициру-
ются как часть данного FEC-класса при помощи метки, имеющей локальное
значение. На каждом LSR-маршрутизаторе каждый помеченный пакет продвига-
ется на основе значения метки пакета, причем LSR-маршрутизатор заменяет вход-
ную метку выходной меткой.
Общая схема, описанная в предыдущем абзаце, накладывает ряд требований:
♦ Каждому потоку трафика должен быть назначен определенный FEC-класс.
4- Для определения топологии и текущего состояния домена требуется прото-
кол маршрутизации, позволяющий каждому FEC-классу назначать конк-
ретный LSP-путь. Протокол маршрутизации должен быть способен соби-
рать и использовать информацию для поддержания требований к качеству
обслуживания данного FEC-класса.
♦ Отдельные LSR-маршрутизаторы должны знать о LSP-пути данного FEC-
класса, должны назначать LSP-путь входящей метке, а также должны обме-
ниваться этой меткой со всеми остальными LSR-маршрутизаторами, кото-
рые могут послать им пакеты данного FEC-класса.
Первое требование не относится к спецификации MPLS. Назначение должно
выполняться либо путем ручной настройки, либо с помощью некоего сигнального
протокола, либо на основе анализа пакетов, поступающих на входные LSR-марш-
рутизаторы. Прежде чем рассмотреть два оставшихся требования, изучим тополо-
гию LSP-путей. Мы можем классифицировать LSP-пути следующим образом:
4- Уникальные входной и выходной LSR-маршрутизаторы. В этом случае через
MPLS-домен проходит один маршрут.
+ Уникальный выходной LSR-маршрутизатор, несколько входных LSR-марш-
рутизаторов. Эта ситуация возникает, если назначенный одному FEC-клас-
су трафик может поступать от разных источников через разные входные
LSR-маршрутизаторы. Примером такой ситуации является корпоративная
интранет-сеть, расположенная в одном регионе, но с доступом к MPLS-до-
мену через несколько входных LSR-маршрутизаторов. В такой ситуации
через MPLS-домен проходит несколько маршрутов, возможно, с общими
конечными ретрансляционными участками.
♦ Несколько выходных LSR-маршрутизаторов для трафика целевой рассылки.
В RFC 3031 утверждается, что чаще всего пакету присваивается FEC-класс
на основе (частично или целиком) адреса получателя сетевого уровня. В про-
тивном случае, возможно, для FEC-класса потребуются маршруты к несколь-
ким различным выходным LSR-маршрутизаторам. Однако, скорее всего,
существует несколько сетей, в которые трафик может быть доставлен через
один выходной LSR-маршрутизатор.
♦ Групповая рассыпка. В RFC 3031 групповая рассылка упоминается как пред-
мет дальнейших исследований.
598 Глава 18. Протоколы поддержания качества обслуживания
Выбор маршрута
Выбор маршрута означает выбор LSP-пути для конкретного FEC-класса. Архитек-
турой MPLS поддерживаются два варианта: маршрутизация на уровне ретрансля-
ционных участков и явная маршрутизация.
При маршрутизации на уровне ретрансляционных участков каждый LSR-мар-
шрутизатор независимо выбирает следующий ретрансляционный участок для
каждого FEC-класса. В RFC предполагается, что в данном варианте применяется
обычный протокол маршрутизации, например OSPF. Такой вариант маршрутиза-
ции опирается на некоторые преимущества архитектуры MPLS, включая быструю
коммутацию при помощи меток, возможность организации меток в виде стека и
дифференцированную обработку пакетов различных FEC-классов, следующих по
одному и тому же маршруту. Однако из-за ограниченности метрик производитель-
ности в типичных протоколах маршрутизации маршрутизация на уровне ретранс-
ляционных участков не готова поддерживать конструирование трафика, какую-
либо политику качества обслуживания, безопасность и пр.
В случае явной маршрутизации один LSR-маршрутизатор, как правило, вход-
ной или выходной, определяет для данного FEC-класса несколько или все LSR-
маршрутизаторы на LSP-пути. При жесткой явной маршрутизации один LSR-мар-
шрутизатор определяет все LSR-маршрутизаторы на LSP-пути. При гибкой явной
маршрутизации задаются лишь некоторые LSR-маршрутизаторы. Явная маршру-
тизация позволяет использовать все преимущества архитектуры MPLS, включая
возможность конструирования трафика и проведения какой-либо политики каче-
ства обслуживания.
Явные маршруты могут выбираться во время конфигурирования, то есть уста-
навливаться заранее, либо динамически. Динамическая явная маршрутизация
обеспечивает оптимальные возможности для конструирования трафика. Для
динамической явной маршрутизации LSR-маршрутизатору, устанавливающему
LSP-пути, требуется информация о топологии MPLS-домена, а также о качестве
обслуживания в MPLS-домене. В спецификации конструирования MPLS-трафи-
ка’ предлагается разбиение относящейся к качеству обслуживания информации
на две категории:
4- Множество атрибутов, ассоциированных с одним FEC-классом или набо-
ром близких FEC-классов, описывающих характеристики их поведения.
♦ Множество атрибутов, ассоциированных с ресурсами (узлами, линиями),
накладывающими ограничения на прокладываемые через них LSP-пути.
Алгоритм маршрутизации, учитывающий требования трафика различных по-
токов, а также принимающий во внимание доступные ресурсы на ретрансляцион-
ных участках и узлах, называется алгоритмом маршрутизации с учетом ограниче-
ний (constraint-based routing algorithm). По существу, сеть, использующая такой
алгоритм маршрутизации, в любой момент времени обладает информацией о те-
кущем коэффициенте использования сети, имеющихся в наличии ресурсах и пре-
доставляемых услугах. В традиционных алгоритмах выбора маршрута, таких как
OSPF и BGP, информация о стоимости ресурсов в достаточной степени не исполь-
1 RFC 2702, MPLS Traffic Engineering, сентябрь 1999.
18.2. Многопротокольная коммутация по меткам
599
зуется, что не позволяет считать их алгоритмами, в которых учитываются ограни-
чения. Кроме того, при расчете стоимости любого заданного маршрута может учи-
тываться только какой-либо один параметр стоимости (например, количество ре-
трансляционных участков, задержка). Для архитектуры MPLS необходимо либо
расширить функциональность существующего протокола маршрутизации, либо
разработать новый протокол. Так, например, была определена1 усовершенствован-
ная версия протокола OSPF, предоставляющая, по меньшей мере, частичную под-
держку архитектуры MPLS. Среди примеров метрик, применяемых в маршрути-
зации с учетом ограничений, можно назвать следующие:
4 максимальная скорость передачи данных в линии;
♦ текущее состояние ресурсов;
♦ процент потерянных пакетов;
4 задержка распространения сигнала в линии.
Распределение меток
Выбор маршрута заключается в определении LSP-пути для FEC-класса. Назначе-
ние реального LSP-пути выполняется следующим образом:
1. Назначить LSP-пути метку для распознавания прибывающих пакетов, при-
надлежащих соответствующему FEC-классу.
2. Информировать все потенциальные узлы выше по течению (узлы, посыла-
ющие данному LSR-маршрутизатору пакеты этого FEC-класса) о метке, на-
значенной LSR-маршрутизатором FEC-классу, так чтобы эти узлы могли
правильно метить пакеты, посылаемые данному LSR-маршрутизатору.
3. Узнать следующий ретрансляционный участок на данном LSP-пути и мет-
ку, назначенную FEC-классу узлом ниже по течению (LSR-маршрутизато-
ром следующего ретрансляционного участка). Это позволит данному LSR-
маршрутизатору преобразовать входную метку в выходную.
Первый шаг представляет собой локальную функцию. Шаги 2 и 3 должны вы-
полняться либо во время ручной настройки, либо при помощи некоего протокола
распределения меток. Таким образом, сущность протокола распределения меток
заключается в том, что он позволяет одному LSR-маршрутизатору информировать
остальные LSR-маршрутизаторы о назначенных им соответствиях между метка-
ми и FEC-классами. Кроме того, протокол распределения меток позволяет двум
LSR-маршрутизаторам узнать возможности друг друга, относящиеся к архитекту-
ре MPLS. Архитектура MPLS не предполагает применения единого протокола рас-
пределения меток, а позволяет использовать несколько таких протоколов. В част-
ности, в RFC 3031 для этой цели описываются новый протокол распределения
меток и усовершенствованные существующие протоколы, такие как RSVP и BGP.
Взаимосвязь между распределением меток и выбором маршрутов довольно за-
путана. Лучше всего рассмотреть ее в контексте двух типов маршрутизации.
При выборе маршрутов на уровне ретрансляционных участков, как мы видели,
не уделяется особого внимания вопросам конструирования трафика или маршру-
RFC 2676, QoS Routing Mechanisms mid OSPFExtensions, август 1999.
600
Глава 18. Протоколы поддержания качества обслуживания
тизации на основе политики. В этом случае для определения следующего ретран-
сляционного участка на каждом LSR-маршрутизаторе применяется обычный про-
токол маршрутизации, например OSPF. Относительно простой протокол распре-
деления меток может работать при помощи протокола маршрутизации.
При явном выборе маршрутов должен быть реализован более сложный алгоритм
маршрутизации без единой метрики прокладки маршрута. В этом случае прото-
кол распределения меток может использовать специальный протокол маршрути-
зации, например усовершенствованный протокол OSPF, или включить алгоритм
выбора маршрута в более сложный протокол распределения меток.
18.3. Протокол RTP
Наиболее популярным протоколом транспортного уровня является протокол TCP
(Transmission Control Protocol — протокол управления передачей). Хотя протокол
TCP доказал свое значение в плане поддержания широкого диапазона распреде-
ленных приложений, он не годится для обслуживания распределенных приложе-
ний реального времени. Под распределенным приложением реального времени мы
подразумеваем приложение, в котором источник генерирует поток данных с по-
стоянной скоростью, а один или несколько получателей должны доставлять дан-
ные приложению с той же самой постоянной скоростью. Примеры таких прило-
жений включают аудио- и видеоконференции, передачу видеоданных в реальном
времени (не для хранения, а для немедленного воспроизведения), совместно ис-
пользуемую рабочую среду, удаленную медицинскую диагностику, телефонию,
управляющие и контролирующие системы, распределенные интерактивные симу-
ляторы, игры и мониторинг реального времени. Ряд особенностей протокола TCP
свидетельствует о его неприменимости в качестве транспортного протокола для
данных приложений:
4 - Протокол TCP представляет собой двухточечный протокол, устанавливаю-
щий соединение между двумя конечными точками. Поэтому он не годится
для групповой рассылки.
♦ Протокол TCP включает механизмы повторной передачи потерянных
сегментов, которые затем прибывают с нарушением порядка следования.
Такие сегменты непригодны для большинства приложений реального вре-
мени.
♦ Протокол TCP не содержит удобного механизма, позволяющего синхрони-
зировать временную информацию с сегментами, что является еще одним
требованием приложений реального времени.
Другой широко применяемый транспортный протокол, UDP (User Datagram
Protocol — пользовательский протокол дейтаграмм), не обладает первыми двумя
перечисленными характеристиками протокола TCP, но, как и протокол TCP,
не предоставляет синхронизирующей информации. Сам по себе протокол UDP
не предоставляет универсальных инструментов, полезных для приложений реаль-
ного времени.
18.3. Протокол RTP
601
Хотя каждое приложение реального времени может содержать собственные
механизмы поддержки транспорта реального времени, существует ряд общих ха-
рактеристик, служащих основанием для определения общего протокола, которым
стал протокол RTP (Real-time Transport Protocol — транспортный протокол реаль-
ного времени), определенный в RFC 1889*. Протокол RTP лучше всего подходит
для гибкого взаимодействия реального времени. Ему не достает механизмов, не-
обходимых для поддержки жесткого трафика реального времени.
В этом разделе предоставляется обзор протокола RTP. Мы начнем с обсужде-
ния требований транспорта реального времени. Затем мы изучим философский
аспект RTP. Оставшаяся часть данного раздела посвящена двум протоколам,
составляющим протокол RTP: протоколу передачи данных, называемому просто
RTP, й протоколу RTCP (RTP Control Protocol — управляющий протокол RTP).
Архитектура протокола RTP
В протоколе RTP наблюдается тесная связь между функциональностью протоко-
ла RTP и функциональностью прикладного уровня. В самом деле, протокол RTP
лучше всего рассматривать как архитектуру, которой приложения могут пользовать-
ся напрямую для реализации единого протокола. Без информации, специфичной
для конкретного приложения, протокол RTP оказывается неполным. С другой сто-
роны, протокол RTP формирует структуру и определяет общие функции, так что
отдельные приложения реального времени освобождаются от части их задач.
Протокол RTP следует принципам архитектуры протоколов, отмеченным в [51 ].
Два ключевых понятия, представленных в этой статье, — это формирование кад-
ров на прикладном уровне и интегрированная многоуровневая обработка.
Формирование кадров на прикладном уровне
В традиционном транспортном протоколе, таком как TCP, ответственность за вос-
становление потерянных при передаче данных выполняется на транспортном уров-
не прозрачно для прикладного уровня. В [51] перечисляются два сценария, в кото-
рых восстановление потерянных данных лучше переложить на плечи приложения:
♦ Приложение в определенных пределах способно выдержать несовершенство
доставки и продолжать работу. Это, например, аудио- и видеоприложения
реального времени. Для таких приложений, возможно, необходимо информи-
ровать источник о качестве доставки, а не требовать повторной передачи дан-
ных. Если потеряно слишком много данных, источник, возможно, предпочтет
перейти на режим передачи с пониженным качеством, предъявляющим более
низкие требования к сети, тем самым увеличивая вероятность доставки.
♦ Возможно, будет лучше, если повторной передачей данных будет занимать-
ся не транспортный, а прикладной уровень. Это может быть полезно в двух
случаях:
♦ передающее приложение может пересчитывать, а не хранить потерянные
данные;
1 RFC 1889, RTP: A Transport Protocol for Real-Time Applications, январь 1996.
602
Глава 18. Протоколы поддержания качества обслуживания
+ вместо того чтобы просто передавать еще раз те же потерянные данные
передающее приложение может послать другие данные, пересмотренные
в связи с изменившейся ситуацией, или отправить данные, позволяющие
скорректировать последствия потери оригинальных данных.
Чтобы позволить приложению управлять функцией повторной передачи, в [51]
предлагается, чтобы нижние уровни, например уровень представления или транс-
портный уровень, работали с данными в тех же единицах, в которых с ними рабо-
тает приложение. Приложение должно разбивать поток данных на модули данных
прикладного уровня (Application-level Data Unit, ADU), а более низкие уровни
должны сохранять границы между ADU-модулями при обработке данных. При-
кладной уровень является тем уровнем, на котором имеет смысл исправление оши-
бок отдельных кадров. Если при передаче потеряна часть ADU-модуля, оставшая-
ся часть модуля, как правило, оказывается бесполезной для приложения. В таком
случае прикладной уровень отбрасывает все прибывающие фрагменты и прн не-
обходимости организует повторную передачу всего ADU-модуля.
Интегрированная многоуровневая обработка
В типичной многоуровневой архитектуре протоколов, такой как TCP/IP или OSI,
каждый уровень архитектуры содержит подмножество функций, необходимых для
обмена данными, кроме того, каждый уровень должен быть логически структури-
рованным в виде отдельных модулей оконечных систем. Таким образом, при пе-
редаче блок данных перемещается вниз по уровням и последовательно ими об-
рабатывается. Такая структура не позволяет программисту выполнять функции
параллельно или в порядке, отличном от порядка расположения уровней, что мог-
ло бы повысить производительность. Лежащая в основе интегрированной много-
уровневой обработки идея, предложенная в [51], заключается в том, что соседние
уровни могут быть тесно связаны и программисту должна предоставляться воз-
можность совместного использования функций этих уровней.
Идея, заключающаяся в том, что жесткое разбиение протокола на уровни мо-
жет привести к низкой эффективности, высказывалась многими исследовате-
лями. Например, в [64] описываются результаты изучения проблемы неэффек-
тивности удаленного вызова процедур (Remote Procedure Call, RPC) поверх
протокола TCP и предлагается более тесное взаимодействие двух уровней. Иссле-
дователи доказывают, что метод интегрированной многоуровневой обработки для
эффективной передачи данных предпочтительнее.
Рисунок 18.9 иллюстрирует способ, которым протокол RTP реализует принцип
интегрированной многоуровневой обработки. Протокол RTP предназначен для
того, чтобы работать поверх не требующего соединения транспортного протокола,
например UDP. Протокол UDP обеспечивает базовую функциональность адреса-
ции к портам транспортного уровня. Протокол RTP содержит прочие функции
транспортного уровня, такие как установление очередности обработки. Однако
протокол RTP сам по себе не полон. Чтобы дополнить его функциональностью
прикладного уровня, может использоваться модификация и/или дополнение
RTP-заголовков. На рисунке показано, что для передачи видеоданных совместно
с протоколом RTP могут применяться несколько различных стандартов кодиро-
вания видеоданных.
18.3. Протокол RTP
603
Рис. 18.9. Архитектура протокола RTP [по 221 ]
Протокол передачи данных RTP
Сначала мы рассмотрим базовые понятия протокола передачи данных RTP, а за-
тем изучим формат заголовка этого протокола. На протяжении данного подразде-
ла термин RTP будет обозначать протокол передачи данных RTP, а в следующем
подразделе мы рассмотрим управляющий протокол RTP (то есть RTCP).
Концепции протокола RTP
Протокол RTP поддерживает передачу данных реального времени между несколь-
кими участниками в течение сеанса. Сеансом называется логическая связь между
двумя или более RTP-сущностями, устанавливаемая на время передачи данных.
Характеристики сеанса перечислены далее:
♦ Номер порта RTP. Для передачи данных с помощью протокола RTP всеми
участниками используется адрес порта получателя. Если нижним уровнем
является протокол UDP, этот номер порта появляется в поле «Порт прием-
ника» заголовка UDP (см. рис. 2.1 в главе 2).
Номер порта RTCP. Для передачи данных с помощью протокола RTP всеми
участниками используется адрес порта получателя.
♦ IP-адреса участников. Это может быть либо групповой IP-адрес, в этом слу-
чае всех участников определяет группа рассылки, либо множество индиви-
дуальных IP-адресов.
Протоколы RTP и RTCP в процессе установки сеанса не участвуют.
Хотя протокол RTP может использоваться для целевой передачи реального
времени, основное его достоинство заключается в поддержании групповой рассыл-
ки. Для этой цели в каждый модуль данных протокола RTP включается иденти-
фикатор источника, идентифицирующий члена группы, отправившего эти данные.
В модуль данных также включается временная метка, позволяющая получателю
правильно воссоздать последовательность кадров во времени путем буферизации
данных. Протокол RTP также идентифицирует формат полезной нагрузки пере-
даваемых данных.
604
Глава 18. Протоколы поддержания качества обслуживания
Протокол RTP позволяет использовать RTP-ретрансляторы двух типов: транс-
ляторы и смесители. Сначала мы должны дать определение понятию ретрансля-
тора. Ретранслятор, функционирующий на определенном протокольном уровне
представляет собой промежуточную систему, действующую при передаче данных
одновременно и как получатель, и как источник. Например, предположим, что
система Л желает оправить данные системе В, но не может выполнить это напря-
мую. Причины могут быть самыми разными: например, система В может находиться
за брандмауэром или не понимать формат данных, в котором передает система А
В таком случае система А может отправить данные промежуточному ретрансля-
тору R. Ретранслятор R принимает модуль данных, производит все необходимые
изменения, а затем передает данные системе В.
Смеситель (mixer) представляет собой RTP-ретранслятор, получающий пото-
ки RTP-пакетов от одного или нескольких источников, объединяющий эти пото-
ки и переправляющий новый пакет одному или нескольким получателям. Смеси-
тель может изменять формат данных или просто выполнять функцию смешения.
Поскольку входные потоки, как правило, не синхронизированы, смеситель предо-
ставляет синхронизирующую информацию в объединенном потоке пакетов, а так-
же снабжает эти пакеты собственным идентификатором, указывая себя в качестве
источника синхронизации.
Пример использования смесителя — объединение нескольких двухпозицион-
ных источников данных, например аудиоданных. Предположим, что несколько
систем являются участниками одного аудиосеанса и каждый участник генерирует
свой RTP-поток. Большую часть времени только один источник активен, хотя вре-
мя от времени одновременно могут «говорить» несколько источников. К сеансу
может пожелать присоединиться новая система, но пропускной способности ее
линии может оказаться недостаточно для передачи всех RTP-потоков. Для реше-
ния проблемы смеситель мог бы получать все RTP-потоки, объединять их в еди-
ный поток и ретранслировать этот поток новому участнику сеанса. Если одновре-
менно активны несколько входящих потоков, смеситель будет просто суммировать
значения их оцифрованных амплитуд. Заголовок RTP, сформированный смеси-
телем, будет содержать идентификаторы источников, внесших свой вклад в обра-
зование данных каждого пакета.
Транслятор (translator) представляет собой более простое устройство, форми-
рующее один или несколько исходящих RTP-пакетов для каждого входящего
RTP-пакета. Транслятор может изменить формат данных в пакете или использо-
вать другой набор низкоуровневых протоколов для передачи данных из одного
домена в другой. Далее приводятся примеры использования транслятора:
♦ Потенциальный получатель может быть неспособен обрабатывать высоко-
скоростной видеосигнал, используемый остальными участниками. Трансля-
тор преобразует видеоданные в формат более низкого качества с понижен-
ной скоростью передачи данных.
♦ Брандмауэр прикладного уровня может не допускать продвижения IP-па-
кетов. В этом случае применяются два транслятора, по одному с каждой сто-
роны брандмауэра. Внешний транслятор туннелирует все полученные им
пакеты групповой рассылки внутреннему транслятору по защищенному
18.3. Протокол RTP
605
соединению. Затем внутренний транслятор посылает RTP-пакеты группе
рассылки, защищенной брандмауэром.
4 Транслятор может дублировать входящий RTP-пакет групповой рассылки
и посылать его нескольким получателям путем целевой рассылки.
Фиксированный RTP-заголовок
Каждый RTP-пакет включает фиксированный заголовок и может также включать
дополнительные поля заголовка, характерные для отдельных приложений. Фор-
мат фиксированного заголовка показан на рис. 18.10 с использованием следующих
обозначений:
4 V — версия;
4 Р — заполнитель;
4 X — расширение;
4 СС — счетчик CSRC;
4 М — маркер.
Биты О
31
Тип полезной’
| -нагрузки, |
"k%‘ ............
«Временная метка е Z
Порядковый номе^'^ К 1
,,...;...4’.......................
Идентификатор источника Синхронизации
Идентификатор содействующего источника
Идентификатор содействующего источника
Рис. 18.10. Заголовок RTP
Первые двенадцать байтов (затененная часть) всегда присутствуют в заголов-
ке, а после фиксированного заголовка может располагаться одно или несколько
полей идентификаторов CSRC (см. далее):
4 Версия (2 бита). Текущий номер версии равен 2.
4 Заполнитель (1 бит). Указывает на наличие байтов заполнения в конце поля
полезной нагрузки. Если этот бит установлен, то последний байт полезной
нагрузки содержит количество байтов заполнения. Заполнение использует-
ся в приложениях, требующих, чтобы полезная нагрузка была кратна опре-
деленной величине, например 32 бит.
4 Расширение (1 бит). Если этот бит установлен, то за фиксированным заго-
ловком следует ровно один заголовок расширения, используемый для экс-
периментальных расширений протокола RTP.
4 Счетчик CSRC (4 бита). Количество идентификаторов CSRC (см. ниже),
следующих за фиксированным заголовком.
606
Глава 18. Протоколы поддержания качества обслуживания
4 Маркер (1 бит). Интерпретация бита маркера зависит от типа полезной на
грузки. Как правило, он используется для индикации границы потока дац
пых. В видеоданных этот бит обозначает конец кадра. В аудиоданных он
идентифицирует начало чьей-либо речи.
4 Тип полезной нагрузки (7 бит). Идентифицирует формат полезной нагрузки
RTP, следующей за заголовком.
4 Порядковый номер (16 бит). Каждый источник начинает передачу со случай-
ного значения порядкового номера, увеличивающегося на единицу в каждом
отправляемом информационном RTP-пакете. Это позволяет обнаруживать
ошибки и упорядочивать пакеты в пределах последовательности с одинако-
вой временной меткой. Несколько последовательных пакетов могут иметь
одинаковую временную метку, если они логически относятся к одному
моменту времени, например несколько пакетов, принадлежащих одному
и тому же видеокадру.
4 Временная метка (32 бита). Соответствует моменту генерирования первого
байта данных полезной нагрузки пакета. Используемые единицы времени
этого поля зависят от типа полезной нагрузки. Значение должно формиро-
ваться по показаниям локального таймера источника.
4 Идентификатор источника синхронизации (Synchronization SouRCe, SSRC).
Случайно генерируемая величина, уникально идентифицирующая источ-
ник на время сеанса.
4 Идентификатор содействующего источника (Contributing SouRCe, CSRC).
Идентифицирует источник, вносящий свой вклад в полезную нагрузку. Эти
идентификаторы поставляются смесителем.
Поле типа полезной нагрузки идентифицирует тип полезной нагрузки и формат
данных, включая данные о сжатии и шифровании. В установившемся состоянии
источник должен использовать только один тип полезной нагрузки в течение сеанса,
но может изменить его в ответ на изменение условий, обнаруженное протоколом
RTCP. В табл. 18.2 приведены типы полезной нагрузки, определенные в RFC 18901.
Таблица 18.2. Типы полезной нагрузки для стандартов кодирования
видео- и аудиоданных (RFC 1890)
Код Тип полезной нагрузки
0 1 2 3 4 5 6 7 8 PCMU-аудио 1016-аудио G721 -аудио GSM-аудио Неизвестные аудиоданные ОУ14-аудио (8 кГц) DV 14-аудио (16 кГц) LPC-аудио РСМА-аудио
1 RFC 1890, RTP Profile for Audio and Video Conferences with Minimal Control, январь 1996.
18.3. Протокол RTP
607
Код Тип полезной нагрузки
9 10 11 12-13 14 15 16-23 24 25 26 27 28 29-30 31 32 33 34-71 72-76 77-95 96-128 С722-аудио L16-аудио (стерео) 1_16-аудио (моно) Неизвестные аудиоданные МРА-аудио С728-аудио Неизвестные аудиоданные Неизвестные видеоданные CelB-видео JPEG-вцдео Неизвестные данные nv-видео Неизвестные видеоданные Н261-видео MPV-видео МР2Т-вцдео Неизвестные данные Зарезервировано Неизвестные видеоданные Динамическая полезная нагрузка
Управляющий протокол RTP
Протокол передачи данных RTP используется только для передачи пользователь-
ских данных между всеми участниками сеанса, как правило, путем групповой рас-
сылки. Отдельный управляющий протокол RTP (RTP Control Protocol, RTCP)
также работает в режиме групповой рассылки, обеспечивая обратной связью ис-
точники RTP-данных, а также всех участников сеанса. Протокол RTCP пользует-
ся теми же самыми транспортными службами, что и протокол RTP (обычно это
службы, предоставляемые протоколом UDP), и выделенным номером порта. Каж-
дый участник периодически посылает всем остальным участникам сеанса RTCP-
пакет. В RFC 1889 отмечаются четыре функции, выполняемые протоколом RTCP:
4- Качество обслуживания и борьба с перегрузкой. Протокол RTCP предоставля-
ет обратную связь, касающуюся качества распределения данных. Поскольку
RTCP-пакеты являются групповыми, все участники сеанса получают возмож-
ность узнать о состоянии получения и передачи данных остальных членов
сеанса. Сведения, передаваемые отправителем, позволяют получателям оце-
нивать скорость передачи данных и качество передачи. Сообщения, посы-
лаемые получателем, извещают о проблемах, с которыми сталкивается по-
лучатель, включая недостающие пакеты и слишком большую флуктуацию
задержки. Например, аудио- или видеоприложение может принять решение
о снижении скорости передачи данных по низкоскоростным линиям, если
качество трафика, передаваемого по этим линиям, недостаточно высоко для
поддержания текущей скорости. Обратная связь от получателей также
важна для диагностики ошибок доставки. Отслеживая сообщения от всех
608
Глава 18. Протоколы поддержания качества обслуживания
участвующих в сеансе получателей, администратор сети может определить
касается ли данная проблема отдельного пользователя или она получила
более широкое распространение.
4- Идентификация. RTCP-пакеты содержат устойчивое текстовое описание
RTCP-источника. Оно предоставляет больше информации об источнике
пакетов данных, чем случайный идентификатор SSRC, а также позволяет
пользователю связывать несколько потоков от различных сеансов, напри-
мер отдельных сеансов для аудио и видео.
♦ Оценка насыщенности сеанса и масштабирование. Для выполнения первых
двух функций все участники периодически посылают RTCP-пакеты. Скорость
передачи таких пакетов должна снижаться при увеличении количества
участников. В сеансе с небольшим количеством участников RTCP-пакеты
посылаются с максимальной скоростью, по одному пакету через каждые
5 секунд. В RFC 1889 также определен относительно сложный алгоритм, с по-
мощью которого каждый участник ограничивает свою RTCP-скорость в за-
висимости от общего количества участников сеанса. Назначение данного
алгоритма заключается в том, чтобы ограничить RTCP-трафик пятью про-
центами от общего трафика сеанса.
4- Управление сеансом. Протокол RTCP дополнительно может предоставлять
минимальную информацию об управлении сеансом, например идентификато-
ры участников, которые должны отображаться пользовательским интерфейсом.
Передача по протоколу RTCP состоит из нескольких отдельных RTCP-паке-
тов, объединенных в одну UDP-дейтаграмму (или другой модуль данных более
низкого уровня). В RFC 1889 определяются следующие типы пакетов:
4- сообщение отправителя (Sender Report, SR);
4- сообщение получателя (Receiver Report, RR);
4- описание источника (Source DEScription, SDES);
4- завершение сеанса (goodBYE, BYE);
4- специфический пакет приложения.
Рисунок 18.11 описывает форматы этих типов пакетов. Пакет каждого типа на-
чинается с 32-разрядного слова, поля которого перечислены далее:
4 Версия (2 бита). Текущая версия имеет номер 2. На рисунке это поле обо-
значено символом V.
4- Заполнитель (1 бит). Указывает на наличие байтов заполнения в конце поля
полезной нагрузки. Если этот бит установлен, то последний байт поля по-
лезной нагрузки содержит количество байтов заполнения. На рисунке это
поле обозначено символом Р.
4- Счетчик (5 бит). Количество блоков сообщения, содержащихся в SR- или
RR-пакете, или число блоков источника, содержащихся в SDES- или BYE-na-
кете. На рисунке это поле обозначено символами RC (для SR- или RR-паке-
тов) или SC (для SDES- или BYE-пакетов).
4- Тип пакета (8 бит). Идентифицирует тип RTCP-пакета. На рисунке это поле
обозначено символами РТ.
4- Длина (16 бит). Длина пакета в 32-разрядных словах минус один.
18.3. Протокол RTP
609
j RC Длина о CD О
Wil • SSRC отлрави теля е
Временная метка NTP (старшее слово) си со
Временная метка NTP (младшее слово) онны мтелз
Временная метка RTP =Г о го 9-
Счетчик пакетов отправителя S Е о. о
Счетчик байтов отправителя е-о
SSRC_1 (SSRC первого источника)
Доля потерь Суммарное число потерянных пакетов к
Расширенный максимальный порядковый номер полученных данных эобщенр
Флуктуация приема О
Временная метка последнего SR-сообщения о 5
Задержка с момента получения последнего SR-сообщения
SSRC отправителя
SSRC.1
(SSRC первого источника)
Доля Суммарное число
потерь потерянных пакетоа
Расширенный максимальный
порядковый номер
полученных данных
Флуктуация приема
Временная метка
последнего SR-сообщения
Задержка с момента
получения последнего
SR-сообщения
SSRC_n (SSRC л-го источника)
Доля потерь Суммарное число потерянных пакетов с
Расширенный максимальный порядковый номер полученных данных (X S т (D 3 ко
Флуктуация приема о о о
Временная метка последнего SR-сообщения о е; LQ
Задержка с момента получения последнего SR-сообщения
SSRC_1
(SSRC первого источника)
Доля Суммарное число
потерь потерянных пакетов
Расширенный максимальный
порядковый номер
полученных данных
Флуктуация приема
Временная метка
последнего SR-сообщения
Задержка с момента
получения последнего
SR-сообщения
б
й Р RC РТ = 202 Длиуа
SSRC/CSRC.1
Элементы SDES
v р |<здтил рт =: 204
SSRC/CSRC
Имя (ASCII)
>' Данные, зависящие
' от приложения ;
SSRC/CSRC n
Элементы SDES
Блок п Блок 1 Блок сообщения п Блок сообщения 1 Заголовок
v 1 3 SC Pt = 2D§ Длина
SSRC/CSRC1
SSRC/CSRC_n
Длина | Причина
завершения сеанса
в
Рис. 18.11. Форматы RTCP-пакетов
610
Глава 18. Протоколы поддержания качества обслуживания
Помимо 32-разрядного начального слова в пакетах сообщений отправителя
и получателя содержится поле идентификатора источника синхронизации (SSRC-
идентификатора), идентифицирующее источник этого RTCP-пакета.
Теперь мы перейдем к описанию каждого типа пакетов.
Сообщение отправителя
RTCP-получатели предоставляют обратную связь с информацией о качестве при-
ема при помощи сообщений получателя (RR) или отправителя (SR), если получа-
тель также является отправителем в данном сеансе. На рис. 18.11, а показан фор-
мат сообщения отправителя. Сообщение отправителя сос тоит из уже описанного
ранее заголовка, информационного блока отправителя, а также нескольких (или
ни одного) блоков сообщений о приеме. Поля информационного блока отправи-
теля перечислены ниже:
♦ Временная метка NTP' (64 бита). Абсолютное время отправки данного со-
общения. Это число с фиксированной точкой без знака, в котором целая
часть числа содержится в старших 32 разрядах, а дробная часть — в млад-
ших 32 разрядах. Временная метка NTP может использоваться отправите-
лем вместе с временной меткой, возвращаемой в сообщениях получателя,
чтобы измерить время прохождения сигнала в прямом и обратном направ-
лениях.
♦ Временная метка RTP (32 бита). Это относительное время, используемое
для создания временных меток в информационных RTP-пакетах. Такая мет-
ка позволяет получателю синхронизировать сообщение с информационны-
ми RTP-пакетами от данного источника.
♦ Счетчик пакетов отправителя (32 бита). Суммарное число информационных
RTP-пакетов, переданных данным источником за время текущего сеанса.
4- Счетчик байтов отправителя (32 бита). Суммарное число байтов полезной
нагрузки, переданных данным источником за время текущего сеанса.
За информационным блоком отправителя следуют ноль или несколько блоков
сообщения о приеме. Для каждого источника, от которого данный участник полу-
чил данные в течение этого сеанса, включается по одному блоку сообщения о при-
еме. В каждый блок включаются следующие поля:
4- SSRC_n (32 бита). Идентифицирует источник, к которому относится дан-
ный блок сообщения.
4- Доля потерь (8 бит). Доля информационных RTP-пакетов от источника
SSRC_n, потерянных за время данного сеанса.
4- Суммарное число потерянных пакетов (24 бита). Количество информационных
RTP-пакетов от источника SSRC_n, потерянных за время данного сеанса.
4- Расширенный максимальный порядковый номер полученных данных (32 бита).
Младшие 16 бит содержат максимальный порядковый номер RTP-данных, по-
лученных от источника SSRC n. Старшие 16 бит содержат счетчик, запоми-
нающий, сколько раз порядковый номер переполнялся и начинал счете нуля.
’ Что означает аббревиатура NTP, непонятно, поскольку больше нигде в книге она не употребляется. —
Примеч. ред.
18.3. Протокол RTP
611
Флуктуация приема (32 бита). Оценка значения флуктуации задержки ин-
формационных RTP-пакетов, полученных от источника SSRCn. Значение
этого поля будет обсуждаться ниже.
♦ Последняя временная метка SR (32 бита). Средние 32 бита временной метки
NTP в последнем SR-пакете, полученном от источника SSRC n. Эти 32 бита
включают младшие 16 разрядов целой части и старшие 16 разрядов дробной
части временной метки.
♦ Задержка с момента получения последнего SR-сообщения (32 бита). Интер-
вал времени 2“16 с между получением последнего SR-пакета от источника
SSRC_n и передачей данного блока сообщения. Последние два поля могут
использоваться источником для оценки времени прохождения данных до
определенного получателя и обратно.
Вспомним, что флуктуация задержки определяется как максимальное измене-
ние значения задержки пакетов в течение одного сеанса. Fie существует простого
способа измерить эту величину на приемной стороне, но можно оценить среднюю
величину флуктуации следующим образом. Определим следующие параметры для
данного источника у определенного получателя:
♦ 5(7) — временная метка от информационного RTP-пакета I;
4- R(I) — время прибытия информационного RTP-пакета 1, выраженное в еди-
ницах временной метки RTP (получатель должен использовать ту же самую
частоту таймера или интервал приращения, что и отправитель, но ему не
нужно синхронизировать значения времени с источником);
♦ D(J) — разница между интервалами времени прибытия пакетов у получате-
ля и временными интервалами между информационными RTP-пакетами,
покидающими источник;
/(7) — оценка средней флуктуации к моменту получения информационного
RTP-пакета I.
Значение 73(7) вычисляется так:
73(7) = (7?(7) - R(J- 1)) - (5(7) - 5(7- 1)).
Таким образом, значение 73(7) определяет, насколько временной интервал меж-
ду поступающими к получателю пакетами отличается от интервала между теми
же пакетами при их передаче. В отсутствии флуктуации значения этих интерва-
лов должны быть одинаковыми и значение 73(7) должно быть равно нулю. Флук-
туация вычисляется постоянно с получением каждого пакета 7 в соответствии со
следующей формулой:
1о 1о
J(J) вычисляется как экспоненциальное среднее1 от наблюдаемых значений 73(7).
Последнее наблюдение умножается на небольшой весовой коэффициент, так что
временной разброс не обесценивает оценку.
1 Для сравнения см. формулу (12.4).
612
Глава 18. Протоколы поддержания качества обслуживания
Информация, посылаемая в сообщении отправителя, позволяет отправителям
получателям и сетевым администраторам следить за состоянием сети в течение
данного сеанса. Например, количество потерянных пакетов указывает на наличие
постоянной пере грузки, тогда как флуктуация позволяет определить наличие вре-
менных перегрузок. Наличие флуктуации может служить предупреждением об
увеличивающейся нагрузке прежде, чем перегрузка приведет к потере пакетов.
Сообщение получателя
Для сообщения получателя (RR) используется тот же самый формат, что и для
сообщения отправителя, с той разницей, что поле типа пакета содержит другое
значение и в сообщении получателя нет информационного блока отправителя
(см. рис. 18.11, б).
Описание источника
Пакет описания источника (SDES) используется источником для предоставления
дополнительной информации о себе (см. рис. 18.11, в). Пакет состоит из 32-разряд-
ного заголовка, за которым могут располагаться ноль или несколько блоков, в каж-
дом из которых содержится информация об источнике. Каждый такой блок начи-
нается с идентификатора источника или одного из содействующих источников.
Следом располагается список элементов SDES. Типы элементов SDES, определен-
ные в RFC 1889, приведены в табл. 18.3.
Таблица 18.3. Типы SDES (RFC 1889)
Значение Название Описание
0 END Конец списка SDES
1 CNAME Каноническое имя, уникальное для данного RTP-сеанса
2 NAME Реальное имя пользователя источника
3 EMAIL Адрес электронной почты
4 PHONE Телефонный номер
5 LOC Географическое положение
6 TOOL Название приложения, генерирующего поток
7 NOTE Сообщение, описывающее текущее состояние источника
8 PRIV Индивидуальные экспериментальные или специфичные для приложения расширения
Завершение сеанса
Пакет завершения сеанса (BYE) сообщает, что один или несколько источников
прекратили активную деятельность. Приняв такой пакет, получатель понимает,
что длительное молчание источника вызвано не неисправностями в сети, а от-
ключением источника. Если пакет BYE получает смеситель, этот пакет пере-
правляется дальше с неизменным списком источников. Пакет BYE состоит из
32-разрядпого заголовка, за которым могут располагаться один или несколько
идентификаторов источников. Дополнительно пакет может включать текстовое
описание причины отключения источника.
18.5. Задания
613
Специфический пакет приложения
Этот пакет предназначен для экспериментального использования функций, спе-
цифических для данного приложения. В конце концов экспериментальному типу
пакета, доказавшему свою полезность, может быть назначен номер типа, а сам тип
включен в стандарт RTCP.
18.4. Рекомендуемые литература
и веб-сайты
В [245] содержится обзор философии и функциональности протокола RSVP, на-
писанный разработчиками протокола. В [32] предоставляется детальное обсужде-
ние архитектуры MPLS. В [231 ] описываются не только MPLS, но также интегри-
рованные и дифференцированные службы. Еще в этой книге есть превосходная
глава, посвященная конструированию трафика MPLS. В [226] включен детальный
обзор архитектуры MPLS и описываются различные частные инициативы, пред-
шествовавшие разработке архитектуры MPLS.
Рекомендуемые веб-сайты перечислены ниже:
♦ RSVP Project. Домашняя страничка, посвященная разработке протокола RSVP.
4 RSVP Working Group. Веб-страница рабочей группы, созданной по инициа-
тиве группы IETF для разработки стандартов, относящихся к дифференци-
рованным службам. Веб-сайт включает все относящиеся к данной теме до-
кументы RFC и проекты стандартов Интернета.
4- MPLS Forum. Сайт промышленного форума, посвященного продвижению
архитектуры MPLS.
4 MPLS Resource Center. Центр обмена информацией об архитектуре MPLS.
4- MPLS Working Group. Веб-страница рабочей группы, созданной по инициа-
тиве группы IETF для разработки стандартов, относящихся к архитектуре
MPLS. Веб-сайт включает все относящиеся к данной теме документы RFC
и проекты стандартов Интернета.
4- Audio/Video Transport Working Group. Веб-страница рабочей группы, создан-
ной по инициативе группы IETF для разработки стандартов, относящихся
к протоколу RTP. Веб-сайт включает все относящиеся к данной теме доку-
менты RFC и проекты стандартов Интернета.
4- About RTP. Веб-сайт, посвященный разработке протокола RTP, включая тех-
нические и промышленные разработки.
18.5. Задания
1. Так как номера портов UDP/TCP используются для классификации паке-
тов, в протоколе RSVP каждый маршрутизатор должен иметь возможность
проверять содержимое данных полей. Это требование приводит к появле-
614
Глава 18. Протоколы поддержания качества обслуживания
нию проблем в указанных далее областях. Поясните природу проблемы
в каждой области и предложите решение.
а) обработка заголовков IPv6;
б) безопасность на уровне IP.
2. Вернитесь к рис. 18.3, а. Эта диаграмма представляет собой упрощение, так
как у каждой пары (источник, получатель) в схеме групповой рассылки
имеется отдельное дерево маршрутов. Таким образом, выходные порты на
диаграмме должны быть помечены не только на основе получателей, но на
основе пар (источник, получатель). Аргументируйте свое согласие или не-
согласие с этим утверждением.
3. Спецификация MPLS позволяет LSR-маршрутизатору использовать техни-
ческий прием, называемый извлечением из стека на предпоследнем ретран-
сляционном участке (penultimate hop popping). При использовании данного
метода предпоследнему на LSP-пути LSR-маршрутизатору разрешается
удалять метку из пакета и последнему на LSP-пути LSR-маршрутизатору —
посылать пакет без метки.
а) объясните, почему возможен такой подход, то есть почему он приводит
к правильному результату;
б) в чем преимущество такого подхода?
4. В наборе протоколов TCP/IP стандартная практика заключается в том, что за-
головок, соответствующий данному протокольному уровню, содержит инфор-
мацию, идентифицирующую протокол, используемый на следующем, более
высоком уровне. Эта информация требуется для того, чтобы получатель про-
токольного модуля данных, удаляя данный заголовок, знал, как интерпрети-
ровать остальные биты заголовка. Например, заголовки IPv4 и IPv6 содержат
поля «Протокол» и «Следующий заголовок» соответственно (см. рис. 2.2
в главе 2). TCP- и UDP-пакеты содержат поля портов источника и приемни-
ка (см. рис. 2.1), которые могут применяться для идентификации протокола
прикладного уровня, используемого поверх протокола TCP или UDP. Однако
каждый узел архитектуры MPLS обрабатывает пакет, верхний элемент кото-
рого представляет собой поле MPLS-метки, не содержащее явной информации
об инкапсулированном протоколе. Как правило, этот протокол представляет
собой протокол IPv4, но это может быть также другой протокол сетевого уровня,
а) каким MPLS-узлам на LSP-пути необходима идентификация протокола
сетевого уровня в пакете;
б) какие ограничения должны налагаться на MPLS-метку для правильной
обработки;
в) подобные ограничения необходимы для всех меток в MPLS-стеке? Если
нет, то для каких меток они нужны?
5. Докажите эффективность или неэффективность использования протокола
RTP в качестве способа снижения сетевой перегрузки для трафика группо-
вой рассылки.
6. Покажите, как два последних поля в блоке сообщения SR или RR протоко-
ла RTCP могут применяться для вычисления времени распространения сиг-
нала в оба конца.
Часть VII
Сжатие данных
Несмотря на гигантские скорости передачи данных, применяемые в современных
сетях и системах передачи данных, интерес к сжатию данных для их последую-
щей передачи или хранения велик. В последние годы продолжается увеличение
пропускной способности сетей, тем не менее, потребности практически всегда
поспевают за предложениями и даже опережают их. Сжатие предоставляет возмож-
ность при сохранении пропускной способности сети снизить задержки, с которыми
сталкиваются приложения.
В часть VII вошли три главы.
♦ Глава 19. Теоретические основы сжатия данных. В этой главе предостав-
ляется обзор понятий, относящихся к теме части VII. Читатель, знакомый с
этой темой, может освежить свои знания. Для читателей, впервые с этим
столкнувшихся, в этой главе предоставляется достаточный объем информации,
ч тобы продолжить обсуждение в главах 20 и 21. В начале главы читатель зна-
комится с понятиями информации и энтропии, являющимися базовыми
в теории сжатия данных. Далее обсуждаются схемы кодирования, позволя-
ющие сжимать данные.
♦ Глава 20. Сжатие без потерь. Существует две формы сжатия данных, и обе
они получили широкое распространение: сжатие без потерь и сжатие с по-
терями. Сжатие без потерь сохраняет всю исходную информацию, так что
после распаковки данные полностью восстанавливаются. Сжатие без потерь
применяется для информационных файлов, сообщений и прочей информа-
ции, где ошибки в отдельных битах недопустимы. В главе 20 обсуждаются
некоторые из наиболее популярных методов сжатия без потерь, включая
групповое кодирование, различные методы факсимильного сжатия, ариф-
метическое кодирование и различные алгоритмы совпадения строк.
♦ Глава 21. Сжатие с потерями. Высокий коэффициент сжатия достижим толь-
ко в том случае, если отказаться от требования отсутствия потерь. Методы
сжатия с потерями позволяют сжимать файлы таким образом, что после распа-
ковки получаются данные, близкие к оригиналу. Эти методы полезны в тех
случаях, когда допустим определенный уровень потерь и искажений, например
при обработке звука или изображений. Глава начинается с обсуждения диск-
ретного косинусного преобразования, представляющего собой базовую техни-
ку многих алгоритмов сжатия с потерями. Затем изучается метод волнового
сжатия, быстрая и эффективная технология, получающая все более широкое
распространение. Методы сжатия изображений и видеоданных чрезвычайно
важны для разработки высокопроизводительных мультимедийных сетей.
Глава 19
Теоретические основы
сжатия данных
Современная точка зрения заключается в том. что чем
больше вероятность появления сообщений, тем меньше
информации в каждом из них. и любое математическое
определение информации должно следовать этой идее.
То есть объем информации, переносимый символом,
знаком, сообщением или наблюдением во множестве
подобных событий, должен уменьшаться с увеличени-
ем частоты появления в этом множестве.
Колин Черри. О человеческом общении
Прежде чем начать обсуждение проблем сжатия данных, освоим теоретический
фундамент — теорию информации. Основы теории информации были заложены
Клодом Шенноном (Claude Shannon) в процессе исследования пропускной способ-
ности информационного канала. Теория информации получила самые разнообраз-
ные применения. Для настоящего обсуждения важно то, что теория информации
определяет предел, до которого для заданного потока данных можно сжимать ин-
формацию без потерь.
Эта глава начинается с обзора концепций теории информации, после чего рас-
сматривается применение теории информации к кодированию.
19.1. Информация и энтропия
Основу теории информации составляют две математические концепции, назва-
ния которых могут ввести в заблуждение: информация и энтропия. Как прави-
ло, под информацией (information) подразумевается нечто, относящееся к смыс-
лу, а энтропия (entropy) — термин из второго закона термодинамики. В теории
информации информация имеет отношение к снижению неосведомленности о не-
коем событии, а энтропией называется усреднение информационных значе-
ний, подчиняющееся тем же математическим законам, что и термодинамическая
энтропия.
19.1. Информация и энтропия
617
Рассмотрим это новое определение информации на примере. Представим инвес-
тора, которому требуется информация (совет) о состоянии определенных ценных
бумаг. Этот инвестор советуется с брокером, обладающим специальной информа-
цией (знанием) в данной области. Брокер информирует (сообщает) инвестора, что
сегодня утром нагрянул федеральный инспектор, искавший информацию (свиде-
тельства) о возможном мошенничестве, в котором замешана корпорация, выпус-
тившая именно эти акции. В ответ на эту информацию (данные) инвестор решает
продать свои акции, о чем и информирует (уведомляет) брокера.
Другими словами, будучи неуверенным в вопросе о том, как распорядиться сво-
им портфелем ценных бумаг, клиент консультируется с кем-то более уверенным
в данном вопросе. Брокер уменьшает неуверенность клиента в этой области, рас-
сказав ему о визите федерального инспектора, который пришел, чтобы разре-
шить собственную профессиональную неуверенность. Кульминацией возрастаю-
щей уверенности клиента о состоянии своих ценных бумаг становится устранение
неуверенности брокера о намерении клиента продать эти ценные бумаги.
Хотя термин информация может означать уведомление, знание или просто дан-
ные, в каждом случае получение информации эквивалентно уменьшению неуве-
ренности. Таким образом, информация означает положительную разность между
двумя уровнями неуверенности.
Информация
Чтобы рассматривать понятие информации с точки зрения математики, нам нуж-
на определенная величина, годящаяся для измерения количества информации.
Впервые эту проблему сформулировал и решил Хартли (Hartley) в 1928 г., изучая
телеграфную связь. Хартли заметил, что если вероятность того, что некоторое со-
бытие произойдет, высока (близка к 1), неуверенность в том, что это событие про-
изойдет, невелика. Если впоследствии мы узнаем, что это событие произошло, то
количество полученной нами информации будет невелико. Таким образом, вну-
шающей доверие мерой информации может служить величина, обратная вероят-
ности некоего события, — 1/р. Например, если происходит событие, вероятность
которого равна 0,25, то мы получаем больше информации, чем если произойдет
событие, вероятность которого равна 0,5. Если мера информации равна 1/р, тогда
первое событие обладает информацией 4(1 /0,25), а количество информации о вто-
ром событии равно 2 (1/0,5). Но с использованием этой меры количества инфор-
мации связано две трудности.
Эта единица измерения, кажется, «не работает» с последовательностями
событий. Рассмотрим двоичный источник, генерирующий поток из единиц
и нулей с равной вероятностью значения каждого бита. Таким образом, каж-
дый бит несет количество информации, равное 2 (1/0,5). Но если бит Ь\ не-
сет в себе 2 единицы информации, то сколько информации содержится в
строке из двух битов bib2? Эта строка может содержать одну из четырех воз-
можных комбинаций битов, причем каждое из четырех значений строка
может принимать с вероятностью 0,25. Таким образом, при использовании
618 Глава 19. Теоретические основы сжатия данных
в качестве меры количества информации величину 1/р два бита будут со-
держать четыре единицы информации. Продолжая данные рассуждения
количество информации, содержащееся в трех битах (bibibs), равно восьми
Это означает, что первые два бита, bi и bi, несут по две единицы информации
а третий бит (Ь3) добавляет сразу четыре единицы информации. Следующий
бит (Ь4) добавит к последовательности уже восемь единиц информации и т. д
Это не кажется разумным.
♦ Рассмотрим событие, приводящее к изменению двух или более независимых
переменных. Примером такого события может быть сигнал, кодируемый при
помощи так называемого метода фазовой манипуляции, для которого ис-
пользуется четыре возможных фазы и две амплитуды. Один элемент такого
сигнала содержит две единицы информации для амплитуды и четыре для
фазы, итого шесть единиц. В то же время, каждый элемент сигнала может
иметь восемь возможных значений, и поэтому должен соответствовать вось-
ми единицам информации, если пользоваться принятой нами мерой.
Хартли разрешил данную проблему, прологарифмировав данную величину, то
есть он предложил в качестве меры количества информации события х функцию
log(l/P(x)), где Р(.г) означает вероятность событиях. Формально можно написать:
1(х) = log (1/Р(х)) = - log Р(х). (19.1)
Эта мера количества информации «работает» и позволяет получить множество
полезных результатов. Основание логарифма может быть взято произвольно, по
удобнее всего логарифмировать по основанию 2, в этом случае единица информа-
ции называется битом. Правильность такого подхода должна стать очевидной по
мере чтения данного раздела, и далее подразумеваются логарифмы по основанию 2.
Можно отметить следующее:
4- Один бит, с равной вероятностью принимающий значения 0 и 1, несет в себе
один бит информации (log( 1/0,5) = 1). Строка из двух битов может прини-
мать четыре равновероятных результата с вероя тностью 0,25 и содержит два
бита информации (log( 1/0,25) = 2). Таким образом, второй бит добавляет
один бит информации. В последовательности из трех независимых битов
третий бит также добавляет один бит информации (log( 1/0,125) = 3) и т. д.
♦ В примере сигнала, кодированного методом фазовой манипуляции, один
элемент сигнала несет один бит информации для амплитуды и два бита для
фазы, итого три бита, что согласуется с наблюдением о восьми возможных
результатах.
На рис. 19.1 показан график зависимости количества информации единичного
события от вероятности этого события. Когда вероятность события приближа-
ется к единице (событие происходит почти наверняка), количество информации,
содержащееся в данном событии, приближается к нулю. И наоборот, когда ве-
роятность события приближается к нулю (событие практически невероятно),
количество информации, содержащееся в данном событии, приближается к бес-
конечности.
19.1. Информация и энтропия
619
Рис. 19.1. Количество информации, содержащееся в одном событии
Энтропия
Другая важная концепция теории информации — энтропия. Эта концепция была
предложена в 1948 г. основателем теории информации Шенноном (Shannon). Шен-
нон определил энтропию как среднее количество информации, получаемое от зна-
чения случайной переменной. Предположим, что имеется случайная переменная
X, способная принимать значения xlt х2.xN, и что соответствующие вероятности
каждого исхода равны P(xi), Р(х2),..., Р(хк). В последовательности из К перемен-
ных X результат xj в среднем будет выбран КР(х,') раз. Таким образом, среднее ко-
личество информации, получаемое от К событий, равно (будем использовать обо-
значение Pj для Р(х/)):
КРх log (1/Р.) + ... + КР„ log (1/Pt).
Если разделить это выражение на К, то мы получим среднее количество инфор-
мации для одного результата случайной переменной, называемое энтропией X и
обозначаемое как Н(Х):
Н(Х) = P?log(l/^) = -f WA (19.2)
j=l 7=1
Функция Н часто выражается как перечень вероятностей возможных резуль-
татов: H(Pt, Р2.Pv).
620
Глава 19. Теоретические основы сжатия данных
Для примера рассмотрим случайную переменную X, принимающую два воз-
можных значения с соответствующими вероятностями Р и 1 - Р. В этом случае ас-
социированная с X энтропия будет равна
Я(Р, 1 - Р) = - Р log(P) - (1 - P)log( 1 - Р).
На рис. 19.2 показан график Н(Х) для данного случая как функция от Р. По этому
графику можно отметить несколько важных особенностей энтропии. Во-первых,
если одно из двух событий является достоверным (Р= 1 или Р= 0), тогда энтропия
равна нулю1. Одно из двух событий должно произойти, и никакой информации
о том, что одно из них произошло, не содержится. Во-вторых, максимального
значения функция Н(Х) достигает, когда два результата равновероятны. Это так-
же обоснованно: когда два результата равновероятны, неуверенность в результате
максимальна. Этот результат можно обобщить для случайной переменной с N ре-
зультатами. Энтропия случайной переменной будет максимальна, когда все ре-
зультаты равновероятны:
max Н(Рь Р2,..., Pv) = Н( 1/М i/N,..., t/N).
Например,
H(l/3,1/3, 1/3) = 1/3 log 3 + 1/3 log 3 + 1/3 log 3 = 1,585,
тогда как
И (1/2,1/3,1/6) = 1/2 log 2 + 1/3 log 3 + 1/6 log 6 = 0,5 + 0,528 + 0,43 = 1,458.
Рис. 19.2. Функция энтропии для случайной переменной с двумя значениями
1 Строго говоря, формула для Н(Х) при Р = 0 не определена. Считается, что значение этой функции J
при Р = 0 равно 0, так как в пределе ЩХ) стремится к 0 при значении Р, стремящемся к 0. /
19.1. Информация и энтропия
621
Свойства функции энтропии
Мы разработали формулу энтропии Н(Х) путем интуитивно понятных рассужде-
ний. Другой метод заключается в том, чтобы определить свойства, которыми долж-
на обладать функция энтропии, а затем доказать, что формула
2
является единственной формулой, обладающей данными свойствами. Эти свой-
1 ства, или аксиомы, можно сформулирован» следующим образом:
♦ Функция Н непрерывна на всем диапазоне вероятностей. Это значит, что
небольшие изменения вероятности одного из событий вызывают небольшие
изменения неуверенности. Это требование кажется разумным.
♦ Если существует Nравновероятных результатов, то есть Р, = 1 /N, тогда Н(Х)
является монотонно возрастающей функцией N. Это свойство также разум-
но, так как оно утверждает, что чем больше равновероятных результатов, тем
выше неуверенность.
+ Если сгруппировать некоторые результаты случайной переменной X, тогда
энтропию //можно выразить как следующую взвешенную сумму энтропий:
H(Pi,P2,P3,
Р„) = + Р2, Р„ .... PN) + (Д + Р2)Н
' I 12
Pt+P2’ Ъ+Р2
Обоснование здесь может быть использовано следующее. До того как ре-
зультат станет известным, средняя неопределенность, связанная с резуль-
татом, равна H(Pt, Р-2, Р3,...»Рл’). Если сгруппировать первые два результата,
тогда средняя неопределенность будет равна H(Pt + Р2, Р3,..., Pn). С вероят-
ностью (Pi + Рг) произойдет одно из первых двух событий, и оставшаяся
неопределенность составит величину H(Pi/(Pi + Рг) + Р2ДР1 + Рг)).
Единственное определение Н(Х), удовлетворяющее всем трем свойствам, — это
то, которое мы только что привели. Справедливость первого свойства очевидна из
графика на рис. 19.2, демонстрирующего непрерывность функции. Изобразить гра-
фик Н(Х) при наличии более двух возможных результатов значительно труднее,
но свойство непрерывности должно соблюдаться и в этом случае.
Проиллюстрируем второе свойство. Если существует N равновероятных ре-
зультатов, тогда функция Н(Х) приобретает следующий вид:
Н(Х) = -X-!og - = -log - = log(N).
N {N) (ZVJ
Функция log(N) монотонно возрастает с увеличением N. Обратите внимание
на то, что при четырех возможных результатах энтропия равна 2 битам; при вось-
ми возможных результатах — 3 битам и т. д.
В качестве численного примера последнего свойства мы можем написать:
i
Я [
2 3 6
=4vi+Mv
6 6 6 Г "
6’6
5 1
3 2 j
5’5 ’
5
1,458 = 0,219 + 0,43 +1 (0,442 + 0,5288) = 0,649 + 0,809.
622
Глава 19. Теоретические основы сжатия данных
19.2. Кодирование
Одно из важных приложений концепции энтропии заключается в том, что эта кон-
цепция помогает понять принципы работы алгоритмов сжатия данных. Энтропия
случайной переменной или источника сообщений определяет количество битов,
требуемых для представления результатов случайной переменной или альтерна-
тивных сообщений без потери информации. Таким образом, при разработке алго-
ритма сжатия данных энтропия представляет собой меру максимально возможного.
Мы начнем этот раздел с рассмотрения кода Хаффмана (Huffman), представ-
ляющего собой простой, но эффективный код, иллюстрирующий взаимосвязь
между энтропией и эффективностью сжатия. Затем мы представим общий резуль-
тат по вопросу энтропии и сжатия. Наконец, мы вернемся к коду Хаффмана, что-
бы проиллюстрировать некоторые основные принципы сжатия данных.
Код Хаффмана
Рассмотрим случайную переменную X, принимающую одно из восьми возможных
значений (xt, х2,..., хв) со следующими вероятностями:
Л = 0,512, Р5 = 0,032,
Р2 = 0,128, Рй = 0,032,
Рз = 0,128, Р7 = 0,032,
Р4 = 0,128, Р8 = 0,008.
Здесь Р, представляет собой вероятность выпадения результата х,-. Предполо-
жим, что сообщение состоит из реализаций случайной переменной X, и мы хотели
бы закодировать сообщение в двоичном виде. Один очевидный вариант решения
заключается в том, чтобы использовать 3-битовый код фиксированной длины,
в котором каждое из восьми возможных значений случайной переменной X коди-
руется одним 3-битовым числом. Лучшая стратегия заключается в использовании
кода переменной длины, в котором более длинные кодовые слова назначаются
менее вероятным значениям X, а более вероятные значения X кодируются корот-
кими кодовыми словами. Такой технический прием применяется в азбуке Морзе
и коде Хаффмана.
Предположим, что сообщения должны передаваться при помощи алфавита из
Nсимволов. Каждый символ должен уникальным образом кодироваться двоичной
последовательностью. Нас интересует способ построения оптимального кода, то
есть кода, дающего в результате минимальную среднюю длину кодируемого сообще-
ния. Важно отметить, что мы не ищем минимальную длину кода для какого-либо
конкретного сообщения или для всех сообщений (последнее найти невозможно),
но минимальную длину кода, усредненную по всем возможным сообщениям.
Другой способ взглянуть на данные требования состоит в том, что мы получа-
ем сообщение, уже закодированное путем назначения символам двоичных слов
фиксированной длины. Таким образом, если символов 8, каждый символ кодиру-
ется тремя битами. Если число символов в алфавите от 9 до 16, то каждый символ
19.2. Кодирование
623
кодируется четырьмя битами и т. д. Такое кодирование не является оптимальным,
если символы встречаются в сообщениях с разной вероятностью. В этом случае
требование может быть сформулировано следующим образом. Требуется разрабо-
тать оптимальную схему кодирования с использованием кода переменной длины,
позволяющую получить кодированное сообщение минимальной средней длины.
Рассмотрим двоичный код с кодовыми длинами Lb L2,..., Ln, поставленный
в соответствие алфавиту из N символов с вероятностями Рь Р2,..., PN. Для удоб-
ства предположим, что символы организованы в порядке убывания вероятности
(Pi > Р2 > ... > Pn). Можно показать, что оптимальный код должен удовлетворять
следующим требованиям:
♦ Никакие два разных сообщения не должны состоять из одинаковых после-
довательностей битов.
4 Никакое кодовое слово не должно совпадать с префиксом другого кодового
слова.
♦ Символы, встречающиеся с большей вероятностью, должны кодироваться
более короткими кодовыми словами. То есть Lt<L2<... < Ln.
4- Два кодовых слова для символов с наименьшей вероятностью должны иметь
одинаковую длину (Z.v=iw-t) и различаться только последней цифрой.
Первое требование гарантирует уникальность кодирования любого сообщения.
Второе требование определяет так называемый мгновенный код. Это требование
не является строго обязательным, но оно требуется, чтобы гарантировать, что сооб-
щение может быть декодировано шаг за шагом. При продвижении слева направо,
как только последовательность битов совпадает с данным кодовым словом, деко-
дирующий алгоритм может произвести соответствующее назначение. Вот пример
кода, нарушающего первые два требования:
Xi О
х2 010
Хз 01
х\ 10
Двоичная последовательность 010 может соответствовать одному из трех со-
общений: Л'2, ХзХ'1, Х1Х4.
Назначение третьего требования легко понять, если отметить, что при наруше-
нии данного условия, поменяв два кода, вы сможете получить меньшее значение
средней длины.
Чтобы понять суть последнего требования, предположим, что Ln > Ln-i- По вто-
рому требованию кодовое слово - 1 не может быть префиксом кодового слова N.
Поэтому первые N - 1 цифры кодового слова ДГ составляют уникальное кодовое
слово, а остальные цифры можно отбросить. Если эти два кодовых слова разли-
чаются в каком-либо бите, кроме последнего, мы можем отбросить последний бит
у каждого слова, получая таким образом лучший код.
На основании этих методов можно построить код, называемый кодом Хафф-
мана. Начнем с упорядочивания всех символов по убыванию вероятности, так
что мы получим символы (fli, а2,..., ад) с вероятностями (Ра\) > (Ра2) ... (Pon).
624
Глава 19. Теоретические основы сжатия данных
Затем объединим два последних символа в эквивалентный символ с вероятно-
стью (Pan-i) + (PaN). Коды этих двух символов будут одинаковыми, кроме послед-
них двух цифр. Теперь у нас есть новый набор из N - 1 символов. При необходи-
мости поменяем порядок следования символов таким образом, чтобы получить
символы (bh b2,..., bN_|) с вероятностями (Р/ц) > (Pb2) > ... > (PbN-t). Теперь мы мо-
жем повторять этот процесс до тех пор, пока не останется всего два символа.
Рисунок 19.3 иллюстрирует этот процесс для набора символов, заданного в на-
чале раздела. Будем считать каждый символ листовым узлом создаваемого дере-
ва. Объединим два узла с минимальной вероятностью в узел, вероятность которого
равна сумме двух соответствующих вероятностей. На каждом шаге будем повто-
рять этот процесс до тех пор, пока не останется только один узел. В результате мы
получим дерево, в котором у каждого узла, кроме корневого, одна ветвь отходит
направо и две налево. На каждом узле пометим две левые ветви символами 0 и 1
соответственно. Для каждого символа кодовое слово представляет собой строку
меток от корневого узла к исходному символу. Все получившиеся в результате ко-
довые слова показаны в левой части рисунка. Для примера процесс построения
кодового слова для символа Xi обозначен жирной линией.
О X!
100 х2
101 х3
110 х4
11100 х5
11101 х6
11110 х7
11111 х8
0,512-------0,512-
0,128-------0,128-
0,128-------0,128-
0,128-------0,128-
0,512
0,128-
-0,128-
-0,128-
0,512-------0,512-------0,512-------0,512
0,008-
Рис. 19.3. Код Хаффмана с восемью символами
В табл. 19.1 приведены свойства кода Хаффмана для данного примера. Сред-
няя длина кодового слова представляет собой вычисляемую следующим образом
ожидаемую величину:
ад = =2,184.
Здесь Li представляет собой длину г-го кодового слова. Таким образом, напри-
мер, для сообщений, состоящих из 1000 символов, средняя длина кодированного у
19.2. Кодирование
625
сообщения равна 2184 бит. При простом кодировании каждого символа тремя би-
тами длина этого сообщения будет составлять 3000 бит.
Таблица 19.1. Коды Хаффмана для восьми символов
Символ Код р, P.L 1од(1/РД Р1од(1/Р)
Х1 0 0,512 1 0,512 0,966 0,494
Хг 100 0,128 3 0,384 2,966 0,38
Хз 101 0,128 3 0,384 2,966 0,38
Х4 110 0,128 3 0,384 2,966 0,38
х5 11100 0,032 5 0,16 4,966 0,159
Хб 11101 0,032 5 0,16 4,966 0,159
х7 11110 0,032 5 0,16 4,966 0,159
хе 11111 0,008 5 0,04 6,966 0,056
Средняя длина = 2,184 Энтропия = 2,176
Энтропия и эффективность кодирования
Рассмотрим случайную переменную с множеством возможных значений (xb х2, x.v),
принимаемых с вероятностями (Рь Р2,Рк), где Р, означает вероятность резуль-
тата Определим нижнюю границу средней длины кода. Из формулы (19.1) мы
знаем, что мерой информации для х, является log( 1 /Р,). Поэтому в идеальном слу-
чае мы сможем представить значение х, кодовым словом длины £, = log( 1/Р,) бит.
Однако в большинстве случаев log( 1/Р,) не является целым числом, и лучшее, что
мы можем сделать, — это выбрать ближайшее целое число £„ такое что
log (1/Р,) < Ц < log (1/Р) + 1. (19.3)
Умножая на Р, и суммируя по всем кодовым словам с помощью формулы (19.2),
получаем:
,v ,v ,v ,v
£ plog(l/p) < £ />/, < £ Plog(l/P) + £ р,
r=l i=l г=1 1=1
Н(Х) < £[£] < Н(Х) + 1.
Таким образом, оптимальный код позволяет получить среднюю длину кода, не
более чем на 1 бит превосходящую энтропию оригинального набора символов. Таким
образом, энтропия случайной переменной X может интерпретироваться как мини-
мальное среднее число битов, необходимых для отображения одного значения X.
Можно показать, что код Хаффмана удовлетворяет данному неравенству. При-
мер приводится в табл. 19.1. Средняя длина кода составляет 2,184, а энтропия рав-
на 2,167. Обратите внимание на то, что не все отдельные кодовые слова удовлет-
воряют неравенству (19.3). Однако в среднем это неравенство выполняется.
Характеристики кода Хаффмана
Два наблюдения, касающиеся кода Хаффмана, позволяют понять принципы рабо-
ты алгоритмов сжатия данных. Эти наблюдения относятся к объединению симво-
лов и использованию зависимостей.
626
Глава 19. Теоретические основы сжатия данных
Объединение символов
Предположим, что у нас есть источник, генерирующий символы из алфавита X,
состоящего всего из двух символов А и В, встречающихся с вероятностью 0,8 и 0,2.
Энтропия при такой схеме составляет 0,8 log(l,25) + 0,2 log(5) » 0,722 (см. рис. 19.2).
Но лучшее, что можно сделать в данном случае, — это использовать по одному биту
для каждого кодового слова (например, А = 0, В = 1). Если определить эффективность
кода как отношение энтропии источника (среднее число битов информации в сим-
воле) к средней длине кодового слова (среднее число битов, используемых для
кодирования одного символа), тогда эффективность этого кода будет равна 0,722.
Эффективность кода можно повысить, если объединить символы в блоки и ко-
дировать эти блоки символов. Например, если мы будем кодировать по два симво-
ла одновременно, тогда можно рассматривать полученные в результате блоки сим-
волов как новый алфавит У, состоящий из четырех символов (АА, АВ, BA, ВВ).
Если символы алфавита X следуют в сообщениях независимо друг от друга, тогда
вероятности, с которыми в них встречаются символы алфавита У, будут равны:
Раа = 0,64; Рдв = 0,16; Рва = 0,16; Рвв = 0,04. На рис. 19.4, а показан код Хаффмана для
такого варианта объединения символов в блоки, а в верхней части табл. 19.2 — ста-
тистика этого кода. В результате мы получаем код со средней длиной 1,56 при эн-
тропии, равной 1,444, таким образом, эффективность кода составляет 0,926, что
значительно лучше, чем при кодировании исходных символов без группировки.
Обратите внимание на то, что информация источника не изменилась. Энтропия
случайной переменной X равна 0,722, а энтропия У равна 0,722 • 2 = 1,444, то есть
все также по 0,722 бита на символ.
Еще лучших результатов можно достичь, объединив символы по три. В этом
случае мы получим вероятности, показанные в табл. 19.1. То есть РААа = 0,8 • 0,8 •
0,8 = 0,512; Раав = 0,8 • 0,8 • 0,2 = 0,128 и т. д. В данном случае эффективность кода
составит 2,167/2,128 = 0,992. Энтропия все также будет составлять 0,722 бит на
символ (2,167/3).
0 АА
11 АВ
а
100 ВА
101 ВВ
0 АА
11 ВВ
б
100 АВ
101 ВА
Рис. 19.4. Код Хаффмана с четырьмя символами
19.2. Кодирование
627
Таблица 19.2. Коды Хаффмана для четырех символов
Символ Код Р L, P,L, log(1/P() P,log(1/P)
Независимые символы
АА 0 0,64 1 0,64 0,644 0,412
АВ 11 0,16 2 0,32 2,644 0,423
ВА 100 0,16 3 0,48 2,644 0,423
ВВ 101 0,04 3 0,12 4,644 0,186
Средняя длина = 1,56 Энтропия = 1,444
Зависимые символы
АА 0 0,72 1 0,72 0,474 0,341
ВВ 11 0,12 2 0,24 3,059 0,367
АВ 100 0,08 3 0,24 3,644 0,292
ВА 101 0,08 3 0,24 3,644 0,292
Средняя длина = 1,44 Энтропия = 1,292
Зависимость символов не учитывается
АА 0 0,72 1 0,72
АВ 11 0,08 2 0,16
ВА 100 0,08 3 0,24
ВВ 101 0,12 3 0,36 Средняя длина = 1,48
Можно показать, что эффективность оптимального кода для независимых по-
следовательностей символов может быть повышена путем объединения символов,
как это было показано ранее. Для блока из К символов мы получим следующее
соотношение:
Я(Х)<Щ<Н(Х) + 1.
1\ IX.
Таким образом, среднее количество битов на одно значение случайной пере-
менной X можно сделать сколь угодно близким к энтропии, выбирая все большие
размеры блоков.
Переходные зависимости
В предыдущем пункте предполагалось, что следующий символ в последователь-
ности не зависит от предыдущего символа. Однако если такая зависимость суще-
ствует, тогда вероятности, связанные с блоками символов, меняются. Например,
рассмотрим снова алфавит X из двух символов и предположим, что к нему приме-
нимы следующие переходные вероятности:
А В
А 0,9 0,1
В 0,4 0,6
Таким образом, вероятность того, что за символом А последует символ А, рав-
на 0,9; вероятность того, что за символом В последует символ А, равна 0,1 и т. Д-
Несложно доказать непротиворечивость матрицы переходов при вероятностях
появления отдельных символов А и В, равных 0,8 и 0,2 соответственно.
628
Глава 19. Теоретические основы сжатия данных
Теперь разработаем код для алфавита У, составленного из комбинаций этих
символов по два. Мы получим:
Рлл = Рг(А|А)Ра = 0,9 • 0,8 = 0,72,
Pw = Рг(В|А)Рл = 0,1 0,8 = 0,08,
РБЛ = Рг(А|В)Рв = 0,4 0,2 = 0,08,
Рвв = Рг(В|В)Рв = 0,6 • 0,2 = 0,12.
На рис. 19.4, б показан код Хаффмана для данного случая, а в средней части
табл. 19.2 — полученная в результате статистика. Обратите внимание на то, что
энтропия У меньше, чем в случае, когда следующие друг за другом символы неза-
висимы (1,292 против 1,444). Поскольку вероятности для отдельных символов ос-
тались теми же самыми (РЛ = 0,8, Рв = 0,2), то чем это объясняется? Ответ состоит
в том, что вероятности переходов добавляют информацию. Когда становится из-
вестен первый символ последовательности, мы получаем больше информации
о том, какой символ появится следующим. Поэтому неопределенность уменьша-
ется, и суммарная энтропия также снижается. Другими словами, в последователь-
ностях появляется избыточность. Так, например, существует значительная избы-
точность в предложениях на английском языке.
В табл. 19.2 для случая зависимых символов средняя длина кода равна 1,44, что
дает эффективность 1,292/1,44 = 0,897. В нижней части табл. 19.2 показано, что
произойдет, если проигнорировать переходные вероятности и предположить, что
следующие друг за другом символы независимы даже в том случае, если они зави-
симы. В этом случае используются те же коды, что и для независимых символов
(ЛА = 0, АВ =11, ВА = 100, ВВ = 101). Однако теперь для второй по частоте ком-
бинации ВВ используется самое длинное кодовое слово 101, поэтому средняя дли-
на кодового слова оказывается равной 1,48, что больше средней длины, получав-
шейся при использовании оптимального кода Хаффмана.
Из этого обсуждения можно сделать вывод, что большей эффективности в сжа-
тии данных можно достичь, кодируя данные большими блоками, а также учиты-
вая зависимости данных.
19.3. Рекомендуемая литература
Существует масса книг по теории информации. Непревзойденной классической
книгой, издаваемой до сих пор, является [88]. Два более современных издания, в
которых особое внимание уделяется теме сжатия информации, — это [110] и [61].
Для самостоятельного изучения годится [ 16]. В [208] переизданы многие относя-
щиеся к этой теме важные статьи, включая конструктивные статьи Шеннона.
19.4. Задания
1. Покажите, что представленное ниже соотношение выполняется для функции
энтропии случайной переменной с тремя возможными значениями Н(Р\, Рг, Рз)'
H(PV рг, р3,pv) = Н(Д + р2, р3,..., pN) + (Д + д)яГ-А_, .
19.4. Задания
629
2. Является ли представленный ниже код уникально расшифровываемым?
Если нет, постройте неоднозначную последовательность:
Х1010 х30110 х5 00011 х711110
х20001 х41100 хеООИО х8101011
3. Создайте коды Хаффмана для следующих символов; в каждом случае сим-
волы нумеруются в соответствии с вероятностью, с которой они встречают-
ся в последовательности:
а б В Г
х, 0,4 х, 0,4 х, 9/36 х, 0,2
х20,2 х20,3 х2 6/36 х20,18
х30,1 х30,2 х36/36 хэ0,1
Хд0,1 Хд0,04 х44/36 х40,1
х50,1 х50,04 х5 3/36 х50,1
х60,1 х6 0,02 х6 3/36 х6 0,061
х? 2/36 х7 0,059
х8 2/36 х6 0,04
х91/36 х9 0,04
х,с0,04
Хи 0,04
X12 0,03
Х13 0,01
4. Одно из требований к оптимальному коду выглядит как Ц < L2 <... < Av- Что-
бы доказать справедливость этого требования, предположим, что у нас есть
код С с Р, > Рь и I,- > Lk. Теперь создайте код С, поменяв кодовые слова i и k.
Вычислите разницу между средней длиной кодовых слов С и С.
5. Рассмотрим алфавит из двух символов А и В с представленной ниже тран-
зитной матрицей. Покажите, что эта матрица является непротиворечивой
при РЛ = 0,8, Рв = 0,2:
А В
А 0,9 0,1
В 0,4 0,6
6. Которые из перечисленных ниже схем кодирования могут быть получены с
помощью алгоритма Хаффмана, а которые нет? Для кодовых схем, могущих
представлять коды Хаффмана, укажите распределение вероятностей, для
которого данный код может представлять оптимальный код Хаффмана.
а) {х,, .г-2, х3, х4} -> {010,011,001,10};
б) {xi, х2| Хз, х4} —> {0,10,110,111};
в) {Х1,Х2,Хз, xt] —> {10, 0,101,11};
г) {х(, х2, х3, х4} —> {00,010,011,1}.
Глава 20
Сжатие без потерь
Одно было хорошо — больше никто не мог сесть в по-
езд. Однако на станции Эйнджел и затем еще раз на Олд
Стрит она убедилась, что это не так. Возможно, та точка,
после которой в вагон уже никто не может втиснуться,
была недостижима, и они могли бы еще сколько угодно
продолжать втискиваться и давиться, пока не задавили
бы друг друга или пока не разорвало бы стены вагона.
Барбара Байн (Рут Ренделл). Ковер царя Соломона
Принцип сжатия данных довольно прост. Практически все формы представле-
ния данных (текст, числа, изображение, видео) содержат избыточные элементы.
Данные могут быть сжаты с одной из двух целей: для экономии места при хране-
нии или для снижения потребностей в пропускной способности. Когда сжатые
данные извлекаются из места хранения или прибывают по линии связи, должна
существовать возможность распаковать данные, восстановив их исходную фор-
му. Для этого при сжатии данных удаляемые элементы данных должны заме-
щаться другими таким образом, чтобы получатель смог восстановить исходную
информацию.
Существует две основные разновидности сжатия данных: сжатие без потерь и
сжатие с потерями. При сжатии без потерь (lossless compression) информация не
теряется и распакованные данные идентичны исходным несжатым данным. Как
было показано в главе 19, эффективность сжатия без потерь ограничена энтропи-
ей источника данных. В случае сжатия с потерями (lossy compression) распако-
ванные данные могут быть приемлемым приближением (в соответствии с некото-
рым критерием точности) к исходным несжатым данным. Например, при сжатии
изображений или видеоданных критерий может заключаться в том, что для чело-
веческого глаза распакованное изображение неотличимо от оригинала.
Важным фактором при разработке и выборе алгоритмов сжатия данных явля-
ется объем работ, требуемый для сжатия и распаковки данных. В общем случае
существует компромисс между достижимой степенью сжатия и скоростью работы
алгоритма сжатия, а также стоимостью этой работы.
В этой главе рассматриваются некоторые из наиболее важных и широко ис-
пользуемых схем сжатия без потерь, применимые в ряде контекстов. В главе 21
20.1. Методы группового кодирования
631
изучаются схемы сжатия данных с потерями, специально разработанные для сжа-
тия изображений и видеоданных.
Глава начинается с обсуждения очень простого метода, называемого группо-
вым. Затем мы покажем, как этот метод используется в стандартах факсимильно-
го сжатия. За этим следует описание арифметического кодирования. В заверше-
ние изучаются методы сжатия данных Лива — Земпеля (Liv — Zempel).
20.1. Методы группового кодирования
Групповое кодирование (run-length encoding) представляет собой простой метод
сжатия данных без потерь, довольно эффективный для сжатия текста. Этот метод
также находит применение в факсимильном сжатии, обсуждаемом в разделе 20.2.
В начале этого раздела обсуждается еще более простая техника подавления нулей,
после чего описывается метод группового кодирования, представляющий собой
обобщение метода подавления нулей.
Подавление нулей
Один из старейших и простейших методов сжатия данных известен как подавление
нулей (null suppression), или подавление пробелов (blank suppression). Он до сих
пор применяется в протоколе уровня передачи данных BISYNC (Binary Synchronous
Communications protocol — двоичный синхронный протокол связи) IBM 3780.
В тексте или потоке символов часто встречаются длинные строки пробелов или
нулей. В методе подавления нулей передатчик сканирует данные в поиске строк
пробелов и заменяет каждую такую строку двухсимвольным кодом. Код состоит
из специального управляющего символа, за которым следует число пробелов в стро-
ке. Например, пусть имеется код с символами пробела, обозначенными знаком Ь:
XYZbbbbbQRX.
Эта строка заменяется следующей строкой, в которой Sc представляет собой
специальный управляющий символ:
XYZS.5QRX.
Такая схема позволяет сделать короче все строки из трех и более пробелов.
В методе подавления нулей приемник ищет в потоке входящих символов спе-
циальный символ, используемый для индикации удаленных пробелов. Получив
такой символ, получатель понимает, что следующий символ содержит количество
удаленных пробелов. По этой информации может быть восстановлен исходный
поток данных.
При том что метод подавления нулей представляет собой крайне примитивную
форму сжатия данных, его преимущество заключается в том, что он очень легко
реализуется. Кроме того, выигрыш даже от применения такого простого метода
может быть значительным. Как сообщалось в [113], выигрыш от перехода с прото-
кола IBM 2780 на протокол 3780 в ряде компьютерных конфигураций составил от
30 до 50 %, и все это благодаря данному методу сжатия данных.
632
Глава 20. Сжатие без потерь
Групповое кодирование
Групповое кодирование представляет собой обобщение метода подавления нулей.
Групповое кодирование применяется для сжатия повторяющихся данных любого
типа. На рис. 20.1 иллюстрируется применение данного метода к символьным дан-
ным. Здесь используются следующие обозначения:
♦ Sc — специальный символ, указывающий на то, что за пим следуют сжатые
данные;
♦ X — любой повторяющийся символ;
♦ С, счетчик символов, то есть количество повторений сжатого символа.
Рис. 20.1. Формат сжатия при групповом кодировании
В табл. 20.1 приводится несколько примеров сжатия по этому алгоритму.
Таблица 20.1. Примеры сжатия при групповом кодировании
Исходная строка данных Кодированная строка данных
$*****‘55.72 SST655.72
— Sc-9
GunsbbbbbbbbbButter GunsScb9Butter
Как и в методе подавления нулей, передатчик ищет последовательности повто-
ряющихся символов. В данном случае он заменяет их трехсимвольным кодом. Код
состоит из специального индикатора сжатия, за которым следуют сам повторяю-
щийся символ и число его повторений. Таким образом, данный метод позволяет
сократить место, занимаемое любой последовательностью из четырех и более оди-
наковых символов.
Эффективность метода группового кодирования зависит от того, насколько
часто в исходных данных встречаются последовательности повторяющихся
символов, и от средней длины таких серий. Стандартной мерой эффективности
сжатия является коэффициент сжатия, представляющий собой отношение дли-
ны несжатых данных к длине сжатых данных (включая символы кодирования).
В табл. 20.2, взятой из [ИЗ], показаны коэффициенты сжатия при использова-
нии метода группового кодирования с различными входными последователь-
ностями из 1000 символов. Здесь представлены результаты сжатия, для количе-
ства серий с повторами в исходных данных, варьирующегося от 10 до 50, и для длин
серий, варьирующихся от 4 до 10. Для этих вариантов исходных данных метод
группового кодирования показал коэффициент сжатия от 1,01 до 1,538 в зави-
симости от характеристик входного текста. Это показывает, что любая схема
сжатия будет обладать переменной производительностью, зависящей от исходных
данных. Однако в большинстве случаев в тексте содержится достаточное количе-
20.1. Методы группового кодирования
633
ство повторяющихся символов, чтобы применение даже такого простого метода,
как групповое кодирование, было оправдано.
Таблица 20.2. Эффективность метода группового кодирования (по [113])
Число серий повторяющихся символов Средняя длина повторяющихся символов Коэффициент сжатия
10 4 1.010
10 5 1,020
10 6 1,031
10 7 1,042
10 8 1,053
10 9 1,064
10 10 1,075
20 4 1,020
20 5 1,042
20 6 1,064
20 7 1,087
20 8 1,111
20 9 1,136
20 10 1,163
30 4 1,031
30 5 1,064
30 6 1,099
30 7 1,136
30 8 1,176
30 9 1,220
30 10 1,266
40 4 1,042
40 5 1,087
40 6 1,136
40 7 1,190
40 8 1,250
40 9 1,316
40 10 1,384
50 4 1,053
50 5 1,111
50 6 1,176
50 7 1,250
50 8 1,333
50 9 1,429
50 10 1,538
634
Глава 20. Сжатие без потерь
Групповое кодирование было одним из первых методов сжатия факсимильных
сообщений, но теперь оно более не используется для этой цели. Однако этот ме-
тод следует изучить, так как он применяется в более сложных методах сжатия
изображений. При использовании метода группового кодирования для изображе-
ний вместо отсканированной и оцифрованной линии передаются длины серий
белых и черных элементов изображения. На рис. 20.2 показан пример применения
метода группового кодирования к простому изображению размером 10 х 10 точек.
Это может быть факсимильное изображение или отсканированное растровое компь-
ютерное изображение. Изображение формата 10 х 10 легко преобразуется в 100-би-
товый код. В данном примере каждый пиксел представляется одним битом, обозна-
чающим белый или черный цвет. Код длин серий состоит из длин чередующихся
черных и белых последовательностей. Поскольку при таком кодировании изоб-
ражения черный и белый цвета всегда чередуются, нет необходимости в ис-
пользовании специального символа, указывающего цвет серии. Таким образом, ко-
дированный поток данных представляет собой строку чисел, обозначающих длины
чередующихся серий черных и белых точек. Обратите внимание на то, что в данном
простом примере кодированные данные занимают больше места, чем исходные.
Однако в случае применения данного метода к типичной странице текста этот
метод будет сжимать данные. Тем не менее, это далеко не самый эффективный спо-
соб сжатия изображений.
или
23 46121649164 23
Длина равна 15 символов, или 120 бит
Простое групповое кодирование
Рис. 20.2. Пример группового кодирования
20.2. Факсимильное сжатие
635
20.2. Факсимильное сжатие
Методы сжатия данных очень важны для широкого применения цифровых фак-
симильных аппаратов. Для примера рассмотрим типичную страницу, отскани-
рованную с разрешением в 200 пелов1 (белых или черных точек) на дюйм (что
является приемлемой, но не высокой степенью разрешения). В результате такая
страница содержит 3 740 000 бит (8,5 дюймов х 11 дюймов х 40 000 пелов па квад-
ратный дюйм). При базовой скорости службы ISDN в 64 Кбит/с передача такой
страницы займет около одной минуты. Обычно пользователи ожидают от систем
работы со скоростью, близкой к скорости копирования, то есть несколько секунд
на страницу. Для удовлетворения данного требования, если не прибегать к уве-
личению скорости передачи данных в линии, необходимо использовать метод
сжатия данных.
Сектор ITU-T стандартизировал два метода сжатия данных без потерь для фак-
симильной связи: модифицированный код Хаффмана и модифицированный код
READ (Relative Element Address Designate — относительное назначение адресов
элементов). Модифицированный код Хаффмана используется по умолчанию в
факсимильной аппаратуре группы З2, в которой модифицированный код READ
может применяться факультативно. В аппаратуре группы 43 применяется моди-
фицированный код READ. Кратко эти два стандарта (группы 3 и 4) характеризу-
ются следующим образом:
♦ Группа 3. Первый цифровой факсимильный стандарт. Эта система обеспе-
чивает только кодирование черных и белых значений с плотностью скани-
рования в 200 точек на дюйм по горизонтали и от 100 до 200 по вертикали.
В аппаратуре группы 3 используются цифровая схема кодирования, а также
средства уменьшения избыточной информации в сигнале документа перед
модуляцией. Предполагается, что передача сигнала осуществляется через
модем по аналоговой телефонной линии. Передача данных ускоряется в три
и более раз по сравнению с группой 2.
Группа 4. Также представляет собой черно-белый цифровой факсимильный
стандарт. Эта группа предназначена для использования в цифровых сетях
со скоростями до 64 Кбит/с при условии безошибочного приема. Стандар-
тизированы разрешения от 200 до 400 точек на дюйм. Как и в группе 3,
для снижения количества передаваемых битов применяются методы сжа-
тия. В аппаратуре группы 4 время передачи одной страницы сокращено
до нескольких секунд по сравнению с несколькими минутами в предыду-
щих стандартах.
1 Пел — элемент изображения (picture element, pel), представляет собой минимальный дискретный эле-
мент отсканированной строки факсимильной системы, содержащий только черно-белую информа-
цию (без уровней серого). Пикселом (pixel) называют элемент изображения, содержащий более де-
тальную информацию об уровне яркости.
2 Standardization for Group 3 Facsimile Apparatus for Document Transmission. Recommendation T.4, 1988.
3 Facsimile Coding Schemes and Coding Control Functions for Group 4 Apparatus for Document Transmission.
Recommendation T.6, 1988.
636
Глава 20. Сжатие без потерь
Модифицированный код Хаффмана
В типичном документе черные и белые области имеют тенденцию к объединению.
Если рассматривать документ как последовательность линий и обратить внима-
ние на расположение участков белого и черного в линии, можно обнаружить длин-
ные серии белых и черных точек. Благодаря этому свойству можно предположить,
что сжатие на основе метода группового кодирования даст хороший результат.
Состоящие из двух значений входные данные преобразуются в длины серий, кото-
рые затем кодируются для передачи. Кроме того, поскольку в общем случае длин-
ные серии черных или белых точек менее вероятны, чем короткие, можно восполь-
зоваться преимуществом кодирования последовательностей переменной длины.
Для кодирования факсимильных документов может применяться код Хаффма-
на, описанный в главе 19. Этот метод можно применить к изображению построч-
но, кодируя последовательности черных и белых точек. Например, предположим,
что при сканировании отдельной строки получается следующая последователь-
ность черных и белых точек: W7, В7, W4, В8, W4, В7, W10 (здесь W означает бе-
лый, а В — черный). Если рассматривать каждый из этих элементов как символ
алфавита источника, тогда для кодирования этих данных может быть использо-
ван метод кодирования Хаффмана. Однако поскольку стандарт ITU-T требует по
меньшей мере 1728 точек на линию, количество различных кодов, а следовательно,
и средняя длина кода будет очень большой.
Альтернативой является модифицированный метод кодирования Хаффмана.
В этом методе длина серии ЛГ рассматривается как сумма двух слагаемых:
N = 64/и + п\ т = 0, 1, 2,..., 27; п = 0, 1, 2,..., 63.
То есть длина каждой серии черных или белых точек считается величиной,
кратной 64 с остатком.
Теперь каждая длина серии может быть представлена двумя значениями, од-
ним для т и другим для п, и эти значения могут кодироваться при помощи метода
Хаффмана. Например, строка из 200 черных точек подряд может быть выражена
как 64-3 + 8. Для этого сектором ITU-T были определены восемь образцов доку-
ментов и рассчитаны вероятности нахождения в документах серий различных
длин. Поскольку для серий из черных и белых точек эти вероятности различают-
ся, были сосчитаны два множества вероятностей. На основе полученной инфор-
мации были составлены две таблицы (табл. 20.3). Длина серии делится на 64, пос-
ле чего частное и остаток от деления кодируются двумя кодовыми словами. Если
длина серии меньше 64 (частное от деления равно нулю), то такая длина серии
кодируется только кодовым словом остатка. Серии длиной более 64 точек кодиру-
ются двумя кодами: кодом остатка (и) и кодом кратности (/и). Имеется еще несколь-
ко деталей, касающихся этого кода. Каждая строка заканчивается уникальным
кодовым словом EOL (End Of Line — конец строки). Это кодовое слово, никогда
не встречающееся в строках данных, обеспечивает восстановление синхронизации
в случае ошибок. Внутри строки должны чередоваться кодовые слова для белых и
черных серий. Обратите внимание на то, что для белых и черных серий используют-
ся различные кодовые слова. Это обеспечивает дополнительную защиту от ошибок.
Наконец, по соглашению каждая строка начинается с белой серии. Если первая
точка в линии черная, то используется белая серия нулевой длины.
20.2. Факсимильное сжатие
637
Таблица 20.3. Модифицированные коды Хаффмана
Длина серии Белая серия Черная серия
Кодовые слова остатка
0 00110101 0000110111
1 000111 010
2 0111 11
3 1000 10
4 1011 011
5 1100 0011
6 1110 0010
7 1111 00011
8 10011 000101
9 10100 000100
10 00111 0000100
11 01000 0000101
12 001000 0000111
13 000011 00000100
14 110100 00000111
15 110101 000011000
16 101010 0000010111
17 101011 0000011000
18 0100111 0000001000
19 0001100 00001100111
20 0001000 00001101000
21 0010111 00001101100
22 0000011 00000110111
23 0000100 00000101000
24 0101000 00000010111
25 0101011 00000011000
26 0010011 000011001010
27 0100100 000011001011
28 0011000 000011001100
29 00000010 000011001101
30 00000011 000001101000
31 00011010 000001101001
32 00011011 000001101010
33 00010010 000001101011
34 00010011 000011010010
35 00010100 000011010011
36 00010101 000011010100
37 00010110 000011010101
38 00010111 000011010110
39 00101000 000011010111
продолжение^
638 Глава 20. Сжатие без потерь
Таблица 20.3 (продолжение}
Длина серии Белая серия Черная серия
40 00101001 000001101100
41 00101010 000001101101
42 00101011 000011011010
43 00101100 000011011011
44 00101101 000001010100
45 00000100 000001010101
46 00000101 000001010110
47 00001010 000001010111
48 00001011 000001100100
49 01010010 000001100101
50 01010011 000001010010
51 01010100 000001010011
52 01010101 000000100100
53 00100100 000000110111
54 00100101 000000111000
55 01011000 000000100111
56 01011001 000000101000
57 01011010 000001011000
58 01011011 000001011001
59 01001010 000000101011
60 01001011 000000101100
61 00110010 000001011010
62 00110011 000001100110
63 00110100 000001100111
Кодовые слова кратности 64
64 11011 0000001111
128 10010 000011001000
192 010111 000011001001
256 0110111 000001011011
320 00110110 000000110011
384 00110111 000000110100
448 01100100 000000110101
512 01100101 0000001101100
576 01101000 0000001101101
640 01100111 0000001001010
704 011001100 0000001001011
768 011001101 0000001001100
832 011010010 0000001001101
896 011010011 0000001110010
960 011010100 0000001110011
1024 011010101 0000001110100
20.2. Факсимильное сжатие
639
Длина серии Белая серия Черная серия
1088 011010110 0000001110101
1152 011010111 0000001110110
1216 011011000 0000001110111
1280 011011001 0000001010010
1344 011011010 0000001010011
1408 011011011 0000001010100
1472 010011000 0000001010101
1536 010011001 0000001011010
1600 010011010 0000001011011
1664 011000 0000001100100
1728 010011011 0000001100101
EOL 000000000001 000000000001
Модифицированный код READ
Использование модифицированного кода Хаффмана значительно сокращает
количество передаваемых битов по сравнению с передачей несжатого растрового
изображения. Дополнительного увеличения производительности можно добить-
ся, зная о корреляции между последовательностями черно-белых серий точек в
двух соседних линиях. В самом деле, в типичных документах, передаваемых по
факсу, приблизительно 50 % черно-белых и бело-черных переходов находятся точ-
но под соответствующими переходами в предыдущей строке, а еще 25 % отли-
чаются всего на одну точку [207]. Поэтому примерно 75 % всех переходов можно
с большой эффективностью определить относительно предыдущей строки. Эти
соображения и послужили основой для создания модифицированного кода READ
(Modified READ, MR).
В схеме MR длины серий кодируются в соответствии с расположением так на-
зываемых переключающих элементов. Переключающий элемент (changing element)
определяется как точка цвета, отличного от цвета предыдущей точки той же самой
линии. Переключающий элемент а, кодируется расстоянием от одной из двух
опорных точек: либо от предыдущего переключающего элемента ао в той же ли-
нии, либо от переключающего элемента bi в предыдущей линии. Выбор переклю-
чающего элемента а0 или bt зависит от конкретной конфигурации, о чем будет по-
дробнее сказано далее.
На рис. 20.3 показаны пять переключающих элементов, определенные для этой
схемы следующим образом:
♦ ао — опорный, или стартовый, переключающий элемент кодируемой линии,
который в начале кодируемой линии устанавливается на воображаемый бе-
лый переключающий элемент, располагающийся левее первого элемента
линии, а в процессе кодирования линии переопределяется после каждого
шага кодирования;
а( — следующий переключающий элемент справа от элемента а0 в кодируе-
мой линии;
640
Глава 20. Сжатие без потерь
♦ а2 — следующий переключающий элемент справа от элемента at в кодируе-
мой линии;
♦ bt — первый расположенный на опорной линии правее элемента а0 переклю-
чающий элемент, цвет которого противоположен цвету ао;
♦ Ь2 — следующий переключающий элемент вправо от Ь, на опорной линии.
Вертикальный режим
Горизонтальный режим
Вертикальный и горизонтальный режимы
Опорная линия
Кодируемая линия
Режим пропуска
Рис. 20.3. Переключающие элементы изображения в схеме МВ
Процедура кодирования, которую иллюстрирует табл. 20.4, выглядит следую-
щим образом:
1. На первом шаге выбирается один из двух возможных вариантов действий:
+ Если переключающий элемент Ь2 расположен левее переключающего
элемента at, это кодируется словом 0001. После кодирования позиция ai
сдвигается так, чтобы переключающий элемент а! располагался под Ь2.
Это называется режимом пропуска. Затем повторяется шаг 1.
♦ Если предыдущее условие не выполняется, переходим к шагу 2.
2. На втором шаге тоже выбирается один из двух возможных вариантов действий:
♦ Если позиция переключающего элемента at находится в пределах трех
точек от позиции переключающего элемента bi (|atbi| < 3), тогда at коди-
руется вертикально, после чего старая позиция at становится новой по-
зицией ао, а2 становится at и т. д.
♦ Если позиция переключающего элемента at не находится в пределах трех
точек от позиции переключающего элемента Ьь тогда at кодируется го-
ризонтально. Следом за кодом горизонтального режима 001 aoat и ata2
кодируются при помощи одномерного модифицированного кодирования
Хаффмана. Затем старая позиция а2 становится новой позицией аи.
20.2. Факсимильное сжатие
641
Таблица 20.4. Кодовая таблица схемы MR
Режим Кодируемые элементы Нотация Кодовое слово
Пропуск Ь,Ьг P 0001
Горизонтальный аоаъ атаг H 001 + M(aoat) + M(aia2)
Вертикальный ai точно под bi a-jbi — 0 V(0) 1
ai правее bi aibi = 1 VR(1) 011
aib] = 2 VB(2) 000011
a!bi = 3 VR(3) 0000011
ai левее bt aibi = 1 VL(1) 010
aib, = 2 Vl(2) 000010
aibi = 3 Vl(3) 0000010
Шаг 1 используется для перемещения позиций переключающих элементов bt
и Ь2 после выполнения шага 2. Кроме того, шаг 1 позволяет избежать больших дайн
серий. На шаге 2, если текущий кодируемый переключающий элемент оказывает-
ся в пределах трех позиций от такого же перехода в предыдущей линии, тогда его
позиция кодируется одним из семи возможных значений при помощи модифици-
рованного кодирования Хаффмана. Эта ситуация сохраняется большую часть вре-
мени. В редких случаях, когда переход в текущей линии не находится в пределах
трех позиций от такого же перехода в предыдущей линии, следующие две серии
кодируются при помощи модифицированного кодирования Хаффмана.
Схема MR в большей степени чувствительна к ошибкам, чем схема модифици-
рованного кодирования Хаффмана. Результат ошибки может распространяться на
непредсказуемые расстояния. Чтобы избежать этого, для каждой К-и линии при-
меняется модифицированная схема кодирования Хаффмана. Сектор ITU-T реко-
мендует значение К =2 для разрешения 3,85 линии на миллиметр и К = 4 для раз-
решения 7,7 линии на миллиметр.
Дважды модифицированный код READ
Дважды модифицированный алгоритм READ (Modified Modified READ, MMR)
определен для аппаратуры факсимильной связи группы 4 в рекомендации Т.6 сек-
тора ITU-T. Он отличается от модифицированного алгоритма READ (MR) тем,
что из него была удалена проверка ошибок, что позволило увеличить степень
сжатия алгоритма. Поскольку аппаратура группы 4 предназначена для работы на
высококачественных линиях с низкой вероятностью ошибок, такой компромисс
кажется разумным.
Таблица 20.5 иллюстрирует эффективность работы модифицированной схемы
кодирования Хаффмана и обеих модифицированных схем READ с одним и тем
же набором страниц в качестве образца. Об этих результатах сообщалось в [14].
Сходные результаты приводятся в [183] и [243]. Результаты работы этих схем ко-
дирования также сравниваются со стандартом кодирования JBIG (Joint Bi-Level
Image experts Group — объединенная группа экспертов по двухуровневой обработке
изображений), определенным в рекомендациях Т.821. Это стандарт для бинарных
Progressive Bi-Level Image Compression. Recommendation T.82,1993.
642
Глава 20. Сжатие без потерь
изображений описывает алгоритмы сжатия с потерями и без с использованием
арифметического кодирования.
Таблица 20.5. Сравнение методов факсимильного сжатия
Разрешение изображения, пелов на дюйм, или тип текста Размер изображения, пелы МН MR MMR JBIG
Коэффициенты сжатия для изображений с различными степенями разрешения
12,5 272х192 2,34 2,32 3,43 6,69
25 544 х 384 3,56 3,94 5,68 10,07
50 1088x768 6,06 7,26 10,34 15,93
100 2176x1536 11,30 14,60 22,52 31,03
200 4352 х 3072 20,28 29,24 48,97 62,52
400 8704x6144 29,72 51,30 95,96 122,38
Коэффициенты сжатия для различных плотностей текста
Письмо 4352 х 3072 20,28 29,24 48,97 62,52
Разреженный текст 4352 х 3072 15,97 25,05 41,96 54,29
Плотный текст 4352 х 3072 3,08 3,95 4,54 5,91
В верхней части таблицы сравниваются алгоритмы сжатия изображений с раз-
личным разрешением. Можно сделать три замечания. Во-первых, все методы по-
зволяют достичь значительной степени сжатия. Во-вторых, схема MR оказывает-
ся лучше модифицированной схемы Хаффмана, а схема MMR позволяет достичь
еще большей степени сжатия, чем схема MR. В-третьих, чем выше разрешение
изображения (и следовательно, на нем больше деталей), тем выше эффект от при-
менения сжатия. То есть коэффициент сжатия изображений с высоким разрешением
выше. В логарифмическом масштабе все алгоритмы демонстрируют примерно ли-
нейный рост коэффициента сжатия при увеличении пространственного разрешения.
В нижней части таблицы сравниваются алгоритмы сжатия, применяемые к трем
стандартизированным документам, определенным сектором ITU-T. Эти докумен-
ты расположены по возрастанию плотности черных точек на странице. Здесь так-
же относительная производительность схемы MR оказывается выше производи-
тельности модифицированной схемы Хаффмана, а схема MMR позволяет достичь
большей степени сжатия, чем схема MR. Обратите также внимание на то, что чем
выше плотность черных точек на странице, тем ниже коэффициент сжатия. Чтобы
объяснить причину этого явления, вспомним, что энтропия потока данных выше
при несбалансированных вероятностях. При увеличении плотности текста мы
сталкиваемся с ситуацией, в которой близки значения вероятностей появления
белых и черных последовательностей точек.
20.3. Арифметическое кодирование
Метод кодирования Хаффмана хотя и является простым в реализации и относитель-
но эффективным, тем не менее, не позволяет достичь максимального коэффици-
ента сжатия, если только все вероятности не представляют собой отрицательных
20.3. Арифметическое кодирование
643
степеней числа 2. Арифметическое кодирование предназначено для достижения
более высоких коэффициентов сжатия за счет усложнения вычислений. При этом
изображение обрабатывается таким образом, чтобы вероятности приближались
к отрицательным степеням числа 2. Арифметическое кодирование используется
в стандартах JPEG и MPEG, описываемых в главе 21.
Мы начнем с концепции, лежащей в основе арифметического кодирования,
а затем рассмотрим некоторые детали.
Основная концепция
Вспомним из обсуждения метода кодирования Хаффмана, что если отдельные ко-
дируемые символы встречаются в исходном тексте с вероятностью Р„ то в лучшем
случае мы можем использовать для каждого символа код длины £„ удовлетворяю-
щей следующему неравенству:
log(l/P,)<£,<log(l/P,) +1.
Здесь Pi представляет собой вероятность, с которой г-й символ встречается в
исходных данных, а £, — длину двоичного кода, которым кодируется данный сим-
вол. Исходя из данного неравенства, можно показать, что
Н(Х) < Е[£] < Н(Х) + 1.
Здесь Н(Х) представляет собой энтропию множества символов X, а Е[£] явля-
ется средней длиной кода для множества X. В схеме сжатия без потерь Н(Х) все-
гда будет нижней границей объема сжатых данных, так как Н(Х) определяет сред-
нее количество информации, содержащейся в символьном наборе.
Наконец, было показано, что эффективность алгоритма сжатия может быть
повышена путем объединения символов и одновременного кодирования блоков
по К символов каждый. В результате мы получаем следующее неравенство:
Н(Х)<Щ<Н(Х)+А.
Л Л
Таким образом, существует способ повышения эффективности алгоритма сжа-
тия. Если нам нужно отправить сообщение длиной в N символов, мы можем ис-
пользовать блок длиной N. Таким образом, мы обращаемся с каждым сообщением
как с одним из М* возможных результатов, где М представляет собой количество
атомарных символов, a N — длину сообщения. В качестве примера рассмотрим слу-
чай, обсуждавшийся в главе 19, в котором имеются два символа, А и В, встречаю-
щиеся в исходном тексте с вероятностями 0,8 и 0,2. Если мы передаем сообщение
длиной в 3 символа (Л£ = 2, N= 3), тогда существуют 23 = 8 возможных результа-
тов. Если появление в потоке данных каждого символа не зависит от предыдущих
символов, тогда мы можем написать вероятности всех 8 результатов:
Вала = 0,512, Рваа = 0,128,
РААВ = 0,128, Рвав = 0,032,
Baba = 0,128, Рвва = 0,032,
Babb = 0,032, Рввв = 0,008.
644 Глава 20. Сжатие без потерь
Один из возможных методов состоит в применении кода Хаффмана (см. рис. 19.3
в главе 19). Для сообщения с восемью возможными результатами это разумно, но!
при очень длинных сообщениях использование этого метода приведет к большим
вычислительным затратам.
Метод арифметического кодирования предоставляет остроумную альтернати-
ву. Заметим, что сумма вероятностей всех возможных сообщений должна быть
равна 1,0. Таким образом, можно разложить все результаты на интервале [0, 1] в
виде отрезков, длины которых равны их вероятностям (рис. 20.4). На рисунке так-
же показан простой метод генерирования интервалов по одному символу. Эта про-
цедура выглядит следующим образом:
1. Алгоритм начинается с позиции первого символа в сообщении, а интервал
делится в соответствии с вероятностями отдельных символов. В данном слу-
чае имеется два символа, А и В, встречающиеся в исходном тексте с вероят-
ностями 0,8 и 0,2. Поэтому интервал [0, 1] разбивается на подынтервалы
[0,0,8) и [0,8,1). Граница между интервалами может быть отнесена произ-
вольно к любому из интервалов.
2. Каждый подынтервал разбивается тем же способом, который применялся
на шаге 1. То есть каждый подынтервал дробится на доли в соотношении 4:1.
3. Этот процесс повторяется для Nсимвольных позиций (сообщение длины N).
Рис. 20.4. Расположение символов на единичном интервале
Теперь результату каждого сообщения поставлен в соответствие интервал, про-
порциональный вероятности сообщения. Таким образом, каждый результат может
быть представлен двоичным дробным числом, равным некоторой точке на интер-
20.3. Арифметическое кодирование
645
вале. Будем использовать для этого нижнюю границу каждого интервала. Резуль-
таты такой операции показаны в пятой колонке табл. 20.6, при этом используются
пять значащих цифр правее двоичной запятой. Такой точности достаточно для
однозначной идентификации каждого интервала, а следовательно, и каждого ре-
зультата. Поэтому мы можем использовать дробную часть каждого значения в ка-
честве кода для соответствующего результата (например, ЛВА= 10100). Однако
полученные коды можно усовершенствовать. Например, можно удалить из кода
некоторые цифры, если только это не приведет к неразличимости кодов (то есть
ни один код не должен совпадать с начальными цифрами другого кода). Результат
этой операции показан в шестой колонке таблицы. Обратите внимание на то, что
в общем случае более короткие интервалы идентифицируются большим числом
битов. В этом есть смысл: нижняя граница короткого интервала близка к нижней
границе следующего интервала. Поэтому двоичные дроби для этих двух границ
будут совпадать в нескольких разрядах. Чем меньше интервал, тем больше одина-
ковых разрядов в соответствующих дробях.
Таблица 20.6. Интервалы вероятности для трехсимвольных последовательностей
Последо- вательность Р, Кумулятивная вероятность Интервал Двоичное представление нижней границы* Код РЛ, P,i°g (1/Р)
ААА 0,512 0,512 [0, 0,512] 0,00000 0 0,512 0,494
ААВ 0,128 0,64 [0,512, 0,64] 0,10000 100 0,384 0,38
АВА 0,128 0,768 [0,64, 0,768] 0,10100 101 0,384 0,38
АВ В 0,032 0,8 [0,768, 0,8] 0,11000 11000 0,16 0,159
ВАА 0,128 0,928 [0,8, 0,928] 0,11001 11001 0,64 0,38
ВАВ 0,032 0,96 [0,928, 0,96] 0,11101 111 0,096 0,159
ВВА 0,032 0,992 [0,96, 0,992] 0,11110 11110 0,096 0,159
ВВВ 0,008 1,0 [0,992, 1,0] 0,11111 11111 0,04 0,056
2,408 2,167
* До 5 значащих цифр.
Таким образом, мы разработали новый метод назначения кодов сообщениям.
В последних двух колонках табл. 20.5 средняя длина нового кода сравнивается
с энтропией множества сообщений (сравните также с табл. 19.1 в главе 19).
Несмотря на всю свою внешнюю привлекательность новый метод обладает дву-
мя существенными недостатками:
4- Если все возможные интервалы вычислять заранее, то объем необходи-
мых вычислений будет огромен. Например, если длина сообщения равна
1000 символов и используется алфавит из 128 символов (например, набор
символов ASCII), тогда число всех возможных сообщений будет составлять
128,0<ш = 102107.
♦ Описанная схема применима только к сообщениям фиксированной длины.
Метод арифметического кодирования позволяет устранить оба недостатка.
646
Глава 20. Сжатие без потерь
Чистое арифметическое кодирование
Мы начнем с простейшей формы алгоритма арифметического кодирования. Хотя
этот алгоритм преодолевает упомянутые ранее недостатки, в нем сохраняются не-
которые вычислительные сложности. Тем не менее, проще понять метод арифме-
тического кодирования, рассмотрев сначала более простую форму.
При арифметическом кодировании нет необходимости заранее генерировать
интервалы для всех возможных сообщений. Вместо этого интервалы для отдель-
ного сообщения вычисляются посимвольно. Таким образом, для передачи одного
сообщения вычисляется только один интервал. Кроме того, поскольку процесс
является посимвольным, нет необходимости фиксировать длину сообщения заранее.
Вычисления продолжаются до тех пор, пока не будет достигнут конец сообщения.
Базовый алгоритм
Каждый шаг алгоритма начинается с полуоткрытого интервала [£, Н), вначале
инициализируемого как [0, 1):
1. Текущий интервал разбивается на подынтервалы по одному для каждого
возможного символа. Каждый подынтервал пропорционален вероятности,
с которой соответствующий символ встречается в тексте.
2. Выбирается подынтервал, соответствующий текущему символу. Этот по-
дынтервал становится текущим интервалом.
3. Если обработано все сообщение, выполняется следующий шаг, если нет, воз-
вращаемся к шагу 1.
4. Выводится количество битов, достаточное для того, чтобы можно было от-
личить данный интервал от двух соседних интервалов.
5. Выводится некий специальный код конца сообщения, чтобы уведомить по-
лучателя.
На первом шаге нет необходимости вычислять все подынтервалы. Вместо это-
го вычисляются только подынтервал, соответствующий текущему символу. Крат-
ко эта операция описана далее. Введем следующие обозначения:
♦ X — набор символов (xi, Хг,..., Хм);
♦ Х(£) — символ, встретившийся на k-ii итерации, то есть k-ii символ сооб-
щения;
♦ /(/г) — значение индекса X(k), например, если X(k) = хз, тогда I(k) = 3;
♦ М — количество возможных символов;
♦ Px(i) = Рг[Х = г] = Pi — функция плотности вероятности для X;
+ Fx (О - У, Pj ~ кумулятивная функция распределения вероятностей для X;
♦ £* — нижняя граница подынтервала после k-ii итерации алгоритма;
♦ Я* — верхняя граница подынтервала после k-й итерации алгоритма;
W* = ££ - Ц — ширина подынтервала после k-ii итерации алгоритма.
20.3. Арифметическое кодирование
647
При этом каждая итерация алгоритма включает следующие вычисления:
Lk = Lk-i + Fx (7(&) - l)W*-i,
Hk — Lk-i + Fx (/(£)) W*-i>
I Wk=Нк - Ц=Pr [X=Х(Л)]Wk ,.
Ширина конечного подынтервала равна произведению вероятностей каждого
встретившегося за время работы алгоритма символа и поэтому представляет со-
: бой вероятность того, что данное сообщение т встретится в MN возможных сооб-
щениях. Это можно выразить так:
Рг(щ)= ПРг[Х = Х(ед.
*=i
Можно показать, что для уникальной идентификации интервала сообщения т
требуется, самое большее, 2 + log( 1/Рг(иг)) бит. Чтобы продемонстрировать это на
интуитивно понятном уровне, рассмотрим два первых интервала с соответствую-
щими длинами Рг(1) и Рг(2), то есть интервалы [0, Рг(1)) и [Pr( 1), Рг(1) + Рг(2)).
Теперь предположим, что для определения интервала мы используем его нижнюю
границу. При этом двоичная дробь, представляющая Рг(1), будет кодом для
второго интервала. Существует некоторое число j, такое, что 2 ' будет наименьшей
величиной, удовлетворяющей неравенству 2 J> Рг(1). Это число представляет
собой двоичную дробь, начинающуюся с (log(l/Pr(/??)) - 1) бит, за которыми сле-
дует 1. При использовании этого значения в качестве кода для второго интервала
гарантируется, что этот код уникально идентифицируется по отношению к пер-
вому интервалу.
Обратите внимание на то, что в данной формулировке не делается предполо-
жений о стационарности или независимости переходов.
Пример
Этот пример взят из [115]. Пусть имеются два символа, а и Ь, вероятности кото-
рых зависят от положения в трехсимвольном сообщении:
Pr(a1) = 2/3, Pr(bt) = l/3,
Рг(а2)=1/2, Рг(Ь2)=1/2,
Рг(а3) = 3/5, Рг(Ьз) = 2/5.
Здесь Рг(а,) представляет собой вероятность того, что символ а встретится
в г-й позиции сообщения. В данном случае кодируется сообщение «ЬаЬ».
На рис. 20.5 показано арифметическое кодирование этого сообщения. Данному
сообщению соответствует конечный интервал [23/30,5/6) = [0,766,0,833). В двоич-
ном виде конечный интервал выглядит следующим образом: [0,110001..., 0,110101...).
Обратите внимание на то, что все числа, начинающиеся с 0,110001, целиком по-
падают в интервал, но существуют некоторые числа, начинающиеся с 0,1100, не
попадающие в этот интервал (например, 0,1100001 < 23/30). Поэтому кода 11001
достаточно, чтобы однозначно идентифицировать интервал и, следовательно,
однозначно идентифицировать сообщение. В общем случае, чем меньше конечный
648
Глава 20. Сжатие без потерь
интервал (соответствующий менее вероятному сообщению), тем больше битов
кода требуется для уникальной идентификации интервала.
Декодирование
Процесс декодирования выполняется по той же общей поэтапной схеме. На этот
раз обнаруживаются последовательные подынтервалы, приводящие к конечному
интервалу и открытию соответствующих сообщений.
Общие правила выглядят следующим образом. Опять же, начнем с интервала [0,1):
1. Разделим текущий интервал на подынтервалы, по одному для каждого сим-
вола. Длина каждого подынтервала пропорциональна вероятности появле-
ния соответствующего символа.
2. Выберем подынтервал, содержащий код, выраженный в виде двоичной дро-
би. Выведем символ, определяющий этот код.
Эти два шага повторяются до тех пор, пока не будет распаковано все сообще-
ние. Существует несколько способов определить, что сообщение распаковано пол-
ностью. К исходному сообщению может быть добавлен символ конца сообщения.
В этом случае процесс декодирования остановится при обнаружении этого симво-
ла. Другой способ состоит в том, чтобы при декодировании на каждом шаге прове-
рять, все ли двоичные дроби, начинающиеся с кода, попадают в один интервал,
и прекратить декодирование, когда это условие перестанет выполняться.
Процесс декодирования, как и процесс кодирования, иллюстрирует рис. 20.5.
Численное значение конечного кода (0,78125 = 0,110012) обозначается кружком на
каждой линии процесса.
20.3. Арифметическое кодирование
649
Инкрементное арифметическое кодирование
У только что описанного алгоритма чистого арифметического кодирования есть
два недостатка. Во-первых, уменьшающиеся размеры текущего интервала требу-
ют все более точных вычислений. Во-вторых, код не может быть послан, пока не
обработано все сообщение.
Метод инкрементного арифметического кодирования позволяет решить обе про-
блемы. При использовании этой техники перед выполнением каждого следующего
шага алгоритма текущий интервал всегда увеличивается, а кодовые биты генери-
руются на каждом шаге и могут передаваться или сохраняться после каждого шага.
Описание алгоритма
Каждый шаг алгоритма начинается с полуоткрытого интервала [£, 77), который
инициализируется значением [0,1). Кроме того, используется счетчик следования
(follow counter), инициализируемый значением 0:
1. Текущий интервал разбивается на подынтервалы по одному для каждого
возможного символа. Длина каждого подынтервала пропорциональна веро-
ятности появления соответствующего символа.
2. Выбирается подынтервал, соответствующий текущему' символу.
3. Следующие шаги выполняются в цикле до тех пор, пока не выполнится
условие выхода из цикла:
♦ Если новый подынтервал не попадает целиком в один из следующих ин-
тервалов: [0, 0,5), [0,25,0,75) или [0,5,1), — выйти из цикла.
♦ Если новый подынтервал попадает в интервал [0,0,5), вывести бит 0, пос-
ле которого ноль или более битов 1, соответствующих значению счетчи-
ка следования, после чего значение счетчика следования установить на
ноль. Удвоить размер подынтервала, линейно расширив [0, 0,5) до [0, 1).
То есть установить L = 2£ и Н= 2Н.
♦ Если новый подынтервал попадает в интервал [0,5, 1,0), вывести бит 1,
после которого ноль или более битов 0, соответствующих значению счет-
чика следования, после чего значение счетчика следования установить
на ноль. Удвоить размер подынтервала, линейно расширив [0,5,1) до [0,1).
То есть установить L = 2(£ - 0,5) и Н= 2(Н - 0,5).
♦ Если новый подынтервал попадает в интервал [0,25 0,75), увеличить на
единицу значение счетчика следования. Удвоить размер подынтервала,
линейно расширив [0,25,0,75) до [0, 1). То есть установить £ = 2(£ - 0,25)
и Н= 2(Н - 0,25).
Шаги с 1 по 3 повторяются до тех пор, пока не будет обработано все сообщение.
Вот что, по сути, выполняет данный алгоритм. Если новый подынтервал цели-
ком попадает в интервал [0,0,5) или [0,5,1,0), алгоритм формирует ведущий бит,
указывающий, в какую половину интервала попадает новый подынтервал, после
чего интервал удваивается, так что новый интервал отражает только неизвестную
часть конечного интервала. Посмотрим, как это работает. Предположим, что на
первом шаге формируется подынтервал в верхней половине единичного интервала
650
Глава 20. Сжатие без потерь
(см., например, рис. 20.5). Таким образом мы узнаем, что конечный подынтервал
также должен находиться в верхней половине единичного интервала, и поэтому
старший бит конечного кода должен быть равен 1. Когда этот бит становится извест-
ным, вторую половину единичного интервала можно проигнорировать, а подын-
тервал удвоить для определения следующего бита кода.
Если конечные точки текущего интервала близки к точке 0,5, но находятся по
разные стороны от этой точки, тогда расположение следующего результата еще не
определено. Однако каким бы он ни был, следующий бит будет иметь противопо-
ложное значение. Читатель может сам поэкспериментировать с несколькими зна-
чениями, чтобы убедиться, что это так. Поэтому алгоритм следит за следующим
битом и симметрично расширяет интервал вокруг значения 0,5.
Пример
На рис. 20.6 показан процесс кодирования, в котором используется то же самое
сообщение «ЬаЬ», что и прежде. В данном примере интервал расширяется один раз
для каждого входного символа. Это не обязательно так. Может быть ноль, одно
или несколько удвоений на символ. Когда последний символ обработан, резуль-
тат представляет собой 110. К этому моменту конечный интервал равен [2/15,2/3).
Поскольку все двоичные числа в этом интервале начинаются с 0,01, для однознач-
ной идентификации этого диапазона достаточно кода 01. Таким образом, мы по-
лучаем тот же код, что и в предыдущем методе (см. рис. 20.5). Так будет всегда,
потому что используются, по сути, те же самые вычисления.
20.4. Алгоритмы совпадения строк
Такие алгоритмы, как метод Хаффмана и арифметическое кодирование, основаны
на знании оценки статистики сжимаемых данных. Эти алгоритмы не адаптируются
к изменениям в представлении данных. Кроме того, ограничения памяти ставят
предел их способности фиксировать взаимосвязи высокого порядка между слова-
ми и фразами текста. Другой подход, доказавший свою эффективность, использу-
ется в семействе методов, известных под названием алгоритмов совпадения строк.
В то время как в методе Хаффмана и при арифметическом кодировании вход-
ные последовательности фиксированной длины преобразуются в коды переменной
длины, алгоритмы совпадения строк преобразуют входные последовательности
переменной длины в коды фиксированной длины. Кроме того, алгоритмы совпа-
дения строк не выдвигают априорных предположений о статистике данных, а адап-
тируются к изменениям в характере входных данных по мере их обработки.
Все алгоритмы данной категории обязаны своим происхождением израильс-
ким исследователям Якову Зива (Jacob Zib) и Аврааму Лемпелю (Abraham Lempel).
В 1977 г. они описали метод, основанный па буфере скользящего окна, в котором
содержится только что обработанный текст [247]. Этот алгоритм обычно называ-
ют LZ77. Разновидность этого алгоритма используется в популярной в Интернете
схеме сжатия zip (PKZIP, gzip, zipit и т. д.). В следующем году те же авторы опи-
сали улучшенную версию этого алгоритма, основанного на структурированном
в виде дерева словаре. Этот алгоритм называется LZ78. Затем алгоритм LZ78 был
20.4. Алгоритмы совпадения строк
651
усовершенствован и назван LZW [234]. Многие программы сжатия основаны на
алгоритмах LZ78 и LZW, включая стандарт V.42Ws сектора ITU-T, предназначен-
ный для голосовых модемов1, популярный формат сжатия изображений GIF, а так-
же программу сжатия данных в операционной системе UNIX.
0,67
0
1,0
bl
а1
Выбирается b
выводится 1;
расширение
1/2
0,33
32
Выбирается а2;
счетчик следования;
расширение
3/5
1/2
0,67
0.167 0,566 ь 0,833
I-------------——--и--------------------------1
Выбирается Ь3; ;
-------- выводится 10; I
। расширение !
0.012=0,25
0,667
0.102 = 0,5
Рис. 20.6. Пример инкрементного арифметического кодирования
В алгоритмах LZ77, LZ78 и их вариантах используется тот факт, что слова и
фразы в потоке текста (элементы изображения в случае GIF) повторяются с боль-
шой вероятностью. Когда встречается повторяющаяся последовательность, она
может быть заменена коротким кодом. Программа сжатия ищет подобные повто-
ряющиеся участки текста и «на лету» формирует коды, которыми заменяет их на
выходе. Те же коды могут использоваться для обозначения новых последователь-
ностей. Алгоритм должен быть определен таким образом, чтобы программа распа-
ковки могла найти текущее соответствие между кодами и последовательностями
исходных данных.
Другой способ повышения эффективности алгоритмов совпадения строк состо-
ит в том, чтобы учитывать энтропию входных данных, рассматриваемых в виде
Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Pro-
cedures. Recommendation V.426is, 1990.
652
Глава 20. Сжатие без потерь
последовательности строк. Вспомним, что чем выше уровень агрегации входных
символов, тем ниже энтропия. Поэтому следует ожидать, что, используя совпаде-
ния строк, можно добиться высоких коэффициентов сжатия.
Алгоритм LZ77
Прежде чем перейти к изучению деталей алгоритма LZ77, рассмотрим простой
пример, основанный на примере из [232]. Пусть имеется следующая бессмыслен-
ная фраза:
the brown fox jumped over the brown foxy jumping frog
Длина этой фразы 53 байта, то есть 424 бита. Алгоритм обрабатывает этот текст
слева направо. Вначале каждый символ преобразуется в 9-битовый код, состоящий
из двоичной единицы, за которой следует 8-битовое Л5СП-представлепие символа.
Во время обработки текста алгоритм ищет повторяющиеся последовательности.
Когда встречается повторяющаяся последовательность, алгоритм ищет конец такой
последовательности, то есть каждый раз алгоритм отыскивает как можно больше
символов. Первой такой последовательностью является the brown fox. Повторяю-
щаяся последовательность заменяется указателем на первый экземпляр последо-
вательности и длиной этой последовательности. В данном случае последователь-
ность the brown fox встречается на 26 позиций раньше и имеет длину 13 символов.
Для данного примера рассмотрим два варианта кодирования: 8-битовый указатель
и 4-битовая длина или 12-битовый указатель и 6-битовая длина. При этом 2-бито-
вый заголовок указывает, который вариант выбран: 00 означает первый вариант,
а 01 — второй вариант. Таким образом, второй экземпляр последовательности the
brown fox кодируется как <00i,><26d><13d> или 00 00011010 1101.
Оставшиеся части сжатого сообщения представляют собой букву у, последова-
тельность <00b><27d><5d>, заменяющую последовательность, состоящую из про-
бела, за которым следует строка jump, и последовательность символов ing frog.
На рис. 20.7 иллюстрируется преобразование алгоритма сжатия. Сжатое со-
общение состоит из 35 9-битовых символов и двух кодов, то есть всего из 35 9 +
+ 2 • 14 = 343 бит. Таким образом, при 424 бит в несжатом сообщении коэффици-
ент сжатия данного метода в этом примере составил 1,24.
•; -? ж X ? 5 «
the brown fox jumped over the fbrown foxyjumping frog
26
l27-----------------------------—------------J
the brown fox jumped over 0b26d13d у 0b27d5aing frog
Рис. 20.7. Пример работы метода LZ77
Алгоритм сжатия
В алгоритме сжатия LZ77 и его вариантах используются два буфера. В скользя-
щем буфере предыстории хранятся А только что обработанных символов источ-
/
20.4. Алгоритмы совпадения строк
653
ника, а в упреждающем буфере содержатся следующие L символов, ожидающих
обработки (рис. 20.8, а). Алгоритм пытается найти соответствие между двумя и
более символами из начала упреждающего буфера и строкой в скользящем буфе-
ре предыстории. Если соответствие не обнаружено, первый символ упреждающе-
го буфера выводится как 9-битовый символ, а также сдвигается в скользящее окно,
при этом самый старый символ выбрасывается из скользящего окна. Если совпа-
дение обнаруживается, алгоритм продолжает искать самое длинное совпадение.
Затем строка, для которой найдено соответствие, выводится в виде триплета (инди-
катор, указатель, длина). Затем из скользящего окна выдвигаются столько символов,
сколько содержится в кодированной триплетом последовательности, и столько же
новых символов исходного текста помещаются в скользящее окно.
Удаление
символов
Сдвигаемый
исходный текст
Сжатый текст
he brown fox jumped over the brown foxy
own fox jumped over thebrown foxy jump
jumping frog
ing frog
6
Рис. 20.8. Схема LZ77
На рис. 20.8, б показана работа данной схемы с последовательностью из на-
шего примера. В иллюстрации предполагается использование 39-символьного
скользящего окна и 13-символьного упреждающего буфера. В верхней части
примера первые 40 символов были обработаны, и несжатая версия последних
39 символов находится в скользящем окне. Остальная часть сообщения нахо-
дится в упреждающем буфере. Алгоритм сжатия находит следующее совпадение,
сдвигает 5 символов из упреждающего буфера в скользящее окно и формирует
код для этой строки. Состояние буфера после этих операций показано в нижней
части примера.
Несмотря на то что алгоритм LZ77 эффективен и адаптируется к природе те-
кущего входного потока, он обладает рядом недостатков. Для поиска совпадений
в предшествующем тексте этот алгоритм использует окно конечного размера. Если
размер текста намного превышает размер окна, то многие потенциальные совпа-
дения остаются необнаруженными. Размер окна может быть увеличен, но это при-
ведет к двум нежелательным эффектам. Во-первых, время работы алгоритма воз-
растет. Во-вторых, придется увеличить размер поля указателя.
654
Глава 20. Сжатие без потерь
Алгоритм распаковки
Процесс распаковки текста, сжатого при помощи алгоритма LZ77, прост. Алгоритм
распаковки должен сохранять последние Nсимволов распакованного результата
Когда встречается закодированная строка, алгоритм распаковки заменяет код с
помощью полей указателя и длины.
Алгоритмы LZ78 и LZW
Алгоритмы LZ78 и LZW пытаются обойти ограничения схемы LZ77, вместо огра-
ниченного окна создавая словари.
Обзор
Как и схема LZ77, алгоритм LZW (и LZ78) поддерживает словарь строк вместе с
их кодами как для сжатия, так и для распаковки. Когда любая строка словаря по-
является на входе алгоритма сжатия, эта строка заменяется кодом. Распаковщик,
наоборот, заменяет коды соответствующими им строками. По мере работы алго-
ритма сжатия к словарю добавляются новые строки.
В любой момент времени словарь содержит все односимвольные строки плюс
некоторые многосимвольные строки. Механизм работает так, что любые ведущие
подстроки присутствующей в словаре строки также могут использоваться в каче-
стве элементов словаря. Например, если в словаре есть строка MEOW, снабжен-
ная своим уникальным кодовым словом, тогда строки МЕО и ME также присут-
ствуют в словаре и у каждой есть свое уникальное кодовое слово.
Логически словарь может быть представлен в виде набора деревьев, при этом
корень каждого дерева соответствует символу алфавита. Таким образом, по умол-
чанию имеется 256 деревьев (все возможные 8-битовые символы).
Далее мы более детально опишем алгоритм, имеющий много общего со стан-
дартом VAlbis и схемами LZ78 и LZW.
Сжатие
Прежде чем перейти к описанию алгоритма, введем следующие обозначения:
♦ G — следующее доступное неиспользуемое кодовое слово;
♦ С2 — размер кодового слова, по умолчанию 9 бит;
♦ N2 — максимальный размер словаря, равный количеству кодовых слов ( 2^);
♦ N3 — размер символа, по умолчанию 8 бит;
♦ N5 — первое кодовое слово, используемое для обозначения строки из более
чем одного символа;
♦ N? — максимальная длина строки, которая может быть закодирована.
Алгоритм сжатия реализует три основные действия:
♦ поиск совпадений строк и кодирование;
4- добавление новых строк к словарю;
♦ удаление старых строк из словаря.
20.4. Алгоритмы совпадения строк
655
Алгоритм всегда ищет в словаре строку максимальной длины, совпадающую с
входной строкой. Передатчик разбивает входной поток на строки, присутствую-
щие в словаре, и преобразует каждую строку в соответствующее кодовое слово.
Поскольку все односимвольные строки уже находятся в словаре, весь входной по-
ток может быть разбит на строки, присутствующие в словаре. Приемник прини-
мает поток кодовых слов и преобразует каждое кодовое слово в соответствующую
символьную строку.
Алгоритм всегда ищет новые строки, которые можно добавить к словарю, а так-
же заменить ими старые строки, которые вряд ли встретятся в будущем. Процедура
выглядит следующим образом:
1. Входные символы обрабатываются, чтобы получить совпадающие строки
большей длины.
2. Если совпадающая строка имеет максимальную длину (Лг7 символов), тогда
алгоритм передает код для этой строки и переходит к шагу 1.
3. В противном случае к совпадающей строке добавляется следующий символ,
а сама строка добавляется к словарю и ей назначается код. Однако посколь-
ку эта строка еще отсутствует в словаре получателя, алгоритм передает код
оригинальной строки и использует оставшийся символ, чтобы опять начать
с шага 1.
Процедура добавления новой строки к словарю зависит от того, является ли
словарь полным или нет. В любом случае передатчик хранит переменную G, пред-
ставляющую собой значение следующего доступного кодового слова. При иници-
ализации системы переменной G присваивается значение N5, которое представ-
ляет собой следующее значение, после того как всем односимвольным строкам
присвоены значения. Таким образом, по умолчанию значение Ct начинается с 256.
До тех пор пока словарь пуст, при определении каждой новой строки ей назнача-
ется код Ci и этот код увеличивается на единицу.
Когда словарь полон, при определении новой строки ей назначается кодовое
значение Ct, затем выполняется следующая процедура:
1. Ci увеличивается на единицу.
2. Если значение Ci равно максимальному размеру словаря N?, оно устанавли-
вается равным Ns. То есть как только величина Ci достигает своего макси-
мального значения, она снова устанавливается равной минимальному зна-
чению.
3. Если узел, идентифицируемый значением G, не является листовым узлом,
тогда выполняется переход к шагу 1.
4. Если узел является листовым узлом, тогда он удаляется из словаря.
В конце этой процедуры в словаре появляется место для новой записи, a Ci
представляет собой неиспользуемый код, присваиваемый этой записи. Теперь си-
стема готова к определению следующей новой строки словаря.
Рисунок 20.9, а иллюстрирует работу алгоритма сжатия, для которого использу-
ется трехсимвольный алфавит. Вначале в словаре находятся только односимволь-
ные строки (верхняя часть табл. 20.7). Входные данные считываются слева на-
656
Глава 20. Сжатие без потерь
право. Поскольку в таблице нет совпадающих строк длиннее а, для этой строки
выводится код 1, а к таблице добавляется новая строка ab, которой назначается
код 4. Затем для начала новой строки используется символ Ь. Поскольку строки Ьа
нет в словаре, она добавляется в словарь с кодом 5, а в выходной поток направля-
ется символ Ь. Процесс продолжается подобным образом.
Входные символы а ь а b с Ь а b а Ь а а а а а а
Выходные коды Новые строки, добавленные 1 2 4 3 5 8 1 10 11
4 6 8 10
в таблицу Входные коды Выходные данные Новые строки, добавленные 1 1 а 5 2 1 ь 7 а 4 3 ab с 9 5 8 1 1 1 i Ьа bab а 11 10 ; аа 11 1 ааа
4 6 8 10
в таблицу 5 7 9 11
б
Рис. 20.9. Пример работы алгоритма LZW
Таблица 20.7. Словарь LZW для примера, показанного на рис. 20.9
Строковая таблица Альтернативная таблица
Символ Код Символ Код
а 1 а 1
ь 2 ь 2
с 3 с 3
ab 4 1b 4
Ьа 5 2а 5
abc 6 4с 6
cb 7 ЗЬ 7
bab 8 5Ь 8
baba 9 8а 9
аа 10 1а 10
аааа 11 10а 11
В таблице показан словарь, формируемый в данном примере. Более компакт-
ный метод хранения иллюстрирует правая часть таблицы, в которой каждая стро-
ка представляется в виде префиксного кода строки и последнего символа. При та-
ком представлении все многосимвольные элементы словаря имеют равную длину.
20.5. Рекомендуемые литература и веб-сайты
657
Такое представление также предполагает структуру словаря, состоящую из не-
скольких деревьев, как показано на рис. 20.10.
Рис. 20.10. Представление словаря LZ в виде деревьев
Распаковка
Интересный аспект работы семейства алгоритмов LZ78 заключается в том, что
словарь не передается явно алгоритму распаковки. Вместо этого алгоритм распа-
ковки создает идентичный словарь в процессе распаковки. Это возможно благо-
даря тому, что при распаковке строка, соответствующая коду, всегда встречается
прежде самого кода.
Рисунок 20.9 б иллюстрирует процесс распаковки. Каждый встреченный код
преобразуется в соответствующую символьную строку. Между тем, выходной по-
ток используется для создания новых элементов словаря по тем же правилам, что
и в алгоритме сжатия.
20.5. Рекомендуемые литература
и веб-сайты
Подробное техническое описание алгоритма, обсуждавшегося в этой главе, при-
ведено в [197]. Другие две полезные книги по сжатию данных — это [194] и [ИЗ].
В обеих книгах содержится ряд примеров программ сжатия и распаковки данных,
а также анализируется восприимчивость данных к сжатию.
Рекомендуемым веб-сайтом является Compression pointers. Это хороший источ-
ник информации о книгах, алгоритмах, продуктах и т. д. по сжатию данных.
658
Глава 20. Сжатие без потерь
20.6. Задания
1. В протоколе MNP (Microcoin Network Protocol — сетевой протокол от Micro-
com) используется разновидность схемы, представленной на рис. 20.1. Реали-
зованный в более чем 1 млн модемов протокол MNP, возможно, представ-
ляет собой самую популярную схему группового кодирования. В протоколе
MNP любая строка из трех и более повторяющихся символов представляется
в виде СХХХ, где С — количество повторений символа, а X — сам символ
(см. пример ниже). Перечислите преимущества и недостатки метода MNP
для группового кодирования по сравнению с методом, который иллюстри-
рует рис. 20.1.
Исходные данные Сжатые данные
ААА 0AAA
ВВВВ 1ВВВ
ссссс 2ССС
2. Постройте код LZ77 для следующей последовательности. Используйте сколь-
зящий буфер предыстории и упреждающий буфер по 8 символов каждый.
0100010011010001010010000101000
3. Декодируйте последовательность 0 0 13 5 2, сформированную при помо-
щи метода LZW, используя (сравните с рис. 20.10) начальный словарь а(0)
и Ь(1).
4. В этом упражнении два вопроса.
а) что при прямолинейной реализации метода кодирования LZ77 будет
работать быстрее — сжатие или распаковка? Почему;
б) ответьте на тот же вопрос для метода кодирования LZ78.
5. Предположим, вам дается входная последовательность вида аааа... ааа, в ко-
торой символ повторяется k раз. Какая схема кодирования будет в данном
случае более эффективной, LZ77 или LZ78? Аргументируйте свой ответ,
а также расскажите о сделанных вами предположениях.
6. Рассмотрим показанную далее символьную строку и предположим, что в этой
строке отражены относительные вероятности появления символов (напри-
мер, Рг(а) = 2/40). Покажите код для этой строки, полученный с помощью
каждого из перечисленных методов:
аа bbb сссс ddddd ееееее fffffffgggggggg
а) метод Хаффмана;
б) алгоритм LZW;
в) арифметическое кодирование.
7. Один из способов повышения эффективности алгоритма сжатия заключа-
ется в предварительной обработке данных и придании им вида, более при-
годного для сжатия. Примером такой обработки является преобразование
20.6. Задания
659
BWT (Burrows — Wheeler Transform — преобразование Бэрроуза — Уилера).
Преобразование BWT выполняется сразу над целым блоком данных; един-
ственное ограничение состоит в размере буфера. Для строки длины 2V преоб-
разование BWT формирует массив из Лфазличных строк длины N. При этом
каждый символ в исходной строке используется в качестве начала цикличес-
кой перестановки исходной строки (это логическая операция; в фактичес-
кой реализации используются указатели или другой метод экономии памя-
ти). Например, если исходная строка представляет собой слово ESEPAAT,
тогда формируется логическая матрица, показанная ниже слева. Для удобства
ряды оригинальной матрицы помечаются по порядку. Затем ряды матрицы
сортируются в лексикографическом порядке (по алфавиту), в результате
чего получается матрица, показанная ниже справа. Окончательный резуль-
тат преобразования представляет собой правый столбец показанной справа
сортированной матрицы и целые числа, указывающие позицию первого сим-
вола оригинальной строки в выходной строке. В нашем примере выходная
строка выглядит как PASTEEA, а целое число равно 5. Затем эта выходная
строка может быть сжата с помощью обычного алгоритма сжатия, например
алгоритма Хаффмана. После того как сжатые данные распаковываются, ис-
ходная строка восстанавливается путем обратного преобразования.
SO Е S Е Р А А Т S4 А А Т Е S Е Р
S1 S Е Р А А Т Е S5 А Т Е S Е Р А
S2 Е Р А А Т Е S S2 Е Р А А Т Е S
S3 Р А А Т Е S Е SO Е S Е Р А А Т
S4 А А Т Е S Е Р S3 Р А А Т Е S Е
S5 А Т Е S Е Р А S1 S Е Р А А Т Е
S6 Т Е S Е Р А А S6 Т Е S Е Р А А
а) на первый взгляд преобразование может показаться необратимым, тем
не менее, оно обратимо. Опишите алгоритм обратного преобразования
для восстановления исходной входной строки;
б) каким образом преобразование BWT может улучшить производитель-
ность алгоритма сжатия?
Глава 21
Сжатие с потерями
В Токийском метро сотрудники заняты исключитель-
но собиранием потерянной обуви и оторванных в лавке
рукавов.
Барбара Вайи (Рут Рендвял). Ковер царя Соломона
Сжатие данных без потерь накладывает жесткую нижнюю границу на размер любо-
го файла или сообщения. Этой границей является энтропия этого файла. Сжатие
данных без потерь позволяет восстановить исходные несжатые данные с точнос-
тью до бита. Эта характеристика, как правило, необходима для текстовых файлов,
баз данных, двоичных объектных файлов и т. д. Однако существует много типов
файлов, для которых не требуется абсолютно точного восстановления исходных
данных. Примеры таких файлов — аудио- и видеоклипы, а также неподвижные
изображения. В этих случаях допускается некоторое количество ошибок при вос-
становлении исходных данных, и может применяться сжатие с потерями.
Ключевым вопросом сжатия с потерями является компромисс между коэффи-
циентом сжатия и точностью восстановленных данных. В общем, должно быть
ясно, что чем выше коэффициент сжатия для данного алгоритма сжатия, тем ниже
точность восстановленных данных. Цель любого алгоритма сжатия с потерями за-
ключается в достижении высоких коэффициентов сжатия за счет потери некото-
рых битов таким образом, чтобы восстановленные данные были достаточно близ-
ки к оригиналу.
Эта глава начинается с описания дискретного косинусного преобразования.
Затем мы изучим волновое сжатие, быстрый и эффективный метод, становящий-
ся все более популярным. Затем мы обсудим стандарт сжатия неподвижных изоб-
ражений JPEG. Наконец, последний раздел посвящен стандарту MPEG, предна-
значенному для сжатия видеоизображения.
21.1. Дискретное косинусное
преобразование
Дискретное косинусное преобразование (Discrete Cosine Transform, DCT) представ-
ляет собой преобразование массива пикселов в массив значений пространствен-
21.1. Дискретное косинусное преобразование
661
ной частоты1. Это преобразование обратимо с точностью до ошибок округления.
Дискретное косинусное преобразование не производит сжатия, но преобразует
информацию об изображении в форму, более удобную для сжатия.
Одномерное дискретное косинусное
преобразование
Будет проще понять работу' дискретного косинусного преобразования в двух из-
мерениях (именно такая форма применяется в алгоритмах MPEG и JPEG), если
мы сначала рассмотрим одномерное дискретное косинусное преобразование.
Определение
Предположим, что у нас есть одномерное изображение, представляющее собой
линейный массив из Д'" пикселов, каждый из которых обозначается некоторым зна-
чением яркости р(х) (0 <х < N). Таким образом, р(х) представляет собой простран-
ственную функцию (а не функцию времени). Это изображение можно представить
в виде суммы пространственно-частотных компонентов с частотами, изменяющи-
мися от 0 до N- 1:
, \ I хр г/1\ с/ гх + 1)т/
S(/)cos[(2j+1)’^
v 2N
(21.1)
Здесь:
ад =
1/72,/ = о,
1, / > 0.
Это напоминает представление непрерывной функции в виде ряда Фурье.
В данном случае мы представляем дискретную функцию р(х), а частотные компо-
ненты определены только для дискретных значений частот.
Чтобы получить формулу (21.1), нужно вычислить коэффициенты {5(/)>
0</<N}. Обратите внимание на то, что первое слагаемое формулы (21.1) пред-
ставляет собой компонент с нулевой частотой, то есть постоянную составляющую.
Это слагаемое должно быть равно среднему значению р(х). Поэтому
5(0) 1 « . .
xIN N г=0
Функция времени может быть выражена во временной области путем присвоения значения каждому
моменту времени. Эта функция также может быть представлена в виде ряда Фурье или преобразова-
ния Фурье, в случае чего мы получаем представление функции в частотной области. Аналогично,
функция, изменяющаяся в пространстве (в одном, двух или трех измерениях), может быть представ-
лена в виде суммы или интеграла частотных составляющих, где каждая составляющая представляет
собой синусоиду, изменяющуюся не во времени, а в пространстве. Такие функции называются про-
странственными и пространственно-частотными соответственно.
662
Глава 21. Сжатие с потерями
5(0) = 4=Хр(х).
-JN л=0
Общая формула для S(f) выглядит следующим образом:
(21.2)
Формула (21.2) называется одномерным дискретным косинусным преобразо-
ванием функции р(х), а формула (21.1) представляет собой обратное дискретное
косинусное преобразование функции 5(f).
Пример
Рассмотрим пример, в котором блок из восьми пикселов одноцветного изображе-
ния подвергается дискретному косинусному преобразованию. Как правило, дву-
мерное дискретное косинусное преобразование применяется к блоку размером
8x8 пикселов, так что данный пример представляет собой вполне реалистичную
одномерную версию. В примере для обозначения яркости пикселов используются
8-битовые значения, так что 0 обозначает белый цвет, а 255 — черный. Это также
типично для одноцветных изображений.
I ' 'Ж O'* Ж 1 : . . Г'.:’ « ... w iiy . Щ. I. * c $ :
а
43 138 148 183 208 254 248 148
б р(0) р(1) р(2) р(3) р(4) р(5) р(6) р(7)
-85 10 20 55 80 126 120 20
в S(0) S(1) S(2) S(3) S(4) S(5) S(6) S(7)
122 -129 -95 26 -73 4 -31 -11
г
-85 10 20 55 80 126 120 20
д
Рис. 21.1. Пример одномерного дискретного косинусного преобразования
На рис. 21.1, а показано исходное изображение, а на рис. 21.1, б — вектор зна-
чений яркости для этого изображения. Для удобства вычтем из каждого изобра- /
21.1. Дискретное косинусное преобразование
663
жения 128 — такая операция называется смещением уровня (level shift) — так, что-
бы диапазон всех возможных значений яркости был симметричен относительно О
(от -128 до 127), в результате получим рис. 21.1, в. Затем производится дискрет-
ное косинусное преобразование:
£ л-0 L
Эти вычисления соответствуют значениям, показанным на рис. 21.1, г. Чтобы
проверить полученные значения, сосчитаем обратное дискретное косинусное пре-
образование:
р(х) = 11 .
/=о L
В результате мы получим значения, показанные на рис. 21.1, д, которые точно
совпадают с исходными значениями.
Стоит показать предыдущую формулу в развернутом виде, чтобы подчеркнуть
природу дискретного косинусного преобразования:
р(х) - ~^= 5(0) cos[0] + cos[(2x + 1)л /16] +
/8 2
+ cos[(2x + 1)2л /16] + cos[(2x + 1)3л /16] +
+ cos[(2t + 1)4л /16] + cos[(2x + 1)5л /16] +
+ cos[(2x + 1)6л /16] + cos[(2x + 1)7 л /16].
Таким образом, функция р(х) может быть представлена в виде взвешенной сум-
мы восьми косинусных функций. На рис. 21.2 показаны эти восемь функций, на-
зываемые базисными косинусными функциями. На каждом графике изображена
косинусная функция дискретной пространственной переменной х. Каждая из этих
дискретных функций представляет собой обычную косинусную функцию, диск-
ретизированную по восьми отсчетам. Этим функциям присущи несколько важных
свойств.
♦ Завершенность. Взвешенная сумма этих восьми функций может быть вы-
числена для каждого из восьми значений пикселов.
- 4 Минимальность. Ни одна из восьми волновых форм не может быть представ-
лена взвешенной комбинацией других волновых функций, и для завершен-
ности требуются все восемь волновых форм.
- 4 Уникальность. Никакой другой набор косинусных функций, кроме масш-
табированных версий этих восьми волновых форм, не может использо-
ваться для представления всех возможных последовательностей восьми
значений пикселов.
664
Глава 21. Сжатие с потерями
cos(O)
cos((2x+1)3n/16]
Рис. 21.2. Базисные дискретные косинусные функции
Эти свойства также применимы к общему случаю использования N косинус-
ных функций для представления одномерного изображения из Лг пикселов.
21.1. Дискретное косинусное преобразование
665
Таким образом, любая дискретная функция {р(л), 0 < х < N} может быть пред-
ставлена при помощи набора дискретных косинусных функций {cos((2x + 1) х
xnf/2N),Q<f<N}.
Обратите внимание на то, что в данном примере большая часть амплитуд диск-
ретного косинусного преобразования сконцентрирована на низких частотах, вклю-
чая нулевую частоту (J = 0). Это типично для изображений. Как правило, яркость
изменяется постепенно, и резкие переходы встречаются нечасто. Соответственно,
высокие пространственные частоты вносят в изображение незначительный вклад.
Важность низкочастотных составляющих иллюстрирует рис. 21.3, на котором по-
казана последовательность частичных сумм для этого примера. На каждом графи-
ке к сумме добавляется еще одно слагаемое. На первом графике изображена всего
одна составляющая с нулевой частотой, а на последнем — все восемь компонентов
взвешенных частот. Уже после сложения первых трех или четырех составляющих
общая форма конечной функции становится очевидной, а последние несколько
слагаемых мало что меняют в общей картине. График в правом нижнем углу ри-
сунка полностью представляет функцию р(х), в чем можно убедиться, сравнив его
с рис. 21.1, в.
Важность частотного представления изображения, выполненного при помощи
дискретного косинусного преобразования, заключается в следующем. Если вклад
высокочастотных составляющих невелик, как это обычно и бывает, тогда можно
удалить эти составляющие или представить их меньшим количеством битов. Имея
дело с исходным изображением, то есть с пространственной функцией, оперируя
в области частот, а не с дискретным косинусным преобразованием, данный тип
сжатия осуществить сложно.
Двумерное дискретное косинусное
преобразование
Двумерное дискретное косинусное преобразование является ключевым для стан-
дартов JPEG и MPEG. Как и раньше, мы начнем с математического определения,
а затем рассмотрим пример.
Определение
Так же как любой линейный массив из Nпикселов может быть представлен в виде
взвешенной суммы N косинусных функций с различными частотами, и матрица
из NxN пикселов может быть представлена взвешенной суммой NxN косинус-
ных функций. Формула выглядит следующим образом:
2 л'-iw-i
рО, у) = ту s S C{u)C{v)S(u, v) cos
N и=0 v=0
(2х + 1)та
2N
(2г/ + 1)лс
(21.3)
Здесь
1/V2, f = о,
1,/>0
для f = и или V.
666 Глава 21. Сжатие с потерями
Как следует из формулы (21.3), двумерный массив пикселов может быть пред-
ставлен произведениями пространственно-частотных компонентов в горизонталь-
21.1. Дискретное косинусное преобразование
667
ном и вертикальном измерениях. Отдельные косинусные сомножители те же са-
мые, что и в одномерном случае. Таким образом, для дискретного косинусного
преобразования 8x8 используются те же косинусные функции, что и на рис. 21.3.
Как и при одномерном преобразовании, слагаемое с нулевой частотой должно
быть равно среднему значению функции р(х). В данном случае это — 5(0,0)/N.
Поэтому
5(0,0) 1 .
™ л-0 г/=0
N
S(0,0) = ^-^^p(x,y).
Л Л-=о у=о
Общая формула для S(f) выглядит следующим образом:
S(w,0 = ^C(w)C(y)££x*^)c°s - cos (21.4)
Формула (21.4) называется двумерным дискретным косинусным преобразова-
нием функции р(х, у).
Пример
Мы рассмотрим пример (взятый из [6]), в котором квадратный массив из 64 пик-
селов (8 х 8) одноцветного изображения подвергается дискретному косинусно-
му преобразованию. В стандарте JPEG изображения обрабатываются блоками по
8x8. Этот размер был выбран по двум причинам. Во-первых, сложность вычисле-
ний быстро растет с увеличением размера обрабатываемого блока, поэтому блоки
больших размеров оказывают чрезмерное давление на вычислительные ресур-
сы. Во-вторых, исследования различных изображений показали, что ограниче-
ния обрабатываемой области этими размерами не приводят к существенным
потерям точности.
На рис. 21.4, а показана матрица значений яркости после смещения уровня в
диапазон от -128 до 127. Обратите внимание на то, что значения пикселов изме-
няются незначительно. Это типично для больших изображений: в любом блоке
8x8, скорее всего, изменения яркости будут небольшими. Затем производится
преобразование:
C(u)C(v) у-у у-у Г(2х+1)тш1 Г(2х+1)то1 гх
5(н, г) = ’ X Е Р(х’ У) cos 1—7^— cos -—~~ (2 L5>
4 L 16 J L 16 J
В результате данных вычислений получается матрица, показанная на рис. 21.4, б.
Верхний левый элемент матрицы представляет собой значение 5(0, 0), соответ-
ствующее среднему значению матрицы, умноженное на 8:
1 7 7
*(о, °)=| £ £ у)=8- —•
о Л =О г/=0 Ь4
668
Глава 21. Сжатие с потерями
79 75 79 82 82 86 94 94
76 78 76 82 83 86 85 94
72 75 67 78 80 78 74 82
74 76 75 75 86 80 81 79
73 70 75 67 78 78 79 85
69 63 68 69 75 78 82 80
76 76 71 71 67 79 80 83
72 77 78 69 75 75 78 78
619 -29 8 2 1 -3 0 1
22 -6 —4 0 7 0 -2 -3
11 0 5 -4 -3 4 0 -3
2 -10 5 0 0 7 3 2
6 2 -1 -1 -3 0 0 8
1 2 1 2 0 2 -2 -2
-8 -2 -4 1 2 1 -1 1
-3 1 5 -2 1 -1 1 -3
а б
Рис. 21.4. Пример двумерного дискретного косинусного преобразования
Значение этого элемента значительно превосходит значения всех остальных
элементов, которые уменьшаются с ростом частоты (с удалением от левого верх-
него элемента матрицы). Это типично для многих изображений. Другими слова-
ми, можно сказать, что большая часть информации в типичном изображении на-
ходится в области низкочастотных составляющих. Другими словами, как правило,
у изображений нет резких изменений яркости.
Для проверки этих значений можно осуществить обратное дискретное косинус-
ное преобразование:
Р{х, г/) = 7 Е Е C(u)C(v)S(u, v) cos
4 м=0 г-=0 L 1Ь
COS
(2у + 1)то
16
(21.6)
В результате подобных преобразований мы получим исходные входные данные,
показанные на рис. 21.4, а.
21.2. Волновое сжатие
В последние годы значительный интерес получило использование метода волно-
вого сжатия (wavelet compression) изображений. Двумя заслуживающими внима-
ния примерами использования данного метода являются система идентификации
отпечатков пальцев ФБР и последняя версия широко применяемого стандарта
JPEG — JPEG 2000. Привлекательность метода волнового сжатия заключается во
впечатляющих коэффициентах сжатия при высоких скоростях. Метод волнового
сжатия также обладает высокой гибкостью. Например, он позволяет представлять
различные области изображения с различными степенями разрешения и точности.
Кроме того, метод волнового сжатия хорошо подходит для прогрессивной переда-
чи изображения, при которой сначала передается нечеткая версия изображения,
а более мелкие детали пересылаются в ходе передачи позднее.
В этом разделе представляется только краткий обзор этого масштабного и слож-
ного вопроса. Мы начнем с ключевых понятий метода волнового сжатия. В остав-
шейся части этого раздела обсуждается метод Хаара (Haar), являющийся наибо-
лее простым методом волнового сжатия.
21.2. Волновое сжатие
669
Элементарная волна
Хороший способ познакомиться с понятием элементарной волны (wavelet) — срав-
нение с представлением функции в виде ряда Фурье. Любая периодическая функ-
ция одной переменной g(x) может быть представлена в виде ряда Фурье:
g(x) = + £[Д, cos(2roz/0x) + В„ sin(2Tin/ox)].
Здесь /о представляет собой величину, обратную периоду функции (/о = 1/Т).
Частота f0 называется основной частотой (fundamental frequency) или основной
гармоникой (fundamental harmonic). Кратные f0 частоты называют гармониками
(harmonics). Таким образом, периодическая функция с периодом Т может быть
представлена как сумма синусоид с частотами, кратными частоте/(| = 1 /Т. Как пра-
вило, разложение в ряд Фурье применяется к функции времени (то есть аргумент
х соответствует времени), но эта операция также применима и к пространствен-
ной функции, что уместно при обработке изображений. По существу, ряды Фурье
показывают, что любая периодическая функция может быть полностью описана
суммой синусоид с частотами, кратными основной частоте. Говорят, что ряды
Фурье представляют функцию в области частот, тогда как оригинальная функ-
ция определена во временной области или в пространстве в зависимости от того,
относится аргумент х ко времени или к пространству.
Используемые при разложении в ряд Фурье коэффициенты вычисляются по
следующим формулам:
2 Т
•* о
2 т
4, =-JgU)cos(2nn/0x)rfx,
' о
2 т(
g(x)sm(2mifox)dx.
J о
Таким образом, по представлению функции в виде ряда Фурье легко восстано-
вить ее временную или пространственную форму.
Непериодическая функция тоже может быть представлена в области частот при
помощи преобразования Фурье. В этом случае вместо суммы дискретных гармо-
ник функция представляется в непрерывном диапазоне частот в виде частотного
спектра. Однако основные принципы здесь те же. Преобразование Фурье также
обратимо, то есть можно по частотному спектру функции получить ее временное
или пространственное представление.
Понятие представления Фурье можно распространить на двумерные функции
и в таком виде использовать для обработки изображений.
Анализ Фурье представляет собой мощный инструмент, позволяющий решать
многие проблемы, которые очень сложно решать другими методами. Коэффици-
енты Фурье можно вычислять, хранить, передавать и использовать для восстапов-
670 Глава 21. Сжатие с потерями
ления исходного сигнала или функции. При решении многих проблем значитель-
но проще оперировать коэффициентами Фурье (в области частот), чем исходной
функцией (во временной или пространственной области).
Однако анализ Фурье плохо подходит для работы с функциями, определенны-
ми на коротком интервале аргумента (в отличие от функций, заданных в диапазоне
-с» < х < +°°), а также с функциями, значение которых резко и значительно изме-
няется. Такими характеристиками обладают изображения, имеющие ограничен-
ную протяженность в пространстве и, как правило, содержащие резкие края или
области с резко изменяющимися характеристиками. Для обработки таких изобра-
жений, а также для многих других целей анализ элементарных волн подходит луч-
ше, чем анализ Фурье.
Как представление Фурье, волновое представление включает суммирование
нескольких элементарных функций. В анализе Фурье в качестве элементарной
функции используется синусоида, заданная на всей вещественной оси. В волновом
анализе элементарной функцией является элементарная волна, представляющая
собой функцию, отличную от нуля только на конечном отрезке значений аргумен-
та и равную нулю для всех остальных значений ар1умента. Функция представляется
в виде суммы элементарных волн, каждая из которых, в свою очередь, представляет
собой растянутую или суженную единичную элементарную волну, называемую
материнской элементарной волной (mother wavelet). Путем анализа элементарных
волн может быть осуществлено волновое преобразование сигнала, протяженного
во времени, или изображения, в результате которого можно получить соответству-
ющие коэффициенты. Как и в случае анализа Фурье, эти коэффициенты позволя-
ют упростить обработку сигнала или изображения.
Простейшая элементарная волна, применяемая в волновом анализе, называет-
ся элементарной волной Хаара (Haar wavelet) и определяется следующим образом:
0< Х<-,
2
^о.о(л-) =
- < X < 1,
2
в остальных областях.
Из этой базовой элементарной волны мы можем получить следующий набор
функций:
'Vj,k{x) = '¥0^2ix-k) =
k2 ’ <х<
2'j,
£ + |]2'' <x<(k + l)2~j,
О, в остальных областях.
21.2. Волновое сжатие
671
На рис. 21.5 показаны некоторые из этих элементарных волн Хаара. Обратите
внимание на то, что с увеличением параметра j элементарная волна становится бо-
лее короткой, то есть частота элементарной волны растет. Параметр k сдвигает эле-
ментарную волну по оси х (во времени или в пространстве).
0,75
0,25
Рис. 21.5. Элементарные волны Хаара
х
Волновое представление позволяет использовать так называемый анализ с
переменным разрешением (multiresolution analysis). Сжатые версии базовой эле-
ментарной волны, сдвинутые в соответствующие области сигнала или изобра-
жения, могут представлять высокочастотные составляющие. Несжатые версии
базовой элементарной волны соответствуют низкочастотным, медленно из-
меняющимся компонентам. Добавляя все более сжатые элементарные волны,
можно представлять сигнал или изображение с произвольной степенью разре-
шения или точности. Более того, подобное представление с переменным разреше-
нием может найти очевидное применение для сжатия и прогрессивного преоб-
разования:
♦ Изображение можно сжать, отбросив коэффициенты с относительно не-
большими значениями. В результате будут отброшены элементарные вол-
ны, вклад которых в формирование изображения невелик.
♦ Передачу изображения по сети можно начинать с низкочастотных компо-
нентов. По мере приема более высокочастотных компонентов к изображе-
нию будет добавляться все больше деталей, а разрешение изображения бу-
дет увеличиваться, то есть изображение будет становиться четче.
Одномерное сжатие с помощью
элементарных волн Хаара
Чтобы понять, как можно использовать элементарные волны Хаара для сжа-
тия изображения в одном направлении, воспользуемся примером из [159].
672
Глава 21. Сжатие с потерями
Рассмотрим строку из восьми значений данных, которые могут быть рядом из
матрицы 8x8 пикселов, значение каждого из которых соответствует яркости.
Их значения равны.
64 48 16 32 56 56 48 24
Мы будем преобразовывать изображение в три этапа, используя процесс, на-
зываемый усреднением и дифференцированием:
64 48 16 32 56 56 48 24
56 24 56 36 8 -8 0 12
40 46 16 10 8 -8 0 12
43 -3 16 10 8 -8 0 12
На первом шаге вычисляются средние значения последовательных пар чисел
из исходной строки, в результате чего получаются первые четыре числа второй
строки. Остальные четыре значения второй строки вычисляются как разности тех
же пар чисел первого ряда. Таким образом, последние четыре числа второго ряда
представляют собой уровень более мелкой детализации, отражающий изменения
изображения. Первые четыре числа отражают фоновый уровень, к которому для
воспроизведения оригинального изображения необходимо добавить более мелкие
детали. На следующем шаге обрабатываются только первые четыре числа, кото-
рые снова попарно усредняются и дифференцируются. В результате мы получаем
два числа, представляющие уровень меньшей степени детализации. На последнем
шаге усредняются и дифференцируются два первых значения предыдущего ряда.
Все разностные значения показаны полужирным шрифтом. Обратите внимание
на то, что первое значение последнего ряда представляет собой среднее значение
всех восьми чисел исходного изображения.
Мы можем сделать несколько наблюдений:
♦ Этот процесс обратим. Путем соответствующих сложений и вычитаний мы
можем снова получить из последнего ряда исходный ряд.
♦ Этот процесс можно обобщить применительно к строкам любой длины. Для
строки из 2* элементов требуются k этапов обработки. Любая строка, длина
которой не равна степени 2, может быть дополнена нулями.
♦ Области, в которых исходные данные изменяются незначительно, после пре-
образования выглядят как последовательности небольших или нулевых зна-
чений.
♦ Преобразованное представление позволяет осуществить сжатие без потерь,
так как обычно преобразованные данные содержат нулевые значения. В нашем
примере седьмой элемент в преобразованном представлении равен нулю.
Путем группового кодирования можно получить сжатую версию.
♦ Значительно большей степени сжатия, хотя и с потерями данных, можно
добиться, игнорируя области малых изменений.
Чтобы продемонстрировать последнее утверждение, зададим некоторое по-
роговое значение в и обнулим все элементы преобразованной строки, модуль
21.2. Волновое сжатие
673
которых не превышает е. Например, при пороговом значении 4 из строки удаляет-
ся второй элемент, в результате чего получится строка (43, 0,16,10, 8, -8, 0,12).
Поместим эту строку в последний ряд пустой таблицы и вычислим по ней ис-
ходные данные:
67 51 19 35 53 53 45 21
59 27 53 33 8 -8 0 12
40 43 16 10 8 -8 0 12
43 0 16 10 8 -8 0 12
На рис. 21.6, а полученный результат сравнивается с исходными данными. Со-
ответствие оказывается довольно близким. На черно-белом дисплее эти два изоб-
ражения были бы практически идентичными. Теперь установим пороговое значе-
ние е = 8. При этом мы устраним еще два элемента в сжатой строке и получим
строку (43,0,16,10,0,0,0,12). Распакуем эту строку: (59,59,27, 27, 53,53,45, 21).
Этот результат сравнивается с исходными данными на рис. 21.6, б. Данное прибли-
жение основывается только на пяти из исходных восьми значений, но приближе-
ние остается довольно неплохим.
——Исходные данные
----Данные после сжатия
Рис. 21.6. Сжатие при помощи элементарных волн Хаара
Представление в виде матрицы
Для вычислений мы можем преобразовать только что описанные операции в про-
стые конструкции линейной алгебры. Обратите внимание на то, что первый элемент
в преобразованной строке представляет собой просто среднее значение всех точек
исходных данных, то есть сумму всех значений, деленную на 8. Второй элемент
674
Глава 21. Сжатие с потерями
представляет собой разность средних значений первых и последних четырех то-
чек и т. д. Таким образом, мы можем представить данное преобразование в виде
следующего произведения вектора и матрицы:
ГХ 1 2 0 4 0 0 0
1 1 2 0 -4 0 0 0
1 1 -2 0 0 4 0 0
(64 48 16 32 56 48 24) х 1х 1 1 1 -1 -2 0 0 2 0 0 -4 0 0 4 0 0
1 -1 0 2 0 0 -4 0
1 -1 0 -2 0 0 0 4
1 -1 0 -2 0 0 0 -4
= (43 -3 16 10 8-8 0 12).
Определим два последних сомножителя в предыдущей формуле как матри-
цу W. Мы можем восстановить исходные данные из преобразованных данных
с помощью обратной матрицы:
W‘ = '11111111' 11 1 1 -1 -1 -1 -1 1 1 -1 -1 0 0 0 0 0 0 0 0 1 1 -1 -1 1 -1 0 0 0 0 0 0 0 0 1 -1 0 0 0 0 0 0 0 0 1 -1 0 0 0 0 0 0 0 0 1 -1 у /
Убедиться в том, что матрица W 1 является обратной по отношению к W, мож-
но, перемножив эти матрицы:
<1 1 1 1 1 1 1 1'
1 1 1 1 -1 -1 -1 -1
1 1 -1 -1 0 0 0 0
0 0 0 0 1 1 -1 -1 1
w *w = X—X
1 -1 0 0 0 0 0 0 8
0 0 1 -1 0 0 0 0
0 0 0 0 1 -1 0 0
0 0 0 0 0 0 1 -ь
21.2. Волновое сжатие
675
Ч 1 2 0 4 0 0 0'
1 1 2 0 -4 0 0 0
1 1 -2 0 0 4 0 0
1 1 -2 0 0 -4 0 0
Х1 -1 020040
1 -1 0 2 0 0 -4 0
1 -1 0 -2 0 0 0 4
1 -1 0 -2 0 0 0 -4,
С помощью обратной матрицы W-1
из преобразованных данных:
fl 0 0 0 0 0 0 О'
0 1 0 0 0 0 0 0
0 0 1 0 0 0 0 0
0 0 0 1 0 0 0 0
0 0 0 0 1 0 0 0
0 0 0 0 0 1 0 0
0 0 0 0 0 0 1 0
.00000001
< 7
I можем восстановить исходные данные
<1 1 1 1 1 1 1 1 1 -1 1 -1 1 -1 1 -1
1 1 -1 -1 0 0 0 0
(43 -3 16 10 8-8 0 12) х 0 0 0 0 1 1 -1 -1
1 -1 0 0 0 0 0 0
0 0 1 -1 0 0 0 0
0 0 0 0 1 -1 0 0
I.0 0 0 0 0 0 1 -1
= (64 48 16 32 56 48 24)
Представление в виде элементарных волн Хаара
Предыдущая формула предлагает способ выражения преобразования в виде сум-
мы элементарных волн Хаара. Вспомним, что нам необходимо сформировать се-
мейство элементарных волн, сжимая базовую элементарную волну в разное число
раз и смещая ее по оси абсцисс. Таким образом, мы получим элементарную волну
полного размера, две элементарные волны половинного размера, четыре элемен-
тарные волны размера 1/4 и т. д. С помощью подобных уменьшенных и сдвину-
тых элементарных волн мы можем представить ряды обратной матрицы W-1, как
показано на рис. 21.7.
Прежде чем продолжить, определим новую функцию, называемую масштаби-
рующей функцией Хаара:
[ 1, если 0 < х < 1,
[0 в противном случае.
Теперь несложно выразить исходную строку данных в виде суммы элементар-
ных волн Хаара и масштабирующей функции Хаара:
43 ф(т) - 3To,o + 164*1Д) + ЮТм + 84*2.0 - 84*2.! + 0Т2.2 + 124*2.3.
676
Глава 21. Сжатие с потерями
Таким образом, мы можем интерпретировать строку как сумму общего средне-
го значения и семи элементарных волн, умноженных на соответствующие коэф-
фициенты.
11111111
Масштаб 1/2
1 1 1 1 -1 -1 -1 -1
Масштаб 1
1 1 -1 -1 0 0 0 0
Масштаб 2
0 0 0 0 1 1 -1 -1
1 -1 0 0 0 0 0 0
0 0 1 -1 0 0 0 0
0 0 0 0 1 -1 0 0
0 0 0 0 0 0 1 -1
Масштаб 2
Рис. 21.7. Матрица, образованная элементарными волнами Хаара
Двумерное сжатие с помощью элементарных
волн Хаара
Одномерное волновое преобразование Хаара заключается в обработке векто-
ра-строки значений пикселов длины Лг= 2". Двумерное волновое преобразование
Хаара включает обработку матрицы NxN значений пикселов. По существу, при
двумерном волновом преобразовании Хаара сначала выполняются операции
усреднения и дифференцирования с каждым рядом матрицы пикселов, а затем та
же операция выполняется с каждым столбцом результата.
Рассмотрим для примера матрицу пикселов 4x4:
'18 14 12 4Л
10 6 8 8
16 4 8 0
12 0 4 4,
21.2. Волновое сжатие
677
Первый шаг двумерного волнового преобразования Хаара состоит из одномер-
ного преобразования каждого ряда, осуществляемого путем умножения матриц
PW, для чего используется версия 4x4 матрицы W, определенной в предыдущем
подразделе:
'18 14 12 4' '11 2 0' '12 4 2 4'
10 6 8 8 1 11-20 8 0 2 0
PW = X —X —
16 4 8 0 4 1-10 2 7 3 6 4
12 0 4 4 к > U -1 0 ~2) 5 16 0 \ 7
Следующий шаг состоит в выполнении одномерного преобразования каждого
столбца. Для этого матрица преобразования столбцов транспонируется, затем
умножается на преобразующую матрицу, после чего результат снова транспо-
нируется. С тем же успехом можно транспонировать преобразующую матрицу
и умножить ее на матрицу преобразованных столбцов:
Т = ((PW)'W)' = W'PW.
(21.7)
Здесь знак' означает транспонирование. Таким образом, двумерное волновое
преобразование исходной матрицы Р равно
4 2 4'
0 2 0
3 6 4
1 6 0,
'8 2 4 2'
2 0-20
2 2 0 2
Л 1 0 2,
Преобразованная матрица Т содержит среднее значение всех элементов исход-
ной матрицы в левом верхнем углу (8), а остальные элементы соответствуют
разностям. Элементы, отстоящие дальше от левого верхнего угла, соответству-
ют уровню более точной детализации, то есть более высокочастотным элемен-
тарным волнам. Как и раньше, сжатие может осуществляться при помощи по-
рогового значения и удаления элементов, значение которых по модулю меньше
порога.
Для обратного преобразования выполним следующие действия с формулой (21.7):
(W^-'TW1 = (W) ’W'PWW 1 = Р. (21.8)
Две нужные нам матрицы легко определить:
'1 1 1 1' '1 1 1 0^
1 1 -1 -1 . (W')-* = 1 1 -1 0
W ’ = 1 -1 0 0 1 -1 0 1
0 1 -ij 0 -1 1 -17
678
Глава 21. Сжатие с потерями
Таким образом,
4 1 1 1 '
1 1-1-1
1-10 0
0 0 1-1
7
4
1
1
1
1
1
-1
-1
1
-1
о
о
О '
О
1
-1
4
2
2
1
2
0
2
1
4
-2
0
0
2
О
2
2
Р =
1 1 1 1 1 -1 0 ' 0 44 0 6 4 8 2 4 ' 2 48 10 14 6 12 8 4' 8
1 -1 0 1 4 4 2 -2 16 4 8 0
1 -1 0 -1 7 I2 2 2 -2; Ь2 0 4 4J
21.3. Стандарт JPEG
Объединенная группа экспертов по обработке фотоизображений (Joint Photography
Experts Group, JPEG) представляет собой совместный проект ISO и ITU-T. Груп-
па JPEG разработала набор стандартов сжатия неподвижных изображений с не-
прерывно изменяющимся тоном, как монохромных, так и цветных. Стандарт JPEG
создавался как стандарт общего назначения, способный удовлетворить широкий
спектр потребностей в таких областях, как настольные издательские системы, гра-
фические произведения, передача фотографий по телефонным линиям и исполь-
зование изображений в медицинских целях.
Чтобы осознать необходимость в сжатии изображений, рассмотрим следующие
данные. Типичное оцифрованное цветное изображение состоит из 512 х 480 пик-
селов. Каждый пиксел представляется 24 битами (по 8 бит для каждого из трех
цветовых составляющих: красного, зеленого и синего). Таким образом, для хране-
ния подобного изображения требуется 737 280 байт. Передача такого изображения
по каналу ISDN с пропускной способностью 64 Кбит/с займет более полутора
минут. Алгоритм сжатия JPEG позволяет сохранить «отличное» качество изоб-
ражения, оставив информации примерно всего 1 бит на пиксел, то есть сжав изоб-
ражение в 24 раза. При таком коэффициенте сжатия объем памяти, занимаемый
изображением, уменьшается до 30 720 байт, а для передачи по 64-килобитной ли-
нии потребуется менее 4 секунд.
Для различных типов изображений требуются разные алгоритмы. Соответ-
ственно, стандартом JPEG определено четыре режима работы (рис. 21.8):
♦ Последовательный режим работы, основанный на дискретном косинусном
преобразовании. Каждый компонент кодируется за один проход слева напра-
во, сверху вниз.
Прогрессивный режим, работы, основанный на дискретном косинусном пре-
образовании. Изображение кодируется за несколько проходов, для прило-
жений с низкой скоростью передачи данных это позволяет получателю на-
21.3. Стандарт JPEG
679
блюдать постепенное появление принимаемого изображения с медленной
прорисовкой мелких деталей. Алгоритм этого режима основан на алгорит-
ме последовательного режима.
♦ Режим работы без потерь. Изображение кодируется с гарантией точного
восстановления оригинала.
♦ Иерархический режим работы. Изображение кодируется с различным раз-
решением, так что к уровням низкого разрешения можно получить доступ,
не распаковывая изображение с полным разрешением. Этот режим может
использоваться вместе с любым из трех других режимов.
Рис. 21.8. Режимы работы алгоритма JPEG
Последовательный режим DCT
Последовательный режим DCT предоставляет комбинацию высоких значений
коэффициента сжатия и хорошее качество распакованного изображения. Обе фазы
сжатия и распаковки состоят из трех основных этапов, проиллюстрированных на
рис. 21.9. На рисунке показана последовательность шагов для обработки моно-
хромного (однокомпонентного) изображения. Этот алгоритм последовательно
обрабатывает поток из блоков монохромного изображения размером 8x8. Сжа-
тие цветного изображения включает сжатие каждого из трех компонентов по отдель-
ности. Работая с цветными изображениями, алгоритм может либо обрабатывать
каждый компонент как отдельное изображение, либо обрабатывать блоки 8x8 каж-
дого компонента по очереди.
Прямое дискретное косинусное преобразование
Алгоритм сжатия начинает обработку каждого блока 8x8, смещая уровень отсче-
тов, так что они попадают в диапазон от -128 до 127. Затем каждый блок отобра-
жается на область частот путем дискретного косинусного преобразования, опре-
деленного формулой (21.5).
680
Глава 21. Сжатие с потерями
DST-кодер
Сжатое
изображение
(8x8 блоков)
Сжатие
DCT-декодер
Распаковка
Рис. 21.9. Последовательный алгоритм JPEG
Квантование
В результате работы алгоритма дискретного косинусного преобразования (DCT)
получается матрица коэффициентов. На вход алгоритма поступает матрица из
8-битовых значений. Для точных значений DCT-коэффициентов, как правило,
требуется больше разрядов. Квантование уменьшает количество разрядов, необ-
ходимое для представления каждого DCT-коэффициента. Кроме того, в результа-
те квантования в DCT-матрице появляется множество нулевых значений, что по-
зволяет достичь более высоких коэффициентов сжатия.
Квантование применяется независимо к каждому из 64 элементов DCT-мат-
рицы, причем к различным элементам квантование может быть применено в раз-
ной степени. В любом случае низкочастотные компоненты квантуются в меньшей
степени, чем высокочастотные. Причина этого в том, что изменения высокочас-
тотных составляющих менее заметны, чем низкочастотных.
Квантование реализуется через таблицу квантования 8x8, пример которой
показан па рис. 21.10 а. Для заданной таблицы квантования с элементами Q(w, у)
и DCT-матрицы с элементами S(u, у) выполняются следующие вычисления:
К(и, v) = round
' S(u,v)'
У“'р1 + 0,5
Q(w, v)
21.3. Стандарт JPEG
681
Здесь представляет собой максимальное целое число, меньшее х. Эта функ-
ция округляет до ближайшего целого значения. Например,
round(8/16) = round(0,5) = 1,
round(7/16) = round(0,4375) = О,
round(8/15) = round(0,533) = 1,
round(7/15) = round(0,466) = 1.
Если число меньше, чем половина коэффициента квантования, тогда оно
округляется до нуля.
16 11 10 16 24 40 51 61
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99
39 -3 1 0 0 0 0 0
2 -1 0 0 0 0 0 0
1 0 0 0 0 0 0 0
0 -1 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
а
б
Рис. 21.10. Эффект квантования
При тщательном подборе таблицы квантования можно добиться высокого ко-
эффициента сжатия при еле заметных для человеческого глаза искажениях. Стан-
дартом JPEG не определяется точное содержание таблицы квантования, а предла-
гается набор таблиц, одна из которых показана на рис. 21.10, а. На рис. 21.10, б
показан результат применения этой таблицы к DCT-матрице, представленной на
рис. 21.4, б. В результате квантования многие члены матрицы обнуляются, что уве-
личивает эффективность сжатия.
Сжатие без потерь
Последняя основная фаза процесса сжатия заключается в применении алгоритма
сжатия без потерь. Этот алгоритм включает два подготовительных этапа, за кото-
рыми следует фактическое кодирование. Сначала элемент (0, 0) квантованной
DCT-матрицы, представляющий собой среднее значение всех пикселов блока, ко-
дируется относительно такого же элемента предыдущего блока:
DIFF = DC, - PRED.
Здесь DIFF представляет собой результат разностного кодирования, DC, — эле-
мент (0, 0) г-го блока 8 х 8, a PRED — элемент (0, 0) предыдущего блока. Подоб-
ное разностное кодирование эффективно по двум причинам. Во-первых, высока
корреляция средних значений двух соседних блоков. Во-вторых, средние значе-
ния часто содержат значительную долю общего значения изображения.
Затем остальные значения матрицы упорядочиваются зигзагообразно, как по-
казано на рис. 21.11 (шахматная клетка нанесена для наглядности). Поскольку
682
Глава 21. Сжатие с потерями
многие высокочастотные компоненты с большой вероятностью равны 0, в резуль-
тате такого упорядочивания появляются длинные последовательности пулей, ко-
торые могут быть заменены символом конца блока. Например, последовательность
для матрицы на рис. 21.10, б будет выглядеть так:
(39 -3 2 1 -1 0 0 0 0 0 -1 ЕОВ).
Эти два подготовительных этапа приводят к появлению двух строк целых чи-
сел, которые затем кодируются путем энтропийного кодирования. Для этого мо-
жет применяться метод Хаффмана или арифметическое кодирование.
Компонент
с нулевой частотой
Увеличение
горизонтальной
частоты
Рис. 21.11. Зигзагообразное сканирование
5(7,7)
Распаковка
При распаковке выполняется обратная последовательность шагов (см. рис. 21.9).
Сначала декодируется и распаковывается закодированный при помощи энтропий-
ного метода файл, в результате чего получается матрица квантованных DCT-ko-
эффициентов. На этом этапе информация не теряется, поэтому восстановленная
матрица точно совпадает с исходной.
Следующий шаг заключается в деквантовании матрицы квантованных DCT-
коэффициентов, в результате чего получается матрица, близкая к исходной DCT-
матрице, в соответствии со следующей формулой:
R(u, v) = К(и, v) Q(w, v).
Полученный результат будет отличаться от исходной матрицы S(u, v), что
вызвано округлением. На рис. 21.12, а показан результат деквантования мат-
рицы, представленной на рис. 21.10, б. Сравнивая результат с рис. 21.4, б, мож-
21.3. Стандарт JPEG
683
но заметить отличия, в частности в правой нижней области матрицы (высокие
частоты).
624 -33 10 0 0 0 0 0
24 -12 0 0 0 0 0 0
14 0 0 0 0 0 0 0
0 -17 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
74 75 77 80 85 91 95 98
77 77 78 79 82 86 89 91
78 77 77 77 78 81 83 84
74 74 74 74 76 78 81 82
69 69 70 72 75 78 82 84
68 68 69 71 75 79 82 85
73 73 72 73 75 77 80 81
78 77 76 75 74 75 76 77
б
а
5 0 2 2 -3 -5 -1 -4
-1 1 -2 3 1 0 -4 3
-6 -2 -10 1 2 -3 -9 -2
0 2 1 1 10 2 0 -3
4 1 5 -5 3 0 -3 1
1 -5 -1 -2 0 -1 0 -5
3 3 -1 -2 -8 2 0 2
-6 0 2 -6 1 0 2 1
в
Рис. 21.12. Восстановление изображения
Наконец, восстановленная DCT-матрица отображается на пространственную
область путем обратного дискретного косинусного преобразования, определенно-
го в формуле (21.6). На рис. 21.12, б показана восстановленная матрица пикселов
из рис. 21.4, а, а на рис. 21.12, в — матрица ошибок, содержащая разности между
исходной и восстановленной матрицами для каждого пиксела.
Взаимосвязь между обсуждавшимися матрицами иллюстрирует рис. 21.13.
Прогрессивный режим DCT
Прогрессивный режим DCT исполюуется для быстрого получения декодируемо-
го приблизительного изображения, что может быть полезно, если декодер отделен
от кодера каналом с низкой скоростью передачи данных. Таким образом, наблю-
датель быстро получает грубое приближение к изображению, после чего постепен-
но видит все более четкие версии. В этом методе используются спектральная се-
лекция и/или последовательное приближение, а изображение обрабатывается за
несколько проходов, а не за один проход.
При использовании прогрессивного DCT-сжатия компрессирующий модуль
должен содержать буфер размером с изображение на выходе операции квантова-
ния. В буфере должна содержаться квантованная DCT-матрица для каждого бло-
ка пикселов 8 х 8 в исходном изображении. Затем на каждом проходе частично
кодируются коэффициенты в буфере.
684
Глава 21. Сжатие с потерями
Преобразование Квантование
Восстановленное
оцифрованное
изображение
Деквантованные
DCT-коэффициенты
Квантованные
DCT-коэффициенты
Рис. 21.13. Схема JPEG
Спектральная селекция
Метод спектральной селекции иллюстрирует рис. 21.14, а. На первом проходе от
каждого блока получается среднее значение (элемент (0, 0) DCT-матрицы). При
последующих проходах посылаются некоторые спектральные компоненты в зиг-
загообразном порядке. На каждом проходе посылается непрерывный набор диск-
ретных частот. Дополнительные проходы выполняются до тех пор, пока не будут
переданы все пространственно-частотные компоненты.
Последовательное приближение
В прогрессивном режиме DCT точность коэффициентов возрастает с каждым про-
ходом. Здесь также средние значения посылаются отдельно. Затем посылаются N
старших разрядов каждого коэффициента, причем величина N может быть выбра-
на по-разному. При последующих проходах посылается по одному дополнитель-
ному биту точности (рис. 21.14, б).
21.3, Стандарт JPEG
685
значимые разряды
Первый проход
Первый проход
Второй проход
Третий проход
Шестой проход
б
а
Рис. 21.14. Прогрессивное сжатие на основе алгоритма DCT
Оба метода (спектральная селекция и последовательное приближение) позво-
ляют получать изображения, постепенно проявляющиеся у получателя. Обсуж-
дение результатов применения каждого из этих методов и их комбинации можно
найти в [178].
686
Глава 21. Сжатие с потерями
Режим без потерь I
Стандарт JPEG включает простой режим работы без потери данных, основанный
на прогнозирующей модели. Как правило, этот метод позволяет достичь коэффици-
ента сжатия около 2:1, что значительно меньше, чем коэффициенты, достижимые
с помощью методов, основанных на дискретном косинусном преобразовании [91
На рис. 21.15, я показана общая блок-схема режима без потерь. В этом случае
обрабатывается вся матрица пикселов изображения, а не отдельные блоки 8x8.
При сканировании изображения каждое значение пиксела заменяется значением
разности в соответствии с формулой
Разность = Пиксел - Предсказание.
Здесь «Предсказание» — значение, основанное на значениях некоторых скани-
рованных ранее соседних пикселов. Философия этой стратегии заключается в сле-
дующем. Как правило, значение пиксела близко к значениям соседних пикселов.
Поэтому предсказание, основанное на значениях соседних пикселов, должно быть
близко к фактическому значению или совпадать с фактическим значением. Если
преобразовать матрицу пикселов в разностную матрицу, основанную на предска-
заниях, многие значения окажутся равными нулю, а другие значения будут неве-
лики. Преобразованное изображение должно упаковываться более компактно.
Сжатое
изображение
Выбранное
значение
Предсказание
О
1
2
3
4
5
6
7
Рис. 21.15. Режим сжатия без потерь JPEG
Предсказания нет
А
В
С
А + В-С
А + ((В - С)/2)
В + ((А-С)/2)
(А + В)/2
Схема JPEG позволяет использовать предсказание, основанное на значениях
некоторых или всех пикселов, смежных с текущим пикселом, но встреченных pa-j
в
21.3. Стандарт JPEG
687
нее в процессе сканирования слева направо или сверху вниз. На рис. 21.15, 6 пока-
зано, что для каждого пиксела X имеются три таких пиксела, помеченных буква-
ми А, В и С. Единственное исключение составляют пикселы верхнего ряда и лево-
го столбца, у которых имеется только один предшествующий пиксел.
Алгоритм сжатия без потерь может быть настроен для использования любой
комбинации предшествующих пикселов, как показано на рис. 21.15, в. В режимах
с 1 по 3 используются одномерные предсказатели, тогда как в режимах с 4 по 7
используются двумерные предсказатели. Которые предсказатели задействовать,
зависит от реализации. Об этом следует информировать распаковывающий мо-
дуль. Однако в любом случае применяются три правила:
1. Значение предсказателя для левого верхнего пиксела равно 2Р-1, где Р пред-
ставляет собой входную точность.
2. Для остальных пикселов верхнего ряда предсказание основывается на зна-
чении левого соседа (режим 1).
3. Для остальных пикселов левого столбца предсказание основывается на зна-
чении соседа сверху (режим 2).
Как только матрица предсказателей сформирована, ее можно закодировать при
помощи метода Хаффмана или путем арифметического кодирования.
Иерархический режим
В иерархическом режиме изображение кодируется в виде набора кадров с возрас-
тающим разрешением. Этот режим может использоваться совместно с любым дру-
гим из трех режимов сжатия.
В иерархическом режиме кодирующий модуль начинает с формирования по-
следовательности изображений, при этом разрешающая способность каждого сле-
дующего изображения в два раза меньше, чем предыдущего, в одном или в обоих
измерениях. Например, изображение размером 1024 х 1024 может быть уменьшено
до размеров 512x512. По существу, эта операция представляет собой фильтрацию
низких частот, усредняющую значения пикселов. Этот процесс продолжается до
тех пор. пока не будет получено изображение с минимальным разрешением, зада-
ваемым алгоритму в виде параметра. Затем выполняются следующие шаги:
1. Изображение с минимальным разрешением сжимается в одном из трех ре-
жимов сжатия (последовательный режим DCT, прогрессивный режим DCT,
режим сжатия без потерь). Результат является частично сжатыми данны-
ми, но также представляет собой входные данные для следующего шага.
2. Распаковывается результат предыдущего шага, а затем путем интерполяции
из него формируется изображение более высокого разрешения.
3. Результат предыдущего шага используется для предсказания битов факти-
ческого изображения с данным разрешением, в результате сравнения кото-
рых получается разностная матрица. Эта матрица сжимается в одном из трех
режимов сжатия. Результат снова является частично сжатыми данными.
4. Шаги 2 и 3 повторяются до тех пор, пока не будет закодировано изображе-
ние с полным разрешением.
688
Глава 21. Сжатие с потерями
Иерархический режим применяется, когда изображение может использовать-
ся приложениями с различными возможностями разрешения, в частности устрой-
ством с низким разрешением (у которого нет буфера для восстановления изобра-
жения с полным разрешением) и последующим масштабированием изображения
для отображения на дисплее с низким разрешением.
JPEG 2000
Стандарт JPEG представляет собой наиболее распространенный стандарт сжатия
изображений с реалистичным воспроизведением цвета и плавно изменяющимся
тоном. Хотя этот стандарт обеспечивает достаточно высокое качество при неболь-
ших и умеренных коэффициентах сжатия, при более сильном сжатии качество
изображений резко падает. Группа экспертов JPEG выпустила вторую версию это-
го стандарта, известную как JPEG 2000, обладающую лучшими характеристика-
ми сжатия и значительно большей гибкостью, чем старый стандарт JPEG. Наибо-
лее замечательное отличие нового стандарта заключается в принципиально другом
алгоритме сжатия. В стандарте JPEG используется дискретное косинусное преоб-
разование, побочный эффект применения которого заключается в плохом воспро-
изведении на рисунке резких переходов. Этого эффекта нет в стандарте JPEG 2000,
в котором применяется сжатие на основе элементарных волн.
Ключевые характеристики стандарта JPEG 2000 перечислены далее.
♦ Формат с переменным разрешением. Изображение хранится с несколькими
разрешениями без избыточности. Пропускная способность линий может
экономиться за счет передачи изображений с более низким разрешением.
♦ Область интереса (Region Of Interest, ROI). Стандарт JPEG 2000 предостав-
ляет возможность кодирования области изображения произвольной формы
с более высоким качеством (вплоть до использования сжатия без потерь),
а также при прогрессивной передаче данной ROI-области прежде остальной
части изображения.
♦ Произвольный доступ. Стандарт JPEG 2000 предоставляет возможность до-
ступа к любой области изображения без распаковки всего изображения.
На рис. 21.16 показаны основные элементы типичных кодирующего и декоди-
рующего модулей JPEG 2000. Если компоненты исходного изображения (напри-
мер, компоненты цвета или данные, сгенерированные многополосными сенсора-
ми) не годятся для сжатия, в стандарте JPEG 2000 может дополнительно перед
сжатием использоваться компонентное преобразование (component transform).
Например, изображение формата RGB (Red, Green, Blue — красный, зеленый,
синий) может быть преобразовано в формат YUV, который значительно легче сжи-
мается. Определены как обратимый, так и необратимый (то есть подверженный
ошибкам округления) алгоритмы. Остальная часть кодирующей схемы работает
индивидуально с каждым компонентом.
Основная работа по сжатию осуществляется путем дискретного волнового пре-
образования (Discrete Wavelet Transform, DWT). Чтобы оптимально представить
21.3. Стандарт JPEG
689
сигнал с помощью элементарных волн, все изображение сканируется в поисках
материнской волны, оптимально соответствующей данному изображению. Одна-
ко материнскую волну требуется передавать вместе с данными изображения, что
увеличило бы размер сжатого файла. Вместо этого используется универсальная
материнская волна. Стандарт JPEG 2000 позволяет достичь коэффициента сжа-
тия до 200:1 для сжатия с потерями и 2:1 для сжатия без потерь.
изображение изображение
Хранение
или передача
I
Сжатое
изображение
Восстановленное
изображение
Рис. 21.16. Блок-схема алгоритма JPEG 2000
Затем полученные в результате волнового преобразования коэффициенты
квантуются. Как и при любом процессе квантования, качество воспроизведения
тем выше, чем больше количество уровней квантования.
После квантования каждый поддиапазон разделяется на прямоугольные обла-
сти, называемые кодовыми блоками (code blocks), как правило, 64 х 64 или 32 х 32.
Каждый кодовый блок кодируется независимо без потерь данных при помощи од-
ной из разновидностей арифметического кодирования (см. раздел 20.3). Арифме-
тическое кодирование выполняется таким образом, что младшие входные биты
легко отбросить. Это эквивалентно большему шагу квантования.
На последнем этапе кодирования сжатые данные всех кодовых блоков органи-
зуются в уровни путем распределения частоты. Последовательные уровни содер-
жат дополнительные сжатые данные от некоторых или от всех кодовых блоков.
Если декодируются только некоторые уровни, то получается изображение с более
низким качеством. Как правило, качество означает меру искажения или разреше-
ния, однородную по всему изображению, но оно может быть различным для раз-
ных областей изображения.
690
Глава 21. Сжатие с потерями
21.4. Стандарт MPEG
Движущееся изображение представляет собой просто последовательность непо-
движных картинок. Соответственно, можно добиться определенного уровня сжа-
тия, независимо сжимая каждый неподвижный кадр последовательности, образу-
ющей движущуюся картину. Но можно добиться большего. Даже в фильме с очень
динамичными сценами различие между соседними кадрами в общем случае не-
велико по сравнению с количеством информации, содержащейся в отдельном кад-
ре. В результате можно предположить, что кодирование разницы между соседни-
ми кадрами позволит добиться существенных успехов в сжатии. Именно эта идея
используется в стандарте MPEG.
Под покровительством ISO группа экспертов по движущимся изображениям
(Motion Pictures Experts Group, MPEG) разработала стандарты для видеоизобра-
жения и ассоциированного с ним звука в цифровой форме. Эти цифровые данные
могут храниться на любых устройствах, таких как компакт-диски, магнитные лен-
ты и оптические диски с возможностью записи, а также передаваться по каналам
связи, таким как ISDN и локальные сети. Стандарт MPEG покрывает не только
видеосжатие, но также и сжатие звука и ассоциируемые с ними системные вопро-
сы и форматы. Успех стандарта MPEG объясняется том, что видеосигнал может
быть сжат до скорости передачи данных 1,5 Мбит/с при приемлемом качестве.
Знакомство с алгоритмом видеосжатия
Большая часть функций сжатия, реализованных в стандарте MPEG, очень близка
к функциям стандарта JPEG. Это видно по блок-схеме алгоритма MPEG, пред-
ставленной на рис. 21.17 с использованием следующих обозначений:
♦ DCT (discrete cosine transform) — дискретное косинусное преобразование;
♦ Q (quantizer) — квантование;
♦ VLC (variable length coder) — формирование кода переменной длины;
♦ FM (frame memory) — буфер кадра;
4 ME (motion estimator) — оценка движения.
На вход модуля сжатия MPEG поступает последовательность видеокадров.
Каждый кадр обрабатывается отдельно как независимое неподвижное изображе-
ние. При обработке отдельного кадра алгоритм кодирования MPEG находится во
внутрикадровом режиме. В этом режиме кадр сначала отображается в частотную
область путем дискретного косинусного преобразования, затем квантуется, а ре-
зультат кодируется методом Хаффмана.
Хотя за счет простой обработки видеосигнала как последовательности непо-
движных изображений методом JPEG можно добиться значительного сжатия, при
таком способе сжатия не используется существенная избыточность, присутству-
ющая в видеосигнале. Как правило, многие пикселы от кадра к кадру меняются
очень мало или не меняются вообще либо изменения просто заключаются в сме-
щении блока пикселов в кадре. Исследования группы MPEG показали, что ис-
пользование этой избыточности в межкадровом режиме позволяет дополнитель-
но сжать данные в три раза [89].
21.4. Стандарт MPEG
691
Рис. 21.17. Блок-схема алгоритма MPEG
В межкадровом режиме сходные блоки пикселов, общие для двух последова-
тельных кадров, заменяются указателем, ссылающимся на один из этих блоков.
Основная трудность заключается в порядке следования кадров. Иногда бывает
удобно ссылаться на блок предыдущего кадра, иногда на блок следующего. Про-
цедура распаковки, прежде чем отобразить кадры, должна расположить их в пра-
вильном порядке.
В процессе работы межкадрового алгоритма после дискретного косинусного пре-
образования и квантования кадр проходит через обратный процесс (деквантоваиие,
обратное дискретное косинусное преобразование), чтобы получить кадр, идентичный
тому, который будет получен алгоритмом распаковки. Затем этот кадр сохраняется
и используется в межкадровом режиме для сравнения с последующими кадрами.
При разработке алгоритма видеосжатия группа MPEG отметила ряд характе-
ристик, важных для ряда приложений стандарта MPEG. Две из этих характерис-
тик имеют отношение к нашему обсуждению:
4 - Произвольный доступ. Сжатый видеопоток должен предоставлять доступ к
любой точке последовательности видеокадров. Любой кадр должен декоди-
роваться за ограниченное времени. Это предполагает наличие кадров до-
ступа, то есть кадров, закодированных только во внутрикадровом режиме,
и поэтому такие кадры могут распаковываться без ссылок на другие кадры.
♦ Быстрая перемотка вперед и назад. Должна предоставляться возможность
сканирования сжатого битового потока и отображения отдельных кадров
(с помощью соответствующих кадров доступа), чтобы создавался эффект
быстрой перемотки вперед или назад. Эта возможность, по сути, представ-
ляет собой более сложную форму произвольного доступа.
Компенсация движения
В основе межкадрового сжатия алгоритма MPEG лежит так называемая компенса-
ция движения (motion compensation). Идея компенсации движения заключается
в том, что часть изображения в кадре остается неизменной или очень мало отлича-
692
Глава 21. Сжатие с потерями
ется от соответствующей части соседнего кадра. В алгоритме MPEG используются
две формы компенсации движения: предсказание и интерполяция.
Предсказание
В алгоритме MPEG для компенсации движения используются блоки по 16 х 16
пикселов, называемые макроблоками (в отличие от меньших по размеру блоков
8x8 пикселов, используемых при дискретном косинусном преобразовании). Об-
рабатываемый в режиме предсказания кадр разделяется на макроблоки, каждый
из которых кодируется отдельно. Кодирование выполняется при помощи ссылки
на так называемый якорный кадр (anchor frame), предшествующий текущему.
Каждый макроблок текущего кадра должен быть представлен указателем, назы-
ваемым вектором движения (motion vector), на этот макроблок в якорном кадре,
наиболее близко совпадающий с данным макроблоком. Вектор движения содер-
жит информацию о расположении макроблока в текущем кадре относительно со-
ответствующего макроблока в якорном кадре. В примере, показанном на рис. 21.18,
каждый видеокадр состоит из 64 х 64 пикселов, сгруппированных в 16 макробло-
ков. Затененная часть текущего кадра представляет собой макроблок, чей левый
верхний пиксел находится в позиции (16, 8). Этому блоку соответствует блок в
предыдущем кадре с координатами (24,4). Короткая стрелка в левом кадре изоб-
ражает вектор движения, который в данном случае равен (8, -4).
Распакованный
Ключевые аспекты прогностического кодирования перечислены далее:
♦ Соответствующий макроблок в предыдущем кадре не обязан находиться на
16-пиксельной границе макроблоков.
♦ Совпадающие макроблоки ищутся не в оригинальном видеопотоке, а в кад-
рах, уже подвергшихся сжатию и распаковке, так как у распаковывающего
модуля нет доступа к исходным видеокадрам.
Найдя совпадающий блок в предыдущем кадре, алгоритм MPEG записывает
вектор движения и ошибку предсказания, представляющую собой матрицу 16x16
разностей между текущим макроблоком в кадре с и опорным макроблоком г.
Ес(х, у) = 1,(х, у) - Л[(х, у) + Мп].
21.4. Стандарт MPEG
693
min
теМ
Здесь Ес(х, у) представляет собой ошибку предсказания, 1,(х, у) — значение
пиксела, расположенного в позиции (х, у) в кадре i, а М,, — вектор движения для
кадра j относительно кадра i.
Таким образом, текущий кадр преобразуется в матрицу ошибок предсказания,
каждое значение которой соответствует одному пикселу, и векторы движения, по
одному для каждого макроблока. В матрице предсказаний будет много нулевых
значений. Эта матрица кодируется путем дискретного косинусного преобразова-
ния, в результате чего должен достигаться более высокий уровень сжатия, чем при
применении этого преобразования напрямую к оригинальному кадру.
Стандартом MPEG не определяется способ поиска соответствий. Как правило,
вектор движения макроблока получается при минимизации оценочной функции,
измеряющей разность между макроблоком и каждым кандидатом из предыдуще-
го кадра. Эти вычисления могут быть представлены формулой
У C\Ic(x,y)- Ir((x,y)+ т)] .
Здесь:
♦ В, - макроблок в текущем кадре Л;
♦ т — вектор перемещения относительно опорного кадра I,;
♦ М — диапазон поиска в опорном кадре;
♦ С — оценочная функция.
Значение т, минимизирующее предыдущее выражение, используется в каче-
стве вектора движения Мп для этого блока. Диапазон поиска может распростра-
няться на весь кадр, а может быть ограничен небольшим смещением.
Интерполяция
Хотя метод предсказания позволяет получить более высокие коэффициенты сжа-
тия, чем простое покадровое сжатие, алгоритм JPEG позволяет достичь большего.
В частности, можно кодировать некоторые кадры с помощью двух опорных кад-
ров, предыдущего и последующего. Такой подход, называемый двунаправленной
интерполяцией (bidirectional interpolation), дает возможность получать более высо-
кие коэффициенты сжатия, чем при использовании всего одного опорного кадра.
Чтобы понять, как двунаправленная интерполяция позволяет добиться лучших
результатов, рассмотрим сцену, двигающуюся относительно кадра со скоростью
пол-пиксела за кадр. Мы не сможем найти соответствующий макроблок в теку-
щем кадре на основе предыдущего кадра. Однако среднее значение из предыдущего
и последующего кадров обеспечивает точное совпадение, причем матрица ошибок
будет вся состоять из нулей.
Рисунок 21.19 иллюстрирует метод, используемый при двунаправленной интер-
поляции. Текущий кадр, называемый В-кадром, обрабатывается по двум опорным
кадрам: предшествующему и последующему. Каждый макроблок может кодиро-
ваться на основании предыдущего кадра (предсказание вперед), следующего кад-
ра (предсказание назад) или обоих кадров (усреднение) в зависимости от того,
какой метод дает минимальную матрицу ошибок. В табл. 21.1 приведены форму-
694
Глава 21. Сжатие с потерями
лы для каждого варианта, при этом цифрой 1 обозначается текущий кадр, 0 — пред-
шествующий опорный кадр, 2 — последующий опорный кадр, az — вектор (х, у).
Предсказание вперед
Двунаправленное предсказание
Очередность передачи
142365J87
ipbbpb!ib
Группа изображений
Рис. 21.19. Пример двунаправленной интерполяции
Таблица 21.1. Режимы предсказания макроблоков в В-кадре
Режим Предсказание
Предсказание вперед /,(z) = /o(z + Moi)
Предсказание назад /,(z) = /2(z + M2l)
Усреднение /, (z) = (/o(z + MC1) + /2(z + M21))/2
В случае двунаправленной интерполяции должно быть закодировано большее
количество информации. Как и для кадров, ссылающихся на один опорный кадр,
формируется разностная матрица, которая затем кодируется путем дискретного
косинусного преобразования. Кроме того, в каждом макроблоке указываются ре-
жим предсказания (вперед, назад, усреднение) и один или два вектора движения.
Упорядочивание кадров
Стандартом MPEG определены три типа кадров:
1-кадр (intraframe — внутренний кадр). Независимое неподвижное изобра-
жение, закодированное алгоритмом JPEG.
21.4. Стандарт MPEG
695
♦ Р-кадр (predicted frame — предсказанный кадр). Кадр, закодированный с уче-
том предыдущего якорного кадра.
♦ В-кадр (bidirectional interpolated frame — кадр после двунаправленной ин-
терполяции). Кадр, закодированный с учетом предыдущего и следующего
якорных кадров.
Относительную частоту, с которой эти типы кадров встречаются в видеопотоке,
можно настраивать. Это требуется, во-первых, чтобы предоставить возможность
произвольного доступа и быстрой перемотки вперед и назад, что накладывает ниж-
нюю границу на долю 1-кадров в кодированном потоке. Во-вторых, существует
компромисс между сложностью вычислений и количеством В-кадров: чем больше
В-кадров, тем больше потребуется вычислений. Наконец, В-кадры могут обраба-
тываться только относительно 1-кадров и Р-кадров, то есть один В-кадр не может
служить опорным кадром для другого В-кадра. Поэтому чем выше доля В-кадров,
тем больше среднее расстояние между В-кадром и его опорными кадрами и тем
меньше корреляция между В-кадром и его опорными кадрами.
Правила кодирования выглядят следующим образом. Каждый 1-кадр кодиру-
ется только при помощи внутрикадрового метода (JPEG). Каждый Р-кадр коди-
руется на основе ближайшего предыдущего 1-кадра или Р-кадра. Каждый В-кадр
кодируется на основе двух ближайших 1-кадров или Р-кадров.
Кадры MPEG организуются в группы. Каждая группа состоит из одного 1-кад-
ра, за которым следует несколько Р-кадров или В-кадров. Поскольку В-кадр не
может быть декодирован, пока не будут декодированы оба опорных кадра, члены
группы реорганизуются таким образом, что оба опорных кадра передаются перед
В-кадром. В примере на рис. 21.19 первые шесть кадров образуют группу. После
кадра 1 сохраняется кадр 4, так как он используется в качестве опорного для
В-кадров 2 и 3. Кадры 5 и 6 меняются местами по той же причине. В-кадр 7 запи-
сывается как часть следующей группы, потому что он кодируется на основе опор-
ного 1-кадра 8.
Стандарты MPEG
Работа над стандартом MPEG началась в 1988 г. С тех пор было выпущено несколь-
ко стандартов MPEG.
♦ MPEG-1. Это первый интегрированный стандарт кодирования аудио- и
видеоданных. Он позволяет кодировать движущееся изображение вместе
со звуком. Полученные данные могут храниться на любом цифровом но-
сителе достаточной емкости или передаваться по каналу со скоростью до
1,5 Мбит/с. Этот стандарт получил широкое распространение. Он включа-
ет подраздел Audio Layer 3, также известный как MP3, касающийся кодиро-
вания стереозвука.
♦ MPEG-2. В стандарте MPEG-1 недоставало методов, необходимых для под-
держания стандартного телевещания с чересстрочной разверткой и хорошим
сжатием. Эти средства были добавлены в стандарт MPEG-2. В настоящее
время этот стандарт широко применяется в цифровом телевидении и DVD.
696
Глава 21. Сжатие с потерями
♦ MPEG-4. Изначально стандарт MPEG-4 предназначался для поддержки
приложений с очень низкой скоростью передачи данных, таких как мобиль-
ная связь и модемная связь через Интернет. Однако он развился в мощный
и гибкий набор инструментов для широкого спектра приложений. Ключе-
вая особенность стандарта MPEG-4 состоит в способности кодирования от-
дельных объектов. Это позволяет пользователям взаимодействовать с вир-
туальными объектами, которые могут быть синтезированны из реальных
объектов средствами компьютерной графики.
♦ MPEG-7. Этот стандарт считается интерфейсом описания содержания в муль-
тимедиа. В отличие от трех предыдущих стандартов, MPEG-7 не описывает
методы кодирования аудиовизуальных данных. Вместо этого он предостав-
ляет информацию о содержании аудиовизуальных данных, закодированных
с помощью алгоритма MPEG. Стандарт MPEG-7 обеспечивает быстрый и
гибкий поиск материала, в котором может быть заинтересован пользователь.
♦ MPEG-21. Это мультимедийный рамочный стандарт, предназначенный для
описания среды, поддерживающей доставку и использование всех типов
данных различными категориями пользователей в нескольких прикладных
доменах.
21.5. Рекомендуемые литература
и веб-сайты
В [39] предоставляется интересный обзор волнового анализа. Всем не знакомым с
этой темой стоит прочесть книгу [116]. Эта замечательная книга была написана
для читателей, не обладающих специальными знаниями в технических областях,
но в ней содержится достаточно много технических подробностей. Еще две книги
по этой теме — [166] и [227]. В [235] содержится пространный обзор волнового
метода сжатия изображений.
В [228] предоставляется хороший обзор алгоритма JPEG, а в [178] данный во-
прос описывается очень подробно, включая полный текст стандарта. В [66] предо-
ставляется общий обзор алгоритма JPEG 2000, а [49] является детальным техни-
ческим описанием алгоритма JPEG 2000.
В [89] содержится хорошее описание стандарта MPEG. [48] представляет со-
бой краткий обзор всех стандартов MPEG. В [140] представляется обзор стан-
дарта MPEG-4. В [20] и [21] содержится более детальное обсуждение этого вопро-
са. В [161] и [162] детально описывается стандарт MPEG-7.
Подробное техническое описание обоих алгоритмов, JPEG и MPEG, имеется
также в 1167]. В [186] есть очень подробное техническое описание алгоритмов JPEG
и MPEG, а также детальное обсуждение вопросов реализации.
Рекомендуемые веб-сайты перечислены далее.
♦ Wavelet resources. Сайт, поддерживаемый компанией MathSoft. Включает
множество статей, учебных материалов и ссылок.
♦ Wavelet compression. Ссылки и документы по теме волнового сжатия.
21.6. Задания
697
4 - JPEG homepage. Домашняя страничка комитета разработки стандартов JPEG.
Включает документы, учебные материалы и ссылки.
♦ MPEG site. Исчерпывающий список ссылок па сайты, относящиеся к стан-
дарту MPEG, включающие продукты, программное обеспечение, видеофай-
лы, объявления, ответы на часто задаваемые вопросы и техническую инфор-
мацию.
21.6. Задания
1. Для примера на рис. 21,1 вычислите дискретное косинусное преобразование
для отсчетов яркости (см. рис. 21.1, б). Сравните полученный результат с дис-
кретным косинусным преобразованием (см. рис. 21.1, с).
2. Рассмотрим пример двумерного волнового преобразования из раздела 21.2.
а) пусть пороговое значение сжатия е = 1. Покажите матрицу волнового
преобразования;
б) по результатам предыдущего вопроса выполните обратное преобразова-
ние. Сравните результат с исходной матрицей Р, начертив две матрицы
яркости;
в) повторите оба предыдущих упражнения для е = 2.
3. Обоснуйте JPEG-предсказания, представленные на рис. 21.15, в.
4. На блок-схеме алгоритма MPEG на рис. 21.17 межкадровая обработка вклю-
чает сравнение текущего кадра с обработанными копиями предыдущих кад-
ров (DCT(Q(Q '(DCT I(F))))). Почему не сравниваются исходные кадры?
Приложение А
Стандарты и организации
по стандартизации
Есть собаки, которые не допускают неуважительного отно-
шения к тому, что почитают важным. Например, прекрасная
и очень серьезная немецкая овчарка, с которой я работала, гром-
ко ворчала на других собак, когда те отказывались выполнять
команды инструктора. Натаскивая ее, я однажды, смеха ради, с
одной стороны поноски прицепила груз. Овчарка неодобри-
тельно посмотрела на груз и на меня, затем аккуратно передви-
нула его в центр поноски и только потом понесла мне ее с весь-
ма недовольным видом.
Вики Хирн. Задача Адама: Называя животных ио имени
Стандарты, часто упоминаемые в этой книге, очень важны. В данном приложении
представляются некоторые исторические сведения, касающиеся разработки стан-
дартов, а также перечисляются основные организации, занимающиеся разработ-
кой стандартов в области сетей и связи.
А. 1. Важность стандартов
Необходимость в разработке стандартов для описания физических, электрических
и процедурных характеристик оборудования связи уже давно осознана в индус-
трии телекоммуникаций. В прошлом в компьютерной промышленности этой
точки зрения не разделяли. Когда производители компьютерного оборудования
осознали, что их оборудование будет взаимодействовать с оборудованием других
производителей, они, как обычно, попытались монополизировать своих клиентов.
Распространение компьютеров и распределенная обработка сделали эту позицию
неприемлемой. Компьютеры различных производителей должны общаться друг с
другом, и при продолжающейся эволюции протоколов связи клиенты не станут
мириться с необходимостью иметь специальное программное обеспечение для пре-
образования протоколов. Как результат — стандартизацией теперь охвачены все
технологии, описываемые в данной книге.
A.2. Стандарты и регулирование
699
С процессом стандартизации связан ряд положительных и отрицательных
аспектов. Главные достоинства стандартов состоят в следующем:
♦ Стандарт гарантирует большой сектор рынка для определенного типа обо-
рудования или программного обеспечения. Это поощряет массовое произ-
водство и в некоторых случаях использование методов интеграции высоко-
го и сверхвысокого уровня, что приводит к снижению цен.
♦ Стандарт обеспечивает взаимодействие устройств, разработанных различ-
ными производителями, что обеспечивает большую гибкость при выборе и
использовании оборудования.
Ниже перечислены основные недостатки стандартов:
Стандартизация ведет к замораживанию технологии. За то время, пока стан-
дарт разрабатывается, проходит проверку, согласуется, пересматривается
и, наконец, публикуется, могут появиться новые, более эффективные тех-
нологии.
♦ Существует множество стандартов, относящихся к одной и той же области
деятельности. Это не является недостатком самих стандартов, а отражает
сегодняшнюю технологию стандартизации. К счастью, в последние годы
многие организации, занимающиеся разработкой стандартов, начали тесно
сотрудничать. Тем не менее, существуют сферы, в которых стандарты ино-
гда конфликтуют друг с другом.
А.2. Стандарты и регулирование
Читателю следует различать следующие три понятия:
♦ добровольные стандарты;
♦ регулирующие стандарты;
♦ регулятивное использование добровольных стандартов.
Добровольные стандарты разрабатываются организациями, производящими
стандарты, описываемыми в данном приложении. Они являются добровольными
в том смысле, что их существование не делает обязательным их применение. То
есть производители добровольно создают продукт, соответствующий стандарту,
если они видят в этом выгоду для самих себя. Никаких юридических обязательств
в этом нет. Эти стандарты также являются добровольными в том смысле, что они
были разработаны добровольцами, предпринимаемые усилия которых не оплачи-
вались организацией, производящей стандарты и управляющей этим процессом.
Эти добровольцы являются служащими заинтересованных организаций, напри-
мер производителей и государственных организаций.
Работоспособность добровольных стандартов объясняется тем, что, как прави-
ло, эти стандарты разрабатывались на основе широкого консенсуса и что потре-
бительский спрос на стандартизированные продукты поощрял применение этих
стандартов производителями.
Регулирующие стандарты, напротив, разрабатываются государственными ре-
гулятивными управлениями для достижения определенной общественной цели,
700
Приложение А. Стандарты и организации по стандартизации
например в области экономики, здравоохранения или безопасности. Эти стандар-
ты обладают регулятивной силой и должны выполняться производителями в кон-
тексте применения данных предписаний. Общеизвестными примерами регулятив-
ных стандартов являются пожарный или санитарный кодексы. Но предписания
могут применяться к широкому' спектру продуктов, включая компьютеры и сред-
ства связи. Например, Федеральная комиссия связи США занимается регулиро-
ванием в области электромагнитных излучений.
Регулятивное использование добровольных стандартов — относительно новое
или, по меньшей мере, недавно ставшее превалирующим явление. Типичный при-
мер этого — предписание, требующее от государственных организаций, чтобы они
приобретали только продукт, соответствующий некоторому набору добровольных
стандартов. У такого подхода есть ряд достоинств:
♦ Он уменьшает бремя производства стандартов, лежащее на государственных
организациях.
♦ Он поощряет сотрудничество между государством и организациями по стан-
дартизации в области производства стандартов широкого применения.
♦ Он уменьшает число стандартов, которые должны выполнять произво-
дители.
А.З. Стандарты Интернета и Общество
Интернета
Многие протоколы, образующие набор протоколов TCP/IP, уже стандартизи-
рованы или находятся в процессе стандартизации. По общему соглашению, за раз-
работку и публикацию этих стандартов отвечает организация, называющаяся Об-
ществом Интернета (Internet Society). Общество Интернета представляет собой
состоящую из профессионалов организацию, надзирающую за множеством коми-
тетов и рабочих групп, занятых разработкой и стандартизацией для Интернета.
В этом разделе представляется краткое описание способа разработки стандар-
тов для набора протоколов TCP/IP.
Организации Интернета и публикация RFC
Общество Интернета представляет собой координационный комитет, занимающий-
ся разработками для Интернета, инженерной поддержкой Интернета и управле-
нием Интернетом. Сфера интересов Общества Интернета включает работу самой
сети Интернет и стандартизацию протоколов, обеспечивающих взаимодействие
оконечных систем в Интернете. За фактическую разработку и публикацию стан-
дартов отвечают три организации, входящие в Общество Интернета:
♦ Совет по функционированию Интернета (Internet Activities Board, IAB) от-
вечает за определение архитектуры Интернета в целом, обеспечивая общее
руководство группой IETF.
А.З. Стандарты Интернета и Общество Интернета
701
♦ Проблемная группа инженерной поддержки Интернета (Internet Engineering
Task Force, IETF) — рабочий орган Интернета, занимающийся разработкой
и инженерной поддержкой протоколов для Интернета.
♦ Ведущая группа инженерной поддержки Интернета (Internet Engineering
Steering Group, IESG) отвечает за техническое руководство деятельностью
группы IETF и управление процессом стандартизации в Интернете.
Фактическая разработка новых стандартов и протоколов для Интернета вы-
полняется рабочими группами, создаваемыми по разрешению группы IETF. Член-
ство в рабочей группе является добровольным; участвовать может любая заинте-
ресованная организация. При разработке спецификации рабочая группа создает
документ под названием «Проект стандарта для Интернета» (Internet draft) и раз-
мещает его в Интернете для всеобщего доступа. Этот документ может оставаться
проектом до шести месяцев, и заинтересованные стороны могут рецензировать и
комментировать его. В течение этого времени группа IESG может одобрить пуб-
ликацию проекта в виде документа RFC (Request for Comment — запрос ком-
ментариев). Если проект не приобретает статуса документа RFC в течение шес-
тимесячного периода, он теряет также статус проекта стандарта для Интернета.
Однако впоследствии рабочая группа может опубликовать переработанную вер-
сию проекта.
Группа IETF публикует документы RFC с одобрения группы IESG. Докумен-
ты RFC представляют собой рабочие записи сообщества исследователей и разра-
ботчиков Интернета. Документ этой серии может быть чем угодно, от доклада о
собрании до спецификации стандарта.
Работа группы IETF охватывает восемь сфер деятельности, каждая нз которых
имеет собственного директора и каждую из которых курирует множество рабочих
групп. В табл. А.1 приведены список сфер деятельности группы IETF и направле-
ние их работы.
Таблица А.1. Сферы деятельности IETF
Сферы деятельностиIETF Тема Примеры рабочих групп
Общая Деятельность группы IETF Общая политика; Подготовка стандартов для Интернета
Приложения Интернет-приложения Web-протоколы (HTTP); Интеграция EDI и Интернета; Протокол LDAP
Интернет Инфраструктура Интернета IPv6; Расширения протокола РРР
Деятельность Стандарты и определения Протокол SNMPv3;
и управление для работы сети Удаленный мониторинг сети
Маршрутизация Протоколы и управление информацией о маршрутах Маршрутизация при групповой рассылке; Алгоритм OSPF Маршрутизация с дифференцированным качеством обслуживания
продолжение^
702
Приложение А. Стандарты и организации по стандартизации
Таблица А.1. Сферы деятельности IETF
Сферы Тема деятельности IETF Примеры рабочих групп
Безопасность Протоколы и технология безопасности Kerberos; IPSec; Х.509; S/MIME; TLS
Транспорт Протоколы транспортного уровня Дифференцированные службы; IP-телефония; NFS; RSVP
Пользовательские службы Методы повышения качества информации, доступной пользователям Интернета Ответственное использование Интернета; Пользовательские службы; Документы «к вашему сведению»
Процесс стандартизации
Решение о том, которые из документов RFC становятся стандартами Интернета,
принимает группа IESG на основании рекомендации группы IETF. Чтобы стать
стандартом, спецификация должна удовлетворять следующим критериям:
♦ неизменность и понятность;
4- техническая компетентность;
4- наличие существенного опыта внедрения и взаимодействия;
4- значительная общественная поддержка;
4- ощутимая полезность в некоторых или во всех областях Интернета.
Ключевое отличие данных критериев от используемых в международных стан-
дартах, разрабатываемых союзом ITU, заключается в наличии пункта об обяза-
тельном опыте применения.
В левой части рис. А.1 показаны этапы, которые проходит спецификация на
пути к стандарту. Этот процесс определяется в RFC 2026. Данные этапы включают
существенное количество наблюдений и тестирования. На каждом этапе группа
IETF должна сформировать рекомендацию для продвижения протокола, а группа
IESG — утвердить ее. Процесс начинается с того момента, когда группа IESG одоб-
ряет публикацию проекта стандарта Интернета, переводя его в разряд документа
RFC со статусом предложенного стандарта.
Белыми прямоугольниками на диаграмме изображаются промежуточные (вре-
менные) состояния документа, которые он должен миновать как можно быстрее.
Тем не менее, документ должен оставаться предложенным стандартом по мень-
шей мере шесть месяцев, а черновым стандартом — как минимум, четыре месяца,
чтобы предоставить время для пересмотра и комментариев. Серые прямоугольни-
ки означают долговременные состояния, в которых документ может находиться
годами.
Чтобы спецификация могла получить статус чернового стандарта, должны
появиться по меньшей мере две независимые реализации, способные взаимо-
А.З. Стандарты Интернета и Общество Интернета
703
действовать друг с другом, и должен быть накоплен достаточный опыт работы
с ними.
После накопления достаточного объема экспериментального материала по функ-
ционированию описываемого в документе программного или аппаратного обеспе-
чения спецификация может получить статус стандарта Интернета. В этот момент
спецификации присваивается номер стандарта, а также номер RFC.
Когда протокол устаревает, он переводится в разряд исторических документов.
Категории стандартов Интернета
Стандарты Интернета распадаются на две категории:
♦ Техническая спецификация (Technical Specification, TS) определяет прото-
кол, службу, процедуру, соглашение или формат. Основная часть Иитернет-
стандартов представляет собой технические спецификации.
♦ Технические условия (Applicability Statement, AS) указывают, как и при каких
условиях может применяться одна или несколько технических специфика-
ций для поддержания определенной функции Интернета. В технических
условиях идентифицируется одна или несколько технических специфика-
ций, относящихся к данной функции, а также могут указываться значения
или диапазоны значений определенных параметров, касающихся техничес-
кой спецификации или функциональных подмножеств технической специ-
фикации, имеющих отношение к данной функции.
704
Приложение А. Стандарты и организации по стандартизации
Другие типы RFC
Существует множество документов RFC, которым не суждено стать стандартами
Интернета. В некоторых документах RFC стандартизируются результаты прово-
димых Интернет-сообществом обсуждений, касающихся совершенствования ме-
тодов выполнения определенных действий или функций группы IETF. Такие до-
кументы RFC называют документами ВСР (Best Current Practice — оптимальное
установившееся положение дел ). Процесс одобрения документа ВСР, по сути, тот
же самый, что и для предложенного стандарта. Но, в отличие от принятия стан-
дартов, процесс одобрения документа ВСР требует не трех, а всего одного этапа.
Протокол (или другая спецификация), который не считается готовым к стандар-
тизации, может быть опубликован как экспериментальный документ RFC. После
дополнительной работы спецификация может быть снова представлена на рас-
смотрение. Если спецификация в общем стабильна, имеются ее действующие ре-
ализации, написана понятным языком, ей уделяется достаточное внимание со сто-
роны Интер нет-сообщества, чтобы считаться ценной, тогда такому документу RFC
присваивается статус предложенного стандарта.
Наконец, публикуется информационная спецификация для ознакомления с дан-
ным вопросом Интернет-сообщества.
А.4. Союз ITU
Международный союз телекоммуникаций (International Telecommunications Union,
ITU) представляет собой специализированное управление Организации Объеди-
ненных Наций. Таким образом, членами союза ITU являются правительства госу-
дарств. Представительство США расквартировано в государственном департамен-
те. В уставе союза ITU говорится, что он «отвечает за изучение технических и
рабочих вопросов, а также вопросов тарификации и за выпуск рекомендаций по
этим вопросам с целью стандартизации телекоммуникаций во всемирном масшта-
бе». Первейшая цель союза заключается в стандартизации, в необходимых пределах,
методов и операций в области телекоммуникаций для достижения глобальной со-
вместимости международных телекоммуникационных соединений независимо от
стран отправителя и получателя.
Сектор ITU-T
Сектор телекоммуникаций союза ITU, называемый для краткости ITU-T (Inter-
national Telecommunications Union-Telecommunications), был создан 1 марта 1993 г.
в результате процесса реформирования союза 1TU. Он пришел на смену Междуна-
родному консультативному комитету по телефонии и телеграфии (Consultative
Committee for International Telephone and Telegraphy, CCITT), у которого были,
по сути, те же устав и цели, что и у ITU-T. Сектор ITU-T исполняет те задачи со-
юза ITU, которые касаются стандартизации телекоммуникаций, изучая техничес-
кие и рабочие вопросы, а также вопросы тарификации и принимая рекомендации
по ним с целью стандартизации телекоммуникаций во всемирном масштабе.
А.5. Стандарты IEEE 802
705
Сектор ITU-T состоит из 14 занимающихся подготовкой рекомендаций иссле-
довательских групп, пронумерованных (названных) следующим образом:
2. Сети и деятельность служб.
3. Принципы тарификации и учета.
4. Сеть управления телекоммуникациями и управление сетями.
5. Защита от электромагнитных воздействий среды.
6. Внешние сооружения.
7. Сети передачи данных и взаимодействие открытых систем.
9. Интегральные широкополосные сети, а также теле- и радиотрансляция.
10. Языковые и общепрограммные аспекты функционирования телекоммуни-
кационных систем.
11. Требования к сигналам и протоколам.
12. Сквозная пропускная способность сетей и терминалов.
13. Многопротокольные сети и IP-сети, а также их совместная работа.
15. Оптические и другие транспортные сети.
16. Мультимедийные службы, системы и терминалы.
SSG. Специальная исследовательская группа (Special Study Group) для IMT-2000
и др.
Расписание
Работа сектора ITU-T проходит в виде четырехгодичных циклов. Каждые четыре
года собирается Всемирная конференция по стандартизации телекоммуникаций.
На ней утверждается программа работы на следующие четыре года в виде вопро-
сов, представляемых на рассмотрение различными исследовательскими группами
на основе запросов, подаваемых членами групп. Конференция оценивает вопро-
сы, проверяет пределы компетенции исследовательских групп, создает новые или
упраздняет старые исследовательские группы и распределяет среди них вопросы.
На основе этих вопросов каждая группа готовит проекты рекомендаций. Проект
рекомендации может быть представлен на рассмотрение следующей конференции
еще через четыре года. Однако в последнее время все чаще проекты рекомендаций
получают одобрение по мере готовности, не ожидая завершения четырехлетнего
периода. Эта ускоренная процедура была принята после очередного четырехлет-
него периода, закончившегося в 1988 г. Таким образом, 1988 г. стал последним го-
дом, когда большой пакет документов был опубликован одновременно в виде на-
бора рекомендаций.
А.5. Стандарты IEEE 802
Ключ к развитию рынка локальных сетей заключается в доступности недорогого
интерфейса. Стоимость подключения оборудования к локальной сети должна быть
значительно меньше стоимости самого оборудования. Это требование, а также
706 Приложение А. Стандарты и организации по стандартизации
сложность логики локальных сетей диктует решение, основанное на использова-
нии микросхем высокой и сверхвысокой интеграции. Однако производители мик-
росхем с неохотой вводят в дело свои ресурсы, если речь не идет о массовом рын-
ке. Широко распространенный стандарт локальных сетей гарантирует массовость,
а также обеспечивает возможность взаимодействия оборудования различных про-
изводителей. Данным рассуждением руководствуется комитет IEEE 802.
Комитет выпустил набор стандартов, которые были в 1985 г. приняты Амери-
канским национальным институтом стандартов (American National Standards
Institute, ANSI) в качестве национального стандарта США. В 1987 г. эти стандар-
ты были переработаны и переизданы Международной организацией по стандар-
тизации (International Organization for Standardization, ISO) как международные
стандарты с обозначением ISO 8802. С тех пор комитет IEEE 802 продолжает ра-
боту по переработке и расширению этих стандартов, а организация ISO утвержда-
ет новые версии стандартов.
Комитет IEEE 802 довольно быстро пришел к двум выводам. Во-первых, зада-
ча обмена данными по локальной сети является достаточно сложной, поэтому эту
задачу необходимо разбить на несколько более простых задач.
Во-вторых, единый технический подход не способен удовлетворить все требова-
ния. С этим утверждением неохотно пришлось согласиться, когда стало очевидно,
что единый стандарт не сможет удовлетворить всех участников комитета. Требо-
валась поддержка различных топологий, методов доступа и физических носите-
лей. Комитет решил не пытаться останавливаться на одном решении, а стандарти-
зировал все серьезные предложения.
На сегодняшний день работа комитета IEEE 802 организована в рабочих группах.
4- 802.1. Протоколы локальных сетей высокого уровня. Разрабатывает стандар-
ты и рекомендации в следующих областях: архитектура локальных и регио-
нальных сетей 802; объединение локальных и региональных сетей 802 с дру-
гими глобальными сетями; общее управление сетями 802 и протокольные
уровни над уровнями МАС и LLC.
4- 802.2. Управление логическим соединением (Logical Link Control, LLC). В на-
стоящее время не работает.
♦ 802.3. Ethernet. Разрабатывает стандарты для локальных сетей, основанных на
технологии CSMA/CD (Carrier Sense Multiple Access with Collision Detection —
множественный доступ с контролем несущей и обнаружением коллизий).
4- 802.4. Маркерная шина. Разрабатывала стандарта для локальных сетей с мар-
керной шиной (token bus). В настоящее время не работает.
4- 802.5. Маркерное кольцо. Разрабатывает стандарты для локальных сетей, ос-
нованных на технологии маркерного кольца (token ring).
4- 802.6. Региональная сеть (Metropolitan Area Network, MAN). Разрабатыва-
ла стандарты для региональных сетей. В настоящее время не работает.
4- 802.7. Техническая консультативная группа по вопросу широкополосных се-
тей. Разрабатывала рекомендации, стандарт IEEE 802.7-1989, рекомендации
IEEE для широкополосных локальных сетей (вновь подтверждены в 1997 г.).
Эта группа не работает и проектов не разрабатывает. Стандарт IEEE 802.7-1989
получил свое продолжение в виде 802.14.
A.5. Стандарты IEEE 802
707
♦ 802.8. Техническая консультативная группа по волоконной оптике. Разраба-
тывает рекомендации по волоконной оптике.
♦ 802.9. Изохронные локальные сети. Разрабатывает стандарты для изохрон-
ных локальных сетей.
♦ 802.10. Безопасность. Разрабатывает стандарты обеспечения безопасности
для взаимодействующих локальных и региональных сетей.
80 2.11. Беспроводные локальные сети. Разрабатывает стандарты для беспро-
водных локальных сетей.
4- 802.12. Приоритетные запросы. Разрабатывает стандарты для локальных
сетей с приоритетными запросами (lOOVG-AnyLAN).
4- 802.13. Не работает.
4- 802.14. Кабельные модемы. Основана для разработки стандартов передачи
данных по традиционным телевизионным кабельным сетям. Архитектура
представляет собой гибрид оптоволоконного и коаксиального кабеля с про-
тяженностью до 80 км от головного узла. Первоначальная цель сетевого про-
токола заключалась в переносе трафика типа IEEE 802.2 LLC (например,
Ethernet). Однако многие члены рабочей группы считают, что сеть также
должна поддерживать сети ATM для переноса мультимедийного трафика
различных типов.
♦ 802.15. Беспроводные персональные сети. Разрабатывает стандарты для пер-
сональных беспроводных сетей, работающих на коротких расстояниях.
♦ 802.16. Широкополосный беспроводной доступ. Разрабатывает crai щарты для
широкополосного беспроводного доступа.
♦ 802.17. Эластичное пакетное кольцо. Этот стандарт будет определять прото-
кол для сверхвысокоскоростных сетей, оптимизированный для передачи
пакетов в топологиях эластичного кольца (resilient ring) на основе волокон-
ной оптики.
Приложение Б
Сокеты1
Исследователями были опубликованы многочисленные свиде-
тельства тому, как при пении птицы сменяют друг друга. Из
двух птиц всегда поет только одна, а вторая уделяет все свое
внимание поющей, как если бы эти двое поддерживали разговор.
Исследователи и студенты, занимавшиеся изучением данных
по общению птиц, отмечают, что а) коммуникационный код
птиц, например ворон, не удается расшифровать никакими сред-
ствами; б) вероятно, все птицы обладают более широким сло-
варным запасом, чем принято считать; в) по мере продолжения
исследований по теме общения птиц обнаруживается все боль-
шая сложность и глубина.
Теодор Барбер. Разум птиц
Как и программный интерфейс приложений (Application Programming Interface,
API), прикладной программный интерфейс сокетов (Sockets API) предоставляет
библиотеку функций, которую может применять программист для разработки се-
тевых приложений. Функции интерфейса сокетов обеспечивают идентификацию
конечных точек соединения, установку соединения, отправку сообщений, ожида-
ние входящих сообщений, разрыв соединения и обработку ошибок. Выбор конк-
ретного программного интерфейса сокетов зависит от используемой операцион-
ной системы и языка программирования.
Отличительной чертой API сокетов является фактически стандартный интер-
фейс с протоколами TCP/IP, изначально определенный в операционной системе
BSD UNIX, а позднее принятый другими операционными системами. Это откры-
тый стандарт, обеспечивающий переносимость исходного кода программ. Поэто-
му мы рассмотрим всего лишь два наиболее распространенных интерфейса — со-
кеты Беркли (Berkeley Software Distribution sockets, BSD) в том виде, в котором
они были представлены для операционной системы UNIX, и небольшую модифи-
кацию этого интерфейса API — сокеты Windows (Windows Sockets, WinSock) от
корпорации Microsoft.
Материал этой главы предназначается для программистов языка С (к функци-
ям сокетов можно также обращаться из программ, написанных на языках C++,
1 Автор этого приложения — Зорница Генова (zgenova@csee.usf.edu).
Б.1. Версии сокетов
709
Visual Basic и PASCAL). В центре нашего обсуждения будет операционная систе-
ма Windows. В то же самое время читателю будут предоставлены примеры из ори-
гинальной спецификации BSD UNIX, чтобы указать на различия (как правило,
незначительные) в спецификации сокетов в этих двух операционных системах.
Предполагается, что читатель имеет базовые знания о сетевых протоколах TCP/IP
и UDP. Большая часть программ должна транслироваться как в операционной си-
стеме Windows, так и системах семейства UNIX.
В.1. Версии сокетов
Оригинальная спецификация BSD хорошо подходит для операционных систем
семейства UNIX (см. табл. Б.1).
Таблица Б.1. Хорошо известные операционные системы семейства UNIX
Название Описание Производитель
Amoeba Прозрачная распределенная система на основе микроядра Vrije Universiteit of Amsterdam
Angel Общая параллельная и распределенная операционная система City University of London
BSD/OS Основанная на BSD 4.4 UNIX операционная система для х86 PC Berkeley Software Design, Inc.
Chorus Открытая операционная система на основе микроядра Sun Microsystems
FreeBSD Операционная система UNIX, основанная на BSD 4.4 The FreeBSD Project
HURD Операционная система типа Mach на основе микроядра Free Software Foundation GNU Project
Linux Свободно распространяемая реализация для PC с процессором 386, 486 и Pentium Linux Online Inc.
Lites Сервер, основанный на UNIX BSD 4.4-lite, и эмуляционная библиотека, обеспечивающая функциональность UNIX на системах типа Mach Helsinki University of Technology
Mach-US University Разработана как часть проекта CMU МАСН Carnegie Mellon
Maruti Исследовательский проект контролируемой по времени операционной системы University of Mariland
NetBSD Производная от UNIX BSD 4.4-lite The NetBSD Foundation, Inc.
OpenBSD Производная от UNIX BSD 4.4-lite OpenBSD Inc.
QNX Основанная на микроядре, распределенная, реального времени, устойчивая к сбоям, поддерживающая стандарт POSIX операционная система для х86 QNX Software Systems Ltd.
RTMX Производная от UNIX BSD 4.4-lite операционная система реального времени RTMX Inc.
Sprite Распределенная операционная система University of California at Berkeley
710
Приложение Б. Сокеты
Здесь будут описываться исключительно сокеты на языке С, но интерфейс
WinSock API также может использоваться в большинстве других языков програм-
мирования, таких как C++, Visual Basic и PASCAL и т. д. Единственное требова-
ние заключается в том, что язык должен предоставлять возможность обращения к
динамически подключаемым библиотекам (Dynamic Link Library, DLL). В 32-раз-
рядной Windows-среде вам потребуется импортировать библиотеку wsock32.Lib,
чтобы использовать преимущество интерфейса WinSock. Эта библиотека должна
быть скомпонована с программой, чтобы при запуске загрузилась динамическая
библиотека wsock32.dll. Динамическая библиотека wsock32.dll работает поверх стека
протоколов TCP/IP. В операционные системы Windows NT, Windows 2000 и Win-
dows 95 файл wsock32.dll включается по умолчанию. Если во время создания
исполняемый файл компонуется вместе с библиотекой wsock32.lib, тем самым не-
явно присоединяется динамическая библиотека wsock32.dll, загружаемая при за-
пуске программы. То есть для обращения к динамической библиотеке wsock32.dll
не потребуется добавлять строки к исходному файлу. Документацию, статьи, про-
граммное обеспечение и примеры программ по интерфейсу Winsock 1.1 и 1.2 мож-
но найти по адресу http://www.stardust.com/.
Также много полезного по данной теме можно найти на веб-сайте «Windows
Sockets Network Programming» Боба Куинна (Bob Quinn) по адресу http://
www.sockets.com/a_d.htm. Программистам, пишущим программы на языке Visual
Basic, стоит прочитать книгу «Client/Server Programming with Microsoft Visual
Basic», написанную Кеннетом Л. Спенсером (Kenneth L. Spencer) и Кеном Мил-
лером (Ken Miller). Кроме того, коллекцию сетевых компонентов и библиотек для
разработчиков программ на языке Visual Basic можно найти на сайте http://
www.catalyst.com/. Старую, но хорошо известную статью Ральфа Дэвиса (Ralph
Devis) по языку C++ «Win32 Network Programming: Windows 95 and Windows NT
Network Programming Using MFC» вместе с библиотекой классов можно найти на
сайте http://cseng.aw.com./book/author/0,3832,0201489309,00.htmL
Исчерпывающие сведения о родословных операционных систем семейств
UNIX и Windows можно найти на сайтах http://perso/wanadoo.fr/levenez/unix/
и http://perso/wanadoo.fr/levenez/windows.
Б.2. Сокеты, дескрипторы сокетов,
порты и соединения
Сокеты представляют собой конечные точки связи, обращение к которым осуще-
ствляется при помощи соответствующих дескрипторов сокетов или слов есте-
ственного языка, описывающих связь сокета с определенной машиной или прило-
жением (например, мы будем обозначать сокет сервера как server_s). Соединение
(или пара сокетов) состоит из пары IP-адресов, обладатели которых общаются друг
с другом, а также пары номеров портов, где номер порта представляет собой
32-разрядное целое без знака, как правило, в десятичной системе счисления. Неко-
Б.2. Сокеты, дескрипторы сокетов, порты и соединения
711
торые номера портов назначения, называемые хорошо известными портами (well-
known ports), закреплены за популярными службами и определяют тип службы,
с которой осуществляется соединение.
Протоколы TCP/IP ориентируются на то, что приложениями для общения друг
с другом используются хорошо известные порты. При этом клиентские приложе-
ния предполагают, что соответствующее серверное приложение прослушивает
свой хорошо известный порт, ассоциированный с этим приложением. Например,
для протокола HTTP (HyperText Transfer Protocol — протокол передачи гипертек-
ста) используется TCP-порт с номером 80. По умолчанию веб-браузер будет пы-
таться установить соединение с ТСР-портом 80 хоста назначения, если в URL-ад-
ресе не указан другой номер порта (например, 8000 или 8080).
Порт (port) идентифицирует точку соединения в локальном стеке (например,
порт с номером 80, как правило, используется веб-сервером). Сокет (socket) иденти-
фицирует пару, состоящую из IP-адреса и номера порта (например, 192.168.1.20:80
обозначает порт веб-сервера на хосте 192.168.1.20). Пара сокетов (socket pair) иден-
тифицирует все четыре компонента (адреса и номера портов отправителя и полу-
чателя). Поскольку хорошо известные порты уникальны, иногда они используют-
ся для обозначения определенного приложения на любом хосте, на котором может
быть запушено это приложение. Однако употребление слова «сокет» подразуме-
вает конкретное приложение на конкретном хосте. Соединение, или пара сокетов,
означает соединение сокетов между двумя конкретными взаимодействующими
системами. Протокол TCP позволяет одновременно устанавливать несколько
соединений для одного и того же локального порта, если у этих соединений от-
личаются удаленные IP-адреса или номера портов.
Номера портов разделяются на три категории:
4- Номера от 0 до 1023 зарезервированы для хорошо известных портов. Они
ассоциированы со службами на постоянной основе. Например, НТТР-сер-
веры всегда принимают запросы к порту 80.
+ Порты с номерами от 1024 до 49 151 являются регистрируемыми. Они ис-
пользуются для различных целей.
4- Порты с номерами от 49 151 до 65 535 представляют собой динамические и
частные порты. С ними не должны ассоциироваться службы.
В реальности машины начинают назначение динамических портов, начиная с
номера 1024. Если вы разрабатываете протокол или приложение, для которого тре-
буется канал связи, сокет, порт, протокол и т. д., свяжитесь с управлением IANA
(Internet Assigned Numbers Authority — уполномоченная организация по выделению
номеров Интернета). IANA располагается в институте кибернетики (Information
Sciences Institute, ISI) университета Южной Калифорнии. Рекомендация RFC
«Assigned Numbers», опубликованная организацией IANA, является официальной
спецификацией, в которой перечисляются назначения портов. Вы можете найти
ее по адресу http://www.iana.org/assignments/port-nunibers. Список номеров портов
со ссылками на информацию о связанных с ними приложениях предоставляется
по адресу http://advice.networkice.com/advice/Exploits/Ports/.
712 Приложение Б. Сокеты
В обеих операционных системах, UNIX и Windows, для проверки состояния
всех активных локальных сокетов может использоваться команда netstat На рис. Б.1
показан примерный результат работы команды netstat.
Proto / Local .Address ^Foreign Address j State
TCP My comp: 1025 . ./ jMycomp: 0 : :i c \ •LISTENING
TCpJ Mycomp:1026 , jMycomp :0 , ^LISTENING :
TCP Mycomp:6666 c iMycortip: 0 x •LISTENING
TCP i; Mycqmp:6667 _ . jMycomp:0 ^LISTENING
TCP _ Mycomp:1234 ; Unycomp: 1234 ... TIMEWAIT :
TCP .s: Mycomp:1025 i2hfc327.any.com:6667 ^ESTABLISHED
TCP о Mycomp:1026 j46c311 .any. com: 6668 iESTABLISHED
udp ' ? Mycomp:6667 j* & ... . Ч-. f
Рис. Б.1. Пример вывода команды netstat
Б.З. Коммуникационная модель
клиент-сервер
Приложение, использующее сокеты, состоит из программы, исполняемой на обо-
их концах канала связи. Программу, инициирующую передачу, часто называют
клиентом (client). Приложение на другом конце соединения, называемое сервером
(server), представляет собой программу, пассивно ожидающую входящих запро-
сов на установку соединений от удаленных клиентов. Как правило, серверное при-
ложение загружается при запуске системы и активно прослушивает свой хорошо
известный порт, ожидая входящих соединений. Клиентские приложения пытают-
ся установить соединение с сервером, после чего начинается обмен данными по
протоколу TCP. По завершении сеанса связи клиент, как правило, разрывает со-
единение. На рис. Б.2 представлена базовая модель взаимодействия, основанная
на концепции потоков (или сокетов TCP/IP).
Клиент
Сервер
socketf)
I
соппесЦ)
send()/recv()
close() для UNIX close() для UNIX
или closesocketQ для Windows или closesocketQ для Windows
Рис. Б.2. Блок-схема взаимодействия потоковых сокетов
Б.4. Элементы сокетов
713
Запуск программы с сокетами на изолированной
машине под Windows
Если набор протоколов TCP/IP установлен на одной машине, вы можете запус-
тить на ней обе программы, и клиент, и сервер (если набор протоколов TCP/IP не
установлен, то при попытке обращения к сокету можно ожидать возникновения
исключений BindException, ConnectException, ProtocolException, SocketException ит. д.)_
Следует использовать локальный хост в качестве имени хоста или адрес 127.0.0.1
в качестве IP-адреса.
Запуск программы с сокетами на одной
сетевой машине под Windows
Когда клиент и сервер запущены на одной машине, даже соединенной с сетью, вы
будете общаться сами с собой. Важно знать, соединена ли ваша машина с сетью
Ethernet или взаимодействует с сетью через телефонный модем. В первом случае
IP-адрес будет назначен машине без каких-либо усилий с вашей стороны. В слу-
чае общения с сетью через модем вам придется дозвониться, получить 1Р-адрес,
после чего вы сможете «поговорить сами с собой». В обоих случаях вы сможете
узнать IP-адрес машины, которой вы пользуетесь, с помощью команды winipcfg
в операционных системах Win9X или команды ipconfig в операционных системах
WinNT/2Kn UNIX.
Б.4. Элементы сокетов
Создание сокета
#1nclude <sys/types.h>
#include <sys/socket.h>
int socket(1 nt domain. Int type, int protocol)
♦ Константа domain (домен) может принимать значения AF_UNIX, AF_INET, AF_OSI
и т. д. Значение AF_INET позволяет взаимодействовать через объединенную
сеть по IP-адресам. Мы будем использовать только это значение.
♦ Константа type (тип) может принимать одно из следующих значений: SOCK_
STREAM (транспортный протокол TCP, ориентированная на соединение на-
дежная связь), SOCK_DGRAM (транспортный протокол UDP, дейтаграммы,
ненадежная связь) или S0CK_RAW (IP-уровень).
♦ Константа protocol (протокол) определяет протокол. Как правило, значени-
ем этого параметра является 0. Это означает, что задействуется протокол по
умолчанию для выбранных значений домена и типа. В наших примерах все-
гда будет использоваться значение 0.
714 Приложение Б. Сокеты
В случае успеха процедура socket() возвращает дескриптор сокета, представля-
ющий собой целое число, в случае неудачи возвращается -1. Ниже приводится
пример вызова:
if (Csd - socket(AFJNET. SOCKJGRAM. 0) < 0)
{
printf("обращение к socketO завершилось неудачей.'');
exit(l):
)
Адрес сокета
Для хранения адреса в домене AFJNET используется следующая структура:
struct in addr {
unsigned long s_addr;
}:
Структура in_addr просто предоставляет имя типа (s_addr) языка С, которое
может быть ассоциировано с IP-адресом:
struct sockaddrJn {
unsigned short sin_family; // идентификаторы AFJNET
unsigned short sin_port; // номер порта.
// если 0. тогда выбрано ядро
struct in_addr sin_addr: // IP-адрес
// INADDR_ANY ссылается на IP-адреса текущего хоста
char sin_zero[8]: // не используется, всегда ноль
}:
В структуре sockaddrJn объявляются локальный и удаленный адреса. В зави-
симости от этого объявления структура sin_addr будет представлять локальный или
удаленный IP-адрес. (В операционных системах семейства UNIX для использова-
ния обеих структур вам потребуется включить файл <netinet/in.h>.)
Привязка к локальному порту
#define WIN // WIN для Winsock и BSD для сокетов BSD
tfifdef WIN
#include «windows.h> // для всех функций Winsock
#endif
#ifdef BSD
#include <sys/types.h>
#include <sys/socket.h // для структуры sockaddr
#endif
int bindlint local_s, const struct sockaddr *addr. int addrlen):
4- Параметр local s задает дескриптор локального сокета, создаваемый функ-
цией socket().
ii
Б.4. Элементы сокетов
715
♦ Параметр addr представляет собой указатель на структуру, в которой хра-
нится адрес (локальный) этого сокета.
4- Параметр addrlen указывает длину структуры ( в байтах), на которую указы-
вает addr.
Функция bi nd () возвращает 0 в случае успеха и -1 в противном случае. После
обращения к функции bind() с сокетом ассоциируется номер локального порта, но
удаленный порт еще не задан.
Ниже приводится пример вызова:
struct sockaddrjn name:
name.sin_family - AFJNET; И используется Интернет-домен
name.sin_port - htons(O): // порт предоставляется ядром
name.sin_addr.s_addr = htonl(INADDR_ANY); // используются все IP-адреса хоста
If (bind(Iocal_socket. (struct sockaddr *)&narne. sizeof(name)) != 0)
// вывести сообщение об ошибке и завершить работу
Обращение к функции bind() необязательно на клиентской стороне и обязатель-
но для сервера. После обращения к функции bind() мы можем найти ее адресную
структуру по дескриптору сокета с помощью функции getsockname().
Представление данных и порядок
следования байтов
В некоторых компьютерах используется обратный порядок следования байтов.
Это касается представления таких объектов, как целые числа в пределах машинно-
го слова. В компьютерах с обратным порядком следования байтов самый старший
байт целого числа хранится в самом левом байте слова, а самый младший байт целого
числа — в правом байте машинного слова. Таким образом, число 5 • 216 + 6 28 + 4
будет храниться на разных машинах по-разному:
♦ адрес байта в памяти: 0 12 3
♦ прямой порядок байтов: 0 5 6 4
♦ обратный порядок байтов: 4 6 5 0
Как можно видеть, если прочитать слово неверного размера на машине с прямым
порядком следования байтов, мы получим неверный результат. В то же время, на
машине с обратным порядком следования байтов иногда может быть получен верный
результат. Обратный порядок следования байтов, в некотором смысле, является
более естественным для человека, так как мы привыкли читать числа слева направо.
Компьютер Sparc корпорации Sun представляет собой машину с обратным
порядком следования байтов. Когда она общается с компьютером i-386 PC (кото-
рый является машиной с прямым порядком следования байтов), имеет место
следующее несоответствие: компьютер с процессором Intel интерпретирует число
5 • 216 + 6 • 28 + 4 как 4 216 + 6 • 28 + 5. Во избежание такой ситуации набором про-
токолов TCP/IP определен машинно-независимый стандарт порядка следования
байтов в сети. В TCP/IP-пакете данные передаются старшим байтом вперед, что
соответствует прямому порядку следования байтов.
716 Приложение Б. Сокеты
В WinSock для различных значений используется сетевой порядок следования
байтов. Функции htonl(), htons(), ntohl(), ntohs() гарантируют использование пра-
вильного порядка следования байтов в вызовах WinSock API независимо от того,
прямой или обратный порядок следования байтов используется в компьютере.
Для преобразования чисел из одной формы хранения в другую используются
следующие функции:
4- unsigned long /z/orz/(unsigned long ri) — преобразование 32-разрядного целого без
знака из формы его представления на хосте в представление, принятое в сети;
4- unsigned long Atons(unsigned short n) — преобразование 16-разрядного целого без
знака из формы его представления на хосте в представление, принятое в сети;
♦ unsigned long ntohl(\insigned long n) — преобразование 32-разрядного целого без
знака из формы его представления в сети в представление, принятое на хосте;
♦ unsigned long ntofo(unsigned short и) — преобразование 16-разрядного целого без
знака из формы его представления в сети в представление, принятое на хосте.
Установление соединения с сокетом
Удаленный процесс идентифицируется IP-адресом и номером порта. При вызове
функции connect() на локальном сайте делается попытка установить соединение с
удаленным компьютером. Это необходимо в случае связи, ориентированной на
соединение, например при использовании сокетов, основанных на концепции по-
токов (TCP/IP). Иногда функция connect() вызывается также при использовании
дейтаграммных сокетов. Делается это потому, что данная функция сохраняет ло-
кально адрес удаленного компьютера, поэтому нам не нужно впоследствии при
отправке каждой дейтаграммы указывать адрес получателя. В результате вместо
системных вызовов sendto() и recvfrom() мы можем воспользоваться системными
вызовами send() и recv(). Однако такие сокеты не подходят для получения дейта-
грамм от других адресов.
#def1ne WIN
#1fdef WIN
include <w1ndows.h>
#endi f
#ifdef BSD
#1nc1ude <sys/types.h>
#1nclude <net1net/1n.h>
#include <sys/socket.h>
#end1 f
// WIN для Winsock и BSD для сокетов BSD
// необходимо для всех функций Winsock
// необходимо для идентификаторов, определяемных системой
// необходимо для структуры Интернет-адресов
// требуется для socketO. bindO и т. д.
Int connect(int local_s. const struct sockaddr *remote_addr. int rmtaddrjen)
4 local s — дескриптор локального сокета;
4- remote addr — указатель на адрес протокола другого сокета;
4 rmtaddr_len — длина адресной структуры в байтах.
В случае успеха функция connect() возвращает целое число 0. Об ошибке дан-
ная функция в операционной системе Windows сообщает ненулевым значением,
а в операционной системе UNIX — отрицательным значением.
Б.4. Элементы сокетов
717
Ниже приводится пример использования данной функции:
#define PORT_NUM 1050 // произвольный номер порта
struct sockaddr_in serv_addr: // адрес Интернет-сервера
int rmt_s; // дескриптор удаленного сокета
// заполнить структуру адресной информацией об удаленном сервере
// и установить соединение с сервером
server_addr.sin_family = AF_INET: // используемое семейство адресов
server_addr.sin_port = htons(PORT_NUM); // используемый номер порта
server_addr.sin_addr.s_addr = inet_addr(inet_ntoa(address)); // IP-адрес
if (connect(rmt_s.(struct sockaddr *)&serv_addr. sizeof(serv_addr)) != 0)
// вывести сообщение об ошибке и прекратить работу
Функция gethostbynamef)
Функция gethostbyname() принимает в качестве аргумента имя хоста и возвращает
NULL в случае ошибки или указатель на экземпляр структуры hostent в случае ус-
пеха. В этой структуре содержится информация об именах хоста, его псевдонимах
и IP-адресах. Эти данные получаются из DNS или из локальной базы данных.
Функция getservbyname() определяет номер порта, ассоциированный со службой,
имя которой указывается в качестве аргумента. Если вместо него указывается чис-
ленное значение, оно напрямую преобразуется в двоичное значение и использует-
ся как номер порта.
#define struct hostent {
char char *h_name; **h_aliases; // официальное имя хоста // завершающийся нулем список // псевдонимов для этого хоста
int h_addrtype; // тип адреса хоста, например. AF_INET
int hl ength; // длина структуры адресов
char **h_addr_list: // завершающийся нулем список адресов
// с сетевым порядком байтов
}
Обратите внимание на то, что список h_addr_list содержит IP-адреса, ассоции-
рованные с хостом:
#define WIN // WIN для Winsock и BSD для сокетов BSD
#ifdef WIN
#include <windows.h> // для всех функций Winsock
#endi f
#ifdef BSD
#include <netdb.h> // для структуры hostent
#endi f
struct hostent *gethostbynairie(const char ★hostname'):
Для обнаружения хостов, служб, протоколов или сетей могут использоваться
следующие функции: getpeemame(), gethostbyaddr(), getprotbyname(), getproyobynumber(),
getprotoent(), getservbyname(), getservbyport(), getservent(), getnetbyname(), getnetbynumber(),
getnetent().
718
Приложение Б. Сокеты
Ниже приводится пример обращения к функции gethostbyname():
tfifdef BSD
#include <sys/types.h> // для типа cadrt
#endif
#def ine SERV_NAME somehost.somecompany.com
#define PORT_NUM 1050 // произвольный номер порта
#define h_addr h_addr_list[0] // для хранения Интернет-адресов хостов
struct sockaddr_in myhost_addr: struct hostent *hp; // Интернет-адрес локального хоста // для хранения информации об удаленном хосте
i nt rmt_s; // дескриптор удаленного сокета
// часть программы, специфическая для UNIX
bzero((char *)&myhost_addr. sizeof(myhost_addr)):
// часть программы, специфическая для Windows
memset(&myhost_addr. 0. sizeof(myhost_addr));
// заполнить структуру адресной информацией об удаленном сервере
// и установить соединение с сервером
myhostaddr.sinfamily = AF_INET: // используемое семейство адресов
myhost_addr.sin_port = htons(PORT_NUM); // используемый номер порта
if (hp = gethostbyname(MY_NAME) == NULL)
// вывести сообщение об ошибке и прекратить работу
// часть программы, специфическая для UNIX
bcopy(hp->h_name, (char *)&myhost_addr.sin_addr. hp->h_length);
// часть программы, специфическая для Windows
memcpy(&myhost_addr.sin_addr. hp->h_addr. hp->h_length):
if(connect(nnt_s.(struct sockaddr *)&myhost_addr, sizeof(myhost_addr))!=0)
// вывести сообщение об ошибке и прекратить работу
Функция bzero() операционной системы UNIX обнуляет буфер указанной дли-
ны. Это одна из функций, работающая с массивами и байтами. Функция Ьсору()
копирует указанное количество байтов из одного буфера в другой. Функция bcmp()
сравнивает указанное количество байтов в двух буферах. Функций операционной
системы UNIX bzero() и bcopy() нет в Windows, поэтому вместо них следует ис-
пользовать функции memset() и memcpy().
Пример программы с использованием сокетов для получения IP-адреса хоста
для данного имени хоста приведен ниже:
#define WIN // WIN для Winsock и BSD для сокетов BSD
#include <stdio.h> // нужно ДЛЯ printfO
include <stdlib.h> // нужно ДЛЯ exitO
#include <string.h> #ifdef WIN // нужно ДЛЯ memcpyO и strcpyO
#include <windows.h> // нужно ДЛЯ Winsock
#endif #ifdef BSD
include <sys/types.h> // нужно ДЛЯ идентификаторов, определяемых системой
Б.4. Элементы сокетов
719
include <netinet/in.h> // нужно для структуры Интернет-адресов
#include <arpa/inet.h> // нужно для inet_ntoa()
^include <sys/socket.h> // нужно для socket!). bind() и т. д.
include <fcntl.h>
^include <netdb.h>
#endi f
void maindnt argc. char *argv[l)
{
#ifdef WIN
WORD wVersionRequested = MAKEWORD(l.l): // для функций WSA
WSADATA wsaData: // для функций WSA
#endi f
struct hostent *host: // структура для gethostbynameO
struct in_addr address: // структура для Интернет-адресов
char host_name[256]: // строка для имени хоста
if (argc != 2)
{
printfC**** ОШИБКА - неверное количество аргументов в командной строке\п"):
printfC формат командной строки: 'getaddr host_name'\n");
exit(l):
}
#ifdef WIN
// Инициализация winsock
WSAStartup(wVersionRequested. &wsaData):
#endi f
// Копировать имя хоста в host_name
strcpy(host_name, argv[l]}:
printfC' Поиск IP-адреса для хоста ’Ss’...\n”, host_name):
host = gethostbyname(host_name);
// Печать результата поиска
if (host = NULL)
printfC He удается найти IP-адрес хоста 'its' \n". hostjiame):
el se
{
niemcpyUaddress. host->h_addr. 4):
printfC IP-адрес хоста 'fcs': its \n“. host_name. inet_ntoa(address));
)
#ifdef WIN
// Очистить winsock
WSACleanupO:
#endi f
)
Прослушивание входящих запросов
на соединение от клиентов
Функция listen() используется на сервере в модели обмена данными на основе
соединений, для того чтобы подготовить сокет к приему сообщений от клиентов.
Определение функции Listenf) выглядит следующим образом:
int listen!int sd. int qlenf-.
720 Приложение Б. Сокеты
+ sd — дескриптор сокета после вызова функции bind();
4- glen — максимальное число входящих запросов на установку соединения,
которые могут ждать в очереди на обработку, пока сервер занят.
Функция Listen() возвращает целое число, равное 0, в случае успеха и -1 в случае
ошибки. Например:
if (listened. 5) < 0) {
// вывести сообщение об ошибке и прекратить работу
Согласие на установку соединения с клиентом
Функция accept() используется на сервере в модели обмена данными на основе
соединений (после обращения к функции Listen()), для того чтобы удовлетворить
запрос на установку соединения, поступивший от клиента:
#define WIN // WIN для Winsock и BSO для сокетов BSD
tfifdef WIN
#include «windows.h> // для всех функций Winsock
#endlf
#ifdef BSD
include «sys/types.h>
#include <sys/socket.h> // для структуры sockaddr
#endif
int accept(1nt server_s. struct sockaddr * client_addr. int * clntaddrjen)
4- servers — дескриптор сокета, прослушиваемый сервером;
4- client_addr — адрес клиента;
4- clntaddr_len — длина адресной структуры клиента.
В случае успеха функция accept() возвращает целое число, представляющее
новый сокет, и -1 в случае ошибки.
После обращения к функции accept() удовлетворяется первый стоящий в оче-
реди входящий запрос и создается новый сокет с теми же свойствами, что и sd. С
этого момента для общения с данным клиентом сервер будет использовать этот
сокет. В результате многократных обращений к функции connect() мы получим
много новых сокетов.
Пример использования функции accept():
struct sockaddr_in client_addr;
int server_s, client_s. clntaddr_len;
if ((client_s - accept!server_s. (struct sockaddr *)&client_addr. &clntaddr_len) < 0)
// вывести сообщение об ошибке и прекратить работу
// на этом этапе поток или процесс может получить
// управление и взять на себя общение с клиентом
При последующих обращениях функция accept() вернет другие соединенные
сокеты. Эти соединенные сокеты мультиплексируются на том же порту сервера
функциями работающего стека протокола TCP. '
В.4. Элементы сокетов
721
Передача и прием сообщений через сокет
В данном разделе мы представим только четыре функции. В действительности
существует больше способов отправки и приема данных через сокеты. Для соке-
тов TCP/IP, как правило, используются функции send() и recv():
int senddnt socket, const void *msg, unsigned int msg_length. int flags'):
int recv(int socket, void *rcv_buff. unsigned int buff_length. int flags): •
♦ socket — локальный сокет, используемый для функций send() и recv();
♦ msg — указатель на сообщение;
♦ msg_length — длина сообщения;
♦ rcv_buff — указатель на буфер приема;
♦ buff_length — длина буфера.
♦ flags — флаги, изменяющие поведение функции по умолчанию.
Например, чтобы указать, что сообщение должно быть отправлено без данных
локальных таблиц маршрутизации (по умолчанию они используются), может быть
задано определенное значение флагов.
Для сокетов UDP, как правило, используются следующие функции:
int sendto(int socket, const void ★msg, unsigned int msg_length, int flags, struct
sockaddr *dest_addr. unsigned int addr_length):
int recvfrom(int socket, void *rcv_buff, unsigned int buff_length. int flags, struct
sockaddr *src_addr. unsigned int addrlength):
Большинство параметров этих функций совпадает с параметрами функций
send() и recv(), кроме параметров destaddr/srcaddr и addr_length. В отличие от
потоковых сокетов, при отправлении и получении дейтаграмм с помощью перечис-
ленных функций необходимо указывать адрес удаленного компьютера. В следую-
щих разделах будет предоставлен пример программ для TCP/IP и UDP клиента и
сервера, где будут приведены примеры вызовов всех четырех функций.
Закрытие сокета
Прототип функции закрытия сокета выглядит следующим образом:
int closesocket(int sd): И прототип Windows
int close(int fd): // прототип BSD UNIX
Параметры fd и sd представляют собой дескриптор файла (аналог дескриптора
сокета в UNIX) и дескриптор сокета.
Когда сокет надежного протокола (например, TCP/IP) закрывается, ядро про-
должает попытки передачи данных, и соединение переходит в состояние TIME_WAIT
(см. рис. Б.1). Если приложение для соединения выбирает тот же номер порта,
может возникнуть следующая ситуация. Когда это удаленное приложение вызы-
вает функцию connect(), локальное приложение предполагает, что существующее
соединение все еще активно, и рассматривает запрос на установку входящего со-
единения как попытку дублирования существующего соединения. В результате
возвращается код ошибки [WSA] ECONNREFUSED. Для каждого активного сокета one-
722
Приложение Б. Сокеты
рационная система поддерживает счетчик ссылок. Обращение к функции close()
уменьшает на единицу значение счетчика сокета, указанного в качестве аргумента.
Об этом важно помнить, если один и тот же сокет используется несколькими процес-
сами. В следующих подразделах будет приведено несколько примеров программ.
Коды ошибок
Выполнение всех обсуждавшихся ранее операций с сокетами может завершиться
неудачей. В программировании считается хорошим стилем сообщать код возвраща-
емой ошибки. Большая часть этих кодов ошибок предназначена для того, чтобы
помочь разработчику в процессе отладки программы, а некоторые коды ошибок
также будут отображаться для пользователей. В среде Windows все возвращаемые
коды ошибок определены в файле winsock.h. В операционных системах семейства
UNIX определения кодов ошибок содержатся в файле socket.h. Коды ошибок
Windows можно получить из оригинальных кодов ошибок BSD путем добавления
к последним 10000, а обозначения ошибок — добавлением префикса WSA к назва-
ниям, принятым в BSD UNIX. Например:
♦ имя в Windows — WSAERPROTOT;
♦ имя в BSD - ERPROTOT;
♦ значение в Windows — 10041;
♦ значение в BSD — 41.
Существует несколько ошибок, специфичных для Windows, отсутствующих
в UNIX:
♦ WSASYSNOTREADY (10091). Возвращается функцией WSAStartup(). Сообщает о
неготовности сетевой подсистемы.
♦ WSAVERNOTSUPPORTED (10092). Возвращается функцией WSAStartup(). Указы-
вает, что DLL не поддерживает данное приложение.
♦ WSANOTINITIALIZED (10093). Возвращается любой функцией, кроме WSAStartup(),
если успешного выполнения функции WSAStartup() еще не было.
Ниже приводится пример программы с обработкой ошибок:
#ifdef WIN
^include <stdio.h> И для fprintfO
include <winsock.h> // для WSAGetLastErrorO
^include <stdlib.h> // для exit!)
#endif
#ifdef BSD
#include <stdio.h>
include <stdlib.h>
#endi f
11 для fprintfO и perrorO
// для exitO
void catch_error(char * programjnsg)
г
char err_descr[128]: // для хранения описания ошибки
int err;
err = WSAGetLastErrorO;
Б.4. Элементы сокетов
723
// заполнить буфер описанием ошибки
if (err -= WSANO_DATA)
strcpy(err_descr. "WSANO_DATA (11004) Запрашиваемое имя найдено, но в базе данных
DNS для него нет данных."):
if (err == WSANO_RECOVERY)
strcpy(err_descr. "WSANO_RECOVERY (11003) Это фатальная ошибка.");
if (err == WSATRY_AGAIN)
fprintf(stderr."£s: Xs\n". programjnsg. err_descr):
exit(l):
}
Вы можете расширить список ошибок, используемых в Windows-приложении,
если заглянете на сайт http://www.sockets.com.
Пример клиентской программы TCP/IP
Эта клиентская программа, инициирующая соединение, получает от сервера одно
сообщение, а затем прекращает работу. После получения сообщения программа
посылает подтверждение серверу:
#define WIN И WIN для Winsock и BSD для BSD-сокетов
#include <stdio.h> И нужно для printfO
#include «string.h> И нужно для memcpyO и strcpyO
#ifdef WIN
#include «windows.h> // нужно для Winsock
#endi f
#ifdef BSD
#include <sys/types.h> // нужно для идентификаторов, определяемых системой
#include <netinet/in.h> // необходимо для структуры Интернет-адресов
#include <sys/socket.h> И требуется для socketO. bindO и т. д.
#include <arpa/inet.h> И нужно для inet_ntoa()
#include <fcntl.h>
#include «netdb.h>
#endif
#define PORTJNUM 1050 // номер порта сервера
#define IP_ADDR "131.247.167.101" И IP-адрес сервера (фиксированный)
void main(void)
{
#ifdef WIN
WORD wVersionRequested = MAKEWORD(1.1): 11 функции WSA
WSADATA wsaData: // функции WSA
#endif
unsigned int server_s:
struct sockaddrjn server addr:
char out_buf[100]:
char in_buf[100J:
// дескриптор сокета сервера
И Интернет-адрес сервера
// выходной буфер для данных
И входной буфер для данных
#ifdef WIN
// инициализировать Winsock
WSAStartup(wVersionRequested. &wsaData):
#endi f
724
Приложение Б. Сокеты
// создать сокет
server_s = socket(AF_INET. SOCK_STREAM. 0):
И заполнить адрес сокета сервера и соединиться с ожидающим
// соединения сервером. Функция connectt) заблокируется.
Server_addr.sin_family = AF_INET: // семейство адресов
Server_addr.sin_port = htons(PORI_NUM); // номер порта
Server_addr.sin_addr.s_addr = inet_addr(IP_ADDR): // IP-адрес
Connect(server_s. (struct sockaddr *)&server_addr. sizeof(server_addr)):
11 получить данные с сервера
recv(server_s. in_buf. sizeof(in_buf). 0);
printft'Received from server data = 'Xs' \n", in_buf);
11 послать данные на сервер
strcpy(out_buf. "Message - client to server");
send(server_s. out_buf, (strlen(out_buf) + 1). 0);
// закрыть все открытые сокеты
#i fdef WIN
closesocket(servers);
#endif
#1fdef BSD
close(server_s):
#endi f
#ifdef WIN
// очистить winsock
WSACleanupO;
#endi f
}
Пример серверной программы TCP/IP
Все, что делает следующая серверная программа, пассивно ожидающая соедине-
ния, — это передает сообщение клиентской программе, работающей на другом хо-
сте. Она создает сокет и ожидает от клиента входящий запрос на обслуживание
через этот единственный сокет. Когда запрос удовлетворен, серверная программа
прекращает работу:
#define WIN // WIN для Winsock и BSD для сокетов BSD
#include <stdio.h> // нужно для printft)
#include «string.h> // нужно для memcpyO и strcpyO
#ifdef WIN
#include «windows.h> // нужно для Winsock
#endif #1fdef BSD
^include <sys/types.h> // нужно для идентификаторов, определяемых системой
^include <netinet/in.h> // нужно для структуры Интернет-адресов
include <arpa/inet.h> // нужно для inet_ntoa()
#include <sys/socket.h> // нужно для sockett). bindO и т. д.
#include <fcntl.h>
#1nclude <netdb.h>
#endi f
#define PORT_NUM 1050 // произвольный номер порта для сервера
Б.4. Элементы сокетов
725
#define MAX_L1STEN 3 И максимальная ллина очереди ожидания соединений
void main(void)
{
#ifdef WIN
WORD wVersionRequested
WSADATA wsaData;
#endif
unsigned int server_s:
struct sockaddr_in server_addr:
unsigned int clients;
struct sockaddr_in client_addr;
struct in_addr client_1p_addr:
int addr_len;
char out_buf[10D];
char in_buf[100]:
= MAKEWORD(l.l);
// для функций WSA
// для функций WSA
// дескриптор сокета сервера
// Интернет-адрес сервера
И дескриптор сокета клиента
И Интернет-адрес клиента
// IP-адрес клиента
// длина Интернет-адреса
// выходной буфер данных
// входной буфер данных
#ifdef WIN
// инициализировать Winsock
WSAStartuptwVersionRequested. SwsaData):
#endif
// создать сокет
// AF [NET - семейство адресов Интернета, a SOCK_STREAM - поток
server_s = socket(AF_INET, SOCK_STREAM. 0):
// заполнить структуру адресной информацией сокета и привязать сокет
// описание структуры sockaddrin см. в winsock.h
server_addr.sin_family = AFINET; И используемое семейство адресов
server_addr.sin_port = htons(PORT_NUM): // используемый номер порта
server_addr.sin_addr.s_addr = htonl(INADDR ANY); И принимать запросы ото всех
И IP-адресов
bind(server_s. (struct sockaddr *)&server_addr, sizeof(serveraddr)):
// ожидать соединения (MAX_LISTEN - максимальная длина очереди)
11sten(server_s. MAX_LISTEN):
// принять запрос соединения. Функция accept!) заблокируется, а затем вернет управление
// с заполненной структурой client_addr
addr_len = sizeof(client_addr);
client_s = accept(server_s. (struct sockaddr *)&client_addr. &addr_len);
// закопировать 4-байтовый IP-адрес клиента в структуру IP-адресов
// описание структуры sockaddrjn см. в winsock.h
memcpy(8client_ip_addr. &client_addr.sin_addr.s_addr. 4);
// вывести сообщение о том. что запрос принят
prwtf("Запрос принят!!! IP-адрес клиента = Xs порт - Xd \n”. inet_ntoa(client_ip_addr).
ntohs(client_addr.sin_port));
И передача сообщения клиенту
strcpy(out_buf. “Сообщение от сервера клиенту ");
send(client_s. out_buf. (strlen(out_buf) + 1). 0):
// получить данные от клиента
recv(client_s. in buf. sizeof(in buf). 0):
printf(“Полученные от клиента данные - ’Xs'Xn'. inbuf);
726
Приложение Б. Сокеты
И закрыть все открытые сокеты
#ifdef WIN
closesocket(server_s);
closesocket(cl 1ent_s):
#endi f
tfifdef BSD
close(server_s);
close(client_s):
#endi f
#ifdef WIN
// очистить Winsock
WSACleanupO;
#endi f
}
Приведенный пример не очень реалистичен. Чаще всего серверные прило-
жения содержат бесконечный цикл и способны принимать несколько запросов.
Данный пример несложно преобразовать в более реальную серверную про грамму,
поместив соответствующие строки в бесконечный цикл, условие завершения ко-
торого никогда не выполняется (например, while(l){...}). Такой сервер создаст
один постоянный сокет с помощью функции socket(), тогда как временные сокеты
будут создаваться каждый раз, когда принимается запрос. Таким образом, каждый
временный сокет будет отвечать за поддержание одного входящего соединения.
Если в конце концов сервер прекратит свою работу, постоянный сокет будет за-
крыт, так же как и все активные временные сокеты. Доступность того же номера
порта для повторного использования другими приложениями определяется ре-
ализацией протокола TCP. Такой порт будет находиться в состоянии TIMEWAIT
в течение некоторого заранее определенного периода времени, как показано на
рис. Б.1 для порта 1234.
Б.5. Потоковые и дейтаграммные сокеты
Для передачи ориентированных на соединение надежных потоков байтов между
машинами используются сокеты типа SOCK_STREAM. Как уже говорилось ранее, в не-
которых случаях перед использованием сокеты должны быть соединены. В этом
случае данные передаются по двунаправленным потокам байтов, и гарантируется
прибытие данных в правильном порядке.
Сокеты типа SOCK_DGRAM (дейтаграммные сокеты) также поддерживают дву-
направленный поток данных, но данные могут прибывать не в том порядке, в ко-
тором они были отправлены, а также могут дублироваться (то есть не гарантиру-
ется сохранение порядка поступления данных и их уникальность). Дейтаграммные
сокеты также не предоставляют надежной службы, так как данные могут быть по-
теряны. Однако важно отметить, что сохраняются границы записей данных, если
длина записей не превышает размера буфера получателя. В отличие от потоковых
сокетов, дейтаграммные сокеты не требуют установки соединений. Таким образом,
не нужно устанавливать соединение перед их применением. На рис. Б.З показана
блок-схема взаимодействия сокетов. Если сравнить данную схему с потоковой
Б.5. Потоковые и дейтаграммные сокеты
727
моделью взаимодействия, можно заметить, что здесь не используются функции
listenQ и accept(), а вместо функций send() и recv() применяются функции sendto()
и recvfrom().
Сервер
Клиент
socketQ
bind()
socket()
sendto()/recvfrom()
close() для UNIX
или closesocketQ для Windows или closesocket() для Windows
Рис. Б.З. Блок-схема взаимодействия дейтаграммных сокетов
Пример клиентской программы UDP
^define WIN // WIN для
^include <stdio.h> И нужно
^include «string.h> // нужно
#ifdef WIN
#include «windows.h> // нужно
#endif
#ifdef BSD
#include <sys/types.h> // нужно
^include «netinet/in.h> // нужно
^include «arpa/inet.h> // нужно
^include «sys/socket.h> /7 нужно
^include <fcntl.h>
^include <netdb.h>
#endif
Winsock и BSD для сокетов BSD
для printfl)
для memcpyO и strcpyO
для Winsock
для идентификаторов, определяемых системой
для структуры Интернет-адресов
для inet_ntoa()
для socket!). bind!) и т. д.
^define PORT_NUM 1050 // номер порта сервера
^define IP_ADDR "131.247.167.101" // IP-адрес сервера (фиксированный)
void main!void)
{
#ifdef WIN
WORD wVersionRequested = MAKEWORD(l.l); // функции WSA
WSADATA wsaData; // функции WSA
#endif
unsigned int server_s;
struct sockaddr_in server_addr;
char out_buf[100];
char in_buf[100]:
// дескриптор сокета сервера
// Интернет-адрес сервера
И выходной буфер для данных
И входной буфер для данных
#ifdef WIN
И инициализировать сокет
WSAStartup(wVersionRequested. &wsaData);
#endif
728
Приложение Б. Сокеты
// создать сокет
server_s = socketCAFINET. SOCK_STREAM. 0):
// заполнить адрес сокета сервера
server_addr.sin_family = AFINET; // используемое семейство адресов
serveraddr.sinjjort * htons(PORT_NUM): И используемый номер порта
server_addr.sin addr.s_addr = inet_addr(inetjitoa(address)); // используемый IP-адрес
// заполнить буфер out_buf сообщением
strcpy(out_buf. "Сообщение от клиента серверу''):
// отправить сообщение серверу. “*1" позволяет включить
И символ конца строки
sendtotservers, out_buf. (strlen(out_buf) +1). 0. (struct sockaddr *)&server_addr.
si zeof(server_addr));
// подождать получения сообщения
addr_len = sizeof(serveraddr):
recvfrom(server_s, in_buf. sizeof(in_buf), 0. (struct sockaddr *)&server addr. &addr_len):
// вывести полученное сообщение
printff'Полученное сообщение: ’Xs' \n". in_buf):
// закрыть все открытые сокеты
#1fdef WIN
closesocket(server_s):
#endi f
#ifdef BSD
close(servers):
#endif
#ifdef WIN
11 очистить сокет
WSACleanupO:
#endif
}
Пример серверной программы UDP
#define WIN // WIN для Winsock и BSD для сокетов BSD
#include <stdio.b> // нужно для printfO
^include <string.h> #ifdef WIN И нужно для memcpyO и strcpyO
#include «windows.h> #endif #ifdef BSD // нужно для Winsock
#include <sys/types.h> И нужно для идентификаторов, определяемых системой
include <netinet/in.h> // нужно для структуры Интернет-адресов
#include <arpa/inet.h> // нужно для inet_ntoa()
#inciude <sys/socket.h> #include «fcntl h> II нужно для socketO. bindt) и т. д.
#include <netdb.h>
#endif
#define PORT_NUM 1050 // используемый номер порта
#define IP_ADDR ”131.247.167.101" // IP-адрес клиента
void rnain(void)
{
#ifdef WIN
Б.5. Потоковые и дейтаграммныесокеты
729
WORD wVersionRequested = MAKEWORD(1.1); // для функций WSA
WSADATA wsaData; // для функций WSA
#endi f
unsigned int senver s: И дескриптор сокета сервера
struct sockaddr_in server_addr: // Интернет-адрес сервера
struct sockaddr_in clientaddr; // Интернет-адрес клиента
int addrjen; // длина Интернет-адреса
char out_buf[100]: И выходной буфер для данных
char in_buf[100]; И входной буфер для данных
long int i: И счетчик циклов
#ifdef WIN
// инициализировать сокет
WSAStartuptwVersionRequested. RwsaData);
#endif
// создать сокет
// AF_INET - семейство адресов Интернета, a SOCKDGRAM - дейтаграмма
server_s = socket(AF_INET. SOCK DGRAM, 0):
// заполнить адресной информацией структуру сокета сервера
server_addr.sin_family = AFINFT: И семейство адресов
server_addr.sin_port = htons(PORT_NUM); // номер порта
server_addr.sin_addr.s_addr = htonl(INADDR_ANY); И прослушивать все IP-адреса
bind(server_s. (struct sockaddr *)&server_addr. sizeof(serveraddr));
// заполнить адресной информацией структуру сокета клиента
client_addr.sin_family - AF_INET; // используемое семейство адресов
client_addr.sin_port = htons(PORl_NUM); // используемый номер порта
client_addr.sin_addr.s_addr - inet_addr(IP_ADDR); // используемый IP-адрес
// ожидать получения сообщения от клиента
addrjen = sizeof(client_addr):
recvfrom(server_s. inbuf. sizeof(in_buf). 0. (struct sockaddr *)&client_addr. Saddr len):
// вывести полученное сообщение
printf("Полученное сообщение: '£s'\n", in buf);
И цикл задержки, предоставляющий время клиенту
for (1=0: 1» Step #5 <«’
И отправить сообщение клиенту. ”+Г позволяет включить
// символ конца строки
sendto(server_s. out_buf, (strlen(out_buf) + 1). 0. (struct sockaddr *)&client_addr.
sizeof(client_addr)):
// закрыть все открытые сокеты
#ifdef WIN
closesocket(server_s):
#endi f
frifdef BSD
close(servers):
#endi f
tfifdef WIN
11 очистить сокет
WSAC1eanupt):
tfendif
}
В этой строке несколько синтаксических ошибок. Догадаться, что имел в виду автор, невозможно.
Примеч. перев.
730
Приложение Б. Сокеты
Б.6. Управление программой во время
выполнения
Неблокирующие обращения к сокетам
По умолчанию сокет создается как блокирующий (то есть он не возвращает управ-
ления обратившейся к нему программе до тех пор, пока не будет выполнена вы-
зываемая функция). Например, если мы обращаемся к функции accept() сокета,
процесс будет заблокирован, пока от клиента не поступит запрос на соединение.
В операционной системе UNIX есть две функции, позволяющие превратить бло-
кирующий сокет в неблокирующий: ioctl() и select(). Функция ioctl() облегчает
управление вводом-выводом файла или сокета. Затем с помощью функции select()
можно определить состояние сокета, то есть его готовность или неготовность к вы-
полнению действия:
И изменение блокирующего состояния сокета
unsigned long unblock = TRUE; H TRUE для неблокирующего. FALSE для блокирующего
ioctKs. FIONBIO. Sunblock);
Затем периодически вызывается функция accept():
while(client_s = acceptts. NULL. NULL) > 0)
I
if (client_s == EWOULDBLOCK)
// ждать, пока не прибудет запрос на соединение от клиента.
// тем временем выполняя полезные действия
else
И обработать поступивший запрос соединения
}
// вывести сообщение об ошибке и прекратить работу
Также можно использовать функцию select(), чтобы опросить состояние соке-
та, как это делается в следующем фрагменте программы с использованием небло-
кирующего сокета:
if (select(max_descr + 1. &sockSet. NULL. NULL. 8sel_timeout) == 0)
11 вывести сообщение для пользователя
else
{ ..
client_s = acceptts. NULL. NULL);
)
Таким образом, процесс должен периодически опрашивать операционную сис-
тему с помощью функции select(), пока сокет не будет готов к операции ввода-вы-
вода. В отличие от случая блокирующего запроса, при длительной неготовности
сокета процесс, выполняющий функцию selectf), сможет возобновить работу, ког-
да истечет период ожидания функции select(), но такое решение неэффективно.
Опрос в цикле функций select() или accept() приводит к напрасному расходова-
нию ресурсов центрального процессора.
Б.6. Управление программой во время выполнения
731
Асинхронный ввод-вывод
Лучшим решением является использование асинхронного ввода-вывода (то есть,
обнаружив активность ввода-вывода сокета, операционная система немедленно
информирует об этом процесс и таким образом избавляет его от необходимости
постоянного опроса). В оригинальной операционной системе BSD UNIX для это-
го используются функции sigaction() и fcntl(). Альтернатива опросу состояния со-
кета с помощью функции select() заключается в том, чтобы позволить ядру опера-
ционной системы информировать приложение о событиях при помощи сигнала
SIGIO. Для этого необходимо установить процедуру обработки этого сигнала с помо-
щью функции sigaction(). В следующем примере программы сокеты не используют-
ся. В нем просто показано, как установить процедуру обработки сигнала. Данная
процедура перехватывает ввод символа прерывания работы программы клавиша-
ми Ctrl+C, устанавливая обработчик сигнала для SIGINT (сигнал прерывания) с по-
мощью функции sigaction():
#include <studio.h> И для printft)
^include <sys/signal,h> // для sigactiont)
^include <unistd.h> // для paused
void catch errortchar *errorMessage): 11 для обработки ошибок
void InterruptSignalHandlertint SignalType); // обработка сигнала interr
int maintint argc. char *argv[l)
struct sigaction handler; // спецификация обработчика сигнала
// использовать функцию InterruptSignalHandlert) в качестве обработчика
handler.sajiandler = InterruptSignalHandler;
// создать маску для всех сигналов
if (sigfi11 set(&handler.sajnask) < 0)
catch_error("работа функции sigfillsett) завершилась неуспешно");
11 сброс флагов
handler.sa_flags = 0;
// установить обработку сигналов прерывания
if tsigactiontSIGINT. &handler. 0) < 0)
catch_error("работа функции sigactiont) завершилась неуспешно ");
fort:;)
paused: // приостановить программу до тех пор. пока не будет получен сигнал
exit(0);
}
void InterruptSignalHandlertint signalType)
{
printft"Прерывание получено. Программа остановлена.\пп);
exit(l);
}
Флаг FASYNC должен быть установлен равным дескриптору сокета с помощью
функции fcntl(). Сначала мы уведомляем операционную систему о нашем желании
установить новую процедуру обработки для сигнала SIGIO с помощью функции
732 Приложение Б. Сокеты
sigaction(). Затем мы заставляем операционную систему предоставлять сигналы I
текущему процессу с помощью функции fcntl(). Этот вызов гарантирует, что сре- •-—=
ди всех процессов, имеющих доступ к сокету, сигнал передается именно текущему
процессу (или группе процессов). Затем мы снова используем функцию fcntl(), 1
чтобы задать флаг состояния равным тому же дескриптору сокета для асинхрон-
ного флага FASYNC. Следующий фрагмент программы с использованием дейта-
граммных сокетов следует данной схеме (для ясности все детали пропущены):
int maint)
{
// создать сокет для передачи/приема дейтаграмм
И инициализировать адресную структуру сервера
// связать с локальным адресом
И установить обработчик сигнала SIGIO
// создать маску для всех сигналов
if (sigfillset(&handler.sajnask) < 0)
// вывести сообщение об ошибке и завершить работу
// сброс флагов
handler.sa_flags = 0:
if (sigactionfSIGIO. Shandler. 0) < 0)
// вывести сообщение об ошибке и завершить работу
И нам нужно владеть сокетом, чтобы получить сообщение SIGIO
if (fcntl (s_socket. FSETOWN. getpidO) < 0)
// вывести сообщение об ошибке и завершить работу
// организовать асинхронный ввод-вывод и доставку сигнала SIGIO
if (fcntl(s_socket. F_SETFL. FASYNC | O_NONBLOCK) < 0)
// вывести сообщение об ошибке и завершить работу
for (;:)
paused;
}
В операционной системе Windows функция select() не реализована. Для запро-
са уведомлений о сетевых событиях используется функция WSAAsyncSelect(). Эта
функция требует, чтобы динамическая библиотека Ws_32.dll посылала сообщение
окну, идентифицируемому дескриптором окна hWnd:
WSAAsyncSelecttSOCKET socket. HIND hWnd. unsigned int wMsg. long lEvent)
Тип SOCKET определен в файле winsock.h. Дополнительную информацию по тп- j
пам данных операционной системы Windows можно найти по адресу http:// !
Б.7. Удаленное выполнение консольного Windows-приложения
733
msdn.microsoft.com/library/psdk/psdkref/type_8uk3.htm. Параметр socket представля-
ет собой дескриптор сокета, h Wnd — дескриптор окна, wMsg — сообщение, a lEvent,
как правило, представляет собой коды всех событий, о которых операционная си-
стема должна уведомлять окно, объединенные оператором логического ИЛИ. Вот
примеры некоторых кодов событий: FD_CONNECT (соединениеустановлено), FD .„ACCEPT
(готовность к установке соединения), FD READ (готовность к чтению). FD_WRITE (го-
товность к записи), FD CLOSЕ (соединение закрыто). Вы можете включить следующий
фрагмент программы с использованием потоковых сокетов в показанную выше
программу или в свое собственное приложение (детали снова опущены):
// сообщение для асинхронного уведомления
^define («Msg (WM_USER + 4)
// сокет socket_s уже создан и привязан к имени
// прослушивать запросы на установку соединения
if (listenfsocket_s. 3) == SOCKET_ERROR)
// вывести сообщение об ошибке
// и завершить работу после чистки
// получить уведомление о входящем запросе на установку соединения
if (WSAAsyncSelectCs. hWnd. wMsg. FD_ACCEPT) = SOCKET ERROR)
// вывести сообщение об ошибке
И и завершить работу после очистки
else
// принять входящее соединение
Дополнительные сведения по вопросам асинхронного ввода-вывода можно
получить в книге Donahoo and Calvert «The Pocket Guide to TCP/IP Sockets —
C Version» (для UNIX) и по адресу http://www.mkp.com/socket, а также в книге Bob
Quinn «Windows Sockets Network Programming» (для Windows) и по адресу http://
www.sockets.com/.
Б.7. Удаленное выполнение консольного
Windows-приложения
Простые операции с сокетами могут использоваться при решении задач, кото-
рые трудно решить другими способами. Например, с помощью сокетов возможно
удаленное выполнение приложения. Ниже приводится пример такой программы'.
С помощью двух программ, использующих сокеты, локальной и удаленной, кон-
сольное Windows-приложение (файл с расширением .ехе) переносится с локаль-
ного хоста на удаленный хост. Затем эта программа выполняется на удаленном
хосте, после чего ее выходные данные (stdout) возвращаются на локальный хост.
1 В написании двух следующих программ принимали участие Кен Кристансен (Ken Christiansen)
и Карл С. Латаксес (Karl S. Lataxes) с кафедры кибернетики университета Южной Флориды (http://
www.csee.usf.edu/-christen/lools).
734
Приложение Б. Сокеты
Локальная программа
#include <stdio.h> #include <stdlib.h> ^include «string.h> ^include «windows.h> #include <fcntl.h> #include <sys\stat.h #include <io.h> // нужно для printfC // нужно для exitO // нужно для memcpyt) и strcpyO // нужно для SleepO и Winsock И нужно для констант файлового ввода-вывода > // нужно для констант файлового ввода-вывода
// нужно для openO. closet) и eoft)
^define PORT-NUM 1050 И произвольный номер порта для сервера
#define MAX_LISTEN 1 // максимальная длина очереди
#define SIZE 256 // размер буфера переноса в байтах
void main(int argc. char *argv[])
WORD wVersionRequested = MAKEWORD(l.l): // функции WSA
WSADATA wsaData; // структура данных Winsock API
unsigned int remotes; // дескриптор удаленного сокета
struct sockaddr_in remote_addr; // удаленный Интернет-адрес
struct sockaddrin server_addr: // Интернет-адрес сервера
unsigned char bin_buf[SIZEJ; // буфер для переноса файла
unsigned int fh; // описатель файла
unsigned int length: // размер перенесенных данных
struct hostent *host; // структура для gethostbynamet)
struct in_addr address: // структура для Интернет-адресов
char host_name[256]; // строка для имени хоста
int addr_len: // длина Интернет-адреса
unsigned int local_s: // дескриптор локального сокета
struct sockaddr_in local_addr: и локальный Интернет-адрес
struct in_addr remote_ip_addr: // удаленный IP-адрес
// проверка синтаксиса командной строки
if (arg !=4)
(
printfC *** ОШИБКА - Должно быть 'local (host) (exefile) (outfile)’\n"):
printfC где host - имя хоста *или* IP-адрес \n”):
printff хоста, на котором работает remote.с. \п");
printfC exefile - имя файла для удаленного запуска, а \п“);
printfC outfile - имя локального файла вывода \п“);
exit(l):
}
// инициализировать winsock
WSAStartuptwVersionRequested. &wsaData):
// скопировать имя хоста в host_name
strcpy(host_name. argv[l]):
// найти хост по имени
host = gethostbyname(argv[l]):
if (host == NULL)
{
printfC *** ОШИБКА - IP-адрес для '£s' не найден \n. host_name"):
exit(l);
}
Б.7. Удаленное выполнение консольного Windows-приложения
735
// скопировать 4-байтовый IP-адрес клиента в структуру address
memcpyt&address. host ->h_addr. 4);
// создать сокет для удаленного хоста
remote_s = socket(AF_INET. SOCK_STREAM. 0);
// заполнить адресную информацию удаленного (серверного) сокета
//и соединиться с ожидающим сервером
server_addr.sin_family - AF_INET; // используемое семейство адресов
server_addr.sin_port = htons(PORTNUM): // используемый номер порта
server_addr.sin_addr.s_addr = inet_ntoa(address)); // IP-адрес
connect(remotes. (struct sockaddr *)&server_addr. sizeof(server_addr)):
// открыть и прочитать *.exe файл
if((fh = open(argv[2], O_RDONLY | OBINARY. SJREAD | SJWRITE)) == -1)
{
printfC ОШИБКА - не удается открыть файл '£s' \n". argv[2]);
exit(l):
}
// индикация начала отправки исполняемого файла
printfC Файл ’Xs’ посылается на удаленный сервер ‘Xs’ \n", argv[2], argv[l]):
// передача файла *.ехе на удаленный сервер
whilet!eof(fh))
{
length = read(fh. bin_buf, SIZE):
send(remote_s. bin_buf. length. 0):
}
// закрыть файл *.exe. переданный на сервер
close(fh):
// закрыть сокет
closesocket(remote_s):
11 очистить winsock
WSACleanupO:
// индикация начала удаленного выполнения
printfC'OaBn '«s' выполняется на удаленном сервере \n", argv[2J):
// задержка (ждем, чтобы все очистилось)
Sleep(lOO);
// инициализировать winsock
WSAStartup(wVersionRequested. &wsaData);
// создать новый сокет для получения файла вывода с удаленного сервера
locals = socket(AF_INET, SOCK_STREAM. 0);
// заполнить адресную информацию сокета и привязать сокет
local addr.sin fanrily =AF_INET; // используемое семейство адресов
local_addr.sin_port = htons(PORT_NUM); // используемый номер порта
local_addr.sin_addr.s_addr = htonl(INADDR_ANY); // прослушивать все IP-адреса
bind(local_s. (struct sockaddr *)&local addr. sizeof(local_addr));
736
Приложение Б. Сокеты
// ждать запроса на соединение (максимальный размер очереди - MAXJ.ISTEN)
listen(local_s, MAX_LISTEN):
// принять соединение. Функция acceptO заблокируется
// и вернется с заполненной структурой remote_addr
addr_len = sizeof(remote_addr);
remote_s = accept(local_s, (struct sockaddr*)&remote_addr. &addr_len);
// скопировать 4-байтовый IP-адрес клиента в структуру remote_ip_addr
memcpy(&reniote_ip_addr. &remote_addr.sin_addr.s_addr. 4):
11 создать и открыть выходной файл для записи
If ((fh=open(argv[3J. O_WRONLY | 0_CREAT | O_TRUNC | OJ3INARY, SJREAD | SJWRITE)) == -1)
{
printfC *** ОШИБКА - не удается создать файл ’Xs'\n", argv[3]):
exit(l);
}
И получить файл вывода с сервера
length = SIZE:
whileflength > 0)
{
length = recv (remote_s. bin_buf. SIZE. 0):
write(fh. binjxif, length):
}
// закрыть выходной файл, полученный от удаленного сервера
close(fh);
// закрыть сокеты
closesocket(local_s):
cl osesocket (remotes):
// сообщить об успешном завершении программы
printf("3anyCK файла 'Xs' и запись результата в файл '£s' прошли успешно!\п".
argv[2].argv[3J):
И очистить Winsock
WSACleanup():
}
Удаленная программа
#include <stdio.h> // нужно
#include <stdlib.h> // нужно
#include «string.h> // нужно
#include «windows.h> // нужно
#include «fcntl.h> // нужно
#include «sys\stat.h> // нужно
#include «io.h> // нужно
tfdefine PORT_NUM 1050 //
tfdefine MAXLISTEN 1 //
#define SIZE 256 //
#define IN_FILE "run.exe" //
для printfC
для exitO
для memcpyO и strcpyO
для SleepO и Winsock
для констант файлового ввода-вывода
для констант файлового ввода-вывода
для openO. closet) и eof()
произвольный номер порта для сервера
максимальная длина очереди
размер буфера переноса в байтах
имя переносимого исполняемого файла
Б.7. Удаленное выполнение консольного Windows-приложения
737
^define TEXTFILE "output" И имя файла вывода
void main(void)
WORD wVersionRequested - MAKEWORDCI, .1): // функции WSA
WSADATA wsaData; И функции WSA
unsigned int remote_s; H дескриптор удаленного сокета
struct sockaddr in remotejddr: П удаленный Интернет-адрес
struct sockaddrJn server_addr: u Интернет-адрес сервера
unsigned char bin_buf[SIZEJ: // буфер для переноса файла
unsigned int fh: // описатель файла
unsigned int length; // размер перенесенных данных
struct hostent *host; // структура для gethostbynamet)
struct in_addr address: И структура для Интернет-адресов
char host_name[256]; и строка для имени хоста
int addrJen; и длина Интернет-адреса
unsigned int local_s; // дескриптор локального сокета
struct sockaddrjn loca Jaddr; и локальный Интернет-адрес
struct inaddr: local Jp_addr; и удаленный IP-адрес
// бесконечный цикл
whiled)
{
И инициализировать winsock
WSAStartuptwVersionRequested. &wsaData);
// создать сокет
remote_s = socket(AFJNET. SOCK_STREAM. 0):
// заполнить адресную информацию сокета и привязать сокет
remote_addr.sinjamily = AFINET: // используемое семейство адресов
remote_addr.sin_port = htons(PORT_NUM): И используемый номер порта
remote_addr.sin_addr.s_addr = htonl(INADDR_ANY): // прослушивать все IP-адреса
bind(remote_s. (struct sockaddr *)8remote_addr. sizeof(remoteaddr));
// индикация ожидания соединения
printft"Ожидание соединения^");
// ожидание соединения
listen(remote_s. MAX LISTEN);
// принять соединение. Функция acceptd заблокируется
// и вернется с заполненной структурой local_addr
addrjen = sizeof(local_addr);
local_s = accept(remote_s. (struct sockaddr *)&local_addr, Saddrjen);
// скопировать 4-байтовый IP-адрес клиента в структуру local_ip_addr
memcpy(&local Jpjddr. &local_addr.sin_addr.s_addr. 4);
// индикация процесса
printft"Соединение установлено, получаем удаленный исполняемый файл\п");
И создать файл INJILE для приема удаленного исполняемого файла
if((fh = open(INJILE. O_WRONLY | OCREAT | OJRUNC | O_BINARY. SJREAD | SJWRITE)) —
-1)
738
Приложение Б. Сокеты
{
printft" *** ОШИБКА - не удается создать исполняемый файлХп"):
exitС1):
}
И получить исполняемый файл по сети
whiletlength > 0)
{
length = recvtlocals. binbuf. SIZE, 0);
writetfh. bin_buf. length):
}
11 закрыть полученный файл IN_FILE
close(fh);
11 закрыть сокеты
closesocket(remote_s):
closesocket(local_s):
// очистить winsock
WSACleanupt);
11 индикация процесса
printft"Запуск полученного удаленного файлаХп");
И запуск полученного удаленного файла
systemtIN FILE TEXTJILE);
// инициализировать Winsock, чтобы снова открыть сокет и послать файл вывода
WSAStartuptwVersionRequested. SwsaData):
11 создать сокет
И AF_INET - семейство адресов Интернета, a SOCK_STREAM - поток
local_s = socket(AF_INET, SOCK_STREAM, 0);
// заполнить структуру адресной информацией сокета и
// соединиться с ожидающим соединения компьютером
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(PORT_NUM);
s erver_addr.s i n_add г.s_addr = i net_add r(inet_ntoa(1 oca 1 _i p_add r));
connect(1 ocaIs. (struct sockaddr *)&server_addr, sizeoftserveraddr));
11 индикация состояния процесса
printft"Передача файла вывода локальному хостуХп”);
// открыть файл вывода для чтения и передачи его клиенту
ifttfti = open(TEXTJILE. ORDONLY | OJINARY. SJREAD | SJWRITE)) == -1)
{
printft" *** ОШИБКА - не удается открыть файл выводаХп");
exit(1);
И передача файла вывода клиенту
while!!eof(fh))
}
/
Б.7. Удаленное выполнение консольного Windows-приложения
739
length = read(fh. bin_buf. SIZE);
send(local_s. bin_buf, length. 0):
}
// закрыть файл вывода
close(fh);
И закрыть сокеты
closesockettremote_s):
closesocket(local_s):
// очистить winsock
WSACleanupt):
// задержка (ждем, пока все очистится)
Sleep(lOO):
}
}
Словарь специальных
терминов
При изучении империи Арраки и всей культуры, создан-
ной Муадлибом, встречается много незнакомых терми-
нов, нуждающихся в разъяснении. Ниже мы приводим
эти слова с переводом и толкованием.
Франк Херберт. Дюна
Некоторые определения в этом глоссарии взяты из словаря American National
Standard Dictionary of Information Technology, стандарт ANSI X3.172, 1995. Эти
определения помечены звездочкой.
Автоматический запрос на повторение (Automatic Repetition Query, ARQ).
Способность автоматически запрашивать повторную передачу в случае обнаруже-
ния ошибки при передаче.
Архитектура протокола (protocol architecture). Аппаратная и программная
структура, реализующая функции обмена данными.
Асинхронный режим передачи (Asynchronous Transfer Mode, ATM). Стандар-
тизованная союзом ITU технология коммутации пакетов фиксированной длины;
является асинхронной в том смысле, что пакеты от отдельных пользователей пе-
редаются апериодически. ATM представляет собой интерфейс для широкополос-
ной сети ISDN. В отличие от стандарта Х.25, технология ATM не предоставляет
механизмов контроля ошибок и управления потоком.
Байт (octet). Группа из 8 бит, как правило, обрабатываемая как единое целое.
Бит четности (parity bit)*. Контрольный бит, добавляемый к массиву двоич-
ных цифр таким образом, чтобы сумма всех разрядов массива, включая бит четно-
сти, была всегда четной (или нечетной).
Взаимодействие открытых систем (Open System Interconnection, OSI). Модель
обмена данными между устройствами. Ей определяется семиуровневая архитек-
тура функций обмена данными.
Виртуальный канал (virtual circuit). Служба сети с коммутацией пакетов, в ко-
торой соединение (виртуальный канал) устанавливается между двумя станциями
в начале передачи. Все пакеты следуют по одному и тому же маршруту, поэтому
они не должны содержать полный адрес получателя. Кроме того, все пакеты, следу-
ющие по виртуальному каналу, прибывают к получателю в том же порядке, в кото-
ром они были отправлены.
Словарь специальных терминов 741
Всемирная паутина (World Wide Web, WWW). Сетевая ориентированная на
использование графики гипермедийная система. Хранящаяся на серверах инфор-
мация по сети передается клиентам, на которых отображается специальными при-
кладными программами, называемыми браузерами, в виде страниц, содержащих
текст и изображения.
Высокоуровневый протокол управления каналом (High-level Data Link Control,
HDLC). Распространенный бит-ориентированный протокол передачи данных (уро-
вень 2 модели OSI), выпущенный Международной организацией по стандартиза-
ции (ISO). Схож с протоколами LAPB, LAPD и LLC.
Групповой адрес (multicast address). Адрес, идентифицирующий не одну, а груп-
пу сущностей в пределах домена (например, локальной или объединенной сети).
Дейтаграмма (datagram)*. В сети с коммутацией пакетов пакет, независимый
от других пакетов, в котором содержится информация, достаточная для выбора
маршрута от терминального оборудования, генерирующего данные, до получаю-
щего терминального оборудования без необходимости установки соединения меж-
ду DTE-устройствами и сетью.
Дифференцированные службы (Differentiated Services, DS). Архитектура, в
которой трафик разбивается на несколько групп. Каждая группа помечается соот-
ветствующим образом и каждой группе сетевыми элементами предоставляется
обслуживание, зависящее от членства в группе, так что пакеты, принадлежащие к
разным группам, обрабатываются по-разному. Архитектура дифференцированных
служб не пытается рассматривать весь совокупный трафик в каком-либо едином
смысле, а также не пытается заранее резервировать сетевые ресурсы.
Заголовок (header). Определяемая системой управляющая информация, пред-
шествующая данным пользователя.
Задержка распространения (propagation delay). Интервал времени между мо-
ментом поступления сигнала в канал и моментом его получения.
Звезда (star). Топология, в которой все станции соединены с центральным ком-
мутатором. Обмен данными между двумя станциями осуществляется путем ком-
мутации каналов.
Инкапсуляция (encapsulation). Добавление к данным, получаемым от пользо-
вателя, протокола управляющей информации, выполняемое протокольной сущ-
ностью.
Интегрированные службы (Integrated Services, IS). Архитектура интегриро-
ванных служб предоставляет интегрированные, или коллективные, услуги для
удовлетворения набора требований трафика в данном домене (например, части
Интернета, в которой реализован определенный элемент архитектуры интегриро-
ванных служб). Поставщик интегрированных услуг рассматривает суммарные тре-
бования трафика и, во-первых, ограничивает удовлетворяемый трафик объемами,
соответствующими текущим возможностям сети, во-вторых, резервирует ресурсы
домена для предоставления обслуживания определенного уровня.
Интернет (Internet). Всемирная сеть, основанная на наборе протоколов TCP/IP,
соединяющая тысячи общественных и частных сетей, а также миллионы пользо-
вателей. При написании со строчной буквы (internet) означает объединенную сеть
(см. объединенная сеть).
742
Словарь специальных терминов
Интернет-протокол (Internet Protocol, IP). Межсетевой протокол, поддержи-
вающий не требующую соединений службу между несколькими соединенными
сетями с коммутацией пакетов.
Интранет (intranet). Корпоративная объединенная сеть, обеспечивающая ра-
боту ключевых Интернет-приложений, в частности Всемирной паутины. Интра-
нет функционирует в пределах организации для внутренних целей и может суще-
ствовать как изолированная самостоятельная объединенная сеть или соединяться
с Интернетом.
Кадр (frame). Группа битов, включающих данные, а также один или несколько
адресов и прочую управляющую информацию протокола. Как правило, обознача-
ет протокольный модуль данных (единицу передачи данных) уровня передачи дан-
ных (уровень 2 модели OSI).
Качество обслуживания (Quality of Service, QoS). Означает свойства сети, со-
ответствующие степени удовлетворения требований пользователя относительно
производительности сети. Как правило, при оценке качества обслуживания учи-
тываются четыре параметра: пропускная способность, или скорость передачи дан-
ных; задержка, или время ожидания; флуктуация (неравномерность) задержки и
доля потерянных данных.
Коллизия (collision). Событие, возникающее при одновременной передаче двух
пакетов по общему каналу связи. В результате оба пакета становятся непригодными.
Кольцо (ring). Топология локальной сети, в которой станции соединены с по-
вторителями, образуя замкнутое кольцо. Данные передаются по кольцу в одном
направлении и могут читаться всеми присоединенными станциями.
Коммутация пакетов (packet switching). Метод передачи сообщений по сети,
при котором длинные сообщения разбиваются на короткие пакеты. Затем пакеты
передаются так же, как в сети с коммутацией сообщений.
Коммутируемая сеть (switched communication network). Компьютерная сеть,
состоящая из сети узлов, соединенных двухточечными линиями. Данные от отпра-
вителя к получателю передаются через промежуточные узлы.
Конкуренция (contention). Ситуация, возникающая, когда две или более стан-
ций пытаются одновременно использовать один и тот же канал.
Контроль с помощью циклического избыточного кода (Cyclic Redundancy
Check, CRC). Код обнаружения ошибок; разновидность группового кода, все стро-
ки образующей матрицы которого могут быть получены при помощи циклическо-
го сдвига одной и той же комбинации.
Контрольная последовательность кадра (Frame Check Sequence, FCS). Поме-
хоустойчивый код, вставляемый в виде поля в блок передаваемых данных. Этот
код служит для обнаружения ошибок при приеме кадра.
Контрольная сумма (checksum). Код, используемый для обнаружения ошибок,
основанный на суммировании разрядов контролируемых данных.
Логическое соединение (logical connection)*. Связь, устанавливаемая между
функциональными модулями для передачи данных.
Локальная сеть (Local Area Network, LAN). Сеть, обеспечивающая соединение
обменивающихся данными устройств, расположенных на небольшой территории.
Маркерное кольцо (token ring). Метод управления доступом к несущей для
локальной сети с кольцевой топологией. По кольцу циркулирует маркер (токен).
Словарь специальных терминов 743
Получившая маркер станция может передать пакет, после чего должна отдать мар-
кер другой станции.
Маршрутизатор (router). Устройство объединенной сети, соединяющее две
компьютерных сети. Оно использует межсетевой протокол и предполагает, что все
соединенные устройства сети имеют одну и ту же архитектуру обмена данными и
протоколы. Маршрутизатор функционирует на уровне 3 модели OSL
Маршрутизация (routing). Определение пути для модуля данных (кадра, па-
кета, сообщения) от отправителя к получателю.
Множественный доступ с контролем несущей (Carrier Sense Multiple Access,
CSMA). Метод управления доступом к несущей коллективного доступа. Станция,
желающая передавать данные, сначала опрашивает несущую и начинает передачу,
только если несущая свободна.
Множественный доступ с контролем несущей и обнаружением коллизий
(Carrier Sense Multiple Access with Collision Detection, CSMA/CD). Усовершен-
ствованный метод CSMA, при котором станции прекращают передачу в случае
коллизий.
Мост (bridge)*. Функциональный модуль, соединяющий две локальные сети,
в которых используется одинаковый протокол управления логической связью, но
могут использоваться разные протоколы управления доступом к передающей среде.
Мультиплексирование (multiplexing). В системе передачи данных функция,
позволяющая двум или более источникам данных совместно использовать общий
носитель данных таким образом, что каждый источник данных получает собствен-
ный канал.
Мультиплексирование с временным разделением (Time Division Multiplexing,
TDM). Одновременная передача по двум или более информационным каналам в
рамках одного физического канала.
Немодулированная передача (baseband). Передача сигналов без модуляции.
В сети с передачей немодулированных сигналов цифровые сигналы (1 и 0) пере-
даются напрямую по кабелю в виде импульсов напряжения. Сигнал использует
весь спектр кабеля. Эта схема не допускает частотного мультиплексирования.
Объединенная сеть (internet). Группа сетей с коммутацией пакетов и широкове-
щательных сетей, соединенных друг с другом маршрутизаторами. При написании
с прописной буквы (Internet) означает всемирную сеть Интернет (см. Интернет).
Оконечная система (End System, ES). Устройство, соединенное с одной из
подсетей объединенной сети и используемое для обслуживания приложений или
служб конечных пользователей.
Оконечное оборудование линии передачи данных (Data Circuit-terminating
Equipment, DCE). Оборудование, осуществляющее преобразование сигнала и ко-
дирование, обеспечивая сопряжение терминального оборудования с линией. Око-
нечное оборудование линии передачи данных может быть самостоятельным либо
являться частью терминального или промежуточного оборудования. Оконечное
оборудование линии передачи данных может также выполнять дополнительные
функции, обычно выполняемые на сетевом конце линии.
Остановка с ожиданием (stop and wait). Протокол управления потоком, в ко-
тором отправитель передает блок данных, а затем, прежде чем отправить следую-
щий блок, ждет подтверждения.
744
Словарь специальных терминов
Пакет (packet). Группа битов, включающая данные и управляющую информа-
цию. Как правило, обозначает протокольный модуль данных (единицу передачи
данных) сетевого уровня (уровня 3 модели OSI).
Передача данных, не требующая соединения (connectionless data transfer).
Протокол «стихийного» (без предварительного согласования) обмена данными
(например, дейтаграммами).
Передача данных с установлением соединения (connection-oriented data transfer).
Протокол обмена данными, при котором между оконечными точками устанавли-
вается логическое соединение (например, виртуальный канал).
Пиксел (pixel)*. Минимальный элемент цифрового изображения, которому мо-
жет быть назначен уровень яркости. Пиксел представляет собой отдельную точку
в матричном представлении изображения.
Подсеть (subnetwork). Одна из сетей, составляющих объединенную сеть. Упо-
требление этого термина позволяет избежать двусмысленности, так как с точки
зрения пользователя объединенная сеть представляет собой единую сеть.
Полнодуплексная передача (full-duplex transmission). Одновременная переда-
ча данных в обоих направлениях.
Полудуплексная передача (half-duplex transmission). Поочередная передача
данных в каждом из направлений.
Помехоустойчивый код (error detecting code)*. Код, строящийся по определен-
ным правилам и содержащий определенное количество избыточной информации,
что позволяет обнаруживать или исправлять ошибки.
Порт (port). Средство идентификации пользователя протокольной службы.
Протокольная сущность предоставляет один или несколько номеров портов для
использования сущностями более высокого уровня. Эквивалентным термином в эта-
лонной модели OSI является точка доступа к службе (Service Access Point, SAP).
Порядковый номер (sequence number). Число, содержащееся в заголовке про-
токольного модуля данных (единицы передачи данных), служащее (отдельно или
вместе с другими полями заголовка) для однозначной идентификации этого мо-
дуля данных в последовательности протокольных модулей данных.
Прикладной уровень (application layer). Уровень 7 в модели OSI. Этот уровень
определяет интерфейс системы с пользователем.
Протокол (protocol). Набор правил, управляющий работой функциональных
модулей и обеспечивающий обмен данными.
Протокольный модуль данных (Protocol Data Unit, PDU)*. Единица переда-
чи данных, состоящая из управляющей информации протокола этого уровня, а так-
же, возможно, данных пользователя этого уровня.
Ретрансляция кадров (frame relay). Форма коммутации пакетов, связанная с
использованием кадров переменного размера на уровне передачи данных. В сети
ретрансляции кадров нет сетевого уровня, кроме того, для повышения производи-
тельности упрощены или исключены многие базовые функции.
Ретрансляция ячеек (cell relay). Механизм коммутации пакетов фиксирован-
ного размера, называемых ячейками. Эта технология применяется в ATM.
Сеансовый уровень (session layer). Уровень 5 модели OSI. Управляет логичес-
ким соединением (сеансом) между двумя процессами или приложениями, обме-
нивающимися данными.
Словарь специальных терминов 745
Сетевой уровень (network layer). Уровень 3 модели OSI. Отвечает за маршру-
тизацию данных в сети.
Сеть связи (communication network). Множество соединенных друг с другом
функциональных модулей, предоставляющих услуги по обмену данными между
станциями, присоединенными к сети.
Синхронное мультиплексирование с временным разделением (synchronous
time division multiplexing). Разновидность мультиплексирования с временным раз-
делением, при которой интервалы времени для доступа к общему носителю дан-
ных предоставляются каналам ввода-вывода на заранее определенной основе.
Скользящее окно (sliding window). Метод управления потоком, при котором
передающая станция может посылать нумерованные пакеты в пределах определен-
ного диапазона номеров. Окно динамически изменяется для передачи дополни-
тельных пакетов.
Согласование битов (bit stuffing). Включение в поток данных дополнительных
битов, чтобы не допустить появления в потоке управляющих последовательностей.
Статистическое мультиплексирование с временным разделением (statistical
time division multiplexing). Разновидность мультиплексирования с временным раз-
делением, при котором интервалы времени для доступа к общему носителю дан-
ных предоставляются каналам ввода-вывода по требованию.
Терминальное оборудование (Data Terminal Equipment, DTE)*. Оборудова-
ние, состоящее из оконечных цифровых инструментов, преобразующее инфор-
мацию пользователя в передаваемые сигналы, а получаемые сигналы в данные
пользователя.
Топология (topology). Применительно к компьютерным сетям, геометрическая
конфигурация (форма) сети, рассматриваемой в виде графа, состоящего из линий
связи и узлов.
Точка доступа к службе (Service Access Point, SAP). См. порт.
Точка-точка (point-to-point). Конфигурация, в которой две станции напрямую
соединяются линиями связи.
Транспортный уровень (transport layer). Уровень 4 эталонной модели OSI. Пре-
доставляет надежную и прозрачную передачу данных между оконечными точками.
Управление доступом к носителю (Medium Access Control, МАС). Применяе-
мый в широковещательных сетях метод определения устройства, которое может
получить доступ к передающей среде.
Управление потоком (flow control). Выполняемая получающей сущностью
функция, ограничивающая объем или скорость передачи данных от передающей
сущности.
Управляющая информация протокола (protocol control information)*. Инфор-
мация, позволяющая координировать совместную работу. Этой информацией об-
мениваются сущности данного уровня при помощи службы, предоставляемой бли-
жайшим более низким уровнем.
Уровень адаптации ATM (ATM Adaptation Level, AAL). Уровень, обеспечива-
ющий сопряжение между протоколами передачи информации и уровнем ATM.
Уровень передачи данных (data link layer)*. В архитектуре OSI уровень, пре-
доставляющий услуги по передаче данных между двумя сущностями сетевого
746
Словарь специальных терминов
уровня, как правило, соседними узлами сети. Уровень передачи данных обнару-
живает и по возможности исправляет ошибки, которые возникают на физическом
уровне.
Уровень представления (presentation layer)*. Уровень 6 модели OSI. Обеспе-
чивает выбор общей синтаксической формы представления данных и преобразо-
вания прикладных данных в эту форму и обратно.
Уровень (layer)*. Обладающая концептуальной полнотой группа служб, функ-
ций и протоколов из набора иерархически организованных групп сетевой архи-
тектуры.
Физический уровень (physical layer). Уровень 1 модели OSI. К этому уровня
относятся электрические, механические и временные аспекты передачи сигнала
по носителю.
Частота ошибок (error rate)*. Отношение числа модулей данных с ошибками
к общему числу модулей данных.
Шина (bus)*. Один или несколько проводников, служащих для соединения
группы устройств.
Широковещание (broadcast). Одновременная передача данных нескольким
станциям.
Широковещательная сеть связи (broadcast communication network). Сеть свя-
зи, в которой передача данных осуществляется путем широковещательной рассыл-
ки и принимается всеми остальными станциями.
Широковещательный адрес (broadcast address). Адрес, идентифицирующий
сразу все станции домена (например, сети или объединенной сети).
Сокращения1
Сокр. Термин Перевод
AAL ATM Adaptation Level Уровень адаптации ATM
АВМ Asynchronous Mode Balanced Асинхронный сбалансированный режим
ABR Available Bit Rate Доступная битовая скорость
ACR Allowed Cell Rate Допустимая скорость ячеек
ADU Application-level Data Unit Модуль данных прикладного уровня
AF Assured Forwarding Гарантированное продвижение данных
ANSI American National Standards Institute Американский национальный институт стандартоа
АР Access Point Точка доступа
API Application Programming Interface Программный интерфейс приложений
ARPA Advanced Research Projects Agency Управление перспективного планирования научно-исследовательских работ
ARQ Automatic Repetition Query Автоматический запрос на повторение
ARTT Average Round-Trip Time Среднее время распространения сигнала в оба конца
AS Applicability Statement Технические условия
AS Autonomous System Автономная система
ATM Asynchronous Transfer Mode Асинхронный режим передачи
BA Behavior Aggregate Агрегат поведения
BCP Best Current Practice Оптимальное установившееся положение дел
BCS Behavior Class Selector Селектор класса поведения
BECN Backward Explicit Congestion Notification Обратное явное уведомление о перегрузке
BFS Breadth-First Search Поиск в ширину
BGP Border Gateway Protocol Протокол пограничного шлюза
B-ISDN Broadband ISDN Широкополосная сеть ISDN
BOM Beginning Of Message Начало сообщения
BRFO Bit-Round Fair Queuing Справедливая организация очередей с побитовым циклом
BRM Backward Resource Management Обратное управление ресурсами
BSD Berkeley Software Distribution sockets Сокеты Беркли
BSS Basic Service Set Базовый набор служб
ВТ Burst Tolerance Допуск на всплеск
1 Поскольку автор использовал гораздо больше аббревиатур, чем было перечислено в списке сокраще-
ний оригинального издания, мы сочли возможным дополнить этот список. — Примеч. ред.
748 Сокращения
Сокр. Термин Перевод
BWT Burrows-Wheeler Transform Преобразование Бэрроуза — Уилера
САС Connection Admission Control Управление допуском соединения
CAD Computer-Aided Design Автоматизированное проектирование
САРС Congestion Avoidance using Proportional Control Предотвращение перегрузки путем пропорционального управления
CBR Constant Bit Rate Постоянная битовая скорость
CCITT Consultative Committee for International Telephone and Telegraphy Международный консультативный комитет по телефонии и телеграфии
ССТ Controlled Cell Transfer Управляемая передача ячеек
CD Carrier Sense Контроль несущей
CDV Cell Delay Variation Разброс задержек передачи ячеек
CDVT Cell Delay Variation Tolerance Допуск на разброс задержек передачи ячеек
CERN Conseil Europeen pour la Recherche Nucleaire Европейский центр ядерных исследований
CIR Committed Information Rate Согласованная скорость передачи информации
CIX Commercial Information Exchange Коммерческий информационный обмен
CLP Cell Loss Priority Приоритет потери ячеек
CLR Cell Loss Ratio Коэффициент потерянных ячеек
CM Control Module Управляющий модуль
COM Continuation Of Message Продолжение сообщения
CPCS Common Part Convergence Sublayer Общая часть подуровня конвергенции
CRC Cyclic Redundancy Check Контроль с помощью циклического избыточного кода
CS Convergence Sublayer Подуровень конвергенции
CSI Convergence Sublayer Indication Индикация подуровня конвергенции
CSMA/ Carrier Sense Multiple Access Множественный доступ с контролем
CD with Collision Detection несущей и обнаружением коллизий
CTD Cell Transfer Delay Задержка передачи ячеек
DCE Data Circuit-terminating Equipment Оконечное оборудование линии передачи данных
DCF Distributed Coordination Function Функция распределенной координации
DCT Discrete Cosine Transform Дискретное косинусное преобразование
DE Discard Eligibility Разрешение на отбрасывание (кадроа)
DLCI Data Link Connection Identifier Идентификатор соединения уровня передачи данных
DLL Dynamic Link Library Динамически подключаемая библиотека
DM Disconnected Mode Разъединенный режим
DPF Down Pressure Factor Коэффициент вертикального давления
DS Differentiated Services Дифференцированные службы
DS Distribution System Распределительная система
DSSS Direct-Sequence Spread Spectrum Расширенный спектр прямого распространения
DTE Data Terminal Equipment Терминальное оборудование
Сокращения 749
Сокр. Термин Перевод
DVD Digital Video Disk Цифровой видеодиск
DWT Discrete Wavelet Transform Дискретное аолновое преобразование
EF Expedited Forwarding Срочное продвижение данных
EFCI Explicit Forward Congestion Indication Явное прямое уведомление о перегрузке
EGP Exterior Gateway Protocol Протокол внешнего шлюза
EIA Electronics Industries Association Ассоциация электронной промышленности
EOL End Of Line Конец строки
EOM End Of Message Конец сообщения
EPD Early Packet Discard Раннее отбрасывание пакетов
EPRCA Enhanced Proportional Rate Control Algorithm Усовершенствованный пропорциональный алгоритм управления скоростью
ERICA Explicit Rate Indication for Congestion Avoidance Явное указание скорости для предотвращения перегрузки
ERP Exterior Routing Protocol Протокол внешней маршрутизации
ES End System Оконечная система
ESS Extended Service Set Расширенный набор служб
FBA Fair Buffer Allocation Справедливое выделение буфера
FBM Fractional Brownain Motion Дробное броуновское движение
FCS Frame Check Sequence Контрольная последовательность кадра
FEC Forwarding Equivalence Class Класс эквивалентности продвижения данных
FECN Forward Explicit Congestion Notification Прямое явное уведомление о перегрузке
FF Fixed Filter Фиксированный фильтр
F-GCRA Frame-based Generic Cell Rate Algorithm Общий алгоритм скорости ячеек для кадров
FHSS Frequency-Hopping Spread Spectrum Расширенный спектр со скачкообразной перестройкой частоты
FIFO First In First Out Первым прибыл — первым обслужен
FO Fair Queuing Справедливая организация очередей
FRM Forward Resource Management Прямое управление ресурсами
FTP File Transfer Protocol Протокол передачи файлов
GCRA Generic Cell Rate Algorithm Общий алгоритм скорости ячеек
GFC Generic Flow Control Общее управление потоком
GFR Guaranteed Frame Rate Гарантированная скорость кадров
GPS Generalized Processor Sharing Обобщенное разделение процессора
HDLC High-level Data Link Control Высокоуровневый протокол управления каналом
НЕС Header Error Control Контрольная сумма заголовка
HHUB Header HUB Головной хаб
HTTP Hypertext Transfer Protocol Протокол передачи гипертекста
IAB Internet Activities Board Совет по функционированию Интернета
IANA Internet Assigned Numbers Authority Уполномоченная организация по выделению номеров Интернета
ICMP Internet Control Message Protocol Протокол управления сообщениями в объединенных сетях
750 Сокращения
1
Сокр. Термин Перевод j
ICR Initial Cell Rate Начальная скорость ячеек * Д -
IDN Integrated Digital Network Интегрированная цифровая сеть И
IDRP Inter-Domain Routing Protocol Протокол внутридоменной маршрутизации
IESG Internet Engineering Steering Group Ведущая группа инженерной поддержки
Интернета
IETF Internet Engineering Task Force Проблемная группа инженерной
поддержки Интернета
IGMP Internet Group Management Protocol Протокол управления группами
в объединенных сетях
IGP Interior Gateway Protocol Протокол внутреннего шлюза
IHL Internet Header Length Длина Интернет-заголовка
IHUB Intermediate HUB Промежуточный хаб
IP Internet Protocol Интернет-протокол
IPng Internet Protocol, next generation Интернет-протокол нового поколения
IRP Interior Routing Protocol Протокол внутренней маршрутизации
IRP Routing Information Protocol Протокол маршрутной информации
IS Integrated Services Интегрированные службы
IS Intermediate System Промежуточная система
ISA Integrated Services Architecture Архитектура интегрированных служб
ISDN Integrated Services Digital Network Цифровая сеть с интегрированными
службами
ISI Information Sciences Institute Институт кибернетики
ISN Initial Sequence Number Начальный порядковый номер
ISO International Organization for Standardization Международная организация
по стандартизации
ITU International Telecommunications Union Международный союз телекоммуникаций
ITU-T International Telecommunications Международный союз
Union-Telecommunications телекоммуникаций — сектор
телекоммуникаций
JBIG Joint Bi-Level Image experts Group Объединенная группа экспертов
по двухуровневой обработке изображений
JPEG Joint Photography Experts Group Объединенная группа экспертов
по обработке фотоизображений
LAPB Link Access Protocol-Balanced Сбалансированный протокол доступа
к каналу связи
LAPF Link Access Procedure for Frame Процедура доступа к каналу
mode bearer services для канальных служб в режиме кадров
LDP Label Distribution Protocol Протокол распределения меток
LF Load Factor Коэффициент загрузки
LI Length Indication Индикация длины
LIFO Last In First Out Последним прибыл — первым обслужен
LLC Logical Link Control Управление логическим соединением
LSR Label Switching Router Маршрутизатор, коммутирующий
по меткам
MAC Medium Access Control Управление доступом к носителю /
Сокращения 751
Сокр. Термин Перевод
MACR Mean Allowed Cell Rate Средняя допустимая скорость ячеек
МАЕ Metropolitan Area Exchange Региональный обменный узел
MAN Metropolitan Area Network Региональная сеть
maxCTD Maximum Cell Transfer Delay Максимальная задержка передачи ячеек
MBS Maximum Burst Size Максимальный размер всплеска
MCR Minimum Cell Rate Минимальная скорость ячеек
MDCR Minimum Desired Cell Rate Минимальная желаемая скорость ячеек
MFS Maximum Frame Size Максимальный размер кадра
MID Multiplexing Identification Идентификатор мультиплексирования
MLP Multilink Protocol Многоканальный протокол
MMR Modified Modified READ Дважды модифицированный код READ
MNP Microcom Network Protocol Сетевой протокол от Microcom
MOSPF Multicast OSPF Протокол OSPF для групповой рассылки
MPEG Motion Pictures Experts Group Группа экспертов по движущимся изображениям
MPLS Multiprotocol Label Switching Многопротокольная коммутация по меткам
MPOA Multiprotocol encapsulation Over ATM Многопротокольная инкапсуляция поверх ATM
MR Modified READ Модифицированный код READ
MTU Maximum Transmission Unit Максимальная единица передачи
NCSA National Center for Supercomputing Applications Национальный центр по применению суперкомпьютеров
NLRI Network Layer Reachability Information Информация о доступности сетевого уровня
nrt-VBR Non-real-time Variable Bit Rate Переменная битовая скорость не реального времени
NSF National Science Foundation Национальный научный фонд США
OAM Operations, Administration and Maintenance Операции, администрирование и поддержка
OFDM Orthogonal Frequency Division Multiplexing Мультиплексирование путем ортогонального разделения частоты
OSI Open System Interconnection Взаимодействие открытых систем
OSPF Open Shortest Path First Первоочередное открытие кратчайших маршрутов
PAD Packet Assembler/Disassembler Сборщик/разборщик пакетов
PCF Point Coordination Function Функция точечной координации
PCR Peak Cell Rate Пиковая скорость ячеек
PDU Protocol Data Unit Протокольный модуль данных
pel Picture element Элемент изображения, или пел
PGPS Packet-by-packet Generalized Processor Sharing Попакетное обобщенное разделение процессора
PHB Per-Нор Behavior Поведение на ретрансляционных участках
PIM Protocol Independent Multicast Независимая от протокола групповая рассылка
PPD Partial Packet Discard Частичное отбрасывание пакетов
752 Сокращения
Сокр. Термин Перевод
PPP Point-to-Point Protocol Протокол двухточечного соединения
PS Processor Sharing Разделение процессора
PVC Permanent Virtual Circuit Постоянный виртуальный канал
QoS Quality of Service Качество обслуживания
RDF Rate Decrease Factor Коэффициент уменьшения скорости
READ Relative Element Address Designate Относительное назначение адресов элементов
RED Random Early Detection Случайное раннее обнаружение
RFC Request for Comment Запрос комментариев
RGB Red, Green, Blue Красный, зеленый, синий
RIF Rate Increase Factor Коэффициент увеличения скорости
RM Resource Management Управление ресурсами
RO1 Region Of Interest Область интереса
RP Rendezvous Point Точка встречи
RPC Remote Procedure Call Удаленный вызов процедур
RSVP Resource Reservation Protocol Протокол резервирования ресурсов
RTCP RTP Control Protocol Управляющий протокол RTP
RTO Retransmission Timeout Тайм-аут повторной передачи
RTP Real-time Transport Protocol Транспортный протокол реального времени
RTT Round-Trip Time Время распространения сигнала в оба конца
rt-VBR Real-time Variable Bit Rate Переменная битовая скорость реального времени
SAP Service Access Point Точка доступа к службе
SAR Segmentation And Reassembly sublayer Подуровень сегментации и восстановления
SCR Sustainable Cell Rate Установившаяся скорость ячеек
SCSI Small Computer Systems Interface Интерфейс малых компьютерных систем
SDH Synchronous Digital Hierarchy Синхронная цифровая иерархия
SDU Service Data Unit Служебный модуль данных
SE Shared-Explicit Совместный явный (стиль фильтрации)
SFD Start Frame Delimiter Ограничитель начала кадра
SLA Service Level Agreement Соглашение об уровне обслуживания
SMTP Simple Mail Transfer Protocol Простой протокол электронной почты
SN Sequence Number Последовательный номер
SNA System Network Architecture Системная сетевая архитектура
SNMP Simple Network Management Protocol Простой протокол сетевого управления
SNP Sequence Number Protection Защита последовательного номера
SONET Synchronous Optical Network Синхронная оптическая сеть
SRTT Smoothed Round-Trip Time estimate Сглаженная оценка времени распространения сигнала в оба конца
SS7 Signaling System 7 Сигнальная система 7
SSG Special Study Group Специальная исследоаательская группа
Сокращения 753
Сокр. Термин Перевод
SSM Single Sequence Message Одиночное последовательное сообщение
SSRC Synchronization Source Источник синхронизации
STP Shielded Twisted Pair Экранированная витая пара
SVC Switched Virtual Circuit Коммутируемый виртуальный канал
sws Silly Window Syndrome Синдром глупого окна
TAT Theoretical Arrival Time Теоретическое время прибытия
TCA Traffic Conditioning Agreement Соглашение о согласовании трафика
TCP Transmission Control Protocol Протокол упрааления передачей
TCP/IP Transmission Control Protocol/ Internet Protocol Протокол управления передачей/ Интернет-протокол
TDM Time Division Multiplexing Мультиплексирование с временным разделением
TOS Type Of Service Тип службы
TPAL Total Path Attributes Length Полная длина атрибутов пути
TS Technical Specification Техническая спецификация
TTL Time To Live Время жизни
UBR Unspecified Bit Rate Неуказанная битовая скорость
UDP User Datagram Protocol Пользовательский протокол дейтаграмм
UM User Module Пользовательский модуль
UNI User-to-Network Interface Интерфейс пользователь — сеть
UPC Usage Parameter Control Контроль параметров использования
URL Uniform Resource Locator Унифицированный указатель информационного ресурса
UTP Unshielded Twisted Pair Неэкранированная витая пара
VBR Variable Bit Rate Переменная битовая скорость
VC Virtual Channel Виртуальный канал
VCC Virtual Channel Connection Соединение виртуального канала
VCI Virtual Channel Identifier Идентификатор виртуального канала
VPC Virtual Path Connection Соединение виртуального пути
VPI Virtual Path Identifier Идентификатор виртуального пути
VPN Virtual Private Network Виртуальная частная сеть
WECA Wireless Ethernet Compatibility Alliance Союз совместимости беспроводных сетей Ethernet
WF Wild Card Главная карта, или джокер
WFQ Weighted Fair Queuing Взвешенная справедливая организация очередей
WinSock Windows Sockets Сокеты Windows
WWW World Wide Web Всемирная паутина
Список литературы
В делах подобного рода каждый чувствует себя вправе на-
писать и опубликовать первое, что придет в голову, стоит
лишь взять в руку перо, полагая при этом свои представле-
ния столь же очевидными, как тот факт, что дважды два рав-
но четырем. Если бы критики взяли на себя многолетний
труд досконального обдумывания данного предмета и про-
верки каждого умозаключения па исторических фактах, как
это делал я, они бы безо всякого сомнения были более ос-
мотрительными в своих высказываниях.
Карл фон Клаузевиц. О войне
1. 10 Gigabit Ethernet Alliance. 10 Gigabit Ethernet — An Introduction. White pa-
per, September 20, 2000.
2. Adler, R.; Feldman, R.; and Taqqu, M. A Practical Guide to Heavy Tails: Statisti-
cal Techniques and Applications. Boston: Birkhauser, 1998.
3. Allen, A. «Queuing Models of Computer Systems». Computer, April 1980.
4. Allman, M., and Falk, A. «On the Effective Evaluation of TCP». Computer
Communication Review, October 1999.
5. Almeroth, K. «The Evolution of Multicast: From the Mbone to Interdomain
Multicast to Internet2 Deployment». IEEE Network, January/February 2000.
6. Andleigh, P., and Thakrar, K. Multimedia Systems Design. Upper Saddle River.
NJ: Prentice Hall, 1996.
7. Andrikopoulos, L; Liakopoulous, A.; Pavlou, G.; and Sun, Z. «Providing Rate
Guarantees for Internet Application Traffic Across ATM Networks». IEEE Com-
munications Surveys,Quarter 1999. http://www.comsoc.org/pubs/surveys.
8. Aras, C.; Kurose, J.; Reeves, D.; and Schulzrinne, H. «Real-Time Communica-
tion in Packet-Switched Networks». Proceedings of the IEEE, January 1994.
9. Aravind, R., et al. «Image and Video Coding Standards». AT&T TechnicalJour-
nal, January/February, 1993.
10. Arlitt, M.; Friedrich, R.; and Jin, T. «Workload Characterization of a Web Proxy
in a Cable Modem Environment». ACM Performance Evaluation Review, Septem-
ber 1999.
11. Arlitt, M„ and Jin, T. «А Workload Characterization Study of the 1998 World
Cup Web Site». IEEE Network, May/June, 2000.
Список литературы 755
12. Armitage, G., and Adams, К. «Packet Reassembly During Cell Loss». JEFF Net-
work, September 1993.
13. Armitage, G. Quality of Service in IP Networks. Indianapolis, IN: Macmillan Tech-
nical Publishing, 2000.
14. Arps, R.; and Truong, T. «Comparison of International Standards for Lossless
Still Image Compression». Proceedings of the IEEE, June 1994.
15. Arulambalam, A.; Chen, X.; and Ansari, N. «Allocating Fair Rates for Available
Bit Rate Service in ATM Networks». IEEE Communications Magazine, Novem-
ber 1996.
16. Ash, R. Information Theory. New York: Dover, 1990.
17. ATM Forum. User-Network Interface (UNI) Specification Version 3.1. Septem-
ber 1994.
18. ATM Forum. Traffic Management Specification Version 4.1. March 1999.
19. Balakrishnan, H„ et al. «TCP Behavior of a Busy Web Server». Proceedings, IEEE
INFOCOM, March 1998.
20. Battista, S.; Casalio, F.; and Lande, C. «MPEG-4: A Multimedia Standard for
the Third Millenium, Part 1». IEEE Multimedia, October-December 1999.
21. Battista, S.; Casalio, F.; and Lande, C. «MPEG-4: A Multimedia Standard for
the Third Millenium, Part 2». IEEE Multimedia, .January — March 2000.
22. Benice, R. «An Analyses of Retransmission Systems». IEEE Transactions on Com-
munication Technology, December 1964.
23. Bennett, J.; Partridge, C.; and Shectman, N. «Packet Reordering is Not Patho-
logical Network Behavior». IEEE/АСМ Transactions on Networking, December 1999.
24. Ъегъп,}. Statistics for Long-Memory Processes.NexvNorV. Chapman and Hall, 1994.
25. Beran, J., Sherman, M., Taqqu, S„ and Willinger, W. «Long-Range Dependence
in Variable-Bit-Rate Video Traffic». IEEE Transactions on Communications, Feb-
ruary 1995.
26. Bergman, W. «Narrowband Frame Relay Congestion Control». Proceedings of the
Tenth Annual Phoenix Conference of Computersand Communications, March 1991.
27. Bernet, Y. «The Complementary Roles of RSVP and Differentiated Services in
the Full-Service Qos Network». IEEE Communications Magazine, February 2000.
28. Bertsekas, D„ and Gallager, R. Data Networks. Englewood Cliffs, NJ: Prentice
Hall, 1992.
29. Black, U. Frame Relay Networks. New York: McGraw-Hill, 1998.
30. Black, V. ATM Volume I: Foundation for Broadband Networks. Upper Saddle Riv-
er, NJ: Prentice Hall, 1992.
31. Black, U. IP Routing Protocols: RIP, OSPF, BGP, PNNI & Cisco Routing Proto-
cols. Upper Saddle River, NJ: Prentice Hall, 2000.
32. Black, U. MPLS and Label Switching Networks. Upper Saddle River, NJ: Prentice
Hall, 2001.
756
Список литературы
33. Bonaventure, О., and Nelissen, J. «Guaranted Frame Rate: A Better Service for
TCP/IP in ATM Networks». IEEE Network, January/February 2001.
34. Bonomi, F., and Fendick, K. «The Rate-Based Flow Control Framework for the
Available Bit Rate ATM Service». IEEE Network, March/April 1995.
35. Borella, M., and Brewster, G. «Measurement and Analyses of Long-Range Packet
Dependent Behavior of Internet Packet Delay». IEEEINFOCOM ’98, April 1998.
36. Borthick, S. «Today’s Internet Can’t Scale». Business Communications Review,
May 2001.
37. Box, G.; Jenkins, G.; and Riensel, G. Time Series Analyses: Forecasting and Con-
trol. Upper Saddle River, NJ: Prentice Hall, 1994.
38. Breyer, R., and Riley, S. Switched, Fast, and Gigabit Ethernet. New York: Mac-
millan Technical Publishing, 1999.
39. Bruce, A.; Donoho, D.; and Gao, H. «Wavelet Analysis». IEEE Spectrum, Octo-
ber 1996.
40. Buckwaiter, J. Frame Relay: Technology and Practice. Reading, MA: Addison-
Wesley, 2000.
41. Bulmer, M. Principles of Statistics. New York: Dover, 1979.
42. Burg, J., and Dorman, D. «Broadband ISDN Resource Management: The Role
of Virtual Paths». IEEE Communications Magazine, September 1991.
43. Bux, W.; Kummerle, K.; and Truong, H. «Balanced HDLC Procedures: A Per-
formance Analysis». IEEE Transactions on Communications, November 1980.
44. Cerf, and Kahn, R. «А Protocol for Packet Network Interconnection». IEEE
Transactions on Communications, May 1974.
45. Chartrand, G. Introductory Graph Theory. New York: Dover, 1977.
46. Chen, К.; Ho, K.; and Saksena, V. «Analysis and Design of a Highly Reliable
Transport Architecture for ISDN Frame-Relay Networks». IEEEJournal on Se-
lected Areas in Communications Magazine, October 1989.
47. Chen, К.; Ho, K.; and Samalam, V. «The Available Bit Rate Service for Data in
ATM Networks». IEEE Communications Magazine, May 1996.
48. Chiariglione, L. «The Impact of MPEG Standards on Multimedia Industry».
Proceedings of the IEEE, June 1998.
49. Christopoulos, C.; Skodras, A.; and Ebrahimi, T. «The JPEG2000 Still Image
Coding System: An Overview». IEEE Transactions on Consumer Electronics, No-
vember 2000.
50. Clark, D. «The Design Philosophy of the DARPA Internet Protocols». Proceed-
ings, SIGCOMM '88, Computer Communication Review, August 1988: reprinted
in Computer Communication Review, January' 1995.
51. Clark, D. «Architectural Considerations for a New Generation of Protocols».
Proceedings, SIGCOMM ’90, Computer Communication Review, September 1990.
52. Clark, D.; Shenker, S.; and Zhang, L. «Supporting Real-Time Applications in an
Integrated Services Packet Network: Architecture and Mechanism». Proceedings,
SIGCOMM ’92, August 1992.
Список литературы 757
53. Clark, D. Adding Service Discrimination to the Internet. MIT Laboratory for
Computer Science Technical Report, September 1995. Available at http://ana-
www.lcs.mit.edu/anaweb/papers.html.
54. Clark, D., and Fang, W. «Explicit Allocation of Best-Effort Packet Delivery Serv-
ice». IEEE/АСМ Transactions on Networking, August 1998.
55. Cohen, J. «Rule Reversal: Old 80/20 LAN Traffic Model Is Getting Turned on
Its Head». Network World, December 16,1996.
56. Comer, D.; and Lin, J. «TCP Buffering and Performance Over an ATM Net-
work». Internetworking: Research and Experience, March 1995.
57. Comer, D.; and Steven, D. Internetworking with TCP/IP, Volume II: Design Im-
plementation, and Internals. Upper Saddle River, NJ: Prentice Hall, 1994.
58. Comer, D.; and Steven, D. Internetworking with TCP/IP, Volume III: Client-Serv-
er Programming and Applications. Upper Saddle River, NJ: Prentice Hall, 2001.
59. Comer, D. Internetworking with TCP/IP, Volume I: Principles, Protocols, and Ar-
chitecture. Upper Saddle River, NJ: Prentice Hall, 2000.
60. Cormen, T.; Leiserson, C.; and Rivest, R. Introduction to Algorithms. Cambridge,
MA: MIT Press, 1990.
61. Cover, T., and Thomas, J. Elements of Information Theory.New York: Wiley, 1991.
62. Croll, A., and Packman, E. Managing Bandwidth: Deploying QoS in Enterprise
Networks. Upper Saddle River, NJ: Prentice Hall, 2000.
63. Crovella, M., and Bestavros, A. «Self-Similarity in World-Wide Web Traffic:
Evidence and Possible Causes». Proceedings, ACM Sigmetrics Conference on
Measurement and Modeling of Computer Systems, May 1996.
64. Crowcroft, J.; Wakeman, L; Wang, Z.; and Sirovica, D. «Is Layering Harmful?»
IEEE Network Magazine, January 1992.
65. Crow, B., et al. «IEEE 802.11 Wireless Local Area Networks». IEEE Communi-
cations Magazine, September 1997.
66. Cruz, D.; Ebrahimi, T.; and Christopoulos, C. «The JPEG 2000 Image Coding
Standard». Dr. Dobb’sJournal, April 2001.
67. Deane, J.; Smythe, C.; and Jefferies, D. «Self-Similarity in a Deterministic Mod-
el of Data Transfer». International Journal of Electronics, No.5,1996.
68. Deering, S., and Cheriton, D. «Multicast Routing in Datagram Internetworks
and Extended LANs». ACM Transactions on Computer Systems, May 1990.
69. Deering, S., et al. «The PIM Architecture for Wide-Area Multicast Routing».
IEEE/ACM Transactions on Networking, April 1996.
70. Demers, A.; Keshav, S.; and Shenker, S. «Analysis and Simulation of a Fair Queue-
ing Algorithm». Internetworking: Research and Experience, September 1990.
71. Dijkstra, E. «А Note on Two Problems in Connection with Graghs». Numerical
Mathematics, October 1959.
72. Doshi, B., and Nguyen, H. «Congestion Control in ISDN Frame-Relay Networks».
AT&T TechnicalJournal, November/December 1988.
758
Список литературы
73. Duffy, D.; McIntosh, A.; Rosenstein, M.; and Willinger, W. «Statistical Analysis
of CCSN/SS7 Traffic Data from Working CCS Subnetworks». IEEEJournal on
Selected Areas in Communications, April 1994.
74. The Economist. «Upgrading the Internet». March 24, 2001.
75. Erramilli, A.; Gordon, J.; and Willinger, W. «Applications of Fractals in Engi-
neering for Realistic Traffic Processes». Proceedings, International Telecommuni-
cations Conference (ITC-14), Amsterdam: Elsevier, 1994.
76. Erramilli, A. (session organizer). «Performance Impact of Self-Similarity in Traf-
fic». Proceedings, Sigmetrics 95/Performance ’95, May 1995.
77. Erramilli, A.; Narayan, O.; and Willinger, W. «Experimental Queueing Analysis
with Long-Range Dependent Packet Traffic». IEEE/АСМ Transactions on Net-
working, April 1996.
78. Falconer, K. Fractal Geometry: Mathematical Foundations and Applications. New
York: Wiley, 1990.
79. Fang, C.; Chen, EL; and Hutchings, J. «А Simulation Study of TCP Performance
in ATM Networks». Proceedings, GLOBENCOM 94,1994.
80. Fang, C„ and Lin, A. On TCP Performance of UBR with EDP and UBR-EDP with
a Fair Buffer Allocation Scheme. ATM Forum Contribution 95-1645, December 1995.
81. Fibre Channel Association. Fibre Channel: Connection to the Future. Austin, TX:
Fibre Channel Association, 1998.
82. Feder, J. Fractals. New York: Plenum Press, 1989.
83. Floyd, S., and Jacobson, V. «Random Early Detection Gateways for Congestion
Avoidance». IEEE/АСМ Transactions on Networking, August 1993.
84. Floyd, S., and Fall, K. «Router Mechanism to Support End-to-End Congestion
Control». Proceedings, SIGCOMM 97,1997.
85. Floyd, S. «А Report on Some Recent Developments in TCP Congestion Con-
trol». IEEE Communications Magazine, April 2001.
86. Ford, L., and Fulkerson, D. Flows in Networks. Princeton, NJ: Princeton Univer-
sity Press, 1962.
87. Frazier, H., and Johnson, H. «Gigabit Ethernet: From 100 to 1,000 Mbps». IEEE
Internet Computing, January/February 1999.
88. Gallager, R. Information Theory and Reliable Communication. New York: Wiley, 1968.
89. Gall, D. «MPEG: A Video Compression Standard for Multimedia Applications».
Communications of the ACM, April 1991.
90. Garrett, M., and Willinger, W. «Analysis, Modeling, and Generation of Self-Sim-
ilar VBR Video Traffic». Proceedings, SIGCOMM 94, August 1994.
91. Garrett, M. «А Service Architecture for ATM: From Applications to Schedul-
ing». IEEE Network, May/June 1996.
92. Geier, J. Wireless LANs. New York: Macmillan Technical Publishing, 1999.
93. Gerla, M., and Kleinrock, L. «Flow Control: A Comparative Survey». IEEE Trans-
actions on Communications, April 1980.
Список литературы 759
94. Gersht, A. and Lee, К. «А Congestion Control Framework for ATM Networks».
IEEE Journal on Selected Areas in Communications, September 1991.
95. Giroux, N., and Ganti, S. Quality of Service in ATM Networks. Upper Saddle Riv-
er, NJ: Prentice Hall 1999.
96. Goldberg, S. Probability: An Introduction. New York: Dover, 1987.
97. Goralski, W. Frame Relay for High-Speed Networks. New York: Wiley 1999.
98. Goyal, R., et al. «UBR+: Improving Performance of TCP over ATM-UBR Serv-
ice». Proceedings, ICC ’97, June 1997.
99. Goyal, R., et al. «Providing Rate Guarantees to TCP over the ATM GFR Serv-
ice». Proceedings of the Local Computer Networks Conference, October 1998.
100. Greenberg, A., and Madras, N. «How Fair is Fair Queueing?» Journal of the ACM,
July 1992.
101. Grimmett, G., and Stirzaker, D. Probability and Random Processes. Oxford: Ox-
ford University Press, 1992.
102. Grossglauser, M., and Bolot, J. «On the Relevance of Long-Range Dependence
in Network Traffic». Proceedings, SIGCOMM ’96, August 1996.
103. Gross, D., and Harris, C. Fundamentals of Queueing Theory. New York: Wiley, 1998.
104. Grossglauser, M., and Bolot, J. «On the Relevance of Long-Range Dependence
in Network Traffic». IEEE/ACM Transactions on Networking, October 1999.
105. Gross, J., and Yellen, J. Graph Theory and Its Applications, Boca Raton, FL: CRC
Press, 1999.
106. Gunther, N. The Practical Performance Analyst. New York: Author Choice Press,
2000.
107. Hafner, K., and Lyon, M. Where Wizards Stay up Late, New York: Simon and
Schuster, 1996.
108. Hagiwara, T.; Doi, H.; Tode, H.; and Ikeda, H. «High-Speed Calculation Meth-
od for the Hurst Parameter Based on Real Traffic». Proceedings, 25th Annual
IEEE Conference on Local Computer Networks, November 2000.
109. Hamming, R. The Ait of Probability: For Scientists and Engineers. Reading, MA:
Addison-Wesley, 1991.
110. Hankerson, D.; Harris, G.; and Johnson, P. Introduction to Information Theory and
Data Compression. Boca Raton, FL: CRC Press, 1998.
111. Harbison, R. «Frame Relay: Technology for Our Time». LAN Technology, De-
cember 1992.
112. Harju,J.,and Kivimaki, P. «Cooperation and Comparison of DiffServ and IntServ:
Performance Measurements». Proceedings, 23rd Annual IEEE Conference on Lo-
cal Computer Networks, November 2000.
113. Held, G. Data and Image Compression: Tools and Techniques.New York: Wiley, 1996.
114. Hoe, J. «Improving the Start-up Behavior of a Congestion Control Scheme for
TCP». Proceedings, SIGCOMM ’96, August 1996.
115. Howard, P., and Vitter, J. «Arithmetic Coding for Data Compression». Proceed-
ings, of the IEEE, June 1994.
760
Список литературы
116. Hubberd, В. The World According to Wavelets. Wellesley, MA: A.K. Peters, 1998.
117. Huitema, C. IPv6: The New Internet Protocol. Upper Saddle River, NJ: Prentice
Hall, 1998.
118. Huitema, С. I Routing in the Internet. Upper Saddle River, NJ: Prentice Hall, 2000.
119. Hurst, H.; Black, R.; and Simaika, Y. Long-Tenn Storage: An Experimental Study.
London: Constable, 1965.
120. Iren, S.; Amer, P.; and Conrad, P. «The Transport Layer: Tutorial and Survey».
ACM Computing Surveys, December 1999.
121. Jacobson, V. «Congestion Avoidance and Control». Proceedings, SIGCOMM ’88,
Computer Communication Review, August 1988; reprinted in Computer Communi-
cation Review, January 1995; a slightly revised version is available at ftp.ee.lbl.gov/
pa pers/co n ga voi d. ps. Z.
122. Jacobson, V. «Berkeley TCP Evolution from 4.3 Tahoe to 4.3-Reno». Proceed-
ings of the Eighteenth Internet Engineering Task Force, September 1990.
123. Jacobson, V. «Modified TCP Congestion Avoidance Algorithm». End2end-int.er-
est mailing list, 20, April 1990. Available at ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt,
124. Jain, R. «Congestion Control in Computer Networks: Issues and Trends». IEEE
Network Magazine, May 1990.
125. Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Ex-
perimental Design, Measurement, Simulation, and Modeling. New York: Wiley, 1991.
126. Jain, R. «Myths About Congestion Management in High-Speed Networks». In-
ternetworking: Research and Experience, Volume 3,1993.
127. Jain, R„ et al. «Source Behavior for ATM ABR Traffic Management: An Expla-
nation. IEEE Communications Magazine, November 1996.
128. Jain, R., et al. ERICA Switch Algorithm: A Complete Description. ATM Forum
Contribution 96-1172, August 1996. (http://www.cis.ohio-state.edu/~jain)
129. Kadambi, J.; Crayford, L; and Kalkunte, M. Gigabit Ethernet. Upper Saddle Riv-
er, NJ: Prentice Hall, 1998.
130. Kalyanaraman, S., et al. «Performance and Buffering Requirements of Internet
Protocols over ATM ABR and UBR Services». IEEE Communications Magazine,
June 1998.
131. Kalyanaraman, S., et al. «The ERICA Switch Algorithm for ABR Traffic Man-
agement in ATM Networks». IEEE Transactions on Networking, February 2000.
132. Kamal, A. «Performance Modeling of Partial Packet Discarding Using the End-
of-Packet Indicator in AAL Type 5». IEEE Transactions on Networking, Decem-
ber 1996.
133. Karn, P., and Partridge, C. «Improving Round-Trip Estimates in Reliable Trans-
port Protocols». ACM Transactions on Computer Systems, November 1991.
134. Keshav, S., and Sharma, R. «Issues and Trends in Router Design». IEEE Commu-
nications Magazine, May 1998.
135. Kilkki, K. Differentiated Services for the Internet. Indianapolis, IN: Macmillan
Technical Publishing, 1999.
Список литературы 761
136. Kleinrock, L. Queueing Systems, Volume I; Theory. New York: Wiley, 1975.
137. Kleinrock, L. Queueing Systems, Volume II: Computer Applications. New York:
Wiley, 1976.
138. Kleinrock, L. «The Latency/Bandwidth Tradeoff in Gigabit Networks». IEEE
Communications Magazine, April 1992.
139. Kleinrock, L. «On the Modeling and Analysis of Computer Networks». Proceed-
ings of the IEEE, August 1993.
140. Koenen, R. «MPEG-4: Multimedia for Our Time». IEEE Spectrum, February 1999.
141. Konheim, А. «А Queueing Analysis of Two ARQ Protocols». IEEE Transactions
on Communications, July 1980.
142. Kumar, V.; Lakshman, T.; and Stiliadis, D. «Beyond Best Effort: Router Archi-
tectures for the Differentiated Services of Tomorrow’s Internet». IEEE Commu-
nications Magazine, May 1998.
143. Leland, W.; Taqqu, M.; Willinger, W.; and Wilson, D. «On the Self-Similar Na-
ture of Ethernet Traffic». Proceedings, SIGCOMM ’93, September 1993.
144. Leland, W.; Taqqu, M.; Willinger, W.; and Wilson, D. «On the Self-Similar Na-
ture of Ethernet Traffic (Extended Version)». IEEE/АСМ Transactions on Net-
working, February 1994.
145. Lin, S.; Costello, D.; and Miller, M. «Automatic-Repeat-Request Error-Control
Schemes». IEEE Communications Magazine, December 1984.
146. Lin, D., and Kung, H. «TCP Fast Recovery Strategies». Proceedings, IEEE IN-
FO COM, March 1998.
147. Livny, M.; Melamed, B.; and Tsiolis, A. «The Impact of Autocorrelation on Queue-
ing Systems». Management Science, March 1993.
148. Luinen, S.; Budrikis, Z.; and Cantoni, A. «The Controlled Cell Transfer Capabil-
ity». Computer Communications Re view, J anuary 1997.
149. Lurie, D., and Moore, R. Applying Statistics. U.S. Nuclear Regulatory Commis-
sion Report NUREG-1475. (Available from the Government Printing Office,
GPO Stock Number 052-020-00390-4.)
150. Mandelbrot, B. «Self Similar Error Clusters in Communications Systems and the
Concept of Conditional Stationarity». IEEE Transactions on Communications Tech-
nology, Volume 13,1965.
151. McDysan, D., and Spohn, D. ATM: Theory and Application. New York: McGraw-
Hill, 1999.
152. Miller, S. IPv6: The Next Generation Internet Protocol. Bedford, MA: Digital Press,
1998.
153. Moldeklev, K., and Gunningberg, P. «How a Large ATM MTU Causes Dead-
locks in TCP Data Transfers». IEEE/АСМ Transactions on Networking, August 1995.
154. Molloy, M. Fundamentals of Performance Modeling. New York: Macmillan, 1989.
155. Morris, C., and Rolph, J. Introduction to Data Analysis and Statistical Inference.
Rand Corp. Report P-5819, June 1978.
762
Список литературы
156. Morris, R. «TCP Behavior with Many Flows». Proceedings of the Fifth IEEE In-
ternational Conference on Network Protocols, October 1997.
157. Moy,J. «Multicast Routing Extensions for OSPF». Communications of the ACM,
August 1994.
158. Moy, J. OSPF: Anatomy of an Internet Routing Protocol. Reading, MA: Addison-
Wesley, 1998.
159. Mulcahy, C. «Plotting and Scheming with Wavelets». Mathematics Magazine,
December 1996. http://www.spelman.edu/~colm
160. Murhammer, M., et al. TCP/IP: Tutorial and Technical Overview. Upper Saddle
River, NJ: Prentice Hall, 1998.
161. Nack, F., and Lindsay, A. «Everything You Wanted to Know about MPEG-7,
Part 1». IEEE Multimedia, July — September 1999.
162. Nack, F., and Lindsay, A. «Everything You Wanted to Know about MPEG-7,
Part 2». IEEE Multimedia, October — December 1999.
163. Nagle, J. «On Packet Switches with Infinite Storage». IEEE Transactions on Com-
munications, April 1987.
164. Narvaez, P.; Siu, K.; and Tzeng, H. «New Dynamic Algorithms for Shortest Path
Tree Computation». IEEE/АСМ Transactions on Networking, December 2000.
165. National Bureau of Standards. Experimental Statistics. NBS Handbook 91, 1963.
(Available from the Government Printing Office, GPO Stock Number 003-003-
00135-0.)
166. Neivergelt, Y. Wavelets Made Easy. Boston: Birkhauser, 1999.
167. Netravali, A., and Haskell, B. Digital Pictures: Representation, Compression, and
Standards. New York: Plenum, 1995.
168. Norros, I. «А Storage Model with Self-Similar Input». Queueing Systems, Vol-
ume 16,1994.
169. Norros, I. «On the Use of Fractional Brownian Motion in the Theory of Con-
nectionless Networks». IEEE Journal on Selected Areas in Communications, Au-
gust 1995.
170. Ore, O., and Wilson, R. Graphs and Their Uses. Washington, DC: The Mathe-
matical Association of America, 1990.
171. Oshaki, H., et al. «Rate-Based Congestion Control for ATM Networks». Com-
puter Communication Review, April 1995.
172. Papoulis, A. Probability, Random Variables, and Stochastic Processes. New York:
McGraw-Hill, 1991.
173. Parekh, A., and Gallager, G. «А Generalized Processor Sharing Approach to Flow
Control in Integrated Services Networks: The Single-Node Case». IEEE/ACM
Transactions on Networking, June 1993.
174. Parekh, A., and Gallager, G. «А Generalized Processor Sharing Approach to Flow
Control in Integrated Services Networks: The Multiple Node Case». IEEE/ACM
Transactions on Networking, April 1994.
Список литературы 763
175. Park, К., and Willinger, W. Self-Similar Network Traffic and Performance Eval-
uation. New York: Wiley, 2000.
176. Paxson, V., and Floyd, S. «Wide Area Traffic: The Failure of Poisson Modeling».
IEEE/ACM Transactions on Networking, June 1995.
177. Paxson, V. «End-to-End Routing Behavior in the Internet». IEEE/ACM Trans-
actions on Networking, October 1997.
178. Pennebaker, W„ and Mitchell, J. JPEG Still Image Data Compression Standard.
New York: Van Nostrand Reinhold, 1993.
179. Perloff, M., and Reiss, K. «Improvements to TCP Performance in High-Speed
ATM Networks». Communications of the ACM, February 1995.
180. Perlman, R. Interconnections: Bridges, Routers, Switches, and Internetworking Pro-
tocols. Reading, MA: Addison-Wesley, 2000.
181. Phillips, J. How to Think About Statistics. New York: Freeman, 1992.
182. Pigeon, S. «Image Compression with Wavelets». Dr. Dobb’sJournal, August 1999.
183. Pratt, W., et al. «Combined Symbol Matching Facsimile Data Compression Sys-
tems». Proceedings of the IEEE, July 1980.
184. Ramalho, M. «Intra- and Inter-Domain Multicast Routing Protocols: A Survey
and Taxonomy». IEEE Communications Surveys and Tutorial, First Quarter 2000.
www.comsoc.org/pubs/surveys
185. Ramjee, R., et al. «Adaptive Playout Mechanisms for Packetized Audio Applica-
tions in Wide-Area Networks». Proceedings, IEEE INFOCOM, June 1994.
186. Rao, K„ and Hwang, J. Techniques and Standards for Image Video, and Audio
Coding. Upper Saddle River, NJ: Prentice Hall, 1997.
187. Redford, R. «Enabling Business IP Services with Multiprotocol Label Switch-
ing». Cisco WhitePaper, July 2000 (www.cisco.com).
188. Rekhter, Y. «Inter-Domain Routing Protocol (IDRP)». Internetworking: Re-
search and Experience, June 1993.
189. Romanow, A., and Floyd, S. «Dynamics of TCP Traffic Over ATM Networks».
IEEEJournal on Selected Areas in Communications, May 1995.
190. Ryu, B., and Lowen, S. «Point Process Approaches for Modeling and Analysis of
Self Similar Traffic, Part II — Applications». Proceedings, International Confer-
ence on Telecommunications Systems, Modeling, and Analysis, March 1997.
191. Sachs, M„ and Varma, A. «Fibre Channel and Related Standards». IEEE Com-
munications Magazine, August 1996.
192. Sahasrabuddhe, L., and Mukherjee, B. «Multicast Routing Algorithms and Pro-
tocols: A Tutorial». IEEE Network, January/February 2000.
193. Saito, J., et al. «Performance Issues in Public ABR Service». IEEE Communica-
tions Magazine, November 1996.
194. Salomon, D. Data Compression: The Complete Reference. New York: Springer-
Verlag, 1998.
195. Sato, K.; Ohta, S.; and Tokizawa, I. «Broad-band ATM Network Architecture
Based on Virtual Paths». IEEE Transactions on Communications, August 1990.
764
Список литературы
196. Sato, К.; Ueda, Н.; and Yoshikai, М. «The Role of Virtual Path Cross-connec-
tion». IEEELTS, August 1991.
197. Sayood, K. Introduction to Data Compression. San Francisco, CA: Morgan
Kaufmann, 2000.
198. Schroeder, M. Fractals, Chaos, Power Laws: Minutes from an Infinite Paradise.
New York: Freeman, 1991.
199. Schwartz, M. Computer- Communication Network Design and Analysis. Englewood
Cliffs, NJ: Prentice Hall, 1997.
200. Schwartz, M., and Stern, T. «Routing Techniques Used in Computer Communi-
cation Networks». IEEE Transactions on Communications, April 1980.
201. Schwartz, M. Broadband Integrated Networks. Upper Saddle River, NJ: Prentice
Hall PTR, 1996.
202. Sciuto, A. «TCP over ATM Performance in NASA NREN and СТ1». 1996. http:/
/www.tisLukans.edu/Workshops/ATM_Performance
203. Seifert, R. Gigabit Ethernet. Reading, MA: Addison-Wesley, 1998
204. Semeria, C., and Maufer, T. Introduction to Multicast Routing. ЗСот.Согр. http:/
/www.3com.com/nsc/501303.html, October 1996.
205. Shenker, S. «Fundamental Design Issues for the Future Internet». IEEEJournal
on Selected Areas in Communications, September 1995.
206. Siket, J., and Proch, D. «MPLS — Bring IP Networks and Connection-Oriented
Networks Together». Business Communications Review, April 2000.
207. Silver, D., and Williamson, J. «Data-Compression Chip Eases Document-
Processing Design». Computer Design, November 15,1987.
208. Slepian, D., ed. Key Papers in the Development of Information Theory. New York:
IEEE Press, 1974.
209. Spohn, D. Data Network Design. New York: McGraw-Hill, 1997.
210. Sportack, M. IP Routing Fundamentals. Indianapolis, IN: Cisco Press, 1999.
211. Spragins, J.; Hammond, J.; and Pawlikovski, K. Telecommunications Protocols and
Design. Reading, MA: Addison-Wesley, 1991.
212. Spurgeon, C. Ethernet: The Definitive Guide. Cambridge, MA: O’Reilly and As-
sociates, 2000.
213. Stallings, W. ISDN and Broadband ISDN, with Frame Relay and ATM. Upper
Saddle River, NJ: Prentice Hall, 1999.
214. Stallings, W. Local and Metropolitan Area Networks, Sixth Edition. Upper Saddle
River, NJ: Prentice Hall, 2000.
215. Stark, H., and Woods, J. Probability, Random Processes, and Estimation Theory
for Engineers. Upper Saddle River, NJ: Prentice Hall, 2000.
216. Stevens, W. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison-
Wesley, 1994.
217. Stevens, W. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP,
and the UNIX(R) Domain Protocol. Reading, MA: Addison-Wesley, 1996.
Список литературы 765
218. Stuck, В., and Arthurs, Е. A Computer Communications Network Performance
Analysis Primer Englewood Cliffs, NJ: Prentice Elall, 1985.
219. Suzuki, T. «ATM Adaptation Layer Protocol». IEEE Communications Magazine,
f April 1994.
220. Tanner, M. Practical Queueing Analysis. New York: McGraw-Hill, 1995.
221. Thomas, S. IPngand the TCP/IP Protocols: Implementing the Next Generation In-
ternet. New York: Wiley, 1996.
222. Tierney, B. «TCP Tuning Guide for Distributed Applications on Wide Area Net-
works». February 2001. http://www-didc.lbl.gov/tcp-wan.html
223. Tipper, C., and Daigle, J. «ATM Cell Delay and Loss for Best-Effort TCP in the
Presence of Isochronous Traffic». lEEEJoumal on Selected Areas in Communica-
tions, October 1995.
224. Tsybakov, B., and Georganas, N. «On Self-Similar Traffic in ATM Queues: Def-
initions, Overflow Probability Bound, and Cell Delay Distribution». IEEE/ACM
Transactions on Networking, June 1997.
225. Vaughan, H. «Research Model for Time Separation Integrated Communication».
i Bell System Technical^Journal, July 1959.
226. Viswanathan, A., et al. «Evolution of Multiprotocol Label Switching». IEEE Com-
munications Magazine, May 1998.
227. Walker, J. A Primer on Wavelets and Their Scientific Applications. Boca Raton:
Chapman & Hall/CRC, 1999.
228. Wallace, G. «The JPEG Still Picture Compression Standard». Communications
of the ACM, April 1991.
229. Walrand, J. Communication Networks: A First Course. New York: McGraw-Hill, 1998.
230. Wang, Z., and Crowcroft, J. «SEAL Detects Cell Misordering». IEEE Network,
July 1992.
231. Wang, Z. Internet QoS: Architectures and Mechanisms for Quality of Service. San
Francisco, CA: Morgan Kaufmann, 2001.
232. Weiss, J., and Schremp, D. «Putting Data on a Diet». IEEE Spectrum, August 1993.
233. Weiss, W. «QoS with Differentiated Services». Bell Labs Technical Journal, Oc-
tober — December 1998.
’ 234. Welch, T. «А Technique for High-Performance Data Compression». Computer,
June 1984.
235. Welstead, S. Fractal and Wavelet Image Compression Techniques. Bellinham, WA:
SPIE Optical Engineering Press, 1999.
236. White, P., and Crowcroft, J. «The Integrated Services in the Internet: State of
the Art». Proceedings of the IEEE, December 1997.
237. Willinger, W.; Wilson, D.; Wilson, D.; and Taqqu, M. «Self-Similar Traffic Mod-
eling for High-Speed Networks». Connexions, November 1994.
I 238. Willinger, W.; Taqqu, M.; Sherman, R.; and Wilson, D. «Self-Similarity Through
I High Variability: Statistical Analysis of Ethernet LAN Traffic at the Source
Level». IEEE/ACM Transactions on Networking, February 1997.
766
Список литературы
239. Wornell, G. Signal Proceeding with Fractals: A Wavelet-Based Approach. Upper
Saddle River, NJ: Prentice Hall, 1996.
240. Wright, G., and Stevens, W. TCP/IP Illustrated, Volume 2: The Implementation.
Reading, MA: Addison-Wesley, 1995.
241. Xiao, X., andNi, L. «Internet QoS: A Big Picture». lEEENetwork, March/April 1999.
242. Yang, C., and Reddy, А. «А Taxonomy for Congestion Control Algorithms in
Packet Switching Networks». IEEE Network, July/August 1995.
243. Yasuda, Y. «Overview of Digital Facsimile Coding Techniques in Japan». Pro-
ceedings of the IEEE, July 1980.
244. Zhang, L. «Why TCP Timer Don’t Work Well». Proceedings, SIGCOMM ’86
Symposium, August 1986.
245. Zhang, L.; Deering, S.; Estrin, D.; Shenker, S.; and Zappala. D. «RSVP: A New
Resource ReSerVation Protocol». IEEE Network, September 1993.
246. Zhang, H. «Service Disciplines for Guaranteed Performance Service in Packet-
Switching Networks». Proceedings of the IEEE, October 1995.
247. Ziv, J., and Lempel, А. «А Universal Algorithm for Sequential Data Compres-
sion». IEEE Transactions on Information Theory, May 1977.
Алфавитный указатель
1000BASE-CX, 172
1000BASE-LX, 172
1000BASE-SX, 172
1000BASE-T, 172
100BASE-FX, 169
100BASE-T4, 168, 169
100BASE-TX, 168
100BASE-X, 168,169
10BASE-T, 160,168
10BASE-T, 161
10BASE5, 161
4B/5B-NRZI, 169
А
AAL, 118,137
ABR, 45,133,135,388,397,409
Access Control, 182
Access Point, 183
ACR, 431
AirPort, 187
Allowed Cell Rate, 431
Al ternet, 28
American National Standards Institute, 306
ANSI, 306, 307
API, 708
AppleTalk, 137
Application Programming Interlace, 708
ARPA, 26,27,51
ARPANET, 25,27,51,481
ARQ, 322
Assured Forwarding, 562
Asynchronous Transfer Mode, 118
ATM, 24,30,44, 118,385,403
ABR, 45
GFR, 45
UBR, 45
адаптация, 45
веб-сайты, 149
глобальная сеть, 34
задачи, 150
локальная сеть, 34
параметры качества обслуживания, 412
слой
контроля, 120
пользователя, 120
управления, 120
ATM Adaptation Level, 45
ATM-форум, 33,45,118,132,397,402,408
Automatic Repetition Query, 322
Available Bit Rate, 45, 133, 135,388, 409
В
B-ISDN, 34
Backward Resource Management, 433
BBN. 26
BCS, 414
BECN, 312,434
Behavior Class Selector, 414
best-effort service, 135
BGP, 498,500
Binary Synchronous Communications protocol, 631
BISYNC, 631
Bit-Round Fair Queuing, 539,540
Bluetooth, 188
Border Gateway Protocol, 498, 500
BRFQ, 539, 540
BRM, 433
BSD UNIX, 708
BSS, 183
C
С-функния Эрланга, 238
CAD, 36,155
CAPC, 439
CBR, 133,405,408
CCITT, 31,44
CDVT, 412
CERFnet, 28
CERN, 29
CIR, 308
CIX, 28
Committed Information Rate, 308
Common Part Convergence Sublayer, 138
Computer-Aided Design, 36, 155
Constant Bit Rate, 133, 405, 408
Control Module, 181
Convergence Sublayer, 138
CPCS, 138
CRC, 321,342
CSMA/CD, 153,156,157,374
CSNET, 27
Cyclic Redundancy Check, 321,342
768
Алфавитный указатель
D
Data Circuit-terminating Equipment, 111
Data Link Connection Identifier, 114
Data Terminal Equipment, 111
DCE, 111
DCF, 185
DECNET. 137
Differentiated Services, 44, 553
Discard Eligibility, 308
Discrete Wavelet Transform, 688
Distributed Coordination Function, 185
Distribution System, 183
DLCI, 114
DLL, 710
DSSS, 187
DTE, 111
DVD, 38
DWT, 688
Dynamic Link Library, 710
E
Early Packet Discard, 395
EFCI, 433
EIA-232, 107,111
Electronics Industries Association, 107
EPD, 395
EPRCA, 439
ERICA. 439
ERP, 478
ESS, 184
Ethernet, 43, 155, 279
10 Гбит/с, 173
Fast, 153, 167
gigabit, 153
трафик, 279
Expedited Forwarding, 561
Explicit Forward Congestion Indication, 433
Extended Service Set, 184
Exterior Routing Protocol, 478
F
Fair Buffer Allocation, 393
Fast Ethernet, 153,155,167, 170
FBA, 393,395
FEC-класс, 590
FECN, 312
FHSS, 187
Fibre Channel, 153, 174
FIFO, 228,542
File Transfer Protocol, 59
First in First Out, 228
Forward Resource Management, 433
Forwarding Equivalence Class, 590
frame relay, 99
FRM, 433
FTP. 26, 59
G
GCRA, 426
Generalized Processor Sharing, 543
GFR, 45,133,136,409,442
Gigabit Ethernet, 153
GPS, 543
Guaranteed Frame Rate, 45.133, 136,409
H
HDCL, 107
HDLC, 306,319,341
Header Error Control, 130
НЕС, 130
HomeRF, 188
I
1.122, 99
1.150, 124,125
1.233, 111
1.361, 128
1.362, 137
1.363, 142
1.370, 309
1.371, 402,414,421
I ANA, 711
IBM 2780, 631
IBM 3780, 631
ICMP, 90,366
ICR, 431
IDN, 30,44
IDRP, 506
IEEE 802, 64,385
IEEE802.il, 183,185
IEEE802.11a, 188
IEEE 802.11b, 187
IEEE 802.15, 188
IEEE 802.3, 155,160,168,170
IETF, 54,83,528
IGMP, 513
Initial Cell Rate, 431
Integrated Digital Network, 30
Integrated Services Architecture, 43, 528
Integrated Services Digital Network, 30, 115
Intel, 715
Inter-Domain Routing Protocol, 506
Interior Routing Protocol, 477
Internet Activities Board, 51
Internet Assigned Numbers Authority, 711
Internet Control Message Protocol, 90, 301,366
Internet Engineering Task Force, 54, 83
Internet Group Management Protocol, 513
Internet Protocol, 74
Internet Protocol, next generation, 54
IP, 39,42,52,74
и ATM, 41
поверх ATM, 137
Алфавитный указатель
769
IP-сеть, 24
IPng, 54
IPv4, 74
IPv6, 44, 54,83, 94
IPX, 137
IRP, 477,479
ISA, 43
ISDN, 30,44,99, 115,118,279
ISO, 59,678
ISO 3009, 341
ISO 4335, 341
ITU, 33
ITU-T, 31, 107,111,118,124,137, 142,306,307,
309,402,641,651,678
J
JBIG, 641
Joint Bi-Level Image experts Group, 641
Joint Photography Experts Group, 678
JPEG, 278,643,678
JPEG 2000, 688
L
Label Distribution Protocol, 591
Label Switched Path, 590
Label Switching Router, 590
LAPB, 107,111,319
LAPD, 312
LAPF, 111,136,302,312,320
Last In First Out, 228
LDP, 591
LIFO, 228
Link Access Protocol-Balanced, 107
LINX, 28
LLC, 186,320,595
Logical Link Control, 186
London Internet Exchange, 28
LSP, 590
LSR-маршрутизатор, 590
LZ77. 650
LZ78, 650
LZW, 651
M
MAC, 165,182,185
Maximum Transmission Unit, 92
MBS, 411
MCR, 135,397,411,431
MDCR, 414
Medium Access Control, 165
MFS, 412
Minimum Cell Rate, 135,397,431
Minimum Desired Cell Rate, 414
Mosaic, 29
MOSPF, 515
Motion Pictures Experts Group, 690
MPEG, 643, 690
MPEG-1, 695
MPEG-2, 695
MPEG-21, 696
MPEG-4, 696
MPEG-7, 696
MPLS, 586
MPOA, 137
MTU, 92
Multicast OSPF, 515
MultiProtocol encapsulation Over ATM, 137
MultiProtocol Label Switching, 586
N
National Science Foundation, 27
NCSA, 29
non-real-time Variable Bit Rate, 133, 409
nrt-VBR, 133,409
NSF, 27
NSFNET, 27
NYSERnet, 28
О
OAM, 407
OFDM, 188
Open Shortest Path First, 80, 486
Open Systems Interconnection, 43, 50, 59
Orthogonal Frequency Division Multiplexing, 188
OSI, 43,59
OSPF, 80,479,486
P
Partial Packet Discard, 392
PCF, 186
PCR, 135,397,411,431
PDU, 58,316
Peak Cell Rate, 135, 397,431
Per-Нор Behavior, 558, 560, 592
PUB, 558,560,592
PIM, 520
Point Coordination Function, 186
Point-to-Point Protocol, 595
PPD, 392
PPP, 595
Protocol Data Unit, 53, 58, 316
Protocol Independent Multicast, 520
PSINet, 28
R
Random Early Detection, 547
READ, 639
Real-time Transport Protocol, 42,44, 601
real-time Variable Bit Rate, 133, 408
RED, 547
Resource reSerVation Protocol, 44,92,366, 553,
572,575,591
770
Алфавитный указатель
RFC 1122, 70,369
RFC 1349, 74,80
RFC 1633, 529
RFC 1812, 80,82
RFC 1889, 601,608
RFC 1932, 388
RFC 2205. 576
RFC 2236, 513
RFC 2460, 87,93
RFC 2474, 558
RFC 2475, 553
RFC 2597, 562
RFC 2598, 561
RFC 2988, 372
RFC 3042, 385
RFC 768, 73
RFC 791, 74
RFC 793, 70,72,359,360,369,371,372,379
Round-Trip Time, 379
Routing Information Protocol, 479
RSVP, 366,553, 572,575, 591
rt-VBR, 133,408
RTCP, 607
RTO, 379
RTP, 42,44,601
RTT, 379
s
SAP, 138
SAR, 138
SATNET, 27
SCR, 411
SCSI, 175
SDH, 45,356,407
SDU, 128
Segmentation And Reassembly Sublayer, 138
Service Access Point, 138
Service Level Agreement, 555
Shielded Twisted Pair, 168
SIGMETRICS, 282
Signaling System 7, 44
Signaling System Number 7, 277
SLA, 555
Small Computer Systems Interface, 175
SMTP, 58
Sockets API, 708
SONET, 45
Sparc, 715
SS7, 44,277
STP, 168
Synchronous Digital Hierarchy, 45, 356
Synchronous Optical Network, 45
TAT, 422
TCP, 39,53,70,320,352,398, 600
TCP и IP, 42
ТСР-сегмент, 57
ТСР-трафик. 39
TCP/IP, 24,50,708
веб-сайт, 66
задачи, 68
приложения, 58
TELNET, 26,59
Theoretical Arrival Time, 422
TM4.1, 414
TOS. 74,493,558
Transmission Control Protocol, 600
twisted pair, 160
Type Of Service, 74,493, 558
u
UBR, 45,134,388, 395,409
UDP, 39,53,73
UDP-трафик, 39
UNI, 45,128,403
Uniform Resource Locator, 29
UNIX, 369,651,708
Unshielded Twisted Pair, 168
Unspecified Bit Rate, 45, 388, 409
UPC, 420
URL, 29
Usage Parameter Control, 420
USENET, 49
User Datagram Protocol, 53,73
User Module, 181
User-to-Network Interface, 45,128, 403
UTP, 168
UUNET Technologies, 28
V
V.42bis, 651
VBR, 278
VCC, 120, 123
VCI, 123
Virtual Channel Connection. 120
Virtual Path Identifier, 126
VPC, 123
VPI, 123,126
w
WECA, 187
Weighted Fair Queuing, 544
WFQ, 543,544
Windows, 709
2000, 710
95, 710
NT, 710
WinSock API, 710
Wireless Ethernet Compatibility Alliance, 187
Алфавитный указатель
771
X
Х.21, 107
Х.25, 107,109,111,115,120,301,316,318,385
Z
zip, 650
А
автоковариация, 207, 270
автокорреляции функция, 206,269, 285
автоматизированное проектирование, 36, 155
автоматический запрос на повторение, 322
автономная система, 477
адаптация ATM, 45
адаптивная маршрутизация, 474
адрес
IPv4, 78
IPv6, 89
источника
IP, 75
IPv6, 87
приемника
IP, 75
IPv6, 87
адресации схема, 63
аксиома, 194
алгоритм
САРС, 442
EPRCA, 439
ERICA, 440
F-GCRA, 446
GCRA, 426,445
LZ77, 650
LZ78, 650
LZW, 651
OSPF, 80
RED, 547,548
Беллмана — Форда, 465
Беллмана — Форда, распределенный, 481
виртуального планирования, 422
выборочного отбрасывания пакетов, 395
Дейкстры, 462
дырявого ведра, 425
Карпа, 374
маркерного ведра, 428
маршрутизации, 305
пиковой скорости ячеек, 421
раннего отбрасывания пакетов, 393
с возвратом на N шагов, 340
сжатия данных, 622
случайного раннего обнаружения, 548
совпадения строк, 650
установившейся скорости ячеек, 425
Якобсона, 370
Американский национальный институт
стандартов, 306
анализ
очередей, 282
с переменным разрешением, 671
Фурье, 669
элементарных волн, 670
ансамбль, 214
апостериорная вероятность, 198
арифметическое кодирование, 643,689
инкрементное, 649
чистое, 646
архитектура
дифференцированных служб, 553
интегрированных служб, 43,528
протоколов, 50, 59
ATM, 119
Fibre Channel, 177
IEEE802.il, 185
TCP/IP, 51,52
TCP/IP поверх ATM, 386
ретрансляции кадров, 111
асинхронный ввод-вывод, 731
асинхро! шый режим передачи, 118
ассоциация
Fibre Channel, 179
электронной промышленности, 107
атрибут обратной связи, 414
Б
базовый набор служб, 183
Байеса теорема, 197
балансирование нагрузки, 497
безопасность, 83
Беллмана — Форда алгоритм, 465
Бернерс-Ли, Тим, 29
беспроводная локальная сеть, 153, 180, 182
бит, единица информации, 618
блокирующий запрос, 730
борьба с перегрузкой, 82, 294,300,303,437
ATM, 403 '
TCP, 365
объединенные сети, 546
сети ретрансляции кадров, 306
браузер
Mosaic, 29
с графическим интерфейсом, 29
с интерфейсом командной строки, 29
броуновское движение, 209
буфер
входной, 295
выходной, 295
быстрая повторная передача, 379
быстрая сеть Ethernet, 153,155, 167,170
быстрое восстановление, 382
ТТ2.
Алфавитный указатель
В
ведро, 535
дырявое, 425
маркерное, 428, 535
вектор движения, 692
Венна диаграмма, 194
вероятность, 193
апостериорная, 198
условная, 197
версия
IP, 74
IPv6, 86
вершина графа, 452
взаимно исключающие события, 194
взвешенная справедливая организация
очередей, 543, 544
взвешенный граф, 454
взвешенный ориентированный граф, 454
видсосжатие, 690
Винера процесс, 209
виртуальные частные сети, 588
виртуальный канал, 104, 107,108,120,122,
146,318
виртуальный путь, 120, 123
витая пара, 160
категория 3, 168, 180
категория 5, 168, 172, 180
неэкраиированная, 161, 168, 172,180
экранированная, 168, 178
влияние самоподобия на производительность, 279
внешняя сигнализация, 45
внутренняя сигнализация, 44
возврат на Л' шагов, 328, 340
волновое преобразование
дискретное, JPEG 2000, 688
одномерное, 676
волновое сжатие, 668
волоконно-оптический канал, 153
восстановление после перегрузки, 307
временная метка, 305
временной штамп
IPv4, 83
TCP, 73
время
жизни, 75,594
обслуживания, 232
отклика, 238
распространения сигнала
в оба конца, RTT, 379
установки соединения, 116
Всемирная Паутина, 29
второй момент, 200
входной буфер, 295
входной пограничный
LSR-маршрутизатор, 591,597
выбор маршрута, 79. 305,474
выборка, 194
выборочная дисперсия, 251
выборочная рассылка, 90
выборочного отбрасывания правило, 394
выборочное распределение, 250
выборочное среднее
выборочное, 270
выборочное среднее значение, 250
выборочное среднеквадратичное отклонение, 284
высокоскоростная локальная магистраль, 36, 155
высокоскоростная локальная сеть. 35, 155
выходной пограничный LSR-маршрутизатор,
591,597
Г
гарантии качества обслуживания, 445
гарантированная скорость кадров, 133. 409
гарантированное продвижение данных, 562
гармоника. 669
гашение источника, 301,366
гибкое состояние, 574, 577
гигабитная сеть Ethernet, 153, 155, 171
глобальная сеть, 34
глобальная синхронизация, 547
головной хаб, 161
граф, 452
группа
изучения высокоскоростных сетей, 170
инженерной поддержки Интернета, 54, 83
групповая маршрутизация, 44
групповая рассылка. 90, 507
групповое кодирование, 631
групповой адрес, 507
группы новостей USENET, 49
д
двоичные схемы обратной связи, 438
двоичный экспоненциальный откат, 159,374
двунаправленная интерполяция, MPEG, 693
двухпозиционный источник, 565
Дейкстры алгоритм. 462
дейтаграмма
IP, 58
определение, 104
отбрасывание, 80
фрагментация, 76
дерево, 456
детерминированные источники данных, 279
Джамбо, параметр IPv6, 92
Джексона теорема, 247
диаграмма Венна, 194
диапазон разброса задержек передачи ячеек,
412,413
динамическая маршрутизация, 42
динамически подключаемая библиотека, 710
Алфавитный указатель
773
динамическое изменение размера окна, 376
дискретная случайная переменная, 199
дискретное волновое преобразование, 688
дискретное косинусное преобразование, 660,690
дискретный во времени стохастический
процесс, 205
дискретный по значениям стохастический
процесс, 205
дисперсия, 200,269,285
выборочная, 286
выборочного среднего, 251
среднего по времени, 268
стохастического процесса, 206
дистанционно-векторная маршрутизация,
479,499
дисциплина
диспетчеризации, 228
очередей, 80,532, 537
FIFO, 542
FQ, 542
дифференцированные службы, 44. 527, 553
ориентированные на соединение, 587
протоколы, 571
длина
адресного поля. 55
заголовка расширения, 90
Интерн ет-заголовка, 74
очереди, 82
поля данных, 90
добровольный стандарт, 699
договор о трафике, 419,442
долгосрочная зависимость, 270
домен, 527
допуск на разброс задержек передачи ячеек, 442
допустимая скорость ячеек, 431
доставка с максимальными усилиями, 38
достоверное событие, 194
доступная битовая скорость, 45,133,135,388,409
доступность
ресурсов, 584
сети. 501
соседей, 501
дочерняя вершина, 456
дуплексная связь, 169
дырявое ведро, 425
Е
Европейский центр ядерных исследований, 29
Европейское Сетевое сообщество, 27
единица информации, бит, 618
3
заголовок
IPv6, 84, 86
аутентификации. IPv6, 85
инкапсуляции защищенных данных, IPv6, 85
заголовок {продолжение)
маршрутизации, IPv6, 85, 93
параметров
получателя, 85,94
ретрансляционных участков, 85
фрагмента, IPv6, 85
задержка, 40,405, 530
обработки, 297
распространения, 297
запрет увеличения скорости, 434
запрос характеристик, 58
затяжной пуск, 375.377
зацикливание, 476
ЗивЯков, 650
зигзагообразное сканирование, JPEG, 681
И
идеальная производительность, 297
идентификатор
IP, 75
виртуального канала, 123
виртуального пути. 123.126
источника синхронизации, 606
содействующего источника, 606
соединения, LAPF, 114
иерархический режим, JPEG, 687
избыточность, 628
избыточный размер всплеска, 309
изменение
задержки, 40
маршрута, 299
состояния сети, 358
структуры, 230
топологии, 483
изменчивости коэффициент, 235
инерционность, 268
инкрементное арифметическое кодирование, 649
инкрементный процесс Пуассона, 212
интегрированная многоуровневая обработка, 602
интегрированная цифровая сеть, 30
интегрированные службы, 527
интенсивности функция, 285
Интернет, 25
история, 25
качество обслуживания, 38
Интернет-протокол. 24,39.42,52, 74
IPv6, 54,83
задачи, 94
новая версия, 44
нового поколения, 54
функцтонировапие, 56
интерфейс, 63
SCSI, 175
UNI, 45
пользователь — сеть, 45,128, 403
интерфейс сокетов, 708
интранет, 62
774
Алфавитный указатель
информация, 616, 617
инцидентное ребро графа, 453
история сетей, 25
источник
двухпозиционный. 565
дейтаграмм, 517
монотонных данных, 564
пакетов, 495, 565
синхронизации, 606
К
кадр, HDLC, 342
Каи, Боб, 27
канал
виртуальный, 104
волоконно-оптический, 98
метасигнальный, 125
Кантора множество, 261
Карпа алгоритм, 374
категория 3, 168, 180
категория 5, 168, 172, 180
качество обслуживания, 35,304, 445
ATM, 412,429
IP-сети, 525
Интернет, 38
квантование, JPEG, 680
Кендалла нотация, 233
класс
обслуживания, 536
пакета, 534
потока, 569
трафика IPv6, 86, 87
эквивалентности продвижения данных, 590
клиент, 712
коаксиальный видеокабель, 178
ковариация, 203
код
READ
дважды модифицированный, 641
модифицированный, 639
Хаффмана, 622, 625,635,690
Хаффмана модифицированный, 636
кодирование, 622
арифметическое, 643
длин серий, 632
эффективность, 625
кодовое слово, 624
коммутатор. 294
2-го уровня, 162
3-го уровня, 165
с промежуточным хранением, 164
сквозной, 165
коммутация
каналов, 100
логических соединений, 110
пакетов, 26,43,99,301
пометкам, 586
ячеек, 126
коммутируемая сеть, 99
Ethernet, 36
локальная, 164
компенсация движения, MPEG, 691
компонентное преобразование, JPEG 2000, 688
компьютерная сеть, 61, 294
конструирование трафика, 588
контроль
допуска, 532
несущей, 157
ошибок, 53,316,320,366
параметров использования, 420, 444
с помощью циклического избыточного
кода, 321
контрольная последовательность кадра, 320
контрольная сумма
IP, 74
TCP, 57,71,72
UDP, 74
заголовка
ATM, 128, 130
IP, 75
кадра, 321
концентратор, 161
коррелированные переменные
негативно, 204
позитивно, 204
корреляции коэффициент, 204, 207
косинусная функция, 663
коэффициент
изменчивости, 235
использования сети, 279, 298
корреляции, 204, 207
потерянных ячеек, 412
сжатия, 632
справедливости, 396
краткосрочная зависимость, 270
кредит, 353,376
Л
лавинная маршрутизация, 488
Лемпель Авраам, 650
линия
виртуального канала, 123
виртуального пути, 123
лист, 456
Литтла формула, 231
логическое соединение, 120, 318
локальная сеть
ATM, 34
Ethernet, 43
IEEE 802, 64
беспроводная, 153, 180, 182
высокоскоростная, 35, 155
общая шина, 156
локальный адрес получателя пакета. 58 ,
Алфавитный указатель
775
М
магистраль
NSFNET, 27
OSPF, 494
макроблок, MPEG, 692
максимальная задержка передачи ячеек, 412
максимальный размер
буфера, 145
всплеска, 411,442
кадра, 159, 412,442
пакета, 27, 63
сегмента, 72
скользящего окна, 325
маркерная шипа, 279
маркерное ведро, 428
маркерное кольцо, 278
маркировка, GFR, 443
маршрутизатор, 62, 63, 184,294, 472,489
группы назначения, 521
коммутирующий по меткам, 590
точки встречи, 521
маршрутизация
адаптивная, 474
в объединенных сетях, 471
внешняя, 478, 498
внутренняя, 471
динамическая, 42
дистанционно-векторная, 479, 499
лавинная, 488
маршрутпо-векторная. 499
па уровне ретрансляционных участков, 598
от источника, 83
протоколы, 471,498
с учетом состояния линий. 487
фиксированная, 472
маршрутизирующий протокол групповой
рассылки, 44
маршрутно-векторная маршрутизация, 499
масштабированный диапазон, 288
масштабирующая функция Хаара, 675
масштабный множитель окна, TCP, 72
материнская элементарная волпа, 670
матрица смежности, 453
международная организация по стандартизации,
59,678
международный союз телекоммуникаций, 31,
107,118, 124,137,142,306,678
межкадровый режим, MPEG, 691
межсетевой уровень, 52
метасигнальный канал, 125
метка потока, IPv6, 86, 87
метод
EPD, 395
FBA, 395
FIFO, 228
подавления пулей, 631
метод {продолжение)
сжатия zip, 650
справедливого выделения буфера, 393
минимальная скорость ячеек, 135,397,411 414
431,435,442
минимальность, 663
многопротокольная коммутация по меткам, 586
многосерверпая очередь, 229, 237
многоуровневая архитектура протоколов, 50
многочастотная модуляция, 188
множественная целевая рассылка, 509
множественные случайные переменные, 203
множество Кантора, 261
модель
OSI, 43,59
TCP/IP, 42
очереди, 226
самоподобного трафика, 391
сетевого трафика, 273
централизованной обработки данных, 37
модель клиент-сервер, 712
модифицированный код
READ, 635,639
Хаффмана, 636
модуль данных
подуровня CPCS, 144
протокольный, 53
CPCS, 145
SAR, 145
TCP, 58
служебный, 145
мост, 62,63,184
мощная рабочая группа, 36,155
мультиплексирование
логических соединений, 110
самоподобных потоков, 280
н
набор протоколов TCP/IP, 24,50, 51,498
веб-сайт, 66
задачи, 68
нагрузка, 297
надежность, 63
направленный граф, 454
Национальный научный фонд США, 27
начальная скорость ячеек, 431
негативно коррелированные переменные, 204
независимые случайные переменные, 203
независимые события, 197
неисправность, 106
некоррелированные переменные, 204
непостоянство задержки доставки ячеек, 405
непрерывная случайная переменная, 199
непрерывный во времени стохастический
процесс, 205
непрерывный по значениям стохастический
процесс, 205
776
Алфавитный указатель
неуказанная битовая скорость, 133, 134, 388,409
иеэкранированная витая пара, 161, 168, 172, 180
неэластичный трафик, 39, 530
неявная сигнализация о перегрузке, 302, 307
помер
виртуального канала, 111
подтверждения. 71
порта, 57
порядковый. 71
сегмента, 57
нормализованный суммарный трафик, 297
нормальное распределение, 202
нотация Кендалла, 233
Ноя эффект, 276
О
обеспечение гарантий скорости, 442
область
интереса, 688
понятие, 494
обратная матрица, 675
обратное явное уведомление о перегрузке, 311
обратный порядок байтов, 715
обслуживание
очередей. 82
по остаточному принципу, 445
с контролируемой нагрузкой, 536
с максимальными усилиями, 135
общая шина, 156, 164
объединение
сетей, 61
подсеть, 56
пример конфигурации, 64
терминология, 61
событий. 194
объединенная сеть, 42, 62, 294
IP, 42
маршрутизация, 471
ограниченная передача, 384
одноранговые уровни, 51
односерверная очередь, 233
ожидание подтверждения, 331
окно, 353
TCP, 71
кадров, 325
скользящее, 650
оконечная система, 62, 297
оконечное оборудование линии передачи
данных, 111
операционная система
UNIX, 708
Windows. 709
операционная система UNIX, 369, 651
описание источника. 612
описатель
потока, 578
описатель (продолжение)
трафика, 409
источника, 410
соединения, 410
оптоволоконный кабель, 178
организация очередей
справедливая. 538
справедливая взвешенная, 543, 544
справедливая с побитовым циклом, 539. 540
ориентированный граф, 454
ортогональное разделение частоты, 188
основное распределение, 250
остановка с ожиданием, 321
остаточный принцип, 38
откат, 373,374
отложенный неуспешный вызов, 249
отрицательное подтверждение, 328
оценка изменчивости RTT, 370
оценочная формула Уиттла, 285, 286
очередь, 226,227, 294
дисциплина, 80
многосерверная, 229, 237
обслуживание, 82
односерверная, 233
с приоритетами. 243
сеть, 245
очищенный неуспешный вызов, 249
ошибка
выборки, 253
систематическая, 253
п
пакет
IP, 494
Source Quench, 301
Х.25, 109
гашения источника, 301
обновления, 489
сдерживающий, 301
управляющий, 305
фиксированного размера, 119
пакетный уровень, Х.25, 107
параллельные ребра графа, 453
параметр
TCP, 72
Джамбо, 92
качества обслуживания, 412
самоподобия, 265
Херста, 265, 279, 286
Парето распределение, 273, 277
Паутина, 29
первоочередное открытие кратчайших
маршрутов, 486
первый момент, 199
первым прибыл, первым обслужен, 228
перегрузка, 82,107,294,307,365
Алфавитный указатель
777
передатчик
межобластной групповой рассылки, 517
межсистемпой групповой рассылки, 518
переключающий элемент, 639
переменная битовая скорость, 278
переменная разрешающая способность, 688
переменная, случайная, 198
пересечение событий, 194
переходные зависимости, 627
периодограмма, 285
пиковая скорость ячеек. 135, 397, 411, 431.442
пиксел, 660
планирование пакетов, 534
плоское адресное пространство, 165
плотности функция, 199
поведение па ретрансляционном участке, 558,
560.592
повреждение
кадра, 321
подтверждения. 321
повторная передача, 300
пограничный LSR-маршрутизатор
входной, 591
выходной, 591
подавление пулей, 631
подграф, 456
подполе старшинства, 81
подсеть, 56,62, 166
подтверждение
обычное, 321
отрицательное, 328
подуровень
CPCS, 138
конвергенции, AAL, 138
сегментации и восстановления, 138
позитивно коррелированные переменные, 204
поиск кратчайшего пути, 461
поле
класса трафика. 87, 554,557
параметров, IPv4, 83
типа службы, 79,557, 558
флагов, 71
полезная длина, IPv6, 86
политика
обрубания хвостов, 553
отбрасывания пакетов, 532
поддержания трафика, 305
приемлемого использования, 28
формирования трафика, 428
полная длина, IP, 75
полной вероятности формула, 197
полномочный получатель групповой
рассылки, 517
полудуплексная связь. 169
попытка. 196
порт
источника, 71
приемника, 57, 71
портал, 184
порядковый помер
AAL1, 141
TCP, 71
порядок
графа, 453
обслуживания очередей, 80
следования пакетов, 104
последним прибыл, первым обслужен, 228
последовательность очередей, 246
постоянная битовая скорость, CBR, 133,405,408
потеря пакетов, 40, 300, 531
поток, 577
байтов, 71
модулей данных. 53
пуассоновский, 263
потребности в корпоративных глобальных
сетях, 37
правило раздвоенного горизонта, 484
преамбула, 159
предел количества ретрансляционных
участков, 87
предотвращение перегрузки, 302, 307
предсказание, JPEG, 686
преобразование
волновое, 676
дискретное волновое, JPEG 2000, 688
дискретное косинусное, 660, 690
компонентное, JPEG 2000, 688
Фурье, 669
прикладной программный интерфейс
сокетов, 708
прикладной уровень, 53, 59
приложение
TCP/IP, 58
FTP, 59
SMTP, 58
TELNET, 59
групповой рассылки, 39
мультимедиа, 39
передачи файлов, 88
реального времени, 39, 74, 218.566
приобретение соседей, BGP, 500
приоритет, 243
проблема счета до бесконечности, 483
продвижение потока данных, TCP, 71
производительность
TCP поверх ABR, 397,398
TCP поверх ATM, 388
влияние самоподобия, 279
двухточечной линии, 330
сети, 352
системы, 218
произвольный доступ, 688
промежуточная система, 62
промежуточный хаб, 161
пропускная способность, 40, 218, 297, 530
778
Алфавитный указатель
простой граф, 453
пространство выборок, 194
противодавление, 300
протокол, 51
AppleTalk, 137
BGP, 498, 500
BISYNC, 631
CSMA/CD, 374
DECNET, 137
FTP, 26,59
HDCL, 107
HDLC, 306,319,341
ICMP. 90,301,366
IDRP, 506
IGMP, 513,521
IP, 24,39,42,52,56,74
IPng, 54,83
IPv4, 511
IPv6, 44,54.83,506,511,515
IPX, 137
IRP, 479
LAPB, 107,111,318,319
LAPD, 312
LAPF, 111, 136,302,312,320
LDP, 591
LLC, 320
MAC. 165,168
MOSPF, 515
OSPF, 486,489,493,494
PIM, 520
PPP, 595
RSVP, 44,92,366, 553,572,575,591
RTCP, 607
RTP, 42,44,601
SMTP, 58
SS7, 277
TCP. 39,53.56,70.320, 352,366,388,
398,600
TELNET, 59
UDP, 39,42,53,73
внешней маршрутизации, 478
внутренней маршрутизации, 477
внутридоменной маршрутизации, 506
двухточечного соединения, 595
задачи, 68
маршрутизации, 471,498
маршрутной информации, 479
пограничного шлюза, 498, 500
распределения меток, 591
реального времени, 601
резервирования ресурсов, 572, 575.591
ретрансляции кадров, 306
состояния канала, 486
протокольный модуль данных, 316
процентиль, 239
процесс
броуновского движения, 209, 265, 281
Винера. 209
процесс (продолжение)
дробного броуновского движения, 266
Пуассона, 202,212
рекурсивный, 262
с долгой памятью, 207
с короткой памятью, 207
случайный, 205
стохастический, 205
эргодический, 214, 268
прямое явное уведомление о перегрузке, 311
Пуассона
поток, 263
процесс, 202,212,280
распределение, 201,246
путь, 453
путь, коммутируемый по меткам, 590
Р
разброс задержек передачи ячеек, 412
раздвоенный горизонт, 484
размер
графа, 453
очереди, 228
разреженный режим, PIM, 520
раннее отбрасывание пакетов, 392,393
распределение, 689
меток, 599
нормальное, 202
Парето, 273, 277
Пуассона, 201, 246
с тяжелым хвостом, 271
функция. 199
экспоненциальное, 200
распределительная система. 183
расстояние между вершинами, 454
рассылка
выборочная, 90
групповая, 90
целевая, 90
расширенный набор служб, 184
реального времени
приложения, 74,218,566
трафик, 563
ребро графа, 452
регистрация маршрута, 83
регулирование трафика, 428
режим
двоичный, 397
ограниченного окна. 397
ограниченной скорости, 397
явного указания скорости, 397
резервирование сетевых ресурсов, 305
рекурсивный процесс, 262
ретрансляция кадров, 31,32,99,109,110,111,118
борьба с перегрузкой, 306
веб-сайт, 116
задачи, 116
Алфавитный указатель
779
родительская вершина, 456
ряд Фурье, 669
С
самоподобие, 259
Ethernet-трафика, 273
влияние на производительность, 279
параметр, 265
самоподобный процесс
с дискретным временем, 268
с непрерывным временем, 265
стохастический, 264
самоподобный трафик, 259
самосинхронизация, 367
связующее дерево, 457
сдерживающий пакет, 301
сеанс, 578
сеансовый уровень, 59
сегментация, 63
селектор класса поведения, 414
семантика, 51
семейство протоколов OSI, 506
сервер, 712
серверная ферма, 36
Серф, Винт, 27
сетевой уровень, 52, 59
сетевые адреса, 78
сеть
Altemet, 28
ARPANET, 25,51
ATM, 24,118,385,403
CERFnet, 28
CSNET, 27
Ethernet, 43,155, 279
Fibre Channel, 153
ISDN, 115
NYSERnet, 28
PSINet, 28
SONET, 45
Интернет, 25
очередей, 245,294
ретрансляции кадров, 306
с коммутацией каналов, 100
с коммутацией пакетов, 99, 104,301, 305
с ретрансляцией кадров, 109
сжатие данных, 622
JPEG, 678
JPEG 2000. 688
MPEG, 690
без потерь, 630
видео, 690
волновое, 668
звук, 690
коэффициент, 632
с потерями, 660
сигнал управления соединением, 110
сигнализация о перегрузке
методы
двоичные, 303
кредита, 303
регулирования скорости, 303
неявная, 302, 307
явная, 302,307,311
сигнальная система 7, 277
симплекс, 576
синтаксис. 51
синхронизация, 51
синхронная цифровая иерархия, 45
система
автоматизированного проектирования, 36
очередей, 295
систематическая ошибка, 253
сквозная задержка, 297
сквозной коммутатор, 165
скользящее окно, 306
TCP, 355
управление потоком, 324
скорость поступления
данных, 530
запросов, 232
пакетов, 295
подтверждений, 367
следующий заголовок, IPv6, 86, 90
слой
контроля ATM, 120
пользователя ATM, 120
управления ATM. 120
служба
ABR, 135
ATM, 136
CBR, 133
GFR, 442
ISA, 534
rt-VBR, 133
UBR, 134
беспроводная локальная сеть, 185
гарантированного продвижения данных, 562
коммерческого информационного обмена, 28
не реального времени, 134
подсети, 80
служебный модуль данных, 128
случайная переменная, 198, 625
дискретная, 199
непрерывная, 199
случайное раннее обнаружение, 546
случайный процесс, 205
смежности матрица, 453
смежные вершины графа, 453
смеситель, 604
смещение
данных, 71
уровня, 663
фрагмента, 75
780
Алфавитный указатель
событие
достоверное, 194
объединение, 194
пересечение, 194
совет по функционированию Интернета, 51
совокупность запросов, 228
совокупный пиковый запрос, 418
согласованная скорость передачи
информации, 308
согласованный размер всплеска, 309
соединение
виртуального канала, 120,123
виртуального пути, 120,123
сокет, 708,711
сообщение
отправителя. 610
получателя, 612
спектр мощности, 208
спектральная плотность, 208, 285
спектратьная селекция, 684
спецификация
1.371, 414
потока, 578
управления трафиком, 403, 414,421
физического уровня, 45
фильтра, 578
справедливая организация очередей, 538
взвешенная, 543, 544
с побитовым циклом, 539,540
справедливое распределение
буфера. 393,395,396
ресурсов коммутатора, 437
сетевых ресурсов, 306
справедливость, 304
среднее
значение стохастического процесса. 206
по ансамблю, 213
повремени, 214
среднеквадратичное отклонение, 200
срочное продвижение данных, 561
срочный указатель, TCP, 71
стандарт
MPEG, 695
SDH, 45
Х.25, 115
стандарты, 698
статистически независимые случайные
переменные, 203
статистическое мультиплексирование, 418
стационарность в широком смысле, 207
стационарный стохастический процесс, 207
стек
меток, 593
протоколов, 386
стили резервирования, 581
стоимость линий, 493
стохастический процесс, 205
дискретный во времени, 205
дискретный по значениям, 205
дисперсия, 206
непрерывный во времени, 205
непрерывный по значениям, 205
с долгой памятью, 207
с короткой памятью, 207
самоподобный, 264
среднее значение, 206
стационарный, 207
эргодический. 214
стратегия отбрасывания, 306
схема
адресации, 63,515
аутентификации, 185
динамической маршрутизации, 573
кодирования данных, 169, 658
обратной связи с явным указанием
скорости, 439
распределения кредитов, 353
сжатия данных, 632
справедливой организации очередей, 540
счетчик следования, 649
считающий процесс Пуассона, 212
т
тайм-аут повторной передачи, 361
таймер повторной передачи, RTO, 359, 379
текущая скорость ячеек, 435
теорема
Байеса, 197
Джексона, 247
теоретическое время прибытия, 422
теория
вероятности, 193
х-рафов, 452
информации, 616
терминальное оборудование, 111
технология коммутации пакетов, 26
тип 1.AAL, 141
тип 2, AAL, 142
тип 3/4, AAL, 142
тип 5, AAL, 146
Томлинсон, Рэй, 26
топология
Fibre Channel, 178
звезда, 161
изменение, 483
каркаса, 178
общая шипа. 156,164
точка
встречи, 521
доступа
в Интернет, 28
к службе, 138,183
соединения, 421
Алфавитныйуказатель
781
транспортный уровень, 53, 59, 70, 74
трафик
Ethernet, 279
FTP, 277
TCP, 277
TELNET, 277
Всемирной Паутины, 276
договор, 442
конструирование, 588
неэластичный. 39, 530
реального времени, 44, 563
регулирование, 428
управление, 416,442
формирование, 428
эластичный, 39,529
требования
к 1Р-сетям, 525
неэластичного трафика, 530
политики, 28
трафика реального времени, 564
тревога маршрутизатора, 92
тяжелый хвост, 273
У
удерживаемый неуспешный вызов, 249
узкополосная сеть ISDN, 99
Уиттла оценочная формула, 285
унифицированный указатель информационного
ресурса, 29
управление
буфером, 443
в замкнутом цикле, 430
в разомкнутом цикле, 429
допуском к соединению, 418
доступом к носителю, 165, 183
кредитом, 434
окном, 375
потоком, 296,316,317,320
TCP, 366
скользящее окно, 324
ячеек ATM, 128
сетевыми ресурсами, 416
скоростью, 434
трафиком, 303
ABR, 429
ATM, 416
GFR, 442
управляемая передача ячеек, 128
управляющий пакет. 305
упреждающее отбрасывание пакетов, 546
уровень
AAL, 45,118,137,138
LLC, 186,595
МАС, 185
адаптации ATM, 118, 136
доступа к сети, 52
передачи данных, 59,317
уровень (продолжение)
представления, 59
прикладной, 59
связи между хостами, 53
сеансовый, 59
сетевой, 59
стека протоколов, 51
транспортный, 59
физический, 59
условная вероятность, 197
усовершенствованные сети IP и ATM, 41
установившаяся скорость ячеек, 411
Ф
факсимильное сжатие, 635
фараон, 287
физический уровень, 52,59, 107
фиксированная маршрутизация, 472
фильтрация, 580
флаг
DF, 94
IP, 75
More, 95
PUSH, 71
SYN, 71
URGENT, 71
флаттер. 475
флуктуация, 103,531,611
формат
ATM, 126
IPv4, 78
IPv6, 84
OSPF, 494
RIP. 485
формирование трафика, 428
формула Липла, 231
форум ретрансляции кадров, 116
фрагментация, 76,92
фрактал, 276
функция
автокорреляции. 206, 269, 285
интенсивности, 285
плотности, 199
распределения, 199
распределенной координации, 185
точечной координации. 186
Фурье
преобразование, 669
ряд, 669
X
Хаара элементарная волна, 670
хаб, 161, 170
Хаффмана код, 622, 625,690
Херста параметр, 265, 279, 286
хорошо известный порт, 711
782
Алфавитный указатель
ц
целевая рассылка, 90
централизованная серверная ферма, 36, 155
цикл, 454
цифровая фотокамера, 37
цифровая электроника, 37
цифровой видеодиск, 37
ч
частичное отбрасывание пакетов, 392
чистое арифметическое кодирование, 646
ш
Шеннон, Клод, 616
широковещательный шторм, 165
шлюз, 577
Шрёдер Манфред, 260
э
экранированная витая пара, 168, 178
экспоненциальное распределение, 200
эластичный трафик, 39, 529
электронная почта, 30
элементарная волна Хаара, 670
эмуляция локальной сети, ATM, 137
энтропия, 616,619
эргодический процесс, 214,268
Эрланга С-фупкция, 238
эталонная модель OSI, 50. 59
эффект
Иосифа, 287
Ноя, 276
эффективная мощность сервера, 279
эффективная пропускная способность, 300
эффективность кодирования, 625
Я
явная маршрутизация, 598
явная сигнализация о перегрузке, 302,307, 311
явно указанная скорость ячеек, 435
явное предотвращение перегрузки, 311
явное уведомление о перегрузке
обратное, 311
прямое, 311,429, 433
Якобсона алгоритм, 370
якорный кадр, 692
ячейка ATM, 33,119,407
САМ, 407
бит
запрета увеличения скорости, 431
индикации перегрузки, 431
поле явной установки скорости ячеек, 431
управления ресурсами, 432
Вильям Столлингс
Современные компьютерные сети
2-е издание
Перевел с английского А. Леонтьев
Главный редактор
Заведующий редакцией
Руководитель проекта
Научный редактор
Литературный редактор
Художник
Иллюстрации
Корректоры
Верстка
Е. Строганова
И. Корнеев
Ю. Суркис
А. Жданов
А. Жданов
Н. Биржаков
М. Жданова, В. Шендерова.
М. Шендерова
С. Беляева, Н. Рощина
Р. Гришанов
Лицензия ИД № 05784 от 07.09.01.
Подписано в печать 28.04.03. Формат 70X100/16. Усл. п. л. 63,21.
Тираж 4000 экз. Заказ № 2871.
ООО «Питер Принт». 196105, Санкт-Петербург, ул. Благодатная, д. 67в.
Налоговая льгота — общероссийский классификатор продукции
ОК 005-93, том 2; 953005 —литература учебная.
Отпечатано с готовых диапозитивов в ФГУП «Печатный двор» им. Л. М. Горького
Министерства РФ по делам печати, телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.