Qualidade de Serviço sobre Redes TCP/IP

QoS on IP - Qualidade de Serviço sobre o Protocolo TCP/IP

© Timóteo dos Santos Oliveira ? Mestrando em Engenharia de Telecom

INATEL ? Santa Rita do Sapucaí - MG


Desenvolvido por universidades na década de 60 o protocolo TCP/IP logo chamou a atenção do DoD- Departamento de Defesa dos Estados Unidos, no anseio de manter a comunicação entre seus sistemas espalhados pelo mundo mesmo em caso de desastres nucleares, apesar das incompatibilidades com os sistemas em uso na época. Então coube a ARPA resolver esses problemas e compatibilizar a tecnologia com os padrões de comunicação, surgindo assim uma aliança entre fabricantes e institutos de pesquisa chamada ARPANET que resultou na origem da internet que temos hoje.

Invariavelmente o grande destaque do TCP/IP é a sua ubiqüidade e a interoperabilidade de comunicação com todos os tipos de hardware e sistemas operacionais, aumentando assim ainda mais gama de nós que podem ser agregados a grande rede, tornando-se assim o padrão universal de suporte para essas aplicações.

No entanto esse protocolo por sempre sustentar o discurso de que poderia ser usado sobre qualquer tipo de meio físico sendo ele de qualquer tecnologia, apresentando ou não confiabilidade com alto ou baixo desempenho e por ser um protocolo relativamente simples o mesmo se abstêm a algumas limitações como a falta de garantia no transito de pacotes, atrasos na transferência entre outros, que acabam por deixar um pouco pra trás um item que cada vez mais se faz primordial em redes de computadores que é a qualidade na operação desses serviços o QoS. E como as redes tem migrado cada vez mais para aplicações robustas como o trafego de grande quantidade de dados, vídeo e voz, o usuário que esta na ponta também esta cada vez mais exigente e não quer saber de ficar esperando por vídeos que travam ou nem carregam no seu browser ou chamadas por voz inaudíveis ou que nem se completam, e tudo isso influencia na eficiência da qualidade de serviço.

A necessidade de garantia de que o serviço será realizado exige a aplicação de tecnologias que permitam atingir um nível de trafego satisfatório e confiável para os dados e aplicações por meio de parâmetros e mecanismos dedicados a este fim.

O TCP/IP diferentemente do ATM é orientado a comutação pacotes coisa que na época de sua concepção apesar do vislumbramento que causou, devido as diversas novidades que trazia como a possibilidade de integrar conexões abertas e possibilitar a proliferação da conectividade lan a wan em diversos ambientes, sua metodologia fugia as regras até então empregadas pelas empresas de telefonia que utilizavam comutação de circuitos. A AT&T, por exemplo debochou e tentou desestimular a idéia de que funcionaria um conceito diferente da comutação por circuito para transferência de dados, voz e vídeo. Uma rede onde as informações transmitidas pudessem encontrar seu próprio caminho na rede? Impossível! Naquela época a empresa telefônica até poderia estar correta em sua posição mas apenas no caso de serviços de voz, aja visto que voz e dados não podem resistir a nenhum retardo pequeno que seja, mas os dados podem.

Em comutação de circuitos um percurso é construído antes do envio das informações, ou seja quando um usuário faz uma chamada telefônica a companhia cria fisicamente um circuito para essa chamada e não se pode falar ou transmitir informações até que o circuito seja criado Já em comutação de pacotes o percurso é encontrado em tempo real, e sempre o percurso deve ser igual, ou não, porem as informações sempre vão de um ponto A a um ponto B, e as informações necessárias para atingir a estação de destino estão no cabeçalho das informações que estão sendo enviadas.

Dados da própria web revelam que só em 2010 trafegou na internet o nível de informação comparável ou até maior que tudo o que já existiu antes, ou seja chegamos em uma época em que as redes sociais, blogs, downloads, p2p e tudo mais dominam praticamente toda a banda disponível de conexões e cada vez mais existem pessoas comprando sempre a melhor conexão disponível para ter o melhor serviço, e o problema é que no Brasil essa demanda é cada vez maior e a oferta é mínima, sem contar que os estudos sobre internet do futuro, e demais pesquisas na área apontam que isso só tende a aumentar. Baseado nisso tem se criado ao longo dos tempos mecanismos que tentam fazer com que essa carência de banda ou trafego disponível se torne menor ou pelo menos fazer com que os serviços que trafegam nas redes sejam entregues de maneira rápida e eficiente, que é justamente o que faz um mecanismo de QoS.

E como o TCP/IP tinha essa carência tem sido usado mecanismos integrados com serviços diferenciados como o RSVP que é uma arquitetura desenvolvida para prover garantias de QoS em redes IP para sessões individuais de aplicações multimídia por meio de fluxos ou serviços integrados como o IntServ.

O RSVP, também conhecido como protocolo de reserva de recursos, procura sanar a carência de QoS no IP haja visto que a internet não foi concebida com intenções de qualidade de serviço o RSVP é a uma solução nesse sentido, tal que seus benefícios são altamente relevantes em aplicações multicast podendo ser utilizado também em aplicações unicast, permitindo que as estações da rede reservem recursos por meio dos roteadores da mesma. É implícito que se o serviço de rede for perfeito, facilita o trabalho da camada de transporte, mas caso contrario a camada de transporte terá que servir de ponte para cobrir a distancia entre o que os usuários de transporte desejam e o que a camada de rede oferece. Basicamente todas as máquinas na rede capazes de enviar dados QoS enviam uma mensagem de PATH a cada 30 segundos, que será difundida a toda a rede, aqueles que desejem aceitá-lo enviam uma mensagem de RESV (diminutivo de Reserve) que irá servir para resolver o caminho de volta para o emissor e essa mensagem RESV irá incluir também as especificações de fluxo.

Os routers entre o emissor e receptor decidem então se podem suportar a reserva requerida e, em caso negativo, enviam uma mensagem de rejeição para notificar o interlocutor. Caso contrário, assim que aceitam a reserva serão responsáveis por suportar o tráfego. Entretanto, os routers armazenam a natureza do fluxo e o regulam sob um estado de volatilidade, o que significa que se não existir contato durante um determinado período de tempo, o tempo de escuta irá expirar e a reserva será cancelada. Esta medida permite resolver situações em que o emissor ou o receptor bloqueiam ou são desligados incorretamente sem previamente cancelar as reservas. Individualmente, os routers podem como opção, sondar o tráfego para garantir a conformidade com as especificações de fluxo.

O principal problema do modelo IntServ é a necessidade de armazenar os múltiplos estados em cada router, entretanto o IntServ torna-se praticável numa escala reduzida, embora com o escalonamento até um sistema das dimensões da Internet, se torna difícil de gerir todas as reservas.

Já a arquitetura DiffServ parte do princípio que domínios adjacentes tenham um controle sobre os serviços que serão disponibilizados entre os mesmos, denominado de SLA ? Service Level Agreement. Um SLA determina as classes de serviços suportadas e a quantidade de tráfego na banda entre os domínios. Os domínios podem definir um SLA estático ou dinâmico, sendo que, neste último caso, um protocolo de sinalização e controle será necessário para o gerenciamento da banda.

Dois novos tipos de serviços especiais surgiram juntamente com o modelo de serviços diferenciados: serviços assegurados e os serviços premium. Serviços assegurados são os serviços para clientes que precisam de segurança para seus provedores servidos no momento que haja um congestionamento. E os serviços premium são para aplicações que necessitam de baixo atraso e baixo jitter.

Com o DiffServ, os próprios clientes podem marcar seus DS Fields e enviar para o receptor. No entanto, dessa forma, não há como saber se há recursos disponíveis para a comunicação, fazendo com que, por exemplo, o pacote chegando em um roteador que não provê QoS com o DS Field marcado, seja remarcado e passe a ser um pacote de um serviço de melhor esforço.

Existem tipos de serviços que não podem conviver com essa incerteza. Por isso, um componente mediador foi inserido nesse modelo para gerenciar recursos no domínio QoS, denominado Bandwidth Broker (BB). O BB trabalha como um gerente de recursos do domínio que tem com função básica controlar a largura de banda, as políticas e prioridades dentro e entre as organizações. Quando há uma solicitação de um fluxo, o BB é o componente que verifica a disponibilidade de recursos e a autorização do cliente para conexão dentro do domínio QoS. Ele também encarrega-se de fazer as alocações necessárias para a comunicação dentro do seu domínio e solicita ao BB do domínio adjacente, caso o pedido de conexão seja para fora do domínio, para fazer o mesmo. O processo de solicitação de alocação de recursos é continuado entre BBs adjacentes até que se chegue ao BB do domínio do receptor. O protocolo de sinalização para alocação de recursos entre os BBs pode ser o RSVP.

Serviços diferenciados tem sido o modelo mais utilizado para implementação de QoS. Ele exige menos dos roteadores, necessitando pouca atualização de software para prover bons métodos de classificação, policiamento, montagem e remarcação de pacotes.

Concluindo esperamos que as pesquisas e inovações na área de internet do futuro e outras áreas emergentes em plena discussão possam trazer soluções para muitos dos problemas que temos nas redes atuais, pois nada melhor que uma tecnologia após outra.



Referências:

- Boletim bimestral sobre tecnologia de redes produzido e publicado pela RNP ? Rede Nacional de Ensino e Pesquisa 12 de novembro de 1999 | volume 3, número 6, ISSN 1518-5974.

- ALBERTI, Antonio M.,"Melhorando a QoS em Redes IP", Curso de Mestrado, INATEL.

- TANEMBAUM, Andrew S., Redes de Computadores. Rio de Janeiro: Elsevier, 2003. 10ª Reimpressão.