Diffserv:

resumo:

Os serviços diferenciados (diffServ) podem ser oferecidos por um conjunto de roteadores que formam  um domínio administrativo (por exemplo, um ISP ou uma empresa de telecomunicações). A administração define um conjunto de classes de serviço com regras de encaminhamento correspondentes a os pacotes do cliente que entrarem no domínio que poderão incluir um campo Tipo de serviço, sendo fornecido um serviço melhor para algumas classes (por exemplo, um serviço especial) melhor que a outras. O trafego dentro de uma classe talvez tenha de obedecer a alguma forma especifica, como a de um balde furado com alguma taxa de escoamento especificada.

Introdução

Os algoritmos baseados no fluxo tem potencial para oferecer boa qualidade de serviço a um ou mais fluxos, porque eles reservam quaisquer recursos necessários ao longo da rota. Porem, eles também tem a desvantagem de exigirem uma configuração antecipada para estabelecer cada fluxo, algo que não se ajusta bem quando existem milhares ou milhões de fluxos. Alem disso, eles mantém o estado interno por fluxo nos roteadores, tornando-os vulneráveis a quedas de roteadores. Por fim, as mudança as exigidas no código do roteador são substanciais e envolvem trocas complexas de roteador para roteador, a fim de configurar os fluxos. Em conseqüência disso, ainda existem poucas implementações de RSVP ou de algo semelhante.

Por essas razoes, a IETF também criou uma abordagem mais simples para oferecer qualidade de serviço, uma estratégia que pode ser implementada em grande parte no local em cada roteador, sem configuração antecipada e sem ter de envolver todo o caminho. Essa abordagem e conhecida como qualidade de serviço baseada na classe (em vez de ser baseada no fluxo). A IETF padronizou uma arquitetura para ela, chamada arquitetura de serviços diferenciados, descrita nas RFCs 2474, 2475 e varias outras.

DA ARQUITETURA DIFFSERV

A arquitetura DiffServ visa prover diferenciação de serviço escalável e flexível – isto é, a capacidade de manipular diferentes ‘classes’ de trafego de maneiras diferentes dentro da internet. A necessidade de escalabilidade surge do fato de que centenas de fluxos de tráfego fonte-destino simultaneamente podem estar presentes em um roteador de blackbone da internet.Veremos que essa necessidade é satisfeita pela introdução de uma funcionalidade simples no núcleo da rede, com a implementação de operações de controle mais complexas na borda da rede. A necessidade de flexibilidade surge do fato de que novas classes de serviços podem surgir e velhas classes de serviços podem se tornar obsoletas. A arquitetura DiffServ é flexível, no sentido de que não define serviços nem classes de serviços especificas (como é o caso, por exemplo da arquitetura IntServ). Em vez disso, ela fornece os componentes funcionais, isto é, as peças de uma arquitetura de rede com as quais esses serviços podem ser montados.

Diferenças entre Qualidade baseada em Fluxo e Classe.

Para tornar mais clara a diferença entre a qualidade de serviço baseada no fluxo e a qualidade de serviço baseada na classe, vamos considerar o exemplo da telefonia na Internet. Com um esquema baseado no fluxo, cada chamada telefônica obtém seus próprios recursos e suas garantias. Com um esquema baseado na classe, todas as chamadas telefônicas juntas obtêm os recursos reservados para a telefonia da classe. Esses recursos não podem ser tirados pelos pacotes da classe de transferência de arquivos ou de outras classes, mas nenhuma chamada telefônica recebe quaisquer recursos privados reservados apenas para ela.

Encaminhamento expedido

A escolha de classes de serviço cabe a cada operadora, mas, como os pacotes com freqüência são encaminhados entre sub-redes pertencentes a diferentes operadoras, a IETF esta trabalhando na definicao de classes de serviço independentes da rede. A mais simples dessas classes e a de encaminhamento expedido; portanto, vamos começar por ela. Essa classe e descrita na RFC 3246.

A idéia que rege o encaminhamento expedido e muito simples. Ha duas classes de serviço disponíveis: regular e expedido. A vasta maioria do trafego deve ser regular, mas uma pequena fração dos pacotes e expedida. Os pacotes expedidos devem ser capazes de transitar pela sub-rede como se nenhum outro pacote estivesse presente. Uma representação simbólica desse sistema de "dois tubos" e dada na Figura logo abaixo  Observe que ainda existe apenas uma linha física. Os dois canais lógicos mostrados na figura representam um modo de reservar largura de banda, e não uma segunda linha física.

Um modo de implementar essa estratégia e programar os roteadores para terem duas filas de saída correspondentes a cada linha de saída, uma para pacotes expedidos e outra para pacotes regulares. Quando um pacote chega, ele enfileirado de acordo com seu tipo. A programação de pacotes deve usar algo semelhante ao enfileiramento justo ponderado. Por exemplo, se 10% do trafego for expedido e 90% for regular, 20% da largura de banda poderá ser dedicada ao trafego expedido, e o restante ao trafego regular. Isso daria ao trafego expedido o dobro da largura de banda de que ele necessitasse, com a finalidade de proporcionar baixo retardo para esse tipo de trafego. Essa alocação pode ser2 alcançada transmitindo um pacote expedido para cada quatro pacotes regulares (supondo-se que a distribuição de tamanhos para ambas as classes seja semelhante). Desse modo, espera-se que os pacotes expedidos encontrem uma sub-rede não carregada, mesmo quando houver de fato uma carga pesada.

Encaminhamento garantido

Um esquema um pouco mais elaborado para gerenciar as classes de serviço e chamado

encaminhamento garantido. Ele e descrito na RFC 2597 e especifica que haverá quatro classes de prioridade, e cada classe terá seus próprios recursos. Alem disso, ele define três probabilidades de descarte de pacotes que estejam sofrendo congestionamento: baixo, medio e alto. Considerados em conjunto, esses dois fatores definem 12 classes de serviço.

A Figura a ser mostrada mostra uma forma possível de processar pacotes no esquema de encaminhamento garantido. A etapa 1 consiste em classificar os pacotes em uma das quatro classes de prioridade.

Essa etapa poderia ser feita no host transmissor (como mostra a figura) ou no roteador de ingresso (o primeiro). A vantagem de fazer a classificação no host transmissor e que nesse local ha mais informações disponíveis sobre quais pacotes pertencem a quais fluxos.

A figura abaixo é uma implementação possível do fluxo de dados para encaminhamento garantido.

A etapa 2 e a marcação dos pacotes de acordo com sua classe. E necessário um campo de

cabeçalho para esse propósito. Felizmente, ha um campo de 8 bits Type of service disponível no cabeçalho IP, como veremos em breve. A RFC 2597 especifica que seis desses bits devem ser usados para a classe de serviço, deixando espaço de codificação para classes de serviço históricas e futuras.

A etapa 3 consiste em fazer os pacotes passarem por um filtro modelador/regulador que pode

retardar ou descartar alguns deles para modelar os quatro fluxos em formas aceitáveis; por

exemplo, usando o balde furado ou o balde de símbolos. Se houver muitos pacotes, alguns deles talvez sejam descartados aqui, pela categoria de descarte. Também são possíveis esquemas mais elaborados, envolvendo medição ou feedback.

Nesse exemplo, essas três etapas são executadas no host de transmissão, e assim o fluxo de saída e agora entregue ao roteador de ingresso. Vale a pena notar que essas etapas podem ser executadas por software em rede especial, ou ate mesmo pelo sistema operacional, a fim de evitar a necessidade de trocas entre aplicações existentes.

Conclusão

Visando sempre um melhor serviço vemos o crescente uso de QoS em grandes redes, a implantação de QoS em uma rede IP traz profundas mudanças no cenário a internet. Certamente, uma delas é a possibilidade de provedores de serviços oferecerem telefonia de boa qualidade e alta confiabilidade NE internet. Podemos inferir que o sucesso dessas propostas mudará o blackbone das empresas de telecomunicação, pois todas as propostas de QoS implicam no uso racional da banda de passagem disponível e no suporte ao trafego real.