Mudanças entre as edições de "RCO2-2011-2"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(174 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 13: Linha 13:
 
* Livros sobre Redes de Computadores (por ordem  de preferência):
 
* Livros sobre Redes de Computadores (por ordem  de preferência):
 
** FOROUZAN, Behrouz. '''''Comunicação de Dados e Redes de Computadores, 3a/4a edicão'''''. Editora Bookman, 2004.
 
** FOROUZAN, Behrouz. '''''Comunicação de Dados e Redes de Computadores, 3a/4a edicão'''''. Editora Bookman, 2004.
−
** KUROSE, James F. e ROSS, Keith W. '''''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'''''. Editora Addison wesley SP, 2010..
+
** KUROSE, James F. e ROSS, Keith W. '''''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'''''. Editora Addison Wesley SP, 2010.
 +
** STALLINGS, W. '''''Redes e sistemas de comunicação de dados'''''. Editora Elsevier RJ, 2005.
 
** TANENBAUM, Andrew S. '''''Redes de Computadores, tradução da quarta edição'''''. Editora Campus RJ, 2003
 
** TANENBAUM, Andrew S. '''''Redes de Computadores, tradução da quarta edição'''''. Editora Campus RJ, 2003
 
** GALLO, Michael A. E HANCOCK Wiliam M. '''''Comunicação entre computadores e tecnologia de rede'''''. Ed. Pioneira Thomson Learning SP, 2003.
 
** GALLO, Michael A. E HANCOCK Wiliam M. '''''Comunicação entre computadores e tecnologia de rede'''''. Ed. Pioneira Thomson Learning SP, 2003.
Linha 51: Linha 52:
  
 
== Avaliações ==
 
== Avaliações ==
 +
 +
<!-- '''Obs:''' no caso de conceito parcial D:
 +
* '''''D!''' significa reprovação em definitivo, por frequência insuficiente''
 +
* '''''D?''' significa que pode ser revertido na recuperação''
 +
-->
 +
 +
{| border="1" cellpadding="2"
 +
!Aluno
 +
!1a prova
 +
!Trabalho Protocolo
 +
!2a prova
 +
!3a prova
 +
!Trabalho Switch
 +
!Trabalho LANs
 +
!Trabalho WAN
 +
!4a prova
 +
!Conceito FINAL
 +
|-
 +
|Ana Paula || D/C || C || D/D||D/C ||C|| C|| D|| C||D
 +
|-
 +
|André || D/A|| B||C||B ||A || A|| B|| B+||A
 +
|-
 +
|Bolívar || D/D||D  || D/D||D/D || B||D ||D || D/D||D
 +
|-
 +
|Davi ||D/C || C ||D/C ||B ||B ||A || C||D/C ||C
 +
|-
 +
|Kalvim || B || B ||B ||A || A|| A||B || C+||A
 +
|-
 +
|Leandro || D/? || C? ||C||C ||B || ||D ||D* ||D
 +
|-
 +
|Luiz Gustavo || B || B ||C ||B ||A ||A || B|| B||B
 +
|-
 +
|Maicky || C || C || C||C || A|| A||B ||C+ ||C
 +
|-
 +
|Marine || C || C ||C ||B ||C || B|| C||B+ ||C
 +
|-
 +
|Mário || D/C || C||C ||C || A|| A|| B|| C||C
 +
|-
 +
|Patrícia || D/C || C ||C ||C || B||A || C|| B||C
 +
|-
 +
|Thayse || D/B || C || C||C ||B || A|| C||B ||C
 +
|-
 +
|Thiego || C || C || B||B || A||A || B||B+ ||B
 +
|-
 +
|}
 +
 +
'''Legenda:'''
 +
* ''B?:'' conceito a verificar (apresentação de trabalho)
 +
* ''D/C:'' conceito da recuperação (C neste exemplo)
 +
* ''B+:'' conceito próximo do próximo nível (pode ajudar a decidir o conceito final)
  
 
== Softwares ==
 
== Softwares ==
Linha 160: Linha 211:
 
== 09/08: Detecção de erros ==
 
== 09/08: Detecção de erros ==
  
−
Finalização do laboratório da aula passada:
+
* Ver capítulos 10 e 11 do livro ''Comunicação de Dados e Redes de Computadores'', de Behrouz Forouzan.
−
* Injetar um quadro no enlace PPP (ver roteiro do laboratório da aula passada):
+
* Ver capítulo 5 do livro ''Redes de Computadores e a Internet'', de James Kurose.
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab1/quadro.raw Arquivo com o quadro]
+
* Ver capítulo 4 do livro ''Redes de Computadores'', de Andrew Tanenbaum.
 +
* Resolver a [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista1.pdf 1a lista de exercícios].
  
−
'''Probabilidade de erros de transmissão (BER - Bit Error Rate), códigos de detecção de erro e CRC.'''
+
=== Probabilidade de erros de transmissão (BER - Bit Error Rate), códigos de detecção de erro e CRC ===
  
 
Há um resumo nas [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula2.pdf transparências].
 
Há um resumo nas [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula2.pdf transparências].
Linha 191: Linha 243:
 
O código fonte do gerador de CRC-16 está no arquivo ''fcs-rfc.c'', o qual foi obtido diretamente da [http://tools.ietf.org/html/rfc1662 RFC 1662].
 
O código fonte do gerador de CRC-16 está no arquivo ''fcs-rfc.c'', o qual foi obtido diretamente da [http://tools.ietf.org/html/rfc1662 RFC 1662].
  
−
=== Trabalho do Módulo 1 ===
+
==== Detecção de erros no PPP ====
 +
 
 +
Pode-se testar a detecção e o tratamento de erros do PPP injetando-se quadros com erros em um enlace previamente estabelecido. Isso pode ser verificado usando-se o Netkit:
  
−
O trabalho do primeiro módulo da disciplina trata da implementação de um protocolo de enlace ponto-a-ponto, que deve estabelecer um enlace entre dois computadores por meio de suas portas seriais. O protocolo de enlace deve-se integrar à pilha de protocolos TCP/IP do Linux, podendo assim transmitir e receber datagramas IP.
+
# Crie o arquivo Lab.conf com o seguinte conteúdo: <syntaxhighlight lang=text>
 +
pc1[type]=generic
 +
pc2[type]=generic
  
−
O protocolo de enlace deve prover os seguintes serviços de enlace:
+
pc1[ppp0]=link_serial:ip=10.0.0.1/30
−
# Encapsulamento e enquadramento (requisito mínimo, gerando um  conceito C).
+
pc2[ppp0]=link_serial:ip=10.0.0.2/30
 +
</syntaxhighlight>
 +
# Inicie o experimento do Netkit: <syntaxhighlight lang=bash>
 +
labstart -p teste
 +
</syntaxhighlight>
 +
# Na máquina real faça o download dos [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab1/quadros.tgz arquivos] que contêm quadros PPP especialmente criadaos para esse experimento. Descompacte esse arquivo dentro de ''teste/shared''.
 +
# Note que existe um enlace PPP entre as máquinas virtuais. Na máquina virtual ''pc1'' deixe o tcpdump monitorando a interface ppp0: <syntaxhighlight lang=bash>
 +
tcpdump -i ppp0 -ln
 +
</syntaxhighlight>
 +
# Na máquina virtual ''pc2'' será feita a injeção de quadros PPP no enlace. A ideia é transmitir quadros corretos e em seguida quadros com erros (i.e. com bits propositalmente modificados), e observar como o PPP na máquina virtual ''pc1'' trata esses quadros. Para isso, primeiro deve-se terminar o ''pppd'' em ''pc2'': <syntaxhighlight lang=bash>
 +
killall -9 pppd
 +
</syntaxhighlight>Isso é necessário para que se consigam injetar os quadros via porta serial ''/dev/ttyS0''. Observe que em ''pc'' o ''pppd'' continua rodando como se nada tivesse acontecido (quer dizer, para ''pc1'' o enlace ainda está ativo).<br>
 +
# Injete o quadro correto em ''pc2'', observando o que mostra o ''tcpdump'' em ''pc1'': <syntaxhighlight lang=bash>
 +
cd /hostlab/shared
 +
cat quadro.ok > /dev/ttyS0
 +
</syntaxhighlight>
 +
# Agora injete o quadro com erros e veja o que acontece: <syntaxhighlight lang=bash>
 +
cd /hostlab/shared
 +
cat quadro.erro > /dev/ttyS0
 +
</syntaxhighlight>
 +
# O que se pode concluir quanto à recepção pelo PPP de quadros com erros de transmissão ?
 +
 
 +
=== Trabalho do Módulo 1 ===
 +
 
 +
O trabalho do primeiro módulo da disciplina trata da implementação de um protocolo de enlace ponto-a-ponto, que deve estabelecer um enlace entre dois computadores por meio de suas portas seriais. O protocolo de enlace deve-se integrar à pilha de protocolos TCP/IP do Linux, podendo assim transmitir e receber datagramas IP.
 +
 
 +
O protocolo de enlace deve prover os seguintes serviços de enlace:
 +
# Encapsulamento e enquadramento (requisito mínimo, gerando um  conceito C).
 
# Detecção de erros (opcional, gerando conceito B)
 
# Detecção de erros (opcional, gerando conceito B)
 
# Controle de erros pare-e-espere (opcional, gerando conceito  A)
 
# Controle de erros pare-e-espere (opcional, gerando conceito  A)
Linha 215: Linha 298:
 
Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista1.pdf 1a lista de exercícios].
 
Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista1.pdf 1a lista de exercícios].
  
−
Controle de erros implica '''garantir a entrega de quadros''' no destino. Assim, quadros recebidos com erros (i.e., quadros identificados pela ''detecção de erros'' como corrompidos) ou quadros extraviados (não recebidos) devem ser retransmitidos. Serviço implementado com protocolos do tipo ARQ (''Automatic Repeat Request''), tais como:
+
Mecanismos ARQ para controle de erros:
−
 
 
 
* '''Stop-and-Wait:'''  só transmite o próximo quadro quando receber uma confirmação (''ACK'') do último quadro enviado. Retransmite o último quadro enviado se um tempo máximo de espera pelo ACK (ou ''timeout'') for excedido.
 
* '''Stop-and-Wait:'''  só transmite o próximo quadro quando receber uma confirmação (''ACK'') do último quadro enviado. Retransmite o último quadro enviado se um tempo máximo de espera pelo ACK (ou ''timeout'') for excedido.
 
* '''Go-Back-N:''' transmite até ''N'' quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite todos os quadros a partir desse quadro.
 
* '''Go-Back-N:''' transmite até ''N'' quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite todos os quadros a partir desse quadro.
 
* '''Selective Repeat:''' transmite até ''N'' quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite somente esse quadro.
 
* '''Selective Repeat:''' transmite até ''N'' quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite somente esse quadro.
  
−
A rigor '''Stop-and-Wait ARQ''' já provê controle de erros, porém tem o potencial de causar uma baixa utilização do meio de transmissão. Os outros mecanismos, '''Go-Back-N''' e '''Selective Repeat''', buscam melhorar o aproveitamento do meio, e assim estão também relacionados com o '''controle de fluxo'''. Esse serviço tem duas motivações principais:
+
[[Desempenho_ARQ|Desempenho esperado do Stop-and-Wait]].
−
 
 
−
# Evitar que um transmissor mais rápido sobrecarregue um receptor
 
−
# Melhorar o aproveitamento do meio de transmissão, quando há necessidade de confirmação de quadros e o meio apresentar um atraso de propagação significativo.
 
−
 
 
−
=== Desempenho do Stop-and-wait ===
 
−
 
 
−
O mecanismo Stop-and-wait apresenta desempenho que depende de seus parâmetros e de características físicas do enlace. Para avaliar seu desmepenho, deve-se determinar qual a taxa efetiva de transmissão que pode ser obtida. A taxa efetiva é definida com a razão entre quantidade de bits transmitidos (contidos em um ou mais quadros) e o tempo que foi necessário para que sejam entregues no destino. Quadros são considerados entregues somente quando o transmissor obtém uma confirmação do receptor. Isto não é a mesma coisa que a taxa de bits nominal do enlace, pois essa taxa informa o tempo que o transmissor leva para transmitir cada bit pelo meio de transmissão (ou melhor, o inverso de quanto tempo dura cada bit no meio). A taxa efetiva pode ser calculada descobrindo-se qual é a utilização do meio de transmissão. A utilização é um valor entre 0 e 1 que informa quanto tempo o meio foi de fato utilizado (i.e. quanto tempo o transmissor de fato precisou para transmitir um ou mais quadros), comparado com o tempo total necessário para fazer a entrega  desses quadros. Por exemplo, se o transmissor levou 1 segundo para transmitir um quadro, e depois ficou 1 segundo esperando até receber a confirmação do receptor, a utilização será de 0.5 (o transmissor usou o meio durante 1 segundo, mas o tempo total para entregar o quadro foi de 2 segundos). Assim, as informações necessárias para calcular o desempenho do Stop-and-wait são:
 
−
 
 
−
* '''Taxa nominal de transmissão, ou taxa de bits (''<math>B</math>''):''' razão entre quantidade de bits que saem do transmissor e o tempo que leva para que saiam.
 
−
* '''Tempo de transmissão (''<math>A_{t}</math>''):''' tempo gasto pelo transmissor para transmitir um quadro. É o tempo gasto desde quando o primeiro bit do quadro começa a sair do transmissor, até quando o último bit termina de sair. Esse tempo depende da quantidade de bits transmitidos (''F'') e da taxa de bits nominal do meio (''B''):  <math>A_{t} = F / B</math>
 
−
* '''Atraso de propagação (''<math>A_{p}</math>''):''' tempo gasto pelo sinal para se propagar desde o transmissor até o receptor. Independe da quantidade de bits transmitidos, pois é uma característica física do meio.
 
−
* '''Outros atrasos (<math>A_{o}</math>):''' outros atrasos envolvidos durante a entrega do quadro
 
−
* '''Tempo de envio (<math>A_{e}</math>):''' tempo necessário para que um quadro seja totalmente transmitido do transmissor até o receptor: <math>A_{e} = A_{t} + A_{p}</math>
 
−
* '''Tempo de entrega (''A''):''' tempo necessário para que um quadro seja entregue no receptor, i.e. desde o instante em que o quadro começa a ser transmitido até quando o reconhecimento chega ao transmissor: <br> <math>A = A_{t} + 2A_{p} + A_{t_{ACK}} + A_{o}</math>
 
−
* '''Utilização do meio (''U'')''': razão entre o tempo em que o meio foi de fato usado pelo transmissor para transmitir o quadro, e o tempo total necessário para que o quadro seja considerado entregue: <br><math>U = \frac {A_{t}}{A} = \frac{A_{t}}{A_{t} + 2A_{p} + A_{t_{ACK}}+ A_{o}}</math>
 
−
* '''Taxa efetiva de transmissão (''E''):''' a taxa de bits percebida pelo transmissor para fazer a entrega de quadros: <math>E = B \cdot U</math>
 
−
* '''Timeout (<math>T_{o}</math>):''' tempo máximo de espera por um reconhecimento.
 
−
 
 
−
[[Imagem:Stop-and-wait.png]]
 
  
 
=== Simulações com Omnet++ ===
 
=== Simulações com Omnet++ ===
Linha 248: Linha 311:
 
* [[Omnetpp-Instalacao| Tutorial para instalação do Omnet++ 4.0p1]]
 
* [[Omnetpp-Instalacao| Tutorial para instalação do Omnet++ 4.0p1]]
 
* [[Omnetpp-Instalacao#Rodando_as_simulações_dos_mecanismos_ARQ|Rodando as simulações dos mecanismos ARQ]]
 
* [[Omnetpp-Instalacao#Rodando_as_simulações_dos_mecanismos_ARQ|Rodando as simulações dos mecanismos ARQ]]
 +
 +
== 16/08: NÃO HAVERÁ AULA DE REDES 2 ==
  
 
== 19/08: Controle de erros e de fluxo: Go-back-N e Selective Repeat ==
 
== 19/08: Controle de erros e de fluxo: Go-back-N e Selective Repeat ==
Linha 255: Linha 320:
 
Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Berhouz Forouzan.
 
Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Berhouz Forouzan.
  
 +
* Análise do mecanismo ARQ Stop-and-Wait [http://tele.sj.ifsc.edu.br/~msobral/RCO2/proto.tgz (programas do protocolo ponto-a-ponto para usar no Netkit)]
 
* Análise dos mecanismos ARQ Go-Back-N e Selective Repeat.
 
* Análise dos mecanismos ARQ Go-Back-N e Selective Repeat.
 +
** Uma [http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html simulação com animação do Selective Repeat].
 
* Demonstração da melhoria da utilização do meio usando esse mecanismo, comparado ao Stop-and-Wait.  
 
* Demonstração da melhoria da utilização do meio usando esse mecanismo, comparado ao Stop-and-Wait.  
 
* Uso do simulador Omnet++ 4.01 para avaliar esses os mecanismos ARQ.
 
* Uso do simulador Omnet++ 4.01 para avaliar esses os mecanismos ARQ.
Linha 265: Linha 332:
 
* Quadro ACK atrasado, fazendo com que ocorra um ''timeout'' de espera por confirmação e consequente retransmissão
 
* Quadro ACK atrasado, fazendo com que ocorra um ''timeout'' de espera por confirmação e consequente retransmissão
  
−
Ser eficaz no controle de erros não significa ser '''eficiente'''. Foi visto que se o atraso de propagação for da ordem de grandeza do atraso de transmissão, a utilização do meio se reduz significativamente. Por exemplo, se o atraso de propagação for metade do de transmissão:
+
Ver [[Desempenho_ARQ|ARQ Go-Back-N e Selective-Repeat]].
  
−
<math>U = \frac {A_{t}}{A_{t} + 2A_{p} + A_{t_{ACK}}} = \frac{A_{t}}{A_{t} + 2A_{t}/2 + A_{t_{ACK}}} = \frac{A_{t}}{2A_{t} + A_{t_{ACK}}} < \frac{1}{2}</math>
+
=== Experimento sobre desempenho do protocolo de enlace em um meio sujeito a erros ===
  
−
Já se esses dois atrasos forem iguais:
+
Vale a pena observar qual a diferença entre fazer ou não controle de erros com ARQ em um protocolo de enlace. A experiência a seguir busca dar uma ideia de seus prós e contras.
  
−
<math>U = \frac {A_{t}}{A_{t} + 2A_{p} + A_{t_{ACK}}} = \frac{A_{t}}{A_{t} + 2A_{t} + A_{t_{ACK}}} = \frac{A_{t}}{3A_{t} + A_{t_{ACK}}} < \frac{1}{3}</math>
+
# Obtenha os [http://tele.sj.ifsc.edu.br/~msobral/RCO2/proto.tgz arquivos de programa do protocolo de enlace ponto-a-ponto]
 +
# Descompacte-o em algum diretório, e em seguida entre no subdiretório ''erros''.
 +
# Execute ''labstart'' para iniciar o experimento.
 +
# Em ambas as máquinas virtuais faça o seguinte: <syntaxhighlight lang=bash>
 +
cd /hostlab/shared
 +
./proto /dev/ttyS0 &
 +
ifconfig tun0 10.0.0.1 dstaddr 10.0.0.2
 +
</syntaxhighlight>... apenas invertendo os endereços IP em uma das máquinas virtuais.
 +
# Na máquina virtual ''pc1'' execute: <syntaxhighlight lang=bash>
 +
/etc/init.d/apache2 start
 +
dd if=/dev/urandom bs=4096 of=/var/www/teste.bin count=512
 +
</syntaxhighlight>
 +
# Na máquina virtual ''pc2'' execute o seguinte: <syntaxhighlight lang=bash>
 +
wget http://10.0.0.1/teste.bin
 +
</syntaxhighlight>
 +
# Observe a taxa de bits obtida durante o donwload ...
 +
# Repita o procedimento, porém usando o programa ''proto-sw''.
  
−
E assim, quanto maior for o atraso de propagação, pior será a utilização do meio de transmissão. A raiz do problema está no tempo em que o meio deixa de ser usado por causa do atraso de propagação. Isto também quer dizer que uma certa quantidade de quadros poderia ser transmitida enquanto não chega a confirmação do primeiro quadro. Essa melhoria no ARQ se chama controle de fluxo, pois visa regular a quantidade de quadros que podem ser enviados de acordo com a capacidade do meio de transmissão e do sistema destino. O ARQ mais simples que implementa uma forma de controle de fluxo se chama '''Go-back-N'''.
+
== 23/08: Protocolos PPP e HDLC ==
  
−
'''''Go-back-N''''' transmite até uma certa quantidade de quadros, sem ainda ter recebido uma confirmação do primeiro quadro enviado. À medida que as confirmações forem recebidas, novos quadros podem ser enviados. Esse mecanismo está ilustrado na figura abaixo:
+
* '''Extra:''' ver uma discussão sobre o desempenho dos mecanismos ARQ quando acontecem erros:
 +
** [[Desempenho_ARQ#Utiliza.C3.A7.C3.A3o_do_meio_com_Go-Back-N_sujeito_a_erros|Go-Back-N sujeito a erros]]
  
−
[[Imagem:Go-back-N.png]]
+
=== PPP e HDLC ===
−
<br>''Figura 1: uma possível sequência de transmissão com Go-back-N''
 
  
−
Para controlar a quantidade de quadros enviados usa-se a técnica de janela deslizante. A janela é o conjunto de quadros transmitidos e ainda não confirmados, e que precisam ser lembrados para caso seja necessário retransmiti-los. Assim, sempre que um novo quadro é transmitido aumenta-se o tamanho da janela em uma unidade, e quando um quadro é confirmado diminui-se o tamanho da janela em ao menos uma unidade. Há um tamanho máximo para a janela, que corresponde à quantidade máxima de quadros que podem ser transmitidos sem ter ainda uma confirmação de entrega. Esse tamanho máximo de janela é de grande importância para a eficiência do Go-back-N, pois tem influência direta na utilização máxima que pode ser obtida do meio de transmissão.
+
Detalhes sobre esses protocolos. Ver as transparências:
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-ppp.pdf PPP]
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-hdlc.pdf HDLC]
 +
** [http://www.aiaa.org/spaceops2002archive/papers/SpaceOps02-P-T5-21.pdf Uso do HDLC em missões espaciais (artigo da Nasa)]
  
−
Um controle com janela deslizante precisa que se numerem os quadros sequencialmente, de forma a representar a ordem em que foram enviados. Assim, quadros fora de ordem não são aceitos no destino (ao menos no caso do Go-back-N). Por razões de praticidade, a quantidade de números de sequência necessária para o Go-back-N é igual ao tamanho máximo da janela + 1. Por exemplo, se o tamanho máximo da janela for 3, são necessários no mínimo 4 números de sequência (ex: 0 a 3). Se a quantidade de números de sequência for igual ao tamanho da janela, pode ocorrer um erro no controle de erros do mecanismo (tente descobrir que erro seria esse ...). A figura abaixo ilustra um exemplo em que se fazem transmissões de quadros com janela de tamanho máximo 3 (a janela a cada instante é destacada em amarelo, e os números correspondem aos números de sequência dos quadros):
+
Resolver a [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista2.pdf 2a lista de exercícios].
  
−
[[Imagem:Sliding-window.png]]
+
=== Enlaces ponto-a-ponto entre roteadores ===
  
−
Note que, assim como no Stop-and-wait, os quadros de reconhecimentos indicam qual o próximo quadro a ser aceito pelo destino. Além disso, o Go-back-N aceita reconhecimentos cumulativos. Quer dizer, se houver três quadros na janela de transmissão, e for recebido um reconhecimento relativo ao segundo quadro, o transmissor considera que tanto o primeiro quanto o segundo quadro foram recebidos com sucesso. Isto é possível pois nesse ARQ o receptor aceita apenas quadros em ordem.
+
Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (''throughput'') com cada um dos protocolos.  
  
−
=== Desempenho do Go-back-N ===
+
[[imagem:Rede-modems.png]]
  
−
Mas qual deve ser a utilização do meio de transmissão com o Go-back-N ? Para responder a essa questão devem-se considerar duas situações:
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2011-1.pdf Roteiro da experiência]
 +
* [http://www.cisco.com/warp/cpropub/45/tutorial.htm Tutorial da interface de linha de comando Cisco (CLI)]
 +
* [http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a008019cfa7.shtml#ppp01 Resolução de problemas com PPP em roteadores Cisco]
  
−
# '''O atraso para receber o primeiro ACK é maior ou igual ao tempo de transmissão para enviar todos os quadros permitidos pelo tamanho máximo de janela:''' essa situação está mostrada na figura 1, que mostra uma sequência de transmissão. A utilização nesse caso será:<br><math>U = \frac{N \cdot A_{t}}{A_{t} + 2A_{p} + A_{t_{ACK}}}</math>
+
Esse experimento pode ser reproduzido usando o Netkit. Os comandos dos roteadores Cisco são muito parecidos no software [http://www.quagga.net/ Quagga], que é usado em máquinas virtuais do Netkit que agem como roteadores. No entanto, as interfaces seriais de enlaces ponto-a-ponto no Quagga são identificadas pelos nomes ''ppp0'', ''ppp1'' e assim por diante (ao contrário de ''Serial 0'' e ''Serial 1'' usados no Cisco). Abaixo segue a configuração do Netkit que reproduz o experimento de hoje:
−
# '''O atraso para receber o primeiro ACK é menor que o tempo de transmissão de uma janela de tamanho máximo:''' nesse caso, a utilização é máxima (= 1), pois todo o atraso de propagação é aproveitado para enviar quadros.
 
  
−
Falta ainda ver o que acontece em situações de erro ...
+
<syntaxhighlight lang=text>
 +
# Os três roteadores
 +
r1[type]=router
 +
r2[type]=router
 +
r3[type]=router
  
−
Análise do mecanismo ARQ Selective Repeat. Análise de seu desempenho, comparado ao Stop-and-wait e Go-Back-N.
+
# O computador que fica na subrede da esquerda
−
Análise do desempenho dos mecanismos ARQ na ocorrência de erros. Experiências com um simulador de um enlace ponto-a-ponto.
+
pc1[type]=generic
  
−
=== Selective Repeat ===
+
# O computador que fica na subrede da direita
 +
pc2[type]=generic
  
−
O ARQ Selective Repeat aceita receber quadros fora de ordem, pois o receptor mantém uma janela de recepção com o mesmo tamanho que a janela de transmissão. Assim, o receptor aceita um quadro se seu número de sequência estiver contido na janela de recepção atual. O limite inferior da janela de recepção avança quando chega um quadro com o primeiro número de sequência da janela. Quando o limite inferior da janela avança, os quadros correspondentes são passados para a camada superior. O receptor sempre envia ACKs com o número do quadro que está no início da janela de recepção.
+
# Um computador que representa a Internet
 +
internet[type]=generic
  
−
[[Imagem:Sliding-window-sr.png|800px]]
+
# Os enlaces ponto-a-ponto entre os roteadores
 +
r1[ppp0]=linkEsquerdo:ip=10.0.0.1/30
 +
r1[ppp1]=linkDireito:ip=10.0.0.5/30
 +
r2[ppp0]=linkEsquerdo:ip=10.0.0.2/30
 +
r3[ppp0]=linkDireito:ip=10.0.0.6/30
  
−
O desempenho do Selective Repeat, na ausência de erros, é o mesmo do Go-Back-N.
+
# a subrede do laboratório, que representa a Internet
 +
r1[eth0]=lanExterna:ip=192.168.1.230/24
 +
internet[eth0]=lanExterna:ip=192.168.1.1/24
  
−
=== Utilização do meio com Go-Back-N sujeito a erros ===
+
# A subrede do lado esquerdo
 +
r2[eth0]=lanEsquerda:ip=172.18.0.30/28
 +
pc1[eth0]=lanEsquerda:ip=172.18.0.17/28
  
−
Quando ocorrem erros, o Go-Back-N precisa reenviar todos os quadros da janela de transmissão. Um erro pode acontecer em qualquer quadro da janela de transmissão, sendo que a partir do quadro perdido deve-se esperar um tempo equivalente ao 'timeout'' de espera por reconhecimento. Somente após esse ''timeout'' o transmissor voltará a transmitir, retransmitindo  quadros a partir do quadro perdido. Assim a transmissão de quadros se compõe de conjuntos de quadros transmitidos com sucesso, intercalados por tempos de espera ''timeout'' devido a quadro perdido (i.e. não reconhecido). Para calcular a utilização do Go-Back-N sujeito a erros, algumas simplificações serão assumidas:
+
# A subrede do lado direito
−
# A sequência de quadros transmitidos para fins de análise será longa (idealmente infinita).
+
r3[eth0]=lanDireita:ip=172.18.10.110/28
−
# A sequência de transmissão será modelada como a transmissão sucessiva de conjuntos de quadros, que correspondem às janelas de transmissão.
+
pc2[eth0]=lanDireita:ip=172.18.10.97/28
−
# Cada conjunto de quadros transmitidos será entendido como até N-1 quadros enviados com sucesso seguidos por um quadro perdido, ou N quadros enviados com sucesso. Quando acontece um erro, o transmissor fica bloqueado até que aconteça um  ''timeout'' (prazo de espera pela chegada de reconhecimento).
+
</syntaxhighlight>
  
−
Cada conjunto de quadros apresenta uma certa utilização, que depende do quadro que sofreu erro. A utilização de cada conjunto pode ser calculada da seguinte forma:
+
Note que as rotas não foram definidas ... você precisará criá-las.
−
# ''A utilização na ausência de erros:'' é a utilização já definida anteriormente, que será chamada de <math>U_{N}</math>, sendo calculada com a equação:<br><math>U_N = min(1, \frac{N A_t}{A})</math>
 
−
# ''A utilização no caso da ocorrência de um erro:'' é a utilização resultante de uma sequência de transmissão em que após um certo número de quadros enviados com sucesso acontece um erro, e será chamada de <math>U_{j}</math>. O índice ''j'' se refere a quantidade de quadros enviados com sucesso antes do erro, e varia de 0 a N-1. Essa utilização pode ser calculada com a equação:<br> <math>U_j = min(1, \frac{j A_t}{T_o+j A_t})</math><br><br>... sendo que o parâmetro ''A'' corresponde ao atraso para recepção de um reconhecimento (i.e. <math>A = A_t + 2 A_p + A_{t_{ACK}}</math>), <math>A_t</math> é o atraso de transmissão, <math>A_p</math> é o atraso de propagação e <math>T_o</math> é o timeout de espera por reconhecimento.
 
  
−
A utilização total depende da probabilidade de acontecer cada uma das possíveis utilizações, que variam de <math>U_0</math> a <math>U_{N-1}</math>. Assumindo-se que a probabilidade de um quadro ser entregue sem erro seja dada pela variável <math>P_q</math>, as probabilidades para cada caso são (obs: janela de tamanho N):
+
<!-- === Curiosidade: captura de quadros para análise ===
  
−
{| border="1" cellpadding="2"
+
Para analisar um protocolo em ação, é necessário capturar suas PDUs e interpretá-las. Programas como '''tcpdump''' e '''wireshark''' fazem exatamente isso, oferecendo grande riqueza de detalhes e opções de filtragem de PDUs a serem analisadas. Mas como nada é perfeito, esses programas não possibilitam capturar plenamente quadros de protocolos de enlace que não sejam Ethernet (IEEE 802.3) ou WiFi (IEEE 802.11), devido ao mecanismo de captura que eles usam. Quer dizer, algumas informações dos cabeçalhos dos quadros podem ser descartados. Assim, caso se deseje analisar um protocolo como PPP, deve-se escrever um programa de captura.
−
!Posição do erro
 
−
!Probabilidade
 
−
|-
 
−
|1 || <math>1-P_q</math>
 
−
|-
 
−
|2|| <math>P_q (1-P_q)</math>
 
−
|-
 
−
|3 ||<math>P_q^2 (1-P_q)</math>
 
−
|-
 
−
|N ||<math>P_q^{N-1} (1-P_q)</math>
 
−
|}
 
  
−
O caso especial em que não ocorrem erros tem probabilidade <math>P_q^N</math>.
+
Os quadros capturados precisam ser gravados em um arquivo para posterior análise pelo '''wireshark'''. Segundo a documentação do projeto do '''wireshark''', arquivos de captura devem seguir o [http://wiki.wireshark.org/Development/LibpcapFileFormat formato descrito na ''libpcap''], a biblioteca de captura usada por esse programa. De acordo com a ''libpcap'', esse arquivo tem o seguinte formato:
  
−
Obs: a variável <math>P_q</math> corresponde à probabilidade de que um quadro seja enviado com sucesso, e seu ACK seja recebido pelo transmissor. Ela pode ser calculada assim:
+
[[imagem:Pcap-file.png]]
  
−
<math>P_q = (1 - BER)^{L + L_{Ack}}</math>
 
  
−
... sendo ''L'' o tamanho do quadro em bits, e <math>L_{Ack}</math> o tamanho do quadro ACK também em bits.
+
Como se vê, o arquivo inicia com um cabeçalho global. Em seguida há uma sequência de pares formados pelo cabeçalho de um pacote e seu conteúdo capturado. O formato do cabeçalho global é:
  
−
A utilização total pode ser calculada fazendo-se uma média ponderada das utilizações <math>U_j</math> correspondentes a cada caso. Os pesos a serem usados são as probabilidades definidas acima. A expressão resultante para a utilização pode ser escrita da seguinte forma:
+
<syntaxhighlight lang=c>
−
 
+
typedef struct pcap_hdr_s {
−
<math>
+
        guint32 magic_number;  /* magic number */
−
U = P_q^N \cdot U_N + \sum_{j=0}^{N-1} P_q^j (1-P_q) \cdot U_j
+
        guint16 version_major;  /* major version number */
−
</math>
+
        guint16 version_minor;  /* minor version number */
 +
        gint32  thiszone;      /* GMT to local correction */
 +
        guint32 sigfigs;        /* accuracy of timestamps */
 +
        guint32 snaplen;        /* max length of captured packets, in octets */
 +
        guint32 network;        /* data link type */
 +
} pcap_hdr_t;
 +
</syntaxhighlight>
  
−
A expressão acima se aplica tanto a casos em que a utilização na ausência de erros for 100% (i.e. U = 1), quanto menor que 100% (U < 1).
+
Os cabeçalhos de pacotes são definidos por outra struct:
  
−
==== Atividade ====
+
<syntaxhighlight lang=c>
 +
typedef struct pcaprec_hdr_s {
 +
        guint32 ts_sec;        /* timestamp seconds */
 +
        guint32 ts_usec;        /* timestamp microseconds */
 +
        guint32 incl_len;      /* number of octets of packet saved in file */
 +
        guint32 orig_len;      /* actual length of packet */
 +
} pcaprec_hdr_t;
 +
</syntaxhighlight>
  
−
Experimente comparar a utilização prevista com a expressão deduzida para o Go-Back-N, e o resultado mostrado com o [[Omnetpp-Instalacao#Rodando_as_simulações_dos_mecanismos_ARQ|simulador]]. Teste diferentes valores para tamanho de janela, atraso de propagação, taxa de bits, BER e timeout.
+
Os detalhes de como usar essas estruturas de dados pode ser visto na [http://wiki.wireshark.org/Development/LibpcapFileFormat descrição do arquivo de captura], no site do '''wireshark'''. Um exemplo de como usá-las segue abaixo:
  
−
=== Utilização do meio com Selective Repeat sujeito a erros ===
+
<syntaxhighlight lang=c>
 +
// Cria um arquivo de captura.
 +
//
 +
// char * nome: o nome do arquivo a ser criado
 +
// int snaplen: a quantidade de bytes capturadas em cada pacote
 +
// int link: o tipo de enlace onde foram capturados os pacotes
 +
//
 +
// valor de retorno: o descritor do arquivo aberto (ou NULL em caso de erro)
  
−
'''''(EM REVISÃO ...)'''''
+
FILE * create_pcap_file(char * nome, int snaplen, int link) {
 +
  pcap_hdr_t header;
 +
  FILE * f;
 +
 
 +
  header.magic_number = 0xa1b2c3d4;
 +
  header.version_major = 2;
 +
  header.version_minor = 4;
 +
  header.thiszone = 0;
 +
  header.sigfigs = 0;
 +
  header.snaplen = snaplen;
 +
  header.network = link;
  
−
Na presença de erros, o ARQ Selective Repeat proporciona uma utilização melhor que Go-Back-N. Abaixo segue a utilização obtida com Selective Repeat para os possíveis cenários de erros:
+
  if ((f = fopen(nome, "w")) != NULL) {
 +
    fwrite(&header, sizeof(header), 1, f);
 +
  }
  
−
==== Quando a utilização na ausência de erros for < 1 ====
+
  return f;
 +
}
  
−
Quer dizer, <math>N \cdot A_{t} < A_{t} + 2 \cdot A_{p} + A_{t_{ACK}}</math>. Nesse caso a utilização é a mesma do Go-Back-N:
+
// Grava um pacote no arquivo de captura.
 +
//
 +
// FILE * f: o descritor do arquivo de captura, criado previamente por create_pacp_file
 +
// unsigned char * msg: o buffer que contém os bytes do pacote capturado
 +
// int bytes: a quantidade de bytes capturados
 +
// int snaplen: a quantidade máxima de bytes capturados
  
−
<math>U = N \cdot A_{t} \cdot (\frac{P_{F}}{A_{t} + 2 \cdot A_{p} + A_{t_{ACK}}} + \frac{1 - P_{F}}{T_{o} + A_{t} + 2 \cdot A_{p} + A_{t_{ACK}}})</math>
+
void save_pcap(FILE * f, unsigned char * msg, int bytes, int snaplen) {
 +
  pcaprec_hdr_t header;
 +
  struct timeval tv;
 +
  int maxbytes;
  
−
==== Quando a utilização na ausência de erros for = 1 ====
+
  if (snaplen < bytes) maxbytes = snaplen;
 +
  else maxbytes = bytes;
  
−
Quer dizer, <math>N \cdot A_{t} \geq A_{t} + 2 \cdot A_{p} + A_{t_{ACK}}</math>
+
  gettimeofday(&tv, NULL);
 +
  header.ts_sec = tv.tv_sec;
 +
  header.ts_usec = tv.tv_usec;
 +
  header.incl_len = maxbytes;
 +
  header.orig_len = bytes;
 +
 
 +
  fwrite(&header, sizeof(header), 1, f);
 +
  fwrite(msg, maxbytes, 1, f);
 +
  fflush(f);
 +
}
 +
</syntaxhighlight>
  
−
Há dois casos a analisar:
+
Os valores para ''link'' (tipo de enlace) onde foi realizada a captura são estes:
  
−
# '''Timeout maior que o tempo para enviar uma janela completa:'''<br><math>U = P_{F} + \frac{N \cdot A_{t} \cdot (1 - P_{F})}{T_{o} + A_{t} + 2 \cdot A_{p} + A_{t_{ACK}}}</math>
+
<syntaxhighlight lang=c>
−
# '''Timeout menor que o tempo para enviar uma janela completa:'''<br><math>U = P_{F} + \frac{N \cdot (1 - P_{F})}{N + 1}</math>
+
// Estas definições foram copiadas da biblioteca libpcap
 +
// Coloquei-as aqui para não precisar instalar a biblioteca para
 +
// compilar esse programa, já que ele não a utiliza.
  
−
== 23/08: Protocolos PPP e HDLC ==
+
#define DLT_NULL        0      /* no link-layer encapsulation */
−
 
+
#define DLT_EN10MB      1      /* Ethernet (10Mb) */
−
* Continuação do estudo sobre '''controle de erros''': faltou discutir o desempenho dos mecanismos ARQ quando acontecem erros:
+
#define DLT_EN3MB      2      /* Experimental Ethernet (3Mb) */
−
** [[RCO2-2011-1#Utiliza.C3.A7.C3.A3o_do_meio_com_Go-Back-N_sujeito_a_erros|Go-Back-N sujeito a erros]]
+
#define DLT_AX25        3      /* Amateur Radio AX.25 */
−
** [[RCO2-2011-1#Utiliza.C3.A7.C3.A3o_do_meio_com_Selective_Repeat_sujeito_a_erros|Selective Repeat sujeito a erros]]
+
#define DLT_PRONET      4      /* Proteon ProNET Token Ring */
−
 
+
#define DLT_CHAOS      5      /* Chaos */
−
=== PPP e HDLC ===
+
#define DLT_IEEE802    6      /* IEEE 802 Networks */
−
 
+
#define DLT_ARCNET      7      /* ARCNET, with BSD-style header */
−
Detalhes sobre esses protocolos. Ver as transparências:
+
#define DLT_SLIP        8      /* Serial Line IP */
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-ppp.pdf PPP]
+
#define DLT_PPP        9      /* Point-to-point Protocol */
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-hdlc.pdf HDLC]
+
#define DLT_FDDI        10      /* FDDI */
−
** [http://www.aiaa.org/spaceops2002archive/papers/SpaceOps02-P-T5-21.pdf Uso do HDLC em missões espaciais (artigo da Nasa)]
+
</syntaxhighlight>
 +
-->
 +
 
 +
== 26/08: Enlaces ponto-a-ponto entre roteadores ==
  
−
Resolver a [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista2.pdf 2a lista de exercícios].
+
''(se não conseguirmos concluir a experiência da aula anterior ...)''
  
−
=== Enlaces ponto-a-ponto entre roteadores ===
 
  
 
Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (''throughput'') com cada um dos protocolos.  
 
Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (''throughput'') com cada um dos protocolos.  
−
 
−
[[imagem:Rede-modems.png]]
 
  
 
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2011-1.pdf Roteiro da experiência]
 
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2011-1.pdf Roteiro da experiência]
Linha 400: Linha 541:
 
* [http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a008019cfa7.shtml#ppp01 Resolução de problemas com PPP em roteadores Cisco]
 
* [http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a008019cfa7.shtml#ppp01 Resolução de problemas com PPP em roteadores Cisco]
  
−
=== Curiosidade: captura de quadros para análise ===
+
<!-- === Curiosidade: sockets para camada de enlace ===
  
−
Para analisar um protocolo em ação, é necessário capturar suas PDUs e interpretá-las. Programas como '''tcpdump''' e '''wireshark''' fazem exatamente isso, oferecendo grande riqueza de detalhes e opções de filtragem de PDUs a serem analisadas. Mas como nada é perfeito, esses programas não possibilitam capturar plenamente quadros de protocolos de enlace que não sejam Ethernet (IEEE 802.3) ou WiFi (IEEE 802.11), devido ao mecanismo de captura que eles usam. Quer dizer, algumas informações dos cabeçalhos dos quadros podem ser descartados. Assim, caso se deseje analisar um protocolo como PPP, deve-se escrever um programa de captura.
+
Assim como é possível escrever programas que se comuniquem usando os protocolos UDP, TCP e IP, também se podem criar programas que se comuniquem diretamente usando um protocolo de enlace. Para isso devem-se usar ''sockets'' do tipo AF_PACKET (no Linux ... em outros Unix pode ser diferente), que possibilitam enviar e receber quadros por uma interface de rede.  
  
−
Os quadros capturados precisam ser gravados em um arquivo para posterior análise pelo '''wireshark'''. Segundo a documentação do projeto do '''wireshark''', arquivos de captura devem seguir o [http://wiki.wireshark.org/Development/LibpcapFileFormat formato descrito na ''libpcap''], a biblioteca de captura usada por esse programa. De acordo com a ''libpcap'', esse arquivo tem o seguinte formato:
+
A criação de um socket AF_PACKET pode ser feita da seguinte forma:
  
−
[[imagem:Pcap-file.png]]
+
<syntaxhighlight lang=c>
 +
  int sd;
  
 +
  // criação de um socket do tipo AF_PACKET, por onde se enviam e recebe quadros pela camada
 +
  // de enlace. O parâmetro 0x8888 é o identificador de protocolo da camada superior.
 +
  if ((sd = socket(AF_PACKET, SOCK_DGRAM, htons(0x8888))) < 0) {
 +
    perror("Ao criar o socket");
 +
    return 1;
 +
  }
 +
</syntaxhighlight>
  
−
Como se vê, o arquivo inicia com um cabeçalho global. Em seguida há uma sequência de pares formados pelo cabeçalho de um pacote e seu conteúdo capturado. O formato do cabeçalho global é:
+
Após criado, o socket deve ser vinculado a uma interface de rede. Dessa forma, os quadros enviados sairão por essa interface, e quadros por ela recebidos serão passados para o socket. A vinculação à interface é feita com a função ''bind'', porém usando-se uma ''struct sockaddr_ll'' para especificar a interface e o identificador do protocolo da camada superior. No exemplo abaixo, vincula-se o socket à interface ''eth0''. Além disso, o protocolo de camada superior foi definido pelo número 8888 (esse valor irá aparecer no campo ''ethertype'' dos quadros Ethernet).
  
 
<syntaxhighlight lang=c>
 
<syntaxhighlight lang=c>
−
typedef struct pcap_hdr_s {
+
   // Precisa vincular o socket a uma interface de rede, usando uma "struct sockaddr_ll"
−
        guint32 magic_number;   /* magic number */
+
  addr.sll_family = AF_PACKET;
−
        guint16 version_major; /* major version number */
+
  addr.sll_protocol = htons(0x8888); // apenas um exemplo: protocolo de número 8888
−
        guint16 version_minor; /* minor version number */
+
  addr.sll_ifindex = getif(sd, "eth0"); // descobre o numero da interface de rede
−
        gint32  thiszone;      /* GMT to local correction */
 
−
        guint32 sigfigs;        /* accuracy of timestamps */
 
−
        guint32 snaplen;        /* max length of captured packets, in octets */
 
−
        guint32 network;       /* data link type */
 
−
} pcap_hdr_t;
 
−
</syntaxhighlight>
 
  
−
Os cabeçalhos de pacotes são definidos por outra struct:
+
  if (addr.sll_ifindex < 0) {
 +
    perror("Interface desconhecida !");
 +
    return 1;
 +
  }
  
−
<syntaxhighlight lang=c>
+
  // vincula o socket a interface de rede
−
typedef struct pcaprec_hdr_s {
+
  if (bind(sd, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
−
        guint32 ts_sec;        /* timestamp seconds */
+
    perror("Ao fazer bind");
−
        guint32 ts_usec;        /* timestamp microseconds */
+
    return 1;
−
        guint32 incl_len;       /* number of octets of packet saved in file */
+
  }
−
        guint32 orig_len;       /* actual length of packet */
 
−
} pcaprec_hdr_t;
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
Os detalhes de como usar essas estruturas de dados pode ser visto na [http://wiki.wireshark.org/Development/LibpcapFileFormat descrição do arquivo de captura], no site do '''wireshark'''. Um exemplo de como usá-las segue abaixo:
+
''Obs: a função getif, usada acima para obter o número da interface de rede conforme registrado no sistema operacional, foi implementada da seguinte forma:''
  
 
<syntaxhighlight lang=c>
 
<syntaxhighlight lang=c>
−
// Cria um arquivo de captura.
+
// Obtém o número de uma interface de rede, conforme registrada no sistema operacional
−
//
+
int getif(int sd, char * ifname) {
−
// char * nome: o nome do arquivo a ser criado
+
  struct ifreq ifr;
−
// int snaplen: a quantidade de bytes capturadas em cada pacote
 
−
// int link: o tipo de enlace onde foram capturados os pacotes
 
−
//
 
−
// valor de retorno: o descritor do arquivo aberto (ou NULL em caso de erro)
 
  
−
FILE * create_pcap_file(char * nome, int snaplen, int link) {
+
  strcpy(ifr.ifr_name, ifname);
−
  pcap_hdr_t header;
+
   if (ioctl(sd, SIOCGIFINDEX, &ifr) < 0) {
−
  FILE * f;
+
     perror("interface ???");
−
 
+
    return -1;
−
  header.magic_number = 0xa1b2c3d4;
 
−
  header.version_major = 2;
 
−
  header.version_minor = 4;
 
−
  header.thiszone = 0;
 
−
  header.sigfigs = 0;
 
−
  header.snaplen = snaplen;
 
−
  header.network = link;
 
−
 
 
−
   if ((f = fopen(nome, "w")) != NULL) {
 
−
     fwrite(&header, sizeof(header), 1, f);
 
 
   }
 
   }
−
 
+
   return ifr.ifr_ifindex;
−
   return f;
 
 
}
 
}
 +
</syntaxhighlight>
  
−
// Grava um pacote no arquivo de captura.
+
Tendo o socket criado e vinculado a uma interface, pode-se usá-lo então para enviar e receber quadros.
−
//
 
−
// FILE * f: o descritor do arquivo de captura, criado previamente por create_pacp_file
 
−
// unsigned char * msg: o buffer que contém os bytes do pacote capturado
 
−
// int bytes: a quantidade de bytes capturados
 
−
// int snaplen: a quantidade máxima de bytes capturados
 
  
−
void save_pcap(FILE * f, unsigned char * msg, int bytes, int snaplen) {
+
<syntaxhighlight lang=c>
−
  pcaprec_hdr_t header;
+
  // endreço de destino: broadcast Ethernet
−
  struct timeval tv;
+
  unsigned char dest[6] = {0xff, 0xff,0xff,0xff,0xff,0xff};
−
  int maxbytes;
 
  
−
   if (snaplen < bytes) maxbytes = snaplen;
+
   // Envia 100 quadros
−
  else maxbytes = bytes;
+
  for (i=0; i < 100; i++) {
 +
    int bytes;
 +
    unsigned char msg[SIZE];
  
−
  gettimeofday(&tv, NULL);
+
    // o conteúdo do quadro (payload) está dentro de msg
−
  header.ts_sec = tv.tv_sec;
+
    bzero(msg, SIZE);
−
  header.ts_usec = tv.tv_usec;
+
    strcpy(msg, "12345678910");
−
  header.incl_len = maxbytes;
 
−
  header.orig_len = bytes;
 
−
 
 
−
  fwrite(&header, sizeof(header), 1, f);
 
−
  fwrite(msg, maxbytes, 1, f);
 
−
  fflush(f);
 
−
}
 
−
</syntaxhighlight>
 
  
−
Os valores para ''link'' (tipo de enlace) onde foi realizada a captura são estes:
+
    // endereço físico do destinatário, e identificador de protocolo (ethertype)
 +
    addr.sll_protocol = htons(0x8888);
 +
    addr.sll_halen = 6;
 +
    memcpy(addr.sll_addr, dest, 6); // variável "dest" é um vetor que contém o endereço de destino
  
−
<syntaxhighlight lang=c>
+
    // envia um quadro
−
// Estas definições foram copiadas da biblioteca libpcap
+
    if ((bytes=sendto(sd, msg, 100, 0, (struct sockaddr*)&addr, sizeof(addr))) > 0) {
−
// Coloquei-as aqui para não precisar instalar a biblioteca para
+
      printf("enviados %d bytes ...\n", bytes);
−
// compilar esse programa, já que ele não a utiliza.
+
    }
  
−
#define DLT_NULL        0      /* no link-layer encapsulation */
+
    // espera 1 segundo
−
#define DLT_EN10MB      1       /* Ethernet (10Mb) */
+
    sleep(1);
−
#define DLT_EN3MB      2      /* Experimental Ethernet (3Mb) */
+
  }
−
#define DLT_AX25        3      /* Amateur Radio AX.25 */
+
  close(sd);
−
#define DLT_PRONET      4      /* Proteon ProNET Token Ring */
 
−
#define DLT_CHAOS      5      /* Chaos */
 
−
#define DLT_IEEE802    6      /* IEEE 802 Networks */
 
−
#define DLT_ARCNET      7      /* ARCNET, with BSD-style header */
 
−
#define DLT_SLIP        8      /* Serial Line IP */
 
−
#define DLT_PPP        9      /* Point-to-point Protocol */
 
−
#define DLT_FDDI        10      /* FDDI */
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== 26/08: Enlaces ponto-a-ponto entre roteadores ==
+
Juntando esses pedaços de programa acima, podem-se criar programas de demonstração do uso de sockets de enlace:
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/soft/l2-envio.c Programa de envio]
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/soft/l2-recepcao.c Programa de recepção]
  
−
''(se não conseguirmos concluir a experiência da aula anterior ...)''
+
Para compilá-los:
 +
<syntaxhighlight lang=c>
 +
gcc -o envio l2-envio.c
 +
gcc -o recepcao l2-recepcao.c
 +
</syntaxhighlight>
  
 +
Teste-os rodando o programa de envio em um computador e o de recepção em outro. Eles precisam ser executados com privilégio de administrador, portanto rode-os dentro de máquinas virtuais desta forma:
 +
<syntaxhighlight lang=bash>
 +
sudo ./envio eth0
 +
</syntaxhighlight>
  
−
Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (''throughput'') com cada um dos protocolos.  
+
... e ...
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2011-1.pdf Roteiro da experiência]
+
<syntaxhighlight lang=bash>
−
* [http://www.cisco.com/warp/cpropub/45/tutorial.htm Tutorial da interface de linha de comando Cisco (CLI)]
+
sudo ./recepcao eth0
−
* [http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a008019cfa7.shtml#ppp01 Resolução de problemas com PPP em roteadores Cisco]
+
</syntaxhighlight>
 +
-->
  
−
=== Curiosidade: sockets para camada de enlace ===
+
== 30/08: Aula de revisão ==
  
−
Assim como é possível escrever programas que se comuniquem usando os protocolos UDP, TCP e IP, também se podem criar programas que se comuniquem diretamente usando um protocolo de enlace. Para isso devem-se usar ''sockets'' do tipo AF_PACKET (no Linux ... em outros Unix pode ser diferente), que possibilitam enviar e receber quadros por uma interface de rede.  
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/Prova1-2010-1.pdf Prova do semestre 2010-1]
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova1-2011-1.pdf Prova do semestre 2011-1]
  
−
A criação de um socket AF_PACKET pode ser feita da seguinte forma:
+
Correção das listas 1 e 2.
  
−
<syntaxhighlight lang=c>
+
=== Dúvidas nas listas de exercícios ===
−
  int sd;
+
 
 +
A questão 3 da lista 2 despertou uma dúvida sobre como a utilização e a taxa efetiva variam em função tanto do tamanho da janela quanto da taxa nominal, para um mecanismo ARQ Go-Back-N. Foram plotados dois gráficos para ilustrar a dependência entre elas, mostrados abaixo. Eles foram gerados usando estes valores: quadros de 1500 bytes, atraso de propagação de 5 ms, quadros ACK de 8 bytes.
  
−
  // criação de um socket do tipo AF_PACKET, por onde se enviam e recebe quadros pela camada
+
[[imagem:TaxaEfetiva.png]]<br><br>
−
  // de enlace. O parâmetro 0x8888 é o identificador de protocolo da camada superior.
+
''Taxa efetiva em função do tamanho da janela (N) e da taxa nominal''
−
  if ((sd = socket(AF_PACKET, SOCK_DGRAM, htons(0x8888))) < 0) {
 
−
    perror("Ao criar o socket");
 
−
    return 1;
 
−
  }
 
−
</syntaxhighlight>
 
  
−
Após criado, o socket deve ser vinculado a uma interface de rede. Dessa forma, os quadros enviados sairão por essa interface, e quadros por ela recebidos serão passados para o socket. A vinculação à interface é feita com a função ''bind'', porém usando-se uma ''struct sockaddr_ll'' para especificar a interface e o identificador do protocolo da camada superior. No exemplo abaixo, vincula-se o socket à interface ''eth0''. Além disso, o protocolo de camada superior foi definido pelo número 8888 (esse valor irá aparecer no campo ''ethertype'' dos quadros Ethernet).
 
  
−
<syntaxhighlight lang=c>
+
----
−
  // Precisa vincular o socket a uma interface de rede, usando uma "struct sockaddr_ll"
 
−
  addr.sll_family = AF_PACKET;
 
−
  addr.sll_protocol = htons(0x8888); // apenas um exemplo: protocolo de número 8888
 
−
  addr.sll_ifindex = getif(sd, "eth0"); // descobre o numero da interface de rede
 
  
−
  if (addr.sll_ifindex < 0) {
 
−
    perror("Interface desconhecida !");
 
−
    return 1;
 
−
  }
 
  
−
  // vincula o socket a interface de rede
+
[[imagem:Utilizacao.png]]<br><br>
−
  if (bind(sd, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
+
''Utilização em função do tamanho da janela (N) e da taxa nominal''
−
    perror("Ao fazer bind");
+
 
−
    return 1;
+
== 02/09: Introdução à camada física ==
−
  }
 
−
</syntaxhighlight>
 
  
−
''Obs: a função getif, usada acima para obter o número da interface de rede conforme registrado no sistema operacional, foi implementada da seguinte forma:''
+
Ver capítulos 3, 4 e 5 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
  
−
<syntaxhighlight lang=c>
+
Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-fisica.pdf transparências].
−
// Obtém o número de uma interface de rede, conforme registrada no sistema operacional
 
−
int getif(int sd, char * ifname) {
 
−
  struct ifreq ifr;
 
  
−
  strcpy(ifr.ifr_name, ifname);
 
−
  if (ioctl(sd, SIOCGIFINDEX, &ifr) < 0) {
 
−
    perror("interface ???");
 
−
    return -1;
 
−
  }
 
−
  return ifr.ifr_ifindex;
 
−
}
 
−
</syntaxhighlight>
 
  
−
Tendo o socket criado e vinculado a uma interface, pode-se usá-lo então para enviar e receber quadros.
+
'''A camada física: camada mais baixa da arquitetura de redes'''
  
−
<syntaxhighlight lang=c>
+
[[imagem:Osi-tcpip.png]]
−
  // endreço de destino: broadcast Ethernet
 
−
  unsigned char dest[6] = {0xff, 0xff,0xff,0xff,0xff,0xff};
 
  
−
  // Envia 100 quadros
 
−
  for (i=0; i < 100; i++) {
 
−
    int bytes;
 
−
    unsigned char msg[SIZE];
 
  
−
    // o conteúdo do quadro (payload) está dentro de msg
+
'''Serviços da camada física:'''
−
    bzero(msg, SIZE);
+
 
−
    strcpy(msg, "12345678910");
+
[[Imagem:Servicos-Camada-Fisica.png|600px]]
 +
<br>''(Adaptado do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Berhouz Forouzan)''
  
−
    // endereço físico do destinatário, e identificador de protocolo (ethertype)
+
=== Transmissão digital ===
−
    addr.sll_protocol = htons(0x8888);
 
−
    addr.sll_halen = 6;
 
−
    memcpy(addr.sll_addr, dest, 6); // variável "dest" é um vetor que contém o endereço de destino
 
  
−
    // envia um quadro
+
* Transmissão serial síncrona x assíncrona
−
    if ((bytes=sendto(sd, msg, 100, 0, (struct sockaddr*)&addr, sizeof(addr))) > 0) {
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2009-2.pdf Experiência para comparar esses dois tipos de transmissão serial]
−
      printf("enviados %d bytes ...\n", bytes);
 
−
    }
 
  
−
    // espera 1 segundo
+
== 06/09: 1a avaliação ==
−
    sleep(1);
 
−
  }
 
−
  close(sd);
 
−
</syntaxhighlight>
 
  
−
Juntando esses pedaços de programa acima, podem-se criar programas de demonstração do uso de sockets de enlace:
+
Foi realizada [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova1-2011-1.pdf esta avaliação].
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/soft/l2-envio.c Programa de envio]
 
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/soft/l2-recepcao.c Programa de recepção]
 
  
−
Para compilá-los:
+
== 09/09: Modems ==
−
<syntaxhighlight lang=c>
 
−
gcc -o envio l2-envio.c
 
−
gcc -o recepcao l2-recepcao.c
 
−
</syntaxhighlight>
 
  
−
Teste-os rodando o programa de envio em um computador e o de recepção em outro. Eles precisam ser executados com privilégio de administrador, portanto rode-os dentro de máquinas virtuais desta forma:
+
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista3-2010-1.pdf 3a lista].
−
<syntaxhighlight lang=bash>
+
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula5-modems.pdf transparências] sobre modems.
−
sudo ./envio eth0
 
−
</syntaxhighlight>
 
  
−
... e ...
+
[[imagem:Modelo-comunicacao.png]]
  
−
<syntaxhighlight lang=bash>
 
−
sudo ./recepcao eth0
 
−
</syntaxhighlight>
 
  
−
== 30/08: Introdução à camada física ==
+
Existem diversas tecnologias para criar enlaces ponto-a-ponto de longa distância. Inicialmente estudaremos enlaces criados com modems síncronos, por ser muito comum ainda de ser implantado. Esse tipo de enlace faz uso de pares metálicos tipicamente usados em redes telefônicas, e por isso foram a primeira solução usada em larga escala. Deve-se ter em mente que quando surgiu a necessidade de enlaces de dados de longa distância, a única opção que havia (e a mais barata, justamente por já existir) era a rede telefônica. Assim, toda uma geração de equipamentos de comunicação de dados foi criada para usar o tipo de circuito provido em redes telefônicas, e o tipo de fiação nela utilizada.
  
−
Não houve aula: apresentação dos pré-projetos de TCC
+
'''Questão para pesquisa:''' ''atualmente como são implantados os circuitos de dados de longa distância, e como eles se relacionam com a rede telefônica ?''
  
−
== 02/09: Aula de revisão ==
+
[[imagem:Rede-ier-wan.png]]
  
−
Correção das listas de exercícios 1 e 2.
+
==== Atividade ====
  
 +
# Realizar a [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3.pdf experiência com modems síncronos], em que se configuram modems SHDSL ([http://www.sj.ifsc.edu.br/~msobral/RCO2/manuais/Guia_DT2048_SHDSL_T_E_S_VG_210.5088.00-1.pdf Manual modem DT2048 SHDSL]).
 +
# Pesquisar qual a codificação usada no modem SHDSL (publicar aqui mesmo na wiki):
 +
#* Taxas de bit suportadas
 +
#* Frequência de portadora
 +
#* Tipo de codificação usada (inclua um diagrama para exemplificar)
 +
#* Níveis de tensão usados no sinal
  
−
== 06/09: Introdução à camada física ==
+
== 12/09: Modems digitais ==
−
 
 
−
Ver capítulos 3, 4 e 5 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
 
−
 
 
−
Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula3-fisica.pdf transparências].
 
  
 +
...continuando a aula anterior.
  
−
'''A camada física: camada mais baixa da arquitetura de redes'''
+
== 16/09: Enlaces de teste em modems ==
  
−
[[imagem:Osi-tcpip.png]]
+
* Finalizar a [[RCO2-2011-1#Atividade_4|experiência da aula passada]].
 +
* Para hoje: como testar circuitos com modems
 +
** Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula6-modems-analogicos.pdf transparências].
 +
** [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/lab5-2010-2.pdf Roteiro do experimento]
  
 +
=== Atividade em aula ===
  
−
'''Serviços da camada física:'''
+
Vamos criar uma tabela com informações sobre os códigos de linha/modulações usados em diversas tecnologias. Devemos descobrir a técnica de modulação ou codificação, as taxas de bit suportadas, frequências de portadoras, níveis de sinal (amplitude), alcance de transmissão e tipo de meio de transmissão suportados. Além disso, deve-se identificar a aplicação de cada uma dessas tecnologias.
  
−
[[Imagem:Servicos-Camada-Fisica.png|600px]]
+
* Interface digital V.35
−
<br>''(Adaptado do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Berhouz Forouzan)''
+
* Interface digital RS-232
 +
* PHY Ethernet 10 Mbps, 100 Mbps, 1 Gbps e 10 Gbps
 +
* Modems SHDSL
 +
** [http://www.dsl-broadband-isp.com/about-shdsl/shdsl-faq SHDSL Faq]
 +
** [http://www.broadband-forum.org/marketing/download/mktgdocs/SHDSL_wp.pdf SHDSL White Paper]
 +
* Modems aDSL
 +
* Modems VDSL
 +
* PLC (Power Line Communication)
 +
* CATV (links de dados via TV a cabo)
 +
* Modems V.92 (acesso discado)
 +
* CAN (um tipo de rede industrial)
 +
* HPNA (tecnologia para redes domésticas): ver [http://www.artigos.com/artigos/exatas/tecnologia/uso-da-tecnologia-hpna-como-alternativa-para-comunicacao-entre-dispositivos-com-interface-ethernet-13798/artigo/ artigo] indicado pelo Davi.
  
 +
Obs: veja os modems de alguns fabricantes:
 +
* [http://www.datacom.ind.br/new/taxonomy/term/45 datacom]
 +
* [http://www.rad.com/20/First-Mile-Local-Loop/2489/ RAD]
 +
* [http://www.digitel.com.br/pt/produtos/default.asp Digitel]
 +
* [http://www.cianet.ind.br/ Cianet]
  
−
=== Dúvidas nas listas de exercícios ===
 
  
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/Prova1-2010-1.pdf Prova do semestre 2010-1]
+
{| border="1" cellpadding="2"
 +
!Tecnologia
 +
!Modulação/Codificação
 +
!Taxa de bits
 +
!Alcance (m)
 +
!Meio físico
 +
!Aplicação
 +
|-
 +
|CATV (Docsis 3.0) || QAM-64 down / QPSK up || até 304 Mbps down / 122 up || ??? || HFC (Coaxial + Fibra) || Acesso
 +
|-
 +
|SHDSL || TC-PAM || 64 kbps a 2.3 Mbps|| 6,5 km a 3,8 km||fios telefonia|| Acesso
 +
|-
 +
|HDSL || 2B1Q || 2048 kbps|| ||fios telefonia|| Acesso
 +
|-
 +
|ADSL2+ || DMT + QAM|| até 20 Mbps|| ||fios telefonia|| Acesso
 +
|-
 +
|PLC/BPL || OFDM || || ||fios elétricos|| Acesso,rede local
 +
|-
 +
|HPNA || FD-QAM || || ||fios telefonia/coaxial|| Rede residencial
 +
|-
 +
|V.92 || QAM/TCM || 56 kbps up/28.8 kbps down|| ||fios telefonia|| Acesso
 +
|}
  
−
Foram corrigidas algumas questões das listas 1 e 2.
+
<!-- === Tarefa individual ===
  
−
A questão 3 da lista 2 despertou uma dúvida sobre como a utilização e a taxa efetiva variam em função tanto do tamanho da janela quanto da taxa nominal, para um mecanismo ARQ Go-Back-N. Foram plotados dois gráficos para ilustrar a dependência entre elas, mostrados abaixo. Eles foram gerados usando estes valores: quadros de 1500 bytes, atraso de propagação de 5 ms, quadros ACK de 8 bytes.
+
A tarefa individual a seguir faz parte da avaliação do segundo módulo da disciplina.
  
−
[[imagem:TaxaEfetiva.png]]<br><br>
+
Fazer uma  pesquisa sobre a codificação de linha/modulação usadas em aDSL2+. O texto deve explicar as características elétricas do sinal gerado na  linha, a codificação ou modulação adotadas, e quaisquer outras estruturações que porventura existam no sinal; explore o uso de diagramas para ilustrar as informações apresentadas. Por fim, deve descrever também os protocolos de enlace usados e a sequência de encapsulamentos realizada desde o computador do usuário (o cliente aDSL2+) até o roteador na operadora.
−
''Taxa efetiva em função do tamanho da janela (N) e da taxa nominal''
 
  
 +
Sua pesquisa deve conter:
 +
* Um resumo (ou ''abstract''), com no máximo 10 linhas, informando o que está contido no texto.
 +
* Uma introdução, contendo a contextualização do serviço aDSL (quando  foi criado, a quem se destina,  e qual o princípio tecnológico) e indicando que informações serão apresentadas no  texto.
 +
* Uma seção sobre a codificação ou modulação usada no  aDSL
 +
* Uma seção sobre  os protocolos de enlace utilizados, incluindo os encapsulamentos efetuados desde o cliente aDSL e o roteador na operadora.
 +
* Uma conclusão
 +
* A bibliografia utilizada (com referências no texto).
  
−
----
+
'''Entrega: 15/04/2011'''
 +
-->
  
 +
== 20/09: Modems analógicos e Interfaces digitais ==
  
−
[[imagem:Utilizacao.png]]<br><br>
+
Ver capítulo 5 e 6 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
−
''Utilização em função do tamanho da janela (N) e da taxa nominal''
 
  
−
== 09/09: 1a avaliação ==
+
Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula6-modems-analogicos.pdf transparências sobre modems analógicos].
  
−
Foi realizada [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova1-2011-1.pdf esta avaliação].
+
Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula5-modems.pdf transparências sobre interfaces digitais].
  
 +
Um [[Interfaces_Digitais_IER|catálogo de interfaces digitais]] feito pela turma do curso Técnico em 2011-1.
  
−
== 13/09: Modems ==
 
  
−
Estamos um pouco atrasados ... mas acho que contei feriados a mais no semestre, então teremos tempo !
+
Durante a aula serão feitas experiências sobre interfaces digitais V.35 e RS-232c.
  
−
=== Transmissão digital ===
+
* [http://en.wikipedia.org/wiki/List_of_device_bandwidths Tabelas de taxas de transmissão de diferentes tecnologias]
 +
* [http://www.best-microcontroller-projects.com/how-rs232-works.html Interface RS-232]
 +
* [http://docstore.mik.ua/univercd/cc/td/doc/product/atm/l2020/l2020r21/clicard/planning/cabling.htm Cabos e pinagens de diversas interfaces digitais]
  
−
Faltou essa experiência aula passada, que pode ser feita rapidamente:
+
[[imagem:Rede-ID.png]]
−
* Transmissão serial síncrona x assíncrona
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3-2009-2.pdf Experiência para comparar esses dois tipos de transmissão serial]
 
  
−
=== Agora sim, modems ===
+
=== Códigos de linha ===
  
−
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista3-2010-1.pdf 3a lista].
+
Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista4-2010-1.pdf 4a lista de exercícios].
−
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula5-modems.pdf transparências] sobre modems.
 
−
 
 
−
Existem diversas tecnologias para criar enlaces ponto-a-ponto de longa distância. Inicialmente estudaremos enlaces criados com modems síncronos, por ser muito comum ainda de ser implantado. Esse tipo de enlace faz uso de pares metálicos tipicamente usados em redes telefônicas, e por isso foram a primeira solução usada em larga escala. Deve-se ter em mente que quando surgiu a necessidade de enlaces de dados de longa distância, a única opção que havia (e a mais barata, justamente por já existir) era a rede telefônica. Assim, toda uma geração de equipamentos de comunicação de dados foi criada para usar o tipo de circuito provido em redes telefônicas, e o tipo de fiação nela utilizada.
 
−
 
 
−
'''Questão para pesquisa:''' ''atualmente como são implantados os circuitos de dados de longa distância, e como eles se relacionam com a rede telefônica ?''
 
−
 
 
−
[[imagem:Rede-ier-wan.png]]
 
−
 
 
−
==== Atividade ====
 
−
 
 
−
# Realizar a [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab3.pdf experiência com modems síncronos], em que se configuram modems SHDSL ([http://www.sj.ifsc.edu.br/~msobral/RCO2/manuais/Guia_DT2048_SHDSL_T_E_S_VG_210.5088.00-1.pdf Manual modem DT2048 SHDSL]).
 
−
# Pesquisar qual a codificação usada no modem SHDSL (publicar aqui mesmo na wiki):
 
−
#* Taxas de bit suportadas
 
−
#* Frequência de portadora
 
−
#* Tipo de codificação usada (inclua um diagrama para exemplificar)
 
−
#* Níveis de tensão usados no sinal
 
−
 
 
−
== 16/09: Enlaces de teste em modems ==
 
−
 
 
−
* Finalizar a [[RCO2-2011-1#Atividade_4|experiência da aula passada]].
 
−
* Para hoje: como testar circuitos com modems
 
−
** Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula6-modems-analogicos.pdf transparências].
 
−
** [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/lab5-2010-2.pdf Roteiro do experimento]
 
−
 
 
−
== 20/09: Códigos de linha ==
 
−
 
 
−
Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista4-2010-1.pdf 4a lista de exercícios].
 
  
 
Ver capítulos 3 e 4 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
 
Ver capítulos 3 e 4 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
Linha 728: Linha 826:
 
** [http://www.youtube.com/watch?v=p1xSolqJ9ZI Vários códigos de linha básicos]
 
** [http://www.youtube.com/watch?v=p1xSolqJ9ZI Vários códigos de linha básicos]
  
−
=== Atividade ===
+
<!-- === Trabalho coletivo ===
  
−
Pesquisar os códigos de linha usados em:
+
Após ver um conjunto de tecnologias de enlace e de camada física, devem existir questões como "afinal, quais tecnologias são usadas de fato atualmente, e quais as apostas para o futuro próximo ?". Para responder a essa pergunta propõe-se um trabalho coletivo de pesquisa para criar uma tabela dessas tecnologias junto com algumas outras informações:
−
* V.35
 
−
* RS-232
 
−
* Ethernet 10 Mbps, 100 Mbps, 1 Gbps e 10 Gbps
 
−
* SHDSL
 
−
** [http://www.dsl-broadband-isp.com/about-shdsl/shdsl-faq SHDSL Faq]
 
−
** [http://www.broadband-forum.org/marketing/download/mktgdocs/SHDSL_wp.pdf SHDSL White Paper]
 
−
* aDSL
 
−
* VDSL
 
  
−
=== Tarefa individual ===
+
* Que protocolos de enlace estão envolvidos ?
 +
* Qual a codificação ou modulação usada ?
 +
* Em que tipo de circuito é usada (incluindo o tipo de meio de transmissão) ?
 +
* Que equipamentos são necessários (incluindo os modelos) ?
 +
* Quais as taxas de bits nominais e BER que proporcionam ?
 +
* Qual o custo do enlace ?
 +
* Empresa de onde obteve a informação ?
  
−
A tarefa individual a seguir faz parte da avaliação do segundo módulo da disciplina.
+
Os resultados da pesquisa devem ser colocados aqui mesmo na Wiki.
 +
-->
  
−
Fazer uma  pesquisa sobre a codificação de linha/modulação usadas em aDSL2+. O texto deve explicar as características elétricas do sinal gerado na  linha, a codificação ou modulação adotadas, e quaisquer outras estruturações que porventura existam no sinal; explore o uso de diagramas para ilustrar as informações apresentadas. Por fim, deve descrever também os protocolos de enlace usados e a sequência de encapsulamentos realizada desde o computador do usuário (o cliente aDSL2+) até o roteador na operadora.
+
== 23/09: Redes locais ==
  
−
Sua pesquisa deve conter:
+
* Correção de exercícios das listas 3 e 4.
−
* Um resumo (ou ''abstract''), com no máximo 10 linhas, informando o que está contido no texto.
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova2-2010-2.pdf 2a avaliação de 2010-2]
−
* Uma introdução, contendo a contextualização do serviço aDSL (quando  foi criado, a quem se destina,  e qual o princípio tecnológico) e indicando que informações serão apresentadas no  texto.
 
−
* Uma seção sobre a codificação ou modulação usada no  aDSL
 
−
* Uma seção sobre  os protocolos de enlace utilizados, incluindo os encapsulamentos efetuados desde o cliente aDSL e o roteador na operadora.
 
−
* Uma conclusão
 
−
* A bibliografia utilizada (com referências no texto).
 
  
−
'''Entrega: 15/04/2011'''
+
=== Introdução a redes locais ===
 +
* Transparências:
 +
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula7.pdf Introdução]
 +
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula8.pdf LANs e acesso ao meio]
 +
* Capítulo 13 do livro "''Comunicação de Dados e Redes de Computadores''", de Berhouz Forouzan (tem no xerox)
 +
* Capítulo 15 do livro "Redes e sistemas de comunicação de dados",  de William Stallings.
 +
* Capítulo 4 do livro "''Redes de Computadores''", de Andrew Tanenbaum (tem na biblioteca)
  
−
=== Conceitos da 1a avaliação ===
+
=== Distinção entre WAN, MAN e LAN ===
  
−
== 23/09: Modems analógicos e Interfaces digitais ==
+
* Aplicações de cada um desses tipos de rede
 +
* Tecnologias envolvidas
 +
* "Backbones" da Internet Brasileira:  
 +
  
−
Ver capítulo 5 e 6 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).
+
''Algumas redes WAN:''
 +
* Brasil em [http://www.cgi.br/publicacoes/artigos/backbone-brasil.htm 1996]
 +
* RNP [http://www.rnp.br/_media/backbone/bkb_mapa1991.png 1991],[http://www.rnp.br/_media/backbone/bkb_mapa1994.png 1992],[http://www.rnp.br/_media/backbone/bkb_mapa1996.png 1996], [http://i116.photobucket.com/albums/o34/almeidaris/1998.gif 1998],[http://www.rnp.br/_media/backbone/bkb_mapa2000.png 2000],[http://i116.photobucket.com/albums/o34/almeidaris/2001.gif 2001],[http://i116.photobucket.com/albums/o34/almeidaris/2005.jpg 2005],[http://i116.photobucket.com/albums/o34/almeidaris/2006.jpg 2006], [http://i116.photobucket.com/albums/o34/almeidaris/2007.jpg 2007].
 +
* Embratel [http://www.embratel.com.br/Embratel02/images/secoes/11/07/951/MG_40_10_20_mapa1.jpg Mapa 1],[http://www.embratel.com.br/Embratel02/images/secoes/11/07/951/MG_40_10_20_mapa2.jpg Mapa 2]
 +
* Eletronet [http://www.eletronet.com/images/mapa_rede_eletronet.jpg Mapa Eletronet]
  
−
Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula6-modems-analogicos.pdf transparências sobre modems analógicos].
 
  
−
Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula5-modems.pdf transparências sobre interfaces digitais].
+
''Uma rede MAN MetroEthernet em Florianópolis.''
  
−
Durante a aula serão feitas experiências sobre interfaces digitais V.35 e RS-232c.
+
[[imagem:Man-metro.png]]
  
−
* [http://en.wikipedia.org/wiki/List_of_device_bandwidths Tabelas de taxas de transmissão de diferentes tecnologias]
+
=== LANs ===
  
−
=== Trabalho coletivo ===
+
* Características
 +
* Topologias
 +
* O problema do acesso ao meio
 +
* Algumas tecnologias:
 +
** [http://en.wikipedia.org/wiki/Ethernet Ethernet (IEEE 802.3)]
 +
** [http://en.wikipedia.org/wiki/Token_ring Token Ring (IEEE 802.5)]
 +
** [http://en.wikipedia.org/wiki/Myrinet Myrinet]
 +
** [http://en.wikipedia.org/wiki/InfiniBand Infiniband]
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab6-2010-2.pdf Roteiro do experimento]
  
−
Após ver um conjunto de tecnologias de enlace e de camada física, devem existir questões como "afinal, quais tecnologias são usadas de fato atualmente, e quais as apostas para o futuro próximo ?". Para responder a essa pergunta propõe-se um trabalho coletivo de pesquisa para criar uma tabela dessas tecnologias junto com algumas outras informações:
 
  
−
* Que protocolos de enlace estão envolvidos ?
+
'''Pontos chaves (obtido de STALLINGS, 2005):'''
−
* Qual a codificação ou modulação usada ?
+
* Uma LAN consiste de um '''meio de transmissão compartilhado''' e um conjunto de hardware e software para servir de interface entre dispositivos e o meio de transmissão, além de regular o acesso ao meio de forma ordenada.
−
* Em que tipo de circuito é usada (incluindo o tipo de meio de transmissão) ?
+
* As topologias usadas em LANs são anel (''ring''), barramento (''bus''), árvore (''tree'') e estrela (''star''). Uma LAN em anel consiste de um laço fechado formado por repetidores que possibilitam que dados circulem ao redor do anel. Um repetidor pode funcionar também como um ponto de acesso de um dispositivo. Transmissão geralmente se dá na forma de '''quadros''' (''frames''). As topologias barramento e árvore são segmentos de cabos passivos a que os dispositivos são acoplados. A transmissão de um quadro por um dispositivo (chamado de '''estação''') pode ser escutada por qualquer outra estação. Uma LAN em estrela inclui um nó central onde as estações são acopladas.
−
* Que equipamentos são necessários (incluindo os modelos) ?
+
* Um conjunto de '''padrões''' definido para LANs especifica uma faixa de taxas de dados e abrange uma variedade de topologias e meios de transmissão.
−
* Quais as taxas de bits nominais e BER que proporcionam ?
+
* Na maioria dos casos, uma organização possui múltiplas LANs que precisam ser interconectadas. A abordagem mais simples para esse problema se vale de equipamentos chamados de '''pontes''' (''bridges''). Os conhecidos ''switches Ethernet'' são exemplos de pontes.
−
* Qual o custo do enlace ?
+
* [http://en.wikipedia.org/wiki/Network_switch Switches] formam os blocos de montagem básicos da maioria das LANs (não muito tempo atrás [http://en.wikipedia.org/wiki/Ethernet_hub hubs] também eram usados).
−
* Empresa de onde obteve a informação ?
+
 
  
−
Os resultados da pesquisa devem ser colocados aqui mesmo na Wiki.
+
[[imagem:Lan1-2011-1.png|800px]]
 +
<br>''Uma pequena LAN com  um link para Internet''
  
−
== 27/09: Redes locais ==
 
  
−
* Correção de exercícios das listas 3 e 4.
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova2-2010-2.pdf 2a avaliação de 2010-2]
 
  
−
=== Introdução a redes locais ===
 
−
* Transparências:
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula7.pdf Introdução]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula8.pdf LANs e acesso ao meio]
 
−
* Capítulo 13 do livro "''Comunicação de Dados e Redes de Computadores''", de Berhouz Forouzan (tem no xerox)
 
−
* Capítulo 4 do livro "''Redes de Computadores''", de Andrew Tanenbaum (tem na biblioteca)
 
  
−
=== Distinção entre WAN, MAN e LAN ===
+
[[imagem:Lan2-2011-1.png|800px]]
 +
<br>''Uma LAN um pouco maior, e também com um link para Internet''
  
−
* Aplicações de cada um desses tipos de rede
 
−
* Tecnologias envolvidas
 
−
* "Backbones" da Internet Brasileira:
 
−
 
  
−
''Algumas redes WAN:''
 
−
* Brasil em [http://www.cgi.br/publicacoes/artigos/backbone-brasil.htm 1996]
 
−
* RNP [http://www.rnp.br/_media/backbone/bkb_mapa1991.png 1991],[http://www.rnp.br/_media/backbone/bkb_mapa1994.png 1992],[http://www.rnp.br/_media/backbone/bkb_mapa1996.png 1996], [http://i116.photobucket.com/albums/o34/almeidaris/1998.gif 1998],[http://www.rnp.br/_media/backbone/bkb_mapa2000.png 2000],[http://i116.photobucket.com/albums/o34/almeidaris/2001.gif 2001],[http://i116.photobucket.com/albums/o34/almeidaris/2005.jpg 2005],[http://i116.photobucket.com/albums/o34/almeidaris/2006.jpg 2006], [http://i116.photobucket.com/albums/o34/almeidaris/2007.jpg 2007].
 
−
* Embratel [http://www.embratel.com.br/Embratel02/images/secoes/11/07/951/MG_40_10_20_mapa1.jpg Mapa 1],[http://www.embratel.com.br/Embratel02/images/secoes/11/07/951/MG_40_10_20_mapa2.jpg Mapa 2]
 
−
* Eletronet [http://www.eletronet.com/images/mapa_rede_eletronet.jpg Mapa Eletronet]
 
  
 +
[[imagem:Lan-media.png]]<br>''Uma LAN de médio porte''
  
−
''Uma rede MAN MetroEthernet em Florianópolis.''
+
== 27/09: Redes locais: arquitetura IEEE 802 ==
  
−
[[imagem:Man-metro.png]]
+
* Arquitetura IEEE 802 e Redes locais IEEE 802.3 (Ethernet)
 +
** Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/slides/aula9-ieee.pdf transparências].
 +
** Capítulo 4 do livro "Redes de Computadores", de Andrew Tanenbaum.
 +
** Capítulo 14 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan.
  
−
=== LANs ===
+
[[Imagem:Ethernet.png|600px]]
  
−
* Características
+
''Desenho usado por Bob Metcalfe, um dos criadores da Ethernet, para apresentação em uma conferência em 1976.''
−
* Topologias
 
−
* O problema do acesso ao meio
 
  
 +
* Elementos de uma rede Ethernet atual:
 +
** '''Estações:''' equipamentos que se comunicam pela rede. Ex: computadores e roteadores.
 +
** '''Interface de rede (NIC):''' dispositivo embutido em cada estação com a finalidade de prover o acesso à rede. Implementa as camadas PHY e MAC.
 +
** '''Meio de transmissão:''' representado pelos cabos por onde os quadros ethernet são transmitidos. Esses cabos são conectados às interfaces de rede das estações.
 +
** '''Switch:''' equipamento de interconexão usado para interligar as estações. Cada estação é conectada a um switch por meio de um cabo. Um switch usualmente possui múltiplas interfaces de rede (12, 24 ou mais). Uma rede com switches apresenta uma topologia física em estrela.
  
−
[[imagem:Lan1-2011-1.png|800px]]
 
−
<br>''Uma pequena LAN com  um link para Internet''
 
  
 +
[[imagem:Lan2-2011-1.png]]
 +
<br>''Uma LAN com switches''
  
 +
... mas no início redes Ethernet não eram assim ! Leia o material de referência para ver como eram essas redes num passado relativamente próximo.
 +
 +
=== Arquitetura IEEE 802 ===
  
  
−
[[imagem:Lan2-2011-1.png|800px]]
+
Define um conjunto de normas e tecnologias no escopo das camadas física (PHY) e de enlace. A camada de enlace é dividida em duas subcamadas:
−
<br>''Uma LAN um pouco maior, e também com um link para Internet''
+
* '''LLC (Logical Link Control):''' o equivalente a um protocolo de enlace de fato, porém na prática de uso restrito (pouco utilizada).
 +
* '''MAC (Medium Access Control):''' um protocolo de acesso ao meio de transmissão, que depende do tipo de meio físico e tecnologia de comunicação. Esse tipo de protocolo é necessário quando o meio de transmissão é compartilhado.
  
  
 +
[[imagem:Arq-ieee.png|400px]]
  
−
[[imagem:Lan-media.png]]<br>''Uma LAN de médio porte''
+
=== Protocolo de acesso ao meio (MAC) ===
  
−
== 30/09: 2a avaliação ==
+
Parte da camada de enlace na arquitetura IEEE 802, tem papel fundamental na comunicação entre estações. O MAC é responsável por:
 +
* '''Definir um formato de quadro''' onde deve ser encapsulada uma PDU de um protocolo de camada superior.
  
−
Envolve o conteúdo sobre Camada Física, e se baseará nas listas de exercícios 3 e 4.
 
  
−
=== Conceitos ===
+
[[imagem:Quadro-ethernet.png|600px]]
 +
<br>''Quadro ethernet''
  
−
== 04/10: sem aula ==
 
  
−
Visita a Alcatel pela turma de Telefonia. Esta aula será resposta em data a combinar.
+
* '''Endereçar as estações''', já que o meio de transmissão é multiponto (ver campos ''Dest Add'' e ''Source Add'' no quadro Ethenet).
  
−
== 07/10: Redes locais: arquitetura IEEE 802 ==
+
* '''Acessar o meio para efetuar a transmissão de quadros''', resolvendo conflitos de acesso quando necessário. Um conflito de acesso (chamado de ''colisão'') pode ocorrer em alguns casos quando mais de uma estação tenta transmitir ao mesmo tempo.
  
−
* Arquitetura IEEE 802 e Redes locais IEEE 802.3 (Ethernet)
 
−
** Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/slides/aula9-ieee.pdf transparências].
 
−
** Capítulo 4 do livro "Redes de Computadores", de Andrew Tanenbaum.
 
−
** Capítulo 14 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan.
 
  
−
[[Imagem:Ethernet.png|600px]]
+
[[imagem:Csma-cd.png|600px]]
 +
<br>''O MAC CSMA/CD (Carrier Sense Multiple Access/Collision Detection''
  
−
''Desenho usado por Bob Metcalfe, um dos criadores da Ethernet, para apresentação em uma conferência em 1976.''
 
  
−
* Elementos de uma rede Ethernet atual:
+
* [http://www.datacottage.com/nch/eoperation.htm Animacões que mostram o tratamento de colisões]
−
** '''Estações:''' equipamentos que se comunicam pela rede. Ex: computadores e roteadores.
 
−
** '''Interface de rede (NIC):''' dispositivo embutido em cada estação com a finalidade de prover o acesso à rede. Implementa as camadas PHY e MAC.
 
−
** '''Meio de transmissão:''' representado pelos cabos por onde os quadros ethernet são transmitidos. Esses cabos são conectados às interfaces de rede das estações.
 
−
** '''Switch:''' equipamento de interconexão usado para interligar as estações. Cada estação é conectada a um switch por meio de um cabo. Um switch usualmente possui múltiplas interfaces de rede (12, 24 ou mais). Uma rede com switches apresenta uma topologia física em estrela.
 
  
 +
==== Ver também ====
  
−
[[imagem:Lan2-2011-1.png]]
+
Leia este texto:
−
<br>''Uma LAN com switches''
+
* [http://www.arandanet.com.br/midiaonline/rti/2010/abril/index.html Ethernet 40 Gbps e 100 Gbps]
  
−
... mas no início redes Ethernet não eram assim ! Leia o material de referência para ver como eram essas redes num passado relativamente próximo.
+
=== Utilização do meio de transmissão em uma rede local com MAC do tipo CSMA/CD ===
−
 
−
=== Arquitetura IEEE 802 ===
 
  
 +
Nesta seção mostra-se como estimar o desempenho do CSMA/CD por meio de experimentos para medir a utilização máxima do meio. Esses experimentos podem ser feitos usando uma rede real, com computadores interligados por ''hubs'', ou com um simulador. Em ambos os casos deve-se fazer com que vários computadores gerem tráfego intenso na rede, e calcular ao final a utilização do meio da seguinte forma:
  
−
Define um conjunto de normas e tecnologias no escopo das camadas física (PHY) e de enlace. A camada de enlace é dividida em duas subcamadas:
+
<math>
−
* '''LLC (Logical Link Control):''' o equivalente a um protocolo de enlace de fato, porém na prática de uso restrito (pouco utilizada).
+
U = \frac{total~bytes~recebidos}{duracao~do~experimento}
−
* '''MAC (Medium Access Control):''' um protocolo de acesso ao meio de transmissão, que depende do tipo de meio físico e tecnologia de comunicação. Esse tipo de protocolo é necessário quando o meio de transmissão é compartilhado.
+
</math>
  
 +
O ''total de quadros recebidos'' pode ser obtido em qualquer um dos computadores.
  
−
[[imagem:Arq-ieee.png|400px]]
+
Para fazer com uma rede real:
 +
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5.pdf Roteiro da experiência]
 +
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/emissor.c Programa emissor]: faça o download e compile com o comando: <syntaxhighlight lang=bash>
 +
gcc -o emissor emissor.c
 +
</syntaxhighlight>
  
−
=== Protocolo de acesso ao meio (MAC) ===
+
'''Resultados (obtidos em 2010-2):'''
 +
<syntaxhighlight lang=text>
 +
1: 140254390 214015690
 +
2: 214015690 276800590
 +
3: 276800590 336225070
 +
4: 336225070 398761510
 +
5: 398761510 460950490
 +
6: 479962630 544977970
 +
7: 544977970 610117870
 +
8: 690263890 755876470
 +
</syntaxhighlight>
  
−
Parte da camada de enlace na arquitetura IEEE 802, tem papel fundamental na comunicação entre estações. O MAC é responsável por:
+
Com esses dados deve-se plotar um gráfico da quantidade de bytes recebidos X quantidade de estações transmissoras. Na tabela acima, as estações transmissoras estão na 1a coluna, e a quantidade de bytes recebidos deve ser calculada pela subtração da 3a coluna pela 2a coluna.
−
* '''Definir um formato de quadro''' onde deve ser encapsulada uma PDU de um protocolo de camada superior.
 
  
 +
Para fazer a experiência pode ser feita também com o simulador Omnet++:
 +
*** [[Omnetpp-Instalacao|Instale o Omnet++ 4]]
 +
*** Instale o modelo INET: <syntaxhighlight lang=bash>
 +
# Faz o download do INET Framework (aprox. 23 MB)
 +
wget http://tele.sj.isfc.edu.br/~msobral/RCO2/soft/inet-20100323-src.tgz
  
−
[[imagem:Quadro-ethernet.png|600px]]
+
# Descompacte o arquivo
−
<br>''Quadro ethernet''
+
tar xzf inet-20100323-src.tar.gz
  
 +
# Compila o INET
 +
cd inet
 +
make makefiles
 +
make
 +
</syntaxhighlight>
 +
*** Copie esses arquivos para dentro de ''inet/examples/ethernet/lans'':<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/mu.ini mu.ini]<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/mu2.ini mu2.ini]<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/Networks.ned Networks.ned]
 +
*** Para executar uma simulação interativa, com animação, faça assim: <syntaxhighlight lang=bash>
 +
cd inet/examples/ethernet/lans
 +
./run mu.ini
 +
</syntaxhighlight>... e escolha um dos modelos para executar.
 +
*** Para executar uma simulação não-interativa, com uma bateria de experimentos que variam a quantidade de estações (2 a 16) e tamanhos de quadros (256, 512 e 1480 bytes), faça assim: <syntaxhighlight lang=bash>
 +
cd inet/examples/ethernet/lans
 +
./run -u Cmdenv -c Hub1 mu2.ini
 +
</syntaxhighlight>
 +
*** Os resultados das simulações estarão em arquivos dentro do subdiretório ''inet/examples/ethernet/lans/results''. Por exemplo, o arquivo ''Hub1-0.sca'' contém o resultado da primeira simulação, e parte de seu conteúdo é mostrada abaixo (cada linha contém algum resultado ou estatística da simulação, e o título é auto-explicativo): <syntaxhighlight lang=text>
 +
version 2
 +
run Hub1-1-20100423-09:38:33-7627
 +
attr bytes 256
 +
attr configname Hub1
 +
attr datetime 20100423-09:38:33
 +
attr experiment Hub1
 +
attr inifile mu2.ini
 +
attr iterationvars "$bytes=256, $stations=3"
 +
attr iterationvars2 "$bytes=256, $stations=3, $repetition=0"
 +
attr measurement "$bytes=256, $stations=3"
 +
attr network HubLAN2
 +
attr processid 7627
 +
attr repetition 0
 +
attr replication #0
 +
attr resultdir results
 +
attr runnumber 1
 +
attr seedset 1
 +
attr stations 3
  
−
* '''Endereçar as estações''', já que o meio de transmissão é multiponto (ver campos ''Dest Add'' e ''Source Add'' no quadro Ethenet).
+
scalar .       bytes  256
−
 
+
scalar .        stations        3
−
* '''Acessar o meio para efetuar a transmissão de quadros''', resolvendo conflitos de acesso quando necessário. Um conflito de acesso (chamado de ''colisão'') pode ocorrer em alguns casos quando mais de uma estação tenta transmitir ao mesmo tempo.
+
scalar HubLAN2.sta[0].cli      "packets sent"  0
−
 
+
scalar HubLAN2.sta[0].cli      "packets rcvd"  0
−
 
+
scalar HubLAN2.sta[0].cli      "end-to-end delay mean"        0
−
[[imagem:Csma-cd.png|600px]]
+
scalar HubLAN2.sta[0].cli      "end-to-end delay stddev"      nan
−
<br>''O MAC CSMA/CD (Carrier Sense Multiple Access/Collision Detection''
+
scalar HubLAN2.sta[0].cli      "end-to-end delay min"  0
−
 
+
scalar HubLAN2.sta[0].cli      "end-to-end delay max"  0
−
 
+
scalar HubLAN2.sta[0].srv      "packets sent"  0
−
* [http://www.datacottage.com/nch/eoperation.htm Animacões que mostram o tratamento de colisões]  
+
scalar HubLAN2.sta[0].srv      "packets rcvd"  247453
−
 
+
scalar HubLAN2.sta[0].srv      "end-to-end delay mean"        1.6121223100944
−
=== Atividade ===
+
scalar HubLAN2.sta[0].srv      "end-to-end delay stddev"      1.0596723502417
−
 
+
scalar HubLAN2.sta[0].srv      "end-to-end delay min"  0.0002378
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab6-2010-2.pdf Roteiro do experimento]
+
scalar HubLAN2.sta[0].srv      "end-to-end delay max"  5.18103003756
−
 
+
scalar HubLAN2.sta[0].llc      "dsaps registered"      1
−
==== Ver também ====
+
scalar HubLAN2.sta[0].llc      "packets from higher layer"    0
−
 
+
scalar HubLAN2.sta[0].llc      "frames from MAC"      247453
−
Leia este texto:
+
scalar HubLAN2.sta[0].llc      "packets passed up"    247453
−
* [http://www.arandanet.com.br/midiaonline/rti/2010/abril/index.html Ethernet 40 Gbps e 100 Gbps]
+
scalar HubLAN2.sta[0].llc      "packets dropped - unknown DSAP"        0
−
 
+
scalar HubLAN2.sta[0].mac      "simulated time"        60.0001141233
−
=== Utilização do meio de transmissão em uma rede local com MAC do tipo CSMA/CD ===
+
scalar HubLAN2.sta[0].mac      "txrate (Mb)"  10
−
 
+
scalar HubLAN2.sta[0].mac      "full duplex"  0
−
Nesta seção mostra-se como estimar o desempenho do CSMA/CD por meio de experimentos para medir a utilização máxima do meio. Esses experimentos podem ser feitos usando uma rede real, com computadores interligados por ''hubs'', ou com um simulador. Em ambos os casos deve-se fazer com que vários computadores gerem tráfego intenso na rede, e calcular ao final a utilização do meio da seguinte forma:
+
scalar HubLAN2.sta[0].mac      "frames sent"  0
−
 
+
scalar HubLAN2.sta[0].mac      "frames rcvd"  247453
−
<math>
+
scalar HubLAN2.sta[0].mac      "bytes sent"    0
−
U = \frac{total~bytes~recebidos}{duracao~do~experimento}
+
scalar HubLAN2.sta[0].mac      "bytes rcvd"    68544481
−
</math>
+
scalar HubLAN2.sta[0].mac      "frames from higher layer"      0
−
 
+
scalar HubLAN2.sta[0].mac      "frames from higher layer dropped (iface down)"        0
−
O ''total de quadros recebidos'' pode ser obtido em qualquer um dos computadores.
+
scalar HubLAN2.sta[0].mac      "frames dropped (bit error)"    0
−
 
+
scalar HubLAN2.sta[0].mac      "frames dropped (not for us)"  0
−
Para fazer com uma rede real:
+
scalar HubLAN2.sta[0].mac      "frames passed up to HL"        247453
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5.pdf Roteiro da experiência]
+
scalar HubLAN2.sta[0].mac      "PAUSE frames sent"    0
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/emissor.c Programa emissor]: faça o download e compile com o comando: <syntaxhighlight lang=bash>
+
scalar HubLAN2.sta[0].mac      "PAUSE frames rcvd"    0
−
gcc -o emissor emissor.c
+
scalar HubLAN2.sta[0].mac      "frames/sec sent"      0
 +
scalar HubLAN2.sta[0].mac      "frames/sec rcvd"      4124.2088221947
 +
scalar HubLAN2.sta[0].mac      "bits/sec sent"        0
 +
scalar HubLAN2.sta[0].mac      "bits/sec rcvd"        9139246.7499834
 +
scalar HubLAN2.sta[0].mac      "rx channel idle (%)"  5.937858457565
 +
scalar HubLAN2.sta[0].mac      "rx channel utilization (%)"    94.031961146038
 +
scalar HubLAN2.sta[0].mac      "rx channel collision (%)"      0.030180396396893
 +
scalar HubLAN2.sta[0].mac      collisions      4825
 +
scalar HubLAN2.sta[0].mac      backoffs        0
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
'''Resultados (obtidos em 2010-2):'''
+
O gráfico abaixo foi obtido com esse experimento de simulação:
−
<syntaxhighlight lang=text>
+
 
−
1: 140254390 214015690
+
[[imagem:Csma-perf-sim.png]]
−
2: 214015690 276800590
 
−
3: 276800590 336225070
 
−
4: 336225070 398761510
 
−
5: 398761510 460950490
 
−
6: 479962630 544977970
 
−
7: 544977970 610117870
 
−
8: 690263890 755876470
 
−
</syntaxhighlight>
 
  
−
Com esses dados deve-se plotar um gráfico da quantidade de bytes recebidos X quantidade de estações transmissoras. Na tabela acima, as estações transmissoras estão na 1a coluna, e a quantidade de bytes recebidos deve ser calculada pela subtração da 3a coluna pela 2a coluna.
+
As simulações tiveram os seguintes parâmetros:
 +
* Quadros de 256, 512 e 1480 bytes
 +
* 2 a 45 estações
 +
* Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)
  
−
Para fazer a experiência pode ser feita também com o simulador Omnet++:
+
* Uma análise feita no capítulo 4 do livro "Redes de Computadores, 4a ed." de Andrew Tanenbaum fornece a seguinte previsão de desempenho para o CSMA/CD em uma rede Ethernet a 10 Mbps.
−
*** [[Omnetpp-Instalacao|Instale o Omnet++ 4]]
 
−
*** Instale o modelo INET: <syntaxhighlight lang=bash>
 
−
# Faz o download do INET Framework (aprox. 23 MB)
 
−
wget http://tele.sj.isfc.edu.br/~msobral/RCO2/soft/inet-20100323-src.tgz
 
  
−
# Descompacte o arquivo
+
* ''Utilização do meio:''
−
tar xzf inet-20100323-src.tar.gz
 
  
−
# Compila o INET
+
<math>U = \frac{1}{1 + \frac{2BLe}{cF}}</math>
−
cd inet
+
 
−
make makefiles
+
* '''''B:''''' taxa de bits nominal
−
make
+
* '''''L:''''' comprimento do meio de transmissão
−
</syntaxhighlight>
+
* '''''c: ''''' velocidade de propagação do sinal
−
*** Copie esses arquivos para dentro de ''inet/examples/ethernet/lans'':<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/mu.ini mu.ini]<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/mu2.ini mu2.ini]<br>[http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab5/Networks.ned Networks.ned]
+
* '''''F:''''' comprimento do quadro
−
*** Para executar uma simulação interativa, com animação, faça assim: <syntaxhighlight lang=bash>
+
 
−
cd inet/examples/ethernet/lans
+
[[Image:Csma-perf.png|400px]]
−
./run mu.ini
+
 
−
</syntaxhighlight>... e escolha um dos modelos para executar.
+
Essa figura mostra curvas para a utilização do meio em função da quantidade de estações prontas para transmitir, e para diferentes tamanhos de quadro. A conclusão é que quadros menores proporcionam desempenho inferior, assim como uma quantidade maior de estações resulta em uma provável menor utilização do meio. No entanto essa análise considera a rede numa situação de carga muito alta, o que não acontece normalmente. Há também algumas simplificações no desenvolvimento da análise, tal como considerar que a probabilidade de retransmissão constante em cada ''slot'', ao invés de analisar o algoritmo de recuo exponencial binário (''backoff''). Finalmente, esse resultado tem sentido para um meio de transmissão compartilhado, mas a atualmente as redes locais ethernet trabalham com meios de transmissão exclusivos (''ethernet comutada e full-duplex'', em que não há risco de colisão).
−
*** Para executar uma simulação não-interativa, com uma bateria de experimentos que variam a quantidade de estações (2 a 16) e tamanhos de quadros (256, 512 e 1480 bytes), faça assim: <syntaxhighlight lang=bash>
+
 
−
cd inet/examples/ethernet/lans
+
Para fins de comparação, um experimento de simulação foi realizado (conforme descrito na [[RCO2-2010-2#Utiliza.C3.A7.C3.A3o_do_meio_de_transmiss.C3.A3o_em_uma_rede_local.2C_com_MAC_do_tipo_CSMA.2FCD|aula anterior]]), e foram obtidos os resultados mostrados na figura abaixo.
−
./run -u Cmdenv -c Hub1 mu2.ini
+
 
−
</syntaxhighlight>
+
[[imagem:Csma-perf-sim.png]]
−
*** Os resultados das simulações estarão em arquivos dentro do subdiretório ''inet/examples/ethernet/lans/results''. Por exemplo, o arquivo ''Hub1-0.sca'' contém o resultado da primeira simulação, e parte de seu conteúdo é mostrada abaixo (cada linha contém algum resultado ou estatística da simulação, e o título é auto-explicativo): <syntaxhighlight lang=text>
 
−
version 2
 
−
run Hub1-1-20100423-09:38:33-7627
 
−
attr bytes 256
 
−
attr configname Hub1
 
−
attr datetime 20100423-09:38:33
 
−
attr experiment Hub1
 
−
attr inifile mu2.ini
 
−
attr iterationvars "$bytes=256, $stations=3"
 
−
attr iterationvars2 "$bytes=256, $stations=3, $repetition=0"
 
−
attr measurement "$bytes=256, $stations=3"
 
−
attr network HubLAN2
 
−
attr processid 7627
 
−
attr repetition 0
 
−
attr replication #0
 
−
attr resultdir results
 
−
attr runnumber 1
 
−
attr seedset 1
 
−
attr stations 3
 
  
−
scalar .        bytes   256
+
Para esse experimento foram realizadas simulações com os seguintes parâmetros:
−
scalar .        stations        3
+
* Quadros de 256, 512 e 1480 bytes
−
scalar HubLAN2.sta[0].cli      "packets sent"  0
+
* 2 a 45 estações
−
scalar HubLAN2.sta[0].cli      "packets rcvd"  0
+
* Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)
−
scalar HubLAN2.sta[0].cli      "end-to-end delay mean"        0
+
 
−
scalar HubLAN2.sta[0].cli      "end-to-end delay stddev"      nan
+
== 04/10: 2a avaliação ==
−
scalar HubLAN2.sta[0].cli      "end-to-end delay min"  0
+
 
−
scalar HubLAN2.sta[0].cli      "end-to-end delay max" 0
+
Envolve o conteúdo sobre Camada Física, e se baseará nas listas de exercícios 3 e 4.
−
scalar HubLAN2.sta[0].srv      "packets sent"  0
+
 
−
scalar HubLAN2.sta[0].srv      "packets rcvd"  247453
+
== 07/10: Redes locais: arquitetura IEEE 802 e interligação de LANs ==
−
scalar HubLAN2.sta[0].srv      "end-to-end delay mean"        1.6121223100944
+
 
−
scalar HubLAN2.sta[0].srv      "end-to-end delay stddev"      1.0596723502417
+
* Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista5.pdf 5a lista de exercícios].
−
scalar HubLAN2.sta[0].srv      "end-to-end delay min"  0.0002378
+
** Obs: tente resolver as questões finais usando o [[Netkit]].
−
scalar HubLAN2.sta[0].srv      "end-to-end delay max"  5.18103003756
+
 
−
scalar HubLAN2.sta[0].llc      "dsaps registered"      1
+
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula10.pdf transparências].
−
scalar HubLAN2.sta[0].llc      "packets from higher layer"    0
+
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
−
scalar HubLAN2.sta[0].llc      "frames from MAC"      247453
+
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
−
scalar HubLAN2.sta[0].llc      "packets passed up"    247453
+
 
−
scalar HubLAN2.sta[0].llc      "packets dropped - unknown DSAP"        0
+
'''Interligação de LANs (norma IEEE802.1D):'''
−
scalar HubLAN2.sta[0].mac      "simulated time"        60.0001141233
+
* Operação de pontes e switches [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab7-2011-1.pdf (roteiro)]
−
scalar HubLAN2.sta[0].mac      "txrate (Mb)"  10
+
** Visualizar o aprendizado de endereços em um switch ou ponte
−
scalar HubLAN2.sta[0].mac      "full duplex"  0
+
*** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/lan-switch-transparent.swf Animação sobre o funcionamento de switches (Cisco)]
−
scalar HubLAN2.sta[0].mac      "frames sent"  0
+
** Visualizar como um switch ou ponte propaga quadros em broadcast.
−
scalar HubLAN2.sta[0].mac      "frames rcvd"  247453
+
 
−
scalar HubLAN2.sta[0].mac      "bytes sent"    0
+
=== Tecnologias de LAN switches ===
−
scalar HubLAN2.sta[0].mac      "bytes rcvd"    68544481
+
 
−
scalar HubLAN2.sta[0].mac      "frames from higher layer"      0
+
Leia este [http://tele.sj.ifsc.edu.br/~msobral/RCO2/docs/switch-internals.pdf bom texto] sobre estruturas internas de switches.
−
scalar HubLAN2.sta[0].mac      "frames from higher layer dropped (iface down)"        0
+
 
−
scalar HubLAN2.sta[0].mac      "frames dropped (bit error)"    0
+
 
−
scalar HubLAN2.sta[0].mac      "frames dropped (not for us)"  0
+
Outros materiais:
−
scalar HubLAN2.sta[0].mac      "frames passed up to HL"        247453
+
* [http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a00800a7af3.shtml#switchtechs Bom texto sobre switches]
−
scalar HubLAN2.sta[0].mac      "PAUSE frames sent"    0
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/lan-switch-transparent.swf Animação sobre o funcionamento de switches (Cisco)]
−
scalar HubLAN2.sta[0].mac      "PAUSE frames rcvd"    0
+
* [http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-465436.html Texto sobre tecnologias de switches (store-and-forward e cut-through)]
−
scalar HubLAN2.sta[0].mac      "frames/sec sent"      0
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0142.mov Animacão sobre switches cut-through]
−
scalar HubLAN2.sta[0].mac      "frames/sec rcvd"      4124.2088221947
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0141.mov Animacão sobre switches store-and-forward]
−
scalar HubLAN2.sta[0].mac      "bits/sec sent"        0
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0143.mov Animacão sobre switches simétricos (todas portas com mesma taxa de bits)]
−
scalar HubLAN2.sta[0].mac      "bits/sec rcvd"        9139246.7499834
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0144.mov Animacão sobre switches assimétricos (portas com diferentes taxas de bits)]
−
scalar HubLAN2.sta[0].mac      "rx channel idle (%)"  5.937858457565
+
 
−
scalar HubLAN2.sta[0].mac      "rx channel utilization (%)"    94.031961146038
+
* Quais são as características dos switches do laboratório ?
−
scalar HubLAN2.sta[0].mac      "rx channel collision (%)"      0.030180396396893
+
** D-Link DES-526 [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/manual-des3526.pdf (manual)]
−
scalar HubLAN2.sta[0].mac      collisions      4825
+
** Micronet SP 1658B [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/SP1658B_Manual.pdf (manual)]
−
scalar HubLAN2.sta[0].mac      backoffs        0
+
** 3Com 3224 [http://www.3com.com/prod/pt_la_amer/detail.jsp?tab=prodspec&sku=3C16479 (especificações)]
−
</syntaxhighlight>
 
  
−
O gráfico abaixo foi obtido com esse experimento de simulação:
+
=== TRABALHO sobre switches ===
  
−
[[imagem:Csma-perf-sim.png]]
+
Para ser lançado em mercado, um switch deve apresentar conformidade com as especificações para ''bridges'' do padrão IEEE 802.1D. Além disso, deve também ter descritos seus parâmetros de desempenho.  
  
−
As simulações tiveram os seguintes parâmetros:
+
O trabalho consiste em efetuar uma avaliação de um switch de baixo custo. Deve-se determinar:
−
* Quadros de 256, 512 e 1480 bytes
+
# Se o switch opera conforme uma ponte transparente (''transparent bridge''), de acordo com o padrão IEEE 802.1D.
−
* 2 a 45 estações
+
# Se o switch é robusto (não tranca).
−
* Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)
+
# Informações de desempenho do switch: latência, vazão (''throughput''), ''backplane'', tamanho da tabela de endereços MAC (total e por porta), taxas de bits e modos duplex, suporte a auto-negociação, limites mínimos e máximos de tamanhos de quadros.
  
−
* Uma análise feita no capítulo 4 do livro "Redes de Computadores, 4a ed." de Andrew Tanenbaum fornece a seguinte previsão de desempenho para o CSMA/CD em uma rede Ethernet a 10 Mbps.
+
Cada equipe receberá um switch, com que deve criar experimentos para responder os ítens da avaliação. Os resultados devem ser reportados em um relatório composto pelas seções:
 +
# Título
 +
# Identificação dos membros da equipe
 +
# Objetivo do trabalho
 +
# Introdução: uma visão geral sobre a avaliação do switch, em que se explicam sucintamente os pontos a serem avaliados. Na introdução deve-se também apresentar resumidamente os procedimentos realizados, e uma indicação dos resultados obtidos.
 +
# Desenvolvimento: descrição dos experimentos e seus resultados. Cada experimento deve ser explicado com detalhes, de forma que outra pessoa pudesse repeti-los. Os resultados devem ser apresentados de forma clara, explorando o uso de gráficos e tabelas quando adequado.
 +
# Conclusão: uma discussão sobre os resultados obtidos, acompanhada de um julgamento sobre a avaliação do switch.
 +
# Bibliografia: uma listagem das referências bibliográficas utilizadas (e que devem ser citadas no texto).
  
−
* ''Utilização do meio:''
 
  
−
<math>U = \frac{1}{1 + \frac{2BLe}{cF}}</math>
+
As equipes podem ser compostas por até '''3 alunos'''.
  
−
* '''''B:''''' taxa de bits nominal
+
'''Prazo de entrega: 18/10'''
−
* '''''L:''''' comprimento do meio de transmissão
 
−
* '''''c: ''''' velocidade de propagação do sinal
 
−
* '''''F:''''' comprimento do quadro
 
  
−
[[Image:Csma-perf.png|400px]]
+
'''OBS:''' use [http://tele.sj.ifsc.edu.br/~msobral/soft/l2-envio.c este programa] para enviar quadros ethernet com endereços de origem forjados. Ele enviará quadros indefinidamente, sendo que cada quadro terá um endereço de origem diferente. O intervalo entre envios é de 100 microssegundos (pode ser modificado editando o programa). Os quadros possuem o campo ''ethertype'' com valor 0x8888. Para compilá-lo faça assim:
  
−
Essa figura mostra curvas para a utilização do meio em função da quantidade de estações prontas para transmitir, e para diferentes tamanhos de quadro. A conclusão é que quadros menores proporcionam desempenho inferior, assim como uma quantidade maior de estações resulta em uma provável menor utilização do meio. No entanto essa análise considera a rede numa situação de carga muito alta, o que não acontece normalmente. Há também algumas simplificações no desenvolvimento da análise, tal como considerar que a probabilidade de retransmissão constante em cada ''slot'', ao invés de analisar o algoritmo de recuo exponencial binário (''backoff''). Finalmente, esse resultado tem sentido para um meio de transmissão compartilhado, mas a atualmente as redes locais ethernet trabalham com meios de transmissão exclusivos (''ethernet comutada e full-duplex'', em que não há risco de colisão).
+
<syntaxhighlight lang=bash>
 +
gcc -o envio l2-envio.c
 +
</syntaxhighlight>
  
−
Para fins de comparação, um experimento de simulação foi realizado (conforme descrito na [[RCO2-2010-2#Utiliza.C3.A7.C3.A3o_do_meio_de_transmiss.C3.A3o_em_uma_rede_local.2C_com_MAC_do_tipo_CSMA.2FCD|aula anterior]]), e foram obtidos os resultados mostrados na figura abaixo.
+
... e para rodá-lo:
  
−
[[imagem:Csma-perf-sim.png]]
+
<syntaxhighlight lang=bash>
 +
sudo ./envio eth0 aa:bb:cc:dd:ee:ff
 +
</syntaxhighlight>
  
−
Para esse experimento foram realizadas simulações com os seguintes parâmetros:
+
''aa:bb:cc:dd:ee:ff'' é o endereço MAC da estação destino. Se ele for omitido, os quadros serão enviados para broadcast.
−
* Quadros de 256, 512 e 1480 bytes
 
−
* 2 a 45 estações
 
−
* Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)
 
  
−
== 11/10: Redes locais: arquitetura IEEE 802 e interligação de LANs ==
+
== 11/10 e 14/10: Redes locais: interligação de LANs e VLANs IEEE 802.1q ==
  
−
* Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista5.pdf 5a lista de exercícios].
+
'''IMPORTANTE:''' Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista5.pdf 5a lista de exercícios].
−
** Obs: tente resolver as questões finais usando o [[Netkit]].
+
* Obs: tente resolver as questões finais usando o [[Netkit]].
 +
----
  
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula10.pdf transparências].
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula10.pdf transparências].
 
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
 
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
 
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
 
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
 +
* Capítulo 5 do livro "''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'', de James Kurose.
  
−
'''Interligação de LANs (norma IEEE802.1D):'''
+
* '''VLANs'''
−
* Operação de pontes e switches [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab7-2011-1.pdf (roteiro)]
+
** Norma [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/ieee/802.1Q-2005.pdf IEEE 802.1q]  
−
** Visualizar o aprendizado de endereços em um switch ou ponte
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab7.pdf Roteiro da experiência]
−
*** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/lan-switch-transparent.swf Animação sobre o funcionamento de switches (Cisco)]
+
*** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/manual-des3526.pdf manual do switch D-Link DES-3526]
−
** Visualizar como um switch ou ponte propaga quadros em broadcast.
 
  
−
=== Emulação de redes locais ===
+
[[imagem:quadro-8021q.png|600px]]
 +
<br>''Quadro ethernet com a TAG IEEE 802.1q''
  
−
Um computador com Linux pode ser transformado em uma ponte ou switch. Essa funcionalidade pode ser explorada no [http://www.netkit.org Netkit]. Esse conjunto de softwares possibilita a configuração, execução e uso de redes emuladas. Assim, consegue-se criar uma rede de tamanho razoável totalmente por software, e que rode em um  único computador. Cada equipamento dessas redes emuladas funciona como um computador Linux, que pode ser configurado para operar como  servidor, roteador,  switch, uma  simples ponte (''bridge'') ou um  firewall. Esses computadores Linux emulados são máquinas virtuais, portanto funcionam como computadores reais.
+
=== VLANs no Netkit ===
  
−
==== Netkit ====
+
Configuração do Netkit (arquivo Lab.conf):
  
−
Um sistema para fazer experimentos com redes interligadas por pontes, switches ou roteadores.
+
<syntaxhighlight lang=text>
 +
switch[type]=switch
 +
pc1[type]=generic
 +
pc2[type]=generic
 +
pc3[type]=generic
 +
pc4[type]=generic
  
−
* [[Netkit|Um tutorial para uso do Netkit em Redes 2]]
+
switch[eth0]=port0:vlan_untagged=5
−
* Para os experimentos abaixo:
+
switch[eth1]=port1:vlan_untagged=10
−
** Fazer experimentos para visualizar como os quadros se propagam entre os segmentos através da ponte.
+
switch[eth2]=port2:vlan_untagged=5
−
** Visualizar como a ponte aprende os endereços das estações de cada segmento.
+
switch[eth3]=port3:vlan_untagged=10
−
** Testar o envio de quadros em broadcast, e observar como a ponte os propaga.
 
−
* [[Netkit#Uma_biblioteca_de_exemplos_de_experimentos|Exemplos de experimentos]]
 
  
−
=== Tema extra: ''tecnologias de LAN switches'' ===
+
pc1[eth0]=port0:ip=192.168.5.1/24
 +
pc2[eth0]=port1:ip=192.168.10.2/24
 +
pc3[eth0]=port2:ip=192.168.5.3/24
 +
pc4[eth0]=port3:ip=192.168.10.4/24
 +
</syntaxhighlight>
  
−
* [http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a00800a7af3.shtml#switchtechs Bom texto sobre switches]
+
== 18/10: Redes locais: interligação de LANs e protocolo Spanning Tree (STP) ==
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/lan-switch-transparent.swf Animação sobre o funcionamento de switches (Cisco)]
 
−
* [http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-465436.html Texto sobre tecnologias de switches (store-and-forward e cut-through)]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0142.mov Animacão sobre switches cut-through]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0141.mov Animacão sobre switches store-and-forward]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0143.mov Animacão sobre switches simétricos (todas portas com mesma taxa de bits)]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/videos/q0144.mov Animacão sobre switches assimétricos (portas com diferentes taxas de bits)]
 
  
−
* Quais são as características dos switches do laboratório ?
+
Fazer a [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista7.pdf 6a lista de exercícios].
−
** D-Link DES-526 [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/manual-des3526.pdf (manual)]
 
−
** Micronet SP 1658B [http://www.sj.ifsc.edu.br/~msobral/IER/roteiros/SP1658B_Manual.pdf (manual)]
 
−
** 3Com 3224 [http://www.3com.com/prod/pt_la_amer/detail.jsp?tab=prodspec&sku=3C16479 (especificações)]
 
  
−
== 14/10: Redes locais: interligação de LANs e VLANs IEEE 802.1q ==
+
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
−
 
 
−
'''IMPORTANTE:''' Ver [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista5.pdf 5a lista de exercícios].
 
−
* Obs: tente resolver as questões finais usando o [[Netkit]].
 
−
----
 
−
 
 
−
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula10.pdf transparências].
 
−
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
 
−
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
 
−
* Capítulo 5 do livro "''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'', de James Kurose.
 
−
 
 
−
* '''VLANs'''
 
−
** Norma [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/ieee/802.1Q-2005.pdf IEEE 802.1q]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab7.pdf Roteiro da experiência]
 
−
*** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/manual-des3526.pdf manual do switch D-Link DES-3526]
 
−
 
 
−
[[imagem:quadro-8021q.png|600px]]
 
−
<br>''Quadro ethernet com a TAG IEEE 802.1q''
 
−
 
 
−
=== VLANs no Netkit ===
 
−
 
 
−
* Como visto em [[RCO2-2011-1#Emula.C3.A7.C3.A3o_de_redes_locais|05/05]], uma máquina virtual Linux no [[Netkit]] pode ser transformada em uma ponte ou switch. O Netkit gera a configuração necessária automaticamente para que [https://help.ubuntu.com/community/NetworkConnectionBridge bridge-utils] transforme o Linux num switch.
 
−
 
 
−
* O Netkit também possibilita que se usem [[Netkit#Experimentos_que_usam_switches_e_interfaces_virtuais|VLANs no Linux]]. As VLANs são também configuradas automaticamente (o Netkit usa internamente o utilitário [http://manpages.ubuntu.com/manpages/hardy/man8/vconfig.8.html vconfig]). Cada VLAN configurada possuirá uma interface virtual correspondente. Ex: ao configurar as VLANs 5 e 10 na interface eth0, passam a existir as interfaces ''eth0.5'' e ''eth0.10''. Essas interfaces podem ser configuradas com o utilitário ''ifconfig'', como qualquer outra interface de rede. Note que as interfaces eth0.5 e eth0.10 funcionam em modo ''tagged''.
 
−
** Unindo-se o suporte a VLANs com as interfaces do tipo bridge, pode-se transformar um computador Linux em um switch com VLANs, e é isso que faz o Netkit.
 
−
 
 
−
== 18/10: Redes locais: interligação de LANs e protocolo Spanning Tree (STP) ==
 
−
 
 
−
Fazer a [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/lista7.pdf 6a lista de exercícios].
 
−
 
 
−
* Capítulo 16 do livro "''Comunicação de Dados e Redes de Computadores, 3a ed.''", de Behrouz Forouzan.
 
 
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
 
* Capítulo 4 do livro "''Redes de Computadores, 4a ed.''", de Andrew Tanenbaum.
 
* Capítulo 5 do livro "''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'', de James Kurose.
 
* Capítulo 5 do livro "''Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição'', de James Kurose.
Linha 1 223: Linha 1 326:
 
* ... [http://freeradius.org/features/eap.html e muitos outros !]
 
* ... [http://freeradius.org/features/eap.html e muitos outros !]
  
−
== 25/10: Introdução a WAN e Revisão ==
+
=== TRABALHO SOBRE LANS ===
  
−
* Introdução a WAN: conceitos básicos (ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula13.pdf transparências])
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/trabalhos/trab-lans-2011-2.pdf Descrição do trabalho]
−
 
+
* [[Netkit|Ajuda sobre o Netkit]]
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab12.pdf Experimento sobre Frame-Relay]
 
−
** [http://www.ciscopress.com/articles/article.asp?p=170741 Guia da Cisco sobre Frame Relay]
 
  
 +
'''Prazo de entrega:''' 07/11
 +
<br>Grupos de até 2 pessoas
  
−
'''Ver também:'''
+
== 25/10: Revisão ==
−
*Capítulo 18 do livro ''Comunicação de Dados e Redes de Computadores, 3a ed.'', de Behrouz Forouzan.
 
−
*Capítulos 12 a 15 do livro ''Comunicação entre Computadores e Tecnologias de Rede'', de Michael Gallo e William Hancock.
 
  
 
Revisão, com correção das listas de exercícios.
 
Revisão, com correção das listas de exercícios.
Linha 1 243: Linha 1 344:
 
Na sala de aula  ...
 
Na sala de aula  ...
  
−
=== Conceitos ===
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova3-2011-1.pdf Prova de 2011-1]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova3-2010-2.pdf Prova de 2010-2]
 +
 
 +
== 04/11: WAN: Frame-Relay e MPLS ==
  
 +
* Introdução a WAN: conceitos básicos (ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula13.pdf transparências])
  
−
== 04/11: WAN: Frame-Relay e MPLS ==
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab12.pdf Experimento sobre Frame-Relay]
 +
** [http://www.ciscopress.com/articles/article.asp?p=170741 Guia da Cisco sobre Frame Relay]
 +
 
 +
 
 +
'''Ver também:'''
 +
*Capítulo 18 do livro ''Comunicação de Dados e Redes de Computadores, 3a ed.'', de Behrouz Forouzan.
 +
*Capítulos 12 a 15 do livro ''Comunicação entre Computadores e Tecnologias de Rede'', de Michael Gallo e William Hancock.
  
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista8.pdf 8a lista de exercícios]
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista8.pdf 8a lista de exercícios]
Linha 1 259: Linha 1 370:
 
** [http://www.ietf.org/rfc/rfc3032.txt MPLS Label Stack Encoding]
 
** [http://www.ietf.org/rfc/rfc3032.txt MPLS Label Stack Encoding]
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/mpls-linux Documentação sobre os experimentos com MPLS (tirados do projeto MPLS-Linux)]
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/mpls-linux Documentação sobre os experimentos com MPLS (tirados do projeto MPLS-Linux)]
−
 
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab13-mpls.pdf 1o Experimento com MPLS]
 
−
** [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/mpls.conf Lab do netkit com o experimento]
 
−
** Os experimentos usarão o [[Netkit#Switches_MPLS|Netkit e MPLS]]
 
  
 
=== MPLS: Multi Protocol Label Switching ===
 
=== MPLS: Multi Protocol Label Switching ===
Linha 1 333: Linha 1 440:
 
== 08/11: WAN: MPLS ==
 
== 08/11: WAN: MPLS ==
  
−
* Concluir a atividade da [[RCO2-2010-2#04.2F11:_WAN:_Frame-Relay_e_MPLS|aula anterior]].
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab13-mpls.pdf 1o Experimento com MPLS]
 +
** [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/mpls.conf Lab do netkit com o experimento]
 +
** Os experimentos usarão o [[Netkit#Switches_MPLS|Netkit e MPLS]]
  
 
O exercício proposto em aula - fazer o LSP entre A2 e A1 passar por E5 ao invés de E3 - implica modificar a configuração dos roteadores E2, E3, E4 e E5:
 
O exercício proposto em aula - fazer o LSP entre A2 e A1 passar por E5 ao invés de E3 - implica modificar a configuração dos roteadores E2, E3, E4 e E5:
Linha 1 350: Linha 1 459:
 
* [http://novaoi.oi.com.br/portal/site/NovaOi/menuitem.5853151550f56e9faf022086f26d02a0/?vgnextoid=02fd7f9586fb2110VgnVCM10000090cb200aRCRD Oi]
 
* [http://novaoi.oi.com.br/portal/site/NovaOi/menuitem.5853151550f56e9faf022086f26d02a0/?vgnextoid=02fd7f9586fb2110VgnVCM10000090cb200aRCRD Oi]
  
−
=== Atividade de hoje: Labelspaces e túneis ===
+
== 10/11: WAN: MPLS (labelspaces e túneis) ==
  
 
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab14-mpls.pdf Roteiro sobre labelspaces e túneis MPLS]
 
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab14-mpls.pdf Roteiro sobre labelspaces e túneis MPLS]
Linha 1 364: Linha 1 473:
 
* Ler [http://www.alcatel-lucent.com/solutions/mpls4ips/docs/MPLS_EEI_wp.pdf este outro texto sobre MPLS], da Alcatel-Lucent.
 
* Ler [http://www.alcatel-lucent.com/solutions/mpls4ips/docs/MPLS_EEI_wp.pdf este outro texto sobre MPLS], da Alcatel-Lucent.
  
−
== 11/11: WAN: MPLS ==
+
== 11/11: WAN MPLS ==
  
 
=== Atenção: 4a avaliação ===
 
=== Atenção: 4a avaliação ===
−
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/trabalhos/trab-wan-2011-1.pdf Trabalho sobre WAN]
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/trabalhos/trab-wan-2011-2.pdf Trabalho sobre WAN]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/trabalhos/wan.conf Configuração do Netkit para o trabalho WAN]
  
−
'''OBS (para professor): adicionar aqui referência para comandos de rede do Linux (ifconfig, route, ...)'''
+
<!-- '''OBS (para professor): adicionar aqui referência para comandos de rede do Linux (ifconfig, route, ...)''' -->
  
−
[[Imagem:Wan-2011-1.png|640px]]
+
[[Imagem:Wan-2011-2.png|640px]]
  
−
==== Conceitos ====
+
'''''CUIDADO:''''' Não use rótulos entre 0 e 15, pois são reservados (ver [http://www.networkers-online.com/blog/2009/01/mpls-labels/ detalhes]).'''
  
−
 
+
=== Label merging ===
−
 
 
−
'''''CUIDADO:''''' Não use rótulos entre 0 e 15, pois são reservados (ver [http://www.networkers-online.com/blog/2009/01/mpls-labels/ detalhes]).'''
 
−
 
 
−
 
 
−
=== Label merging ===
 
  
 
* ''Label merging:'' [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab15-mpls.pdf roteiro do experimento]
 
* ''Label merging:'' [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab15-mpls.pdf roteiro do experimento]
Linha 1 391: Linha 1 496:
 
No exemplo acima, os LSP ''A1 -> A3'' e ''A2 -> A3'' seguem o mesmo caminho a partir do roteador E3. Assim, a partir desse ponto eles podem ser fundidos. Porém os LSP ''A3 -> A1'' e ''A3 -> A2'' não podem ser fundidos, já que os caminhos que eles seguem terminam em destinos diferentes.
 
No exemplo acima, os LSP ''A1 -> A3'' e ''A2 -> A3'' seguem o mesmo caminho a partir do roteador E3. Assim, a partir desse ponto eles podem ser fundidos. Porém os LSP ''A3 -> A1'' e ''A3 -> A2'' não podem ser fundidos, já que os caminhos que eles seguem terminam em destinos diferentes.
  
−
 
+
== 22/11: Redes sem-fio: introdução ==
−
== 18/11: Redes sem-fio: introdução ==
 
  
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula15.pdf transparências]
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula15.pdf transparências]
Linha 1 439: Linha 1 543:
 
''Redes entre veículos (experimental)''
 
''Redes entre veículos (experimental)''
  
−
== 22/11: Redes sem-fio: padrão IEEE 802.11 ==
+
=== Padrão IEEE 802.11 ===
  
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula15.pdf transparências]
 
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula15.pdf transparências]
Linha 1 447: Linha 1 551:
 
* Ver este [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro on-line] sobre redes IEEE 802.11. (precisa do ''gnochm'' ou ''chmsee'' para ser lido)
 
* Ver este [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro on-line] sobre redes IEEE 802.11. (precisa do ''gnochm'' ou ''chmsee'' para ser lido)
  
−
* Continuaremos o experimento iniciado [[RCO2-2010-2#23.2F11:_Redes_sem-fio:_padr.C3.A3o_IEEE_802.11|aula passada]]:
+
<!--* Continuaremos o experimento iniciado [[RCO2-2010-2#23.2F11:_Redes_sem-fio:_padr.C3.A3o_IEEE_802.11|aula passada]]:
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab16-wlan.pdf Roteiro do experimento]
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab16-wlan.pdf Roteiro do experimento]-->
  
 
Apresentaram-se as características de comunicação e propagação de sinal em uma rede sem-fio multiponto,  
 
Apresentaram-se as características de comunicação e propagação de sinal em uma rede sem-fio multiponto,  
 
introduzindo-se os problemas a serem considerados pelo protocolo MAC.
 
introduzindo-se os problemas a serem considerados pelo protocolo MAC.
  
−
A aula foi usada em parte para a apresentação do trabalho do Jonas (Observador Didático de Protocolos de Roteamento).  
+
== 25/11: Redes sem-fio: padrão IEEE 802.11 ==
  
−
== 25/11: Redes sem-fio: padrão IEEE 802.11 ==
+
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista9-2010-2.pdf 9a lista de exercicios].
  
 
Continuação sobre o MAC CSMA/CA.
 
Continuação sobre o MAC CSMA/CA.
Linha 1 524: Linha 1 628:
 
  !Upstream (kB/s)
 
  !Upstream (kB/s)
 
  |-
 
  |-
−
  |332|| 264
+
  |369||  
−
|-
 
−
|304 || 252
 
 
  |-
 
  |-
−
  |195 || 274
+
  |389 ||  
 
  |-
 
  |-
−
  |200 || 250
+
  |360 ||  
 
  |-
 
  |-
−
  |201 || 252
+
  |368 ||  
−
|-
 
−
|199 || 296
 
 
  |}
 
  |}
−
 
−
== 29/11: Redes sem-fio: desempenho do MAC CSMA/CA ==
 
−
 
−
* Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula15.pdf transparências]
 
−
* Ver capítulo 15 do livro ''Comunicação de Dados e Redes de Computadores, 3a ed.'', de Behrouz Forouzan.
 
−
* Ver capítulo 6 do livro ''Redes de Computadores e a Internet, 3a ed.'', de James Kurose.
 
−
* Ver capítulo 4 (seção 4.4) do livro ''Redes de Computadores, 4a ed.'', de Andrew Tanenbaum.
 
−
* Ver este [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro on-line] sobre redes IEEE 802.11. (precisa do ''gnochm'' ou ''chmsee'' para ser lido)
 
−
 
−
Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista9-2010-2.pdf 9a lista de exercicios].
 
−
 
−
Discussão sobre [[RCO2-2010-2#23.2F11:_Redes_sem-fio:_padr.C3.A3o_IEEE_802.11|experimento da aula passada]].
 
  
 
=== Desempenho estimado do MAC CSMA/CA ===
 
=== Desempenho estimado do MAC CSMA/CA ===
Linha 1 570: Linha 1 658:
 
** signal extension (trailer PHY): 6 us
 
** signal extension (trailer PHY): 6 us
  
 +
== 29/11: Redes sem-fio IEEE 802.11: formação de BSS. Sistemas de Distribuição ==
  
−
== 02/12: Redes Ad Hoc ==
+
* Ver capítulos 8, 20, 21, 23 e 25 do [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro sobre IEEE 802.11]
 +
* Ver capítulo 8 (seção 8.6.4) do livro ''Redes de Computadores, 4a ed.'' de Anndrew Tanenbaum.
 +
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista10.pdf 10a lista de exercícios]
  
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab17-wlan.pdf Roteiro do experimento]
+
=== Autenticação e associação ===
  
−
* Ausência de uma estação base (ou ''Access Point'')
+
Originalmente foi definido na norma IEEE 802.11 que uma estação precisa se autenticar e associar a um BSS para poder transmitir dados. Em sua forma mais simples, esses procedimentos demandam apenas quatro quadros de controle no total, sendo dois para cada operação. A sequência de autenticação em sua forma  mais simples é denominada ''Autenticação aberta'', mostrada abaixo:
−
* Cada estação pode se comunicar diretamente com qualquer outra estação em seu alcance
 
−
* Problemas dos nodos  escondidos e expostos se manifestam intensamente
 
−
* Demandam roteamento especializado (ex: [http://en.wikipedia.org/wiki/Ad_hoc_On-Demand_Distance_Vector_Routing AODV], [http://en.wikipedia.org/wiki/OLSR OLSR])
 
  
 +
[[imagem:80211-auth.png]]<br>
 +
''Autenticação aberta''
  
−
[[imagem:Adhoc1.jpg]]
 
−
<br>''Podem  possibilitar a criação de uma rede local temporária em um ambiente previamente sem infraestrutura (AP)''
 
  
 +
Como se pode ver, chamar essa operação de autenticação é forçar o uso desse termo porque o AP (que controla o BSS) não confere a identidade informada pela estação. Assim, outra forma de autenticação foi criada para conferir a informação passada pela estação, além de negociar chave de encriptação para ter o sigilo das comunicações. Esse novo método se chama ''Autenticação com chave compartilhada'', sendo implementado pelo WEP (e lembre que isso é inseguro e não deve ser usado em redes reais ;-):
  
 +
[[imagem:80211-shared-key-auth.png]]<br>
 +
''Autenticação com chave compartilhada''
  
−
[[imagem:Adhocnet.gif|400px]]
+
Uma vez estando a estação em estado autenticado, deve ocorrer a associação com o AP. Na associação o AP registra a existência da estação de forma que o sistema de distribuição (''DS'', que interliga os AP) saiba em que AP se encontra essa estação e possa assim lhe encaminhar quadros. A norma IEEE 802.11 proíbe explicitamente a associação a mais de um AP simultaneamente.
−
<br>''Podem formar redes temporárias entre equipamentos móveis''
 
  
 +
[[imagem:80211-associate.png]]<br>
 +
''Associação com AP''
  
 +
=== Sistemas de Distribuição ===
  
−
[[imagem:Vanet.gif|400px]]
 
−
<br>''Podem  ser usadas como base para aplicações inovadoras, como  redes veiculares ''
 
  
−
=== Problemas sobre nodos escondidos e expostos ===
+
Em uma rede IEEE 802.11, vários BSS podem se combinar para formarem um ESS (Extended Station Set). A interligação entre os AP deve ser feita em nível de enlace, seja por uma rede cabeada ou por links sem-fio. Essa interligação é denominada Sistema de Distribuição, estando exemplificada na figura abaixo:
  
−
# De acordo com a rede sem-fio em modo ad hoc mostrada na figura abaixo, assumindo que o MAC  seja o CSMA/CA, identifique:
 
−
#* Quais estações não conseguem transmitir simultaneamente, devido ao problema dos nodos expostos
 
−
#* Para cada estação, identifique todas as estações que podem transmitir simultaneamente (independente da estação destino). Quer dizer, que estações podem transmitir sem risco de colisões devido ao problema dos nodos escondidos. <br><br>[[imagem:Rede-sem-fio1.png|600px]]<br>
 
−
# Faça a mesma análise para a rede mostrada abaixo: <br><br>[[imagem:Rede-sem-fio2.png|600px]]
 
  
−
== 06/12: Redes sem-fio: transição entre BSS em rede infra-estruturada (handover) ==
+
[[imagem:80211-ds.png|400px]]
  
−
* Ver capítulos 8, 20, 21, 23 e 25 do [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro sobre IEEE 802.11]
 
−
* Ver capítulo 8 (seção 8.6.4) do livro ''Redes de Computadores, 4a ed.'' de Anndrew Tanenbaum.
 
−
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista10.pdf 10a lista de exercícios]
 
  
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab19-wlan-2010-2.pdf Roteiro do experimento]
+
O sistema de distribuição funciona como uma ponte entre as WSTA, como mostrado na figura abaixo. Assim, se dois AP forem interligados, as WSTA que pertencem a seus BSS poderão se comunicar como se estivessem na mesma rede local.  
  
−
=== Autenticação e associação ===
 
  
−
Originalmente foi definido na norma IEEE 802.11 que uma estação precisa se autenticar e associar a um BSS para poder transmitir dados. Em sua forma mais simples, esses procedimentos demandam apenas quatro quadros de controle no total, sendo dois para cada operação. A sequência de autenticação em sua forma  mais simples é denominada ''Autenticação aberta'', mostrada abaixo:
+
[[imagem:80211-ds2.png|400px]]
  
−
[[imagem:80211-auth.png]]<br>
+
=== Atividade ===
−
''Autenticação aberta''
 
  
 +
Será criada uma rede sem-fio composta por três BSS, que formarão o ESS "redes2". Essa rede sem-fio estará em uma subrede separada da rede do laboratório, havendo um computador com papel de gateway. Duas configurações serão testadas:
 +
# Os AP estarão interligados por um DS via rede cabeada<br><br>[[imagem:Lab-ds-1.png|400px]]<br><br>
 +
# Os AP estarão interligados por um WDS. <br><br>[[imagem:Lab-ds-2.png|400px]]<br><br>
 +
Em ambos os casos, serão feitos downloads de arquivos longos para estimar a vazão que pode ser obtida.
  
−
Como se pode ver, chamar essa operação de autenticação é forçar o uso desse termo porque o AP (que controla o BSS) não confere a identidade informada pela estação. Assim, outra forma de autenticação foi criada para conferir a informação passada pela estação, além de negociar chave de encriptação para ter o sigilo das comunicações. Esse novo método se chama ''Autenticação com chave compartilhada'', sendo implementado pelo WEP (e lembre que isso é inseguro e não deve ser usado em redes reais ;-):
+
== 02/12: Redes Ad Hoc ==
  
−
[[imagem:80211-shared-key-auth.png]]<br>
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab17-wlan.pdf Roteiro do experimento]
−
''Autenticação com chave compartilhada''
 
  
−
Note que no caso de se usar WPA ou WPA2, a autenticação é transferida para depois da associação. Porém, por compatibilidade com o que foi definido originalmente na norma, deve-se efetuar a autenticação aberta antes da associação.
+
* Ausência de uma estação base (ou ''Access Point'')
 +
* Cada estação pode se comunicar diretamente com qualquer outra estação em seu alcance
 +
* Problemas dos nodos  escondidos e expostos se manifestam intensamente
 +
* Demandam roteamento especializado (ex: [http://en.wikipedia.org/wiki/Ad_hoc_On-Demand_Distance_Vector_Routing AODV], [http://en.wikipedia.org/wiki/OLSR OLSR])
  
−
Uma vez estando a estação em estado autenticado, deve ocorrer a associação com o AP. Na associação o AP registra a existência da estação de forma que o sistema de distribuição (''DS'', que interliga os AP) saiba em que AP se encontra essa estação e possa assim lhe encaminhar quadros. A norma IEEE 802.11 proíbe explicitamente a associação a mais de um AP simultaneamente.
 
  
−
[[imagem:80211-associate.png]]<br>
+
[[imagem:Adhoc1.jpg]]
−
''Associação com AP''
+
<br>''Podem  possibilitar a criação de uma rede local temporária em um ambiente previamente sem infraestrutura (AP)''
  
  
−
=== Transição de BSS ===
 
  
−
Em redes IEEE 802.11 com mais de um AP, para ampliar a área de cobertura, estações que se movimentam podem precisar migrar de um AP para outro. Essa operação se chama ''transição de BSS'' (também conhecida como ''handover'' ou ''roaming'').
+
[[imagem:Adhocnet.gif|400px]]
 +
<br>''Podem formar redes temporárias entre equipamentos móveis''
  
−
[[imagem:Handover2.png]]
 
  
−
A transição se desencadeia quando o sinal do enlace com o AP atual tem sua qualidade abaixo de um determinado limiar. Isso faz com que um novo AP seja procurado (varredura, ou ''scanning''). Ao escolher um novo AP, a estação precisa nele se autenticar e associar. A autenticação depende do método usado (aberto, WPA-PSK à esquerda, ou WPA-EAP à direita)
 
  
−
[[imagem:Auth-rsn1.png]]  [[imagem:Auth-eap.png|400px]]
+
[[imagem:Vanet.gif|400px]]
 +
<br>''Podem  ser usadas como base para aplicações inovadoras, como  redes veiculares ''
  
 +
=== Problemas sobre nodos escondidos e expostos ===
  
−
Como se pode deduzir, a transição feita dessa forma não é imediata. Na verdade, ela pode demorar muitos segundos ! Esse atraso de transição pode influenciar negativamente nas comunicações em andamento, uma vez que a transição costuma ocorrer quando o sinal está com baixa qualidade (causando perdas de quadros), além da demora para se completar. Esforços vêm sendo feitos atualmente para reduzir o atraso de transição, e dentre eles a norma [http://en.wikipedia.org/wiki/IEEE_802.11r-2008 IEEE 802.11r] propõe um mecanismo para acelerar a autenticação. Porém o atraso de varredura ainda está por melhorar ...
+
# De acordo com a rede sem-fio em modo ad hoc mostrada na figura abaixo, assumindo que o MAC  seja o CSMA/CA, identifique:
 +
#* Quais estações não conseguem transmitir simultaneamente, devido ao problema dos nodos expostos
 +
#* Para cada estação, identifique todas as estações que podem transmitir simultaneamente (independente da estação destino). Quer dizer, que estações podem transmitir sem risco de colisões devido ao problema dos nodos escondidos. <br><br>[[imagem:Rede-sem-fio1.png|600px]]<br>
 +
# Faça a mesma análise para a rede mostrada abaixo: <br><br>[[imagem:Rede-sem-fio2.png|600px]]
  
−
A qualidade do sinal depende da modulação usada (e da taxa de dados), assim o limiar entre um BSS e outro depende de como as estações medem a qualidade de sinal e quais as taxas mínimas aceitáveis. A figura abaixo ilustra possíveis alcances para diferentes taxas de dados.
+
== 06/12: Redes sem-fio: Segurança em redes IEEE 802.11  ==
  
−
[[imagem:80211-ranges-rates.png|400px]]<br>
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula16.pdf Transparências]
−
''Taxas em função da distância do AP (exemplo, pois depende das condições do ambiente e dos equipamentos)''
+
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/802.1x_book_c2.pdf Capítulo de um livro  sobre IEEE 802.1x]
 +
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/WEP2SecurityAnalysis.ppt Uma análise sobre a segurança WEP]
 +
** Ver capítulos 5, 6 e 7 do [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro sobre IEEE 802.11]
 +
** Ver capítulo 8 (seção 8.6.4) do livro ''Redes de Computadores, 4a ed.'' de Anndrew Tanenbaum.
 +
** [http://techdir.rutgers.edu/wireless.html Bom artigo sobre segurança em redes sem-fio]
 +
** [http://aboba.drizzlehosting.com/IEEE/ The Unofficial 802.11 Security Web Page]
  
  
−
Esta outra figura ilustra as taxas em função da distância para um cenário sem obstáculos, e assumindo alguns parâmetros típicos de equipamentos (ver o capítulo 23 do livro ''"802.11 Wireless Networks The Definitive Guide"'').
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18-2010-2.pdf Roteiro do experimento]
 +
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18 Arquivos para o wpa_supplicant]
 +
** [http://www.aircrack-ng.org/ Aircrack-ng] (software para quebrar chaves WEP e WPA-PSK)
 +
*** [http://www.aircrack-ng.org/doku.php?id=simple_wep_crack Um guia rápido para quebra de chaves WEP]
 +
*** [http://www.aircrack-ng.org/doku.php?id=cracking_wpa Um tutorial sobre como quebrar WPA/WPA2]
  
−
[[imagem:80211-ranges.png]]
+
Redes sem-fio oferecem muitos atrativos, como acesso ubíquo, ausência de cabeamento e suporte a usuários móveis. Mas também se sujeitam a uso indevido, uma vez que pessoas não-autorizadas no alcance do sinal do ponto de acesso podem tentar usá-la para se comunicarem. Em geral três questões fundamentais aparecem no que diz respeito à [http://en.wikipedia.org/wiki/Wireless_security segurança em redes sem-fio]:
  
−
Assim, a cobertura de uma área envolve um planejamento que leve em conta as taxas mínimas desejáveis e as características dos equipamentos (potências de transmissão e ganhos de antenas) e do ambiente (existência de obstáculos, reflexões, e fontes de ruído). Além disso, deve-se minimzar a interferência entre BSS vizinhos, o que pode ser feito escolhendo-se canais que não se sobreponham. A figura abaixo mostra conceitualmente como se podem escolher os canais dos AP para atingir esse objetivo.
+
# ''Acesso indevido:'' uso indevido da infraestrutura por pessoas não-autorizadas.
 +
# ''Monitoramento do tráfego da rede:'' os quadros na rede sem-fio podem ser coletados e interpretados, com possível roubo ou revelação de informação sensível.
 +
# ''Infiltração de equipamentos na rede:'' um ou mais pontos de acesso podem ser infiltrados na rede sem-fio (chamados de [http://en.wikipedia.org/wiki/Rogue_access_point ''Rogue AP'']), fazendo com que pessoas os utilizem para se comunicarem. Assim, o tráfego dessas pessoas pode passar por outra rede, sendo passível de monitoramento.
  
−
[[imagem:80211-freq-planning.png]]
+
Por exemplo, redes em locais densamente ocupados (como edifícios) podem ser investigadas por alguém em busca de uma rede aberta ou fácil de ser invadida. Essa pessoa pode simplesmente querer usar o acesso à Internet disponível em alguma rede sem-fio, ou mesmo invadir os equipamentos existentes em tal rede. A figura abaixo mostra a técnica de [http://en.wikipedia.org/wiki/Wardriving WarDriving], em que uma pessoa investiga a existência de redes sem-fio a partir de um carro que trafega pelas ruas.
  
 +
[[imagem:View_from_Wardriver_Windshield.jpg]]
  
−
Desta forma, podem-se criar BSS para cobrir uma área e aproveitar melhor a capacidade do meio de transmissão.
+
Existem inclusive símbolos ([http://pt.wikipedia.org/wiki/Warchalking ''warchalking'']) usados para indicar em ruas e edifícios a existência de redes sem-fio abertas. Esta rápida explicação sobre ''warchalking'' foi obtida em um [http://www.clubedowarchalking.com.br/index.php?option=com_content&view=article&id=43&Itemid=53 artigo sobre WarChalking]:
  
−
[[imagem:80211-cobertura.png]]
+
<syntaxhighlight lang=text>
 +
O warchalking foi criado pelo web designer Matt Jones que, enquanto almoçava com dois amigos, viu alguns estudantes
 +
utilizando conexões wireless para trabalhar a partir de uma praça pública, como se fosse um escritório. Um dos amigos de
 +
Matt lembrou-se de uma “linguagem” de sinais utilizada por mendigos e viajantes com o objetivo de informar onde poderiam
 +
achar comida grátis, uma cama confortável ou até mesmo encrenca, e surgiu a idéia de demarcar a presença de redes wireless
 +
com sinais parecidos.
 +
</syntaxhighlight>
  
−
=== Medição da qualidade de enlace ===
 
  
−
Em um [http://www.wirelessforums.org/hardware-discussion/measuring-link-quality-4809.html forum] encontrou-se o seguinte questionamento:
+
Os símbolos do ''warchalking'' são:
  
−
<syntaxhighlight lang=text>
+
[[imagem:Warchalking2.jpg]]
−
Hello,
 
  
  
−
the 802.11 standard specifies that link quality should be (for DSSS modulation) calculated from the correlation value obtained
+
Assim, uma rede sem-fio minimamente bem configurada deve usar mecanismos de segurança que impeçam ou dificultem seu uso indevido. Em um cenário usual, tal rede sem-fio poderia se apresentar como mostrado abaixo:
−
when code lock is achieved between the local PN code and the incoming PN codes.
 
  
−
In practice however I am convinced that Wi-Fi cards' producers do not calculate it in this way but rather by the percentage of
+
[[imagem:Wifi-security1.png]]
−
correctly recieved bits or as the difference between signal strength and noise level.
+
 
 +
 
 +
Para tratar essas questões, deve haver mecanismos de segurança que contemplem os seguintes requisitos:
 +
 
 +
# ''Autenticação de usuários:'' usuários da rede sem-fio devem se identificar (ou ''autenticar'') na infra-estrutura dessa rede, de forma a se autorizarem ou não seus acessos.
 +
# ''Sigilo das comunicações:'' o tráfego na rede sem-fio deve ser encriptado, para que não seja inteligível caso sejam capturados por usuários mal-intencionados que estejam monitorando a rede sem-fio.
 +
# ''Autenticação dos pontos de acesso:'' pontos de acesso devem se identificar para os usuários, para evitar a infiltração de pontos de acesso indevidos na rede.
  
−
I am currently doing some research on the possibility of using a 802.11 signal in a Wi-Fi LAN for locational purposes and I
+
Há mecanismos de segurança usados em redes IEEE 802.11 que contemplam todos os requisitos acima (WPA-EAP, WPA Enterprise), ou parcialmente (WPA-PSK ou WPA Personal). WPA-EAP aproveita a infraestrutura IEEE 802.1x, junto com técnicas de encriptação entre estações sem-fio, para atender esses requisitos. Já WPA-PSK usa apenas as técnicas de encriptação, não havendo um controle de acesso baseado em usuário. Na figura abaixo se mostra uma pequena rede sem-fio que usa WPA-EAP.
−
would like to consider all the information available to estimate a terminal's position. That includes, signal strength, noise
 
−
level and link quality. However I cannot use link quality if I am not sure of how it is calculated.
 
  
−
Does anyone know how I can find a Wi-Fi card whose vendors specify their method of determining the link quality? Or a card from
+
[[imagem:Wifi-auth.jpeg]]
−
which I can extract a link quality according to the definition of the standard?
 
−
</syntaxhighlight>
 
  
−
Há  também um outro [http://www.rigacci.org/wiki/doku.php/doc/appunti/linux/sa/wifi_signal_quality bom texto], com explicações sobre muitos termos usados quando se trata da qualidade do link (tais como RSSI e SNR). Um tanto comprido, por isso não o copiei aqui.
+
Além dos mecanismos WPA, definidos na norma [http://en.wikipedia.org/wiki/IEEE_802.11i-2004 IEEE 802.11i], outra forma de implantar controle de acesso em redes sem-fio se vale de um ''portal de captura''. Quando um usuário não identificado acessa a rede, o acesso ao ponto de acesso é concedido mas ao tentar navegar na Web seu acesso é desviado para uma página predefinida. Nessa página o usuário deve se identificar (ex: com ''login'' e senha), e em caso de sucesso seu acesso à Internet é liberado. Essa técnica se vale de uma combinação de mecanismos (firewall com filtro IP, serviço Web, uso de programas para autenticação) para controlar o acesso dos usuários. No entanto, não provê sigilo das comunicações nem autenticação de pontos de acesso ao usuário. Sua atratividade reside na simplicidade de implantação e uso (não necessita de ''supplicant''), sendo uma escolha comum em ''hot spots'' como aeroportos e ''cyber cafes''. No [[Projeto_Integrador_-_2009.2| Projeto Integrador 2009.2]] as equipes implantaram uma infra-estrutura que usava essa técnica.
  
−
O texto acima questiona como se faz a medição de qualidade de enlace em uma rede sem-fio IEEE 802.11.  Nele se observa que a norma define como se deve fazer isso, mas os  fabricantes provavelmente  não seguem isso à risca. Partindo desse texto, pesquise como um determinado fabricante ou modelo de interface de rede faz essa medição (ex: Atheros, D-Link, Ralink, Intel, Broadcom, ...).
+
== 09/12: finalização ... ==
  
−
== 09/12: Redes sem-fio: Segurança em redes IEEE 802.11  ==
+
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/prova4-2011-1.pdf Prova 4 de 2011-1]
  
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula16.pdf Transparências]
+
<!-- === Se der tempo ... ===
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/802.1x_book_c2.pdf Capítulo de um livro  sobre IEEE 802.1x]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/WEP2SecurityAnalysis.ppt Uma análise sobre a segurança WEP]
 
−
** Ver capítulos 5, 6 e 7 do [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro sobre IEEE 802.11]
 
−
** Ver capítulo 8 (seção 8.6.4) do livro ''Redes de Computadores, 4a ed.'' de Anndrew Tanenbaum.
 
−
** [http://techdir.rutgers.edu/wireless.html Bom artigo sobre segurança em redes sem-fio]
 
−
** [http://aboba.drizzlehosting.com/IEEE/ The Unofficial 802.11 Security Web Page]
 
  
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18-2010-2.pdf Roteiro do experimento]
 
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18-2010-2.pdf Roteiro do experimento]
Linha 1 703: Linha 1 804:
 
*** [http://www.aircrack-ng.org/doku.php?id=simple_wep_crack Um guia rápido para quebra de chaves WEP]
 
*** [http://www.aircrack-ng.org/doku.php?id=simple_wep_crack Um guia rápido para quebra de chaves WEP]
 
*** [http://www.aircrack-ng.org/doku.php?id=cracking_wpa Um tutorial sobre como quebrar WPA/WPA2]
 
*** [http://www.aircrack-ng.org/doku.php?id=cracking_wpa Um tutorial sobre como quebrar WPA/WPA2]
 +
*** [http://tldp.org/HOWTO/html_single/8021X-HOWTO/ Bom texto sobre IEEE 802.1X em redes sem-fio]
  
−
Redes sem-fio oferecem muitos atrativos, como acesso ubíquo, ausência de cabeamento e suporte a usuários móveis. Mas também se sujeitam a uso indevido, uma vez que pessoas não-autorizadas no alcance do sinal do ponto de acesso podem tentar usá-la para se comunicarem. Em geral três questões fundamentais aparecem no que diz respeito à [http://en.wikipedia.org/wiki/Wireless_security segurança em redes sem-fio]:
+
* [[Projeto_Integrador_-_2009.2#Instala.C3.A7.C3.A3o_de_Equipamentos_de_Rede|Exemplo de portal de captura implantado no Projeto Integrador 2009.2 do Curos Técnico em Redes]]
 +
 
 +
== 09/12: Redes sem-fio: transição entre BSS em rede infra-estruturada (handover) ==
 +
 
 +
* Ver capítulos 8, 20, 21, 23 e 25 do [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/livros/livro-802_11.chm livro sobre IEEE 802.11]
 +
* Ver capítulo 8 (seção 8.6.4) do livro ''Redes de Computadores, 4a ed.'' de Anndrew Tanenbaum.
 +
* Resolver a [http://www.sj.ifsc.edu.br/~msobral/RCO2/listas/lista10.pdf 10a lista de exercícios]
  
−
# ''Acesso indevido:'' uso indevido da infraestrutura por pessoas não-autorizadas.
+
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab19-wlan-2010-2.pdf Roteiro do experimento]
−
# ''Monitoramento do tráfego da rede:'' os quadros na rede sem-fio podem ser coletados e interpretados, com possível roubo ou revelação de informação sensível.
 
−
# ''Infiltração de equipamentos na rede:'' um ou mais pontos de acesso podem ser infiltrados na rede sem-fio (chamados de [http://en.wikipedia.org/wiki/Rogue_access_point ''Rogue AP'']), fazendo com que pessoas os utilizem para se comunicarem. Assim, o tráfego dessas pessoas pode passar por outra rede, sendo passível de monitoramento.
 
  
−
Por exemplo, redes em locais densamente ocupados (como edifícios) podem ser investigadas por alguém em busca de uma rede aberta ou fácil de ser invadida. Essa pessoa pode simplesmente querer usar o acesso à Internet disponível em alguma rede sem-fio, ou mesmo invadir os equipamentos existentes em tal rede. A figura abaixo mostra a técnica de [http://en.wikipedia.org/wiki/Wardriving WarDriving], em que uma pessoa investiga a existência de redes sem-fio a partir de um carro que trafega pelas ruas.
+
=== Autenticação e associação ===
  
−
[[imagem:View_from_Wardriver_Windshield.jpg]]
+
Originalmente foi definido na norma IEEE 802.11 que uma estação precisa se autenticar e associar a um BSS para poder transmitir dados. Em sua forma mais simples, esses procedimentos demandam apenas quatro quadros de controle no total, sendo dois para cada operação. A sequência de autenticação em sua forma  mais simples é denominada ''Autenticação aberta'', mostrada abaixo:
  
−
Existem inclusive símbolos ([http://pt.wikipedia.org/wiki/Warchalking ''warchalking'']) usados para indicar em ruas e edifícios a existência de redes sem-fio abertas. Esta rápida explicação sobre ''warchalking'' foi obtida em um [http://www.clubedowarchalking.com.br/index.php?option=com_content&view=article&id=43&Itemid=53 artigo sobre WarChalking]:
+
[[imagem:80211-auth.png]]<br>
 +
''Autenticação aberta''
  
−
<syntaxhighlight lang=text>
 
−
O warchalking foi criado pelo web designer Matt Jones que, enquanto almoçava com dois amigos, viu alguns estudantes
 
−
utilizando conexões wireless para trabalhar a partir de uma praça pública, como se fosse um escritório. Um dos amigos de
 
−
Matt lembrou-se de uma “linguagem” de sinais utilizada por mendigos e viajantes com o objetivo de informar onde poderiam
 
−
achar comida grátis, uma cama confortável ou até mesmo encrenca, e surgiu a idéia de demarcar a presença de redes wireless
 
−
com sinais parecidos.
 
−
</syntaxhighlight>
 
  
 +
Como se pode ver, chamar essa operação de autenticação é forçar o uso desse termo porque o AP (que controla o BSS) não confere a identidade informada pela estação. Assim, outra forma de autenticação foi criada para conferir a informação passada pela estação, além de negociar chave de encriptação para ter o sigilo das comunicações. Esse novo método se chama ''Autenticação com chave compartilhada'', sendo implementado pelo WEP (e lembre que isso é inseguro e não deve ser usado em redes reais ;-):
  
−
Os símbolos do ''warchalking'' são:
+
[[imagem:80211-shared-key-auth.png]]<br>
−
 
+
''Autenticação com chave compartilhada''
−
[[imagem:Warchalking2.jpg]]
+
 
−
 
+
Note que no caso de se usar WPA ou WPA2, a autenticação é transferida para depois da associação. Porém, por compatibilidade com o que foi definido originalmente na norma, deve-se efetuar a autenticação aberta antes da associação.
−
 
+
 
−
Assim, uma rede sem-fio minimamente bem configurada deve usar mecanismos de segurança que impeçam ou dificultem seu uso indevido. Em um cenário usual, tal rede sem-fio poderia se apresentar como mostrado abaixo:
+
Uma vez estando a estação em estado autenticado, deve ocorrer a associação com o AP. Na associação o AP registra a existência da estação de forma que o sistema de distribuição (''DS'', que interliga os AP) saiba em que AP se encontra essa estação e possa assim lhe encaminhar quadros. A norma IEEE 802.11 proíbe explicitamente a associação a mais de um AP simultaneamente.
−
 
+
 
−
[[imagem:Wifi-security1.png]]
+
[[imagem:80211-associate.png]]<br>
 +
''Associação com AP''
 +
 
 +
 
 +
=== Transição de BSS ===
 +
 
 +
Em redes IEEE 802.11 com mais de um AP, para ampliar a área de cobertura, estações que se movimentam podem precisar migrar de um AP para outro. Essa operação se chama ''transição de BSS'' (também conhecida como ''handover'' ou ''roaming'').
 +
 
 +
[[imagem:Handover2.png]]
 +
 
 +
A transição se desencadeia quando o sinal do enlace com o AP atual tem sua qualidade abaixo de um determinado limiar. Isso faz com que um novo AP seja procurado (varredura, ou ''scanning''). Ao escolher um novo AP, a estação precisa nele se autenticar e associar. A autenticação depende do método usado (aberto, WPA-PSK à esquerda, ou WPA-EAP à direita)
 +
 
 +
[[imagem:Auth-rsn1.png]]  [[imagem:Auth-eap.png|400px]]
 +
 
 +
 
 +
Como se pode deduzir, a transição feita dessa forma não é imediata. Na verdade, ela pode demorar muitos segundos ! Esse atraso de transição pode influenciar negativamente nas comunicações em andamento, uma vez que a transição costuma ocorrer quando o sinal está com baixa qualidade (causando perdas de quadros), além da demora para se completar. Esforços vêm sendo feitos atualmente para reduzir o atraso de transição, e dentre eles a norma [http://en.wikipedia.org/wiki/IEEE_802.11r-2008 IEEE 802.11r] propõe um mecanismo para acelerar a autenticação. Porém o atraso de varredura ainda está por melhorar ...
 +
 
 +
A qualidade do sinal depende da modulação usada (e da taxa de dados), assim o limiar entre um BSS e outro depende de como as estações medem a qualidade de sinal e quais as taxas mínimas aceitáveis. A figura abaixo ilustra possíveis alcances para diferentes taxas de dados.
 +
 
 +
[[imagem:80211-ranges-rates.png|400px]]<br>
 +
''Taxas em função da distância do AP (exemplo, pois depende das condições do ambiente e dos equipamentos)''
 +
 
 +
 
 +
Esta outra figura ilustra as taxas em função da distância para um cenário sem obstáculos, e assumindo alguns parâmetros típicos de equipamentos (ver o capítulo 23 do livro ''"802.11 Wireless Networks The Definitive Guide"'').
 +
 
 +
[[imagem:80211-ranges.png]]
 +
 
 +
Assim, a cobertura de uma área envolve um planejamento que leve em conta as taxas mínimas desejáveis e as características dos equipamentos (potências de transmissão e ganhos de antenas) e do ambiente (existência de obstáculos, reflexões, e fontes de ruído). Além disso, deve-se minimzar a interferência entre BSS vizinhos, o que pode ser feito escolhendo-se canais que não se sobreponham. A figura abaixo mostra conceitualmente como se podem escolher os canais dos AP para atingir esse objetivo.
 +
 
 +
[[imagem:80211-freq-planning.png]]
 +
 
 +
 
 +
Desta forma, podem-se criar BSS para cobrir uma área e aproveitar melhor a capacidade do meio de transmissão.
 +
 
 +
[[imagem:80211-cobertura.png]]
 +
 
 +
=== Medição da qualidade de enlace ===
 +
 
 +
Em um [http://www.wirelessforums.org/hardware-discussion/measuring-link-quality-4809.html forum] encontrou-se o seguinte questionamento:
 +
 
 +
<syntaxhighlight lang=text>
 +
Hello,
 +
 
 +
 
 +
the 802.11 standard specifies that link quality should be (for DSSS modulation) calculated from the correlation value obtained
 +
when code lock is achieved between the local PN code and the incoming PN codes.
 +
 
 +
In practice however I am convinced that Wi-Fi cards' producers do not calculate it in this way but rather by the percentage of
 +
correctly recieved bits or as the difference between signal strength and noise level.
 +
 
 +
I am currently doing some research on the possibility of using a 802.11 signal in a Wi-Fi LAN for locational purposes and I
 +
would like to consider all the information available to estimate a terminal's position. That includes, signal strength, noise
 +
level and link quality. However I cannot use link quality if I am not sure of how it is calculated.
 +
 
 +
Does anyone know how I can find a Wi-Fi card whose vendors specify their method of determining the link quality? Or a card from
 +
which I can extract a link quality according to the definition of the standard?
 +
</syntaxhighlight>
 +
 
 +
Há  também um outro [http://www.rigacci.org/wiki/doku.php/doc/appunti/linux/sa/wifi_signal_quality bom texto], com explicações sobre muitos termos usados quando se trata da qualidade do link (tais como RSSI e SNR). Um tanto comprido, por isso não o copiei aqui.
 +
 
 +
O texto acima questiona como se faz a medição de qualidade de enlace em uma rede sem-fio IEEE 802.11.  Nele se observa que a norma define como se deve fazer isso, mas os  fabricantes provavelmente  não seguem isso à risca. Partindo desse texto, pesquise como um determinado fabricante ou modelo de interface de rede faz essa medição (ex: Atheros, D-Link, Ralink, Intel, Broadcom, ...).
 +
 
 +
-->
 +
 
 +
== 13/12: Avaliação ==
  
 +
* [http://tele.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/prova4-2011-2.pdf A prova que foi aplicada ...]
  
−
Para tratar essas questões, deve haver mecanismos de segurança que contemplem os seguintes requisitos:
+
== 16/12: Recuperações ==
  
−
# ''Autenticação de usuários:'' usuários da rede sem-fio devem se identificar (ou ''autenticar'') na infra-estrutura dessa rede, de forma a se autorizarem ou não seus acessos.
+
Será feita '''uma prova para cada unidade pendente'''. Deve-se obter '''ao menos C''' em cada prova.
−
# ''Sigilo das comunicações:'' o tráfego na rede sem-fio deve ser encriptado, para que não seja inteligível caso sejam capturados por usuários mal-intencionados que estejam monitorando a rede sem-fio.
 
−
# ''Autenticação dos pontos de acesso:'' pontos de acesso devem se identificar para os usuários, para evitar a infiltração de pontos de acesso indevidos na rede.
 
  
−
Há mecanismos de segurança usados em redes IEEE 802.11 que contemplam todos os requisitos acima (WPA-EAP, WPA Enterprise), ou parcialmente (WPA-PSK ou WPA Personal). WPA-EAP aproveita a infraestrutura IEEE 802.1x, junto com técnicas de encriptação entre estações sem-fio, para atender esses requisitos. Já WPA-PSK usa apenas as técnicas de encriptação, não havendo um controle de acesso baseado em usuário. Na figura abaixo se mostra uma pequena rede sem-fio que usa WPA-EAP.
+
=== Trabalhos pendentes ===
  
−
[[imagem:Wifi-auth.jpeg]]
+
Há duas opções:
−
 
+
# Entregá-los até 19/12, às 14 h.
−
Além dos mecanismos WPA, definidos na norma [http://en.wikipedia.org/wiki/IEEE_802.11i-2004 IEEE 802.11i], outra forma de implantar controle de acesso em redes sem-fio se vale de um ''portal de captura''. Quando um usuário não identificado acessa a rede, o acesso ao ponto de acesso é concedido mas ao tentar navegar na Web seu acesso é desviado para uma página predefinida. Nessa página o usuário deve se identificar (ex: com ''login'' e senha), e em caso de sucesso seu acesso à Internet é liberado. Essa técnica se vale de uma combinação de mecanismos (firewall com filtro IP, serviço Web, uso de programas para autenticação) para controlar o acesso dos usuários. No entanto, não provê sigilo das comunicações nem autenticação de pontos de acesso ao usuário. Sua atratividade reside na simplicidade de implantação e uso (não necessita de ''supplicant''), sendo uma escolha comum em ''hot spots'' como aeroportos e ''cyber cafes''. No [[Projeto_Integrador_-_2009.2| Projeto Integrador 2009.2]] as equipes implantaram uma infra-estrutura que usava essa técnica.
+
# A partir de 14h, fazer uma prova prática para cada trabalho em haver :-b
−
 
 
−
=== Se der tempo ... ===
 
−
 
 
−
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18-2010-2.pdf Roteiro do experimento]
 
−
** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab18 Arquivos para o wpa_supplicant]
 
−
** [http://www.aircrack-ng.org/ Aircrack-ng] (software para quebrar chaves WEP e WPA-PSK)
 
−
*** [http://www.aircrack-ng.org/doku.php?id=simple_wep_crack Um guia rápido para quebra de chaves WEP]
 
−
*** [http://www.aircrack-ng.org/doku.php?id=cracking_wpa Um tutorial sobre como quebrar WPA/WPA2]
 
−
*** [http://tldp.org/HOWTO/html_single/8021X-HOWTO/ Bom texto sobre IEEE 802.1X em redes sem-fio]
 
−
 
 
−
* [[Projeto_Integrador_-_2009.2#Instala.C3.A7.C3.A3o_de_Equipamentos_de_Rede|Exemplo de portal de captura implantado no Projeto Integrador 2009.2 do Curos Técnico em Redes]]
 
−
 
 
−
== 13/12: Avaliação ==
 

Edição atual tal como às 13h21min de 20 de dezembro de 2011

Redes de Computadores II: Diário de Aula 2011-2

Professor: Marcelo Maia Sobral (msobral@gmail.com)
Lista de email (forum): rco2@googlegroups.com
Encontros: 4a feira/7:30, 5a feira/9:40
Atendimento paralelo: 4a de 10h às 12 h, 5a de 8h às 9:30h e de 13:30 às 15:00h.
IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação, e aguardar o parecer da coordenação. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina.

Bibliografia

  • Livros sobre Redes de Computadores (por ordem de preferência):
    • FOROUZAN, Behrouz. Comunicação de Dados e Redes de Computadores, 3a/4a edicão. Editora Bookman, 2004.
    • KUROSE, James F. e ROSS, Keith W. Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição. Editora Addison Wesley SP, 2010.
    • STALLINGS, W. Redes e sistemas de comunicação de dados. Editora Elsevier RJ, 2005.
    • TANENBAUM, Andrew S. Redes de Computadores, tradução da quarta edição. Editora Campus RJ, 2003
    • GALLO, Michael A. E HANCOCK Wiliam M. Comunicação entre computadores e tecnologia de rede. Ed. Pioneira Thomson Learning SP, 2003.
    • COMMER, Douglas E. Redes de Computadores e Internet – 2a edição. Editora Bookman, Porto Alegre, 2001

Curiosidades

Listas de exercícios

Avaliações

Aluno 1a prova Trabalho Protocolo 2a prova 3a prova Trabalho Switch Trabalho LANs Trabalho WAN 4a prova Conceito FINAL
Ana Paula D/C C D/D D/C C C D C D
André D/A B C B A A B B+ A
Bolívar D/D D D/D D/D B D D D/D D
Davi D/C C D/C B B A C D/C C
Kalvim B B B A A A B C+ A
Leandro D/? C? C C B D D* D
Luiz Gustavo B B C B A A B B B
Maicky C C C C A A B C+ C
Marine C C C B C B C B+ C
Mário D/C C C C A A B C C
Patrícia D/C C C C B A C B C
Thayse D/B C C C B A C B C
Thiego C C B B A A B B+ B

Legenda:

  • B?: conceito a verificar (apresentação de trabalho)
  • D/C: conceito da recuperação (C neste exemplo)
  • B+: conceito próximo do próximo nível (pode ajudar a decidir o conceito final)

Softwares

02/08: Apresentação

Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório.

Introdução e camada de enlace

  • Ver Parte III e capítulo 10 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan (há uma cópia no xerox), ou capítulo 3 do livro "redes de Computadores" de Andrew Tanenbaum.

Apresentou-se uma visão geral dos conceitos sobre comunicação de dados, amparada em transparências. Nesta aula se planta a base para iniciar o estudo com maior profundidade da camada de enlace e da camada física.

Data-link.png

Os serviços identificados na figura acima estão descritos abaixo. A eles foram acrescentados outros dois:

  • Encapsulamento (ou enquadramento): identificação das PDUs (quadros) de enlace dentro de sequências de bits enviadas e recebidas da camada física
  • Controle de erros: garantir que quadros sejam entregues no destino
    • Detecção de erros: verificação da integridade do conteúdo de quadros (se foram recebidos sem erros de bits)
  • Controle de fluxo: ajuste da quantidade de quadros transmitidos, de acordo com a capacidade do meio de transmissão (incluindo o atraso de transmissão) e do receptor
  • Endereçamento: necessário quando o enlace for do tipo multi-ponto, em que vários equipamentos compartilham o meio de transmissão (ex: redes locais e redes sem-fio)
  • Controle de acesso ao meio (MAC): também necessário para meios compartilhados, para disciplinar as transmissões dos diversos equipamentos de forma a evitar ou reduzir a chance de haver colisões (transmissões sobrepostas)
  • Gerenciamento de enlace: funções para ativar, desativar e manter enlaces

Atividade

Uma empresa possui uma filial em outra cidade do estado, e precisa estabelecer um enlace dedicado que a una a matriz. Por esse enlace trafegarão dados de aplicativos administrativos da empresa (ex: ERP), e de gerência de redes. A solução para o problema deve contemplar essas questões:

  1. Que tecnologias podem ser usadas ? Quais suas características ?
  2. Qual a viabilidade para implantação de cada uma delas ?

Após decidirmos como implantar esse enlace, será feito um experimento no laboratório simulando a solução.

A escolha após discussão em aula foi por um circuito dedicado com pares metálicos para o enlace físico, e o protocolo PPP para o enlace lógico.

Questões a serem respondidas pela turma mediante pesquisa na bibliografia ou outras fontes:

  1. Para que cenários foi criado o protocolo PPP ? Ele exige alguma característica especial do enlace físico ?
  2. Ele pode ser usado por qualquer protocolo de camada de rede ?
  3. Qual o formato dos quadros desse protocolo, e qual o overhead de seus dados de controle ?
  4. Como esse protocolo identifica onde começa e termina cada quadro durante a transmissão (pense nos quadros sendo recebidos) ?
  5. O que acontece se um quadro sofrer um erro durante a transmissão ? Quer dizer, se um quadro for perdido durante a transmissão (não chegar ao destino), ou chegar corrompido ?

Pesquise e responda as questões acima, para que possam ser discutidas na próxima aula.

05/08: Enquadramento

  • Ver Parte III e capítulo 12 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan (há uma cópia no xerox), ou capítulo 3 do livro "Redes de Computadores" de Andrew Tanenbaum.


Rede2-IER.png
Exemplo de enlace ponto-a-ponto entre roteadores


Transparências sobre camada de enlace

Atividade

Nesta aula se criarão enlaces ponto-a-ponto entre computadores, usando o protocolo PPP. A partir de alguns experimentos se discutem os serviços da camada de enlace, em particular o enquadramento e detecção de erros.

Lab1-2011-1.png
Rede do experimento


A rede do experimento será inicialmente implantada usando o Netkit, um software para emulação de redes. A configuração necessária para criá-la segue abaixo: 

pc1[type]=generic
pc2[type]=generic
r1[type]=gateway
r2[type]=gateway
 
pc1[eth0]=rede0:ip=192.168.0.1/26
r1[eth0]=rede0:ip=192.168.0.62/26
r1[ppp0]=serial:rate=115200
 
pc2[eth0]=rede1:ip=192.168.1.1/24
r2[eth0]=rede1:ip=192.168.1.254/24
r2[ppp0]=serial:rate=115200

pc1[default_gateway]=192.168.0.62
pc2[default_gateway]=192.168.1.254

Roteiro do primeiro laboratório


Atividade para próxima aula

Reflita sobre o problema descrito a seguir:

No exemplo baseado no enlace entre duas unidades de uma empresa, imagine que o enlace físico apresente uma taxa de erros de 0,001% (i.e. a cada 100000 bits transmitidos, em média um bit chega com erro). Usando-se o protocolo PPP na camada de enlace, quais as possíveis consequências para as seguintes aplicações:

  1. Web (HTTP e HTTPS)
  2. DNS
  3. Email (POP3 e SMTP)
  4. VoIP

Seria possível que alguma modificação na camada de enlace reduzisse ou eliminasse os problemas apontados ? Caso acredite que sim, o que poderia ser feito ?

09/08: Detecção de erros

  • Ver capítulos 10 e 11 do livro Comunicação de Dados e Redes de Computadores, de Behrouz Forouzan.
  • Ver capítulo 5 do livro Redes de Computadores e a Internet, de James Kurose.
  • Ver capítulo 4 do livro Redes de Computadores, de Andrew Tanenbaum.
  • Resolver a 1a lista de exercícios.

Probabilidade de erros de transmissão (BER - Bit Error Rate), códigos de detecção de erro e CRC

Há um resumo nas transparências.

O experimento com o gerador de CRC-16 do PPP pode ser repetido em casa. Ele é capaz de verificar um quadro PPP, que pode ser conseguido usando-se a opção record do pppd. Essa opção grava em um arquivo de log os conteúdos dos quadros PPP enviados e recebidos, que podem depois serem visualizados (ou terem seu bytes extraídos) com o utilitário pppdump. Porém o gerador de CRC-16 fornecido inclui dois arquivos contendo quadros PPP previamente coletados: quadro_correto.raw e quadro_errado.raw. Eles podem ser verificados com o programa fcs (o verificador de CRC-16): 

# descompacta o arquivo do gerador de CRC-16
tar czf fcs-rfc.tgz
cd fcs

# Testa o quadro correto
./fcs quadro_correto.raw

# Testa o quadro_errado
./fcs quadro_errado.raw

Há um testador que modifica aleatoriamente uma certa quantidade de bits do quadro_correto.raw, até que encontre um caso em que o erro não seja detectado. Para usá-lo deve-se executar o programa testa.py: 

# executa testa.py com 4 erros de bit por quadro gerados aleatoriamente
./testa.py 4

O código fonte do gerador de CRC-16 está no arquivo fcs-rfc.c, o qual foi obtido diretamente da RFC 1662.

Detecção de erros no PPP

Pode-se testar a detecção e o tratamento de erros do PPP injetando-se quadros com erros em um enlace previamente estabelecido. Isso pode ser verificado usando-se o Netkit:

  1. Crie o arquivo Lab.conf com o seguinte conteúdo: 
    pc1[type]=generic
pc2[type]=generic

pc1[ppp0]=link_serial:ip=10.0.0.1/30
pc2[ppp0]=link_serial:ip=10.0.0.2/30
  2. Inicie o experimento do Netkit: 
    labstart -p teste
  3. Na máquina real faça o download dos arquivos que contêm quadros PPP especialmente criadaos para esse experimento. Descompacte esse arquivo dentro de teste/shared.
  4. Note que existe um enlace PPP entre as máquinas virtuais. Na máquina virtual pc1 deixe o tcpdump monitorando a interface ppp0: 
    tcpdump -i ppp0 -ln
  5. Na máquina virtual pc2 será feita a injeção de quadros PPP no enlace. A ideia é transmitir quadros corretos e em seguida quadros com erros (i.e. com bits propositalmente modificados), e observar como o PPP na máquina virtual pc1 trata esses quadros. Para isso, primeiro deve-se terminar o pppd em pc2: 
    killall -9 pppd
    Isso é necessário para que se consigam injetar os quadros via porta serial /dev/ttyS0. Observe que em pc o pppd continua rodando como se nada tivesse acontecido (quer dizer, para pc1 o enlace ainda está ativo).
  6. Injete o quadro correto em pc2, observando o que mostra o tcpdump em pc1: 
    cd /hostlab/shared
cat quadro.ok > /dev/ttyS0
  7. Agora injete o quadro com erros e veja o que acontece: 
    cd /hostlab/shared
cat quadro.erro > /dev/ttyS0
  8. O que se pode concluir quanto à recepção pelo PPP de quadros com erros de transmissão ?

Trabalho do Módulo 1

O trabalho do primeiro módulo da disciplina trata da implementação de um protocolo de enlace ponto-a-ponto, que deve estabelecer um enlace entre dois computadores por meio de suas portas seriais. O protocolo de enlace deve-se integrar à pilha de protocolos TCP/IP do Linux, podendo assim transmitir e receber datagramas IP.

O protocolo de enlace deve prover os seguintes serviços de enlace:

  1. Encapsulamento e enquadramento (requisito mínimo, gerando um conceito C).
  2. Detecção de erros (opcional, gerando conceito B)
  3. Controle de erros pare-e-espere (opcional, gerando conceito A)

Para realizar o trabalho será usado o Netkit, um projeto da Universidade de Roma para experimentação com redes virtuais baseadas em Linux.

  • Data limite de entrega: 10/09
    • Entrega deve constar de código fonte, demonstração de funcionamento e resposta a questões colocadas pelo professor.
    • Cada serviço de enlace somente será considerado correto se plenamente funcional (e sem erros).
  • Pode ser feito em grupos de até dois alunos.

12/08: Controle de erros: stop-and-wait

Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan (há uma cópia no xerox).

Resolver a 1a lista de exercícios.

Mecanismos ARQ para controle de erros:

  • Stop-and-Wait: só transmite o próximo quadro quando receber uma confirmação (ACK) do último quadro enviado. Retransmite o último quadro enviado se um tempo máximo de espera pelo ACK (ou timeout) for excedido.
  • Go-Back-N: transmite até N quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite todos os quadros a partir desse quadro.
  • Selective Repeat: transmite até N quadros sem receber confirmação, quando então espera os ACK antes de enviar mais quadros. Caso exceda o timeout de um dos quadros enviados, retransmite somente esse quadro.

Desempenho esperado do Stop-and-Wait.

Simulações com Omnet++

Na aula foi mostrada uma simulação de protocolo de enlace que usa Stop-and-Wait. Essas simulações foram criadas usando-se o simulador de redes Omnet++. Abaixo segue um tutorial para instalar esse simulador em seu computador (assume-se que nele haja o Ubuntu Linux 9.04 ou superior):

16/08: NÃO HAVERÁ AULA DE REDES 2

19/08: Controle de erros e de fluxo: Go-back-N e Selective Repeat

  • Resolver a 1a lista de exercícios. Ela deve ser entregue por email (preferencialmente em PDF) até a próxima aula (10/03).

Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Berhouz Forouzan.

Na aula anterior foi visto que o mecanismo ARQ Stop-and-wait é eficaz no controle de erros. Isto significa que ele garante que um quadro seja entregue no destino. Além disto, o Stop-and-wait não se atrapalha se ocorrerem os seguintes erros de transmissão:

  • Perda de quadro de dados (inclui quadro de dados recebido com erros e assim descartado).
  • Perda de quadro ACK
  • Quadro ACK atrasado, fazendo com que ocorra um timeout de espera por confirmação e consequente retransmissão

Ver ARQ Go-Back-N e Selective-Repeat.

Experimento sobre desempenho do protocolo de enlace em um meio sujeito a erros

Vale a pena observar qual a diferença entre fazer ou não controle de erros com ARQ em um protocolo de enlace. A experiência a seguir busca dar uma ideia de seus prós e contras.

  1. Obtenha os arquivos de programa do protocolo de enlace ponto-a-ponto
  2. Descompacte-o em algum diretório, e em seguida entre no subdiretório erros.
  3. Execute labstart para iniciar o experimento.
  4. Em ambas as máquinas virtuais faça o seguinte: 
    cd /hostlab/shared
./proto /dev/ttyS0 &
ifconfig tun0 10.0.0.1 dstaddr 10.0.0.2
    ... apenas invertendo os endereços IP em uma das máquinas virtuais.
  5. Na máquina virtual pc1 execute: 
    /etc/init.d/apache2 start
dd if=/dev/urandom bs=4096 of=/var/www/teste.bin count=512
  6. Na máquina virtual pc2 execute o seguinte: 
    wget http://10.0.0.1/teste.bin
  7. Observe a taxa de bits obtida durante o donwload ...
  8. Repita o procedimento, porém usando o programa proto-sw.

23/08: Protocolos PPP e HDLC

PPP e HDLC

Detalhes sobre esses protocolos. Ver as transparências:

Resolver a 2a lista de exercícios.

Enlaces ponto-a-ponto entre roteadores

Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (throughput) com cada um dos protocolos.

Rede-modems.png

Esse experimento pode ser reproduzido usando o Netkit. Os comandos dos roteadores Cisco são muito parecidos no software Quagga, que é usado em máquinas virtuais do Netkit que agem como roteadores. No entanto, as interfaces seriais de enlaces ponto-a-ponto no Quagga são identificadas pelos nomes ppp0, ppp1 e assim por diante (ao contrário de Serial 0 e Serial 1 usados no Cisco). Abaixo segue a configuração do Netkit que reproduz o experimento de hoje: 

# Os três roteadores
r1[type]=router
r2[type]=router
r3[type]=router

# O computador que fica na subrede da esquerda
pc1[type]=generic

# O computador que fica na subrede da direita
pc2[type]=generic

# Um computador que representa a Internet
internet[type]=generic

# Os enlaces ponto-a-ponto entre os roteadores
r1[ppp0]=linkEsquerdo:ip=10.0.0.1/30
r1[ppp1]=linkDireito:ip=10.0.0.5/30
r2[ppp0]=linkEsquerdo:ip=10.0.0.2/30
r3[ppp0]=linkDireito:ip=10.0.0.6/30

# a subrede do laboratório, que representa a Internet
r1[eth0]=lanExterna:ip=192.168.1.230/24
internet[eth0]=lanExterna:ip=192.168.1.1/24

# A subrede do lado esquerdo
r2[eth0]=lanEsquerda:ip=172.18.0.30/28
pc1[eth0]=lanEsquerda:ip=172.18.0.17/28

# A subrede do lado direito
r3[eth0]=lanDireita:ip=172.18.10.110/28
pc2[eth0]=lanDireita:ip=172.18.10.97/28

Note que as rotas não foram definidas ... você precisará criá-las.


26/08: Enlaces ponto-a-ponto entre roteadores

(se não conseguirmos concluir a experiência da aula anterior ...)


Nesta aula serão configurados enlaces entre dois roteadores Cisco usando os protocolos PPP e HDLC. O objetivo é ter um contato com esse tipo de equipamento, e ver os protocolos em ação. Além disto, será feita uma medição de vazão (throughput) com cada um dos protocolos.


30/08: Aula de revisão

Correção das listas 1 e 2.

Dúvidas nas listas de exercícios

A questão 3 da lista 2 despertou uma dúvida sobre como a utilização e a taxa efetiva variam em função tanto do tamanho da janela quanto da taxa nominal, para um mecanismo ARQ Go-Back-N. Foram plotados dois gráficos para ilustrar a dependência entre elas, mostrados abaixo. Eles foram gerados usando estes valores: quadros de 1500 bytes, atraso de propagação de 5 ms, quadros ACK de 8 bytes.

TaxaEfetiva.png

Taxa efetiva em função do tamanho da janela (N) e da taxa nominal



Utilizacao.png

Utilização em função do tamanho da janela (N) e da taxa nominal

02/09: Introdução à camada física

Ver capítulos 3, 4 e 5 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).

Ver transparências.


A camada física: camada mais baixa da arquitetura de redes

Osi-tcpip.png


Serviços da camada física:

Servicos-Camada-Fisica.png
(Adaptado do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Berhouz Forouzan)

Transmissão digital

06/09: 1a avaliação

Foi realizada esta avaliação.

09/09: Modems

Modelo-comunicacao.png


Existem diversas tecnologias para criar enlaces ponto-a-ponto de longa distância. Inicialmente estudaremos enlaces criados com modems síncronos, por ser muito comum ainda de ser implantado. Esse tipo de enlace faz uso de pares metálicos tipicamente usados em redes telefônicas, e por isso foram a primeira solução usada em larga escala. Deve-se ter em mente que quando surgiu a necessidade de enlaces de dados de longa distância, a única opção que havia (e a mais barata, justamente por já existir) era a rede telefônica. Assim, toda uma geração de equipamentos de comunicação de dados foi criada para usar o tipo de circuito provido em redes telefônicas, e o tipo de fiação nela utilizada.

Questão para pesquisa: atualmente como são implantados os circuitos de dados de longa distância, e como eles se relacionam com a rede telefônica ?

Rede-ier-wan.png

Atividade

  1. Realizar a experiência com modems síncronos, em que se configuram modems SHDSL (Manual modem DT2048 SHDSL).
  2. Pesquisar qual a codificação usada no modem SHDSL (publicar aqui mesmo na wiki):
    • Taxas de bit suportadas
    • Frequência de portadora
    • Tipo de codificação usada (inclua um diagrama para exemplificar)
    • Níveis de tensão usados no sinal

12/09: Modems digitais

...continuando a aula anterior.

16/09: Enlaces de teste em modems

Atividade em aula

Vamos criar uma tabela com informações sobre os códigos de linha/modulações usados em diversas tecnologias. Devemos descobrir a técnica de modulação ou codificação, as taxas de bit suportadas, frequências de portadoras, níveis de sinal (amplitude), alcance de transmissão e tipo de meio de transmissão suportados. Além disso, deve-se identificar a aplicação de cada uma dessas tecnologias.

  • Interface digital V.35
  • Interface digital RS-232
  • PHY Ethernet 10 Mbps, 100 Mbps, 1 Gbps e 10 Gbps
  • Modems SHDSL
  • Modems aDSL
  • Modems VDSL
  • PLC (Power Line Communication)
  • CATV (links de dados via TV a cabo)
  • Modems V.92 (acesso discado)
  • CAN (um tipo de rede industrial)
  • HPNA (tecnologia para redes domésticas): ver artigo indicado pelo Davi.

Obs: veja os modems de alguns fabricantes:


Tecnologia Modulação/Codificação Taxa de bits Alcance (m) Meio físico Aplicação
CATV (Docsis 3.0) QAM-64 down / QPSK up até 304 Mbps down / 122 up ??? HFC (Coaxial + Fibra) Acesso
SHDSL TC-PAM 64 kbps a 2.3 Mbps 6,5 km a 3,8 km fios telefonia Acesso
HDSL 2B1Q 2048 kbps fios telefonia Acesso
ADSL2+ DMT + QAM até 20 Mbps fios telefonia Acesso
PLC/BPL OFDM fios elétricos Acesso,rede local
HPNA FD-QAM fios telefonia/coaxial Rede residencial
V.92 QAM/TCM 56 kbps up/28.8 kbps down fios telefonia Acesso


20/09: Modems analógicos e Interfaces digitais

Ver capítulo 5 e 6 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).

Ver transparências sobre modems analógicos.

Ver transparências sobre interfaces digitais.

Um catálogo de interfaces digitais feito pela turma do curso Técnico em 2011-1.


Durante a aula serão feitas experiências sobre interfaces digitais V.35 e RS-232c.

Rede-ID.png

Códigos de linha

Resolver a 4a lista de exercícios.

Ver capítulos 3 e 4 do livro "Comunicação de dados e Redes de Computadores", de Berhouz Forouzan (cópia no xerox).

Ver transparências sobre códigos de linha.

Bom texto sobre modulação digital


23/09: Redes locais

Introdução a redes locais

  • Transparências:
  • Capítulo 13 do livro "Comunicação de Dados e Redes de Computadores", de Berhouz Forouzan (tem no xerox)
  • Capítulo 15 do livro "Redes e sistemas de comunicação de dados", de William Stallings.
  • Capítulo 4 do livro "Redes de Computadores", de Andrew Tanenbaum (tem na biblioteca)

Distinção entre WAN, MAN e LAN

  • Aplicações de cada um desses tipos de rede
  • Tecnologias envolvidas
  • "Backbones" da Internet Brasileira:


Algumas redes WAN:


Uma rede MAN MetroEthernet em Florianópolis.

Man-metro.png

LANs


Pontos chaves (obtido de STALLINGS, 2005):

  • Uma LAN consiste de um meio de transmissão compartilhado e um conjunto de hardware e software para servir de interface entre dispositivos e o meio de transmissão, além de regular o acesso ao meio de forma ordenada.
  • As topologias usadas em LANs são anel (ring), barramento (bus), árvore (tree) e estrela (star). Uma LAN em anel consiste de um laço fechado formado por repetidores que possibilitam que dados circulem ao redor do anel. Um repetidor pode funcionar também como um ponto de acesso de um dispositivo. Transmissão geralmente se dá na forma de quadros (frames). As topologias barramento e árvore são segmentos de cabos passivos a que os dispositivos são acoplados. A transmissão de um quadro por um dispositivo (chamado de estação) pode ser escutada por qualquer outra estação. Uma LAN em estrela inclui um nó central onde as estações são acopladas.
  • Um conjunto de padrões definido para LANs especifica uma faixa de taxas de dados e abrange uma variedade de topologias e meios de transmissão.
  • Na maioria dos casos, uma organização possui múltiplas LANs que precisam ser interconectadas. A abordagem mais simples para esse problema se vale de equipamentos chamados de pontes (bridges). Os conhecidos switches Ethernet são exemplos de pontes.
  • Switches formam os blocos de montagem básicos da maioria das LANs (não muito tempo atrás hubs também eram usados).


Lan1-2011-1.png
Uma pequena LAN com um link para Internet



Lan2-2011-1.png
Uma LAN um pouco maior, e também com um link para Internet


Lan-media.png
Uma LAN de médio porte

27/09: Redes locais: arquitetura IEEE 802

  • Arquitetura IEEE 802 e Redes locais IEEE 802.3 (Ethernet)
    • Ver transparências.
    • Capítulo 4 do livro "Redes de Computadores", de Andrew Tanenbaum.
    • Capítulo 14 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan.

Ethernet.png

Desenho usado por Bob Metcalfe, um dos criadores da Ethernet, para apresentação em uma conferência em 1976.

  • Elementos de uma rede Ethernet atual:
    • Estações: equipamentos que se comunicam pela rede. Ex: computadores e roteadores.
    • Interface de rede (NIC): dispositivo embutido em cada estação com a finalidade de prover o acesso à rede. Implementa as camadas PHY e MAC.
    • Meio de transmissão: representado pelos cabos por onde os quadros ethernet são transmitidos. Esses cabos são conectados às interfaces de rede das estações.
    • Switch: equipamento de interconexão usado para interligar as estações. Cada estação é conectada a um switch por meio de um cabo. Um switch usualmente possui múltiplas interfaces de rede (12, 24 ou mais). Uma rede com switches apresenta uma topologia física em estrela.


Lan2-2011-1.png
Uma LAN com switches

... mas no início redes Ethernet não eram assim ! Leia o material de referência para ver como eram essas redes num passado relativamente próximo.

Arquitetura IEEE 802

Define um conjunto de normas e tecnologias no escopo das camadas física (PHY) e de enlace. A camada de enlace é dividida em duas subcamadas:

  • LLC (Logical Link Control): o equivalente a um protocolo de enlace de fato, porém na prática de uso restrito (pouco utilizada).
  • MAC (Medium Access Control): um protocolo de acesso ao meio de transmissão, que depende do tipo de meio físico e tecnologia de comunicação. Esse tipo de protocolo é necessário quando o meio de transmissão é compartilhado.


Arq-ieee.png

Protocolo de acesso ao meio (MAC)

Parte da camada de enlace na arquitetura IEEE 802, tem papel fundamental na comunicação entre estações. O MAC é responsável por:

  • Definir um formato de quadro onde deve ser encapsulada uma PDU de um protocolo de camada superior.


Quadro-ethernet.png
Quadro ethernet


  • Endereçar as estações, já que o meio de transmissão é multiponto (ver campos Dest Add e Source Add no quadro Ethenet).
  • Acessar o meio para efetuar a transmissão de quadros, resolvendo conflitos de acesso quando necessário. Um conflito de acesso (chamado de colisão) pode ocorrer em alguns casos quando mais de uma estação tenta transmitir ao mesmo tempo.


Csma-cd.png
O MAC CSMA/CD (Carrier Sense Multiple Access/Collision Detection


Ver também

Leia este texto:

Utilização do meio de transmissão em uma rede local com MAC do tipo CSMA/CD

Nesta seção mostra-se como estimar o desempenho do CSMA/CD por meio de experimentos para medir a utilização máxima do meio. Esses experimentos podem ser feitos usando uma rede real, com computadores interligados por hubs, ou com um simulador. Em ambos os casos deve-se fazer com que vários computadores gerem tráfego intenso na rede, e calcular ao final a utilização do meio da seguinte forma:

O total de quadros recebidos pode ser obtido em qualquer um dos computadores.

Para fazer com uma rede real:

Resultados (obtidos em 2010-2): 

1: 140254390 214015690
2: 214015690 276800590
3: 276800590 336225070
4: 336225070 398761510
5: 398761510 460950490
6: 479962630 544977970
7: 544977970 610117870
8: 690263890 755876470

Com esses dados deve-se plotar um gráfico da quantidade de bytes recebidos X quantidade de estações transmissoras. Na tabela acima, as estações transmissoras estão na 1a coluna, e a quantidade de bytes recebidos deve ser calculada pela subtração da 3a coluna pela 2a coluna.

Para fazer a experiência pode ser feita também com o simulador Omnet++:

      • Instale o Omnet++ 4
      • Instale o modelo INET: 
        # Faz o download do INET Framework (aprox. 23 MB)
wget http://tele.sj.isfc.edu.br/~msobral/RCO2/soft/inet-20100323-src.tgz

# Descompacte o arquivo
tar xzf inet-20100323-src.tar.gz

# Compila o INET
cd inet
make makefiles
make
      • Copie esses arquivos para dentro de inet/examples/ethernet/lans:
        mu.ini
        mu2.ini
        Networks.ned
      • Para executar uma simulação interativa, com animação, faça assim: 
        cd inet/examples/ethernet/lans
./run mu.ini
        ... e escolha um dos modelos para executar.
      • Para executar uma simulação não-interativa, com uma bateria de experimentos que variam a quantidade de estações (2 a 16) e tamanhos de quadros (256, 512 e 1480 bytes), faça assim: 
        cd inet/examples/ethernet/lans
./run -u Cmdenv -c Hub1 mu2.ini
      • Os resultados das simulações estarão em arquivos dentro do subdiretório inet/examples/ethernet/lans/results. Por exemplo, o arquivo Hub1-0.sca contém o resultado da primeira simulação, e parte de seu conteúdo é mostrada abaixo (cada linha contém algum resultado ou estatística da simulação, e o título é auto-explicativo): 
        version 2
run Hub1-1-20100423-09:38:33-7627
attr bytes 256
attr configname Hub1
attr datetime 20100423-09:38:33
attr experiment Hub1
attr inifile mu2.ini
attr iterationvars "$bytes=256, $stations=3"
attr iterationvars2 "$bytes=256, $stations=3, $repetition=0"
attr measurement "$bytes=256, $stations=3"
attr network HubLAN2
attr processid 7627
attr repetition 0
attr replication #0
attr resultdir results
attr runnumber 1
attr seedset 1
attr stations 3

scalar .        bytes   256
scalar .        stations        3
scalar HubLAN2.sta[0].cli       "packets sent"  0
scalar HubLAN2.sta[0].cli       "packets rcvd"  0
scalar HubLAN2.sta[0].cli       "end-to-end delay mean"         0
scalar HubLAN2.sta[0].cli       "end-to-end delay stddev"       nan
scalar HubLAN2.sta[0].cli       "end-to-end delay min"  0
scalar HubLAN2.sta[0].cli       "end-to-end delay max"  0
scalar HubLAN2.sta[0].srv       "packets sent"  0
scalar HubLAN2.sta[0].srv       "packets rcvd"  247453
scalar HubLAN2.sta[0].srv       "end-to-end delay mean"         1.6121223100944
scalar HubLAN2.sta[0].srv       "end-to-end delay stddev"       1.0596723502417
scalar HubLAN2.sta[0].srv       "end-to-end delay min"  0.0002378
scalar HubLAN2.sta[0].srv       "end-to-end delay max"  5.18103003756
scalar HubLAN2.sta[0].llc       "dsaps registered"      1
scalar HubLAN2.sta[0].llc       "packets from higher layer"     0
scalar HubLAN2.sta[0].llc       "frames from MAC"       247453
scalar HubLAN2.sta[0].llc       "packets passed up"     247453
scalar HubLAN2.sta[0].llc       "packets dropped - unknown DSAP"        0
scalar HubLAN2.sta[0].mac       "simulated time"        60.0001141233
scalar HubLAN2.sta[0].mac       "txrate (Mb)"   10
scalar HubLAN2.sta[0].mac       "full duplex"   0
scalar HubLAN2.sta[0].mac       "frames sent"   0
scalar HubLAN2.sta[0].mac       "frames rcvd"   247453
scalar HubLAN2.sta[0].mac       "bytes sent"    0
scalar HubLAN2.sta[0].mac       "bytes rcvd"    68544481
scalar HubLAN2.sta[0].mac       "frames from higher layer"      0
scalar HubLAN2.sta[0].mac       "frames from higher layer dropped (iface down)"         0
scalar HubLAN2.sta[0].mac       "frames dropped (bit error)"    0
scalar HubLAN2.sta[0].mac       "frames dropped (not for us)"   0
scalar HubLAN2.sta[0].mac       "frames passed up to HL"        247453
scalar HubLAN2.sta[0].mac       "PAUSE frames sent"     0
scalar HubLAN2.sta[0].mac       "PAUSE frames rcvd"     0
scalar HubLAN2.sta[0].mac       "frames/sec sent"       0
scalar HubLAN2.sta[0].mac       "frames/sec rcvd"       4124.2088221947
scalar HubLAN2.sta[0].mac       "bits/sec sent"         0
scalar HubLAN2.sta[0].mac       "bits/sec rcvd"         9139246.7499834
scalar HubLAN2.sta[0].mac       "rx channel idle (%)"   5.937858457565
scalar HubLAN2.sta[0].mac       "rx channel utilization (%)"    94.031961146038
scalar HubLAN2.sta[0].mac       "rx channel collision (%)"      0.030180396396893
scalar HubLAN2.sta[0].mac       collisions      4825
scalar HubLAN2.sta[0].mac       backoffs        0

O gráfico abaixo foi obtido com esse experimento de simulação:

Csma-perf-sim.png

As simulações tiveram os seguintes parâmetros:

  • Quadros de 256, 512 e 1480 bytes
  • 2 a 45 estações
  • Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)
  • Uma análise feita no capítulo 4 do livro "Redes de Computadores, 4a ed." de Andrew Tanenbaum fornece a seguinte previsão de desempenho para o CSMA/CD em uma rede Ethernet a 10 Mbps.
  • Utilização do meio:

  • B: taxa de bits nominal
  • L: comprimento do meio de transmissão
  • c: velocidade de propagação do sinal
  • F: comprimento do quadro

Csma-perf.png

Essa figura mostra curvas para a utilização do meio em função da quantidade de estações prontas para transmitir, e para diferentes tamanhos de quadro. A conclusão é que quadros menores proporcionam desempenho inferior, assim como uma quantidade maior de estações resulta em uma provável menor utilização do meio. No entanto essa análise considera a rede numa situação de carga muito alta, o que não acontece normalmente. Há também algumas simplificações no desenvolvimento da análise, tal como considerar que a probabilidade de retransmissão constante em cada slot, ao invés de analisar o algoritmo de recuo exponencial binário (backoff). Finalmente, esse resultado tem sentido para um meio de transmissão compartilhado, mas a atualmente as redes locais ethernet trabalham com meios de transmissão exclusivos (ethernet comutada e full-duplex, em que não há risco de colisão).

Para fins de comparação, um experimento de simulação foi realizado (conforme descrito na aula anterior), e foram obtidos os resultados mostrados na figura abaixo.

Csma-perf-sim.png

Para esse experimento foram realizadas simulações com os seguintes parâmetros:

  • Quadros de 256, 512 e 1480 bytes
  • 2 a 45 estações
  • Geração de tráfego por estação com intervalos entre quadros dados por uma distribuição exponencial com média 15*tamanho_quadro_em_bits*0.11us (0.11us é o tempo aproximado de um bit)

04/10: 2a avaliação

Envolve o conteúdo sobre Camada Física, e se baseará nas listas de exercícios 3 e 4.

07/10: Redes locais: arquitetura IEEE 802 e interligação de LANs

  • Ver transparências.
  • Capítulo 16 do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Behrouz Forouzan.
  • Capítulo 4 do livro "Redes de Computadores, 4a ed.", de Andrew Tanenbaum.

Interligação de LANs (norma IEEE802.1D):

Tecnologias de LAN switches

Leia este bom texto sobre estruturas internas de switches.


Outros materiais:

TRABALHO sobre switches

Para ser lançado em mercado, um switch deve apresentar conformidade com as especificações para bridges do padrão IEEE 802.1D. Além disso, deve também ter descritos seus parâmetros de desempenho.

O trabalho consiste em efetuar uma avaliação de um switch de baixo custo. Deve-se determinar:

  1. Se o switch opera conforme uma ponte transparente (transparent bridge), de acordo com o padrão IEEE 802.1D.
  2. Se o switch é robusto (não tranca).
  3. Informações de desempenho do switch: latência, vazão (throughput), backplane, tamanho da tabela de endereços MAC (total e por porta), taxas de bits e modos duplex, suporte a auto-negociação, limites mínimos e máximos de tamanhos de quadros.

Cada equipe receberá um switch, com que deve criar experimentos para responder os ítens da avaliação. Os resultados devem ser reportados em um relatório composto pelas seções:

  1. Título
  2. Identificação dos membros da equipe
  3. Objetivo do trabalho
  4. Introdução: uma visão geral sobre a avaliação do switch, em que se explicam sucintamente os pontos a serem avaliados. Na introdução deve-se também apresentar resumidamente os procedimentos realizados, e uma indicação dos resultados obtidos.
  5. Desenvolvimento: descrição dos experimentos e seus resultados. Cada experimento deve ser explicado com detalhes, de forma que outra pessoa pudesse repeti-los. Os resultados devem ser apresentados de forma clara, explorando o uso de gráficos e tabelas quando adequado.
  6. Conclusão: uma discussão sobre os resultados obtidos, acompanhada de um julgamento sobre a avaliação do switch.
  7. Bibliografia: uma listagem das referências bibliográficas utilizadas (e que devem ser citadas no texto).


As equipes podem ser compostas por até 3 alunos.

Prazo de entrega: 18/10

OBS: use este programa para enviar quadros ethernet com endereços de origem forjados. Ele enviará quadros indefinidamente, sendo que cada quadro terá um endereço de origem diferente. O intervalo entre envios é de 100 microssegundos (pode ser modificado editando o programa). Os quadros possuem o campo ethertype com valor 0x8888. Para compilá-lo faça assim: 

gcc -o envio l2-envio.c

... e para rodá-lo: 

sudo ./envio eth0 aa:bb:cc:dd:ee:ff

aa:bb:cc:dd:ee:ff é o endereço MAC da estação destino. Se ele for omitido, os quadros serão enviados para broadcast.

11/10 e 14/10: Redes locais: interligação de LANs e VLANs IEEE 802.1q

IMPORTANTE: Ver 5a lista de exercícios.

  • Obs: tente resolver as questões finais usando o Netkit.
  • Ver transparências.
  • Capítulo 16 do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Behrouz Forouzan.
  • Capítulo 4 do livro "Redes de Computadores, 4a ed.", de Andrew Tanenbaum.
  • Capítulo 5 do livro "Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição, de James Kurose.

Quadro-8021q.png
Quadro ethernet com a TAG IEEE 802.1q

VLANs no Netkit

Configuração do Netkit (arquivo Lab.conf): 

switch[type]=switch
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
pc4[type]=generic

switch[eth0]=port0:vlan_untagged=5
switch[eth1]=port1:vlan_untagged=10
switch[eth2]=port2:vlan_untagged=5
switch[eth3]=port3:vlan_untagged=10

pc1[eth0]=port0:ip=192.168.5.1/24
pc2[eth0]=port1:ip=192.168.10.2/24
pc3[eth0]=port2:ip=192.168.5.3/24
pc4[eth0]=port3:ip=192.168.10.4/24

18/10: Redes locais: interligação de LANs e protocolo Spanning Tree (STP)

Fazer a 6a lista de exercícios.

  • Capítulo 16 do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Behrouz Forouzan.
  • Capítulo 4 do livro "Redes de Computadores, 4a ed.", de Andrew Tanenbaum.
  • Capítulo 5 do livro "Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição, de James Kurose.

Em LANs grandes pode ser necessário ter enlaces redundantes, para evitar que a interrupção de um enlace isole parte da rede. A existência de interligações alternativas portanto tem a finalidade de conferir algum grau de tolerância a falhas na infraestrutura da rede. Assim, uma LAN com uma ligação em anel como mostrado abaixo apresentaria dois enlaces para ligar cada switch ao resto da rede.

LAN-anel-stp.png 

sw1[type]=switch
sw2[type]=switch
sw3[type]=switch
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic

# Ativação do STP nos switches
sw1[stp]=on
sw2[stp]=on
sw3[stp]=on

sw1[eth0]=sw1-sw2
sw1[eth1]=sw1-port1
sw1[eth2]=sw1-sw3

sw2[eth0]=sw1-sw2
sw2[eth1]=sw2-port1
sw2[eth2]=sw2-sw3

sw3[eth0]=sw1-sw3
sw3[eth1]=sw3-port1
sw3[eth2]=sw2-sw3

pc1[eth0]=sw1-port1:ip=192.168.0.1/24
pc2[eth0]=sw2-port1:ip=192.168.0.2/24
pc3[eth0]=sw3-port1:ip=192.168.0.3/24

Apesar de desejável em algumas situações, uma topologia de rede com caminhos fechados, como visto na figura acima, não pode ser instalada sem alguns cuidados. Uma rede como essa trancaria devido a um efeito chamado de tempestade de broadcasts (broadcast storm). Isso acontece porque ao receber um quadro em broadcast, um switch sempre o retransmite por todas as demais portas. Para que a rede acima funcione como esperado, uma ou mais portas de switches precisarão ser desativadas de forma que o caminho fechado seja removido. Ter que fazer isso manulamente tira o sentido de ter tal configuração para tolerância a falhas, por isso foi criado o protocolo STP (Spanning Tree Protocol, definido na norma IEEE 802.1d) para realizar automaticamente essa tarefa.

Switches_e_STP_(Spanning_Tree_Protocol) no Netkit

... ver também:

  • timers do STP (hello e max-age), que influenciam o tempo de convergência do protocolo

21/10: Redes locais: controle de acesso com IEEE 802.1x e VLANs dinâmicas


Norma IEEE 802.1x


A norma IEEE 802.1x define um framework para controle de acesso a redes locais IEEE 802, sendo usado tanto em redes cabeadas quanto sem-fio. O propósito dessa norma é criar mecanismos para identificar e autorizar ou não o acesso de um usuário à infraestrutura da rede. Esses mecanismos são implementados em três componentes que forma a estrutura de controle de acesso IEEE 802.1x, mostrada na figura abaixo:

Ieee-8021x.png

  • Supplicant: o cliente que deseja se autenticar. Implementado com um software (ex: wpa_supplicant, xsupplicant).
  • Autenticador: o equipamento que dá acesso à rede para o cliente, e onde é feito o bloqueio ou liberação do uso da rede. Implementado em switches e Access Points (no caso de redes sem-fio).
  • Servidor de Autenticação: o equipamento que verifica as credenciais fornecidas pelo supplicant, e informa ao autenticador se ele pode ou não acessar a rede. Implementado comumente em um servidor Radius.

A autenticação se faz com protocolos específicos definidos na norma IEEE 802.1x:

  • EAP (Extensible Authentication Protocol): protocolo para intercâmbio de informações de autenticação entre supplicant e servidor de autenticação.
  • EAPOL (EAP over LAN): protocolo para transportar as PDUs EAP entre supplicant e autenticador.

Ieee-802x-eap.png

Existem vários métodos EAP, que correspondem a diferentes mecanismos de autenticação. Assim, o método de autenticação pode ser escolhido de acordo com as necessidades de uma rede.

  • EAP-MD5: baseado em login e senha, usa um desafio MD5 para autenticar o usuário.
  • EAP-TLS: baseado em certificados digitais X.509, usados para autenticar a rede para o supplicant, e o supplicant para a rede.
  • EAP-TTLS: também baseado em certificados digitais, mas somente para autenticar a rede pro supplicant. O supplicant se autentica com algum outro método EAP mais simples, como EAP-MD5.
  • ... e muitos outros !

TRABALHO SOBRE LANS

Prazo de entrega: 07/11
Grupos de até 2 pessoas

25/10: Revisão

Revisão, com correção das listas de exercícios.

01/11: 3a avaliação

Na sala de aula ...

04/11: WAN: Frame-Relay e MPLS


Ver também:

  • Capítulo 18 do livro Comunicação de Dados e Redes de Computadores, 3a ed., de Behrouz Forouzan.
  • Capítulos 12 a 15 do livro Comunicação entre Computadores e Tecnologias de Rede, de Michael Gallo e William Hancock.

MPLS: Multi Protocol Label Switching

MPLS é um mecanismo para redes de telecomunicações de alto desempenho que encaminha e transporta dados de um nó da rede a outro. Isso se faz por meio de links virtuais entre nós distantes um do outro, semelhante ao conceito de circuitos virtuais. Diversos protocolos podem ser transportados por MPLS, tais como IP e Ethernet (note que o primeiro é um protocolo de rede, mas o segundo é um "protocolo" de enlace). Assim, MPLS se apresenta como uma tecnologia de transporte de dados em redes de longa distância, como ilustrado na figura abaixo.

Mpls-network.jpg

Simplificadamente, um cabeçalho (shim header) é adicionado a cada PDU a ser transportada pela rede MPLS. O rótulo contém um número identificador chamado de rótulo (label, e similar ao VCI visto em circuitos virtuais), junto com alguns bits de controle. Os roteadores dentro da rede MPLS encaminham essas PDUs com base somente no conteúdo desse cabeçalho, comutando-os de acordo com os valores de rótulo (label switching). Note que MPLS não faz roteamento, e sim comutação de circuitos virtuais: os circuitos devem ser previamente estabelecidos para que o encaminhamento de PDUs entre origem e destino possa ser realizada. Desta forma, MPLS parece ser um protocolo que fica entre as camadas de rede e de enlace, como mostrado na figura a seguir.

Mpls protocolstack.jpg ----> MPLS D2.gif


O cabeçalho MPLS possui apenas 32 bits, como mostrado abaixo. O valor de rótulo ocupa 20 bits, o que possibilita pouco mais de 1 milhão de diferentes rótulos (). Há um campo Time To Live (ou simplesmente TTL) com 8 bits, com mesma finalidade que o campo homônimo existente em PDUS IPv4: evitar que um erro de configuração em um roteador faça com que PDUs fiquem circulando eternamente em um loop na rede. O valor desse campo TTL é decrementado por cada roteador que encaminhe a PDU e, se o valor chegar a 0, a PDU é descartada. O campo Exp com 3 bits foi pensado para codificar a classe de serviço da PDU, a qual pode ser usada por mecanismos de qualidade de serviço (QoS) existentes na rede. Por exemplo, o valor de Exp pode ser usado como prioridade da PDU em um determinado roteador dentro da rede MPLS. Por fim, o bit S (bottom of stack) informa se esse é o último cabeçalho MPLS na PDU, uma vez que podem-se empilhar dois ou mais desses cabeçalhos.


Mpls-label.png


A terminologia MPLS possui nomes próprios para diversos componentes da arquitetura. Como ocorre em outras tecnologias, existem conceitos conhecidos apresentados porém com nomes diferentes. A tabela abaixo descreve alguns termos importantes existentes no MPLS:


Termo Descrição
LSP Label Switching Path, o análogo a circuito virtual.
LSR Label Switching Router, ou roteador capaz de comutar PDUs MPLS.
LER Label Edge Router, ou roteador que faz a interface entre a rede MPLS (onde se encaminham PDUs exclusivamente com base nos rótulos), e a rede externa (onde não se usa MPLS). A rede externa pode ser qualquer outra rede, como IPv4, IPv6 ou mesmo LAN Ethernet. Note que LER é um tipo especial de LSR, e podem ser denominados também como LSR ingress (LSR de entrada na rede MPLS) e LSR egress (LSR de saída da rede MPLS).
LFIB Label Forwarding Information Base, ou o conjunto de informações existentes nos LSR usadas para fazer o encaminhamento das PDUS MPLS. Pode ser entendida como uma estrutura análoga à tabela de comutação de circuitos virtuais.


Usando os termos acima, podem-se descrever redes MPLS demonstrativas como mostrado a seguir. Na primeira rede há dois LSP: um vai do Host X ao Host Z e está identificado com PDUS em amarelo, e outro vai de Host X ao Host Y e tem PDUs em azul. O número dentro de cada PDU informa os valores de rótulo usados ao longo dos LSP. Assim como em circuitos virtuais em geral (e como em Frame Relay e ATM), os valores de rótulo podem ser modificados por cada roteador que os comute.

Mplsrouters.gif

Conceitos básicos sobre comutação de rótulos

A comutação de rótulos feita nos LSR é muito parecida com comutação de circuitos virtuais. Ao receber uma PDU MPLS, um LSR decide o que fazer com ela com base no número do rótulo e na interface de rede de onde ela foi recebida. Porém há um detalhe específico do MPLS: uma ou mais interfaces podem ser associadas em um labelspace MPLS, sendo esse labelspace usado para identificar de onde foi recebida uma PDU. Desta forma, um LSR na verdade decide o que fazer com uma PDU com base em seu rótulo e no seu labelspace. Dentro do LSR essa operação se chama ILM (Input Label Mapping). 

ILM é a função que identifica uma PDU recebida e mapeia seu rótulo para um labelspace

Um caso especial trata de PDUs que entram na rede MPLS. Por exemplo, uma PDU IPv4, originada de uma rede externa, deve ser transportada pela rede MPLS. Nesse caso, o LER (roteador de borda) deve associar essa PDU a um rótulo MPLS e encaminhá-lo pela rede MPLS. A identificação de uma PDU externa à rede MPLS, com base nas informações dessa PDU, se chama FEC (Forwarding Equivalence Class).

Uma vez identificada uma PDU recebida, o LSR deve encaminhá-la de acordo com instruções predefinidas em sua LFIB. Dentro de sua LFIB essas instruções são chamadas de NHLFE (Next-Hop Label Forwarding Entry), e contêm a operação MPLS a ser realizada e a interface de saída por onde encaminhar a PDU. As operações MPLS possíveis estão descritas na tabela abaixo:


Operação Descrição
SWAP Troca o valor de rótulo. Essa operação deve ser usada para comutação dentro da rede MPLS. Mesmo quando o novo valor de rótulo for idêntico ao anterior essa operação deve ser realizada.
PUSH Adiciona um cabeçalho MPLS com um determinado valor de rótulo. Essa operação deve ser usada principalmente nos LER, quando uma PDU entra na rede MPLS.
POP Remove o cabeçalho MPLS. Essa operação deve ser usada principalmente nos LER, quando uma PDU sai da rede MPLS.


A comutação fica completa ao se juntarem o mapeamento de entrada (ILM) com as NHLFE, no caso de comutação dentro da rede MPLS. No caso de entrada de PDUs na rede MPLS, a operação se chama FTN (Fec-To-Nhlfe), que nada mais é que regras para associar os rótulos MPLS a essas PDUS. No exemplo da PDU IPv4, pode-se usar o endereço IPv4 de destino dessa PDU para escolher que rótulo MPLS deve ser usado. Isso está sumarizado na figura abaixo.

Mpls-lfib.png

08/11: WAN: MPLS

O exercício proposto em aula - fazer o LSP entre A2 e A1 passar por E5 ao invés de E3 - implica modificar a configuração dos roteadores E2, E3, E4 e E5:

Exercicio-mpls-1.png

  • E4: mudar a NHLFE para que o LSP A2->A1 vá para E5.
  • E5: fazer a comutação A2->A1 que antes ficava em E3.
  • E2: modificar o labelspace 0 para que contenha a interface eth3.
  • E3: removida a configuração da comutação A2->A1


Exemplos de serviços baseados em MPLS em operadoras:

10/11: WAN: MPLS (labelspaces e túneis)

Questão: para que serviria um túnel MPLS ?

Para casa

11/11: WAN MPLS

Atenção: 4a avaliação


Wan-2011-2.png

CUIDADO: Não use rótulos entre 0 e 15, pois são reservados (ver detalhes).

Label merging

Label merging ("fusão de rótulos") significa a união de dois ou mais LSP a partir de um roteador. Isso pode ser feito quando os LSP em questão seguem o mesmo caminho a partir desse roteador e possuem o mesmo destino (e são tratados da mesma forma do ponto de vista de engenharia de tráfego).

Label-merging.png

No exemplo acima, os LSP A1 -> A3 e A2 -> A3 seguem o mesmo caminho a partir do roteador E3. Assim, a partir desse ponto eles podem ser fundidos. Porém os LSP A3 -> A1 e A3 -> A2 não podem ser fundidos, já que os caminhos que eles seguem terminam em destinos diferentes.

22/11: Redes sem-fio: introdução

  • Ver transparências
  • Ver capítulo 15 do livro Comunicação de Dados e Redes de Computadores, 3a ed., de Behrouz Forouzan.
  • Ver capítulo 6 do livro Redes de Computadores e a Internet, 3a ed., de James Kurose.
  • Ver capítulo 4 (seção 4.4) do livro Redes de Computadores, 4a ed., de Andrew Tanenbaum.
  • Ver este livro on-line sobre redes IEEE 802.11. (precisa do gnochm ou chmsee para ser lido)

Será feito um experimento para configurar, usar e verificar a vazão de uma rede local sem-fio IEEE 802.11. Também será investigado o tráfego nessa rede, usando o analisador de protocolo wireshark.


Alguns usos de redes sem-fio

WLAN-comum.gif
Redes locais sem-fio


Wireless point to point.jpg
Enlaces ponto-a-ponto de média/longa distância



Wlan-train.png
Prover conectividade em ferrovias



Body-network.jpg
Redes de dispositivos acoplados ao corpo de uma pessoa



SensorWebImageForEnewsJuly2.jpg
Redes de sensores



V2v.jpg
Redes entre veículos (experimental)

Padrão IEEE 802.11

  • Ver transparências
  • Ver capítulo 15 do livro Comunicação de Dados e Redes de Computadores, 3a ed., de Behrouz Forouzan.
  • Ver capítulo 6 do livro Redes de Computadores e a Internet, 3a ed., de James Kurose.
  • Ver capítulo 4 (seção 4.4) do livro Redes de Computadores, 4a ed., de Andrew Tanenbaum.
  • Ver este livro on-line sobre redes IEEE 802.11. (precisa do gnochm ou chmsee para ser lido)


Apresentaram-se as características de comunicação e propagação de sinal em uma rede sem-fio multiponto, introduzindo-se os problemas a serem considerados pelo protocolo MAC.

25/11: Redes sem-fio: padrão IEEE 802.11

Continuação sobre o MAC CSMA/CA.

MAC CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance)

O CSMA/CA definido na norma IEEE 802.11 implementa um acesso ao meio visando reduzir a chance de colisões. Numa rede sem-fio como essa, não é possível detectar colisões, portanto uma vez iniciada uma transmissão não pode ser interrompida. A detecção de colisões, e de outros erros que impeçam um quadro de ser recebido pelo destinatário, se faz indiretamente com quadros de reconhecimento (ACK). Cada quadro transmitido deve ser reconhecido pelo destinatário, como mostrado abaixo, para que a transmissão seja considerada com sucesso.

Wlan-ack.png
Envio de um quadro de dados, com subsequente reconhecimento (ACK)


O não recebimento de um ACK desencadeia uma retransmissão, de forma parecida com o procedimento de retransmissão do CSMA/CD ao detectar colisão. Antes de efetuar uma retransmissão, o MAC espera um tempo aleatório denominado backoff (recuo). Esse tempo é sorteado dentre um conjunto de possíveis valores que compõem a Janela de Contenção (Cw - Contention Window), representados no intervalo [0, Cw]. O valor de Cw varia de (15 para IEEE 802.11g e 31 para 802.11b) a (1023), e praticamente dobra a cada retransmissão de um mesmo quadro. A figura abaixo ilustra as janelas de contenção para retransmissões sucessivas.

Wlan-backoff.png
Backoff para retransmissões sucessivas


Uma diferença importante com relação ao CSMA/CD se refere ao caso em que uma estação tem um quadro para transmitir, mas encontra o meio ocupado. No CSMA/CD essa estação iria aguardar até que o meio se tornasse ocioso, e então transmitiria imediatamente o quadro. No CSMA/CA, porém, a estação faz obrigatoriamente um backoff assim que o meio se torna livre (usando como valor de Cw). Além disso, se durante a espera do backoff o meio voltar a ficar ocupado, o decremento do backoff é pausado até que o meio fique ocioso novamente. Esses procedimentos têm por objetivo reduzir a chance de colisão nessa situação. Se uma estação estiver aguardando o meio ficar ocioso, há uma boa chance de outra estação estar fazendo a mesma coisa. Se essas estações transmitissem assim que o meio se tornasse ocioso, fatalmente ocorreria uma colisão. Assim, com o CSMA/CA o acesso ao meio por um conjunto de estações ocorreria como mostrado na figura abaixo.

Csma-ca.png


Juntando tudo, pode-se descrever em alto-nível o algoritmo do CSMA/CA (simplificando alguns detalhes) com o fluxograma abaixo:


Fluxograma-csma-ca.png
Fluxograma para MAC CSMA/CA em modo contenção (função DCF). Esse fluxograma não mostra as esperas de intervalos entre quadros (IFS). Cw significa Janela de Contenção (Contention Window), e Cwmin é seu valor mínimo definido na norma (15 no caso do IEEE 802.11g, e 31 para IEEE 802.11b).


Um último detalhe sobre o CSMA/CA trata dos intervalos entre quadros (IFS - Inter Frame Space), que são tempos mínimos que um nodo deve esperar antes de transmitir um quadro, após o meio se tornar ocioso. Sua finalidade é priorizar o acesso ao meio para certos tipos de quadros, que têm urgência para serem enviados. Esse é o caso de quadros de confirmação (ACK) e CTS (Clear To Send). Um IFS menor corresponde a uma maior prioridade de transmissão de quadro. A figura abaixo ilustra os tipos de IFS:

Ifs-csma-ca.gif
Intervalos entre quadros

  • SIFS (Short Interframe Space): intervalo mais curto, usado antes do envio de quadros ACK e CTS.
  • PIFS (PCF Interframe Space): intervalo intermediário, usado quando em modo PCF (Point Coordination Function). O modo PCF implementa um tipo de acesso ao meio mestre-escravo. Raramente encontrado em equipamentos.
  • DIFS (Distributed Interframe Space): intervalo usual, aplicado no início de transmissões em geral (quadros de dados, associação, autenticação, RTS).


Resultados do experimento

  • Downstream: 7 fluxos unidirecionais simultâneos de 144 MB enviados do computador do professor (rede cabeada) para os dos alunos (rede sem-fio).
  • Upstream: 7 fluxos unidirecionais simultâneos de 144 MB enviados do computador dos alunos para o do professor.
  • Comandos usados (usaram-se dd e nc):
    • No computador que recebe o fluxo (X é o número do computador): nc -d -l 150X
    • No computador que inicia o fluxo: dd if=/dev/zero bs=1440 count=100000 | nc 192.168.1.X 150X


Downstream (kB/s) Upstream (kB/s)
369
389
360
368

Desempenho estimado do MAC CSMA/CA

  • Temporização: tempos envolvidos na operação do MAC
Wlan-timing.png Wlan-parametros.png
Parâmetros usados pelo MAC CSMA/CA

Deve-se usar a análise do desempenho do stop-and-wait para estimar qual a melhor utilização possível com CSMA/CA num cenário ideal. Tal cenário seria descrito assim:

  • apenas uma estação transmite quadros (fluxo unidirecional)
  • não ocorrem erros
  • os quadros de dados têm sempre tamanho máximo = 1534 bytes, com payload de 1500 bytes.
  • os quadros ACK têm 14 bytes
  • assume-se taxa nominal de 54 Mbps, com SIFS = 13 us, DIFS = 31 us, slot = 9 us e
  • há um tempo adicional de 26 us usado para preâmbulo e outros detalhes da camada física (PHY):
    • preâmbulo: 20 us
    • signal extension (trailer PHY): 6 us

29/11: Redes sem-fio IEEE 802.11: formação de BSS. Sistemas de Distribuição

Autenticação e associação

Originalmente foi definido na norma IEEE 802.11 que uma estação precisa se autenticar e associar a um BSS para poder transmitir dados. Em sua forma mais simples, esses procedimentos demandam apenas quatro quadros de controle no total, sendo dois para cada operação. A sequência de autenticação em sua forma mais simples é denominada Autenticação aberta, mostrada abaixo:

80211-auth.png
Autenticação aberta


Como se pode ver, chamar essa operação de autenticação é forçar o uso desse termo porque o AP (que controla o BSS) não confere a identidade informada pela estação. Assim, outra forma de autenticação foi criada para conferir a informação passada pela estação, além de negociar chave de encriptação para ter o sigilo das comunicações. Esse novo método se chama Autenticação com chave compartilhada, sendo implementado pelo WEP (e lembre que isso é inseguro e não deve ser usado em redes reais ;-):

80211-shared-key-auth.png
Autenticação com chave compartilhada

Uma vez estando a estação em estado autenticado, deve ocorrer a associação com o AP. Na associação o AP registra a existência da estação de forma que o sistema de distribuição (DS, que interliga os AP) saiba em que AP se encontra essa estação e possa assim lhe encaminhar quadros. A norma IEEE 802.11 proíbe explicitamente a associação a mais de um AP simultaneamente.

80211-associate.png
Associação com AP

Sistemas de Distribuição

Em uma rede IEEE 802.11, vários BSS podem se combinar para formarem um ESS (Extended Station Set). A interligação entre os AP deve ser feita em nível de enlace, seja por uma rede cabeada ou por links sem-fio. Essa interligação é denominada Sistema de Distribuição, estando exemplificada na figura abaixo:


80211-ds.png


O sistema de distribuição funciona como uma ponte entre as WSTA, como mostrado na figura abaixo. Assim, se dois AP forem interligados, as WSTA que pertencem a seus BSS poderão se comunicar como se estivessem na mesma rede local.


80211-ds2.png

Atividade

Será criada uma rede sem-fio composta por três BSS, que formarão o ESS "redes2". Essa rede sem-fio estará em uma subrede separada da rede do laboratório, havendo um computador com papel de gateway. Duas configurações serão testadas:

  1. Os AP estarão interligados por um DS via rede cabeada

    Lab-ds-1.png

  2. Os AP estarão interligados por um WDS.

    Lab-ds-2.png

Em ambos os casos, serão feitos downloads de arquivos longos para estimar a vazão que pode ser obtida.

02/12: Redes Ad Hoc

  • Ausência de uma estação base (ou Access Point)
  • Cada estação pode se comunicar diretamente com qualquer outra estação em seu alcance
  • Problemas dos nodos escondidos e expostos se manifestam intensamente
  • Demandam roteamento especializado (ex: AODV, OLSR)


Adhoc1.jpg
Podem possibilitar a criação de uma rede local temporária em um ambiente previamente sem infraestrutura (AP)


Adhocnet.gif
Podem formar redes temporárias entre equipamentos móveis


Vanet.gif
Podem ser usadas como base para aplicações inovadoras, como redes veiculares

Problemas sobre nodos escondidos e expostos

  1. De acordo com a rede sem-fio em modo ad hoc mostrada na figura abaixo, assumindo que o MAC seja o CSMA/CA, identifique:
    • Quais estações não conseguem transmitir simultaneamente, devido ao problema dos nodos expostos
    • Para cada estação, identifique todas as estações que podem transmitir simultaneamente (independente da estação destino). Quer dizer, que estações podem transmitir sem risco de colisões devido ao problema dos nodos escondidos.

      Rede-sem-fio1.png
  2. Faça a mesma análise para a rede mostrada abaixo:

    Rede-sem-fio2.png

06/12: Redes sem-fio: Segurança em redes IEEE 802.11


Redes sem-fio oferecem muitos atrativos, como acesso ubíquo, ausência de cabeamento e suporte a usuários móveis. Mas também se sujeitam a uso indevido, uma vez que pessoas não-autorizadas no alcance do sinal do ponto de acesso podem tentar usá-la para se comunicarem. Em geral três questões fundamentais aparecem no que diz respeito à segurança em redes sem-fio:

  1. Acesso indevido: uso indevido da infraestrutura por pessoas não-autorizadas.
  2. Monitoramento do tráfego da rede: os quadros na rede sem-fio podem ser coletados e interpretados, com possível roubo ou revelação de informação sensível.
  3. Infiltração de equipamentos na rede: um ou mais pontos de acesso podem ser infiltrados na rede sem-fio (chamados de Rogue AP), fazendo com que pessoas os utilizem para se comunicarem. Assim, o tráfego dessas pessoas pode passar por outra rede, sendo passível de monitoramento.

Por exemplo, redes em locais densamente ocupados (como edifícios) podem ser investigadas por alguém em busca de uma rede aberta ou fácil de ser invadida. Essa pessoa pode simplesmente querer usar o acesso à Internet disponível em alguma rede sem-fio, ou mesmo invadir os equipamentos existentes em tal rede. A figura abaixo mostra a técnica de WarDriving, em que uma pessoa investiga a existência de redes sem-fio a partir de um carro que trafega pelas ruas.

View from Wardriver Windshield.jpg

Existem inclusive símbolos (warchalking) usados para indicar em ruas e edifícios a existência de redes sem-fio abertas. Esta rápida explicação sobre warchalking foi obtida em um artigo sobre WarChalking: 

 O warchalking foi criado pelo web designer Matt Jones que, enquanto almoçava com dois amigos, viu alguns estudantes
utilizando conexões wireless para trabalhar a partir de uma praça pública, como se fosse um escritório. Um dos amigos de 
Matt lembrou-se de uma “linguagem” de sinais utilizada por mendigos e viajantes com o objetivo de informar onde poderiam 
achar comida grátis, uma cama confortável ou até mesmo encrenca, e surgiu a idéia de demarcar a presença de redes wireless 
com sinais parecidos.


Os símbolos do warchalking são:

Warchalking2.jpg


Assim, uma rede sem-fio minimamente bem configurada deve usar mecanismos de segurança que impeçam ou dificultem seu uso indevido. Em um cenário usual, tal rede sem-fio poderia se apresentar como mostrado abaixo:

Wifi-security1.png


Para tratar essas questões, deve haver mecanismos de segurança que contemplem os seguintes requisitos:

  1. Autenticação de usuários: usuários da rede sem-fio devem se identificar (ou autenticar) na infra-estrutura dessa rede, de forma a se autorizarem ou não seus acessos.
  2. Sigilo das comunicações: o tráfego na rede sem-fio deve ser encriptado, para que não seja inteligível caso sejam capturados por usuários mal-intencionados que estejam monitorando a rede sem-fio.
  3. Autenticação dos pontos de acesso: pontos de acesso devem se identificar para os usuários, para evitar a infiltração de pontos de acesso indevidos na rede.

Há mecanismos de segurança usados em redes IEEE 802.11 que contemplam todos os requisitos acima (WPA-EAP, WPA Enterprise), ou parcialmente (WPA-PSK ou WPA Personal). WPA-EAP aproveita a infraestrutura IEEE 802.1x, junto com técnicas de encriptação entre estações sem-fio, para atender esses requisitos. Já WPA-PSK usa apenas as técnicas de encriptação, não havendo um controle de acesso baseado em usuário. Na figura abaixo se mostra uma pequena rede sem-fio que usa WPA-EAP.

Wifi-auth.jpeg

Além dos mecanismos WPA, definidos na norma IEEE 802.11i, outra forma de implantar controle de acesso em redes sem-fio se vale de um portal de captura. Quando um usuário não identificado acessa a rede, o acesso ao ponto de acesso é concedido mas ao tentar navegar na Web seu acesso é desviado para uma página predefinida. Nessa página o usuário deve se identificar (ex: com login e senha), e em caso de sucesso seu acesso à Internet é liberado. Essa técnica se vale de uma combinação de mecanismos (firewall com filtro IP, serviço Web, uso de programas para autenticação) para controlar o acesso dos usuários. No entanto, não provê sigilo das comunicações nem autenticação de pontos de acesso ao usuário. Sua atratividade reside na simplicidade de implantação e uso (não necessita de supplicant), sendo uma escolha comum em hot spots como aeroportos e cyber cafes. No Projeto Integrador 2009.2 as equipes implantaram uma infra-estrutura que usava essa técnica.

09/12: finalização ...


13/12: Avaliação

16/12: Recuperações

Será feita uma prova para cada unidade pendente. Deve-se obter ao menos C em cada prova.

Trabalhos pendentes

Há duas opções:

  1. Entregá-los até 19/12, às 14 h.
  2. A partir de 14h, fazer uma prova prática para cada trabalho em haver :-b
Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=RCO2-2011-2&oldid=38671”