Consideraes acerca do estabelecimento de QoS no RNP2

Cybelle Suemi Oda Oyama <cybelle@rnp.br> Sidney Cunha de Lucena <sidney@rnp.br> Centro de Engenharia e Operaes (CEO) Rede Nacional de Ensino e Pesquisa (RNP) Resumo 1. Introduo 2. Arquiteturas QoS 2.1 Intserv 2.2 Diffserv 3. Proposta de implementao 4. Opes de implementao 5. Exemplo de implementao 5.1 Configurao nos roteadores de borda 5.1.1 Definio das classes 5.1.2 Classificao dos pacotes 5.1.3 Marcao dos pacotes 5.1.4 Configurao das polticas 5.1.5 Moldagem do trfego na interface de sada 5.1.6 Aplicao das polticas nas interfaces 5.2 Configurao nos roteadores do ncleo 5.2.1 Definio das classes 5.2.2 Configurao das polticas 5.2.3 Aplicao das polticas na interface 5.3 Exemplo aplicado ao backbone RNP2 5.4 Restries 6. Concluso Referncias bibliogrficas

Resumo
Este artigo aborda aspectos relacionados implantao de servios diferenciados no backbone da RNP, tais como escolha da arquitetura, opes de implementao, exemplos de configurao e dificuldades enfrentadas. Tais informaes so decorrentes de resultados obtidos com o projeto piloto de QoS IP, desenvolvido no segundo semestre de 2001.

1. Introduo
A necessidade por qualidade de servios vem se evidenciando no RNP2, desde 2001, atravs de solicitaes de apoio a transmisses de udio/vdeo em aplicaes de videoconferncia e telemedicina. Como o servio de rede atual de melhor esforo (best-effort) inadequado para garantir o desempenho de tais aplicaes, duas solues podem ser implementadas para atender a essas demandas: estabelecimento de um canal dedicado para a transmisso e implementao de QoS IP (usando a estrutura do RNP2). Embora, tecnicamente, a primeira soluo oferea uma qualidade superior, a segunda apresenta como atrativos o custo reduzido (no h a necessidade de contratao de enlaces adicionais) e a rapidez na disposio do servio (basta fazer a configurao nos roteadores do caminho, uma vez que a estrutura j se encontra disponvel).

Em junho de 2001, a RNP iniciou um projeto piloto, cujo objetivo foi estudar, avaliar e testar qualidade de servio IP no backbone RNP2. Como resultado do piloto, pode-se destacar a proposta de uma estrutura QoS no RNP2, bem como a experincia adquirida e as consideraes acerca da implementao. Este artigo enfoca o ltimo resultado e comea mostrando duas opes de arquitetura de QoS, o intserv (1) e o diffserv (2). A seguir, apresentada a proposta para implementao de servio diferenciado no backbone RNP2. As possibilidades tecnolgicas para implementao da proposta em roteadores Cisco so apresentadas na seqncia, seguidas de uma descrio de como ficam as configuraes dos mesmos. Por fim, as concluses. 1 - Integrated Services. 2 - Differentiated Services.

2. Arquiteturas QoS
A IETF padronizou duas arquiteturas para agregar QoS ao modelo tradicional IP: Diffserv (RFC2475) e Intserv (RFC1633). Ambas possuem o mesmo objetivo: propiciar diferenciao de servio. Porm, com abordagens distintas, bem como vantagens e desvantagens inerentes a cada uma. Um breve descrio das mesmas apresenta-se a seguir.

2.1 Intserv
A Intserv est apoiada em dois pilares: reserva de recursos e controle de admisso, ou seja, antes da transmisso dos pacotes se iniciar, a aplicao faz a solicitao dos servios, o caminho

configurado e os recursos previamente alocados. Especifica dois nveis de servios, alm do melhor esforo:

y y

Servio garantido (RFC2212): para aplicaes que necessitam de limites fixos de atraso; Servio de carga controlada (RFC2211): seu desempenho pode ser equiparado ao do melhor esforo sob condies de no congestionamento. Pela definio do RFC, "O servio de carga controlada fornece ao fluxo de dados cliente uma qualidade de servio muito prxima a que oferece um elemento de rede no carregado (unloaded), porm usa controle de capacidades para assegurar que este servio seja recebido mesmo que o elemento de rede esteja sobrecarregado (overloaded)." Os elementos de rede no Intserv devem implementar quatro componentes:

Protocolo de sinalizao (ex.: RSVP(3) ): utilizado na configurao do caminho e reserva de recursos. Implica na manuteno de informaes sobre o status de cada fluxo nos ns finais e em todos os roteadores ao longo do caminho;

y y

Escalonador de pacotes: lida com o envio de pacotes utilizando algum mecanismo de filas ou temporizadores (timers); Classificador (classificao Multi-Field): para fins de controle de trfego e contabilizao, cada pacote deve ser mapeado para alguma classe, onde recebem o mesmo tratamento dispensado pelo escalonador de pacotes;

Rotina de controle de admisso: determina se um novo fluxo pode receber QoS solicitado, sem impactar as garantias anteriores. Como trabalha no nvel de fluxos(4), no se recomenda seu uso em backbones, pois a implementao das funes acima pode exigir uma quantidade de recursos considervel, podendo comprometer o desempenho como um todo. 3 - RFC2205 ("Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification"). 4 - No contexto Intserv, um fluxo definido como uma seqncia de pacotes como os mesmos endereos, portas fontes e destino e requisitos de QoS

2.2 Diffserv
O Diffserv surgiu como uma alternativa mais simples ao Intserv (mais complexo e rigoroso em termos de QoS). Como trabalha no nvel de classes, possui uma escalabilidade maior, pois fluxos com requisitos de QoS similares so agregados em uma mesma classe, a qual pode receber um servio melhor ou pior que outras definidas. Fornece um modo simples de categorizar e priorizar trfego: as funes mais complexas de marcao, classificao e condicionamento de trfego (policiamento e moldagem) ocorrem nos roteadores de borda, enquanto os roteadores do ncleo preocupam-se apenas em como dar o

tratamento de expedio s classes de trfego. A este tratamento, d-se o nome de per-hopbehavior, ou PHB. A classificao dos pacotes baseia-se em um campo do cabealho IP, denominado DS-field. Este pode ser considerado como uma redefinio do campo Type of Service presente no cabealho IPv4, ou Class of Traffic do IPv6. Seis bits do DS-field so usados para identificar o valor de DSCP (differentiated services codepoint), usado na seleo do PHB. Os dois ltimos bits (CU - currrently unused), no so utilizados atualmente, e por conseguinte, so desconsiderados pelo Diffserv.

Figura 1 - Representao do DS-field Existem dois PHBs padronizados:

Expedited Forwarding PHB (RFC 2598) Este PHB pode ser usado para construir servio fim-a-fim com as seguintes caractersticas:

o o o o

Baixa perda; Baixa latncia; Baixa variao de atraso, e Banda assegurada.

Do ponto de vista do n final, tal servio aparenta ser uma conexo ponto-a-ponto ou uma virtual leased line. Este servio tambm tem sido descrito como servio Premium.

Assured Forwarding PHB (RFC 2597) O grupo AF PHB fornece entrega de pacotes IP em 4 classes onde, para cada uma, alocada uma determinada quantia de recursos para o encaminhamento do trfego (buffer e banda). Dentro de cada classe AF, um pacote IP pode ser associado a um dentre trs nveis diferentes de precedncia de descarte. Este PHB pode ser usado para implementar servios que garantam um valor de banda, mesmo em tempos de congestionamento. Um exemplo o servio Olmpico (Gold, Silver e Bronze). Valores de DSCP recomendados para identificar os PHBs

Default PHB Codepoint 000000 (0) (melhor esforo) EF PHB 101110 (46) AF PHB Low Classes Drop Prec 001010 Class 1 (10) Class 2 010010

High Medium Drop Drop Prec Prec 001100 001110 (12) (14) 010100 010110

(18) 011010 Class 3 (26) 100010 Class 4 (34)

(20) 011100 (28) 100100 (36)

(22) 011110 (30) 100110 (38)

Dada a pouca escalabilidade da Intserv no contexto de backbones, bem como o exemplo de outras iniciativas como o QBone, optou-se pela implementao da arquitetura Diffserv no backbone RNP2.

3. Proposta de implementao
A proposta para implementar Diffserv sob demanda no backbone RNP2 se vale de prconfiguraes nos roteadores, a serem habilitadas de acordo com o tipo de demanda e o papel de cada roteador no escopo desta. Dado que um roteador faa parte de uma malha que deve prover garantias de QoS para um determinado trfego, este roteador ser classificado como roteador de borda e/ou de ncleo e desempenhar suas respectivas funes. Os roteadores de borda so aqueles que se encontram nas extremidades da conexo, servindo como porta de acesso ao "core", e os de ncleo so os demais roteadores ao longo do caminho, ou dos possveis caminhos. No caso do RNP2, dependendo da situao, alguns roteadores podero fazer o papel de roteador de borda e de ncleo ao mesmo tempo. A partir da, so implementados os PHB EF (Premium) e AF (Olmpico). Ou seja, aps definidas as classes de servio, o trfego ser classificado, marcado e possivelmente condicionado (tudo isso) nas bordas e, no ncleo, ser efetuado o gerenciamento de congestionamento. A figura a seguir exemplifica a distribuio das funes.

Figura 2 - Distribuio de funes nos roteadores de borda e ncleo Uma observao a ser feita que, embora estejam definidas cinco classes de servio, h a possibilidade de uma implementao parcial, visto que atualmente no existe demanda para todas estas classes concorrentemente. Ou seja, uma estratgia de implementao pode considerar,

inicialmente, apenas a configurao de duas classes de servio: Premium e Gold, alm da classe de melhor esforo. Dessa forma, um exemplo de mapeamento de aplicaes seria: Exemplo de aplicaes VoIP e videoconferncia

Servio Servio Premium Gold

Caractersticas oferecidas

Baixa latncia e CBR (constant bit rate) Banda assegurada em tempo de Vdeo sob demanda congestionamento

Proteo do trfego priorizado O fato da classificao dos pacotes ser feita somente utilizando o campo DSCP cria uma certa vulnerabilidade, uma vez que qualquer pacote que entre no backbone com esse campo marcado pode ser atendido por uma classe de servio (caso os valores de DSCP do pacote e da classe coincidam). Surge, ento, a necessidade de mecanismos adicionais de controle de acesso e autenticao que assegurem a utilizao das classes de servio apenas pelos dados dos usurios que os contrataram. Para resolver este problema, foram consideradas duas estratgias:

Remarcao dos pacotes da classe melhor esforo (que no ir necessitar de priorizao) com DSCP 0 nas bordas. Este mecanismo deve ser implementado em todos os roteadores do backbone, uma vez que o trfego esprio pode entrar por qualquer ponto do mesmo;

Criar listas de acesso (access-lists), casando o trfego prioritrio em todos os roteadores do caminho. Esta soluo deve ser adotada com cautela, pois o consumo de recursos no roteador pode ser considervel. A adoo de uma destas estratgias est condicionada a testes que visem estudar o impacto dessas solues no desempenho do backbone.

4. Opes de implementao
Considerando-se que os roteadores do backbone so todos Cisco, as caractersticas que podem ser usadas nas implementaes das funes so mostradas na tabela abaixo. Caractersticas Cisco IOS QoS CAR (Commited Access Rate), access-list GTS (Generic Traffic Shaping) Class Based Policer, CAR (Commited Access Rate) LLQ (Low Latency Queuing), CBWFQ (Class Based Weighted) WRED (Weigthed Random Early Detection) CRTP (Compressed Real

Roteador Borda

Funo Marcao/classificao Moldagem Policiamento

Ncleo

Gerenciamento de congestionamento Preveno de congestionamento Mecanismos de eficincia

do enlace

Time Protocol) LFI (Link Fragmentation and Interleaving)

Outra questo a ser levada em considerao a caracterstica da aplicao a ser protegida. Algumas so sensveis a atrasos e/ou perda de pacotes, enquanto outras so vorazes no consumo de banda. O documento da Cisco "Implementing Quality of Service (QoS)" apresenta uma tabela para servir de guia na escolha das caractersticas (features), considerando esse aspecto: Guideline No usar weighted random early detection (WRED), moldagem, fragmentao (FRF12), ou policiamento. Para este tipo de trfego, deve-se implementar LLQ e usar a fila prioritria para o trfego sensvel a atraso. Aplicaes que geram Usar WRED, policiamento, moldagem, ou rajadas (bursts) ou class-based weighted fair queueing grandes consumidoras (CBWFQ) para garantir banda. de banda (FTP e HTTP) Aplicaes baseadas Usar WRED, uma vez que perdas de em TCP pacotes causaro retransmisses. Se o trfego baseado em UDP e no h retransmisses, no use WRED. Use policiamento se houver a necessidade de limitar o trfego da aplicao. Caractersticas Aplicaes sensveis a atrasos ou perda (voz e vdeo em tempo real)

5. Exemplo de implementao
Nesta seo, apresentado um exemplo de implementao, considerando:

y y y

Classes de servio: Premium (LLQ); Gold, Silver e Bronze (CBWFQ); Classificao, marcao e moldagem nos roteadores de borda; Controle de congestionamento no ncleo.

5.1 Configurao nos roteadores de borda

Neste esquema, o trfego entrante classificado usando listas de acesso e, depois, marcado atravs da configurao do campo DSCP. Este campo ser usado pelos roteadores intermedirios para associar os pacotes s respectivas classes de servio. Para garantir que o trfego no ultrapasse os valores acordados, ser feita a moldagem do mesmo na sada do roteador.

5.1.1 Definio das classes

So definidos dois conjuntos de classes nos roteadores de borda. O primeiro refere-se classificao do trfego baseada em algum critrio, por exemplo endereos IP e/ou porta da aplicao, que identifique os dados que devero ser atendidos pelas classes de servios. Estas sero posteriormente referenciadas na marcao dos pacotes atravs da configurao do valor de DSCP. class-map EF Case todo o trfego prioritrio que requeira baixa latncia, identificado por um critrio nico. class-map Case todo o trfego que requeira garantia de banda, AF1 porm no tenha restrio quanto a latncia, identificado por um critrio nico. class-map Case todo o trfego que requeira garantia de banda, AF2 identificado por um critrio nico, porm sem restrio quanto latncia e com prioridade inferior AF1. class-map Case todo o trfego que requeira garantia de banda, AF3 identificado por um critrio nico, porm sem restrio quanto a latncia e com prioridade inferior AF2.

O segundo conjunto, refere-se s classes de servio baseados nos valores de DSCP. class-map Premium class-map Gold class-map Silver class-map Bronze

Case todo o trfego que tenha o valor de DSCP = 46 Case todo o trafego que tenha o valor de DSCP = 10 Case todo o trafego que tenha o valor de DSCP = 18 Case todo o trafego que tenha o valor de DSCP = 26

5.1.2 Classificao dos pacotes

class-map match-all EF match access-group N1

class-map match-all AF1 match access-group N2

class-map match-all AF2 match access-group N3

class-map match-all AF3 match access-group N4

As listas de acesso N1, N2, N3 e N4 realizam a classificao por endereos IP e/ou porta da aplicao, ou outro requisito que caracterize o trfego a ser priorizado.

5.1.3 Marcao dos pacotes

O comando policy-map utilizado para configurar as caractersticas de QoS que devem estar associadas ao trfego previamente classificado. Neste caso, a marcao do campo DSCP feita atravs do comando set ip dscp.

policy-map MARCADSCP class EF set ip dscp 46 class AF1 set ip dscp 10 class AF2 set ip dscp 18 class AF3 set ip dscp 26

5.1.4 Configurao das polticas

Estas se referem configurao da banda reservada para cada classe. Premium Gold Silver Bronze Alocao de banda P(5) Alocao de banda G(6) Alocao de banda S(7) Alocao de banda B(8)

Obs: o total das bandas configuradas em todas as classes (P+G+S+B) no deve ultrapassar a 75% da banda total do enlace, a fim de se garantir o trfego das informaes de controle da rede. class-map match-all premium match ip dscp 46 class-map match-all gold match ip dscp 10 class-map match-all silver match ip dscp 18 class-map match-all bronze match ip dscp 26

Policy-map Premium-Olmpico class premium priority (9) P class gold bandwidth(10) G class silver bandwidth S class bronze bandwidth B

5.1.5 Moldagem do trfego na interface de sada

traffic-shape group(11) N2 G G1 G1 traffic-shape group traffic-shape group N3 S S1 S1 N3 B B1 B1

Uma dica: quando no se sabe como definir os valores para "normal burst size" e "excess burst size", uma opo efetuar o clculo considerando o trfego de 1,5 segundos. Por exemplo, supondo que o valor mximo da banda da classe (primeiro parmetro) seja 64000 bps, o trfego referente a 1,5 segundos 96000 bps, ou 12000 bytes por segundo, para os dois ltimos parmetros. 5 - Valor da banda para a classe Premium acordada entre cliente e provedor. 6 - Valor da banda para a classe Gold acordada entre cliente e provedor. 7 - Valor da banda para a classe Silver acordada entre cliente e provedor. 8 -Valor da banda para a classe Bronze acordada entre cliente e provedor. 9 - A implementao do LLQ se d atravs do comando priority bandwidth, o qual reserva uma priority queue estrita para o trfego CBWFQ. 10 - O comando bandwidth bandwidth-kbps especifica a quantidade de banda, associada classe CBWFQ. 11 - O comando traffic-shape group utilizado para se fazer a moldagem do trfego classificado atravs da access-list. Os 3 parmetros subseqentes correspondem a: bit-rate [burst-size] [excess-burst-size].

5.1.6 Aplicao das polticas nas interfaces

Na interface local do roteador, por onde entra o trfego a ser priorizado, aplica-se a poltica de marcao dos pacotes:

service-policy input MARCADSCP

Na interface de sada, aplica-se as polticas de priorizao do trfego: service-policy output Premium-olimpico

5.2 Configurao nos roteadores do ncleo

Nos roteadores do ncleo (core), o enfoque est no tratamento do trfego associado s classes: priorizao e controle de congestionamento.

5.2.1 Definio das classes

Como os pacotes j entram marcados, as nicas classes definidas so as dos servios propriamente ditos. class-map Premium class-map Gold class-map Silver class-map Bronze Case todo o trfego que tenha o valor de DSCP = 46 Case todo o trafego que tenha o valor de DSCP = 10 Case todo o trafego que tenha o valor de DSCP = 18 Case todo o trafego que tenha o valor de DSCP = 26

5.2.2 Configurao das polticas

As polticas referem-se priorizao, garantia de banda para cada classe e controle de congestionamento (12), considerando-se que o trfego seja TCP. Premium (DSCP 46) Gold (DSCP 10)

Alocao de banda P

Alocao de banda G e preveno de congestionamento Alocao de banda S e preveno de Silver (DSCP 18) congestionamento Bronze (DSCP Alocao de banda B e preveno de 26) congestionamento

No caso particular da implementao do servio Premium, a preveno de congestionamento no ser implementada, seguindo a recomendao da Cisco de no us-la em conjunto com o LLQ .

class-map match-all premium match ip dscp 46 class-map match-all gold match ip dscp 10 class-map match-all silver match ip dscp 18 class-map match-all bronze match ip dscp 26

class-map match-all premium match ip dscp 46 class-map match-all gold match ip dscp 10 class-map match-all silver match ip dscp 18 class-map match-all bronze match ip dscp 26

Policy-map Premium-Olmpico class premium priority P class gold bandwidth G random-detect class silver bandwidth S random-detect class bronze bandwidth B random-detect
( 13 )

12 - Valor da banda para a classe Premium acordada entre cliente e provedor. 13 - O comando random-detect implementa o WRED no IOS. Neste caso, no apresentando parmetros, uma vez que se usa os valores default.

5.2.3 Aplicao das polticas na interface

Na interface de sada, aplicar as polticas de priorizao do trfego:

service-policy output Premium-olimpico

5.3 Exemplo aplicado ao backbone RNP2

Tome-se como exemplo uma videoconferncia entre uma instituio no Rio de Janeiro e outra em Minas Gerais, na qual ambas podem transmitir e receber sinal, e uma outra instituio na Paraba podendo receber o sinal de ambas, porm sem interagir com Rio e Minas.

Figura 3 - Topologia das conexes no exemplo citado Neste exemplo hipottico, possvel ver, atravs da figura 3, que os roteadores dos PoPs PB e MG funcionam como roteadores de borda (o PoP-PB um caso especial a ser visto adiante); os roteadores dos PoPs de SP e PE funcionam como roteadores do ncleo; e o roteador do PoP-RJ funciona tanto como roteador de borda, quanto como de ncleo. Um roteador que acumule as duas funes deve ter uma configurao que abranja os dois casos, ou seja, faa a marcao (policy-map MARCADSCP), defina as classes de servio e o controle de congestionamento (policy-map Premium-Olmpico com o WRED habilitado) e efetue a moldagem no trfego de sada. No caso do roteador de PB, apesar dele estar na "borda" da comunicao, ele no precisar fazer nenhum tipo de marcao e classificao, pois a instituio hipottica ligada a ele no transmitir sinal, ser apenas receptora. Desta forma, assim como deve ser nas outras bordas (RJ e MG), basta que o roteador trate de encaminhar os pacotes da videoconferncia para a interface de sada que aponta para a respectiva instituio participante da melhor maneira possvel. Caso haja perigo de conteno (congestionamento), possvel usar o mesmo police-map de sada comumente definido para os roteadores do ncleo e de borda.

5.4 Restries
A principal restrio decorre da prpria arquitetura DiffServ: ausncia de mecanismos de controle de admisso. Ou seja, uma vez que a classe de servios definida, no existe controle de

quantos fluxos podero estar entrando nesta classe. Um exemplo o caso da classe prioritria configurada para atender ao trfego VoIP, cuja banda alocada suporta at trs ligaes simultneas. Se uma quarta ligao for estabelecida, esta poder entrar na mesma classe, compartilhar a banda e acabar degradando a qualidade de todas, uma vez que a banda garantida no suficiente para quatro ligaes simultneas. Portanto, torna-se necessria a adoo de mecanismos externos arquitetura, para efetuar este tipo de controle. Outras restries so decorrentes da prpria estrutura atual do backbone, onde ainda no h uma uniformidade nas verso de IOS decorrente, principalmente, de limitaes de hardware em alguns roteadores. Ou seja, dependendo do nvel da verso de IOS, nem todas as caractersticas esto disponveis. A proposta contempla apenas QoS no backbone, e no necessariamente fim-a-fim. Ou seja, cabe ao solicitante prover a garantia de servio at a entrada neste.

6. Concluso
Atualmente, j existem arquiteturas padronizadas e equipamentos com mecanismos para controles de congestionamento, classificao, priorizao e condicionamento de trfegos; ou seja, o ponto crtico no mais a existncia do instrumental necessrio, mas fazer a escolha adequada, considerando o ambiente de produo particular. Considerando as arquiteturas atuais, a melhor maneira de se garantir qualidade de servio no backbone RNP2 atravs do uso de Diffserv.

Devido a diversos aspectos relacionados com a heterogeneidade da rede, este artigo apresenta uma proposta de implementao sob demanda de servio diferenciado no backbone da RNP. Esta implementao d-se por meio de pr-configuraes a serem parametrizadas e habilitadas sempre que houver solicitao de garantia de QoS. Apenas os roteadores envolvidos em cada caso sero configurados, ou seja, sero parametrizados e tero os police-maps aplicados s devidas interfaces. Num prximo artigo, ser feito um levantamento mais detalhado sobre as funcionalidades da Cisco para implementao de servio diferenciado, suas restries e aplicabilidades.