Devemos observar que em uma sub-rede geograficamente distribuída,
erviço de rede, por ser oferecido à camada de transporte existente apenas
3 DTEs, é um serviço para transporte de dados do DTE de origem para o
TE de destino. Embora a camada de rede seja realizada tanto nos DTEs
mto nos DCEs e DSEs, o serviço é de DTE (de origem) a DTE (de desti-
i, ao contrário dos serviços da camada de enlace, que transportam dados
re DTE-DCE, DCE-DCE, DCE-DSE e DSE-DSE.
1.1 - Organização Interna do Nível de Rede OSI
As funções do nível de rede incluem:
• Multiplexação.
• Endereçamento.
• Mapeamento entre endereços de rede e endereços de enlace.
• Roteamento.
• Estabelecimento e liberação de conexões de rede.
• Transmissão de unidades de dados do serviço de rede.
• Segmentação2 e blocagem.3
• Detecção e recuperação de erros.
• Seqíienciação.
• Controle de congestionamento.
As funções do nível de rede fornecem suporte para uma grande varie-
3 de configurações de conexões de rede, indo desde" conexões ponto a
to até combinações complexas de sub-redes com características diferen-
Quando as funções do nível de rede são executadas através da combina-
de várias sub-redes distintas, a especificação das funções de roteamento
cilitada pelo uso de subcamadas. As subcamadas são empregadas para
irar as funções de roteamento das sub-redes individuais das funções de
amento entre sub-redes. Por esse motivo, o nível de rede do RM-OSI
) 87a] foi dividido em três subcamadas, como pode ser observado na Fi-
. 10.1.
- Mapeamento de urna SDU do nível de rede (PDU do nível de transporte).em várias PDUs do
:le rede (SDUs dn nível de enlace).
' Mapeamento tle várias SDUs do nível de rede (PDUs do nível de transporte) em uma PDU do
:ie rede (SDU do nível de enlace).
Figura 10.1: Organização interna do nível de rede OSI.
A subcamada de acesso à sub-rede [Rose 90] é dependente da tecno-
logia de sub-rede específica. As funções dessa subcamada incluem a transfe-
rência de dados dentro da sub-rede, o estabelecimento, manutenção e a libe-
ração de conexões em sub-redes orientadas à conexão, podendo incluir ainda
funções de roteamento e retransmissão de informações que trafegam dentro
da sub-rede. Os protocolos de acesso à sub-rede {Subnetwork Access Proto-
col — SNAcP) podem variar muito de uma rede para outra. Citando exem-
plos, o SNAcP em uma rede local Ethernet pode ser extremamente simples
quando comparado aos protocolos X.25 de uma rede pública.
A função da subcamada dependente da sub-rede é harmonizar sub-re-
des que oferecem serviços diferentes. As sub-redes podem se diferenciar em
muitos aspectos. Tomemos como exemplo o endereçamento. A subcamada
independente da sub-rede, conforme definida pelo RM-OSI, utiliza pontos
de acesso de rede (SAPs de redes) para endereçamento. Em sub-redes que
utilizam endereçamento por estação, por exemplo sub-redes X-25, é neces-
sário a multiplexação dos pontos de acesso a serviços de redes (SAPs de
rede), utilizados em última análise para endereçar processos, no endereço de
estação. Esta seria então uma das funções realizadas peio protocolo de con-
vergência dependente da sub-rede (Subnetwork Dependent Convergence
Protocola SNDCP).
Como mencionamos, no RM-OSI o nível de rede provê os meios fun-
cionais e procedurais para transmissão de dados orientada ou não-orientada
à conexão entre entidades do nível de transporte. Assim, potencialmente
existem dois SNDCPs para cada tipo de sub-rede: um adapta o serviço da
sub-rede ao serviço de rede orientado à conexão, e o outro ao serviço sem
conexão. Quando o serviço oferecido pela subcamada de acesso à sub-rede é
semelhante ao serviço de rede desejado, o SNDCP não é necessário. Nesse
caso, a função da subcamada dependente da sub-rede resume-se à manipula-
ção de parâmetros do serviço da sub-rede, e o SNDCP é também referen-
299
9.7.3 - Interface entre as Subcamadas LLC e MAC

As primitivas trocadas pelos níveis LLC e MAC são as seguintes:

• MA-UNITDATA.reqiiest(source-address, destination-address, data,
priQrity, service-class)
Capítulo 1 (
• MA-UNITDATA.indication(source-address, destination-address,
data, receptíon~status,priority,
service-ciass)
. MA-UNITDATA-STATUS.indication(source-address,
destination-address,
transmission-status,
provided-priority,
Nível de Rede
provided-service-class)
A primitiva MA-UNITDATA.request solicita que uma MSDU (MAC
Service Data Unif) seja transferida para uma ou mais estações de destino. Os
parâmetros prioridade e classe de serviço indicam respectivamente a priori-
dade e a classe de serviço que devem ser utilizadas na transferência da uni-
dade de dados.
A primitiva MA-UNITDATA.indication comunica à entidade LLC a
O nível de rede provê os meios funcionais e procedurais para transir
chegada de uma unidade de dados, transferindo-a da camada MAC para a
camada LLC. A primitiva também indica se a unidade de dados foi recebida são de dados orientada ou não-orientada à conexão entre entidades do ní
corretamente ou não, através do parâmetro reception-status. de transporte [ISO 92].

A primitiva MA-UNITDATA-STATUS.indication provê informações
sobre o sucesso ou falha (transmission-status) de uma primitiva MA-
UNITDATA.request previamente emitida. A primitiva também indica a
prioridade e a classe de serviço efetivamente utilizadas na transmissão.
Todo o transporte de pacotes, desde a origem até o destino, passan
por todo um caminho que pode conter vários nós e sub-redes1 intermed
rias, é função do nível de redes. Ele deve oferecer ao nível de transporte
dependência quanto a considerações de chaveamento e roteamento assoe
das com o estabelecimento e operação de uma conexão de rede, incluindc
caso onde são usadas várias sub-redes em sequência, ou em paralelo na c
nexão.
É função do nível de rede tornar transparente para as entidades
transporte, de que forma os recursos dos níveis inferiores — conexões
enlace e meios físicos de comunicação — são usados para implementar c
nexões de rede, devendo executai- os procedimentos necessários para masc
rar as diferenças entre as diversas tecnologias de transmissão das sub-redi
O serviço fornecido aos usuários de uma conexão de rede é único, mesr
quando a conexão atravessa sub-redes distintas que fornecem serviços dii
rentes.

Uma sub-rede é a representação no RM-OSI de uma rede real como, por exemplo, ama ri
publica, uma rede privada, ou uma rede local de computadores.

296 2!
ciado como função de convergência dependente da sub-rede (Subnetwork
Dependent Convergence Function — SNDCF). Se os sistemas finais de ori-
gem e destino fizerem parte da mesma sub-rede, o SNDCP é o responsável
pelo fornecimento do serviço de rede.
A subcamada independente da sub-rede é responsável pelo forneci-
mento do serviço de rede OSI entre dois sistemas finais. O protocolo de
convergência independente da sub-rede {Subnetwork Independent Conver-
gence Protocol — SNICP) só é usado quando os sistemas finais estão loca-
lizados em sub-redes distintas. O SNICP constrói os serviços de rede OSI
orientado ou não-orientado à conexão, operando sobre as funções fornecidas
pela subcamada dependente da sub-rede, de forma independente das carac-
terísticas das sub-redes envolvidas. A principal tarefa da subcamada inde-
pendente da sub-rede é o roteamento entre redes.
Resumindo, cada subcamada executa sua função com base nos serviços
fornecidos pelas subcamadas inferiores. O SNAcP torna possível a transfe-
rência de dados dentro de uma sub-rede, o SNDCP amplia esse serviço de
transferência de dados de modo a fornecer um serviço de rede OSI na sub-
rede (orientado ou não orientado à conexão). E, o SNICP, com base no ser-
viço de rede OSI fornecido em sub-redes interligadas (cada serviço forne-
cido por um SNDCP diferente), realiza as adaptações necessárias à conexão
de sistemas finais localizados em sub-redes distintas.
10.2 - Considerações sobre o Nível de Rede
Nesta seção discutiremos algumas questões relacionadas ao projeto da
camada de rede. Procuraremos falar sobre os diversos temas de uma forma
geral, deixando para as seções específicas sobre protocolos particulares a
exemplificação dos diversos procedimentos que aqui apresentaremos.
10.2.1 - Endereçamento
Alguns níveis de rede oferecem a comunicação entre estações (um
único SAP de rede), ao passo que outros possibilitam a definição de vários
SAPs de rede por estação. Não importa o tipo de rede, o endereçamento dos
pontos de acesso a serviços de rede (SAPs de rede) deve ser completamente
independente dos demais endereçamentos dos outros níveis de protocolo.
Basicamente dois tipos de endereçamento são possíveis: o hierárquico e o
horizontal.
No endereçamento hierárquico o endereço de urna entidade é consti-
tuído de acordo com os endereços correspondentes aos vários níveis de hie-
300
rarquia de que ela faz parte. Um exemplo comum é um endereço de SAP
rede formado pelo número da rede a que pertence, pelo número da estaç
dentro dessa rede e pelo número da porta associada. O IP {Internet Proioa
da Arpanet é um exemplo de utilização de endereço hierárquico, onde
identificação de um SAP de rede (único por estação) é formada pelo endei
ço da rede (sub-rede4) e pelo endereço da estação.
O endereço hierárquico é também o método sugerido pelo ITU-T, at:
vés da recomendação X.121, para interconexão de redes públicas de pacofc
Nessa recomendação os endereços são números decimais formados por ti
campos, um código do país (três dígitos), um código para a rede (um dígi
— no máximo 10 redes) e um campo para o endereçamento dentro da re
(10 dígitos).
No endereçamento horizontal, os endereços não têm relação algui
com o lugar onde estão as entidades dentro da rede. Ura exemplo comi
desse tipo de endereçamento seriam os endereços globalmente administ
dos, constituídos pelo número de assinatura do usuário, como os utilizac
pelo padrão IEEE 802.
Considerações sobre o roteamento parecem indicar vantagens na ut
zação de endereços hierárquicos, uma vez que estes contêm informaçc
explícitas sobre o local onde se localizam as entidades, informações que j
dem ser usadas quando necessário. Já o endereço horizontal, por ser in<
pendente da localização, vai facilitar os esquemas de reconfiguração |
permitir uma mobilidade das entidades sem renumeração das mesmas.
O mapeamento do endereço de um SAP de rede em um endereço
sub-rede (muitas vezes o endereço no nível de enlace se a rede não possu
subcamada de acesso à sub-rede do RM-OSI) para o envio de pacotes é u
tarefa a ser resolvida pelo nível de rede (subcamada dependente da si
rede). Existem duas técnicas usuais para essa conversão: resolução atra'
de mapeamento direto e resolução através de vinculação dinâmica.
No mapeamento direto, a estação sabe como computar, de modo efi
ente, o endereço de sub-rede, através de uma função que mapeia o enden
inter-redes no endereço de sub-rede. Por exemplo, suponha o caso do eni
reçamento hierárquico onde o campo de endereço de estação correspoi
exatamente ao endereço da estação no nível da sub-rede. Neste caso a o
versão é trivial. Conversões mais complicadas podem ser realizadas atra-
de tabelas de conversão e técnicas de acesso rápido a estas tabelas.
Aiguns autores e padrões chamam a sub-rede de comunicação de rede; e a rede, possivelm
composta de sub-redes, de inter-rede. Passaremos agora a adotar os termos rede e inter-rede, utiliz:
apenas o termo sub-rede quando a palavra rede causar confusão.
 Para evitar o uso de tabelas de conversão, uma vinculação dinâmica
de ser efetuada entre o endereço da inter-rede e o endereço da sub-rede,
•aves da utilização de algum protocolo de resolução. Por exemplo, supo-
a o caso extremo onde a cada comunicação é enviada uma mensagem a
ia inter-rede, arguindo o endereço de sub-rede correspondente ao SAP de
je do destino. A estação de destino responderia à requisição enviando seu
dereço de sub-rede, possibilitando ao SAP de rede de origem realizar a
muni cação.
O leitor pode pensar que, uma vez que se está enviando uma mensagem
r difusão arguindo o endereço de sub-rede, por que não enviar diretamente
dados por difusão? A razão vem do fato de que a realização de difusão
la vez que se quer enviar um pacote é muito custosa, em termos de tráfego
'ado na rede e de processamento que cada estação tem de realizar, quer o
:ote seja destinado a ela ou não. Para reduzir esses custos, as estações
ntêm em memória cache os endereços de sub-rede recentemente requeri-
5 e sua vinculação com os endereços dos SAPs de rede, de forma a não ter
realizar o protocolo de resolução a todo pacote transmitido. Discutiremos
Seção 10.4.1.1 o protocolo de conversão do IP da rede Arpanet como
:mplo.
.2.2 - Roteamento
No próximo capítulo veremos que a ligação entre redes é realizada por
ições especiais, denominadas gateways, ligadas a duas ou mais redes. O
íamento é uma função que deve ser resolvida tanto a nível dos gateways,
mto a nível das demais estações. Em redes geograficamente distribuídas,
no já vimos no Capítulo 2, as estações (DTEs) passam sua função de ro-
mento para os DCEs (IMPs na Arpanet) e DSEs, como mostra a Figura
. Para mantermos uma mesma nomenclatura, independente da sub-rede
izada, diremos que um nó realiza o roteamento, independentemente de
ser a própria estação, um DCE ou DSE, ou um gateway.
A estação (ou DCE e DSE em redes geograficamente distribuídas) ca-
á a escolha do melhor gateway ao qual será enviado o pacote no caso de
•i mensagem inter-redes, ou a qual estação (ou DCE em redes geografi-
íente distribuídas), no caso de uma mensagem dentro da mesma rede.
:im, cabe à estação (DCE e DSE em redes geograficamente distribuídas)
.im nível de roteamento. Ao gateway cabe escolher a melhor rota através
jutros gateways, se for o caso, para o encaminhamento dos pacotes. Em
;s que possuem mensagens por difusão, o roteamento realizado pelas es-
íes pode ser relaxado. Querendo enviar uma mensagem inter-redes, uma
ição simplesmente transmitirá um pacote por difusão. Se a mensagem é
inter-redes cabe então aos gateways o reconhecimento de qual deles deverá
se responsabilizar pela continuidade do encaminhamento da mensagem.
A implementação do roteamento exige uma estrutura de dados que in-
forme os possíveis caminhos e seus custos, a fim de que se possa decidir
qual o melhor. Diversos métodos têm sido utilizados para a manutenção da
estrutura de dados.
No encaminhamento por rota fixa, a tabela (estrutura de dados) uma
vez criada, não é mais alterada. As rotas são fixas e caminhos alternativos
são tomados só em caso de falhas. Esse método tem a vantagem de ser bas-
tante simples, mas em geral leva à má utilização dos meios de comunicação,
a não ser que o tráfego da rede seja bem regular e bastante conhecido.
Já no encaminhamento adaptativo, a rota é escolhida de acordo com a
carga na rede. Nas tabelas de rotas são mantidas informações sobre o tráfego
(como por exemplo o retardo sofrido em um determinado caminho), que são
consultadas para a escolha do caminho mais curto (por exemplo, o de menor
atraso). As tabelas devem ser periodicamente atualizadas, podendo tal atua-
lização ser realizada de vários modos:
• No modo isolado a atualização é realizada com base nas filas de
mensagens para os diversos caminhos e outras informações locais.
• No modo distribuído cada nó envia periodicamente aos outros nós,
incluindo os gateways, as informações locais sobre a carga na rede.
Essas informações são utilizadas para o cálculo da nova tabela.
• No.modo centralizado cada nó envia a um ponto central da rede as
informações locais sobre a carga. Essas informações são utilizadas
pelo ponto central para o cálculo das novas tabelas, que são então
enviadas aos gateways e demais nós.
Antes de passarmos a discutir os vários modos de atualização das tabe-
las de rotas, vamos analisar com um pouco mais de profundidade o que en-
tendemos por caminho mais curto, mencionado anteriormente.
Existem várias formas de medir o comprimento do caminho. Uma
forma é o número de saltos, isto é, o número de nós intermediários pelos
quais deve passar o pacote até chegar ao destino. Outra medida é a distância
geográfica em metros. Ainda outra medida poderia ser o retardo de transfe-
rêcia do pacote. Nesse caso o caminho mais curto seria, na verdade, o cami-
nho mais rápido.
São conhecidos diversos algoritmos para a computação do caminho
mais curto (qualquer que seja sua definição) entre dois nós. A referência
[Tanembaum 89] apresenta uma discussão sobre o assunto.
303
ciado como função de convergência dependente da sub-rede (Subnetwork
Dependent Convergence Function — SNDCF). Se os sistemas finais de ori-
gem e destino fizerem parte da mesma sub-rede, o SNDCP é o responsável
pelo fornecimento do serviço de rede.
A subcamada independente da sub-rede é responsável pelo forneci-
mento do serviço de rede OSI entre dois sistemas finais. O protocolo de
convergência independente da sub-rede (Subnetwork Independent Conver-
gence Protocol — SNICP) só é usado quando os sistemas finais estão loca-
lizados em sub-redes distintas. O SNICP constrói os serviços de rede OSI
orientado ou não-orientado à conexão, operando sobre as funções fornecidas
pela subcamada dependente da sub-rede, de forma independente das carac-
terísticas das sub-redes envolvidas. A principal tarefa da subcamada inde-
pendente da sub-rede é o roteamento entre redes.
Resumindo, cada subcamada executa sua função com base nos serviços
fornecidos pelas subcamadas inferiores. O SNAcP torna possível a transfe-
rência de dados dentro de uma sub-rede, o SNDCP amplia esse serviço de
transferência de dados de modo a fornecer um serviço de rede OSI na sub-
rede (orientado ou não orientado à conexão). E, o SNICP, com base no ser-
viço de rede OSI fornecido em sub-redes interligadas (cada serviço forne-
cido por um SNDCP diferente), realiza as adaptações necessárias à conexão
de sistemas finais localizados em sub-redes distintas.
10.2 - Considerações sobre o Nível de Rede
Nesta seção discutiremos algumas questões relacionadas ao projeto da
camada de rede. Procuraremos falar sobre os diversos temas de uma forma
geral, deixando para as seções específicas sobre protocolos particulares a
exemplificação dos diversos procedimentos que aqui apresentaremos.
10.2.1 - Endereçamento
Alguns níveis de rede oferecem a comunicação entre estações (um
único SAP de rede), ao passo que outros possibilitam a definição de vários
SAPs de rede por estação. Não importa o tipo de rede, o endereçamento dos
pontos de acesso a serviços de rede (SAPs de rede) deve ser completamente
independente dos demais endereçamentos dos outros níveis de protocolo.
Basicamente dois tipos de endereçamento são possíveis: o hierárquico e o
horizontal.
No endereçamento hierárquico o endereço de uma entidade é consti-
tuído de acordo com os endereços correspondentes aos vários níveis de hie-
300
rarquia de que ela faz parte. Um exemplo comum é um endereço de SAI
rede formado pelo número da rede a que pertence, pelo número da este
dentro dessa rede e pelo número da porta associada. O IP (Internet Proto
da Arpanet é um exemplo de utilização de endereço hierárquico, onc
identificação de um SAP de rede (único por estação) é formada pelo end
ço da rede (sub-rede4) e pelo endereço da estação.
O endereço hierárquico é também o método sugerido pelo ITU-T, £
vés da recomendação X.121, para interconexão de redes públicas de pacc
Nessa recomendação os endereços são números decimais formados por
campos, um código do país (três dígitos), ura código para a rede (um díe
— no máximo 10 redes) e um campo para o endereçamento dentro da i
(10 dígitos).
No endereçamento horizontal, os endereços não têm relação algi
com o lugar onde estão as entidades dentro da rede. Um exemplo COIT
desse tipo de endereçamento seriam os endereços globalmente adminis
dos, constituídos pelo número de assinatura do usuário, como os utiliza
pelo padrão IEEE 802.
Considerações sobre o roteamento parecem indicar vantagens na u
zação de endereços hierárquicos, uma vez que estes contêm informaç
explícitas sobre o local onde se localizam as entidades, informações que
dem ser usadas quando necessário. Já o endereço horizontal, por ser ín
pendente da localização, vai facilitar os esquemas de reconfiguração
permitir uma mobilidade das entidades sem renumeração das mesmas.
O mapeamento do endereço de um SAP de rede em um endereço
sub-rede (muitas vezes o endereço no nível de enlace se a rede não possi
subcamada de acesso à sub-rede do RM-OSI) para o envio de pacotes é v
tarefa a ser resolvida pelo nível de rede (subcamada dependente da s
rede). Existem duas técnicas usuais para essa conversão: resolução atra
de mapeamento direto e resolução através de vinculação dinâmica.
No mapeamento direto, a estação sabe como computar, de modo ef
ente, o endereço de sub-rede, através de uma função que mapeia o enden
inter-redes no endereço de sub-rede. Por exemplo, suponha o caso do en
reçamento hierárquico onde o campo de endereço de estação correspoi
exatamente ao endereço da estação no nível da sub-rede. Neste caso a c
versão é trivial. Conversões mais complicadas podem ser realizadas atra
de tabelas de conversão e técnicas de acesso rápido a estas tabelas.
Alguns autores e padrões chamara a sub-rede de comunicação de rede; e a rede, possivelm
composta de sub-redes, de inter-rede. Passaremos agora a adotar os termos rede e imer-rede, utilize
apenas o termo sub-rede quando a paiavra rede causar confusão.
10.2.2.1 - Roteamento Centralizado
No roteamento centralizado existe, em algum lugar da rede, um Centro
de Controle de Roteamento (CCR) responsável pelo cálculo das tabelas de
rotas.
A utilização desse modo tem como vantagem o fato do CCR sempre
poder tomar decisões precisas sobre o caminho ótimo, uma vez que possui
todas as informações da rede. No entanto, esse tipo de roteamento apresenta
alguns problemas.
Em primeiro lugar, para se adaptar a um tráfego mutável, o cálculo das
tabelas deve ser realizado com muita frequência. Para uma rede com um
grande numero de nós esse cálculo pode exigir um processamento muito
grande. Se as mudanças, no entanto, não são tão frequentes, por exemplo se
as mudanças que queremos refletir no cálculo das tabelas se restringirem a
mudanças na topologia da rede, que são em geral pouco frequentes, o méto-
do é bastante razoável.
Um segundo problema é o alto tráfego que as linhas que levam ao CCR
deverão suportar, de forma a possibilitar a atualização de informações vinda
dos nós e indo para os nós.
Um terceiro problema 6 a confiabilidade. Uma falha no CCR é crítica.
O aumento da confiabilidade colocando outro CCR redundante pode ser in-
viável pelo custo. Além disso seria necessário algum protocolo para deter-
minação de qual CCR deveria atuar em um dado instante.
Ainda um outro problema vem do fato de que os nós receberão suas ta-
belas em tempos diferentes, devido a retardos diferentes sofridos pelas men-
sagens que as transportaram. Esse fato pode gerar inconsistências de rotea-
mento causando maiores retardos, inclusive nas mensagens que transportam
as tabelas, reaiimentando o processo.
10.2.2.2 - Roteamento Isolado
No roteamento isolado a atualização é realizada com base nas filas de
mensagens para os diversos caminhos e outras informações locais.
Um algoritmo de roteamento isolado simples é o apresentado por
Baran [Baran 64]. Nesse algoritmo um nó ao receber um pacote tenta se li-
vrar dele imediatamente pelo enlace que possui a fila mais curta no momen-
to.
Uma melhora no algoritmo pode ser conseguida combinado-o com o
encaminhamento por rota fixa. Agora, ao encaminhar um pacote, devemos
levar em conta não só a rota estática especificada, mas também o tamanho
304
das filas. Por exemplo, até um certo limiar do tamanho das filas, o pacote
deve ser encaminhado para a menor fila; depois de um certo limiar, deve ser
utilizada a rota estática.
Um outro algoritmo de roteamento isolado também apresentado por
Baran leva em conta que cada pacote deve incluir o nó de origem e um con-
tador de saltos (nós intermediários por onde trafegou). Ao receber um paco-
te, o nó sabe a que distância o nó de origem está, a partir do enlace de che-
gada. Se na sua tabela o nó de origem está a uma distância maior, ele deve
atualizar a tabela. Passado um determinado tempo, cada nó possuirá o cami-
nho mais curto para qualquer outro nó. Como cada nó só registra a troca
para melhor, de tempos em tempos ele deve reiniciar o.processo, de forma
que enlaces que caiam ou fiquem sobrecarregados não afetem a confiabili-
dade da tabela. Se as tabelas forem reiniciadas em um período pequeno, pa-
cotes podem ter de ser transferidos por rotas desconhecidas. Se forem reini-
ciadas em um período longo, os pacotes podem ser transmitidos em rotas
congestionadas ou com enlaces em falha.
Ainda um outro algoritmo de roteamento isolado, simples porém de
grande custo devido à quantidade de pacotes gerados, exige que um pacote
ao chegar em um nó da rede, seja enviado por todos os enlaces de saída do
nó, exceto aquele por onde chegou.
Outros algoritmos e melhoras nos algoritmos apresentados podem ser
encontrados em [Sunshine 77] e [Postei 80a].
10.2.2.3 - Roteamento Distribuído
No modo distribuído, cada no envia periodicamente aos outros nós,
incluindo os gateways, informações locais sobre a carga na rede. Essas in-
formações são utilizadas para o cálculo da nova tabela.
Existem vários algoritmos para o roteamento distribuído. Descrevere-
mos apenas um deles, facilmente realizável em inter-redes formadas por re-
des de difusão, como, por exemplo, inter-redes de redes locais.
No algoritmo, quando um nó quer descobrir o caminho mais curto
(aqui exemplificado pelo caminho de menor retardo) até um nó de destino,
ele envia um pacote de requisição por difusão (em todos os seus enlaces) na
rede, com um campo contendo o endereço do nó de destino e um campo
contendo um caminho, inicialmente com seu endereço. Cada nó intermediá-
rio ao receber o pacote de difusão verifica se o campo caminho contém seu
endereço. Se não contiver, o nó acrescenta ao caminho seu endereço e o di-
funde por todos os seus enlaces. Em caso contrário, simplesmente descarta o
pacote. O nó de destino vai receber vários pacotes, pelos diversos caminhos
que possui desde o nó de origem. O primeiro deles contém no campo cami-
305
o a rota de menor retardo. O nó de destino envia então, como resposta ao
cote recebido, um outro pacote contendo essa rota (por exemplo, através
rota reversa ou uma rota que no momento lhe pareça a de menor retardo
tre o destino/nova origem e a origem/novo destino).
De forma a manter sua tabela de rotas, um nó deve periodicamente
viar pacotes de difusão para descobrimento das rotas. Quanto menor o
Todo, mais adaptável às flutuações de tráfego é o algoritmo. Quanto
ior o período, menor é o tráfego que o algoritmo gera na rede. Uma solu-
) de compromisso deve ser encontrada.
2.2.4 - Roteamento Hierárquico
Quando as redes tornam-se muito grandes, o número de entradas na ta-
a de rotas pode ser tão elevado que as tornam- impossíveis de serem ar-
zenadas ou percorridas. A solução nesse caso é realizar o roteamento hie-
quicamente.
No roteamento hierárquico os nós são divididos em regiões, com cada
capaz de manter as informações de rotas das regiões a que pertence. De-
nos notar que a subdivisão da camada de rede no RM-OSI torna natural
arar cada rede como uma região. Para muitas redes, no entanto, essa hie-
quia em dois níveis é insuficiente, podendo ser necessário agrupar regiões
super-regiões e assim sucessivamente.
Para urna sub-rede única muito extensa com N nós, Kamoun e
'.inrock [Kamoun 791 descobriram que o número ótimo de níveis hierár-
cos é InN, exigindo um total de elnN entradas por nó. Mostraram também
s nesse caso, o aumento no comprimento do caminho médio efetivo cau-
o pelo roteamento hierárquico é suficientemente pequeno para ser des-
zado.
2.2.5 - Transmissão de Pacotes por Difusão
Diversos métodos têm sido propostos para o envio de pacotes por difu-
, isto é, um pacote endereçado a todos os usuários da inter-rede.
Um método simples é o envio de um pacote para cada nó de destino,
m de gerar um tráfego elevado na rede, esse método exige que cada nó
heça todos os destinos.
Uma outra alternativa óbvia é um método por nós já discutido. O mé-
o exige que um pacote, ao chegar em um nó da rede, seja enviado por to-
os enlaces de saída do nó, exceto aquele por onde chegou. Trata-se de
um algoritmo simples, porém de grande custo devido à quantidade de paco-
tes gerados.
Um outro método exige que cada pacote contenha uma lista de destinos
desejados. Cada nó intermediário calcula a partir dessa informação as linhas
de saída necessárias (note que nem sempre é a rota ótima para um determi-
nado destino da. lista). O nó intermediário gera então um pacote para cada
linha com a lista de destino atualizada. O endereçamento com múltiplos
destinos também exige que o nó de origem conheça todos os destinos da
rede.
Ainda em um outro método, quando um pacote de difusão enviado pelo
nó N chega a um nó, ele verifica se o pacote chegou pela linha utilizada para
enviar pacotes a N. Se for o caso, existe uma grande probabilidade de que o
pacote tenha seguido a melhor rota, sendo, portanto a primeira cópia. Nesse
caso o nó retransmite o pacote em todas as suas linhas de saída. Em caso
contrário, o pacote é simplesmente descartado como uma provável duplicata.
Vários problemas devera ser enfrentados em redes com caminhos fe-
chados entre nós. Pacotes por difusão podem ser replicados indefinidamente.
Várias são as técnicas que podem ser adotadas. Na Seção 10.2.2.3 vimos
uma forma de resolver o problema através do registro do caminho percorrido
pelo pacote.
10.2.3 - Tipos de Serviço
A confiabilidade dos pacotes inter-redes está diretamente ligada ao lu-
gar desse protocolo dentro da estrutura hierárquica e aos serviços que ele
oferece ao nível superior.
São dois os tipos de serviço que podem ser oferecidos: com conexão
(circuito virtual) e sem conexão (datagrama).
Nos serviços com conexão (serviços de circuito virtual) um caminho
lógico é estabelecido entre a origem e o destino, conexão esta que perma-
nece até o fim da comunicação, quando deve ser desfeita. Por poder conter
mecanismos implícitos de controle de erro e de fluxo, que garantem entre
outras coisas a sequência de entrega dos pacotes ao destino, esse serviço,
quando oferecido, garante um alto nível de confiabilidade. Além disso, nos
serviços com conexão é possível fazer-se a pré-alocação de recursos (por
exemplo, recursos de armazenamento nos gateways e nós), garantindo um
melhor controle de congestionamento a nível inter-redes. Tal serviço, no
entanto, apresenta um alto grau de complexidade, exigindo dos gateways e
estações, espaço de armazenamento e tempo de processamento nem sempre
disponíveis para sua implementação.
307
 Nos serviços sem conexão (serviços de datagrama) uma mensagem é
tratada de forma individual e entregue ao destino através do caminho mais
conveniente, definido pelos algoritmos de roteamento. A inter-rede não dá
garantias de entrega em sequência dos pacotes e, muitas vezes, nem garantia
de chegada de um pacote ao destino final (datagrama não confiável). A
principal vantagem do serviço é sua simplicidade, deixando para níveis su-
periores o controle de erro, de sequência e de fluxo, caso sejam necessários.
Independente do serviço oferecido pela inter-rede, o serviço oferecido
pelas redes (sub-redes) pode ser com conexão ou sem conexão, com as
mesmas características dos serviços inter-redes citados. É importante salien-
tarmos que o serviço oferecido pela inter-rede é um assunto separado do
serviço de cada rede. Qualquer combinação é possível. Serviços inter-redes
sem conexão usando serviços de rede sem conexão, bem como serviços
inter-redes com conexão usando serviços de redes com conexão parecem
óbvios. A implementação de serviços inter-redes com conexão utilizando
serviços de redes sem conexão também é razoável quando se quer oferecer
um serviço inter-rede mais confiável, A utilização de serviços de redes com
conexão na implementação de um serviço inter-redes sem conexão é um
tanto estranha, e só é realizada porque as redes originalmente não previam o
uso de serviços inter-redes sem conexão.
Em um serviço com conexão (serviço de circuito virtual), não importa
se a nível de rede ou inter-rede, todos os pacotes podem seguir a mesma
rota, que é escolhida no momento do estabelecimento da conexão. Nesse
caso a conexão é usualmente chamada de um circuito virtual. Conexões de
circuito virtual são utilizadas geralmente em sub-redes. Em uma outra op-
ção, os pacotes de um serviço com conexão (serviço de circuito virtual) po-
dem seguir rotas diferentes até o destino.
Cabe aqui abrirmos um parêntese para esclarecermos uma confusão
conceituai que é usualmente alimentada por alguns autores. Existem duas
definições de circuito virtual: uma relativa ao serviço, outra relativa ao en-
caminhamento de pacotes. Do ponto de vista do serviço, o serviço de circui-
to virtual é um outro nome que se dá ao serviço com conexão. A nível de
encaminhamento de pacotes, uma conexão de circuito virtual é aquela em
que todos os pacotes seguem a mesma rota determinada na abertura da co-
nexão. Note que podemos ter um serviço de circuito virtual implementado
ou não em uma conexão de circuito virtual.
A discussão sobre qual tipo de serviço deve oferecer o nível de rede é
antiga e parece interminável. Essa mesma discussão ocorre na camada de
enlace, mas não é tão grave naquele caso. Como vimos, a definição do pa-
drão IEEE 802.2 oferece ambos os serviços. Como as redes locais são ge-
ralmente privadas, os usuários podem optar pelo serviço que desejarem.
308
Com a camada de rede a situação é diferente, pois o serviço é normalmente
oferecido por uma concessionária.
A defesa do serviço sem conexão é fortemente realizada pela comuni-
dade da rede Internet. Argumenta esse grupo que a função do protocolo
inter-redes é mover dados de um ponto a outro da rede e nada mais. A inter-
rede é inerentemente não confiável, não importa como seja projetada. De
qualquer forma, as estações deverão realizar em níveis superiores o controle
de erro e de fluxo, havendo pouca vantagem em realizar essas funções duas
vezes. Em segundo lugar, argumentam que nem todas as aplicações necessi-
tam da confiabilidade oferecida pelos serviços com conexão, pelo contrário,
o atraso introduzido pela realização desses serviços pode ser até prejudicial,
como no caso de transmissão de voz em tempo real. Na verdade é comum
observarmos até mesmo a nível de transporte a opção pelos dois tipos de
serviços: circuito virtual ou datagrama. Uma visão mais interessante portan-
to parece ser a da utilização dos serviços de datagrama no nível inter-redes,
deixando para os níveis superiores a realização do controle de erros, fluxo e
seqíienciação, quando necessários.
Outro grupo, representado pelas concessionárias de telecomunicações,
defende a posição de que a camada de rede (e também a sub-rede) deve ofe-
recer um serviço confiável, baseado em conexões, com mecanismos implíci-
tos de controle de erro e de fluxo, que garantam entre outras coisas a se-
quência de entrega dos pacotes ao destino. E argumenta que a maior parte
dos usuários não está disposta a executar protocolos de transporte comple-
xos em suas máquinas, desejando um serviço confiável, suprido pelo serviço
com conexão. Além disso, argumenta que em serviços com conexão é possí-
vel se fazer a pré-alocação de recursos (por exemplo, recursos de armaze-
namento nos gateways e nós), garantindo um melhor controle de congestio-
namento a nível inter-redes.
A princípio, o lobby dos defensores do serviço com conexão foi mais
forte, tendo sido esse o serviço escolhido originalmente pelo RM-OS1.
Contudo as pressões do grupo desejoso do serviço sem conexão não dimi-
nuíram, fazendo com que a ISO modificasse posteriormente o RM-OSI de
forma a incluir ambos os serviços. Na realidade, a modificação foi mais ge-
ral, incluindo ambos os serviços em todas as camadas a partir da de enlace,
inclusive a camada de rede.
As primitivas oferecidas pelo serviço de rede são muito parecidas com
as apresentadas pelo padrão IEEE 802.2 discutido no Capítulo 9, e por isso
estão apenas resumidas aqui.
No serviço com conexão, um grupo de primitivas é responsável pelo
estabelecimento da conexão, um outro grupo pela desconexão e um outro
grupo pela troca de dados. Ainda um outro grupo é responsável pelo relato
3Q9
 falhas irrecuperáveis na rede, são as primitivas de RESET. Depois que
mitivas de RESET são trocadas (causadas por queda da entidade de
nsporte ou do próprio fornecedor do serviço de rede), os dados presentes
; filas são descartados, sendo responsabilidade da camada dé transporte
uperã-los (a camada de rede não é de todo confiável. como já observa-
s).
No serviço sem conexão, um grupo de primitivas é responsável pela
;a de dados, e um outro grupo foi projetado de forma que usuários da
nada de rede troquem informações sobre as características médias de en-
;a de dados ao destino especificado.
Lembrando que cada conexão é estabelecida entre SAPs de rede e cada
:a de pacotes é realizada entre SAPs de redes, terminamos esta seção
esentando o formato dos endereços dos SAPs da camada de rede do RM-
I.
Os endereços foram projetados de forma a acomodar diversos tipos de
ereçamento utilizados hoje em dia. Cada endereço tem três campos. O
neiro campo identifica o tipo de endereço presente no terceiro campo. Os
igos foram alocados de forma que o terceiro campo contenha endereços
pacote de rede, endereços telefónicos, endereços ISDN (apresentada na
te III), números de telex etc. O segundo campo especifica o domínio ao
1 pertence o endereço presente no terceiro campo. Por exemplo, no caso
rndereço telefónico, esse campo pode indicar o código do país.
2.4 - Controle de Congestionamento
Quando temos pacotes em excesso em uma sub-rede, ou parte de uma
-rede, o desempenho da rede se degrada e dizemos que temos um con-
'ionamento. Os congestionamentos podem ser causados por vários fato-
se os nós da rede são lentos, se o tráfego de entrada exceder a capaci-
2 das linhas de saída em um nó etc.
Uma rede congestionada pode chegar à condição de impasse
idlock). Suponha, por exemplo, um nó A de uma rede com conexão de
uito virtual com todo seu espaço de armazenamento ocupado com paco-
a espera para serem transmitidos (ou retransmitidos) para o nó B, que
todo seu espaço ocupado com pacotes a espera para serem transmitidos
retransmitidos) para o nó A. Os dois nós ficarão bloqueados. Várias
>íveis soluções para o problema de impasse, e prevenção de impasses,
discutidas na literatura [Merlin 80, Blazewicz 87, Lai 82, Gopal 85]'.
Antes de começarmos a discutir alguns algoritmos de controle de con-
ionamento, vale a pena salientar que ele é diferente do controle de fluxo,
embora sejam muitas vezes confundidos. O controle de congestionamento é
realizado de forma a garantir que a rede seja capaz de transportar o tráfego
oferecido. É um controle global envolvendo todos os recursos da rede. Já o
controle de fluxo se relaciona com o tráfego entre um transmissor e um de-
terminado receptor. Sua função é garantir que um transmissor não transmita
dados em uma velocidade maior que a capacidade do receptor.
Algumas redes tentam evitar o congestionamento pelo controle de
fluxo, embora seja impossível controlar a quantidade total de tráfego na rede
usando regras de controle de fluxo fim a fim.
O problema com o controle do fluxo é que ele não pode ser ajustado
pela taxa média do tráfego gerado, pois isso limitaria uma aplicação cujo
tráfego possui uma taxa variável, resultando em um serviço ruim nos mo-
mentos de pico do tráfego. Por outro lado, se o controle de fluxo estiver
ajustado para permitir que a taxa de pico do tráfego seja aproximada, ele
tem pouco valor como controle de congestionamento.
10.2.4.1 - Descarte de Pacotes
Neste método de controle de congestionamento, se um pacote chegar a
um nó da rede e não houver espaço para armazená-lo ele é simplesmente jo-
gado fora.
Em uma rede com serviço de datagrama o congestionamento está re-
solvido. Em uma rede com serviço de circuito virtual uma cópia do pacote
deve ser mantida em algum lugar de modo a poder ser retransmitida. Neste
caso uma situação de impasse, conforme a descrita na seção anterior pode
ocorrer.
O descarte indiscriminado de pacotes pode levar a situações onde es-
tamos descartando exatamente uma confirmação que liberaria um.buffer do
nó. Uma melhora do algoritmo pode ser conseguida reservando permanen-
temente um buffer por linha de entrada, a fim de permitir que todos os paco-
tes que cheguem sejam inspecionados. Cada pacote recém-chegado é exami-
nado pelo nó, que faz uso de qualquer confirmação transportada, para só de-
pois descartar de algum modo o pacote. O pacote recém-chegado pode até
ser recebido, caso tenha transportado uma confirmação que liberou um
buffer.
Suponha agora a situação onde todos os buffers (exceto possivelmente
o buffer reservado para cada entrada) tenham sido alocados a uma única li-
nha de saída de um nó. Qualquer pacote que chega para ser despachado por
qualquer uma das outras linhas de saída são descartados por falta de buffer,
mesmo que a linha de saída correspondente esteja completamente ociosa.
Para evitar esse problema, Irland [Irland 78] propôs uma modificação no al-
311
(
goritmo, que limita o número de buffers que podem estar associados a uma
linha de saída, permitindo sempre haver buffers disponíveis para outras li-
( nhas. Irland estudou diversos algoritmos para determinar o número máximo
de buffers m em uma fila de uma linha de saída, de um nó que possui k buff-
ers e s linhas de saída. O valor ótímo de m é uma função complicada do trá-
( fego da rede, mas Irland mostrou que bons resultados podem ser consegui-
dos com o valor de m~ k I . Ainda uma outra possibilidade é limitar não
só o número máximo, mas também o número mínimo de buffers por linha.
Nem sempre o pacote que chega deve ser descartado quando não en-
contra espaço para armazenamento. De forma a minimizar a banda passante
desperdiçada no descarte de pacotes, podemos descartar o pacote da fila que
( viajou uma distância menor. Esta poderia ser uma outra variante no algo-
ritmo de descarte.
« miar, a linha de saída entra em estado de alerta.
( Quando um pacote chega ao nó e deve ser despachado por uma linha
10.2.4.2 - Pré-alocação de Buffers
( pacote (de alerta) contendo o seu identificador e o nó de destino do pacote
Se conexões de circuito virtual são usadas em um serviço com cone-
xão, o congestionamento pode ser resolvido pela pré-alocação de buffers
( para a conexão, no momento de seu estabelecimento. Se um pacote de pedi-
do de conexão chegar a um nó e todos os seus buffers já estiverem reserva-
(
dos, uma nova rota deve ser buscada. Se não for possível achar uma rota a
! conexão não deve ser concretizada.
Como nesse método os recursos de armazenamento são alceados de
forma permanente, não há qualquer risco de congestionamento. Por outro
lado há um uso ineficiente dos recursos, uma vez que um buffer pré-alocado
< não pode ser compartilhado, mesmo não estando em uso. Por ser caro alocar
recursos a um circuito virtual ocioso, muitas vezes esse método é usado
apenas em circuitos virtuais em que o retardo pequeno é condição essencial,
por exemplo, na transmissão de voz.
Uma variante do método pode ser conseguida associando um tempori-
( zador a cada buffer. Se o buffer não for utilizado dentro de um certo tempo,
ele é liberado temporariamente para um pacote de outra conexão.
10.2.4.3 - Controle Isorrítmico
X Um outro método para controle de congestionamento foi proposto por
Davies [Davies 72], tentanto evitar o congestionamento pela limitação do
número de pacotes em trânsito na sub-redè.
< rede, para.ligação DTE-DCE. Esses padrões ficaram conhecidos coletiva-
Nesse método existem permissões que circulam pela sub-rede. Sempre
que um nó deseja introduzir um novo pacote na sub-rede ele deve primeiro
(
( 312
capturar uma permissão e destruí-la. A permissão é regenerada pelo nó que
recebe o pacote no destino.
O. grande problema desse método está na distribuição das permissões,
que depende das aplicações na rede. Além disso, o próprio passeio aleatório
das permissões causa um tráfego extra na sub-rede, roubando seu desempe-
nho. Mais ainda, a perda de uma permissão por uma falha qualquer deve ser
recuperada, sob pena de diminuirmos a capacidade de transporte da rede.
10.2.4.4 - Controle de Tráfego no Enlace
Neste método cada nó monitora a utilização percentual de cada uma de
suas linhas de saída. Sempre que a utilização passar de um determinado li-
em estado de alerta, o nó deve enviar ao nó de origem do pacote, ura outro
original. O pacote original é marcado, de forma a não gerar mais pacotes de
alerta, e encaminhado de forma usual. O nó de origem, ao receber o pacote
de alerta, é obrigado a reduzir o tráfego para o destino especificado, que se-
gue por uma rota que passa pelo nó que o alertou.
Como provavelmente antes de receber o pacote de alerta o nó de ori-
gem já enviou vários pacotes para o mesmo destino, passando pela linha
congestionada, vários outros pacotes de alerta chegarão e devem ser ignora-
dos, pois o tráfego já foi reduzido quando da chegada do primeiro alerta.
Dessa forma, ao receber um pacote de alerta, o nó ignora outros pacotes de
alerta por um período determinado. Se quando está disponível para receber
pacotes de alerta o nó não os recebe durante um período também determi-
nado, o nó pode aumentar novamente o fluxo de dados. Variações desse al-
goritmo são discutidas em [Tanembaum 89].
1 0 . 3 - O Protocolo X-25
Nosso primeiro exemplo de implementação da camada de rede é o pa-
drão X-25 PLP (Paclcet Layer Protocol) da ITU-T.
Para evitar que redes públicas geograficamente distribuídas desenvol-
vessem interfaces diferentes de acesso, o ITU-T (então chamado CCITT)
propôs em 1974 padrões de implementação dos níveis físico de enlace e de
mente como X-25 PLP, ou simplesmente X-25. A Figura I0.2 ilustra uma
313
rede X-25. Note na figura que o ITU-T não define os protocolos internos à
sub-rede, isto é, a comunicação DCE-DCE e DCE-DSE.
No nível físico, o X-25 faz referência aos padrões X-21 e X-21 bis, que
definem respectivamente as interfaces digital e analógica, conforme vimos
resumidamente no Capítulo 6.
Figura 10.2: X-25 e o Modelo OSI.
No nível de enlace os protocolos utilizados são o LAP e o LAPB, com
características bastante semelhantes ao padrão IEEE 802.2 por nós já estu-
dado.
No nível de rede, é utilizado o serviço com conexão com circuito vir-
tual. Duas formas de conexões são possíveis: circuitos virtuais permanentes
(conexões preestabelecidas) e chamadas virtuais (conexões alocadas em
tempo de comunicação). No estabelecimento de uma conexão, recursos es-
peciais (facilidades) para a conexão podem ser negociados. Os recursos po-
dem variar de uma rede para outra; um exemplo de recurso possível é a tari-
fação reversa (chamada a. cobrar). Urna vez estabelecida uma conexão, os
dados podem ser trocados nas duas direções. Qualquer um dos lados pode
encerrar uma conexão.
O sistema de endereçamento usado no X-25 é definido na recomenda-
ção X. 1.21 do ITU-T, conforme já discutimos naSeção 1.0.2.1.
Os dados trocados em uma conexão sofrem controle de fluxo e de erro,
usando uma janela deslizante, conforme estudado no Capítulo 7. A confir-
314
mação de recebimento de um pacote pode ser de dois tipos, selecionados por
um bit (bit D) do pacote de dados. Se D=0, a confirmação significa que o
DCE recebeu o pacote e não o DTE remoto. Se D=i, a confirmação indica
que o pacote foi entregue ao DTE remoto, representando, portanto, uma
confirmação fim a fim.
Como todo nível de rede, o X-25 tem também de lidar com falhas na
rede. Os pacotes de RESET e RESTART são usados para recuperação de
falhas variadas. Um RESET.tem como efeito a reiniciação de todos os pa-
râmetros de uma conexão, por exemplo, a janela. Um RESTART significa a
reiniciação de todas as conexões. Da mesma forma que todos os protocolos
de rede, dados perdidos, quando de um RESET ou RESTART, devem ser
recuperados pelo nível de transporte.
O padrão original do X-25 (1976) não incluía a facilidade de data-
grama. A demanda por serviços de datagrama, no entanto, era alta, fazendo
com que o ITU-T aceitasse tanto as propostas (conflitantes) dos Estados
Unidos quanto do Japão, para inclusão do serviço de datagrama no padrão.
Contudo os PTTs não implementaram tal serviço, tendo como consequência
sua retirada do padrão em 1984.
Apesar disso, permanecia a demanda por um serviço sem conexão, le-
vando o ITU-T a concordar, em 1984, com a adição de ifm recurso chamado
fast select. Quando esse recurso é usado, o pacote de estabelecimento de co-
nexão (CALL REQUEST) é expandido de modo a incluir 128 bytes do usu-
ário. O recurso fast select é solicitado como uma facilidade da conexão. No
que toca à rede, esse pacote é uma tentativa de estabelecimento de conexão,
mas o DTE chamado a rejeita com um pacote CLEAR REQUEST, que tam-
bém é expandido para incluir 128 bytes de dados de resposta. Maiores deta-
lhes sobre o X-25 podem ser obtidos da referência [CCITT 84c].
10.4 - O Protocolo IP (Internet Protocol)
O IP [Postei 81b] foi projetado para permitir a interconexão de redes
de computadores que utilizam a tecnologia de comutação de pacotes. O
ambiente inter-rede consiste em hosts conectados a redes que por sua vez
são interligadas através de gàteways, como mostra a Figura 10.3. As redes
que fazem parte da inter-rede variam de redes locais (por exemplo, redes
Ethernet) até redes de grande porte (por exemplo, a Arpanet).
Os gàteways da Internet são também chamados de routers (roteadores).
As características dos roteadores serão discutidas no Capítulo 1 D
315
rede X-25. Note na figura que o ITU-T não define os protocolos internos à
sub-rede, isto é, a comunicação DCE-DCE e DCE-DSE.
No nível físico, o X-25 faz referência aos padrões X-21 e X-21 bis, que
definem respectivamente as interfaces digital e analógica, conforme vimos
resumidamente no Capítulo 6.
Sistema Aberto „,„•„ .. .
sistema Aberto
Protocolo do Nível Físico X-25
Figura 10.2: X-25 e o Modelo OSI.
No nível de enlace os protocolos utilizados são o LAP e o LAPB, com
características bastante semelhantes ao padrão IEEE 802.2 por nós já estu-
dado.
No nível de rede, é utilizado o serviço com conexão com circuito vir-
tual. Duas formas de conexões são possíveis: circuitos virtuais permanentes
(conexões preestabelecidas) e chamadas virtuais (conexões alocadas em
tempo de comunicação). No estabelecimento de uma conexão, recursos es-
peciais (facilidades) para a conexão podem ser negociados. Os recursos po-
dem variar de uma rede para outra; um exemplo de recurso possível é a tari-
fação reversa (chamada a cobrar). Uma vez estabelecida uma conexão, os
dados podem ser trocados nas duas direções. Qualquer um dos lados pode
encerrar uma conexão.
O sistema de endereçamento usado no X-25 é definido na recomenda-
ção X. 121 do ITU-T, conforme já discutimos na Seção 1.0.2.1.
Os dados trocados em uma conexão sofrem controle de fluxo e de erro,
usando uma janela deslizante, conforme estudado no Capítulo 7. A confir-
314
i
mação de recebimento de um pacote pode ser de dois tipos, selecionados por
um bit (bit D) do pacote de dados. Se D=0, a confirmação significa que o
DCE recebeu o pacote e não o DTE remoto. Se D=l, a confirmação indica
que o pacote foi entregue ao DTE remoto, representando, portanto, uma
confirmação fim a fim.
Como todo nível de rede, o X-25 tem também de lidar com falhas na
rede. Os pacotes de RESET e RESTART são usados para recuperação de
falhas variadas. Um RESET.tem como efeito a reiniciação de todos os pa-
râmetros de uma conexão, por exemplo, a janela. Um RESTART significa a
reiniciação de todas as conexões. Da mesma forma que todos os protocolos
de rede, dados perdidos, quando de um RESET ou RESTART, devem ser
recuperados pelo nível de transporte.
O padrão original do X-25 (1976) não incluía a facilidade de data-
grama. A demanda por serviços de datagrama, no entanto, era alta, fazendo
com que o ITU-T aceitasse tanto as propostas (conflitantes) dos Estados
Unidos quanto do Japão, para inclusão do serviço de datagrama no padrão.
Contudo os PTTs não implementaram tal serviço, tendo como consequência
sua retirada do padrão em 1984.
Apesar disso, permanecia a demanda por um serviço sem conexão, le-
vando o ITU-T a concordar, em 1984, com a adição de rim recurso chamado
fast select. Quando esse recurso é usado, o pacote de estabelecimento de co-
nexão (CALL REQUEST) é expandido de modo a incluir 128 bytes do usu-
ário. O recurso fast select é solicitado como uma facilidade da conexão. No
que toca à rede, esse pacote é uma tentativa de estabelecimento de conexão,
mas o DTE chamado a rejeita com um pacote CLEAR REQUEST, que tam-
bém é expandido para incluir 128 bytes de dados de resposta. Maiores deta-
lhes sobre o X-25 podem ser obtidos da referência [CCITT 84c].
10.4 - O Protocolo IP (Internet Protocol)
O IP [Postei 81b] foi projetado para permitir a interconexão de redes
de computadores que utilizam a tecnologia de comutação de pacotes. O
ambiente inter-rede consiste em hosts conectados a redes que por sua vez
são interligadas através de gateways, como mostra a Figura 10.3. As redes
que fazem parte da inter-rede variam de redes locais (por exemplo, redes
Ethernet) até redes de grande porte (por exemplo, a Arpanet).
Os gateways da Internet são também chamados de routers (roteadores).
As características dos roteadores serão discutidas no Capítulo 11.-
315

Figura 10.3: Conceito de inter-rede.
Ao contrário do protocolo X.25, o protocolo IP é um protocolo sem
conexões. Sua função é transferir blocos de dados denominados datagramas
da origem para o destino, onde a origem e o destino são hosts identificados
por endereços IP. O protocolo IP também fornece o serviço de fragmentação
e remontagem de datagramas longos, quando necessário, para que eles pos-
sam ser transmitidos através de redes onde o tamanho máximo permitido
para os pacotes é pequeno.
O serviço oferecido pelo IP é sem conexão. Portanto, cada datagrama
IP é tratado como uma unidade independente que não possui nenhuma rela-
ção com qualquer outro datagrama. A comunicação é não-confiável, não
sendo usados reconhecimentos fim a fim ou entre nós intermediários. Ne-
nhum mecanismo de controle de erros nos dados transmitidos é utilizado,
exceto um checksum do cabeçalho que garante que as informações nele
contidas, que são usadas pelos gateways para encaminhar os datagramas,
estão corretas. Nenhum mecanismo de controle de fluxo é empregado.
Algumas-das principais características desse protocolo são:
• Serviço de datagrama não-confiável.
• Endereçamento hierárquico.
• Facilidade de fragmentação e remontagem de pacotes.
• Identificação da importância do datagrama e do nível de contabili-
dade exigido.
• Identificação da urgência de entrega e da ocorrência futura ou .não
de pacotes na mesma direção (pré-alocação, controle de congestio-
namento).
316
• Campo especial indicando qual o protocolo de transporte a ser utili-
zado no nível superior.
• Roteamento adaptativo distribuído nos gateways.
• Descarte e controle de tempo de vida dos pacotes inter-redes no
gateway.
10.4.1 - Endereços IP
Os endereçou IP são números com 32 bits, normalmente escritos como
quatro octetos (em decimal), por exemplo 128.6.4.7. A primeira parte do en-
dereço identifica uma rede específica na inter-rede, a segunda parte identi-
fica um host dentro dessa rede. Devemos notar que um endereço IP não
identifica uma máquina individual, mas uma conexão à inter-rede. Assim,
um gateway conectando ;?. redes tem n endereços IP diferentes, um para cada
conexão.
Os endereços IP podem ser usados para nos referirmos tanto a redes
quanto a um host individual. Por convenção, um endereço de rede tem o
campo identificador de host com todos os bits iguais a 0. Podemos também
nos referir a todos os hosts de uma rede através de um endereço por difusão,
quando, por convenção, o campo identificador de host deve ter todos os bits
iguais a l. Um endereço com todos os 32 bits iguais a J é considerado um
endereço por difusão para a rede do host origem do datagrama. O endereço
127.0.0.0 é reservado para teste (loopback) e comunicação entre processos
da mesma máquina.
IP utiliza três classes diferentes de endereços. A definição de classes
de endereços deve-se ao fato do tamanho das redes que compõem a inter-
rede variar muito, indo desde redes locais de computadores de pequeno
porte, até redes públicas interligando milhares de hosts.
Na primeira classe de endereços, classe A, o bit mais significativo é 0,
os outros 7 bits do primeiro octeto identificam a rede, e os 24 bits restantes
definem o endereço local. Essa classe de endereços é usada para redes de
grande porte, os endereços de rede variam de 1 a 126, e cada rede tem ca-
pacidade de endereçar cerca de 16 milhões de hosts. A Arpanet é um exem-
plo de uma rede com endereços classe A.
A classe B de endereços usa dois octetos para o número da rede e dois
para endereços de hosts. Os.endereços de redes classe B variam na faixa cie
1.28.1 até 191.255 (os números 0 e 255 do segundo octeto, e 127 no primeiro
são usados para funções especiais), e cada rede pode interligar cerca de 65
mil hosts.
317
 Finalmente, os endereços classe C utilizam três octetos para identificar
;de e um para o host. Os endereços de rede situam-se na faixa de 192.1:1
223.254.254, e cada rede pode endereçar 254 hosts. Os endereços acima
223 no primeiro octeto foram reservados para uso futuro [Hedrick 87],
4.1.1 - Mapeamento de Endereços
O mapeamento do endereço de um SAP de rede em um endereço de
-rede (muitas vezes o endereço no nível de enlace se a rede não possui a
camada de acesso à sub-rede do RM-OSI) foi discutido na Seção 10.2:1.
as técnicas foram apresentadas: resolução através de mapeamento. direto
•solução através de vinculação dinâmica.
A resolução através de vinculação dinâmica pode ser realizada através
um protocolo denominado ARP (Address Resolution Protocol). O ARP
imite a um host encontrar o endereço de sub-rede de outro host na mesma
-rede, através do envio de um datagrama por difusão na sub-rede, con-
ne apresentamos na Seção 10.2.1. Na realidade, nessa seção descrevemos
tamente o funcionamento básico do ARP. Alguns refinamentos podem
acrescentados ao protocolo, como discutido em [Plummer 82].
Para identificar um quadro carregando uma requisição ou resposta
P, o campo type do cabeçalho do quadro de enlace deve ter um código
npriado. Por exemplo, no padrão IEEE 802.3 o código em hexadecimal é
6.
Tomemos agora o problema inverso. Suponha que por algum motivo
i máquina não saiba seu endereço IP. Como ela poderia descobrir esse
ereço? O protocolo RARP (Reversa Address Resolution Protocol),
atado do protocolo ARP, tem a resposta.
A solução seria termos um servidor de endereços IP na rede. Quando
t máquina quisesse saber seu endereço IP ela mandaria um quadro por
são dentro de sua rede, que seria reconhecido como uma requisição pelo
idor. Nesse quadro, a máquina se identificaria através de seu endereço
ub-rede (o endereço no nível de enlace se a rede não possui a subcamada
icesso à sub-rede do RM-OSI). A partir desse endereço, o servidor des-
piria o endereço IP e o enviaria à maquina requisitante.
Na prática, o protocolo RARP permite que qualquer máquina descubra
dereço ÍP de qualquer outra máquina, desde que conheça o seu endereço
ub-rede. Maiores detalhes sobre o protocolo RARP podem ser obtidos
eferência [Finlayson 84].
10.4.2 - Formato do Datagrama IP
A Figura 10.4" mostra o formato de um datagrama LP. O campo vers
identifica a versão do protocolo IP que montou o quadro. Como o tamanho
do cabeçalho de um datagrama IP pode variar, o campo hlen indica seu
comprimento em palavras de 32 bits. O campo service type armazena parâ-
metros que determinam a qualidade do serviço que deve ser prestado pelas
redes por onde passa o datagrama. O campo options possui tamanho e con-
teúdo variáveis, podendo inclusive ser vazio. Este campo é utilizado para
transportar informações relativas a procedimentos de controle e testes. O
campo total length armazena o tamanho do datagrama (cabeçalho + dados).
Os campos identification, flags e fragment offset são usados no procedi-
mento de fragmentação e remontagem de datagramas, e sua função será
explicada na Seção 10.4.3.
0 7 15 23 31
[ Oclèto i F Octeto. 2 ; ; Oclato 3 V :-[y- . Octeto;4 ' |
VERS | HLEN-| SERVICE TYPEp TOTAL' LENGTK
IDENTIFICATION FLAGS | FRAGMENT OFFSET
• TIME TO LIVE |; PROTOCOL . HEADER CHEGKSUM .
•' " .' SOUROE IP ADDRESS
DESfiNATlON IP ADDRESS ' •
IP:OPTIONS(IFANY) j PADDING
~~ DATA
Figura 10.4: Formato de ura datagrama IP.
O campo time to live é usado para limitar o tempo de transmissão dos
datagramas. Esse campo recebe um valor inicial quando o datagrama é cria-
do. Sempre que um gateway retransmite o datagrama ele decrementa o valor
desse campo. Quando o valor time to live atinge o valor zero, o datagrama é
descartado. Esse evento é um sintoma de que o datagrama estava em loop,
ou de que há um grande congestionamento, ou mesmo um erro na atribuição
do valor inicial do campo time to live. Uma outra utilidade desse campo é
discutida na Seção 10.4.3. O campo protocol identifica o protocolo de trans-
porte que gerou e que irá receber o datagrama no destino. O campo header
checksum é usado pelos gateways para verificar se as informações do cabe-
çalho de um datagrama LP estão corretas, pois não faz nenhum sentido um
gateway basear-se em informações inconsistentes para rotear o datagrama.
Cabe mais uma vez salientar que o IP não verifica se .os dados transportados
no datagrama estão corretos. Essa função é deixada para os níveis superiores
de protocolos. Os campos source IP address e destination IP address carre-
gam respectivamente os endereços dos hosts origem e destino. O campo IP
319
Options é usado para informações de segurança, roteamento na origem, rela-
tórios de erro, depuração, fixação de hora etc. O campo data carrega os da-
dos do datagrama IP.
10.4.3 - Fragmentação e Remontagem de Datagramas
A arquitetura Internet TCP/IP foi projetada para interligar redes das
mais diversas tecnologias. Infelizmente, o tamanho máximo permitido para
os pacotes varia de uma tecnologia de rede para outra. Por exemplo, enquan-
to os pacotes Ethernet podem ter 1500 octetos, os pacotes da Arpanet têm
cerca de 1000.
O campo flags do cabeçalho do datagrama DP é composto dos bits DF
(don't fragmeni) e MF (more fragments). Quando DF=i, os roteadores não
podem fragmentar o datagrama, pelo fato de que o destino será incapaz de
juntar novamente as partes. Se um datagrama desse tipo não puder ser
transmitido através da rede, ele tem de ser roteado de forma a contornar a
rede, ou então ser descartado.
A fragmentação de um datagrama IP é necessária quando ele é monta-
do em uma rede cujo tamanho do pacote excede o limite permitido em uma
das redes intermediárias que o datagrama tem que atravessar para atingir seu
destino.
Vejamos um exemplo onde um datagrama original D 0 é dividido em
dois novos datagramas: D| e D 2 . Para fragmentar um datagrama o módulo W
cria os novos datagramas e copia para eles o conteúdo do cabeçalho do da-
tagrama original. A Figura 10.4 mostra o cabeçalho de um datagrama IP.
Quando a cópia é feita, o valor do campo Identification permanece inalte-
rado. Esse campo, junto com os endereços de origem e destino, e com a
identificação do protocolo de transporte, serve para especificar todos os
fragmentos de um mesmo datagrama IP.
O módulo D? toma providências para que um número de identificação
só seja reutilizado depois de decorrido um tempo suficiente para o descarte
do datagrama que utilizou anteriormente a mesma identificação. Isto é pos-
sível, devido ao fato de que os datagramas IP têm um tempo máximo de vida
especificado pelo campo time-to-live em seu cabeçalho, conforme foi expli-
cado na Seção 10.4.2.
Os dados carregados pelo datagrama original, D0, são divididos em
blocos de 8 octetos (64 bits). O primeiro datagrama, D,, é montado com um
número inteiro de blocos de dados, denominado NFB (número de blocos de
dados do fragmento). No seu cabeçalho, o campo total length, que contém o
valor copiado do datagrama original, é atualizado passando a carregar o
320
comprimento do datagrama que acabou de ser criado. Esse campo pas;
armazenar o número de octetos do cabeçalho, somado ao número de oct<
de dados do datagrama Dj. Ainda no datagrama Dj-, oflag MF do cabeçj
recebe o valor 1, especificando more-fragtnents.
A segunda parte dos dados é colocada no outro datagrama recém-c
do, D2. O campo t o tal length desse datagrama também é atualizado, pas:
do a carregar o. número de octetos desse datagrama (cabeçalho + dados^
Jlag more fragments mantém o valor copiado do datagrama D 0 , pois elè j
prio pode ter sido anteriormente fragmentado. O campo fragment-offset
cebe a soma do valor que tinha em Do com o valor NFB (que indica o nú
ro de blocos de dados transportado no fragmento anterior do datagrama 1
Aqui cabem duas observações. A primeira delas é que o valor do car
fragment-offset do datagrama original é utilizado na soma porque, nc
mente, o datagrama original pode já ter passado por um processo de fi
mentação anterior. A segunda observação é que se fossem necessário:
datagramas, o NFB usado deveria indicar o número de blocos carrega
nos N-l datagramas anteriores.
Para remontar o datagrama original, o módulo IP destinatário comi
os datagramas IP que possuem o mesmo valor para os campos identificai,
protocol, source address e destination address. A recombinação é feita a
vés da colocação da porção de dados de cada fragmento na posição rela1
indicada pelo valor do campo fragment-offset de seus cabeçalhos. O prin
ro fragmento possui o fragment-offset igual a 0, e o último fragmento tei
flag more fragments igual a 0.
10.4.4 - Roteamento
Roteamento inter-redes é a principal função do protocolo IP. O pr<
colo assume que os hosts sabem enviar datagramas para qualquer outro 1
conectado à mesma rede. A função de roteamento torna-se mais compl
quando uma entidade IP deve transmitir um datagrama cujo destinatário
está ligado à mesma rede que ela. Nesse caso, parte da função de roteame
é transferida para os gateways (roteadores), cabendo ao módulo IP no 1
apenas o envio do datagrama a um dos gateways conectados a sua rede:
teamento hierárquico.
Os roteadores são frequentemente computadores normais que possu
mais de uma interface de rede. Nesse caso, a função de roteamento é exe
tada por software. Porém, em casos onde o tráfego inter-rede é muito a
são utilizados equipamentos projetados especificamente para executar a
refa de roteamento. A Figura 10.5 mostra um exemplo de uma inter-rede i