Osi

REDES DE COMPUTADORES: MODELO OSI X.
25
Eleri Cardozo Maur
cio F. Magalh~ aes Departamento de Engenharia de Computa c~ ao e Automa ca ~o Industrial Faculdade de Engenharia El etrica Universidade Estadual de Campinas 1996
c 1995,1996 DCA FEEC UNICAMP
Indice
~O 1 INTRODUC A
1.1 1.2 1.3 1.4 1.5 1.6 Conceitos B asicos : : : : : : : : : : : : : : : : Aplica c~ oes T
picas : : : : : : : : : : : : : : : Estruturas de Redes : : : : : : : : : : : : : : Padroniza c~ ao de Redes : : : : : : : : : : : : : Estrutura c~ ao de Redes em Camadas : : : : : : O modelo OSI : : : : : : : : : : : : : : : : : : 1.6.1 A Camada F
sica : : : : : : : : : : : : 1.6.2 A Camada de Enlace : : : : : : : : : : 1.6.3 A Camada de Rede : : : : : : : : : : : 1.6.4 A Camada de Transporte : : : : : : : 1.6.5 A Camada de Sess~ ao : : : : : : : : : : 1.6.6 A Camada de Apresenta c~ ao : : : : : : 1.6.7 A Camada de Aplica c~ ao : : : : : : : : 1.7 Servi cos : : : : : : : : : : : : : : : : : : : : : 1.7.1 Servi cos Conectados e Sem Conex~ ao : 1.7.2 Identi cadores : : : : : : : : : : : : : : 1.7.3 Unidades de Dados : : : : : : : : : : : 1.7.4 Primitivas para Requisi c~ ao de Servi cos 1.8 Protocolos : : : : : : : : : : : : : : : : : : : : 1.8.1 Especi ca c~ ao de Protocolo : : : : : : : 1.9 Problemas : : : : : : : : : : : : : : : : : : : :
2 A CAMADA F ISICA
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
5 6 7 7 10 11 11 12 13 13 13 13 14 14 15 17 17 19 20 21 23
Modos de Transmiss~ ao : : : : : : : : : : : : : : : : Codi ca ca ~o de Sinais Digitais : : : : : : : : : : : : Modula ca ~o de Sinais Digitais : : : : : : : : : : : : : Multiplexa ca ~o : : : : : : : : : : : : : : : : : : : : : Caracter
sticas dos Meios de Transmiss~ ao El etricos Fontes de Distor c~ ao do Sinal : : : : : : : : : : : : : Capacidade de Transmiss~ ao de um Canal : : : : : : Meios de Transmiss~ ao : : : : : : : : : : : : : : : : : 2.8.1 Par Tran cado Met alico : : : : : : : : : : : : 2.8.2 Cabo Coaxial : : : : : : : : : : : : : : : : : 1
25
25 26 28 28 29 31 33 35 35 36
DCA-FEEC-UNICAMP
Redes de Computadores: Modelo OSI X.25
tica : : : : : : : 2.8.3 Fibra O 2.9 Componentes da Camada F

sica 2.10 Padr~ oes da Camada F
sica : : : 2.10.1 Redes locais : : : : : : : 2.10.2 Redes P ublicas : : : : : 2.11 Problemas : : : : : : : : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
37 38 39 39 40 41
3 A CAMADA DE ENLACE
3.1 A Subcamada de Acesso ao Meio MAC : : : : : : : : : : : 3.1.1 T ecnicas de Acesso Aleat orio : : : : : : : : : : : : : 3.1.2 M etodos Baseados em Passagem de Permiss~ ao : : : : 3.1.3 Passagem de Permiss~ ao no Padr~ ao IEEE 802.5 : : : : 3.1.4 Passagem de Permiss~ ao no Padr~ ao IEEE 802.4 : : : : 3.2 A Subcamada de Enlace L ogico LLC : : : : : : : : : : : : 3.2.1 Montagem de Quadros : : : : : : : : : : : : : : : : : 3.2.2 Detec c~ ao de Erros : : : : : : : : : : : : : : : : : : : : 3.2.3 T ecnicas de Recupera c~ ao de Erros por Retransmiss~ ao 3.2.4 Formas de Estabelecimento do Enlace : : : : : : : : : 3.2.5 Controle do Fluxo de Quadros : : : : : : : : : : : : : 3.3 Protocolos de Enlace : : : : : : : : : : : : : : : : : : : : : : 3.3.1 O Protocolo ISO HDLC para Redes P ublicas : : : : : 3.3.2 O Protocolo IEEE 802.2 para Redes Locais : : : : : : 3.4 Problemas : : : : : : : : : : : : : : : : : : : : : : : : : : : :
42
42 42 46 48 50 52 52 54 56 58 59 59 59 61 63
4 A CAMADA DE REDE
4.1 Entrega de Pacotes : : : : : : : : : : : : : : : : : : 4.1.1 Camadas de Rede Orientadas a Conex~ ao : : 4.1.2 Camadas de Rede Orientadas a Datagrama : 4.2 Roteamento : : : : : : : : : : : : : : : : : : : : : : 4.2.1 Roteamento Centralizado : : : : : : : : : : : 4.2.2 Roteamento Distribu
do : : : : : : : : : : : 4.3 Controle de Congestionamento : : : : : : : : : : : : 4.3.1 Pr e-aloca c~ ao de Bu ers : : : : : : : : : : : : 4.3.2 Descarte de Pacotes : : : : : : : : : : : : : : 4.4 Interconex~ ao de Redes : : : : : : : : : : : : : : : : 4.4.1 Interconex~ ao de Redes e o Modelo OSI : : : 4.4.2 Pontes : : : : : : : : : : : : : : : : : : : : : 4.4.3 Comportas : : : : : : : : : : : : : : : : : : : 4.5 O Protocolo X.25 Camada 3 : : : : : : : : : : : : : 4.6 Problemas : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
64
64 65 66 66 68 69 71 71 71 72 73 75 76 78 81
5 A CAMADA DE TRANSPORTE
5.1 Qualidade do Servi co : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 82 5.2 O Servi co de Transporte : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 83 5.3 Classes de Protocolos de Transporte : : : : : : : : : : : : : : : : : : : : : : : 84
82
DCA-FEEC-UNICAMP
~O 6 A CAMADA DE SESSA
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9
5.4 Protocolos de Transporte Classe 4 : : : : : : : : : : : 5.4.1 Estabelecimento de Conex~ oes : : : : : : : : : 5.4.2 Transfer^ encia de TPDUs de Dados : : : : : : 5.4.3 Encerramento de Conex~ oes : : : : : : : : : : : 5.5 Multiplexa c~ ao : : : : : : : : : : : : : : : : : : : : : : 5.6 Protocolos de Transporte OSI Orientados a Conex~ ao 5.7 Protocolos de Transporte OSI sem Conex~ ao : : : : : 5.8 Problemas : : : : : : : : : : : : : : : : : : : : : : : : Estabelecimento e T ermino do Di alogo Troca de Informa c~ ao : : : : : : : : : : Gerenciamento do Di alogo : : : : : : : Sincroniza c~ ao do Di alogo : : : : : : : : Gerenciamento de Atividades : : : : : Detec c~ ao de Erros : : : : : : : : : : : : Primitivas OSI de Sess~ ao : : : : : : : : Protocolo OSI de Sess~ ao : : : : : : : : Problemas : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
86 87 87 88 90 90 92 93 94 95 95 96 97 98 98 98 100 101 102 103 104 105 106 106 107 108 109 110 112 113 115 116 118 120 121 125 127
~O 7 A CAMADA DE APRESENTAC A
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
94
~O 8 A CAMADA DE APLICAC A
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11
7.1 Representa c~ ao Can^ onica de Dados : : : : : : : : 7.2 A Sintaxe ASN.1 : : : : : : : : : : : : : : : : : 7.2.1 Tipos Primitivos de Dados : : : : : : : : 7.2.2 Tipos Complexos Construtores : : : : 7.2.3 Tipos Marcados Tagged : : : : : : : : 7.3 Sintaxe de Transfer^ encia : : : : : : : : : : : : : 7.3.1 Identi ca c~ ao do Tipo, Tamanho e Valor 7.4 Primitivas OSI de Apresenta c~ ao : : : : : : : : : 7.5 Problemas : : : : : : : : : : : : : : : : : : : : :
101
Funcionalidades da Camada de Aplica c~ ao : : : : : : : : : : Estrutura c~ ao da Camada de Aplica c~ ao : : : : : : : : : : : Servi co de Associa ca ~o ACSE : : : : : : : : : : : : : : : : Servi co de Opera c~ oes Remotas ROSE : : : : : : : : : : : Servi co de Transfer^ encia Con a vel RTSE : : : : : : : : : Servi co de Controle de Concorr^ encia e Recupera c~ ao CCR Servi co de Troca de Mensagens MHS : : : : : : : : : : : Servi co de Diret orio DS : : : : : : : : : : : : : : : : : : : Servi co de Transfer^ encia de Arquivos FTAM : : : : : : : Terminal Virtual VT : : : : : : : : : : : : : : : : : : : : Problemas : : : : : : : : : : : : : : : : : : : : : : : : : : :
109
DCA-FEEC-UNICAMP
9 GERENCIAMENTO DE REDES
9.1 Requisitos do Gerenciamento de Rede : : : : : : : : : : : : : : : : : : : : : : 9.1.1 Gerenciamento de Falha : : : : : : : : : : : : : : : : : : : : : : : : : 9.1.2 Gerenciamento de Contabilidade : : : : : : : : : : : : : : : : : : : : : 9.1.3 Gerenciamento de Nome e Con gura c~ ao : : : : : : : : : : : : : : : : 9.1.4 Gerenciamento de Desempenho : : : : : : : : : : : : : : : : : : : : : 9.1.5 Gerenciamento de Seguran ca : : : : : : : : : : : : : : : : : : : : : : : 9.2 Sistemas de Gerenciamento de Rede : : : : : : : : : : : : : : : : : : : : : : : 9.3 Gerenciamento de Rede OSI : : : : : : : : : : : : : : : : : : : : : : : : : : : 9.3.1 Contexto do Gerenciamento OSI : : : : : : : : : : : : : : : : : : : : : 9.3.2 Fun c~ oes de Gerenciamento : : : : : : : : : : : : : : : : : : : : : : : : 9.3.3 Estrutura da Informa c~ ao de Gerenciamento : : : : : : : : : : : : : : 9.3.4 Servi co Comum de Informa c~ ao de Gerenciamento CMIS : : : : : : : 9.3.5 Protocolo de Gerenciamento Comum de Informa c~ ao Common Management Information Protocol - CMIP : : : : : : : : : : : : : : : : : 9.4 Problemas : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
128
128 129 130 130 131 132 132 134 135 136 137 139 141 141
A Per l OSI Governamental GOSIP B DECnet OSI
142 145
Cap
tulo 1 ~O INTRODUC A
De niremos Rede de Computadores como um conjunto de computadores aut^ onomos e interconectados. O termo aut^ onomo exclui arranjos de processadores que apresentam rela c~ ao mestre escravo ou disp~ oem de um controle centralizado como os multiprocessadores, as m aquinas data ow e os array processors. Numa rede, nenhum computador obedece a comandos de outro, possuindo inclusive autonomia para se desconectar da rede. Os meios de interconex~ ao s~ ao muitos: cabos de cobre, bras o ticas, rotas de microondas, radiodifus~ ao, etc. Atualmente, os cabos de cobre coaxiais e pares tran cados s~ ao os mais empregados, devendo a bra o tica assumir este papel num futuro pr oximo. Os meios de interconex~ ao limitam tanto a taxa de transmiss~ ao de informa c~ ao quanto a extens~ ao geogr a ca da rede. Quanto a sua extens~ ao geogr a ca, as redes se classi cam em: 1. Redes Locais LAN: Local Area Network: interconectam computadores localizados numa mesma sala ou edif
cio 10 m - 1 Km. Tipicamente, um u nico meio de transmiss~ ao e empregado. 2. Redes de Campus CAN: Campus Area Network: interconectam computadores a n
vel de campus f abrica, universidade, etc. em extens~ oes n~ ao superiores a 10 Km. Tipicamente s~ ao compostas de v arias LANs interligadas por uma rede de alto desempenho backbone. 3. Redes Metropolitanas MAN: Metropolitan Area Network: interconectam computadores e LANs a n
vel regional 5 - 100 Km, usualmente empregando uma ou mais redes de alto desempenho interconectadas. 4. Redes de Longa Dist^ ancia WAN: Wide Area Network: interconectam computadores e LANs a n
vel nacional ou continental 100 - 5000 Km. Via de regra s~ ao operadas por holdings nacionais de telecomunica c~ oes. Uma rede e dita homog^ enea se todos os computadores por ela interconectados s~ ao id^ enticos. Caso contr ario, temos uma rede heterog^ enea. Obviamente, redes heterog^ eneas demandam 5
1.1 Conceitos B asicos
DCA-FEEC-UNICAMP
padroniza c~ ao tanto no n
vel de hardware tens~ oes, frequ^ encias, etc. quanto no n
vel de software por exemplo, representa c~ ao de dados e formata c~ ao de mensagens. O objetivo central de uma rede de computadores e o compartilhamento de informa ca ~o e recursos. Outros benef
cios importantes s~ ao: o crescimento gradual da capacidade de processamento da informa c~ ao; a diversidade de equipamentos e a liberdade de escolha; o aumento da con abilidade via redund^ ancia; o processamento da informa c~ ao in loco; um meio alternativo de comunica c~ ao social.
1.2 Aplica co ~es T

picas
A tecnologia de redes de computadores teve profundo impacto nas atividades relacionadas ao ensino pesquisa, a produ c~ ao e servi cos, e a administra c~ ao. No ensino pesquisa, a interliga ca ~o de bibliotecas, o correio eletr^ onico e os servi cos de boletim eletr^ onico aumentam a velocidade de dissemina c~ ao do conhecimento. Nas atividades relacionadas a produ c~ ao, as redes locais suportam a automa c~ ao da manufatura, os sistemas distribu
dos de controle digital SDCD e a manufatura integrada. As modernas tecnologias de fabrica c~ ao demandam uma capacidade de processamento de informa ca ~o em diversos n
veis desde o controle de sensores e manipuladores at e a emiss~ ao de faturas capaz de ser obtida apenas com a interconex~ ao de processadores diversi cados PCs, esta c~ oes de trabalho, computadores de processo, etc.. No campo da administra c~ ao, a automa c~ ao de escrit orios e o melhor exemplo do emprego de redes de computadores. Anterior a populariza c~ ao do computador pessoal, poucos eram os funcion arios administrativos capazes de operar um terminal conectado a mainframe. Hoje, nas grandes empresas, com a dissemina c~ ao dos computadores pessoais conectados via rede local, documentos s~ ao gerados, transmitidos e armazenados sem a necessidade de manipula c~ ao de pap eis, envelopes, carimbos, etiquetas, etc. A substitui c~ ao do papel pela m
dia eletr^ onica teve profundo impacto na racionaliza c~ ao dos custos administrativos. Na d ecada de setenta, as empresas de telecomunica c~ ao passaram a oferecer servi cos de comunica c~ ao de dados, utilizando, muitas vezes, as pr oprias linhas de voz existentes. Este servi co, no Brasil, e oferecido pela Embratel atrav es da Rede Nacional de Comuta ca ~o de Pacotes RENPAC. A comunica c~ ao de dados permite a interconex~ ao em longa dist^ ancia de computadores. Se o canal de comunica c~ ao for de banda larga, a informa c~ ao poder a vir acompanhada de sinais de v
deo e audio digitalizados e compactados. Inicia-se assim a era da multim
dia, abrindo-se novas fronteiras no emprego do computador como ve
culo de comunica ca ~o e intera c~ ao humana. Pessoas localizadas em diferentes cidades ou pa
ses poder~ ao interagir em sess~ oes de CAD1 cooperativo, Teleconfer^ encia, Telemedicina, etc.
1
Computer-Aided Design.
DCA-FEEC-UNICAMP
1.3 Estruturas de Redes

Um computador conectado a rede e denominado Host ou End System ES. Hosts s~ ao conectados por uma subrede de comunica c~ ao. Subredes carregam mensagens2 de um host para outro. Tipicamente, em redes locais, a subrede de comunica c~ ao se reduz a um duto el etrico ou o tico. Em redes de longa dist^ ancia, a subrede de comunica c~ ao e composta de linhas de transmiss~ ao ou canais e dispositivos de chaveamento denominados IMPs Interface Message Processors ou ISs Intermediate Systems. IMPs s~ ao computadores especializados que conectam duas ou mais linhas de transmiss~ ao e aos quais os hosts se conectam gura 1.1.
fronteira da subrede de comunicao IMP subrede de comunicao HOST
Figura 1.1: Hosts e IMPs numa subrede de comunicac~ ao. Subredes de comunica c~ ao se dividem em dois grupos: ponto-a-ponto3 e de difus~ ao broadcast. Em subredes ponto-a-ponto os IMPs s~ ao conectados por linhas de transmiss~ ao, de sorte que apenas IMPs diretamente conectados se comunicam. Se uma mensagem necessita ser transmitida entre dois IMPs n~ ao conectados, a mesma deve ser roteada atrav es de outros IMPs. A gura 1.2 mostra as topologias t
picas de subredes ponto-a-ponto. Em subredes de difus~ ao todos os hosts compartilham uma mesma linha de transmiss~ ao. Mensagens enviadas por um host s~ ao recebidas por todos os demais. Se o endere co de destino contido na mensagem for diferente do endere co do host que a recebeu, a mensagem e simplesmente descartada. A gura 1.3 mostra as topologias t
picas de subredes de difus~ ao.
1.4 Padroniza c~ ao de Redes

Um padr~ ao e um conjunto de normas e procedimentos. O cumprimento destas normas e procedimentos pode ser obrigat orio normalmente quando relacionados a seguran ca do homem ou recomend avel normalmente quando relacionados a qualidade de produtos e servi cos. Padr~ oes visam homogeneizar produtos e servi cos num n
vel aceit avel de qualidade
2 3
Tamb em denominadas pacotes. Tamb em denominadas comuta c~ ao de pacotes.
DCA-FEEC-UNICAMP
(a)
(b)
(d) (c)
rvore, Figura 1.2: Topologias t

picas em subredes ponto-a-ponto: a Estrela b Anel, c A d Gen erica. e seguran ca, minimizar investimentos em estoques, compatibilizar equipamentos de diferentes proced^ encias, etc. Um padr~ ao e dito de facto quando foi adotado sem nenhuma a c~ ao de entidade reguladora. Exemplo: IBM-PC. Por outro lado, padr~ oes de jure s~ ao produzidos por entidades reguladoras, nacionais ou internacionais, governamentais ou n~ ao. Exemplo: ISO-9000. Cada pa
s industrializado ou semi-industrializado possui uma entidade de padroniza c~ ao. As mais conhecidas no ramo da engenharia el etrica s~ ao: Brasil: Associa ca ~o Brasileira de Normas T ecnicas ABNT; EUA: American National Standard Institute ANSI e Institute of Electrical and Electronic Engineers IEEE; Alemanha: Deutsche Industrie-Norm DIN; Inglaterra: Britsh Standard Institution BSI. Na area de redes de computadores os padr~ oes de jure s~ ao estabelecidos por duas entidades: ITU-TS International Telecommunications Union - Telecommunication Standardization, antiga CCITT Comit e Consultatif International de T el egraphique et T el ephonique, que congrega as companhias de telecomunica c~ oes nacionais; e a ISO International Standard Organization, que congrega as entidades de padroniza c~ ao nacionais.
DCA-FEEC-UNICAMP

satlite
(a)
(b)
(c)
Figura 1.3: Topologias t

picas em subredes de difus~ ao: a Barramento b Radiodifus~ ao via sat elite, c Anel. A ISO tem aceito padr~ oes j a estabelecidos por outras entidades principalmente ANSI, IEEE e ITU-TS como padr~ oes internacionais, simplesmente redigindo-os e catalogando-os de acordo com os seus crit erios. Por exemplo, o padr~ ao IEEE 802 para redes locais foi adotado integralmente pela ISO ISO 8802. Padr~ oes da ITU-TS normalmente se referem a transmiss~ ao de dados a longas dist^ ancias, enquanto pad~ oes ISO s~ ao mais voltados aos servi cos que uma rede geralmente prov^ eea protocolos de conversa c~ ao inter-hosts. A grosso modo, pode-se a rmar que padr~ oes ITU-TS situam-se mais pr oximos do hardware que os padr~ oes ISO. Este texto cobrir a o modelo proposto pela ISO para a Interconex~ ao de Sistemas Abertos 4 OSI e conhecido como modelo ISO OSI ou simplesmente modelo OSI. Este modelo estipula que uma rede de computadores deve ser estruturada em sete camadas, propondo um ou mais padr~ oes para controlar o funcionamento de cada camada. Os padr~ oes OSI est~ ao ainda em vias de se tornarem padr~ oes de facto. Atualmente, os padr~ oes de facto s~ ao os chamados padr~ oes Internet5. Criados pelo Departamento de Defesa DoD dos EUA para a interconex~ ao de seus computadores no nal da d ecada de 70, t^ em sido adotado por todos os fabricantes daquele pa
s para atender as normas de contrato impostas pelo DoD. O que nos leva a crer que os padr~ oes ISO suplantar~ ao os padr~ oes Internet no futuro? A resposta baseia-se no fato dos padr~ oes OSI cobrirem uma gama maior de servi cos, desde aqueles manipulados diretamente pelo usu ario submiss~ ao de jobs remotos, correio eletr^ onico, terminal virtual, etc. at e aqueles de interfaceamento com o hardware, passando por compress~ ao de dados e criptogra a. Mais resumidamente, a ISO possui padr~ oes cobrindo praticamente todo o espectro da tecnologia de redes, o que n~ ao ocorre com os padr~ oes Internet. Os padr~ oes Internet enfatizam mais o transporte con avel de dados de um host para outro. Inicialmente, apenas tr^ es servi cos s~ ao padronizados no n
vel de usu ario: transfer^ encia de arquivos, correio eletr^ onico e login remoto. Outros servi cos que utilizam o transporte o de dados Internet foram introduzidos pela comunidade de usu arios ou por fabricantes. E caso do Yellow Pages diret orio, RPC chamada de procedimento remotos e NFS sistema
4 5
Open Systems Interconnection Abrevia c~ ao de interconnected networks.
DCA-FEEC-UNICAMP
10
de compartilhamento de arquivos. Muitos destes servi cos foram desenvolvidos pela Sun Microsystems para uso pr oprio e se tornaram padr~ oes de facto. Especialistas estimam que os protocolos Internet como o TCP IP continuar~ ao a existir por um longo tempo, mesmo que oferecidos por redes OSI. Entretanto, novos servi cos como aqueles oferecidos por redes digitais de servi cos integrados RDSI ser~ ao totalmente aderentes ao modelo OSI.
1.5 Estrutura c~ ao de Redes em Camadas

Como todo sistema complexo, redes de computadores s~ ao normalmente modeladas como blocos funcionais interligados. Estes blocos s~ ao referidos na literatura como camadas, sendo associado a cada camada um n
vel. A id eia e que cada camada ofere ca servi cos a camada superior, escondendo os detalhes de como estes servi cos s~ ao implementados. Logicamente, a camada N de um host troca informa c~ ao com a camada N dos outros hosts. As regras envolvidas na conversa c~ ao formam o protocolo da camada N . A especi ca c~ ao de protocolos n~ ao trata de detalhes de como s~ ao implementados, detalhes estes que dependem da tecnologia empregada. Entre cada par de camadas adjacentes existe uma interface, que de ne claramente as regras de utiliza ca ~o dos servi cos oferecidos pela camada inferior. O conjunto de camadas e protocolos de nem a arquitetura da rede. Considere uma rede de cinco camadas como mostra a gura 1.4. Suponha que uma mensagem e gerada por um processo em um host e direcionada para um segundo processo num outro host. Vamos seguir esta mensagem pela rede da gura 1.4. Para processos do usu ario, o ponto de entrada na rede e a camada 5. A camada 5 transforma os dados da mensagem numa representa c~ ao padr~ ao, independente da arquitetura do processador, e submete a mensagem transformada a camada 4. Na camada 4 a mensagem e particionada em unidades menores, sendo a cada unidade adicionado um cabe calho contendo informa c~ oes de controle, tais como n umero de sequ^ encia e se a unidade eau ltima da sequ^ encia ou n~ ao. As unidades geradas na camada 4 s~ ao, uma a uma, conduzidas a camada 3. A camada 3 decide o caminho que as unidades ir~ ao percorrer roteamento. Informa c~ oes tais como identi ca c~ ao dos hosts emissor e destinat ario s~ ao contidas num outro cabe calho adicionado pela camada 3. Na camada 2 e computado um c odigo para ns de detec c~ ao de erros checksum. Esta camada adiciona tanto um novo cabe calho quanto um r otulo demarcador de nal nas unidades oriundas da camada 3. A camada 2 envia suas unidades para a camada 1, armazenando-as caso o protocolo desta camada exija con rma c~ ao de recep ca ~o. Na camada 1 ser~ ao gerados os sinais el etricos ou o ticos, ou eletromagn eticos, dependendo do meio f
sico de transmiss~ ao que far~ ao as unidades atingirem o host destinat ario. Ao receber na camada 1 as unidades transmitidas, o host destinat ario propaga-as para as camadas superiores, at e atingir a camada 5, quando o processo destinat ario ser a noti cado. No caminho inverso, as unidades s~ ao remontadas de acordo com as informa c~ oes contidas nos cabe calhos: a mensagem atinge o processo receptor na forma em que foi enviada pelo processo emissor.
DCA-FEEC-UNICAMP
APLICATIVO

APLICATIVO
11
protocolo da camada 5 CAMADA 5 CAMADA 5
MEIO FSICO
HOST #1
HOST #2
Figura 1.4: Camadas, protocolos e interfaces numa rede de computadores.
1.6 O modelo OSI

O modelo OSI e composto das 7 camadas apresentadas na gura 1.5. O modelo OSI n~ ao e uma arquitetura, posto que n~ ao especi ca os protocolos empregado pelas camadas. Entretanto, a ISO tem produzido protocolos para as 7 camadas, publicados como padr~ oes internacionais. A camada f
sica e a respons avel pela gera c~ ao dos sinais el etricos, oticos ou eletromagn eticos que ser~ ao propagados pelo meio f
sico. Protocolos nesta camada especi cam qual a dura c~ ao e intensidade do sinal, t ecnica de multiplexa c~ ao, pinagem, etc. Obviamente esta camada est a intimamente relacionada ao meio f
sico empregado.
1.6.1 A Camada F
sica
DCA-FEEC-UNICAMP
7 APLICAO

protocolo de aplicao PDU APLICAO
12
protocolo de apresentao 6 APRESENT. PDU APRESENT. COMUNICAO HOST-HOST protocolo de sesso 5 SESSO PDU SESSO
protocolo de transporte 4 TRANSPORTE subrede de comunicao PDU TRANSPORTE
REDE
REDE
pacote
REDE
REDE
COMUNICAO 2 ENLACE ENLACE quadro ENLACE ENLACE IMP-IMP HOST-IMP
FSICA HOST #1
FSICA
bit
FSICA
FSICA HOST #2
IMP #i
IMP #j
Figura 1.5: O modelo OSI.
1.6.2 A Camada de Enlace
A camada de enlace utiliza a camada f

sica para a transmiss~ ao de quadros de dados data frames. Tipicamente um quadro de dados e composto de algumas centenas de bytes. Quadros s~ ao delimitados por sequ^ encias pr e-estabelecidas de bits. A camada de enlace transmite recebe quadros de dados, aguardando enviando o respectivo quadro de reconhecimento de recep c~ ao. A transmiss~ ao de quadros, mesmo com reconhecimento de recep ca ~o, n~ ao e con a vel. Quadros podem ser duplicados ou chegar fora de ordem. A duplica c~ ao ocorre quando o quadro de reconhecimento e deformado, tornando-se inintelig
vel pelo receptor. O receptor, neste caso, envia novamente o quadro de dados correspondente por falta de reconhecimento, gerando assim a sua duplica c~ ao. A camada de enlace tamb em controla o uxo de quadros, evitando que um host envie quadros numa taxa superior a que o receptor e capaz de processar.
DCA-FEEC-UNICAMP
13
1.6.3 A Camada de Rede
A camada de rede controla a opera c~ ao da subrede. Uma de suas fun c~ oes e o roteamento de pacotes6 do host de origem ao host de destino. O roteamento pode apresentar caracter
sticas din^ amicas, evitando gargalos em certos IMPs, ou est aticas, empregando-se sempre a mesma rota entre dois hosts. Outra fun c~ ao desta camada e a fragmenta c~ ao e remontagem de pacotes para atender a limites impostos por determinados segmentos da subrede de comunica c~ ao. Em subredes de difus~ ao e redes locais esta camada e extremamente simples, dado que sua principal atribui ca ~o roteamento e inexistente nestas subredes.
1.6.4 A Camada de Transporte
A fun ca ~o principal da camada de transporte e receber dados da camada de sess~ ao, particionar estes dados em unidades menores e, em certos casos, garantir que estas unidades cheguem a seu destino sem duplica c~ ao e na ordem correta. Esta camada possui tipicamente dois tipos de servi cos: um servi co r apido onde mensagens s~ ao limitadas em tamanho e n~ ao existe garantia de entrega, ordem ou aus^ encia de duplica c~ ao; e um servi co mais lento, por em altamente con a vel e sem limites de tamanho nas mensagens. Um terceiro servi co, difus~ ao de mensagens para todos os hosts da subrede, pode estar dispon
vel nesta camada. No caso de servi co com entrega con avel, a camada de transporte e respons avel pela remontagem dos quadros oriundos da camada de rede, respeitando a ordem em que foram enviados e descartando duplica co ~es. E fun c~ ao tamb em desta camada o controle do uxo de dados entre dois processos comunicantes a camada de rede controla o uxo apenas entre IMPs. As camadas anteriores f
sica, de enlace e de rede s~ ao empregadas na comunica c~ ao IMPIMP. A camada de transporte e a primeira a promover comunica c~ ao host-host ver gura 1.5.
1.6.5 A Camada de Sess~ ao
Esta camada permite dois processos de aplica ca ~o APs: Application Processes estabelecerem sess~ oes entre si a m de organizar e sincronizar a troca de informa ca ~o. Para tal, uma conex~ ao de sess~ ao e estabelecida, de nindo-se as regras de di alogo entre os dois APs. Existem tr^ es variantes de di alogo quanto ao sentido do uxo de dados: TWS Two Way Simultaneous: bidirecional simultaneamente, TWA Two Way Alternate: bidirecional alternadamente um por vez, e OW One Way: unidirecional. Esta camada fornece servi cos de representa c~ ao can^ onica de dados, compress~ ao de dados e criptogra a. Uma representa ca ~o can^ onica dos dados se faz necess aria quando hosts de
6
1.6.6 A Camada de Apresenta c~ ao
A taxa de utiliza c~ ao de uma subrede e medida pelo uxo de pacotes por unidade de tempo.
DCA-FEEC-UNICAMP
14
arquiteturas diferentes devem se comunicar. Por exemplo, a representa c~ ao de n umeros em ponto utuante varia de arquitetura para arquitetura. Quando um oat e transmitido, o mesmo e convertido para uma representa c~ ao padronizada, enviado via rede, e reconvertido na representa c~ ao adotada pelo host de destino. A camada de apresenta c~ ao disp~ oe de um protocolo para tal EDR: External Data Representation. Compress~ ao de dados eu til para o envio de grandes massas de dados como imagens e textos. Criptogra a e utilizada quando os dados a serem transmitidos s~ ao con denciais e visa evitar sua intercepta c~ ao em tr^ ansito por pessoas n~ ao autorizadas. Protocolos para compress~ ao e criptogra a de dados tamb em s~ ao de nidos nesta camada.
1.6.7 A Camada de Aplica c~ ao
Esta camada disp~ oe de servi cos comumente utilizados por usu arios de redes. Correio eletr^ onico, transfer^ encia de arquivos, login remoto, servi cos de diret orio e submiss~ ao de jobs remotos s~ ao exemplos destes servi cos. Esta camada tamb em se constitui no ponto de acesso a rede por processos de aplica ca ~o APs. Est~ ao em vias de padroniza c~ ao as chamadas APIs Application Program Interfaces, que s~ ao bibliotecas de fun c~ oes para envio recep ca ~o de mensagens, estabelecimento de conex~ oes, etc.
1.7 Servi cos

O modelo de refer^ encia n~ ao especi ca por si s o o comportamento de sistemas abertos, ou seja, servi cos e protocolos. Ele basicamente cria o contexto no qual uma detalhada especi ca ca ~o de servi cos e protocolos possa ser suportada pelo sistema aberto. Do ponto de vista da abstra c~ ao a gura 1.6 ilustra os v arios n
veis envolvidos relacionando o modelo de refer^ encia, servi cos, protocolos e implementa c~ ao de um protocolo. Da gura anterior podemos observar que o modelo de refer^ encia permite a especi ca ca ~o de v arias classes de servi co. Cada classe de servi co permite a especi ca ca ~o de v arias classes de protocolo onde o n
vel mais baixo e representado pela implementa c~ ao do protocolo. O modelo de refer^ encia OSI procura fornecer uma vis~ ao global de um sistema organizado atrav es de uma rede. Esta vis~ ao, por outro lado, divide a rede em camadas horizontais cuja nalidade consiste em: permitir uma discuss~ ao da intera c~ ao entre elementos pares, ou seja, elementos que situam-se em uma mesma camada; esta discuss~ ao deve ocorrer sem levar em conta componentes das outras camadas; a funcionalidade de cada camada pode ser desenvolvida de forma modular e gradual; o sistema aberto pode ser visto como uma sucess~ ao de sub-sistemas facilitando o desenvolvimento de uma implementa c~ ao modular do mesmo. Os elementos ativos em cada camada s~ ao chamados entidades. Uma entidade pode ser um componente de software um processo, por exemplo ou de hardware um controlador
DCA-FEEC-UNICAMP
Servios

Modelo de Referncia
15
Protocolos
Implementao de um Protocolo
Figura 1.6: Rela c~ ao entre Modelo de Refer^ encia, Especi ca c~ ao de Servi co e Especi ca c~ ao de Protocolo. de I O, por exemplo. As entidades na camada N implementam servi cos usados na camada N + 1. Neste contexto, a camada N e denominada provedora de servi cos enquanto a camada N +1 e dita usu aria de servi cos. Servi cos s~ ao dispon
veis nos SAPs Service Access Points. A camada N + 1 acessa os servi cos oferecidos pela camada N nos SAPs desta camada. Cada SAP possui um endere co que o identi ca u nica e globalmente. A gura 1.7 ilustra alguns conceitos associados aos pontos de acesso de servi cos. Da gura podemos observar que: no m aximo uma entidade e respons avel pelo suporte ao SAP; no m aximo uma entidade-N + 1pode acessar um SAP-N de cada vez; uma entidade-N pode suportar qualquer n umero de SAPs-N de cada vez; uma entidade-N + 1 pode acessar servi cos em mais de um SAP-N . A associa c~ ao entre uma entidade-N + 1 a um SAP-N como tamb em a associa c~ ao de uma entidade-N que suporta um SAP-N n~ ao s~ ao associa co ~es permanentes podendo ser alteradas dinamicamente. A natureza dos servi cos suportados por uma camada dependem das primitivas que uma entidade-N + 1 e uma entidade-N podem evocar relativamente ao SAP-N .
1.7.1 Servi cos Conectados e Sem Conex~ ao
Servi cos conectados s~ ao an alogos a um servi co telef^ onico. Estabelece-se uma conex~ ao discagem atendimento, utiliza-se a conex~ ao para troca de informa c~ oes conversa ca ~o e termina-se
DCA-FEEC-UNICAMP
Entidade-(N+1)
16
Camada-(N+1)
SAP-(N)
Entidade-(N) Protocolo-(N) SAP-(N-1) Camada-(N)
Camada-(N-1) Entidade-(N+1)
Figura 1.7: Pontos de Acesso de Servi cos. a conex~ ao volta ao gancho. Servi cos conectados estabelecem um canal l ogico entre as entidades comunicantes. Neste canal, a ordem temporal no envio da informa ca ~o e respeitada e duplica c~ oes s~ ao inexistentes. O canal e dito l ogico ou virtual pelo fato de n~ ao dispor de uma conex~ ao f
sica exclusiva, ao contr ario, m ultiplos canais l ogicos compartilham uma mesma conex~ ao f
sica. Servi cos conectados se dividem em dois tipos: mensagens e cadeias de bytes. Mensagens t^ em suas fronteiras delimitadas, o que n~ ao ocorre com as cadeias de bytes. Servi cos t
picos que demandam conex~ ao s~ ao transfer^ encia de arquivos e login remoto. Servi cos sem conex~ ao s~ ao an alogos a servi cos postais. Envia-se uma mensagem a um destinat ario carta ou telegrama e faz-se votos que ele a receba. Servi cos sem conex~ ao s~ ao denominados servi cos de datagrama. S~ ao mais r apidos que os servi cos conectados, mas a garantia de entrega, aus^ encia de duplica c~ ao e preserva c~ ao da ordem de envio n~ ao s~ ao garantidas. Servi cos t
picos que podem ser baseados em datagrama s~ ao os do tipo requisi c~ ao resposta acesso a banco de dados e sincroniza c~ ao de rel ogios, por exemplo. Dentro do jarg~ ao ISO uma conex~ ao e estabelecida por iniciativa de uma entidade-N +1 que evoca servi co espec
co da camada-N para estabelecimento de uma conex~ ao l ogica com uma entidade-N + 1 remota. A conex~ ao e estabelecida entre SAPs-N correspondentes. Todas as conex~ oes estabelecidas em um mesmo SAP s~ ao suportadas pela entidade-N correspondente. De modo a permitir que a entidade-N + 1 e a entidade-N possam distinguir v arias conex~ oes estabelecidas via um mesmo SAP, de ne-se o conceito de ponto nal de conex~ ao CEP - connection end point. Para cada conex~ ao, 2 CEPs s~ ao de nidos, um para cada extremo da conex~ ao. Desta maneira, um ponto nal da conex~ ao-N CEP-N termina uma conex~ ao-N em um SAP-N . Um CEP-N relaciona tr^ es elementos, ou seja, uma entidade-N + 1, uma entidade-N e uma conex~ ao-N . No caso do envio sem conex~ ao s~ ao utilizados servi cos de transfer^ encia de dados sem
DCA-FEEC-UNICAMP
17
conex~ ao suportados pela camada-N .
1.7.2 Identi cadores
Com o objetivo de permitir que objetos como entidades, SAPs e conex~ oes sejam referenciados no mundo OSI e necess ario um esquema de identi ca c~ ao global destes objetos. Os identi cadores de entidades s~ ao denominados de t
tulos titles, os de pontos de acesso de servi cos SAPs s~ ao denominados de endere cos e as conex~ oes s~ ao identi cadas pelos identi cadores do ponto nal de identi ca c~ ao CEP-identi er, ou seja: uma entidade-N possui um t
tulo-N ; um SAP-N possui um endere co-N ; um CEP-N possui um identi cador-CEP-N .
O su xo N usado acima indica que os identi cadores possuem signi cado no n

vel da camada-N . A associa ca ~o do t
tulo de uma entidade-N + 1 com o endere co do SAP-N ao qual ela est a conectada encontra-se em um diret orio mantido pela camada-N + 1, referenciado como diret orio-N +1. Desta maneira, caso uma entidade-N +1 necessite estabelecer uma conex~ ao com uma entidade-N + 1, ela pode recorrer ao diret orio-N + 1 para determinar o endere co do SAP-N ao qual a entidade destino encontra-se conectada.
1.7.3 Unidades de Dados
A troca de dados entre entidades no modelo OSI ocorre de duas formas: 1. entre entidades pares, ou seja, entidades-N + 1 remotas sendo a troca governada por um protocolo-N ; 2. entre entidades em camadas adjacentes, isto e, entidade-N +1 e entidade-N atrav es de um mesmo SAP-N . As informa c~ oes trocadas entre as entidades, sejam entidades pares ou adjacentes, podem ser divididas em duas partes: dados e informa c~ oes de controle. Desta forma, e poss
vel de nir-se quatro tipos de unidades de dado: 1. informa ca ~o de controle de protocolo: informa c~ ao trocada entre entidades pares com a nalidade de coordenar as suas opera co ~es conjuntas; 2. dado do usu ario: dado transferido entre uma entidade-N + 1 e uma entidade-N +1 par atrav es de servi cos suportados por entidades-N ; 3. informa ca ~o de controle de interface: trata-se de informa c~ ao trocada entre entidadeN + 1 e entidade-N para coordenar as suas intera c~ oes atrav es do SAP-N ;
DCA-FEEC-UNICAMP
18
4. dado de interface: dado transferido da entidade-N +1 a entidade-N para ser enviado a entidade-N + 1 par. Como, em geral, as informa c~ oes trocadas entre as entidades pares ou adjacentes incluem informa c~ oes de dado e controle, determinam-se 2 novas unidades: 1. unidade de dado do protocolo-N PDU-N : informa c~ ao trocada entre entidades pares e constituida de controle e dado do usu ario; 2. unidade de dado de interface-N + 1: informa c~ ao trocada entre uma entidade-N +1 e uma entidade-N atrav es de um SAP-N , sendo constituida de controle e dado do usu ario. O conjunto de PDUs trocadas entre entidades-N +1 pares e especi cado pelo protocoloN + 1 que rege a intera c~ ao entre estas entidades. Por outro lado, a descri c~ ao do servi co n~ ao especi ca um conjunto de unidades de dados de interface, isto porque a troca deste tipo de unidade de dado se d a entre entidades adjacentes internas a um sistema aberto, ou seja, fora do escopo de padroniza c~ ao OSI. A de ni c~ ao deste tipo de informa c~ ao e basicamente para permitir a introdu ca ~o da unidade de dado de servi co-N . Uma unidade de dado de servi co SDU-N e um dado da interface cuja identidade e preservada de um extremo a outro da conex~ ao. N~ ao e relevante como uma SDU-N e trocada entre as entidade-N + 1 e a entidade-N desde que os limites entre SDUs sejam preservados. Em determinadas situa c~ oes uma entidade-N + 1necessita enviar dados urgentes. Neste caso e associada uma unidade de dado de servi co urgente SDU-urgente-N ao servi co permitindo uma transfer^ encia do dado em condi c~ oes priorit arias. De forma resumida temos que uma camada fornece um servi co que permite que entidadesN +1 pares comuniquem-se atrav es da troca de dados, ou seja, PDUs-N +1. A entidadeN + 1 envia a PDU-N + 1para a entidade-N atrav es do SAP-N na forma de uma SDU-N . Esta SDU e entregue remotamente a entidade-N + 1 no SAP correspondente. A entidade-N no sistema onde a informa c~ ao e originada trata a SDU-N como dado do usu ario e cria uma PDU-N anexando ao dado informa c~ ao de controle do protocolo-N . Este mapeamento de uma PDU-N +1 em uma SDU-N e da SDU-N em uma PDU-N e mostrada na gura 1.8 O Modelo de Refer^ encia OSI n~ ao coloca restri c~ oes com rela ca ~o ao tamanho da unidade de dado. De modo a suportar o comprimento vari avel das unidades, o Modelo permite que uma unidade de dado seja mapeada em um n umero de unidades de dado, ou que um n umero de unidades de dado seja mapeado em uma u nica unidade de dado. Consequentemente, as formas de mapeamento a seguir s~ ao poss
veis:
segmenta c~ ao: e a fun c~ ao realizada por uma entidade-N atrav es da qual uma SDU-N e mapeada em v arias PDUs-N gura 1.9; remontagem: fun c~ ao inversa da segmenta c~ ao, ou seja, a entidade-N par mapeia m ultiplas PDUs-N em uma SDU-N gura 1.9;
DCA-FEEC-UNICAMP

PDU-(N+1)
19
SDU-(N) PCI-(N)
CAMADA-(N)
PDU-(N)
Figura 1.8: Mapeamento de PDUs em SDUs.

bloqueio: fun c~ ao realizada por uma entidade-N que mapeia m ultiplas SDUs-N em uma PDU-N gura 1.10; desbloqueio: fun c~ ao reversa do bloqueio, ou seja, a entidade-N par mapeia uma PDUN em m ultiplas SDUs-N correspondentes gura 1.10; concatena c~ ao: e a forma que permite a uma entidade-N mapear m ultiplas PDUs-N em uma SDU-N , 1 gura 1.11; separa c~ ao: fun c~ ao reversa da concatena c~ ao e realizada pela entidade-N que mapeia uma SDU-N , 1 em m ultiplas PDUs-N correspondentes gura 1.11.
1.7.4 Primitivas para Requisi c~ ao de Servi cos
A de ni c~ ao dos servi cos suportados por uma determinada camada-N e caracterizada pelo conjunto de primitivas e os respectivos par^ ametros que podem ser evocadas pelo usu ario do servi co entidade-N + 1 e pelo provedor do servi co entidade-N atrav es de um SAPN . A intera c~ ao entre a entidade-N +1 e a entidade-N atrav es das primitivas de servi co de nidas involve a passagem de informa c~ oes de controle ou de dados, ou ambos. No modelo OSI, as primitivas para a requisi c~ ao de servi cos s~ ao divididas em quatro tipos gura 1.12. Vamos tomar o exemplo do estabelecimento de uma conex~ ao entre duas entidades. A entidade que deseja se conectar executa a primitiva CONNECT.request na nota c~ ao OSI, passando como par^ ametro o endere co da segunda entidade. A entidade endere cada recebe um
DCA-FEEC-UNICAMP

SDU-(N)
20
PCI-(N)
PCI-(N)
CAMADA-(N)
PDU-(N)
PDU-(N)
Figura 1.9: Segmenta c~ ao e Remontagem.

CONNECT.indication avisando que uma conex~ ao est a sendo requisitada. Como resposta, executa um CONNECT.response indicando se aceita ou rejeita a conex~ ao. A entidade que requisitou est a bloqueada num CONNECT.con rm, que volta exatamente o resultado do CONNECT.response emitido pela outra entidade. Servi cos envolvendo duas partes podem conter negocia c~ ao. Por exemplo, uma conex~ ao pode especi car certa taxa m
nima de transfer^ encia de dados, m aximo tamanho das mensagens, etc. Neste caso, a negocia ca ~o deve fazer parte do protocolo que regulamenta o servi co. Servi cos podem ser con rmados ou sem con rma c~ ao. Servi cos con rmados necessitam das quatro primitivas b asicas requisi c~ ao, indica c~ ao, resposta e con rma c~ ao. Servi cos sem con rma c~ ao necessitam apenas das primitivas do tipo requisi c~ ao e indica c~ ao. Exemplo: servi co de desconex~ ao. A gura 1.13 ilustra estes conceitos.
1.8 Protocolos
Um dos problemas fundamentais abordado na especi ca c~ ao de um sistema de comunica ca ~o aberto diz respeito ao protocolo envolvendo entidades pares. O conceito cl assico de protocolo de ne a forma como entidades equivalentes interagem entre si para a realiza ca ~o de um objetivo comum para a presta c~ ao de servi cos a entidades na camada superior. Desta forma, 2 entidades-N + 1 que desejam se comunicar devem utilizar os servi cos de comunica c~ ao suportadas pela camada-N , com exce c~ ao da camada f
sica para acesso ao meio f
sico diretamente. Para suportarem os servi cos de comunica c~ ao requisitados no SAP-N pelas entidadesN +1, as entidades-N devem se comunicar atrav es de servi cos da camada-N , 1. Neste caso, a comunica c~ ao entre entidades pares e regida por um conjunto de regras e formatos que as entidades devem seguir para suportar os servi cos. Este conjunto de regras e formatos representando por aspectos sem^ anticos, sint aticos e temporais e denominado de protocolo da camada-N .
DCA-FEEC-UNICAMP

SDU-(N) SDU-(N)
21
PCI-(N)
CAMADA-(N)
PDU-(N)
Figura 1.10: Bloqueio e Desbloqueio.
PDU-(N)
PDU-(N)
CAMADA-(N)
SDU-(N-1)
Figura 1.11: Concatena c~ ao e Separa c~ ao.
1.8.1 Especi ca c~ ao de Protocolo
A especi ca c~ ao de um protocolo relativamente a uma camada compreende: descri ca ~o dos tipos de PDUs; descri ca ~o dos procedimentos do protocolo e os servi cos evocados para transfer^ encia de cada tipo de PDU; de ni c~ ao formal da estrutura de cada tipo de PDU; de ni c~ ao formal da opera c~ ao da entidade de protocolo.
DCA-FEEC-UNICAMP
22
Primitiva
Requisi ca ~o Indica c~ ao Resposta Con rma c~ ao
Signi cado
Uma entidade requer a execu c~ ao de um servi co Uma entidade e informada da ocorr^ encia de um evento Uma entidade deseja responder a um evento Uma entidade e informada sobre o resultado de sua requisi c~ ao Figura 1.12: Tipos de servi cos no modelo OSI.
S.request
S.request
S.indication
S.indication
bloqueia
processa requisio
processa requisio
S.response S.confirm
entidade A
(a)
entidade B
entidade A
(b)
entidade B
Figura 1.13: Servi cos OSI con rmados a e sem con rma ca ~o b.
De ni c~ ao de PDU
Duas entidades pares de um protocolo comunicam-se atrav es da troca de PDUs. Estas s~ ao formadas por uma parte correspondente aos dados do usu ario e outra parte contendo as informa c~ es de controle relativa ao protocolo PCI. Como a PDU e uma informa c~ ao que ser a trocada entre sistemas diferentes, e necess ario que a PDU possua uma estrutura cujo signi cado seja comum as entidades de ambos os sistemas. Isto e obtido nos documentos de padroniza c~ ao atrav es da utiliza ca ~o de cadeias de bits ou atrav es de uma forma baseada em tipos abstratos de dados Abstract Syntax Notation Number One ou ASN.1 acompanhada de regras de codi ca ca ~o. A representa c~ ao baseada em cadeia de bits e mais utilizada na especi ca ca ~o dos protocolos das camadas inferiores. A representa c~ ao utilizando o ASN.1 e mais comum na especi ca ca ~o de PDUs dos protocolos de n
vel mais alto, isto e, dos protocolos orientados a aplica c~ ao. ASN.1 e baseada na tipi ca ca ~o dos dados como encontrado na maioria das linguagens de programa c~ ao. Como ASN.1 e uma sintaxe abstrata, isto signi ca que nada e especi cado com rela c~ ao ao n umero e ordem dos bits correspondentes a cada tipo de dado encontrado na especi ca c~ ao. Neste caso, utiliza-se um conjunto de regras de codi ca c~ ao que ir a gerar PDUs formadas de cadeias de bytes, cadeias estas que ser~ ao interpretadas da mesma forma
DCA-FEEC-UNICAMP em todos os sistemas.
23
Opera c~ ao do Protocolo
Uma entidade de protocolo e modelada na forma de uma m aquina de estados nitos aut^ omato. Isto signi ca que uma entidade de protocolo deve encontrar-se em um u nico estado de cada vez dentre um conjunto nito de estados poss
veis. A transi c~ ao de um estado para outro acontece quando um evento v alido ocorre na interface do aut^ omato. Alguns exemplos de eventos s~ ao os seguintes: recep c~ ao de uma primitiva de servi co na interface com a camada superior; recep c~ ao de uma primitiva na interface com a camada inferior; ocorr^ encia de eventos locais. Em geral, associado a ocorr^ encia de um evento v alido, o aut^ omato muda de estado e gera alguma a c~ ao interna espec
ca como, por exemplo, o disparo de um rel ogio ou a evoca ca ~o de uma primitiva. O m etodo de especi ca c~ ao de protocolo utiliza uma tabela evento-estado onde cada entrada na tabela especi ca o evento sa
da e o novo estado para o qual o aut^ omato dever a transitar devido a uma combina c~ ao evento-de-entrada|estado-atual gura 1.14.
1.9 Problemas
1. Qual o principal benef
cio proporcionado por uma rede de computadores ? 2. Terminais banc arios podem ser considerados hosts de uma rede de computadores ? Justi que. 3. O que s~ ao IMPs ? Por que diferenci a-los dos hosts ? 4. Quem usu ario, fabricante, vendedor, etc. lucra mais com a padroniza c~ ao de redes de computadores ? 5. Quais as vantagens de se estruturar uma rede em camadas ? 6. Qual a diferen ca entre modelo, protocolo e arquitetura ? 7. Descreva suscintamente as 7 camadas do modelo OSI. 8. Suponha que voc^ e decida reimplementar a camada de rede utilizando um algoritmo inteligente de roteamento. Que cuidados voc^ e deve tomar para que as camadas de enlace e de transporte permane cam inalteradas ? 9. Considere o programa talk do Unix que abre uma sess~ ao de conversa ca ~o on-line entre dois usu arios o que e teclado num terminal e mostrado no outro e vice-versa. Voc^ eo implementaria como um servi co conectado ou sem conex~ ao ? Justi que.
DCA-FEEC-UNICAMP
Estado Atual Evento de Entrada IE1 S0

S1 S2 --Sn
24
...
IEx IEx+1
Eventos de entrada (camada superior primitivas de servio)
...
IEy IEy+1
ou
Eventos de entrada (camada inferior recepo de PDUs)
...
IEz
Eventos Locais (ex. temporizador)
OEx Sa
OEx = Evento de saida x Sa = Novo estado a
P0: OEx Sa; P2: OEy Sb;
onde Px sao predicados
Figura 1.14: Tabela evento-estado utilizada na especi ca c~ ao de protocolos. 10. Considere o programa mail do Unix que envia uma mensagem para um usu ario em determinado host correio eletr^ onico. Voc^ e o implementaria como um servi co con rmado ou sem con rma c~ ao ? Justi que.
Cap
tulo 2 A CAMADA F ISICA
A camada f
sica trata da gera c~ ao de sinais e sua propaga c~ ao atrav es do meio f
sico. A camada deve especi car: a natureza do meio f
sico: sua constitui c~ ao cabo coaxial, bra o tica, etc., suas dimens~ oes di^ ametro, comprimento, etc., suas constantes f
sicas imped^ ancia caracter
stica, atenua ca ~o, etc., dentre outros par^ ametros; a forma como os hosts e IMPs s~ ao interconectados no meio f
sico conectores, pinagem, etc.; a forma como 0s e 1s s~ ao codi cados em sinais compat
veis com o meio f
sico; os par^ ametros e suas respectivas toler^ ancias dos sinais: tens~ oes, correntes, frequ^ encias, etc.; o procedimento de multiplexa c~ ao de sinais no meio f
sico, se houver. Vamos examinar os principais t opicos relacionados com a camada f
sica, procurando limitar o n
vel de detalhamento ao esc^ opo deste texto. Padr~ oes publicados por entidades como IEEE, ANSI e ISO devem ser consultados para um estudo mais aprofundado dos componentes da camada f
sica para uma determinada tecnologia de rede.
2.1 Modos de Transmiss~ ao

A camada f
sica e respons avel pela transmiss~ ao atrav es do meio f
sico dos quadros oriundos da camada de enlace. De acordo com o hardware empregado, a transmiss~ ao pode ocorrer em modo full duplex onde dois hosts comunicantes transmitem simultaneamente, ou half duplex caso a informa ca ~o tenha seu uxo alternado no tempo apenas um host por vez pode transmitir. Em redes locais de computadores, a comunica c~ ao half duplex e a mais comum, dado que, na maioria das vezes, o meio f
sico e composto de duto u nico. A transmiss~ ao de bits pelo meio f
sico pode se processar de forma serial ou paralela. Na transmiss~ ao serial um bit e transmitido a cada intervalo de tempo, enquanto na paralela os bits s~ ao transmitidos serialmente por N dutos independentes, resultando na transmiss~ ao de 25
DCA-FEEC-UNICAMP
26
N bits por unidade de tempo. Como a transmiss~ ao paralela requer um meio f

sico composto de v arios dutos, esta n~ ao e empregada em redes locais de computadores. Uma transmiss~ ao de bits pode se dar de forma s
ncrona ou ass
ncrona. Na transmiss~ ao s
ncrona um bit e transmitido a cada intervalo de tempo bem de nido, enquando na transmiss~ ao ass
ncrona um bit pode ser transmitido num instante de tempo arbitr ario. A transmiss~ ao s
ncrona requer que tanto o host transmissor quanto o host receptor disponham de uma base de tempo comum, o que torna seu emprego muito restrito em redes locais de computadores. A transmiss~ ao ass
ncrona a n
vel de bits, por outro lado, e um processo ine ciente pois requer a introdu c~ ao de um separador entre dois bits caracter especial ou intervalo de tempo sem transmiss~ ao. Na pr atica, utiliza-se um meio termo entre os modos s
ncrono e ass
ncrono, onde a transmiss~ ao ass
ncrona se d a a n
vel de bloco de bits transmiss~ ao start-stop. Detectado a ocorr^ encia de um bloco, os bits que o comp~ oe s~ ao recebidos sincronamente. Cada bloco e iniciado com um delimitador de in
cio combina c~ ao de bits e terminado com um delimitador de nal de bloco. Ao detectar um delimitador de in
cio, o receptor sincroniza seu rel ogio para receber, sincronamente, os bits que comp~ oem o bloco. Mesmo que o host transmissor e receptor apresentem um certo drift em seus rel ogios, a transmiss~ ao start-stop requer sincronismo apenas entre os delimitadores de in
cio e nal de bloco.
2.2 Codi ca c~ ao de Sinais Digitais

A representa c~ ao de bits em circuitos digitais se d a, via de regra, por sinais do tipo ON OFF onde um valor alto de tens~ ao representa o c odigo 1 enquanto um valor baixo representa o c odigo 0 ou vice-versa. Esta forma de codi ca c~ ao produz ondas quadradas de formato altamente irregular o que di culta sua transmiss~ ao atrav es do meio f
sico justi cativa adiante. Outras formas de se codi car um sinal digital ON OFF para sua posterior transmiss~ ao s~ ao gura 2.1: C odigo Polar NRZ Non Return to Zero: id^ entico ao sinal ON OFF, exceto que duas polaridades s~ ao empregadas positiva e negativa. Raramente empregado em redes locais de computadores; C odigo Unipolar RZ Return to Zero: o bit 1 coincide com um pulso de rel ogio, enquanto o bit 0 e representado pela aus^ encia do pulso. Raramente empregado em redes locais de computadores; C odigo Manchester: uma transi c~ ao sempre ocorre no meio do intervalo de um bit. Se positiva subida, a transi c~ ao representa o bit 1, se negativa descida o bit 0. Transi c~ oes s~ ao do tipo RZ; C odigo Bifase: id^ entico ao Manchester, mas empregando transi c~ oes NRZ; C odigo Manchester Diferencial: uma transi c~ ao sempre ocorre no meio do intervalo de um bit. Uma transi c~ ao adicional no in
cio do intervalo representa o bit 0, enquanto a aus^ encia desta representa o bit 1. Transi c~ oes s~ ao do tipo RZ;
DCA-FEEC-UNICAMP
27
C odigo Bifase Diferencial: id^ entico ao Manchester Diferencial, mas empregando transi c~ oes NRZ; C odigo CMI Code Mark Inversion: o bit 0 e representado por uma transi c~ ao positiva subida no meio do intervalo do bit, e o bit 1 pela aus^ encia de transi c~ ao positiva. Uma transi c~ ao no nal do intervalo ocorre quando bits 1s se repetem. Transi c~ oes s~ ao do tipo NRZ.
Sinal Digital
Relgio
ON/OFF
Polar NRZ
Unipolar RZ
Manchester
Manchester Dif.
CMI
Figura 2.1: Formas de se codi car um sinal digital. Um sinal codi cado pode ser transmitido de forma digital ou anal ogica. Na forma digital, pulsos el etricos ou oticos s~ ao gerados no meio f
sico. O padr~ ao IEEE 802.3 CSMA CD utiliza transmiss~ ao digital com codi ca c~ ao Manchester injetando no cabo pulsos de tens~ ao com amplitude variando entre 0 e -2.05 Volts. Na forma anal ogica, sinais senoidais s~ ao gerados no meio f
sico. A gera ca ~o de sinais senoidais a partir de um sinal digital e denominada modula c~ ao. O padr~ ao IEEE 802.4 Token Bus emprega modula ca ~o na transmiss~ ao de sinais digitais pelo meio f
sico.
DCA-FEEC-UNICAMP
28
2.3 Modula c~ ao de Sinais Digitais

O processo de modula c~ ao consiste em variar a amplitude, a frequ^ encia ou a fase de um sinal senoidal para representar determinado n
vel de um sinal digital. A Modula c~ ao por Chaveamento de Amplitude ASK emprega uma onda senoidal de frequ^ encia xa e dois n
veis de amplitude que representam os n
veis do sinal digital gura 2.2. A Modula c~ ao por Chaveamento de Frequ^ encia FSK emprega duas frequ^ encias para codi car os n
veis do sinal digital gura 2.2. A passagem da frequ^ encia alta para a baixa pode se dar de forma cont
nua ou de forma discreta. Na passagem cont
nua modula ca ~o FSK-cont
nua, existe um tempo m aximo para ocorrer a transi c~ ao entre as duas frequ^ encias e uma varia c~ ao m axima nas amplitudes correspondentes as frequ^ encias alta e baixa. Na passagem discreta FSK-coerente, normalmente se empregam N ciclos de frequ^ encia baixa para representar determinado n
vel bin ario, e 2N ciclos de frequ^ encia alta o dobro da baixa para o outro n
vel. O padr~ ao IEEE 802.4 Token Bus prev^ e ambas as formas de modula c~ ao FSK n~ ao coexistentes na mesma rede, obviamente. Na modua c~ ao FSK-cont
nua, as frequ^ encias s~ ao
odo de transi c~ ao n~ ao pode 3.75 e 6.25 MHz com uma toler^ ancia de + 80 KHz. O per ultrapassar 100 nanosegundos e as amplitudes nas frequ^ encias alta e baixa n~ ao devem ter uma varia c~ ao superior a 10. Na modula c~ ao FSK-coerente, s~ ao empregadas frequ^ encias de 5 e 10 ou 10 e 20 MHz e um ciclo de frequ^ encia baixa para representar o bit 1 N = 1. Finalmente, a Modula c~ ao por Chaveamento de Fase PSK representa os n
veis bin arios por um avan co ou atraso de fase no sinal senoidal. Por exemplo, uma transi c~ ao negativa de 1 para 0 e representada por um avan co de 90 na fase do sinal senoidal, enquanto uma transi c~ ao positiva de 0 para 1 e representada por um atraso equivalente gura 2.2.
o
2.4 Multiplexa c~ ao
Multiplexa c~ ao e o processo pelo qual o meio f
sico e compartilhado entre dois ou mais pares transmissor-receptor. A multiplexa c~ ao pode se dar pela divis~ ao em frequ^ encia FDM: Frequency Division Multiplex ou pela divis~ ao no tempo TDM: Time Division Multiplex. Na multiplexa c~ ao FDM, diferentes bandas de frequ^ encias s~ ao alocadas a diferentes pares transmissor-receptor. Esta t ecnica e bastante empregada em troncos telef^ onicos, sendo rara em redes de computadores. Em redes, a multiplexa c~ ao TDM e a mais empregada. Esta t ecnica e an aloga ao time-sharing onde a CPU de um processador e alocada a cada usu ario de forma alternada. A multiplexa c~ ao TDM pode ser s
ncrona ou ass
ncrona. Na TDM s
ncrona, o meio f
sico e alocado alternadamente e por um per
odo xo a cada host, independente do host querer utiliz a-lo ou n~ ao. Caso tenha quadros para transmitir, o host o faz no per
odo em que o meio ca a ele alocado. Esta t ecnica provoca uma sub-utiliza c~ ao do meio f
sico, mas garante uma taxa m
nima de transmiss~ ao para cada host. Esta garantia e fundamental em aplica c~ oes de tempo real. Na t ecnica TDM ass
ncrona, quando um host necessitar transmitir quadros o mesmo deve executar um procedimento de acesso ao meio f
sico. Procedimentos convencionais s~ ao:
DCA-FEEC-UNICAMP
Sinal Digital

1 1 0 0 0 1 1 1 1 0 1
29
ON/OFF
ASK
FSK
PSK
Figura 2.2: Modula c~ ao de sinais digitais. passagem de cha e sensoriamento do meio estudados no pr oximo cap
tulo. Na t ecnica TDM ass
ncrona, o meio f
sico e utilizado mais e cienetmente, mas, em geral, n~ ao existe garantia de taxa m
nima de transmiss~ ao para os hosts.
2.5 Caracter
sticas dos Meios de Transmiss~ ao El etricos
Via de regra, os meios de transmiss~ ao el etricos s~ ao do tipo passa-baixas, isto e, permitem a propaga c~ ao de frequ^ encias baixas at e determinado limiar largura de banda B. Em geral, a largura de banda e de nida como a frequ^ encia em que o sinal injetado num extremo tem sua pot^ encia diminuida em 50 -3 dB na outra extremidade gura 2.3-a. Entretanto, se considerarmos os elementos el etricos diretamente conectados ao meio de transmiss~ ao, sua caracter
stica passa-baixas se altera para uma caracter
stica passa-faixa. Considere, por exemplo, que o circuto de transmiss~ ao e recep c~ ao esteja ligado ao meio atrav es de um transformador de desacoplamento. Como transformadores exercem forte atenua c~ ao em baixas frequ^ encias, o conjunto transformador-meio de transmiss~ ao passa a operar como um ltro passa-faixa gura 2.3-b. A caracter
stica passa-faixa de um meio de transmiss~ ao e a raz~ ao pela qual utiliza-se codi ca c~ ao de sinais diferentes de ON OFF. Seja um sinal aleat orio em codi ca c~ ao ON OFF com amplitude unit aria no caso de 1 e com igual probabilidade de ocorr^ encia de 0s e 1s. Utilizando-se um ltro ideal que permite a passagem apenas se sinais na frequ^ encia f , vamos
DCA-FEEC-UNICAMP
Atenuao (dB) 0 dB -3dB

Atenuao (dB)
30
0 dB -3dB
B (a)
f(Hz)
f1 (b)
f2
f(Hz)
Figura 2.3: Um ltro passa-baixas a e passa-faixa b. aplicar o sinal ON OFF ao ltro e computar a pot^ encia do sinal ltrado. Variando-se f de zero n
vel DC a in nito, obtem-se o gr a co espectro de pot^ encia da gura 2.4-a.
S(f) T 2 T 2 S(f)
T 4 T 8
1 2T
1 T (a)
3 2T
2 T
1 2T
1 T (b)
3 2T
2 T
Figura 2.4: Espectro de pot^ encia de um sinal de amplitude unit aria e per
odo de ocorr^ encia de bits igual a T: a codi ca c~ ao ON-OFF; b codi ca c~ ao Manchester. Percebe-se agora que um meio de transmiss~ ao com caracter
sticas passa-faixa e inadequado para transmitir um sinal bin ario em codi ca c~ ao ON OFF, pois este sinal demanda a propaga c~ ao de pot^ encias consider aveis em baixas frequ^ encias de 0 at e o inverso do per
odo do bit-T. Impedindo-se a propaga c~ ao de tais frequ^ encias, tem-se um sinal altamente distorcido no receptor. Passando agora o sinal ON OFF por um codi cador Manchester antes de aplic a-lo ao ltro, obtem-se o espectro de pot^ encia da gura 2.4-b. O c odigo Manchester demanda a propaga c~ ao de pot^ encias moderadas tanto de baixas quanto de altas frequ^ encias, causando pouca distor ca ~o do sinal quando transmitido atrav es de um meio passa-faixa.
DCA-FEEC-UNICAMP
31
2.6 Fontes de Distor c~ ao do Sinal

Caracter
stica Passa-faixa do Meio
A gura 2.5 mostra a distor c~ ao de um sinal peri odico pela aus^ encia ou atenua c~ ao de suas componentes de alta frequ^ encia. A aus^ encia de componentes de baixa frequ^ encia di culta ainda mais a identi ca c~ ao de 0s e 1s pelo receptor. Sinais peri odicos necessitam apenas da propaga c~ ao de submultiplos inteiros de sua frequ^ encia harm^ onicas da s erie de Fourier.
SINAL ON-OFF
UMA HARMNICA
DUAS HARMNICAS
QUATRO HARMNICAS
OITO HARMNICAS
Figura 2.5: Um sinal peri odico e suas harm^ onicas. Quando aplicamos uma onda retangular de tens~ ao a um meio de transmiss~ ao el etrico, temos no receptor do sinal uma onda n~ ao retangular como mostra a gura 2.6. A subida
ngreme da tens~ ao e impedida pelas capacit^ ancias inerentes do meio, que necessitam armazenar energia para ter sua tens~ ao variada. Esta energia e devolvida quando a tens~ ao decai, impondo igualmente um decr escimo suave da tens~ ao no meio. Suponha a ocorr^ encia do bit 1 seguido do bit 0. O decaimento suave da tens~ ao pode fazer com que o receptor detecte o bit 1 no lugar do bit 0, caso a amostragem se d^ e mais pr oxima do in
cio do intervalo do bit. A este fen^ omeno denomina-se interfer^ encia entre s
mbolos.
Interfer^ encia Entre S

mbolos
DCA-FEEC-UNICAMP
0 1

1 1 0 1 0
32
SINAL NO TRANSMISSOR
SINAL NO RECEPTOR
limiar de deciso
pontos de deteco
ponto de deteco deslocado
Figura 2.6: Interfer^ encia entre s

mbolos. Jitter de fase e uma imprecis~ ao na fase do sinal digital causada por altera c~ ao do ponto de opera c~ ao normal dos circuitos eletr^ onicos devido a varia c~ oes de temperatura, oscila c~ oes da tens~ ao de alimenta c~ ao, etc. O jitter de fase causa uma mudan ca no instante de passagem pelo limiar que distingue uma transi c~ ao gura 2.7. Como consequ^ encia, o per
odo de ocorr^ encia dos bits tem um valor n~ ao constante, podendo causar erros na recep c~ ao do sinal. O jitter de fase e medido pela faixa de tempo em que a transi c~ ao pode variar em valor absoluto ou relativo ao per
odo do bit.
Jitter de Fase
Ru
do T ermico
Ru
do t ermico e uma perturba c~ ao de natureza aleat oria que distorce o sinal. Transit orios t ermicos e eletromagn eticos s~ ao as causas mais comuns de ru
do t ermico. Transit orios mec^ anicos e outra fonte de ru
do t ermico, alterando as caracter
sticas el etricas dos contactos resist^ encia e capacit^ ancia de contacto. A gura 2.8 ilustra a distor c~ ao causada pelo ru
do t ermico.
DCA-FEEC-UNICAMP
1

1 1
33
jitter
jitter
PERODO
1
SINAL NO RECEPTOR
1
limiar de deciso
pontos de deteco
Figura 2.7: Erro de detec c~ ao devido ao jitter de fase. Um sinal pode ser representado por um certo n umero de componentes harm^ onicas senoidais. Nos meios f
sicos usuais a velocidade de propaga c~ ao de uma onda senoidal depende de sua frequ^ encia. Caso esta depend^ encia seja acentuada, uma harm^ onica de frequ^ encia alta pode ter sua fase alterada em rela c~ ao as harm^ onicas de frequ^ encias baixas. A gura 2.9 mostra este efeito.
Distor c~ ao por Atraso de Propaga c~ ao
2.7 Capacidade de Transmiss~ ao de um Canal

A frequ^ encia com que um sinal pode se propagar no meio de transmiss~ ao e denominada baud. 6 Um canal de 10 Mbaud permite 10 varia c~ oes do sinal por segundo. A rela ca ~o entre baud e bits por segundo bits baud depende da forma de codi ca c~ ao do sinal. Um canal com capacidade de N bauds pode transportar N bits s no caso de sinal digital com codi ca c~ ao ON OFF ou NRZ. No caso de codi ca c~ ao Manchester, teremos N 2 bits s em m edia. o caso Um canal de N bauds pode transportar um n umero maior que N de bits s. E de, por exemplo, utilizar-se um sinal digital com codi ca c~ ao ON OFF e 4 n
veis de tens~ ao representando as ocorr^ encias dos bits 00, 01, 10 e 11. Neste caso temos 2N bits s. A codi ca c~ ao de m ultiplos bits numa u nica varia c~ ao do sinal e rara em redes locais devido a alta taxa de falhas na decodi ca ca ~o do sinal. Quando utilizada principalmente em troncos telef^ onicos, emprega-se transmiss~ ao anal ogica com modula ca ~o PSK e ASK combinadas. gura 2.10. A capacidade de transmiss~ ao de um canal passa-baixas e limitada pelo teorema de Ny-
DCA-FEEC-UNICAMP
0 1

1 1 0 1 0
34
RUDO TRMICO erro de deteco
SINAL NO RECEPTOR
limiar de deciso
pontos de deteco
Figura 2.8: Erro de detec c~ ao devido ao ru

do t ermico. quist: Um canal livre de ru
do com largura de banda B transmitindo um sinal com V diferentes amplitudes possui uma taxa de transmiss~ ao T em bits s dada por
T 2B log2 V
Por exemplo, um canal com largura de banda 3 KHz apresenta uma capacidade m axima de 6 Kbits s caso sejam empregadas duas amplitudades modula c~ ao ASK para codi car os n
veis 0 e 1. Intuitivamente, o limite de Nyquist se deve a ltragem de frequ^ encias altas pelo canal tornando in util amostragens com taxa maior que 2B. Devido a presen ca das fontes de distor c~ ao descritas acima, o limite te orico de Nyquist nunca e atingido na pr atica. A interfer^ encia entre s
mbolos causadas pelas indut^ ancias e capacit^ ancias ao longo do meio e um fator preponderante na limita c~ ao da taxa de transmiss~ ao de um canal el etrico. Em redes de computadores baseadas em canais el etricos, taxas da ordem de 10 Mbits s s~ ao t
picas. Em redes baseadas em bra o tica, 100 Mbits s e taxa t
pica. Redes operando na faixa de Gbits s como as baseadas em tecnologia ATM Asynchronous Transfer Mode j a est~ ao dispon
veis comerciamente.
DCA-FEEC-UNICAMP

1a. harmnica sinal resultante 3a. harmnica
35
1a. harmnica sinal resultante 3a. harmnica com diferente velocidade de propagao
Figura 2.9: Distor c~ ao devido a varia c~ ao da velocidade de propaga c~ ao das harm^ onicas com a frequ^ encia.
2.8 Meios de Transmiss~ ao

Um par tran cado constitui-se de dois os enrolados de forma helicoidal. Esta forma evita que os os assumam caracter
sticas de uma antena, o que os tornaria suscept
veis a interfer^ encias eletromagn eticas, bem como minimizam a componente indutiva da imped^ ancia. A componente resistiva da imped^ ancia sofre o chamado efeito pelicular, segundo o qual a corrente el etrica tende a se concentrar nas bordas exteriores do condutor, aumentando sua resist^ encia efetiva. Pares tran cados s~ ao utilizados tanto para transmiss~ ao de sinais anal ogicos em redes telef^ onicas, quanto digitais em redes de computadores. Este meio de transmiss~ ao tem como atrativo o baixo custo e a facilidade de instala c~ ao, aproveitando-se, em muitos casos, a pr opria a c~ ao telef^ onica existente. A frequ^ encia m axima de transmiss~ ao depende do comprimento e da espessura do par de
2.8.1 Par Tran cado Met alico
DCA-FEEC-UNICAMP
fase
36
fase nvel do sinal
(a)
(b)
Figura 2.10: Modula co ~es PSK e ASK combinadas para 3 bits baud a e 4 bits baud b. os, o que em u ltima inst^ ancia dita a imped^ ancia el etrica do par. Para longas dist^ ancias quilometros a taxa de transmiss~ ao n~ ao ultrapassa 20 Kbits s, podendo atingir 100 Mbits s comum redes na faixa de 10 Mbits s ter em comprimentos de poucas dezenas de metros. E como meio de transmiss~ ao pares tran cados para dist^ ancias inferiores a 1 quilometro.
2.8.2 Cabo Coaxial
composto de um condutor cil E

ndrico isolado envolto por uma malha de cobre e uma capa pl astica de prote ca ~o gura 2.11. A blindagem forma uma prote c~ ao eletrost atica ao condutor central tornando o cabo mais imune a interfer^ encias eletromagn eticas. Sua forma de constru c~ ao minimiza as perdas em altas frequ^ encias efeito pelicular e irradia c~ ao. Entretanto, sua estrutura assim etrica contribui para a atenua c~ ao imposta a amplitude do sinal. Apesar de apresentar certa complexidade de instala c~ ao, o cabo coaxial e o meio de transmiss~ ao mais empregado em redes locais de computadores.
capa externa de proteo isolante
condutor de cobre malha de cobre
Figura 2.11: Cabo coaxial de cobre. Tipicamente cabos com imped^ ancias caracter
sticas de 75 e 50 s~ ao empregados. Os
DCA-FEEC-UNICAMP
37
cabos de 50 s~ ao denominados cabos banda b asica pois s~ ao adequados ao suporte de uma frequ^ encia b asica de transmiss~ ao ou duas no caso de modula c~ ao FSK. Os cabos de 75 s~ ao denominados cabos banda larga por disporem de largura de faixa estendida permitindo a multiplexa c~ ao pela divis~ ao em frequ^ encia FDM de v arios canais. A dist^ ancia m axima de um cabo coaxial depende da atenua ca ~o imposta ao sinal. Um limite m aximo de 30 dB e comumente imposto. A atenua ca ~o depende do comprimento do cabo, de suas caracter
sticas el etricas, da frequ^ encia do sinal e do n umero de conectores existentes onde os hosts se conectam. O gr a co da gura 2.12 mostra a atenua c~ ao da amplitude do sinal por quilometro de cabo em fun c~ ao da frequ^ encia.
atenuao (dB/Km) RG-62/U RG-55/U 140 120 100 80 60 40 20 RG-59/U RG-14/U RG-19/U
200
400
600
800
1000
frequncia (MHz)
Figura 2.12: Atenua c~ ao da amplitude por quilometro em fun ca ~o da frequ^ encia.
tica 2.8.3 Fibra O
A bra o tica e composta de um n ucleo de s

lica envolto por uma casca tamb em de s
lica, tudo protegido por uma capa pl astica. O n ucleo e a casca apresentam
ndices de refra c~ ao distintos, apesar de constru
dos de materiais similares. A tecnologia mais comum e a chamada bra multimodo onde a luz e mantida no n ucleo por re ex~ ao na casca gura 2.13. Fibras multimodo possuem di^ ametros entre 50 e 200 m. Atenua co ~es de 1 a 5 dB por quiilometro na pot^ encia do sinal otico s~ ao t
picas. O sinal o tico consite de luz policrom atica de comprimento de onda centrado em 0:8m. O sinal e produzido por diodos LED e captado por fotodetectores, sendo totalmente imune a interfer^ encias eletromagn eticas. As bras o ticas s~ ao de dif
cil instala c~ ao, e utilizadas em redes com topologia em anel onde o tr afego da informa c~ ao se d a num sentido u nico. A conex~ ao de um host numa rede de bra
DCA-FEEC-UNICAMP

capa plstica casca (ndice de refrao n2)
38
ncleo (ndice de refrao n1) luz policromtica ngulo limite
Figura 2.13: Fibra otica multimodo. tica o e um processo complicado. O sinal otico e convertido num sinal el etrico correspondente, passado ao computador que, quando for o caso, o retransmite empregando o processo inverso. Essa regenera c~ ao do sinal coopera para o aumento da dist^ ancia da rede gura 2.14. Redes baseadas em bra o tica FDDI, por exemplo operam a taxas de 100 Mbits s. Taxas de Gbits s com percursos de longas dist^ ancias necessitam bras monomodo di^ ametros de 5 a 10 m e luz monocrom atica produzida por diodos laser.
2.9 Componentes da Camada F

sica
Os padr~ oes IEEE 802 dividem a camada f
sica em cinco componentes: 1. PLS Physical Layer Signaling: e o ponto de sa
da do host em dire c~ ao meio f
sico. E parte da placa de rede inserida num slot do barramento de dados do computador; 2. PMA Physical Medium Attachment: e o dispositivo respons avel pela transmiss~ ao e recep c~ ao de sinais no meio f
sico. E comandada pela PLS. No jarg~ ao Ethernet eo transceiver transmitter-receiver; 3. MDI Medium Dependent Unit: conecta a PMA ao meio f
sico. Em cabos coaxiais pode ser um conector tipo T que requer o seccionamento do cabo ou um conector vampiro, que morde o cabo sem seccion a-lo. A PMA mais a MDI formam a MAU Medium Attachment Unit; 4. AUI Attachment Unit Interface: conecta a PLS a PMA. Via de regra consiste de cabo de pares tran cado com blindagem externa e comprimento m aximo de 50 metros; 5. Meio de Transmiss~ ao. Em redes de longa dist^ ancia, de ne-se apenas dois componentes para a camada f
sica: 1. DTE Data Termininal Equipment: o equipamento do usu ario conectado a rede computador, videotexto, etc.; 2. DCE Data Circuit-terminating Equipment O front-end da rede colocado pela operadora junto ao DTE. Via de regra, e um modulador demodulador modem.
DCA-FEEC-UNICAMP

fibra
39
interface
computador
luz
fotodiodo
regenerador de sinal (eltrico)
LED
luz
fibra
fibra
p/ o computador
Figura 2.14: Rede de bra otica em anel com repetidores ativos.
Atualmente, a vasta maioria das redes locais s~ ao baseadas nos padr~ oes IEEE 802: 802.3 CSMA CD, 802.4 Token Bus e 802.5 Token Ring. Tais padr~ oes foram integralmente aceitos pela ISO padr~ oes 8802. Por exemplo, o documento ANSI IEEE Std 802.3-1984 denominado IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection CSMA CD - Access Methods and Physical Layer Speci cations, de 143 p aginas, descreve os padr~ oes el etricos e mec^ anicos dos cinco componentes da camada f
sica listados acima para redes CSMA CD Ethernet. Tal documento e imprescind
vel para o fabricante de placas e componentes de redes locais, sendo de pouca valia para o projetista, instalador e usu ario de redes. Em geral, dados como tipo do cabo, comprimento m aximo, dist^ ancia m
nima entre MDIs, etc., s~ ao su cientes para o projeto, instala c~ ao e opera ca ~o de redes locais de computadores no que tange a camada f
sica.
2.10.1 Redes locais
2.10 Padr~ oes da Camada F

sica
DCA-FEEC-UNICAMP
40
Apenas a t
tulo de exemplo, vamos examinar algumas especi ca c~ oes do padr~ ao IEEE 802.3. O 802.3 admite 3 meios de transmiss~ ao: cabo coaxial em banda b asica o mais utilizado, cabo coaxial em banda larga e bra otica em banda b asica. As taxas de transmiss~ ao podem ser de 1, 5, 10 a mais usual, e 20 Mbits s. A MAU emprega codi ca c~ ao Manchester com tens~ oes variando de zero a -2.05 Volts. Os tempos de subida e descida do sinal devem estar compreendidos entre 25 + 5 nanosegundos. A faixa limiar de tens~ ao que distingue uma transi ca ~o deve situar-se entre -1.492 e -1.629 Volts. A MDI deve impor uma resist^ encia de contacto n~ ao superior a 50 nanoohms tanto para o condutor central quanto para a blindagem e apresentar capacit^ ancia inferior a 2 pF a 10 MHz. O jitter m aximo introduzido pela MAU n~ ao deve ser superior a 1.7 nanosegundos, e a atraso de propaga ca ~o na MAU deve ser inferior a 257 nanosegundos. Para cabos de 50 banda b asica, a atenua c~ ao m axima e de 17 dB Km a velocidade de propaga c~ ao do sinal el etrico deve ser superior a 77 da velocidade da luz no v acuo, e o jitter m aximo inferior a 7 nanosegundos, tudo para frequ^ encia de 10 MHz e 500 metros de cabo. Dezenas de outros par^ ametros el etricos e mec^ anicos fazem parte do documento IEEE 802.3.
2.10.2 Redes P ublicas
Em redes p ublicas de longa dist^ ancia, o u nico padr~ ao existente na camada f

sica e a interconex~ ao do DTE ao DCE. O padr~ ao mais comum e a interface X.21 da CCITT, muito parecida com a interface serial RS-232C, presente em praticamente todos os computadores. A interface X.21 prev^ e oito conex~ oes para comunica c~ ao full-duplex DCE-DTE gura 2.15.
T (transporte) C (controle) R (recepo) I (indicao) DTE S (sinal) B (byte timing) Ga (retorno comum do DTE) G (terra) DCE
Figura 2.15: Linhas da interface X.21. As linhas T e C s~ ao empregadas para dados e controle no sentido do DTE para o DCE;
DCA-FEEC-UNICAMP
41
as linhas R e I para dados e controle no sentido inverso. A linha S prov^ e ao DTE um sinal de rel ogio. A linha B opcional prov^ e uma refer^ encia que delimita um byte. As linhas Ga e G s~ ao empregadas para retorno de corrente e terra. Como na interface RS-232C, emprega-se codi ca c~ ao NRZ onde o bit 0 e representado por uma tens~ ao positiva maior que 4 Volts, e o bit 1 por uma tens~ ao negativa de m odulo superior a 3 Volts. Um cabo composto de n ucleos de cobre envoltos por blindagem conecta o DTE ao DCE a uma dist^ ancia m axima de 15 m.
2.11 Problemas
1. Quais os motivos de se empregar esquemas de codi ca ca ~o diferente do ON OFF ? 2. Desenhe a forma de onda nos c odigos Manchester e Manchester Diferencial do sinal composto dos bits 0001110101. 3. Diz-se que o c odigo Manchester colabora para a manuten c~ ao do sincronismo entre o emissor e o receptor de um sinal. Comente esta a rma c~ ao. 4. Quais as formas de se modular um sinal digital ? 5. Qual a taxa de transmiss~ ao de um canal de 6 MHz utilizando-se modula c~ ao PSK com 4 avan cos de fases distintos ? 6. O que e Interfer^ encia Entre S
mbolos e Jitter de Fase e quais os seus efeitos na transmiss~ ao de sinais digitais ? 7. Quando se utiliza cabos coaxiais banda b asica e banda larga ? 8. Por que a grande maioria das redes baseadas em bra otica apresentam topologias em anel ? 9. Descreva os componentes da camada f
sica do padr~ ao IEEE 802. 10. Redes p ublicas apresentam a camada f
sica mais simples ou mais complexa que as redes locais ? Justi que.
Cap
tulo 3 A CAMADA DE ENLACE
A camada de enlace e respons avel pela detec ca ~o e recupera c~ ao de erros ocorridos na camada f
sica, oferecendo as camadas superiores um transporte de dados mais con a vel. O enlace e uma conex~ ao virtual por onde uem os quadros. Esta conex~ ao implementa protocolos simples de detec ca ~o e recupera c~ ao de erros, por exemplo detec c~ ao atrav es de checksum e recupera c~ ao por retransmiss~ ao. Em redes de longa dist^ ancia e metropolitanas o enlace se d a entre IMPs. A rota f
sica por onde os quadros uem e exclusiva dos IMPs por ela conectados o meio f
sico e decomposto em segmentos que conectam dois, e somente dois, IMPs. Ao decidir transmitir um quadro, um IMP simplesmente seleciona o segmento conectando ao destinat ario e invoca os servi cos da camada f
sica referente ao segmento. Em redes locais, o meio f
sico e compartilhado por todos os hosts. A transmiss~ ao de um quadro em redes locais requer antes um procedimento de acesso ao meio. Este procedimento e denominado MAC Medium Access Control e varia em complexidade em fun ca ~o da topologia e demais caracter
sticas da rede. Dada a import^ ancia do controle de acesso ao meio em redes locais, e comum reservar uma subcamada no modelo de rede exclusiva para tal. A subcamada de acesso ao meio e parte da camada de enlace e situa-se na interface desta com a camada f
sica. O restante da camada de enlace denomina-se Controle de Enlace L ogico LLC: Logical Link Control e podemos consider a-la como uma segunda subcamada, acima da subcamada de acesso ao meio.
3.1 A Subcamada de Acesso ao Meio MAC

A subcamada de acesso ao meio implementa uma disciplina seguida a risca por todos os hosts de acesso ao meio f
sico. As mais difundidas t ecnicas de controle de acesso ao meio s~ ao as baseadas em acesso aleat orio ou de conten c~ ao e passagem de permiss~ ao. As t ecnicas de acesso aleat orio s~ ao utilizadas em redes com topologia de barramento. Dois m etodos de acesso aleat orio ser~ ao descritos: m etodos ALOHA pioneiros e sua evolu ca ~o para 42
3.1.1 T ecnicas de Acesso Aleat orio
DCA-FEEC-UNICAMP
43
os m etodos de acesso m ultiplo com detec c~ ao de portadora CSMA: Carrier Sense Multiple Access. Este m edodo foi concebido na Universidade do Hawaii para uma rede conectando unidades em quatro ilhas via r adio. A t ecnica necessita de reconhecimento por parte do receptor e segue o algoritmo abaixo: 1. 2. 3. 4. transmita o quadro; aguarde o reconhecimento da recep c~ ao por T unidades de tempo; se recebido, m; gere um n umero aleat orio r entre 0 e R; v a para 1 ap os r unidades de tempo.
M etodo ALOHA Puro
A t ecnica ALOHA pura e basteante simples. Sempre que necessitar transmitir um quadro, o host simplesmente o faz. Caso ocorra colis~ ao interfer^ encia entre duas transmiss~ oes, o quadro ser a propagado com erro, causando o seu descarte pelo destinat ario. O emissor detecta colis~ ao pelo n~ ao recebimento do reconhecimento. Neste caso, a pr oxima retransmiss~ ao se dar a ap os um intervalo de tempo aleat orio. E importante tentar nova transmiss~ ao ap os um intervalo de tempo aleat orio, pois, caso contr ario, uma nova colis~ ao certamente ocorrer a se ambos os hosts colidentes tentarem a retransmiss~ ao ao mesmo tempo. A t ecnica ALOHA pura apresenta baixa e ci^ encia na utiliza c~ ao do canal pois uma transmiss~ ao em curso est a sempre sujeita a interfer^ encia de outra que se inicia. A variante a seguir impede interfer^ encias numa transmiss~ ao em curso. Esta variante do ALOHA puro permite que transmiss~ oes se iniciem em intervalos de tempo bem de nidos parti co ~es. Se o per
odo das parti c~ oes for superior ao tempo de transmiss~ ao de um quadro, uma transmiss~ ao que se iniciou sem colis~ ao ser a conclu
da sem colis~ ao. Como desvantagem, o host deve esperar o in
cio do pr oxima parti c~ ao para transmitir, mesmo que o meio esteja livre. O algoritmo e dado abaixo: 1. 2. 3. 4. 5. aguarde o beep de in
cio de parti c~ ao fornecido por uma esta c~ ao mestre; transmita o quadro; aguarde o reconhecimento da recep c~ ao por T unidades de tempo; se recebido, m. gere um n umero aleat orio r entre 0 e R; v a para 1 ap os r unidades de tempo.
M etodo ALOHA Particionado
DCA-FEEC-UNICAMP
44
Os m etodos da fam
lia CSMA t^ em em comum a capacidade de escutar o meio f
sico para a detec ca ~o de uma transmiss~ ao em curso. Um host somente inicia a transmiss~ ao se detectar o meio em repouso sem transi c~ oes, no caso de transmiss~ ao digital. Colis~ oes ainda podem ocorrer, se dois hosts detectarem o meio em repouso e iniciarem a transmiss~ ao ao mesmo tempo. Neste caso, a con rma c~ ao por parte do receptor, como nos m etodos ALOHA, tamb em e imprescind
vel. O m etodo CSMA N~ ao Persistente opera segundo o algoritmo: 1. escute o meio; 2. se o meio estiver em repouso: a transmita o quadro; b aguarde o reconhecimento da recep c~ ao por T unidades de tempo; se recebido, m; c v a para 1. 3. caso contr ario transmiss~ ao em curso: a gere um n umero aleat orio r entre 0 e R; b v a para 1 ap os r unidades de tempo. Quando detectada uma transmiss~ ao em curso, o m etodo aguarda um intervalo aleat orio antes de reiniciar a escuta do meio a m de aguardar a sua libera c~ ao. Se a transmiss~ ao terminar logo ap os o in
cio do intervalo aleat orio, uma sub-utiliza c~ ao do meio e acarretada. Este m etodo e id^ entico ao anterior, apenas fazendo o intervalo aleat orio igual zero escuta permanente do meio at e cessar a transmiss~ ao em curso. Este m etodo evita as esperas com o meio em repouso do anterior aumentando portanto a utiliza c~ ao do canal sob pena de um aumento da possibilidade de colis~ oes quando dois hosts est~ ao sensoriando o meio ocupado por um terceiro. um meio termo entre o m E etodo N~ ao Persistente e o 1-Persistente. O m etodo detecta o meio permanentemente at e a transmiss~ ao em curso se encerrar. Neste ponto, o m etodo pode transmitir ou suspender a transmiss~ ao por um intervalo de tempo aleat orio. Os passos do algoritmo CSMA p-Persistente s~ ao os seguintes: 1. escute o meio at e ser detectada a condi c~ ao de repouso; 2. gere um n umero aleat orio s entre 0 e 1; 3. Se s p:
M etodo CSMA N~ ao Persistente
M etodo CSMA 1-Persistente
M etodo CSMA p-Persistente
DCA-FEEC-UNICAMP
45
a transmita o quadro; b aguarde o reconhecimento da recep c~ ao por T unidades de tempo; se recebido, m; c v a para 1. 4. Caso contr ario s p: a gere um n umero aleat orio r entre 0 e R; b aguarde r unidades de tempo; c escute o meio; se em repouso v a para 2; d caso contr ario transmiss~ ao em curso: i. gere um n umero aleat orio u entre 0 e U; ii. v a para 1 ap os u unidades de tempo. O m etodo CSMA p-Persistente apresenta uma boa taxa de utiliza c~ ao do meio com baixa probabilidade da de ocorr^ encia de colis~ oes caso p seja ajustado as caracter
sticas do tr afego. O m etodo CSMA-CD Collision Detection adiciona aos m etodos CSMA a detec c~ ao de colis~ oes sem a necessidade de aguardar reconhecimento por parte do receptor. Detectada uma colis~ ao, o host interrompe imediatamente a transmiss~ ao, entrando em seguida num processo de retransmiss~ ao. O processo de detec c~ ao de colis~ ao e simples: durante uma transmiss~ ao o host escuta o meio, comparando o sinal no meio com aquele sendo transmitido. Ocorrida uma diferen ca, o host conclui que uma segunda transmiss~ ao est a se sobrepondo a sua. Detectada uma colis~ ao, o host refor ca a colis~ ao com a inje ca ~o de sinais esp urios no meio jamming a m de que os demais hosts transmitindo detectem imediatamente a colis~ ao e suspendam igualmente a transmiss~ ao. O algoritmo e composto dos seguintes passos: 1. escute o meio at e ser detectada a condi c~ ao de repouso; 2. inicie a transmiss~ ao do quadro, escutando o meio para se certi car que apenas esta transmiss~ ao est a em curso; encerrada a transmiss~ ao do quadro sem colis~ ao, m; 3. reforce a colis~ ao jamming; 4. caso o n umero de colis~ oes c na transmiss~ ao deste quadro exceder um limite, sinalize um erro a camada superior e termine; 5. gere um n umero aleat orio r entre 0 e Rc; 6. v a para 1 ap os r unidades de tempo. Como o m etodo CSMA-CD detecta colis~ oes independente do reconhecimento por parte do receptor, esta t ecnica pode suportar servi cos de datagrama sem con rma c~ ao. A rede Ethernet foi pioneira na introdu c~ ao do m etodo CSMA-CD, sendo comum empregarse o termo Ethernet para este m etodo de acesso ao meio.
M etodo CSMA-CD
DCA-FEEC-UNICAMP
46
CSMA-CD no Padr~ ao IEEE 802.3

Bytes 7 1 6 ENDEREO DESTINO
O padr~ ao IEEE 802.3 estabelece o formato de quadros apresentado na gura 3.1.

6 ENDEREO FONTE 2 0-1500 0-46 4
PREMBULO
TIPO
DADOS
PAD CHECKSUM
10101010 comeo do delimitador do quadro (10101011)
Figura 3.1: Formato dos quadros no IEEE 802.3 O quadro inicia com um pre^ ambulo de 7 bytes composto dos bits 10101010. A seguir vem um byte de in
cio de quadro composto dos bits 10101011. Duas sequ^ encias de 6 bytes estabelecem os endere cos do destinat ario e do emissor, respectivamente. Seguem 2 bytes contendo o tipo da informa c~ ao contida no quadro e os bytes correspondentes 1500 m aximo. Caso o n umero de bytes da informa c~ ao contida no quadro seja insu ciente para atingir o tamanho m
nimo de quadro 64 bytes a partir do byte de in
cio, um pad de 0 a 46 bytes completa as informa c~ oes do quadro. Finalmente, 4 bytes s~ ao reservados para checksum. A imposi c~ ao de um tamanho m
nimo de quadro se d a por duas raz~ oes: 1. quadros muitos curtos emitidos nos extremos do cabo podem entrar em colis~ ao sem que os respectivos emissores a detectem isto e, quando um quadro atinge o extremo oposto a tansmiss~ ao do quadro neste extremo j a foi conclu
da; 2. refor car o checksum, diminuindo a probabilidade de diferentes arranjos de bits gerarem o mesmo checksum. Os m etodos baseados em passagem de permiss~ ao foram desenvolvidas para redes com topologia em anel. A id eia b asica e ter-se uma cha token circulando pelo anel, de host para host. O host que detiver o token est a autorizado a transmitir. Transmitido um quadro, este circula pelo anel at e atingir o host destino. Recebido sem erros no destino, o host ativa no pr oprio quadro um bit de reconhecimento e transmite ao seu sucessor at e atingir o host que o emitiu note que um quadro sempre d a uma volta completa pelo anel. O emissor pode ent~ ao se certi car que o quadro foi corretamente recebido ou ignorado devido a erros ocorridos na camada f
sica ou inexist^ encia do destinat ario, drenando-o do anel. Nenhum host pode manter a posse do token por um intervalo de tempo superior a um limite pr e-estabelecido. Efetuadas as transmiss~ oes ou expirado o tempo m aximo de posse do token, o host a passa para seu sucessor. Redes com topologia em anel que empregam passagem de permiss~ ao como m etodo de acesso ao meio s~ ao denominadas redes token ring.
3.1.2 M etodos Baseados em Passagem de Permiss~ ao
DCA-FEEC-UNICAMP
47
M etodos baseados em passagem de permiss~ ao apresentam duas caracter

sticas b asicas: inexist^ encia de colis~ oes e tempo m aximo de espera para acessar o meio este tempo, em teoria, e in nito para os m etodos de acesso aleat orio. O anel pode conter uma esta c~ ao mestre que tem como fun ca ~o veri car se o token n~ ao se perdeu, reiniciar o anel em caso de falhas, remover quadros corrompidos, etc. Em caso de falha desta esta ca ~o, outra e eleita como mestre automaticamente ou com a interven ca ~o do operador. Apesar da simplicidade do conceito, m etodos de acesso ao meio baseados na passagem de permiss~ ao s~ ao bem mais complexos que os m etodos de acesso aleat orio. A seguintes situa c~ oes devem ser tratadas: inicia c~ ao do anel quando o primeiro host e ligado; inser c~ ao de novos hosts no anel; recon gura c~ ao do anel ante a falha ou o desligamento programado de hosts. Apesar de associados a topologia em anel, m etodos baseados em passagem de permiss~ ao tamb em se aplicam a topologia de barramento. Neste caso, forma-se um anel l ogico ordenando os hosts de acordo com algum crit erio, por exemplo, seus endere cos. O token circula neste anel l ogico, dando permiss~ ao ao host que o det em de difundir quadros no meio f
sico. Redes com topologia de barramento que empregam passagem de permiss~ ao como m etodo de acesso ao meio s~ ao denominadas redes token bus gura 3.2. Nestas redes o hosts emissor n~ ao disp~ oe de con rma c~ ao por parte do receptor como nas redes token ring visto que o quadro e simplesmente difundido no barramento.
1 2 3
anel lgico BARRAMENTO
sentido de rotao do token 4 5 6
estao fora do anel lgico
Figura 3.2: Passagem de permiss~ ao em redes com topologia de barramento. Redes token bus apresentam um atrativo adicional em rela c~ ao a redes token ring: um host pode receber mensagens sem estar participando do anel l ogico host 6 na gura 3.2, posto que todas as mensagem s~ ao transmitidas em difus~ ao pelo meio f
sico. Tais hosts s~ ao incapazes de transmitir, pois jamais estar~ ao de posse do token no m aximo podem responder a uma mensagem a eles direcionada. Esta caracter
stica das redes token bus viabiliza a
DCA-FEEC-UNICAMP
48
inclus~ ao de processadores extremamente simples na rede microcontroladores, por exemplo, sem dot a-los da capacidade plena de acesso ao meio e portanto sem empregar todas as funcionalidades das sete camadas do modelo OSI. O padr~ ao IEEE 802.5 token ring e bem mais complexo que o CSMA-CD do 802.3. Duas caracter
sticas n~ ao presentes no 802.3 s~ ao de nidas no 802.5: prioridade de acesso ao meio e reserva do meio. O token e composto de 3 bytes: DI delimitador de in
cio CA controle de acesso e TIPO. O primeito byte, DI, identi ca o in
cio do token e e formado por transi c~ oes inv alidas do c odigo Manchester Diferencial transi co ~es que jamais ocorrem em cadeias de 0s e 1s tais como duas transi co ~es positivas ou negativas seguidas. O segundo byte, CA, e utilizado para controle de acesso ao meio, sendo composto de agrupamentos de bits em 4 categorias: 1. status 1 bit: se o token est a livre ou n~ ao; 2. monitor 1 bit: se o token passou pela esta ca ~o mestre ou n~ ao. A esta c~ ao mestre ativa este campo sempre que um token passar por ela; 3. prioridade 3 bits: estipula a prioridade m
nima dos quadros que podem ser transmitidos com a captura do token. Se o valor deste campo for N, um host detentor do token pode transmitir quadros de prioridade maior ou igual a N; 4. reserva 3 bits: determina a prioridade do pr oximo token livre. Ao gerar um novo token, caso o valor da reserva seja maior que o valor da prioridade do token capturado, o host atribui o valor da reserva como prioridade do token. Se um host deseja reservar o token, este atribui ao campo de reserva a prioridade dos quadros que tem para transmitir, caso esta prioridade seja maior que a prioridade de reserva corrente. Para evitar que a prioridade do token cres ca inde nidamente, todo o host que aumentar a prioridade da reserva e capturar o token se compromete a liber a-lo com prioridade menor. O byte de TIPO estipula o tipo da informa c~ ao que o quadro carrega: dados oriundos das camadas superiores ou controle este u ltimo utilizado para a manuten c~ ao do anel. E frequente na literatura a a rma c~ ao que redes token ring s~ ao determin
sticas, isto e, apresentam um tempo de acesso ao meio limitado aproximadamente o tempo m aximo de reten c~ ao do token multiplicado pelo n umero de hosts no anel. Tal propriedade ocorre somente se o esquema de prioridade e reserva n~ ao seja utilizado. A gura 3.3 mostra o formato de um quadro no padr~ ao IEEE 802.5. Capturado o token, o quadro e injetado no anel logo a seguir. Os campos de endere co e checksum s~ ao id^ enticos ao IEEE 802.3. A quantidade de dados e ilimitada a rigor, limitada pelo tempo m aximo que um host pode reter o token. O campo DF delimitador de nal tamb em e composto por transi c~ oes Manchester Diferencial inv alidas. Um campo ap os o DF, ST status cont em dois bits: A e C. O bit A e ativado pelo host destino e informa o host fonte que o destinat ario tomou conhecimento do quadro a ele endere cado. O bit C
3.1.3 Passagem de Permiss~ ao no Padr~ ao IEEE 802.5
DCA-FEEC-UNICAMP
Bytes 1 1 1 6 ENDEREO DESTINO

6 ENDEREO FONTE sem limites 4 1 1
49
DI
CA
TIPO
DADOS
CHECKSUM
DF
ST
Figura 3.3: Formato dos quadros no IEEE 802.5 e ativado se o destinat ario aceitou o quadro pode t^ e-lo rejeitado por falta de a rea para armazenamento, por exemplo. Duas observa c~ oes importantes: 1. um quadro no IEEE 802.5 n~ ao de ne campo de tamanho do quadro; o campo de dados come ca 14 bytes ap os o campo DI do token e termina 4 bytes antes do campo DF do quadro; 2. o campo DF deve obrigatoriamente preceder o campo ST; o destinat ario est a em condi c~ oes de aceitar um quadro bit C do campo ST somente ap os computar o checksum e, como n~ ao existe quadro de tamanho de dados, o campo de checksum s o e de nido ap os o recebimento do campo DF. Uma das esta c~ oes do anel e rotulada como esta c~ ao mestre EM. Via de regra, e a primeira esta ca ~o a completar o procedimento de boot. Caso esta esta c~ ao falhe, uma nova EM e eleita. Periodicamente, a EM circula um token com o campo TIPO contendo a informa ca ~o ACTIVE MONITOR PRESENT. Se este token car sem circular por determinado per
odo, inicia-se um procedimento de escolha de uma nova EM. Assim que uma esta c~ ao termina o procedimento de boot, ela aguarda a passagem do token ou um quadro de ACTIVE MONITOR PRESENT. Expirado este tempo de espera, a esta c~ ao gera um quadro de controle com a informa ca ~o CLAIM TOKEN. Se este quadro circular sem altera c~ ao, a esta c~ ao que o emitiu se torna a esta ca ~o mestre. Se j a existir uma EM, a mesma altera o quadro de CLAIM TOKEN, informando ao emissor do quadro a sua exist^ encia. S~ ao atribui c~ oes da esta ca ~o mestre: drenar quadros corrompidos do anel; drenar quadros orf~ aos do anel quadros n~ ao drenados pelo emissor por falhas de hardware ou software; veri car se o token n~ ao se perdeu o host detentor do token falha em injetar um novo token no anel. Neste caso, a esta c~ ao mestre gera um novo token no anel.
Manuten ca ~o do Anel
DCA-FEEC-UNICAMP
50
O dreno de quadros pela esta c~ ao mestre e feito caso o bit de monitor do quadro CA estiver ativado quando o quadro passar pela EM indicando que se trata de uma segunda passagem. Finalmente, quando um host suspeitar da ruptura do anel tempo longo sem a passagem de tokens, este injeta um token de controle com a informa ca ~o BEACON no campo TIPO. Se o quadro voltar ao emissor, este sup~ oe que o problema foi sanado. Caso contr ario, a esta c~ ao entra num estado de standby aguardando o reestabelecimento do anel.
3.1.4 Passagem de Permiss~ ao no Padr~ ao IEEE 802.4
O padr~ ao IEEE 802.4 token bus emprega topologia de barramento, sendo o meio controlado por passagem de permiss~ ao. O anel l ogico gura 3.4 e estabelecido ordenando-se os hosts de acordo com os respectivos endere cos n umero formado pelos 48 bits que comp~ oem o endere co. O token circula no sentido do endere co mais alto para o mais baixo. O padr~ ao de ne quatro prioridades para os quadros: 0, 2, 4 e 6 a mais alta. Logicamente, e como se cada host tivesse quatro las de quadros para serem transmitidos. De posse do token, o host transmite os quadros de prioridade 6. Esgotados estes, os de prioridade 4 s~ ao transmitidos e assim por diante at e que todos os quadros pendentes se esgotem ou o tempo m aximo de posse do token for atingido. Os quadros do padr~ ao IEEE 802.4 t^ em o formato dado pela gura 3.4.
Bytes >= 1 1 1 6 ENDEREO DESTINO 6 ENDEREO FONTE 0-8174 4 1
PA
DI
TIPO
DADOS
CHECKSUM
DF
Figura 3.4: Formato dos quadros no IEEE 802.4 O pre^ ambulo PA tem durac~ ao superior ou igual a um per
odo de um byte. Sua fun c~ ao b asica e permitir que os hosts se preparem para receber o quadro, sincronizando seus rel ogios com o do host emissor. A seguir, o campo DI delimitador de in
cio cont em codi ca c~ oes inv alidas como no IEEE 802.5. O campo TIPO cont em os seguintes dados: 1. tipo do quadro 2 bits: se quadro de controle, de dados ou de gerenciamento do anel. 2. prioridade 3 bits: prioridade m
nima dos quadros que podem ser transmitidos com a captura do token. O padr~ ao IEEE 802.4 n~ ao prov^ e mecanismo de reserva como no IEEE 802.5. O campo de dados pode conter no m aximo 8174 bytes. O campo de checksum e o delimitador de nal DF s~ ao similares ao 802.5.
DCA-FEEC-UNICAMP
51
Cada esta c~ ao mant em o endere co de sua antecessora e de sua sucessora no anel. N~ ao existe esta c~ ao mestre. O anel e iniciado quando a primeira esta c~ ao termina o procedimento de boot. A esta c~ ao monitora o meio por determinado per
odo de tempo. Caso nenhuma atividade seja ao houver detectada, a esta c~ ao emite um quadro de controle to tipo CLAIM TOKEN. Se n~ contesta c~ ao, a esta ca ~o se torna detentora do token e neste caso, sozinha no anel. De posse do token e terminadas as transmiss~ oes, caso o per
odo de posse do token n~ ao tenha se expirado, a esta c~ ao cria uma janela de inclus~ ao, dando chance a outras esta c~ oes de ingressarem no anel l ogico. A esta c~ ao detentora do token propaga um quadro do tipo SOLICIT SUCESSOR com o seu endere co no campo de endere co fonte e o de sua atual sucessora no campo de endere co destino do quadro. Caso alguma esta c~ ao esteja esperando para ingressar no anel isto e, sua tentativa de iniciar o anel falhou e seu endere co esteja situado entre estas esta c~ oes, a mesma responde informando seu endere co. A esta c~ ao emissora armazena o novo endere co de sua sucessora, e informa a sua antiga sucessora que sua antecessora mudou. A esta c~ ao ingressante tem os endere cos de sua antecessora e sucessora no quadro que iniciou o procedimento. Caso mais de uma esta c~ ao responda a proposta de inclus~ ao, um procedimento de conten c~ ao seleciona apenas uma cando as demais aguardando as pr oximas janelas de inclus~ ao. A sa
da de uma esta c~ ao no anel e um procedimento mais simples que o ingresso. De posse do token, a esta c~ ao propaga um token do tipo SET SUCESSOR dirigida a sua antecessora com o endere co de sua sucessora no quadro. A esta c~ ao antecessora armazena sua nova sucessora, eliminando assim a esta ca ~o que iniciou o processo do anel l ogico. A passagem do token e um processo delicado. A esta c~ ao cria um quadro de controle do tipo TOKEN com o campo de endere co destino igual ao de sua sucessora. Recebido pela sucessora, esta se considera de posse do token. O host que passou o token certi ca-se de seu recebimento atrav es da escuta do meio. A esta c~ ao que recebeu o token acessa o meio logo a seguir seja para transmitir seus quadros, seja para passar o token adiante. Caso o meio que inativo, a esta c~ ao que passou o token propaga um quadro do tipo WHO FOLLOWS fornecendo o endere co de sua sucessora no campo de endere co destino do quadro. A esta c~ ao que tiver como antecessora este endere co responde, tornando-se a nova sucessora a receber o token a esta ca ~o que falhou em receber o token e eliminada do anel l ogico, podendo ingressar mais tarde via janela de inclus~ ao. Caso o procedimento de WHO FOLLOWS falhe, um quadro do tipo SOLICIT SUCESSOR2 e propagado solicitando que todas as esta c~ oes que seguem a emissora no anel l ogico respondam. Neste procedimento, mais de uma esta c~ ao e eliminada do anel l ogico. Duas situa c~ oes devem ainda ser gerenciadas: tokens duplicados: se uma esta c~ ao detentora do token "ouvir" uma transmiss~ ao, esta o descarta eventualmente todos os tokens duplicados s~ ao descartados, vide abaixo; perda do token: se uma esta ca ~o n~ ao receber o token por um per
odo longo, esta inicia um procedimento de CLAIM TOKEN. Caso mais de uma esta c~ ao o fa ca, um algoritmo de conten c~ ao indica a esta ca ~o vencedora que ter a a posse do token.
Manuten ca ~o do Anel L ogico
DCA-FEEC-UNICAMP
52
3.2 A Subcamada de Enlace L ogico LLC

A subcamada LLC prov^ e servi cos a camada de rede atrav es de SAPs ver Cap. 1 denominadas LSAPs. Tipicamente, 3 servi cos podem estar dispon
veis nas LSAPs detalhados a seguir: 1. servi co sem conex~ ao e sem reconhecimento; 2. servi co sem conex~ ao com reconhecimento; 3. servi co orientado a conex~ ao. Para prover tais servi cos, a subcamada LLC deve dispor das seguintes funcionalidades: parti c~ ao dos pacotes oriundos da camada de rede em quadros compat
veis com a subcamada de acesso ao meio; detec ca ~o de quadros corrompidos por erros de transmiss~ ao; recupera c~ ao de quadros corrompidos; estabelecimento e gerenciamento de conex~ oes; controle do uxo de quadros. Os quadros s~ ao de nidos de forma diferente para redes locais ou p ublicas. Em redes locais, os quadros t^ em o formato imposto pela subcamada de acesso ao meio e os dados referentes ao protocolo de enlace s~ ao incorporados num PDU ver Cap. 1 que trafega no campo de dados do quadro. Em redes p ublicas, n~ ao existe subcamadada de acesso ao meio, e os quadros s~ ao de nidos justamente para implementar os protocolos de enlace. Neste caso, os dados do protocolo possuem campos exclusivos no quadro. Na montagem de quadros, a delimita c~ ao dos mesmos merece alguns coment arios. Caso os quadros sejam compostos exclusivamente de caracteres o que e raro na atualidade pode-se de nir caracteres especiais para a delimita c~ ao de quadros. Por exemplo, o c odigo ASCII reserva alguns c odigos especiais para delimita c~ ao de blocos de dados como o Data Link Escape DLE, o Start of Text STX e o End of Text ETX. Assim, um quadro pode ser delimitado por:
DLE STX ... texto em ASCII ... DLE ETX
3.2.1 Montagem de Quadros
Os caracteres DLE, STX e ETX n~ ao ocorrem no interior do texto, pois s~ ao caracteres de controle. Atualmente, os dados que comp~ oem o quadro s~ ao sequ^ encias arbitr arias de bits n umeros, segmentos de mem oria, etc que n~ ao podem ser representados como sequ^ encia de caracteres texto. Nestes casos, duas t ecnicas s~ ao bastante empregadas:
DCA-FEEC-UNICAMP
53
Enchimento de Bits bit stu
Escolhe-se um delimitador de
nicio de quadro por exemplo 01111110 e previne-se de sua ocorr^ encia nos dados com uma regra simples como: A cada ocorr^ encia de cinco 1s adicionase um 0. O receptor do quadro executa procedimento inverso na recep c~ ao. A gura 3.5 ilustra este procedimento.
(a) (b)
ng
011011111111111111110010 011011111011111011111010010
bits adicionados
(c)
011011111111111111110010
Figura 3.5: Enchimento de bits: a dados originais, b dados no quadro, c dados decodicados pelo receptor.
Delimita-se o quadro com c odigos inv alidos empregados pela camada f

sica 1. Dado que tais c odigos jamais ocorrem na codi ca c~ ao de 0s e 1s, sua detec c~ ao indica o in
cio ou o nal de quadros. No c odigo Manchester Diferencial empregado pelo 802.5 utiliza-se transi c~ oes positivas H seguidas de negativas L: HHLLHHLL. Na modula c~ ao FSK-coerente empregada no 802.4, pode-se misturar frequ^ encias altas e baixas num mesmo per
odo do bit, gerando assim um c odigo inv alido gura 3.6.
INVLIDO INVLIDO 0 1
Viola c~ ao de C odigos da Camada F

sica
Figura 3.6: Exemplo de modula c~ ao FSK-coerente com c odigos inv alidos.

1
A rigor, quem gera os quadros inv alidos e a camada f

sica a partir de indicador suprido pela LLC.
DCA-FEEC-UNICAMP
54
A t ecnica mais usual para detec ca ~o de erros2 durante a transmiss~ ao de quadros e a Redund^ ancia C
clica CRC. Esta t ecnica n~ ao utiliza bits de redund^ ancia o su ciente para corre c~ ao do erro. Via de regra, detectado que um quadro chegou com erro, o receptor solicita ao emissor sua retransmiss~ ao. Em redes de computadores, a retransmiss~ ao e a t ecnica mais usual de corre c~ ao recupera c~ ao de erros. A t ecnica CRC e similar aos d
gitos de controle presentes no CPF, contas banc arias, etc. O d
gito de controle e computado por uma sequ^ encia de opera c~ oes bem de nida na origem e transmitido ao destino que o recomputa. Em havendo diferen ca entre os valores transmitido e computado, conclui-se sobre a invalidade do n umero. Na t ecnica CRC pode-se imaginar que os bits do quadro formam um gigantesco ! n umero inteiro. Se o quadro e composto por k bits numerados de 0 a k-1, este n umero e dado pelo polin^ omio:
3.2.2 Detec c~ ao de Erros
P x = bk , 1:x ,1 + bk , 2:x ,2 + :::b1:x + b0

k k
onde bj e o valor do bit na posi c~ ao j 0 ou 1 e x e a base da representa c~ ao 2. Por exemplo, 9 8 a sequ^ encia de 10 bits 1101011011 e representada pelo polin^ omio x + x + x6 + x4 + x3 + x +1. A t ecnica CRC reserva um n umero arbitr ario de bits n para detec c~ ao de erros checksum. Assim, s~ ao transmitidos n+k bits, sendo k de informa ca ~o seguidos de n bits de checksum. Os n bits de checksum s~ ao computados de forma que os n+k bits do quadro sejam representados por um polin^ omio F x:P x, sendo F x de ordem n. Seja um polin^ omio de refer^ encia, Gx de ordem n denominado polin^ omio gerador. Podemos escrever a seguinte igualdade:
F x:P x = Qx:Gx + Rx

onde Qx e de ordem k-1 e Rx de ordem n-1. Na t ecnica CRC escolhe-se F x = x e computa-se Rx dividindo-se os inteiros n~ ao os polin^ omios ! F x:P x por Qx. Neste caso, Rx formar a os bits de checksum. As opera c~ oes s~ ao feitas em aritm etica m odulo 2 sem o "vai 1":
n
Adi c~ ao 0+0=0 0+1=1 1+0=1 1+1=0
Subtra c~ ao 0-0=0 0-1=1 1-0=1 1-1=0
Multiplic. Divis~ ao 0x0=0 01=0 0x1=0 11=1 1x0=0 1x1=1
Em aritm etica m odulo 2, pode-se escrever
F x:P x = Qx:Gx + Rx

Erro neste contexto e a invers~ ao do valor de um ou mais bits. Invers~ oes de N bits em sequ^ encia e denominada erro de rajada de comprimento N.
2
DCA-FEEC-UNICAMP como
55
F x:P x + Rx = Qx:Gx Como F x = x o lado esquerdo da igualdade acima representa os bits originais acrescidos dos bits referentes a Rx a direita. No exemplo da sequ^ encia 1101011011, considerando-se n = 4 4 bits de checksum e tomando-se o polin^ omio gerador: Gx = x4 + x + 1 temos
n
Qx = x9 + x8 + x3 + x Rx = x3 + x2 + x A gura 3.7 ilustra as opera c~ oes, que nas implementa c~ oes pr aticas s~ ao efetuadas por hardware. Asssim os bits 1101011011 s~ ao transmitidos com quatro bits adicionais: 1101011011-1110
Dados do Quadro
11010 1 10110 0 0 0
Polinmio Gerador
10011 1001 1 10011 0000 1 00000 0001 0 00000 0010 1 00000 0101 1 00000 1011 0 10011 0101 0 00000 1010 0 10011 0111 0 00000 1110
RESTO
Figura 3.7: Exemplo do c^ omputo do checksum. Tanto a ITU-T como o IEEE padronizaram polin^ omios geradores para o c^ omputo de checksum.
DCA-FEEC-UNICAMP
56
CCR , 16 : x16 + x15 + x2 + 1 CCR , CCITT : x16 + x12 + x5 + 1 IEEE , 802:2 : x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x +1 Os polinomios CCR-16 e CCR-CCITT, para 16 bits de checksum s~ ao capazes de detectar: invers~ oes de 1 ou 2 bits; invers~ oes de um n umero
mpar de bits; rajadas de comprimento menor ou igual a 16; 99,997 das rajadas de comprimento 17; 99,998 das rajadas de comprimento 18.
3.2.3 T ecnicas de Recupera c~ ao de Erros por Retransmiss~ ao

Reconhecimento Positivo
As t ecnicas mais usuais de recupera c~ ao de erros por retransmiss~ ao s~ ao baseadas em reconhecimento. Neste m etodo, ao transmitir um quadro, o emissor aguarda outro de reconhecimento por parte do receptor, caso o primeiro tenha sido recebido livre de erros. Recebido um quadro de reconhecimento, o emissor envia o pr oximo quadro e assim sucessivamente. Caso o receptor tenha detectado um erro por exemplo, diferen ca entre o checksum computado e enviado, este simplesmente suprime o envio do reconhecimento. Expirado o tempo de espera pelo reconhecimento, o emissor retransmite o quadro.
Reconhecimento Negativo
Neste m etodo o receptor sempre transmite um quadro de reconhecimento imediatamente ap os a recep c~ ao de um quadro: reconhecimento positivo, caso nenhum erro tenha sido detectado, ou negativo, caso contr ario. A recep c~ ao de um reconhecimento negativo faz o emissor retransmitir prontamente o quadro, sem a necessidade de espera como no m etodo anterior.
Reconhecimento Cont
nuo
Os m etodos de reconhecimento positivo e negativo apresentam dois inconvenientes: 1. duplica ca ~o de quadros: 0 receptor recebe quadros duplicados em duas situa co ~es: quando o reconhecimento chegar ap os ter-se expirado seu tempo de espera; ou quando o reconhecimento e descartado na sua recep c~ ao devido a erros; 2. baixa e ci^ encia: para cada quadro transmitido, circula outro de controle reconhecimento no sentido inverso.
DCA-FEEC-UNICAMP
57
O m etodo de reconhecimento cont

nuo permite o emissor transmitir at e N largura da janela quadros sem a necessidade de espera por reconhecimento. Cada quadro carrega dois contadores, NS e NR, cujos valores dependem do tipo do quadro de informa c~ ao ou reconhecimento. A gura 3.8 compara o reconhecimento cont
nuo com o reconhecimento negativo.
HOST #1 HOST #2 HOST #1 HOST #2
PACOTE i
PACOTE i PACOTE j ACK(i) PACOTE k ACK(j) ACK(i)
PACOTE j ACK(k) ACK(j)
PACOTE k
ACK(k)
tempo
tempo
Figura 3.8: Reconhecimento negativo esquerda comparado com reconhecimento cont

nuo com janela de tamanho 3. Nos quadros de informa c~ ao que uem no sentido emissor-receptor, NS indica o n umero do quadro sendo transmitido e NR o n umero do pr oximo quadro esperado pelo emissor. Nos quadros de reconhecimento, NR indica o pr oximo quadro sendo esperado implicitamente os quadros numerados at e NR-1 foram recebidos livre de erros. NS e NR ocupam poucos bits, tipicamente 3, sendo neste caso um contador em m odulo 8. Isto justi ca a introdu c~ ao da janela em curso, permitindo maior seguran ca na identi ca c~ ao dos quadros. O reconhecimento cont
nuo permite duas formas de opera c~ ao quanto ao reconhecimento: 1. um quadro de reconhecimento para toda a janela; 2. quadros individuais de reconhecimeto. No primeiro caso o emissor veri ca se NR indica que a janela em curso se completou com sucesso. Neste caso, uma nova janela e iniciada com a transmiss~ ao dos pr oximos N quadros. Caso contr ario, o emissor retransmite os quadros a partir de NR at eou ltimo
DCA-FEEC-UNICAMP
58
quadro da janela, aguardando novo reconhecimento. Esta t ecnica reduz considravelmente os quadros de reconhecimento, aumentando a e ci^ encia do enlace. No segundo caso gura 3.8 o transmissor desliza avan ca a janela a cada quadro de reconhecimento recebido. Como para cada quadro de dado existe um de reconhecimento, a janela desliza continuamente, o que n~ ao ocorre no primeito caso. Esta t ecnica minimiza as retransmiss~ oes, sendo atrativa para enlaces sujeitos a altas taxas de erro. Quadros duplicados podem ainda ocorrer por exemplo, quando um quadro de reconhecimento e corrompido, mas sua detec ca ~o e simples, posto que os quadros s~ ao identi cados um a um. O enlace conex~ ao virtual pode se dar entre dois hosts ou emanando de um host para v arios outros. No primeiro caso o enlace e dito ponto-a-ponto, enquanto no segundo tem-se um enlace multiponto. Um enlace ponto-a-ponto ocorre, por exemplo, quando dois hosts se conectam para efetuar a transfer^ encia de um arquivo. Exemplo de enlace multiponto e um computador central controlando v arios terminais dispersos geogra camente. Podemos identi car tr^ es tipos de esta c~ oes hosts quanto suas responsabilidades pelo enlace: 1. esta co ~es prim arias: controlam totalmente o enlace; 2. esta co ~es secund arias: recebem comandos da prim aria, podendo transmitir pelo enlace somente quando autorizadas por esta; 3. esta c~ oes combinadas: atuam de forma dual, ora como prim aria ora como secund aria, dependendo do contexto. Enlaces ponto-a-ponto s~ ao constitu
dos tipicamente por duas esta c~ oes combinadas, enquanto enlaces multiponto s~ ao formados por uma prim aria e v arias secund arias. Um enlace pode ser estabelecido para operar em um dos tr^ es modos abaixo: 1. modo de resposta normal: a esta c~ ao prim aria envia um quadro de consulta para as suas secund arias inquirindo sobre a exist^ encia de quadros para transmitir; em caso positivo, a secund aria transmite imediatamente ap os ter recebido o quadro de consulta; 2. modo de resposta ass
ncrono: as esta c~ oes secund arias transmitem independentemente da consulta por parte da prim aria; este modo e geralmente empregado quando as esta c~ oes secund arias se conectam a prim aria por canais exclusivos por exemplo, linhas seriais; este modo n~ ao e empregado em redes de computadores; 3. modo de resposta ass
ncrono balanceado: utilizado em enlaces ponto-a-ponto envolvendo apenas esta co ~es combinadas; as esta c~ oes gerenciam o enlace de acordo com um protocolo de nido pelas camadas de enlace dos hosts comunicantes. Finalmente, um enlace e governado por um protocolo composto de quatro fases:
3.2.4 Formas de Estabelecimento do Enlace
DCA-FEEC-UNICAMP
59
1. estabelecimento do enlace, onde um host toma a iniciativa do estabelecimento de uma conex~ ao virtual com um ou mais hosts; 2. transfer^ encia de dados, onde os hosts que comp~ oem a conex~ ao trocam quadros de informa c~ ao atrav es desta; 3. encerramento do enlace, onde um dos hosts toma a iniciativa de propor o encerramento da conex~ ao; 4. reinicia c~ ao do enlace, onde um host toma a iniciativa de reinicializar o protocolo de transfer^ encia de quadros pelo enlace pela ocorr^ encia de um erro irrecuper avel. O controle de uxo e necess ario quando um receptor de quadros v^ e-se na impossibilidade moment^ anea de continuar a recep c~ ao. V arias s~ ao as raz~ oes para isso ocorrer: exaust~ ao de bu ers, ocorr^ encia de erros internos de hardware ou software, atendimento de atividades de comunica c~ ao mais priorit arias, etc. Em protocolos baseados no reconhecimento positivo ou negativo, o controle do uxo e desnecess ario, pois o emissor s o envia o pr oximo quadro ap os o recebimento do reconhecimento do receptor. Caso o receptor deseje a suspens~ ao tempor aria do envio de quadros, este simplesmente deixa de enviar os quadros de reconhecimento. Em protocolos que empregam o reconhecimento cont
nuo, dois quadros de controle s~ ao empregados para o controle de uxo: quadros RR Receiver Ready: informa o emissor que o receptor est a pronto para iniciar ou continuar a recep c~ ao de quadros; quadros RNR Receiver Not Ready: informa o emissor que o receptor est a impossibilitado temporariamente de receber quadros. Os quadros RR e RNR visam aumentar a e ci^ encia do canal compartilhado evitando a circula c~ ao de quadros de dados que com certeza ser~ ao descartados pelo receptor.
3.2.5 Controle do Fluxo de Quadros
3.3 Protocolos de Enlace
O protocolo HDLC High-level Data Link Control e padronizado pela ISO, servindo de base para o X.25 camada 2 que emprega um subconjunto denominado LAPB Link Access Procedure, Balanced3. No HDLC, os quadros t^ em o formato apresentado na gura 3.9. O quadro possui um delimitador de in
cio e nal composto dos bits 01111110. Um procedimento de codi ca ca ~o de bits e empregado para evitar a ocorr^ encia desta sequ^ encia no quadro. O campo de endere co
O LAPB restringe o HDLC por permitir apenas enlace no modo de resposta ass
ncrono balanceado - ver subse c~ ao 3.2.4.
3
3.3.1 O Protocolo ISO HDLC para Redes P ublicas
DCA-FEEC-UNICAMP
60
e utilizado em conex~ oes multiponto para identi car as esta c~ oes secund arias da conex~ ao. Em conex~ oes ponto-a-ponto este campo e utilizado para distinguir quadros de comandos dos de resposta.
Bits 8 8 8 >= 0 16 8
01111110
ENDEREO
CONTROLE
DADOS
CHECKSUM
01111110
Figura 3.9: Formato do quadro no protocolo HDLC. O campo de dados possui tamanho arbitr ario, mas normalmente limitado por restri c~ oes impostas pela camada f
sica. O campo de checksum e computado pelo polin^ omio gerador x16 + x12 + x5 + 1. O campo de controle de ne tr^ es tipos de quadros: de informa c~ ao I, de supervis~ ao S e n~ ao numerados N, sendo os dois u ltimos quadros de controle gura 3.10.
Bits 1 0 3 N(S) 1 P/F 3 N(R) INFORMAO
1 1
1 0
1 S
1 S
1 P/F
3 N(R) SUPERVISO
1 1
1 1
1 M
1 M
1 P/F M
3 M M NO NUMERADO
Figura 3.10: Formatos do campo de controle no protocolo HDLC. Os quadros de informa ca ~o carregam os contadores NS e NR para reconhecimento cont
nuo do uxo de quadros. Os quadros de supervis~ ao s~ ao empregados no controle de uxo e como reconhecimento da recep c~ ao de quadros. Tr^ es tipos instru c~ oes podem estar contidas no campo SS: 1. RR Receiver Ready: informa que o receptor est a pronto para continuar a recep ca ~o de quadros a partir de NR, inclusive. 2. RNR Receiver Not Ready: informa que o receptor reconhece o recebimento de todos os quadros at e NR-1, e solicita a suspens~ ao tempor aria do envio de novos quadros.
DCA-FEEC-UNICAMP
61
3. REJ Reject: informa que o receptor detectou um erro na recep ca ~o do quadro NR e solicita o envio a partir deste. Os quadros n~ ao numerados s~ ao utilizados para estabelecimento e t ermino de conex~ oes. Seis tipos de intru c~ oes s~ ao de nidas: 1. SNRM Set Normal Response Mode: estabelece uma conex~ ao entre esta c~ ao prim aria e secund aria. 2. SABM Set Asynchronous Balanced Mode: estabelece uma conex~ ao entre esta c~ oes combinadas. 3. DISC Disconnect: informa o outro extremo da conex~ ao que este host deseja terminar o enlace. 4. DM Disconnect Mode: Informa que uma conex~ ao solicitada n~ ao pode ser estabelecida por exemplo, por falta de espa co para armazenar os par^ ametros de controle da conex~ ao. 5. UA Unnumbered Acknowledgement: reconhece positivamente comandos de estabelecimento, t ermino e reinicializa c~ ao de conex~ ao. 6. FRMR Frame Reject: um quadro foi recebido com erro atrav es da conex~ ao e seu conte udo n~ ao p^ ode ser identi cado. O bit P F Pool Final e ativado por uma esta c~ ao prim aria quando em consulta a uma secund aria. Caso tenha quadros para transmitir, a esta c~ ao secund aria o faz com o bit P F ativado, at eou ltimo quadro onde o bit P F e desativado, indicando o nal da transmiss~ ao. O protocolo de enlace de nido pelo IEEE no escopo do padr~ ao 802 e denominado LLC Logical Link Control e foi inspirado no HDLC descrito acima. No padr~ ao 802, os quadros t^ em o formato como o da gura 3.1. O LLC especi ca o formato do PDU que e parte dos dados do quadro. Este PDU, denominado LPDU, tem o formato dado pela gura 3.11.
Bytes 1 ENTIDADE DESTINO 1 ENTIDADE FONTE 1 ou 2 >=0
3.3.2 O Protocolo IEEE 802.2 para Redes Locais
CONTROLE
INFORMAO
Figura 3.11: Formatos de um LPDU. O campo ENTIDADE FONTE especi ca qual entidade gerou o PDU, enquanto o campo ENTIDADE DESTINO estipula a entidade para a qual o PDU se destina. O protocolo prev^ e servi cos sem conex~ ao com e sem reconhecimento e os servi cos orientados a conex~ ao
DCA-FEEC-UNICAMP
62
L-CONNECT.requestend local, end remoto, classe de servi co L-CONNECT.indicationend local, end remoto, classe de servi co L-CONNECT.responseend local, end remoto, classe de servi co L-CONNECT.con rmend local, end remoto, classe de servi co L-DISCONNECT.requestend local, end remoto L-DISCONNECT.indicationend local, end remoto L-DATA.requestend local, end remoto, l sdu L-DATA.indicationend local, end remoto, l sdu L-EXPEDITED-DATA.requestend local, end remoto, l sdu L-EXPEDITED-DATA.indicationend local, end remoto, l sdu L-RESET.requestend local, end remoto L-RESET.indicationend local, end remoto L-RESET.responseend local, end remoto L-RESET.con rmend local, end remoto L-ERROR-REPORT.indicationraz~ ao L-UNIT-DATA.requestend local, end remoto, l sdu, classe de servi co L-UNIT-DATA.indicationend local, end remoto, l sdu, classe de servi co Tabela 3.1: Primitivas OSI de enlace. L-UNIT-DATA e utilizada para os servi cos sem conex~ ao; as demais para servi cos com conex~ ao. oferecidos pelo protocolo LLC. A camada de rede invoca estes servi cos atrav es de primitivas de nidas pela subcamada de enlace l ogico. As fam
lias de primitivas s~ ao: L-CONNECT: estabelecimento de conex~ ao com con rma c~ ao; L-DISCONNECT: t ermino de conex~ ao sem con rma c~ ao; L-DATA: envio de quadros de dados atrav es da conex~ ao sem con rma c~ ao; L-RESET: reinicializa c~ ao de conex~ ao com con rma c~ ao; L-ERROR-REPORT: informe de erros pelo provedor indica c~ ao apenas; L-EXPEDITED-DATA: envio de dados urgentes atrav es da conex~ ao sem con rma ca ~o; L-UNIT-DATA: envio de dados sem conex~ ao sem cor rma c~ ao. A tabela 3.1 ilustra o formato destas primitivas. A interface LLC MAC e do tipo sem conex~ ao, j a que a comunica c~ ao entre ambas e local interior a camada de enlace ou interface de rede. Uma u nica primitiva, MA-DATA, e empregada para transferir informa c~ ao entre as subcamadas LLC e MAC. O campo de controle do LPDU e inspirado no HDLC. Os tr^ es tipos de quadros do HDLC informa c~ ao, supervis~ ao e n~ ao numerados s~ ao de nidos no protocolo LLC.
DCA-FEEC-UNICAMP
63
Quadros de informa ca ~o s~ ao subdivididos em dois grupos: tipo I Information que transportam dados atrav es de conex~ oes, e tipo UI Unnumbered Information que transportam datagramas. Quadros de supervis~ ao s~ ao do tipo RR, RNR, REJ id^ enticos ao X.25. Quadros n~ ao numerados s~ ao do tipo SABM4, DISC, DM, UA e FRMR tamb em id^ enticos ao X.25. Dois tipos de quadros n~ ao numerados, ausentes no X.25, s~ ao listados a seguir: 1. TEST: utilizado para testar uma conex~ ao, fazendo com que o outro lado envie quadro similar. 2. XID Exchange Information: utilizado para um host comunicar os tipos de servi cos providos e tamanhos de janelas.
3.4 Problemas
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Descreva o funcionamento dos principais m etodos de acesso ao meio para redes locais. Descreva os campos que comp~ oem o quadro dos padr~ oes IEEE 802.3, 802.4 e 802.5. Descreva os campos que comp~ oem o token dos padr~ oes IEEE 802.4 e 802.5. Descreva a manuten c~ ao do anel no padr~ ao IEEE 802.5. Descreva as t ecnicas mais usuais para delimita c~ ao de quadros e em que situa c~ oes s~ ao empregadas. Por que protocolos de enlace baseados em caracter est~ ao superados ? Compute o checksum utilizando a t ecnica CRC para a sequ^ encia de 12 bits 111001100010 4 2 e polin^ omio gerador x + x + x + 1. Fa ca um diagrama temporal mostrando a transmiss~ ao de quadros com reconhecimento cont
nuo e largura de janela 3, utilizando quadros de controle tipo RR e RNR. Descreva os quadros n~ ao numerados empregados pelo padr~ ao X.25 camada 2. Fa ca um diagrama temporal mostrando o estabelecimento de enlace, envio de quadros e t ermino do enlace utilizando os quadros do protocolo HDLC.
O LLC suporta apenas o modo de resposta ass

ncrono balanceado, isto e, todas as esta c~ oes s~ ao combinadas.
4
Cap
tulo 4 A CAMADA DE REDE
A camada de rede e a terceira e u ltima camada onde o uxo de informa ca ~o leva em conta as peculiariedades da subrede de comunica c~ ao, tais como a exist^ encia de IMPs, como os IMPs se interconectam, etc. A partir desta, as camadas acima empregam mecanismos de comunica ca ~o host a host, abstraindo a exist^ encia da subrede de comunica c~ ao. Para que a camada de transporte venha independer da topologia e tecnologia da subrede de comunica ca ~o, a camada de rede deve prover: entrega de pacotes: recolher um pacote do host emissor e entreg a-lo ao host receptor; roteamento: escolha da rota de comunica c~ ao por onde os pacotes oriundos da camada de transporte ir~ ao trafegar; controle de congestionamento: evitar que IMPs quem congestionados de pacotes devido a surtos de tr afego ou roteamento mal conduzido; interconex~ ao de redes internetworking: possibilitar que hosts em subredes heterog^ eneas possam se comunicar por exemplo, um host numa subrede Ethernet e outro numa subrede Token Ring.
4.1 Entrega de Pacotes

Pacote e a unidade de informa c~ ao que trafega entre os IMPs de uma rede de longa dist^ ancia. Quando um host DTE necessitar transferir um pacote, este o entrega ao IMP ao qual ele se conecta sicamente via DCE. O IMP escolhe uma rota para o pacote tendo como destinat ario o IMP ao qual o host de destino est a conectado, para, a partir deste, ser entregue ao destinat ario nal novamente, via DCE. O tr afego entre os IMPs pode se dar atrav es de uma conex~ ao pr e-estabelecida ou sem o estabelecimento pr evio de conex~ ao. No primeiro caso a camada de rede e dita orientada a conex~ ao. Se a camada de rede n~ ao suporta circuitos virtuais conex~ oes, a mesma e dita sem conex~ ao ou orientada a datagrama. A camada de transporte acessa o servi co de entrega de pacotes atrav es de NSAPs Network Service Acess Points. NSAPs s~ ao endere cos que identi cam no n
vel de rede as entidades provedoras do servi co. O modelo OSI especi ca um NSAP gura 4.1 contendo 64
DCA-FEEC-UNICAMP
65
valores decimais, n~ ao ocupando mais que 40 d

gitos 20 bytes. O NSAP e dividido em tr^ es campos: 1. AFI Authority and Format Indicator: indica o tipo de numera c~ ao presente no terceiro campo n umero de telefone, endere co Internet, etc. Ocupa 1 byte codi cando dois d
gitos decimais com valores entre 10 e 99; 2. IDI Initial Domain Identi er: especi ca o dom
nio ao qual o terceiro campo pertence. Por exemplo, se o terceiro campo armazena o n umero de um telefone, o IDI pode conter o c odigo do pa
s. Este campo armazena um n umero vari avel de bytes, fun c~ ao do campo AFI; 3. DSP Domain Speci c Part: armazena o endere co do servi co propriamente dito. Cont em um n umero vari avel de bytes, fun c~ ao dos campos AFI e IDI.
PARTE INICIAL DO DOMNIO (IDP)
INDICADOR DE FORMATO E AUTORIDADE (AFI)
IDENTIFICADOR INICIAL DE DOMNIO (IDI)
PARTE ESPECFICA DO DOMNIO (DSP)
Figura 4.1: Formato de NSAP para redes OSI.
No caso de redes locais, conex~ oes no n

vel de camada de rede s~ ao similares as conex~ oes no n
vel de camada de enlace: apenas dois hosts s~ ao envolvidos e apenas estes dela tomam parte. Em redes de longa dist^ ancia, uma conex~ ao no n
vel da camada de enlace envolve tamb em dois computadores: o host e o IMP ao qual se conecta via DCE. O objetivo desta conex~ ao e a entrega con a vel de quadros mesmo que o DCE esteja sicamente conectado ao IMP atrav es de em canal sujeito a ru
do. Uma conex~ ao no n
vel de camada de rede, por outro lado, requer a intermedia ca ~o de m ultiplos IMPs, pois a conex~ ao se estende de host a host, via IMPs. No estabelecimento de uma conex~ ao deste tipo, escolhe-se uma rota vide pr oxima se c~ ao e o tr afego de pacotes se dar a sempre por esta rota. Um IMP que toma parte de uma conex~ ao, recebe um pacote do IMP antecessor ou host emissor, armazena-o temporariamente at e que pacotes recebidos previamente possam uir, e o entrega ao IMP sucessor ou host de destino. As vantagens de se estabelecer conex~ ao e a aloca ca ~o de recursos a priori para a transmiss~ ao de pacotes, garantindo que pacotes n~ ao ser~ ao descartados por falta de recursos para seu armazenamento quando em tr^ ansito. Como desvantagem do emprego de conex~ oes podemos citar: se um IMP que toma parte da conex~ ao falhar, a mesma estar a comprometida;
4.1.1 Camadas de Rede Orientadas a Conex~ ao
DCA-FEEC-UNICAMP
66
a rede se torna mais suscept

vel a congestionamentos, dada a impossibilidade de se reorientar conex~ oes j a estabelecidas; os recursos alocados a uma conex~ ao se tornam sub-utilizados se a taxa de transmiss~ ao de pacotes pela conex~ ao for baixa.
4.1.2 Camadas de Rede Orientadas a Datagrama
Camadas de rede orientadas a datagrama n~ ao estabelecem conex~ ao para o envio de pacotes. O servi co de entrega e pouco con avel, cabendo a camada de transporte gerenciar pacotes perdidos, duplicados ou que chegam fora de ordem. Como recursos n~ ao s~ ao previamente alocados para o tr afego de pacotes, estes est~ ao sujeitos ao descarte quando um IMP n~ ao for capaz process a-los. Cada pacote e roteado individualmente, independente dos demais. Neste caso, a garantia de entrega de pacotes na ordem em que foram emitidos n~ ao e veri cada. Pacotes podem ser duplicados caso pacotes de reconhecimento RR da camada superior n~ ao atinjam o destino. A vantagem das camadas de rede orientadas a datagrama est a na sua simplicidade e capacidade de se adaptar prontamente as condi c~ oes de tr afego da rede e a falhas de IMPs. Como desvantagens, uma so sticada camada de transporte e requerida. Em outas palavras, ca a cargo dos hosts isto e, dos usu ario da subrede de comunica c~ ao gerenciar a con abilidade do servi co de entrega de pacotes. Nas camadas de rede orientadas a conex~ ao, esta con abilidade recai sobre os IMP isto e, sobre a pr opria subrede de comunica c~ ao. A tabela 4.1 ilustra as primitivas OSI ofereciadas pela camada de rede a camada de transporte para servi cos sem e com conex~ ao.
4.2 Roteamento
O problema de rotear pacotes inexiste quando a comunica c~ ao se d a numa rede local: o pacote atinge o host destinat ario sem a intermedia c~ ao de IMPs. Em redes MAN e WAN, a exist^ encia de IMPs obriga, na transmiss~ ao de um pacote, a se proceder a escolha de um circuito entre o emissor e o destinat ario do pacote. No circuito, um ou mais IMPs ir~ ao receber o pacote, armazen a-lo temporariamente e retransmit
-lo ao pr oximo IMP do circuito. Roteamento e um problema presente em muitas atividades. Imagine um servi co de entrega r apida com v arios dep ositos e uma frota de ve
culos. Quando um ve
culo apanha uma encomenda de um cliente, v arios procedimentos podem ser adotados: 1. entregar a encomenda imediatamente ao destinat ario com o mesmo ve
culo; 2. armazenar a encomenda num dep osito para ser entregue com outras encomendas destinadas a mesma regi~ ao; 3. mover a encomenda de dep osito em dep osito at e atingir o mais pr oximo do cliente, de onde ser a entregue.
DCA-FEEC-UNICAMP
67
N-UNITDATA.requestend local, end remoto, QoS, dados N-UNITDATA.requestend local, end remoto, QoS, dados N-FACILITY.requestQoS N-FACILITY.indicationend remoto, QoS, motivo N-REPORT.indicationend remoto, QoS, motivo N-CONNECT.requestNSAP local, NSAP remoto, ACK, EXP, QoS, dados N-CONNECT.indicationNSAP local, NSAP remoto, ACK, EXP, QoS, dados N-CONNECT.responseNSAP remoto, ACK, EXP, QoS, dados N-CONNECT.con rmNSAP remoto, ACK, EXP, QoS, dados N-DISCONNECT.requestrequerente, motivo, dados, end resposta N-DISCONNECT.indicationent solicitante, motivo, dados, end resposta N-DATA.requestdados N-DATA.indicationdados N-DATA-ACKNOLEDGE.request N-DATA-ACKNOLEDGE.indication N-EXPEDITED-DATA.requestdados N-EXPEDITED-DATA.indicationdados N-RESET.requestent solicitante, motivo N-RESET.indicationent solicitante, motivo N-RESET.response N-RESET.con rm Tabela 4.1: Servi cos ofereciados pela camada de rede: as primitivas N-UNITDATA, NFACILITY e N-REPORT s~ ao empregadas em servi cos sem conex~ ao; as demais em servi cos com conex~ ao.
DCA-FEEC-UNICAMP
68
Au ltima op c~ ao e an aloga a redes de computadores. Os IMPs s~ ao dep ositos de pacotes e somente o IMP diretamente conectado a subrede do host destinat ario e que est a habilitado a fazer a entrega. O problema de roteamento e de natureza combinat oria, sendo portanto computacionalmente complexo caso desejamos obter a solu c~ ao otima1. A area de Pesquisa Operacional tem produzido v arios algoritmos para este problema, bem como heur
sticas para a obten c~ ao de solu c~ oes sub- otimas. Infelizmente, tais algoritmos e heur
sticas requerem o conhecimento pr evio do uxo dos objetos roteados, ou uma boa estat
stica do mesmo. Em redes de computadores n~ ao dispomos da informa c~ ao antecipada quanto ao uxo de pacotes. Isto demanda o c^ omputo do uxo on-line, periodicamente, ou frente a uma condi ca ~o de congestionamento na rede. Em outra palavras, em redes de computadores o roteamento deve ter caracter
stica din^ amica. A forma mais simples de rotear pacotes numa subrede e dotar cada IMP de uma tabela de roteamento contendo o melhor circuito ligando este IMP aos demais. Via de regra, a tabela armazena mais de um circuito entre dois IMPs, na eventualidade de uma rota de comunica c~ ao ou um IMP do circuito sair de servi co. Num roteamento din^ amico, a tabela de roteamento varia de acordo com as condi c~ oes de tr afego da subrede. Em redes de computadores, o roteamento din^ amico pode ser centralizado ou distribu
do. No roteamento centralizado, os IMPs enviam periodicamente informa c~ oes de tr afego a uma central de roteamento NCC: Network Control Center. A central disp~ oe de informa c~ oes sobre: os IMPs que est~ ao ativos e os que est~ ao inativos por falha, manuten ca ~o, etc; as rotas de comunica c~ ao que est~ ao ativas e as que est~ ao inativas; o uxo m edio de pacotes nas rotas ativas; o tempo m edio que um pacote ca armazenado num IMP; etc. A partir destas informa c~ oes o NCC, computa qual seria o roteamento o timo ou sub- otimo de pacotes para uma dada situa c~ ao de tr afego. Computado o roteamento, o NCC distribui novas tabelas de roteamento aos IMPs. O roteamento centralizado e vi avel apenas nos dom
nios da operadora da subrede de comunica c~ ao.
etc
1
4.2.1 Roteamento Centralizado
O crit erio de otimalidade pode ser: m

nimo tempo de tr^ ansito, caminho m
nimo, m axima con abilidade,
DCA-FEEC-UNICAMP
69
O roteamento distribu
do n~ ao utiliza um elemento centralizador como o NCC. A primeira consequ^ encia da distribui c~ ao e a indisponibilidade de uma vis~ ao global do tr afego na subrede. No roteamento distribu
do, cada IMP e respons avel pela atualiza c~ ao de sua tabela de roteamento. Em geral, esta atualiza c~ ao e fruto da troca de informa c~ oes de tr afego entre IMPs diretamente conectados. A tabela de roteamento disp~ oe de um
ndice para cada IMP da subrede e armazena informa co ~es de roteamento para os circuitos iniciando no IMP detentor da tabela. Cada posi c~ ao na tabela armazena duas informa c~ oes: o pr oximo host do circuito diretamente conectado ao detentor da tabela, e uma estimativa do tempo que o pacote levar a para atingir o destinat ario nal. Estimativas de tempo s~ ao obtidas circulando periodicamente pacotes de eco entre IMPs diretamente conectados. O emissor de um pacote de eco marca no pacote o instante de tempo em que o pacote foi gerado e o transmite ao destinat ario. O destinat ario, ao recebelo, simplesmente o envia de volta ao emissor. O tempo de circula c~ ao de um pacote de eco e uma boa m etrica das condi c~ oes de tr afego entre dois IMPs o tempo m edio de tr afego no trecho e igual ao tempo de circula c~ ao do pacote dividido por dois. Considere a subrede da gura 4.2. A subrede e representada por um grafo onde os n os representam os IMPs e os arcos rotas de comunica c~ ao entre IMPs. Suponha que ao transmitir um pacote de eco, o IMP envia tamb em as medidas de tempo m edio de tr afego para todos os demais IMPs a partir deste. Com isto, um IMP J disp~ oe do tempo m edio de tr afego: entre J e I todos os IMPs diretamente conectados ao IMP J; entre I e os demais IMPs.
j j
4.2.2 Roteamento Distribu

do
F E
G H
J I
Figura 4.2: Uma subrede de comunica ca ~o. As quatro primeiras colunas da tabela 4.2 consistem de vetores recebidos por J de seus vizinhos A, I, H, K. Na primeira coluna A informa J que o tempo m edio para atingir B e 12
DCA-FEEC-UNICAMP A B C D E F G H I J K L
Redes de Computadores: Modelo OSI X.25 0 12 25 40 14 23 18 17 21 9 24 29 24 36 18 27 7 20 31 20 0 11 22 33 20 31 19 8 30 19 6 0 14 7 22 9 21 28 36 24 22 40 31 19 22 10 0 9 8 20 28 20 17 30 18 12 10 0 6 15 A A I H I I H H I K K
70
Tabela 4.2: Quadros de eco recebidos pelo IMP J dos IMPs A, I, H e K colunas 1-4 e sua tabela de roteamento ultima coluna. mseg, 25 mseg para C, e assim por diante. A u ltima coluna da tabela cont em a estimativa levantada pelo pr oprio IMP J. De posse dos quatro vetores, J pode computar o tempo de tr afego m
nimo entre ele e qualquer outro IMP quinta coluna da tabela 4.2. A segunda coluna da tabela informa o IMP que deve ser enviado o pacote caso o destinat ario nal seja o IMP dado pela linha correspondente. Vajamos como esta tabela de roteamento e gerada. Os IMPs medem periodicamente o tempo de comunica ca ~o para com os vizinhos. Sempre que um pacote de eco e enviado, o receptor adiciona a ele as estimativas de tr afego de que disp~ oe obtidas por ele ou enviadas em pacotes de eco pelos vizinhos. Como a subrede de comunica c~ ao forma um grafo conectado, pouco a pouco as tabelas v~ ao se completando, at e que todos os IMPs disponham de estimativas de tr afego a partir dos IMPs vizinhos para qualquer outro IMP da rede. Por exemplo, qual o melhor roteamento de J para F ? Certamente este roteamento deve passar por A, I, K ou H. Passando por A, J disp~ oe do custo J-A 8 mseg por medida pr opria e 23 mseg de A para F, informado por A no vetor recebido por J coluna 1. Um tempo de 31 mseg e incorrido se o roteamento de J para F passar por A. Note que J desconhece como A ir a rotear o pacote para F, sabendo apenas que o menor tempo para tal e 23 mseg. Analogamente, tempos de 30, 31 e 46 mseg s~ ao incorridos caso o roteamento se d^ e via I, H e K, respectivamente. Neste caso, sempre que necessitar rotear um pacote por F, J o faz via I com um custo de 30 mseg. A tabela de roteamento de J e recomputada todas as vezes que J receber um novo vetor de seus vizinhos ou obter uma medida por iniciativa pr opria.
DCA-FEEC-UNICAMP
71
4.3 Controle de Congestionamento

Vimos no cap
tulo anterior que a camada de enlace e capaz de controlar o uxo de quadros entre dois hosts comunicantes. Cabe a camada de rede controlar o uxo de pacotes entre IMPs evitando que um IMP receba mais pacotes do que e capaz de processar. Tal como roteamento, esta atividade e inexistente em redes locais, bastando neste caso um controle entre as camadas de rede e de enlace no mesmo host como e feito no IEEE 802.2 - ver Cap. 3. Vamos examinar duas estrat egias de controle de congestionamento: pr e-aloca c~ ao de buffers e descarte de pacotes. A primeira e mais empregada para comunica ca ~o conectada e a segunda para comunica c~ ao sem conex~ ao. Um recurso importante que um IMP disp~ oe para o processamento de pacotes s~ ao bu ers de mem oria. Em caso do estabelecimento de uma conex~ ao no n
vel de camada de rede, todos os IMPs envolvidos alocam bu ers capazes de abrigar tantos pacotes quanto for o tamanho da janela, garantindo que pacotes que trafegam nos dois sentidos ter~ ao espa co de armazenamento alocado a priori. Caso este espa co n~ ao possa ser alocado no momento do estabelecimento da conex~ ao por um IMP, outro circuito pode ser escolhido ou a conex~ ao e recusada. Esta estrat egia, entretanto, pode representar uma sub-utiliza c~ ao dos recursos, no caso de uma conex~ ao ser estabelecida e poucos pacotes circularem por ela. Pior ainda, novas conex~ oes podem ser recusadas em favor de conex~ oes ociosas" j a estabelecidas. Este problema pode ser resolvido criando-se um pool de bu ers e ir alocando e desalocando a medida da necessidade. Utilizando-se um pool de bu ers corre-se o risco de um pacote chegar num IMP e n~ ao existir bu er dispon
vel para armazen a-lo. Neste caso, a conex~ ao e rearranjada tirando este IMP do circuito, reiniciada ou um sinal de ocupado e enviado ao IMP que emitiu o pacote, solicitando sua retransmiss~ ao mais tarde.
4.3.1 Pr e-aloca c~ ao de Bu ers
4.3.2 Descarte de Pacotes
Esta estrat egia de controle de congestionamento e oposta a apresentada acima. Cada IMP possui um conjunto de bu ers para a recep c~ ao um por linha chegando no IMP e para o armazenamento local de pacotes antes de sua retransmiss~ ao. Caso um pacote seja recebido e n~ ao exista espa co dispon
vel para armazen a-lo, o mesmo e simplesmente descartado. Em geral, pacotes de controle n~ ao s~ ao descartados, sendo processados no pr oprio bu er de recep c~ ao. A raz~ ao para tal e que pacotes de controle geralmente causam a libera c~ ao de pacotes de dados armazenados. Por exemplo: pacotes de reconhecimento liberam pacotes de dados j a transmitidos mas ainda armazenados caso sua retransmiss~ ao se fa ca necess aria; pacotes de encerramento ou reinicia c~ ao de conex~ ao causam o descarte de pacotes ainda uindo pela conex~ ao.
DCA-FEEC-UNICAMP
72
Seja um IMP com k bu ers dispon

veis para armazenamento de pacotes bu ers alocados a recep c~ ao n~ ao contam e s linhas de sa
da. Como cada pacote recebido e roteado para uma dada linha de sa
da, pode-se dizer que os bu ers armazenando pacotes s~ ao alocados as linhas de sa
da. Obviamente, uma u nica linha n~ ao pode monopolizar os k bu ers do pool. Ent~ ao, qual o n umero m aximo de bu ers, m, que devemos alocar por linha p ? Estudos emp
ricos mostram um n umero adequado de bu ers e dado pela rela c~ ao m = k= s. A rede ARPANET utilizava esta estrat egia de controle de congestionamento, mas alocando um n umero m
nimo de bu ers por linha de sa
da. Isto evita que linhas de alto tr afego mantenham permanentemente os bu ers a ela alocados causando o descarte permanente de pacotes que uem por linhas de pouco tr afego.
4.4 Interconex~ ao de Redes

Dois fatos: redes s~ ao heterog^ eneas e redes necessitam ser interligadas. Redes s~ ao heterog^ eneas o porque cada fornecedor desenvolveu e comercializa sua pr opria arquitetura de rede. E caso da arquitetura SNA da IBM, DECNET da Digital, NetWare da Novell, e assim por diante. Se todas as redes empregassem o modelo OSI ISO com id^ entica pilha de protocolos, a interconex~ ao de redes seria uma tarefa trivial. Redes necessitam ser interconectadas para possibilitar o compartilhamento de recursos e informa ca ~o. A interconex~ ao pode ocorrer n
vel de: LAN-LAN: conex~ ao entre duas LANs numa mesma organiza c~ ao; LAN-WAN: conex~ ao entre uma LAN e uma rede p ublica ou corporativa; WAN-WAN: conex~ ao entre duas redes p ublicas ou corporativas operadas por diferentes entidades; LAN-WAN-LAN: conex~ ao entre duas LANs de uma mesma organiza ca ~o por interm edio de uma rede p ublica ou corporativa. A gura 4.3 ilustra estas possibilidades.
Dispositivos para Interconex~ ao de Redes Repetidores
De acordo com a heterogeneidade das redes sendo interligadas, os dispositivos de interconex~ ao variam em complexidade. Tais dispositivos se classi cam em: Repetidores regeneram o sinal entre segmentos de uma mesma rede. Por exemplo, uma rede Ethernet possui um limitante de 500m para o comprimento do cabo em banda larga. Entretanto, pode-se estender uma Ethernet at e 2500m utilizando-se 4 repetidores. Repetidores est~ ao relacionados unicamente com a camada f
sica do modelo OSI.
DCA-FEEC-UNICAMP
73
W A N
802.3 Ethernet
802.3 Ethernet 802.5 Token Ring
802.3 Ethernet
Figura 4.3: Exemplo de interconex~ ao de redes. Ret^ angulos com a letra R s~ ao repetidores; com a letra P pontes; e com a letra C comportas. Demais ret^ angulos s~ ao hosts.
Pontes Bridges
Pontes interconectam redes cujas diferen cas n~ ao passam da camada de enlace do modelo OSI. E o caso, por exemplo, das redes padr~ ao IEEE 802.3, 802.4 e 802.5, que possuem o mesmo protocolo de enlace 802.2-LLC mas formato de quadros, protocolo de acesso ao meio e camada f
sica diferenciados. Pontes convertem o enlace de dados, o protocolo de acesso ao meio e os padr~ oes da camada f
sica de uma rede para outra, atuando nas duas primeiras camadas do modelo OSI ou unicamente na camada interface de rede da arquitetura TCP IP.
Comportas Gateways
Comportas interconectam redes cujas diferen cas chegam at e a camada de rede protocolo de enlace, formato dos pacotes, etc. Por exemplo, a conex~ ao de uma rede local a uma rede p ublica se d a atrav es de uma comporta formato dos pacotes e quadros, protocolos de enlace e acesso ao meio, e padr~ oes da camada f
sica requerem convers~ ao. Comportas atuam nas tr^ es primeiras camadas do modelo OSI ou nas duas primeiras da arquitetura TCP IP.
Conversores de Protocolos
Conversores de protocolos interconectam redes cujas diferen cas ultrapassam a camada de rede. Por exemplo, uma rede local Ethernet com protocolo de transporte TCP IP se conecta a uma rede p ublica com protocolo de transporte OSI ISO 8073 atrav es de um conversor de protocolo.
4.4.1 Interconex~ ao de Redes e o Modelo OSI
Interconex~ ao de redes n~ ao teve a devida aten c~ ao por parte da ISO na elabora ca ~o do modelo OSI. No modelo OSI, interliga c~ ao de redes e propiciada pela divis~ ao da camada de rede em tr^ es subcamadas:
DCA-FEEC-UNICAMP
74
1. subcamada de acesso a subrede: trata do processamento dos protocolos das camadas de rede referentes a s subredes sendo interconectadas; 2. subcamada de aprimoramento: compatibiliza os diferentes servi cos oferecidos pelas subredes interconectadas; 3. subcamada inter-redes: processa os pacotes como se as redes interconectadas fossem homog^ eneas. A gura 4.4 mostra a interconex~ ao entre duas subredes utilizando a proposta do modelo OSI subdivis~ ao da camada de rede. Esta proposta nada mais e que estabelecer uma camada de rede padr~ ao na subcamada inter-redes OSI, obviamente, cabendo a subcamada de aprimoramento processar as devidas convers~ oes de e para esta camada padr~ ao. Como veremos, convers~ oes causam invariavelmente degrada c~ ao do desempenho e perda de funcionalidades.
COMPORTA
INTER-REDES
APRIMORAMENTO
APRIMORAMENTO
ACESSO SUBREDE
ACESSO SUBREDE
CAMADA DE ENLACE
CAMADA DE ENLACE
CAMADA FSICA
CAMADA FSICA
SUBREDE #1
SUBREDE #2
Figura 4.4: Proposta do modelo OSI para interconex~ ao de redes. Por exemplo, seja as subredes da gura 4.4 redes p ublica distintas. Quando um pacote enviado da subrede 1 se destinar a subrede 2, o roteamento obrigatoriamente passar a pela comporta. A subcamada de acesso a subrede processar a o pacote, fornecendo eventualmente um reconhecimento ao emissor no protocolo da subrede 1. O pacote e ent~ ao passado a subcamada de aprimoramento, que o converte num formato dado pelo padr~ ao da subcamada inter-redes. Na subcamada inter-redes, o pacote e processado como se o mesmo circulasse por uma subrede homog^ enea. Feito este processamento, o pacote e passado para a subcamada
DCA-FEEC-UNICAMP
75
de aprimoramento da subrede 2, onde ser a convertido para o formato requerido por esta subrede e encaminhado a subcamada de acesso a subrede. Esta, completa a transmiss~ ao do pacote, recebendo eventualmente o reconhecimento do destinat ario no protocolo da subrede 2. Dado que a camada de rede praticamente inexiste em redes locais, pontes s~ ao comumente empregadas para interconect a-las. Neste caso e imprescind
vel que as subredes interconectadas operem com o mesmo protocolo nas camadas de 4, 5, 6 e 7 caso contr ario, conversores de protocolos devem ser empregados. A gura 4.5 ilustra uma ponte interconectando duas subredes da fam
lia IEEE 802 802.3 e 802.5. Estas subredes utilizam o mesmo protocolo de enlace, mas formatos de quadros, disciplina de acesso ao meio e camada f
sica distintos. O mesmo conceito de interconex~ ao de redes proposto pelo modelo OSI e empregado, exceto que, neste caso, a convers~ ao se d a no n
vel quadros n~ ao de pacotes.
PONTE
4.4.2 Pontes
802.2 LLC
802.3 MAC (CSMA/CD)
802.5 MAC (TOKEN RING)
802.3 FSICA
802.5 FSICA
ETHERNET
TOKEN RING
Figura 4.5: Ponte interconectando subredes IEEE 802.3 e 802.5. A ponte converte o formato de pacote e o protocolo de enlace quando for o caso de uma rede para outra. A ponte disp~ oe de tantas camadas f
sicas e subcamadas de acesso ao meio quantas forem as subredes por ela conectadas. A subcamada de enlace l ogico e quem perfaz o elo de liga c~ ao entre as subredes. Via de regra, pontes s~ ao hosts n~ ao exclusivamente dedicados a esta tarefa. Infelizmente, muitos problemas decorrem da interliga c~ ao de subredes. Vamos exempli car alguns para o caso da interconex~ ao de subredes IEEE 802.3 CSMA-CD e 802.5 Token Ring.
DCA-FEEC-UNICAMP
76
Tamanho dos quadros
Quadros no padr~ ao 802.3 t^ em um comprimento m aximo da ordem de 1500 bytes enquando no padr~ ao 802.5 e limitado pela taxa de transmiss~ ao e pelo tempo m aximo de posse do token, tipicamente 5000 bytes. O que ocorre quando uma subrede 802.5 envia um quadro de, por exemplo, 3000 bytes para a subrede 802.3? Como o protocolo LLC imp~ oe a indivisibilidade do quadro, tal quadro simplesmente e descartado pela ponte.
Taxa de Transmiss~ ao
Suponha a subrede 802.3 operando a 10 Mbits seg e a subrede 802.5 operando a 4 Mbits seg. Se um host na 802.3 enviar uma rajada de quadros para outro na subrede 802.5, a ponte ir a receber quadros numa taxa mais alta que e capaz de escoar. Como consequ^ encia, pode ocorrer uma exaust~ ao de bu ers na ponte acarretando a perda de quadros. O padr~ ao 802.5 suporta prioriza ca ~o no envio de quadros e reserva do meio. A transmiss~ ao de um quadro de alt
ssima prioridade de uma rede 802.5 para outra 802.3 n~ ao garante sua pronta recep c~ ao. Ocorre que a ponte, ao receber e converter o quadro necessita executar o procedimento CSMA-CD para acessar o meio no lado 802.3. Este procedimento n~ ao suporta prioridade, sendo o tempo de acesso fun c~ ao do n
vel de tr afego na subrede.
Perda de Funcionalidades
Atraso na Comunica c~ ao
Pontes invariavelmente imp~ oem um atraso na comunica c~ ao entre dois hosts. A ponte adiciona ao tempo de comunica c~ ao normal dois procedimentos de acesso ao meio, um c^ omputo do checksum e a convers~ ao do pacote de um formato para outro desprezando-se o tempo extra na propaga c~ ao do sinal. Este atraso na comunica c~ ao pode causar a ocorr^ encia de timeouts no lado emissor gerando retransmiss~ oes desnecess arias que contribuem para mais atrasos !.
Perda de Con abilidade
Ao receber um pacote da subrede 802.5, a ponte computa o checksum, e, se livre de erros, o converte e retransmite para a subrede 802.3, enviando imediatamente um reconhecimento positivo ao emissor no lado 802.5. Este reconhecimento e mentiroso" pois nada garante que o receptor na subrede 802.3 recebeu o quadro livre de erros. Isto causa perda de con abilidade nos protocolos de transporte onde a garantia de entrega de pacotes e amarrada a garantia de entrega de quadros na camada de enlace como o protocolo UDP, por exemplo.
4.4.3 Comportas
Comportas conectam subredes no n

vel da camada 3 sendo mais empregadas na interconex~ ao de redes p ublicas. O emprego de uma u nica comporta na interconex~ ao de duas redes p ublicas gera con itos entre as operadoras, pois aquela que operar a comporta tem in u^ encia na
DCA-FEEC-UNICAMP
77
opera c~ ao da outra rede. A solu c~ ao e se empregar duas comportas, uma de cada lado, e interconect a-las por uma via de comunica ca ~o. Comportas podem ser orientadas a conex~ ao ou orientadas a datagrama, dependendo da natureza da camada 3 da rede. Se ambas as subredes interconectadas s~ ao baseadas em conex~ ao, as comportas tomam parte do circuito virtual conex~ ao, como mostrado na gura 4.6. Neste caso, diz-se que as comportas s~ ao orientadas a conex~ ao. Este tipo de comporta aloca os recursos requeridos pela conex~ ao, antes de estabelece-la, garantindo uma entrega con avel dos pacotes que uem de uma subrede para outra. Como desvantagem temos: se uma comporta falhar, a conex~ ao e os pacotes em tr^ ansito estar~ ao comprometidos; in exibilidade no roteamento, pois uma vez estabelecida uma conex~ ao, o uxo de pacotes associados a esta conex~ ao permanece xo. Comportas orientadas a conex~ ao se comunicam atrav es do protocolo CCITT X.75 quase id^ entico ao X.25.
Comportas Orientada a Conex~ ao
X.75 H I X.25 I C C I X.25 I H
Figura 4.6: Interliga c~ ao de duas subredes via comportas orientadas a conex~ ao C: comporta; H: host; I: IMP. A linha pontilhada indica uma conex~ ao.
Comportas Orientadas a Datagrama
Comportas orientadas a datagrama s~ ao empregadas quando uma ou ambas as subredes interconectadas n~ ao suportam circuitos virtuais no n
vel da camada de rede. Neste caso, os pacotes que comp~ oem uma dada mensagem podem uir por rotas diferentes gura 4.7. Esta propriedade facilita o roteamento, adaptando-o prontamente a s condi co ~es de tr afego na interliga c~ ao. Quando comportas orientadas a datagrama s~ ao empregadas, pacotes podem se perder por falta de bu er numa comporta, por exemplo, ou serem recebidos fora de ordem caso uam por diferentes comportas, por exemplo. Cabe a camada de transporte nos hosts comunicantes tratar estas situa c~ oes.
DCA-FEEC-UNICAMP
78
I H C fonte
I C C I I H
destino
C I I I H
Figura 4.7: Interliga ca ~o de duas subredes via comportas orientadas a datagrama. As linhas tracejadas indicam rotas de datagramas.
4.5 O Protocolo X.25 Camada 3

O protocolo X.25 para a camada de rede difere dos correspondentes X.25 para as camadas 1 e 2 no que tange ao estabelecimento das conex~ oes. No X.25 camada 1 a conex~ ao DTE-DCE e f
sica el etrica e estabelecida permanentemente. No X.25 camada 2, uma conex~ ao involve apenas dois computadores: o host DTE e o IMP a ele conectado via DCE. Aqui, o DTE deve iniciar a conex~ ao com o IMP utilizando uma via f
sica permanente ou tempor aria linha discada, por exemplo. Para o X.25 camada 3, a conex~ ao une dois DTEs e se estende por pelo menos 1 tipicamente v arios IMPs. Diferente dos anteriores, o estabelecimento de uma conex~ ao ir a envolver m ultiplas entidades DTEs e IMPs. O protocolo X.25 para a camada de rede de ne um endere camento para os hosts segundo a recomenda c~ ao X.121 da CCITT. Este endere camento e diferente dos NSAPs padr~ ao OSI, e composto de 14 d
gitos decimais. Os primeiros 3 d
gitos identi cam o pa
s exemplo: 302 a 307 para o Canad a, o quarto d
gito a rede p ublica naquele pa
s totalizando 6 10 = 60 para o Canad a, e os u ltimos 10 d
gitos o IMP da rede. O X.25 camada 3 utiliza um protocolo denominado PLP Packet Layer Protocol. Este protocolo de ne 3 tipos de pacotes: um tipo para a requisi c~ ao de conex~ oes, um tipo para controle, e um para dados. A gura 4.8 ilustra o formato de um pacote utilizado no estabelecimento de conex~ oes. Neste pacote, os campos GRUPO e CANAL ocupam 12 bytes e armazenam o identi cador do circuto virtual sendo estabelecido. A seguir vem os endere cos formato X.121 dos IMPs de origem e destino. O campo RECURSOS e utilizado para requerer alguns servi cos providos pela rede, por exemplo, tipo de circuito full-duplex, simplex, etc, tamanho da janela controle de uxo, velocidade de comunica c~ ao 1200 bps, 2400 bps, etc, taxa ca ~o no IMP destino chamada a cobrar, etc. Finalmente, o DTE que iniciou a conex~ ao pode dispor RIO. Este campo de, no m aximo, 16 bytes no campo DADOS-DO-USUA e interpretado pelo DTE sendo conectado e ignorado pela rede. Um pacote de controle gura 4.9 possui campos para identi car a conex~ ao GRUPO-
DCA-FEEC-UNICAMP
0 0

0 1 CANAL TIPO (00001011) TAMANHO DO ENDEREO FONTE CRTL 1 GRUPO
79
TAMANHO DO ENDEREO DESTINO
ENDEREO FONTE ENDEREO DESTINO
TAMANHO DO CAMPO RECURSO RECURSOS
DADOS DO USURIO
Figura 4.8: Pacote X.25 utilizado no estabelecimento de conex~ oes. CANAL e a c~ ao de controle sendo tomada. Um ou dois bytes de informa c~ ao adicional acompanha o cabe calho e indica tipicamente o porque da a ca ~o de controle por exemplo, a recusa do estabelecimento de uma conex~ ao. As a c~ oes de controle poss
veis s~ ao: CALL ACCEPT: indica o aceite de pedido de conex~ ao; CLEAR REQUEST: indica o t ermino de conex~ ao ou o n~ ao aceite; CLEAR CONFIRMATION: con rma o t ermino de conex~ ao; RECEIVER READY, RECEIVER NOT READY, REJECT: utilizados no controle do uxo do pacotes de dados; INTERRUPT: envio de, no m aximo, 32 bytes fora de sequ^ encia com alta prioridade; INTERRUPT CONFIRMATION: reconhece um INTERRUPT; RESET REQUEST: reinicia uma conex~ ao zerando o n umero de sequ^ encia dos pacotes de dados; RESET CONFIRMATION: reconhece um RESET REQUEST;
DCA-FEEC-UNICAMP
0 0

0 1 CANAL TIPO CRTL 1 GRUPO
80
INFORMAO ADICIONAL
Figura 4.9: Pacote X.25 de controle. oes que este DTE participa emitido RESTART REQUEST: reinicia todas as conex~ ap os a volta de um crash; RESTART CONFIRMATION: reconhece um RESTART REQUEST; DIAGNOSTIC: informa o DTE de problemas ocorridos na subrede de comunica ca ~o por exemplo, campo TIPO inv alido. Pacotes de dados apresentam o formato da gura 4.10.
Q D MDULO CANAL PIGGYBACK MAIS SEQUNCIA CRTL 0 GRUPO
DADOS
Figura 4.10: Pacote X.25 de dados. O bit Q indica dados quali cados e e utilizado pela camada de transporte para distinguir seus PDUs de dados dos de controle. O bit D estipula o signi cado do campo piggyback. Se D for igual a 1, piggyback indica um reconhecimento por parte do host DTE receptor. Caso contr ario Q igual a zero, o reconhecimento da entrega e oriundo do DCE local. O campo m odulo pode assumir o valor 01 para numera c~ ao em m odulo 8, ou 10 para numera c~ ao em m odulo 128.
DCA-FEEC-UNICAMP
81
Piggyback e um reconhecimento sem a utiliza c~ ao de pacotes de controle. Se o host receptor necessitar enviar um pacote da dados durante a recep c~ ao de uma sequ^ encia de pacotes, este, voluntariamente, informa o u ltimo pacote da sequ^ encia recebido sem erros permitindo o outro lado avan car a janela. Isto minimiza a necessidade de pacotes de reconhecimento quando a comunica ca ~o e intensa nos dois sentidos. O campo MAIS indica que mais pacotes pertencentes a este grupo est~ ao por vir. Somente ^ NCIA numera quando MAIS for zero, a mensagem e entregue ao receptor. O campo SEQUE os pacotes em m odulo 8 ou 128 conforme o campo Q.
4.6 Problemas
1. Quais os servi cos providos pela camada de rede ? 2. Quais as vantagens e desvantagens das camadas de rede orientadas a conex~ ao e sem conex~ ao ? 3. Descreva o algoritmo do caminho mais curto para roteamento de pacotes em redes de computadores. 4. Quais as t ecnicas mais empregadas para controle de congestinamento em subredes de comunica c~ ao ? 5. Quais os dispositivos existentes para a interconex~ ao de redes e em que situa co ~es s~ ao empregados ? 6. Cite algumas perdas de funcionalidades causadas pela interconex~ ao de redes 802.3 CSMA-CD e 802.4 TOKEN BUS. 7. Como o modelo OSI trata a interconex~ ao de redes ? 8. Como e estabelecida uma conex~ ao no n
vel da camada de rede no protocolo X.25 ? 9. Quais os pacotes de controle empregados no X.25 Camada 3 ? Fa ca um diagrama temporal mostrando os pacotes emitidos pelas duas entidades. 10. O que e piggybacking ?
Cap
tulo 5 A CAMADA DE TRANSPORTE
A camada de transporte e a primeira camada do modelo OSI a abstrair a topologia e a tecnologia da subrede de comunica c~ ao. Esta camada utiliza o servi co de entrega de pacotes da camada de rede para prover comunica c~ ao con a vel host a host. Se a camada de rede for baseada em datagrama, todo o trabalho para uma comunica c~ ao con avel ca a cargo da camada de transporte. Neste caso, a camada de transporte deve gerenciar a perda, duplica ca ~o e invers~ ao de ordem de pacotes ocorridas na subrede de comunica c~ ao. No caso da camada de rede prover entrega con avel de pacotes, a camada de transporte tem uma estrutura mais simpli cada, gerenciando principalmente o uxo de mensagens TPDUs entre os hosts comunicantes e as quebras de conex~ oes de rede N-RESETs.
5.1 Qualidade do Servi co

A camada de transporte de ne alguns par^ ametros associados a qualidade do transporte de dados. Estes par^ ametros s~ ao negociados no estabelecimento de conex~ oes de transporte entre os hosts e a subrede de comunica c~ ao. Os principais par^ ametros s~ ao: vaz~ ao bytes s: taxa m
nima assegurada de transmiss~ ao de mensagens pela conex~ ao de transporte; atraso de propaga c~ ao milisegundos: tempo m aximo de tr^ ansito de um TPDU entre as camadas de transporte dos hosts comunicantes; jitter milisegundos: varia ca ~o m axima do atraso de propaga c~ ao; tempo de estabelecimento da conex~ ao milisegundos: m aximo intervalo de tempo entre a entidade usu aria da camada de transporte solicitar uma conex~ ao e a sua con rma ca ~o; probabilidade de falha no estabelecimento da conex~ ao: probabilidade da conex~ ao n~ ao ser estabelecida no tempo estipulado devido a falta de bu ers nos hosts, congestionamento na subrede de comunica c~ ao, etc; taxa de erro residual: Taxa de mensagens perdidas ou corrompidas na conex~ ao de transporte teoricamente zero, mas assumindo um valor muito pequeno na pr atica; 82
DCA-FEEC-UNICAMP
83
tempo de encerramento de conex~ ao milisegundos: tempo m aximo para o t ermino de uma conex~ ao; probabilidade de falha no t ermino de conex~ ao: probabilidade do encerramento de uma conex~ ao n~ ao se completar no tempo de encerramento estipulado; prote ca ~o: estipula a privacidade dos dados uindo pela conex~ ao de transporte quanto a sua intercepta ca ~o por terceiros; prioridade: estipula a prioridade desta conex~ ao em rela c~ ao a s demais a prioridade da transmiss~ ao de TPDUs e fun c~ ao da prioridade das conex~ oes por onde os TPDUs uem; con abilidade: mede a probabilidade da camada de transporte falhar espontaneamente devido a bugs, situa c~ oes n~ ao previstas, etc. Um subconjunto destes par^ ametros e passado a camada de transporte no estabelecimento de uma conex~ ao. A conex~ ao n~ ao e estabelecida se a qualidade do servi co requisitada n~ ao puder ser honrada: 1. pela camada de transporte do host local; 2. pela camada de transporte do host remoto sendo conectado; 3. pela subrede de comunica c~ ao.
5.2 O Servi co de Transporte

O servi co de transporte pode ser orientado a conex~ ao ou a datagrama sem conex~ ao. Em redes locais, dada a alta con abiliade da camada de rede, o servi co sem conex~ ao e atrativo para muitas aplica co ~es, dado seu baixo overhead. Em redes p ublicas, mesmo com camada de rede orientada a conex~ ao como no caso do X.25 camada 3, o servi co de transporte orientado a conex~ ao e o mais seguro para a maioria das aplica c~ oes. O modelo OSI especi ca apenas quatro primitivas para transporte orientado a conex~ ao e uma para transporte orientado a datagrama tabela 5.1. Note a aus^ encia de primitiva do tipo RESET: uma conex~ ao de transporte e muito mais con a vel que uma conex~ ao de rede camada 3. As primitivas T-CONNECT, T-DISCONNECT e T-DATA estabelecem, terminam e transmitem TPDUs por uma conex~ ao. S~ ao equivalentes aquelas da camada de rede. A primitiva T-EXPEDITED-DATA transmite dados expressos: TPDUs com alta prioridade que s~ ao entregues a aplica c~ ao fora de sequ^ encia. S~ ao empregados para transmitir informa c~ oes urgentes como um caracter de controle BREAK, DELETE, etc teclado pelo usu ario numa sess~ ao de login remoto 1.
Imagine um programa em loop que supostamente deveria ler caracteres j a digitados pelo usu ario. O que aconteceria se o caracter BREAK, teclado pelo usu ario para abortar o programa, for entregue em sequ^ encia?
1
DCA-FEEC-UNICAMP
84
T-CONNECT.requestTSAP origem, TSAP destino, exp req, QoS, dados T-CONNECT.indicationTSAP origem, TSAP destino, exp req, QoS, dados T-CONNECT.responseQoS, TSAP destino, exp req, dados T-CONNECT.con rmQoS, TSAP destino, exp req, dados T-DISCONNECT.requestdados T-DISCONNECT.indicationjusti cativa, dados T-DATA.requestdados T-DATA.indicationdados T-EXPEDITED-DATA.requestdados T-EXPEDITED-DATA.indicationdados T-UNITDATA.requestTSAP origem, TSAP destino, QoS, dados T-UNITDATA.indicationTSAP origem, TSAP destino, QoS, dados Tabela 5.1: Servi cos ofereciados pela camada de transporte: as primitivas T-CONNECT, T-DISCONNECT e T-DATA s~ ao empregadas em servi cos com conex~ ao; T UNITDATA em servi cos sem conex~ ao. exp req e um ag que indica se dados expressos ser~ ao enviados pela conex~ ao ou n~ ao. QoS estabelece a qualidade de servi co proposta ou aceita. A primitiva T-UNIDATA transmite um TPDU sem o estabelecimento de conex~ ao e sem garantia de entrega, sequ^ encia ou aus^ encia de duplica c~ ao. A gura 5.1 mostra sequ^ encias t
picas de ocorr^ encia destas primitivas. A camada de transporte prov^ e servi cos nos TSAPs Transport Service Access Points. Na camada de rede um NSAP identi cava um host. Na camada de transporte, um TSAP identi ca um port de comunica c~ ao mantido por um processo em host conhecido. A entidade usu aria da camada de transporte normalmente indica o host e o port aos quais a mensagem se destina. A camada de transporte manipula o port, passando o host no formato adequado de NSAPs a camada de rede. Via de regra, um TSAP e uma estrutura muito mais simples que um NSAP: tipicamente um inteiro ocupando 2 bytes que identi ca o port. Um TSAP pode ser entendido como um identi cador de uma la para onde mensagens s~ ao enviadas ou de onde mensagens s~ ao recebidas. A forma como um processo solicita este recurso depende da interface de acesso aos servi cos de transporte provida pelo sistema operacional. O estado em que um TSAP pode se encontrar e o que causa as transi c~ oes de estado e apresentado no diagrama da gura 5.2.
5.3 Classes de Protocolos de Transporte

Os protocolos de transporte s~ ao classi cados em cinco categorias em fun c~ ao da camada de rede da qual se utilizam e de certas funcionalidades que prov^ eem. As subredes de comunica c~ ao se classi cam em tr^ es tipos:
Tipo A : Livres de erros e de N-RESETs. Apenas as LANs se aproximam desta classe.
DCA-FEEC-UNICAMP
entidade #1 entidade #2

entidade #1 T-CONNECT.request entidade #2
85
T-CONNECT.request T-CONNECT.indication
T-CONNECT.indication
T-CONNECT.confirm
T-CONNECT.response
T-DISCONNECT.request
T-DISCONNECT.indication T-DATA.request T-CONNECT.request (b)
T-DATA.indication T-EXPEDITED-DATA.request T-EXPEDITED-DATA.indication
T-CONNECT.indication T-DATA.indication T-DATA.request (c)
T-DISCONNECT.request T-DISCONNECT.indication
T-DISCONNECT.indication
T-DISCONNECT.indication
(d) (a) tempo
Figura 5.1: Algumas sequ^ encias de ocorr^ encia das primitivas OSI: a sequ^ encia normal de transfer^ encia de dados; b conex~ ao recusada pelo host remoto; c conex~ ao recusada pela camada de transporte; d t ermino de conex~ ao requisitado pela camada de transporte.
Tipo B : Transporte con a vel de pacotes, mas com a ocorr^ encia de N-RESETs quebras
de conex~ oes. Redes p ublicas X.25 pertencem a esta classe. Tipo C : Transporte de pacotes n~ ao con a vel. Redes com protocolo IP Internet Protocol como a Internet, por exemplo, pertencem a esta classe. As cinco categorias de protocolos de transporte s~ ao descritas a seguir. bilidade do transprte de dados recai sobre a subrede de comunica c~ ao. Classe 1 : Para subredes tipo B, prov^ eem recupera c~ ao b asica de erros principalmente NRESETs. No mais, deixam a cargo da subrede de comunica c~ ao a con abilidade do transporte de dados. Classe 2 : Para redes tipo A, s~ ao id^ enticos aos de Classe 0, permitindo apenas a multiplexa c~ ao de v arias conex~ oes de transporte numa u nica conex~ ao de rede. Classe 3 : Para redes tipo B, prov^ eem as funcionalidas das classes 1 e 2.
Classe 0 : Operam em subredes tipo A. S~ ao os protocolos mas simples pois toda a con a-
DCA-FEEC-UNICAMP

Espera 1
86
1 2 ou 3 2 4
2 ou 3
Requisio de Conexo Solicitada Entidade Remota 5 6
Requisio de Conexo Solicitada pela Entidade Remota
4 Conexo Estabelecida
7-10
Figura 5.2: Estados de um TSAP. Os eventos que causam transi c~ ao de estado s~ ao: 1 TCONNECT.request gerado pela camada usu aria; 2 T-DISCONNECT.indication recebido da camada de transporte; 3 T-DISCONNECT.request gerado pela camada usu aria; 4 T-CONNECT.indication recebido da camada de transporte; 5 T-CONNECT.con rm recebido da camada de transporte; 6 T-CONNECT.response gerado pela camada usu aria; 7 T-DATA.request gerado pela camada usu aria; 8 T-DATA.indication recebido da camada de transporte; 9 T-EXPEDITED-DATA.request gerado pela camada usu aria; 10 T-EXPEDITED-DATA.indication recebida da camada de transporte.
Classe 4 : Os u nicos a operarem em subredes tipo C, prov^ eem detec c~ ao e recupera c~ ao de

erros n~ ao tratados pela subrede de comunica c~ ao usualmente baseadas em datagrama. S~ ao os protocolos de transporte mais complexos.
5.4 Protocolos de Transporte Classe 4

Protocolos classe 4 operam em subredes tipo C que oferem servi cos de datagramas sem garantia de entrega, ordem ou aus^ encia de duplica c~ ao. Portanto, cabe ao servi co de transporte adicionar a con abilidade n~ ao oferecida pela camada de rede. Protocolos classe 4 s~ ao empregados tamb em em subredes classe B, onde a camada de transporte pode se valer de servi cos orientados a conex~ ao oferecidos pela camada de rede. Neste caso, as diferen cas entre um protocolo classe 3 e 4 s~ ao desprez
veis em termos de desempenho, j a que ambos ter~ ao que gerenciar apenas as quebras de conex~ ao no n
vel da camada de rede. Um protocolo de transporte classe 4 deve gerenciar a perda, duplica c~ ao e invers~ ao de ordem dos pacotes em tr^ es situa c~ oes: 1. durante o estabelecimento de conex~ oes de transporte; 2. durante a transfer^ encia de TPDUs de dados;
DCA-FEEC-UNICAMP
87
3. durante o fechamento de conex~ oes. Vamos examinar as solu c~ oes comumente empregadas nos protocolos classe 4 para estas tr^ es situa c~ oes. Dois cen arios devem ser gerenciados por um protocolo de transporte classe 4: duplica c~ ao de um TPDU que carrega uma requisi c~ ao de conex~ ao gerado pela chamada T-CONNECT.request; e perda de um TPDU que carrega a con rma c~ ao do estabelecimento da conex~ ao que iria gerar um T-CONNECT.con rm. No primeiro caso, ao receber um TPDU duplicado, o destinat ario ir a supor que uma segunda conex~ ao foi solicitada. No segundo cen ario, o host que solicitou a conex~ ao sup~ oe que sua requisi c~ ao se perdeu e a envia novamente. Uma segunda conex~ ao ser a estabelecida pelo receptor, como no caso anterior. Os dois cen arios descritos acima apresentam uma caracter
stica em comum: uma conex~ ao estabelecida apenas num host, e que portanto jamais ser a utilizada. Os recursos alocados a tais conex~ oes s~ ao totalmente in uteis e permanecem alocados at e esta situa c~ ao ser detectada e corrigida. Uma solu c~ ao comumente empregada e o estabelecimento de conex~ oes em tr^ es fases. Esta t ecnica evita conex~ oes in uteis geradas por duplica c~ ao ou perda de TPDUs. Ao enviar um pedido de conex~ ao, o host solicitante informa um n umero inicial de sequ^ encia na numera ca ~o dos TPDUs de dados que ele enviar pela conex~ ao: x primeira fase. Ao receber a solicita c~ ao, o destinat ario reconhece x e informa que seu n umero inicial de sequ^ encia ser a y segunda fase. Ao receber a con rma ca ~o da conex~ ao, o host que a iniciou reconhece y num TPDU de reconhecimento ou no primeiro TPDU de dados que enviar terceira fase. Este m etodo de estabelecimento de conex~ oes gura 5.3 e imune a duplica c~ ao ou perda de TPDUs empregados no estabelecimento de conex~ oes. No primeiro cen ario, o host que recebeu a segunda con rma c~ ao de conex~ ao, responder a com um REJECT na terceira fase, causando a desativa c~ ao imediata da conex~ ao gerada pelo TPDU duplicado. No segundo cen ario, a primeira conex~ ao ser a desativada por falta do recebimento de con rma c~ ao na terceira fase ap os timeout. Perdas, duplica co ~es e invers~ oes de ordem s~ ao tratadas de forma adequada por protocolos de controle de uxo com reconhecimento e piggybacking. Um problema adicional nos protocolos de transporte classe 4 reside na aloca c~ ao de bu ers. TPDUs transmitidos devem permanecer armazenados no emissor at e a chegada de reconhecimento por parte do receptor. O receptor necessita tamb em armazenar TPDUs at e que se complete uma janela no caso de reconhecimento cont
nuo ou uma mensagem composta de v arios TPDUs. Via de regra, os esquemas de bu eriza ca ~o empregam um pool de bu ers compartilhados por todas as conex~ oes ou um bu er de grandes dimens~ oes para cada conex~ ao. Neste ultimo caso, o bu er u nico abriga v arios TPDUs e sua manuten c~ ao lembra gerenciamento de mem oria em sistemas operacionais.
5.4.1 Estabelecimento de Conex~ oes
5.4.2 Transfer^ encia de TPDUs de Dados
DCA-FEEC-UNICAMP
CR (seq = X)

CR (seq = X) dupl. CR (seq = X) CR (seq = X) CR (seq = X) CC (seq = Y, ack = X)
88
CC (seq = Y, ack = X)
CC (seq = Y, ack = X) CC (seq = X, ack = Y)
CC (seq = X, ack = Y)
REJ (ack = Y) CC (seq = X, ack = Y)
CC (seq = X, ack = Y)
REJ (ack = Y)
(a) tempo
(b)
Figura 5.3: Estabelecimento de conex~ ao em 3 fases: a situa c~ ao normal; b duplica c~ ao de TPDU de requisi ca ~o. Tanto no emprego de um pool de bu ers quanto no emprego de um bu er u nico ca a quest~ ao: qual o tamanho dos bu ers? Esta quest~ ao e importante pois o tamanho dos TPDUs varia de poucos bytes como numa sess~ ao de login remoto, a milhares de bytes como em transfer^ encia de arquivos. No caso de pool de bu ers, pode-se empregar bu ers de tamanho variado. Isto causa um overhead adicional na procura de um bu er no pool de tamanho adequado ao TPDU que o bu er ir a abrigar. No caso de se empregar bu er u nico, pode-se negociar um tamanho inicial de bu er ao inv es do tamanho da janela no estabelecimento da conex~ ao. O host que est a recebendo TPDUs de dados informa nos TPDUs de reconhecimento quantos bytes existem dispon
veis no bu er. O host emitindo os TPDUs ajusta sua taxa de transmiss~ ao em fun c~ ao dos TPDUs que tem para transmitir e da quantidade de espa co que o receptor tem para armazen alos. Note que o tamanho do bu er u nico no receptor e no transmissor, caso esteja usando o mesmo esquema de bu eriza c~ ao pode permanecer constante, aumentar ou diminuir de tamanho, em fun c~ ao da mem oria dispon
vel a camada de transporte como um todo.
5.4.3 Encerramento de Conex~ oes
O encerramento de conex~ oes em protocolos de transporte classe 4 e tamb em um processo que requer cuidados. Dois cen arios devem ser considerados: 1. o TPDU solicitando o encerramento da conex~ ao se perdeu, gerando o fechamento da conex~ ao em apenas um lado; 2. um TPDU de dados chega ap os a conex~ ao pela qual uia ter sido encerrada.
DCA-FEEC-UNICAMP
89
Analogamente ao estabelecimento de conex~ oes, um esquema de tr^ es fases pode ser empregado para o encerramento de conex~ oes. Ao enviar uma requisi c~ ao de encerramento de conex~ ao, o emissor dispara um contador de tempo. Chegada a con rma c~ ao do encerramento, a "con rma c~ ao da con rma c~ ao" e enviada e o host encerra a conex~ ao. Expirado o tempo do contador sem a chegada de con rma c~ ao, o pedido de encerramento de conex~ ao e retransmitido. O processo se repete por determinado n umero de vezes quando a conex~ ao e encerrada unilateralmente pelo lado do emissor. O receber um TPDU solicitando o encerramento de conex~ ao, o receptor tamb em dispara um contador de tempo com intervalo bem superior ao do emissor, enviando prontamente a con rma c~ ao ao solicitante. Se este tempo se expirar sem o recebimento da "con rma ca ~o da con rma ca ~o", o host encerra unilateralmente a conex~ ao. A gura 5.4 ilustra este procedimento.
DR DR DR DR
DC DC DC remove conexo remove conexo ACK ACK ACK perda DC
remove conexo timeout remove conexo (b) (a) tempo
DR DR
DR DR
DC perda perda
DC
timeout DR DR timeout
timeout DR perda timeout DC
DC remove conexo ACK ACK timeout remove conexo
remove conexo
remove conexo
(c)
(d)
Figura 5.4: Encerramento de conex~ ao em 3 fases: a situa c~ ao Normal; b falha na terceira fase; c falha na segunda fase; d falhas na segunda e terceira fase.
DCA-FEEC-UNICAMP
90
Este procedimento garante tamb em que TPDUs "atrasados" n~ ao ser~ ao descartados. Simplesmente, um host n~ ao aceita o encerramento da conex~ ao emitindo um REJECT na terceira fase se um ou mais TPDU de dados ainda n~ ao teve seu recebimento con rmado. Encerramento de conex~ ao em tr^ es fases n~ ao garante que uma conex~ ao ser a encerrada em cem por cento dos casos por exemplo, quando nenhum dos TPDUs solicitando o encerramento da conex~ ao atingem o destino. Uma seguran ca adicional e encerrar uma conex~ ao caso permane ca inativa por um determinado per
odo de tempo. TPDUs de conte udo nulo podem ser empregados para manter a conex~ ao viva, fazendo com que sua recep c~ ao zere o contador de tempo que monitora e inatividade da conex~ ao.
5.5 Multiplexa c~ ao
Multiplexa c~ ao a n
vel de camada de transporte e a capacidade de: 1. operar m ultiplas conex~ oes de transporte atrav es de uma u nica conex~ ao de rede multiplexa c~ ao upward; ou 2. uma u nica conex~ ao de transporte utilizar m ultiplas conex~ oes de rede multiplexa ca ~o downward. O primeiro caso e comum em redes p ublicas onde a taxa c~ ao e fun c~ ao do n umero de conex~ oes requisitadas a subrede de comunica c~ ao. Obviamente a qualidade do servi co e pobre em conex~ oes de transporte multiplexadas numa mesma conex~ ao de rede. Protocolos de transporte classe 2 em diante s~ ao dotados de capacidade de multiplexa c~ ao upward. O segundo caso multiplexa c~ ao downward ocorre quando uma conex~ ao de transporte necessita determinada vaz~ ao n~ ao assegurada pela conex~ ao de rede. Neste caso, distribui-se os TPDUs por v arias conex~ oes de rede, aumentando a vaz~ ao da conex~ ao de transporte.
5.6 Protocolos de Transporte OSI Orientados a Conex~ ao

Os protocolos de transporte OSI e um padr~ ao ISO 8073 tipicamente em conjun c~ ao com o X.25. Este protocolo de ne 10 classes de TPDUs. Os formatos s~ ao os mesmos para as 5 classes de protocolos, exceto que certas classes n~ ao necessitam de todos os TPDUs. Os tr^ es primeiros campos dos TPDUs s~ ao comuns. O primeiro, LI Length Indicator, ocupa 1 byte e cont em o tamanho do cabe calho partes xa e vari avel. Segue o segundo campo, tamb em de 1 byte, contendo nos primeiros 4 bits o tipo de TPDU e nos 4 bits restantes o tamanho da janela Cdt: cr edito, quando for o caso. O terceiro campo ocupa 2 bytes e cont em um identi cador da conex~ ao. Uma conex~ ao e identi cada por dois inteiros denominados refer^ encia destino estabelecido por quem aceita a conex~ ao e refer^ encia fonte estabelecido por quem inicia a conex~ ao. Os demais campos dependem do tipo de TPDU. Os 10 tipos s~ ao descritos a seguir e apresentados na gura 5.5.
DCA-FEEC-UNICAMP
91
CR Connection Request: inicia uma conex~ ao de transporte. O campo CLASSE prop~ oe uma classe de protocolo para a conversa c~ ao geralmente a classe 4 e empregada. A parte vari avel consiste de: 1. os TSAPs de origem e destino; 2. o tamanho m aximo dos TPDUs de 128 a 8192, em pot^ encias de 2; 3. a vers~ ao do protocolo; 4. uma chave de prote c~ ao para ns de criptogra a, direito de acesso ao servi co, etc; 5. um indicador de uso de checksum; 6. par^ ametros de qualidade do servi co. Este TPDU pode carregar at e 32 bytes de dados do usu ario entregue a entidade que mant em o TSAP destino. CC Connection Con rm: Prov^ e con rma c~ ao positiva ou negativa de uma requisi ca ~o de conex~ ao. Possui formato id^ entico ao CC, carregando na parte vari avel a contraproposta referente aos par^ ametros de qualidade de servi co contidos na requisi ca ~o. DR Disconnect Request: solicita o encerramento da conex~ ao. O campo MOTIVO prov^ e um indicativo do motivo de tal requisi c~ ao. A parte vari avel, quando for o caso, carrega informa c~ oes complementares ao campo MOTIVO. DC Disconnect Con rm: con rma o t ermino da conex~ ao. A parte vari avel carrega apenas o checksum, se sua utiliza c~ ao foi decidida no estabelecimento da conex~ ao. DT Data: transporta dados. O campo EOT End of Text ocupa 1 bit e indica se este TPDU eou ltimo de uma mensagem ou n~ ao em sendo o u ltimo, a mensagem pode ser entregue a entidade receptora. Completando o byte, o campo TPDU-N, de 7 bits, prov^ e o n umero de sequ^ encia do TPDU em m odulo 7. ED Expedited Data: carrega dados expressos. A parte vari avel cont em o checksum, quando for o caso. AK Acknowledgement: reconhece TPDUs de dados DT ou ED. O campo Cdt pode alterar a janela previamente em uso para ns de controle de uxo. A parte vari avel cont em o checksum, quando for o caso. RJ Reject: utilizado nos protocolos de classe 1 e 3, solicita a transmiss~ ao de todos os TPDUs a partir e inclusive do n umero de sequ^ encia constante no campo TPDUESPERADO. ER Error Report: informa a ocorr^ encia de erros tais como par^ ametros desconhecidos, tipo de TPDU inv alido, etc. O campo MOTIVO informa o erro detectado. Caso necess ario, maiores informa co ~es s~ ao supridas na parte vari avel.
DCA-FEEC-UNICAMP
92
5.7 Protocolos de Transporte OSI sem Conex~ ao

O protocolo de transporte OSI sem conex~ ao de ne um u nico tipo de TPDU utilizado no transporte de dados gura 5.5. A parte vari avel do cabe calho cont em os TSAPs de origem e destino, e, opcionalmente, o checksum. Cada TPDU e transmitido num pacote separado, sem con rma c~ ao de recebimento. N~ ao h a garantia de entrega, ordem, ou aus^ encia de duplica c~ ao. Protocolos de transporte sem conex~ ao e utilizado principalmente em redes classes A locais.
Bytes 1 1 2 2 1
CR
LI
1110
Cdt
00 . . . . 0
TSAP origem
CLASSE
Parte Varivel
Dados
CC
LI
1101
Cdt
TSAP destino
TSAP origem
CLASSE
Parte Varivel
Dados
DR
LI
1000
0000
TSAP destino
TSAP origem
MOTIVO
Parte Varivel
Dados
DC
LI
1100
0000
TSAP destino
TSAP origem
Parte Varivel
DT
LI
1111
0000
TSAP destino
TPDU-N
Dados
EOT
ED
LI
0001
0000
TSAP destino
TPDU-N
Parte Varivel
Dados
AK
LI
0110
Cdt
TSAP destino
TPDUESPERADO
Parte Varivel
EA
LI
0010
0000
TSAP destino
TPDUESPERADO
Parte Varivel
RJ
LI
0101
Cdt
TSAP destino
TPDUESPERADO
ER
LI
0111
0000
TSAP destino
MOTIVO
Parte Varivel
(a)
LI
01000000
Parte Varivel
Dados
(b)
Figura 5.5: PDUs de transporte de nidos pela ISO: a transporte orientado a conex~ ao; b transporte orientado a datagrama.
DCA-FEEC-UNICAMP
93
5.8 Problemas
Quais as fun c~ oes prec
puas da camada de transporte ? O que e "qualidade de servi co" e sob que par^ ametros e determinada ? Qual a nalidade de se de nir classes de protocolos de transporte ? Descreva como conex~ oes s~ ao estabelecidas em protocolos de transporte classe 4. Como se d a o controle de uxo em protocolos de transporte classe 4 ? Quais as diferen cas no procedimento de tr^ es fases para se abrir e fechar conex~ oes ? De na multiplexa ca ~o upward e downward. Mapeie as primitivas OSI nos PDUs de transporte de nidos pela ISO. De na um algoritmo a ser utilizado num protocolo de transporte para tratar os NRESETs produzidos pela camada de rede. razo 10. E avel se empregar um protocolo de transporte sem conex~ ao em subredes de comunica ca ~o orientadas a conex~ ao X.25, por exemplo ? Justi que. 1. 2. 3. 4. 5. 6. 7. 8. 9.
Cap
tulo 6 ~O A CAMADA DE SESSA
A camada de sess~ ao tem por nalidade organizar a troca de informa c~ ao di alogo entre dois hosts comunicantes. Esta camada prov^ e mecanismos para: estabelecer e terminar sess~ oes de di alogo; trocar informa ca ~o numa sess~ ao de di alogo; gerenciar o di alogo; sincronizar o di alogo; de nir e gerenciar unidades de di alogo atividades; reportar erros detectados no decorrer do di alogo. Vamos examinar cada uma das funcionalidades acima.
6.1 Estabelecimento e T ermino do Di alogo

Dependendo do protocolo de transporte, uma conex~ ao de transporte pode se encerrar adruptamente por uma das partes, causando, eventualmente, perda de informa ca ~o. A gura 6.1a ilustra esta situa c~ ao onde uma conex~ ao foi terminada antes da outra parte encerrar o envio de dados. Isto de deve ao fato das primitivas OSI de transporte prever o encerramento da conex~ ao como um servi co sem con rma c~ ao primitivas do tipo request e indication apenas, ver gura 5.1. A camada de sess~ ao prov^ e encerramento de uma conex~ ao de sess~ ao como um servi co con rmado primitivas request, indication, response e con rm. Neste caso, uma aplica ca ~o envolvida numa sess~ ao de di alogo, ao receber uma indica c~ ao de desconex~ ao, emite a resposta a rmativa apenas caso n~ ao tenha mais informa c~ ao para transmitir. Isto garante que a conex~ ao se encerra sem a perda de informa c~ ao, mesmo que a conex~ ao de transporte da qual a conex~ ao de sess~ ao se utilizava se encerre adruptamente. A gura 6.1b ilustra o encerramento ordenado de uma sess~ ao de di alogo Uma conex~ ao de sess~ ao pode se encerrar adruptamente caso a pr opria camada de sess~ ao tome a iniciativa do encerramento. Um exemplo desta situa c~ ao e a quebra da conex~ ao de transporte da qual a conex~ ao de sess~ ao fazia uso. 94
DCA-FEEC-UNICAMP
entidade #1 T-DATA.request

entidade #2 entidade #1 S-DATA.request entidade #2 S-RELEASE.request
95
T_DISCONNECT.request
descarte T-DISCONNECT.indication S-RELEASE.indication S-RELEASE.response S-DATA.indication
tempo (a) (b)
S-RELEASE.confirm
Figura 6.1: Encerramento de conex~ oes: a de transporte; b de sess~ ao RELEASE tem o signi cado de DISCONNECT.
6.2 Troca de Informa c~ ao

Sess~ oes de di alogo podem conduzir quatro tipos de dados: 1. dados regulares: informa c~ ao que diz respeito apenas a s entidades comunicantes da aplica ca ~o; 2. dados expressos: informa ca ~o urgente gerada pela aplica c~ ao entregue fora de sequ^ encia; 3. dados tipados: informa c~ ao enviada sem que o transmissor detenha o token de envio veja pr oxima sess~ ao; 4. dados de capacidade: empregados exclusivamente para controle interno da camada de sess~ ao, permitem alterar par^ ametros do di alogo. As primitivas para envio dos tr^ es primeiros tipos de dados de sess~ ao s~ ao sem con rma ca ~o. O envio de dados de capacidade e um servi co con rmado, pois a altera c~ ao de par^ ametros do di alogo dependem do aceite da outra parte envolvida no di alogo.
6.3 Gerenciamento do Di alogo

Conex~ oes de transporte usualmente s~ ao do tipo full-duplex, onde a informa ca ~o ui nos dois sentidos simultaneamente. Entretanto, muitas sen~ ao a maioria aplica co ~es se comunicam em modo half-duplex, onde a informa c~ ao ui num sentido de cada vez. Comunica ca ~o halfduplex pode ser implementada em conex~ ao full-duplex pela introdu c~ ao de um token: apenas quem detiver o token est a habilitado a enviar informa ca ~o pela conex~ ao. No estabelecimento de uma conex~ ao de sess~ ao e especi cado o tipo da conex~ ao half- ou full-duplex. No caso de ser escolhida conex~ ao half-duplex, deve-se especi car tamb em a qual das partes ser a atribu
do o token primeiro. Terminado o envio de informa c~ ao, o detentor do token passa-o a outra parte. O token pode ser requisitado a qualquer momento pela entidade que n~ ao o det em. Recebida a requisi ca ~o, a entidade detentora do token pode, a seu crit erio, pass a-lo a quem o solicitou.
DCA-FEEC-UNICAMP
96
A gura 6.2 ilustra as o emprego do token e dados tipados em comunica c~ ao half-duplex.

entidade #1 entidade #2
tempo legenda: S-DATA S-EXPEDITED-DATA S-TOKEN-PLEASE S-TOKEN-GIVE
Figura 6.2: Comunica c~ ao t

pica no n
vel de sess~ ao.
6.4 Sincroniza c~ ao do Di alogo

Numa sess~ ao de di alogo pode-se de nir pontos de sincronismo. Pontos de sincronismo estabelecem marcas no di alogo para ns de retomada da comunica c~ ao a partir destas marcas. Pontos de sincronismo s~ ao de nidos pelas entidades comunicantes, n~ ao pela camada de sess~ ao esta os adiciona unicamente sob requisi c~ ao da aplica c~ ao. A introdu c~ ao de pontos de sincronismo necessita o reconhecimento da outra entidade comunicante, sendo portanto um servi co co rmado. Seja o exemplo de um a rede se servi cos integrados que oferece transmiss~ ao por fac-simile fax. Cada p agina do texto e transmitida como uma s erie de mensagens de dados. Antes do envio de cada p agina, o transmissor adiciona um ponto de sincronismo. Suponha que o receptor roteia os dados dos SPDUs diretamente para uma impressora, sem armazen alos localmente. Se ocorrer uma falha na impress~ ao por exemplo, travamento do papel, o receptor solicita ao transmissor que volte ao ponto de sincronismo referente a p agina afetada
DCA-FEEC-UNICAMP
97
pelo problema, passando a receber todas as mensagens a partir da

. O que ocorreu neste caso foi uma ressincroniza c~ ao do di alogo a partir de um ponto do passado. Caso pontos de sincronismo sejam empregados, o transmissor deve armazenar as mensagens caso o receptor ressincronize o di alogo. Obviamente, a quantidade de mensagens armazenadas deve ser limitada. Para tal, de ne-se dois tipos de pontos de sincronismo: menor como os do exemplo acima e maior. Pontos de sincronismo maior PSM de nem barreiras cujo retrocesso n~ ao pode ser ultrapassado, limitando, portanto, a quantidade de mensagens armazenadas para ns de ressincroniza c~ ao. Retomando o exemplo anterior, suponha que o transmissor adicione um PSM a cada cinco pontos de sincronismo menor que delimitam as p aginas. Agora, ao reconhecer um PSM, o receptor deve ter certeza que todas as p aginas transmitidas at e ent~ ao foram corretamente impressas, pois as mensagens transmitidas antes de um PSM s~ ao descartadas pelo transmissor. A quantidade de informa c~ ao transmitida entre dois PSMs e denominada unidade de di alogo ou atividade gura 6.3.
6.5 Gerenciamento de Atividades

Atividades s~ ao unidades delimitadas de uma sess~ ao de di alogo. Geralmente a delimita ca ~o das atividades est a relacionada com fronteiras naturais reconhecidas pelas entidades comunicantes. Por exemplo, numa sess~ ao de transfer^ encia de arquivos, a transmiss~ ao de cada arquivo estaria associada uma atividade gura 6.3.
SESSO
ATIVIDADE #1
ATIVIDADE #2
ATIVIDADE #3
tempo incio trmino interrupo retomada descarte
ponto de sincronismo maior
ponto de sincronismo menor
Figura 6.3: Parti c~ ao de uma sess~ ao de di alogo em atividades. Atividades numa mesma sess~ ao de di alogo est~ ao delimitadas por pontos de sincronismo maior. Como consequ^ encia, durante o processamento de uma atividade n~ ao podemos ressincronizar o di alogo a um ponto pertencente a atividade anterior. As opera c~ oes relacionadas com atividades s~ ao: in
cio: marca o in
cio de nova atividade inserindo um ponto de sincronismo maior exemplo: inicio da transmiss~ ao de arquivo;
DCA-FEEC-UNICAMP
98
t ermino: informa que a atividade corrente terminou de forma normal exemplo: m da transmiss~ ao de arquivo; descarte t ermino anormal: abandona a atividade corrente exemplo: descarte da parte j a transmitida do arquivo; interrup c~ ao: suspende temporariamente uma atividade exemplo: suspens~ ao de transmiss~ ao de arquivo; retomada: retoma uma atividade a partir do ponto em que foi interrompida exemplo: retoma a transmiss~ ao de arquivo. As consequ^ encias de se iniciar, terminar, descartar, suspender e retomar atividades dizem respeito apenas as aplica c~ oes usu arias da camada de sess~ ao. A camada de sess~ ao apenas prov^ e as primitivas para tal, gerando os respectivos SPDUs de controle que causam as respectivas indica c~ oes na camada de sess~ ao oposta. As primitivas para iniciar e retomar atividade interrompida s~ ao servi cos sem con rma c~ ao; as demais s~ ao servi cos con rmados. Finalmente, nada impede ao usu ario inserir pontos de sincronismo maior menor no interior de uma atividade.
6.6 Detec c~ ao de Erros

A camada de sess~ ao prov^ e apenas duas primitivas para o informe de situa c~ oes anormais. A primeira e utilizada pela aplica c~ ao. Por exemplo, uma aplica c~ ao remota solicita a local a transfer^ encia de um arquivo inexistente. Esta primeira primitiva de ne um servi co sem con rma c~ ao. A segunda primitiva e utilizada pela pr opria camada de sess~ ao quando esta detecta alguma situa c~ ao anormal. As aplica c~ oes conectadas numa sess~ ao de di alogo recebem apenas uma indica c~ ao do erro, podendo proceder como desejarem. Exemplo de erro neste n
vel ea perda do sequenciamento na transmiss~ ao dos SPDUs que comp~ oem uma mensagem.
6.7 Primitivas OSI de Sess~ ao

A tabela 6.1 apresenta as primitivas OSI para a camada de sess~ ao. As primitivas fornecem os servi cos orientados a conex~ ao descritos nas se c~ oes precedentes. Primitivas iniciando com S-P possuem o modo indication apenas e se prestam para o informe de eventos detectados pela entidade provedora do servi co neste caso, os protocolos da camada de sess~ ao. Uma u nica primitiva, S-UNITDATA, prov^ e transmiss~ ao de informa c~ ao sem o estabelecimento de conex~ ao.
6.8 Protocolo OSI de Sess~ ao

O protocolo OSI de sess~ ao ISO 8327 e inspirado num protocolo antigo da CCITT para teletexto. A forma geral dos SPDUs e dada na gura 6.4a. A campo SI Session Identi er
DCA-FEEC-UNICAMP
99
primitiva S-CONNECT S-RELEASE
Estabelecimento de uma conex~ ao de sess~ ao T ermino de uma conex~ ao de sess~ ao S-U-ABORT Termina adruptamente uma conex~ ao S-P-ABORT Informa o t ermino adrupto de uma conex~ ao S-DATA Transfere de dados S-EXPEDITED-DATA Transfere de dados expressos S-TYPED-DATA Transfere de dados fora de faixa out-of-band S-CAPABILITY-DATA Transfere de informa c~ ao de controle S-TOKEN-GIVE Passa o token a outra entidade S-TOKEN-PLEASE Solicita o token de outra entidade S-CONTROL-GIVE Passa todos os tokens a outra entidade S-SYNC-MAJOR Insere um ponto de sincroniza c~ ao maior S-SYNC-MINOR Insere um ponto de sincroniza c~ ao menor S-RESYNCHRONIZE Retorna a um ponto de sincroniza c~ ao S-ATIVITY-START Inicia uma atividade S-ACTIVITY-END Termina uma atividade S-ACTIVITY-DISCARD Descarta uma atividade S-ACTIVITY-INTERRUPT Interrompe uma atividade em curso S-ATIVITY-RESUME Retoma uma atividade interrompida S-U-EXCEPTION-REPORT O usu ario informa sobre uma exce ca ~o S-P-EXCEPTION-REPORT A entidade provedora informa sobre uma exce ca ~o S-UNITDATA Transfere dados sem o estabelecimento de conex~ ao Tabela 6.1: Primitivas OSI para a camada de sess~ ao. As primitivas em negrito s~ ao servi cos con rmados. de um byte cont em o tipo do SPDU. O campo LI Length Identi er, tamb em de um byte, indica o tamanho em bytes do campo de par^ ametros. LI varia entre 0 e 254: um valor de 255 indica a exist^ encia de 2 bytes adicionais para este campo. Ap os os campos SI e LI, v^ em os parametros do SPDU. Par^ ametros t^ em o formato da gura 6.4b. PI Parameter Identi er informa o tipo do par^ ametro; LI seu tamanho; PV Parameter Value seu valor. Certos SPDUs prov^ eem campo de dados do usu ario para que os usu arios da camada de sess~ ao enviem informa c~ ao adicional aquelas passadas nas primitivas a camada de sess~ ao n~ ao interpreta estes dados. Grosso modo, a chamada de cada primitiva de sess~ ao gera um SPDU do tipo da primitiva. Primitivas que implementam servi cos con rmados de nem tamb em seus correspondentes SPDUs de reconhecimento.
nalidade
DCA-FEEC-UNICAMP
1 byte SI 1byte LI

PARMETROS ....
100
DADOS
PI
LI
PV
Figura 6.4: Formato geral de um SPDU para compatibilidade com o protocolo CCITT para teletexto.
6.9 Problemas
Quais as funcionalidades que a camada de sess~ ao prov^ e? Quais as diferen cas entre uma conex~ ao de transporte e uma conex~ ao de sess~ ao ? Como a camada de sess~ ao implementa comunica c~ ao half-duplex ? Como a camada de sess~ ao classi ca os dados por ela transmitidos ? Como funciona o mecanismo de sincroniza c~ ao da camada de sess~ ao ? Quais as vantangens de se organizar o di alogo em atividades ? Quais as opera c~ oes de gerenciamento de atividades ? Fa ca um diagrama temporal mostrando uma ressincroniza c~ ao do di alogo. Idem para o in
cio, suspens~ ao, retomada e t ermino de uma atividade. 9. Cite as primitivas OSI de sess~ ao. 10. Descreva os campos de um SPDU do protocolo OSI de sess~ ao. 1. 2. 3. 4. 5. 6. 7. 8.
Cap
tulo 7 ~O A CAMADA DE APRESENTAC A
A camada de apresenta c~ ao e empregada para alterar a representa c~ ao de dados transmitidos via rede para ns de: 1. compatibilizar a comunica c~ ao; 2. seguran ca e privacidade; 3. compacta c~ ao de dados. O primeiro item diz respeito a representa c~ ao can^ onica de dados: uma representa c~ ao intelig
vel por todos os hosts comunicantes independentemente de suas arquiteturas de m aquina. Os dois u ltimos itens se relacionam com criptogra a e compress~ ao de dados. A camada de apresenta c~ ao e o local para se implementar tais fun c~ oes. Criptogra a e compress~ ao de dados s~ ao t opicos extensos e dependentes do contexto no qual a aplica c~ ao est a inserida. Estes t opicos n~ ao ser~ ao cobertos neste texto.
7.1 Representa c~ ao Can^ onica de Dados

At e ent~ ao nos referimos a dados sem nos preocupar com sua representa ca ~o. Infelizmente, representar dados n~ ao e tarefa trivial, posto que diferentes computadores adotam representa c~ oes diferentes para o mesmo dado. Por exemplo, a IBM de longa data emprega o c odigo EBCDIC em seus mainframes para representar texto. Os demais fabricantes empregam o c odico ASCII. Outro problema e a sequ^ encia de bits numa palavra: alguns computadores empregam o bit mais signi cativo a esquerda, enquanto outros a direita. Por exemplo, o n umero 11 e representado como 0...01011 numa SUN e 11010...0 num VAX. Como regra geral, a forma de representa c~ ao interna de dados adotada por computadores e fortemente in uenciada por suas arquiteturas de hardware. Com o advento das redes heterog^ eneas interconectando hardware de diferentes arquiteturas, tornou-se necess ario uma representa c~ ao can^ onica de dados ou sintaxe de tranfer^ encia. A id eia e simples. Antes de transmitir um dado, o host converte de sua representa c~ ao interna para a representa ca ~o can^ onica. Ao receb^ e-lo, o host receptor converte da representa ca ~o can^ onica para sua representa ca ~o interna. Em outras palavras, os dados que uem pela rede 101
DCA-FEEC-UNICAMP
102
t^ em uma representa ca ~o padronizada. Isto evita que hosts comunicantes necessitem conhecer mutuamente a forma de representa c~ ao de dados por eles empregadas 1. No modelo OSI, a representa c~ ao can^ onica de dados baseia-se numa sintaxe denominada ASN.1 Abstract Syntax Notation, version 1.
7.2 A Sintaxe ASN.1

ASN.1 e uma linguagem formal de especi ca c~ ao de tipos de dados padronizada pela ISO documento 8824. Uma segunda padroniza c~ ao, BER Basic Encoding Rules, especi ca como dados na sintaxe ASN.1 s~ ao formatados numa mensagem por exemplo, um TPDU. BER e tamb em um padr~ ao ISO documento 8825. Aplica c~ oes de nem todas as estruturas de mensagens v alidas tipos de PDUs em ASN.1, agrupando estas de ni c~ oes num u nico m odulo: o dicion ario de dados. Ao transmitir um PDU, a aplica ca ~o passa a camada de apresenta c~ ao o tipo de PDU sendo transmitido e o conte udo do seus campos. A camada de apresenta c~ ao consulta o dicion ario de dados em busca da de ni ca ~o dos campos do PDU e, utilizando a norma BER, gera a mensagem a ser transmitida. A gura 7.1 ilustra este processo.
<TIPO, VALORES> <TIPO, VALORES>
APLICAO APRESENTAO
PSAP PSAP
tipo? DICIONRIO DE TIPOS
tipo?
BER
ASN.1 TIPO CODIFICADO
BER
ASN.1 TIPO CODIFICADO SSAP SSAP
DICIONRIO DE TIPOS
SESSO
Figura 7.1: O servi co OSI de apresenta c~ ao. Quando a mensagem atingir a camada de apresenta c~ ao do receptor, e veri cado o tipo de PDU. O dicion ario de dados e ent~ ao consultado para se obter a estrutura do PDU recebido. Com base sua na estrutura e, sabendo-se que a codi ca c~ ao segue ASN.1 BER, o receptor pode remontar o PDU segundo sua representa c~ ao pr opria de dados. Como toda a linguagem formal, ASN.1 consiste num conjunto de elementos b asicos tokens e regras de combina c~ ao destes elementos. ASN.1 de ne quatro tipos de tokens:
Esta solu c~ ao e invi avel por tr^ es raz~ oes: a quantidade de arquiteturas e portanto representa c~ oes distintas; o aparecimento cont
nuo de novas arquiteturas; e a impossibilidade de difus~ ao de mensagens num formato intelig
vel por todos os hosts.
1
DCA-FEEC-UNICAMP
103
ractere deve ser uma letra. Palavras de nem tipos de dados, identi cadores e palavraschave. n umeros: forma co ~es compostas apenas de d
gitos. strings: cadeia de caracteres to tipo alfanum erico: qualquer conte udo delimitado por " " hexadecimal: conte udo entre 0-9 e A-F delimitado por ' 'H bin ario: 0 ou 1 delimitados por ' 'B pontua c~ ao: caracteres do tipo
. : = , - ' " |
palavras: sequ^ encias de letras mai usculas ou min usculas, d

gitos e h
fem. O primeiro ca-
ASN.1 de ne um conjunto de tipos primitivos de dados. Tipos mais complexos s~ ao obtidos atrav es da agrega c~ ao dos tipos primitivos. Os tipos primitivos s~ ao: boolean: valores l ogicos TRUE-FALSE; integer: n umeros inteiros; real: n umeros reais mantissa, base, expoente; bit String: sequ^ encia ordenada de 0s e 1s; octet string: sequ^ encia ordenada de bytes octetos; any: tipo a ser especi cado; null: tipo sem valor; object descriptor: referencia algum objeto sem sintaxe formal usado mais a t
tulo de coment ario; object identi er: de ne univocamente um objeto, por exemplo, um protocolo de transfer^ encia de arquivos; encripted: tipo encriptado. Exemplos:
7.2.1 Tipos Primitivos de Dados
DCA-FEEC-UNICAMP
ChecksumInUse ::= BOOLEAN ChecksumInUse ::= FALSE TimeToLive ::= INTEGER TimeToLive ::= 60 Timeout ::= REAL Timeout ::= 250, 10, -3 Preamble ::= BITSTRING Preamble ::= '01010101'B ForFutureUse ::= ANY NoLongerInUse ::= NULL
104
Ftam ::= OBJECT DESCRIPTOR Ftam ::= "File Transfer, Access and Management" Ftam ::= OBJECT IDENTFIER Ftam ::= iso standard 8571
7.2.2 Tipos Complexos Construtores
Tipos constutores s~ ao formados a partir dos tipos primitivos descritos na se c~ ao anterior. S~ ao eles:
sequence: lista ordenada de tipos primitivos arbitr arios; sequence of: lista ordenada de tipos primitivos homog^ eneos; set: lista n~ ao ordenada de tipos primitivos arbitr arios; set of: lista n~ ao ordenada de tipos primitivos homog^ eneos; choice: um conjunto de tipos dos quais apenas um deve ser considerado.
Exemplos:
PDUHeader ::= SEQUENCE Length INTEGER, Flags BITSTRING, DestinationTSAP INTEGER, SourceTSAP INTEGER
DCA-FEEC-UNICAMP
ProtocolClassOption ::= CHOICE

class-0 class-1 class-2 class-3 class-4 OCTETSTRING, OCTETSTRING, OCTETSTRING, OCTETSTRING, OCTETSTRING
105
Tipos marcados carregam uma informa c~ ao adicional para ns de elimina c~ ao de ambiguidades. Vimos pelos exemplos acima que tipos construtores s~ ao estruturas compostas de m ultiplos campos. Durante a transmiss~ ao de um tipo construtor, o tipo tamanho e valor de cada um de seus campos e codi cado segundo a norma BER. Um problema decorre da exist^ encia de campos opcionais. A palavra-chave OPTIONAL pode ser usada para identi car um campo como opcional. Outra palavra-chave, DEFAULT, estabelece o valor que deve ser tomado caso o campo opcional seja omitido. Por exemplo:
PDUHeader ::= SEQUENCE Length INTEGER, Flags BITSTRING OPTIONAL DEFAULT '00000000'B, DestinationTSAP INTEGER, SourceTSAP INTEGER
7.2.3 Tipos Marcados Tagged
Ao receber um PDU com o cabe calho dado pela sequ^ encia acima, como o receptor reconhece se o campo opcional foi transmitido ? A solu c~ ao e marcar explicitamente os componentes da sequ^ encia e transmitir a marca junto com o dado. Exemplo:
PDUHeader ::= SEQUENCE Length 0 INTEGER, Flags 1 BITSTRING OPTIONAL DEFAULT '00000000'B, DestinationTSAP 2 INTEGER, SourceTSAP 3 INTEGER
Assim sendo, se o campo Flags for omitido, o receptor toma conhecimento pela aus^ encia da marca 1 . Com a transmiss~ ao da marca, o tipo ca redundante pois pode ser acessado pelo receptor na de ni ca ~o do tipo construtor. Esta redund^ ancia pode ser mantida como uma veri ca c~ ao adicional. Para elimin a-la deve-se utilizar a palavra-chave IMPLICIT:
DCA-FEEC-UNICAMP
106
PDUHeader ::= SEQUENCE Length 0 IMPLICIT INTEGER, Flags 1 IMPLICIT BITSTRING OPTIONAL DEFAULT '00000000'B, DestinationTSAP 2 IMPLICIT INTEGER, SourceTSAP 3 IMPLICIT INTEGER
Suponha agora que o protocolo possui v arios tipos de PDUs por exemplo, 9 para o TP4. Ao receber um PDU, como o receptor descobre de que tipo se trata ? Se o cabe calho do exemplo anterior for, digamos, do terceiro tipo, podemos marcar n~ ao apenas seus campos, mas tamb em sua estrutura como um todo:
PDUHeader ::= APPLICATION 3 SEQUENCE Length 0 IMPLICIT INTEGER, Flags 1 IMPLICIT BITSTRING OPTIONAL DEFAULT '00000000'B, DestinationTSAP 2 IMPLICIT INTEGER, SourceTSAP 3 IMPLICIT INTEGER
A palavra-chave APPLICATION denota um tipo construtor no dicion ario de dados da aplica c~ ao OSI. A marca, 3, indica se tratar da terceira de ni ca ~o presente no dicion ario. APPLICATION pode ser substitu
da por PRIVATE aplica ca ~o privada, CONTEXT-SPECIFIC interpreta c~ ao dependente do conexto e UNIVERSAL tipos primitivos do ASN.1.
7.3 Sintaxe de Transfer^ encia

Sintaxe de transfer^ encia especi ca como um tipo ASN.1 e formatado numa mensagem. A norma BER fornece regras para esta formata ca ~o. Dada a sua extens~ ao, veremos apenas os aspectos fundamentais do BER. BER adota inteiramente o c odigo ASCII para caracteres. As representa co ~es adotam o bit mais signi cativo a esquerda. N umeros s~ ao representados pelos seus complementos de dois. Tipos primitivos ou n~ ao s~ ao formatados em tr^ es campos: a identi ca c~ ao do tipo, o tamanho do dado, e o valor propriamente dito. Caso o tipo n~ ao seja primitivo, o valor ir a conter tamb em outros tr^ es campos tipo, tamanho, valor, e assim sucessivamente at e chegarmos unicamente a tipos primitivos.
7.3.1 Identi ca c~ ao do Tipo, Tamanho e Valor
O tipo e identi cado por um byte. Os primeiros dois bits informam a classe do tipo UNIVERSAL, APPLICATION, CONTEXT-SPECIFIC e PRIVATE. O pr oximo bit denota se
DCA-FEEC-UNICAMP
107
o tipo e primitivo ou n~ ao. Os cinco bits restantes identi cam o tipo na classe. Para a classe UNIVERSAL, 1 denota BOOLEAN, 2 denota INTEGER, 3 denota BITSTRING, 4 denota OCTETSTRING, e assim por diante. Caso uma classe tenha mais que 30 tipos, ativa-se todos os 5 bits do tipo seguindo-se tantos bytes quantos forem necess arios para abrigar o
ndice m aximo, todos come cando com 1 no primeiro bit restando sete para o tipo, exceto o u ltimo. O tamanho do dado, se menor que 128 ocupa um u nico byte, tendo o primeiro bit com valor 0. Se maior que 128, o primeiro bit e feito 1 e os sete restantes estipulam quantos bytes a seguir armazenam o valor. Um tamanho de conte udo nulo todos os bits 0 indica que o valor ser a delimitado por dois bytes de conte udo nulo em cada extremo. A codi ca c~ ao de valores varia com o tipo. Por exemplo, um OCTETSTRING de N bytes e codi cado empregando-se um byte por caractere, segundo o c odigo ASCII. Exemplos:
numero 100: numero 32768: string "A": 00000010 00000001 01100100 00000010 00000010 01000000 00000000 00000100 00000001 01100001
Como exemplo de tipos construtores, tomemos o caso de uma SEQUENCE. Neste caso, o byte que descreve o tipo indica se tratar de uma sequ^ encia, o byte tamanho indica o n umero de elementos da sequ^ encia N e o byte valor d a lugar a N triplas tipo, tamanho, valor. Por exemplo, uma sequ^ encia composta do n umero 100 e do string "A" e codi cada como:
Exemplo ::= UNIVERSAL 7 SEQUENCE elem-1 1 IMPLICIT INTEGER, elem-2 2 IMPLICIT OCTETSTRING
Para valores 100, "A" , a sequ^ encia acima e codi cada como:
00001000 00000010 00000010 00000001 01100100 00000100 00000001 01100001
7.4 Primitivas OSI de Apresenta c~ ao

As primitivas OSI para a camada de apresenta c~ ao s~ ao as mesmas, exceto uma, da camada 2 de sess~ ao ver gura 6.1. Simplesmente tais primitivas curto-circuitam" a camada de
2
Come cando com P- ao inv es de S-
DCA-FEEC-UNICAMP
108
apresenta c~ ao, permitindo a camada de aplica c~ ao o acesso a s fun c~ oes da camada de sess~ ao. Tais primitivas existem para manter o conceito de camadas. Uma nova primitiva S-ALTER-CONTEXT prov^ e um mecanismo de mudan ca de contexto, isto e, passar de uma atividade de sess~ ao para outra sem suuspender a primeira. Esta primitiva e um servi co com con rma c~ ao.
7.5 Problemas
1. Quais as fun co ~es da camada de apresenta c~ ao ? 2. Especi que os NPDUs do X.25 camada 3 em ASN.1.
Cap
tulo 8 ~O A CAMADA DE APLICAC A
8.1 Funcionalidades da Camada de Aplica c~ ao
A camada de aplica c~ ao do modelo OSI de ne protocolos e entidades que os implementam utilizados por aplicativos denominados APs Application Processes ou Processos de Aplica c~ ao. Por exemplo, um AP que implementa um servi co de mensagens via caixa postal, por exemplo quando operando num ambiente OSI utilizaria o protocolo MHS Message Handling System de nido na camada de aplica ca ~o. A camada de aplica c~ ao tem por nalidade prover os seguintes servi cos aos APs que dela se utilizam: identi car elementos remotos de aplica c~ ao, veri cando sua disponibilidades servidores, por exemplo; negociar com estes elementos uma qualidade de servi co apropriada; negociar contextos de apresenta c~ ao para troca de informa c~ ao; negociar servi cos de sess~ ao; transportar dados entre aplicativos; autenticar as entidades comunicantes. Alguns exemplos de servi cos providos pela camada de aplica c~ ao s~ ao listados abaixo: servi co de acesso e transfer^ encia de arquivos; servi co de troca de mensagens; servi co de diret orio; servi co de manipula c~ ao de tarefas jobs remotas; servi co de controle de concorr^ encia e recupera c~ ao; 109
DCA-FEEC-UNICAMP servi co de terminal remoto; etc.
110
Para o provimento destes servi cos a camada de aplica c~ ao possui uma estrutura ca ~o relativamente complexa quando comparada as demais camadas do modelo OSI. Esta estrutura c~ ao e sintetizada na sequ^ encia.
8.2 Estrutura c~ ao da Camada de Aplica c~ ao

A camada de aplica ca ~o agrega entidades de aplica c~ ao respons aveis pelo provimento de servi cos aos APs. Estes servi cos podem ser de prop osito geral ou espec
co. Os servi cos de prop osito geral s~ ao providos por entidades denominadas CASE Common Application Service Elements, enquanto os de prop osito espec
cos s~ ao providos pelas entidades SASE Speci c Application Service Elements. Em linhas gerais, APs usam servi cos oferecidos por SASEs que por sua vez usam servi cos oferecidos pelos CASEs conforme ilustrado na gura 8.1.
USURIO
PROCESSO DE APLICAO (AP) USER ELEMENT (UE)
...
PROCESSO DE APLICAO (AP) USER ELEMENT (UE) AMBIENTE "REAL" AMBIENTE OSI
SPECIFIC APPLICATION SERVICE ELEMENTS (SASEs) ...
FTAM
MHS
DS CAMADA DE APLICAO
COMMON APPLICATION SERVICE ELEMENTS (CASEs) ...
ACSE
ROSE
CCR
PSAP
PSAP
PSAP CAMADA DE APRESENTAO
Figura 8.1: Os componentes da camada de aplica ca ~o do modelo OSI.
DCA-FEEC-UNICAMP
111
Um conceito importante na camada de aplica c~ ao e o conceito de associa c~ ao. As demais camadas do modelo OSI oferecem a abstra c~ ao de conex~ ao primitivas tipo CONNECT como o meio intera ca ~o entre duas entidades da camada N+1 via servi cos oferecidos pela camada N. O que ocorre se N = 7, ou, em outas palavras, quem utilizaria as conex~ oes da camada de aplica c~ ao ? Este problema foi resolvido atrav es das regras abaixo: 1. a camada de aplica c~ ao de ne associa c~ ao n~ ao conex~ ao como forma de provimento de servi cos aos APs; 2. cada associa ca ~o de aplica c~ ao utiliza uma u nica conex~ ao de apresenta c~ ao isto e, uma associa c~ ao pode ser vista como uma extens~ ao de uma conex~ ao de apresenta c~ ao. Um CASE denominado ACSE Association Control Service Element oferece o servi co de estabelecimento de associa c~ ao para as demais entidades da camada de aplica c~ ao. Atualmente, a tend^ encia e evitar a distin c~ ao entre CASE e SASE e denominar estas entidades simplesmente de ASE Application Service Element. Uma quent~ ao crucial e: como combinar ASEs para implementar um servi co complexo ? Esta quest~ ao est a vinculada com o conceito de associa c~ ao. Intuitivamente, um ASE proveria uma associa ca ~o atrav es de uma conex~ ao de apresenta ca ~o agregando valor a conex~ ao oferecida pela camada inferior1. Este modelo apresenta alguns problemas quando ASEs s~ ao combinados. O principal problema refere-se a complexidade da coordena c~ ao de m ultiplas associa c~ oes cada qual utilizando uma u nica conex~ ao de apresenta c~ ao. O que ocorre, por exemplo, se uma das associa c~ oes e encerrada pelo provedor ?; ou, como gerenciar o di alogo a n
vel de aplica c~ ao se diferentes associa c~ oes utilizam diferentes servi cos de sess~ ao2 ? A proposta da ISO para esta quest~ ao e a de ni c~ ao de um componente agregador denominado ASO Application Service Object. Um ASO e um objeto provedor de servi co que agrega: Elementos de Servi co de Aplica c~ ao ASE; Outros ASOs; Uma u nica Fun c~ ao de Controle CF: Control Function que especi ca como os componentes de um ASO s~ ao agregados. Um ASO estabelece uma u nica associa c~ ao eliminando, portanto, o problema de gerenciamento de m ultiplas associa c~ oes uma por ASE. Obviamente, caso um ASO agregue outros ASOs m ultimas associa c~ oes emanar~ ao deste, mas as demais associa c~ oes s~ ao encapsuladas pelos ASOs agregados. Entidades de aplica c~ ao agora s~ ao de nidas em termos de ASOs, n~ ao mais em termos de ASEs. Em linhas gerais, neste modelo os ASEs de nem mensagems APDUs, enquanto os ASOs via CF determinam a din^ amica da intera c~ ao atrav es destas mensagens.
1 2
As demais camadas operam segundo este princ

pio. Por exemplo, uma utiliza tokens para gerenciar o di alogo e a outra n~ ao.
DCA-FEEC-UNICAMP
112
A gura 8.2 ilustra esta nova concep c~ ao da camada de aplica c~ ao. Infelizmente, esta concep c~ ao foi elaborada ap os muitos ASEs j a terem sido padronizados. Esta padroniza c~ ao n~ ao levou em conta a possibilidade destes ASEs serem agregados em torno de um ASO. A reformula c~ ao destes padr~ oes para adequarem os ASEs a nova estrutura c~ ao da camada de aplica c~ ao e um processo incerto.
USURIO
PROCESSO DE APLICAO (AP) USER ELEMENT (UE)
ASO
ASE
ASE
ASE
CF
ASO
ASO
ASO
PSAP
PSAP
CONEXO DE APRESENTAO
Figura 8.2: Camada de aplica c~ ao baseada em ASOs. A seguir apresentaremos alguns elementos de servi co da camada de aplica ca ~o.
8.3 Servi co de Associa c~ ao ACSE

Conforme mensionado anteriormente, o elemento de aplica c~ ao respons avel pelo estabelecimento de associa c~ ao e o ACSE. O ACSE utiliza uma conex~ ao de apresenta c~ ao para cada associa c~ ao que estabelece. Um dado interessante e que ap os estabelecida a associa ca ~o, a entidade que a requisitou passa a utilizar diretamente a conex~ ao de apresenta c~ ao aberta para esta associa ca ~o para a troca de dados. Entretanto, o encerramento da associa ca ~o se d a atrav es do ACSE. Al em dos par^ ametros requeridos pela primitiva P-CONNECT, o estabelecimento de uma associa c~ ao necessita: identi cadores das entidades de aplica c~ ao envolvidas na associa c~ ao iniciadora e respondedora;
DCA-FEEC-UNICAMP
113
um contexto de aplica c~ ao: um identi cador de objeto em ASN.1 utilizado para identi car as regras de interc^ ambio de informa c~ ao atrav es da associa c~ ao por exemplo, protocolo de aplica c~ ao; dados supridos pela entidade usu aria n~ ao interpretados pelo ACSE. um contexto de autentica c~ ao: um identi cador de objeto em ASN.1 utilizado para identi car as regras de autentica ca ~o por exemplo, chaves criptogr a cas. Os servi cos providos pelo ACSE s~ ao acessados atrav es das primitivas abaixo: 1. A-ASSOCIATE: estabelece uma associa c~ ao utilizando a primitiva P-CONNECT da camada de apresenta c~ ao. Este servi co e con rmado. 2. A-RELEASE: termina uma associa c~ ao utilizando a primitiva P-RELEASE de apresenta c~ ao. Este servi co e con rmado. 3. A-ABORT: termina adruptamente aborta uma associa c~ ao por solicita c~ ao da entidade usu aria utilizando a primitiva P-U-ABORT de apresenta c~ ao. Este servi co e sem con rma ca ~o. 4. A-P-ABORT: informa o t ermino adrupto de uma associa c~ ao pelo provedor do servi co. Esta primitiva e ativada quando da ocorr^ encia de um P-P-ABORT na camada de apresenta c~ ao e possui o modo indica c~ ao apenas. 5. A-UNITDATA: transfere uma unidade de dados de aplica c~ ao sem o estabelecimento de associa c~ ao. Este servi co e sem con rma c~ ao e utiliza a primitiva P-UNITDATA de apresenta c~ ao. Note a inexist^ encia da primitiva A-DATA para envio de dados atrav es de uma associa c~ ao. A primitiva P-DATA e empregada para esta nalidade. Um ponto importante do ACSE e como entidades de aplica c~ ao s~ ao identi cadas. A identi ca c~ ao AEs se d a atrav es de nomes que o ACSE mapeia em endere cos de apresenta c~ ao PSAPs utilizando o pr oprio servi co de diret orio da camada de aplica c~ ao.
8.4 Servi co de Opera c~ oes Remotas ROSE

ROSE Remote Operations Service Element e um ASE que intermedia a submiss~ ao remota de opera c~ oes. Exemplo de tais opera c~ oes s~ ao: armazenamento de mensagens e submiss~ ao de tarefas jobs remotas. O ROSE fornece um servi co similar a uma chamada de procedimento remoto RPC: Remote Procedure Call, sendo que este servi co pode ter natureza s
ncrona ou ass
ncrona. No modo s
ncrono a entidade solicitante permanece bloqueada at e a entidade executora retornar o resultado da opera c~ ao. No modo ass
ncrono, a entidade solicitante pode evocar m ultiplas opera c~ oes e s o ent~ ao coletar os respectivos resultados. Sob esta otica, as opera co ~es remotas s~ ao agrupadas em cinco classes:
DCA-FEEC-UNICAMP
114
classe 1: opera ca ~o s
ncrona que retorna indicativo de sucesso ou falha; classe 2: opera ca ~o ass
ncrona que retorna indicativo de sucesso ou falha; classe 3: opera ca ~o ass
ncrona que retorna somente indicativo de falha; classe 4: opera ca ~o ass
ncrona que retorna somente indicativo de sucesso; classe 5: opera ca ~o ass
ncrona que n~ ao retorna qualquer indicativo. O ROSE utiliza associa co ~es para a comunica c~ ao entre entidades remotas3. Uma associa c~ ao aberta para suporte a opera coes remotas de ne atrav es de sua classe qual entidade est a autorizada a evocar procedimentos remotos: classe 1: permite apenas a entidade que solicitou a associa c~ ao evocar opera c~ oes remotas; classe 2: permite apenas a entidade que aceitou a associa c~ ao evocar opera co ~es remotas; classe 3: permite ambas as entidades evocarem opera c~ oes remotas. O ROSE prov^ e seus servi cos atrav es de cinco primitivas: 1. 2. 3. 4. RO-INVOKE: solicita a execu c~ ao de uma opera c~ ao remota; RO-RESULT: retorna o resultado da opera c~ ao remota; RO-ERROR: reporta um erro na execu c~ ao de uma opera c~ ao remota; RO-REJECT-U: rejeita uma solicita c~ ao ou retorno se a entidade usu aria detectar um erro por exemplo, opera c~ ao inexistente ou falha de autentica c~ ao; 5. RO-REJECT-P: rejeita uma solicita c~ ao ou retorno se o provedor de servi co detectar um erro. Todos os servi cos s~ ao sem con rma c~ ao RO-REJECT-P possui o modo indica c~ ao apenas. O ROSE de ne quatro classes de de PDUs, um para cada tipo de primitiva. Argumentos, resultados e erros das opera co ~es s~ ao especi cados em ASN.1. O ROSE prov^ e ainda o conceito de opera c~ oes ligadas linked. Neste mecanismo um argumento de uma opera c~ ao identi ca outra opera c~ ao dirigida para o pr opria entidade solicitante. Um dos objetivos e evitar a passagem de argumentos volumosos matrizes, por exemplo atrav es da execu c~ ao de opera c~ oes no local onde os argumentos est~ ao armazenados emulando a passagem de argumentos por refer^ encia. A gura 8.3 ilustra este exemplo.
Propostas recentes permitem opera c~ oes remotas sem o estabelecimento de associa c~ ao atrav es da primitiva A-UNITDATA.
3
DCA-FEEC-UNICAMP
ROSE #1

ROSE #2
115
OPERAO B (ligada A) OPERAO A
TEMPO
TEMPO
Figura 8.3: Opera c~ oes ligadas no ROSE.
8.5 Servi co de Transfer^ encia Con avel RTSE

RTSE Reliable Transfer Service Element e um ASE que prov^ e a transfer^ encia con a vel de dados entre duas entidades de aplica c~ ao. Por con a vel subentende-se a capacidade de recupera c~ ao de erros quebras de conex~ oes, panes de hardware, etc.. O RTSE fornece uma interface mais simples a camada de sess~ ao, al em de esconder" a exist^ encia do ACSE. Por exemplo, o RTSE insere automaticamente pontos de sincronismo no uxo de dados sendo transferido, al em de gerenciar a atividade de sess~ ao aberta para a transfer^ encia. O RTSE e utilizado, por exemplo, nas implementa c~ oes MHS Message Handling System para transfer^ encia con avel de mensagens entre comutadores relays. O RTSE emprega transfer^ encia alternada nos dois sentidos TWA: Two Way Alternate, com mecanismo de token para gerenciamento do sentido da comunica c~ ao. Para cada PDU submetido para transfer^ encia, o RTSE abre uma nova atividade a n
vel de sess~ ao. O PDU e ent~ ao segmentado em blocos, sendo a transfer^ encia de cada bloco precedida por um ponto de sincronismo menor. Quando todos os blocos tiverem sua recep ca ~o con rmada o RTSE con rma a entidade usu aria a entrega do PDU e encerra a atividade. Caso um bloco n~ ao tenha sido con rmado, o RTSE solicita ao outro extremo uma retroa c~ ao ao ponto de sincronismo inserido anteriormente a este bloco. Um ponto importante do RTSE e que este assume que os dados sendo transferido s~ ao constitu
dos de string de bytes, isto e, o tipo ASN.1 OCTET STRING. A raz~ ao desta imposi ca ~o
DCA-FEEC-UNICAMP
116
e facilitar a inser c~ ao autom atica de pontos de sincronismo menor para ns de retroa c~ ao ante a ocorr^ encia de falhas. Isto sem duvida consiste numa limita c~ ao severa posto que as entidades usu arias do RTSE certamente desejariam transferir dados bem mais estruturados. Para contornar esta limita c~ ao, a especi ca c~ ao RTSE de ne um servi co de compatibiliza c~ ao sint atica4 . Este servi co permite que as entidades usu arias de nam implementa c~ oes locais que transformam os tipos de dados peculiares da entidade em string de octetos. Regras para esta transforma ca ~o est a fora da especi ca c~ ao do RTSE. O RTSE disp~ oe de sete primitivas: um servi RT-OPEN: solicita o estabelecimento de uma associa ca ~o. E co con rmado. um servi RT-CLOSE: solicita o encerramento de uma associa c~ ao. E co con rmado. um servi RT-TRANSFER: transfere dados. E co con rmado. um RT-TURN-PLEASE: solicita a outra entidade habilita c~ ao para transferir dados. E servi co n~ ao con rmado. RT-TURN-GIVE: passa o token a outra entidade, habilitando-a a transferir dados. E um servi co n~ ao con rmado. um servi RT-U-ABORT: termina adruptamente uma associa c~ ao. E co n~ ao con rmado. RT-P-ABORT: o provedor sinaliza a impossibilidade de manter a associa c~ ao. Possui o modo indica ca ~o apenas.
8.6 Servi co de Controle de Concorr^ encia e Recupera c~ ao CCR

CCR Commitment, Concurrency and Recovery e um servi co de suporte a transa co ~es at^ omicas. Uma transa c~ ao at^ omica e um conjunto de opera c~ oes tipicamente sobre uma massa de dados cuja execu c~ ao deve satisfazer a tr^ es propriedades: 1. atomicidade: ou todas as opera c~ oes se completam com sucesso, ou tudo que a transa c~ ao produziu e desfeito; 2. serializa c~ ao: as opera c~ oes pertencentes a transa c~ oes at^ omicas distintas n~ ao se entrela cam; 3. persist^ encia: quando uma transa c~ ao at^ omica termina com sucesso, o resultado de suas opera c~ oes n~ ao se perde ante a falhas n~ ao catastr o cas tais como queda de hosts e rede. Transa c~ oes at^ omicas t^ em por nalidade manter consistente o estado de determinados objetos massas de dados, programas, etc quando manipulados por opera c~ oes sujeitas a falhas.
4
Syntax Matching Service.
DCA-FEEC-UNICAMP
117
Uma transa ca ~o at^ omica opera sobre objetos localizados em um ou mais hosts. No u ltimo caso, um host e eleito como coordenador da transa c~ ao geralmente o host da aplica c~ ao que solicitou a transa ca ~o sendo os demais participantes. Tanto o coordenador quanto os participantes s~ ao respons aveis pela garantia das tr^ es propriedades acima. Um instante cr
tico para esta garantia e o encerramento da transa c~ ao. Um protocolo de consenso se faz necess ario e 5 o mais utilizado e o protocolo de compromissamento em duas fases . A implementa c~ ao de transa c~ oes at^ omicas n~ ao e tarefa trivial. Mecanismos de recupera ca ~o rollback s~ ao necess arios para a garantia da atomicidade; de bloqueio locking para garantir a serializa c~ ao; e de logging para a garantia da persist^ encia. O CCR n~ ao oferece tais mecanismos, posto que s~ ao fortemente dependentes da aplica c~ ao. Em resumo, o CCR prov^ e primitivas para iniciar, abortar e terminar uma transa c~ ao segundo o protocolo de compromissamento em duas fases. As primitivas CCR s~ ao: C-BEGIN: o coordenador informa aos participantes o in
cio de uma transa c~ ao at^ omica sem con rma c~ ao; C-PREPARE: o coordenador solicita aos participantes o encerramento da transa c~ ao sem con rma c~ ao; C-READY: o participante responde o coordenador que est a pronto para encerrar a transa c~ ao sem con rma c~ ao. Neste momento, todas as opera co ~es efetuadas pela transa c~ ao s~ ao feitas permanentes gravadas em disco. C-REFUSE: o participante responde o coordenador que est a impossibilitado de encer6 rar a transa c~ ao com sucesso sem con rma c~ ao; C-COMMIT: o coordenador informa aos participantes que a transa ca ~o pode se encerrar com sucesso caso todos os participantes tenham respondido C-READY. Este servi co e con rmado; C-ROLLBACK: o coordenador informa aos participantes que a transa c~ ao deve ser abortada caso pelo menos um participante respondeu C-REFUSE. Coordenador e participantes desfazem todas as opera c~ oes efetuadas pela transa ca ~o. Este servi co e con rmado; C-RESTART: reinicia, se poss
vel, uma transa c~ ao a partir de um ponto especi cado. Este servi co e con rmado. Note a inexist^ encia de uma primitiva tipo C-DATA. Tal qual o RTSE, o CCR utiliza os servi cos da camada de apresenta c~ ao para transfer^ encia de dados. O CCR fornece apenas os mecanismos de controle para o processamento de transa c~ oes. As opera c~ oes realizadas no ambito de uma transa ^ ca ~o est~ ao fora da especi ca c~ ao CCR. Estas podem se basear no ROSE ou simplesmente utilizar a primitiva P-DATA de apresenta ca ~o para o envio de informa c~ ao.
Provavelmente porque alguma de suas opera co ~es falhou, ou est a impossibilitado de tornar as opera c~ oes permanentes.
5 6
Two-fase commit.
DCA-FEEC-UNICAMP
118
Do ponto de vista da implementa ca ~o, uma transa c~ ao e delimitada por pontos de sincronismo maior. As primitivas C-REFUSE, C-ROLLBACK e C-RESTART emitem um PRESYNCHRONIZE a m de retroagir via facilidades de logging ao ponto de sincronismo inserido no in
cio da transa c~ ao. Uma especi ca c~ ao correlata denominada TP Transaction Processing incorpora todas as primitivas do CCR, de nindo inclusive uma primitiva TP-DATA.
8.7 Servi co de Troca de Mensagens MHS

MHS Message Handling System e um servi co de manipula c~ ao7 de mensagens. Este servi co e conhecido como X.400 por ter se originado na CCITT e publicado com esta identi ca c~ ao. MHS se destina tanto ao suporte de sistemas de mensagens inter-pessoal correio eletr^ onico quanto documentos comerciais EDI: Electronic Data Exchange. O MHS n~ ao se restringe a caracteres ASCII, como o SMTP8, seu equivalente da arquitetura TCP IP. Mensagens compostas de textos, imagens, gr a cos, etc., podem ser manipuladas pelo MHS. O modelo MHS consiste de v arios elementos funcionais, descritos a seguir. Um Agente do Usu ario UA: User Agent pode ser visto como um aplicativo que interage com o usu ario. Por usu ario subentende-se uma pessoa ou um programa que faz uso do MHS. O UA e encarregado de preparar, enviar e receber mensagens. O envio de mensagens se d a atrav es de Agentes de Transfer^ encia de Mensagens MTA: Message Transfer Agent. MTAs s~ ao comutadores de mensagens, isto e, armazenam temporariamente e enviam a outro MTA pol
tica Armazena e Envia" at e ser entregue ao UA servindo o destinat ario. Note que n~ ao e aberta conex~ ao direta entre o originador e o destinat ario da mensagem; ao contr ario, a mensagem e chaveada" entre MTAs analogamente a comuta c~ ao de pacotes. MTAs cooperam segundo um protocolo denominado P1 e utilizam o RTSE para a transfer^ encia con avel da mensagem entre MTAs. Acesso aos MTAs se d a atrav es de um protocolo denominado P3. MS Message Store e um elemento funcional que atua entre o UA e o MTS. Sua fun c~ ao e armazenar temporariamente a mensagem at e ser entregue ao MTS no caso de envio ou ao UA no caso de recep ca ~o. Opera c~ oes de armazenamento e recupera ca ~o nos MSs s~ ao executadas segundo um protocolo denominado P7. Tais opera co ~es s~ ao executadas remotamente nos MSs atrav es dos servi cos providos pelo ROSE. MTS Message Transfer System e uma cole c~ ao de MTAs que atuam cooperativamente an no roteamento de mensagens. E alogo a uma rede de comuta c~ ao de pacotes onde os MTAs seriam os IMPs. A gura 8.4 ilustra a interliga c~ ao dos elementos funcionais descritos acima. Uma mensagem X.400 e composta de um envelope e um conte udo conforme ilustrado na gura 8.5. O endere camento X.400 e utilizado tanto para identi car originador e destinat arios quanto para rotear as mensagens. Um endere co X.400 e composto dos seguintes campos:
7 8
Endere camento, armazenamento, envio, noti ca c~ ao, etc. Simple Mail Transfer Protocol.
DCA-FEEC-UNICAMP
USURIO

USURIO
119
MHS
MS UA
P3 P7
P3
UA
MTA
MTA
P1
P1 P1
MTS
P1
MTA
P3
MTA UA
P7 P3
UA
P3
UA
USURIO
MS
USURIO USURIO
Legenda: MTA: Message Tranfer Agent MS: Message Store UA: User Agent MTS: Message Transfer System MHS: Message Handling System
Figura 8.4: Elementos funcionais do MHS. Nome de Pa

s: c odigo de 2 ISO 3166 ou 3 CCITT X.121 caracteres indicando o pa
s do usu ario Ex: BR; Nome ADMD Administrative Management Domain: especi ca a organiza c~ ao provedora do servi co ao qual o usu ario est a conectado Ex: Embratel; Nome PDMD Private Management Domain: eventual corpora c~ ao que intermedia o oferecimento do servi co ex: uma BBS; Nome da Organiza c~ ao a qual o usu ario pertence; Nome da Unidade Organizacional a qual o usu ario pertence; Nome Pessoal do usu ario; Atributos pr oprios do dom
nio; Endere co X.121 do terminal do usu ario. Nem todos os atributos acima podem estar presentes no envelope de uma mensagem. Por exemplo, o endere co do terminal pode suprimir o nome da organiza c~ ao e usu ario. Quanto a seguran ca e privacidade, o protocolo X.400 cobre tr^ es areas:
DCA-FEEC-UNICAMP

EMISSOR: DESTINATARIO: INFO. SOBRE ROTEAMENTO: INFO. SOBRE CONTEDO: ....
120
ENVELOPE
TIPO: CODIFICAO:
CONTEDO
Figura 8.5: Estrutura de mensagens no MHS. 1. con dencialidade: garante que apenas o destinat ario ter a acesso ao conte udo da mensagem; 2. autentica c~ ao: garante a identidade do originador9 ; 3. provas de submiss~ ao e entrega: noti ca c~ oes que comprovam o envio recep ca ~o.
8.8 Servi co de Diret orio DS

DS Directory Service e um servi co de base de dados global DIB: Directory Information Base. Esta base de dados forma um diret orio eletr^ onico" que armazena objetos tais como pessoas, endere cos, senhas, organiza c~ oes, etc. Este servi co e parte das recomenda co ~es da s erie X.500 da ex-CCITT. Cada objeto do diret orio possui um ou mais nomes distintos que servem como chave de acesso para este objeto. Nomes distintos s~ ao cole co ~es ordenadas de atributos tais como: cn: common name nome usual; ou: organizational unit unidade organizacional; o: organiza c~ ao; st: state estado; c: country pa
s.
9
Isto e, impede que uma mensagem seja enviada em nome de outr em.
DCA-FEEC-UNICAMP
121
Um objeto e uma sequ^ encia de atributos especi cado em ASN.1 onde cada atributo possui um identi cador de objeto que descreve o tipo de atributo e os correspondentes valores. Tipos usualmente s~ ao PrintableString em ASN.1 o que possibilita uma interpreta c~ ao livre de arquitetura de m aquina. A gura 8.6 ilustra um objeto gen erico.
ATRIBUTO ATRIBUTO ATRIBUTO
TIPO
VALOR
VALOR
VALOR
Figura 8.6: Modelo de objeto para o Servi co de Diret orio. Objetos s~ ao agrupados em classes, sendo algumas classes padronizadas pela recomenda ca ~o X.520. O diret orio em si e estruturado na DIB na forma de arvore denominada DIT: Directory Information Tree conforme ilustrado na gura 8.7. Do ponto de vista funcional, o DS e composto que quatro componentes. O primeiro, DSA Directory Service Agent armazena uma parte do diret orio distribu
do. O segundo componente, DUA Directory User Agent intermedia o acesso ao diret orio por parte de um usu ario. O terceiro componente, DAP Directory Access Protocol viabiliza a intera ca ~o DUA-DSA; sendo o quarto componente, DSP Directory Service Protocol um protocolo de intera c~ ao DSA-DSA. DAP e DSP s~ ao de nidos como opera c~ oes ROSE. Este modelo funcional e ilustrado na gura 8.8. O DAP e um protocolo tipo requisi c~ ao-resposta. A requisi c~ ao carrega tipicamente um nome distinto de um objeto e a resposta o conte udo deste objeto. Caso o objeto n~ ao esteja armazenado no DSA, este pode: 1. retornar o endere co de apresenta c~ ao de outro DSA mais pr oximo" da informa ca ~o requisitada; 2. encadear a solicita c~ ao para outro DSA; 3. difundir a solicita ca ~o para um conjunto de DSAs, repassando uma eventual resposta ao DUA que solicitou a informa c~ ao.
8.9 Servi co de Transfer^ encia de Arquivos FTAM

FTAM File Transfer, Access and Management e um ASE que prov^ e funcionalidades para acesso, transfer^ encia e ger^ encia de arquivos remotos, diret orios e links simb olicos10. O FTAM
10
Diret orios e links simb olicos foram incorporados como adendos a especi ca ca ~o em 1990.
DCA-FEEC-UNICAMP

RAIZ
122
c: BR
c: FR
o: UNICAMP
o: USP
ou: FEEC
ou: FEM
ou: DCA
ou: DEB
ou: ELERI CARDOZO
Figura 8.7: DIT Directory Information Tree. de ne um sistema de arquivos virtual", independente do sistema de arquivos real" da m aquina. As opera c~ oes FTAM s~ ao de nidas sobre o primeiro e mapeadas no segundo de acordo com a implementa c~ ao gura 8.9. O FTAM utiliza o ACSE para o estabelecimento de uma sess~ ao de opera ca ~o sobre arquivos remotos e o CCR para agrupar numa mesma sess~ ao uma sequ^ encia de opera c~ oes. Um arquivo e composto de zero ou mais unidades de dados DU: Data Units. As DUs s~ ao organizadas em uma estrutura hier arquica arvore que determina a inter-rela c~ ao entre as DUs. Esta estrutura e denominada FADU File Access Data Unit. Caso o arquivo possua apenas uma FADU, o mesmo e denominado n~ ao-estruturado; se a hierarquia de FADUs possuir apenas 2 n
ves, o arquivo e dito sequencial; com mais de 2 n
veis, tem-se um arquivo estruturado em blocos. A gura 8.10 ilustra estas tr^ es possibilidades. O FTAM de ne nove tipos de arquivos, desde arquivos de texto n~ ao estruturados at e arquivos especiais para aplica c~ oes gr a cas. O FTAM possui 25 primitivas. Seis primitivas s~ ao de nidas para abertura fechamento de sess~ ao: 1. F-INITIALIZE: inicia uma sess~ ao FTAM servi co con rmado; 2. F-TERMINATE: encerra uma sess~ ao FTAM servi co con rmado; 3. F-U-ABORT: interrompe aborta uma sess~ ao FTAM servi co n~ ao con rmado;
DCA-FEEC-UNICAMP

USURIO
123
DSA
DAP
DUA
DSP
DSP
DSA
DSP DAP
DSA
DUA
Legenda: DSA: Directory Service Agent DUA: Directory User Agent DSP: Directory Service Protocol DAP: Directory Access Protocol
USURIO
Figura 8.8: Modelo funcional do Servi co de Diret orio DS 4. F-P-ABORT: o provedor de servi co interrompe aborta uma sess~ ao FTAM primitiva tipo indica c~ ao apenas; 5. F-SELECT: seleciona um arquivo para opera c~ ao servi co con rmado; 6. F-DESELECT: desfaz uma sele c~ ao servi co con rmado. Quatro primitivas s~ ao de nidas para gerenciamento de arquivos todas as primitivas s~ ao servi cos con rmados: 1. 2. 3. 4. F-CREATE: cria um novo arquivo; F-DELETE: remove um arquivo. F-READ-ATTRIB: l^ e os atributos do arquivo permiss~ oes, tipo, etc.; F-CHANGE-ATTRIB: altera os atributos do arquivo.
Seis primitivas s~ ao utilizadas para gerenciamento de falhas e atomicidade todas as primitivas s~ ao servi cos con rmados: 1. F-BEGIN-GROUP: marca o in
cio de uma opera c~ ao at^ omica; 2. F-END-GROUP: sinaliza o t ermino de uma opera c~ ao at^ omica;
DCA-FEEC-UNICAMP
USURIO
124
PROCESSO DE APLICAO (AP)
FTAM
Protocolo FTAM
FTAM
SAV
Legenda: SAV: Sistema de Arquivo Virtual SA: Sistema de Arquivo
SA
Figura 8.9: FTAM: Sistema de Arquivos Virtual. 3. F-RECOVER: restabelece um regime de transfer^ encia ap os a ocorr^ encia de falha; 4. F-CANCEL: termina adruptamente uma transfer^ encia de arquivo; 5. F-CHECK: estabelece um checkpoint no regime de transfer^ encia11; 6. F-RESTART: retorna a um checkpoint anterior. Finalmente, nove primitivas oferecem o servi co de transfer^ encia propriamente dito: 1. F-OPEN: abre um arquivo para leitura escrita servi co con rmado; 2. F-CLOSE: fecha um arquivo aberto servi co con rmado; 3. F-LOCATE: posiciona o ponteiro de transfer^ encia numa FADU espec
ca servi co conrmado; 4. F-ERASE: destr oi uma FADU servi co con rmado; 5. F-READ: l^ e uma ou mais FADUs servi co sem con rma c~ ao;
11
O FTAM n~ ao utiliza pontos de sincroniza c~ ao para este servi co.
DCA-FEEC-UNICAMP
125
DU (A)
DU (B)
DU
DU
DU
DU
DU
DU
(C) Legenda: DU: Data Unit
Figura 8.10: FTAM: Arquivos n~ ao estruturado A; sequencial B; estruturado em blocos C. As linhas pontilhadas do item C de nem FADUs. 6. F-WRITE: escreve numa ou mais FADUs servi co sem con rma c~ ao; 7. F-DATA: sinaliza a entidade respondedora a presen ca de dados primitiva tipo indica c~ ao apenas; 8. F-DATA-END: sinaliza a entidade respondedora o t ermino de trasfer^ encia de uma FADU primitiva tipo indica c~ ao apenas; 9. F-TRANFER-END: encerra o regime de transfer^ encia servi co con rmado. A gura 8.11 ilustra um diagrama de estados t
pico de opera c~ ao do FTAM.
8.10 Terminal Virtual VT

VT Virtual Terminal e um ASE que de ne terminais virtuais utilizados para intera c~ ao via rede com aplica c~ oes remotas. A necessidade de tal servi co est a relacionada a vasta gama de terminais existentes no mercado. Ao inv es de incorporar as particularidades de cada
DCA-FEEC-UNICAMP

IDLE abort
126
initialize
terminate
conectado
select/create
deselect/delete read attribute change attribute
selecionado
open
close
transferindo dados read transfer end cancel
locate/erase write
data/check/restart
read
write
data/check/restart
Figura 8.11: FTAM: diagrama de estados t

pico. terminal, uma aplica c~ ao opera sobre este terminal virtual e uma outra entidade mapeia este dispositivo virtual num dispositivo real. A id eia e similar ao conceito de sistema de arquivos virtual gura 8.9 do FTAM. A ISO de ne v arias classes de terminais de acordo com a complexidade dos objetos que o terminal e capaz de manipular. Atualmente, apenas a classe referente aos terminais baseados em caractere est a padronizada no a ^mbito do VT. O VT e um ASE similar aos descritos anteriormente: utiliza o ACSE e uma conex~ ao de apresenta c~ ao para o estabelecimento de associa c~ ao e transporte de PDUs, respectivamente. O VT utiliza tamb em os servi cos de sess~ ao para organiza c~ ao do di alogo via token caso as entidades estabele cam comunica c~ ao alternada nos dois sentidos TWA. O protocolo VT prev^ e: 1. estabelecimento de associa c~ ao entre as entidades VT12; 2. t ermino normal ou adr upto da associa c~ ao; 3. transfer^ encia de dados pela associa ca ~o; 4. negocia c~ ao e renegocia c~ ao de um per l de opera c~ ao para o terminal virtual; 5. gerenciamento do di alogo13. As primitivas para abertura e encerramento de associa ca ~o s~ ao id^ enticas as do ACSE com o pre xo VT: VT-ASSOCIATE, VT-RELEASE, VT-U-ABORT, VT-P-ABORT.
Tipicamente uma vinculada ao terminal do usu ario e outra vinculada a aplica c~ ao remota. O protocolo VT de ne dois modos de opera c~ ao: no modo A inexiste qualquer forma de gerenciamento, enquanto no modo B o gerenciamento e baseado em tokens.
12 13
DCA-FEEC-UNICAMP
127
A primitiva principal para transfer^ encia de dados, VT-DATA, de ne um servi co sem con rma c~ ao. Um dos par^ ametros desta primitiva e a prioridade dos dados: normal, alta ou urgente. Um par de primitivas tamb em sem con rma c~ ao, VT-DELIVER e VT-ACKRECEIPT s~ ao utilizadas, respectivamente, para transfer^ encia de dados e reconhecimento da recep c~ ao. A negocia ca ~o do per l de opera c~ ao se d a atrav es das seguintes primitivas: VT-START-NEG: solicita a outra entidade o in
cio de uma sess~ ao de negocia c~ ao servi co con rmado; VT-OFFER-NEG: consulta a outra entidade sobre a conveni^ encia de se estabelecer uma sess~ ao de negocia c~ ao servi co sem con rma c~ ao; VT-ACCEPT-NEG VT-REJECT-NEG: responde a rmativa ou negativamente a consulta acima servi co sem con rma c~ ao; VT-END-NEG: termina uma sess~ ao de negocia c~ ao servi co con rmado; VT-SWITCH-PROFILE: altera o per l de opera c~ ao de um terminal virtual servi co con rmado. Um ponto de sincronismo maior e inserido caso a associa c~ ao seja reiniciada via VT-BREAK. O gerenciamento do di alogo modo B se d a atrav es das primitivas VT-REQUESTTOKENS e VT-GIVE-TOKENS, ambas sem con rma c~ ao. Finalmente, o protocolo VT oferece uma primitiva para reiniciar a conex~ ao via PRESYNCHRONIZE: VT-BREAK. Este servi co e con rmado.
8.11 Problemas
Cite a loso a de integra c~ ao entre os ambientes local e OSI. Como a camada de aplica c~ ao e estruturada ? Qual a diferen ca entre conex~ ao e associa c~ ao ? Qual a vantagem de se de nir objetos de servi co ASOs ? Descreva a utilidade do ACSE, ROSE e RTSE. Cite dois empregos t
picos de transa co ~es at^ omicas. Desenhe um diagrama temporal para uma transa c~ ao at^ omica envolvendo coordenador e 3 participantes. Considere os casos de t ermino normal e anormal rollback. 8. Descreva funcionalmente o MHS. 9. Descreva funcionalmente o DS. 10. Descreva funcionalmente o FTAM. 1. 2. 3. 4. 5. 6. 7.
Cap
tulo 9 GERENCIAMENTO DE REDES
Devido a expans~ ao das redes, dois aspectos s~ ao fundamentais: a rede e os recursos associados t^ em se tornado indispens aveis a s organiza c~ oes; aumento da probabilidade de comportamento errado devido a falha em parte da rede ou degrada c~ ao do desempenho a n
veis inaceit aveis. Uma rede de maior complexidade n~ ao pode ser gerenciada somente com o esfor co humano, necessitando que ferramentas autom aticas de gerenciamento sejam utilizadas. A di culdade de fornecimento destas ferramentas aumenta se a rede inclui equipamentos de v arios fabricantes. Estas di culdades est~ ao presentes nos n
veis das redes locais LAN - Local Area Network, redes metropolitanas MANs - Metropolitan Area Networks e redes de longa dist^ ancia WAN - Wide Area Networks. Entretanto, as redes locais e, em boa parte, as redes metropolitanas, encontram-se no centro de qualquer estrat egia de rede de uma empresa e devem ser uma das preocupa c~ oes principais de todo programa de gerenciamento de rede. Para gerenciar uma rede e fundamental o conhecimento sobre o status e comportamento da rede. Neste sentido, e necess ario um sistema de gerenciamento de rede que inclua um conjunto compreens
vel de ferramentas de captura de dados e controle integrado ao software e hardware da rede.
9.1 Requisitos do Gerenciamento de Rede

A ISO International Standard Organization lista as seguintes areas como chaves no gerenciamento de redes: gerenciamento de falhas; gerenciamento de contabilidade; gerenciamento de con gura c~ ao e nome; gerenciamento de desempenho; gerenciamento de seguran ca. Cada uma destas ger^ encias encontra-se discutida na sequ^ encia. 128
DCA-FEEC-UNICAMP
129
9.1.1 Gerenciamento de Falha
De modo a manter uma opera c~ ao adequada de uma rede complexa, cuidados devem ser tomados de modo a que o sistema como um todo, e cada componente essencial individualmente, encontrem-se operando em ordem. Quando da ocorr^ encia de uma falha e importante que as seguintes a c~ oes sejam tomadas o mais rapidamente possivel: determinar exatamente o local da falha; isolar o resto da rede da falha de modo que continue a funcionar sem interfer^ encia; recon gurar ou modi car a rede de modo a minimizar o impacto na opera c~ ao sem a presen ca dos componentes em falha; reparar ou substituir os componentes com problema permitindo a rede o retorno ao estado inicial. Importante na quest~ ao da de ni c~ ao do gerenciamento de falha e o pr oprio conceito de falha. Esta deve ser distinguida do erro. Uma falha e uma condi c~ ao anormal que requer aten ca ~o ou a c~ ao do gerenciamento para repara c~ ao. Uma falha e normalmente indicada por uma opera ca ~o incorreta ou por um n umero excessivo de erros. Por exemplo, no caso de uma linha de comunica c~ ao interrompida, nenhum sinal ui atrav es da linha, ou ainda, uma emenda em um cabo pode causar fortes distor c~ oes de modo a provocar uma taxa elevada e persistente de erro no n
vel de bit. Certos erros, por outro lado, podem ocorrer ocasionalmente e n~ ao s~ ao normalmente considerados como falha, por exemplo, o erro em um u nico bit em uma linha de comunica c~ ao. Em geral, e poss
vel compensar a ocorr^ encia de erros atrav es de mecanismos de controle de erros presentes nos protocolos de comunica ca ~o. Os usu arios esperam uma solu c~ ao r apida e con a vel do problema. Muitos usu arios nais poder~ ao, eventualmente, tolerar perdas ocasionais. Entretanto, quando da ocorr^ encia n~ ao frequente destas perdas, o usu ario espera receber uma noti ca c~ ao e a solu ca ~o quase que imediata do problema Para fornecer este n
vel de resolu c~ ao de falhas, e necess aria a disponibilidade de fun co ~es de gerenciamento r apidas e con aveis voltadas para dete ca ~o de falhas e os respectivos diagn osticos. O impacto e a dura c~ ao das falhas tamb em podem ser minimizados pelo uso de componentes redundantes e rotas de comunica c~ ao alternativas com o objetivo de fornecer a rede um alto grau de toler^ ancia a falhas. A pr opria capacidade de gerenciamento de falhas deve ser redundante a m de aumentar a con abilidade da rede. Os usu arios esperam ser informados do status da rede, incluindo-se a programa c~ ao da manuten ca ~o da rede, como tamb em , a manuten c~ ao n~ ao programada e feita em fun c~ ao da ocorr^ encia de problemas na rede. Ap os corre c~ ao de uma falha e restaura c~ ao do sistema a sua condi c~ ao plena de opera c~ ao, o servi co de gerenciamento de falhas deve garantir que o problema foi resolvido e que nenhum outro problema foi introduzido. Assim como em outras areas do gerenciamento de redes, o gerenciamento de falhas deve ter um efeito m
nimo no desempenho da rede.
Requisitos do Usu ario
DCA-FEEC-UNICAMP
130
9.1.2 Gerenciamento de Contabilidade
Em muitas redes corporativas, divis~ oes ou projetos s~ ao cobrados pelo uso dos servi cos de rede. Estes procedimentos internos de contabilidade n~ ao envolvem, em geral, transfer^ encia real de fundos, mas s~ ao importantes para a empresa. Mesmo que este tipo de contabilidade interna n~ ao seja empregada, o gerente da rede deve ser capaz de acompanhar o uso dos recursos da rede por parte de um usu ario ou de grupos de usu arios com as seguintes nalidades: um usu ario, ou grupo de usu arios, pode estar abusando gra cas a um acesso privilegiado e, desta maneira, sobrecarregando a rede em preju
zo de outros usu arios; usu arios podem estar fazendo um uso ine ciente da rede; o gerente da rede poder a assisti-los na mudan ca de procedimentos visando uma melhoria no desempenho. O gerente da rede estar a em uma melhor posi c~ ao para planejar uma eventual expans~ ao da rede se as atividades dos usu arios forem conhecidas em detalhe su ciente. O gerente da rede deve ser capaz de especi car os tipos de informa c~ ao de contabilidade que dever~ ao ser armazenados nos v arios n os, o intervalo desejado de envio das informa c~ oes armazenadas aos n
veis superiores de gerenciamento e os algoritmos a serem utilizados nos c alculos de carga do uso da rede pelos usu arios. Relat orios de contabilidade dever~ ao ser gerados sob controle do gerente de rede. Com o objetivo de limitar o acesso a s informa c~ oes de contabilidade, o sistema deve ser capaz de veri car a autoriza ca ~o de acesso e manipula ca ~o da informa ca ~o por parte dos usu arios.
9.1.3 Gerenciamento de Nome e Con gura c~ ao
As redes modernas de comunica c~ ao s~ ao formadas de componentes individuais e subsistemas l ogicos que podem ser con gurados para suportar muitas aplica c~ oes diferentes. O mesmo dispositivo pode ser con gurado para agir como um roteador, como um n o do sistema ou ambos. Uma vez decidido como o dispositivo ser a usado, o gerente de con gura c~ ao pode escolher o software apropriado e o conjunto de atividades e valores ex: tempo de retransmiss~ ao na camada de transporte para aquele dispositivo. O gerente de con gura ca ~o e respons avel pela inicia c~ ao da rede e pela parada controlada da rede ou parte da rede. Ainda sob a sua responsabilidade encontram-se a manuten c~ ao, adi c~ ao e atualiza ca ~o das rela c~ oes entre os componentes e o estado destes componentes durante a opera c~ ao da rede.
As opera c~ oes de partida e parada em uma rede s~ ao responsabilidades espec

cas do gerente de con gura c~ ao. O gerente deve ser capaz de identi car os componentes da rede e de nir a conectividade desejada destes componentes. Quando a rede e con gurada sempre com o mesmo conjunto de atributos e necess ario poder de nir e modi car os atributos default, como tamb em, carregar estes conjuntos pr e-de nidos de atributos em componentes espec
cos da
DCA-FEEC-UNICAMP
131
rede. O gerente deve ser capaz de alterar a conectividade dos componentes da rede quando houver altera c~ ao nas necessidades do usu ario. Recon gura c~ ao de uma rede e geralmente desej avel em resposta a avalia c~ ao de desempenho ou para suportar expans~ ao da rede, recupera c~ ao de falha e teste de seguran ca. Usu arios geralmente necessitam, ou desejam ser informados do estado dos recursos e componentes da rede. Portanto, na ocorr^ encia de mudan cas na con gura ca ~o, os usu arios dever~ ao ser noti cados desta altera c~ ao. Relat orios de con gura c~ ao podem ser gerados de forma peri odica ou em resposta a uma requisi c~ ao. Gerentes de rede aceitam somente que usu arios autorizados operadores gerenciem e controlem a opera c~ ao de rede ex: distribui c~ ao e atualiza c~ ao de software.
9.1.4 Gerenciamento de Desempenho
As redes de computadores modernas s~ ao compostas de muitos componentes variados que necessitam se intercomunicar e compartilhar dados e recursos. Em muitos casos a efetividade da aplica c~ ao requer que a comunica c~ ao via rede esteja dentro de certos limites de desempenho. O gerenciamento de desempenho de uma rede de computadores compreende duas amplas categorias: monitoramento e controle. Monitoramento e a fun c~ ao que "persegue" as atividades na rede. A fun c~ ao de controle permite o gerenciamento de desempenho da rede. Algumas das quest~ oes de desempenho relacionadas ao gerenciamento da rede s~ ao: qual o n
vel da capacidade de utiliza c~ ao? existe tr afego excessivo? o throughput tem sido reduzido a n
veis aceit aveis? o tempo de resposta est a aumentando? Para responder a estas quest~ oes, o gerente de rede deve focalizar um conjunto inicial de recursos para ser monitorado de modo a estimar os n
veis de desempenho. Isto inclui a associa c~ ao de m etricas e valores adequados a recursos importantes da rede como indicadores dos diferentes n
veis de desempenho. Por exemplo, qual o n umero de retransmiss~ oes em uma conex~ ao de transporte que deve indicar problemas de desempenho necessitando de aten ca ~o? O gerenciamento de desempenho deve, portanto, monitorar muitos recursos para fornecer informa co ~es a respeito de um determinado n
vel de opera c~ ao da rede. Atrav es da cole ca ~o e an alise destas informa c~ oes e do uso do resultado desta an alise como realimenta c~ ao ao conjunto de valores recomendados, o gerente da rede pode adquirir cada vez mais a per
cia para reconhecer situa c~ oes indicativas de degrada c~ ao do desempenho.
Antes de usar uma rede para uma aplica c~ ao particular, um usu ario pode querer conhecer informa c~ oes como os tempos m edios e de pior caso e a con abilidade dos servi cos de rede. O desempenho deve ser conhecido em detalhe su ciente para poder responder quest~ oes espec
cas dos usu arios. Os usu arios nais esperam que os servi cos de rede sejam gerenciados de forma que possam proporcionar, consistentemente, bons tempos de resposta as suas
DCA-FEEC-UNICAMP
132
aplica c~ oes. Os gerentes de rede necessitam de estat

sticas de desempenho que os auxiliem a planejar, gerenciar e manter redes complexas. Estat
sticas de desempenho podem ser usadas para reconhecer potenciais gargalos antes que estes causem problemas aos usu arios nais. A c~ oes corretivas podem ent~ ao ser tomadas. Estas a co ~es podem traduzir-se na mudan ca de tabelas de roteamento para balancear ou redistribuir a carga do tr afego durante per
odos de pico ou quando um gargalo e identi cado pelo crescimento muito r apido da carga em uma determinada area. A longo prazo, a capacidade de planejamento baseada em tais informa c~ oes de desempenho pode indicar a decis~ ao, por exemplo, de expans~ ao das linhas naquela a rea.
9.1.5 Gerenciamento de Seguran ca
O gerenciamento de seguran ca est a associado com a gera c~ ao, distribui c~ ao e armazenamento de chaves de criptogra a. Password e outras informa c~ oes de controle de acesso devem ser mantidas e distribu
das. Gerenciamento de seguran ca tamb em encontra-se associado com o monitoramento e controle de acesso a redes de computadores e acesso a toda, ou parte, da informa c~ ao de gerenciamento obtida de n os da rede. Arquivos de registro s~ ao uma ferramenta de seguran ca importante o que faz com que o gerenciamento de seguran ca envolva a cole ca ~o, armazenamento e exame de arquivos de seguran ca, assim como, a habilita c~ ao e desabilita ca ~o destas facilidades de registros logs.
O gerenciamento de seguran ca fornece facilidades para prote c~ ao de recursos da rede e da informa c~ ao do usu ario. Facilidades de seguran ca de rede devem ser dispon
veis somente para usu arios autorizados. Os usu arios desejam saber que pol
ticas de seguran ca est~ ao implantadas na rede e que o gerenciamento das facilidades de seguran ca tamb em e seguro.
9.2 Sistemas de Gerenciamento de Rede

Um sistema de gerenciamento de rede e uma cole c~ ao de ferramentas para monitoramento e controle da rede com as seguintes caracter
sticas: uma u nica interface de operador com um poderoso e amig avel conjunto de comandos para realiza c~ ao da maioria das tarefas de gerenciamento; uma quantidade m
nima de equipamentos separados, ou seja, a maioria do hardware e do software requerido para o gerenciamento da rede deve ser incorporado no equipamento existente do usu ario. Um sistema de gerenciamento de redes consiste de adi c~ oes incrementais de hardware e software implementados entre os componentes existentes na redes. O software utilizado nas tarefas de gerenciamento reside nos computadores n os da rede e nos processadores de comunica c~ ao ex: processadores front-end, controladores de terminal, pontes, roteadores, etc.. Um sistema de gerenciamento de rede deve ser projetado para enxergar a rede como uma arquitetura uni cada, com endere cos e nomes atribu
dos a cada ponto e conhecer os
DCA-FEEC-UNICAMP
133
atributos e liga co ~es de cada elemento no sistema. Os elementos ativos da rede fornecem regularmente uma realimenta c~ ao da informa c~ ao do estado para o centro de controle da rede. A gura a seguir sugere a arquitetura de um sistema de gerenciamento de rede. Cada n o da rede cont em uma cole c~ ao de software voltado para a tarefa de gerenciamento de rede, indicada na gura como entidade de gerenciamento de rede Network Management Entity NME. Cada NME realiza as seguintes tarefas: coleciona estat
sticas de comunica c~ ao e atividades relacionadas a rede; armazena estat
stica local; responde aos comandos do centro de controle da rede, incluindo: comandos para transmiss~ ao ao NCC de estat
sticas coletadas; altera c~ ao de par^ ametros ex: temporizador utilizado no protocolo de transporte; fornecimento de informa co ~es sobre estado de componentes ex: valores de par^ ametros, liga c~ oes ativas e gera c~ ao de tr afego arti cial para realiza c~ ao de testes. Pelo menos um hospedeiro no sistema e designado como centro de controle da rede. Al em do software NME, o hospedeiro que atua como controle da rede inclui uma cole ca ~o de softwares denominada Network Control Center NCC. O NCC inclui uma interface de operador para permitir a um usu ario autorizado o gerenciamento da rede. O NCC responde a comandos do usu ario atrav es de informa c~ oes enviadas para o v
deo, ou ent~ ao, comandos s~ ao dirigidos as NMEs atrav es da rede. Esta comunica c~ ao e realizada via protocolo de gerenciamento de rede no n
vel da camada de aplica c~ ao, empregando uma arquitetura de comunica c~ ao da mesma forma que qualquer outra aplica c~ ao distribu
da. Algumas observa c~ oes s~ ao importantes: 1. como o software de gerenciamento de rede baseia-se no sistema operacional do hospedeiro e na arquitetura de comunica c~ ao, muitos sistemas dispon
veis at e recentemente eram projetados para serem empregados em equipamentos de um u nico fabricante. No caso de computadores pessoais, existe um grande n umero de pacotes de software de gerenciamento que permitem a integra c~ ao de computadores pessoais de v arios fabricantes. Padr~ oes nesta area ainda est~ ao imaturos, entretanto, sistemas de gerenciamento de redes baseados em padr~ oes de modo a permitir o gerenciamento de equipamentos de v arios fabricantes est~ ao tornando-se mais comuns; 2. como mostrado na gura anterior, o centro de controle de rede comunica-se e controla, inicialmente, monitores de software em outros sistemas. A arquitetura pode ser estendida para incluir elementos de hardware especializados para fun c~ ao de monitoramento e controle; 3. para permitir uma alta disponibilidade da fun c~ ao de gerenciamento da rede, dois ou mais centros de controle s~ ao utilizados. Em opera c~ ao normal, um dos centros encontrase inativo, ou simplesmente coletando estat
sticas, enquanto o outro e utilizado para controle. Caso o centro de controle de rede prim ario falhe, o sistema de back-up poder a ser usado.
DCA-FEEC-UNICAMP
Hospedeiro controlador da rede

Processador front-end NME
134
NCC
Hospedeiro Comm. Appl. OS NME Appl. NCC
NME
Comm. OS Comm. OS
Hospedeiro NCC Controladora Appl. Comm. OS OS NCC = Centro de Controle da Rede NME = Entidade de Gerenciamento da Rede Appl. = Aplicaes Comm. Software de Comunicao NME Comm.
NME
Figura 9.1: Elementos de um Sistema de Gerenciamento de Rede
9.3 Gerenciamento de Rede OSI

A ISO International Organization for Standardization e respons avel por um conjunto de padr~ oes de gerenciamento de rede. O primeiro padr~ ao relacionado ao gerenciamento de rede foi denominado ISO 7498-4 e especi ca o contexto de gerenciamento para o modelo OSI. Este documento indica que o gerenciamento OSI suporta os seguintes requisitos dos usu arios: atividades que permitem aos gerentes planejar, organizar, supervisionar, controlar e contabilizar o uso de servi cos de interconex~ ao; habilidade de responder aos requisitos de mudan ca; facilidades que garantam comportamento previs
vel na comunica c~ ao; facilidade para prote c~ ao da informa c~ ao e autentica c~ ao da origem e do destino dos dados transmitidos. A partir deste documento, a ISO tem publicado um conjunto volumoso de padr~ oes voltados ao gerenciamento de rede. O antigo CCITT Consultative Comittee on Interna-tional Telegraphy and Telephony, atualmente ITU-TS Telecommunications Strandardization Sector, e a ISO atuam conjuntamente nestes esfor cos de padroniza c~ ao sendo o primeiro respons avel pela s erie de recomenda co ~es X.700. Os padr~ oes situam-se em cinco categorias:
DCA-FEEC-UNICAMP
135
1. vis~ ao geral e contexto do gerenciamento OSI: inclui o documento OSI 7498-4 que fornece uma introdu c~ ao geral aos conceitos de gerenciamento e o ISO 10040, que fornece uma vis~ ao geral dos documentos restantes; 2. CMIS CMIP: de ne os servi cos de informa c~ ao de gerenciamento comuns Common Management Information Service- CMIS, necess arios as aplica c~ oes de gerenciamento OSI, e o protocolo comum de gerenciamento da informa c~ ao Common Management Information Protocol - CMIP, protocolo este que fornece a capacidade de troca de informa c~ oes necess arias ao suporte do CMIS; 3. fun c~ oes do sistema de gerenciamento: de ne as fun c~ oes espec
cas que s~ ao realizadas pelo sistema de gerenciamento OSI; 4. estrutura da informa c~ ao gerenciada: de ne a base de informa c~ oes de gerenciamento Management Information Base - MIB, a qual cont em uma representa c~ ao de todos os objetos do ambiente OSI sujeitos ao gerenciamento; 5. gerenciamento de camada: de ne as informa c~ oes, servi cos e fun c~ oes do gerenciamento relacionado as v arias camadas do modelo OSI.
9.3.1 Contexto do Gerenciamento OSI
A gura na sequ^ encia mostra a arquitetura OSI para o gerenciamento de rede. Os elementos chaves desta arquitetura incluem: 1. processo de aplica c~ ao System Management Aplication Process - SMAP: e o software local respons avel pela execu c~ ao das fun c~ oes de gerenciamento de rede em um u nico sistema hospedeiro, processador front-end, roteador, etc.. Possui acesso aos par^ ametros do sistema e coordena a c~ oes com os outros SMAPs do sistema; 2. entidade de aplica ca ~o System Management Application Entity - SMAE: e respons avel pela comunica ca ~o com outros n os, especialmente com o centro de controle da rede NCC. Um protocolo padr~ ao, CMIP Common Management Information Protocol e utilizado para esta facilidade. A entidade de aplica c~ ao SMAE fornece um servi co comum de informa co ~es de gerenciamento Common Management Information Service - CMIS; 3. entidade de gerenciamento de camada Layer Management Entity - LME: l ogica e acrescida a cada camada da arquitetura OSI para fornecer fun c~ oes de gerenciamento espec
cas de cada camada; 4. base de informa c~ oes de gerenciamento Management Information Base - MIB: cole ca ~o de informa c~ oes, situada em cada n o, pertencentes ao gerenciamento da rede. Os elementos ilustrados na gura anterior devem ser implementados de forma distribu
da em todos os sistemas que est~ ao sujeitos ao gerenciamento de rede. As intera c~ oes que ocorrem entre os sistemas est~ ao ilustradas, de forma abstrata, na gura a seguir.
DCA-FEEC-UNICAMP
136
Processo de Aplicao do Sistema de Gerenciamento (SMAP) Interface do Sistema de Gerenciamento (SMI) Entidade de Aplicao do Sistema de Gerenciamento (SMAE) Camada de Apresentao Camada de Sesso Camada de Transporte Camada de Rede
LME LME Base de Informaes de Gerenciamento (MIB) LME LME LME LME LME
CMIP
Camada de Enlace Camada Fsica
LME = Entidade de Gerenciamento de Camada Interface do Gerenciamento da Camada (LMI) CMIP = Protocolo Comum de Informaes
Figura 9.2: Modelo da Arquitetura do Gerenciamento OSI As atividades de gerenciamento s~ ao realizadas atrav es da manipula c~ ao de objetos gerenciados. Cada sistema cont em um certo n umero destes objetos. Cada objeto e uma estrutura de dados que corresponde a uma entidade a ser gerenciada. O SMAP presente em um sistema pode possuir um dentre dois poss
veis pap eis: papel de agente ou papel de gerente. O SMAP possui o papel de gerente em um sistema que atua como gerente de rede ou centro de controle da rede. O gerente envia requisi co ~es de informa c~ ao e comandos de opera ca ~o para execu ca ~o nos sistemas gerenciados. Em cada sistema gerenciado o processo agente, respons avel pela ger^ encia dos objetos locais, interage com o gerente.
9.3.2 Fun c~ oes de Gerenciamento
Um conjunto de padr~ oes tem sido publicado na categoria denominada fun c~ oes de gerenciamento Systems Management Functions - SMF. Cada padr~ ao SMF de ne a funcionalidade necess aria para suportar os requisitos da a rea funcional do gerenciamento do sistema System Management Function Area - SMFA. As areas funcionais, descritas anteriormente, s~ ao:gerenciamento de falha,gerenciamento de contabilidade, gerenciamento de con gura c~ ao, gerenciamento de desempenho e gerenciamento de seguran ca. Uma determinada SMF pode
DCA-FEEC-UNICAMP
137
SISTEMA DE GERENCIAMENTO
Processo Gerente
Requisies/ Operaes de Gerenciamento
Respostas / Notificaes de Gerenciamento
Processo Agente
Outros sistemas gerenciados
= Objeto Gerenciado (pode conter outros objetos)
Figura 9.3: Intera c~ oes no Sistema de Gerenciamento suportar requisitos em uma ou mais das cinco SMFAs, por exemplo: a fun c~ ao de gerenciamento voltada a elabora c~ ao de eventos pode ser aplic avel a todas as SMFAs . Cada uma das SMFAs requer v arias SMFs. Cada padr~ ao SMF de ne a funcionalidade da SMF e fornece um mapeamento entre os servi cos fornecidos pela SMF e os servi cos de informa c~ ao de gerenciamento comum CMIS. A gura a seguir ilustra estas rela c~ oes.
9.3.3 Estrutura da Informa c~ ao de Gerenciamento
A base da atividade de gerenciamento dos sistemas e a base de informa c~ oes de gerenciamento MIB que possui a representa ca ~o de todos os recursos do sistema de gerenciamento. A estrutura da informa c~ ao de gerenciamento Structure of Management Information - SMI de ne o contexto geral na qual a MIB pode ser de nida e construida. O SMI identi ca os tipos de dados que podem ser usados na MIB e como os recursos dentro da MIB s~ ao representados e nomeados. O gerenciamento de sistemas OSI baseia-se fortemente nos conceitos de projeto orientado a objetos. Cada recurso monitorado e controlado pelo gerenciamento OSI e
DCA-FEEC-UNICAMP

reas Funcionais de Gerenciamento (SMFAs)
138
Gerenciamento de falha
Gerenciamento de contabilidade
Gerenciamento de configurao
Gerenciamento de desempenho
Gerenciamento de segurana
Gerenciamento de objeto
Gerenciamento de estado
Relatrio de alarme
Relatrio de eventos
Controle de registro (log)
Alarme de segurana
Auditoria de segurana
Controle de acesso
Monitoramento de carga
Gerenciamento de teste
Resumo
Gerenciamento de contabilidade
Gerenciamento de desempenho Funes de Gerenciamento de Sistema
Initialize
Event Report
Terminate
Action
Create
Abort
Delete
Get Set
Servios CMISE
Figura 9.4: Vis~ ao Geral dos Sistemas de Gerenciamento representado por um objeto gerenciado. Este objeto pode ser de nido para qualquer recurso que uma organiza c~ ao deseje monitorar e ou controlar. Exemplos de recursos de hardware s~ ao: chaves switches, esta c~ oes de trabalho, PBXs, porta de placa de rede local, multiplexadores, etc. Exemplos de recursos de software s~ ao: algoritmos de roteamento, rotinas de gerenciamento de armazenamento, etc. Objetos gerenciados relativos a recursos espec
cos de uma camada s~ ao denominados objetos gerenciados da camada-N. Objetos gerenciados relativos a recursos que englobam mais de uma camada denominam-se objetos gerenciados de sistema. Um objeto gerenciado e de nido em termos dos atributos que ele possui, das opera c~ oes que podem ser realizadas sobre ele, das noti ca c~ oes que ele pode enviar e das rela c~ oes com outros objetos gerenciados. De modo a estruturar a de ni ca ~o de uma MIB, cada objeto gerenciado e uma inst^ ancia de uma classe de objeto gerenciado. Esta classe e um modelo para as inst^ ancias do objeto gerenciado que compartilham os mesmos atributos, noti ca c~ ao e opera c~ oes de gerenciamento. A de ni c~ ao de uma classe de objeto gerenciado consiste em:
DCA-FEEC-UNICAMP
139
atributos vis
veis na interface do objeto; opera c~ oes de gerenciamento que podem ser aplicadas ao objeto; comportamento exibido pelo objeto gerenciado em resposta as opera c~ oes de gerenciamento; noti ca c~ oes que podem ser emitidas pelo objeto. Atributos: os dados reais contidos em um objeto gerenciado s~ ao denominados atributos. Cada atributo traduz uma propriedade de recurso que o objeto representa como, por exemplo, caracter
sticas operacionais, estado atual ou condi c~ oes de opera ca ~o. O tipo de dado de um atributo pode ser inteiro, real, booleano, cadeia de caracteres ou algum tipo composto constru
do a partir de tipos b asicos. Um atributo pode ter um u nico valor ou um conjunto de valores. Em adi ca ~o ao tipo de dado, cada atributo possui regras de acesso leitura, escrita, leitura escrita e regras pelas quais ele pode ser localizado como resultado de uma busca. Opera co ~es: as opera c~ oes de gerenciamento aplicam-se aos atributos de um objeto ou ao objeto gerenciado como um todo. Uma opera c~ ao realizada em um objeto gerenciado pode ter sucesso somente se o sistema de gerenciamento que est a evocando a opera ca ~o possui autoriza c~ ao necess aria para realizar a opera c~ ao e as restri c~ oes de consist^ encia n~ ao s~ ao violadas. Comportamento: um objeto gerenciado exige certas caracter
sticas de comportamento, incluindo a forma como o objeto reage a opera c~ oes realizadas sobre ele e as restri c~ oes associadas ao seu comportamento. O comportamento do objeto ocorre em resposta a um est
mulo tanto externo como interno. Est
mulos externos traduzem-se em opera c~ oes de gerenciamento liberadas na forma de mensagens CMIP. Est
mulos internos s~ ao eventos internos ao objeto gerenciado e aos seus recurso tal como, por exemplo, o temporizador associado ao objeto. Noti ca c~ oes: objetos gerenciados emitem noti ca c~ oes quando alguma ocorr^ encia interna ou externa que afete o sistema e detetada. Noti ca c~ oes podem ser transmitidas externamente atrav es de um protocolo ou ent~ ao ser arquivadas logged. Sistemas de gerenciamento podem requisitar que algumas, ou todas, as noti ca c~ oes emitidas por um objeto gerenciado lhes sejam enviadas. Noti ca c~ oes que s~ ao enviadas a um gerente est~ ao contidas em um relat orio de evento event report. O CMIS de ne os servi cos suportados pelo gerenciamento de sistemas OSI. Estes servi cos s~ ao evocados pelos processos de gerenciamento para comunicar remotamente. Estes servi cos s~ ao de dois tipos: servi cos con rmados e servi cos n~ ao-con rmados. No primeiro caso, e necess ario que o processo de gerenciamento remoto envie uma resposta para indicar a recep c~ ao e o sucesso falha da opera c~ ao requisitada; no segundo caso n~ ao h a o envio de respostas. Tr^ es categorias de servi cos s~ ao relevantes para o CMIS: 1. servi cos de associa c~ ao: os usu arios do CMIS necessitam estabelecer uma associa c~ ao de aplica ca ~o para comunica c~ ao. O usu ario CMIS baseia-se, neste caso, no elemento de servi co de controle de associa c~ ao Association Control Service Element- ACSE, que e uma entidade de aplica ca ~o OSI separada, para controle das associa c~ oes de aplica ca ~o;
9.3.4 Servi co Comum de Informa c~ ao de Gerenciamento CMIS
DCA-FEEC-UNICAMP
140
2. servi co de noti ca c~ ao de gerenciamento: este servi co e usado para transportar informa ca ~o de noti ca c~ ao. A de ni c~ ao de uma noti ca c~ ao e o consequente comportamento das entidades de comunica c~ ao s~ ao dependentes da especi ca ca ~o do objeto gerenciado que gerou a noti ca ca ~o, especi ca c~ ao esta que se encontra fora do escopo do CMIS. Primitiva do servi co de noti ca c~ ao: Servi co: M-EVENT-REPORT; Tipo: con rmado n~ ao con rmado; De ni c~ ao: relata um evento sobre um objeto gerenciado a um usu ario par do servi co CMIS. 3. servi co de opera c~ ao de gerenciamento: existem seis servi cos que s~ ao utilizados para transportar informa c~ oes de gerenciamento associadas as opera c~ oes de gerenciamento. A de ni c~ ao da opera ca ~o e o consequente comportamento das entidades de comunica ca ~o s~ ao dependentes da especi ca c~ ao do objeto gerenciado para o qual a opera c~ ao e dirigida estando tamb em fora do escopo do CMIS. Primitivas de servi cos de opera c~ ao: Servi co: M-GET; Tipo: con rmado, De ni c~ ao: requisita informa c~ ao de gerenciamento de um usu ario par do servi co CMIS; Servi co: M-SET; Tipo: con rmado n~ ao con rmado; De ni ca ~o : requisita a modica c~ ao da informa c~ ao de gerenciamento por parte de um usu ario par de um servi co CMIS; Servi co: M-ACTION; Tipo: con rmado n~ ao con rmado, De ni ca ~o: requisita a um usu ario par do servi co CMIS a realiza c~ ao de uma a c~ ao; Servi co: M-CREATE; Tipo: con rmado, De ni c~ ao: requisita a um us ario par do servi co CMIS para criar uma inst^ ancia de um objeto gerenciado; Servi co: M-DELETE; Tipo: con rmado, De ni c~ ao: requisita a um usu ario par do servi co CMIS para deletar uma inst^ ancia de um objeto gerenciado; Servi co: M-CANCEL-GET; Tipo: con rmado, De ni c~ ao: requisita a um usu ario par do servi co CMIS para cancelar uma requisi c~ ao previamente solicitada e aguarda a evoca c~ ao de um servi co M-GET; O CMIS fornece 2 facilidades de estrutura c~ ao: 1. m ultiplas respostas a uma opera c~ ao con rmada podem ser associadas a uma opera c~ ao atrav es do uso de um par^ ametro de identi ca c~ ao de liga c~ ao; 2. opera c~ oes podem ser realizadas em m ultiplos objetos gerenciados, selecionados segundo algum crit erio e seguindo a condi c~ ao de sincroniza c~ ao. As primitivas de servi co M-GET, M-SET, M-ACTION e M-DELETE incluem um par^ ametro para selecionar os objetos a serem usados na opera c~ ao. A sele c~ ao dos objetos envolve tr^ es conceitos: escopo, ltragem e sincroniza c~ ao. Estas tr^ es facilidades s~ ao fornecidas como par^ ametros. Escopo: refere-se a identi ca c~ ao de um objeto ou objetos para o qual um ltro e aplicado. O escopo refere-se a uma base de objetos gerenciados. Esta base eo ponto de partida para a sele c~ ao de um ou mais objetos a partir da aplica c~ ao do ltro. Usando a base de objeto como raiz, uma sub- arvore e obtida a partir da a rvore global de objetos;
DCA-FEEC-UNICAMP
141
Filtragem: trata-se de uma express~ ao booleana, contendo uma ou mais asser c~ oes sobre a
presen ca ou valores de atributos de um objeto gerenciado. Cada asser c~ ao pode ser um teste de igualdade, ordem, presen ca ou compara c~ ao de um conjunto. A ltragem e aplicada em todos os objetos gerenciados selecionados pelo par^ ametro do escopo e somente os objetos que atendem ao ltro s~ ao selecionados para a realiza c~ ao da opera c~ ao Sincroniza c~ ao: o par^ ametro de escopo pode resultar na sele c~ ao de mais de um objeto gerenciado a ser submetido a ltragem. A quest~ ao que se coloca diz respeito ao fato de que a ordem na qual estes objetos ser~ ao selecionados pelo ltro n~ ao e especi cada deixada como quest~ ao de implementa c~ ao local. O usu ario do servi co CMISE pode requisitar dois tipos de sincroniza c~ ao: 1. at^ omica: todos os objetos gerenciados selecionados para a opera c~ ao s~ ao tratados para detetar se eles est~ ao aptos a realiza c~ ao com sucesso da opera c~ ao. Caso um ou mais objetos n~ ao estejam aptos, nenhuma opera c~ ao e realizada; 2. melhor esfor co: todos os objetos selecionados s~ ao solicitados a realizarem a opera ca ~o.
9.3.5 Protocolo de Gerenciamento Comum de Informa c~ ao Common Management Information Protocol - CMIP
O CMIP suporta os servi cos fornecidos pelo gerenciamento de sistemas OSI atrav es de um conjunto de entidades de dado de protocolo que implementam o CMIS. Estas PDUs s~ ao transmitidas em resposta as primitivas de servi co do CMIS enviada pelos usu arios do servi co CMIS.
9.4 Problemas
1. Quais os requisitos que a atividade de gerenciamento de rede deve atender ? Descreva brevemente cada um deles. 2. Quais os elementos que comp~ oem um sistema de gerenciamento de redes ? 3. Qual a arquitetura necess aria para o gerenciamento OSI ? 4. Quais os elementos funcionais que comp~ oem a arquitetura de gerenciamento OSI ? 5. Quais as funcionalidades do CMIS ?
Ap^ endice A Per l OSI Governamental GOSIP

Os maiores compradores de computadores e redes de comunica c~ ao s~ ao os o rg~ aos governa mentais, principalmente os do governo federal norte-americano. E natural que cada o rg~ ao d^ e prefer^ encia a uma arquitetura de rede que melhor atenda a s suas necessidades. Surge ent~ ao um problema: como interligar os diversos org~ aos governamentais para ns de troca de informa c~ oes t ecnicas e administrativas ? O governo federal norte-americano publicou uma recomenda c~ ao em 1988 no sentido de padronizar uma arquitetura m
nima de interconex~ ao de computadores. O t
tulo da recomenta c~ ao, Goverment Open Systems Interconection Pro le, gerou um termo comumente associado a publica c~ oes semelhantes: GOSIP. A gura A.1 ilustra os componentes da especi ca c~ ao GOSIP norte-americana. Existem tr^ es vers~ oes desta especi ca c~ ao: vers~ ao 1 est avel; vers~ ao 2 proposta e vers~ ao 3 futura. Uma observa c~ ao importante e a agrega c~ ao das camadas de sess~ ao e apresenta ca ~o a camada 1 de aplica c~ ao isto e, os servi cos de sess~ ao e apresenta ca ~o est~ ao embutidos na aplica c~ ao que por sua vez acessa diretamente o servi co de transporte. No Brasil, o Decreto 518 de 8 de maio de 1992 estabelece o POSIG Per l OSI do Governo Brasileiro. A gura A.2 ilustra os componentes do POSIG.
Esta estrutura c~ ao reduz as sete camadas do modelo OSI as quatro camadas da arquitetura TCP IP.
142
DCA-FEEC-UNICAMP
143
ODA ISO 8613
EDI ANSI X12
MHS X.400 1984
FTAM ISO 8571
VT ISO 9041
MHS X.400 1988
DS X.500
NET MGMT
FTAM EXT.
ROSE ROSE RTSE ROSE
APLICAO
ACSE
ACSE
ACSE
ACSE
ACSE
APRESENTAO
ISO 8823
APRESENTAO
SESSO
ISO 8327
SESSO
TRANSPORTE CLASSE 0 ISO 8073
TRANSPORTE CLASSE 4 ISO 8073 PROTOCOLO DE REDE SEM CONEXO ISO 8473 ES-IS ISO 9542 IS-IS
TRANSP. SEM CONEXO ISO 8602
TRANSPORTE
CONS ISO 8348 X.25 PLP
ISDN CCITT Q.921
REDE
IEEE 802.2 LLC Tipo 1, Classe 1 IEEE 802.3 IEEE 802.4 IEEE 802.5
HDLC LAPB ISO 7776 ANSI X3T9.5 FDDI
ISDN LAPD CCITT Q.921 ISDN ISO 1430/1
ENLACE
RS-232
V.35
FSICA
Legenda: Verso 1 Verso 2 Verso 3
Figura A.1: GOSIP Government Open Systems Interconection Pro le norte-americano.
DCA-FEEC-UNICAMP
144
ODA ISO 8613
EDI ANSI X12
MHS X.400 1984
FTAM ISO 8571
VT ISO 9041
MHS X.400 1988
DS X.500 EDIM X.435 ROSE XF.345
FTAM EXT.
ROSE RTSE
APLICAO
ACSE
ACSE
ACSE
ACSE
ACSE
APRESENTAO
ISO 8823
APRESENTAO
SESSO
ISO 8327
SESSO
TRANSPORTE CLASSES 0, 2, 4 ISO 8073 PROTOCOLO DE REDE SEM CONEXO ISO 8473 CONS ISO 8348 IEEE 802.2 LLC Tipo 1, Classe 1 IEEE 802.3 IEEE 802.5 ANSI X3T9.5 FDDI ES-IS ISO 9542 HDLC LAPB ISO 7776 ISDN
TRANSPORTE
X.25 PLP
REDE
ENLACE
RS-232
X.21 bis
V.35
FSICA
Legenda: Atual Futuro
Figura A.2: POSIG Per l OSI do Governo Brasileiro.
Ap^ endice B DECnet OSI

DECnet Fase V ou DECnet OSI e uma implementa c~ ao da pilha OSI ISO comercializada pela Digital Equipment Corp. A gura B.1 ilustra os protocos OSI implementados, bem como os protocolos da vers~ ao anterior fase IV mantidos para ns de interoperabilidade.
DECnet/OSI
APLICAO APRESENTAO SESSO TRANSPORTE REDE ENLACE X.25 ACSE Protocolos FASE IV
ROSE
FTAM
VT DAP
PROTOCOLO OSI DE APRESENTAO PROTOCOLO OSI DE SESSO TP0 CONS HDLC RS-232C RS-242 RS-243 TP2 CLNS TP4 NSP ES-IS DDCMP CONTROLE DE SESSO
IEEE 802.2 (LLC) Ethernet Token Ring FDDI
FSICA
V.24 V.25 V.35
Figura B.1: Arquitetura DECnet OSI. O n

vel f
sico implementa as interfaces RS-232-C, RS-422, RS-423, V.35 e redes Ethernet, token Ring e FDDI. O n
vel de enlace implementa os protocolos HDLC LAPB utilizados no X.25 e 802.2 LLC utilizados nas LANs Ethernet, Token Ring e FDDI. O n
vel de rede implementa os protocolos de rede X.25 PLP, CONS Connection Oriented Network Service1 e CLNS Connectionless Mode Network Service; al em do protocolo ES-IS de roteamento. O n
vel de transporte implementa os protocolos OSI orientados a conex~ ao de classe 0, 2 e 4; al em do protocolo NSP presente na DECnet Fase IV.
1
Implementado sobre o X.25.
145
DCA-FEEC-UNICAMP
146
O n
vel de sess~ ao implementa o protocolo ISO de sess~ ao orientado a conex~ ao; al em do protocolo DNA da Fase IV. O n
vel de apresenta c~ ao implementa o protocolo de OSI apresenta c~ ao orientado a conex~ ao que oferece basicamente os mesmos servi cos de sess~ ao. Finalmente o n
vel de aplica ca ~o implementa os elementos ACSE Association Control Service Element e ROSE Remote Operations Service Element, bem como os servi cos FTAM File Transfer Access and Management e VT Virtual Terminal.

Osi

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Osi

Enviado por

Direitos autorais:

Formatos disponíveis

REDES DE COMPUTADORES: MODELO OSI X.

c 1995,1996 DCA FEEC UNICAMP

Redes de Computadores: Modelo OSI X.25

tica : : : : : : : 2.8.3 Fibra O 2.9 Componentes da Camada F

Redes de Computadores: Modelo OSI X.25

Redes de Computadores: Modelo OSI X.25

A Per l OSI Governamental GOSIP B DECnet OSI

1.1 Conceitos B asicos

Redes de Computadores: Modelo OSI X.25

1.2 Aplica co ~es T

Redes de Computadores: Modelo OSI X.25

1.3 Estruturas de Redes

fronteira da subrede de comunicao IMP subrede de comunicao HOST

1.4 Padroniza c~ ao de Redes

Tamb em denominadas pacotes. Tamb em denominadas comuta c~ ao de pacotes.

Redes de Computadores: Modelo OSI X.25

rvore, Figura 1.2: Topologias t

Redes de Computadores: Modelo OSI X.25

Figura 1.3: Topologias t

Open Systems Interconnection Abrevia c~ ao de interconnected networks.

Redes de Computadores: Modelo OSI X.25

1.5 Estrutura c~ ao de Redes em Camadas

Redes de Computadores: Modelo OSI X.25

protocolo da camada 5 CAMADA 5 CAMADA 5

protocolo da camada 4 CAMADA 4 CAMADA 4

protocolo da camada 3 CAMADA 3 CAMADA 3

protocolo da camada 2 CAMADA 2 CAMADA 2

protocolo da camada 1 CAMADA 1 CAMADA 1

Figura 1.4: Camadas, protocolos e interfaces numa rede de computadores.

1.6 O modelo OSI

Redes de Computadores: Modelo OSI X.25

protocolo de transporte 4 TRANSPORTE subrede de comunicao PDU TRANSPORTE

COMUNICAO 2 ENLACE ENLACE quadro ENLACE ENLACE IMP-IMP HOST-IMP

Figura 1.5: O modelo OSI.

1.6.2 A Camada de Enlace

A camada de enlace utiliza a camada f

Redes de Computadores: Modelo OSI X.25

1.6.3 A Camada de Rede

1.6.4 A Camada de Transporte

1.6.5 A Camada de Sess~ ao

1.6.6 A Camada de Apresenta c~ ao

Redes de Computadores: Modelo OSI X.25

1.6.7 A Camada de Aplica c~ ao

1.7 Servi cos

Redes de Computadores: Modelo OSI X.25

1.7.1 Servi cos Conectados e Sem Conex~ ao

Redes de Computadores: Modelo OSI X.25

Entidade-(N) Protocolo-(N) SAP-(N-1) Camada-(N)

Redes de Computadores: Modelo OSI X.25

conex~ ao suportados pela camada-N .

1.7.2 Identi cadores

O su xo N  usado acima indica que os identi cadores possuem signi cado no n

1.7.3 Unidades de Dados

Redes de Computadores: Modelo OSI X.25

Redes de Computadores: Modelo OSI X.25

Figura 1.8: Mapeamento de PDUs em SDUs.

1.7.4 Primitivas para Requisi c~ ao de Servi cos

Redes de Computadores: Modelo OSI X.25

Figura 1.9: Segmenta c~ ao e Remontagem.

Redes de Computadores: Modelo OSI X.25

Figura 1.10: Bloqueio e Desbloqueio.

Figura 1.11: Concatena c~ ao e Separa c~ ao.

1.8.1 Especi ca c~ ao de Protocolo

Redes de Computadores: Modelo OSI X.25

A Per l OSI Governamental GOSIP B DECnet OSI

1.2 Aplica co ~es T

1.4 Padroniza c~ ao de Redes

Tamb em denominadas pacotes. Tamb em denominadas comuta c~ ao de pacotes.

Open Systems Interconnection Abrevia c~ ao de interconnected networks.

1.5 Estrutura c~ ao de Redes em Camadas

1.6.6 A Camada de Apresenta c~ ao

1.6.7 A Camada de Aplica c~ ao

1.7 Servi cos

1.7.1 Servi cos Conectados e Sem Conex~ ao

conex~ ao suportados pela camada-N .

O su xo N usado acima indica que os identi cadores possuem signi cado no n

1.7.4 Primitivas para Requisi c~ ao de Servi cos

Figura 1.9: Segmenta c~ ao e Remontagem.

Figura 1.11: Concatena c~ ao e Separa c~ ao.

1.8.1 Especi ca c~ ao de Protocolo

Requisi ca ~o Indica c~ ao Resposta Con rma c~ ao

2.2 Codi ca c~ ao de Sinais Digitais

2.3 Modula c~ ao de Sinais Digitais

2.6 Fontes de Distor c~ ao do Sinal

Distor c~ ao por Atraso de Propaga c~ ao

Figura 2.8: Erro de detec c~ ao devido ao ru

2.8.1 Par Tran cado Met alico

Figura 2.12: Atenua c~ ao da amplitude por quilometro em fun ca ~o da frequ^ encia.

3.1 A Subcamada de Acesso ao Meio MAC