3

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

Serviços Integrados 49

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 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

Serviços Integrados 50

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 trans-

Serviços Integrados 51

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.

Serviços Integrados 52

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 roteadores 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.

Serviços Diferenciados 53

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

SLA

SLA SLA

SLA

Figura 3.1 Arquitetura Lógica DiffServ

Serviços Diferenciados 54

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

Serviços Diferenciados 55

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 endereç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.

Serviços Diferenciados 56

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 Condicionamento 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.

Serviços Diferenciados 57

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 caracterí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.

Serviços Diferenciados 58

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 AF ij 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 apresentado 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.

Serviços Diferenciados 59

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.

Serviços Diferenciados 60

Suavizador/ Descartador

Agregados

Policiador Buffers

Descarte ( Fora do Perfil)

Descarte ( Congestionamento )

Agendamento

SLA

TX

Roteador de Borda (Entre Domínios DS)

EF AF ij 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

Serviços Diferenciados 61

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

T C T E

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

Serviços Diferenciados 62

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

T C T E

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 contratado (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).

Serviços Diferenciados 63

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

Serviços Diferenciados 64

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

Serviços Diferenciados 65

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 agregados 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 den-

Serviços Diferenciados 66

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.

Desempenho de Redes DiffServ 67

3.3

Desempenho de Redes DiffServ

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

Desempenho de Redes DiffServ 68

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-se desempenho bem melhor dos esquemas com

Desempenho de Redes DiffServ 69

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 classe 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

Desempenho de Redes DiffServ 70

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,

Desempenho de Redes DiffServ 71

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á

Desempenho de Redes DiffServ 72

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.

B l TD B Pacotes com Preferência

Pacotes sem Preferência

Threshold Dropping Priority Scheduling B h

PS

Pacotes com Preferência

Pacotes sem Preferência

B l PS

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 BTDl 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)< BTDl . Note que TD

permite compartilhamento de buffer entre pacotes tão logo B(t) < BTDl .No

mecanismo PS, um buffer de tamanho BPSh é alocado para pacotes preferidos

e o segundo, de tamanho BPSl , 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

Desempenho de Redes DiffServ 73

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.

1Consideramos 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.