Возможности администратора повлиять на выбор пути Bandwidth Priority Administrative Weight Attributes & Affinity

Bandwidth ip rsvp bandwidth Позволяет протоколу RSVP динамически резервировать до X Кбит/c пропускной способности на определенном интерфейсе X – верхний предел резервирования в Кбит/с Y – в MPLS не использкется default: X==Y==75% пропусной способности интерфейса

Priority tunnel mpls traffic-eng {H} Конфигурируется на интерфейсе типа tunnel S = setup priority (0-7) - установка H = holding priority (0-7) - удержание 0 – высший приоритет

Priority Новый туннель с более высоким приоритетом установки может вытеснить (разорвать) туннель с более низким приоритетом удержания, если ему нужна пропускная способность старого туннеля Конфигурирование S

Priority RtrB RtrA RtrC RtrD 45MB = 40MB tunnel S=7, H=7 = 40MB tunnel S=6, H=6

Priority RtrB RtrA RtrC RtrD 45MB = 40MB tunnel with S=7, H=7 = 40MB tunnel with S=6, H=6 ResvTear RtrC посылает сообщение ResvTear протокола RSVP к RtrA, туннель разрушается

Administrative Weight mpls traffic-eng administrative- weight Команда конфигурирования физического интерфейса X = 0, 1, … (2 32 –1) Назначает метрику, которая заменяет метрику IGP

Administrative Weight tunnel mpls traffic-eng path- selection metric {te|igp} Команда конфигурирования туннеля Default параметр - igp Параметр te приведет к использованию сконфигурированной административной метрики administrative-weight при выборе пути для туннеля Обычно используется при учете задержек каналов – чувствительная к задержкам метрика

Чувствительная к задержкам метрика tunnel mpls traffic-eng path-selection metric {te|igp} mpls traffic-eng administrative-weight Сконфигурируйте admin weight == interface delay Сконфигурируйте VoIP туннели для использования метрики TE metric при выборе пути

Attributes & Affinity Атрибуты – 32 бита, описывающие некоторые свойства канала связи Affinity туннеля (сходство) – желание проложить туннель через каналы с определенными свойствами

mpls traffic-eng attribute- flags Команда физического интерфейса Attributes & Affinity

tunnel mpls traffic-eng affinity {mask } Команда конфигурирования туннеля Маска определяет биты «интереса» Биты affinity определяют желаемые значения бит интереса: 0x2 mask 0xA - «меня интересуют биты 2 and 8; бит 2 должен быть установлен в 1, а бит 8 - в 0» Attributes & Affinity

Пример: чтобы исключить спутниковые каналы из туннеля для VoIP, нужно дать таки каналам атрибут 0x2, а туннель для VoIP сконфигурировать как affinity 0x0 mask 0x2 Attributes & Affinity

Auto-Bandwidth – динамическое изменение резервирования полосы tunnel mpls traffic-eng auto-bw ? collect-bw Just collect Bandwidth info on this tunnel frequency Frequency to change tunnel BW max-bw Set the Maximum Bandwidth for auto-bw on this tunnel min-bw Set the Minimum Bandwidth for auto-bw on this tunnel Команда конфигурирования туннеля Периодически изменяет зарезервированную полосу для туннеля в зависмости от трафика, протекакющего через туннель Настраиваемый таймер периода

Защита путей и каналов В обычной IP сети отказ канала приводит к простою в несколько секунд Этап От чего зависит его продолжительность Время Обнаружение отказа канала Зависит от платформы~ мкс (POS + APS) Распространение информации оботказе IGP таймеры~5-30 сек Вычисление нового пути Размерность топологической базы, CPU ~1-2сек

В сети MPLS нужно выполнить несколько больше действий для перехода на новый путь LSP Защита путей и каналов Этап От чего зависит его продолжительность Время Обнаружение отказа канала Зависит от платформы~ мкс (POS + APS) Распространение информации оботказе IGP таймеры~5-30 сек Вычисление нового пути Размерность топологической базы, CPU ~1-2 сек Установка нового пути LSP Размер сети~1-5 сек

Стандартная защита пути в MPLS tunnel mpls traffic-eng path-option 1 explicit name straight tunnel mpls traffic-eng path-option 2 dynamic Задается две опции для туннеля: Основная – точный статический путь Резервная – динамически вычисляемый путь после отказа основого

Fast ReRouting (Cisco)– быстрый переход на новый путь Link Protection Единственная схема, реализованная сегодня Node Protection Разрабатывается Path Protection Дальняя цель разработчиков

Link Protection TE туннель A->B->D->E RtrDRtrB RtrC RtrERtrA

Link Protection B имеет предварительно установленный туннель к дальнему концу защищаемой линии (RtrD) B считает, что D использовал при привязывании метки глобальное (платформенно-специфическое) пространство меток RtrDRtrB RtrC RtrERtrA

Link Protection Связь B->D отказывает, туннель A->E инкапсулируется в туннель B->D Резервный туннель используется до тех пор, пока A не вычислит новый путь для туннеля A->B->C->D->E ( сек) RtrC RtrERtrA RtrDRtrB

Link Protection Конфигурирование туннеля в ingress LSP: tunnel mpls traffic-eng fast-reroute RtrC RtrERtrA RtrDRtrB На защищаемой линии: mpls traffic-eng backup-path

Два подхода к поддержке QoS в сетях MPLS DS-TE: Diffserv-aware Traffic Engineering (L-LSP) Отдельные пути (и резервирование) для транков трафика разных классов DiggServ Набор расширений протоколов, используемых для MPLS TE Изменения в протоколах сигнализации (резервирование) – никаких новых механизмов QoS при передаче данных Не дают гарантированного QoS MPLS DS (E-LSP) DSCP -> EXP EXP -> PHB конфигурируется вручную

Резервирование полосы в TE Find route & set-up tunnel for 20 Mb/s from POP1 to POP4 POP4 POP POP2 POP1 WAN area Find route & set-up tunnel for 10 Mb/s from POP2 to POP4

Пример проблемы с голосовым трафиком в MPLS TE 2 туннеля через связь C E 40MB каждый туннель 100MB свободной полосы на связи C E, 55 МВ уже переносят голосовой трафик Что будет, если каждый туннель будет переносить по 20MB трафикаVoIP? RtrARtrB RtrC RtrE RtrD RtrF RtrG

Проблема: один пул пропускной способности для интерфейса, нет возможности дифференцировать тип трафика! Решение: поддерживать несколько пулов RtrARtrB RtrC RtrE RtrD RtrF RtrG 55MB LLQ+40MB LLQ = 95 MB LLQ – на 25МВ больше 50% канала – большие задержки голоса Пример проблемы с голосовым трафиком в MPLS TE

Задержка как функция коэффициента использования Utilization Delay 0% 100% % Цель для EF Цель для Data Premium – AF1 Цель для Best-Effort Если для EF трафика < %, то задержка EF будет меньше M1 ms Если для AF1 трафика < %, то задержка AF1 будет меньше M2 ms %

Diffserv-Aware Traffic Engineering ip rsvp bandwidth sub-pool «эта связь имеет резервируемую полосу X, Y из которой – это sub-pool» Для приоритетного трафика доступно только Y Кбит/c, которые также входят в пул X

Пулы пропускной способности Общая величина пула TE Пул для приоритетного трафика, если он недоиспользован, то полоса отдается общему пулу

Diffserv-Aware Traffic Engineering tunnel mpls traffic-eng bandwidth sub-pool Создание туннеля для приоритетного трафика, который резервирует X Кбит/с из sub-pool Если в sub-pool уже нет достаточной полосы, то туннель не устанавливается Трафик с этой меткой направляется в приоритетную очередь

Стандартизация DS-TE Начало – середина 2000 Internet Drafts: draft-ietf-tewg-diff-te-reqts-00.txt draft-ietf-mpls-diff-te-ext-01.txt draft-ietf-ospf-diff-te-00.txt draft-ietf-isis-diff-te-00.txt

Сеть TE - Best Effort Find route & set-up tunnel for 20 Mb/s from POP1 to POP4 POP4 POP POP2 POP1 WAN area Find route & set-up tunnel for 10 Mb/s from POP2 to POP4

Сеть TE и MPLS Diff-Serv Find route & set-up tunnel for 20 Mb/s (aggregate) from POP1 to POP4 Find route & set-up tunnel for 10 Mb/s (aggregate) from POP2 to POP4 POP4 POP POP2 POP1 WAN area

DiffServ Aware Traffic Engineering Find route & set-up tunnel for 5 Mb/s of EF from POP1 to POP4 Find route & set-up tunnel for 3 Mb/s of EF from POP2 to POP4 POP4 POP POP2 POP1 WAN area Find route & set-up tunnel for 15 Mb/s of BE from POP1 to POP4 Find route & set-up tunnel for 7 Mb/s of BE from POP2 to POP4

Обобщенная коммутация на основе GMPLS Единицы коммутации: Тайм-слоты и виртуальные контейнеры SDH/PDH Световые волны (лямбды) DWDM Оптические волокна (порты) Метка GMPLS представляет собой условный номер волокна, длины волны или тайм-слота в виртуальном контейнере Протокол сигнализации из архитектуры GMPLS позволяет динамически сформировать оптический путь через SDH- мультиплексоры и DWDM кросс-коннекторы – гигабиты по требованию Устройства узнают топологию сети и состояния каналов по традиционным протоколам маршрутизации сетей IP: OSPF и IS-IS с расширениями Переход на заранее определенный резервный маршрут – десятки миллисекунд, как в SDH

Иерархия уровней коммутации в GPMLS IPSDH Fiber SDHIP IP-пакеты Тайм-слоты и виртуальные контейнеры Волны Волокна Сигнализация GMPLS управляет расстановкой меток в разнотипном оборудовании – общая плоскость управления Пути вкладываются друг в друга: Пути IP-пакетов объединяются в SDH/PDH пути SDH/PDH пути объединяются в пути оптических волн Пути оптических волны объединяются в волокна

Стандартизация GMPLS Начальная стадия разработки стандартов – Internet Draft В разработке участвуют многие ведущие производители магистрального оптического оборудования – Nortel, Alcatel, Lucent, Siemens, Cisco, Juniper, CIENA и многие другие Форум Optical Internetworking Forum разработал проект спецификации пользовательского интерфейса доступа к оптическому ядру – Optical UNI Совместимость реального оборудования по интерфейсу Optical UNI была продемонстрирована в ходе конференции-шоу SuperComm В демонстрации использовалось оборудование 25 производителей, в том числе Nortel, Lucent, Cisco, Alcatel, CIENA, Sycamore