Perspectivas sobre Qualidade de Serviço nos Protocolos da Internet - Estudo de Caso: Aplicações de Vídeo Sob Demanda

Aline C. Viana <aline@apice.ufg.br>
Anibal S. Jukemura <anibal@apice.ufg.br>
Daniela A. Xavier <daniela@apice.ufg.br>
Kleber V. Cardoso <kleber@apice.ufg.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
1.1 Serviços Integrados (IntServ)
1.2 Serviços Diferenciados (DiffServ)
1.3 Integração
2. Perspectivas sobre QoS na Internet
2.1 O Ambiente
2.2 Validação da Proposta
3. Conclusões
4. Referências

Resumo

A proposta da Internet 2 envolve mais que criar uma infra-estrutura de comunicação com ampla largura de banda, ela abrange a disponibilização de novas tecnologias capazes de suportar aplicações interativas e sensíveis ao tempo. Dentro dessa perspectiva a capacidade de suportar QoS (Quality of Service - Qualidade de Serviço) pela infra-estrutura de rede se torna uma característica necessária, a qual novos modelos de arquiteturas, como de Serviços Integrados e Serviços Diferenciados, se propõem a atender. A efetividade e a viabilidade dos protocolos que suportam QoS no nível de rede da Internet, assim como a necessidade de iteração dos mesmos são os tópicos principais desse trabalho.

Descreveremos um estudo de caso de um tráfego modelado de Vídeo Sob Demanda em uma infra-estrutura composta por implementações que abrangem partes dos Modelos de Serviços Integrados e Serviços Diferenciados. Utilizamos o protocolo RSVP, implementado na forma de um daemon, para realizar sinalização de recursos e, controle de tráfego implementado como suporte no kernel e configurado pela ferramenta tc (traffic control), para efetivar a alocação de recursos sinalizada. Fizemos uso do sistema operacional Linux sobre uma infra-estrutura de rede ATM de 25Mbps, com serviço de emulação de LAN (LAN Emulation). Os resultados de nossos testes validaram a importância de realizar reservas de recursos na infra-estrutura de rede e que tais reservas são viáveis e efetivas quando realizadas no nível de rede da Internet.

^

1. Introdução

Integrar diferentes tipos de tráfegos em uma rede comutada de pacotes de forma escalável e flexível é uma solução almejada, sobretudo se considerarmos que esta rede é a Internet. O que dificulta esta integração é que aplicações de tempo real têm necessidades diferentes das aplicações convencionais [Kuo98]. O modelo de serviço tradicional oferece somente serviço de Melhor Esforço, bastante adequado para um grande número de aplicações (que não são sensíveis ao tempo). Entretanto, o serviço de Melhor Esforço não é adequado para tráfego sensível a atrasos, perdas de pacotes ou variações no atraso. Estes tipos de distorções podem diminuir severamente a qualidade da transmissão de tempo real, podendo até mesmo inviabilizá-la [Blake98, Braden94].

Afim de se atender as necessidades de uma aplicação de tempo real (vídeo sob demanda, vídeo conferência, etc) faz-se necessária a inserção de novas características à infra-estrutura para oferecer Qualidade de Serviço [Kuo98]. Em linhas gerais, isto pode ser obtido através da inclusão de itens como: controle de tráfego, alocação e gerência de recursos, policiamento, controle de admissão, entre outros [Blake98, Braden94, Braden97].

Devido à ampla abrangência que o suite de protocolos IP conquistou nas redes de comunicação de dados existentes hoje, sobretudo com o próprio serviço de Melhor Esforço, apoiamos a afirmativa [Blake98, Braden94, Xiao99] de que soluções que atendam às novas demandas de tráfego devem, ainda, manter as características originais e, adicionar a estas novos recursos necessários ao tráfego de tempo real. As características do suite de protocolos IP, que se deseja manter, podem ser vistas em [CerfKahn74, Clark88].

Com a preocupação de tratar tais necessidades para o ambiente de tráfego da Internet, duas abordagens distintas de fornecimento de serviços foram propostas pelo IETF (Internet Engineering Task Force) nos últimos anos: a Arquitetura de Serviços Integrados [Braden94] e a Arquitetura de Serviços Diferenciados [Blake98]. Ambas as propostas possuem vantagens e desvantagens. Desta forma, pesquisas realizadas [Magalhães97] mostram que a integração de IntServ (RSVP) e DiffServ deverá ser a solução mais apropriada para a obtenção de Qualidade de Serviço (QoS), característica esta essencial para a transmissão adequada de aplicações de tempo real. Tal integração ofereceria, no núcleo da Internet, a escalabilidade proporcionada pelo DiffServ e, nas redes de borda, uma QoS quantitativa fim-a-fim proporcionada pelo IntServ, empregando-se o protocolo de sinalização RSVP.

No contexto da Internet 2, cuja parte inicial no Brasil é representada pelas ReMAVs, a infra-estrutura predominante é a tecnologia ATM, a qual constitui uma rede com conexão e com suporte nativo à Qualidade de Serviço. Porém, o suporte ao suite de protocolos IP pretende ser conservado [Blake98, Braden94, Xiao99]. Ainda que, sob determinado ponto de vista, o uso da camada IP possa ser considerado como um excedente desnecessário, pois o ATM (em tese) é capaz de implementar todas suas características; na verdade, o IP oferece um conjunto de vantagens que justifica sua manutenção. Sendo assim, faz-se necessário o mapeamento de qualidade de serviço entre os protocolos da Internet e a tecnologia ATM.

No intuito de validar as principais teorias propostas, realizamos testes práticos com protótipos e ferramentas de domínio público no Linux. As partes utilizadas dos Modelos apresentados foram validadas, assim como seu framework e protocolos.

No ambiente de testes utilizado, foi empregado o protocolo RSVP, o qual sinalizava reservas de recursos requisitadas pela ferramenta de geração de tráfego mgen, ao controle de tráfego ativado. Este último, constitui a implementação de parte dos componentes integrantes das arquiteturas DiffServ e IntServ. O restante deste artigo é estruturado como segue. A subseção 1.1 fornece uma visão geral da Arquitetura de Serviços Integrados, enquanto a sessão 1.2 trata a Arquitetura de Serviços Diferenciados. A subseção 1.3 apresenta perspectivas sobre a integração das duas Arquiteturas ou (Modelos) anteriores. Descrevemos na sessão 2 o ambiente de testes utilizado como uma proposta de implementação de QoS na infra-estrutura da Internet 2, baseando-se nos Modelos apresentados. Apresentamos também nesta sessão os testes realizados, bem como os resultados obtidos. Por fim, a sessão 3 apresenta as conclusões e perspectivas de trabalhos futuros nesta linha de pesquisa.

^

1.1 Serviços Integrados (IntServ)

O Modelo de Serviços Integrados é caracterizado pela reserva de recursos. Para aplicações de tempo real, antes da transmissão dos dados, as aplicações devem configurar caminhos e reservar recursos. RSVP (Resource ReSerVation Protocol) é um protocolo de sinalização para configurar caminhos e reservar recursos. O modelo propõe duas classes de serviço além do Serviço de Melhor Esforço. O primeiro é o Serviço Garantido [Shenker97] para aplicações que exigem limites fixos de atraso. O segundo é o Serviço Preditivo ou de Carga Controlada [Wroclawski97] para aplicações que exigem um limite probabilístico de atraso. A filosofia deste modelo é que "existe uma exigência inescapável para roteadores serem capazes de reservar recursos de forma a fornecer QoS especial para seqüências específicas ou fluxos de pacotes de usuários. Este por sua vez exige estado de fluxo específico nos roteadores" [Braden94].

RSVP foi criado como um protocolo de sinalização para aplicações realizarem reservas de recursos [Braden97]. O processo de sinalização é ilustrado na figura 1. O transmissor envia uma mensagem PATH para o receptor especificando características do tráfego. Cada roteador intermediário ao longo do caminho, passa a mensagem PATH para o próximo hop, determinado pelo protocolo de roteamento. Ao receber uma mensagem PATH, o receptor responde com uma mensagem RESV para requisitar recursos para o fluxo. Cada roteador intermediário ao longo do caminho, pode rejeitar ou aceitar as requisições da mensagem RESV. Se a mensagem for rejeitada, o roteador enviará uma mensagem de erro para o receptor e, o processo de sinalização terminará. Se a sinalização for aceita, largura de banda no enlace e espaço nos buffers são alocados para cada fluxo, e as informações de estado do fluxo relatado, serão instaladas no roteador.

Figura 1: Sinalização RSVP

O Modelo de Serviços Integrados é implementado por quatro componentes: protocolo de sinalização (por exemplo RSVP), rotina de controle de admissão, classificador e escalonador de pacotes. Aplicações exigindo serviço Garantido ou serviço de Carga Controlada, devem configurar caminhos e reservar recursos antes de transmitir seus dados. As rotinas de controle de admissão decidirão se uma requisição por recursos pode ser garantida. Quando um roteador recebe um pacote, o classificador realizará uma classificação Multi-Field (MF) e colocará o pacote em uma fila específica baseada no resultado da classificação. Então, o escalonador de pacotes escalonará os pacotes de forma a satisfazer suas exigências de QoS.

Os problemas com a Arquitetura de Serviços Integrados são:

1. A quantidade de informação de estado aumenta proporcionalmente com o número de fluxos. Isto exige enorme espaço de armazenamento e gera sobrecarga de processamento nos roteadores. Por esta razão, esta arquitetura não é escalável para o núcleo da Internet.
2. A exigências nos roteadores é alta. Todos os roteadores devem implementar RSVP, controle de admissão, classificação MF e escalonamento de pacotes.

^

1.2 Serviços Diferenciados (DiffServ)

Devido à dificuldade em implementar e empregar puramente Serviços Integrados e RSVP, Serviços Diferenciados foram introduzidos. O esforço de Serviços Diferenciados no IETF desenvolveu um modelo simples para diferenciar qualidades na entrega de pacotes. O modelo assume que cada pacote carrega um valor apropriado no campo DS (anteriormente chamado byte TOS - Type Of Service ) do cabeçalho IP. Cada campo DS corresponde a um tratamento diferente de encaminhamento, chamado Per Hop Behavior (PHB) [Nichols98]. Dentro do núcleo da rede, roteadores ordenam pacotes de entrada em diferentes classes de encaminhamento, de acordo com seus valores de DS. Logo, o Modelo de Serviços Diferenciados é essencialmente um esquema de prioridade relativa. Afim de que um cliente receba Serviços Diferenciados a partir de seu provedor de serviços Internet (ISP - Internet Service Provider), ele deve ter um Service Level Agreement (SLA) com seu ISP. Um SLA basicamente, especifica as classes de serviços suportadas e a quantidade de tráfego permitida em cada classe. Um SLA pode ser estático ou dinâmico. SLAs estáticos são negociados de uma forma regular, por exemplo, mensalmente ou anualmente. Clientes com SLAs dinâmicos devem usar um protocolo de sinalização, por exemplo RSVP, para requisitar serviços sob demanda.

Clientes podem marcar o campo DS de pacotes individuais para indicar o serviço desejado, ou podem ser marcados pelo roteador folha.

No ingresso de redes ISP, pacotes são classificados, policiados e possivelmente condicionados (shaped). As regras de classificação, policiamento e condicionamento usadas nos roteadores ingress são derivados a partir das SLAs. A quantidade de espaço de buffer necessário para essas operações, são derivados a partir dos SLAs. Quando um pacote entra em um domínio a partir de outro domínio, seu campo DS pode ser remarcado, como determinado pelo SLA entre os dois domínios [Blake98].

Através do uso de mecanismos de classificação, policiamento, condicionamento e escalonamento, muitos serviços podem ser fornecidos, por exemplo: Expedited Service Premium Service para aplicações exigindo serviços com baixo atraso e baixo jitter [Jacobson99] e Assured Service para aplicações exigindo maior confiabilidade do que a oferecida pelo Serviço de Melhor Esforço [Heinanen99]. Vale lembrar que o Modelo de Serviços Diferenciados apenas define campos DS e PHBs. É responsabilidade dos ISPs decidirem quais serviços fornecer.

O Modelo de Serviços Diferenciados é significativamente diferente de Serviços Integrados. Primeiro, existe apenas um número limitado de classes de serviço indicadas pelo campo DS. Desde que o serviço é alocado na granularidade de uma classe, a quantidade de informação de estado é proporcional ao número de classes, ao invés do número de fluxos. Serviços Diferenciados é portanto mais escalável.

Segundo, operações de classificação sofisticada, marcação, policiamento e condicionamento são apenas necessárias nos limites das redes. Logo, roteadores núcleo necessitam apenas implementar classificações Behavior Aggregate (BA). Sendo assim, é mais fácil implementar e empregar Serviços Diferenciados. Porém, Serviços Diferenciados, como já descrito, é um refinamento do esquema de prioridades relativas cuja principal desvantagem é assegurar desempenho às aplicações apenas em termos relativos. Esquemas de prioridade relativa garantem que uma aplicação gerando tráfego de determinada prioridade terá desempenho melhor que outra gerando tráfego de menor prioridade. Entretanto, dependendo da carga da rede, ambas as aplicações podem ter desempenho muito aquém de suas reais necessidades.

^

1.3 Integração

A arquitetura DiffServ foi desenvolvida como uma forma de oferecer escalabilidade à implementação de QoS na rede, escalabilidade esta que era comprometida no caso da arquitetura IntServ. A escalabilidade no caso da arquitetura DiffServ é obtida através da agregação dos vários fluxos no conceito de classes e na definição de comportamentos dentro da rede para cada uma das classes. A arquitetura não prevê qualquer forma de sinalização. Entretanto, é possível se pensar na implementação de uma solução envolvendo de forma complementar a arquitetura DiffServ e o protocolo RSVP. O protocolo RSVP pode se beneficiar dos aspectos de agregação da arquitetura DiffServ. Esta última, por sua vez, pode utilizar o mecanismo de sinalização de QoS proporcionado pelo RSVP para oferecer uma QoS quantitativa fim-a-fim.

No modelo RSVP-DiffServ existe o conceito de redes stub que implementam a arquitetura IntServ e que interagem com redes de trânsito que implementam a arquitetura DiffServ. As redes de trânsito representam redes de provedores de serviços Internet (ISP) e que manipulam grandes quantidades de tráfego agregado dos clientes. As redes stub representam redes privadas de menor porte. Interconectando estas duas redes encontram-se roteadores que podem ser considerados meio-RSVP e meio-DiffServ. O lado RSVP processa as mensagens PATH e RESV enquanto o lado DiffServ aloca recursos do ponto de vista da rede de trânsito e marca os pacotes de forma apropriada. A figura 2 ilustra a interação de redes stubs através de uma rede de trânsito.

Figura 2: Redes Stub com Arquitetura IntServ interconectadas por Rede de Trânsito com Arquitetura DiffServ

No modelo proposto podemos analisar o seu funcionamento a partir de um host em uma rede stub que é uma fonte de fluxo de dados segundo a arquitetura IntServ. Neste caso, a fonte enviará mensagens PATH juntamente com o fluxo de dados. Esta mensagem atravessará a rede stub, segundo o modelo IntServ, até alcançar o roteador na fronteira com a rede de trânsito. Este roteador enviará a mensagem de PATH através da rede de trânsito de forma transparente, ou seja, os roteadores na rede de trânsito não processarão a mensagem de PATH. A mensagem atravessará a rede de trânsito até alcançar o roteador de saída na fronteira da rede de trânsito com a segunda rede stub. O roteador de saída processa a mensagem de PATH e esta atravessa a segunda rede stub do exemplo, até alcançar o destino. Após receber a mensagem de PATH o destino pode enviar uma mensagem RESV correspondente. Esta mensagem atravessará a segunda rede stub na forma tradicional do modelo IntServ, até alcançar o roteador na fronteira da segunda rede stub com a rede de trânsito. Este roteador, ao receber a mensagem RESV, deve verificar se a rede de trânsito, ou seja, a rede que implementa o modelo DiffServ, possui recursos suficientes para suportar a requisição de reserva contida na mensagem RESV. Caso os recursos existentes na rede de trânsito sejam suficientes, a mensagem RESV será enviada através da rede de trânsito até alcançar o roteador de saída na fronteira da rede de trânsito com a primeira rede stub. O roteador de saída processa a mensagem RESV e esta atravessa a primeira rede stub do exemplo, até alcançar a fonte de fluxo de dados.

Caso não existam recursos suficientes na rede de trânsito uma mensagem de erro será encaminhada até o destino. Os métodos utilizados para determinar se existem recursos disponíveis na rede DiffServ, ou seja, na rede de trânsito, são variados. Idealmente, informações de roteamento e informações sobre a alocação de banda na rede de trânsito devem estar disponíveis de modo que a disponibilidade dos recursos na rede possa ser conhecida de forma determinística. Uma vez que a mensagem RESV seja recebida pela fonte do fluxo de dados, esta poderá começar a marcar o byte DS no cabeçalho dos pacotes com o código DSCP recebido na mensagem RESV. Outra possibilidade é que o roteador na fronteira com a rede de trânsito possa marcar e policiar os pacotes pertencentes ao fluxo de dados. Estes pacotes deverão ser tratados de forma adequada na rede de trânsito baseado somente no conteúdo do byte DS, permitindo oferecer uma QoS fim-a-fim sem comprometer os aspectos de escalabilidade na rede de trânsito.

^

2. Perspectivas sobre QoS na Internet

Como já descrito, objetivamos neste trabalho mostrar o quão importante é ter suporte à Qualidade de Serviço oferecida pela infra-estrutura de rede e como esta estaria disponível para aplicações. Mas ainda, objetivamos mostrar os resultados insatisfatórios que se obtém ao tentar trafegar aplicações sensíveis ao tempo sobre uma infra-estrutura de rede sem reserva de recursos (ou seja, sem QoS), ainda que a rede ofereça uma grande largura de banda, como o caso da tecnologia ATM.

Nossa pesquisa baseia-se ainda na proposta de que a Internet 2 será constituída por uma combinação dos modelos IntServ e DiffServ (como descrito na sessão 1.3), como a forma mais apropriada de se implementar QoS, conservando ainda as vantagens já conhecidas do suite de protocolos IP.

Afim de validar esta proposta, estruturamos um ambiente de testes baseado no sistema operacional Linux com alguns protótipos e ferramentas que implementam características dos dois modelos para possibilitar a implementação de Qualidade de Serviço. O ambiente e as configurações utilizadas, assim como os testes realizados e resultados obtidos, serão descritos nas sessões 2.1 e 2.2, respectivamente.

^

2.1 O Ambiente

O laboratório foi montado focando a infra-estrutura de rede ATM disponibilizada ao projeto ReMAV, apesar da tecnologia Ethernet também estar disponível. Acreditamos que a tecnologia ATM deve prevalecer, futuramente, como a principal infra-estrutura de rede, sobretudo em backbones, e, em alguns casos, disponíveis em hosts terminais. O serviço ATM de emulação de LAN (LANE - LAN Emulation) foi escolhido para uso em todos os consorciados da ReMAV Goiás.

A figura 3 ilustra como o laboratório foi instalado fisicamente.

Figura 3: Diagrama da rede física do Laboratório Ápice no Projeto ReMAV

As ligações entres os computadores e os switches foram realizadas utilizando cabos de par trançado não blindados categoria 5, com distâncias de 2,5 metros ou inferiores. A placa de rede ATM utilizada foi de 25Mbits modelo IBM Turboways. Os computadores eram todos idênticos, possuindo a seguinte configuração:

• Intel Pentium 166 MMX;
• 32 MB de memória RAM (tipo DIMM).

Esses equipamentos são considerados low-end de baixo desempenho e, significativamente limitantes para algumas atividades, como serviço de Vídeo Sob Demanda ou Vídeo Conferência.

Por ser o ambiente de rede utilizado, experimental e não de produção, foi escolhido uma numeração IP de redes isoladas (Intranet), sendo que neste trabalho, a rede IP utilizada foi a Classe C (completa) 192.168.070.000 (máscara de rede 255.255.255.000), sendo o endereço IP 192.168.070.015 utilizado como o do roteador padrão, que era implementado em um switch 8265.

Além disso, o ambiente consistia em uma rede emulada contendo cinco entidades LECs (para as três interfaces de rede ATM, para os switches 8285 e 8271) e uma entidade LES/BUS. Esta última encontra-se configurada em um switch 8265, cujo endereço ATM é: 39.08.10.62.00.10.10.00.00.00.00.00.60.40.00.82.65.00.60.03. O protocolo de sinalização empregado é o PNNI, onde foi criado um único peer group, definido como default.

Para tornar viável a implementação de qualidade de serviço no sistema operacional Linux, tivemos que habilitar no Kernel (núcleo do sistema), recursos extras que não acompanham o sistema em modo nativo e, então, recompilá-lo. Com tais recursos, obtêm-se qualidade de serviço através da implementação de controle de tráfego, ou seja, classificação, escalonamento, policiamento e filtragem de pacotes. No sistema operacional Linux, o suporte à qualidade de serviço é chamado de Traffic Control [Almesberger99], ou simplesmente TC, constituindo-se basicamente de opções extras selecionadas na configuração do Kernel antes da sua compilação e uma ferramenta (também chamada tc) que estabelece regras para ativar e descrever o suporte ao controle de tráfego [Kuznetsov99].

O controle de tráfego funciona de forma passiva, ou seja, faz-se necessário a utilização de algum recurso que configure mecanismos que garantam os parâmetros de QoS requisitados pela aplicação. Este recurso deve ainda oferecer a possibilidade de troca de mensagens entre os hosts terminais de forma a sinalizar reservas de recursos de qualidade de serviço. Para tal fim, utilizamos o protocolo RSVP implementado como um daemon, o rsvpd [ISI98].

Por fim, era necessário o emprego de uma aplicação que gerasse o tráfego real ou modelado de Vídeo Sob Demanda e que tivesse a capacidade de fazer requisições que estabelecessem reservas de recursos junto ao protocolo RSVP. Para tal finalidade, foi utilizado o conjunto de ferramentas de modelagem, geração e análise de tráfego, MGEN (Multi-GENerator) [Adamson].

^

2.2 Validação da Proposta

Escolhemos o tráfego de vídeo sob demanda como o estudo de caso a ser empregado na infra-estrutura de rede de testes disponível. Utilizamos a ferramenta mgen, que oferece a capacidade de gerar tráfegos modelados dos mais diferentes tipos e funciona de forma satisfatória em equipamentos com hardware de baixo desempenho, além de ser capaz de fazer requisições de reserva junto ao daemon rsvpd. Além disso, uma outra ferramenta do conjunto MGEN, o drec, permite capturar e gravar os resultados obtidos.

Os testes iniciais objetivavam apenas obter a situação de stress da rede, resultado este, necessário à realização dos testes que se seguiram. A taxa efetiva obtida nesta situação totalizou 20.439Kbps. Observamos que apesar de nominalmente o adaptador de rede indicar a taxa de 25.000Kbps, a taxa útil não excedia o valor citado, devido às informações de controle dos diversos protocolos de comunicação envolvidos.

Baseado na informação anterior, pudemos deduzir que o tráfego de dados de uma aplicação sensível ao tempo, no caso, Vídeo Sob Demanda, seria viável. Assim, realizamos algumas seqüências de testes, onde um tráfego modelado de um stream de Vídeo Sob Demanda de 1.500Kbps foi transmitido e analisado sob diferentes condições, as quais serão descritas a seguir.

• Tráfego de Vídeo Sob Demanda dentro dos limites suportados pela rede (sem reserva de recursos)
  
  Inicialmente, realizamos testes com um único tráfego de 1.500Kbps sem reserva de recursos, onde observamos os valores dos seguintes parâmetros: pacotes descartados, atraso máximo e jitter. Os resultados obtidos (figuras 4, 5 e 6), foram satisfatórios, ou seja, tais parâmetros satisfaziam os limites impostos por uma aplicação de Vídeo sob Demanda com as características estabelecidas. Concluímos que em uma situação adequada (baixa ou nenhuma carga da rede), obtém-se um desempenho satisfatório para uma aplicação de tempo real.
  
  
• Tráfego de Vídeo Sob Demanda acima dos limites suportados pela rede (sem reserva de recursos)
  
  A próxima seqüência de testes realizada, objetivava a análise do comportamento da rede quando submetida ao tráfego de 1.500Kbps, utilizado no teste anterior, porém perturbado por um tráfego de 19.600Kbps. Ou seja, o computador assumindo o papel de receptor, era submetido a uma carga superior à taxa efetiva de saturação de 20.439Kbps. Isto seria um exemplo típico, onde um stream de vídeo sendo transmitido é perturbado por uma rajada (burst), comumente produzida por aplicações que fazem uso do serviço de Melhor Esforço. Vale lembrar que é importante que os dados trafegados pelo serviço de Melhor Esforço cheguem ao seu destino, porém estes não exigem controle de atraso ou jitter, diferentemente de uma aplicação de tempo real. Apesar de se ter disponível uma infra-estrutura de rede de alto desempenho, o uso limitado de suas características (não alocação de QoS), não garante o tráfego adequado de uma aplicação sensível ao tempo. Este fato pôde ser comprovado pelo não atendimento dos limites nos parâmetros pacotes descartados, atraso máximo e jitter, para o tráfego de 1.500Kbps (figuras 4, 5 e 6). Desta forma, concluímos que em uma situação de sobrecarga da rede obtém-se um desempenho inadequado (até mesmo inviável) para uma aplicação sensível ao tempo, no caso, Vídeo Sob Demanda. Assim, reforça-se a necessidade de termos reservas de recursos que garantam a qualidade de serviço adequada exigida por esse tipo de aplicação.
• Tráfego de Vídeo Sob Demanda acima dos limites suportados pela rede (com reserva de recursos)
  
  Uma solução à limitação validada na seqüência de testes anterior, seria a alocação nativa de QoS no ATM, o que, em termos de infra-estrutura, descartaria o uso do suite de protocolos IP. Como já ressaltado anteriormente não apoiamos esta abordagem, maiores detalhes sobre esta, estão além do escopo desse documento.
  
  Outra solução implicaria na utilização do protocolo de sinalização RSVP e no mapeamento deste diretamente para ATM, o qual acreditamos ser a solução com perspectivas mais promissoras. Porém, não foi possível a realização de testes do daemon RSVP interagindo diretamente com o ATM, o que ocorreu devido ao fato de não estar disponível até o momento, em domínio público, uma implementação deste.
  
  Por fim, a solução aplicada constitui-se na utilização do protocolo RSVP, para sinalização das reservas de recursos ao controle de tráfego, sendo este último implementado no kernel do sistema operacional Linux. Entretanto, a tecnologia de nível de enlace, acessada pelo RSVP/IP, foi a Ethernet emulada pelo ATM (LANE).
  
  Essa solução foi validada com a última seqüência de testes realizados, onde objetivamos a análise do comportamento da rede quando submetida ao tráfego de 1.500Kbps, com reservas de recursos e perturbado por um tráfego de 19.600Kbps. Nessa situação (figuras 4, 5 e 6) o que ocorreu foi uma reserva de recursos (dinâmica) para o tráfego da aplicação de Vídeo Sob Demanda, deixando o restante para a rajada de perturbação, que chegava ao seu destino, porém tendo que lidar com a restrição de recursos imposta.

Baseado nos resultados obtidos nas seqüências de testes anteriormente descritas, elaboramos os gráficos das figuras 4, 5 e 6, os quais exibem o comportamento dos valores relativos a pacotes descartados, atraso máximo e jitter para o tráfego de 1.500Kbps (stream de Vídeo Sob Demanda).

Para obtenção dos valores de cada parâmetro, geramos 10 testes consecutivos. Baseado nestes testes foram gerados arquivos de registro (logs) pela ferramenta drec, os quais serviram como entrada para a análise estatística da ferramenta mcalc (também pertencente ao conjunto MGEN). Os parâmetros analisados foram: pacotes descartados, atraso máximo e jitter. Obviamente, teve-se o cuidado de observar se os valores obtidos nos 10 testes, eram próximos e/ou convergentes.

• Teste 1: Fluxo de dados de 1.500Kbps, sem reserva de recurso e sem tráfego concorrente;
• Teste 2: Fluxo de dados de 1.500Kbps, sem reserva de recurso e com tráfego concorrente;
• Teste 3: Fluxo de dados de 1.500Kbps, com reserva de recurso e com tráfego concorrente.

Figura 4: Gráfico comparativo do número de Pacotes Descartados

Figura 5: Gráfico comparativo do Atraso Máximo

Figura 6: Gráfico comparativo do Jitter

Observando os gráficos gerados, pudemos constatar:

• A inviabilidade de se trafegar um stream de vídeo (1.500Kbps) em uma infra-estrutura de rede que não possibilita alocação de recursos de Qualidade de Serviço, quando esta é submetida a uma carga significativamente alta de tráfego (Teste 2).
• A manutenção, pela infra-estrutura, dos parâmetros de Qualidade de Serviço configurados para atender os requisitos da aplicação de Vídeo Sob Demanda em questão (stream de vídeo de 1.500Kbps), mesmo submetida a uma carga significativamente alta de tráfego (Teste 3).

A solução empregada no último teste gerado, demonstrou-se adequada ao problema do tráfego de aplicação de Vídeo Sob Demanda, conseguindo garantir os parâmetros estabelecidos dentro dos limites exigidos pela aplicação de tempo real em questão. Ou seja, o tráfego gerado com alocação de recursos foi garantido apesar da perturbação imposta. Assim, pôde-se validar a importância da alocação prévia de recursos que garantam o tráfego com qualidade de serviço, à aplicações de tempo real.

Apesar dos resultados positivos, temos ciência de que um número maior de testes faz-se necessário afim de melhorar a confiabilidade de nossas constatações.

^

3. Conclusões

A partir dos testes que realizamos, constatamos a importância de se ter uma infra-estrutura que ofereça possibilidade de realizar reservas de recursos para a implementação de Qualidade de Serviço. Além disso, observamos as vantagens obtidas a partir da reserva de recurso na camada de rede e da necessidade de um mapeamento adequado para a tecnologia de enlace empregada, sobretudo para ATM.

Com as seqüências de testes e a pesquisa bibliografia realizadas, inferimos que a proposta de se usar RSVP/IP sobre ATM é adequada e que testes futuros devem demonstrar essa situação. Algumas questões deverão surgir, tais como o gerenciamento da reserva de recursos no ATM (abertura e fechamento de VCs), ou mapeamento de parâmetros de reserva de recursos ou ainda o problema de escalabilidade, porém as vantagens obtidas deverão ser suficientes para justificar as pesquisas e investimentos futuros neste sentido. Nesse sentido, acreditamos também, que trabalhos futuros deverão envolver Serviços Diferenciados sobre ATM.

^

4. Referências

[Adamson] Adamson, Brian, Gallavan, Sean, et al., MGEN-3.2 User´s Guide, ftp://manimac.itd.nrl.navy.mil/ManiMac/Pub/MGEN.

[Almesberger99] Almesberger, Werner and Salim, Jamal H., Differentiated Services on Linux, Global Telecommunications Conference - Globecom´99, Dezembro de 1999.

[Blake98] Blake, S., Black, D. L., Carlson, M., Davies, E., Wang, Z. and Weiss, W., An Architecture for Differentiated Services. Internet RFC 2475; Dezembro de 1998.

[Braden94] Braden, R., Clark, D. D., and Shenker, S. Integrated Services in the Internet Architecture: an Overview. Internet RFC 1633; Junho de 1994.

[Braden97] Braden, B., Estrin, D., Herzog, S., and S. Jamin, Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. Internet RFC 2205; Setembro de 1997.

[CerfKahn74] Cerf, V., and R. Kahn, A Protocol for Packet Network Intercommunication, IEEE Trans on Comm., Vol. Com-22, No. 5, May 1974.

[Clark88] Clark, D., The Design Philosophy of the DARPA Internet Protocols, ACM SIGCOMM '88, August 1988.

[Heinanen99] Heinanen, J., Baker, F., Weiss, and W., Wroclawski, J., Assured Forwarding PHB Group. Internet RFC 2597; Junho de 1999.

[ISI98] ISI Team, http://www.ini.edu/div7/rsvp, Agosto de 1998.

[Jacobson99] Jacobson, V., Nichols, K., and Poduri, K. An Expedited Forwarding PHB. Internet RFC 2598; Junho de 1999.

[Kuo98] Kuo, Franklin F.; Effelsberg, Wolfgang and Garcia-Luna-Aceves, J.J.. Multimedia Communications - Protocolos and Aplications. New Jersey: Prentice Hall, 1998.

[Kuznetsov99] Kuznetsov, Alexey, IProute2 + TC (Traffic Control), ftp://ftp.inr.ac.ru/iprouting/, Outubro de 1999.

[Magalhães97] Magalhães, Maurício, Pinto, Alexandre de S., Figueiredo, Antonio, Serviços Integrados e RSVP sobre ATM, Departamento de Engenharia da Computação e Automação Industrial, Unicamp, Dezembro de 1997.

[Nichols98] Nichols, K., Blake, S., Baker, F., and Black, D., Derfinition of the Differentiated Services (DS Field) in the Ipv4 and Ipv6 Headers. Internet RFC 2474; Dezembro de 1998.

[Shenker97] Shenker, S., Partridge, C., Guerin, R., Specification of Guaranteed Quality of Service, Internet RFC 2212; Setembro de 1997.

[Xiao99] Xiao, Xipeng and Ni, Lionel M., Internet QoS: the Big Picture, Department of Computer Science, Michigan State University IEEE Network, vol 13, no. 2, pp. 1-13, March/April 1999.

[Wroclawski97] Wroclawski, J., Specification of the Controlled-Load Network Element Service, Internet RFC 2211; Setembro de 1997.

^

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