Protocolos de Rede

CAMADAS DA ARQUITETURA TCP/IP

Telnet FTP SMTP DNS FTP SNMP RPC APLICAÇÃO

TCP UDP TRANSPORTE

ICMP IP REDE

Hardware ENLACE
ARP RARP
Interface DE DADOS
Protocolo de controle ICMP
ICMP: Internet Control Message Protocol

 usado por computadores e

roteadores para troca de Tipo Código descrição
informação de controle da 0 0 echo reply (ping)
camada de rede 3 0 dest. network unreachable
 error reporting: host, rede,
3 1 dest host unreachable
3 2 dest protocol unreachable
porta ou protocolo
3 3 dest port unreachable
 echo request/reply (usado
3 6 dest network unknown
pela aplicação ping) 3 7 dest host unknown
 transporte de mensagens: 4 0 source quench (congestion
 mensagens ICMP control - not used)
transportadas em 8 0 echo request (ping)
datagramas Ip 9 0 route advertisement
 ICMP message: tipo, código, 10 0 router discovery
mais primeiros 8 bytes do 11 0 TTL expired
datagrama IP que causou o erro 12 0 bad IP header
Protocolo IP
 EXEMPLO DAS CAMADAS
Processo do
Usuário (Dados Protocolo
CLIENTE FTP SERVIDOR FTP APLICAÇÃO
da Aplicação) FTP

Kernel Protocolo
TCP TCP TRANSPORTE
(Comunicação TCP
de Dados)

Protocolo REDE
IP IP
IP

Protocolo ENLACE
Driver Ethernet Driver Ethernet
Ethernet DE DADOS

Rede Ethernet
Composição do Pacote de Dados
Transmitido
APLICAÇÃO APLICAÇÃO
DADOS
DADOS PDU

INFORMAÇÃO

TRANSPORTE HEADER TRANSPORTE

DADOS
SEGMENTO TCP TCP PDU

INFORMAÇÃO

REDE HEADER HEADER REDE

DATAGRAMA IP DADOS PDU
IP TCP

INFORMAÇÃO

ENLACE DE DADOS HEADER HEADER HEADER TRAILER ENLACE DE

QUADRO DADOS DADOS PDU
QUADRO IP TCP QUADRO
Denominação das PDU em cada camada

Rede
Ambiente dos protocolos da camada de rede
Funções Da Camada De Rede
 Transportar pacotes entre os aplicação
sistemas finais da rede transporter
ede
enlace
 A camada de rede deve ter uma fisica
rede
rede enlace rede
entidade em cada sistema final enlace fisica enlace
fisica fisica
ou roteador da rede
rede
enlace
Funções importantes: fisica rede
enlace
fisica
Estabelecimento de conexão: rede
algumas arquiteturas de rede rede
enlace
enlace
fisica
exigem o estabelecimento de fisica

circuitos virtuais antes da rede

enlace aplicação
transmissão de dados. fisica transporte
rede
enlace
fisica
Comutação: mover pacotes entre as
portas de entrada e de saída dos
roteadores.
Funções Da Camada De Rede

Funções importantes: aplicação

transporter
ede
 Determinação de caminhos: rota enlace
rede
fisica
escolhida pelos pacotes entre a rede enlace rede
enlace fisica enlace
origem e o destino. Algoritmos fisica fisica
de roteamento. rede
enlace
fisica rede
enlace
fisica
 Controle de congestionamento: rede
rede
ações para controlar o enlace
enlace
fisica
congestionamento da rede. fisica
rede
enlace aplicação
fisica transporte
rede
enlace
fisica
Estabelecimento de conexão
 Formato do Datagrama IPv4
versão do Protocolo IP 32 bits tamanho total
do datagrama
tamanho do header
ver head. type of lenght
(bytes)
(bytes) len service
Classe de serviço fragment para
16-bit identifier flgs fragmentação/
offset
número máximo time to proto- Internet remontagem
de saltos live col checksum
(decrementado em
32 bit endereço IP de origem
cada roteador)
32 bit endereço IP de destino
Protocolo da camada
superior com dados no Opções (se houver) Ex. timestamp,
datagrama registro de rota
data lista de rotea-
(tamanho variável , dores a visitar.
tipicamente um segmento
TCP ou UDP)
 IP Fragmentação e Remontagem
 enlaces de rede têm MTU
(max.transfer size) - corresponde
ao maior frame que pode ser
transportado pela camada de
enlace. fragmentação
 tipos de enlaces diferentes in: um datagrama grande
out: 3 datagramas menores
possuem MTU diferentes
(ethernet: 1518 bytes)
 datagramas IP grandes devem ser
divididos dentro da rede
(fragmentados) reassembly
 um datagrama dá origem a
vários datagramas
 “remontagem” ocorre apenas no
dedstino final
 O cabeçalho IP é usado para
identificar e ordenar
datagramas relacionados
IP Fragmentação e Remontagem
tamanho ID fragflag offset
=4000 =x =0 =0

Um grande datagrama se torna

vários datagramas menores

tamanho ID fragflag offset

=1500 =x =1 =0

tamanho ID fragflag offset

=1500 =x =1 =1480

tamanho ID fragflag offset

=1040 =x =0 =2960
Modelo Do Serviço De Rede
Q: como escolher um
modelo de serviço para
Nível mais geral
o canal transportando
de abstração na
pacotes da origem ao
camada de rede

? ?
destino?
 Banda-passante garantida? circuito virtual
abstração de serviço

 Preservação dos intervalos ou

?
entre pacotes? datagrama
 Entrega sem perdas?
 Entrega em ordem?
 Realimentação de informação
de congestionamento?
Redes Datagrama: o modelo da Internet
 Não existem conexões na camada de transporte
 Não há informação de estado de conexão nos roteadores
 Não existe conexão na camada de rede
 Pacotes tipicamente transportam o endereço de destino
 Pacotes para o mesmo destino podem seguir diferentes rotas

aplicação
aplicação
transporte
transporte
rede
rede
enlace 1. Envia dados 2. Recebe dados
enlace
fisica
fisica
Sub-rede roteando por datagrama: o modelo da
Internet
Circuitos Virtuais (VC)
“A ligação entre a origem e o destino emula uma
ligação telefônica”
 Orientado ao desempenho
 A rede controla a conexão entre a origem e o destino

 Estabelecimento da conexão deve preceder o envio de dados. Liberação da conexão

após os dados.
 Cada pacote transporte um identificador do CV, não transporta o endereço
completo do destino
 Cada roteador na rota mantém informação de estado para conexão que passa por
ele.
 A conexão de camada de transporte envolve apenas os sistemas finais
 A banda passante e os recursos do roteador podem ser alocado por VC
 Controle de Qualidade de Serviço por VC
Sub-rede roteando por circuito virtual
Circuitos Virtuais: Sinalização

 Usado para estabelecer, manter e encerrar

Circuitos Virtuais
 Usados em ATM, Frame-Relay e X-25, mas não na
Internet

aplicação
6. Recebe Dados aplicação
transporte 5. Inicia Fluxo de dados
rede 4. Call connected 3. Accept call transporte
rede
enlace 1. Call Request 2. incoming call
enlace
fisica
fisica
Modelos de Serviço da Camada de Rede:
Parâmetros Garantidos
Arquitetura Modelo de Realim. de
de Rede Serviço Banda Perda Ordem Tempo Congestão

Internet melhor não não não não não (examina

esforço perdas)
ATM CBR taxa sim sim sim não há
constante congestão
ATM VBR taxa sim sim sim não há
garantida congestão
ATM ABR mínimo não sim não sim
garantido
ATM UBR não não sim não não

 Novos serviços na Internet: Intserv, Diffserv

Datagrama versus Circuito Virtual
Internet ATM
 Dados trocados entre  Originário da telefonia
computadores
 Conversação humana:
 Serviço elástico, requisitos
de atraso não críticos  Tempos estritos,
 Sistemas finais inteligentes exigências de
 Podem adaptar-se, realizar confiabilidade
controle e recuperação de  Necessário para serviço
erros garantido
 A rede é simples, a
 Sistemas finais “burros”
complexidade fica nas pontas
 Telefones
 Muitos tipos de enlaces
 Características diferentes  Complexidade dentro da

 Difícil obter um serviço rede

uniforme
Comutação de pacotes
Comutação de pacotes
Protocolos de roteamento
Roteamento
Protocolo de Roteamento
OBJ: determinar “bons” caminhos 5
(seqüência de roteadores) através da
rede da fonte ao destino. 3
B C 5
2
A 2 1 F
3
1 2
D E
1

 “bons” caminhos:
 tipicamente corresponde
aos caminhos de menor
custo
 caminhos redundantes
Roteamento Hierárquico
Problemas do mundo real
 roteadores não são todos idênticos
 as redes não são “flat” na prática

Escala: com milhões de Autonomia Administrativa

destinos:  Internet = rede de redes
 Não é possível armazenar todos
 Cada administração de rede
os destinos numa única tabela
de rotas! pode querer controlar o
 As mudanças na tabela de rotas
roteamento na sua própria
rede
irão congestionar os enlaces!
Roteamento Intra-AS e Inter-AS
roteamento Inter-AS
C.b entre A e B
B.a
A.a Host
b A.c c h2
a C a
b
a B
Host d c roteamento Intra-
h1 b
A AS dentro do AS B
roteamento Intra-AS
dentro AS A

AS: Área de serviço

 A camada de rede da Internet
Entidade de rede em roteadores ou hosts:

Camada de Transporte: TCP, UDP

Prot. de roteamento protocolo IP

•escolha de caminhos •endereçamento
•RIP, OSPF, BGP •formato dos datagramas
Camada de •tratamento de pacotes
Rede tabela
de rotas protocolo ICMP
•aviso de erros
•sinalização de rotas

Camada de enlace

Camada física
Controle de congestionamento
 Controle de congestionamento
Quando há pacotes demais presentes em (parte de) uma sub-rede, o desempenho
diminui. Essa situação é chamada congestionamento. A figura ilustra o sintoma.
 Controle de congestionamento
Quando o número de pacotes depositados na sub-rede pelos hosts está dentro
de sua capacidade de transporte, eles são todos entregues (exceto alguns que
sofram com erros de transmissão), e o número entregue é proporcional ao número
enviado.

Entretanto, quando o tráfego aumenta muito, os roteadores já não são capazes de

suportá-lo e começam a perder pacotes. Isso tende a piorar a situação.

No caso de tráfego muito intenso, o desempenho entra em colapso total, e quase

nenhum pacote é entregue.
 Controle de congestionamento
O congestionamento pode ser causado por diversos fatores. Se os fluxos de pacotes
começarem a chegar repentinamente em três ou quatro linhas de entrada e todas
precisarem da mesma linha de saída, haverá uma fila.

Se a memória for insuficiente para conter todos eles, os pacotes se perderão. A

inclusão de mais memória ajudará até certo ponto, mas Nagle (1987) descobriu que,
se os roteadores tiverem um volume infinito de memória, o congestionamento
piorará, e não melhorará pois, no momento em que os pacotes chegarem ao início da
fila, eles já terão sido temporizados (repetidamente) e as duplicatas já terão sido
enviadas.

Todos esses pacotes serão encaminhados com todo cuidado ao roteador seguinte,
aumentando a carga até o destino.
 Controle de congestionamento
Processadores lentos também podem causar congestionamento.

Se as CPUs dos roteadores forem lentas na execução de tarefas administrativas

(enfileiramento de buffers, atualização de tabelas etc.), poderão surgir filas,
mesmo que haja capacidade de linha suficiente.

Da mesma forma, linhas de baixa largura de banda também podem causar

congestionamento.

A atualização das linhas sem a alteração dos processadores, ou vice-versa, sempre

ajuda um pouco, mas com freqüência transfere o gargalo.
 Controle de congestionamento
Diferença entre controle de congestionamento e controle de fluxo:

• O controle de congestionamento se baseia na garantia de que a sub-rede é capaz

de transportar o tráfego oferecido.

É uma questão global, envolvendo o comportamento de todos os hosts, de todos os

roteadores, do processamento de operações store-and-forward dentro dos
roteadores e de todos os outros fatores que tendem a reduzir a capacidade de
transporte da sub-rede.

• Por outro lado, o controle de fluxo se baseia no tráfego ponto a ponto entre um
determinado transmissor e um determinado receptor.

Sua tarefa é garantir que um transmissor rápido não possa transmitir dados
continuamente com maior rapidez do que o receptor é capaz de absorver.

O controle de fluxo quase sempre envolve algum feedback direto do receptor para o
transmissor. Dessa forma, o transmissor fica sabendo como tudo está sendo feito
na outra extremidade.
 Princípios gerais do controle de congestionamento

Muitos problemas em sistemas complexos, como as redes de computadores, podem

ser encarados do ponto de vista da teoria de controle.

Essa abordagem nos leva à divisão de todas as soluções em dois grupos: loops
abertos e loops fechados.

• As soluções para loops abertos tentam resolver o problema com um bom projeto,
basicamente para garantir que eles em princípio não ocorrerão. Uma vez que o
sistema esteja em funcionamento, não serão feitas correções que afetem processos
em andamento.

Entre as ferramentas que controlam loops abertos, encontram-se as que são

empregadas para decidir quando aceitar mais tráfego, para decidir quais pacotes
devem ser descartados e quando isso deve ser feito, e ainda para programar
decisões em vários pontos da rede.

Tudo isso tem em comum o fato de que as decisões serão tomadas sem levar em
conta o estado atual da rede.
 Princípios gerais do controle de congestionamento

Em contraste, as soluções para loops fechados se baseiam no conceito de um loop

de feedback.

Essa estratégia tem três partes, quando aplicada ao controle de congestionamento:

1. Monitorar o sistema para detectar quando e onde ocorre congestionamento.

2. Enviar essas informações para lugares onde alguma providência possa ser tomada.
3. Ajustar a operação do sistema para corrigir o problema.

Várias unidades métricas podem ser usadas para monitorar a sub-rede quanto à
ocorrência de congestionamentos.

As principais são a percentagem de todos os pacotes descartados por falta de

espaço em buffer, a média dos comprimentos de fila, o número de pacotes
interrompidos por alcançarem o tempo limite e que são retransmitidos, o retardo
médio de pacotes e o desvio padrão do retardo de pacote.
Em todos os casos, números crescentes indicam aumento de congestionamento.
 Princípios gerais do controle de congestionamento

A segunda etapa do loop de feedback é transferir informações sobre

congestionamento do ponto em que o fenômeno é detectado para o ponto em que
algo pode ser feito em relação a ele.

A solução mais óbvia é o roteador detectar o congestionamento com a finalidade de

enviar um pacote à origem ou às origens de tráfego, anunciando o problema.

É claro que esses pacotes extras aumentam a carga exatamente no momento em que
não há necessidade de mais carga, ou seja, quando a sub-rede está congestionada.

Entretanto, também existem outras possibilidades. Por exemplo, pode-se reservar

um bit ou um campo em todos os pacotes para que os roteadores o preencham
sempre que o congestionamento superar algum limite inicial.

Quando detecta esse estado de congestionamento, o roteador preenche o campo

em todos os pacotes de saída, a fim de alertar os vizinhos.
 Princípios gerais do controle de congestionamento

Outra abordagem é fazer com que os hosts ou roteadores enviem pacotes de

sondagem periodicamente para perguntar de forma explícita sobre o
congestionamento.

Essa informação pode então ser usada para rotear o tráfego em áreas
problemáticas, tornando possível que os roteadores façam o roteamento de pacotes
de modo a evitar os pontos congestionados.
 Princípios gerais do controle de congestionamento

Existem muitos algoritmos de controle de congestionamento. Para oferecer uma

forma de organizá-los logicamente, Yang e Reddy (1995) desenvolveram uma
taxonomia para algoritmos de controle de congestionamento.

Eles começam dividindo todos os algoritmos em loops abertos ou em loops

fechados, como descrevemos antes.

Depois, dividem os algoritmos de loop aberto em algoritmos que atuam na origem e

em algoritmos que atuam no destino.

Os algoritmos de loop fechado também são divididos em duas subcategorias:

feedback explícito e feedback implícito.

• Em algoritmos de feedback explícito, os pacotes são enviados do ponto de

congestionamento para advertir a origem sobre o problema.

• Em algoritmos de feedback implícito, a origem deduz a existência do

congestionamento fazendo observações locais, como o tempo necessário para
que as confirmações retornem.
 Políticas de prevenção de congestionamento

Políticas adotadas:

• Camada de Transporte
• Política de retransmissão
• Política de cache fora de ordem
• Política de confirmação
• Política de controle de fluxo
• Determinação de timeout
• Camada de Rede
• Circuitos virtuais versus datagramas na sub-rede
• Política de serviço e de enfileiramento de pacotes
• Política de descarte de pacotes
• Algoritmo de roteamento
• Gerenciamento da duração do pacote
• Camada de Enlace de dados
• Política de retransmissão
• Política de cache fora de ordem
• Política de confirmação
• Política de controle de fluxo
 Políticas de prevenção de congestionamento

Controle de congestionamento em sub-redes de circuitos virtuais

Algumas estratégias para controlar dinamicamente o congestionamento em sub-

redes de circuitos virtuais.

• Uma técnica amplamente utilizada para impedir que um congestionamento que já

tenha começado se torne pior é o controle de admissão.

A idéia é simples: uma vez que o congestionamento tenha dado alguma indicação de
sua existência, nenhum outro circuito virtual será estabelecido até que o problema
tenha passado.
 Políticas de prevenção de congestionamento

Controle de congestionamento em sub-redes de circuitos virtuais

• Técnica de controle de admissão.

(a) Uma sub-rede congestionada. (b) Uma sub-rede redesenhada que elimina o
congestionamento. Também está representado um circuito virtual de A até B.
 Políticas de prevenção de congestionamento

Controle de congestionamento em sub-redes de circuitos virtuais

• Outra estratégia relacionada a circuitos virtuais é negociar um acordo entre o

host e a sub-rede quando um circuito virtual for configurado.

Normalmente, esse acordo especifica o volume e a formatação do tráfego, a

qualidade de serviço exigida e outros parâmetros. Para manter essa parte do
acordo, em geral a sub-rede reservará recursos ao longo do caminho quando o
circuito for configurado. Esses recursos podem incluir espaço em tabelas e buffers
nos roteadores, além de largura de banda nas linhas. Dessa maneira, é improvável
que ocorra congestionamento nos novos circuitos virtuais, pois todos os recursos
necessários estarão disponíveis.

Esse tipo de reserva sempre poderá ser feito todo o tempo como procedimento de
operação padrão ou somente quando a sub-rede estiver congestionada. Uma
desvantagem de fazer isso o tempo todo é a tendência a desperdiçar recursos.
 Políticas de prevenção de congestionamento

Controle do congestionamento em sub-redes de datagramas

Agora vamos examinar algumas estratégias que podem ser utilizadas em sub-redes
de datagramas (e também em sub-redes de circuitos virtuais).

Cada roteador pode monitorar facilmente a utilização de suas linhas de saída e de

outros recursos.

Sempre que ultrapassar um limite, a linha de saída entra em um estado de

"advertência".

Cada pacote recém-chegado é conferido para sabermos se sua linha de saída

encontra-se em estado de advertência.

Se estiver, alguma ação será adotada. A ação específica pode ser uma dentre as
várias alternativas que examinaremos em seguida.
 Políticas de prevenção de congestionamento
• O bit de advertência

A antiga arquitetura DECNET assinalava o estado de advertência ativando um bit

especial no cabeçalho do pacote. O mesmo é feito no frame relay. Quando o
pacote chegava a seu destino, a entidade de transporte copiava o bit na próxima
confirmação a ser enviada de volta à origem. Em seguida, a origem interrompia o
tráfego.

Enquanto estivesse no estado de advertência, o roteador continuava a definir o bit

de advertência, e isso significava que a origem continuava a receber informações
com o bit ativado.

A origem monitorava a fração de confirmações com o bit ativado e ajustava sua

velocidade de transmissão de acordo com ele.

Enquanto os bits de advertência continuavam a fluir, a origem continuava a diminuir

sua taxa de transmissão. Quando diminuía a velocidade de chegada das
confirmações, a origem aumentava sua taxa de transmissão.

Observe que, considerando que cada roteador ao longo do caminho podia ativar o bit
de advertência, o tráfego só aumentava quando nenhum roteador tinha problemas.
 Políticas de prevenção de congestionamento
• Pacotes reguladores

Segundo essa abordagem, o roteador enviará um pacote regulador ao host de

origem, informando o destino encontrado no pacote.

O pacote original é marcado (um bit de cabeçalho é ativado) para que ele não venha
a gerar mais pacotes reguladores ao longo do caminho, e depois é encaminhado da
forma habitual.

Ao receber o pacote regulador, o host de origem é obrigado a reduzir em X% o

tráfego enviado ao destino especificado.

Como outros pacotes com o mesmo destino provavelmente já estarão a caminho e

irão gerar ainda mais pacotes reguladores, o host deve ignorar os pacotes
reguladores que se refiram a esse destino por um intervalo de tempo fixo. Depois
que esse tempo houver expirado, o host detectará mais pacotes reguladores para
outro intervalo. Se chegar um pacote, a linha ainda estará congestionada; logo, o
host reduzirá o fluxo ainda mais e começará novamente a ignorar pacotes
reguladores. Se não chegar nenhum outro pacote regulador durante o período de
escuta, o host poderá aumentar o fluxo mais uma vez.
 Políticas de prevenção de congestionamento
O feedback implícito desse protocolo pode ajudar a evitar congestionamento sem
estrangular o fluxo, a menos que ocorra algum problema.

Os hosts podem reduzir o tráfego ajustando seus parâmetros de orientação como,

por exemplo, o tamanho de sua janela.

Em geral, o primeiro pacote regulador faz a taxa de dados se reduzir a 0,50 de seu
valor anterior, o seguinte causa uma redução de 0,25 e assim por diante.

Os aumentos são feitos em incrementos menores para impedir que voltem

rapidamente a ocorrer congestionamentos.

Foram propostas diversas variações desse algoritmo de controle de

congestionamento.

De acordo com uma delas, os roteadores podem manter diversos limiares.

Dependendo do limiar que tiver sido ultrapassado, o pacote regulador poderá conter
uma advertência suave, uma advertência severa ou um ultimato.

Outra variação é o uso de comprimentos de filas ou buffers, em vez de linhas como

sinal para ativar o processo.
 Políticas de prevenção de congestionamento
Pacotes reguladores hop a hop

Em altas velocidades ou em longas distâncias, o envio de um pacote regulador para

os hosts de origem não funciona bem porque a reação é muito lenta.

Uma abordagem alternativa é fazer com que o pacote regulador tenha efeito a cada
hop pelo qual passar.

Aqui, assim que o pacote regulador atinge F, o nó F é solicitado a reduzir o fluxo

para D. Fazendo isso, F terá de dedicar mais buffers ao fluxo, pois a origem ainda
estará transmitindo a plena carga, mas dará alívio imediato a D, como um remédio
para dor de cabeça em um comercial de televisão.

Na etapa seguinte, o pacote regulador atingirá E, o que fará E reduzir o fluxo para
F. Essa ação impõe uma demanda maior sobre os buffers de E, mas proporciona
alívio imediato a F.

Por fim, o pacote regulador atinge A e o fluxo diminui sua velocidade.

 Políticas de prevenção de congestionamento
Pacotes reguladores hop a hop

O efeito líquido desse esquema hop a hop é oferecer alívio rápido no ponto de
congestionamento, ao preço de aumentar o consumo de buffers do fluxo ascendente
(upstream).

Dessa maneira, o congestionamento pode ser cortado pela raiz sem perda de
pacotes.
 Políticas de prevenção
de congestionamento

(a) Um pacote regulador que afeta apenas a

origem.

(b) (b) Um pacote regulador que afeta cada

hop por que passa.
 Políticas de prevenção de congestionamento
Escoamento de carga

Quando nenhum dos métodos anteriores fizer o congestionamento desaparecer, os

roteadores poderão chamar a artilharia pesada: o escoamento de carga.

O escoamento de carga é uma maneira diferente de dizer que, quando os roteadores

estão sendo inundados por pacotes que não podem manipular, eles simplesmente
devem descartá-los.
 Políticas de prevenção de congestionamento
Um roteador que está sendo sufocado com pacotes pode simplesmente selecionar ao
acaso aqueles que deverão ser descartados, mas em geral é possível fazer algo
melhor que isso.

O pacote a ser descartado pode depender das aplicações em execução.

No caso de transferência de arquivos, um pacote antigo compensa mais que um novo,

pois descartar o pacote 6 e manter os pacotes de 7 a 10 causará um intervalo no
receptor que poderá forçar a retransmissão dos pacotes de 6 a 10 (se o receptor
descartar rotineiramente pacotes fora de ordem). Em um arquivo de 12 pacotes,
descartar o pacote 6 pode exigir a retransmissão dos pacotes de 7 a 12, enquanto a
ação de descartar o pacote 10 deve exigir que apenas os pacotes de 10 a 12 sejam
retransmitidos.
 Políticas de prevenção de congestionamento
Em comparação, no caso de multimídia, um novo pacote é mais importante que um
antigo.

A primeira dessas políticas (antigo é melhor que novo) costuma ser chamada política
do vinho, e a segunda (novo é melhor que antigo) é chamada política do leite.

Uma etapa acima dessa em termos de inteligência exige a cooperação dos

transmissores.

No caso de muitas aplicações, alguns pacotes são mais importantes que outros.

Por exemplo, certos algoritmos para compactação de vídeo transmitem

periodicamente um quadro inteiro e depois enviam quadros subseqüentes sob a
forma de diferenças em relação ao último quadro completo. Nesse caso, descartar
um pacote que faz parte de uma diferença é mais interessante que descartar um
pacote que faz parte de um quadro completo.

Como outro exemplo, considere a transmissão de um documento contendo texto

ASCII e figuras. A perda de uma linha de pixels em alguma imagem é muito menos
prejudicial que a perda de uma linha de texto legível.
 Políticas de prevenção de congestionamento
Para implementar uma política de descarte inteligente, as aplicações devem marcar
seus pacotes por classes de prioridade, a fim de indicar qual a importância deles.

Se as aplicações fizerem isso, quando os pacotes tiverem de ser descartados, os

roteadores poderão descartar primeiro os pacotes da classe mais baixa, depois os
da classe mais baixa seguinte e assim por diante.

Uma outra opção é permitir que os hosts excedam os limites especificados no

acordo negociado quando o circuito virtual foi configurado (por exemplo, usar uma
largura de banda mais alta que a permitida), mas fiquem sujeitos à condição de que
todo o tráfego em excesso seja marcado como tráfego de baixa prioridade.
 Políticas de prevenção de congestionamento
Detecção aleatória prematura

É bem conhecido o fato de que lidar com o congestionamento após sua detecção
inicial é mais eficaz do que permitir que o congestionamento se consolide e depois
tentar lidar com ele.

Essa observação nos leva à idéia de descartar pacotes antes que todo o espaço dos
buffers realmente se esgote.

Um algoritmo popular para isso é chamado RED (Random Early Detection —

detecção aleatória prematura) (Floyd e Jacobson, 1993).
 Políticas de prevenção de congestionamento
Detecção aleatória prematura

Em alguns protocolos de transporte (inclusive o TCP), a resposta à perda de pacotes

é tornar a origem mais lenta.

O raciocínio por trás dessa lógica é que o TCP foi projetado para redes fisicamente
conectadas e essas redes são muito confiáveis; assim, a perda de pacotes se deve
muito mais ao estouro de buffers do que a erros de transmissão.

Esse fato pode ser explorado para ajudar a reduzir o congestionamento.

Fazendo os roteadores descartarem pacotes antes que a situação se torne

desesperadora (daí a palavra "prematura" no nome), a idéia consiste em ter tempo
para empreender alguma ação antes de ser tarde demais.

Para determinar quando começar a descartar pacotes, os roteadores mantêm uma

média atualizada dos comprimentos de suas filas.

Quando o comprimento médio da fila em alguma linha excede um limiar, considera-se

que a linha está congestionada e é executada uma ação para solucionar o problema.
 Políticas de prevenção de congestionamento
Detecção aleatória prematura

Tendo em vista que o roteador provavelmente não poderá detectar a origem que
está causando a maior parte do problema, escolher um pacote ao acaso na fila que
disparou a ação deve ser o melhor que ele consegue fazer.

Como o roteador deve fornecer informações à fonte sobre o problema?

Uma alternativa é enviar um pacote regulador, conforme descrevemosantes. Porém,

um problema que surge no caso dessa abordagem é que ela impõe ainda mais carga à
rede já congestionada.

Uma estratégia diferente é simplesmente descartar o pacote selecionado e não

informar sobre o fato. A origem notará eventualmente a falta de confirmação e
executará alguma ação.
 Políticas de prevenção de congestionamento
Detecção aleatória prematura

Como ela sabe que a perda de pacotes em geral é causada pelo congestionamento e
por descartes, a origem responderá diminuindo a velocidade, em vez de continuar a
tentar transmitir com maior intensidade.

Essa forma implícita de feedback só funciona quando as origens respodem à perda

de pacotes reduzindo sua taxa de transmissão.

Em redes sem fios, nas quais a maioria das perdas se deve ao ruído no enlace
aéreo, essa abordagem não pode ser usada.
 Políticas de prevenção de congestionamento
Controle de flutuação

Para aplicações como a transmissão de áudio e vídeo, não importa muito se os

pacotes demoram 20 ms ou 30 ms para serem entregues, desde que o tempo em
trânsito seja constante.

A variação (isto é, o desvio padrão) nos tempos de chegada de pacotes é chamada

flutuação (jitter).

Por exemplo, uma flutuação elevada, na qual alguns pacotes demoram 20 ms e outros
demoram 30 ms para chegar, resultará em uma qualidade irregular do som ou do
filme.

Em contraste, um acordo em que 99% dos pacotes fossem entregues com um

retardo no intervalo de 24,5 ms a 25,5 ms poderia ser aceitável.

É claro que o valor médio escolhido deve ser viável. Ele deve levar em conta o tempo
de trânsito na velocidade da luz e o retardo mínimo na passagem pelos roteadores, e
talvez deixar uma pequena folga para alguns retardos inevitáveis.
 Políticas de prevenção de congestionamento
Controle de flutuação

A flutuação pode ser limitada pelo cálculo do tempo de trânsito esperado para cada
hop ao longo do caminho.

Quando um pacote chega a um roteador, este verifica se o pacote está adiantado ou

atrasado em suas programação. Essas informações são armazenadas no pacote e
atualizadas a cada hop. Se estiver adiantado, o pacote será retido um tempo
suficiente para que seja sincronizado. Se ele estiver atrasado, o roteador tentará
enviá-lo rapidamente.

Na realidade, o algoritmo que define, entre os diversos pacotes que disputam uma
linha de saída, o pacote que deve ser enviado em seguida sempre pode escolher o
pacote que estiver mais atrasado em sua programação.

Dessa forma, pacotes que estão adiantados na programação têm sua velocidade
reduzida, e pacotes que estão atrasados são acelerados; em ambos os casos, essa
ação reduz o volume de flutuação.
 Políticas de prevenção de congestionamento
Controle de flutuação (minimizar o jitter)

(a) Alta flutuação. (b) Baixa flutuação

 Políticas de prevenção de congestionamento
Controle de flutuação

Em algumas aplicações, como vídeo por demanda, a flutuação pode ser eliminada
pelo armazenamento em buffer no receptor, seguido pela busca de dados para
exibição no buffer, e não na rede em tempo real.

No entanto, para outras aplicações, em especial aquelas que exigem interação em

tempo real entre pessoas, como telefonia da Internet e videoconferência, o
retardo inerente do armazenamento em buffer não é aceitável.
 Políticas de prevenção de congestionamento
Qualidade de serviço

As técnicas que examinamos nas seções anteriores foram projetadas para reduzir o
congestionamento e melhorar o desempenho das redes.

Porém, com o crescimento da multimídia em rede, freqüentemente essas medidas ad

hoc não são suficientes.

Há necessidade de empreender tentativas sérias para garantir a qualidade de

serviço por meio do projeto de redes e protocolos.

Mais para afrente, estudaremos alternativas para oferecer uma qualidade de

serviço adequada às necessidades das aplicações.
Obrigado pela atenção !
 IPv6
 Motivação inicial: o espaço de endereços de 32-bits
estará completamente alocado por volta de 2008.
 Motivação adicional:
 melhorar o formato do header para permitir maior velocidade
de processamento e de transmissão
 mudanças no header para incorporar mecanismos de controle
de QOS
 novo tipo de endereço: “anycast” - permite enviar uma
mensagem para o melhor dentre vários servidores replicados
 IPv6 formato dos datagramas:
 cabeçalho fixo de 40 bytes
 não é permitida fragmentação
IPv6
IPv6 Header (Cont)
Priority: permitir definir prioridades diferenciadas
para vários fluxos de informação
Flow Label: identifica datagramas do mesmo “fluxo.”
(conceito de “fluxo” não é bem definido).
Next header: identifica o protocolo da camada superior
ou um header auxiliar
Outras mudanças do IPv4
 Checksum: removido inteiramente para
reduzir o tempo de processamento em cada
hop
 Options: são permitidas, mas são alocadas
em cabeçalhos suplementares, indicados
pelo campo “Next Header”
 ICMPv6: nova versão de ICMP
 tipos de mensagens adicionais , ex. “Packet Too
Big”
 funções de gerenciamento de grupos multicast
Transição do IPv4 para IPv6
 Nem todos os roteadores poderão ser atualizados
simultaneamente
 não haverá um dia da vacinação universal
 A rede deverá operar com os dois tipos de datagramas
simultaneamente presentes
 Duas abordagens propostas:
 Dual Stack: algusn roteadores com pilhas de protocolos
duais (v6, v4) podem trocar pacotes nos dois formatos e
traduzir de um formato para o outro
 Tunneling: IPv6 transportado dentro de pacotes IPv4
entre roteadores IPv4
Dual Stack Approach
Tunneling

IPv6 dentro do IPv4 onde necessário