Tecnologias de Comunicação de Dados
Versão 2.0 –
30/07/2001
1 Modelo de Referência OSI......................................................................................................... 6
1.1 Camada Física....................................................................................................................... 8
1.1.1 Análise de Fourier (1904)......................................................................................................................................... 9
1.1.2 Largura de Banda.................................................................................................................................................... 10
1.1.3 Taxa Máxima de Transmissão de
um Canal:........................................................................................................ 10
1.1.4 Meios de Transmissão........................................................................................................................................... 11
1.1.4.1 Cabo Coaxial........................................................................................................................................................ 11
1.1.4.2 Par Trançado........................................................................................................................................................ 12
1.1.4.3 Fibra Óptica.......................................................................................................................................................... 13
1.1.4.4 Wireless................................................................................................................................................................ 15
1.1.4.5 Satélite.................................................................................................................................................................. 17
1.1.4.6 Sistema Telefônico.............................................................................................................................................. 18
1.1.5 Sub-camada de Acesso ao Meio.......................................................................................................................... 21
1.1.5.1 IEEE 802.3 - CSMA/CD (Carrier Sense Multiple
Access/Collision Detection).......................................... 22
1.1.5.2 IEEE 802.5 - Token Ring..................................................................................................................................... 24
1.1.5.3 IEEE 802.11 - CSMA/CA (Carrier Sense Multiple
Access/Collision Avoidance)..................................... 27
1.1.5.4 FDDI (Fiber Distributed Data Interface).......................................................................................................... 36
1.1.5.5 FDMA (Frequency Division Multiple Access).............................................................................................. 38
1.1.5.6 TDMA (Time Division Method Access)........................................................................................................ 38
1.1.5.7 CDMA (Code Division Method Access)........................................................................................................ 38
1.2 Camada de Enlace.............................................................................................................. 39
1.2.1 Serviços oferecidos pela
camada de enlace........................................................................................................ 39
1.2.2 Enquadramento (Framing)...................................................................................................................................... 39
1.2.3 Controle de Erros..................................................................................................................................................... 40
1.2.4 Protocolos................................................................................................................................................................ 41
1.2.4.1 ADSL.................................................................................................................................................................... 41
1.2.4.2 ATM – Asynchronous Transfer
Mode.......................................................................................................... 45
1.2.4.3 X.25....................................................................................................................................................................... 49
1.2.4.4 Frame-Relay......................................................................................................................................................... 51
1.2.4.5 MPLS (Multi Protocol Label
Switch)............................................................................................................... 52
1.3 Camada de Rede................................................................................................................. 53
1.4 Camada de Transporte....................................................................................................... 53
1.5 Camada de Sessão.............................................................................................................. 54
1.6 Camada de Apresentação................................................................................................... 54
1.7 Camada de Aplicação.......................................................................................................... 54
1.8 Serviços.............................................................................................................................. 54
1.9 Primitivas dos Serviços...................................................................................................... 55
2 Conceitos de Internet e TCP/IP............................................................................................... 57
2.1 Evolução de TCP/IP e Internet.......................................................................................... 57
2.2 Protocolos TCP/IP.............................................................................................................. 59
2.2.1 Camada de rede........................................................................................................................................................ 59
2.2.2 Camada Inter-Rede.................................................................................................................................................. 60
2.2.3 Camada de Transporte............................................................................................................................................ 61
2.2.4 Camada de Aplicação............................................................................................................................................. 61
2.2.5 Posicionamento do Nível OSI................................................................................................................................ 61
2.2.6 Internet e Padronização de
Protocolos e Funções............................................................................................. 63
2.2.7 Exemplos de aplicação de redes
com arquitetura TCP/IP.................................................................................. 68
2.2.8 Protocolos da Camada
Inter-Rede........................................................................................................................ 70
3 Protocolo IP.............................................................................................................................. 71
3.1 Endereços IP...................................................................................................................... 71
3.2 Broadcast............................................................................................................................ 74
3.3 Mapeamento de endereços IP em
endereços de rede...................................................... 74
3.4 Roteamento IP.................................................................................................................... 77
3.4.1 Algoritmo de Transmissão de um
pacote IP....................................................................................................... 78
3.4.2 Algoritmo de Recepção de um
pacote IP............................................................................................................. 79
3.5 Roteamento estático x
Roteamento dinâmico................................................................... 80
3.6 Pacote IP............................................................................................................................. 81
3.6.1 Opções IP................................................................................................................................................................. 82
3.6.2 Fragmentação........................................................................................................................................................... 83
3.7 Endereçamento em Sub-redes........................................................................................... 84
3.8 Flexibilidade de Endereçamento........................................................................................ 86
3.9 Roteamento com Sub-rede................................................................................................. 89
3.9.1 Algoritmo de Recepção de pacote
IP com máscara........................................................................................... 90
3.10 Sub-Redes não utilizáveis:.............................................................................................. 90
3.11 Endereços IP’s para uso
exclusivo de Redes Privativas............................................... 91
4 Protocolo ICMP........................................................................................................................ 92
4.1 Echo Request e Echo Reply............................................................................................... 93
4.2 Destination Unreachable.................................................................................................... 93
4.3 Source Quench................................................................................................................... 94
4.4 Redirect.............................................................................................................................. 94
4.5 TTL Expired....................................................................................................................... 96
4.6 ICMP Router Solicitation/Advertisement......................................................................... 96
4.7 Aquisição de informações de
roteamento.......................................................................... 97
5 Protocolos da Camada de Transporte..................................................................................... 99
5.1 Camada de Transporte....................................................................................................... 99
6 Protocolo UDP....................................................................................................................... 100
6.1 Formato da mensagem UDP............................................................................................. 101
7 Protocolo TCP........................................................................................................................ 102
7.1 Características do TCP.................................................................................................... 104
7.1.1 Sliding Windows:.................................................................................................................................................. 104
7.1.2 Controle de Fluxo no TCP.................................................................................................................................... 105
7.1.3 Fluxo Normal de Transferência
de Dados.......................................................................................................... 106
7.1.4 Estabelecimento de Conexões
TCP.................................................................................................................... 106
7.2 Protocolos da camada de Rede e
Protocolos auxiliares de TCP/IP................................ 107
7.3 BOOTP e DHCP.............................................................................................................. 107
7.3.1 Protocolo BOOTP.................................................................................................................................................. 107
7.3.2 Protocolo DHCP.................................................................................................................................................... 108
7.3.2.1 Opções DHCP.................................................................................................................................................... 110
7.4 Protocolo PPP................................................................................................................... 111
7.4.1 Protocolo LCP - Link Control
Protocol............................................................................................................... 112
7.4.2 Protocolo IPCP - Network
Control Protocol...................................................................................................... 113
7.5 Protocolo SLIP................................................................................................................. 114
7.6 Interfaces do Nível de
Transporte (socket, WinSock).................................................... 115
7.7 Protocolos de Nível de
Aplicação.................................................................................... 117
7.8 Protocolo DNS.................................................................................................................. 117
7.8.1 Implementação do DNS........................................................................................................................................ 118
8 Radius – Remote
Dial-In User Service................................................................................. 120
8.1 Tipos de Serviços ao Usuário........................................................................................... 120
8.2 Atributos/ Pares de Valores............................................................................................. 120
8.2.1 Login/Atributos de senha.................................................................................................................................... 120
8.2.2 Framed-Attributes................................................................................................................................................. 121
8.3 Exemplo de Arquivo de Usuários.................................................................................... 122
8.3.1 Gerenciando o Arquivo Client............................................................................................................................. 124
9 Protocolos de Roteamento..................................................................................................... 125
9.1 Protocolo RIP................................................................................................................... 125
9.1.1 Protocolo RIP2....................................................................................................................................................... 128
9.2 Protocolo OSPF................................................................................................................ 128
9.3 Protocolo BGP-4............................................................................................................... 129
9.3.1 Por que utilizar BGP-4 ?........................................................................................................................................ 130
9.3.2 Questões relacionadas
à alocação de endereços IP....................................................................................... 132
9.3.3 Processo de seleção do envio
de pacotes via protocolo BGP-4.................................................................... 134
9.3.3.1 Valores possíveis dos
atributos..................................................................................................................... 135
9.3.3.2 Expressões regulares para
seleção de rotas.................................................................................................. 135
9.4 IP Multicast...................................................................................................................... 136
9.4.1 Roteamento Multicast.......................................................................................................................................... 137
9.4.2 MBone - Multicast Backbone............................................................................................................................. 138
9.4.2.1 Roteamento MBone.......................................................................................................................................... 138
9.4.3 Aplicações MBone............................................................................................................................................... 139
10 Gerenciamento TCP/IP...................................................................................................... 139
10.1 QUEUE – Gerenciamento de
Congestionamento........................................................ 139
10.1.1 Stochastic Fairness Queueing
(SFQ)................................................................................................................. 140
10.1.2 Class-Based Queueing (CBQ)............................................................................................................................. 140
10.1.3 Random Early-Detection (RED)........................................................................................................................... 140
10.1.4 Deficit Round Robin (DRR)................................................................................................................................. 141
10.2 SNMP - Simple Network Management Protocol......................................................... 141
10.2.1 Controlando acesso SNMP a
roteadores.......................................................................................................... 142
10.2.2 Modo não privilegiado......................................................................................................................................... 142
10.2.3 Modo privilegiado................................................................................................................................................. 142
11 Ports TCP e UDP................................................................................................................ 144
12 Modelo para solução de problemas gerais......................................................................... 145
12.1 Componentes de um modelo de
solução de problemas............................................... 145
12.2 Usando esse manual para
determinar problemas específicos...................................... 146
13 Utilizando as ferramentas de diagnóstico Cisco............................................................... 147
13.1 Usando comandos Show................................................................................................ 147
13.2 Usando comandos debug.............................................................................................. 147
13.3 Usando os comandos Ping e
Trace............................................................................... 148
14 Cenários de problema de Conectividade............................................................................ 149
14.1 Usando o comando show
interfaces serial.................................................................... 150
14.1.1 “Status” da linha serial e do
protocolo.............................................................................................................. 151
14.1.1.1 Solução.......................................................................................................................................................... 152
14.1.1.2 Saídas descartadas....................................................................................................................................... 154
14.1.1.3 Entradas descartadas................................................................................................................................... 155
14.1.1.4 Erros de entrada............................................................................................................................................ 156
14.1.1.5 Resets ocorridos na interface..................................................................................................................... 158
14.1.1.6 Oscilações de portadora.............................................................................................................................. 159
14.2 Usando o comando show
controllers............................................................................ 159
14.3 Usando comandos de debug......................................................................................... 162
14.4 Usando o comando extended ping................................................................................ 164
14.5 Determinando problemas de
clock............................................................................... 166
14.5.1 Causa dos problemas de clock............................................................................................................................ 166
14.5.2 Detectando problemas de clock.......................................................................................................................... 166
14.5.3 Isolando problemas de clock............................................................................................................................... 167
14.5.4 Isolando problemas de clock............................................................................................................................... 168
14.5.4.1 Solução.......................................................................................................................................................... 168
14.5.5 Invertendo a transmissão de
clock..................................................................................................................... 168
14.6 Ajustando buffers.......................................................................................................... 169
14.6.1 Ajustando os buffers de
sistema........................................................................................................................ 169
14.6.2 Implementando Hold Queues
(Filas de espera)................................................................................................ 171
14.7 Testes especiais em linhas
seriais............................................................................... 171
14.7.1 Testes de loopback............................................................................................................................................... 171
14.7.1.1 Testes de loopback locais para
enlaces HDLC ou PPP.......................................................................... 172
14.7.1.2 Testes de loopback remotos para enlaces HDLC ou PPP...................................................................... 173
O modelo ISO/OSI não
é uma arquitetura de rede porque ele não especifica exatamente os serviços e
protocolos a serem usados em cada camada, ele é simplesmente um modelo de
referência baseado em camadas, sendo que cada camada é dependente da camada
subsequente de nível inferior.

A figura acima exibe
a interdependência entre as camadas e as interfaces entre uma determinada
camada n e as camadas n+1 e n-1.

Na comunicação entre duas
entidades quaisquer é estabelecido uma
comunicação virtual entre a camada n do transmissor e a respectiva camada n do
receptor, entretanto, a comunicação ocorre de fato é entre a camada n e a n-1
da mesma entidade.

Esta camada está
relacionada com a transmissão simples de bits sobre um canal de
comunicação. Esta camada deve garantir
que ao entrar um sinal elétrico ele será convertido em bit 1 na entidade
transmissora, chegará um bit 1 na camada física da entidade receptora e que
será encaminhado para a camada de enlace. É nessa camada que ocorre a
determinação da taxa de transmissão devido à limitação do meio.
Voltagem para bit
"1"
Voltagem para bit
"0"
Tempo de duração de
um pulso
Modelo de
transmissão (simplex, half-duplex, full-duplex)
Pinagem dos
conectores
Uma informação pode
ser transmitida por fios elétricos pela variação de uma propriedade física
qualquer como a voltagem ou a corrente. Sinais podem ser representados como uma
função "f (t)", onde o valor da voltagem ou corrente varia com o
tempo. Assim eles podem ser analisados matematicamente.
Quando um sinal
elétrico está na forma de corrente dentro de um transmissor ou receptor
passando através de algum condutor, ele encontra muitos objetos diferentes que
são chamados componentes ou dispositivos. Há literalmente centenas de
componentes diferentes os quais existem por alguma razão, sendo que todos esses
componentes se encaixam em duas categorias, ativo ou passivo. A diferença entre
eles é muito simples de ser observada através da identificação se o componente
requer ou não fonte de alimentação. Se requer então é ativo, caso contrário,
passivo.
Todos os componentes
(ativos e passivos) possuem uma dentre duas propriedades distintas: perda ou
ganho.
Se o sinal que chega
é maior que o que sai, então o comportamento daquele componente é de perda.
Caso o sinal que chega é menor que o que sai, então o comportamento é de ganho
e ele é chamado de amplificador. Todo amplificador é um componente ativo.
A atenuação de um
sinal é o fenômeno de perda de sinal quando comparado com o sinal de entrada. Todo
componente passivo que provoca perda de sinal transforma a parcela do sinal
atenuado em calor, e essa propriedade de dissipação de calor, chamada de
impedância térmica é medida em Celsius por watt (watt é a unidade de medida de
potência).
A relação entre o
sinal de saída e o sinal de entrada, de ganho ou de perda, é medida em decibéis
(dB). Sendo que a inclusão de amplificadores ou atenuadores em
série faz com que o sinal também seja multiplicado ou dividido em série.
O modelo matemático
de cálculo de ganho ou de perda toma como premissa de que a potência do sinal
de saída pode ser bilhões de vezes maior ou menor que o do sinal de entrada,
por isso foi adotada a escala logarítmica para a sua representação.
Apenas para
referência: perda ou ganho é igual a 10log(potência de saída/potência de
entrada) medido em dB.
Na prática e amparado
pela expressão acima, quando um sinal é:
Amplificado em 2
vezes, significa que o sinal foi aumentado em 3dB.
Amplificado em 10
vezes, significa que o sinal foi aumentado em 10dB.
Atenuado em 2 vezes,
significa que o sinal foi reduzido em 3dB.
Atenuado em 10
vezes, significa que o sinal foi reduzido em 10dB.
Note que uma perda
de 6dB no sinal é a mesma coisa que uma variação de –6B no sinal, e não que o
sinal teve perda de –6dB.
Observe que devido
às propriedades matemáticas do logaritmo, o efeito multiplicativo ou divisor do
sinal torna-se apenas uma somatória ou subtração de todas as variações, assim
na cadeia de RF, dada uma quantidade de componentes de amplificação e
atenuação, a variação total é a somatória de todas as variações em potência do
sinal de cada componente ativo ou passivo.
Como o uso dessa
escala em dB não é restrita unicamente a identificação da variação de potência
de saída versus potência de entrada, logo, é possível dizer que o aumento de
clientes em 100% significa que a quantidade de clientes aumentou em 3dB.
Qualquer função g(t)
periódica com o período T pode ser escrita como uma soma de senos e cossenos.
, onde:
f = 1/T (freqüência
fundamental)
são as amplitudes dos
senos e cossenos da n-ésima harmônica.
Para qualquer g(t),
a, b e c podem ser calculados.
Nenhum sistema
transmite sinais sem perdas de energia no processo. Adicionalmente as perdas
ocorrem de maneira diferente para diferentes harmônicas, o que insere
distorção. Normalmente, as freqüências são transmitidas sem alterações até uma
determinada freqüência fc. As
freqüências acima de fc são
fortemente atenuadas.
O limite fc, muitas vezes é devido à
propriedades físicas do meio. Em outros casos, é intencionalmente colocado na
linha.
No caso de linhas
telefônicas comuns, fc = 4 KHz.
Largura de Faixa,
também conhecida como bandwidth é termo aplicado para expressar a
diferença entre a freqüência mais alta e a mais baixa que um determinado
dispositivo está manipulando em um determinado instante, medido em Hz. Comumente
bandwidth também é referenciada como largura de banda, sendo medido em bps.
Para linhas sem
ruído : Teorema de Nyquist
Velocidade Máxima =![]()
bits/seg, onde:
H é a largura máxima
de banda
V é o número de
níveis discretos.
Para linha
telefonica com fc= 3 KHz, velocidade máxima = 6 Kbps.
Para linhas com
ruído : Teorema de Shannon
Velocidade Máxima =
, onde:
H é a largura máxima
de banda
S/n é relação sinal
ruído que nada mais é que Potência do Sinal (s) dividido Potência do Ruído (n)
Assim, numa linha
telefonica com fc = 3 KHz e 30 dB, temos max rate = 30 Kbps, independente do
número discreto de níveis.
Existem vários tipos
de cabos coaxiais, cada um com suas características específicas. Alguns são
melhores para transmissão em alta freqüência, outros tém atenuação mais baixa,
e outros são imunes a ruídos e interferências. Os cabos coaxiais de alta
qualidade não são maleáveis e são difíceis de instalar e os cabos de baixa
qualidade podem ser inadequados para trafegar dados em alta velocidade e longas
distâncias.
A ligação do cabo
coaxial causa reflexão devido a impedância não infinita do conector. A
colocação destes conectores, em ligação multiponto, deve ser controlada de
forma a garantir que as reflexões não desapareçam em fase de um valor
significativo. A maioria dos sistemas de transmissão de banda base utilizam
cabos de impedância com características de 50 Ohm, geralmente utilizados nas
TVs a cabo e em redes de banda larga. Isso se deve ao fato de a transmissão em
banda base sofrer menos reflexões, devido às capacitâncias introduzidas nas
ligações ao cabo de 50 Ohm.
Os cabos coaxiais
possuem uma maior imunidade a ruídos eletromagnéticos de baixa freqüência e,
por isso, eram o meio de transmissão mais usado em redes locais.

Baseband - 50 ohms - Transmissão digital
Broadband - 75 ohms - Transmissão
Analógica.
Impedância é medida
que descreve a “dificuldade” que um sinal tem ao passar através de um condutor
qualquer. A impedância é relacionada diretamente com a parte da transmissão
antes de ser transmitida através do ar, enfim, o cabeamento e a conectorização
são os principais componentes de avaliação da impedância.
A impedância entre
os componentes interconectados deve “casar”, sendo que a qualidade da
comunicação depende diretamente do casamento dessa impedância. A taxa que
avalia o casamento de impedância é o VSWR (Voltage Standing Wave Ratio),
ou seja, o VSWR é a unidade de medição comparativa que indica o desvio
da impedância de entrada ou de saída quando comparado com 50ohm.
Assim, quanto maior
for esse desvio, maior a perda da qualidade de comunicação entre dois
componentes. Dentre outras conseqüências do efeito do descasamento de
impedância, a principal é que devido ao fato do descasamento de impedância, o
fenômeno de reflexão do sinal transmitido pode vir a causar a queima do próprio
equipamento transmissor (rádio, amplificador, etc). O
perfeito casamento é observado quando o VSWR é 1.0:1.
Os cabos de par
trançado possuem dois ou mais fios entrelaçados em forma de espiral e, por
isso, reduzem o ruído e mantém constante as propriedades elétricas do meio, em
todo o seu comprimento.
A desvantagem deste
tipo de cabo, é que devido ao fato de ele pode ser usado tanto para transmissão
analógica quanto digital, é sua suscetibilidade às interferências a ruídos
(eletromagnéticos e radiofreqüência). Esses efeitos podem, entretanto, ser
minimizados com blindagem adequada.
Esse cabo se adapta
muito bem às redes com topologia em estrela, onde as taxas de dados mais
elevadas permitidas por ele e pela fibra óptica ultrapassam, e muito a
capacidade das chaves disponíveis com a tecnologia atual. Usado também em
conjunto com sistemas ATM para viabilizar o tráfego de dados a uma velocidade
de 155 Mbps.
O padrão EIA/TIA
568-B define a pinagem normal:
/--T2 1 Branco/Laranja par2 \--R2 2 Laranja /----------T3 3 Branco/Verde / /-R1 4 Azul par3 \ par1 \-T1 5 Branco/Azul \----------R3 6 Verde /--T4 7 Branco/Marrom par4 \--R4 8 Marrom
A pinagem do cabo
cross é:
BL 1 <--------------> 3 BV L 2 <--------------> 6 V BV 3 <--------------> 1 BL A 4 <--------------> 4 A BA 5 <--------------> 5 BA V 6 <--------------> 2 L BM 7 <--------------> 7 BM M 8 <--------------> 8 M
Os pinos utilizados
por tecnologia são:
ATM 155Mbps à pares 2 e 4 (pinos 1-2, 7-8)
Ethernet 10Base-T à pares 2 e 3 (pinos 1-6)
Ethernet 100Base-Tx à pares 1,2,3 e 4 (pinos 1-8)
Token-Ring à pares 1 e 3 (pinos 3-6)
Cabeamento por
Tecnologia:
Categoria 1 = 1 Mhz à Não definido
Categoria 2 = 4 Mhz à Telefonia
Categoria 3 = 10 Mhz à 10baseT
Categoria 4 = 16 Mhz à Token Ring
Categoria 5 = 20 Mhz à 10baseT, 100baseT
Tecnicamente
falando, os dados são transmitidos por pulsos de luz., sendo que um pulso de
luz corresponde ao bit "1"e a
ausência de luz ao bit "0", sendo que a potencial de largura de faixa
é de
MHz, dentro do domínio
de freqüência do infravermelho a uma velocidade de 10 a 15 MHz. O cabo óptico
consiste de um filamento de sílica e de plástico, onde é feita a transmissão da
luz. As fontes de transmissão de luz podem ser diodos emissores de luz (LED) ou
lasers semicondutores.
O cabo óptico com
transmissão de raio laser é o mais eficiente em potência devido a sua espessura
reduzida. Já os cabos com diodos emissores de luz são muito baratos, além de
serem mais adaptáveis à temperatura ambiente e de terem um ciclo de vida maior
que o do laser.
Os cabos de fibra
óptica são mais imunes às interferências de ruídos eletromagnéticos e com
radiofreqüências e permitem um quase total isolamento entre transmissor e
receptor.
O cabo de fibra
óptica pode ser utilizado tanto em ligações ponto a ponto quanto em ligações
multiponto. A exemplo do cabo de par trançado, a fibra óptica também se aplica
a sistemas ATM, que transmitem os dados em alta velocidade.
Componentes de um
sistemas de transmissão :

"Multimode
Fiber " (MMF): Os raios incidentes
pulam de uma borda para outra da fibra.
"Singlemode
Fiber" (SMF): O diâmetro da fibra é reduzido ao comprimento de onda de
luz. Dado o fato que a luz se propaga em
linha com o condutor a eficiência do meio é maior permitindo uma distância
maior sem emendas ou repetidor.
Descrevendo de forma
mais simples possível, todo sistema de transmissão digital possui os 6
componentes básicos a seguir:
Sinal è Amplificador è (Misturador + Oscilador) è Filtro è Antena
Como já vimos um
Amplificador aumenta a amplitude do sinal, mas ele também tem a propriedade de
“ouvir” sinais extremamente baixos. Essa característica é chamada de LNA
(Low Noise Amplifier) e é unidade de medição da qualidade de detectar sinal é
Figura de Ruído, ou seja, quanto menor for a figura de ruído melhor a qualidade
de recepção do sinal.
HPA (High Power Amplifier) é o amplificador que
tem a função específica de aumentar a potência de transmissão, e é medido em
dBm (30 dBm é igual a 1 watt).
Assim, toda cadeia
de RF possui os dois amplificadores, sendo que é comum o mesmo amplificador
fazer as duas funções, mas uma função é relativa à saída do sinal (HPA) e a
outra função é relativa à entrada do sinal (LNA).
O misturador também
é conhecido como up ou down converter tem a função básica de efetuar a
conversão entre os sinais que estão sendo transmitidos pelo ar e os sinais
manipulados pelos componentes em terra.
A função básica do
oscilador é fornecer sinais ao misturador o qual os utilizará para efetuar a
conversão dos sinais.
O nome
auto-explicativo denota claramente a função desse componente, que é de permitir
somente a passagem da freqüência definida, quer seja definindo a menor
freqüência, a maior, ou ambas, neste caso o filtro é chamado de filtro de banda
passante.
Os 2 fatores que
determinam o tamanho e o formato de uma antena, são a freqüência e a cobertura,
sendo que quanto maior a freqüência, menor o tamanho, e vice-versa. Se o
objetivo de uso de uma antena for para todas as direções, essa antena é chamada
omni-direcional e tem um ganho (amplificação) inferior às antenas direcionais,
porém, teoricamente, possui abrangência de 360˚.
Quando um sinal
viaja no ar, as ondas podem trafegar horizontalmente ou verticalmente, o que é
chamado de polarização. O objetivo da implementação dessa técnica na
transmissão de sinais é para obter transmissão simultânea na mesma faixa de
freqüência no mesmo lugar ao mesmo tempo.
A tabela de alocação
de freqüência por tipo de serviços.

|
FAIXA DE FREQÜÊNCIA (Hz) |
DESIGNAÇÃO TÉCNICA |
CARACTERÍSTICA DE PROPAGAÇÃO ÚTIL |
PRINCIPAL UTILIZAÇÃO |
|
300 a 3.000 |
ELF (Extremely Low
Frequency) |
Penetram na superfície terrestre e na água |
Comunicação para submarinos e escavações de minas. |
|
3K a 30K |
VLF (Very Low
Frequency) |
Ótima reflexão na ionosfera e alguma penetração na
superfície |
Comunicação para submarinos e escavações de minas. |
|
30K a 300K |
LF (Low Frequency) |
Reflexão na ionosfera até 100K. Acima de 100K, ondas de
superfície |
Serviços marítimos e auxílio a navegação aérea. |
|
300K a 3.000K |
MF (Medium
Frequency) |
Ondas de superfície com pouca atenuação |
Radiodifusão local. |
|
3M a 30M |
HF (High
Frequency) |
Refração na ionosfera |
Radiodifusão local e distante. Serviços marítimos |
|
30M a 300M |
VHF (Very High
Frequency) |
Pode ser focalizada por antenas convenientes |
TV, sistemas comercias e particulares de comunicação. |
|
300M a 3.000M |
UHF (Ultra High
Frequency) |
Direcionamento por antenas mais eficiente, tropodifusão (1
a 2 GHz) |
TV, serviços de segurança pública |
|
3G a 30G |
SHF (Super High
Frequency) |
|
Comunicação pública à longa distância |
|
30G a 300G |
EHF (Extremely High
Frequency) |
|
|
Redes baseado em
satélites visam a troca de informações onde as distancias são estrondosas. A
sua implementação nas aplicações sem fio foi lenta, apesar da vantagem de se
poder ter um satélite, que cubra uma vasta área incluindo florestas, mares e
lagoas.
Basicamente os
satélites se estabelecem em três níveis. Os satélites de baixa órbita LEO (Low
Earth Orbit) são posicionados em torno de 1000 Km de altitude, mas, em
diferentes posições em relação á terra. Os satélites de órbitas médias MEO
(Medium Earth Orbit) estão aproximadamente a 10000 Km de altitude. E os
satélites de órbitas elevadas ou estacionárias GEO (Geosynchronous Earth Orbit)
estão situados á aproximadamente 36000 Km de altitude e em regiões próximas a
linha do equador.
|
Sistema |
Patrocínio |
Tipo |
Altura |
#Sat. (Orb.) |
Serviços |
|
Msat |
American M. Sat |
GEO |
19.000 |
1(a) |
Veicular e tel. Fixo |
|
Globis |
Consórcio União Sov. |
GEO |
20.000 |
1(a) |
Tel. Fixo e TV |
|
Odissey |
TRW |
MEO |
4.600 |
12 (a) |
Voz, dados, localiz. |
|
Ellipso |
Mobile Comm. Hold. |
MEO |
4.212 |
15 (b) 6 (a) |
Voz, dados, fax |
|
Archimede |
European Space |
MEO |
n.d |
4 (n.d) |
Voz, dados, fax |
|
Iridium |
Motorola |
LEO |
413 |
66(a) |
Voz digital, dados, localiz. |
|
Globalstar |
Loral & Qualcomm |
LEO |
750 |
48(a) |
Voz digital, dados, localiz. |
|
Áries |
Constellation |
LEO |
550 |
48(a) |
Voz digital, dados, localiz. |
|
Teledisc |
Teledisc |
LEO |
378 |
840(a) |
Tel fixo, vídeo relay |
|
Orbcom |
Orbital Sci.Corp |
LEO |
424 |
18(a)2(c) |
Dados (Store forward) |
|
Starsys |
Starsys Positio. Inc. |
LEO |
702 |
24 (a) |
Dados (Store forward) |
|
LeoStar |
Italspuzio |
LEO |
432 |
24 (a) |
Dados (Store forward) |
|
Ecco |
Telebrás,Cci,Bell Atl., etc |
LEO |
1.100 |
11 + 1 (res.) (a) |
Voz, dados, paging |
(*)
Milhas Náuticas; Orbitas (a)Circular, (b)
Elíptica, (c) Síncrona com o sol
Tabela
3.1Sistemas de comunicação via satélite.
Os satélites LEO
foram os primeiros a serem lançados e apresentam um complexo problema de
roteamento dos sinais e rastreamento em terra. Devido ás baixas altitudes é
necessário um número elevado de unidades para maior cobertura, apesar dos
equipamentos serem também menores por trabalharem em baixas potências. Os
atrasos no processos também são menores.
A segunda geração
são os satélite GEO que movimentam em sincronia com a terra, mantendo a mesma
posição em relação à linha do equador. Isto permite manter as estações
terrestres em posições fixas. O primeiro satélite GEO foi lançado pela INTELSAT
em 1965, e a partir daí, passaram a predominar.Com o sincronismo os problemas
de roteamento e rastreamento são reduzidos. Aumentando a altitude também se
reduz o número de unidades para uma maior cobertura. Uma unidade com antena não
direcionada pode cobrir até 30% da superfície terrestre, bastando três
satélites direcionados a 120 graus para uma ampla cobertura. Mas, a proximidade
à linha do equador deixa algumas regiões polares sombreadas. Também se eleva as
dimensões dos equipamentos pelo uso de grandes potências, reduz-se a
portabilidade dificulta atendimento pela massa. Outra característica importante
é o atrasos de comunicação comprometendo aplicações e sistemas. O atraso por
enlace é de aproximadamente 120 ms de ida e volta. Envolvendo mais de um
satélite esse atraso aproxima de 1s, o que inviabiliza muitos serviços.
O GSM foi criado
para prover serviços celulares digitais modernos, que permitam às pessoas
viajarem sem encontrar problemas com voz e aplicações com dados.
O desenvolvimento do
GSM começou em 1982 quando a CEPT (Conference European Post and Telegraphf),
formaram um grupo de estudo chamado de Groupe Specilale Mobile (GSM), com o
objetivo de estudar e desenvolver um sistema celular Pan-Europeia na faixa de
900 MHz, usando o espectro que foi previamente alocado.
Alguns dos critérios
básicos para o sistema proposto era boa qualidade subjetivo da fala, baixo
custo de terminais e serviços, suporte para roaming internacional. Entre
outros.
Em 1985, a
responsabilidade do GSM foi transferido para o Instituto Europeu de padrões e
telecomunicações.
Uma rede GSM é
constituído pelos mesmos componentes de uma rede celular convencional: antenas,
estações base, backbones fixos, gateways para sistemas de telefones públicas. Os
componentes funcionais de um sistemas GSM podem ser de um modo geral divididos
em: dispositivos de usuário móvel ou estação móvel, subsistema de estações base
subsistemas de rede.Cada subsistema é compreendido de entidades funcionais que
comunicam através de várias interfaces, usando protocolos específicos.
Mobile station – tem
duas partes distintas. O hardware, ou o dispositivo móvel, e uma informação de
assinaste que inclui um identificador ’único chamado de IMST( International
Mobile Subscriber Identity), que é armazenado num módulo SIM (subscriber
Identity Module) implementado num smart card.
Subsistema da estação base compreende um BTS
(Base Transceiver Station), e um BTC (Base Transceiver Controllers). O BTS
aloja os radio transceptores que definem a célula e manuseio do protocolo de
interface de radio com estações móveis. O BTC gerencia os recursos o rádio para
um ou mais BTS, incluindo setup, freqüência hopping.
Subsistema de rede –
o componente central do subsistemas de rede é o MSC (Mobile switching center), equivalente a PSTN
ou ISDN. O MSC prove todas as funcionalidade para adquirir assinantes móveis,
incluindo registros, autenticação e atualização de local, roteamento de
chamadas, em conjunção com quatro bases de dados inteligentes e juntos formas o
subsistema de rede. São eles:
- HLR (Home location Registrer) – que contem
todas as informações administrativas pertinentes a cada assinante, registrado
na respectiva rede na localização atual. Cada rede GSM contem uma única SLR
- VLR (Visitor
location Registres)- que contem informações HLR administrativas suficientes
para manter o controle de uma camada e prover a todos os serviços para cada
móvel na área controlada pelo VLR
- EIR (Equipaments
Identity Registers) que contém uma lista de todos os equipamentos moveis em uso
na rede. Cada peça do equipamento é identificado por um IMEI - (International
mobile euipament identity code).
- AuC (Autentication Center) que compreende banco de dados contendo uma copia da chave secreta armazenada no cartão SIM. O GSM tornou-se um padrão internacional para serviços celulares digitais. Cerca de 74 países assinaram um memorando para adota-lo como padrão. O desenvolvimento maior tem sido na Europa.
A infraestrutura interna do sistema
telefônifo é digital e utiliza o método PCM (Modulação Codificada por Pulsos),
que consiste em amostrar o sinal de voz limitado em 4 kHz a uma taxa de 8 kHz
(taxa de Nyquist) e representar a amplitude dessas amostras por 8 bits. Assim,
é gerada uma taxa de 8000 x 8 = 64 Kbps.
Para aproveitar a capacidade de
transmissão dos canais disponíveis (que geralmente é maior que 64 Kbps), é
utilizada uma técnica de multiplexação no tempo (TDM - Time Division
Multiplexing), onde vários sinais podem ser transportados por um único meio
físico, intercalando-se bytes (ou octetos) de cada sinal durante o intervalo de
transmissão. Por exemplo, a hierarquia européia de 2 Mbps resulta do
agrupamento de 30 canais de voz de 64 Kbps (e mais 2 canais de controle) em um
único canal de 2048 Kbps.
Dado que os sinais do sistema TDM são
provenientes de fontes diferentes ocorre assim uma diferença de sincronismo
entre eles, o que impede a multiplexação direta dos tributários (tributários
são os canais que carregam sinais dos usuários) e se faz necessária a inclusão
de bits de ajuste (enchimento) pelo multiplexador para compatibilizar a fase e
a taxa de transmissão dos canais de voz. Esta diferença de freqüência de
amostragem entre os sinais é conhecida como Plesiochronous Digital Hierarquy
(PDH) – (plesios vem do grego "próximo" e chronous = tempo) .
Uma das principais dificuldades do PDH é a
pouca flexibilidade de inserção/extração de tributários pois para se inserir ou
extrair tributários de um sistema PDH é necessária uma operação de
multiplexação/demultiplexação.
Criou-se então o SDH (Synchronous Digital
Hierarquy) com compatibilidade retroativa com o PDH. Em paralelo foi criado o
padrão SONET (Synchronous Optical Network).
A finalidade do
padrão SDH é padronizar a interconexão de equipamentos ópticos de diversos
fornecedores, que através de sua arquitetura flexível é capaz de se adaptar a
aplicações com taxas variáveis.
O sistema telefônico
é organizado de maneira altamente redundante com hierarquia de multicamadas,
algo como segue:


As linhas
telefônicas normais não podem ser usadas diretamente para interconexão de dois
computadores. Os sinais digitais são degradados drasticamente, para isso foi
criado o equipamento MODEM (MOdulator DEModulator) que converte sinais digitais
em analógicos e vice-versa, onde a portadora tem um sinal de 1 a 2 KHz que é
introduzido na linha. Sua amplitude, freqüência ou fase podem ser modulados
para se conseguir transmitir informações.
A interface entre o
computador e o modem é um exemplo de um protocolo de camada física. Este protocolo
deve especificar em detalhes as características mecanicas, elétricas,
funcionais e procedurais.

Circuit Switching
Quando uma conexão é
feita, um caminho dedicado é aberto entre a fonte e o destino. Um caminho
porta-a-porta deve ser estabelecido antes da transmissão de qualquer dado.
Normalmente aplicável para voz.
A comutação de circuitos implica na
existência de um caminho dedicado para comunicação entre duas estações, com uma
taxa de transmissão fixa. A comunicação via comutação de circuitos envolve três
etapas: - estabelecimento da conexão; - transferência da informação; -
desconexão do circuito;
Há a alocação de um canal que permanece
dedicado à conexão até a sua desconexão (feita por um dos usuários através de
sinais de controle). Para o caso de tráfego variável, este canal pode estar
sendo subutilizado e para o tráfego em rajadas há um melhor rendimento na
utilização de uma técnica de comutação por pacotes. Isso faz com que esta
técnica seja muito utilizada na transmissão de voz (telefonia) que possui as
características necessárias de taxa de transmissão constante (64 kbps) e
tráfego contínuo.
Packet Switching
Os tamanhos de
blocos são limitados. Os IMPs não têm que dispor de buffers para armazenar
blocos longos."A principal razão para implementação de paquet switching é
evitar o tempo de conexão. Aplicável para dados.
As técnicas de
comutação de circuitos apresentam alto rendimento quando utilizadas em
telefonia para transmissão de voz, pois o canal está ocupado quase que todo o
tempo de conexão (um dos usuários está sempre falando). Porém, com o aumento da
utilização da rede telefônica para a transmissão de dados, ocorrem alguns
problemas, como por exemplo, a característica de variação da taxa na
transmissão de dados e o dimensionamento da linha com base na taxa de pico,
provocando subutilização da rede quando a taxa for menor. Esses incovenientes
são evitados pelas técnicas de comutação de pacotes. Nesta técnica, quadros de
informação são transmitidos por rotas definidas nó a nó, não havendo
necessidade de estabelecimento de um caminho dedicado entre as estações. Isso
implica em um maior aproveitamento das linhas de comunicação, uma vez que os
canais podem ser compartilhados por várias mensagens ao longo do tempo (as
mensagens são transmitidas por demanda). Um dos mais graves problemas desta
técnica é que os cabeçalhos dos pacotes são excessivamente grandes e isso
dificulta a sua aplicação onde se tem altas taxas de transmissão. Além disso,
como cada pacote a ser transmitido é armazenado e transmitido apenas quando o
canal não está ocupado, quando o tráfego na rede é grande podem haver altos
retardos entre pacotes, o que não é desejável para aplicações como voz, que
exigem taxa constante de transmissão.

a) Circuit Switching b) Packet Switching
Do ponto de vista
estrutura física as redes de comunicação de dados podem ser classificadas em
redes ponto a ponto e redes de difusão.
Redes de Difusão é
aquela onde há apenas um canal de comunicação que pode ser compartilhado e para
isso depende do método de acesso de controle do meio, o qual tem por função determinar como e qual
dispositivo terá direito de usar o canal quando há uma disputa por ele.
A implementação
dentro do modelo OSI é baseado no seguinte diagrama esquemático:

Redes locais, redes de comunicação sem
fio, comunicação via satélite e os sistemas de transmissão de TV via cabo são
os principais exemplos de redes de difusão.
Esse padrão atende a
dois modos distintos de operação: half e full duplex, sendo que num dado
momento um host pode operar num ou noutro modo, ainda que o modo full duplex
não utiliza o tradicional algoritmo CSMD/CD para compartilhamento do meio.
No modo half duplex,
o método de acesso CSMA/CD é implementado quando há duas ou mais estações
compartilhando o mesmo meio de transmissão, sendo que para transmitir uma
determinada estação aguarda até que não haja transmissão no meio, isto é, não
existe nenhuma estação transmitindo, e
então envia a mensage numa forma de bit-stream. Se após o início da transmissão
a mensagem colide com a de uma outra, então cada uma das estações retransmite a
mensagem após um período aleatório de tempo.
A operação em full
duplex permite simultâneas conexões entre um par de estação usando um canal
dedicado. Como não há necessidade do transmissor observar o meio não a disputa
pelo meio compartilhado nesse modo. Full duplex pode ser utilizado somente
quando todas as seguintes situações são verdadeiras:
O meio físico é
capaz de suportar simultaneamente transmissão e recepção sem interferência.
Quando há exatamente
duas estações conectadas através de um enlace full-duplex ponto-a-ponto. Como
não há disputa pelo meio, os algoritmos do CSMA/CD são desnecessários.
Ambas estações na
rede local são capazes e estão configuradas para operação no modo full-duplex.
A mais comum
operação full-duplex consiste de um switch com cada porta conectada a uma única
estação. Por essência os repetidores não operam em modo full-duplex.
Preâmbulo (7 octetos), contém sempre
bits alternados 1 e 0, assim: 10101010
Start Frame Delimiter (1 octeto),
sempre: 10101011
Endereço de origem e destino (6 octetos)
Multicast: envio de uma
mesma mensagem para um grupo de estações (MSB = 1)
Broadcast: envio de uma
mesma mensagem para todas as estações. (Todos os bits = 1)
Tamanho/Tipo (2 octetos): Se o conteúdo
é menor que X’0600’ o campo identifica tamanho, caso contrário, identifica o
tipo encapsulado do campo Dados.
X’0800’: IPV4
X’0806’: ARP
X’809B’: AppleTalk
Dados/PAD: O tamanho mínimo desse campo
é de 46 octetos, sendo que quando o campo de dados é menor que algum múltiplo
de 8, esse campo é complementado pelo PAD.
FCS: O
algoritmo CRC é utilizado para calcular o valor do FCS que sera transmitido e
recebido. O campo FCS é calculado em função dos conteúdos dos campos origem,
destino, tamanho/tipo e dados/PAD. A codificação é definida pelo seguinte
gerador polynomial:
G(x)=x^32 +x^26 +x^23 +x^22 +x^16 +x^12 +x^11 +x^10 +x^8 +x^7 +x^5 +x^4 +x^2 +x+1
A eficiência desse
protocolo numa operação half-duplex é dada pela fórmula:
Eficiência =
, onde:
B = largura de banda
L = comprimento do cabo
C = velocidade de propagação
F = comprimento do frame
A rede token ring
consiste de um sistema baseado em estrela com estações conectadas ao
concentrador TCU (Trunk Coupling Unit), conforme exibe a figura abaixo. Um
concentrador contém múltiplas TCU’s e são conectados serialmente utilizando as
portas “ring in” e “ring out”, formando assim o caminho principal e o backup. A
interconexão dos dois caminhos pode ser realizada através de repetidores e
conversores que dividem o caminho total em segmentos distintos.

Cada TCU tem um modo de conexão
(“insertion” or “bypass”) descrito na figura como “Conectada” ou
“Desconectada”. Esse mecanismo é normalmente controlado pelo modulo RAC (Ring
Access Control) de cada estação. Enquanto está em “bypass” a estação realiza
uma série de self-tests entre a interface e o TCU. Assim que o TCU recebe a
sinalização da estação muda o status para o modo “insertion”, permitindo o
início da recepção de dados.
As informações no
token ring é transferido sequencialmente, bit a bit, iniciando pelo primeiro
bit inserido na rede. Na figura acima, caso a Estação 1 transmita para a
Estação 3, o fluxo de dados não passará pela Estação 2, o que seria a situação
normal caso a Estação 2 estivesse no modo “insertion”.
Cada estação
regenera e repete cada bit que passa através dela.
Uma estação ganha o
direiro de transmitir no meio assim que ela detecta o token passando pelo meio
físico. Um token é um sinal de controle constando uma sinalização sequencial
que circula no meio. Qualquer estação após detectar um apropriado token pode
capturá-lo modificando-o e incluindo a sequência de início de e demais campos
de controles, campos de status, campos de endereços, informações de roteamento,
dados, checksum e finalmente a sequência de fim de frame.
O contador CTO
(Counter, Transmitted Octet) define o período máximo de tempo que uma estação
pode transmitir no meio antes de liberar o token.
A velocidade de
propagação de um sinal elétrico num cabo coaxial é da ordem de 200 metros por
microssegundo.
D = V*T
D = 200 m/microseg.*1/x microseg.
D = 200/x
metros
Por exemplo, numa
rede rodando a 10 Mbps: D = 20 metros.

Formato do frame
token:
|
SD |
AC |
ED |
SD = Starting Delimiter (1 octeto)
AC = Access Control (1 octeto)
ED = Ending Delimiter (1 octeto)
Formato do frame de
dados:
|
SD |
AC |
FC |
DA |
SA |
RI |
INFO |
FCS |
ED |
FS |
IFG |
SD =
Starting Delimiter (1 octeto)
AC =
Access Control (1 octeto)
Indica
a prioridade do token
FC = Frame
Control (1 octeto)
Indica
o tipo de frame
DA =
Destination Address (6 octetos)
SA =
Source Address (6 octetos)
RI = Routing Information
(0 até 30 octetos)
INFO = Information (0 or mais
octetos)
FCS = Frame Check Sequence (4
octetos)
ED = Ending Delimiter (1
octeto)
FS = Frame Status (1 octeto)
Indica
se o frame é originado ou não pela estação que está de posse do token.
IFG =
Interframe Gap
Em condições normais
o primeiro bit do frame vai circular todo o anel e retornar antes de terminar a
transmissão do frame. Por isto, a estação retransmissora deve retirar os bits
que ela coloca na rede.
Enquanto o controle
das redes em duto é feito de maneira descentralizada, Token Ring tem uma
estação de monitoramento, sendo que qualquer estação tem capacidade de ser
monitora.
As velocidades de
transmissão dentro do anel são normalmente de 4 Mbps ou 16Mbps. Em anéis de 4
Mbps apenas um token ou frame de dados pode circular pelo anel num determinado
tempo. Isto assegura uma ordem, um tempo determinado para circular, de acordo
com o tamanho do anel e também ausência de colisões para as mensagens/frames.
Nos anéis de 16Mbps,
é implementado o conceito chamado de “Early Token Release”, o qual permite que
um ou mais frames estejam circulando pelo anel ao mesmo tempo que o token. Neste
caso uma estação pode enviar o token logo após ter inserido seus dados no anel,
ao invés de aguardar uma volta completa para retirar sua mensagem e liberar um
novo token no anel. Assim, uma estação poderá transmitir seus dados antes que a
primeira tenha sido retirada do anel. Isto faz com que seja aumentado a
quantidade de informações na rede, especialmente para pequenas
mensagens/frames.
![]()

Padrão implementado para o sistema
Wireless LAN, onde os transmissores têm baixa potência, significando que a os
sinais terão a potência somente para curtas distâncias, além disso substâncias
metálicas acabam obstruindo o sinal. A ausência da comunicação plena faz com
que os elementos da Wireless LAN não possam utilizar as mesmas características
do CSMA/CD.
A
B
C
“Hiden Station”
ocorre as situações onde a estação C está distante o suficiente de A de tal
forma que não haja a possibilidade de conexão direta. Para assegurar que eles
compartilhem o meio de forma correta, usando a técnica do CSMA/CA, a estação A
envia um RTS para a estação B, solicitando o início da comunicação, o qual, por
sua vez, retorna com um CTS para A informando que está pronto para receber. O
método backoff (retransmissão do pacote por n vezes) entra em ação caso as
estações A e C transmitam o RTS simultaneamente (o que obviamente causou uma
colisão).
A faixa de
freqüência de implementação do Wireless LAN é conhecida como ISM (Industrial,
Scientific and Medical), a qual foi definida pelo FCC (Federal Communications
Commission) em 1985 como sendo freqüência não licenciada com possibilidade de
uso comercial para comunicação wireless desde que a transmissão ocorra com potência
máxima de 1 watt.
As faixas de
freqüência alocadas para ISM são:
|
UHF |
902-928 MHz |
|
S-Band |
2.4-2.5 GHz |
|
C-Band |
5.725-5.875 GHz |
Pelo motivo de uso
de baixa potência de transmissão e pelo fato de que existe uma variedade e
quantidade muito ampla de uso dessa faixa, foi criada a comunicação por
modulação de espalhamento espectral (spread spectrum), a qual permite o
compartilhamento da mesma faixa de freqüência entre várias estações
(ponto-multiponto), sendo que a característica mais importante é a transmissão
dos sinais espalhados numa faixa de freqüência maior que a faixa de freqüência
alocada para transmissão daquela estação.
No caso de Wireless
LAN, embora cada canal tem 5khz os sinais são transmitidos espalhados numa
faixa de freqüência de 22khz, sendo assim, num mesmo ponto de conexão pode ser
utilizado somente 3 canais (1, 6 e 11), se for implementado polarização inversa
a quantidade de canais em uso pode chegar a 6 sem comprometer e sem interferir
um canal no outro.
O formato do frame
802.11 é:

Frame Control :
Indica o tipo do frame
Duration/ID :
Se o conteúdo for menor que X’7D8’ então o dado é o ID de association, caso
contrário indica o período de duração.
Addr x : Indica os endereços MAC de destino, de
origem, do receptor e do transmissor.
Sequence Control :
É o indicador de sequenciação do frame
Frame Body :
Campo de dados
FCS : CRC-32
\DSSS usa uma seqüência de 11 bits para espalhar
os dados antes de transmiti-los. Cada bit transmitido é modulado por esta
seqüência. Este processo espalha a energia de rádio-freqüência em torno de uma
larga largura de banda que pode ser necessária para transmitir o dado. A carga
de processamento do sistema é definido como sendo 10 vezes o logaritmo da taxa
de espalhamento (também conhecido como taxa de chip) para o dado. O receptor
concentra o sinal de rádio-freqüência recebido para recuperar o dado original. A
vantagem deste técnica é que ela reduz os efeitos de interferência de fontes de
banda estreita.
FHSS tem 22
"modelos de salto" (hop patterns) para serem escolhidas. Esta camada
é requerida para saltar em torno da banda ISM de 2,4 GHz, cobrindo 79 canais. Cada
canal ocupa 1 MHz de largura de banda e deve saltar para uma taxa mínima
especificada pelo corpo de regulamento do país intencionado.
........Cada uma das camadas físicas usa seus próprios
cabeçalhos para sincronizar o receptor e determinar o formato de modulação do
sinal e o tamanho do pacote de dados. Os cabeçalhos de camada física são sempre
transmitidos a 1 Mbps. Campos pré-definidos nos cabeçalhos permitem a opção de
aumentar a taxa de dados para 2 Mbps para o pacotes de dados atual.
O plano de
freqüência do DSSS (Direct Sequence Spread Spectrum) é:
|
Canal |
Freqüência |
EUA (X’10’) |
Canadá (X’20’) |
Europa (X’30’) |
Espanha (X’31’) |
França (X’32’) |
Japão (X’40’) |
|
1 |
2412 MHz |
X |
X |
X |
- |
- |
- |
|
2 |
2417 MHz |
X |
X |
X |
- |
- |
- |
|
3 |
2422 MHz |
X |
X |
X |
- |
- |
- |
|
4 |
2427 MHz |
X |
X |
X |
- |
- |
- |
|
5 |
2432 MHz |
X |
X |
X |
- |
- |
- |
|
6 |
2437 MHz |
X |
X |
X |
- |
- |
- |
|
7 |
2442 MHz |
X |
X |
X |
- |
- |
- |
|
8 |
2447 MHz |
X |
X |
X |
- |
- |
- |
|
9 |
2452 MHz |
X |
X |
X |
- |
- |
- |
|
10 |
2457 MHz |
X |
X |
X |
X |
X |
- |
|
11 |
2462 MHz |
X |
X |
X |
X |
X |
- |
|
12 |
2467 MHz |
- |
- |
X |
- |
X |
- |
|
13 |
2472 MHz |
- |
- |
X |
- |
X |
- |
|
14 |
2484 MHz |
- |
- |
- |
- |
- |
X |
Pelo fato da técnica
de modulação em quadratura QPSK a largura de banda total do sistema pode chegar
a 11Mbps.
Existem duas
arquiteturas de rede: Infra-estrutura e Rede Ad Hoc. Uma Rede infra-estrutura é
uma arquitetura de rede para prover comunicação entre clientes Wireless LAN e
clientes de redes tradicionais com fio. A transição de informações da Wireless
LAN para o meio tradicional é feito via um Access Point. A área de cobertura é
definida por um Access Point (AP) e ele associa os clientes Wireless, e todos
os dispositivos associados a rede, isto define a área de cobertura básica
(basic service set – BSS).
Uma rede Ad Hoc é a
arquitetura de rede que é utilizada para comunicação somente entre clientes
Wireless.
Uma rede Ad Hoc não
acessa clientes de redes com fio, e não necessita um Access Point para fazer
parte da rede. Os principais serviços que a Camada de Rede deve prover são :
a)
Transferência de Informações: Os clientes Wireless usam o protocolo CSMA/CA
para acesso ao meio;
b) Associação:
Este serviço habilita o estabelecimento de links Wireless entre clientes
Wireless e Access Points na rede Infra Estrutura;
c)
Reassociação: É a forma de associação de um cliente Wireless, que se move da
sua para uma outra BSS. Duas BSS’s adjacentes formam uma Extensão da área de
cobertura básica (Extended Service Set – ESS), e são definidas por ESSID. Com a
definição de um ESSID, o cliente Wireless pode fazer roaming de uma área para
outra. Apesar da reassociação ser especificada na norma 802.11, o mecanismo que
permite a determinação dos Access Points para roaming não é especificado;
d) Autenticação:
Autenticação é o processo de dar um cliente Wireless a sua identificação, na
IEEE 802.11 este processo determina a prioridade para um cliente Wireless LAN
associado com um Access Point. Por default os dispositivos da IEEE 802.11
operam em um sistema aberto, onde essencialmente qualquer cliente Wireless pode
associar-se a um Access Point sem checar suas credenciais. Autenticação
verdadeira é possível com o uso da opção da IEEE 802.11, conhecida como Wired
Equivalent Privacy ou WEP, onde uma chave compartilhada (SK) é configurada no
Access Point e em seus clientes. Somente estes dispositivos com uma SK válida
permitirão ser associados ao Access Point;
e)
Privacidade: Por padrão as informações são transferidas claramente, qualquer
dispositivo que atenda a IEEE 802.11 pode escutar o tráfego da camada física
dentro do range e antes de enviar pelo meio Wireless, usando um algoritmo de
encriptação de 40 bits conhecido como RC4. A mesma chave compartilhada (SK) que
é usada na autenticação, é usada para encriptar ou decriptar a informação,
então somente os clientes Wireless com a SK exata podem decifrar corretamente
as informações.
Há 2 modos de
energia, um Modo Ativo (Active Mode), onde um cliente Wireless provê energia
para transmitir e receber, e um modo econômico (Power Save), onde o cliente
Wireless não é habilitado para receber ou transmitir, consumindo pouca energia.
Atualmente o consumo de energia não é definido, depende de cada implementação.
Padronização e
interoperabilidade entre dispositivos que usam a interfaces da mesma camada
física é a intenção da norma IEEE 802.11. A interoperabilidade de produtos
Wireless LAN é importante, uma vez que vários produtos, de vários fabricantes
devem coexistir e se inter-relacionar em uma Wireless LAN. Cinco áreas
específicas são vitais para a interoperabilidade da Wireless LAN:
a) Comunicação de
Dados: Com segurança, a comunicação de dados deve ocorrer entre clientes, como
também entre clientes e hosts ou Access Point e vice–versa;
b) Segurança:
Informações devem ser protegidas de acessos não autorizados mas ao mesmo tempo,
clientes e Access Point devem ser habilitados a reconhecer e compartilhar
esquemas de segurança;
c) Roaming: Devido
a característica da uma Wireless LAN, os clientes devem possuir a
facilidade de deslocamento sem perder a conectividade e a integridade das
informações;
d) Configuração:
Configurações de clientes e hosts devem ser configuráveis entre diferentes
fabricantes. Isto inclue configurações regionais, identificação de domínios,
canais e sub-canais.
e) Coexistência:
Diversos produtos Wireless devem coexistir com outros produtos Wireless LAN e
LANs com fios, sem interferência.
Vários computadores,
cada um equipado com placas de interface de rede sem fio. Cada computador pode
comunicar diretamente com todos os outros equipados com placas de interface. Eles
podem compartilhar arquivos, impressoras, mas não acessar os recursos de uma
rede fixa.

Uma rede local sem
fio pode possuir um ponto de acesso, que funciona como os hubs das outras
redes. Esses pontos de acesso podem conectar (como uma ponte) uma rede local
sem fio a uma rede local fixa, permitindo aos computadores acessar os recursos
dessa rede.

.
Os pontos de acesso
podem ser hardwares dedicados (HAP – Hardware Access Point) (figura
acima), ou softwares rodando em computadores equipados com uma placa de
interface de rede sem fio (figura abaixo).

Se uma área é muito
grande para ser coberta por um único ponto de acesso, então múltiplos pontos de
acesso ou pontos de extensão podem ser usados.

Pontos de extensão
não foram definidos nos padrões de transmissão sem fio, porém foram
desenvolvidos por alguns fabricantes. A principal diferença entre pontos de
acesso (figura acima) e pontos de extensão (figura abaixo) está no fato de os
pontos de extensão não necessitarem de uma rede fixa.

Um usuário pode se
mover da Área 1 para a Área 2 de forma transparente, ou seja, sem a perda da
comunicação. O hardware da rede automaticamente muda o usuário para o ponto de
acesso em que o sinal for o melhor.

Na figura abaixo,
dois pontos de acesso foram utilizados para conectar a Rede Ethernet Fixa 1 com
a Rede Ethernet Fixa 2. Nesse caso, os pontos de acesso devem estar dentro do
alcance de comunicação.

Na figura abaixo,
duas antenas direcionais foram utilizadas, permitindo que as duas redes fixas
estejam a uma distância maior.

Redes locais sem fio
podem se conectar à Internet, uma vez que o protocolo 802.11 só padroniza as
camadas 1 e 2 da Arquitetura ISO/OSI, e os protocolos de roteamento (como IP) e
de transporte (como TCP) são definidos para as camadas 3 e 4 do ISO/OSI,
respectivamente.

O acesso de redes
locais sem fio à Internet pode ser feito tanto por um HAP (figura acima) quanto
por um computador (figura abaixo).

Se uma rede local
fixa já existente tiver uma conexão à Internet, então os pontos de acesso
simplesmente se conectam à rede local sem fio e permitem a estes computadores
usar a conexão existente da mesma forma que computadores da rede local fixa
(figura abaixo).

De forma análoga, se
é um ponto de acesso que tem uma conexão à Internet, então tanto a rede local
sem fio quanto a fixa podem se conectam à Internet (figura abaixo).

Funcionamente o FDDI
opera a 100Mbps, em distâncias a 200Km, permitindo até 1000 estações no ring,
sendo que é normalmente utilizado em backbones
A fibra ótica é o
meio físico usual, normalmente MMF pois até 100Mbps não é necessário SMF, sendo
que consiste de dois canais em fibra; um no sentido horário e outro no sentido
anti-horário. Se um anel quebra, o outro assume.
A estação deve
regenerar o token logo após a transmissão de seu frame (diferente do 802.5). O
formato dos frames do FDDI são similares ao 802.5. Adicionalmente, permite a
transmissão síncrona de frames para uso em transmissão de voz (PCM) e tráfego
ISDN.
O formato do frame é
o seguinte:
Formato do frame
token:
|
SD |
AC |
ED |
SD = Starting
Delimiter (1 octeto)
AC = Access Control
(1 octeto)
ED = Ending
Delimiter (1 octeto)
Formato do frame de
dados:
|
PREAMBLE |
SD |
FC |
DA |
SA |
INFO |
FCS |
ED |
PREAMBLE = Padrão de bits para “setar” o clock
do receptor(1 ou mais octetos)
SD =
Starting Delimiter (1 octeto)
FC =
Frame Control (1 octeto)
DA =
Destination Address (6 octetos)
SA =
Source Address (6 octetos)
INFO =
Information (0 or mais octetos)
FCS =
Frame Check Sequence (4 octetos)
ED =
Ending Delimiter (1 octeto)

1 erro em 2.5x
bits (pior caso)

É o mecanismo mais
simples de alocação de freqüência,
aplicável quando existe um número fixo e pequeno de dispositivos e cada
um tem uma carga grande de tráfego, entretanto, como a alocação da faixa de
freqüência é fixa por dispositivo, o sistema usa de forma ineficiente o meio.
Os sinais são transmitidos
através de portadoras usando diferentes freqüências centrais de RF. O arranjo
mais simples dentro da arquitetura FDMA utiliza uma portadora para cada canal.
Este esquema é conhecido como SCPC (Single Channel Per Carrier). Na estação
base, os canais podem ser acessados por qualquer estação móvel, sendo a
alocação feita sob o demanda à medida que os recursos forem sendo solicitados.
Dada uma banda no espectro de freqüência, o número de canais será função da
largura de cada canal. Dentre os canais disponíveis, uma pequena porção é
dedicada a canais de controle, sendo os demais utilizados para tráfego de voz.
O AMPS (Advanced
Mobile Phone System), que é o sistema celular analógico ainda em operação no
Brasil utiliza FDMA com 416 canais 30KHz em cada uma das bandas A e B, para
cada uma das quais reservam-se 25MHz de banda (12,5MHz para os canais diretos e
outros 12,5MHz para os reversos).
A mesma portadora
pode ser compartilhada por diferentes canais, fazendo uso desta portadora em
diferentes instantes de tempo. O maior número de canais por portadora implica
uma maior taxa de transmissão que, por sua vez implica maior faixa. Desta
forma, técnicas de redução da taxa de transmissão, através de algoritmos
eficientes de codificação da fala e de esquemas eficientes de modulação são
essenciais.
Tanto as portadoras
quanto os intervalos de tempo alocados aos canais podem ser acessados de forma
troncalizada. Note que o esquema TDMA descrito e utilizado pelos sistemas
celulares digitais é, efetivamente, uma combinação FDMA e TDMA. A transmissão
neste esquema processa-se na forma buffer-and-burst (armazenamento-e-surto),
sendo que transmissão e recepção utilizam intervalos distintos.
Os sistemas
celulares digitais com arquitetura TDMA em operação no Brasil, o D-AMPS
(Digital AMPS) utiliza o padrão IS-136, em que três canais compartilham uma
portadora de largura de 30 KHz, com uma taxa de transmissão de 48,6Kbps. O
sistema digital europeu, o GSM (Global System for Mobile Communication), também
com arquitetura TDMA, utiliza 8 canais em portadoras de 200KHz de largura,
transmitindo a uma taxa de 271Kbps.
A mesma portadora é
compartilhada por todos os usuários que podem transmitir simultaneamente (todos
ao mesmo tempo) através de sinais que ocupam toda a faixa disponível. Para
isto, cada conexão transmissor-receptor é provida com um código particular, de
tal forma que as conexões simultâneas são diferenciadas por códigos distintos e
com baixa correlação (similaridade) entre sí. Idealmente, esta correlação
deveria ser nula através do uso de códigos ortogonais. O par
transmissor-receptor trabalha de forma síncrona e, obviamente, o código
utilizado na transmissão deverá ser conhecido na recepção. Este sincronismo, no
entanto, constitui sincronismo entre pares individuais e não entre todos os
pares, isto é de sistema. De fato, no que concerne ao sistema, os canais direto
(base-estação) operam de forma síncrona, enquanto os canais reversos
(estação-base) trabalham de forma assíncrona.
Os sistemas
celulares CDMA, hoje em uso, seguem o padrão IS-95, em que as taxas básicas são
9,6 ou 14,4 Kbps, e a taxa de espalhamento é de 1,2288Mbps, utilizando uma
portadora de 1,25Mhz de banda. O uso de uma taxa básica menor (9,6Kbps) implica
maior capacidade (ganho de processamento de 128, ou seja, 21dB), porém menor
qualidade de transmissão. O uso de uma taxa maior (14,4Kbps) implica menor
capacidade (ganho de processamento de 85, ou seja, 19 dB), porém melhor
qualidade de transmissão.
A tarefa desta
camada é tornar um sistema de transmissão cru e transformá-lo numa linha que se
mostra livre de erros de transmissão à camada de rede. Organiza a entrada em data frames (algumas centenas de bits),
transmite os frames sequencialmente e procura frames de aviso de recebimento
para enviar de volta ao transmissor.
Coloca sinalizadores
e identifica inequivocamente o início e fim de dados.
Resolve problemas de
danificação, perda e duplicação de frames.
Deve tratar do
problema de conexão de máquinas de diferentes velocidades.
Dentre as principais
tarefas desempenhadas pela camada de enlace está o agrupamento dos bits
recebidos a partir da camada física em quadros, a divisão de um pacote enviado
pela camada de rede em vários quadros, a detecção e correção de erros ocorridos
durante a transmissão de um quadro e o controle do fluxo de quadros de forma a
evitar que uma máquina lenta não seja derrubada por uma máquina que pode enviar
quadros mais rapidamente que a primeira pode receber.
Os serviços
oferecidos pela camada de enlace pode, de forma grosseira, serem divididos em
três categorias:
Serviços sem conexão
e não confirmado.
Serviços sem conexão
e confirmado.
Serviço orientado a
conexão e confirmado.
Uma vez que a camada
de transporte oferece serviços com confirmação, por exemplo o protocolo TCP, a
oferta de serviços confirmados não é um requisito necessário à camada de
enlace, mas sim uma otimização. Imagine que a camada de transporte esteja
enviando uma mensagem que será dividida em 10 quadros pela camada de enlace e
que 20% dos quadros enviados são perdidos. Neste cenário, se somente a camada
de transporte implementa serviços confirmados a mensagem levará um longo
período de tempo para ser transmitida sem problemas, pois a camada de
transporte terá retransmitir várias vezes os quadros da mensagem até que todos
eles sejam recebidos sem erros. Entretanto, se a confirmação se desse quadro a
quadro, a mensagem seria transmitida de forma mais rápida e menos
retransmissões seriam necessárias. Em canais confiáveis, tais como as fibras
óticas, exigir que os serviços da camada de enlace sejam confirmados pode não
trazer muitos benefícios e impor um alto custo à transmissão de dados, mas num canal
de rádio(sem fio) essa exigência é tão benéfica quanto aconselhável.
Enquadramento é a
ação de dividir uma sequência de bits em quadros. Há várias maneiras para se
fazer esta divisão, por exemplo, pode-se inserir intervalos de tempo entre dois
quadros da mesma maneira que inserimos espaços em branco entre duas palavras de
um texto.Entretanto, como poderíamos garantir que todas as máquinas da rede
estivessem sincronizadas ou que intervalos de tempo não sejam inseridos durante
a transmissão de um quadro? É muito difícil e arriscado utilizar esta
metodologia para identificar o início e fim de cada quadro, outras metodologias
serão discutidas:
a. Contagem
de caracteres
Um campo no
cabeçalho de cada quadro é utilizado para especificar o número de caracteres no
quadro. O problema com este método é que o conteúdo deste campo pode ser
alterado por um erro durante a transmissão do quadro. Por exemplo, se para um
quadro o conteúdo deste campo é 5 e após sua transmissão o quadro é recebido com
o valor 7 neste campo, a máquina que recebeu o quadro irá sair da sincronização
e não conseguirá mais encontrar o início do próximo quadro. Mesmo que a máquina
destino possa detectar o erro no quadro recebido, ela continua não tendo como
dizer onde o próximo quadro começa. Enviar um quadro de volta para solicitar a
retransmissão dos dados não ajudaria muito, pois a máquina destino não tem como
saber quantos caracteres foram perdidos. Por estas razões este método raramente
utilizado.
b. Uso de
caracteres especiais para marcar o início e o final de um quadro e realizar o
estofamento de caracter (character stuffing)
Este método resolve
o problema da re-sincronização encontrado no método anterior, todo quadro deve
iniciar com a sequência de caracteres DLE STX e finalizar com a sequência DLE
ETX. (DLE significa Data Link Escape, STX
significa Start of TeXt e ETX significa End of TeXt). Desta maneira, a máquina destino poderá sempre
identificar os limites de um quadro.
Um problema sério
ocorre quando dados binários são enviados, tais como, arquivos de programas ou
imagens. Quando este tipo de dado é enviado podemos facilmente encontrar as
sequências DLE STX e DLE ETX no meio dos dados, isso irá certamente interferir
no funcionamento do método de enquadramento. Para resolver este problema, a
máquina remetenrte deve, após cada ocorrência do caracter DLE nos dados a serem
transmitidos, inserir um novo caracter DLE. Os caracteres DLE nos dados são
sempre duplicados. Na máquina destino os caracteres DLE inseridos são retirados
antes do quadro ser passado para a camada de rede. Esta técnica é chamada estofamento
de caracter. Desta maneira, as sequências de ínicio e final de quadro
poderão sempre serem reconhecidas.
A maior disvantagem
deste método é que ele é mais adequado para o envio de dados que possam ser
divididos em um número inteiro de caracteres de 8-bits cada, em particular este
método é adequado para o envio de dados no formato ASCII.
c. Uso de flags
para marcar o início e o final de um quadro e realizar o estofamento de bit (bit
stuffing).
Este método permite
aos quadros conterem um número arbitrário de bits assim como o envio de
caracteres com um número arbitrário de bits por caracter. Cada quadro deve
iniciar e ser finalizado com um padrão especial de bits, 01111110, chamado flag.
Se a camada de enlace da máquina remente encontrar uma sequência de 5 bits 1
consecutivos nos dados a serem transmitidos, ela irá inserir de forma
automática um bit 0 logo após a sequência de 1s. Esta técnica é conhecida como estofamente
de bits. Quando a camada de enlace da máquina destino percebe uma
sequência de 5 bits 1 seguida por um bit 0 no quadro recebido, ela retira esse
bit 0 dos dados e então os passa para a camada de rede. Então, se os dados a
serem transmitidos possuem o padrão 01111110, essa parte dos dados será
transmitida como 011111010. Desta forma, os limites de um quadro poderão sempre
serem reconhecidos.
d. Violando
a codificação da camada física.
Este método só pode
ser aplicado a redes onde a codificação utilizada pela camada física contém
alguma redundância. Por exemplo, algumas LANs codificam um bits de dado como 2
bits físicos. Normalmente, um bit 1 é codificado como um par alto-baixo de bits
e um bit 0 é codificado como um par baixo-alto de bits. Então, as combinações
alto-alto e baixo-baixo podem ser utilizadas para marcar o início e o fim de um
quadro. O uso de códigos inválidos para a camada física é parte dos padrões de
LANs IEEE 802.
Quando a camada de
enlace oferece um serviço confirmado ela, geralmente, envia um quadro de
reconhecimento positivo (ack) sempre que um quadro é recebido sem problemas e
envia um quadro de reconhecimento negativo sempre que um quadro é recebido com
problemas.
Entretanto, quando
um quadro é completamente perdido devido a, por exemplo, uma falha do hardware,
a camada de enlace da máquina destino não tem porque reagir e a camada de
enlace da máquina remetente ficaria eternamente esperando por um quadro de
reconhecimento positivo ou negativo. Este problema introduz a necessidade de
temporizadores nos protocolos da camada de enlace, assim a camada de enlace da
máquina remetente esperaria somente por um período de tempo pré-estabelecido e
então retransmitiria o quadro perdido. O tempo de espera dever longo o
sufuciente para o quadro chegar à máquina destino e o quadro de reconhecimento
retornar à máquina remetente.
Porém, quando o
quadro de reconhecimento é perdido, o tempo de espera por ele irá expirar e a
camada de enlace da máquina remetente irá retransmitir o quadro que foi
transmitido perfeitamente. Portanto, um mecanismo deve ser implementado pelos
protocolos da camada de enlace para evitar a duplicidade de quadros. Os
protocolos poderiam, por exemplo, numerar os quadros de uma mensagens e
descartar quadros repetidos.
A taxa de passagem dos dados depende de vários fatores, tais como o comprimento da linha de cobre, diâmetro, presença de derivações, e interferência de outros pares. A atenuação da linha aumenta com o comprimento e a freqüência, e diminui com aumento do diâmetro do fio. Ignorando as derivações, o ADSL terá a seguinte performance:
|
Taxa |
Medida do Fio |
Distância |
Diâmetro |
Distância |
|
1.5/2.0 Mbps |
24 AWG |
18.000 pés |
0.5 mm |
5.5 Km |
|
1.5/2.0 Mbps |
26 AWG |
5.000 pés |
0.4 mm |
4.6 Km |
|
6.1 Mbps |
24 AWG |
12.000 pés |
0.5 mm |
3.7 Km |
|
6.1 Mbps |
26 AWG |
9.000 pés |
0.4 mm |
2.7 Km |

Enquanto a medida varia conforme a
empresa, estas capacidades podem cobrir até 95% da planta dependendo da taxa de
dados desejada. Os clientes além destas distâncias podem ser atendidos com um
sistema digital baseado em fibras óticas. Enquanto estes sistemas de cabeamento
ficam comercialmente disponíveis, as companhias de telefone podem oferecer
acesso virtualmente presente em um tempo relativamente pequeno.
Muitas aplicações previstas para o
ADSL envolvem vídeo comprimido digital. Com um sinal em tempo real, o vídeo
digital não pode ter o nivel de erro comumente encontrado em sistemas de
comunicações de dados. O modem ADSL incorpora um sistema de correção que
dramaticamente reduz os erros causados por ruídos elétricos, além dos presentes
nos pares trançados.
O ADSL depende de um processo
digital avançado de sinal e algoritmos criativos para comprimir a informação
para linhas de telefone com pares-trançados. Além disso, foram necessários
muitos avanços em transformadores, filtros analógicos, e conversores de A/D. As
linhas de telefone longas podem atenuar sinais a um megahertz (a extremidade
inferior da faixa usada pelo ADSL) por 90 dB, forçando as seções analógicas do
modem ADSL a trabalhar muito para atingir faixas largas e dinâmicas, canais
separados, e manter baixas figuras de ruído.
No lado de fora, o ADSL parece um
simples duto de dados síncrono transparente com várias taxas de dados em cima
de linhas de telefone comuns. No lado de dentro, onde todos os amplificadores
trabalham, há um milagre da tecnologia moderna.

Ao criar canais múltiplos, os
modems ADSL dividem a largura de banda disponível de uma linha telefônica em
uma das suas duas formas: Multiplexing por Divisão de Frequência (FDM) ou
Cancelamento de Eco. O FDM determina uma faixa inferior de dados e outra faixa
superior. A inferior é dividida então através de multiplexação por divisão de
tempo em um ou mais canais de alta velocidade ou em um ou mais canais de baixa
velocidade. A faixa superior está também multiplexada em canais correspondentes
de baixa velocidade. O cancelamento de eco sobrepõe a faixa superior na
inferior, e separa os dois por meio de cancelamento de eco local, uma técnica
conhecida em modems V.32 e V.34. Em ambas as técnicas, o ADSL divide uma faixa
de 4 kHz da linha comum até o final da banda.

Um modem de ADSL organiza o fluxo
de dados agregado, criado por multiplexação de canais, canais duplex, e
manutenção de canais agregados em blocos, prendendo um código de correção de
erro a cada bloco. Os receptores, então, corrigem erros que acontecem durante a
transmissão até os limites indicados pelo código e extensão do bloco. A unidade
pode, por opção do usuário, criar também superblocos de dados intercalando
páginas em branco dentro dos subblocos; isto permite ao receptor corrigir
qualquer combinação de erros dentro de um pedaço específico de bits. Isto
permite a transmissão efetiva de dados e vídeo com sinais semelhantes.
O American National Standart
Institute (ANSI), trabalhando no grupo T1E1.4, aprovou recentemente um padrão
de ADSL a taxas de até 6.1 Mbps (ANSI Padrão T1.413). O European Technical
Standart Institute (ETSI) contribuiu com um anexo a T1.413 refletindo as
exigências européias. T1.413 incorpora uma única interface terminal. A Edição
II ampliará o padrão para incluir uma interface de multiplexação nos terminais,
protocolos para configuração e administração de cadeia, entre outras melhorias.
O ATM Forum e DAVIC, ambos
reconheceram o ADSL como um protocolo de transmissão de camada física para
pares trançados sem blindagem.
O ADSL Forum foi formado em
dezembro de 1994 para promover o conceito de ADSL e facilitar o desenvolvimento
de arquiteturas de sistema ADSL, protocolos, e interfaces para as principais
aplicações ADSL. O Forum tem aproximadamente 300 membros que representam os
provedores de serviço, fabricantes de equipamento, e companhias de
semicondutores de todo o mundo.
Foram testados, com êxito, modems
ADSL em mais de 100 companhias de telefone nos EUAs, operadoras de
telecomunicações, e milhares de linhas foram instaladas com tecnologias
variadas na América Norte, Europa e Ásia. Algumas companhias telefônicas
planejam diversas alternativas de mercado que usam o ADSL, principalmente
porque têm acesso a dados, mas também incluindo aplicações em vídeo compras
on-line, jogos interativos, e programação educacional.
As companhias de semicondutores
introduziram transceptores de chipsets que já estão sendo usados como
alternativa de mercado para os modems. Estes chipsets combinam os componentes
comuns, processadores digitais programáveis e costumização da ASICS. O
investimento efetuado pelas companhias de semicondutores aumentou a
funcionalidade, reduziram custos, baixou o consumo de energia, possibilitando o
desenvolvimento em massa de serviços baseados em ADSL.
Em casa:
A.
Dentro de Seu PC: O modem ADSL de seu computador
conecta a uma linha de telefone analógica padrão.
B.
Voz e Dados: Um modem ADSL tem um chip chamado
"POTS Splitter" que divide a linha telefônica existente em duas
partes: um para voz e um para dados. Voz viaja nos primeiros 4kHz de
freqüência. As freqüências mais altas (até 2MHz, dependendo das condições da
linha, densidade do arame e distância) é usado para tráfego de dados.
C.
Dividida Novamente: Outro chip no modem, chamado
"Channel Separator", divide o canal de dados em duas partes: um maior
para download e um menor para o upload de dados.

Na
A.
Pelo Fio: Na outra ponta do fio (18,000 pés de
distância no máximo) existe outro modem ADSL localizado na central da companhia
telefônica. Este modem também tem um "POTS Splitter" que separa os
chamados de voz e de dados.
B.
Chamadas de Telefone: Chamadas de voz são roteadas
para a rede de comutação de circuitos da companhia telefônica (PSTN – Public
Switched Telephone Network) e procede pelo seu caminho como de costume.
C.
Pedidos de Dados: Dados que vem de seu PC passam do
modem ADSL ao multiplexador de acesso à linha de assinante digital (DSLAM –
Digital Subscriber Line Access Multiplexer). O DSLAM une muitas linhas de ADSL
em uma única linha ATM (Asynchronous Transfer Mode) de alta velocidade que fica
conectada a Internet por linhas com velocidades acima de 1Gbps.
D.
De Volta para Você: Os dados requeridos anteriormente
retornam da Internet e são roteados de volta através do DSLAM e o modem ADSL da
central da companhia telefônica chegando novamente ao seu PC.

Na prática, um
circuito ADSL conecta um modem ADSL em cada ponta de uma linha de telefone de
par-trançado comum e cria três canais lógicos de alta velocidade para download,
um canal duplex de média velocidade (dependendo do implementação da arquitetura
de ADSL na companhia telefônica), e uma POTS (Plain Old Telephony Services ou
linha de voz comum utilizada hoje pelas companhias telefônicas). O canal de
POTS é dividido do modem digital por filtros, garantindo canal de voz
ininterruptos, até mesmo se houver falhas com o ADSL. As faixas de capacidade
do canal de alta velocidade podem ir de 256Kbps a 6.1 Mbps, enquanto a faixa de
capacidade das taxas dúplex vão de 16Kbps a 640 kbps. Cada canal pode ser
submultiplexado para formar canais de múltiplas taxas mais baixos dependendo do
sistema utilizado.
Os modems ADSL
provêem dados de acordo com os padrões norte-americanos e europeus de
hierarquias digitais e pode ser comprado com vários alcances de velocidade e
capacidades. A configuração mínima provê 256Kbps para download e um canal
duplex de 16Kbps. Outros provedores oferecem taxas de 6.1 Mbps de download e
256Kbps para upload. Produtos com taxas acima dos 8Mbps de download e 640kpbs
de upload já existem. Os modems ADSL acomodarão transporte de redes ATM com
taxas variáveis e compensação de overhead gerados nestas redes, bem como redes
baseadas nos protocolos IP.
ATM é uma tecnologia
de comunicação, ou mais especificamente de comutação rápida de pacotes -
baseada em padrões abertos (não privativos de qualquer grupo ou empresa) que se
propõe a servir de transporte comum para diversos tipos de tráfego, como dados,
voz (áudio), imagem estática e vídeo. Entre outras importantes diferenças em
relação às tecnologias de comunicação de dados existentes, deve-se notar que
ATM emerge com a possibilidade de ser algo como a tecnologia de all area
network, uma vez que pode ser utilizada tanto em redes de longa distância
(WANs), quanto em redes locais, passando pelas redes intermediárias (MANs),
diluindo limites e fazendo inclusive com que esses conceitos percam
progressivamente muito do seu sentido original.
A exemplo de outras
tecnologias tradicionais de comutação de pacotes, e a exemplo do que ocorre no
modelo das redes telefônicas, as redes ATM são orientadas à conexão. Isto
significa que um circuito virtual precisa ser estabelecido através da rede,
entre os pontos envolvidos numa comunicação antes de qualquer transferência de
dados entre esses pontos. O objetivo é permitir à rede reservar com
antecedência os recursos necessários à comunicação, buscando simplificação e
maior rapidez no processo de comutação. A tecnologia ATM garante que, numa dada
conexão, a ordem de transferência das células é preservada, de um extremo ao
outro da comunicação.
Basicamente, há dois
tipos de conexões ou circuitos virtuais ATM: os PVCs, Permanent Virtual
Círcuits (Circuitos Virtuais Permanentes), e os SVCs, Switched Virtual Circuits
(Circuitos Virtuais Comutados). As conexões do primeiro tipo são estabelecidas
através de algum tipo de mecanismo externo, normalmente a intervenção manual da
administração da rede; como o nome sugere, são conexões fixas que permanecem
inalteradas até que nova intervenção seja realizada. As conexões do segundo
tipo são estabelecidas automaticamente, por meio um protocolo de sinalização, e
não requerem intervenção manual. Nesse caso o estabelecimento de uma conexão
precede a comunicação a qual se refere e após o término dessa, a conexão é
liberada.
A utilização de
células traz algumas importantes vantagens para um ambiente em que convivem
tipos diferentes de informação. Em primeiro lugar, o emprego das entidades de
tamanho fixo torna mais fácil a previsão de retardos na rede, o que favorece os
projetos da própria rede e dos serviços que ela pode suportar. Serviços
sensíveis ao retardo, normalmente impõem fortes restrições aos máximos retardos
admissíveis entre os extremos envolvidos na comunicação. Comunicações
multimídia reforçam ainda mais essas restrições, já que impõem a necessidade de
estreita sincronização entre diversos canais de informação.
Outra vantagem da
utilização das células é a previsibilidade que introduzem no projeto do
hardware de suporte dos protocolos de comunicação. Essa previsibilidade
facilita, por exemplo, a especificação de buffers e de suas estruturas de controle
e o uso da integração em larga escala. Por fim, o emprego das células facilita
enormemente o projeto modular dos elementos comutadores, as switches. O tamanho
fixo das células favorece o paralelismo e a escalabilidade dos recursos
internos das switches, que, em consequência podem ser mais rápidas que as
convencionais. Uma desvantagem inerente ao Cell Relay, é o overhead introduzido
pela presença obrigatória do cabeçalho em cada célula.
Um conceito
importante fortemente associado às especificações da tecnologia ATM é o QoS,
Quality of Service (Qualidade de Serviço). A motivação por trás desse conceito
é a de procurar garantir ao usuário que objetivos predefinidos de desempenho da
rede possam ser alcançados, isso é particularmente importante nas redes que
suportam aplicações em tempo real. O ATM Forum define QoS como um conjunto de
parâmetros de desempenho - tais como retardo, variação de retardo, taxa de
perda de células, etc. - que pode ser negociado pelo usuário, como parte de um
Contrato de Tráfego, durante o estabelecimento de uma conexão. Para cada
direção de uma conexão ATM, o usuário pode solicitar uma classe de QoS
específica, dentre as que são oferecidas pela rede. Durante toda a duração de
uma dada conexão a rede assume o compromisso de atender a QoS associada, desde
que o usuário cumpra a sua parte no Contrato de Tráfego.
Uma Rede ATM é
composta por vários equipamentos ligados em conformidade com o padrão ATM. Os
diferentes possíveis arranjos das interconexões nessa rede, os equipamentos
necessários para permitir essas múltiplas conexões e as regras fixadas para
garantir sua correta operação impõem, todos eles, a adoção de um modelo de
estrutura para as Redes ATM. Como sempre ocorre quando se representa uma
realidade complexa através de um modelo, há um preço a pagar em troca da
vantagem obtida. No caso de modelo de arquitetura de uma Rede ATM, a vantagem é
a simplificação e o subsequente tratamento do problema propiciados por sua
divisão em módulos bem identificados. Já o preço a pagar, neste caso, é o
inevitável esforço de abstração que a distância modelo-realidade exige, além da
necessidade de familiarização com uma quantidade razoável de novos termos,
siglas e conceitos que serão apresentados neste capítulo.
A) Equipamentos
do usuário
Os TEs - Terminal
Equipments - (Equipamentos do Usuário) são a razão de ser da rede. São esses
equipamentos e seus usuários que pela necessidade de troca de informações entre
si, suscitam a existência da rede. A ligação desses equipamentos de
processamento a uma rede ATM exige adaptação, normalmente na forma de
dispositivos e programas adicionais. Exemplificando, caso uma estação de
trabalho venha a ser incorporada a uma rede ATM, esta necessitará de uma placa
adaptadora também conhecida como NIC (Network Interface Card), compatível com
as características internas da estação, à qual se liga através de conectores
adequados. Em geral, a própria placa é inserida em conectores apropriados
preexistentes na estação, constituintes do chamado barramento do sistema.
Além da placa, o TE
precisará também de um software responsável pela adequada interação do
equipamento com a rede. O software deverá permitir:
1) Controle da placa
adaptadora pelo equipamento hospedeiro;
2) A adaptação das
aplicações executadas no TE à conexão ATM, com maior ou menor grau de
transparência para o usuario;
3) A incorporação de
novas características funcionais a aplicações já utilizadas anteriormente;
4) A incorporação de
novas aplicações.
Dependendo da
solução adotada no projeto da placa adaptadora, pode haver uma parcela do
software que é executada na própria placa, contribuindo para que as funções
enumeradas sejam executadas de maneira mais eficiente.
É possível antecipar
a futura presença entre os TEs dos mais diversos tipos de dispositivos de
intercomunicação de voz, dados e imagens: telefone, videofone, fac-símile, TV
de definição normal, terminais de videoconferência, TV interativa e HDTV.
B) Switches
As Switches podem
desempenhar variadas funções na rede ATM. Como o próprio nome do dispositivo
sugere, essas funções são resultado da evolução, no mundo ATM, da idéia básica
de chaveamento. A função básica da Switch é permitir interligações de
diferentes pontos da rede e alterá-las conforme a necessidade. O objetivo é
propiciar a ligação apropriada entre quaisquer TEs na rede, concentrando ou
expandindo ligações físicas, ou ainda provendo pontos de acesso aos usuários. Para
que consiga atingir esses objetivos uma Switch ATM deve ser capaz de
desempenhar duas funções básicas:
1) Comutação Espacial
- Toda informação apresentada em uma porta de entrada será dirigida, como
resultado de uma conexão prévia, a uma porta de saída específica.
2) Comutação
Temporal - Assim como no STM, a mesma porta de entrada pode trazer informações
destinadas ora a uma, ora a outra porta de saída. No STM, o direcionamento de
um determinado conjunto de informações à sua porta de saída correta é feito com
base no intervalo de tempo que essa informação ocupa dentro de um ciclo
completo. Entretanto, a switch ATM pode praticar a comutação temporal, ou seja,
alterar a posição na escala de tempo ocupada por um determinado conjunto de
informações. Como, diferentemente do STM, não há uma relação prefixada entre
intervalos de tempo e portas de entrada ou saída, a informação apresentada em
uma determinada entrada precisa trazer explícitos dados de endereçamento que
permitam dirigi-la ao destino correto.
A comutação espacial
e a comutação temporal podem ser reunidas como técnicas distintas e
complementarepara se atingir o mesmo objetivo: direcionar as informações. 

A cada switch no
caminho entre origem e destino finais da comunicação, os dados de endereçamento
são verificados e eventualmente alterados, para adequá-los ao roteamento que a
próxima switch (comutador) no caminho da informação terá de fazer.
Existe uma questão
na colisão de informações originárias de entradas diferentes e destinadas à
mesma saída, onde a solução é atrasar uma das informações, já que não há
instante de tempo a ser estritamente obedecido para o despacho das informações.
O atraso no envio das informações implica a necessidade de capacidade de
armazenamento temporário na switch, também referida como buffering ou queuing
(enfileiramento). Tem-se assim uma nova atribuição da switch: armazenamento
temporário de células.
C) Gateways
O principal objetivo
de um gateway é interligar redes ATM e redes não-ATM. Porém esse objetivo
principal de um gateway não impede que outros objetivos, semelhantes aos que se
busca atingir com as switches, possam ser simultaneamente buscados. Isso
frequentemente ocorre, e muitas vezes, gateways incorporam funções típicas de
switches (comutação espacial e temporal, manipulação de cabeçalhos e
armazenamento temporário), ao lado da conversão de protocolos de comunicação.
A conexão de um host
a uma rede de comutação de pacotes envolve a implementação, nesta máquina, de
um protocolo de acesso à rede. O protocolo usualmente utilizado para acesso a
redes públicas é o especificado na recomendação X.25 do ITU. Nesse protocolo
são especificados os níveis correspondentes aos níveis físico, de enlace e de
rede da arquitetura RM-OSI. O nível físico descreve as características físicas,
elétricas e funcionais da conexão física e é definido pelas normas X.21 e
X.21bis. O nível de enlace descreve procedimentos derivados do HDLC (High
Level Data Link Control), denominados LAP e LAPB, para controle da linha
entre o host e um nó de comutação da rede, ou IMP. Com a finalidade de
que o nível de rede possa atender a uma larga gama de usuários, dois tipos de
serviços são definidos: o serviço de circuito virtual e o serviço de datagrama.
Dentro do modelo ISO, estas duas classes de serviço são chamadas,
respectivamente, serviço de rede orientado à conexão e serviço de
rede não orientado à conexão.
No serviço de
circuito virtual a interface da camada de rede fornece aos seus usuários um meio
de comunicação sem erros, através do qual mensagens são transportadas sem
perdas, duplicações ou alterações de ordem. A interação dos usuários com o
nível de rede apresenta três fases distintas: estabelecimento do circuito
virtual, transferência de dados e finalização. Existem duas modalidades de
circuito virtual: circuito virtual permanente (CVP) e circuito virtual comutado
(CVC). Os circuitos virtuais permanentes são um tipo especial de circuito
virtual onde a fase de conexão não é necessária, isto é, os ETDs comunicantes
são considerados permanentemente conectados. Neste caso, o canal lógico está
permanentemente no estado de transferência de dados.
No serviço de
datagrama, as mensagens (pacotes) são transportadas da fonte ao destino sem o
estabelecimento de conexões de rede e sem o armazenamento de informações de
rota dentro da rede. Cada pacote deve possuir todas as informações necessárias
para o seu roteamento, o que implica um cabeçalho mais longo. Dois pacotes de
uma mesma mensagem são tratados de forma independente pelos nós de comutação e
podem seguir rotas diferentes para atingir o mesmo destino. Isto possibilita a
ocorrência de chegada de pacotes fora de ordem e deve ser corrigida pelas
camadas superiores. Em outras palavras, a rede não garante a seqüencialização
das mensagens nem implementa mecanismos de controle de fluxo fim-a-fim. Também
fica a cargo das camadas superiores todas as tarefas de recuperação de erros.
A escolha de qual
classe de serviço deve ser utilizada depende fortemente do tipo de usuário que
deseja conectar-se à rede. A decisão está ligada não apenas a critérios
técnicos, mas também a critérios políticos e comerciais. O serviço de circuito
virtual oferece uma transferência de dados teoricamente livre de erros, o que
facilita a tarefa de implementação da camada superior (transporte). Muito
embora a implementação da camada de transporte seja mais simples, no serviço
com circuito virtual, a implementação da camada de rede é mais complexa.
A arquitetura do
protocolo X.25 é constituída de três níveis : físico, quadro e pacotes. Os
níveis de protocolo X.25 coincidem com os respectivos padrões da OSI (Open
Systems Interconnection) da ISO (International Standards Organizations ).
Pelo fato de ser
bastante elaborado, oprotocolo X.25 implica recursos normalmente não
disponíveis em equipamentos de dados mais simples e de baixo custo, como é o
caso dos terminais assíncronos.
Para permitir o
acesso desses terminais,as redes comutadas de pacotes possuem interface PAD
(Packed Assembler/Diassembler), cuja função principal é exatamente o
empacotamento e o desempacotamento de dados, ou seja, o PAD recebe os caracters
originadod por um terminal START/STOP e forma pacotes para transmissão através
de rede, executando a operação inversa no sentido rede/terminal. Dessa forma
pode-se dizer que o PAD atua como um conversor de protocolo.
As especificações
para acesso à rede comutada de pacotes, via interfaces PAD, constam das
recomendações X.9, X.28 e X.29 do CCITT.
O PAD pode ser visto
pela rede como um terminal X.25 . No entanto, isto não obriga que o PAD seja um
equipamento à parte do nó de comutação da rede, ou seja, esta função pode estar
residente no mesmo hardware que o resto das funções do nó.
Esta recomendação do
CCITT define os aspectos funcionais e os procedimentos de interface
terminal/modem, permitindo permitindo o acesso de um terminal modo pacote (que
opera com X.25) a uma rede de pacotes, através de uma rede comutada por
circuitos. No caso do Brasil essa recomendação atenderá a interligação de
terminais , trabalhando com protocolo X,25, acessando à Renpac via rede
telefônica (acesso comutado).
Três serviços
poderão ser suportados pela recomendação X.32: serviço não identificado, onde o
usuário não será vínculo comercial com a empresa mantenedora da rede de pacotes
( no Brasil, a empresa é a Embratel com a Renpac); serviço identificado, onde o
usuário terá vinculo comercial com a empresa mantenedora da rede de pacotes;
serviço personalizado, que atenderá o usuário com vínculo comercial e com
características de serviços compatíveis com as suas necessidades, tais como
identidade do ETD, método de identificação do ETD, endereço do ETD e registro,
designação de canais lógicos , facilidade opcionais (locação temporária,
rediscagem de segurança).
As redes e os
equipamentos de computação dos dias de hoje têm um potencial para trabalhar a
velocidades muito mais altas e transferir dados em grande quantidade. Com a
diversidade e a complexidade dessas redes, o gerenciamento pode se tornar uma
tarefa gigante se você não tiver as ferramentas adequadas. Os diversos
ambientes têm sua configuração particular de equipamentos de diferentes
fabricantes.
Rede Frame Relay
Tipica:

O Frame Relay, um
método de comunicação de rede relativamente novo, tem ganhado popularidade
ultimamente. Assim como o X.25, o FR usa uma tecnologia de comutação de
pacotes, porém, de modo mais eficiente. Como resultado, sua rede poderá ficar
mais rápida, simples e mais barata de manter. O Frame Relay foi desenvolvido
para resolver problemas de comunicação que outros protocolos não conseguiam: a
necessidade cada vez maior por velocidades mais altas, eficiência em altas
larguras de banda, particularmente para surtos de tráfego, aumento da
inteligência dos dispositivos de rede para a redução do processamento dos
protocolos e a necessidade de contar LANs e WANs.
Assim como no X.25,
o Frame Relay é um protocolo de comutação de pacotes. Só que o Frame Relay é
uma versão mais enxuta. Há diferenças significativas que fazem do Frame Relay
uma rede mais rápida e mais eficiente. Uma rede Frame Relay não realiza
detecção de erros, o que resulta em um processamento significativamente menor
que o X.25. O Frame Relay também é independente de protocolo (ele aceita dados
de diferentes protocolos). Os dados são encapsulados pelo equipamento Frame
Relay, não pela rede.
Os dispositivos
inteligentes conectados em uma rede Frame Relay são responsáveis pela correção
de erros e pelo formato do frame. O tempo de processamento é minimizado para
que a transmissão dos dados seja muito mais rápida e eficiente.
Além disso, o Frame
Relay é totalmente digital, o que reduz a chance de erros e oferece taxas de
transmissão excelentes. O Frame Relay opera tipicamente de 64 até 2048 Mbps.
O Frame Relay envia
as informações em pacotes, também conhecidos como frames, através da rede. Cada
frame contém todas as informações necessárias para encaminhá-lo para o destino
certo.
Desse modo, cada
ponto pode se comunicar com muitos destinos diferentes usando uma única linha
de acesso à rede. E, ao invés de se atribuir uma largura de banda fixa, o
serviço Frame Relay oferece CIR (Committed Information Rate), que é uma
garantia de que os dados terão uma determinada largura de banda garantida se a
transmissão exigir. Dependendo dos parâmetros, os dados podem até exceder essa
largura de banda garantida.
Como o processamento
dos pacotes no Frame Relay é rápido, ele é ideal para as redes complexas de
hoje. Você ganha vários benefícios: em primeiro lugar, são as múltiplas
conexões lógicas que podem ser transmitidas em uma única conexão física,
reduzindo os custos de comunicação. Pela redução da quantidade de processamento
necessária, você consegue maior desempenho e tempo de resposta. E como o Frame
Relay usa um protocolo de rede simples, seu equipamento só vai precisar de
pequenas modificações de software ou hardware. Assim, você não vai precisar investir
muito dinheiro para atualizar seu sistema. Uma aplicação que tem usada com o
Frame Relay é o VOFR, ou voz sobre Frame Relay.
Como o Frame Relay é
independente de protocolo, ele pode processar tráfego a partir de protocolos
como IP, IPX™ e SNA.
O Frame Relay é a
escolha ideal para a conexão de WANs (Redes de Área Extensa), as quais têm alto
volume de tráfego em surtos imprevisíveis. Essas aplicações, tipicamente
incluem transferência de dados, CAD/CAM e aplicações cliente-servidor.
O Frame Relay também
oferece vantagens para interconxão de WANs. No passado, a instalação de WANs
requeria o uso linhas privativas (LPs) ou comutação de circuitos baseados em
linhas privativas. No Frame Relay, não é necessário instalar linhas privativas
dedicadas para se fazer uma conexão WAN-WAN, reduzindo assim os custos.
Como o Frame Relay
não faz conversão de protocolos nem detecção/correção de erros, os dispositivos
do usuário final precisam ser inteligentes. Alguns dos equipamentos Frame Relay
são os FRADs (Frame Relay Assembler/Disassembler), roteadores, bridges e
switches de frame.
Roteadores de frame.
Os roteadores de
Frame traduzem os protocolos de comunicações de dados existentes, para
transmiti-los na rede Frame Relay, depois roteiam os dados através da rede para
outro roteador de frames ou outro dispositivo compatível. Os roteadores de
Frame podem lidar com muitos tipos de protocolos incluindo os protocolos de
rede. Eles são usados em ambientes que necessitam de velocidades de acesso E1
(2 Mbps) ou menor. Os roteadores suportam várias interfaces físicas de dados e
podem proporcionar muitas portas de usuários.
Bridges, roteadores
e FRADs.
Bridges, roteadores
ou FRADs (Dispositivos de acesso Frame-Realy) agregam e convertem dados em
pacotes Frame Relay.
As bridges são
fáceis de configurar e manter e normalmente conectam uma filial a uma
localidade central.
Os roteadores podem
tratar do tráfego de outros protocolos de WAN, re-rotear uma conexão se a linha
cair, ou proporcionar suporte para controle de fluxo e controle de
congestionamento.
Os FRADs formatam os
dados para a rede Frame Relay, alguns até mesmo funcionam como roteadores. Eles
trabalham bem em aplicações onde já existam roteadores e bridges ou quando se
estiver enviando dados de mainframe.
O MPLS é um esquema
de encaminhamento de pacotes que atua entre as camadas 2 (camada de Enlace) e 3
(camada de Rede) do modelo de referência OSI (RM-OSI).
O esquema de Label
Switching é uma funcionalidade que habilita roteadores localizados nas
bordas de uma rede a aplicarem simples rótulos aos pacotes, permitindo aos
dispositivos no núcleo da rede, chavearem os pacotes de acordo com esses
rótulos, de forma a se ter uma atividade mínima na leitura/escrita das tabelas
de roteamento. Essa funcionalidade pode ser encontrada tanto em switches
(ATM por exemplo) como em roteadores.
O MPLS utiliza um
protocolo, o LSP (Label Switched Path), para distribuir rótulos e
estabelecer um caminho fim-a-fim dentro de um determinado domínio. Um LSP opera
de forma similar a um circuito virtual numa rede ATM; estabelece um caminho
unidirecional do emissor ao receptor.
A escolha do caminho
(rota) pode ser estabelecida usando o protocolo de roteamento nó a nó ou
utilizando uma ER (Explicit Route).
Resumindo, o MPLS é
um mecanismo atraente a ser aplicado em redes IP, pois desempenha uma rápida
classificação e encaminhamento de pacotes e atua como um eficiente mecanismo de
tunelamento.
Dessa forma,
principalmente pela segunda característica citada, o MPLS se apresenta como uma
importante ferramenta a ser utilizada na Engenharia de Tráfego.
Um esquema do
emprego de MPLS com Serviços Diferenciados com Encaminhamento Expresso com SLA
dinâmico, é mostrado na figura 3.
|
|
A principal tarefa é
determinar o melhor caminho de conectividade para se chegar ao destino, baseado
em tabelas de roteamento criadas a partir de rotas estáticas ou dinâmicas.
Também faz controle de tráfego e congestionamento, conversão de protocolos, estatísticas de
utilização, etc.
A função desta
camada é obter os dados da camada de sessão, quebrá-los em partes menores, se
necessário, passá-los para a camada de rede e garantir que as partes cheguem na
ordem correta no host receptor. Esta camada isola as camadas superiores das
mudanças inevitáveis no hardware podendo criar uma conexão distinta na camada
de rede para cada conexão requisitada pela camada de sessão.
No caso de uma
requisição para conexão de grande desempenho, a camada de transporte pode criar
múltiplas conectivas na camada de rede.
Outras
características dessa camada é a multiplexação, difusão de mensagens
(broadcast) para múltiplos destinatários.
A camada de transporte é a primeira camada fim-a-fim,
ou seja, um programa na máquina fonte conversa diretamente com um programa na
máquina destino. Nas camadas inferiores, os protocolos são entre cada máquina e
seu host vizinho imediato.
Muitos hosts permitem multiprogramação, o que
implica que múltiplas conexões podem estar entrando e saindo de cada host. O cabeçalho do quadro de
transporte diz qual mensagem pertence a qual conexão.
A camada de sessão
permite usuários em máquinas diferentes estabelecerem sessões (por exemplo,
login, transferência de arquivos) entre elas. Um serviço oferecido por esta
camada é o controle de diálogo.
Para alguns
protocolos, é essencial que ambos os lados não tentem a mesma operação ao mesmo
tempo. Um sistema de tokens pode ser
gerenciado pela camada de sessão. Numa transferência, o problema de
sincronização deve ser elaborado.
Trata da sintaxe e
semântica da informação transmitida. Por exemplo, trata da codificação dos
dados numa forma padrão. Faz também compressão de dados e criptografia para
garantir privacidade.
Contém uma variedade
de protocolos que são comumente necessários: tipos de terminais; tipos de
convenções de nomes em transferência de arquivos; correio eletrônico, etc..
Cada serviço possui
um SAP (Service Address Point), os quais identificam univocamente aquele
serviço específico.
Os serviços podem
ser orientados à conexão, como no sistema telefônico, ou não orientado à
conexão, como no sistema postal.
Os serviços podem
ter característica de garantia de entrega ou não. Com isso, a seguinte matriz
de conectividade versus Garantia de entrega indica alguns exemplos:
Orientado à conexão
+ Garantia de Entrega ↔ Transferência de arquivos
Orientado à conexão
+ Sem Garantia de Entrega ↔ Voz
Não Orientado à
conexão + Garantia de Entrega ↔ Carta Registrada
Não Orientado à
conexão + Sem Garantia de Entrega ↔ Carta Comum
Um serviço
utiliza-se de uma série de primitivas (operações), as quais possuem parâmetros
específicos e individuais.
A primitivas do
modelo OSI para o estabelecimento de uma sessão são:
CONNECT REQUEST: Uma entidade quer o serviço
para executar alguma tarefa.
CONNECT INDICATION: Uma entidade deve ser informada sobre o
evento.
CONNECT RESPONSE: Uma entidade que responde a um evento.
CONNECT CONFIRM: Uma entidade deve ser
informada sobre um pedido.

O seguinte exemplo
faz uma analogia de uma ligação telefônica para convidar alguém para jantar com
o modelo OSI:
CONNECT.REQUEST Você disca um número
CONNECT.INDICATION O telefone toca
CONNECT.RESPONSE Alguém atende
CONNECT.CONFIRM Você percebe que o telefone parou de
tocar
DATA.REQUEST Você faz o convite
DATA.INDICATION Ela ouve o
convite
DATA.REQUEST Ela diz que gostou
muito
DATA.INDICATION Você ouve ela aceitando
DISCONNECT.REQUEST Você desliga
DISCONNECT.INDICATION Ela ouve e desliga

A Internet é uma
rede pública de comunicação de dados, com controle descentralizado e que
utiliza o conjunto de protocolos TCP/IP como base para a estrutura de
comunicação e seus serviços de rede. Isto se deve ao fato de que a arquitetura
TCP/IP fornece não somente os protocolos que habilitam a comunicação de dados
entre redes, mas também define uma série de aplicações que contribuem para a
eficiência e sucesso da arquitetura. Entre os serviços mais conhecidos da
Internet estão o correio eletrônico (protocolos SMTP, POP3), a transferência de
arquivos (FTP), o compartilhamento de arquivos (NFS), a emulação remota de
terminal (Telnet), o acesso à informação hipermídia (HTTP), conhecido como WWW
(World Wide Web).
A Internet é dita
ser um sistema aberto uma vez que todos os seus serviços básicos assim como as
aplicações são definidas publicamente, podendo ser implementadas e utilizadas
sem pagamento de royalties ou licenças para outras instituições.
O conjunto de
protocolos TCP/IP foi projetado especialmente para ser o protocolo utilizado na
Internet. Sua característica principal é o suporte direto a comunicação entre
redes de diversos tipos. Neste caso, a arquitetura TCP/IP é independente da
infra-estrutura de rede física ou lógica empregada. De fato, qualquer
tecnologia de rede pode ser empregada como meio de transporte dos protocolos
TCP/IP, como será visto adiante.
Alguns termos
utilizados freqüentemente, são explicados de forma resumida adiante:
A Internet (nome
próprio) é a denominação da rede mundial que interliga redes no mundo. É
formada pela conexão complexa entre centenas de milhares de redes entre si. A
Internet tem suas políticas controladas pelo IAB (Internet Architecture Board),
um fórum patrocinado pela Internet Society, uma comunidade aberta formada por
usuários, fabricantes, representantes governamentais e pesquisadores.
Um internet é um
termo usado para definir uma rede genérica formada pela interligação de redes
utilizando o protocolo TCP/IP, porém é mais usual referirmos como rede tcp/ip.
Uma intranet é a
aplicação da tecnologia criada na Internet e do conjunto de protocolos de
transporte e de aplicação TCP/IP em uma rede privada, interna a uma empresa.
Numa intranet, não somente a infra-estrutura de comunicação é baseada em
TCP/IP, mas também grande quantidade de informações e aplicações são
disponibilizadas por meio dos sistemas Web (protocolo HTTP) e correio
eletrônico.
Uma extranet, ou
extended intranet é a extensão dos
serviços da intranet de uma empresa para interligar e fornecer aplicações para
outras empresas, como clientes, fornecedores, parceiros, etc… Desta forma a
extranet é a utilização de tecnologia como Web e correio eletrônico para
simplificar a comunicação e a troca de informações entre empresas.
World Wide Web é a
designação do conjunto de informações públicas disponibilizadas na Internet por
meio do protocolo HTTP. É o somatório das informações que podem ser acessadas
por um browser Web na Internet. As informações internas de uma empresa que são
acessíveis via um browser Web são enquadradas no termo intranet.
Em 1966, o
Departamento de Defesa do governo americano iniciou, através de sua agência
DARPA (Defense Advanced Research Projects Agency) projetos para a interligação
de computadores em centros militares e de pesquisa, com o objetivo de criar um
sistema de comunicação e controle distribuído com fins militares. Esta
iniciativa teve como um dos motivadores o surgimento de minicomputadores com
grande poder de processamento, que poderiam ter seu emprego enriquecido com o
acesso a uma grande rede de comunicação. Esta rede recebeu o nome de ARPANET. O
principal objetivo teórico da ARPANET era formar uma arquitetura de rede sólida
e robusta que pudesse sobreviver a uma perda substancial de equipamento e ainda
operar com os computadores e enlaces de comunicação restantes. Para alcançar
este objetivo, o sistema de comunicação deveria suportar diversos tipos de
equipamentos distintos, ser dividido em diversos níveis de protocolos distintos
para permitir a evolução independente de cada um deles e ser baseado em
transferência de pacotes de
informação.
Durante a década de
70 até 1983, a ARPANET era baseada em IMPs (Interface Message Processor),
rodando diversos protocolos, sendo o principal o NCP (Network Control
Protocol). O TCP/IP ainda estava sendo projetado e a Internet era formada por
máquinas de grande porte e minicomputadores ligados aos IMPs. O roteamento fora
dos IMPS não existia, impedindo a conexão de máquinas em rede local que surgiam.
Ou seja, para se ligar à ARPANET era necessária a ligação direta a um IMP.
Nesta época, os
computadores com potencial para se ligar na rede eram de grande porte e em
número reduzido. As diferenças de porte desta rede imaginada na época e o que
se observa hoje é gigantesco. Um dos projetistas dos sistemas de comunicação da
ARPANET, referindo-se ao tamanho de um byte para os identificadores das
máquinas, afirmou que “256 máquinas é essencialmente infinito”.
No começo de 1980, a
ARPANET foi dividida em ARPANET e MILNET, separando a porção acadêmica e
militar. Nesta época, a ARPA decidiu adotar o Unix como sistema operacional
prioritário para o suporte de seus projetos de pesquisa (dos quais a ARPANET
era um deles), escolhendo a Universidade da Califórnia - Berkeley com centro de
desenvolvimento. A ARPA incentivou a criação nativa do suporte de TCP/IP no
Unix.
O protocolo TCP/IP
começou a ser projetado em 1977 com o objetivo de ser o único protocolo de
comunicação da ARPANET. Em 1/1/1983, todas as máquinas da ARPANET passaram a
utilizar o TCP/IP como protocolo de comunicação. Isto permitiu o crescimento
ordenado da rede, eliminando as restrições dos protocolos anteriores. Em 1986,
a NSF (Network Science Foundation) passou a operar o backbone (espinha dorsal)
de comunicações com o nome de NSFNet e iniciou a formação de redes regionais
interligando os institutos acadêmicos e de pesquisa. Desde 1983 começaram a surgir diversas redes
paralelas nos Estados Unidos financiadas por órgãos de fomento a pesquisa como
a CSNET (Computer Science Net), HEPNet (High Energy Physics Net) , SPAN (Nasa
Space Physics Network) e outras. Estas redes foram integradas ao NSFNet e
adicionadas a redes de outros países, caracterizando o início de uso do termo
Internet em 1988.
Em 1993, foram
criados os protocolos HTTP e o browser Mosaic, dando início ao World Wide Web
(WWW). O World Wide Web foi o grande responsável pela crescimento exponencial
da Internet, pois permitiu o acesso a informações com conteúdo rico em gráficos
e imagens e de forma estruturada. O WWW foi também o grande motivador do uso
comercial da Internet, permitindo às empresas disponibilizar informações e
vender produtos via Internet.
A NSFNet foi
privatizada em 1995, e o backbone passou a ser distribuído e complexo, formado
por múltiplas redes de prestadoras de serviços de telecomunicações como
AT&T, MCI, Sprint e outros. Hoje a Internet não é mais formada por um único
backbone central, mas por um conjunto de grandes provedores de acesso. Em 1995
foi permitido também o tráfego de informações comerciais na Internet.
No Brasil, o acesso
à Internet foi iniciado com a conexão de instituições acadêmicas como a Fapesp,
USP, Unicamp, PUC, UFRJ e outras em 1989. Foram formados dois backbones
regionais, a RedeRio e a ANSP (An Academic Network at São Paulo) interligando
as principais instituições destes estados. Posteriormente foi criada a RNP
(Rede Nacional de Pesquisa) com o objetivo de formar um backbone nacional de
acesso à Internet e de estimular a formação de redes regionais como a Rede
Minas, Rede Tchê e outras. Em 1995, foi liberado o tráfego comercial, com a
Embratel montando e operando o backbone comercial no Brasil. O fornecimento de
serviços IP não foi considerado monopólio da Telebrás, permitindo o surgimento
de provedores de backbone e de acesso à Internet.
Hoje o backbone da
Internet no Brasil é formado por diversos backbones nacionais interligados
entre si, como a Impsat, a RNP, Embratel, IBM, Unisys, IFX, GlobalOne entre
outros. O Comitê Gestor da Internet Brasil é o responsável pela determinação de
regras, políticas e aprovação de fornecimento de endereços IP (CIDR) para redes
autônomas para a porção brasileira da Internet cuja função foi delegada à
Fapesp que também é responsável pelo registro de nomes de domínio .br.
A ARIN (American
Registry Internet Numbers) fornece os números das redes autônomas para todo o
continente americano (rede autônoma se constitui quando há a necessidade de
multihoming, ou seja, uma rede conectada a mais de um provedor de backbone, por
ex.: Global One).
TCP/IP é um acrônimo
para o termo Transmission Control Protocol/Internet Protocol Suite, ou seja é
um conjunto de protocolos, onde dois dos mais importantes (o IP e o TCP) deram
seus nomes à arquitetura. O protocolo IP, base da estrutura de comunicação da
Internet é um protocolo baseado no paradigma de comutação de pacotes
(packet-switching).
Os protocolos TCP/IP
podem ser utilizados sobre qualquer estrutura de rede, seja ela simples como
uma ligação ponto-a-ponto ou uma rede de pacotes complexa. Como exemplo,
pode-se empregar estruturas de rede como
Ethernet, Token-Ring, FDDI, PPP, ATM, X.25, Frame-Relay, barramentos SCSI,
enlaces de satélite, ligações telefônicas discadas e várias outras como meio de
comunicação do protocolo TCP/IP.
A arquitetura
TCP/IP, assim como OSI realiza a divisão de funções do sistema de comunicação
em estruturas de camadas. Em TCP/IP as camadas são:
Aplicação
Transporte
Inter-Rede
Rede
A figura 1 ilustra a
divisão em camadas da arquitetura TCP/IP:

A camada de rede é
responsável pelo envio de datagramas construídos pela camada Inter-Rede. Esta
camada realiza também o mapeamento entre um endereço de identificação de nível
Inter-rede para um endereço físico ou lógico do nível de Rede. A camada
Inter-Rede é independente do nível de Rede.
Alguns protocolos
existentes nesta camada são:
Protocolos com
estrutura de rede própria (X.25, Frame-Relay, ATM)
Protocolos de Enlace OSI (PPP, Ethernet,
Token-Ring, FDDI, HDLC, SLIP, …)
Protocolos de Nível
Físico (V.24, X.21)
Protocolos de
barramento de alta velocidade (SCSI, HIPPI, …)
Protocolos de
mapeamento de endereços (ARP - Address Resolution Protocol) - Este protocolo
pode ser considerado também como parte da camada Inter-Rede.
Os protocolos deste
nível possuem um esquema de identificação das máquinas interligadas por este
protocolo. Por exemplo, cada máquina situada em uma rede Ethernet, Token-Ring
ou FDDI possui um identificador único chamado endereço MAC ou endereço físico
que permite distinguir uma máquina de outra, possibilitando o envio de
mensagens específicas para cada uma delas. Tais rede são chamadas redes locais
de computadores.
Da mesma forma,
estações em redes X.25, Frame-Relay ou ATM também possuem endereços que as
distinguem uma das outras.
As redes
ponto-a-ponto, formadas pela interligação entre duas máquinas não possuem,
geralmente, um endereçamento de nível de rede (modelo TCP/IP), uma vez que não
há necessidade de identificar várias estações.
Esta camada realiza
a comunicação entre máquinas vizinhas através do protocolo IP. Para identificar
cada máquina e a própria rede onde estas estão situadas, é definido um
identificador, chamado endereço IP, que é independente de outras formas de
endereçamento que possam existir nos níveis inferiores. No caso de existir
endereçamento nos níveis inferiores é realizado um mapeamento para possibilitar
a conversão de um endereço IP em um endereço deste nível.
Os protocolos
existentes nesta camada são:
Protocolo de transporte
de dados: IP - Internet Protocol
Protocolo de
controle e erro: ICMP - Internet Control Message Protocol
Protocolo de
controle de grupo de endereços: IGMP - Internet Group Management Protocol
Protocolos de
controle de informações de roteamento
O protocolo IP
realiza a função mais importante desta camada que é a própria comunicação
inter-redes. Para isto ele realiza a função de roteamento que consiste no transporte de mensagens entre redes e na
decisão de qual rota uma mensagem deve seguir através da estrutura de rede para
chegar ao destino.
O protocolo IP
utiliza a própria estrutura de rede dos níveis inferiores para entregar uma
mensagem destinada a uma máquina que está situada na mesma rede que a máquina
origem. Por outro lado, para enviar mensagem para máquinas situadas em redes
distintas, ele utiliza a função de roteamento IP. Isto ocorre através do envio
da mensagem para uma máquina que executa a função de roteador. Esta, por sua
vez, repassa a mensagem para o destino ou a repassa para outros roteadores até
chegar no destino.

Esta camada reúne os
protocolos que realizam as funções de transporte de dados fim-a-fim, ou seja,
considerando apenas a origem e o destino da comunicação, sem se preocupar com
os elementos intermediários. A camada de
transporte possui dois protocolos que são o UDP (User Datagram Protocol) e TCP
(Transmission Control Protocol).
O protocolo UDP
realiza apenas a multiplexação para que várias aplicações possam acessar o
sistema de comunicação de forma coerente.
O protocolo TCP
realiza, além da multiplexação, uma série de funções para tornar a comunicação
entre origem e destino mais confiável. São responsabilidades do protocolo TCP:
o controle de fluxo, o controle de erro, a sequenciação e a multiplexação de
mensagens.
A camada de
transporte oferece para o nível de aplicação um conjunto de funções e
procedimentos para acesso ao sistema de comunicação de modo a permitir a
criação e a utilização de aplicações de forma independente da implementação.
Desta forma, as interfaces socket ou TLI (ambiente Unix) e Winsock (ambiente
Windows) fornecem um conjunto de funções padrão para permitir que as aplicações
possam ser desenvolvidas independentemente do sistema operacional no qual
rodarão.
A camada de
aplicação reúne os protocolos que fornecem serviços de comunicação ao sistema
ou ao usuário. Pode-se separar os protocolos de aplicação em protocolos de
serviços básicos ou protocolos de serviços para o usuário:
Protocolos de
serviços básicos, que fornecem serviços para atender as próprias necessidades
do sistema de comunicação TCP/IP: DNS, BOOTP, DHCP.
Protocolos de
serviços para o usuário: FTP, HTTP, Telnet, SMTP, POP3, IMAP, TFTP, NFS, NIS,
LPR, LPD, ICQ, RealAudio, Gopher, Archie, Finger, SNMP e outros
A arquitetura TCP/IP
possui uma série de diferenças em relação à arquitetura OSI. Elas se resumem
principalmente nos níveis de aplicação e Inter-rede da arquitetura TCP/IP,
principais diferenças pode-se citar:
·
OSI trata todos os níveis, enquanto TCP/IP só trata a partir do nível de
Rede OSI
·
OSI tem opções de modelos incompatíveis. TCP/IP é sempre compatível entre as várias implementações
·
OSI oferece serviços orientados a conexão no nível de rede, o que
necessita de inteligência adicional em cada equipamento componente da estrutura
de rede. Em TCP/IP a função de roteamento é bem simples e não necessita de
manutenção de informações complexas
·
TCP/IP tem função mínima (roteamento IP) nos nós intermediários
(roteadores)
Aplicações TCP/IP
tratam os níveis superiores de forma monolítica, Desta forma OSI é mais
eficiente pois permite re-aproveitar funções comuns a diversos tipos de
aplicações. Em TCP/IP, cada aplicação tem que implementar suas necessidades de
forma completa.
Note que a camada
inter-rede TCP/IP apresenta uma altura menor que o correspondente nível de Rede
OSI. Isto representa o fato de que uma das funções do nível de Rede OSI é
realizada pelo nível de Rede TCP/IP. Esta função é a entrega local de mensagens
dentro da mesma rede. O IP só trata a entrega e a decisão de roteamento quando
o origem e o destino da mensagem estão situados em redes distintas.


A Internet é
controlada pelo IAB (Internet Architecture Board) em termos de padronizações e
recomendações. Este gerencia as funções de definição de padrões de protocolos,
criação de novos protocolos, evolução, etc.. O IAB é um fórum suportado pela
Internet Society (ISOC), cujos membros organizam as reuniões e o funcionamento
do IAB, além de votarem os seus representantes.
O controle da
Internet em relação a sua operação normal é dividida em diversos órgãos, alguns
centrais e outros por países. Por exemplo, o órgão que gerencia toda a política
de fornecimento de endereços IP e outros códigos utilizados nos protocolos é o
IANA - Internet Assigned Numbers Authority. Por sua vez, a distribuição de
endereços IP é realizada pela ARIN, por outro lado nomes de domínio (DNS),
assim como a manutenção da documentação de padronização da Internet é realizada
pelo InterNIC (Internet Network Information Center) que atualmente é operado
por um conjunto de empresas, principalmente Network Solutions Inc. Outro órgão
relevante é o GTLD-Mou, um comitê criado em 1997 para decidir sobre a padronização
de novos nomes básicos da Internet (como .com, .org, .gov, .arts, .web e
outros).
A figura 4 ilustra o
diagrama da IAB. Este consiste de um órgão executivo, o IETF (Internet
Engineering Task Force), que é responsável pela definição e padronização de protocolos
utilizados na Internet. O IRTF (Internet Research Task Force) é responsável por
criar, projetar e propor novas aplicações, em nome do IAB. Além das
contribuições iniciadas pelo IRTF, qualquer instituição ou pessoa pode submeter
propostas de novos protocolos ou aplicações ao IRTF.

O processo de
padronização é baseado em um documento chamado RFC (Request for Comments) que
contém a definição ou proposição de algum elemento (prática, protocolo,
sistema, evolução, aplicação, histórico, etc…) para a Internet. Quando uma nova
proposta é submetida ela recebe o nome de Draft Proposal. Esta proposta será
analisada pelo Working Group especializado na área que se refere e se aprovada
por votação, recebe um número e se torna uma RFC. Cada RFC passa por fases,
onde recebe classificações como Proposed Standard, Draft Standard, até chegar a
um Internet Standard. Um protocolo não precisa se tornar um Internet Standard
para ser empregado na Internet. De fato são poucos os que tem esta
classificação.
As RFCs podem ter os
seguintes status:
S = Internet Standard
PS = Proposed Standard
DS = Draft Standard
BCP = Best Current Practices
E = Experimental
I = Informational
H = Historic
Hoje existem
aproximadamente mais de 2500 RFCs publicadas. Cerca de 500 reúnem as informações
mais importantes para implementação e operação da Internet
Abaixo enumera-se
algumas RFCs importantes e a classificação por STANDARD. O STANDARD é o
agrupamento das RFC que se referem a um determinado padrão:
|
Classif. |
STD |
RFC |
Descrição |
|
Padrões |
STD-1 |
2200 |
INTERNET OFFICIAL
PROTOCOL STANDARDS |
|
|
STD-2 |
1700 |
ASSIGNED NUMBERS |
|
|
STD-3 |
1122 |
Requirements for Internet hosts -
communications layers |
|
|
STD-3 |
1123 |
Requirements for Internet hosts -
application and support |
|
|
STD-4 |
1009 |
Requirements for
Internet Gateways |
|
|
|
1812 |
Requirements for
IP Routers |
|
|
|
1918 |
Address Allocation for Private
Internets |
|
Internet |
|
2135 |
Internet Society
By-Laws |
|
|
|
2134 |
Articles of Incorporation of Internet
Society |
|
|
|
2008 |
Implication of Various Address
Allocation Policies for Internet Routing |
|
|
|
2026 |
The Internet Standards Process - Rev.3 |
|
|
|
2050 |
The Internet Registry IP Allocation
Guidelines |
|
IP |
STD-5 |
791 |
IP - Internet
Protocol |
|
|
STD-5 |
792 |
ICMP - Internet
Control Message Protocol |
|
|
STD-5 |
919 |
Broadcasting
Internet Datagrams |
|
|
STD-5 |
922 |
Broadcasting Internet datagrams in the
presence of subnets |
|
|
STD-5 |
950 |
Internet standard
subnetting procedure |
|
|
STD-5 |
1112 |
Host extensions for IP multicasting -
IGMP |
|
|
|
2101 |
IPv4 address
Behaviour Today |
|
|
|
1256 |
ICMP Router
Discovery Protocol |
|
|
|
2236 |
Internet Group Management Protocol, v.2 |
|
|
|
1788 |
ICMP Domain Name
Messages |
|
|
|
1191 |
Path MTU Discovery
Protocol |
|
UDP |
STD-6 |
768 |
User Datagram
Protocol - UDP |
|
TCP |
STD-7 |
793 |
Transmission
Control Protocol |
|
|
|
1144 |
Compressing TCP headers for low speed
serial links |
|
|
|
1323 |
TCP Extensions for High Performance |
|
Telnet |
STD-8 |
854 |
Telnet Protocol
specification |
|
|
STD-8 |
855 |
Telnet Option
Specification |
|
FTP |
STD-9 |
959 |
File Transfer
Protocol - FTP |
|
SMTP |
STD-10 |
821 |
Simple Mail
Transfer Protocol - SMTP |
|
|
STD-10 |
1869 |
SMTP Service
Extensions |
|
|
STD-10 |
1870 |
SMTP Service Extension for Message Size
Declaration |
|
|
|
1652 |
SMTP Service Extensions for 8-bit MIME
transport |
|
|
|
1891 |
SMTP Service Extensions for Delivery
Status Notification |
|
|
|
2142 |
Mailbox Names for Common Services,
Roles and Functions |
|
Mail-Content |
STD-11 |
822 |
Standard Format for ARPANET Messages |
|
|
STD-11 |
1049 |
Content-type header field for Internet
messages |
|
NTP |
STD-12 |
1119 |
Network Time Protocol v.2 - NTP |
|
DNS |
STD-13 |
1034 |
Domain names - concepts and facilities |
|
|
STD-13 |
1035 |
Domain names - implementation and
specification |
|
|
STD-14 |
974 |
Mail Routing and the Domain Name System |
|
|
STD-15 |
1137 |
A Simple Network Management Protocol -
SNMP |
|
|
|
1034, 1035 |
Domain Names, concepts, facilities,
implementation and specification |
|
|
|
2100 |
The Naming of
Hosts |
|
|
|
2136 |
Dynamic Updates in the Domain Name
System |
|
|
|
2181 |
Clarifications to
DNS Specification |
|
|
|
2182 |
Selection and Operation of Secondary
DNS Servers |
|
SNMP-MIB |
STD-16 |
1155 |
Structure and Identification of
Management Information for TCP/IP-based Internets |
|
|
STD-16 |
1212 |
Concise MIB
Definitions |
|
|
STD-17 |
1213 |
Management Information Base for Network
Management of TCP/IP-based internets - MIB II |
|
Netbios/IP |
STD-19 |
1001 |
Protocol standard for a NetBIOS service
on a TCP/UDP transport: Concepts and Methods |
|
|
STD-19 |
1002 |
Protocol standard for a NetBIOS service
on a TCP/UDP transport: Detailed specifications |
|
TFTP |
STD-33 |
1350 |
Trivial FTP
Protocol Rev.2 |
|
IP-SLIP |
STD-47 |
1055 |
IP datagrams over serial lines: SLIP |
|
PPP |
STD-51 |
1661 |
Point-to-Point Protocol - PPP |
|
|
|
1662 |
PPP in HDLC like Framing |
|
|
|
1332 |
IPCP - PPP IP
Control Protocol |
|
|
|
1570 |
PPP LCP Extensions |
|
|
|
1662 |
PPP in HDLC
Framing |
|
|
|
2153 |
PPP Vendor
Extensions |
|
POP3 |
STD-53 |
1939 |
Post Office Protocol v.3 - POP3 |
|
RIP |
|
1722, 1723 |
RIP - Routing Information Protocol version
2 |
|
OSPF |
STD-54 |
2328 |
Open Shortest Path Protocol - OSPF v.3 |
|
|
|
2154 |
OSPF with Digital
Signatures |
|
ARP |
|
866 |
ARP - Address
Resolution Protocol |
|
|
|
903 |
RARP - Reverse Address Resolution
Protocol |
|
|
|
1027 |
Proxy ARP |
|
ATM |
|
1483 |
Multiprotocol
Encapsulation Over ATM |
|
|
|
1577 |
Classic IP over
ATM |
|
BOOTP |
|
951 |
BOOTP - Bootstrap
Protocol |
|
|
|
1497 |
BOOTP Vendor
Extensions |
|
|
|
1533 |
DHCP Options and BOOTP Vendor
Extensions |
|
BGP |
|
1771 |
Border Gateway
Protocol 4 |
|
|
|
1517, 1518, 1519 |
CIDR - ClassLess
Interdomain Router |
|
|
|
1930 |
Guidelines for creation, selection and
registration of an Autonomous System (AS) |
|
DHCP |
|
2131 |
DHCP - Dynamic Host Configuration
Protocol |
|
|
|
2132 |
DHCP Options and BOOTP Vendor
Extensions |
|
|
|
1534 |
Interoperation Between DHCP and BOOTP |
|
|
|
2241 |
DHCP Options for Novell Directory
Services |
|
|
|
2242 |
Netware/IP Domain Name and Information |
|
RADIUS |
|
2138 |
Remote Authentication Dial-in User
Service (RADIUS) |
|
|
|
2139 |
RADIUS Accounting |
|
HTML |
|
1866 |
HTML - HyperText
Markup Language |
|
|
|
2110 |
MIME E-mail Encapsulation of Aggregate
Documents such as HTML |
|
HTTP |
|
2068 |
HTTP/1.1 -
HyperText Transfer Protocol |
|
|
|
2109 |
HTTP State
Management Mechanism |
|
|
|
2168 |
Resolution of Uniform Resource
Identifiers using the Domain Name System |
|
|
|
2145 |
Use and Interpretation of HTTP Version
Numbers |
|
LDAP |
|
2251 |
LDAP (Lightweight Directory Access
Protocol) v.3 |
|
|
|
|
|
|
IRC |
|
1459 |
IRC - Internet
Relay Chat |
|
MIME |
|
1521 |
MIME - Multipurpose Internet Mail
Extension |
|
NFS |
|
1813 |
NFS Version 3 - Network File System |
|
NNTP |
|
977 |
NNTP - Network News Transport Protocol |
|
IPV6 |
|
2147 |
TCP and UDP over IPv6 Jumbograms |
|
|
|
2185 |
Routing Aspects of IPv6 Transition |
|
ICP |
|
2186 |
Internet Cache
Protocol (ICP), v2 |
|
|
|
2187 |
Application of
ICP, v2 |
|
Segurança |
|
2196 |
Site Security
Handbook |
|
Histórico |
|
2235 |
Hobbe’s Internet
Timeline |
|
Resumos |
|
2151 |
A Primer on Internet and TCP/IP Tools
and Utilities |
No Brasil, assim
como nos outros países, existem órgãos específicos para o controle local. No
Brasil o Comitê Gestor da Internet é responsável pela definição de políticas de
utilização, e a FAPESP é responsável pela distribuição de endereços e
atribuição de nomes de domínio.
Seguem abaixo,
alguns exemplos de aplicações da arquiteturas distintas de rede baseadas em
TCP/IP, como por exemplo, redes internas de empresas baseadas em transporte
TCP/IP, serviços de redes de empresas conectados à Internet, provedores de
acesso à Internet.
Exemplo 1: Redes
internas à empresa utilizando protocolos TCP/IP para formar a estrutura de
comunicação e a base das aplicações de rede (correio eletrônico),
compartilhamento de arquivos, distribuição de informação via hipertexto, etc… e
chamadas de intranet:

Exemplo 2: Uma
estrutura de rede TCP/IP conectada à Internet de forma segura, através da
utilização de um firewall, que realiza o filtro de pacotes IP e o transporte de
protocolo de aplicações por meio de um gateway (proxy):

Exemplo 3: Um
provedor de acesso à Internet, fornecendo serviços de conexão a usuários
discados e empresas por meio de ligação dedicada, além de oferecer os serviços
básicos de Internet como HTTP, SMTP, POP3, FTP, etc…

A figura 8 ilustra o
posicionamento de diversos protocolos da arquitetura TCP/IP:

Nível Inter-rede
compreende principalmente os protocolos IP e ICMP e IGMP (Internet Group
Management Protocol). Os protocolos ARP e RARP são pertencentes na verdade aos
dois níveis, Inter-rede e Rede pois realizam funções com informações de ambos.
Protocolo IP é
responsável pela comunicação entre máquinas em uma estrutura de rede TCP/IP.
Ele provê a capacidade de comunicação entre cada elemento componente da rede
para permitir o transporte de uma mensagem de uma origem até o destino. O
protocolo IP provê um serviço sem conexão e não confiável entre máquinas em uma
estrutura de rede. Qualquer tipo de serviço que necessite dessas
características deve ser fornecido pelos protocolos de níveis superiores. As
funções mais importantes realizadas pelo protocolo IP são a atribuição de um
esquema de endereçamento independente do endereçamento da rede utilizada abaixo
e independente da própria topologia da rede utilizada, além da capacidade de
rotear e tomar decisões de roteamento para o transporte das mensagens entre os
elementos que interligam as redes.
Na arquitetura
TCP/IP, os elementos responsáveis por interligar duas ou mais redes distintas
são chamados de roteadores. As redes
interligadas podem ser tanto redes locais, redes geograficamente distribuídas,
redes de longa distância com comutação de pacotes ou ligações ponto-a-ponto
seriais. Um roteador tem como característica principal a existência de mais de
uma interface de rede, cada uma com seu próprio endereço específico. Um
roteador pode ser um equipamento específico ou um computador de uso geral com
mais de uma interface de rede.
Por outro lado, um
componente da arquitetura TCP/IP que é apenas a origem ou destino de um
datagrama IP (não realiza a função de roteamento) é chamado de host.
As funções de host e
roteador podem ser visualizadas na figura 9:

Um endereço IP é um
identificador único para certa interface de rede de uma máquina. Este endereço
é formado por 32 bits (4 bytes) e possui uma porção de identificação da rede na
qual a interface está conectada e outra para a identificação da máquina dentro
daquela rede. O endereço IP é representado pelos 4 bytes separados por . e representados por números decimais.
Desta forma o endereço IP:
11001000 11000100
1000010 00000001 é representado por 200.196.66.1.
Como o endereço IP
identifica tanto uma rede quanto a estação a que se refere, fica claro que o
endereço possui uma parte para rede e outra para a estação. Desta forma, uma
porção do endereço IP designa a rede na qual a estação está conectada, e outra
porção identifica a estação dentro daquela rede.
Uma vez que o
endereço IP tem tamanho fixo, uma das opções dos projetistas seria dividir o
endereço IP em duas metades, dois bytes para identificar a rede e dois bytes
para a estação. Entretanto isto traria inflexibilidade pois só poderiam ser
endereçados 65536 redes, cada uma com 65536 estações. Uma rede que possuísse
apenas 100 estações estaria utilizando um endereçamento de rede com capacidade
de 65536 estações, o que também seria um desperdício.
A forma original de
dividir o endereçamento IP em rede e estação, foi feita por meio de classes. Um
endereçamento de classe A consiste em endereços que tem uma porção de
identificação de rede de 1 byte e uma porção de identificação de máquina de 3
bytes. Desta forma, é possível endereçar até 256 redes com 2 elevado a 32
estações. Um endereçamento de classe B utiliza 2 bytes para rede e 2 bytes para
estação, enquanto um endereço de classe C utiliza 3 bytes para rede e 1 byte
para estação. Para permitir a distinção de uma classe de endereço para outra,
utilizou-se os primeiros bits do primeiro byte para estabelecer a distinção
(veja figura abaixo).
Nesta forma de
divisão é possível acomodar um pequeno número de redes muito grandes (classe A)
e um grande número de redes pequenas (classe C). Esta forma de divisão é
histórica e não é mais empregada na Internet devido ao uso de uma variação que
é a sub-rede, como será visto em seção adiante. Entretanto sua compreensão é
importante para fins didáticos.
As classes
originalmente utilizadas na Internet são A, B, C, D, E., conforme mostrado
abaixo. A classe D é uma classe especial para identificar endereços de grupo
(multicast) e a classe E é reservada.

A Classe A possui
endereços suficientes para endereçar 128 redes diferentes com até 16.777.216
hosts (estações) cada uma.
A Classe B possui
endereços suficientes para endereçar 16.284 redes diferentes com até 65.536
hosts cada uma.
A Classe C possui
endereços suficientes para endereçar 2.097.152 redes diferentes com até 256
hosts cada uma.
As máquinas com mais
de uma interface de rede (caso dos roteadores ou máquinas interligadas à mais
de uma rede, mas que não efetuam a função de roteamento) possuem um endereço IP
para cada uma, e podem ser identificados por qualquer um dos dois de modo
independente. Um endereço IP identifica
não uma máquina, mas uma conexão à rede.
Alguns endereços são
reservados para funções especiais:
Endereço de Rede: Identifica a própria rede e não uma interface
de rede específica, representado por todos os bits de hostid com o valor ZERO.
Endereço de Broadcast: Identifica todas as máquinas na rede
específica, representado por todos os bits de hostid com o valor UM.
Desta forma, para
cada rede A, B ou C, o primeiro endereço e o último são reservados e geralmente
não são usados por nenhuma interface de
rede.
Endereço de Broadcast Limitado: Identifica um broadcast na própria rede, sem
especificar a que rede pertence. Representado por todos os bits do endereço
iguais a UM = 255.255.255.255.
Endereço de Loopback: Identifica a própria máquina. Serve para
enviar uma mensagem para a própria máquina rotear para ela mesma, ficando a
mensagem no nível IP, sem ser enviada à rede. Este endereço é 127.0.0.1.
Permite a comunicação inter processos (entre aplicações) situados na mesma
máquina. Função muito utilizada para efetuar balanceamento entre dois
roteadores conectados por 2 interfaces de igual velocidade.
As figuras abaixo
mostram exemplos de endereçamento de máquinas situadas na mesma rede e em redes
diferentes. Pode ser observado que como o endereço começa por 200 (ou seja, os
dois primeiros bits são 1 e o terceiro 0), eles são de classe C. Por isto, os
três primeiros bytes do endereço identificam a rede. Como na primeira figura,
ambas as estações tem o endereço começando por 200.195.240, elas estão na mesma
rede. Na segunda figura, as estações estão em redes distintas e uma possível
topologia é mostrada, onde um roteador interliga diretamente as duas redes.


A figura abaixo
ilustra um diagrama de rede com o endereçamento utilizado. Note que não há
necessidade de correlação entre os endereços utilizados nas redes adjacentes. O
mecanismo para que uma mensagem chegue na rede correta é o roteamento. Cada
elemento conectando mais de uma rede realiza a função de roteamento IP, baseado
em decisões de rotas. Note que mesmo os enlaces formados por ligações
ponto-a-ponto são também redes distintas.
Neste diagrama
existem 6 redes, identificadas por 200.201.133.0, 200.123.0.0, 200.195.4.0,
210.201.0.0, 10.0.0.0 e 200.1.3.0.

Através do uso de
valores pré-estabelecidos nos identificadores de sub-redes e de estação do
endereço IP, é possível utilizar funcionalidades adicionais realizadas pela
camada IP. Estas funções são descritas a seguir.
A função directed broadcast (difusão dirigida)
permite o envio de uma mensagem a uma sub-rede de destino para que seja feita a
sua difusão às estações dessa rede. Neste caso, o campo id.estação do endereço
IP é preenchido com ls e o id.rede contém o identificador da sub-rede. A função
limited broadcast (difusão restrita)
possibilita o envio de uma mensagem as estações locais. Neste caso, tanto o
id.rede como o id.sub-rede são preenchidos com ls.
Em geral, o valor
"0" no endereço IP significa "este" e o valor
"1", todos". A utilização destes valores é restrita a situações
excepcionais, na maioria das vezes quando se desconhece o endereço exato do
destinatário a ser alcançado. A Figura 4 apresenta os casos de utilização de
valores pré-estabelecidos e o significado associado.
Os protocolos de
rede compartilhada como Ethernet, Token-Ring e FDDI possuem um endereço próprio
para identificar as diversas máquinas situadas na rede. Em Ethernet e Token-Ring
o endereçamento utilizado é chamado endereço físico ou endereço MAC - Medium
Access Control , formado por 6 bytes, conforme a figura abaixo:
![]()
Este tipo de
endereçamento só é útil para identificar diversas máquinas, não possuindo
nenhuma informação capaz de distinguir redes distintas. Para que uma máquina
com protocolo IP envie um pacote para outra máquina situada na mesma rede, ela
deve se basear no protocolo de rede local, já que é necessário saber o endereço
físico. Como o protocolo IP só identifica uma máquina pelo endereço IP, deve
haver um mapeamento entre o endereço IP e o endereço de rede MAC. Este
mapeamento é realizado pelo protocolo ARP.
O mapeamento via
protocolo ARP só é necessário em uma rede do tipo compartilhada como Ethernet,
Token-Ring, FDDI, etc.. Em uma rede ponto-a-ponto como, por exemplo, um enlace
serial, o protocolo ARP não é necessário já que há somente um destino possível.
A figura abaixo
mostra uma rede com 3 estações, onde uma máquina A com endereço IP
200.195.240.1 deseja enviar uma mensagem para a máquina B cujo endereço é
200.195.240.3. A mensagem a ser enviada é uma mensagem IP. No caso do exemplo
abaixo, antes de efetivamente enviar a mensagem IP, a estação utilizará o
protocolo ARP para determinar o endereço MAC da interface cujo endereço IP é o
destino da mensagem.

O funcionamento do
protocolo ARP é descrito abaixo:
Estação A verifica
que a máquina destino está na mesma rede local, determinado através dos
endereços origem e destino e suas respectivas classes.
O protocolo IP da
estação A verifica que ainda não possui um mapeamento do endereço MAC para o
endereço IP da máquina destino.
O protocolo IP
solicita ao protocolo que o endereço MAC necessário
Protocolo ARP envia
um pacote ARP (ARP Request) com o endereço MAC destino de broadcast (difusão
para todas as máquinas)

A mensagem ARP
enviada é encapsulada em um pacote Ethernet conforma mostrado abaixo:

Todas as máquinas
recebem o pacote ARP, mas somente aquela que possui o endereço IP especificado
responde. A máquina B já instala na tabela ARP o mapeamento do endereço
200.195.240.1 para o endereço MAC de A.

A resposta é enviada
no pacote Ethernet, encapsulado conforme mostrado abaixo, através de uma
mensagem ARP Reply endereçado diretamente para a máquina origem.

A máquina A recebe o
pacote e coloca um mapeamento do endereço IP de B e seu endereço MAC
respectivo. Esta informação residirá em uma tabela que persistirá durante um
certo tempo.
Finalmente a máquina
A transmite o pacote IP inicial, após saber o endereço MAC da estação destino.

Os protocolos de
nível de Rede como Ethernet possuem um identificador para determinar o tipo do
protocolo que está sendo carregado no seu campo de dados. Um pacote Ethernet
pode, por exemplo, carregar os protocolos ARP, IP, RARP, IPX, Netbios e outros.
A figura abaixo mostra o formato do quadro Ethernet. Note que o campo
protocolo, de 2 bytes de tamanho identifica o protocolo sendo carregado no campo
de dados. No caso de transporte de um pacote ARP, o valor é 0806h
(hexadecimal), enquanto que no caso de IP este campo tem o valor 0800h.

O protocolo ARP
possui dois pacotes, um REQUEST e um REPLY, com o formato abaixo. No REQUEST,
são preenchidos todos os dados exceto o endereço MAC do TARGET. No REPLY este
campo é completado.

HARDWARE TYPE identifica o hardware (Ethernet, Token-Ring , FDDI, etc) utilizado, que
pode variar o tamanho do endereço MAC.
PROTOCOL TYPE identifica o protocolo sendo mapeado (IP, IPX, etc,) que pode variar o
tipo do endereço usado.
OPERATION identifica o tipo da operação, sendo
1 = ARP Request, 2 = ARP Reply, 3 = RARP
Request, 4 = RARP Reply
O destino de um
mensagem IP sendo enviado por uma máquina pode ser a própria estação, uma
estação situada na mesma rede ou uma estação situada numa rede diferente. No
primeiro caso, o pacote é enviado ao nível IP que o retorna para os níveis
superiores. No segundo caso, é realizado o mapeamento por meio de ARP e a mensagem
é enviada por meio do protocolo de rede.
Quando uma estação
ou roteador deve enviar um pacote para outra rede, o protocolo IP deve enviá-lo
para um roteador situado na mesma rede. O roteador por sua vez irá
enviar o pacote para outro roteador, na mesma rede que este e assim
sucessivamente até que o pacote chegue ao destino final. Este tipo de
roteamento é chamado de Next-Hop Routing, já que um pacote é sempre enviado
para o próximo roteador no caminho.
Neste tipo de
roteamento, não há necessidade de que um roteador conheça a rota completa até o
destino. Cada roteador deve conhecer apenas o próximo roteador para o qual deve
enviar a mensagem. Esta decisão é chamada de decisão de roteamento. Uma máquina
situado em uma rede que tenha mais de um roteador deve também tomar uma decisão
de roteamento para decidir para qual roteador deve enviar o pacote IP.
Quando uma estação
deve enviar uma mensagem IP para outra rede, ela deve seguir os seguintes
passos:
Descobrir, através do protocolo
ARP, qual o endereço MAC do roteador
Uma questão
importante no pacote roteado consiste no fato de que o pacote a ser roteado é
endereçado fisicamente ao roteador (endereço MAC), mas é endereçado logicamente
(endereçamento IP) à máquina destino. Quando o roteador recebe um pacote que
não é endereçado a ele, tenta roteá-lo.
A decisão de
roteamento é baseada em uma tabela, chamada de tabela de rotas, que é parte
integrante de qualquer protocolo IP. Esta tabela relaciona cada rede destino ao
roteador para onde o pacote deve ser enviado para chegar a ela.
As figuras abaixo
mostram o funcionamento do roteamento:


Nas figuras acima o
roteamento é realizado somente por um roteador. Caso houvesse mais de um
roteador a ser atravessado, o primeiro roteador procederia de forma idêntica à
Estação A, ou seja determinaria a rota correta e enviaria a mensagem para o
próximo roteador.
Algoritmo de
Transmissão de um pacote IP é descrito abaixo. A transmissão pode ser aplicada
tanto a um host quanto a uma estação:
1. Datagrama pronto para ser transmitido
1.1. Endereço Destino é igual ao Endereço Transmissor ?
1.1.1. Entrega datagrama pela interface loopback (127.0.0.1) Þ FIM
1.2. Endereço de rede do destino é igual ao endereço de
rede local ?
1.2.1. Descobre o endereço físico do destino (ARP)
1.2.2. Transmite datagrama pela interface correta Þ FIM
1.3. Endereço de rede do destino é diferente do endereço de
rede local ?
1.3.1. Verifica tabela de rotas
1.3.2. Descobre rota que se encaixa com a rede destino
1.3.3. Descobre o endereço físico do gateway (ARP)
1.3.4. Transmite o datagrama para o gateway Þ FIM
1. Datagrama recebido da camada intra-rede,
desfragmentado e testado
1.1.
End. destino = End. host, ou End.
destino = outras interface host, ou End. destino = broadcast
1.1.1. Passa datagrama para níveis superiores Þ FIM
1.2. Máquina que recebeu não é roteador
1.2.1. Descarta datagrama Þ FIM
1.3. Máquina é roteador (possui mais de uma interface IP)
1.3.1. Endereço IP destino é igual Rede IP com interface
diretamente conectada
1.3.2. Descobre o endereço físico do destino (ARP)
1.3.3. Transmite datagrama pela interface respectiva Þ FIM
1.4. Endereço de rede destino é diferente dos endereços das
interfaces
1.4.1. Verifica tabela de rotas
1.4.2. Descobre o endereço físico do gateway (ARP)
1.4.3. Transmite o datagrama para o gateway Þ FIM
O exemplo abaixo
ilustra uma estrutura de redes e a tabela de rotas dos roteadores. As tabelas
de rotas de cada roteador são diferentes uma das outras. Note nestas tabela a
existência de rotas diretas, que são informações redundantes para identificar a
capacidade de acessar a própria rede na qual os roteadores estão conectados.
Este tipo de rota apesar de parecer redundante é útil para mostrar de forma
semelhante as rotas diretas para as redes conectadas diretamente no roteador.
Outra informação
relevante é a existência de uma rota default.
Esta rota é utilizada durante a decisão de roteamento no caso de não existir
uma rota específica para a rede destino da mensagem IP. A rota default pode ser
considerada como um resumo de diversas rotas encaminhadas pelo mesmo próximo
roteador. Sem a utilização da rota default, a tabela de rotas deveria possuir
uma linha para cada rede que pudesse ser endereçada. Em uma rede como a
Internet isto seria completamente impossível.

A tabela de rotas
para o roteador da esquerda é descrita abaixo:
|
Rede Destino |
Roteador (Gateway) |
Hops |
|
201.0.0.0 |
eth0 (rota direta) |
0 |
|
202.0.0.0 |
eth1 (rota direta) |
0 |
|
203.0.0.0 |
202.0.0.3 |
1 |
|
204.0.0.0 |
203.0.0.3 |
2 |
|
default |
203.0.0.3 |
-- |
A tabela de rotas
para o roteador central é descrita abaixo:
|
Rede Destino |
Roteador (Gateway) |
Hops |
|
202.0.0.0 |
eth0 (rota direta) |
0 |
|
203.0.0.0 |
eth1 (rota direta) |
0 |
|
201.0.0.0 |
202.0.0.2 |
1 |
|
204.0.0.0 |
203.0.0.5 |
1 |
|
Default |
203.0.0.5 |
-- |
A tabela de rotas
para o roteador da direita é descrita abaixo:
|
Rede Destino |
Roteador (Gateway) |
Hops |
|
203.0.0.0 |
eth0 (rota direta) |
0 |
|
204.0.0.0 |
eth1 (rota direta) |
0 |
|
202.0.0.0 |
203.0.0.4 |
1 |
|
201.0.0.0 |
203.0.0.4 |
1 |
|
Default |
204.0.0.7** |
-- |
** Não mostrado na
figura.
A rota default
geralmente é representada nos sistemas operacionais como a rede 0.0.0.0
A alimentação das
informações na tabela de rotas pode ser de modo estático ou dinâmico ou ambos
simultaneamente. Na alimentação estática, as rotas são preenchidas manualmente,
geralmente pela configuração inicial da máquina. Na alimentação dinâmica,
protocolos como RIP, RIP2, EIGRP, OSPF ou BGP4 são responsáveis pela aquisição
de informações sobre a topologia da rede e a publicação de rotas na tabela de
rotas dos roteadores envolvidos.
Como exemplos de
rotas definidas estaticamente, pode-se citar:
Uma rota default (ou
roteador default) configurado manualmente nas estações (caso típico da maioria
das estações cliente em uma rede. Exemplo: Janela de configuração básica de
TCP/IP em Windows 98, Windows NT e Windows 2000.
Mais de uma rota
default, com os roteadores configurados manualmente nas estações.
Rotas adicionais
estáticas configuradas manualmente endereçando redes específicas. Por .ex.
Comando route add dos sistemas operacionais Windows NT e Windows 2000 .
Roteadores
descobertos através do protocolo ICMP Router Advertisement
Rotas informadas
através do protocolo ICMP Redirect
O protocolo IP
define a unidade básica de transmissão, que é o pacote IP. Neste pacote são
colocadas as informações relevantes para o envio deste pacote até o destino.
O pacote IP possui o
formato descrito abaixo:

Os campos mais
importantes são descritos abaixo:
VERSION - Informa a versão do protocolo IP sendo carregado. Atualmente a versão
de IP é 4
HEADER LENGTH - Informa o tamanho do cabeçalho IP em grupos de 4 bytes
TYPE OF SERVICE - Informa como o pacote deve ser tratado, de
acordo com sua prioridade e o tipo de serviço desejado como Baixo Retardo, Alta
Capacidade de Banda ou Alta Confiabilidade. Normalmente este campo não é
utilizado na Internet
IDENTIFICATION - Identifica o pacote IP unicamente entre os
outros transmitidos pela máquina. Este campo é usado para identificar o pacote
IP no caso de haver fragmentação em múltiplos datagramas
FLAGS (3 bits) - um bit (MF - More Fragments) identifica se
este datagrama é o último fragmento de um pacote IP ou se existem mais. Outro
bit (DNF - Do Not Fragment) informa aos roteadores no caminho se a aplicação
exige que os pacotes não sejam fragmentados.
FRAGMENT OFFSET - Informa o posicionamento do fragmento em
relação ao pacote IP do qual faz parte.
TIME-TO-LIVE - Este valor é decrementado a cada 1 segundo que o pacote passa na rede
e a cada roteador pelo que ele passa. Serve para limitar a duração do pacote IP
e evitar que um pacote seja roteador eternamente na Internet como resultado de
um loop de roteamento.
PROTOCOL - Informa que protocolo de mais alto nível está sendo carregado no
campo de dados. O IP pode carregar mensagens UDP, TCP, ICMP, e várias outras.
HEADER CHECKSUM - Valor que ajuda a garantir a integridade do
cabeçalho do pacote IP
SOURCE ADDRESS - Endereço IP da máquina origem do pacote IP
DESTINATION ADDRESS - Endereço IP da máquina destino do pacote IP
OPTIONS - Opções com informações adicionais para o protocolo IP. Consiste de um
byte com a identificação da opção e uma quantidade de bytes variável com as
informações específicas. Um pacote IP pode transportar várias opções
simultaneamente.
formato das opções
IP é descrita no quadro abaixo:

As opções IP que
podem ser utilizadas são:
|
Classe |
Código |
Composição |
Descrição |
|
0 |
0 |
-- |
Fim da Lista de
Opções |
|
0 |
1 |
-- |
Nenhuma Operação |
|
0 |
3 |
variável |
LOOSE SOURCE
ROUTING (Especifica a rota aproximada que um datagrama deve seguir) |
|
0 |
7 |
variável |
RECORD ROUTE
(Escreve os endereços dos roteadores por onde o pacote passou) |
|
0 |
9 |
variável |
STRICT SOURCE
ROUTING (Especifica a rota exata que um datagrama deve seguir) |
|
2 |
4 |
variável |
INTERNET TIMESTAMP
(A cada roteador grava a hora da passagem para outra rede) |
As opções IP são
utilizadas basicamente como forma de verificação e monitoração de uma rede IP.
As opções que especificam a rota até o destino não são utilizadas normalmente
pois o IP é baseado na técnica de Next-Hop routing. Ainda assim, estes
mecanismos são pouco utilizados como ferramenta de testes e verificação, sendo
raros os programas que os implementam.
Como um datagrama trafega
através de diversos tipos de rede e cada tecnologia tem um tamanho de bloco
diferente, a camada IP possui o mecanismo de fragmentação , para garantir que um datagrama possa atravessar
redes que utilizem tamanhos de bloco de transmissão diferentes. Quando for necessário
transportar um datagrama de tamanho maior do que aquele que a sub-rede pode
suportar, o mecanismo de fragmentação é acionado. O datagrama original é
particionado em fragmentos. O
tamanho de fragmento é determinado de maneira a poder ser transportado em único
bloco de transmissão da sub-rede.
Os fragmentos são
transportados como se fossem datagramas independentes até o destino. Ao receber
o primeiro fragmento, a estação inicia uma temporização para aguardar o
conjunto completo de fragmentos; se algum faltar, o datagrama é descartado.
Assim, o processo de fragmentação provoca uma perda de eficiência devido à
preservação dos fragmentos até a estação destinatária (mesmo que sejam
transportados por sub-redes com tamanho de blocos superiores) e devido ao
aumento do índice de retransmissões nos casos de perda de fragmentos, quando,
então, o datagrama completo é descartado.
Para fragmentar um datagrama
longo, são criados vários datagramas menores que recebem uma cópia do datagrama
original sendo alguns dos seus campos modificados. Nos datagramas criados, o
tamanho da parte de dados é múltiplo de 8 octetos e está limitado pelo tamanho
máximo do bloco de transmissão permitido na sub-rede. Pode ser que o último
fragmento não seja múltiplo de 8 octetos. Na definição do tamanho do fragmento
são levadas em conta a parte dos dados e a do cabeçalho. A primeira parte dos
dados do datagrama original é inserida no primeiro fragmento e neste o campo comprimento total é atualizado com o
tamanho dessa parte de dados e do cabeçalho. Nesse primeiro fragmento, um dos bits do campo flags, chamado bit mais-fragmentos,
recebe o valor 1 para indicar que mais fragmentos deverão seguir-se. O seu
campo fragment offset permanece igual ao datagrama original.
O restante dos dados é
inserido em fragmentos subsequentes. Nestes, o campo comprimento total corresponde à quantidade de dados
efetivamente enviada. O valor do fragment offset em cada um desses
fragmentos é a soma do fragment offset e do número de
octetos de dados do fragmento anterior. Se o fragmento não for o último, o bit mais-fragmentos do campo flags recebe o valor 1; caso
contrário, o valor "0". Além destes campos essenciais ao processo, os
outros campos são alterados, como o campo de opções, o campo de comprimento do
cabeçalho e o checksum.
Na recepção, um
datagrama é reconhecido como fragmento pela indicação do bit mais-fragmentos do campo
flags e da ocorrência de valor diferente de zero no campo fragment
offset (exceto se for o primeiro fragmento). Os fragmentos de um mesmo
datagrama são identificados através do campo identificação, dos endereços IP de origem e destino e do campo de
protocolo, copiados a partir do datagrama original no momento da fragmentação.
O último fragmento é identificado por ter o campo mais-fragmentos igual a
zero e pelo valor diferente de zero do campo fragment offset.
Enfim, um pacote IP
pode ter um tamanho de até 64 Kbytes. Entretanto o nível de rede geralmente tem
um tamanho máximo menor que 64K. Por exemplo, uma rede Ethernet pode transmitir
uma mensagem de até 1500 bytes. Este valor é chamado de MTU - Maximum
Transmission Unit - para este tipo de rede. A camada IP deve então ser capaz de
dividir um pacote IP maior que 1500 bytes em diversos fragmentos de até 1500
bytes cada um.
A fragmentação do
pacote IP pode ocorrer na máquina origem ou em algum roteador que possua uma
rede com MTU menor que o tamanho do pacote IP sendo roteado. Note que durante o
percurso até o destino, um fragmento pode ser novamente fragmentado se o MTU da
rede seguinte for ainda menor que o tamanho do fragmento. A remontagem do
pacote só é realizada pela máquina destino, baseado nas informações de FRAGMENT
OFFSET e bit MF. A perda de um fragmento inutiliza o datagrama inteiro.
O campo fragment
offset identifica a posição em Bytes do fragmento face ao pacote IP
completo conforme pode ser visto nas figuras abaixo:

A figura abaixo
mostra a fragmentação de um pacote quando este passa para uma rede com MTU
menor que o tamanho do pacote IP.

A divisão de
endereçamento tradicional da Internet em classes, causou sérios problemas de
eficiência na distribuição de endereços. Cada rede na Internet, tenha ela 5,
200, 2000 ou 30 máquinas deveria ser compatível com uma das classes de
endereços. Desta forma, uma rede com 10 estações receberia um endereço do tipo
classe C, com capacidade de endereçar 256 estações. Isto significa um
desperdício de 246 endereços. Da mesma forma, uma rede com 2000 estações
receberia uma rede do tipo classe B, e desta forma causaria um desperdício de
62000 endereços.
número de redes
interligando-se à Internet a partir de 1988 aumentou, causando o agravamento do
problema de disponibilidade de endereços na Internet, especialmente o
desperdício de endereços em classes C e B. Desta forma, buscou-se alternativas
para aumentar o número de endereços de rede disponíveis sem afetar o
funcionamento dos sistemas existentes. A melhor alternativa encontrada foi
flexibilizar o conceito de classes - onde
a divisão entre rede e host ocorre somente a cada 8 bits.
A solução encontrada
foi utilizar a identificação de rede e host no endereçamento IP de forma
variável, podendo utilizar qualquer quantidade de bits e não mais múltiplos de
8 bits conforme ocorria anteriormente. Um identificador adicional, a MÁSCARA,
identifica em um endereço IP, que porção de bits é utilizada para identificar a
rede e que porção de bits para host.
A máscara é formada
por 4 bytes com uma seqüência contínua de 1’s, seguida de uma seqüência de 0’s.
A porção de bits em 1 identifica quais bits são utilizados para identificar a
rede no endereço e a porção de bits em 0, identifica que bits do endereço
identificam a estação.
Obs. A máscara pode
ser compreendida também como um número inteiro que diz a quantidade de bits um
utilizados. Por exemplo uma máscara com valor 255.255.255.192, poderia ser
representada como /26. Este tipo de notação é empregada em protocolos de
roteamento mais recentes
Este mecanismo está
representado na figura abaixo:

Neste endereço
200.18.160.X, a parte de rede possui 26 bits para identificar a rede e os 6
bits restantes para identificar os hosts. Desta forma, o endereço 200.18.160.0
da antiga classe C, fornecido a um conjunto de redes pode ser dividido em
quatro redes com as identificações abaixo. Note que os 4 endereços de rede são
independentes entre si. Elas podem ser empregadas em redes completamente
separadas, e até mesmo serem utilizadas em instituições distintas.
200.18.160.[00XXXXXX]
200.18.160.[01XXXXXX]
200.18.160.[10XXXXXX] e
200.18.160.[11XXXXXX]
Em termos de
identificação da rede, utiliza-se os mesmos critérios anteriores, ou seja,
todos os bits de identificação da estação são 0. Quando os bits da estação são todos 1, isto
identifica um broadcast naquela rede específica. Desta forma temos as seguintes
identificações para endereço de rede:
200.18.160.64
200.18.160.128 e
200.18.160.192
Os endereços de
broadcast nas redes são:
200.18.160.127
200.18.160.191 e
200.18.160.255
Os possíveis
endereços de estação em cada rede são:
200.18.160.[1-62]
200.18.160.[65-126]
200.18.160.[129-190] e
200.18.160.[193-254]
O mesmo raciocínio
de sub-rede pode ser usado para agrupar várias redes da antiga classe C em uma
rede com capacidade de endereçamento de um maior número de hosts. A isto dá-se
o nome de superrede. Hoje, já não há mais esta denominação pois não existe mais
o conceito de classes. Um endereço da antiga classe A, como por exemplo
32.X.X.X pode ser dividido de qualquer forma por meio da máscara.

As máscaras das
antigas classes A, B e C são um subconjunto das possibilidades do esquema
utilizado atualmente, conforme mostrado abaixo:
Classe A: máscara
equivalente = 255.0.0.0
Classe B: máscara
equivalente = 255.255.0.0
Classe C: máscara
equivalente = 255.255.255.0
Uma conclusão que
pode-se obter da análise acima é que uma identificação de uma rede, composta de
um endereço de rede e uma máscara (por ex. 200.195.240.64 e máscara
255.255.255.192) é, na verdade, um espaço de endereçamento, que pode ser usado
da forma mais indicada. Por exemplo um espaço de endereçamento dado por
Rede = 32.10.20.128
com máscara 255.255.255.192
Pode-se endereçar 64
endereços (62 endereços válidos) em uma rede só. Mas podemos subdividi-lo em
sub-redes, de tal forma que poderemos ter:
1 rede de 64
endereços (usando o endereço e a máscara como estão)
2 redes de 32
endereços (aumentando em mais um bit a máscara)
Neste caso temos o
endereço 32.10.20.128 dividido da seguinte forma:
Rede 1 =
32.10.20.128 com máscara 255.255.255.224 e
Rede 2 = 32.10.20.160
com máscara 255.255.255.224
Neste caso, cada
rede formada pode ter até 30 endereços, pois deve-se sempre reservar os bits
TODOS ZERO para o endereço de rede e os bits TODOS UM para o endereço de
broadcast.
Desta forma, os
endereços de máquina em cada rede são:
Rede 1:
32.10.20.[129-158] e
Rede 2:
32.10.20.[161-190]
Note que deve-se
sempre respeitar o espaço de endereçamento original. Um dos erros mais comuns é
utilizar parte do endereçamento vizinho, o que está errado pois pertence a
outro espaço de endereçamento.
4 redes de 16
endereços (aumentando em dois bits a mascara original)
Neste caso temos o
endereço 32.10.20.128 dividido da seguinte forma:
Rede 1 =
32.10.20.128 com máscara 255.255.255.240
Rede 2 =
32.10.20.144 com máscara 255.255.255.240
Rede 3 =
32.10.20.160 com máscara 255.255.255.240
Rede 4 =
32.10.20.176 com máscara 255.255.255.240
Neste caso, cada
rede formada pode ter até 14 estações
Então os endereços
de máquina em cada rede são:
Rede 1:
32.10.20.[129-142]
Rede 2: 32.10.20.[145-158]
Rede 3:
32.10.20.[161-174]
Rede 4:
32.10.20.[177-190]
Note que o espaço de
endereçamento original sempre se manteve, variando de 128 a 191
8 redes de 8
endereços
16 redes de 4
endereços (onde 4 endereços são na verdade duas estações, devido aos endereços
reservados de rede e broadcast)
E só ! pois 32 redes de 2 estações não existe pois
seria uma rede sem nenhuma estação pois os dois endereços disponíveis já seriam
utilizados para rede e broadcast.
Entretanto, as
formas acima ainda não são as únicas formas de divisão do espaço de
endereçamento. Pode-se dividir em mais uma dezena de forma, utilizando-se
divisões do espaço de endereçamento de forma não homogênea. Um exemplo claro
pode ser dado por exemplo observando redes reais, onde a quantidade de estações
pode variar bastante entre cada uma. Po exemplo, supondo que o espaço de
endereçamento acima com capacidade de endereçar 64 estações deva ser utilizado
em uma empresa com 50 estações. Estas 50 estações estão divididas em 3 redes,
sendo uma com 30 estações e duas com 10 estações. Pode-se observar que nenhuma
das formas de divisão acima são aceitáveis pois ou não comportam o número de
redes necessárias (divisão em duas) ou não comportam o número de estações
(divisão em 4).
A solução é realizar
uma divisão do espaço de endereçamento de forma não homogênea. Isto é realizado
de forma simples, utilizando metade do espaço original para a rede de 30
estações e dividindo o espaço restante em duas redes de 16 endereços.
De forma resumida, a
divisão é da seguinte forma:
espaço original; é
dividido em dois, onde temos duas redes de 32 endereços:
Rede 1 =
32.10.20.128 com máscara 255.255.255.224
Rede 2 =
32.10.20.160 com máscara 255.255.255.224
Utiliza-se a rede 1
que possui os endereços de estação 32.10.20[129-158] para a rede com 30
estações. A rede 2 é na verdade um outro espaço de endereçamento (!) dado por
32.10.20.160 com máscara 255.255.255.224. Pode-se então dividir este espaço de
endereçamento em duas rede, bastando aumentar um bit na máscara de rede:
Rede 2 =
32.10.20.160 com máscara 255.255.255.240
Rede 3 =
32.10.20.176 com máscara 255.255.255.240
Então, o resultado
final são três redes, onde a rede 2 possui os endereços de rede
32.10.20.[161-174] para estações e a rede 3 possui os endereços 32.10.20.[177-190]
para as estações.
A figura abaixo
mostra um exemplo de redes de uma empresa que ao se ligar à Internet, recebeu o
espaço de endereçamento 200.195.240.0 com máscara 255.255.255.0 para ser
utilizado em suas 3 redes internas. As rede possuem cada uma 50 estações, de
modo que a divisão mais adequada é dividir o espaço em 4 redes de 64 endereços.
Neste caso o espaço
de endereçamento 200.195.240.0 com máscara 255.255.255.0 foi dividido em três
sub-redes, cada uma com capacidade de endereçar até 62 estações (64
endereços retirando o [000000] e o
[111111]).
Note neste exemplo,
que para a Internet, as três redes são vistas como uma só pois as rotas na
Internet sempre se referem à rede 200.195.240.0 com máscara 255.255.255.0. Por
isto os termos rede e espaço de endereçamento são utilizados de forma
indistinta.

Com a utilização de
sub-rede, a tabela de rotas possui um campo adicional que é a mascara de rede,
já que a identificação de uma rede possui uma máscara.
No caso do exemplo
anterior, um roteador qualquer na Internet que conecte este conjunto de redes à
Internet possui apenas uma rota para a rede 200.195.240.0, com máscara
255.255.255.0, endereçada para o roteador 10.0.0.1. Isto mostra que a informação
roteamento das diversas sub-redes pode ser agregada em uma única linha na
tabela de rotas.
Por exemplo apesar
de possuir centenas de redes, os roteadores na Internet possuem um conjunto de
rotas agrupadas para cada provedor. Os roteadores internos devem saber
distinguir as diversas sub-redes formadas.
No exemplo anterior,
o roteador interna da empresa não pode ter uma rota genérica para a rede
200.195.240.0, mas precisa saber endereçar as diversas sub-redes. Isto se dá
pela utilização de rotas associadas a máscara. A tabela abaixo mostra a tabela
de rotas deste roteador:
|
Rede Destino |
Máscara |
Roteador (Gateway) |
Hops |
|
200.195.240.0 |
255.255.255.192 |
200.195.240.1
(eth0) |
0 |
|
10.0.0.0 |
255.0.0.0 |
10.0.0.1 (serial1) |
0 |
|
200.195.240.64 |
255.255.255.192 |
200.195.240.3 |
1 |
|
200.195.240.128 |
255.255.255.192 |
200.195.240.2 |
1 |
|
default |
0.0.0.0 |
10.0.0.2 |
-- |
A tabela de rotas do
roteador inferior é dada pela tabela abaixo:
|
Rede Destino |
Máscara |
Roteador (Gateway) |
Hops |
|
200.195.240.0 |
255.255.255.192 |
200.195.240.3
(eth0) |
0 |
|
200.195.240.64 |
255.255.255.192 |
200.195.240.65
(eth1) |
0 |
|
200.195.240.128 |
255.255.255.192 |
200.195.240.2 |
1 |
|
default |
0.0.0.0 |
200.195.240.1 |
-- |
A máscara de rede
faz parte de toda tabela de rotas.
Algoritmo de
Recepção de pacote IP e roteamento com a introdução da máscara de sub-rede fica
alterado conforme abaixo:
Datagrama recebido
da camada intra-rede, desfragmentado e testado
End destino = End.
host, ou End. destino = outras interfaces host, ou End. destino = broadcast
Passa datagrama para
níveis superiores Þ FIM
1.1. Máquina que recebeu não é roteador
1.1.1. Descarta datagrama Þ FIM
1.2. Máquina é roteador (possui mais de uma interface IP)
1.2.1. Endereço de rede IP destino = Rede IP com interface
diretamente conectada
1.2.1.1.
Descobre o endereço físico
do destino (ARP)
1.2.1.2.
Transmite datagrama pela
interface respectiva Þ FIM
1.2.2. AND lógico do end IP destino e das rotas da tabela com
máscaras de cada rede
1.2.2.1.
Se algum conferir, descobriu
uma rota
1.2.2.2.
Obtém da tabela o end IP do
roteador destino da rota mais específica.
1.2.2.2.1.
Descobre o endereço físico
do gateway (ARP)
1.2.2.2.2.
Transmite o datagrama para o
gateway Þ FIM
Devido a motivos
históricos do desenvolvimento de TCP/IP, a divisão em sub-redes tem algumas
restrições quanto a utilização de algumas sub-redes. Basicamente, não se pode
utilizar o endereçamento que contêm todos os bits UM da porção da sub-rede. As
implementações mais novas permitem que este endereçamento seja utilizado.
A figura abaixo
ilustra esta restrição na utilização da sub-rede com os dois bits 11, para o
caso da máscara 255.255.255.192. No caso da utilização da máscara
255.255.255.224, não se deve utilizar a sub-rede com bits 111.

Tendo em vista o
crescimento de corporações que estão implementando TCP/IP como protocolo de
rede, o IANA (Internet Assigned Numbers Authority) reservou 3 faixas de
endereçamento a serem utilizados para as redes privativas através da criação da
RFC 1918 (Request for Comments), que são:
10.0.0.0 - 10.255.255.255 (prefixo 10/8)
172.16.0.0 -
172.31.255.255 (prefixo 172.16/12)
192.168.0.0 -
192.168.255.255 (prefixo 192.168/16)
Nós referimos ao primeiro bloco como "bloco
24-bit ", o segundo como "bloco 20-bit ", e ao terceiro como
“bloco 16-bit ".Note que (pre-CIDR notação) primeiro nada mas é que uma
única rede classe A, enquanto que a segunda é um conjunto de 16 redes classes B
contíguas, e a terceira é um conjunto de 256 redes contíguas classes C.
O protocolo ICMP é
um protocolo auxiliar ao IP, que carrega informações de controle e diagnóstico,
informando falhas como TTL do pacote IP expirou, erros de fragmentação,
roteadores intermediários congestionados e outros.
Uma mensagem ICMP é
encapsulada no protocolo IP, conforme ilustrado na figura abaixo. Apesar de
encapsulado dentro do pacote IP, o protocolo ICMP não é considerado um
protocolo de nível mais alto.

A mensagem ICMP é
sempre destinada ao host origem da mensagem, não existindo nenhum mecanismo
para informar erros aos roteadores no caminho ou ao host destino.
As mensagens ICMP
possuem um identificar principal de tipo (TYPE) e um identificador de sub-tipo
(CODE), conforme pode ser visto no formato de mensagem ilustrado abaixo:

Os tipos de mensagem
ICMP são listados na tabela abaixo:

As mensagens ICMP
são listadas abaixo:
Utilizada pelo
comando ping, a mensagem Echo Request enviada para um host causa o retorno de
uma mensagem Echo Reply. É utilizada principalmente para fins de testes de
conectividade entre as duas máquinas.

Esta mensagem possui
diversos sub-tipos para identificar o motivo da não alcançabilidade: os
sub-tipos utilizados atualmente são:
0 : Network Unreachable - Rede destino inalcançável
1 : Host Unreachable (ou
falha no roteamento para subnet) - Máquina destino inalcançável
2 : Protocol Unreachable - Protocolo destino desativado
ou aplicação inexistente
3 : Port Unreachable - Port destino sem aplicação
associada
4 : Fragmentation Needed and
DNF set -
Fragmentação necessária mas bit DNF setado. Alterado também pela RFC 1191 para
suporta o protocolo Path MTU Discovery
5 : Source Route Failed - Roteamento por rota
especificada em opção IP falhou
6 : Destination Network Unknown
7 : Destination Host Unknown
8 : Source Host Isolated
9 : Communication with
destination network administratively prohibited
10 : Communication with
destination host administratively prohibited
O sub-tipo
Fragmentation Needed and DNF set é utilizado como forma de um host descobrir o
menor MTU nas redes que serão percorridas entre a origem e o destino. Por meio
desta mensagem, é possível enviar pacotes que não precisarão ser fragmentados,
aumentando a eficiência da rede. Esta técnica, que forma um protocolo é
denominado de ICMP MTU Discovery Protocol, definido na RFC 1191.
A operação é
simples. Todo pacote IP enviado é marcado com o bit DNF (Do Not Fragment), que
impede sua fragmentação nos roteadores. Desta forma, se uma pacote IP, ao
passar por um roteador para chegar a outra rede com MTU menor, deva ser
fragmentado, o protocolo IP não irá permitir e enviará uma mensagem ICMP
Destination Unreacheable para o destino. Para suportar esta técnica, a mensagem
ICMP foi alterada para informar o MTU da rede que causou o ICMP. Desta forma, a
máquina origem saberá qual o valor de MTU que causou a necessidade de
fragmentação, podendo reduzir o MTU de acordo, nos próximos pacotes. Esta
mensagem está ilustrada abaixo:

Esta mensagem é
utilizada por um roteador para informar à origem, que foi obrigado a descartar
o pacote devido a incapacidade de roteá-lo devido ao tráfego.

Esta mensagem, uma
das mais importantes do protocolo IP, é utilizada por um roteador para informar
ao host origem de uma mensagem que existe uma rota direta mais adequada através
de outro roteador. O host, após receber a mensagem ICMP, instalará uma rota
específica para aquele host destino:

A operação do ICMP
Redirect ocorre conforme os diagramas abaixo. Note que a rota instalada é uma
rota específica para host, com máscara 255.255.255.255, não servindo para
outras máquinas na mesma rede. Se uma máquina se comunica com 10 máquinas em
outra rede e se basear em ICMP Redirect para aprender as rotas, ele instalará
pelo menos 10 entradas na tabela de rede, uma para cada máquina


Na figura acima, a
estação 200.123.17.22 criou, após a mensagem ICMP, a seguinte rota na tabela de
rotas:
|
Rede Destino |
Máscara |
Roteador (Gateway) |
Hops |
|
200.123.19.55 |
255.255.255.255 |
200.123.17.1 |
0 |
Esta mensagem ICMP
originada em um roteador informa ao host de origem que foi obrigado a descartar
o pacote, uma vez que o TTL chegou a zero.

Esta mensagem é
utilizada pelo programa traceroute (ou tracert no Windows) para testar o
caminho percorrido por um pacote. O programa funciona da seguinte forma:
É enviada uma
mensagem ICMP Echo Request para um endereço IP destino. Esta mensagem é enviada
com TTL = 1.
Quando chega ao
primeiro roteador, este decrementa o valor de TTL da mensagem IP e retorna uma
mensagem ICMP TTL Expired. O programa armazena o endereço IP do roteador que
enviou a mensagem TTL Expired.
O programa envia
outra mensagem ICMP Echo Request para o endereço IP destino. Esta mensagem é
enviada desta vez com TTL=2.
A mensagem atravessa
o primeiro roteador e tem o TTL decrementado para 1. Quando chega ao segundo
roteador, o TTL torna-se 0 e este roteador envia uma mensagem ICMP TTL Expired
para a máquina origem. Esta armazena o endereço do segundo roteador.
Esta operação
prossegue até que a máquina destino responda. Todos os roteadores no caminho
são registrados.
Note, entretanto,
que devido à diferenças de rotas seguidas pelos diversos pacotes, o caminho
obtido não necessariamente é único. A execução do programa traceroute mais de
uma vez pode revelar rotas diferentes seguidas pelos pacotes.
Esta variação de
ICMP, definido na RFC 1256 foi projetada para permitir que um roteador possa
divulgar sua existência para as máquinas existentes na rede. O objetivo desta
função é evitar a necessidade de se configurar manualmente todas as estações da
rede com a rota default e permitir que uma estação conheça outros roteadores
além do default que possam rotear no caso de falha do principal.
A mensagem é
composta de duas formas: a solicitação de divulgação de uma roteador e o
anúncio de um roteador. O roteador pode ser configurado para enviar
automaticamente as mensagens de anúncio ou fazê-lo apenas comandado por uma
mensagem de solicitação.
A mensagem ICMP
Router Solicitation é mostrada abaixo:

A mensagem ICMP
Router Solicitation é mostrada abaixo:

Esta mensagem pode
conter a divulgação de diversos roteadores iniciada a partir de um que seja
configurado para divulgá-los. O número de preferência é a ordem de preferência
que estes roteadores podem ser utilizados pelas estações.
Em uma estação e em
um roteador, as informações constantes na tabela de rotas podem ser obtidas de
diversas formas.
As rotas podem ser
obtidas por uma estação ou em um roteador de diversas formas, com limitações
dependendo da implementação do TCP/IP em cada sistema operacional:
Estação sem nenhuma
rota. Neste caso, a estação vai precisar de pelo menor um roteador default. A
estação pode obter um roteador default através de:
protocolo ICMP
Router Advertisement
Protocolo BOOTP ou
DHCP durante a etapa de boot ou após ela.
Escuta dos
protocolos de roteamento como RIP e outras para descobrir roteadores
outras, sempre não
respeitando a divisão em camadas
Estação com somente
um roteador default. Com um roteador, a estação já pode operar corretamente. No
caso de existir rotas melhores através de outros roteadores, o roteador default
informará rotas específicas através de ICMP Redirect, sempre específica para
uma estação destino.
Estação com mais de
um roteador default, poderá utilizar os diversos roteadores default, no caso de
falha do primeiro.
Estação com rotas
específicas para outras redes configuradas de forma manual.
Estação executando
algum protocolo de roteamento, geralmente na forma SOMENTE ESCUTA. Desta forma,
a estação pode aprender informações de rotas trocadas entre os roteadores sem
divulgar rotas.
É possível inclusive
ocorrer o recebimento de informações conflitantes ou não idênticas de rotas
para determinadas redes. O roteador resolve estes conflitos com a adoção de
prioridades para rotas aprendidas por meios diferentes. Geralmente, a ordem de
prioridade da forma de aprendizagem das rotas é da seguinte forma:
Rotas configuradas
estaticamente tem maior prioridade, exceto se houver outra rota mais específica
(com máscara mais longa). P. exemplo, um roteador possui uma rota para a rede
200.0.0.0 mas aprende uma rotas específica para 200.0.0.123. Esta última terá
maior prioridade
Rotas específicas
aprendidas por meio de ICMP Redirect e rotas default aprendidas por meio de
ICMP Router Advertisement
Rotas aprendidas por
meio dos protocolos OSPF e BGP
Rotas aprendidas por
meio do protocolo RIP
A figura 1 ilustra a
divisão em camadas da arquitetura TCP/IP:

Esta camada reúne os
protocolos que realizam as funções de transporte de dados fim-a-fim, ou seja,
considerando apenas a origem e o destino da comunicação, sem se preocupar com
os elementos intermediários. A camada de
transporte possui dois protocolos que são o UDP (User Datagram Protocol) e TCP
(Transmission Control Protocol).
O protocolo UDP
realiza apenas a multiplexação para que várias aplicações possam acessar o
sistema de comunicação de forma coerente.
O protocolo TCP
realiza além da multiplexação, uma série de funções para tornar a comunicação
entre origem e destino mais confiável. São responsabilidades do protocolo TCP o
controle de fluxo, o controle de erro, a sequenciação e a multiplexação de
mensagens.
A camada de
transporte oferece para o nível de aplicação um conjunto de funções e
procedimentos para acesso ao sistema de comunicação de modo a permitir a
criação e a utilização de aplicações de forma independente da implementação.
Desta forma, as interfaces socket (ambiente Unix) e Winsock (ambiente Windows)
fornecem um conjunto de funções padrão para permitir que as aplicações possam
ser desenvolvidas independentes do sistema operacional no qual rodarão.
O protocolo UDP
fornece uma forma simples de acesso ao sistema de comunicação, provendo um
serviço sem conexão, sem confiabilidade e sem correção de erros. A principal
função do nível de transporte implementada em UDP é a capacidade de
multiplexação de acesso ao sistema de comunicação. Esta função permite que
vários processos ou programas executando em um computador possam acessar o
sistema de comunicação e o tráfego de dados respectivo a cada um deles seja corretamente
identificado, separado e utilize buffers individuais.
Um processo é o
programa que implementa uma aplicação do sistema operacional, e que pode ser
uma aplicação do nível de aplicação TCP/IP.
A forma de
identificação de um ponto de acesso de serviço (SAP) do modelo OSI é o port de protocolo em TCP/IP. O port é a
unidade que permite identificar o tráfego de dados destinado a diversas
aplicações. A identificação única de um processo acessando os serviços TCP/IP
é, então, o endereço IP da máquina e o port (ou ports) usados pela aplicação.
Cada processo pode utilizar mais de um port simultaneamente, mas um port só
pode ser utilizada por uma aplicação em um dado momento. Uma aplicação que
deseje utilizar os serviços de comunicação deverá requisitar uma ou mais ports
para realizar a comunicação. O mesmo port usado por uma aplicação pode ser
usada por outra, desde que a primeira tenha terminado de utilizá-la.
A forma de
utilização de ports mostra uma distinção entre a parte cliente e a parte
servidora de uma aplicação TCP/IP. O programa cliente pode utilizar um número
de port qualquer, já que nenhum programa na rede terá necessidade de enviar uma
mensagem para ele. Já uma aplicação servidora deve utilizar uma número de port
bem conhecido (Well-known ports) de modo que um cliente qualquer, querendo
utilizar os serviços do servidor, tenha que saber apenas o endereço IP da
máquina onde este está executando.
Se não houvesse a
utilização de um número de port bem conhecido, a arquitetura TCP/IP deveria
possuir um mecanismo de diretório para que um cliente pudesse descobrir o
número do port associado ao servidor. Para evitar este passo intermediário,
utiliza-se números de port bem conhecidos e o cliente já possui pré programado
em seu código o número de port a ser utilizado.
Os números de port
de 1 a 1023 são números bem conhecidos para serviços (aplicações) atribuídos
pela IANA (Internet Assigned Numbers Authority). Os números de 1024 a 65535
podem ser atribuídos para outros serviços e são geralmente utilizados pelas programas
cliente de um protocolo (que podem utilizar um número de port qualquer). Este
conjunto de números tem ainda a atribuição de alguns serviços de forma não
oficial, já que os primeiros 1024 números não conseguem comportar todos os
protocolos TCP/IP existentes.
A figura abaixo
ilustra a multiplexação/demultiplexação realizada pelo protocolo UDP, camada de
transporte:


A mensagem UDP é
representada pela figura acima. O dado carregado é o pacote de nível de
aplicação. UDP acrescenta apenas mais 8 bytes que são o port de protocolo
origem o port de protocolo destino, o tamanho da mensagem UDP e um checksum
para averiguar a correção dos dados do cabeçalho UDP.
O protocolo TCP
trabalha no mesmo nível que o protocolo UDP, mas oferece serviços mais
complexos, que incluem controle de erros e fluxo, serviço com conexão e envio
de fluxo de dados. TCP utiliza o mesmo conceito de port de UDP. Para TCP, uma
conexão é formada pelo par (End. IP. Origem, Port Origem) e (End. IP Destino,
Port Destino).
O protocolo TCP
oferece as seguintes características:
·
Controle de Fluxo e Erro fim-a-fim
·
Serviço confiável de transferência de dados
·
Comunicação full-duplex fim-a-fim
·
A aplicação basta enviar um fluxo de bytes
·
Desassociação entre qtde. de dados enviados pela aplicação e pela camada
TCP
·
Ordenação de mensagens
·
Multiplexação de IP, através de várias ports
·
Opção de envio de dados urgentes
A conexão TCP é ilustrada na figura abaixo:

Uma conexão TCP é formada por três fases: o estabelecimento
de conexão, a troca de dados e o finalização da conexão, conforme ilustrado na
figura abaixo:

A fase inicial de estabelecimento de conexão é formada
de três mensagens, formando o three-way-handshaking, conforme a figura abaixo:

pacote TCP é formado pela mensagem mostrada abaixo:

Estes campos são definidos da seguinte forma:TCP SOURCE PORT: Port origem da mensagem
TCP DESTINATION PORT: Port destino da mensagem
SEQUENCE NUMBER: número de seqüência dos
dados sendo transmitidos face ao conjunto total de dados já transmitidos. Este
número indica a posição do primeiro byte de dados sendo transmitido em relação
ao total de bytes já transmitidos nesta conexão. O primeiro número de seqüência
utilizado não é zero ou um, mas começa de um valor aleatório. Logo se um pacote
está transmitindo do 1234o. byte até o 2000o. byte de uma conexão e o SEQUENCE
NUMBER inicial utilizado nesta conexão foi 10000, o campo SEQUENCE NUMBER
conterá o valor 11234. O sequence number em um sentido da conexão (máquina A
para B) é diferente do sequence number do sentido inverso, já que os dados
transmitidos por um e outro lado são completamente distintos.
ACKNOWLEDGE NUMBER: número que significa o
reconhecimento dos dados recebidos até então no sentido inverso. O ACK de um
sentido é transmitido em piggy-backing no outro sentido. O ACK contém o número
do próximo byte do fluxo de dados recebido, que a origem deste pacote espera
receber da outra máquina. Este valor leva em consideração o número de SEQUENCE
NUMBER inicial praticado pela outra máquina. O valor de ACK informa sempre o
próximo byte ainda não recebido do conjunto contíguo de bytes recebidos do
transmissor.
CODE BITS: São formados por seis
bits, URG, ACK, PSH, RST, SYN e FIN, cuja utilização é mostrada abaixo:
URG: bit de Urgência: significa
que o segmento sendo carregado contém dados urgentes que devem ser lidos com
prioridade pela aplicação. A aplicação origem é responsável por acionar este
bit e fornecer o valor do URGENT POINTER que indica o fim dos dados urgentes.
Um exemplo da utilização desta facilidade é o aborto de uma conexão (por
exemplo por Control-C), que faz com que a aplicação destino examine logo o
pacote até o fim da área de urgência, descubra que houve um Control-C e termine
a conexão.
ACK: bit de Reconhecimento:
indica que o valor do campo de reconhecimento está carregando um reconhecimento
válido.
PSH: bit de PUSH: Este
mecanismo que pode ser acionado pela aplicação informa ao TCP origem e destino
que a aplicação solicita a transmissão rápida dos dados enviados, mesmo que ela
contenha um número baixo de bytes, não preenchendo o tamanho mínimo do buffer
de transmissão.
RST: bit de RESET: Informa o
destino que a conexão foi abortada neste sentido pela origem
SYN: bit de Sincronismo: ë o
bit que informa que este é um dos dois primeiros segmentos de estabelecimento
da conexão.
FIN: bit de Terminação: indica
que este pacote é um dos pacotes de finalização da conexão
WINDOW: Este campo informa o
tamanho disponível em bytes na janela de recepção da origem deste pacote. Por
meio deste valor, o TCP pode realizar um controle adequando de fluxo para
evitar a sobrecarga do receptor. Quando este valor é igual a zero, o
transmissor não envia dados, esperando receber um pacote com WINDOW maior que
zero. O transmissor sempre vai tentar transmitir a quantidade de dados
disponíveis na janela de recepção sem aguardar um ACK. Enquanto não for
recebido um reconhecimento dos dados transmitidos e o correspondente valor de
WINDOW > 0, o transmissor não enviará dados.
OPTIONS: O campo de opções só
possui uma única opção válida que é a negociação do MSS (Maximum Segment Size)
que o TCP pode transmitir. O MSS é calculado através do MTU ou através do
protocolo ICMP Path MTU Discovery.
Há três técnicas
utilizadas pelo TCP para oferecer transferência confiável considerando que o
protocolo utilizado na camada de rede apenas oferece transferência não
confiável:
·
Positive acknowledge (aviso de recebimento positivo)
·
Retransmissão
·
Sliding Window (para aumentar a eficiência)
No mesmo instante
que o host envia um determinado pacote, ele mantém cópia do que enviou, ativa o
timer interno e retransmite o pacote caso o timeout tenha sido alcançado e ele
não recebeu um ack.
Slide Window ou janela
deslizante é a técnica onde o emissor do pacote não necessita ficar aguardando
o ack do receptor para transmitir o próximo pacote, onde existe um timer para
cada pacote enviado.
|
1 2
3 4 5
6 7 8 |
9 10
11 |
Inicial |
|
1 |
2 3
4 5 6
7 8 9 |
10 11 |
Após receber |
|
|
|
|
primeiro ack |
Como o método
utiliza-se de 3 ponteiros para o controle, a implementação de slide window é a
nível de byte. Onde o destinatário acusa o recebimento de “cada byte”, na
realidade o reconhecimento é feito no “último byte recebido +1”, ou seja, o
receptor envia um ack informando qual o próximo byte que ele espera receber.
|
1 2 |
3 4
5 6 7
8 9 10
11 12 |
13 14 |
|
Início dos dados a
serem reconhecidos |
Último dado
transmitido |
Fim da window |
Abaixo está um exemplo de
como é realizado o reconhecimento da recepção:
Remetente:
|
42 A b
c d e f |
48 g h
i j k
l m n |
Destinatário:
|
ACK 48 |
ACK 56 |
O objetivo do
controle de fluxo do TCP é tornar a velocidade de transmissão da máquina fonte
compatível com a velocidade de processamento da máquina destino, como em
qualquer outro sistema de comunicação. A técnica não pode ser implementada de
forma que o destinatário simplesmente "segure" o seu ACK, pois isto
causaria um timeout e consequentemente a retransmissão. A saída é o
destinatário definir um "tamanho de janela" disponível, ou seja,
definir a quantidade de bytes que ele está apto a receber.
Enquanto o
destinatário estiver recebendo os pacotes normalmente, o tamanho da janela vai
aumentando até que chegue no tamanho máximo de janela definido .
|
42 a b
c d e f |
------------------------> |
|
<---------------------- |
ACK
48 / WIN 1024 |
|
48 g h
i j k
l m n |
------------------------> |
|
<---------------------- |
ACK
56 / WIN 1024 |
|
56 o p
q r s t |
------------------------> |
|
<---------------------- |
ACK
62/ WIN 1024 |
O controle de fluxo
ocorre na situação onde o host destinatário começa a não aceitar mais dados e indicando
que o tamanho da janela diminuiu, esse processo ocorrerá até que o host
destinatário comece a aumentar a janela ou até que a janela chegue a zero.
|
<---------------------- |
ACK
42/ WIN 1024 |
|
42 a b
c d e f |
------------------------> |
|
<---------------------- |
ACK
48 / WIN 1018 |
|
48 g h
i j k
l m n |
------------------------> |
|
<---------------------- |
ACK
56 / WIN 1010 |
.
.
.
|
<---------------------- |
ACK
1066 / WIN 0 |
No host origem:
No host destino:
Normalmente uma
extremidade é passiva (um serviço esperando ser chamado- por exemplo, TELNET
SERVER) e a outra extremidade é ativa (um usuário começando uma sessão TELNET).
Para toda conexão as
estações geram o ISM (Initial Sequence Number), utilizando o TCP option para
determinar o tamanho máximo do segmento.
Este protocolos são
agrupados neste capítulo, por fornecerem serviços auxiliares para TCP/IP, tanto
a nível de enlace OSI quanto a nível a de aplicação.
Este protocolos
fornecem aos protocolos TCP/IP, as informações iniciais de configuração da
máquina tais como endereço IP, máscara, roteadores default, rotas, servidores
de Boot, servidores de nome e diversas outras informações. Eles são utilizados
principalmente para realizar a administração centralizada de máquinas TCP/IP e
possibilitar o BOOT de máquinas sem rígido e sem informações iniciais de
configuração. O BOOTP (Bootstrap Protocol) é o protocolo mais antigo e o DHCP
(Dynamic Host Control Protocol) está aos poucos substituindo-o. O BOOTP é
bastante utilizado para o boot inicial de dispositivos de rede, como
roteadores, switches, hubs gerenciáveis, além de estações diskless. O DHCP é um
pouco mais complexo e mais versátil e vem sendo utilizado principalmente para
simplificar a administração de endereços e outros parâmetros de configuração de
grandes instalações de máquinas TCP/IP.
A mensagem BOOTP é
encapsulada em UDP e possui o seguinte formato:

As mensagens BOOTP
Request e BOOTP Reply tem o mesmo formato mas no Request alguns campos não são
preenchidos. Uma estação que deseja obter informações de configuração pode
enviar uma mensagem BOOTP Request por broadcast. Um servidor de BOOTP pré
configurado na rede com os parâmetros de cada cliente, receberá a mensagem e
enviará os dados previamente armazenados para o cliente.


Na área Vendor
Specific da mensagem BOOTP podem ser colocadas uma série de variáveis possíveis
adicionais para configuração da estação cliente de BOOTP. Estas opções são
definidas em RFCs adicionais e servem tanto para BOOTP quanto para DHCP.
DHCP tem como
principal vantagem em relação ao BOOTP a sua capacidade de configuração
automática de estações, sem necessidade de criação de uma tabela de configuração
para cada máquina (com seus parâmetros e endereços MAC respectivos, como é o
caso de BOOTP). Desta forma, um administrador de rede pode configurar as
diversas estações IP existentes na rede de modo genérico, sem especificar uma
tabela para cada uma.
DHCP tem a
capacidade de distribuir endereços de forma dinâmica para as estações, usando
três métodos de fornecimento distintos:
Empréstimo (leasing)
de endereço aleatório por tempo limitado: Neste tipo de fornecimento de
endereço IP, o servidor fornece ao cliente um endereço IP obtido de um conjunto
pré-definido de endereços (por ex. 192.168.0.10 a 192.168.0.90) por um tempo
pré determinado.
Empréstimo de
endereço aleatório por tempo infinito: Neste tipo, o servidor associa um
endereço obtido do conjunto de endereços a um cliente na primeira vez que este
cliente contatar o servidor. Nas demais vezes, será fornecido o mesmo endereço
a este cliente (associado através do endereço MAC), mesmo que as duas máquinas
sejam desligadas e ligadas. Este método simplifica a atribuição de endereços
para uma quantidade grande de máquinas.
Empréstimo de
endereço fixo: Neste tipo de fornecimento, o DHCP opera como o BOOTP, onde há a
associação explícita entre o endereço IP e o endereço MAC da máquina origem,
estipulado em uma tabela de configuração
A mensagem DHCP é
compatível com BOOTP e possui o formato abaixo:

Ao contrário da
mensagem BOOTP que possui apenas dois tipos de comandos (REQUEST e REPLY), a
mensagem DHCP possui 8 tipos de comandos. Este comandos não são colocados no
campo OP, como em BOOTP, mas para manter a compatibilidade, são colocados como
uma opção especial no campo OPTIONS, a de código 53, associado a um dos
comandos abaixo:
DHCP DISCOVER - Enviado pelo cliente para
solicitar uma resposta de algum servidor DHCP
DHCP OFFER - Oferta de endereço IP de
um servidor para um cliente. Um cliente pode receber várias ofertas de
diferentes servidores DHCP
DHCP REQUEST - Requisição de um endereço
específico daqueles oferecidos pelos servidores. É enviado por broadcast apesar
de ser endereçado a um único servidor para que os demais tomem conhecimento da
escolha.
DHCP DECLINE - Informa que a oferta
contêm parâmetros incorretos (Erro)
DHCP ACK - Confirmação do servidor
sobre a atribuição do endereço para a requisição do cliente.
DHCP NAK - Servidor nega o
fornecimento do endereço previamente oferecido, geralmente causado por um erro
ou pelo fato do cliente ter demorado muito a requisitar o endereço solicitado.
DHCP RELEASE - Cliente libera o endereço
IP utilizado. Ë raramente utilizado na prática, pois geralmente o cliente é
desligado sem liberar o endereço. Ele retorna ao conjunto de endereços
disponíveis no servidor devido ao estouro do tempo de leasing.
DHCP INFORM - Cliente que já possui
endereço IP pode requisitar outras informações de configuração respectivas
àquele endereço.
A operação de DHCP
define diversos estados de funcionamento, quando o cliente está executando
alguma ação e enviando uma das mensagens acima:
INITIALIZE
Configura interface com valor zero pois não tem
endereço disponível - 0.0.0.0
Envia DHCPDISCOVER(UDP 67) como broadcast e muda para
estado SELECT. Nesta mensagem, pode colocar opções de configurações desejadas
SELECT
Pode receber uma ou várias mensagens DHCPOFFER, cada
uma com seus parâmetros distintos
Escolhe uma, envia DHCPREQUEST como broadcast e vai
para estado REQUEST
REQUEST
Aguarda até receber DHCPACK do servidor escolhido. Se
não receber, escolhe outra oferta e a solicita
Vai para o estado BOUND.
BOUND
É o estado normal de funcionamento.
Passa a utilizar o endereço, durante o tempo
especificado pelo servidor
Quando o tempo atingir 50%, envia novo DHCPRequest
para o servidor e passa para estado RENEW
Para cancelar o uso da endereço envia DHCPRelease
RENEW
Servidor pode enviar DHCPNAK, DHCPACK ou nenhuma
resposta à solicitação de Request
Se receber ACK, volta para o estado BOUND
Se não receber resposta nenhuma, o cliente envia
DHCPREQUEST em broadcast para que outros servidores possam enviar ofertas.
Se receber DHCPNAK,
libera IP e vai para estado INITIALIZE
As opções DHCP tem o
formato abaixo:
![]()
Código indica o tipo
da opção. Os comandos DHCP tem sempre o código 53 e tamanho 1, sendo o próximo
byte o código específico do comando:
1 = DHCPDISCOVER
2 = DHCPOFFER
3 = DHCPREQUEST
4 = DHCPDECLINE
5 = DHCPPACK
6 = DHCPNACK
7 = DHCPRELEASE
8 = DHCPINFORM
As opções de DHCP e
BOOTP informam dados úteis para as diversas camadas TCP/IP, desde o nível de
Rede ao Nível de Aplicação. Enumera-se algumas abaixo:
Opções Básicas:
Code Param Descrição
Pad - alinhamento
Fim das opções
1 MASK Máscara a ser utilizada pela
estação
3 IP1,
IP2, ... Lista de roteadores
default para a estação
6 IP1,
IP2, … Lista de servidores de DNS
9 IP1,
IP2, … Lista de servidores de
impressão LPR
12 nome Nome da máquina
13 número Tamanho do arquivo de boot
15 nome Nome do domínio
16 IP Endereço do servidor de
swap
17 nome Path
do diretório / da máquina
Opções de DHCP
Code Param Descrição
50 IP Endereço IP requerido
preferencialmente
51 tempo
(s) Tempo de empréstimo de
endereço
53 mensagem Mensagem
DHCP
54 IP Identificação do servidor
DHCP remetente
55 COD1,
… Cliente requisita opções ao
servidor
56 texto Mensagem de erro
57 número Tamanho máximo da mensagem DHCP
58 tempo T1 - Tempo de espera para estado
RENEWING
59 tempo T2
- Tempo de espera para estado REBINDING
Opções de IP
Code Param Descrição
19 1/0 Habilita IP Forwarding na
estação
20 1/0 Habilita Source Routing na
estação
22 número Tamanho máximo do datagrama que
cliente deve receber
23 número Tamanho
do TTL default da máquina
26 número
MTU da interface
27 1/0 Todas as interfaces tem o
mesmo MTU ?
28 IP Endereço de broadcast da
rede
29 1/0 Realizar ICMP Mask Discovery
?
31 1/0 Realizar ICMP Router
Discovery ?
33 IP1/DEST1, IP2/DEST2, .. Rotas estáticas
O protocolo PPP
(Point-to-Point Protocol) é o principal protocolo para o transporte de IP sobre
ligações ponto a ponto, criando um nível de enlace em um meio que não o possua.
O PPP é empregado como protocolo de enlace nos seguintes tipos de meio:
ligações seriais discadas, ligações seriais dedicadas (enlaces telefônicos,
satélite, rádio), ligações ISDN e outras.
Pode-se diferenciar
o funcionamento de PPP em dois grupos principais: quando empregado em ligações
discadas ele provê os mecanismos de autenticação, com a correspondente
interação com os dispositivos para verificar a autenticidade do originador da
chamada, além de que as mensagens trocadas diferenciam o originador da chamada
do receptor da chamada. Quando empregado em ligações dedicadas, geralmente não
são trocadas mensagens de autenticação e o funcionamento do protocolo é
praticamente simétrico em relação às mensagens trocadas.
PPP é genérico
podendo carregar diversos protocolos de nível de rede OSI, além de possuir uma
série de opções que podem ser negociadas pelos dois lados da conexão. PPP provê
três tipos de funcionalidade:
Encapsulamento
Protocolos de
Controle do Enlace PPP (protocolo LCP, PAP, CHAP, LQM)
Protocolos de
Controle do Protocolo de Nível 3 sendo carregado (protocolos IPCP, IPXCP, …)
Encapsulamento de
PPP na verdade não faz parte do protocolo, permitindo que ele se encaixe em
outros protocolos de nível de enlace. O PPP pode utilizar diversos tipos de
encapsulamento compatíveis com HDLC, ISDN e outros. Na sua forma default, o
encapsulamento de PPP é similar ao início de um pacote HDLC, conforma a figura
abaixo:

Os campos FLAG, ADDR e CTRL são similares a HDLC. Os
campos Protocolo, Dados e FCS são comuns a todo pacote PPP. Protocolo contém o
protocolo sendo carregado no campo de dados, sendo por exemplo os valores: LCP = C021, IPCP = 8021, IPXCP = 802B, PAP
= C023, CHAP = C223, LQR = C025, IP = 0021, IPX = 002B, Bridging NCP = 8031,
Netbios = 803F, ...
encapsulamento dos
diversos protocolos sobre PPP é mostrado na figura abaixo:

Este protocolo
controla o enlace PPP. O formato de sua mensagem é dado abaixo:
![]()
Comando pode ser um
dos seguintes tipos:
Configure-Request:
Solicita o aceite para as opções especificadas no campo de dados
Configure-Ack:
Concorda com as opções, para serem utilizadas pelo outro lado
Configure-Nack:
Rejeita as opções, enumerando-as no campo de dados
Configure-Reject:
Rejeita as opções que não possuem um campo de valor
Terminate-Request:
Informa o fim da conexão PPP
Terminate-Ack:
Concorda com o fim da conexão
Code-Reject: Informa
erro no código do comando LCP
Protocol-Reject:
Informa erro no protocolo da mensagem PPP
Echo-Request
Echo-Reply
Discard-Request
A troca de dados em
uma conexão PPP é realizada conforme a figura abaixo. Os comandos de
configuração do link PPP (LCP) são trocados com o objetivo de estabelecer os
parâmetros de operação da ligação. Após o
acordo dos comandos de configuração, são passados os comandos de
configuração do protocolo de dados (IPCP) e, após estes, são finalmente
passados os pacotes do protocolo IP.

As opções de
configuração LCP mais utilizadas são:
Maximum Receive Unit
Authentication
Protocol
Quality Protocol
Magic Number
Protocol Field
Compression
Address Control
Field Compression
Em ligações discadas
é comum os servidores de acesso remoto possuírem a opção de detecção automática
de PPP. Neste caso, como, geralmente os primeiros pacotes PPP trocados são os
Configure-Request, basta que o receptor verifique se os dados correspondem aos
códigos deste comando e, então, iniciem automaticamente o PPP.
Os comandos
possíveis no protocolo IPCP são:
Configure-Request:
Solicita o aceite para as opções especificadas no campo de dados
Configure-Ack:
Concorda com as opções, para serem utilizadas pelo outro lado
Configure-Nack:
Rejeita as opções, enumerando-as no campo de dados
Configure-Reject:
Rejeita as opções que não possuem um campo de valor
Terminate-Request:
Informa o fim da troca de dados IP
Terminate-Ack:
Concorda com o fim da troca de dados
Code-Reject: Informa
erro no código do comando IPCP
Este comandos são
trocados de forma semelhante ao LCP, sendo que ao término da fase de acordo do
IPCP, passam os dados do protocolo IP.
As principais opções
de configuração de IPCP são:
IP Compression
Protocol: Informa se será utilizado algum protocolo de compressão (e qual) para
o cabeçalho IP
IP Address: origem
informa ao destino o endereço IP a ser utilizado pela origem. No caso de conter
0.0.0.0 (que ocorre tipicamente na estação que realiza uma ligação serial
discada), o outro lado (neste caso o servidor de acesso remoto) fornece o
endereço IP a ser utilizado pela origem, através do comando Configure Nack.
As possíveis formas
de negociação de endereço IP são dadas pela figura abaixo:

SLIP fornece apenas
o encapsulamento para um enlace serial. Sua mensagem é dado na forma abaixo:

funcionamento de
SLIP ocorre da seguinte forma:
Transmite ESC
Transmite datagrama, caracter por caracter,
substituindo um ESC nos dados por ESC ESC
Transmite END
A interface de
socket do Unix é um conjunto de funções para permitir a utilização do sistema
de comunicação por processos (programas) neste sistema operacional. A interface
Winsock é composta de funções semelhantes a socket, para o ambiente Windows.
A interface socket
possui funções distintas para a comunicação com e sem conexão.
A utilização das
funções de socket para a comunicação sem
conexão é dada abaixo:

A utilização destas
funções é dada abaixo:
socket: Inicializa a
estrutura de dados do socket (equivalente ao SAP - Ponto de acesso de serviço),
determinando qual o protocolo (PF_INET = TCP/IP) e o tipo do serviço (DGRAM =
UDP e STREAM = TCP)
bind: associa o
socket a um port UDP ou TCP - pode-se dizer que para o programador, o port do
protocolo TCP ou UDP é efetivamente o socket.
sendto: solicita ao
sistema de comunicação o envio de dados, especificando o endereço IP destino e
o port destino, além dos próprios dados.
recvfrom: informa ao
sistema de comunicação que o programa está aguardando dados. O programa será
congelado enquanto não houverem dados para receber, sendo reativado quando
chegarem dados.
close: desassocia o
port do socket e desativa o socket.
Deve-se observar que
nem todas as funções geram mensagens de rede. De fato, apenas a função sendto
gera uma mensagem.
A sintaxe destas
funções é mostrada abaixo:
sock1 = socket (pf, type, protocol)
pf =
PF_INET | PF_APPLETALK | PF_NETW | PF_UNIX
type =
SOCK_STREAM | SOCK_DGRAM | SOCK_RAW | SOCK_RDGRAM
close (sock1)
bind (sock1, localaddr, addrlen)
localaddr
= struct {ADDR_FMLY, PROTO_PORT, IP_ADDR}
sendto (sock1, message, length, flags, destaddr,
addrlen)
recvfrom (sock1, buffer. length, flags, fromaddr,
addrlen)
nptr = gethostbyname (name)
nptr =
struct {name, aliases, address_type, address}
nptr = gethostbyaddr (addr, len, type)
sptr = getservbyname (servname, proto)
sptr = struct {name,
protocol, port)
No caso de comunicação
utilizando conexão, a utilização das funções é dada na figura abaixo:

A sintaxe das
funções adicionais é dada abaixo:
connect (sock1, destaddr, addrlen)
destaddr
= struct {ADDR_FMLY, PROTO_PORT, IP_ADDR}
write (sock1, data, length)
read (sock1, buffer, length)
listen (sock1, qlength)
newsocket = accept (sock1, addr, addrlen)
ready = select (ndesc, indesc, outdesc, excdesc,
timeout)
ndesc = numero de descritores a serem examinados
indesc = descritores examinados
excdesc = descritores examinados para exceção
timeout = tempo
máximo de espera
Os protocolos de
aplicação TCP/IP são aqueles que realizam as funções de alto nível e que
utilizam os serviços da camada de transporte UDP ou TCP para a comunicação.
Os protocolos de
aplicação podem realizar funções diretamente acessíveis pelo usuário como FTP,
HTTP, SMTP, POP3, IMAP4, Finger, Telnet, Chat, NFS, TFTP, NNTP e outros. Além
disto, podem também realizar funções mais próximas do sistema de comunicação,
tais como os protocolos DNS, BOOTP, DHCP, SNMP, BGP4, e outros.
As aplicações são
ilustradas na figura abaixo:

O protocolo DNS
(Domain Name System) especifica duas partes principais: regras de sintaxe para
a definição de domínios e o protocolo utilizado para a consulta de nomes.
DNS é basicamente um
mapeamento entre endereços IP e nomes. A abordagem inicial para este mapeamento
era a utilização de nomes planos, ou seja, sem hierarquia. Esta abordagem
possui limitações intrínsecas quanto a escalabilidade e a manutenção. O sistema
de nomes utilizado na Internet tem o objetivo de ser escalável, suportando a
definição de nomes únicos para todas as redes e máquinas na Internet e permitir
que a administração seja descentralizada.
A estrutura de nomes
na Internet tem o formato de uma árvore invertida onde a raiz não possui nome.
Os ramos imediatamente inferiores à raiz são chamados de TLDs (Top-Level Domain
Names) e são por exemplo .com, .edu., .org, .gov, .net, .mil, .br, .fr, .us,
uk, etc… Os TLDs que não designam países são utilizados nos EUA. Os diversos
países utilizam a sua própria designação para as classificações internas. No
Brasil, por exemplo, temos os nomes .com.br., .gov.br, .net.br, .org.br e
outros.
Cada ramo completo
até a raiz como, por exemplo, impsat.com.br, saraiva.com.br, nasa.gov, e outros
são chamados de domínios. Um domínio é a área administrativa englobando ele
próprio e os subdomínios abaixo dele. Por exemplo o domínio .br engloba todos
os subdomínios do Brasil. O domínio impsat.com.br tem a responsabilidade por
todos os domínios abaixo dele.
A delegação de
responsabilidade de um domínio é a capacidade do DNS de simplificar a
administração. Ao invés do domínio .br ser responsável diretamente por todos os
seus subdomínios e os que vierem abaixo deles, há na verdade uma delegação na
atribuição de nomes para os diversos subdomínios. No exemplo abaixo, a empresa
Techno possui a responsabilidade de administração do domínio impsat.com.br.
A hierarquia de
domínios pode ser observada na figura abaixo:

Os domínios
principais genéricos, chamados de GTLDs (Generic Top Level Domain Names) que
são .net, .com e .org são administrados pelo InterNIC (Internet Network
Information Center) que também é responsável pela administração do espaço de
endereçamento IP. Recentemente foram criados novos nomes de domínio genéricos
que serão utilizado a partir de 98. São eles: .firm, .store, .web, .arts, .rec,
.infor, .nom.
Os domínios são
completamente independentes da estrutura de rede utilizada. Não existe
necessariamente algum relacionamento entre eles. O DNS possui uma estrutura
inversa para poder representar o endereçamento de rede, ou permitir que seja
feito o mapeamento do endereço IP correspondente a um nome. Esta estrutura possui
como raiz principal a notação .arpa e possui como único ramo o .in-addr. Abaixo
deste são colocados em ordem os bytes do endereço IP.
DNS é implementado
por meio de uma aplicação cliente-servidor. O cliente é o resolver (conjunto de rotinas em uma implementação de TCP/IP que
permite a consulta a um servidor) e um servidor geralmente é o programa bind ou uma implementação específica de
um servidor de DNS (Windows 2000).
Um servidor de DNS
pode ser responsável pela resolução de uma ou mais nomes de domínios (ex.
impsat.com.br, presid.impsat.com.br). Seu escopo de atuação define a Zona de
atuação de um servidor DNS. Por exemplo, para resolver o domínio impsat.com.br
e seus subdomínios existem três zonas: a primeira resolve o próprio domínio
principal e os subdomínios net.impsat.com.br e internet.impsat.com.br; a
segunda resolve os domínios engen.impsat.com.br e proj.engen.impsat.com.br; e a
terceira resolve o domínio lab.engen.impsat.com.br. Cada zona possui um
servidor de nomes principal ou primário, que mantêm em tabelas o mapeamento dos
nomes em endereços IP daquele domínio. Uma zona pode ter servidores secundários
que possam substituir os primários em caso de falha. Os secundários, entretanto
não possuem fisicamente as tabelas de mapeamento mas carregam regularmente as
informações do primário.
Veja figura abaixo:

Por outro lado, a
representação do domínio reverso .in-addr.arpa para uma das máquinas de
proj.engen.impsat.com.br é visto abaixo:

A resolução de um
nome é realizada de forma recursiva, consultando diversos servidores de nome
até chegar àquele responsável pelo domínio consultado. Por exemplo a resolução
do endereço www.lab.engen.impsat.com.br,
será realizado pelo servidor da zona responsável por
lab.engen.impsat.com.br.

No RADIUS existem 5 tipos de
serviços ao usuário que podem ser definidos. São eles:
·
Login-User
·
Framed-User
·
Dialback-Login-User
·
Dialback-Framed-User
·
Outbound-User
Login User
Quando definido, este campo
especifica que o usuário terá acesso direto ao servidor ou à rede, de acordo
com o seu username e o password.
Framed-User
Quando especificado, este
campo indica que o usuário possui permissão para fazer uma conexão SLIP ou PPP.
Como opção, os campos Framed-Protocol,
Framed-Address e Framed-Netmask deverão também ser especificados. Os campos Framed-Routing e Framed-Compression também poderão ou não ser definidos.
Dialback-Login-User
Quando definido, este campo
informa que o usuário deverá ter a ligação retornada (dialback) para um
determinado número de telefone, de acordo com seu username e o password.
Dialback-Framed-User
Quando definido, este campo
especifica o usuário como tendo permissão de se co_nectar usando SLIP ou PPP e
de ter a ligação retornada. O número de telefone para discagem e demais
informações associadas são mantidos na Tabela de Localização.
Outbound-User
Quando definido, este
usuário será autenticado pelo RADIUS quando estiver usando uma conexão externa
via modem.
Esta sessão contém o
dicionário de tradução para parsing o pedido do RADIUS e gerar uma resposta.
Todas as transações são composta por atributos/pares de valores. Os valores
devem ser guardados no arquivo de usuários de forma a facilitar a sua
administração. O formato para todos os entries , exceto o userid, é:
attribute=<value>
User-Name
Este string denota o usuário
(login name) a ser autenticado.
Password
Este string possui um par de
valores que pode ser quotado como uma senha em texto puro contido no arquivo de
usuários ou um valor citado do Unix, que força o RADIUS a usar o /etc/passwd no
sevidor RADIUS ou, se o NIS estiver sendo usado, pedir ao servidor NIS pela
autenticação da senha.
Client-Id
Este campo, que deve ser sua
notação compatível com a internet (ou seja, com ".'), contém o endereço IP
do PortMaster que é usado na autenticação de um usuário.
Client-Port-Id
Este campo identifica uma
porta PortMaster que é usado na autenticação de um usuário.
Framed-Protocol
Este campo é usado para
identificar o usuário como um usuário SLIP ou PPP. O padrão para o User Type of
Network User é o protocolo PPP.
Framed-Address
Este campo é usado para
especificar o endereço IP do destinatário ou o nome do servidor autenticado do
usuário da rede. Se o PortMaster estiver configurado para usar endereços
pré-configurados, a ação padrão será designar um endereço para o usuário, ou
então o PortMaster irá negociar o endereço.
Framed-Netmask
Este campo é usado para
especificar o netmask destino de um usuário autenticado. O netmask padrão é
255.255.255.255
Framed-ipxnet
Este campo é usado para
especificar o número da rede IPX de um usuário autenticado. Este número deve
estar no formato HEX
Framed-Routing
Este campo define as opções
de roteamento RIP. Existem quatro possíveis valores que podem ser especificados
aqui. O default é None. A descrição
das opções são as seguintes:
None
Se o valor especificado for
None ou for omitido, os pacotes RIP (Routing Infor_mation Protocol) estarão
desabilitados no Dial In do usuário.
Broascast
Se um broadcast é
especificado, os pacotes padrão RIP terão permissão para serem mandados através
da interface.
Listen
Se a especificação for
Listen, os pacotes padrão RIP terão permissão para serem recebidos através da
interface
Broadcast-Listen
Se esta for a especificação
do campo, os pacotes RIP terão permissão para trafegarem em ambas as direções.
Framed-Filter-Id
Este campo identifica o
filtro de pacotes que será configurado no PortMaster pelo qual o usuário estará
acessando a rede. Se um usuário puder acessar múltiplos PortMaster numa rede,
cada PortMaster deverá ter filtros idênticos instalados. Note que ao se
especificar um nome neste campo ele será mapeado no formato ID.in ou ID.out dependendo se o que estiver definido for um filtro de
entrada ou de saída. Se o Framed-Filter-ID
estiver nomeado como, por exemplo, FredFilter,
internamente o PortMaster usará um filtro denominado FredFilter.out.
Framed-MTU
Este campo especifica a
unidade máxima de transmissão permitida através do conec_tor serial da rede. O
valor máximo para o SLIP é de 1006 bytes, enquanto o PPP suporta um MTU de até
1500. O default é 1500 bytes.
Framed-Compression
Este campo especifica se a
compressão Van-Jacobson será ou não utilizada. Os valores possíveis são Van-Jacobson TCP-IP ou None. Caso o protocolo padrão seja o PPP
o default para a compressão será On.
Login-Host
Este campo identifica o
sevidor no qual um usuário está conectado.
Login-Service
Este campo possui quatro
possíveis configurações. São elas:
Telnet
Usa o protocolo telnet
(porta 23 por default) para estabelecer uma conexão com o servidor;
Rlogin
Usa o protocolo rlogin
(porta 513 por default) para estabelecer uma conexão;
TCP-Clear
Usa o protocolo PortMaster
Netdata (porta 6000 por default) para estabelecer a conexão;
PortMaster
Usa o protocolo PortMaster
pmd (porta 1642) para estabelecer a conexão;
Login-TCP-Port
Quando definido, este campo
é usado para forçar a conexão do usuário para uma porta TCP especificada (tal
como a porta 23, default para o telnet).
Dialback-No
Este campo deve ser definido
de forma a utilizar a facilidade de dialback no PortMaster. É um string que
contém o número de telefone a ser discado pelo PortMaster depois de uma
autenticação bem sucedida.
Expiration
Este campo numérico
especifica a quanto tempo falta antes de uma senha expirar. É expresso como December 12, 1999 por exemplo.
Framed-Route
Este campo permite a
especificação de uma rota única. Poderá haver tantas Framed-Routes quantas
necessárias para uma conexão remota. O formato deste atributo é:
Framed-Route=destination gateway metric
onde:
destination é o servidor ou a rede de destino;
gateway é o node que informa a rota para o servidor ou à rede;
metric
é o custo (ou hot-count) para o gateway.
Se a conexão for configurada
para usar um endereço pré-configurado ou se o endereço for negociado, a notação
0.0.0.0 fará com que o gateway seja aprendido.
O arquivo de usuários
(localizado no diretório /etc/raddb por default) usa atributos/pares de valores
providos pelo arquivo de dicionário. Este arquivo pode ser modificado, mas não
é recomendado a menos que você realmente entenda o funcionamento do RADIUS.
Em seguida estão alguns
exemplos de como o arquivo de usuários pode ser configurado usando algumas das
facilidades do servidor RADIUS:
Login-User:
fabio Password =
"UNIX"
User-Service-Type =
Login-User,
Login-Host = powerhost,
Login-Service = PortMaster
No exemplo acima, a
identificação do login fabio tem sua
senha mantida ou em /etc/passwd ou através do NIS. Este usuário pode
literalmente se logar (no prompt login:) como fabio. O servidor padrão será um servidor o qual pode ser look up
com sucesso através de /etc/hosts ou um nome tal como NIS, DNS. O RADIUS também
suporta segurança nível C2. Finalmente, o login-Service do usuário fabio é
definido como PortMaster.
Note que a linha de
username/password não possui vírgula em seguida enquanto que as outras possuem.
Isso acontece porque a primeira linha contém os itens de autenticação enquanto
que as linhas restantes são conhecidos como itens de resposta. Além disso, a
última linha também não possui a vírgula inficando o final do entry.
Dialback-Login-User
bfabio Password
="something"
User-Service-Type =
Dialback-User,
Dialback-No =
"18005551212",
Login-Host = powerhost,
Login-Service = PortMaster
No exemplo acima, note que o
password é something. Este é o string
que o usuário fabio colocou como sendo a sua senha no prompt password. Exceto
pelo Dialback-User e o Dialback-No, o usuário não é tratado
diferentemente do que o exemplo anterior.
Framed-User
sfabio Password =
"UNIX', Client-Id=portmaster1, Client-Port-Id=1
User-Service-Type =
Framed-User,
Framed-Protocol = SLIP,
Framed-Address =
199.199.1.50,
Framed-Netmask =
255.255.255.0,
Framed-Routing = None,
Framed-Compression =
Van-Jacobsen-TCP-IP,
Framed-MTU = 1006
No exemplo acima, o usuário
SLIP com a identificação sfabio tem seu password gravado ou em /etc/passwd ou
no NIS e tem o SLIP como sendo o protocolo definido. As configurações Client-Id e Client-Port-Id forçam fabio a ter acesso somente à porta S0 do portmaster1.
Além disso, o endereço de destino foi configurado como 199.199.1.50 e o netmask
como 255.255.255.0. O netmask deverá ser igual àquele da rede de destino.
Configurando o Framed-Routing = None,
nenhum pacote padrão RIP será mandado ou recebido através da interface; note
que se o Framed-Routing não fosse
incluído, nenhum pacote RIP poderia ser mandado ou recebido através da
interface. Ao se colocar a linha Framed-Compression,
a compressão Van Jacobsen foi abilitada. Finalmente, a unidade máxima de
transmissão (MTU) foi configurada para 1006, que é a máxima permitida pelo
protocolo SLIP.
Dialback-Framed-User
sbfabio Password =
"UNIX"
User-Service-Type =
Dialback-Framed-User,
Dialback-Name =
"f_location",
Neste exemplo, o usuário
sfabio é definido como um usuário do tipo Dialback-Framed
usando o protocolo SLIP. O campo Dialback-Name
é usado para especificar o nome da Tabela de Localização a ser usada para
discar para o local onde se encontra o usuário.
O arquivo de
clientes é um arquivo de formato:
Nome_PortMaster Chave_Criptografia
onde: Nome_PortMaster é o nome do PortMaster que
está usando o RADIUS;
Chave_Criptografia é o
segredo do RADIUS que está sendo usado por aquele PortMaster.
Exemplo:
O arquivo client se encontra
no diretório /etc/raddb do servidor RADIUS.
A Internet é organizada numa estrutura contendo um conjunto de
domínios separados, denominados Autonomous
Systems – AS. Um Sistema Autônomo consiste
em um grupo de redes e gateways
relativamente homogêneos controlados por uma única autoridade administrativa.
Dentro desse ambiente,
identificam-se então, dois tipos de
gateways: Interior Gateways (IG) e
Exterior Gateways (EG). Diz-se que dois gateways são IG quando pertencem a
um mesmo AS. O protocolo de roteamento executado entre IG, denominado Interior Gateway Protocol (IGP), é de
propriedade do AS não necessita ser executado pelos gateways fora do AS. No caso simples, um sistema autônomo pode
consistir em sistema em somente um gateway
conectado, por exemplo, uma sub-rede ao Sistema
Core. Este gateway é chamado stub
gateway, uma vez que seu único objetivo é o de fornecer uma interface entre
tal sub-rede e o Backbone Internet.
Por outro lado, diz-se dois gateways são Exterior Gateways (EG)
quando pertencem a diferentes AS. O protocolo de roteamento executado entre EG
é denominado Exterior Gateway Protocol
(EGP).
Conforme citado em
capítulos anteriores, o IP possui vários mecanismos para obter informações para
sua tabela de rotas (específicas de cada máquina). A tabela de rotas de IP pode
ser preenchida por meio de:
Rotas default por
meio de configuração estática (manual)
Rotas específicas
por meio de configuração estática (manual)
Rotas default por
meio do protocolo ICMP Router Advertisement
Rotas específicas
para estação por meio de ICMP Redirect
Rotas aprendidas
dinamicamente por meio de protocolos de roteamento (ex. RIP, OSPF, BGP-4)
A última forma de
aprendizado se aplica normalmente aos próprios roteadores, quando situados em
redes complexas, já que suas tabelas de rota devem conter os detalhes de
roteamento da rede (Uma estação por outro lado, pode ter rotas para um único
roteador default e aprender rotas melhores por meio de ICMP Redirect).
O protocolo RIP é do
tipo Vetor de Distância pois baseia a escolha de rotas por meio da distância em
número de roteadores. O funcionamento do protocolo RIP é bem simples,
consistindo na divulgação de rotas de cada roteador para seus vizinhos
(situados na mesma rede).
Cada roteador
divulga sua tabela de rotas através de um broadcast na rede. Os demais
roteadores situados na mesma rede recebem a divulgação e verificam se possuem
todas as rotas divulgadas, com pelo menos o mesmo custo (custo é a quantidade
de roteadores até o destino).
Se não possuírem
rota para determinada rede divulgada, incluem mais uma entrada na sua tabela de
rotas e colocam o roteador que a divulgou como o gateway para aquela rede. Em
seguida, sua própria divulgação de rotas já conterá a rota nova aprendida. Este
processo se repete para todos os roteadores em um conjunto de redes, de modo
que, após várias interações, todos já possuem rotas para todas as redes. Uma
rota aprendida é mantida enquanto o roteador que a originou continuar
divulgando. Caso o roteador pare de divulgar a rota ou nenhuma mensagem de
divulgação seja recebida dele, o roteador que havia aprendido a rota a mantêm
por 160 segundos, findos os quais a rota é retirada da tabela de rotas. Neste
caso, se outro roteador divulgar uma rota para aquela rede específica, esta
será utilizada.
No caso em que um
roteador, recebe rotas para uma mesma rede divulgadas por roteadores
diferentes, a com menor custo é usada, sendo as demais descartadas.
O protocolo RIP não
possui suporte para sub-rede (máscara de rede), o que só vem a ser suportado no
protocolo RIPv2.
O custo de uma rota
é a quantidade de roteadores que uma mensagem terá que atravessar desde o
roteador que possui a rota até a rede destino. O custo máximo em RIP tem o
valor de 16, que significa infinito. Por isto, o diâmetro máximo de uma rede
com protocolo RIP é de 14 roteadores.
A mensagem RIP tem o
seguinte formato:

Nesta mensagem, as
rotas divulgadas por cada roteador são incluídas na parte IP ADDRESS OF NET X
….
As figuras abaixo
mostram a divulgação de rotas por meio do protocolo RIP. Os roteadores divulgam
e recebem informações de rotas via RIP, enquanto as estações apenas aprendem as
rotas (RIP passivo).
Roteador G1 divulga
sua tabela de rotas, que inicialmente contêm apenas as rotas diretas, para as
redes ligadas diretamente.

O roteador G2,
possui rotas para as redes ligadas diretamente, mas recebe um pacote de
divulgação de rotas de R1, com uma rede nova (Rede 1). O roteador G2 instala a
rota nova na sua tabela de rotas.

O Roteador G2
divulga suas rotas para as redes ligadas diretamente, incluindo a rota nova
aprendida de G1. G1, recebendo esta divulgação, instala uma rota nova para a
Rede 3.

O protocolo RIP
possui problemas intrínsecos de loop e convergência. O problema de convergência
ocorre no seguinte caso:

O roteador R2 havia
aprendido uma rota para a Rede A, através de R1. Tanto R1 quanto R2 divulgam de
30 em 30 segundos a sua tabela de rotas por meio de RIP. No funcionamento
normal, se R1 perder a rota para a Rede A, o roteador R1 divulgará uma mensagem
RIP contendo uma rota para a Rede A com custo infinito (=16). O roteador R2, ao
receber esta rota, verificará que ela veio de R1, de onde havia aprendido a
rota para a rede A. Ele então procederá como determina o protocolo RIP e
colocar a rota também com custo = 16.
Entretanto se,
quando R1 perder a rota para a Rede A,
R2 enviar sua tabela de rotas por RIP antes que R1 o tenha feito, R1 verificará
que R2 possui uma rota melhor que ele para a rede A, com custo = 2 (já que R2
enviaria por meio de R1). R1 então instala uma rota para a rede A com custo =
3, sendo R2 o gateway da rota. Na
próxima divulgação de R1, R2 constatará uma rota para a rede A com custo = 3.
Ele então atualizará sua própria rota (já que a havia aprendido de R1), com
custo = 4. A próxima divulgação de R2, causará a respectiva alteração do custo
da rota em R1 para 5. Isto ocorre até que o custo desta rota atinja o valor 16.
O problema de
convergência pode ser reduzido adotando-se as seguintes técnicas:
split -horizon update: não divulga rotas de volta para a interface de
onde recebeu a informação de rota
hold-down: não
aceita por 60s informações sobre uma rede após ela ser dada como não
-alcançável
poison-reverse:
divulga rotas de volta para a interface de onde recebeu a rota, mas com métrica
16 (não -alcançável e mantém este estado durante um tempo mínimo, mesmo
recebendo rota para a rede
riggered-updates:
força um roteador a divulgar imediatamente as rotas quando recebe rede
não-alcançável
O protocolo RIP2 é
bastante semelhante ao RIP, com as
seguintes adições:
As rotas contêm a
máscara da rede destino, permitindo divulgar rotas para sub-redes
O protocolo pode ser
autenticado, adicionando segurança
RIP2 pode carregar
informações de outros roteadores adjacentes, que funcionam com outros
protocolos (como OSPF e BGP-4)
A mensagem RIP é
mostrada abaixo:

O protocolo OSPF Open
Shortest-Path-First Protocol foi
elaborado por um grupo de trabalho da Internet Engineering Task Force com o
propósito de atender às exigências de roteamento de grandes redes, ou seja, um
IGP para sistemas autônomos de porte. É um protocolo que usa o algoritmo SPS e
compreende uma série de facilidades adicionais listados a seguir, as quais
permitem diminuir a sobrecarga necessária para a manutenção da topologia
atualizada de uma rede internet:
·
roteamento levando em consideração o tipo de serviço;
·
balanceamento de carga entre rotas de mesmo tamanho;
·
participação dos gateways e
redes em subgrupos denominados áreas, sendo a topologia de uma área conhecida
apenas dentro da mesma, facilitando o crescimento modular do AS ;
·
definição da topologia de rede virtual que abstraia detalhes de rede
real;
·
divulgação e informações recebidas de exterior gateways. O formato da mensagem permite distinguir
informações recebidas de fontes externas daquelas recebidas dentro do AS.
O protocolo OSPF é baseado
nas mensagens: Hello, Database
Description, Link Status Request e Link Status Update. Quando um gateway OSPF é inicializado, sua
primeira ação é contatar os gateways vizinhos,
através de mensagens Hello. Os
gateways trocam mensagens entre si para eleger o gateway mestre (DR
-Designated Router). Este gateway torna-se
responsável pela notificação de informações de roteamento a todos os gateways presentes na rede (gateways secundários). Nos protocolos de
roteamento discutidos anteriormente todos os gateways enviavam e recebiam informações de roteamento, gerando
tráfego excessivo. A figura de um gateway
mestre, com o função de gerador/distribuidor de informações, reduz
significativamente o tráfego relativo às mensagens de roteamento, que são
trocadas somente entre o gateway
mestre e os demais gateways secundários.
OSPF usa o roteamento link state. As informações de roteamento
trocados entre gateways, através da
mensagem Database Description,
indicam o estado e o custo associado às interfaces e aos gateways vizinhos. Estas mensagens são confirmadas pelos gateways
que a recebem. Como as bases podem ser grandes, uma base de topologia pode
gerar várias mensagens. A mensagem Link
Status Request é usada por um gateway na requisição de dados atualizados a
outro gateway. Na mensagem Link Status Update é usada por um gateway no envio de informações sobre o
estado de seus enlaces.
Uma vez estabelecido o gateway mestre da cada sub-rede internet , realizada a troca de informações de roteamento entre o gateways mestres das várias sub-redes em que esteja conectado, o
gateway monta a sua base de dados de roteamento. O algoritmo SPF é, então
executado a partir dessa base e, como resultado, é obtida uma árvore de
roteamento com o gateway na raiz,
indicando a conectividade com outras redes. A partir dos dados de custo, são
calculados os custos totais das rotas até cada sub-rede da internet.
Com o crescimento da
Internet, o uso do EGP tornou-se limitado. Existia a necessidade de acrescentar
funções de policiamento no roteamento e o protocolo devia suportar topologias
complexas. Consequentemente surgiu o BGP - Border Gateway Protocol, para suprir
as deficiências do EGP no roteamento entre sistemas autônomos.
Roteadores com BGP se
preocupam com critérios políticos de roteamento. Um sistema autônomo (SA) deve
querer habilidade de enviar pacotes para algum site e receber pacotes de outro
site de seu interesse. Entretanto, ele não deve gostar de conduzir pacotes
entre sistemas autônomos (AS's) que não seja de seu interesse. Por exemplo,
companhias telefônicas devem atuar como portadora de seus clientes, mas não dos
outros.
protocolo BGP foi projetado
para permitir muitos critérios de roteamento a serem aplicadas no tráfego entre
AS's. Critérios típicos envolvem considerações de ordem política, de segurança,
ou econômicas. Alguns exemplos de limites de roteamento são: nunca coloque o
Iraque na rota para o Pentágono; tráfego iniciando ou terminando na IBM, não
trafega para Microsoft.
Os critérios são
configurados manualmente em cada roteador BGP.
Do ponto de vista do
roteador BGP, o mundo consiste de outros roteadores BGP interconectados. Dois
roteadores BGP são considerados conectados se eles compartilham uma rede comum.
Dado o interesse de um BGP especial no tráfego, as redes são agrupadas em três
categorias. A primeira categoria é stubs networks, na qual somente tem
conexão para um roteador BGP. Estas não podem ser usadas para trânsito na rede,
porque só tem uma ligação. A segunda é as redes multiconnected networks.
Podem ser usadas para tráfego em trânsito, exceto se recusarem. Finalmente,
existem as redes transit networks, como um backbone, que estão dispostas a
manipular pacotes de outros, possivelmente com algumas restrições.
Pares de roteadores BGP se
comunicam através de conexões TCP. Operando deste modo eles fornecem uma
comunicação confiável e escondem os detalhes da rede que os pacotes estão
passando.
BGP é um protocolo que usa o
algoritmo vector distance, mas com
uma pequena diferença. Ao invés de manter a distância de cada destino, cada
roteador BGP mantém o caminho usado. Similarmente, ao invés de periodicamente
dar a cada vizinho a distância estimada para cada possível destino, cada
roteador diz a seus vizinhos o caminho exato que está usando.
BGP facilmente
resolve o problema de contagem infinita que causa problema a outros algoritmos
de roteamento.
vector-distance, uma diferente estratégia de podar a árvore deve ser seguida. O
algoritmo básico é o reverse path
forwarding. Entretanto, quando um roteador que não faz parte do grupo,
recebe uma mensagem multicast, ele responde para que o emissor não envie mensagens
para ele.
Uma desvantagem deste
algoritmo é que para grandes redes muita memória é necessária. Supor que uma
rede tem n grupos, cada um com a média de m membros. Para cada
grupo, m spanning trees
podadas são armazenadas, para um total de m.n árvores. Quando muitos grupos
grandes existem, é gasto muito memória para armazenar as árvores.
Uma alternativa é usar
árvores chamadas core-base tree. Aqui
uma única árvore spanning tree por
grupo é computada, com a raiz ("the core") perto do meio do grupo. Para
enviar uma mensagem multicast, uma
estação envia-a para a raiz, que então envia para os nós do grupo. Embora esta
técnica não seja ótima, ela reduz os custos de armazenagem de m
árvores para uma árvore por grupo.
O BGP é um protocolo de roteamento dinâmico externo
empregado entre dois Autonomous Systems distintos, fazendo assim uma rede ser
multihomed, ou seja, estar conectada a mais de uma rede autônoma.
Pré-requisito para a implantação de BGP-4:
- Possuir Classe CIDR adquirida junto à FAPESP/Comitê
Gestor (http://registro.fapesp.br/ip.html)
- Possuir Autonomous Systems Number adquirido junto à
ARIN (http://www.arin.net/initial-isp.html)
Roteamento:
Os roteadores CISCO sempre dão preferência a rotas mais
específicas do que outras mais genéricas.
O BGP-4 envia e divulga rotas do seu A.S., dos seus
clientes, e também de toda a Internet, dependendo da necessidade.
Que tipo de rota divulgar?
Ø
Rotas default:
Permite à rede multihomed evitar a manutenção de
informações detalhadas de roteamento (filtragem das rotas recebidas ou
transmitidas, manipulação de custos das rotas, e até a alocação de memória para
receber rotas).
A rota default é propagada para algum protocolo de
roteamento dinâmico interno - IGP, tal
qual OSPF, EIGRP ou RIP (são os mais
comuns) e divulgada dentro daquele A.S.
Empregável no atendimento à conexões backup, onde há
mais de uma rota default, com custo diferenciado. Utilizado também quando as
duas conexões estão no mesmo router com custo igual, fazendo assim um
balanceamento de carga.
Configuração mínima: Roteador Cisco série 2500 com
8Mbytes memória.
Banda mínima necessária: 64Kbps.
Skill mínimo necessário: Analista Junior.
Ø
Rotas parciais:
O Provedor fornece rotas parciais a pedido do cliente.
Utilizado quando se deseja aproveitar pouca memória do roteador para receber
essas rotas parciais, e ainda assim manter uma relação boa de roteamento, pois
é possível receber rotas de um provedor (e encaminhar o fluxo de tráfego dessas
rotas recebidas para esse provedor) e fluir todo o tráfego restante para o
outro provedor, via default gateway.
Necessita de configuração um pouco mais apurada.
Roteamento quase ótimo.
Configuração mínima: Roteador Cisco série 3600 com
32Mbytes memória.
Banda mínima necessária: 256Kbps.
Skill mínimo necessário: Analista Pleno.
Ø
Rotas completas:
A recepção de rotas completas permite o roteamento
ótimizado para todos os destinos. Exige maior
entendimento para manutenção e manipulação das rotas,
necessita também de significante aumento
de memória dos roteadores.
Utilizado por todos os roteadores de borda dos grandes
provedores.
Configuração mínima: Roteador Cisco série 7200 com
128Mbytes memória.
Banda mínima necessária: 512Kbps.
Skill mínimo necessário: Analista Pleno.
A decisão de se tornar multihomed envolve uma grande
variedade de considerações, dentre elas, as seguintes:
Ø
Multihomed para um ou vários provedores ?
Isso depende de vários fatores, incluindo tamanho da
banda disponível desses provedores, proximidade de roteamento e até aspectos de
negócios, custos.
Ø
Obtenção de endereços do provedor ou possuir o seu
próprio ?
Se optar por vários provedores, a escolha deve
evidentemente ser por possuir a sua própria faixa de endereços. Caso optasse
por um único provedor, ainda que possível, é desaconselhável.
Ø
Configuração do protocolo
Dependendo das políticas de roteamento e de tráfego, as
configuraçôes do BGP4 podem variar muito em complexidade, refletindo inclusive
nas configurações de IGP dentro do próprio A.S.
Quanto mais complexo for a configuração maior skill
técnico é necessário.
Ø
Balanceamento de carga entre múltiplas conexões aos
provedores
Uma vez havendo múltiplas conexões com provedores,
existe a motivação de utilizá-las.
Há diferentes mecanismos de balancear o tráfego entre
múltiplas conexões, as quais requerem o uso de roteamento IGP. Deve ser notado
que a rede consegue de forma eficiente efetuar o balanceamento de tráfego de
saída. O tráfego de entrada pode ser manipulado através da divulgação de rotas
com atributos, porém sem a conotação de balanceamento.
A RFC 1998 enfoca o uso do balanceamento entre conexões
com o mesmo provedor.
Ø
Roteamento simétrico
O roteamento simétrico (o pedido sai por um enlace e
retorna por outros enlaces de dados),
pode evitar eventuais inconsistencias de delay para as
aplicações, ou seja, um pacote chegou
ao destino antes do pacote anterior.
A política de roteamento assimétrico deve enfatizar o
retorno dos pacotes de uma mesma conexão
TCP pelo mesmo caminho.
Uma rede Multihomed não consegue utilizar a conexão com
o provedor, a menos que o provedor faça a divulgação das rotas para a Internet.
Isso independe se as rotas pertencem ou não àquele provedor.
Um A.S. trânsito é aquele que permite o tráfego entre
por uma porta de um roteador e saia por qualquer outra porta.
Definições de termos:
Ø
Neighbor: A.S. ao qual diretamente se troca informações de
roteamento
Ø
Advertise/announce/anúncio/divulgação: envio de informações de roteamento para um neighbor
Ø
Accept: receber e tratar as informações enviadas pelo neighbor
Ø
Originate: Inserção de atributos no anúncio
Ø
Peer: um roteador no AS neighbor (eBGP) ou dentro do próprio
AS (iBGP), com o qual há troca de informações de roteamento.
Ø
iBGP:
Peer de roteamento interno
Ø
eBGP:
Peer de roteamento externo
Ø
Prefix:
identificação de uma rota, tal qual 200.196.64.0/19
Para que as informações passe através de dois AS, o
seguinte fluxo deve ocorrer:
Ø
AS1 anuncia rotas para AS2
Ø
AS2 aceita rotas do AS1
Ø
AS2 anuncia rotas para AS1
Ø
AS1 aceita rotas do AS2
Para que haja conectividade entre duas redes, todos os
AS intermediários devem permitir a passagem desse tráfego, para isso é
necessário que os AS intermediários recebam as rotas e divulguem para os outros
roteadores. Muitos A.S. efetuam filtragem de pacotes de divulgação, o que
evidentemente impede o fluxo normal, e somente liberando quando houver uma
solicitação formal.
Há mais de 55000 prefixos sendo divulgados na Internet,
com centenas de AS, o que implica numa instabilidade independente de haver ou
não conectividade.
A política de implementação de roteamento possui alguns
problemas que são a limitação de rotas baseadas somente em destino, topologia
global é impossível de se conhecer, não há formas de efetuar agrupamento total
de rotas por AS e o conjunto total de rotas na Internet é desconhecido.
A divulgação como pôde ser vista é totalmente dependente
da cooperação entre os provedores.
Apesar de poder haver um roteamento otimizado dentro de
um AS. não é possível garantir o roteamento otimizado fora da Internet.
A fim de facilitar a agregação de várias rotas em um
único prefixo, o uso de rotas consecutivas distribuídas por sites é altamente
desejável.
O CIDR (Classless Inter Domain Routing) elimina a necessidade
de distinção entre diferentes classes de redes,ou seja, muitos grupos de redes
classes C e B podem ser divulgada ou recebida num mesmo update, com supressão
das rotas mais específicas.
A seguir está uma comparação das características dos
protocols IGP e EGP:
Ø
IGP:
(OSPF, EIGRP, RIP, etc)
ü
Possui mecanismo de
descoberta automática dos roteadores
ü
Há uma relação
confiança entre os roteadores
ü
As rotas são divulgadas
para todos os roteadores
Ø
EGP:(BGP4,
etc)
ü
Roteadores peers devem
ser especificamente configurados
ü
A conexão é com routers
externos, de outro AS.
ü
Há uma definição da
política de roteamento.
O BGP4 (roda sobre TCP, port 179) aprende múltiplos
caminhos para o mesmo destino via iBGP ou eBGP, e utiliza o melhor caminho para
a criação da tabela de roteamento.
O processo de roteamento ocorre assim:
Recepção:
1.
BGP receive as
informações divulgadas e passa pelos filtros
2.
BGP coloca essas rotas
selecionadas numa tabela BGP, e identifica o melhor caminho com um flag.
3.
BGP copia as melhores
rotas para a tabela de roteamento
3.1.1.
Se o prefixo é único
colocar o prefixo na tabela de roteamento
3.1.2.
Senão compara as rotas
baseados na distância administrativa, o vencedor vai para a tabela de
roteamento.
Envio:
1. BGP seleciona as rotas através de filtros e divulga as
melhores rotas para os peers.
Distância
administrativa:
|
Interface
diretamente conectada |
0 |
|
Rota
estática |
1 |
|
Rota
sumarizada EIGRP |
5 |
|
EBGP |
20 |
|
Internal
EIGRP |
90 |
|
IGRP |
100 |
|
OSPF |
110 |
|
IS-IS |
115 |
|
RIP |
120 |
|
EGP |
140 |
|
External
EIGRP |
170 |
|
IBGP |
200 |
|
Desconhecido |
255 |
Ø
iBGP:
É utilizado para troca de informações de roteamento
dentro de um mesmo A.S.
O é mais flexível para redistribuição de rotas dentro do
mesmo A.S. do que um protocolo IGP,
visto
Ocorre entre peers BGP dentro de um mesmo AS, não
necessita estar conectado diretamente,
neighbors iBGP devem estar numa malha full-meshed.
Pode estar distante por vários hops.
Para garantir a estabilidade da conexão BGP, os peers
devem utilizar a interface loopback, evitando
assim oscilações na conexão BGP, evitando tráfego
desnecessário.
Ø
eBGP:
Ocorre entre peers BGP de AS diferentes e devem estar
conectados diretamente.
distribute-list => IP Address
filter-list
=> AS-PATH
Em construção!
Sincronização:
Em construção!
O BGP seleciona somente uma
rota como a melhor rota.
Quando uma rota é
selecionada, o BGP põe a rota selecionada em sua tabela de distribuição e
propaga a rota para a seus vizinhos.
O BGP usa os seguintes
critérios, na ordem apresentada, para selecionar uma rota para um destino:
1.
Se a rota especificar um próximo hop que esteja inacessível, essa rota é
descartada;
2. A
rota com o maior weigth será
preferida;
3. Se mais que uma rota tiver weigth iguais, a rota escolhida será a que
tiver maior local-preference;
4.
Se mais que uma rota tiver local-preference iguais, a rota escolhida será
aquela que foi originado pelo BGP local
desse router;
5.
Se nenhuma rota for originada localmente, terá preferência a rota com o menor
AS_PATH;
6.
Se mais que uma rota tiver AS_PATH de mesmo tamanho, a rota escolhida será a
que tiver menor origin (IGP é
menor EGP, EGP é menor que incomplete);
7.
Se origin forem iguais, a rota preferida será a que tiver menor MED;
8.
Se mais que uma rota tiver mesmo MED, a rota com path externo terá preferência sobre o path interno;
9.
Se as rotas forem internas, terá preferência aquela que o neighbor for mais próximo;
10.
Enfim a rota com o menor router ID do BGP terá a preferência.
|
Atributo |
Valores |
Descrição |
|
ORIGIN |
0 (IGP); 1 (EGP); 2
(incomplete) |
Especifica a origem de uma
rota. Incomplete indica que a rota foi originado pela redistribuição no BGP
através de um IGP. |
|
AS_PATH |
De 0 até N (2-bytes) |
Indica a lista de todos ASN que a rota
atravessa. |
|
NEXT_HOP |
IP address |
Indica para onde enviar os
dados |
|
MULTI_EXIT_DISC |
De 0 até 2 elevado a 32 |
Indicação interna e
externamente do weight |
|
LOCAL_PREF |
De 0 até 2 elevado a 32 |
Indicação interna do
weight |
|
ATOMIC_AGGREGATE |
TRUE/FALSE |
Indica se esta rota é a
mais específica conhecida pelo router |
|
AGGREGATOR |
{ ASN, IP address } par |
Se a rota é um agregado,
indica quem criou a rota. |
|
COMMUNITY |
De 0 até N (4-bytes) |
Community |
|
ORIGINATOR_ID |
|
Usado pelo BGP Route
Reflection |
|
CLUSTER_LIST |
|
Usado pelo BGP Route
Reflection |
Rotas originadas localmente tem por default o weight de 32768 e 0 para rotas vindas
de outro router.
O valor default do atributo local_pref é 100.
Origin indica se a rota foi criada
pelo IGP via parâmetro network, pelo EGP via algum anúncio recebido, ou
incomplete via redistribuição do IGP no BGP.
As expressões regulares são
usadas com os seguintes componentes e formas:
A: Ranges:
Um range é uma
seqüência de caracteres contidos entre chaves, ex.: [abcd]
B: Atoms
Um atom é um dos seguintes caracteres:
.: (ponto – indica qualquer
caractere)
^: (circunflexo – indica o
início de uma string)
$: (cifrão – indica o fim de
uma string)
\caractere: (barra invertida
e um caractere – indica um caractere específico)
-: (menos – indica uma vírgula (,), um colchete
esquerdo ({), um direito (}), o início de uma
string, o fim de uma string ou um espaço.
C: Pieces
Um piece é um atom
seguido por um dos seguintes símbolos:
*: (indica 0 ou mais seqüências de atom)
+: (indica 1 ou mais
seqüências de atom)
?: (indica o atom ou uma
string nula)
D: Branch
Um branch é a
concatenação de 0 ou mais pieces.
Exemplos de
expressões regulares:
a*: Indica qualquer ocorrência
da letra a inclusive nada.
a+: Indica que no mínimo a
ocorrência de uma letra deve estar presente.
ab?a: Indica aa ou aba.
_100_: (Indica via AS100)
^100$: (Indica rota originada
pelo AS100)
^100.*: (Indica rota proveniente
do AS100)
^$: (Indica rota originada por
este AS)
A comunicação IP normal é
ponto-a-ponto. Entretanto, para algumas aplicações, a comunicação multiponto é
útil para o processo de enviar mensagens para um grande número de receptores
simultaneamente. Exemplos de aplicações multiponto são replicação de dados,
banco de dados distribuídos e multiconferência.
IP suporta multicast, usando a classe de endereços
D. Cada endereço da classe D identifica um grupo de estações. No endereço IP,
28 bits estão disponíveis para identificar grupos. Quando um processo envia um
pacote para endereço de classe D, o pacote é liberado para todos os membros do
grupo, mas não garante que todos receberão o pacote.
Existe dois tipos de grupos
de endereços: permanente e temporário. Um grupo permanente sempre existirá e não
precisa ser configurado. Alguns exemplos de endereços de grupo permanente são:
224.0.0.1 - todos os
sistemas numa rede local;
224.0.0.2 - todos os
roteadores numa rede local;
224.0.0.5 - todos os
roteadores OSPF numa rede local.
Multicasting é implementado por roteadores multicast
especiais. Cerca de uma vez a cada minuto, cada roteador multicast envia um pacote para as
estações de sua rede local (endereço 224.0.0.1) perguntando para eles
responderem de volta, quais os grupos que seus processos pertencem.
Estes pacotes de consultas e
respostas usam um protocolo chamado IGMP (Internet
Group Management Protocol), que é similar ao ICMP. Ele tem dois tipos de
pacote: consulta e resposta, cada um com formato fixo contendo alguma
informação de controle na primeira palavra do campo payload e um endereço classe D na segunda palavra. Isto está
descrito com maiores detalhes na [RFC1122].
A versão padrão do protocolo
IGMP é de 1988. A versão usada no MBone hoje é inteiramente compatível com os
novos desenvolvimentos tais como MOSPF e PIM. Muito vendedores estão agora
incluindo-o no seu suporte de rede. Isto tornará uma característica padrão de
pacotes TCP/IP.
A especificação MOSPF
publicada em 1994, e vários vendedores de roteadores tem implementado-o.
As especificações
PIM foram publicadas antes de 1995. Alguns vendedores de roteadores tem
iniciado a implementação do PIM modo denso; ele é muito mais simples e aparece
como substituto natural para a tecnologia MBone. Entretanto vários pontos terão
que ser estudados, em particular a interação entre PIM, MOSPF e DVMRP. Existe
pouca experiência com as dinâmicas destes protocolos. Portanto existe muito
trabalho a ser realizado.
Para algumas aplicações, os
processos estão separados em vários locais, mas trabalham juntos em grupo. Por
exemplo, um grupo de processos implementando um sistema de banco de dados
distribuído. Nele é frequente um processo enviar uma mensagem para todos os
outros membros do grupo. Então necessita-se de um modo de enviar mensagens para
grupos bem definidos que são numericamente grandes, mas pequenos comparados ao
tamanho da rede. Para realizar esta tarefa é necessário utilizar uma técnica de
roteamento multiponto, que será abordada nesta seção.
Para fazer multicasting,
cada roteador constrói sua spanning tree selecionando enlaces
na rede formando uma árvore, de forma a cobrir todos os outros roteadores na
sub-rede.
Pacotes multicast são enviados somente na spanning tree apropriada.
Vários modos de podar a
árvore são possíveis. O modo mais simples é usar o roteamento link-state, sendo que cada roteador deve
conhecer a topologia completa da sub-rede. Então a spanning tree pode ser construída iniciando no final de cada
caminho até a raiz, eliminando os roteadores que não pertencem ao grupo.
Com o roteamento vector-distance, uma diferente
estratégia de podar a árvore deve ser seguida. O algoritmo básico é o reverse path forwarding. Entretanto,
quando um roteador que não faz parte do grupo, recebe uma mensagem multicast,
ele responde para que o emissor não envie mensagens para ele.
Uma desvantagem deste
algoritmo é que para grandes redes muita memória é necessária. Supor que uma
rede tem n grupos, cada um com a média de m membros. Para cada
grupo, m spanning trees
podadas são armazenadas, para um total de m.n árvores. Quando muitos grupos
grandes existem, é gasto muito memória para armazenar as árvores.
Uma alternativa é usar
árvores chamadas core-base tree. Aqui
uma única árvore spanning tree por
grupo é computada, com a raiz ("the core") perto do meio do grupo.
Para enviar uma mensagem multicast,
uma estação envia-a para a raiz, que então envia para os nós do grupo. Embora
esta técnica não seja ótima, ela reduz os custos de armazenagem de m
árvores para uma árvore por grupo.
Enquanto a indústria está
fazendo grande publicidade e planos para o futuro do vídeo sob demanda, a
comunidade Internet tem implementado
seu sistema multimídia digital chamado MBone.
Para uma pesquisa mais aprofundada ver um livro sobre Mbone.
MBone
pode ser pensado como um rádio e televisão da Internet. Diferente de vídeo sob demanda, onde a ênfase está na
chamada e na visão de filmes armazenados no servidor, MBone é usado para
difusão de áudio e vídeo na forma digital para o mundo via Internet. Ele está
operacional desde 1992. Muitas conferências científicas, especialmente os
encontros do IETF, têm sido difundidos. Um concerto dos Rollings Stones foi
difundido sobre MBone.
Maioria das pesquisas sobre MBone é sobre como fazer
"multicast" eficientemente sobre a Internet. Pouco tem sido feito
sobre codificação de áudio e vídeo.
Tecnicamente, MBone é uma rede virtual sobre a Internet. Consiste de ilhas multicast
conectadas por túneis. Os túneis propagam pacotes MBone entre as ilhas. Cada ilha (tipicamente uma rede local ou
grupos de rede locais) suporta hardware multicast.
Algum dia no futuro, quando todos os roteadores serão capazes de manipular
tráfego multicast diretamente, esta
superestrutura não será mais necessária.
Cada ilha contém um ou mais
roteadores especiais chamados de mrouters
(multicast routers). Alguns
destes são roteadores normais, mas a maioria são workstations UNIX executando software especial à nível de usuário.
Os mrouters
são logicamente conectados por túneis. No passado, pacotes MBone eram conduzidos de mrouter
para mrouter
( usualmente através de um ou mais roteadores que não conheciam sobre MBone) usando roteamento de cada fonte.
Hoje, pacotes MBone são encapsulados
em pacotes IP e enviados como pacotes unicast
regulares para o endereço IP destino do mrouter.
Túneis são configurados
manualmente. Usualmente um túnel executa sobre um caminho para que uma conexão
física exista, mas não é um requisito. Se por acidente, um caminho físico
quebra, sobre um túnel, os mrouters usando
um túnel não perceberão, desde que a Internet
automaticamente re-direcionará todo tráfego destes caminhos para outra linhas.
Quando uma nova ilha aparece
e deseja se juntar ao MBone, seu
administrador envia uma mensagem anunciando sua existência para a lista de
correio MBone. Os administradores dos
sites vizinhos entram em contato com
ele para arrumar e configurar os túneis. Túneis não tem existência física. São
definidos por tabelas nos mrouters e
podem ser adicionados, excluídos ou movidos usando as tabelas.
Tipicamente cada país no MBone tem um backbone, com ilhas regionais. Até maio de 1994, MBone era composto de 900 roteadores e
ligava 20 países.
Inicialmente o MBone usou o algoritmo de roteamento DVMRP (Distance
Vector Multicast Routing Protocol) baseado
no algoritmo Vetor-Distância. Por exemplo, na figura 14, a ilha C pode rotear
para A via B ou via E. Ele faz sua escolha, tomando os valores destes nós, que
são fornecidas para ele, sua respectiva distância para A e então somando sua
distância para deles. Estas rotas não são atualmente utilizadas desta maneira,
entretanto será visto resumidamente.
Agora veremos como multicast funciona. Para fazer o
multicast de um programa de áudio ou vídeo, a fonte deve primeiro adquirir um
endereço multicast classe D, que atua
como uma freqüência de canal ou número de canal.
Periodicamente, cada mrouter envia um pacote broadcast IGMP (Internet Group Management Protocol) limitado a sua ilha,
perguntando quem está interessado naquele canal. As estações que querem receber
um ou mais canais, enviam um pacote IGMP em resposta. Estas respostas são
alternadas no tempo, para evitar sobrecarga na rede local. Cada mrouter mantém uma tabela de quais
canais que deve retirar da rede, para evitar desperdício de largura de banda
pelos canais multicast que ninguém
quer.
Pacotes multicast propagam no MBone
da seguinte forma. Quando uma fonte de áudio e vídeo gera um novo pacote, ele
difunde na sua ilha usando equipamento multicast.
Este pacote é mantido no mrouter
local, que então copia para os túneis que estão conectados.
Cada mrouter captura tal pacote via túnel e então verifica se o pacote
veio pela melhor rota, isto é, a rota que sua tabela diz para usar, para
alcançar a fonte (como ela fosse um destino). Se o pacote vem ao longo da
melhor rota, o roteador copia o pacote
para outros túneis. Se o pacote chega, por outra rota, ele é descartado. Este
algoritmo é o reverse path forwarding. Não
é perfeito, mas é simples para implementar.
Além disso, usando-se reverse path forwarding, previne-se de
inundar (flooding) a Internet. Para isso deve ser usado o
campo tempo de vida do pacote IP,
com objetivo de limitar o escopo do multicasting.
Cada pacote com algum valor, determinado pela fonte. Cada túnel possui um peso.
Um pacote somente passa pelo túnel, se tiver peso suficiente, por outro lado é
descartado.
Muita pesquisa tem sido
devotada para aperfeiçoamento do MBone. Uma
proposta mantém a idéia do roteamento Vetor-Distância, mas faz o algoritmo
hierárquico pelo agrupamento dos sites
MBone em regiões.
Outra proposta é para usar
uma forma modificada do roteamento link-state
do roteamento vetor-distância. Em particular, um grupo de trabalho do IETF,
está modificando o OSPF, tornando ele adequado para multicast com um simples sistema autônomo. O multicast resultante é chamado de MOSPF.
Uma segunda área de pesquisa
é roteamento entre sistemas autônomos. Aqui um algoritmo chamado PIM (Protocol Independent Multicast) está
sendo desenvolvido por outro grupo do IETF [HUITE95].
A maioria das aplicações MBone, são orientadas para grupos de
comunicações e produtividade. Correntemente, a maioria das aplicações citadas
aqui, usam o UDP multicast. É esperado que a adoção do Real-time Transport Protocol (RTP) [RFC1889] conduza a um largo uso
do RTP para aplicações multicast.
Alguns exemplos de
aplicações prontas para serem usadas são:
mmcc (Multimedia Conference Control) da Universidade de Califórnia do
Sul;
sd (Session Directory) da Laurence
Berkeley Laboratories (LBL);
vat (Visual Audio Terminal) da LBL;
nvt (Network Voice Terminal) da Universidade de Massachusetts;
nv (Network Video) da Xerox PARC;
ivs (INRIA Videoconfenrencing Systems).
fair-queue
limite dinâmica reservadas
limite:default=64, varia entre 1 e 512, descarta pacotes
quando chega limite
dinâmica:default=256, varia entre 16 e 4096
reservada:default=0, varia entre 0 e 1000, utilizado
para RSVP
SFQ não é determinística,
mas funciona bem (em média). Seus principais benefícios são que ela requer
pouco uso da CPU e da memória. É menos precisa que outras implementações de
Fair Queueing, mas requer menos calculus.
SFQ usa hashing para
mapear os pacotes que chegam no roteador para uma fila FIFO. Entretanto, ao
invés de manter uma fila para cada fluxo possível (o que seria intuitivo), o
algoritmo utiliza menos filas do que o número de fluxos possíveis. Todos os
fluxos que são mapeados para o mesmo valor da tabela hash são tratados de
maneira equivalente, o que simplifica a computação, mas implica que esses
fluxos que "colidem" na tabela são tratados "injustamente."
Se tamanho do índice de hashing for suficientemente maior do que o número de
fluxos ativos, a probabilidade de "injustiça" fica muito reduzida.
As filas são servidas
seguindo um algoritmo de round robin, sem considerar os tamanhos dos pacotes.
Provê particionamento e
compartilhamento da largura de banda de um link através do uso de classes
hierarquicamente estruturadas. Cada classe tem sua própria fila e recebe uma
"fatia" da banda. Uma classe filha pode "emprestar" largura
de banda de sua classe mãe desde que haja banda em excesso disponível.
A figura abaixo mostra os
componentes básicos de CBQ. Ela funciona da seguinte maneira: o
"classificador" designa os pacotes que chegam à classe apropriada. O
"estimador" estima a largura de banda usada por uma classe
recentemente. Se uma classe excede um limite predeterminado, o estimador marca
essa classe. O "escalonador" determina o próximo pacote a ser enviado
dentre as várias classes, baseado nas prioridades e estados das classes. Um
algoritmo de round robin com pesos é usado entre classes com a mesma
prioridade.

O mecanismo de controle de
congestionamento do RED monitora a média de tamanho para cada fila de saída e
usa “randomização” para escolher as conexões que serão notificadas deste
congestionamento.
Congestionamentos
temporários são acomodados por um aumento temporário na fila. Congestionamentos
mais demorados refletem em um aumento da média do tamanho da fila, além de
notificar algumas conexões escolhidas randomicamente. A probabilidade de uma
conexão ser notificada de congestionamento é proporcional ao tamanho da “fatia”
da largura de banda gerenciada pelo gateway que é utilizada por esta
conexão.
O gateway pode notificar a
ocorrência de congestionamento para conexões de duas maneiras, dependendo do
protocolo de transporte: descartando pacotes ou setando um bit no cabeçalho do
pacote (quando isso acontece diz-se que o pacote é marcado). A média do tamanho
dos pacotes é comparada com dois valores: o mínimo e o máximo. Quando a média
do tamanho da fila é menor que o valor mínimo, nenhum pacote é marcado. Quando
a média do tamanho do pacote é maior que o valor máximo, todo pacote que chega
é marcado. E quando a média do tamanho do pacote está entre o mínimo e o
máximo, os pacotes que chegam são marcados dentro de uma certa
probabilidade.
O DRR usa SFQ para atribuir
fluxos para as filas. Para o serviço das filas é usado round robin com uma
fatia de tempo de serviço (quantum) atribuída a cada fila. A única diferença
entre o round robin tradicional e o DRR é que se uma fila não foi capaz de
enviar um pacote no round anterior, porque o tamanho do pacote era muito
grande, o resto do quantum anterior é adicionado ao quantum do próximo round.
Desta maneira, os déficits são monitorados; filas que são desfavorecidas em um
round são compensadas no próximo round.
Em construção
SNMP é um dos
métodos utilizados para fazer gerenciamento de rede e também ter acesso a
roteadores. Com o SNMP podemos agrupar estatísticas ou configurar roteadores.
Agrupar estatísticas a partir de messages get-request e get-next-request, e
configurar roteadores a partir de mensagens set-request. Cada uma destas
mensagens SNMP tem uma string de comunidade que é uma senha, não encriptada
(cleartext), enviada em todo pacote entre uma estação de gerenciamento e o
roteador ( o qual contém um agente SNMP). A string de comunidade SNMP é usada
para autenticar mensagens enviadas entre o gerente e agente. Apenas quando o
gerente envia uma mensagem com a string de comunidade correta o agente irá
responder.
agente SNMP no roteador
permite configurar comunidades diferentes para acesso não privilegiado e privilegiado.
A string de comunidade do roteador pode ser configurada pelo comando
"snmp-server community string [RO | RW] [access-list] ".
Strings de comunidade SNMP
são enviadas na rede em cleartext ASCII. Assim é possível capturar pacotes na
rede pode descobrir a string de comunidade. Isto pode levar usuários sem
autorização a examinar ou modificar roteadores via SNMP. Por esta razão, usando
o comando "no snmp-server trap-authentication" podemos impedir
intrusos de usar mensagens de trap (enviou entre os gerentes e agentes SNMP)
para descobrir a string de comunidade.
A comunidade da Internet
reconhecendo este problema, aumentou a segurança através do SNMP versão 2
(SNMPv2) como descrito no Request For Comments (RFC) 1446. O SNMPv2 usa um
algoritmo chamado MD5 para autenticar a comunicações entre um servidor e agente
SNMP. O MD5 verifica a integridade da comunicação, autentica a origem e confere
o timeliness. Futuramente, o SNMPv2 terá a habilidade para usar o Data
Encryption Standard para encriptação de informação. Os roteadores Cisco
suportam SNMPv2 na versão 10.3 e posteriores.
controle de acesso a
roteadores Cisco é implementado usando os seguintes métodos:
·
Acesso a Console
·
Acesso via Telnet (incluindo Terminal Access Controller Access Control
System [TACACS])
·
Acesso Simple Network Management Protocol (SNMP)
·
Acesso ao Servidor de Rede para os arquivos de configuração dos
roteadores
Os três primeiros métodos
podem ser assegurados empregando características contidas no software do
roteador. Para cada método, pode ser permitido acesso não privilegiado e acesso
privilegiado para o usuário (ou grupo de usuários). O acesso não privilegiado
permite aos usuários monitorar o roteador, mas não configurar o roteador. O
acesso privilegiado permite ao usuário configurar o roteador completamente.
A partir da console e do
Telnet, podemos setar dois tipos de senhas. O primeiro tipo de senha, a senha
de login, permite usuários não privilegiados acessar o roteador. Depois de ter
acesso ao roteador, o usuário pode entrar em modo privilegiado utilizando o
comando enable e a senha específica. O modo privilegiado proporciona ao usuário
todas as capacidades de configuração.
O acesso SNMP permite setar comunidades SNMP
diferentes para ambos acesso não privilegiado e privilegiado. O acesso não
privilegiado permite aos usuários enviar aos roteadores mensagens SNMP
get-request e SNMP get-next-request. Estas mensagens são usadas para agrupar
estatísticas do roteador. O acesso privilegiado permite os usuários enviar
mensagens SNMP set-request para fazer mudanças às configurações e estado
operacional do roteador
A opção de RO do comando
"snmp-server community" prove acesso não privilegiado a seus
roteadores via SNMP. Os seguintes comandos de configuração setam o agente no
roteador para permitir apenas mensagens SNMP get-request e get-next-request que
são enviadas com a string de comunidade "public":
snmp-server community public
RO
Podemos também especificar
uma lista de endereços IP que tem permissão para enviar mensagens ao roteador
usando a opção "access-list" com o comando "snmp-server
community". No seguinte exemplo de configuração, apenas os hosts 1.1.1.1 e
2.2.2.2 são permitidos para acesso ao modo SNMP não privilegiado ao roteador:
access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2
snmp-server community public
RO 1
A opção de RW do comando
"snmp-server community" prove acesso privilegiado para seus
roteadores via SNMP. O seguintes comando de configuração seta o agente no
roteador para permitir apenas mensagens SNMP set-request que são enviadas com a
string de comunidade "private":
snmp-server community
private RW
Podemos também
especificar uma lista de endereços IP que são permitidos para enviar mensagens
ao roteador usando a opção do access-list do comando "snmp- server
community". No seguinte exemplo de configuração, apenas os hosts 5.5.5.5 e
6.6.6.6 são permitidos acessar o modo SNMP privilegiado ao roteador:
access-list 1 permit 5.5.5.5
access-list 1 permit 6.6.6.6
snmp-server community
private RW 1
|
Serviço |
Tipo da Port |
Port |
Bloquear ? |
|
File
Transfer Protocol (FTP)---Data |
TCP |
20 |
|
|
FTP---Commands
|
TCP |
21 |
|
|
Telnet |
TCP |
23 |
|
|
Simple Mail
Transfer Protocol (SMTP)---E-mail |
TCP |
25 |
|
|
Terminal
Access Controller Access Control System |
UDP |
49 |
|
|
Domain Name
Server (DNS) |
TCP e UDP |
53 |
|
|
Trivial File
Transfer Protocol (TFTP) |
UDP |
69 |
sim |
|
finger |
TCP |
79 |
|
|
link---commonly
used by intruders |
TCP |
87 |
sim |
|
SUN Remote
Procedure Call (RPC) |
UDP |
111 |
sim |
|
Network News
Transfer Protocol (NNTP) |
TCP |
119 |
|
|
Network Time
Protocol (NTP) |
TCP e UDP |
123 |
|
|
NewS |
TCP |
144 |
|
|
Simple
Management Network Protocol (SNMP) |
UDP |
161 |
|
|
SNMP (traps)
|
UDP |
162 |
|
|
Border
Gateway Protocol (BGP) |
TCP |
179 |
|
|
rlogin |
TCP |
513 |
sim |
|
rexec |
TCP |
514 |
sim |
|
NFS |
UDP |
2049 |
sim |
|
BSD UNIX r
commands (rsh, rlogin, and so forth) |
TCP |
512 –514 |
sim |
|
line printer
daemon (lpd) |
TCP |
515 |
sim |
|
UNIX-to-UNIX
copy program daemon (uucpd) |
TCP |
540 |
sim |
|
Open Windows
|
TCP e UDP |
2000 |
sim |
|
X Windows |
TCP e UDP |
6000+ |
sim |
Antes de entrar no
processo de determinação de problemas, tenha um plano para identificar os
prováveis problemas, isole as causas mais prováveis destes problemas, e então,
sistematicamente elimine cada causa potencial.
O modelo de de
solução de problemas que segue não é uma receita de bolo muito rígida para
resolver problemas de internetworking. Mas é uma base para traçar planos para
resolver os mais variados casos.
A figura 1.1 mostra um modelo de soluções gerais de
problemas descritos em passos que seguem.

Figura 1.1 Diagrama de solução geral de problemas
Os passos seguintes detalham o processo de
determinação de problemas da figura 1.1:
Passo 1: Defina os problemas em um conjunto de sintomas e causas
associadas.
Defina claramente o problema. Você pode reconhecer e
definir tipo do problema/falha identificando qualquer sintoma associado e a
partir daí procurar os tipos de problema possíveis que resultam nos sintomas
levantados.
Passo 2: Coletando dados.
Uma vez listados os sintomas e identificadas as
possíveis causas, colete dados. A coleta de dados pode envolver traces de rede
através de analisadores de LAN, traces de
linhas seriais, stack
dumps, core dumps, e dados de retorno de uma variedade de comandos show e
debug.
Passo 3: Crie um plano de ação.
O plano de ação deve ser criado a partir do conjunto
de possibilidades que foi criado. Esse plano deve limitar a manipulação de uma
variável por vez, para que a causa do problema seja melhor identificada.
Passo 4: Implemente o plano de ação.
Essa fase consiste na execução do plano de ação
criado. É importante ser muito específico na criação do plano de ação ( isto é,
identifique um conjunto de passos específicos e implemente cuidadosamente cada
passo).
Passo 5: Observe os resultados de cada ação.
Após manipular uma variável na tentativa de encontrar
a solução do problema, observe os resultados baseado no plano de ação (copie os
traces relevantes, capture dados dos comandos debug e show, etc.). Esses dados
podem ser utilizados para otimizar o plano de ação até que a solução seja
alcançada. É durante essa fase que você deve determinar se o problema foi
resolvido. Esse é o ponto de saida do loop estabelecido na figura 1.1.
Passo 6: Limite as possibilidades baseado em resultados.
Para alcançar um ponto onde você pode sair do
problema/loop da solução, você deve esforçar-se para obter progressos através
de um pequeno conjunto de possibilidades, até que reste apenas um.
Passo 7: Aplique o processo de determinação de problemas
interativamente.
Depois de limitar a lista de possibilidades, repita o
processo, começando com um novo plano de ação baseado em uma nova lista de
possibilidades. Continue o processo até que a solução seja encontrada. A
resolução do problema pode consistir na mudança de várias configurações em
servidores, roteadores, etc.
Ao utilizar esse
manual para determinar problemas de rede, siga os seguintes passos:
Step 1: Identifique os sintomas que estão ocorrendo na rede.
Step 2: Elimine o Hardware Cisco como um possível problema
(através do manual "Diagnosticando Hardware Cisco"), mesmo que seja
necessária a substituição do equipamento.
Step 3: Analise o Módulo de
Sintomas de cada capítulo desse conjunto de manuais direcionados à tecnologias
ou protocolos utilizados na sua rede para identificar sintomas similares.
Step 4: Após verificar os
módulos de sintomas, avalie problemas listados nas seções de Possíveis causas e
ações sugeridas.
Step 5: Sistematicamente
aplique ações para cada problema suspeito até que todos os sintomas sejam
eliminados o a possível lista de causas acabe.
As ferramentas a
seguir são utilizadas para a coleta de informações para determinação de
problemas em redes baseadas em equipamentos Cisco:
·
show - comandos de demonstração de
configuração e parâmetros específicos.
·
debug -
comandos de diagnóstico.
·
ping (Echo
Request/Echo Reply) e trace - testes
de conectividade
·
exception dump and write core - comandos de configuração.
Os ítens que seguem
demonstram a utilização desses comandos. O Capítulo XX, "O comando
Debug" define comandos debug para protocolos e tecnologias discutidas
nesse conjunto de manuais, o Apêndice X, "Criando Core Dumps",
explica os comandos exception dump e write core.
Os comandos show são
as ferramentas mais importantes para entender o "status" do roteador,
monitorando a rede em geral, verificando as conexões, e isolando problemas da
rede.
Esses comandos são
essenciais em quase todos os casos de determinação de problemas e monitiração.
Use comandos show para as seguintes atividades:
Observar o
comportamento do roteador durante a instalação inicial
Monitorar se a
operação da rede está normal
Isolar problemas de
interfaces, configurações, etc.
Determinar quando
uma rede está congestionada
Determinar o
"status" dos servidores, clientes ou roteadores "vizinhos"
Ex.: Use o comando
show protocol route (como sh ip route) para determinar se determinada rede está
na tabela de rotas do roteador.
Os comandos debug
podem fornecer muita informação à respeito do tráfego que está fluindo (ou que
não está mas deveria) em uma interface, mensagens de erro geradas na rede ou no
próprio roteador, pacotes de diagnósticos de protocolos, e outros tipos de
dados a serem utilizados na determinação do problema.
Use comandos debug
para isolar problemas, não para monitorar a operação da rede. Não utilize esse
tipo de comando à menos que você esteja procurando por tipos específicos de
tráfego ou problemas que possam ter poucas causas.
Cuidado: O uso de
comandos debug são sugeridos em vários capítulos dos manuais para obter
informações sobre o tráfego da rede e "status" do roteador. Use esses
comandos com muito cuidado. Ao habilitar o "debbuging" o roteador
passa a consumir mais memória, ficando muito carregado, o que pode levá-lo à
falhas. Ao terminar de usar esses comandos, lembre-se de desabilitá-los através
do comando no debug all.
Esses são os dois
comandos de diagnóstico mais utilizados. O comando ping é um mecanismo para determinar
se pacotes estão chegando em um destino. O comando trace permite determinar o
caminho percorrido para se chegar à um determinado destino e onde os pacotes
estão parando.
Usando Core Dumps
Os comandos
exception dump e write core são as ferramentas de diagnóstico menos claras de
um roteador. O resultado desses comandos são arquivos binários que devem ser
processados por um Syslog Server antes de serem interpretados por uma pessoa
técnica. O Apêdice X, "Criando Core Dumps" descreve resumidamente
esse processo.
Esse
capítulo apresenta alguns cenários de resolução de problemas, focando na
identificação, isolamento e solução de problemas que interferem na
conectividade entre redes.
Os
cenários de resolução de problemas mostrados aqui fornecem detalhes de
situações específicas e ilustram o processo de isolamento de problemas e
solução. O objetivo dos cenários é ilustrar um método de resolução de problemas
baseado no modelo definido no capítulo 1, "Um Overview em Determinação de
Problemas". Esses cenários são compostos por situações que ocorrem no
mundo real.
Cada
cenário contém os seguintes elementos:
·
Demonstração dos sintomas
·
Descrição do ambiente de
rede
·
Discussão do isolamento de
problemas e processos
·
Resumo da solução
Os
capítulos subsequentes apresentam uma série de Módulos de Sintomas que fornecem tabelas dos sintomas mais
ocorridos, pssíveis causas, e ações a serem tomadas.
Overview
Problemas
de conectividade se manifestam de várias maneiras. Alguns exemplos são rotas
não aparecendo nas tabelas de rotas, usuários não coneseguindo acessar algum
servidor, etc.). Esses indícios podes ser resultado de uma variedade de
problemas.
Esse
capítulo apresenta uma série de discussões e inclui a aplicação de várias
ferramentas de diagnóstico.
COLOCAR A TOPOLOGIA
DO SITE INTERNET E SIMULAR SITUAÇÕES DE ERROS!!!
DETERMINANDO PROBLEMAS EM LINHAS SERIAIS
Esse
capítulo apresenta informações gerais para determinação de problemas em portas
seriais através dos seguintes tópicos:
§
Usando o comando show interfaces serial
§
Usando o comando show controllers
§
Usando o comando debug
§
Usando o comando extended ping
§
Determinando problemas de
clock
§
Ajustando buffers
§
Testes especiais em linhas
seriais
O comando
show interfaces serial mostra informações específicas das portas seriais. A
figura 3.1 mostra a tela de resultado de um comando show interfaces serial
executado em uma porta HDLC.
Esse
tópico descreve como usar esse comando para diagnosticar problemas de
conectividade em portas WAN. As seções abaixo mostram alguns campos importantes
a serem observados.
§
“Status” da porta e do
protocolo
§
Pacotes de saída descartados
§
Pacotes de entrada
descartados
§
Erros de entrada
§
“Resets” ocorridos na
interface
§
Oscilações de portadora

Figura 3.1 Resultado do comando show
interfaces serial em uma porta HDLC
É
possível identificar cinco problemas no “status” da linha serial (veja na
figura 3.1):
§
Serial x is down, line protocol is down
§
Serial x is up, line protocol is down
§
Serial x is up, line protocol is up (looped)
§
Serial x is up, line protocol is down (disabled)
§
Serial x is administratively down, line protocol is down
A tabela
3.1 mostra os possíveis “status” das interfaces, possíveis problemas e soluções
para esses problemas, exibidos através do comando show interface serial
|
“Status” da interface |
Provável
problema |
|
|
Serial x is up, line protocol is up |
|
Essa é a condição normal, ou seja, os enlaces lógico e físico estão
ok. |
|
Serial x
is down, line protocol is down (roteador é DTE) |
Indica que o roteador não está recebendo o sinal CD1
do DCE (LP, Rádio, etc.) 1
Problema de enlace ou o cabo não está conectado à
interface do DCE 2
Cabo incorreto ou com defeito 3
Erro de configuração ou porta do DCE com defeito |
Passo 1 Verifique os LEDs do DCE
para ver se o sinal CD está “up” Passo 2 Verifique se o cabo
utilizado é o correto e se a interface elétrica (V.35, V.36, etc.) está configurada
corretamente no DCE Passo 3 Coloque um monitor na
linha e verifique a sinalização Passo 4 Verifique se há algum
problema no enlace (LP, Rádio, Modem Satelital, etc.) Passo 5 Se houver suspeitas de
falha no roteador, configure outra porta serial e mude a conexão. Se, após
isso, a conexão funcionar a interface anterior está com problemas |
|
Serial x
is up, line protocol is down (roteador é DTE) |
1
O roteador local ou remoto não está configurado
corretamente 2
Keepalives não estão sendo enviados ao roteador remoto 3
Problema físico enlace (LP, Rádio, etc.) 4
O DCE não está gerando clock 5
Falha de hardware do roteador (local ou remoto) |
Passo 1 Coloque o modem em loop e verifique, através do comando show
interfaces serial, e verifique se o “status” do protocolo muda para “up
(looped)”. Se isso ocorrer há um problema físico de enlace Passo 2 Se o problema parecer estar ocorrendo no roteador remoto, repita
o Passo 1 no DCE remoto Passo 3 Verifique todos os cabos. Tenha certeza de que o cabo está
conectado à interface correta do roteador e do DCE. Use o comando show
controllers para saber que tipo de cabo está conectado à interface Passo 4 Execute o comando debug serial interface e terminal monitor Passo 5 Se mesmo com loopback local o protocolo não de linha não mudar o “status”
para “up (looped)” e se nos dados demonstrados pelo comando debug serial
interface o contador de keepalive (HDLC mysek) não estiver sendo
incrementado, provavelmente há uma falha de hardware do roteador. Troque de
porta Passo 6 Se o protocolo de linha está up e o contador HDLC mysek está
sendo incrementado, o problema não é no roteador local. Siga as instruções
dos tópicos “Determinando problemas de clock” e “Testes de loopback” deste
capítulo |
|
Serial x
is up , line protocol is down (roteador é DCE) |
1
O roteador não está gerando clock 2
O DTE não está configurado ou não suporta o modo
SCTE2 3
Falha no DCE remoto 4
Cabo com defeito ou incorreto 5
Falha de hardware do roteador |
Passo 1 Entre no modo de configuração da interface e adicione o comando
clockrate Passo 2 Se possível, configure o DTE para o modo SCTE. Se isso não for
possível, desabilite o modo SCTE na interface do roteador. Verifique o tópico
“Invertendo a transmissão de clock” deste capítulo Passo 3 Verifique se o cabo que está sendo utilizado é o correto Passo 4 Se o protocolo de linha continua “down”, é possível que haja uma
falha de hardware ou de cabo. Coloque um analisador na linha e verifique a
sinalização. Passo 5 Substitua os equipamentos com defeito |
|
Serial x
is up, line protocol is up (looped) |
Existe
um loop no circuito. A seqüência de números dos pacotes de keepalive nesse
caso muda para um número randômico. Se esse número retorna quando enviado,
existe o loop |
Passo 1 Execute o comando show running-config e verifique se o parâmetro
loopback está configurado na interface Passo 2 Se estiver, use o comando
no loopback no modo de configuração da interface para remover o loop Passo 3 Se você não encontrar alguma entrada loopback na configuração da
interface, examine o DCE e verifique se ele está em loopback (botão LDL da
LP, por exemplo). Se estiver, remova o loopback Passo 4 Desligue e ligue o DCE e
verifique o status da linha no roteador. Se o protocolo mudar o status para
up, havia um problema no DCE Passo 5 Se o DCE não está configurado com loop, há um problema de enlace
físico |
|
Serial x
is up, line protocol is down (disabled) |
1
Está ocorrendo um grande número de erros no enlace
físico 2
O DCE está com algum problema de hardware 3
O roteador está com alguma falha de hardware (porta) |
Passo 1 Utilize um analizador na linha e verifique se os sinais CTS3 e
DSR4 estão oscilando Passo 2 Force um loop no DCE. Se o problema persistir, é provável que
haja uma falha de hardware. Se o problema não continuar, é provável que haja
um problema no enlace físico Passo 3 Troque os equipamentos com defeito (DCE, switch, router, etc.) |
|
Serial x
is administratively down, line protocol is down |
1
O comando shutdown
está configurado na interface 2
Endereço IP duplicado |
Passo 1 Verifique a configuração da interface e cheque se o comando
shutdown está configurado Passo 2 Use o comando no shutdown no modo de configuração da interface
para remover esse parâmetro Passo 3 Verifique se não há nenhum endereço IP duplicado usando o comando
show running-config ou show interfaces Passo 4 Se há algum endereço duplicado, resolva o conflito
mudando um deles |
1 CD=Carrier Detect
2 SCTE=Serial Clock Transmit
External, indica que o equipamento está configurado para receber clock externo.
3 CTS=Clear To Send
4 DSR=Data Set Ready
São
mostrados no campo “output drops” da tela de resultado do comando show
interfaces serial (Veja a figura 3.1). Pacotes são descartados quando não há
espaço nos buffers de transmissão e o sistema envia pacotes para esses buffers.
Sintoma: A taxa de pacotes de saída descartados está muito alta
e aumentando em um enlace serial
Causa provável: A taxa de entrada da interface serial excede a banda
disponível do enlace
Ação recomendada: Os passos a seguir são sugeridos para esse problema:
Passo 1 No modo de configuração da interface afetada execute o
comando no ip route-cache
Passo 2 Na configuração da interface execute o comando hold queue nnnn out para configurar
filas
Nota Os descartes são aceitáveis
sob certas condições. Por exemplo, se um enlace está sendo super-utilizado é
melhor que os pacotes sejam descartados que enfileirados, pois o protocolo
TCP/IP possui controle de fluxo.
As
entradas descartadas aparecem no campo “input drops” da tela de resultado do
comando show interfaces serial (Veja a figura 3.1). As entradas passam a ser
descartadas quando o sistema está processando muitos pacotes em determinada
interface.
Sintoma: A taxa de entradas descartadas está muito alta e
aumentando em um enlace serial
Causa provável: A taxa de entrada da interface serial excede a
capacidade de processamento do roteador ou as filias de entrada excedem o
tamanho das filas de saída.
Nota Esses problemas geralmente
ocorrem quando o tráfego está sendo roteado entre interfaces de alta velocidade
(como ethernet, fast-ethernet, token ring, etc.) e interfaces seriais. Quando o
tráfego é baixo, não há problema. O roteador só descarta pacotes em períodos de
congestionamento.
Ação recomendada: Os passos a seguir são sugeridos para esse problema:
Passo 1 Aumente o tamanho da fila de saída da interface que
está descartando pacotes. Use o comando hold-queue
nnnn in para fazer essa configuração.
Passo 2 Reduza o tamanho da fila de entrada, usando o comando hold-queue nnnn in no modo de
configuração da interface, para forçar que os descartes de entrada tornem-se
descartes de saída. Pacotes descartados na saída afetam menos a performance do
roteador.
Há muitos
tipos de problemas que podem causar erros de entrada, que são verificados com o
comando show interfaces serial (Veja figura 3.1). As causas mais comuns são
listadas a seguir.
Nota Qualquer valor de erros de
entrada para CRC (CRC error), erros de montagem
de frame (framing erros), ou pacotes abortados acima de um porcento do
tráfego total da interface sugere algum tipo de problema de enlace que deve ser
isolado e resolvido.
Sintoma: Número de erros de entrada crescente e acima de um
porcento do tráfego total da interface.
Causa provável: Os seguintes problemas podem gerar esse tipo de
problema:
§
Falha no modem
§
Enlace com nível de ruído
muito alto
§
Configuração incorreta de
clock (SCTE não configurado)
§
Cabo incorreto ou muito
longo
§
Cabo ou conector com defeito
§
Roteador com problema
Ação recomendada: Os passos a seguir são sugeridos para esse problema:
Passo 1 Use um analisador serial para isolar a fonte dos erros
de entrada. Se forem detectados erros, é provável que haja algum problema de
hardware ou algum problema de configuração de clock de algum equipamento que
compõe o enlace físico.
Passo 2 Faça testes com loopback e ping para isolar a fonte do
problema. Veja o tópico “Usando o comando extended
ping” e “Testes de loopback no DTE e DCE” deste capítulo.
A tabela
3.2 descreve os vários tipos de erros de entrada demonstrados através do
comando show interfaces serial (Veja a figura 3.1), possíveis problemas que
podem estar causando esses erros, e suas soluções.
Tabela 3.2 Linhas
seriais: Determinando problemas de erros de entrada
|
Tipo de erro de entrada (nome do campo) |
Provável problema |
Solução |
|
Erros de CRC (CRC) |
Erros de CRC acontecem quando o cálculo do CRC do
pacote não bate (indicando que houve alteração do pacote na transmissão) 1
Ruído no
enlace físico 2
O cabo da interface serial é muito longo ou está
passando junto com cabos elétricos 3
O modo SCTE não está configurado no DTE 4
O DCE não está gerando clock corretamente |
Passo 1 Certifique-se de que a qualidade do enlace está aceitável,
através de testes de BER, por exemplo Passo 2 Verifique se as configurações de clock estão corretas. Se os DCEs
estão gerando clock e se os DTEs estão configurados para receber clock (modo
SCTE) Passo 3 Solicite testes nos equipamentos que compõem o enlace físico |
|
Erros na montagem de frames (frame) |
Erros de montagem de frames ocorrem quando o último
byte do frame não possui 8 bits 1
Ruído no enlace físico 2
Cabo não apropriado; cabo muito longo 3
O DTE não está configurado para receber clock
externo; o DCE não está configurado para gerar clock; |
Passo 1 Certifique-se de que a qualidade do enlace está aceitável,
através de testes de BER, por exemplo Passo 2 Verifique se as configurações de clock estão corretas. Se os DCEs
estão gerando clock e se os DTEs estão configurados para receber clock (modo
SCTE) Passo 3 Solicite testes nos equipamentos que compõem o enlace físico |
|
Transmissões abortadas (abort) |
Indicam uma sequência ilegal de bits 1
O DTE não está configurado para receber clock
externo 2
A configuração de clock no DCE não está correta 3
O cabo serial é muito longo 4
Pacote terminado no meio da transmissão (por causa
de um reset na interface ou erro de montagem de pacote) 5
Problema de hardware – circuito com problema,
DCE/DTE com problema, ou falha na interface do roteador remoto |
Passo 1 Certifique-se de que a qualidade do enlace está aceitável, através
de testes de BER, por exemplo Passo 2 Verifique se as configurações de clock estão corretas. Se os DCEs
estão gerando clock e se os DTEs estão configurados para receber clock (modo
SCTE) Passo 3 Cheque o hardware dos dois equipemantos-fim do enlace e troque de
interface, se necessário Passo 4 Diminua o tráfego e verifique se o número de aborts diminui Passo 5 Use loopbacks locais e remotos para determinar a origem dos
aborts Passo 6 Solicite um teste no enlace físico |
Os resets
de interface, que aparecem no comando show interfaces serial (Veja a figura
3.1), são resultados de pacotes de keepalive perdidos.
Sintoma: Resets de interfaces aumentando em interfaces seriais
Causa provável: As seguintes situações podem gerar esse tipo de
problema:
§
Link congestionado
(tipicamente associado à descartes de saída)
§
Problema de enlace, causando
oscilações do sinal CD
§
Possível problema de
hardware no DCE, switch ou DTE
Ação recomendada: Quando estiver ocorrendo resets na interface, examine
outros campos demonstrados com o comando show
interfaces serial para determinar a fonte dos problemas. Assumindo que o
contador de resets está aumentando, examine os seguintes campos (ilustrados na
figura 3.1):
Passo 1 Se está ocorrendo um grande número de descartes de
pacotes de saída e esse número está aumentando (use o comando show interfaces serial para verificar
isso) leia o tópico “Saídas descartadas” deste capítulo.
Passo 2 Cheque o campo de oscilações de portadora. Se o número
de oscilações estiver incrementando, provavelmente há alguma falha no enlace
físico ou no DCE/DTE ligado diretamente ao roteador. Solicite um teste nos
equipamentos do enlace.
Passo 3 Cheque o campo de erros de entrada. Se o número de
erros de entrada estiver incrementando, provavelmente há alguma falha no enlace
físico ou no DCE/DTE ligado diretamente ao roteador. Solicite um teste nos
equipamentos do enlace.
Oscilações
de portadora ocorrem quando há interrupções no sinal da portadora (como um
reset da interface do roteador remoto)
Sintoma: Contador de oscilações de portadora está aumentando
Causa provável: As seguintes situações podem gerar esse tipo de
problema:
§
Interrupções na linha devido
à um problema externo, como uma separação física de cabo
§
Falha de hardware do
roteador ou problema no DCE/DTE conectado à ele
Ação recomendada: Siga os seguintes passos:
Passo 1 Cheque o hardware dos equipamentos-fim do enlace
(coloque um analisador na linha para determinar a origem do problema).
Passo 2 Se não for possível identificar erros através do
analisador, verifique se não há problema de hardware no roteador.
Passo 3 Troque os equipamentos com defeito, se necessário.
Outra
ferramenta de diagnóstico de linhas seriais importante é o comando show
controllers. A sintaxe do comando varia dependendo da plataforma:
§
Em roteadores Cisco da
família 7000 use o comando show
controllers cbus
§
Nos Access Servers use o
comando show controllers
A figura
3.2 mostra o resultado do comando show controllers serial n/n em um roteador
Cisco 7200. No resultado do comando pode ser verificado o clock que a interface
está recebendo, o tipo de cabo que está sendo utilizado e os sinais da linha
serial.

Figura
3.2 Resultado do comando show
controllers serial em uma porta HDLC (Roteador 7206)
O
resultado desse comando em roteadores de outra família, como a 2500 por
exemplo, é diferente, como pode ser observado na figura 3.3, que é o resultado
do comando show controllers em um roteador Cisco 2501, onde a interface serial
0 possui um cabo V.35 e a serial 1 não possui nenhum cabo.

Figura
3.3 Resultado do comando show
controllers serial em uma porta HDLC (Roteador 2501)
O
resultado dos comandos debug fornece informações de status de um determinado
protocolo e atividade da rede.
CUIDADO Esse tipo de
comando deve ser utilizado com muito cuidado. O processamento do roteador é
extremamente afetado quando comandos de debug são habilitados. Após a análise
dos dados gerados pelo comando, utilize o comando no debug all para retirar todos os debugs.
A seguir são demonstrados alguns
comandos debug que são úteis para a determinação de problemas em portas seriais
WAN.
§
debug serial interface – Através desse comando é possível verificar se os
pacotes HDLC de keepalive estão incrementando. Se não estiver, algum erro está
ocorrendo na porta do roteador ou na rede.
§
debug frame-relay events – Determina se
está ocorrendo troca de pacotes entre o roteador e o switch Frame Relay.
§
debug ppp negotiation – Mostra os pacotes PPP transmitidos durante o
estabelecimento da sessão, onde as opções são negociadas.
§
debug ppp packet –
Mostra os pacotes PPP enviados e recebidos.
Para executar os comandos de debug,
faça telnet no roteador, entre com a senha de enable, execute o comando terminal monitor para receber as
mensagens de debug na sessão de telnet aberta. Após isso digite o comando de
debug desejado e verifique os dados necessários, seguem abaixo alguns
resultados desse tipo de comando.

Figura 3.4 Resultado do comando debug
serial interface & terminal monitor

Figura 3.5 Resultado do comando debug
ppp packet & terminal monitor

Figura 3.6 Resultado do comando debug
frame-relay packet & terminal monitor
O comando
ping é útil para fazer testes de conectividade entre equipamentos e de erros de
entrada registrados no comando show interfaces serial.
Para
determinar problemas de erros no enlace, faça os seguintes testes com o comando
ping:
Passo 1 Coloque o DCE em loop.
Passo 2 Configure o comando ping para enviar pacotes com dados e tamanhos diferentes. As
figuras 3.7 e 3.8 mostram dois tipos interessantes de teste, um com pacotes de
1500 bytes “0” e outro com 1500 bytes “1”, respectivamente.

Figura
3.7 Teste com o comando ping – 100
pacotes de 1500 bytes com valor “0”.

Figura
3.8 Teste com o comando ping – 100
pacotes de 1500 bytes com valor “1”.
Passo 3 Examine, através do comando show interfaces serial (Veja a Figura 3.1), e determine se os erros
de entrada aumentaram. Se não, os hardwares locais (DCE, cabo ou interface do
roteador) estão sem problemas.
Assumindo
que com esse teste ocorreram vários erros de CRC ou montagem de frame,
provavelmente há um erro de clock. Verifique a configuração de clock no DCE.
Passo 4 Se não houver erro de configuração de clock, nem
estiver acontecendo erros de CRC ou de montagem de frame, coloque o DCE ou DTE
remoto em loop.
Passo 5 Repita o teste de ping e verifique as estatísticas de
erros de entrada.
Passo 6 Se os erros aumentarem, pode haver um problema no
DCE/DTE remoto ou no enlace. Solicite um teste de erros no enlace e, se
necessário, substitua o DCE/DTE remoto.
Problemas
de clock em conexões WAN podem resultar em perda de conexão ou em uma
degradação de performance. Os itens a seguir mostram alguns aspectos de
problemas de clock:
§
Causa dos problemas de clock
§
Detectando problemas de
clock
§
Isolando problemas de clock
§
Solução de problemas de
clock
Em geral,
os problemas de clock podem ser atribuídos à uma das seguintes causas:
§
Configuração incorreta do
DTE
§
Configuração incorreta do
DCE
§
Cabos com defeito
§
Cabos passando com fiação
elétrica
Para
detectar problemas de clock em enlaces WAN, procure por erros de entrada
conforme o roteiro abaixo:
Passo 1 Execute o comando show
interfaces serial nos roteadores-fim do enlace.
Passo 2 Procure por erros de CRC, montagem de pacotes e
descartes.
Passo 3 Se algum dos casos a taxa de erros exceder ao range
0,5 à 2 porcento do tráfego da interface, provavelmente está ocorrendo problema
de clock em algum ponto do enlace WAN.
Passo 4 Isole a fonte dos problemas de clock seguindo os passos
do próximo tópico (“Isolando problemas de clock”)
Depois de
determinar que os problemas de clock estão gerando os erros de entrada na
interface, siga os passos a seguir para isolar a fonte dos erros:
Passo 1 Execute uma série de testes de ping e loopback (locais
e remotos).
Passo 2 Descubra qual lado da conexão está gerando o problema,
ou se o problema está no enlace físico. Através de loopback local, faça testes
de ping com tamanho de pacote e valores diferentes para os bytes (use
datagramas de 1500 bytes, por exemplo).
Passo 3 Use o comando show
interfaces serial e verifique se os contadores de erros de entrada estão
aumentando.
Se os
erros estão ocorrendo nas duas pontas, provavelmente há problema no clock do
DCE.
Se os erros de entrada estiverem ocorrendo em
apenas um lado, provavelmente há algum problema de cabo ou de configuração de
clock no DTE.
Se
estiverem ocorrendo descartes em algum lado, provavelmente o outro está
mandando pacotes com problemas ou há problema no enlace físico.
Nota Sempre execute o comando show interfaces serial e verifique se
ocorreram ou não mudanças nos contadores de erro.
A tabela
3.3 descreve algumas sugestões para problemas de clock, baseadas na origem do
problema.
Tabela 3.3 Linhas
seriais: Problemas de clock e soluções
|
Provável
problema |
|
|
Configuração incorreta do DCE |
Passo 1 Verifique se a
configuração de clock dos DCEs das duas pontas Passo 2 Configure os
parâmetros de clock dos DCEs, se necessário |
|
Configuração incorreta do DTE |
Passo 1 Verifique se
os DTEs das duas pontas estão configurados para receber clock externo (modo
SCTE) Passo 2 Se não
estiverem, onfigure os DTEs para receber clock externo |
|
Cabo com defeito |
Verifique
se não há problema de cabo (comprimento, passando junto com fiação elétrica,
etc.) |
Se você
está usando um equipamento para conectar ao roteador (em velocidades superiores
à 64 Kbps) que não suporta o modo SCTE, pode ser necessário inverter a
transmissão de clock no roteador. A inversão da transmissão de clock compensa a
troca de fase entre os sinais de clock e dados.
O comando
para inverter a transmissão de clock varia entre as plataformas. Em um roteador
Cisco 7000 a sintaxe é invert-transmit-clock, para a família 4000 é
dte-invert-txc.
Utilização
excessiva de banda acarreta na redução da performance geral e pode causar
falhas intermitentes. Por exemplo, uma transmissão em protocolo UDP pode estar
falhando porque pacotes estão sendo descartados em algum lugar da rede.
Se a
situação é muito ruim, deve-se aumentar a largura de banda do enlace. No
entanto, isso não é imediato. Uma maneira de resolver problemas de
super-utilização do enlace é controlar a utilização de buffers no roteador.
CUIDADO Esse tipo de
comande deve ser utilizado com muito cuidado, pois ele pode reduzir a
performance do roteador e da rede se utilizado incorretamente.
Use uma das três opções abaixo para
controlar a utilização dos buffers:
§
Ajuste parâmetros associados
com os buffers de sistema
§
Especifique o número de
pacotes que podem ser enfileirados na saída (hold queues)
§
Defina a prioridade de como
o tráfego é enfileirado para a transmissão (priority hold queuing)
Há dois
tipos de buffers nos roteadores Cisco. São os buffers de hardware e de sistema.
Somente os de sistemas são configuráveis pelos administradores do sistema.
Os
buffers de hardware são utilizados para transmissão e recepção das interfaces e
são associados e gerenciados dinamicamente pelo sistema.
Os
buffers de sistema são associados com a memória principal e são alocados para
blocos de memória de tamanhos diferentes. Para verificar o status dos buffers
de sistema execute o comando show
buffers. A figura 3.9 mostra o resultado do comando show buffers.

Figura 3.9 Resultado do comando show
buffers
Hits – Contador de buffers alocados com
sucesso.
Misses –
Contador de tentativas de alocação de buffer que resultaram no crescimento do
pool de buffers
Trim – Contador de buffers liberados ao sistema
por não estarem sendo utilizados.
Criados – Número de buffers criados devido à
falhas.
Se o comando mostrar
um grande número de falhas no campo “no memory”, deve ser reduzida a utilização
dos buffers de sistema ou a memória RAM deve ser aumentada.
Se houver
um grande número nos campos trims e created (acima de 12000), é possível
melhorar a performance do enlace aumentando o valor “max-free” configurado para
os buffers de sistema. Use o comando buffers max-free nnnn para aumentar o
número de buffers de sistema livre. O valor a ser configurado deve ser 150
porcento do campo “total”. Repita esse processo até que não sejam mais
demonstrados valores para os campos trims e created.
Hold
queues são buffers usados por cada interface do roteador para armazenar pacotes
de entrada e saída. Use o comando hold-queue no modo de configuração da
interface para aumentar o número de pacotes que podem ser armazenados antes do
roteador começar a descartá-los, em caso de super-utilização do enlace.
Nota Geralmente é necessário
aumentar os buffers de sistema quando hold queues de saída são configuradas. O
valor usado depende do tamanho dos pacotes que trafegam pelo enlace.
Além das
ferramentas básicas de diagnóstico dos roteadores Cisco há uma série de outras
ferramentas e técnicas que podem ser utilizadas para determinar a condição de
cabos, switches, modems, estações e equipamentos de rede remotos.
Se o
comando show interface serial indica que a linha está “up”, mas o protocolo de
linha está “down”, faça testes de loopback para determinar a origem dos
problemas. Execute testes de loopback locais, depois remotos. A figura 3.10
mostra uma topologia básica de testes de loop local e remoto.
Figura 3.10 Testes de loopback local e remoto
Os passos
abaixo indicam um procedimento geral para fazer testes de loopback juntamente
com ferramentas de diagnóstico dos roteadores Cisco.
Passo 1 Coloque o DCE em loop local. Quando em loop, o
equipamento é forçado a usar o clock local.
Passo 2 Use o comando show
interfaces serial e verifique se o status da linha mudou de “line protocol
is down” para “line protocol is up (looped)”, ou se permanece em “down”.
Passo 3 Se o protocolo de linha mudar o status para “up” com o
loop local ativo, provavelmente o problema está ocorrendo no outro lado do
conexão. Se o status não mudar, é possível que haja um problema no roteador, no
cabo ou no DCE.
Passo 4 Se o problema aparentar ser local, use o comando debug serial interface e o comando terminal monitor.
Passo 5 Retire a configuração de loop no DCE local. Quando o
protocolo mudar o status para “down” novamente o debug indicará que o contador
de keepalive não está aumentando.
Passo 6 Configure o loop local novamente. Com isso os pacotes
de keepalive devem ser incrementados. Se não estiverem incrementando,
provavelmente há problemas de configuração de clock no DCE ou problemas na
interface do roteador.
Passo 7 Cheque os equipamentos locais e os cabos conectados.
Verifique se os cabos estão conectados às portas corretas.
A figura
3.11 mostra o resultado de um comando debug
serial interface para uma conexão HDLC, com perda de pacotes de keepalive,
mudando o status da linha para “down” e um reset na interface.

Figura 3.11 Comando debug serial interface & terminal monitor
Se for
determinado que os equipamentos locais estão funcionando mas ainda estão
ocorrendo problemas com o enlace, tente fazer testes de loopback remoto para
isolar a causa do problema.
Nota Esse teste assume que o
protocolo de encapsulamento do enlace é HDLC.
Passo 1 Coloque o DCE remoto em loopback.
Passo 2 Verifique através do comando show interfaces serial se o protocolo de linha continua “up”, com o
status “line protocol is up (looped)” ou “line protocol is down”.
Passo 3 Se o status permanecer “up (looped)”, o problema está
ocorrendo entre o DCE remoto e o roteador. Faça os testes de loop local no
outro lado da conexão para isolar a origem do problema.
Passo 4 Se o status mudar para “line protocol is down”, provavelmente
há problemas no enlace físico.