/
Автор: Вегешна Ш.
Теги: компьютерные технологии информатика компьютерные сети
ISBN: 5-8459-0404-8
Год: 2003
Текст
Качество обслуживания
' В СЕТЯХ IP
*IP Quality of Service
Srinivas Vegesna
Cisco Systems
miiunHmiiiim®
Cisco Press
Cisco Press i V
201 West 1O3rd Street,
Indianapolis, IN 46290 USA
Качество обслуживания
в сетях IP
Шринивас Вегешна
ВИЛЬЯМС
Москва • Санкт-Петербург • Киев
2003
ББК 32.973.26-018.2.75
В26
УДК 681.3.07
Издательский дом “Вильямс”
Зав. редакцией С.Н. Тригуб
Руководитель проекта В. В. Александров
Перевод с английского А.А. Борисенко и А.В. Журавлева
Под редакцией А. В. Журавлева
По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу:
info@williamspublishing.com, http://www.williamspublishing.com
Вегешна, Шринивас.
В26 Качество обслуживания в сетях IP. : Пер. с англ. — М. : Издательский
дом “Вильямс”, 2003. — 368 с. : ил. — Парад, тит. англ.
ISBN 5-8459-0404-8 (рус.)
Реализация в компьютерных сетях технологий QoS (Quality of Service) обеспечивает
надежную доставку данных приложений посредством контроля за доступом к сети, за-
держкой, потерей, качеством передаваемых пакетов и пропускной способностью кана-
лов передачи информации. Функции QoS являются неотъемлемой частью современных
легкомасштабируемых сетей IP. Глубокое знание основных концепций и возможностей
технологий QoS позволит сетевым планировщикам, разработчикам и инженерам мак-
симально оптимизировать производительность сетей и обеспечить стабильное функ-
ционирование нового поколения мультимедийных и голосовых приложений. Эта книга
является источником чрезвычайно полезной информации для всех, кто планирует раз-
вертывание служб QoS в сетях, построенных на базе оборудования компании Cisco
Systems. Автор проводит исчерпывающий обзор возможностей и функций QoS в сетях
IP, не забывая при этом о поучительных практических упражнениях и примерах кон-
фигурации устройств. Основной акцент делается на обсуждении реальных задач, что не
только познакомит читателя с различными теоретическими концепциями, но и научит
его решать наиболее распространенные проблемы проектирования.
Книга рассчитана на пользователей высокой квалификации и профессионалов.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками
соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой
бы то ни было форме и какими бы то ни было средствами, будь то электронные или механиче-
ские, включая фотокопирование и запись на магнитный носитель, если на это нет письменного
разрешения издательства Cisco Press.
Authorized translation from the English language edition published by Cisco Press, Copyright © 2001
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage re-
trieval system, without permission from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with
R&I Enterprises International, Copyright © 2003
ISBN 5-8459-0404-8 (pyc.)
ISBN 1-5787-0116-3 (англ.)
© Издательский дом “Вильямс”, 2003
© Cisco Press, 2001
Оглавление
Об авторе 13
Благодарности 14
Посвящения 14
О технических рецензентах 15
Часть I. Качество обслуживания в сетях IP 17
Глава 1. Введение в качество обслуживания в сетях IP 19
Глава 2. Архитектура дифференцированных услуг 37
Глава 3. Формирование трафика на границе сети: классификация пакетов,
маркировка пакетов и управление интенсивностью трафика 51
Глава 4. РНВ-политика: распределение ресурсов (часть 1) 89
Глава 5. РНВ-политика: распределение ресурсов (часть 2) 131
Глава 6. РНВ-политика: предотвращение перегрузки и политика
отбрасывания пакетов 153
Глава 7. Интегрированные услуги: RSVP 177
Часть II. Качество обслуживания канального уровня и сети MPLS —
межсетевой обмен с IP QoS 197
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен с IP QoS 199
Глава 9. Качество обслуживания в сетях MPLS 241
Часть III. Управление трафиком 275
Глава 10. Управление трафиком в сетях MPLS 277
Часть IV. Приложения 307
Приложение А. Модульный интерфейс командной строки Cisco QoS 309
Приложение Б. Механизмы коммутации пакетов 317
Приложение В. Политики маршрутизации 331
Приложение Г. Транспортный протокол реального времени (RTP) 343
Приложение Д. Общие функции линейной эфективности протокола IP 345
Приложение Е. Фрагментация и чередование пакетов на канальном уровне 349
Приложение Ж. Значения поля IP-приоритета и поля DSCP 353
Предметный указатель 356
Содержание
Об авторе 13
Благодарности 14
Посвящения 14
О технических рецензентах 15
Часть I. Качество обслуживания в сетях IP 17
Глава 1. Введение в качество обслуживания в сетях IP 19
Уровни качества обслуживания 20
Краткий экскурс в историю возникновения и развития качества
обслуживания в сетях IP 23
Характеристики производительности сетевого соединения 25
Полоса пропускания 25
Задержка и дрожание при передаче пакетов 26
Потеря пакетов 27
Функции качества обслуживания 28
Классификация и маркировка пакетов 28
Управление интенсивностью трафика 28
Распределение ресурсов 28
Предотвращение перегрузки и политика отбрасывания пакетов 29
Сигнальный протокол QoS 29
Коммутация 29
Маршрутизация 29
Технологии качества обслуживания канального уровня 30
Многопротокольная коммутация меток 30
Сквозное качество обслуживания 31
Цели 32
Аудитория 32
Широта охвата и ограничения изложенного в книге материала 33
Организация книги 33
Часть I 34
Часть II 34
Часть III 34
Часть IV 34
Глава 2. Архитектура дифференцированных услуг 37
Архитектура интегрированных услуг (intserv) 37
Архитектура дифференцированных услуг (diffserv) 38
Формирователи трафика, расположенные на границе сети 42
РНВ-политика 43
Политика распределения ресурсов 45
Резюме 48
Глава 3. Формирование трафика на границе сети: классификация пакетов,
маркировка пакетов и управление интенсивностью трафика 51
Классификация пакетов 52
Маркировка пакетов 53
IP-приоритет 53
DSCP 54
QoS-группа 54
Практический пример 3.1: классификация и маркировка пакетов
с использованием поля IP-приоритета 55
Практический пример 3.2: классификация и маркировка пакетов
с использованием поля QoS-группы 58
Практический пример 3.3: переопределение значения поля
IP-приоритета 60
Необходимость управления интенсивностью трафика 61
Корзина маркеров 61
Ограничение трафика 62
Практический пример 3.4: ограничение интенсивности трафика
приложения на уровне обслуживания 68
Практический пример 3.5: ограничение интенсивности трафика
в зависимости от значения IP-приоритета 70
Практический пример 3.6: предоставление услуг с ограниченной
интенсивностью трафика 71
Практический пример 3.7: предоставление услуг по размещению
Web-серверов 71
Практический пример 3.8: предотвращение атак типа Denial-of-Service 72
Практический пример 3.9: ограничение трафика в точке обмена
трафиком общего пользования 72
Выравнивание трафика 74
Дозирование трафика 75
Практический пример 3.10: выравнивание интенсивности трафика
до скорости доступа 76
Практический пример 3.11: выравнивание интенсивности входящего
и исходящего трафика узла 79
Практический пример 3.12: выравнивание трафика Frame Relay в ответ
на получение обратного явного уведомления о перегрузке (BECN) 82
Резюме 84
Глава 4. РНВ-политика: распределение ресурсов (часть 1) 89
Поддержка функций QoS со стороны механизмов обслуживания очередей 90
Алгоритм обслуживания очередей FIFO 91
Максиминная схема равномерного распределения ресурсов 91
Обобщенная схема разделения процессорного времени 94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе вычисления порядкового номера пакета 94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе потока 98
Взаимодействие механизма WFQ с протоколом RSVP 101
Реализация алгоритма WFQ 101
Содержание 7
Практический пример 4.1; взвешенный механизм равномерного
обслуживания очередей (WFQ) на основе потока 103
Практический пример 4.2: распределение полосы пропускания в
зависимости от веса потока 104
Практический пример 4.3: одновременное обслуживание WFQ-
планировщиком потоков голосового трафика и FTP-трафика 105
Распределенный взвешенный алгоритм равномерного обслуживания
очередей (DWFQ) на основе потока 106
Практический пример 4.4: распределенный взвешенный алгоритм
равномерного обслуживания очередей (DWFQ) на основе потока 108
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе класса 108
Практический пример 4.5: выделение дополнительной полосы
пропускания для критического трафика 109
Практический пример 4.6: выделение дополнительной полосы
пропускания в зависимости от входного интерфейса 111
Практический пример 4.7: выделение полосы пропускания в зависимости
от класса ToS 111
Конфигурация механизма CBWFQ без использования модульного
интерфейса командной строки QoS ИЗ
Практический пример 4.8: выделение полосы пропускания в зависимости
от QoS-группы без использования модульного интерфейса командной
строки QoS 115
Приоритетное обслуживание очередей 115
Практический пример 4.9: обслуживание трафика на основании
значения поля IP-приоритета 116
Практический пример 4.10: приоритетное обслуживание пакетов
на основе размера 117
Практический пример 4.11: приоритетное обслуживание пакетов
на основе адреса источника 118
Заказное обслуживание очередей 118
Роль счетчика байтов в механизме заказного обслуживания очередей 119
Практический пример 4.12: выделение минимальной полосы
пропускания интерфейса для различных протоколов 120
Механизмы обслуживания очередей, предназначенные для обработки
голосового трафика 123
Механизм CBWQF с приоритетной очередью 123
Практический пример 4.13: очередь со строгим приоритетом
обслуживания, предназначенная для обработки голосового трафика 124
Механизм заказного обслуживания с приоритетными очередями 125
Резюме 126
Глава 5. РНВ-политика: распределение ресурсов (часть 2) 131
Модифицированный взвешенный алгоритм кругового обслуживания
(MWRR) 131
Пример работы алгоритма MWRR 132
Реализация алгоритма MWRR 138
Практический пример 5.1: алгоритм MWRR на основе класса трафика 139
8
Содержание
Модифицированный алгоритм кругового обслуживания
с дефицитом (MDRR) 140
Пример работы алгоритма MDRR 142
Реализация алгоритма MDRR 146
Практический пример 5.2: выделение полосы пропускания
и минимизация дрожания голосового трафика в рамках политики
предотвращения перегрузки 147
Резюме 150
Глава 6. РНВ-политика: предотвращение перегрузки и политика
отбрасывания пакетов 153
Механизм медленного старта и предотвращение перегрузки 154
Реакция TCP-трафика на применение политики “отбрасывания хвоста” 155
RED — алгоритм превентивного управления очередью с целью
предотвращения перегрузки сети 156
Алгоритм вычисления среднего размера очереди 158
Алгоритм вычисления вероятности отбрасывания пакетов 159
Взвешенный алгоритм произвольного раннего обнаружения (WRED) 160
Реализация алгоритма WRED 160
Практический пример 6.1: применение механизма WRED для
предотвращения перегрузки канала передачи информации 161
Практический пример 6.2: конфигурация механизма WRED на основе
класса трафика с помощью модульного интерфейса командной строки
QoS 163
Алгоритм WRED на основе потока 164
Практический пример 6.3: предотвращение перегрузки для
неадаптивных потоков трафика 166
Механизм явного уведомления о перегрузке (ECN) 167
Механизм избирательного отбрасывания пакетов (SPD) 168
Практический пример 6.4: предотвращение атаки злоумышленника,
использующего некорректные IP-пакеты, с помощью механизма SPD 170
Резюме 172
Глава 7. Интегрированные услуги: RSVP 177
Протокол RSVP 177
Работа протокола RSVP 178
RSVP-компоненты 180
RSVP-сообщения 181
Стили резервирования 182
Индивидуальное резервирование 182
Общее резервирование 183
Типы услуг 185
Регулируемая нагрузка 185
Гарантированная битовая скорость 185
Среда передачи и протокол RSVP 186
Масштабируемость протокола RSVP 186
Практический пример 7.1: сквозное резервирование полосы
пропускания для приложения с помощью протокола RSVP 187
Содержание
9
Практический пример 7.2: использование протокола RSVP с целью
резервирования ресурсов для VoIP-трафика 193
Резюме 194
Часть II. Качество обслуживания канального уровня и сети MPLS —
межсетевой обмен с IP QoS 197
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен с IP QoS 199
ATM 199
Формат ATM-ячейки 200
ATM QoS 201
Классы услуг ATM 202
Стратегии отбрасывания ячеек 204
Выравнивание трафика на виртуальном пути 205
Практический пример 8.1: применение услуги ABR к каналу PVC 205
Практический пример 8.2: выравнивание трафика на виртуальном пути 206
Межсетевой обмен ATM и IP QoS 208
Практический пример 8.3: дифференцированное отбрасывание
IP-пакетов на границе АТМ-сети 211
Практический пример 8.4: дифференцированное обслуживание 214
Практический пример 8.5: установка CLP-бита на основе IP-приоритета 216
Frame Relay 216
Механизм предотвращения перегрузки в сети Frame Relay 217
Механизм выравнивания трафика в сети Frame Relay (FRTS) 218
Фрагментация в сетях Frame Relay 221
Межсетевой обмен Frame Relay и IP QoS 223
Практический пример 8.6: выравнивание трафика Frame Relay
с использованием функции автораспознавания QoS 224
Практический пример 8.7: адаптивный механизм выравнивания
трафика и интеграция BECN/FECN 225
Практический пример 8.8: использование нескольких PVC-каналов
для передачи различных типов трафика 227
Практический пример 8.9: конфигурация механизма WFQ на каждом
VC-канале 230
Практический пример 8.10: отображение DE-бита Frame Relay на биты
IP-приоритета 230
Практический пример 8.11: фрагментация Frame Relay 231
Семейство локальных сетей IEEE 802.3 232
Возможность передачи высокоприоритетного трафика 233
Резюме 237
Глава 9. Качество обслуживания в сетях MPLS 241
MPLS 241
Передающий компонент 242
Управляющий компонент 242
Инкапсуляция меток 246
MPLS и ATM 248
Практический пример 9.1: нисходящее распространение меток 249
Качество обслуживания в сетях MPLS 254
10
Содержание
Предоставление сквозных услуг IP QoS 255
Практический пример 9.2: MPLS CoS 256
LER-маршрутизатор 256
LSR-маршрутизатор 257
Виртуальные частные сети (VPN) на основе MPLS 258
Практический пример 9.3: MPLS VPN 259
Качество обслуживания в сетях MPLS VPN 268
Дифференцированные услуги MPLS VPN QoS 268
Гарантированные услуги QoS 270
Практический пример 9.4: качество обслуживания в сетях MPLS VPN 271
Резюме 271
Часть III. Управление трафиком 275
Глава 10. Управление трафиком в сетях MPLS 277
Оверлейная модель канального уровня 278
Маршрутизация на основе резервирования ресурсов (RRR) 279
Определение ТЕ-транка 280
Атрибуты ТЕ-туннеля 281
Полоса пропускания 282
Приоритет установки и удержания 282
Родственность класса ресурса 282
Порядок выбора пути 283
Адаптируемость 283
Устойчивость 283
Атрибуты ресурсов канала 283
Доступная полоса пропускания 283
Класс ресурса 284
Распространение информации о ресурсах канала 284
Политика выбора пути 284
Установка ТЕ-туннеля 285
Управление доступом к каналу 286
Поддержка ТЕ-пути 286
Сигнальный протокол TE-RSVP 287
Расширения протокола маршрутизации внутреннего шлюза 288
Модификации протокола IS-IS 288
Модификации протокола OSPF 288
Подходы к реализации механизма управления трафиком 289
Практический пример 10.1: установка и функционирование ТЕ-туннеля в
MPLS-сети 289
Резюме 304
Часть IV. Приложения 307
Приложение А. Модульный интерфейс командной строки Cisco QoS 309
Определение класса трафика 310
Определение политики 311
Применение политик 312
Иерархические политики 313
Содержание 11
Порядок выполнения политик 314
Упорядочение политик 314
Упорядочение операторов внутри политик 315
Приложение Б. Механизмы коммутации пакетов 317
Коммутация процессов 317
Продвижение пакетов с помощью кэша маршрутов 318
CEF-коммутация 319
Преимущества CEF-коммутации 319
Распределенный механизм коммутации CEF (DCEF) 321
Практический пример Б.1: применение механизма коммутации CEF
на магистральном маршрутизаторе 321
Сравнение механизмов коммутации с помощью кэша маршрутов и CEF 328
Резюме 329
Приложение В. Политики маршрутизации 331
Использование QoS-политик при принятии решения о маршрутизации 331
Маршрутизация на основе качества обслуживания (QoS) 331
Маршрутизация на основе политики 332
Практический пример В.1: маршрутизация на основе IP-приоритета 333
Практический пример В.2: маршрутизация на основе размера пакета 335
Распространение QoS-политик с помощью протокола BGP 336
Практический пример В.З: применение политики QoS для входящего
и исходящего трафика 338
Резюме 341
Приложение Г. Транспортный протокол реального времени (RTP) 343
Приложение Д. Общие функции линейной эфективности протокола IP 345
Алгоритм Нагля 345
Функция определения максимально возможной единицы передачи данных
(MTU) пути 346
Сжатие заголовка TCP/IP 346
Сжатие RTP-заголовка 346
Приложение Е. Фрагментация и чередование пакетов на канальном уровне 349
Приложение Ж. Значения поля IP-приоритета и поля DSCP 353
Предметный указатель 356
12
Содержание
Об авторе
Шринивас Вегешна (Srinivas Vegesna), CCIE #1399, занимает пост менеджера служ-
бы по предоставлению расширенной консультации поставщикам услуг Internet в ком-
пании Cisco Systems. Основным направлением его деятельности является разработка
общих принципов построения IP-сетей с акцентом на протоколах маршрутизации и
качестве обслуживания в сетях IP. За 6 лет работы в компании Cisco Systems Шрини-
вас имел опыт сотрудничества с большим числом поставщиков услуг Internet и корпо-
ративных заказчиков, проектируя, внедряя крупномасштабные IP-сети и устраняя не-
поладки в них. Шринивас получил степень магистра по электротехнике в университе-
те штата Аризона. В настоящее время он проходит обучение с целью получить
степень магистра делового администрирования в университете Санта-Клары.
Благодарности
Прежде всего я хотел бы поблагодарить своих друзей и коллег в компании Cisco Sys-
tems за создание стимулирующей рабочей обстановки на протяжении последних 6 лет. Я
очень ценю технические дискуссии, которые велись нами посредством внутренней элек-
тронной почты и во время прогулок по длинным коридорам офисов компании. Отдель-
ная благодарность техническим рецензентам этой книги — Сэнджею Карле (Sanjay
Karla) и Виджею Боллапрагаде (Vijay Bollapragada), а также исполнительным редакто-
рам — Китти Джаррет (Kitty Jarret) и Элисону Джонсону (Allison Johnson). Благодаря их
стараниям книга претерпела значительные изменения, что сказалось самым положи-
тельным образом как на ее содержании, так и на способе изложения материала. Огром-
ное спасибо Мосадаку Тураби (Mosaddaq Turabi) за его ценные замечания и интерес,
проявленный к данной книге. Я хотел бы вспомнить также своего коллегу и друга Кэ-
вина Ху (Kevin Hu), который покинул нас в 1995 году. Кэвин и я начали работать в
Cisco Systems в один день и были настоящей командой на протяжении целого года. Кэ-
вин был очень разносторонне развитым и ярким человеком.
И, наконец, я хотел бы поблагодарить свою семью, без поддержки и терпения ко-
торой эта книга вряд ли когда-либо вышла в свет. Хочу выразить чувство огромной
любви и признательности своей жене Лате (Latha), которая поддерживала меня на
протяжении всего процесса написания книги. Большое спасибо моему брату Шрихари
(Srihari) — за то, что он прекрасный брат и друг. Отдельное спасибо моему двухлетне-
му сыну Акшею (Akshay) за его чудесную улыбку и прелестный лепет, а также моему
только что родившемуся сыну Картику (Karthik) за его невинный вид и просто пото-
му, что он такой замечательный.
Посвящения
Моим родителям, Венкатапати Раджу (Venkatapathi Raju) и Кастури (Kasturi).
О технических рецензентах
Виджей Боллапрагада (Vijay Bollapragada), CCIE #1606, в настоящее время работает
менеджером в группе технических решений (Solution Engineering) компании Cisco
Systems, где он занимается вопросами современных сетевых решений и устраняет
сложные проблемы, связанные с программным и аппаратным обеспечением оборудо-
вания Cisco. Виджей читает несколько курсов для инженеров компании Cisco Systems
и персонала компаний-клиентов, включая курс по архитектуре маршрутизаторов Cisco
(Cisco Router Architecture), широковещательной передаче информации в сетях IP (IP
Multicast), качеству обслуживания в Internet (Internet Quality of Service) и принципам
маршрутизации в Internet (Internet Routing Architectures). Виджей является адъюнкт-
профессором факультета электротехники в университете Дьюка.
Эрик Map (Erick Маг), CCIE #3882, работает системным инженером-консультантом
(Consulting Systemd Engineer) в компании Cisco Systems. Эрик получил квалификацию сер-
тифицированного специалиста по межсетевому обмену Cisco (CCIE) в области маршрути-
зации и коммутации. Последние 8 лет он работал с различными производителями сетевого
оборудования, занимаясь вопросами проектирования и внедрения сетевых решений для
крупных компаний из списка Fortune 500. Эрик получил степень магистра экономики
управления (М.В.А.) в университете Санта-Клары и бакалавра экономики управления в
университете штата Сан-Франциско.
Шери Моран (Sheri Moran), CCIE #1476, работает на компанию Cisco Systems, Inc.
вот уже более 7 лет. В настоящее время она является системным инженером-
консультантом компании Northeast Commercial Operation, занимая эту должность на
протяжении последних полутора лет. Шери специализируется на маршрутизации,
коммутации, качестве обслуживания, проектировании университетских сетей, широ-
ковещательной передаче информации в сетях IP и технологиях IBM. До этого 6 лет
Шери работала инженером-консультантом центрального региона штата Нью-Джерси,
обеспечивая поддержку корпоративных сетей таких компаний, как Prudential, John-
son & Johnson, Bristol Meyers Squibb, Nabisco, Chubb Insurance и American Reinsurance.
Шери закончила с отличием Вестминстерский колледж в Нью-Вилмингтоне, штат
Пенсильвания, получив степень бакалавра в области вычислительной техники и мате-
матики (Computer Science and Math). Помимо этого, Шери закончила с отличием
университет округа Монмут (Monmouth University) (ранее — колледж округа Монмут
(Monmouth College)), штат Нью-Джерси, получив степень магистра по финансам.
Шери является сертифицированным специалистом по межсетевому обмену Cisco
(CCIE), владея также сертификатом Cisco CIP и сертификатом Novell. В настоящее
время Шери живет в Милстоуне, штат Нью-Джерси.
Часть
' t, /«,s
Качество обслуживания
в сетях IP
В этой части.
Ж
&
Глава 1.' Введение в качество обслуживания в сетях IP
Глава 2. Архитектура дифференцированных услуг
Глава 3. Формирование трафика на границе сети:
, ,й. классификация пакетов, маркировка пакетов
и управление интенсивностью трафика
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
Глава 6. РНВ-политика: предотвращение перегрузки
и политика отбрасывания пакетов
Глава 7. Интегрированные услуги; RSVP
19
37
51
89
131
153
177
В этой главе...
Уровни качества, обслуживания
IZ „ Jr & t"
Кратким экскурс в историю возникновения й развития качества
обслуживания в сетях IP *
Характеристики производительности сетевого соединения
Функции качества обслуживания* '<
Технологии качества обслуживания канального уровня й.
Многопротокольная коммутация меток
^Сквозное кадге^тво обслуживания
>Цели Л! >.
$ -dr #
Аудиторття Ц
4 Широта охвата и ограничения изЙОйкенного в книге материал
? . Организация книги
20
23
25
28
зо
30
Jo
ж
' <ч
32
33
&
Глава
Введение в качество
обслуживания в сетях IP
вплоть до настоящего времени поставщикам услуг Internet и крупным компаниям при-
s ходилось создавать и поддерживать ,отдельные сети для передачи голосовой информации,
? видеоизображения, трафика, необходимого для решения критически важных задач, и всего
остального сетевого трафика. Тем не менее нельзя не отметить сложившуюся в последнее
э'время ярко выраженную тенденцию к объединению всех этих сетей в одну сеть с пакетной
к передачей данных на основе протокола Internet Protocol (IP).
v Наиболее крупная IP-сеть — этб^ естественно, глобальная сеть Internet. За последние
несколько лет рост Internet, передаваемого по Сети трафика и количества существующих
Internet-приложений приблизился к экспоненциальному. В то время как Internet и кор-
поративные интрасети продолжают свой рост, многие аналитики предсказывают появ-
ление приложений, ориентированных на передачу нетрадиционных типов информа-
ции и, — например, передачу голоса по сетям IP (Voice over IP — VoIP) или передачу тра-
фика видеоконференций. Поскольку .количество пользователей Internet и различных
сетевых приложений увеличивается^с’каждым днем, Сеть нуждается в средствах, кото-
Цз рые бы обеспечили поддержку как существующих, так и появляющихся приложений и
Ц служб. Тем не менее на сегодняшний; день Internet может обеспечить всего лишь
й негарантированную доставку daHHbix(best effort service). Негарантированная доставка дан-
; ных не предполагает предоставление каких-либо гарантий, касающихся времени и са-
мого факта прибытия пакета в пункт назначения. При этом нельзя не отметить, что от-
брасывание пакетов может произойти только в момент перегрузки сети. (Более подроб-
но негарантированная доставка пакетов рассматривается в разделе “Уровни качества
обслуживания” далее в этой главе.) :
Как правило, передаваемые по сети пакеты различаются на основе пяти полей за-
головка IP, которые однозначно определяют поток данных, — адрес источника IP-
пакета, адрес назначения IP-пакета, поле протокола IP, порт источника и порт назна-
чения. Поток информации состоит из пакетов, сгенерированных приложением, вы-
полняющемся на компьютере-источнике, и предназначающихся для передачи прило-
жению, выполняющемуся на компьютере-приемнике. Пакеты, принадлежащие одно-
му потоку, имеют одинаковые значения всех пяти полей в заголовке IP-пакета.
С целью поддержки передачи голоса, видео и трафика данных приложений с раз-
личными требованиями к пропускной способности, системы ядра IP-сети должны об-
ладать возможностью дифференцирования и обслуживания различных типов сетевого
трафика в зависимости от предъявляемых ими требований. Негарантированная дос-
тавка данных не предполагает проведения какого-либо различия между тысячами по-
токов информации в ядре IP-сети. Следовательно, IP-сеть не может обеспечить ника-
кой гарантии надежной доставки трафика приложений. Другими словами, негаранти-
рованная доставка данных препятствует передаче трафика, требующего выделения
заданного минимума сетевых ресурсов и гарантии предоставления определенных ус-
луг. Для разрешения описанной выше проблемы и было введено такое понятие, как
качество обслуживания (quality of service — QoS) в сетях IP.
Функции качества обслуживания в сетях IP (IP QoS) заключаются в обеспечении
гарантированного и дифференцированного обслуживания сетевого трафика путем пе-
редачи контроля за использованием ресурсов и загруженностью сети ее оператору.
QoS представляет собой набор требований, предъявляемых к ресурсам сети при
транспортировке потока данных. QoS обеспечивает сквозную гарантию передачи дан-
ных и основанный на системе правил контроль за средствами повышения производи-
тельности IP-сети, такими, как механизм распределения ресурсов, коммутация, мар-
шрутизация, механизмы обслуживания очередей и механизмы отбрасывания пакетов.
Ниже перечислены некоторые из основных преимуществ качества обслуживания в
сетях IP.
• Обеспечение поддержки существующих и появляющихся мультимедийных служб и
приложений. Некоторые новые приложения, такие, как передача голоса по сетям IP
(VoIP), предъявляют определенные требования к качеству обслуживания.
• Передача контроля за ресурсами сети и их использованием сетевому оператору.
• Обеспечение гарантии обслуживания и дифференцирование сетевого трафика.
Это условие является необходимым для объединения аудио-, видеотрафика и
трафика приложений в пределах одной 1Р-сети.
• Позволяет поставщикам услуг Internet предлагать клиентам дополнительные услуги
наряду со стандартной услугой негарантированной доставки данных (другими
словами, предоставлять услуги в соответствии с так называемым классом обслужи-
вания — Class of Service (CoS)). Поставщик услуг Internet может определить несколь-
ко классов дополнительных услуг (например, “платиновый”, “золотой” и
“серебряный” классы) и настроить сетевые правила, позволяющие обрабатывать
трафик каждого класса в соответствии с заданными параметрами.
• Дает возможность организовать обслуживание сетевого трафика в зависимости
от сгенерировавшего этот трафик приложения, информация о котором содер-
жится в заголовке IP-пакета.
• Играет значительную роль в развитии новых сетевых технологий, таких, как
виртуальные частные сети (Virtual Private Networks — VPNs).
Уровни качества обслуживания
Сетевой трафик состоит из множества потоков, сгенерированных приложениями
конечных станций. Эти приложения отличаются друг от друга различными требова-
ниями к обслуживанию и к рабочим характеристикам сети. По сути, требование к об-
20
Часть I. Качество обслуживания в сетях IP
служиванию каждого потока целиком и полностью определяется требованиями сгене-
рировавшего этот поток приложения. Следовательно, для того чтобы выяснить струк-
туру сушествуюших в сети запросов на качество обслуживания, необходимо опреде-
лить типы сетевых приложений.
Способность сети обеспечивать различные уровни обслуживания, запрашиваемые теми
или иными сетевыми приложениями, наряду с проведением контроля за характеристика-
ми производительности — полосой пропускания, задержкой/дрожанием и потерей паке-
тов — может быть классифицирована по трем перечисленным ниже категориям.
• Негарантированная доставка данных (best-effort service). Обеспечение связности
узлов сети без гарантии времени и самого факта доставки пакета в точку назна-
чения. Следует отметить, что отбрасывание пакета может произойти только в
случае переполнения буфера входной или выходной очереди маршрутизатора.
На самом деле негарантированная доставка пакетов не является частью QoS
вследствие отсутствия гарантии качества обслуживания и гарантии обеспе-
чения доставки пакетов. Следует отметить, что негарантированная доставка
пакетов является на сегодняшний день единственной услугой, поддержи-
ваемой в Internet.
Несмотря на некоторое снижение производительности, для большинства при-
ложений, ориентированных на передачу информации (например, приложений,
обеспечиваюших взаимодействие по протоколу передачи файлов (File Transfer
Protocol — FTP)), эта услуга является вполне достаточной. В целом же опти-
мальные условия функционирования всех приложений включают в себя требо-
вания к выделению определенных сетевых ресурсов в терминах полосы пропус-
кания, задержки и уровня потери пакетов.
• Дифференцированное обслуживание (differentiated service). Дифференцирование
обслуживание предполагает разделение трафика на классы на основе требова-
ний к качеству обслуживания. Каждый класс трафика дифференцируется и об-
рабатывается сетью в соответствии с заданными для этого класса механизмами
QoS. Подобная схема обеспечения качества обслуживания (QoS) довольно часто
называется схемой CoS.
Следует отметить, что дифференцированное обслуживание само по себе не
предполагает обеспечения гарантий предоставляемых услуг. В соответствии с
данной схемой трафик распределяется по классам, каждый из которых имеет
свой собственный приоритет. По этой причине дифференцированное обслужи-
вание довольно часто называют мягким QoS (soft QoS).
Дифференцированное обслуживание удобно применять в сетях с интенсивным
трафиком приложений. В этом случае важно обеспечить отделение администра-
тивного трафика сети от всего остального трафика и назначить ему приоритет,
позволяюший в любой момент времени быть уверенным в связности узлов сети.
• Гарантированное обслуживание (guaranteed service). Гарантированное обслужива-
ние предполагает резервирование сетевых ресурсов с целью удовлетворения
специфических требований к обслуживанию со стороны потоков трафика.
В соответствии с гарантированным обслуживанием выполняется предваритель-
ное резервирование сетевых ресурсов по всей траектории движения трафика.
Глава 1. Введение в качество обслуживания в сетях IP
21
Гарантированное обслуживание довольно часто называют еше жестким QoS
(hard QoS) в связи с предъявлением строгих требований к ресурсам сети.
К сожалению, резервирование ресурсов на всем пути следования отдельных потоков
трафика невозможно реализовать в масштабах магистрали Internet, обслуживающей
в отдельный момент времени тысячи потоков данных. Исправить положение при-
звано агрегированное резервирование ресурсов, требующее хранения в базовых
маршрутизаторах Internet всего лишь небольшого количества информации.
Приложения, требующие гарантированного обслуживания, включают в себя муль-
тимедийные приложения, проводящие передачу голосовой информации и видео-
изображений. Интерактивные приложения, ориентированные на передачу речи по
Internet, могут функционировать нормально (т.е. не вызывая неудобства у пользова-
телей) лишь в том случае, если значение латентности равно или меньше 100 мс.
Следует отметить, что аналогичный уровень латентности является приемлемым для
большинства мультимедийных приложений. А вот приложениям Intenet-телефонии
уже понадобится канал передачи информации с пропускной способностью как ми-
нимум 8 Кбит/с и со значением задержки подтверждения приема, равном 100 мс.
Для того чтобы удовлетворить подобные требования к гарантированному обслужи-
ванию, сеть должна обладать определенным запасом ресурсов.
Качество обслуживания уровня 2 эталонной модели OSI (Layer 2 QoS) включает в
себя все механизмы QoS, предусмотренные различными технологиями канального
уровня или технологиями, объектом которых этот уровень является. Более подробно
качество обслуживания уровня 2 эталонной модели OSI рассматривается в главе 8,
“Качество обслуживания на уровне 2: межсетевой обмен с IP QoS”, далее в этой
книге. Качество обслуживания уровня 3 эталонной модели OSI (Layer 3 QoS) включа-
ет в себя все механизмы QoS, предусмотренные на сетевом уровне (уровне протокола
IP). В табл. 1.1 перечислены три уровня обслуживания и соответствующие им разре-
шающие функции QoS канального и сетевого уровней эталонной модели OSI. Более
подробно эти функции рассматриваются в оставшейся части книги.
> Таблица 1.1. Уровни обслуживания и соответствующие им разрешающие •
функции QoS
Уровень обслуживания Разрешающая функция QoS Разрешающая функция QoS
сетевого уровня канального уровня
Негарантированная Связность узлов сети Технология асинхронной передачи
доставка пакетов данных (Asynchronous Transfer Mode — ATM), обслуживание с не- определенной битовой скоростью (Unspecified Bit Rate — UBR), ме- ханизм согласования скорости пе- редачи информации (Committed Information Rate — CIR) в сетях Frame Relay
22
Часть I. Качество обслуживания в сетях IP
Окончание табл. 1.1
Уровень обслуживания Разрешающая функция QoS сетевого уровня Разрешающая функция QoS канального уровня
Дифференцированное обслуживание Механизм согласования скорости доступа (Committed Access Rate — CAR) CoS, взвешенный алгоритм равномерного обслуживания оче- редей (Weighted Fair Queuing — WFQ), взвешенный алгоритм про- извольного раннего обнаружения (Weighted Random Early Detection - WRED) IEEE 802.1p
Гарантированное обслуживание Протокол резервирования ресур- сов (Resource Reservation Protocol — RSVP) Диспетчер пропускной способности подсети (Subnet Bandwidth Manager —SBM), механизм обслу- живания с постоянной битовой ско- ростью (Constant Bit Rate — CBR) в сетях ATM, механизм согласования скорости передачи информации (CIR) в сетях Frame Relay
Краткий экскурс в историю возникновения
и развития качества обслуживания в сетях IP
Качество обслуживания в сетях IP не является чьей-то блестящей идеей, возникшей на
протяжении нескольких последних лет. Отцы-основатели Internet предвидели эту потреб-
ность и предусмотрели байт типа обслуживания (Type of Service — ToS) в заголовке IP-
пакета. Следовательно, возможность реализации качества обслуживания была заложена
еще в начальной спецификации протокола IP. Ниже приведена выдержка из специфика-
ции протокола IP, в которой описывается предназначение байта ToS.
“Байт типа обслуживания (Type of Service — ToS) используется для указания абст-
рактных параметров требуемого качества обслуживания. На основании этих парамет-
ров производится выбор реальных характеристик механизмов обслуживания при пере-
даче датаграммы через заданную сеть.”1
Вплоть до конца 80-х годов Internet пребывала в “зародышевом” состоянии, что
характеризовалось низким объемом трафика и малым числом используемых сетевых
приложений. Следовательно, поддержкой байта ToS можно было пренебречь, что и
сделано практически во всех реализациях протокола IP. IP-приложения не произво-
дили установку значения байта ToS, а маршрутизаторы игнорировали его при приня-
тии решения о продвижении IP-пакета.
Важность внедрения механизма QoS в масштабах Internet возросла благодаря уве-
личению популярности Сети и приобретению ею коммерческих черт. Функциониро-
вание Internet базируется на сквозном режиме обслуживания пакетов данных без ори-
ентации на установку соединения, который подразумевает негарантированную достав-
ку информации с использованием для этого связки из двух протоколов — протокола
управления передачей (Transmission Control Protocol — TCP) и протокола Internet
(Internet Protocol — IP), более известную как TCP/IP. Несмотря на то что отсутствие
1 RFC 791: Internet Protocol Specification/Postel J., 1981.
Глава 1. Введение в качество обслуживания в сетях IP
23
ориентации на установку соединения делает Internet более гибкой и устойчивой к
сбоям, динамика передаваемых потоков данных делает ее склонной к перегрузкам,
которые чаще всего возникают в местах стыка двух сетей со значительно различаю-
щимися пропускными способностями. Проблема снижения работоспособности
TCP/IP сетей в моменты перегрузки была рассмотрена Джоном Наглем (John Nagle) в
середине 80-х годов прошлого столетия2.
Первоначально функции качества обслуживания были возложены на узлы Internet.
Одна из наиболее серьезных проблем, касающаяся дорогостоящих каналов передачи
информации глобальных сетей (Wide-Area Network — WAN), заключалась в их чрез-
мерной перегрузке пакетами протокола TCP, имеющими небольшой объем и сгенери-
рованными такими приложениями, как telnet и rlogin. Алгоритм Нагля, призванный
решить эту проблему, реализован сегодня во всем программном обеспечении, уста-
новленном в узлах Internet и поддерживающем протокол IP3. Можно сказать, что ал-
горитм Нагля “возвестил” о начале эпохи качества обслуживания в сетях IP.
В 1986 году Ван Якобсон (Van Jacobson) разработал следующий набор функций
Internet QoS для конечных систем — механизмы предотвращения перегрузки, являю-
щиеся стандартом де-факто для всех современных реализаций TCP. Следует отметить,
что эти механизмы (механизм медленного старта и механизм предотвращения пере-
грузки) играют огромную роль в предупреждении критического снижения работоспо-
собности сети в сегодняшней Internet. Ответственными за реагирование на сигналы о
перегрузке сети (которыми служат отброшенные пакеты) являются потоки трафика
TCP. В 1990 году для обеспечения оптимальной производительности сети в моменты
потери пакетов были разработаны два дополнительных механизма — механизм быст-
рой повторной передачи и механизм быстрого восстановления4.
Несмотря на то что реализация механизмов QoS в конечных системах является необхо-
димым условием, она не позволяет говорить о сквозном качестве обслуживания до тех пор,
пока соответствующие механизмы не будут реализованы в маршрутизаторах — устройст-
вах, ответственных за передачу трафика между конечными системами. Следовательно, с
1990-х годов акцент в разработке механизмов QoS вполне логично переместился на иссле-
дование возможности реализации функций качества обслуживания в маршрутизаторах.
Маршрутизаторы, поддерживающие только один механизм обслуживания очередей —
“первым пришел, первым обслужен” (first-in, first-out — FIFO), — не способны обеспечить
дифференцирование потоков трафика на основе их приоритета на уровне алгоритма пла-
нирования очередей. Более того, обслуживание очередей по методу FIFO приводит к от-
брасыванию пакетов и не способно защитить потоки с предсказуемым поведением от
“шалунов”. Решить данную проблему на уровне магистрали Internet были призваны алго-
ритм обслуживания очередей WFQ (Weighted Fair Queuing — взвешенный алгоритм равно-
мерного обслуживания очередей)5 и алгоритм управления очередями WRED (Weighted
Random Early Detection — взвешенный алгоритм произвольного раннего обнаружения)6.
2 RFC 896: Congestion Control in 1P/TCP Internetworks/Nagle J., 1984.
’ RFC 1122: Requirements for Internet Hosts — Communication Layers/Braden R., 1989.
4 RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algo-
rithms/Stevens W., 1997.
5 Demers A., Keshav S., Shenkar S. Design and Analysis of a Fair Queuing Algorithm. — In: Proceed-
ings of ACM SIGCOMM ’89, Austin, TX, September 1989.
6 Floyd S., Jacobson V. Random Early Detection Gateways for Congestion Avoidance. — IEEE/ACM
Transactions on Networking, August 1993.
24 Часть I. Качество обслуживания в сетях IP
Разработка механизмов QoS продолжилась попытками стандартизации функций
сквозного качества обслуживания в масштабах Internet. Целью рабочей группы IETF
по созданию интегрированных услуг (Integrated Services (intserv) Internet Engineering
Task Force (IETF) Working Group)7 является обеспечение приложений средствами
формулирования требований к ресурсам при сквозном обслуживании, а также разра-
ботка соответствующих механизмов на уровне маршрутизаторов и технологий подсе-
тей. Использующимся в этих целях сигнальным протоколом является протокол RSVP
(Resource Reservation Protocol — протокол резервирования ресурсов). В соответствии с
моделью intserv обслуживание каждого потока трафика производится на всей траекто-
рии соединения, что серьезно затрудняет использование этой модели в масштабах
магистрали Internet, обрабатывающей в каждый момент времени тысячи потоков ин-
формации. Более подробно протокол RSVP и типы обслуживания intserv рассматри-
ваются в главе 7, “Интегрированные услуги: RSVP”, далее в этой книге.
Несмотря на то что байт заголовка IP-пакета ToS до недавнего времени практиче-
ски не использовался, сейчас это один из самых распространенных методов определе-
ния требований к качеству обслуживания. Байт ToS представляет собой главный ме-
ханизм обеспечения услуг diffserv в масштабах Internet, что подвигло рабочую группу
IETF по созданию дифференцированных услуг (IETF differentiated services (diffserv)
Working Group)8 предложить стандартизировать этот байт в качества байта diffserv. Бо-
лее подробно архитектура diffserv рассматривается в главе 2, “Архитектура
дифференцированных услуг”, далее в этой книге.
Характеристики производительности сетевого
соединения
Внедрение механизмов QoS предполагает обеспечение со стороны сети соединения
с определенными ограничениями по производительности. Основными характеристи-
ками производительности сетевого соединения являются полоса пропускания, за-
держка, дрожание и уровень потери пакетов. Более подробно все упомянутые характе-
ристики производительности рассматриваются в следующих разделах этой главы.
Полоса пропускания
Термин полоса пропускания (bandwidth) используется для описания номинальной
пропускной способности среды передачи информации, протокола или соединения.
Этот термин достаточно эффективно определяет “ширину канала”, требующуюся
приложению для взаимодействия по сети.
Как правило, каждое соединение, нуждающееся в гарантированном качестве об-
служивания, требует от сети резервирования минимальной полосы пропускания.
К примеру, приложения, ориентированные на передачу оцифрованной речи, создают
поток информации интенсивностью 64 Кбит/с. Эффективное использование таких
приложений становится практически невозможным вследствие снижения полосы
пропускания ниже 64 Кбит/с на каком-либо из участков соединения.
7 IETF Intserv Working Group, www.ietf.org/html.charters/intserv-charter.html
8 IETF DiffServ Working Group, www.ietf.org/html.charters/dijfserv-charter.html
Глава 1. Введение в качество обслуживания в сетях IP
25
Задержка и дрожание при передаче пакетов
Задержка при передаче пакета (packet delay), или латентность (latency), на каждом пе-
реходе состоит из задержки сериализации, задержки распространения и задержки комму-
тации. Ниже приведены определения каждого из названных выше типов задержки.
• Задержка сериализации (serialization delay). Время, которое требуется устройству на
передачу пакета при заданной ширине полосы пропускания. Задержка сериализа-
ции зависит как от ширины полосы пропускания канала передачи информации,
так и от размера передаваемого пакета. Например, передача пакета размером
64 байт при заданной полосе пропускания 3 Мбит/с занимает всего лишь 171 нс.
Обратите внимание, что задержка сериализации очень сильно зависит от полосы
пропускания: передача того же самого пакета размером 64 байт при заданной по-
лосе пропускания 19.2 Кбит/с занимает уже 26 мс. Довольно часто задержку се-
риализации называют еще задержкой передачи (transmission delay).
• Задержка распространения (propagation delay). Время, которое требуется пере-
данному биту информации для достижения принимающего устройства на дру-
гом конце канала. Эта величина довольно существенна, поскольку в наилучшем
случае скорость передачи информации соизмерима со скоростью света. Обрати-
те внимание, что задержка распространения зависит от расстояния и исполь-
зуемой среды передачи информации, а не от полосы пропускания. Для линий
связи глобальных сетей задержка распространения измеряется в миллисекундах.
Для трансконтинентальных сетей Соединенных Штатов характерна задержка
распространения порядка 30 мс.
• Задержка коммутации (switching delay). Время, которое требуется устройству, по-
лучившему пакет, для начала его передачи следующему устройству. Как прави-
ло, это значение меньше 10 нс.
Обычно каждый из пакетов, принадлежащий одному и тому же потоку трафика,
передается с различным значением задержки. Задержка при передаче пакетов меняет-
ся в зависимости от состояния промежуточных сетей.
В том случае, если сеть не испытывает перегрузки, пакеты не ставятся в очередь в
маршрутизаторах, а общее время задержки при передаче пакета состоит из суммы за-
держки сериализации и задержки распространения на каждом промежуточном пере-
ходе. В этом случае можно говорить о минимально возможной задержке при передаче
пакетов через заданную сеть. Следует отметить, что задержка сериализации становит-
ся незначительной по сравнению с задержкой распространения при передаче пакета
по каналу с большой пропускной способностью.
Если же сеть перегружена, задержки при организации очередей в маршрутизаторах
начинают влиять на общую задержку при передаче пакетов и приводят к возникнове-
нию разницы в задержке при передаче различных пакетов одного и того же потока.
Колебание задержки при передаче пакетов получило название дрожания при передаче
пакетов (packet jitter).
Дрожание пакетов имеет большую важность, поскольку именно оно определяет
максимальную задержку при приеме пакетов в конечном пункте назначения. Прини-
мающая сторона, в зависимости от типа используемого приложения, может попытать-
ся компенсировать дрожание пакетов за счет организации приемного буфера для хра-
нения принятых пакетов на время, меньшее или равное верхней границе дрожания.
К этой категории относятся приложения, ориентированные на передачу/прием непре-
26
Часть I. Качество обслуживания в сетях IP
рывных потоков данных, например Internet-телефония или приложения, обеспечи-
вающие проведение видеоконференций.
На рис. 1.1 проиллюстрировано влияние задержки сериализации, задержки рас-
пространения и задержки коммутации на общую задержку при передаче пакетов в за-
висимости от возрастания полосы пропускания канала.
Задержка сериелизеции
Задержка коммутации
□ Задержка распространения
Рис. 1.1. Структура общей задержки при передаче пакета размером 1500 байт по
трансконтинентальному каналу Соединенных Штатов в зависимости от воз-
растания полосы пропускания
Обратите внимание, что задержка сериализации становится незначительной по
сравнению с задержкой распространения по мере увеличения полосы пропускания
канала. Задержка коммутации пренебрежимо мала в случае отсутствия пакетов в оче-
редях маршрутизаторов, однако склонна к существенному увеличению при росте раз-
меров очередей.
Потеря пакетов
Уровень потери пакетов (packet loss) определяет количество пакетов, отбрасывае-
мых сетью во время передачи. Основными причинами потери пакетов являются пе-
регрузка сети и повреждение пакетов во время передачи по линии связи. Чаще всего
отбрасывание пакетов происходит в местах перегрузки, где число поступающих паке-
тов намного превышает верхнюю границу размера выходной очереди. Кроме того, от-
брасывание пакетов может быть вызвано недостаточным размером входного буфера.
Как правило, уровень потери пакетов выражается как доля отброшенных пакетов за
определенный интервал времени.
Некоторые приложения не способны нормально функционировать или же функ-
ционируют крайне неэффективно в случае потери пакетов. Подобные приложения
требуют от сети гарантии надежной доставки всех пакетов.
Как правило, хорошо спроектированные сети характеризуются очень низким значе-
нием потери пакетов. Потеря пакетов также несвойственна приложениям, для которых
были заранее зарезервированы требуемые этими приложениями ресурсы. Что касается
волоконно-оптических линий связи со значением частоты появления ошибочных битов
(Bit Error Rate — BER) 10E-9, то здесь потеря пакетов возможна только в случае их от-
брасывания в местах перегрузки сети. Отбрасывание пакетов, к сожалению, является
неизбежным явлением при негарантированной доставке трафика, хотя и в этом случае
оно обуславливается крайней необходимостью. Следует отметить, что отброшенные па-
Глава 1. Введение в качество обслуживания в сетях IP
27
кеты указывают на неэффективное использование ресурсов сети, часть которых была
потрачена на доставку пакетов в точку, где они были потеряны.
Функции качества обслуживания
В данном разделе приводится краткое описание различных функций качества об-
служивания, связанных с ними возможностей и преимуществ. Более подробно каждая
из упомянутых здесь функций QoS рассматривается в оставшейся части этой книги.
Классификация и маркировка пакетов
Маршрутизаторы, расположенные на границе сети, используют функцию класси-
фикации для распознавания пакетов, принадлежащих различным классам трафика, в
зависимости от значения одного или нескольких полей в заголовке TCP/IP. Функция
маркировки пакетов используется для разметки классифицированного трафика путем
установки значения поля IP-приоритета или поля кода дифференцированного обслу-
живания (Differentiated Services Code Point — DSCP).
Более подробно функции классификации и маркировки пакетов рассматриваются
в главе 3, “Формирование трафика на границе сети: классификация пакетов,
маркировка пакетов и управление интенсивностью трафика”, далее в этой книге.
Управление интенсивностью трафика
Поставщики услуг используют ограничивающую функцию для приведения пара-
метров поступающего в сеть клиентского трафика в соответствие с его профилем. В то
же время, корпорации используют выравнивающую функцию для дозирования посту-
пающего в сеть поставщика услуг трафика и выравнивания его интенсивности в соот-
ветствии с заданным профилем. Наиболее распространенной схемой дозирования
трафика является так называемая схема корзины маркеров (token bucket).
Более подробно эта функция качества обслуживания рассматривается в главе 3,
“Формирование трафика на границе сети: классификация пакетов, маркировка паке-
тов и управление интенсивностью трафика”, далее в этой книге.
Распределение ресурсов
Наиболее распространенным механизмом обслуживания очередей в маршрутизаторах и
коммутаторах современной Internet является ставший уже традиционным механизм
“первым пришел, первым обслужен” (first-in, first-out — FIFO). Несмотря на простоту реа-
лизации, для механизма FIFO характерно несколько фундаментальных проблем, затруд-
няющих выполнение функций качества обслуживания. Так, механизм FIFO не предусмат-
ривает приоритетной обработки чувствительного к задержке трафика путем его перемеще-
ния во главу очереди. Весь трафик обрабатывается одинаково, без учета принадлежности
потоков к различным классам с разными требованиями к обслуживанию.
Минимальное требование, предъявляемое к поддерживающему функции QoS алго-
ритму обслуживания очередей, — способность дифференцировать и определять требо-
вания к обработке различных пакетов. В соответствии с этими параметрами алгоритм
обслуживания должен планировать порядок передачи поставленных в очередь паке-
тов. Частота обслуживания пакетов одного и того же потока трафика определяет вы-
деленную этому потоку полосу пропускания.
28
Часть I. Качество обслуживания в сетях IP
Более подробно функция распределения ресурсов рассматриваются в главе 4,
“РНВ-политика: распределение ресурсов (часть 1)”, далее в этой книге.
Предотвращение перегрузки и политика
отбрасывания пакетов
Традиционный механизм обслуживания очередей FIFO предусматривает отбрасы-
вание всех входяших пакетов после достижения максимального значения длины оче-
реди. Подобный способ управления очередью получил название “отбрасывание хво-
ста” (tail drop) и характеризуется тем, что сигнал о перегрузке поступает лишь в мо-
мент фактического переполнения очереди. К сожалению, механизм FIFO не
предусматривает проведения каких-либо активных действий по предотвращению пе-
регрузки или по уменьшению размера очереди с целью снижения времени задержки.
Активный алгоритм управления очередями позволяет маршрутизатору предвидеть пе-
регрузку еше до переполнения очереди.
Более подробно механизм предотвращения перегрузки и политика отбрасывания
пакетов рассматривается в главе 6, “РНВ-политика: предотвращение перегрузки и по-
литика отбрасывания пакетов”, далее в этой книге.
Сигнальный протокол QoS
Сигнальный протокол RSVP является частью разработанной организацией IETF архи-
тектуры intserv, обеспечивающей предоставление сквозных услуг QoS в масштабах Internet.
Протокол RSVP позволяет приложениям сообщать о требованиях к обслуживанию отдель-
ных потоков трафика. Для определения количественных показателей качества обслужива-
ния с целью управления доступом протокол RSVP использует служебные параметры.
Более подробно сигнальный протокол RSVP рассматривается в главе 7,
“Интегрированные услуги: RSVP”, далее в этой книге.
Коммутация
Главная функция маршрутизатора заключается в быстрой и эффективной комму-
тации входящего трафика на соответствующие выходные интерфейсы согласно ин-
формации, хранящейся в таблице продвижения пакетов. Традиционный механизм
продвижения пакетов, несмотря на его эффективность, обладает низкой масштаби-
руемостью; кроме того, его производительность оставляет желать лучшего в периоды
нестабильного функционирования сети, что выражается в резком увеличении расхо-
дов на обслуживание кэша и снижении эффективности коммутации пакетов.
Метод продвижения пакетов, учитывающий топологию сети, обладает бесспорны-
ми преимуществами перед методом, базирующимся на кэшировании пакетов, что
обусловлено совпадением таблицы продвижения пакетов с таблицей маршрутизации.
Механизм продвижения пакетов, учитывающий топологию сети, называется также
методом скоростной коммутации пакетов Cisco (Cisco Express Forwarding — CEF). Бо-
лее подробно различные механизмы коммутации пакетов рассматриваются в прило-
жении Б, “Механизмы коммутации пакетов”, далее в этой книге.
Маршрутизация
Традиционная маршрутизация осуществляется на основании адреса назначения пакета
и предполагает выбор наименее короткого маршрута, хранящегося в таблице маршрутиза-
Глава 1. Введение в качество обслуживания в сетях IP
29
ции. К сожалению, подобный механизм является недостаточно гибким для некоторых се-
тевых сценариев. Маршрутизация на основе политики — это функция качества обслужи-
вания, позволяющая заменить традиционный механизм маршрутизации пакетов механиз-
мом, учитывающим всевозможные настраиваемые пользователем параметры.
Современные протоколы маршрутизации, работающие по методу выбора наименее
короткого пути, позволяют учитывать такие значения метрики, как административное
расстояние, вес или число переходов. Маршрутизация пакетов осуществляется на ос-
новании хранящейся в таблице маршрутизации информации без учета требований по-
тока трафика к качеству обслуживания или доступности сетевых ресурсов на всем
протяжении маршрута. QoS-маршрутизация представляет собой механизм маршрути-
зации пакетов, учитывающий требования потоков трафика к качеству обслуживания и
осуществляющий выбор маршрута в зависимости от наличия сетевых ресурсов.
Более подробно маршрутизация на основе политики рассматривается в приложе-
нии В, “Политики маршрутизации”, далее в этой книге.
Технологии качества обслуживания
канального уровня
Поддержка функций качества обслуживания реализована в некоторых технологиях
уровня 2 эталонной модели OSI, включая технологии ATM, Frame Relay, Token Ring
и, в последнее время, коммутируемые локальные сети (LAN) семейства Ethernet. Как
технология, ориентированная на установку соединения, ATM предлагает наиболее
полную поддержку функций QoS с возможностью обеспечения гарантии качества об-
служивания для отдельного соединения. С учетом этого узел, запрашивающий соеди-
нение, может включить в свой запрос требования к качеству обслуживания и быть
уверенным в том, что сеть будет предоставлять ему соответствующие услуги в течение
всего времени существования данного соединения. Сети Frame Relay способны обес-
печить соединение с минимальным значением CIR, поддерживаемым даже в периоды
перегрузки сети. Технология Token Ring и более поздний стандарт IEEE (Institute of
Electrical and Electronic Engineers) 802. Ip также обладают механизмами дифференци-
рованного обслуживания.
Если функции качества обслуживания необходимо обеспечить в пределах подсети
или облака WAN, то перечисленные выше технологии канального уровня (в особен-
ности ATM) способны полностью оправдать возложенное на них доверие. Однако ни
ATM, ни какая-либо другая технология уровня 2 эталонной модели OSI не могут быть
всеобъемлющим решением для более крупных сетей, таких, как Internet.
Многопротокольная коммутация меток
Рабочая группа по созданию и внедрению технологии многопротокольной комму-
тации меток (Multiprotocol Label Switching (MPLS) Working Group)9 занимается стан-
дартизацией базовой технологии, предполагающей применение механизма продвиже-
ния пакетов на основе замены меток (метод коммутации меток) и использующейся
совместно с маршрутизацией сетевого уровня. Целью рабочей группы является разра-
ботка механизмов совместного использования технологии многопротокольной комму-
9 IETF MPLS Working Group, www.ietf.org/html.charters/mpls-charter.html
30
Часть I. Качество обслуживания в сетях IP
тации меток с различными технологиями канального уровня, включая Packet-over-
Sonet, Frame Relay, ATM и Ethernet co скоростью передачи данных 10, 100 и 1000 Мбит/с.
Стандарт MPLS базируется на механизме коммутации тэгов (tag switching), разработан-
ном компанией Cisco Systems.
В числе других преимуществ технология MPLS позволяет достичь большей гибко-
сти в предоставлении услуг QoS и управлении трафиком. Для идентификации потока
трафика с определенными требованиями к качеству обслуживания используются мет-
ки, которые, кроме всего прочего, позволяют проводить выбор оптимизированного
пути передачи пакета. Технология MPLS, виртуальные частные сети (VPNs) на основе
технологии MPLS и управление трафиком в сетях MPLS нашли свое применение
преимущественно в сетях поставщиков услуг. Более подробно многопротокольная
коммутация меток и качество обслуживания в сетях MPLS рассматриваются в главе 9,
“Качество обслуживания в сетях MPLS”, а управление трафиком в сетях MPLS — в
главе 10, “Управление трафиком в сетях MPLS”, далее в этой книге.
Сквозное качество обслуживания
Технологии QoS уровня 2 эталонной модели OSI способны стать полноценным реше-
нием лишь в сетях ограниченного размера и не могут быть применены для обеспечения
сквозного качества обслуживания в Internet и других крупных сетях IP в силу того, что эти
сети состоят из множества сегментов, построенных на базе различных технологий каналь-
ного уровня. В общем виде сквозное взаимодействие в сети начинается с уровня 3 эталон-
ной модели OS1 и, следовательно, только протокол сетевого уровня (каковым является
протокол IP в Internet) может обеспечить предоставление сквозных услуг QoS.
В Internet применяются различные технологии канального уровня и различные ли-
нии связи. С целью реализации сквозного качества обслуживания протокол IP, обес-
печивая сквозное взаимодействие узлов, должен установить соответствие между
функциями QoS сетевого уровня и механизмами QoS канального уровня (особенно в
коммутируемых сетях).
Магистрали некоторых поставщиков услуг построены на базе таких технологий
коммутируемых сетей, как ATM или Frame Relay. В этом случае для обеспечения
сквозного качества обслуживания сетевым инженерам придется организовать взаимо-
действие механизмов QoS канального уровня сетей ATM или Frame Relay и протокола
IP. Это позволит проводить корректную обработку запросов к обслуживанию QoS се-
тевого уровня облаком ATM или Frame Relay.
Коммутируемые локальные сети являются неотъемлемой частью сетей поставщи-
ков услуг Internet (Internet Service Provider — ISP), предоставляющих услуги по разме-
щению Web-сайтов и обеспечивающих функционирование корпоративных интрасе-
тей. Дифференцирование трафика в коммутируемых сетях предусматривается прото-
колами IEEE 802.1р и IEEE 802.1Q. Следовательно, для обеспечения в сети сквозного
качества обслуживания достаточно реализовать взаимодействие этих протоколов с
протоколом IP. Более подробно взаимодействие механизмов IP QoS с механизмами
QoS канального уровня рассматривается в главе 8, “Качество обслуживания на
уровне 2: межсетевой обмен с IP QoS”, далее в этой книге.
Технология MPLS помогает обеспечить качество обслуживания в сетях IP и пре-
доставляет расширенные возможности по управлению трафиком, которые способст-
вуют организации основанных на технологии MPLS виртуальных частных сетей
(VPNs). С целью обеспечения в IP-сети сквозного качества обслуживания следует
Глава 1. Введение в качество обслуживания в сетях IP
31
реализовать взаимодействие механизмов QoS сетевого уровня с механизмами QoS
MPLS-сетей и виртуальных частных MPLS-сетей. Более подробно эта тема рассмат-
ривается в главе 9, “Качество обслуживания в сетях MPLS”, далее в этой книге.
Цели
Эта книга призвана стать ценным источником информации для сетевых админист-
раторов, архитекторов и инженеров, желающих изучить и внедрить в своих сетях ус-
луги IP QoS. Функции качества обслуживания являются крайне необходимыми в со-
временных масштабируемых IP-сетях, обеспечивая предоставление гарантированных
и дифференцированных услуг Internet путем передачи контроля за ресурсами сети и
их использованием сетевому оператору.
Целью этой книги является рассмотрение архитектуры механизмов IP QoS и ассо-
циированных с ними функций, которые позволяют реализовать сквозное качество об-
служивания в корпоративных интрасетях, сетях поставщиков услуг и, в общем случае,
в глобальной сети Internet. Главный акцент при рассмотрении архитектуры механиз-
мов IP QoS делается на архитектуре дифференцированных услуг (diffserv). Кроме
этого, в данной книге уделяется внимание механизмам QoS, предусмотренным техно-
логиями ATM, Frame Relay, IEEE 802.Ip, IEEE 802.1Q, MPLS и MPLS VPN, а также
взаимодействию этих механизмов с механизмами IP QoS с целью обеспечения сквоз-
ного качества обслуживания. Еще одной не менее важной темой, затронутой в этой
книге, является тема управления трафиком в сетях MPLS.
В книге представлено наиболее полное описание IP QoS и всех связанных с каче-
ством обслуживания технологий. Рассмотрение каждой технологии заканчивается
практическим примером, наглядно иллюстрирующим ее применение. Читатели дан-
ной книги получат исчерпывающую информацию по следующим вопросам.
• Фундаментальные основы качества обслуживания в сетях IP и необходимость
внедрения механизмов QoS.
• Архитектура дифференцированных услуг (diffserv) и разрешающие функции QoS.
• Архитектура интегрированных услуг (Intserv) и разрешающие функции QoS.
• Механизмы QoS, предусмотренные технологиями ATM, Frame Relay и
IEEE 802. lp/802.IQ, — взаимодействие с механизмами IP QoS.
• Технологии MPLS и MPLS VPN — взаимодействие с механизмами IP QoS.
• Управление трафиком в сетях MPLS.
• Политики маршрутизации, общие функции IP QoS и другая информация, ка-
сающаяся качества обслуживания.
Механизмы QoS могут быть реализованы в любой IP-сети. Следовательно, матери-
ал, представленный в данной книге, относится ко всем сетям IP — корпоративным
интрасетям, сетям поставщиков услуг и, наконец, Internet.
Аудитория
Эта книга предназначена для профессионалов в сфере межсетевого взаимодейст-
вия, в чью компетенцию входит разработка и поддержка функций обслуживания тра-
фика для корпоративных интрасетей и сетей поставщиков услуг. Если вы являетесь
сетевым инженером, архитектором, планировщиком, проектировщиком или операто-
32
Часть I. Качество обслуживания в сетях IP
ром, обладающим лишь начальными знаниями технологий QoS, данная книга помо-
жет вам восполнить этот пробел и позволит развить практические навыки в планиро-
вании и внедрении в сети различных уровней качества обслуживания.
Помимо этого, в книге содержится материал, полезный для консультантов, сис-
темных инженеров и инженеров по сбыту, разрабатывающих IP-сети на заказ. Други-
ми словами, данная книга рассчитана на широкую аудиторию, поскольку планирова-
ние некоторых функций качества обслуживания является неотъемлемой частью про-
цесса проектирования практически любой 1Р-сети.
Широта охвата и ограничения изложенного
в книге материала
Несмотря на попытку представить полное и исчерпывающее описание механизмов ка-
чества обслуживания в сетях IP и функций QoS, специфических для оборудования компа-
нии Cisco, некоторые вопросы в этой книге не рассматривались. Так, не приводится ин-
формация об архитектуре различных платформ Cisco, которая может иметь отношение к
механизмам QoS. Кроме того, несмотря на попытку унифицированного подхода к изложе-
нию материала, авторам не удалось избежать описания некоторых особенностей, характер-
ных только для определенных устройств компании Cisco, что связано, в первую очередь, с
несогласованностью в реализации функций QoS на различных платформах.
Одной из целей, которые ставились при написании этой книги, было сохранение
целостности и актуальности представленного в книге материала. Тем не менее следует
отметить, что качество обслуживания в целом и механизмы QoS оборудования Cisco в
частности ждет много нововведений, каждое из которых способно со временем по-
влиять на изложенный в книге материал.
Практические примеры, приведенные в книге, предназначены для обсуждения не-
которых вопросов, связанных с внедрением и конфигурацией функций качества об-
служивания в IP-сети. Естественно, данная книга ни в коем случае не претендует
стать заменой документации компании Cisco. Документация Cisco по сей день являет-
ся наилучшим источником информации, касающейся предназначенных для настройки
механизмов QoS конфигурационных команд.
Следует отметить, что приведенные в книге практические примеры базируются на
огромном числе различных версий операционной системы IOS. В большинстве случа-
ев, если не оговорено противное, практические примеры базируются на версии опе-
рационной системы IOS 12.0(6)S или более поздней версии 12.OS. Практические при-
меры, в которых рассматривается технология MPLS, базируются на операционной
системе IOS версии 12.0(8)ST или более поздней версии 12.0ST.
Организация книги
Книга состоит из четырех частей. В части I, “Качество обслуживания в сетях IP”,
рассматривается архитектура качества обслуживания в сетях IP и разрешающие функции
QoS. Часть II, “Качество обслуживания канального уровня и сети MPLS — межсетевой
обмен с IP QoS”, посвящена механизмам QoS, предусмотренным технологиями ATM,
Frame Relay, Ethernet, MPLS и MPLS VPN, а также взаимодействию этих механизмов с
функциями IP QoS. В части III, “Управление трафиком”, рассматривается управление
трафиком в сетях MPLS. И, наконец, в части IV, “Приложения”, приводится описание
Глава 1. Введение в качество обслуживания в сетях IP 33
модульного интерфейса командной строки QoS и различных функций качества обслу-
живания; кроме того, здесь можно найти полезный справочный материал.
В большинстве глав имеются практические примеры, которые могут помочь разо-
браться в наиболее сложных проблемах внедрения функций качества обслуживания, а
также списки часто задаваемых вопросов.
Часть I
В части I данной книги рассматривается архитектура качества обслуживания в се-
тях 1Р и разрешающие функции QoS. В главе 2 приводится описание двух архитектур
IP QoS: архитектуры дифференцированных услуг (diffserv) и архитектуры интегриро-
ванных услуг (intserv). Как упоминалось ранее, главный акцент при изложении мате-
риала делается на рассмотрении архитектуры дифференцированных услуг.
В главах 3, 4, 5 и 6 рассматриваются различные разрешающие функции архитекту-
ры diffserv. К примеру, в главе 3 обсуждается функция QoS, ответственная за форми-
рование трафика на границе сети, что существенно облегчает задачу внедрения функ-
ций дифференцированного обслуживания. В главах 4 и 5 приводится описание меха-
низмов обслуживания очередей, позволяющих гарантировать минимальную полосу
пропускания для каждого потока трафика. В главе 6 рассматривается технология ак-
тивного управления очередью, которая характеризуется превентивным отбрасыванием
пакетов, сигнализирующих о перегрузке сети. И, наконец, в главе 7 речь идет о сиг-
нальном протоколе RSVP и двух типах интегрированных в него функций QoS.
Часть II
В этой части книги, включающей в себя главы 8 и 9, рассматриваются механизмы
QoS, предусмотренные технологиями ATM, Frame Relay, IEEE 802.Ip, IEEE 802.IQ,
MPLS и MPLS VPN, а также способ взаимодействия этих механизмов с механизмами
IP QoS с целью обеспечения сквозного качества обслуживания.
Часть III
Часть III включает в себя единственную главу 10, в которой рассматривается необ-
ходимость проведения управления трафиком и обсуждается управление трафиком в
сетях MPLS.
Часть IV
В данной части книги содержится весьма полезная информация, имеющая непо-
средственное отношение к теме качества обслуживания в сетях IP.
Приложение А, “Модульный интерфейс командной строки Cisco QoS”, знакомит
читателя с новым пользовательским интерфейсом, позволяющим проводить гибкую
модульную конфигурацию служб QoS.
В приложении Б, “Механизмы коммутации пакетов”, обсуждаются различные ме-
ханизмы коммутации пакетов, реализованные на платформах Cisco. Путем сравни-
тельного анализа механизмов коммутации пакетов демонстрируются преимущества
метода скоростной коммутации пакетов Cisco (CEF), являющегося необходимым ус-
ловием для реализации некоторых функций QoS.
В приложении В, “Политики маршрутизации”, речь идет о маршрутизации QoS,
маршрутизации на основе политики, а также распространении политик QoS с помо-
34
Часть I. Качество обслуживания в сетях IP
шью протокола пограничного шлюза (QoS Policy Propagation using Border Gateway
Protocol — QPPB).
В приложении Г, “Транспортный протокол реального времени (RTP)”, обсуждает-
ся транспортный протокол, использующийся для пакетной передачи голосового тра-
фика и трафика видеоизображений в масштабе реального времени.
В приложении Д, “Общие функции линейной эфективности протокола IP”, пред-
ставлен материал о некоторых функциях протокола IP, позволяющих увеличить дос-
тупную полосу пропускания.
В приложении Е, “Фрагментация и чередование пакетов на канальном уровне”, обсуж-
даются функциональные возможности многоканального протокола двухточечной связи
(Multilink Point-to-Point protocol), касающиеся фрагментации и чередования пакетов.
В приложении Ж, “Значения поля IP-приоритета и поля DSCP”, приводятся зата-
булированные значения поля IP-приоритета и поля кода DSCP, а также иллюстриру-
ется соотношение между данными характеристиками трафика.
Глава 1. Введение в качество обслуживания в сетях IP
35
В этой главе...
Архитектура интегрированных услуг (intserv) 37
Архитектура дифференцированных услуг (diffserv) 38
Глава
2
Архитектура
дифференцированных услуг
Цель качества обслуживания в сетях IP (IP Quality of Service — IP QoS) — предос-
ту давление гарантированных и дифференцированных услуг в масштабах Internet или
J любой другой IP-сети. Дифференциация услуг обусловливает наличие нескольких
уровней качества обслуживания, каждому из которых соответствует собственная архи-
тектурная модель обеспечения функций QoS.
? ’ Главный акцент при изложении материала данной главы делается на рассмотрении
архитектуры дифференцированных услуг (Differentiated Services — diffserv), использую-
щейся для обеспечения функций QoS в масштабах Internet. Кроме этого, здесь обсужда-
ется и другой подход к предоставлению, функций QoS — архитектура интегрированных
туслуг (Integrated Services — intserv). Более подробно архитектура интегрированных услуг
рассматривается в главе 7, “Интегрированные услуги: RSVP”, далее в этой книге. В дан-
ной главе будет описана также операционная модель QoS сетевого узла.
Архитектура интегрированных услуг (intserv)
В Л994 году проблемная группа проектирования Internet (Internet Engineering Task
Force — IETF) сформировала рабочую группу по созданию интегрированных услуг (intserv
А Working Group), главной задачей которой являлось расширение базовой модели услуг In-
ternet с целью обеспечения улучшенной поддержки разнообразных приложений, ориенти-
рованных на передачу голосового трафика и трафика видеоизображений. Созданная рабо-
чая группа должна была четко определить новую усовершенствованную модель услуг Inter-
net, разработать средства, позволяющие приложениям выражать сквозные требования к
ресурсам, и создать механизмы, которые бы обеспечили надлежащую интерпретацию этих
требований маршрутизаторами и различными технологиями, использующимися в подсе-
тях. Основная идея при этом заключалась в отдельной обработке потоков трафика, запро-
сивших определенный уровень качества обслуживания.
С этой целью были разработаны две услуги — гарантированного обслуживания1 и
регулируемой нагрузки1 2. Гарантированное обслуживание (guaranteed service) предполага-
1 Specification of Guaranteed Quality of Service/Shenker S., Partridge C, Guerin R. — RFC 2212.
2 Specification of the Controlled-Load Network Element Service/Wroclawski J. — RFC 2211.
ет предоставление детерминированных гарантий задержки, в то время как служба ре-
гулируемой нагрузки (controlled load service) использует механизм, похожий на механизм
негарантированной доставки трафика в слегка загруженной сети. Более подробно ка-
ждая из этих услуг рассматривается в главе 7, “Интегрированные услуги: RSVP”, да-
лее в этой книге.
В качестве сигнального протокола, использующегося для передачи требований
сквозного обслуживания, был предложен протокол резервирования ресурсов (Resource
Reservation Protocol — RSVP)3.
Следует отметить, что модель intserv требует обеспечения гарантированного каче-
ства обслуживания для каждого отдельного потока трафика в масштабах Internet. Учи-
тывая тот факт, что на сегодня в каждый момент времени в Internet существуют тыся-
чи потоков трафика, объем информации, который должны поддерживать маршрутиза-
торы, может быть запредельно большим. К сожалению, это означает наличие
практически неизбежных проблем, связанных с масштабированием сети, поскольку
объем информации, который следует поддерживать маршрутизаторам, увеличивается
пропорционально росту числа потоков трафика.
В 1998 году организация IETF сформировала рабочую группу по созданию диффе-
ренцированных услуг (diffserv Working Group). Архитектурную модель diffserv можно
сравнить с мостом, соединяющим требования гарантированного качества обслужива-
ния модели intserv с механизмом негарантированной доставки трафика, использую-
щимся сегодня в Internet. Модель diffserv обеспечивает дифференцирование трафика
путем его разбивки на классы с различным приоритетом.
Архитектура дифференцированных
услуг (diffserv)
В соответствии с моделью diffserv4 обеспечение качества обслуживания в сети IP
предполагает наличие небольшого числа четко определенных “строительных” блоков,
на основе которых можно создать множество различных услуг. Главной задачей под-
хода diffserv является определение стандартизированного байта дифференцированной
услуги (DS) — байта типа обслуживания (Type of Service — ToS) из заголовка пакета
Internet Protocol (IP) Version 4 и байта класса трафика (Traffic Class) пакета IP Ver-
sion 6 — и его соответствующая маркировка, от которой зависит принятие специфиче-
ского решения о продвижении пакета данных на каждом переходе (per-hop behavior —
РНВ), т.е. в каждом промежуточном узле.
Архитектура дифференцированных услуг обеспечивает базовую основу5, которая мо-
жет быть использована поставщиками услуг для предоставления своим клиентам боль-
шого диапазона различных предложений в зависимости от предъявляемых требований к
качеству обслуживания. Клиент может выбрать требуемый уровень услуг путем установ-
ки соответствующего значения поля кода дифференцированной услуги (Differentiated
Services Code Point — DSCP) для каждого отдельного пакета. Код дифференцированной
услуги определяет цепочку решений о продвижении пакета в каждом промежуточном
узле сети поставщика услуг (РНВ-политика). Как правило, поставщик услуг обсуждает
3 The Use of RSVP with IETF Integrated Scrvices/Wroclawski J. — RFC 2210.
4 IETF Differentiated Services Working Group.
5 A Framework for Differentiated Services/Bernet Y. et al., Internet Draft.
38
Часть I. Качество обслуживания в сетях IP
вместе с заказчиком профиль, согласно которому каждому уровню обслуживания будет
соответствовать определенная интенсивность передачи трафика. Если же объем переда-
ваемого трафика превысит установленную квоту для данного уровня обслуживания, то
предоставление оговоренных услуг для “сверхплановых” пакетов не гарантируется.
Следует отметить, что архитектура дифференцированных услуг определяет всего
лишь базовые механизмы, на основе которых осуществляется обслуживание пакетов.
Используя эти механизмы в качестве строительных блоков, вы можете разработать целое
множество различных услуг. Напомним, что в данном случае услуга определяет весьма
значительные характеристики передачи пакетов, такие, как пропускная способность, за-
держка, дрожание, а также уровень потери пакетов в одном направлении при передаче
вдоль сетевого маршрута. К тому же вы можете охарактеризовать услугу в терминах от-
носительного приоритета при доступе к ресурсам сети. После определения услуги разра-
батываются соответствующие ей решения о продвижении пакета (РНВ-политика) для
каждого узла сети, поддерживающего данную услугу. РНВ-политике присваивается оп-
ределенный код DSCP. РНВ-политика — это наблюдаемая извне политика поведения
сетевого узла в отношении пакетов с определенным значением поля кода дифференци-
рованной услуги (DSCP). Все пакеты потока трафика со специфическим требованием к
обслуживанию несут в себе одно и то же значение поля DSCP.
Все узлы внутри diffserv-домена определяют РНВ-политику, которая должна быть
применена к пакету на основе хранящегося в нем значения поля кода дифференциро-
ванной услуги. Кроме того, пограничные узлы diffserv-домена выполняют очень важ-
ную функцию формирования поступающего в diffserv-домен трафика. Формирование
трафика включает в себя выполнение таких функций, как классификация пакетов и
ограничение трафика, и обычно выносится на входной интерфейс поступающих в
diffserv-домен пакетов. Формирование играет решающую роль в управлении посту-
пающим в diffserv-домен трафиком, поскольку в этом случае для каждого пакета сеть
может определить соответствующую ему РНВ-политику.
На рис. 2.1 схематически представлена архитектура дифференцированных услуг. Опи-
сание двух основных функциональных блоков этой архитектуры приведено в табл. 2.1.
установка значения поля DSCP;
ограничение трафика.
Рис. 2.1. Архитектура дифференцированных услуг
Глава 2. Архитектура дифференцированных услуг
39
i Таблица 2.1. Функциональные блоки архитектуры
j дифференцированных услуг
Функциональный блок Расположение Разрешающая функция Действие
Формирователи трафика Входной интерфейс по- граничного маршрутиза- тора diffserv-домена Классификация пакетов, выравнивание и ограни- чение трафика (более подробно см. в главе 3) Ограничение входящего трафика и установка зна- чения поля DSCP на осно- ве профиля трафика
Устройства, реализующие РНВ-политику Все маршрутизаторы diffserv-домена Распределение ресурсов (более подробно см. в главе 4 и главе 5) и по- литика отбрасывания па- кетов (более подробно см. в главе 6) РНВ-политика обработ- ки пакетов определяет- ся на основе характери- стик качества обслужи- вания, соответствующих заданному значению по- ля DSCP
Помимо описанных выше функциональных блоков, политика распределения ре-
сурсов играет важную роль в определении стратегии управления доступом, коэффици-
ента бронирования ресурсов и т.д.
Примечание
Для четкого разделения и обеспечения модульной конфигурации различных разре-
шающих функций QoS компания Cisco разработала модульный интерфейс командной
строки (Command-Line Interface— CLI) QoS (более подробно модульный интерфейс
командной строки QoS рассматривается в приложении А, “Модульный интерфейс ко-
мандной строки Cisco QoS”, далее в этой книге).
На рис. 2.2 изображена обобщенная операционная модель QoS.
Рис. 2.2. Обобщенная операционная модель QoS
Код дифференцированной услуги (DSCP)
В настоящее время рабочая группа IETF по созданию и внедрению дифференциро-
ванных услуг предпринимает попытки стандартизации поля DSCP, которая позволила
бы использовать 6 бит из байта ToS заголовка IP-пакета для установки кода диффе-
ренцированной услуги. При этом 2 младших бита из байта ToS не используются
(currently unused — CU). Фактически код дифференцированной услуги представляет
собой расширение 3-битового поля IP-приоритета. Так же, как и IP-приоритет, код
40
Часть I. Качество обслуживания в сетях IP
дифференцированной услуги позволяет определять способ обработки отмеченных
соответствующим образом пакетов данных. На рис. 2.3 представлена структура байта
ToS6. После стандартизации поля кода дифференцированной услуги байт ToS будет
переименован в байт DS. На рис. 2.4 представлена структура байта DS.
| Р2 | Р1 | РО | ТЗ | Т2 | Т1 | ТО J CU~|
IP-приоритет: 3 бит (Р2-Р0)
Тип обслуживания (ToS): 4 бит (ТЗ-ТО)
Не используется (CU): 1 бит
Рис. 2.3. Структура байта ToS в соответствии
с документом RFC 1349
[ DS5 | DS4 | DS3 ]"DS2 | DS1 | DSO | CU | CU~|
Код дифференцированной услуги (DSCP): 6 бит (DS5-DS0)
Не используется (CU): 2 бит
Рис. 2.4. Структура байта DS
На сегодняшний день рабочая группа IETF по созданию и внедрению дифферен-
цированных услуг определяет коды DSCP следующим образом7.
• Стандартный код DCSP. Определен как ООО 000.
• Селектор класса. Эти коды DCSP обладают обратной совместимостью с кодами
IP-приоритета и представлены в табл. 2.2.
Таблица 2.2. Селекторы класса
Селектор класса DSCP
Приоритет 1 001 000
Приоритет 2 010 000
Приоритет 3 011 000
Приоритет 4 100 000
Приоритет 5 101 000
Приоритете 110 000
Приоритет 7 111 000
• РНВ-политика немедленной передачи (Expedited Forwarding — EF). Этот код
DSCP соответствует наиболее высококлассному уровню обслуживания, предос-
тавляемому за дополнительную стоимость. Рекомендуемое значение — 101 НО.
• РНВ-политика гараитироваииой передачи (Assured Forwarding — AF). Эти коды
DSCP определяют четыре уровня обслуживания, каждый из которых, в свою
очередь, может быть охарактеризован тремя уровнями приоритета отбрасыва-
6 Type of Service in the Internet Protocol Suite/Almquist P. — RFC 1349.
7 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers/Nichols K. ct
al. - RFC 2474.
Глава 2. Архитектура дифференцированных услуг
41
ния пакетов данных. Как результат РНВ-политике гарантированной передачи
соответствуют 12 кодов DSCP, представленных в табл. 2.3.
Г Таблица 2.3. РНВ-прлитика гарантированной передачи
Приоритет отбрасывания пакета Класс 1 Класс 2 Класс 3 Класс 4
Низкий 001010 010010 011010 100010
Средний 001100 010100 011100 100100
Высокий 001110 010110 011110 100110
Формирователи трафика, расположенные на границе сети
Формирователи трафика — это различные функции качества обслуживания, кото-
рые должны быть реализованы в пограничных устройствах сети. Граничные функции
классифицируют или маркируют трафик путем установки соответствующего значения
поля DSCP, а также проводят мониторинг входящего в сеть трафика с целью провер-
ки его соответствия установленному профилю.
Код дифференцированной услуги представляет собой поле, на основании значения
которого определяется способ обработки пакета в diffserv-домене. В качестве обраба-
тывающей трафик функции может выступать функция классификации пакетов, функ-
ция маркировки DSCP-поля, или же функция дозирования трафика, наделенная либо
полномочиями выравнивания трафика, либо полномочиями отбрасывания пакетов.
Все названные выше функции рассматриваются в следующих разделах данной главы;
тем не менее если вам необходимо получить более подробную информацию, обрати-
тесь к главе 3, “Формирование трафика на границе сети: классификация пакетов,
маркировка пакетов и управление интенсивностью трафика”.
Классификатор пакетов
Классификатор пакетов выбирает пакет из потока трафика на основании анализа
части содержимого заголовка пакета. Наиболее распространенный способ классифи-
кации пакетов заключается в анализе поля DSCP, однако теоретически вы можете
классифицировать пакет на основании значения других полей его заголовка. Функция
классификации пакета определяет соответствующий этому пакету класс трафика.
Маркер
Эта функция предназначена для записи/перезаписи поля DSCP в зависимости от
класса трафика, к которому относится данный пакет.
Дозирование трафика
Функция дозирования проверяет трафик на соответствие заданному профилю на
основании дескриптора трафика, такого, как корзина маркеров. Результаты проверки
передаются функции маркировки трафика, а также либо функции выравнивания тра-
фика, либо функции отбрасывания пакетов для принятия соответствующего решения
в отношении “плановых” и “внеплановых” пакетов.
42
Часть I. Качество обслуживания в сетях IP
Функция выравнивания трафика
Функция выравнивания трафика (traffic shaping) осуществляет задержку пакетов пу-
тем их буферизации с целью удовлетворения параметров заданного профиля.
Функция отбрасывания пакетов
Функция отбрасывания пакетов осуществляет отбрасывание всех пакетов, не удов-
летворяющих параметрам заданного профиля трафика. Это действие часто называют
также ограничением трафика (traffic policing).
РНВ-политика
Сетевые узлы с поддержкой дифференцированного обслуживания используют
поле DSCP в заголовке IP-пакета для определения соответствующей этому пакету
РНВ-политики.
РНВ-политика может быть определена в терминах приоритета в предоставлении
ресурсов по отношению к другим РНВ-политикам или же с помощью таких измеряе-
мых характеристик трафика, как задержка пакетов, уровень потери пакетов или дро-
жание трафика. В некоторой степени РНВ-политику можно рассматривать как свое-
образный “черный ящик”, поскольку она определяет некоторое наблюдаемое извне
поведение сетевого узла в отношении поступающих пакетов, не навязывания при
этом конкретную реализацию.
В качестве стандартной РНВ-политики в diffserv-сети можно рассматривать нега-
рантированную доставку трафика. В соответствии с архитектурой дифференцирован-
ного обслуживания каждой РНВ-политике рекомендуется назначить определенный
код DSCP, однако поставщик услуг волен выбрать отличные от рекомендованных
значения поля DSCP для своей собственной сети. Рекомендованное значение поля
DSCP для политики негарантированной доставки пакетов равняется 000000.
РНВ-политика, соответствующая определенному классу трафика, зависит от це-
лого ряда факторов.
• Интенсивность входного потока или нагрузки для заданного класса трафика. Этот
параметр контролируется пограничным формирователем трафика.
• Распределение ресурсов для заданного класса трафика. Этот параметр контроли-
руется функциями распределения ресурсов, реализованными в узлах diffserv-
домена. Более подробно распределение ресурсов в узлах diffserv-сети рассматри-
вается в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”, и главе 5,
“РНВ-политика: распределение ресурсов (часть 2)”, далее в этой книге.
• Уровень потери трафика. Этот параметр зависит от политики отбрасывания па-
кетов, проводимой в узлах diffserv-домена. Более подробно данная функция
рассматривается в главе 6, “РНВ-политика: предотвращение перегрузки и
политика отбрасывания пакетов”.
Существуют две стандартные РНВ-политики — РНВ-политика немедленной пере-
дачи (EF РНВ) и РНВ-политика гарантированной доставки (AF PH В). Их рассмотре-
нию посвящены два следующих раздела этой главы.
Глава 2. Архитектура дифференцированных услуг
43
РНВ-политика немедленной передачи пакетов (EF РНВ)
РНВ-политика немедленной передачи пакетов (Expedited Forwarding РНВ — EF
РНВ) используется для обеспечения сквозного обслуживания пакетов в узлах diffserv-
домена, характерными чертами которого являются низкий уровень потери пакетов,
малая задержка, незначительное дрожание трафика, а также гарантированная полоса
пропускания8. Политика EF РНВ применяется для обслуживания трафика таких при-
ложений, как передача голоса по сетям IP (Voice over IP — VoIP), приложений видео-
конференций, а также для обеспечения таких услуг, как передача информации по
виртуальным арендуемым каналам, поскольку эта услуга представляет собой двухто-
чечное соединение конечных узлов diffserv-домена. Подобный тип обслуживания дос-
таточно часто называют также услугами высокого класса (premium service).
Главными факторами, ведущими к большой задержке пакетов и дрожанию трафи-
ка, являются задержки, связанные с возникновением больших накопленных очередей.
Подобные очереди характерны для перегруженных участков сети. Причиной перегруз-
ки сети является преобладание интенсивности входного потока трафика над интен-
сивностью его выходного потока. Один из способов избежать задержки пакетов, свя-
занной с возникновением больших очередей, — ограничение максимальной интен-
сивности входного потока трафика минимальной интенсивностью его выходного
потока. РНВ-политика немедленной передачи пакетов предусматривает установку
значения интенсивности выходного потока трафика, в то время как интенсивность
входного потока контролируется формирователями трафика, реализованными в по-
граничных устройствах сети.
Поскольку в соответствии с политикой EF РНВ входящие пакеты не должны образо-
вывать очередь (допускается очередь очень малого размера), интенсивность исходящего
потока трафика должна быть равной интенсивности входящего потока или превышать
ее. Следует отметить, что интенсивность исходящего потока трафика (полоса пропуска-
ния) не должна зависеть от других потоков трафика. Как правило, интенсивность вхо-
дящего и исходящего потоков трафика измеряется с интервалами, равными времени,
которое требуется для передачи MTU-пакета (пакета максимального размера, который
может быть передан через интерфейс маршрутизатора) по данной линии связи.
Маршрутизатор может выделить ресурсы, достаточные для обеспечения определен-
ной интенсивности исходящего трафика для заданного интерфейса, путем использова-
ния различных функциональных реализаций политики EF РНВ. Когда речь идет о пе-
редаче трафика через перегруженный сегмент сети (а это предполагает наличие больших
накопленных очередей), данная функциональная возможность может быть реализована
за счет применения различных механизмов обслуживания очередей, таких, как взве-
шенный механизм равномерного обслуживания очередей на основе класса трафика
(Class-Based Weighted Fair Queuing — CBWFQ), взвешенный механизм кругового обслу-
живания (Weighted Round Robin — WRR) и механизм кругового обслуживания с дефи-
цитом (Deficit Round Robin — DRR). В этом случае EF-трафику назначается вес, кото-
рый соответствует полосе пропускания, намного превышающей интенсивность входя-
щего EF-трафика. В дальнейшем вы можете модифицировать эти механизмы, добавив
приоритетную очередь, предназначенную специально для обслуживания EF-трафика.
Более подробно механизмы обслуживания очередей рассматриваются в главе 5, “РНВ-
политика: распределение ресурсов (часть 2)”, далее в этой книге.
s Expedited Forwarding (EF) РНВ/Jacobson V., Nichols К., Poduri К. — RFC 2598.
44
Часть I. Качество обслуживания в сетях IP
Если обработка EF-трафика реализуется за счет организации приоритетной очере-
ди, следует убедиться в том, что оставшиеся очереди трафика не испытывают недос-
татка в поступающих пакетах в рамках определенного предела. В целях предотвраще-
ния этой проблемы можно определить максимальную интенсивность трафика, обра-
батываемого с помощью приоритетной очереди. Если интенсивность поступающего
EF-трафика превысит заданный предел, весь избыточный трафик будет отброшен.
Пограничные формирователи поступающего в diffserv-домен трафика должны быть
сконфигурированы таким образом, чтобы интенсивность EF-трафика никогда не пре-
вышала заданного предела на любом участке сети.
Рекомендуемое значение поля DSCP для EF-трафика равняется 101110.
РНВ-политика гарантированной доставки пакетов (AF РНВ)
РНВ-политика гарантированной доставки пакетов (Assured Forwarding РНВ — AF
РНВ)9 представляет собой средство, с помощью которого поставщик услуг может
обеспечить несколько различных уровней надежности доставки IP-пакетов, получен-
ных из diffserv-домена клиента. Политика AF РНВ является приемлемой для боль-
шинства ТСР-приложений.
РНВ-политика гарантированной доставки пакетов подразумевает наличие различ-
ных уровней обслуживания для каждого из четырех классов AF-трафика. Каждому
классу AF-трафика соответствует своя собственная очередь пакетов, что позволяет
проводить эффективное управление полосой пропускания. Каждый класс AF-трафика
характеризуется тремя уровнями приоритета отбрасывания пакетов (низкий, средний
и высокий), что позволяет реализовать механизм управления очередью по типу меха-
низма произвольного раннего обнаружения (Random Early Detection — RED).
Политика распределения ресурсов
В последнем разделе этой главы мы обсудим способы реализации РНВ-политик в
diffserv-сети. Каким образом происходит формирование трафика на границе сети и
распределение ресурсов в ее узлах для достижения определенной РНВ-политики? Су-
ществует три решения: инициализация сети, сигнализация о качестве обслуживания и
диспетчер политик.
Инициализация сети
Один из способов распределения ресурсов заключается в инициализации ресурсов
сети с использованием эвристических методов или техники систематического модели-
рования. Следует отметить, что этот метод может быть применен только в сетях не-
большого размера, для которых политики QoS и профили трафика остаются неизмен-
ными на протяжении достаточно долгого промежутка времени.
Сигнализация о качестве обслуживания
В соответствии с этим методом реализации РНВ-политики приложения извещают
сеть о требованиях к качеству обслуживания с помощью сигнального протокола
RSVP. С точки зрения протокола RSVP diffserv-домен рассматривается как еще одно
звено сети, требующее управление доступом. С помощью протокола RSVP можно ус-
9 Assured Forwarding (AF) P/IB/Heinanen J., Finland T, Baker F. (Cisco Systems), Weiss W.
(Lucent Technologies), Wroclawski J. (MIT LCS) — RFC 2591.
Глава 2. Архитектура дифференцированных услуг
45
тановить соответствие между запросами к качеству обслуживания приложений и клас-
сами услуг diffserv. К примеру, гарантированному обслуживанию RSVP может быть
поставлена в соответствие diffserv-услуга немедленной передачи пакетов.
Сигнализация о качестве обслуживания является чрезвычайно масштабируемым
решением в крупных сетях, поскольку протокол RSVP выполняется только в погра-
ничных узлах diffserv-домена, как показано на рис. 2.5.
Дифференцированные услуги
Сквозная передача сигнальной информации протокола RSVP
через сеть с дифференцированным обслуживанием
Рис. 2.5. Передача сигнальной информации протокола RSVP через сеть с дифференцирован-
ным обслуживанием
Установка соответствия между резервированием ресурсов протокола RSVP и diff-
serv-классами проводится на границе diffserv-сети. Учитывая широкую поддержку
протокола RSVP (к примеру, RSVP поддерживается операционной системой Microsoft
Windows 2000), уведомленные о существующей политике пограничные приложения
могут использовать его для сообщения требований к качеству обслуживания, не об-
ращая при этом внимания на возможное увеличение масштабов сети. Это решение
хорошо подходит для реализации в крупных корпоративных сетях.
Протокол RSVP обладает выдающейся способностью к масштабированию — он
может поддерживать несколько тысяч выполняющихся параллельно сеансов передачи
информации. К тому же сейчас ведется работа по реализации протокола RSVP с под-
держкой агрегирования. Несколько резервирований ресурсов протокола RSVP могут
быть объединены в одно агрегированное резервирование в случае применения прото-
кола RSVP в масштабе крупной базовой сети, требующей управления доступом с уче-
том топологии. Агрегированное резервирование ресурсов протокола RSVP представля-
ет собой мощное, медленно регулируемое состояние резервирования, которое позво-
ляет снизить объем сигнальной информации в базовой сети. Аналогично обычному
резервированию ресурсов протокола RSVP, вы можете установить соответствие между
агрегированным резервированием и diffserv-классом.
Диспетчер политик QoS
Определение политики обусловливает выбор стратегии QoS, применяемой к пото-
ку трафика. Политика определяет трафик, необходимый для функционирования кри-
тически важных приложений, и соответствующий ему уровень услуг QoS. На самом
деле политика представляет собой всего лишь определенную конфигурацию, которая
должна быть реализована во всех узлах QoS-сети. Каким же образом узел QoS-сети
узнает о назначенной ему политике?
46
Часть I. Качество обслуживания в сетях IP
Если взять наиболее простой случай, сетевой инженер может собственноручно на-
строить QoS-политики в сети путем внесения определенных изменений в конфигура-
цию маршрутизаторов. Однако же в крупномасштабной сети этот процесс становится
чрезвычайно утомительным и практически неуправляемым. Для того чтобы крупно-
масштабная сеть могла обеспечивать сквозное качество обслуживания, политики, реа-
лизованные во всех ее узлах, должны быть непротиворечивы. Следовательно, для бы-
строй и безболезненной реализации QoS-политик во всех узлах сети требуется нали-
чие централизованного диспетчера политик. Подобный диспетчер политик и будет
ответствен за распространение единой QoS-политики на все устройства сети.
Обшая открытая служба политик (Common Open Policy Service — COPS) — это
протокол распространения политик, разработанный группой IETF. В терминологии
протокола COPS централизованный сервер политик называется точкой определения
политики (Policy Decision Point — PDP). Узел сети, которому навязывается политика,
получил название точки применения политики (Policy Enforcement Point — PEP).
PDP-сервер использует протокол COPS для загрузки политик в РЕР-узлы сети. РЕР-
устройство может сгенерировать сообщение, в котором оно информирует PDP-сервер
о невозможности реализации предложенной PDP-сервером политики.
IP-приоритет в сравнении с кодом DSCP
Как обсуждалось ранее в этой главе, архитектура diffserv предполагает наличие фор-
мирователей трафика на границе сети, а также поддержки функции распредепения
ресурсов и функции отбрасывания пакетов в ядре сети в целях обеспечения РНВ-
политики немедленной передачи пакетов (EF РНВ) и РНВ-политики гарантированной
доставки пакетов (AF РНВ). Поскольку вплоть до настоящего времени четкого опре-
деления поля DSCP попросту не существовало, поддержка архитектуры diffserv бази-
ровалась на использовании 3-битового поля IP-приоритета (исторически сложилось
так, что именно поле IP-приоритета использовалось для обозначения качества обслу-
живания или приоритета IP-пакета). Операционная система Cisco IOS полностью под-
держивает архитектуру diffserv и предоставляет все пограничные функции и функции
ядра QoS, основываясь при этом на значении 3-битового поля IP-приоритета.
3-битовое поле IP-приоритета и 6-битовое поле DSCP используются дпя выполнения
одних и тех же функций в diffserv-сети: маркировка пакетов на границе сети и реали-
зация определенной политики обработки пакетов (например, их отбрасывание или по-
становка в очередь) внутри сети. Следует отметить, что поле DSCP обратно совмес-
тимо с полем IP-приоритета. Следовательно, обеспечение поддержки поля DSCP не
требует внесения каких-либо изменений в существующие функциональные возможно-
сти и архитектуру. Вскоре все функции IP QoS будут поддерживать поле DSCP наряду
с полем IP-приоритета.
Компания Cisco разработала модульный интерфейс командной строки QoS для обес-
печения четкого разделения и модульной конфигурации различных разрешающих
функций качества обслуживания. Более подробно модульный интерфейс командной
строки QoS рассматривается в приложении А, “Модульный интерфейс командной
строки Cisco QoS”, далее в этой главе. Поддержка поля DSCP со стороны различных
функций QoS является частью модульной архитектуры QoS.
Глава 2. Архитектура дифференцированных услуг
47
Резюме
В этой главе были рассмотрены две различные архитектуры Internet QoS — архи-
тектура интегрированных услуг (intserv) и архитектура дифференцированных услуг
(diffserv). Архитектура intserv была разработана с целью предоставления приложения-
ми возможности запрашивать сквозные требования к ресурсам. В качестве сигналь-
ного протокола был предложен протокол RSVP. К сожалению, архитектуре inserv при-
сущи проблемы масштабирования, которые не позволяют эффективно использовать
ее в крупных сетях и, в особенности, в Internet, характеризующейся наличием десят-
ков тысяч потоков трафика. Более подробно архитектура intserv рассматривается в
главе 7, “Интегрированные услуги: RSVP”, далее в этой книге.
Главный акцент при изложении материала этой главы был сделан на рассмотрении
архитектуры diffserv. Архитектура diffserv была разработана с целью обеспечения под-
держки легкомасштабируемых дифференцированных услуг в пределах Internet. Для
маркировки IP-пакета в соответствии с требуемым уровнем QoS используется недавно
стандартизированное поле DSCP, которое определяет РНВ-политику, применяемую
при транспортировке данного пакета в пределах diffserv-домена. Формирование и
маркировка трафика осуществляется на границе diffserv-сети. РНВ-политика — это
наблюдаемая извне политика поведения сетевого узла в отношении пакетов с опреде-
ленным значением поля кода дифференцированной услуги (DSCP). РНВ-политика
может быть определена в терминах приоритета в предоставлении ресурсов по отноше-
нию к другим РНВ-политикам или же с помощью таких измеряемых характеристик
трафика, как задержка пакетов, уровень потери пакетов или дрожание трафика. Су-
ществуют две стандартные РНВ-политики — РНВ-политика немедленной передачи
(EF РНВ) и РНВ-политика гарантированной доставки (AF РНВ). Политика EF РНВ
применяется для обслуживания трафика таких функционирующих в масштабе реаль-
ного времени приложений, как передача голоса по сетям IP (Voice over IP — VoIP).
Политика AF РНВ представляет собой средство, с помощью которого поставщик ус-
луг может обеспечить несколько различных уровней надежности доставки IP-пакетов
в зависимости от значения поля DSCP.
Общая открытая служба политик (Common Open Policy Service — COPS) — это но-
вый протокол распространения в сети политик QoS, разработанный группой IETF.
48
Часть I. Качество обслуживания в сетях IP
В этой главе..
Классификация пакетов (52
Маркировка пакетов , ; ..... . ' 53
Необходимость управления интенсивностью трафика 61
Ограничение трафика ' ? 62
Выравнивание трафика 1 . 74
Глава
3
Формирование трафика
на границе сети:
классификация пакетов,
маркировка пакетов
и управление интенсивностью
трафика
Функции формирования трафика, реализованные в пограничных устройствах сети,
‘ являются жизненно важными для обеспечения дифференцированного обслуживания в
пределах diffserv-домена. К этим функциям относятся функции классификации тра-
фика, маркировки пакетов и управления интенсивностью трафика.
Как правило, передаваемые по сети пакеты различают по их принадлежности к
тому или иному потоку трафика, определяемому пятью полями заголовка IP-пакета:
адрес источника IP-пакета, адрес назначения IP-пакета, поле протокола IP, порт ис-
точника и порт назначения. Поток информации состоит из пакетов, сгенерированных
приложением, выполняющемся на компьютере-источнике, и предназначающихся для
передачи приложению, выполняющемуся на компьютере-приемнике. Пакеты, при-
надлежащие одному потоку, имеют одинаковые значения всех пяти полей в заголовке
IP-пакета. Поскольку число потоков трафика может оказаться достаточно большим,
функции качества обслуживания, применяемые к отдельному потоку трафика, не об-
ладают масштабируемостью. Маршрутизаторы, расположенные на границе сети, про-
водят классификацию пакетов с целью отнесения их к тому или иному классу трафи-
ка на основании значения одного или нескольких полей в заголовке ТСР/1Р-пакета.
Функция маркировки используется для “раскраски” классифицированного трафика
путем установки соответствующего значения поля IP-приоритета или поля кода диф-
ференцированной услуги (Differentiated Services Code Point — DSCP). Попав в ядро
сети, “раскрашенные” пакеты будут обработаны в соответствии с РНВ-политикой,
определенной на основании поля IP-приоритета или поля DSCP.
Другим не менее важным формирователем трафика, расположенным на границе
сети, является функция управления интенсивностью трафика. Управление интенсив-
ностью трафика предполагает соизмерение параметров поступающего в сеть трафика
клиента с его профилем с помощью ограничивающей функции. И наоборот, компа-
ния, подключенная к сети поставщика услуг, может проверять параметры своего ис-
ходящего трафика с целью поддержания его интенсивности на уровне, удовлетворяю-
щем всем ограничивающим функциям поставщика услуг.
Наличие формирователей трафика, расположенных на границе сети, является необхо-
димым условием для обеспечения сетью функций дифференцированного обслуживания.
Классификация пакетов
Классификация пакетов (packet classification) представляет собой средство, позво-
ляющее отнести пакет к тому или иному классу трафика в зависимости от значения
одного или нескольких полей пакета. Распознающая функция может быть как очень
простой, так и весьма сложной. Ниже перечислено несколько различных способов
классификации пакетов.
• Распознающая функция IP-потока зависит от пяти параметров: адреса источ-
ника IP-пакета, адреса назначения IP-пакета, поля протокола IP, порта источ-
ника и порта назначения.
• Распознающая функция зависит от значения поля IP-приоритета или поля кода
дифференцированной услуги (DSCP).
• Распознающая функция зависит от других параметров заголовка TCP/IP-
пакета, таких, как длина пакета.
• Распознающая функция зависит от МАС-адреса источника и МАС-адреса на-
значения пакета.
• Распознающая функция зависит от используемых приложением номеров пор-
тов, адресов URL (Universal Resource Locator — универсальный указатель ин-
формационного ресурса) и т.д. Данная функциональная возможность реализо-
вана в продуктах Cisco в виде метода распознавания приложений на основе се-
тевых параметров (Network Based Application Recognition — NBAR).
Чтобы задать критерий совпадения пакетов на основании различных параметров
потока, можно использовать списки доступа. Кроме того, списки доступа могут быть
использованы и для идентификации пакетов на основе значения поля IP-приоритета
или поля DSCP. Распознавание приложений на основе сетевых параметров (NBAR)
позволяет маршрутизаторам идентифицировать трафик отдельных приложений, по-
зволяя таким образом проводить классификацию пакетов на основе сгенерировавших
их программных средств.
Классификация пакетов может быть основана также и на внутренних параметрах
маршрутизатора. Примером подобной классификации является идентификация паке-
тов на основании входного интерфейса маршрутизатора или идентификация пакетов
на основании значения поля QoS-группы, относящегося к внутренней по отношению
к маршрутизатору структуре данных пакета. Перечисленные выше механизмы клас-
сификации пакетов поддерживаются всеми функциями качества обслуживания как
часть модульного интерфейса командной строки QoS. Более подробно модульный ин-
52
Часть I. Качество обслуживания в сетях IP
терфейс командной строки QoS (Modular QoS CLI) рассматривается в приложении А,
“Модульный интерфейс командной строки Cisco QoS”, далее в этой книге.
Классификацию пакетов часто называют также маркировкой (packet marking) или
раскраской пакетов (packet coloring). Все пакеты, принадлежащие определенному клас-
су трафика, “окрашиваются” в соответствующий цвет.
Маркировка пакетов
Маркировка пакетов используется для идентификации соответствующего им клас-
са трафика. Пакеты могут быть маркированы путем установки значения поля IP-
приоритета или поля кода дифференцированной услуги (DSCP), расположенных в
заголовке IP-пакета, а также путем установки значения поля QoS-группы, относяще-
гося к внутренней по отношению к маршрутизатору структуре данных пакета.
1Р-приоритет
Поле IP-приоритета, расположенное в заголовке IP-пакета, указывает на относи-
тельный приоритет при обработке соответствующего пакета данных. Поле IP-
приоритета состоит из трех битов байта типа обслуживания (Type of Service — ToS).
Помимо битов IP-приоритета, байт ToS содержит биты типа обслуживания (ToS-
биты). ToS-биты были предназначены для хранения значений, определяющих способ
обработки соответствующего пакета данных в сети, однако на практике они не полу-
чили широкого распространения. Схема байта ToS1, включающая биты IP-приоритета
и ToS-биты, представлена на рис. 2.3 в главе 2, “Архитектура дифференцированных
услуг”, ранее в этой книге. В табл. 3.1 перечислены все допустимые комбинации би-
тов IP-приоритета вместе с их значениями и названиями* 2.
I Таблица 3.1. Значения и названия битов IP-приоритета , I
L-_________________— ______________________________-______ .---------L..~.I
Значение IP-приоритета Биты IP-приоритета Название IP-приоритета
0 ООО Стандартный
1 001 Приоритетный
2 010 Немедленный
3 011 Срочный
4 100 Сверхсрочный
5 101 Критический
6 110 Межсетевое управление
7 111 Сетевое управление
Примечание
По умолчанию всему управляющему трафику, ответственному за обеспечение мар-
шрутизации, ставится в соответствие IP-приоритет 6. Помимо этого, для администра-
тивного трафика сети зарезервирован также и IP-приоритет 7. Следовательно, IP-
приоритет 6 и 7 не рекомендуется назначать трафику пользовательских приложений.
7 Type of Service in the Internet Protocol Suite/Almquist P. — RFC 1349.
2 Internet Protocol Specification/Postel J. — RFC 791.
Глава 3. Формирование трафика на границе сети: классификация... 53
“Раскраска” пакетов путем установки значения поля IP-приоритета может быть
осуществлена как сгенерировавшим эти пакеты приложением, так и узлом сети. Сред-
ства качества обслуживания Cisco, поддерживающие функцию маркировки пакетов,
включают в себя механизм согласования скорости доступа (Committed Access Rate —
CAR), маршрутизацию на основе политики (Policy-Based Routing — PBR) и распро-
странение политик QoS с помощью протокола пограничного шлюза (QoS Policy
Propagation using Border Gateway Protocol — QPPB). Более подробно установка значе-
ния поля IP-приоритета с использованием для этого различных функций качества об-
служивания рассматривается в практическом примере 3.1 далее в этой главе. О меха-
низме согласования скорости доступа (CAR) речь идет в разделе “Ограничение
трафика” далее в этой главе. Маршрутизация на основе политики (PBR) и распро-
странение политик QoS с помощью протокола пограничного шлюза (QPPB) рассмат-
риваются в приложении В, “Политики маршрутизации”, далее в этой книге.
Примечание
Несмотря на возможность маркировки пакетов путем установки значения попя IP-
приоритета, главным функциональным предназначением маршрутизации на основе поли-
тики (PBR) является маршрутизация пакетов на основе заданных правил. Именно поэтому
использование PBR-маршрутизации для “раскраски" пакетов рекомендуется только в слу-
чае отсутствия поддержки механизмов CAR ипи QPPB, а также при необходимости уста-
новки попя IP-приоритета при осуществлении маршрутизации на основе заданных правил.
DSCP
Поле кода дифференцированной услуги (DSCP) используется для идентификации
РНВ-политики обработки пакетов. Поле DSCP состоит из шести битов заголовка IP-
пакета и в настоящий момент находится в процессе стандартизации по инициативе
рабочей группы IETF, занимающейся созданием дифференцированных услуг (IETF
Differentiated Services Working Group). После стандартизации поля кода дифференци-
рованной услуги байт ToS будет переименован в байт DSCP. Схема байта DSCP пред-
ставлена на рис. 2.4 в главе 2, “Архитектура дифференцированных услуг”. Там же
можно найти определения поля DSCP3 и рекомендуемые значения кода дифференци-
рованной услуги для различных РНВ-политик.
Аналогично IP-приоритету, поле DSCP является частью заголовка IP-пакета. На самом
деле поле DSCP представляет собой расширение поля IP-приоритета. Следовательно, спо-
собы использования и установки значения поля DSCP во многом напоминают рассмот-
ренные нами ранее способы использования и установки значения поля IP-приоритета.
Следует отметить, что поле кода дифференцированной услуги (DSCP) обладает об-
ратной совместимостью с полем IP-приоритета.
QoS-группа
QoS-группа представляет собой поле внутренней по отношению к маршрутизатору
структуры данных пакета. Поле QoS-группы применяется для маркировки пакетов на
основании определенных пользователем критериев классификации. Следует отметить,
3 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers/Nichols K. et
al. - RFC 2474.
54
Часть I. Качество обслуживания в сетях IP
что поле QoS-группы является внутренним по отношению к маршрутизатору и не
входит в заголовок IP-пакета.
С помощью поля QoS-группы производится внутренняя по отношению к маршру-
тизатору “раскраска” пакета. Средства качества обслуживания Cisco, поддерживающие
данную функцию маркировки пакетов, включают в себя механизм согласования ско-
рости доступа (CAR) и механизм распространения политик QoS с помощью протоко-
ла пограничного шлюза (QPPB). Классификация и маркировка пакетов с помощью
поля QoS-группы рассматриваются в практическом примере 3.2 далее в этой главе.
Модульный интерфейс командной строки QoS позволяет проводить маркировку
пакетов с использованием любого из трех рассмотренных выше механизмов. В
табл. 3.2 приведена сравнительная характеристика механизмов маркировки пакетов с
помощью поля IP-приоритета, поля DSCP и поля QoS-группы.
Таблица 3.2. Маркировка трафика с использованием поля IP-приоритета,
поля DSCP и поля QoS-группы
Атрибуты IP-приоритет DSCP QoS-группа
Область Вся сеть. Значение поля Вся сеть. Значение поля Внутреннее поле по от-
классификации IP-приоритета хранится в заголовке IP-пакета DSCP хранится в заго- ловке IP-пакета ношению к заданному маршрутизатору. Значе- ние поля QoS-группы не хранится в заголовке IP-пакета
Количество классов 8 классов (0-7) 64 класса (0-63) 100 классов (0-99)
Довольно часто пакеты поступают в пограничное устройство сети с уже установлен-
ным полем IP-приоритета или полем DSCP. Несмотря на то что поступивший пакет
уже имеет “раскраску”, сетевой оператор должен назначить новую маркировку пакета в
зависимости от его класса и соответствующего этому классу качества услуг, предлагае-
мых данной сетью. Более подробно переопределение значения поля IP-приоритета рас-
сматривается в практическом примере 3.3 далее в этой главе.
Практический пример 3.1: классификация и маркировка
пакетов с использованием поля IP-приоритета
Поставщик услуг Internet (Internet Service Provider — ISP) предлагает различные
уровни обслуживания трафика клиента с использованием для этих целей поля IP-
приоритета (другими словами, он гарантирует предпочтительную обработку клиент-
ского трафика в пределах своей базовой сети). Корпоративный клиент оплачивает ISP
два уровня услуг. Трафик корпоративного клиента, поступающий в сеть ISP из сети
215.215.215.0/24, должен иметь значение поля IP-приоритета, равное 5, а весь остав-
шийся трафик — значение поля IP-приоритета, равное 4 (см. рис. 3.1).
В данном практическом примере рассматривается установка поля IP-приоритета с
использованием механизмов CAR, PBR и QPPB.
С целью установки значения поля IP-приоритета всего поступающего трафика на ос-
новании IP-адреса источника поставщик услуг Internet должен применить соответствую-
щие конфигурационные команды механизмов CAR, PBR или QPPB на высокоскоростном
последовательном интерфейсе маршрутизатора (High-Speed Serial Interface — HSSI), под-
ключенного к сети корпоративного клиента.
Глава 3. Формирование трафика на границе сети: классификация... 55
Рис. 3.1. Подключение сети корпоративного клиента к сети поставщика услуг Internet
Классификация трафика путем установки значения поля
IP-приоритета с помощью механизма CAR
В листинге 3.1 приведена типичная конфигурация маршрутизатора, проводящего
классификацию трафика путем установки значения поля IP-приоритета с помощью
механизма CAR.
{ Листинг 3.1. Классификация трафика путем установки значения поля
j IP-приоритета с помощью механизма CAR
interface Hssi 0/0/1
rate-limit access-group 1 input 45000000 22500 22500
conform-action set-prec-transmit 5
exceed-action set-prec-transmit 5
rate-limit input 45000000 22500 22500
conform-action set-prec-transmit 4
exceed-action set-prec-transmit 4
access-list 1 permit 215.215.215.0 0.0.0.255
Для установки значения поля IP-приоритета используются два оператора, ограни-
чивающие интенсивность входящего трафика. Первый оператор назначает IP-
приоритет 5 трафику, поступающему из сети 215.215.215.0/24. Всему оставшемуся
трафику, поступающему на интерфейс HssiO/0/l, присваивается значение поля IP-
приоритета, равное 4.
Следует отметить, что несмотря на указание параметров ограничения интенсивно-
сти трафика, предназначение обоих операторов заключается всего лишь в установке
значения поля IP-приоритета на основании соответствующего списка доступа.
56
Часть I. Качество обслуживания в сетях IP
Примечание
Механизм согласования скорости доступа (CAR) предполагает наличие двух функций в од-
ном операторе: функции ограничения интенсивности трафика и функции установки значе-
ния поля IP-приоритета. Несмотря на то что в данном практическом примере рассматри-
вается только установка значения поля IP-приоритета, оператор rate-limit требует указания
параметров обеих функций. В будущем, с реализацией поддержки модульного интерфейса
командной строки QoS, установка значения поля IP-приоритета не будет требовать опре-
деления параметров функции, ограничивающей интенсивность трафика.
Классификация трафика путем установки значения поля
IP-приоритета с помощью механизма PBR
В листинге 3.2 приведена типичная конфигурация маршрутизатора, проводящего
классификацию трафика путем установки значения поля IP-приоритета с помощью
механизма PBR.
! Листинг 3.2. Классификация трафика путем установки значения поля
IP-приоритета с помощью механизма PBR
interface Hssi 0/0/1
ip policy route-map tasman
route-map tasman permit 10
match ip address 1
set ip precedence 5
route-map tasman permit 20
set ip precedence 4
access-list 1 permit 215.215.215.0 0.0.0.255
Карта маршрута tasman используется для установки значения поля IP-приоритета
равным 5 для трафика, поступающего из сети 215.215.215.0/24. В соответствии с кар-
той маршрута tasman всему оставшемуся трафику, поступающему на интерфейс
HssiO/0/l, присваивается значение поля IP-приоритета, равное 4.
Классификация трафика путем установки значения поля
IP-приоритета с помощью механизма QPPB
Маршрутизатор поставщика услуг Internet получает информацию о BGP-маршруте
215.215.215.0 из сети корпоративного клиента. В соответствии с BGP-конфигурацией
маршрутизатора карта таблицы tasman указывает на необходимость маркировки мар-
шрута 215.215.215.0 с помощью значения поля IP-приоритета, равного 5. Все остав-
шиеся BGP-маршруты, полученные из сети корпоративного клиента, маркируются с
помощью значения поля IP-приоритета, равного 4. В соответствии с протоколом по-
граничного шлюза (Border Gateway Protocol — BGP) вместе c BGP-маршрутом в таб-
лицу маршрутизации заносится также ассоциированное с этим маршрутом значение
IP-приоритета. Согласно же механизму скоростной коммутации пакетов Cisco (Cisco
Глава 3. Формирование трафика на границе сети: классификация... 57
Express Forwarding — CEF) из таблицы маршрутизации наряду с информацией о про-
движении пакета извлекается и значение поля IP-приоритета. Более подробно меха-
низм скоростной коммутации пакетов Cisco рассматривается в приложении Б,
“Механизмы коммутации пакетов”, далее в этой книге.
Прежде чем передать пакет, поступивший на интерфейс HssiO/0/l, на выходной
интерфейс, механизм CEF проверяет IP-адрес источника пакета и устанавливает зна-
чение поля IP-приоритета в соответствии с извлеченной из таблицы маршрутизации
информацией. В листинге 3.3 приведена типичная конфигурация маршрутизатора,
проводящего классификацию трафика путем установки значения поля IP-приоритета
с помощью механизма QPPB.
Листинг 3.3. Классификация трафика путем установки значения поля , >
IP-приоритета с помощью механизма QPPB
interface Hssi 0/0/1
ip address 217.217.217.1 255.255.255.252
bgp source ip-prec-map
router bgp 10
table-map tasman
neighbor 217.217.217.2 remote-as 2345
route-map tasman permit 10
match ip address 1
set ip precedence 5
route-map tasman permit 20
set ip precedence 4
access-list 1 permit 215.215.215.0 0.0.0.255
Практический пример 3.2: классификация и маркировка
пакетов с использованием поля QoS-группы
Возвратимся к условию практического примера 3.1 и предположим, что поставщик
услуг Internet предпочитает использовать поле QoS-группы для дифференцирования
входящего трафика в маршрутизаторах, подключенных к сети корпоративного клиен-
та. Как показано на рис. 3.1, трафик корпоративного клиента, поступающий из сети
215.215.215.0/24, маркируется с помошью значения поля QoS-группы, равного 3, а
весь оставшийся трафик — с помощью значения поля QoS-группы, равного 0.
Примечание
Проведение классификации пакетов с помощью поля QoS-группы вместо поля
IP-приоритета может быть оправдано потребностью иметь более чем 8 классов
трафика, а также необходимостью оставить без изменений начальное значение по-
ля IP-приоритета пакетов.
58
Часть I. Качество обслуживания в сетях IP
В данном практическом примере рассматривается классификация пакетов путем
установки значения поля QoS-группы с использованием механизмов CAR и QPPB. В
следующих разделах этой главы будут приведены типичные конфигурации маршрути-
затора, проводящего классификацию трафика путем установки значения поля QoS-
группы с помощью механизмов CAR и QPPB.
Классификация трафика путем установки значения поля
QoS-группы с помощью механизма CAR
В листинге 3.4 приведена типичная конфигурация маршрутизатора, проводящего
классификацию трафика путем установки значения поля QoS-группы с помощью ме-
ханизма CAR.
i Листинг 3.4. Классификация трафика путем установки значения поля
j ^ QoS-группы с помощью механизма CAR
interface Hssi 0/0/1
rate-limit access-group 1 input 45000000 22500 22500
4>conform-action set-qos-transmit 3 exceed-action drop
rate-limit input 45000000 22500 22500 conform-action
4>set-qos-transmit 0 exceed-action drop
access-list 1 permit 215.215.215.0 0.0.0.255
Классификация трафика путем установки значения поля
QoS-группы с помощью механизма QPPB
В листинге 3.5 приведена типичная конфигурация маршрутизатора, проводящего
классификацию трафика путем установки значения поля QoS-группы с помощью ме-
ханизма QPPB.
Листинг 3.5. Классификация трафика путем установки значения поля ,
QoS-группы с помощью механизма QPPB ,
interface Hssi 0/0/1
ip address 217.217.217.1 255.255.255.252
bgp source ip-qos-map
router bgp 10
table-map tasman
neighbor 217.217.217.2 remote-as 2345
route-map tasman permit 10
match ip address 1
set ip qos-group 3
route-map tasman permit 20
set ip qos-group 0
access-list 1 permit 215.215.215.0 0.0.0.255
Глава 3. Формирование трафика на границе сети: классификация... 59
Практический пример 3.3: переопределение значения
поля IP-приоритета
Поставщик услуг предлагает своим клиентам различные уровни обслуживания
трафика в добавление к негарантированной доставке трафика. Трафик клиентов, оп-
лачивающих дополнительные услуги, маркируется посредством установки значения
поля IP-приоритета, равного 5, а трафик всех оставшихся клиентов — посредством ус-
тановки значения поля IP-приоритета, равного 0 (рис. 3.2). Установка значения поля
IP-приоритета производится на границе сети поставщика услуг в зависимости от
уровня обслуживания клиентов.
Маркировка пакетов путам
устаноаки IP-приоритета О
Поставщик услуг
Hssi 1/1
Маркировка пакетов путем
установки 1Р-приоритата 5
Клиент, оплачивающий услугу
передачи трафика методом
негарантированной доставки
Клиант, оплачивающий
дополнительные услуги
передачи трафика
Hssi 1/0
Рис. 3.2. Установка IP-npuopumema входящего трафика в зависимости
от уровня обслуживания клиентов
Поставщик услуг должен присвоить IP-приоритет 0 всему трафику клиентов, опла-
чивающих услугу негарантированной доставки трафика. Трафику клиентов, оплачи-
вающих дополнительные услуги, следует присвоить IP-приоритет 5.
Установка IP-приоритета производится механизмом CAR, сконфигурированным
на высокоскоростных последовательных интерфейсах маршрутизатора, подключен-
ного к сетям клиентов (листинг 3.6).
------------------------------------------------------------------------—-г—п
Листинг 3.6. Использование механизма CAR для маркировки трафика . ;
j , путем установки значения поля IP-приоритета \ i
interface Hssi 1/0
rate-limit input 45000000 22500 22500 conform-action
set-prec-transmit 0 exceed-action set-prec-transmit 0
interface Hssi 1/1
rate-limit input 10000000 22500 22500 conform-action
set-prec-transmit 5 exceed-action set-prec-transmit 5
Интерфейс Hssi 1/0 подключен к сети клиента, оплачивающего услугу негарантиро-
ванной доставки пакетов. Следовательно, всему поступающему на данный интерфейс
трафику необходимо присвоить IP-приоритет 0.
60
Часть I. Качество обслуживания в сетях IP
Аналогично, интерфейс Hssil/1 подключен к сети клиента, оплачивающего допол-
нительные услуги передачи пакетов. Следовательно, всему поступающему на данный
интерфейс трафику необходимо присвоить IP-приоритет 5.
Необходимость управления интенсивностью
трафика
С целью обеспечения функций качества обслуживания весь входящий в сеть по-
ставщика услуг трафик должен проходить строгий контроль на границе сети на пред-
мет соответствия его интенсивности поддерживаемым сетью параметрам. Даже если
небольшое число пограничных маршрутизаторов начнут передавать трафик с интен-
сивностью, превышающей максимально допустимое значение, увеличившаяся нагруз-
ка потока трафика может привести к перегрузке сети. Следует отметить, что снижение
производительности сети неизбежно приведет к невозможности обеспечения функций
качества обслуживания для всего сетевого трафика.
Управление интенсивностью трафика может быть достигнуто за счет применения
двух функций: функции ограничения трафика, предусмотренной механизмом CAR, и
функции выравнивания трафика (traffic shaping — TS), предусмотренной одноимен-
ным механизмом. Несмотря на одинаковое предназначение, названные выше функ-
ции отличаются способом обработки трафика в момент исчерпания маркеров. Поня-
тие маркера исходит из схемы “корзина маркеров” — известного алгоритма дозиро-
ванной передачи трафика, который рассматривается в следующих разделах этой главы.
В табл. 3.3 приведена сравнительная характеристика функции ограничения и функции
выравнивания трафика.
Таблица 3.3. Сравнительная характеристика функции ограничения : : ‘ j
и функции выравнивания трафика * ; в
Функция ограничения трафика (механизм CAR) Функция выравнивания трафика (механизм TS)
Пересылает удовлетворяющий заданным параметрам Сглаживает трафик и пересылает его с постоянной
трафик с линейной интенсивностью. Допускает интенсивностью
всплеск трафика В случае исчерпания маркеров возможно отбрасыва- В случае исчерпания маркеров пакеты помещаются в
ние пакетов буфер и извлекаются из него по мере появления дос- тупных маркеров
Применяется для обработки входящего и исходящего В существующей реализации применяется только для
трафика обработки исходящего трафика
Протокол управления передачей (Transmission Control Если протокол TCP определяет, что скорость переда-
Protocol — TCP) определяет доступную полосу про- чи информации по линии связи недостаточна для пе-
пускания, однако адаптируется в моменты отбрасы- редачи поступающего трафика, он настраивает соот-
вания пакетов путем сужения размеров окна ветствующим образом таймер повторной передачи пакетов. Результатом этого является уменьшение
числа повторно переданных пакетов, что положи- тельно влияет на работу протокола TCP
Корзина маркеров
В процессе своей работы механизм управления интенсивностью трафика полагает-
ся на функцию дозирования трафика. Одной из наиболее распространенных схем до-
Глава 3. Формирование трафика на границе сети: классификация... 61
зирования трафика является так называемая схема “корзина маркеров” (token bucket).
Схема “корзина маркеров” используется как алгоритмом ограничения, так и алгорит-
мом выравнивания трафика и представляет собой средство сообщения о результатах
сопоставления параметров пакета с заданными ограничениями интенсивности.
Примечание
’’Корзина маркеров” является всего лишь средством дозирования трафика. Пакеты
данных при этом не подвергаются фильтрации, изменению или какому-либо другому
воздействию.
В зависимости от результатов дозирования принимается соответствующее решение
(передать пакет, отбросить пакет и т.п.).
Схема “корзина маркеров” предполагает наличие трех ключевых параметров.
• Средняя интенсивность, или согласованная скорость передачи информации
(Committed Information Rate — CIR), бит/с. Как правило, интенсивность трафи-
ка не превышает согласованную скорость передачи информации.
• Согласованный размер всплеска (Вс), байт. Объем трафика, на который может
быть превышен размер корзины маркеров в отдельно взятый момент времени.
Иногда этот параметр называют также стандартным размером всплеска.
• Расширенный размер всплеска (ВЕ), байт. “Резервный фонд”. Объем трафика, на
который может быть превышен размер корзины маркеров в экстренном случае.
Всплеск, размер которого находится между согласованным и расширенным раз-
мером, разрешается, как правило, только для очень небольшой части трафика.
Четвертый ключевой параметр — интервал времени (time interval — TI) — зависит
от средней интенсивности трафика и согласованного размера всплеска и вычисляется
по формуле TI = Вс -* CIR.
Вся оставшаяся часть этой главы посвящена рассмотрению реализации схемы
“корзина маркеров” для функции ограничения и функции выравнивания трафика.
Ограничение трафика
Функция ограничения трафика обеспечивается механизмом согласования скорости
доступа (Committed Access Rate — CAR). В целом механизм CAR реализует две основ-
ные функции: маркировка пакетов путем установки значения поля IP-приоритета и
ограничение интенсивности трафика.
Как функция ограничения трафика механизм CAR не помешает пакеты в буфер и
не сглаживает трафик, что может привести к отбрасыванию пакетов в моменты пре-
вышения максимально допустимого размера всплеска. Реализация механизма CAR
представляет собой список операторов rate-limit. Оператор rate-limit может быть при-
менен как к входящему, так и к исходящему трафику заданного интерфейса. Ниже
приведена структура оператора rate-limit.
rate-limit <input/ouput> access-group I rate-limit "CIR'1
^"согласованный всплеск" "расширенный всплеск"
?>conform-action "требуемое действие"
^exceed-action "требуемое действие"
62
Часть I. Качество обслуживания в сетях IP
Каждый оператор ограничения интенсивности трафика состоит из трех элементов.
Алгоритм обработки оператора rate-limit схематически представлен на рис. 3.3.
Переход к
следующему
оператору
rate-limit
Рис. 3.3. Алгоритм обработки оператора rate-limit
Условие совпадения трафика
Условие совпадения трафика позволяет определить пакеты, которые должны быть
обработаны с помощью механизма CAR. Условие совпадения трафика проверяется
последовательно для каждого из операторов rate-limit. В случае соответствия пакета
указанным параметрам выполняется алгоритм “корзина маркеров”. Если действие,
которое необходимо предпринять по завершении алгоритма, является действием про-
должения, то к рассмотрению принимается следующий по списку оператор rate-limit.
Обратите внимание, что условие совпадения трафика может быть составлено таким
образом, чтобы охватить собой все пакеты.
Пакет, “прошедший” все операторы rate-limit, должен быть передан. При необхо-
димости вы можете разместить в конце списка операторов rate-limit оператор, кото-
рый будет отбрасывать все пакеты.
Условие совпадения трафика может быть составлено одним из четырех перечис-
ленных ниже способов.
• Условие совпадения трафика охватывает собой все пакеты.
• Пакеты отбираются на основании значения поля IP-приоритета с использова-
нием ограничивающих интенсивность трафика списков доступа.
• Пакеты отбираются на основании МАС-адреса с использованием ограничи-
вающих интенсивность трафика списков доступа.
• Пакеты отбираются с использованием стандартных или расширенных списков
доступа на основе IP-адреса.
Списки доступа, ограничивающие интенсивность трафика, были специально соз-
даны с целью обеспечения возможности отбора пакетов на основании значения поля
IP-приоритета и МАС-адреса. Использование ограничивающих интенсивность трафи-
ка списков доступа, а также других способов отбора пакетов рассматривается в прак-
тических примерах далее в этой главе.
Глава 3. Формирование трафика на границе сети: классификация... 63
Дозирование трафика
Основным средством дозирования трафика является схема “корзина маркеров”. Реали-
зация этой схемы в рамках механизма согласования скорости доступа (CAR) представлена
на рис. 3.4.
Поступившие
пакеты
Избыточные
маркеры
Вс — согласованный размер всплеска
Т — интенсивность поступления маркеров
Переданные пакеты
(согласованное действие)
Отброшенные пакеты
(действие по переполнению)
Рис. 3.4. Стандартная реализация схемы “корзина маркеров” в рамках механизма согласования ско-
рости доступа (CAR)
Размер корзины маркеров (максимальное число маркеров, которое может вместить
корзина) равен согласованному размеру всплеска (Вс). Для каждого пакета, обрабаты-
ваемого в соответствии с механизмом CAR, из корзины вынимается число маркеров,
равное размеру пакета в байтах. Если для обслуживания пакета в корзине нашлось
достаточное количество маркеров, пакет передается. Если же размер в байтах посту-
пившего пакета больше, чем текущее количество доступных маркеров, учитывается
расширенный размер всплеска (ВЕ). Рассмотрим две типичные ситуации.
Стандартная корзина маркеров, ВЕ = Вс.
Стандартная корзина маркеров не поддерживает возможность экстренного уве-
личения размера всплеска. Расширенный размер всплеска для стандартной кор-
зины маркеров всегда равен согласованному размеру всплеска (Вс). В этом слу-
чае нехватка маркеров приводит к отбрасыванию пакета.
Корзина маркеров с возможностью экстренного увеличения размера всплеска, ВЕ > Вс.
В отличие от стандартной корзины маркеров, корзина маркеров с возможностью
экстренного увеличения размера всплеска позволяет “занять” недостающие марке-
64
Часть I. Качество обслуживания в сетях IP
ры. Поскольку вся последующая за этим дискуссия будет самым непосредственным
образом касаться темы заимствования, позволим себе ввести два “долговых” терми-
на — текущий долг (actual debt — DA) и накопленный долг (compounded debt —
Dc), — которые помогут нам разобраться во всех тонкостях поведения корзины
маркеров с возможностью экстренного увеличения размера всплеска.
Текущий долг (DA) представляет собой количество маркеров, занятых в настоящий
момент времени. Благодаря накоплению маркеров текущий долг уменьшается через
постоянные временные интервалы, определяемые сконфигурированной согласован-
ной скоростью передачи информации. Предположим, что вслед за последним отбра-
сыванием пакета вы занимали по 100 маркеров для передачи каждого из трех пакетов
данных. Таким образом, значение текущего долга (DA) после передачи первого, вто-
рого и третьего пакетов равно, соответственно, 100, 200 и 300.
Накопленный долг (Dc) представляет собой сумму текущих долгов (DA) всех пакетов,
переданных с момента последнего отбрасывания. В отличие от текущего долга (DA),
представляющего собой количество занятых маркеров с момента последнего отбрасыва-
ния пакета, накопленный долг (Dc) является суммой текущих долгов всех пакетов, для
передачи которых потребовалось занять маркеры с момента последнего отбрасывания
пакета. Аналогично предыдущему примеру, предположим, что вслед за последним от-
брасыванием пакета вы занимали по 100 маркеров для передачи каждого из трех пакетов
данных. Таким образом, значение накопленного долга (Dc) после передачи первого,
второго и третьего пакетов равно, соответственно, 100, 300 (= 100 + 200) и 600
( = 100 + 200 + 300). Обратите внимание, что после передачи первого пакета (для кото-
рой потребовалось занять маркеры) с момента последнего отбрасывания величина нако-
пленного долга (Dc) становится равной величине текущего долга (DA).
При потере пакета значение накопленного долга (Dc) обнуляется. Следующему пакету,
для передачи которого потребуется занять маркеры, ставится с соответствие новое значе-
ние накопленного долга (Dc), равное текущему долгу (DJ. Например, в том случае, если
четвертый пакет будет отброшен, следующему пакету, для передачи которого потребуется
занять маркеры (предположим, 100), будет поставлено в соответствие значение накоплен-
ного долга Dc = Da = 400 ( = 300 + 100). Обратите внимание, что, в отличие от накоплен-
ного долга (Dc), значение текущего долга (Од) не обнуляется после отбрасывания пакета.
Если текущий долг (DA) превышает расширенную границу, пакеты отбрасываются до тех
пор, пока значение DA не вернется в допустимые пределы (напомним, что уменьшение те-
кущего долга производится за счет накопления маркеров).
Потребность в использовании корзины с возможностью экстренного увеличения раз-
мера всплеска обуславливается таким весьма нежелательным свойством стандартной кор-
зины маркеров, как “отбрасывание хвоста” (tail-drop). Корзина маркеров с возможностью
экстренного увеличения размера всплеска обеспечивает постепенное отбрасывание паке-
тов, более характерное для алгоритма произвольного раннего обнаружения (Random Early
Detection — RED). Подробное рассмотрение алгоритма произвольного раннего обнаруже-
ния приводится в главе 6, “РНВ-политика: предотвращение перегрузки и политика
отбрасывания пакетов”, далее в этой книге. Если для передачи вновь пришедшего пакета
требуется занять некоторое число маркеров, проводится сравнение расширенного размера
всплеска (В^ и накопленного долга (Dc). Если Dc больше, чем ВЕ, пакет отбрасывается, а
значение накопленного долга (Dc) обнуляется. В противном случае пакет передается, при
этом текущий долг (DA) увеличивается на число занятых маркеров, а накопленный долг
(Dc) — на величину, равную обновленному значению текущего долга (DA).
Глава 3. Формирование трафика на границе сети: классификация... 65
Следует отметить, что когда пакет отбрасывается по причине нехватки маркеров
(т.е. когда число доступных маркеров меньше размера пакета в байтах), корзина не
опустошается (другими словами, отбрасывание пакетов не приводит к уменьшению
границы всплеска или границы интенсивности трафика).
Обратите внимание, что согласованная скорость передачи данных (CIR) — это ве-
личина, измеряемая в байтах в секунду. В свою очередь всплеск трафика выражается в
байтах. Текущий размер всплеска хранится в счетчике всплеска. Значение счетчика
всплеска может быть как меньше, так и больше, чем согласованный размер всплеска
(Вс). Когда значение счетчика всплеска превышает Вс, оно равно сумме согласован-
ного размера всплеска и текущего долга Вс + DA. В момент поступления нового паке-
та значение счетчика всплеска обновляется, как показано на рис. 3.5.
Счетчик всплеска
Be
Согласованное действие
(передача пакета)
Пропорциональное размеру
всплеска действие по переполнению
Действие по переполнению
(отбрасывание пакета)
Вс — согласованный всплеск В Е — расширенный всплеск
Рис. 3.5. Выбор соответствующего действия в отношении вновь прибывшего пакета на основа-
нии значения счетчика всплеска
В случае, когда значение счетчика всплеска находится между согласованным (Вс) и
расширенным (ВЕ) размерами всплеска, вероятность действия по переполнению мо-
жет быть приблизительно рассчитана по следующей формуле:
(Счетчик всплеска - ВС) + (ВЕ - ВС).
На рис. 3.6 представлен график вероятности отбрасывания пакета механизмом
CAR с учетом предложенной аппроксимации.
Вероятность отбрасывания
пакета, %
Счетчик
всплеска
Согласованный Расширенный
всплеск всплеск
Рис. 3.6. График вероятности отбрасывания па-
кета механизмом CAR
Линейное возрастание вероятности отбрасывания пакета механизмом CAR на от-
резке между согласованным и расширенным размерами всплеска напоминает линей-
ное возрастание вероятности отбрасывания пакета механизмом RED на отрезке между
минимальным и максимальным пороговым значением.
66
Часть I. Качество обслуживания в сетях IP
Примечание
Для упрощения восприятия материала на протяжении всего раздела под согласован-
ным действием и действием по переполнению подразумевается соответственно пе-
редача и отбрасывание пакета. В действительности же согласованное действие и
действие по переполнению может быть определено множеством различных способов,
которые рассматриваются в разделе “Политика действия" далее в этой главе.
Следует отметить, что типичный оператор ограничения интенсивности трафика, в
котором согласованный (Вс) и расширенный (ВЕ) размеры всплеска равны между со-
бой, исключает возможность линейного возрастания вероятности отбрасывания паке-
та на каком-либо участке.
Текущая реализация механизма согласования скорости доступа (CAR) накладывает
следующие ограничения на параметры корзины пакетов.
• Шаг увеличения интенсивности передачи трафика (бит/с) равен 8 Кбит/с, а
наименьшее значение согласованного и расширенного размера всплеска —
8000 байт.
• Минимальное значение согласованного размера всплеска (Вс) равно отноше-
нию интенсивности передачи трафика (бит/с) к 2000. Наименьшее значение
согласованного размера всплеска равно 8000 байт.
• Расширенный размер всплеска (ВЕ) всегда равен согласованному размеру
всплеска (Вс) или больше него.
Политика действия
Вы можете определить собственную политику действия для согласованного дейст-
вия и действия по переполнению каждого оператора ограничения интенсивности
трафика. Ниже перечислены возможные значения параметров conform-action и exceed-
action оператора rate-limit:
• передать пакет;
• отбросить пакет;
• продолжить (continue) (перейти к следующему по списку оператору rate-limit);
• установить значение поля IP-приоритета и передать пакет;
• установить значение поля IP-приоритета и продолжить просмотр списка опера-
торов rate-limit;
• установить значение поля QoS-группы и передать пакет;
• установить значение поля QoS-группы и продолжить просмотр списка операто-
ров rate-limit.
Более подробно использование действия продолжения рассматривается в практиче-
ском примере 3.9 далее в этой главе. Следует отметить, что на текущий момент клас-
сификация трафика путем установки значения поля QoS-группы реализована только в
маршрутизаторах Cisco серии 7500, построенных на базе интерфейсных плат VIР
(Versatile Interface Processor — универсальный интерфейсный процессор).
Глава 3. Формирование трафика на границе сети: классификация... 67
Примечание
Конфигурирование интенсивности трафика для отдельного интерфейса (Per-lnterface
Rate Configuration — PIRC) представляет собой будущую реализацию механизма CAR
для маршрутизаторов Cisco серии 12000. Функция PIRC встраивается в набор микроко-
манд специализированной интегральной схемы (Application-Specific Integrated Circuit —
ASIC), отвечающей за коммутацию пакетов и установленной на определенных линейных
платах маршрутизатора. Следует отметить, что к каждому интерфейсу маршрутизатора
может быть применено только одно правило CAR, ограничивающее интенсивность тра-
фика и/или устанавливающее значение поля IP-приоритета. Функция PIRC может быть
применена для обработки только входящего трафика.
Практический пример 3.4: ограничение интенсивности
трафика приложения на уровне обслуживания
Предположим, что один из клиентов поставщика услуг вносит дополнительную
плату за определенный уровень обслуживания, в соответствии с которым весь трафик
клиента, за исключением трафика HTTP (Hypertext Transfer Protocol — протокол пе-
редачи гипертекстовых файлов) интенсивностью более 15 Мбит/с, маркируется с по-
мощью установки значения поля IP-приоритета, равного 4. HTTP-трафик интенсив-
ностью более 15 Мбит/с маркируется с помощью установки значения поля IP-
приоритета, равного 0. Общая пропускная способность каналов, оплачиваемых клиен-
том поставщика услуг, равна 30 Мбит/с.
В листинге 3.7 приведена конфигурация механизма CAR в пограничном маршру-
тизаторе сети поставщика услуг, подключенном к сети клиента.
[ Листинг 3.7. Ограничение интенсивности HTTP-трафика на уровне обслу-
живания
Interface Hssil/0/0
rate-limit input 30000000 15000 15000 conform-action
4>continue exceed-action drop
rate-limit input access-group 101 15000000 10000 10000
4>conform-action set-prec-transmit 4
^exceed-action set-prec-transmit 0
rate-limit input 30000000 15000 15000 conform-action
set-prec-transmit 4 exceed-action set-prec-transmit 4
i
access-list 101 permit tcp any any eq www
access-list 101 permit tcp any eq www any
Первый оператор rate-limit ограничивает интенсивность всего входящего трафика
до 30 Мбит/с. В качестве согласованного действия используется действие продолжения
(continue), указывающее на необходимость перехода к анализу следующего по списку
оператора rate-limit. Второй оператор rate-limit используется для маркировки НТТР-
трафика с помощью поля IP-приоритета в зависимости от его интенсивности. И, на-
конец, последний оператор rate-limit используется для маркировки всего оставшегося
(не HTTP-) трафика с помощью установки значения поля IP-приоритета, равного 4. В
68
Часть I. Качество обслуживания в сетях IP
листингах 3.8 и 3.9 приведен результат выполнения некоторых важных show-команд
механизма CAR.
; Листинг 3.8. Параметры механизма CAR и статистика обработки пакетов’?;^
fshow interface hssil/0 rate
Hssil/0/0
Input
matches: all traffic
params: 30000000 bps, 15000 limit, 15000 extended limit
conformed 0 packets, 0 bytes; action: continue
exceeded 0 packets, 0 bytes; action: drop
last packet: 338617304ms ago, current burst: 0 bytes
last cleared 00:11:11 ago, conformed 0 bps, exceeded 0 bps
matches: access-group 101
params: 15000000 bps, 10000 limit, 10000 extended limit
conformed 0 packets, 0 bytes; action: set-prec-transmit 4
exceeded 0 packets, 0 bytes; action: set-prec-transmit 0
last packet: 338617201ms ago, current burst: 0 bytes
last cleared 00:11:11 ago, conformed 0 bps, exceeded 0 bps
matches: all traffic
params: 15000000 bps, 10000 limit, 10000 extended limit
conformed 0 packets, 0 bytes; action: set-prec-transmit 4
exceeded 0 packets, 0 bytes; action: set-prec-transmit 4
last packet: 338617304ms ago, current burst: 0 bytes
last cleared 00:03:30 ago, conformed 0 bps, exceeded 0 bps
Результатом выполнения команды show interface rate является вывод конфигураци-
онных параметров механизма CAR и статистики обработки пакетов. Значение пара-
метра current burst представляет собой мгновенный “снимок” корзины маркеров на
момент вывода результата выполнения команды show interface rate. Значение согласо-
ванной интенсивности передачи трафика (conformed f bps) вычисляется путем деления
общего объема переданного трафика с момента последнего обновления счетчиков на
время передачи.
! Листинг 3.9. Статистика учета IP-приоритета входящего и исходящего . ?,|
’ -трафика для интерфейса HssiWO , <
♦show interface hssil/0/0 precedence
Hssil/0/0
Input
Precedence 4: 10 packets, 1040 bytes
Output
Precedence 4: 10 packets, 1040 bytes
Результатом выполнения команды show interface precedence является вывод стати-
стики учета IP-приоритета входящего и исходящего трафика для заданного интерфей-
са маршрутизатора при условии активизации соответствующей функции.
Глава 3. Формирование трафика на границе сети: классификация... 69
Практический пример 3.5: ограничение интенсивности
трафика в зависимости от значения IP-приоритета
Поставщик услуг ограничивает интенсивность низкоприоритетного трафика, по-
ступающего из сети партнера по линии связи DS3. Ограничение интенсивности тра-
фика со значением IP-приоритета 0, 1 и 2 — 10 Мбит/с, в то время как высокопри-
оритетный трафик передается без каких-либо ограничений (рис. 3.7).
Рис. 3.7. Ограничение интенсивности трафика в зависимости от значения
IP-npuopumema
В листинге 3.10 приведена соответствующая конфигурация высокоскоростного по-
следовательного интерфейса маршрутизатора, подключенного к сети партнера.
: Листинг 3.10. Ограничение интенсивности трафика в зависимости 4
. от значения IP-приоритета г/,4.|
interface Hssil/O/O
rate-limit input access-group rate-limit 1 10000000 10000 10000
conform-action transmit exceed-action drop
access-list rate-limit 1 mask 07
Критерий совпадения диапазона значений IP-приоритета задается с помощью
8-битовой маски, каждый бит которой представляет собой соответствующий IP-
приоритет. Так, IP-приоритету 7 соответствует маска 10000000, IP-приоритету 6 —
маска 01000000, IP-приоритету 5 — маска 00100000 и т.д. В данном примере ис-
пользуется маска 07 (в шестнадцатеричном представлении), которой отвечает би-
нарная запись 00000111. Следовательно, эта маска соответствует диапазону значе-
ний IP-приоритета 0-2.
В приведенном выше листинге для отбора трафика со значением IP-приоритета 0,
1 и 2 используется оператор списка доступа с ограничением интенсивности трафика.
Номера списков доступа с ограничением интенсивности трафика на основании зна-
чения IP-приоритета находятся в диапазоне от 1 до 99. Соответствующий оператор
rate-limit ограничивает общую интенсивность трафика со значением IP-приоритета 0,
1 и 2 до 10 Мбит/с.
70
Часть I. Качество обслуживания в сетях IP
Практический пример 3.6: предоставление услуг
с ограниченной интенсивностью трафика
Поставщик услуг предоставляет своему клиенту выделенный физический канал
ТЗ, однако ограничивает его пропускную способность с целью уменьшения або-
нентской платы (к примеру, пропускная способность канала ТЗ может быть огра-
ничена до 10, 20 или 30 Мбит/с). При желании со временем клиент может рас-
ширить пропускную способность. Интенсивность трафика предоставленного кли-
енту канала связи ограничивается до оговоренного обеими сторонами предела
механизмом CAR (при этом, как правило, предусматривается возможность вре-
менного всплеска трафика). Следует отметить, что сетевой оператор может увели-
чить предоставляемую клиенту пропускную способность без необходимости вне-
сения изменений в структуру сети на физическом уровне.
Для того чтобы ограничить интенсивность входящего трафика интерфейса ТЗ до
уровня, оплачиваемого клиентом, поставщик услуг может сконфигурировать на этом
интерфейсе оператор rate-limit. В листинге 3.11 приведена конфигурация, в соответст-
вии с которой интенсивность входящего трафика ограничивается до 20 Мбит/с. Тра-
фик, интенсивность которого превышает это значение, будет отброшен.
i Листинг 3.11. Предоставление услуг с ограниченной интенсивностью
L ' трафика
|.; п... ____,__... ,. . ...___; ._A.,.; J ‘ ... ____... - '.I
interface HssiO/O/O
rate-limit input rate-limit 20000000 40000 40000
^conform-action transmit exceed-action drop
Практический пример 3.7: предоставление услуг
по размещению Web-серверов
Предположим, что поставщик услуг поддерживает кластер Web-серверов, предлагая
своим клиентам воспользоваться этой возможностью для размещения необходимых им
служб. Оплата предоставляемых услуг зависит от гарантированной полосы пропускания и
уровня обслуживания трафика клиента в сети поставщика услуг. Далее, предположим, что
клиент, работающий в сфере электронной коммерции, покупает для своего Web-сервера
гарантированную полосу пропускания 5 Мбит/с и оплачивает высокий уровень обслужи-
вания трафика. Поставщик услуг маркирует весь трафик Web-сервера клиента (1Р-адрес
209.11.212.1) интенсивностью до 5 Мбит/с посредством установки значения поля IP-
приоритета, равного 4. Подобное значение IP-приоритета будет гарантировать высокий
уровень обработки трафика клиента даже в случае перегрузки сети поставщика услуг. Тра-
фик, интенсивность которого превышает 5 Мбит/с, будет доставляться без гарантий; соот-
ветственно, ему назначается наиболее низкий IP-приоритет — 0. Подобный сценарий раз-
вития событий реализуется с помощью приведенной в листинге 3.12 конфигурации мар-
шрутизатора, подключенного к кластеру серверов.
: Листинг 3.12. Предоставление услуг по размещению Web-серверов ?
interface FastEthernet4/0/0
rate-limit input access-group 2 rate-limit 5000000 40000 40000
Глава 3. Формирование трафика на границе сети: классификация... 71
^conform-action set-prec-transmit 4
4>exceed-action set-prec-transmit 0
access-list 2 permit 209.11.212.1
Все пакеты, пересылаемые Web-сервером с IP-адресом 209.11.212.1, маркируются с
помощью установки соответствующего значения поля IP-приоритета в зависимости от
интенсивности трафика. Трафик, интенсивность которого не превышает 5 Мбит/с,
маркируется посредством установки IP-приоритета 4, в то время как весь остальной
трафик маркируется посредством установки IP-приоритета 0.
Практический пример 3.8: предотвращение атак типа
Denial-of-Service
Поставщики услуг часто подвергаются нападению злоумышленников, использую-
щих пакеты протокола управляющих сообщений Internet (Internet Control Message
Protocol — ICMP) для бомбардировки важных сетевых узлов, таких как Web-сервер
или сервер электронной почты. ICMP-трафик высокой интенсивности способен на
некоторое время вывести сервер из строя, что и является целью подобных атак, полу-
чивших название атак типа Denial-of-Service (“отказ в обслуживании”).
Панацея от атак типа Denial-of-Service заключается в надлежащем использовании мар-
шрутизатора поставщика услуг. Несмотря на то что сам маршрутизатор не является объек-
том атаки, правильно сконфигурированный механизм CAR может обнаружить атаку зло-
умышленника и уберечь сеть от внешнего воздействия путем ограничения интенсивности
ICMP-трафика до уровня, необходимого для нормальной эксплуатации всех служб.
В листинге 3.13 приведена конфигурация интерфейса маршрутизатора, подклю-
ченного к каналу DS3, в соответствии с которой интенсивность входящего ICMP-
трафика ограничивается до 256 Кбит/с.
: Листинг 3.13. Предотвращение атаки типа Denial-of-Service
interface Hssil/0
rate-limit input access-group 100 256000 8000 8000
4>conform-action transmit exceed-action drop
access-list 100 permit iemp any any
Практический пример 3.9: ограничение трафика в точке
обмена трафиком общего пользования
Предположим, что поставщик услуг Internet уровня 1 (Tier-1 ISP) обеспечивает переда-
чу транзитного трафика для состоящих с ним в отношении соседства (peer) и расположен-
ных ниже по потоку поставщиков услуг Internet (ISP) X и Y через точку обмена трафиком
общего пользования, построенную на базе коммутатора FDDI (Fiber Distributed Data Inter-
face — распределенный интерфейс передачи данных по волоконно-оптическим каналам).
Расположенный выше по потоку поставщик услуг уровня 1 ограничивает интенсивность
транзитного трафика ISP X и Y с помощью соответствующей конфигурации механизма
CAR, позволяющей проводить ограничение трафика на основе МАС-адреса. Кроме того,
72
Часть I. Качество обслуживания в сетях IP
поставщик услуг уровня 1 хочет быть уверенным в том, что подключенные к коммутатору
поставщики услуг Internet, не состоящие с ним в отношениях соседства (поп-peer), не
смогут передавать через него транзитный трафик (рис. 3.8).
Отбрасывание всего
трафика, поступающего
не от ISP X или Y ।
Поставщик услуг
уровня 1
Рис. 3.8. Ограничение трафика в точке обмена трафиком общего пользования
Поставщик услуг уровня 1 хочет ограничить интенсивность трафика, поступаю-
щего от ISP X и Y, до 30 и 40 Мбит/с соответственно. Весь трафик, превышающий
среднюю интенсивность, будет отброшен.
Кроме того, поставщик услуг уровня 1 отбрасывает все пакеты, пришедшие на
FDDI-интерфейс от поставщиков услуг Internet, не состоящих с ним в отношениях
соседства (т.е. ISP, отличных от X и Y).
В листинге 3.14 приведена соответствующая конфигурация маршрутизатора по-
ставщика услуг уровня 1.
Листинг 3.14. Ограничение трафика в точке обмена трафиком общего
пользования '
interface Fddil/O/O
ip address 162.111.10.1 255.255.255.192
rate-limit input access-group rate-limit 110 30000000 15000 15000
^conform-action transmit exceed-action drop
rate-limit input access-group rate-limit 120 40000000 40000 40000
4c>conform-action transmit exceed-action drop
rate-limit input access-group 100 4000000 40000 40000
conform-action drop exceed-action drop
access-list rate-limit 110 0000.OclO.7819
access-list rate-limit 120 0000.0c89.6900
access-list 100 permit ip any any
Глава 3. Формирование трафика на границе сети: классификация... 73
МАС-адресами FDDI-интерфейсов маршрутизаторов поставщиков услуг Internet X
и Y являются, соответственно, 0000.ОсЮ.7819 и 0000.0c89.6900.
Номера списков доступа, ограничивающих интенсивность трафика на основании
значения МАС-адреса, находятся в диапазоне от 100 до 199. Список доступа с номе-
ром НО используется для ограничения интенсивности трафика, поступающего от по-
ставщика услуг Internet X, до 30 Мбит/с. Аналогично, список доступа с номером 120
используется для ограничения интенсивности трафика, поступающего от поставщика
услуг Internet Y, до 40 Мбит/с.
Последний оператор rate-limit предназначен для “захвата” и отбрасывания всего
трафика, поступающего на FDDI-интерфейс поставщика услуг уровня 1 от не со-
стоящих с ним в отношениях соседства ISP.
Выравнивание трафика
Выравнивание трафика (traffic shaping — TS) представляет собой механизм сглажи-
вания поступающего на интерфейс потока трафика с целью недопущения перегрузки
канала и удовлетворения требований поставщика услуг. В соответствии с механизмом
TS интенсивность пульсирующего трафика выравнивается до согласованной скорости
передачи информации (CIR) путем постановки в очередь (буферизации) пакетов, ин-
тенсивность передачи которых превысила среднее значение. Буферизованные пакеты
передаются по мере накопления достаточного числа маркеров. Передача поставлен-
ных в очередь пакетов планируется механизмом обслуживания очередей “первым
пришел, первым обслужен” (first-in, first-out — FIFO) или взвешенным механизмом
равномерного обслуживания очередей (Weighted Fair Queuing — WFQ). Операционная
модель механизма выравнивания трафика схематически представлена на рис. 3.9.
Рис. 3.9. Операционная модель механизма выравнивания трафика
Механизм TS может быть сконфигурирован в адаптивном режиме на интерфейсе
Frame Relay. В этом режиме механизм выравнивания трафика определяет доступную
полосу пропускания на основании объединения значения поля BECN/FECN (Backward
Explicit Congestion Notification — обратное явное уведомление о перегрузке; Forward Ex-
plicit Congestion Notification— прямое явное уведомление о перегрузке) и бита DE
74
Часть I. Качество обслуживания в сетях IP
(Discard Eligible — “пригодный для отбрасывания”) (более подробно механизмы преду-
преждения перегрузки в сетях Frame Relay рассматриваются в главе 8, “Качество
обслуживания на уровне 2: межсетевой обмен с IP QoS”, далее в этой книге).
В этом разделе рассматривается выравнивание трафика на всех интерфей-
сах/субинтерфейсах вне зависимости от возможной инкапсуляции интерфейса. Выравни-
вание трафика на отдельном постоянном/коммутируемом виртуальном канале (permanent
virtual circuit — PVC; switched virtual circuit — SVC) Frame Relay рассматривается в главе 8,
“Качество обслуживания на уровне 2: межсетевой обмен с IP QoS”, далее в этой книге.
Дозирование трафика
В качестве инструмента дозирования трафика механизм TS использует уже знако-
мую нам корзину маркеров, которая применяется для проверки поступающих пакетов
на соответствие заданному профилю.
Максимальный размер корзины маркеров равен сумме размеров согласованного (Вс) и
расширенного (ВЕ) всплесков. Корзина пополняется маркерами, число которых равняется
размеру согласованного всплеска (Вс), через каждый интервал времени Т = Вс ч- CIR, где
CIR представляет собой согласованную среднюю интенсивность потока трафика. Когда
корзина становится полной, вновь прибывающие избыточные маркеры отбрасываются.
Для каждого пакета, обрабатываемого в соответствии с механизмом TS, из корзины выни-
мается число маркеров, равное размеру пакета в байтах. Если для передачи пакета в кор-
зине нашлось достаточное количество маркеров, пакет передается, а размер корзины
уменьшается на равное размеру переданного пакета количество маркеров. В противном
случае пакет маркируется как не удовлетворяющий заданному профилю и ставится в оче-
редь для последующей передачи. На рис. 3.10 изображена реализация алгоритма “корзина
маркеров” для механизма выравнивания трафика.
Корзина пополняется маркерами,
число которых равняется размеру
согласованного всплеска (Вс), чврвз
каждый интервал времени Т = Bc/CIR
Избыточные маркеры отбрасываются
Рис. 3.10. Реализация алгоритма “корзина маркеров ” для механизма выравнивания трафика
Размвр корзины
ВС+ВЕ
Если для передачи пакета в корзине
нашлось достаточное количество
маркеров, пакет передается, а размер
корзины уменьшается на равное размеру
пакета в байтах число маркеров
Механизм выравнивания трафика может быть применен к любому унифицирован-
ному интерфейсу с использованием одной из его двух реализаций — обобщенного ме-
Глава 3. Формирование трафика на границе сети: классификация... 75
ханизма выравнивания трафика (Generic Traffic Shaping — GTS) и распределенного
механизма выравнивания трафика (Distributed Traffic Shaping — DTS). Сравнительная
характеристика механизмов GTS и DTS приведена в табл. 3.4.
’ Таблица 3.4. Сравнительная характеристика двух реализаций механизма
выравнивания трафика: GTS и DTS
Основные характеристики Обобщенный механизм выравнивания трафика (GTS) Распределенный механизм выравнивания трафика (DTS)
Порядок передачи В качестве алгоритма обслуживания В качестве алгоритма обслужива-
буферизованных пакетов очередей используется алгоритм WFQ ния очередей используется либо алгоритм FIFO, либо распределен- ный алгоритм WFQ (Distributed WFQ-DWFQ)
Критерий совпадения трафика Поддерживаются два режима: кри- терию совпадения удовлетворяет либо весь трафик, либо трафик, со- ответствующий простому или рас- ширенному списку доступа на осно- ве IP-адреса Классы трафика определяются пользователем с помощью одного из механизмов классификации трафика (CAR или QPPB)
Поддержка идентификации Выравнивание трафика для отделы- Поддерживается выравнивание тра-
соединения канального уровня ных каналов PVC/SVC на интерфей- фика для отдельных каналов
(Data-Link Connection Identifier - DLCI) для каналов Frame Relay се Frame Relay не поддерживается PVC/SVC на интерфейсе Frame Relay
Доступность Все однопроцессорные (не распре- деленные) платформы Только в маршрутизаторах Cisco серии 7500, построенных на базе интерфейсной платы VIP
Поддержка протоколов Все протоколы Только протокол IP
Практический пример 3.10: выравнивание интенсивности
трафика до скорости доступа
Корпоративный клиент подключен к сети поставщика услуг на скорости доступа
256 Кбит/с с использованием канала Т1. Сетевой администратор корпоративного кли-
ента желает ограничить среднюю интенсивность исходящего по каналу Т1 трафика до
256 Кбит/с, как показано на рис. 3.11.
Рис. 3.11. Выравнивание интенсивности
трафика до 256 Кбит/с
76
Часть I. Качество обслуживания в сетях IP
Скорость доступа последовательного интерфейса маршрутизатора корпоративного кли-
ента, подключенного к сети поставщику услуг, равна 256 Кбит/с. В следующих разделах
этой главы рассматривается выравнивание трафика с помощью механизмов GTS и DTS.
Выравнивание трафика с помощью механизма GTS
В листингах 3.15-3.18 приведен пример конфигурации механизма GTS, исполь-
зующегося для выравнивания средней интенсивности трафика до 256 Кбит/с, а также
результаты выполнения некоторых важных show-команд, предназначенных для мони-
торинга процесса выравнивания трафика.
Листинг 3.15. Выравнивание средней интенсивности трафика \
до 256 Кбит/с с помощью механизма GTS
interface SerialO
traffic-shape rate 256000
Обратите внимание, что конфигурация механизма выравнивания трафика GTS
предполагает указание значения только одного параметра — требуемой согласованной
скорости доступа (CIR). Соответствующие значения обеспечиваемой скорости переда-
чи пакетов и расширенного размера всплеска (ВЕ), приведенные в лист. 3.16, подби-
раются автоматически.
Листинг 3.16. Параметры механизма выравнивания трафика GTS, сконфи- i
гурированного на интерфейсе SerialO ;
#show traffic shape serialO
Access Target Byte Sustain Excess Interval Increment Adapt
I/F List Rate Limit bits/int bits/int (ms) (bytes) Active
SeO 256000 1984 7936 7936 31 992
Команда show traffic-shape предназначена для вывода на экран конфигурации ме-
ханизма выравнивания трафика и параметров корзины маркеров.
, Листинг 3.17. Статистика очереди механизма выравнивания трафика GTS
#show traffic serial queue
Traffic queued in shaping queue on SerialO
Queueing strategy: weighted fair
Queueing Stats: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 4/8/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
(depth/weight/discards/tail drops/interleaves) 9/585/0/0/0
Conversation 118, linktype: ip, length: 70
source: 199.199.199.199, destination: 2.2.2.1, id: 0x212D,
ttl: 255, TOS: 192 prot: 6, source port 60568,
destination port 711
(depth/weight/discards/tail drops/interleaves) 6/1365/0/0/0
Глава 3. Формирование трафика на границе сети: классификация... 77
Conversation 84, linktype: ip, length: 60
source: 254.6.140.76, destination: 172.16.1.3, id: 0x45C0,
ttl: 213, prot: 158
(depth/weight/discards/tail drops/interleaves) 8/4096/0/0/0
Conversation 124, linktype: ip, length: 114
source: 172.16.69.115, destination: 2.2.2.1, id: 0x0079,
ttl: 254, prot: 1
(depth/weight/discards/tail drops/interleaves) 5/4096/26/0/0
Conversation 257, linktype: cdp, length: 337
Команда show traffic-shape queue предназначена для вывода на экран параметров алго-
ритма обслуживания очередей WFQ, а также сведений о поставленных в очередь пакетах.
: Листинг 3.18. Статистика механизма выравнивания трафика GTS
для интерфейса SerialO ‘
♦ show traffic Access serialO Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
SeO 4 2000 185152 20 1281 yes
Команда show traffic-shape statistics предназначена для вывода на экран статистики об-
работки пакетов механизмом выравнивания трафика GTS. Значение параметра Queue Depth
отражает число пакетов в очереди WFQ на момент выполнения команды show traffic-shape
statistics. Общий объем трафика, переданного через интерфейс, можно узнать с помощью
параметров Packets и Bytes. Параметры Packets Delayed и Bytes Delayed указывают на часть
переданного трафика, которая была поставлена в очередь WFQ. Статус механизма вырав-
нивания трафика (активен в данный момент или нет) зафиксирован в параметре Shaping
Active. Механизм выравнивания трафика переводится в активное состояние в случае необ-
ходимости постановки пакетов в очередь WFQ перед их передачей.
Выравнивание трафика с помощью механизма DTS
Оператор class-map относит весь IP-трафик к единственному классу myclass. Опе-
ратор policy-map указывает на необходимость использования политики mypolicy для
выравнивания средней интенсивности трафика класса myclass до 256 Кбит/с. Полити-
ка mypolicy применяется к последовательному интерфейсу маршрутизатора с целью
выравнивания исходящего трафика.
В целях продолжения дальнейшей дискуссии предположим, что последовательный
интерфейс маршрутизатора, изображенного на рис. 3.11, является интерфейсом Se-
rialO/O/O. Напомним, что механизм выравнивания трафика DTS реализован только в
маршрутизаторах Cisco серии 7500, построенных на базе интерфейсных плат VIР.
В листингах 3.19 и 3.20 приведен пример конфигурации механизма DTS, исполь-
зующегося для выравнивания средней интенсивности трафика до 256 Кбит/с, а также
результат выполнения одной важной show-команды, предназначенной для монито-
ринга процесса выравнивания трафика.
78
Часть I. Качество обслуживания в сетях IP
Листинг 3.19. Выравнивание средней интенсивности трафика
до 256 Кбит/с с помощью механизма DTS
class-map myclass
match any
policy-map mypolicy
class myclass
shape average 256000 16384 0
interface Serial0/0/0
service-policy output mypolicy
Команда shape average используется для установки согласованной скорости переда-
чи (CIR) исходящего трафика (в данном примере 256000 бит/с) без возможности пре-
вышения интенсивности трафика на отдельно взятом интервале. Согласованный раз-
мер всплеска (Вс) равен 16384 бит. Следовательно, временной интервал равен 64 мс.
Напомним, что в соответствии с командой shape average превышение интенсивности
трафика на отдельно взятом интервале не допускается. Более того, увеличение разме-
ра всплеска невозможно даже в том случае, если в качестве третьего параметра коман-
ды shape average указано значение, отличное от 0. Для увеличения размера всплеска
на отдельно взятом временном интервале до Вс + ВЕ бит с сохранением текущего зна-
чения CIR используется команда shape peak.
Листинг 3.20. Параметры механизма выравнивания трафика DTS
и статистика очереди
♦ show interface shape
Serial0/0/0 nobuffer drop 0
Serial0/0/0 (class 2):
cir 256000, Be 16384, Be 0
packets output 0, bytes output 0
queue limit 0, queue size 0, drops 0
last clear = 00:01:39 ago, shape rate = 0 bps
Команда show interface shape предназначена для вывода на экран статистики передачи
пакетов, статистики очереди и параметров механизма выравнивания трафика DTS.
Практический пример 3.11: выравнивание интенсивности
входящего и исходящего трафика узла
Узел А с IP-адресом 200.200.200.1, расположенный в удаленном отделе сбыта
крупной компании, подключен к сети с помощью интерфейса Ethernet. Подключение
к корпоративной сети компании осуществляется посредством маршрутизатора по ка-
налу Т1. Сетевой администратор хочет выравнять интенсивность входящего и исхо-
дящего трафика узла Адо 128 Кбит/с, как показано на рис. 3.12.
Глава 3. Формирование трафика на границе сети: классификация... 79
Рис. 3.12. Выравнивание входящего и исходящего трафика узла А
Узел А подключен к маршрутизатору удаленного отдела продаж через интерфейс
ethemetO. Последовательный интерфейс маршрутизатора serialO подключен к корпора-
тивной сети с помощью канала Т1. В следующих разделах этой главы рассматривается
использование механизмов GTS и DTS для выравнивания интенсивности входящего и
исходящего трафика узла А до 128 Кбит/с.
Конфигурация механизмов выравнивания трафика GTS и DTS приведена в лис-
тингах 3.21 и 3.22, соответственно.
Выравнивание интенсивности входящего и исходящего
трафика узла с помощью механизма GTS
В листинге 3.21 приведена конфигурация механизма GTS, использующегося для
выравнивания интенсивности входящего и исходящего трафика узла А.
! Листинг 3.21. Выравнивание интенсивности трафика до 128 Кбит/с
i с помощью механизма GTS
interface serial О
traffic-shape group 101 128000
interface ethernet 0
traffic-shape group 102 128000
access-list 101 permit ip host 200.200.200.1 any
access-list 102 permit ip any host 200.200.200.1
Критерии совпадения, заданные списками доступа 101 и 102, удовлетворяют исхо-
дящему и входящему трафику узла с IP-адресом 200.200.200.1. Механизм GTS скон-
80
Часть I. Качество обслуживания в сетях IP
фигурирован для выравнивания интенсивности исходящего трафика до 128 Кбит/с на
интерфейсе serial 0. Аналогичным образом, выравнивание интенсивности входящего
трафика производится на интерфейсе ethernetO.
Выравнивание интенсивности входящего и исходящего
трафика узла с помощью механизма DTS
В листинге 3.22 приведен пример конфигурации механизма DTS, использующегося
для выравнивания интенсивности входящего и исходящего трафика узла А до
128 Кбит/с. Предположим, что последовательный интерфейс и Ethemet-интерфейс
маршрутизатора, изображенного на рис. 3.12, являются интерфейсами SerialO/0/O и
Ethernet 1/0/0, соответственно. Механизм формирования трафика DTS реализован только в
маршрутизаторах Cisco серии 7500, построенных на базе интерфейсных плат VIР.
; Листинг 3.22. Выравнивание интенсивности трафика до 128 Кбит/с
с помощью механизма DTS ’
:.................... ... ___ . .. .............____________ . .
class-map FromHostA
match ip access-list 101
class-map ToHostA
match ip access-list 102
policy-map frompolicy
class FromHostA
shape peak 128000 8192 1280
policy-map topolicy
class ToHostA
shape peak 128000 8192 1280
interface serial0/0/0
service-policy output frompolicy
interface ethernetl/0/0
service-policy output topolicy
Критерии совпадения, определенные картами класса FromHostA и ToHostA, удовле-
творяют исходящему и входящему трафику узла А, соответственно. К каждому из двух
классов трафика применяется политика выравнивания интенсивности передачи дан-
ных до 128 Кбит/с. Команда service-policy используется для применения политик к ис-
ходящему трафику интерфейса.
Команда shape peak 128000 8192 1280 указывает на необходимость выравнивания
средней интенсивности трафика до 128 Кбит/с с размером всплеска 9472
(8192 + 1280) бит на интервал.
Глава 3. Формирование трафика на границе сети: классификация... 81
Практический пример 3.12: выравнивание трафика Frame
Relay в ответ на получение обратного явного
уведомления о перегрузке (BECN)
Предположим, что сайт электронной коммерции подключен к Internet с помощью
технологии Frame Relay с использованием физического канала Т1. Скорость доступа,
обеспечиваемая поставщиком услуг, составляет 256 Кбит/с, согласованная скорость
передачи информации (CIR) — 64 Кбит/с. Интенсивность исходящего трафика сайта
электронной коммерции должна находиться на уровне 256 Кбит/с при условии нор-
мального режима функционирования сети и сбрасываться до согласованной скорости
передачи 64 Кбит/с при получении обратного явного уведомления о перегрузке
(Backward Explicit Congestion Notification — BECN).
В следующих разделах этой главы рассматривается конфигурация интерфейса маршру-
тизатора сайта электронной коммерции, подключенного к сети поставщика услуг.
Конфигурация механизмов выравнивания трафика GTS и DTS приведена, соответ-
ственно, в листингах 3.23 и 3.24.
Выравнивание интенсивности трафика с помощью
механизма GTS
В листинге 3.23 приведена конфигурация механизма GTS, использующегося для
выравнивания исходящего трафика сайта электронной коммерции.
! Листинг 3.23. Выравнивание интенсивности трафика до 256 Кбит/с
с помощью механизма GTS
interface SerialO/O/O.1 point-to-point
traffic-shape rate 256000
traffic-shape adaptive 64000
Команда traffic-shape adaptive указывает маршрутизатору на необходимость адапта-
ции механизма выравнивания интенсивности трафика к получению серии обратных
явных уведомлений о перегрузке (BECN). При условии нормального функционирова-
ния сети средняя интенсивность исходящего трафика поддерживается на уровне
256 Кбит/с (соответствующая конфигурация механизма GTS достигается с помощью
команды traffic-shape rate). Тем не менее при получении серии обратных явных уве-
домлений о перегрузке (BECN) средняя интенсивность трафика сбрасывается до
64 Кбит/с (рис. 3.13).
82
Часть I. Качество обслуживания в сетях IP
Скорость доступа: 256 Кбит/с
CIR: 64 Кбит/с
Сеть
поставщика услуг
Пересылка трафика
на скорости 256 Кбит/с
I / Пересылка трафика
' ' на скорости 64 Кбит/с
в результате получения
серии уведомлений BECN
Рис. 3.13. Адаптивный механизм выравнивания трафика,
сконфигурированный на интерфейсе Frame Relay
Выравнивание интенсивности трафика с помощью
механизма DTS
В листинге 3.24 приведена конфигурация механизма DTS, использующегося для
выравнивания исходящего трафика сайта электронной коммерции.
i Листинг 3.24. Выравнивание интенсивности трафика до 256 Кбит/с
с помощью механизма DTS
class-map myclass
match any
policy-map mypolicy
class myclass
shape peak 256000 16384 1280
shape adaptive 64000
interface serial0/0/0.1 point-to-point
service-policy output mypolicy
Команда shape adaptive указывает маршрутизатору на необходимость адаптации ме-
ханизма выравнивания интенсивности трафика к получению серии обратных явных
уведомлений о перегрузке (BECN). При условии нормального функционирования се-
ти средняя интенсивность исходящего трафика поддерживается на уровне 256 Кбит/с
(соответствующая конфигурация механизма DTS достигается с помощью команды
shape peak). Тем не менее при получении серии обратных явных уведомлений о пере-
грузке (BECN) средняя интенсивность трафика сбрасывается до 64 Кбит/с.
Глава 3. Формирование трафика на границе сети: классификация... 83
Резюме
Пограничные формирователи трафика выполняют следующие функции качества
обслуживания: классификация пакетов, маркировка пакетов и управление интенсив-
ностью трафика.
Главной целью классификации пакетов, проводимой на границе сети, является созда-
ние предпосылки для дифференцированного обслуживания пакетов внутри сети. Класси-
фикация пакетов является необходимым условием для идентификации различных классов
трафика в зависимости от требуемого уровня обслуживания. IP-пакет может быть класси-
фицирован на основании одного или нескольких полей заголовка. После отнесения пакета
к определенному классу он маркируется посредством установки соответствующего значе-
ния поля IP-приоритета, поля DSCP или поля QoS-группы.
Пограничное управление интенсивностью трафика — это необходимое условие сущест-
вования достаточного количества ресурсов и обеспечения функций качества обслуживания
внутри базовой сети. Для ограничения интенсивности трафика, превышающего заданный
предел, используется механизм согласования скорости доступа (CAR). Механизм CAR до-
пускает пересылку некоторого избыточного объема трафика с линейной интенсивностью,
однако после достижения порогового значения все избыточные пакеты будут отбрасывать-
ся. Механизм выравнивания трафика (TS) “сглаживает” трафик путем буферизации паке-
тов, которые затем пересылаются с согласованной интенсивностью.
Механизм TS является более дружественным для TCP, чем механизм CAR, поскольку
отбрасывание пакетов способно привести к сужению окна TCP-потока до 1, что, в свою
очередь, может стать причиной падения интенсивности TCP-потока ниже допустимого
значения. Подобрав должным образом параметры всплеска, отличающиеся в каждой реа-
лизации протокола TCP, можно обеспечить условия повышения интенсивности ТСР-
потока вплоть до согласованной скорости передачи информации.
Ответы на часто задаваемые вопросы
Можно ли использовать списки доступа для того, чтобы задать критерий совпадения
пакетов на основании значения поля DSCP?
Да. Поддержка списками доступа на основе IP-адреса поля DSCP была впервые
представлена в операционной системе Cisco IOS версии 12.0(7)Т. В приведенном ни-
же примере список доступа 101 используется для того, чтобы задать критерий совпа-
дения всех IP-пакетов со значением поля DSCP, равным 101110 (Expedited
Forwarding — РНВ-политика немедленной передачи).
access-list 101 permit ip any any dscp EF
Существует ли способ маркировки входящих или исходящих по отношению к заданно-
му маршрутизатору Telnet-пакетов путем установки значения поля /Р-приоритета ?
Маркировка входящих или исходящих по отношению к заданному маршрутизатору
Telnet-пакетов путем установки значения поля IP-приоритета может быть осуществ-
лена с помощью команды ip telnet tos. Например, с помощью команды ip telnet tos СО
устанавливается IP-приоритет 6.
Интенсивность трафика ограничена до 1 Мбит/с. Возможно ли превышение интен-
сивности трафика при условии, что согласованная скорость передачи информации под-
держивается на уровне 250 Кбит/с?
84
Часть I. Качество обслуживания в сетях IP
Превышение интенсивности трафика может случиться на очень короткий проме-
жуток времени. В среднем же интенсивность трафика, анализируемого механизмом
CAR, равна 250 Кбит/с.
Как подобрать правильное значение согласованного размера всплеска (В J для меха-
низма CAR?
Однозначного ответа не сушествует. Все зависит от типа потоков трафика и от
уровня сглаживания всплесков.
Для IP- и ICMP-трафика параметры всплеска не играют большой роли, так как
они фактически определяют всего лишь длину промежутка времени, в который ин-
тенсивность трафика будет превышать среднее значение. Поскольку со временем ин-
тенсивность трафика неизбежно ограничивается значением согласованной скорости
передачи информации (CIR), выбор параметров всплеска IP- и ICMP-трафика не яв-
ляется критически важной задачей.
Что же касается протоколов передачи информации, использующих адаптивный ме-
ханизм контроля интенсивности трафика (например, протокол TCP), то отбрасывание
пакета может привести к превышению временного лимита таймера повторной передачи
в устройстве-источнике и уменьшению размера его окна до 1. Несмотря на то что пара-
метры всплеска TCP-потока разнятся в зависимости от реализации TCP в устройстве-
источнике и устройстве-приемнике, ниже приведены рекомендации, касающиеся выбо-
ра оптимальных параметров всплеска механизма CAR:
согласованный размер всплеска = CIR х (1 байт -г- 8 бит) х 1.5 с, где CIR представляет
собой согласованную скорость передачи информации;
расширенный размер всплеска = 2 х согласованный размер всплеска.
Насколько большое значение могут принимать счетчики трафика механизма CAR?
Механизм CAR использует 64-битовые счетчики трафика.
Каким образом механизм CAR накладывает штраф на потоки трафика, интенсив-
ность которых постоянно превышает согласованный размер всплеска (ВJ?
Когда происходит отбрасывание пакета, значение накопленного долга (Dc) об-
нуляется, а значение текущего долга (DA) остается без изменений. При передаче
следующего пакета, требующего заимствования маркеров, новое значение накоп-
ленного долга (Dc) устанавливается равным текущему долгу (DA). Если передача
потока трафика приводит к постоянному заимствованию маркеров, то значение
текущего долга (DA) может очень скоро превысить максимально допустимое зна-
чение (в этом случае для отбрасывания пакета не потребовалось бы даже значе-
ния накопленного долга). Отбрасывание пакетов будет продолжаться до тех пор,
пока значение текущего долга (DA) не уменьшиться до приемлемого уровня бла-
годаря накоплению маркеров.
Может ли сетевой администратор настроить механизм ограничения трафика на
активизацию только в определенный промежуток дня?
Да, для этого ему придется использовать списки доступа с временным критерием
при конфигурации механизма CAR или модульного интерфейса командной строки
QoS. Более подробно списки доступа протокола IP с временным критерием рассмат-
риваются в документации компании Cisco.
Глава 3. Формирование трафика на границе сети: классификация... 85
Какое количество ресурсов процессора маршрутизатора отнимает механизм CAR?
Количество ресурсов процессора маршрутизатора, отнимаемое механизмом CAR, зави-
сит от сложности критерия совпадения трафика и от глубины списка операторов rate-limit.
Критерий совпадения трафика, использующий сложный расширенный список дос-
тупа на основании IP-адреса, является более ресурсоемким по сравнению с критерием
совпадения, использующим относительно простой список доступа. В целом же списки
доступа на основании IP-приоритета и МАС-адреса требуют меньше процессорного
времени, нежели списки доступа на основании IP-адреса.
Поскольку операторы ограничения интенсивности трафика обрабатываются после-
довательно, количество ресурсов процессора маршрутизатора линейно зависит от чис-
ла пройденных операторов rate-limit.
86
Часть I. Качество обслуживания в сетях IP
В этой главе...
Поддержка функций QoS со стороны механизмов
обслуживания очередей 90
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе вычисления порядкового номера пакета 94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе потока 98
Распределенный взвешенный алгоритм равномерного обслуживания
очередей (DWFQ) на основе потока 106
Взвешенный алгоритм равномерного обслуживания очередей (WFQ)
на основе класса 108
Приоритетное обслуживание очередей 115
Заказное обслуживание очередей 118
Механизмы обслуживания очередей, предназначенные
для обработки голосового трафика 123
Глава
4
РНВ-политика: распределение
ресурсов (часть 1)
В моменты перегрузки „ сети распределение ресурсов для отдельного потока
трафика обусловливается порядком обслуживания поставленных в очередь пакетов.
Порядок обслуживания поставленных в очередь пакетов определяет следующий пакет,
который будет извлечен из очереди. Частота обслуживания пакетов, принадлежащих к
одному и тому же потоку трафика, Обусловливает его полосу пропускания (bandwidth)
или распределение ресурсов (resource allocation) для данного потока трафика.
Традиционным для Internet механизмом обслуживания очередей является меха-
низм “первым пришел, первом обслужен” (first-in, first-out — FIFO), в соответствии с
которым пакеты передаются в том.порядке, в котором они были поставлены в выход-
ную очередь. Несмотря на то что механизм FIFO достаточно прост и его легко реали-
зовать, он не способен проводить различие между несколькими потоками трафика.
Следовательно, механизм FIFO не может выделить требуемый объем ресурсов для по-
тока или обеспечить его приоритетную по отношению к другим потокам обработку.
Взвешенный механизм равномерного обслуживания очередей (Weighted Fair Queuing —
WFQ) представляет собой механизм обслуживания очередей с учетом принадлежности
пакетов к тому, или иному классу трафика. В соответствии с механизмом WFQ каждому
потоку трафика назначается определенный вес, обуславливающий частоту обслуживания
пакетов данного потока. Механизм WFQ поддерживает приоритетную обработку пото-
ков с большим весом, а также защиту и равномерное обслуживание потоков с одинако-
вым весом путем применения максиминной схемы равномерного распределения ресур-
сов (max-min fair-share, allocation scheme). В этой главе рассматривается максиминная
схема равномерного распределения ресурсов и ее реализация в виде механизма равно-
мерного обслуживания очередей (Fair Queuing — FQ). Кроме того, здесь приводится де-
тальное описание взвешенного механизма равномерного обслуживания очередей (WFQ).
В главе 5, “РНВ-политика: распределение ресурсов (часть 2)”, рассматривается модифи-
цированный взвешенный алгоритм кругового обслуживания (Modified Weighted Round
Robin — MWRR) и модифицированный алгоритм кругового обслуживания с дефицитом
(Modified Deficit Round Robin — MDRR).
Далее в этой главе обсуждаются две схемы обслуживания очередей — приоритет-
ная и заказная. Приоритетная схема обслуживания очередей предоставляет средства
дифференцирования потоков трафика и их обработки в зависимости от абсолютных
приоритетов потоков, а заказная схема — средства дифференцирования потоков тра-
фика и их обработки по круговому принципу.
В конце этой главы содержится раздел, посвященный механизмам обслуживания
очередей голосового трафика. Следует отметить, что изложенный в этой главе матери-
ал посвящен исключительно вопросам, касающимся выбора пакета, который будет
извлечен из очереди на следующем шаге. Более подробно механизмы обслуживания
очередей (в частности, вопросы, касающиеся политики отбрасывания пакетов), рас-
сматриваются в главе 6, “РНВ-политика: предотвращение перегрузки и политика
отбрасывания пакетов”.
Поддержка функций QoS со стороны
механизмов обслуживания очередей
Динамика передачи пакетов в сети делает ее уязвимой для случайных или посто-
янных перегрузок, наиболее часто возникающих в местах расположения маршрутиза-
торов, объединяющих сети с существенно различающимися полосами пропускания.
В моменты нормального функционирования сети любая схема обслуживания очередей
кажется идеальной, поскольку очередей как таковых в маршрутизаторах попросту нет.
Однако же при перегрузке сети маршрутизаторы начинают проводить буферизацию
пакетов и использовать механизмы обслуживания очередей с целью выбора пакета,
который должен быть обработан на следующем шаге.
Алгоритм обслуживания очередей с поддержкой QoS должен как минимум обла-
дать средством дифференцирования пакетов и средством определения уровня обслу-
живания каждого пакета. Кроме того, подобный алгоритм должен гарантировать каче-
ство обслуживания пакетов путем распределения ресурсов для каждого отдельного по-
тока трафика или с помощью определения относительного приоритета потоков.
Следует отметить, что дифференцирование пакетов может осуществляться как на ос-
новании принадлежности пакета к потоку трафика, так и на основании принадлежно-
сти пакета к классу трафика, включающему в себя, как правило, пакеты из различных
потоков. Более подробно классификация трафика была рассмотрена в главе 3,
“Формирование трафика на границе сети: классификация пакетов, маркировка
пакетов и управление интенсивностью трафика”.
Кроме того, алгоритм обслуживания очередей с поддержкой QoS должен обеспечи-
вать защиту и равномерную обработку всех потоков трафика с одинаковым приорите-
том (например, трафика, доставляемого без гарантий).
Дополнительными требованиями к подобному алгоритму обслуживания очередей
являются легкость реализации и поддержка управления доступом для потоков, нуж-
дающихся в гарантированном предоставлении ресурсов.
Несмотря на то что алгоритм WFQ более сложен в реализации, нежели алгоритм
FIFO, он удовлетворяет всем требования алгоритма обслуживания очередей с под-
держкой QoS (чем, к сожалению, не может похвастаться алгоритм FIFO). Помимо
этого, алгоритм WFQ способен взаимодействовать с протоколом резервирования ре-
сурсов (Resource Reservation Protocol — RSVP) в целях обеспечения управления досту-
пом для потоков, сигнализирующих о требованиях к качеству обслуживания посредст-
вом протокола RSVP. Более подробно протокол резервирования ресурсов рассматри-
вается в главе 7, “Интегрированные услуги: RSVP”, далее в этой книге.
90
Часть I. Качество обслуживания в сетях IP
Примечание
Закон сохранения из теории очередей гласит, что любая дисциплина обслуживания
очередей может уменьшить среднюю задержку потока только за счет увеличения
средней задержки другого потока.
Другими словами, время от времени задержка одних потоков трафика “обменивается”
на предоставление определенной полосы пропускания для других потоков. В то время
как один поток получает преференциальное обслуживание, другой поток неизбежно
страдает от его недостатка.
Алгоритм обслуживания очередей FIFO
FIFO представляет собой механизм обслуживания очередей, в соответствии с которым
порядок постановки пакетов в очередь совпадает с порядком их извлечения из очереди для
обработки (передачи). Очередь механизма FIFO схематически представлена на рис. 4.1.
Очередь FIFO
3 2 1
Рис. 4.1. Очередь FIFO
Как уже говорилось ранее, в соответствии с механизмом обслуживания FIFO порядок
постановки пакетов в очередь совпадает с порядком их извлечения из очереди. На сего-
дняшний день механизм FIFO является наиболее распространенным механизмом обслу-
живания очередей, применяющимся в маршрутизаторах. Его реализация отличается своей
простотой. К сожалению, механизм FIFO не имеет средств дифференцирования потоков
трафика и, следовательно, не может выделить приоритетные потоки. Более того, механизм
FIFO не способен обеспечить равномерное обслуживание потоков трафика с одинаковым
приоритетом и защитить их от подавления потоками с неравномерной интенсивностью.
Последние могут отобрать часть ресурсов у потоков, имеющих постоянную интенсивность
и обслуживающихся сквозными адаптивными схемами управления потоком, такими, как
схема управления динамическим окном протокола TCP (Transmission Control Protocol —
протокол управления передачей). Выясняется, что в соответствии с механизмом FIFO по-
токи трафика обслуживаются почти пропорционально их интенсивности. Подобная схема
обслуживания очередей не является равномерной, поскольку она допускает преобладание
потоков высокой интенсивности над всеми остальными потоками трафика. Любой же рав-
номерный алгоритм обслуживания очередей обеспечивает защиту от потоков с высокой
интенсивностью по своей природе.
Максиминная схема равномерного распределения
ресурсов
Если механизм FIFO не обеспечивает равномерного распределения ресурсов между по-
токами, то какой же должна быть схема равномерного обслуживания очередей? Схемой
равномерного распределения ресурсов, получившей широкое признание, является макси-
минная схема равномерного распределения ресурсов (max-min fair-share allocation scheme).
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
91
Как правило, разные пользователи предъявляют различные требования к ресурсам.
Следовательно, существует возможность классификации пользователей в порядке воз-
растания их требований к ресурсам. Ниже дано определение максиминной схемы
равномерного распределения ресурсов1.
• Ресурсы распределяются в порядке возрастания требований.
• Пользователь не может получить превышающий его потребности объем ресурсов.
• Ресурсы распределяются равномерно между пользователями с неудовлетворен-
ными требованиями.
Рассмотрим пример. Предположим, что общий объем доступного ресурса равен
14 единицам. Требования к ресурсу пользователей А, В, С, D и Е составляют 2, 2, 3, 5 и
6 единиц, соответственно. Распределение ресурса начинается с источника с наименьшими
требованиями, который получает объем ресурса, равный отношению всего запаса ресурса к
общему числу пользователей. Таким образом, в рассматриваемом нами случае пользовате-
лям А и В будет предоставлено 14 + 5 = 2.8 единиц ресурса. Однако требования пользова-
телей А и В составляют всего лишь 2 единицы ресурса. В этом случае избыточный ресурс
объемом 1.6 единиц (по 0.8 единиц с каждого пользователя) равномерно распределяется
между оставшимися тремя пользователями. Таким образом, пользователи С, D и Е полу-
чают по 2.8 + (1.6 + 3) = 3.33 единицы ресурса. Следующим по объему предъявляемых
требований к ресурсам является пользователь С. Требования пользователя С на 0.33 еди-
ницы “скромнее” предлагаемого ему объема ресурсов. Избыточный ресурс объемом 0.33
единицы равномерно распределяется между пользователями С и D, каждый из которых
получает по 3.33 + (0.33 2) = 3.5 единицы ресурса.
Объем ресурсов, предоставляемый пользователю, рассчитывается по следующей
формуле:
объем ресурсов, предоставляемый пользователю = (весь запас ресурсов - объем уже
распределенных ресурсов) + число пользователей, которым все еще требуются ресурсы.
Рассмотренный нами пример наглядно проиллюстрирован на рис. 4.2—4.4. На
шаге 1 (рис. 4.2) требования пользователей А и В удовлетворяются в полном объеме,
так как они не превышают значения, полученного в результате равномерного распре-
деления ресурсов между всеми пользователями.
1 Keshav S. An Engineering Approach to Computer Networking. — Reading, MA: Addison-Wesley, 1997.
92
Часть I. Качество обслуживания в сетях IP
Поскольку требования к ресурсам пользователей С, D и Е превышают 2.8 единиц,
они не могут быть удовлетворены на этом шаге. На следующем шаге объем невостре-
бованных пользователями А и В ресурсов равномерно распределяется между остав-
шимися тремя пользователями — С, D и Е.
На шаге 2 (рис. 4.3) в полном объеме удовлетворяется лишь требование пользова-
теля С как не превышающее значения, полученного в результате равномерного рас-
пределения оставшихся ресурсов между пользователями С, D и Е.
Поскольку требования к ресурсам пользователей D и Е превышают 3.33 единицы,
они не могут быть удовлетворены на этом шаге. На следующем шаге объем невостре-
бованных пользователем С ресурсов равномерно распределяется между оставшимися
двумя пользователями — D и Е.
На шаге 3 (рис. 4.4) значения, полученного в результате равномерного распределе-
ния ресурсов (3.5 единиц), недостаточно для покрытия запроса как пользователя D,
так и пользователя Е, объем неудовлетворенных требований которых составляет 1.5 и
2.5 единиц, соответственно.
Рис. 4.4. Распределение ресурсов для пользователей D и Е
Представленный выше способ распределения ресурсов получил название макси-
минной схемы равномерного распределения ресурсов. Обратите внимание, что все
пользователи с неудовлетворенными требованиями (т.е. с требованиями, объем кото-
рых превышает их максиминную равномерную долю) получают равные объемы ресур-
сов. Максиминная схема равномерного распределения ресурсов получила свое назва-
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
93
ние в связи с тем, что пользователь с неудовлетворенными требованиями получает
максимум из возможных минимальных равномерных долей.
Максиминная схема равномерного распределения ресурсов, в которой каждому
пользователю назначается определенный вес, получила название взвешенной макси-
минной схемы равномерного распределения ресурсов (weighted max-min fair-share allocation
scheme). В соответствии co взвешенной максиминной схемой равномерного распреде-
ления ресурсов каждому пользователю выделяется равномерная доля ресурсов, про-
порциональная его весу.
Обобщенная схема разделения процессорного времени
При обработке потоков трафика, передаваемого по методу негарантированной дос-
тавки (а также всех других равновесных классов трафика), должна применяться схема,
обеспечивающая справедливое обслуживание по типу максиминной схемы равномер-
ного распределения ресурсов. Именно такой схемой и является обобщенная схема
разделения процессорного времени (Generalized Processor Sharing — GPS).
В соответствии со схемой GPS каждый поток трафика помешается в собственную
логическую очередь, после чего бесконечно малый объем данных из каждой непустой
очереди обслуживается по круговому принципу. Необходимость обработки бесконеч-
но малого объема данных на каждом круге обусловлена требованием обслуживания
всех непустых очередей на любом конечном временном интервале. Таким образом,
схема GPS является справедливой в любой момент времени.
Если же всем потокам трафика назначить вес, то объем данных потока, обрабаты-
ваемый на каждом круге, будет пропорционален его весу. Подобное расширение схе-
мы GPS фактически представляет собой взвешенную максиминную схему равномер-
ного обслуживания.
Несмотря на то что GPS является идеальным воплощением максиминной схемы рав-
номерного распределения ресурсов, подобная модель не может быть реализована на прак-
тике. Таким образом, к алгоритму обслуживания очередей, пригодному для практического
использования, выдвигаются два требования: он должен быть как можно более близкой
аппроксимацией схемы GPS и должен быть реализуемым на практике.
Взвешенный алгоритм равномерного
обслуживания очередей (WFQ) на основе
вычисления порядкового номера пакета
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) представляет
собой аппроксимацию схемы GPS, поскольку он моделирует поведение планировщи-
ка GPS без нереализуемого на практике предположения о бесконечно малом объеме
обрабатываемых данных2. Взвешенный алгоритм равномерного обслуживания очере-
дей на основе вычисления порядкового номера пакета имитирует работу GPS-сервера,
обслуживающего в отдельный момент времени 1 байт данных. Алгоритм WFQ доста-
точно хорошо справляется с обработкой пакетов переменной длины, поскольку ему не
нужно знать заранее средний размер пакета в потоке. Основой алгоритма WFQ явля-
2 Demers A., Keshav S., Shenker S. A classical self-locked WFQ algorithm. — SIGCOMM 1989,
Austin, TX, September 1989.
94
Часть I. Качество обслуживания в сетях IP
ется алгоритм FQ, в соответствии с которым все потоки трафика рассматриваются как
равные между собой — т.е. как потоки с одинаковым весом.
Алгоритм FQ моделирует схему GPS путем вычисления порядкового номера каж-
дого полученного пакета. По существу, порядковый номер пакета представляет собой
служебную метку, определяющую относительный порядок обработки пакетов. Поря-
док обслуживания пакетов на основе вычисления порядкового номера эмулирует по-
рядок обслуживания пакетов планировщика GPS.
Для того чтобы интуитивно представить себе механизм моделирования схемы GPS,
введем переменную и назовем ее счетчиком циклов (round number). Значение счетчика
циклов определяет количество выполненных циклов побайтового планировщика кру-
гового обслуживания в заданный момент времени. Отметим, что вычисление поряд-
кового номера пакета зависит от счетчика циклов самым непосредственным образом.
С целью наглядной иллюстрации способа моделирования схемы GPS посредством
алгоритма FQ рассмотрим три потока трафика, А, В и С, размеры пакетов которых
составляют 128, 64 и 32 байт, соответственно. Пакеты поступают один за другим на
загруженный FQ-сервер в порядке Al, А2, АЗ, Bl, С1. Первым на FQ-сервер поступа-
ет пакет А1, затем — пакет А2 и т.д.
Назовем поток активным (active), если хотя бы один из принадлежащих этому по-
току пакетов находится в ожидании обслуживания; в противном случае назовем поток
пассивным (inactive).
Вернувшись к рассмотрению нашего примера, предположим, что системой FQ был по-
лучен пакет А1, принадлежащий пассивному потоку трафика. Полная обработка 128-
байтового пакета побайтовым планировщиком кругового обслуживания займет 128 циклов.
Если на момент получения пакета А1 значение счетчика циклов равнялось 100, то после
полной передачи пакета А1 это значение станет равным 100 + 128 = 228. Отсюда порядко-
вый номер пакета, принадлежащего пассивному потоку, рассчитывается как сумма счетчи-
ка циклов и размера пакета в байтах. По сути, порядковый номер пакета представляет со-
бой номер цикла, в который осуществляется передача его (пакета) последнего байта. По-
скольку в действительности планировщик за один раз проводит передачу всего пакета, а не
его одного байта, он обслуживает весь пакет вне зависимости от того, сравнялся ли счет-
чик циклов с порядковым номером пакета.
Когда система FQ получит пакет А2, он уже будет принадлежать активному потоку
трафика благодаря наличию в очереди пакета А1 с порядковым номером 228. Поряд-
ковый номер пакета А2 равняется 228 + 128 = 356, поскольку он должен быть передан
после пакета А1. Отсюда, порядковый номер пакета, принадлежащего активному по-
току, рассчитывается как сумма наибольшего порядкового номера пакета, поставлен-
ного в очередь этого потока, и размера пакета в байтах.
Аналогичным образом, пакету АЗ назначается порядковый номер 356 + 128 = 484.
Поскольку пакеты В1 и С1 принадлежат пассивному потоку трафика, их порядковые
номера равняются 164 (100 + 64) и 132 (100 + 32), соответственно.
Ниже приведены формулы, по которым производится расчет порядкового номера
пакета (Sequence Number — SN) в зависимости от его принадлежности активному или
пассивному потоку трафика.
Для пакетов, принадлежащих пассивному потоку трафика,
порядковый номер = размер пакета в байтах + значение счетчика циклов на момент
поступления пакета (значение счетчика циклов равняется порядковому номеру по-
следнего обслуженного пакета).
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
95
Для пакетов, принадлежащих активному потоку трафика,
порядковый номер = размер пакета в байтах + значение наибольшего порядкового но-
мера пакета, поставленного в очередь этого потока.
Для более наглядной иллюстрации моделирования схемы GPS посредством алго-
ритма FQ на рис. 4.5 схематически представлены очереди пакетов с соответствующи-
ми им (пакетам) порядковыми номерами.
Счетчик циклов/порядковый номер пакета
Счетчик циклов: 100
С1 В1 АЗ А2 А1 —►
---► АЗ А2 А1 В1
Планировщик FQ
Рис. 4.5. Пример моделирования побайтового GPS-планировщика кругового обслуживания посредст-
вом алгоритма FQ
GPS-планировщик завершит обслуживание пакета А1 на 228-м цикле. Напомним,
что порядковый номер пакета определяет очередность обработки пакетов планиров-
щиком. В данном случае планировщик FQ обслуживает пакеты в таком порядке: С1,
Bl, Al, А2, АЗ.
Счетчик циклов используется исключительно для вычисления порядкового номера
пакетов, принадлежащих новым (пассивным) потокам трафика. Порядковый номер
пакетов, принадлежащих активным потокам трафика, рассчитываются с учетом наи-
96
Часть I. Качество обслуживания в сетях IP
большего порядкового номера пакета, поставленного в очередь этого потока. Таким
образом, если пакет А4 будет принят до обслуживания пакета АЗ, то его порядковый
номер будет равняться 484 + 128 = 612.
Следует отметить, что счетчик циклов обновляется при передаче каждого очеред-
ного пакета, при этом его новое значение равняется порядковому номеру пакета, ко-
торый передается. Таким образом, если 32-байтовый пакет D1, принадлежащий ново-
му потоку трафика, будет принят в момент передачи пакета А1, значение счетчика
циклов будет равняться 228, а порядковый номер пакета D1 — 260 (228 + 32). По-
скольку порядковый номер пакета D1 меньше порядковых номеров пакетов А2 и АЗ,
он будет передан раньше этих пакетов. Изменение в порядке обслуживания пакетов
схематически изображено на рис. 4.6.
Очередь А
АЗ (128)
А2(128)
D1
(32)
Очередь D
.484
“Г—
500
“Г
400
356
Г
зоо
^260.228
J—'—Г
200
~т~
юо
Счетчик циклов/порядковый номер пакета
D1 ...АЗ А2
„ . Счетчик циклов: 228
Очередь А
---► АЗ А2 D1
Планировщик FQ
Рис. 4.6. Изменение в порядке обслуживания пакетов, вызванное поступлением пакета DI в
момент передачи пакета АI
Довольно типичной является ситуация, в которой одни потоки трафика рассматри-
ваются как более приоритетные по сравнению с другими. Естественно, что плани-
ровщик должен отдавать подобным потокам предпочтение перед другими, менее важ-
ными, потоками трафика. Этого можно достичь, назначив каждому потоку вес, про-
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
97
порционально которому и будет обслуживаться поток. Такое расширение алгоритма
равномерного обслуживания очередей (FQ) получило название взвешенного алгорит-
ма равномерного обслуживания очередей (WFQ) на основе потока.
Взвешенный алгоритм равномерного
обслуживания очередей (WFQ)
на основе потока
В соответствии с механизмом WFQ вес пакета определяется на основании значе-
ния поля IP-приоритета в заголовке пакета. Ниже приведена формула для расчета ве-
са IP-пакета:
вес = 4096 + (IP-npuopumem + 1).
Примечание
Учитывая недавние изменения в реализации алгоритма WFQ, предыдущая формула
для расчета веса потока применима лишь в операционных системах IOS версии
12.0(4)Т и ниже. Изменения в реализацию алгоритма WFQ быпи внесены с цепью
поддержки взвешенного алгоритма равномерного обслуживания очередей на основе
класса трафика (Class-Based Weighted Fair Queuing — CBWFQ). Более подробно ал-
горитм CBWFQ рассматривается дапее в этой главе.
В операционных системах IOS версии 12.0(5)Т и выше рассматриваемый в этой главе
WFQ-вес потока умножается на 8. Следовательно, WFQ-вес трафика, передаваемого
без гарантий (IP-приоритет 0), равняется
4096 х 8 = 32768,
а формула для расчета веса пакета принимает следующий вид:
вес = 32768 + (IP-npuopumem + 1).
Зависимость веса пакета от значения поля IP-приоритета и байта типа обслуживания
(Type of Service — ToS) показана в табп. 4.1.
Таблица 4.1. Зависимость веса пакета, принадлежащего не RSVP-потоку
трафика, от значения поля IP-приоритета
IP-приоритет
Значение байта ToS
Вес
I0S версии ниже 12.0(5)Т I0S версии 12.0(5)Т
и выше
0 0(0x00) 4096 32768
1 32 (0x20) 2048 16384
2 64 (0x40) 1365 10920
3 96 (0x60) 1024 8192
4 128(0x80) 819 6552
5 160 (ОхАО) 683 5456
6 192 (ОхСО) 585 4680
7 224 (ОхЕО) 512 4096
98
Часть I. Качество обслуживания в сетях IP
Вес RSVP-потока с максимальным резервированием полосы пропускания равен 4 в
IOS версии ниже 12.0(5)Т и 6 в IOS версии 12.0(5)Т и выше. Вес всех остальных заре-
зервированных RSVP-потоков рассчитывается на основании максимального резерви-
рования полосы пропускания, как показано ниже.
Вес RSVP-потока (RSVP-диалога) = наибольшее резервирование полосы пропуска-
ния канала х (максимальное резервирование полосы пропускания канала + полоса
пропускания диалога).
При изложении материала в оставшейся части этого раздела будет использоваться
система весов операционных систем IOS версии ниже 12.0(5)Т. Следует отметить, что
в контексте объяснения принципов функционирования алгоритма WFQ конкретный
метод расчета веса не имеет значения.
Алгоритм WFQ использует два параметра для определения порядкового номера па-
кета. Подобно алгоритму FQ, одним из параметров является размер пакета в байтах.
К тому же алгоритм WFQ учитывает назначенный пакету вес. Порядковый номер па-
кета равняется произведению его размера в байтах и веса пакета. Это и есть единст-
венное отличие алгоритмов WFQ и FQ.
Следует отметить, что прямое соответствие между побайтовым планировщиком
кругового обслуживания и алгоритмом FQ теряется в алгоритме WFQ, поскольку
перед вычислением порядкового номера пакета счетчик циклов умножается на его
(пакета) вес. Другими словами, в соответствии с алгоритмом WFQ порядковый
номер пакета определяет относительное положение пакета в WFQ-планировщике,
а счетчик циклов — порядковый номер последнего обслуженного WFQ-
планировщиком пакета.
Вернемся к рассмотрению примера, приведенного в предыдущем разделе этой гла-
вы, и предположим, что пакеты потока А имеют приоритет 5, а пакеты потоков В и
С — приоритет 0. В соответствии с алгоритмом WFQ пакетам потока А назначается
вес 683, а пакетам потоков В и С — вес 4096. Все параметры потоков, рассматривае-
мых в данном примере, приведены в табл. 4.2.
Таблица 4.2. Пример работы взвешенного алгоритма равномерного
обслуживания очередей (WFQ) на основе потока
Очередь Размер пакета Приоритет Вес = 4096 + (IP-приоритет +1)
Очередь А 128 5 683
Очередь В 64 0 4096
Очередь С 32 0 4096
Порядковый номер пакета AI равняется 100 + (683 х 128) = 87524. Аналогичным
образом рассчитываются порядковые номера пакетов А2, АЗ, В1 и С1, равные 174948,
262372, 262244 и 131172, соответственно. Таким образом, планировщик WFQ обслу-
живает полученные пакеты в порядке А1, С1, А2, В1, АЗ, как показано на рис. 4.7.
Следует отметить, что с помощью алгоритма WFQ вы можете установить более вы-
сокий приоритет потока А, однако не можете обеспечить равномерное обслуживание
потоков В и С. Фактически планировщик WFQ моделирует максиминную взвешен-
ную схему GPS.
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
99
Счетчик циклов: 100
Очередь А (вес 683)
262372 174948 87524
А4 (128) АЗ (128) А2 (128)
С1 В1 АЗ А2 А1 —►
262244
Очередь В (вес 4096) В1 (64)
131172
С1
Очередь С (вес 4096) (32)
АЗ В1 А2 С1 А1
Рис. 4.7. Иллюстрация работы взвешенного алгоритма равномерного обслуживания очередей (WFQ)
на основе потока
Если пакеты А4 и D1 (новый поток с приоритетом 0 и размером пакета 32 байт)
будут получены после обработки планировшиком WFQ пакета А1, им будут назначе-
ны порядковые номера 349796 ((683 х 128) + 262372) и 218596 ((4096 х 32) + 87524),
соответственно. Соображения по поводу вычисления порядковых номеров пакетов А4
и D1, высказывавшиеся в предыдущем разделе при рассмотрении алгоритма FQ, мо-
гут быть отнесены и к алгоритму WFQ. Теперь планировщик WFQ будет обслуживать
оставшиеся пакеты в следующем порядке: Cl, А2, D1, В1, АЗ и А4 (рис. 4.8).
Рис. 4.8. Изменение в порядке обслуживания пакетов, вызванное поступлением пакетов DI и А4
Пакет D1 был получен практически сразу же после обработки планировшиком
WFQ пакета А1. Отметим, что пакет D1 будет передан перед пакетами АЗ и А4, кото-
рые были поставлены в очередь раньше.
Примечание
Порядковый номер пакета, поступившего на интерфейс, вычисляется только в случае
перегрузки выходного интерфейса в результате переполнения буфера аппаратной
100
Часть I. Качество обслуживания в сетях IP
очереди. Если же выходной интерфейс не перегружен, применяется алгоритм обслу-
живания очередей FIFO, в соответствии с которым входящий пакет попросту ставится
в аппаратную очередь передачи выходного интерфейса.
Длина аппаратной очереди передачи интерфейса определяет максимальную задерж-
ку очереди трафика масштаба реального времени для планировщика WFQ. Прежде
чем начать передачу пакетов трафика масштаба реального времени (например, голо-
сового трафика), маршрутизатор должен передать все находящиеся на текущий мо-
мент в аппаратной очереди пакеты. Чрезмерная задержка очереди может привести к
дрожанию трафика — явлению, очень негативному в контексте передачи информации
масштаба реального времени (например, оцифрованной речи). Стандартный аппа-
ратный буфер интерфейса может вместить от одного до пяти пакетов. В соответствии
с реализацией операционной системы IOS, большинство интерфейсов автоматически
уменьшают размер своей аппаратной очереди до 2 при условии применения алгорит-
ма WFQ. Сетевой оператор должен иметь возможность изменять размеры аппарат-
ных очередей интерфейсов в зависимости от существующих требований к задержке
трафика. Это утверждение особенно справедливо для трафика масштаба реального
времени, такого, как голосовой трафик. Размер аппаратной очереди интерфейса мо-
жет быть изменен с помощью команды tx-queue-limit.
Взаимодействие механизма WFQ с протоколом RSVP
Протокол RSVP нуждается в поддержке со стороны планировщика с целью гаранти-
рованного резервирования полосы пропускания. Механизм WFQ обладает средствами
взаимодействия с запросами резервирования ресурсов (RESV-запросами) протокола
RSVP. Так, данный механизм поддерживает резервные очереди диалогов с весом, соот-
ветствующим резервируемой на основании запроса протокола RSVP полосе пропуска-
ния. Более подробно протокол RSVP рассматривается в главе 7, “Интегрированные
услуги: RSVP”, далее в этой книге. Число резервируемых очередей диалогов является
настраиваемым параметром.
Реализация алгоритма WFQ
В соответствии со взвешенным алгоритмом равномерного обслуживания оче-
редей (WFQ) на основе потока вес пакета строго зависит от его приоритета и не
может быть изменен. Несмотря на то что реализации алгоритма FQ не существу-
ет, с практической точки зрения алгоритм WFQ совпадает с алгоритмом FQ при
условии равенства IP-приоритета всех пакетов, поступающих на обработку WFQ-
планировщику.
Планировщик взвешенного алгоритма равномерного обслуживания очередей
(WFQ) на основе потока не нарушает порядка обработки пакетов, принадлежащих
одному потоку, даже в том случае, если они имеют различный приоритет. С этой
целью поток реализуется в виде хэша, определяемого IP-адресом источника, IP-
адресом назначения, полем протокола IP, номерами портов Transmission Control
Protocol/User Datagram Protocol (TCP/UDP) и пятью битами (за исключением
трех битов IP-приоритета) байта ToS. Согласно с таким определением, пакеты
одного потока с различными значениями поля IP-приоритета попадают в одну и
ту же очередь. Очередь потока обслуживается в соответствии с алгоритмом FIFO.
Следует отметить, что алгоритм WFQ отбрасывает пакеты только наиболее ак-
тивных потоков трафика, в то время как алгоритм FIFO готов отбросить пакет
Глава 4. РНВ-политика: распределение ресурсов (часть 1) 101
любого потока. Другими словами, алгоритм WFQ пытается уменьшить интенсив-
ность активных потоков трафика, не нанося при этом ушерба менее активным
потокам. Поскольку средняя длина потока трафика в Internet равняется 10-20 па-
кетам, алгоритм WFQ “наказывает” всего лишь весьма незначительный процент
потоков, в то время как алгоритм FIFO “действует без разбора”. Таким образом,
для трафика с адаптивным управлением потоком (например, для ТСР-трафика)
эффект глобальной синхронизации будет выражен менее ярко в случае примене-
ния алгоритма WFQ, по сравнению с алгоритмом FIFO. Более подробно глобаль-
ная синхронизация и политика превентивного отбрасывания пакетов рассматри-
ваются в главе 6, “РНВ-политика: предотвращение перегрузки и политика
отбрасывания пакетов”, далее в этой книге.
Взвешенный механизм равномерного обслуживания очередей (WFQ) на основе
потока использует для обработки каждого потока трафика так называемую подо-
чередь. Учитывая это обстоятельство, очереди механизма WFQ на основе потока
называются также очередями диалога (conversation queue). Поскольку память явля-
ется конечным ресурсом, число очередей диалога по умолчанию ограничено 256.
Несмотря на это, данный параметр является настраиваемым в случае применения
интерфейсной команды fair-queue. Обратите внимание, что увеличение количества
очередей приводит к увеличению памяти, требующейся для размещения структур
данных очередей, а также к увеличению объема поддерживаемой маршрутизато-
ром информации о состоянии системы. Если число потоков превысит число оче-
редей, допускается использование одной очереди для обработки нескольких пото-
ков. Следует отметить, что увеличение числа очередей естественным образом
уменьшает шансы подобного развития ситуации (т.е. вы можете быть уверены в
том, что каждому потоку соответствует своя собственная очередь).
Взвешенный механизм равномерного обслуживания очередей (WFQ) на основе
потока может функционировать в связке со взвешенным механизмом произволь-
ного раннего обнаружения (Weighted Random Early Detection — WRED) — полити-
кой превентивного отбрасывания пакетов во избежание перегрузки сети. Более под-
робно алгоритм WRED рассматривается в главе 6, “РНВ-политика: предотвращение
перегрузки и политика отбрасывания пакетов”, далее в этой книге.
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе по-
тока реализован на базе алгоритма сортировки списков. Сложность подобного алго-
ритма составляет О(и), где п — это количество пакетов, ожидающих обслуживания
WFQ-планировщиком. Следует отметить, что сортировка списков может отнять непо-
зволительно большое количество ресурсов маршрутизатора, подключенного к каналам
с широкой полосой пропускания, поскольку в этом случае число потоков трафика и
число обрабатываемых в секунду пакетов очень велико.
Примечание
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе потока
реализован в большинстве маршрутизаторов Cisco. Одно из наиболее заметных ис-
ключений составляют маршрутизаторы Cisco серии 12000. Механизм обслуживания
очередей WFQ на основе потока является стандартным для всех интерфейсов с по-
лосой пропускания ниже 2 Мбит/с.
102
Часть I. Качество обслуживания в сетях IP
Практический пример 4.1: взвешенный механизм
равномерного обслуживания очередей (WFQ)
на основе потока
Высокоприоритетный трафик время от времени испытывает задержку, вызванную
передачей низкоприоритетного трафика, поскольку пакеты всех активных потоков
выглядят одинаково в выходной очереди маршрутизатора, использующего алгоритм
обслуживания очередей FIFO. С целью обеспечения дифференцирования пакетов на
основе требований к обслуживанию сетевой администратор начинает устанавливать
значение поля IP-приоритета входящих пакетов в зависимости от важности соответст-
вующего потока трафика. Кроме этого, сетевой администратор конфигурирует взве-
шенный механизм равномерного обслуживания очередей (WFQ) на основе потока, в
соответствии с которым:
• активные потоки трафика с одинаковым IP-приоритетом получают равные доли
полосы пропускания интерфейса;
• активные потоки с большим IP-приоритетом получают большую долю полосы
пропускания интерфейса, нежели активные потоки с меньшим IP-приоритетом.
После установки значения поля IP-приоритета для всего входящего трафика мож-
но начинать конфигурирование взвешенного алгоритма равномерного обслуживания
очередей (WFQ) на основе потока в маршрутизаторах сети. Классификация пакетов на
основе установки значения поля IP-приоритета рассматривалась в главе 3,
“Формирование трафика на границе сети: классификация пакетов, маркировка
пакетов и управление интенсивностью трафика”.
Конфигурация взвешенного алгоритма равномерного обслуживания очередей
(WFQ) на основе потока осуществляется с помощью интерфейсной команды fair-
queue. В листинге 4.1 приведен результат выполнения команды show queue, исполь-
зующейся для вывода на экран списка активных потоков, глубины очереди, веса по-
тока, а также другой статистической информации. Кроме этого, команда show queue
используется для отображения параметров очереди WFQ-системы.
> Листинг 4.1. Результат выполнения команды show queue serialO
Router#show queue serialO
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 9/1000/120/0 (size/max total/threshold/drops)
Conversations 1/4/256 (active/max active/threshold)
Reserved Conversations 0/1 (allocated/max allocated)
(depth/weight/discards/tail drops/interleaves) 2/4096/0/0/0
Conversation 1044, linktype: ip, length: 1504
source: 172.26.237.58, destination: 172.26.237.2, id: 0xC4FE,
ttl:126, TOS: 0 prot: 6, source port 1563, destination port 4665
Параметр max total из листинга 4.1 представляет собой глобальное ограничение
размера буфера механизма WFQ для данного интерфейса, в то время как значение па-
раметра threshold отражает максимальный размер буфера для отдельного диалога.
Глава 4. РНВ-политика: распределение ресурсов (часть 1) 103
Следует отметить, что значение параметра max total совпадает с размером выходной
очереди удержания и, как следствие, может быть изменено с помощью интерфейсной
команды hold-queue <длина очереди> out. Назовем диалог активным (active), если дли-
на его очереди отлична от нуля. Параметры active и max active отражают текущее и
максимальное число активных диалогов, соответственно. Количество зарезервирован-
ных потоков RSVP указано в строке Reserved Conversations.
Проанализируем вторую часть листинга 4.1. Параметр depth представляет собой
число ожидающих обслуживания пакетов в очереди диалога (параметры которого на-
ходятся строкой ниже), а параметр weight — вес, назначенный данному потоку трафи-
ка. Отбрасывание пакета (параметр discards) осуществляется в момент превышения
размера очереди диалога порогового значения, а так называемое “отбрасывание хво-
ста” (параметр tail drops) — в момент превышения размера WFQ-буфера значения
параметра max total. Если WFQ-буфер будет переполнен, то любой пакет, пришедший
в “хвост” полной очереди, будет немедленно отброшен. Чередование пакетов
(параметр interleaves) происходит при условии соответствующей настройки механиз-
мов фрагментации и чередования пакетов канального уровня, позволяющей переда-
вать пакеты небольшого объема между фрагментами больших пакетов. Чередование
пакетов позволяет уменьшить флуктуацию времени задержки для потоков трафика,
состоящих из пакетов небольшого объема.
Примечание
Статистика очереди отображается при условии наличия в ней на момент выполнения
команды show queue хотя бы одного пакета. В противном случае диалог считается
пассивным, а на экран никакая информация не выводится. Следовательно, выполне-
ние команды show queue не приведет к выводу на экран каких-либо сведений, если
соответствующий интерфейс маршрутизатора недостаточно загружен.
Команда show queueing fair используется для вывода на экран параметров сконфи-
гурированного на интерфейсе механизма WFQ. В листинге 4.2 приведен результат
выполнения команды show queueing fair.
> Листинг 4.2. Результат выполнения команды show queueing fair
RouterHshow queueing fair
Current fair queue configuration:
Interface Discard Dynamic Reserved
threshold queue count queue count
SerialO 64 256 0
Практический пример 4.2: распределение полосы
пропускания в зависимости от веса потока
На последовательном интерфейсе со сконфигурированным взвешенным алгоритмом
равномерного обслуживания очередей (WFQ) на основе потока обрабатывается 8 потоков
трафика — по одному на каждое значение IP-приоритета. Как изменится распределение
полосы пропускания для каждого потока, если на последовательном интерфейсе будут об-
104
Часть I. Качество обслуживания в сетях IP
рабатываться 25 потоков трафика — 18 потоков с IP-приоритетом 1 и по одному потоку на
каждое оставшееся значение IP-приоритета?
Как отмечалось ранее в этой главе, ширина полосы пропускания, выделенной по-
току трафика, обратно пропорциональна его весу. В соответствии со взвешенным ал-
горитмом равномерного обслуживания очередей (WFQ) на основе потока вес потока
рассчитывается по следующей формуле:
вес = 4096 -в (IP-npuopumem + 1).
Следовательно, ширина полосы пропускания, выделенной для потока трафика,
прямо пропорциональна величине (IP-приоритет + 1).
Каждому потоку трафика выделяется часть доступной полосы пропускания канала
пропорционально величине (Р + 1), где Р — это IP-приоритет пакетов потока. Ко-
нечное значение выделенной потоку полосы пропускания зависит от других потоков,
разделяющих между собой данный канал передачи информации.
В первом случае мы имеем дело с 8 потоками — по одному на каждое значе-
ние IP-приоритета. Поток трафика с IP-приоритетом 0 получает
1-ь(1 + 2 + 3 + 4 + 5 + 6 + 7 + 8)= 1/36 полосы пропускания канала, поток
трафика с IP-приоритетом 1 — 2/36 полосы пропускания канала, поток трафика с
IP-приоритетом 2 — 3/36 полосы пропускания канала и т.д.
Во втором случае число потоков возрастает до 25 — 18 потоков с IP-
приоритетом 1 и по одному потоку на каждое оставшееся значение IP-
приоритета. Теперь каждый поток трафика с IP-приоритетом 0 получает всего
лишь 1-*-(1+(2х18) + 3 + 4 + 5 + 6+ 7 + 8)= 1/70 полосы пропускания канала,
каждый поток трафика с IP-приоритетом 1 — 2/70 полосы пропускания канала и т.д.
Практический пример 4.3: одновременное обслуживание
WFQ-планировщиком потоков голосового трафика
и FTP-трафика
По каналу DS3 поставщика услуг Internet (Internet Service Provider — ISP) передается
голосовой трафик и трафик протокола FTP (File Transfer Protocol — протокол передачи
файлов). Голосовой трафик испытывает неравномерные задержки, вызванные передачей
относительно больших FTP-пакетов различного объема. Сетевые инженеры полагают,
что ситуацию можно исправить путем замены алгоритма обслуживания очередей FIFO
классическим алгоритмом WFQ, однако они не уверены, что при этом будет обеспечено
равномерное обслуживание голосового трафика наравне с трафиком FTP.
Голосовой трафик состоит из 64-байтовых пакетов, обозначенных VI, V2, V3 и
т.д., а FTP-трафик — из 1472-байтовых пакетов, обозначенных Fl, F2, F3 и т.д.
В оставшейся части этого раздела рассматривается распределение ресурсов для
голосового трафика (обрабатываемого параллельно с FTP-трафиком) в соответст-
вии с алгоритмами FQ и WFQ.
В первом случае значение поля IP-приоритета не задано ни для одного пакета.
Таким образом, весь поступающий по каналу DS3 трафик имеет стандартный IP-
приоритет 0. 64-байтовые пакеты голосового трафика обслуживаются равномерно
наряду с пакетами FTP-трафика. В момент, когда оба потока являются активны-
ми, FQ-планировщик обслуживает в среднем один FTP-пакет на 23 ( = 1472 -5- 64)
пакета голосового трафика.
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
105
Во втором случае голосовой трафик имеет IP-приоритет 5, а FTP-трафик — IP-
приоритет 0. В соответствии с алгоритмом WFQ пакетам голосового трафика назнача-
ется вес меньший, чем вес пакетов FTP-трафика. Голосовой трафик получает 6/7, а
FTP-трафик — 1/7 часть полосы пропускания канала. Другими словами, ширина по-
лосы пропускания голосового трафика в 6 раз больше, чем ширина полосы пропуска-
ния трафика FTP. Учитывая различие в размерах пакетов в момент, когда оба потока
являются активными, FQ-планировшик обслуживает в среднем один FTP-пакет на
138 ( = 23 х 6) пакетов голосового трафика!
Примечание
По существу, алгоритм WFQ не позволяет отдать абсолютный приоритет какому-либо
потоку трафика. Как было показано в предыдущем примере, все, на что способен
данный алгоритм, — это выделить больший объем ресурсов или обеспечить гаранти-
рованную полосу пропускания. Следовательно, этот алгоритм ни при каких условиях
не способен быть идеальным решением для обслуживания трафика интерактивных
приложений, выполняющихся в масштабе реального времени. Что касается голосово-
го трафика, то алгоритм WFQ способен обеспечить его должное обслуживание только
при наличии в сети сравнительно небольшого объема низкоприоритетного трафика.
К сожалению, в сильно перегруженных сетях алгоритм WFQ не может удовлетворить
требований, касающихся уровня дрожания голосового трафика интерактивных прило-
жений. Для обслуживания трафика приложений такого типа используется модифици-
рованный алгоритм WFQ— алгоритм WFQ с приоритетной очередью (Priority
Queue— PQ). Более подробно алгоритм WFQ с приоритетной очередью рассматри-
вается ближе к концу этой главы.
Распределенный взвешенный алгоритм
равномерного обслуживания очередей (DWFQ)
на основе потока
Распределенный взвешенный алгоритм равномерного обслуживания очередей
(DWFQ) на основе потока (Flow-Based Distributed WFQ) выполняется в распреде-
ленном режиме на маршрутизаторах Cisco серии 7500, построенных на базе интер-
фейсных плат VIР (Versatile Interface Processor — универсальный интерфейсный
процессор), оснащенных встроенными процессорами. Сконфигурированный на ин-
терфейсе маршрутизатора механизм DWFQ на основе потока выполняется процес-
сором линейной платы V1P данного интерфейса, а не центральным процессором
маршрутизатора (как механизм WFQ). Поддержка распределенного взвешенного
алгоритма равномерного обслуживания очередей (DWFQ) на основе потока требует
от маршрутизатора поддержки распределенного механизма скоростной коммутации
пакетов Cisco (Distributed Cisco Express Forwarding — DCEF). Более подробно рас-
пределенный механизм скоростной коммутации пакетов Cisco рассматривается в
приложении Б, “Механизмы коммутации пакетов”.
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе по-
тока использует для хранения пакетов отсортированный связанный список. Вновь
прибывшие пакеты заносятся в этот список в соответствии с присвоенными им по-
рядковыми номерами. Что касается распределенного алгоритма равномерного обслу-
106
Часть I. Качество обслуживания в сетях IP
живания очередей (DWFQ) на основе потока, то для выполнения функции сортиров-
ки он использует так называемые календарные очереди. Календарные очереди алго-
ритма DWFQ на основе потока аппроксимируют механизм GPS посредством алгорит-
ма, менее сложного, нежели простой алгоритм сортировки списка. В отличие от стан-
дартных алгоритмов вставки элемента в список, имеющих сложность О(и),
календарные очереди позволяют осуществлять вставку элемента с затратами 0(1), что
очень существенно для высокоскоростных интерфейсов маршрутизатора. Несмотря на
то что календарные очереди выглядят эффективнее в терминах использования ресур-
сов центрального процессора, они более требовательны к объему памяти. Таким обра-
зом, сетевому администратору приходится идти на компромисс, выбирая между воз-
росшими требованиями к ресурсам памяти и ограничениями, накладываемыми в ре-
зультате использования меньшего количества календарных очередей.
Для всех вновь прибывших пакетов вычисляются временнь/е метки, которые
сортируются с использованием календарной очереди. Степень детализации времен-
ных меток в любой реализации алгоритма, использующего календарные очереди,
ограничена числом присутствующих в системе календарных очередей. Для аппрок-
симации взвешенного алгоритма равномерного обслуживания очередей (WFQ) на
основе потока количество календарных очередей должно равняться
4096 х максимальный размер единицы передачи информации для данного интер-
фейса (Maximum Transmission Unit — MTU)!
Поскольку число календарных очередей не позволяет достичь степени детализа-
ции, разрешающей иметь уникальные временные метки пакетов размером от одного
байта до MTU байтов, пакеты различных размеров, принадлежащие пото-
кам/классам с одним и тем же весом, могут иметь равные метки. С целью обеспе-
чения надлежащего распределения полосы пропускания канала пакеты различных
размеров с одинаковыми метками должны обслуживаться посредством алгоритма с
дефицитом. В связи с этим часть механизма DFWQ имеет характеристики механиз-
ма кругового обслуживания с дефицитом (Deficit Round Robin — DRR). Более под-
робно алгоритм DRR рассматривается в главе 5, “РНВ-политика: распределение
ресурсов (часть 2)”, далее в этой книге.
Реализация алгоритма DWFQ предусматривает наличие ограничения на размер от-
дельной очереди и совокупного ограничения на размер всех очередей системы. Огра-
ничение на размер отдельной очереди применяется только в случае достижения сово-
купного ограничения на размер всех очередей системы.
Фактически распределенный взвешенный алгоритм равномерного обслуживания
очередей (DWFQ) на основе потока является не чем иным, как классическим алго-
ритмом FQ. В соответствии с алгоритмом FQ все потоки имеют одинаковый приори-
тет и не имеют веса. Алгоритм DWFQ на основе потока реализует поток в виде хэша,
определяемого IP-адресом источника, IP-адресом назначения, полем протокола IP и
номерами портов Transmission Control Protocol/User Datagram Protocol (TCP/UDP).
Весь трафик, отличный от трафика IP, рассматривается как один поток и, следова-
тельно, помещается в одну и ту же очередь.
По причинам, рассматривавшимся в разделе, посвященном механизму WFQ на
основе потока, количество подочередей распределенного взвешенного алгоритма рав-
номерного обслуживания очередей (DWFQ) на основе потока ограничено. Общее
число очередей механизма DWFQ на основе потока равняется 512. Если на интерфей-
се одновременно обрабатываются более чем 512 потоков трафика, то некоторые из
них разделяют одну подочередь.
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
107
Практический пример 4.4: распределенный взвешенный
алгоритм равномерного обслуживания очередей (DWFQ)
на основе потока
Крупная компания обнаружила, что в сети, где планируется переход на обслужи-
вание пакетов в зависимости от их IP-приоритета, активные потоки трафика данных с
большим размером пакетов негативно влияют на передачу трафика транзакций, со-
стоящего из пакетов сравнительно небольшого объема. Сетевой инженер компании
намеревается изолировать потоки трафика, с тем чтобы каждый из них получил рав-
ноценную долю полосы пропускания.
Распределенный взвешенный алгоритм равномерного обслуживания очередей
(DWFQ) на основе потока обеспечивает как изолирование, так и защиту активных по-
токов трафика. В случае применения этого алгоритма все активные потоки получат
равноценные доли доступной полосы пропускания.
Конфигурация распределенного взвешенного алгоритма равномерного обслужива-
ния очередей (DWFQ) на основе потока осуществляется с помощью интерфейсной
команды fair-queue на маршрутизаторе серии 7500, построенном на базе интерфейс-
ных плат VIР. В строке, выводимой на экран в результате выполнения команды show
interface, равномерное обслуживание очереди с помощью интерфейсной платы VIP
указано в качестве стратегии обслуживания очередей данного интерфейса. Параметры
механизма DWFQ на основе потока показаны в листинге 4.3.
; Листинг 4.3. Параметры распределенного взвешенного алгоритма равно-
' мерного обслуживания очередей (DWFQ) на основе потока
Routerflshow interface fair
POSO/O/O queue size 0
packets output 2, wfq drops 1, nobuffer drops 0
WFQ: aggregate queue limit 5972, individual queue limit 2986
max available buffers 5972
Результатом выполнения команды show interface fair является отображение стати-
стики переданных пакетов, а также статистики пакетов, отброшенных в результате пе-
реполнения DWFQ-буфера.
Примечание
Объем DWFQ-буфера, ограничение на размер отдельной очереди и совокупное огра-
ничение на размер всех очередей зависит от объема установленного на VIP-плате
статического ОЗУ (Static Random Access Memory — SRAM), количества интерфейсов
VIP-платы и пропускной способности этих интерфейсов.
Взвешенный алгоритм равномерного
обслуживания очередей (WFQ) на основе класса
В предыдущих двух разделах этой главы были рассмотрены два алгоритма обслужи-
вания очередей: взвешенный алгоритм равномерного обслуживания очередей (WFQ) на
108
Часть I. Качество обслуживания в сетях IP
основе потока, выполняющийся на центральном процессоре маршрутизатора, работаю-
щего под управлением операционной системы 1OS, и распределенный взвешенный ал-
горитм равномерного обслуживания очередей (DWFQ) на основе потока, выполняю-
щийся на процессоре VIP-платы, установленной в маршрутизаторах Cisco серии 7500.
В настоящем разделе обсуждается взвешенный алгоритм равномерного обслуживания
очередей (WFQ) на основе класса (Class-Based WFQ — CBWFQ), который может выпол-
няться как в нераспределенном, так и в распределенном режиме работы.
В соответствии с алгоритмом CBWFQ подочередь выделяется для обработки класса
трафика, а не его отдельного потока, как предусматривается алгоритмом WFQ на основе
потока. Таким образом, алгоритм CBWFQ (предназначенный для выполнения как в не-
распределенном, так и в распределенном режиме работы) может быть получен путем
доработки существующих реализаций алгоритма WFQ на основе потока. Для этого к
алгоритму WFQ на основе потока необходимо добавить модуль классификации трафика,
в соответствии с которым подочередь WFQ будет предназначена для обслуживания
класса трафика, а не его отдельного потока. Следовательно, реализация алгоритма
CBWFQ, выполняющегося на центральном процессоре маршрутизатора, основана на
вычислении порядковых номеров пакетов, а реализация алгоритма CBWFQ, выполняю-
щегося на процессоре интерфейсной платы VIP, — на календарных очередях.
Механизм CBWFQ использует набор компонентов модульного интерфейса ко-
мандной строки (CLI) QoS, более подробное описание которого можно найти в при-
ложении А, “Модульный интерфейс командной строки Cisco QoS”. Следовательно,
указанный алгоритм поддерживает все классы, включенные в этот набор. Класс тра-
фика может быть определен на основе различных параметров, таких, как IP-
приоритет, код DSCP (Differentiated Serviced Code Point — код дифференцированной
услуги), входной интерфейс и QoS-группа. Более подробно возможности классифика-
ции трафика описываются в приложении А.
Алгоритм CBWFQ позволяет явно указать требуемую минимальную полосу про-
пускания для каждого класса трафика. Это выгодно отличает данный алгоритм от ал-
горитма WFQ на основе потока, в соответствии с которым минимальная полоса про-
пускания потока определялась неявно на основании весов всех активных потоков
WFQ-системы.
Примечание
Алгоритм CBWFQ может быть использован для моделирования алгоритма WFQ на
основе потока. Стандартный класс трафика алгоритма CBWFQ является не чем иным,
как обычным WFQ-потоком, обработка которого в соответствии с алгоритмом WFQ на
основе потока может быть осуществлена посредством команды fair-queue.
Различие алгоритмов DWFQ и CBWFQ заключается в том, что вы можете модели-
ровать алгоритм FQ внутри любого DWFQ-класса, а алгоритм WFQ — только внутри
стандартного класса механизма CBWFQ.
Практический пример 4.5: выделение дополнительной
полосы пропускания для критического трафика
Компания, входящая в список Fortune 500, обнаружила, что ее критический тра-
фик приложения базы данных испытывает задержку при передаче по линии связи
глобальной сети (WAN). Проведя анализ трафика, специалисты компании пришли к
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
109
выводу, что причиной перегрузки сети является чрезмерный объем HTTP-, FTP-
трафика, а также трафика, связанного с передачей видео- и аудиофайлов. В результате
отдел обслуживания сети компании получил задание установить такой приоритет тра-
фика приложения базы данных, который бы, с одной стороны, обеспечил его приори-
тетное обслуживание по сравнению с другими типами трафика, а с другой — не при-
вел бы к его тотальному доминированию в сети.
С помощью команды class-map весь критический трафик приложения базы данных
относится к классу gold. После этого классу трафика gold ставится в соответствие поли-
тика goldservice. Наконец, политика goldservice применяется к исходящему трафику ин-
терфейса serialO с целью обеспечения заданной полосы пропускания для критического
трафика. Соответствующая конфигурация маршрутизатора приведена в листинге 4.4.
: Листинг 4.4. Обеспечение заданной полосы пропускания
р для критического трафика
class-map gold
match access-group 101
policy-map goldservice
class gold
bandwidth 500
interface serialO
service-policy output goldservice
access-list 101 permit ip any any udp range 1500 1600
Механизм CBWFQ позволяет явно указать требуемую минимальную полосу про-
пускания для класса трафика посредством применения команды bandwidth.
Список доступа 101 задает критерий совпадения для всего критического трафика
приложения базы данных. Команды show policy и show class используются для вывода
информации обо всех определенных на маршрутизаторе политиках и классах трафика,
соответственно.
В листингах 4.5 и 4.6 приведена информация о политике goldservice и классе тра-
фика gold, соответственно.
Листинг 4.5. Информация о политике goldservice ' ' ;
Routerdshow policy goldservice
Policy Map goldservice
Weighted Fair Queueing
Class gold
Bandwidth 500 (kbps) Max Thresh 64 (packets)
• Листинг 4.6. Информация о классе трафика gold
RouterUshow class gold
class Map gold
match access-group 101
110
Часть I. Качество обслуживания в сетях IP
Как и в практическом примере 4.1, вы можете выполнить команду show queueing
fair для отображения параметров механизма WFQ и команду show queue serialO для по-
лучения статистики пакетов очереди.
Практический пример 4.6: выделение дополнительной
полосы пропускания в зависимости от входного
интерфейса
Сетевой инженер компании — поставщика услуг хочет выделить полосу пропускания
шириной 30 Мбит/с на канале DS3 маршрутизатора Internet для трафика, поступающего
на Fast Ethemet-интерфейс маршрутизатора Internet (предположим, что весь трафик гене-
рируется некоторым сервером, расположенным в соответствующем сегменте сети).
Первый шаг заключается в классификации трафика, который должен быть передан по
каналу DS3 маршрутизатора Internet. Карта класса server задает критерий совпадения для
трафика, поступающего на интерфейс Fast Ethernet 1/1 маршрутизатора Internet. После
этого классу трафика server ставится в соответствие политика febandwidth. Наконец, поли-
тика febandwidth применяется к исходящему трафику интерфейса HssiO/O (канал DS3) по-
средством использования команды service-policy output febandwidth. Соответствующая кон-
фигурация маршрутизатора приведена в листинге 4.7.
Листинг 4.7. Выделение полосы пропускания в зависимости от входного
интерфейса маршрутизатора
class-map server
match input-interface FastEthernetl/1
policy-map febandwidth
class server
bandwidth 30000
interface HssiO/0
service-policy output febandwidth
Практический пример 4.7: выделение полосы
пропускания в зависимости от класса ToS
Крупный поставщик услуг Internet желает разбить весь магистральный трафик на
четыре класса, используя для этого поле IP-приоритета (табл. 4.3).
; Таблица 4.3. Классификация трафика на основании IP-приоритета
Критический (класс 3) Элитный (класс 2) Стандартный (класс 1) Экономичный (класс 0)
Согласованный трафик Приоритет 7 Приоритет 6 Приоритет 5 Приоритет 4
Избыточный трафик Приоритет 3 Приоритет 2 Приоритет 1 Приоритет 0
Каждому классу соответствуют два значения IP-приоритета — по одному для со-
гласованного и избыточного трафика. Трафику классов 1-3 необходимо выделить 15,
Глава 4. РНВ-политика: распределение ресурсов (часть 1) 111
30 и 40 процентов полосы пропускания высокоскоростного последовательного интер-
фейса (High-Speed Serial Interface — HSSI), соответственно. Оставшаяся часть полосы
пропускания (15 процентов) отдается трафику класса 0.
Предположим, что классификация трафика в зависимости от его интенсивности
осуществляется пограничными маршрутизаторами сети поставщика услуг. Более
подробно классификация пакетов рассматривалась в главе 3, “Формирование
трафика на границе сети: классификация пакетов, маркировка пакетов и
управление интенсивностью трафика”.
В соответствии с конфигурацией HSS 1-интерфейса классам обслуживания трафика
0—3 выделяется 6750 Кбит/с, 6750 Кбит/с, 13500 Кбит/с и 18000 Кбит/с полосы про-
пускания, соответственно (листинг 4.8).
• Листинг 4.8. Выделение полосы пропускания в зависимости
i от класса обслуживания
class-map match-any classO
match ip precedence 4
match ip precedence 0
class-map match-any class 1
match ip precedence 1
match ip precedence 5
class-map match-any class2
match ip precedence 2
match ip precedence 6
class-map match-any class3
match ip precedence 3
match ip precedence 7
policy-map tos-based
class classO
bandwidth 6750
class classl
bandwidth 6750
class class2
bandwidth 13500
class class3
bandwidth 18000
interface hssi0/0/0
service-policy output tos-based
Примечание
Хотя на момент написания этой книги определение выделенной классу трафика поло-
сы пропускания как части от общей полосы пропускания канала было невозможно,
вскоре подобная опция должна стать доступной.
112
Часть I. Качество обслуживания в сетях IP
Конфигурация механизма CBWFQ без использования
модульного интерфейса командной строки QoS
Вы можете сконфигурировать некоторые распределенные механизмы CBWFQ — а
именно, механизм DWFQ на основе класса услуг (ToS) и механизм DWFQ на основе
QoS-группы — на маршрутизаторах Cisco серии 7500, построенных на базе интер-
фейсных плат VIР, без использования модульного интерфейса командной строки QoS.
Распределенный алгоритм равномерного обслуживания
очередей (DWFQ) на основе класса услуг
Распределенный алгоритм равномерного обслуживания очередей (DWFQ) на осно-
ве класса услуг (ToS-based DWFQ) представляет собой алгоритм CBWFQ, в котором
для выбора очереди используются два младших бита поля IP-приоритета. Количество
возможных очередей при этом равняется четырем. В табл. 4.4 показано соответствие
классов услуг значению поля IP-приоритета.
Таблица 4.4. Категоризация трафика на основании класса услуг
Биты IP-приоритета Биты класса услуг Класс услуг
ООО 00 0
001 01 1
010 10 2
011 11 3
100 00 0
101 01 1
110 10 2
111 11 3
Конфигурация распределенного взвешенного алгоритма равномерного обслужива-
ния очередей (DWFQ) на основе класса услуг ToS осуществляется с помощью коман-
ды fair-queue tos.
Рассмотрим конфигурацию механизма CBWFQ на основании класса услуг, анало-
гичную той, что представлена в практическом примере 4.7. Отметим, что в этом слу-
чае модульный интерфейс командной строки QoS не применяется (листинг 4.9).
Листинг 4.9. Выделение полосы пропускания в зависимости
от класса услуг ToS
interface Hssi0/0/0
fair-queue tos
fair-queue tos 1 weight 15
fair-queue tos 2 weight 30
fair-queue tos 3 weight 40
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
113
Примечание
В реализации алгоритма DWFQ понятие веса (параметр weight) отличается от анало-
гичного понятия в реализации алгоритма WFQ на основе потока. В аспекте алгоритма
DWFQ вес указывает на процент от общей полосы пропускания линии связи.
Следует отметить, что стандартный вес классов услуг ToS 1, 2 и 3 составляет 20, 30
и 40, соответственно. В рассматриваемом случае планируемый вес классов 2 и 3 сов-
падает с их стандартным весом и, следовательно, не нуждается в дополнительной
конфигурации. Классу! назначается вес 15. В листинге 4.10 приведены параметры
алгоритма DWFQ на основе класса услуг ToS и статистика обработки пакетов.
Листинг 4.10. Параметры алгоритма DWFQ на основе классов услуг ToS
I и статистика обработки пакетов
Routerfshow interface fair
HSSIO/O/O queue size 0
packets output 20, wfq drops 1, nobuffer drops 0
WFQ: aggregate queue limit 5972, individual queue limit 2986
max available buffers 5972
Class 0: weight 15 limit 2986 qsize 0 packets output 0 drops 0
Class 1: weight 15 limit 2986 qsize 0 packets output 0 drops 0
Class 2: weight 30 limit 2986 qsize 0 packets output 0 drops 0
Class 3: weight 40 limit 2986 qsize 0 packets output 0 drops 0
Параметр weight указывает на процент от общей полосы пропускания канала, вы-
деленный данному классу трафика. К примеру, вес класса услуг ToS 3 равняется 40.
Это означает, что данному классу трафика выделяется 40 процентов пропускной спо-
собности линии связи в момент одновременного обслуживания очередей всех четырех
классов (0, 1, 2 и 3).
Вес класса услуг ToS 0 всегда зависит от весов оставшихся классов и изменяется в слу-
чае изменения веса класса услуг ToS 1-3. Поскольку совокупный вес всех классов услуг
равняется 100, вес класса услуг ToS 0 всегда может быть вычислен как 100 - (вес классов
услуг 1-3). Следует отметить, что сумма весов классов услуг 1-3 не должна превышать 99.
Распределенный алгоритм равномерного обслуживания
очередей (DWFQ) на основе QoS-группы
В дополнение к механизму DWFQ на основе класса услуг ToS, вы можете скон-
фигурировать механизм DWFQ на основе QoS-группы на маршрутизаторах Cisco се-
рии 7500, построенных на базе интерфейсных платХЧР, без использования модуль-
ного интерфейса командной строки QoS.
QoS-группа — это номер, присваиваемый пакету в случае удовлетворения какого-
либо определенного пользователем критерия совпадения. Следует отметить, что QoS-
группа представляет собой внутреннюю по отношению к маршрутизатору метку, т.е.
не входит подобно полю IP-приоритета в структуру IP-пакета. Без использования мо-
дульного интерфейса командной строки QoS конфигурация механизма DWFQ на ос-
нове QoS-группы осуществляется посредством команды fair-queue qos-group.
114
Часть I. Качество обслуживания в сетях IP
Практический пример 4.8: выделение полосы
пропускания в зависимости от QoS-группы без
использования модульного интерфейса командной
строки QoS
Поставщик услуг Internet планирует выделить на интерфейсе HSSI0/0/0 вчетверо
большую полосу пропускания для трафика QoS-группы 3, нежели для трафика QoS-
группы 0. Предположим, что перед поступлением в маршрутизатор пакеты классифи-
цируются с помощью метки QoS-группы некоторым приложением. Кроме этого,
предположим, что обработка трафика QoS-группы, отличной от 0 и 3, маршрутизато-
ром поставщика услуг Internet не предусмотрена.
В листинге 4.11 приведен пример конфигурации механизма DWFQ на основе QoS-
группы без использования модульного интерфейса командной строки QoS.
\ Листинг 4.11. Выделение 80 процентов полосы пропускания трафику
> QoS-группы 3
interface hssiO/O/O
fair-queue qos-group
fair-queue qos-group 3 weight 80
Полоса пропускания интерфейса HSSI0/0/0 распределяется между трафиком QoS-
группы 3 и QoS-группы 0 в пропорции 4:1. Поскольку вес трафика определяется в процен-
тах от доступной полосы пропускания, указанная выше пропорция задается как 80:20.
В листинге 4.12 приведены параметры алгоритма DWFQ и статистика обработки
пакетов.
; Листинг 4.12. Параметры алгоритма DWFQ и статистика обработки пакетов
Router#show interface fair
HSSIO/O/O queue size 0
packets output 3142, wfq drops 32, nobuffer drops 0
WFQ: aggregate queue limit 5972, individual queue limit 2986
max available buffers 5972
Class 0: weight 20 limit 2986 qsize 0 packets output 11 drops 1
Class 3: weight 80 limit 2986 qsize 0 packets output 3131 drops 31
qsize 0 packets output 0 drops 0
Приоритетное обслуживание очередей
Механизм приоритетного обслуживания очередей предполагает наличие четырех
выходных подочередей — подочереди с высоким, средним, обычным и низким при-
оритетом обслуживания. Сетевой администратор может определить принадлежность
потока трафика к любой из четырех очередей. Пакеты, принадлежащие очереди с вы-
соким приоритетом обслуживания, передаются первыми. Когда высокоприоритетная
очередь окажется пустой, начнется передача пакетов следующей по приоритету об-
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
115
служивания очереди и т.д. Отметим, что передача пакетов очереди со средним при-
оритетом обслуживания не начнется до тех пор, пока не будут обслужены все пакеты
высокоприоритетной очереди.
Приоритетное обслуживание пакетов востребовано в сетях, где передача трафика,
необходимого для решения критически важных задач, должна быть осуществлена даже
при условии полного доминирования высокоприоритетного трафика в моменты пере-
грузки сети. Вполне возможно, что во время перегрузки сети для передачи трафика, не-
обходимого для решения критически важных задач, будет выделено 100 процентов дос-
тупной полосы пропускания. Если интенсивность высокоприоритетного трафика срав-
няется на определенный промежуток времени с линейной интенсивностью или
превысит ее, механизм приоритетного обслуживания очередей все равно обеспечит пе-
редачу высокоприоритетной информации до поступления ее следующей порции, даже
если для этого придется пожертвовать управляющим трафиком сети.
Механизм приоритетного обслуживания очередей поддерживает классификацию паке-
тов в зависимости от входного интерфейса, простого или расширенного списка доступа на
основании IP-адреса, размера пакета и сгенерировавшего этот пакет приложения.
Следует отметить, что неклассифицированный трафик по умолчанию относится к
очереди с обычным приоритетом обслуживания. В пределах очереди пакеты обраба-
тываются в соответствии с механизмом FIFO.
Практический пример 4.9: обслуживание трафика
на основании значения поля IP-приоритета
Сеть Internet-компании обслуживает трафик с IP-приоритетом 0, I, 2 и 3 в зави-
симости от его важности. Чем важнее трафик, тем он получает более высокий при-
оритет обслуживания. Высокоприоритетный трафик имеет строгое предпочтение пе-
ред низкоприоритетным трафиком.
Значения IP-приоритета 4-7 зарезервированы для трафика приложений с более
строгими требованиями к ресурсам и в настоящий момент не используются. Тем не
менее если не поддерживаемое в данный момент значение IP-приоритета будет все-
таки использовано, соответствующий трафик будет обрабатываться как трафик с IP-
приоритетом 0.
Как упоминалось ранее, механизм приоритетного обслуживания очередей преду-
сматривает наличие четырех выходных очередей, обрабатываемых строго в соответст-
вии с их приоритетом. Очереди с высоким, средним, обычным и низким приоритетом
обслуживания соответствует IP-приоритет 3, 2, 1 и 0. Конфигурация маршрутизатора
Internet-компании приведена в листинге 4.13.
- Листинг 4.13. Обслуживание трафика на основании значения поля
IP-приоритета
interface SerialO
ip address 201.201.201.2 255.255.255.252
priority-group 1
access-list
access-list
access-list
100 permit ip
101 permit ip
102 permit ip
any any precedence routine
any any precedence priority
any any precedence immediate
116
Часть I. Качество обслуживания в сетях IP
access-list 103 permit ip any any precedence flash
priority-list 1 protocol ip high list 103
priority-list 1 protocol ip medium list 102
priority-list 1 protocol ip normal list 101
priority-list 1 protocol ip low list 100
priority-list 1 default low
В листингах 4.14 и 4.15 содержится текущая конфигурация механизма приоритет-
ного обслуживания очередей и информация о стратегии обслуживания очередей ин-
терфейса serialO, соответственно. Команда show queueing priority используется для вы-
вода на экран текущей конфигурации механизма приоритетного обслуживания очере-
дей данного маршрутизатора, а команда show interface serialO — для вывода на экран
информации о сконфигурированном на интерфейсе serialO списке приоритета, а также
статистики обработки пакетов каждой из четырех очередей.
Листинг 4.14. Параметры механизма приоритетного обслуживания очередей
Router#show queueing priority
Current priority queue configuration:
List Queue Args
1 low default
1 high protocol ip list 103
1 medium protocol ip list 102
1 normal protocol ip list 101
1 low protocol ip list 100
Листинг 4.15. Информация о стратегии обслуживания очередей интер-
фейса serialO
Router#show interface serialO
<верхняя часть листинга удалена>
Queueing strategy: priority-list 1
Output queue (queue priority: size/max/drops):
high: 2/20/0, medium: 0/40/0, normal: 0/60/0, low: 4/80/0
<нижняя часть листинга удалена>
Практический пример 4.10: приоритетное обслуживание
пакетов на основе размера
Крупная компания столкнулась с проблемой длительных переменных задержек
трафика транзакций, необходимого для решения критически важных задач, и голо-
сового трафика (Voice over IP — VoIP), передаваемого по линии связи глобальной
сети (WAN), размер пакетов которого не превышает 100 байт. Руководство компа-
нии желает, чтобы маршрутизатор обрабатывал трафик с пакетами размером мень-
ше 100 байт сразу же при его поступлении, не обращая при этом внимания на об-
служивание остального трафика. Маршрутизатор может приступить к обработке ос-
тального трафика только при условии отсутствия в очереди трафика с пакетами
размером менее 100 байт.
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
117
Соответствующая конфигурация механизма приоритетного обслуживания приве-
дена в листинге 4.16.
Листинг 4.16. Приоритетное обслуживание пакетов на основе размера
interface serial О
priority-group 1
priority-list 1 protocol ip high It 100
priority-list 1 default low
Практический пример 4.11: приоритетное обслуживание
пакетов на основе адреса источника
Филиал крупной компании подключен к главному офису с помощью канала Т1.
В одной из подсетей филиала, 213.13.13.0/8, расположены приложения и серверы, ис-
пользующиеся для решения критически важных задач. Сетевой администратор пери-
ферийного отдела хочет обеспечить приоритетную обработку трафика, исходящего из
этой подсети, по отношению ко всему остальному трафику филиала компании.
В листинге 4.17 приведена конфигурация механизма приоритетного обслуживания
очередей на основе IP-адреса источника.
j Листинг 4.17. Приоритетное обслуживание пакетов на основе адреса
источника
interface serial 0
priority-group 1
priority-list 1 protocol ip high list 1
priority-list 1 default low
access-list 1 permit 213.13.13.0 0.0.0.15
Заказное обслуживание очередей
В то время как приоритетное обслуживание очередей позволяет гарантировать
предоставление всей полосы пропускания трафику, необходимому для решения кри-
тически важных задач (игнорируя при этом весь оставшийся сетевой трафик), заказ-
ное обслуживание очередей обеспечивает минимальную полосу пропускания для каж-
дого класса трафика.
Механизм заказного резервирования полосы пропускания обрабатывает каждую
непустую очередь в режиме кругового обслуживания, всякий раз передавая некоторое
настраиваемое число пакетов этой очереди. Заказное обслуживание очередей позволя-
ет гарантировать предоставление определенной части полосы пропускания трафику,
необходимому для выполнения критически важных задач, в то же время не забывая и
об остальном трафике сети. Механизм заказного обслуживания очередей во многом
похож на механизм CBWFQ со сложной конфигурацией.
118
Часть I. Качество обслуживания в сетях IP
В соответствии с заказным обслуживанием трафик может быть распределен по
16 очередям. Помимо этого, существует дополнительная 0-я очередь, которая называется
системной очередью (system queue). Системная очередь предназначена для обработки высо-
коприоритетных пакетов, таких, как пакеты поддержки соединения и управляющие паке-
ты. Пользовательский трафик не может обрабатываться в системной очереди. Механизм
заказного обслуживания очередей поддерживает классификацию пакетов в зависимости от
входного интерфейса, простого или расширенного списка доступа на основании IP-адреса,
размера пакета и сгенерировавшего этот пакет приложения.
Одним из наиболее распространенных способов использования механизма заказ-
ного обслуживания очередей является обеспечение гарантированной полосы пропус-
кания для набора узлов, определенных посредством списка доступа. Чтобы распреде-
лить полосу пропускания по различным очередям, для каждой очереди необходимо
указать значение счетчика байтов.
Роль счетчика байтов в механизме заказного
обслуживания очередей
В соответствии с механизмом заказного обслуживания маршрутизатор передает
поставленные в очередь пакеты до тех пор, пока не будет превышено значение
счетчика байтов. Следует отметить, что даже в случае превышения этого значения
пакет, который передается в текущий момент времени, будет передан полностью.
Например, если значение счетчика байтов будет равно 100, а размер пакета —
1024 байт, то каждый раз при обслуживании данной очереди маршрутизатор будет
передавать 1024 байт, а не 100 байт.
Предположим, что размер пакетов трех различных протоколов равен 500, 300 и
100 байт, соответственно. Для того чтобы равномерно распределить полосу пропуска-
ния между тремя протоколами, вы можете попытаться установить значение счетчика
байтов для каждой очереди равным 200. Следует отметить, что подобное решение, тем
не менее, не приведет к распределению полосы пропускания в пропорции 33/33/33.
Когда маршрутизатор обслуживает первую очередь, он передает каждый раз 500-
байтовый пакет информации; вторую очередь — 300-байтовый пакет; третью оче-
редь — два 100-байтовых пакета. Таким образом, действительное распределение поло-
сы пропускания осуществляется в пропорции 50/30/20. К подобному непредусмот-
ренному результату привело слишком малое значение счетчика байтов.
На самом деле достаточно большое значение счетчиков байтов также может при-
вести к весьма нежелательному распределению полосы пропускания. Если всем трем
очередям будет присвоено значение счетчика байтов, равное 10 Кбайт, то, несмотря
на то что пакеты каждого из протоколов будут обслуживаться быстро в момент обра-
ботки соответствующей этому протоколу очереди, может пройти достаточно много
времени, прежде чем данная очередь будет обслужена снова. В рассматриваемом нами
случае одним из наиболее оптимальных решений является установка значений счет-
чиков байтов очередей, равными 500, 600 и 500 байт, соответственно, что приведет к
распределению полосы пропускания в пропорции 31:38:31.
Для того чтобы обеспечить равномерное обслуживание очередей и гарантировать
как можно более близкое к требуемому распределение полосы пропускания, сетевой
инженер должен подбирать значение счетчиков очередей на основании размера пакета
каждого протокола. В противном случае полученная в результате пропорция может
оказаться далеко не идеальной.
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
119
Практический пример 4.12: выделение минимальной
полосы пропускания интерфейса для различных
протоколов
Сетевой администратор хочет распределить полосу пропускания между протокола-
ми А, В и С в пропорции 20:60:20. В среднем размер пакета протокола А равен
1086 байт, протокола В — 291 байт, а протокола С — 831 байт.
Использование механизма заказного обслуживания для распределения полосы
пропускания между протоколами А, В и С требует подбора корректных значений
счетчиков байтов для очереди каждого протокола.
Для того чтобы определить подходящее значение счетчика байтов для каждой оче-
реди, выполните следующие действия.
Шаг 1. Для каждой из очередей разделите процент полосы пропускания, который
необходимо выделить этой очереди, на размер пакета в байтах. В рассмат-
риваемом случае мы получим:
20:1086, 60:291, 20:831
или
0.01842, 0.20619, 0.02407.
Шаг 2. Проведите нормализацию полученных величин путем деления каждой из
них на наименьшую величину:
1, 11.2, 1.3.
Полученные в результате значения представляют собой коэффициенты
пропорции числа пакетов каждого протокола, которые должны переда-
ваться за один раз для достижения желаемого распределения полосы про-
пускания интерфейса (20:60:20).
Шаг 3. Дробное значение коэффициента пропорции указывает на необходимость
передачи дополнительного пакета. Для того чтобы получить действительное
число пакетов, которые должны быть переданы за один сеанс обслуживания
очередей, округлите полученные значения до следующего целого числа.
В рассматриваемом нами примере действительные значения коэффициен-
тов пропорции равняются 1, 12 и 2 пакета.
Шаг 4. Для того чтобы получить требуемые значения счетчиков байтов, умножьте
коэффициенты пропорции на соответствующий им размер пакета.
В данном случае для распределения полосы пропускания в пропорции,
близкой к 20:60:20, маршрутизатор должен передавать один 1086-
байтовый, двенадцать 291-байтовых и два 831-байтовых пакета за каждый
сеанс обслуживания соответствующей очереди. Таким образом, требуемые
значения счетчиков байтов составили 1086, 3492 и 1662 байта.
Шаг 5. Для того чтобы узнать распределение полосы пропускания, обусловленное
полученной выше пропорцией, сперва необходимо подсчитать общее чис-
ло пакетов, передаваемое за один сеанс обслуживания всех трех очередей:
(1 х 1086) + (12 х 291) + (2 х 831) = 1086 + 3492+ 1662 = 6240.
Шаг 6. Определите процентное соотношение числа пакетов, передаваемых за
один сеанс обслуживания каждой очереди:
120
Часть I. Качество обслуживания в сетях IP
1086 - 6240, 3492 - 6240, 1662 + 6240 = 17.4%, 56% и 26.6%.
Как видите, полученное распределение полосы пропускания интерфейса
достаточно близко к желаемой пропорции 20:60:20.
Шаг 7. Если вас не устраивает полученное распределение полосы пропускания, ум-
ножьте коэффициенты пропорции 1,11.2 и 1.3, рассчитанные на шаге 2, на не-
которое оптимальное значение, выбранное с целью максимального приближе-
ния коэффициентов пропорции к целым числам. Обратите внимание, что вы-
бранное вами оптимальное значение совсем не обязательно должно быть
целым числом. Предположим, что вы удвоили коэффициенты пропорции, по-
лучив соотношение 2:22.4:2.6. Это означает, что теперь за один сеанс обслужи-
вания очередей маршрутизатор должен переслать два 1086-байтовых, двадцать
три 291-байтовых и три 831-байтовых пакета, всего 11358 байт в пропорции
2172:6693:2493. Полученное распределение полосы пропускания составляет
19:59:22 процента, что уже намного ближе к требуемому соотношению.
В листинге 4.18 приведена конфигурация механизма заказного обслуживания на
интерфейсе SerialO/0/З, определяющая значения счетчиков байтов для трех очередей
протоколов и назначающая трафику каждого протокола соответствующую очередь.
; Листинг 4.18. Конфигурация механизма заказного обслуживания очередей .
: на интерфейсе SerialO/0/З
interface SerialO/0/З
custom-queue-list 1
queue-list 1 protocol ip 1 tcp <протокол A>
queue-list 1 protocol ip 2 tcp <протокол B>
queue-list 1 protocol ip 3 tcp <протокол C>
queue-list 1 queue 1 byte-count 2172
queue-list 1 queue 2 byte-count 6693
queue-list 1 queue 3 byte-count 2493
В листингах 4.19 и 4.20 содержится текущая конфигурация механизма заказного
обслуживания очередей и информация о стратегии обслуживания очередей интерфей-
са SerialO/0/З, соответственно. Команда show queueing custom используется для вывода
на экран текущей конфигурации механизма заказного обслуживания очередей.
! Листинг 4.19. Конфигурация механизма заказного обслуживания очередей
Router#show queueing custom
Current custom queue configuration:
List Queue Args
1 1 protocol ip tcp port <протокол A>
1 2 protocol ip tcp port "«протокол B>
1 3 protocol ip tcp port "«протокол C>
1 1 byte-count 2172
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
121
1 2 byte-count 6693
1 3 byte-count 2493
Листинг 4.20. Информация о стратегии обслуживания очередей интер-
фейса SerialO/0/З и статистика обработки пакетов
RouterKshow interface serial0/0/3
<верхяяя часть листинга удалена>
Queueing strategy: custom-list 1
Output queues: (queue i: size/max/drops)
0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0
<нижняя часть листинга удалена>
В результате выполнения команды show interface на экран выводится информация
о максимальном размере каждой из 16 очередей механизма заказного обслуживания, а
также текущий размер и статистика отбрасывания пакетов каждой очереди на момент
выполнения команды.
Следует отметить, что действительное распределение полосы пропускания интер-
фейса зависит также и от размера окна каждого из протоколов. Если размер окна про-
токола равняется 1, то этот протокол не разместит в очереди следующий пакет до мо-
мента получения подтверждения о доставке. Что же касается алгоритма заказного об-
служивания, то он переходит к обработке следующей очереди либо при превышении
значения счетчика байтов, либо при опустошении очереди.
Другими словами, если размер окна протокола равняется 1, то за один сеанс обслужи-
вания очередей маршрутизатор сможет переслать только один пакет. К примеру, если зна-
чение счетчика байтов равно 2 Кбайт, а размер пакета — 256 байт, то за один сеанс обслу-
живания такой очереди маршрутизатор сможет передать всего лишь 256 байт.
Примечание
Несмотря на то что, аналогично механизму CBWFQ, механизм заказного обслужива-
ния очередей позволяет проводить резервирование полосы пропускания для класса
трафика, механизм CBWFQ обладает существенными преимуществами перед меха-
низмом заказного обслуживания. Некоторые их них перечислены ниже.
• Конфигурирование механизма CBWFQ намного проще и понятнее по сравнению с
настройкой механизма заказного обслуживания.
• Механизм CBWFQ поддерживает взаимодействие с протоколом резервирования
ресурсов RSVP.
• В дополнение к выделению минимальной полосы пропускания механизм CBWFQ
позволяет применить к отдельному классу трафика политику отбрасывания паке-
тов, такую, как политика произвольного раннего обнаружения (Random Early
Detection — RED).
• Механизм CBWFQ поддерживает 64 класса трафика, в то время как используя ме-
ханизм заказного обслуживания очередей, вы будете ограничены всего лишь
16 классами.
122
Часть I. Качество обслуживания в сетях IP
Механизмы обслуживания очередей,
предназначенные для обработки
голосового трафика
Для того чтобы быть понятным для слушателя, голосовой трафик должен испыты-
вать при передаче минимальную задержку и дрожание (вариацию задержки). Несмот-
ря на то что механизм CBWFQ и механизм заказного обслуживания очередей могут
обеспечить требуемую полосу пропускания, они не в состоянии гарантировать прием-
лемого для голосового трафика диапазона дрожания. Голосовой трафик характеризу-
ется сравнительно небольшими запросами к полосе пропускания (как правило,
64 Кбит/с), однако намного более жесткими требованиями к уровню задержки и дро-
жания. С целью минимизации задержки и дрожания голосового трафика механизм
CBWFQ и механизм заказного обслуживания модифицируются путем добавления од-
ной или нескольких очередей со строгим приоритетом. Очередь со строгим приорите-
том называется также очередью с малой задержкой (low latency queue).
Помимо голосового трафика, очереди со строгим приоритетом могут использовать-
ся для обработки трафика любых приложений, функционирующих в масштабе реаль-
ного времени и чувствительных к задержке пакетов.
Механизм CBWQF с приоритетной очередью
Механизм CBWFQ с приоритетной очередью позволяет обеспечить обслуживание
чувствительного к задержкам трафика (например, голосового) посредством использо-
вания очереди со строгим приоритетом; при этом все остальные классы трафика об-
рабатываются посредством стандартного планировщика CBWFQ. Механизм CBWFQ с
приоритетной очередью называется также механизмом обслуживания очередей с малой
задержкой (low latency queuing — LLQ).
В соответствии с усовершенствованным механизмом CBWFQ голосовой трафик
обрабатывается посредством одной приоритетной очереди, которая по своим характе-
ристикам напоминает высокоприоритетную очередь механизма приоритетного обслу-
живания, рассматривавшегося в предыдущих разделах этой главы. Оставшиеся очере-
ди представляют собой стандартные очереди механизма CBWFQ (по одной очереди на
класс трафика), обеспечивающие дифференциацию различных классов трафика и га-
рантированное распределение пропускной способности интерфейса на основе веса
или явного указания полосы пропускания очереди.
Голосовой трафик может быть идентифицирован на основе номеров портов транс-
портного протокола масштаба реального времени (Real-time Transport Protocol —
RTP). Чтобы назначить для обработки голосового трафика приоритетную очередь,
следует применить команду ip rtp priority на соответствующем выходном интерфейсе
маршрутизатора. Более подробно протокол RTP рассматривается в приложении Г,
“Транспортный протокол реального времени (RTP)”.
Загруженность приоритетной очереди может привести к “подавлению” ею оставшихся
очередей интерфейса, снижая эффективность обслуживания стандартных классов трафика
механизма CBWFQ до менее чем удовлетворительной. С целью уменьшения этой пробле-
мы сетевой администратор может задать максимальную полосу пропускания для трафика,
обслуживаемого посредством приоритетной очереди. Если интенсивность трафика превы-
сит максимальное значение, весь избыточный трафик будет отброшен. Следует отметить,
что подобный способ ограничения трафика является весьма грубым, ибо он учитывает
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
123
только выделенную для приоритетной очереди полосу пропускания, не обращая при этом
внимания на сам голосовой вызов.
Сумма полос пропускания приоритетной и стандартных очередей механизма
CBWFQ не должна превышать 75 процентов от обшей полосы пропускания интер-
фейса. Подобное решение было принято с целью предоставления полосы пропуска-
ния для неклассифицированного трафика и инкапсулированной информации уров-
ня 2 эталонной модели OSI. Следует отметить, что сетевой администратор все же мо-
жет изменить стандартное значение максимальной полосы пропускания интерфейса с
помошью команды max-reserved-handwidth.
Даже несмотря на наличие приоритетной очереди, механизм CBWFQ не может гаран-
тировать немедленную передачу пакетов голосового трафика. Это связано с тем, что в мо-
мент поступления голосового пакета планировщик CBWFQ, весьма вероятно, уже обраба-
тывает какой-либо пакет данных и ему необходимо полностью завершить его передачу по
линии связи. Пакеты голосового трафика имеют небольшой размер, однако размер обра-
батываемых в CBWFQ-очередях пакетов может оказаться значительным, а от него прямо
пропорционально зависит величина потенциальной задержки пакетов голосового трафика.
Наиболее ошутимо задержка голосовых пакетов проявляется при их передаче через
низкоскоростные интерфейсы маршрутизаторов. Чтобы уменьшить задержку голосового
трафика, сетевому администратору может потребоваться сконфигурировать на низкоскоро-
стных интерфейсах механизм фрагментации многоканального двухточечного протокола
(Multilink Point-to-Point — MLPP). MLPP-фрагментация позволяет разбить большой пакет
данных на несколько мелких частей и передавать их, чередуя с передачей пакетов голосо-
вого трафика. Более подробно MLPP-фрагментация рассматривается в приложении Д,
“Общие функции линейной эфективности протокола IP”.
Примечание
Приоритетная очередь, предназначенная для обработки голосового трафика, может
использоваться не только в комбинации с механизмом CBWFQ, но также и в комбина-
ции с механизмом WFQ на основе потока.
Практический пример 4.13: очередь со строгим
приоритетом обслуживания, предназначенная
для обработки голосового трафика
В этом практическом примере рассматривается конфигурация интерфейса маршру-
тизатора, обрабатывающего голосовой трафик интенсивностью до 640 Кбит/с с помо-
шью очереди со строгим приоритетом.
В листингах 4.21 и 4.22 приведена конфигурация интерфейса маршрутизатора, ис-
пользующего для приоритетной обработки голосового трафика механизм WFQ на ос-
нове потока и механизм CBWFQ, соответственно.
Листинг 4.21. Обработка голосового трафика интенсивностью
до 640 Кбит/с с помощью очереди со строгим приоритетом
в соответствии с механизмом WFQ на основе потока
interface SerialO
ip rtp priority 16384 32767 640
124
Часть I. Качество обслуживания в сетях IP
Механизм WFQ на основе потока является стандартным механизмом обслужива-
ния очередей, использующимся на последовательном интерфейсе маршрутизатора.
Для того чтобы указать на необходимость использования механизма WFQ на основе
потока на интерфейсе с полосой пропускания более 2 Мбит/с, следует применить ко-
манду fair-queue. В предыдущей конфигурации был указан весь диапазон портов голо-
сового трафика (от 16384 до 32767), использующийся устройствами Cisco VoIP. Таким
образом, команда ip rtp priority указывает на необходимость строгой приоритетной об-
работки всего голосового трафика. В соответствии с механизмом WFQ на основе по-
тока приоритетной очереди назначается специальный вес 0.
: Листинг 4.22. Обработка голосового трафика интенсивностью
= до 640 Кбит/с с помощью очереди со строгим приоритетом
в соответствии с механизмом CBWFQ
class-map premium
match сприоритетный голосовой трафик>
policy-map premiumpolicy
class premium
priority 640
interface serialO
service-policy output premiumpolicy
В соответствии с конфигурацией механизма CBWFQ на интерфейсе SerialO резер-
вируется полоса пропускания для обслуживания приоритетного голосового трафика
шириной 640 Кбит/с. Механизм CBWFQ использует для обработки голосового трафи-
ка очередь со строгим приоритетом, на что указывает команда priority в разделе кон-
фигурации policy-map.
Механизм заказного обслуживания с приоритетными
очередями
Как отмечалось ранее в этой главе, механизм заказного обслуживания очередей
используется для выделения минимальной полосы пропускания интерфейса для за-
данного класса трафика. Несмотря на гарантию предоставления полосы пропускания,
механизм заказного обслуживания, тем не менее, не может обеспечить минимальную
задержку для голосового или другого чувствительного к задержке трафика, что, в пер-
вую очередь, связано с необходимостью обслуживания других очередей в зависимости
от соответствующего им значения счетчика байтов.
С целью обработки голосового трафика с минимально возможной задержкой вы
можете модифицировать одну или несколько очередей механизма заказного обслужи-
вания, преобразовав их в приоритетные очереди.
Механизм заказного обслуживания поддерживает до 16 очередей на один интерфейс
маршрутизатора. Для того чтобы обеспечить поддержку приоритетных очередей, вы
должны определить одну из 16 очередей в качестве наинизшей заказной очереди. При
этом все очереди с номерами, меньшими, чем номер наинизшей заказной очереди, бу-
дут автоматически считаться приоритетными очередями. Предположим, что в качестве
наинизшей заказной очереди была определена очередь 6. Очереди 1—5 при этом будут
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
125
считаться приоритетными, а очереди 6—16 — заказными. Отметим, что приоритет оче-
редей 1—5 уменьшается с возрастанием номера очереди. Так, очередь 1 считается очере-
дью с наивысшим приоритетом, а очередь 5 — очередью с наинизшим приоритетом.
Допустим, что все приоритетные очереди пусты и в настоящий момент обслужива-
ется одна из заказных очередей. В случае постановки в приоритетную очередь нового
пакета планировщик механизма заказного обслуживания сможет перейти к ее обра-
ботке только после завершения обработки заказной очереди в соответствии с назна-
ченным ей счетчиком байтов. Таким образом, для того чтобы не допустить длитель-
ных задержек приоритетных пакетов, значения счетчиков байтов заказных очередей
следует поддерживать на сравнительно низком уровне.
Примечание
Следует отметить, что модифицированный взвешенный алгоритм кругового обслужи-
вания очередей (Modified Weighted Round Robin— MWRR) и модифицированный ал-
горитм кругового обслуживания очередей с дефицитом (Modified Deficit Round Robin —
MDRR) также могут обеспечить поддержку голосового трафика при условии преобра-
зования одной из очередей в очередь со строгим приоритетом. Более подробно алго-
ритмы обслуживания очередей MWRR и MDRR рассматриваются в главе 5, “РНВ-
политика: распределение ресурсов (часть 2)”.
Резюме
В моменты перегрузки сети механизм обслуживания очередей может выделить опре-
деленную полосу пропускания для потока (класса) трафика путем регулирования поряд-
ка обслуживания пакетов в соответствующей этому потоку (классу) очереди. Взвешен-
ный механизм обслуживания очередей (WFQ) на основе потока предусматривает выде-
ление всем потокам трафика с одинаковым весом равных долей полосы пропускания
благодаря использованию максиминного алгоритма равномерного распределения ресур-
сов. Что касается потоков трафика с различным весом, то именно он (вес) и определяет
полосу пропускания, предоставляемую этим потокам. Механизм CBWFQ представляет
собой взвешенный механизм обслуживания очередей (WFQ) на основе класса, поддер-
живающий модульный интерфейс командной строки (CL1) QoS. В соответствии с меха-
низмом CBWFQ каждый класс трафика помещается в отдельную подочередь и обслужи-
вается в зависимости от выделенной ему полосы пропускания.
Механизмы приоритетного и заказного обслуживания были созданы на базе ис-
пользования очереди со строгим приоритетом и схемы кругового обслуживания, соот-
ветственно. Минимальное дрожание при передаче голосового трафика могут обеспе-
чить модифицированные путем добавления очереди со строгим приоритетом меха-
низм CBWQF и механизм заказного обслуживания.
Ответы на часто задаваемые вопросы
Объясните различные механизмы обслуживания очередей, используя при этом весьма
распространенную аналогию с моделью регистрации пассажиров при посадке на борт
авиалайнера.
Если провести аналогию с моделью регистрации пассажиров при посадке на борт
авиалайнера, механизм обслуживания очередей FIFO представляет собой модель реги-
126
Часть I. Качество обслуживания в сетях IP
страции, в соответствии с которой пассажиры всех классов — первого, бизнес- и эко-
ном-класса — стоят в одной очереди. Другими словами, механизм обслуживания
FIFO не поддерживает дифференциацию по классам.
Механизмы обслуживания очередей CBWFQ, MWRR и MDRR можно сравнить с
регистрационной моделью, в которой пассажиры каждого класса занимают соответст-
вующую очередь, характеризующуюся определенным весом (полосой пропускания).
Скорость обслуживания каждой из очередей пассажиров определяется ее весом
(полосой пропускания).
Аналогом механизма приоритетного обслуживания является модель регистрации, в
которой каждому классу пассажиров (первому, бизнес- и эконом-классу) соответству-
ет своя очередь, обслуживаемая в порядке строгого приоритета — другими словами,
первыми регистрацию проходят пассажиры первого класса. Модель регистрации пас-
сажиров при посадке на борт авиалайнера, в которой очереди пассажиров обслужива-
ются по круговому принципу — 10 пассажиров первого класса, 6 пассажиров бизнес-
класса и 4 пассажира эконом-класса за один цикл, — является аналогом механизма
заказного обслуживания.
Как в соответствии с механизмом обслуживания очередей CBWFQ распределяется
остаток полосы пропускания, образовавшийся вследствие использования классом трафи-
ка лишь части выделенных ему ресурсов?
Полоса пропускания, предоставляемая механизмом обслуживания очередей CBWFQ
классу трафика, представляет собой гарантированную минимальную полосу пропуска-
ния в момент перегрузки сети. Если класс трафика не использует всего объема предос-
тавленных ему ресурсов, то их остаток будет распределен между оставшимися классами
трафика пропорционально их весу.
В соответствии с механизмом WFQ на основе потока вес пакета зависит от его IP-
приоритета. Существуют ли исключения из данного правила?
Да. Вес пакета определяется на основании его IP-приоритета до тех пор, пока не
выполняется одно из перечисленных ниже условий:
• протокол RSVP зарезервировал определенный вес для потока трафика;
• трафик является голосовым, при этом режим чередования фреймов Local Frame
Interleave включен;
• пакет сгенерирован локальным устройством (например, пакет с обновлениями
информации о маршрутах) и маркирован специальным флагом приоритета;
• для обслуживания трафика используется очередь со строгим приоритетом, ак-
тивизированная посредством команды ip rtp priority.
В каждом из перечисленных выше случаев пакету назначается вес, специфический
для используемого приложения.
Каким образом механизм WFQ на основе потока обрабатывает не 1Р-трафик?
Механизм WFQ на основе потока поддерживает отдельную процедуру классифика-
ции потоков не 1Р-трафика, в соответствии с которой в расчет принимается тип каналь-
ного уровня пакета (например, IPX, AppleTalk, DECnet, BRIDGE, RSRB). Всем пакетам,
принадлежащим потокам не IP-трафика, присваивается вес, аналогичный весу IP-пакета
с приоритетом 0. Каждому не IP-диалогу соответствует собственный поток трафика и
тип канального уровня. Следовательно, даже при условии присвоения всем пакетам ве-
Глава 4. РНВ-политика: распределение ресурсов (часть 1)
127
са, аналогичного весу IP-пакета с приоритетом 0, механизм WFQ на основе потока
обеспечивает равномерное обслуживание всех потоков не 1Р-трафика.
Я сконфигурировал механизм взвешенного равномерного обслуживания очередей (WFQ)
для обработки поступающего на интерфейс трафика, однако действительное распреде-
ление полосы пропускания интерфейса отличается от теоретических значений. Почему?
Используйте команды show interface fair и show queueing fair для получения инфор-
мации о глубине очереди и статистике отброшенных пакетов для каждого класса тра-
фика. Подобным образом вы сможете оценить достаточность реальной нагрузки тра-
фика для совпадения действительного и заданного распределения полосы пропуска-
ния интерфейса. Так, если нагрузка недостаточна для поддержания очередей всех
классов трафика непустыми, то действительное распределение полосы пропускания
будет неизбежно отличаться от теоретического. Это связано с тем, что алгоритм WFQ
является экономичным алгоритмом, позволяющим потокам трафика занять всю дос-
тупную полосу пропускания интерфейса.
128
Часть I. Качество обслуживания в сетях IP
В этой главе...
Модифицированный взвешенный алгоритм кругового
обслуживания (MWRR) 131
Модифицированный алгоритм кругового обслуживания
с дефицитом (MDRR) .140
Глава
5
РНВ-политика: распределение
ресурсов (часть 2)
Наиболее подходящий алгоритм обслуживания очередей для заданного маршрутизатора
. зависит от используюшейся в нем (маршрутизаторе) архитектуры коммутации пакетов.
К примеру, взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair
: Queuing — WFQ) является идеальным выбором для маршрутизаторов Cisco, построенных
кна базе шинной архитектуры. В маршрутизаторах Cisco, использующих для коммутации
пакетов специализированную коммутационную матрицу, должен применяться алгоритм
• обслуживания очередей, наилучшим образом согласующийся с этой архитектурой. В част-
ности, в семействе коммутаторов Cisco Catalyst и в маршрутизаторах серии 8540 применя-
г ется модифицированный взвешенный алгоритм кругового обслуживания (Modified
Weighted Round Robin — MWRR), а в маршрутизаторах Cisco серии 12000 — модифициро-
< ванный алгоритм кругового обслуживания с дефицитом (Modified Deficit Round Robin —
MDRR). Алгоритмы MWRR и MDRR имеют много сходств с алгоритмом WFQ, поскольку
они тоже моделируют обобщенную схему разделения процессорного времени (Generalized
Processor Sharing — GPS).
Я Следующие два раздела этой главы посвящены рассмотрению модифицированного
взвешенного алгоритма кругового обслуживания (MWRR) и модифицированного ал-
горитма кругового обслуживания с дефицитом (MDRR).
I Модифицированный взвешенный алгоритм
кругового обслуживания (MWRR)
Механизм кругового обслуживания, обрабатывающий за цикл один пакет (вместо бес-
конечно малого объема данных) из каждой непустой очереди, представляет собой самую
простую реализацию схемы GPS. Наиболее точная имитация планировщика GPS достига-
ется в случае равенства размера всех пакетов. Взвешенный алгоритм кругового обслужива-
ния (Weighted Round Robin — WRR) представляет собой расширение планировщика кру-
гового обслуживания, в соответствии с которым каждому потоку трафика назначается свой
вес1. Алгоритм WRR обрабатывает поток трафика пропорционально его весу.
Наиболее оптимальным образом WRR-планировщик согласуется с механизмом комму-
. тации ATM (Asynchronous Transfer Mode — режим асинхронной передачи), в соответствии
1 An Engineering Approach to Computer Networking/Keshav S. — Addison-Wesley, 1997.
с которым пакет представляется в виде ячеек, а алгоритм WRR используется для обработки
очередей, состоящих из ячеек. По сути, WRR является механизмом кругового обслужива-
ния на основе ячеек, в котором вес потока определяет число ячеек, обслуживаемых за
один цикл. Следовательно, каждой очереди выделяется часть полосы пропускания интер-
фейса в соответствии с весом потока трафика, не зависящая от размера пакета.
При желании вместо обслуживания ячеек алгоритм WRR может использоваться для
обслуживания пакетов. В этом случае за один цикл планировщик WRR должен будет
обработать все ячейки пакета, несмотря на возможность занять вес очереди у будущих
циклов. С целью поддержки пакетов переменного размера модифицированный взве-
шенный алгоритм кругового обслуживания (MWRR) использует счетчик дефицита, ас-
социированный с каждой WRR-очередью. Это придает алгоритму MWRR некоторые
свойства алгоритма кругового обслуживания с дефицитом (Deficit Round Robin — DRR),
более подробное описание которого приводится в следующем разделе этой главы.
Перед началом обслуживания очередей значение соответствующего ей счетчика дефи-
цита устанавливается равным весу очереди. Обработка пакета осуществляется только в том
случае, если значение счетчика дефицита больше нуля. После обслуживания пакета, со-
стоящего из п ячеек, значение счетчика дефицита уменьшается на п. Обработка пакетов
проводится до тех пор, пока значение счетчика дефицита остается больше нуля. Затем
планировщик переходит к обслуживанию следующей очереди. В каждом новом цикле зна-
чение счетчика дефицита очереди увеличивается на вес очереди. Следует отметить, что ес-
ли значение счетчика дефицита все еще меньше нуля или равно нулю, обработка пакета не
производится. После обслуживания пакета значение счетчика дефицита уменьшается на
количество ячеек, из которых состоит этот пакет. Использование счетчика дефицита по-
зволяет алгоритму MWRR легко справляться с обработкой пакетов переменного размера.
Эффективная ширина полосы пропускания очереди прямо пропорциональна ее
весу и рассчитывается по следующей формуле:
эффективная ширина полосы пропускания — (вес очереди х ширина полосы пропуска-
ния интерфейса) + сумма весов всех активных очередей.
Пример работы алгоритма MWRR
Предположим, что алгоритм MWRR используется для обслуживания трех очере-
дей, вес каждой из них приведен в табл. 5.1.
' Таблица 5.1. Вес очередей, обслуживаемых с помощью алгоритма MWRR '
Очередь Вес
2 Г"
1 3
О 2
Схематическое изображение очередей с указанием соответствующих им значений
счетчиков дефицита представлено на рис. 5.1.
Напомним, что счетчики дефицита используются алгоритмом MWRR с целью под-
держки пакетов переменного размера.
Каждая очередь состоит из девяти ячеек (см. рис. 5.1). Ячейки, составляющие целый
пакет, имеют одинаковый оттенок серого цвета. К примеру, в очереди 2 находятся три
пакета, состоящие из (справа налево) двух, трех и четырех ячеек, соответственно.
132
Часть I. Качество обслуживания в сетях IP
Очередь Счетчик дефицита
0 0
1 0
2 0
Рис. 5.1. WRR-очереди и соответствующие им значения счетчиков де-
фицита до начала обслуживания
Первой обслуживается очередь 0. При инициализации счетчика дефицита ему при-
сваивается значение 2, равное весу очереди. Во главе очереди 0 стоит 4-ячеечный пакет.
Следовательно, после обслуживания этого пакета значение счетчика дефицита станет рав-
ным 2 - 4 = -2. Поскольку значение счетчика дефицита отрицательно, очередь 0 не может
быть обслужена до тех пор, пока значение счетчика дефицита не станет больше нуля
(рис. 5.2).
Очередь Счетчик дефицита
2 0
1 0
0 -2
Рис. 5.2. Состояние очередей алгоритма MWRR после первого цикла об-
служивания очереди 0
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
133
Следующей обслуживается очередь 1. При инициализации счетчика дефицита ему
присваивается значение 3. В результате обслуживания стоящего во главе очереди 1 3-
ячеечного пакета значение счетчика дефицита становится равным 3-3 = 0. Посколь-
ку значение счетчика дефицита равно нулю, планировщик алгоритма MWRR присту-
пает к обработке следующей очереди (рис. 5.3).
Рис. 5.3. Состояние очередей алгоритма MWRR после первого цикла об-
служивания очереди 1
Последней обслуживается очередь 2. При инициализации счетчика дефицита ему
присваивается значение 3. В результате обслуживания стоящего во главе очереди 2 2-
ячеечного пакета значение счетчика дефицита становится равным 4-2 = 2. Посколь-
ку значение счетчика дефицита больше нуля, MWRR-планировщик обрабатывает сле-
дующий, 3-ячеечный, пакет. После обслуживания 3-ячеечного пакета значение счет-
чика дефицита очереди 2 становится равным 2 - 3 = -1, как показано на рис. 5.4.
Планировщик MWRR приступает ко второму циклу обслуживания очереди 0. Зна-
чение счетчика дефицита очереди 0, установленное на первом цикле, равно -2. В ре-
зультате увеличения значения счетчика дефицита на вес очереди оно становится рав-
ным -2 + 2 = 0. Поскольку значение счетчика дефицита все еще не больше нуля,
планировщик алгоритма MWRR приступает к обработке следующей очереди
(рис. 5.5).
134
Часть I. Качество обслуживания в сетях IP
Очередь 2
Очередь Счетчик дефицита
2 -1
1 0
0 -2
Рис. 5.4. Состояние очередей алгоритма MWRR по-
сле первого цикла обслуживания очереди 2
Очередь 2
9 8 7 6
Очередь 1
9 I 8
Очередь О
Очередь Счетчик дефицита
2 -1
1 0
0 0
Рис. 5.5. Состояние очередей алгоритма MWRR по-
сле второго цикла обслуживания очереди О
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
135
После первого цикла обслуживания значение счетчика дефицита очереди 1
равнялось нулю. Во втором цикле обслуживания значение счетчика дефицита
увеличивается на вес очереди и становится равным 0 + 3 = 3. В результате обслу-
живания стояшего во главе очереди 1 4-ячеечного пакета значение счетчика де-
фицита становится равным 3 - 4 = -1, как показано на рис. 5.6.
Рис. 5.6. Состояние очередей алгоритма MWRR по-
сле второго цикла обслуживания очереди 1
Во втором цикле обслуживания значение счетчика дефицита очереди 2 увели-
чивается на ее вес и становится равным -1+4 = 3. В результате обслуживания
стояшего во главе очереди 2 4-ячеечного пакета значение счетчика дефицита ста-
новится равным 3 - 4 = -1. Поскольку теперь очередь 2 становится пустой, зна-
чение ее счетчика дефицита сбрасывается в нуль (рис. 5.7).
Планировшик MWRR приступает к третьему циклу обслуживания очереди 0.
Значение счетчика дефицита увеличивается и становится равным 0 + 2 = 2. В ре-
зультате обслуживания стояшего во главе очереди 0 2-ячеечного пакета значение
счетчика дефицита становится равным 2-2 = 0. MWRR-планировшик прекраща-
ет обработку очереди 0 и переходит к очереди 1 (рис. 5.8).
136
Часть I. Качество обслуживания в сетях IP
Очередь 2
Очередь 1
9 |8
Очередь О
9 00 <0
Очередь Счетчик дефицита
2 0
1 -1
0 0
Рис. 5.7. Состояние очередей алгоритма MWRR по-
сле второго цикла обслуживания очереди 2
Очередь 2
Рис. 5.8. Состояние очередей алгоритма MWRR по-
сле третьего цикла обслуживания очереди О
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
137
Новое значение счетчика дефицита очереди 1 равняется -1+3 = 2. В резуль-
тате обслуживания стояшего во главе очереди 1 2-ячеечного пакета значение
счетчика дефицита становится равным 2-2 = 0. Поскольку теперь очередь 1 ста-
новится пустой, планировшик алгоритма MWRR приступает к обработке очере-
ди 0, как показано на рис. 5.9.
Очередь 2
Очередь 1
Рис. 5.9. Состояние очередей алгоритма MWRR по-
сле третьего цикла обслуживания очереди 1
В четвертом цикле обслуживания очереди 0 значение ее счетчика дефицита стано-
вится равным 2. В результате обслуживания стояшего во главе очереди 0 3-ячеечного
пакета значение счетчика дефицита становится равным -1. Поскольку теперь оче-
редь 0 становится пустбй, значение ее счетчика дефицита сбрасывается в нуль.
Реализация алгоритма MWRR
Алгоритм MWRR реализован в семействе коммутаторов Cisco Catalyst и маршрути-
заторах серии 8540. Конкретные реализации алгоритма MWRR в том или ином уст-
ройстве различаются между собой в терминах количества доступных MWRR-очередей
и способа классификации трафика.
Реализация алгоритма MWRR в маршрутизаторах Cisco серии 8450 предусматрива-
ет наличие четырех очередей на два любых интерфейса маршрутизатора; классифика-
ция трафика при этом проводится на основе значения группы битов поля типа обслу-
живания (Type of Service — ToS). Распределение трафика по классам ToS представле-
но в табл. 5.2.
138
Часть I. Качество обслуживания в сетях IP
Таблица 5.2. Распределение трафика по классам ToS в соответствии с
i алгоритмом MWRR
Биты поля IP-приоритета Биты класса ToS Класс ToS
000 00 0
001 00 1
010 01 2
011 01 3
100 10 0
101 10 1
110 11 2
111 11 3
Примечание
Алгоритм MWRR на основе классов ToS, реализованный в маршрутизаторах Cisco се-
рии 8500, имеет множество сходств с алгоритмом DWFQ на основе классов ToS, рас-
сматривавшимся в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”. Прин-
ципиальное отличие между двумя алгоритмами заключается в используемых битах
поля IP-приоритета. Алгоритм DWFQ на основе класса ToS использует два младших
бита поля IP-приоритета, в то время как алгоритм MWRR на основе класса ToS, реа-
лизуемый в маршрутизаторах серии 8500, —два старших бита.
Реализация алгоритма MWRR в коммутаторах Cisco Catalyst серии 6000 и 6500 преду-
сматривает наличие двух очередей — очереди 1 и очереди 2. Классификация трафика про-
изводится на 2-м уровне эталонной модели OSI на основании значения поля класса об-
служивания (Class of Service — CoS), определенного в спецификации IEEE (Institute of
Electrical and Electronics Engineers — институт инженеров по электротехнике и электрони-
ке) 802.1р. Фреймы со значением поля CoS 0-3 ставятся в очередь 1, а фреймы со значе-
нием поля CoS 4-7 — в очередь 2. Более подробно поле CoS спецификации 802.1р рас-
сматривается в главе 8, “Качество обслуживания на уровне 2: межсетевой обмен с IP QoS”,
далее в этой книге.
Реализация алгоритма MWRR в коммутаторах Cisco серии 6500, кроме всего про-
чего, предполагает наличие очереди со строгим приоритетом, использующейся для
обработки голосового и другого трафика масштаба реального времени, предъявляю-
щего жесткие требования к уровню задержки.
Практический пример 5.1: алгоритм MWRR на основе
класса трафика
Крупный поставщик услуг Internet принял решение разделить магистральный тра-
фик на 4 класса в зависимости от значения поля IP-приоритета (см. табл. 5.3).
Базовая сеть поставщика услуг построена на основе маршрутизаторов Cisco се-
рии 8450. Каждому классу соответствуют два значения IP-приоритета — по одному
для согласованного и избыточного трафика. Трафику классов 0-3 необходимо выде-
лить 15, 15, 30 и 40 процентов полосы пропускания канала связи, соответственно.
Для того чтобы активизировать режим QoS-коммутации в маршрутизаторах Cisco се-
рии 8450, воспользуйтесь командой qos switching. Стандартное распределение веса для
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
139
классов ToS 0-3 составляет 1, 2, 4 и 8, соответственно. Следовательно, классам ToS 0-3 бу-
дет выделено 1/15, 2/15, 4/15 и 8/15 частей эффективной полосы пропускания интерфейса.
[Таблица 5.3. Классификация трафика на основании IP-приоритета
Критический Элитный Стандартный (класс 3) (класс 2) (класс 1) Экономичный (класс 0)
Согласованный трафик Приоритет? Приоритет 6 Приоритет 5 Избыточный трафик Приоритет 3 Приоритет 2 Приоритет 1 Приоритет 4 Приоритет 0
В рассматриваемом случае распределение полосы пропускания для классов 0-3 со-
ставляет 15:15:30:40 или 3:3:6:8, поскольку алгоритм WRR допускает использование
веса только в диапазоне от 1 до 15.
В листинге 5.1 приведена глобальная конфигурация механизма MWRR на основе
классов ToS для маршрутизатора Cisco серии 8500.
Листинг 5.1. Глобальная конфигурация механизма MWRR на основе
классов ToS ;
qos switching
qos mapping precedence 0 wrr-weight 3
qos mapping precedence 1 wrr-weight 3
qos mapping precedence 2 wrr-weight 6
qos mapping precedence 3 wrr-weight 8
В листинге 5.2 приведена конфигурация механизма MWRR на основе классов ToS,
предназначенная для обработки трафика, поступающего и исходящего через заданный
интерфейс.
[ Листинг 5.2. Конфигурация механизма MWRR на основе классов ToS, '
J : - предназначенная для обработки заданного трафика .
qos switching
qos mapping <входной интерфейсу <выходной интерфейсу
precedence 0 wrr-weight 3
qos mapping <входной интерфейсу <выходной интерфейсу
precedence 1 wrr-weight 3
qos mapping <входной интерфейсу <выходной интерфейсу
precedence 2 wrr-weight 6
qos mapping <входной интерфейсу <выходной интерфейсу
precedence 3 wrr-weight 8
Модифицированный алгоритм кругового
обслуживания с дефицитом (MDRR)
В этом разделе рассматривается модифицированный алгоритм кругового обслужи-
вания с дефицитом (Modified Deficit Round Robin — MDRR), использующийся для
140 Часть I. Качество обслуживания в сетях IP
распределения ресурсов в маршрутизаторах Cisco серии 12000. В соответствии с DRR-
планировшиком2 каждая очередь характеризуется связанным с ней квантовым значе-
нием (quantum value) — средним числом байтов, обслуживаемых на каждом цикле — и
счетчиком дефицита, начальное значение которого устанавливается равным квантово-
му значению. Каждая непустая очередь обрабатывается по круговому принципу. Сум-
ма размеров обслуживаемых за один цикл пакетов примерно равняется квантовому
значению очереди. Обработка пакетов очереди производится до тех пор, пока значе-
ние счетчика дефицита остается больше нуля. В результате обслуживания каждого па-
кета значение счетчика дефицита очереди уменьшается на величину, равную размеру
пакета в байтах. Когда значение счетчика дефицита становится меньше нуля или рав-
ным нулю, DRR-планировщик переходит к обработке следующей очереди. Следует
отметить, что в каждом новом цикле значение счетчика дефицита увеличивается на
величину, равную квантовому значению.
После обслуживания очереди значение ее счетчика дефицита представляет собой
размер дебета, зависящего от того, превысило ли число обработанных на предыдущем
цикле байтов квантовое значение очереди. Объем данных, которые будут обработаны
в следующем цикле обслуживания очереди, рассчитывается как разность квантового
значения и счетчика дефицита.
С целью повышения эффективности механизма MDRR квантовое значение должно
равняться размеру в байтах пакета максимального объема. Это дает гарантию, что DRR-
планировщик всегда будет обслуживать по меньшей мере один пакет из каждой очереди.
Примечание
Значение счетчика дефицита пустой очереди всегда сбрасывается в нуль, что позво-
ляет избежать его чрезмерного аккумулирования, неизбежно ведущего к неравномер-
ному обслуживанию различных очередей.
Описанный выше обобщенный алгоритм DRR модифицируется посредством добавле-
ния так называемой очереди с малой задержкой (low-latency queue). В соответствии с алго-
ритмом MDRR все очереди, за исключением очереди с малой задержкой, обслуживаются
по круговому принципу. Очередь с малой задержкой может обслуживаться в двух режимах:
режиме строгого приоритета и режиме чередующегося приоритета.
В режиме строгого приоритета (strict priority mode) очередь с малой задержкой об-
служивается при наличии в ней хотя бы одного пакета, что обуславливает минималь-
но возможную задержку для обрабатывающегося с помощью этой очереди класса тра-
фика. В то же время следует отметить, что высокоприоритетная очередь с малой за-
держкой способна на продолжительный период времени занять 100 процентов полосы
пропускания интерфейса и тем самым “подавить” оставшиеся MDRR-очереди.
В режиме чередующегося приоритета (alternate priority mode) очередь с малой за-
держкой обрабатывается в промежутках между обработкой оставшихся очередей.
В дополнение к очереди с малой задержкой алгоритм MDRR поддерживает еще семь
очередей. Предположим, что очередь с малой задержкой имеет номер 0. Тогда в соот-
ветствии с режимом чередующегося приоритета очереди механизма MDRR обслужи-
ваются в следующем порядке: 0, 1,0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7.
2 Efficient Fair Queuing using Deficit Round Robin/Shreedhar M., Varghese G. — SIGCOMM
1995, p. 231-242.
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
141
Режим чередующегося приоритета позволяет снизить максимальную задержку об-
служивания очереди 0 с суммы квантовых значений (что было бы в случае традици-
онного механизма кругового обслуживания) до максимального квантового значения
всех оставшихся очередей.
Кроме снижения эффективности алгоритм MDRR, в отличие от алгоритма DRR,
использует нетрадиционную схему кругового обслуживания очередей. Так, в соответ-
ствии с алгоритмом MDRR задержка обслуживания одной выбранной пользователем
очереди ограничивается с целью уменьшения дрожания трафика.
Пример работы алгоритма MDRR
Предположим, что алгоритм MDRR используется для обслуживания трех очередей —
очереди 2, очереди 1 и очереди 0, — вес которых равняется 1, 2 и 1, соответственно. Оче-
редь 2 представляет собой очередь с малой задержкой, обслуживаемой в режиме чередую-
щегося приоритета. Схематическое изображение очередей с указанием соответствующих
им значений счетчиков дефицита представлено на рис. 5.10.
Очередь 2
500 1500 500
Очередь 1
500 1500 500 1500
Очередь 0
1500 500 1500
Очередь Счетчик дефицита
2 0
1 0
0 0
Рис. 5.10. MDRR-очереди и соответствующие им значения счетчи-
ков дефицита до начала обслуживания
Вес и квантовое значение каждой очереди приведены в табл. 5.4.
i Таблица 5.4. Вес и квантовые значения очередей, обслуживаемых
j ! с помощью алгоритма MDRR j
Номер очереди Вес Квантовое значение = вес х MTU (MTU = 1500 байт)
Очередь 2 1 1500
Очередь 1 2 3000
Очередь 0 1 1500
142
Часть I. Качество обслуживания в сетях IP
Когда механизм MDRR сконфигурирован на выходном интерфейсе маршрутизатора, в
качестве максимального размера единицы передачи информации (Maximum Transmission
Unit — MTU) используется соответствующее значение MTU этого интерфейса.
Первой обслуживается очередь 2. При инициализации счетчика дефицита ему при-
сваивается значение 1500, равное квантовому значению очереди. Очередь 2 обслужи-
вается до тех пор, пока соответствующее ей значение счетчика дефицита остается
больше нуля. После обслуживания пакета значение счетчика дефицита очереди 2
уменьшается на величину, равную размеру пакета в байтах. Поскольку текущее значе-
ние счетчика дефицита (1500) больше нуля, планировшик MDRR обслуживает распо-
ложенный во главе очереди 2 500-байтовый пакет. Новое значение счетчика дефицита
очереди 2 становится равным 1500 - 500 = 1000. Поскольку новое значение счетчика
дефицита все еще больше нуля, планировшик MDRR приступает к обслуживанию
следующего пакета очереди. В результате передачи 1500-байтового пакета значение
счетчика дефицита уменьшается до 1000 - 1500 =-500, после чего MDRR-
планировщик переходит к обслуживанию следующей очереди. Состояние очередей и
соответствующих им значений счетчиков дефицита после окончания обслуживания
очереди 2 схематически представлено на рис. 5.11.
Очередь 2
lob
Рис. 5.11. Состояние очередей и соответствующих им значений
счетчиков дефицита после первого цикла обслуживания очереди 2
Поскольку обслуживание очереди 2 осуществляется в режиме чередующегося при-
оритета, MDRR-планировщик переходит к обработке другой очереди, номер которой
выбирается в соответствии с круговым принципом. Предположим, что подошел черед
обслуживания очереди 0. При инициализации счетчика дефицита ему присваивается
значение 1500, равное квантовому значению очереди 0. В результате обслуживания
1500-байтового пакета значение счетчика дефицита уменьшается до 1500 - 1500 = 0.
В соответствии с алгоритмом MDRR планировщик завершает обслуживание очере-
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
143
ди 0. Состояние очередей и соответствуюших им значений счетчиков дефицита после
окончания обслуживания очереди 0 схематически представлено на рис. 5.12.
Рис. 5.12. Состояние очередей и соответствующих им значений счет-
чиков дефицита после первого цикла обслуживания очереди О
Поскольку режим чередующегося приоритета предполагает постоянное пере-
ключение MDRR-планировщика между очередью с малой задержкой и
очередями, обрабатываемыми в соответствии с круговым принципом, следующей
обслуживается очередь 2. Новое значение счетчика дефицита становится равным
-500 + 1500 = 1000. Поскольку значение счетчика дефицита больше нуля, MDRR-
планировщик приступает к обслуживанию следующего пакета очереди 2. В ре-
зультате передачи 500-байтового пакета значение счетчика дефицита уменьшается
до 500. Несмотря на то что MDRR-планировщик мог бы обслужить как минимум
еще один пакет очереди 2, это не представляется возможным, так как очередь
пуста. Поэтому значение счетчика дефицита очереди 2 устанавливается равным
нулю. Поскольку пустая очередь не обрабатывается MDRR-планировщиком, зна-
чение счетчика дефицита очереди 2 остается равным нулю до постановки в эту
очередь следующего пакета. Состояние очередей и соответствующих им значений
счетчиков дефицита после окончания обслуживания очереди 2 схематически
представлено на рис. 5.13.
Следующей обслуживается очередь 1, значение счетчика дефицита которой устанавли-
вается равным 3000. MDRR-планировшик передает три пакета очереди 1, в результате чего
значение ее счетчика дефицита уменьшается до 3000 - 1500 - 500 - 1500 = -500. Состояние
очередей и соответствующих им значений счетчиков дефицита после окончания обслужи-
вания очереди 1 схематически представлено на рис. 5.14.
144
Часть I. Качество обслуживания в сетях IP
Очередь 2
Рис. 5.13. Состояние очередей и соответствующих им значений счетчи-
ков дефицита после второго цикла обслуживания очереди 2
Очередь 2
Очередь Счетчик дефицита
2 0
1 -500
0 0
Рис. 5.14. Состояние очередей и соответствующих им значений
счетчиков дефицита после первого цикла обслуживания очереди 1
В результате обслуживания двух пакетов очереди 0 значение ее счетчика дефицита
становится равным 1500 - 1000 - 1500 = -500. Поскольку очередь 0 становится пустой,
соответствующее значение счетчика дефицита сбрасывается в нуль. Состояние очере-
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
145
дей и соответствующих им значений счетчи"ов дефицита после окончания обслужи-
вания очереди 0 схематически представлено на рис. 5.15.
Очередь 2
Очередь 1
166
Очередь О
Очередь Счетчик дефицита
2 0
1 -500
0 0
Рис. 5.15. Состояние очередей и соответствующих им значений счетчи-
ков дефицита после второго цикла обслуживания очереди О
На следующем шаге MDRR-планировщик обрабатывает последний пакет очере-
ди 1. Поскольку очередь 1 становится пустой, соответствующее ей значение счетчика
дефицита сбрасывается в нуль.
Реализация алгоритма MDRR
Модифицированный алгоритм кругового обслуживания с дефицитом (Modified
Deficit Round Robin — MDRR) реализован в маршрутизаторах Cisco серии 12000. Ме-
ханизм MDRR может быть сконфигурирован для обслуживания либо очереди выход-
ного интерфейса (выходной блок маршрутизатора — ТХ), либо очереди входного ин-
терфейса (входной блок маршрутизатора — RX) при функционировании в режиме по-
дачи очередей коммутационной матрицы маршрутизатора на выходной интерфейс.
Существуют различные аппаратные версии линейных плат маршрутизаторов се-
рии 12000, называемые моделями 0, 1, 2, 3 и т.д. Способ реализации алгоритма
MDRR зависит от версии линейной платы. Так, модель 0 поддерживает всего лишь
программную реализацию алгоритма MDRR, в то время как модели 2 и выше под-
держивают аппаратные реализации алгоритма MDRR.
Реализация алгоритма MDRR в RX-блоке маршрутизатора
Как уже отмечалось выше в этой главе, линейные платы маршрутизаторов поддер-
живают как программные, так и аппаратные реализации алгоритма MDRR. В соответ-
ствии с программной реализацией алгоритма MDRR каждая линейная плата передает
трафик в 16 сегментов назначения, поскольку в маршрутизаторах Cisco серии 1200
146
Часть I. Качество обслуживания в сетях IP
используется коммутационная матрица размером 16x16. Каждому сегменту назначе-
ния коммутационной матрицы соответствует восемь CoS-очередей. Легко подсчитать,
что общее число CoS-очередей равняется 128 (16 х 8). Каждая CoS-очередь может
быть сконфигурирована независимо от других.
Согласно аппаратной реализации алгоритма MDRR, каждая линейная плата поддержи-
вает восемь CoS-очередей на каждом интерфейсе назначения. Принимая во внимание
число сегментов назначения (16) и число соответствующих каждому сегменту интерфейсов
(16), максимальное количество CoS-очередей равняется 16 х 16 х 8 = 2048. Следует отме-
тить, что все интерфейсы определенного сегмента назначения имеют одинаковые CoS-
параметры.
Реализация алгоритма MDRR в ТХ-блоке маршрутизатора
Каждому интерфейсу соответствует восемь CoS-очередей, которые могут быть
сконфигурированы независимо друг от друга как в аппаратной, так и в программной
реализации алгоритма MDRR.
Реализация алгоритма MDRR предусматривает гибкое отображение множества
значений поля IP-приоритета на множество доступных очередей. Поскольку макси-
мальное количество очередей, поддерживаемых механизмом MDRR, равняется 8, тра-
фик каждого приоритета может обрабатываться с помощью отдельной очереди. Следу-
ет отметить, что необходимое количество очередей так же, как и способ отображения
между доступными очередями и значениями поля IP-приоритета, может быть опреде-
лено пользователем. При желании одна очередь может использоваться для обработки
потоков трафика различного приоритета.
Механизм MDRR предусматривает индивидуальный подход при определении по-
литики отбрасывания пакетов и полосы пропускания очереди. Каждая очередь харак-
теризуется собственными параметрами механизма произвольного раннего обнаруже-
ния (Random Early Detection — RED), обусловливающими пороги отбрасывания и
квантовое значение DRR, от которого зависит ширина выделенной очереди полосы
пропускания. Квантовое значение (другими словами, среднее число байтов очереди,
обслуживаемое на каждом цикле) может быть определено пользователем.
Практический пример 5.2: выделение полосы
пропускания и минимизация дрожания голосового
трафика в рамках политики предотвращения перегрузки
В зависимости от важности трафика он разбивается на различные классы, характе-
ризующиеся минимальной гарантируемой полосой пропускания. Поставщик услуг
Internet определяет пять классов трафика: “золотой”; “серебряный”; “бронзовый”;
трафик, передающийся методом негарантированной доставки; голосовой трафик
(требующий как можно более низкого уровня дрожания).
Сетевому администратору необходимо настроить параметры пяти очередей: четырех (0-
3) — для трафика классов “золотой”, “серебряный”, “бронзовый”, а также трафика, пере-
даваемого методом негарантированной доставки, и одной — для голосового трафика.
В листинге 5.3 приведена конфигурация трех ОСЗ-интерфейсов PoS (Point-to-Point
(PPP) over Synchronous Optical Network (SONET) — протокол двухточечного взаимодейст-
вия через синхронную оптическую сеть), относящихся к сегментам назначения 1-3.
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
147
[ Листинг 5.3. Определение классов трафика и назначение им соответст-
। вующих очередей с гарантированной минимальной полосой
i пропускания во время перегрузки сети
interface POS1/0
tx-cos cos-a
interface POS2/0
tx-cos cos-a
interface POS3/0
tx-cos cos-a
slot-table-cos table-a
destination-slot 0 cos-a
destination-slot 1 cos-a
destination-slot 2 cos-a
rx-cos-slot 1 table-a
rx-cos-slot 2 table-a
rx-cos-slot 3 table-a
cos-queue-group cos-a
precedence all random-detect-label 0
precedence 0 queue 0
precedence 1 queue 1
precedence 2 queue 2
precedence 3 queue 3
precedence 4 queue low-latency
precedence 5 queue 0
random-detect-label 0 50 200 2
exponential-weighting-constant 8
queue 0 10
queue 1 20
queue 2 30
queue 3 40
queue low-latency strict-priority 20
В ТХ-блоке интерфейсов PoSl/0, PoS2/0 и PoS3/0 сконфигурирована политика CoS,
заданная с помощью команды cos-queue group cos-a. Трафик распределяется по классам в
зависимости от значения поля IP-приоритета пакетов. Каждый из пяти классов трафика
обрабатывается с помощью отдельной очереди, которая характеризуется рассчитанным на
основе выделяемой этому классу минимальной полосы пропускания весом. Полосы про-
пускания очередей 0-3 и очереди с малой задержкой составляют пропорцию
8.33:16.67:25:33.33:16.67. Следует отметить, что голосовой трафик является чувствительным
к уровню задержки, однако не столь требовательным к ширине полосы пропускания. По-
этому для его обработки требуется очередь с малой задержкой, характеризующаяся не
слишком высокими требованиями к пропускной способности.
148
Часть I. Качество обслуживания в сетях IP
Сеть поставщика услуг предназначена для обслуживания трафика с приоритетом от
О до 4. IP-приоритет 5 зарезервирован для трафика, передающегося методом негаран-
тированной доставки, который обрабатывается с помощью очереди 0. IP-приоритет 6
и 7 соответствует управляющим пакетам, сгенерированным маршрутизатором. Управ-
ляющие пакеты имеют внутреннюю метку и всегда передаются первыми, независимо
от конфигурации механизма MDRR.
Команда cos-queue-group cos-a предназначена для конфигурирования политики предот-
вращения перегрузки сети WRED (Weighted Random Early Detection — взвешенный алго-
ритм произвольного раннего обнаружения), параметры которой приведены ниже:
• минимальное пороговое значение: 50 пакетов;
• максимальное пороговое значение: 200 пакетов;
• вероятность отбрасывания пакетов при достижении максимального порогового
значения: J = 50 процентов;
• экспоненциальная весовая константа, использующаяся для расчета глубины
очереди: 8.
Более подробно алгоритм WRED рассматривается в главе 6, “РНВ-политика:
предотвращение перегрузки и политика отбрасывания пакетов”, далее в этой книге.
Механизм MDRR может быть сконфигурирован на линейной плате входного ин-
терфейса с целью обслуживания очередей коммутационной матрицы, использующих-
ся для передачи пакета линейной плате назначения. Команда slot-table-cos применяет-
ся для определения политики каждой из CoS-очередей линейных плат назначения на
входной линейной плате. В рассматриваемом нами примере команда slot-table-cos
table-a определяет политику CoS (см. выше команду cos-queue-group cos-a) для линей-
ных плат назначения 0-2. Следует отметить, что линейная плата назначения и вход-
ная линейная плата на самом деле могут оказаться одними и теми же платами, по-
скольку на одной линейной плате может существовать как входной, так и выходной
интерфейс, обслуживающие определенный тип трафика.
С помощью команды rx-cos-slot команда slot-table-cos table-a применяется к опре-
деленному сегменту (линейной плате). В листинге 5.4 приведена соответствующая
конфигурация маршрутизатора.
. Листинг 5.4. Информация о политике CoS
Routerflshow Interface РО1/0 Р02/0 РОЗ/О cos Queue Cos Group cos-a cos-a cos-a
Rx Slot 1 2 3 Slot Table table-a table-a table-a
Slot Table Name - table-0
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
149
1 cos-a
2 cos-a
3 cos-a
Cos Queue Group - cos-a
precedence all mapped label 0
red label 0
min thresh 100, max thresh 300 max prob 2
exponential-weighting-constant 8
queue 0 weight 10
queue 1 weight 20
queue 2 weight 40
queue 3 weight 80
queue 4 weight 10
queue 5 weight 10
queue 6 weight 10
low latency queue weight 20, priority strict
Обратите внимание, что очереди 4-6 являются пустыми, поскольку им не со-
ответствует ни одно значение IP-приоритета. В то же время очереди 0-3 и оче-
редь с малой задержкой используются для обработки трафика определенного типа
и характеризуются минимальной гарантированной полосой пропускания, задан-
ной с помощью веса.
Для того чтобы получить информацию о входных и выходных CoS-очередях,
воспользуйтесь командой линейной платы show controllers frfab/tofab cos-queue
length/parameters/variables.
Резюме
В этой главе были рассмотрены два новых алгоритма обслуживания очередей, ис-
пользующихся для распределения ресурсов: модифицированный взвешенный алго-
ритм кругового обслуживания (Modified Weighted Round Robin — MWRR) и модифи-
цированный алгоритм кругового обслуживания с дефицитом (Modified Deficit Round
Robin — MDRR). По способу планирования очередей алгоритмы MWRR и MDRR
весьма сходны с алгоритмом WFQ. При необходимости механизмы MWRR и MDRR
посредством применения очереди со строгим приоритетом могут быть сконфигуриро-
ваны для обработки голосового трафика. В настоящее время алгоритмы MWRR и
MDRR реализованы в коммутаторах Cisco семейства Catalyst и в маршрутизаторах
Cisco серии 12000, соответственно.
Ответы на часто задаваемые вопросы
Каким образом механизм обслуживания очепедей влияет на распределение ресурсов?
Механизм обслуживания очередей планирует порядок обработки поставленных в
очередь пакетов. Частота обработки пакетов заданного потока трафика и определяет
выделенный этому потоку объем ресурсов (полосу пропускания).
150
Часть I. Качество обслуживания в сетях IP
Можно ли использовать механизмы MWRR и MDRR для обслуживания голосового
трафика?
Да. Путем применения очереди со строгим приоритетом механизмы MWRR и
MDRR могут быть сконфигурированы для обработки голосового трафика. Очередь со
строгим приоритетом обеспечивает обслуживание с малой задержкой для трафика
масштаба реального времени.
В чем состоит сходство алгоритмов MWRR и MDRR с алгоритмом WFQ?
Алгоритмы WFQ, MWRR и MDRR являются алгоритмами распределения ресурсов.
Способ планирования очередей алгоритмов MWRR и MDRR похож на способ плани-
рования очередей алгоритма WFQ, поскольку все три алгоритма моделируют обоб-
щенную схему разделения процессорного времени (GPS). Более подробно схема GPS
рассматривалась в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”.
Глава 5. РНВ-политика: распределение ресурсов (часть 2)
151
В этой главе... Xv -
Механизм медленного старта и предотвращение перегрузки 154
Реакция TCP-трафика на применение политики
“отбрасывания хвоста” 155
RED — алгоритм превентивного управления очередью
с целью предотвращения перегрузки сети 156
Взвешенный алгоритм произвольного раннего обнаружения (WRED) 160
Алгоритм WRED на основе потока 164
Механизм явного уведомления о перегрузке (ECN) . 167
; Механизм избирательного отбрасывания пакетов (SPD) 168
Глава
6
РНВ-политика:
предотвращение перегрузки
и политика отбрасывания
пакетов ;
Политика отбрасывания пакетов (packet drop policy) представляет собой алгоритм
управления очередью, применяющийся для регулирования ее длины. Традиционный
алгоритм обслуживания очередей‘“первым пришел, первым обслужен” (fist-in, first-
out — FIFO) использует достаточно простую политику “отбрасывания хвоста” (tail
drop policy), в соответствии с которой любая попытка постановки пакета в полную
очередь неминуемо завершится его отбрасыванием.
В настоящий момент основным транспортным протоколом Internet является
протокол управления передачей (Transmission Control Protocol — TCP). В этой главе
рассматриваются механизмы предотвращения перегрузки протокола TCP, а также ре-
акция TCP-трафика на применение политики “отбрасывания хвоста”. Кроме того, мы
познакомимся с алгоритмом активного управления очередью RED (Random Early De-
tection — алгоритм произвольного раннего обнаружения), позволяющим предотвра-
тить перегрузку сети путем превентивного отбрасывания пакетов с целью уведомле-
ния о возможной перегрузке источников TCP-соединения посредством механизма
сквозного адаптивного управления с обратной связью.
В этой главе также рассматривается взвешенный алгоритм произвольного раннего обнару-
жения (Weighted Random Early Detection — WRED), позволяющий настраивать различные
RED-параметры в зависимости от значения поля IP-приоритета или класса трафика. Алго-
ритм WRED на основе потока (flow WRED) представляет собой расширение алгоритма
WRED, предусматривающее возможность назначения штрафа с ненулевой вероятностью
тем потокам, которые пытаются завладеть слишком большой долей доступных ресурсов.
Алгоритм явного уведомления о перегрузке (Explicit Congestion Notification — ECN) позволяет
предупредить TCP-источник о начинающейся перегрузке сети путем маркировки (а не от-
брасывания) пакетов. Описание принципов работы обоих названных выше алгоритмов
можно найти далее в этой главе. И, наконец, в конце главы рассматривается алгоритм из-
бирательного отбрасывания пакетов (Selective Packet Discard — SPD), который применяется
для управления очередью IP-процесса маршрутизатора.
Механизм медленного старта
и предотвращение перегрузки
С целью поддержки механизма предотвращения заторов в сети источники ТСР-
соединения используют так называемое окно перегрузки (congestion window — cwnd).
Инициализация окна перегрузки осуществляется в момент установки TCP-сеанса. В
соответствии с механизмом медленного старта начальное значение окна перегрузки
устанавливается равным одному сегменту (максимальный размер сегмента (maximum
segment size — MSS) либо сообщается источником на другом конце ТСР-соединения,
либо устанавливается равным стандартному значению и, как правило, составляет 536
или 512 байт). Значение окна перегрузки представляет собой максимальный размер
данных, которые может переслать TCP-отправитель в рамках заданного сеанса без по-
лучения подтверждения о доставке.
При получении подтверждения о доставке первого пакета TCP-источник увеличивает
размер окна перегрузки до 2, что указывает на возможность отправки уже двух пакетов.
Аналогично, при получении подтверждения о доставке двух пакетов TCP-источник увели-
чивает размер окна перегрузки до 4. Таким образом, рост размера окна перегрузки являет-
ся экспоненциальным. Следует отметить, что на самом деле рост размера окна перегрузки
может и не быть строго экспоненциальным, поскольку TCP-получатель, как правило, не
посылает подтверждение о доставке каждого пакета, а использует так называемые под-
тверждения с задержкой (подтверждение о получении двух пакетов). Описанное поведение
источников ТСР-соединения подчиняется алгоритму медленного старта, в соответствии с
которым TCP-источник передает в сеть пакеты с интенсивностью, равной интенсивности
получения подтверждений о доставке пакетов от TCP-получателя. Это делает протокол
TCP самосинхронизирующимся (self-clocking) транспортным протоколом.
В соответствии с протоколом TCP сигналом о перегрузке сети является потеря па-
кета. TCP-источник обнаруживает перегрузку при отсутствии подтверждения о дос-
тавке пакета в течение заданного промежутка времени, называемого оценочным вре-
менным лимитом таймера повторной передачи (retransmit timer timeout — RTT).
В сложившейся ситуации TCP-источник сбрасывает значение размера окна перегрузки
до одного сегмента и перезапускает алгоритм медленного старта. Кроме этого, он также
уменьшает пороговое значение алгоритма медленного старта (slow start threshold — ssthresh)
до величины, равной половине размера окна перегрузки в момент повторной передачи
пакета. Следует отметить, что при установке TCP-сеанса значение параметра ssthresh
устанавливается равным либо размеру окна получателя, сообщенного ТСР-источником
на другом конце соединения, либо стандартному значению в 65535 байт.
После достижения временного лимита таймера повторной передачи (RTT) отпра-
витель следует алгоритму медленного старта до тех пор, пока размер окна перегрузки
не достигнет величины ssthresh. Начиная с этого момента размер окна увеличивается
линейно (с коэффициентом 1/cwnd) по мере получения подтверждений о доставке па-
кета. Замедление роста размера окна перегрузки вызвано тем, что значение параметра
ssthresh представляет собой оценку доступной полосы пропускания данного ТСР-
соединения. Пример работы алгоритма медленного старта и алгоритма предотвраще-
ния перегрузки1 схематически представлен на рис. 6.1.
1 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms/Stevens Ж —
NOAO, RFC 2001.
154
Часть I. Качество обслуживания в сетях IP
Размер
окна
перегрузки
(cwnd)
1 — медленный старт
2 — временной лимит теймера повторной передечи (RTT)
3 — предотвращение перегрузки/линейный рост размера окна
2 Размер окна перегрузки получателя
Время
Рис. 6.1. Изменение размера ТСР-ок„а в соответствии с алгоритмами мед-
ленного старта и предотвращения перегрузки
Когда потеря пакета вызвана не перегрузкой сети, ожидание превышения временного
лимита повторной передачи пакета (RTT) может весьма негативным образом сказаться на
производительности TCP-соединения, что особенно характерно для высокоскоростных се-
тей. Для того чтобы избежать подобного развития ситуации, протокол TCP использует ал-
горитм быстрой повторной передачи и алгоритм быстрого восстановления.
Реакция TCP-трафика на применение политики
“отбрасывания хвоста”
Традиционная политика обработки пакетов, которые должны быть поставлены в
очередь, достигшую своего максимального размера, заключается в их отбрасывании.
Подобная “дискриминация” пакетов продолжается до тех пор, пока длина очереди не
уменьшится за счет передачи уже находящихся в ней пакетов^ Алгоритм управления
очередью, в соответствии с которым любая попытка постановки пакета в полную оче-
редь неминуемо завершится его отбрасыванием, получил название алгоритма
“отбрасывания хвоста ” (tail drop)2.
Поскольку отбрасывание пакета является сигналом о перегрузке сети для источника
TCP-соединения, механизм “отбрасывания хвоста” сообщает о перегрузке сети лишь в
момент фактического переполнения очереди. В результате отбрасывания пакета источник
TCP-соединения уменьшает размер окна до одного сегмента и перезапускает алгоритм
медленного старта, что приводит к резкому уменьшению исходящего ТСР-трафика.
Поскольку типичный магистральный маршрутизатор Internet или другой IP-сети
большого размера в отдельный момент времени обрабатывает тысячи ТСР-потоков,
применение алгоритма управления очередью “отбрасывание хвоста” может привести к
2 Recommendations on Queue Management am' Congestion Avoidance in the Internet/Braden B., Clark
D., Crowcroft J., Davie B., Deering S., Estrin D, Floyd S., Jacobson V., Minshall G., Partridge C,
Peterson L., Ramakrishnan K., Shenker S., Wroclawski J., Zhang L., April 1998.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 155
потере пакетов для очень большого числа TCP-соединений. Получив уведомления о
перегрузке сети, множество TCP-источников практически одновременно уменьшат
интенсивность передаваемого ими трафика, что приведет к резкому уменьшению раз-
мера очереди маршрутизатора.
Все TCP-источники, перезапустившие механизм медленного старта и сбросившие зна-
чение размера окна до одного сегмента, начнут экспоненциальное увеличение размеров
окна, ведущее к росту интенсивности обрабатываемого очередью трафика. Монотонное
увеличение интенсивности трафика приведет к переполнению очереди и отбрасыванию
пакетов. Таким образом, алгоритм “отбрасывания хвоста” и во второй раз приведет к по-
тере пакетов для очень большого числа TCP-соединений, а также к резкому уменьшению
размеров очереди. По мере увеличения размеров TCP-окна всех источников, перезапус-
тивших механизм медленного старта, интенсивность обрабатываемого очередью трафика
будет расти, что вскорости приведет к уже известному сценарию развития событий.
Периодическое резкое снижение интенсивности трафика и перегрузка сети приво-
дят к волноподобному изменению размера очереди, получившему название эффекта
глобальной синхронизации (global synchronization). Эффект глобальной синхронизации
схематически представлен на рис. 6.2.
Размер
очереди
1. В результате выполнения алгоритма "отбрасывания хвоста"
одновременно достаточно большое число ТСР-источников
сужают размер окна перегрузки до 1 и перезапускают механизм
Рис. 6.2. Эффект глобальной синхронизации
Эффект глобальной синхронизации обязан своим названием одновременному
(синхронному) перезапуску алгоритмов медленного старта множества ТСР-источников,
вызванного работой алгоритма “отбрасывания хвоста”. Помимо нежелательного измене-
ния размеров очереди, этот эффект способен также привести к возрастанию дрожания за-
держки трафика и снижению пропускной способности всей сети.
RED — алгоритм превентивного управления
очередью с целью предотвращения
перегрузки сети
С поведением ТСР-источников в моменты работы алгоритма “отбрасывания хво-
ста” связана необходимость проведения превентивного управления очередью с целью
156
Часть I. Качество обслуживания в сетях IP
сигнализации о перегрузке сети до фактического переполнения очереди и контроля за
размером очереди с целью снижения задержки обработки пакетов. Алгоритм произ-
вольного раннего обнаружения (Random Early Detection — RED) представляет собой
алгоритм предотвращения перегрузки, предложенный Салли Флойдом (Sally Floyd) и
Ваном Якобсоном (Van Jacobson)3. Данный механизм активного управления очередью
обладает существенными преимуществами по сравнению с традиционным механиз-
мом “отбрасывания хвоста”.
Как уже упоминалось ранее, механизм RED использует превентивный подход к
предотвращению перегрузки сети. Вместо ожидания фактического переполнения оче-
реди, RED начинает отбрасывать пакеты с ненулевой вероятностью, когда средний
размер очереди превысит определенное минимальное пороговое значение. Вероятно-
стный подход к отбрасыванию пакетов позволяет быть уверенным в том, что меха-
низм RED отбросит пакеты всего лишь нескольких произвольно выбранных потоков,
тем самым помогая избежать эффекта глобальной синхронизации. Напомним, что от-
брасывание пакета представляет собой сигнал TCP-источнику о необходимости
уменьшить интенсивность передаваемого трафика для соответствующего потока, что
достигается за счет перезапуска алгоритма медленного старта.
Если средний размер очереди будет продолжать увеличиваться несмотря на отбрасы-
вание произвольных пакетов, то это приведет к линейному росту вероятности отбрасы-
вания. В соответствии с механизмом RED вероятность отбрасывания пакетов растет
прямо пропорционально увеличению среднего размера очереди от минимального до
максимального порогового значения. Средний размер очереди строго ограничен макси-
мальным пороговым значением, поскольку в этом случае вероятность отбрасывания па-
кетов достигает своего наибольшего значения (100 процентов). Другими словами, глав-
ная цель механизма произвольного раннего обнаружения (RED) заключается в миними-
зации среднего размера очереди, а значит, и обшей задержки трафика.
Определение вероятности отбрасывания пакета базируется на взвешенном экспо-
ненциальном значении среднего размера очереди, вычисление которого более под-
робно рассматривается в разделе “Алгоритм вычисления среднего размера очереди”
далее в этой главе. Это позволяет избежать предвзятого отношения механизма RED к
характеризующимся кратковременными всплесками потокам трафика в условиях про-
должительной перегрузки сети.
Если же средний размер очереди весьма невелик и находится ниже минимального
порогового значения, механизм RED не способен обеспечить существенного преиму-
щества по сравнению с традиционными механизмами управления очередью. С другой
стороны, при затяжном периоде перегрузки сети поведение механизма RED, несмотря
на длинную очередь и высокое максимальное пороговое значение, аналогично пове-
дению классического механизма “отбрасывания хвоста”. Таким образом, основное
предназначение механизма RED заключается в сглаживании временных всплесков
трафика и предупреждении длительной перегрузки сети посредством уведомления ис-
точников трафика о необходимости снижения интенсивности передачи информации.
Если источники проявят способность к взаимодействию и одновременно уменьшат
интенсивность передаваемого трафика, это поможет предотвратить перегрузку сети.
3 Floyd S., Jacobson V. Random Early Detection Gateways for Congestion Avoidance. — IEEE/ACM
Transactions on Networking, V.l N.4, August 1993, pp. 397-413.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 157
В противном случае средний размер очереди достаточно скоро достигнет мак-
симального порогового значения, что приведет к отбрасыванию всех поступаю-
щих пакетов.
Ниже перечислены некоторые из основных целей механизма раннего произволь-
ного обнаружения.
• Минимизация дрожания задержки пакетов путем контроля за средним разме-
ром очереди.
• Предотвращение эффекта глобальной синхронизации ТСР-трафика.
• Обеспечение непредвзятого обслуживания трафика, характеризующегося крат-
ковременными всплесками.
• Строгое ограничение максимального среднего размера очереди.
Фактически, механизм произвольного раннего обнаружения базируется на двух
следующих алгоритмах.
• Алгоритм вычисления среднего размера очереди. Определяет допустимый уровень
всплеска трафика в очереди.
• Алгоритм вычисления вероятности отбрасывания пакетов. Определяет вероятность
(частоту) отбрасывания пакетов для заданного среднего размера очереди.
Более подробно каждый из названных выше алгоритмов рассматривается в двух
следующих разделах этой главы.
Алгоритм вычисления среднего размера очереди
При определении вероятности отбрасывания пакетов механизм RED вычисляет не те-
кущий, а экспоненциально взвешенный средний размер очереди. Текущий средний размер
очереди определяется на основании предыдущего среднего и текущего действительного
размера. Использование механизмом RED среднего размера очереди обусловлено стремле-
нием реагировать только на продолжительную перегрузку сети и “не замечать” момен-
тальных всплесков трафика. Средний размер очереди вычисляется по формуле:
средний_размер_очереди = (предыдущий_средний_размерх(1 - 1/2") +
+ (текущий_размер_очереди х 1/2"),
где п — это экспоненциальный весовой коэффициент, определяемый пользователем.
Экспоненциальный весовой коэффициент является ключевым параметром, который
определяет относительный вклад предыдущего среднего и текущего размера очереди в но-
вый средний размер очереди. Практика показала, что наиболее приемлемым значением
экспоненциального весового коэффициента п является 9. Увеличение экспоненциального
весового коэффициента приведет к доминированию предыдущего среднего размера очере-
ди над ее текущим размером в аспекте вычисления нового среднего размера очереди. На-
против, уменьшение экспоненциального весового коэффициента приведет к возрастанию
значимости текущего размера очереди при вычислении ее нового среднего размера.
Большое значение коэффициента п обуславливает математическую близость но-
вого и предыдущего среднего размера очереди, а также позволяет механизму RED бо-
лее сдержанно реагировать на моментальные изменения в ее текущем размере, что
выражается в следующем поведении.
• Значение среднего размера очереди изменяется медленно, для него крайне не-
характерны резкие скачки.
158
Часть I. Качество обслуживания в сетях IP
• Механизм RED достаточно сдержанно относится к временным всплескам тра-
фика, стараясь выровнять текущий размер очереди.
• Механизм RED не спешит иници ровать процесс отбрасывания пакетов, кото-
рый, тем не менее, может продолжаться некоторое время после снижения дей-
ствительного размера очереди ниже минимального порогового значения.
• Если значение коэффициента п слишком велико, механизм RED может и вовсе
перестать реагировать на перегрузку сети, поскольку в этом случае текущий
размер очереди практически не будет влиять на вычисление ее среднего разме-
ра. Пакеты будут передаваться или отбрасываться так, как если бы механизм
RED и вовсе не использовался.
Напротив, маленькое значение коэффициента п обуславливает математическую
близость нового среднего и текущего размера очереди, что выражается в следующем
поведении механизма RED.
• Средний размер очереди изменяется очень быстро, для него характерна сильная
зависимость от флуктуаций потока трафика.
• Механизм RED немедленно реагирует на длинную очередь, однако как только
ее размер оказывается ниже минимального порогового значения, отбрасывание
пакетов прекращается.
• Если значение коэффициента п слишком мало, механизм RED начинает очень
остро реагировать на временные всплески трафика, что выражается в неоправ-
данном отбрасывании пакетов.
Алгоритм вычисления вероятности отбрасывания
пакетов
Вероятность отбрасывания пакетов представляет собой функцию, линейно завися-
щую от среднего размера очереди. Помимо этого, данная функция зависит также от
минимального порогового значения, максимального порогового значения и
знаменателя граничной вероятности (mark probability denominator), определяющего часть
отбрасываемых пакетов при достижении средним размером очереди максимального
порогового значения. Например, если знаменатель граничной вероятности равен 10,
то при достижении средним размером очереди максимального порогового значения
механизм RED будет отбрасывать 1 из 10 пакетов. Ниже приведена формула, по кото-
рой рассчитывается вероятность отбрасывания пакетов.
Вероятность отбрасывания пакетов = ((средний размер очереди - минимальное
пороговое значение) / (максимальное пороговое значение - минимальное пороговое
значение)) / знаменатель граничной вероятности.
Когда средний размер очереди превышает минимальное пороговое значение, ме-
ханизм RED начинает отбрасывать пакеты. Интенсивность отбрасывания пакетов воз-
растает прямо пропорционально возрастанию среднего размера очереди до тех пор,
пока он не достигнет максимального порогового значения.
Когда средний размер очереди превышает максимальное пороговое значение, ме-
ханизм RED отбрасывает все пакеты, предназначенные для постановки в очередь.
График вероятности отбрасывания пакетов схематически представлен на рис. 6.3.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 159
Вероятность
отбрасывания
пакетов
пороговое пороговое
значение значение
Средний размер очереди
Рис. 6.3. График вероятности отбрасывания пакетов механизмом RED
Взвешенный алгоритм произвольного раннего
обнаружения (WRED)
Взвешенный алгоритм произвольного раннего обнаружения (Weighted Random
Early Detection — WRED) предоставляет различные уровни обслуживания пакетов в
зависимости от вероятности их отбрасывания и обеспечивает избирательную установ-
ку параметров механизма RED на основании значения поля IP-приоритета. Другими
словами, алгоритм WRED предусматривает возможность более интенсивного отбрасы-
вания пакетов, принадлежащих определенным типам трафика, и менее интенсивного
отбрасывания всех остальных пакетов.
Реализация алгоритма WRED
Алгоритм WRED может выполняться как на центральном процессоре маршрутизато-
ра, так и в распределенном режиме на маршрутизаторах Cisco серии 7500, построенных
на базе интерфейсных плат V1P. По умолчанию все уровни приоритета трафика харак-
теризуются одинаковым максимальным пороговым значением и различными мини-
мальными пороговыми значениями. Таким образом механизм WRED обеспечивает бо-
лее интенсивное отбрасывание низкоприоритетных пакетов и менее интенсивное отбра-
сывание высокоприоритетных. Стандартное минимальное пороговое значение для
трафика приоритета 0 составляет половину максимального порогового значения.
Механизм WRED может быть сконфигурирован для обслуживания различных классов
трафика с помощью модульного интерфейса командной строки (CL1) QoS, который по-
зволяет определить параметры механизма RED отдельно для каждого класса. Более под-
робно модульный интерфейс командной строки QoS рассматривается в приложении А,
“Модульный интерфейс командной строки Cisco QoS”, далее в этой книге.
В маршрутизаторах Cisco серии 12000 алгоритм WRED присутствует как в программ-
ной, так и в аппаратной реализации в зависимости от версии линейной платы. Маршрути-
заторы Cisco серии 12000 характеризуются наличием восьми классов CoS-очередей. Каж-
дой CoS-очереди может быть поставлено в соответствие одно или несколько значений IP-
160
Часть I. Качество обслуживания в сетях IP
приоритета. После определения CoS-очередей вы можете сконфигурировать параметры
механизма RED отдельно для каждой CoS-очереди. Поскольку данная платформа Cisco
построена на базе коммутационной архитектуры, механизм RED может быть активизиро-
ван как для очередей коммутационной матрицы на принимающей стороне, так и для оче-
редей интерфейсов на передающей стороне. Более подробно конфигурация маршрутиза-
торов Cisco серии 12000 рассматривалась в практическом примере 5.2 в главе 5, “РНВ-
политика: распределение ресурсов (часть 2)”.
Практический пример 6.1: применение механизма WRED
для предотвращения перегрузки канала передачи
информации
Поставщик услуг предлагает своим клиентам четыре класса обработки трафика:
“платиновый”, “золотой”, “серебряный” и “бронзовый”. Дифференцирование трафи-
ка осуществляется в базовой сети поставщика услуг посредством установки значения
поля IP-приоритета (4, 3, 2 и 1 в зависимости от оплаченного клиентом уровня об-
служивания). Наряду с приоритетным трафиком сеть поставщика услуг поддерживает
обработку трафика методом негарантированной доставки (IP-приоритет 0). Каналы
поставщика услуг, соединяющие его с другими 1SP верхнего уровня, состоящими с
ним в отношении соседства, испытывают перегрузку и, следовательно, нуждаются в
применении политики отбрасывания пакетов.
С целью предотвращения перегрузки сетевой администратор должен сконфигури-
ровать механизм активного управления очередью WRED на всех интерфейсах, соеди-
няющих поставщика услуг с соседними 1SP. Конфигурация механизма WRED осуще-
ствляется посредством применения команды random-detect.
Обратите внимание, что минимальное пороговое значение механизма WRED, со-
ответствующее высокоприоритетному трафику, должно быть большим, чем мини-
мальное пороговое значение низкоприоритетного трафика. Выполнение этого условия
необходимо для обеспечения строгой очередности отбрасывания пакетов, согласно ко-
торой первыми начинают отбрасываться низкоприоритетные пакеты.
В листингах 6.1 и 6.2 приведены параметры механизма WRED и статистика отбра-
сывания пакетов, полученные путем выполнения команды show queueing random-detect,
при выполнении алгоритма WRED на центральном процессоре маршрутизатора Cisco
серии 7200 и в распределенном режиме на процессоре интерфейсной платы V1P мар-
шрутизатора Cisco серии 7500, соответственно.
' Листинг 6.1. Статистика выполнения алгоритма WRED на центральном 1
процессоре низкопроизводительного маршрутизатора Cisco
серии 7200 и в нераспределенном режиме на центральном
процессоре маршрутизатора Cisco серии 7500
Router#show queueing random-detect
Hssi3/0/0
Queueing strategy: random early detection (WRED)
Exp-weight-constant: 9 (1/512)
mean queue depth: 40
drops: class random tail min-th max-th mark-prob
0 13783 174972 20 40 1/10
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 161
1 14790 109428 22 40 1/10
2 14522 119275 24 40 1/10
3 14166 128738 26 40 1/10
4 13384 138281 28 40 1/10
5 12285 147148 31 40 1/10
6 10893 156288 33 40 1/10
7 9573 166044 35 40 1/10
rsvp 0 0 37 40 1/10
Когда алгоритм WRED выполняется на центральном процессоре маршрутизатора,
то он применяется к выходной очереди интерфейса, а пороговые значения определя-
ются следующим образом.
• Минимальное пороговое значение для трафика с приоритетом i. Минимальное по-
роговое значение для трафика с приоритетом i вычисляется по формуле:
(1/2 + i/18) х размер выходной очереди удержания.
• Максимальное пороговое значение. Равняется размеру выходной очереди удержания.
В результате выполнения команды show queueing random-detect на экран выводится
следующая статистика обработки пакетов.
• Статистика произвольного отбрасывания пакетов (параметр random и Random drop).
Количество пакетов, отброшенных механизмом WRED при условии нахожде-
ния среднего размера очереди между минимальным и максимальным порого-
вым значением.
• Статистика отбрасывания пакетов в соответствии с алгоритмом “отбрасывания
хвоста” (параметр tail и Tail drop). Количество пакетов, отброшенных меха-
низмом WRED при условии превышения средним размером очереди макси-
мального порогового значения.
• Граничная вероятность (параметр mark-prob и Mark probability). Вероятность от-
брасывания пакетов в момент достижения средним размером очереди макси-
мального порогового значения.
; Листинг 6.2. Статистика выполнения алгоритма WRED в распределенном
режиме на маршрутизаторе Cisco серии 7500, построенном
на базе интерфейсных плат VIP
Router#show queueing random-detect
Hssi3/0/0
Queueing strategy: VIP-based fair queueing
Packet drop strategy: VIP-based random early detection (DWRED)
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0
Queue size: 0 Maximum available buffers: 5649
Output packets: 118483 WRED drops: 800 No buffer: 0
Class Random Tail Minimum Maximum Mark Output
drop drop threshold threshold probability Packets
162
Часть I. Качество обслуживания в сетях IP
0 23 0 1412 2824 1/10 116414
1. 0 0 1588 2824 1/10 0
2 0 0 1764 2824 1/10 12345
3 0 0 1940 2824 1/10 20031
4 0 0 2116 2824 1/10 45670
5 0 0 2292 2824 1/10 0
6 0 0 2468 2824 1/10 2345
7 0 0 2644 2824 1/10 0
Когда алгоритм WRED выполняется в распределенном режиме на маршрутизато-
рах Cisco серии 7500, построенных на базе интерфейсных плат VIP, все вычисления
производятся с использованием локальных процессоров линейных плат, а не цен-
трального процессора маршрутизатора. Следовательно, распределенный механизм
WRED оперирует очередью VIP-платы, а не выходной очередью интерфейса.
Распределенный механизм WRED использует схему межпроцессного взаимодейст-
вия на основе метода скоростной коммутации пакетов Cisco (Cisco Express Forward-
ing — CEF) для распространения конфигурационных параметров и статистической
информации между процессорами RSP (Route/Switch Processor — процессор маршру-
тизации и коммутации) и интерфейсными платами VIP. (Более подробно метод ско-
ростной коммутации пакетов Cisco рассматривается в приложении Б, “Механизмы
коммутации пакетов”.) Из этого следует, что выполнение механизма WRED в распре-
деленном режиме требует активизации режима коммутации CEF. Статистика отбра-
сывания пакетов для заданного интерфейса включает в себя статистику пакетов, от-
брошенных распределенным механизмом WRED (Distributed WRED — DWRED).
Механизм DWRED вычисляет стандартное максимальное пороговое значение на
основании размера пула (грубо говоря, размера очереди платы VIР), максимального
размера единицы передачи информации (MTU) и полосы пропускания заданного ин-
терфейса. Размер пула, в свою очередь, зависит от объема установленной на VIP-
плате памяти и ряда других факторов, что существенно затрудняет его однозначное
определение. Следовательно, размер пула может помочь только приблизительно оце-
нить объем допустимого всплеска. При необходимости вы можете установить макси-
мальное пороговое значение механизма WRED, отличающееся от стандартного.
Практический пример 6.2: конфигурация механизма WRED
на основе класса трафика с помощью модульного
интерфейса командной строки QoS
Поставщик услуг заинтересован в использовании механизма WRED, поскольку
интерфейсные очереди маршрутизаторов достаточно часто подают симптомы эффекта
глобальной синхронизации. Сеть поставщика услуг используется для передачи UDP-
трафика (User Datagram Protocol — протокол передачи датаграмм пользователя), необ-
ходимого для выполнения критически важных приложений. С учетом этого произ-
вольное отбрасывание пакетов критически важного трафика нежелательно, несмотря
на возможность применения механизма “отбрасывания хвоста” при достижении сред-
ним размером очереди максимального порогового значения.
В листинге 6.3 приведен пример конфигурации механизма WRED на интерфейсе
HssiO/0/O, предусматривающий предварительное “отсеивание” критически важного
UDP-трафика.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 163
Листинг 6.3. Применение механизма WRED для обслуживания некритиче-
ского трафика с помощью модульного интерфейса команд-
ной строки QoS
class-map non-critical
match access-group 101
policy-map wred
match class non-critical
random-detect exponential-weighting-constant 9
random-detect precedence 0 112 375 1
interface HssiO/O/O
service-policy output wred
Класс non-critical соответствует всему трафику, за исключением UDP-трафика, не-
обходимого для выполнения критически важных задач. Критерий совпадения для
всего некритического трафика задан посредством отсутствующей в листинге 6.3
команды access-list 101. Команда match access-group 101 указывает на необходимость
включения в класс non-critical трафика, удовлетворяющего заданному списком доступа
101 условию. Необходимость применения механизма WRED для обслуживания всего
некритического трафика указывается посредством команды policy-map wred. В рас-
сматриваемом примере значение экспоненциальной весовой константы механизма
WRED равняется 9. В то же время минимальное пороговое значение, максимальное
пороговое значение и знаменатель граничной вероятности для пакетов с IP-
приоритетом 0 равняется 112, 375 и 1, соответственно. Посредством команды service-
policy output wred политика обслуживания пакетов wred применяется к высокоскорост-
ному последовательному интерфейсу HssiO/0/O.
Алгоритм WRED на основе потока
Сигнал о перегрузке сети воспринимается должным образом только адаптивными
потоками TCP-трафика, в то время как не обладающий способностью к адаптации
UDP-трафик не реагирует на уведомление о перегрузке и не снижает свою интенсив-
ность. Учитывая такое поведение UDP-трафика, несложно представить себе ситуа-
цию, в которой во время перегрузки сети неадаптивные потоки передают данные с
намного большей интенсивностью, чем потоки, обладающие способностью к адапта-
ции. Следовательно, на неадаптивные потоки трафика приходится львиная доля ре-
сурсов по сравнению с потоками, снижающими свою интенсивность в ответ на полу-
чение сигнала о перегрузке. Алгоритм WRED на основе потока (flow WRED) представ-
ляет собой модификацию алгоритма WRED, предусматривающую штрафование
потоков, отнимающих чрезмерную долю ресурсов.
С целью обеспечения равномерного обслуживания активных потоков трафика ме-
ханизм WRED классифицирует все устанавливаемые в очередь пакеты в зависимости
от их приоритета и потока трафика, к которому они относятся. Кроме этого, WRED
поддерживает информацию о состоянии всех активных потоков (active flows), т.е. по-
токов, хотя бы один пакет которых поставлен на обработку в какую-либо из очередей.
164
Часть I. Качество обслуживания в сетях IP
Информация о состоянии активных потоков используется для определения справед-
ливой доли выделенных потоку ресурсов очереди (размер очереди/количество актив-
ных потоков), а также для выявления и штрафования потоков, отнимающих чрезмер-
но большой объем ресурсов.
Чтобы механизм WRED более адекватно реагировал на всплески потоков трафика,
вы можете увеличить справедливую долю ресурсов каждого потока путем применения
так называемого коэффициента масштабирования (см. приведенные ниже формулы).
Справедливая доля ресурсов, выделяемая активному потоку трафика = размер
очереди + количество активных потоков.
Справедливая доля ресурсов, выделяемая активному потоку трафика, с учетом
коэффициента масштабирования = (размер очереди + количество активных
потоков) х коэффициент масштабирования.
Поток, требования которого превышают справедливую долю ресурсов с учетом ко-
эффициента масштабирования, штрафуется путем увеличения ненулевой вероятности
отбрасывания для всех вновь пришедших пакетов.
В качестве примера рассмотрим действия, предпринимаемые механизмом WRED на
основе потока в отношении только что поставленного в очередь пакета. При определении
вероятности отбрасывания пакета механизм WRED на основе потока учитывает как значе-
ние поля IP-приоритета пакета, так и информацию о состоянии активных потоков. От IP-
приоритета пакета зависят сконфигурированные (либо стандартные) минимальное и мак-
симальное пороговые значения. Если средний размер очереди ниже минимального поро-
гового значения, то вероятность отбрасывания пакета устанавливается равной нулю
(другими словами, этот пакет не будет отброшен). Если же средний размер очереди нахо-
дится между минимальным и максимальным пороговым значением, то в расчет принима-
ется информация о состоянии активных потоков трафика. Так, если пакет принадлежит
потоку, превысившему справедливую долю ресурсов с учетом коэффициента масштабиро-
вания, механизм WRED увеличивает вероятность отбрасывания этого пакета путем
уменьшения соответствующего максимального порогового значения, как показано ниже.
Новое максимальное пороговое значение = минимальное пороговое значение +
+ ((максимальное пороговое значение - минимальное пороговое значение) * 2).
Ненулевая вероятность отбрасывания пакета рассчитывается на основании мини-
мального и нового максимального порогового значения. Поскольку результатом сни-
жения максимального порогового значения является существенное увеличение угла
наклона кривой вероятности отбрасывания (рис. 6.4), шансы пакета быть отброшен-
ным резко возрастают.
Если же поток трафика не превышает справедливой доли ресурсов с учетом коэф-
фициента масштабирования, то ненулевая вероятность отбрасывания пакета рассчи-
тывается по стандартному методу.
Когда средний размер очереди превышает максимальное пороговое значение, ме-
ханизм WRED на основе потока отбрасывает все пакеты, предназначенные для поста-
новки в очередь.
Следует отметить, что механизм WRED на основе потока увеличивает вероятность
отбрасывания пакетов только для тех потоков трафика, чьи требования превысили
справедливую долю ресурсов с учетом коэффициента масштабирования. Во всем ос-
тальном поведение механизма WRED на основе потока аналогично поведению стан-
дартного механизма WRED.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 165
Результет работы
механизма WRED
Результат работы
маханизма WRED
на основе потока на основе потока
в случве превышения в случае непревышения
последним справедливой последним справедливой
доли ресурсов с учетом доли ресурсов с учетом
Минимельное пороговое
значение (определено
на основе IP-приоритета
пакета)
Максимальное пороговое
значение (определено
на основе IP-приоритета
пакета, однако впоследствии
изменено ввиду излишней
"прожорливости" потока)
Максимальное пороговое
значение (определено
на основении IP-приоритета
пакета)
Средний размер очереди
Рис. 6.4. График вероятности отбрасывания пакета при использовании механизма WRED
Примечание
Как уже было сказано выше, механизм WRED на основе потока устанавливает ненуле-
вую вероятность отбрасывания пакетов при нахождении среднего размера очереди ме-
жду минимальным и максимальным пороговыми значениями даже для тех потоков, ко-
торые характеризуются всего лишь несколькими поставленными в очередь пакетами.
Вы можете сконфигурировать механизм WRED на основе потока таким образом, чтобы
он не отбрасывал пакеты подобных потоков трафика (указав при этом, какое именно
число поставленных в очередь пакетов все еще является “спасительным” для потока)
путем установки минимального порогового значения, близкого к максимальному порого-
вому значению. При этом когда средний размер очереди достигнет максимального поро-
гового значения, вы можете применить механизм “отбрасывания хвоста”.
Практический пример 6.3: предотвращение перегрузки
для неадаптивных потоков трафика
С целью предотвращения перегрузки сети и контроля за средним размером очере-
ди сетевой инженер хочет сконфигурировать механизм WRED на основе потока на
маршрутизаторе, обрабатывающем существенный объем UDP- и TCP-трафика. Пред-
166
Часть I. Качество обслуживания в сетях IP
полагается, что трафик, поступающий на обработку в маршрутизатор, характеризуется
частыми всплесками.
В листинге 6.4 приведены соответствующие конфигурационные команды механиз-
ма WRED с коэффициентом масштабирования среднего размера очереди 6.
!' Листинг 6.4. Конфигурация механизма WRED с коэффициентом масшта- ]
| бирования среднего размера очереди 6 |
random-detect flow
random-detect flow average-depth-factor 6
Команда random-detect flow указывает на необходимость активизации механизма
WRED на основе потока с коэффициентом масштабирования 4 и значением счетчика
потоков 256. Ввиду предположения о том, что трафик, поступающий на обработку в
маршрутизатор, характеризуется частыми всплесками, вы можете увеличить коэффи-
циент масштабирования до 6 с помощью команды random-detect flow average-depth-
factor 6. Воспользовавшись командой random-detect flow count, вы можете установить
любое значение счетчика потоков в диапазоне от 0 до 215.
Команда show queueing random-detect используется для получения информации об
использующейся на интерфейсе стратегии управления очередью.
Механизм явного уведомления
о перегрузке (ECN)
До сих пор при активном управлении очередью с использованием механизма
WRED пакеты отбрасывались с целью сообщения источникам TCP-соединения о пе-
регрузке сети. Вместо отбрасывания пакета механизм явного уведомления о перегруз-
ке (Explicit Congestion Notification — ECN) использует соответствующую маркировку
заголовка пакета4. И если раньше для того чтобы сообщить о перегрузке сети, WRED-
мар щрутизатору приходилось отбрасывать пакет, вызывая тем самым задержку в дос-
тавке данных вследствие повторной передачи, то теперь маршрутизатору требуется
всего лишь установить специальный ECN-бит в заголовке пакета.
Реализация механизма ECN требует поддержки СЕ-бита (Congestion Experienced —
“обнаружена перегрузка”) в заголовке IP-пакета и наличие транспортного протокола,
должным образом интерпретирующего СЕ-бит. С этой целью в заголовке IP-пакета
выделяется специальное ECN-поле длиной 2 бит. Установка источником ТСР-
соединения бита ЕСТ (ECN-Capable Transport— транспортировка данных с поддерж-
кой поля ECN) указывает на способность конечных точек транспортного протокола к
интерпретации поля ECN. Бит СЕ устанавливается маршрутизатором с целью уведом-
ления конечных узлов соединения о перегрузке сети.
Шестой и седьмой биты байта типа обслуживания (Type of Service — ToS) заголов-
ка IPv4 формируют поле ECN и являются битами ЕСТ и СЕ, соответственно. Следует
отметить, что в аспекте архитектуры дифференцированных услуг биты 6 и 7 байта ToS
не используются.
4 A proposal to add Explicit Congestion Notification (ECN) to IP/Ramakrishnan K., Floyd S. —
RFC 2481.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 167
Механизм ECN выдвигает три новых требования к протоколу TCP.
• Наличие средства уведомления конечных точек ТСР-соединения о поддержке поля
ECN. Конечные точки ТСР-соединения должны обладать средством уведомле-
ния друг друга о поддержке поля ECN.
• Поддержка флага ECN-Echo в ТСР-заголовке. TCP-приемник использует флаг
ECN-Echo для информирования TCP-источника о получении СЕ-пакета.
• Поддержка флага CWR (Congestion Window Reduced — сужение окна перегрузки) в
ТСР-заголовке. TCP-источник использует CWR-флаг для информирования
TCP-приемника об уменьшении размера окна перегрузки.
Механизм ECN все еще находится на стадии обсуждения в различных организаци-
ях, занимающихся разработкой стандартов.
Механизм избирательного отбрасывания
пакетов (SPD)
Механизм избирательного отбрасывания пакетов (Selective Packet Discard— SPD)
служит для отделения важного управляющего трафика сети (например, пакетов с об-
новлением информации о маршрутах) от остального трафика на уровне маршрутиза-
тора. Механизм SPD помогает маршрутизатору поддерживать целостность информа-
ции о маршрутах протокола IGP (Interior Gateway Protocol— протокол внутреннего
шлюза) и протокола BGP (Border Gateway Protocol— протокол пограничного шлюза)
во время перегрузки сети путем приоритетной обработки пакетов протоколов маршру-
тизации по отношению к остальным пакетам сетевого трафика.
В соответствии с механизмом SPD к очереди IP-процесса маршрутизатора приме-
няется избирательная политика отбрасывания пакетов. Отсюда можно сделать вывод о
том, что механизм SPD предназначен исключительно для обработки трафика, обслу-
живаемого посредством механизма коммутации процессов. Следует отметить, что да-
же в случае применения маршрутизатором схемы определения адреса продвижения
пакета на основе кэша маршрутов (так называемая быстрая коммутация пакетов) не-
который объем транзитного трафика все же должен быть обработан с помощью меха-
низма коммутации процессов с целью занесения в кэш информации о маршрутах. Что
же касается маршрутизатора, в котором применяется механизм скоростной коммута-
ции пакетов Cisco (Cisco Express Forwarding— CEF), то весь транзитный трафик об-
рабатывается с помощью механизма CEF, а во входную очередь IP-процесса ставятся
только пакеты важного управляющего трафика (например, пакеты с обновлением ин-
формации о маршрутах и служебные пакеты, необходимые для поддержания соедине-
ния); пакеты обычного трафика, предназначенные данному маршрутизатору; пакеты
транзитного трафика, которые не могут быть обработаны с помощью механизма CEF.
Более подробно механизмы коммутации процессов, определения адреса продвижения
пакета на основе кэша маршрутов и скоростной коммутации пакетов рассматриваются
в приложении Б, “Механизмы коммутации пакетов”.
Пакеты трафика, подлежащие обработке во входной очереди IP-процесса, разделе-
ны на три группы.
• Важный управляющий трафик IP (пакеты протокола маршрутизации), часто на-
зываемый приоритетным трафиком (priority traffic).
168
Часть I. Качество обслуживания в сетях IP
• Обычный IP-трафик (например, пакеты приложений telnet или ping), IP-пакеты
с альтернативами, а также любое расширение или инкапсуляция IP, не поддер-
живаемая механизмом CEF.
• Пакеты, которые должны быть отброшены. Сюда относятся IP-пакеты, по тем
или иным причинам не прошедшие тест на корректность, — пакеты с неверной
контрольной суммой, неправильной версией, истекшим “временем жизни”
(Time-to-Live — TTL), неверным номером порта UDP/TCP, неверным значени-
ем поля протокола IP и т.д. При получении большинства из этих пакетов авто-
матически генерируется ICMP-пакет (Internet Control Message Protocol— про-
токол управляющих сообщений Internet) с целью уведомления отправителя об
ошибке. Небольшое число ICMP-пакетов генерируется некоторыми служебны-
ми программами, такими, как traceroute. Следует отметить, что большой объем
ICMP-трафика может являться частью атаки злоумышленников, пытающихся
вывести из строя маршрутизатор путем переполнения очереди IP-процесса. Та-
ким образом, становится очевидной необходимость избирательного отбрасыва-
ния этих пакетов без потери важной управляющей информации.
Механизм SPD может функционировать в следующих режимах.
• Отключен (Disabled). Механизм SPD отключен на заданном маршрутизаторе.
• Нормальный режим функционирования (Normal). Размер входной очереди IP-
процесса находится ниже минимального порогового значения. Пакеты не от-
брасываются.
• Режим случайного отбрасывания пакетов (Random drop). Размер входной очереди
IP-процесса находится в пределах между минимальным и максимальным по-
роговыми значениями. В данном режиме отбрасываются все IP-пакеты, при-
надлежащие обычным потокам трафика. Вероятность отбрасывания пакетов
рассчитывается по приведенной ниже формуле.
Вероятность отбрасывания пакета = (длина очереди - минимальное пороговое зна-
чение) (максимальное пороговое значение - минимальное пороговое значение).
Случайные отбрасывания пакетов получили название SPD-сбросов (SPD flush).
Следует отметить, что важный управляющий трафик сети по-прежнему ставит-
ся в очередь для обработки.
• Режим тотального отбрасывания пакетов (Full drop). Размер входной очереди IP-
процесса превысил максимальное пороговое значение. Механизм SPD отбрасывает
все пакеты, принадлежащие обычным потокам трафика. Важный управляющий
трафик все еще ставится на обработку в специальную приоритетную очередь (priority
queue), которая обрабатывается перед всеми обычными очередями 1Р-процесса.
• Режим активного отбрасывания пакетов (Aggressive drop). Специальный режим,
при котором отбрасываются все IP-пакеты, не прошедшие проверку на кор-
ректность. Отбрасывание некорректных пакетов производится, когда размер
входной очереди превышает минимальное пороговое значение. Режим актив-
ного отбрасывания пакетов механизма SPD активизируется с помощью
команды ip spd mode aggressive.
Все режимы функционирования механизма избирательного отбрасывания пакетов
(SPD) схематически представлены на рис. 6.5.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 169
Вероятность
отбросывания
пакета
О
Активное
Тотальное
Минимальное
пороговое знечение
________________ Входная
очередь
Максимальное
пороговое значение
При-
ори-
1Р-процесса
тетная
Размер очереди
очередь
"Отбрасывание
хвоста"
1
Рис. 6.5. Режимы функционирования механизма SPD
Практический пример 6.4: предотвращение атаки
злоумышленника, использующего некорректные
IP-пакеты, с помощью механизма SPD
Предположим, что сеть подвергается атаке злоумышленника, использующего IP-
пакеты с истекшим “сроком жизни” (некорректным значением поля TTL). Получение
большого количества некорректных IP-пакетов крайне неблагоприятно сказывается на ра-
ботоспособности маршрутизатора, вынужденного обрабатывать эти пакеты посредством
механизма коммутации процессов (получение пакета с истекшим “сроком жизни” приво-
дит к генерированию соответствующего ICMP-пакета). С целью отбрасывания некоррект-
ных пакетов, в том случае, когда их количество превышает заданное минимальное порого-
вое значение, сетевой инженер должен активизировать на маршрутизаторе механизм SPD,
функционирующий в режиме активного отбрасывания пакетов. В этом практическом
примере рассматривается функционирование механизма SPD посредством использования
различных show-команд.
Активизация механизма SPD производится с помощью команды ip spd. Следует
отметить, что при использовании операционной системы IOS версии 12.0 или выше
механизм SPD активизируется по умолчанию. В листинге 6.5 приведена информация
о параметрах механизма SPD и режиме его функционирования.
f Листинг 6.5. Параметры механизма SPD и информация о режиме
[' его функционирования 5
t ?'"*. .......... Г-.,,___л ... '3.' -- .'к" .... ,
R3#sh ip spd
Current mode: normal.
Queue min/max thresholds: 73/74, Headroom: 100
IP normal queue: 20, priority queue: 20.
SPD special drop mode: none.
170
Часть I. Качество обслуживания в сетях IP
Команда show ip spd используется для вывода на экран информации о режиме
функционирования механизма SPD, минимальном и максимальном пороговых значе-
ниях, а также о размере приоритетной очереди и очереди IP-процесса. Минимальный
и максимальный пороговые размеры входной очереди механизма SPD являются на-
страиваемыми параметрами.
Размеры обычной очереди IP-процесса и приоритетной очереди измеряются на
момент выполнения команды show ip spd. Поскольку длина обычной очереди рав-
на 20, что ниже минимального порогового значения, равного 73, механизм SPD
функционирует в нормальном режиме.
Как упоминалось ранее, для обработки важного IP-трафика в момент переполнения
входной очереди IP-процесса используется так называемая приоритетная очередь (IPpriority
queue). Входная очередь IP-процесса представляет собой глобальную очередь, в которую
заносятся все IP-пакеты, ожидающие обработки IP-процессом. Эти пакеты не могут быть
обработаны в результате прерывания центрального процессора маршрутизатора.
Длина приоритетной очереди может быть изменена с помощью команды ip spd
headroom. Следует отметить, что попытка помещения пакетов любого важного 1Р-трафика
в переполненную приоритетную очередь завершится их отбрасыванием.
Примечание
Обратите внимание, что формат некоторых конфигурационных команд механизма
SPD, применявшийся в операционных системах IOS версии 11.1, в версии IOS12.0
был изменен. В то время как все команды механизма SPD, реализованные в операци-
онных системах IOS версии 11.1, начинались с ключевых слов ip spd, некоторые кон-
фигурационные команды механизма SPD, реализованные в операционных системах
IOS версии 12.0, должны начинаться с ключевого слова spd. Более подробно формат
конфигурационных команд механизма SPD рассматривается в соответствующей до-
кументации компании Cisco Systems.
Параметр Headroom обозначает длину приоритетной очереди. Как отмечалось выше,
приоритетная очередь используется для обработки приоритетного трафика. На текущий
момент в приоритетной очереди находится 20 пакетов, ожидающих обработки. Стандарт-
ные пороговые значения очереди, предназначенной для обработки обычного трафика, оп-
ределяются на основании размера входной очереди. Для того чтобы узнать длину входной
очереди, следует воспользоваться командой show interface. Все пакеты, не прошедшие про-
верку на корректность, обслуживаются в соответствии с механизмом коммутации процес-
сов. Если длина очереди IP-процесса, предназначенной для обработки обычного трафика,
превысит минимальное пороговое значение, сетевой инженер должен активизировать ме-
ханизм SPD в режиме активного отбрасывания пакетов, воспользовавшись командой ip spd
mode aggressive. В листинге 6.6 приведена информация о параметрах механизма SPD,
функционирующего в режиме активного отбрасывания пакетов.
Листинг 6.6. Параметры механизма SPD, функционирующего в режиме
отбрасывания всех IP-пакетов, не прошедших проверку ,
на корректность
R3#sh ip spd
Current mode: normal.
Queue min/max thresholds: 73/74, Headroom: 100
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 171
IP normal queue: 20, priority queue: 5.
SPD special drop mode: aggressively drop bad packets
В листинге 6.7 приведена подробная статистика обработки пакетов механизмом SPD.
! Листинг 6.7. Подробная статистика обработки пакетов механизмом SPD
R3#show interface hssi0/0/0 switching
Hssi0/0/0
Throttle count 10
Drops RP 13568 SP 0
SPD Flushes Fast 322684 SSE 0
SPD Aggress Fast 322684
SPD Priority Inputs 91719 Drops 4
Команда show interface switching используется для вывода на экран статистики SPD-
сбросов и статистики механизма активного отбрасывания пакетов. Информация, вы-
водимая на экран в результате выполнения этой команды, включает в себя сведения
об объеме полученного приоритетного трафика и количестве пакетов, отброшенных
при переполнении приоритетной очереди.
RP-отбрасывания (Route Processor— процессор маршрутов) представляют собой
отбрасывания IP-пакетов процессором маршрутов при переполнении входной очере-
ди. Они соответствуют параметру, определяющему количество отброшенных пакетов
входной очереди, значение которого выводится на экран в результате выполнения
команды show interface Hssi0/0/0.
Быстрые SPD-сбросы осуществляются в режимах случайного, тотального и актив-
ного отбрасывания пакетов механизма SPD, когда размер входной очереди еще не
достиг своего максимального значения. В случае, когда длина входной очереди мень-
ше минимального порогового значения, отбрасывание пакетов не предпринимается.
Быстрые SPD-сбросы осуществляются также и в режиме активного отбрасывания
пакетов. В этом случае их количество отражает число отброшенных механизмом SPD
пакетов, которые по тем или иным причинам не прошли проверку на корректность.
Опять же, в случае, когда длина входной очереди меньше минимального порогового
значения, активное отбрасывание пакетов не предпринимается.
Приоритетная очередь механизма SPD предназначена для обработки приоритет-
ного трафика (priority traffic). Приоритетный трафик представляет собой управляющий
трафик сети с приоритетом 6.
Резюме
В этой главе были рассмотрены различные алгоритмы предотвращения перегрузки и
отбрасывания пакетов: RED (Random Early Detection — алгоритм произвольного раннего
обнаружения), WRED (Weighted Random Early Detection— взвешенный алгоритм произ-
вольного раннего обнаружения), Row WRED (Row Weighted Random Early Detection —
взвешенный алгоритм произвольного раннего обнаружения на основе потока) и ECN
(Explicit Congestion Notification —алгоритм явного уведомления о перегрузке).
RED представляет собой алгоритм активного управления очередью, позволяющий
маршрутизатору обнаружить перегрузку сети еше до фактического переполнения оче-
172
Часть I. Качество обслуживания в сетях IP
реди. Целью алгоритма RED является уменьшение среднего размера очереди и, как
следствие этого, сокращение задержки передачи пакетов и предотвращение эффекта
глобальной синхронизации. Работа алгоритма RED основана на применении вероят-
ностной стратегии отбрасывания пакетов в случае нахождения среднего размера оче-
реди в диапазоне между заданными пороговыми значениями. Взвешенный алгоритм
RED (WRED) позволяет настраивать различные параметры RED в зависимости от
приоритета трафика.
Алгоритм WRED на основе потока представляет собой расширение алгоритма
WRED, призванное обеспечить равномерное применение политики отбрасывания по
отношению к пакетам, принадлежащим одному и тому же потоку трафика. Целью
алгоритма ECN является уведомление источников трафика о зарождающейся пере-
грузке сети путем маркировки пакетов (а не их отбрасывания).
В этой главе был рассмотрен также алгоритм избирательного отбрасывания паке-
тов (Selective Packet Discard — SPD), использующийся для управления входной очере-
дью IP-процесса маршрутизатора Cisco. Алгоритм SPD применяется для обеспечения
дифференцированного обслуживания пакетов управляющего трафика, обрабатываю-
щихся посредством механизма коммутации процессов маршрутизатора Cisco.
Ответы на часто задаваемые вопросы
Существуют ли какие-то эмпирические правила подбора параметров механизма RED?
Ниже приведена формула для расчета экспоненциального весового коэффициента5.
Экспоненциальный весовой коэффициент = 10 + В,
где В — это полоса пропускания выходного канала передачи информации в пакетах
размером MTU байтов.
Поскольку это не влияет на конечный результат, используйте значение MTU, рав-
ное 1500 байт, для всех каналов передачи информации даже в том случае, если дейст-
вительное значение MTU равняется 4470 байт.
Например, для канала DS3 (45 Мбит/с)
В = (45 Мбит/с 4- 8) н- 1500 = 3750.
Следовательно, экспоненциальный весовой коэффициент
= 10 н-В = 2.67 Е-3,
что приблизительно равняется 2-9.
Для остальных интерфейсов экспоненциальный весовой коэффициент рассчитыва-
ется аналогичным способом.
Минимальное и максимальное пороговые значения можно установить равными 0.03 В
и 0.1В, соответственно. К примеру, для канала DS3 эти значения равны 112 и 375, соответ-
ственно. Знаменатель граничной вероятности при этом следует установить равным 1.
В табл. 6.1 приведены рекомендованные значения параметров механизма RED для
линий связи DS1, DS3, ОСЗ и ОС12. При использовании механизма WRED эти зна-
чения являются рекомендованными значениями для трафика IP-приоритета 0.
5 RED in a Different Light/Jacobson V., Nichols К., Poduri К. — в состоянии разработки.
Глава 6. РНВ-политика: предотвращение перегрузки и политика... 173
* Таблица 6.1. Рекомендованные значения параметров механизма RED для
различных линий связи
Скорость передачи информации по линии связи Экспоненциальный весовой коэффициент Минимальное пороговое значение Максимальное пороговое значение Знаменатель граничной вероятности
DS1 4 4 13 1
DS3 9 112 375 1
ОСЗ 10 388 1292 1
0С12 12 1550 5167 1
Можно ли считать, что механизм WRED на основе потока не следует применять
для обработки голосового трафика вследствие того, что этот механизм ограничива-
ет UDP-трафик?
Нет. Механизм WRED на основе потока ограничивает не весь UDP-трафик, а
только потоки с чрезмерными требованиями к ресурсам. Следовательно, этот меха-
низм можно применять для обработки голосового трафика.
Целесообразно ли применение механизма SPD во всех маршрутизаторах сети?
Применение механизма SPD является критически важным решением в любой
крупномасштабной IP-сети, что особено оправдано при использовании маршрутиза-
торами сети схемы определения адреса продвижения пакета на основе кэша маршру-
тов. В случае использования маршрутизаторами сети схемы быстрой коммутации па-
кетов Cisco (CEF) эффективность применения механизма SPD несколько снижается,
поскольку этот механизм применяется исключительно для обработки трафика, обслу-
живаемого по методу коммутации процессов. Тем не менее использование механизма
SPD всегда оправданно в аспекте дифференцированной обработки важного сетевого
трафика, такого, как пакеты протоколов маршрутизации и пакеты, необходимые для
поддержания соединения.
Активизация специального режима функционирования механизма SPD— режима
активного отбрасывания пакетов— позволяет свести к минимуму угрозу атак типа
Denial-of-Service с применением некорректных IP-пакетов (например, пакетов с ис-
текшим “сроком жизни”), направленных на вывод маршрутизатора из строя.
174
Часть I. Качество обслуживания в сетях IP
В этой главе...
Протокол RSVP 177
Стили резервирования 182
Типы услуг 185
Среда передачи и протокол RSVP 186
Масштабируемость протокола RSVP 186
Глава
7
Интегрированные услуги: RSVP
В предыдущих главах обсуждалась архитектура дифференцированных услуг
(Differentiated Services — diffserv) и ее разрешающие функции. Мы рассмотрели
использование поля кода дифференцированной услуги (Differentiated Services
Code Point — DSCP) и поля приоритета протокола Internet (Internet Protocol —
IP) в IP-заголовке пакета для классификации трафика на основе его уровня об-
служивания и определения РНВ-политики сети. Теперь, рассматривая архитекту-
ру интегрированных услуг (Integrated Services — intserv), мы обсудим способ ин-
формирования сети о нуждах различных потоков трафика.
Для этой цели в архитектуре intserv используется сигнальный протокол качества
обслуживания (quality of service— QoS)— протокол резервирования ресурсов
(Resource Reservation Protocol — RSVP). RSVP — это сигнальный протокол QoS, кото-
рый позволяет конечным приложениям, требующим определенные гарантированные
услуги, проводить сквозную сигнализацию своих QoS-требований. Вместе с тем РНВ-
политика сети определяется функциями планирования сетевого узла, как это описы-
валось в главах 4, “РНВ-политика: распределение ресурсов (часть 1)”, 5, “РНВ-
политика: распределение ресурсов (часть 2)’’, и 6, “РНВ-политика: предотвращение
перегрузки и политика отбрасывания пакетов”.
В этой главе обсуждается протокол RSVP, его управляющие сообщения, функцио-
нирование и пр. Кроме того, также описываются два типа интегрированных служб —
управляемая нагрузка и гарантированная услуга.
Диспетчер полосы пропускания подсети (Subnet Bandwidth Manager — SBM) — это
версия протокола RSVP и его расширений для канального уровня, поддерживающая
управление трафиком в сетях на основе многопротокольной коммутации меток
(Multiprotocol Label Switching — MPLS). Диспетчер SBM и управление трафиком в се-
тях MPLS описываются в главе 8, “Качество обслуживания на уровне 2: межсетевой
обмен с IP QoS”, и главе 10, “Управление трафиком в сетях MPLS”, соответственно.
Протокол RSVP
Рабочая группа IETF определила RSVP1 как сигнальный протокол для архитектуры
intserv. Этот протокол позволяет приложениям посыпать сигналы в сеть о своих QoS-
1 Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification/Branden R. et al. —
RFC 2205, 1997.
требованиях для каждого потока. Чтобы определить количественные характеристики
этих требований с целью управления доступом, используются служебные параметры.
Протокол RSVP применяется в приложениях с групповой рассылкой, таких, как
приложения аудио- и видеоконференций. Несмотря на то что изначально протокол
RSVP был ориентирован на мультимедийный трафик, с его помощью легко можно ре-
зервировать полосу пропускания для однонаправленного трафика, например для тра-
фика сетевой файловой системы (Network File System — NFS) и управляющего трафи-
ка виртуальных частных сетей (Virtual Private Network — VPN).
Протокол RSVP сигнализирует о запросах резервирования ресурсов по доступному
маршрутизируемому пути в сети. При этом RSVP не производит собственную мар-
шрутизацию; напротив, этот протокол был разработан для использования других, бо-
лее мощных, протоколов маршрутизации. Как и любой другой 1Р-трафик, при опре-
делении пути для данных и управляющего трафика RSVP полагается на используемый
в сети протокол маршрутизации. После того как информация протокола маршрутиза-
ции адаптируется к изменениям в топологии сети, запросы резервирования протокола
RSVP переносятся на новый путь. Подобная модульность помогает протоколу RSVP
эффективно функционировать совместно с любой службой предоставления информа-
ции о маршрутах. RSVP обеспечивает явную передачу управляющих трафиком и по-
литиками сообщений и легко работает в неподдерживаемых окружениях.
Работа протокола RSVP
Конечные системы используют протокол RSVP для запрашивания у сети определен-
ного уровня QoS от имени потока данных приложения. RSVP-запросы передаются по сети
при прохождении каждого узла, который используется для передачи потока. Протокол
RSVP пытается зарезервировать ресурсы для потока данных на каждом из этих узлов.
RSVP-совместимые маршрутизаторы помогают доставить нужные потоки данных в
нужную точку назначения. На рис. 7.1 изображены основные модули, информация о
потоке данных и информация об управляющих потоках клиента и маршрутизатора,
поддерживающих протокол RSVP.
RSVP в узлах и маршрутизаторах
Данные
——-► Пакеты RSVP или управляющие пакеты
Рис. 7. /. Информация о потоке данных и информация об управляющих потоках клиента и маршру-
тизатора, поддерживающих протокол RSVP
178
Часть I. Качество обслуживания в сетях IP
Перед тем как зарезервировать ресурсы, RSVP-демон маршрутизатора соединяется
е двумя локальными модулями принятия решения — модулем управления доступом
(admission control) и модулем управления политикой (policy control)2. Модуль управления
доступом определяет, имеет ли узел достаточно свободных ресурсов для обеспечения
запрошенного уровня QoS. Модуль управления политикой определяет, есть ли у поль-
зователя администраторские права, для того чтобы произвести резервирование. Если
какая-либо из проверок не прошла, RSVP-демон отправляет сообщение об ошибке
процессу приложения, которое создало запрос. Если обе проверки прошли нормально,
RSVP-демон устанавливает параметры классификатора пакетов (packet classifier) и пла-
нировщика пакетов (packet scheduler) для получения нужного уровня QoS. Классифика-
тор пакетов определяет класс QoS для каждого пакета, а планировщик пакетов управ-
ляет передачей пакетов, основываясь на их классе QoS. Взвешенный алгоритм равно-
мерного обслуживания очередей (Weighted Fair Queuing — WFQ) и взвешенный
алгоритм произвольного раннего обнаружения (Weighted Random Early Detection —
WRED) обеспечивают поддержку QoS на уровне планировщика. Алгоритмы WFQ и
WRED обсуждаются в главах 4 и 6, соответственно.
Во время процесса принятия решения модулем управления доступом резервирование
затребованной полосы пропускания производится только в том случае, если для запра-
шиваемого класса трафика достаточно оставшейся части. В противном случае запрос на
доступ отклоняется, но трафик все равно передается с качеством обслуживания, опреде-
ленным по умолчанию для данного класса трафика. Во многих случаях, даже если за-
прос на доступ отклонен на одном или нескольких маршрутизаторах, модуль все еще
может реализовать приемлемое качество обслуживания, установив резервирование на
перегруженных маршрутизаторах. Это возможно из-за того, что другие потоки данных
могут не полностью использовать заказанную ими полосу пропускания.
Резервирование всегда должно следовать по одному и тому же одноадресному пути
или по многоадресному дереву. В случае выхода из строя линии связи маршрутизатор
должен сообщить об этом RSVP-демону, чтобы генерируемые им RSVP-сообщения
передавались по новому пути.
Процесс установки резервирования можно разбить на пять отдельных шагов3.
1. Отправители данных посылают управляющие сообщения RSVP PATH по тому
же пути, по которому они отправляют обычный трафик с данными. В этих со-
общениях описываются данные, которые уже отправляются или только будут
отправляться.
2. Каждый RSVP-маршрутизатор перехватывает РАТН-сообщения, сохраняет IP-
адрес предыдущей точки назначения, записывает вместо него свой собственный
адрес и отправляет обновленное сообщение дальше по тому же пути, по которо-
му передаются данные приложения.
3. Станции-получатели выбирают подмножество сеансов, для которых они полу-
чили РАТН-информацию и с помощью RSVP RESV-сообщения запрашивают
RSVP-резервирование ресурсов у предыдущего маршрутизатора. RSVP RESV-
сообщения идут от получателя к отправителю в противоположном направлении
по маршруту, пройденному RSVP РАТН-сообщениями.
2 Resource Reservation Protocol (RSVP) Version 1 Applicability Statement, Some Guidelines on De-
ployment/Mankin A. et al. — RFC 2208, 1997.
3 Официальная Web-страница, посвященная протоколу RSVP: www.isi.edu/rsvp
Глава 7. Интегрированные услуги: RSVP
179
4. RSVP-маршрутизаторы определяют, могут ли они удовлетворить эти RESV-
запросы. Если нет, они отказывают в резервировании. Если да, то они объеди-
няют^ полученные запросы на резервирование и отсылают запрос предыдущему
маршрутизатору.
5. Отправители, получив запросы на резервирование ресурсов от соответствующих
маршрутизаторов, считают резервирование ресурсов состоявшимся. Обратите вни-
мание, что реальное резервирование ресурсов осуществляется RESV-сообшениями.
Механизм RSVP-резервирования схематически показан на рис. 7.2.
Рис. 7.2. Механизм RSVP-резервирования ресурсов
Как уже обсуждалось в главе 3, “Формирование трафика на границе сети:
классификация пакетов, маркировка пакетов и управление интенсивностью трафика”, па-
кеты, идущие от приложения на машине-источнике к приложению на машине-
получателе, формируют отдельный поток. С целью управления доступом требования пото-
ка представляются в виде параметров объекта FlowSpec.
RSVP-компоненты
RSVP-компоненты выполняют следующие функции.
• RSVP-отправитель (RSVP sender) — это приложение, инициирующее отправку
трафика в RSVP-сеансе. Ниже перечислены спецификации потока, которые
RSVP-отправители могут передавать по RSVP-сети:
• средняя скорость передачи данных;
• максимальный размер всплеска.
• По сети, состоящей из RSVP-совместимых маршрутизаторов (RSVP-enabled
router network), прокладывается путь между RSVP-отправителями и RSVP-
получателями.
• RSVP-получатель (RSVP-receiver) — это приложение, которое получает трафик в
RSVP-сеансе. Во время конференций или при передаче голоса по протоколу IP
(Voice over IP — VoIP) приложение может играть роль и RSVP-отправителя, и
RSVP-получателя. Ниже перечислены спецификации потока, который RSVP-
получатели могут передавать по RSVP-сети.
• Средняя скорость передачи данных.
180
Часть I. Качество обслуживания в сетях IP
• Максимальный размер всплеска.
• QoS, включая:
• гарантированное обслуживание — в РЛТН-сообщениях также описываются
максимально возможные задержки в сети;
• обслуживание с управляемой нагрузкой — маршрутизаторы гарантируют
только то, что сетевые задержки будут минимальными.
RSVP-сообщения
В протоколе RSVP используются семь типов сообщений: два обязательных —
PATH и RESV - и пять опциональных - PATH ERROR, PATH TEARDOWN, RESV
ERROR, RESV CONFIRM и RESV TEARDOWN. RSVP-маршрутизаторы и клиенты
используют эти сообщения для создания и поддержки состояний резервирования.
Обычно протокол RSVP работает непосредственно поверх протокола IP. Следователь-
но, RSVP-сообщения являются ненадежными датаграммами. Они помогают создавать в
маршрутизаторах гибкие состояния, которые необходимо периодически обновлять.
Ниже перечислены типы сообщений отправителя.
• Отправители периодически посылают РАТН-сообщения. В описание потока
включается IP-адрес источника и приемника, IP-протокол и, при необходимо-
сти, порты протокола передачи датаграмм пользователя (User Datagram
Protocol — UDP) или порты протокола управления передачей (Transmission
Control Protocol — TCP). Отправители проводят оценку ожидаемых затрат ре-
сурсов для передачи данных. При этом определяется средняя скорость передачи
и размер всплеска.
PATH-сообщения отправляются многоадресным группам или одноадресной
точке назначения потока, для которого производится резервирование. RSVP-
маршрутизаторы обнаруживают их по признаку IP Router Alert в IP-заголовке
или по UDP-сообшению, предназначенному для индивидуального UDP-порта.
При получении РАТН-сообщений маршрутизатор создает блок состояния пути
(Path State Block — PS В).
В РАТН-сообщениях содержится периодический hello-интервал, указывающий
на частоту посылки этих сообщений отправителем. По умолчанию hello-
интервал равен 30 с. Очень важно иметь небольшой hello-интервал или быст-
рую схему повторной передачи, поскольку из-за потери РАТН-сообщения мо-
жет ухудшиться производительность VoIP-приложений вследствие задержки
при установке RSVP-резервирования на пути VoIP-вызова. Блок PSB сбрасыва-
ется, если получено сообщение PATH TEARDOWN, вышла из строя линия свя-
зи или если блок не обновлялся новым РАТН-сообщением в течение четырех
hello-интервалов.
• При обнаружении в РАТН-сообщении ошибки(ошибок) получателем или мар-
шрутизатором отправляется необязательное сообщение PATH ERROR, опове-
щающее отправителя о возникшей проблеме. Обычно это происходит из-за
ошибки при проверке целостности сообщения.
• Сообщения PATH TEARDOWN, содержащие адрес источника отправителя, по-
сылаются многоадресной группе в случае необходимости удаления пути из базы
Глава 7. Интегрированные услуги: RSVP
181
данных, при выходе из строя канала или если отправитель покидает многоад-
ресную группу.
Ниже перечислены типы сообщений получателя.
• Получатели периодически отправляют RESV-сообшения. Они описывают пото-
ки и необходимые ресурсные гарантии, используя информацию, полученную из
РАТН-сообщений: IP-адреса источника и пункта назначения, IP-протокола и,
при необходимости, UDP- или TCP-портов. С помощью спецификации потока
они также описывают необходимую битовую скорость и характеристики за-
держки. RESV-сообщения проходят через все RSVP-маршрутизаторы по мар-
шрутизируемому пути к отправителю, для которого производится резервирова-
ние ресурсов. По приходе RESV-сообщений (FlowSpec, FilterSpec) маршрутиза-
торы создают блоки состояния резервирования (Reservation State Block — RSB).
В RESV-сообщениях содержится периодический hello-интервал, указывающий на
частоту посылки этих сообщений получателем. Блок RSB сбрасывается при получе-
нии сообщения RESV TEARDOWN, выходе из строя канала или если блок не об-
новлялся новым RESV-сообщением в течение четырех hello-интервалов.
• При обнаружении в RESV-сообщении ошибки(ошибок) отправителем или
маршрутизатором отправляется сообщение RESV ERROR, оповещающее полу-
чателя о возникшей проблеме. Обычно это происходит из-за фундаментальной
ошибки формата, ошибки при проверке целостности или из-за недостатка сво-
бодных ресурсов для предоставления запрашиваемых гарантий.
• Если RESV-сообщение используется для сквозного резервирования ресурсов и
получатель запрашивает подтверждение резервирования, то получателям или
маршрутизаторам, расположенным в точках объединения запросов, отправляет-
ся сообщение RESV CONFIRM.
• Когда блок RSB должен быть удален из базы данных вследствие выхода из
строя линии связи или когда отправитель покидает многоадресную группу, от-
правляются сообщения RESV TEARDOWN.
Стили резервирования
RSVP-резервирование ресурсов для потока можно разбить на два главных типа:
индивидуальное и общее. Типы RSVP-резервирования обсуждаются в следующих раз-
делах этой главы.
Индивидуальное резервирование
Индивидуальное резервирование (distinct reservations) применяется в тех приложениях,
в которых несколько источников данных могут отправлять информацию одновремен-
но. В видеоприложениях каждый отправитель генерирует индивидуальный поток дан-
ных, для которого необходимо осуществлять отдельное управление доступом и плани-
рование очереди на всем пути к получателю. Следовательно, для такого потока необ-
ходимо осуществлять отдельное резервирование ресурсов для каждого отправителя и
для каждого канала в пути.
Индивидуальное резервирование происходит явно для отправителя и устанавлива-
ется с помощью стиля резервирования с фиксированным фильтром (Fixed Filter —
182
Часть I. Качество обслуживания в сетях IP
FF). Символически запрос на резервирование в стиле FF можно представить как
FF(S,Q), где S — это отправитель, a Q — объект FlowSpec.
Самый простой случай индивидуального резервирования ресурсов наблюдается на
примере приложения с одноадресным трафиком, где есть только один отправитель и
один получатель.
Общее резервирование
Общее резервирование (shared reservations) применяется в тех приложениях, в которых
несколько источников данных не склонно передавать информацию одновременно, на-
пример цифровые аудиоприложения, такие, как приложения VoIP. В этом случае, по-
скольку в любой отдельно взятый промежуток времени разговор ведет небольшое число
людей, информация передается лишь небольшим ограниченным количеством отправи-
телей. Такой поток не нуждается в отдельном резервировании ресурсов для каждого от-
правителя, для него необходимо всего лишь одно резервирование, которое при необхо-
димости можно будет применить к любому отправителю в группе.
В терминах протокола RSVP такой поток называется общим потоком (shared flow)',
он устанавливается с помощью общего явного или группового резервирования. Ука-
занные стили резервирования рассматриваются ниже.
• При общем явном (Shared Explicit — SE) резервировании потоки, которые ре-
зервируют сетевые ресурсы, указываются отдельно.
Символически запрос на резервирование в стиле SE можно представить как
SE((SI,S2){Q}), где SI, S2, ... — отдельные отправители, требующие резервиро-
вания ресурсов, a Q — объект FlowSpec.
• С помощью группового фильтра (Wildcard Filter — WF) полоса пропускания и
характеристики задержки могут быть зарезервированы для любого отправителя.
Такой фильтр не позволяет указать отправителей отдельно — он принимает
всех отправителей, на что указывает установка адреса источника и порта в ноль.
Символически запрос на резервирование в стиле WF можно представить как
WF(*{Q}), где символ “*” представляет собой групповой символ выбора отпра-
вителей, a Q — объект FlowSpec.
В табл. 7.1 показаны различные фильтры резервирования, основанные на стилях
резервирования и количестве отправителей, а на рис. 7.3 — три ранее рассмотренных
стиля фильтров резервирования.
I Таблица 7.1. Различные фильтры резервирования, основанные на стиле
и количестве отправителей •• •
Количество отправителей Стили резервирования
Индивидуальное Общее
Явное резервирование FF SE
Групповое резервирование Не определено WF
Глава 7. Интегрированные услуги: RSVP
183
Рис. 7.3. Примеры трех стилей фильтров резервирования
184
Часть I. Качество обслуживания в сетях IP
Типы услуг
Протокол RSVP предоставляет два типа интегрированных услуг, которые получате-
ли могут запрашивать с помощью сообщений RSVP RESV: службу регулируемой на-
грузки и службу гарантированной битовой скорости.
Регулируемая нагрузка
Служба регулируемой нагрузки (controlled load service)4 обеспечивает гарантию того, что
зарезервированный поток достигнет своего пункта назначения с минимальным вмеша-
тельством со стороны трафика, доставляемого без гарантий. Более того, в реализации
этой услуги компанией Cisco предусмотрена изоляция отдельных зарезервированных по-
токов. Изоляция потока позволяет исключить влияние других присутствующих в сети
зарезервированных потоков при резервировании ресурсов.
Как правило, служба регулируемой нагрузки применяется при передаче трафика
Internet-приложений, чувствительных к перегрузкам в сети. Такие приложения отлич-
но работают в незагруженных сетях, но сразу “приходят в негодность” при перегруз-
ке. Примером таких приложений может служить приложение, работающее по прото-
колу FTP (File Transfer Protocol — протокол передачи файлов).
Гарантированная битовая скорость
Служба гарантированной битовой скорости (guaranteed bit rate service)5 обеспечивает ог-
раничение задержки без отбрасывания датаграмм, удовлетворяющих параметрам трафика,
в условиях отсутствия сбоев в работе сетевых компонентов или изменений в информации
о маршрутах во время жизни потока. Эта служба гарантирует минимальное вмешательство
со стороны трафика, доставляемого без гарантий, изоляцию зарезервированных потоков и
числовое выражение максимальной задержки.
Служба гарантированной битовой скорости может обеспечить только максималь-
ную, но не минимальную или среднюю задержку датаграмм. Более того, чтобы под-
считать максимальную задержку датаграммы, сначала нужно определить фиксирован-
ную задержку пути (задержка распространения и задержка передачи) и прибавить ее к
гарантированной максимальной задержке очереди. Важно отметить, что служба гаран-
тированной битовой скорости определяет максимальную задержку очереди, а не мак-
симальную общую сквозную задержку, поскольку такие компоненты последней, как
задержка распространения и задержка передачи полностью зависят от выбора пути, по
которому передается трафик.
Максимальная задержка очереди — это кумулятивная задержка передачи РАТН-
сообщения от источника до получателя. РАТН-сообщение содержит информацию о
задержке на всем пути от источника до получателя и в любое время предоставляет по-
лучателю ее точную оценку. Получатель использует информацию о задержке во время
запроса гарантированного обслуживания.
Служба гарантированной битовой скорости лучше всего подходит для тех прило-
жений масштаба реального времени, которые позволяют воспроизводить аудио- и ви-
деофайлы. Подобные приложения используют для своей нормальной работы буфер
дрожания с целью компенсации неравномерности прибытия пакетов. Определяя мак-
4 Specification of the Controlled-Load Network Element Service/Wroclawskl J. — RFC 2211, 1997.
5 Specification of Guaranteed Quality of Service/Shenker S., Partridge C, Guerin R. — RFC 2212, 1997
Глава 7. Интегрированные услуги: RSVP
185
симальную задержку очереди, служба гарантированной битовой скорости помогает
оценить необходимый размер буфера дрожания. Таким образом, приложения масшта-
ба реального времени могут рассчитывать на гарантированные полосу пропускания и
максимальную задержку.
Службы регулируемой нагрузки и гарантированной битовой скорости используют
корзину маркеров для описания параметров потока данных. Корзина маркеров — это
механизм регулирования интенсивности трафика, определяющий среднюю скорость
(средний объем данных, который можно передать за единицу времени), размер вспле-
ска (объем данных, который можно отправить в течение заданного промежутка вре-
мени без ущерба для планирования очереди) и интервал измерения (квант времени).
Более детально механизм регулирования интенсивности трафика с использованием
корзины маркеров описывается в главе 3, “Формирование трафика на границе сети:
классификация пакетов, маркировка пакетов и управление интенсивностью трафика”.
При использовании обеих служб получатель запрашивает в RESV-сообщении опреде-
ленную битовую скорость и размер всплеска. Планировщик WFQ и механизм управления
очередью WRED с предпочтительным весом гарантируют, что трафик достигнет получате-
ля через строго определенное время. Служба регулирования нагрузки обещает только
“хорошее обслуживание”, а служба гарантированной битовой скорости предоставляет ин-
формацию (в РАТН-сообщениях), из которой можно вычислить значение задержки.
Среда передачи и протокол RSVP
Двухточечная среда передачи, такая, как последовательная линия связи, прекрасно
подходит для протокола RSVP, а совместно используемая среда передачи, такая, как
Ethernet, ATM (Asynchronous Transfer Mode — режим асинхронной передачи), Frame
Relay и X.25, — не подходит.
В совместно используемой среде передачи нет способа дать гарантию, что другие уст-
ройства из того же сегмента не передают в данный момент трафик, который может при-
вести к перегрузке сегмента. Однако протокол RSVP все же может нормально работать на
не очень загруженных сегментах или на сегментах с небольшим количеством источников.
Чтобы решить проблему резервирования ресурсов в совместно используемой среде переда-
чи, был разработан протокол SBM — протокол управления доступом на основе RSVP для
сетей IEEE (Institute of Electrical and Electronic Engineers — Институт инженеров по элек-
тротехнике и электронике) семейства 802. Протокол SBM определяет некоторые RSVP-
расширения, которые предоставляют метод отображения протокола RSVP на устройства и
сети канального уровня. Более подробно этот метод описан в главе 8, “Качество
обслуживания на уровне 2: межсетевой обмен с IP QoS”.
В реализации компании Cisco с целью поддержки протокола RSVP в АТМ-сетях
для каждого резервирования создается коммутируемый виртуальный канал (Switched
Virtual Circuit — SVC) ATM с услугой переменной битовой скорости (Variable Bit
Rate — VBR). После этого весь зарезервированный трафик перенаправляется в соот-
ветственный канал SVC, а управление трафиком возлагается на АТМ-интерфейс.
Масштабируемость протокола RSVP
Недостатком протокола RSVP является то, что объем требуемой информации о состоя-
нии потоков увеличивается с ростом числа резервирований ресурсов для потоков трафика.
186
Часть I. Качество обслуживания в сетях IP
Так как в Internet-магистрали в любое время могут существовать многие сотни тысяч од-
ноадресных и многоадресных потоков, использование информации о состоянии каждого
потока считается немасштабируемым решением для магистралей Internet.
Протокол RSVP с резервированием ресурсов для каждого потока хорошо масшта-
бируется в корпоративных intranet-сетях среднего размера со скоростью линий связи
DS3 или меньше. При применении в больших intranet-сетях и магистралях поставщи-
ков услуг Internet (Internet Service Provider — ISP) протокол RSVP хорошо масштаби-
руется при условии использования больших многоадресных групп, больших статиче-
ских классов или объединения потоков на границах сети. Агрегирование RSVP-
резервирований6 предполагает слияние нескольких сквозных резервирований, имею-
щих обшие маршрутизаторы входа и выхода, в одно большое сквозное резервирова-
ние. Другой подход к решению проблемы масштабируемости протокола RSVP в ядре
крупной сети заключается в использовании протокола RSVP на границах сети и реа-
лизации diffserv-услуг в ее магистрали. Использование протокола RSVP в diffserv-сети
обсуждалось в главе 2, “Архитектура дифференцированных услуг”.
В будущем сети поставщиков услуг и Internet в большинстве случаев будут иметь
достаточно широкую полосу пропускания для передачи обычного телефонного трафи-
ка. При проектировании сети, имеющей достаточный запас полосы пропускания, весь
телефонный трафик можно выделить в отдельный класс. Ширина канала телефонного
трафика зависит от ширины доступной полосы пропускания сети. Поскольку этот ка-
нал будет являться частью общей полосы пропускания, ему не нужно будет выделять
ресурсы для каждого отдельного вызова.
Практический пример 7.1: сквозное резервирование
полосы пропускания для приложения с помощью
протокола RSVP
Приложения отправителя и получателя должны сигнализировать с помощью про-
токола RSVP о том, что они производят сквозное резервирование полосы пропуска-
ния для воспроизведения цифровой аудиозаписи. Трафик приложения отправителя и
получателя состоит из UDP-пакетов с портом назначения 1040. Схема сети изображе-
на на рис. 7.4 (обратите внимание, что IP-адрес на этом рисунке указывает только на
последний октет адреса сети 210.210.210.X). Предположим, что приложения отправи-
теля и получателя не являются RSVP-совместимыми и полагаются на конечные мар-
шрутизаторы, которые производят RSVP-сигнализацию.
Если приложения не являются RSVP-совместимыми, конечные маршрутизаторы
должны быть настроены так, как будто бы они все-таки получают периодическую
сигнальную информацию от отправителя и получателя. Нужно также сконфигуриро-
вать еще одно RSVP-резервирование для пакетов протокола ICMP (Internet Control
Message Protocol — протокол управляющих сообщений Internet) с тем, чтобы разре-
шить прохождение ping-пакетов между отправителем и получателем, если возникнет
необходимость устранения проблем соединения в сети.
6 Aggregation of RSVPfor IPv4 and IPv6 Reservations. IETF Draft/Baker et al., 1999.
Глава 7. Интегрированные услуги: RSVP
187
Примечание. IP-адрес на диаграмме обозначает только последний октет едреса 210.210.210.Х.
PATH
* UUH порт 1U4U
* RESV
PATH .
* ICMP
RESV
* PATH
ICMP
Рис. 7.4. RSVP-сигнализация и резервирование полосы пропускания для потоков тра-
фика между двумя конечными узлами
Примечание
Использование протокола RSVP с целью резервирования ресурсов для ICMP-
сообщений в этом примере необходимо только для иллюстрации работы протокола
RSVP, так как практическая необходимость в этом минимальная.
Для сквозной RSVP-сигнализации на входящих и исходящих интерфейсах мар-
шрутизаторов сети, расположенных на всем пути от отправителя до получателя, дол-
жен быть сконфигурирован механизм WFQ и протокол RSVP. Обратите внимание,
что механизм WFQ по умолчанию активен на интерфейсах с полосой пропускания
2 Мбайт или меньше. С помощью команды show interface можно узнать, какой метод
планирования очереди используется на заданном интерфейсе.
В этом практическом примере RSVP-резервирование ресурсов производится для
следующих протоколов.
• UDP-трафик (порт 1040) приложения от узла А до узла В.
• ICMP-трафик от узла А до узла Вив обратном направлении с целью проверки
и диагностики проблем связности во время перегрузок в сети. Таким образом,
всегда разрешается прохождение ping-пакетов (ICMP Echo Request) от одного
конечного узла до другого и ответных пакетов ICMP Echo Reply.
В листинге 7.1 показана конфигурация протокола RSVP на маршрутизаторе R1.
! Листинг 7.1. Конфигурация протокола RSVP на маршрутизаторе R1
interface EthernetO
ip address 210.210.210.1 255.255.255.224
fair-queue 64 256 234
ip rsvp bandwidth 7500 7500
i
interface SerialO
ip address 210.210.210.101 255.255.255.252
fair-queue 64 256 36
188
Часть I. Качество обслуживания в сетях IP
ip rsvp bandwidth 1158 1158
ip rsvp sender 210.210.210.60 210.210.210.30 1 0 0
210.210.210.30 EtO 1 1
ip rsvp sender 210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.30 EtO 32 32
ip rsvp reservation 210.210.210.60 210.210.210.30 1 0 0
210.210.210.30 EtO ff 1 1
Эта конфигурация указывает на необходимость активизации на интерфейсах мар-
шрутизатора R1 механизма WFQ и протокола RSVP. Команда fair-queue позволяет ус-
тановить порог отбрасывания очереди и максимальное число обычных и резервируе-
мых очередей диалога. Команда ip rsvp bandwidth устанавливает максимальную ширину
резервируемой полосы пропускания на интерфейсе и максимальную разрешенную ре-
зервируемую полосу пропускания для каждого отдельного резервирования.
Команда ip rsvp sender используется для настройки маршрутизатора таким образом,
как будто бы он периодически получает сообщения RSVP PATH от расположенного
ниже по потоку трафика отправителя, а также позволяет ему отправлять сообщения
RSVP PATH выше по потоку. Нужно отметить, что эта команда нужна только в том
случае, если отправитель не может посылать сообщения RSVP PATH.
В этой конфигурации используются две команды ip rsvp path. Они нужны для эму-
ляции получения периодических сообщений RSVP PATH от отправителя
210.210.210.30 для ICMP-трафика и UDP-трафика (порт 1040), соответственно. Мар-
шрутизатор R1 передает полученные сообщения RSVP PATH ниже по потоку трафика
в сторону точки назначения 210.210.210.60.
Команда ip rsvp reservation используется для настройки маршрутизатора таким об-
разом, как будто бы он периодически получает сообщения RSVP RESV. В данной
конфигурации эта команда используется для получения периодических запросов на
резервирование ресурсов (RSVP RESV) для ICMP-трафика от узла 210.210.210.30. По-
добным образом обеспечивается RSVP-резервирование ресурсов для ping-пакетов
(ICMP), передающихся от узла В до узла А. Сами же сообщения RSVP RESV про-
двигаются по направлению к источнику 210.210.210.60.
В листингах 7.2 и 7.3 показаны конфигурации протокола RSVP для маршрутизато-
ров R2 и R3, соответственно.
। Листинг 7.2. Конфигурация протокола RSVP на маршрутизаторе R2 j
interface SerialO
ip address 210.210.210.102 255.255.255.252
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface Seriall
ip address 210.210.210.105 255.255.255.252
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
Обратите внимание, что для этого маршрутизатора не нужны операторы ip rsvp sender и
ip rsvp reservation, поскольку они необходимы только на пограничных маршрутизаторах.
Глава 7. Интегрированные услуги: RSVP
189
Пограничные маршртуизаторы динамически распространяют RSVP-сообщения для того,
чтобы позволить маршрутизатору R2 произвести резервирование для RSVP-потоков.
j Листинг 7.3. Конфигурация протокола RSVP на маршрутизаторе R3
interface Ethernet!)
ip address 210.210.210.33 255.255.255.224
fair-queue 64 256 234
ip rsvp bandwidth 7500 7500
I
interface Seriall
ip address 210.210.210.106 255.255.255.252
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
ip rsvp sender 210.210.210.30 210.210.210.60 1 0 0
210.210.210.60 EtO 1 1
ip rsvp reservation 210.210.210.60 210.210.210.30 100
210.210.210.60 EtO FF LOAD 1 1
ip rsvp reservation 210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.60 EtO FF LOAD 32 32
В листингах 7.4-7.10 приведена различная информация, касающаяся протокола RSVP.
Листинг 7.4. Информация о RSVP-интерфейсе маршрутизатора R1
Router#show ip rsvp interface
interfac UDP М/С allocate i/f max flow max per/255 UDP IP UDP_IP
EtO 0 IK 7500K 7500K 0 /255 0 1 0
SeO 0 ЗЗК 1158K 1158K 7 /255 0 1 0
С помощью команды show ip rsvp interface можно получить информацию о распределе-
нии полосы пропускания интерфейса. По умолчанию, максимальная резервируемая поло-
са пропускания на интерфейсе равна 75% от общей полосы пропускания интерфейса.
! Листинг 7.5. Информация, касающаяся RSVP-получателя,
на маршрутизаторе R1
RouterUshow ip rsvp sender
To From Pro DPort Sport
Prev Hop I/F BPS Bytes
210.210.210.30 210.210.210.60 1 0 0
210.210.210.102 SeO IK IK
210.210.210.60 210.210.210.30 1 0 0
210.210.210.30 EtO IK IK
190
Часть I. Качество обслуживания в сетях IP
210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.30 EtO 32K 32K
Результат выполнения команды show ip rsvp sender показывает, что маршрутизатор R1
“увидел” три различных сообщения RSVP PATH.
Листинг 7.6. Запросы RSVP-резервирования, полученные
маршрутизатором R1
Routerishow ip rsvp reservation
To From Pro DPort. Sport
Next Hop I/F Fi Serv BPS Bytes
210.210.210.30 210.210.210.60 1 0 0
210.210.210.30 EtO FF LOAD 1K IK
210.210.210.60 210.210.210.30 1 0 0
210.210.210.102 SeO FF LOAD IK IK
210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.102 SeO FF LOAD 32K 32K
Результат выполнения команды show ip rsvp reservation показывает, что маршрути-
затор R1 получил три сообщения RSVP RESV. В этом примере маршрутизатор R1 по-
лучил одно сообщение RSVP RESV для UDP-потока от маршрутизатора R2 со сле-
дующей точкой назначения 210.210.210.102.
; Листинг 7.7. Установленные RSVP-резервирования на маршрутизаторе R1 j
Routerishow ip rsvp installed
RSVP: EthernetO
BPS То Weight Conv From Protoc DPort Sport
IK 210.210.210.30 4 264 RSVP: SerialO 210.210.210.60 1 0 0
BPS To Weight Conv From Protoc DPort Sport
IK 210.210.210.60 128 264 210.210.210.30 1 0 0
32K 210.210.210.60 210.210.210.30 UDP 1040 0
4 265
Результат выполнения команды show ip rsvp installed показывает наличие трех ак-
тивных RSVP-резервирований на маршрутизаторе R1. Он также показывает номер
диалога и вес, назначенный механизмом WFQ для каждого резервирования.
Обратите внимание, что вес наибольшего RSVP-резервирования всегда равен 4.
Вес резервирования для ICMP-пакетов на интерфейсе serialO рассчитывается по сле-
дующей формуле:
4 х (запрос на RSVP-резервирование) + (наибольшее распределенное
RSVP-резервирование) = 4 х 32 + 1 = 128.
Глава 7. Интегрированные услуги: RSVP
191
; Листинг 7.8. RSVP-резервирования, отправленные маршрутизатором R1
! . , выше по потоку
Routerlshow ip rsvp request
To From Pro DPort Sport
Next Hop I/F Fi Serv BPS Bytes
210.210.210.30 210.210.210.60 1 0 0
210.210.210.102 SeO FF LOAD IK IK
210.210.210.60 210.210.210.30 1 0 0
210.210.210.30 EtO FF LOAD IK IK
210.210.210.60 210.210.210.30 DDP 1040 0
210.210.210.30 EtO FF LOAD 32K 32K
Результат выполнения команды show ip rsvp request показывает, что
маршрутизатор R1 передал три сообщения RSVP RESV. В этом примере маршрутиза-
тор R1 отправил сообщение RSVP RESV для UDP-потока расположенному ниже по
потоку узлу со следующей точкой назначения 210.210.210.30.
| Листинг 7.9. RSVP-соседи маршрутизатора R1
Router#show ip rsvp neighbor
Interfac Neighbor Encapsulation
EtO 210.210.210.30 RSVP
SeO 210.210.210.102 RSVP
Результат выполнения команды show ip rsvp neighbor показывает соседние маршру-
тизаторы или узлы, от которых маршрутизатор R1 получил RSVP-сообщения.
i Листинг 7.10. Информация об очереди интерфейса serialO
маршрутизатора R1
Routerfshow queue serialO
Input queue: 0/75/1071 (size/max/drops); Total output drops:
107516
Queueing strategy: weighted fair
Output queue: 41/1000/64/107516 (size/max total/threshold/drops)
Conversations 1/4/256 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
(depth/weight/discards/tail drops/interleaves) 1/4096/100054/0/0
Conversation 265, linktype: ip, length: 50
source: 210.210.210.30, destination: 210.210.210.60, id:
0x033D,
ttl: 254, TOS: 0 prot: 17, source port 38427,
destination port 1040
(depth/weight/discards/tail drops/interleaves) 40/4096/1131/0/0
Conversation 71, linktype: ip, length: 104
192
Часть I. Качество обслуживания в сетях IP
source: 210.210.210.30, destination: 210.210.210.60, id:
0x0023, ttl: 254, prot: 1
(depth/weight/discards/tail drops/interleaves) 1/128/65046/0/0
Conversation 264, linktype: ip, length: 104
source: 210.210.210.30, destination: 210.210.210.60, id:
0x0023, ttl: 254, prot: 1
В приведенном выше листинге показаны пакеты, находящиеся в выходной очереди
интерфейса serialO на момент выполнения команды show queue serialO. Обратите вни-
мание, что номера диалогов RSVP-потоков в очереди совпадают с теми, которые были
получены с помощью команды show ip rsvp installed.
Практический пример 7.2: использование протокола RSVP
с целью резервирования ресурсов для VoIP-трафика
Предположим, что на маршрутизаторах R1 и R3 (см. рис. 7.4) есть коммутируемые пор-
ты, предназначенные для подсоединения аналоговых телефонов с целью использования
сети для осуществления обычных телефонных звонков. Телефонный разговор требует ре-
зервирования ресурсов для гарантированного обслуживания со стороны сети.
В дополнение к конфигурации протокола RSVP, приведенной в практическом
примере 7.1, в листингах 7.11 и 7.12 приведены примеры конфигурации VoIP-узлов
(конечных точек вызова) и соответствующего RSVP-резервирования.
j Листинг 7.11. Конфигурация VoIP QoS на маршрутизаторе R1 1
dial-peer voice 1211 voip
req-qos guaranteed-delay
^Листинг 712. Конфигурация VoIP QoS на маршрутизаторе R3 |
dial-peer voice 1212 voip
req-qos guaranteed-delay
Команда req-qos guaranteed-delay устанавливает гарантированную задержку в каче-
стве требуемого (запрошенного) уровня QoS для конечной точки вызова. Другие за-
просы QoS могут представлять собой либо запросы на управление нагрузкой, либо за-
просы на доставку без гарантий. По умолчанию для голосового вызова используется
только услуга негарантированной доставки.
Примечание
Время повторной передачи RSVP-сообщений может быть слишком большим для
VoIP-трафика. Так как потеря сообщений RSVP PATH может негативно сказаться на
VoIP-трафике вследствие задержек RSVP-резервирования на пути VoIP-вызова, очень
важно иметь либо небольшой hello-интервал для сообщений RSVP PATH, либо быст-
рую схему повторной передачи сообщений.
Глава 7. Интегрированные услуги: RSVP
193
Резюме
В рамках архитектуры intserv протокол RSVP используется для сигнализации QoS-
требований с помощью управляющих сообщений, которые отличаются от обычных
пакетов с данными. RSVP-сигнализация предоставляет определенные ресурсные га-
рантии на всем пути трафика.
При использовании протокола RSVP архитектура intserv, как и архитектура diffserv, за-
висит от планировщика пакетов в маршрутизаторе с поддержкой QoS (такого, как WFQ и
WRED), обеспечивающего требуемое качество обслуживания для RSVP-потоков.
Ответы на часто задаваемые вопросы
Приведите примеры приложений с поддержкой протокола RSVP.
Примерами популярных настольных приложений с поддержкой протокола RSVP могут
служить Microsoft NetShow и NetMeeting. Более того, новая операционная система Micro-
soft Windows — Windows 2000 — имеет встроенную поддержку протокола RSVP.
Можно ли узнать, для какого сеанса, адреса и порта была зарезервирована полоса
пропускания на определенном интерфейсе?
Эту информацию можно получить, выполнив на маршрутизаторе команду show ip rsvp
installed. Кроме этого, с помощью команды show tech-support rsvp можно просмотреть ре-
зультаты выполнения всех доступных RSVP-команд, включая команду show ip rsvp.
Как можно убедиться, что управляющие RSVP-пакеты имеют больший приоритет,
чем остальной трафик сети ?
Сетевой оператор может установить высокий IP-приоритет для управляющих
RSVP-пакетов с тем, чтобы они обрабатывались сетью в первую очередь.
На каком уровне протокола — IP или UDP — работает протокол RSVP?
Протокол RSVP работает на уровне протокола IP, используя поле протокола 46.
Однако на узлах, которые не могут напрямую обращаться к сети (другими словами,
отправлять и получать IP-датаграммы), необходима инкапсуляция протокола UDP.
Для того чтобы использовать протокол RSVP, такие системы должны инкапсулировать
RSVP-сообщения в датаграммы протокола UDP. Для такой инкапсуляции использу-
ются хорошо известные UDP-порты 1698 и 1699.
Я выполняю статическую команду ip rsvp sender 224.10.10.10 10.1.15.5 udp 0 0
10.1.15.5 Hssi 1/0 1200 4, но маршрутизатор выдает сообщение RSVP: sender not
accepted. Моя команда не принимается?
Это сообщение об ошибке может появиться по нескольким причинам. Наиболее
распространенная из них заключается в том, что на интерфейсе, идущем к отправите-
лю (в данном случае Hssi 1/0), не активизирован механизм WFQ в то время, как про-
токол RSVP используется. Так как протокол RSVP полагается на механизм WFQ для
распределения ресурсов, возникает указанная выше ошибка.
Почему в результате выполнения команды show ip rsvp installed не отображаются вес
и номера диалогов для установленных резервирований?
Вес и номера диалогов определяются механизмом WFQ. Убедитесь, что на интер-
фейсе, на котором установлено резервирование, используется этот механизм. Более
194
Часть I. Качество обслуживания в сетях IP
подробно механизм WFQ обсуждается в главе 4, “РНВ-политика: распределение
ресурсов (часть 1)”.
Команда show ip rsvp installed отображает номер диалога 256 и вес 4 для RSVP-
резервирования на интерфейсе serialO. Однако команда show queue sO отображает
вес 4096 для диалога 256. Как можно объяснить эту разницу?
Наиболее вероятно, что интенсивность RSVP-потока превышает зарезервирован-
ную полосу пропускания. Если интенсивность потока превышает зарезервированную
полосу пропускания, чрезмерный трафик доставляется методом негарантированной
доставки, на что указывает вес 4096, присвоенный ему механизмом WFQ. Следова-
тельно, пакет с весом 4096 может представлять собой пакет трафика, не согласующе-
гося с установленными параметрами. Более подробно механизм WFQ обсуждается в
главе 4, “РНВ-политика: распределение ресурсов (часть 1)”.
Маршрутизатор не может установить RSVP-резервирование для потока, который я
только что сконфигурировал. В результате выполнения команды debug ip rsvp выдается
следующее сообщение: RSVP RESV: по path information for 207.2.23.1. Что означает это
сообщение?
Обычно это сообщение появляется на маршрутизаторе, на котором сконфигуриро-
вано статическое RSVP-резервирование для потока и который ведет себя так, как если
бы он периодически получал RESV-сообщения для этого потока. Отладочное сообще-
ние информирует вас, что маршрутизатор не получил ни одного РАТН-сообщения для
соответствующего потока. Протокол RSVP не может отправить RESV-сообшение, не
получив сначала соответствующее РАТН-сообщение для потока. Проверьте путь к по-
лучателю, для того чтобы определить причину, по которой маршрутизатор не получает
сообщения RSVP PATH.
Верно ли то, что RSVP-сообщения коммутируются с помощью механизма CEF (Cisco
Express Forwarding — скоростная коммутация пакетов Cisco) ?
Нет. RSVP-сообщения являются управляющими пакетами, которые должны быть об-
работаны маршрутизатором посредством механизма коммутации процессов. Следует отме-
тить, что пакеты с данными, принадлежащие RSVP-потоку, обрабатываются посредством
механизма коммутации, сконфигурированного на маршрутизаторе. Более подронбо ком-
мутация пакетов обсуждается в приложении Б, “Механизмы коммутации пакетов”.
Глава 7. Интегрированные услуги: RSVP
195
Часть
Качество обслуживания
канального уровня и сети
МРкБуМмежсетевой обмен
В этой части. ~
® ж
11
О ’«/л
Глава 8. Качество обслуживания на уровне 2:
межсетевой обмен с IP QoS
Глава 9. Качество обслуживания в сетях MPLS
199
241
?й'
?<ь г.
Аг<;й^Ии (W
.«г
&'
f
А?’
•т.'
.<«
Глава
8
качество обслуживания
на уровне 2: межсетевой обмен
с IP QoSlB,
А Чаше всего в сетах используются разнообразные технологии передачи информа-
ции. В таких популярных технологиях канального уровня, как режим асинхронной
^передачи (Asynchronous Transfer M6de?- ATM), ретрансляция кадров (Frame Relay) и
Ethernet, фунйши качества, обслуЦдоЦмя (Quality of Service — QoS) реализуются на
^уровне 2 эталойнойгмодели4Р51. Йрй главе обсуждаются технологии канального
^ровда^^ййожеёгвенным доступом и .способ реализации в них качества обслужива-
ния.'Поскольку качество раббты функций QoS приравнивается к качеству работы са-
gMoro слабого кай&а в сети, необходимсйудостовериться, чтобы функции QoS Intemet-
Дпротокола (IP) были непрерывны при переходе на другие технологии канального
руровня. Таким образом, для обеспечения,сквозной работы IP QoS необходимо, чтобы
p QoS на уровне 2 преобразовывалась в IP QoS, и наоборот.
ft 4.’ ,
" ^АТЛЛ <i ‘-М. v .•<
ATM1 — это технология коммутации и мультиплексирования ячеек с фиксиро-
| ванным размером. "Поскольку данная технология ориентирована на соединение,
1 виртуальный канал (Virtual Circuit —- VC) в ATM-сети должен быть установлен до
того, как пользователь сможет передавать данные между двумя и более АТМ-
устройствами. В основном в технологии ATM используются два типа соединения
(два виртуальных канала): постоянные виртуальные каналы (Permanent Virtual
.Circuit— PVC) ^коммутируемые виртуальные каналы (Switched Virtual Circuit —
SVC). Первые обычно являются статическими и нуждаются в ручной или внеш-
ней настройке. Каналы SVC являются динамическими и создаются по требова-
нию. Для установки и тех и других каналов требуется сигнальный протокол между
конечными ATM-точками и АТМ-коммутаторами.
1 The ATM Forum, www.atmforum.com
ATM-сеть состоит из ATM-коммутаторов и конечных ATM-узлов. Для коммутации
АТМ-ячеек ATM-коммутаторы используют информацию, которая находится в заго-
ловке ячейки. Канальный уровень разбивается на два подуровня: уровень адаптации
ATM (ATM Adaptation Layer — AAL) и ATM-уровень. Различные услуги переносятся
на ATM-уровень с помощью уровня AAL. Пользовательская информация передается
на уровень AAL из более высоких уровней в виде битов. Далее она инкапсулируется в
AAL-кадр, а затем ATM-уровень разбивает эту информацию на ATM-ячейки. На сто-
роне получателя все делается в обратном порядке. Этот процесс известен под назва-
нием сегментация и повторная сборка (Segmentation and Reassembly — SAR).
Формат ATM-ячейки
Каждая ATM-ячейка состоит из 53 байт — 5 байт информации в заголовке и
48 байт пользовательской информации (так называемой полезной нагрузки (payload)).
Существует два формата ATM-ячейки: интерфейс “пользователь-сеть” (User-to-
Network Interface — UNI), в котором определяется формат ячеек, передающихся меж-
ду пользователем и ATM-коммутатором; и межсетевой интерфейс (Network-to-
Network Interface — NNI), в котором определяется формат ячеек, передающихся меж-
ду коммутирующими узлами. Форматы ячеек показаны на рис. 8.1.
Заголовок (5 байт) GFC VPI VPI
VPI VCI VCI
PT CLP PT CLP
НЕС НЕС
Полезная нагрузка (48 байт) Полезная нагрузка (48 байт) Полезная нагрузка (48 байт)
— 8 бит --------►
АТМ-ячейка ATM-ячейка UNI ATM-ячейка NNI
GFC — общее управление потоком (Generic Flow Control)
VPI — идентификатор виртуального пути (Virtual Path Identifier)
VCI — идентификатор виртуального канала (Virtual Channel Identifier)
PT —тип полезной нагрузки (Payload Тура)
CLS — приоритет отбрасывания ячайки (Call Loss Priority)
НЕС — контроль ошибок в заголовке (Header Error Control)
Рис. 8.1. Форматы заголовка для А ТМ-ячеек типа UNI и NNI
Общее управление потоком (GFC) влияет на локальное (пользовательское) управ-
ление потоком. Механизм GFC используется для управления трафиком, который ис-
ходит из конечных станций в сеть. В формате NNI-ячейки поля GFC нет. Определя-
ется два режима работы: неконтролируемый доступ и контролируемый доступ. Тра-
200 Часть II. Качество обслуживания канального уровня и сети MPLS...
фик, который поступает в сеть без управления потоком на основе механизма GFC,
находится в режиме неконтролируемого доступа. В режиме контролируемого доступа
конечные узлы, подключенные к ATM-сети, формируют передачу данных в соответст-
вии со значением, которое находится в поле GFC. В большинстве реализаций интер-
фейса UNI это поле не используется.
Виртуальный путь (Virtual Path — VP) состоит из набора виртуальных каналов, ему
присваивается идентификатор виртуального пути — VPI (Virtual Path Identifier). ATM-
коммутаторы коммутируют идентификаторы VPI вместе со всеми содержащимися в
них виртуальными каналами. Виртуальные каналы являются путями, по которым пе-
редаются пользовательские данные. Каждому виртуальному каналу, который входит в
состав виртуального пути, присваивается идентификатор виртуального канала — VCI
(Virtual Channel Identifier). Поля VPI и VCI используются ATM-коммутаторами при
принятии решения во время коммутации.
На рис. 8.2 показан виртуальный канал, установленный между маршрутизаторами
R1 и R2 в сети, состоящей из ATM-коммутаторов. Всем ячейкам, исходящим из мар-
шрутизатора R1 в маршрутизатор R2, присваивается значение поля VP1, равное 0, и
значение поля VCI, равное 64. ATM-коммутатор S1 просматривает пару VPI/VCI в
порту 0 и ищет ее в своей таблице отображения. Исходя из этой информации, комму-
татор направляет ячейки через порт 1 с новым значением VPI, равным 1, и новым
значением VCI, равным 100. Аналогично, коммутатор S4 получает ячейки в порт 4 со
значением VPI, равным I, и значением VCI, равным 100. Основываясь на своей таб-
лице отображения, коммутатор направляет их в порт 3 с новым значением VPI, рав-
ным 2, и новым значением VCI, равным 100.
Рассмотрим оставшиеся поля АТМ-заголовка.
• Идентификатор типа полезной нагрузки (Payload Type Identifier — РТП). Это 3-
битовое поле используется для определения типа полезной нагрузки в ячейке.
Оно необходимо для того, чтобы отличать операционную, административную и
обслуживающую (Operation, Administration and Maintenance — OAM) информа-
цию от данных пользователя.
• Приоритет потери ячейки (Cell Loss Priority — CLP). Поле CLP определяет при-
оритет ячейки. Если этот бит не установлен (CLP = 0), то считается, что у
ячейки больший приоритет, чем у ячейки с установленным полем CLP
(CLP =1). В случае перегрузки сети у ячеек с установленным битом CLP
больше шансов быть отброшенными.
• Контроль ошибок в заголовке (Header Error Control — НЕС). Контроль НЕС ис-
пользуется для обнаружения и исправления ошибок в АТМ-заголовке.
ATM QoS
Технология ATM предоставляет QoS-гарантии путем явного определения конеч-
ными ATM-станциями контракта, описывающего характеристики их трафика. Деск-
риптор потока несет такие параметры QoS, как пиковая скорость передачи ячеек
(Peak Cell Rate — PCR), стабильная скорость передачи ячеек (Sustainable Cell Rate —
SCR) и размер всплеска.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 201
Таблица отображения каналов PVC на порту 0 коммутатора S1
PVC Выходной PVC Выходной порт
0/64 1/100 1
PVC Выходной PVC Выходной порт
1/100 2/100 3
Рис. 8.2. Соединение между маршрутизаторами R1 и R2 через АТМ-сеть
Конечные ATM-системы отвечают за то, чтобы переданный трафик соответствовал
контракту QoS. Они формируют трафик путем буферизации данных и передачи его в
рамках параметров контракта QoS. ATM-коммутаторы проверяют каждую характери-
стику пользовательского трафика и сравнивает ее с контрактом QoS. Если определен-
ная часть трафика не удовлетворяет контракту QoS, коммутатор может установить
CLP-бит для всего не согласующегося с заданными параметрами трафика. А, как из-
вестно, у ячейки с установленным битом CLP большая вероятность быть отброшен-
ной при перегрузке сети, чем у ячейки со значением бита CLP, равным 0.
Классы услуг ATM
Уровень AAL предоставляет технологии ATM ту самую гибкость, которая позволя-
ет определять совершенно разные услуги передачи трафика в одном формате. ATM
предусматривает наличие пяти разных типов уровня AAL в зависимости от поддержи-
ваемого типа услуги. Уровни AAL1 и AAL2 соответствуют услугам с постоянной ско-
ростью передачи (Constant Bit Rate — CBR) и переменной скоростью передачи
(Variable Bit Rate — VBR) информации. Уровни AAL3 и AAL4, которые соответствова-
ли услугам передачи данных с ориентировкой и без ориентировки на соединение,
сейчас поглощены более обобщенным уровнем AAL5, соответствующим услуге пере-
дачи данных, объединенных в пакеты.
202
Часть II. Качество обслуживания канального уровня и сети MPLS...
Существующие услуги ATM основываются на синхронизации между источником и
пунктом назначения, интенсивности трафика и режиме соединения. Форум ATM оп-
ределяет пять категорий услуг.
• Обслуживание с постоянной битовой скоростью (CBR). Предназначено для дан-
ных масштаба реального времени, которые не допускают задержек, дрожания, и
требуют широкую полосу пропускания. CBR — это синоним выражения
“эмуляция канала” (Circuit Emulation). Для такого типа трафика требуется заре-
зервированная полоса пропускания, которая должна предоставляться по требо-
ванию. В качестве примера можно привести передачу стандартного голосового
трафика на скорости 64 Кбит/с и трафика видеоизображений (стандарт Н.320).
• Переменная скорость передачи в режиме реального времени (Real-Time Variable Bit
Rate — RT-VBR). Как следует из названия, указанная услуга, как и CBR, пред-
назначается для передачи данных масштаба реального времени, однако в этом
случае источники могут отправлять данные неравномерно. Объединенный в па-
кеты трафик видеоизображений и данных с требованиями режима реального
времени (например, интерактивный мультимедийный трафик) относится имен-
но к этой категории. Услуга RT-VBR определяется параметрами PCR, SCR и
максимальным размером всплеска (maximum burst size — MBS).
• Переменная скорость передачи не в режиме реального времени (Non-Real Time
Variable Bit Rate — nRT-VBR). Данная услуга предназначена для приложений,
которые передают трафик всплесками и допускают наличие задержек и дрожа-
ния. В эту категорию попадают интерактивные транзакции данных. Услуга
nRT-VBR определяется параметрами PCR, SCR и MBS.
• Доступная скорость передачи (Available Bit Rate — ABR). ABR-источники регулируют
скорость передачи в соответствии с информацией, предоставляемой сетью. Услуга
ABR не резервирует полосу пропускания как таковую, а адаптирует трафик к сети,
основываясь на механизме обратной связи, который реализуется с помощью ячеек
управления ресурсами (Resource Management — RM). ABR использует метод оцени-
вания, состоящий в том, что скорость передачи на каждом виртуальном канале под-
бирается в соответствии с явным указанием скорости, которое передается RM-
ячейками. RM-ячейки передаются перед ячейками с данными. Скорость источника
контролируется вернувшимися RM-ячейками, которые закольцовываются пунктом
назначения или виртуальным пунктом назначения. RM-ячейки представляют собой
новый источник издержек, связанных с передачей служебной информации. Услуга
ABR хорошо работает с протоколом управления передачей2 (Transmission Control
Protocol — TCP), в котором реализован адаптивный алгоритм управления потоком.
Услуга ABR определяется параметром PCR и гарантируемой минимальной скоро-
стью передачи ячеек (Minimum Cell Rate — MCR) на каждом виртуальном канале.
• Неопределенная битовая скорость (Unspecified Bit Rate — UBR). UBR является
ATM-эквивалентом услуги передачи данных методом негарантированной достав-
ки протокола IP. В соответствии с этой услугой резервирование полосы пропус-
кания не производится, а также нет никаких ограничений, касающихся задержки
и дрожания. На уровне ATM также не осуществляется контроль за перегрузкой
сети. Примером трафика такого типа может служить массивная передача файлов,
2 Romanov/ A., Floyd S. Dynamics of TCP Traf.c over ATM Networks. — IEEE JSAC, V. 13, N 4,
May 1995, p. 633—641.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 203
в частности резервирование системы. Протокол TCP не очень хорошо работает в
связке с услугой LJBR, так как передача данных по UBR-каналу может характери-
зоваться потерей ячеек. Однако положение можно исправить с помощью страте-
гий отбрасывания ячеек, которые описываются в следующем разделе.
Стратегии отбрасывания ячеек
Как уже говорилось ранее в этой главе, в ATM-заголовке есть CLP-бит для указания
приоритета потери ячейки. В первую очередь отбрасываются ячейки с CLP = 1, а во вто-
рую — ячейки с CLP = 0. Механизм ограничения ATM-трафика может установить CLP-
бит равным 1 в ячейке, которая нарушила спецификацию контракта трафика виртуального
канала. Когда в какой-то части ATM-сети происходит перегрузка, могут быть отброшены
любые ячейки, однако ячейки с установленным CLP-битом отбрасываются в первую оче-
редь. Частичное отбрасывание пакетов (Partial Packet Discard — PPD) и раннее отбрасыва-
ние пакетов (Early Packet Discard — EPD) — это стратегии отбрасывания ATM-ячеек, ко-
торые способны эффективно повысить производительность АТМ-сети.
Функция ATM SAR отвечает за разбивку больших пакетов на ячейки. Если отбро-
шенная ATM-ячейка является частью большого пакета, совершенно не обязательно
посылать оставшиеся ячейки, которые принадлежат сегментированному пакету, так
как в этом случае возникнет ненужный трафик на и без того перегруженном канале.
В этом случае повторная сборка ячеек в первоначальный пакет в конечном пункте не-
возможна и необходимо повторно переслать весь пакет целиком. Следовательно, ко-
гда отбрасывается ячейка большого пакета, функция PPD отбрасывает и остальные
ячейки, принадлежащие этому пакету. Преимущество такого подхода ограничено, так
как коммутатор начинает отбрасывать ячейки только в случае переполнения буфера.
Реализация функции PPD напрямую зависит от уровня AAL5. Эта функция может
быть сигнализирована на каждом виртуальном канале. Коммутатор отбрасывает ячей-
ки на определенном виртуальном канале до тех пор, пока установленный в заголовке
ATM-ячейки параметр не укажет на то, что ALL-пакет закончился. Сама ячейка, яв-
ляющаяся признаком конца пакета, не отбрасывается. Так как AAL5 не поддерживает
одновременное мультиплексирование пакетов на одном виртуальном канале, эту
ячейку можно использовать для определения границ пакета.
Поскольку отбрасывание ячеек большого пакета (и, как следствие, применение
функции PPD) может произойти после того, как предыдущие ячейки большого пакета
были поставлены в очередь на отправку, функция PPD производит только частичное
отбрасывание пакета. Поэтому по перегруженному каналу все еще будет передаваться
значительная часть ячеек, принадлежащих поврежденным пакетам. Следует отметить,
что если отброшенная ячейка была первой в пакете, то PPD отбрасывает весь пакет.
С другой стороны, функция EPD3 применяется еще перед тем, как какая-либо ячейка
допускается в очередь на отправку. Во время поступления новых пакетов алгоритм
EPD проверяет коэффициент загрузки выходного буфера. Если этот коэффициент
ниже сконфигурированного порогового значения, ATM-коммутатор считает, что раз-
мер буфера не будет превышен и все ячейки пакета могут быть помещены в очередь.
В противном случае коммутатор предполагает, что буфер близок к переполнению и
весь пакет не может быть помешен в очередь, в результате чего пакет отбрасывается.
Таким образом, функция EPD либо ставит в очередь все ячейки пакета, либо отбра-
сывает весь пакет. В связи с тем, что функция EPD производит полное отбрасывание
3 Early Packet Discard (EPD) Page, www.aciri.org/floyd/epd.html
204
Часть II. Качество обслуживания канального уровня и сети MPLS...
пакета перед тем, как любая из ячеек пакета будет помещена в очередь, этот процесс
называется ранним отбрасыванием пакета (early packet discard).
Выравнивание трафика на виртуальном пути
Как и на виртуальном канале ATM, аналогичные услуги по выравниванию трафика
можно применить с целью установки ограничений на контракт для целого виртуального
пути (VP). В пределах VP по всем виртуальным каналам может передаваться трафик UBR-
типа без каких-либо строгих ограничений по параметрам. На рис. 8.3 изображена логиче-
ская диаграмма виртуальных каналов, объединенных в виртуальный путь.
Рис. 8.3. Объединение виртуальных каналов в виртуальный путь
Примечание
Услуги ATM, применяемые на уровне виртуального пути, могут поддерживать все
классы услуг ATM, применяемые на уровне виртуального канала.
Практический пример 8.1: применение услуги ABR
к каналу PVC
Предположим, вы сконфигурировали услугу ABR на PVC-канале маршрутизатора
(VP1 = О, VCI = 34). Параметры PCR и MCR услуги ABR равны 10 Мбит/с и 1 Мбит/с,
соответственно. Интенсивность ABR-трафика необходимо увеличивать и уменьшать с ко-
эффициентом 8 в ответ на сообщения сети, полученные посредством RM-ячеек.
В листинге 8.1 показана соответствующая конфигурация маршрутизатора.
J Листинг 8.1. Конфигурация услуги ABR для канала PVC на интерфейсе . s
[ АТМ/0/0/0 i
interface atm 0/0/0
ip address 225.225.255.2 255.255.255.252
pvc 0/34
abr 10000 1000
atm abr rate-factor 8 8
Услуга ABR сконфигурирована с параметрами PCR и MCR, равными 10 Мбит/с и
1 Мбит/с, соответственно. Команда atm abr rate-factor 8 8 указывает на необходимость
увеличения и уменьшения скорости передачи ячеек в зависимости от контрольной
информации, полученной из сети.
Обратите внимание, что значения по умолчанию для параметров PCR и MCR рав-
ны линейной интенсивности и 0, соответственно. Стандартный коэффициент интен-
сивности равен 16.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 205
Практический пример 8.2: выравнивание трафика
на виртуальном пути
Поставщик услуг Internet (ISP) 1-го уровня желает сотрудничать с альтернативной
местной телекоммуникационной компанией (Competitive Local Exchange Carrier —
CLEC) с целью предоставления виртуального ISP-продукта. CLEC предоставляет фи-
зический DSL-доступ для конечных пользователей, a ISP 1-го уровня — соединение с
Internet. Предположим, что поставщик услуг ISP-1 покупает Intemet-канал шириной
6 Мбайт/с у ISP 1-го уровня. Интерфейсы ISP 1-го уровня напрямую (через CLEC)
подключены к DSL-каналам конечных пользователей поставщика услуг ISP-1. Обра-
тите внимание, что у поставщика услуг ISP-1 нет своего оборудования — он владеет
только договорами с конечными пользователями. CLEC предоставляет отдельный
виртуальный канал ATM для соединения каждого пользователя с ISP 1-го уровня.
ISP 1-го уровня устанавливает ограничение на общую полосу пропускания вирту-
ального пути к поставщику услуг ISP-1. Внутри VP виртуальные каналы могут иметь
либо постоянную скорость передачи (CBR) информации, либо свободно менять свою
полосу пропускания (как при использовании услуги UBR), насколько это позволяет
постоянная интенсивность виртуального пути.
CLEC использует мультиплексор доступа цифровых абонентских линий (Digital
Subscriber Line Access Multiplexer — DSLAM), который представляет собой блок ADSL-
карт (Asynchronous Digital Subscriber Line — асинхронная цифровая абонентская ли-
ния), мультиплексирующих данные для передачи на интерфейс или в канал магист-
ральной сети (Tl, ОСЗ DS3, ATM или Frame Relay). Мультиплексор DSLAM является
ADSL-эквивалентом модемной стойки в оборудовании поставщика услуг Internet. В
нашем случае DSLAM принадлежит альтернативной местной телекоммуникационной
компании (CLEC). Как показано на рис. 8.4, мультиплексор DSLAM подключается к
маршрутизатору ISP 1-го уровня через коммутатор ATM/Frame, который находится в
точке присутствия (Point of Presence — РоР) CLEC.
ISP1
DSL __________
ZZZZ DSLAM
DSL
ISP 2
Frame
Reley
CLEC
Поставщик услуг Internet 1-го уровня
VP с
пропускной
(или ОС-3)
пропускной (или ОС-3)
способностью
3 Мбайт/с
Рис. 8.4. Пример выравнивания VP-трафика
Каждому поставщику услуг Internet, подсоединенному через CLEC, назначается
интерфейс на маршрутизаторе ISP 1-го уровня; при этом все его (вторичного ISP)
206 Часть II. Качество обслуживания канального уровня и сети MPLS...
виртуальные каналы попадают в один виртуальный путь. В примере конфигурации
маршрутизатора ISP 1-го уровня, показанной в листинге 8.2, видно, что для постав-
щика услуг ISP-1 назначен интерфейс АТМО/О/О и виртуальный путь 2. Механизм
выравнивания VP-трафика конфигурируется на главном ATM-интерфейсе. Все вирту-
альные каналы используют один VP, при этом каждому из них присвоен собственный
субинтерфейс на главном интерфейсе.
Листинг 8.2. Конфигурация механизма выравнивания VP-трафика *
.< на интерфейсе АТМО/О/О маршрутизатора ISP 1-го уровня
interface АТМО/О/О
atm pvp 2 6000000
f
interface АТМО/О/О.1 point-to-point
ip address 212.12.12.1 255.255.255.252
atm pvc 101 2 101 aal5snap
I
interface АТМО/0/0.2 point-to-point
ip address 212.12.12.4 255.255.255.252
atm pvc 102 2 102 aal5snap
interface ATM 0/0/0.3 point-to-point
ip address 212.12.12.8 255.255.255.252
atm pvc 103 2 103 aal5snap
Как показано в листинге 8.2, команда atm pvp указывает на необходимость вырав-
нивания VP-трафика для всех виртуальных каналов указанного пути до обусловлен-
ной пиковой скорости.
Для того чтобы проверить конфигурацию групп VP, можно воспользоваться
командой show atm vp, которая выводит на экран параметры выравнивания VP-
трафика для всех VP-групп в маршрутизаторе. Всего можно создать до 256 таких
групп. Эта команда также показывает количество виртуальных каналов в VP-rpynne.
В листинге 8.3 приведены параметры выравнивания VP-трафика.
^Листинг8.3. .Параметрыi выравнивания vfp-трафика
Router#show atm vp
Data CES Peak CES
Interface VPI VCs VCs Kbps Kbps Status
АТМ0/0/0 2 3 0 6000000 0 ACTIVE
Вы можете получить более детальную информацию о виртуальном пути 2 с помо-
щью команды show atm vp 2. Эта команда выводит информацию обо всех виртуальных
каналах в маршрутизаторе с идентификатором VPI, равным 2. Два виртуальных канала
управления автоматически создаются маршрутизатором в каждой сконфигурирован-
ной VP-группе — один для передачи служебных ячеек ОАМ F4 сегмента и второй для
сквозной передачи служебных ячеек ОАМ F4. В листинге 8.4 приведена детальная
информация по виртуальным каналам с идентификатором виртуального пути 2.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 207
| Листинг 8.4. Информация о параметрах выравнивания VP-трафика для
i виртуального пути 2 Г
____ —____________________1______________________________________
Routertshow atm vp 2
ATM0/0/0 VPI: 2, PeakRate: 6000000, CesRate: 0, DataVCs: 3,
CesVCs: 0, Status: ACTIVE
VCD VCI Type InPkts OutPkts AAL/Encap Status
1 3 PVC 0 0 F4 OAM ACTIVE
2 4 PVC 0 0 F4 OAM ACTIVE
101 101 PVC 0 0 AAL5-SNAP ACTIVE
102 102 PVC 0 0 AAL5-SNAP ACTIVE
103 103 PVC 0 0 AAL5-SNAP ACTIVE
TotallnPkts: 0, TotalOutPkts: 0, TotallnFast: 0,
TotalOutFast: 0, TotalBroadcasts: 0
С помощью команды show atm vc можно просмотреть информацию обо всех вирту-
альных каналах на маршрутизаторе, независимо от их VPI. В листинге 8.5 отображена
информация обо всех виртуальных каналах ATM маршрутизатора.
Листинг 8.5. Параметры виртуальных каналов ATM
VCD / Peak Avg/Min Burst
Interface Sts Name VPI VCI Type Encaps SC Kbps Kbps Cells
0/0/0 UP 1 2 3 PVC F4-OAM UBR 6000000
0/0/0 UP 2 2 4 PVC F4-OAM UBR 6000000
0/0/0.1 UP 101 2 101 PVC SNAP UBR 6000000
0/0/0.2 UP 102 2 102 PVC SNAP UBR 6000000
0/0/0.3 UP 103 2 103 PVC SNAP UBR 6000000
Межсетевой обмен ATM и IP QoS
В IP сети, некоторая часть которой использует ATM в качестве основной технологии
передачи данных канального уровня (рис. 8.5), IP-трафик передается по АТМ-магистрали
посредством виртуального канала, который характеризуется определенным уровнем услуг
ATM QoS, соответствующим передаваемому 1Р-трафику. Однако из-за перегрузок на входе
в ATM-сеть размер очередей может возрасти, что приведет к отбрасыванию пакетов. Без IP
QoS такие отбрасывания происходят случайным образом без определения приоритета IP-
пакета, тем самым препятствуя обеспечению сквозных функций IP QoS в ATM-сети. По-
этому реализация функций IP QoS в ATM-сети оказывается просто необходимой. С этой
208
Часть II. Качество обслуживания канального уровня и сети MPLS...
целью на входных очередях ATM-сети следует применить такие механизмы QoS, как
взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detec-
tion — WRED) и взвешенный алгоритм равномерного обслуживания очередей (Weighted
Fair Queuing — WFQ). После этого отбрасывание пакетов и планирование выходной оче-
реди будет основываться на запрошенном уровне качества обслуживания пакета. Более
подробно алгоритмы WRED и WFQ обсуждаются в главе 4, “РНВ-политика: распределе-
ние ресурсов (часть 1)”, и главе 6, “РНВ-политика: предотвращение перегрузки и
политика отбрасывания пакетов”, соответственно.
IP-подсеть 1
Рис. 8.5. Передана IP-трафика через облако ATM
IP-подсеть 4
Обратите внимание, что с точки зрения IP QoS IP-трафик передается по АТМ-сети
без потерь (потери в АТМ-сети не отслеживаются на уровне IP QoS) с использовани-
ем услуги ATM, которая удовлетворяет всем запросам 1Р-трафика к качеству обслужи-
вания. На уровне IP QoS каждому виртуальному каналу АТМ-сети соответствует от-
дельная очередь, так что алгоритмы WRED и WFQ можно применить к любому VC.
В этом разделе обсуждаются два сценария обеспечения функций IP QoS при пере-
даче трафика через АТМ-сеть.
1. Один канал PVC переносит весь IP-трафик в конечную точку назначения. 1Р-трафик,
превышающий параметры ATM PVC, ставится в очередь на входе в ATM-сеть. По
мере возрастания перегрузки очередь обслуживается такими механизмами IP QoS,
как WRED и WFQ. Алгоритм WRED гарантирует, что потери более приоритетного
трафика будут гораздо меньше, чем потери менее приоритетного трафика. Алгоритм
WFQ гарантирует, что более приоритетному трафику будет предоставлена большая
полоса пропускания по сравнению с менее приоритетным трафиком, поскольку бо-
лее приоритетный трафик обслуживается чаще. Следует также отметить, что когда
трафик канала PVC обслуживается в соответствии со взвешенным механизмом рав-
номерного обслуживания очередей на основе класса (Class-Based Weighted Fair
Queuing — CBWFQ), вы можете назначать полосы пропускания в зависимости от
класса трафика. Более подробно механизм CBWFQ обсуждается в главе 4, “РНВ-
политика: распределение ресурсов (часть 1)”.
2. VC-связка, состоящая из нескольких PVC, переносит IP-трафик в конечную точку
назначения. Когда трафик с различными требованиями QoS (трафик масштаба
реального времени; трафик, передаваемый не в режиме реального времени; тра-
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 209
фик, передаваемый методом негарантированной доставки) доставляется в одно и то
же место, лучше всего создать несколько PVC-каналов в ATM-сети с целью передачи
каждого класса IP-трафика по отдельному каналу. Каждый PVC соответствует классу
услуг ATM в зависимости от передающегося по нему IP-трафика. На рис. 8.6 изо-
бражена схема межсетевого взаимодействия 1Р-АТМ с использованием VC-связки
(некоторые характеристики последней приведены ниже).
• Каждый виртуальный канал в связке предназначен для передачи трафика с
определенным значением IP-приоритета. Виртуальный канал можно скон-
фигурировать для передачи трафика с одним или несколькими значениями
IP-приоритета. При этом следует обратить внимание, что для каждой отдель-
ной PVC-связки устанавливается одно отношение соседства (смежности мар-
шрутизаторов).
• За целостностью канала VC можно следить с помощью технологий ATM ОАМ
или ILMI (Interim Local Management Interface — промежуточный интерфейс ло-
кального управления). Если виртуальный канал с высоким приоритетом перестает
работать, можно либо “перебросить” его трафик в канал с меньшим приоритетом
из этой же связки, либо объявить об обрыве всей связки.
• Для каждого виртуального канала в связке существует отдельная очередь. Для
каждой из них можно применить алгоритм IP QoS WRED и WFQ.
Рис. 8.6. VC-связка в сети ATM: отображение IP-npuopumema на виртуальные каналы
Ожидается, что класс услуг ATM для IP-трафика должен быть выше класса UBR
(передача методом негарантированной доставки), так что пакеты (ячейки) не будут
отбрасываться внутри ATM-сети в результате применения ATM QoS. На рис. 8.7 изо-
бражены два сценария межсетевого взаимодействия IP-ATM QoS.
Принятие решения об использовании одного канала PVC или PVC-связки для
межсетевого обмена IP QoS зависит от цены и важности трафика в сети. Несмотря на
то что PVC-связка может быть дороже одного канала PVC, она способна изолировать
критические классы трафика (например, голосовой трафик). С другой стороны, для
PVC-связки необходимо предварительно спланировать передачу трафика с тем, чтобы
все PVC-каналы связки использовались оптимально. Иначе может возникнуть ситуа-
ция, когда PVC-канал связки, по которому передается высокоприоритетный трафик,
210
Часть II. Качество обслуживания канального уровня и сети MPLS...
окажется перегруженным, а PVC-канал, по которому передается менее приоритетный
трафик, останется относительно свободным. Отметьте, что в случае перегрузки PVC-
канала нельзя автоматически перебросить его высокоприоритетный трафик на другой
PVC-канал этой же связки. При использовании одного PVC можно применить меха-
низм CBWFQ с приоритетной очередью, обеспечивая таким образом первенство голо-
сового трафика среди других типов данных, передаваемых по этому PVC. Более под-
робно механизм CBWFQ с приоритетной очередью обсуждается в главе 4, “РНВ-
политика: распределение ресурсов (часть 1)”.
□□□□
Несколько PVC-каналоа
ATM (по одному на каждый
класс IP-трафика) с различ-
ными услугами ATM QoS
Облако ATM
Механизмы
WRED и WFQ
для каждого
PVC-канала
Один канал
ABR PVC
для всех
классов трафика
Рис. 8.7. Межсетевое взаимодействие IP-ATM QoS
Практический пример 8.3: дифференцированное
отбрасывание IP-пакетов на границе АТМ-сети
Предположим, что инженер, обслуживающий магистраль поставщика услуг
Internet, реализовал в IP-сети дифференцированные услуги, предполагающие наличие
трех классов: “золотого”, “серебряного” и “бронзового”. Входящий трафик сети рас-
пределяется по трем классам обслуживания на основе значения IP-приоритета
(табл. 8.1). На определенной части магистрали в качестве основной транспортной тех-
нологии используется ATM. Инженеру необходимо применить два механизма IP QoS
на входе в ATM-сеть — механизм WFQ для выделения полосы пропускания каждому
классу услуг и механизм WRED для того, чтобы любое отбрасывание пакетов было
основано на значении IP-приоритета пакета.
Таблица 8.1. Классы услуг на основе IP-приоритета ; Управляющий Золотой Серебряный •] Бронзовый
Обычный трафик Приоритет? Приоритет5 Приоритет3 Чрезмерный трафик Приоритете Приоритет 4 Приоритет 2 Приоритет 1 Приоритет 0
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 211
PVC-канал должен обеспечивать передачу данных без потерь, так как отбрасыва-
ние ячеек в ATM-сети производится независимо от значения IP-приоритета. Таким
образом, ATM-сеть функционирует как механизм передачи данных без потерь физи-
ческого уровня и при этом обеспечивает требуемые IP-трафиком услуги.
Прежде всего для каждого класса услуг определяются классы трафика и политики.
Заданная политика применяется к входному интерфейсу ATM-сети. В листинге 8.6
приведен пример соответствующей конфигурации маршрутизатора.
Листинг 8.6. Конфигурация межсетевого обмена IP-ATM QoS
interface АТМО/О/О.1 point-to-point
ip address 200.200.200.1 255.255.255.252
pvc 0/101
abr 10000 1000
encapsulation aalSnlpid
service-policy output atmpolicy
class-map control
match precedence 7
match precedence 6
class-map gold
match precedence 5
match precedence 4
class-map silver
match precedence 3
match precedence 2
class-map bronze
match precedence 1
match precedence 0
policy-map atmpolicy
class control
bandwidth 10000
random-detect
class gold
bandwidth 40000
random-detect
class silver
bandwidth 30000
random-detect
class bronze
bandwidth 20000
random-detect
212
Часть II. Качество обслуживания канального уровня и сети MPLS...
Обратите внимание, что в конфигурации используется модульный интерфейс ко-
мандной строки QoS (command-line interface — CLI), который рассматривается более
подробно в приложении А, “Модульный интерфейс командной строки Cisco QoS”,
далее в этой книге.
В конфигурации, приведенной в листинге 8.6, определяются три карты класса —
“золотая”, “серебряная” и “бронзовая” — для дифференцирования трафика данных,
основываясь на его приоритете. Четвертый класс — класс управления — был опреде-
лен для всего управляющего трафика сети, который может передавать IP-пакеты с
приоритетом 6 и 7.
После классификации трафика определяется карта политики atmpolicy, в которой
оговаривается полоса пропускания и необходимость применения политики WRED для
каждого из четырех классов трафика. Например, для “золотого” класса резервируется
полоса пропускания 40 Мбайт/с и применяется политика отбрасывания пакетов
WRED. Наконец, с помощью команды service-policy политика atmpolicy применяется к
соответствующему субинтерфейсу ATM. Выполнив команду show policy-map, можно
просмотреть информацию о заданной карте политики. Информация о политике
atmpolicy показана в листинге 8.7.
Листинг 8.7. Информация о политике atmpolicy
Routerfshow policy-шар atmpolicy
Policy Map atmpolicy
Weighted Fair Queueing
Class control
Bandwidth 20000 (kbps)
exponential weight 9
class min-threshold max-threshold mark-probability
0 - - 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 128 512 1/10
7 256 512 1/10
rsvp - - 1/10
Class gold
Bandwidth 10000 (kbps)
exponential weight 9
class min-threshold max-threshold
mark-probability
0
1
2
3
4 128 512
1/10
1/10
1/10
1/10
1/10
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 213
5 256 512 1/10
6 - 1/10
7 - 1/10
rsvp - 1/10
Class silver
Bandwidth 30000 (kbps)
exponential weight 9
class min-threshold max-threshold mark-probability
0 - 1/10
1 - 1/10
2 128 512 1/10
3 256 512 1/10
4 - 1/10
5 - 1/10
6 - 1/10
7 - 1/10
rsvp - 1/10
Class bronze
Bandwidth 20000 (kbps)
exponential weight 9
class min-threshold max-threshold mark-probability
0 128 512 1/10
1 256 512 1/10
2 - 1/10
3 - 1/10
4 - 1/10
5 - 1/10
6 - 1/10
7 - 1/10
rsvp - 1/10 '
Практический пример 8.4: дифференцированное
обслуживание
Как и в практическом примере 8.3, поставщику услуг необходимо реализовать
дифференцированное обслуживание, основанное на IP-приоритете пакетов, опреде-
лив три класса услуг — “золотой”, “серебряный” и “бронзовый”. Входящий трафик
сети распределяется по трем классам на основе значения IP-приоритета (см.
табл. 8.1). На определенной части магистрали в качестве основной транспортной
технологии используется ATM, и сетевому инженеру необходимо установить соот-
ветствие между трафиком с тремя уровнями приоритета и различными виртуальны-
ми каналами ATM.
PVC-связка (с несколькими PVC-каналами) используется для передачи трафика в
Лондон — конечную точку назначения PVC-канала. В листинге 8.8 показан пример
конфигурации PVC-связки для обеспечения дифференцированных услуг на основе
IP-приоритета в АТМ-сети.
214
Часть II. Качество обслуживания канального уровня и сети MPLS...
j Листинг 8.8. Конфигурация PVC-связки.. V. ’
interface atmO/O.l multipoint
ip address 222.21.123.1 255.255.255.252
bundle london
oam-bundle manage 5
encapsulation aal5snap
protocol ip 192.1.103.20 broadcast
pvc-bundle control 1/107
vbr-nrt 4000 2000 200
precedence 6-7
protect vc
random-detect
pvc-bundle gold 1/105
vbr-nrt 2000 1000 100
precedence 4-5
protect group
random-detect
pvc-bundle silver 1/103
vbr-nrt 1000 500 50
precedence 2-3
random-detect
protect group
pvc-bundle bronze 1/102
ubr
precedence 0-1
random-detect
protect group
Вначале определяется PVC-связка london. После этого определяются входящие в
нее PVC-каналы — “управляющий”, “золотой”, “серебряный” и “бронзовый”. Каж-
дый PVC-канал соответствует определенному классу услуги ATM в зависимости от IP-
трафика, который по нему передается. Например, “серебряный” канал связки отвеча-
ет за передачу трафика с лучшим уровнем обслуживания, чем “бронзовый” PVC, по
которому передается трафик методом негарантированной доставки.
Компонент PVC-связки control определен как защищенный виртуальный канал,
поскольку управляющий PVC-канал очень важен для всей PVC-связки и необходим
для ее корректной работы. В связи с этим если управляющий PVC-канал выходит из
строя, прекращает функционировать вся связка.
Компоненты связки “золотой”, “серебряный” и “бронзовый” формируют так на-
зываемую защищенную группу. Для прекращения функционирования защищенной
PVC-связки необходимо, чтобы перестали функционировать все ее компоненты. Если
VC-канал защищенной группы отключается, его трафик “перебрасывается” на вирту-
альный канал с меньшим приоритетом.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 215
Практический пример 8.5: установка CLP-бита на основе
IP-приоритета
Сетевому администратору, ответственному за реализацию в IP-сети компании
дифференцированных услуг, основанных на IP-приоритете, необходимо отобразить
IP-приоритет на CLP-бит. Так как напрямую это сделать невозможно, сетевой адми-
нистратор хочет установить CLP-бит (присвоить ему значение 1) для IP-пакетов с
приоритетом 0. Таким образом, в случае возникновения перегрузки в АТМ-сети тра-
фик, передаваемый методом негарантированной доставки (IP-приоритет 0), будет от-
брасываться перед более высокоприоритетным трафиком. В листинге 8.9 приведена
необходимая для этого конфигурация маршрутизатора.
Листинг 8.9. Конфигурация, предусматривающая установку CLP-бита для j
трафика, передаваемого методом негарантированной дос-
тавки ‘ '' 5? " ч ’ 1
class-map best-effort
match ip precedence 0
policy-map lossok
class best-effort
set atm-clp 1
interface atm0/0/0.1 point-to-point
service-policy output lossok
Вначале IP-трафик с приоритетом 0 классифицируется как трафик, передаваемый
методом негарантированной доставки. Затем определяется политика lossok, которая
соответствует трафику, передаваемому методом негарантированной доставки, и указы-
вает на необходимость установки значения CLP-бита, равного 1. И наконец, политика
lossok применяется к ATM-интерфейсу маршрутизатора.
Frame Relay
Frame Relay — популярная технология передачи пакетов в глобальных сетях, от-
лично подходящая для передачи данных. Frame Relay — это простой протокол, в ко-
тором не предусмотрено управление потоком на канальном уровне и нет функций
коррекции ошибок внутри Frame Relay-сети. Все эти функции должны выполнять
приложения конечных станций. Как уже говорилось, этот протокол лучше всего под-
ходит для передачи данных, поскольку он может переносить внезапные всплески.
Работа протокола Frame Relay основана на использовании виртуальных каналов (VC).
VC-канал предоставляет логическое соединение между двумя конечными точками сети
Frame Relay. В сети VC-канал Frame Relay можно использовать вместо частной выделен-
ной линии. Во Frame Relay сети можно использовать как постоянные виртуальные каналы
(PVC), так и коммутируемые виртуальные каналы (SVC). PVC-канал устанавливается сете-
вым оператором на станции управления сетью, в то время как SVC-канал устанавливается
динамически при каждом вызове. Наиболее часто в сети Frame Relay используются каналы
PVC, поддержка же каналов SVC была введена относительно недавно.
216 Часть II. Качество обслуживания канального уровня и сети MPLS...
Для отправки во Frame Relay-сеть пользовательский кадр вставляется в заголовок
Frame Relay. Этот заголовок показан на рис. 8.8.
DLCI — идентификатор соединения канального уровня (Data-Link Connection Identifier)
C/R — бит поля команды и ответе (зависит от приложения и не изменяется сетью) (Command/Response)
FECN — прямое явное уведомление о перегрузке (Forward Explicit Congestion Notification)
BECN — обратное явное уведомление о перегрузке (Beckward Explicit Congestion Notification)
DE — индикатор пакете, пригодного для отбрасывания (Discard Eligible)
ЕА — бит расширения (позволяет указать на 3- или 4-байтовый заголовок) (Extension bit)
Рис. 8.8. Пример заголовка Frame Relay
10-битовый идентификатор соединения канального уровня (data-link connection
identifier — DLCI) является номером VC-канала Frame Relay, соответствующего логи-
ческому соединению во Frame Relay-сети. Идентификатор DLCI имеет только ло-
кальную значимость. Коммутатор Frame Relay оперирует таблицами отображения VC-
каналов для коммутации кадра в конечную точку назначения DLCI.
Бит расширения адреса (Address Extension — АЕ) указывает на 3- или 4-байтовый
заголовок. Он не поддерживается текущей реализацией протокола Frame Relay на
платформе Cisco. Бит C/R (Command and Respond — команда и ответ) не использует-
ся в протоколе Frame Relay и передается из конца в конец без изменений.
Контрольная последовательность кадра (Frame Check Sequence — FCS) исполь-
зуется для проверки целостности кадра коммутатором Frame Relay-сети и конеч-
ной станцией. Кадр, не прошедший FCS-тест, отбрасывается. Во Frame Relay-
сети не производится никакого исправления ошибок. Повторная отправка кадра
после обнаружения его потери возлагается на более высокоуровневые протоколы
конечных станций.
Механизм предотвращения перегрузки в сети Frame Relay
В сети Frame Relay механизм предотвращения перегрузки обеспечивают три бита
Frame Relay-заголовка. Это биты прямого явного уведомления о перегрузке (Forward Ex-
plicit Congestion Notification — FECN), обратного явного уведомления о перегрузке
(Backward Explicit Congestion Notification — BECN) и DE-бит (Discard Eglible — кадр,
пригодный для отбрасывания).
Вы можете установить в коммутаторе значение FECN-бита, равное 1, для того что-
бы сообщить конечному терминальному оборудованию (data terminal equipment —
DTE), например маршрутизатору, что на пути передачи кадра от источника до конеч-
ной точки произошла перегрузка сети.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 217
Значение BECN-бита устанавливается коммутатором в 1, для того чтобы сооб-
щить маршрутизатору пункта назначения, что в сети произошла перегрузка по
направлению, обратному к направлению передачи кадра от источника до пункта
назначения.
Основное преимущество использования FECN-бита и BECN-бита заключается в
предоставлении возможности протоколам более высокого уровня разумно реагировать
на сообщения о перегрузке сети (рис. 8.9).
Рис. 8.9. Использование FECN-бита и BECN-бита
DE-бит устанавливается маршрутизатором или другим DTE-устройством для того,
чтобы указать, что отмеченный кадр менее важен по сравнению с другими передавае-
мыми кадрами. Таким образом обеспечивается базовый механизм назначения приори-
тетов в Frame Relay-сетях. Кадры с установленным DE-битом отбрасываются в пер-
вую очередь, т.е. перед кадрами, в которых этот флаг не установлен.
Механизм выравнивания трафика
в сети Frame Relay (FRTS)
Механизм FRTS (Frame Relay Traffic Shaping) выравнивает трафик, исходящий из
VC-канала, в соответствии со сконфигурированной скоростью передачи информации.
FRTS пытается сгладить пульсирующий трафик, буферизируя пакеты, превысившие
среднюю интенсивность. Помещенные в буфер пакеты изымаются из очереди для пе-
редачи, после того как механизм обслуживания очередей сочтет освободившийся
объем ресурсов достаточным. Алгоритм обслуживания очередей может быть сконфи-
гурирован на каждом канале VC только для исходящего трафика интерфейса.
FRTS может выравнивать трафик до пиковой скорости — согласованной скорости
передачи информации (Committed Information Rate — CIR) или какой-либо другой
величины, например избыточной скорости передачи информации (Excess Information
Rate — EIR), — на каждом VC-канале.
Механизм FRTS, работающий в адаптивном режиме, позволяет уменьшить интен-
сивность исходящего трафика VC-канала Frame Relay, основываясь на полученных се-
тевых индикаторах перегрузки BECN. Он выравнивает интенсивность трафика, пере-
даваемого через PVC-канал, в зависимости от доступной полосы пропускания Frame
Relay-сети. Таким образом, интенсивность трафика может составлять X, однако когда
сеть начнет посылать BECN-индикаторы, она будет уменьшена до Y.
218
Часть II. Качество обслуживания канального уровня и сети MPLS...
Выравнивание VC-трафика
Корзина маркеров, похожая на ту, использование которой для выравнивания
трафика описано в главе 3, “Формирование трафика на границе сети:
классификация пакетов, маркировка пакетов и управление интенсивностью
трафика”, служит дескриптором трафика, позволяющим проводить его дозирова-
ние. Договорную среднюю интенсивность обычно называют согласованной
скоростью передачи информации (Committed Information Rate — CIR). Размер
всплеска (Вс) — это количество данных, добавляемых в корзину маркеров
размером Вс + ВЕ на каждом интервале времени Тс. Интервал Тс определяется
как Bc/CIR. Расширенный размер всплеска (ВЕ) — это объем чрезмерного
всплеска данных, которые разрешено отправить в течение первого интервала вре-
мени после заполнения корзины маркеров. Когда приходит новый пакет, он
ставится в очередь на отправку, которая обслуживается таким планировщиком,
как WFQ или FIFO (first-in, first-out — “первым пришел, первым обслужен”).
Пакет, предназначенный для передачи, отправляется только в том случае, если в
корзине имеется достаточно маркеров. После того как пакет будет отправлен, из
корзины изымается эквивалентное размеру пакета число маркеров.
Если в течение интервала Тс было передано менее Вс байт, можно
“перебросить” неиспользованные байты на следующий интервал времени. Таким
образом, если в течение интервала Тс было передано менее Вс байт трафика, чис-
ло байтов, которые могут быть переданы за следующий интервал времени, может
достичь верхней границы Вс + ВЕ.
Если произошла серьезная перегрузка и корзина маркеров полна, вы можете
отправить ВЕ+ВС байт в течение первого интервала времени и Вс байт за каждый
последующий интервал до тех пор, пока перегрузка сети не пойдет на убыль. Та-
ким образом, во время перегрузки сети скорость передачи трафика может быть
уменьшена до CIR.
Взаимоотношение между параметрами механизма выравнивания трафика показано
на рис. 8.10.
Несмотря на уменьшение скорости передачи до CIR во время перегрузки сети,
механизм выравнивания трафика Frame Relay допускает возникновение случай-
ных всплесков, превышающих CIR, на канале PVC. Канал PVC также может быть
сконфигурирован таким образом, чтобы скорость передачи данных была равна
CIR (ВЕ = 0).
Адаптивный механизм FRTS
В течение каждого временного интервала Тс процесс проверяет, получено ли от
сети Frame Relay уведомление BECN. Если уведомление BECN было получено в те-
чение последнего Тс-интервала, скорость передачи уменьшается на 25% по сравнению
с текущей скоростью. Сброс скорости может продолжаться до тех пор, пока не будет
достигнута нижняя граница CIR (MINCIR). Вне зависимости от загрузки Frame
Relay-сети, маршрутизатор не будет сбрасывать скорость ниже значения MINCIR.
Значение MINCIR по умолчанию равно половине значения CIR.
После адаптации скорости передачи трафика к перегрузке во Frame Relay-сети
механизм выравнивания трафика ждет 16 Тс-интервалов без уведомлений BECN и
начинает увеличивать скорость передачи трафика до сконфигурированной скоро-
сти CIR.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 219
м
CIR
CIR
CIR
с помощью
бита DE
с помощью
бита DE
Рис. 8.10. Взаимоотношение между параметрами механизма выравнивания трафика
Интеграция FECN/BECN
Приложения, работающие по протоколу UDP или IP, могут передавать трафик
только в одном направлении, так как в обоих протоколах (UDP и IP) не используется
схема подтверждения доставки. Если применить механизм выравнивания UDP-
трафика, то единственное уведомление о перегрузке сети будет заключаться в уста-
новке FECN-бита, получаемого вместе с кадрами, приходящими в конечный маршру-
тизатор. Маршрутизатор, передающий весь этот трафик, не сможет получить ни од-
ного сообщения BECN, поскольку обратного трафика попросту нет. Интеграция
FECN/BECN реализуется в виде команды на отправку тестового кадра Q.922 с уста-
новленным BECN-битом в ответ на получение кадра с установленным FECN-битом.
Обратите внимание, что в BECN-кадре, который отправляется в ответ на полученное
уведомление FECN, должен быть сброшен DE-бит. Несмотря на то что при получе-
нии маршрутизатором-источником тестового кадра последний сразу же отбрасывает-
ся, BECN-бит указывает на необходимость уменьшения интенсивности трафика. Что-
бы реализовать такую интеграцию, во входящих и исходящих портах должны быть
сконфигурированы команды выравнивания трафика.
Примечание
В случае одностороннего трафика на маршрутизаторе-источнике необходимо приме-
нить команду traffic-shape adaptive. Команда traffic-shape fecn-adapt используется
220
Часть II. Качество обслуживания канального уровня и сети MPLS...
для отправки тестового кадра Q.9224 с установленным BECN-битом в ответ на полу-
чение уведомления FECN.
Фрагментация в сетях Frame Relay
Большие пакеты, поставленные в выходную очередь канала PVC маршрутизатора
перед маленькими, чувствительными к задержкам пакетами, способствуют увеличе-
нию задержки и дрожания маленьких пакетов. Это происходит из-за того, что задерж-
ка при передаче больших пакетов обычно больше задержки при передаче маленьких
пакетов. Более подробно задержка при передаче рассматривалась в главе 1, “Введение
в качество обслуживания в сетях IP”. Разбивая при постановке в очередь на передачу
большие кадры с данными на более мелкие кадры и вставляя между ними маленькие,
чувствительные к задержкам пакеты с последующей сборкой кадра в конечной точке,
мы тем самым облегчаем жизнь маленьким пакетам. Форум Frame Relay (Frame Relay
Forum — FRF)5 одобрил новый стандарт фрагментации Frame Relay FRF. 12.
Стандарт FRF. 12 гарантирует, что голосовые пакеты и другие подобные им небольшие
пакеты данных не будут задерживаться из-за передачи больших пакетов. В этом стандарте
также предусмотрена гарантированная равномерная отправка маленьких пакетов, призван-
ная уменьшить дрожание трафика. Такая возможность очень важна для пользователя, по-
скольку позволяет ему передавать по одному PVC-каналу голосовой трафик и трафик
других приложений, таких, как ERP-приложения (Enterprise Resource Planning — планиро-
вание ресурсов предприятий); приложения, необходимые для решения критически важных
задач; приложения, не чувствительные к задержкам, и пр.
Этот же стандарт применим к UNI-интерфейсам (между маршрутизатором или
устройством доступа Frame Relay (Frame Relay Access Device — FRAD) и облаком
Frame Relay), NNI-интерфейсам (между коммутаторами внутри облака Frame Relay), a
также между маршрутизаторами (или устройствами FRAD) при сквозной передаче
данных, когда фрагментация проходит незаметно для Frame Relay-облака.
В связи с тем, что фрагментация наиболее полезна на медленных линиях, а низкоско-
ростные каналы часто являются каналами доступа к устройству FRAD или маршрутизато-
ру, UNI-фрагментация используется достаточно широко. UNI-фрагментация является ло-
кальной для маршрутизатора; вы можете оптимизировать сетевой интерфейс и подобрать
размер фрагментов, исходя из скорости DTE-устройства.
NNI-фрагментация и сквозная фрагментация используются редко. Применение
фрагментации на высокоскоростных магистралях облака Frame Relay не очень хоро-
шая идея, так как по таким каналам могут передаваться относительно большие кадры
(по сравнению с низкоскоростными каналами доступа) без существенных задержек
для голосовых пакетов. Несоответствие скоростей между двумя конечными FRAD-
системами также может помешать сквозной фрагментации между DTE-устройствами,
для реализации которой может быть использована UNI-фрагментация. Для конечных
DTE-устройств, не проводящих сквозную фрагментацию, UNI-фрагментация позво-
ляет использовать сеть как прокси-систему DTE-устройства.
Важным практическим применением стандарта FRF.12 является передача голосо-
вой информации через сеть Frame Relay с качеством обслуживания междугородной
4 ISDN Data Link Layer Specification for Frame Mode Bearer Services/lntemational Telegraph and Telephone
Consultative Committee, CCTTTRecomendation Q.922, 19 April 1991.
5 Frame Relay Forum (FRF), www.frforum.com
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 221
телефонной связи. Фрагментация, особенно если она используется вместе с механиз-
мами QoS, такими, как WFQ и WRED, гарантирует последовательную непрерывную
передачу голосовой информации.
До реализации стандарта FRF.12 единственным способом разбить кадры в 1Р-среде
была установка маленького значения MTU (maximum transmission unit — максималь-
ного размера единицы передачи информации). Однако этот способ оказался весьма
неэффективным из-за повышения загруженности процессора и увеличения числа па-
кетов. Кроме того, стандарт FRF.12 работает “под” 3-м уровнем эталонной модели
OSI (Open System Interconnection — взаимодействие открытых систем), а поэтому с
его помощью можно фрагментировать не только IP-кадры, но и другие кадры. В слу-
чае передачи голоса по сети IP (Voice over IP — VoIP) фрагментация пакетов стано-
вится абсолютной необходимостью в сетях с небольшой пропускной способностью.
В дополнение к фрагментации FRF.12 устройства Cisco поддерживают фрагмента-
цию FRF. 11 Annex С и собственную фрагментацию. Фрагментация Frame Relay явля-
ется частью механизма выравнивания трафика устройств Cisco. На рис. 8.11 показан
пример фрагментации Frame Relay при передаче голосового трафика и трафика дан-
ных по каналу PVC.
Маршрутизатор
Коммутатор
Рис. 8.11. Фрагментация Frame Relay
iHlBBHIMI
Активизация механизма FRTS является необходимым условием при переходе к
фрагментации FRF.12. При выравнивании голосового трафика FRTS использует
взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing —
WFQ) на основе потока с приоритетной очередью (priority queue — PQ). Каждый
PVC-канал Frame Relay имеет свою собственную структуру PQ-WFQ, которая исполь-
зуется для планирования обслуживания пакетов на основе значения IP-приоритета
согласно алгоритму WFQ на основе потока, который обсуждался более подробно в
главе 4, “РНВ-политика: распределение ресурсов (часть 1)”. На уровне интерфейса
механизм FRTS использует две FIFO-очереди: одну для приоритетных пакетов
(голосовой трафик, LMI-трафик (Local Management Interface — интерфейс локального
управления) и пр.), другую — для остального трафика. Обратите внимание, что меха-
низм FRTS запрещает на интерфейсном уровне любой другой метод обслуживания
очередей, кроме двойного FIFO.
На рис. 8.12 изображены три различных потока — два потока данных и один поток
голосового трафика, — которые поступают на интерфейс для их последующей переда-
чи. Потоки маршрутизируются к соответствующим структурам PVC-канала на основе
информации в заголовке пакета. В нашем случае потоки 1 и 2 относятся к каналу
PVC 1, а поток 3 — к каналу PVC 2. Каждому каналу PVC соответствует своя очередь
выравнивания трафика. Так, на канале PVC 1 сконфигурирован механизм PQ-WFQ,
предусматривающий первоочередное обслуживание пакетов голосового потока с по-
мощью приоритетной FIFO-очереди интерфейса. Пакеты с данными, обслуживаемые
посредством очереди с выравниванием трафика, разбиваются на фрагменты в зависи-
222
Часть II. Качество обслуживания канального уровня и сети MPLS...
мости от установленного порогового значения и помещаются в обычную FIFO-
очередь интерфейса. Пороговое значение размера фрагмента должно быть установле-
но таким образом, чтобы ни один голосовой пакет не был фрагментирован. Несмотря
на то что для каждого канала PVC существует отдельная очередь выравнивания тра-
фика, все каналы PVC используют двойную FIFO-очередь интерфейса. Пакеты извле-
каются из приоритетной FIFO-очереди в соответствии со строгим приоритетом по
сравнению с пакетами обычной FIFO-очереди интерфейса.
Большой
пакет с
данными
(PVC1)
I
t t
Маленький Большой
VoIP-пакет пакет с
(PVC 1) данными
(PVC 2)
Структура организации очередей маршрутизатора
пакетов с данными
Frame
Relay
Рис. 8.12. Концептуальный взгляд на работу механизма FRF. 12 с несколькими каналами PVC
и
Межсетевой обмен Frame Relay и IP QoS
Межсетевое взаимодействие IP-Frame Relay QoS, как и межсетевое взаимодег
ствие IP-ATM QoS, необходимо для обеспечения сквозного качества обслужи!
ния в сетях IP. На входе в сеть Frame Relay очереди IP-трафика организуются д.1.1
каждого виртуального канала (VC) Frame Relay. Для каждой VC-очереди можно
применить алгоритмы WFQ и WRED. В дополнение к WFQ, в качестве механизма
обслуживания VC-очереди можно выбрать механизм PQ-WFQ, механизм с при-
оритетной схемой обслуживания и механизм с заказной схемой обслуживания.
Как упоминалось ранее, для обеспечения базовой дифференциации трафика в
технологии Frame Relay используется бит DE. Вероятность отбрасывания кадра с
установленным флагом DE больше, чем вероятность отбрасывания кадра со зна-
чением DE-бита, равным 0.
В связи с тем, что в протоколе IP для определения приоритета используется три би-
та, напрямую отобразить DE-бит на уровни IP-приоритета нельзя. Тем не менее можно
воспользоваться довольно простым отображением, а именно —поставить в соответствие
IP-трафику, передаваемому методом негарантированной доставки (IP-приоритет 0), ус-
тановленный DE-бит, а другому, более важному трафику — сброшенный DE-бит. Таким
образом, трафик, передаваемый методом негарантированной доставки, будет отбрасы-
ваться раньше, чем более важный трафик.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 223
Практический пример 8.6: выравнивание трафика Frame
Relay с использованием функции автораспознавания QoS
Предположим, что сетевому администратору общенациональной сети необхо-
димо сконфигурировать механизм выравнивания трафика на маршрутизаторах,
подключенных к сети Frame Relay, в соответствии с обусловленным QoS-
контрактом (CIR, Вс, ВЕ). Вместо явной конфигурации администратору необхо-
димо воспользоваться расширенным интерфейсом LMI, для того чтобы маршру-
тизаторы получали QoS-информацию напрямую от подключенного коммутатора
сети Frame Relay для каждого VC-канала.
С целью использования функции автораспознавания QoS расширенный интерфейс
LMI должен быть сконфигурирован как на маршрутизаторе, так и на подключенном к
нему коммутаторе. Маршрутизатор будет динамически получать от коммутатора QoS-
информацию для каждого VC-канала.
Основываясь на полученной информации QoS (CIR, Вс, ВЕ), маршрутизатор вы-
равнивает трафик VC-канала.
В листинге 8.10 показан пример конфигурации механизма FRTS с функцией авто-
распознавания QoS для маршрутизатора.
Листинг 8.10. Конфигурация механизма FRTS с функцией "
автораспознавания QoS . !
_______ ____ .... ..-....._________------------------- ------------------
interface SerialO/O
encapsulation frame-relay
frame-relay Imi-type ansi
frame-relay traffic-shaping
frame-relay qos-autosense
interface SerialO/O.l point-to-point
ip address 202.12.12.1 255.255.255.252
frame-relay interface-dlci 17 IETF protocol ip 202.12.12.2
Команда frame-relay qos-autosense указывает на необходимость использования рас-
ширенного интерфейса LMI для динамического получения информации QoS для каж-
дого VC-канала интерфейса. Команда frame-relay traffic-shaping выравнивает трафик на
каждом VC-канале, основываясь на полученной информации QoS.
В листингах 8.11 и 8.12 показаны результаты выполнения соответствующих show-
команд. Как показано в листинге 8.11, команда show frame-relay qos-autosense также
выводит на экран значения, полученные от коммутатора. В листинге 8.12 команда
show traffic-shape показывает QoS-параметры и параметры дескриптора трафика.
Листинг 8.11. Информация, полученная в результате использования
функции автораспознавания QoS ।
Routerfshow frame-relay qos-autosense
ELMI information for interface Seriall
Connected to switch:FRSM-4Tl PlatformzAXIS Vendor:cisco
(Time elapsed since last update 00:00:03)
224
Часть II. Качество обслуживания канального уровня и сети MPLS...
DLCI = 17
OUT: CIR 64000 BC 9600 BE 9600 FMIF 4497
IN: CIR 32000 BC 30000 BE 20000 FMIF 4497
Priority 0 (Time elapsed since last update 00:00:03)
i......---------------------------------------------------------
! Листинг 8.12. Параметры механизма выравнивания трафика Frame Relay j
Routerflshow traffic-shape
access Target Byte Sustain Excess Interval
I/F list Rate Limit bits/int bits/int (ms)
Se0/0 64000 2400 9600 9600 150
Значение в столбце Byte Limit — это размер корзины маркеров (размер корзи-
ны = Вс + ВЕ = 9600 + 9600 = 19200 бит = 2400 байт), а значение в столбце Interval — это
Тс-интервал (Тс = Вс CIR = 9600/64000 = 150 мс).
Практический пример 8.7: адаптивный механизм
выравнивания трафика и интеграция BECN/FECN
Предположим, что узел компании, занимающейся электронной коммерцией, под-
ключен к Internet по протоколу Frame Relay на физической скорости Т1. Скорость
доступа, обеспечиваемая поставщиком услуг, равна 256 Кбит/с, а скорость CIR —
64 Кбит/с. Компания желает передавать трафик со скоростью 256 Кбит/с и снижать
ее до значения CIR (64 Кбит/с) при получении уведомлений BECN. Кроме этого, не-
обходимо, чтобы удаленный маршрутизатор поставщика услуг был сконфигурирован с
исходящей скоростью CIR, равной 32 Кбит/с, для отражения всех полученных уве-
домлений FECN с помощью уведомлений BECN, так как большая часть трафика
представляет собой однонаправленный UDP-трафик, передающийся от узла компа-
нии на удаленный маршрутизатор.
В листингах 8.13 и 8.14 показан пример конфигурации интерфейса маршрутизато-
ра компании, подключенного к поставщику услуг, с использованием механизмов
FRTS и DTS, соответственно. Более подробно механизм DTS рассматривается в
главе 3, “Формирование трафика на границе сети: классификация пакетов,
маркировка пакетов и управление интенсивностью трафика”.
Листинг 8.13. Конфигурация механизма FRTS для интерфейса
маршрутизатора, подключенного к поставщику услуг
interface Serial 0/0/0
encapsulation frame-relay
interface Serial0/0/0.1 point-to-point
ip address 202.12.12.1 255.255.255.252
frame-relay interface-dlci 17 IETF protocol ip 202.12.12.2
frame-relay class adaptivefrts
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 225
map-class frame-relay adaptivefrts
frame-relay traffic-shape rate 256000
frame-relay traffic-shape adaptive 64000
Листинг 8.14. Конфигурация механизма DTS для интерфейса !
s маршрутизатора, подключенного к поставщику услуг
interface Serial 0/0/0
encapsulation frame-relay
class-map myclass
match any
policy-map mypolicy
class-map myclass
shape peak 256000 8000 8000
shape adaptive 64000
interface serialO/0/0.1 point-to-point
ip address 202.12.12.1 255.255.255.252
frame-relay interface-dlci 17 IETF protocol ip 202.12.12.1
service-policy output mypolicy
Маршрутизатор узла компании настроен на передачу трафика со скоростью CIR,
равной 256000 бит/с, и динамически изменяет ее при получении уведомлений BECN.
Минимальная скорость CIR при постоянном поступлении сообщений BECN (что оз-
начает перегрузку сети) равна 64 Кбит/с.
В листингах 8.15 и 8.16 показана конфигурация механизмов FRTS и DTS, соответ-
ственно, для маршрутизатора поставщика услуг.
f ’ ’ - ~ .- - - - . - j
Листинг 8.15. Конфигурация механизма FRTS для интерфейса
| маршрутизатора поставщика услуг i
interface Serial 0/0
encapsulation frame-relay
frame-relay traffic-shaping
interface Serial0/0/0.1 point-to-point
ip address 202.12.12.2 255.255.255.252
frame-relay interface-dlci 20 IETF protocol ip 202.12.12.1
frame-relay class BECNforFECN
map-class frame-relay BECNforFECN
frame-relay traffic peak 32000
frame-relay be out 8000
frame-relay be out 8000
226
Часть II. Качество обслуживания канального уровня и сети MPLS...
Листинг 8.16. Конфигурация механизма DTS для интерфейса , * ''л
; маршрутизатора поставщика услуг < !
1__:__l______________________________________________________iLj.__ir-iiii-
interface Serial 0/0
encapsulation frame-relay
class-map myclass
match any
policy-map mypolicy
class-map myclass
shape peak 32000 8000 8000
shape fecn-adapt
interface serial0/0/0.1 point-to-point
ip address 202.12.12.2 255.255.255.252
frame-relay interface-dlci 17 IETF protocol ip 202.12.12.1
service-policy output mypolicy
Так как трафик, исходящий из маршрутизатора компании к удаленному маршру-
тизатору поставщика услуг, является однонаправленным UDP-трафиком, маршрутиза-
тор компании не получает уведомления BECN от маршрутизатора поставщика услуг и
не может соответствующим образом адаптировать механизм выравнивания трафика в
случае перегрузки сети. Следовательно, в ответ на кадр с битом FECN маршрутизатор
поставщика услуг должен сформировать для маршрутизатора компании кадр с уста-
новленным битом BECN для того, чтобы тот мог динамически менять параметры ме-
ханизма выравнивания трафика.
Приведенная выше конфигурация устанавливает скорость передачи CIR, равную
32 Кбит/с, и указывает маршрутизатору отвечать уведомлением BECN на все полу-
ченные уведомления FECN.
Механизм DTS использует модульный интерфейс командной строки QoS, который
рассматривается в приложении А, “Модульный интерфейс командной строки Cisco
QoS”, далее в этой книге.
Практический пример 8.8: использование нескольких
PVC-каналов для передачи различных типов трафика
Представьте себе, что сетевому архитектору узла компании, занимающейся элек-
тронной коммерцией, необходимо использовать несколько каналов PVC для передачи
трафика с разным приоритетом в магистраль поставщика услуг. Сейчас по сети ком-
пании передается IP-трафик четырех уровней приоритета (0-3). Следовательно, ком-
пания арендует четыре PVC-канала для передачи по ним трафика четырех уровней
приоритета. Каждый канал настроен в соответствии с важностью трафика, который по
нему передается.
В листинге 8.17 приведен пример конфигурации маршрутизатора компании.
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 227
Листинг 8.17. Конфигурация, предусматривающая маршрутизацию
, ' f \ трафика в зависимости от его^ипа?^ .?^ t
interface Serial5/0
encapsulation frame-relay
interface Serial 5/0.1 multipoint
frame-relay priority-dlci-group 1 203 202 201 200
frame-relay qos-autosense
access-list 100 permit ip any any precedence routine
access-list 101 permit ip any any precedence priority
access-list 102 permit ip any any precedence immediate
access-list 103 permit ip any any precedence flash
priority-list 1 protocol ip high list 103
priority-list 1 protocol ip medium list 102
priority-list 1 protocol ip normal list 101
priority-list 1 protocol ip low list 100
Четырем сконфигурированным каналам PVC присвоены следующие номера DLCI:
203, 202, 201 и 200. С помощью команды frame-relay priority-dlci-group эти четыре но-
мера ставятся в соответствие трафику с высоким, средним, обычным и низким при-
оритетом. Обратите внимание, что эта команда не активизирует механизм приоритет-
ного обслуживания очереди, она только определяет различные DLCI для передачи
различных классов трафика. Для распределения трафика по четырем классам IP-
приоритета (0-3) используется список приоритетов 1. Высокоприоритетный трафик
передается по высокоприоритетному каналу, среднеприоритетный трафик — по сред-
неприоритетному DLCI и т.д.
В листингах 8.18 и 8.19 показаны результаты выполнения двух важных show-
команд. При выполнении команды show frame-relay pvc (листинг 8.18) на экран выво-
дятся все известные маршрутизатору пары PVC/DLCI и информация о приоритетной
DLCI-группе. Эта же команда показывает статистику пакетов для каждого идентифи-
катора DLCL Команда show queueing priority (листинг 8.19) показывает сконфигуриро-
ванный на маршрутизаторе список приоритетов.
Листинг818Результатвыполнениякоманды show frame-relay pvc ,
Г ' -5 ... ' .° ' ... , '
Routerfshow frame-relay pvc
PVC Statistics for interface Serial5/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 4000
Switched 0000
Unused 0000
DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
input pkts 0
out bytes 0
output pkts 0
dropped pkts 0
in bytes 0
in FECN pkts 0
228
Часть II. Качество обслуживания канального уровня и сети MPLS...
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out beast pkts 0 out beast bytes 0
pvc create time 00:05:31, last time pvc status changed 00:05:31
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
input pkts 0
out bytes 0
in BECN pkts 0
in DE pkts 0
out beast pkts 0
output pkts 0
dropped pkts 0
out FECN pkts 0
out DE pkts 0
out beast bytes 0
in bytes 0
in FECN pkts 0
out BECN pkts 0
pvc create time 00:05:55, last time pvc status changed 00:05:55
DLCI = 202, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
input pkts 0
out bytes 0
in BECN pkts 0
in DE pkts 0
out beast pkts 0
output pkts 0
dropped pkts 0
out FECN pkts 0
out DE pkts 0
out beast bytes 0
in bytes 0
in FECN pkts 0
out BECN pkts 0
pvc create time 00:04:36, last time pvc status changed 00:04:36
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
input pkts 0
out bytes 0
in BECN pkts 0
in DE pkts 0
out beast pkts 0
output pkts 0
dropped pkts 0
out FECN pkts 0
out DE pkts 0
out beast bytes 0
in bytes 0
in FECN pkts 0
out BECN pkts 0
pvc create time 00:04:37, last time pvc status changed 00:04:37
Priority DLCI Group 1, DLCI 203 (HIGH), DLCI 202 (MEDIUM)
DLCI 201 (NORMAL), DLCI 200 (LOW)
! Листинг 8.19. Результат выполнения команды show queueing priority
’ • --г'- ‘ • '
Router#show queueing priority
Current priority queue configuration:
List Queue Args
1 high protocol ip list 103
1 medium protocol ip list 102
1 normal protocol ip list 101
1 low protocol ip list 100
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 229
Практический пример 8.9: конфигурация механизма WFQ
на каждом VC-канале
Предположим, что в сети используются различные QoS-классы трафика, основан-
ные на его приоритете. Сетевому администратору необходимо сделать так, чтобы от-
правка пакетов по каждому VC-каналу Frame Relay планировалась алгоритмом WFQ,
т.е. чтобы класс трафика с высоким IP-приоритетом получал более широкую полосу
пропускания, нежели трафик с низким IP-приоритетом.
В листинге 8.20 показан пример конфигурации маршрутизатора, предусматриваю-
щей использование алгоритма WFQ на каждом VC-канале.
Листинг 8.20. Использование алгоритма WFQ на каждом VC-канале I
interface Serial 0/0/0
encapsulation frame-relay
frame-relay class pervcwfq
interface Serial0/0/0.1 point-to-point
ip address 220.20.20.1 255.255.255.252
frame-relay interface-dlci 17 IETF protocol ip 220.20.20.2
map-class frame-relay pervcwfq
frame-relay fair-queue
Практический пример 8.10: отображение DE-бита Frame
Relay на биты IP-приоритета
Предположим, что одна финансовая компания использует сеть Frame Relay в каче-
стве магистрали для своей общенациональной сети. Компания распределяет трафик
по категориям на границе так, что высокоприоритетный трафик обслуживается в пер-
вую очередь. Трафик распределяется на два класса: трафик с высоким приоритетом и
трафик с низким приоритетом (IP-приоритет 3 и 0, соответственно). Компании необ-
ходимо установить DE-бит для низкоприоритетного трафика с тем, чтобы он, при не-
обходимости, отбрасывался без какого-либо ущерба для приоритетного трафика. На
выходе из сети Frame Relay трафик маркируется обратно с помощью IP-приоритета 3
и 0 в зависимости от состояния DE-бита.
В листинге 8.21 показана конфигурация, предусматривающая установку DE-бита
для пакетов с IP-приоритетом 0.
Листинг 8.21. Пример конфигурации, предусматривающей установку
DE-бита для пакетов с IP-приоритетом О
frame-relay de-list 1 protocol ip list 101
interface serial 1/0/0
encapsulation frame-relay
interface seriall/0/0.1 point-to-point
230
Часть II. Качество обслуживания канального уровня и сети MPLS...
frame-relay interface-dlci 18 broadcast
frame-relay de-group 101 18
access-list 101 permit ip any any precedence routine
Команда de-group определяет класс пакета и DLCI-номер канала, на котором про-
изводится установка DE-бита. Команда de-list определяет класс пакетов, для которых
необходимо установить DE-бит. В данном примере это необходимо сделать для всех
IP-пакетов с приоритетом 0, которые направляются в сеть Frame Relay. Остальной IP-
трафик поступает в сеть Frame Relay без установленного флага DE (DE = 0).
Практический пример 8.11: фрагментация Frame Relay
Предположим, что сетевому администратору IP-сети, построенной на базе протокола
Frame Relay, необходимо обеспечить передачу по сети VoIP-трафика. При этом он желает
гарантировать для VoIP-трафика минимальную задержку и низкий уровень дрожания.
Сетевой администратор знает, что у технологии VoIP есть ограничения по времени
доставки трафика и использует для передачи голосовых данных IP-приоритет 5. Тра-
фику данных назначается IP-приоритет 0-4. Несмотря на то что в сети используется
алгоритм WFQ, часть VoIP-трафика испытывает необычно большие задержки и дро-
жание. Администратор заметил, что средний размер пакета с данными равен
1024 байт, а VoIP-пакета — всего 64 байт. Так как большой размер пакета данных мо-
жет быть причиной задержек VoIP-трафика, необходимо разбить пакеты с данными,
которые превышают определенный размер, так, чтобы у VoIP-трафика были мини-
мальные задержки и низкий уровень дрожания. Кроме этого, для уменьшения задер-
жек и дрожания голосового трафика необходимо применить алгоритм PQ-WFQ.
В листинге 8.22 приведен пример конфигурации механизма фрагментации Frame Relay.
Листинг 8.22. Конфигурация механизма фрагментации Frame Relay ' . 'j
у / , с алгоритмом обслуживания очередей PQ-WFQ - !
interface Serial 1/0
ip address 220.200.200.2 255.255.255.252
encapsulation frame-relay
frame-relay traffic-shaping
ip rtp priority 16384 16383 640
frame-relay interface-dlci 110
class frag
map-class frag
frame-relay cir 64000
frame-relay be 8000
frame-relay fragment 64
frame-relay fair-queue
Команда class frag указывает на необходимость проведения фрагментации и выравни-
вания трафика на интерфейсе Frame Relay. С помощью команды frame-relay fragment опре-
деляется размер фрагмента. В соответствии с конфигурацией любой пакет, размер кото-
рого превышает 64 байт, будет разбит на части. Для активизирования фрагментации необ-
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 231
холимо активизировать механизм выравнивания трафика Frame Relay. В данном случае
параметры механизма выравнивания трафика определяются так: скорость CIR равна
64 Кбит/с, а значение Вс — 8000 байт. Для обслуживания очереди, в которой накаплива-
ются кадры при выравнивании трафика, используется планировщик WFQ. Посредством
команды ip rtp priority указывается необходимость использования приоритетной очереди
механизма WFQ. По умолчанию используется сквозная фрагментация на основе специфи-
кации FRF.12. На маршрутизаторах Cisco также поддерживаются и другие типы фрагмен-
тации. Фрагментация на основе спецификации FRF. 11 Annex С применяется в том случае,
если на интерфейсе Frame Relay используется команда vofr. Фрагментация собственной
разработки Cisco применяется с помощью команды vofr cisco.
Семейство локальных сетей IEEE 802.3
Наиболее часто использующейся технологией локальных сетей (LAN) является
Ethernet. Изначально под технологией Ethernet подразумевалась передача данных на скоро-
сти 10 Мбит/с по методу множественного доступа с контролем несущей и обнаружением
конфликтов (carrier sense media access, collision detect — CSMA/CD). Сегодня термин
Ethernet используется для определения всех расширений оригинальной спецификации Eth-
ernet, в которых продолжается использование метода доступа к среде CSMA/CD.
Технология Ethernet со скоростью передачи 10 Мбит/с стандартизирована как часть
спецификации IEEE 802.3. Так же широко распространена Ethernet Version 2.0, совмести-
мая со спецификацией IEEE 802.3. В высокоскоростных версиях семейства локальных се-
тей Ethernet— Fast Ethernet (lOOBaseT — скорость передачи 100 Мбит/с) и Gigabit
Ethernet — продолжается использование существующей спецификации IEEE 802.3
CSMA/CD или ее расширений. Технологии lOOBaseT и Gigabit Ethernet стандартизированы
как спецификации IEEE 802.3u и 802.3х соответственно. В результате во всем семействе
Ethernet 802.3 сохранился формат кадра IEEE 802.3, его размер и механизм обнаружения
ошибок. Спецификация IEEE 802.3 и формат кадра Ethernet показаны на рис. 8.13.
Длина поля в байтах Ethernet
8 6 6 2 46-1500 4
Преамбула Адрес назначения Адрес источнике Тип Данные FCS
Длина поля в байтах
7 6
IEEE 802.3
6 2
46-1500
Преамбула S О F Адрес назнвчвния Адрес источника Длина Заголовок 802.3 и двнные FCS
SOF — ограничитель начала кадра (Start Of Frame delimiter)
FCS — контрольная последовательность кадра (Frame Check Sequence)
Рис. 8.13. Форматы кадров Ethernet и IEEE 802.3
232
Часть II. Качество обслуживания канального уровня и сети MPLS...
Возможность передачи высокоприоритетного трафика
Возможность передачи высокоприоритетного трафика позволяет проводить диф-
ференциацию передаваемой информации в сетях Ethernet, виртуальных локальных се-
тях (VLAN) и др.
Возможность передачи высокоприоритетного трафика для Ethernet определена
как часть стандарта 802.1р. Для поддержки сетей VLAN используются три бита
4-байтовой метки, определенной стандартом 802.1Q6. 4 байта 802.1Q и биты
802.1р показаны на рис. 8.14.
6
6
2
2
2
Параменная
длина
4
' ^Е#>вгТурвж*ТРЮ^л
‘ Контрольная I ,
информация метки j
Длина/тип МАС
Данныа
PAD
FCS
CFI
Адрас назначания
VID (VLAN ID)-12 бит
Адрас источника
Приоритат
пользователя
Рис. 8.14. Кадр 802.1Q с битами 802.1р
В стандарте 802.1Q определяется новый тип маркированного кадра путем добавле-
ния 4-байтовой метки, состоящей из следующих частей.
• Два байта идентификатора маркированного протокола (Tagged Protocol Identi-
fier - TPID):
• 0x8100 используется для маркировки пакета 802.1Q.
• Два байта маркированной контрольной информации (Tagged Control Informa-
tion — TCI):
• три бита 802. Ip;
• один бит идентификатора канонического формата (Canonical Format
Identifier — CFI);
• 12-битовый идентификатор VLAN (ID).
На рис. 8.15 показано, как оригинальный кадр Ethemet/802.3 преобразуется в мар-
кированный кадр 802.1Q. После введения 4-байтовой метки необходимо пересчитать
контрольную последовательность кадра.
В стандарте 802.1р предусмотрен метод сохранения информации о приоритете при
передаче кадра по локальной сети. Всего существует 8 приоритетов на основе значе-
ния трех битов 802.1р. С целью поддержки стандарта 802.1р канальный уровень дол-
жен поддерживать множественные очереди — по одной на каждый приоритет или
6 Virtual Bridged Local Area Networks. IEEE 802. IQ, grouper.ieee.org/groups/802/l/vlan.html
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 233
класс трафика. Высокоприоритетный трафик всегда предпочтительнее низкоприори-
тетного. Коммутатор сохраняет значения приоритета при коммутации кадра.
Название
Источник
Длина/тип Данные
Начальный
кадр
Название
Источник
TPID TCI Длина/тип Данные
FCS
Приоритет CFI
j__।_1_।_lJ___L.
VLAN-ID
Отмеченный
кадр
(VLAN-ID и CFI являются
частью стандарта 802.1Q,
а нв 602.1р)
Рис. 8.15. Переход от кадра Ethernet к маркированному кадру 802.1Q
Примечание
Совсем несложно отобразить 3-битовое поле IP-приоритета на три бита приоритета
стандарта IEEE 802.1 р и наоборот, обеспечивая таким образом взаимодействие меж-
ду IP QoS и IEEE 802.1р.
В семействе коммутаторов Cisco Catalyst биты класса обслуживания (Class of
Service — COS) 802. Ip используются для дифференциации трафика на основе таких ме-
ханизмов QoS, как WRR (Weighted Round Robin — взвешенный алгоритм кругового об-
служивания) и WRED. Алгоритмы WRR и WRED более детально обсуждаются в главе 5,
“РНВ-политика: распределение ресурсов (часть 2)”, и главе 6, “РНВ-политика:
предотвращение перегрузки и политика отбрасывания пакетов”, соответственно.
Несмотря на то что в стандарте 802.1р используется метка, определенная IEEE 802.1Q —
стандартом для сетей VLAN, — 802.1р можно использовать и при отсутствии виртуаль-
ной локальной сети, как показано на рис. 8.16. Идентификатор VID, равный 0,
зарезервирован и используется для указания на отсутствие VLAN.
Поступающий кадр
VID = 0, приоритет = 5 -►
Комму-
татор
Отсутствие VLAN
Рис. 8.16. Использование стандарта 802.1р при отсутствии VLAN
Из-за дополнительной 4-байтовой метки, добавленной спецификациями 802.1Q и
802.1р, Ethernet-кадр может превысить свой максимальный размер в 1518 байт. Имен-
но поэтому организация IEEE разрабатывает спецификацию 802.Зас (модификацию
стандарта 802.3) с целью увеличить максимальный размер кадра с 1518 до 1522 байт.
Примечание
В спецификации IEEE 802.1 Q, Standard for Virtual Bridged Local Area Network
(Стандарт для виртуально соединенных локальных сетей) определяется метод созда-
ния сетей VLAN.
234
Часть II. Качество обслуживания канального уровня и сети MPLS...
Возможность передачи высокоприоритетного трафика определена как часть стандар-
та 802.1р. Стандарт 802.1 р является частью недавно модифицированной версии
стандарта для прозрачного мостового соединения 802.1 D7. Передача высокоприори-
тетного трафика предполагает разделение его на классы с целью дифференцирован-
ной передачи пользовательских данных на уровне кадра.
Рабочая группа IETF, разрабатывающая интегрированные услуги на специфических
нижних уровнях8 (Integrated Services over Specific Lower Layers— ISSLL), определяет
метод отображения запросов протокола резервирования ресурсов 3-го уровня
(Resource Reservation Protocol — RSVP) на приоритеты 802.1 р посредством диспетче-
ра полосы пропускания подсети (Subnet Bandwidth Manager— SBM). Более подробно
диспетчер SBM рассматривается в следующем разделе этой главы.
Диспетчер SBM
SBM9 — сигнальный протокол, поддерживающий управление доступом на основе
протокола RSVP в семействе сетей Ethernet 802.3. Как упоминалось в главе 7,
“Интегрированные услуги: RSVP”, RSVP — это механизм сквозной сигнализации,
использующийся для запросов резервирования ресурсов сети. В сети Ethernet
гарантированное резервирование полосы пропускания невозможно ни для одной
станции в сегменте, так как Ethemet-сегмент является сетью с разделяемой средой
передачи. Станция Ethemet-сегмента не располагает сведениями о резервировании
ресурсов, произведенном другими станциями, и может отправлять трафик в сегмент
со скоростью, не соответствующей существующему распределению ресурсов. SBM —
это средство для поддержки резервирования ресурсов на основе протокола RSVP в
сетях семейства 802.3.
Ethemet-сегмент с одним или несколькими устройствами, поддерживающими про-
токол SBM, называется управляемым Ethemet-сегментом (managed Ethernet segment).
Управляемый сегмент может быть как общим сегментом с одной или несколькими
SBM-станциями, так и коммутируемым сегментом с максимум двумя SBM-
станциями. В управляемом сегменте одно из устройств с работающим протоколом
SBM играет роль назначенного SBM (designated SBM — DSBM). Станция DSBM может
выбираться динамически или быть сконфигурированной на одной из SBM-станций.
Все остальные SBM-станции управляемого сегмента (кроме станции DSBM) игра-
ют роль DSBM-клиентов. DSBM-станция отвечает за управление доступом для всех
запросов на резервирование ресурсов, отправляемых DSBM-клиентами управляемого
сегмента. Маршрутизаторы Cisco и операционная система Windows NT 5.0 являются
примерами станций, поддерживающих DSBM-функциональность.
Станция с SBM-функциональностью называется SBM-совместимой станцией
(SBM-capable station). SBM-совместимая станция, сконфигурированная для участия в
выборах DSBM, называется станцией-кандидатом DSBM (candidate DSBM station).
7 MAC Bridging. IEEE 802. ID, grouper.ieee.org/groups/8O2/1/mac.html
s Integrated Services over Specific Lower Layers (ISSLL)/IETF Working Group,
www.ietf.org/html.charters/issll-charter.html
9 SBM: A Protocol for RSVP-Based Admission Control over IEEE 802-Style Networks/Ed. Yavatkar et
al., search.ietf.org/intemet-drafts/draft-ietf-issll-is802-sbm-08.txt
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 235
Инициализация
Для обеспечения работы протокола SBM используются два широковещательных адреса.
• AlISBMAddress. Используется для выбора DSBM и передачи всех DSBM-
сообщений. Все SBM-совместимые станции прослушивают этот адрес, а
DSBM-станция отправляет на него свои сообщения.
• DSBMLogicalAddress. Используется для передачи DSBM-клиентами сообщений
RSVP PATH DSBM-станции. Этот адрес прослушивают только станции-
кандидаты DSBM.
После активизации протокола RSVP на SBM-совместимой станции разделяемого
сегмента он регистрирует интерфейс этого сегмента для прослушивания широковеща-
тельного адреса AlISBMAddress. Если станция получила на этот адрес сообщение
I_AM_DSBM, интерфейс считается принадлежащим управляемому сегменту. Прото-
кол RSVP на управляемом сегменте должен работать в соответствии с SBM-
протоколом. DSBM-клиент управляемого сегмента прослушивает сообщения RSVP
PATH, переданные ему через DSBM-станцию по адресу AlISBMAddress.
Станция, сконфигурированная как DSBM-кандидат, помимо адреса AlISBMAddress
прослушивает также адрес DSBMLogicalAddress. DSBM-кандидат отправляет в управ-
ляемый сегмент сообщение DSBM_WILLING. Все сообщения RSVP PATH, исходя-
щие от SBM-клиентов, отправляются по адресу DSBMLogicalAddress. DSBM-станция
не прослушивает сообщения PATH, пришедшие по адресу AlISBMAddress.
SBM-совместимая станция обеспечивает следующие возможности.
• Выбор DSBM. Механизм выбора DSBM-станции в управляемом сегменте.
• Расширения RSVP. Расширения для обработки входящих и исходящих сообще-
ний RSVP PATH и PATH TEAR.
В следующих двух разделах мы обсудим эти функции более подробно.
Выборы DSBM
Новая SBM-станция управляемого сегмента в течение какого-то периода времени
работает в режиме прослушивания, для того чтобы определить, выбран ли DSBM
данного сегмента. Если SBM-станция получает сообщение I_AM_DSBM на адрес
AlISBMAddress, то она не участвует в выборах DSBM, пока существующая DSBM-
станция не выйдет из строя и не станет необходимо провести новые выборы DSBM.
DSBM-станция отправляет сообщение I_AM_1DSBM с интервалом в DSBMRe-
freshinterval секунд. Если DSBM-клиент не получает сообщение I_AM_DSBM по
прошествии интервала в DSBMDeadlnterval (несколько интервалов DSBMRefreshlnter-
val) секунд, он предполагает, что DSBM, вероятно, вышел из строя, и если клиент
сконфигурирован как DSBM-кандидат, он начинает новые выборы DSBM.
Во время выборов DSBM каждая станция, являющаяся DSBM-кандидатом, от-
правляет сообщение DSBM_WILLING по адресу DSBMLogicalAddress, в котором ука-
зывает адрес своего интерфейса и SВМ-приоритет. SBM-приоритет определяет вес
DSBM-кандидата, использующийся при выборе DSBM-станции. Выигрывает стан-
ция-кандидат DSBM с наибольшим приоритетом. Если SBM-приоритет у двух стан-
ций совпадает, сравниваются IP-адреса DSBM-кандидатов. DSBM-кандидат с боль-
шим IP-адресом побеждает.
236
Часть II. Качество обслуживания канального уровня и сети MPLS...
Расширения RSVP
При работе протокола SBM DSBM-станция перехватывает все поступающие и ис-
ходящие сообщения RSVP PATH и RSVP-TEAR, добавляя тем самым один дополни-
тельный переход (hop).
Все исходящие от SBM-клиента управляемого сегмента сообщения RSVP PATH
отправляются DSBM-устройству этого сегмента (по адресу DSBMLogicalAddress), а не
по адресу назначения RSVP-сеанса. После обработки DSBM-станция направляет со-
общение PATH по адресу назначения RSVP-сеанса. Во время обработки DSBM-
станция создает и обновляет блок состояния пути (Path State Block — PSB) сеанса и
сохраняет адрес L2/L3 предыдущего перехода сообщения PATH.
Полученное DSBM-станцией сообщение RSVP PATH требует анализа дополнительных
SBM-объекгов и установки нужной SBM-информации в блоке PSB. Сообщение RSVP
PATH-TEAR используется для удаления установленного блока PSB RSVP-сеанса.
Сообщения RSVP RESV не требуют никаких изменений. SBM-клиент, которому
необходимо сделать резервирование ресурсов после обработки полученного сообще-
ния RSVP PATH, следует стандартным правилам RSVP и отправляет сообщения RSVP
RESV по Е2/ЬЗ-адресу предыдущего перехода (адресу DSBM-станции сегмента) полу-
ченного сообщения PATH, основываясь на информации из PSB-блока сеанса.
DSBM-станция обрабатывает сообщение RSVP RESV SBM-клиента, основываясь
на доступной пропускной способности сети. Если запрос удовлетворить невозможно,
SBM-клиенту, запрашивающему резервирование, отправляется сообщение RSVP
RESVERR. Если запрос можно удовлетворить, сообщение RESV отправляется по ад-
ресу предыдущего перехода полученного сообщения PATH, взятого из PSB-блока се-
анса. Так же, как и в стандартном протоколе RSVP, DSBM, при возможности, объе-
диняет запросы о резервировании.
Резюме
Технология ATM предоставляет богатый набор функций QoS, которые, в свою очередь,
обеспечивают разнообразные услуги. В ATM-сети, по которой передается IP-трафик, ме-
ханизмы отбрасывания ячеек PPD и EPD значительно улучшают пропускную способность
по сравнению с механизмом случайного отбрасывания ячеек. Когда в ATM-сети необхо-
димо отбросить ячейку, механизм PPD может отправить часть пакета (т.е. отбрасываются
не все ячейки), тогда как служба EPD отбрасывает все ячейки пакета.
Для обеспечения сквозных услуг IP QoS через ATM-сеть отбрасывание пакетов и
планирование трафика на входе в ATM-сеть должно производится на основе значения
IP-приоритета пакета. Для этого используются такие механизмы IP QoS, как WFQ и
WRED. Внутри АТМ-облака VC-канал, по которому передается IP-трафик, настраи-
вается таким образом, чтобы обеспечить минимальную потерю IP-трафика и предос-
тавить необходимые при его передаче услуги.
Когда весь трафик до точки назначения передается по одному каналу PVC, функ-
ции IP QoS могут быть сконфигурированы на каждом VC-канале. Что касается PVC-
связки, где точка назначения может быть достигнута посредством нескольких каналов
PVC, существует возможность отобразить IP-приоритет на каждый канал PVC и при-
менить функции IP QoS для каждого виртуального канала связки.
В протоколе Frame Relay предусматривается основанная на CIR функция QoS с
возможностью превышать согласованное качество обслуживания, когда сеть не пере-
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 237
гружена. Протокол Frame Relay также предлагает обширный набор параметров для
контроля за перегрузкой сети. Фрагментация Frame Relay позволяет передавать тра-
фик реального времени по тому же каналу PVC, что и пакеты с данными, которые
имеют относительно большой размер.
В разделяемой или коммутируемой сети Ethernet возможность дифференцирован-
ной обработки трафика основывается на использовании стандарта 802.1р в рамках
кадра 802.1Q. Высокоприоритетный кадр получает больше “прав”, чем низкоприори-
тетный кадр. Резервирование полосы пропускания, основанное на протоколе RSVP, в
Ethernet становится проблематичным, так как сеть этого типа является сетью с разде-
ляемой пропускной способностью. Протокол SBM назначает одну станцию для резер-
вирования полосы пропускания RSVP-типа для всего сегмента Ethernet.
Ответы на часто задаваемые вопросы
Что такое широковещательный адрес, зарезервированный для протокола SBM?
Для своей работы протокол SBM использует два широковещательных адреса. Все
SBM-системы прослушивают адрес 224.0.0.17. Кроме того, все DSBM-кандидаты про-
слушивают адрес 224.0.0.16.
Какие алгоритмы планирования можно применить для обслуживания очереди выравни-
вания трафика механизма FRTS?
Для обслуживания очереди выравнивания трафика механизма FRTS можно ис-
пользовать следующие алгоритмы планирования: приоритетную схему обслуживания
(priority queue — PQ), заказную схему обслуживания (custom queue — CQ), а также
алгоритмы WFQ и CBWFQ. Последние поддерживают использование строгой приори-
тетной очереди. Более детально алгоритмы обслуживания очередей рассматриваются в
главе 4, “РНВ-политика: распределение ресурсов (часть 1)”.
Какая разница между интерфейсной очередью и выравнивающей очередью в аспекте
механизма выравнивания трафика Frame Relay?
При выравнивании трафик, превышающий допустимую интенсивность, ставится в
очередь и передается позднее. В зависимости от требований трафика для обслужива-
ния выравнивающей очереди можно применить любой из алгоритмов планирова-
ния — PQ, CQ, WFQ или PQ-WFQ. Пакеты, предназначенные для извлечения из вы-
равнивающей очереди, ставятся в двойную FIFO-очередь интерфейса. Обратите вни-
мание, что на уровне интерфейса механизм FRTS запрещает использование других
механизмов обслуживания очередей, кроме FIFO. Как уже отмечалось, механизм
FRTS использует двойную очереди FIFO. Пакеты из первой очереди передаются со
строгим приоритетом в отличие от пакетов из второй очереди.
Какая разница между обобщенным механизмом выравнивания трафика (Generic Traffic
Shaping — GTS) и механизмом FRTS?
Различия между механизмами GTS и FRTS показаны в табл. 8.2. Более подробно
механизм GTS обсуждается в главе 3, “Формирование трафика на границе сети:
классификация пакетов, маркировка пакетов и управление интенсивностью трафика”.
238
Часть II. Качество обслуживания канального уровня и сети MPLS...
Таблица 8.2. Сравнена ... • - * - - - - — - - в функций GTS и FRTS J GTS FRTS
Предполагаемое применение Степень детализации Общее для всех интерфейсов Только Frame Relay Работает на уровне интерфейса Работает на уровне PVC-канала Frame Relay или DLCI
Внутренняя выравнивающая очередь Для обслуживания внутренней вы- Для обслуживания внутренней вы- равнивающей очереди используются равнивающей очереди использу- только алгоритмы WFQ и CBWFQ, ются алгоритмы PQ, CQ, WFQ и основанные на потоке. CBWFQ. Алгоритмы WFQ и CBWFQ под- Алгоритмы WFQ и CBWFQ под- держивают строгую приоритетную держивают строгую приоритетную очередь очередь
Фрагментация FRF.12 Интерфейсная очередь Не поддерживается Работает только с механизмом FRTS На интерфейсном уровне подцер- На интерфейсном уровне поддер- живается любой тип обслуживания живается только двойная FIFO- очередей очередь
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен... 239
" > W I t> *1/ к -
В этой главе...
MPLS -Г s
MPLS и ATM r
Качество обслуживания в сетях MPLS ' у
Предоставление сквозных услуг IP QoS <
Виртуальные частные сети (VPN) на основе MPLS
Качество обслуживания в сетях MPLS VPN
241
248
254
255
258
268
Глава
9
Качество обслуживания
в сетях MPLS
Многопротокольная коммутация меток (Multiprotocol Label Switching — MPLS) — это
, стандарт, разработанный рабочей группой по созданию интегрированных услуг (Internet
Engineering Task Force — IETF) для нового типа коммутации, которая позволяет коммути-
ровать пакеты на канальном уровне (уровень 2 модели OSI), используя при этом инфор-
мацию о продвижении данных сетевого уровня (уровень 3 модели OSI). Таким образом, в
протоколе MPLS совмещаются высокоэффективные возможности коммутации канального
уровня и масштабируемость передачи данных сетевого уровня.
На входе в MPLS-сеть информация о приоритете протокола IP может быть либо
скопирована как биты класса" обслуживания (class of service — CoS), либо отображена
на соответствующее значение MPLS CoS в MPLS-метке канального уровня. Внутри
MPLS-сети информация MPLS CoS используется для обеспечения дифференциро-
- ванных услуг. Следовательно, MPLS CoS позволяет предоставлять сквозное качество
услуг IP QoS при передаче данных через MPLS-сеть.
Коммутация пакетов на основе MPLS позволяет поставщику услуг размещать в се-
ти новые службы, в частности виртуальные частные сети (Virtual Private Networks —
VPNs) и службы управления трафиком.
’ В этой главе рассматривается техология MPLS, сети VPN, построенные на базе MPLS,
а также обсуждаются предлагаемые ними функции QoS. Управление трафиком рассматри-
вается в главе 10, “Управление трафиком в сетях MPLS”, далее в этой книге.
MPLS -
MPLS* — это стандарт IETF передачи данных на основе замены меток с использо-
ванием информации о маршрутах. Он состоит из двух принципиальных компонентов:
управляющего и передающего. Управляющий компонент (control component) использует
протокол распространения меток для поддержания информации о продвижении меток
для всех точек назначения MPLS-сети. Передающий компонент (forwarding component)
коммутирует пакеты путем замены метки с использованием информации, передаю-
1 Multiprotocol Label Switching Architecture/Rosen E., Viswanathan A., Callon R. IETF Draft, в ста-
дии разработки.
щейся в пакете, и информации о продвижении меток, поддерживаемой управляющим
компонентом.
Как видно из названия, технология MPLS поддерживает разные протоколы сете-
вого уровня. Поэтому передающий компонент не зависит от какого-то конкретного
протокола. Для того чтобы MPLS можно было использовать с несколькими протоко-
лами сетевого уровня, управляющий компонент должен поддерживать распростране-
ние меток для различных протоколов уровня 3 модели OSI.
Передающий компонент
Продвижение пакетов в сети MPLS осуществляется с помощью метода замены
меток. Когда пакет с меткой попадает в маршрутизатор коммутации меток (Label
Switching Router — LSR), последний использует метку как указатель в своей ин-
формационной базе меток (Label Information Base — LIB). Для полученной метки
в базе LIB содержится точная запись о соответствующей исходящей метке, ин-
терфейсе и информации об инкапсуляции канального уровня, необходимой для
продвижения пакета. Опираясь на информацию из базы LIB, LSR заменяет полу-
ченную метку на исходящую и передает пакет на выходной интерфейс с соответ-
ствующей инкапсуляцией канального уровня.
Пограничный маршрутизатор меток (Label Edge Router — LER) является по-
граничным маршрутизатором MPLS-облака. Некоторые из его интерфейсов уча-
ствуют в продвижении пакетов с использованием MPLS, а некоторые — нет. LER
добавляет MPLS-метку ко всем пакетам, поступающим в MPLS-облако через не
MPLS-интерфейсы. С другой стороны, он удаляет MPLS-метку из пакетов, кото-
рые покидают MPLS-облако. Процесс передачи пакетов в MPLS-сети схематиче-
ски представлен на рис. 9.1.
Представленная схема является упрощением схемы продвижения пакетов обыч-
ного IP-маршрутизатора. Не MPLS-маршрутизатор производит маршрутизацию на
основе адреса пункта назначения с использованием наилучшего совпадения среди за-
писей в таблице маршрутизации. С другой стороны, MPLS-маршрутизатор использует
короткую метку, которая размещается перед заголовком 3-го уровня, и производит
решение о дальнейшей передаче пакета, основываясь на точном совпадении метки с
записью в базе LIB. Таким образом, процедура продвижения пакетов достаточно про-
ста для ее реализации на аппаратном уровне.
Управляющий компонент
Управляющий компонент отвечает за создание привязок меток и их последующее
распространение между LSR-маршрутизаторами.
Привязка метки (label binding) — это связь между меткой и информацией о дости-
жимости конечной точки сетевого уровня или отдельным потоком трафика — в зави-
симости от степени детализации сведений о продвижении данных. С одной стороны,
метка может быть ассоциирована с группой маршрутов, тем самым предоставляя от-
личную масштабируемость протокола MPLS.
242
Часть II. Качество обслуживания канального уровня и сети MPLS...
LER — пограничный маршрутизатор меток (Label Edge Router)
LSR — маршрутизатор коммутации меток (Label Switching Router)
LER на входе
Маршрутизатор на границе
MPLS-сети
1. Классификация пакетов
2. Добавление в пакет MPLS-метки
LSR
1Р-маршрутизатор/
ATM-коммутатор базовой сети
с поддержкой MPLS
1. Передача пакетов на основе
LER на выходе
1. Коммутация пакета после
удаления метки на основе
IP-адреса точки назначения
MPLS-метки канального уровня
2. Предпоследний LER-маршрутизатор
удаляет метку перед передачей
пакета LER-маршрутизатору на
выходе из MPLS-сети
Рис. 9.1. MPLS-сеть
С другой стороны, метка может быть связана с потоком конкретного приложения,
обеспечивая гибкость механизма продвижения пакетов. Функционирование MPLS-
сети схематически показано на рис. 9.2.
Когда метки привязываются к информации о маршруте, MPLS осуществляет пере-
дачу пакетов на основе адреса пункта назначения. Однако передача пакетов на основе
адреса пункта назначения несовместима с более тонкими и гибкими политиками
маршрутизации. В случаях, когда необходимо использовать гибкие политики передачи
информации, привязка метки может основываться не на информации о маршруте.
MPLS обеспечивает гибкие политики передачи пакетов, применяемые на уровне по-
тока или группы потоков. Эту особенность MPLS можно использовать при реализа-
ции механизма управления трафиком (traffic engineering). Управление трафиком обсуж-
дается в главе 10, “Управление трафиком в сетях MPLS”, далее в этой книге.
В следующем разделе описана процедура привязывания меток для обеспечения пе-
редачи пакетов на основе адреса пункта назначения.
Глава 9. Качество обслуживания в сетях MPLS
243
1
2
6
1 — существующие протоколы маршрутизации (например, OSPF или IS-IS) определяют
достижимость сетей назначения
2 — протокол распространения меток (Label Distribution Protocol — LDP) определяет отображение
между меткой и сетью назначения
3 — LSR-маршрутизатор на входе в MPLS-сеть принимает пакет, обеспечивает выполнение
дополнительных служб сетевого уровня и отмечает пакет
4 — LSR-маршрутизатор базовой сети коммутирует пакеты с помощью замены меток
5 — предпоследний LSR-маршрутизатор уделяет метку и отправляет пакет конечному
LER-маршрутизатору
6 — LER-маршрутизатор на выходе из MPLS-сети коммутацирует пакет после удаления метки
на основе IP-едреса точки назначения
Рис. 9.2. Функционирование MPLS-cemu
Привязка меток для обеспечения передачи пакетов на основе
адреса пункта назначения
На сегодняшний день механизм скоростной передачи пакетов Cisco (Cisco Express
Forwarding — CEF) является рекомендуемым механизмом коммутации пакетов для IP-
сетей. Более подробно CEF обсуждается в приложении Б, “Механизмы коммутации
пакетов”. В таблице CEF содержится информация о продвижении пакетов, основан-
ная на сведениях, взятых из таблицы маршрутизации. Исходя из этого данный меха-
низм передает пакеты на основе адреса пункта назначения. MPLS расширяет таблицу
CEF, назначая метку для каждой записи. База LIB используется для привязывания за-
писей таблицы CEF к соответствующим меткам.
MPLS предлагает три метода назначения и распространения меток:
• нисходящее назначение меток;
• нисходящее назначение меток по требованию;
• восходящее назначение меток.
Для всех этих типов размещения меток используется протокол распространения ме-
ток (Label Distribution Protocol — LDP), который распространяет метки среди маршрути-
заторов. Следует обратить внимание, что термины “нисходящий” и “восходящий” ис-
пользуются по отношению к направлению потока данных.
244
Часть II. Качество обслуживания канального уровня и сети MPLS...
Нисходящее назначение меток
Нисходящее назначение меток (downstream label allocation) происходит в обратном
направлении в отношении к потоку данных. Метка, передаваемая в пакете, генериру-
ется и привязывается к префиксу LSR-маршрутизатором в конце канала по направле-
нию потока данных. Таким образом, каждый LSR создает метки для своих непосред-
ственно подключенных префиксов, привязывает их как входящие метки префиксов и
распространяет ассоциацию метки среди всех маршрутизаторов, расположенных выше
по потоку данных. Маршрутизатор, находящийся выше по потоку, заносит получен-
ную привязку в таблицу CEF как исходящую метку префикса и, в свою очередь, соз-
дает для него входящую метку, передавая ее следующему, расположенному выше по
потоку данных маршрутизатору.
В режиме независимого распространения меток каждый расположенный ниже
по потоку маршрутизатор самостоятельно привязывает входящую метку префикса
и распространяет ее как исходящую метку среди всех маршрутизаторов, располо-
женных выше по потоку. В этом случае получение исходящей метки префикса
перед созданием и распространением входящей метки необязательно. Когда у
маршрутизатора есть и входящая, и исходящая метки префикса, он может начать
коммутировать пакеты путем замены меток.
Другой режим распространения меток называется режимом упорядоченного
управления (ordered control mode). В таком режиме перед тем, как отправить свою
метку выше по потоку, маршрутизатор ожидает получения метки от соседа, рас-
положенного ниже по потоку.
Нисходящее назначение меток по требованию
Этот процесс назначения меток похож на нисходящее назначение, однако он ини-
циируется по требованию маршрутизатора, расположенного выше по потоку. Данный
маршрутизатор идентифицирует следующую точку назначения для каждого префикса
из таблицы CEF и отправляет в нее запрос на создание привязки метки для этого
маршрута. Оставшаяся часть процесса назначения метки совпадает с процессом нис-
ходящего назначения меток.
Восходящее назначение меток
Восходящее назначение меток (upstream label allocation) происходит по направле-
нию потока данных. Метка, передаваемая в заголовке пакета данных, генерирует-
ся и привязывается к префиксу LSR-маршрутизатором в конце канала против на-
правления потока данных. Для каждой записи таблицы CEF LSR-маршрутизатора
исходящая метка назначается и распространяется среди маршрутизаторов, распо-
ложенных ниже по потоку, как входящая метка. В этом случае входящие метки
распространяются по префиксам.
Когда у LSR-маршрутизатора есть и входящая, и исходящая метки префикса, он
может начать коммутировать пакеты путем замены меток.
Когда LSR создает привязку исходящей метки к маршруту, коммутатор, помимо
заполнения базы LIB, также обновляет свою таблицу CEF информацией о привязке.
Это позволяет LSR-маршрутизатору добавлять метки к изначально неотмеченным па-
кетам при их создании. В табл. 9.1 приводится сравнение методов нисходящего и вос-
ходящего распространения меток.
Глава 9. Качество обслуживания в сетях MPLS
245
Таблица 9.1. Сравнение нисходящего и восходящего распространения меток
Нисходящее назначение Восходящее назначение
Направление назначения меток Происходит в направлении, про- тивоположном направлению пото- ка данных Происходит в направлении потока данных
Назначение и распространение меток Назначает входящую метку для всех записей в таблице CEF и распространяет исходящую метку среди маршрутизаторов, распо- ложенных выше по потоку Назначает исходящую метку для всех записей в таблице CEF и распространяет входящую метку среди маршрутизаторов, распо- ложенных ниже по потоку
Протокол распространения меток Назначает исходящие метки Назначает входящие метки
Применимость Применим для IP-сетей, постро- енных не на АТМ-технологии Нисходящее назначение меток по требованию и восходящее назна- чение меток наиболее эффектив- ны в сетях ATM
Примечание
Относительно управляющего компонента MPLS следует сделать несколько важных
замечаний.
• Общее число меток, использующихся LSR-маршрутизатором, не превышает число
записей в его таблице CEF. Вообще говоря, в большинстве случаев можно привя-
зать одну метку к группе маршрутов с одинаковой следующей точкой назначения,
поэтому число использующихся меток гораздо меньше, чем число CEF-записей.
Подобным образом можно обеспечить легкомасштабируемые решения.
• Назначение меток зависит от топологической информации, отраженной в таблице
CEF, которая, в свою очередь, основана на информации о маршрутах, а не на те-
кущем трафике данных.
• MPLS не заменяет протоколы маршрутизации IP. Управляющий компонент MPLS
зависит от существования информации о маршрутах в маршрутизаторе, но он не
зависит от того, какой протокол маршрутизации используется в MPLS-сети. Сле-
довательно, в MPLS-сети можно использовать любой протокол маршрутизации
или даже несколько протоколов.
Инкапсуляция меток
Информация метки может передаваться в пакете несколькими способами.
• Как 4-байтовая метка, которая вставляется между заголовками канального и сетевого
уровня. Этот способ подходит для каналов типа “точка-точка” (Point-to-Point —
PPP) и локальных сетей Ethernet (всех типов). Подобным методом можно передать
одну MPLS-метку или стек меток (несколько меток). На рис. 9.3 показан способ
передачи метки по каналам РРР и локальным сетям Ethernet.
• Как часть заголовка канального уровня. Этот способ подходит для технологии
ATM, в которой информация метки передается в полях VPI/VCI, как показано
на рис. 9.4.
246 Часть II. Качество обслуживания канального уровня и сети MPLS...
Заголовок РРР MPLS-меткв л- Заголовок 3-го уровня ?
Заголовок МАС MPLS-метка заголовок ^гоуровия
Рис. 9.3. MPLS-метка в PPP-кадре и Ethernet-кадре
GFC '5IVPI 'У'-vci «' '$РТР, A’CLP*
t
MPLS-метка
Рис. 9.4. MPLS-метка, передаваемая в полях VPI/VCI АТМ-заголовка
• Как часть кадра AAL5 (ATM Adaptation Layer 5 — уровень адаптации ATM 5) пе-
ред сегментацией и сборкой (segmentation and reassembly — SAR). Это происходит
в ATM-окружении в случае, когда информация метки состоит из стека меток
(несколько полей MPLS-меток).
Примечание
Добавление MPLS-метки или стека меток к 1492-байтовому пакету может привести к
его фрагментации. При передаче пакетов MTU-размера (Maximum Transmission Unit —
максимально возможная единица передачи данных) с MPLS-меткой протокол управ-
ления передачей (Transmission Control Protocol— TCP) определяет, что в MPLS-сети
необходимо произвести фрагментацию.
Однако следует отметить, что многие Ethernet-каналы поддерживают 1500- или 1508-
байтовые пакеты. Более того, в большинстве сетей пакеты с метками обычно пере-
даются по ATM- или PPP-каналам, а не по сегментам локальных сетей.
Поле MPLS-метки состоит из заголовка и 20-битовой метки. Заголовок метки со-
стоит из трех полей: поля CoS, S-бита и поля TTL (Time-to-Live — “время жизни”).
Формат 4-байтовой MPLS-метки представлен на рис. 9.5.
0 12 3
012345678910123456789012345678901
Метка CoS S TTL
Метка 20 бит
CoS (класс обслуживания) 3 бит
S (признак "дна" стека) 1 бит
TTL ("время жизни") 8 бит
Рис. 9.5. Формат MPLS-метки
• CoS (3 бит). Это поле необходимо для предоставления дифференцированных
услуг в MPLS-сети. Для сквозного обеспечения услуг IP QoS на границе MPLS-
сети можно скопировать поле IP-приоритета в поле CoS.
• S-бит. Указывает на метку в нижней части стека. Устанавливается в 1 для по-
следней метки в стеке и в 0 для всех остальных меток стека. Это позволяет
привязывать префикс к нескольким меткам, другими словами — к стеку меток
Глава 9. Качество обслуживания в сетях MPLS
247
(label stack). Каждая метка стека имеет свои собственные значения поля CoS, S-
бита и поля TTL.
Примечание
Поле CoS в MPLS-заголовке имеет только 3 бит. Таким образом, в нем может переда-
ваться только 3-битовое поле IP-приоритета, а 6-битовое поле кода дифференциро-
ванной услуги (Differentiated Services Code Point — DSCP) — нет. При необходимости
информация CoS может передаваться в виде одной из меток MPLS-стека. Поле метки
имеет размер 20 бит и способно вместить как поле IP-приоритета, так и поле DSCP.
• TTL (8 бит). Указывает “время жизни” MPLS-пакета. Значение TTL, установ-
ленное на границе MPLS-сети, уменьшается по мере прохождения пакетом ка-
ждой следующей точки назначения MPLS-сети.
Примечание
По умолчанию во время добавления метки поле TTL протокола IP копируется в поле
TTL MPLS. Это позволяет служебной программе traceroute показывать все промежу-
точные узлы сети MPLS в том случае, когда при достижении точки назначения пакет
проходит MPLS-облако.
Для того чтобы при входе в MPLS-сеть поле TTL протокола IP не копировалось в поле
TTL MPLS, используется команда no mpls ip propagate-ttl. В этом случает значение
поля TTL MPLS устанавливается в 255. Следовательно, после этого служебная про-
грамма traceroute не показывает промежуточные узлы в MPLS-сети. Вместо этого она
отображает весь домен MPLS как один IP-переход.
MPLS и ATM
У ATM-коммутатора уже есть передающий компонент MPLS-типа, поскольку он
производит замену поля VPI/VCI, похожую на замену MPLS-меток. Таким образом,
для того чтобы коммутатор поддерживал MPLS, ему необходим только управляющий
компонент. Для передающего компонента и передачи информации метки использует-
ся поле VPI/VCL Во всех случаях, когда можно ограничиться одной меткой, для ее
передачи по MPLS-сети, основанной на технологии ATM, используется поле VCI.
Поле VPI вступает в действие, если возникнет необходимость во второй метке.
Для поддержки управляющего компонента MPLS на ATM-коммутаторе следует за-
пустить протокол маршрутизации, например OSPF или IS-IS. Это нужно для общения
с другими LSR-маршрутизаторами, получения информации о достижимости точек на-
значения сетевого уровня и распространения основанной на этой информации табли-
цы CEF. LSR-маршрутизатор ATM не обязательно должен работать с протоколом
BGP, так как в большинстве случаев он все равно не может быть LER-
маршрутизатором. Далее, чтобы информация метки распространялась среди соседних
LSR, на этом маршрутизаторе необходимо запустить протокол распространения ме-
ток, такой, как LDP, и протокол резервирования ресурсов (Resource Reservation Proto-
col — RSRP) с функцией управления трафиком (TE-RSRP), который более подробно
обсуждается в главе 10, “Управление трафиком в сетях MPLS”.
248
Часть II. Качество обслуживания канального уровня и сети MPLS...
Реализация MPLS на ATM-коммутаторе может потребовать ассоциации несколь-
ких меток с одним маршрутом (или с группой маршрутов, имеющих одинаковую сле-
дующую точку назначения). Это необходимо для избежания чередования пакетов,
приходящих от разных, расположенных выше по потоку коммутаторов меток, но от-
правляемых одновременно в одну и ту же точку назначения. Для назначения меток и
поддержки базы LIB на ATM-коммутаторах может использоваться либо схема нисхо-
дящего назначения меток по требованию, либо схема восходящего назначения меток.
Практический пример 9.1: нисходящее
распространение меток
В этом примере обсуждается привязка меток, распространение и коммутация на
основе меток для префикса 222.222.222.3 на Нью-Йоркском маршрутизаторе в сети,
схематически показанной на рис. 9.6. В процессе коммутации участвуют маршрутиза-
торы Нью-Йорка, Чикаго, Далласа и Сан-Франциско.
Для запуска MPLS на маршрутизаторе используется команда mpls ip. Первая необ-
ходимая вещь для распространения меток — это механизм CEF, который включается
с помощью глобальной команды ip cef.
При нисходящем назначении меток MPLS-маршрутизатор размещает входящую
метку для каждого элемента таблицы CEF и распространяет ее на каждый из своих
интерфейсов. Расположенный выше по потоку маршрутизатор получает привязку
метки и использует ее как исходящую метку для своего ассоциированного CEF-
префикса. В этом методе назначения меток входящая метка назначается локально, а
исходящая — получается от расположенного ниже по потоку маршрутизатора.
В данном примере внимание концентрируется на изучении процесса нисходящего рас-
пространения меток для одного префикса: 222.222.222.3. В следующих листингах содер-
жится информация о префиксе 222.222.222.3, взятая из таблицы CEF, информация о при-
вязке метки и таблица продвижения меток каждого маршрутизатора. Для получения ин-
формации из таблицы CEF, информации о привязке метки и таблицы продвижения меток
используются команды show ip cef, show mpls Idp bindings и show mpls forwarding-table, соот-
ветственно. В листингах 9.1—9.3 представлена информация CEF, информация о привязке
меток и параметры протокола распространения меток Нью-Йоркского маршрутизатора.
Листинг 9.1. Информация о префиксе 222.222.222.3 из таблицы CEF 1
Нью-Йоркского маршрутизатора ; ।
NewYorkfshow ip cef 222.222.222.3
222.222.222.3/32, version 170, connected, receive
| Листинг 9.2. Информация о прйвязке метки префикса 222.222.222.3, взятая
L из Нью-Йоркского маршрутизатора
NewYorkfshow mpls Idp bindings
LIB entry: 222.222.222.3/32, rev 118
local binding: label: imp-null
remote binding: Isr: 222.222.222.2:0, label: 26
remote binding: Isr: 222.222.222.4:0, label: 29
Глава 9. Качество обслуживания в сетях MPLS
249
Локальная метка Исходящая метка или VC-канал Префикс Выходной интерфейс
26 Метка POP 222.222.222.3 Hssi1/0
Локальная метка: 26
Hssil/O
222.222.2222
Чикаго
Локальная метка: 31
Локальная метка Исходящая метка или VC-канал Префикс Выходной интерфейс
31 26 222.222.222.3 Hssil/1
29 222.222.222.3 Hssil/O
222.222.222.22
222.222.222.3 ->26
222.222.222.3 ->26
222.222.222.1
Сан-Франциско
Даллас
222.222.222.3
Нью-Йорк
'.222.3 ->29
HssiVO
222.222.222.4
222.222.222.3 ->31
222.222.222.3 ->0
Hss<1/1
Hssi1/0
222.222.222.3 ->31
222.222.222 3 ->29
222.222.222.18
222.222.222.9
222.222.222.14
222 222.222.3 ->0
Локальная метка: 29
Локальная метка Исходящая метка или VC-канал Префикс Выходной интерфейс
29 Метка POP 222.222.222.3 HssH/0
Направление потока данных
Рис. 9.6. Нисходящее распространение меток
Листинг 9.3. Параметры протокола распространения меток ; л J
NewYorkishow mpls Idp paramatars
Protocol version: 1
Downstream label pool: min label: 10; max_label: 100000; reserved labels: 16
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery directed hello: holdtime: 180 sec; interval: 5 sec
MPLS создает привязки меток для всех префиксов в таблице CEF и распространя-
ет их среди своих LDP-соседей. С помощью команды show mpls Idp bindings можно
просмотреть привязки меток. Локальные привязки передаются вверх по потоку.
В данном случае локальной привязкой для префикса 222.222.222.3 является NULL,
так как это напрямую подключенный IP-адрес маршрутизатора. Маршрутизатор Нью-
Йорка передает привязку метки NULL своим соседним LDP-маршрутизаторам в Чи-
каго и Далласе. Маршрутизатор, получивший привязку метки префикса NULL, вы-
талкивает (pops) метку при продвижении пакета, направленного к этому префиксу.
Удаленные привязки — это привязки меток, объявленные соответствующими маршру-
тизаторами. Удаленные LSR-маршрутизаторы 222.222.222.2 и 222.222.222.4 имеют локаль-
ные метки 26 и 29, соответственно. Локальная привязка метки распространяется всем
смежным LDP-маршрутизаторам. С помощью команды show mpls Idp paramaters можно
просмотреть параметры протокола LDP и информацию о привязке меток.
Так как маршрутизатор Нью-Йорка получает пакеты, предназначенные для пре-
фикса 222.222.222.3, без метки, то в таблицу продвижения меток информация о пре-
фиксе 222.222.222.3 не заносится.
В листингах 9.4-9.6 представлена информация из таблицы CEF, информация о
привязке и информация о продвижении меток для префикса 222.222.222.3 на маршру-
тизаторе Чикаго.
Листинг 9.4. Информация о префиксе 222.222.222.3 из таблицы CEF j
маршрутизатора Чикаго I
Chicagofshow ip caf 222.222.222.3
222.222.222.3/32, version 179, cached adjacency to Hssil/0
0 packets, 0 bytes
via 210.210.210.9, Hssil/0, 0 dependencies
next hop 210.210.210.9, Hssil/0
valid cached adjacency
Листинг 9.5. Информация б привязке метки для префикса 222.222.222.3
маршрутизатора Чикаго |
Chicagofshow mpls Idp bindings
LIB entry: 222.222.222.3/32, rev 90
local binding: label: 26
remote binding: Isr: 222.222.222.3:0, label: imp-null
remote binding: Isr: 222.222.222.1:0, label: 31
Глава 9. Качество обслуживания в сетях MPLS
251
: Листинг 9.6. Информация о продвижении метки для префикса
222.222.222.3 маршрутизатора Чикаго
Chicago#show mpls forwarding-table
Local Outgoing Prefix Bytes label Outgoing Next Hop
Label label or VC or Tunnel Id switched interface
26 Pop label 222.222.222.3/32 63 Hsl/0 point2point
Локальная метка 26 является привязкой метки префикса 222.222.222.3 на мар-
шрутизаторе в Чикаго. Эта локальная привязка производится в ответ на появле-
ние записи 222.222.222.3 в таблице CEF и распространяется среди всех LDP-
соседей. У LSR-маршрутизатора в Сан-Франциско есть локальная привязка мет-
ки 31 для префикса 222.222.222.3, которая распространяется всем LDP-соседям.
С помощью команды show mpls forwarding-table можно просмотреть информацию,
необходимую для коммутации пакетов методом замены меток. Исходящая метка
является POP-меткой (POP label), потому что на исходящий интерфейс была по-
лучена метка NULL от удаленного маршрутизатора в Нью-Йорке (поскольку пре-
фикс является напрямую подключенным адресом удаленного маршрутизатора).
В этом примере все входящие пакеты с меткой 26 коммутируются на интерфейс
Hssil/О после удаления или выталкивания (popping) метки. Метка удаляется, пото-
му что пакет коммутируется к своему конечному маршрутизатору. Удаление метки
на предпоследней точке перед пунктом назначения называется выталкиванием в
предпоследней точке (penultimate hop popping — PHP).
В листингах 9.7—9.9 показана информация из таблицы CEF, информация о при-
вязке и информация о продвижении метки для префикса 222.222.222.3 маршрутизато-
ра в Далласе.
Листинг 9.7. Информация о префиксе 222.222.222.3 из таблицы CEF мар-
1 шрутизатора в Далласе .
Dallas#show ip cef 222.222.222.3
222.222.222.3/32, version 18, cached adjacency to Hssil/0
0 packets, 0 bytes
via 210.210.210.14, Hssil/0, 0 dependencies
next hop 210.210.210.14, Hssil/0
valid cached adjacency
» Листинг 9.8. Информация о привязке метки для префикса 222.222.222.3
маршрутизатора в Далласе
Dallas#show mpls Idp bindings
LIB entry: 222.222.222.3/32, rev 18
local binding: label: 29
remote binding: Isr: 222.222.222.3:0, label: imp-null
remote binding: Isr: 222.222.222.1:0, label: 31
252
Часть II. Качество обслуживания канального уровня и сети MPLS...
f Листинг 9.9. Информация о продвижении метки для префикса
i .Х7д:'.',;..'.222.222.222Л маршрутизатора в Далласе'
Dallasfshow mpls forwarding-table
Local Outgoing Prefix Bytes label Outgoing Next Hop
label label or VC or Tunnel Id switched interface
29 Pop label 222.222.222.3/32 1190 Hsl/0 point2point
Разъяснения этих листингов для маршрутизатора в Далласе в основном такие же,
как и для маршрутизатора в Чикаго.
В листингах 9.10-9.12 представлена информация из таблицы CEF, информация о
привязке и информация о продвижении метки для префикса 222.222.222.3 маршрути-
затора в Сан-Франциско.
! Листинг 9.10. Запись в таблице CEF для префикса 222.222.222.3
| маршрутизатора в Сан-Франциско
SanFranciscofshow ip cef 222.222.222.3
222.222.222.3/32, version 38, per-destination sharing
0 packets, 0 bytes
via 210.210.210.22, Hssil/1, 0 dependencies
traffic share 1
next hop 210.210.210.22, Hssil/1
valid adjacency
via 210.210.210.18, Hssil/0, 0 dependencies
traffic share 1
next hop 210.210.210.18, Hssil/0
valid adjacency
0 packets, 0 bytes switched through the prefix
I '• ' ' r‘. " • • > -Л
l Листинг 9.11. Информация б привязке метки для префикса 222.222.222.3 / I
f маршрутизатора в Сан-Франциско |
SanFranciscoishow mpls Idp bindings
LIB entry: 222.222.222.3/32, rev 8
local binding: label: 31
remote binding: Isr: 222.222.222.2:0, label: 26
remote binding: Isr: 222.222.222.4:0, label: 29
| Листинг 9.12. Информация б продвижении метки для префикса
i , л 222.222.222.3 маршрутизатора в Сан-Франциско .
SanFranciscofshow mpls forwarding-table
Local Outgoing Prefix Bytes label Outgoing Next Hop
label label or VC or Tunnel Id switched interface
31 26 222.222.222.3/32 0 Hsl/1 point2point
29 222.222.222.3/32 0 Hsl/0 point2point
Глава 9. Качество обслуживания в сетях MPLS
253
В таблице CEF показаны два одинаковых по стоимости пути для достижения префикса
222.222.222.3. Локальная привязка для префикса — 31, она распространяется среди всех
LDP-соседей. Удаленные привязки представляют собой локальные привязки метки, рас-
пространенные соседними LDP-маршрутизаторами. MPLS-маршрутизатор коммутирует
пакеты, полученные с локальной меткой, заменяя ее на исходящую метку на основе полу-
ченной информации об удаленной привязке.
Качество обслуживания в сетях MPLS
Обеспечение функций QoS — это важный компонент технологии MPLS. В MPLS-
сети QoS-информация передается в поле CoS заголовка MPLS-метки.
Так же, как и IP QoS, MPLS QoS достигается посредством выполнения двух глав-
ных логических шагов, которые показаны в табл. 9.2, и использует такие же QoS-
функции. На рис. 9.7 представлены QoS-функции, использующиеся в MPLS-сети.
*Таб1 iHua79i2gMPLS Оо
Шаг Место применения Подходящие функции QoS Действие QoS
1 Маршрутизатор на Согласование скорости досту- Вариант 1. Механизм CAR ограничивает
входе в MPLS-облако па (Committed Access Rate — трафик на входном маршрутизаторе для
(пограничный мар- шрутизатор) CAR) всего поступающего в MPLS-облако Р-трафика. Он устанавливает для трафика значение IP-приоритета исходя из профи- ля трафика и существующих политик. Значение поля IP-приоритета пакета ко- пируется в поле MPLS CoS. Вариант 2. Механизм CAR ограничивает трафик на входном маршрутизаторе для всего поступающего в MPLS-облако IP- трафика. Она устанавливает для трафика значение поля MPLS CoS исходя из профи- ля трафика и существующего контракта. В отличие от варианта 1, значение приорите- та в IP-заголовке остается неизменным
2 Вся MPLS-сеть Взвешенный алгоритм равно- мерного обслуживания очере- дей (Weighted Fair Queuing — WFQ), взвешенный алгоритм произвольного раннего обна- ружения (Weighted Random Early Detection — WRED) Дифференциация трафика в MPLS-магистрали на основании значения поля MPLS CoS с помощью функций IP QoS WFQ и WRED
MPLS использует функции IP QoS для реализации различных уровней обслужива-
ния трафика, передающегося по MPLS-сети. Единственное различие заключается в
том, что MPLS QoS базируется на CoS-битах MPLS-метки, тогда как IP QoS базиру-
ется на значении поля приоритета в заголовке IP-пакета.
254
Часть II. Качество обслуживания канального уровня и сети MPLS...
Предоставление дифференцированных услуг
с использованием механизмов WFQ/WRED
и анализа битов поля MPLS CoS пакета
Рис. 9.7. QoS в MPLS-cemu
На ATM-магистрали в ATM-коммутаторе с функцией MPLS поддержка MPLS CoS
может осуществляться двумя методами.
• Один LSP (Label Switched Path — определяемый с помощью меток путь) со
службой ABR (Available Bit Rate — доступная скорость передачи).
• Параллельные LSP со службой LBR (Label Bit Rate — скорость передачи меток).
Один LSP-путь при условии использования службы ATM ABR может быть уста-
новлен с помощью протокола LDP. Весь MPLS-трафик использует один и тот же путь
ABR LSP, а его дифференциация производится маршрутизаторами на входе в АТМ-
облако с помощью алгоритмов WFQ и WRED.
Для поддержки трафика с несколькими значениями приоритета можно установить
с помощью протокола LDP несколько параллельных LSP-путей. Каждый установлен-
ный LSP-путь предназначается для передачи трафика с определенным значением по-
ля MPLS CoS. LSP-пути используют службу LBR ATM. LBR — это новая категория
ATM-служб, которая основана на механизмах планирования (WFQ) и отбрасывания
пакетов (WRED) в ATM-коммутаторе, а потому более подходит для протокола IP.
Если ATM-коммутатор не поддерживает MPLS, вы можете воспользоваться услу-
гами ATM QoS с помощью классов трафика, предложенных форумом ATM (Constant
Bit Rate — CBR, Variable Bit Rate — VBR, и ABR), и механизмами взаимодействия
ATM/IP, как обсуждалось ранее в главе 8, “Качество обслуживания на уровне 2:
межсетевой обмен с IP QoS”.
Предоставление сквозных услуг IP QoS
Для проведения классификации трафика с тем, чтобы функции QoS внутри сети
могли реализовать различные типы обслуживания, можно установить биты MPLS CoS
на границе сети. Таким образом, для сквозного предоставления услуг IP QoS через
MPLS-сеть с поддержкой QoS нужно отобразить или скопировать значение IP-
приоритета в биты MPLS CoS на границе MPLS-сети. Значение IP-приоритета может
быть использовано и после выхода пакета за пределы MPLS-сети. В табл. 9.3 показаны
некоторые функции QoS для сквозного предоставления услуг IP QoS через MPLS-сеть.
Глава 9. Качество обслуживания в сетях MPLS
255
Таблица 9.3. Сквозное предоставление услуг IP QoS через MPLS-сеть
Шаг Место применения Тип QoS Функция QoS
1 IP-облако (перед входом в MPLS-сеть) IP QoS Применяются стандартные политики IP QoS. На границе сети к входящему трафику применяется соответствующая политика и устанавливается значение IP-приоритета на основе уровня об- служивания. В IP-сети дифференцирование услуг основывается на значении IP-приоритета
2 Маршрутизатор на Взаимодействие Значение IP-приоритета пакета копируется в поле MPLS CoS.
входе в MPLS-сеть IP/MPLS QoS Поле MPLS CoS также может быть установлено напрямую исходя из профиля трафика и его контракта
3 MPLS-сеть MPLS QoS В MPLS-магистрали дифференциация трафика основывается на поле MPLS CoS с помощью функций IP QoS WFQ и WRED
4 iP-сетъ (после перехо- да через MPLS-сеть) IP QoS IP-приоритет в заголовке IP-пакета продолжает быть основ- ным аспектом при дифференциации трафика и предостав- лении услуг QoS
Практический пример 9.2: MPLS CoS
MPLS-сеть поставщика услуг предлагает разнообразные классы обслуживания для
передаваемого по ней трафика. В табл. 9.4 приведены сведения о четырех классах об-
служивания на основе значения битов CoS.
Таблица 9.4. Четыре класса обслуживания на основе значения битов MPLS CoS i
Класс Биты IP-приоритета (в десятичном формате) Биты класса типа обслуживания (Type of Service - ToS) Приоритет отбрасывания
Класс 0 (низший класс ООО (0) 00 0
обслуживания) 100 (4) 00 1
Класс 1 (стандартный класс 001(1) 01 0
обслуживания) 101 (5) 01 1
Класс 2 (высокий класс 010(2) 10 0
обслуживания) 110(6) 10 1
Класс 3 (управляющий 011 (3) 11 0
трафик) Ш(7) 11 1
Два облака IP-сети, расположенные в Сиэтле и Атланте, соединены через MPLS-сеть,
как показано на рис. 9.7. Рассмотрим действия, необходимые для предоставления стан-
дартного класса обслуживания для трафика, передаваемого из Сиэтла в Атланту.
LER-маршрутизатор
IP-трафик, передаваемый из Сиэтла в Атланту, входит в MPLS-сеть через LER-
маршрутизатор.
256
Часть II. Качество обслуживания канального уровня и сети MPLS...
На интерфейсе LER-маршрутизатора, который подключен к облаку сети в Сиэтле,
активизирован механизм CAR для ограничения входящего трафика в соответствии с
контрактом. В листинге 9.13 поступающий на интерфейс трафик классифицируется
как стандартный путем установки IP-приоритета 5 для трафика с интенсивностью ме-
нее 20 Мбит/с и IP-приоритета 1 — для трафика, превысившего это ограничение.
Листинг 9.13. Активизация механизма CAR с целью классификации тра- j
; ' фика 3..............................цу
interface HssiO/O/O
ip address 221.221.221.254 255.255.255.252
rate-limit input 20000000 2000000 8000000
4>conform-action set-mpls-exp-transmit
transmit 5
exceed-action set-mpls-exp-transmit 1
Как часть взаимодействия IP/MPLS QoS, значение поля IP-приоритета копируется
в поле MPLS CoS.
От LER-маршртизатора трафик, предназначенный для передачи в Атланту, прохо-
дит через LSR-маршрутизатор. На интерфейсе LER-маршрутизатора POS3/0/0, под-
ключенном к LSR, активизированы механизмы WRED и WFQ для дифференциации
трафика на основе значения поля CoS MPLS-пакета.
LSR-маршрутизатор
Трафик, передаваемый в Атланту, проходит через ATM-сеть с поддержкой MPLS.
На LSR-маршрутизаторе сконфигурированы параллельные LSP-пути со службой LBR
так, чтобы по каждому LSP-пути передавался трафик с различным IP-приоритетом.
Другими словами, в ATM-сети осуществляется дифференциация трафика на основе
IP-приоритета. В листинге 9.14 показан пример конфигурирования параллельных
LSP-путей на основе MPLS со службой LBR. Для каждого LSP-пути активизирован
механизм WRED.
* Листинг 9.14. Конфигурирование на LSR-маршрутизаторе параллельных '
LSP-путей со службой LBR
interface АТМ1/1/0
।
interface ATM 1/1/0.1 mpls
ip unnumbered LoopbackO
mpls multi-vc
mpls random detect
Глава 9. Качество обслуживания в сетях MPLS
257
Виртуальные частные сети (VPN)
на основе MPLS
Одним из наиболее важных применений технологии MPLS является служба VPN1. Не-
сколько удаленных облаков сетей клиента могут подключиться к магистрали поставщика
услуг VPN в нескольких местах. VPN-магистраль обеспечивает связность различных обла-
ков сетей клиента. Характеристики такой связности делают облако поставщика услуг по-
хожей на частную сеть для клиента. Между различными VPN-сетями в магистрали по-
ставщика услуг не разрешена передача какой-либо информации.
Любое устройство в VPN-облаке может обмениваться данными только с устройст-
вом облака, которое принадлежит к той же сети VPN.
В сети поставщика услуг для каждого VPN-облака устанавливается соединение
между пограничным маршрутизатором поставщика услуг и пограничным мар-
шртизатором клиента. В сети VPN обычно фигурируют несколько географически
разделенных сетей, которые соединяются с локальными пограничными маршру-
тизаторами поставщика услуг. VPN-облаку и его маршрутам присваиваются один
или более VPN-цветов (VPN colors). Каждый VPN-цвет определяет VPN-сеть, к
которой принадлежит сетевое облако. Облако может обмениваться информацией
с другим облаком, подключенным к VPN-магистрали, только если оно имеет тот
же VPN-цвет. Во всех облаках, подключенных к VPN-магистрали и использую-
щих один цвет, запускается VPN-служба интрасети. Облако из одной сети VPN
может обмениваться данными с облаком из другой сети VPN или Internet с по-
мощью VPN-службы экстрасети. VPN-служба экстрасети может быть реализована
путем выборочной “утечки” некоторых внешних маршрутов различных сетей VPN
или Internet в интрасеть VPN.
В пограничном маршрутизаторе поставщика услуг хранится информация о мар-
шрутах только для тех сетей VPN, к которым они напрямую подключены. Все погра-
ничные маршрутизаторы VPN-сети поставщика услуг соединены в топологию
“полная сетка” и являются многопротокольными BGP-соседями1 2.
Несколько сетей VPN могут использовать одинаковые IPv4-адреса. Примерами та-
ких адресов могут служить частные и незарегистрированные IP-адреса. Пограничный
маршрутизатор поставщика услуг должен отличать такие адреса для разных сетей
VPN. Для этого определяется новое семейство адресов под названием VPN-IPv4. Ад-
рес VPN-IPv4 представляет собой 12-байтовое значение. В его первых восьми байтах
содержится значение отличительного признака маршрута (route distinguisher — RD), в
последних четырех байтах —обычный IPv4-aapec. Признак RD используется для обес-
печения уникальности частных и незарегистрированных IPv4-адресов VPN-сетей в
магистрали поставщика услуг. Признак RD состоит из 2-байтового номера автоном-
ной системы (autonomous system — AS) и 4-байтового значения, назначаемого по-
ставщиком услуг. VPN-IPv4-aapeca считаются разными семействами адресов и пере-
даются по протоколу BGP с помощью его многопротокольных расширений. В BGP-
расширениях информация об отображении метки передается как часть информации о
достижении точки назначения на сетевом уровне (Network Layer Reachability Informa-
1 BGP/MPLS VPNs/Rosen E, Rekhter Y. - RFC 2547.
2 Multiprotocol Extensions for BGP4/Bates T., Chandra R., Katz D., Rekhter Y. — RFC 2283.
258 Часть II. Качество обслуживания канального уровня и сети MPLS...
tion — NLRI)3. Метка идентифицирует выходной интерфейс, подсоединенный к дан-
ному NLRI-префиксу.
Атрибут расширенного сообщества4 используется для передачи значений иденти-
фикатора точки назначения маршрута (Route Target — RT) и идентификатора источ-
ника маршрута (Source of Origin — SOO). Маршрут может ассоциироваться с несколь-
кими значениями RT так же, как атрибут BGP-сообшества может переносить инфор-
мацию о нескольких сообществах для IP-префикса. Значения RT используются для
управления распространением маршрутов, поскольку маршрутизатор может принять
или отвергнуть маршрут исходя из значения RT. Значение SOO используется для
уникальной идентификации VPN-облака. В табл. 9.5 приведены некоторые важные
термины MPLS VPN.
I Таблица 9.5. Терминология MPLS VPN
Термин Определение
Пограничный маршрутизатор клиента (Customer Edge Router) Пограничный маршрутизатор поставщика услуг (Provider Edge Router) Маршрутизатор поставщика ус- луг (Provider Router) Экземпляр таблицы маршрути- зации и продвижения в VPN- сети (VPN Routing and Forwarding — VRF) VPN-IPv4-aflpec SOO RD RT Маршрутизатор клиента, подключенный к пограничному маршрутизатору поставщика услуг Маршрутизатор поставщика услуг, подключенный к пограничному маршру- тизатору клиента Внутренний маршрутизатор сети поставщика услуг. Он не обладает информа- цией о существовании сетей VPN Таблица маршрутизации и продвижения, связанная с одним (или более) напрямую подключенным облаком клиента. VRF назначается для каждого интерфейса VPN-клиента. Облака VPN-клиентов, которые используют одну и ту же информацию о маршрутах, могут быть частью одного экземпляра VRF. Экземпляр VRF идентифицируется по имени и имеет только локаль- ное значение Включает 64-битовый признак RD и 32-битовый IPv4-aflpec Идентифицирует облако-источник 64-битовый атрибут, использующийся для уникальной идентификации ад- ресного пространства VPN-сети в магистрали поставщика услуг 64-битовый идентификатор, необходимый для определения маршрутиза- торов, которые должны получить маршрут
Практический пример 9.3: MPLS VPN
Обсудим ввод в действие VPN-службы между облаками корпоративного клиента в
Сан-Франциско и Нью-Йорке через магистраль поставщика услуг, как показано на
рис. 9.8. Облако клиента в Сан-Франциско подключается к локальному маршрутиза-
тору поставщика услуг, а облако клиента в Нью-Йорке — к маршрутизатору постав-
щика услуг в Нью-Йорке.
•’ Carrying Labe! Information in BGP4/Rekhter Y., Rosen E., в стадии разработки.
4 BGP Extended Communities Attribute/Srihari R., Tappan D. drqft-ramchandra-bgp-ext-communities.txt
Глава 9. Качество обслуживания в сетях MPLS
259
VPN-сеть Red
222.222.222.2
Чикаго
VPN-сеть Green Р°Л°/1 200.200.1.0/24 22 / 200.200.11.0/24 / 222.222.222.20/30/ Облако / s / Сан-Франциско / POS5/1/ CDR y' CAR x\Hssi0/0 “/ 222 222 222 1 Сан-Франциско У / 17\ —>/ POS5/3 X. C J 222 222.222 16/30 X^ VPN-сеть Red X. 1 POS0/0 VPN-сеть Green Ю 200.200 2 0/24 25 X. 200.200.22.0/24 \ 222.222.222.8/30 _ zffCW-wA Облако X. J Ньго'^орка x< POS8/0 /HssiO/O 222.222.222.3 X Нью-Йорк Zl4 222.222.222.24/30 / POS8/2 /222.222.222.12/30 26 / B ДалласХ VPN-сеть Red 222.222.222.4^X/""^
Рис. 9.8. MPLS VPN
В этом примере обсуждается реализация сетей MPLS VPN в магистрали поставщи-
ка услуг. Мы рассмотрим конфигурацию, необходимую для реализации VPN-службы,
а также функционирование сети VPN через сеть поставщика услуг, используя для
этого некоторые команды, выполненные на магистральном маршрутизаторе.
Предположим, что для VPN-службы корпоративного клиента определен VRF-
экземпляр green. Для того чтобы отличать маршруты этого клиента в магистрали по-
ставщика услуг, используется RD-признак 200:100. Обсудим конфигурацию сети VPN
на маршрутизаторе в Сан-Франциско и функционирование сети VPN между облаками
клиента в Сан-Франциско и Нью-Йорке через сеть поставщика услуг. В листинге 9.15
приведена конфигурация MPLS VPN на маршрутизаторе в Сан-Франциско.
; Листинг 9.15. Конфигурация MPLS VPN на маршрутизаторе в Сан-Франциско !
ip vrf green
rd 200:100
route-target export 200:1
route-target import 200:1
route-target import 200:2
ip cef
clns routing
i
interface LoopbackO
ip address 222.222.222.1 255.255.255.255
ip router isis isp
।
interface Hssi0/0
ip vrf forwarding green
ip address 222.222.222.25 255.255.255.252
ip router isis isp
mpls ip
1
interface POS5/1
ip address 222.222.222.21 255.255.255.252
ip router isis isp
mpls ip
i
interface POS5/3
ip address 222.222.222.17 255.255.255.252
ip router isis isp
mpls ip
।
।
router isis isp
net 50.0000.0000.0000.0001.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
Глава 9. Качество обслуживания в сетях MPLS
261
router bgp 200
no synchronization
neighbor 222.222.222.2 remote-as 200
neighbor 222.222.222.2 update-source LoopbackO
neighbor 222.222.222.3 remote-as 200
neighbor 222.222.222.3 update-source LoopbackO
neighbor 222.222.222.4 remote-as 200
neighbor 222.222.222.4 update-source LoopbackO
no auto-summary
i
address-family ipv4 vrf green
no auto-summary
no synchronization
network 200.200.1.0
network 200.200.11.0
exit-address-family
i
address-family vpnv4
neighbor 222.222.222.2 activate
neighbor 222.222.222.2 send-community extended
neighbor 222.222.222.3 activate
neighbor 222.222.222.3 send-community extended
neighbor 222.222.222.4 activate
neighbor 222.222.222.4 send-community extended
no auto-summary
exit-address-family
i
ip route vrf green 200.200.1.0 255.255.255.0 Hssi0/0
ip route vrf green 200.200.11.0 255.255.255.0 HssiO/0
VRF-экземпляр green сконфигурирован на интерфейсе HssiO/O, который подключен
к маршрутизатору клиента в Сан-Франциско. В листинге 9.16 показан RD-признак и
интерфейсы, ассоциированные с VRF-экземпляром green.
Г '' 1 Листинг 9.16. SanFranciscoUsh Name green Информация об VRF-экземпляре green • г , . , . ^4 ip vrf green Default RD Interfaces 200:100 HssiO/0
В первой части BGP-конфигурации маршрутизатор в Сан-Франциско устанавлива-
ет отношение соседства с другими маршрутизаторами магистрали поставщика услуг
по протоколу BGP. Для этого используются адреса интерфейса loopbackO, поскольку
такие интерфейсы всегда работают и не отключаются.
В следующей части BGP-конфигурации определяются маршруты, принадлежащие
VRF-экземпляру green. Такие маршруты могут быть динамически получены с помо-
щью VRF-экземпляра green таких протоколов, как BGP и RlPv2 (Routing Inforamtion
262
Часть II. Качество обслуживания канального уровня и сети MPLS...
Protocol version 2 — протокол информации о маршрутах версии 2). VRF-экземпляр
green протокола работает только на интерфейсах VRF-экземпляра green. Таким обра-
зом, все маршруты VRF-экземпляра green получаются динамически через интерфейсы
VRF-экземпляра green или определяются статически как маршруты VRF-экземпляра
green, указывающие на интерфейс VRF-экземпляра green.
На маршрутизаторе в Сан-Франциско маршруты пользователя, принадлежащие
облаку в Сан-Франциско, определены как статические маршруты VRF-экземпляра
green. Эти статические маршруты указывают на двухточечный интерфейс, подключен-
ный к облаку Сан-Франциско. Для получения информации о статических маршрутах
VRF-экземпляра green можно воспользоваться командой show ip route vrf green.
В последней части BGP-конфигурации определяется группа BGP-соседей для об-
мена семейством маршрутов VPN-IPv4. Экспортные RT-значения передаются в атри-
буте расширенного BGP-сообщества. Локальные VRF-маршруты устанавливаются в
локальной BGP-таблице VPN-IPv4, если их импортированное RT-значение совпадает
с определенным для них экспортным RT-значением. Для того чтобы внести маршрут
в таблицу маршрутизации BGP VPN, в VRF-экземпляре маршрутизатора должно быть
определено импортированное RT-значение как равное одному из полученных вместе
с маршрутом экспортных RT-значений.
На маршрутизаторе в Сан-Франциско для VRF-экземпляра green определено экс-
портное RT-значение 200:1. Все локальные маршруты этого маршрутизатора, принадле-
жащие VRF-экземпляру green, экспортируются с помощью протокола BGP с RT-
значением 200:1 в атрибуте расширенного BGP-сообщества. Маршрутизатор, которому
необходимы маршруты Сан-Франциско, принадлежащие VRF-экземпляру green, должен
с помощью команды route-target import 200:1 импортировать маршруты с RT-значением
200:1. Маршрутизатор в Сан-Франциско сам должен иметь эту команду в конфигура-
ции, так как его импортированное RT-значение должно совпадать с экспортным RT-
значением для того, чтобы он мог передавать маршруты по протоколу BGP.
Наряду с RT-значением 200:1 в VRF-экземпляре green определяется также RT-
значение 200:2. Следовательно, маршрутизатор в Сан-Франциско может импорти-
ровать в таблицу маршрутизации VRF-экземпляра green любые BGP-маршруты
VPN с RT-значением 200:1 или 200:2. С помощью команды showip bgp vpn vrf
green можно просмотреть маршруты VRF-экземпляра green, передаваемые по про-
токолу BGP. Таблицу маршрутизации для VRF-экземпляра green можно просмот-
реть посредством команды show ip router vrf green. IP- и BGP-маршруты, принад-
лежащие к VRF-экземпляру green в маршрутизаторе Сан-Франциско, показаны в
листингах 9.17 и 9.18.
I Листинг 9.17. Маршруты Сан-Франциско в таблице маршрутизации !
j VRF-экземпляра green ।
SanFranciscoflshow ip route vrf green
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, В - BGP
D - EIGRP, EX - EIGRP external, 0 - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, LI - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static routeo - ODR
Глава 9. Качество обслуживания в сетях MPLS
263
Gateway of last resort is not set
222.222.222.0/30 is subnetted, 1 subnets
C 222.222.222.24 is directly connected, Hssi0/0
В 200.200.22.0/24 [200/0] via 222.222.222.3, 00:01:19
S 200.200.1.0/24 is directly connected, Hssi0/0
В 200.200.2.0/24 [200/0] via 222.222.222.3, 00:01:19
S 200.200.11.0/24 is directly connected, Hssi0/0
В VRF-экземпляр таблицы маршрутизации green включены все динамически получен-
ные или статически определенные маршруты VRF-экземпляра green. В нее также включе-
ны маршруты BGP VPN-1IM, которые импортированы в локальную таблицу маршрутиза-
ции VRF-экземпляра green при совпадении импортируемого RT-значения 200:2.
{ Листинг 9.18. Маршруты BGP VPN-IPv4 Сан-Франциско, принадлежащие j
{ ‘ < VRF-экземпляру green ' ‘ 1
SanFrancisco#sh ip bgp vpn vrf green
BGP table version is 57, local router ID is 222.222.222.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 200:100 (default for vrf green)
*> 200.200.1.0 0.0.0.0 0 32768 I
*>i200.200.2.0 222.222.222.3 0 100 0 3456 I
*> 200.200.11.0 0.0.0.0 0 32768 I
*>i200.200.22.0 222.222.222.3 0 100 0 3456 i
Протокол BGP производит обмен привязок меток вместе со своими VPN-IPv4-
маршрутами. В BGP-метке указывается локальный выходной интерфейс, через кото-
рый может быть достигнут маршрут. В листинге 9.19 показаны привязки меток для
VPN-lPv4-MapuipyTOB, передаваемых по протоколу BGP.
{ Листинг 9.19. Привязки меток для VPN-IPv4-Mapiuрутов, передаваемых
! по протоколу BGP
SanFrancisco#sh ip bgp vpn vrf green label
Network Next Hop In label/Out label
Route Distinguisher: 200:100 (green)
200.200.1.0 0.0.0.0 26/nolabel
200.200.2.0 222.222.222.3 nolabel/39
200.200.11.0 0.0.0.0 27/nolabel
200.200.22.0 222.222.222.3 nolabel/40
В листинге 9.19 показано, что 39 — это метка маршрутизатора в Нью-Йорке с ID
222.222.222.3, распространенная как привязка метки для маршрута 200.200.2.0. В сле-
264
Часть II. Качество обслуживания канального уровня и сети MPLS...
дующих нескольких листингах отражен процесс передачи IP-пакета от облака в Сан-
Франциско через сеть поставщика услуг к облаку в Нью-Йорке по адресу 200.200.2.1.
В листинге 9.20 показана информации о продвижении метки для префикса
222.222.222.3.
< Листинг 9.20. Информация о продвижении метки для префикса^ 4?4
J 222.222.222.3 ;
SanFranciscofshow mpls forwarding-table 222.222.222.3
Local Outgoing Prefix Bytes mpls Outgoing Next Hop
label label or VC or Tunnel Id switched interface
36 37 222.222.222.3/32 0 Po5/3 point2point
30 222.222.222.3/32 7161 Po5/1 point2point
В зависимости от природы распределения нагрузки по параллельным путям мар-
шрутизатор может выбрать альтернативную метку для префикса 222.222.222.3. В этом
случае он выбирает метку 30 через интерфейс Ро5/1.
После того как пакет для префикса 200.200.2.1 поступил в маршрутизатор Сан-
Франциско, последний присоединяет к нему стек из двух меток (30 и 39) и отправляет
пакет маршрутизатору в Чикаго через интерфейс Ро5/1. Одна из меток “доставляет”
пакет до следующей точки назначения 222.222.222.3, а другая — до конечной точки
назначения 222.222.2.1. В листинге 9.21 показана информации о продвижении метки
для входящей метки 30 маршрутизатора в Чикаго.
[ Листинг 9.21. Таблица продвижения метки Для 'префикса 222.222.222.3 Jj: Д
Chicagoffsh mpls forwarding-table 222.222.222.3 32
Local Outgoing Prefix Bytes label Outgoing Next Hop
label label or VC or Tunnel Id switched interface
30 Pop label 222.222.222.3/32 7161 Po0/0 point2point
Поскольку маршрутизатор в Чикаго является предпоследней точкой назначения перед
адресом 222.222.222.3, он выталкивает внутреннюю метку 30 и, как показано в
листинге 9.22, отправляет пакет через интерфейс SerialO маршрутизатору в Нью-Йорке.
! Листинг 9.22. Отладочная информация, в которой отражен процесс " !
) коммутации MPLS-пакета от облака клиента k d
} в Сан-Франциско до облака клиента в Нью-Йорке
\ с адресом 200.200.2.1 маршрутизатором в Чикаго ' • ж . < J
MPLS: РоО/1: recvd: CoS=0, TTL=255, Label(s)=30/39
MPLS: Po0/0: xmit: CoS=0, TTL=254, Label(s)=39
После прибытия пакета в маршрутизатор Нью-Йорка в нем все еще остается вто-
рая метка — 39. В листинге 9.23 показана таблица продвижения меток маршрутизато-
ра Нью-Йорка для входящей метки 39.
Глава 9. Качество обслуживания в сетях MPLS
265
! Листинг 9.23. Таблица продвижения меток маршрутизатора Нью-Йорка
для VRF-экземпляра green
NewYorkUsh mpls forwarding-table vrf green
Local Outgoing Prefix Bytes mpls Outgoing Next Hop
label label or VC or Tunnel Id switched 1 interface
39 Unlabelged 200.200.2.0/24[V] 520 Hs0/0 point2point
40 Unlabelged 200.200.22.0/24[V] 0 Hs0/0 point2point
Исходя из информации о продвижении меток маршрутизатор Нью-Йорка удаляет
входящую метку 39 и отправляет пакет через интерфейс HssiO/O, подключенный к об-
лаку в Нью-Йорке. Это действие отображено в листинге 9.24 с помощью команд от-
ладки, выполненных на маршрутизаторе Нью-Йорка.
Листинг 9.24. Отладочная информация, в которой отражен процесс i
коммутации MPLS-пакета на адрес 200.200.2.1 |
маршрутизатором Нью-Йорка ^?, г х
MPLS: Р08/О: recvd: CoS=0, TTL=254, Label(s)=39
MPLS: HsO/O: xmit: (no label)
В листинге 9.25 показана конфигурация VPN на маршрутизаторе Нью-Йорка.
[Листинг 9.25. Конфигурация VPN на маршрутизаторе Нью-Йорка
ip vrf green
rd 200:100
route-target export 200:2
route-target import 200:1
route-target import 200:2
ip cef
clns routing
i
t
i
interface LoopbackO
ip address 222.222.222.3 255.255.255.255
ip router isis isp
t
interface POS8/0
ip address 222.222.222.9 255.255.255.252
ip router isis isp
mpls ip
t
interface HssiO/O
ip vrf forwarding green
ip address 222.222.222.37 255.255.255.252
266
Часть II. Качество обслуживания канального уровня и сети MPLS...
ip router isis isp
mpls ip
j
interface POS8/2
ip address 222.222.222.14 255.255.255.252
ip router isis isp
mpls ip
j
router isis isp
net 50.0000.0000.0000.0003.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
i
router bgp 200
no synchronization
neighbor 222.222.222.1 remote-as 200
neighbor 222.222.222.1 update-source LoopbackO
neighbor 222.222.222.2 remote-as 200
neighbor 222.222.222.2 update-source LoopbackO
neighbor 222.222.222.4 remote-as 200
neighbor 222.222.222.4 update-source LoopbackO
no auto-summary
t
address-family ipv4 vrf green
neighbor 222.222.222.38 remote-as 3456
neighbor 222.222.222.38 activate
no auto-summary
no synchronization
exit-address-family
t
address-family vpnv4
neighbor 222.222.222.1 activate
neighbor 222.222.222.1 send-community extended
neighbor 222.222.222.2 activate
neighbor 222.222.222.2 send-community extended
neighbor 222.222.222.4 activate
neighbor 222.222.222.4 send-community extended
no auto-summary
exit-address-family
Во второй части BGP-конфигурации маршрутизатора Нью-Йорка показано, что в нем
используется отношение BGP-соседства для получения маршрутов VRF-экземпляра green
от облака в Нью-Йорке. Обратите внимание, что в маршрутизаторе Сан-Франциско, кон-
фигурация которого обсуждалась ранее, маршруты VRF-экземпляра green облака Сан-
Франциско сконфигурированы статически.
Глава 9. Качество обслуживания в сетях MPLS
267
Качество обслуживания в сетях MPLS VPN
Качество обслуживания — это ключевой компонент службы VPN. Так же, как
и услуги IP QoS, которые обсуждались в первой части книги, услуги MPLS VPN
QoS могут быть как дифференцированными, так и гарантированными. Для обес-
печения MPLS VPN QoS можно использовать те же средства IP QoS, которые об-
суждалась в части I этой книги, “Качество обслуживания в сетях IP”. “Грубые”
дифференцированные услуги QoS реализуются с помощью механизмов CAR, WFQ
и WRED, тогда как “тонкие” гарантированные услуги QoS — с помощью прото-
кола RSVP.
Дифференцированные услуги MPLS VPN QoS
Эта модель QoS обладает свойствами, которые в некоторых случаях похожи на
свойства механизма согласования скорости передачи информации (Committed Infor-
mation Rate — CIR) во Frame Relay-сети.
Каждое VPN-облако предоставляет функции CAR и CDR (Committed Delivery
Rate — согласованная скорость доставки информации) на каждом порту, через кото-
рый узел получает доступ к сети. Во Frame Relay-сети механизм CIR применяется для
входящего и исходящего трафика устройства, подключенного к сети. Однако в окру-
жении, не ориентированном на установку соединения, каковым является IP-сеть
VPN, для каждого порта, который подключен к VPN-сети, существуют две различные
скорости передачи.
• Скорость CAR — для всего входящего трафика от облака в порт доступа к
VPN-сети.
• Скорость CDR — для всего исходящего трафика от оставшейся части VPN-сети
в облако, подключенное через порт доступа.
Трафик, поступающий в порт доступа к MPLS VPN-сети, называется согласован-
ным, если скорость входящего и исходящего трафика этого порта ниже обусловлен-
ной скорости CAR и CDR, соответственно. Согласованные пакеты доставляются с
большей вероятностью, чем несогласованный трафик.
Из-за того, что в IP-сети VPN передача данных осуществляется без установки со-
единения, пакеты можно отправлять между любыми двумя облаками сети VPN, но
при этом нужно определить согласованную скорость передачи информации отдельно
для входящего и исходящего трафика. Так как в протоколе Frame Relay обмен данны-
ми осуществляется с установкой соединения, одна и та же скорость передачи трафика
подходит для обоих концов канала.
Для того чтобы реализовать службы CAR и CDR на порту доступа, применяют
функцию ограничения входящего и исходящего трафика. Эта функция присваива-
ет больший IP-приоритет согласованному трафику и меньший IP-приоритет —
несогласованному. В VPN-магистрали поставщика услуг дифференцированные
QoS-функции WFQ и WRED применяются для доставки согласованного трафика
с большей вероятностью по сравнению с несогласованным трафиком. В табл. 9.6
приведены функции QoS, которые применяются для трафика, передающегося из
одного VPN-облака в другое через сеть MPLS VPN поставщика услуг.
268
Часть II. Качество обслуживания канального уровня и сети MPLS...
i Таблица 9.6. Функции MPLS VPN QoS
Шаг Место применения Функция QoS
1 Маршрутизатор на входе в сеть MPLS VPN Вариант 1. Механизм CAR ограничивает трафик, который приходит от погра- ничного маршрутизатора клиента, в пограничном маршрутизаторе постав- щика услуг. Трафику присваивается значение IP-приоритета исходя из его профиля и контракта. Значение IP-приоритета в заголовке IP-пакета копиру- ется в поле MPLS CoS. Вариант 2. Механизм CAR ограничивает трафик, который приходит от погра- ничного маршрутизатора клиента, в пограничном маршрутизаторе постав- щика услуг. Трафику присваивается значение MPLS CoS исходя из его про- филя и контракта
2 Магистраль постав* щика услуг Дифференциация трафика на основе поля MPLS CoS с помощью функций IP QoS WFQ и WRED
3 Маршрутизатор на выходе из сети MPLS VPN Поле CoS из MPLS метки копируется в поле IP-приоритета в заголовке IP-пакета
4 Маршрутизатор на выходе из сети MPLS VPN Механизм CAR ограничивает исходящий трафик на интерфейсе погранично- го маршрутизатора поставщика услуг, подключенном к конечному маршру- тизатору клиента, на основе функции CDR
Как показано на рис. 9.9, поставщик услуг использует механизмы CAR и CDR на
каждом порту доступа. Поставщик услуг настраивает сеть таким образом, чтобы порты
доступа работали на скоростях CAR и CDR. Любой трафик, превысивший согласо-
ванную скорость передачи, отбрасывается с большей вероятностью по сравнению с
согласованным трафиком.
Согласованная скорость
доставки (Committed
Delivery Rate — CDR)
Поставщик услуг CAR
MPLS VPN
Согласованная скорость
доступа (Committed
Access Rate — CAR)
CDR
MPLS CoS
CDR
VPN Green ;
Использование механизмов
vvFQ/WRED на основе
битов поля CoS
Рис. 9.9. Дифференцированные QoS-услуги сети MPLS VPN
VPN,Green
Облако 1
Согласованные пакеты в правильно сконфигурированной сети MPLS VPN достав-
ляются с высокой вероятностью, сравнимой с надежностью механизма CIR в сетях
Frame Relay.
Глава 9. Качество обслуживания в сетях MPLS
269
Гарантированные услуги QoS
Для обеспечения гарантированных услуг QoS требуется сквозное использование
протокола RSVP во всех VPN-облаках, подключенных посредством магистрали по-
ставщика услуги, на всем пути от источника до точки назначения. Размеры области и
уровень гарантированных услуг QoS зависят от того, какая часть сети производит яв-
ное резервирование ресурсов с помощью сообщений RSVP PATH. Мы обсудим три
уровня реализации гарантированных услуг QoS в следующих разделах этой книги. В
основном они отличаются предлагаемым поставщиком услуг VPN качеством обслужи-
Поставщик услуг
MPLS VPN
Рис. 9.10. Гарантированные услуги QoS в сети MPLS VPN QoS
Использование протокола RSVP только в узлах VPN-облака
RSVP-резервирование производится только в узлах VPN-облака. Поставщик услуг
VPN просто передает все RSVP-пакеты, как если бы это были обычные IP-пакеты с
данными. Это позволяет клиенту управлять распределением ресурсов в рамках кли-
ентского облака, но никак не влияет на обработку клиентского трафика в сети по-
ставщика услуг.
Использование протокола RSVP в VPN-облаке
и предоставление дифференцированного обслуживания
магистралью поставщика услуг
RSVP-резервирование производится только в узлах VPN-облака. На входе в сеть
поставщика услуг VPN трафик с гарантированным обслуживанием отмечается высо-
ким значением поля MPLS CoS. Таким образом, этот трафик будет доставляться по
сети поставщика услуг MPLS VPN с большой степенью вероятности благодаря ис-
пользованию таких функций IP QoS, как WFQ и WRED. Поставщик услуг MPLS VPN
передает все RSVP-пакеты как обычные IP-пакеты с данными.
Таким образом, трафик, для которого были зарезервированы ресурсы, получает
более высокий уровень обслуживания без участия поставщика услуг, которому в
этом случае не нужно производить резервирование ресурсов отдельно для каждого
клиента своей сети.
270
Часть II. Качество обслуживания канального уровня и сети MPLS...
Сквозная гарантированная полоса пропускания
Туннели с гарантированной полосой пропускания (guaranteed bandwidth — GB) ис-
пользуются для передачи трафика, требующего резервирования ресурсов в магистрали
поставщика услуг. Основополагающим принципом при создании GB-туннеля являет-
ся отметка части веса очереди гарантированной полосы пропускания как занятой.
RSVP-резервирование производится как сквозное от источника до точки назначе-
ния через сеть поставщика услуг VPN. Внутри сети поставщика услуг RSVP-
сообщения передаются по GB-туннелю, как обычные пакеты с данными.
Практический пример 9.4: качество обслуживания в сетях
MPLS VPN
Поставщик услуг IP VPN предлагает для своих клиентов “стандартный” и
“высокий” уровни обслуживания (подобно уровням услуг, приведенным ранее в
табл. 9.4). В зависимости от типа обслуживания весь поступающий от клиента трафик
классифицируется и дифференцируется в магистрали поставщика VPN.
В листинге 9.26 показана конфигурация механизмов ограничения трафика CAR и
CDR, используемых в точке подключения клиента к сети VPN.
i Листинг 9.26. Конфигурация механизмов CAR и СОЯ для классификации
входящего и исходящего трафика, соответственно
Interface Hssi2/0/0
ip vrf forwarding green
ip address 200.200.1.1 255.255.255.252
rate-limit input 1500000 8000 8000
4>conform-action set-mpls-exp-transmit 5
4>exceed-action set-mpls-exp-transmit 1
rate-limit output 1000000 8000 8000
’bconform-action set-mpls-exp-transmit 5
4>exceed-action set-mpls-exp-transmit 1
На входных интерфейсах пограничных маршрутизаторов поставщика услуг скон-
фигурированы механизмы CAR и CDR. Значения CAR и CDR для облака клиента
сконфигурированы как 1.5 Мбит/с и 10 Мбит/с, соответственно. На всех интерфейсах
магистральных маршрутизаторов поставщика услуг VPN определена служба MPLS
CoS для дифференцирования трафика на основе значения поля CoS MPLS-пакета.
Резюме
MPLS позволяет коммутировать пакеты на основе информации метки в пакете без
необходимости просматривать IP-заголовок. Коммутация пакетов производится с по-
мощью замены меток, а не путем определения более полного совпадения адреса точки
назначения в таблице продвижения IP-пакетов. Для определения приоритета пакета в
MPLS-метке есть три бита CoS, похожих на биты поля IP-приоритета. Поле MPLS
CoS можно использовать для индикации приоритета пакета в MPLS-сети и сквозного
предоставления услуг IP QoS через MPLS-облако.
Глава 9. Качество обслуживания в сетях MPLS
271
Важная область применения технологии MPLS — создание на основе MPLS сетей
VPN. Сети MPLS VPN являются хорошо масштабируемым решением вследствие ис-
пользования протоколов маршрутизации для сокрытия информации о топологии, из-
вестной входящему пакету, от VPN-облака. В сетях MPLS VPN можно обеспечить
функции качества обслуживания с помощью механизмов CAR и CDR, а также диф-
ференцированные функции QoS в базовой сети поставщика услуг. Для реализации га-
рантированных услуг QoS в сети VPN используются GB-туннели.
Ответы на часто задаваемые вопросы
Во всех ли маршрутизаторах реализованы функции LSR и LER?
Функции LSR и LER являются встроенными в маршрутизатор и поддерживаются
любыми образами системы Cisco IOS, в которых реализована технология MPLS.
Маршрутизатор выполняет соответственно функции LSR или LER в зависимости от
своего размещения: на границе или внутри MPLS-сети.
Как распространется информация метки в MPLS-cemu?
Информация метки распространяется с помощью протокола LDP. Эта информа-
ция также может передаваться по протоколу BGP (в сетях MPLS VPN), по протоколу
RSVP (MPLS-управления трафиком) или по протоколу обнаружения меток Cisco (Tag
Discovery Protocol — TDP), который является предшественником протокола LDP.
272
Часть II. Качество обслуживания канального уровня и сети MPLS...
Часть
III
Управление трафиком
%
W.
В этой части
2
В этой главе.
¥
м
Оверлейная модель канального уровня
Маршрутизация на основе резервирования ресурсов (RRR)
Определение ТЕ-транка •...
Атрибуты ТЕ-туннеля
Атрибуты ресурсов канала ' *"
Распространение информации о ресурсах канала ...
Политика выбора пути
Установка ТЕ-туннеля ./•
S ^/правление доступом к каналу
Поддержка ТЕ-пути
Сигнальный протокол ТЕ-RSVP . ,
Расширения протокола маршрутизации внутреннего шлюза
Подходы к реализации механизма управления трафиком
278
279
280
281
283
284
284
285
286
286
287
288
289
Глава
10
Управление трафиком
в сетях MPLS
Механизм управления трафиком (Traffic Engineering — ТЕ) предоставляет воз-
можность устанавливать явный путь, по которому будут передаваться потоки дан-
ных. IP-трафик маршрутизируется посредством его передачи от одной точки на-
значения к другой и следует до пункта назначения по пути, имеющем наимень-
шую суммарную метрику сетевого уровня. Путь, по которому следует 1Р-трафик,
может не быть оптимальным, так как он зависит от информации о статической
метрике канала. При выборе пути не учитываются свободные сетевые ресурсы, а
также требования к обслуживанию трафика.
В главе 9, “Качество обслуживания в сетях MPLS”, обсуждалось назначение и
распространение меток с использованием технологии MPLS (Multiprotocol Label
Switching — многопротокольная коммутация меток) для передачи пакетов по
маршрутному пути, основанному на адресе пункта назначения. В этой главе мы
рассмотрим механизм управления трафиком в сети MPLS (MPLS ТЕ). Этот меха-
низм определяет коммутируемый с помощью меток путь (Label Switched Path —
LSP) для передачи трафика по явным образом заданному пути, который может
отличаться от обычного пути, основанного на адресе пункта назначения. В каче-
стве сигнального протокола для установки пути LSP используется протокол ре-
зервирования ресурсов (Resource Reservation Protocol — RSVP) ТЕ-модификации
(ТЕ-RSVP).
Наибольшей проблемой для поставщика услуг при обеспечении сквозного качества
обслуживания (quality of service — QoS) является неспособность определить точный
путь, по которому будут передаваться IP-пакеты. Маршрутизатор не может заранее
определить путь, rio которому пойдет IP-трафик, что является результатом поэтапного
принятия решения о маршруте. Подобное свойство IP-маршрутизации обусловлено
тем, что IP является протоколом без ориентации на установку соединения, в отличие
от телефонных сетей, сетей Frame Relay и сетей ATM (Asynchronous Transfer Mode —
режим асинхронной передачи). При маршрутизации на основе резервирования ресур-
сов (Routing by Resource Reservation — RRR) для обеспечения механизма IP ТЕ ис-
пользуются свойства MPLS-канала. Таким образом, туннели, построенные на базе
LSP-пути, используются для управления трафиком, а метки — для передачи данных
по явному пути, отличающемуся от того, который получается в результате передачи
пакетов на основе адреса пункта назначения1.
На сегодняшний день решение, основанное на использовании механизма MPLS
ТЕ, ограничено одним маршрутным доменом. Для протоколов внутреннего шлюза
(Interior Gateway Protocol — IGP) необходимы расширения, позволяющие им поддер-
живать механизм ТЕ. На текущий момент только открытый протокол предпочтитель-
ного выбора кратчайшего пути (Open Shortest Path First — OSPF) и протокол обмена
информацией о маршрутах между промежуточными системами (Intermediate System-
to-Intermediate System — IS-IS) поддерживают ТЕ-расширения.
Оверлейная модель канального уровня
Традиционно сложилось так, что оверлейные сети, построенные на канальном
уровне, использовались для управления трафиком и полосой пропускания. В свою
очередь, сетевой уровень (IP) “видел” логическую полносвязную структуру, построен-
ную на базе облака канального уровня (ATM или Frame Relay). У каждого маршрути-
затора на сетевом уровне было логическое соединение с каждым маршрутизатором,
подключенным к облаку канального уровня.
На рис. 10.1 показано физическое и логическое представление сетевого уровня
оверлейной модели. Физическая модель включает в себя устройства сетевого уров-
ня — маршрутизаторы, соединенные через коммутаторы на канальном уровне (Frame
Relay или ATM). Коммутаторы помогают определить точный физический путь, по ко-
торому пройдет трафик сетевого уровня, входящий в облако Frame Relay или ATM.
Рис. 10.1. Оверлейная модель канального уровня для механизма
управления трафиком
Полное объединение
на сетевом уровне
Для трафика, идущего от маршрутизатора А к маршрутизатору В, облако каналь-
ного уровня предоставляет три физических пути: А1* 1=>4=>В, А^^^З^Ф^В и
А=> 1 =>б‘=>51=>41=> В. Однако реальный путь, по которому пойдет IP-трафик, уже предо-
пределен коммутаторами канального уровня. Использование явного транзитного
1 Requirements for Traffic Engineering Over MPLS/Awduche D. et al., draft~ietf-mpls-traffic-eng-OO.txt.
278
Часть III. Управление трафиком
уровня позволяет точно управлять используемой трафиком полосой пропускания та-
кими методами, которые на данный момент невозможно применить, изменяя метри-
ки маршрутов на сетевом уровне.
В больших полносвязных сетях затраты на поддержание инфраструктуры очень
высоки. Для таких сетей также присуща проблема масштабируемости использующего-
ся протокола маршрутизации внутреннего шлюза, например OSPF или IS-IS, так как
стандартный механизм лавинообразного распространения информации о маршрутах
неэффективен в больших полносвязанных окружениях.
Маршрутизация на основе резервирования
ресурсов (RRR)
Такие протоколы маршрутизации, как OSPF и IS-IS, продвигают трафик с помощью
информации о топологии сети и метриках каналов. В дополнение к информации, пре-
доставляемой протоколом маршрутизации, механизм RRR передает IP-пакет с учетом
класса трафика, требования к обслуживанию и наличия доступных сетевых ресурсов.
На рис. 10.2 показаны два пути от Сан-Франциско до Нью-Йорка через сеть по-
ставщика услуг: один — через Даллас, а другой — через Чикаго.
Рис. 10.2. ТЕ-туннель от маршрутизатора в Сан-
Франциско к маршрутизатору в Нью-Йорке
Поставщик услуг заметил, что трафик от Сан-Франциско до Нью-Йорка обычно
передается по пути Сан-Франциско^Чикаго1^Нью-Йорк. Однако в определенное
время этот путь становится сильно перегруженным. Было также замечено, что во вре-
мя периода перегрузки пути от Сан-Франциско до Нью-Йорка через Чикаго путь от
Сан-Франциско до Нью-Йорка через Даллас практически не используется. Необхо-
димо отрегулировать движение трафика так, чтобы свободные сетевые ресурсы ис-
пользовались наилучшим образом. В настоящий момент передача трафика между
Сан-Франциско и Нью-Йорком является крайне неоптимальной, так как в опреде-
ленное время сеть не может использовать альтернативный путь между этими двумя
узлами. Подобный сценарий является типичным примером применения механизма
управления трафиком (ТЕ). Более детально работа механизма ТЕ в сети MPLS рас-
сматривается в практическом примере 10.1.
После небольшого анализа трафика, становится ясно, что если весь трафик,
который направляется из Сан-Франциско в Нью-Йорк, во время периода пере-
Глава 10. Управление трафиком в сетях MPLS
279
грузки будет передаваться по пути через Даллас, а не через Чикаго, то оба пути
будут использоваться наиболее оптимально. Следовательно, между Сан-
Франциско и Нью-Йорком устанавливается ТЕ-туннель. Он называется туннелем,
потому что путь, по которому идет трафик, определяется на маршрутизаторе в
Сан-Франциско, а не является результатом поэтапного принятия решения о вы-
боре маршрута. В обычных условиях туннель проходит через Чикаго. Однако во
время перегрузки в Чикаго ТЕ-путь меняется на путь через Даллас. Таким обра-
зом, в результате применения механизма ТЕ осуществляется оптимальное исполь-
зование свободных сетевых ресурсов и, в то же время, обход точек перегрузки.
Механизм ТЕ может быть настроен таким образом, что ТЕ-путь будет опять из-
менен на путь через Чикаго после того, как освободится достаточное количество
сетевых ресурсов.
Механизм RRR ТЕ предполагает определение транка трафика, требований к ресур-
сам, политики туннеля, а также способа вычисления или спецификации явного пути,
по которому будет прокладываться ТЕ-туннель. В нашем примере транком трафика
является трафик, идущий от Сан-Франциско в Нью-Йорк, требования к ресурсам —
это полоса пропускания ТЕ-туннеля и другие политики, а явный путь — это путь от
Сан-Франциско в Нью-Йорк через Даллас.
Операционная модель работы механизма RRR показана на рис. 10.3. Здесь изо-
бражены различные рабочие блоки механизма ТЕ в форме блок-схемы. В следующем
разделе каждая из приведенных функций будет рассмотрена более подробно.
Примечание
Перед внедрением механизма ТЕ в сети очень важно создать профили шаблонов по-
токов трафика и собрать статистику в нескольких точках сети. Это можно сделать с
помощью автономных средств и методов, не рассматриваемых в данной книге. В ре-
зультате вы должны получить модель трафика с максимальным использованием ре-
сурсов сети.
Определение ТЕ-транка
ТЕ-транк (ТЕ trunk) определяет класс пакетов, передающихся по ТЕ-туннелю.
Это локальная политика для головного маршрутизатора, инициирующего созда-
ние ТЕ-туннеля.
Как уже упоминалось в главе 3, “Формирование трафика на границе сети:
классификация пакетов, маркировка пакетов и управление интенсивностью трафика”,
класс трафика определяется по заголовкам протоколов TCP/IP (Transmission Control
Protocol/Internet Protocol — протокол управления передачей/1мегпе1-протокол). Класс
трафика может основываться на одном параметре, например на IP-адресе точки на-
значения или MPLS-поле класса обслуживания (Class of Service — CoS), а также на
нескольких параметрах, примером чему может служить класс FTP-трафика, передаю-
щегося от заданного отправителя к заданному получателю. В соответствии с механиз-
мом RRR все пакеты трафика одного класса передаются через сеть по специально
указанному или динамически определенному пути. Именно поэтому классы RRR-
трафика также называют транками трафика (traffic trunks).
280
Часть III. Управление трафиком
Рис. 10.3. Операционная модель работы механизма ТЕ
Атрибуты ТЕ-туннеля
ТЕ-туннель имеет определенные атрибуты, описывающие требования транка тра-
фика, от которых зависит выбор административных политик. Атрибуты туннеля рас-
сматриваются далее в этой главе.
Глава 10. Управление трафиком в сетях MPLS
281
Полоса пропускания
Атрибут полосы пропускания (bandwidth) определяет сквозную полосу пропускания,
необходимую для ТЕ-туннеля. Ее выбор основан на требованиях класса трафика, ко-
торый передается по ТЕ-туннелю.
Приоритет установки и удержания
Приоритеты установки (setup priority) и удержания (holding priority) используются
при управлении доступом. Приоритет установки определяет приоритет ресурса.
Когда ресурсы находятся в состоянии конфликта (contention), новый туннель с вы-
соким приоритетом получения ресурса может вне очереди занять свободный ресурс,
вытесняя при этом все установленные туннели в пути, приоритет удержания которых
меньше приоритета получения ресурса нового туннеля. Установленный ТЕ-туннель с
наивысшим приоритетом удержания не может быть вытеснен.
В табл. 10.1 показаны следствия установки низких и высоких значений приорите-
тов получения и удержания ресурса для ТЕ-туннеля.
Таблица 10.1. Следствия установки низких и высоких значений приоритетов]
получения и удержания ресурса для ТЕ-туннеля ? .
Высоксэ значение Низкое значение
Приоритет получения ресурса Часто приводит к вытеснению уста-
новленных ТЕ-туннелей
(вытесняющий (preemptor) туннель)
Приоритет удержания ресурса Редко может быть вытеснен только
что установленным ТЕ-туннелем
(невытесняемый (nonpreemptable)
туннель)
Редко приводит к вытеснению установ-
ленных ТЕ-туннелей (невытесняющий
(nonpreemptor) туннель)
Часто может быть вытеснен только
что установленным ТЕ-туннелем
(вытесняемый (preemptable) туннель)
Родственность класса ресурса
Атрибут родственности класса ресурса (resource class affinity) предоставляет возмож-
ность ограничивать выбор пути административным включением в сеть определенных
каналов или исключением их из сети. Атрибут родственности класса ресурса состоит
из 32-битового атрибута родственности ресурса и 32-битовой маски класса ресурса.
Атрибут родственности ресурса (resource affinity) указывает на необходимость включе-
ния в процесс расчета пути определенного канала или его исключения из процесса.
Каждый канал имеет атрибут класса ресурса, равный по умолчанию 0x00000000 (если
он не определен явным образом). Маска класса ресурса (resource class mask.) использу-
ется для выделения нужного набора битов атрибута класса ресурса канала. Класс ре-
сурса, маска класса ресурса и атрибут родственности класса ресурса соотносятся друг с
другом следующим образом.
Класс ресурса & маска класса ресурса == родственность класса ресурса,
где обозначает побитовую операцию логического И, а “==” —побитовое ло-
гическое равенство.
В табл. 10.2 приведена политика включения или исключения канала из процесса
определения пути для ТЕ-туннеля на базе атрибутов ресурсов.
282
Часть III. Управление трафиком
\ Таблица 10.2. Политика включения или исключения канала из процесса # • ;
I „ - . I : / ... определения пути для ТЕ-туннеля . ч J
Атрибут класса ресурса канала Атрибут родственности класса ресурса ТЕ-туннеля Политика включения канала в возможный путь ТЕ-туннеля или исключения канала из него
Маска класса Атрибут ресурса родственности ресурса
1 0 1 или 0 1 1 1 0 0 0 Явное включение Явное исключение Никаких действий не предпринимается
Порядок выбора пути
Атрибут порядка выбора пути (path selection order) определяет порядок, в котором
пограничный маршрутизатор выбирает явные пути для ТЕ-туннелей. Явный путь
(explicit path) — это исходный маршрут, представляющий собой последовательность
IP-адресов, заданную административным способом либо динамически вычисленную
на основе кратчайшего пути с учетом различных ограничений. В атрибуте порядка
выбора пути указывается порядок, в котором административно заданный или динами-
чески полученный путь используется для установки ТЕ-туннеля.
Адаптируемость
В атрибуте адаптируемости (adaptability) определяется, нужно ли повторно оптими-
зировать существующий ТЕ-туннель в случае, если появился лучший путь. Повторная
оптимизация обсуждается далее в этой главе.
Устойчивость
В атрибуте устойчивости (resilience) определяется желаемое поведение системы в
случае прекращения существования текущего пути ТЕ-туннеля. Это обычно происхо-
дит из-за сбоев в сети или вытеснения туннеля. Восстановление ТЕ-туннеля в указан-
ном случае рассматривается далее в этой главе.
Атрибуты ресурсов канала
Все каналы в RRR-сети описываются атрибутами, в которых содержится инфор-
мация о свободных ресурсах и о политиках использования канала для вычисления
RRR-пути.
Доступная полоса пропускания
В атрибуте доступной полосы пропускания (available bandwidth) указывается ширина
свободной полосы пропускания для каждого приоритета получения ресурса. Доступ-
ная полоса пропускания в действительности может и не существовать. Так, в опреде-
ленных ситуациях сетевой оператор завышает пропускную способность канала, задав
ей значение, большее, чем реальная ширина полосы пропускания.
Глава 10. Управление трафиком в сетях MPLS
283
Примечание
Свободная полоса пропускания для большего значения приоритета получения ресур-
са всегда должна превышать значение, используемое для меньшего значения при-
оритета получения ресурса или быть равной ему.
Класс ресурса
Атрибут класса ресурса (resource class) “окрашивает” канал. Как было сказано ранее
в этой главе, решение о включении канала в процесс вычисления пути или об исклю-
чении канала из него основывается на атрибуте класса ресурса канала и на атрибуте
родственности класса туннеля.
Распространение информации
о ресурсах канала
Важным требованием для -введения в действие механизма управления трафиком
является распространение локальной информации о ресурсах каналов по RRR-сети.
Атрибуты ресурсов канала лавинообразно распространяются по сети с помощью рас-
ширений таких протоколов маршрутизации состояния канала, как OSPF и IS-IS.
Существующий протокол маршрутизации канального уровня лавинообразно рас-
пространяет информацию о метрике и топологии сети по всем каналам, для того что-
бы обеспечить вычисление кратчайшего пути до точки назначения. В RRR-сети ис-
пользуется расширенный протокол маршрутизации, который вместе с информацией о
метрике распространяет по каждому каналу атрибуты ресурсов.
Лавинообразное распространение атрибутов ресурсов происходит независимо от рас-
пространения информации о метрике и предпринимается только тогда, когда изменяется
состояние канала или класс ресурса канала, а также когда ширина свободной полосы про-
пускания превысила заранее сконфигурированное пороговое значение.
Политика выбора пути
ТЕ-путь должен учитывать как ограничения канала, так и требования ТЕ-туннеля.
При вычислении ТЕ-пути производятся такие действия.
Шаг 1. Рассматриваются следующие атрибуты и информация:
• атрибуты ТЕ-туннеля, установленные головным маршрутизатором, соз-
дающим этот туннель;
• атрибуты ресурсов каналов всей сети, которые распространяются с помо-
щью протокола внутреннего шлюза;
• информация о топологии сети, которая распространяется с помощью про-
токола внутреннего шлюза;
• если производится повторная оптимизация ТЕ-туннеля, то рассматрива-
ется его текущий путь.
Шаг 2. Удаляются каналы с недостаточной пропускной способностью или несоот-
ветствующие политике ресурсов.
284
Часть III. Управление трафиком
Шаг 3. После удаления всех нерассматриваемых каналов, запускается отдельная
копия алгоритма выбора кратчайшего пути (Shortest Path First — SPF) для
вычисления кратчайшего (с наименьшей метрикой) пути из базы состоя-
ний каналов протокола внутреннего шлюза.
Копия алгоритма SPF запускается специально для вычисления ТЕ-пути, и
она отличается от копии алгоритма, которая используется маршрутизато-
ром для построения своей таблицы маршрутизации на основе базы состоя-
ний каналов.
Явный путь для ТЕ-туннеля вычисляется с помощью алгоритма SPF. Вычислен-
ный явный путь представляется как последовательность, состоящая из IP-адресов
маршрутизаторов. После запроса на установление ТЕ-туннеля последний создается с
использованием явного пути на основе атрибута порядка выбора.
Установка ТЕ-туннеля
Для сигнализации ТЕ-туннеля2 используется протокол ТЕ-RSVP. В нем применя-
ются те же RSVP-сообщения, что и в обычном сигнальном протоколе, но с неболь-
шими изменениями и расширениями, необходимыми для поддержки нового способа
применения протокола. Протокол ТЕ-RSVP помогает создать явно маршрутизируе-
мый LSP-путь для установки ТЕ-туннеля.
В протокол ТЕ-RSVP добавлены две важные функциональные возможности, кото-
рые позволяют ему создавать явно маршрутизируемый LSP-путь (Explicitly Routed La-
bel Switched Path — ER-LSP): метод привязки меток к RSVP-потокам и функция яв-
ной маршрутизации RSVP-сообщений. В ТЕ-туннеле, построенном на основе ER-
LSP-пути, единственным отправителем является первый узел в LSP-пути, а единст-
венным получателем — последний узел. Все промежуточные узлы в LSP-пути произ-
водят обычную коммутацию меток на основе входящей метки. Первый узел в LSP-
пути инициирует создание ER-LSP-пути. Этот узел иногда называют головным мар-
шрутизатором (head-end router).
Головной маршрутизатор инициирует установку ТЕ-туннеля, отправляя сообщение
RSVP PATH по IP-адресу точки назначения туннеля с объектом SRO (Source Route
Object — объект исходного маршрута), определяющим явный маршрут. В объекте SRO
находится список IP-адресов и указателей, определяющих следующую точку назначе-
ния в списке. Все узлы в сети передают РАТН-сообщение по адресу следующей точки
назначения, указанному в объекте SRO. Кроме этого, они добавляют объект SRO в
свой блок состояния пути. Когда устройство в точке назначения получает РАТН-
сообщение, оно определяет, что ему необходимо установить ER-LSP-путь на основе
объекта запроса метки (Label Request Object — LRO), который находится в РАТН-
сообщении и генерирует RSVP-сообщение запроса на резервирование ресурсов для
сеанса (RESV). В сообщении RSVP RESV, которое передается отправителю, устройст-
во размещает созданную им метку и отправляет ее как объект LABEL. Узел, получив-
ший RESV-сообщение, использует метку для отправки всего трафика по этому пути.
Он также создает новую метку и отправляет ее как объект LABEL в сообщении RSVP
RESV следующему узлу по направлению к отправителю. Именно эту метку узел рас-
считывает получить вместе со всем трафиком, поступающим по этому пути.
2 Extensions to RESPfor LSP Tunnels/Awduche D. et al., draft-ietf-mpls-rsvp-lsp-tunnel-04.txt.
Глава 10. Управление трафиком в сетях MPLS
285
Примечание
Сообщение RSVP RESV следует по пути, прямо противоположному пути, по которому
шло сообщение RSVP PATH. Это связано с тем, что объект SRO в блоке состояния
пути (установленный в каждом узле РАТН-сообщением) определяет способ передачи
сообщения RSVP RESV вверх по направлению движения потока трафика.
После того как путь ER-LSP сформирован, устанавливается ТЕ-туннель. Следует заме-
тить, что если трафик доставляется без гарантий, то резервирование ресурсов производить
необязательно. Для того чтобы распределить ресурсы на ER-LSP-пути, используются
обычные RSVP-объекты Tspec и Rspec. Tspec-объект отправителя, содержащийся в РАТН-
сообщении, используется для определения трафика, который передается по этому пути.
Точка назначения сообщения RSVP PATH использует эту информацию для создания со-
ответствующих объектов Tspec и Rspec получателя, которые используются при распределе-
нии ресурсов на каждом узле ER-LSP-пути.
Управление доступом к каналу
Система управления доступом к каналу решает, какому из ТЕ-туннелей следует
предоставить ресурсы. Она предполагает наличие следующих функций.
• Определение наличия ресурсов. Система определяет, есть ли свободные ресурсы.
• Уничтожение туннеля. Система должна уничтожить существующие туннели,
когда новые туннели с высоким приоритетом получения ресурсов вытесняют
существующие туннели с низким приоритетом удержания ресурсов.
• Ведение локального учета использования ресурсов. Система следит за использо-
ванием ресурсов.
• Инициирование обновления информации о маршрутах протокола внутреннего шлюза.
Система инициирует процесс лавинообразного распространения обновления ин-
формации о маршрутах протокола внутреннего шлюза, когда из статистики локаль-
ного учета использования ресурсов следует, что количество доступных ресурсов мо-
жет опуститься ниже сконфигурированного порогового значения.
Поддержка ТЕ-пути
Поддержка ТЕ-пути включает выполнение таких функций, как повторная оптими-
зация пути и его восстановление. Эти операции выполняются после установки ТЕ-
туннеля. Повторная оптимизация пути (path reoptimization) описывает желаемое пове-
дение маршрутизатора в случае появления после установки ТЕ-пути его потенциально
лучшего преемника. Во время повторной оптимизации пути маршрутизатор должен
попытаться найти какую-нибудь возможность для того, чтобы заново оптимизировать
существующий ТЕ-путь. Необходимость применения функции повторной оптимиза-
ции пути указывается в атрибуте адаптируемости.
Восстановление пути (path restoration) описывает метод восстановления ТЕ-туннеля
в случае, если текущий путь перестал функционировать, используя для этого атрибут
устойчивости.
286
Часть III. Управление трафиком
Сигнальный протокол TE-RSVP
Протокол ТЕ-RSVP — это расширение существующего протокола RSVP с под-
держкой сигнализации LSP-пути. Протокол ТЕ-RSVP использует сигнальные сооб-
щения протокола RSVP, добавляя определенные расширения для поддержки меха-
низма управления трафиком. Ниже перечислены некоторые важные расширения про-
токола ТЕ-RSVP.
• Поддержка резервирования меток. Для того чтобы использовать RSVP при сиг-
нализации LSP-туннеля, этот протокол должен поддерживать резервирование и
установку меток. В отличие от обычных RSVP-потоков, протокол ТЕ-RSVP ис-
пользует RSVP с целью резервирования меток для потоков без резервирования
полосы пропускания. Для этого был определен новый тип объекта FlowSpec.
Кроме того, протокол ТЕ-RSVP резервирует также метки для потоков.
• Поддержка маршрутизации от источника. В LSP-туннелях используется явная
маршрутизация от источника. Явная маршрутизация от источника реализована
в протоколе RSVP путем добавления нового объекта — SRO.
• Поддержка RSVP-узлов. В отличие от протокола RSVP, в котором сообщения
RSVP PATH и RSVP RESV создаются приложениями на конечных узлах, в про-
токоле ТЕ-RSVP сообщения RSVP PATH и RSVP RESV инициируются голов-
ными маршрутизаторами.
Следовательно, протокол ТЕ-RSVP требует поддержки маршрутизаторами эму-
ляции RSVP-узлов.
• Поддержка идентификации туннеля, созданного на базе ER-LSP-пути. Для пере-
дачи идентификатора туннеля используются новые типы объектов Filter_Spec и
Sender_Template. Объекту Session также разрешается переносить номер IP-
протокола null, так как по LSP-туннелю, вероятнее всего, будут передаваться
IP-пакеты со многими другими номерами протокола.
• Поддержка нового алгоритма удаления резервирования. Добавлено новое RSVP-
сообшение, RESV TearConfirm. Это сообщение добавляется для гарантирован-
ного удаления ТЕ-туннеля.
Краткий список RSVP-объектов, которые были добавлены или модифицированы с
целью поддержки механизма ТЕ, приведены в табл. 10.3.
> Таблица 10.3. Новые или модифицированные RSVP-объекты, ‘
j необходимые для поддержки механизма управления
{ трафиком, и их функции
RSVP-объект RSVP-сообщение Назначение
Label RESV Используется при распространении меток
Label_Request PATH Используется для запроса разрешения на назначение метки
Source_Route PATH Определяет явный маршрут от источника
Record_Route PATH, RESV Используется при диагностике — позволяет записать путь, по которому прошло RSVP-сообщение
Session_Attribute PATH Определяет приоритет удержания и получения ресурса
Session PATH Может переносить номер IP-протокола null
Глава 10. Управление трафиком в сетях MPLS
287
Окончание табл. 10.3
RSVP-объект RSVP-сообщение Назначение
Sender_Template PATH Объекты Sender_Template и
Filter_Spec RESV Filter_Spec могут переносить идентификатор туннеля, что по- зволяет определить ER-LSP-путь
Расширения протокола маршрутизации
внутреннего шлюза
Протоколы маршрутизации внутреннего шлюза OSPF и IS-IS были расширены для
распространения атрибутов ресурсов канала вместе с информацией об 1Р-достижимости
сетевого уровня. Для передачи информации о ресурсах канала протокол IS-IS использует
новый кортеж, состоящий из поля типа (Туре), длины (Length) и значения (Value) и обыч-
но известный как кортеж TVL3, а протокол OSPF — непрозрачное извещение о состоянии
канала (Opaque Link State Advertisement — LSA)4. Следует отметить, что существующая
функциональность протоколов OSPF и IS-IS осталась прежней, только теперь эти прото-
колы отправляют информацию о текущих ограничениях каждый раз, когда им необходимо
распространить информацию об IP-достижимости. Механизм управления доступом к ТЕ-
каналу маршрутизатора требует повторного распространения информации об ограничени-
ях всякий раз, когда он замечает существенные изменения в информации о доступных ре-
сурсах, основываясь на сконфигурированных пороговых значениях.
Модификации протокола IS-IS
Кортеж TLV, определяющий IS-достижимость, расширен для передачи информа-
ции о ресурсах канала. Расширенный кортеж TLV называется кортежем TLV типа 22.
Внутри этого кортежа используются различные подкортежи TLV, предназначенные
для передачи атрибутов канала с целью поддержки механизма управления трафиком.
Модификации протокола OSPF
Поскольку базовое LSA-объявление маршрутизатора протокола OSPF является не-
расширяемым, для поддержки механизма управления трафиком используется непро-
зрачное LSA-объявление5. Существует три типа непрозрачного LSA-объявления, каждое
из которых характеризуется своей собственной областью лавинообразного распростра-
нения. OSPF-расширения для обеспечения поддержки механизма ТЕ используют только
LSA-объявления типа 10, распространение которых ограничено одной областью.
Новый тип непрозрачного LSA-объявления (тип 10), обеспечивающего поддержку ме-
ханизма ТЕ, называется объявлением ТЕ LSA. В этом LSA-объявлении описываются мар-
шрутизаторы и двухточечные каналы (так же, как в объявлении LSA маршрутизатора). Для
описания каналов с множественным доступом хватает существующего объявления LSA се-
ти, а поэтому для этой цели не было определено никаких дополнительных LSA-
обьявлений.
3 IS-IS Extensions for Traffic Engineering/Smit IL, Li T, draft-ietf-isis-traffic-OO.txt.
4 Traffic Engineering Extensions to OSPF/Katz D., Yueng D., draft-katz-yeung-ospf-traffic-OO.txt.
5 The OSPF Opaque LSA Option/Coltun R., RFC 2370, July 1998.
288
Часть III. Управление трафиком
Подходы к реализации механизма управления
трафиком
Пример, рассмотренный в начале этой главы, является типичным подходом к реа-
лизации механизма ТЕ, в соответствии с которым управление трафиком сводится к
обходу точек перегрузки сети. Следует отметить, что ограничение механизма ТЕ до
переключения между несколькими маршрутами может не оправдать себя в том случае,
если остальной трафик в сети будет передаваться без участия механизма ТЕ.
Широко рекомендуемым подходом является использование полносвязной структу-
ры из созданных на основе LSP-путей ТЕ-туннелей между всеми пограничными мар-
шрутизаторами в сети поставщика услуг. Как правило, этими пограничными маршру-
тизаторами являются либо РОР-марщрутизаторы (Point of Presence — точка присутст-
вия), либо маршрутизаторы, соединенные с сетями других поставщиков услуг.
Практический пример 10.1: установка
и функционирование ТЕ-туннеля в MPLS-сети
В сети, схематически показанной на рис. 10.4, устанавливается MPLS ТЕ-туннель от
Сан-Франциско до Нью-Йорка на базе явного пути и динамически определяемого резерв-
ного пути. Укажите конфигурацию, необходимую для установки такого туннеля, для всех
маршрутизаторов сети. Исследуйте, что произойдет, если один из каналов явного пути
выйдет из строя. И, наконец, изучите процесс восстановления пути ТЕ-туннеля в случае,
когда установленный динамический путь прекратит функционирование.
222.222.222,2
Чикаго
222.222.222.1
Сан-Франциско
POS0/0
222.222.222.8/30
POS8/0
25
POSO/3
222.222.222.24/30
17
POS9/2
28
POSO/1
222.222.222.20/30
POS5/1
21
222.222.222.3
Нью-Йорк
Даллас
222.222.222.4
Рис. 10.4. MPLS ТЕ-туннель от маршрутизатора Сан-Франциско до маршрутизатора Нью-Йорка
POS5/3
222.222.222.16/30
POS9/0
14
POS8/2
222.222.222.12/30
POS9/1
Обсудите функционирование ТЕ-туннеля и ТЕ-расширений протоколов IS-IS и
RSVP на основе различных show- и debug-команд маршрутизатора.
Глава 10. Управление трафиком в сетях MPLS
289
Все четыре маршрутизатора сконфигурированы согласно адресной схеме и схеме со-
единений, показанным на рис. 10.4. В качестве протокола внутреннего шлюза использо-
вался встроенный протокол IS-IS. Он настроен на использование 32-битовых значений
метрики, в отличие от обычных 6-битовых значений. IP-адрес интерфейса loopbackO ис-
пользуется в качестве идентификатора маршрутизатора для механизма MPLS ТЕ.
Для активизации механизма MPLS ТЕ необходимо выполнить команду mpls traffic-
eng tunnels на глобальном и интерфейсном уровнях. Для RSVP-сигнализации и уста-
новки ТЕ-туннелей на всех интерфейсах должен использоваться протокол RSVP.
RSVP выполняет две главные задачи: распространяет метки для установки LSP-пути
вдоль явного пути туннеля и производит необходимое резервирование полосы про-
пускания на LSP-пути. На интерфейсах используется взвешенный механизм равно-
мерного обслуживания очередей (Weighted Fair Queuing — WFQ), поскольку он нужен
протоколу RSVP для предоставления гарантированной полосы пропускания.
Маршрутизатор Сан-Франциско инициирует создание ТЕ-туннеля до маршрутиза-
тора Нью-Йорка. С этой целью конфигурируется интерфейс tunnelO. Режим работы
туннеля устанавливается с помощью команды tunnel mode mpls traffic-eng. Вдоль всего
пути туннеля производится запрос на резервирование полосы пропускания шириной
10 Кбит/с. Приоритет получения и удержания ресурсов для туннеля устанавливается в
наивысшее значение — 7.
Явный путь ТЕ-туннеля через маршрутизатор Чикаго определяется как явный путь
sfny. Значение параметра path-option, равное 1, используется для указания того, что
явно определенный путь является предпочтительным путем для установки ТЕ-
туннеля. Динамически определяемый ТЕ-путь объявляется резервным. Обратите вни-
мание, что параметр path-option задает порядок выбора пути для ТЕ-туннеля.
В листингах 10.1-10.4 приведена необходимая конфигурация для каждого маршру-
тизатора. Отметьте, что в листингах показана только конфигурация, относящаяся к
протоколу MPLS, т.е. без какой-либо посторонней информации.
i Листинг 10.1. Конфигурация маршрутизатора Сан-Франциско
ip cef
clns routing
mpls traffic-eng tunnels
!
i
i
interface LoopbackO
ip address 222.222.222.1 255.255.255.255
ip router isis isp
।
interface TunnelO
ip unnumbered LoopbackO
tunnel destination 222.222.222.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 10
tunnel mpls traffic-eng path-option 1 explicit name sfny
290
Часть III. Управление трафиком
tunnel mpls traffic-eng path-option 2 dynamic
tunnel mpls traffic-eng record-route
।
।
interface POS5/1
ip address 222.222.222.21 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface POS5/3
ip address 222.222.222.17 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
router isis isp
net 50.0000.0000.0000.0001.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level 1
।
ip explicit-path name sfny enable
next-address 222.222.222.22
next-address 222.222.222.9
[ Листинг 10.2. Конфигурация маршрутизатора Чикаго
ip cef
clns routing
mpls traffic-eng tunnels
।
i
interface LoopbackO
ip address 222.222.222.2 255.255.255.255
ip router isis isp
i
interface POS0/0
ip address 222.222.222.10 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 468
ip rsvp bandwidth 1158 1158
i
interface POSO/1
Глава 10. Управление трафиком в сетях MPLS
291
ip address 222.222.222.22 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface POSO/3
ip address 222.222.222.25 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
I
router isis isp
net 50.0000.0000.0000.0002.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
Листинг 10.3. Конфигурация маршрутизатора Нью-Йорка .....
interface LoopbackO
ip address 222.222.222.3 255.255.255.255
ip router isis isp
I
interface POS8/0
ip address 222.222.222.9 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface POS8/2
ip address 222.222.222.14 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
router isis isp
net 50.0000.0000.0000.0003.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
292
Часть III. Управление трафиком
| ЛистинМО.4. Конфигурациямаршрут^атора^лла^аК
clns routing
mpls traffic-eng tunnels
i
interface LoopbackO
ip address 222.222.222.4 255.255.255.255
ip router isis isp
interface POS9/0
ip address 222.222.222.18 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface POS9/1
ip address 222.222.222.13 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
interface POS9/2
ip address 222.222.222.26 255.255.255.252
ip router isis isp
mpls traffic-eng tunnels
fair-queue 64 256 36
ip rsvp bandwidth 1158 1158
i
router isis isp
net 50.0000.0000.0000.0004.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
После активизирования предыдущих конфигураций на соответствующих маршру-
тизаторах проверьте состояние ТЕ-туннеля с помощью команды show mpls traffic-eng
tunnel tunnelO. В листинге 10.5 показан результат выполнения этой команды. На экран
выводится состояние туннеля и вариант пути, который использовался при его уста-
новке. Кроме того, показывается конфигурация туннеля и сигнальная информация
протокола RSVP.
Как можно видеть, туннель был установлен с помощью указанного пользователем
явного пути, который проходит через Чикаго. Сигнальная информация RSVP свиде-
тельствует о том, что для отправки пакетов по пути туннеля используется метка 26 и
выходной интерфейс POS5/1. Так как была использована функция записи маршрута
(команда tunnel mpls traffic-eng record-route), в сообщении RSVP RESV был записан
маршрут, по которому проложен туннель.
Глава 10. Управление трафиком в сетях MPLS
293
| Листинг 10.5. Результат выполнения команды showmpls traffic-eng tunnel I
tunnelO при условии прохождения туннеля
по административно заданному явному пути
SanFranciscojsh mpls tr tun tO
Name: SanFrancisco_tO (TunnelO)
^Destination: 222.222.222.3
Status:
Admin: up Oper: up Path: valid
^Signalling: connected
path option 1, type explicit sfny (Basis for Setup,
1>path weight 20)
path option 2, type dynamic
Config Paramters:
Bandwidth: 10 Priority: 7 7 Affinity: OxO/OxFFFF
AutoRoute: enabled LockDown: disabled
InLabel : -
OutLabel : P0S5/1, 26
RSVP Signalling Info:
Src 222.222.222.1, Dst 222.222.222.3, Tun_Id 0,
1>Tun_Instance 1
RSVP Path Info:
My Address: 222.222.222.1
Explicit Route: 222.222.222.22 222.222.222.9
Record Route:
Tspec: ave rate=10 kbits, burst=1000 bytes,
^peak rate=10 kbits
RSVP Resv Info:
Record Route: 222.222.222.9 222.222.222.22
Fspec: ave rate=10 kbits, burst=1000 bytes, peak rate=Inf
Предположим, что после того как туннель начал функционировать, канал от Чикаго до
Нью-Йорка вышел из строя. Канал Чикаго-Нью-Йорк можно сделать неработоспособ-
ным, либо просто программно отключив канал, либо изменив его локальный атрибут
класса ресурса. В этом примере атрибут класса ресурса для канала Чикаго-Нью-Йорк был
изменен на 0x1. Следовательно, побитовая логическая операция И, выполненная по отно-
шению к классу ресурса канала (0x1) и маске класса ресурса туннеля (OxOOOOFFFF), логи-
чески не эквивалентна значению родственности ресурса туннеля (0x0000). Следовательно,
канал Чикаго-Нью-Йорк не может быть включен в путь туннеля.
Атрибут класса ресурса канала Чикаго-Нью-Йорк был изменен на 0x1 с помощью
команды mpls traffic-eng attribute-flag 0x1, выполненной на интерфейсе POS0/0 мар-
шрутизатора Чикаго.
Такая локальная смена атрибута на маршрутизаторе Чикаго делает явный путь непри-
годным для использования, поскольку он не пройдет тест на родственность ресурсов.
294
Часть III. Управление трафиком
Следовательно, ТЕ-туннель должен быть проложен по динамически выбираемому
пути. После выбора динамического пути маршрутизатор удаляет канал Чикаго-Нью-
Йорк из топологии сети, пользуясь своей локальной политикой ресурсов канала.
Маршрутизатор повторно рассчитывает путь ТЕ-туннеля через Даллас, запустив для
этого отдельную копию алгоритма SPF.
В листинге 10.6 показан результат выполнения команды show mpls traffic-eng tunnel
tunnelO после того, как туннель был проложен по динамическому пути через маршру-
тизатор Далласа.
I Листинг 10.6. Результат выполнения команды show mpls traffic-eng tunnel
i : tunnelO после того, как туннель был проложен
по динамическому пути через маршрутизатор Далласа
SanFranciscofsh mpls tr tun tO
Name: SanFrancisco_tO (TunnelO)
^Destination: 222.222.222.3
Status:
Admin: up Oper: up Path: valid
^Signalling: connected
path option 2, type dynamic (Basis for Setup,
1>path weight 20)
path option 1, type explicit sfny
Config Paramters:
Bandwidth: 10 Priority: 7 7 Affinity: OxO/OxFFFF
AutoRoute: enabled LockDown: disabled
InLabel : -
OutLabel : POS5/3, 26
RSVP Signalling Info:
Src 222.222.222.1, Dst 222.222.222.3, Tun_Id 0,
1>Tun_Instance 2
RSVP Path Info:
My Address: 222.222.222.1
Explicit Route: 222.222.222.18 222.222.222.14 222.222.222.3
Record Route:
Tspec: ave rate=10 kbits, burst=1000 bytes,
1>peak rate=10 kbits
RSVP Resv Info:
Record Route: 222.222.222.14 222.222.222.18
Fspec: ave rate=10 kbits, burst=1000 bytes, peak rate=Inf
Предположим, что после того как путь через Чикаго был установлен, канал, входящий
в путь туннеля, снова стал непригодным для использования. Локальный атрибут ресурса
канала Сан-Франциско-Даллас был изменен на 0x1, делая невозможным использование
существующего ТЕ-пути. Поэтому, учитывая новые локальные атрибуты ресурса канала,
Глава 10. Управление трафиком в сетях MPLS
295
маршрутизатор Сан-Франциско выбирает ТЕ-пугь через маршрутизаторы Чикаго и Далла-
са для того, чтобы обеспечить достижимость маршрутизатора Нью-Йорка.
В листинге 10.7 показан результат выполнения команды show mpls traffic-eng tunnel
tunnelO после того, как туннель был проложен по динамическому пути через маршру-
тизаторы Чикаго и Далласа до маршрутизатора Нью-Йорка
< Листинг.10.7. Результатвыпол нения команды show mpls traffic-eng tunnel
? funne/O на маршрутизаторе Сан-Франциско после того, ’
туннель был проложен по динамическому пути через
маршрутизаторыЧикаго и Далласа до маршр^изатора'
’ НЬю-Йорка ’W--< '
SanFranciscoDsh mpls traffic-eng tunnel tO
Name: SanFrancisco_tO (TunnelO)
^Destination: 222.222.222.3
Status:
Admin: up Oper: up Path: valid
^Signalling: connected
path option 2, type dynamic (Basis for Setup,
'bpath weight 30)
path option 1, type explicit sfny
Config Paramters:
Bandwidth: 10 Priority: 7 7 Affinity: 0x0/0xFFFF
AutoRoute: enabled LockDown: disabled
InLabel : -
OutLabel : POS5/0, 26
RSVP Signalling Info:
Src 222.222.222.1, Dst 222.222.222.3, Tun_Id 0,
tbTun_Instance 2
RSVP Path Info:
My Address: 222.222.222.1
Explicit Route: 222.222.222.22 222.222.222.26
^222.222.222.14 222.222.222.3
Record Route:
Tspec: ave rate=10 kbits, burst=1000 bytes,
^peak rate=10 kbits
RSVP Resv Info:
Record Route: 222.222.222.14 222.222.222.26 222.222.222.22
Fspec: ave rate=10 kbits, burst=1000 bytes, peak rate=Inf
SanFrancisco#
Из результата выполнения предыдущей команды видно, что путь ТЕ-туннеля до
Нью-Йорка установлен через маршрутизаторы Чикаго и Далласа.
296
Часть III. Управление трафиком
Чтобы больше узнать о том, как работает MPLS ТЕ-туннель, просмотрите
листинг 10.8. В нем показана важная часть результата выполнения команды show
interface tunnel 0. Для проверки установленных ТЕ-туннелей также может быть ис-
пользована команда show isis mpls traffic tunnel. Результат выполнения этой команды
показан в листинге 10.9.
Листинг 10.8. Результатвыполнениякоманды show Interface tunnelO
SanFranciscoish interface tunnel 0
TunnelO is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of LoopbackO
^>(222.222.222.1)
MTU 1496 bytes, BW 9 Kbit, DLY 500000 usee, rely 255/255,
4>load 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec)
Tunnel source 222.222.222.1, destination 222.222.222.3
Tunnel protocol/transport Label Switching, key disabled,
^sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
^Листинг 10.9. 'Результатвыполнения^ом^й^^^^^/вт^^^^ tunnel
SanFrancisco# sh isis mpls traffic-eng tunnel
System Id Tunnel Name Bandwidth Nexthop
Metric Mode
NewYork.OO TunnelO 100000 222.222.222.3
В листингах 10.10 и 10.11 используются команды, которые демонстрируют работу
протокола IS-1S с ТЕ-расширениями. Протокол 1S-IS с ТЕ-расширениями не только
предоставляет информацию о топологии сети и метриках каналов, но также передает
ТЕ-атрибуты всех каналов в сети. В листинге 10.10 показан результат выполнения ко-
манды, показывающей MPLS ТЕ-атрибуты всех каналов с активизированным прото-
колом MPLS на маршрутизаторе Чикаго с идентификатором 222.222.222.2.
Листинг 10.10. Вывод атрибутов'механизма управления трафикрм'для
' > > всех каналов с активизированным npOTOKondM MPLS на' 1
,......,' >.* маршру^ето^^истпр.с идентификатором^22^22^222.2
4c7507=Rl#sh mpls traffic-eng topology 222.222.222.2
IGP Id: 0000.0000.0002.00, MPLS ТЕ Id:222.222.222.2 Router
4>Node, Internal Node_id 3
linkfO ]:Nbr IGP Id: 0000.0000.0004.00, nbr_node_id:2
Intf Address:222.222.222.25, Nbr Intf Address:
4>222.222.222.26
admin_weight:10, affinity_bits:0x0
Глава 10. Управление трафиком в сетях MPLS
297
max link bw:1544 max link reservable: 1158
allocated reservable allocated reservable
--------- — — — — — — — --
bw[0]: 0 1158 bw[l]: 0 1158
bw[2]: 0 1158 bw[3]: 0 1158
bw[4]: 0 1158 bw[5J: 0 1158
bw{6]: 0 1158 bw[7J: 10 1148
link[l ]:Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:l
Intf Address:222.222.222.22, Nbr Intf Address:
^>222.222.222.21
admin_weight:10, affinity bits:0x0
max link bw:1544 max link reservable: 1158
allocated reservable allocated reservable
bw[0]: 0 1158 bw[l]: 0 1158
bw[2]: 0 1158 bw[3]: 0 1158
bw[4]: 0 1158 bw[5]s 0 1158
bw[6): 0 1158 bw[7J: 0 1158
link[2 ]:Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:4
Intf Address:222.222.222.10, Nbr Intf Address:
^>222.222.222.9
admin_weight:10, affinity_bits:Oxl
max_link_bw:1544 max_link_reservable: 1158
allocated reservable allocated reservable
bw[0]: 0 1158 bw[l]: 0 1158
bw[2]: 0 1158 bw[3]: 0 1158
bw[4]: 0 1158 bw[5J: 0 1158
bw[6]: 0 1158 bw[7]: 0 1158
SanFrancisco#
Каждый маршрутизатор, участвующий в процессе управления трафиком, объявляет
свои собственные атрибуты каналов для остальной части сети с помощью IS-IS-
расширений. Для просмотра атрибутов, объявленных маршрутизатором, используется
команда show isis mpls traffic-eng advertise. В листинге 10.11 показан результат выпол-
нения этой команды на маршрутизаторе Сан-Франциско.
? Л истинг10.11. ТЕ-атрибуты, объявленные маршрутизатором Сан-Франциско t
SanFranciscoish isis mpls traffic-eng advertise
System ID: SanFrancisco.OO
Router ID: 222.222.222.1
Link Count: 2
Link[l]
Neighbor System ID: Wl-R2c4500m=R2.00 (broadcast link)
Interface IP address: 222.222.222.21
298
Часть III. Управление трафиком
Neighbor IP Address: 222.222.222.22
Admin. Weight: 10
Physical BW: 1544000 bits/sec
Reservable BW: 1158000 bits/sec
BW unreservedf0]: 1158000 bits/sec, BW unreservedfl]:
^>1158000 bits/sec
BW unreserved!2]: 1158000 bits/sec, BW unreserved[3]:
^>1158000 bits/sec
BW unreserved[4]: 1158000 bits/sec, BW unreserved[5]:
^>1158000 bits/sec
BW unreserved!6]: 1158000 bits/sec, BW unreserved!7]:
4>1148000 bits/sec
Affinity Bits: 0x00000000
Link[2]
Neighbor System ID: Yl-R5c7513=R4.00 (broadcast link)
Interface IP address: 222.222.222.17
Neighbor IP Address: 222.222.222.18
Admin. Weight: 10
Physical BW: 1544000 bits/sec
Reservable BW: 1158000 bits/sec
BW unreserved!0]: 1158000 bits/sec, BW unreservedfl]:
^>1158000 bits/sec
BW unreserved[2]: 1158000 bits/sec, BW unreserved[3]:
1>1158000 bits/sec
BW unreserved[4]: 1158000 bits/sec, BW unreserved[5]:
^>1158000 bits/sec
BW unreserved[6]: 1158000 bits/sec, BW unreserved!7]:
^>1158000 bits/sec
Affinity Bits: 0x00000001
SanFrancisco#
По умолчанию функционирующий ТЕ-туннель не устанавливается в таблицу маршру-
тизации и не объявляется протоколом 1S-1S. Для установки MPLS-туннеля в таблицу
маршрутизации и его объявления с помощью протокола IS-IS используется команда tunnel
mpls tafiic-eng autoroute announce. В листинге 10.12 показан результат выполнения команды
show ip route до и после выполнения команды autoroute announce.
-до И после» установки туннедя^ f {ii
SanFrancisco#show ip route 222.222.222.3
Routing entry for 222.222.222.3/32
Known via "isis", distance 115, metric 30, type level-1
Redistributing via isis
Last update from 222.222.222.22 on POS5/1, 00:02:07 ago
Routing Descriptor Blocks:
* 222.222.222.22, from 222.222.222.3, via POS5/1
Route metric is 30, traffic share count is 1
Глава 10. Управление трафиком в сетях MPLS
299
222.222.222.18, from 222.222.222.3, via POS5/3
Route metric is 30, traffic share count is 1
SanFrancisco(config)#int to
SanFrancisco(config-if)#tunnel mpls traffic-eng
^autoroute announce
SanFranciscofsh ip route 222.222.222.3
Routing entry for 222.222.222.3/32
Known via “isis", distance 115, metric 30, type level-1
Redistributing via isis
Last update from 222.222.222.3 on TunnelO, 00:00:01 ago
Routing Descriptor Blocks:
* 222.222.222.3, from 222.222.222.3, via TunnelO
Route metric is 30, traffic share count is 1
В листинге 10.13 показана информация о пункте назначения туннеля 222.222.222.3,
хранящаяся в таблице механизма скоростной коммутации пакетов Cisco (Cisco Express
Forwarding — CES), полученная с помощью выполнения команды show ip cef
222.222.222.3 internal. Результат выполнения команды включает сведения о метке, на-
значенной трафику, передающемуся в пункт назначения туннеля.
I Листинг 10.13.Информация о пункте назначения туннеля 222.222.222.3 .
ГА” 8''X......A'A. .’."'J
SanFranciscoish ip cef 222.222.222.3 internal
222.222.222.3/32, version 253
0 packets, 0 bytes
has label information: local label: tunnel head
fast label rewrite: TuO, point2point, labels imposed 26
via 222.222.222.3, TunnelO, 0 dependencies
next hop 222.222.222.3, TunnelO
valid adjacency
Протокол RSVP устанавливает метки для создания LSP-пути MPLS-туннеля. В ка-
ждом маршрутизаторе находится таблица продвижения меток, необходимая для ком-
мутации пакетов на основе их входящих меток. В листинге 10.14 показаны таблицы
продвижения меток в маршрутизаторах, распложенных вдоль пути ТЕ-туннеля. Обра-
тите внимание, что маршрутизатор Далласа удаляет MPLS-метку перед отправкой па-
кета в пункт назначения (маршрутизатор Нью-Йорка). Именно поэтому таблица про-
движения меток маршрутизатора Нью-Йорка в этом примере не показана.
Листинг 10.14. Информация, хранящаяся в таблицах продвижения меток j
1 > А Ларшрутизаторов Са№4>ранц^0> ЧвкагС!-иЯалласа^ А 'г I
SanFranciscofsh mpls forwarding-table 222.222.222.3 32 detail
Local Outgoing Prefix Bytes mpls Outgoing
'b Next Hop
label label or VC or Tunnel Id switched interface
300
Часть III. Управление трафиком
Tun hd Unlabeled 222.222.222.3/32 0 TuO
point2point
MAC/Encaps=4/8, MTU=1500, Label Stack{26), via POS5/1
0F008847 OOO1AOOO
Chicago#sh mpls forwarding-table
Local Outgoing Prefix Bytes mpls Outgoing
Next Hop label label or VC or Tunnel Id switched interface
26 30 222.222.222.1 0 [1] o POSO/3
point2point Chicago# Dallas#sh mpls forwarding-table Local Outgoing Prefix Bytes mpls Outgoing
Next Hop label label or VC or Tunnel Id switched interface
30 Pop label 222.222.222.1 0 [1] o P0S9/1
point2point
На рис. 10.5 показан процесс коммутации пакетов на пути ТЕ-туннеля. Маршру-
тизатор Сан-Франциско назначает метку 26 всему трафику, передающемуся в (или че-
рез) пункт назначения туннеля, и отправляет его через интерфейс P0S5/1. Маршрути-
затор Чикаго получает пакет с входящей меткой 26. На основе своей таблицы про-
движения меток маршрутизатор Чикаго заменяет входящую метку пакета 26 на
исходящую метку 30 и отправляет пакет на интерфейс POSO/3. Маршрутизатор Далла-
са получает пакет с входящей меткой 30. Так как маршрутизатор Даллас — это пред-
последний маршрутизатор на пути до пункта назначения, он удаляет MPLS-метку и
отправляет пакет в конечную точку через интерфейс P0S9/1.
Входящая Исходящая
метка матка
26 30
Сан-Франциско
POS5/1
Чикаго
Входящая
метка
30
Исходящая
метка
РОР-метка
Нью-Йорк
POS8/2
RSVP PATH RSVP PATH
RSVP RESV RSVP RESV
LABEL 26
LSP-путь установлен
RSVP PATH
RSVP PATH
RSVP RESV
LABEL 30
RSVP RESV
LABEL 0
Поток пакетов LABEL 26 LABEL 30
Нет метки
(не MPLS-пакет)
Рис. 10.5. LSP-путь для ТЕ-туннеля от Сан-Франциско до Нью-Йорка
Как было сказано ранее, протокол RSVP используется для установки ТЕ-туннелей. На
маршрутизаторе Чикаго была получена отладочная информация, содержащая RSVP-
Глава 10. Управление трафиком в сетях MPLS
301
сообщения, которые были использованы для установки туннеля. В листингах 10.15 и 10.16
показано содержание сообщений RSVP PATH и RSVP RESV, соответственно, которые бы*
ли получены маршрутизатором Чикаго. Обратите внимание на новые и модифицирован-
ные RSVP-объекты, а также на информацию, которая в них находится.
[ Листинг 10.15. Сообщение RSVP PATH, полученное маршрутизатором
J \ Чикаго от и^арш'рутизатора Сан-Франциско ' ‘
RSVP: version:l flags:OOOO type:PATH cksum:0000 ttl:254
Preserved:0 length: 248
SESSION type 7 length 16:
Destination 222.222.222.3, Tunnelld 0, Source
Ч>222.222.222.1
HOP type 1 length 12: DEDEDEI5 : 00000000
TIME_VALUES type 1 length 8 : 00007530
EXPLICIT_ROUTE type 1 length 28:
(#1) Strict IPv4 Prefix, 8 bytes, 222.222.222.22/32
(#2) Strict IPv4 Prefix, 8 bytes, 222.222.222.26/32
(#3) Strict IPv4 Prefix, 8 bytes, 222.222.222.14/32
LABEL_REQUEST type 1 length 8 : 00000800
SESSION_ATTRIBUTE type 7 length 24:
setup_pri: 7, reservation_pri: 7 MAY REROUTE
SESSION_NAME:SanFrancisco_tO
SENDER_TEMPLATE type 7 length 12:
Source 222.222.222.1, tunnel_id 1
SENDER_TSPEC type 2 length 36:
version=0, length in words=7
service id=l, service length=6
parameter id=127, flags=0, parameter length=5
average rate=1250 bytes/sec, burst depth=1000 bytes
peak rate =1250 bytes/sec
min unit=0 bytes, max unit=0 bytes
ADSPEC type 2 length 84:
version=0 length in words=19
General Parameters break bit=0 service length=8
IS Hops:0
Minimum Path Bandwidth (bytes/sec):2147483647
Path Latency (microseconds):0
Path MTU:-1
Guaranteed Service break bit=0 service length=8
Path Delay (microseconds):0
Path Jitter (microseconds):0
Path delay since shaping (microseconds):0
Path Jitter since shaping (microseconds):0
Controlled Load Service break bit=0 service length=0
RECORD_ROUTE type 1 length 12:
(#1) IPv4 address, 222.222.222.21/32
302
Часть III. Управление трафиком
Обратите внимание на объект Explicit_Route (явный маршрут) в сообшении RSVP
PATH, в котором находится точный путь, пройденный сообшением RSVP PATH с це-
лью установки LSP-пути для туннеля. В сообшении также находится объект
LABEL_REQUEST (запрос метки) для запроса распределения меток и объект
RECORD_ROUTE (запись маршрута) для записи пути, пройденного сообшением.
Листинг 10.16. Сообщение RSVP RESV, отправленное маршрутизатором v J
Чикаго Miwtfl^WopyCaH^^ipitod И
RSVP: version:l flags:OOOO type:RESV cksum:D748 ttl:255
preserved:0 length: 136
SESSION type 7 length 16:
Destination 222.222.222.3, Tunnelld 0, Source
^222.222.222.1
HOP type 1 length 12: DEDEDE16 : 00000000
TIME_VALUES type 1 length 8 : 00007530
STYLE type 1 length 8 :
RSVP_SE_OPTION
FLOWSPEC type 2 length 36:
version = 0 length in words = 7
service id = 5, service length = 6
tspec parameter id = 127, tspec flags = 0,
’ktspec length = 5
average rate = 1250 bytes/sec, burst depth = 1000 bytes
peak rate = 2147483647 bytes/sec
min unit = 0 bytes, max unit = 0 bytes
FILTER_SPEC type 7 length 12:
Source 222.222.222.1, tunnel_id 1
LABEL type 1 length 8 : 0000001A
RECORD ROUTE type 1 length 28:
(fl) IPv4 address, 222.222.222.14/32
(#2) IPv4 address, 222.222.222.26/32
(#3) IPv4 address, 222.222.222.22/32
Обратите внимание, что в сообшении RSVP RESV содержится метка 0x1 А (26 в деся-
тичной системе исчисления) и информация FLOWSPEC. В объекте RECORD_ROUTE за-
писан путь, пройденный сообщением. RSVP-сеанс и установленное резервирование пока-
заны в листинге 10.17.
[ Листинг 10.17. RSVP-сеанс и информация об установленном резервировании,
• хранящаяся на маршрутизаторе Сан-Францйско -/Л' м:
SanFranciscofshow ip rsvp host sender
To From Pro DPort Sport Prev Hop
I/F BPS Bytes
222.222.222.3 222.222.222.1 0 0 1
10K IK
Глава 10. Управление трафиком в сетях MPLS
303
SanFrancisco#show ip rsvp installed
RSVP: POS5/1
BPS To From Protoc Dport Sport
Weight Conversation
10K 222.222.222.3 222.222.222.1 0 0 1
4 264
По умолчанию значение параметра TTL (Time-to-Live — “время жизни”) из заго-
ловка IP-пакета копируется в MPLS-заголовок пограничным маршрутизатором LSP-
пути. Поэтому служебная программа traceroute будет нормально показывать все про-
межуточные точки назначения в LSP-пути туннеля. При желании вы можете скрыть
точки назначения LSP-пути, не копируя значение поля TTL из заголовка IP-пакета в
MPLS-заголовок на границе MPLS-сети. В листинге 10.18 показан результат работы
служебной программы traceroute на маршрутизаторе Сан-Франциско до и после вы-
полнения команды no mpls ip propagate-ttl.
---г-???"':"?— — •gtffrW.'1' " ................------—;
Листинг 1018. Результат работы служебной программы trace route до и .
SanFranciscoitrace 222.222.222.3
Type escape sequence to abort.
Tracing the route to 222.222.222.3
1 222.222.222.22 12 msec 8 msec 8 msec
2 222.222.222.26 12 msec 8 msec 12 msec
3 222.222.222.14 12 msec 8 msec *
SanFrancisco(config)ino mpls ip propagate-ttl
SanFranciscoitrace 222.222.222.3
Type escape sequence to abort.
Tracing the route to 222.222.222.3
1 222.222.222.14 8 msec 8 msec *
SanFranciscoi
Резюме
Механизм MPLS ТЕ использует свойства коммутации каналов для управления ТЕ-
туннелями с соответствующими зарезервированными на основе передаваемого по
туннелю трафика ресурсами. Протокол ТЕ-RSVP используется для установки LSP-
пути для ТЕ-туннеля. ТЕ-расширения протоколов OSPF и IS-IS позволяют лавинооб-
разно передавать информацию о доступных ресурсах каналов по всей сети.
Известное высказывание Майка О’Делла (Mike O’Dell) из UUNET — “Эффективность
производственной деятельности компании и стоимость ее инфраструктуры напрямую за-
304
Часть III. Управление трафиком
висит от эффективности, с которой используется доступная полоса пропускания в среде
передачи данных” — как можно более точно выражает необходимость в применении ме-
ханизма управления трафиком.
Ответы на часто задаваемые вопросы
Как определяется путь ТЕ-туннеля, если в таблице маршрутизации содержатся два
пути к его (туннеля) пункту назначения?
Если к пункту назначения туннеля существуют несколько путей, выбор пути осно-
вывается на следующих критериях (в приведенном ниже порядке).
• Метрика. Путь с наименьшей метрикой (ценой) всегда выбирается в первую
очередь.
• Полоса пропускания. Путь с самой широкой доступной полосой пропускания.
• Точки назначения. Путь с наименьшим числом точек назначения.
• Первый путь. Первый найденный путь.
В чем заключается разница между ТЕ-транком, ТЕ-туннелем и ТЕ-путем?
ТЕ-транк определяет класс пакетов, которые передаются по ТЕ-туннелю. ТЕ-
туннель — это однонаправленный IP-туннель между источником и пунктом назначения,
построенный на базе технологии MPLS. ТЕ-путь — это путь, по которому проложен ТЕ-
туннель. Он определяется протоколом RRR и устанавливается протоколом TE-RSVP.
Чем отличаются области применения и функционирование протоколов RSVP и TE-RSVP?
Области применения оригинального протокола RSVP и протокола TE-RSVP сущест-
венно отличаются. В табл. 10.4 приведены некоторые важные отличия этих протоколов.
; Таблица 10.4. Сравнительная характеристика работы протоколов RSVP
S и TE-RSVP
RSVP TE-RSVP
Применение Сигнализирует о требованиях к рас- пределению ресурсов вдоль пути Устанавливает LSP-путь с исполь- зованием или без использования распределения ресурсов
Информация состояния Для каждого потока Для каждого транка трафика
Путь, по которому передаются RSVP-сообщения передаются по Путь передачи сообщений не огра-
RSVP-сообщения пути обычного маршрута, проло- женного на основе адреса пункта назначения, по которому переда- ются пакеты с данными ничен маршрутом, проложенным на основе адреса пункта назначения
Управление распределением ресурсов Управляется получателем Управляется отправителем
RSVP-сеанс Между узлами Между маршрутизаторами
Глава 10. Управление трафиком в сетях MPLS
305
Часть
IV
Приложения
В этой части...
Приложение А. Модульный интерфейс командной строки
.Cisco QoS <
Приложение Б. Механизмы коммутации пакетов
Приложение В. Политики маршрутизации
Приложение Г. Транспортный протокол реального
: времени (RTP)
Приложение Д. Общие функцшглинейной эфективности
протокола IP
Приложение Е. Фрагментация и чередование пакетов
на канальном уровне
Приложение Ж. Значения поля IP-приоритета и поля DSCP
309
317
331
343
345
349
353
-Г
310
311
312
314
В этом приложении
Определение класса трафика
Определение политики
Применение политик
Порядок выполнения политик
Приложение
А
Модульный интерфейс
командной строки Cisco QoS
uS ' ' ‘if. h
Модульныйинтерфейскомандной строки (command-line interface — CLI) качества об-
•• служивания (quality of service — QoS) определяет новый способ конфигурации QoS в про-
граммном обеспечении Cisco IOS, основанный на использовании CLI-интерфейса. В соот-
t ветствии с новым методом, определения политики QoS-конфигурация разделена на три
. модуля: определение класса трафика, определение политики и применение политики.
Модул ьныЙ интерфейс комадной строки QoS одинаково хорошо подходит для QoS-
моделей протокола Internet (Internet Protocol — IP), технологии многопротокольной ком-
мутации меток (Multiprotocol Label Switching — MPLS), а также основанных на использо-
вании вирутальных каналов (virtual circuit— VC) технологий ATM (Asynchronous Transfer
Mode — режим асинхронной передачи) й Frame Relay. В плане определения политик все
QoS-модели похожи между собой. Так, они включают в себя такие политики выравнива-
ния или ограничений интенсидндсги трагика, как механизм согласования скорости досту-
па (Committed Access Rate — CAR), обобщенный механизм выравнивания трафика
(Generic Traffic Shaping — GTS) и механизм выравнивания трафика Frame Relay (Frame
. Relay Traffic Shaping —- FRTS); такие политики планирования пакетов, как взвешенный
алгоритм равномерного обслуживания очередей (Weighted Fair Queuing — WFQ), и такие
I? политики отбрасывания пакетов, как взвешенный алгоритм произвольного раннего обна-
.? ружения (Weighted Random Early Detection — WRED).
Основное отличие между разными QoS-моделями заключается в их политике класси-
фикации трафика. Например, модели IP QoS, основанные на базе использования значе-
ния поля IP-приоритета и поля кода дифференцированной услуги (Differentiated Service
Code Point — DSCP), отличаются битами, которые применяются для определения класса
трафика. После того как классы определены, для дифференцированного обслуживания
1 трафика используются стандартные политики. В то время как модели IP QoS и MPLS QoS
отличаются только битами в заголовке пакета, которые применяются для определения
класса трафика, QoS-модели Frame Relay и ATM отличаются от модели IP QoS уровнем
применения политик, Политики IP QoS применяются на интерфейсном уровне, тогда как
политики QoS-моделёй АТЦи Frame Relay — на уровне виртуального канала (VC).
В соответствии с модульной моделью интерфейса командной строки (CLI) QoS
(^Политики в маршрутизаторе конфигурируются за три шага, по одному на каждый
модуль CLL.^
Шаг 1. Определение класса трафика. Конфигурирование политики классификации
трафика с помощью команды class-map.
Шаг 2. Определение политики. Конфигурирование политик для различных, уже оп-
ределенных классов трафика с помощью команды policy-map.
ШагЗ. Применение политики. Активизирование политики на интерфейсе или виртуаль-
ном канале ATM или Frame Relay с помощью команды service-policy.
Определение класса трафика
Дифференциация или классификация трафика — это первый шаг в обеспечении
дифференцированных QoS-услуг. Для определения класса трафика в модульном CLI-
интерфейсе QoS используется команда class-map, а для определения пакетов, принад-
лежащих классу трафика, — вложенная команда match.
Команда class-map похожа на команду route-map, которая присутствует в операци-
онной системе Cisco IOS. Команда route-map используется для определения критерия
совпадения пакетов на основе сведений, взятых из заголовка пакета: IP-адрес, номер
автономной системы (Autonomous System — AS) протокола пограничного шлюза
(Border Gateway Protocol — BGP), атрибут BGP-сообщества и т.д. Команда class-map
расширяет функциональность команды route-map, добавляя такие новые средства
классификации пакета, как критерий совпадения на основе МАС-адреса (Media Ac-
cess Control — управление доступом к среде передачи) и входного интерфейса.
В листинге А.1 классы трафика classl, class2, class3, class4 и class5 определены на
базе значения поля IP-приоритета, значения поля DSCP, МАС-адреса пункта назна-
чения, входящего интерфейса и информации протокола, соответственно.
! Листинг А.1. Примеры определения классов трафика , , J „ "/1
class-map classl
match ip precedence 5
class-map class2
match ip dscp EF
class-map class3
match destination <mac-address>
class-map class4
match input-interface Hssi0/0/0
class-map class5
match protocol https
Одно из обязательных условий при определении классов трафика — наличие воз-
можности определить такой класс, который бы соответствовал пакетам, удовлетво-
ряющим критериям нескольких или всех ранее определенных классов. Для этого до-
бавляются два ключевых слова: match-any и match-all. Эти ключевые слова выполняют
операции логического ИЛИ и И, соответственно, по отношению ко вложенным ко-
310
Часть IV. Приложения
мандам match, определенным в модуле class-map. В листинге А. 2 определяется класс
трафика class-any с критерием совпадения пакетов, удовлетворяющим трафику любого
из ранее определенных классов — classl и class2.
। Листинг А.2. Пример использования ключевого слова match-апу class-map '
class-map classl
match <>
class-map class2
match <>
class-map match-any class-any
match classl
match class2
В листинге А.З определяется класс трафика class-all с критерием совпадения паке-
тов, удовлетворяющим трафику, который принадлежит обоим ранее созданным клас-
сам — classl и class2.
Листинг АЗ. Пример использования ключевого слова match-all class-map i
class-map classl
match <>
class-map class2
match <>
class-map match-all class-all
match classl
match class2
Определение политики
После конфигурации классов трафика необходимо определить QoS-политики, соответ-
ствующие этим классам. QoS-политики определяются с помощью команды policy-map.
При желании в качестве подкоманды модуля policy-map можно указать любую QoS-
функцию. Наряду с основными QoS-функциями WFQ и WRED, сюда включаются все
пограничные функции QoS, такие, как механизм выравнивания или ограничения интен-
сивности трафика и установка значения поля IP-приоритета или поля DSCP.
В листингах А.4 и А.5 показаны примеры политик, предназначенных для
пограничных интерфейсов и интерфейсов базовой сети, соответственно.
Листинг А.4. Примеры политик, предназначенных для пограничных
V1 К сеТ^'Х интерфейсов „ ; Л. ';
policy-map epolicyl
match classl
rate-limit <>
Приложение А. Модульный интерфейс командной строки Cisco QoS 311
policy-map epolicy2
match class2
set ip dscp EF
policy-map epolicy3
match class3
shape <>
set ip precedence 4
В листинге A.4 политика epolicy 1 определяет ограничение интенсивности трафика для
класса class 1, политика ероПсу2 устанавливает значение, соответствующее РНВ-политике
EF, в поле DSCP для класса трафика calss2, а политика ероНсуЗ активизирует механизм вы-
равнивания трафика и устанавливает IP-приоритет 4 для класса трафика class3.
! Листинг А.5. Примеры политик, предназначенных для интерфейсов
j ’базовой сети
policy-map epolicyl
match classl
bandwidth <>
random-detect <>
В листинге A. 5 политика epolicy 1 определяет минимальную полосу пропускания и
активизирует механизм WRED для класса трафика classl.
Пример конфигурации многомерной политики показан в листинге А.6. В этом
примере политика epolicyl определяет ограничение интенсивности для класса трафика
classl и устанавливает IP-приоритет 3 для класса трафика class2.
i Листинг А.6. Многомерные политики
policy-map epolicyl
match classl
rate-limit <>
match class2
set ip precedence 3
Применение политик
После конфигурации классов трафика (class-map) и политик (policy-map) остается
только примененить последние на интерфейсе путем привязки команды policy-map к
интерфейсу с помощью команды service-policy. Для того чтобы определить объект
применения политики — входящий или исходящий трафик интерфейса, — использу-
ются дополнительные ключевые слова input или output, соответственно.
В листинге А.7 показаны примеры применения политики к интерфейсу. Политика
policyl применяется ко всему входящему трафику интерфейса HSSI0/0/0, а политика
policy2 — к исходящему трафику интерфейса POS0/0/0.
312
Часть IV. Приложения
, Листинг А.7. Пример применения политики к интерфейсу,
interface HSSI0/0/0
service-policy input policyl
interface POSO/O/O
service-policy output policy2
Команду service-policy можно применять на каждом виртуальном канале интерфей-
са ATM и Frame Relay, а также на каждом интерфейсе таких логических интерфейсов,
как Tunnel и FastEthernetChannel. Эта команда используется для применения соответ-
ствующих политик, сконфигурированных для виртуальных каналов или интерфейсов.
Иерархические политики
Для некоторых приложений необходимо разрешить определение иерархических
политик.
Поскольку иерархические политики могут быть применены как к интерфейсам,
так и к отдельным виртуальным каналам интерфейсов Frame Relay или ATM, мы уже
имеем дело с иерархией политик, которую можно организовать путем применения
политик на разных уровнях этой иерархии. (Например, можно применить одну ко-
манду service-policy к интерфейсу Frame Relay, а другую команду service-policy — к по-
стоянному виртуальному каналу (permanent virtual circuit — PVC) интерфейса Frame
Relay.) На самом деле хотя интерфейс или PVC-канал и не определен посредством
команды class-map, он представляет собой класс трафика с общим атрибутом. Следо-
вательно, команду service-policy можно применить не только к интерфейсу или PVC-
каналу, но и к классу трафика в модуле policy-map.
В листинге А.8 показано применение команды service-policy к классу трафика для
определения политики.
, Листинг А.8. Применение команды service-policy к классу трафика . ]
policy-map policy-hierarchy
class classl
service-policy <>
Для иллюстрации иерархических политик рассмотрим политику, которая ограничивает
интенсивность агрегированного трафика протокола управления передачей (Transmission
Control Protocol — TCP) до 10 Мбит/с. Вместе с тем она ограничивает интенсивность
TCP-трафика определенных приложений (например, агрегированного трафика Telnet и
трафика протокола передачи файлов (File Transfer Protocol — FTP)) до 1 Мбит/с. Соответ-
ствующая конфигурация иерархической политики показана в листинге А.9.
i Листинг А.9. Пример иерархической политики, предназначенной
для ограничения интенсивности трафика ........... i
class-map tcp
match <all tcp traffio
Приложение А. Модульный интерфейс командной строки Cisco QoS 313
class-map telnet
match <all telnet traffic?
class-map ftp
match <all ftp traffic?
policy-map telnet-ftp-police
class telnet
rate-limit 1000000
class ftp
rate-limit 1000000
policy-map TCP-police-hierarchical
class tcp
rate-limit 10000000
service-policy telnet-ftp-police
В предыдущем листинге классы tcp, telnet и ftp соответствуют трафику, принадле-
жащему TCP-приложениям, приложению Telnet и FTP-приложениям. Политика
telnet-ftp-police ограничивает интенсивность трафика приложения Telnet и FTP-
приложений до 1 Мбит/с каждый.
И, наконец, политика TCP-police-hierarchical определена для организации иерархи-
ческой политики. Она ограничивает интенсивность трафика класса tcp до 10 Мбит/с,
и в то же время использует политику telnet-ftp-policy для ограничения интенсивности
трафика приложения Telnet и FTP-приложений до 1 Мбит/с каждый.
Порядок выполнения политик
Одной из важных проблем, касающихся определения QoS-политик, является вре-
менной порядок их применения. Правильно определить порядок применения свойств
политик необходимо для того, чтобы пользователь мог разобраться в эффекте, дости-
гаемом с помощью различных конфигураций QoS.
Упорядочение политик
Ниже приведен порядок применения политик в операционной системе Cisco IOS
(известный также как упорядочение политик) с использованием или без использова-
ния модульного CLI-интерфейса QoS.
1. Входные списки доступа (фильтрация входящих пакетов).
2. Установка приоритета или QoS-метки на основе адреса источника.
3. Установка приоритета или QoS-метки на основе адреса пункта назначения.
4. Ограничение интенсивности входного трафика.
5. Маршрутизация на основе политик.
6. Выходные списки доступа (фильтрация исходящих пакетов).
7. Ограничение интенсивности исходящего трафика.
8. Выходная политика отбрасывания (например, WRED).
9. Выходное планирование (например, WFQ) и выравнивание трафика.
314
Часть IV. Приложения
Независимо от QoS-политик сразу после применения входных списков доступа
производится учет входящих пакетов, а непосредственно перед тем как пакеты от-
правляются по среде передачи данных, — учет исходящих пакетов.
Упорядочение операторов внутри политик
Еще одним порядком применения политик является упорядочение операторов
внутри самих политик. К примеру, в операторе ограничения интенсивности трафика
существует параметр порядкового номера, помогающий пользователям определить
порядок, в котором будут рассматриваться критерии совпадения. Порядковый номер
также позволяет легко добавлять в систему новые классы трафика.
Рассмотрим листинг А. 10, в котором проверка критерия совпадения для класса
classl производится до проверки критерия совпадения для класса class2 (порядковый
номер 10 меньше порядкового номера 20) для карты политики policy 1.
? Листинг А.10. Упорядочение операторов внутри политик j
policy-map policyl
class classl
rate-limit 10 input <>
class class2
rate-limit 20 input <>
В листинге A. 11 политика policy2 ограничивает интенсивность трафика класса
class2 перед ограничением интенсивности трафика класса classl (порядковый номер 5
меньше порядкового номера 10). Этот пример иллюстрирует изменение порядка при-
менения операторов политик.
г" ' .............—”—-------------------- 1
Листинг А.11. Порядок выполнения операторов политики изменен путем :
модификации порядкового номера
policy-map policy2
class classl
rate-limit 10 input <>
class class2
rate-limit 5 input <>
Приложение А. Модульный интерфейс командной строки Cisco QoS 315
Приложение
Б
Механизмы коммутации
пакетов
Л? " %
Главной задачей маршрутизатора является эффективная и корректная коммутация
пакетов. В операционной системе Cisco IOS поддерживаются несколько методов ком-
мутации. В этом приложении обсуждаются три из них — коммутация процессов, про-
движение пакетов с помошью кэша маршрутов и скоростная коммутация пакетов
Cisco (Cisco Express Forwarding — CEF).
В современных сетях, обеспечивающих передачу тысяч кратковременных потоков
данных, рекомендуется использовать метод коммутации пакетов CEF. Этот метод иг-
рает жизненно важную роль в контексте реализации функций маршрутизации на ос-
нове политик, которые требуют просмотра таблицы маршрутизации. CEF также явля-
ется необходимым механизмом Коммутации пакетов для активизации определенных
QoS-функций, таких, как механизм распространения политик QoS с помощью прото-
кола BGP (QoS Policy Propagation using BGP — QPPB). Более подробно маршрутиза-
ция на основе политик и механизм QPPB обсуждаются в приложении В, “Политики
маршрутизации”, далее в этой книге.
Коммутация процессов
При коммутации процессов (process switching) пакет поступает на входной интерфейс и
ставится во входную очередь процесса, который коммутирует пакет. Когда планировшик
запускает процесс, последний просматривает таблицу маршрутизации в поисках маршрута
до точки назначения. Если маршрут найден, то из таблицы маршрутизации извлекается
адрес точки следующей передачи пакета. Механизм управления доступом к среде передачи
(Media Access Control — МАС) перезаписывает адрес точки следующей передачи с помо-
щью информации, взятой из таблицы протокола преобразования адресов (Address Resolu-
tion Protocol — ARP), после чего пакет устанавливается в выходную очередь интерфейса
для отправки. Коммутация процессов — это медленная, неэффективная и требующая ин-
тенсивного использования ресурсов процессора операция, поскольку каждое принятие
решения о коммутации пакета требует просмотра таблицы маршрутизации и ARP-
таблицы. При существовании нескольких путей к пункту назначения с одинаковой ценой
коммутация процессов предполагает распределение нагрузки для каждого пакета. Комму-
тация процессов схематически изображена на рис. Б. 1.
Кадр I Пакет
I_____________!____________I
Перезапись заголовке канального уровня
Рис. Б. 1. Коммутация процессов предполагает просмотр таблицы 1Р-маршрутизации
и ARP-таблицы
Продвижение пакетов с помощью кэша
маршрутов
Продвижение пакетов с помощью кэша маршрутов (route-cache forwarding) решает
некоторые проблемы, присущие коммутации процессов. Так, в соответствии с этим
методом после того, как первый пакет был передан с помощью коммутации процес-
сов, адрес пункта назначения, интерфейс точки следующей передачи и инкапсуляция
МАС-адреса точки следующей передачи сохраняются в таблице под названием кэш
маршрутов (route-cache). Таким образом, можно осуществить быструю коммутацию
последующих пакетов, предназначенных для этого же пункта назначения, всего лишь
найдя адрес пункта назначения в кэше маршрутов. При использовании этого метода
принятие решения о коммутации производится в рамках того же прерывания, которое
было вызвано поступлением пакета. Продвижение пакетов с помощью кэша маршру-
тов часто называют также быстрой коммутацией (fast switching). Механизм продвиже-
ния пакетов с помощью кэша маршрутов схематически изображен на рис. Б.2.
Рис. Б.2. Передача пакетов с помощью кэша маршрутов осуществ-
ляется путем просмотра 1Р-кэша
Механизм продвижения пакетов с помощью кэша маршрутов производит быстрый по-
иск префикса пункта назначения по требованию. Запись для пункта назначения в кэше
маршрутов создается только после того, как маршрутизатор получит первый предназна-
ченный к отправке в этот пункт пакет. Данный пакет передается с помошью коммутации
процессов, однако все остальные пакеты, предназначенные для передачи в этот же пункт
назначения, коммутируются путем их поиска в более быстром и эффективном кэше мар-
шрутов. Записи в кэше маршрутов периодически устаревают. Более того, изменение в то-
пологии сети может мгновенно сделать эти записи недействительными.
318
Часть IV. Приложения
Подобная схема кэширования маршрутов по требованию эффективна только в тех
случаях, когда большинство потоков трафика предназначаются для передачи в неко-
торое подмножество пунктов назначения в таблице маршрутизации. Однако профили
трафика в ядре Internet и больших intranet-сетях не подпадают под это описание. Ха-
рактеристики такого трафика изменились в сторону увеличения количества кратко-
временных потоков, обычно инициированных интерактивными приложениями и
Web-приложениями. Изменение в модели Intemet-трафика требует изменений меха-
низма коммутации с целью уменьшения огромного количества обращений к кэшу,
вызванного большим числом кратковременных потоков трафика и изменениями то-
пологии сети, которые отражаются в таблице маршрутизации.
Когда существует несколько путей с одинаковой ценой к подсети назначения, ме-
ханизм продвижения пакетов с помощью кэша маршрутов для выравнивания нагруз-
ки кэширует префиксы длиной 32 бит для всего трафика, предназначенного для пере-
дачи в эту подсеть.
CEF-коммутация
CEF является масштабируемым механизмом коммутации сетевого уровня, разрабо-
танным специально для адаптации к изменениям характеристик трафика и динамики
топологии Internet и крупных intranet-сетей. В механизме CEF представлено большое
число улучшений по сравнению с традиционным методом коммутации с помощью
кэша маршрутов.
Преимущества CEF-коммутации
Механизм CEF избегает потенциального перенасыщения постоянными обра-
щениями к кэшу с помощью топологической таблицы CEF, использующейся во
время принятия решения о коммутации. В CEF-таблице зеркально отображается
вся информация о маршрутах. Существует прямое соответствие между записями в
CEF-таблице и префиксами таблицы маршрутизации. При создании записи CEF-
таблицы автоматически разрешается проблема рекурсивного маршрута, вследствие
чего механизм CEF позволяет достичь таких преимуществ, как производитель-
ность, масштабируемость, устойчивость сети и функциональность. Преимущества
механизма CEF особенно видны в больших, сложных сетях с динамической моде-
лью трафика.
Наряду с CEF-таблицей поддерживается таблица смежностей (adjacency table).
В таблице смежностей хранится информация заголовка канального уровня, кото-
рая заполняется любыми протоколами — ARP, открытым протоколом предпочти-
тельного выбора кратчайшего пути (Open Shortest Path First — OS PF), BGP и
др., — которым необходимо установить отношение смежности. Каждый заголовок
канального уровня смежного узла заранее вычисляется и сохраняется вместе с
информацией об установке смежности.
Таблица CEF заполняется путем обратных вызовов из таблицы маршрутизации.
После того как маршрут разрешен, соответствующая ему запись в CEF-таблице ука-
зывает на точку следующей передачи пакета, которая должна представлять собой
смежное устройство. Если данное отношение смежности найдено в таблице смежно-
стей, то указатель на него кэшируется в CEF-записи. Процесс CEF-коммутации схе-
матически изображен на рис. Б.З.
Приложение Б. Механизмы коммутации пакетов
319
Рис. Б.З. Процесс CEF-коммутации пакетов путем просмотра таблицы CEF
Кроме обычных физических смежностей, необходимо еще обработать особые типы
смежности. Записи CEF-таблицы с префиксами, которые необходимо обработать спе-
циальным образом, заносятся в кэш с указанием на специальный тип смежности.
Примеры таких типов смежностей показаны в табл. Б.1.
[Таблица Б.1. Примеры некоторых специальных типов смежностей
Тип смежности Причина специальной обработки
Receive Пакеты, соответствующие этим префиксам, предназначаются для передачи маршрутизато- ру. Записи CEF-таблицы с этими смежностями являются префиксами длиной 32 IP-адреса маршрутизатора, а также адресами направленного и обычного широковещания
Null Пакеты, соответствующие этим префиксам, предназначены для интерфейса NullO маршру- тизатора. Записи CEF-таблицы с этой смежностью создаются для префиксов с точкой на- значения, представляющей собой интерфейс NullO маршрутизатора. Пакеты, предназна- ченные для передачи на интерфейс NullO, отбрасываются механизмом СЕР
Glean Записи CEF-таблицы со смежностью Glean (“сборная” смежность) создаются для префик- сов подсети, напрямую подсоединенных к одному из не двухточечных интерфейсов мар- шрутизатора. Для пакетов, которые должны быть переданы конечной станции, в базе дан- ных смежности производится тщательный поиск специального префикса
Punt Записи CEF-таблицы со смежностью Punt (“спорная” смежность) создаются для префиксов, которые не могут быть скоммутированы с помощью механизма CEF, так как определенные свойства могут требовать специальной обработки или пока не поддерживаются
Примечание
Интерфейс NullO— это псевдоинтерфейс, который работает так же, как и null-
устройства, существующие в большинстве операционных систем. Этот интерфейс все-
гда работает и не может передавать или получать трафик. Он предоставляет альтерна-
тивный метод фильтрации трафика.
В отличие от модели кэша маршрутов, в которой префиксы длиной 32 бит кэ-
шируются для выравнивания нагрузки, механизм CEF проводит поиск эффектив-
ной хэш-функции с целью выравнивания нагрузки для каждой пары “источник-
пункт назначения”. Хэш-функция указывает на уникальную смежность для каж-
дой пары “адрес источника-адрес пункта назначения”. Более того, механизм CEF
может производить выравнивание нагрузки для каждого пакета с помощью указа-
320
Часть IV. Приложения
теля, который циклически перемещается по смежностям с одинаковой стоимо-
стью, соответствующим пункту назначения.
Еще одним показательным преимуществом механизма CEF является сбор стати-
стики CEF-пакетов и распространение QoS-политик. Более подробно распростране-
ние QoS-политик обсуждается в приложении В, “Политики маршрутизации”.
Распределенный механизм коммутации CEF (DCEF)
Механизм CEF-коммутации может работать в распределенном режиме на
маршрутизаторах, поддерживающих интерфейсные линейные платы со встроен-
ными процессорами. При работе в распределенном режиме таблица CEF загружа-
ется в память интерфейсных линейных плат маршрутизатора с тем, чтобы приня-
тие решения о коммутации пакетов производилось не на плате центрального про-
цессора, а на отдельных линейных платах. DCEF — это необходимый для всех
распределенных QoS-функций механизм коммутации, работающий на интер-
фейсных линейных платах.
Примечание
Механизм продвижения пакетов с помощью кэша маршрутов также может работать в
распределенном режиме а случае, если информация IP-кэша будет загружена в па-
мять на интерфейсных линейных платах.
Практический пример Б.1: применение механизма
коммутации CEF на магистральном маршрутизаторе
В настоящий момент все маршрутизаторы сети поставщика услуг Internet (Internet
Service Provider — ISP) производят продвижение пакетов с помощью маршрутного
кэша. Сеть поставщика услуг схематически изображена на рис. Б.4. Поставщику не-
обходимо внедрить в сети механизм передачи пакетов CEF.
Примечание
Целью этого практического примера является иллюстрация работы механизма CEF и
его сраанение с моделью кэша маршрутов. Для лучшего понимания обоих механизмоа
коммутации рассматриваются таблица кэша маршрутов и CEF-таблица маршрутиза-
тора R2 после активизации на последнем, один за другим, обоих механизмоа комму-
тации. В этом примере также рассматриваются некоторые типы записей CEF-
таблицы.
Так как обе модели коммутации передают пакеты на основе информации о мар-
шруте, для начала рассмотрим таблицу маршрутизации маршрутизатора R2. В лис-
тинге Б.1 показана информация о маршрутах маршрутизатора R2, выведенная на эк-
ран с помощью команды show ip route.
Приложение Б. Механизмы коммутации пакетов
321
ISP с
Hssi3/0/0
101
Hssi2/0/0/
200.200.200.100/30/
ISP A
R5
10
R1
109
\Hssi2/0/1
\ 200.200.200.108/30
191.108.0.0/18
20.0.0.0/8
131.108.0.0/16
210.210.210.0/24
102
Hssi2/0/1
R2
Hssi2/0/0
FE1/0/0
17
105
200.200.200.16/28
Сеть поставщике
услуг Internet
AS 109
191.108.10.8/30 / /191.108.10.12/30
\ Hssi3/O/o//
110
Hssi2/0/1
Hssi2/0/0
200.200.200.104/30
106
FE1/0/0
201.201.201.16/28
10
ISP В
R4
/ Serial4/0/0
13
R3
Seriel4/0/1
\ 201.201.201.8/30
\ Сеть клиента
_ AS 4567
R6
194.194.194.0/24
9
9
Рис. Б.4. Сеть поставщика услуг
Листинг Б. 1. Таблица маршрутизации маршрутизатора R2 г,
R2#sh ip route
Codes: С - connected, S - static, I - IGRP, R - RIP, M - mobile, В - BGP
D - EIGRP, EX - EIGRP external, 0 - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, LI - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, о - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
200.200.200.0/24 is variably subnetted, 8 subnets, 4 masks
C 200.200.200.104/30 is directly connected, Hssi2/0/0
0 200.200.200.108/30 [110/20] via 200.200.200.101, Hssi2/0/l
[110/20] via 200.200.200.106, Hssi2/0/0
C 200.200.200.100/30 is directly connected, Hssi2/0/l
S 200.200.200.0/24 is directly connected, NullO
322
Часть IV. Приложения
О 200.200.200.1/32 [110/11] via 200.200.200.101, Hssi2/0/l
С 200.200.200.2/32 is directly connected, LoopbackO
О 200.200.200.3/32 [110/11] via 200.200.200.106, Hssi2/0/0
C 200.200.200.16/28 is directly connected, FastFastEthernetl/0/0
191.108.0.0/16 is variably subnetted, 3 subnets, 2 masks
О 191.108.10.8/30 [110/20] via 200.200.200.106, Hssi2/0/0
О 191.108.10.12/30 [110/20] via 200.200.200.106, Hssi2/0/0
В 191.108.0.0/16 [200/0] via 191.108.10.10
201.201.201.0/24 is variably subnetted, 2 subnets, 2 masks
О 201.201.201.8/30 [110/20] via 200.200.200.106, Hssi2/0/0
О 201.201.201.0/28 [110/20] via 200.200.200.106, Hssi2/0/0
В 194.194.194.0/24 [200/0] via 201.201.201.10
В 20.0.0.0/8 [200/0] via 191.108.10.10
В 131.108.0.0/16 [200/0] via 191.108.10.10
В 210.210.0.0/16 [200/0] via 191.108.10.10
Таблица IP-маршрутизации не зависит от механизма коммутации пакетов. Как
правило, она заполняется динамическими протоколами маршрутизации, маршрутами
к непосредственно подключенным подсетям и статическими маршрутами.
Перед тем как запустить механизм CEF на маршрутизаторе R2, воспользуемся
командой show ip cache verbose для того, чтобы просмотреть таблицу кэша, исполь-
зующуюся в модели кэша маршрутов. В листинге Б.2 показана таблица кэша маршру-
тов маршрутизатора R2 на момент запуска команды.
{ Листинг Б.2. Кэш маршрутизатора Й2, использующего механизм
i -у-у- коммутации на основе кэша маршрутов.
R2#sh ip cache verbose
IP routing cache 7 entries, 1196 bytes
1967 adds, 1960 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval
4>5 seconds, quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Приложение Б. Механизмы коммутации пакетов
323
Prefix/Length Age Interface Next Hop
20.0.0.0/8-8 4 0F000800 00:01:14 Hssi2/0/0 200.200.200.106
131.108.0.0/16-16 4 0F000800 00:00:49 Hssi2/0/0 200.200.200.106
191.108.1.0/30-30 4 0F000800 00:01:47 Hssi2/0/0 200.200.200.106
191.108.10.8/30-30 4 0F000800 00:03:19 Hssi2/0/0 200.200.200.106
200.200.200.1/32-32 4 0F000800 00:03:22 Hssi2/0/l 200.200.200.101
200.200.200.3/32-32 4 0F000800 00:03:22 Hssi2/0/0 200.200.200.106
200.200.200.101/32-30 4 0F000800 00:03:19 Hssi2/0/l 200.200.200.101
200.200.200.20/32-28 00:00:29 14 00000C31DD8B00E0B0E2B843080C FastEthernetl/0/0 200.200.200.106 1
210.210.210.0/24-16 4 0F000800 00:02:57 Hssi2/0/0 200.200.200.106
Таблица кэша всегда изменяется, поскольку она зависит от трафика. Запись в кэ-
ше для префикса создается только после того, как будет коммутирован первый пакет,
предназначенный для передачи по этому префиксу. Обратите внимание на следующие
характеристики таблицы продвижения пакетов, построенной на базе кэша маршрутов.
• Таблица кэша является полноклассной. Длина ее префикса может быть равна
только 0, 8, 16, 24 или 32 бит.
• Длина префиксов сети класса А, В и С не может иметь длину префикса кэша,
отличную от 8, 16 и 24 бит, соответственно.
• Длина префикса в таблице кэша равна длине префикса наиболее точной подсе-
ти этого класса сетей в таблице IP-маршрутизации. Например, длина префикса
кэша адресного пространства 200.200.200.0/24 равна 32 бит, так как в таблице
маршрутизации существует как минимум один маршрут из адресного простран-
ства 200.200.200.0/24 с маской длиной 32 бит.
В таблице кэша длина префикса показана в формате х-у, где х обозначает реаль-
ную длину записи в кэше, а у — длину подходящего префикса из таблицы маршрути-
зации. В записи кэша для префикса также показан выходной интерфейс, IP-адрес
точки следующей передачи пакета и инкапсуляция канального уровня.
С помощью глобальной команды ip cef на маршрутизаторе R2 был запущен меха-
низм CEF. В листингах Б.З и Б.4 показаны таблица CEF-смежностей и таблица CEF-
коммутации маршрутизатора R2.
[ Листинг Б.З. Таблица CEF-смежностей маршрутизатора R2 . / {
R2#show adjacency detail
Protocol Interface Address
IP Hssi2/0/0 point2point(26)
0 packets, 0 bytes
324
Часть IV. Приложения
IP Hssi2/0/l
IP FastEthernetl/O/O
0F000800
CEF expires: 00:02:47
refresh: 00:00:47
point2point(16)
0 packets, 0 bytes
0F000800
CEF expires: 00:02:01
refresh: 00:00:01
200.200.200.20(16)
0 packets, 0 bytes
00000C31DD8B00E0B0E2B8430800
ARP 00:08:00
В таблице смежностей показана инкапсуляция канального уровня, необходимая
для достижения различных напрямую подсоединенных маршрутизаторов и конечных
узлов. Смежности обнаруживаются посредством протокола ARP, протоколов маршру-
тизации или конфигурационных команд тар, использующихся обычно на интерфей-
сах ATM и Frame Relay. Смежности периодически обновляются для поддержания их
текущего состояния.
( Листинг Б.4. Таблица CEF-коммутации пакетов маршрутизатора R2 j
... - . ,‘UXt. ...к;
R2#sh ip cef
Prefix Next Hop Interface
0.0.0.0/32 receive
20.0.0.0/8 200.200.200.106 Hssi2/0/0
131.108.0.0/16 200.200.200.106 Hssi2/0/0
191.108.0.0/16 200.200.200.106 Hssi2/0/0
191.108.10.8/30 200.200.200.106 Hssi2/0/0
191.108.10.12/30 200.200.200.106 Hssi2/0/0
194.194.194.0/24 200.200.200.106 Hssi2/0/0
200.200.200.0/24 attached NullO
200.200.200.1/32 200.200.200.101 Hssi2/0/l
200.200.200.2/32 receive
200.200.200.3/32 200.200.200.106 Hssi2/0/0
200.200.200.16/28 attached FastEthernetl/0/0
200.200.200.16/32 receive
200.200.200.17/32 receive
200.200.200.31/32 receive
200.200.200.100/30 attached Hssi2/0/l
200.200.200.100/32 receive
200.200.200.101/32 200.200.200.101 Hssi2/0/l
200.200.200.102/32 receive
200.200.200.103/32 receive
200.200.200.104/30 attached Hssi2/0/0
200.200.200.104/32 receive
200.200.200.105/32 receive
200.200.200.107/32 receive
Приложение Б. Механизмы коммутации пакетов
325
200.200.200.108/30
201.201.201.8/30
201.201.201.16/28
210.210.0.0/16
224.0.0.0/4
224.0.0.0/24
255.255.255.255/32
200.200.200.101
200.200.200.106
200.200.200.106
200.200.200.106
200.200.200.106
0.0.0.0
receive
receive
Hssi2/0/l
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
CEF-таблица остается стабильной до тех пор, пока топология, отраженная в таб-
лице маршрутизации, остается неизменной. Каждой записи в таблице маршрутизации
соответствует запись в CEF-таблице. В оставшейся части этого примера обсуждаются
CEF-записи различных типов смежностей. В листингах Б.5-Б. 10 показаны примеры
различных типов CEF-записей.
Листинг Б.5. Пример CEF-записи со смежностью-Receive '
R4506#sh ip cef 200.200.200.105
200.200.200.105/32, version 6, receive
Механизм CEF, помимо поддержки соответствия CEF-записи для каждого мар-
шрута из таблицы маршрутизации, обрабатывает CEF-записи со смежностью Receive
для всех непосредственно подключенных IP-адресов, адресов направленного широко-
вещания (первый и последний адрес каждой непосредственно подключенной подсети)
маршрутизатора и общих широковещательных адресов (0.0.0.0 и 255.255.255.255).
200.200.200.105 — это IP-адрес интерфейса Hssi2/0/0 маршрутизатора.
j Листинг Б.6. Пример рекурсивной CEF-записи с действительной j
помещенной в кэш смежностью •
R4506#sh ip cef 131.108.0.0
131.108.0.0/16, version 20, cached adjacency to Hssi2/0/0
0 packets, 0 bytes
via 191.108.10.10, 0 dependencies, recursive
next hop 200.200.200.106, Hssi2/0/0 via 191.108.10.8/30
valid cached adjacency
В записи из таблицы маршрутизации для адреса 131.108.0.0 указана неподключен-
ная напрямую точка следующей передачи пакета 191.108.10.10. Для этой записи тре-
буется рекурсивный поиск точки следующей передачи для 191.108.10.10 с тем, чтобы
добраться до напрямую подключенной точки следующей передачи 200.200.200.106 для
адреса 131.108.0.0.
Механизм CEF производит рекурсивный поиск еще до создания CEF-записи для
адреса 131.108.10.1. Поэтому адресу 131.108.0.0 в таблице CEF соответствует подсое-
диненная точка следующей передачи 200.200.200.106.
В модели передачи пакетов с помощью кэша маршрутов рекурсивный поиск пунк-
та назначения, при необходимости, производится в процессе коммутации первого па-
кета, переданного по направлению к пункту назначения в соответствии с созданной
326
Часть IV. Приложения
записью в кэше. Механизм CEF производит рекурсивный поиск до прибытия пакета.
Таким образом, экономятся несколько циклов работы процессора.
/Листинг Б.7. Пример CEF-записи с действительной помещенной в кэш
!' смежностью с зависимостями
R2#sh ip cef 191.108.10.10
191.108.10.8/30, version 17, cached adjacency to Hssi2/0/0
0 packets, 0 bytes
via /00.200.200.106, Hssi2/0/0, 4 dependencies
next hop 200.200.200.106, Hssi2/0/0
valid cached adjacency
В этой CEF-записи отмечено четыре зависимости. В ней указывается, что четыре
рекурсивных записи (20.0.0.0/8, 131.108.0.0/16, 191.108.0.0/16 и 210.210.210.0/24) зави-
сят от этой CEF-записи в плане определения их точки следующей передачи пакета.
Е. - . - —.. ...^ ..._.—. — . —. . м ... --- . ~ .... - . . — —т .... - ........ I >vj~* — *у- - —r“.' *•“ X f
Листинг Б.8. Пример CEF-записи для путей с одинаковыми стоимостями
. и разделяемой нагрузкой 'для каждого направления^Н^^ЙМ^
R2#sh ip cef 200.200.200.108
200.200.200.108/30, version 12, per-destination sharing
0 packets, 0 bytes
via 200.200.200.101, Hssi2/0/l, 0 dependencies
traffic share 1
next hop 200.200.200.101, Hssi2/0/l
valid adjacency
via 200.200.200.106, Hssi2/0/0, 0 dependencies
traffic share 1
next hop 200.200.200.106, Hssi2/0/0
valid adjacency
0 packets, 0 bytes switched through the prefix
У точки назначения 200.200.200.108/30 есть два пути с одинаковой стоимостью и
распределяемой нагрузкой для каждой пары “источник-пункт назначения”. (Следует
отметить, что термин “распределение для каждого направления”, использованный в
листинге Б.7, не совсем правильный. На самом деле имеет место распределение на-
грузки для каждой пары “источник-пункт назначения”.) Механизм CEF также под-
держивает распределение нагрузки для каждого пакета.
j" ;-,г .--j.-- ^... j
| Листинг Б.9. Пример CEF-записи со смежностью Glean ~ ’
R2#sh ip cef 200.200.200.16 255.255.255.240
200.200.200.16/28, version 26, attached, connected
0 packets, 0 bytes
via FastEthernetl/0/0, 0 dependencies
valid glean adjacency
Приложение Б. Механизмы коммутации пакетов
327
Точка назначения 200.200.200.16/28 является напрямую подключенной к интер-
фейсу Fast Ethernet подсетью. Вместо создания CEF-записи для каждого узла этой
широковещательной подсети со множественным доступом, данная подсеть устанавли-
вается в качестве “сборной” смежности. При отправке пакета с использованием
“сборной” смежности перед коммутацией пакета механизм CEF просматривает таб-
лицу смежности в поисках МАС-адреса пункта назначения.
i Листинг Б.10. Пример CEF-запйси с Null-смежностью
R4506#sh ip cef 200.200.200.0
200.200.200.0/24, version 14, attached
0 packets, 0 bytes
via NullO, 0 dependencies
valid null adjacency
Трафик, соответствующий этой CEF-записи, направляется на интерфейс NullO.
Сравнение механизмов коммутации с помощью кэша
маршрутов и CEF
В табл. Б.2 сравниваются схемы коммутации с помощью кэша маршрутов и CEF-
коммутации.
Таблица Б.2. Сравнение схемы коммутации с помощью кэша маршрутов
. и CEF-коммутации
Коммутация с помощью кэша маршрутов CEF-коммутация
Запись в кэше создается во время коммутации
первого пакета. Все последующие пакеты переда-
ются с помощью этой записи
Управляется трафиком. Создается по требованию
Эффективна для трафика с небольшим количест-
вом длительных потоков, обычно инициированных
приложениями передачи файлов
Каждый рекурсивный поиск маршрута производит-
ся, когда начальный пакет, направляющийся в
пункт назначения, инициировал создание элемента
кэша. Лимит на глубину рекурсии — 6
Периодически при возникновении нестабильности в
сети происходят скачки загруженности процессора
Производит распределение нагрузки на основе адреса
пункта назначения. Это осуществляется путем созда-
ния записей длиной 32-бит в кэше для записи мар-
шрута, у которого есть пути с одинаковой стоимостью
Распределение нагрузки для каждого пакета не
производится
Механизм CEF строит таблицу коммутации на базе таблицы
маршрутизации. CEF-запись доступна для CEF-коммутации
пакета до тех пор, пока доступна запись о маршруте
Управляется топологией. Создается как точная копия
таблицы маршрутизации
Эффективна для трафика с большим количеством крат-
ковременных потоков, обычно инициированных инте-
рактивными приложениями и Web-приложениями
Механизм CEF производит все рекурсивные поиски
маршрутов до того, как они вставляются в таблицу
коммутации. Лимита на глубину рекурсии нет
Скачков загруженности процессора не происходит. Во
время нестабильности сети производительность не па-
дает. Механизм CEF либо коммутирует пакет, либо от-
брасывает его
Производит распределение нагрузки для каждой пары
“источник — пункт назначения". Осуществляется с по-
мощью хэш-алгоритма, который учитывает как адрес
источника, так и адрес пункта назначения
Производится распределение нагрузки для каждого па-
кета. Осуществляется с помощью хэш-алгоритма, кото-
рый циклически проходит все возможные пути
328
Часть IV. Приложения
Окончание табл, Б.2
коммутация с помощью кэша маршрутов CEF-коммутация
Пакеты, которые необходимо передать на интер- фейс NullO, не поддерживаются механизмом ком- му* ации с помощью кэша маршрутов. Такие пакеты обрабатываются с помощью неэффективного меха- низма коммутации процессов Такие функции, как маршрутизация на основе по- литики, которые нуждаются в поиске маршрута, не поддерживаются явно Не поддерживает распространения QoS-политик Пакеты, которые необходимо передать на интерфейс NullO, могут быть эффективно CEF-коммутированы или отброшены посредством специальной Null-смежности Поскольку CEF-таблица является точной копией табли- цы маршрутизации, маршрутизация на основе полити- ки эффективно поддерживается механизмом CEF Позволяет присоединять информацию QoS-политики к CEF-записи. Пакет может быть CEF-коммутирован с учетом QoS-политики
Резюме
Для современных крупномасштабных IP-сетей и ISP-сетей рекомендуется использовать
механизм коммутации CEF. Для особых режимов коммутации пакетов поддержка некото-
рых функций QoS ограничена. В частности, все распределенные функции QoS, которые
работают на отдельных линейных платах маршрутизатора, а не на плате центрального
процессора, требуют использования распределенного механизма CEF.
Приложение Б. Механизмы коммутации пакетов
329
В этом приложении...
Использование QoS-политик при принятии решения
о маршрутизации у... .< - •'
Распространение QoS-политик с помощью протокола BGP
331
336
Приложение
в
Политики маршрутизации
В этом приложении обсуждаются политики маршрутизации и распространение по-
литики качества обслуживания (quality of service — QoS) с помощью протокола погра-
ничного шлюза (Border Gateway Protocol — BGP). Маршрутизация на основе полити-
ки используется для замены,традиционной функции маршрутизации на основе адреса
пункта назначения более гибким ,механизмом маршрутизации. Для передачи инфор-
мации о политике по сети поставщика услуг механизм распространения QoS-политик
использует протокол BGP. В этом приложении также кратко описана маршрутизация
на основе качества обслуживания.
Использование QoS-политик при принятии
-••у w » at-
решения маршрутизации
Независимо от адреса пунктаназначения решение о маршрутизации, при наличии
. такой возможности, должно приниматься на основе гибких политик и требований к
ресурсам сети. Подобный механизм принятия решения предоставляет сетевому адми-
нистратору средства, позволяющие более эффективно осуществлять маршрутизацию
's- . -й: /' > Н'
трафика в сети.
Маршрутизация на основе качества обслуживания (QoS)
у Маршрутизация на основе QoS (QoS-based routing) — это механизм маршрутизации,
’ в соответствии с которым пути для потоков трафика определяются на основе некото-
рых сведений о наличии ресурсов сети и на основе требований потоков к качеству об-
служивания1. **
Механизм мйрЫрутизации нач
ggOWP^^ |
• Протокол маршрутизациирпередает метрики с динамической информацией о
наличии ресурсов (0о8) (например, информация о доступной полосе пропуска-
ния, уровне потери постов или задержке).
• ПротокщРтйЙрщрутиЙции должен вычислять не только оптимальный путь, но и
^-<^д^у№е"юзможны,^йуги на основе их QoS-доступности.
-политик использует следующие важные
7 A Frameworkfqr QoS-Based Routing in the Intemet/Crawley E. et al. — RFC 2386.
• В каждом потоке передаются сведения о необходимом качестве услуг (QoS).,
QoS-информация может передаваться в байте типа обслуживания (Type of ;
Service — ToS) заголовка IP-протокола. Маршрутный путь для потока выбира-
ется в соответствии с его QoS-требованиями.
Следует отметить, что маршрутизация на основе QoS влечет за собой существен-
ные сложности. По своей природе метрики QoS-доступности очень динамичны. Та-
ким образом, обновления маршрутов происходят более часто, поглощая ценные сете-
вые ресурсы и занимая циклы работы процессора маршрутизатора. Поток может часто
“колебаться” между альтернативными QoS-маршрутами из-за изменений QoS-
метрики нестабильного пути. Более того, частая смена маршрутов может привести к
увеличению дрожания (jitter), т.е. колебания задержек, которые испытывает конечный
пользователь. За исключением упомянутых проблем, маршрутизация на основе QoS
является весьма ценным атрибутом QoS-сети.
Открытый протокол предпочтительного выбора кратчайшего пути (Open Shortest
Path First — OSPF) и протокол обмена информацией о маршрутах между промежуточ-
ными системами (Intermediate System-to-Intermediate System — IS-IS), являющиеся
очень распространенными протоколами внутреннего шлюза (Interior Gateway Proto-
col — IGP) сетей поставщиков услуг, вместе с объявлением о состоянии канала могут
передавать и ToS-байт. Тем не менее на сегодняшний день ToS-байт все еще устанав-
ливается равным нулю и, таким образом, не используется. Тема QoS-маршрутизации
пока что находится в стадии обсуждения организациями по стандартизации.
Между тем протоколы OSPF и IS-IS были расширены с целью поддержки механизма
управления трафиком (Traffic Engineering — ТЕ) на основе технологии многопротокольной
коммутации меток (Multiprotocol Label Switching — MLPS) путем включения информации
о ресурсах канала в объявление маршрута. Несмотря на то что эти протоколы все еще ос-
новываются на адресе пункта назначения, в каждом маршруте теперь находится дополни-
тельная информация, которую такие протоколы, как MPLS, могут использовать для обес-
печения механизма управления трафиком. Протоколы маршрутизации OSPF и IS-IS с ТЕ-
расширениями представляют собой практический компромисс между современными про-
токолами маршрутизации на основе пункта назначения и QoS-маршрутизацией. Более
подробно механизм управления трафиком на основе технологии MPLS обсуждается в гла-
ве 10, “Управление трафиком в сетях MPLS”.
Маршрутизация на основе политики
Сегодня маршрутизация в IP-сетях основывается исключительно на IP-адресе
пункта назначения пакета. Маршрутизация на основе другой информации, переда-
ваемой в заголовке или теле IP-пакета невозможна при использовании современных
динамических протоколов маршрутизации. Для решения этой проблемы и предназна-
чена маршрутизация на основе политики.
Предположим, что поставщику услуг Internet (Internet Service Provider — ISP) может
понадобиться разделить трафик, направляющийся к определенному серверу, на два класса:
с приоритетом 3 (передается по выделенной быстрой линии связи) и с приоритетом 0. Не-
смотря на то что пункт назначения один и тот же, трафик направляется по различным вы-
деленным каналам, соответствующим каждому значению IP-приоритета. Аналогичным об-
разом, маршрутизация может быть основана на длине пакета, адресе источника, потоке,
определенном парой “адрес источника-адрес пункта назначения” и портами протокола
управления передачей (Transmission Control Protocol — TCP) и протокола передачи дата-
332
Часть IV. Приложения
грамм пользователя (User Datagram Protocol — UDP), битами ToS, битами поля IP-
приоритета и т.д. Подобная гибкая схема маршрутизации обычно и называется маршру-
тизацией на основе политики (policy-based routing).
Маршрутизация на основе политики не опирается на какой-нибудь динамический
протокол маршрутизации, а использует локальную статическую конфигурацию мар-
шрутизатора. Она позволяет маршрутизировать трафик на основе определенной поли-
тики, даже если информация о маршруте к пункту назначения потока недоступна,
или вообще игнорируя динамическую информацию о маршруте. Более того, можно
указать маршрутизатору на необходимость установки значения поля IP-приоритета
пакета для трафика, маршрутизируемого на основе политики.
Примечание
Некоторые функции маршрутизации на основе политики, требующие просмотра таб-
лицы маршрутизации, могут эффективно выполняться на маршрутизаторах с под-
держкой механизма скоростной коммутации пакетов Cisco (Cisco Express Forward-
ing — CEF). Более подробно механизм CEF обсуждается в приложении Б, “Механизмы
коммутации пакетов". Так как CEF зеркально отображает каждую запись таблицы
маршрутизации, функция маршрутизации на основе политики может использовать
CEF-таблицу, не производя поиск в таблице маршрутизации.
Если для сбора статистики потока на интерфейсе активизирован режим учета netflow,
необходимо применить команду ip route-cache flow accelerate. С целью сохранения
памяти в записях кэша потока передается его состояние, а проверка политики карты
маршрута для каждого пакета активного потока не проводится. Режим учета netflow
используется для сбора статистики потока трафика.
Поскольку конфигурация маршрутизации на основе политики является статической,
это может привести к отбрасыванию трафика в случае, если сконфигурированная точка
следующей передачи пакета становится недоступной. Для проверки доступности точки
следующей передачи механизм маршрутизации на основе политики может использовать
протокол обнаружения Cisco (Cisco Discovery Protocol — CDP). Когда механизм маршрути-
зации на основе политики не может обнаружить точку следующей передачи в CDP-
таблице, он прекращает передавать соответствующие пакеты в эту точку и перенаправляет
их, используя таблицу маршрутизации. Маршрутизатор возвращается к осуществлению
маршрутизации на основе политики, когда точка следующей передачи опять становится
доступной (это определяется с помощью протокола CPD). Эту функциональность можно
применять только в том случае, если на интерфейсе активизирован протокол CDP.
Практический пример В.1: маршрутизация на основе
IP-приоритета
Компания, занимающаяся электронной коммерцией, подключена к своему поставщику
услуг Internet с помощью высокоскоростного ОБЗ-соединения и низкоскоростного Т1-
канала. Компания использует IP-приоритет для дифференциации различных типов трафи-
ка на основе таких критериев, как тип трафика приложения, важность пользовательского
трафика и т.д. Компания желает использовать скоростной ОБЗ-канал только для передачи
важного трафика с приоритетом 4, 5, 6 или 7. Остальной трафик с более низким IP-
приоритетом должен передаваться по низкоскоростному каналу Т1. На рис. В.1 показан
пример трафика, маршрутизируемого на основе политики.
Приложение В. Политики маршрутизации
333
— 65
IR
211.201.201.64/27
FastEthamat2/0/1
Hssi3/0/0 181.188.10.8/30 10
Sarial4/0/0 181.188.10.12/30 14
[Трафик с приоритатом 0,1, 2, 3]
[Трафик с приоритетом 4, 5, 6, 7]
Поставщик услуг
Рис. В. 1. Трафик, маршрутизируемый на основе политики с учетом значения IP-npuopumema
В листинге В.1 показана конфигурация маршрутизатора Internet (Internet Router —
IR) компании, занимающейся электронной коммерцией, необходимая для маршрути-
зации пакетов на основе значения их IP-приоритета.
Листинг В.1. Конфигурация маршрутизатора IR для маршрутизации >
пакетов на основе значения их IP-приоритета
interface FastEthernet 2/0/1
ip address 211.201.201.65 255.255.255.224
ip policy route-map tasman
any precedence routine
any precadence priority
any precedence immediate
any precedence flash
any precedence flash-override
any precedence critical
any precedence internet
any precedence network
access-list 101 permit ip any
access-list 101 permit ip any
access-list 101 permit ip any
access-list 101 permit ip any
access-list 102 permit ip any
access-list 102 permit ip any
access-list 102 permit ip any
access-list 102 permit ip any
route-map tasman permit 10
match ip address 101
set ip next-hop 181.188.10.14
route-map tasman permit 20
match ip address 102
set ip next-hop 181.188.10.10
Интерфейс FastEthemet2/0/l является входящим интерфейсом для всего внутреннего
трафика. Именно на нем активизирована маршрутизация на основе политики. Все входя-
щие пакеты этого интерфейса маршрутизируются с помощью карты маршрута tasman.
Списки доступа 101 и 102 используются для отбора пакетов со значениями IP-
приоритета 0, 1, 2, 3 и 4, 5, 6, 7 соответственно.
Все пакеты, удовлетворяющие списку доступа 101, передаются в следующую точку
назначения с IP-адресом 181.188.10.14. Все пакеты, удовлетворяющие списку доступа
102, передаются в следующую точку назначения с IP-адресом 181.188.10.10. В лис-
тинге В.2 показаны show-команды, соответствующие механизму маршрутизации на
основе политики.
334
Часть IV. Приложения
Листинг В.2. show-команды, необходимые для проверки конфигурации
и работы механизма маршрутизаций на основе политики
IR#show ip policy
Interface Route map
FastEthernet2/0/l tasman
IR#show route-map tasman
route-map tasman, permit, sequence 10
Match clauses:
ip address (access-lists): 101
Set clauses:
ip next-hop 181.188.10.14
Policy routing matches: 0 packets, 0 bytes
route-map tasman, permit, sequence 20
Match clauses:
ip address (access-lists): 102
Set clauses:
ip next-hop 181.188.10.10
Policy routing matches: 0 packets, 0 bytes
С помошью команды show ip policy можно просмотреть интерфейс(интерфейсы), на
котором активизирована маршрутизация на основе политики для входящих пакетов, а
также соответствующую карту маршрута для каждого из этих интерфейсов. Команда
show route-map tasman выводит подробную информацию о карте маршрута tasman и
статистку пакетов, маршрутизируемых на основе политики, для каждого элемента
(порядкового номера) карты маршрута.
Практический пример В.2: маршрутизация на основе
размера пакета
В компании, предоставляющей банковские услуги через Internet, обнаружили, что
трафик определенных приложений, состояший из пакетов большого размера, замед-
ляет продвижение трафика, необходимого для решения критически важных задач, со-
стояшего из небольших пакетов (1000 и менее байтов). Компания решила отметить
все IP-пакеты размером 1000 и менее байтов с помошью IP-приоритета 5.
В листинге В.З показана конфигурация маршрутизатора, необходимая для установ-
ки значения IP-приоритета пакета в зависимости от его размера.
J Листинг В.З. Конфигурация маршрутизатора, необходимая для установки 3
Г значения IP-приоритета пакета в зависимости от его размера J
interface FastEthernet 4/0/1
ip address 201.201.201.9 255.255.255.252
ip policy route-map tasman
Приложение В. Политики маршрутизации
335
route-map tasman permit 10
match length 32 1000
set ip precedence 5
Всем пакетам размером от 32 до 1000 байт будет назначаться IP-приоритет, равный 5.
Примечание
Рассмотрим несколько полезных советов, касающихся конфигурации механизма мар-
шрутизации на основе политики.
• На каждом интерфейсе можно определить только одну карту маршрута. Однако
вы можете создать несколько элементов карты маршрута с помощью различных
комбинаций команд match и set.
• В карте маршрута механизма маршрутизации на основе политики можно размес-
тить несколько операторов match и set. Когда все условия match будут удовле-
творены, будут выполнены все операторы set.
• Когда в операторе match или set используется несколько параметров, соответст-
вующий оператор выполняется при условии совпадения хотя бы одного из них.
Например, оператор match ip address 101 102 справедлив, если пакет удовле-
творяет либо критерию списка доступа 101, либо критерию списка доступа 102.
Оператор set ip next-hop X Y Z устанавливает IP-адрес точки следующей переда-
чи для всех удовлетворяющих критерию пакетов равным адресу первой доступной
точки назначения (X, Y или Z).
• Команда ip policy route-map используется для активизации механизма маршрути-
зации на основе политики для всего входящего трафика интерфейса маршрутиза-
тора. С целью активизации механизма маршрутизации на основе политики для
трафика, генерируемого маршрутизатором (не транзитного трафика), использует-
ся команда ip local policy route-map.
• На сегодняшний день механизм маршрутизации на основе политики позволяет ис-
пользовать только такие критерии совпадения пакетов, как списки доступа IP и
длина пакета.
• Ниже приведен порядок выполнения команд, использующихся механизмом мар-
шрутизации на основе политики.
set precedence/tos
set ip next-hop
set interface
set ip default next-hop
set default interface
Распространение QoS-политик с помощью
протокола BGP
Значение IP-приоритета пакета указывает на предназначенную для него QoS-
политику. Но как и когда эта QoS-политика реализуется в виде предоставления услуг?
В самом простом случае машина-источник устанавливает значение IP-приоритета
пакета, после чего тот передается без изменений локальным и всеми промежуточны-
336
Часть IV. Приложения
ми поставщиками услуг до тех пор, пока не достигнет пункта назначения. Следует
отметить, что этот вариант не является ни реальным, ни, в некоторым смысле, при-
емлемым. В большинстве случаев исходный поставщик услуг ограничивает входящий
трафик и его уровень обслуживания для того, чтобы удостовериться, что они не вы-
шли за рамки установленного профиля трафика.
Локальный по отношению к машине-источнику поставщик услуг может гаранти-
ровать определенный уровень обслуживания, заданный на основе IP-приоритета,
внутри своей сети. Однако после того как пакет покидает сеть локального поставщика
услуг и переходит в другую сеть, подсоединенную к пункту назначения, исходный по-
ставщик услуг уже не может гарантировать определенный уровень обслуживания до
тех пор, пока он не заключит определенное соглашение об уровне обслуживания
(Service Level Agreement — SLA) для своего трафика с другими поставщиками услуг.
В этом разделе не рассматриваются подробности распространения QoS-политик среди
поставщиков услуг, так как оно зависит от заключенных между поставщиками услуг со-
глашений SLA. Мы сконцентрируем свое внимание на распространении информации о
QoS-политиках в сетях клиентов поставщика услуг. Весь входящий или исходящий трафик
клиента получает свою QoS-политику (IP-приоритет) в точке входа в сеть поставщика. Как
обсуждалось ранее, пограничный маршрутизатор поставщика услуг, подсоединенный к
клиенту, может устанавливать QoS-политику путем установки значения поля IP-
приоритета пакета на основе его уровня обслуживания. Значение приоритета используется
для указания уровня обслуживания пакета устройствам сети поставщика услуг.
Поскольку Intemet-трафик асимметричен, трафик, предназначенный для важного
клиента, может поступить к его поставщику услуг через любой из его пограничных
маршрутизаторов. Возникает вопрос: как сделать так, чтобы все маршрутизаторы в се-
ти поставщика услуг распознавали входящий трафик важного клиента и устанавлива-
ли значение IP-приоритета пакетов, основываясь на его уровне обслуживания? В этом
разделе рассматриваются способы использования протокола BGP для распростране-
ния QoS-политик, предназначенные специально для решения подобных ситуаций.
Распространение QoS-политик с помошью протокола BGP2 — это механизм класси-
фикации пакетов на основе информации об IP-префиксе, BGP-сообществе и пути авто-
номной системы (autonomous system — AS) BGP. Поддерживаемые политики классифи-
кации включают в себя установку IP-приоритета и способность отмечать пакет с помо-
щью внутреннего для маршрутизатора идентификатора QoS-класса — QoS-группой (QoS
group). После того как пакет был классифицирован, можно воспользоваться другими ме-
ханизмами QoS, например механизмом согласования скорости доступа (Committed Ac-
cess Rate — CAR) или взвешенным алгоритмом произвольного раннего обнаружения
(Weighted Random Early Detection — WRED) для реализации бизнес-политик и форми-
рования бизнес-модели. Более подробно алгоритмы CAR и WRED обсуждаются в
главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка
пакетов и управление интенсивностью трафика”, и в главе 6, “РНВ-политика:
предотвращение перегрузки и политика отбрасывания пакетов”.
Распространение QoS-политик с помощью протокола BGP требует функциониро-
вания механизма коммутации CEF. Более подробно CEF-коммутация обсуждается в
приложении Б, “Механизмы коммутации пакетов”. Любая QoS-политика BGP пере-
дается из таблицы маршрутизации BGP в CEF-таблицу через таблицу маршрутизации
1Р. Запись CEF-таблицы для префикса пункта назначения отмечается с помощью
2 Border Gateway Protocol 4 (BGP-4)/Rekhter К, Li T. — RFC 1771.
Приложение В. Политики маршрутизации
337
QoS-политики BGP. Во время CEF-коммутации пакета QoS-политика применяется к
пакету согласно информации в CEF-таблице.
Практический пример В.З: применение политики QoS
для входящего и исходящего трафика
Поставщик услуг Internet (ISP), использующий в своей сети QoS-политики, начал
предлагать своим клиентам обслуживание за дополнительную плату. Последнее пред-
полагает более высокий приоритет обслуживания для входящего и исходящего трафи-
ка важных клиентов по сравнению с остальным трафиком сети, который передается
методом негарантированной доставки.
QoS-политики поставщика услуг Internet предполагают дифференциацию трафика
на основе IP-приоритета, обеспечивая самый высокий приоритет обслуживания тра-
фику со значением IP-приоритета 7, а самый низкий — трафику, передаваемому ме-
тодом негарантированной доставки (приоритет 0). При этом трафику важных клиен-
тов назначается IP-приоритет 4. Реализация дифференцированных услуг в сети ISP
схематически показана на рис. В.2.
Рис. В.2. Политика IP QoS для входящего и исходящего Internet-трафика
В данном примере поставщик услуг должен реализовать следующую конфигурацию.
1. Трафик важного клиента, предназначенный для передачи в Internet, должен по-
лучать улучшенное обслуживание внутри сети поставщика услуг. С этой целью
на входе в сеть поставщика услуг данному трафику необходимо присвоить при-
оритет 4, вследствие чего он будет получать улучшенное обслуживание во всей
сети поставщика услуг.
2. Internet-трафику, предназначенному для передачи в сеть важного клиента, необ-
ходимо присвоить приоритет 4 в точке входа в сеть поставщика услуг: в маршру-
тизаторе BR-1, BR.-2 или BR.-3. Трафик с IP-приоритетом 4 получает улучшен-
ное обслуживание во всей сети поставщика услуг.
338
Часть IV. Приложения
Маршрутизатор BR-2 подключен к сети важного клиента (см. рис. В.2). Следова-
тельно, весь входящий трафик, передающийся по соединению с важным клиентом,
получает улучшенное обслуживание в сети поставщика услуг. Улучшенное обслужива-
ние идентифицируется IP-приоритетом 4 в заголовке пакета. Входящий Internet-
трафик, предназначенный для передачи в сеть важного клиента, может поступать ли-
бо через маршрутизатор BR-1, либо через маршрутизатор BR-3, так как они оба под-
ключены к остальной части Internet. Всему трафику, идущему через маршрутизатор
BR-1 или BR-3 в сеть важного клиента, необходимо присвоить IP-приоритет 4.
В листинге В.4 показана соответствующая конфигурация маршрутизатора BR-3.
! Листинг В.4. Конфигурация маршрутизатора BR-3, предполагающая акти-
! визирование механизма распространения QoS-политик
> с помощью протокола BGP
ip cef
interface loopback О
ip address 200.200.200.3 255.255.255.255
interface Serial4/0/l
ip address 201.201.201.10 255.255.255.252
bgp-policy source ip-prec-map
interface Hssi3/0/0
bgp-policy destination ip-prec-map
interface Serial4/0/0
bgp-policy destination ip-prec-map
ip bgp-community new-format
router bgp 109
table-map tasman
neighbor 200.200.200.1 remote-as 109
neighbor 201.201.201.10 remote-as 4567
neighbor 201.201.201.10 route-map premium in
route-map tasman permit 10
match as-path 1
set ip precedence 4
route-map premium permit 10
set community 109:4
ip as-path access-list 1 permit л4567$
С помощью команды route-map tasman на маршрутизаторе BR-3 устанавливается
приоритет 4 для всех маршрутов с AS-путем 4567. В данном случае есть только один
такой маршрут— 194.194.194.0/24, который принадлежит автономной системе 4567.
Следовательно, для этого маршрута в таблице маршрутизации протокола IP устанав-
Приложение В. Политики маршрутизации
339
ливается IP-приоритет 4, а затем эта информация переносится в CEF-таблицу. Более
того, с помошью команды route-map premium маршрутам, полученным из сети важ-
ного клиента, назначается атрибут сообшества 109:4. Используя эти сведения, мар-
шрутизаторы сети поставщика услуг смогут назначать соответствуюшие политики.
Обратите внимание, что команда bgp-policy source ip-prec-map используется на ин-
терфейсе Serial4/0/l, вследствие чего механизм распространения QoS-политик с по-
мошью протокола BGP применяется ко всем пакетам важного клиента. Отображение
IP-приоритета осуществляется на основе адреса источника входящего пакета с помо-
шью значения приоритета, ассоциированного с соответствуюшей CEF-записью для
IP-адреса источника. Intemet-трафик, предназначенный для передачи в сеть важного
клиента, может входить в сеть его поставшика услуг через любой из пограничных
маршрутизаторов, имеющих соединение с сетями других поставщиков услуг. Следова-
тельно, информация о QoS-политике, относящаяся к важному клиенту, должна быть
распространена по всей сети поставшика услуг для того, чтобы пограничные маршру-
тизаторы могли на ее основе устанавливать значение IP-приоритета. В данном приме-
ре Internet-трафик, предназначенный для передачи в сеть важного клиента, может по-
ступать либо через маршрутизатор BR-1, либо через маршрутизатор BR-3.
Трафику важного клиента, поступаюшему на интерфейсы Hssi3/0/0 и Serial4/0/0
маршрутизатора BR-3, назначается приоритет 4. Чтобы механизм распространения
QoS-политик с помошью протокола BGP применялся для всех входяших пакетов, на
входяшем для пакетов интерфейсе необходимо применить команду bgp-policy
destination ip-prec-map. Отображение IP-приоритета осуществляется на основе адреса
точки назначения входящего пакета с помошью значения приоритета, ассоциирован-
ного с соответствуюшей CEF-записью для IP-адреса точки назначения.
В листинге В.5 показана соответствуюшая конфигурация маршрутизатора BR-1.
! Листинг В.5. Конфигурация маршрутизатора BR-1, предполагающая '
активизирование механизма распространения QoS-политик
с помощью протокола BGP для обеспечения приоритетного
обслуживания трафика важного клиента
ip cef
interface hssi 3/0/0
bgp-policy destination ip-prec-map
ip bgp-community new-format
router bgp 109
table-map tasman
neighbor 200.200.200.3 remote-as 109
route-map tasman permit 10
match community 101
set ip precedence 4
ip community-list 101 permit :4$
Команда table-map использует карту маршрута tasman для назначения приоритета 4
всем имеющимся в таблице маршрутизации BGP-маршрутам с атрибутом BGP-
340
Часть IV. Приложения
сообщества, последние два байта которого установлены в 4. Так как маршрутизатор
BR-3 отмечает маршрут 194.194.194.0/24 сети важного клиента с помощью атрибута
BGP-сообщества 109:4 и обменивается им посредством протокола IBGP с маршрути-
заторами BR-1 и BR-2, маршрутизатор BR-1 отмечает префикс 194.194.194.0/24 в сво-
ей таблице маршрутизации IP и CEF-таблице с помощью IP-приоритета 4.
Для того чтобы механизм распространения QoS-политик с помощью протокола
BGP применялся для всех поступающих из Internet пакетов на основе IP-адресе пунк-
та назначения, на входящем интерфейсе HSSI3/0 маршрутизатора BR-1 должна быть
применена команда bgp-policy destination ip-prec-map.
Резюме
В больших, динамически маршрутизируемых окружениях растет необходимость в
применении функций качества обслуживания и управления трафиком. Возможность
механизма маршрутизации на основе политики выборочно устанавливать биты при-
оритета и маршрутизировать пакеты, основываясь на ранее определенных гибких по-
литиках, становится очень важной. В то же время такие протоколы маршрутизации,
как OSPF и IS-IS, снабжаются расширениями, позволяющими обеспечить поддержку
механизма QoS. Так, протоколы OSPF и IS-IS были расширены для передачи инфор-
мации о доступных ресурсах вместе с объявлениями о состоянии канала, что является
большим шагом к реализации полноценного механизма маршрутизации на основе
QoS-политик. Тем не менее жизнеспособность механизма маршрутизации на основе
QoS-политик все еще обсуждается различными организациями по стандартизации.
Протокол BGP может облегчить распространение QoS-политик по всей сети. Меха-
низм CEF получает информацию о BGP-политике из таблицы маршрутизации и исполь-
зует ее для установки политики пакета перед тем, как передать его дальше по сети.
Приложение В. Политики маршрутизации
341
Транспортный протокол
реального времени (RTP)
Транспортный протокол реального времени (Real-time Transport Protocol — RTP) пред-
назначен для передачи по IP-сетипотоков трафика масштаба реального времени, такого,
' , как объединенные в пакеты аудио-и видеоданные1. Протокол RTP имеет стандартный
формат заголовка, включающий в сёбя, кроме всего прочего, порядковый номер, обуслов-
<; ленную средой передачи временнуюметку, идентификатор источника и идентификатор
полезной нагрузки. Как правило, притранспортировке данных протокол RTP полагается
на протокол передачи датаграмм пользователя (User Datagram Protocol — UDP).
Дополнением к протоколу RTP является протокол управления передачей реального
времени (Reaktime Transfer Control Protocol — RTCP), ответственный за передачу
управляющей информации о текущем RTP-сеансе. RTCP-пакеты используются для
передачи информации о состоянии RTP-канала, такой, как объем переданных и каче-
ство принятых данных. Протокол RTP может использовать эту информацию для ана-
лиза статистики потери пакетов, полученной с помощью RTCP, и требовать от источ-
ника соответствующим образом адаптировать интенсивность передачи данных.
В протокол RTCP включена поддержка проходящих в режиме реального времени
конференций для большого числа участников. RTP позволяет объединять потоки тра-
фика с различными источниками в один агрегированный поток, после чего каждый
пакет, вошедший в это объединение, будет содержать в себе информацию обо всех
источниках агрегированного потока данных.
Временные метки протокола RTP зависят от потока и, следовательно, единица их
измерения обусловлена средой передачи потока. Когда несколько различных потоков
объединяются в один, временные .Метки RTP не могут обеспечить синхронизацию
объединенного потока. Для обеспечения взаимосвязи между часами реального време-
ни источника и временными метками RTP используется протокол RTCP. Кроме это-
.го, протокол RTCP может обеспечить передачу описательной текстовой информации
об источнике в конференции.
Следует отметить, что протокол RTP не предполагает резервирование ресурсов или
обеспечение качества обслуживания (QoS); вместо этого, он полагается на такие механиз-
мы распределения ресурсов, как WFQ (Weighted Fair Queing — взвешенный алгоритм рав-
номерного обслуживания очередей), и на такие протоколы резервирования ресурсов, как
RSVP (Resource Reservation Protocol — протокол резервирования ресурсов).
7 RTP: A Transport Protocol for Real-Time Applications, RFC 1889/Jacobson V, January 1996.
В этом приложении...
Алгоритм Нагля
Функция определения максимально возможной единипы
передачи данных (MTU) пути ‘
Сжатие заголовка ТСР/1Р ’
Сжатие RTP-заголовка »
345
346
346
346
Приложение
д
Общие функции линейной
эфективности протокола IP
' ' " , Л/-
S -л
В этом приложении рассматриваются следующие функции линейной эффективно-
сти протокола IP (Internet Protocol): алгоритм Нагля (Nagle Algorithm), функция опре-
деления максимально возможной • единицы передачи данных пути (Path maximum
transmission unit (MTU) Discovery),г сжатие заголовка TCP/IP (Transmission Control
Protocol/Internet Protocol) и сжатие заголовка RTP (Real-time Transport Protocol).
Алгоритм Нагля
Терминальные приложения/ такие, как telnet и rlogin, генерируют 41-байтовые пакеты
(40 байт — длина пакета IP, и 1 байт — TCP-заголовок) для каждого байта пользователь-
ских данных. Использование пакетов столь небольшого объема, известных также под на-
званием миниграмм (tinygrams), не является проблемой в локальных сетях (LAN), однако
такие пакеты могут существенно уменьшить доступную полосу пропускания на медленных
; или перегруженных каналах передачи информации. Главная задача алгоритма Нагля1 —
повышение эффективности использования полосы пропускания для ТСР-трафика.
Ниже приводится описание TCP-сеанса в соответствии с алгоритмом Нагля. Каж-
дое TCP-соединение может иметь только один незавершенный (или, другими слова-
ми, неподтвержденный) сегмент. Пока ожидается подтверждение (acknowledgement —
АСК), происходит процесс накопления дополнительных данных, которые передаются
при получении подтверждения как один сегмент. Вместо передачи информации по
одному символу, TCP-сеанс старается сформировать большой сегмент путем накопле-
ния символов и отправить его сразу же после получения подтверждения о доставке
предыдущего сегмента. Механизм: самосинхронизации позволяет TCP-сеансу отправ-
лять меньше сегментов по медленным или перегруженным каналам связи по сравне-
нию с быстрыми и незагруженными каналами.
Алгоритм Нагля активизируется с помощью команды service nagle. Несмотря на то
что эффективность этого алгоритма может быть невысокой в случае применения к
трафику терминальных приложений на медленных или перегруженных каналах, в це-
лом он зарекомендовал себя великолепно для большей части ТСР-трафика.
1 Congestion Control in IP/TCP Internetworks/Nagle J., 1984. — RFC 896.
Функция определения максимально возможной
единицы передачи данных (MTU) пути
Функция определения максимально возможной единицы передачи данных пути2
используется для динамического определения значения MTU на всем пути от источ-
ника то точки назначения. Она помогает предотвратить или по крайней мере умень-
шить фрагментацию пакетов в сети, используюшей различные технологии передачи
канального уровня, тем самым повышая доступную полосу пропускания.
Для того чтобы определить MTU пути, станция-источник посылает пункту назначения
один большой пакет с установленным битом DF (Don’t Fragment — “не
фрагментировать”) в IP-заголовке. Когда маршрутизатор или коммутатор, встретившийся
на пути пакета, пытается коммутировать его в канал с меньшим значением MTU, он от-
сылает источнику сообщение протокола ICMP (Internet Control Message Protocol — прото-
кол управляющих сообщений Internet) “Can’t Fragment” (“He могу фрагментировать”). Ис-
точник, получив ICMP-сообшение “Can’t Fragment”, уменьшает размер пакета и пытается
определить MTU пути заново. Если же источник не получил ICMP-сообшение “Can’t
Fragment”, он использует текущее значение MTU в качестве значения MTU всего пути.
С целью активизирования функции определения MTU пути для инициированных
маршрутизатором TCP-соединений используется команда ip top path-mtu-discovery.
Сжатие заголовка TCP/IP
Сжатие заголовка TCP/IP3 применяется для повышения эффективности использова-
ния полосы пропускания медленных последовательных каналов передачи информации.
Типичный ТСР/1Р-пакет включает в себя 20-байтовые заголовки IP и TCP. После уста-
новки TCP-соединения информация заголовка становится избыточной и не требует пе-
ресылки в каждом пакете. Путем изменения заголовка, который теперь будет включать в
себя идентификатор соединения и информацию об изменившихся полях, можно до-
биться уменьшения объема передаваемых пакетов. В среднем размер сжатого TCP/IP-
заголовка составляет 10 байт в отличие от 40 байт в несжатом состоянии.
Для активизации механизма сжатия TCP-заголовка на интерфейсе используется
команда ip tcp header compression.
Сжатие RTP-заголовка
Как правило, размеры RTP-пакетов аудиоприложений варьируются в пределах от 20
до 150 байт при условии сжатия полезной нагрузки. Типичный уровень избыточности
информации, содержащейся в IP-, UDP- и RTP-заголовках, достаточно высок. Мини-
мальная длина IP/U DP/RTP-заголовка составляет 40 байт, если считать, что минималь-
ная длина IP-, UDP- и RTP-заголовка равна 20, 12 и 8 байт, соответственно.
Механизм сжатия RTP-заголовка4, реализация которого напоминает реализацию
механизма сжатия TCP-заголовка (RFC 1144), в среднем позволяет сжать 40-байтовый
заголовок до 10 байт.
2 Path MTU Discovery/Deering S. et a!., 1990. — RFC 1191.
3 Compressing TCP/IP Headers for Low-Speed Serial Links/Jacobson V, 1990. — RFC 1144.
4 Compressing 1P/UDP/RTP Headers for Low-Speed Serial Links/Casner S., Jacobson V., 1999. —
RFC 2508.
346
Часть IV. Приложения
Приложение
Е
Фрагментация и чередование
пакетов на канальном уровне
В этом приложении рассматривается функция фрагментации и чередования паке-
тов канального уровня (Link-Layer Fragmentation and Interleaving — LFI) с использова-
нием многоканального двухточечного протокола (Multi-Link Point-to-Point — MLPP).
Механизм канального уровня LFI, позволяет повысить эффективность и предсказуе-
мость услуг, предоставляемых для критического трафика приложений.
Протокол MLPP1 позволяет распределить трафик по нескольким РРР-каналам
глобальных сетей (Wide Area Network,— WAN), обеспечивая при этом функциональ-
ную совместимость устройств разных производителей, а также фрагментацию и упо-
рядочение пакетов. В главе 8, “Качество обслуживания на уровне 2: межсетевой
обмен с IP QoS”, рассматривался стандарт FRF.12, описывающий функции фрагмен-
тации и чередования пакетов в сетях Frame Relay.
Даже несмотря на применение таких алгоритмов планирования очередей, как CBWFQ
(Class-Based Weighted Fair Queuing — взвешенный алгоритм равномерного обслуживания
очередей на основе класса) с приоритетной очередью и протокола RSVP (Resource Reserva-
tion Protocol — протокол резервирования ресурсов), интерактивный трафик масштаба ре-
ального времени все еще может испытывать существенные задержки блокирования, вы-
званные наличием пакетов большого размера, в особенности на медленных последова-
тельных линиях связи. Если пакет голосового трафика поступил в маршрутизатор в
момент обработки некоторого другого пакета большого размера, то обработка пакета голо-
сового трафика будет отложена до тех пор, пока не будет передан большой пакет. Естест-
венно, подобная схема является абсолютно неприемлемой для трафика масштаба реаль-
ного времени, такого, как трафик интерактивных приложений, ориентированных на пере-
дачу оцифрованного голоса. Следует отметить, что эффективная работа последних
достигается при условии сквозной задержки не более 100-150 мс.
Механизм LFI предполагает фрагментацию кадров большого размера и их чередо-
вание с маленькими, чувствительными к задержке, кадрами, перед постановкой в оче-
редь на передачу. Такой подход позволяет существенно уменьшить задержку при пе-
редаче маленьких пакетов трафика масштаба реального времени. Следует также отме-
тить, что фрагментированные кадры восстанавливаются в точке назначения.
7 The PPP Multilink Protocol (MP)/Sklower К. et al., 1994. — RFC 1717.
Для обеспечения надлежащего уровня обслуживания голосового трафика масштаба
реального времени механизм LF1 может использоваться совместно с механизмом
CBWFQ с приоритетной очередью (рис. 1.1).
Рис. Е. 1. Иллюстрация работы механизма фрагментации и чередования пакетов канального уровня
Как показано на рис. Е.1, голосовой трафик масштаба реального времени ставится
на обработку в приоритетную очередь. Весь остальной трафик обрабатывается с по-
мощью одной или нескольких очередей механизма WFQ (Weighted Fair Queuing —-
взвешенный алгоритм равномерного обслуживания очередей). Пакеты, принадлежа-
щие обычному трафику, фрагментируются с целью уменьшения задержки блокирова-
ния при обработке пакетов голосового трафика. Фрагменты пакетов трафика данных
ставятся на обработку в WFQ-очереди, которые вместе с очередью голосового трафика
обслуживаются в соответствии с алгоритмом CBWFQ с приоритетной очередью. Те-
перь максимальная задержка блокирования пакетов голосового трафика равняется за-
держке сериализации фрагментированных пакетов обычного трафика данных. В
табл. Е.1 отражена зависимость размеров фрагментов от скорости канала передачи
информации при задержке блокирования 10 мс.
Таблица Е.1. Зависимость размеров фрагментов от скорости канала
. передачи информации при задержке блокирования 10 мс
Скорость линии связи, Кбит/с
Размер фрагмента, байт
56 70
64 80
128 160
256 320
512 640
768 1000
Механизм LFI гарантирует, что голосовые и другие пакеты небольшого разме-
ра не будут неприемлемо долго блокироваться пакетами большого размера. Кроме
того, LFI старается обеспечить более равномерную передачу маленьких пакетов,
тем самым снижая их дрожание. Подобная функциональность позволяет сети эф-
фективно передавать обычный трафик совместно с голосовым и другим чувстви-
тельным к задержке трафиком.
350
Часть IV. Приложения
Примечание
Как уже отмечалось, механизм MLPP LFI используется совместно с механизмом
CBWFQ для минимизации задержки голосового трафика, обрабатывающегося с по-
мощью приоритетной очереди. В листинге Е.1 приведена соответствующая конфигу-
рация маршрутизатора.
В этом примере конфигурация MLPP-связки применяется к интерфейсу virtual-
template. Интерфейсы SerialO и Serial! включаются в MLPP-связку с помощью
команды ppp multilink. Отметьте, что механизм CBWFQ активизируется на интерфей-
се virtual-template, а не на входящих в MLPP-связку физических интерфейсах. Команда
ppp multilink fragment-delay 20 используется для ограничения задержки голосового
трафика значением в 20 мс. Для указания на необходимость чередования голосовых
пакетов и фрагментов больших пакетов используется команда ppp multilink
interleave. С цепью строгого приоритетного обеспечения полосы пропускания для го-
лосового трафика используется CBWFQ-политика premiumpolicy.
* Листинг Е.1. Конфигурация механизма MLPP LFI
class-map premium
match <voice packets>
policy-map premiumpolicy
class premium
priority 500
interface serialO
bandwidth 128
no fair-queue
ppp multilink
interarface seriall
bandwidth 128
no fair-queue
ppp multilink
interface virtual-template 1
service-policy output premiumpolicy
ppp multilink
ppp multilink fragment-delay 20
ppp multilink interleave
Приложение E. Фрагментация и чередование пакетов на канальном... 351
Приложение
ж
Значения поля IP-приоритета
и поля DSCP
| Р2 | Р1 | РО CU |
IP-приоритет: 3 бит (Р2-Р0)
Тип обслуживания (ToS): 4 бит (ТЗ-ТО)
Не используется (CU): 1 бит
Рис. Ж.1. Биты поля приоритета протокола IP (Internet
Protocol) в байте типа обслуживания (Type of Serv-
ice — ToS)
: Таблица Ж.1. Таблица значений поля IP-приоритета
Значение поля IP- приоритета Биты IP-приоритета • Название IP- приоритета Значение байта ToS
0 ООО Стандартный 0(0x00)
1 001 . Приоритетный 32 (0x20)
010 м Немедленный 64 (0x40)
3 011 Срочный 96 (0x60)
4 100 Сверхсрочный 128 (0x80)
5 101 Критический 160 (0хА0)
6 110 Межсетевое управление 192 (ОхСО)
7 111 Сетевое управление 224 (ОхЕО)
| DS5 | DS4 | DS3 | DS2 | DS1 | DSO | CU | CU |
Код дифференцированной услуги (DSCP): 6 бит (DS5-DS0)
Не используется (CU): 2 бит
Рис. Ж.2. Биты поля кода дифференцированной услуги
(Differentiated Services Code Point — DSCP) в байте
дифференцированного обслуживания (Differentiated
Services — DS)
Предопределенные значения поля DSCP:
• стандартный код DCSP ООО 000;
• селекторы класса;
Таблица Ж.2. Селекторы класса
Селектор класса DSCP
Приоритет 1 Приоритет 2 Приоритет 3 Приоритет 4 Приоритет 5 Приоритет 6 Приоритет 7 001 000 010 000 011 000 100 000 101 000 110 000 111 000
• РНВ-политика немедленной передачи (Expedited Forwarding — EF): I0III0;
• РНВ-политика гарантированной передачи (Assured Forwarding — AF).
Таблица Ж.З. РНВ-политика гарантированной передачи
Приоритет отбрасывания пакета Класс 1 Класс 2 Класс 3 Класс 4
Низкий 001010 010010 011010 100010
Средний 001100 010100 011100 100100
Высокий 001110 010110 011110 100110
Отображение между значениями поля IP-приоритета и значениями поля DSCP:
• в табл. Ж.4 показано отображение поля IP-приоритета на поле DSCP;
Таблица Ж.4. Отображение поля IP-приоритета на поле DSCP
IP-приоритет DSCP
О О
1 8
2 16
3 24
4 32
5 40
6 48
7 56
• в табл. Ж.5 показано отображение поля DSCP на поле IP-приоритета.
354
Часть IV. Приложения
Таблица Ж.5. Отображение поля DSCP на поле IP-приоритета \ Л 3
i , . . . „ . _ __ •
DSCP IP-приоритет
0-7 0
8-15 16-23 24-31 32-39 40-47 48-55 56-63 1 2 3 4 5 6 7
Приложение Ж. Значения поля IP-приоритета и поля DSCP
355
Предметный указатель
A D
Address Extension (АЕ), 217
Address Resolution Protocol (ARP), 317
AF PHB, 45
Application-Specific Integrated Circuit
(ASIC), 68
Assured Forwarding (AF), 41; 354
Asynchronous Transfer Mode (ATM),
199; 309
ATM Adaptation Layer (AAL), 200
Available Bit Rate (ABR), 203
В
Backward Explicit Congestion Notification
(BECN), 74; 217
Border Gateway Protocol (BGP), 57; 331
c
Cell Loss Priority (CLP), 201
Cisco Discovery Protocol (CDP), 333
Cisco Express Forwarding (CEF), 29; 317
Class-Based Weighted Fair Queuing
(CBWFQ), 98; 108
Command and Respond (C/R), 217
Command-Line Interface (CLI), 309
Committed Access Rate (CAR), 54; 309
конфигурация, 56; 59
ограничение трафика, 62
Committed Delivery Rate (CDR), 268
Committed Information Rate (CIR), 218;
268
Common Open Policy Service (COPS),
47
Congestion Experienced (CE), 167
Constant Bit Rate (CBR), 202
Customer Edge Router, 259
Data Terminal Equipment (DTE), 217
Data-Link Connection Identifier (DLCI)
217
Deficit Round Robin (DRR), 107; 132
Designated SBM (DSBM), 235
Differentiated Service Code Point (DSCP),
309
Differentiated Services (DS), 353
Differentiated Services Code Point
(DSCP), 28; 38; 353
diffserv, 38
Discard Eglible (DE), 217
Distributed Cisco Express Forwarding
(DCEF), 106; 321
Distributed Traffic Shaping (DTS), 76
Distributed Weighted Fair Queuing
(DWFQ), 106
Don’t Fragment (DF), 346
DS-байт, 38
E
Early Packet Discard (EPD), 204
EF PHB, 44
Enterprise Resource Planning (ERP), 221
Excess Information Rate (E1R), 218
Expedited Forwarding (EF), 41; 354
Explicit Congestion Notification
(ECN), 153
Explicitly Routed Label Switched Path
(ER-LSP), 285
F
Fair Queuing (FQ), 89
Fiber Distributed Data Interface
(FDDI), 72
File Transfer Protocol (FTP), 21; 105;
185; 313
First In, First Out (FIFO), 91
First-In, First-Out (FIFO), 24
Fixed Filter (FF), 183
FlowSpec, 183
Forward Explicit Congestion Notification
(FECN), 74; 217
Frame Check Sequence (FCS), 217
Frame Relay, 216
выравнивание интенсивности
трафика, 82
межсетевой обмен Frame Relay и IP
QoS, 223
фрагментация, 221
Frame Relay Access Device (FRAD), 221
Frame Relay Forum (FRF), 221
Frame Relay Traffic Shaping (FRTS),
218; 309
G
Generalized Processor Sharing (GPS), 94
Generic Traffic Shaping (GTS), 76; 309
Guaranteed Bandwidth (GB), 271
H
Header Error Control (НЕС), 201
High-Speed Serial Interface (HSSI), 112
I
Institute of Electrical and Electronic
Engineers (IEEE), 30
Institute of Electrical and Electronics
Engineers (IEEE), 232
Integrated Services (intserv), 25
Integrated Services over Specific Lower
Layers (ISSLL), 235
Interim Local Management Interface
(ILMI), 210
Interior Gateway Protocol (IGP), 332
Interior Gateway Routing Protocol
(IGRP), 288
Intermediate System-to-Intermediate
System (IS-IS), 278; 332
Internet Control Message Protocol
(ICMP), 72
Internet Engineering Task Force
(IETF), 25; 37
Internet Protocol (IP), 309
IP-приоритет, 53
история возникновения и развития
QoS, 23
Internet Router (IR), 334
Internet Service Provider (ISP), 321
intserv, 25; 37
IP-приоритет, 53; 333
L
Label Distribution Protocol (LDP), 244
Label Edge Router (LER), 242
Label Information Base (LIB), 242
Label Switched Path (LSP), 277
Label Switching Router (LSR), 242
Link State Advertisement (LSA), 288
Link-Layer Fragmentation and
Interleaving (LFI), 349
M
Maximum Burst Size (MBS), 203
Maximum Segment Size (MSS), 154
Media Access Control (MAC), 310
MINCIR, 219
Minimum Cell Rate (MCR), 203
Modified Deficit Round Robin (MDRR),
131; 140
Modified Weighted Round Robin (MWRR),
131
Multi-Link Point-to-Point (MLPP), 349
Multilink Point-to-Point (MLPP), 124
Multiprotocol Label Switching (MLPS),
332
Multiprotocol Label Switching (MPLS),
31; 241; 277; 309
N
Network Based Application Recognition
(NBAR), 52
Network File System (NFS), 178
Network Layer Reachability Information
(NLRI), 258
Предметный указатель
357
Network-to-Network Interface
(NNI), 200
Non-Real Time Variable Bit Rate
(nRT-VBR), 203
О
Open Shortest Path First (OSPF),
278; 319
P
Partial Packet Discard (PPD), 204
PATH, 181
PATH ERROR, 181
Path State Block (PSB), 181; 237
PATH TEARDOWN, 181
Payload Type Identifier (PTI), 201
Peak Cell Rate (PCR), 201
Per-Interface Rate Configuration (PIRC),
68
Permanent Virtual Circuit (PVC), 75; 199
РНВ-политика, 39; 43
РНВ-политика гарантированной
доставки пакетов (AF PHB), 45
РНВ-политика немедленной передачи
пакетов (EF РНВ), 44
Point of Presence (POP), 289
Policy Decision Point (PDP), 47
Policy Enforcement Point (PEP), 47
Policy-Based Routing (PBR), 54
Priority Queue (PQ), 106
Provider Edge Router, 259
Provider Router, 259
Q
QoS Policy Propagation using BGP
(QPPB), 317
QoS Policy Propagation using Border
Gateway Protocol (QPPB), 54
установка IP-приоритета, 57
установка поля QoS-группы, 59
R
Random Early Detection (RED), 153
Real-time Transfer Control Protocol
(RTCP), 343
Real-time Transport Protocol (RTP), 123;
343
Real-Time Variable Bit Rate (RT-VBR),
203
Resource Management (RM), 203
Resource Reservation Protocol (RSVP),
38; 177
RSVP-компоненты, 180
RSVP-сообщения, 181
TE-RSVP, 277
гарантированная битовая скорость,
185
использование протокола RSVP
только в узлах VPN-облака, 270
масштабируемость, 186
расширения RSVP, 237
регулируемая нагрузка, 185
среда передачи, 186
стили резервирования, 182
RESV, 181
RESV CONFIRM, 181
RESV ERROR, 181
RESV TEARDOWN, 181
Retransmit Timer Timeout (RTT), 154
Route Distinguisher (RD), 258
Route Target (RT), 259
Routing by Resource Reservation (RRR),
277
s
Segmentation and Reassembly (SAR), 200
Selective Packet Discard (SPD), 153
Sequence Number (SN), 95
Service Level Agreement (SLA), 337
Shared Explicit (SE), 183
Shortest Path First (SPF), 285
Slow Start Threshold (ssthresh), 154
Source of Origin (SOO), 259
Source Route Object (SRO), 285
Static Random Access Memory (SRAM),
108
Subnet Bandwidth Manager (SBM), 235
Sustainable Cell Rate (SCR), 201
Switched Virtual Circuit (SVC), 75; 199
358
Предметный указатель
Synchronous Optical Network (SONET),
147
T
TE-RSVP, 277
Time-to-Live (TTL), 304
Traffic Engineering (ТЕ), 277; 332
Traffic Shaping (TS), 61
Transmission Control Protocol (TCP),
181; 332
Transmission Control Protocol/Internet
Protocol (TCP/IP), 23
Type of Service (ToS), 38; 138; 353
u
Universal Resource Locator (URL), 52
Unspecified Bit Rate (UBR), 203
User Datagram Protocol (UDP), 181;
333; 343
User-to-Network Interface (UNI), 200
V
Variable Bit Rate (VBR), 202
Versatile Interface Processor (VIP), 67;
106
Virtual Channel Identifier (VCI), 201
Virtual Circuit (VC), 199; 309
Virtual Path (VP), 201
Virtual Private Network (VPN), 178; 241
MPLS, 258
Voice over IP (VoIP), 117; 193
VPN Routing and Forwarding (VRF), 259
w
Weighted Fair Queuing (WFQ), 89; 309
Weighted Random Early Detection
(WRED), 153; 309
Weighted Round Robin (WRR), 131
Wide Area Network (WAN), 349
Wide-Area Network (WAN), 24
Wildcard Filter (WF), 183
A
Активный поток трафика, 164
Алгоритм Нагля, 345
Архитектура
diffserv, 38
intserv, 37
В
Взвешенный алгоритм произвольного
раннего обнаружения (WRED), 153;
160
алгоритм WRED на основе потока,
164
предотвращение перегрузки, 161
Г
Гарантированное обслуживание, 21
Глобальная синхронизация, 156
Головной маршрутизатор, 285
д
Дрожание при передаче пакетов, 26
Ж
Жесткое QoS, 22
3
Задержка при передаче пакетов, 26
Знаменатель граничной вероятности,
159
Значение
SOO, 259
квантовое, 141
И
История возникновения и развития
QoS, 23
К
Канальный уровень
Предметный указатель
359
ATM, 199
Frame Relay, 216
оверлейная модель, 278
технологии QoS, 30
Квантовое значение, 141
Классификация пакетов, 28; 42
Команда
access-list, 164
atm abr rate-factor, 205
atm pvp, 207
bgp-policy source ip-prec-map, 340
class frag, 231
class-map, 110; 310
cos-queue group, 148
de-group, 231
de-list, 231
fair-queue, 102; 103; 189
fair-queue qos-group, 114
frame-relay fragment, 231
frame-relay priority-dlci-group, 228
ip cef, 249; 324
ip local policy route-map, 336
ip policy route-map, 336
ip route-cache flow accelerate, 333
ip rsvp bandwidth, 189
ip rsvp path, 189
ip rsvp reservation, 189
ip rsvp sender, 189
ip rtp priority, 123; 125; 232
ip spd headroom, 171
ip spd mode aggressive, 169
ip tcp header compression, 346
ip tcp path-mtu-discovery, 346
map, 325
match, 336
match access-group, 164
max-reserved-bandwidth, 124
mpls traffic-eng attribute-flag, 294
mpls traffic-eng tunnels, 290
no mpls ip propagate-ttl, 248; 304
policy-map, 311
policy-map wred, 164
ppp multilink, 351
ppp multilink fragment-delay 20, 351
ppp multilink interleave, 351
qos switching, 139
random-detect, 161
random-detect flow, 167
random-detect flow average-depth-
factor, 167
random-detect flow count, 167
req-qos guaranteed-delay, 193
route-map, 310
route-target import, 263
rx-cos-slot, 149
service nagle, 345
service-policy, 213; 312
service-policy output febandwidth, 111
set, 336
shape average, 79
shape peak, 79
show atm vc, 208
show atm vp, 207
show class, 110
show controllers frfab/tofab cos-
queue
length/parameters/variables, 150
show frame-relay pvc, 228
show frame-relay qos-autosense, 224
show interface Hssi0/0/0, 172
show interface rate, 69
show interface serialO, 117
show interface shape, 79
show interface switching, 172
show interface tunnel, 297
show ip cache verbose, 323
show ip cef, 249; 300
show ip policy, 335
show ip route, 263; 321
show ip rsvp installed, 191
show ip rsvp interface, 190
show ip rsvp neighbor, 192
show ip rsvp request, 192
show ip rsvp reservation, 191
show ip rsvp sender, 191
show ip spd, 171
show isis mpls traffic tunnel, 297
show isis mpls traffic-eng advertise,
298
show mpls forwarding-table, 249; 252
show mpls Idp bindings, 249; 251
show mpls Idp parameters, 251
show mpls traffic-eng tunnel, 293
show policy, 110
show policy-map, 213
show queue, 103; 193
360
Предметный указатель
show queue serialO, 103
show queueing custom, 121
show queueing fair, 104
show queueing priority, 117; 228
show queueing random-detect, 161;
167
show route-map tasman, 335
show traffic-shape, 77; 224
show traffic-shape statistics, 78
slot-table-cos, 149
traffic-shape adaptive, 220
traffic-shape fecn-adapt, 220
tunnel mode mpls traffic-eng, 290
tunnel mpls taffic-eng autoroute
announce, 299
tunnel mpls traffic-eng record-route,
293
tx-queue-limit, 101
vofr, 232
vofr cisco, 232
Коммутация
продвижение пакетов с помощью
кэша маршрутов, 318
Коммутация, 29
CEF-коммутация, 319
в сетях MPLS, 241
процессов, 317
Компонент
RSVP-компоненты, 180
передающий, 242
управляющий, 242
м
Маршрутизация, 30
Межсетевое взаимодействие
ATM и IP QoS, 208
Frame Relay и IP QoS, 223
Метки
восходящее назначение, 245
выталкивание, 252
инкапсуляция, 246
коммутация, 31
нисходящее назначение, 245
нисходящее назначение по
требованию, 245
привязка, 242
Метод негарантированной доставки, 21
Миниграммы, 345
Минимизация дрожания трафика, 147
О
Обслуживание очередей
алгоритм MWRR на основе класса
трафика, 139
алгоритм заказного обслуживания
очередей, 118
алгоритм обслуживания очередей
FIFO, 91
алгоритм приоритетного
обслуживания очередей, 115
алгоритм равномерного
обслуживания очередей (FQ), 89
взвешенный алгоритм
равномерного обслуживания
очередей (WFQ) на основе
вычисления порядкового номера
пакета, 94
взвешенный алгоритм равномерного
обслуживания очередей (WFQ) на
основе класса, 108
взвешенный алгоритм
равномерного обслуживания
очередей (WFQ) на основе
потока, 98
модифицированный алгоритм
кругового обслуживания с
дефицитом (MDRR), 140
модифицированный взвешенный
алгоритм кругового
обслуживания (MWRR), 131
распределенный алгоритм
равномерного обслуживания
очередей (DWFQ) на основе
QoS-группы, 114
распределенный алгоритм
равномерного обслуживания
очередей (DWFQ) на основе
класса услуг, 113
распределенный взвешенный
алгоритм равномерного
обслуживания очередей (DWFQ)
на основе потока, 106
Предметный указатель
361
Очередь
алгоритм превентивного
управления очередью RED, 156
входного интерфейса, 146
выходного интерфейса, 146
вычисление среднего размера, 158
диалога, 102
календарная, 107
обслуживание в соответствии с
алгоритмом WRR, 132
приоритетная очередь IP, 171
с малой задержкой, 141
“Отбрасывание хвоста”, 29
п
Пакеты
CEF-коммутация, 319
ТЕ-транк, 280
вероятность отбрасывания, 159
выравнивание трафика, 74
дифференцированное отбрасывание
IP-пакетов на границе АТМ-
сети, 211
задержка и дрожание при передаче,
26
инкапсуляция меток, 246
классификация, 52; 55
классификация и маркировка, 28
коммутация процессов, 317
маркировка, 53
обслуживание в соответствии с
алгоритмом WRR, 132
политика отбрасывания, 29
потеря, 27
приоритетное обслуживание на
основе адреса источника, 118
продвижение пакетов с помощью
кэша маршрутов, 318
раскраска, 53
стратегии отбрасывания ячеек, 204
фрагментация в сетях Frame Relay,
221
Параметр
conform-action, 67
exceed-action, 67
Перегрузка
алгоритм превентивного
управления очередью RED, 156
механизм предотвращения
перегрузки в сети Frame Relay,
217
предотвращение, 29
механизм WRED, 161
механизм избирательного
отбрасывания пакетов (SPD),
168
механизм явного уведомления о
перегрузке (ECN), 167
протокол TCP, 154
Пограничные формирователи трафика,
42
Политики
выбора пути, 284
действия, 67
диспетчер политик, 46
иерархические, 313
маршрутизация на основе
политики, 332
определение, 311
отбрасывания пакетов, 29
порядок выполнения, 314
предотвращения перегрузки, 147
применение, 312
применение политики QoS для
входящего и исходящего
трафика, 338
распределения ресурсов, 45
Полоса пропускания, 25
ТЕ-туннель, 282
выделение дополнительной полосы
пропускания, 109
выделение полосы пропускания в
зависимости от QoS-группы, 115
выделение полосы пропускания в
зависимости от класса ToS, 111
заказное обслуживание очереди,
118
распределение, 104
сквозная гарантированная полоса
пропускания, 271
Потеря пакетов, 27
Практический пример
MPLS CoS, 256
MPLS VPN, 259
362
Предметный указатель
адаптивный механизм
выравнивания трафика и
интеграция BECN/FECN, 225
алгоритм MWRR на основе класса
трафика, 139
взвешенный механизм
равномерного обслуживания
очередей (WFQ) на основе
потока, 103
выделение дополнительной полосы
пропускания в зависимости от
входного интерфейса, 111
выделение дополнительной полосы
пропускания для критического
трафика, 109
выделение минимальной полосы
пропускания интерфейса для
различных протоколов, 120
выделение полосы пропускания в
зависимости от QoS-группы без
использования модульного
интерфейса командной строки
QoS, 115
выделение полосы пропускания в
зависимости от класса ToS, 111
выделение полосы пропускания и
минимизация дрожания
голосового трафика в рамках
политики предотвращения
перегрузки, 147
выравнивание интенсивности
трафика, 76; 79; 82
выравнивание трафика Frame Relay
с использованием функции
автораспознавания QoS, 224
выравнивание трафика на
виртуальном пути, 206
дифференцированное
обслуживание, 214
дифференцированное отбрасывание
IP-пакетов на границе АТМ-
сети, 211
использование нескольких PVC-
каналов для передачи различных
типов трафика, 227
использование протокола RSVP с
целью резервирования ресурсов
для VoIP-трафика, 193
качество обслуживания в сетях
MPLS VPN, 271
классификация и маркировка
пакетов, 55; 58
конфигурация механизма WFQ на
каждом VC-канале, 230
конфигурация механизма WRED на
основе класса трафика с
помощью модульного
интерфейса командной строки
QoS, 163
нисходящее распространение
меток, 249
обслуживание трафика на
основании значения поля IP-
приоритета, 116
ограничение интенсивности
трафика, 68; 70
ограничение трафика в точке
обмена трафиком общего
пользования, 72
одновременное обслуживание
WFQ-планировщиком потоков
голосового трафика и FTP-
трафика, 105
отображение DE-бита Frame Relay
на биты IP-приоритета, 230
очередь со строгим приоритетом
обслуживания, предназначенная
для обработки голосового
трафика, 124
переопределение значения поля
IP-приоритета, 60
предоставление услуг по
размещению Web-серверов, 71
предоставление услуг с
ограниченной интенсивностью
трафика, 71
предотвращение атак типа Denial-
of-Service, 72
предотвращение атаки
злоумышленника,
использующего некорректные
IP-пакеты, с помощью
механизма SPD, 170
предотвращение перегрузки для
неадаптивных потоков трафика,
166
Предметный указатель
363
применение механизма WRED для
предотвращения перегрузки
канала передачи информации,
161
применение услуги ABR к каналу
PVC, 205
приоритетное обслуживание
пакетов на основе адреса
источника, 118
приоритетное обслуживание
пакетов на основе размера, 117
распределение полосы пропускания
в зависимости от веса потока,
104
распределенный взвешенный
алгоритм равномерного
обслуживания очередей (DWFQ)
на основе потока, 108
сквозное резервирование полосы
пропускания для приложения с
помощью протокола RSVP, 187
установка CLP-бита на основе IP-
приоритета, 216
установка и функционирование
ТЕ-туннеля в MPLS-сети, 289
фрагментация Frame Relay, 231
Приложения
идентификация, 52
протокол RSVP, 177
с групповой рассылкой, 178
уровни качества обслуживания, 20
Продвижение пакетов
сеть MPLS, 242; 244
Протокол управления передачей
(TCP), 153
ТСР-трафик, 155
механизм медленного старта и
предотвращение перегрузки, 154
механизм явного уведомления о
перегрузке (ECN), 167
Протоколы
сигнальный протокол QoS, 29
File Transfer Protocol (FTP), 21; 185
Internet Control Message Protocol
(ICMP), 72
Internet Protocol (IP), 23
Multiprotocol Label Switching
(MPLS), 31
Real-time Transport Protocol (RTP),
123
Resource Reservation Protocol
(RSVP), 38
Subnet Bandwidth Manager (SBM),
235
Transmission Control Protocol (TCP),
181
Transmission Control
Protocol/Intemet Protocol
(TCP/IP), 23
User Datagram Protocol (UDP), 181
P
Раскраска пакетов, 53
Расширения
RSVP, 237
протоколов маршрутизации
внутреннего шлюза, 288
Реализация
алгоритма MDRR, 146
алгоритма MWRR, 138
алгоритма WFQ, 101
Режим строгого приоритета, 141
Режим чередующегося приоритета, 141
С
Самосинхронизация, 154
Сети
ATM
канальный уровень, 199
межсетевой обмен ATM и IP
QoS, 208
Frame Relay
канальный уровень, 216
межсетевой обмен Frame Relay и
IP QoS, 223
Wide-Area Network (WAN), 24
инициализация, 45
маршрутизация на основе
политики, 332
оверлейная модель канального
уровня, 278
пограничные интерфейсы, 311
пограничные формирователи
трафика, 42
364
Предметный указатель
предоставление сквозных услуг IP
QoS, 255
семейство локальных сетей IEEE
802.3, 232
управление интенсивностью
трафика, 61
уровни качества обслуживания, 20
характеристики
производительности, 25
Сигнализация о качестве
обслуживания, 45
Сквозное качество обслуживания, 31
Схема
коммутации, 317
корзина маркеров, 61
максиминная схема равномерного
распределения ресурсов, 91
Счетчик байтов, 119
Счетчик циклов, 95
т
Трафик
ATM QoS, 201
Frame Relay, 217
IEEE 802.3, 233
РНВ-политика, 43
QPPB, 54
выравнивание, 74
дозирование, 64
маршрутизация на основе
резервирования ресурсов, 279
механизм CAR, 56
механизм избирательного
отбрасывания пакетов (SPD),
168
мультимедиа, 178
обработка голосового трафика, 123
обслуживание голосового трафика,
147
оверлейная модель канального
уровня, 278
ограничение, 62
однонаправленный, 178
определение класса трафика, 310
пограничные формирователи
трафика, 42
политика действия, 67
реакция TCP-трафика на
применение политики
“отбрасывания хвоста”, 155
точка обмена трафиком общего
пользования, 72
управление интенсивностью, 61
управление трафиком, 243
уровни качества обслуживания, 20
условие совпадения, 63
У
Управление
интенсивностью трафика, 61
очередью, 156
с помощью политик, 331
Управление трафиком, 277
ТЕ-путь, 286
ТЕ-транк, 280
ТЕ-туннель, 281
Услуги
гарантированная битовая скорость,
185
гарантированные, 21
дифференцированные, 21
РНВ-политика, 43
архитектура, 38
распределение ресурсов, 45
передача данных методом негаран-
тированной доставки, 19
доступная скорость передачи (ABR),
203
интегрированные, 37
неопределенная битовая скорость
(UBR), 203
обслуживание с постоянной
битовой скоростью (CBR), 203
переменная скорость передачи в
режиме реального времени (RT-
VBR), 203
переменная скорость передачи не в
режиме реального времени
(nRT-VBR), 203
регулируемая нагрузка, 185
Устранение неполадок
планирование обслуживания
очередей, 89
поддержка ТЕ-пути, 286
Предметный указатель
365
протокол RSVP, 186
управление интенсивностью
трафика, 61
характеристики
производительности сетевого
соединения, 25
Ф
Фрагментация
Frame Relay, 221; 231
Функции
выравнивание трафика, 43; 61
дозирование трафика, 42
классификация и маркировка
пакетов, 28
классификация пакетов, 42
коммутация, 29
маркировка пакетов, 42
маршрутизация, 30
ограничение трафика, 61; 62
отбрасывание пакетов, 43
предотвращение перегрузки, 29
распознавание класса трафика, 52
распределение ресурсов, 28
сигнальный протокол QoS, 29
управление интенсивностью
трафика, 28
366
Предметный указатель
Научно-популярное издание
Шринивас Вегешна
Качество обслуживания в сетях IP
Литературный редактор
Верстка
Художественный редактор
Корректоры
С. Г. Езерницкая
О. В. Линник
В. Г. Павлютин
З.В. Александрова, Л.А. Гордиенкс
и О. В. Мишу тина
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.
Подписано в печать 23.12.2002. Формат 70x100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 29,7. Уч.-изд. л. 21,0.
Тираж 2500 экз. Заказ № 2020.
Отпечатано с диапозитивов в ФГУП “Печатный двор”
Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
Качество обслу
в сетях №