2004 г.
Семёнов Ю.А. (ГНЦ ИТЭФ),
D. Awduche, Requirements for Traffic Engineering Over MPLS, RFC-2702
1.0. Введение
Мультипротокольная коммутация пакетов по меткам (MPLS) [1,2] интегрирует в себе технику операций с метками и сетевую маршрутизацию. Базовой идеей является присвоение меток фиксированной длины пакетам на входе облака MPLS (базирующегося на концепции переадресации классов эквивалентности [1,2]). Всюду внутри домена MPLS, метки, присвоенные пакету, используются для принятия решения о переадресации (обычно без рассмотрения исходных заголовков пакета).
Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [1,2,3]).
Этот документ ориентирован исключительно на управление трафиком (Traffic Engineering) в рамках MPLS. Главной целью является рассмотрение требований управления трафиком в больших опорных сетях Интернет. Описаны базовые возможности и функциональности, которым должна соответствовать реализация MPLS.
Следует заметить, что хотя основное внимание уделено опорным сетям, возможности, описанные в этом документе, в равной мере применимы для управления трафиком в корпоративных сетях. Вообще, эта технология может быть использована в любой сети с коммутацией по меткам, в которой имеется, по крайней мере, два пути между двумя узлами.
Предлагается архитектура, которая включает в себя MPLS и RSVP, чтобы предоставить масштабируемые дифференцированные услуги и управление трафиком в Интернет.
2.0. Управление трафиком
В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами. В этом разделе обосновываются требования, предъявляемые к MPLS.
Управление трафиком (TE) связано с оптимизацией рабочих характеристик сетей. Вообще, ТЕ включает в себя технологию и научные принципы измерения, моделирования, описание, управление трафиком Интернет и приложение таких знаний и техники для получения определенных рабочих характеристик.
Главной целью управления трафиком в Интернет является достижение эффективной и надежной работы сети. Управление трафиком стало непременной функцией многих автономных систем, из-за высокой стоимости услуг Интернет.
2.1. Объективные характеристики управления трафиком
Ключевые характеристики, сопряженные с управлением трафиком, могут относиться к следующим категориям:
1. ориентированные на трафик или
2. ориентированные на ресурсы.
Задачи, ориентированные на управление трафиком, включают в себя аспекты улучшения QoS информационных потоков. В модели “оптимальных усилий” для Интернет-сервиса ключевая задача управления трафиком включает в себя: минимизацию потерь пакетов и задержек, оптимизацию пропускной способности и согласование наилучшего уровня услуг. В данной модели минимизация вероятности потери пакетов является наиболее важным аспектом. Статистически заданные характеристики трафика (такие как разброс времени доставки пакетов, вероятность потери и максимальное время доставки) становятся важными в грядущих дифференцированных услугах Интернет. Одним из подходов решения таких проблем является оптимизация использования всех имеющихся ресурсов сети. В частности, желательно гарантировать, чтобы субнаборы сетевых ресурсов не были перегружены, в то время как аналогичные ресурсы на альтернативных маршрутах недогружены. Полоса пропускания является критическим ресурсом современных сетей. Следовательно, центральной функцией управления трафиком является эффективное управление пропускной способностью.
Минимизация перегрузок является первичной задачей. Здесь речь идет не о кратковременных перегрузках, а о долгосрочных, влияющих на поведение сети в целом. Перегрузка обычно проявляется двояко:
1. Когда сетевых ресурсов недостаточно или они не соответствуют существующей загрузке.
2. Когда потоки трафика неэффективно распределены по имеющимся ресурсам.
Первый тип проблем перегрузки может быть решен путем:
(i) расширения ресурса, или
(ii) применением классических средств управления перегрузкой, или
(iii) сочетанием этих подходов. Классическое управление перегрузкой пытается регулировать уровень потребности, снижая его до имеющегося в распоряжении уровня ресурсов. Классическое управление перегрузкой включает в себя: ограничение потока, управление шириной окна для потока, управление очередями в маршрутизаторе, диспетчеризацию и т.д. (смотри [8]).
Второй тип проблем перегрузки, связанный с неэффективным размещением ресурсов, может быть решен посредством управления трафиком.
Вообще, перегрузка, связанная с неэффективным размещением ресурсов, может быть уменьшена с помощью политики балансировки нагрузки в различных фрагментах сети. Задачей таких стратегий является минимизация максимальной перегрузки или напротив минимизация максимума использования ресурса. Когда перегрузка минимизирована путем оптимального размещения ресурсов, потери пакетов и задержка доставки падают, а совокупная пропускная способность возрастает. Таким образом, восприятие конечным пользователем качества сетевого обслуживания становится лучше.
Понятно, что балансировка определяет политику оптимизации рабочих характеристик сети. Не смотря ни на что, возможности, предоставляемые управлением трафиком, должны быть достаточно гибкими, чтобы сетевые администраторы могли реализовать другие политики, которые принимают во внимание господствующую структуру цен или даже модель получения доходов.
2.2. Управление трафиком и ресурсами
Оптимизация рабочих характеристик сетей является фундаментальной проблемой управления. В модели процесса управления трафиком, инженер трафика, или подходящая система автоматизации, действует как контроллер в системе с адаптивной обратной связью. Эта система включает набор взаимосвязанных сетевых элементов, систему мониторирования состояния сети, и набор средств управления конфигурацией. Инженер трафика формулирует политику управления, отслеживает состояние сети посредством системы мониторинга, характеристики трафика, и предпринимает управляющие действия, чтобы перевести сеть в требуемое состояние, в соответствии с политикой управления. Это может быть осуществлено с помощью действий, предпринимаемых как отклик на текущее состояние сети, или превентивно, используя прогнозирование состояния и тенденции и предпринимая действия, предотвращающие нежелательные будущие состояния.
В идеале управляющие действия должны включать:
1. Модификацию параметров управления трафиком,
2. Модификацию параметров, связанных с маршрутизацией, и
3. Модификацию атрибутов и констант, связанных с ресурсами.
Уровень человеческого вмешательства в процесс управления трафиком, когда это возможно, должен быть минимизирован. Это может быть реализовано путем автоматизации операций, описанных выше. Операции эти могут быть распределенными и масштабируемыми.
2.3. Ограничения механизмов управления IGP
В этом подразделе рассматриваются некоторые хорошо известные ограничения современных IGP с точки зрения управления трафиком.
Возможности управления, предлагаемые существующими внутренними протоколами маршрутизации шлюзов Интернет, не соответствуют требованиям управления трафиком. Это делает трудным актуализировать эффективные политики, предназначенные для решения проблем совершенствования работы сети. Действительно, IGP, базирующиеся на алгоритмах кратчайшего пути, вносят заметный вклад в проблемы перегрузки в автономных системах Интернет. Алгоритмы SPF базируются на простой аддитивной метрике. Эти протоколы управляются топологией, так что полоса пропускания и параметры трафика не являются факторами, рассматриваемыми в процессе принятия маршрутных решений. Следовательно, перегрузка часто происходит, когда:
1. кратчайшие пути нескольких потоков трафика объединяются в каких-то каналах или интерфейсах маршрутизатора, или
2. данный трафик потока маршрутизирован через канал или интерфейс маршрутизатора, который не имеет достаточной полосы пропускания.
Эти сценарии проявляются даже тогда, когда имеются альтернативные маршруты с избытком ресурсов. Это является тем аспектом проблем перегрузки (симптом неоптимального распределения ресурсов), которой управление трафиком стремится всеми способами избежать. Равномерное распределение загрузки может использоваться для разрешения второй проблемы, упомянутой выше, однако такое решение бесполезно в случае первого варианта перегрузки.
Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких как IP поверх ATM или IP поверх frame relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загруженные каналы.
Для управления трафиком в больших насыщенных сетях желательно снабдить MPLS определенным уровнем функциональности, чтобы сделать его более совместимым с настоящими моделями наложений. К счастью, это может быть сделано достаточно прямолинейно.
3.0. MPLS и управление трафиком
В этом разделе дается обзор применимости MPLS для управления трафиком. В последующих разделах обсуждается набор возможностей, необходимых для удовлетворения требований управления трафиком.
Протокол MPLS стратегически достаточен для управления трафиком, так как он может предоставить большую часть функций, доступных в модели наложений, и по относительно низкой цене по сравнению с конкурирующими альтернативными решениями. Столь же важно, что MPLS предлагает возможность автоматизировать функции управления трафиком. Это последнее соображение требует дальнейшего исследования и находится за пределами рассмотрения данного документа.
Концепция каналов передачи данных MPLS используется достаточно широко в данном документе. Согласно Li и Rekhter [3], канал передачи данных представляет собой объединение потоков данных одного и того же класса, которые следуют маршруту с коммутацией пакетов по меткам. Канал передачи данных представляет собой абстракцию трафика, с которой могут быть ассоциированы определенные характеристики. Полезно рассматривать каналы передачи данных как объекты, которые можно маршрутизировать, то есть, путь, по которому переносятся данные, может меняться. С этой точки зрения, каналы передачи данных подобны виртуальным каналам в сетях ATM и Frame Relay. Важно, однако, подчеркнуть, что существует фундаментальное отличие между каналом передачи данных и путем. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит трафик. На практике, термины LSP и канал передачи данных часто используются синонимично.
Привлекательность MPLS для управления трафиком может быть ассоциирована со следующими факторами:
(1) явные пути с коммутацией меток (которые не ограничиваются парадигмой переадресации, когда маршрут определяется на основе адреса места назначения) могут быть легко сформированы сетевым администратором или посредством стандартных протоколов,
(2) LSP могут поддерживаться эффективно,
(3) Каналы передачи данных могут быть смоделированы и поставлены в соответствие LSP,
(4) Набор атрибутов может быть ассоциирован с каналами передачи данных, которые регулируют их рабочие характеристики,
(5) Набор атрибутов может быть ассоциирован с ресурсами, которые ограничивают положение LSP и каналов передачи данных,
(6) MPLS позволяет как агрегацию так и дисагрегацию трафика, в то время как классическая переадресация на основе IP-адреса места назначения допускает только агрегацию,
(7) Относительно легко интегрировать "маршрутизацию на основе ограничений" в рамках MPLS,
(8) Хорошая реализация MPLS может предложить заметно более низкую избыточность, чем конкурирующие альтернативы управления трафиком.
Кроме того, через механизм коммутации меток MPLS позволяет наложить на современную модель маршрутизации Интернет квазиканальную коммутацию. Многие существующие предложения для управления трафиком посредством MPLS концентрируются на возможности формирования LSP. Хотя такая возможность является фундаментальной для управления трафиком, этого реально недостаточно.
3.1. Наведенный MPLS-граф
В данном подразделе вводится концепция "наведенного MPLS-графа", которая является центральной при управлении трафиком в сфере MPLS. Наведенный MPLS-граф аналогичен виртуальной топологии в модели наложений. Он логически проектируется на физическую сеть путем выбора LSP для каналов транспортировки трафика.
Наведенный MPLS-граф состоит из набора LSR, которые представляют собой узлы графа, и набора LSP, которые предоставляют логические соединение точка-точка между указанными LSR, и, следовательно, служат в качестве каналов наведенного графа. Имеется возможность сформировать иерархический наведенный MPLS-граф, базирующийся на концепции стеков меток (смотри [1]).
Наведенные MPLS-графы важны потому, что базовые проблемы управления полосой пропускания в MPLS определяются тем, как эффективно совместить наведенный MPLS-граф с физической топологией сети. Абстракция наведенного MPLS-графа формализуется ниже.
Пусть G = (V, E, c) является графом, отражающим физическую топологию сети. Здесь, V – набор узлов сети и E – набор каналов; то есть, для v и w из V, объект (v,w) содержится в E, если v и w являются непосредственно связанными в рамках G. Параметр "c" представляет собой набор емкостей и других ограничений, сопряженных с E и V. Мы будем рассматривать G как "основу" сетевой топологии.
Пусть H = (U, F, d) является наведенным MPLS-графом, где U является субнабором V, представляющим набор LSR в сети, или более точно набор LSR, которые являются конечными точками, по крайней мере, одного LSP. Здесь, F представляет собой набор LSP, так что для x и y из U, объект (x, y) находится в F, если существует LSP с x и y в качестве конечных точек. Параметр "d" представляет собой набор требований и ограничений, ассоциированных с F. Очевидно, H является ориентированным графом. Можно видеть, что H зависит от переходных характеристик G.
3.2. Фундаментальные проблемы управления трафиком в MPLS
Существует три фундаментальных проблемы, относящиеся к управлению трафиком в MPLS.
- Первая проблема касается того, как определять соответствие пакетов определенному классу FEC (Forwarding Equivalence Class).
- Вторая проблема касается того, как определять соответствие FEC и каналов передачи данных.
- Третья проблема касается того, как определять соответствие каналов передачи данных физической топологии сети через маршруты с коммутацией по меткам.
Данный документ не касается первых двух перечисленных проблем (хотя они весьма важны). Вместо этого, остальная часть документа посвящена возможностям, которые позволяют третей функции осуществлять эффективную и надежную работу сетей. Установление соответствия между наведенным MPLS-графом (H) и базовой топологией сети (G) является достаточно важной проблемой.
4.0. Расширенные возможности управления трафиком с помощью MPLS
В предыдущих разделах рассмотрены базовые функции управления трафиком в современном Интернет. Остальная часть документа описывает функциональные возможности, необходимые для полномасштабного поддержания управления трафиком в больших сетях через посредство MPLS.
Предлагаемые возможности включают в себя:
1. Набор атрибутов, связанных с каналами передачи данных, совокупность которых характеризует рабочее состояние сети.
2. Набор атрибутов, связанных с ресурсами, которые ограничивают размещение пути информационных потоков. Они могут рассматриваться также как топологические ограничения.
3. "Маршрутизация на основе ограничений", которая используется для выбора пути для канала передачи данных в соответствии с набором параметров пунктов 1 и 2, приведенных выше. Маршрутизация на основе ограничений не должна являться частью протокола MPLS. Однако они должны быть тесно связаны.
Атрибуты, связанные с каналами передачи данных и ресурсами, а также параметры, ассоциированные с маршрутизацией, в совокупности представляют собой набор управляющих переменных, которые могут быть модифицированы в результате либо действий администратора, либо автоматических агентов, для того чтобы привести сеть в желательное состояние.
В рабочей сети, крайне желательно, чтобы эти атрибуты можно было менять динамически в реальном масштабе времени без неблагоприятных последствий.
5.0. Атрибуты и характеристики канала передачи данных
В этом разделе обсуждаются атрибуты, которые можно ассоциировать с каналами передачи данных и которые могут определять рабочие характеристики сети. Базовые свойства каналов передачи данных перечислены ниже:
- Канал передачи данных представляет собой объединение потоков данных, принадлежащих одному классу. В определенном контексте, может быть желательно смягчить это определение и позволить каналам передачи данных содержать мультиклассные объединения потоков.
- В одноклассной модели обслуживания, такой как современный Интернет, канал передачи данных может включать в себя все потоки между входным LSR и выходным LSR.
- Каналы передачи данных являются маршрутизируемыми объектами (аналогично ATM VC).
- Канал передачи данных отличается от LSP, через который он проходит. В операционном контексте, канал передачи данных может быть перенесен из одного пути в другой.
- Каналы передачи данных являются однонаправленными.
На практике, канал передачи данных может характеризоваться своими входным и выходным LSR, FEC, которому он соответствует, и набором атрибутов, которые определяют его рабочие характеристики.
Имеется два пункта особой важности: (1) параметризация каналов передачи данных и (2) положение маршрута и правила управления каналом передачи данных.
5.1. Двунаправленные каналы передачи данных
Хотя каналы передачи данных (traffic trunks) являются концептуально однонаправленными, во многих практических контекстах, полезно одновременно анализировать два канала передачи данных с идентичными конечными точками, но с разным направлением потоков. Два канала передачи данных логически связаны друг с другом. Один канал, называемый прямым, транспортирует трафик от исходного узла к узлу места назначения. Другой канал, называемый обратным, транспортирует трафик от узла места назначения к исходному узлу. Объединение двух таких каналов называется двунаправленным каналом передачи данных BTT (bidirectional traffic trunk), если выполняются следующие два условия:
- Оба канала передачи данных инициализированы одновременно одним и тем же LSR, называемым исходным узлом, или возникли в результате одномоментной операции сетевой управляющей станции.
- Ни один из образующих такую пару каналов не может существовать отдельно. То есть, оба создаются и исчезают одновременно.
Следует также рассмотреть топологические свойства BTT. BTT может быть топологически симметричным или асимметричным. BTT считается "топологически симметричным", если составляющие его каналы передачи данных имеют одни и те же физические маршруты. Если, однако, составляющие его каналы передачи данных маршрутизированы через разные пути, тогда BTT называется "топологически асимметричным".
Следует заметить, что двунаправленные каналы передачи данных имеют в основном административное удобство. На практике, большинство функций управления трафиком могут быть реализованы с использованием исключительно однонаправленных каналов передачи данных.
5.2. Базовые операции для канала передачи данных
Базовые операции в канале передачи данных, важные для целей управления трафиком перечислены ниже.
- Установить (Establish): создать канал передачи данных.
- Активировать (Activate): запустить информационный обмен через канал передачи данных. Установление и активизация канала передачи данных логически не связанные события. Они могут, однако, быть реализованы в рамках одной операции.
- Деактивировать (Deactivate): Останавливать информационный поток через канал передачи данных.
- Модифицировать атрибуты (Modify Attributes): Изменить атрибуты канала передачи данных.
- Сменить маршрут (Reroute): Изменить маршрут канала передачи данных. Это может быть сделано административно или автоматически с помощью базовых протоколов.
- Ликвидировать (Destroy): Ликвидировать канал передачи данных и уведомить об имеющихся ресурсах. К таким ресурсам относится пространство меток и, возможно, дополнительная полоса пропускания.
Выше рассматривались базовые операции каналов передачи данных. Возможны и дополнительные операции, сопряженные с реализацией политики и формированием трафика.
5.3. Мониторирование аккоунтинга и работы
Возможности мониторинга аккоутнтинга и рабочих характеристик является крайне важным для задач билинга и контроля параметров трафика. Статистика трафика, полученная с помощью такой системы мониторинга, может использоваться для оптимизации рабочих характеристик канала и для планирования управления трафиком.
Возможность получения статистики на уровне канала передачи данных так важна, что это следует рассматривать как существенное требование управления трафиком через MPLS.
5.4. Базовые атрибуты управления трафиком каналов передачи данных
Атрибут канала передачи данных является параметром, который влияет на рабочие характеристики канала.
Атрибуты могут быть явно присвоены каналам передачи данных администратором или заданы неявно базовыми протоколами, когда пакеты классифицируются и сортируются по классам эквивалентности (FEC) на входе в область MPLS. Независимо оттого как атрибуты были первоначально присвоены, для целей управления трафиком нужно допустить их административную модификацию.
Основные атрибуты каналов передачи данных наиболее важные для управления трафиком перечислены ниже.
- Атрибуты параметров трафика
- Атрибуты управления и выбора пути
- Атрибут приоритета
- Атрибут приоритетной подмены (Preemption)
- Атрибут устойчивости (Resilience)
- Атрибут политики (Policing)
Комбинация параметров трафика и атрибутов политики аналогична использованию параметрического управления в сетях ATM. Большинство атрибутов, перечисленных выше, имеют аналоги в хорошо установившихся технологиях. Следовательно, следует достаточно непосредственно установить соответствие между атрибутами канала передачи данных и многими существующими архитектурами переключения и маршрутизации.
Приоритет и приоритетная подмена (preemption) могут рассматриваться как относительные атрибуты, так как они выражают определенные отношения между каналами передачи данных. Концептуально, эти двоичные отношения определяют способ взаимодействия каналов между собой, когда они соревнуются за получения сетевых ресурсов в процессе установления пути и его рабочих параметров.
5.5. Атрибуты параметров трафика
Параметры трафика могут использоваться при сборе данных об информационных потоках (или более точно FEC), которые надлежит транспортировать через информационный канал. Такие характеристики могут включать пиковые загрузки, средние потоки. Параметры трафика важны потому, что они указывают требования к ресурсам канала передачи данных. Это полезно для выделения ресурсов и исключения перегрузки за счет политики предвидения.
5.6. Атрибуты управления и выбора пути
Атрибуты управления и выбора пути определяют правила выбора пути канала передачи данных, а также правила работы с маршрутами, которые уже существуют.
Маршруты могут быть вычислены автоматически с помощью протоколов маршрутизации или они могут быть определены сетевым администратором. Если требований к ресурсам или ограничений, сопряженных с каналом передачи данных, нет, тогда для выбора пути может быть использован протокол, управляемый топологией. Однако, если требования к ресурсам или ограничения, связанные с политикой, имеются, тогда следует использовать маршрутизацию, основанную на ограничениях.
В разделе 7 описана маршрутизация, где путь вычисляется на основе определенных ограничений.
Управление касается всех аспектов, имеющих отношение к поддержанию путей, через которые проходят каналы передачи данных. В некоторых операционных контекстах, желательно, чтобы реализация MPLS могла динамически себя реконфигурировать для адаптации к состоянию системы. Адаптивность и устойчивость являются аспектами динамического управления маршрутом.
Чтобы контролировать выбор пути и процесс управления, необходим набор атрибутов. Базовые атрибуты и рабочие характеристики, связанные с выбором пути и управлением каналом передачи данных, описаны ниже.
5.6.1. Административно специфицированные маршруты
Административно специфицированный путь для канала передачи данных конфигурируется в результате действий оператора. Административно специфицированный путь может быть определен полностью или частично. Путь полностью специфицирован, если указаны все шаги между начальной и конечной точками. Путь частично специфицирован, если представлен только субнабор промежуточных шагов. В этом случае, нужны базовые протоколы, чтобы сформировать окончательный маршрут. Из-за ошибок оператора, административно специфицированный путь может оказаться несогласованным или нелогичным. Базовые протоколы маршрутизации должны быть способны детектировать такую несогласованность и внести необходимые коррективы.
Атрибут "path preference rule" (правило предпочтения пути) должно быть ассоциировано с административно специфицированными путями. Атрибут “правила предпочтения пути” представляет собой двоичную переменную, которая указывает, является ли административно сконфигурированный путь “обязательным” или нет.
Если административно сконфигурированный путь выбран с “обязательным” атрибутом, должен использоваться этот (и только этот) путь. Если обязательный путь недопустим (например, конечные пункты топологически разделены), или, если путь не может быть использован, так как его ресурсы неадекватны, тогда процесс установки пути (setup) потерпит неудачу. Другими словами, если путь специфицирован как обязательный, тогда альтернативный путь не может использоваться ни при каких обстоятельствах. Обязательный путь, который успешно приписан, является неявно закрепленным. Раз путь присвоен, его нельзя изменить, а только ликвидировать или заменить новым.
Однако если административно специфицированный путь выбран со значением атрибута предпочтения "необязательный", тогда путь следует использовать, если это возможно. В противном случае, может использоваться альтернативный путь, предлагаемый маршрутным протоколом.
5.6.2. Иерархия предпочтений для мультимаршрутов
В некоторых практических контекстах, может быть полезно административно специфицировать набор кандидатов маршрутов для данного канала передачи данных и определить иерархию предпочтения этих маршрутов. Во время установления пути, правила предпочтения используются при выборе подходящего пути из списка кандидатов. В случае неполадки правила предпочтения используются для выбора альтернативного пути из списка кандидатов.
5.6.3. Атрибуты сродства классов ресурсов (Resource Class Affinity)
Атрибуты сродства классов ресурсов, ассоциированные с каналом передачи данных, могут использоваться для спецификации класса ресурсов (смотри раздел 6), которые следует включить явно или исключить из пути канала передачи данных. Эти атрибуты политики, которые могут использоваться для введения дополнительных ограничений для маршрута канала передачи данных. Атрибуты сродства классов ресурсов могут быть специфицированы для трафика в виде последовательности пар:
<resource-class, affinity>; <resource-class, affinity>;
Параметр resource-class идентифицирует класс ресурса, для которого определено соотношение сродства в отношении канала передачи данных. Параметр affinity указывает на соотношение сродства; то есть, включены или исключены члены класса ресурсов в путь канала передачи данных. В частности, параметр affinity может быть двоичной величиной, которая принимает одно из следующих значений: (1) явное включение, и (2) явное исключение.
Если атрибут сродства является двоичной переменной, можно использовать Булевы выражения для спецификации сродства класса ресурсов, ассоциированных с данным каналом передачи данных.
Если не специфицировано никакого атрибута сродства класса, тогда предполагается значение отношения сродства "don't care" (безразлично) между каналом передачи данных и ресурсами. То есть, не существует никаких требований по включению или исключению каких-либо ресурсов для пути канала передачи данных. На практике - это режим по умолчанию.
Атрибуты сродства классов ресурсов очень полезны и эффективны, так как они могут быть использованы при реализации самых разных политик. Например, они могут быть применены для размещения определенных каналов передачи данных в заданных топологических областях сети.
"Маршрутизация на основе ограничений" (смотри раздел 7.0) может использоваться для вычисления точного пути для канала передачи данных так, чтобы удовлетворить ограничениям сродства класса ресурсов следующим образом:
1. Для прямого включения, перед началом вычисления пути удалить все ресурсы, не принадлежащие специфицированным классам.
2. Для прямого исключения перед началом вычисления пути, удалить все ресурсы, принадлежащие специфицированным классам.
5.6.4. Атрибут адаптивности
Характеристики сети и ее состояние изменяются со временем. Например, появляются новые ресурсы, утраченные ресурсы могут быть снова активизированы, а выделенные ресурсы могут оказаться недоступными. Вообще, иногда могут оказаться доступными более эффективные пути. Следовательно, с точки зрения управления трафиком, необходимо иметь административные параметры управления, которые могут использоваться для спецификации того, как канал передачи данных будет реагировать на этот динамизм. При некоторых сценариях, может оказаться желательным динамически изменить пути некоторых информационных каналов в ответ на изменения состояния сети. Этот процесс называется реоптимизацией. При других сценариях реоптимизация может оказаться нежелательной.
Атрибут адаптивности (adaptivity) является частью блока параметров пути, ассоциированного с каналом передачи данных. Атрибут адаптивности, ассоциированный с каналом передачи данных, указывает на то, является ли канал субъектом реоптимизации. То есть, атрибут адаптивности представляет собой двоичную переменную, которая принимает одно из следующих значений: (1) разрешить реоптимизацию и (2) запретить реоптимизацию.
Если реоптимизация разрешена, канал передачи данных может под действие маршрутных протоколов изменить путь в ответ на изменение состояния сети. Напротив, если реоптимизация запрещена, канал передачи данных является закрепленным и его маршрут не может быть изменен при вариации ситуации в сети.
Стабильность является главным соображением, когда разрешена реоптимизация. Чтобы содействовать стабильности реализация MPLS не должна быть слишком реактивной в ответ на эволюционные изменения в сети. В то же время, она должна достаточно быстро адаптироваться, чтобы оптимально использовать появляющиеся сетевые ресурсы. Отсюда следует, что частота реоптимизаций должна определяться административно, чтобы допускать настройку.
Следует заметить, что реоптимизация не то же самое что и устойчивость к внешним воздействиям. Для спецификации характеристик устойчивости канала передачи данных используются другие атрибуты (смотри раздел 5.9). На практике, представлялось бы разумным ожидать, что канал передачи данных, подвергающийся реоптимизации, должен быть устойчив против отказов вдоль его пути. Однако канал передачи данных, который не подвергается реоптимизации и чей маршрут не специфицирован административно как “обязательный”, также должен быть устойчивым против отказов связей и узлов вдоль своего пути.
Формально, можно заявить, что адаптивность к состоянию эволюции через реоптимизацию влечет за собой устойчивость к отказам, тогда как устойчивость к отказам не предполагает общей адаптивности к изменениям состояния сети.
5.6.5. Распределение нагрузки в параллельных каналах передачи данных
Распределение нагрузки по нескольким параллельным каналам передачи данных между двумя узлами является крайне важным. Во многих практических контекстах, суммарный трафик между узлами может быть таким, что ни один канал в отдельности (следовательно, и ни один маршрут) не сможет его пропустить. Однако суммарный поток может быть меньше, чем максимально допустимый поток через поперечное сечение ("min-cut"), разделяющее два узла. В этом случае, единственно возможным решением может быть деление трафика на несколько потоков.
В домене MPLS, эта проблема может быть решена с помощью нескольких каналов, соединяющих два узла. Следовательно, нужны гибкие средства назначения нагрузки для параллельных каналов передачи данных, соединяющих два узла.
В частности, в ситуациях, где параллельные потоки данных оправданы, было бы полезно иметь некоторые атрибуты, которые могут применяться для указания доли трафика, проходящего через каждый из каналов. Базовые протоколы реализуют нагрузку каналов в указанной пропорции. Желательно также обеспечивать порядок передачи пакетов, принадлежащих одному и тому же микро потоку (идентичные адреса отправителя, получателя, и номера порта).
5.7. Атрибут приоритета
Атрибут priority (приоритет) определяет относительную важность канала передачи данных. Если с MPLS используется маршрутизация, базирующаяся на ограничениях, тогда приоритеты становятся очень важными, так как они используются в случае отказов для определения порядка, в котором выбираются пути для канала передачи данных из имеющегося списка.
Приоритеты важны также в реализациях допускающих приоритетное обслуживание, так как они могут быть использованы для определения политики обслуживания каналов передачи данных.
5.8. Атрибут Preemption
Атрибут preemption определяет, может ли канал передачи данных заместить другой канал на данном пути, и может ли другой канал передачи данных заместить заданный канал. Приоритетная подмена полезна как для схемы оптимизации, ориентированной на трафик, так и для схемы, ориентированной на ресурс. Приоритетное замещение может использоваться, чтобы гарантировать то, что канал передачи данных маршрутизирован через вполне определенный путь, а это особенно важно при оказании дифференцированных услуг
Приоритетное замещение может также использоваться при реализации различных политик восстановления, вступающих в силу при отказах оборудования или программ.
Атрибут preemption может использоваться для спецификации четырех режимов приоритетного замещения для канала передачи данных: (1) замещающий объект активирован (preemptor enabled), (2) non-preemptor, (3) допускающий подмену и (4) не допускающий подмены. Канал передачи данных, где разрешено приоритетное замещение (preemptor enabled) может заменять каналы с более низким приоритетом, признанные, как приемлемые для замены. Канал передачи, специфицированный, как не подлежащий подмене, не может быть замещен каким-либо иным каналом, вне зависимости от их относительных приоритетов. Канал передачи данных, допускающий замещение, может быть замещен другим каналом с более высоким приоритетом, который имеет атрибут preemptor enabled.
Достаточно просто понять, что некоторые режимы замещения являются взаимно исключающими. Используя схему нумерации, описанную выше, можно назвать допустимые комбинации режимов для канала передачи данных: (1, 3), (1, 4), (2, 3) и (2, 4). Комбинация (2, 4) является режимом по умолчанию.
Канал передачи данных, скажем "A", может заместить другой канал, скажем "B", только если все следующие пять условий будут выполнены:
(i) "A" имеет относительно более высокий приоритет, чем "B",
(ii) "A" претендует на ресурс, используемый "B",
(iii) ресурс не может одновременно поддерживать "A" и "B",
(iv) "A" может быть приемником, и
(v) "B" допускает подмену.
Атрибут preemption не рассматривается, как обязательный атрибут современной модели обслуживания в Интернет (best effort service), хотя и является полезным. Однако, в сценарии с дифференциальными услугами, необходимость подмены становится очевидной. Более того, в появляющихся архитектурах оптического Интернет, где функции защиты и восстановления, чтобы уменьшить цену, могут быть перенесены с оптического уровня на информационные сетевые элементы (такие как гигабитные и терабитные маршрутизаторы с коммутацией по меткам), стратегии приоритетного замещения могут использоваться для сокращения времени восстановления канала в условиях сбоев.
5.9. Атрибут устойчивости (Resilience)
Атрибут resilience определяет поведение канала передачи данных в случае возникновения ошибок. То есть, когда ошибка происходит на пути, через который проходит канал. При таких обстоятельствах должны быть рассмотрены следующие проблемы: (1) детектирование ошибки, (2) уведомление об ошибке, (3) восстановление после сбоя. Очевидно, реализация MPLS должна содержать механизмы для решения всех этих задач.
Многие политики восстановления могут быть специфицированы для каналов передачи данных, чьи маршруты подвержены отказам. Ниже представлены примеры приемлемых схем:
1. Не нужно изменять маршрут канала передачи данных (traffic trunk). Например, схема живучести может уже существовать и быть реализована за счет альтернативного механизма, который гарантирует непрерывность обслуживания в случае сбоя без необходимости изменения маршрута канала передачи данных. Примером такой альтернативной схемы (конечно существует и много других), является ситуация, когда между двумя узлами имеется несколько параллельных каналов, и в случае отказа одного LSP, его трафик будет перераспределен между остальными LSP согласно некоторой заданной политике.
2. Перенаправить маршрут на приемлемый путь с достаточными ресурсами. Если такового нет, тогда маршрут не изменять.
3. Поменять маршрут на любой доступный, игнорируя ограничения по ресурсам.
4. Возможно много других схем, включая комбинации перечисленных выше.
"Базовый" атрибут resilience указывает на процедуру восстановления, которая должна быть запущена для данного канала, при возникновении отказа. В частности, "базовый" атрибут resilience является двоичной переменной, которая определяет, будет ли данный канал изменять маршрут, если сегмент его пути выдал отказ. "Расширенный" атрибут resilience может использоваться для подробной спецификации действий в случае сценария отказа. Например, расширенный атрибут resilience может специфицировать набор альтернативных путей, которые следует использовать в случае отказа, а также правил, которые управляют относительным предпочтением для каждого специфицированного пути. Атрибуты resilience обеспечивают тесное взаимодействие между MPLS и маршрутизацией.
5.10 Атрибут Policing
Атрибут policing определяет действия, которые следует предпринять в рамках базовых протоколов, когда канал передачи данных становится нерабочим. То есть, когда какие-то параметры канала отклонились за оговоренные пределы. Вообще, атрибуты policing могут указывать, является ли неуправляемый канал передачи данных лимитированным по полосе пропускания, или он просто переадресуется без каких-либо действий, учитывающих местную политику. Если используется политика, тогда для реализации таких функций могут использоваться адаптации алгоритмов, таких как ATM GCRA [11].
Использование политики необходимое во многих рабочих сценариях, может быть неприемлемо в других. Вообще, обычно желательно реализовать какую-то политику на входе сети (чтобы обеспечить согласование с требованиями уровня обслуживания) и минимизировать применение политики в ядре, за исключением ситуации, когда ограничение емкости диктуют обратное.
Следовательно, с точки зрения управления трафиком необходимо иметь возможность административно разрешать и запрещать использование политики для каждого канала передачи данных (traffic trun).
6.0. Атрибуты ресурсов
Атрибуты resource являются частью параметров состояния топологии, которые используются, чтобы установить ограничения на маршрутизацию каналов передачи данных в рамках имеющихся ресурсов.
6.1. Максимально выделяемая доля (Maximum Allocation Multiplie)
Максимально выделяемая доля MAM (maximum allocation multiplier) ресурса является административно задаваемым атрибутом, который определяет долю ресурса, доступную для канала передачи данных. Этот атрибут используется в основном для распределения полосы пропускания. Однако он может быть применен также для резервирования ресурсов LSR. Концепция MAM аналогична концепции параметров подписки и резервирования в сетях frame relay и ATM.
Значения MAM могут быть выбраны так, чтобы ресурс был недораспределен или перераспределен. Ресурс считается недораспределенным, если суммарные требования всех каналов передачи данных, которые могут его использовать, меньше емкости ресурса. В противном случае ресурс считается перераспределенным.
Недораспределение может использоваться, чтобы установить предел использования ресурсов. Однако, в случае MPLS это сложнее, чем в схемах с коммутацией каналов, так как для MPLS, некоторые потоки могут маршрутизоваться посредством обычных протоколов шаг-за-шагом без рассмотрения каких-либо ресурсных ограничений.
Перераспределение может применяться, чтобы реализовать преимущества статистических характеристик трафика в рамках более эффективной политики использования имеющихся ресурсов. В частности, перераспределение можно применить в ситуации, когда пики загрузки трафика в разных каналах не совпадают по времени.
6.2. Атрибут класса ресурса
Атрибуты класса ресурса являются параметрами, присваиваемыми административно, и вводят понятие класса для ресурсов. Атрибуты класса ресурса могут рассматриваться как "цвета", приписанные ресурсам, такие, что набор ресурсов с одним "цветом" концептуально принадлежит к одному классу. Атрибуты класса ресурса могут использоваться для реализации разнообразных политик. Ключевыми ресурсами здесь являются связи. В случае применения в отношении связей, атрибут класса ресурса становится эффективной характеристикой параметров состояния связи.
Концепция атрибутов класса ресурса является достаточно мощной абстракцией. С точки зрения управления трафиком она может использоваться для реализации различных политик при оптимизации характеристик канала по трафику или по ресурсам. В частности, атрибуты класса могут использоваться для:
1. Реализации одинаковых политик для набора ресурсов, которые не обязательно находятся в одной и той же топологической области.
2. Спецификации относительного предпочтения для набора ресурсов, связанных с положением маршрута, по которому транспортируется поток данных.
3. Ограничения положения каналов передачи данных для заданного субнабора ресурсов.
4. Реализации обобщенного включения/исключения политик.
5. Реализации политики ограничения локальности трафика. То есть, политики, которая ищет способы размещения трафика в пределах оговоренных топологических областей сети.
Кроме того, атрибуты класса ресурса могут использоваться для целей идентификации.
Вообще, ресурс может быть ассоциирован более чем с одним атрибутом класса ресурса. Например, все каналы OC-48 в заданной сети могут быть приписаны определенному атрибуту класса ресурса. Субнаборы каналов OC-48, которые имеются, могут быть приписаны к дополнительным атрибутам класса, для того чтобы реализовать специальную политику или построить нужную вам сеть.
7.0. Маршрутизация, базирующаяся на ограничениях
В этом разделе обсуждается вопросы, связанные с маршрутизацией, основанной на ограничениях, используемой в доменах MPLS. В современной терминологии, маршрутизация, основанная на ограничениях, часто называется "QoS маршрутизацией", смотри [5,6,7,10].
В этом документе используется термин "маршрутизация на основе ограничений " однако, если быть точным, QoS маршрутизация является лишь ее составной частью.
Маршрутизация на основе ограничений делает возможным резервирование ресурсов по запросу, сосуществование с имеющимися внутренними протоколами маршрутизации Интернет, работающими по принципу шаг-за-шагом.
Маршрутизация на основе ограничений, использует следующие данные в качестве входных:
- Атрибуты, связанные с каналами передачи данных (traffic trunks).
- Атрибуты, связанные с ресурсами.
- Другую информацию, характеризующую состояние топологии сети.
Базируясь на этой информации, процесс маршрутизации на основе ограничений автоматически вычисляет маршрут для каждого потока, исходящего из данного узла. В этом случае, маршрут для каждого информационного потока представляет собой спецификацию пути с коммутацией по меткам, который удовлетворяет требованиям, записанным в атрибутах канала. Ограничения формулируются на основе доступности ресурсов, административной политики и статусной топологической информации.
Маршрутизация на основе ограничений может существенно сократить уровень ручной конфигурации и необходимого вмешательства для актуализации политики управления трафиком (Traffic Engineering policies).
На практике инженер трафика, оператор, или даже автоматическая система специфицирует конечные точки канала передачи данных (traffic trunk) и приписывает набор атрибутов, который объединяет ожидаемые рабочие характеристики канала. Предполагается, что маршрутизация на основе ограничений найдет приемлемый путь, который удовлетворит имеющимся ожиданиям. Если необходимо для более тонкой оптимизации, инженер трафика или система поддержки управления трафиком может затем использовать административно сконфигурированные маршруты.
7.1 Базовые характеристики маршрутизации на основе ограничений
Маршрутизация на основе ограничений должна, по крайней мере, иметь возможность автоматически получать базовые, приемлемые решения задачи размещения пути для канала передачи данных.
Вообще, известно, что проблема маршрутизации на основе ограничений трудно разрешима для большинства реалистичных ограничений. Однако, на практике для нахождения приемлемого пути, если он существует, может использоваться очень простая хорошо известная эвристика (смотри, например, [9]):
- Сначала отбрасываются ресурсы, которые не удовлетворяют требованиям атрибутов канала передачи данных.
- Затем, для оставшегося графа связей запускается алгоритм поиска кратчайшего пути.
Ясно, что если приемлемый путь для заданного канала передачи данных существует, тогда выше предложенная простая процедура его найдет. Могут быть специфицированы дополнительные правила для разрубания узлов и выполнения дальнейшей оптимизации. Вообще, оптимизация обычно сводится к минимизации перегрузки. Однако когда нужно маршрутизировать несколько каналов передачи данных, можно показать, что выше предложенный алгоритм не всегда находит решение, даже когда такое решение существует.
7.2 Соображения реализации
Многие коммерческие реализации коммутаторов frame relay и ATM уже поддерживают некоторые аспекты маршрутизации на основе ограничений. Для таких приборов или для новых MPLS-реализаций должно быть относительно просто расширить существующие реализации маршрутизации на основе ограничений, чтобы удовлетворить специфическим требованиям MPLS.
Для маршрутизаторов, которые используют топологически управляемые IGP, определяющие маршрут шаг-за-шагом, маршрутизацию на основе ограничений можно внедрить одним из двух способов:
1. Путем расширения существующих IGP протоколов, таких как OSPF и IS-IS для поддержки маршрутизации на основе ограничений. Прилагаются усилия для решения этой задачи в отношении протокола OSPF (смотри [5,7]).
2. Путем добавления процесса маршрутизации на основе ограничений в каждый маршрутизатор, который может сосуществовать с имеющимися IGP. Этот сценарий представлен на рис. 1.
Рис. 1. Процесс маршрутизации, базирующийся на ограничениях, на уровне 3 LSR
Существует много важных деталей, связанных с реализацией маршрутизации на основе ограничений в устройствах уровня 3, которые здесь не обсуждались. Сюда входит следующее:
- Механизмы обмена статусной топологической информацией (данные о доступности ресурсов, информация о состоянии связи, информация об атрибутах ресурсов) между процессами маршрутизации на основе ограничений.
- Механизмы работы с топологической статусной информацией.
- Взаимодействие между процессами маршрутизации на основе ограничений и процессами традиционных IGP.
- Механизмы выполнения требований адаптивности каналов передачи данных.
- Механизмы выполнение требований устойчивости и живучести каналов передачи данных.
Короче, маршрутизация на основе ограничений помогает при осуществлении оптимизации сетей путем автоматического поиска приемлемых маршрутов, которые удовлетворяют набору ограничений, налагаемых на каналы передачи данных. Она может существенно уменьшить усилия по административной конфигурации и ручному вмешательству для решения задач управления трафиком.
8.0. Заключение
В данном документе представлен набор требований для реализации управления трафиком (Traffic Engineering) посредством MPLS. Описаны многие возможности, целью которых является улучшение применимости MPLS для управления трафиком в Интернет.
Следует заметить, что некоторые вопросы, описанные здесь, могут быть разрешены путем введения некоторого минимального набора модификаций в MPLS, и затем использования суперструктуры управления сетью, чтобы расширить функциональность. Маршрутизация на основе ограничений не является частью спецификаций ядра MPLS. Однако MPLS требует некоторого взаимодействия с маршрутизацией на основе ограничений, для того чтобы решить задачи управления трафиком.
9.0. Библиография
[1] Rosen, E., Viswanathan, A. и R. Callon, "A Proposed Architecture for MPLS", Work in Progress.
[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. и A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress.
[3] Li, T. и Y. Rekhter, "Provider Architecture for Differentiated Services и Traffic Engineering (PASTE)", RFC 2430, October 1998.
[4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. и G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997.
[5] Zhang, Z., Sanchez, C., Salkewicz, B. и E. Crawley "Quality of Service Extensions to OSPF", Work in Progress.
[6] Crawley, E., Nair, F., Rajagopalan, B. и H. Sandick, "A Framework for QoS Based Routing in the Интернет", RFC 2386, August 1998.
[7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. и D. Williams, "QoS Routing Mechanisms и OSPF Extensions", RFC 2676, August 1999.
[8] C. Yang и A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995.
[9] W. Lee, M. Hluchyi, и P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks,"IEEE Network, July 1995, pp 46-55.
[10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996.