Estive um pouco afastado pela correria de muitos projetos, mudança de São Paulo para o Rio de Janeiro, mas enfim, quando sobra um tempinho corro aqui para escrever para o iMasters.

Vamos continuar no assunto QOS e neste artigo vou concluir todo o tópico de QOS.

Nas matérias anteriores eu falei um pouco sobre Conceitos de QOS, onde abordamos o princípio do QOS. Depois falamos sobre Componentes do QOS. Para concluirmos todo o tópico de QOS faltava a definição das classes, que falaremos neste artigo

Definição das classes Classificação dos pacotes

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.

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.

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 comandoset 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

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  P
    class gold
        bandwidth G
    class silver
        bandwidth S
    class bronze
        bandwidth B

Moldagem do tráfego na interface de saída

traffic-shape group(11) 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.

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, aplicam-se as políticas de priorização do tráfego:

     service-policy output Premium-olimpico

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.

Definição das classes

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

Configuração das políticas

As políticas referem-se à priorização, garantia de banda para cada classe e controle de congestionamento(12), 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

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

Exemplo aplicado a um backbone

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.

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 de ele 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.

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.

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, faremos um levantamento mais detalhado sobre as funcionalidades da Cisco para implementação de serviço diferenciado, suas restrições e aplicabilidades.