• a chamada virtual (virtual calls), que é similar a uma chamada telefônica comum, a
qual é caracterizada pelo estabelecimento de uma conexão, a troca de dados e a
liberação de conexão;
• o circuito virtual permanente (permanent virtual circuits), que funciona como uma
linha especializada, disponível a todo momento, de modo que basta aos DTEs
efetuar a transferência dos dados (uma conexão permanente é estabelecida na
inicialização).
No caso das chamadas virtuais, como mostra a figura 2.3.30, quando um DTE quer
dialogar com um outro DTE, ele deve, inicialmente, estabelecer a conexão; ele constrói,
então, um pacote CALL REQUEST enviando-o ao DCE. Em seguida, a subrede encaminha o
pacote ao DCE destinatário que vai passá-lo ao DTE correspondente. Se a conexão pode ser
estabelecida, o DTE destinatário vai enviar um pacote CALL ACCEPTED indicando a
aceitação da chamada.
DTE P rotocolo X.25 P LP DTE
(D ata T erm inal
Eq uipm e n t)
DCE DCE
(D ata C ircu it-
term inating
Eq uipm e n t)
DSE
(D a ta S w itch ing
Ex chan ge)
IM P (ISO)
Figura 2.3.29 - O protocolo de rede X.25 PLP
Com a conexão estabelecida, os dois DTEs podem, então trocar pacotes de dados
através de uma linha de comunicação bidirecional.
Quando um dos DTEs deseja terminar o diálogo, ele envia um pacote CLEAR
REQUEST ao seu par que vai responder com um pacote CLEAR CONFIRMATION em
reconhecimento.
81
DTE local interface interface DTE remoto
DTE-DCE DTE-DCE
CALL
CALL
etapa de
chamada CALL
CALL
DADOS
DADOS
etapa de troca de um número
transf. de DADOS arbitrário de pacotes
dados de dados
DADOS
CLEAR
CLEAR
etapa de
CLEAR
liberação
CLEAR
Figura 2.3.30 - Comunicação entre dois DTEs via X.25.
A figura 2.3.31 apresenta o formato de um pacote CALL REQUEST. Este pacote,
assim como os demais do protocolo X.25, inicia por um cabeçalho de 3 bytes. Os campos
GRUPO e CANAL compõem um número de circuito virtual a ser utilizado no diálogo, este
número codificado em 12 bits, o que significa que pode-se utilizar até 4096 circuitos virtuais
distintos, sendo que o número 0 é reservado pelo protocolo. O campo TIPO permite
identificar o tipo do pacote enviado, o bit CM estando a 1 nos pacotes de controle e a 0 nos
pacotes de dados. O cabeçalho é, de fato, comum a todos os pacotes do X.25. Já os campos a
seguir são específicos ao pacote CALL REQUEST. Os dois campos seguintes, TAM. END.
INIC. e TAM. END. RESP. representam os tamanhos dos endereços do iniciador e do
respondedor, respectivamente. Eles são codificados na forma de dígitos decimais, em 4 bits
por campo.
O sistema de endereçamento do X.25 é similar ao do sistema telefônico, onde cada
usuário é identificado por um número decimal formado pelo código do país, um código de
rede e um endereço interior da rede correspondente, este endereço podendo conter até 14
dígitos decimais. O campo TAM. FACILIDADES, permite indicar o tamanho do campo
seguinte, FACILIDADES, que por sua vez permite ao usuário requisitar serviços especiais
(facilidades) necessários à comunicação. Um exemplo destas «facilidades» pode ser a
chamada a cobrar (PCV). Finalmente, o campo DADOS USUÁRIO permite ao DTE enviar até
16 bytes de informação com o pacote CALL REQUEST.
O pacote de dados do X.25 é mostrado à figura 2.3.32. O bit Q indica dado
qualificado. Este bit não tem grande utilidade no protocolo de Rede, mas ele permite aos
82
protocolos das camadas superiores fazer a distinção entre suas mensagens de controle e suas
mensagens de dados. O campo CM é sempre 0 para os pacotes de dados.
Os campos SEQÜÊNCIA e SUPERPOS. são utilizados no controle de fluxo com janela
de antecipação. O bit D indica o significado do campo SUPERPOS.: se D = 0, o
reconhecimento vai indicar que o DCE local recebeu o pacote; se D = 1, o reconhecimento vai
indicar que o DTE remoto recebeu o pacote. O campo M (More) indica a pertinência de um
pacote a um grupo de pacotes considerado.
8 bits
0 0 0 1 GRUPO
CANAL
TIPO CM
TAM. END. INIC. TAM. END. RESP.
ENDEREÇO INICIANTE
ENDEREÇO RESPONDEDOR
0 0 TAM. FACILIDADES
FACILIDADES
DADOS USUÁRIO
Figura 2.3.31 - Pacote CALL REQUEST do X.25.
8 bits
Q D MÓD. GRUPO
CANAL
SUPERPOS. M SEQUÊNCIA 0
DADOS
Figura 2.3.32 - Pacote de dados do X.25.
Os demais pacotes de controle do X.25 são apresentados na figura 2.3.33, alguns deles
contendo apenas o cabeçalho e outros contendo informações adicionais (até 2 bytes). No caso
de um pacote CLEAR REQUEST, por exemplo, o quarto byte indica a causa da liberação da
conexão.
83
8 bits
0 0 0 1 GRUPO
CANAL
TIPO CM
INFORMAÇÃO
ADICIONAL
Figura 2.3.33 - Pacotes de controle do X.25.
b) O Protocolo IP (Internet Protocol)
O protocolo IP foi projetado para redes de comutação de pacotes. Assume-se que a
rede é composta de várias sub-redes de tipos diferentes, interligadas por “routers”
(roteadores). Cada estação na rede é denominada um “host” (hospedeiro).
O IP é um protocolo sem conexão e sem reconhecimento (opera, portanto, com
datagrama não confiável). Ele só faz controle de erros do cabeçalho das mensagens, para
garantir a correção do endereço de destino, vital para a função de roteamento. O IP também
não faz controle de fluxo. Como o protocolo IP é usualmente utilizado em conjunto com um
protocolo de transporte chamado TCP, estas funções ficam a cargo deste outro protocolo,
como veremos na seção seguinte.
O IP usa endereçamento hierárquico e suporta roteamento dinâmico distribuído nos
routers. Um router pode também descartar pacotes se não houver espaço em buffer para
armazena-los.
O esquema de endereçamento adotado no protocolo IP é o seguinte: cada estação na
rede possui um endereço único, composto de 32 bits (4 bytes), subdivididos em 3 classes mais
utilizadas:
classe A: byte 1 => msb a zero, demais 7 bits identificam sub-rede (de 1 a 126); 24
bits restantes usados para definir o endereço local do host (até 16 milhões de hosts
por sub-rede)
classe B: 2 bytes para sub-rede e 2 bytes para host (até 65.536 hosts por sub-rede)
classe C: 3 bytes para sub-rede e 1 byte para host (até 254 hosts, valores 0 e 255
reservados)
O esquema completo de endereçamento é apresentado na figura 2.3.34.
Usa-se uma máscara de endereçamento para definir a partir de que byte começa o
endereço do host, separando-o do endereço da subrede. Por exemplo, a máscara
[Link] indica que os 3 primeiros bytes fazem parte do endereço da subrede, enquanto
o quarto byte contém o endereço do host.
84
Desta forma, uma estação de rede teria um endereço IP do tipo: [Link] (host
atlas no LCMI-UFSC) ou [Link] (host polaris, também no LCMI). Observe que as
duas estações do exemplo acima estão situadas na mesma subrede. Os bytes nos exemplos
acima são separados por pontos para facilitar a conversão do formato string para endereço IP.
32 bits
classe Endereços
A 0 Sub-rede Host [Link] a
127 255 25
B 10 Sub-rede Host [Link] a
191 255 25
C 110 Sub-rede Host [Link] a
223 255 25
D 1110 Endereço para Multicast [Link] a
239 255 25
E 11110 Reservado para uso futuro [Link] a
247 255 25
Figura 2.3.34 – Endereçamento IP
2.3.5. A CAMADA DE TRANSPORTE
A função da camada de Transporte é permitir a transferência de informações do
sistema emissor ao sistema receptor de forma confiável e econômica, independentemente da
natureza da informação ou das redes suportando a comunicação.
A importância dos serviços fornecidos por esta camada está no fato que muitas
aplicações existentes podem funcionar simplesmente com a existência de um serviço
confiável de transporte de informação, o que quer dizer que os serviços que poderiam ser
fornecidos pelas camadas superiores são dispensáveis. Um exemplo disto é a interconexão de
estações no sistema UNIX.
Nesta parte do documento serão apresentadas as principais definições relacionadas aos
serviços e protocolos de transporte, particularmente do ponto de vista do modelo OSI.
[Link]. O serviço oferecido à camada de Sessão
85
Segundo o modelo OSI, os usuários da camada de Transporte são as entidades de
Sessão, às quais deve ser oferecido o serviço confiável de transporte dos bits de informação
fim-a-fim, este serviço sendo fornecido através de uma entidade de software ou de hardware
denominada entidade de transporte.
De maneira similar à camada de Rede, a de Transporte pode fornecer duas classes de
serviço, ou seja, sem conexão e orientados à conexão.
Os serviços de Transporte orientados à conexão são caracterizados pelas três etapas já
descritas para outros níveis do modelo OSI, isto é, estabelecimento de conexão, transferência
de dados e liberação da conexão.
Estes serviços são bastante similares aos serviços oferecidos pela camada de Rede, o
que poderia colocar em dúvida a necessidade desta camada. No entanto, a sua existência se
justifica pela necessidade de serviços de supervisão da camada de Rede do ponto de vista das
entidades efetivamente envolvidas na comunicação. Trata-se aqui de uma supervisão fim-a-
fim, uma vez que, até o nível de Rede, as comunicações se fazem ponto-a-ponto.
Outra contribuição importante da camada de Transporte é que ela permite a utilização
de primitivas de serviço padrão pelas diversas aplicações construídas sobre a rede efetuando
um perfeito «isolamento» em relação às camadas superiores e tornando transparentes as
possíveis alterações tecnológicas que poderiam ocorrer nos níveis inferiores. Por esta razão,
constuma-se fazer uma distinção entre os níveis de 1 a 4 e os de 5 a 7. Os primeiros quatro
níveis seriam mais orientados ao transporte efetivo das informações e os três níveis
superiores, mais orientados às aplicações que serão construídas sobre a rede.
Poderíamos sintetizar o serviço fornecido pela camada de Transporte como de
supervisor da qualidade de serviço oferecido pela camada de Rede. Isto significa que, se a
camada de Rede é confiável, a camada de Transporte não terá muito a fazer.
Por outro lado, se o serviço de Rede é deficiente, a camada de Transporte assume a
função de suprir as diferenças entre a qualidade de serviço que a camada de Sessão necessita e
aquilo que a camada de Rede pode oferecer.
Para isto, o conceito de qualidade de serviço (QOS, Quality Of Service) é um aspecto
importante na concepção da camada de Transporte, baseado sobre um certo conjunto de
parâmetros, entre os quais:
• o tempo de estabelecimento de uma conexão;
• a probabilidade de falha de um estabelecimento;
• a taxa de débito da conexão;
• o tempo de trânsito;
• a taxa de erro residual;
• a probabilidade de incidente de transferência;
• o tempo de desconexão;
86
• a prioridade, etc...
No momento do pedido de um estabelecimento de conexão, o usuário iniciante
encaminha estes parâmetros nas primitivas de serviço. Se a camada de Transporte julga certos
parâmetros longe da realidade, ela pode sinalizar isto ao usuário iniciante, sem mesmo ter
tentado estabelecer a conexão, através de uma mensagem de erro que vai, também, indicar a
natureza do erro sinalizado. Outra possibilidade é a camada de Transporte julgar que um certo
valor para um parâmetro seja impossível de oferecer, mas que um valor não muito longe
daquele poderia ser oferecido. Neste caso, ela pode modificar os valores dos parâmetros
enquadrados e encaminhar o pedido de conexão à máquina remota.
Ainda, se a máquina distante verifica que ela não pode oferecer determinados valores
especificados nos parâmetros do pedido, ela pode modificar aqueles parâmetros. Se ela
verificar que não pode atender determinados parâmetros nos valores mínimos permitidos, a
conexão será rejeitada.
[Link]. As primitivas de serviço de Transporte
As primitivas de serviço de Transporte do modelo OSI são apresentadas na tabela a
seguir, existindo para os serviços orientados à conexão e sem conexão.
SERVIÇO ORIENTADO Á CONEXÃO
T_CONNECT.request (called, calling,exp_data,qos,user_data)
T_CONNECT.indication (called, calling, exp_data,qos,user_data)
T_CONNECT.response (qos, responder, exp_data, user_data)
T_CONNECT.confirm (qos, responder, exp_data, user_data)
T_DISCONNECT.request (user_data)
T_DISCONNECT.indication (reason, user_data)
T_DATA.request (user_data)
T_DATA.indication (user_data)
T_EXPEDITED_DATA.request (user_data)
T_EXPEDITED_DATA.indication (user_data)
SERVIÇO SEM CONEXÃO
T_UNITDATA.request (called, calling,qos,user_data)
T_UNITDATA.indication (called, calling,qos,user_data)
Como podemos ver, as primitivas de serviço de Transporte se assemelham bastante
àquelas do serviço de Rede. Existe, porém, uma diferença fundamental entre os dois níveis.
No caso do nível Rede, considera-se que o serviço oferecido corresponde ao funcionamento
real do sistema, representando inclusive suas falhas. Desta forma, podem ocorrer perdas de
pacotes ou a emissão de comandos N_RESET de sua própria iniciativa.
87
Já no caso do nível Transporte, os comandos N_RESET não são propagados aos
usuários (as camadas superiores), uma vez que o objetivo principal desta camada é o
tratamento de todos os problemas de comunicação evitando que os usuários do serviço tomem
conhecimento das más condições de funcionamento da rede de comunicação (se tal é o caso!).
Uma outra diferença entre os dois serviços são os usuários destes. No caso do serviço
de Rede, os usuários são as entidades de Transporte, normalmente elementos associados ao
sistema operacional considerado ou a uma placa específica instalada nos sistemas.
Já os usuários do serviço de Transporte podem ser programas escritos pelos
programadores de aplicações, uma vez que, como já foi dito, muitas aplicações podem
comunicar-se diretamente através do uso direto das primitivas de serviço de Transporte (não
fazendo uso dos serviços de Sessão, de Apresentação ou de Aplicação).
As possíveis relações entre as primitivas de serviço da camada de Transporte são
apresentadas na figura [Link]. As duas extremidades das ilustrações caracterizam os usuários
do serviço de Transporte, o fornecedor sendo representado pelo espaço separando os dois
usuários.
Em [Link](a) é ilustrada um estabelecimento normal de conexão, onde o usuário da
esquerda envia uma primitiva T_CONNECT.request à camada de transporte. O usuário da
direita vai receber então uma primitiva T_CONNECT.indication, cujos parâmetros vão
conduzir os valores, particularmente, da qualidade de serviço a serem negociados. Este aceita
o estabelecimento da conexão, retornando à camada de Transporte uma primitiva
T_CONNECT.response, que será refletida, via serviço de Transporte, no usuário da esquerda
na forma de uma primitiva T_CONNECT.confirm.
88
T_CONNECT T_CONNECT T_CONNECT
request request request
T_CONNECT T_CONNECT
indication indication
T_CONNECT T_DISCONNECT
response request
T_CONNECT T_DISCONNECT T_DISCONNECT
confirm indication indication
(a) (b) (c)
T_DISCONNECT T_DISCONNECT T_DISCONNECT
request request request T_DISCONNECT T_DISCONNECT
T_DISCONNECT indication indication
indication
(d) (e) (f)
T_DATA T_EXPEDITED_DATA
request request
T_DATA T_EXPEDITED_DATA
indication indication
(g) (h)
Figura [Link] - As diversas interações entre as primitivas de serviço de Transporte.
A figura [Link](b) apresenta uma tentativa de estabelecimento de conexão, rejeitada,
porém, pelo usuário da direita, que utiliza as primitivas de serviço T_DISCONNECT.request e
T_DISCONNECT.indication para sinalizar a rejeição.
O caso é similar na figura [Link](c), porém, desta vez, é o próprio fornecedor do
serviço de Transporte quem rejeita a conexão, enviando uma primitiva
T_DISCONNECT.indication ao usuário da esquerda.
No que diz respeito à liberação da conexão, pode-se considerar três diferentes
maneiras: a primeira, ilustrada em [Link](d), considera o caso em que a liberação é iniciada
por um dos usuários (no caso o da esquerda). A conexão é liberada no momento em que o
usuário da direita recebe uma primitiva T_DISCONNECT.indication, reflexo da primitiva
T_DISCONNECT.request emitida pelo usuário que iniciou a liberação; em [Link](e) é
considerado o caso em que os dois usuários iniciam, simultaneamente, a liberação da conexão,
neste caso, a conexão é liberada sem a emissão de outras primitivas de serviço; finalmente,
em [Link](f), a liberação é iniciada pelo próprio serviço de Transporte, que vai emitir
primitivas T_DISCONNECT.indication aos dois usuários conectados.
Já as figuras [Link](g) e [Link](h), representam, respectivamente, a etapa de
transferência de dados, para dados normais e expressos.
[Link]. Os protocolos de Transporte
89
Como definido pelo modelo OSI, o serviço oferecido por uma camada N é o resultado
da implementação de um protocolo N regendo a comunicação entre duas entidades N. Em
princípio, os protocolos de Transporte apresentam preocupações similares à dos protocolos de
Enlace, ou seja, o controle de erros, o controle de fluxo, o sequenciamento dos dados.
No entanto, algumas diferenças podem ser levantadas:
• no caso da camada de Enlace, dois IMPs comunicam-se via um canal de
comunicação; a nível de Transporte, a comunicação é feita via uma subrede;
• no que diz respeito ao endereçamento, a nível de Enlace, um IMP não necessita
referir-se explicitamente com qual IMP ele quer dialogar, uma vez que dois IMPs
são conectados por uma via única (exceto no caso de redes de difusão); já, no nível
Transporte, o endereço do destinatário deve ser explicitamente definido;
• um outro problema é a questão do controle de fluxo; ao contrário do nível de Enlace,
onde cada conexão pode alocar um determinado número de buffers para o
armazenamento dos quadros, no nível Transporte isto fica mais difícil dado o
número de conexões que pode estar sendo gerenciado num dado instante.
Um aspecto a ser levado em conta no momento da concepção da camada de Transporte
é o serviço oferecido pela camada de Rede, que pode ser classificado da seguinte maneira:
• serviços do tipo A, que caracteriza os serviços "perfeitos", onde a fração de pacotes
perdidos, duplicados ou corrompidos é desprezível; é o tipo de serviço dificilmente
encontrado em redes públicas, mas algumas redes locais são bastante próximas deste
tipo de serviço;
• serviços do tipo B, onde a perda de pacotes também é rara, mas a comunicação é
freqüentemente interrompida (serviço N_RESET) devido a problemas de congestão,
de hardware ou software;
• serviços do tipo C, não confiáveis, sendo caracterizados normalmente pelas redes a
longa distância do tipo datagrama.
Para cada tipo de serviço, de A a C, o nível do serviço de Transporte caminha do mais
simples ao mais complexo, ou seja, quanto pior o serviço oferecido pela camada de Rede,
melhor (e mais complexo) deverá ser o serviço oferecido pela camada de Transporte.
Para permitir a definição de vários níveis de oferecimento de serviço, o modelo OSI, a
nível da camada de Transporte, define cinco classes de serviço:
90