DiffServ-ориентированное управление трафиком в MPLS

Ина Минеи (Ina Minei) Инженер-программист
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
408 745 2000 or 888 JUNIPER
www.juniper.net
Артикул: 200048-001

1. Резюме

Дифференцированное обслуживание (DiffServ) обеспечивает масштабируемость сетей с несколькими классами обслуживания. Управление трафиком (Traffic Engineering, TE) в MPLS обеспечивает резервирование ресурсов, отказоустойчивость и оптимизацию передачи ресурсов. Управление трафиком на основе DiffServ в MPLS (MPLS DiffServ-TE) сочетает в себе преимущества как DiffServ, так и TE. Результатом является возможность гарантировать обеспечение высокий уровень качества обслуживания (QoS) при оптимизации использования сетевых ресурсов. Качество обслуживания, обеспечиваемое MPLS DiffServ-TE позволяет операторам предоставлять услуги, требующие гарантированно высокого уровня QoS, такие как голос, и объединить IP и ATM / FR сети в единое ядро.

2. Введение

В условиях жесткой конкуренции современного рынка, провайдеры услуг стремятся увеличить свои доходы и в тоже время минимизировать капитальные и эксплуатационные затраты. С практической точки зрения это требует (1) предоставления новых услуг, приносящих выгоду, например, передачи голоса, и гарантированную полосу пропускания для критически важных бизнес-приложений и (2) миграции L2-сервисов из традиционных сетей, таких как АТМ и FR, в инфраструктуру сети IP, освобождая пользователя от необходимости нескольких физических сетей. Задача заключается в том что оба типа услуг – новые и традиционные – требуют соблюдения соглашений о гарантированном уровне обслуживания (SLA).

Соглашения о гарантированном уровне обслуживания определяют качество услуг основываясь на передаче трафика по сети и выражается в уровне задержки, джиттера, гарантированной пропускной способности, отказоустойчивости и времени простоя. Соглашения о гарантированном уровне обслуживания заключаются в двух условиях: (1) дифиринциации планирования, очередей и отклонения поведения, основанных на типе приложения, а также (2) гарантированной пропускной способности для каждого приложения.

На сегодняшний день поставщики услуг разворачивают приносящие доход услуги в своей сети только с использованием DiffServ. Назначив приложениям различные классы обслуживания и маркировав пути передачи, первое условие было удовлетворено. Однако, чтобы получить строгое соблюдение гарантий, недостаточно соответствующим образом маркировать трафик. Если трафик передается по пути с недостаточными ресурсами для удовлетворения эксплуатационных характеристик, таких как джиттер или задержка, требования соглашений об уровне обслуживания не могут быть удовлетворены. В принципе, операторы могли бы решить эту задачи с помощью перепредоставления ресурсов, чтобы избежать заторов в целом. Помимо того, расточительный в отношении использования ресурсов подход "увеличения полосы пропускания при проблеме" не может предоставить никаких гарантий, когда проблема вызвана аварией на линии или узле связи.

Управление трафиком в MPLS (MPLS Traffic Engineering, MPLS-TE) устанавливает пути коммутируемые по меткам (label-switched-path, LSP) в зависимости от имеющихся ресурсов, обеспечивая, тем самым, гарантированную доступность полосы пропускания для конкретного потока и избежание заторов в стационарном состоянии и во время отказа сценариев. Потому что LSP создаются только там, где имеются ресурсы, перепредоставление ресурсов не нужно. Дальнейшая оптимизация передачи ресурсов осуществляется LSP через перенаправление трафика, если имеющиеся ресурсы по кратчайшему пути недостаточны. Дополнительным преимуществом является то, что встроенные в MPLS механизмы, такие, как защита линий и быстрая перенастройка маршрутов, обеспечивают устойчивость в случае отказов. Хитрость состоит в том, что MPLS-TE не использует классификации на классы обслуживания (CoS), работая с пропускной способностью на агрегированном уровне во всех классах.

MPLS-TE DiffServ производит управление трафиком основываясь на CoS, что позволяет резервировать ресурсы в соответствии с CoS и обеспечения настроек отказоустойчивости MPLS для каждого класса услуги. Сочетание функциональности DiffServ и TE позволяет MPLS DiffServ -TE обеспечивать гарантированное QoS в соответствии с требованиями SLA, например, теми, которые необходимы для передачи голоса, ATM, Frame Relay.

Заметим, что даже если ресурсы зарезервированы для каждого класса обслуживания, а трафик правильно маркирован в соответствии с CoS приложений, по-прежнему не может быть гарантировано выполнение соглашений об уровне обслуживания, пока новые механизмы, такие, как политика и контроль за установлением соединений, не будут инициализированы для того, чтобы трафик оставался в пределах, заложенных при резервировании ресурсов.

Раздел 3 этой статьи представляет DiffServ и TE, описывает несколько сценариев приложений и рассказывает, каким образом каждая из этих технологий не обеспечивает приемлемые решения. Раздел 4 дает углубленный обзор MPLS DiffServ-TE технологии как это определено в стандартах IETF. Раздел 5 освещает некоторые преимущества реализации JUNOS DiffServ-TE.

3. DiffServ и TE – современные методы

В этой главе описываются две составляющие MPLS DiffServ-TE, DiffServ and TE, и обосновывается необходимость их сочетания для соблюдения гарантированного QoS в сценариях прикладных приложений.

3.1 DiffServ

Начальные попытки обеспечения качества обслуживания (QoS) в IP-сетях были основаны на модели интегрированного обслуживания (IntServ), в которой отдельные приложения запрашивали гарантированное QoS прямо из сети. Протокол обмена сигналами RSVP использовался для распределения запросов к сетевым узлам, и состояние должно было поддерживаться для каждого потока на каждом участке маршрута. В условиях множества потоков, проходящих по сети, этот подход оказался недоступным и чрезмерно сложным, и более «крупномодульная» модель была разработана в форме DiffServ.

DiffServ подходит к проблеме QoS, разделяя трафик на малое число классов и распределяя ресурсы сети на классовой основе. Чтобы избежать необходимости обмена сигналами в протоколе, класс маркируется непосредственно в пакете, в 6-битном коде поля дифференцированной услуги. Поле DSCP является частью исходного поля типа услуги (type of service, ToS) в IP-заголовке. IETF повторно определил значение малоиспользуемого поля ToS, разделив его на 6-битное DSCP поле и 2-битное ECN поле, как показано на рисунке 1.

Рисунок 1 – ToS и DSCP+ ECN

DSCP определяет QoS пакета в определенном сетевом узле. Это так называемое политика пошагового поведения (PHB), которая выражается через планирование и установку параметров особенностей обслуживания пакета. С точки зрения применения, PHB передает пакетной очереди, служащей для переадресации, возможность изменения, если очередь превышает определенный предел, ресурсы (буферы и полосу пропускания), отведенные каждой очереди, и частоту, на которой обслуживается очередь. IETF определяет набор стандартных PHB следующим образом: 

- Best effort (BE). Для трафика не применяется особая обработка.
- Expedited forwarding (EF). Для трафика устанавливается минимальная задержка и низкие потери. С практической точки зрения, это представляет собой очередь, выделенную под EF трафик, для которой интенсивность входного потока пакетов меньше, чем интенсивность обслуживания, и таким образом задержки, джиттер и потери из-за перегрузки канала связи маловероятны. Голосовые и видео потоки – типичные примеры трафика, преобразованного в EF: они имеют постоянные параметры и требуют минимальной задержки и потерь.
- 12 aгарантированной переадресации (assured forwarding, AF).. Каждый PHB задан номером очереди и параметрами отклонений. IETF рекомендует использование четыре разных очередей с тремя уровнями настроек в каждой, дающих вместе 12 различных AF PHB. Условные обозначения для названий AF PHB представляют собой AFxy, где x – это номер очереди, а y – уровень установки параметров отклонения. Таким образом, все пакеты из AF1y будут помещены в одну и ту же очередь для переадресации, гарантируя, что пакеты из единого приложения не будут перегруппированы, если они отличаются только по параметрам отклонений. AF PHB применимы для трафика, который требует обеспечения параметров, но не требует ограничений на задержку или джиттер.

Хотя IETF определил рекомендуемые значения DSCP для каждого стандартного PHB, поставщики позволяют операторам связи повторно определять преобразования между DSCP и PHB, и определять нестандартные PHB. Важно иметь в виду, что как только пакет промаркирован определенным значением DSCP, его QoS обработка определяется на каждом участке, который он проходит. Таким образом, чтобы обеспечить пошаговое поведение QoS, крайне важно поддерживать последовательные DSCP-PHB преобразования. Это требование приводит нас к понятию DiffServ-домена, который представляет собой множество узлов, поддерживающих DiffServ, с: 1) общим набором определенных PHB, 2) одинаковыми DSCP-PHB преобразованиями и 3) унифицированной политикой предоставления услуг. Обычно DiffServ-домен работает под единым руководством. На краю DiffServ-домена трафик маркируется значениями DSCP, которые обеспечивают желаемое пошаговое поведение и в конечном итоге желаемое QoS

Рисунок 2: DiffServ-домен. Голосовой трафик маркируется EF на входе в домен, трафик данных – BE. Каждый узел анализирует DSCP биты и направляет трафик в различные очереди.

Подводя итоги, можно сказать, что DiffServ предоставляет дифференцированный режим переадресации трафика, таким образом, обеспечивая соблюдение QoS для различных потоков трафика. Это масштабируемое решение, которое не требует обмена сигналами в потоке и запоминания текущего состояния в оперативной памяти ЭВМ. Однако, оно не может гарантировать QoS, если маршрут трафика не имеет достаточных ресурсов, отвечающих требованиям QoS.

6. Заключение

Технология DiffServ-TE определяется IETF, предусматривая гарантированное обслуживание различных типов трафика. Такие гарантии позволяют операторам внедрять новые услуги и обеспечивать более эффективное использование ресурсов для существующих услуг. Осуществления JUNOS предлагает основанную на стандартах, обеспечивающих возможность взаимодействия, и масштабируемую реализацию DiffServ-TE, вместе с уникальным инструментом для обеспечения того, чтобы трафик оставался в границах ресурсов, зарезервированы для него.

7. Ссылки

[DSTE- MAM] - Le Faucheur F., Lai K., Maximum Allocation Bandwidth Constraints Model for DS-TE - draft-ietf-tewg-diff-te-mam-01.txt 
DSTE-PROTO] - Le Faucheur F. et al, Protocol extensions for support of DS-aware MPLS TE - draft-ietf-tewg-diff-te-proto-05.txt 
[DSTE-RDM] - Le Faucheur F. et al, Russian Dolls Bandwidth Constraints Model for DS-TE - draft-ietf-tewg-diff-te-russian-04.txt 
[FRR] - Pan P. et al, Fast Reroute Extensions to RSVP-TE for LSP Tunnels - draft-ietf-mpls- rsvp-lsp-fastreroute-03.txt, work in progress 
[ISIS-TE] – Smit H., Li T., IS-IS extensions for Traffic Engineering - draft-ietf-isis-traffic-05.txt 
[MPLSTECH] – Davie B., Rekhter Y. , MPLS Technology and Applications 
[OSPF-TE] – Katz D. Yeung D., Traffic Engineering Extensions to OSPF - draft-katz-yeung- ospf-traffic-10.txt 
[RFC2475] – Blake S. et al, An Architecture for Differentiated Services – RFC 2475 
[RFC2702] - Awduche D. et al, Requirements for Traffic Engineering Over MPLS – RFC 2702 
[RFC3031] - Rosen E. et al, Multiprotocol Label Switching Architecture – RFC 3031
[RFC3036] – Anderson L. et al, LDP Specification – RFC 3036 
[RFC3209] - Awduche D. et al, RSVP-TE: Extensions to RSVP for LSP Tunnels - RFC 3209 
[RFC3270] - Le Faucheur F. et al, MPLS Support of Diff-Serv - RFC 3270 
[RFC3468] – Anderson L., Swallow G., The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols – RFC 3468 
[RFC3564]- Le Faucheur F. et al, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering - RFC 3564 

Благодарности

Автор хотел бы выразить благодарность Yakov Rekhter, Julian Lucek и Amir Tabdili за их комментарии, предложения и понимание; Mike Capuano, Hannes Gredler, Nischal Sheth и Chelian Pandian за их рецензию; Aviva Garret за редактирования, и Susan Lane за производственную продержку