Upload
trinhtuong
View
212
Download
0
Embed Size (px)
Citation preview
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.