Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
$ Качество Обслуживания в сетях IP
IP Quality of Service
Srinivas Vegesna
Cisco Systems a
Cisco Press ;
Cisco Press i 201 West 103rd 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 retrieval 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 (рус.)© Издательский дом “Вильямс”, 2003
ISBN 1-5787-0116-3 (англ.)© Cisco Press, 2001
Оглавление
Об авторе13
Благодарности14
Посвящения14
О технических рецензентах15
Часть I. Качество обслуживания в сетях IP17
Глава 1. Введение в качество обслуживания в сетях IP19
Глава 2. Архитектура дифференцированных услуг37
Глава 3. Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика51
Глава 4. РНВ-политика: распределение ресурсов (часть 1)89
Глава 5. РНВ-политика: распределение ресурсов (часть 2)131
Глава 6. РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов153
Глава 7. Интегрированные услуги: RSVP177
Часть II. Качество обслуживания канального уровня и сети MPLS — межсетевой обмен с IP QoS197
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен с IP QoS199
Глава 9. Качество обслуживания в сетях MPLS241
Часть III. Управление трафиком275
Глава 10. Управление трафиком в сетях MPLS277
Часть IV. Приложения307
Приложение А. Модульный интерфейс командной строки Cisco QoS309
Приложение Б. Механизмы коммутации пакетов317
Приложение В. Политики маршрутизации331
Приложение Г. Транспортный протокол реального времени (RTP)343
Приложение Д. Общие функции линейной эфективности протокола IP345
Приложение Е. Фрагментация и чередование пакетов на канальном уровне349
Приложение Ж. Значения поля IP-приоритета и поля DSCP353
Предметный указатель356
Содержание
Об авторе13
Благодарности14
Посвящения14
О технических рецензентах15
Часть I. Качество обслуживания в сетяхIP17
Глава 1. Введение в качество обслуживанияв сетях IP19
Уровни качества обслуживания20
Краткий экскурс в историю возникновения и развития качества обслуживания в сетях IP23
Характеристики производительности сетевого соединения25
Полоса пропускания25
Задержка и дрожание при передаче пакетов26
Потеря пакетов27
Функции качества обслуживания28
Классификация и маркировка пакетов28
Управление интенсивностью трафика28
Распределение ресурсов28
Предотвращение перегрузки и политика отбрасывания пакетов29
Сигнальный протокол QoS29
Коммутация29
Маршрутизация29
Технологии качества обслуживания канального уровня30
Многопротокольная коммутация меток30
Сквозное качество обслуживания31
Цели32
Аудитория32
Широта охвата и ограничения изложенного в книге материала33
Организация книги33
Часть I34
Часть II34
Часть III34
Часть IV34
Глава 2. Архитектура дифференцированных услуг37
Архитектура интегрированных услуг (intserv)37
Архитектура дифференцированных услуг (diffserv)38
Формирователи трафика, расположенные на границе сети42
РНВ-политика43
Политика распределения ресурсов45
Резюме48
Глава 3. Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика51
Классификация пакетов52
Маркировка пакетов53
IP-приоритет53
DSCP54
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-Service72
Практический пример 3.9: ограничение трафика в точке обмена трафиком общего пользования72
Выравнивание трафика74
Дозирование трафика75
Практический пример 3.10: выравнивание интенсивности трафика до скорости доступа76
Практический пример 3.11: выравнивание интенсивности входящего и исходящего трафика узла79
Практический пример 3.12: выравнивание трафика Frame Relay в ответ
на получение обратного явного уведомления о перегрузке (BECN)82
Резюме84
Глава 4. РНВ-политика: распределение ресурсов (часть 1)89
Поддержка функций QoS со стороны механизмов обслуживания очередей90
Алгоритм обслуживания очередей FIFO91
Максиминная схема равномерного распределения ресурсов91
Обобщенная схема разделения процессорного времени94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе вычисления порядкового номерапакета94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе потока98
Взаимодействие механизма WFQспротоколом RSVP101
Реализация алгоритма WFQ101
Практический пример 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: выделение полосы пропускания в зависимости от класса ToS111
Конфигурация механизма CBWFQ без использования модульного интерфейса командной строки QoSИЗ
Практический пример 4.8: выделение полосы пропускания в зависимости от QoS-группы без использования модульного интерфейса командной строки QoS115
Приоритетное обслуживание очередей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
Пример работы алгоритма MWRR132
Реализация алгоритма MWRR138
Практический пример 5.1: алгоритм MWRR на основекласса трафика139
Модифицированный алгоритм кругового обслуживания с дефицитом (MDRR)140
Пример работы алгоритма MDRR'142
Реализация алгоритма MDRR146
Практический пример 5.2: выделение полосы пропускания и минимизация дрожания голосового трафика в рамках политики предотвращения перегрузки147
Резюме150
Глава 6. РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов153
Механизм медленного старта и предотвращение перегрузки154
Реакция TCP-трафика на применение политики “отбрасывания хвоста"155
RED — алгоритм превентивного управления очередью с целью предотвращения перегрузки сети156
Алгоритм вычисления среднего размера очереди158
Алгоритм вычисления вероятности отбрасывания пакетов159
Взвешенный алгоритм произвольного раннего обнаружения (WRED)160
Реализация алгоритма WRED160
Практический пример 6.1: применение механизма WRED для предотвращения перегрузки канала передачи информации161
Практический пример 6.2: конфигурация механизма WRED на основе класса трафика с помощью модульного интерфейса командной строки QoS163
Алгоритм WRED на основе потока164
Практический пример 6.3: предотвращение перегрузки для неадаптивных потоков трафика166
Механизм явного уведомления о перегрузке (ECN)167
Механизм избирательного отбрасывания пакетов(SPD)168
Практический пример 6.4: предотвращение атаки злоумышленника, использующего некорректные IP-пакеты, с помощью механизма SPD170
Резюме172
Глава 7. Интегрированные услуги: RSVP177
Протокол RSVP177
Работа протокола RSVP178
RSVP-компоненты180
RSVP-сообщения181
Стили резервирования182
Индивидуальное резервирование182
Общее резервирование183
Типы услуг185
Регулируемая нагрузка185
Гарантированная битовая скорость185
Среда передачи и протокол RSVP186
Масштабируемость протокола RSVP186
Практический пример 7.1: сквозное резервирование полосы пропускания для приложения с помощью протокола RSVP187
Практический пример 7.2: использование протокола RSVP с целью резервирования ресурсов для VoIP-трафика193
Резюме194
Часть II. Качество обслуживания канального уровня и сети MPLS — межсетевой обмен с IP QoS197
Глава 8. Качество обслуживания на уровне 2: межсетевой обмен с IP QoS 199
ATM199
Формат ATM-ячейки200
ATM QoS201
Классы услуг ATM202
Стратегии отбрасывания ячеек204
Выравнивание трафика на виртуальном пути205
Практический пример 8.1: применение услуги ABR к каналу PVC205
Практический пример 8.2: выравнивание трафика на виртуальном пути206
Межсетевой обмен ATM и IP QoS208
Практический пример 8.3: дифференцированное отбрасывание
IP-пакетов на границе АТМ-сети211
Практический пример 8.4: дифференцированное обслуживание214
Практический пример 8.5: установка CLP-бита на основе IP-приоритета 216
Frame Relay216
Механизм предотвращения перегрузки в сети FrameRelay217
Механизм выравнивания трафика в сети Frame Relay (FRTS)218
Фрагментация в сетях Frame Relay221
Межсетевой обмен Frame Relay и IP QoS223
Практический пример 8.6: выравнивание трафика Frame Relay с использованием функции автораспознавания QoS224
Практический пример 8.7: адаптивный механизм выравнивания
трафика и интеграция BECN/FECN225
Практический пример 8.8: использование нескольких PVC-каналов для передачи различных типов трафика227
Практический пример 8.9: конфигурация механизма WFQ на каждом
VC-канале230
Практический пример 8.10: отображение DE-бита Frame Relay на биты
IP-приоритета230
Практический пример 8.11: фрагментация FrameRelay231
Семейство локальных сетей IEEE 802.3232
Возможность передачи высокоприоритетного трафика233
Резюме237
Глава 9. Качество обслуживания в сетях MPLS241
MPLS241
Передающий компонент242
Управляющий компонент242
Инкапсуляция меток246
MPLS и ATM248
Практический пример 9.1: нисходящее распространение меток249
Качество обслуживания в сетях MPLS254
Предоставление сквозных услуг IP QoS255
Практический пример 9.2: MPLS CoS256
LER-маршрутизатор256
LSR-маршрутизатор257
Виртуальные частные сети (VPN) на основе MPLS258
Практический пример 9.3: MPLS VPN259
Качество обслуживания в сетях MPLS VPN268
Дифференцированные услуги MPLS VPN QoS268
Гарантированные услуги QoS270
Практический пример 9.4: качество обслуживания в сетях MPLS VPN271
Резюме271
Часть III. Управление трафиком275
Глава 10. Управление трафиком в сетях MPLS277
Оверлейная модель канального уровня278
Маршрутизация на основе резервирования ресурсов (RRR)279
Определение ТЕ-транка280
Атрибуты ТЕ-туннеля281
Полоса пропускания282
Приоритет установки и удержания282
Родственность класса ресурса282
Порядок выбора пути283
Адаптируемость283
Устойчивость283
Атрибуты ресурсов канала283
Доступная полоса пропускания283
Класс ресурса284
Распространение информации о ресурсах канала284
Политика выбора пути284
Установка ТЕ-туннеля285
Управление доступом к каналу286
Поддержка ТЕ-пути286
Сигнальный протокол TE-RSVP287
Расширения протокола маршрутизации внутреннего шлюза288
Модификации протокола IS-IS288
Модификации протокола OSPF288
Подходы к реализации механизма управления трафиком289
Практический пример 10.1: установка и функционирование ТЕ-туннеля в
MPLS-сети289
Резюме304
Часть IV. Приложения307
Приложение А. Модульный интерфейс командной строки Cisco QoS309
Определение класса трафика310
Определение политики311
Применение политик312
Иерархические политики313
Порядок выполнения политик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-политик с помощью протокола BGP336
Практический пример В.З: применение политики QoS для входящего
и исходящего трафика338
Резюме341
Приложение Г. Транспортный протокол реального времени (RTP)343
Приложение Д. Общие функции линейной эфективности протокола IP345
Алгоритм Нагля345
Функция определения максимально возможной единицы передачи данных
(MTU) пути346
Сжатие заголовка TCP/IP346
Сжатие RTP-заголовка346
Приложение Е. Фрагментация и чередование пакетов на канальном уровне349
Приложение Ж. Значения поля IP-приоритета и поля DSCP353
Предметный указатель356
Об авторе
Шринивас Вегешна (Srinivas Vegesna), CCIE #1399, занимает пост менеджера службы по предоставлению расширенной консультации поставщикам услуг Internet в компании Cisco Systems. Основным направлением его деятельности является разработка общих принципов построения IP-сетей с акцентом на протоколах маршрутизации и качестве обслуживания в сетях IP. За 6 лет работы в компании Cisco Systems Шринивас имел опыт сотрудничества с большим числом поставщиков услуг Internet и корпоративных заказчиков, проектируя, внедряя крупномасштабные IP-сети и устраняя неполадки в них. Шринивас получил степень магистра по электротехнике в университете штата Аризона. В настоящее время он проходит обучение с целью получить степень магистра делового администрирования в университете Санта-Клары.
Благодарности
Прежде всего я хотел бы поблагодарить своих друзей и коллег в компании Cisco Systems за создание стимулирующей рабочей обстановки на протяжении последних 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 Mar), 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, Johnson & Johnson, Bristol Meyers Squibb, Nabisco, Chubb Insurance и American Reinsurance. Шери закончила с отличием Вестминстерский колледж в Нью-Вилмингтоне, штат Пенсильвания, получив степень бакалавра в области вычислительной техники и математики (Computer Science and Math). Помимо этого, Шери закончила с отличием университет округа Монмут (Monmouth University) (ранее — колледж округа Монмут (Monmouth College)), штат Нью-Джерси, получив степень магистра по финансам. Шери является сертифицированным специалистом по межсетевому обмену Cisco (CCIE), владея также сертификатом Cisco CIP и сертификатом Novell. В настоящее время Шери живет в Милстоуне, штат Нью-Джерси.
Часть
Качество обслуживания в сетях IP
'й^В этой части.
к
Ж
Глава 1. Введение в качество обслуживания в сетях IP
Глава 2. Архитектура дифференцированных услуг
Глава 3. Формирование трафика на границе сети: , /;.й. классификация пакетов, маркировка пакетов
": Л'":""' и управление интенсивностью трафика
Глава 4. РНВ-политика: распределение ресурсов (часть 1) Глава 5. РНВ-политика: распределение ресурсов (часть 2) Глава 6. РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов
Глава 7. Интегрированные услуги: RSVP
19
37
51
89
131
153
177
•Ж
В этой главе...
Уровни качества, обслуживания<
Краткий экскурс в историю возникновения И развития качества
20
обслуживания в сетях IP*
Характеристики производительности сетевого соединения Функции качества обслуживания*
Технологии качества обслуживания канального уровня ч Многопротокольная коммутация меток
ж
23 25
. 28 зо 30
^Сквозное качество обслуживания
:#Цели А»■&.
< Аудитория SW
.* широта охвата и ограничения из) ? . Организация книги
32
33
зз
:енного в книге материал
Глава
Введение в качество обслуживания в сетях IP
Ц-^ Вплоть до настоящего времени поставщикам услуг Internet и крупным компаниям при- s ходилось создавать и поддерживать ^отдельные сети для передачи голосовой информации, ? видеоизображения, трафика, необходимого для решения критически важных задач, и всего остального сетевого трафика. Тем не менее нельзя не отметить сложившуюся в последнее в'время ярко выраженную тенденцию к объединению всех этих сетей в одну сеть с пакетной к передачей данных на основе протокола Internet Protocol (IP).
v Наиболее крупная IP-сеть — этб^ естественно, глобальная сеть Internet. За последние } ’несколько лет рост Internet, передаваемого по Сети трафика и количества существующих
Internet-приложений приблизился к экспоненциальному. В то время как Internet и корпоративные интрасети продолжают свой рост, многие аналитики предсказывают появление приложений, ориентированных на передачу нетрадиционных типов информа- А ции, — например, передачу голосапо сетям IP (Voice over IP — VoIP) или передачу трафика видеоконференций. Поскольку ^количество пользователей Internet и различных сетевых приложений увеличиваетс^с’каждым днем, Сеть нуждается в средствах, кото- 55 рые бы обеспечили поддержку как существующих, так и появляющихся приложений и А" служб. Тем не менее на сегодняшний; день 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).
Уровни качества обслуживания
Сетевой трафик состоит из множества потоков, сгенерированных приложениями конечных станций. Эти приложения отличаются друг от друга различными требованиями к обслуживанию и к рабочим характеристикам сети. По сути, требование к об-
служиванию каждого потока целиком и полностью определяется требованиями сгенерировавшего этот поток приложения. Следовательно, для того чтобы выяснить структуру существующих в сети запросов на качество обслуживания, необходимо определить типы сетевых приложений.
Способность сети обеспечивать различные уровни обслуживания, запрашиваемые теми или иными сетевыми приложениями, наряду с проведением контроля за характеристиками производительности — полосой пропускания, задержкой/дрожанием и потерей пакетов — может быть классифицирована по трем перечисленным ниже категориям.
Негарантированная доставка данных (best-effort service). Обеспечение связности узлов сети без гарантии времени и самого факта доставки пакета в точку назначения. Следует отметить, что отбрасывание пакета может произойти только в случае переполнения буфера входной или выходной очереди маршрутизатора.
На самом деле негарантированная доставка пакетов не является частью QoS вследствие отсутствия гарантии качества обслуживания и гарантии обеспечения доставки пакетов. Следует отметить, что негарантированная доставка пакетов является на сегодняшний день единственной услугой, поддерживаемой в Internet.
Несмотря на некоторое снижение производительности, для большинства приложений, ориентированных на передачу информации (например, приложений, обеспечиваюших взаимодействие по протоколу передачи файлов (File Transfer Protocol — FTP)), эта услуга является вполне достаточной. В целом же оптимальные условия функционирования всех приложений включают в себя требования к выделению определенных сетевых ресурсов в терминах полосы пропускания, задержки и уровня потери пакетов.
Дифференцированное обслуживание (differentiated service). Дифференцирование обслуживание предполагает разделение трафика на классы на основе требований к качеству обслуживания. Каждый класс трафика дифференцируется и обрабатывается сетью в соответствии с заданными для этого класса механизмами QoS. Подобная схема обеспечения качества обслуживания (QoS) довольно часто называется схемой CoS.
Следует отметить, что дифференцированное обслуживание само по себе не предполагает обеспечения гарантий предоставляемых услуг. В соответствии с данной схемой трафик распределяется по классам, каждый из которых имеет свой собственный приоритет. По этой причине дифференцированное обслуживание довольно часто называют мягким QoS (soft QoS).
Дифференцированное обслуживание удобно применять в сетях с интенсивным трафиком приложений. В этом случае важно обеспечить отделение административного трафика сети от всего остального трафика и назначить ему приоритет, позволяюший в любой момент времени быть уверенным в связности узлов сети.
Гарантированное обслуживание (guaranteed service). Гарантированное обслуживание предполагает резервирование сетевых ресурсов с целью удовлетворения специфических требований к обслуживанию со стороны потоков трафика.
В соответствии с гарантированным обслуживанием выполняется предварительное резервирование сетевых ресурсов по всей траектории движения трафика.
Гарантированное обслуживание довольно часто называют еше жестким 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
Окончание табл. 1.1
Уровень обслуживания
Разрешающая функция QoS сетевого уровня
Разрешающая функция QoS канального уровня
Дифференцированное обслуживание
Механизм согласования скорости доступа (Committed Access Rate — CAR) CoS, взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing — WFQ), взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detection - WRED)
IEEE802.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) используется для указания абстрактных параметров требуемого качества обслуживания. На основании этих параметров производится выбор реальных характеристик механизмов обслуживания при передаче датаграммы через заданную сеть.”
Вплоть до конца 80-х годов Internet пребывала в “зародышевом” состоянии, что характеризовалось низким объемом трафика и малым числом используемых сетевых приложений. Следовательно, поддержкой байта ToS можно было пренебречь, что и сделано практически во всех реализациях протокола IP. IP-приложения не производили установку значения байта ToS, а маршрутизаторы игнорировали его при принятии решения о продвижении IP-пакета.
Важность внедрения механизма QoS в масштабах Internet возросла благодаря увеличению популярности Сети и приобретению ею коммерческих черт. Функционирование Internet базируется на сквозном режиме обслуживания пакетов данных без ориентации на установку соединения, который подразумевает негарантированную доставку информации с использованием для этого связки из двух протоколов — протокола управления передачей (Transmission Control Protocol — TCP) и протокола Internet (Internet Protocol — IP), более известную как TCP/IP. Несмотря на то что отсутствие
ориентации на установку соединения делает Internet более гибкой и устойчивой к сбоям, динамика передаваемых потоков данных делает ее склонной к перегрузкам, которые чаще всего возникают в местах стыка двух сетей со значительно различающимися пропускными способностями. Проблема снижения работоспособности TCP/IP сетей в моменты перегрузки была рассмотрена Джоном Наглем (John Nagle) в середине 80-х годов прошлого столетия.
Первоначально функции качества обслуживания были возложены на узлы Internet. Одна из наиболее серьезных проблем, касающаяся дорогостоящих каналов передачи информации глобальных сетей (Wide-Area Network — WAN), заключалась в их чрезмерной перегрузке пакетами протокола TCP, имеющими небольшой объем и сгенерированными такими приложениями, как telnet и rlogin. Алгоритм Нагля, призванный решить эту проблему, реализован сегодня во всем программном обеспечении, установленном в узлах Internet и поддерживающем протокол IP. Можно сказать, что алгоритм Нагля “возвестил” о начале эпохи качества обслуживания в сетях IP.
В 1986 году Ван Якобсон (Van Jacobson) разработал следующий набор функций Internet QoS для конечных систем — механизмы предотвращения перегрузки, являющиеся стандартом де-факто для всех современных реализаций TCP. Следует отметить, что эти механизмы (механизм медленного старта и механизм предотвращения перегрузки) играют огромную роль в предупреждении критического снижения работоспособности сети в сегодняшней Internet. Ответственными за реагирование на сигналы о перегрузке сети (которыми служат отброшенные пакеты) являются потоки трафика TCP. В 1990 году для обеспечения оптимальной производительности сети в моменты потери пакетов были разработаны два дополнительных механизма — механизм быстрой повторной передачи и механизм быстрого восстановления.
Несмотря на то что реализация механизмов QoS в конечных системах является необходимым условием, она не позволяет говорить о сквозном качестве обслуживания до тех пор, пока соответствующие механизмы не будут реализованы в маршрутизаторах — устройствах, ответственных за передачу трафика между конечными системами. Следовательно, с 1990-х годов акцент в разработке механизмов QoS вполне логично переместился на исследование возможности реализации функций качества обслуживания в маршрутизаторах. Маршрутизаторы, поддерживающие только один механизм обслуживания очередей — “первым пришел, первым обслужен" (first-in, first-out — FIFO), — не способны обеспечить дифференцирование потоков трафика на основе их приоритета на уровне алгоритма планирования очередей. Более того, обслуживание очередей по методу FIFO приводит к отбрасыванию пакетов и не способно защитить потоки с предсказуемым поведением от “шалунов”. Решить данную проблему на уровне магистрали Internet были призваны алгоритм обслуживания очередей WFQ (Weighted Fair Queuing — взвешенный алгоритм равномерного обслуживания очередей) и алгоритм управления очередями WRED (Weighted Random Early Detection — взвешенный алгоритм произвольного раннего обнаружения).
Разработка механизмов QoS продолжилась попытками стандартизации функций сквозного качества обслуживания в масштабах Internet. Целью рабочей группы IETF по созданию интегрированных услуг (Integrated Services (intserv) Internet Engineering Task Force (IETF) Working Group) является обеспечение приложений средствами формулирования требований к ресурсам при сквозном обслуживании, а также разработка соответствующих механизмов на уровне маршрутизаторов и технологий подсетей. Использующимся в этих целях сигнальным протоколом является протокол RSVP (Resource Reservation Protocol — протокол резервирования ресурсов). В соответствии с моделью intserv обслуживание каждого потока трафика производится на всей траектории соединения, что серьезно затрудняет использование этой модели в масштабах магистрали Internet, обрабатывающей в каждый момент времени тысячи потоков информации. Более подробно протокол RSVP и типы обслуживания intserv рассматриваются в главе 7, “Интегрированные услуги: RSVP”, далее в этой книге.
Несмотря на то что байт заголовка IP-пакета ToS до недавнего времени практически не использовался, сейчас это один из самых распространенных методов определения требований к качеству обслуживания. Байт ToS представляет собой главный механизм обеспечения услуг diffserv в масштабах Internet, что подвигло рабочую группу IETF по созданию дифференцированных услуг (IETF differentiated services (diffserv) Working Group) предложить стандартизировать этот байт в качества байта diffserv. Более подробно архитектура diffserv рассматривается в главе 2, “Архитектура дифференцированных услуг", далее в этой книге.
Характеристики производительности сетевого соединения
Внедрение механизмов QoS предполагает обеспечение со стороны сети соединения с определенными ограничениями по производительности. Основными характеристиками производительности сетевого соединения являются полоса пропускания, задержка, дрожание и уровень потери пакетов. Более подробно все упомянутые характеристики производительности рассматриваются в следующих разделах этой главы.
Полоса пропускания
Термин полоса пропускания (bandwidth) используется для описания номинальной пропускной способности среды передачи информации, протокола или соединения. Этот термин достаточно эффективно определяет “ширину канала”, требующуюся приложению для взаимодействия по сети.
Как правило, каждое соединение, нуждающееся в гарантированном качестве обслуживания, требует от сети резервирования минимальной полосы пропускания. К примеру, приложения, ориентированные на передачу оцифрованной речи, создают поток информации интенсивностью 64 Кбит/с. Эффективное использование таких приложений становится практически невозможным вследствие снижения полосы пропускания ниже 64 Кбит/с на каком-либо из участков соединения.
Задержка и дрожание при передаче пакетов
Задержка при передаче пакета (packet delay), или латентность (latency), на каждом переходе состоит из задержки сериализации, задержки распространения и задержки коммутации. Ниже приведены определения каждого из названных выше типов задержки.
Задержка сериализации (serialization delay). Время, которое требуется устройству на передачу пакета при заданной ширине полосы пропускания. Задержка сериализации зависит как от ширины полосы пропускания канала передачи информации, так и от размера передаваемого пакета. Например, передача пакета размером 64 байт при заданной полосе пропускания 3 Мбит/с занимает всего лишь 171 нс. Обратите внимание, что задержка сериализации очень сильно зависит от полосы пропускания: передача того же самого пакета размером 64 байт при заданной полосе пропускания 19.2 Кбит/с занимает уже 26 мс. Довольно часто задержку сериализации называют еще задержкой передачи (transmission delay).
Задержка распространения (propagation delay). Время, которое требуется переданному биту информации для достижения принимающего устройства на другом конце канала. Эта величина довольно существенна, поскольку в наилучшем случае скорость передачи информации соизмерима со скоростью света. Обратите внимание, что задержка распространения зависит от расстояния и используемой среды передачи информации, а не от полосы пропускания. Для линий связи глобальных сетей задержка распространения измеряется в миллисекундах. Для трансконтинентальных сетей Соединенных Штатов характерна задержка распространения порядка 30 мс.
Задержка коммутации (switching delay). Время, которое требуется устройству, получившему пакет, для начала его передачи следующему устройству. Как правило, это значение меньше 10 нс.
Обычно каждый из пакетов, принадлежащий одному и тому же потоку трафика, передается с различным значением задержки. Задержка при передаче пакетов меняется в зависимости от состояния промежуточных сетей.
В том случае, если сеть не испытывает перегрузки, пакеты не ставятся в очередь в маршрутизаторах, а общее время задержки при передаче пакета состоит из суммы задержки сериализации и задержки распространения на каждом промежуточном переходе. В этом случае можно говорить о минимально возможной задержке при передаче пакетов через заданную сеть. Следует отметить, что задержка сериализации становится незначительной по сравнению с задержкой распространения при передаче пакета по каналу с большой пропускной способностью.
Если же сеть перегружена, задержки при организации очередей в маршрутизаторах начинают влиять на общую задержку при передаче пакетов и приводят к возникновению разницы в задержке при передаче различных пакетов одного и того же потока. Колебание задержки при передаче пакетов получило название дрожания при передаче пакетов (packet jitter).
Дрожание пакетов имеет большую важность, поскольку именно оно определяет максимальную задержку при приеме пакетов в конечном пункте назначения. Принимающая сторона, в зависимости от типа используемого приложения, может попытаться компенсировать дрожание пакетов за счет организации приемного буфера для хранения принятых пакетов на время, меньшее или равное верхней границе дрожания. К этой категории относятся приложения, ориентированные на передачу/прием непре-
рывных потоков данных, например Internet-телефония или приложения, обеспечивающие проведение видеоконференций.
На рис. 1.1 проиллюстрировано влияние задержки сериализации, задержки распространения и задержки коммутации на общую задержку при передаче пакетов в зависимости от возрастания полосы пропускания канала.
■ Задержка сериелизеции■ Задержка коммутации□ Задержка распространения■ Задержка сериелизеции■ Задержка коммутации□ Задержка распространенияРис. 1.1. Структура общей задержки при передаче пакета размером 1500 байт по трансконтинентальному каналу Соединенных Штатов в зависимости от возрастания полосы пропусканияРис. 1.1. Структура общей задержки при передаче пакета размером 1500 байт по трансконтинентальному каналу Соединенных Штатов в зависимости от возрастания полосы пропускания
■ Задержка сериелизеции
■ Задержка коммутации
□ Задержка распространения
■ Задержка сериелизеции
■ Задержка коммутации
□ Задержка распространения
Рис. 1.1. Структура общей задержки при передаче пакета размером 1500 байт по трансконтинентальному каналу Соединенных Штатов в зависимости от возрастания полосы пропускания
Рис. 1.1. Структура общей задержки при передаче пакета размером 1500 байт по трансконтинентальному каналу Соединенных Штатов в зависимости от возрастания полосы пропускания
Обратите внимание, что задержка сериализации становится незначительной по сравнению с задержкой распространения по мере увеличения полосы пропускания канала. Задержка коммутации пренебрежимо мала в случае отсутствия пакетов в очередях маршрутизаторов, однако склонна к существенному увеличению при росте размеров очередей.
Потеря пакетов
Уровень потери пакетов (packet loss) определяет количество пакетов, отбрасываемых сетью во время передачи. Основными причинами потери пакетов являются перегрузка сети и повреждение пакетов во время передачи по линии связи. Чаще всего отбрасывание пакетов происходит в местах перегрузки, где число поступающих пакетов намного превышает верхнюю границу размера выходной очереди. Кроме того, отбрасывание пакетов может быть вызвано недостаточным размером входного буфера. Как правило, уровень потери пакетов выражается как доля отброшенных пакетов за определенный интервал времени.
Некоторые приложения не способны нормально функционировать или же функционируют крайне неэффективно в случае потери пакетов. Подобные приложения требуют от сети гарантии надежной доставки всех пакетов.
Как правило, хорошо спроектированные сети характеризуются очень низким значением потери пакетов. Потеря пакетов также несвойственна приложениям, для которых были заранее зарезервированы требуемые этими приложениями ресурсы. Что касается волоконно-оптических линий связи со значением частоты появления ошибочных битов (Bit Error Rate — BER) 10E-9, то здесь потеря пакетов возможна только в случае их отбрасывания в местах перегрузки сети. Отбрасывание пакетов, к сожалению, является неизбежным явлением при негарантированной доставке трафика, хотя и в этом случае оно обуславливается крайней необходимостью. Следует отметить, что отброшенные па-
кеты указывают на неэффективное использование ресурсов сети, часть которых была потрачена на доставку пакетов в точку, где они были потеряны.
Функции качества обслуживания
В данном разделе приводится краткое описание различных функций качества обслуживания, связанных с ними возможностей и преимуществ. Более подробно каждая из упомянутых здесь функций QoS рассматривается в оставшейся части этой книги.
Классификация и маркировка пакетов
Маршрутизаторы, расположенные на границе сети, используют функцию классификации для распознавания пакетов, принадлежащих различным классам трафика, в зависимости от значения одного или нескольких полей в заголовке TCP/IP. Функция маркировки пакетов используется для разметки классифицированного трафика путем установки значения поля IP-приоритета или поля кода дифференцированного обслуживания (Differentiated Services Code Point — DSCP).
Более подробно функции классификации и маркировки пакетов рассматриваются в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика”, далее в этой книге.
Управление интенсивностью трафика
Поставщики услуг используют ограничивающую функцию для приведения параметров поступающего в сеть клиентского трафика в соответствие с его профилем. В то же время, корпорации используют выравнивающую функцию для дозирования поступающего в сеть поставщика услуг трафика и выравнивания его интенсивности в соответствии с заданным профилем. Наиболее распространенной схемой дозирования трафика является так называемая схема корзины маркеров (token bucket).
Более подробно эта функция качества обслуживания рассматривается в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика”, далее в этой книге.
Распределение ресурсов
Наиболее распространенным механизмом обслуживания очередей в маршрутизаторах и коммутаторах современной Internet является ставший уже традиционным механизм “первым пришел, первым обслужен" (first-in, first-out — FIFO). Несмотря на простоту реализации, для механизма FIFO характерно несколько фундаментальных проблем, затрудняющих выполнение функций качества обслуживания. Так, механизм FIFO не предусматривает приоритетной обработки чувствительного к задержке трафика путем его перемещения во главу очереди. Весь трафик обрабатывается одинаково, без учета принадлежности потоков к различным классам с разными требованиями к обслуживанию.
Минимальное требование, предъявляемое к поддерживающему функции QoS алгоритму обслуживания очередей, — способность дифференцировать и определять требования к обработке различных пакетов. В соответствии с этими параметрами алгоритм обслуживания должен планировать порядок передачи поставленных в очередь пакетов. Частота обслуживания пакетов одного и того же потока трафика определяет выделенную этому потоку полосу пропускания.
Более подробно функция распределения ресурсов рассматриваются в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”, далее в этой книге.
Предотвращение перегрузки и политика отбрасывания пакетов
Традиционный механизм обслуживания очередей FIFO предусматривает отбрасывание всех входяших пакетов после достижения максимального значения длины очереди. Подобный способ управления очередью получил название “отбрасывание хвоста” (tail drop) и характеризуется тем, что сигнал о перегрузке поступает лишь в момент фактического переполнения очереди. К сожалению, механизм FIFO не предусматривает проведения каких-либо активных действий по предотвращению перегрузки или по уменьшению размера очереди с целью снижения времени задержки. Активный алгоритм управления очередями позволяет маршрутизатору предвидеть перегрузку еше до переполнения очереди.
Более подробно механизм предотвращения перегрузки и политика отбрасывания пакетов рассматривается в главе 6, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов”, далее в этой книге.
Сигнальный протокол QoS
Сигнальный протокол RSVP является частью разработанной организацией IETF архитектуры intserv, обеспечивающей предоставление сквозных услуг QoS в масштабах Internet. Протокол RSVP позволяет приложениям сообшать о требованиях к обслуживанию отдельных потоков трафика. Для определения количественных показателей качества обслуживания с целью управления доступом протокол RSVP использует служебные параметры.
Более подробно сигнальный протокол RSVP рассматривается в главе 7, “Интегрированные услуги: RSVP”, далее в этой книге.
Коммутация
Главная функция маршрутизатора заключается в быстрой и эффективной коммутации входящего трафика на соответствующие выходные интерфейсы согласно информации, хранящейся в таблице продвижения пакетов. Традиционный механизм продвижения пакетов, несмотря на его эффективность, обладает низкой масштабируемостью; кроме того, его производительность оставляет желать лучшего в периоды нестабильного функционирования сети, что выражается в резком увеличении расходов на обслуживание кэша и снижении эффективности коммутации пакетов.
Метод продвижения пакетов, учитываюший топологию сети, обладает бесспорными преимуществами перед методом, базирующимся на кэшировании пакетов, что обусловлено совпадением таблицы продвижения пакетов с таблицей маршрутизации. Механизм продвижения пакетов, учитываюший топологию сети, называется также методом скоростной коммутации пакетов Cisco (Cisco Express Forwarding — CEF). Более подробно различные механизмы коммутации пакетов рассматриваются в приложении Б, “Механизмы коммутации пакетов”, далее в этой книге.
Маршрутизация
Традиционная маршрутизация осушествляется на основании адреса назначения пакета и предполагает выбор наименее короткого маршрута, храняшегося в таблице маршрутиза-
ции. К сожалению, подобный механизм является недостаточно гибким для некоторых сетевых сценариев. Маршрутизация на основе политики — это функция качества обслуживания, позволяющая заменить традиционный механизм маршрутизации пакетов механизмом, учитывающим всевозможные настраиваемые пользователем параметры.
Современные протоколы маршрутизации, работаюшие по методу выбора наименее короткого пути, позволяют учитывать такие значения метрики, как административное расстояние, вес или число переходов. Маршрутизация пакетов осуществляется на основании хранящейся в таблице маршрутизации информации без учета требований потока трафика к качеству обслуживания или доступности сетевых ресурсов на всем протяжении маршрута. 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) занимается стандартизацией базовой технологии, предполагающей применение механизма продвижения пакетов на основе замены меток (метод коммутации меток) и использующейся совместно с маршрутизацией сетевого уровня. Целью рабочей группы является разработка механизмов совместного использования технологии многопротокольной комму-
тации меток с различными технологиями канального уровня, включая 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-сети сквозного качества обслуживания следует
реализовать взаимодействие механизмов 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.
Аудитория
Эта книга предназначена для профессионалов в сфере межсетевого взаимодействия, в чью компетенцию входит разработка и поддержка функций обслуживания трафика для корпоративных интрасетей и сетей поставщиков услуг. Если вы являетесь сетевым инженером, архитектором, планировщиком, проектировщиком или операто-
ром, обладающим лишь начальными знаниями технологий QoS, данная книга поможет вам восполнить этот пробел и позволит развить практические навыки в планировании и внедрении в сети различных уровней качества обслуживания.
Помимо этого, в книге содержится материал, полезный для консультантов, системных инженеров и инженеров по сбыту, разрабатывающих IP-сети на заказ. Другими словами, данная книга рассчитана на широкую аудиторию, поскольку планирование некоторых функций качества обслуживания является неотъемлемой частью процесса проектирования практически любой 1Р-сети.
Широта охвата и ограничения изложенного в книге материала
Несмотря на попытку представить полное и исчерпывающее описание механизмов качества обслуживания в сетях IP и функций QoS, специфических для оборудования компании Cisco, некоторые вопросы в этой книге не рассматривались. Так, не приводится информация об архитектуре различных платформ Cisco, которая может иметь отношение к механизмам QoS. Кроме того, несмотря на попытку унифицированного подхода к изложению материала, авторам не удалось избежать описания некоторых особенностей, характерных только для определенных устройств компании Cisco, что связано, в первую очередь, с несогласованностью в реализации функций QoS на различных платформах.
Одной из целей, которые ставились при написании этой книги, было сохранение целостности и актуальности представленного в книге материала. Тем не менее следует отметить, что качество обслуживания в целом и механизмы QoS оборудования Cisco в частности ждет много нововведений, каждое из которых способно со временем повлиять на изложенный в книге материал.
Практические примеры, приведенные в книге, предназначены для обсуждения некоторых вопросов, связанных с внедрением и конфигурацией функций качества обслуживания в IP-сети. Естественно, данная книга ни в коем случае не претендует стать заменой документации компании Cisco. Документация Cisco по сей день является наилучшим источником информации, касающейся предназначенных для настройки механизмов QoS конфигурационных команд.
Следует отметить, что приведенные в книге практические примеры базируются на огромном числе различных версий операционной системы IOS. В большинстве случаев, если не оговорено противное, практические примеры базируются на версии операционной системы IOS 12.0(6)5 или более поздней версии 12.0S. Практические примеры, в которых рассматривается технология 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, “Приложения”, приводится описание
модульного интерфейса командной строки 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 с помо-
шью протокола пограничного шлюза (QoS Policy Propagation using Border Gateway Protocol — QPPB).
В приложении Г, “Транспортный протокол реального времени (RTP)”, обсуждается транспортный протокол, использующийся для пакетной передачи голосового трафика и трафика видеоизображений в масштабе реального времени.
В приложении Д, “Общие функции линейной эфективности протокола IP", представлен материал о некоторых функциях протокола IP, позволяющих увеличить доступную полосу пропускания.
В приложении Е, “Фрагментация и чередование пакетов на канальном уровне", обсуждаются функциональные возможности многоканального протокола двухточечной связи (Multilink Point-to-Point protocol), касающиеся фрагментации и чередования пакетов.
В приложении Ж, “Значения поля IP-приоритета и поля DSCP”, приводятся зата- булированные значения поля IP-приоритета и поля кода DSCP, а также иллюстрируется соотношение между данными характеристиками трафика.
В этой главе...
Архитектура интегрированных услуг (intserv)37
Архитектура дифференцированных услуг (diffserv) '38
ГлаваГлава22
Глава
Глава
2
2
Архитектура
дифференцированных услуг
Цель качества обслуживания в сетях IP (IP Quality of Service — IP QoS) — предосту тавление гарантированных и дифференцированных услуг в масштабах Internet или : любой другой 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), главной задачей которой являлось расширение базовой модели услуг Internet с целью обеспечения улучшенной поддержки разнообразных приложений, ориентированных на передачу голосового трафика и трафика видеоизображений. Созданная рабочая группа должна была четко определить новую усовершенствованную модель услуг Internet, разработать средства, позволяющие приложениям выражать сквозные требования к ресурсам, и создать механизмы, которые бы обеспечили надлежащую интерпретацию этих требований маршрутизаторами и различными технологиями, использующимися в подсетях. Основная идея при этом заключалась в отдельной обработке потоков трафика, запросивших определенный уровень качества обслуживания.
С этой целью были разработаны две услуги — гарантированного обслуживания и регулируемой нагрузки. Гарантированное обслуживание (guaranteed service) предполага-
ет предоставление детерминированных гарантий задержки, в то время как служба регулируемой нагрузки (controlled load service) использует механизм, похожий на механизм негарантированной доставки трафика в слегка загруженной сети. Более подробно каждая из этих услуг рассматривается в главе 7, “Интегрированные услуги: RSVP", далее в этой книге.
В качестве сигнального протокола, использующегося для передачи требований сквозного обслуживания, был предложен протокол резервирования ресурсов (Resource Reservation Protocol — RSVP).
Следует отметить, что модель intserv требует обеспечения гарантированного качества обслуживания для каждого отдельного потока трафика в масштабах Internet. Учитывая тот факт, что на сегодня в каждый момент времени в Internet существуют тысячи потоков трафика, объем информации, который должны поддерживать маршрутизаторы, может быть запредельно большим. К сожалению, это означает наличие практически неизбежных проблем, связанных с масштабированием сети, поскольку объем информации, который следует поддерживать маршрутизаторам, увеличивается пропорционально росту числа потоков трафика.
В 1998 году организация IETF сформировала рабочую группу по созданию дифференцированных услуг (difEserv Working Group). Архитектурную модель diflserv можно сравнить с мостом, соединяющим требования гарантированного качества обслуживания модели intserv с механизмом негарантированной доставки трафика, использующимся сегодня в Internet. Модель diflserv обеспечивает дифференцирование трафика путем его разбивки на классы с различным приоритетом.
Архитектура дифференцированных услуг (diffserv)
В соответствии с моделью diflserv обеспечение качества обслуживания в сети IP предполагает наличие небольшого числа четко определенных “строительных” блоков, на основе которых можно создать множество различных услуг. Главной задачей подхода diflserv является определение стандартизированного байта дифференцированной услуги (DS) — байта типа обслуживания (Type of Service — ToS) из заголовка пакета Internet Protocol (IP) Version 4 и байта класса трафика (Traffic Class) пакета IP Version 6 — и его соответствующая маркировка, от которой зависит принятие специфического решения о продвижении пакета данных на каждом переходе (per-hop behavior — РНВ), т.е. в каждом промежуточном узле.
Архитектура дифференцированных услуг обеспечивает базовую основу, которая может быть использована поставщиками услуг для предоставления своим клиентам большого диапазона различных предложений в зависимости от предъявляемых требований к качеству обслуживания. Клиент может выбрать требуемый уровень услуг путем установки соответствующего значения поля кода дифференцированной услуги (Differentiated Services Code Point — DSCP) для каждого отдельного пакета. Код дифференцированной услуги определяет цепочку решений о продвижении пакета в каждом промежуточном узле сети поставщика услуг (РНВ-политика). Как правило, поставщик услуг обсуждает
вместе с заказчиком профиль, согласно которому каждому уровню обслуживания будет соответствовать определенная интенсивность передачи трафика. Если же объем передаваемого трафика превысит установленную квоту для данного уровня обслуживания, то предоставление оговоренных услуг для “сверхплановых” пакетов не гарантируется.
Следует отметить, что архитектура дифференцированных услуг определяет всего лишь базовые механизмы, на основе которых осуществляется обслуживание пакетов. Используя эти механизмы в качестве строительных блоков, вы можете разработать целое множество различных услуг. Напомним, что в данном случае услуга определяет весьма значительные характеристики передачи пакетов, такие, как пропускная способность, задержка, дрожание, а также уровень потери пакетов в одном направлении при передаче вдоль сетевого маршрута. К тому же вы можете охарактеризовать услугу в терминах относительного приоритета при доступе к ресурсам сети. После определения услуги разрабатываются соответствующие ей решения о продвижении пакета (РНВ-политика) для каждого узла сети, поддерживающего данную услугу. РНВ-политике присваивается определенный код DSCP. РНВ-политика — это наблюдаемая извне политика поведения сетевого узла в отношении пакетов с определенным значением поля кода дифференцированной услуги (DSCP). Все пакеты потока трафика со специфическим требованием к обслуживанию несут в себе одно и то же значение поля DSCP.
Все узлы внутри diflserv-домена определяют РНВ-политику, которая должна быть применена к пакету на основе хранящегося в нем значения поля кода дифференцированной услуги. Кроме того, пограничные узлы diflserv-домена выполняют очень важную функцию формирования поступающего в diflserv-домен трафика. Формирование трафика включает в себя выполнение таких функций, как классификация пакетов и ограничение трафика, и обычно выносится на входной интерфейс поступающих в diflserv-домен пакетов. Формирование играет решающую роль в управлении поступающим в diflserv-домен трафиком, поскольку в этом случае для каждого пакета сеть может определить соответствующую ему РНВ-политику.
На рис. 2.1 схематически представлена архитектура дифференцированных услуг. Описание двух основных функциональных блоков этой архитектуры приведено в табл. 2.1.
установка значения поля DSCP;
ограничение трафика.
Рис. 2.1. Архитектура дифференцированных услуг
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-приоритет, код
дифференцированной услуги позволяет определять способ обработки отмеченных соответствующим образом пакетов данных. На рис. 2.3 представлена структура байта ToS. После стандартизации поля кода дифференцированной услуги байт ToS будет переименован в байт DS. На рис. 2.4 представлена структура байта DS.
| Р2 | Р1 | РО | ТЗ | Т2 I Т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 следующим образом.
Стандартный код DCSP. Определен как ООО 000.
Селектор класса. Эти коды DCSP обладают обратной совместимостью с кодами IP-приоритета и представлены в табл. 2.2.
: Таблица 2.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). Этот код DSCP соответствует наиболее высококлассному уровню обслуживания, предоставляемому за дополнительную стоимость. Рекомендуемое значение — 101 НО.
РНВ-политика гарантированной передачи (Assured Forwarding — AF). Эти коды DSCP определяют четыре уровня обслуживания, каждый из которых, в свою очередь, может быть охарактеризован тремя уровнями приоритета отбрасыва-
ния пакетов данных. Как результат РНВ-политике гарантированной передачи соответствуют 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 в зависимости от класса трафика, к которому относится данный пакет.
Дозирование трафика
Функция дозирования проверяет трафик на соответствие заданному профилю на основании дескриптора трафика, такого, как корзина маркеров. Результаты проверки передаются функции маркировки трафика, а также либо функции выравнивания трафика, либо функции отбрасывания пакетов для принятия соответствующего решения в отношении “плановых” и “внеплановых” пакетов.
Функция выравнивания трафика
Функция выравнивания трафика (traffic shaping) осуществляет задержку пакетов путем их буферизации с целью удовлетворения параметров заданного профиля.
Функция отбрасывания пакетов
Функция отбрасывания пакетов осуществляет отбрасывание всех пакетов, не удовлетворяющих параметрам заданного профиля трафика. Это действие часто называют также ограничением трафика (traffic policing).
РНВ-политика
Сетевые узлы с поддержкой дифференцированного обслуживания используют поле DSCP в заголовке IP-пакета для определения соответствующей этому пакету РНВ-политики.
РНВ-политика может быть определена в терминах приоритета в предоставлении ресурсов по отношению к другим РНВ-политикам или же с помощью таких измеряемых характеристик трафика, как задержка пакетов, уровень потери пакетов или дрожание трафика. В некоторой степени РНВ-политику можно рассматривать как своеобразный “черный ящик”, поскольку она определяет некоторое наблюдаемое извне поведение сетевого узла в отношении поступающих пакетов, не навязывания при этом конкретную реализацию.
В качестве стандартной РНВ-политики в diffserv-сети можно рассматривать негарантированную доставку трафика. В соответствии с архитектурой дифференцированного обслуживания каждой РНВ-политике рекомендуется назначить определенный код DSCP, однако поставщик услуг волен выбрать отличные от рекомендованных значения поля DSCP для своей собственной сети. Рекомендованное значение поля DSCP для политики негарантированной доставки пакетов равняется 000000.
РНВ-политика, соответствующая определенному классу трафика, зависит от целого ряда факторов.
Интенсивность входного потока или нагрузки для заданного класса трафика. Этот параметр контролируется пограничным формирователем трафика.
Распределение ресурсов для заданного класса трафика. Этот параметр контролируется функциями распределения ресурсов, реализованными в узлах diffserv- домена. Более подробно распределение ресурсов в узлах diffserv-сети рассматривается в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”, и главе 5, “РНВ-политика: распределение ресурсов (часть 2)”, далее в этой книге.
Уровень потери трафика. Этот параметр зависит от политики отбрасывания пакетов, проводимой в узлах diffserv-домена. Более подробно данная функция рассматривается в главе 6, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов”.
Существуют две стандартные РНВ-политики — РНВ-политика немедленной передачи (EF РНВ) и РНВ-политика гарантированной доставки (AF РН В). Их рассмотрению посвящены два следующих раздела этой главы.
РНВ-политика немедленной передачи пакетов (EF РНВ)
РНВ-политика немедленной передачи пакетов (Expedited Forwarding РНВ — EF РНВ) используется для обеспечения сквозного обслуживания пакетов в узлах diffserv- домена, характерными чертами которого являются низкий уровень потери пакетов, малая задержка, незначительное дрожание трафика, а также гарантированная полоса пропускания. Политика 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)”, далее в этой книге.
Если обработка EF-трафика реализуется за счет организации приоритетной очереди, следует убедиться в том, что оставшиеся очереди трафика не испытывают недостатка в поступающих пакетах в рамках определенного предела. В целях предотвращения этой проблемы можно определить максимальную интенсивность трафика, обрабатываемого с помощью приоритетной очереди. Если интенсивность поступающего EF-трафика превысит заданный предел, весь избыточный трафик будет отброшен. Пограничные формирователи поступающего в diffserv-домен трафика должны быть сконфигурированы таким образом, чтобы интенсивность EF-трафика никогда не превышала заданного предела на любом участке сети.
Рекомендуемое значение поля DSCР для EF-трафика равняется 101110.
РНВ-политика гарантированной доставки пакетов (AF РНВ)
РНВ-политика гарантированной доставки пакетов (Assured Forwarding РНВ — AF РНВ) представляет собой средство, с помошью которого поставщик услуг может обеспечить несколько различных уровней надежности доставки IP-пакетов, полученных из diffserv-домена клиента. Политика AF РНВ является приемлемой для большинства ТСР-приложений.
РНВ-политика гарантированной доставки пакетов подразумевает наличие различных уровней обслуживания для каждого из четырех классов AF-трафика. Каждому классу AF-трафика соответствует своя собственная очередь пакетов, что позволяет проводить эффективное управление полосой пропускания. Каждый класс AF-трафика характеризуется тремя уровнями приоритета отбрасывания пакетов (низкий, средний и высокий), что позволяет реализовать механизм управления очередью по типу механизма произвольного раннего обнаружения (Random Early Detection — RED).
Политика распределения ресурсов
В последнем разделе этой главы мы обсудим способы реализации РНВ-политик в diffserv-сети. Каким образом происходит формирование трафика на границе сети и распределение ресурсов в ее узлах для достижения определенной РНВ-политики? Существует три решения: инициализация сети, сигнализация о качестве обслуживания и диспетчер политик.
Инициализация сети
Один из способов распределения ресурсов заключается в инициализации ресурсов сети с использованием эвристических методов или техники систематического моделирования. Следует отметить, что этот метод может быть применен только в сетях небольшого размера, для которых политики QoS и профили трафика остаются неизменными на протяжении достаточно долгого промежутка времени.
Сигнализация о качестве обслуживания
В соответствии с этим методом реализации РНВ-политики приложения извещают сеть о требованиях к качеству обслуживания с помошью сигнального протокола RSVP. С точки зрения протокола RSVP diffserv-домен рассматривается как еше одно звено сети, требующее управление доступом. С помошью протокола RSVP можно ус-
тановить соответствие между запросами к качеству обслуживания приложений и классами услуг diffserv. К примеру, гарантированному обслуживанию RSVP может быть поставлена в соответствие diffserv-услуга немедленной передачи пакетов.
Сигнализация о качестве обслуживания является чрезвычайно масштабируемым решением в крупных сетях, поскольку протокол RSVP выполняется только в пограничных узлах diffserv-домена, как показано на рис. 2.5.
Дифференцированные услуги
Сквозная передача сигнальной информации протокола RSVP через сеть с дифференцированным обслуживанием
Рис. 2.5. Передача сигнальной информации протокола RSVP через сеть с дифференцированным обслуживанием
Установка соответствия между резервированием ресурсов протокола RSVP и diffserv-классами проводится на границе diffserv-сети. Учитывая широкую поддержку протокола RSVP (к примеру, RSVP поддерживается операционной системой Microsoft Windows 2000), уведомленные о существующей политике пограничные приложения могут использовать его для сообщения требований к качеству обслуживания, не обращая при этом внимания на возможное увеличение масштабов сети. Это решение хорошо подходит для реализации в крупных корпоративных сетях.
Протокол RSVP обладает выдающейся способностью к масштабированию — он может поддерживать несколько тысяч выполняющихся параллельно сеансов передачи информации. К тому же сейчас ведется работа по реализации протокола RSVP с поддержкой агрегирования. Несколько резервирований ресурсов протокола RSVP могут быть объединены в одно агрегированное резервирование в случае применения протокола RSVP в масштабе крупной базовой сети, требующей управления доступом с учетом топологии. Агрегированное резервирование ресурсов протокола RSVP представляет собой мощное, медленно регулируемое состояние резервирования, которое позволяет снизить объем сигнальной информации в базовой сети. Аналогично обычному резервированию ресурсов протокола RSVP, вы можете установить соответствие между агрегированным резервированием и diffserv-классом.
Диспетчер политик QoS
Определение политики обусловливает выбор стратегии QoS, применяемой к потоку трафика. Политика определяет трафик, необходимый для функционирования критически важных приложений, и соответствующий ему уровень услуг QoS. На самом деле политика представляет собой всего лишь определенную конфигурацию, которая должна быть реализована во всех узлах QoS-сети. Каким же образом узел QoS-сети узнает о назначенной ему политике?
Если взять наиболее простой случай, сетевой инженер может собственноручно настроить 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.
Резюме
В этой главе были рассмотрены две различные архитектуры 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.
В этой главе...
Классификация пакетов52
Маркировка пакетов'53
Необходимость управления интенсивностью трафика61
Ограничение трафика?62
Выравнивание трафика’ /< >; - 74
Глава
3
Формирование трафика на границе сети: классификация пакетов, марки ровна пакетов
и управление интенсивностью трафика
■' Функции формирования трафика, реализованные в пограничных устройствах сети, ‘ являются жизненно важными для обеспечения дифференцированного обслуживания в пределах diffserv-домена. К этим функциям относятся функции классификации трафика, маркировки пакетов и управления интенсивностью трафика.
Как правило, передаваемые по сети пакеты различают по их принадлежности к тому или иному потоку трафика, определяемому пятью полями заголовка IP-пакета: адрес источника IP-пакета, адрес назначения IP-пакета, поле протокола IP, порт источника и порт назначения. Поток информации состоит из пакетов, сгенерированных приложением, выполняющемся на компьютере-источнике, и предназначающихся для передачи приложению, выполняющемуся на компьютере-приемнике. Пакеты, принадлежащие одному потоку, имеют одинаковые значения всех пяти полей в заголовке IP-пакета. Поскольку число потоков трафика может оказаться достаточно большим, функции качества обслуживания, применяемые к отдельному потоку трафика, не обладают масштабируемостью. Маршрутизаторы, расположенные на границе сети, проводят классификацию пакетов с целью отнесения их к тому или иному классу трафика на основании значения одного или нескольких полей в заголовке TCP/IP-пакета. Функция маркировки используется для “раскраски” классифицированного трафика путем установки соответствующего значения поля 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. Более подробно модульный ин-
терфейс командной строки QoS (Modular QoS CLI) рассматривается в приложении А, “Модульный интерфейс командной строки Cisco QoS”, далее в этой книге.
Классификацию пакетов часто называют также маркировкой (packet marking) или раскраской пакетов (packet coloring). Все пакеты, принадлежащие определенному классу трафика, “окрашиваются” в соответствующий цвет.
Маркировка пакетов
Маркировка пакетов используется для идентификации соответствующего им класса трафика. Пакеты могут быть маркированы путем установки значения поля IP- приоритета или поля кода дифференцированной услуги (DSCP), расположенных в заголовке IP-пакета, а также путем установки значения поля QoS-группы, относящегося к внутренней по отношению к маршрутизатору структуре данных пакета.
IP-приоритет
Поле IP-приоритета, расположенное в заголовке IP-пакета, указывает на относительный приоритет при обработке соответствующего пакета данных. Поле IP- приоритета состоит из трех битов байта типа обслуживания (Type of Service — ToS). Помимо битов IP-приоритета, байт ToS содержит биты типа обслуживания (ToS- биты). ToS-биты были предназначены для хранения значений, определяющих способ обработки соответствующего пакета данных в сети, однако на практике они не получили широкого распространения. Схема байта ToS, включающая биты IP-приоритета и ToS-биты, представлена на рис. 2.3 в главе 2, “Архитектура дифференцированных услуг”, ранее в этой книге. В табл. 3.1 перечислены все допустимые комбинации битов IP-приоритета вместе с их значениями и названиями.
{Таблица 3.1. Значения и названия битов IP-приоритета v , J
Значение 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 не рекомендуется назначать трафику пользовательских приложений.
“Раскраска” пакетов путем установки значения поля 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, “Архитектура дифференцированных услуг”. Там же можно найти определения поля DSCP и рекомендуемые значения кода дифференцированной услуги для различных РНВ-политик.
Аналогично IP-приоритету, поле DSCP является частью заголовка IP-пакета. На самом деле поле DSCP представляет собой расширение поля IP-приоритета. Следовательно, способы использования и установки значения поля DSCP во многом напоминают рассмотренные нами ранее способы использования и установки значения поля IP-приоритета.
Следует отметить, что поле кода дифференцированной услуги (DSCP) обладает обратной совместимостью с полем IP-приоритета.
QoS-группа
QoS-группа представляет собой поле внутренней по отношению к маршрутизатору структуры данных пакета. Поле QoS-группы применяется для маркировки пакетов на основании определенных пользователем критериев классификации. Следует отметить,
что поле QoS-группы является внутренним по отношению к маршрутизатору и не входит в заголовок IP-пакета.
С помощью поля QoS-группы производится внутренняя по отношению к маршрутизатору “раскраска” пакета. Средства качества обслуживания Cisco, поддерживающие данную функцию маркировки пакетов, включают в себя механизм согласования скорости доступа (CAR) и механизм распространения политик QoS с помощью протокола пограничного шлюза (QPPB). Классификация и маркировка пакетов с помощью поля QoS-группы рассматриваются в практическом примере 3.2 далее в этой главе.
Модульный интерфейс командной строки QoS позволяет проводить маркировку пакетов с использованием любого из трех рассмотренных выше механизмов. В табл. 3.2 приведена сравнительная характеристика механизмов маркировки пакетов с помощью поля IP-приоритета, поля DSCP и поля QoS-группы.
Таблица 3.2. Маркировка трафика с использованием поля IP-приоритета, поля DSCP и поля QoS-группы'
Атрибуты
IP-приоритет
DSCP
QoS-rpynna
Область
Вся сеть. Значение поля
Вся сеть. Значение поля
Внутреннее поле по от-
классификации
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.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-приоритета на основании соответствующего списка доступа.
Примечание
Механизм согласования скорости доступа (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
Express Forwarding — СЕР) из таблицы маршрутизации наряду с информацией о продвижении пакета извлекается и значение поля 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-приоритета пакетов.
В данном практическом примере рассматривается классификация пакетов путем установки значения поля 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
S>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.3: переопределение значения поля IP-приоритета
Поставщик услуг предлагает своим клиентам различные уровни обслуживания трафика в добавление к негарантированной доставке трафика. Трафик клиентов, оплачивающих дополнительные услуги, маркируется посредством установки значения поля IP-приоритета, равного 5, а трафик всех оставшихся клиентов — посредством установки значения поля IP-приоритета, равного 0 (рис. 3.2). Установка значения поля IP-приоритета производится на границе сети поставщика услуг в зависимости от уровня обслуживания клиентов.
Поставщик услугПоставщик услугHssi 1/1Hssi 1/1Маркировка пакетов путам устаноаки IP-приоритета ОМаркировка пакетов путам устаноаки IP-приоритета ОМаркировка пакетов путем установки 1Р-приоритата 5Маркировка пакетов путем установки 1Р-приоритата 5Клиент, оплачивающий услугу передачи трафика методом негарантированной доставкиКлиент, оплачивающий услугу передачи трафика методом негарантированной доставкиКлиант, оплачивающий дополнительные услуги передачи трафикаКлиант, оплачивающий дополнительные услуги передачи трафикаHssi 1/0Hssi 1/0Рис. 3.2. Установка IP-npuopumema входящего трафика в зависимости от уровня обслуживания клиентовРис. 3.2. Установка IP-npuopumema входящего трафика в зависимости от уровня обслуживания клиентов
Поставщик услуг
Поставщик услуг
Hssi 1/1
Hssi 1/1
Маркировка пакетов путам устаноаки IP-приоритета О
Маркировка пакетов путам устаноаки IP-приоритета О
Маркировка пакетов путем установки 1Р-приоритата 5
Маркировка пакетов путем установки 1Р-приоритата 5
Клиент, оплачивающий услугу передачи трафика методом негарантированной доставки
Клиент, оплачивающий услугу передачи трафика методом негарантированной доставки
Клиант, оплачивающий дополнительные услуги передачи трафика
Клиант, оплачивающий дополнительные услуги передачи трафика
Hssi 1/0
Hssi 1/0
Рис. 3.2. Установка IP-npuopumema входящего трафика в зависимости от уровня обслуживания клиентов
Рис. 3.2. Установка IP-npuopumema входящего трафика в зависимости от уровня обслуживания клиентов
Поставщик услуг должен присвоить IP-приоритет 0 всему трафику клиентов, оплачивающих услугу негарантированной доставки трафика. Трафику клиентов, оплачивающих дополнительные услуги, следует присвоить IP-приоритет 5.
Установка IP-приоритета производится механизмом CAR, сконфигурированным на высокоскоростных последовательных интерфейсах маршрутизатора, подключенного к сетям клиентов (листинг 3.6).
,
|Листийг,3.6. Использование механизма CAR для маркировки трафика |, путем установки значения поля IP-приоритета.
interface Hssi 1/0
rate-limit input 45000000 22500 22500 conform-action
S>set-prec-transmit 0 exceed-action set-prec-transmit 0
interface Hssi 1/1
rate-limit input 10000000 22500 22500 conform-action
S>set-prec-transmit 5 exceed-action set-prec-transmit 5
Интерфейс Hssi 1/0 подключен к сети клиента, оплачивающего услугу негарантированной доставки пакетов. Следовательно, всему поступающему на данный интерфейс трафику необходимо присвоить IP-приоритет 0.
Аналогично, интерфейс Hssil/1 подключен к сети клиента, оплачивающего дополнительные услуги передачи пакетов. Следовательно, всему поступающему на данный интерфейс трафику необходимо присвоить IP-приоритет 5.
Необходимость управления интенсивностью трафика
С целью обеспечения функций качества обслуживания весь входящий в сеть поставщика услуг трафик должен проходить строгий контроль на границе сети на предмет соответствия его интенсивности поддерживаемым сетью параметрам. Даже если небольшое число пограничных маршрутизаторов начнут передавать трафик с интенсивностью, превышающей максимально допустимое значение, увеличившаяся нагрузка потока трафика может привести к перегрузке сети. Следует отметить, что снижение производительности сети неизбежно приведет к невозможности обеспечения функций качества обслуживания для всего сетевого трафика.
Управление интенсивностью трафика может быть достигнуто за счет применения двух функций: функции ограничения трафика, предусмотренной механизмом CAR, и функции выравнивания трафика (traffic shaping — TS), предусмотренной одноименным механизмом. Несмотря на одинаковое предназначение, названные выше функции отличаются способом обработки трафика в момент исчерпания маркеров. Понятие маркера исходит из схемы “корзина маркеров” — известного алгоритма дозированной передачи трафика, который рассматривается в следующих разделах этой главы. В табл. 3.3 приведена сравнительная характеристика функции ограничения и функции выравнивания трафика.
Таблица 3.3. Сравнительная характеристика функции ограничения : > : и функции выравнивания трафика ч ;у,-
Функция ограничения трафика (механизм CAR) Функция выравнивания трафика (механизм TS)
Пересылает удовлетворяющий заданным параметрам трафик с линейной интенсивностью. Допускает всплеск трафикаВ случае исчерпания маркеров возможно отбрасывание пакетовПрименяется для обработки входящего и исходящего трафикаПротокол управления передачей (Transmission Control Protocol — TCP) определяет доступную полосу пропускания, однако адаптируется в моменты отбрасывания пакетов путем сужения размеров окнаПересылает удовлетворяющий заданным параметрам трафик с линейной интенсивностью. Допускает всплеск трафикаВ случае исчерпания маркеров возможно отбрасывание пакетовПрименяется для обработки входящего и исходящего трафикаПротокол управления передачей (Transmission Control Protocol — TCP) определяет доступную полосу пропускания, однако адаптируется в моменты отбрасывания пакетов путем сужения размеров окнаСглаживает трафик и пересылает его с постоянной интенсивностьюВ случае исчерпания маркеров пакеты помещаются в буфер и извлекаются из него по мере появления доступных маркеровВ существующей реализации применяется только для обработки исходящего трафикаЕсли протокол TCP определяет, что скорость передачи информации по линии связи недостаточна для передачи поступающего трафика, он настраивает соответствующим образом таймер повторной передачи пакетов. Результатом этого является уменьшение числа повторно переданных пакетов, что положительно влияет на работу протокола TCPСглаживает трафик и пересылает его с постоянной интенсивностьюВ случае исчерпания маркеров пакеты помещаются в буфер и извлекаются из него по мере появления доступных маркеровВ существующей реализации применяется только для обработки исходящего трафикаЕсли протокол TCP определяет, что скорость передачи информации по линии связи недостаточна для передачи поступающего трафика, он настраивает соответствующим образом таймер повторной передачи пакетов. Результатом этого является уменьшение числа повторно переданных пакетов, что положительно влияет на работу протокола TCP
Пересылает удовлетворяющий заданным параметрам трафик с линейной интенсивностью. Допускает всплеск трафика
В случае исчерпания маркеров возможно отбрасывание пакетов
Применяется для обработки входящего и исходящего трафика
Протокол управления передачей (Transmission Control Protocol — TCP) определяет доступную полосу пропускания, однако адаптируется в моменты отбрасывания пакетов путем сужения размеров окна
Пересылает удовлетворяющий заданным параметрам трафик с линейной интенсивностью. Допускает всплеск трафика
В случае исчерпания маркеров возможно отбрасывание пакетов
Применяется для обработки входящего и исходящего трафика
Протокол управления передачей (Transmission Control Protocol — TCP) определяет доступную полосу пропускания, однако адаптируется в моменты отбрасывания пакетов путем сужения размеров окна
Сглаживает трафик и пересылает его с постоянной интенсивностью
В случае исчерпания маркеров пакеты помещаются в буфер и извлекаются из него по мере появления доступных маркеров
В существующей реализации применяется только для обработки исходящего трафика
Если протокол TCP определяет, что скорость передачи информации по линии связи недостаточна для передачи поступающего трафика, он настраивает соответствующим образом таймер повторной передачи пакетов. Результатом этого является уменьшение числа повторно переданных пакетов, что положительно влияет на работу протокола TCP
Сглаживает трафик и пересылает его с постоянной интенсивностью
В случае исчерпания маркеров пакеты помещаются в буфер и извлекаются из него по мере появления доступных маркеров
В существующей реализации применяется только для обработки исходящего трафика
Если протокол TCP определяет, что скорость передачи информации по линии связи недостаточна для передачи поступающего трафика, он настраивает соответствующим образом таймер повторной передачи пакетов. Результатом этого является уменьшение числа повторно переданных пакетов, что положительно влияет на работу протокола TCP
Корзина маркеров
В процессе своей работы механизм управления интенсивностью трафика полагается на функцию дозирования трафика. Одной из наиболее распространенных схем до-
зирования трафика является так называемая схема “корзина маркеров’’ (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 f rate-limit ''CIR'1
^"согласованный всплеск" "расширенный всплеск"
?>conform-action "требуемое действие"
^exceed-action "требуемое действие"
Каждый оператор ограничения интенсивности трафика состоит из трех элементов.
Алгоритм обработки оператора rate-limit схематически представлен на рис. 3.3.
Переход к следующему оператору rate-limitПереход к следующему оператору rate-limitРис. 3.3. Алгоритм обработки оператора rate-limitРис. 3.3. Алгоритм обработки оператора rate-limit
Переход к следующему оператору rate-limit
Переход к следующему оператору rate-limit
Рис. 3.3. Алгоритм обработки оператора rate-limit
Рис. 3.3. Алгоритм обработки оператора rate-limit
Условие совпадения трафика
Условие совпадения трафика позволяет определить пакеты, которые должны быть обработаны с помощью механизма CAR. Условие совпадения трафика проверяется последовательно для каждого из операторов rate-limit. В случае соответствия пакета указанным параметрам выполняется алгоритм “корзина маркеров”. Если действие, которое необходимо предпринять по завершении алгоритма, является действием продолжения, то к рассмотрению принимается следующий по списку оператор rate-limit. Обратите внимание, что условие совпадения трафика может быть составлено таким образом, чтобы охватить собой все пакеты.
Пакет, “прошедший” все операторы rate-limit, должен быть передан. При необходимости вы можете разместить в конце списка операторов rate-limit оператор, который будет отбрасывать все пакеты.
Условие совпадения трафика может быть составлено одним из четырех перечисленных ниже способов.
Условие совпадения трафика охватывает собой все пакеты.
Пакеты отбираются на основании значения поля IP-приоритета с использованием ограничивающих интенсивность трафика списков доступа.
Пакеты отбираются на основании МАС-адреса с использованием ограничивающих интенсивность трафика списков доступа.
Пакеты отбираются с использованием стандартных или расширенных списков доступа на основе IP-адреса.
Списки доступа, ограничивающие интенсивность трафика, были специально созданы с целью обеспечения возможности отбора пакетов на основании значения поля IP-приоритета и МАС-адреса. Использование ограничивающих интенсивность трафика списков доступа, а также других способов отбора пакетов рассматривается в практических примерах далее в этой главе.
Дозирование трафика
Основным средством дозирования трафика является схема “корзина маркеров”. Реали
зация этой схемы в рамках механизма согласования скорости доступа (CAR) представлена
на рис. 3.4.
ПоступившиепакетыПоступившиепакетыИзбыточные маркерыИзбыточные маркерыВс — согласованный размер всплескаТ — интенсивность поступления маркеровВс — согласованный размер всплескаТ — интенсивность поступления маркеровПереданные пакеты(согласованное действие)Переданные пакеты(согласованное действие)
Поступившиепакеты
Поступившиепакеты
Избыточные маркеры
Избыточные маркеры
Вс — согласованный размер всплеска
Т — интенсивность поступления маркеров
Вс — согласованный размер всплеска
Т — интенсивность поступления маркеров
Переданные пакеты(согласованное действие)
Переданные пакеты(согласованное действие)
Отброшенные пакеты(действие по переполнению)
Рис. 3.4. Стандартная реализация схемы “корзина маркеров" в рамках механизма согласования скорости доступа (CAR)
Размер корзины маркеров (максимальное число маркеров, которое может вместить корзина) равен согласованному размеру всплеска (Вс). Для каждого пакета, обрабатываемого в соответствии с механизмом CAR, из корзины вынимается число маркеров, равное размеру пакета в байтах. Если для обслуживания пакета в корзине нашлось достаточное количество маркеров, пакет передается. Если же размер в байтах поступившего пакета больше, чем текущее количество доступных маркеров, учитывается расширенный размер всплеска (ВЕ). Рассмотрим две типичные ситуации.
Стандартная корзина маркеров, ВЕ = Вс.
Стандартная корзина маркеров не поддерживает возможность экстренного увеличения размера всплеска. Расширенный размер всплеска для стандартной корзины маркеров всегда равен согласованному размеру всплеска (Вс). В этом случае нехватка маркеров приводит к отбрасыванию пакета.
Корзина маркеров с возможностью экстренного увеличения размера всплеска, ВЕ > Вс.
В отличие от стандартной корзины маркеров, корзина маркеров с возможностью экстренного увеличения размера всплеска позволяет “занять” недостающие марке-
ры. Поскольку вся последующая за этим дискуссия будет самым непосредственным образом касаться темы заимствования, позволим себе ввести два “долговых” термина — текущий долг (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), равное текущему долгу (ОД Например, в том случае, если четвертый пакет будет отброшен, следующему пакету, для передачи которого потребуется занять маркеры (предположим, 100), будет поставлено в соответствие значение накопленного долга Dc = DA = 400 ( = 300 + 100). Обратите внимание, что, в отличие от накопленного долга (Dc), значение текущего долга (DA) не обнуляется после отбрасывания пакета. Если текущий долг (DA) превышает расширенную границу, пакеты отбрасываются до тех пор, пока значение DA не вернется в допустимые пределы (напомним, что уменьшение текущего долга производится за счет накопления маркеров).
Потребность в использовании корзины с возможностью экстренного увеличения размера всплеска обуславливается таким весьма нежелательным свойством стандартной корзины маркеров, как “отбрасывание хвоста” (tail-drop). Корзина маркеров с возможностью экстренного увеличения размера всплеска обеспечивает постепенное отбрасывание пакетов, более характерное для алгоритма произвольного раннего обнаружения (Random Early Detection — RED). Подробное рассмотрение алгоритма произвольного раннего обнаружения приводится в главе 6, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов”, далее в этой книге. Если для передачи вновь пришедшего пакета требуется занять некоторое число маркеров, проводится сравнение расширенного размера всплеска (В^ и накопленного долга (Dc). Если Dc больше, чем ВЕ, пакет отбрасывается, а значение накопленного долга (Dc) обнуляется. В противном случае пакет передается, при этом текущий долг (DA) увеличивается на число занятых маркеров, а накопленный долг (Dc) — на величину, равную обновленному значению текущего долга (DA).
Следует отметить, что когда пакет отбрасывается по причине нехватки маркеров (т.е. когда число доступных маркеров меньше размера пакета в байтах), корзина не опустошается (другими словами, отбрасывание пакетов не приводит к уменьшению границы всплеска или границы интенсивности трафика).
Обратите внимание, что согласованная скорость передачи данных (CIR) — это величина, измеряемая в байтах в секунду. В свою очередь всплеск трафика выражается в байтах. Текущий размер всплеска хранится в счетчике всплеска. Значение счетчика всплеска может быть как меньше, так и больше, чем согласованный размер всплеска (Вс). Когда значение счетчика всплеска превышает Вс, оно равно сумме согласованного размера всплеска и текущего долга Вс + DA. В момент поступления нового пакета значение счетчика всплеска обновляется, как показано на рис. 3.5.
Счетчик всплеска
Согласованное действие(передача пакета)Согласованное действие(передача пакета)Действие по переполнению(отбрасывание пакета)Действие по переполнению(отбрасывание пакета)ВЕ
Согласованное действие(передача пакета)
Согласованное действие(передача пакета)
Действие по переполнению(отбрасывание пакета)
Действие по переполнению(отбрасывание пакета)
Пропорциональное размерувсплеска действие по переполнению
Вс — согласованный всплескВ Е — расширенный всплеск
Рис. 3.5. Выбор соответствующего действия в отношении вновь прибывшего пакета на основании значения счетчика всплеска
В случае, когда значение счетчика всплеска находится между согласованным (Вс) и расширенным (ВЕ) размерами всплеска, вероятность действия по переполнению может быть приблизительно рассчитана по следующей формуле:
(Счетчик всплеска - ВС) + (ВЕ - ВС).
На рис. 3.6 представлен график вероятности отбрасывания пакета механизмом CAR с учетом предложенной аппроксимации.
Вероятность отбрасыванияпакета, %
100100Согласованный РасширенныйСогласованный РасширенныйСчетчик всплескаСчетчик всплескавсплесквсплесквсплесквсплескРис. 3.6. График вероятности отбрасывания пакета механизмом CARРис. 3.6. График вероятности отбрасывания пакета механизмом CAR
100
100
Согласованный Расширенный
Согласованный Расширенный
Счетчик всплеска
Счетчик всплеска
всплеск
всплеск
всплеск
всплеск
Рис. 3.6. График вероятности отбрасывания пакета механизмом CAR
Рис. 3.6. График вероятности отбрасывания пакета механизмом CAR
Линейное возрастание вероятности отбрасывания пакета механизмом CAR на отрезке между согласованным и расширенным размерами всплеска напоминает линейное возрастание вероятности отбрасывания пакета механизмом RED на отрезке между минимальным и максимальным пороговым значением.
Примечание
Для упрощения восприятия материала на протяжении всего раздела под согласованным действием и действием по переполнению подразумевается соответственно передача и отбрасывание пакета. В действительности же согласованное действие и действие по переполнению может быть определено множеством различных способов, которые рассматриваются в разделе “Политика действия" далее в этой главе.
Следует отметить, что типичный оператор ограничения интенсивности трафика, в котором согласованный (Вс) и расширенный (ВЕ) размеры всплеска равны между собой, исключает возможность линейного возрастания вероятности отбрасывания пакета на каком-либо участке.
Текущая реализация механизма согласования скорости доступа (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 — универсальный интерфейсный процессор).
Примечание
Конфигурирование интенсивности трафика для отдельного интерфейса (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
^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
access-list 101 permit tcp any any eq ww access-list 101 permit tcp any eq ww any
Первый оператор rate-limit ограничивает интенсивность всего входящего трафика до 30 Мбит/с. В качестве согласованного действия используется действие продолжения (continue), указывающее на необходимость перехода к анализу следующего по списку оператора rate-limit. Второй оператор rate-limit используется для маркировки НТТР- трафика с помощью поля IP-приоритета в зависимости от его интенсивности. И, наконец, последний оператор rate-limit используется для маркировки всего оставшегося (не HTTP-) трафика с помощью установки значения поля IP-приоритета, равного 4. В
листингах 3.8 и 3.9 приведен результат выполнения некоторых важных show-команд механизма CAR.
; Листинг 3.8. Параметры механизма CAR и статистика обработки пакетов*?;^ ishow 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 # bps) вычисляется путем деления общего объема переданного трафика с момента последнего обновления счетчиков на время передачи.
! Листинг 3.9. Статистика учета IP-приоритета входящего и исходящего,. ?
' • •• . трафика для интерфейса Hssi1/O/O , </
#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.5: ограничение интенсивности трафика в зависимости от значения IP-приоритета
Поставщик услуг ограничивает интенсивность низкоприоритетного трафика, поступающего из сети партнера по линии связи DS3. Ограничение интенсивности трафика со значением IP-приоритета 0, 1 и 2 — 10 Мбит/с, в то время как высокоприоритетный трафик передается без каких-либо ограничений (рис. 3.7).
Рис. 3.7 Ограничение интенсивности трафика в зависимости от значения IP-npuopumema
В листинге 3.10 приведена соответствующая конфигурация высокоскоростного последовательного интерфейса маршрутизатора, подключенного к сети партнера.
= Листинг 3.10. Ограничение интенсивности трафика в зависимости ■ k /'от значения IP-приоритета .|
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 Мбит/с.
Практический пример 3.6: предоставление услуг с ограниченной интенсивностью трафика
Поставщик услуг предоставляет своему клиенту выделенный физический канал ТЗ, однако ограничивает его пропускную способность с целью уменьшения абонентской платы (к примеру, пропускная способность канала ТЗ может быть ограничена до 10, 20 или 30 Мбит/с). При желании со временем клиент может расширить пропускную способность. Интенсивность трафика предоставленного клиенту канала связи ограничивается до оговоренного обеими сторонами предела механизмом CAR (при этом, как правило, предусматривается возможность временного всплеска трафика). Следует отметить, что сетевой оператор может увеличить предоставляемую клиенту пропускную способность без необходимости внесения изменений в структуру сети на физическом уровне.
Для того чтобы ограничить интенсивность входящего трафика интерфейса ТЗ до уровня, оплачиваемого клиентом, поставщик услуг может сконфигурировать на этом интерфейсе оператор rate-limit. В листинге 3.11 приведена конфигурация, в соответствии с которой интенсивность входящего трафика ограничивается до 20 Мбит/с. Трафик, интенсивность которого превышает это значение, будет отброшен.
i Листинг 3.11. Предоставление услуг с ограниченной интенсивностью ;
[ "! ’ . У трафика 'г \.
interface HssiO/O/O
rate-limit input rate-limit 20000000 40000 40000
4>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
4>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 Interface — распределенный интерфейс передачи данных по волоконно-оптическим каналам). Расположенный выше по потоку поставщик услуг уровня 1 ограничивает интенсивность транзитного трафика ISP X и Y с помощью соответствующей конфигурации механизма CAR, позволяющей проводить ограничение трафика на основе МАС-адреса. Кроме того,
поставщик услуг уровня 1 хочет быть уверенным в том, что подключенные к коммутатору поставщики услуг' Internet, не состоящие с ним в отношениях соседства (поп-peer), не смогут передавать через него транзитный трафик (рис. 3.8).
Отбрасывание всего трафика, поступающего не от ISP X или Y ।Отбрасывание всего трафика, поступающего не от ISP X или Y ।Поставщик услуг уровня 1Поставщик услуг уровня 1Рис. 3.8. Ограничение трафика в точке обмена трафиком общего пользованияРис. 3.8. Ограничение трафика в точке обмена трафиком общего пользования
Отбрасывание всего трафика, поступающего не от ISP X или Y ।
Отбрасывание всего трафика, поступающего не от ISP X или Y ।
Поставщик услуг уровня 1
Поставщик услуг уровня 1
Рис. 3.8. Ограничение трафика в точке обмена трафиком общего пользования
Рис. 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
4>conform-action transmit exceed-action drop
rate-limit input access-group 100 4000000 40000 40000
4>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
МАС-адресами FDDl-интерфейсов маршрутизаторов поставщиков услуг Internet X и Y являются, соответственно, 0000.ОсЮ.7819 и 0000.0c89.6900.
Номера списков доступа, ограничивающих интенсивность трафика на основании значения МАС-адреса, находятся в диапазоне от 100 до 199. Список доступа с номером НО используется для ограничения интенсивности трафика, поступающего от поставщика услуг Internet X, до 30 Мбит/с. Аналогично, список доступа с номером 120 используется для ограничения интенсивности трафика, поступающего от поставщика услуг Internet Y, до 40 Мбит/с.
Последний оператор rate-limit предназначен для “захвата" и отбрасывания всего трафика, поступающего на FDDl-интерфейс поставщика услуг уровня 1 от не состоящих с ним в отношениях соседства 1SP.
Выравнивание трафика
Выравнивание трафика (traffic shaping — TS) представляет собой механизм сглаживания поступающего на интерфейс потока трафика с целью недопущения перегрузки канала и удовлетворения требований поставщика услуг. В соответствии с механизмом TS интенсивность пульсирующего трафика выравнивается до согласованной скорости передачи информации (C1R) путем постановки в очередь (буферизации) пакетов, интенсивность передачи которых превысила среднее значение. Буферизованные пакеты передаются по мере накопления достаточного числа маркеров. Передача поставленных в очередь пакетов планируется механизмом обслуживания очередей “первым пришел, первым обслужен” (first-in, first-out — FIFO) или взвешенным механизмом равномерного обслуживания очередей (Weighted Fair Queuing — WFQ). Операционная модель механизма выравнивания трафика схематически представлена на рис. 3.9.
Рис. 3.9. Операционная модель механизма выравнивания трафика
Механизм TS может быть сконфигурирован в адаптивном режиме на интерфейсе Frame Relay. В этом режиме механизм выравнивания трафика определяет доступную полосу пропускания на основании объединения значения поля BECN/FECN (Backward Explicit Congestion Notification — обратное явное уведомление о перегрузке; Forward Explicit Congestion Notification— прямое явное уведомление о перегрузке) и бита DE
(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Корзина пополняется маркерами,число которых равняется размерусогласованного всплвска (Вс), чврвзкаждый интервал времени Т = Bc/CIRИзбыточные маркеры отбрасываютсяИзбыточные маркеры отбрасываютсяРис. 3.10. Реализация алгоритма “корзина маркеров ” для механизма выравнивания трафикаРис. 3.10. Реализация алгоритма “корзина маркеров ” для механизма выравнивания трафикаРазмвр корзины ВС+ВЕРазмвр корзины ВС+ВЕЕсли для передачи пакета в корзиненашлось достаточное количествомаркеров, пакет передается, а размеркорзины уменьшается на равное размерупакета в байтах число маркеровЕсли для передачи пакета в корзиненашлось достаточное количествомаркеров, пакет передается, а размеркорзины уменьшается на равное размерупакета в байтах число маркеров
Корзина пополняется маркерами,число которых равняется размерусогласованного всплвска (Вс), чврвзкаждый интервал времени Т = Bc/CIR
Корзина пополняется маркерами,число которых равняется размерусогласованного всплвска (Вс), чврвзкаждый интервал времени Т = Bc/CIR
Избыточные маркеры отбрасываются
Избыточные маркеры отбрасываются
Рис. 3.10. Реализация алгоритма “корзина маркеров ” для механизма выравнивания трафика
Рис. 3.10. Реализация алгоритма “корзина маркеров ” для механизма выравнивания трафика
Размвр корзины ВС+ВЕ
Размвр корзины ВС+ВЕ
Если для передачи пакета в корзиненашлось достаточное количествомаркеров, пакет передается, а размеркорзины уменьшается на равное размерупакета в байтах число маркеров
Если для передачи пакета в корзиненашлось достаточное количествомаркеров, пакет передается, а размеркорзины уменьшается на равное размерупакета в байтах число маркеров
Механизм выравнивания трафика может быть применен к любому унифицированному интерфейсу с использованием одной из его двух реализаций — обобщенного ме-
ханизма выравнивания трафика (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. / /. Выравнивание интенсивности трафика до 256 Кбит/сРис. 3. / /. Выравнивание интенсивности трафика до 256 Кбит/с
Рис. 3. / /. Выравнивание интенсивности трафика до 256 Кбит/с
Рис. 3. / /. Выравнивание интенсивности трафика до 256 Кбит/с
Скорость доступа последовательного интерфейса маршрутизатора корпоративного клиента, подключенного к сети поставщику услуг, равна 256 Кбит/с. В следующих разделах этой главы рассматривается выравнивание трафика с помощью механизмов GTS и DTS.
Выравнивание трафика с помощью механизма GTS
В листингах 3.15-3.18 приведен пример конфигурации механизма GTS, использующегося для выравнивания средней интенсивности трафика до 256 Кбит/с, а также результаты выполнения некоторых важных show-команд, предназначенных для мониторинга процесса выравнивания трафика.
Листинг 3.15. Выравнивание средней интенсивности трафика\
.до 256 Кбит/с с помощью механизма GTS .. J
interface SerialO
traffic-shape rate 256000
Обратите внимание, что конфигурация механизма выравнивания трафика GTS предполагает указание значения только одного параметра — требуемой согласованной скорости доступа (C1R). Соответствующие значения обеспечиваемой скорости передачи пакетов и расширенного размера всплеска (ВЕ), приведенные в лист. 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
SeO256000 1984 7936793631992-
Команда show traffic-shape предназначена для вывода на экран конфигурации механизма выравнивания трафика и параметров корзины маркеров.
, Листинг 3.17. Статистика очереди механизма выравнивания трафика GTS
fshow 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
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-команды, предназначенной для мониторинга процесса выравнивания трафика.
Листинг 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 используется для установки согласованной скорости передачи (СJR) исходящего трафика (в данном примере 256000 бит/с) без возможности превышения интенсивности трафика на отдельно взятом интервале. Согласованный размер всплеска (Вс) равен 16384 бит. Следовательно, временной интервал равен 64 мс. Напомним, что в соответствии с командой shape average превышение интенсивности трафика на отдельно взятом интервале не допускается. Более того, увеличение размера всплеска невозможно даже в том случае, если в качестве третьего параметра команды shape average указано значение, отличное от 0. Для увеличения размера всплеска на отдельно взятом временном интервале до Вс + ВЕ бит с сохранением текущего значения CIR используется команда shape peak.
Листинг 3.20. Параметры механизма выравнивания трафика DTS\
;■ и статистика очереди
tshow 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.12. Выравнивание входящего и исходящего трафика узла А
Узел А подключен к маршрутизатору удаленного отдела продаж через интерфейс ethernetO. Последовательный интерфейс маршрутизатора 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 скон-
фигурировав для выравнивания интенсивности исходящего трафика до 128 Кбит/с на интерфейсе serial 0. Аналогичным образом, выравнивание интенсивности входящего трафика производится на интерфейсе ethernetO.
Выравнивание интенсивности входящего и исходящего трафика узла с помощью механизма DTS
В листинге 3.22 приведен пример конфигурации механизма DTS, использующегося для выравнивания интенсивности входящего и исходящего трафика узла А до 128 Кбит/с. Предположим, что последовательный интерфейс и Ethernet-интерфейс маршрутизатора, изображенного на рис. 3.12, являются интерфейсами SerialO/0/O и Ethernet 1/0/0, соответственно. Механизм формирования трафика DTS реализован только в маршрутизаторах Cisco серии 7500, построенных на базе интерфейсных плат VIР.
i Листинг 3.22. Выравнивание интенсивности трафика до 128 Кбит/с '
:с помощью механизма DTS .’ '
.... ... . - -_ .. V'z.
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
Практический пример 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).
в результате получения серии уведомлений BECN
Рис. 3.13. Адаптивный механизм выравнивания трафика, сконфигурированный на интерфейсе Frame Relay
Выравнивание интенсивности трафика с помощью механизма DTS’
В листинге 3.24 приведена конфигурация механизма DTS, использующегося для выравнивания исходящего трафика сайта электронной коммерции.
i Листинг 3.24. Выравнивание интенсивности трафика до 256 Кбит/с Sс помощью механизма DTS'i
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 Кбит/с.
Резюме
Пограничные формирователи трафика выполняют следующие функции качества обслуживания: классификация пакетов, маркировка пакетов и управление интенсивностью трафика.
Главной целью классификации пакетов, проводимой на границе сети, является создание предпосылки для дифференцированного обслуживания пакетов внутри сети. Классификация пакетов является необходимым условием для идентификации различных классов трафика в зависимости от требуемого уровня обслуживания. 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-пакетов путем установки значения поля IP-npuopumema ?
Маркировка входящих или исходящих по отношению к заданному маршрутизатору Telnet-пакетов путем установки значения поля IP-приоритета может быть осуществлена с помощью команды ip telnet tos. Например, с помощью команды ip telnet tos СО устанавливается IP-приоритет 6.
Интенсивность трафика ограничена до 1 Мбит/с. Возможно ли превышение интенсивности трафика при условии, что согласованная скорость передачи информации поддерживается на уровне 250 Кбит/с?
Превышение интенсивности трафика может случиться на очень короткий промежуток времени. В среднем же интенсивность трафика, анализируемого механизмом CAR, равна 250 Кбит/с.
Как подобрать правильное значение согласованного размера всплеска (BJ для механизма CAR?
Однозначного ответа не сушествует. Все зависит от типа потоков трафика и от уровня сглаживания всплесков.
Для IP- и ICMP-трафика параметры всплеска не играют большой роли, так как они фактически определяют всего лишь длину промежутка времени, в который интенсивность трафика будет превышать среднее значение. Поскольку со временем интенсивность трафика неизбежно ограничивается значением согласованной скорости передачи информации (CIR), выбор параметров всплеска IP- и ICMP-трафика не является критически важной задачей.
Что же касается протоколов передачи информации, использующих адаптивный механизм контроля интенсивности трафика (например, протокол TCP), то отбрасывание пакета может привести к превышению временного лимита таймера повторной передачи в устройстве-источнике и уменьшению размера его окна до 1. Несмотря на то что параметры всплеска TCP-потока разнятся в зависимости от реализации TCP в устройстве- источнике и устройстве-приемнике, ниже приведены рекомендации, касающиеся выбора оптимальных параметров всплеска механизма CAR:
согласованный размер всплеска = CIR х (1 байт + 8 бит) х 1.5 с, где CIR представляет собой согласованную скорость передачи информации;
расширенный размер всплеска = 2 х согласованный размер всплеска.
Насколько большое значение могут принимать счетчики трафика механизма CAR?
Механизм CAR использует 64-битовые счетчики трафика.
Каким образом механизм CAR накладывает штраф на потоки трафика, интенсивность которых постоянно превышает согласованный размер всплеска (В<)?
Когда происходит отбрасывание пакета, значение накопленного долга (Dc) обнуляется, а значение текущего долга (DA) остается без изменений. При передаче следующего пакета, требующего заимствования маркеров, новое значение накопленного долга (Dc) устанавливается равным текущему долгу (DA). Если передача потока трафика приводит к постоянному заимствованию маркеров, то значение текущего долга (DA) может очень скоро превысить максимально допустимое значение (в этом случае для отбрасывания пакета не потребовалось бы даже значения накопленного долга). Отбрасывание пакетов будет продолжаться до тех пор, пока значение текущего долга (DA) не уменьшиться до приемлемого уровня благодаря накоплению маркеров.
Может ли сетевой администратор настроить механизм ограничения трафика на активизацию только в определенный промежуток дня?
Да, для этого ему придется использовать списки доступа с временным критерием при конфигурации механизма CAR или модульного интерфейса командной строки QoS. Более подробно списки доступа протокола IP с временным критерием рассматриваются в документации компании Cisco.
Какое количество ресурсов процессора маршрутизатора отнимает механизм CAR?
Количество ресурсов процессора маршрутизатора, отнимаемое механизмом CAR, зависит от сложности критерия совпадения трафика и от глубины списка операторов rate-limit.
Критерий совпадения трафика, использующий сложный расширенный список доступа на основании IP-адреса, является более ресурсоемким по сравнению с критерием совпадения, использующим относительно простой список доступа. В целом же списки доступа на основании IP-приоритета и МАС-адреса требуют меньше процессорного времени, нежели списки доступа на основании IP-адреса.
Поскольку операторы ограничения интенсивности трафика обрабатываются последовательно, количество ресурсов процессора маршрутизатора линейно зависит от числа пройденных операторов rate-limit.
В этой главе...
Поддержка функций QoS со стороны механизмов обслуживания очередей90
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе вычисления порядкового номера пакета94
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе потока'98
Распределенный взвешенный алгоритм равномерного обслуживания очередей (DWFQ) на основе потока106
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе класса108
Приоритетное обслуживание очередей115
Заказное обслуживание очередей •■118
Механизмы обслуживания очередей, предназначенные для обработки голосового трафика123
ГлаваГлава44
Глава
Глава
4
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”, далее в этой книге.
Примечание
Закон сохранения из теории очередей гласит, что любая дисциплина обслуживания очередей может уменьшить среднюю задержку потока только за счет увеличения средней задержки другого потока.
Другими словами, время от времени задержка одних потоков трафика “обменивается” на предоставление определенной полосы пропускания для других потоков. В то время как один поток получает преференциальное обслуживание, другой поток неизбежно страдает от его недостатка.
Алгоритм обслуживания очередей FIFO
FIFO представляет собой механизм обслуживания очередей, в соответствии с которым порядок постановки пакетов в очередь совпадает с порядком их извлечения из очереди для обработки (передачи). Очередь механизма FIFO схематически представлена на рис. 4.1.
Очередь FIFO
3 213 21
Рис. 4.1. Очередь FIFO
Как уже говорилось ранее, в соответствии с механизмом обслуживания FIFO порядок постановки пакетов в очередь совпадает с порядком их извлечения из очереди. На сегодняшний день механизм FIFO является наиболее распространенным механизмом обслуживания очередей, применяющимся в маршрутизаторах. Его реализация отличается своей простотой. К сожалению, механизм FIFO не имеет средств дифференцирования потоков трафика и, следовательно, не может выделить приоритетные потоки. Более того, механизм FIFO не способен обеспечить равномерное обслуживание потоков трафика с одинаковым приоритетом и защитить их от подавления потоками с неравномерной интенсивностью. Последние могут отобрать часть ресурсов у потоков, имеющих постоянную интенсивность и обслуживающихся сквозными адаптивными схемами управления потоком, такими, как схема управления динамическим окном протокола TCP (Transmission Control Protocol — протокол управления передачей). Выясняется, что в соответствии с механизмом FIFO потоки трафика обслуживаются почти пропорционально их интенсивности. Подобная схема обслуживания очередей не является равномерной, поскольку она допускает преобладание потоков высокой интенсивности над всеми остальными потоками трафика. Любой же равномерный алгоритм обслуживания очередей обеспечивает защиту от потоков с высокой интенсивностью по своей природе.
Максиминная схема равномерного распределения ресурсов
Если механизм FIFO не обеспечивает равномерного распределения ресурсов между потоками, то какой же должна быть схема равномерного обслуживания очередей? Схемой равномерного распределения ресурсов, получившей широкое признание, является максиминная схема равномерного распределения ресурсов (max-min fair-share allocation scheme).
Как правило, разные пользователи предъявляют различные требования к ресурсам. Следовательно, существует возможность классификации пользователей в порядке возрастания их требований к ресурсам. Ниже дано определение максиминной схемы равномерного распределения ресурсов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) требования пользователей А и В удовлетворяются в полном объеме, так как они не превышают значения, полученного в результате равномерного распределения ресурсов между всеми пользователями.
* Keshav S. An Engineering Approach to Computer Networking. — Reading, MA: Addison-Wesley, 1997.
Поскольку требования к ресурсам пользователей С, 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 и Е
Представленный выше способ распределения ресурсов получил название максиминной схемы равномерного распределения ресурсов. Обратите внимание, что все пользователи с неудовлетворенными требованиями (т.е. с требованиями, объем которых превышает их максиминную равномерную долю) получают равные объемы ресурсов. Максиминная схема равномерного распределения ресурсов получила свое назва-
ние в связи с тем, что пользователь с неудовлетворенными требованиями получает максимум из возможных минимальных равномерных долей.
Максиминная схема равномерного распределения ресурсов, в которой каждому пользователю назначается определенный вес, получила название взвешенной максиминной схемы равномерного распределения ресурсов (weighted max-min fair-share allocation scheme). В соответствии co взвешенной максиминной схемой равномерного распределения ресурсов каждому пользователю выделяется равномерная доля ресурсов, пропорциональная его весу.
Обобщенная схема разделения процессорного времени
При обработке потоков трафика, передаваемого по методу негарантированной доставки (а также всех других равновесных классов трафика), должна применяться схема, обеспечивающая справедливое обслуживание по типу максиминной схемы равномерного распределения ресурсов. Именно такой схемой и является обобщенная схема разделения процессорного времени (Generalized Processor Sharing — GPS).
В соответствии со схемой GPS каждый поток трафика помешается в собственную логическую очередь, после чего бесконечно малый объем данных из каждой непустой очереди обслуживается по круговому принципу. Необходимость обработки бесконечно малого объема данных на каждом круге обусловлена требованием обслуживания всех непустых очередей на любом конечном временном интервале. Таким образом, схема GPS является справедливой в любой момент времени.
Если же всем потокам трафика назначить вес, то объем данных потока, обрабатываемый на каждом круге, будет пропорционален его весу. Подобное расширение схемы GPS фактически представляет собой взвешенную максиминную схему равномерного обслуживания.
Несмотря на то что GPS является идеальным воплощением максиминной схемы равномерного распределения ресурсов, подобная модель не может быть реализована на практике. Таким образом, к алгоритму обслуживания очередей, пригодному для практического использования, выдвигаются два требования: он должен быть как можно более близкой аппроксимацией схемы GPS и должен быть реализуемым на практике.
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе вычисления порядкового номера пакета
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) представляет собой аппроксимацию схемы GPS, поскольку он моделирует поведение планировщика GPS без нереализуемого на практике предположения о бесконечно малом объеме обрабатываемых данных. Взвешенный алгоритм равномерного обслуживания очередей на основе вычисления порядкового номера пакета имитирует работу GPS-сервера, обслуживающего в отдельный момент времени 1 байт данных. Алгоритм WFQ достаточно хорошо справляется с обработкой пакетов переменной длины, поскольку ему не нужно знать заранее средний размер пакета в потоке. Основой алгоритма WFQ явля-
ется алгоритм FQ, в соответствии с которым все потоки трафика рассматриваются как равные между собой — т.е. как потоки с одинаковым весом.
Алгоритм FQ моделирует схему GPS путем вычисления порядкового номера каждого полученного пакета. По существу, порядковый номер пакета представляет собой служебную метку, определяющую относительный порядок обработки пакетов. Порядок обслуживания пакетов на основе вычисления порядкового номера эмулирует порядок обслуживания пакетов планировщика GPS.
Для того чтобы интуитивно представить себе механизм моделирования схемы GPS, введем переменную и назовем ее счетчиком циклов (round number). Значение счетчика циклов определяет количество выполненных циклов побайтового планировщика кругового обслуживания в заданный момент времени. Отметим, что вычисление порядкового номера пакета зависит от счетчика циклов самым непосредственным образом.
С целью наглядной иллюстрации способа моделирования схемы GPS посредством алгоритма FQ рассмотрим три потока трафика, А, В и С, размеры пакетов которых составляют 128, 64 и 32 байт, соответственно. Пакеты поступают один за другим на загруженный FQ-сервер в порядке Al, А2, АЗ, В1, С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) в зависимости от его принадлежности активному или пассивному потоку трафика.
Для пакетов, принадлежащих пассивному потоку трафика,
порядковый номер = размер пакета в байтах + значение счетчика циклов на момент поступления пакета (значение счетчика циклов равняется порядковому номеру последнего обслуженного пакета).
Для пакетов, принадлежащих активному потоку трафика, порядковый номер = размер пакета в байтах + значение наибольшего порядкового номера пакета, поставленного в очередь этого потока.
Для более наглядной иллюстрации моделирования схемы GPS посредством алгоритма FQ на рис. 4.5 схематически представлены очереди пакетов с соответствующими им (пакетам) порядковыми номерами.
Счетчик циклов/порядковый номер пакетаСчетчик циклов/порядковый номер пакетаС1 В1 АЗ А2 А1С1 В1 АЗ А2 А1Счетчик циклов: 100Счетчик циклов: 100Планировщик FQПланировщик FQРис. 4.5. Пример моделирования побайтового GPS-планировщика кругового обслуживания посредством алгоритма FQРис. 4.5. Пример моделирования побайтового GPS-планировщика кругового обслуживания посредством алгоритма FQАЗ А2 А1 В1АЗ А2 А1 В1
Счетчик циклов/порядковый номер пакета
Счетчик циклов/порядковый номер пакета
С1 В1 АЗ А2 А1
С1 В1 АЗ А2 А1
Счетчик циклов: 100
Счетчик циклов: 100
Планировщик FQ
Планировщик FQ
Рис. 4.5. Пример моделирования побайтового GPS-планировщика кругового обслуживания посредством алгоритма FQ
Рис. 4.5. Пример моделирования побайтового GPS-планировщика кругового обслуживания посредством алгоритма FQ
АЗ А2 А1 В1
АЗ А2 А1 В1
GPS-планировщик завершит обслуживание пакета А1 на 228-м цикле. Напомним, что порядковый номер пакета определяет очередность обработки пакетов планировщиком. В данном случае планировщик FQ обслуживает пакеты в таком порядке: С1, Bl, Al, А2, АЗ.
Счетчик циклов используется исключительно для вычисления порядкового номера пакетов, принадлежащих новым (пассивным) потокам трафика. Порядковый номер пакетов, принадлежащих активным потокам трафика, рассчитываются с учетом наи-
большего порядкового номера пакета, поставленного в очередь этого потока. Таким образом, если пакет А4 будет принят до обслуживания пакета АЗ, то его порядковый номер будет равняться 484 + 128 = 612.
Следует отметить, что счетчик циклов обновляется при передаче каждого очередного пакета, при этом его новое значение равняется порядковому номеру пакета, который передается. Таким образом, если 32-байтовый пакет D1, принадлежащий новому потоку трафика, будет принят в момент передачи пакета А1, значение счетчика циклов будет равняться 228, а порядковый номер пакета D1 — 260 (228 + 32). Поскольку порядковый номер пакета D1 меньше порядковых номеров пакетов А2 и АЗ, он будет передан раньше этих пакетов. Изменение в порядке обслуживания пакетов схематически изображено на рис. 4.6.
Очередь А
АЗ (128)АЗ (128)А2(128)А2(128)
АЗ (128)
АЗ (128)
А2(128)
А2(128)
D1(32)D1(32)ОчередьDОчередьD-484500-484500“Г400“Г400356Г зоо356Г зоо:260:228J'—Г:260:228J'—Г200200“Гюо“Гюо
D1(32)
D1(32)
ОчередьD
ОчередьD
-484
500
-484
500
“Г400
“Г400
356
Г зоо
356
Г зоо
:260:228
J'—Г
:260:228
J'—Г
200
200
“Гюо
“Гюо
Счетчик циклов/порядковый номер пакета
D1 АЗ А2D1 АЗ А2„.Счетчик циклов: 228Очередь А„.Счетчик циклов: 228Очередь А► АЗ А2 D1► АЗ А2 D1
D1 АЗ А2
D1 АЗ А2
„.Счетчик циклов: 228
Очередь А
„.Счетчик циклов: 228
Очередь А
► АЗ А2 D1
► АЗ А2 D1
Планировщик FQ
Рис. 4.6. Изменение в порядке обслуживания пакетов, вызванное поступлением пакета D1 в момент передачи пакета А /
Довольно типичной является ситуация, в которой одни потоки трафика рассматриваются как более приоритетные по сравнению с другими. Естественно, что планировщик должен отдавать подобным потокам предпочтение перед другими, менее важными, потоками трафика. Этого можно достичь, назначив каждому потоку вес, про-
порционально которому и будет обслуживаться поток. Такое расширение алгоритма равномерного обслуживания очередей (FQ) получило название взвешенного алгоритма равномерного обслуживания очередей (WFQ) на основе потока.
Взвешенный алгоритм равномерного обслуживания очередей (WFQ) на основе потока
В соответствии с механизмом WFQ вес пакета определяется на основании значения поля IP-приоритета в заголовке пакета. Ниже приведена формула для расчета веса IP-пакета:■
вес = 4096 (JP-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)7 I0S версии 12.0(5)7
и выше
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
Вес 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(128)АЗ (128)А2 (128)А4(128)АЗ (128)А2 (128)Счетчик циклов: 100Очередь А (вес 683) 26237217494887524Счетчик циклов: 100Очередь А (вес 683) 26237217494887524262244" В1(64)262244" В1(64)С1В1АЗА2А1—►Очередь В (вес 4096)Очередь С (вес 4096)С1В1АЗА2А1—►Очередь В (вес 4096)Очередь С (вес 4096)—►АЗВ1А2С1А1—►АЗВ1А2С1А1131172 "сГ (32)131172 "сГ (32)
А4(128)
АЗ (128)
А2 (128)
А4(128)
АЗ (128)
А2 (128)
Счетчик циклов: 100
Очередь А (вес 683) 26237217494887524
Счетчик циклов: 100
Очередь А (вес 683) 26237217494887524
262244
" В1
(64)
262244
" В1
(64)
С1
В1
АЗ
А2
А1
—►
Очередь В (вес 4096)
Очередь С (вес 4096)
С1
В1
АЗ
А2
А1
—►
Очередь В (вес 4096)
Очередь С (вес 4096)
—►
АЗ
В1
А2
С1
А1
—►
АЗ
В1
А2
С1
А1
131172 "сГ (32)
131172 "сГ (32)
Рис. 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Рис. 4.8. Изменение в порядке обслуживания пакетов, вызванное поступлением пакетов Di и А 4
Рис. 4.8. Изменение в порядке обслуживания пакетов, вызванное поступлением пакетов Di и А 4
Рис. 4.8. Изменение в порядке обслуживания пакетов, вызванное поступлением пакетов Di и А 4
Пакет D1 был получен практически сразу же после обработки планировшиком WFQ пакета А1. Отметим, что пакет D1 будет передан перед пакетами АЗ и А4, которые были поставлены в очередь раньше.
Примечание
Порядковый номер пакета, поступившего на интерфейс, вычисляется только в случае перегрузки выходного интерфейса в результате переполнения буфера аппаратной
очереди. Если же выходной интерфейс не перегружен, применяется алгоритм обслуживания очередей 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 готов отбросить пакет
любого потока. Другими словами, алгоритм 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 Мбит/с.
Практический пример 4.1: взвешенный механизм равномерного обслуживания очередей (WFQ) на основе потока
Высокоприоритетный трафик время от времени испытывает задержку, вызванную передачей низкоприоритетного трафика, поскольку пакеты всех активных потоков выглядят одинаково в выходной очереди маршрутизатора, использующего алгоритм обслуживания очередей FIFO. С целью обеспечения дифференцирования пакетов на основе требований к обслуживанию сетевой администратор начинает устанавливать значение поля IP-приоритета входящих пакетов в зависимости от важности соответствующего потока трафика. Кроме этого, сетевой администратор конфигурирует взвешенный механизм равномерного обслуживания очередей (WFQ) на основе потока, в соответствии с которым:
активные потоки трафика с одинаковым IP-приоритетом получают равные доли полосы пропускания интерфейса;
активные потоки с большим IP-приоритетом получают большую долю полосы пропускания интерфейса, нежели активные потоки с меньшим IP-приоритетом.
После установки значения поля IP-приоритета для всего входящего трафика можно начинать конфигурирование взвешенного алгоритма равномерного обслуживания очередей (WFQ) на основе потока в маршрутизаторах сети. Классификация пакетов на основе установки значения поля IP-приоритета рассматривалась в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика”.
Конфигурация взвешенного алгоритма равномерного обслуживания очередей (WFQ) на основе потока осуществляется с помощью интерфейсной команды fairqueue. В листинге 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 отражает максимальный размер буфера для отдельного диалога.
Следует отметить, что значение параметра 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 ■ ■ ;
Routerfshow queueing fair
Current fair queue configuration:
InterfaceDiscardDynamicReserved
threshold queue count queue count SerialO642560
Практический пример 4.2: распределение полосы пропускания в зависимости от веса потока
На последовательном интерфейсе со сконфигурированным взвешенным алгоритмом равномерного обслуживания очередей (WFQ) на основе потока обрабатывается 8 потоков трафика — по одному на каждое значение IP-приоритета. Как изменится распределение полосы пропускания для каждого потока, если на последовательном интерфейсе будут об-
рабатываться 25 потоков трафика — 18 потоков с IP-приоритетом 1 и по одному потоку на каждое оставшееся значение IP-приоритета?
Как отмечалось ранее в этой главе, ширина полосы пропускания, выделенной потоку трафика, обратно пропорциональна его весу. В соответствии со взвешенным алгоритмом равномерного обслуживания очередей (WFQ) на основе потока вес потока рассчитывается по следующей формуле:
вес = 4096 4- (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 получает всего лишь l-i-(l+(2xl8) + 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 -^ 64) пакета голосового трафика.
Во втором случае голосовой трафик имеет 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) на основе потока использует для хранения пакетов отсортированный связанный список. Вновь прибывшие пакеты заносятся в этот список в соответствии с присвоенными им порядковыми номерами. Что касается распределенного алгоритма равномерного обслу-
живания очередей (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.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) на
основе потока, выполняющийся на центральном процессоре маршрутизатора, работающего под управлением операционной системы 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). Проведя анализ трафика, специалисты компании пришли к
выводу, что причиной перегрузки сети является чрезмерный объем 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 ''
Routerishow policy goldservice
Policy Map goldservice
Weighted Fair Queueing
Class gold
Bandwidth 500 (kbps) Max Thresh 64 (packets)
Листинг 4.6. Информация о классе трафика gold
Routerishow class gold
class Map gold
match access-group 101
Как и в практическом примере 4.1, вы можете выполнить команду show queueing fair для отображения параметров механизма WFQ и команду show queue serialO для получения статистики пакетов очереди.
Практический пример 4.6: выделение дополнительной полосы пропускания в зависимости от входного интерфейса
Сетевой инженер компании — поставщика услуг хочет выделить полосу пропускания шириной 30 Мбит/с на канале DS3 маршрутизатора Internet для трафика, поступающего на Fast Ethernet-интерфейс маршрутизатора 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,
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
Примечание
Хотя на момент написания этой книги определение выделенной классу трафика полосы пропускания как части от общей полосы пропускания канала было невозможно, вскоре подобная опция должна стать доступной.
Конфигурация механизма 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 HssiO/O/O
fair-queue
tos
fair-queue
tos
1 weight
15
fair-queue
tos
2 weight
30
fair-queue
tos
3 weight
40
Примечание
В реализации алгоритма DWFQ понятие веса (параметр weight) отличается от аналогичного понятия в реализации алгоритма WFQ на основе потока. В аспекте алгоритма DWFQ вес указывает на процент от общей полосы пропускания линии связи.
Следует отметить, что стандартный вес классов услуг ToS 1, 2 и 3 составляет 20, 30 и 40, соответственно. В рассматриваемом случае планируемый вес классов 2 и 3 совпадает с их стандартным весом и, следовательно, не нуждается в дополнительной конфигурации. Классу! назначается вес 15. В листинге 4.10 приведены параметры алгоритма DWFQ на основе класса услуг ToS и статистика обработки пакетов.
Листинг 4.10. Параметры алгоритма DWFQ на основе классов услуг ToS Iи статистика обработки пакетов
Routertfshow 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:weight15limit2986qsize0packetsoutput0drops0
Class 1:weight15limit2986qsize0packetsoutput0drops0
Class 2:weight30limit2986qsize0packetsoutput0drops0
Class 3:weight40limit2986qsize0packetsoutput0drops0
Параметр 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, построенных на базе интерфейсных платУ1Р, без использования модульного интерфейса командной строки QoS.
QoS-группа — это номер, присваиваемый пакету в случае удовлетворения какого- либо определенного пользователем критерия совпадения. Следует отметить, что QoS- группа представляет собой внутреннюю по отношению к маршрутизатору метку, т.е. не входит подобно полю IP-приоритета в структуру IP-пакета. Без использования модульного интерфейса командной строки QoS конфигурация механизма DWFQ на основе QoS-группы осуществляется посредством команды fair-queue qos-group.
Практический пример 4.8: выделение полосы пропускания в зависимости от QoS-группы без использования модульного интерфейса командной строки QoS
Поставщик услуг Internet планирует выделить на интерфейсе HSSI0/0/0 вчетверо большую полосу пропускания для трафика QoS-группы 3, нежели для трафика QoS- группы 0. Предположим, что перед поступлением в маршрутизатор пакеты классифицируются с помощью метки QoS-группы некоторым приложением. Кроме этого, предположим, что обработка трафика QoS-группы, отличной от 0 и 3, маршрутизатором поставщика услуг Internet не предусмотрена.
В листинге 4.11 приведен пример конфигурации механизма DWFQ на основе QoS- группы без использования модульного интерфейса командной строки QoS.
i Листинг 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
Приоритетное обслуживание очередей
Механизм приоритетного обслуживания очередей предполагает наличие четырех выходных подочередей — подочереди с высоким, средним, обычным и низким приоритетом обслуживания. Сетевой администратор может определить принадлежность потока трафика к любой из четырех очередей. Пакеты, принадлежащие очереди с высоким приоритетом обслуживания, передаются первыми. Когда высокоприоритетная очередь окажется пустой, начнется передача пакетов следующей по приоритету об-
служивания очереди и т.д. Отметим, что передача пакетов очереди со средним приоритетом обслуживания не начнется до тех пор, пока не будут обслужены все пакеты высокоприоритетной очереди.
Приоритетное обслуживание пакетов востребовано в сетях, где передача трафика, необходимого для решения критически важных задач, должна быть осуществлена даже при условии полного доминирования высокоприоритетного трафика в моменты перегрузки сети. Вполне возможно, что во время перегрузки сети для передачи трафика, необходимого для решения критически важных задач, будет выделено 100 процентов доступной полосы пропускания. Если интенсивность высокоприоритетного трафика сравняется на определенный промежуток времени с линейной интенсивностью или превысит ее, механизм приоритетного обслуживания очередей все равно обеспечит передачу высокоприоритетной информации до поступления ее следующей порции, даже если для этого придется пожертвовать управляющим трафиком сети.
Механизм приоритетного обслуживания очередей поддерживает классификацию пакетов в зависимости от входного интерфейса, простого или расширенного списка доступа на основании IP-адреса, размера пакета и сгенерировавшего этот пакет приложения.
Следует отметить, что неклассифицированный трафик по умолчанию относится к очереди с обычным приоритетом обслуживания. В пределах очереди пакеты обрабатываются в соответствии с механизмом FIFO.
Практический пример 4.9: обслуживание трафика на основании значения поля IP-приоритета
Сеть Internet-компании обслуживает трафик с IP-приоритетом 0, 1, 2 и 3 в зависимости от его важности. Чем важнее трафик, тем он получает более высокий приоритет обслуживания. Высокоприоритетный трафик имеет строгое предпочтение перед низкоприоритетным трафиком.
Значения IP-приоритета 4-7 зарезервированы для трафика приложений с более строгими требованиями к ресурсам и в настоящий момент не используются. Тем не менее если не поддерживаемое в данный момент значение IP-приоритета будет все- таки использовано, соответствующий трафик будет обрабатываться как трафик с IP- приоритетом 0.
Как упоминалось ранее, механизм приоритетного обслуживания очередей предусматривает наличие четырех выходных очередей, обрабатываемых строго в соответствии с их приоритетом. Очереди с высоким, средним, обычным и низким приоритетом обслуживания соответствует IP-приоритет 3, 2, 1 и 0. Конфигурация маршрутизатора Internet-компании приведена в листинге 4.13.
j Листинг 4.13. Обслуживание трафика на основании значения поля IP-приоритета.
interface SerialO
ip address 201.201.201.2 255.255.255.252 priority-group 1
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 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
1
1
1
1
1
Queue Args
low default
high protocoliplist103
medium protocoliplist102
normal protocoliplist101
low protocoliplist100
Листинг 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), передаваемого no линии связи глобальной сети (WAN), размер пакетов которого не превышает 100 байт. Руководство компании желает, чтобы маршрутизатор обрабатывал трафик с пакетами размером меньше 100 байт сразу же при его поступлении, не обращая при этом внимания на обслуживание остального трафика. Маршрутизатор может приступить к обработке остального трафика только при условии отсутствия в очереди трафика с пакетами размером менее 100 байт.
Соответствующая конфигурация механизма приоритетного обслуживания приведена в листинге 4.16.
Листинг 4.16. Приоритетное обслуживание пакетов на основе размера '
interface serial 0.
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-адреса источника.
; Листинг 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 со сложной конфигурацией.
В соответствии с заказным обслуживанием трафик может быть распределен по 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.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 х S31) = 1086 + 3492+ 1662 = 6240.
Шаг 6. Определите процентное соотношение числа пакетов, передаваемых за один сеанс обслуживания каждой очереди:
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
1
1
1
1
Queue Args
protocoliptcpport<протоколA>
protocoliptcpport<протоколB>
protocoliptcpport<протокопC>
1byte-count 2172
12byte-count 6693
13byte-count 2493
Листинг 4.20. Информация о стратегии обслуживания очередей интерфейса SerialO/0/З и статистика обработки пакетов
Router#show interface serial0/0/3
<верхняя часть листинга удалена>
Queueing strategy: custom-list 1
Output queues: (queue #: size/max/drops)
0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0
0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
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 классами.
Механизмы обслуживания очередей, предназначенные для обработки голосового трафика
Для того чтобы быть понятным для слушателя, голосовой трафик должен испытывать при передаче минимальную задержку и дрожание (вариацию задержки). Несмотря на то что механизм 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 до менее чем удовлетворительной. С целью уменьшения этой проблемы сетевой администратор может задать максимальную полосу пропускания для трафика, обслуживаемого посредством приоритетной очереди. Если интенсивность трафика превысит максимальное значение, весь избыточный трафик будет отброшен. Следует отметить, что подобный способ ограничения трафика является весьма грубым, ибо он учитывает
только выделенную для приоритетной очереди полосу пропускания, не обращая при этом внимания на сам голосовой вызов.
Сумма полос пропускания приоритетной и стандартных очередей механизма 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
Механизм WFQ на основе потока является стандартным механизмом обслуживания очередей, использующимся на последовательном интерфейсе маршрутизатора. Для того чтобы указать на необходимость использования механизма WFQ на основе потока на интерфейсе с полосой пропускания более 2 Мбит/с, следует применить команду fair-queue. В предыдущей конфигурации был указан весь диапазон портов голосового трафика (от 16384 до 32767), использующийся устройствами Cisco VoIP. Таким образом, команда ip rtp priority указывает на необходимость строгой приоритетной обработки всего голосового трафика. В соответствии с механизмом WFQ на основе потока приоритетной очереди назначается специальный вес 0.
i Листинг 4.22. Обработка голосового трафика интенсивностью ■
=до 640 Кбит/с с помощью очереди со строгим приоритетом ;
iв соответствии с механизмом 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 при этом будут
считаться приоритетными, а очереди 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 представляет собой модель реги-
страции, в соответствии с которой пассажиры всех классов — первого, бизнес- и эко- ном-класса — стоят в одной очереди. Другими словами, механизм обслуживания 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-диалогу соответствует собственный поток трафика и тип канального уровня. Следовательно, даже при условии присвоения всем пакетам ве-
са, аналогичного весу IP-пакета с приоритетом 0, механизм WFQ на основе потока обеспечивает равномерное обслуживание всех потоков не 1Р-трафика.
Я сконфигурировал механизм взвешенного равномерного обслуживания очередей (WFQ) для обработки поступающего на интерфейс трафика, однако действительное распределение полосы пропускания интерфейса отличается от теоретических значений. Почему?
Используйте команды show interface fair и show queueing fair для получения информации о глубине очереди и статистике отброшенных пакетов для каждого класса трафика. Подобным образом вы сможете оценить достаточность реальной нагрузки трафика для совпадения действительного и заданного распределения полосы пропускания интерфейса. Так, если нагрузка недостаточна для поддержания очередей всех классов трафика непустыми, то действительное распределение полосы пропускания будет неизбежно отличаться от теоретического. Это связано с тем, что алгоритм WFQ является экономичным алгоритмом, позволяющим потокам трафика занять всю доступную полосу пропускания интерфейса.
В этой главе...,.
Модифицированный взвешенный алгоритм кругового обслуживания (MWRR)131
Модифицированный алгоритм кругового обслуживания
с дефицитом (MDRR)140
Глава
5
РНВ-политика: распределение ресурсов (часть 2)
Наиболее подходящий алгоритм обслуживания очередей для заданного маршрутизатора зависит от используюшейся в нем (маршрутизаторе) архитектуры коммутации пакетов. К примеру, взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing — WFQ) является идеальным выбором для маршрутизаторов Cisco, построенных кна базе шинной архитектуры. В маршрутизаторах Cisco, использующих для коммутации . пакетов специализированную коммутационную матрицу, должен применяться алгоритм • обслуживания очередей, наилучшим образом согласующийся с этой архитектурой. В частности, в семействе коммутаторов Cisco Catalyst и в маршрутизаторах серии 8540 применя- k г ется модифицированный взвешенный -алгоритм кругового обслуживания (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) представляет собой расширение планировщика кругового обслуживания, в соответствии с которым каждому потоку трафика назначается свой вес. Алгоритм WRR обрабатывает поток трафика пропорционально его весу.
Наиболее оптимальным образом WRR-планировщик согласуется с механизмом комму. тации ATM (Asynchronous Transfer Mode — режим асинхронной передачи), в соответствии
с которым пакет представляется в виде ячеек, а алгоритм WRR используется для обработки очередей, состоящих из ячеек. По сути, WRR является механизмом кругового обслуживания на основе ячеек, в котором вес потока определяет число ячеек, обслуживаемых за один цикл. Следовательно, каждой очереди выделяется часть полосы пропускания интерфейса в соответствии с весом потока трафика, не зависящая от размера пакета.
При желании вместо обслуживания ячеек алгоритм WRR может использоваться для обслуживания пакетов. В этом случае за один цикл планировщик WRR должен будет обработать все ячейки пакета, несмотря на возможность занять вес очереди у будущих циклов. С целью поддержки пакетов переменного размера модифицированный взвешенный алгоритм кругового обслуживания (MWRR) использует счетчик дефицита, ассоциированный с каждой WRR-очередью. Это придает алгоритму MWRR некоторые свойства алгоритма кругового обслуживания с дефицитом (Deficit Round Robin — DRR), более подробное описание которого приводится в следующем разделе этой главы.
Перед началом обслуживания очередей значение соответствующего ей счетчика дефицита устанавливается равным весу очереди. Обработка пакета осуществляется только в том случае, если значение счетчика дефицита больше нуля. После обслуживания пакета, состоящего из п ячеек, значение счетчика дефицита уменьшается на п. Обработка пакетов проводится до тех пор, пока значение счетчика дефицита остается больше нуля. Затем планировшик переходит к обслуживанию следующей очереди. В каждом новом цикле значение счетчика дефицита очереди увеличивается на вес очереди. Следует отметить, что если значение счетчика дефицита все еще меньше нуля или равно нулю, обработка пакета не производится. После обслуживания пакета значение счетчика дефицита уменьшается на количество ячеек, из которых состоит этот пакет. Использование счетчика дефицита позволяет алгоритму MWRR легко справляться с обработкой пакетов переменного размера.
Эффективная ширина полосы пропускания очереди прямо пропорциональна ее весу и рассчитывается по следующей формуле:
эффективная ширина полосы пропускания = (вес очереди х ширина полосы пропускания интерфейса) + сумма весов всех активных очередей.
Пример работы алгоритма MWRR
Предположим, что алгоритм MWRR используется для обслуживания трех очередей, вес каждой из них приведен в табл. 5.1.
' Таблица 5.1. Вес очередей, обслуживаемых с помощью алгоритма MWRR '
ОчередьВес
2Г"
13
О2
Рис. 5.1. VVRR-очереди и соответствующие им значения счетчиков дефицита до начала обслуживания
Первой обслуживается очередь 0. При инициализации счетчика дефицита ему присваивается значение 2, равное весу очереди. Во главе очереди 0 стоит 4-ячеечный пакет. Следовательно, после обслуживания этого пакета значение счетчика дефицита станет равным 2 - 4 = -2. Поскольку значение счетчика дефицита отрицательно, очередь 0 не может быть обслужена до тех пор, пока значение счетчика дефицита не станет больше нуля (рис. 5.2).
Рис. 5.2. Состояние очередей алгоритма MWRR после первого цикла обслуживания очереди 0
Следующей обслуживается очередь 1. При инициализации счетчика дефицита ему присваивается значение 3. В результате обслуживания стоящего во главе очереди 1 3- ячеечного пакета значение счетчика дефицита становится равным 3-3 = 0. Поскольку значение счетчика дефицита равно нулю, планировщик алгоритма MWRR приступает к обработке следующей очереди (рис. 5.3).
Рис. 5.3. Состояние очередей алгоритма MVVRR после первого цикла обслуживания очереди 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).
Очередь
Счетчик дефицита
2
-1
1
0
0
0
Очередь 2Очередь 2Рис. 5.4. Состояние очередей алгоритма MWRR после первого цикла обслуживания очереди 2Рис. 5.4. Состояние очередей алгоритма MWRR после первого цикла обслуживания очереди 2Очередь 2Очередь 2Очередь 19 I 8Очередь 19 I 8Очередь ООчередь О
Очередь 2
Очередь 2
Рис. 5.4. Состояние очередей алгоритма MWRR после первого цикла обслуживания очереди 2
Рис. 5.4. Состояние очередей алгоритма MWRR после первого цикла обслуживания очереди 2
Очередь 2
Очередь 2
Очередь 1
9 I 8
Очередь 1
9 I 8
Очередь О
Очередь О
Рис. 5.5. Состояние очередей алгоритма MWRR по-сле второго цикла обслуживания очереди О
После первого цикла обслуживания значение счетчика дефицита очереди 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).
Очередь 2
Очередь
Счетчик дефицита
2
0
1
-1
0
0
Рис. 5.7. Состояние очередей алгоритма MWRR по-сле второго цикла обслуживания очереди 2
Очередь 2
Рис. 5.8. Состояние очередей алгоритма MWRR после третьего цикла обслуживания очереди О
Новое значение счетчика дефицита очереди 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.
■ Таблица 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. Стандартное распределение веса для
классов ToS 0-3 составляет 1, 2, 4 и 8, соответственно. Следовательно, классам ToS 0-3 будет выделено 1/15, 2/15, 4/15 и 8/15 частей эффективной полосы пропускания интерфейса.
LТаблица 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,'
i :предназначенная для обработки заданного трафика . . ,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), использующийся для
распределения ресурсов в маршрутизаторах Cisco серии 12000. В соответствии с DRR- планировшиком каждая очередь характеризуется связанным с ней квантовым значением (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.
Режим чередующегося приоритета позволяет снизить максимальную задержку обслуживания очереди 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.
[таблица 5.4. Вес и квантовые значения очередей, обслуживаемых |! с помощью алгоритма MDRR
Номер очереди
Вес
Квантовое значение = вес х MTU (MTU = 1500 байт)
Очередь 2
1
1500
Очередь 1
2
3000
Очередь 0
1
1500
Когда механизм 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
"500
Рис. 5.11. Состояние очередей и соответствующих им значений счетчиков дефицита после первого цикла обслуживания очереди 2
Поскольку обслуживание очереди 2 осуществляется в режиме чередующегося приоритета, MDRR-планировщик переходит к обработке другой очереди, номер которой выбирается в соответствии с круговым принципом. Предположим, что подошел черед обслуживания очереди 0. При инициализации счетчика дефицита ему присваивается значение 1500, равное квантовому значению очереди 0. В результате обслуживания 1500-байтового пакета значение счетчика дефицита уменьшается до 1500 - 1500 = 0. В соответствии с алгоритмом MDRR планировщик завершает обслуживание очере-
ди 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.
Очередь 2
Очередь 1
500
1500
500
1500
Очередь О
1500
1000
Очередь
Счетчик дефицита
2
0
1
0
0
0
Рис. 5.13. Состояние очередей и соответствующих им значений счетчиков дефицита после второго цикла обслуживания очереди 2
Очередь 2
Очередь
Счетчик дефицита
2
0
1
-500
0
0
Рис. 5.14. Состояние очередей и соответствующих им значенийсчетчиков дефицита после первого цикла обслуживания очереди 1
В результате обслуживания двух пакетов очереди 0 значение ее счетчика дефицита становится равным 1500 - 1000 - 1500 = -500. Поскольку очередь 0 становится пустой, соответствующее значение счетчика дефицита сбрасывается в нуль. Состояние очере-
дей и соответствующих им значений счетчи"ов дефицита после окончания обслуживания очереди 0 схематически представлено на рис. 5.15.
Очередь 2
Очередь 1 "500
Очередь 0
Очередь
Счетчик дефицита
2
0
1
-500
0
0
Рис. 5.15. Состояние очередей и соответствующих им значений счетчи-ков дефицита после второго цикла обслуживания очереди 0
На следующем шаге 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
используется коммутационная матрица размером 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 определяет пять классов трафика: “золотой”; “серебряный"; “бронзовый”; трафик, передающийся методом негарантированной доставки; голосовой трафик (требующий как можно более низкого уровня дрожания).
Сетевому администратору необходимо настроить параметры пяти очередей: четырех (03) — для трафика классов “золотой”, “серебряный”, “бронзовый", а также трафика, передаваемого методом негарантированной доставки, и одной — для голосового трафика.
В листинге 5.3 приведена конфигурация трех ОСЗ-интерфейсов PoS (Point-to-Point (PPP) over Synchronous Optical Network (SONET) — протокол двухточечного взаимодействия через синхронную оптическую сеть), относящихся к сегментам назначения 1-3.
[ Листинг 5.3. Определение классов трафика и назначение им соответст- { ' ' j вующих очередей с гарантированной минимальной полосой 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. Следует отметить, что голосовой трафик является чувствительным к уровню задержки, однако не столь требовательным к ширине полосы пропускания. Поэтому для его обработки требуется очередь с малой задержкой, характеризующаяся не слишком высокими требованиями к пропускной способности.
Сеть поставщика услуг предназначена для обслуживания трафика с приоритетом от О до 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
Routerishow cos
Interface Queue Cos Group
P01/Ocos-a
PO2/0cos-a
PO3/0cos-a
Rx SlotSlot Table
table-a
table-a
table-a
Slot Table Name - table-0
cos-a
cos-a
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, соответственно.
Ответы на часто задаваемые вопросы
Каким образом механизм обслуживания очередей влияет на распределение ресурсов?
Механизм обслуживания очередей планирует порядок обработки поставленных в очередь пакетов. Частота обработки пакетов заданного потока трафика и определяет выделенный этому потоку объем ресурсов (полосу пропускания).
Можно ли использовать механизмы MWRR и MDRR для обслуживания голосового трафика?
Да. Путем применения очереди со строгим приоритетом механизмы MWRR и MDRR могут быть сконфигурированы для обработки голосового трафика. Очередь со строгим приоритетом обеспечивает обслуживание с малой задержкой для трафика масштаба реального времени.
В чем состоит сходство алгоритмов MWRR и MDRR с алгоритмом WFQ?
Алгоритмы WFQ, MWRR и MDRR являются алгоритмами распределения ресурсов. Способ планирования очередей алгоритмов MWRR и MDRR похож на способ планирования очередей алгоритма WFQ, поскольку все три алгоритма моделируют обобщенную схему разделения процессорного времени (GPS). Более подробно схема GPS рассматривалась в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”.
W<Y>v; " * ' . '
В этой главе... Ч^'--*
Механизм медленного старта и предотвращение перегрузки154
Реакция TCP-трафика на применение политики “отбрасывания хвоста”155
RED — алгоритм превентивного управления очередью
с целью предотвращения перегрузки сети156
Взвешенный алгоритм произвольного раннего обнаружения (WRED) 160
Алгоритм WRED на основе потока164
Механизм явного уведомления о перегрузке (ECN)167
Механизм избирательного отбрасывания пакетов (SPD)168
Глава
6
РНВ-политика:
предотвращение перегрузки и политика отбрасывания
пакетов ;
Политика отбрасывания пакетов (packet drop policy) представляет собой алгоритм управления очередью, применяющийся для регулирования ее длины. Традиционный алгоритм обслуживания очередей* “первым пришел, первым обслужен” (fist-in, firstout — FIFO) использует достаточно простую политику “отбрасывания хвоста” (tail drop policy), в соответствии с которой любая попытка постановки пакета в полную очередь неминуемо завершится его отбрасыванием.
В настоящий момент основным транспортным протоколом Internet является протокол управления передачей (Transmission Control Protocol — TCP). В этой главе рассматриваются механизмы предотвращения перегрузки протокола TCP, а также реакция TCP-трафика на применение политики “отбрасывания хвоста”. Кроме того, мы познакомимся с алгоритмом активного управления очередью RED (Random Early Detection — алгоритм произвольного раннего обнаружения), позволяющим предотвратить перегрузку сети путем превентивного отбрасывания пакетов с целью уведомления о возможной перегрузке источников 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 представляет собой оценку доступной полосы пропускания данного ТСР- соединения. Пример работы алгоритма медленного старта и алгоритма предотвращения перегрузки схематически представлен на рис. 6.1.
1 — медленный старт
Размер2 — временной лимит теймера повторной передечи (RTT)
окна3 — предотвращение перегрузки/линейный рост размера окна
перегрузки
(cwnd)2Размер окна перегрузки получателя
Время
Рис. 6.1. Изменение размера ТСР-окиа в соответствии с алгоритмами медленного старта и предотвращения перегрузки
Когда потеря пакета вызвана не перегрузкой сети, ожидание превышения временного лимита повторной передачи пакета (RTT) может весьма негативным образом сказаться на производительности TCP-соединения, что особенно характерно для высокоскоростных сетей. Для того чтобы избежать подобного развития ситуации, протокол TCP использует алгоритм быстрой повторной передачи и алгоритм быстрого восстановления.
Реакция TCP-трафика на применение политики “отбрасывания хвоста”
Традиционная политика обработки пакетов, которые должны быть поставлены в очередь, достигшую своего максимального размера, заключается в их отбрасывании. Подобная “дискриминация” пакетов продолжается до тех пор, пока длина очереди не уменьшится за счет передачи уже находящихся в ней пакетов^ Алгоритм управления очередью, в соответствии с которым любая попытка постановки пакета в полную очередь неминуемо завершится его отбрасыванием, получил название алгоритма “отбрасывания хвоста ” (tail drop).
Поскольку отбрасывание пакета является сигналом о перегрузке сети для источника TCP-соединения, механизм “отбрасывания хвоста” сообщает о перегрузке сети лишь в момент фактического переполнения очереди. В результате отбрасывания пакета источник TCP-соединения уменьшает размер окна до одного сегмента и перезапускает алгоритм медленного старта, что приводит к резкому уменьшению исходящего ТСР-трафика.
Поскольку типичный магистральный маршрутизатор Internet или другой IP-сети большого размера в отдельный момент времени обрабатывает тысячи ТСР-потоков, применение алгоритма управления очередью “отбрасывание хвоста" может привести к
потере пакетов для очень большого числа TCP-соединений. Получив уведомления о перегрузке сети, множество TCP-источников практически одновременно уменьшат интенсивность передаваемого ими трафика, что приведет к резкому уменьшению размера очереди маршрутизатора.
Все TCP-источники, перезапустившие механизм медленного старта и сбросившие значение размера окна до одного сегмента, начнут экспоненциальное увеличение размеров окна, ведушее к росту интенсивности обрабатываемого очередью трафика. Монотонное увеличение интенсивности трафика приведет к переполнению очереди и отбрасыванию пакетов. Таким образом, алгоритм “отбрасывания хвоста” и во второй раз приведет к потере пакетов для очень большого числа TCP-соединений, а также к резкому уменьшению размеров очереди. По мере увеличения размеров TCP-окна всех источников, перезапустивших механизм медленного старта, интенсивность обрабатываемого очередью трафика будет расти, что вскорости приведет к уже известному сценарию развития событий.
Периодическое резкое снижение интенсивности трафика и перегрузка сети приводят к волноподобному изменению размера очереди, получившему название эффекта глобальной синхронизации (global synchronization). Эффект глобальной синхронизации схематически представлен на рис. 6.2.
1. В результате выполнения алгоритма "отбрасывания хвоста" одновременно достаточно большое число ТСР-источников сужают размер окна перегрузки до 1 и перезапускают механизм
Рис. 6.2. Эффект глобальной синхронизации
Эффект глобальной синхронизации обязан своим названием одновременному (синхронному) перезапуску алгоритмов медленного старта множества ТСР-источников, вызванного работой алгоритма “отбрасывания хвоста”. Помимо нежелательного изменения размеров очереди, этот эффект способен также привести к возрастанию дрожания задержки трафика и снижению пропускной способности всей сети.
RED — алгоритм превентивного управления очередью с целью предотвращения перегрузки сети
С поведением ТСР-источников в моменты работы алгоритма “отбрасывания хвоста” связана необходимость проведения превентивного управления очередью с целью
сигнализации о перегрузке сети до фактического переполнения очереди и контроля за размером очереди с целью снижения задержки обработки пакетов. Алгоритм произвольного раннего обнаружения (Random Early Detection — RED) представляет собой алгоритм предотвращения перегрузки, предложенный Салли Флойдом (Sally Floyd) и Ваном Якобсоном (Van Jacobson). Данный механизм активного управления очередью обладает существенными преимуществами по сравнению с традиционным механизмом “отбрасывания хвоста”.
Как уже упоминалось ранее, механизм RED использует превентивный подход к предотвращению перегрузки сети. Вместо ожидания фактического переполнения очереди, RED начинает отбрасывать пакеты с ненулевой вероятностью, когда средний размер очереди превысит определенное минимальное пороговое значение. Вероятностный подход к отбрасыванию пакетов позволяет быть уверенным в том, что механизм RED отбросит пакеты всего лишь нескольких произвольно выбранных потоков, тем самым помогая избежать эффекта глобальной синхронизации. Напомним, что отбрасывание пакета представляет собой сигнал TCP-источнику о необходимости уменьшить интенсивность передаваемого трафика для соответствующего потока, что достигается за счет перезапуска алгоритма медленного старта.
Если средний размер очереди будет продолжать увеличиваться несмотря на отбрасывание произвольных пакетов, то это приведет к линейному росту вероятности отбрасывания. В соответствии с механизмом RED вероятность отбрасывания пакетов растет прямо пропорционально увеличению среднего размера очереди от минимального до максимального порогового значения. Средний размер очереди строго ограничен максимальным пороговым значением, поскольку в этом случае вероятность отбрасывания пакетов достигает своего наибольшего значения (100 процентов). Другими словами, главная цель механизма произвольного раннего обнаружения (RED) заключается в минимизации среднего размера очереди, а значит, и обшей задержки трафика.
Определение вероятности отбрасывания пакета базируется на взвешенном экспоненциальном значении среднего размера очереди, вычисление которого более подробно рассматривается в разделе “Алгоритм вычисления среднего размера очереди” далее в этой главе. Это позволяет избежать предвзятого отношения механизма RED к характеризующимся кратковременными всплесками потокам трафика в условиях продолжительной перегрузки сети.
Если же средний размер очереди весьма невелик и находится ниже минимального порогового значения, механизм RED не способен обеспечить существенного преимущества по сравнению с традиционными механизмами управления очередью. С другой стороны, при затяжном периоде перегрузки сети поведение механизма RED, несмотря на длинную очередь и высокое максимальное пороговое значение, аналогично поведению классического механизма “отбрасывания хвоста”. Таким образом, основное предназначение механизма RED заключается в сглаживании временных всплесков трафика и предупреждении длительной перегрузки сети посредством уведомления источников трафика о необходимости снижения интенсивности передачи информации. Если источники проявят способность к взаимодействию и одновременно уменьшат интенсивность передаваемого трафика, это поможет предотвратить перегрузку сети.
В противном случае средний размер очереди достаточно скоро достигнет максимального порогового значения, что приведет к отбрасыванию всех поступающих пакетов.
Ниже перечислены некоторые из основных целей механизма раннего произвольного обнаружения.
Минимизация дрожания задержки пакетов путем контроля за средним размером очереди.
Предотвращение эффекта глобальной синхронизации ТСР-трафика.
Обеспечение непредвзятого обслуживания трафика, характеризующегося кратковременными всплесками.
Строгое ограничение максимального среднего размера очереди.
Фактически, механизм произвольного раннего обнаружения базируется на двух следующих алгоритмах.
Алгоритм вычисления среднего размера очереди. Определяет допустимый уровень всплеска трафика в очереди.
Алгоритм вычисления вероятности отбрасывания пакетов. Определяет вероятность (частоту) отбрасывания пакетов для заданного среднего размера очереди.
Более подробно каждый из названных выше алгоритмов рассматривается в двух следующих разделах этой главы.
Алгоритм вычисления среднего размера очереди
При определении вероятности отбрасывания пакетов механизм RED вычисляет не текущий, а экспоненциально взвешенный средний размер очереди. Текущий средний размер очереди определяется на основании предыдущего среднего и текущего действительного размера. Использование механизмом RED среднего размера очереди обусловлено стремлением реагировать только на продолжительную перегрузку сети и “не замечать” моментальных всплесков трафика. Средний размер очереди вычисляется по формуле:
средний_размер_очереди = (предыдущий_средний_размерх(1 - 1/2") +
+ (текущий_размер_очереди х 1/2"),
где п — это экспоненциальный весовой коэффициент, определяемый пользователем.
Экспоненциальный весовой коэффициент является ключевым параметром, который определяет относительный вклад предыдущего среднего и текущего размера очереди в новый средний размер очереди. Практика показала, что наиболее приемлемым значением экспоненциального весового коэффициента п является 9. Увеличение экспоненциального весового коэффициента приведет к доминированию предыдущего среднего размера очереди над ее текущим размером в аспекте вычисления нового среднего размера очереди. Напротив, уменьшение экспоненциального весового коэффициента приведет к возрастанию значимости текущего размера очереди при вычислении ее нового среднего размера.
Большое значение коэффициента п обуславливает математическую близость нового и предыдущего среднего размера очереди, а также позволяет механизму RED более сдержанно реагировать на моментальные изменения в ее текущем размере, что выражается в следующем поведении.
Значение среднего размера очереди изменяется медленно, для него крайне нехарактерны резкие скачки.
Механизм RED достаточно сдержанно относится к временным всплескам трафика, стараясь выровнять текущий размер очереди.
Механизм RED не спешит иници ровать процесс отбрасывания пакетов, который, тем не менее, может продолжаться некоторое время после снижения действительного размера очереди ниже минимального порогового значения.
Если значение коэффициента п слишком велико, механизм RED может и вовсе перестать реагировать на перегрузку сети, поскольку в этом случае текущий размер очереди практически не будет влиять на вычисление ее среднего размера. Пакеты будут передаваться или отбрасываться так, как если бы механизм RED и вовсе не использовался.
Напротив, маленькое значение коэффициента п обуславливает математическую близость нового среднего и текущего размера очереди, что выражается в следующем поведении механизма RED.
Средний размер очереди изменяется очень быстро, для него характерна сильная зависимость от флуктуаций потока трафика.
Механизм RED немедленно реагирует на длинную очередь, однако как только ее размер оказывается ниже минимального порогового значения, отбрасывание пакетов прекращается.
Если значение коэффициента п слишком мало, механизм RED начинает очень остро реагировать на временные всплески трафика, что выражается в неоправданном отбрасывании пакетов.
Алгоритм вычисления вероятности отбрасывания пакетов
Вероятность отбрасывания пакетов представляет собой функцию, линейно зависящую от среднего размера очереди. Помимо этого, данная функция зависит также от минимального порогового значения, максимального порогового значения и знаменателя граничной вероятности (mark probability denominator), определяющего часть отбрасываемых пакетов при достижении средним размером очереди максимального порогового значения. Например, если знаменатель граничной вероятности равен 10, то при достижении средним размером очереди максимального порогового значения механизм RED будет отбрасывать 1 из 10 пакетов. Ниже приведена формула, по которой рассчитывается вероятность отбрасывания пакетов.
Вероятность отбрасывания пакетов = ((средний размер очереди - минимальное пороговое значение) / (максимальное пороговое значение - минимальное пороговое значение)) / знаменатель граничной вероятности.
Когда средний размер очереди превышает минимальное пороговое значение, механизм RED начинает отбрасывать пакеты. Интенсивность отбрасывания пакетов возрастает прямо пропорционально возрастанию среднего размера очереди до тех пор, пока он не достигнет максимального порогового значения.
Когда средний размер очереди превышает максимальное пороговое значение, механизм RED отбрасывает все пакеты, предназначенные для постановки в очередь. График вероятности отбрасывания пакетов схематически представлен на рис. 6.3.
Вероятность отбрасывания пакетовВероятность отбрасывания пакетовпороговоепороговоепороговоепороговоезначениезначениезначениезначениеСредний размер очередиРис. 6.3. График вероятности отбрасывания пакетов механизмом REDСредний размер очередиРис. 6.3. График вероятности отбрасывания пакетов механизмом RED
Вероятность отбрасывания пакетов
Вероятность отбрасывания пакетов
пороговое
пороговое
пороговое
пороговое
значение
значение
значение
значение
Средний размер очереди
Рис. 6.3. График вероятности отбрасывания пакетов механизмом RED
Средний размер очереди
Рис. 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-
приоритета. После определения 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 на центральном ' .процессоре низкопроизводительного маршрутизатора Cisco i
■ серии 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: classrandomtailmin-thmax-thmark-prob
01378317497220401/10
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 выполняется на центральном процессоре маршрутизатора, то он применяется к выходной очереди интерфейса, а пороговые значения определяются следующим образом.
Минимальное пороговое значение для трафика с приоритетом L Минимальное пороговое значение для трафика с приоритетом 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 RandomTail Minimum Maximum MarkOutput
dropdrop threshold threshold probability Packets
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 Forwarding — CEE) для распространения конфигурационных параметров и статистической информации между процессорами RSP (Route/Switch Processor — процессор маршрутизации и коммутации) и интерфейсными платами VIP. (Более подробно метод скоростной коммутации пакетов Cisco рассматривается в приложении Б, “Механизмы коммутации пакетов".) Из этого следует, что выполнение механизма WRED в распределенном режиме требует активизации режима коммутации СЕР. Статистика отбрасывания пакетов для заданного интерфейса включает в себя статистику пакетов, отброшенных распределенным механизмом 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.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 Hssi0/0/0
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, соответственно. Посредством команды servicepolicy output wred политика обслуживания пакетов wred применяется к высокоскоростному последовательному интерфейсу HssiO/0/O.
Алгоритм WRED на основе потока
Сигнал о перегрузке сети воспринимается должным образом только адаптивными потоками TCP-трафика, в то время как не обладающий способностью к адаптации UDP-трафик не реагирует на уведомление о перегрузке и не снижает свою интенсивность. Учитывая такое поведение UDP-трафика, несложно представить себе ситуацию, в которой во время перегрузки сети неадаптивные потоки передают данные с намного большей интенсивностью, чем потоки, обладающие способностью к адаптации. Следовательно, на неадаптивные потоки трафика приходится львиная доля ресурсов по сравнению с потоками, снижающими свою интенсивность в ответ на получение сигнала о перегрузке. Алгоритм WRED на основе потока (flow WRED) представляет собой модификацию алгоритма WRED, предусматривающую штрафование потоков, отнимающих чрезмерную долю ресурсов.
С целью обеспечения равномерного обслуживания активных потоков трафика механизм WRED классифицирует все устанавливаемые в очередь пакеты в зависимости от их приоритета и потока трафика, к которому они относятся. Кроме этого, WRED поддерживает информацию о состоянии всех активных потоков (active flows), т.е. потоков, хотя бы один пакет которых поставлен на обработку в какую-либо из очередей.
Информация о состоянии активных потоков используется для определения справедливой доли выделенных потоку ресурсов очереди (размер очереди/количество активных потоков), а также для выявления и штрафования потоков, отнимающих чрезмерно большой объем ресурсов.
Чтобы механизм WRED более адекватно реагировал на всплески потоков трафика, вы можете увеличить справедливую долю ресурсов каждого потока путем применения так называемого коэффициента масштабирования (см. приведенные ниже формулы).
Справедливая доля ресурсов, выделяемая активному потоку трафика = размер очереди + количество активных потоков.
Справедливая доля ресурсов, выделяемая активному потоку трафика, с учетом коэффициента масштабирования = (размер очереди + количество активных потоков) х коэффициент масштабирования.
Поток, требования которого превышают справедливую долю ресурсов с учетом коэффициента масштабирования, штрафуется путем увеличения ненулевой вероятности отбрасывания для всех вновь пришедших пакетов.
В качестве примера рассмотрим действия, предпринимаемые механизмом WRED на основе потока в отношении только что поставленного в очередь пакета. При определении вероятности отбрасывания пакета механизм WRED на основе потока учитывает как значение поля IP-приоритета пакета, так и информацию о состоянии активных потоков. От IP- приоритета пакета зависят сконфигурированные (либо стандартные) минимальное и максимальное пороговые значения. Если средний размер очереди ниже минимального порогового значения, то вероятность отбрасывания пакета устанавливается равной нулю (другими словами, этот пакет не будет отброшен). Если же средний размер очереди находится между минимальным и максимальным пороговым значением, то в расчет принимается информация о состоянии активных потоков трафика. Так, если пакет принадлежит потоку, превысившему справедливую долю ресурсов с учетом коэффициента масштабирования, механизм WRED увеличивает вероятность отбрасывания этого пакета путем уменьшения соответствующего максимального порогового значения, как показано ниже.
Новое максимальное пороговое значение = минимальное пороговое значение +
+ ((максимальное пороговое значение - минимальное пороговое значение) ■* 2).
Ненулевая вероятность отбрасывания пакета рассчитывается на основании минимального и нового максимального порогового значения. Поскольку результатом снижения максимального порогового значения является существенное увеличение угла наклона кривой вероятности отбрасывания (рис. 6.4), шансы пакета быть отброшенным резко возрастают.
Если же поток трафика не превышает справедливой доли ресурсов с учетом коэффициента масштабирования, то ненулевая вероятность отбрасывания пакета рассчитывается по стандартному методу.
Когда средний размер очереди превышает максимальное пороговое значение, механизм WRED на основе потока отбрасывает все пакеты, предназначенные для постановки в очередь.
Следует отметить, что механизм WRED на основе потока увеличивает вероятность отбрасывания пакетов только для тех потоков трафика, чьи требования превысили справедливую долю ресурсов с учетом коэффициента масштабирования. Во всем остальном поведение механизма WRED на основе потока аналогично поведению стандартного механизма WRED.
Результет работы механизма WREDРезультет работы механизма WREDРезультат работы маханизма WREDРезультат работы маханизма WREDна основе потокана основе потокав случве превышенияв случае непревышенияпоследним справедливойпоследним справедливойна основе потокана основе потокав случве превышенияв случае непревышенияпоследним справедливойпоследним справедливойдоли ресурсов с учетомдоли ресурсов с учетомдоли ресурсов с учетомдоли ресурсов с учетомМинимельное пороговое значение (определено на основе IP-приоритета пакета)Минимельное пороговое значение (определено на основе IP-приоритета пакета)Максимальное пороговое значение (определено на основе IP-приоритета пакета, однако впоследствии изменено ввиду излишней "прожорливости" потока)Максимальное пороговое значение (определено на основе IP-приоритета пакета, однако впоследствии изменено ввиду излишней "прожорливости" потока)Максимальное пороговое значение (определено на основении IP-приоритета пакета)Максимальное пороговое значение (определено на основении IP-приоритета пакета)
Результет работы механизма WRED
Результет работы механизма WRED
Результат работы маханизма WRED
Результат работы маханизма WRED
на основе потокана основе потока
в случве превышенияв случае непревышения
последним справедливойпоследним справедливой
на основе потокана основе потока
в случве превышенияв случае непревышения
последним справедливойпоследним справедливой
доли ресурсов с учетомдоли ресурсов с учетом
доли ресурсов с учетомдоли ресурсов с учетом
Минимельное пороговое значение (определено на основе IP-приоритета пакета)
Минимельное пороговое значение (определено на основе IP-приоритета пакета)
Максимальное пороговое значение (определено на основе IP-приоритета пакета, однако впоследствии изменено ввиду излишней "прожорливости" потока)
Максимальное пороговое значение (определено на основе IP-приоритета пакета, однако впоследствии изменено ввиду излишней "прожорливости" потока)
Максимальное пороговое значение (определено на основении IP-приоритета пакета)
Максимальное пороговое значение (определено на основении IP-приоритета пакета)
Средний размер очереди
Рис. 6.4. График вероятности отбрасывания пакета при использовании механизма WRED
Примечание
Как уже было сказано выше, механизм WRED на основе потока устанавливает ненулевую вероятность отбрасывания пакетов при нахождении среднего размера очереди между минимальным и максимальным пороговыми значениями даже для тех потоков, которые характеризуются всего лишь несколькими поставленными в очередь пакетами. Вы можете сконфигурировать механизм WRED на основе потока таким образом, чтобы он не отбрасывал пакеты подобных потоков трафика (указав при этом, какое именно число поставленных в очередь пакетов все еще является “спасительным” для потока) путем установки минимального порогового значения, близкого к максимальному пороговому значению. При этом когда средний размер очереди достигнет максимального порогового значения, вы можете применить механизм “отбрасывания хвоста”.
Практический пример 6.3: предотвращение перегрузки для неадаптивных потоков трафика
С целью предотвращения перегрузки сети и контроля за средним размером очереди сетевой инженер хочет сконфигурировать механизм WRED на основе потока на маршрутизаторе, обрабатывающем существенный объем UDP- и TCP-трафика. Пред-
полагается, что трафик, поступающий на обработку в маршрутизатор, характеризуется частыми всплесками.
В листинге 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-depthfactor 6. Воспользовавшись командой random-detect flow count, вы можете установить любое значение счетчика потоков в диапазоне от 0 до 215.
Команда show queueing random-detect используется для получения информации об использующейся на интерфейсе стратегии управления очередью.
Механизм явного уведомления о перегрузке (ECN)
До сих пор при активном управлении очередью с использованием механизма WRED пакеты отбрасывались с целью сообщения источникам TCP-соединения о перегрузке сети. Вместо отбрасывания пакета механизм явного уведомления о перегрузке (Explicit Congestion Notification — ECN) использует соответствующую маркировку заголовка пакета. И если раньше для того чтобы сообщить о перегрузке сети, WRED- мар шрутизатору приходилось отбрасывать пакет, вызывая тем самым задержку в доставке данных вследствие повторной передачи, то теперь маршрутизатору требуется всего лишь установить специальный ECN-бит в заголовке пакета.
Реализация механизма ECN требует поддержки СЕ-бита (Congestion Experienced — “обнаружена перегрузка”) в заголовке IP-пакета и наличие транспортного протокола, должным образом интерпретирующего СЕ-бит. С этой целью в заголовке IP-пакета выделяется специальное ECN-поле длиной 2 бит. Установка источником ТСР- соединения бита ЕСТ (ECN-Capable Transport— транспортировка данных с поддержкой поля ECN) указывает на способность конечных точек транспортного протокола к интерпретации поля ECN. Бит СЕ устанавливается маршрутизатором с целью уведомления конечных узлов соединения о перегрузке сети.
Шестой и седьмой биты байта типа обслуживания (Type of Service — ToS) заголовка IPv4 формируют поле ECN и являются битами ЕСТ и СЕ, соответственно. Следует отметить, что в аспекте архитектуры дифференцированных услуг биты 6 и 7 байта ToS не используются.
Механизм ECN выдвигает три новых требования к протоколу TCP.
Наличие средства уведомления конечных точек TCP-соединения о поддержке поля ECN. Конечные точки TCP-соединения должны обладать средством уведомления друг друга о поддержке поля 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).
Обычный IP-трафик (например, пакеты приложений telnet или ping), IP-пакеты с альтернативами, а также любое расширение или инкапсуляция IP, не поддерживаемая механизмом СЕР.
Пакеты, которые должны быть отброшены. Сюда относятся 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.5. Режимы функционирования механизма SPD
Практический пример 6.4: предотвращение атаки злоумышленника, использующего некорректные IP-пакеты, с помощью механизма SPD
Предположим, что сеть подвергается атаке злоумышленника, использующего IP- пакеты с истекшим “сроком жизни” (некорректным значением поля TTL). Получение большого количества некорректных IP-пакетов крайне неблагоприятно сказывается на работоспособности маршрутизатора, вынужденного обрабатывать эти пакеты посредством механизма коммутации процессов (получение пакета с истекшим “сроком жизни” приводит к генерированию соответствующего ICMP-пакета). С целью отбрасывания некорректных пакетов, в том случае, когда их количество превышает заданное минимальное пороговое значение, сетевой инженер должен активизировать на маршрутизаторе механизм SPD, функционирующий в режиме активного отбрасывания пакетов. В этом практическом примере рассматривается функционирование механизма SPD посредством использования различных show-команд.
Активизация механизма SPD производится с помощью команды ip spd. Следует отметить, что при использовании операционной системы IOS версии 12.0 или выше механизм SPD активизируется по умолчанию. В листинге 6.5 приведена информация о параметрах механизма SPD и режиме его функционирования.
( Листинг 6.5. Параметры механизма SPD и информация о режиме . j' \ \ его ФУИкЦиониР06^^^
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.
Команда show ip spd используется для вывода на экран информации о режиме функционирования механизма SPD, минимальном и максимальном пороговых значениях, а также о размере приоритетной очереди и очереди IP-процесса. Минимальный и максимальный пороговые размеры входной очереди механизма SPD являются настраиваемыми параметрами.
Размеры обычной очереди IP-процесса и приоритетной очереди измеряются на момент выполнения команды show ip spd. Поскольку длина обычной очереди равна 20, что ниже минимального порогового значения, равного 73, механизм SPD функционирует в нормальном режиме.
Как упоминалось ранее, для обработки важного IP-трафика в момент переполнения входной очереди IP-процесса используется так называемая приоритетная очередь (IP priority 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
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
13568
SP
0
Drops
RP
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— взвешенный алгоритм произвольного раннего обнаружения), How WRED (How Weighted Random Early Detection — взвешенный алгоритм произвольного раннего обнаружения на основе потока) и ECN (Explicit Congestion Notification —алгоритм явного уведомления о перегрузке).
RED представляет собой алгоритм активного управления очередью, позволяющий маршрутизатору обнаружить перегрузку сети еше до фактического переполнения оче-
реди. Целью алгоритма RED является уменьшение среднего размера очереди и, как следствие этого, сокращение задержки передачи пакетов и предотвращение эффекта глобальной синхронизации. Работа алгоритма RED основана на применении вероятностной стратегии отбрасывания пакетов в случае нахождения среднего размера очереди в диапазоне между заданными пороговыми значениями. Взвешенный алгоритм RED (WRED) позволяет настраивать различные параметры RED в зависимости от приоритета трафика.
Алгоритм WRED на основе потока представляет собой расширение алгоритма WRED, призванное обеспечить равномерное применение политики отбрасывания по отношению к пакетам, принадлежащим одному и тому же потоку трафика. Целью алгоритма ECN является уведомление источников трафика о зарождающейся перегрузке сети путем маркировки пакетов (а не их отбрасывания).
В этой главе был рассмотрен также алгоритм избирательного отбрасывания пакетов (Selective Packet Discard — SPD), использующийся для управления входной очередью IP-процесса маршрутизатора Cisco. Алгоритм SPD применяется для обеспечения дифференцированного обслуживания пакетов управляющего трафика, обрабатывающихся посредством механизма коммутации процессов маршрутизатора Cisco.
Ответы на часто задаваемые вопросы
Существуют ли какие-то эмпирические правила подбора параметров механизма RED?
Ниже приведена формула для расчета экспоненциального весового коэффициента.
Экспоненциальный весовой коэффициент = 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.
! Таблица 6.1. Рекомендованные значения параметров механизма RED для >
Скорость передачи информации по линии связи
различных линий связиJ
Экспоненциальный весовой коэффициент
Минимальное пороговое значение
Максимальное пороговое значение
Знаменатель граничной вероятности
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-пакетов (например, пакетов с истекшим “сроком жизни”), направленных на вывод маршрутизатора из строя.
В этой главе...
Протокол RSVP177
Стили резервирования182
Типы услуг185
Среда передачи и протокол RSVP186
Масштабируемость протокола RSVP186
Глава
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, “РНВ-политика: распределение ресурсов (часть!)”, 5, “РНВ- политика: распределение ресурсов (часть 2)”, и 6, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов”.
В этой главе обсуждается протокол RSVP, его управляющие сообщения, функционирование и пр. Кроме того, также описываются два типа интегрированных служб — управляемая нагрузка и гарантированная услуга.
Диспетчер полосы пропускания подсети (Subnet Bandwidth Manager — SBM) — это версия протокола RSVP и его расширений для канального уровня, поддерживающая управление трафиком в сетях на основе многопротокольной коммутации меток (Multiprotocol Label Switching — MPLS). Диспетчер SBM и управление трафиком в сетях MPLS описываются в главе 8, “Качество обслуживания на уровне 2: межсетевой обмен с IP QoS", и главе 10, “Управление трафиком в сетях MPLS", соответственно.
Протокол RSVP
Рабочая группа IETF определила RSVP как сигнальный протокол для архитектуры intserv. Этот протокол позволяет приложениям посыпать сигналы в сеть о своих QoS-
требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.
Протокол 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
Перед тем как зарезервировать ресурсы, RSVP-демон маршрутизатора соединяется с двумя локальными модулями принятия решения — модулем управления доступом (admission control) и модулем управления политикой (policy control)1. Модуль управления доступом определяет, имеет ли узел достаточно свободных ресурсов для обеспечения запрошенного уровня 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-сообщения передавались по новому пути.
Процесс установки резервирования можно разбить на пять отдельных шагов.
Отправители данных посылают управляющие сообщения RSVP PATH по тому же пути, по которому они отправляют обычный трафик с данными. В этих сообщениях описываются данные, которые уже отправляются или только будут отправляться.
Каждый RSVP-маршрутизатор перехватывает РАТН-сообщения, сохраняет IP- адрес предыдущей точки назначения, записывает вместо него свой собственный адрес и отправляет обновленное сообщение дальше по тому же пути, по которому передаются данные приложения.
Станции-получатели выбирают подмножество сеансов, для которых они получили РАТН-информацию и с помощью RSVP RESV-сообщения запрашивают RSVP-резервирование ресурсов у предыдущего маршрутизатора. RSVP RESV- сообщения идут от получателя к отправителю в противоположном направлении по маршруту, пройденному RSVP РАТН-сообщениями.
RSVP-маршрутизаторы определяют, могут ли они удовлетворить эти RESV- запросы. Если нет, они отказывают в резервировании. Если да, то они объединяют полученные запросы на резервирование и отсылают запрос предыдущему маршрутизатору.
Отправители, получив запросы на резервирование ресурсов от соответствующих маршрутизаторов, считают резервирование ресурсов состоявшимся. Обратите внимание, что реальное резервирование ресурсов осуществляется RESV-сообщениями.
Механизм RSVP-резервирования схематически показан на рис. 7.2.
Рис. 7.2. Механизм RSVP-резервирования ресурсов
Как уже обсуждалось в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика”, пакеты, идущие от приложения на машине-источнике к приложению на машине- получателе, формируют отдельный поток. С целью управления доступом требования потока представляются в виде параметров объекта HowSpec.
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-сети.
Средняя скорость передачи данных.
Максимальный размер всплеска.
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, содержащие адрес источника отправителя, посылаются многоадресной группе в случае необходимости удаления пути из базы
данных, при выходе из строя канала или если отправитель покидает многоадресную группу.
Ниже перечислены типы сообщений получателя.
Получатели периодически отправляют 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 —
FF). Символически запрос на резервирование в стиле FF можно представить как FF(S,Q), где S — это отправитель, a Q — объект FlowSpec.
Самый простой случай индивидуального резервирования ресурсов наблюдается на примере приложения с одноадресным трафиком, где есть только один отправитель и один получатель.
Общее резервирование
Общее резервирование (shared reservations) применяется в тех приложениях, в которых несколько источников данных не склонно передавать информацию одновременно, например цифровые аудиоприложения, такие, как приложения VoIP. В этом случае, поскольку в любой отдельно взятый промежуток времени разговор ведет небольшое число людей, информация передается лишь небольшим ограниченным количеством отправителей. Такой поток не нуждается в отдельном резервировании ресурсов для каждого отправителя, для него необходимо всего лишь одно резервирование, которое при необходимости можно будет применить к любому отправителю в группе.
В терминах протокола RSVP такой поток называется общим потоком (shared flow); он устанавливается с помощью общего явного или группового резервирования. Указанные стили резервирования рассматриваются ниже.
При общем явном (Shared Explicit — SE) резервировании потоки, которые резервируют сетевые ресурсы, указываются отдельно.
Символически запрос на резервирование в стиле SE можно представить как SE((S1,S2){Q}), где SI, S2, ... — отдельные отправители, требующие резервирования ресурсов, a Q — объект FlowSpec.
С помощью группового фильтра (Wildcard Filter — WF) полоса пропускания и характеристики задержки могут быть зарезервированы для любого отправителя. Такой фильтр не позволяет указать отправителей отдельно — он принимает всех отправителей, на что указывает установка адреса источника и порта в ноль. Символически запрос на резервирование в стиле WF можно представить как WF(*{Q}), где символ “*” представляет собой групповой символ выбора отправителей, a Q — объект FlowSpec.
В табл. 7.1 показаны различные фильтры резервирования, основанные на стилях резервирования и количестве отправителей, а на рис. 7.3 — три ранее рассмотренных стиля фильтров резервирования.
I Таблица 7.1. Различные фильтры резервирования, основанные на стиле : и количестве отправителей ■?•
Количество отправителейСтили резервирования
ИндивидуальноеОбщее
Явное резервированиеFFSE
Групповое резервированиеНе определеноWF
Рис. 7.3. Примеры трех стилей фильтров резервирования
Типы услуг
Протокол RSVP предоставляет два типа интегрированных услуг, которые получатели могут запрашивать с помощью сообщений RSVP RESV: службу регулируемой нагрузки и службу гарантированной битовой скорости.
Регулируемая нагрузка
Служба регулируемой нагрузки (controlled load service) обеспечивает гарантию того, что зарезервированный поток достигнет своего пункта назначения с минимальным вмешательством со стороны трафика, доставляемого без гарантий. Более того, в реализации этой услуги компанией Cisco предусмотрена изоляция отдельных зарезервированных потоков. Изоляция потока позволяет исключить влияние других присутствующих в сети зарезервированных потоков при резервировании ресурсов.
Как правило, служба регулируемой нагрузки применяется при передаче трафика Internet-приложений, чувствительных к перегрузкам в сети. Такие приложения отлично работают в незагруженных сетях, но сразу “приходят в негодность” при перегрузке. Примером таких приложений может служить приложение, работающее по протоколу FTP (File Transfer Protocol — протокол передачи файлов).
Гарантированная битовая скорость
Служба гарантированной битовой скорости (guaranteed bit rate service) обеспечивает ограничение задержки без отбрасывания датаграмм, удовлетворяющих параметрам трафика, в условиях отсутствия сбоев в работе сетевых компонентов или изменений в информации о маршрутах во время жизни потока. Эта служба гарантирует минимальное вмешательство со стороны трафика, доставляемого без гарантий, изоляцию зарезервированных потоков и числовое выражение максимальной задержки.
Служба гарантированной битовой скорости может обеспечить только максимальную, но не минимальную или среднюю задержку датаграмм. Более того, чтобы подсчитать максимальную задержку датаграммы, сначала нужно определить фиксированную задержку пути (задержка распространения и задержка передачи) и прибавить ее к гарантированной максимальной задержке очереди. Важно отметить, что служба гарантированной битовой скорости определяет максимальную задержку очереди, а не максимальную общую сквозную задержку, поскольку такие компоненты последней, как задержка распространения и задержка передачи полностью зависят от выбора пути, по которому передается трафик.
Максимальная задержка очереди — это кумулятивная задержка передачи РАТН- сообщения от источника до получателя. РАТН-сообщение содержит информацию о задержке на всем пути от источника до получателя и в любое время предоставляет получателю ее точную оценку. Получатель использует информацию о задержке во время запроса гарантированного обслуживания.
Служба гарантированной битовой скорости лучше всего подходит для тех приложений масштаба реального времени, которые позволяют воспроизводить аудио- и видеофайлы. Подобные приложения используют для своей нормальной работы буфер дрожания с целью компенсации неравномерности прибытия пакетов. Определяя мак-
симальную задержку очереди, служба гарантированной битовой скорости помогает оценить необходимый размер буфера дрожания. Таким образом, приложения масштаба реального времени могут рассчитывать на гарантированные полосу пропускания и максимальную задержку.
Службы регулируемой нагрузки и гарантированной битовой скорости используют корзину маркеров для описания параметров потока данных. Корзина маркеров — это механизм регулирования интенсивности трафика, определяющий среднюю скорость (средний объем данных, который можно передать за единицу времени), размер всплеска (объем данных, который можно отправить в течение заданного промежутка времени без ущерба для планирования очереди) и интервал измерения (квант времени). Более детально механизм регулирования интенсивности трафика с использованием корзины маркеров описывается в главе 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 является то, что объем требуемой информации о состоянии потоков увеличивается с ростом числа резервирований ресурсов для потоков трафика.
Так как в Internet-магистрали в любое время могут существовать многие сотни тысяч одноадресных и многоадресных потоков, использование информации о состоянии каждого потока считается немасштабируемым решением для магистралей Internet.
Протокол RSVP с резервированием ресурсов для каждого потока хорошо масштабируется в корпоративных intranet-сетях среднего размера со скоростью линий связи DS3 или меньше. При применении в больших intranet-сетях и магистралях поставщиков услуг Internet (Internet Service Provider — ISP) протокол RSVP хорошо масштабируется при условии использования больших многоадресных групп, больших статических классов или объединения потоков на границах сети. Агрегирование RSVP- резервирований предполагает слияние нескольких сквозных резервирований, имеющих общие маршрутизаторы входа и выхода, в одно большое сквозное резервирование. Другой подход к решению проблемы масштабируемости протокола 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-пакетов между отправителем и получателем, если возникнет необходимость устранения проблем соединения в сети.
PATH_
*RESV
PATH
" UUP порт 1U4U
' ICMP
RESV _PATH
RESV
„ ICMP
Рис. 7.4. RSVP-сигнализация и резервирование полосы пропускания для потоков трафика между двумя конечными узлами
Примечание. IP-адрес на диаграмме обозначает только последний октет едреса 210.210.210.Х.Примечание. IP-адрес на диаграмме обозначает только последний октет едреса 210.210.210.Х.
Примечание. IP-адрес на диаграмме обозначает только последний октет едреса 210.210.210.Х.
Примечание. IP-адрес на диаграмме обозначает только последний октет едреса 210.210.210.Х.
Примечание
Использование протокола 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
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, поскольку они необходимы только на пограничных маршрутизаторах.
Пограничные маршртуизаторы динамически распространяют RSVP-сообщения для того, чтобы позволить маршрутизатору R2 произвести резервирование для RSVP-потоков.
j Листинг 7.3. Конфигурация протокола RSVP на маршрутизаторе R3 •
interface EthernetO
ip address 210.210.210.33 255.255.255.224
fair-queue 64 256 234
ip rsvp bandwidth 7500 7500
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 allocate i/f max
flow max per/255 UDP
IP
UDP_IP
UDP М/С EtO
IK
7500K
7500K
0
/255
0
1
0
0 SeO
33K
1158K
1158K
7
/255
0
1
0
0
С помощью команды show ip rsvp interface можно получить информацию о распределении полосы пропускания интерфейса. По умолчанию, максимальная резервируемая полоса пропускания на интерфейсе равна 75% от обшей полосы пропускания интерфейса.
! Листинг 7.5. Информация, касающаяся RSVP-получателя, iна маршрутизаторе R1
Router#show ip rsvp sender
ToFromPro DPort Sport
Prev HopI/F BPS Bytes
210.210.210.30 210.210.210.60100
210.210.210.102 SeO IK IK 210.210.210.60 210.210.210.30100
210.210.210.30 EtO IKIK
210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.30 EtO 32K32K
Результат выполнения команды show ip rsvp sender показывает, что маршрутизатор RI “увидел” три различных сообшения RSVP PATH.
Листинг 7.6. Запросы RSVP-резервирования, полученные :маршрутизатором R1• i ■
Routerishow ip rsvp reservation
ToFromPro DPort. Sport
Next HopI/FFi Serv BPS Bytes
210.210.210.30 210.210.210.60 100
210.210.210.30 EtO FF LOAD IKIK
210.210.210.60 210.210.210.30 100
210.210.210.102 SeO FF LOAD IKIK
210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.102 SeO FF LOAD 32K32K
Результат выполнения команды show ip rsvp reservation показывает, что маршрутизатор RI получил три сообшения RSVP RESV. В этом примере маршрутизатор R1 получил одно сообщение RSVP RESV для UDP-потока от маршрутизатора R2 со следующей точкой назначения 210.210.210.102.
; Листинг 7.7. Установленные RSVP-резервирования на маршрутизаторе R1 j
Routerishow ip rsvp installed
RSVP: EthernetO
BPS То
From
Protoc
DPort
Sport
Weight Conv
IK210.210.210.30
210.210.210.60
1
0
0
4264
RSVP: SerialO
BPS To
From
Protoc
DPort
Sport
Weight Conv
IK210.210.210.60
210.210.210.30
1
0
0
128264
32K210.210.210.60
210.210.210.30
UDP
1040
0
4265
Результат выполнения команды show ip rsvp installed показывает наличие трех активных RSVP-резервирований на маршрутизаторе R1. Он также показывает номер диалога и вес, назначенный механизмом WFQ для каждого резервирования.
Обратите внимание, что вес наибольшего RSVP-резервирования всегда равен 4. Вес резервирования для ICMP-пакетов на интерфейсе serialO рассчитывается по следующей формуле:
4 х (запрос на RSVP-резервирование) ^ (наибольшее распределенное
RSVP-резервирование) = 4 х 32 + 1 = 128.
; Листинг 7.8. RSVP-резервирования, отправленные маршрутизатором R1 !. выше по потоку
DPort SportBytes 00DPort SportBytes 00Router#show ip rsvp request
DPort Sport
Bytes 00
DPort Sport
Bytes 00
ToFromPro
Next HopI/F Fi Serv BPS
210.210.210.30 210.210.210.60 1
210.210.210.102 SeO FF LOAD IKIK
210.210.210.60 210.210.210.30 100
210.210.210.30 EtO FF LOAD IK IK 210.210.210.60 210.210.210.30 UDP 1040 0
210.210.210.30 EtO FF LOAD 32K32K
Результат выполнения команды show ip rsvp request показывает, что маршрутизатор RI передал три сообщения RSVP RESV. В этом примере маршрутизатор R1 отправил сообщение RSVP RESV для UDP-потока расположенному ниже по потоку узлу со следующей точкой назначения 210.210.210.30.
I Листинг 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-сообщения.
1 Листинг 7.10. Информация об очереди интерфейса serialO
>маршрутизатора R1
Router#show 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
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-резервирования.
: Листинг 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, либо быструю схему повторной передачи сообщений.
Резюме
В рамках архитектуры intserv протокол RSVP используется для сигнализации QoS- требований с помощью управляющих сообщений, которые отличаются от обычных пакетов с данными. RSVP-сигнализация предоставляет определенные ресурсные гарантии на всем пути трафика.
При использовании протокола RSVP архитектура intserv, как и архитектура diffserv, зависит от планировщика пакетов в маршрутизаторе с поддержкой QoS (такого, как WFQ и WRED), обеспечивающего требуемое качество обслуживания для RSVP-потоков.
Ответы на часто задаваемые вопросы
Приведите примеры приложений с поддержкой протокола RSVP.
Примерами популярных настольных приложений с поддержкой протокола RSVP могут служить Microsoft NetShow и NetMeeting. Более того, новая операционная система Microsoft 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. Убедитесь, что на интерфейсе, на котором установлено резервирование, используется этот механизм. Более
подробно механизм 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-потоку, обрабатываются посредством механизма коммутации, сконфигурированного на маршрутизаторе. Более подронбо коммутация пакетов обсуждается в приложении Б, “Механизмы коммутации пакетов”.
Качество обслуживания канального уровня и сетиКачество обслуживания канального уровня и сетиMPLS —с IP QoSMPLS —с IP QoS■Я■ЯЙЕЙЕВ этой части;..В этой части;..Глава 8. Качество обслуживания на уровне 2:межсетевой обмен с IP QoS
Качество обслуживания канального уровня и сети
Качество обслуживания канального уровня и сети
MPLS —с IP QoS
MPLS —с IP QoS
■Я
■Я
ЙЕ
ЙЕ
В этой части;..
В этой части;..
Глава 9. Качество обслуживания в сетях MPLS
i
199241199241@?^^@?^^ff:$Г^'^^"'’' А
199
241
199
241
@?^^
@?^^
f
f
ГлаваГлава88
Глава
Глава
8
8
Качество обслуживания на уровне 2: межсетевой обмен
Чаше всего в сетях используются разнообразные технологии передачи информа-
^ции. В таких популярных технологиях канального уровня, как режим асинхронной ^передачи (Asynchronous Transfer M6de?- ATM), ретрансляция кадров (Frame Relay) и Ethernet, функции качества, обслу^б^ия (Quality of Service — QoS) реализуются на |уровне 2 эталоЦнрй''модели,Ю51. |В Йрй главе обсуждаются технологии канального Йровьу^^йожеёгвенным доступом и .способ реализации в них качества обслужива- ^ййя. Поскольку качество работы-функции QoS приравнивается к качеству работы самого слабого канала в сети, необходимо|удостовериться, чтобы функции QoS Internet- а.протокола (IP) были непрерывны при переходе на другие технологии канального руровня. Таким образом, для обеспечения,сквозной работы IP QoS необходимо, чтобы
^‘QoS на уровне 2 преобразовывалась в IP QoS, и наоборот.
g1
11IM*- '
1
1
| ATM — это технология коммутации и мультиплексирования ячеек с фиксиро- | ванным размером. "Поскольку данная технология ориентирована на соединение, 1 виртуальный канал (Virtual Circuit — VC) в ATM-сети должен быть установлен до того, как пользователь сможет Передавать данные между двумя и более АТМ- устройствами. В основном в технологии ATM используются два типа соединения (два виртуальных канала): постоянные виртуальные каналы (Permanent Virtual ^Circuic— PVC) ^коммутируемые виртуальные каналы (Switched Virtual Circuit — SVC). Первые обычно являются статическими и нуждаются в ручной или внешней настройке. Каналы SVC являются динамическими и создаются по требованию. Для установки и тех и других каналов требуется сигнальный протокол между конечными ATM-точками и АТМ-коммутаторами.
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-ячейка UNIATM-ячейка NNI
GFC — общее управление потоком (Generic Flow Control)
VPI — идентификатор виртуального пути (Virtual Path Identifier)
VCI — идентификатор виртуального канала (Virtual Channel Identifier)
PT —тип полезной нагрузки (Payload Тура)
CLS — приоритет отбрасывания ячайки (Call Loss Priority) НЕС — контроль ошибок в заголоаке (Header Error Control)
Рис. 8.1. Форматы заголовка для А ТМ-ячеек типа UN1 и NNI
Общее управление потоком (GFC) влияет на локальное (пользовательское) управление потоком. Механизм GFC используется для управления трафиком, который исходит из конечных станций в сеть. В формате NNI-ячейки поля GFC нет. Определяется два режима работы: неконтролируемый доступ и контролируемый доступ. Тра-
фик, который поступает в сеть без управления потоком на основе механизма 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, равным 1, и значением VCI, равным 100. Основываясь на своей таблице отображения, коммутатор направляет их в порт 3 с новым значением VPI, равным 2, и новым значением VCI, равным 100.
Рассмотрим оставшиеся поля АТМ-заголовка.
Идентификатор типа полезной нагрузки (Payload Type Identifier — PTI). Это 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) и размер всплеска.
Таблица отображения каналов 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, соответствующим услуге передачи данных, объединенных в пакеты.
Существующие услуги 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 хорошо работает с протоколом управления передачей (Transmission Control Protocol — TCP), в котором реализован адаптивный алгоритм управления потоком.
Услуга ABR определяется параметром PCR и гарантируемой минимальной скоростью передачи ячеек (Minimum Cell Rate — MCR) на каждом виртуальном канале.
Неопределенная битовая скорость (Unspecified Bit Rate — UBR). UBR является ATM-эквивалентом услуги передачи данных методом негарантированной доставки протокола IP. В соответствии с этой услугой резервирование полосы пропускания не производится, а также нет никаких ограничений, касающихся задержки и дрожания. На уровне ATM также не осуществляется контроль за перегрузкой сети. Примером трафика такого типа может служить массивная передача файлов,
в частности резервирование системы. Протокол TCP не очень хорошо работает в связке с услугой UBR, так как передача данных по 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 отбрасывает весь пакет. С другой стороны, функция EPD применяется еще перед тем, как какая-либо ячейка допускается в очередь на отправку. Во время поступления новых пакетов алгоритм EPD проверяет коэффициент загрузки выходного буфера. Если этот коэффициент ниже сконфигурированного порогового значения, ATM-коммутатор считает, что размер буфера не будет превышен и все ячейки пакета могут быть помещены в очередь. В противном случае коммутатор предполагает, что буфер близок к переполнению и весь пакет не может быть помешен в очередь, в результате чего пакет отбрасывается. Таким образом, функция EPD либо ставит в очередь все ячейки пакета, либо отбрасывает весь пакет. В связи с тем, что функция EPD производит полное отбрасывание
пакета перед тем, как любая из ячеек пакета будет помещена в очередь, этот процесс называется ранним отбрасыванием пакета (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: выравнивание трафика на виртуальном пути
Поставщик услуг Internet (ISP) 1-го уровня желает сотрудничать с альтернативной местной телекоммуникационной компанией (Competitive Local Exchange Carrier — CLEC) с целью предоставления виртуального ISP-продукта. CLEC предоставляет физический DSL-доступ для конечных пользователей, a ISP 1-го уровня — соединение с Internet. Предположим, что поставщик услуг ISP-1 покупает Internet-канал шириной 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.
CLECCLECFrame ReleyFrame ReleyATMO/O/1ATMO/O/1Коммутатор ATM/ Frame RelayКоммутатор ATM/ Frame RelayDS3 (или OC-3)DS3 (или OC-3)VP c ATM DS3 пропускной (или ОС-3) способностью3 Мбайт/сVP c ATM DS3 пропускной (или ОС-3) способностью3 Мбайт/сVP с пропускной способностью ,._,6 Мбайт/с Маршрутизатор поставщика услуг InternetVP с пропускной способностью ,._,6 Мбайт/с Маршрутизатор поставщика услуг InternetI АТМО/О/ОI АТМО/О/ОПоставщик услуг Internet 1-го уровня
CLEC
CLEC
Frame Reley
Frame Reley
ATMO/O/1
ATMO/O/1
Коммутатор ATM/ Frame Relay
Коммутатор ATM/ Frame Relay
DS3 (или OC-3)
DS3 (или OC-3)
VP c ATM DS3 пропускной (или ОС-3) способностью
3 Мбайт/с
VP c ATM DS3 пропускной (или ОС-3) способностью
3 Мбайт/с
VP с пропускной способностью ,._
,6 Мбайт/с Маршрутизатор поставщика услуг Internet
VP с пропускной способностью ,._
,6 Мбайт/с Маршрутизатор поставщика услуг Internet
I АТМО/О/О
I АТМО/О/О
ISP1
DSL
2ZZZ DSLAM
DSL
ISP 2
Рис. 8.4. Пример выравнивания VP-трафика
Каждому поставщику услуг Internet, подсоединенному через CLEC, назначается интерфейс на маршрутизаторе ISP 1-го уровня; при этом все его (вторичного ISP)
виртуальные каналы попадают в один виртуальный путь. В примере конфигурации маршрутизатора ISP 1-го уровня, показанной в листинге 8.2, видно, что для поставщика услуг ISP-1 назначен интерфейс АТМО/О/О и виртуальный путь 2. Механизм выравнивания VP-трафика конфигурируется на главном ATM-интерфейсе. Все виртуальные каналы используют один VP, при этом каждому из них присвоен собственный субинтерфейс на главном интерфейсе.
Листинг 8.2. Конфигурация механизма выравнивания VP-трафика * на интерфейсе АТМО/О/О маршрутизатора ISP 1-го уровня
interface АТМО/О/О atm pvp 2 6000000 I
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. Параметры выравнивания УЁ-трафика
Router#show atm vp
Data CESPeakCES
StatusACTIVEStatusACTIVEInterfaceVPIVCs VCsKbpsKbps
Status
ACTIVE
Status
ACTIVE
ATM0/0/023060000000
Вы можете получить более детальную информацию о виртуальном пути 2 с помощью команды show atm vp 2. Эта команда выводит информацию обо всех виртуальных каналах в маршрутизаторе с идентификатором VPI, равным 2. Два виртуальных канала управления автоматически создаются маршрутизатором в каждой сконфигурированной VP-группе — один для передачи служебных ячеек ОАМ F4 сегмента и второй для сквозной передачи служебных ячеек ОАМ F4. В листинге 8.4 приведена детальная информация по виртуальным каналам с идентификатором виртуального пути 2.
Листинг 8.4. Информация о параметрах выравнивания VP-трафика для j , вирильного пути 2(
Routertshow atm vp 2
АТМО/О/О VPI: 2, PeakRate: 6000000, CesRate: 0, DataVCs: 3,
CesVCs: 0, Status: ACTIVE
VCD
1
2
101
102
103
VCI Type InPkts OutPkts AAL/Encap Status 3 PVC 0 0 F4 OAM ACTIVE 4 PVC 0 0 F4 OAM ACTIVE 101 PVC 0 0 AAL5-SNAP ACTIVE 102 PVC 0 0 AAL5-SNAP ACTIVE 103 PVC 0 0 AAL5-SNAP ACTIVE
TotallnPkts: 0, TotalOutPkts: 0, TotallnFast: 0,
TotalOutFast: 0, TotalBroadcasts: 0
С помощью команды show atm vc можно просмотреть информацию обо всех виртуальных каналах на маршрутизаторе, независимо от их VPI. В листинге 8.5 отображена информация обо всех виртуальных каналах ATM маршрутизатора.
f Листинг 8.5. Параметры виртуальных каналов ATM' \
VCD /
Peak Avg/Mir
1 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-сети оказывается просто необходимой. С этой
целью на входных очередях АТМ-сети следует применить такие механизмы QoS, как взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detection — WRED) и взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing — WFQ). После этого отбрасывание пакетов и планирование выходной очереди будет основываться на запрошенном уровне качества обслуживания пакета. Более подробно алгоритмы WRED и WFQ обсуждаются в главе 4, “РНВ-политика: распределение ресурсов (часть 1)”, и главе б, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов”, соответственно.
Рис. 8.5. Передача IP-трафика через облако ATM
Обратите внимание, что с точки зрения IP QoS IP-трафик передается по АТМ-сети без потерь (потери в АТМ-сети не отслеживаются на уровне IP QoS) с использованием услуги ATM, которая удовлетворяет всем запросам 1Р-трафика к качеству обслуживания. На уровне IP QoS каждому виртуальному каналу АТМ-сети соответствует отдельная очередь, так что алгоритмы WRED и WFQ можно применить к любому УС.
В этом разделе обсуждаются два сценария обеспечения функций IP QoS при передаче трафика через АТМ-сеть.
Один канал РУС переносит весь IP-трафик в конечную точку назначения. 1Р-трафик, превышающий параметры ATM РУС, ставится в очередь на входе в ATM-сеть. По мере возрастания перегрузки очередь обслуживается такими механизмами IP QoS, как WRED и WFQ. Алгоритм WRED гарантирует, что потери более приоритетного трафика будут гораздо меньше, чем потери менее приоритетного трафика. Алгоритм WFQ гарантирует, что более приоритетному трафику будет предоставлена большая полоса пропускания по сравнению с менее приоритетным трафиком, поскольку более приоритетный трафик обслуживается чаще. Следует также отметить, что когда трафик канала РУС обслуживается в соответствии со взвешенным механизмом равномерного обслуживания очередей на основе класса (Class-Based Weighted Fair Queuing — CBWFQ), вы можете назначать полосы пропускания в зависимости от класса трафика. Более подробно механизм CBWFQ обсуждается в главе 4, “РНВ- политика: распределение ресурсов (часть 1)”.
VC-связка, состоящая из нескольких PVC, переносит IP-трафик в конечную точку назначения. Когда трафик с различными требованиями QoS (трафик масштаба реального времени; трафик, передаваемый не в режиме реального времени; тра-
фик, передаваемый методом негарантированной доставки) доставляется в одно и то же место, лучше всего создать несколько 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-канал связки, по которому передается высокоприоритетный трафик.
окажется перегруженным, а PVC-канал, по которому передается менее приоритетный трафик, останется относительно свободным. Отметьте, что в случае перегрузки PVC- канала нельзя автоматически перебросить его высокоприоритетный трафик на другой PVC-канал этой же связки. При использовании одного PVC можно применить механизм CBWFQ с приоритетной очередью, обеспечивая таким образом первенство голосового трафика среди других типов данных, передаваемых по этому PVC. Более подробно механизм CBWFQ с приоритетной очередью обсуждается в главе 4, “РНВ- политика: распределение ресурсов (часть 1)”.
□□□□□□□□Облако ATMОблако ATMНесколько PVC-каналоа ATM (по одному на каждый класс IP-трафика) с различными услугами ATM QoSНесколько PVC-каналоа ATM (по одному на каждый класс IP-трафика) с различными услугами ATM QoSМеханизмы WREDи WFQ для каждого PVC-каналаМеханизмы WREDи WFQ для каждого PVC-каналаОдин канал ABR PVC для всех классов трафикаОдин канал ABR PVC для всех классов трафикаРис. 8.7. Межсетевое взаимодействие 1Р-АТМ QoSРис. 8.7. Межсетевое взаимодействие 1Р-АТМ QoS
□□□□
□□□□
Облако ATM
Облако ATM
Несколько PVC-каналоа ATM (по одному на каждый класс IP-трафика) с различными услугами ATM QoS
Несколько PVC-каналоа ATM (по одному на каждый класс IP-трафика) с различными услугами ATM QoS
Механизмы WREDи WFQ для каждого PVC-канала
Механизмы WREDи WFQ для каждого PVC-канала
Один канал ABR PVC для всех классов трафика
Один канал ABR PVC для всех классов трафика
Рис. 8.7. Межсетевое взаимодействие 1Р-АТМ QoS
Рис. 8.7. Межсетевое взаимодействие 1Р-АТМ QoS
Практический пример 8.3: дифференцированное отбрасывание IP-пакетов на границе АТМ-сети
Предположим, что инженер, обслуживающий магистраль поставщика услуг Internet, реализовал в IP-сети дифференцированные услуги, предполагающие наличие трех классов: “золотого”, “серебряного” и “бронзового”. Входящий трафик сети распределяется по трем классам обслуживания на основе значения IP-приоритета (табл. 8.1). На определенной части магистрали в качестве основной транспортной технологии используется ATM. Инженеру необходимо применить два механизма IP QoS на входе в ATM-сеть — механизм WFQ для выделения полосы пропускания каждому классу услуг и механизм WRED для того, чтобы любое отбрасывание пакетов было основано на значении IP-приоритета пакета.
^Таблица 8.1. Классы услуг на основе IP-приоритета 1;
УправляющийЗолотойСеребряный
гj^ ^few^y <t3$$».; j
Бронзовый
Обычный трафикПриоритет?Приоритет5Приоритет3
Чрезмерный трафикПриоритетеПриоритет 4Приоритет 2
Приоритет 1
Приоритет 0
PVC-канал должен обеспечивать передачу данных без потерь, так как отбрасывание ячеек в ATM-сети производится независимо от значения IP-приоритета. Таким образом, ATM-сеть функционирует как механизм передачи данных без потерь физического уровня и при этом обеспечивает требуемые IP-трафиком услуги.
Прежде всего для каждого класса услуг определяются классы трафика и политики. Заданная политика применяется к входному интерфейсу ATM-сети. В листинге 8.6 приведен пример соответствующей конфигурации маршрутизатора.
Листинг 8.6. Конфигурация межсетевого обмена 1Р-АТМ 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
Обратите внимание, что в конфигурации используется модульный интерфейс командной строки 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-map atmpolicy
Policy Map atmpolicy
Weighted Fair Queueing
Class control
mark-probability
Bandwidth 20000 (kbps) exponential weight 9
max-threshold
class
min-threshold
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/10
1
-
-
1/10
2
1/10
3
-
-
1/10
4
128
512
1/10
5256
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
2128
512
1/10
3256
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
0128
512
1/10
1256
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-приоритета в АТМ-сети.
I .Листинг8.8. Конфигурация PVC-связки. \ i «’^чнН*^ ^ *'< V. 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.5: установка CLP-бита на основе IP-приоритета
Сетевому администратору, ответственному за реализацию в IP-сети компании дифференцированных услуг, основанных на IP-приоритете, необходимо отобразить IP-приоритет на CLP-бит. Так как напрямую это сделать невозможно, сетевой администратор хочет установить CLP-бит (присвоить ему значение 1) для IP-пакетов с приоритетом 0. Таким образом, в случае возникновения перегрузки в ATM-сети трафик, передаваемый методом негарантированной доставки (IP-приоритет 0), будет отбрасываться перед более высокоприоритетным трафиком. В листинге 8.9 приведена необходимая для этого конфигурация маршрутизатора.
Листинг 8.9. Конфигурация, предусматривающая установку CLP-бита для j ' ' трафика, передаваемого методом негарантированной дос- i
1 тавки '■ ;'/’‘v ’ 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 была введена относительно недавно.
Для отправки во 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 Explicit Congestion Notification — FECN), обратного явного уведомления о перегрузке (Backward Explicit Congestion Notification — BECN) и DE-бит (Discard Eglible — кадр, пригодный для отбрасывания).
Вы можете установить в коммутаторе значение FECN-бита, равное 1, для того чтобы сообщить конечному терминальному оборудованию (data terminal equipment — DTE), например маршрутизатору, что на пути передачи кадра от источника до конечной точки произошла перегрузка сети.
Значение 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.
Выравнивание 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.
ммCIRCIRCIRCIRCIRCIRс помощью бита DEс помощью бита DEс помощью бита DEс помощью бита DEРис. 8.10. Взаимоотношение между параметрами механизма выравнивания трафикаРис. 8.10. Взаимоотношение между параметрами механизма выравнивания трафика
м
м
CIR
CIR
CIR
CIR
CIR
CIR
с помощью бита DE
с помощью бита DE
с помощью бита DE
с помощью бита DE
Рис. 8.10. Взаимоотношение между параметрами механизма выравнивания трафика
Рис. 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 используется
для отправки тестового кадра Q.922 с установленным BECN-битом в ответ на получение уведомления FECN.■
Фрагментация в сетях Frame Relay
Большие пакеты, поставленные в выходную очередь канала PVC маршрутизатора перед маленькими, чувствительными к задержкам пакетами, способствуют увеличению задержки и дрожания маленьких пакетов. Это происходит из-за того, что задержка при передаче больших пакетов обычно больше задержки при передаче маленьких пакетов. Более подробно задержка при передаче рассматривалась в главе 1, “Введение в качество обслуживания в сетях IP”. Разбивая при постановке в очередь на передачу большие кадры с данными на более мелкие кадры и вставляя между ними маленькие, чувствительные к задержкам пакеты с последующей сборкой кадра в конечной точке, мы тем самым облегчаем жизнь маленьким пакетам. Форум Frame Relay (Frame Relay Forum — FRF) одобрил новый стандарт фрагментации 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 с качеством обслуживания междугородной
телефонной связи. Фрагментация, особенно если она используется вместе с механизмами 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
Активизация механизма 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-очереди интерфейса. Пакеты с данными, обслуживаемые посредством очереди с выравниванием трафика, разбиваются на фрагменты в зависи-
Структура организации очередей маршрутизатораСтруктура организации очередей маршрутизаторапакетов с даннымипакетов с даннымиFrame RelayFrame Relayиимости от установленного порогового значения и помещаются в обычную FIFO- очередь интерфейса. Пороговое значение размера фрагмента должно быть установлено таким образом, чтобы ни один голосовой пакет не был фрагментирован. Несмотря на то что для каждого канала PVC существует отдельная очередь выравнивания трафика, все каналы PVC используют двойную FIFO-очередь интерфейса. Пакеты извлекаются из приоритетной FIFO-очереди в соответствии со строгим приоритетом по сравнению с пакетами обычной FIFO-очереди интерфейса.
Структура организации очередей маршрутизатора
Структура организации очередей маршрутизатора
пакетов с данными
пакетов с данными
Frame Relay
Frame Relay
и
и
Большойпакет сданными(PVC1)
I игпгп t t Маленький Большой VoIP-пакет пакет с (PVC 1) данными (PVC 2)
Рис. 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.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 с функцией автораспознавания QoS5 < J
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)
DLCI = 17
OUT: CIR
64000ВС 9600BE 9600FMIF
4497
IN:CIR
32000BC 30000BE 20000FMIF
4497
Priority 0
(Time elapsed since last update 00:00:03)
i Листинг 8.12. Параметры механизма выравнивания трафика Frame Relay j
Routerflshow traffic-shape
access TargetByte . SustainExcessInterval
I/F
Se0/0
list RateLimitbits/intbits/int(ms)
64000240096009600150
Значение в столбце 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
map-class frame-relay adaptivefrts frame-relay traffic-shape rate 256000 frame-relay traffic-shape adaptive 64000
[листинг 8.14. Конфигурация механизма DTS для интерфейса -i
। '• маршрутизатора, подключенного к поставщику услуг :
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, соответственно, для маршрутизатора поставщика услуг.
[ "" ""~" "■"’ :'~’-—^ - -- - -, - ;
Листинг 8.15. Конфигурация механизма FRTS для интерфейса:
Jмаршрутизатора поставщика услуг!
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
Листинг 8.16. Конфигурация механизма DTS для интерфейса л - iмаршрутизатора поставщика услуг л- > s ?\
1 : lz—^———_ -^l^^.^-2lll^^ д2— ir~2ii^ IILll^
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.17. Конфигурация, предусматривающая маршрутизацию : , ' f ( трафика в зависимости от его^ипа^. .;^.
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 100permitipanyanyprecedenceroutine
access-list 101permitipanyanyprecedencepriority
access-list 102permitipanyanyprecedenceimmediate
access-list 103permitipanyanyprecedenceflash
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-группе. Эта же команда показывает статистику пакетов для каждого идентификатора DLCI. Команда show queueing priority (листинг 8.19) показывает сконфигурированный на маршрутизаторе список приоритетов.
Листинг8.18 Результат выполнения команды show frame-re/ay pvc ,:
Routerfshow frame-relay pvc
PVC Statistics for interface Serial5/0 (Frame Relay DTE) Active Inactive Deleted Static
Local4000
Switched0000
Unused0000
DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
input pkts 0out bytes 0input pkts 0out bytes 0output pkts 0dropped pkts 0output pkts 0dropped pkts 0in bytes 0in FECN pkts 0in bytes 0in FECN pkts 0
input pkts 0
out bytes 0
input pkts 0
out bytes 0
output pkts 0
dropped pkts 0
output pkts 0
dropped pkts 0
in bytes 0
in FECN pkts 0
in bytes 0
in FECN pkts 0
in BECN pkts 0out FECN pkts 0out BECN pkts 0
in DE pkts 0out DE pkts 0
out beast pkts 0out 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 0output pkts 0inbytes0
out bytes 0dropped pkts 0inFECN pkts0
in BECN pkts 0out FECN pkts0outBECNpkts0
in DE pkts 0out DE pkts 0
out beast pkts 0out beast bytes 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
output pkts 0
in bytes 0
out bytes 0
dropped pkts 0
in FECN pkts 0
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:04:36, last time pvc status changed 00:04:36
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Se5/0
in bytes 0in FECN pkts 0out BECN pkts 0in bytes 0in FECN pkts 0out BECN pkts 0input pkts 0output pkts 0
in bytes 0
in FECN pkts 0
out BECN pkts 0
in bytes 0
in FECN pkts 0
out BECN pkts 0
out bytes 0dropped pkts 0
in BECN pkts 0out FECN pkts 0
in DE pkts 0out DE pkts 0
out beast pkts 0out beast bytes 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.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-приоритетом 0 ,,
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
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 ' | у с алгоритмом обслуживания очередей 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 байт, будет разбит на части. Для активизирования фрагментации необ-
холимо активизировать механизм выравнивания трафика 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 используется для определения всех расширений оригинальной спецификации Ethernet, в которых продолжается использование метода доступа к среде 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
Длина поля в байтахIEEE 802.3
766246-15004
Превмбула
S О F
Адрес назнвчвния
Адрес источника
Длине
Заголовок 802.3 и данные
FCS
SOF — ограничитель начала кадра (Start Of Frame delimiter)
FCS — контрольная последовательность кадра (Frame Check Sequence)
Рис. 8.13. Форматы кадров Ethernet и IEEE 802.3
Возможность передачи высокоприоритетного трафика
Возможность передачи высокоприоритетного трафика позволяет проводить дифференциацию передаваемой информации в сетях Ethernet, виртуальных локальных сетях (VLAN) и др.
CFICFIАдрас назначанияАдрас назначанияVID (VLAN ID)-12 битVID (VLAN ID)-12 битАдрас источникаАдрас источникаПриоритат пользователяПриоритат пользователя66222Параменнаядлина466222Параменнаядлина4Возможность передачи высокоприоритетного трафика для Ethernet определена как часть стандарта 802.1р. Для поддержки сетей VLAN используются три бита 4-байтовой метки, определенной стандартом 802.1Q. 4 байта 802.1Q и биты 802.1р показаны на рис. 8.14.
CFI
CFI
Адрас назначания
Адрас назначания
VID (VLAN ID)-12 бит
VID (VLAN ID)-12 бит
Адрас источника
Адрас источника
Приоритат пользователя
Приоритат пользователя
6
6
2
2
2
Параменнаядлина
4
6
6
2
2
2
Параменнаядлина
4
1 ;<«#EtherTypesuTPID^#‘ Контрольная I ,информация метки а
ДанныаДанныаPADPADFCSFCSДлина/тип МАС
Данныа
Данныа
PAD
PAD
FCS
FCS
Рис. 8.14. Кадр 802.1Q с битами 802.1р
В стандарте 802.1Q определяется новый тип маркированного кадра путем добавления 4-байтовой метки, состоящей из следующих частей.
Два байта идентификатора маркированного протокола (Tagged Protocol Identifier - TPID):
0x8100 используется для маркировки пакета 802.1Q.
Два байта маркированной контрольной информации (Tagged Control Information — TCI):
три бита 802. Ip;
один бит идентификатора канонического формата (Canonical Format Identifier — CFI);
12-битовый идентификатор VLAN (ID).
На рис. 8.15 показано, как оригинальный кадр Ethernet/802.3 преобразуется в маркированный кадр 802.1Q. После введения 4-байтовой метки необходимо пересчитать контрольную последовательность кадра.
В стандарте 802.1р предусмотрен метод сохранения информации о приоритете при передаче кадра по локальной сети. Всего существует 8 приоритетов на основе значения трех битов 802.1р. С целью поддержки стандарта 802.1р канальный уровень должен поддерживать множественные очереди — по одной на каждый приоритет или
класс трафика. Высокоприоритетный трафик всегда предпочтительнее низкоприоритетного. Коммутатор сохраняет значения приоритета при коммутации кадра.
НазваниеНазваниеИсточникИсточникДлина/тип ДанныеДлина/тип ДанныеНачальный кадрНачальный кадрНазваниеНазваниеИсточникИсточникTPID TCI Длина/тип ДанныеTPID TCI Длина/тип ДанныеFCSFCSПриоритет CFI JI11ШL.Приоритет CFI JI11ШL.VLAN-IDVLAN-IDОтмеченныйкадрОтмеченныйкадр(VLAN-ID и CFI являются частью стандарта 802.10, а нв 602.1р)(VLAN-ID и CFI являются частью стандарта 802.10, а нв 602.1р)
Название
Название
Источник
Источник
Длина/тип Данные
Длина/тип Данные
Начальный кадр
Начальный кадр
Название
Название
Источник
Источник
TPID TCI Длина/тип Данные
TPID TCI Длина/тип Данные
FCS
FCS
Приоритет CFI JI11ШL.
Приоритет CFI JI11ШL.
VLAN-ID
VLAN-ID
Отмеченныйкадр
Отмеченныйкадр
(VLAN-ID и CFI являются частью стандарта 802.10, а нв 602.1р)
(VLAN-ID и CFI являются частью стандарта 802.10, а нв 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.
Возможность передачи высокоприоритетного трафика определена как часть стандарта 802.1р. Стандарт 802.1 р является частью недавно модифицированной версии стандарта для прозрачного мостового соединения 802.1 D. Передача высокоприоритетного трафика предполагает разделение его на классы с целью дифференцированной передачи пользовательских данных на уровне кадра.
Рабочая группа IETF, разрабатывающая интегрированные услуги на специфических нижних уровнях (Integrated Services over Specific Lower Layers— ISSLL), определяет метод отображения запросов протокола резервирования ресурсов 3-го уровня (Resource Reservation Protocol — RSVP) на приоритеты 802.1 р посредством диспетчера полосы пропускания подсети (Subnet Bandwidth Manager— SBM). Более подробно диспетчер SBM рассматривается в следующем разделе этой главы.
Диспетчер SBM
SBM — сигнальный протокол, поддерживающий управление доступом на основе протокола RSVP в семействе сетей Ethernet 802.3. Как упоминалось в главе 7, “Интегрированные услуги: RSVP”, RSVP — это механизм сквозной сигнализации, использующийся для запросов резервирования ресурсов сети. В сети Ethernet гарантированное резервирование полосы пропускания невозможно ни для одной станции в сегменте, так как Ethernet-сегмент является сетью с разделяемой средой передачи. Станция Ethernet-сегмента не располагает сведениями о резервировании ресурсов, произведенном другими станциями, и может отправлять трафик в сегмент со скоростью, не соответствующей существующему распределению ресурсов. SBM — это средство для поддержки резервирования ресурсов на основе протокола RSVP в сетях семейства 802.3.
Ethernet-сегмент с одним или несколькими устройствами, поддерживающими протокол SBM, называется управляемым Ethernet-сегментом (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).
Инициализация
Для обеспечения работы протокола 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_;DSBM с интервалом в DSBMRefreshinterval секунд. Если 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-адресом побеждает.
Расширения 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 с возможностью превышать согласованное качество обслуживания, когда сеть не пере-
гружена. Протокол 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, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика".
Таблица 8.2. Сравнени!
в функций GTS и FRTSJ
GTSFRTS
Предполагаемое применение Степень детализации
Общее для всех интерфейсовТолько Frame Relay
Работает на уровне интерфейса Работает на уровне PVC-канала Frame Relay или DLCI
Внутренняя выравнивающая очередь
Для обслуживания внутренней вы- Для обслуживания внутренней выравнивающей очереди используются равнивающей очереди использу- только алгоритмы WFQ и CBWFQ,ются алгоритмы PQ, CQ, WFQ и
основанные на потоке.CBWFQ.
Алгоритмы WFQ и CBWFQ под-Алгоритмы WFQ и CBWFQ под
держивают строгую приоритетную держивают строгую приоритетную очередьочередь
Фрагментация FRF.12
Интерфейсная очередь
Не поддерживаетсяРаботает только с механизмом FRTS
На интерфейсном уровне подцер- На интерфейсном уровне поддерживается любой тип обслуживания живается только двойная FIFO- очередейочередь
241248254255258268241248254255258268
241
248
254
255
258
268
241
248
254
255
258
268
MPLSs
MPLS и ATM Г
Качество обслуживания в сетях MPLSу
Предоставление сквозных услуг IP QoS < Виртуальные частные сети (VPN) на основе MPLS Качество обслуживания в сетях MPLS VPN ;Д
Глава
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) коммутирует пакеты путем замены метки с использованием информации, передаю-
щейся в пакете, и информации о продвижении меток, поддерживаемой управляющим компонентом.
Как видно из названия, технология 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.
LER — пограничный маршрутизатор меток (Label Edge Router) LSR — маршрутизатор коммутации меток (Label Switching Router)LER — пограничный маршрутизатор меток (Label Edge Router) LSR — маршрутизатор коммутации меток (Label Switching Router)LER на входеМаршрутизатор на границе MPLS-сети1. Классификация пакетов2. Добавление в пакет MPLS-меткиLER на входеМаршрутизатор на границе MPLS-сети1. Классификация пакетов2. Добавление в пакет MPLS-меткиLSR1Р-маршрутизатор/ ATM-коммутатор базовой сети с поддержкой MPLS1. Передача пакетов на основеLSR1Р-маршрутизатор/ ATM-коммутатор базовой сети с поддержкой MPLS1. Передача пакетов на основеLER на выходе1. Коммутация пакета после удаления метки на основе IP-адреса точки назначенияLER на выходе1. Коммутация пакета после удаления метки на основе IP-адреса точки назначенияMPLS-метки канального уровня
LER — пограничный маршрутизатор меток (Label Edge Router) LSR — маршрутизатор коммутации меток (Label Switching Router)
LER — пограничный маршрутизатор меток (Label Edge Router) LSR — маршрутизатор коммутации меток (Label Switching Router)
LER на входе
Маршрутизатор на границе MPLS-сети
1. Классификация пакетов
2. Добавление в пакет MPLS-метки
LER на входе
Маршрутизатор на границе MPLS-сети
1. Классификация пакетов
2. Добавление в пакет MPLS-метки
LSR
1Р-маршрутизатор/ ATM-коммутатор базовой сети с поддержкой MPLS
1. Передача пакетов на основе
LSR
1Р-маршрутизатор/ ATM-коммутатор базовой сети с поддержкой MPLS
1. Передача пакетов на основе
LER на выходе
1. Коммутация пакета после удаления метки на основе IP-адреса точки назначения
LER на выходе
1. Коммутация пакета после удаления метки на основе IP-адреса точки назначения
2. Предпоследний LER-маршрутизатор удаляет метку перед передачей пакета LER-маршрутизатору на выходе из MPLS-сети
Рис. 9.1. MPLS-сеть
С другой стороны, метка может быть связана с потоком конкретного приложения, обеспечивая гибкость механизма продвижения пакетов. Функционирование MPLS- сети схематически показано на рис. 9.2.
Когда метки привязываются к информации о маршруте, MPLS осуществляет передачу пакетов на основе адреса пункта назначения. Однако передача пакетов на основе адреса пункта назначения несовместима с более тонкими и гибкими политиками маршрутизации. В случаях, когда необходимо использовать гибкие политики передачи информации, привязка метки может основываться не на информации о маршруте. MPLS обеспечивает гибкие политики передачи пакетов, применяемые на уровне потока или группы потоков. Эту особенность MPLS можно использовать при реализации механизма управления трафиком (traffic engineering). Управление трафиком обсуждается в главе 10, “Управление трафиком в сетях MPLS”, далее в этой книге.
В следующем разделе описана процедура привязывания меток для обеспечения передачи пакетов на основе адреса пункта назначения.
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), который распространяет метки среди маршрутизаторов. Следует обратить внимание, что термины “нисходящий” и “восходящий” используются по отношению к направлению потока данных.
Нисходящее назначение меток
Нисходящее назначение меток (downstream label allocation) происходит в обратном направлении в отношении к потоку данных. Метка, передаваемая в пакете, генерируется и привязывается к префиксу LSR-маршрутизатором в конце канала по направлению потока данных. Таким образом, каждый LSR создает метки для своих непосредственно подключенных префиксов, привязывает их как входящие метки префиксов и распространяет ассоциацию метки среди всех маршрутизаторов, расположенных выше по потоку данных. Маршрутизатор, находящийся выше по потоку, заносит полученную привязку в таблицу СЕР как исходящую метку префикса и, в свою очередь, создает для него входящую метку, передавая ее следующему, расположенному выше по потоку данных маршрутизатору.
В режиме независимого распространения меток каждый расположенный ниже по потоку маршрутизатор самостоятельно привязывает входящую метку префикса и распространяет ее как исходящую метку среди всех маршрутизаторов, расположенных выше по потоку. В этом случае получение исходящей метки префикса перед созданием и распространением входящей метки необязательно. Когда у маршрутизатора есть и входящая, и исходящая метки префикса, он может начать коммутировать пакеты путем замены меток.
Другой режим распространения меток называется режимом упорядоченного управления (ordered control mode). В таком режиме перед тем, как отправить свою метку выше по потоку, маршрутизатор ожидает получения метки от соседа, расположенного ниже по потоку.
Нисходящее назначение меток по требованию
Этот процесс назначения меток похож на нисходящее назначение, однако он инициируется по требованию маршрутизатора, расположенного выше по потоку. Данный маршрутизатор идентифицирует следующую точку назначения для каждого префикса из таблицы CEF и отправляет в нее запрос на создание привязки метки для этого маршрута. Оставшаяся часть процесса назначения метки совпадает с процессом нисходящего назначения меток.
Восходящее назначение меток
Восходящее назначение меток (upstream label allocation) происходит по направлению потока данных. Метка, передаваемая в заголовке пакета данных, генерируется и привязывается к префиксу LSR-маршрутизатором в конце канала против направления потока данных. Для каждой записи таблицы СЕР LSR-маршрутизатора исходящая метка назначается и распространяется среди маршрутизаторов, расположенных ниже по потоку, как входящая метка. В этом случае входящие метки распространяются по префиксам.
Когда у LSR-маршрутизатора есть и входящая, и исходящая метки префикса, он может начать коммутировать пакеты путем замены меток.
Когда LSR создает привязку исходящей метки к маршруту, коммутатор, помимо заполнения базы LIB, также обновляет свою таблицу СЕР информацией о привязке. Это позволяет LSR-маршрутизатору добавлять метки к изначально неотмеченным пакетам при их создании. В табл. 9.1 приводится сравнение методов нисходящего и восходящего распространения меток.
{ Таблица 9.1. Сравнение нисходящего и восходящего распространения меток
Нисходящее назначение
Восходящее назначение
Направление назначения меток
Происходит в направлении, противоположном направлению потока данных
Происходит в направлении потока данных
Назначение и распространение меток
Назначает входящую метку для всех записей в таблице CEF и распространяет исходящую метку среди маршрутизаторов, расположенных выше по потоку
Назначает исходящую метку для всех записей в таблице CEF и распространяет входящую метку среди маршрутизаторов, расположенных ниже по потоку
Протокол распространения меток
Назначает исходящие метки
Назначает входящие метки
Применимость
Применим для IP-сетей, построенных не на АТМ-технологии
Нисходящее назначение меток по требованию и восходящее назначение меток наиболее эффективны в сетях ATM
Примечание
Относительно управляющего компонента MPLS следует сделать несколько важных замечаний.
Общее число меток, использующихся LSR-маршрутизатором, не превышает число записей в его таблице СЕР. Вообще говоря, в большинстве случаев можно привязать одну метку к группе маршрутов с одинаковой следующей точкой назначения, поэтому число использующихся меток гораздо меньше, чем число СЕР-записей. Подобным образом можно обеспечить легкомасштабируемые решения.
Назначение меток зависит от топологической информации, отраженной в таблице СЕР, которая, в свою очередь, основана на информации о маршрутах, а не на текущем трафике данных.
MPLS не заменяет протоколы маршрутизации IP. Управляющий компонент MPLS зависит от существования информации о маршрутах в маршрутизаторе, но он не зависит от того, какой протокол маршрутизации используется в MPLS-сети. Следовательно, в MPLS-сети можно использовать любой протокол маршрутизации или даже несколько протоколов.
Инкапсуляция меток
Информация метки может передаваться в пакете несколькими способами.
Как 4-байтовая метка, которая вставляется между заголовками канального и сетевого уровня. Этот способ подходит для каналов типа “точка-точка” (Point-to-Point — PPP) и локальных сетей Ethernet (всех типов). Подобным методом можно передать одну MPLS-метку или стек меток (несколько меток). На рис. 9.3 показан способ передачи метки по каналам РРР и локальным сетям Ethernet.
Как часть заголовка канального уровня. Этот способ подходит для технологии ATM, в которой информация метки передается в полях VPI/VCI, как показано на рис. 9.4.
Заголовок РРР
MPLS-меткВ
Заголовок 3-го Уровня i -
Заголовок МАС
MPLS-метка
заголовок ^гоурбвня
Рис. 9.3. MPLS-метка в PPP-кадре и Ethernet-кадре
GFC
■51VPI "'р'" ver -'
’‘рп*
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.
0123
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 для всех остальных меток стека. Это позволяет привязывать префикс к нескольким меткам, другими словами — к стеку меток
(label stack). Каждая метка стека имеет свои собственные значения поля CoS, S- бита и поля TTL.
Примечание
Поле CoS в MPLS-заголовке имеет только 3 бит. Таким образом, в нем может передаваться только 3-битовое поле IP-приоритета, а 6-битовое поле кода дифференцированной услуги (Differentiated Services Code Point — DSCP) — нет. При необходимости информация CoS может передаваться в виде одной из меток MPLS-стека. Поле метки имеет размер 20 бит и способно вместить как поле IP-приоритета, так и поле DSCP.
11L (8 бит). Указывает “время жизни" MPLS-пакета. Значение TTL, установленное на границе MPLS-сети, уменьшается по мере прохождения пакетом каждой следующей точки назначения MPLS-сети.
Примечание
По умолчанию во время добавления метки поле TTL протокола IP копируется в поле TTL MPLS. Это позволяет служебной программе traceroute показывать все промежуточные узлы сети MPLS в том случае, когда при достижении точки назначения пакет проходит MPLS-облако.
Для того чтобы при входе в MPLS-сеть поле TTL протокола IP не копировалось в поле TTL MPLS, используется команда по mpls ip propagate-ttl. В этом случает значение поля TTL MPLS устанавливается в 255. Следовательно, после этого служебная программа traceroute не показывает промежуточные узлы в MPLS-сети. Вместо этого она отображает весь домен MPLS как один IP-переход.
MPLS и ATM
У ATM-коммутатора уже есть передающий компонент MPLS-типа, поскольку он производит замену поля VPI/VCI, похожую на замену MPLS-меток. Таким образом, для того чтобы коммутатор поддерживал MPLS, ему необходим только управляющий компонент. Для передающего компонента и передачи информации метки используется поле VPI/VCI. Во всех случаях, когда можно ограничиться одной меткой, для ее передачи по MPLS-сети, основанной на технологии ATM, используется поле VCI. Поле VPI вступает в действие, если возникнет необходимость во второй метке.
Для поддержки управляющего компонента MPLS на ATM-коммутаторе следует запустить протокол маршрутизации, например OSPF или IS-IS. Это нужно для общения с другими LSR-маршрутизаторами, получения информации о достижимости точек назначения сетевого уровня и распространения основанной на этой информации таблицы CEF. LSR-маршрутизатор ATM не обязательно должен работать с протоколом BGP, так как в большинстве случаев он все равно не может быть LER- маршрутизатором. Далее, чтобы информация метки распространялась среди соседних LSR, на этом маршрутизаторе необходимо запустить протокол распространения меток, такой, как LDP, и протокол резервирования ресурсов (Resource Reservation Protocol — RSRP) с функцией управления трафиком (TE-RSRP), который более подробно обсуждается в главе 10, “Управление трафиком в сетях 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из Нью-Йоркского маршрутизатора
NewYork#show 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
Локальная метка
Исходящая метка или VC-канал
Префикс
Выходной интерфейс
26
Метка POP
222.222.222.3
HssiVO
Локальная метка: 26
HssiVO
222.222.222 2 Чикаго
Локальная метка
Исходящая метка или VC-канал
Префикс
Выходной интерфейс
31
26
222.222.222.3
Hssi1/1
29
222.222.222.3
HssiVO
Локальная метка: 31
222.222.222.22
222.222.222.3 ->26
222.222.222.3 ->26
222.222.222,1
222.222.222.3
Нью-Йорк
Сан-Франциско
222.222.222.3 ->29
HssiVO
Даллас
222.222.222.4
222.222.222.3 ->31
222.222.222.3 ->0
Hssil/1
HssiVO
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
Локальная метка
Исходящая метка или VC-канал
Префикс
Выходной интерфейс
29
Метка POP
222.222.222.3
HssiVO
Локальная метка: 29
Направление потока данных
Рис. 9.6. Нисходящее распространение меток
^Листинг 9.3. Параметры протокола распространения меток . ; л J
NewYorkjshow 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 маршрутизатора Чикаго
Chicagofshow ip caf 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 ~1 маршрутизатора Чикаго. i
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
i Листинг 9.6. Информация о продвижении метки для префикса 222.222.222.3 маршрутизатора Чикаго
Chicago#show mpls forwarding-table
LocalOutgoingPrefixBytes labelOutgoing Next Hop
Labellabel or VCor Tunnel Idswitchedinterface
26Pop label222.222.222.3/3263Hsl/0 point2point
Локальная метка 26 является привязкой метки префикса 222.222.222.3 на маршрутизаторе в Чикаго. Эта локальная привязка производится в ответ на появление записи 222.222.222.3 в таблице СЕР и распространяется среди всех 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 показана информация из таблицы СЕР, информация о привязке и информация о продвижении метки для префикса 222.222.222.3 маршрутизатора в Далласе.
Листинг 9.7. Информация о префиксе 222.222.222.3 из таблицы СЕР мар- 1шрути затор а в Далласе.
Dallas#show ip cef 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
[ Листинг 9.9. Информация о продвижении метки для префикса Г '';^^,‘/ J222.222.222.3 маршрутизатора в Далласе/ * / ,‘"‘
Dallasishow mpls forwarding-tableLocal OutgoingPrefixlabel label or VC or Tunnel Id 29Pop label222.222.222.3/32Dallasishow mpls forwarding-tableLocal OutgoingPrefixlabel label or VC or Tunnel Id 29Pop label222.222.222.3/32Bytes label Outgoing Next Hop switched interface1190 Hsl/0 point2pointBytes label Outgoing Next Hop switched interface1190 Hsl/0 point2point
Dallasishow mpls forwarding-table
Local OutgoingPrefix
label label or VC or Tunnel Id 29Pop label222.222.222.3/32
Dallasishow mpls forwarding-table
Local OutgoingPrefix
label label or VC or Tunnel Id 29Pop label222.222.222.3/32
Bytes label Outgoing Next Hop switched interface
1190 Hsl/0 point2point
Bytes label Outgoing Next Hop switched interface
1190 Hsl/0 point2point
Разъяснения этих листингов для маршрутизатора в Далласе в основном такие же, как и для маршрутизатора в Чикаго.
В листингах 9.10-9.12 представлена информация из таблицы СЕР, информация о привязке и информация о продвижении метки для префикса 222.222.222.3 маршрутизатора в Сан-Франциско.
; Листинг 9.10. Запись в таблице СЕР для префикса 222.222.222.3'•
|маршрутизатора в Сан-Франциско //'•■
SanFranciscoishow 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 Листинг 9.11. Информация б привязке метки для префикса 222.222.222.3. / 4
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 маршрутизатора в Сан-Франциско
SanFranciscoishow mpls forwarding-table
Local Outgoing PrefixBytes label Outgoing Next Hop
label label or VC or Tunnel Id switched interface
3126222.222.222.3/32 0Hsl/1 point2point
29222.222.222.3/32 0Hsl/0 point2point
В таблице 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ЙцгЙ912зМРк8 Оо
Шаг
Место применения
Подходящие функции 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-пакета.
Предоставление дифференцированных услуг с использованием механизмов 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.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(
Класс
Биты 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- маршрутизатор.
На интерфейсе LER-маршрутизатора, который подключен к облаку сети в Сиэтле, активизирован механизм CAR для ограничения входящего трафика в соответствии с контрактом. В листинге 9.13 поступающий на интерфейс трафик классифицируется как стандартный путем установки IP-приоритета 5 для трафика с интенсивностью менее 20 Мбит/с и IP-приоритета 1 — для трафика, превысившего это ограничение.
; Листинг 9.13. Активизация механизма CAR с целью классификации тра-v.’-.
' фИКЭV
interface Hssi0/0/0
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.
i Листинг 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
Виртуальные частные сети (VPN) на основе MPLS
Одним из наиболее важных применений технологии MPLS является служба VPN. Несколько удаленных облаков сетей клиента могут подключиться к магистрали поставщика услуг 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-соседями.
Несколько сетей VPN могут использовать одинаковые ПМ-адреса. Примерами таких адресов могут служить частные и незарегистрированные IP-адреса. Пограничный маршрутизатор поставщика услуг должен отличать такие адреса для разных сетей VPN. Для этого определяется новое семейство адресов под названием VPN-IPv4. Адрес VPN-IPv4 представляет собой 12-байтовое значение. В его первых восьми байтах содержится значение отличительного признака маршрута (route distinguisher — RD), в последних четырех байтах —обычный IPv4-aapec. Признак RD используется для обеспечения уникальности частных и незарегистрированных IPv4-aapecoe VPN-сетей в магистрали поставщика услуг. Признак RD состоит из 2-байтового номера автономной системы (autonomous system — AS) и 4-байтового значения, назначаемого поставщиком услуг. VPN-IPv4-aapeca считаются разными семействами адресов и передаются по протоколу BGP с помощью его многопротокольных расширений. В BGP- расширениях информация об отображении метки передается как часть информации о достижении точки назначения на сетевом уровне (Network Layer Reachability Informa-
tion — NLRI). Метка идентифицирует выходной интерфейс, подсоединенный к данному NLRI-префиксу.
Атрибут расширенного сообщества используется для передачи значений идентификатора точки назначения маршрута (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-
напрямую подключенным облаком клиента. VRF назначается для каждого
сети (VPN Routing and
интерфейса VPN-клиента. Облака VPN-клиентов, которые используют одну
Forwarding — VRF)
и ту же информацию о маршрутах, могут быть частью одного экземпляра VRF. Экземпляр VRF идентифицируется по имени и имеет только локальное значение
VPN-IPv4-aflpec
Включает 64-битовый признак RD и 32-битовый IPv4-aflpec
SOO
Идентифицирует облако-источник
RD
64-битовый атрибут, использующийся для уникальной идентификации адресного пространства VPN-сети в магистрали поставщика услуг
RT
64-битовый идентификатор, необходимый для определения маршрутизаторов, которые должны получить маршрут
Практический пример 9.3: MPLS VPN
Обсудим ввод в действие VPN-службы между облаками корпоративного клиента в Сан-Франциско и Нью-Йорке через магистраль поставщика услуг, как показано на рис. 9.8. Облако клиента в Сан-Франциско подключается к локальному маршрутизатору поставщика услуг, а облако клиента в Нью-Йорке — к маршрутизатору поставщика услуг в Нью-Йорке.
VPN-сеть Red
222.222.222.2
Чикаго
25
222.222.222.20/30
POS5/1
HssiO/O
222.222.222.1
222.222.222.3
Нью-Йорк
Сан-Франциско
222.222.222.24/30
222.222.222 16/30
VPN-сеть Red
26
VPN-сеть Red
Рис. 9.8. MPLS VPN
VPN-сеть Green 200.200.1.0/24 200.200.11.0/24
VPN-сеть Green 200.200.2.0/24 200.200.22.0/24
POS0/1
22
14
POS8/2
Облако Нью-Йорка
Облако Сан-Франциско
иип -.
Hssi0/0
POS0/0
10
222.222.222.8/30
POS8/0
CAR
17POS5/3
Даллас
222.222.222.4
222.222.222.12/30
В этом примере обсуждается реализация сетей 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 tins 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
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 HssiO/0
ip route vrf green 200.200.11.0 255.255.255.0 HssiO/0
VRF-экземпляр green сконфигурирован на интерфейсе HssiO/O, который подключен к маршрутизатору клиента в Сан-Франциско. В листинге 9.16 показан RD-признак и интерфейсы, ассоциированные с VRF-экземпляром green.
[ Листинг 9.16. Информация об VRF-экземпляре green ■ ■ .j SanFranciscoish ip vrf green
NameDefault RD .Interfaces
green200:100HssiO/0
В первой части BGP-конфигурации маршрутизатор в Сан-Франциско устанавливает отношение соседства с другими маршрутизаторами магистрали поставщика услуг по протоколу BGP. Для этого используются адреса интерфейса loopbackO, поскольку такие интерфейсы всегда работают и не отключаются.
В следующей части BGP-конфигурации определяются маршруты, принадлежащие VRF-экземпляру green. Такие маршруты могут быть динамически получены с помощью VRF-экземпляра green таких протоколов, как BGP и RlPv2 (Routing Inforamtion
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-lPv4. Экспортные RT-значения передаются в атрибуте расширенного BGP-сообщества. Локальные VRF-маршруты устанавливаются в локальной BGP-таблице VPN-lPv4, если их импортированное 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. Маршруты Сан-Франциско в таблице маршрутизации ■ | jVRF-экземпляра green.. .i
SanFranciscofshow 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
Ml - 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
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-IPv4, которые импортированы в локальную таблицу маршрутизации VRF-экземпляра green при совпадении импортируемого RT-значения 200:2.
( Листинг 9.18. Маршруты BGP VPN-IPv4 Сан-Франциско, принадлежащие j
( * ■< VRF-экземпляруgreen 1 ‘1 ■ . "' -* ’ 1
SanFranciscoish 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
032768 I
*>1200.200.2.0
222.222.222.3
01000 3456 I
*> 200.200.11.0
0.0.0.0
032768 I
*>i200.200.22.0
222.222.222.3
01000 3456 i
Протокол BGP производит обмен привязок меток вместе со своими VPN-lPv4- маршрутами. В BGP-метке указывается локальный выходной интерфейс, через который может быть достигнут маршрут. В листинге 9.19 показаны привязки меток для VPN-IPv4-мapшpyтoв, передаваемых по протоколу BGP.
( Листинг 9.19. Привязки меток для VPN-IPv4-Mapui рутов, передаваемых !,■ по протоколу BGP.■•
SanFranciscoish ip bgp vpn vrf green label
NetworkNext Hop In label/Out label
Route Distinguisher: 200:100 (green)
00.0.0.026/nolabel
0222.222.222.3nolabel/39
00.0.0.027/nolabel
0222.222.222.3nolabel/40
В листинге 9.19 показано, что 39 — это метка маршрутизатора в Нью-Йорке с ID
222.222.222.3, распространенная как привязка метки для маршрута 200.200.2.0. В сле-
дующих нескольких листингах отражен процесс передачи IP-пакета от облака в СанФранциско через сеть поставщика услуг к облаку в Нью-Йорке по адресу 200.200.2.1.
В листинге 9.20 показана информации о продвижении метки для префикса 222.222.222.3.
i Листинг 9.20. Информация о продвижении метки для префикса, I222.222.222.3>'"
SanFrancisco#show mpls forwarding-table 222.222.222.3
Local Outgoing PrefixBytes mpls Outgoing Next Hop
label label or VC or Tunnel Id switched interface
3637222.222.222.3/32 0Po5/3 point2point
30222.222.222.3/32 7161Po5/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 ' Д
Chicagofsh mpls forwarding-table 222.222.222.3 32
Local Outgoing PrefixBytes 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. Отладочная информация, в которой отражен процесс " I )коммутации MPLS-пакета от облака клиента5 J
}в Сан-Франциско до облака клиента в Нью-Йорке
гс адресом 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.
I Листинг 9.23. Таблица продвижения меток маршрутизатора Нью-Йорка для VRF-экземпляра green
NewYorkish mpls forwarding-table vrf green
Local Outgoing PrefixBytes mpls Outgoing Next Hop
label label or VC or Tunnel Id switched interface
39Unlabelged 200.200.2.0/24[V] 520Hs0/0point2point
40Unlabelged 200.200.22.0/24[V] 0HsO/0point2point
Исходя из информации о продвижении меток маршрутизатор Нью-Йорка удаляет входящую метку 39 и отправляет пакет через интерфейс HssiO/O, подключенный к облаку в Нью-Йорке. Это действие отображено в листинге 9.24 с помощью команд отладки, выполненных на маршрутизаторе Нью-Йорка.
Листинг 9.24. Отладочная информация, в которой отражен процесс. i коммутации MPLS-пакета на адрес 200.200.2.1|
.. маршрутизатором Нью-Йорка ,^ г ; :; j:,•
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
tins routing I ।
interface LoopbackO
ip address 222.222.222.3 255.255.255.255
ip router isis isp
interface POS8/0
ip address 222.222.222.9 255.255.255.252
ip router isis isp
mpls ip
interface HssiO/0
ip vrf forwarding green
ip address 222.222.222.37 255.255.255.252
ip router isis isp mpls ip
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
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
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 облака СанФранциско сконфигурированы статически.
Качество обслуживания в сетях 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 Information 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 поставщика услуг.
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 QoSWFQnWRED
3
Маршрутизатор на выходе из сети MPLS VPN
Поле CoS из MPLS метки копируется в поле IP-приоритета в заголовке IP-пакета
4
Маршрутизатор на выходе из сети MPLS VPN
Механизм CAR ограничивает исходящий трафик на интерфейсе пограничного маршрутизатора поставщика услуг, подключенном к конечному маршрутизатору клиента, на основе функции CDR
Как показано на рис. 9.9, поставщик услуг использует механизмы CAR и CDR на каждом порту доступа. Поставщик услуг настраивает сеть таким образом, чтобы порты доступа работали на скоростях CAR и CDR. Любой трафик, превысивший согласованную скорость передачи, отбрасывается с большей вероятностью по сравнению с согласованным трафиком.
CDRCDRMPLS CoSMPLS CoSCDRCDRVPN Green ;VPN Green ;Согласованная скорость доставки (Committed Delivery Rate — CDR)Согласованная скорость доставки (Committed Delivery Rate — CDR)Поставщик услуг CAR MPLS VPNПоставщик услуг CAR MPLS VPNИспользование механизмовИспользование механизмовWFQ/WRED на основеWFQ/WRED на основебитов поля CoSбитов поля CoSСогласованная скорость доступа (Committed Access Rate — CAR)Согласованная скорость доступа (Committed Access Rate — CAR)Облако 1Облако 1Рис. 9.9. Дифференцированные QoS-услуги сети MPLS VPNРис. 9.9. Дифференцированные QoS-услуги сети MPLS VPNyPN,GreenyPN,Green
CDR
CDR
MPLS CoS
MPLS CoS
CDR
CDR
VPN Green ;
VPN Green ;
Согласованная скорость доставки (Committed Delivery Rate — CDR)
Согласованная скорость доставки (Committed Delivery Rate — CDR)
Поставщик услуг CAR MPLS VPN
Поставщик услуг CAR MPLS VPN
Использование механизмов
Использование механизмов
WFQ/WRED на основе
WFQ/WRED на основе
битов поля CoS
битов поля CoS
Согласованная скорость доступа (Committed Access Rate — CAR)
Согласованная скорость доступа (Committed Access Rate — CAR)
Облако 1
Облако 1
Рис. 9.9. Дифференцированные QoS-услуги сети MPLS VPN
Рис. 9.9. Дифференцированные QoS-услуги сети MPLS VPN
yPN,Green
yPN,Green
Согласованные пакеты в правильно сконфигурированной сети MPLS VPN доставляются с высокой вероятностью, сравнимой с надежностью механизма C1R в сетях Frame Relay.
Гарантированные услуги QoS
Для обеспечения гарантированных услуг QoS требуется сквозное использование протокола RSVP во всех VPN-облаках, подключенных посредством магистрали поставщика услуги, на всем пути от источника до точки назначения. Размеры области и уровень гарантированных услуг QoS зависят от того, какая часть сети производит явное резервирование ресурсов с помощью сообщений RSVP PATH. Мы обсудим три уровня реализации гарантированных услуг QoS в следующих разделах этой книги. В основном они отличаются предлагаемым поставщиком услуг VPN качеством обслуживания (рис. 9.10).
Поставщик услуг 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-пакеты с данными.
Таким образом, трафик, для которого были зарезервированы ресурсы, получает более высокий уровень обслуживания без участия поставщика услуг, которому в этом случае не нужно производить резервирование ресурсов отдельно для каждого клиента своей сети.
Сквозная гарантированная полоса пропускания
Туннели с гарантированной полосой пропускания (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
S>exceed-action set-mpls-exp-transmit 1
rate-limit output 1000000 8000 8000
4>conform-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-облако.
Важная область применения технологии 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.
Часть
III
Управление трафиком
2
В этой части
Глава 10. Управление трафиком в сетях MPLS
В этой главе... гчл лч".., л-^ '
Оверлейная модель канального уровня , =>278
Маршрутизация на основе резервирования ресурсов (RRR)279
Определение ТЕ-транкач,-280
Атрибуты ТЕ-гуннеля’281
Атрибуты ресурсов канала г':<;283
Распространение информации о ресурсах канала .... ^284
Политика выбора пути W.^'284
Установка ТЕ-туннеля р^,.7285
р Управление доступом к каналу.S 286
Поддержка ТЕ-пути*7"286
Сигнальный протокол ТЕ-RSVP287
Расширения протокола маршрутизации внутреннего шлюза *" 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-пути, используются для управления трафиком, а метки — для передачи данных
по явному пути, отличающемуся от того, который получается в результате передачи пакетов на основе адреса пункта назначения.
На сегодняшний день решение, основанное на использовании механизма 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. Оверлейная модель канального уровня для механизма управления трафикомРис. 10.1. Оверлейная модель канального уровня для механизма управления трафикомПолное объединениена сетевом уровне
Рис. 10.1. Оверлейная модель канального уровня для механизма управления трафиком
Рис. 10.1. Оверлейная модель канального уровня для механизма управления трафиком
Для трафика, идущего от маршрутизатора А к маршрутизатору В, облако канального уровня предоставляет три физических пути: А'=>11::>4'=>В, А1^ 11=>2,=>31=>41::> В и АсИсЭб^'^^В. Однако реальный путь, по которому пойдет IP-трафик, уже предопределен коммутаторами канального уровня. Использование явного транзитного
уровня позволяет точно управлять используемой трафиком полосой пропускания такими методами, которые на данный момент невозможно применить, изменяя метрики маршрутов на сетевом уровне.
В больших полносвязных сетях затраты на поддержание инфраструктуры очень высоки. Для таких сетей также присуща проблема масштабируемости использующегося протокола маршрутизации внутреннего шлюза, например OSPF или IS-IS, так как стандартный механизм лавинообразного распространения информации о маршрутах неэффективен в больших полносвязанных окружениях.
Маршрутизация на основе резервирования ресурсов (RRR)
Такие протоколы маршрутизации, как OSPF и IS-IS, продвигают трафик с помощью информации о топологии сети и метриках каналов. В дополнение к информации, предоставляемой протоколом маршрутизации, механизм RRR передает IP-пакет с учетом класса трафика, требования к обслуживанию и наличия доступных сетевых ресурсов.
На рис. 10.2 показаны два пути от Сан-Франциско до Нью-Йорка через сеть поставщика услуг: один — через Даллас, а другой — через Чикаго.
Рис. 10.2. ТЕ-туннель от маршрутизатора в СанФранциско к маршрутизатору в Нью-Йорке
Поставщик услуг заметил, что трафик от Сан-Франциско до Нью-Йорка обычно передается по пути Сан-Франциско^Чикаго^Нью-Йорк. Однако в определенное время этот путь становится сильно перегруженным. Было также замечено, что во время периода перегрузки пути от Сан-Франциско до Нью-Йорка через Чикаго путь от Сан-Франциско до Нью-Йорка через Даллас практически не используется. Необходимо отрегулировать движение трафика так, чтобы свободные сетевые ресурсы использовались наилучшим образом. В настоящий момент передача трафика между Сан-Франциско и Нью-Йорком является крайне неоптимальной, так как в определенное время сеть не может использовать альтернативный путь между этими двумя узлами. Подобный сценарий является типичным примером применения механизма управления трафиком (ТЕ). Более детально работа механизма ТЕ в сети MPLS рассматривается в практическом примере 10.1.
После небольшого анализа трафика, становится ясно, что если весь трафик, который направляется из Сан-Франциско в Нью-Йорк, во время периода пере-
грузки будет передаваться по пути через Даллас, а не через Чикаго, то оба пути будут использоваться наиболее оптимально. Следовательно, между СанФранциско и Нью-Йорком устанавливается ТЕ-туннель. Он называется туннелем, потому что путь, по которому идет трафик, определяется на маршрутизаторе в Сан-Франциско, а не является результатом поэтапного принятия решения о выборе маршрута. В обычных условиях туннель проходит через Чикаго. Однако во время перегрузки в Чикаго ТЕ-путь меняется на путь через Даллас. Таким образом, в результате применения механизма ТЕ осушествляется оптимальное использование свободных сетевых ресурсов и, в то же время, обход точек перегрузки. Механизм ТЕ может быть настроен таким образом, что ТЕ-путь будет опять изменен на путь через Чикаго после того, как освободится достаточное количество сетевых ресурсов.
Механизм RRR ТЕ предполагает определение транка трафика, требований к ресурсам, политики туннеля, а также способа вычисления или спецификации явного пути, по которому будет прокладываться ТЕ-туннель. В нашем примере транком трафика является трафик, идущий от Сан-Франциско в Нью-Йорк, требования к ресурсам — это полоса пропускания ТЕ-туннеля и другие политики, а явный путь — это путь от Сан-Франциско в Нью-Йорк через Даллас.
Операционная модель работы механизма RRR показана на рис. 10.3. Здесь изображены различные рабочие блоки механизма ТЕ в форме блок-схемы. В следующем разделе каждая из приведенных функций будет рассмотрена более подробно.
Примечание
Перед внедрением механизма ТЕ в сети очень важно создать профили шаблонов потоков трафика и собрать статистику в нескольких точках сети. Это можно сделать с помощью автономных средств и методов, не рассматриваемых в данной книге. В результате вы должны получить модель трафика с максимальным использованием ресурсов сети.
Определение ТЕ-транка
ТЕ-транк (ТЕ trunk) определяет класс пакетов, передающихся по ТЕ-туннелю. Это локальная политика для головного маршрутизатора, инициирующего создание ТЕ-туннеля.
Как уже упоминалось в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика", класс трафика определяется по заголовкам протоколов TCP/IP (Transmission Control Protocol/Internet Protocol — протокол управления передачей/1п1егпе1-протокол). Класс трафика может основываться на одном параметре, например на IP-адресе точки назначения или MPLS-поле класса обслуживания (Class of Service — CoS), а также на нескольких параметрах, примером чему может служить класс FTP-трафика, передающегося от заданного отправителя к заданному получателю. В соответствии с механизмом RRR все пакеты трафика одного класса передаются через сеть по специально указанному или динамически определенному пути. Именно поэтому классы RRR- трафика также называют трайками трафика (traffic trunks).
Рис. 10.3. Операционная модель работы механизма ТЕ
Атрибуты ТЕ-туннеля
ТЕ-туннель имеет определенные атрибуты, описывающие требования транка трафика, от которых зависит выбор административных политик. Атрибуты туннеля рассматриваются далее в этой главе.
Полоса пропускания
Атрибут полосы пропускания (bandwidth) определяет сквозную полосу пропускания, необходимую для ТЕ-туннеля. Ее выбор основан на требованиях класса трафика, который передается по ТЕ-туннелю.
Приоритет установки и удержания
Приоритеты установки (setup priority) и удержания (holding priority) используются при управлении доступом. Приоритет установки определяет приоритет ресурса.
Когда ресурсы находятся в состоянии конфликта (contention), новый туннель с высоким приоритетом получения ресурса может вне очереди занять свободный ресурс, вытесняя при этом все установленные туннели в пути, приоритет удержания которых меньше приоритета получения ресурса нового туннеля. Установленный ТЕ-туннель с наивысшим приоритетом удержания не может быть вытеснен.
В табл. 10.1 показаны следствия установки низких и высоких значений приоритетов получения и удержания ресурса для ТЕ-туннеля.
Таблица 10.1. Следствия установки низких и высоких значений приоритетов’ ] получения и удержания ресурса для ТЕ-туннеля/. q
Высоксз значение
Низкое значение
Приоритет получения ресурса
Часто приводит к вытеснению установленных ТЕ-туннелей (вытесняющий (preemptor) туннель)
Редко приводит к вытеснению установленных ТЕ-туннелей (невытесняющий (nonpreemptor) туннель)
Приоритет удержания ресурса
Редко может быть вытеснен только что установленным ТЕ-туннелем (невытесняемый (nonpreemptable) туннель)
Часто может быть вытеснен только что установленным ТЕ-туннелем (вытесняемый (preemptable) туннель)
Родственность класса ресурса
Атрибут родственности класса ресурса (resource class affinity) предоставляет возможность ограничивать выбор пути административным включением в сеть определенных каналов или исключением их из сети. Атрибут родственности класса ресурса состоит из 32-битового атрибута родственности ресурса и 32-битовой маски класса ресурса. Атрибут родственности ресурса (resource affinity) указывает на необходимость включения в процесс расчета пути определенного канала или его исключения из процесса. Каждый канал имеет атрибут класса ресурса, равный по умолчанию 0x00000000 (если он не определен явным образом). Маска класса ресурса (resource class mask) используется для выделения нужного набора битов атрибута класса ресурса канала. Класс ресурса, маска класса ресурса и атрибут родственности класса ресурса соотносятся друг с другом следующим образом.
Класс ресурса & маска класса ресурса == родственность класса ресурса,
где “&” обозначает побитовую операцию логического И, а “==” —побитовое логическое равенство.
В табл. 10.2 приведена политика включения или исключения канала из процесса определения пути для ТЕ-туннеля на базе атрибутов ресурсов.
i Таблица 10.2. Политика включения или исключения канала из процесса # • ;
определения пути для
ТЕ-туннеля .., j
Атрибут класса
Атрибут родственности класса
Политика включения канала в возможный путь
ресурса канала
ресурса ТЕ-туннеля
ТЕ-туннеля или исключения канала из него
Маска класса Атрибут ресурсародственности
ресурса
1
11
Явное включение
0
10
Явное исключение
1 или 0
00
Никаких действий не предпринимается
Порядок выбора пути
Атрибут порядка выбора пути (path selection order) определяет порядок, в котором пограничный маршрутизатор выбирает явные пути для ТЕ-туннелей. Явный путь (explicit path) — это исходный маршрут, представляющий собой последовательность IP-адресов, заданную административным способом либо динамически вычисленную на основе кратчайшего пути с учетом различных ограничений. В атрибуте порядка выбора пути указывается порядок, в котором административно заданный или динамически полученный путь используется для установки ТЕ-туннеля.
Адаптируемость
В атрибуте адаптируемости (adaptability) определяется, нужно ли повторно оптимизировать существующий ТЕ-туннель в случае, если появился лучший путь. Повторная оптимизация обсуждается далее в этой главе.
Устойчивость
В атрибуте устойчивости (resilience) определяется желаемое поведение системы в случае прекращения существования текущего пути ТЕ-туннеля. Это обычно происходит из-за сбоев в сети или вытеснения туннеля. Восстановление ТЕ-туннеля в указанном случае рассматривается далее в этой главе.
Атрибуты ресурсов канала
Все каналы в RRR-сети описываются атрибутами, в которых содержится информация о свободных ресурсах и о политиках использования канала для вычисления RRR-пути.
Доступная полоса пропускания
В атрибуте доступной полосы пропускания (available bandwidth) указывается ширина свободной полосы пропускания для каждого приоритета получения ресурса. Доступная полоса пропускания в действительности может и не существовать. Так, в определенных ситуациях сетевой оператор завышает пропускную способность канала, задав ей значение, большее, чем реальная ширина полосы пропускания.
Примечание
Свободная полоса пропускания для большего значения приоритета получения ресурса всегда должна превышать значение, используемое для меньшего значения приоритета получения ресурса или быть равной ему.
Класс ресурса
Атрибут класса ресурса (resource class) “окрашивает" канал. Как было сказано ранее в этой главе, решение о включении канала в процесс вычисления пути или об исключении канала из него основывается на атрибуте класса ресурса канала и на атрибуте родственности класса туннеля.
Распространение информации о ресурсах канала
Важным требованием для -введения в действие механизма управления трафиком является распространение локальной информации о ресурсах каналов по RRR-сети. Атрибуты ресурсов канала лавинообразно распространяются по сети с помощью расширений таких протоколов маршрутизации состояния канала, как OSPF и IS-IS.
Существующий протокол маршрутизации канального уровня лавинообразно распространяет информацию о метрике и топологии сети по всем каналам, для того чтобы обеспечить вычисление кратчайшего пути до точки назначения. В RRR-сети используется расширенный протокол маршрутизации, который вместе с информацией о метрике распространяет по каждому каналу атрибуты ресурсов.
Лавинообразное распространение атрибутов ресурсов происходит независимо от распространения информации о метрике и предпринимается только тогда, когда изменяется состояние канала или класс ресурса канала, а также когда ширина свободной полосы пропускания превысила заранее сконфигурированное пороговое значение.
Политика выбора пути
ТЕ-путь должен учитывать как ограничения канала, так и требования ТЕ-туннеля. При вычислении ТЕ-пути производятся такие действия.
Шаг 1. Рассматриваются следующие атрибуты и информация:
атрибуты ТЕ-туннеля, установленные головным маршрутизатором, создающим этот туннель;
атрибуты ресурсов каналов всей сети, которые распространяются с помощью протокола внутреннего шлюза;
информация о топологии сети, которая распространяется с помощью протокола внутреннего шлюза;
если производится повторная оптимизация ТЕ-туннеля, то рассматривается его текущий путь.
Шаг 2. Удаляются каналы с недостаточной пропускной способностью или несоответствующие политике ресурсов.
Шаг 3. После удаления всех ^рассматриваемых каналов, запускается отдельная копия алгоритма выбора кратчайшего пути (Shortest Path First — SPF) для вычисления кратчайшего (с наименьшей метрикой) пути из базы состояний каналов протокола внутреннего шлюза.
Копия алгоритма SPF запускается специально для вычисления ТЕ-пути, и она отличается от копии алгоритма, которая используется маршрутизатором для построения своей таблицы маршрутизации на основе базы состояний каналов.
Явный путь для ТЕ-туннеля вычисляется с помощью алгоритма SPF. Вычисленный явный путь представляется как последовательность, состоящая из IP-адресов маршрутизаторов. После запроса на установление ТЕ-туннеля последний создается с использованием явного пути на основе атрибута порядка выбора.
Установка ТЕ-туннеля
Для сигнализации ТЕ-туннеля используется протокол ТЕ-RSVP. В нем применяются те же RSVP-сообщения, что и в обычном сигнальном протоколе, но с небольшими изменениями и расширениями, необходимыми для поддержки нового способа применения протокола. Протокол ТЕ-RSVP помогает создать явно маршрутизируемый LSP-путь для установки ТЕ-туннеля.
В протокол ТЕ-RSVP добавлены две важные функциональные возможности, которые позволяют ему создавать явно маршрутизируемый LSP-путь (Explicitly Routed Label Switched Path — ER-LSP): метод привязки меток к RSVP-потокам и функция явной маршрутизации RSVP-сообщений. В ТЕ-туннеле, построенном на основе ERLSP-пути, единственным отправителем является первый узел в 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 следующему узлу по направлению к отправителю. Именно эту метку узел рассчитывает получить вместе со всем трафиком, поступающим по этому пути.
Примечание
Сообщение RSVP RESV следует по пути, прямо противоположному пути, по которому шло сообщение RSVP РАТК. Это связано с тем, что объект SRO в блоке состояния пути (установленный в каждом узле РАТН-сообщением) определяет способ передачи сообщения RSVP RESV вверх по направлению движения потока трафика.
После того как путь ER-LSP сформирован, устанавливается ТЕ-туннель. Следует заметить, что если трафик доставляется без гарантий, то резервирование ресурсов производить необязательно. Для того чтобы распределить ресурсы на ER-LSP-пути, используются обычные RSVP-объекты Tspec и Rspec. Tspec-объект отправителя, содержащийся в РАТН- сообщении, используется для определения трафика, который передается по этому пути. Точка назначения сообщения RSVP PATH использует эту информацию для создания соответствующих объектов Tspec и Rspec получателя, которые используются при распределении ресурсов на каждом узле ER-LSP-пути.
Управление доступом к каналу
Система управления доступом к каналу решает, какому из ТЕ-туннелей следует предоставить ресурсы. Она предполагает наличие следующих функций.
Определение наличия ресурсов. Система определяет, есть ли свободные ресурсы.
Уничтожение туннеля. Система должна уничтожить существующие туннели, когда новые туннели с высоким приоритетом получения ресурсов вытесняют существующие туннели с низким приоритетом удержания ресурсов.
Ведение локального учета использования ресурсов. Система следит за использованием ресурсов.
Инициирование обновления информации о маршрутах протокола внутреннего шлюза. Система инициирует процесс лавинообразного распространения обновления информации о маршрутах протокола внутреннего шлюза, когда из статистики локального учета использования ресурсов следует, что количество доступных ресурсов может опуститься ниже сконфигурированного порогового значения.
Поддержка ТЕ-пути
Поддержка ТЕ-пути включает выполнение таких функций, как повторная оптимизация пути и его восстановление. Эти операции выполняются после установки ТЕ- туннеля. Повторная оптимизация пути (path reoptimization) описывает желаемое поведение маршрутизатора в случае появления после установки ТЕ-пути его потенциально лучшего преемника. Во время повторной оптимизации пути маршрутизатор должен попытаться найти какую-нибудь возможность для того, чтобы заново оптимизировать существующий ТЕ-путь. Необходимость применения функции повторной оптимизации пути указывается в атрибуте адаптируемости.
Восстановление пути (path restoration) описывает метод восстановления ТЕ-туннеля в случае, если текущий путь перестал функционировать, используя для этого атрибут устойчивости.
Сигнальный протокол 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.3
RSVP-объект
RSVP-сообщение
Назначение
Sender_Template
PATH
Объекты Sender_Template и
Filter_Spec
RESV
Filter_Spec могут переносить идентификатор туннеля, что позволяет определить ER-LSP-путь
Расширения протокола маршрутизации внутреннего шлюза
Протоколы маршрутизации внутреннего шлюза OSPF и IS-IS были расширены для распространения атрибутов ресурсов канала вместе с информацией об 1Р-достижимости сетевого уровня. Для передачи информации о ресурсах канала протокол IS-IS использует новый кортеж, состоящий из поля типа (Туре), длины (Length) и значения (Value) и обычно известный как кортеж TVL, а протокол OSPF — непрозрачное извещение о состоянии канала (Opaque Link State Advertisement — LSA). Следует отметить, что существующая функциональность протоколов OSPF и IS-IS осталась прежней, только теперь эти протоколы отправляют информацию о текущих ограничениях каждый раз, когда им необходимо распространить информацию об IP-достижимости. Механизм управления доступом к ТЕ- каналу маршрутизатора требует повторного распространения информации об ограничениях всякий раз, когда он замечает существенные изменения в информации о доступных ресурсах, основываясь на сконфигурированных пороговых значениях.
Модификации протокола IS-IS
Кортеж TLV, определяющий IS-достижимость, расширен для передачи информации о ресурсах канала. Расширенный кортеж TLV называется кортежем TLV типа 22. Внутри этого кортежа используются различные подкортежи TLV, предназначенные для передачи атрибутов канала с целью поддержки механизма управления трафиком.
Модификации протокола OSPF
Поскольку базовое LSA-объявление маршрутизатора протокола OSPF является нерасширяемым, для поддержки механизма управления трафиком используется непрозрачное LSA-объявление. Существует три типа непрозрачного LSA-объявления, каждое из которых характеризуется своей собственной областью лавинообразного распространения. OSPF-расширения для обеспечения поддержки механизма ТЕ используют только LSA-объявления типа 10, распространение которых ограничено одной областью.
Новый тип непрозрачного LSA-объявления (тип 10), обеспечивающего поддержку механизма ТЕ, называется объявлением ГЕ £5/1. В этом LSA-объявлении описываются маршрутизаторы и двухточечные каналы (так же, как в объявлении LSA маршрутизатора). Для описания каналов с множественным доступом хватает существующего объявления LSA сети, а поэтому для этой цели не было определено никаких дополнительных LSA- обьявлений.
Подходы к реализации механизма управления трафиком
Пример, рассмотренный в начале этой главы, является типичным подходом к реализации механизма ТЕ, в соответствии с которым управление трафиком сводится к обходу точек перегрузки сети. Следует отметить, что ограничение механизма ТЕ до переключения между несколькими маршрутами может не оправдать себя в том случае, если остальной трафик в сети будет передаваться без участия механизма ТЕ.
Широко рекомендуемым подходом является использование полносвязной структуры из созданных на основе LSP-путей ТЕ-туннелей между всеми пограничными маршрутизаторами в сети поставщика услуг. Как правило, этими пограничными маршрутизаторами являются либо РОР-марщрутизаторы (Point of Presence — точка присутствия), либо маршрутизаторы, соединенные с сетями других поставщиков услуг.
Практический пример 10.1: установка
и функционирование ТЕ-туннеля в MPLS-сети
В сети, схематически показанной на рис. 10.4, устанавливается MPLS ТЕ-туннель от Сан-Франциско до Нью-Йорка на базе явного пути и динамически определяемого резервного пути. Укажите конфигурацию, необходимую для установки такого туннеля, для всех маршрутизаторов сети. Исследуйте, что произойдет, если один из каналов явного пути выйдет из строя. И, наконец, изучите процесс восстановления пути ТЕ-туннеля в случае, когда установленный динамический путь прекратит функционирование.
222.222.222.2222.222.222.2ЧикагоЧикаго222.222.222.1Сан-Франциско222.222.222.1Сан-Франциско2525POS0/3POS0/3222.222.222.24/30222.222.222.24/301717POS9/2POS9/22828POS0/0POS0/0222.222.222.8/30POS8/0222.222.222.8/30POS8/0POS0/1 222.222.222.20/30POS5/1 21POS0/1 222.222.222.20/30POS5/1 21POS9/0POS9/0POS9/1POS9/1222.222.222.3Нью-Йорк222.222.222.3Нью-ЙоркДаллас 222.222.222.4Даллас 222.222.222.4Рис. 10.4. MPLS ТЕ-туннель от маршрутизатора Сан-Франциско до маршрутизатора Нью-ЙоркаРис. 10.4. MPLS ТЕ-туннель от маршрутизатора Сан-Франциско до маршрутизатора Нью-ЙоркаPOS5/3222.222.222.16/30POS5/3222.222.222.16/3014
222.222.222.2
222.222.222.2
Чикаго
Чикаго
222.222.222.1
Сан-Франциско
222.222.222.1
Сан-Франциско
25
25
POS0/3
POS0/3
222.222.222.24/30
222.222.222.24/30
17
17
POS9/2
POS9/2
28
28
POS0/0
POS0/0
222.222.222.8/30
POS8/0
222.222.222.8/30
POS8/0
POS0/1 222.222.222.20/30
POS5/1 21
POS0/1 222.222.222.20/30
POS5/1 21
POS9/0
POS9/0
POS9/1
POS9/1
222.222.222.3
Нью-Йорк
222.222.222.3
Нью-Йорк
Даллас 222.222.222.4
Даллас 222.222.222.4
Рис. 10.4. MPLS ТЕ-туннель от маршрутизатора Сан-Франциско до маршрутизатора Нью-Йорка
Рис. 10.4. MPLS ТЕ-туннель от маршрутизатора Сан-Франциско до маршрутизатора Нью-Йорка
POS5/3
222.222.222.16/30
POS5/3
222.222.222.16/30
POS8/2
222.222.222.12/30
Обсудите функционирование ТЕ-туннеля и ТЕ-расширений протоколов IS-IS и RSVP на основе различных show- и debug-команд маршрутизатора.
Все четыре маршрутизатора сконфигурированы согласно адресной схеме и схеме соединений, показанным на рис. 10.4. В качестве протокола внутреннего шлюза использовался встроенный протокол IS-IS. Он настроен на использование 32-битовых значений метрики, в отличие от обычных 6-битовых значений. IP-адрес интерфейса loopbackO используется в качестве идентификатора маршрутизатора для механизма MPLS ТЕ.
Для активизации механизма MPLS ТЕ необходимо выполнить команду mpls trafiic- 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
tins 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
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
i Листинг 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 POS0/1
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
router isis isp
net 50.0000.0000.0000.0002.00
metric-style wide
mpls traffic-eng router-id LoopbackO
mpls traffic-eng level-1
—7 ^__?;„.^: ^^r^
Листинг 10.3. Конфигурация маршрутизатора Нью-Йорка
.^^^d^Lffisisd^jk-^-jii^^J!^^1,1’, *—. 5 **
interface LoopbackO
ip address 222.222.222.3 255.255.255.255
ip router isis isp
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 i
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 Листингу 0.4. Конфигурация маршрутиз^ра^
tins 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 P0S9/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 был записан маршрут, по которому проложен туннель.
I Листинг 10.5. Результат выполнения команды show mpls traffic-eng tunnel I ■, tunnelO при условии прохождения туннеля■ <>!
.по административно заданному явному пути,^/.
SanFranciscoish mpls tr tun tO
Name: SanFrancisco_tO(TunnelO)
^Destination: 222.222.222.3
Status: Admin: upOper: 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 маршрутизатора Чикаго.
Такая локальная смена атрибута на маршрутизаторе Чикаго делает явный путь непригодным для использования, поскольку он не пройдет тест на родственность ресурсов.
Следовательно, ТЕ-туннель должен быть проложен по динамически выбираемому пути. После выбора динамического пути маршрутизатор удаляет канал Чикаго-Нью- Йорк из топологии сети, пользуясь своей локальной политикой ресурсов канала. Маршрутизатор повторно рассчитывает путь ТЕ-туннеля через Даллас, запустив для этого отдельную копию алгоритма SPF.
В листинге 10.6 показан результат выполнения команды show mpls traffic-eng tunnel tunnelO после того, как туннель был проложен по динамическому пути через маршрутизатор Далласа.■
I Листинг 10.6. Результат выполнения команды show mpls trafflc-eng tunnel
I ;' tunnelO после того, как туннель был проложен.., ■ '•. -'
по динамическому пути через маршрутизатор Далласа ‘'
SanFranciscotsh mpls tr tun tO
Name: SanFrancisco_tO(TunnelO)
^Destination: 222.222.222.3
Status:
Admin: upOper: 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: 10Priority: 7 7 Affinity: OxO/OxFFFF
AutoRoute: enabledLockDown: 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.7 показан результат выполнения команды show mpls traffic-eng tunnel tunnelO после того, как туннель был проложен по динамическому пути через маршрутизаторы Чикаго и Далласа до маршрутизатора Нью-Йорка.
Листинг .10.7, Результат выполнения команды show mpls traffic-eng tunnel tunne/O на маршрутизаторе Сан-Франциско после того, -. ^js ^■Ыт^^^»*®* туннель был проложен по динамическому пути через , ^В|||^ 1 ^;маршрутизат6рыЧикаго й Далласа до маршрутизатора!!.^^ M'^yv -’• " ftgjgsjjpf^ij^^^'1У у ^^Ш$
SanFranciscoKsh mpls traffic-eng tunnel tO
Name: SanFrancisco_tO(TunnelO)
^Destination: 222.222.222.3
Status:
Admin: upOper: up Path: valid
^Signalling: connected
path option 2, type dynamic (Basis for Setup, 4jpath weight 30)
path option 1, type explicit sfny
Config Paramters:
Bandwidth: 10Priority: 7 7 Affinity: OxO/OxFFFF
AutoRoute: enabledLockDown: disabled
InLabel : -
OutLabel : POS5/0, 26
RSVP Signalling Info:
Src 222.222.222.1, Dst 222.222.222.3, Tun_Id 0, 4jTun_Instance 2
RSVP Path Info:
My Address: 222.222.222.1
Explicit Route: 222.222.222.22 222.222.222.26
4j222.222.222.14 222.222.222.3
Record Route:
Tspec: ave rate=10 kbits, burst=1000 bytes, 4>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#
Из результата выполнения предыдущей команды видно, что путь ТЕ-туннеля до Нью-Йорка установлен через маршрутизаторы Чикаго и Далласа.
> Чтобы больше узнать о том, как работает MPLS ТЕ-туннель, просмотрите листинг 10.8. В нем показана важная часть результата выполнения команды show interface tunnel 0. Для проверки установленных ТЕ-туннелей также может быть использована команда show isis mpls traffic tunnel. Результат выполнения этой команды показан в листинге 10.9.
Листинг 10.8. Резул ьтатвыполнениякоманды show Interface tunnelO
SanFranciscotsh 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,
^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 IdTunnel NameBandwidthNexthop
4> Metric Mode NewYork.OOTunnelO100000222.222.222.3
В листингах 10.10 и 10.11 используются команды, которые демонстрируют работу протокола IS-1S с ТЕ-расширениями. Протокол 1S-IS с ТЕ-расширениями не только предоставляет информацию о топологии сети и метриках каналов, но также передает ТЕ-атрибуты всех каналов в сети. В листинге 10.10 показан результат выполнения команды, показывающей MPLS ТЕ-атрибуты всех каналов с активизированным протоколом MPLS на маршрутизаторе Чикаго с идентификатором 222.222.222.2.
Листинг 10.10. Вывод атрибутов'механизма управления трафиком'для'*;v-
max_link_bw:1544 max_link_reservable: 1158
allocated
reservable
allocated
reservable
bw[0J: 0
1158
bw[l]: 0
1158
bw[2J: 0
1158
bw[3]: 0
1158
bw[4]: 0
1158
bw[5]: 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:
1>222.222.222.21
admin_weight:10, affinity_bits:0x0
max link bw:1544 max link reservable: 1158
allocated
reservable
allocated
reservable
bw[0J: 0
1158
bw[l]: 0
1158
bw[2]: 0
1158
bw[3]: 0
1158
bw[4]: 0
1158
bw[5]: 0
1158
bw[6]: 0
1158
bw[7]: 0
1158
link[2 ]:Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:4
Intf Address:222.222.222.10, Nbr Intf Address: 4>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[2J: 0
1158
bw[3]: 0
1158
bw[4]: 0
1158
bw[5]: 0
1158
bw[6]: 0
1158
bw[7]: 0
1158
SanFrancisco#
Каждый маршрутизатор, участвующий в процессе управления трафиком, объявляет свои собственные атрибуты каналов для остальной части сети с помощью IS-IS- расширений. Для просмотра атрибутов, объявленных маршрутизатором, используется команда show isis mpls traffic-eng advertise. В листинге 10.11 показан результат выполнения этой команды на маршрутизаторе Сан-Франциско.
ГЛ истинг10.11. ТЕ-атрибуты, объявленные маршрутизатором Сан-Франциско I
SanFrancisco#sh isis mpls traffic-eng advertise
System ID: SanFrancisco.00
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
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 unreserved[l]: 4>1158000 bits/sec
BW unreserved!2]: 1158000 bits/sec, BW unreserved[3]: 4>1158000 bits/sec
BW unreserved!4]: 1158000 bits/sec, BW unreserved!5]: 4>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 unreserved[l]: 4>1158000 bits/sec
BW unreserved[2]: 1158000 bits/sec, BW unreserved[3]; 4>1158000 bits/sec
BW unreserved[4]: 1158000 bits/sec, BW unreserved[5]: 4>1158000 bits/sec
BW unreserved[6]: 1158000 bits/sec, BW unreserved!7]: 4>1158000 bits/sec
Affinity Bits: 0x00000001
SanFrancisco#
По умолчанию функционирующий ТЕ-туннель не устанавливается в таблицу маршрутизации и не объявляется протоколом 1S-1S. Для установки MPLS-туннеля в таблицу маршрутизации и его объявления с помощью протокола IS-IS используется команда tunnel mpls taffic-eng autoroute announce. В листинге 10.12 показан результат выполнения команды show ip route до и после выполнения команды autoroute announce.
А° и пос^ У^а^овки туннеля^ табл^ф^щ^ , ,;i
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
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
SanFrancisco#sh 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 . >
SanFrancisco#sh 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
aZL^Ja^K!!^3^^
SanFrancisco#sh mpls forwarding-table 222.222.222.3 32 detail
Local Outgoing PrefixBytes mpls Outgoing
1> Next Hop label label or VC or Tunnel Id switched interface
Tun hd Unlabeled 222.222.222.3/32 0TuO
t> point2point
MAC/Encaps=4/8, MTU=1500, Label Stack{26), via POS5/1 0F008847 OOO1AOOO
Chicago#sh mpls forwarding-table
Local Outgoing PrefixBytes mpls Outgoing
1> Next Hop
label label or VC or Tunnel Id switchedinterface
2630222.222.222.1 0 [1] 0POSO/3
^ point2point
Chicago#
Dallas#sh mpls forwarding-table
Local Outgoing PrefixBytes mpls Outgoing
1> Next Hop
label label or VC or Tunnel Id switchedinterface
30 Pop label 222.222.222.1 0 [1] 0 POS9/1
^ point2point
На рис. 10.5 показан процесс коммутации пакетов на пути ТЕ-туннеля. Маршрутизатор Сан-Франциско назначает метку 26 всему трафику, передающемуся в (или через) пункт назначения туннеля, и отправляет его через интерфейс POS5/1. Маршрутизатор Чикаго получает пакет с входящей меткой 26. На основе своей таблицы продвижения меток маршрутизатор Чикаго заменяет входящую метку пакета 26 на исходящую метку 30 и отправляет пакет на интерфейс POSO/З. Маршрутизатор Далласа получает пакет с входящей меткой 30. Так как маршрутизатор Даллас — это предпоследний маршрутизатор на пути до пункта назначения, он удаляет MPLS-метку и отправляет пакет в конечную точку через интерфейс POS9/1.
Входящая Исходящаяметкаматка
Сан-ФранцискоСан-ФранцискоPOS5/1POS5/1ЧикагоЧикагоPOS0/1POS0/1POS0/3POS0/3Входящая метка 30Входящая метка 30Исходящая метка РОР-меткаИсходящая метка РОР-меткаДалласДалласНью-ЙоркНью-ЙоркPOS8/2POS8/2RSVP PATH RSVP PATHRSVP PATH RSVP PATHRSVP PATHRSVP PATHRSVP PATHRSVP PATHRSVP RESV RSVP RESV LABEL 26RSVP RESV RSVP RESV LABEL 26RSVP RESV LABEL 30RSVP RESV LABEL 30RSVP RESVLABEL 0RSVP RESVLABEL 02630
Сан-Франциско
Сан-Франциско
POS5/1
POS5/1
Чикаго
Чикаго
POS0/1
POS0/1
POS0/3
POS0/3
Входящая метка 30
Входящая метка 30
Исходящая метка РОР-метка
Исходящая метка РОР-метка
Даллас
Даллас
Нью-Йорк
Нью-Йорк
POS8/2
POS8/2
RSVP PATH RSVP PATH
RSVP PATH RSVP PATH
RSVP PATH
RSVP PATH
RSVP PATH
RSVP PATH
RSVP RESV RSVP RESV LABEL 26
RSVP RESV RSVP RESV LABEL 26
RSVP RESV LABEL 30
RSVP RESV LABEL 30
RSVP RESVLABEL 0
RSVP RESVLABEL 0
LSP-путь установлен
Поток пакетовПоток пакетовLABEL 26LABEL 26LABEL 30LABEL 30Нет метки(не MPLS-пакет)Нет метки(не MPLS-пакет)
Поток пакетов
Поток пакетов
LABEL 26
LABEL 26
LABEL 30
LABEL 30
Нет метки(не MPLS-пакет)
Нет метки(не MPLS-пакет)
Рис. 10.5. LSP-путь для ТЕ-туннеля от Сан-Франциско до Нью-Йорка
Как было сказано ранее, протокол RSVP используется для установки ТЕ-туннелей. На маршрутизаторе Чикаго была получена отладочная информация, содержащая RSVP-
сообщения, которые были использованы для установки туннеля. В листингах 10.15 и 10.16 показано содержание сообщений RSVP PATH и RSVP RESV, соответственно, которые бы* ли получены маршрутизатором Чикаго. Обратите внимание на новые и модифицированные RSVP-объекты, а также на информацию, которая в них находится.
[ Листинг 10.15. Сообщение RSVP PATH, полученное маршрутизатором
।\ ЧикагоотмаршрутизатораСан-Франциско ' ' ‘ ; к;;
RSVP: version:1 flags:0000 typezPATH cksumzOOOO ttl:254
Preserved:0 length: 248
SESSIONtype 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:
StrictIPv4Prefix,8bytes,222.222.222.22/32
(#2)StrictIPv4Prefix,8bytes,222.222.222.26/32
(#3)StrictIPv4Prefix,8bytes,222.222.222.14/32
LABEL_REQUESTtype 1 length 8 : 00000800
SESSION_ATTRIBUTEtype 7 length 24:
setup_priz 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_TSPECtype2 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
ADSPECtype 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)z2147483647
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_ROUTEtype 1 length 12:
IPv4 address, 222.222.222.21/32
Обратите внимание на объект Explicit_Route (явный маршрут) в сообщении RSVP PATH, в котором находится точный путь, пройденный сообщением RSVP PATH с целью установки LSP-пути для туннеля. В сообщении также находится объект LABEL_REQUEST (запрос метки) для запроса распределения меток и объект RECORD_ROUTE (запись маршрута) для записи пути, пройденного сообщением.
Листинг 10.16. Сообщение RSVP RESV, отправленное маршрутизатором
Чикаго маршрутизатору Сан-Франциско ^г 777 ' ; 'J “
RSVP: version:1 flags:0000 type:RESV cksum:D748 ttl:255
preserved: 0 length: 136
SESSIONtype 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,
^tspec 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:
(#1) 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-сеанс и информация об установленном резервировании, j хранящаяся на маршрутизаторе Сан-Франциско ; L; >к ч«^^
SanFranciscofshow ip rsvp host sender
ToFromPro DPort Sport Prev Hop
I/F BPS Bytes
222.222.222.3222.222.222.1001
9>ЮК IK
SanFranciscoishow ip rsvp installed
RSVP: POS5/1
BPS ToFromProtoc Dport Sport
S> Weight Conversation
10K222.222.222.3222.222.222.1001
S> 4264
По умолчанию значение параметра TTL (Time-to-Live — “время жизни”) из заголовка IP-пакета копируется в MPLS-заголовок пограничным маршрутизатором LSP- пути. Поэтому служебная программа traceroute будет нормально показывать все промежуточные точки назначения в LSP-пути туннеля. При желании вы можете скрыть точки назначения LSP-пути, не копируя значение поля TTL из заголовка IP-пакета в MPLS-заголовок на границе MPLS-сети. В листинге 10.18 показан результат работы служебной программы traceroute на маршрутизаторе Сан-Франциско до и после выполнения команды по mpls ip propagate-ttl.
™^, г:™^г* —7ч;-,
Листинг 10.18. Результат работы служебной программы trace route до и . j Wh’- после выполнениякоШндылотр1в/рргорада1е-Н/ > ц
SanFranciscoitrace 222.222.222.3
Type escape sequence to abort.
Tracing the route to 222.222.222.3
222.222.222.22 12 msec 8 msec 8 msec
222.222.222.26 12 msec 8 msec 12 msec
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
222.222.222.14 8 msec 8 msec *
SanFranciscoi
Резюме
Механизм MPLS ТЕ использует свойства коммутации каналов для управления ТЕ- туннелями с соответствующими зарезервированными на основе передаваемого по туннелю трафика ресурсами. Протокол ТЕ-RSVP используется для установки LSP- пути для ТЕ-туннеля. ТЕ-расширения протоколов OSPF и IS-IS позволяют лавинообразно передавать информацию о доступных ресурсах каналов по всей сети.
Известное высказывание Майка О’Делла (Mike O’Dell) из UUNET — “Эффективность производственной деятельности компании и стоимость ее инфраструктуры напрямую за-
висит от эффективности, с которой используется доступная полоса пропускания в среде передачи данных” — как можно более точно выражает необходимость в применении механизма управления трафиком.
Ответы на часто задаваемые вопросы
Как определяется путь ТЕ-туннеля, если в таблице маршрутизации содержатся два пути к его (туннеля) пункту назначения?
Если к пункту назначения туннеля существуют несколько путей, выбор пути основывается на следующих критериях (в приведенном ниже порядке).
Метрика. Путь с наименьшей метрикой (ценой) всегда выбирается в первую очередь.
Полоса пропускания. Путь с самой широкой доступной полосой пропускания.
Точки назначения. Путь с наименьшим числом точек назначения.
Первый путь. Первый найденный путь.
В чем заключается разница между ТЕ-транком, ТЕ-туннелем и ТЕ-путем?
ТЕ-транк определяет класс пакетов, которые передаются по ТЕ-туннелю. ТЕ- туннель — это однонаправленный IP-туннель между источником и пунктом назначения, построенный на базе технологии MPLS. ТЕ-путь — это путь, по которому проложен ТЕ- туннель. Он определяется протоколом RRR и устанавливается протоколом TE-RSVP.
Чем отличаются области применения и функционирование протоколов RSVP и TE-RSVP?
Области применения оригинального протокола RSVP и протокола TE-RSVP существенно отличаются. В табл. 10.4 приведены некоторые важные отличия этих протоколов.
। Таблица 10.4. Сравнительная характеристика работы протоколов RSVP 8и TE-RSVP
RSVP
TE-RSVP
Применение
Сигнализирует о требованиях к распределению ресурсов вдоль пути
Устанавливает LSP-путь с использованием или без использования распределения ресурсов
Информация состояния
Для каждого потока
Для каждого транка трафика
Путь, по которому передаются
RSVP-сообщения передаются по
Путь передачи сообщений не огра-
RSVP-сообщения
пути обычного маршрута, проложенного на основе адреса пункта назначения, по которому передаются пакеты с данными
ничен маршрутом, проложенным на основе адреса пункта назначения
Управление распределением ресурсов
Управляется получателем
Управляется отправителем
RSVP-сеанс
Между узлами
Между маршрутизаторами
Часть
IV
Приложения
В этой части... ■
, ,, Приложение А. Модульный интерфейс командной строки
Cisco QoS309
Приложение Б. Механизмы коммутации пакетов317
Приложение В. Политики маршрутизации331
Приложение Г. Транспортный протокол реального
\: времени (RTP) ^343
,^- 1 ТТрйложение Д. Общие функции^линейной эфективности кпротокола IP345
Приложение Е. Фрагментация и чередование пакетов "на канальном уровне349
Приложение Ж. Значения поля IP-приоритета и поля DSCP 353
4rd
В этом приложении.
Определение класса трафика -^310
Определение политики311
Применение политик .д^-‘312
Порядок выполнения политик '.^"'314
Приложение
А
Модульный интерфейс командной строки Cisco QoS
Модульныйинтерфейскомандной строки (command-line interface — CLI) качества об- -ч. служивания (quality of service — QoS) определяет новый способ конфигурации QoS в программном обеспечении Cisco IOS, основанный на использовании CLI-интерфейса. В соот- ? ветствии с новым методом, определения политики QoS-конфигурация разделена на три . модуля: определение класса трафика, определение политики и применение политики.
У Модул ьньгЙ интерфейс комадной строки QoS одинаково хорошо подходит для QoS- моделей протокола Internet (InternetProtocol — 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), и такие политики отбрасывания пакетов, как взвешенный алгоритм произвольного раннего обна- .? ружения (Weighted Random Early Detection — WRED).
Основное отличие между разными QoS-моделями заключается в их политике классификации трафика. Например, модели IP QoS, основанные на базе использования значения поля IP-приоритета й поля кода дифференцированной услуги (Differentiated Service Code Point — DSCP), отличаются битами, которые применяются для определения класса трафика. После того как классы определены, для дифференцированного обслуживания ? трафика используются стандартные политики. В то время как модели 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), атрибут BG P-сообщества и т.д. Команда class-map расширяет функциональность команды route-map, добавляя такие новые средства классификации пакета, как критерий совпадения на основе МАС-адреса (Media Access Control — управление доступом к среде передачи) и входного интерфейса.
В листинге А.1 классы трафика class!. class2, class3, class4 и class5 определены на базе значения поля IP-приоритета, значения поля DSCP, МАС-адреса пункта назначения, входящего интерфейса и информации протокола, соответственно.
! Листинг А.1. Примеры определения классов трафика v У ч
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. Эти ключевые слова выполняют операции логического ИЛИ и И, соответственно, по отношению ко вложенным ко-
мандам match, определенным в модуле class-map. В листинге А. 2 определяется класс трафика class-any с критерием совпадения пакетов, удовлетворяющим трафику любого из ранее определенных классов — class! и 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 ;
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. Примеры политик, предназначенных для пограничных ’ > ^уу ^- сетМ'Х интерфейсов „ ;У*,. , , Jr г .ь. .у л
policy-map epolicyl match classl
rate-limit <>
policy-map epolicy2 match class2
set ip dscp EF
policy-map epolicyl
match class3
shape <>
set ip precedence 4
В листинге A.4 политика epolicyl определяет ограничение интенсивности трафика для класса class 1, политика epolicy2 устанавливает значение, соответствующее РНВ-политике EF, в поле DSCP для класса трафика calss2, а политика ероПсуЗ активизирует механизм выравнивания трафика и устанавливает IP-приоритет 4 для класса трафика class3.
! Листинг А.5. Примеры политик, предназначенных для интерфейсов i v ■ базовой сети . ■.
policy-map epolicyl match classl bandwidth <> random-detect <>
В листинге A.5 политика epolicyl определяет минимальную полосу пропускания и активизирует механизм 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 — к исходящему трафику интерфейса P0SO/O/O.
, Листинг А.7. Пример применения политики к интерфейсу?
interface HSSI0/0/0
service-policy input policyl
interface POS0/0/0
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 ■для ограничения интенсивности трафика . ц; i
class-map tcp
match <all tcp traffic*
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.
Входные списки доступа (фильтрация входящих пакетов).
Установка приоритета или QoS-метки на основе адреса источника.
Установка приоритета или QoS-метки на основе адреса пункта назначения.
Ограничение интенсивности входного трафика.
Маршрутизация на основе политик.
Выходные списки доступа (фильтрация исходящих пакетов).
Ограничение интенсивности исходящего трафика.
Выходная политика отбрасывания (например, WRED).
Выходное планирование (например, WFQ) и выравнивание трафика.
Независимо от QoS-политик сразу после применения входных списков доступа производится учет входящих пакетов, а непосредственно перед тем как пакеты отправляются по среде передачи данных, — учет исходящих пакетов.
Упорядочение операторов внутри политик
Еще одним порядком применения политик является упорядочение операторов внутри самих политик. К примеру, в операторе ограничения интенсивности трафика существует параметр порядкового номера, помогающий пользователям определить порядок, в котором будут рассматриваться критерии совпадения. Порядковый номер также позволяет легко добавлять в систему новые классы трафика.
Рассмотрим листинг АЛО, в котором проверка критерия совпадения для класса class! производится до проверки критерия совпадения для класса class2 (порядковый номер 10 меньше порядкового номера 20) для карты политики policy!.
—,—,__—_—____г_т_____
; Листинг АН Упорядочение операторов внутри политикj
policy-map policyl
class classl
rate-limit 10 input <>
class class2
rate-limit 20 input <>
В листинге A. 11 политика policy2 ограничивает интенсивность трафика класса class2 перед ограничением интенсивности трафика класса classl (порядковый номер 5 меньше порядкового номера 10). Этот пример иллюстрирует изменение порядка применения операторов политик.
[ листинг А.11. Порядок выполнения операторов политики изменен путем ~1 Iмодификации порядкового номераj
policy-map policy2
class classl
rate-limit 10 input о
class class2
rate-limit 5 input <>
Приложение
Б
Механизмы коммутации пакетов
Главной задачей маршрутизатора является эффективная и корректная коммутация пакетов. В операционной системе 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 Resolution Protocol — ARP), после чего пакет устанавливается в выходную очередь интерфейса для отправки. Коммутация процессов — это медленная, неэффективная и требующая интенсивного использования ресурсов процессора операция, поскольку каждое принятие решения о коммутации пакета требует просмотра таблицы маршрутизации и ARP- таблицыг При существовании нескольких путей к пункту назначения с одинаковой ценой коммутация процессов предполагает распределение нагрузки для каждого пакета. Коммутация процессов схематически изображена на рис. Б. 1.
Кадр I ПакетКадр I ПакетПерезапись заголовке канального уровняПерезапись заголовке канального уровня
Кадр I Пакет
Кадр I Пакет
Перезапись заголовке канального уровня
Перезапись заголовке канального уровня
Рис. Б. 1. Коммутация процессов предполагает просмотр таблицы 1Р-маршрутизации и ARP-таблицы
Продвижение пакетов с помощью кэша маршрутов
Продвижение пакетов с помощью кэша маршрутов (route-cache forwarding) решает некоторые проблемы, присущие коммутации процессов. Так, в соответствии с этим методом после того, как первый пакет был передан с помощью коммутации процессов, адрес пункта назначения, интерфейс точки следующей передачи и инкапсуляция МАС-адреса точки следующей передачи сохраняются в таблице под названием кэш маршрутов (route-cache). Таким образом, можно осуществить быструю коммутацию последующих пакетов, предназначенных для этого же пункта назначения, всего лишь найдя адрес пункта назначения в кэше маршрутов. При использовании этого метода принятие решения о коммутации производится в рамках того же прерывания, которое было вызвано поступлением пакета. Продвижение пакетов с помощью кэша маршрутов часто называют также быстрой коммутацией (fast switching). Механизм продвижения пакетов с помощью кэша маршрутов схематически изображен на рис. Б.2.
Рис. Б.2. Передача пакетов с помощью кэша маршрутов осуществляется путем просмотра 1Р-кэшаРис. Б.2. Передача пакетов с помощью кэша маршрутов осуществляется путем просмотра 1Р-кэша
Рис. Б.2. Передача пакетов с помощью кэша маршрутов осуществляется путем просмотра 1Р-кэша
Рис. Б.2. Передача пакетов с помощью кэша маршрутов осуществляется путем просмотра 1Р-кэша
Механизм продвижения пакетов с помощью кэша маршрутов производит быстрый поиск префикса пункта назначения по требованию. Запись для пункта назначения в кэше маршрутов создается только после того, как маршрутизатор получит первый предназначенный к отправке в этот пункт пакет. Данный пакет передается с помощью коммутации процессов, однако все остальные пакеты, предназначенные для передачи в этот же пункт назначения, коммутируются путем их поиска в более быстром и эффективном кэше маршрутов. Записи в кэше маршрутов периодически устаревают. Более того, изменение в топологии сети может мгновенно сделать эти записи недействительными.
Подобная схема кэширования маршрутов по требованию эффективна только в тех случаях, когда большинство потоков трафика предназначаются для передачи в некоторое подмножество пунктов назначения в таблице маршрутизации. Однако профили трафика в ядре Internet и больших intranet-сетях не подпадают под это описание. Характеристики такого трафика изменились в сторону увеличения количества кратковременных потоков, обычно инициированных интерактивными приложениями и Web-приложениями. Изменение в модели Internet-трафика требует изменений механизма коммутации с целью уменьшения огромного количества обращений к кэшу, вызванного большим числом кратковременных потоков трафика и изменениями топологии сети, которые отражаются в таблице маршрутизации.
Когда существует несколько путей с одинаковой ценой к подсети назначения, механизм продвижения пакетов с помощью кэша маршрутов для выравнивания нагрузки кэширует префиксы длиной 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-коммутации схематически изображен на рис. Б.З.
Рис. Б.З. Процесс CEF-коммутации пакетов путем просмотра таблицы СЕР
Кроме обычных физических смежностей, необходимо еще обработать особые типы смежности. Записи CEF-таблицы с префиксами, которые необходимо обработать специальным образом, заносятся в кэш с указанием на специальный тип смежности. Примеры таких типов смежностей показаны в табл. Б.1.
[Таблица Б.1. Примеры некоторых специальных типов смежностей
Тип смежности Причина специальной обработки
Receive
Пакеты, соответствующие этим префиксам, предназначаются для передачи маршрутизатору. Записи CEF-таблицы с этими смежностями являются префиксами длиной 32 IP-адреса маршрутизатора, а также адресами направленного и обычного широковещания
Null
Пакеты, соответствующие этим префиксам, предназначены для интерфейса NullO маршрутизатора. Записи CEF-таблицы с этой смежностью создаются для префиксов с точкой назначения, представляющей собой интерфейс NullO маршрутизатора. Пакеты, предназначенные для передачи на интерфейс NullO, отбрасываются механизмом СЕР
Glean
Записи CEF-таблицы со смежностью Glean (“сборная” смежность) создаются для префиксов подсети, напрямую подсоединенных к одному из не двухточечных интерфейсов маршрутизатора. Для пакетов, которые должны быть переданы конечной станции, в базе данных смежности производится тщательный поиск специального префикса
Punt
Записи CEF-таблицы со смежностью Punt (“спорная” смежность) создаются для префиксов, которые не могут быть скоммутированы с помощью механизма СЕР, так как определенные свойства могут требовать специальной обработки или пока не поддерживаются
Примечание
Интерфейс NullO— это псевдоинтерфейс, который работает так же, как и null- устройства, существующие в большинстве операционных систем. Этот интерфейс всегда работает и не может передавать или получать трафик. Он предоставляет альтернативный метод фильтрации трафика.
В отличие от модели кэша маршрутов, в которой префиксы длиной 32 бит кэшируются для выравнивания нагрузки, механизм СЕР проводит поиск эффективной хэш-функции с целью выравнивания нагрузки для каждой пары “источник- пункт назначения”. Хэш-функция указывает на уникальную смежность для каждой пары “адрес источника-адрес пункта назначения”. Более того, механизм СЕР может производить выравнивание нагрузки для каждого пакета с помощью указа-
теля, который циклически перемещается по смежностям с одинаковой стоимостью, соответствующим пункту назначения.
Еще одним показательным преимуществом механизма 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.
ISP сISP сISP AISP AHssi3/0/0Hssi3/0/0R5R5110110Hssi2/0/1Hssi2/0/1Hssi2/0/1Hssi2/0/1Hssi2/0/0Hssi2/0/0Hssi2/0/0Hssi2/0/0R2R2R3R3106106105105200.200.200.104/30200.200.200.104/30FE1/0/0FE1/0/0200.200.200.16/28200.200.200.16/28201.201.201.16/28201.201.201.16/28R6R6R4R4194.194.194.0/24194.194.194.0/24ISP ВISP ВСеть поставщике услуг Internet AS 109Сеть поставщике услуг Internet AS 109FE1/0/017FE1/0/017191.108.10.8/30191.108.10.8/30Hssi3/0/0Hssi3/0/0101 Hssi2/0/0 200.200.200.100/30101 Hssi2/0/0 200.200.200.100/30R1109Hssi2/0/1200.200.200.108/30R1109Hssi2/0/1200.200.200.108/3010101010191.108.0.0/1820.0.0.0/8131.108.0.0/16210.210.210.0/24191.108.0.0/1820.0.0.0/8131.108.0.0/16210.210.210.0/24191.108.10.12/30191.108.10.12/30Serial4/0/0 13Serial4/0/0 13Seriel4/0/1201.201.201.8/30Сеть клиентаAS 4567Seriel4/0/1201.201.201.8/30Сеть клиентаAS 4567
ISP с
ISP с
ISP A
ISP A
Hssi3/0/0
Hssi3/0/0
R5
R5
110
110
Hssi2/0/1
Hssi2/0/1
Hssi2/0/1
Hssi2/0/1
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
R2
R2
R3
R3
106
106
105
105
200.200.200.104/30
200.200.200.104/30
FE1/0/0
FE1/0/0
200.200.200.16/28
200.200.200.16/28
201.201.201.16/28
201.201.201.16/28
R6
R6
R4
R4
194.194.194.0/24
194.194.194.0/24
ISP В
ISP В
Сеть поставщике услуг Internet AS 109
Сеть поставщике услуг Internet AS 109
FE1/0/0
17
FE1/0/0
17
191.108.10.8/30
191.108.10.8/30
Hssi3/0/0
Hssi3/0/0
101 Hssi2/0/0 200.200.200.100/30
101 Hssi2/0/0 200.200.200.100/30
R1
109
Hssi2/0/1
200.200.200.108/30
R1
109
Hssi2/0/1
200.200.200.108/30
10
10
10
10
191.108.0.0/18
20.0.0.0/8
131.108.0.0/16
210.210.210.0/24
191.108.0.0/18
20.0.0.0/8
131.108.0.0/16
210.210.210.0/24
191.108.10.12/30
191.108.10.12/30
Serial4/0/0 13
Serial4/0/0 13
Seriel4/0/1
201.201.201.8/30
Сеть клиентаAS 4567
Seriel4/0/1
201.201.201.8/30
Сеть клиентаAS 4567
Рис. Б.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 Ш - 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
0/24 is variably subnetted, 8 subnets, 4 masks
C200.200.200.104/30is directly connected, Hssi2/0/0
0200.200.200.108/30[110/20] via 200.200.200.101, Hssi2/0/l
[110/20] via 200.200.200.106, Hssi2/0/0
C200.200.200.100/30is directly connected, Hssi2/0/l
S 200.200.200.0/24 is directly connected, NullO
О 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
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
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] via191.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-маршрутизации не зависит от механизма коммутации пакетов. Как правило, она заполняется динамическими протоколами маршрутизации, маршрутами к непосредственно подключенным подсетям и статическими маршрутами.
Перед тем как запустить механизм СЕР на маршрутизаторе R2, воспользуемся командой show ip cache verbose для того, чтобы просмотреть таблицу кэша, использующуюся в модели кэша маршрутов. В листинге Б.2 показана таблица кэша маршрутов маршрутизатора R2 на момент запуска команды.
{ Листинг Б.2. Кэш маршрутизатора Й2, использующего механизм j ,?.^ ; коммутации на основе кэша маршрутов.
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
Prefix/Length
Age
Interface
Next Hop
20.0.0.0/8-8
40F000800
00:01:14
Hssi2/0/0
200.200.200.106
131.108.0.0/16-16
40F000800
00:00:49
Hssi2/0/0
200.200.200.106
191.108.1.0/30-30
40F000800
00:01:47
Hssi2/0/0
200.200.200.106
191.108.10.8/30-30
40F000800
00:03:19
Hssi2/0/0
200.200.200.106
200.200.200.1/32-32
40F000800
00:03:22
Hssi2/0/l
200.200.200.101
200.200.200.3/32-32
40F000800
00:03:22
Hssi2/0/0
200.200.200.106
200.200.200.101/32-30
40F000800
00:03:19
Hssi2/0/l
200.200.200.101
200.200.200.20/32-2800:00:29
1400000C31DD8B00E0B0E2B843080C
FastEthernetl/0/0 200.200.200.106
1
210.210.210.0/24-16
40F000800
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 был запущен механизм СЕР. В листингах Б.З и Б.4 показаны таблица CEF-смежностей и таблица CEF- коммутации маршрутизатора R2.
Листинг Б.3. Таблица CEF-смежностей маршрутизатора R2 './{
R2#show adjacency detail
Protocol InterfaceAddress
IP Hssi2/0/0point2point(26)
0 packets, 0 bytes
0F000800
CEF expires: 00:02:47
IP Hssi2/0/lIP Hssi2/0/lIP FastEthernetl/O/OIP FastEthernetl/O/Orefresh: 00:00:47 point2point(16) 0 packets, 0 bytes 0F000800
IP Hssi2/0/l
IP Hssi2/0/l
IP FastEthernetl/O/O
IP FastEthernetl/O/O
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-коммутации пакетов маршрутизатора R2j
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
200.200.200.101200.200.200.106200.200.200.106200.200.200.106200.200.200.1060.0.0.0receivereceive200.200.200.101200.200.200.106200.200.200.106200.200.200.106200.200.200.1060.0.0.0receivereceiveHssi2/0/lHssi2/0/0Hssi2/0/0Hssi2/0/0Hssi2/0/0Hssi2/0/lHssi2/0/0Hssi2/0/0Hssi2/0/0Hssi2/0/0200.200.200.108/30
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
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
Hssi2/0/l
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
Hssi2/0/0
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
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 маршрутизатора.
( Листинг Б.6. Пример рекурсивной CEF-записи с действительной . ■' j
ч помещенной в кэш смежностью •
H4506#sh ip cef 131.108.0.0
.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.
В модели передачи пакетов с помощью кэша маршрутов рекурсивный поиск пункта назначения, при необходимости, производится в процессе коммутации первого пакета, переданного по направлению к пункту назначения в соответствии с созданной
записью в кэше. Механизм СЕР производит рекурсивный поиск до прибытия пакета. Таким образом, экономятся несколько циклов работы процессора.
/Листинг Б.7. Пример CEF-записи с действительной помещенной в кэш !; смежностью с зависимостями,•
R2#sh ip cef 191.108.10.10
.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-записи в плане определения их точки следующей передачи пакета.
Листинг Б.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 также поддерживает распределение нагрузки для каждого пакета.
| Листинг Б.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
Точка назначения 200.200.200.16/28 является напрямую подключенной к интерфейсу Fast Ethernet подсетью. Вместо создания CEF-записи для каждого узла этой широковещательной подсети со множественным доступом, данная подсеть устанавливается в качестве “сборной” смежности. При отправке пакета с использованием “сборной” смежности перед коммутацией пакета механизм CEF просматривает таблицу смежности в поисках МАС-адреса пункта назначения.
Листинг Б.10. Пример CEF-записи с Null-смежностью;
R4506#sh ip cef 200.200.200.0
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 Периодически при возникновении нестабильности в сети происходят скачки загруженности процессораЗапись в кэше создается во время коммутации первого пакета. Все последующие пакеты передаются с помощью этой записиУправляется трафиком. Создается по требованиюЭффективна для трафика с небольшим количеством длительных потоков, обычно инициированных приложениями передачи файловКаждый рекурсивный поиск маршрута производится, когда начальный пакет, направляющийся в пункт назначения, инициировал создание элемента кэша. Лимит на глубину рекурсии — 6 Периодически при возникновении нестабильности в сети происходят скачки загруженности процессораПроизводит распределение нагрузки на основе адреса пункта назначения. Это осуществляется путем создания записей длиной 32-бит в кэше для записи маршрута, у которого есть пути с одинаковой стоимостью Распределение нагрузки для каждого пакета не производитсяПроизводит распределение нагрузки на основе адреса пункта назначения. Это осуществляется путем создания записей длиной 32-бит в кэше для записи маршрута, у которого есть пути с одинаковой стоимостью Распределение нагрузки для каждого пакета не производитсяМеханизм CEF строит таблицу коммутации на базе таблицы маршрутизации. CEF-запись доступна для CEF-коммутации пакета до тех пор, пока доступна запись о маршруте Управляется топологией. Создается как точная копия таблицы маршрутизацииЭффективна для трафика с большим количеством кратковременных потоков, обычно инициированных интерактивными приложениями и Web-приложениямиМеханизм CEF производит все рекурсивные поиски маршрутов до того, как они вставляются в таблицу коммутации. Лимита на глубину рекурсии нетСкачков загруженности процессора не происходит. Во время нестабильности сети производительность не падает. Механизм CEF либо коммутирует пакет, либо отбрасывает егоПроизводит распределение нагрузки для каждой пары “источник — пункт назначения". Осуществляется с помощью хэш-алгоритма, который учитывает как адрес источника, так и адрес пункта назначенияПроизводится распределение нагрузки для каждого пакета. Осуществляется с помощью хэш-алгоритма, который циклически проходит все возможные путиМеханизм CEF строит таблицу коммутации на базе таблицы маршрутизации. CEF-запись доступна для CEF-коммутации пакета до тех пор, пока доступна запись о маршруте Управляется топологией. Создается как точная копия таблицы маршрутизацииЭффективна для трафика с большим количеством кратковременных потоков, обычно инициированных интерактивными приложениями и Web-приложениямиМеханизм CEF производит все рекурсивные поиски маршрутов до того, как они вставляются в таблицу коммутации. Лимита на глубину рекурсии нетСкачков загруженности процессора не происходит. Во время нестабильности сети производительность не падает. Механизм CEF либо коммутирует пакет, либо отбрасывает егоПроизводит распределение нагрузки для каждой пары “источник — пункт назначения". Осуществляется с помощью хэш-алгоритма, который учитывает как адрес источника, так и адрес пункта назначенияПроизводится распределение нагрузки для каждого пакета. Осуществляется с помощью хэш-алгоритма, который циклически проходит все возможные пути
Запись в кэше создается во время коммутации первого пакета. Все последующие пакеты передаются с помощью этой записи
Управляется трафиком. Создается по требованию
Эффективна для трафика с небольшим количеством длительных потоков, обычно инициированных приложениями передачи файлов
Каждый рекурсивный поиск маршрута производится, когда начальный пакет, направляющийся в пункт назначения, инициировал создание элемента кэша. Лимит на глубину рекурсии — 6 Периодически при возникновении нестабильности в сети происходят скачки загруженности процессора
Запись в кэше создается во время коммутации первого пакета. Все последующие пакеты передаются с помощью этой записи
Управляется трафиком. Создается по требованию
Эффективна для трафика с небольшим количеством длительных потоков, обычно инициированных приложениями передачи файлов
Каждый рекурсивный поиск маршрута производится, когда начальный пакет, направляющийся в пункт назначения, инициировал создание элемента кэша. Лимит на глубину рекурсии — 6 Периодически при возникновении нестабильности в сети происходят скачки загруженности процессора
Производит распределение нагрузки на основе адреса пункта назначения. Это осуществляется путем создания записей длиной 32-бит в кэше для записи маршрута, у которого есть пути с одинаковой стоимостью Распределение нагрузки для каждого пакета не производится
Производит распределение нагрузки на основе адреса пункта назначения. Это осуществляется путем создания записей длиной 32-бит в кэше для записи маршрута, у которого есть пути с одинаковой стоимостью Распределение нагрузки для каждого пакета не производится
Механизм CEF строит таблицу коммутации на базе таблицы маршрутизации. CEF-запись доступна для CEF-коммутации пакета до тех пор, пока доступна запись о маршруте Управляется топологией. Создается как точная копия таблицы маршрутизации
Эффективна для трафика с большим количеством кратковременных потоков, обычно инициированных интерактивными приложениями и Web-приложениями
Механизм CEF производит все рекурсивные поиски маршрутов до того, как они вставляются в таблицу коммутации. Лимита на глубину рекурсии нет
Скачков загруженности процессора не происходит. Во время нестабильности сети производительность не падает. Механизм CEF либо коммутирует пакет, либо отбрасывает его
Производит распределение нагрузки для каждой пары “источник — пункт назначения". Осуществляется с помощью хэш-алгоритма, который учитывает как адрес источника, так и адрес пункта назначения
Производится распределение нагрузки для каждого пакета. Осуществляется с помощью хэш-алгоритма, который циклически проходит все возможные пути
Механизм CEF строит таблицу коммутации на базе таблицы маршрутизации. CEF-запись доступна для CEF-коммутации пакета до тех пор, пока доступна запись о маршруте Управляется топологией. Создается как точная копия таблицы маршрутизации
Эффективна для трафика с большим количеством кратковременных потоков, обычно инициированных интерактивными приложениями и Web-приложениями
Механизм CEF производит все рекурсивные поиски маршрутов до того, как они вставляются в таблицу коммутации. Лимита на глубину рекурсии нет
Скачков загруженности процессора не происходит. Во время нестабильности сети производительность не падает. Механизм CEF либо коммутирует пакет, либо отбрасывает его
Производит распределение нагрузки для каждой пары “источник — пункт назначения". Осуществляется с помощью хэш-алгоритма, который учитывает как адрес источника, так и адрес пункта назначения
Производится распределение нагрузки для каждого пакета. Осуществляется с помощью хэш-алгоритма, который циклически проходит все возможные пути
Окончание табл. Б.2
Коммутация с помощью кэша маршрутов
CEF-коммутация
. Пакеты, которые необходимо передать на интерфейс NullO, не поддерживаются механизмом комму ации с помощью кэша маршрутов. Такие пакеты обрабатываются с помощью неэффективного механизма коммутации процессов
Такие функции, как маршрутизация на основе политики, которые нуждаются в поиске маршрута, не поддерживаются явно
Не поддерживает распространения QoS-политик
Пакеты, которые необходимо передать на интерфейс NullO, могут быть эффективно CEF-коммутированы или отброшены посредством специальной Null-смежности
Поскольку CEF-таблица является точной копией таблицы маршрутизации, маршрутизация на основе политики эффективно поддерживается механизмом CEF Позволяет присоединять информацию QoS-политики к CEF-записи. Пакет может быть CEF-коммутирован с учетом QoS-политики
Резюме
Для современных крупномасштабных IP-сетей и ISP-сетей рекомендуется использовать механизм коммутации СЕР. Для особых режимов коммутации пакетов поддержка некоторых функций QoS ограничена. В частности, все распределенные функции QoS, которые работают на отдельных линейных платах маршрутизатора, а не на плате центрального процессора, требуют использования распределенного механизма СЕР.
В этом приложении...
Использование QpS-политик при принятии решения о маршрутизации ^';331
Распространение QoS-политик с помощью протокола BGP336
Приложение
в
Политики маршрутизации
В этом приложен и иобсуждаютс я политики маршрутизации и распространение политики качества обслуживания (quality of service — QoS) с помощью протокола пограничного шлюза (Border Gateway Protocol — BGP). Маршрутизация на основе политики используется для замены ,традиционной функции маршрутизации на основе адреса пункта назначения более гибким .Механизмом маршрутизации. Для передачи информации о политике по сети поставрика услуг механизм распространения QoS-политик использует протокол BGP. В этом приложении также кратко описана маршрутизация на основе качества обслуживания. п, „^
Использование QoS-политик при принятии решения £ маршрутизации
<4 Независимо от адреса пункта назна’£&ия решение о маршрутизации, при наличии . такой возможности, должно приниматься на основе гибких политик и требований к ресурсам сети. Подобный механизм принятия решения предоставляет сетевому адми- нистратору средства, позволяющие более эффективно осуществлять маршрутизацию , : трафика в сети.
Маршрутизация на основе качества обслуживания (QoS)
у Маршрутизация на основе QoS (QoS-based routing) — это механизм маршрутизации, ’ в соответствии с которым пути дляпотоков трафика определяются на основе некоторых сведений о наличии ресурсов бетй и на основе требований потоков к качеству об-
служивания.
-политик использует следующие важные-политик использует следующие важныеМеханизм-мйрЦгрутизации нач
-политик использует следующие важные
-политик использует следующие важные
^сцддреййя.’^сцддреййя.’1212
^сцддреййя.’
^сцддреййя.’
12
12
Протокол маршрутизацииупередает метрики с динамической информацией о наличии pecypcoB(QoS)(HanpHMep, информация о доступной полосе пропускания, уровне потери пакетов или задержке).
ПротокоМШрщрутиЗации должен вычислять не только оптимальный путь, но и другйе Йбзможные^йуги на основе их QoS-доступности.
• В каждом потоке передаются сведения о необходимом качестве услуг (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 Protocol — 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) и протокола передачи дата-
грамм пользователя (User Datagram Protocol — UDP), битами ToS, битами поля IP- приоритета и т.д. Подобная гибкая схема маршрутизации обычно и называется маршрутизацией на основе политики (policy-based routing).
Маршрутизация на основе политики не опирается на какой-нибудь динамический протокол маршрутизации, а использует локальную статическую конфигурацию маршрутизатора. Она позволяет маршрутизировать трафик на основе определенной политики, даже если информация о маршруте к пункту назначения потока недоступна, или вообще игнорируя динамическую информацию о маршруте. Более того, можно указать маршрутизатору на необходимость установки значения поля IP-приоритета пакета для трафика, маршрутизируемого на основе политики.
Примечание
Некоторые функции маршрутизации на основе политики, требующие просмотра таблицы маршрутизации, могут эффективно выполняться на маршрутизаторах с поддержкой механизма скоростной коммутации пакетов Cisco (Cisco Express Forwarding — CEF). Более подробно механизм CEF обсуждается в приложении Б, “Механизмы коммутации пакетов". Так как CEF зеркально отображает каждую запись таблицы маршрутизации, функция маршрутизации на основе политики может использовать CEF-таблицу, не производя поиск в таблице маршрутизации.
Если для сбора статистики потока на интерфейсе активизирован режим учета netflow, необходимо применить команду ip route-cache flow accelerate. С целью сохранения памяти в записях кэша потока передается его состояние, а проверка политики карты маршрута для каждого пакета активного потока не проводится. Режим учета netflow используется для сбора статистики потока трафика.
Поскольку конфигурация маршрутизации на основе политики является статической, это может привести к отбрасыванию трафика в случае, если сконфигурированная точка следующей передачи пакета становится недоступной. Для проверки доступности точки следующей передачи механизм маршрутизации на основе политики может использовать протокол обнаружения Cisco (Cisco Discovery Protocol — CDP). Когда механизм маршрутизации на основе политики не может обнаружить точку следующей передачи в CDP- таблице, он прекращает передавать соответствующие пакеты в эту точку и перенаправляет их, используя таблицу маршрутизации. Маршрутизатор возвращается к осуществлению маршрутизации на основе политики, когда точка следующей передачи опять становится доступной (это определяется с помощью протокола CPD). Эту функциональность можно применять только в том случае, если на интерфейсе активизирован протокол CDP.
Практический пример В.1: маршрутизация на основе IP-приоритета
Компания, занимающаяся электронной коммерцией, подключена к своему поставщику услуг Internet с помощью высокоскоростного О53-соединения и низкоскоростного Т1- канала. Компания использует IP-приоритет для дифференциации различных типов трафика на основе таких критериев, как тип трафика приложения, важность пользовательского трафика и т.д. Компания желает использовать скоростной О83-канал только для передачи важного трафика с приоритетом 4, 5, 6 или 7. Остальной трафик с более низким IP- приоритетом должен передаваться по низкоскоростному каналу Т1. На рис. В.1 показан пример трафика, маршрутизируемого на основе политики.
— 65— 65Hssi3/0/0 181.188.10.8/30 10Hssi3/0/0 181.188.10.8/30 10Sarial4/0/0 181.188.10.12/30 14Sarial4/0/0 181.188.10.12/30 14[Трафик с приоритатом 0,1, 2, 3][Трафик с приоритатом 0,1, 2, 3]IR 211.201.201.64/27IR 211.201.201.64/27[Трафик с приоритетом 4, 5, 6, 7][Трафик с приоритетом 4, 5, 6, 7]FastEtharnat2/0/1FastEtharnat2/0/1Поставщик услугПоставщик услуг
— 65
— 65
Hssi3/0/0 181.188.10.8/30 10
Hssi3/0/0 181.188.10.8/30 10
Sarial4/0/0 181.188.10.12/30 14
Sarial4/0/0 181.188.10.12/30 14
[Трафик с приоритатом 0,1, 2, 3]
[Трафик с приоритатом 0,1, 2, 3]
IR 211.201.201.64/27
IR 211.201.201.64/27
[Трафик с приоритетом 4, 5, 6, 7]
[Трафик с приоритетом 4, 5, 6, 7]
FastEtharnat2/0/1
FastEtharnat2/0/1
Поставщик услуг
Поставщик услуг
Рис. В. 1. Трафик, маршрутизируемый на основе политики с учетом значения IP-npuopumema
В листинге В.1 показана конфигурация маршрутизатора Internet (Internet Router — IR) компании, занимающейся электронной коммерцией, необходимая для маршрутизации пакетов на основе значения их IP-приоритета.
Листинг ВЛ. Конфигурация маршрутизатора IR для маршрутизации 1
, пакетов на основе значения их IP-приоритета
interface FastEthernet 2/0/1
ip address 211.201.201.65 255.255.255.224
ip policy route-map tasman
any precedence routineany precadence priorityany precedence immediateany precedence flashany precedence flash-override any precedence critical any precedence internet any precedence networkany precedence routineany precadence priorityany precedence immediateany precedence flashany precedence flash-override any precedence critical any precedence internet any precedence networkaccess-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
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
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
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-команды, соответствующие механизму маршрутизации на основе политики.
■ Листинг В.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 Листинг В.З. Конфигурация маршрутизатора, необходимая для установки |/ значения IP-приоритета пакета в зависимости о т е го размера
interface FastEthernet 4/0/1
ip address 201.201.201.9 255.255.255.252 ip policy route-map tasman
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-приоритета пакета, после чего тот передается без изменений локальным и всеми промежуточны-
ми поставщиками услуг до тех пор, пока не достигнет пункта назначения. Следует отметить, что этот вариант не является ни реальным, ни, в некоторым смысле, приемлемым. В большинстве случаев исходный поставщик услуг ограничивает входящий трафик и его уровень обслуживания для того, чтобы удостовериться, что они не вышли за рамки установленного профиля трафика. ,
Локальный по отношению к машине-источнику поставщик услуг может гарантировать определенный уровень обслуживания, заданный на основе IP-приоритета, внутри своей сети. Однако после того как пакет покидает сеть локального поставщика услуг и переходит в другую сеть, подсоединенную к пункту назначения, исходный поставщик услуг уже не может гарантировать определенный уровень обслуживания до тех пор, пока он не заключит определенное соглашение об уровне обслуживания (Service Level Agreement — SLA) для своего трафика с другими поставщиками услуг.
В этом разделе не рассматриваются подробности распространения QoS-политик среди поставщиков услуг, так как оно зависит от заключенных между поставщиками услуг соглашений SLA. Мы сконцентрируем свое внимание на распространении информации о QoS-политиках в сетях клиентов поставщика услуг. Весь входящий или исходящий трафик клиента получает свою QoS-политику (IP-приоритет) в точке входа в сеть поставщика. Как обсуждалось ранее, пограничный маршрутизатор поставщика услуг, подсоединенный к клиенту, может устанавливать QoS-политику путем установки значения поля IP- приоритета пакета на основе его уровня обслуживания. Значение приоритета используется для указания уровня обслуживания пакета устройствам сети поставщика услуг.
Поскольку Intemet-трафик асимметричен, трафик, предназначенный для важного клиента, может поступить к его поставщику услуг через любой из его пограничных маршрутизаторов. Возникает вопрос: как сделать так, чтобы все маршрутизаторы в сети поставщика услуг распознавали входящий трафик важного клиента и устанавливали значение IP-приоритета пакетов, основываясь на его уровне обслуживания? В этом разделе рассматриваются способы использования протокола BGP для распространения QoS-политик, предназначенные специально для решения подобных ситуаций.
Распространение QoS-политик с помощью протокола BGP — это механизм классификации пакетов на основе информации об IP-префиксе, BGP-сообществе и пути автономной системы (autonomous system — AS) BGP. Поддерживаемые политики классификации включают в себя установку IP-приоритета и способность отмечать пакет с помощью внутреннего для маршрутизатора идентификатора QoS-класса — QoS-группой (QoS group). После того как пакет был классифицирован, можно воспользоваться другими механизмами QoS, например механизмом согласования скорости доступа (Committed Access Rate — CAR) или взвешенным алгоритмом произвольного раннего обнаружения (Weighted Random Early Detection — WRED) для реализации бизнес-политик и формирования бизнес-модели. Более подробно алгоритмы CAR и WRED обсуждаются в главе 3, “Формирование трафика на границе сети: классификация пакетов, маркировка пакетов и управление интенсивностью трафика", и в главе 6, “РНВ-политика: предотвращение перегрузки и политика отбрасывания пакетов".
Распространение QoS-политик с помощью протокола BGP требует функционирования механизма коммутации CEF. Более подробно CEF-коммутация обсуждается в приложении Б, “Механизмы коммутации пакетов”. Любая QoS-политика BGP передается из таблицы маршрутизации BGP в CEF-таблицу через таблицу маршрутизации 1Р. Запись CEF-таблицы для префикса пункта назначения отмечается с помощью
QoS-политики BGP. Во время CEF-коммутации пакета QoS-политика применяется к пакету согласно информации в CEF-таблице.
Практический пример В.З: применение политики QoS для входящего и исходящего трафика
Поставщик услуг Internet (ISP), использующий в своей сети QoS-политики, начал предлагать своим клиентам обслуживание за дополнительную плату. Последнее предполагает более высокий приоритет обслуживания для входящего и исходящего трафика важных клиентов по сравнению с остальным трафиком сети, который передается методом негарантированной доставки.
QoS-политики поставщика услуг Internet предполагают дифференциацию трафика на основе IP-приоритета, обеспечивая самый высокий приоритет обслуживания трафику со значением IP-приоритета 7, а самый низкий — трафику, передаваемому методом негарантированной доставки (приоритет 0). При этом трафику важных клиентов назначается IP-приоритет 4. Реализация дифференцированных услуг в сети ISP схематически показана на рис. В.2.
Рис. В.2. Политика IP QoS для входящего и исходящего Internet-трафика
В данном примере поставщик услуг должен реализовать следующую конфигурацию.
Трафик важного клиента, предназначенный для передачи в Internet, должен получать улучшенное обслуживание внутри сети поставщика услуг. С этой целью на входе в сеть поставщика услуг данному трафику необходимо присвоить приоритет 4, вследствие чего он будет получать улучшенное обслуживание во всей сети поставщика услуг.
Internet-трафику, предназначенному для передачи в сеть важного клиента, необходимо присвоить приоритет 4 в точке входа в сеть поставщика услуг: в маршрутизаторе BR-1, BR-2 или BR-3. Трафик с IP-приоритетом 4 получает улучшенное обслуживание во всей сети поставщика услуг.
Маршрутизатор BR-2 подключен к сети важного клиента (см. рис. В.2). Следовательно, весь входящий трафик, передающийся по соединению с важным клиентом, получает улучшенное обслуживание в сети поставщика услуг. Улучшенное обслуживание идентифицируется IP-приоритетом 4 в заголовке пакета. Входящий Intemet- трафик, предназначенный для передачи в сеть важного клиента, может поступать либо через маршрутизатор 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 устанав-
ливается IP-приоритет 4, а затем эта информация переносится в CEF-таблицу. Более того, с помошью команды route-map premium маршрутам, полученным из сети важного клиента, назначается атрибут сообшества 109:4. Используя эти сведения, маршрутизаторы сети поставщика услуг смогут назначать соответствующие политики.
Обратите внимание, что команда bgp-policy source ip-prec-map используется на интерфейсе Serial4/0/l, вследствие чего механизм распространения QoS-политик с помошью протокола BGP применяется ко всем пакетам важного клиента. Отображение IP-приоритета осуществляется на основе адреса источника входящего пакета с помошью значения приоритета, ассоциированного с соответствующей CEF-записью для IP-адреса источника. Internet-трафик, предназначенный для передачи в сеть важного клиента, может входить в сеть его поставщика услуг через любой из пограничных маршрутизаторов, имеющих соединение с сетями других поставщиков услуг. Следовательно, информация о 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-политик .
i■ с помощью протокола 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-
сообщества, последние два байта которого установлены в 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-политике из таблицы маршрутизации и использует ее для установки политики пакета перед тем, как передать его дальше по сети.
Приложение
Транспортный протокол реального времени (RTF)
Транспортный протокол реального времени (Real-time Transport Protocol — RTP) предназначен для передачи по ГР-сети потоков трафика масштаба реального времени, такого, ' , как объединенные в пакеты аудио-и видеоданные1. Протокол RTP имеет стандартный - формат заголовка, включающий в сёбя, кроме всего прочего, порядковый номер, обуслов- <; ленную средой передачи временную метку, идентификатор источника и идентификатор полезной нагрузки. Как правило, притранспортировке данных протокол RTP полагается на протокол передачи датаграмм пользователя (User Datagram Protocol — UDP).
Дополнением к протоколу RTP является протокол управления передачей реального времени (Real-time 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 — протокол резервирования ресурсов).
1 RTP: A Transport Protocol for Real-Time Applications, RFC 1889/Jacobson V., January 1996.
Приложение
д
Общие функции линейной эфективности протокола IP
В этом приложении рассматриваются следующие функции линейной эффективности протокола 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, и ( байт — TCP-заголовок) для каждого байта пользовательских данных. Использование пакетов столь небольшого объема, известных также под названием миниграмм (tinygrams), не является проблемой в локальных сетях (LAN), однако ■ такие пакеты могут существенно уменьшить доступную полосу пропускания на медленных ; или перегруженных каналах передачи информации. Главная задача алгоритма Нагля* — повышение эффективности использования полосы пропускания для ТСР-трафика.
Ниже приводится описание TCP-сеанса в соответствии с алгоритмом Нагля. Каждое TCP-соединение может иметь только один незавершенный (или, другими словами, неподтвержденный) сегмент. Пока ожидается подтверждение (acknowledgement — . АСК), происходит процесс накопления дополнительных данных, которые передаются при получении подтверждения как один сегмент. Вместо передачи информации по одному символу, TCP-сеанс старается сформировать большой сегмент путем накопления символов и отправить его сразу же после получения подтверждения о доставке предыдущего сегмента. Механизм самосинхронизации позволяет TCP-сеансу отправлять меньше сегментов по медленным или перегруженным каналам связи по сравнению с быстрыми и незагруженными каналами.
Алгоритм Нагля активизируется с помощью команды service nagle. Несмотря на то что эффективность этого алгоритма может быть невысокой в случае применения к трафику терминальных приложений на медленных или перегруженных каналах, в целом он зарекомендовал себя великолепно для большей части ТСР-трафика.
1 Congestion Control in IP/TCP Internetworks/Nagle J., 1984. — RFC 896.
Функция определения максимально возможной единицы передачи данных (MTU) пути
Функция определения максимально возможной единицы передачи данных пути используется для динамического определения значения 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/IP применяется для повышения эффективности использования полосы пропускания медленных последовательных каналов передачи информации. Типичный ТСР/1Р-пакет включает в себя 20-байтовые заголовки IP и TCP. После установки TCP-соединения информация заголовка становится избыточной и не требует пересылки в каждом пакете. Путем изменения заголовка, который теперь будет включать в себя идентификатор соединения и информацию об изменившихся полях, можно добиться уменьшения объема передаваемых пакетов. В среднем размер сжатого TCP/IP- заголовка составляет 10 байт в отличие от 40 байт в несжатом состоянии.
Для активизации механизма сжатия TCP-заголовка на интерфейсе используется команда ip top header compression.
Сжатие RTP-заголовка
Как правило, размеры RTP-пакетов аудиоприложений варьируются в пределах от 20 до 150 байт при условии сжатия полезной нагрузки. Типичный уровень избыточности информации, содержащейся в IP-, UDP- и RTP-заголовках, достаточно высок. Минимальная длина IP/U DP/RTP-заголовка составляет 40 байт, если считать, что минимальная длина IP-, UDP- и RTP-заголовка равна 20, 12 и 8 байт, соответственно.
Механизм сжатия RTP-заголовка, реализация которого напоминает реализацию механизма сжатия TCP-заголовка (RFC 1144), в среднем позволяет сжать 40-байтовый заголовок до 10 байт.
Приложение
Е
Фрагментация и чередование пакетов на канальном уровне
В этом приложении рассматривается функция фрагментации и чередования пакетов канального уровня (Link-Layer Fragmentation and Interleaving — LFI) с использованием многоканального двухточечного протокола (Multi-Link Point-to-Point — MLPP). Механизм канального уровня LFI, позволяет повысить эффективность и предсказуемость услуг, предоставляемых для критического трафика приложений.
Протокол MLPP позволяет распределить трафик по нескольким РРР-каналам глобальных сетей (Wide Area Network,— WAN), обеспечивая при этом функциональную совместимость устройств разных производителей, а также фрагментацию и упорядочение пакетов. В главе 8, “Качество обслуживания на уровне 2: межсетевой обмен с IP QoS’’, рассматривался стандарт FRF.12, описывающий функции фрагментации и чередования пакетов в сетях Frame Relay.
Даже несмотря на применение таких алгоритмов планирования очередей, как CBWFQ (Class-Based Weighted Fair Queuing — взвешенный алгоритм равномерного обслуживания очередей на основе класса) с приоритетной очередью и протокола RSVP (Resource Reservation Protocol — протокол резервирования ресурсов), интерактивный трафик масштаба реального времени все еще может испытывать существенные задержки блокирования, вызванные наличием пакетов большого размера, в особенности на медленных последовательных линиях связи. Если пакет голосового трафика поступил в маршрутизатор в момент обработки некоторого другого пакета большого размера, то обработка пакета голосового трафика будет отложена до тех пор, пока не будет передан большой пакет. Естественно, подобная схема является абсолютно неприемлемой для трафика масштаба реального времени, такого, как трафик интерактивных приложений, ориентированных на передачу оцифрованного голоса. Следует отметить, что эффективная работа последних достигается при условии сквозной задержки не более 100-150 мс.
Механизм LFI предполагает фрагментацию кадров большого размера и их чередование с маленькими, чувствительными к задержке, кадрами, перед постановкой в очередь на передачу. Такой подход позволяет существенно уменьшить задержку при передаче маленьких пакетов трафика масштаба реального времени. Следует также отметить, что фрагментированные кадры восстанавливаются в точке назначения.
Для обеспечения надлежащего уровня обслуживания голосового трафика масштаба реального времени механизм LF1 может использоваться совместно с механизмом CBWFQ с приоритетной очередью (рис. 1.1).
Рис. Е. 1. Иллюстрация работы механизма фрагментации и чередования пакетов канального уровня
Как показано на рис. Е.1, голосовой трафик масштаба реального времени ставится на обработку в приоритетную очередь. Весь остальной трафик обрабатывается с помощью одной или нескольких очередей механизма WFQ (Weighted Fair Queuing — взвешенный алгоритм равномерного обслуживания очередей). Пакеты, принадлежа- шие обычному трафику, фрагментируются с целью уменьшения задержки блокирования при обработке пакетов голосового трафика. Фрагменты пакетов трафика данных ставятся на обработку в WFQ-очереди, которые вместе с очередью голосового трафика обслуживаются в соответствии с алгоритмом CBWFQ с приоритетной очередью. Теперь максимальная задержка блокирования пакетов голосового трафика равняется задержке сериализации фрагментированных пакетов обычного трафика данных. В табл. Е.1 отражена зависимость размеров фрагментов от скорости канала передачи информации при задержке блокирования 10 мс.
Таблица ЕЛ. Зависимость размеров фрагментов от скорости канала '1
передачи информации при задержке блокирования 10 мс j
Скорость линии связи, Кбит/сРазмер фрагмента, байт
56
70
64
80
128
160
256
320
512
640
768
1000
Механизм LFI гарантирует, что голосовые и другие пакеты небольшого размера не будут неприемлемо долго блокироваться пакетами большого размера. Кроме того, LFI старается обеспечить более равномерную передачу маленьких пакетов, тем самым снижая их дрожание. Подобная функциональность позволяет сети эффективно передавать обычный трафик совместно с голосовым и другим чувствительным к задержке трафиком.
Примечание
Как уже отмечалось, механизм MLPP LFI используется совместно с механизмом CBWFQ для минимизации задержки голосового трафика, обрабатывающегося с помощью приоритетной очереди. В листинге Е.1 приведена соответствующая конфигурация маршрутизатора.
В этом примере конфигурация MLPP-связки применяется к интерфейсу virtual- template. Интерфейсы SerialO и SeriaH включаются в 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
Приложение
ж
Значения поля IP-приоритета и поля DSCP
IP-приоритет: 3 бит (Р2-Р0)
Тип обслуживания (ToS): 4 бит (ТЗ-ТО)
Не используется (CU): 1 бит
Рис. Ж.1. Биты поля приоритета протокола IP (Internet Protocol) в байте типа обслуживания (Type of Service — 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): 101110;
РНВ-политика гарантированной передачи (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 2 3 4 5 6 7О 1 2 3 4 5 6 7О 8 16 24 32 40 48 56
О 1 2 3 4 5 6 7
О 1 2 3 4 5 6 7
в табл. Ж.5 показано отображение поля DSCP на поле IP-приоритета.
Таблица Ж.5. Отображение поля DSCP на поле IP-приоритета \>
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
Предметный указатель
AD
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 (C1R), 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
(FDD1), 72
File Transfer Protocol (FTP), 21; 105;
185; 313
First In, First Out (FIFO), 91
First-ln, 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 (HEC), 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
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 РНВ), 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
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/lnternet 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.
К
Канальный уровень
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-depthfactor, 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
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
Очередь
алгоритм превентивного
управления очередью 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
адаптивный механизм выравнивания трафика и интеграция 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
применение механизма WRED для предотвращения перегрузки канала передачи информации, 161
применение услуги ABR к каналу РУС, 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/Internet 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
предоставление сквозных услуг 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
протокол 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
Научно-популярное издание
Шринивас Вегешна
Качество обслуживания в сетях IP
Литературный редактор Верстка Художественный редактор КорректорыЛитературный редактор Верстка Художественный редактор КорректорыС. Г. Езерницкая
Литературный редактор Верстка Художественный редактор Корректоры
Литературный редактор Верстка Художественный редактор Корректоры
О.В. Линник
В. Г. Павлютин
З.В. Александрова, Л.А. Гордиенкс и О.В. Мишу тина
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.Изд. лиц. ЛР № 090230 от 23.06.99Госкомитета РФ по печати.
Подписано в печать 23.12.2002. Формат 70x100/16.Гарнитура Times. Печать офсетная.
Усл. печ. л. 29,7. Уч.-изд. л. 21,0.Тираж 2500 экз. Заказ № 2020.
Отпечатано с диапозитивов в ФГУП “Печатный двор”Министерства РФ по делам печати,телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
Качество обслуживании в сетях IP
2 Resource Reservation Protocol (RSVP) Version 1 Applicability Statement, Some Guidelines on De- ployment/Mankin A. et al. — RFC 2208, 1997.
* * , -. всех каналов с активизированным npOTOKondM MPLS на1 $ •
идентификатором ^22^2^222.2^1
4c7507=Rl#sh mpls traffic-eng topology 222.222.222.2
IGP Id: 0000.0000.0002.00, MPLS ТЕ Id:222.222.222.2 Router ^Node, Internal Node_id 3
link[0 ]:Nbr IGP Id: 0000.0000.0004.00, nbr_node_id:2
Intf Address:222.222.222.25, Nbr Intf Address: ^222.222.222.26
admin_weight:10, affinity_bits:0x0