Arquitetura de Redes de Computadores - Aula 9

Prévia do material em texto

Arquitetura de Redes
(Infraestrutura de Redes)
Aula 9 - Equipamentos de rede - Parte 1
INTRODUÇÃO
Uma das funções importantes de algumas implementações de camada de enlace é a transmissão con�ável. Por
transmissão con�ável, entende-se a capacidade de emitir dados ao receptor, de modo a que os dados cheguem
ordenados, livre de perdas e de erros de transmissão.
Nesta aula, estudaremos os principais protocolos de transmissão con�ável. Analisaremos as limitações de alguns e
estudaremos como as soluções mais elaboradas contornam essas limitações.
Em seguida, estudaremos o padrão IEEE 802, abordando sua arquitetura e os respectivos formatos de quadro 802.3
que surgiram desde a publicação da norma. Para cada variação de formato de quadro 802.3 estudados, veremos
exemplos de sistemas operacionais/protocolos que adotam.
OBJETIVOS
Analisar os protocolos de transmissão con�ável;
Veri�car a arquitetura IEEE 802 e os tipos de quadros IEEE 802.3.
PROTOCOLOS DE TRANSMISSÃO CONFIÁVEL
No contexto de redes de computadores, transferência con�ável de dados signi�ca que os dados transferidos possuem
algumas características ao serem entregues ao destinatário:
Antes de iniciar o estudo de protocolos de transferência con�ável, é importante que você mantenha em mente essas
três características.
É importante, também, que você não confunda o conceito de transferência con�ável de dados com a ideia de
segurança em redes de computadores.
Para garantir que você compreenda bem a diferença entre a transferência con�ável de dados e a segurança de dados,
vamos brevemente destacar a diferenças entre os dois conceitos.
Em redes de computadores, os protocolos de transferência con�áveis mais usados são baseados em uma ideia
simples: tudo o que for transmitido pelo nó remetente deve ser con�rmado ou refutado pelo nó destinatário.
Dessa maneira, o remetente saberá o que não foi recebido corretamente e, portanto, precisa ser retransmitido.
Protocolos baseados nessa ideia de con�rmações e transmissões são amplamente conhecidos como protocolos ARQ
(Automatic Repeat reQuest, ou solicitação automática de repetição).
Para implementar protocolos ARQ, o transmissor e o receptor devem ter em mente que o caminho entre os dois é um
meio hostil que pode gerar diversos tipos de empecilhos à transferência con�ável (glossário). Como os erros de
transmissão podem ocorrer tanto sobre os pacotes de dados quanto sobre os ACKs/NACKs, então uma técnica de
detecção de erros pode ser usada (já estudamos essas técnicas em uma aula anterior).
Uma técnica comumente usada é a soma de veri�cação (checksum) adicionadas a campos de cabeçalho, tanto dos
pacotes de dados quanto dos ACKs/NACKs. Assim, ambos os lados conseguem identi�car se o que receberam está
livre de erros.
Vamos fazer uma pausa para re�etir sobre a seguinte questão:
Um ACK/NACK contendo um checksum permite que o transmissor detecte se esses pacotes de retorno estão livres de
erros. Entretanto, se o transmissor detecta, usando o checksum, que o ACK/NACK está corrompido, como ele saberá
se o que foi enviado pelo receptor foi um ACK ou um NACK? Dê a sua opinião.
Resposta Correta
Para facilitar a compreensão, vamos analisar dois exemplos.
Considere o caso em que o último pacote de dados tenha sido corrompido antes de chegar ao receptor, e o NACK
enviado pelo receptor também chega corrompido no transmissor. Suponha que o transmissor, cuidadoso, retransmite o
último pacote de dados que, por sorte, chega íntegro ao receptor. O receptor, que anteriormente havia enviado um
NACK, agora enviará um ACK. Se supormos que o ACK chegará corretamente ao transmissor, então o problema foi
resolvido.
Fonte da Imagem:
Agora suponha um segundo cenário onde o receptor recebe corretamente um pacote e envia ACK ao transmissor.
Imagine que o ACK seja corrompido no caminho até o transmissor. Agora, o transmissor realizará uma retransmissão
do último pacote de dados.
Entretanto, o receptor já havia recebido corretamente um pacote de dados e agora se confundirá achando que está
recebendo um novo pacote, e não uma retransmissão. Felizmente, esse problema é facilmente contornável se o
transmissor incluir mais um campo de cabeçalho nos pacotes enviados: o número de sequência.
Através da checagem do número de sequência, o receptor facilmente identi�ca se um pacote recebido é um novo
pacote ou uma retransmissão.
Fonte da Imagem:
Se o receptor também usar números de sequência para identi�car seus ACKs, então ele pode simpli�car o processo de
con�rmações, eliminando os pacotes NACK.
Por exemplo, suponha que o receptor recebeu um pacote de dados com número de sequência 0, e tenha enviado um
ACK com número de sequência 0 para con�rmar ao transmissor que tudo ocorreu bem.
O transmissor dará seguimento e enviará o próximo pacote de dados, com número de sequência 1. Se esse pacote
chegar corrompido ao receptor, ao invés de enviar um NACK, ele pode retransmitir o ACK 0 para informar ao
transmissor que algo deu errado com o novo pacote, e que a última coisa que foi corretamente recebida foi o pacote 0.
Como o transmissor sempre envia apenas um pacote por vez, e �ca aguardando uma con�rmação, basta que o número
de sequência tenha apenas um único bit.
Dessa forma:
• Dois pacotes seguidos com o mesmo valor binário no número de sequência (exemplo: pacote 1 e depois pacote 1)
equivalem a uma retransmissão;
• Dois pacotes seguidos com número de sequência distintos (exemplo: pacote 1 e depois pacote 0) indicam que o
segundo pacote é um novo pacote de dados.
O CANAL COMUNICAÇÃO TAMBÉM PODE PERDER PACOTES?
Até agora, estudamos como o uso de checksum e de números de sequência, tanto nos pacotes de dados quanto nos
ACKs, permitem criar um protocolo simples de transmissão con�ável que é capaz de contornar problemas de erros de
transmissão tanto no pacote de dados quanto nos ACKs.
Então, vamos analisar um cenário ainda mais real, onde o canal de comunicação também pode perder pacotes.
Para o protocolo de transmissão con�ável que estudamos acima, caso um pacote de dados ou um ACK seja perdido, o
transmissor �cará eternamente aguardando um ACK.
A forma mais comum de contornar esse problema é incluir um temporizador no transmissor.
Cada vez que o transmissor transmite um pacote de dados, ele inicia um temporizador para limitar a espera por um
ACK. Caso o temporizador expire, o transmissor retransmite o pacote de dados (lembre-se, contendo checksum e
número de sequência) e inicia um novo temporizador para aguardar por um ACK.
O temporizador será �nalizado quando o transmissor receber um ACK com o mesmo número de sequência do pacote
para o qual aguarda con�rmação.
O PROBLEMA NO USO DOS TEMPORIZADORES
Um problema de se usar temporizadores é de�nir por quanto o transmissor deve esperar para realizar uma
retransmissão.
Obviamente, é desejável que o transmissor aguarde no mínimo o tempo de um atraso de ida e volta (RTT – Round Trip
Time) entre ele e o destinatário.
Em muitas redes, o atraso de ida e volta é difícil de ser estimado, e, pior, pode variar bastante ao longo do tempo.
Se o transmissor de�nir um temporizador muito longo, ele demorará muito para retransmitir o pacote, o que afetará
negativamente o desempenho.
Por outro lado, se o transmissor de�nir um temporizador curto demais (exemplo: menor do que o RTT), então, ele
realizará retransmissões desnecessárias, já que fará retransmissões antes do tempo necessário para os ACKs
chegarem.
Qual é o mais indicado?
Uma solução comumente usada é ir calculando o RTT médio durante a transmissão de dados. Para isso, o transmissor
calcula o intervalo de tempo entre o momento em que um pacote de dados é enviado e o momento em que o ACK
chega, e calcula uma média ponderada, onde o histórico de medições tem um peso maior, e a última medição feita tem
um peso menor.
O protocolo de transmissão con�ável que estudamos até agora usa números de sequência (pacotes de dados e ACKs)
e checksum (pacote de dados e ACKs), além de temporizadores no transmissor.
Esse protocoloé considerado o tipo mais simples de protocolo ARQ capaz de fornecer transmissão con�ável em redes
reais, que oferecem todo tipo de obstáculo à transmissão con�ável: perda e corrompimento, tanto de pacotes de dados
quanto de ACKs.
Esse protocolo é comumente chamado de protocolo Stop-And-Wait (para e espera). Observe, abaixo, exemplos que
ilustram o funcionamento do protocolo Stop-And-Wait para dois outros cenários, um com perda de um ACK (esquerda)
e outro com temporizador prematuramente expirado (direita).
A grande desvantagem desse protocolo é que o transmissor transmite um único pacote de dados por vez, e, então,
suspende a transmissão para aguardar por um ACK.
Esse comportamento incorre em limitação do desempenho que é diretamente proporcional ao RTT entre o transmissor
e o receptor. Ou seja, quanto maior for o RTT, maior será a porcentagem de tempo que o transmissor passará
aguardando que seu pacote viaje até o destinatário, e que o ACK viaje de volta para con�rmar que tudo ocorreu
conforme o esperado. Observe, abaixo, a ilustração dessa desvantagem.
O transmissor (Tx) inicia a transmissão de um pacote de dados (Rx) no instante t .
Se supormos um pacote de tamanho L = 12000 bits (exemplo: 1500 bytes), e um link com taxa de transmissão de R =
100Mbps, então, o tempo de transmissão do pacote será de L/R = 12.000/100.000.000 = 0.12 milissegundos.
Para não sermos muito pessimistas, vamos supor um valor baixo para RTT: 1 milissegundo.
O tempo total necessário para transmitir e con�rmar um pacote é calculado como RTT + L/R = 1 + 0.12 = 1.12s.
Desse total, o tempo em que o transmissor esteve efetivamente transmitindo dados pela rede foi de 0.12ms.
0
Logo, se de�nirmos a utilização U como sendo a porcentagem de tempo em que o transmissor efetivamente está
transmitindo dados, então, U pode ser calculado como:
Portanto, o transmissor, em um cenário otimista, passa apenas 10.7% do tempo transmitindo dados, e 89.3% do tempo
aguardando pelo retorno do ACK. Um desempenho sofrível!
Dica
, Se considerarmos que protocolos ARQ também podem ser usados na camada de transporte (Na Internet, o TCP!), e que hosts
remotos na Internet se deparam com RTTs acima de 100ms, então, a utilização da rede �cará abaixo 0.12%. Ou seja, um host
�caria mais de 99.88% do tempo parado aguardando a chegada de ACKs, e menos de 0.12% do tempo efetivamente transmitindo
dados. Um desempenho totalmente inviável.
Uma classe de protocolos ARQ denominados protocolos de janelas deslizantes, ou protocolos com paralelismo
(pipeline), buscam melhorar o desempenho através do envio de múltiplos pacotes de dados seguidos mesmo antes
que algum ACK seja recebido, conforme ilustrado na imagem a seguir.
A única alteração de cabeçalhos dos pacotes de protocolos com pipeline em relação ao protocolo Stop-And-Wait é que
o número de sequência não pode mais ser apenas 0 e 1. Isso ocorre porque vários pacotes �cam simultaneamente
pendentes de con�rmação.
Os dois protocolos de transmissão con�ável (protocolos ARQ) com paralelismo mais amplamento conhecidos e
usados são: O Go-Back-N (glossário) (GBN) e o Selective Repeat (SR).
Ambos os protocolos possuem a mesma característica básica: são protocolos ARQ em que o transmissor tem
permissão para transmitir N pacotes de dados seguidos sem esperar por um ACK.
O número de pacotes “viajando pela rede e pendentes de con�rmação” não pode ultrapassar o limite N. Alguns autores
dizem que esses são protocolos de janelas deslizantes com janela do transmissor de tamanho N.
Na imagem, o transmissor emitiu 8 pacotes antes de receber o primeiro ACK. Nesse caso, então, podemos dizer que
N=8, caso o transmissor não tivesse permissão de transmitir mais do que 8 pacotes em pipelining antes de receber um
ACK.
Vamos compreender as diferenças entre os protocolos Go-Back-N e Selective Repeat:
Go-Back-N
Suponha que um pacote com número de sequência 6 enviado pelo transmissor é perdido. Se
a janela do transmissor possui tamanho N=8, então o transmissor transmitirá os pacotes
6,7,8,9,10,11,12 e 13, sem ter recebido o ACK para o pacote 6.
O receptor não receberá o pacote 6 que foi perdido, mas receberá os pacotes 7,8,9,10,11,12
e 13.
Como o receptor Go-Back-N somente é capaz de receber o pacote com o número de
sequência aguardado (6), então, os pacotes com número de sequência de 7 a 13 serão
descartados.
Consequentemente, o transmissor, ao notar que o temporizador do pacote 6 expirou, será
obrigado a retransmitir todos os pacotes de sua janela (de 6 a 13) na esperança de que
dessa vez os pacotes cheguem ao receptor livre de perdas.
Em resumo, o protocolo Go-Back-N é mais e�ciente do que o Stop-And-Wait, pois usa
pipelining, mas não é muito e�ciente para se recuperar de perdas, já que o transmissor
precisa retransmitir todos os pacotes de sua janela.
Selective Repeat
A recuperação de perdas é justamente o ponto em que o protocolo Selective Repeat
(Retransmissão Seletiva) busca melhorar.
Nesse protocolo, o receptor possui janela de recepção maior do que um, ou seja, é capaz de
receber e armazenar no buffer pacotes fora de ordem.
Suponha que um pacote com número de sequência 6 enviado pelo transmissor é perdido. Se
a janela do transmissor possui tamanho N = 8, então, o transmissor transmitirá os pacotes
6,7,8,9,10,11,12 e 13 sem ter recebido o ACK para o pacote 6.
Agora suponha um receptor Selective Repeat com janela de recepção N=8, assim como o
transmissor. O receptor também não receberá o pacote 6, já que este pacote foi perdido.
Porém, ao receber os pacotes 7,8,9,10,11,12 e 13 fora de ordem (pois o 6 não chegou), o
receptor não os descarta. Ao contrário, os pacotes com número de sequência de 7 a 13 são
armazenados no Buffer do receptor.
Quando o temporizador do transmissor Selective Repeat expirar, ele precisará retransmitir
apenas o pacote de número 6.
Claramente, o protocolo Selective Repeat é capaz de se recuperar de perdas de maneira
mais e�ciente do que o Go-Back-N.
ARQUITETURA IEEE 802 E OS TIPOS DE QUADROS IEEE 802.3
A arquitetura IEEE (glossário) 802 especi�ca um modelo de 3 camadas para as redes locais. Essas camadas
correspondem basicamente às camadas 1 e 2 do modelo ISSO/OSI, conforme mostrado na tabela abaixo.
O IEEE 802 (OSI como referência) e suas tecnologias de subcamada LLC, MAC e de camada física
O LLC tem como objetivo proporcionar diversos serviços da camada de enlace, por exemplo:
No exemplo abaixo, um quadro 802.3 é apresentado com destaque aos bytes de sincronização, e depois o quadro
802.3 é detalhado.
Em seguida, mostramos um quadro 802.2 encapsulado em um quadro 802.3, conforme especi�cado na norma IEEE
802.
Para efeitos de sincronização, o quadro 802.3 se inicia com uma sequência de 8 bytes: 7 bytes contendo 10101010
(preâmbulo), que são usados para sincronização entre as interfaces transmissora e receptora, seguido de um byte
conhecido por SFD (“Start Frame Delimiter”) contendo 10101011, que permite aos receptores detectarem o início
efetivo do quadro.
Os quadros 802.3 usam um cabeçalho de 14 bytes:
• 6 bytes para o endereço de origem;
• 6 bytes para o endereço de destino;
• 2 bytes contendo o comprimento em bytes do campo de dados.
Após o campo de dados, pode existir o campo PAD que é adicionado para que o quadro tenha o comprimento mínimo
exigido (512 bits, ou seja, 64 bytes). Por �m, o campo FCS (Frame Check Sequence) é usado para veri�cação de erros
de transmissão.
Os formatos de quadro IEEE 802.3/802.2 não são meticulosamente seguidos por todos os sistemas operacionais. Em
muitos casos, o quadro a trama 802.3 é diretamente usado, como é, é o caso do TCP/IP (glossário) e IPX.
TIPOS DE QUADROS
Há quatro tipos de quadros podem existir em uma rede Ethernet:
Quadro Ethernet II
Também conhecido como quadro DIX (Digital; Intel; Xerox), é o quadro padrão usado por
redes TCP/IP.
Consequentemente, é o tipo mais comum atualmente.
Campo EthetType (Tpo) é usado para multiplexar/identi�car o protocolo da camada superior.
Por exemplo, o protocolo IP possui Ethertype= 80 e o ARP possui Ethertype = 806.
Quadro 802.3 RAW
Corresponde ao uso de um quadro 802.3 “cru” que não especi�ca nenhuma forma de
multiplexar/identi�car protocolos da camada superior.
Esse formato foi inicialmente usado por redes Novel/Netware com o protocolo IPX, mas caiu
em desuso atualmente.
Quadro 802.2/802.3
Corresponde à aplicação correta da norma IEEE 802, ou seja, o encapsulamento de um
quadro 802.2 em um quadro 802.3.
O quadro LLC – Logical Link Control (802.2) tem como principal objetivo de�nir um
mecanismo de multiplexagem que permita que vários protocolos de cama superior usem,
simultaneamente, o mesmo nó da rede. Assim, a cada protocolo é atribuído um valor único
de SAP, o que evita con�itos entre protocolos.
Para isso, o quadro 802.2 adiciona ao quadro 802.3:
• Os campos DSAP (Service Access Point de destino) de 1 byte;
• SSAP (Service Access Point de Origem) de 1 byte;
• Control de 1 byte.
Esse formato é usado por versões mais atuais de redes IPX/SPX. Por exemplo, o protocolo
IPX atual usa o SAP de valor E0.
Um dos problemas desse formato é que o número de bytes do cabeçalho é ímpar (17 bytes),
o que gera di�culdades de implementações em equipamentos com arquitetura de 32 bits.
Além disso, o SAP de 1 byte é muito limitado, pois só é capaz de identi�car 255 protocolos
diferentes.
Para contornar essas limitações, criou-se uma variação denominada Ethernet SNAP (Sub-
Network Access Protocol).
Quadro Ethernet SNAP (Sub-Network Access Protocol)
Obedece ao formato da norma IEEE 802, mas adiciona mais um campo conhecido por
SNAPID de 5 bytes, que garante o alinhamento de 32 bits do cabeçalho.
Para manter total coerência com o IEEE 802, quadros "Ethernet SNAP" usam sempre os
valores de SAP “AA”, que foi reservado para identi�car quadros SNAP.
O campo SNAPID é dividido em duas subpartes, os 3 bytes mais signi�cativos identi�cam a
organização, e é denominado OUI (Organizational Unit Identi�er). Esse campo atualmente
não é usado, com uma exceção ao protocolo AppleTalk.
Os dois octetos menos signi�cativos identi�cam o protocolo, usando valores idênticos ao
EtherType do “Ethernet II”.
O sistema operacional MAC OS usa encapsulamento IEEE 802.2 LLC SAP/SNAP para a suíte
de protocolos Appletalk v2 sobre redes Ethernet (“EtherTalk”).
ATIVIDADES
Para �nalizarmos esta aula, responda as atividades a seguir.
1. Explique como protocolos ARQ de janelas deslizantes (paralelismo/pipeline) contornam o problema de baixa taxa de
transmissão do protocolo Stop-And-Wait.
Resposta Correta
2. Comente sobre a diferença do método de recuperação de perdas entre o Go-Back-N e o Selective Repeat.
Resposta Correta
Glossário
EMPECILHOS À TRANSFERÊNCIA CONFIÁVEL
• Pacotes de dados (transmissor->receptor) podem ser perdidos;
• ACKs (receptor->transmissor) podem ser perdidos;
• Pacotes de dados (transmissor->receptor) podem ser corrompidos por erros de transmissão (exemplo: interferência
eletromagnética);
• ACKs/NACKs (receptor->transmissor) podem ser corrompidos por erros de transmissão (exemplo: interferência
eletromagnética).
GO-BACK-N
No protocolo Go-Back-N, o receptor não é capaz de receber pacotes fora de ordem. Em outras palavras, a janela do receptor
possui tamanho 1.
O receptor Go-Back-N mantém uma variável indicando o número de sequência do pacote esperado, e, caso receba algum pacote
com número de sequência diferente do esperado, o pacote é simplesmente descartado.
IEEE
Institute of Electrical and Electronic Engineers (Instituto de Engenheiros Eletricistas e Eletrônicos).
IP
Internet Protocol, Protocolo de Internet, que de�ne formato do cabeçalho, endereçamento IP e fragmentação de datagramas.