Considerações 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 Operações (CEO)
Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
2. Arquiteturas QoS
2.1 Intserv
2.2 Diffserv
3. Proposta de implementação
4. Opções de implementação
5. Exemplo de implementação
5.1 Configuração nos roteadores de borda
5.1.1 Definição das classes
5.1.2 Classificação dos pacotes
5.1.3 Marcação dos pacotes
5.1.4 Configuração das políticas
5.1.5 Moldagem do tráfego na interface de saída
5.1.6 Aplicação das políticas nas interfaces
5.2 Configuração nos roteadores do núcleo
5.2.1 Definição das classes
5.2.2 Configuração das políticas
5.2.3 Aplicação das políticas na interface
5.3 Exemplo aplicado ao backbone RNP2
5.4 Restrições
6. Conclusão
Referências bibliográficas

Resumo

Este artigo aborda aspectos relacionados à implantação de serviços diferenciados no backbone da RNP, tais como escolha da arquitetura, opções de implementação, exemplos de configuração e dificuldades enfrentadas. Tais informações são decorrentes de resultados obtidos com o projeto piloto de QoS IP, desenvolvido no segundo semestre de 2001.

^

1. Introdução

A necessidade por qualidade de serviços vem se evidenciando no RNP2, desde 2001, através de solicitações de apoio a transmissões de áudio/vídeo em aplicações de videoconferência e telemedicina. Como o serviço de rede atual de melhor esforço (best-effort) é inadequado para garantir o desempenho de tais aplicações, duas soluções podem ser implementadas para atender a essas demandas: estabelecimento de um canal dedicado para a transmissão e implementação de QoS IP (usando a estrutura do RNP2).

Embora, tecnicamente, a primeira solução ofereça uma qualidade superior, a segunda apresenta como atrativos o custo reduzido (não há a necessidade de contratação de enlaces adicionais) e a rapidez na disposição do serviço (basta fazer a configuração nos roteadores do caminho, uma vez que a estrutura já se encontra disponível).

Em junho de 2001, a RNP iniciou um projeto piloto, cujo objetivo foi estudar, avaliar e testar qualidade de serviço IP no backbone RNP2. Como resultado do piloto, pode-se destacar a proposta de uma estrutura QoS no RNP2, bem como a experiência adquirida e as considerações acerca da implementação.

Este artigo enfoca o último resultado e começa mostrando duas opções de arquitetura de QoS, o intserv ⁽¹⁾ e o diffserv ⁽²⁾. A seguir, é apresentada a proposta para implementação de serviço diferenciado no backbone RNP2. As possibilidades tecnológicas para implementação da proposta em roteadores Cisco são apresentadas na seqüência, seguidas de uma descrição de como ficam as configurações dos mesmos. Por fim, as conclusões.

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 diferenciação de serviço. Porém, com abordagens distintas, bem como vantagens e desvantagens inerentes a cada uma. Um breve descrição das mesmas apresenta-se a seguir.

^

2.1 Intserv

A Intserv está apoiada em dois pilares: reserva de recursos e controle de admissão, ou seja, antes da transmissão dos pacotes se iniciar, a aplicação faz a solicitação dos serviços, o caminho é configurado e os recursos previamente alocados. Especifica dois níveis de serviços, além do melhor esforço:

• Serviço garantido (RFC2212): para aplicações que necessitam de limites fixos de atraso;
• Serviço de carga controlada (RFC2211): seu desempenho pode ser equiparado ao do melhor esforço sob condições de não congestionamento. Pela definição do RFC, "O serviço de carga controlada fornece ao fluxo de dados cliente uma qualidade de serviço muito próxima a que oferece um elemento de rede não carregado (unloaded), porém usa controle de capacidades para assegurar que este serviço seja recebido mesmo que o elemento de rede esteja sobrecarregado (overloaded)."

Os elementos de rede no Intserv devem implementar quatro componentes:

• Protocolo de sinalização (ex.: RSVP⁽³⁾ ): utilizado na configuração do caminho e reserva de recursos. Implica na manutenção de informações sobre o status de cada fluxo nos nós finais e em todos os roteadores ao longo do caminho;
• Escalonador de pacotes: lida com o envio de pacotes utilizando algum mecanismo de filas ou temporizadores (timers);
• Classificador (classificação Multi-Field): para fins de controle de tráfego e contabilização, cada pacote deve ser mapeado para alguma classe, onde recebem o mesmo tratamento dispensado pelo escalonador de pacotes;
• Rotina de controle de admissão: determina se um novo fluxo pode receber QoS solicitado, sem impactar as garantias anteriores.

Como trabalha no nível de fluxos⁽⁴⁾, não se recomenda seu uso em backbones, pois a implementação das funções acima pode exigir uma quantidade de recursos considerável, 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 seqüência de pacotes como os mesmos endereços, 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 nível de classes, possui uma escalabilidade maior, pois fluxos com requisitos de QoS similares são agregados em uma mesma classe, a qual pode receber um serviço melhor ou pior que outras definidas.

Fornece um modo simples de categorizar e priorizar tráfego: as funções mais complexas de marcação, classificação e condicionamento de tráfego (policiamento e moldagem) ocorrem nos roteadores de borda, enquanto os roteadores do núcleo preocupam-se apenas em como dar o tratamento de expedição às classes de tráfego. A este tratamento, dá-se o nome de per-hop-behavior, ou PHB.

A classificação dos pacotes baseia-se em um campo do cabeçalho IP, denominado DS-field. Este pode ser considerado como uma redefinição do campo Type of Service presente no cabeçalho IPv4, ou Class of Traffic do IPv6. Seis bits do DS-field são usados para identificar o valor de DSCP (differentiated services codepoint), usado na seleção do PHB. Os dois últimos bits (CU - currrently unused), não são utilizados atualmente, e por conseguinte, são desconsiderados pelo Diffserv.

Figura 1 - Representação do DS-field

Existem dois PHBs padronizados:

• Expedited Forwarding PHB (RFC 2598)
  Este PHB pode ser usado para construir serviço fim-a-fim com as seguintes características:
  • Baixa perda;
  • Baixa latência;
  • Baixa variação de atraso, e
  • Banda assegurada.

Do ponto de vista do nó final, tal serviço aparenta ser uma conexão ponto-a-ponto ou uma virtual leased line. Este serviço também tem sido descrito como serviço 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 tráfego (buffer e banda). Dentro de cada classe AF, um pacote IP pode ser associado a um dentre três níveis diferentes de precedência de descarte. Este PHB pode ser usado para implementar serviços que garantam um valor de banda, mesmo em tempos de congestionamento. Um exemplo é o serviço Olímpico (Gold, Silver e Bronze).

Valores de DSCP recomendados para identificar os PHBs

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

^

3. Proposta de implementação

A proposta para implementar Diffserv sob demanda no backbone RNP2 se vale de pré-configurações 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 faça parte de uma malha que deve prover garantias de QoS para um determinado tráfego, este roteador será classificado como roteador de borda e/ou de núcleo e desempenhará suas respectivas funções. Os roteadores de borda são aqueles que se encontram nas extremidades da conexão, servindo como porta de acesso ao "core", e os de núcleo são os demais roteadores ao longo do caminho, ou dos possíveis caminhos. No caso do RNP2, dependendo da situação, alguns roteadores poderão fazer o papel de roteador de borda e de núcleo ao mesmo tempo.

A partir daí, são implementados os PHB EF (Premium) e AF (Olímpico). Ou seja, após definidas as classes de serviço, o tráfego será classificado, marcado e possivelmente condicionado (tudo isso) nas bordas e, no núcleo, será efetuado o gerenciamento de congestionamento. A figura a seguir exemplifica a distribuição das funções.

Figura 2 - Distribuição de funções nos roteadores de borda e núcleo

Uma observação a ser feita é que, embora estejam definidas cinco classes de serviço, há a possibilidade de uma implementação parcial, visto que atualmente não existe demanda para todas estas classes concorrentemente. Ou seja, uma estratégia de implementação pode considerar, inicialmente, apenas a configuração de duas classes de serviço: Premium e Gold, além da classe de melhor esforço. Dessa forma, um exemplo de mapeamento de aplicações seria:

Proteção do tráfego priorizado

O fato da classificação 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 serviço (caso os valores de DSCP do pacote e da classe coincidam). Surge, então, a necessidade de mecanismos adicionais de controle de acesso e autenticação que assegurem a utilização das classes de serviço apenas pelos dados dos usuários que os contrataram. Para resolver este problema, foram consideradas duas estratégias:

• Remarcação dos pacotes da classe melhor esforço (que não irá necessitar de priorização) com DSCP 0 nas bordas. Este mecanismo deve ser implementado em todos os roteadores do backbone, uma vez que o tráfego espúrio pode entrar por qualquer ponto do mesmo;
• Criar listas de acesso (access-lists), casando o tráfego prioritário em todos os roteadores do caminho. Esta solução deve ser adotada com cautela, pois o consumo de recursos no roteador pode ser considerável.

A adoção de uma destas estratégias está condicionada a testes que visem estudar o impacto dessas soluções no desempenho do backbone.

^

4. Opções de implementação

Considerando-se que os roteadores do backbone são todos Cisco, as características que podem ser usadas nas implementações das funções são mostradas na tabela abaixo.

Outra questão a ser levada em consideração é a característica da aplicação a ser protegida. Algumas são sensíveis a atrasos e/ou perda de pacotes, enquanto outras são vorazes no consumo de banda. O documento da Cisco "Implementing Quality of Service (QoS)" apresenta uma tabela para servir de guia na escolha das características (features), considerando esse aspecto:

^

5. Exemplo de implementação

Nesta seção, é apresentado um exemplo de implementação, considerando:

• Classes de serviço: Premium (LLQ); Gold, Silver e Bronze (CBWFQ);
• Classificação, marcação e moldagem nos roteadores de borda;
• Controle de congestionamento no núcleo.

^

5.1 Configuração nos roteadores de borda

Neste esquema, o tráfego entrante é classificado usando listas de acesso e, depois, marcado através da configuração do campo DSCP. Este campo será usado pelos roteadores intermediários para associar os pacotes às respectivas classes de serviço. Para garantir que o tráfego não ultrapasse os valores acordados, será feita a moldagem do mesmo na saída do roteador.

^

5.1.1 Definição das classes

São definidos dois conjuntos de classes nos roteadores de borda. O primeiro refere-se à classificação do tráfego baseada em algum critério, por exemplo endereços IP e/ou porta da aplicação, que identifique os dados que deverão ser atendidos pelas classes de serviços. Estas serão posteriormente referenciadas na marcação dos pacotes através da configuração do valor de DSCP.

O segundo conjunto, refere-se às classes de serviço baseados nos valores de DSCP.

^

5.1.2 Classificação 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 classificação por endereços IP e/ou porta da aplicação, ou outro requisito que caracterize o tráfego a ser priorizado.

^

5.1.3 Marcação dos pacotes

O comando policy-map é utilizado para configurar as características de QoS que devem estar associadas ao tráfego previamente classificado. Neste caso, a marcação do campo DSCP é feita através 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 Configuração das políticas

Estas se referem à configuração da banda reservada para cada classe.

Obs: o total das bandas configuradas em todas as classes (P+G+S+B) não deve ultrapassar a 75% da banda total do enlace, a fim de se garantir o tráfego das informações 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-Olímpico
    class premium
        priority (9) P
    class gold
        bandwidth(10) G
    class silver
        bandwidth S
    class bronze
        bandwidth B

^

5.1.5 Moldagem do tráfego na interface de saída

traffic-shape group⁽¹¹⁾ N2 G G1 G1
traffic-shape group    N3 S S1 S1
traffic-shape group    N3 B B1 B1

Uma dica: quando não se sabe como definir os valores para "normal burst size" e "excess burst size", uma opção é efetuar o cálculo considerando o tráfego de 1,5 segundos. Por exemplo, supondo que o valor máximo da banda da classe (primeiro parâmetro) seja 64000 bps, o tráfego referente a 1,5 segundos é 96000 bps, ou 12000 bytes por segundo, para os dois últimos parâmetros.

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 implementação do LLQ se dá através do comando priority bandwidth, o qual reserva uma priority queue estrita para o tráfego 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 tráfego classificado através da access-list. Os 3 parâmetros subseqüentes correspondem a: bit-rate [burst-size] [excess-burst-size].

^

5.1.6 Aplicação das políticas nas interfaces

Na interface local do roteador, por onde entra o tráfego a ser priorizado, aplica-se a política de marcação dos pacotes:

     service-policy input MARCADSCP

Na interface de saída, aplica-se as políticas de priorização do tráfego:

     service-policy output Premium-olimpico

^

5.2 Configuração nos roteadores do núcleo

Nos roteadores do núcleo (core), o enfoque está no tratamento do tráfego associado às classes: priorização e controle de congestionamento.

^

5.2.1 Definição das classes

Como os pacotes já entram marcados, as únicas classes definidas são as dos serviços propriamente ditos.

^

5.2.2 Configuração das políticas

As políticas referem-se à priorização, garantia de banda para cada classe e controle de congestionamento ⁽¹²⁾, considerando-se que o tráfego seja TCP.

No caso particular da implementação do serviço Premium, a prevenção de congestionamento não será implementada, seguindo a recomendação da Cisco de não 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-Olímpico
    class premium
        priority P
    class gold
        bandwidth G
        random-detect ^{( 13 )} 
    class silver
        bandwidth S
        random-detect
    class bronze
        bandwidth B
        random-detect

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, não apresentando parâmetros, uma vez que se usa os valores default.

^

5.2.3 Aplicação das políticas na interface

Na interface de saída, aplicar as políticas de priorização do tráfego:

          service-policy output Premium-olimpico

^

5.3 Exemplo aplicado ao backbone RNP2

Tome-se como exemplo uma videoconferência entre uma instituição no Rio de Janeiro e outra em Minas Gerais, na qual ambas podem transmitir e receber sinal, e uma outra instituição na Paraíba podendo receber o sinal de ambas, porém sem interagir com Rio e Minas.

Figura 3 - Topologia das conexões no exemplo citado

Neste exemplo hipotético, é possível ver, através 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 núcleo; e o roteador do PoP-RJ funciona tanto como roteador de borda, quanto como de núcleo. Um roteador que acumule as duas funções deve ter uma configuração que abranja os dois casos, ou seja, faça a marcação (policy-map MARCADSCP), defina as classes de serviço e o controle de congestionamento (policy-map Premium-Olímpico com o WRED habilitado) e efetue a moldagem no tráfego de saída.

No caso do roteador de PB, apesar dele estar na "borda" da comunicação, ele não precisará fazer nenhum tipo de marcação e classificação, pois a instituição hipotética ligada a ele não 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 videoconferência para a interface de saída que aponta para a respectiva instituição participante da melhor maneira possível. Caso haja perigo de contenção (congestionamento), é possível usar o mesmo police-map de saída comumente definido para os roteadores do núcleo e de borda.

^

5.4 Restrições

A principal restrição decorre da própria arquitetura DiffServ: ausência de mecanismos de controle de admissão. Ou seja, uma vez que a classe de serviços é definida, não existe controle de quantos fluxos poderão estar entrando nesta classe. Um exemplo é o caso da classe prioritária configurada para atender ao tráfego VoIP, cuja banda alocada suporta até três ligações simultâneas. Se uma quarta ligação for estabelecida, esta poderá entrar na mesma classe, compartilhar a banda e acabar degradando a qualidade de todas, uma vez que a banda garantida não é suficiente para quatro ligações simultâneas. Portanto, torna-se necessária a adoção de mecanismos externos à arquitetura, para efetuar este tipo de controle.

Outras restrições são decorrentes da própria estrutura atual do backbone, onde ainda não há uma uniformidade nas versão de IOS decorrente, principalmente, de limitações de hardware em alguns roteadores. Ou seja, dependendo do nível da versão de IOS, nem todas as características estão disponíveis.

A proposta contempla apenas QoS no backbone, e não necessariamente fim-a-fim. Ou seja, cabe ao solicitante prover a garantia de serviço até a entrada neste.

^

6. Conclusão

Atualmente, já existem arquiteturas padronizadas e equipamentos com mecanismos para controles de congestionamento, classificação, priorização e condicionamento de tráfegos; ou seja, o ponto crítico não é mais a existência do instrumental necessário, mas fazer a escolha adequada, considerando o ambiente de produção particular. Considerando as arquiteturas atuais, a melhor maneira de se garantir qualidade de serviço no backbone RNP2 é através do uso de Diffserv.

Devido a diversos aspectos relacionados com a heterogeneidade da rede, este artigo apresenta uma proposta de implementação sob demanda de serviço diferenciado no backbone da RNP. Esta implementação dá-se por meio de pré-configurações a serem parametrizadas e habilitadas sempre que houver solicitação de garantia de QoS. Apenas os roteadores envolvidos em cada caso serão configurados, ou seja, serão parametrizados e terão os police-maps aplicados às devidas interfaces.

Num próximo artigo, será feito um levantamento mais detalhado sobre as funcionalidades da Cisco para implementação de serviço diferenciado, suas restrições e aplicabilidades.

^

Referências bibliográficas

[1] "An Architecture for Differentiated Services" (RFC2475), dezembro, 1998.

[2] "Assured Forwarding PHB Group" (RFC2597), junho, 1999.

[3] "An Expedited Forwarding PHB" (RFC2598), junho, 1999.

[4] "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification" (RFC3086), abril 2001.

[5] "A Framework for Integrated Services Operation over Diffserv Networks" (RFC2998), novembro 2000.

[6] "A Two-bit Differentiated Services Architecture for the Internet" (RFC2638), julho, 1999.

[7] "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (RFC2474), dezembro, 1998.

[8] Cisco ( http://www.cisco.com ) - Documentos:

Introduction: Quality of Service Overview
DiffServ-The Scalable End-to-End QoS Model
Implementing Quality of Service (QoS)
Implementing DiffServ for End-to-End Quality of Service
Planning for Quality of Service
Configuring Quality of Service for Voice
IOS Quality of Service
Modular Quality of Service Command-Line Interface
Class-Based Weighted Fair
Low Latency Queueing
Configuring Low Latency Queueing
Configuring Committed Access Rate
Configuring Weighted Random Early Detection
Configuring Generic traffic Shaping

[9] QoS Technical Tips ( http://www.cisco.com/warp/public/105/qos_index.shtml )

[10] QBONE - http://qbone.internet2.edu/

[11] ABILENE - http://www.internet2.edu/abilene/qos/

[12] TF-TANT - http://www.dante.net/tf-tant/

[13] Esnet - http://www.lbl.gov/CS/qos.html

[14] Internet QoS: the Big Picture, X. Xiao, L. M. Li. IEEE Network, vol. 13, no. 2, pp. 1-13, março/abril 1999.

[15] Differentiated Services: A New Approach for Quality in the Internet, F. Baumgartner, T. Braun, P. Habegger. Proceedings. of the 8th IFIP Conference on High Performance Networking - HPN'98, stembro 1998.

[16] A Comparative Study of Schemes for Differentiated Services, A. Basu, Z. Wang,

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004