Este trabalho mostra um pouco da importância em se prover QoS para as novas aplicações que estão surgindo na Internet e propõem a arquitetura “DiffServ”. Apresenta-se um pouco do histórico da Internet e necessidades que surgem devido as novas aplicações. São apresentadas as arquiteturas “best effort”, “IntServ” com o intuito de compará-las com o “DiffServ”. Conceitos importantes para a arquitetura “DiffServ” tais como: PHB, campo DS, Condicionador de Tráfego, Classificador de Tráfego também são mostrados.

1 Introdução

A internet hoje oferece, via de regra, um único serviço, denominado “best-effort” (melhor esforço), para todo o tráfego independente dos seus requisitos. Neste modelo empregado, o tráfego é processado o mais rápido possível, porém sem nenhuma garantia de entrega ou dentro do atraso tolerado. Dentro do cenário de crescimento da Internet e das necessidades de uma infraestrutura confiável, principalmente requisitadas por “e-commerce” e serviços multimídia, a Qualidade de Serviço (QoS) passou a ser um requisito essencial para as novas aplicações. Muitas classes de serviço passarão a ser solicitadas para atender os diferentes requisitos das várias aplicações que fazem uso da mesma infraestrutura de rede. Neste contexto, o Internet Engineering Task Force (IETF) está considerando algumas arquiteturas que permitam a alocação de diferentes níveis de serviços para os diferentes usuários. Algumas empresas estão querendo classes de serviços que forneçam uma qualidade previsível na Internet. Estas empresas estão dispostas a pagar uma certa quantia para tornar seus serviços mais confiáveis e para dar aos seus usuários uma imagem positiva dos seus “Web sites”. Também há muitos usuários de rede dispostos a pagar por qualidade de serviço.

1.1 Aspectos Históricos

A força da Internet foi verdadeiramente percebida quando a “World Wide Web” (WWW) foi desenvolvida no começo da década de 90. O WWW e a linguagem de hipertextos HTML propiciaram um modo conveniente e muito intuitivo de distribuição e acesso à informação de qualquer ponto da Internet. Usuários comerciais, assim como os tipicamente residenciais, começaram a se conectar na Internet fazendo uso principalmente da aplicação WWW. Por volta de 1994, a Internet tinha mais de 45.000 redes conectadas e mais de 4.000.000 e “hosts”[1]. De acordo com o “Internet Software Consortium” (ISC), estima-se que em Janeiro de 2001 havia entorno de 109 milhões de “host” conectados usando a Internet em todo o mundo [2]. No Brasil, que está entre os dez países com maior número de “hosts” conectados, o número de “host” devia ser de 876 mil.

O sucesso da Internet trouxe basicamente duas questões. Por um lado, a arquitetura da Internet baseada no modelo TCP/IP é bastante robusta na sua expansão e na incorporação de novas redes e “hosts”. Por outro lado, alguns componentes da arquitetura atual da Internet não são mais adequados para o seu crescimento. De modo particular, pode-se mencionar três problemas.

Primeiramente, as novas aplicações que estão sendo desenvolvidas para rodar na Internet, muitas das quais são vídeo ou áudio em tempo-real, requerem da rede algum tipo de qualidade de serviço. A Internet atual usa o modelo de serviço “best effort”, no qual a rede aloca uma certa quantia de largura de banda para todos os usuários naquele momento da melhor forma possível que ela pode, não fazendo nenhuma garantia explícita nem de largura de banda nem de atraso. Os roteadores não mantém nenhum estado de conexão dos “end-hosts”, e quanto acontece congestionamento nos seus “buffers”, o roteador faz descarte de pacotes. Todas as conexões que estavam enviando pacotes devem diminuir suas taxas de transmissão e coletivamente enviar pacotes numa taxa igual à capacidade do ponto de congestionamento. Logo, do ponto de vista do usuário final, o serviço da rede não é sempre previsível, já que ele depende de como as múltiplas conexões simultâneas estão enviando pacotes.

Em Segundo lugar, a Internet transformou-se de um projeto fundamentalmente governamental (ambiente cooperativo) em uma rede comercial (ambiente competitivo) e com uma base de usuários heterogêneos. Num ambiente de rede heterogêneo e commercial, os usuários individuais tem expectativas diferentes quanto à utilização dos recursos da rede e, alguns estão dispostos a pagar para receber estes serviços diferenciados. Entretanto, a arquitetura atual da Internet não oferece serviços flexíveis para atender as expectativas destes usuários.

Em terceiro lugar, desde que a Internet é uma rede comercial, os “Internet Service Providers” (ISPs) querem recuperar os seus gastos e otimizar a sua infraestrutura de rede para poder expandir seu negócio. No projeto da Internet atual, nenhum mecanismo de cobrança pelo uso foi previsto, já que a rede foi concebida com fins de pesquisa e para o governo. [3]. Todavia, numa rede comercial, se não existirem mecanismos de cobrança adequados à forma de uso, a rede tenderá a ficar altamente utilizada e congestionada (qualquer semelhança com Internet gratuita não é mera coincidência).

Em outubro de 1996, 34 universidades americanas se uniram para formar o “General Committee of Work of the Internet2”. Em janeiro de 1997, mais de 100 universidades americanas já tinham assumido formalmente o compromisso de participar do projeto da Internet2. A Internet2 é uma iniciativa Norte Americana no sentido de retomar para a comunidade acadêmica e de pesquisa o desenvolvimento de tecnologias e aplicações avançadas nas redes Internet. [4]. Um dos objetivos que o projeto da Internet2 tem é prover uma infraestrutura de rede que permita suportar QoS e que atenda as novas aplicações que estão por vir.

Atualmente, a Internet2 contam com o apoio e participação de mais de 170 universidades trabalhando em parceria com centros de pesquisas, agencies do governo e membros dedicados da industria para desenvolver as novas tecnologias para a Internet de alto desempenho. [4]

As atividades de desenvolvimento da Internet2 são feitas em comitês conhecidos como “Working Groups”. “The mission of the Internet2 QoS Working Group is to support the development and deployment of advanced network applications through the use of IP traffic differentiation. The flagship project of the WG is the QBone-an effort to specify, deploy, and evaluate new IP services in an interdomain diffserv testbed.” [4]

Desde maio de 1995, as atividades relacionadas de administração e implementação da Internet no Brasil são de responsabilidade do “Brazilian Internet Steering Committee”. “The Steering Committee's main attributions are: to foment the development of INTERNET services in Brazil, to recommend patterns of technical and operational procedures for the INTERNET in Brazil, to coordinate the attribution of INTERNET addresses, the registration of domain names and backbone interconnections, to collect, organize and disseminate information on Internet services.” [5]

1.2 Visão Geral das Tecnologias

1.2.1 “Best Effort”

Neste modelo, uma aplicação envia dados quanto ela bem entender, da forma que ela quiser e sem pedir nenhuma permissão. O elemento de rede tenta fazer o melhor possível para entregar os pacotes para os seus destinos sem nenhuma preocupação com atraso, “jitter”, etc. Mas caso o elemento de rede não consiga realizar esta tarefa (por motives diversos), ele simplesmente desiste e não informa nem o “host” que está enviando o pacote nem o “host” que está recebendo. Então, o ônus disto tudo fica para o usuário final que precisa implementar mecanismos que assegurem que o pacote foi realmente entregue (através de “ACKnowledgement”). A atual rede IP é um exemplo de implementação que segue este tipo serviço.

1.2.2 “Integrated Services”

“Integrated Services” (IntServ) é um modelo de serviço que incluir ambos os serviços, ou seja, tradicional (“best effort”) e serviços de tempo real. Os estudos com “IntServ” começaram no começo da década de 90 e geraram muito interesse e discussões por volta de 1994[6]. As pesquisas com o “IntServ” abordaram o problema de como prover um suporte de rede que possibilitasse o funcionamento simultâneo de aplicações de tempo real e de não tempo real. Os pesquisadores observaram que muitas aplicações emergentes (multimídia, “teleconferencing”, “remote vídeo”, “computerbased telephony”, “remote visualization”, etc) tem requisitos de QoS muito diferentes dos requisitos de QoS das aplicações tradicionais de não tempo real (como WWW, Ftp e telnet).

Uma arquitetura de rede que provê serviços para as aplicações de tempo real pode ser implementada sem nenhum vínculo com a arquitetura Internet, prova disto é a rede de telefonia. Porém, isto obriga a ter duas redes separadas, uma oferecendo serviços de tempo real e outra provendo serviços de não tempo real; todavia, oferecer uma rede integrada com os dois tipos de serviços parece ser mais atrativo porque é mais barato construir uma só rede e é mais fácil também para o desenvolvimento de aplicações.

Os pesquisadores acreditam que o modelo “Integrated Service” pode:

· Manter estados de fluxo nos roteadores;

· Necessitar um mecanismo de pedido explícito para instalar e desinstalar um estado de fluxo no roteador.

A solução proposta é que o “host” do usuário faça inicialmente uma requisição de QoS antes de transmitir seu tráfego pelas redes. Esta requisição é transportada por um protocolo denominado de RSVP. Se as redes aceitam tal requisição, então ela criará “Estados por Fluxo” para garantir a QoS solicitada durante aquela transmissão. Se a rede não tem recursos suficientes, a requisição por QoS é rejeitada.

A proposta do “Integrated Service” fez um bom trabalho quando:

1) Analisa os requisitos das aplicações de tempo real;

2) Argumenta para se ter uma rede integrada que ofereça diferentes tipos de serviços ao invés de separar as redes cada uma implementando um modelo de serviço.

Entretanto, a implementação de uma rede “IntServ” tem uma série de problemas. É factível implementar e manter “Estados por Fluxo” em roteadores, especialmente aqueles que trabalham com grande número de tráfegos agregados? O protocolo RSVP é complexo e, portanto, é pouco realístico esperar que os roteadores empreguem muito recurso para interpretar as requisições RSVP e fazer controles de admissão para os estados estabelecidos.

Se houver roteadores no caminho que não entendam o RSVP e não possam fazer a reserva de recursos, então será impossível fazer qualquer garantia para os “hosts” fim-a-fim.[12]

1.2.3 Differentiated Services

“Differentiated Services” (Diffserv) se beneficiou do trabalho de pesquisa das duas arquiteturas propostas anteriormente. Esta arquitetura divide com o “IntServ” as mesmas metas para prover QoS às aplicações, porém oferecendo uma solução escalável. A idéia central é bastante simples. O “Diffserv” define um pequeno grupo de classes de pacotes e cria mecanismos na rede para tratar as diferentes classes de forma diferenciada durante congestionamento. Quando não há congestionamento, todos os pacotes são encaminhados através do modo usual. Os usuários contratam um “Service Level Agreements” (SLAs) dos seus respectivos provedores de serviço (ISPs). Cada SLA define o perfil de serviço que o usuário irá pagar e também espera receber do provedor. Este SLAs e os elementos de policiamento ficam somente nas bordas das redes, ou seja, a complexidade fica somente na borda. Os tráfegos dos usuários são classificados e mapeados em uma das poucas classes na borda da rede, e são despachados dentro do núcleo da rede conforme a classe a que pertencem. Os mecanismos no núcleo da rede permanecem simples, pois o roteador só precisa decidir como tratar o pacote baseando-se na classe a que ele pertence.

Os benefícios do “DiffServ” são: a possibilidade de estabelecimento de preços, cobrança e por fornecer a capacidade de expectativa de serviço. Esta proposta também define perfis de serviços, contratos entre os provedores e os usuários nos quais os clientes explicitam suas expectativas de serviço.

Desde 1996, “DiffServ” tem provocado um tremendo interesse dos pesquisadores. Os trabalhos iniciais com [10] focam na arquitetura e mecanismos. Trabalhos posteriores [11] focam nos diferentes tipos de serviços que podem ser suportados pela arquitetura “DiffServ” e na necessidade de mecanismos para prover tais tipos de serviços. As diferentes proposições são testemunhas que a arquitetura “DiffServ” é suficientemente flexível para suportar diferentes tipos de serviços.

2 Arquitetura de Serviços

Nesta seção, serão descritos de forma mais detalhada os três tipos de arquiteturas: “best effort”, “IntServ” e “Diffserv”. Isto será feito para elucidar que o “DiffServ” reúne a eficiência do “best effort” e o provisonamento de QoS do IntServ.

2.1 O Modelo de Serviço “Best Effort”

Do ponto de vista de topologia, a Internet atual pode ser modelada como uma conexão arbitrária de vários sistemas autônomos. Cada sistema autônomo representa uma entidade do mundo real como um provedor (ISP) ou uma universidade. Há basicamente duas estruturas de roteamento empregadas na Internet de hoje. Dentro do sistema autônomo, os roteadores trocam informações usando um protocolo de roteamento interno. Há uma métrica de roteamento consistente sendo utilizada por todos os roteadores dentro do sistema autônomo. Além disto, os sistemas autônomos trocam informações de roteamento entre si usando um protocolo de roteamento externo.

Dentro de cada sistema autônomo, há dois tipos de dispositivos: roteadores e “hosts”. Os roteadores trocam informações de roteamento um com o outro, multiplexam fluxos de pacotes IPs de diferentes links de entrada e encaminham-los para os seus roteadores vizinhos. Os roteadores provêem um mecanismo bastante simples e não confiável denominado de serviço “best effort”. Tal serviço é usualmente implementado com um mecanismo de enfileiramento chamado de “droptail”, no qual um roteador descarta todos os pacotes se a sua fila está cheia. Os “hosts” dos usuários finais implementam o protocolo TCP/IP, que provê a confiabilidade e o serviço de camada de transporte seqüencial para as aplicações.

A razão pela qual a Internet escolheu o modelo “best effort” pode ser rastreada das suas raízes, ou seja, de ser uma rede de pesquisa militar. A Internet foi concebida no final da década de 60 como uma extensão da ARPANET, um projeto de defesa fundado pela “Advanced Research Project Agency” (ARPA). A meta de projeto primária que guiou a Internet era sobrevivência em caso de falha [3 ]. Isto é, se duas entidades estão se comunicando pela Internet e alguma falha ocorre, indisponibilizando a Internet temporariamente, as duas entidades deveriam ainda ser capazes de comunicar-se sem ter que restabelecer suas conversações. Assim os “hosts” devem manter as informações de estados de conexão, de forma a atender o requisito anterior. Por outro lado, os roteadores precisam somente fazer a comutação dos pacotes e, portanto, não precisam manter estados de fluxo.

No modelo atual da Internet, o esquema de alocação de recursos da rede é fundamentado no controle de congestionamento nos roteadores e no “hosts”. Nos roteadores, há a fila “droptail” que descarta os pacotes quando o “buffer” está cheio. As perdas de pacotes na rede são detectadas pelo TCP nos “hosts” dos usuários e são interpretadas como sinal de congestionamento. O TCP diminui sua taxa de envio de dados quando detecta congestionamento. Esta atitude alivia o congestionamento da rede e o TCP no “host” começa a gradativamente aumentar sua taxa de envio de pacotes. A largura de banda que uma conexão TCP recebe da rede é dependente do estado de congestionamento da rede das rotas e de como as outras conexões simultâneas estão, o que na prática dá pouca presivibilidade. [14 ]

A Internet usa uma arquitetura simples que é caracterizada pelos seguintes atributos:

· Distinção entre dois tipos de dispositivos: roteadores e “host”. Os roteadores são dispositivos que atuam no nível de rede (camada IP) e entregam pacotes de forma colaborativa desde a fonte até o destino. Eles formam uma base consistente para entrega dos pacotes gerados nos “hosts”. Os “hosts” são dispositivos que operam no nível de transporte, recebendo e enviando pacotes IPs para os roteadores.

· Não há contrato de serviço explícito entre a rede e o usuário final. Os usuários finais (“hosts”) enviam seus tráfegos sem fazer um pedido explícito de conexão. Os roteadores usam um mecanismo simples para entrega dos pacotes IPs, no qual ele descarta pacotes se houver uma falha ou se ele estir congestionado. É responsabilidade do protocolo da camada de transporte nos “hosts” finais assegurar que o pacote chegue ao destino final. Portanto, não há nenhum compromisso explícito da rede com o “host” de que sera entregue e quando será entregue.

· Só um tipo de serviço é provido pela rede. No nível de rede, todos os pacotes são submetidos de acordo com um mesmo tipo de tratamento pela rede (encaminhados de acordo com o endereço IP de destino e descartados se os roteadores estiverem congestionados).

O modelo de serviço “best effort” é simples e permite uma grande multiplicação estatística, a qual leva a um uso eficiente dos recursos da rede. A dificuldade desta arquitetura é que, sem nenhum suporte explícito da rede, a provisão de qualquer tipo de serviço assegurado ou garantido no “host” final, torna-se muito difícil.

2.2 Integrated Services

O modelo “Integrated Services” é uma extensão da arquitetura original da Internet “best effort” [7]. Ele inclui dois serviços objetivados para as aplicações de tempo real: serviço garantido e serviço predito. Serviço garantido envolve os atrasos nas bordas pré-computados para o pior caso e o serviço predito usa as medidas de desempenho da rede no cálculo do atraso nas bordas.

Baseados nestas considerações, os pesquisadores acreditam que o modelo “Integrated Services” irá:

Manter adicionalmente estados de fluxo nos roteadores;
Requerer um mecanismo de “setup” para instalar e retirar estados de fluxo nos roteadores.

Para isto, em termos de implementações, uma estrutura “Integrated Services” tem quatros componentes: [15]

· “Packet Scheduler”

O “packet scheduler” administra o encaminhamento dos diferentes fluxos de pacotes usando um conjunto de filas ou talvez outros mecanismos como temporizadores.

· Classificadores

Quando um pacote chega num roteador, ele é primeiro classificado (Classificador), por exemplo, mapeado em alguma das classes. Pacotes na mesma classe recebem o mesmo tratamento pelo “packet scheduler”. As classificações são decididas por uma camada de policiamento e podem ser usadas para propósitos de cobrança.

· Controle de Admissão

O controle de admissão implementa um algoritmo de decisão que um roteador ou um “host” usa para determinar se um novo fluxo pode ter a garantia de QoS requisitada sem que isto impacte as garantias dos fluxos já anteriormente instalados. O controle de admissão é envolvido em cada roteador para tomar a decisão local de aceitação ou rejeição da solicitação de serviço.

· Protocolo de Reserva

Um protocolo de reserva é um protocolo de sinalização, que carrega as requisições de QoS do “host”, a fim de que os pacotes sejam roteados através de um caminho de roteamento que garanta QoS. As requisições de QoS são necessárias para criar e manter estados de fluxo específicos ao longo do caminho do fluxo de pacotes. Com este objetivo, Zhang, Deering, Estrin and Shenker in [9] propuseram um protocolo de “setup” denominado de RSVP. RSVP is um protocolo de reserva que pode acomodar as necessidades de tráfego “unicast” e “multicast”. A idéia geral é que o RSVP carregue as requisições de QoS - uma lista de parâmetros denominada de especificação de fluxo (“flowspec”) [8] - ao longo do caminho reservado para o fluxo de dados, e faça as reservas de recursos em cada roteador. Se qualquer roteador não tiver recursos suficientes para aceitar tal requisição, seu modulo de controle de admissão rejeita a requisição, e a rejeição é carregada pelo RSVP de volta ao “host” inicial. Se todos os roteadores ao longo do caminho aceitarem a especificação de fluxo, então o RSVP deverá manter e atualizar o estado de QoS estabelecidos pelos roteadores. O estado mantido nos roteadores é “soft state”; isto é, ele expira se não for atualizado por requisições RSVP periódicas. Isto fornece suporte para um relacionamento dinâmico e para adaptações automáticas para mudanças de roteamento.

Sob o ponto de vista de arquitetura, o “IntServ” é parecido com o modelo “best effort” no qual há dois tipos de equipamentos: roteadores e “hosts”. Entretanto, no “IntServ”, os roteadores são muito mais complexos. Eles têm que implementar um protocolo de reserva de recurso para estabelecer estados de QoS e manter mecanismos para manter, remover ou atualizar os estados de QoS. Os atributos da arquitetura “IntServ” são mostrados a seguir: [16]

· Distinção entre dois tipos de dispositivos roteadores e “hosts”. Semelhante ao modelo “best effort”, os roteadores atuam no nível de rede (IP) trocando informações de roteamento e entregando, de forma colaborativa, pacotes da origem para o seu destino. Os roteadores formam uma base consistente para entrega de pacotes gerados nos “hosts”. Além disto, eles precisam implementar protocolos para estabelecimento, remoção e atualização dos estados de QoS requisitados pelos “hosts”. Os “host” são dispositivos que operam no nível de transporte(TCP or UDP) gerando e recebendo pacotes IP para o roteador entregar, tal como ocorre no modelo “best effort”. Adicionalmente, eles iniciam os protocolos RSVP para estabelecimento dos estados de QoS.

· Contratos explícitos de serviços entre a rede e o “host” são estabelecidos, de modo a acordar o que um tem que fornecer e o que o outro espera receber. Para que possam receber determinada QoS, o “hosts” tem que especificar explicitamente nas suas requisições (requisições de QoS) para rede, os parâmetros de qualidade de serviço que eles esperam receber. O tráfego gerado pelos “hosts” é explicitamente verificado e policiado pela rede, de modo a evitar tráfego oportunista (contrata QoS nível bronze e tenta usar tipo ouro) e degradação da QoS dos fluxos já admitidos.

· Ótima granularidade dos níveis por fluxo de serviços numa base de rede consistente. Dentro da rede, os pacotes que pertencem a fluxos que tem especificações de QoS e foram admitidos pela rede, recebem o tratamento de QoS de todos os roteadores no caminho de roteamento. Como as requisições de QoS dos “hosts” possuem ótima granularidade, os serviços providos pela rede “IntServ” também terão ótima granularidade.

É claro que se os mecanismos “IntServ” puderem ser implementados na rede, então a rede poderá suportar requisições explícitas de QoS feitas pelos “hosts”. Contudo, esta facilidade particular vem a um custo de perder um pouco da eficiência da rede. Reservas explícitas por fluxo significa que há menos ou nenhuma multiplexação estatística dos recursos da rede ao longo dos fluxos que requisitaram uma QoS explícita. Desde que a multiplexação estatística é o que faz do “best effort” um modelo de serviço eficiente, a proposição do “IntServ” reduz a eficiência da rede.

Uma outra séria preocupação diz respeito quanto à complexidade envolvida no estabelecimento, manutenção e remoção dos estados de QoS por granularidade de fluxo no “IntServ”. Este modelo tem sido criticado por alguns pesquisadores da área como sendo uma encarnação na Internet da arquitetura tradicional de QoS baseada em circuitos, ou seja, o tradicional modelo empregado na telefonia.

2.3 Serviços Diferenciados (Differentiated Services)

Os serviços diferenciados (“DiffServ”) tenta combinar os benefícios dos modelos “best effort” e “IntServ”. A meta primária é preservar a natureza da multiplexação estatística da Internet atual, enquanto que, usa mecanismos escaláveis e flexíveis para prover uma ampla gama de serviços com QoS. Um segundo objetivo do “DiffServ” é tornar possível cobrança pelo uso dos recursos da rede [16] .

A idéia geral da arquitetura “DiffServ” é marcar os pacotes dentro de um pequeno número de classes na borda da rede e criar mecanismos dentro da rede que tratem de modo diferenciado as diferentes classes de pacotes. Cada usuário é associado com um “Service Level Agreement” (SLA), que é um contrato entre um cliente e um provedor de serviços de Internet (ISP), onde é especificado o serviço de envio de pacotes que o cliente espera poder receber. Um SLA também especifica um perfil de qual tipo de tráfego o cliente irá ter. O SLA é pago pelo cliente com a condição do ISP fornecer o serviço de despacho de pacotes para o tráfego dentro do perfil. Todo o tráfego que está for a do perfil contratado é considerado oportunista e não tem nenhum tipo de garantia de serviço.

Na borda da rede, os roteadores de borda do ISP classificam os pacotes e fazem o mapeamento do tráfego nos seus respectivos SLAs. O tráfego enviado dentro do perfil estabelecido no SLA é marcado pelo roteador de borda em uma das diferentes classes de pacotes. O tráfego enviado fora do perfil estabelecido no SLA é deixado sem marcação e é considerado com tráfego oportunista. Aqui, ilustra-se a idéia de diferentes classes de pacotes com somente dois tipos de pacotes: pacotes IN e pacotes OUT. Pacotes IN representam os pacotes dentro do perfil e os pacotes OUT representam os pacotes que excedem o perfil contratado. O roteador de borda marca os pacotes com sendo pacotes IN se o tráfego esta dentro do SLA do cliente; tudo que excede o SLA é marcado como pacote OUT. Dentro da rede (“core”), os roteadores somente precisam distinguir entre dois tipos de pacotes e dar preferência para tratamento dos pacotes IN em termos de largura de banda ou atraso ou ambos.

No “DiffServ”, somente os roteadores de borda precisam manter os “Estados por Fluxo”. Os roteadores do núcleo da rede não precisam manter nenhum “Estado por Fluxo” como ocorre do “IntServ”, já que a filosofia aqui é tratar os pacotes no “core” da rede somente pela classe a que ele pertence. Deste modo, a complexidade do sistema é levada para as bordas da rede. A manutenção de “Estados por Fluxo” somente nos roteadores de borda faz do “DiffServ” uma arquitetura mais escalável do que o “IntServ”. Além disto, o SLA serve como uma base para o ISP cobrar pelo uso dos recursos da rede.

A Figura 1mostra a rede “Differentiated Services” com dois domínios “DiffServ”. Os roteadores centrais adotam mecanismos simples nos seus caminhos de despachos de pacotes e dão tratamento diferenciado para as diferentes classes de pacotes. Os roteadores de borda empregam mecanismos - denominados de “Condicionadores de Tráfego” - que classificam, monitoram e marcam os pacotes. Finalmente, o “DiffServ” também pode requerer mecanismos simples a serem empregados nos “hosts” finais a fim de se obter uma precisa alocação de recursos.

Figura 1 – Elementos chaves da arquitetura “DiffServ”

Uma conexão que passa por muitos domínios “DiffServ” de pequena dimensão irá passar por muitos roteadores de borda; seus pacotes serão marcados e remarcados nos roteadores de borda de cada domínio. Por exemplo, na Figura 1, uma conexão do “host 1” (H1) para o “host 2” (H2) passa por dois domínios “DiffServ” adjacentes. Os pacotes são primeiramente marcados no roteador de borda (ER1) do domínio 1. A marcação é feita de acordo com o SLA entre o cliente (H1) e o domínio 1. Quando os pacotes deixam o domínio 1 e entram no domínio 2, o roteador de borda (ER2) marcá-los novamente. Desta vez, os pacotes, juntamente com os pacotes das outras conexões que saem do domínio 1 para o domínio 2, são marcadas de acordo com o SLA entre o domínio 1 e domínio 2. Em outras palavras, o roteador de borda (ER2) marca o tráfego agregado, já que o domínio 2 não mantém SLAs individuáveis para cada conexão.

Comparando-se a arquitetura “DiffServ” simultaneamente com a “best effort” e “IntServ”, os seguintes atributos podem ser dados ao “DiffServ” [16 ]

· Distinção entre roteadores de borda, roteadores interiores e “hosts”. A arquitetura “DiffServ” faz distinção entre “hosts”, que implementam protocolo da camada de transporte, e roteadores, que implementam protocolo da camada de rede, tal como é feito pelo “best effort”. Além disto, é também há a distinção entre dois tipos de roteadores: roteadores de borda e roteadores interiores. Os roteadores de borda mantém informações de estado dos SLAs, classificam pacotes, marcam os pacotes em uma das diferentes classes e fazem o policiamento da chegada dos pacotes de acordo com os perfis de serviço. Os roteadores interiores não precisam manter estados por fluxo, eles somente precisam fazer uma certa distinção com relação as diferentes classes e dar o tratamento preferencial para as diferentes classes de pacotes.

· Contratos explícitos a rede e os “hosts”. O serviço que a rede provê para os “hosts” está descrito num SLA. Um SLA descreve as especificações de tráfego de um “host” para a rede. O tráfego de um “host” pode exceder o especificado no SLA desde que ele não congestione a rede. Se a rede for congestionada, espera-se que o “host” reduza seu tráfego para aquele especificado no seu perfil. A diferença entre um SLA e um “flowspec” do “IntServ” é que o primeiro é um perfil de serviço esperado enquanto que o outro é uma descrição exata de uma especificação de tráfego que por sua vez corresponde a uma requisição de QoS explícita.

· Poucos níveis de serviços diferenciados por meio de uma base consistente de roteadores interiores. Na arquitetura “DiffServ”, uma vez que os pacotes estão no núcleo da rede, eles são tratados como um tráfego agregado. Os roteadores interiores fazem distinção entre poucas classes de pacotes examinando o campo “Type of Services” (TOS) dos cabeçalhos IP (IPV4) e tratam de modo diferenciado as diferentes classes de pacotes. Os roteadores interiores formam um base de rede que fornece um tratamento consistente dos pacotes das diferentes classes. Os pacotes dentro da rede são agregados, desfrutando de um alto grau de multiplexação estatística, tal como acontece no modelo “best effort”. Esta característica de projeto preserva a eficiência da rede que vem da multiplexação estatística[16][14].

· A arquitetura “DiffServ” espera prover uma variedade de serviços em termos de requisitos de largura de banda e atraso, atendendo as necessidades dos vários tipos de serviços que os “hosts” necessitam. Isto tudo com a possibilidade de realização tanto para o tráfego agregado quanto para o tráfego por fluxo. A existência dos condicionadores de tráfego da borda da rede é quem garante esta característica.

Do ponto de vista de arquitetura, o “DiffServ” combina o melhor dos dois mundos: um alto grau de agregação do modelo “besteffort” e a garantia de QoS do “IntServ”. Os roteadores de fronteira mantêm estados por fluxo, monitoram e marcam o tráfego usando condicionadores de tráfego. Os roteadores interiores ainda são “stateless”, como na Internet atual. Esta solução é mais escalável em termos de mecanismos do que o “IntServ”.

Assim como o “IntServ”, o “DiffServ” utiliza a vantagem das mesmas observações que muitas aplicações de tempo real são adaptativas e não requerem garantias estritas da rede. Contudo, ele difere do “IntServ” em muitas coisas. Ao invés de tentar suportar muitos níveis ótimos de especificações de QoS na rede propriamente, o “DiffServ” somente suporta os níveis de especificações na fronteira da rede, onde ele mapeia as especificações de QoS para poucas classes de pacotes.

No interior da rede, o “DiffServ” trata as diferentes classes de pacotes de forma diferenciada. Esta premissa de projeto simplifica o projeto do interior da rede e torna os mecanismos escaláveis.

O “DiffServ” separa os serviços implementáveis dos mecanismos implementados atualmente. O “DiffServ” tem como objetivo suportar muitos serviços diferentes e flexíveis, quer sejam serviços de ótima granularidade, tráfego por fluxo ou tráfego agregado, e quer sejam baseado no fluxo de envio ou fluxo de recepção. Em termos das implementações atuais, entretanto, estes serviços podem ser suportados por um ou vários conjuntos de mecanismos integrados. Por exemplo, pode haver diferentes modos de fornecer níveis diferenciados de largura de banda para as aplicações e cada modo propõe um conjunto de mecanismos integrados para implementação. Do ponto de vista dos ISPs, isto prove um número de implementações alternativas para escolher. Na perspectiva do usuário, as aplicações podem rodar transparentemente no topo dos mecanismos diferenciados tanto quanto os mecanismos podem atender o que está especificado no seu perfil.

3 Diffserv

3.1 Conceitos Importantes

3.1.1 Perfil de Tráfego

Um perfil de tráfego especifica as propriedades temporais de um fluxo de tráfego. Ele provê regras para se determinar se um pacote em particular está dentro ou fora de perfil. Por exemplo, o método de policiamento “token-bucket” (Figura 2) pode ser usado para considerar o pacote dentro ou fora de perfil.

Figura 2 – Método “token-bucket” para avaliação de tráfego.

No método “token-bucket” são especificados a taxa e o tamanho de “burst” admitidos. Para entender seu funcionamento, considere um balde com fichas dentro. Suponha que cada ficha representa a chegada de 100kbits em 1s. Se o balde tiver 10 fichas, isto representa que se houver um tráfego de 1Mbits em 1s, ele será considerado dentro do perfil. Por outro lado se em 1s chegar 1.2Mbits, 1Mbit será considerado dentro do perfil e 200kbits serão considerados fora de perfil. Com está forma de medição de perfil, “burst” de tráfego são tolerados e especificados no perfil contratado. O tráfego fora do perfil pode ser moldado (enfileirado até ficar de acordo com o perfil), descartado por ser considerado tráfego oportunista (policiado), ser remarcado como um novo “codepoint” (conforme a Figura 2) ou ainda ser encaminhado normalmente porém com uma cobrança adicional (multa por exceder o perfil).

Cabe-se ressaltar que um perfil de tráfego é um componente opcional do acordo de condicionamento de tráfego e o seu uso depende das especificações de serviço oferecido ou política de provisionamento de serviço.

3.1.2 Per Hop Behavior (PHB)

No caso do “Diffserv”, a qualidade de transmissão é descrita pela forma como um pacote é despachado de um “hop” para outro “hop” numa conexão (Figura 3).

Os recursos dentro dos nós e nos links de transmissão são limitados. Uma distinção entre várias qualidades de serviço pode, por exemplo, ser feita por um certo grupo de conexões que sempre tem um certo percentual de recursos (exemplo um percentual do “buffer”). Neste caso, a chance de um pacote que chega poder ser armazenado num “buffer” aumenta e a probabilidade de perda diminui.

Tal mecanismo implementado de “hop” por “hop” (em cada roteador) é denominado de “Per Hop Behavior”. Se tal comportamento é determinado para cada roteador de uma conexão, isto faz com que a qualidade de serviço de uma conexão ponto a ponto seja afetada.

Figura 3 - Per hop behaviors

3.1.3 Behavior Aggregate

O “Diffserv” permite que muitas conexões diferentes, com os mesmos requisitos de qualidade de serviço, sejam combinadas tal como na Figura 4. Esta combinação de fluxos de tráfego com mesmas características são denominadas de “behavior aggregate”.

Este conceito é um pré-requisito importante para manter o “Diffserv” como uma solução escalável. Mesmo se o número de conexões aumentar de modo que a rede cresça em tamanho, isto não terá nenhuma influência na quantidade do “Per Hop Behavior” e não significará nenhuma carga adicional para os roteadores envolvidos.

Figura 4 - Behavior aggregate

3.2 A Arquitetura do Diffserv

O “Diffserv” inclui um grupo de funções que são incorporadas dentro dos roteadores de uma rede. Estas funções incluem:

· Comportamentos por “hop” definidos: “Diffserv” define um número de PHBs relativamente pequenos.

· Classificação do Tráfego: para possibilitar que os pacotes sejam atribuídos aos PHBs particulares, o tráfego precisa ser classificado de acordo.

· Condicionamento de tráfego: depois da classificação com sucesso, o modo que os pacotes de uma classe devem ser subseqüentemente manuseados precisa ser estabelecido em detalhes. Esta é uma tarefa do condicionador de tráfego. O condicionamento de tráfego define funções com as quais: um fluxo de pacotes pode ser monitorado (medido), o código “Diffserv” pode ser alterado (marcado) e finalmente funções que possam manipular o fluxo de tráfego de forma que ele tenha o comportamento desejado ou permitido (“shaping” / “dropping”).

A característica distingue a arquitetura “Diffserv” é que as funções complicadas como Condicionamento e Classificação do Tráfego (Figura 5) não precisam estar disponíveis em todos os nós da rede. Como uma regra geral, estas funções estão na fronteira de uma subseção denominada de domínio “DiffServ” (DS domain).

Para encaminhar um pacote no interior da rede, o nó precisa somente suportar um conjunto particular de PHBs pré-definidos. Em particular, nenhuma informação a respeito das conexões individuais precisa ser manipulada no interior da rede.

Figura 5 - Functional components of Diffserv

3.2.1 O Domínio de Serviços Diferenciados

Um domínio “DiffServ” é um conjunto contíguo de nós DS que operam com política de provisionamento de serviço e conjunto de grupos PHBs em comum, isto sendo feito em todos os nós do domínio[18].Um domínio de serviços diferenciados (“DS domain”) é um grupo de roteadores que tem as seguintes características:

· PHBs idênticos são suportados em cada roteador do domínio DS.

· Externamente, o domínio DS tem os contornos claramente definidos. Nestes contornos, os nós de fronteira asseguram que o fluxo de tráfego dentro do domínio está classificado e possivelmente adaptado (Classificação de Tráfego e Condicionamento de Tráfego) ver Figura 6.

· Dentro do domínio, o encaminhamento de pacotes e a seleção de um PHB somente são feitos baseando-se no valor presente no campo DS. Os valores do DSCP são mapeados para um dos PHBs suportados.

A inclusão no domínio DS de nós não compatíveis pode resultar em performance imprevisível e pode impedir a satisfação dos SLAs[18].

Um domínio DS normalmente consiste de um ou mais redes sob mesma administração. A administração do domínio é responsável por assegurar que recursos adequados são provisionados e/ou reservados para dar suporte aos SLAs oferecidos pelo domínio[18].

Figura 6 - The Diffserv domain

3.2.1.1 Nós de Fronteira e Nós Interiores no Domínio “DiffServ”

Um domínio DS consiste de nós de fronteira (borda) e nós interiores. Os nós de fronteira interconectam o domínio DS como outros domínios (DS ou não). Já os nós interiores somente conectam-se com outros nós DS interiores ou com nós de fronteira.

Ambos os nós devem ser capazes de aplicar o PHB apropriado aos pacotes, baseando-se no DS “codepoint”, caso contrário não se tem uma garantia de comportamento previsível. Além disto, aos roteadores de fronteira pode ser solicitado realização de funções de condicionamento de tráfego. Roteadores interiores podem também ser capazes de realizar funções limitadas de condicionamento de tráfego (exemplo remarcação) [18].

3.2.1.2 Nós “DiffServ” de Ingresso e Egresso

Os nós DS de fronteira atual simultaneamente como nó de ingresso e de egresso para as diferentes direções do tráfego. Os nós de ingresso são responsáveis por garantir que o tráfego entre no domínio DS conforme qualquer acordo de condicionamento de tráfego entre ele e outros domínio aos quais ele está conectado [18].

3.2.2 Região “DiffServ”

Uma região “DiffServ” é um conjunto contíguo de um ou mais domínios DS. As regiões DS são capazes de suportar serviços diferenciados ao longo de caminhos que atravessam os domínios que estão dentro da região DS.

Os domínios DS e uma região DS podem suportar internamente diferentes grupos de PHBs e diferentes mapeamentos de “codepoint” para PHB. Contudo, para permitir que os serviços que momentaneamente cruzam os domínios, os domínios DS pares devem cada um estabelecer um SLA par o qual define (explicitamente ou implicitamente) um acordo de condicionamento de tráfego. O acordo de condicionamento de tráfego, por sua vez, especificará como a transição do tráfego de um domínio DS para outro é condicionada na borda entre os dois domínios DS.

É possível que muitos domínios DS dentro de uma região DS possam adotar política de provisionamento de serviço comuns e também possam suportar conjuntos de grupos de PHBs e mapeamento de “codepoint” comuns. Com isto, a necessidade de condicionamento de tráfego entre os domínios DS é eliminada [18].

3.2.3 Classificação e Condicionamento de Tráfego

Antes de um cliente poder experimentar um serviço de alta qualidade, é necessário entrar em contato com um provedor de serviço e definir as características do seu serviço. Além da qualidade de serviço, um “Service Level Agreement” também pode incluir um “traffic profile” no qual são definidos, por exemplo, a taxa máxima permitida e o tamanho do “burst”. A qualidade é assegurada somente se o cliente respeita este acordo. O acordo então firmado será implementado posteriormente no condicionador de tráfego [18].

Um nó de fronteira do domínio “DiffServ” tem duas opções para classificação de um pacote entrante:

· Uma opção é somente avaliar as informações existentes no campo DS. Esta opção é por classificadores do tipo “Behavior Aggregate”.

· Uma outra opção é analisar uma combinação de vários campos do cabeçalho IP para efetuar a classificação, por exemplo: endereço IP de origem, IP de destino, números particulares de portas, etc. Classificadores que analisam vários campos do pacote IP são denominados de classificadores “Multi-Field”.

A classificação é usada para selecionar um processo de condicionamento de tráfego particular. Isto determina a maneira pela qual o pacote deverá ser subseqüentemente manuseado. A política de classificação de pacote identifica o subconjunto de tráfego que pode receber um serviço diferenciado sendo condicionado e/ou mapeado para um ou mais BHs (através da remarcação de “codepoint”) dentro do domínio DS [18].

O condicionamento do tráfego inclui as funções de medição, marcação, moldagem e descarte conforme mostrado no fluxo da Figura 7.

· Medição

Uma vez que o pacote tenha sido classificado, por exemplo poderá ser feita uma verificação se ele está de acordo com um perfil de tráfego particular ou se ele é um potencial violador do acordo estabelecido. Entretanto, é também possível somente efetuar medidas para propósitos estatísticos. Quebra do contrato de tráfego pode resultar que o pacote seja identificado de como não conforme e subseqüentemente seja marcado como um pacote fora de perfil.

· Marcação

No processo de marcação, uma nova entrada também é escrita dentro do campo DS ou uma entrada já existente é alterada. A entrada do campo DS é usada para apurar o tipo de PHB (Per Hop Behavior) durante as transmissões mais adiante e, portanto, é usada para prover a qualidade de serviço corrente. Neste ponto, o resultado da medição pode ser levado em consideração. Se um pacote viola o contrato de tráfego, isto pode ser sinalizado numa entrada apropriada do campo DS. Isto poderá resultar mais tarde num descarte preferencial deste pacote.

· Moldagem e Descarte

Se houver uma violação do perfil de tráfego acordado nos passos anteriores, duas coisas que podem ser feitas. A opção mais simples é simplesmente descartar os pacotes afetados. A segunda opção é armazenar os pacotes temporariamente e não encaminhá-los até que estejam de acordo com o perfil de tráfego acordado. Este último processo é denominado de moldagem do fluxo de tráfego.

Figura 7- Packet classifier and traffic conditioner

Como já mencionado, estas funções são de forma geral somente implementadas nos roteadores que representam a fronteira entre o domínio “DiffServ” com o mundo externo.

Uma vez que um pacote efetuou a transição para dentro de um domínio “DiffServ” como descrito acima, ele é encaminhado (salto a salto) conforme o PHB correspondente, que é determinado pela marcação feita no campo DS.

3.2.4 O campo DS

O resultado da Classificação e Condicionamento do Tráfego é mantido no campo DS, o qual por sua vez descreve o tipo de classe de serviço. O resultado da classificação é gravado através de um valor particular, o DS “codepoint”.

No caso de pacotes Ipv4 (Figura 8), o campo DS é composto pelos 6 primeiros bits do byte TOS. Já para o IPv6, os 6 primeiros bits do byte “Traffic Class” são usados.

O valor do campo DS é avaliado em cada roteador da rede “Diffserv”. Em cada roteador, uma decisão é tomada baseando-se tanto no valor do campo DS como no PHB com o qual o pacote deve ser encaminhado, mesmo se os roteadores de uma área somente suportam um pequeno número de PHBs.

Figura 8 - The DS field in an Ipv4 header

A estrutura do octeto TOS é mostrada abaixo (IPv4):

0	1	2	3	4	5	6	7
Precedence			TOS				MBZ

MBZ field: Must Be Zero, a bit mais à direita do octeto TOS.

A estrutura a seguir mostra o campo DS para o IPv6:

0	1	2	3	4	5	6	7
DSCP						Currently Unused

DSCP: Differentiated Service Code Point, os 6 bits mais à esquerda do campo DS.

3.2.5 Tipos de “Per Hop Behaviors”

Dois diferentes PHBs são atualmente definidos no “Diffserv”: o “Assured Forwarding”[19] e “Expedited Forwarding”[20].

3.2.5.1 Assured Forwarding

A categoria “Assured Forwarding” possibilita um operador de rede oferecer aos seus clients várias grades de serviços para encaminhamento de pacotes. Quatro diferentes classes são atualmente definidas [17] (ver Figura 9).

Figura 9 - O “assured forwarding” PHB

Para cada recurso da classe, por exemplo, existem quarto “buffers” de armazenagem e largura de banda reservada em todos os nós individuais de uma rede, sendo que uma maior parte dos recursos é disponibilizada para as classes com uma maior grade de serviço.

Dentro de classes individuais, os pacotes são subdivididos novamente. Se pacotes precisam ser descartados, a prioridade que um pacote pode ser descartado pode ser determinada em três diferentes níveis. Estes níveis são denominados de Níveis de Precedência de Descarte.

Os níveis de precedência de descarte são uma medida da importância relativa de um pacote dentro de uma classe em caso de congestionamento. Um nó do “DiffServ” congestionado tenta proteger os pacotes com um valor de precedência de descarte baixo de serem descartados. Isto é feito descartando preferencialmente os pacotes que possuem valor de precedência de descarte alto.

A garantia de encaminhamento do “Assured Forwarding” depende de muitas condições iniciais [17].

· Primeiramente, a probabilidade de encaminhamento é dependente da quantidade de recursos que foram alocadas para uma classe particular.

· Em Segundo lugar, a probabilidade de encaminhamento depende da quantidade de tráfego que está sendo transmitida naquele momento em uma classe particular.

· Se os gargalos de recurso surgem dentro de uma classe, a probabilidade de encaminhamento para um pacote depende do nível de precedência de descarte que lhe foi atribuído.

Pode-se concluir do exposto anteriormente que as garantia fornecidas pelo “Assured Forwarding” são relativamente melhores do que garantias absolutas. Uma classe pode ser tratada preferencialmente em relação a uma outra mas igualmente o “status” de carga atual também contribui para a grade de serviços.

A qualidade de serviço é altamente dependente das regras que são implementadas nos roteadores de contorno do domínio DS. Pela pré-definição e monitoramento dos correspondentes perfis de tráfego, é possível assegurar que a carga dentro de classes individuais permanece restrita. Precisa ser assegurado que os recursos disponíveis são adequados pelo menos na media num longo prazo.

Se os recursos não são adequados num longo prazo, a rede não tem outra opção senão descartar pacotes. Gargalos temporários podem ser facilmente contornados através de armazenamento dos pacotes em “buffers” e posterior encaminhamento mais tarde (moldagem). Em ambas as instâncias, os pacotes podem primeiro ser verificados como se eles ainda estivessem dentro do perfil de tráfego acertado. Se eles não caem dentro deste perfio, eles podem ter seu nível de precedência de descarte posicionado num valor alto e, portanto, serão preferencialmente descartados.

3.2.5.1.1 Uso do “Assured Forwarding”

O “Assured Forwarding” poderia por exemplo ser usado para introduzir um modelo de serviço olímpico (Figura 10), que seria constituído por três classes de serviço: “gold”, “silver” e “bronze”.

Figura 10 - Gold, silver, bronze – ou como o “assured forwarding” poderia ser vendido para o cliente.

“Gold”, “silver” e “bronze” são realizados por meio de três diferentes classes AF. A classe Gold é naturalmente aquela que tem a maioria dos recursos atribuídos (relativo a carga prevista).

Dentro das classes individuais, como descrito previamente, diferentes probabilidades de descarte podem então ser definidas através do nível de precedência de descarte.

Um serviço da classe definida com “Gold” poderia primeiramente ser caracterizado por uma alta probabilidade dos pacotes serm despachados e não descartados. A rede poderia também ser tolerante com respeito a pequenos períodos de picos de carga, já que uma maior capacidade de “buffer” é reservada para esta classe.

Todavia, é também claro que “Assured Forwarding” é somente apropriado para uma faixa limitada de serviços de tempo real. O PHB definido a seguir (“Expedited Forwarding) é mais apropriado para as aplicações de tempo real que tem requisitos mais apurados”.

3.2.5.2 “Expedited Forwarding”

O “Expedited Forwarding” é definido como um tratamento de despacho de pacotes para um particular agregado “DiffServ” onde a taxa de partida dos pacotes agregados em qualquer nó “DiffServ” deva ser igual ou maior do que a taxa de chegada [20]. O “Expedited Forwarding” descreve um PHB que pode ser usado para suportar serviços que esperam poucos atrasos e poucas variações de atraso durante o encaminhamento de pacote. Um requisito adicional é que a probabilidade de perda de pacote também seja pequena.

Conexões com as características anteriormente mencionadas são também chamadas de “virtual wires”. As conexões ponto a ponto com qualidade similar as tradicionais linhas privativas devem também ser disponibilizadas via Internet. Este é um mercado que a tecnologia Internet não deve e não pode desprezar, logo a arquitetura “DiffServ” prevê um modo de oferecer tal serviço através do “ Expedited Forwarding”.

A principal causa do atraso e da variação do atraso (“jitter”) são os “buffers”. Pareceria então óbvio reduzir os tamanhos dos “buffers”. Contudo, isto é uma discrepância com relação ao requisito de baixa perda de pacotes se medidas adicionais não são tomadas [13].

· Adequação da Largura de Banda nos roteadores

Para manter baixa perda de pacotes e também baixos tamanhos de “buffers, uma largura de banda adequada precisa ser reservada para o transporte subseqüente dos pacotes entrantes. A largura de banda reservada não deve ser dependente do “status” de carga das outras conexões. Esta requisição precisa ser implementada em cada roteador.

· Condicionamento de Tráfego

Nas bardas da rede, precisa ser assegurado que somente o tanto de tráfego que pode ser manuseado pelos recursos disponíveis da rede são aceitos pela rede. As taxas de transmissão precisam ser fixadas através de acordos contratuais (“Service Level Agreements”) de tal modo que os recursos disponíveis sejam adequados. Precisa ser garantido, por meio de um policiamento rigoroso e descarte de pacotes não conformes que transgridam estes acordos, de modo a evitar com que clients individuais afetem os outros clientes.

4 Conclusão

A arquitetura “DiffServ” apresenta uma proposta que busca conciliar as vantagens das arquiteturas “Best Effort” e “Integrated Service”. O tratamento diferenciado dos pacotes (baseando-se no campo DS do pacote IP) permite a implementação de uma rede com QoS e escalável. Um ponto importante a ressaltar com respeito ao “DiffServ” é que ele mantém um mecanismo simples nos roteadores interiores e joga toda a complexidade para as bordas das redes.

O “DiffServ” é uma arquitetura bastante flexível, permitindo a criação de novos serviços que por ventura possa ser exigidos pelas novas aplicações que surgirão no futuro. Outra vantagem importante ao “DiffServ” é a criação de mecanismos que possibilitem a tarifação diferenciada, possibilitando ao ISPs cobrarem mais das aplicações/clientes que utilizam mais os recursos da rede. Também, a existência de “Service Level Agreement” entre o ISPs e o cliente é muito importante, pois estabelece claramente qual é a expectativa do cliente e o que o IPS precisam alocar de recurso para prover o serviço esperado.

Finalmente, pode-se dizer que o “DiffServ” certamente ocupará definitivamente a sua posição nas redes mundiais nos próximos anos. Isto se dará principalmente pelos requisitos das aplicações como: “Voice over IP”, “Vídeo Conference” e “Vídeo on Demand”, que necessitam de tratamento diferenciado e tem grande apelo popular. Já algumas operadoras de telefonia que utilizam o conceito de redes convergentes (“Next Generation Networks”) estão fazendo uso do “DiffServ” para priorizar os pacotes de VoIP.

5 Bibliography

[1] MACKIEMASON, J., and Varian, H., “Economic faqs about the internet”. In Internet Economics (Cambridge, MA, 1997), J. B. L. McKnight, Ed., MIT press, pp. 27-63.

[2] http://www.isc.org/

[3] CLARK, D., “The design philosophy of the darpa internet protocols”. In Proceedings of ACM SIGCOMM (1988), pp. 16-19.

[4] Available in site http://www.internet2.edu

[5] Available in site http://www.cg.org.br/sobre-cg/history.htm

[6] SHENKER, S., “Public Access to the Internet”. Pretice Hall, NJ, 1995, ch. Service Models and Pricing Policies for an Integrated Service Internet.

[7] BRADEN, B., Clark, D., and Shenker, S., “Integrated services in the internet architecture: an overview”. In RFC 1633, 1994.

[8] PARTRIDGE, C. “A proposed flow specification”. In RFC 1363, I. R. Editor, Ed. 1992.

[9] ZHANG, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D., ”Rsvp: A new resource reservation protocol”. IEEE Network 7, 5 (1993), 8-18.

[10] CLARK, D. D., and Fang, W. ,“Explicit allocation of best effort packet delivery service”. IEEE/ACM Transactions on Networking 6, 4 (1998).

[11] DOVROLIS, C., Stiliadis, D., and Ramanathan, P., “Proportional differentiated services”. In Proceedings of SIGCOMM (October 1999), vol. 29.

[12] CLARK, D. D., “Adding Service Discrimination to the Internet”. http://ana-www.lcs.mit.edu/anaweb/ps-papers/TPRC2-0.ps

[13] JACOBSON, V., Nichols, K., and Poduri, K., “An expedited forwarding phb”. In RFC2598, June 1999.

[14] Available in http://www.coritel.it/coritel/ip/sofia/qos.htm#Integrated%20Services

[15] Available in http://www.computer.org/internet/v3n3/w3onwire.htm

[16] Available in http://www.computer.org/internet/v3n2/w2onwire2.htm

[17] HEINANEN, J., Baker, F., Weiss, W., and Wroclawski, J., “Assured Forwarding PHB Group”, RFC 2597, June 1999.

[18] BLAKE, S., Black, D., Carlson M., Davies, E., Wang, Z., Weiss, W., “An Archicteture for Differentiated Services”, RFC2475, December 1998.

[19] HEINANEN, J., Baker, F., Wroclawski, J., “Assured Forwarding PHB Group”, RCF2597, June 1999.

[20] JACOBSON, V., Nichols K., Poduri K., “An Expedited Forwarding PHB”, RFC2598, June 1999.