Aula 4 - Qualidade de Serviço (qos)

Prévia do material em texto

Gerência e Análise de Redes
Aula 4 - QUALIDADE DE SERVIÇO (QoS)
INTRODUÇÃO
Nesta aula, você aprenderá sobre as limitações relativas à qualidade de serviço, presentes na camada de rede da internet.
Também serão abordadas possíveis soluções usadas para mitigar as limitações discutidas e você aprenderá sobre o método padrão de
implementação de classes de serviço na Internet.
Bons estudos!
OBJETIVOS
De�nir Qualidade de Serviço (QoS – Quality of Service) em redes IP, incluindo suas limitações e desa�os;
Descrever Redes de Melhor Esforço;
Identi�car Múltiplas Classes de Serviço.
O QUE É QUALIDADE DE SERVIÇO?
O protocolo de camada de rede da internet, o IP, provê um serviço denominado de melhor esforço. Em outras
palavras, a internet faz seu melhor esforço para transportar cada datagrama do remetente ao receptor o mais
rapidamente possível, mas não faz nenhuma promessa sequer sobre a Qualidade de Serviço (QoS – Quality of
Service) a ser alcançada.
Entende-se QoS, então, como:
Portanto, quando se diz que a internet, em sua camada de rede, oferece o serviço de melhor esforço signi�ca
que a rede, em princípio, não oferece QoS.
DIFERENTES REQUISITOS QUANTO À QOS
É importante destacar que diferentes classes de aplicações possuem diferentes requisitos quanto à QoS. Por exemplo, aplicações multimídia
(streaming de áudio/vídeo, telefonia IP etc.) tipicamente requerem que a taxa de transmissão esteja acima de um nível de�nido para que a aplicação
funcione.
Veja algumas características:
 O atraso e a perda também impactam na qualidade da experiência do usuário e não podem ser muito altos.
 Outras aplicações, como downloads de arquivos, correio eletrônico e aplicações de bancos de dados, não toleram bem degradações no atraso
e na taxa de transmissão, mas não toleram perda de dados.
 A falta da garantia (QoS) na internet impõe desa�os signi�cativos, principalmente ao projeto de redes que deve suportar aplicações
multimídia.
 Streaming de áudio/vídeo, vídeo conferência e telefonia IP (VoIP) são exemplos de aplicações que são bastante sensíveis à variação de atraso
e à taxa de transmissão e, nos casos das aplicações multimídia de tempo real (teleconferência), ao atraso.
 Algum nível de perda é tolerável, desde que não seja muito alta. Em geral, atrasos acima de 150ms já impactam fortemente aplicações de
videoconferência e VoIP.
 Um nível de perda de pacotes que ultrapasse a faixa de 1% a 20% também gera forte degradação na experiência do usuário de aplicações
multimídia.
Exemplo de VoIP
, Para manter a discussão em termos concretos, suponha as limitações de um serviço de IP de melhor esforço no contexto de um exemplo especí�co de VoIP. O
remetente gera bytes a uma taxa de 8.000bytes por segundo. A cada 20ms, o emitente agrupa esses bytes em um bloco. Um bloco e um cabeçalho especial
(discutiremos sobre isso em seguida) são encapsulados em um segmento UDP por meio de uma chamada à interface do socket. Sendo assim, o número de bytes
do bloco é:, , (20ms) ∙ (8.000bytes/s) = 160bytes, , Um segmento de UDP é enviado a cada 20ms. Se cada pacote chega ao receptor com um atraso fim a fim
constante, então, os pacotes chegam no receptor a cada 20ms. Nessas condições ideais, o receptor pode simplesmente reproduzir cada parte assim que ele
chega. Infelizmente alguns pacotes talvez se percam e a maioria deles não possuirá o mesmo atraso fim a fim ainda que a internet esteja ligeiramente
congestionada. Por esse motivo, o receptor deve se empenhar em determinar:, , 1 - quando reproduzir uma parte; e
2 - o que fazer com uma parte perdida.
Considere um dos segmentos UDPs gerado por nossa aplicação VoIP.
Fonte da Imagem:
O segmento UDP é encapsulado por um datagrama IP. Enquanto o datagrama vagueia pela rede, ele passa por buffers (filas) nos roteadores, onde
aguarda para ser transmitido em enlaces de saída.
É possível que um ou mais dos buffers na rota entre o remetente e o destinatário estejam lotados e não possam aceitar o datagrama IP. Nesse caso,
o datagrama IP será descartado e nunca chegará à aplicação receptora.
A perda pode ser eliminada enviando os pacotes por TCP (que proporciona transferência de dados con�ável) em vez de por UDP. Contudo, os
mecanismos de retransmissão frequentemente são considerados inaceitáveis para aplicações interativas de áudio em tempo real, como o VoIP,
porque aumentam o atraso fim a fim.
Além disso, por causa do controle do TCP após a perda de pacote, a taxa de transmissão no remetente pode ser reduzida a uma taxa mais baixa do
que a de reprodução no receptor, possivelmente ocasionando inanição no buffer e pausa forçada da aplicação para que o buffer seja recarregado.
Isso pode causar um forte impacto sobre a integridade da voz no receptor. Por essas razões, quase todas as aplicações de VoIP existentes
executam em UDP.
Exemplo
, Por exemplo, o UDP é usado pelo Skype, a não ser que o usuário esteja atrás de um NAT ou de um firewall que bloqueia os segmentos UDP (neste caso, TCP é
usado)., , Porém, perder pacotes talvez não seja tão desastroso quanto se possa imaginar. Na verdade, taxas de perda de pacotes entre 1% e 20% podem ser
toleradas, dependendo de como a voz é codi�cada e transmitida e de como a perda é ocultada no receptor (abordaremos isso daqui a pouco).
A tabela a seguir compila os principais tipos de aplicações e os respectivos requisitos de QoS:
MOTIVAÇÃO PARA A IMPLANTAÇÃO DE QOS EM REDES IP
A motivação para a implantação de QoS em redes IP vem da demanda por aplicações que são sensíveis:
Dessa forma, é necessário prover algum tipo de técnica que busca obter mais do que o serviço de melhor esforço sozinho é capaz de oferecer.
Então, várias técnicas foram propostas para aprimorar o desempenho de uma rede de melhor esforço (ou seja, da internet).
Na camada de aplicação, são aplicadas técnicas que foram criadas para uso na internet de melhor esforço de hoje. São elas:
Bufferização de dados no cliente para contornar o jitter e a variação na taxa de transmissão de dados;
FEC (Forward Error Correction) para recuperação de perda de dados.
Atenção!
, Lembre-se que elas estão em uso exatamente porque a internet oferece, em sua camada de rede, apenas uma única classe de serviço: o melhor esforço (Best
Effort).
MECANISMOS PARA DAR SUPORTE À ENTREGA DE CONTEÚDO DE MULTIMÍDIA
Como estudiosos de redes de computadores, não podemos evitar a pergunta:
Poderia a camada de rede da internet colaborar oferecendo mecanismos para dar suporte à entrega de conteúdo de multimídia?
Como veremos nesta aula, a resposta é, naturalmente, sim!
É importante ressaltar que diversos dos mecanismos de camada de rede que estudaremos para melhorar a QoS ainda precisam ser colocados em prática. Talvez
isso se deva a sua complexidade e ao fato de que as técnicas em nível de aplicação, junto com o serviço de melhor esforço e recursos de rede corretamente
dimensionados (como a largura de banda), podem, de fato, oferecer um serviço de entrega de multimídia de fim a fim “bom o bastante” (mesmo que não seja
perfeito).
A tabela a seguir resume 3 técnicas gerais para oferecer suporte em camada de rede para aplicações de multimídia. Observe:
Veja, a seguir, uma descrição dos mecanismos para dar suporte à entrega de conteúdo de multimídia:
Obtendo o melhor do serviço de melhor esforço
Os mecanismos de camada de aplicação podem ser usados com sucesso em uma rede bem dimensionada onde a
perda de pacotes e o atraso excessivo de fim a fim raramente ocorrem.
Quando são previstos aumentos de demanda, os provedores incrementam, adquirindo novos equipamentos e
estabelecendo novos (e mais velozes) links, largura de banda e capacidade de comutação para continuar a garantir
um desempenho satisfatório com atraso e perda de pacotes.
Serviço diferenciado
Desde os primeiros dias da internet, tem sido previsto que diferentes tipos de tráfego (conforme indicado no campo
de tipo de serviço, TOS – Type of Service, do cabeçalho de pacote IPv4) poderiam ser fornecidos com classes de
serviço diversas emvez de um único serviço de melhor esforço abrangente.
Com o serviço diferenciado, um tipo de tráfego poderia receber prioridade estrita sobre outra classe de tráfego,
quando os dois tipos forem en�leirados em um roteador. Por exemplo, pacotes pertencentes a uma aplicação
interativa em tempo real poderiam ter prioridade sobre outros pacotes por causa de restrições de atraso mais
rigorosas. A introdução do serviço diferenciado na rede exigirá novos mecanismos para marcação de pacotes
(indicando a classe de serviço de um pacote).
Garantias de qualidade de serviço (QoS) por conexão
Com garantias de QoS por conexão, cada instância de uma aplicação reserva explicitamente largura de banda de fim
a fim e, assim, tem um desempenho de fim a fim garantido.
Uma garantia rígida signi�ca que a aplicação receberá sua qualidade de serviço (QoS) requisitada com certeza.
Uma garantia �exível signi�ca que a aplicação receberá sua qualidade de serviço requisitada com alta probabilidade.
Por exemplo, se um usuário quiser fazer uma chamada VoIP do Hospedeiro A para o Hospedeiro B, a aplicação VoIP
do usuário reserva largura de banda explicitamente em cada enlace ao longo de uma rota entre os dois hospedeiros.
Pense, agora, na seguinte pergunta:
Por que o QoS por conexão não teve implementação signi�cativa na internet?
Resposta Correta
1º
Precisamos de um protocolo que, em favor das aplicações, reserve largura de banda do enlace nos caminhos dos remetentes aos destinatários.
2º
Precisamos de novas políticas de escalonamento nas �las do roteador, para que as reservas de largura de banda por conexão possam ser
cumpridas.
3º
Para fazer uma reserva, as aplicações precisam dar à rede uma descrição do tráfego que elas pretendem enviar e a rede precisará regular o tráfego
de cada aplicação para ter certeza de que obedecerá a essa descrição.
Saiba mais!
, Tais mecanismos, quando combinados, exigem software novo e complexo nos hospedeiros e nos roteadores. Devido a isso, o serviço garantido de QoS por
conexão não teve implementação signi�cativa na internet.
DIMENSIONANDO REDES DE MELHOR ESFORÇO
Fonte da Imagem: Winui / Shutterstock
Fundamentalmente, a di�culdade no suporte de aplicações de multimídia surge de seus rigorosos requisitos de desempenho — pouco atraso,
variação de atraso, perda de pacotes e baixa taxa de transmissão de fim a fim — e do fato de que atraso, variação do atraso e perda de pacotes
ocorrem sempre que a rede �ca congestionada.
Uma primeira técnica para melhorar a qualidade das aplicações de multimídia — e que, muitas vezes, pode ser usada para resolver quase qualquer
problema onde os recursos são restritos — é apenas “gastar dinheiro no problema” e, desse modo, evitar disputa por recursos.
No caso da multimídia em rede, isso signi�ca oferecer capacidade de enlace su�ciente, através da rede, para que nunca, ou raramente, ocorra além
de consequentes atrasos e perdas de pacotes. Com capacidade de enlace su�ciente, os pacotes poderiam correr a internet de hoje sem atraso ou
perda nas �las.
PROVISÃO E DIMENSIONAMENTO
Tanto a provisão de largura de banda quanto o dimensionamento de rede são assuntos complexos e vão muito além do que abordaremos nesta aula.
No entanto, vamos falar um pouco deles. Observe:
Provisão de largura de banda
A questão logicamente é quanta capacidade é “su�ciente” para se conseguir esse paraíso e se os custos para
fornecer largura de banda “su�ciente” são práticos do ponto de vista comercial para os provedores.
Quanta capacidade oferecer nos enlaces de rede em determinada topologia para alcançar determinado nível de
desempenho costuma ser conhecida como provisão de largura de banda.
Dimensionamento de redes
A questão ainda mais complicada de como projetar uma topologia de rede (onde posicionar roteadores, como
interconectar roteadores com enlaces e que capacidade atribuir aos enlaces), para alcançar determinado nível de
desempenho de fim a fim, é um problema de projeto de redes que muitas vezes é chamado de dimensionamento de
redes.
Fonte: donatas1205 / Shutterstock
Como oferecer capacidade su�ciente para atender aos requisitos de desempenho de uma aplicação?
Veja a partir de agora as questões que precisam ser resolvidas para que se possa prever o desempenho em nível de aplicação entre duas
extremidades da rede oferecendo, assim, capacidade su�ciente para atender aos requisitos de desempenho de uma aplicação.
MODELOS DE DEMANDA DE TRÁFEGO ENTRE AS EXTREMIDADES DA REDE
Os modelos podem precisar ser especi�cados em dois níveis:
- Nível de chamada (por exemplo, os usuários “chegando” à rede e executando aplicações);
- Nível de pacote (por exemplo, pacotes sendo gerados pelas aplicações em curso).
Observe que a carga de trabalho pode variar com o tempo.
REQUISITOS DE DESEMPENHO BEM DEFINIDOS
Por exemplo, um requisito de desempenho para dar suporte ao tráfego sensível ao atraso (como uma aplicação de multimídia interativa) poderia ser explicado
pela probabilidade de o atraso de fim a fim do pacote ser maior do que um atraso máximo tolerável.
MODELOS PARA PREVER O DESEMPENHO DE FIM A FIM
Nos modelos para prever o desempenho de fim a fim para determinado modelo de carga de trabalho e técnicas para encontrar uma alocação de largura de banda
de custo mínimo que resulte em cumprir todos os requisitos do usuário, os pesquisadores estão ocupados desenvolvendo modelos de desempenho que possam:
- Quanti�car o desempenho para determinada carga de trabalho;
- Criar técnicas de otimização para achar alocações de largura de banda de custo mínimo cumprindo requisitos de desempenho.
Fonte: donatas1205 / Shutterstock
Por que a internet de hoje não dá suporte para o tráfego de multimídia em um nível de desempenho apropriado?
Se fosse dimensionada, sabemos que a internet de melhor esforço de hoje poderia (do ponto de vista da tecnologia) dar suporte para o tráfego de
multimídia em um nível de desempenho apropriado. A internet de hoje não faz isso devido a dois aspectos:
ASPECTO ECONÔMICO
As respostas são principalmente econômicas.
Mas será que os usuários estariam dispostos a pagar a seus provedores o su�ciente para que eles instalassem largura de banda que desse suporte
a aplicações de multimídia por uma internet de melhor esforço?
ASPECTOS ORGANIZACIONAIS
As questões organizacionais talvez sejam ainda mais assombrosas.
Observe que um caminho de fim a fim entre duas extremidades de multimídia passará pelas redes de vários provedores.
De um ponto de vista organizacional, esses provedores estariam dispostos a cooperar (talvez compartilhando receitas) para garantir que o caminho
de fim a fim seja dimensionado devidamente para dar suporte a aplicações de multimídia?
MÚLTIPLAS CLASSES DE SERVIÇO
Fonte da Imagem: Winui / Shutterstock
Talvez a melhoria mais simples no serviço de melhor esforço da internet atual seja dividir o tráfego em classes e fornecer diferentes níveis de serviço
para essas classes.
Veja alguns exemplos:
,
Um provedor poderia querer oferecer uma classe de serviço mais alta para o tráfego de VoIP (sensível ao atraso) ou teleconferência (e cobrar mais por esse
serviço) do que para o tráfego elástico (como e-mail ou HTTP). Como alternativa, um provedor poderia simplesmente querer oferecer uma qualidade de serviço
mais alta para clientes que queiram pagar mais por esse serviço melhorado.
Diversos provedores de acesso residencial, com e sem �o, por celular adotaram esses níveis de serviço em camadas — com assinantes de serviço “platina”
recebendo um serviço melhor do que os assinantes “ouro” ou “prata”.
Já estamos acostumados com diferentes classes de serviço em nossas vidas diárias. Os passageiros de primeira classe em companhias aéreas, por exemplo,
recebem melhor atendimento do que os da classe executiva, que, por sua vez, recebem melhor atendimento do que aqueles que voam na classe econômica.
Os VIPs recebem entrada imediata em eventos, enquanto todos os outros esperam na fila. Os idosos são respeitados em alguns países e recebem assentos de
honrae a melhor comida em uma mesa.
Podemos classi�car as múltiplas classes de serviço em:
Serviço diferencial entre agregações de tráfego
É importante observar que esse serviço diferencial é fornecido entre agregações de tráfego, ou seja, entre classes de
tráfego e não entre conexões individuais.
Por exemplo, todos os passageiros de primeira classe são tratados da mesma forma, sem que qualquer passageiro
da primeira classe receba tratamento melhor do que qualquer outro da mesma classe.
Seguindo os mesmos critérios, todos os pacotes VoIP receberiam o mesmo tratamento dentro da rede, sem depender
da conexão fim a fim à qual pertencem.
Conforme veremos, lidando com um pequeno número de agregações de tráfego em vez de um número grande de
conexões individuais, novos mecanismos de rede exigidos para fornecer um serviço ainda melhor podem ser
mantidos relativamente simples. Os primeiros projetistas da internet claramente tinham essa noção de múltiplas
classes de serviço em mente.
O campo Tipo de Serviço (ToS)
Vamos relembrar o campo Tipo de Serviço (ToS), no cabeçalho IPv4, que é descrito assim:
“O TOS fornece uma indicação dos parâmetros abstratos da qualidade de serviço desejada. Esses parâmetros devem
ser usados para guiar a escolha de parâmetros através de serviço quando um datagrama estiver sendo transmitido
através de uma rede especí�ca. Muitas redes oferecem serviços prioritários, os quais de alguma forma reservam
mais atenção ao tráfego de prioridade alta do que aos outros.” [ISI 1979]
Há três décadas, a visão de fornecer diferentes níveis de serviço a diferentes níveis de tráfego estava evidente. No
entanto, levou um longo período para que pudéssemos perceber essa visão.
Agora, analise a seguinte ilustração:
Temos os seguintes problemas:
1 - Vamos admitir que as velocidades das LANs sejam bem mais altas do que 1Mbits/s e focalizar a �la de saída do roteador R1. É aqui que
ocorrerão atraso e perda de pacotes, se a taxa agregada de envio de H1 e H2 exceder 1Mbits/s.
2 - Vamos supor ainda que uma aplicação de áudio de 1Mbit/s (por exemplo, uma chamada de áudio com qualidade de CD) compartilhe o enlace de
1Mbits/s entre R1 e R2 com uma aplicação de navegação Web HTTP que está baixando uma página Web de H2 para H4. Na Internet de melhor
esforço, os pacotes de áudio e HTTP são misturados na �la de saída de R1 e (em geral) transmitidos na ordem primeiro a entrar/primeiro a sair (FIFO
– First In First Out). Nesse cenário, uma rajada de pacotes da origem HTTP poderia lotar a �la, fazendo pacotes IP de áudio sofrerem atraso
excessivo ou perda por causa do estouro do buffer (�la) em R1.
Como você resolveria esse problema potencial?
Resposta Correta
PRINCÍPIOS DOS MECANISMOS NECESSÁRIOS PARA OFERECER MÚLTIPLAS CLASSES
DE TRÁFEGO
Primeiro princípio do fornecimento de múltiplas classes de serviço
A marcação de pacotes permite que um roteador faça a distinção de pacotes pertencentes a diferentes classes de tráfego. Observe que, embora,
nosso exemplo considere um �uxo concorrente de multimídia e elástico, o mesmo princípio se aplica ao caso em que classes de serviço platina,
ouro e prata são implementadas. Um mecanismo de marcação de pacotes ainda é necessário para indicar a classe de serviço à qual um pacote
pertence.
Fonte da Imagem: Macrovector / Shutterstock
Suponha agora que o roteador saiba que deve dar prioridade a pacotes da aplicação de áudio de 1Mbit/s.
Como a velocidade de saída do enlace é de 1Mbits/s, mesmo que os pacotes HTTP recebam prioridade mais baixa, ainda assim receberão na média
um serviço de transmissão de 0Mbit/s.
Mas o que acontece se a aplicação de áudio começar a enviar pacotes a uma taxa de 1Mbits/s ou mais alta (seja com má intenção, seja devido a
um erro de aplicação)?
Resposta Correta
Segundo princípio do fornecimento de múltiplas classes de serviço
Idealmente, o que se quer é certo grau de isolamento entre classes de tráfego para proteger uma classe da outra. Essa proteção poderia ser
implementada em diferentes locais da rede — em todo e qualquer roteador na primeira entrada na rede ou nos limites da rede entre domínios. Logo,
este é o segundo princípio do fornecimento de múltiplas classes de serviço:
Quando há a necessidade de atender a ambos os princípios, podemos utilizar algumas técnicas. Observe:
Leaky Bucket (Balde Furado)
Ao invés de usar uma disciplina de atendimento com prioridade estrita, existem técnicas para garantir que ambos os princípios sejam atendidos,
como o Leaky Bucket (Balde Furado), mostrado na �gura.
Se a aplicação regulada se comportar mal, mecanismos como o Leaky Bucket executarão alguma ação para evitar que o tráfego de menor prioridade
sofra de inanição (nunca seja atendido).
Figura: Leaky Bucket (Balde Furado). Um �uxo de alta prioridade só pode exceder uma
taxa de�nida por um tempo curto (para evitar a inanição de �uxos
de menor prioridade).
Atenção!
, Existem inúmeras técnicas alternativas ao Leaky Bucket para disciplinar o atendimento de pacotes em �las de roteadores. Na verdade, poderíamos passar todo
um semestre dedicado a uma disciplina que trataria exclusivamente deste assunto. Entretanto, por questões de escopo e limitação de tempo, deixaremos o Leaky
Bucket como o único exemplo.
DIFFSERV
Tendo visto a motivação, os princípios e os mecanismos especí�cos para oferecer múltiplas classes de serviço, vamos encerrar nosso estudo
dessas técnicas com um exemplo: a arquitetura Diffserv (RFC (glossário) 2475).
O Diffserv oferece diferenciação de serviço, isto é, a capacidade de lidar com as diversas classes de tráfego de
diferentes modos na internet de modo escalável.
A necessidade da escalabilidade vem do fato de que centenas de milhares de �uxos simultâneos de tráfego de
origem-destino estarem presentes em um roteador backbone.
Veremos, de modo breve, que essa necessidade é satisfeita ao colocarmos uma funcionalidade dentro do
núcleo da rede com operações de controle mais complexas, sendo implementadas na borda da rede. Assim, há
um possível uso da arquitetura Diffserv (outras variações são possíveis, como descreve o RFC 2475).
A arquitetura Diffserv consiste em dois conjuntos de elementos funcionais:
Funções de borda: classi�cação de pacotes e condicionamento de tráfego
Na borda de entrada da rede (isto é, em um host habilitado para Diffserv que gera o tráfego ou, no primeiro roteador habilitado para Diffserv, pelo qual
o tráfego passa), os pacotes que chegam são marcados. Mais especi�camente, o campo Differentiated Service (DS) (glossário) do cabeçalho do
pacote IPv4 ou IPv6 é de�nido para algum valor [RFC 3260].
Veja um exemplo:
Na �gura, a seguir, os pacotes que estão sendo enviados de H1 para H3 poderiam ser marcados em R1, ao passo que os pacotes enviados de H2
para H4 poderiam ser marcados em R2.
A marca que um pacote recebe identi�ca a classe de tráfego à qual ele pertence. Assim, diferentes classes de tráfego receberão serviços
diferenciados dentro do núcleo da rede.
Figura: Diffserv: Um exemplo simples
Função central: envio
Quando um pacote marcado com DS chega a um roteador habilitado para Diffserv, ele é repassado até seu próximo salto, de acordo com o
comportamento por salto (PHB – Per Host Behavior (glossário)) associado à classe do pacote.
O comportamento por salto in�uencia a maneira pela qual os buffers e a largura de banda de enlace de um roteador são compartilhados entre as
classes de tráfego concorrentes.
Fonte da Imagem: TechnoVectors / Shutterstock
Um dogma crucial da arquitetura Diffserv é que o comportamento por salto do roteador se baseará somente nas marcas dos pacotes, isto é, na
classe de tráfego a que o pacote pertence.
Assim, se os pacotes que estão sendo enviados de H1 para H3 receberem a mesma marca dos que estão sendo enviados de H2 para H4, os
roteadores da rede tratarão esses pacotes como um agregado sem distinguir se eles se originam de H1 ou H2. Por exemplo, R3 não faria nenhuma
distinção entre pacotes de H1 e H2 ao transmiti-los a R4.
Portanto, a arquitetura deserviço diferenciado evita a necessidade de manter o estado do roteador para pares origem–destino individuais. E isso é
uma consideração importante para atender aos requisitos de escalabilidade do Diffserv.
PRIMEIROS PACOTES CLASSIFICADOS
Os pacotes que chegam ao roteador de borda são primeiros classi�cados. Veja como ocorre esse processo:
Saiba Mais
, Existe a função de medição que compara o �uxo de entrada de pacotes com o per�l de tráfego negociado. A decisão de imediatamente remarcar, repassar,
atrasar ou descartar um pacote é uma questão de política determinada pelo administrador da rede e não está especi�cada na arquitetura Diffserv.
COMPORTAMENTO POR SALTO (PHB — PER-HOP BEHAVIOR)
Até aqui examinamos as funções de marcação e regulação da arquitetura Diffserv. O segundo componente fundamental dessa arquitetura envolve o
comportamento por salto (PHB — per-hop behavior) realizado pelos roteadores habilitados para Diffserv. O PHB é de�nido como:
1º
Um PHB pode resultar no recebimento de diferentes desempenhos por diferentes classes de tráfego (isto é, comportamentos de repasse diferentes
que possam ser observados externamente).
2º
Embora um PHB de�na diferenças de desempenho (comportamento) entre classes, ele não determina nenhum mecanismo especí�co para
conseguir esses comportamentos.
3º
As diferenças de comportamento devem ser observáveis e, por conseguinte, mensuráveis.
Saiba Mais
, Desde que os critérios de desempenho observados externamente sejam cumpridos, quaisquer mecanismos de execução e quaisquer políticas de alocação de
buffer/largura de banda podem ser usados., , Por exemplo, um PHB não exigiria que fosse utilizada uma disciplina de en�leiramento de pacotes em particular
(como um en�leiramento prioritário versus um en�leiramento WFQ versus um en�leiramento FCFS) para atingir determinado comportamento., , O PHB é o �m para
o qual os mecanismos de alocação e implementação de recursos são os meios.
Para o Diffserv foram de�nidos dois PHBs:
UM PHB DE REPASSE ACELERADO
Também como conhecido como Expedited Forwarding — EF [RFC 3246], que especi�ca que a taxa de partida de uma classe de tráfego de um roteador deve ser
igual ou maior do que uma taxa con�gurada;
UM PHB DE REPASSE ASSEGURADO
Também conhecido como Assured Forwarding — AF [RFC 2597], que divide o tráfego em quatro classes e garante, a cada classe AF, o fornecimento de alguma
quantidade mínima de largura de banda e de buffer.
A tabela, a seguir, mostra um exemplo do valor do campo DS (TOS) do pacote IP para o PHB de repasse acelerado [RFC 2745].
Saiba mais!
, Expedited Forwarding (EF) - Tipo de PHB que especi�ca que a taxa de partida de uma classe de tráfego de um roteador deve ser igual ou maior do que uma taxa
con�gurada.
MODELO DE SERVIÇO DO DIFFSERV
Vamos encerrar nossa discussão do Diffserv com algumas observações wm relação ao seu modelo de serviço:
1. Ele é disponibilizado dentro de um único domínio administrativo.
O caso mais típico é o do serviço fim a fim que tem de ser con�gurado para vários provedores localizados entre os sistemas �nais comunicantes.
Para prover serviço Diffserv fim a fim, todas os provedores entre o sistemas �nais devem não apenas prover esse serviço mas, acima de tudo,
cooperar e fazer acordos para oferecer aos clientes �nais um serviço verdadeiramente fim a fim.
Sem esse tipo de cooperação, provedores que vendem serviço Diffserv diretamente a clientes terão sempre de se justi�car perante eles dizendo:
2. Se o Diffserv estivesse disponível e a rede trabalhasse apenas sob carga moderada, na maior parte do tempo, não se perceberia nenhuma
diferença entre um serviço de melhor esforço e um serviço Diffserv.
Na verdade, hoje, o atraso fim a fim em geral é dominado pelas taxas de acesso e saltos de roteadores e não por atrasos de �la em roteadores.
Imagine o infeliz cliente do Diffserv que pagou a mais por um serviço diferenciado, mas descobre que o serviço de melhor esforço oferecido por
outros quase sempre apresenta o mesmo desempenho!
Chegou a hora de exercitar o que você aprendeu!
Analise os itens abaixo e, em seguida, faça a relação com suas de�nições.
( ) DIFFSERV
( ) Best Effotr (Melhor Esforço)
( ) Isolamento de tráfego entre
classes de serviço diferentes
1 - É o serviço em que a internet, em sua camada de rede, faz seu melhor esforço para
transportar cada datagrama do remetente ao receptor o mais rapidamente possível, mas não
faz nenhuma promessa sequer sobre a qualidade de serviço (QoS – Quality of Service) a ser
alcançada.
2 - Permite que uma classe de alta prioridade (como o VoIP) não consuma toda a banda,
impedindo uma classe de menor prioridade (como o e-mail) sofra de inanição (seus pacotes
nunca são servidos das �las dos roteadores).
3 - Representa o serviço padrão da Internet que dá suporte à implementação de múltiplas
classes de serviço.
A sequência correta é:
3 −2 −1
1 – 2 - 3
3 − 1 −2
2 – 3 - 1
Justi�cativa
Glossário
HTTP
Hyper Text Transfer Protocol – Protocolo padrão para navegação web da Internet.
RFC
Request For Comments – Documentos de domínio público que de�nem cada padrão/protocolo usado pela Internet. Estes documentos estão gratuitamente
disponíveis na Internet.
DIFFERENTIATED SERVICES (DS)
Campo de cabeçalho que substitui o antigo campo TOS, para dar suporte ao DIFFSERV.
PER HOST BEHAVIOR (PHB)
Uma descrição do comportamento de repasse de um nó Diffserv que possa ser observado e externamente aplicado a um comportamento agregado Diffserv em
particular.