Padronização para Oferecimento de QoS na Internet

Padronização para Oferecimento de QoS na Internet

Nesta seção apresentamos as principais abordagens que estão sendo discu-tidas atualmente para o oferecimento de QoS na Internet e os relacionamentos que podem existir entre elas. Existe um grande interesse acadêmico e comer-cial (fabricantes, provedores) nesse tema, mas o principal fórum de discussão está no âmbito do IETF, o órgão responsável pela padronização na Internet. 3.1

Serviços Integrados

A Internet tradicionalmente oferece um único modelo de serviço chamado de melhor- esforço, que apresenta um desempenho razoável para aplicações as quais não exigem grandes garantias de tempo e segurança, como transfe-rência de arquivos e mensagens de correio eletrônico. Entretanto, a medida que avançamos em direção à era das comunicações multimídia, estão sendo desenvolvidas novas aplicações de tempo real com uma grande sensibilidade ao atraso da rede. Para essas aplicações, o modelo de melhor-esforço é totalmente inadequado, mesmo em redes com cargas leves. Embora esse problema possa ser aliviado introduzindo o maior grau possível de adaptabilidade em certas aplicações, existe uma necessidade de garantias mais rígidas em termos de largura de banda, atraso e perda de pacotes.

Nesse contexto, o IETF criou o grupo de trabalho IntServ (Integrated Ser-vices) [3] para viabilizar o surgimento de uma rede de serviços integrados.O termo serviços integrados é empregado para designar um modelo de serviços para a Internet, que inclui o serviço de melhor esforço, serviços de tempo real e serviços de compartilhamento controlado de enlace. Os objetivos iniciais do

grupo IntServ são a criação de um modelo de serviços integrados e de um mo-delo de referência para implementação. Alguns dos tópicos mais importantes são abordados a seguir.

3.1.1

O Modelo de Referência para Implementação

Em um modelo de Serviços Integrados, um roteador deve ser capaz de tratar diferentes fluxos de acordo com seus respectivos parâmetros de QoS determina-dos em um contrato de serviço. Assim, a funcionalidade básica determina-dos roteadores deve ser estendida para habilitá-los a participar desta rede. Estas novas funci-onalidades incluem quatro componentes básicos: classificador, escalonador de pacotes, controle de admissão, e o protocolo de reserva de recursos.

O classificador mapeia pacotes que chegam em determinadas classes, de forma que todos os pacotes em uma classe recebam o mesmo tratamento. Classe aqui é uma abstração e cada roteador pode mapear um mesmo pacote para uma classe diferente. No entanto, a granularidade de uma classe é bas-tante fina, ou seja, geralmente corresponde a um fluxo específico. Os conceitos básicos e alguns tipos específicos dos demais mecanismos foram introduzidos no Capítulo 2. Em princípio, a reserva de recursos pode ser executada por qual-quer protocolo que seja compatível com o modelo, mas na prática o protocolo RSVP [9] é o padrão de fato, tanto que se refere com freqüência à arquitetura IntServ/RSVP. O RSVP é apresentado na Seção 3.1.4.

3.1.2

O Serviço de QoS Garantido

O Serviço Garantido [10] é uma classe de QoS proporcionado pelo modelo de serviços integrados que oferece um nível assegurado de largura de banda, um limite rígido de atraso fim-a-fim e uma proteção contra a perda de pacotes nas filas, para os pacotes que estiverem obedecendo o perfil de tráfego contratado. É direcionado para aplicações com requisitos rígidos de tempo real, como certas aplicações multimídia intolerantes, que precisam de uma garantia firme de que um pacote não irá chegar no destino depois de um tempo maior que um limite

especificado. Esse serviço não oferece garantia mínima da variação do atraso, simplesmente garante um atraso máximo gerado pelas filas.

A obtenção de um limite máximo para o atraso exige que todos os rotea-dores no caminho suportem o serviço garantido. O comportamento fim-a-fim oferecido por uma série de roteadores que implementam o serviço garantido é um nível assegurado de largura de banda para um determinado fluxo que, quanto utilizado por um fluxo que está sendo policiado, produz um serviço com atraso limitado para todos os pacotes que estejam dentro do perfil. Para ter acesso a esse serviço, as aplicações descrevem os seus fluxos através de um balde de fichas e a partir dos valores de taxa e rajada, cada roteador cal-cula vários parâmetros descrevendo como ele tem que tratar os pacotes desses fluxos. Combinando os parâmetros dos vários roteadores em um caminho, é possível calcular o atraso máximo que um pacote irá experimentar quando transmitido por aquele caminho. Uma vez que as aplicações podem contro-lar os valores de taxa e rajada dos fluxos, elas conseguem obter uma garantia provada matematicamente sobre o atraso máximo dos seus pacotes.

O serviço garantido necessita de controle de admissão para operar de acordo com as especificações. Teoricamente, ele pode ser utilizado com qualquer pro-tocolo de reserva de recursos, mas apenas para a sua utilização em conjunto com o RSVP foi especificada.

3.1.3

O Serviço de Carga Controlada

O Serviço de Carga Controlada [11] não oferece garantias quantitativas rí-gidas, como o Serviço Garantido. O comportamento fim-a-fim oferecido para uma aplicação por uma série de roteadores que implementa esse serviço se as-semelha ao comportamento visto por aplicações que estão recebendo o serviço de melhor-esforço em uma rede apenas levemente carregada (ou seja, sem ne-nhuma situação grave de congestionamento). As garantias que as aplicações têm são:

• um percentual muito alto de pacotes transmitidos chegarão com sucesso no receptor (deve se aproximar da taxa básica de erros do meio de

missão, ou seja, pouquíssimos descartes em filas são permitidos).

• o atraso sofrido por um alto percentual dos pacotes não deverá exceder muito o atraso mínimo sofrido por um pacote dentro de um fluxo. Ou seja, a maior parte dos pacotes deve ter um atraso muito próximo do atraso mínimo.

Para assegurar que essas condições serão válidas, aplicações que requisitam o serviço de carga controlada devem fornecer aos roteadores uma estimativa do tráfego de dados que elas irão gerar, chamada de TSpec, que é baseada em um balde de fichas. Como resposta, o serviço assegura que a aplicação terá a sua disposição recursos dos roteadores suficientes para processar adequadamente todos os pacotes que estiverem de acordo com a especificação contida no TSpec. Por outro lado, pacotes introduzidos na rede fora das especificações poderão ser descartados, ou enfrentar um atraso mais significativo.

O objetivo do serviço de carga controlada é suportar um ampla classe de aplicações que tem sido desenvolvidas para a Internet atual, mas que não funcionam em situações de carga alta na rede. Alguns membros dessa classe são as aplicações de tempo real adaptáveis, atualmente sendo oferecidas inclusive comercialmente. Essas aplicações têm mostrado que funcionam bem com redes com carga leve, mas a qualidade se degrada rapidamente em condições de congestionamento. Um serviço que imita redes com carga leve é útil para essas aplicações.

As aplicações podem solicitar o serviço de carga controlada antes de ini-ciar as transmissões, ou então somente quando elas detectam que o serviço de melhor-esforço não está oferecendo um desempenho aceitável. A primeira estratégia oferece uma maior garantia de que o nível de QoS não irá mudar enquanto durar a sessão. A segunda estratégia é mais flexível e barata, pois o serviço com tarifação mais alta não é utilizado durante todo o tempo de duração da sessão.

3.1.4

O Protocolo RSVP

O RSVP é um protocolo desenvolvido para realizar reserva de recursos em uma rede de serviços integrados. O RSVP é utilizado para requisitar à rede níveis específicos de QoS para as aplicações. Também é utilizado pelos rotea-dores para repassar as requisições de QoS para todos os outros rotearotea-dores que estiverem no caminho entre fonte e destino, e para estabelecer e manter infor-mações de estado que possibilitam oferecer o serviço desejado. As requisições RSVP geralmente terão como resultado a reserva de recursos feita em todos os roteadores no caminho dos dados.

As duas mensagens mais importantes do protocolo RSVP são PATH (que é originado no transmissor) e RESV (que é originado no receptor). Os principais objetivos da mensagem PATH são informar o receptor sobre as características de tráfego da requisição do transmissor e sobre o caminho fim-a-fim entre eles. Além disso, a mensagem PATH instala informações de roteamento reverso em todos os nós por onde passa, para que a mensagem RESV possa percorrer o mesmo caminho. PATH não faz a reserva, ela é feita pela mensagem RESV, enviado pelo receptor. As informações de roteamento reverso são necessárias porque é comum que a comunicação nos dois sentidos siga caminhos distin-tos. Sem essas informações, as reservas de recursos poderiam ser feitas em roteadores diferentes daqueles por onde os dados vão passar.

Após receber uma mensagem PATH, um receptor envia uma mensagem RESV de volta ao último roteador solicitando uma reserva de recursos de acordo com os parâmetros especificados em PATH. Essa mensagem é reen-caminhada para todos os roteadores no caminho até chegar no transmissor. Cada roteador pode aceitar ou rejeitar a reserva de recursos solicitada, de acordo com a quantidade de recursos disponíveis e a política de controle de admissão adotada. Se a requisição é rejeitada, o roteador envia um mensagem de erro para o receptor e a sinalização é encerrada. Se a requisição é aceita, largura de banda do enlace e espaço em buffers são alocados para o fluxo e informações de estado relacionadas ao fluxo são instalados no roteador.

3.2

Serviços Diferenciados

A arquitetura de Serviços Integrados se baseia em um conjunto de processos definidos para cada fluxo individualmente. Em uma rede global como a Inter-net, o enorme número de fluxos a serem processados torna impraticável esta solução. A alternativa foi o desenvolvimento de uma nova arquitetura denomi-nada Serviços Diferenciados (Differentiated Services - DS) [4] cujos objetivos são semelhantes àqueles da arquitetura Intserv, mas que consegue contornar o problema da escalabilidade. A arquitetura Diffserv resolve o problema da escalabilidade processando agregados de tráfego, em vez de fluxos individuais como se explica a seguir.

Um segmento da rede capaz de oferecer Serviços Diferenciados é denomi-nado domínio de Serviços Diferenciados (domínio DS). Um domínio como esse é composto por um conjunto de nós compatíveis com a proposta de Serviços Diferenciados que compartilham uma mesma política de provisão de serviços. Nas extremidades dos domínios DS, os aspectos técnicos e comerciais dos serviços oferecidos são definidos na forma de um contrato de serviço (SLA), que especifica o desempenho que o usuário deve esperar desses serviços e as formas de cobrança e tarifação. O oferecimento de um serviço fim-a-fim é realizando através da concatenação dos vários domínios DS, onde os SLAs são negociados em cada uma das bordas entre os domínios existentes. A arquitetura lógica DiffServ, com os vários domínios e SLAs nas bordas é mostrada na Figura 3.1.

Fonte

Destino

SLA

SLA: Service Level Agreement

Domínio

Domínio

Domínio

Figura 3.1 Arquitetura Lógica DiffServ

A Figura 3.2 representa um domínio DS onde se distinguem os roteadores de entrada, denominados roteadores de borda, e os roteadores internos ao do-mínio, denominados roteadores de núcleo. Nos roteadores de borda os pacotes são policiados, associados a uma determinada classe de agregado e encami-nhados aos nós interiores. Nos roteadores de núcleo são estabelecidas formas de tratamento específico para cada classe de agregado, denominadas Per Hop

Behavior (PHB). Uma vez identificada a classe a que pertence, o pacote é

processado de acordo com PHB correspondente. Assim não é necessário iden-tificar cada fluxo e o processar de acordo com um contrato de serviço específico deste fluxo. Em contrapartida, como o contrato de serviço se refere a um agre-gado é possível que os parâmetros de tráfego sejam garantidos para a média do agregado mas não para determinados fluxos do conjunto.

RN RN RN RB RB RB: Roteadores de Borda RN: Roteadores de núcleo · Classificação · Marcação · Policiamento · Encaminhamento · Classificação · Encaminhamento Domínio DS RB RB RB Fluxo Ingresso Fluxo Egresso 1 2 3 4 6 5 7 8

Figura 3.2 Domínio DiffServ ilustrando os roteadores de borda e interno

A identificação das agregações de fluxos no interior de um domínio de Serviços Diferenciados é efetuada através da marcação de um novo campo no cabeçalho IP chamado DS (Differentiated Services). O campo DS é obtido pela renomeação do campo TOS (Type of Service), no caso de IPv4, ou do campo Traffic Class, no caso de IPv6. A estrutura do campo DS é mostrada na Figura 3.3. Seis bits do campo DS formam o subcampo DSCP (Differentiated Services Codepoint), que identifica a agregação de fluxos. Os dois outros bits estão

reservados para uso futuro. Em cada roteador compatível com a proposta de Serviços Diferenciados, o código (Codepoint) contido no subcampo DS é mapeado em um PHB.

DSCP Diffserv Code Point ND Não Definido

Figura 3.3 Estrutura do campo DS

Os roteadores de ingresso ao domínio de Serviços Diferenciados devem pos-suir informações que identifiquem um fluxo de dados individualmente. Desta forma, os pacotes pertencentes a um fluxo podem ser classificados e marcados com o código correspondente a uma determinada agregação de fluxos. Os clas-sificadores que examinam a combinação de um ou mais campos do cabeçalho do pacote para a identificação de um fluxo, para que possam indicar a sua marcação como pertencentes a uma determinada agregação, são chamados de classificadores Multicampo (Multifield - MF). Esses campos podem ser o en-dereço de origem, o enen-dereço de destino, o número das portas na origem e no destino, o identificador de protocolo ou o campo DS. Os classificadores deste tipo encontram-se nos nós de ingresso de um domínio DS ou junto às fontes de tráfego.

No interior do domínio DS, a classificaçao dos pacotes é realizada somente pelo exame do subcampo DSCP. Os classificadores que realizam essa tarefa são chamados de classificadores de Comportamento Agregado (Behavior Aggregate - BA). A cada nó do domínio DS é associada uma tabela de mapeamento de fluxos para códigos, no caso de classificadores MF, ou de códigos para novos códigos, no caso de classificadores BA. Portanto, os classificadores BA permitem a remarcação do código associado aos pacotes. Resumidamente, como os códigos identificam as agregações, há um estado por fluxo nos nós de ingresso e um estado por agregação nos demais nós pertencentes ao domínio DS. O objetivo da agregação dentro do domínio DS é aumentar a escalabilidade pela manutenção de um menor número de estados.

3.2.1

Condicionamento de Tráfego

Para realizar as funções de classificação, marcação e encaminhamento, a arquitetura Diffserv prevê a adoção de um conjunto de elementos funcionais implementados em seus nós. Esses elementos são responsáveis pelo condicio-namento do tráfego a ser atendido pela arquitetura DS. A política de condici-onamento de tráfego integra o Acordo de Condicicondici-onamento de Tráfego (Traffic

Conditioning Agreement -TCA) junto com as regras de classificação adotadas

pelo domínio DS. O TCA também estabelece o perfil de tráfego contratado, que especifica as características do tráfego selecionado pelo classificador para compor uma agregação de fluxos.

Os elementos funcionais de condicionamento de tráfego incluem medidores, marcadores, suavizadores e mecanismos de descarte de tráfego. O conjunto destes mecanismos corresponde a um policiamento de tráfego. Os medidores são responsáveis por verificar a conformidade do tráfego ao perfil de tráfego contratado estabelecido no TCA. O seu resultado influencia as ações dos de-mais elementos. O marcador estabelece o código no campo DSCP do pacote, acrescentando este pacote a uma determinada agregação. O suavizador de trá-fego retém um ou mais pacotes até que estes estejam em conformidade com o perfil contratado e possam ser encaminhados na rede. O buffer utilizado por um suavizador possui tamanho limitado. Portanto, eventualmente, pacotes podem ser descartados quando o tamanho do buffer é insuficiente. O relacio-namento entre estes elementos está ilustrado na Figura 3.4 . Os pacotes fora de perfil podem ser tratados de formas distintas. Eles podem ser descartados, suavizados ou remarcados para uma outra agregação que possua um serviço inferior. Essa decisão deve estar especificada no TCA.

Figura 3.4 Condicionadores de Tráfego 3.2.2

Arquiteturas Específicas

As funções de condicionamento de tráfego, normalmente, estão localizadas nos nós de ingresso e egresso de um domínio DS. Contudo, essas funções po-dem também estar em nós interiores ao domínio DS, ou mesmo em nós não-DS. Nesses casos, os condicionadores podem estar no domínio da fonte de tráfego. Desta forma, essa fonte pode realizar uma marcação inicial ou pré-marcação em seus pacotes antes destes alcançarem o domínio DS. Essa alternativa pos-sui algumas vantagens. A marcação torna-se mais simples, pois as regras de classificação são reduzidas.

As aplicações que geram o tráfego possuem melhores condições de marcar adequadamente os pacotes de seus fluxos de acordo com as próprias caracte-rísticas destes. Por desconhecer as caractecaracte-rísticas do tráfego, um mecanismo de condicionamento no roteador de ingresso pode marcar pacotes essenciais à qualidade do tráfego como fora do perfil e comprometer o resultado da trans-missão. Assim, as fontes, cientes do conteúdo de seus fluxos de tráfego, podem pré-marcar seus pacotes e evitar a marcação indiscriminada dos roteadores de fronteira.

Apresentamos a seguir diagramas da arquitetura específica de condiciona-mento de tráfego para os diverso tipo de roteadores.

3.2.2.1

Roteador de Borda (Entrada)

Como visto anteriormente, cabe ao roteador de borda as funções de classi-ficar, marcar, policiar e encaminhar os pacotes. Estas operações estão repre-sentadas na Figura 3.5. Fontes CAC Classificador /Marcador Buffers Suavizador/ Descartador Descarte (Fora do Perfil) Descarte (Congestionamento) Agendamento SLA TX

Roteador de Borda (Entrada)

EF AFij

BE

Tratamento por Fluxos

Medidor

Figura 3.5 Diagrama de Blocos do Roteador de Borda

Um pacote ao chegar em um roteador de borda pode sofrer um controle de admissão ou simplesmente passar por esse bloco encontrando-se diretamente com o classificador. No classificador, ele é direcionado, com base no SLA, para o apropriado condicionador de tráfego. Uma vez encaminhado o tráfego, o medidor o analisa e verifica se está no perfil contratado. Dependendo do resul-tado apresenresul-tado no medidor, ações poderão ocorrer nos blocos de marcação, suavização e descarte. Após passarem pelo condicionador de tráfego existente nos nós de borda, os pacotes são marcados com os DS codepoint apropriados, onde esse será um PHB EF, AF ou BE. Após saírem da estrutura de condici-onamento de tráfego, os pacotes são encaminhados para o buffer de saída do roteador, que irá servi-los através de uma disciplina de escalonamento. Nesse buffer, os pacotes também podem ser descartados, porém nesse caso, a perda de pacotes será devido a congestionamento.

3.2.2.2

Roteador de Núcleo

O roteador de núcleo recebe os fluxos já marcados e agregados dos nós de borda, logo um tratamento empregado nele simplifica bastante, pois ape-nas a estrutura de encaminhamento de pacote será necessária. Um pacote, pertencente a fluxo agregado, ao chegar no roteador central é encaminhado di-retamente para o buffer de saída. No buffer de saída, os pacotes serão servidos de acordo com a disciplina de escalonamento de fila empregada.

Agregados Buffers Descarte (Congestionamento) Agendamento TX Roteador Núcleo

Tratamento por Agregados

Figura 3.6 Diagrama de Blocos do Roteador Núcleo

3.2.2.3

Roteador de Borda (Entre Domínios Diffserv)

O Roteador de borda entre domínios Diffserv tem como função apenas o encaminhamento de pacotes. Eles têm que garantir que os pacotes que saem do seu domínio Diffserv em direção a um outro domínio Diffserv cheguem em conformidade com o SLA contratado. Logo, uma estrutura de condicio-namento de tráfego é necessária. O pacote ao chegar no roteador de borda é encaminhado para o módulo de policiamento, nele o pacote é medido e mol-dado de acordo com SLA contratada entre os domínios DS. Após sair do bloco de policiamento, o pacote é encaminhado para o buffer que irá servi-lo com a disciplina de escalonamento aplicada.

Suavizador/ Descartador Agregados Policiador Buffers Descarte (Fora do Perfil) Descarte (Congestionamento) Agendamento SLA TX

Roteador de Borda (Entre Domínios DS)

EF AFij

BE

Tratamento por Agregados Medidor

Figura 3.7 Diagrama de Blocos do Roteador de Borda (Entre Domínios DS) 3.2.3

Marcadores de Tráfego

A seguir serão apresentados três mecanismos de marcação de tráfego padro-nizados pelo IETF.

3.2.3.1

srTCM (single rate Three Color Marker)

O srTCM [12] é um mecanismo de policiamento de tráfego que é configurado através de três parâmetros: CIR (Committed Information Rate) - taxa do conteúdo de informação, CBS (Committed Burst Size) - tamanho médio de explosividade e EBS (Excess Burst Size) -tamanho máximo de explosividade. Ele é usual nas extremidades das redes DiffServ e admite os fluxos com base no tamanho máximo de explosividade, e não na taxa de pico. Nesse mecanismo, o fluxo de pacotes entrante é primeiramente medido, e dependendo do resultado obtido, os pacotes podem sair marcados como no perfil (verde), elegível para descarte (amarelo) ou (fora do perfil) vermelho como representado na Figura 3.8.

O medidor desse mecanismo pode operar em dois modos, o “cego” e o

EBS: Número máximo de Fichas Fichas? (S) (N) CIR (fichas/s) Vermelho CBS: Número máximo de Fichas Fichas ? (N) (S) Pacotes Verde Amarelo TC TE CIR: bits/s CBS e EBS: bytes Figura 3.8 Marcador srTCM

“ciente”. No modo cego, o medidor considera que o pacote não foi “colorido” previamente. No modo ciente, o medidor assume que alguma entidade “pré-coloriu” o pacote.

O comportamento do medidor é especificado através de dois baldes de fi-chas, C e E, aonde em ambos a taxa de entrada de fichas é CIR. O tamanho do balde C é CBS e o tamanho do balde E é EBS. Logo, um grupo de pacotes ao chegar no srTCM analisa primeiramente no balde C se há fichas suficientes. Se a resposta for positiva, o pacote é marcado como verde e é encaminhado; caso contrário, o pacote será encaminhado para o balde E. No balde E o número de fichas é analisado novamente. Caso existam fichas suficientes no balde, o pa-cote é marcado como amarelo e encaminhado; caso contrário ele é encaminhado como vermelho.

O modo cego e o ciente trabalham similarmente. Porém, no modo ciente, se um pacote chega marcado como amarelo, a análise do balde C não é feita, sendo o pacote encaminhado diretamente para o balde E.

3.2.3.2

trTCM(two rate Three Color Marker)

O mecanismo trTCM [13] é similar ao srTCM. Porém, neste mecanismo quatro parâmetros são necessários para sua configuração: CIR (Committed Information Rate) - taxa média de informação; CBS (Committed Burst Size) - tamanho médio de explosividade; PIR (Peak Information Rate) - taxa de

pico; e PBS (Peak Burst Size) - tamanho do pico de explosividade. Como no srTCM, o trTCM pode operar nos modos cego ou ciente.

A principal diferença entre esses dois mecanismos é que no trTCM o se-gundo balde de fichas é enchido pela taxa PIR e não mais pela CIR. Logo, seguindo o mesmo procedimento adotado pelo srTCM, os pacotes chegarão no primeiro balde de fichas. Caso existam fichas suficientes, os pacotes são mar-cados como verde, caso contrário, são encaminhados para o segundo balde. No segundo balde, uma outra análise é feita: caso ela seja bem sucedida, os pacotes saem marcados como amarelo, caso contrário, são marcados como vermelho.

PBS: Número máximo de Fichas Fichas? (S) (N) CIR: r fichas/s Vermelho CBS: Número máximo de Fichas Fichas ? (N) (S) Pacotes Verde Amarelo TC TE

CIR e PIR: bits/s CBS e EBS: bytes PIR: r fichas/s

Figura 3.9 Marcador trTCM

3.2.3.3

TSW (Time Sliding Window)

O TSW [14] faz a marcação dos pacotes que estão dentro do perfil con-tratado (In-Profile) ou fora do perfil concon-tratado (Out-Profile). O algoritmo possui dois componentes independentes: um estimador de taxa, que estima a taxa de transmissão num determinado período de tempo, e um marcador, que faz a marcação dos pacotes baseado na taxa estimada. Com a taxa es-timada, o TSW determina se a fonte excedeu sua taxa contratada. Caso a fonte esteja enviando a uma taxa menor do que a contratada, todos os pacotes serão marcados como In-Profile; se estiver acima da taxa contratada , todos os pacotes excedentes à taxa serão marcados como Out-Profile. O marcador qe implementa este algortimo é chamado de TSW2CM ( TSW 2 color marker).

O algoritmo TSW marca com três cores também , neste caso ele é chamado de TSW3CM ( TSW 3 color marker). Na verdade é um variação do algortimo de 2 cores, aonde se marca com verde os pacotes dentro do perfil , com vermelho os pacotes fora do perfil e com amarelo os pacotes elegíveis para descarte. A relação lógica entre o estimador de taxa e o marcador é mostrado na Figura 3.10.

Estimador de Taxa

Marcador Fluxo de Pacotes Marcados (Verde, amarelo e vermelho) Taxa

Fluxo de Pacotes

Figura 3.10 Marcador TSW3CM

3.2.4

PHB’s para Implementação de Serviços Diferenciados

A arquitetura DiffServ define um serviço como um “tratamento global de um determinado subconjunto do tráfego de um usuário dentro de um domínio DS, ou fim-a-fim” [4]. Mas, embora receba o nome de “Serviços diferenciados”, o IETF não tem a intenção de padronizar os serviços, especificando apenas comportamentos de encaminhamento por salto ou PHBs - Per Hop Beha-viors. Um PHB descreve como será realizado o encaminhamento de pacotes pertencentes a uma mesma classe de serviço em um roteador DiffServ.

Atualmente, existem duas propostas de PHB (Per-Hop Behavior) para a implementação de Serviços Diferenciados: o Encaminhamento Expresso

(Expe-dited Forwarding- EF) [15] e o Encaminhamento Assegurado (Assured

Forwar-ding - AF) [16]. Estas propostas serão descritas a seguir.

3.2.4.1

PHB EF - Encaminhamento Expresso

O PHB de Encaminhamento Expresso (Expedited Forwarding - EF) tem como objetivo principal definir garantias mais rígidas de QoS para aplicações muito sensíveis a variações de características temporais da rede. Ele pode ser

utilizado para implementar um serviço com pouco atraso, pouca variação do atraso (jitter) e largura de banda garantida. Para os usuários, esse serviço, conhecido como Premium, parece com uma Linha Privativa Virtual. Para esse tipo de serviço, os pacotes que não estiverem dentro do perfil contratado são descartados diretamente, não passando por uma reclassificação. O PHB EF é a versão de DiffServ para encaminhar tráfego de aplicações multimídia e de tempo real em geral.

As filas nas quais um pacote em trânsito permanece ao longo de sua rota pelos nós da rede são as maiores responsáveis pela perda, pelo retardo e pelo

jitter apresentados por este pacote. O PHB de Encaminhamento Expresso

objetiva diminuir a permanência dos pacotes pertencentes a uma determinada agregação de fluxos em filas no interior de um domínio DS. Para alcançar essa meta, o nó que oferece o PHB EF deve garantir que a agregação de fluxos contratante receba a taxa de serviço contratada, que deve ser maior que a taxa de chegada em qualquer instante. Essa garantia deve prevalecer independentemente da intensidade de outros tráfegos que cheguem ao nó.

Os roteadores de ingresso do domínio DS devem condicionar o tráfego EF de forma a assegurar que a sua taxa de chegada aos nós interiores esteja em conformidade com a taxa contratada. Essa medida protege o domínio DS de um uso abusivo e obriga as fontes de tráfego EF a suavizar o tráfego trans-mitido se desejarem evitar o condicionamento de seus pacotes no ingresso do domínio DS. Na realidade, conforme as agregações EF provenientes de diferen-tes roteadores de ingresso compõem novas agregações nos roteadores interiores ao domínio DS, estas novas agregações também precisam ser condicionadas para que a definição do PHB EF seja válida a qualquer momento por todo o trajeto. Portanto, a junção dessas agregações e também a diferença de capa-cidades entre os enlaces do interior de um domínio DS podem obrigar que um recondicionamento seja realizado em pontos no interior deste domínio.

A implementação do PHB EF pode ser realizada por diferentes mecanismos de escalonamento de filas. Um mecanismo com uma fila prioritária (Priority

Queueing - PQ) fornece o comportamento desejado. Nesse caso, torna-se

espe-cialmente importante o condicionamento de tráfego nas fronteiras do domínio

DS. A ausência de tal condicionamento permitiria, em uma situação de abuso da agregação EF em relação à taxa de transmissão, a utilização de recursos não contratados em detrimento de tráfegos presentes nas demais filas. Outra possibilidade de implementação é a utilização de uma fila entre um conjunto de filas servidas por um mecanismo de (Weighted Round Robin - WRR). A fatia de serviço alocada à fila que atende a agregação EF deve ser correspondente, no mínimo, a taxa de serviço contratada.

3.2.4.2

PHB AF - Encaminhamento Assegurado

O PHB de Encaminhamento Assegurado (Assured Forwarding - AF) é es-sencialmente representativo da arquitetura Diffserv. Esse modelo de serviço, ao invés de fornecer uma garantia estrita, fornece uma garantia estatística, implementada através de níveis de precedência no descarte de pacotes. O ob-jetivo é fornecer, mesmo em situações de congestionamento, um serviço com as característica do serviço melhor-esforço operando sem congestionamento.

Um perfil associado a cada tráfego define o serviço esperado por este. As-sim, um mecanismo de condicionamento de tráfego atua nas fronteiras do do-mínio DS de forma a marcar os pacotes de acordo com a sua conformidade com esse perfil. Os roteadores de fronteira são responsáveis pela manutenção da granulosidade dos serviços providos à agregação de fluxos.

A garantia existente no modelo de Serviço Assegurado é que pacotes marca-dos como conformes são entregues com alta probabilidade, enquanto o tráfego agregado não exceder a taxa contratada definida no perfil de serviço. No entanto, é permitido ao usuário exceder as taxas contratadas. Ao fazê-lo, con-tudo, o usuário deve estar consciente de que o tráfego excedente não terá a mesma alta probabilidade de entrega. Conforme os pacotes são transporta-dos pela rede e agregatransporta-dos a outros fluxos, roteadores nas fronteiras de outros domínios somente condicionam a agregação de fluxos.

Foram definidas quatro Classes AF. Dentro de cada classe AF, um pacote IP pode ser marcado, ou pelo próprio usuário ou pelo domínio DS, com até três níveis de precedência para descarte. No caso de congestionamento

tro de uma classe AF, a precedência de descarte de um pacote determina a importância relativa daquele pacote. Um nó DS em situação de congestiona-mento preferencialmente descarta pacotes com um maior valor de precedência de descarte, ao mesmo tempo em que evita descartar pacotes com um valor de precedência de descarte menor. Assim, o AF define um grupo de PHBs onde são definidas até 12 níveis de serviços AF distintos, distribuídos em 4 filas (classes) com 3 precedências de descarte cada. A configuração desses níveis a cada nó DS pode ser diferente desde que se mantenha coerente em relação às prioridades relativas entre as filas e precedências de descarte. A implementação das classes AF nos nós do domínio DS está ilustrada na Figura 3.11.

AF11, 12, 13 AF4X AF2X AF3X AF1X Qualidade de Serviço

AFx1 tem uma menor probabilidade de descarte ( melhor serviço) de que AFx2.

Figura 3.11 Implementação do PHB de Encaminhamento Assegurado

O nível de garantia para o encaminhamento depende da quantidade de re-cursos alocados para a classe AF, da carga atual de cada classe e em caso de congestionamento, do valor de precedência de descarte do pacote IP. A im-plementação de um PHB AF procura minimizar congestionamentos de longa duração, porém permitindo congestionamentos de curta duração, como os re-sultantes de rajadas de tráfego.

O PHB AF detecta e reage a congestionamentos de longa duração dentro de cada classe através do descarte de pacotes. Além disto, ele aceita em sua fila pacotes que causam congestionamento de curta duração. Para a realização desse procedimento é necessário um algoritmo para o gerenciamento ativo de filas como os algoritmos RED, RIO e WRED, descritos no capítulo anterior.

3.3

Desempenho de RedesDiffServ

Nesta seção apresenta-se um conjunto de resultados básicos de desempenho dos modelos propostos para as redes DiffServ e alguns resultados recentes. Algumas questões básicas são colocadas como referência:

• Qual a melhor disciplina de filas a ser utilizada em um determinada configuração de tráfego?

• Que tipo de garantia real pode oferecer uma rede DiffServ ? Taxas con-tratadas podem ser sempre alcançadas?

Como visto anteriormente, a arquitetura DiffServ possui dois PHBs padro-nizados. Porém não existe uma padronização especificando qual disciplina de encaminhamento de pacotes deve ser utilizada. A garantia de atraso mínimo no PHB classe EF sugere em princípio a utilização de uma fila com prioridade para este tipo de tráfego. Todavia, se os recursos são compartilhados, a prioridade ao tráfego EF pode significar a asfixia dos demais tráfegos. Na especificação do PHB AF é garantido uma quantidade mínima de recursos à cada classe de encaminhamento AF. Porém, em grande parte do tempo, o enlace não está congestionado, deixando uma quantidade de banda ociosa. Nestas ocasiões é permitido uma redistribuição dessa banda ociosa entre as classes AF existentes. Qual será então a maneira mais justa para se redistribuir essa banda? Estas e outras questões têm sido investigadas em diversos trabalhos [17–19].

3.3.1

Desempenho de Tráfego EF

Na RFC 2598 “An Expedited Forwarding PHB ” são descritos resultados de simulações deste modelo. O objetivo das simulações é avaliar o jitter nos pacotes EF quando estes compartilham a banda do roteador de núcleo com outros tráfegos. É utilizada uma topologia com 6 hops com bandas decres-centes convergindo para um enlace gargalo através de um roteador de núcleo. Informa-se que a taxa agregada de fluxos EF corresponde a 30% deste enlace

e que uma mistura de FTP e HTTP é usada para sobrecarregar o enlace no roteador de núcleo.

Como especificado no EF PHB, o tráfego EF é encaminhado através de uma fila separada enquanto o tráfego restante segue por outra. São avaliadas duas formas de escalonamento de filas : PQ e WRR. Em geral, verifica-se que o esquema PQ diminui o jitter em relação ao esquema WRR. São avaliados os efeitos do número de fluxos EF, da taxa de serviço e do número de filas de saída. O trabalho é pioneiro e sugere-se que muitas alternativas precisam ser investigadas.

Em [17] são realizadas extensivas simulações envolvendo o uso de PQ e WRR. A topologia está mostrada na Figura 3.12 onde S0 e S6 são tráfegos EF, S1 e S2 são tráfegos AF e os demais são de melhor- esforço. LSRx são roteadores de borda, RTx são roteadores de núcleo e Rx são receptores.

S3 S4 S5 R1 R2 R3 R4 R5 R6 S0 S1 S2 15Mb 1ms 15Mb 1ms 15Mb 1ms LSR0 LSR1 LSR2 15Mb 1ms 15Mb 1ms 15Mb 1ms 15Mb 1ms 20Mb 5ms 20Mb 7ms S6 S7 15Mb 1ms 15Mb 1ms 15Mb 1ms LSR3 RT0 RT1 RT2 15Mb 1ms

Figura 3.12 Topologia da Simulação

Com relação ao escalonamento, são consideradas 3 alternativas:

• Filas com prioridades: prioridade máxima para EF e decrescentes para AF e BE.

• WRR: filas para EF, AF e BE atendidas em rodízio com pesos. • PQWRR: fila com prioriade para EF e WRR entre AF e BE.

Os resultados são, basicamente, os valores de atraso e jitter do tráfego EF S0-R1. Inicialmente, simula-se uma situação de congestionamento e comparam-se os três esquemas. Verifica-comparam-se decomparam-sempenho bem melhor dos esquemas com

PQ e aproximadamente igual entre estes. Em seguida, considera-se um cenário onde aumenta-se o volume de tráfego AF em relação à EF verificando-se um aumento substancial do jitter com WRR. São também investigados o impacto de diferentes volumes de tráfego AF e o prejuízo do serviço BE em presença do alto volume de tráfego EF/AF.

A análise feita através de simulações mostrou que a disciplina PQWRR possui um comportamento melhor que o WRR no suporte do tráfego EF, apresentando um baixo atraso e uma pequena variação estatística do atraso em diferentes condições do tráfego EF. Usando o modelo PQWRR, a performance do tráfego EF mostrou-se firme, independentemente da carga de tráfego AF empregada, respeitando, assim, as especificações do modelo DiffServ. Mostra-se ainda que o PQWRR minimizou o problema da asfixia da clasMostra-se BE.

Pode-se dizer que o trabalho confirma e quantifica algumas idéias básicas em relação ao escalonamento. Ou seja, que o escalonamento PQ deve ser usado para o tráfego EF, e que WRR é uma forma adequada de compartilhamento entre os tráfegos AF e BE. Esta estrutura está representada na Figura 3.13.

EF AF

BE _WRR

PQ

Figura 3.13 Disciplina de fila PQWRR

Alguns trabalhos recentes abordam também estas questões e propõem a utilização de outros tipos mais complexos de escalonamento. Gallardo e Ma-krakis [18] propõem um novo modelo de realocação dinâmica da banda ociosa, o DP-WFQ (Dynamic Predictive Weighted Fair Queuing) tendo como princi-pal motivação a necessidade de suprir as deficiências encontradas nos modelos relacionados WFQ (Weighted Fair Queuing), WF2Q (Worst-Case WFQ) e LTO-WFQ (Least Time to Overflow WFQ).

O escalonamento WFQ garante uma fração mínima da banda para cada classe independentemente do comportamento dos fluxos. Se uma das classes de tráfego não estiver usando a banda a ela reservada, essa é redistribuída

proporcionalmente entre as classes ativas. Isso possibilita a uma classe de tráfego receber uma banda maior que a ela garantida. Porém, a realocação desta banda ociosa é feita de modo estático, de forma que as proporções nunca se alteram.

O WF2Q (Worst-Case WFQ) propõe um novo algoritmo que provê uma melhor aproximação para o comportamento ideal da disciplina GPS (General

Processor Sharing). O modelo LTO-WFQ (Least Time to Overflow WFQ),

utiliza a banda excedente para servir as filas que estão mais próximas de enche-rem, reduzindo assim, as perdas nas múltiplas classes. Para isto, é necessário fazer uma predição do tempo que falta para cada fila encher. A proposta de Gallardo e Makrakis consiste em melhorar esta predição. O desempenho dos diversos esquemas foi comparado em uma simulação considerando três tipos de tráfego: vídeo agregado, dados e tráfego WWW. A Figura 3.14 apresenta o modelo de simulação. Fontes de Vídeo Fontes de Dados Fontes WWW Roteador Segmentador WFQ Marcador-0 Marcador-2 Marcador-1 Internet

Figura 3.14 Modelo de simulação DP-WFQ

Em [19], Ferrari, Pau e Raffaelli analisam o desempenho de um tráfego EF através de medidas. Mostra-se que o atraso fim-a-fim sofrido pelo pacote EF em uma disciplina PQ (não preemptiva) é influenciado por três grandes fatores: tamanho do pacote de baixa prioridade, tamanho instantâneo da fila e tamanho do pacote EF.

A sensibilidade em relação ao tamanho do pacote de baixa prioridade vem do fato da fila ser não preemptiva, logo, se um pacote EF chegar no momento em que o pacote BE está sendo servido, ele deverá esperar o término do tempo de serviço do pacote BE para em seguida ser devidamente servido. Em relação ao pacote de alta, o seu aumento significa num aumento do tempo médio de serviço sofrido por cada pacote, logo, os pacotes que se encontram na fila,

também esperarão um maior tempo para serem atendidos.

O tamanho instantâneo da fila está diretamente relacionado com a caracte-rística explosiva do tráfego internet, pois dependendo da posição do pacote EF num surto de pacotes, o atraso encontrado pode variar de zero até o máximo permitido.

3.3.2

Desempenho de Tráfego AF

A preocupação básica relacionada ao tráfego AF é quanto a capacidade de atendimento à taxa contratada. Vários estudos vêm sendo feitos com o objetivo de estabelecer relações entre banda contratada, banda assegurada, condições de tráfego, recursos de rede e mecanismos de controle. Como a classe AF é tipicamente usada por tráfego TCP/IP, é particularmente importante a inte-ração entre os mecanismos da arquitetura Diffserv e os mecanismos de controle de congestionamento no TCP. Este problema será abordado com detalhe no capítulo 4.

3.3.3

Modelos Analíticos de Controle de Tráfego

Dois trabalhos relativamente recentes [20,21] procuram fazer uma modela-gem analítica dos mecanismos básicos de controle de tráfego em redes Diffserv. Em [20], o intuito é fazer uma comparação desses mecanismos através da aná-lise da perda de pacotes e do atraso. O trabalho parte de duas questões básicas: (1) Como um roteador interno deve tratar pacotes de diferentes classes; (2) O roteador de borda (acesso) deve ou não encaminhar os pacotes que estão fora do perfil? Esta segunda questão será abordada no Capítulo 4. A seguir apre-sentamos um resumo da análise em torno da primeira questão

O tratamento de pacotes de diferentes classes mencionado é reduzido em [20] a dois esquemas: (1) fila com prioridade - denominado priority scheduling (PS) e (2) fila FIFO com mecanismo de descarte diferenciado para cada classe de serviço, denominado threshold dropping (TD). No esquema TD um limiar de queda é associado a cada classe de serviço determinando se o pacote será

descartado ou não. Especificamente, um pacote é aceito se o tamanho da fila for menor que o limiar correspondente a sua classe. No desenvolvimento apresentado foram consideradas apenas 2 classes.

BlTD B Pacotes com Preferência Pacotes sem Preferência

Threshold Dropping Priority Scheduling

BhPS Pacotes com Preferência Pacotes sem Preferência BlPS

Figura 3.15 Modelos Threshold Dropping e Priority Scheduling

A Figura 3.15 ilustra os mecanismos TD e PS. No TD, o B simboliza o

tamanho total do buffer, e BT D

l simboliza o limiar para pacotes não preferidos.

B(t) simboliza o tamanho do buffer no instante t. Todos pacotes aceitos são enfileirados num único buffer simples com disciplina de fila FIFO. A chegada de pacotes preferidos são aceitos tão logo exista espaço em buffer, isto é, B(t)<

B. Pacotes não-preferidos serão aceitos somente se B(t)< BT D

l . Note que TD

permite compartilhamento de buffer entre pacotes tão logo B(t) < BT D

l .No

mecanismo PS, um buffer de tamanho BP S

h é alocado para pacotes preferidos

e o segundo, de tamanho BP S

l , para pacotes não-preferidos. Um pacote é

admitido tão logo exista espaço em seu buffer correspondente.

A análise primeiramente utilizou um modelo de chegadas de Poisson, em seguida foi feito uma análise com um tráfego de chegadas gerado por uma popu-lação de fontes ON-OFF. Para o modelo de chegadas de Poisson, constatou-se que é possível prover um atraso consideravelmente menor para pacotes pre-feridos com priority scheduling que com threshold dropping. Adicionalmente, constatou-se que é necessário um aumento de 30% a 70% na capacidade do link para que threshold dropping tenha o mesmo atraso esperado que o priority

scheduling.

Em relação à perda de pacotes, os mecanismos de roteamento tiveram as mesmas taxas para os pacotes preferidos, com TD provendo uma margem me-nor de perda em relação ao PS. Resultados similares foram observados quando

o tráfego é gerado por fontes ON-OFF, com a seguinte exceção: quando as fon-tes são extremamente em rajada e uma pequena margem de perda é permitida, TD utiliza de forma mais eficiente o buffer e a capacidade do link.

Finalmente, para o caso em que as fontes ON-OFF são adaptativas1

, observou-se resultados similares aos obtidos com o modelo de chegadas de Poisson. Resu-mindo, os resultados analíticos justificam o que parece ser uma solução natural para implementação dos serviços EF e AF: uso de fila com prioridade para EF e descarte seletivo para AF.

1

Consideramos fontes adaptativas aquelas que acomodam fatores como perda, atraso e vazão. Assim, quando a rede não fornece condições ideais devido a congestionamento, aceita-se uma perda de qualidade em relação ao parâmetro considerado menos importante.