Arquitetura de Redes de Computadores

SUMÁRIO
CAPÍTULO 1 INTRODUÇÃO ÀS REDES DE COMUNICAÇÃO
1. Histórico das Redes de Comunicação.................................................................1.1

2. Importância das Redes de Comunicação ............................................................1.2
3. Extensão e Topologia............................................................................................1.2
4. Aspectos Arquiteturais ..........................................................................................1.4
5. Tecnologias de Transmissão de Dados...............................................................1.9
CAPÍTULO 2 O MODELO DE REFERÊNCIA OSI
1. Introdução..............................................................................................................2.1
2. Fundamentos e Arquitetura...................................................................................2.1
3. Serviços e Protocolos ...........................................................................................2.3
4. A Arquitetura OSI e as Funções das Camadas ...................................................2.4
5. A Comunicação no OSI ........................................................................................2.7
6. Os Conceitos do Modelo OSI ...............................................................................2.7
7. As Primitivas de Serviço.....................................................................................2.10
CAPÍTULO 3 AS SETE CAMADAS DO MODELO OSI
1. Introdução..............................................................................................................3.1
2. A Camada Física ..................................................................................................3.1
3. A Camada de Enlace de Dados ...........................................................................3.5
4. A Camada de Rede.............................................................................................3.10
5. A Camada de Transporte....................................................................................3.16
6. A Camada de Sessão.........................................................................................3.21
7. A Camada de Apresentação...............................................................................3.28
8. A Camada de Aplicação......................................................................................3.36
—i—
ARQUITETURA DE REDES DE COMPUTADORES — SUMÁRIO PROF. VITÓRIO BRUNO MAZZOLA
CAPÍTULO 4 AS REDES LOCAIS
1. Introdução..............................................................................................................4.1
2. Classificação das Redes de Computadores........................................................4.1
3. Parâmetros de Comparação ................................................................................4.2
4. Características das Redes Locais .......................................................................4.3
5. Histórico ................................................................................................................4.4
6. Definições Básicas ...............................................................................................4.4
7. RM-OSI e as Redes Locais ..................................................................................4.5
8. Os Sistemas Operacionais de Rede....................................................................4.6
9. O Padrão IEEE 802...............................................................................................4.7
10. Ethernet 802.3.....................................................................................................4.10
11. A Rede Local Ethernet ........................................................................................4.12
12. Configuração da Ethernet ...................................................................................4.15
13. Fast Ethernet.......................................................................................................4.15
14. Token Ring e IEEE 802.5....................................................................................4.16
15. Cabeamento Estruturado....................................................................................4.18
CAPÍTULO 5 REDES LOCAIS INDUSTRIAIS
1. Introdução..............................................................................................................5.1
2. Níveis Hierárquicos da Integração Fabril ..............................................................5.1
3. As Redes na Empresa..........................................................................................5.2
4. Aspectos da Comunicação em Ambiente Industrial.............................................5.2
5. Características Básicas das Redes Industriais ...................................................5.4
6. Projetos de Padronização de Redes Industriais ..................................................5.6
7. Projeto MAP...........................................................................................................5.7
8. Redes Fieldbus ...................................................................................................5.16
CAPÍTULO 6 INTERCONEXÃO DE REDES
1. Introdução..............................................................................................................6.1
2. Aspectos da Conectividade ..................................................................................6.2
3. A Interconexão segundo o Modelo OSI.................................................................6.3
4. As Diferentes Possibilidades de Interconexão .....................................................6.4
5. As Pontes ..............................................................................................................6.4
6. Os Roteadores......................................................................................................6.6
7. As Passarelas .......................................................................................................6.8
— ii —
ARQUITETURA DE REDES DE COMPUTADORES — SUMÁRIO PROF. VITÓRIO BRUNO MAZZOLA
CAPÍTULO 7 ENGENHARIA DE PROTOCOLOS
1. Introdução..............................................................................................................7.1
2. As Etapas de Concepção dos Protocolos de Comunicação...............................7.1
3. Especificação de Protocolos de Comunicação ...................................................7.2
4. A Validação de Protocolos de Comunicação .....................................................7.11
5. A Implementação dos Protocolos de Comunicação ..........................................7.19
6. O Teste de Protocolos de Comunicação ...........................................................7.19
7. Conclusão .......................................................................................................... 7.20
CAPÍTULO 8 REDES DE PETRI
1. Introdução ........................................................................................................... 8.1

2. Redes de Petri — Definição Básica................................................................... 8.1
3. Propriedades das Redes de Petri ...................................................................... 8.6
4. Representação de Dados e de Aspectos Temporais...................................... 8.12
5. Redes de Petri Coloridas ................................................................................. 8.15
6. Redes de Petri Predicados-Transições ........................................................... 8.18
7. Redes de Petri Temporizadas ......................................................................... 8.21
8. Redes de Petri Temporais ............................................................................... 8.22
9. Conclusão......................................................................................................... 8.24
CAPÍTULO 9 A TÉCNICA ESTELLE
1. Introdução..............................................................................................................9.1
2. As Técnicas de Descrição Formal Padronizadas................................................9.1
3. A Técnica de Descrição Formal Estelle ...............................................................9.2
4. Os Trabalhos Realizados em torno de Estelle...................................................9.18
CAPÍTULO 10 ESTADO DA ARTE EM REDES
1. Introdução............................................................................................................10.1
2. A Rede Digital de Serviços Integrados - ISDN....................................................10.1
3. A Rede FDDI.......................................................................................................10.8
4. A Pesquisa em Redes de Comunicação - Estado da Arte ................................10.9
BIBLIOGRAFIA............................................................................................................... B.1
— iii —
Capítulo 1
AS REDES DE COMPUTADORES
1. HISTÓRICO DAS REDES DE COMUNICAÇÃO
A evolução da microeletrônica e da informática tem possibilitado a obtenção de

processadores e outros componentes de computadores cada vez mais potentes e velozes,
num tamanho mais reduzido e num preço cada vez mais acessível a um maior número de
pessoas.
Os microprocessadores existentes hoje em dia e que ocupam o espaço menor do
que uma caixa de fósforos substituem e ultrapassam as capacidades dos computadores de
alguns anos atrás, que ocupavam salas inteiras. Estes eram máquinas bastante complexas
no que diz respeito à sua utilização e que ficavam em salas isoladas onde muito poucas
pessoas tinham acesso, sendo operadas apenas por especialistas (analistas de sistema).
Os usuários daqueles computadores normalmente submetiam seus programas aplicativos
como jobs (ou tarefas) que executavam sem qualquer interação com o processamento do
programa.
Uma primeira tentativa de interação com o computador ocorreu no início dos anos 60,
com a técnica de time-sharing, que foi o resultado do desenvolvimento das tele-impressoras
e da tecnologia de transmissão de dados. Nesta técnica um conjunto de terminais era
conectado a um computador central através de linhas de comunicação de baixa velocidade,
o que permitia aos usuários interagir com os seus programas. A necessidade de conexão de
terminais para o processamento interativo foi o ponto de partida para o estabelecimento de
necessidades de comunicação nos computadores. A técnica de time-sharing permitia a um
grande conjunto de usuários o compartilhamento de um único computador para a resolução
de uma grande diversidade de problemas e as aplicações desenvolvidas foram cada vez
mais se multiplicando e se diversificando (cálculos complexos, produção de relatórios,
ensino de programação, aplicações militares, etc...). Este aumento na demanda implicava
numa necessidade crescente de atualizações e incrementos nas capacidades de cálculo e
de armazenamento nas unidades central o que nem sempre era viável ou possível, dado que
os computadores do tipo mainframes nem sempre eram adaptados para suportar
determinadas extensões.
Nos anos 70, com o surgimento dos minicomputadores, foi possível adaptar as
capacidades de processamento às reais necessidades de uma dada aplicação. Além disso,
dado que a nível de uma empresa um grande número de usuários operavam sobre
conjuntos comuns de informações, a necessidade do compartilhamento de dados, de
dispositivos de armazenamento e de periféricos entre os vários departamentos de uma
empresa deu um novo impulso aos trabalhos no sentido de se resolver os problemas de
comunicação entre os computadores. Este novo tipo de aplicações exigia uma velocidade e
uma capacidade de transmissão muito mais elevadas que no caso da conexão de terminais
a um computador central. Assim, com a utilização de minicomputadores interconectados,
obtinha-se uma capacidade de processamento superior àquela possível com a utilização dos
mainframes. Outro aspecto interessante é que as redes podiam ser estendidas em função
— 1.1 —
CAP. 1 – I NTRODUÇÃO ÀS REDES DE COMPUTADORES PROF. VITÓRIO BRUNO MAZZOLA
das necessidades de processamento das aplicações. Além disso, a modularidade natural

das redes de computadores era tal que uma falha num minicomputador (ou de comunicação
da rede) tinha um efeito bastante limitado em relação ao processamento global.
Atualmente, as vantagens dos sistemas distribuídos e interconectados são uma
evidência reconhecida para as aplicações mais diversas, desde a automação de escritórios
até o controle de processos, passando por aplicações de gerenciamento bancário, reservas
de passagens aéreas, processamento de texto, correio eletrônico, etc...
2. IMPORTÂNCIA DAS REDES DE COMUNICAÇÃO
Um grande número de empresas possui atualmente uma quantidade relativamente

grande de computadores operando nos seus diversos setores. Um exemplo deste fato é
aquele de uma empresa que possui diversas fábricas contendo cada uma um computador
responsável das atividades de base da fábrica (controle de estoques, controle da produção
e, o que também é importante, a produção da folha de pagamentos). Neste exemplo, apesar
da possibilidade de operação destes computadores de maneira isolada, é evidente que sua
operação seria mais eficiente se eles fossem conectados para, por exemplo, permitir o
tratamento das informações de todas as fábricas da empresa. O objetivo da conexão dos
diferentes computadores da empresa é permitir o que poderíamos chamar de
compartilhamento de recursos, ou seja, tornar acessíveis a cada computador todos os
dados gerados nas diversas fábricas da empresa.
Um outro ponto importante da existência das Redes de Comunicação é relacionado a
um aumento na confiabilidade do sistema como um todo. Pode-se, por exemplo, ter
multiplicados os arquivos em duas ou mais máquinas para que, em caso de defeito de uma
máquina, cópias dos arquivos continuarão acessíveis em outras máquinas. Além disso, o
sistema pode operar em regime degradado no caso de pane de um computador, sendo que
outra máquina pode assumir a sua tarefa. A continuidade de funcionamento de um sistema é
ponto importante para um grande número de aplicações, como por exemplo: aplicações
militares, bancárias, o controle de tráfego aéreo, etc.
A redução de custos é uma outra questão importante da utilização das Redes de
Comunicação, uma vez que computadores de pequeno porte apresentam uma menor
relação preço/desempenho que os grandes. Assim, sistemas que utilizariam apenas uma
máquina de grande porte e de custo muito elevado podem ser concebidos à base da
utilização de um grande número de microcomputadores (ou estações de trabalho)
manipulando dados presentes num ou mais servidores de arquivos.
3. EXTENSÃO E TOPOLOGIA
3.1. Redes locais e redes de longa distância
Na seção anterior foram apresentados dois exemplos de implementação de Redes

de Comunicação: no primeiro caso, o sistema era composto de diversos computadores
espalhados cada um numa fábrica da empresa.
No segundo caso, o sistema era composto de diversos microcomputadores,
podendo todos estar localizados na mesma sala ou em salas vizinhas num mesmo edifício.
A diferença na dimensão das Redes de Comunicação introduz diferentes problemas
e necessidades e deve então, fazer objeto de uma classificação. No que diz respeito ao
exemplo dos microcomputadores, a rede é classificada como sendo uma Rede Local (ou
LAN - Local Área Network), caracterizada particularmente por uma pequena extensão,
limitando-se normalmente à interconexão de computadores localizados numa mesma sala,
num mesmo prédio ou num campus.
No exemplo da empresa possuindo diversas fábricas, a rede utilizada permitiria
conectar computadores localizados em diferentes prédios numa mesma cidade ou mesmo
— 1.2 —
em cidades distantes de uma dada região. Esta caracteriza uma Rede de Longa Distância
ou Rede Geograficamente Distribuída (ou WAN - Wide Área Network).
3.2. As diferentes topologias
Um ponto importante no que diz respeito à concepção de uma rede de comunicação

é a definição da maneira como as diferentes estações serão associadas. Inicialmente,
podemos distinguir dois tipos principais de concepção: os canais em modo ponto-a-ponto e
os canais de difusão.
Nos canais em ponto-a-ponto, a rede é composta de diversas linhas de
comunicação, cada linha sendo associada à conexão de um par de estações.
Neste caso, se duas estações devem se comunicar sem o compartilhamento de um
cabo, a comunicação será feita de modo indireto, através de uma terceira estação. Assim,
quando uma mensagem (ou pacote) é enviada de uma estação a outra de forma indireta (ou
seja, através de uma ou mais estações), ela será recebida integralmente por cada estação
e, uma vez que a linha de saída da estação considerada está livre, retransmitida à estação
seguinte.
Esta política de transmissão é também conhecida por “store and forward” ou
comutação de pacotes. A maior parte das redes de longa distância são do tipo ponto-a-
ponto.
As redes ponto-a-ponto podem ser concebidas segundo diferentes topologias. As
redes locais ponto-a-ponto são caracterizadas normalmente por uma topologia simétrica; as
redes de longa distância apresentam geralmente topologias assimétricas. A figura 1.1
apresenta as diferentes topologias possíveis nas redes ponto-a-ponto.
Uma outra classe de redes, as redes de difusão, são caracterizadas pelo
compartilhamento, por todas as estações, de uma linha única de comunicação. Neste caso,
as mensagens enviadas por uma estação são recebidas por todas as demais conectadas
ao suporte, sendo que um campo de endereço contido na mensagem permite identificar o
destinatário.
Na recepção, a máquina verifica se o endereço definido no campo corresponde ao
seu e, em caso negativo, a mensagem é ignorada. As redes locais pertencem geralmente a
esta classe de redes. Nas redes de difusão, existe a possibilidade de uma estação enviar
uma mesma mensagem às demais estações da rede, utilizando um código de endereço
especial; neste caso, todas as estações vão tratar a mensagem recebida.
Figura 1.1 - Topologias ponto-a-ponto: estrela, anel, malha regular, malha irregular e árvore.
— 1.3 —
Pode-se ainda especificar uma mensagem de modo que esta seja enviada a um
subgrupo de estações da rede. A figura 1.2 apresenta algumas topologias possíveis no caso
das redes a difusão. Numa rede em barramento, uma única máquina é autorizada a cada
instante a transmitir uma mensagem — é a estação mestre do barramento. As demais
estações devem esperar autorização para transmissão.
Para isto, um mecanismo de arbitragem deve ser implementado para resolver
possíveis problemas de conflito (quando duas ou mais estações querem enviar uma
mensagem), este mecanismo podendo ser centralizado ou distribuído.
No caso das redes de satélite (ou rádio), cada estação é dotada de uma antena
através da qual pode enviar e receber mensagens. Cada estação pode “escutar” o satélite e,
em alguns casos, receber diretamente as mensagens enviadas pelas demais estações.
No caso do anel, cada bit transmitido é propagado de maneira independente em
relação à mensagem (ou pacote) ao qual ele pertence. Em geral, cada bit realiza uma volta
completa do anel durante o tempo necessário para a emissão de um certo número de bits,
antes mesmo da emissão completa da mensagem.
Também nesta topologia, é necessária a implementação de um mecanismo de
acesso ao suporte de comunicação. Existem diferentes técnicas para este fim que serão
discutidas ao longo do curso.
As redes de difusão podem ainda considerar duas classes de mecanismos de
acesso ao suporte de comunicação: estáticas ou dinâmicas. Um exemplo do primeiro caso
é a definição de intervalos de tempo durante os quais cada estação tem a posse do canal de
comunicação, permitindo então que esta emita a mensagem de maneira cíclica. No entanto,
esta política é bastante ineficiente do ponto de vista do envio das mensagens, uma vez que
muitas estações não vão enviar mensagens nos intervalos a elas destinadas. Já na outra
classe de mecanismos, dinâmicos, o acesso é dado às estações segundo a demanda de
envio de mensagens. Nos mecanismos de acesso dinâmicos, pode-se ainda considerar dois
casos:
• os mecanismos centralizados, nos quais uma estação central (árbitro) é a
responsável da definição do direito de acesso ao suporte de comunicação;
• os mecanismos distribuídos, nos quais cada estação define quando ela vai
emitir a mensagem.
4. ASPECTOS ARQUITETURAIS
4.1. Serviços necessários à comunicação
Como visto nas seções precedentes, as redes de computadores podem se

caracterizar por diferentes configurações e topologias. Apesar da diversidade no que diz
respeito a este aspecto, todas as possíveis configurações têm um objetivo comum — a
transferência de dados.
Figura 1.2 - Topologias das redes de difusão: barramento, satélite e anel
— 1.4 —
O problema que se coloca é então relacionado à especificação dos procedimentos e

mecanismos que devem ser implementados para viabilizar o funcionamento da rede. A
resolução deste problema é baseada principalmente no conhecimento prévio das funções
que devem ser suportadas pela rede, assim como do ambiente no qual ela vai ser inserida.
Estes aspectos serão mostrados aqui através de alguns exemplos. O primeiro exemplo é
baseado nas políticas de time-sharing já descrita na seção 1. Vamos considerar o caso em
que temos apenas um terminal conectado a um computador, como mostrado na figura 1.3.
Considerando que um usuário vai servir-se do terminal para processar informações
no computador central, para que isto seja possível, é necessário que o computador central
seja dotado do programa necessário ao tratamento daquelas informações. Em caso positivo,
o terminal e o computador devem estabelecer um diálogo que permita o bom desenrolar das
operações de tratamento das informações. Este diálogo deverá permitir, por exemplo, que o
usuário comunique sua intenção (de processar as informações!) ao computador e, em
seguida, envie as informações a serem processadas. Uma vez efetuado o tratamento, o
computador deve retornar os resultados ao terminal.
Esta seqüência de operações, apesar de aparentemente elementar, requer a
satisfação de uma série de condições. Vamos supor, por exemplo, que o computador central
e o terminal tenham sido fabricados de forma totalmente independente um do outro, o que
pode ter resultado numa diferente filosofia no que diz respeito ao formato das informações.
Um primeiro obstáculo a ser vencido é aquele da linguagem; o terminal deveria então
se adaptar à linguagem do computador central.
Resolvido o problema de compreensão, um outro problema encontrado diz respeito
aos possíveis erros de transmissão que podem ocorrer durante a comunicação, uma vez
que as linhas de comunicação estão sujeitas a ruídos e outros fenômenos podendo provocar
perdas de informação.
Uma outra questão pode ainda estar relacionada à velocidade de funcionamento dos
dois elementos. Se considerarmos que o computador central opera numa velocidade
superior à do terminal, por exemplo, o terminal corre o risco de ser “bombardeado” pelo fluxo
de dados vindo do computador, o que vai exigir então o estabelecimento de um mecanismo
de controle do fluxo de informação.
Resumindo, a rede de comunicação deve, além de suprir as funções de transmissão
e tratamento de informações, oferecer serviços de adaptação, detecção e correção de erros
de transmissão e controle de fluxo.
Vamos considerar agora que, ao invés de um único terminal, vamos conectar um
maior número deles ao computador central (figura 1.4).
Aqui, cada terminal pode, a princípio e a qualquer momento, tomar a iniciativa da troca de
dados com o computador. Isto significa que cada terminal terá de ser caracterizado por um
endereço específico, cuja utilização correta vai permitir evitar que o computador central envie
as informações aos terminais de maneira indevida.
Figura 1.3 - Terminal conectado a um computador central
— 1.5 —
Figura 1.4 - Configuração com vários terminais
Por outro lado, se o número de terminais conectados ao computador central torna-se

relativamente elevado (a fim de permitir a utilização máxima da capacidade de
processamento deste), será necessário organizar as interações entre terminais e o
computador central em sessões, de tal forma que, ao término de uma sessão entre um
terminal e o computador central, este terá liberados determinados elementos (envolvidos
naquela sessão) que poderão atender outros terminais em estado de espera.
Ainda, considerando que nem todos os terminais vão efetuar o mesmo tipo de
tratamento de forma simultânea, dever-se-á, então, especificar a aplicação associada.
Assim, todas as necessidades vistas neste exemplo deverão ser associadas às
funcionalidades definidas no exemplo anterior. Mas os problemas não terminam por aqui... (é
impossível, no momento, prever onde terminarão os problemas!)
Vamos considerar ainda um exemplo, mais particularmente o de uma rede contendo
diversos computadores, terminais, etc... , cada um destes elementos constituindo um nó da
rede (figura 1.5). Neste exemplo, os dois elementos envolvidos numa comunicação não
serão mais necessariamente adjacentes; além disso, podem existir diversas maneiras de
conectá-los, o que vai corresponder a diferentes caminhos. No exemplo mostrado na figura,
os nós 1 e 5 podem ser conectados por pelos menos uns 10 caminhos e a escolha de qual
caminho utilizar deverá então ser realizada, o que é não é uma tarefa tão simples quanto
possa parecer.
Ainda, se a rede é da classe ponto-a-ponto (ou comutação de pacotes), o sistema de
comunicação deve assegurar a correta transmissão (transporte) da informação de um ponto
a outro. Particularmente, será necessário garantir que as mensagens enviadas serão
recuperadas e reconstituídas na ordem correta no ponto de chegada.
Um requisito também importante é o aspecto da codificação das mensagens de
modo a evitar o acesso a informações de parte de usuários alheios ao sistema considerado.
A esta função, pode-se eventualmente acrescentar a técnicas de compressão de dados,
necessária se a informação enviada é demasiadamente redundante e o custo da
comunicação é alto.
4.2. Questões organizacionais
Uma vez listadas as diferentes necessidades relacionadas a uma rede de

comunicação, a questão que se coloca é a da viabilidade de um projeto de rede, dada a
quantidade de funções a implementar.
— 1.6 —
4
3
Figura 1.5 - Configuração com vários computadores e terminais.
Uma outra questão é a do ordenamento das funções. O controle de fluxo deve ser
realizado antes ou depois da correção de erros? Uma vez resolvida esta questão, que
elementos da rede serão responsáveis da implementação destas funções? As soluções
adotadas são dependentes do suporte de transmissão utilizado? Elas continuam válidas no
caso de expansão da rede? Estas questões representam, de certo modo, a necessidade de
levar em conta um certo ordenamento no que diz respeito à adoção das soluções a cada
problema.
Uma ilustração típica do problema é aquele da comunicação entre duas empresas.
Vamos supor que o Diretor de uma Empresa A quer comunicar com o Diretor de uma
Empresa B. Ele convoca a sua Secretária Administrativa e solicita, informalmente, que esta
construa um texto relativo ao assunto a ser tratado. A Secretária Administrativa elabora o
documento e o entrega ao Office Boy que vai envelopá-lo e encaminhá-lo ao Chefe do Setor
de Malote. Este último encaminha o documento ao Serviço Postal para condução à Empresa
B.
Considerando que a Empresa B apresenta uma estrutura similar à Empresa A (como
é ilustrado na figura 1.6), os mesmos elementos atuam, cada um em suas funções para
fazer com que a correspondência chegue às mãos do Diretor da Empresa.
Empresa A Empresa B
Diretor Diretor
Empresa Empresa
Secretária Secretária
Administrativa Administrativa
Office Office
Boy Boy
Chefe Chefe
Malote Malote
Serviço Postal
Figura 1.6 - Filosofia de concepção das redes, ilustrada por um processo de relações entre empresas.
— 1.7 —
Este processo caracteriza, na verdade, a filosofia de concepção das redes de

comunicação, que é baseada em dois conceitos fundamentais: o da hierarquia e o da
descentralização, cuja conjunção vai permitir responder à questão de ordenação na adoção
das soluções. Segundo esta filosofia, uma tarefa global é vista como sendo decomposta à
medida que se vai descendo na hierarquia e que a única interação física se faz no seu nível
mais baixo.
Podemos considerar que a comunicação entre dois nós de uma rede é uma tarefa
global que afeta um sistema complexo e, consequentemente, sujeita à aplicação dos
princípios de hierarquização e de descentralização.
As vantagens da adoção destes princípios são, fundamentalmente:
• facilidade de estudo e de implementação da rede a partir de elementos de base
existentes, o que permite a redução dos custos de instalação;
• simplificação de sua operação em função da definição de regras formais;
• garantia de confiabilidade de um sistema que seja aceitável, particularmente
graças ao encapsulamento das funções o que permite limitar a propagação de
erros e facilitar a manutenção;
• garantia, pela modularidade, de um grau satisfatório de evolutividade e de
extensibilidade da rede;
• otimizar o desempenho.
Todos estes aspectos nos conduzem a conceber uma arquitetura de comunicação

como sendo uma organização de software e hardware estruturada em camadas.
4.3. A estruturação em camadas
Os conceitos de hierarquia e descentralização podem ser empregados de diferentes

formas, cada uma podendo implicar num tipo de rede particular. Em função desta provável
multiplicidade, surgiu então a necessidade de uma normalização permitindo a conexão de
diferentes classes de hardware.
Para possibilitar a normalização, foi necessário estabelecer um modelo teórico capaz
de representar as relações entre as diferentes tarefas implementadas nos diferentes níveis
hierárquicos. A possibilidade de interconexão de um número qualquer de sistemas, ou seja,
de conjuntos autônomos podendo efetuar tarefas de tratamento ou de transmissão de
informação, era uma característica essencial para o modelo a ser estabelecido.
A figura 1.7 ilustra uma arquitetura hierarquizada em 7 camadas que permitirá
introduzir o conjunto de conceitos relacionados ao modelo estabelecido.
O objetivo de cada camada é o oferecimento de um determinado serviço às camadas
superiores de forma a evitar que estas necessitem conhecer certos aspectos da
implementação destes serviços.
A camada n assume a comunicação com a camada n de uma outra máquina. Para
fazê-lo, ela se serve de um conjunto de convenções e regras que vão permitir gerir esta
comunicação. A este conjunto de regras e convenções, dá-se o nome de protocolo da
camada n, ou, simplesmente, protocolo n. Como se pode ver na figura, não existe meio de
comunicação físico entre as diferentes camadas (apenas o Meio de Transmissão entre as
entidades pares da camada 1), o que significa que não existe transferência direta de dados
entre a camada n de uma máquina à camada n de outra máquina.
Na realidade, cada camada transfere os dados à camada imediatamente inferior até a
camada mais baixa; o dado é então transmitido à outra máquina através do Meio de
Transmissão. A comunicação entre as camadas é vista então como uma comunicação
virtual e é representada, na figura 1.7, pelas linhas tracejadas ligando cada par de processos
de uma camada.
— 1.8 —
SISTEMA A SISTEMA B
Protocolo da Camada 7
Camada 7 Camada 7
Interface Interface
6/7 Protocolo da Camada 6 6/7
Camada 6 Camada 6
Interface Interface
Camada 5 Camada 5
Interface Interface
Camada 4 Camada 4
Interface Interface
Camada 3 Camada 3
Interface Interface
Camada 2 Camada 2
Interface Interface
Camada 1 Camada 1
Meio de Transmissão
Figura 1.7 - Modelo hierarquizado em 7 camadas.
Cada camada comunica-se com as camadas adjacentes através de uma interface,

que define as operações elementares e os serviços que a camada inferior oferece à camada
considerada.
No momento da definição do número de camadas que vai compor uma rede e do
papel que cada uma delas deve cumprir, uma tarefa importante será a definição completa
das interfaces entre as camadas; isto vai implicar que na definição do serviço oferecido por
cada camada.
Uma vantagem da correta definição das interfaces é a facilidade da introdução de
modificações nas implementações das diferentes camadas; os mecanismos podem ser
implementados de forma diferente, desde que as interfaces anteriormente definidas sejam
respeitadas.
Ao conjunto das camadas compondo uma rede dá-se o nome de arquitetura da rede,
e as especificações da arquitetura devem conter informações suficientes para permitir o
correto desenvolvimento da rede, tanto do ponto de vista do software quanto do hardware.
Por outro lado, os detalhes de implementação dos mecanismos a implementar em cada
camada, assim como as especificações detalhadas das interfaces não fazem parte da
definição da arquitetura da rede.
5. TECNOLOGIAS DE TRANSMISSÃO DE DADOS
5.1. Principais Características
Podemos definir transmissão como a técnica do transporte do sinal por um meio, de

um ponto a outro afastado. Em particular, a transmissão de dados apresenta diversas
características referentes ao sentido da transmissão, número de canais utilizados,
sincronismo entre transmissor e receptor e velocidade de transmissão.
Um equipamento pode ser projetado de tal forma que a transmissão sobre um
determinado meio seja feita em uma das seguintes formas (sentido):
§ Simplex - quando a transmissão é feita em um único sentido.
§ Half-duplex - quando a transmissão é feita nos dois sentidos mas não ao
mesmo tempo.
§ Full-duplex - quando a transmissão é feita nos dois sentidos simultaneamente.
— 1.9 —
Uma mensagem é definida como um conjunto de símbolos. Cada símbolo, por sua
vez, para efeito de transmissão de dados, é caracterizado por um conjunto de configurações
do sinal que representam bits. Por necessidade de codificação, os símbolos ficam
associados a caracteres, que são, na realidade, configurações de sinais. Na verdade, uma
mensagem nada mais é que uma seqüência de bits. Para transferir essa seqüência de bits,
podemos fazer de duas formas: serial ou paralela. Na transmissão paralela, os bits que
compõem um caracter são transportados de forma simultânea, cada um possuindo seu
próprio canal, conforme mostra a figura 1.8.
Na transmissão serial, os bits que compõem um caracter são transportados um após
o outro, utilizando apenas um canal, como ilustrado na figura 1.9.
canal 0
1 1
canal 1
1 1
canal 2
0 0
canal 3
1 1
canal 4
0 0
canal 5
0 0
canal 6
1 1
canal 7
0 0
EMISSOR RECEPTOR
Figura 1.8 - Transmissão paralela.
1
1
0
1 1 1 0 1 0 0 1 0
1 1 0 1 0 0 1 0
0
0
1 RECEPTOR
0
EMISSOR
Figura 1.9 - Transmissão serial.
Como os bits chegam um de cada vez, o equipamento receptor deverá saber qual bit
é o primeiro do caracter, a fim de que possa decodificar o símbolo recebido, ou quais bits
são realmente de informação. Este é um problema de sincronização. Sincronização pode
ser vista, então, como o método do equipamento transmissor fazer a separação dos
caracteres ou das mensagens para o equipamento receptor. Existem dois modos de se
fazer sincronização e eles são conhecidos como transmissão síncrona e transmissão
assíncrona. Todos os dois modos dizem respeito à transmissão serial.
Na transmissão serial assíncrona, a sincronização é alcançada precedendo-se cada
caracter de um elemento de start e colocando-se, após os bits de dados um elemento de
stop. Geralmente os dados são transmitidos serialmente em um número fixo de bits,
dependendo do código usado.
Na transmissão serial síncrona, a sincronização é alcançada transmitindo-se os bits
de um caracter seguidos imediatamente pelos bits do próximo caracter, não havendo
elementos de start/stop entre eles. O conjunto de caracteres que formam uma mensagem é
dividido em blocos. O tamanho destes blocos varia desde alguns poucos caracteres até
centenas deles, dependendo dos equipamentos envolvidos na transmissão.
— 1.10 —
A sincronização na transmissão síncrona se faz antes que um bloco de informação

seja enviado pelo equipamento transmissor. Ela é alcançada pelo envio de uma configuração
de bits chamada "caracter de sincronização" que precede o bloco a ser transmitido. Neste
caso, a sincronização é feita mediante um ou dois bytes de sincronismo que são
configurações de bits designadas para este fim. Do mesmo modo que é iniciada, a
comunicação síncrona é encerrada, não por um bit, mas por um ou mais caracteres de fim
de transmissão.
Os caracteres iniciais e finais de um bloco em transmissão síncrona constituem o
envelope do bloco, que pode ou não ser uma mensagem completa e tem funções análogas
as do envelope de uma carta, inclusive a de conter também o endereço do destinatário. A
ordem correta dos bits que constituem o envelope do bloco é definida por um conjunto de
regras chamado protocolo de comunicação. São exemplos destes protocolos para
transmissão síncrona: BSC, SDLC e HDLC.
As vantagens de transmissão assíncrona são: geração de caracteres por meio de
dispositivos eletromecânicos e transmissão de caracteres irregularmente espaçados no
tempo. As desvantagens são: uma parte considerável do que transmite não transporta
informação útil: a sincronização depende dos start/stop que podem não ser detectados por
causa de distorções do sinal. Uma utilização da transmissão assíncrona é quando não se
necessita de transmissão freqüente de informação.
A transmissão síncrona apresenta, como vantagem, uma melhor proteção contra
erros, pois ao término de cada bloco uma configuração de bits para detecção de erros pode
ser enviada; é mais eficiente pois a proporção de mensagem transmitida como informação
em relação à configuração de sincronização é maior que na transmissão assíncrona; não é
tão sensível à distorção e opera a velocidades bem mais altas que no modo assíncrono. As
desvantagens são: caso haja erro de sincronização, todo bloco é perdido; os caracteres são
enviados em blocos e não antes destes poderem ser formados, obrigando que os
equipamentos sejam dotados de memória de armazenamento para a coleta dos caracteres
até que se forme o bloco com o comprimento usado pelo equipamento. Memória, nesse
caso, são buffers, o que encarece seu custo.
5.2. Largura de Banda e Capacidade de Canal
A taxa em que podemos enviar dados sobre um canal é proporcional à largura de

banda do canal (ou bandwidth). O termo largura de banda não tem qualquer relação com as
freqüências que são transmitidas no canal. Ele indica apenas a diferença entre os limites
inferior e superior das freqüências que são suportadas pelo canal. Por exemplo, um canal
que admite freqüências da ordem de 1500 a 5000 Hz, tem uma largura de banda igual a
5000-1500 = 3500Hz. Da mesma forma, um canal que admite freqüências que vão desde
18000 Hz a 21500 Hz também apresenta uma largura de banda 3500 Hz (21500 - 18000).
A largura de banda de um canal de comunicação constitui uma medida da máxima
taxa de informação que pode ser transmitida pelo canal. Largura de banda significa o
espectro de freqüência que o canal é capaz de transmitir. Sobre a questão de quantos
estados de sinalização podem ser transmitidos e distinguidos separadamente no receptor de
um sistema de comunicação de dados pode-se dizer que, examinados os fatores que
influenciam esse número de estados, podemos definir o conceito de capacidade do canal.
Ruído, distorção e flutuações na atenuação do sinal portador têm influência no
número de estados de sinalização. Este número de estados é observado na unidade de
tempo (segundo). Quanto maior o número de estados que podem ser transmitidos e
distinguidos, maior será a capacidade do canal. Podemos então concluir que a capacidade
do canal está intimamente relacionada com a velocidade de transmissão, pois quanto maior
o número de estados mais bits por segundo poderão ser transmitidos. Daí medir-se
capacidade na unidade bits/segundo.
Diferentes tipos de sinais (voz humana, música, dados, imagem) necessitam de
diferentes capacidades de canal, as quais são indicadas em termos de largura de banda e
— 1.11 —
outros fatores que influenciam a capacidade de um canal. Conhecida, pois, a largura de

banda de um canal de comunicação, pode-se estabelecer a máxima taxa de sinalização que
o mesmo pode conduzir sem erro, o que é denominado de capacidade do canal de
comunicação.
5.3. Distorção e Ruído na Transmissão
Atenuação, ruído e retardo são termos usados de um modo geral para descrever
as modificações que um sinal sofre quando é transmitido em um circuito ou canal. Essas
alterações resultam de imperfeições na propagação do sinal, ao longo do suporte de
transmissão (atenuação e retardo) e de perturbações (ruídos) que atuam não só no suporte
de transmissão como também nos estágios de processamento do sinal que compõem o
receptor. Quando a alteração sofrida pelo sinal é muito grande, pode ocorrer a detecção
trocada da informação binária, isto é, detecção de "1" quando foi transmitido o "0" ou
detecção de "0" quando foi transmitido o "1". Estas detecções trocadas caracterizam os
chamados erros de transmissão.
O desempenho de um sistema de transmissão de dados é avaliado através do seu
grau de confiabilidade na transmissão dos bits. A taxa de erros de um sistema de
transmissão representa a probabilidade de ocorrência de erros de transmissão.
Para redes de longa distância existe uma padronização internacional que determina
uma taxa de erros máxima em um canal a fim de que o mesmo possa ser considerado
adequado para a transmissão de dados. O ITU recomenda uma taxa de erros não superior a
10-5 , isto é, 1 bit errado a cada 100.000 bits transmitidos. Para redes locais, de maneira
geral, admite-se taxas de erros típicas da ordem de 10-9 a 10-12 .
A transmissão sem erros é um requisito essencial de quase todas as aplicações de
comunicação de dados e portanto, uma série de mecanismos deve ser implementada para
detectar e corrigir possíveis erros. A maneira usual utilizada para detectar a alteração de bits
de informação transmitidos, consiste na adição de bits de redundância na mensagem a ser
transmitida. Dentre as várias técnicas usadas para esta finalidade pode-se citar: bits de
paridade por caracter, paridade longitudinal e códigos de redundância cíclica (CRC).
5.4. Comutação
A função de comutação, ou chaveamento, em uma rede de comunicação refere-se

à alocação dos recursos da rede (meios de transmissão, repetidores, sistemas
intermediários, etc.) para a transmissão pelos diversos dispositivos conectados. A alocação
destes recursos está intimamente ligada à forma de multiplexação dos meios de
transmissão, que será discutida mais adiante. As formas de comutação são denominadas
comutação de circuitos, comutação de mensagens e comutação de pacotes.
A comutação de circuitos pode ser realizada se existir um caminho dedicado de
comunicação entre duas estações. Esta comunicação envolve 3 fases: estabelecimento do
circuito, transferência de informações e desconexão do circuito. Na comutação de circuitos o
caminho alocado durante a fase de estabelecimento da conexão permanece dedicado
àquelas estações até que uma delas, ou ambas, decida desfazer o circuito. Caso o tráfego
entre as estações não seja contínuo e constante a capacidade do meio físico será
desperdiçada. O caminho dedicado entre a origem e o destino pode ser: um caminho físico
formado por uma sucessão de enlaces físicos, uma sucessão de canais de freqüência
alocados em cada enlace ou uma sucessão de canais de tempo alocados em cada enlace.
Este tipo de comutação é bastante utilizada em sistemas telefônicos.
Na comutação de mensagens não é necessário o estabelecimento de um caminho
dedicado entre as estações. Se uma estação deseja transmitir uma mensagem ela adiciona
o endereço de destino da mesma poderá ser transmitida pela rede de nó em nó, utilizando
apenas um canal por vez. A mensagem é armazenada e retransmitida em cada nó (store-
and-forward).
— 1.12 —
A comutação de pacotes é semelhante à comutação de mensagens, sendo que a

principal diferença está no tamanho da mensagem sendo transmitida, que neste caso tem
tamanho reduzido e limitado. Neste caso as mensagens com tamanho acima de um limite
devem ser fragmentadas em unidades menores denominadas pacotes. Os pacotes que
formam uma mensagem podem estar sendo transmitidos simultaneamente pela rede em
diferentes enlaces, o que reduz o atraso de transmissão total da mensagem. Redes com
comutação de pacotes requerem nós de comutação com menor capacidade de
armazenamento e procedimentos de recuperação de erros mais eficientes do que para
comutação de mensagens.
5.5. Multiplexação
Quando a banda passante de um meio físico for maior ou igual à banda passante
necessária para um sinal podemos transmitir mais de um sinal neste meio físico. Esta
técnica é denominada multiplexação.
As duas principais técnicas de multiplexação são: multiplexação por divisão de
freqüência (FDM) e multiplexação por divisão de tempo (TDM). A primeira técnica divide
a largura de banda em diversas larguras de banda menores, cada qual com seu próprio
domínio de freqüências. Cada uma destas componentes pode ser usada individualmente
como se ela fosse uma linha separada. A segunda técnica intercala os bits, que fluem das
linhas de baixa velocidade, dentro da linha de maior velocidade. Em ambos os métodos o
resultado é que uma linha transmite em paralelo um número de sinais de linhas de
velocidades mais baixas.
Uma desvantagem da FDM é a relativa dificuldade de expansão porque, uma vez
determinado o número de sub-canais sobre a linha compartilhada, pode ser difícil adicionar
novos sub-canais já que as freqüências em um grupo devem ser reatribuídas. Na TDM na
qual o tempo disponível é dividido para os terminais; a largura de banda interna da linha de
alta velocidade é ocupada pelo sinal de uma das linhas de baixa velocidade por unidade de
tempo, então a largura de banda é dedicada ao tráfego da próxima linha de baixa velocidade
e assim por diante. O multiplexador examina os sinais das linhas de baixa velocidade com
uma ordem pré-definida. A linha de alta velocidade é ocupada com um único sinal em um
determinado instante. Esta técnica é assim, totalmente diferente da FDM, na qual todos os
sinais são enviados ao mesmo tempo, porém cada um ocupando uma diferente porção da
largura de banda.
A FDM ajusta-se naturalmente dentro do mundo dos sinais analógicos e a TDM tem
sido amplamente usada com sinais digitais. A TDM é geralmente mais eficiente do que a
FDM porque mais sub-canais podem ser colocados. FDM usa guardas-de-banda para
separar freqüências alocadas. Similarmente, alguma perda do tempo ocorre com TDM. As
fatias de tempo alocadas devem ser separadas por um espaço de tempo umas das outras.
A TDM pode ser utilizada quando a capacidade (em quantidade de bits por segundo)
do meio de transmissão, em muitos casos excede a taxa máxima de geração de bits da
estações conectadas ao meio físico. Quando isto ocorre vários sinais podem ser
transportados por um único caminho físico, intercalando-se porões de cada sinal durante o
tempo. A TDM pode ser síncrona ou assíncrona. Na TDM síncrona o domínio do tempo é
dividido em intervalos de tamanho fixo denominados frames, que por sua vez são
subdivididos em subintervalos denominados slots. Cada estação deve esperar o seu slot
dentro de cada frame quando então poderá transmitir dentro do tempo daquele slot utilizando
a taxa de transmissão máxima suportada pelo meio físico. A TDM assíncrona procura
eliminar o desperdício de capacidade existente no TDM síncrono, eliminando a alocação
prévia do canal. Neste caso parcelas de tempo são alocadas dinamicamente de acordo com
a demanda das estações, em compensação as unidades de informação devem conter um
cabeçalho com os endereços origem e destino.
O único objetivo dos multiplexadores é a diminuição do custo das linhas em uma
rede. Uma tendência evidente é o crescente uso de inteligência nos multiplexadores para
— 1.13 —
diminuir, ainda mais o custo das linhas (aumentar a economia). Multiplexadores inteligentes
podem ser vistos como equipamentos de processamento da comunicação mais gerais e
incluem os concentradores e processadores front-end.
Um concentrador, em sua forma mais simples, nada mais é que um multiplexador
inteligente , com memória de armazenamento e um processador. Nos multiplexadores existe
uma correlação direta entre as velocidades de entrada e saída, enquanto que nos
concentradores, que também incluem um software de controle, um grande número de linhas
de baixa velocidade podem compartilhar um pequeno número de canais de alta velocidade.
Através de armazenamento, enfileiramento e alocação estatística de canais disponíveis, os
dados da fonte são "concentrados" em um canal de alta velocidade. Uma diferença
fundamental entre multiplexadores e concentradores é que o primeiro trabalha com mesma
taxa de entrada e saída de dados, enquanto que um concentrador inteligente pode ajustar
dinamicamente suas alocações de largura de banda para modificações no tráfego.
A técnica TDM se caracteriza por alocar uma fatia de tempo n à n-ésima linha de
baixa velocidade, mesmo que não exista nenhum tráfego sobre esta linha. Uma modificação
para otimizar esta técnica é a TDM estatística (STDM) que é uma forma de concentração.
Uma fatia de tempo só será alocada se existir tráfego na linha. Em geral, o uso da STDM é
mais vantajoso que a TDM pois evita a má utilização da linha. No entanto, se o tráfego de
várias fontes (ou destinos) é uniformemente distribuído no tempo, então o uso da TDM será
menos caro e proporcionará uma melhor utilização da linha.
Um processador front-end é um concentrador de propósito especial que é instalado
na frente do computador hospedeiro (HOST) e executa a tarefa de gerenciar a interface entre
o HOST e a rede de comunicação. O principal objetivo da utilização de um processador
front-end é aliviar o HOST das tarefas de processamento de comunicação reduzindo o
tempo e o espaço dedicados pelo HOST para estas tarefas e, portanto, aumentar a sua
disponibilidade para o processamento de dados.
5.6. Modulação
Computadores são equipamentos que armazenam, processam e codificam

informações em bits, que correspondem a dois níveis discretos de tensão ou corrente,
representado pelos valores lógicos 0 ou 1. Este tipo de informação é chamada de digital. As
informações geradas por fontes sonoras apresentam variações contínuas de amplitude,
constituindo-se no tipo de informação que comumente denominamos de analógica. Desta
forma podemos afirmar que existem dois tipos de sinais gerados para transmissão: sinais
analógicos e sinais digitais. É importante notar que qualquer tipo de informação, analógica
ou digital, pode ser transmitida através de um sinal analógico ou digital. A transmissão de
informação digital através de sinais analógicos é possível através de técnicas de
modulação, que transformam os sinais digitais em sinais analógicos através da variação
contínua de um de seus parâmetros.
Neste ponto, é conveniente fazer uma diferenciação entre as unidades bits por
segundo (bps) e bauds. A taxa em bauds indica o número de vezes que a característica do
sinal portador da informação (sinal modulado) se altera por segundo. Se o estado do sinal
representa a presença ou ausência de um bit, então a taxa em bauds é a mesma que a taxa
em bps. Por outro lado, quando usamos transmissão multinível, cada estado do sinal
representa mais de um bit (2 bits na modulação dibit e 3 bits na modulação tribit, etc) e
observamos que a taxa em bauds é menor que a taxa em bps. Por exemplo, considerando
uma modulação dibit, onde o sinal pode estar em quatro estados e cada estado representa
um dibit (2 bits), se a velocidade de sinalização for de 200 bauds, isto é, se a condição do
sinal se alterar 200 vezes por segundo, teremos 400 bits transmitidos por segundo, ou seja,
para cada alteração de condição do sinal, estaremos transmitindo dois bits representativos
de um estado.
Um exemplo sobre a diferença entre as velocidades bauds e bps é a utilização do
canal telefônico para transmissão de sinal de dados. A largura de banda deste canal é de
— 1.14 —
3100 Hz (ciclos/segundo) e na prática é usado para transmitir sinal de dados até 2400
bauds. Se desejarmos transmitir a uma velocidade de transmissão de 4800 bps neste canal,
deveremos usar um sinal dibit, ao qual corresponderá a mesma velocidade de sinalização de
2400 bauds. Neste caso, a velocidade de transmissão é duas vezes a velocidade de
sinalização. Da mesma forma que se desejarmos transmitir 7200 bps, deveremos usar um
sinal tribit e teremos velocidade de transmissão igual a três vezes a velocidade de
sinalização.
Modulação é o processo pelo qual se imprime uma informação em uma onda
portadora, pela variação de um de seus parâmetros (amplitude, freqüência ou fase). O
processo inverso, no qual a informação é retirada da onda portadora, é denominado
demodulação. O equipamento que realiza a adequação dos sinais binários ao canal de
transmissão é denominado modem (modulador-demodulador).
Existem três técnicas básicas de modulação:
§ modulação por amplitude (AM)

§ modulação por freqüência (FM)
§ modulação por fase (PM)
No caso específico do sinal modulador ser um sinal digital, essas técnicas tomam as
seguintes denominações:
§ modulação por chaveamento da fase (ASK)
§ modulação por chaveamento da freqüência (FSK)
§ modulação por chaveamento de fase (PSK)
5.7. Sistemas em Banda Larga e em Banda Básica
Duas técnicas de transmissão são as mais empregadas: sinalização em banda

básica (baseband) e sinalização em banda larga (broadband). Na sinalização em banda
básica (ou sinalização digital) o sinal é simplesmente colocado na rede sem se usar
qualquer tipo de modulação, aparecendo diretamente na rede e não como deslocamentos de
freqüência, fase ou amplitude de uma portadora. Sinalização em banda básica vem sendo
adotada nos projetos de redes por não necessitar de modems e por possibilitar a
transmissão em alta velocidade. Esta técnica não é adequada para transmissão a longas
distâncias e para circuitos sujeitos a ruídos, interferências e erros aleatórios. Na sinalização
em banda básica todo o espectro (banda) de freqüência do meio é utilizado para produzir o
sinal. No ambiente de redes locais a sinalização em banda básica é bastante adequada.
A sinalização em banda larga (ou sinalização analógica) realiza a multiplexação em
freqüência (FDM). Com esta sinalização o espectro de freqüência do meio é dividido em
vários canais, cada um podendo suportar diferentes tráfegos. Um caso especial de sistema
de banda larga é o sistema de baixo custo que utiliza apenas um canal, denominado banda
larga de único canal. A sinalização em banda larga é geralmente utilizada em redes locais
Sinalização em banda larga é geralmente utilizada em redes locais em barra. Nas redes em
banda larga cada canal pode ser utilizado para transportar qualquer tipo de sinal, por
exemplo, sinais analógicos, como imagem ou voz, ou sinais digitais. Os canais podem ser
classificados como dedicados ou chaveados. Tanto os canais dedicados quanto os canais
chaveados podem ser ponto-a-ponto ou multiponto.
— 1.15 —
Capítulo 2
O M ODELO DE R E F E R Ê N C I A OSI
1. INTRODUÇÃO
A grande importância da interconexão dos computadores através de redes de

comunicação deu origem a uma necessidade que foi tornando-se evidente à medida que os
desenvolvimentos neste domínio foram acentuando-se — a normalização das redes de
comunicação.
Iniciou-se, então, no seio da ISO - International Organization for Standardization, uma
reunião de esforços no sentido de definir uma proposta de arquitetura normalizada para as
redes de comunicação. Dada a grande diversidade dos equipamentos e das soluções
existentes no que diz respeito à comunicação, o resultado deste trabalho foi de fato a
padronização de um modelo (modelo de referência) sobre o qual deveriam ser baseadas as
arquiteturas de redes de comunicação de forma a permitir a interconexão de equipamentos
heterogêneos, tornando transparente ao usuário a forma como esta interconexão fosse
implementada.
Um sistema fundado em tal modelo de referência é dito um sistema aberto, uma vez
que este está aberto à comunicação com outros equipamentos, de diferentes classes,
fabricantes, modelos, etc...
Baseada nesta filosofia, a proposta, definida numa série de documentos produzidos
por aquela organização, foi denominada de Modelo de Referência para a Interconexão de
Sistemas Abertos ou RM-OSI (Reference Model for Open Systems Interconnection), cujos
conceitos principais serão apresentados nas seções que seguem.
2. FUNDAMENTOS E ARQUITETURA
O conjunto de camadas ou níveis compondo um conjunto de regras de comunicação

numa rede, denominada arquitetura da rede, e as especificações da arquitetura devem
conter informações suficientes para permitir o correto desenvolvimento da rede, tanto do
ponto de vista do software quanto do hardware. Os detalhes de implementação dos
mecanismos a implementar em cada camada, assim como as especificações detalhadas
das interfaces não fazem parte da definição da arquitetura da rede.
Conforme já introduzido anteriormente, a figura 2.1 ilustra a arquitetura hierarquizada
em camadas, no caso, 7 camadas, que permitirá introduzir o conjunto de conceitos
relacionados ao modelo estabelecido.
O objetivo de cada camada é o oferecimento de um determinado serviço às camadas
superiores (utilizando-se, também dos serviços oferecidos pelas camadas inferiores) de
forma a evitar que estas necessitem conhecer certos aspectos da implementação destes
serviços.
A camada n assume a comunicação com a camada n de uma outra máquina. Para
fazê-lo, ela se serve de um conjunto de convenções e regras que vão permitir gerir esta
comunicação. A este conjunto de regras e convenções, dá-se o nome de protocolo da
— 2.1 —
CAP. 2 – O MODELO DE REFERÊNCIA OSI PROF. VITÓRIO BRUNO MAZZOLA
camada n, ou, simplesmente, protocolo n. As entidades representando camadas

correspondentes em diferentes sistemas são denominadas processos pares, ou entidades
pares. Os processos pares vão se comunicar então através dos protocolos. Como se pode
ver na figura, não existe meio de comunicação físico entre as diferentes camadas (apenas o
Meio de Transmissão entre as entidades pares da camada 1), o que significa que não existe
transferência direta de dados entre a camada n de uma máquina à camada n de outra
máquina.
Cada camada transfere os dados à camada imediatamente inferior até a camada
mais baixa; o dado é então transmitido à outra máquina através do Meio de Transmissão. A
comunicação entre as camadas é vista como uma COMUNICAÇÃO VIRTUAL e é representada,
na figura 2.1, pelas linhas tracejadas ligando cada par de processos de uma camada. Cada
camada comunica-se com as camadas adjacentes através de uma interface, que define as
operações elementares e os serviços que a camada inferior oferece à camada considerada.
No momento da definição do número de camadas que vai compor uma rede e do papel que
cada uma delas deve cumprir, uma tarefa importante será a definição completa das
interfaces entre as camadas; isto vai implicar que na definição do serviço oferecido por cada
camada. Uma vantagem da correta definição das interfaces é a facilidade da introdução de
modificações nas implementações das diferentes camadas; os mecanismos podem ser
implementados de forma diferente, desde que as interfaces anteriormente definidas sejam
respeitadas.
Ao conjunto das camadas compondo uma rede dá-se o nome de arquitetura da rede,
e as especificações da arquitetura devem conter informações suficientes para permitir o
correto desenvolvimento da rede, tanto do ponto de vista do software quanto do hardware.
Por outro lado, os detalhes de implementação dos mecanismos a implementar em cada
camada, assim como as especificações detalhadas das interfaces não fazem parte da
definição da arquitetura da rede. A figura 2.2 permite ilustrar o processo da comunicação
no contexto de uma arquitetura multicamadas. O processo da camada 7 gera uma
mensagem m, que será transmitida desta à camada inferior segundo o que estiver definido
pela interface das camadas 6/7.
Considera-se que esta transmissão introduz algumas modificações na mensagem
(por exemplo, uma compressão de dados), o que justifica uma nova representação desta por
M. Esta mensagem é, por sua vez, transmitida à camada 5, através da interface das
camadas 5/6.
SISTEMA A SISTEMA B
Camada 7 Camada 7
Interface Interface
Camada 6 Camada 6
Interface Interface
Camada 5 Camada 5
Interface Interface
Camada 4 Camada 4
Interface Interface
Camada 3 Camada 3
Interface Interface
Camada 2 Camada 2
Interface Interface
Camada 1 Camada 1
Meio de Transmissão
Figura 2.1 - Modelo hierarquizado em 7 camadas.
— 2.2 —
No exemplo considerado na figura, a mensagem não sofre modificações, mas esta

camada efetua o controle de fluxo. A camada 4 é responsável da decomposição da
mensagem a fim de respeitar as restrições de tamanho que podem ser impostas pelas
camadas inferiores. Assim, M é decomposta em M1 e M2.
Para isto, é inserido também na mensagem (ou nas partes da mensagem) um
cabeçalho H4 contendo uma informação de controle, como, por exemplo, um número de
ordem que vai permitir, posteriormente na camada 4 do sistema destinatário, a reconstrução
da mensagem a partir das partes recebidas. Outras informações podem ainda estar
contidas neste cabeçalho, como, por exemplo, o tamanho da mensagem, o instante de
envio, etc...
Na camada 3, é feita a escolha das linhas de saída e um novo cabeçalho, H3, é
introduzido às mensagens. Na camada 2, além de um cabeçalho, H2, é introduzido também
um sufixo, T2, contendo informações específicos a esta camada. A mensagem é finalmente
entregue à camada 1 para emissão via meio físico.
No sistema destinatário, o processo inverso se desenrola, sendo que as mensagens
vão subindo, de camada em camada, e os cabeçalhos retirados nas camadas respectivas,
de modo a evitar que estes sejam transferidos às camadas que não lhes dizem respeito.
Um aspecto importante mostrado na figura 2.2 é o da comunicação virtual ocorrendo
entre as diferentes camadas pares. As camadas em cada nível possuem uma visão da
comunicação horizontal, mesmo se as mensagens são na realidade transmitidas às
camadas inferiores pertencentes ao mesmo sistema.
3. SERVIÇOS E PROTOCOLOS
Embora sejam freqüentemente confundidos, serviço e protocolo são dois conceitos

distintos. O importante nesta distinção é de poder estabelecer a relação entre os dois
conceitos.
O serviço corresponde a um conjunto de operações que uma camada é capaz de
oferecer à camada imediatamente superior. Ele define o que uma camada é capaz de
executar sem se preocupar com a maneira pela qual as operações serão executadas.
O serviço está intimamente relacionado com as interfaces entre duas camadas, a
inferior sendo a fornecedora do serviço e a superior, a usuária deste.
TRANSMISSOR RECEPTOR
Protocolo
M M
da Camada 7
Protocolo
m m
da Camada 6
Protocolo
m m
da Camada 5
Protocolo
H4 M1 H4 M2 H4 M1 H4 M2
da Camada 4
Protocolo
H3 H4 M1 H3 H4 M2 H3 H4 M1 H3 H4 M2
da Camada 3
Protocolo
H2 H3 H4 M1 H2 H3 H4 M2 H2 H3 H4 M1 H2 H3 H4 M2
da Camada 2
Figura 2.2 - Ilustração da comunicação virtual numa arquitetura de rede.
— 2.3 —
Por outro lado, o protocolo define um conjunto de regras que permitem especificar
aspectos da realização do serviço, particularmente, o significado dos quadros, pacotes ou
mensagens trocadas entre as entidades pares de uma dada camada. A nível de uma
camada, o protocolo pode ser mudado sem problemas, desde que as interfaces com a
camada superior não sejam alteradas, ou seja, que aquela continue a ter a mesma
visibilidade no que diz respeito aos serviços realizados pela camada considerada; isto
corresponde, na verdade, a um certo desacoplamento entre os conceitos de serviço e
protocolo.
4. A ARQUITETURA OSI E AS FUNÇÕES DAS CAMADAS
O modelo OSI foi criado seguindo a filosofia das arquiteturas multicamadas, descrita
no capítulo precedente. Como mostra a figura 2.3, sua arquitetura define 7 camadas, cujos
princípios de definição foram os seguintes:
• cada camada corresponde a um nível de abstração necessário no modelo;
• cada camada possui suas funções próprias e bem definidas;
• as funções de cada camada foram escolhidas segundo a definição dos
protocolos normalizados internacionalmente;
• a escolha das fronteiras entre cada camada deveriam ser definidas de modo a
minimizar o fluxo de informação nas interfaces;
• número de camadas deveria ser suficientemente grande para evitar a realização
de funções muito diversas por uma mesma camada;
• número de camadas deveria ser suficientemente pequeno para evitar uma alta
complexidade da arquitetura.
Como se pode ver na figura, o modelo prevê a comunicação entre sub-redes através
de processadores de interface de mensagem, ou IMPs (Interface Message Processors). Na
figura, vemos ainda as unidades de dados trocadas a nível da arquitetura: APDU, PPDU, ...,
BIT. Vamos descrever, a seguir, as principais funções realizadas por cada uma das
camadas definidas no modelo.
A Camada Física é responsável da transferência de bits num circuito de
comunicação.
SISTEMA A SISTEMA B
7 7
Aplicação Aplicação
6 Apresentação Apresentação 6
5 5
Sessão Sessão
4 4
Transporte Transporte
3 3
Rede Rede Rede Rede
2 Enlace Enlace Enlace Enlace 2
1 1
Física Física Física Física
IMP IMP
IMP - Interface Message Processor
Figura 2.3 - Arquitetura de sete camadas do modelo OSI.
— 2.4 —
De maneira geral, a sua função é garantir que cada bit enviado de um lado será
recebido do outro lado sem ter alterado o seu valor, ou seja, se o bit enviado está a 1, ele
será recebido a 1 e não a 0.
Para isto, as questões a serem resolvidas neste nível são do tipo:
• os modos de representação dos bits 0 e 1 de maneira a evitar ambigüidades ou

confusões (valor da tensão em volts para a representação dos valores 0 e 1 dos bits,
duração de cada sinal representando um bit, a codificação dos sinais, etc...);
• os tipos de conectores a serem utilizados nas ligações (número de pinos utilizado, as
funções associadas a cada pino, ...);
• a maneira como as conexões são estabelecidas para a iniciação de um diálogo e
como é feita a desconexão ao final deste;
• modo de transmissão adotado ( unidirecional, bidirecional, ...);
• modo de conexão adotado (ponto-a-ponto, multiponto, ...);
• modo de tratamento dos erros (detecção, tratamento, etc...).
A concepção desta camada deve se relacionar à definição das interfaces elétricas e

mecânicas, seus modos de funcionamento, o suporte de comunicação adotado, etc.
A Camada de Enlace de Dados tem por função principal a transformação do meio de

comunicação «bruto» em uma linha livre de erros de transmissão para a camada de Rede.
Ela efetua esta função através do fracionamento das mensagens recebidas do emissor em
unidades de dados denominadas quadros, que correspondem a algumas centenas de bytes.
Estes quadros são transmitidos seqüencialmente e vão gerar quadros de reconhecimento
enviados pelo receptor. Nesta camada, as unidades de dados são enriquecidas com um
conjunto de bits adicional (no início e fim de cada quadro) de modo a permitir o
reconhecimento destes.
Um problema típico deste nível é o da ocorrência de uma perturbação sobre a linha
de transmissão que provoque a destruição (perda) do quadro enviado. Neste caso, o quadro
deve ser retransmitido para garantir a integridade da informação transferida. Por outro lado,
deve-se também evitar múltiplas retransmissões de um mesmo quadro, o que pode
provocar a sua duplicação... por exemplo, se o quadro de reconhecimento é perdido.
Uma outra função desta camada é evitar uma alta taxa de envio de dados da parte do
emissor no caso do sistema emissor não ter capacidade de absorver a informação à mesma
taxa. Este mecanismo deve permitir informar ao emissor a necessidade de armazenamento
dos dados a transmitir (controle de fluxo).
A Camada de Rede é responsável da gestão de sub-redes; ela define a forma como

os pacotes de dados serão encaminhados do emissor ao receptor. Os caminhos a serem
utilizados podem ser definidos em função de tabelas estáticas ou determinados
dinamicamente no momento de cada diálogo em função das condições de tráfego da rede.
Esta camada deve ainda efetuar a gestão dos problemas de congestionamento provocados
pela presença de uma quantidade excessiva de pacotes de dados na rede. Ela deve,
finalmente, resolver todos os problemas relacionados à interconexão de redes heterogêneas,
particularmente:
• incompatibilidades no endereçamento;
• incoerências em relação aos tamanhos das mensagens;
• etc.
A Camada de Transporte recebe os dados enviados da camada de sessão,

decompô-los, se for o caso, em unidades de dados menores e garantir que todas as partes
da mensagem vão ser transmitidas corretamente à outra extremidade. Esta função deve ser
suprida de maneira eficiente, inclusive, sem que a camada de Sessão tome conhecimento
de possíveis alterações na tecnologia da parte material da rede.
— 2.5 —
Esta camada cria, normalmente, uma conexão de rede para cada conexão de
transporte requerida pela camada de Sessão, embora, se as necessidades de velocidade
transmissão são justificadas, ela possa estabelecer diversas conexões de rede para uma
mesma conexão de transporte. Por outro lado, se o custo da manutenção de uma conexão
de rede é considerado elevado, esta camada pode efetuar a função inversa, ou seja, a
multiplexação de várias conexões de transporte sobre uma mesma conexão de rede, esta
tarefa sendo feita de modo transparente para a camada de Sessão.
Ela deve determinar, também, o tipo de serviço oferecido à camada de Sessão e, por
conseqüência, aos usuários da rede. Uma conexão de transporte típica é aquela de um
canal ponto-a-ponto, livre de erros de transmissão, transmitindo as mensagens na mesma
ordem em que elas foram enviadas. Por outro lado, outras classes de serviços podem
fornecer uma conexão capaz de enviar as mensagens de modo isolado, mas sem a garantia
de uma ordem correta na transmissão. O tipo do serviço a ser fornecido é definido no
momento do estabelecimento da conexão.
Uma característica desta camada é que ela implementa um verdadeiro diálogo fim-a-
fim, ou seja, o programa executando no sistema fonte dialoga com o programa executando
na máquina destino através dos cabeçalhos e informações de controle contidas nas
mensagens deste nível. Já nas camadas mais baixas, os protocolos operam entre máquinas
vizinhas e não entre os sistemas fonte e destino, dado que estes podem estar separados por
vários IMPs. Esta diferença fundamental, que se estende igualmente às camadas superiores
(até a camada 7) pode ser verificada pela ilustração da figura 2.3.
Dado que esta camada é responsável do estabelecimento e término das conexões
de rede, ela deve definir um mecanismo de endereçamento que permita a um sistema
indicar com qual sistema ele deseja dialogar.
Finalmente, ela deve implementar um mecanismo de controle de fluxo fim-a-fim para
evitar que o sistema fonte envie mensagens numa taxa superior àquela com a qual o sistema
destino pode consumi-las.
A Camada de Sessão é responsável dos estabelecimentos de sessões de diálogo

para os usuários da rede. Uma sessão objetiva permitir o transporte de dados, da mesma
forma que os serviços oferecidos pela camada de Transporte, mas ela oferece serviços
mais sofisticados de comunicação que podem ser úteis a determinadas aplicações. Um
exemplo disto é a possibilidade de envio, através de uma sessão, de um arquivo de dados
(ou programa) de um sistema a outro. Outro serviço da camada de Sessão é efetuar a
gestão do diálogo, ou seja, definir, por exemplo, se o diálogo vai ser efetuado em modo uni-
ou bidirecional.
Um serviço também importante é aquele da sincronização do diálogo. Por exemplo,
se um arquivo deve ser transferido através de uma sessão e este deve durar duas horas.
Se, por uma razão qualquer, o tempo médio entre duas panes é de uma hora. Após uma
primeira interrupção por pane, a transferência deverá reiniciar, podendo ocasionar em erros
de transmissão. Uma forma de evitar isto é a inserção de pontos de teste junto aos dados
fazendo com que, após uma interrupção de transferência, os dados sejam retomados
apenas a partir do último ponto de teste.
A Camada de Apresentação utiliza algumas funções freqüentemente necessárias de

modo a poupar o usuário deste trabalho. Esta camada assume particularmente as funções
associadas à sintaxe e à semântica dos dados transmitidos. Um exemplo típico das funções
efetuadas por esta camada é a codificação da informação num padrão bem definido (ASCII,
EBCDIC, etc...).
Esta camada pode ainda suprir outras funções associadas à compreensão dos
dados, se utilizando do conhecimento do significado da informação para reduzir a quantidade
de informação enviada, inclusive para implementar funções de confidencialidade e de
autenticação.
— 2.6 —
A Camada de Aplicação implementa um conjunto de protocolos bastante

diversificado e orientado a aplicações bem definidas. Um exemplo disto é o protocolo de
terminal virtual, que permite gerar a utilização de um determinado programa (por exemplo,
um editor de textos) de forma independente do tipo de terminal conectado à rede. Outro
serviço importante é o de transferência de arquivos, que permite adaptar o tipo do arquivo
transferido à forma implementada pelo sistema de arquivamento do sistema considerado.
Na parte dedicada a esta camada veremos, além destas, outras classes de serviços
implementados a este nível.
5. A COMUNICAÇÃO NO OSI
A forma como os dados são transferidos ao longo do modelo OSI é ilustrada na figura
2.4. Como se pode ver, o processo emissor vai enviar uma certa quantidade de dados ao
processo receptor.
Ele envia, então, os dados à camada de Aplicação que introduz a estes um cabeçalho
de aplicação, AH, e envia a mensagem resultante à camada de Apresentação.
Esta camada, por sua vez, introduz à mensagem recebida um cabeçalho de
apresentação, PH, enviando a mensagem, em seguida à camada inferior. É importante
ressaltar aqui que esta camada não toma conhecimento da existência e significado do
cabeçalho de aplicação, considerando este como parte dos dados compondo a mensagem.
Este processo de transferência de camada a camada vai se repetindo até o nível físico,
quando os dados serão, enfim, transmitidos ao sistema destino.
Neste sistema, os diversos cabeçalhos introduzidos nas camadas de rede do
sistema fonte vão sendo interpretados e eliminados nas camadas correspondentes até que
os dados cheguem ao processo receptor.
O conceito fundamental da transferência de dados é que cada camada foi projetada
como se ela fosse realmente horizontal, quando na verdade a transmissão se dá de modo
vertical.
Isto fica claro, por exemplo, quando a camada de Transporte emissora recebe um
dado da camada de Sessão; ela insere um cabeçalho de transporte e envia a mensagem à
camada de Rede emissora. Este processo, portanto, para a camada de Transporte, não é
mais do que um detalhe técnico. Um exemplo análogo é aquele de um diplomata de um país
fazendo um discurso, na sua própria língua, nas Nações Unidas. Este considera estar se
dirigindo aos seus colegas diplomatas de outros países, embora, na prática, ele esteja
dirigindo-se ao seu intérprete.
PROCESSO PROCESSO
EMISSOR DADOS RECEPTOR
Aplicação AH DADOS Aplicação
Apresentação PH DADOS Apresentação
Sessão SH DADOS Sessão
Transporte TH DADOS Transporte
Rede NH DADOS Rede
Enlace LH DADOS Enlace
Física BITS Física
Figura 2.4 - Ilustração da comunicação no modelo OSI.
— 2.7 —
6. OS CONCEITOS DO MODELO OSI
Como visto anteriormente, o objetivo de cada camada definida no modelo OSI é

fornecer um determinado conjunto de serviços à camada imediatamente superior. A nível do
modelo de referência OSI, foi feita uma série de definições que vão permitir identificar cada
componente do modelo de forma clara e não ambígua. É objetivo desta seção introduzir
estes conceitos.
6.1. Terminologia OSI
A nível de cada camada existem elementos ativos que implementam os serviços e

protocolos relacionados com aquela camada. A estes elementos ativos, dá-se o nome de
entidade e estas podem ser entidades de software ou de hardware. Às entidades localizadas
em diferentes sistemas, mas associadas a um mesmo nível (ou camada), dá-se o nome de
entidades pares. As entidades recebem também uma denominação complementar em
função da camada à qual elas estão relacionadas — por exemplo, entidade de aplicação,
entidade de apresentação, etc...
As entidades de uma camada N (ou entidades N) implementam um serviço que é
utilizado pela camada N+1. Assim, a camada N é dita ser um fornecedor de serviço e a
camada N+1 é denominada um usuário de serviço.
Por outro lado, a camada N poderá utilizar os serviços da camada imediatamente
inferior, a camada N-1 para oferecer os serviços à camada superior. Ela pode ainda oferecer
diferentes categorias (ou classes) de serviços: serviços mais eficientes e mais «caros» ou
serviços lentos e «econômicos».
Os serviços oferecidos por uma camada são acessíveis em pontos de acesso aos
serviços, ou SAP (service access point). Os SAPs da camada N são os lugares onde a
camada N+1 poderá ter acesso aos serviços oferecidos, cada SAP sendo identificado por
um endereço único. Por exemplo, os SAP de uma rede telefônica são as tomadas às quais
podem ser conectados os aparelhos telefônicos e seus endereços são os números de
telefone associados à tomada considerada.
Para que duas camadas possam trocar informações, existe uma série de regras a
serem respeitadas, definidas pela interface. Através de uma interface, a camada N+1 envia
uma unidade de dados de interface, ou IDU (Interface Data Unit) à entidade da camada N
pelo SAP. A IDU é composta de uma parte denominada unidade de dados de serviço, ou
SDU (Service Data Unit) e de outras informações de controle. A SDU é a informação
transmitida via rede à entidade par e, em seguida, à camada N+1. A informação de controle é
utilizada para auxiliar a gestão da camada inferior em seu trabalho (por exemplo, o número
de bytes compondo a SDU correspondente).
Para transmitir uma SDU, a entidade da camada N pode fragmentá-la em diversas
partes, e cada parte vai receber um cabeçalho, sendo enviada como uma unidade de dados
de protocolo, ou PDU (Protocol Data Unit). Os cabeçalhos de PDU são utilizados pelas
entidades pares para o transporte do protocolo. Elas identificam a PDU contendo os dados e
aquelas contendo informações de controle (números de seqüência, contagens, etc...). A
figura 2.5 ilustra o processo descrito. As PDUs recebem normalmente uma denominação
segundo a camada à qual estão associadas. Por exemplo, as PDUs de aplicação são ditas
APDU, assim como as de apresentação são as PPDU, as de sessão SPDU, e assim por
diante.
6.2. Serviços orientados conexão e sem conexão
Como já foi dito, as camadas podem oferecer diferentes classes de serviços às

camadas superiores, estes serviços podendo ser orientados conexão ou sem conexão.
No que diz respeito ao serviços orientados à conexão, podemos citar, como exemplo
típico o sistema telefônico. Para que seja possível falar a alguém no telefone, é necessário,
— 2.8 —
inicialmente, tirar o fone do gancho, digitar (ou discar) um número, esperar que o interlocutor
atenda, falar e, finalmente, desligar.
Este é o princípio de base de um serviço orientado conexão: estabelecimento da
conexão, utilização do serviço e término da conexão. O aspecto principal da conexão é o fato
de que ela funciona como uma espécie de canal através do qual irão transitar os objetos ou
mensagens envolvidas na realização do serviço.
Já os serviços sem conexão são estruturados como o sistema postal, onde cada
mensagem (ou carta, se consideramos o exemplo citado) contém o endereço do destinatário
e é então encaminhada no sistema, independente de outras.
Normalmente, se duas mensagens são enviadas a um mesmo destinatário, a primeira a ser
enviada deve ser a primeira a ser recebida. Por outro lado, neste modo de serviço pode
ocorrer que uma mensagem seja atrasada fazendo com que a segunda mensagem seja
recebida primeiro. Já nos serviços orientados conexão, isto jamais poderá acontecer.
Cada serviço é caracterizado por uma qualidade de serviço. Um serviço dito confiável
é aquele em que os dados não podem ser jamais perdidos. Normalmente, a implementação
de serviços confiáveis é feita através da definição de mensagens de reconhecimento
enviadas pelo receptor, para cada mensagem recebida do emissor. Este processo, embora
extremamente benéfico, introduz uma lentidão na transferência de dados, o que significa que
nem sempre ele é desejável num sistema.
Os serviços confiáveis orientados conexão apresentam duas variantes. No primeiro
caso, as fronteiras das mensagens são sempre preservadas. Se duas mensagens de 1
Kbytes são enviadas, elas chegarão sob a forma de duas mensagens de 1 Kbytes e nunca
como uma única mensagem de 2 Kbytes.
Já na segunda variante, se uma mensagem de 2 Kbytes é recebida, não há como
identificar se ela foi enviada realmente como uma única mensagem de 2 Kbytes, como duas
mensagens de 1 Kbytes, ou ainda como 2048 mensagens de 1 byte.
IDU
Camada
N+1 ICI SDU
SAP
Interface
Cabeçalho
Camada
N ICI SDU SDU
N-PDU
Figura 2.5 - Ilustração dos diferentes conceitos associados ao modelo de referência OSI.
Em algumas aplicações, é necessário resguardar as fronteiras entre as mensagens

enviadas; por exemplo, no caso do envio de um documento a uma impressora é interessante
poder preservar as fronteiras entre as páginas.
No que diz respeito aos dois tipos de serviços (orientados conexão e sem conexão),
nem todas as aplicações requerem a utilização de conexão. Um exemplo disto pode ser o de
uma aplicação de correio eletrônico. Pode-se imaginar uma aplicação de correio em que o
usuário não se interesse à necessidade de estabelecimento de conexão e tampouco a uma
confiabilidade de 100% no que diz respeito à chegada das mensagens. Os serviços sem
conexão e não-confiáveis são denominados serviços de datagrama.
— 2.9 —
Existem casos, porém, em que, apesar de não necessitar o estabelecimento de

conexão, a confiabilidade é essencial. O serviço utilizado neste caso é dito de datagrama
com reconhecimento.
O serviço de pedido-resposta já é um outro tipo de serviço no qual o emissor envia
um datagrama contendo um serviço e o receptor envia um outro contendo a resposta a este
pedido.
A tabela a seguir ilustra os diferentes serviços com e sem conexão, com exemplos
de aplicação destes serviços.
SERVIÇOS MODALIDADES EXEMPLO

Transf. confiável de mensagens com ou sem conexão seqüenciamento de páginas
Transf. confiável de dados com ou sem conexão transferência de arquivos
Transf. sem controle de erros com ou sem conexão voz digitalizada
Datagrama s/ reconhecimento sem conexão correio eletrônico
Datagrama c/ reconhecimento sem conexão corr. eletrônico «registrado»
Pedido-Resposta sem conexão consulta a bases de dados
7. AS PRIMITIVAS DE SERVIÇO
Um serviço é definido formalmente por um conjunto de primitivas (ou operações)

disponíveis a um usuário ou a outras entidades para o acesso àquele serviço. Estas
primitivas permitem indicar a ação a ser executada pelo serviço ou ainda um pedido de
informação sobre uma ação executada previamente.
No modelo OSI, as primitivas de serviço são divididas em quatro classes: as
primitivas de pedido (request), as primitivas de indicação (indication), as primitivas de
respostas (response) e as primitivas de confirmação (confirm).
A tabela a seguir mostra o significado de cada uma destas primitivas no que diz
respeito à execução de um serviço.
PRIMITIVA SIGNIFICADO
REQUEST Pedido enviado por uma entidade que solicita um serviço
INDICATION Através dela, a entidade par é informada de uma solicitação de serviço
RESPONSE A entidade par responde ao pedido de serviço
CONFIRM A entidade solicitante é informada do resultado do serviço
Um exemplo da utilização das primitivas de serviço é o pedido de um

estabelecimento de conexão. Para requisitar o estabelecimento de uma conexão, a entidade
que quer iniciar o diálogo envia uma primitiva de serviço de pedido de abertura de conexão,
«CONNECT.request» que vai se refletir, na entidade destinatária, por uma primitiva de
indicação, «CONNECT.indication».
A entidade que recebeu a indicação vai enviar uma primitiva de resposta,
«CONNECT.response», para informar se esta aceita ou não a conexão. Finalmente, a
entidade emissora vai saber do resultado do seu pedido pela recepção de uma primitiva de
serviço de confirmação, «CONNECT.confirm».
Parâmetros podem ser associados às primitivas; no caso do serviço de conexão, por
exemplo, os parâmetros podem especificar os seguintes aspectos relacionados à conexão
desejada: a máquina com a qual se deseja dialogar, o tipo de serviço desejado, o tamanho
máximo das mensagens, etc...
Se a entidade invocada não está de acordo com os parâmetros contidos na primitiva
de indicação recebida, esta pode fazer uma contra-proposta, através dos parâmetros da
primitiva de resposta, que será transmitida à entidade emissora através dos parâmetros da
primitiva de confirmação.
— 2.10 —
Os serviços no modelo OSI podem ser de dois tipos: confirmados ou não-

confirmados. No caso dos serviços confirmados, as quatro classes de primitivas são
definidas, ou seja, pedido (request), indicação (indication), resposta (response) e
confirmação (confirm). Isto significa que a entidade que requisitou o serviço terá sempre uma
informação sobre as condições de realização deste, até mesmo se este foi realizado com
sucesso ou não.
Nos serviços não-confirmados, apenas as duas primeiras classes de primitivas são
utilizadas, ou seja, pedido e indicação. Neste tipo de serviços, a entidade emissora do pedido
não receberá nenhuma informação sobre as condições de realização do serviço requisitado,
nem mesmo se este foi realizado.
A tabela a seguir apresenta um conjunto de primitivas associadas a um serviço
orientado à conexão.
CONNECT.request pedido de estabelecimento de uma conexão
CONNECT.indication indicação à entidade invocada
CONNECT.response utilizada para indicar a aceitação ou não da conexão
CONNECT.confirm informa à entidade emissora se a conexão é aceita
DATA.request pedido de envio de dados
DATA.indication sinalização da chegada de dados
DISCONNECT.request pedido de término da conexão
DISCONNECT.indication indicação do pedido à entidade par
Neste exemplo, CONNECT é um serviço confirmado enquanto os serviços DATA e

DISCONNECT são não-confirmados. A figura 2.6 permite ilustrar as trocas de primitivas de
serviço entre as camadas no caso de um serviço confirmado. O exemplo utilizado é o
serviço CONNECT.
SISTEMA A SISTEMA B
Camada N+1 Camada N+1
connect.req connect.rsp
connect.cnf connect.ind
Camada N Camada N
Figura 2.6 - Ilustração da troca de primitivas de serviço (confirmado).
— 2.11 —
Capítulo 3
AS SETE CAMADAS DO M ODELO OSI
1. INTRODUÇÃO
A definição de um modelo de referência para a interconexão de sistemas abertos, o

modelo OSI foi, sem dúvida, uma contribuição positiva para a padronização das arquiteturas
de comunicação.
Entretanto, a definição das camadas presentes do modelo OSI está relacionada à
definição de soluções em termos de serviços e protocolos que implementem as funções
relacionadas a cada uma destas camadas.
O objetivo desta parte é apresentar os principais problemas e as respectivas
soluções relacionadas com cada uma das camadas do modelo OSI.
Como poderá ser visto ao longo desta parte, as sete camadas do modelo OSI podem
ser organizadas em duas classes distintas:
• as camadas baixas, que compreendem desde a camada física até a camada de

transporte e cujos serviços e protocolos estão relacionados com a transmissão
dos dados propriamente dita;
• as camadas altas, que compreendem desde a camada de sessão até a camada
de aplicação, cujos serviços e protocolos são mais orientados a resolver questões
envolvendo as aplicações que irão utilizar o suporte de comunicação considerado.
2. A CAMADA FÍSICA
O objetivo da camada Física é assegurar o transporte dos dados, representados por

um conjunto de bits, entre dois equipamentos terminais, via um suporte de transmissão.
Abordaremos, nesta parte do documento, os principais aspectos e problemas
relacionados à transmissão de dados, como, os suportes de transmissão, os modos de
transmissão, a multiplexação e a comutação.
Ainda nesta seção, serão vistos alguns exemplos de interfaces físicas padronizadas
e adotadas em muitas aplicações e arquiteturas de comunicação.
2.1. Os Suportes de Transmissão
Os suportes de transmissão podem se caracterizar pela existência ou não de um

guia físico. Na primeira classe estão os cabos elétricos, as fibras óticas e, na segunda
classe, as ondas de rádio, as ondas de luz, etc...
2.1.1. O par de fios trançados
Em diversas aplicações, é necessário se manter uma conexão direta e permanente

entre dois computadores. O suporte de transmissão mais clássico utilizado até o momento é
— 3.1 —
CAP. 3 — AS SETE CAMADAS DO MODELO OSI PROF. VITÓRIO BRUNO MAZZOLA
o par de fios trançados, o qual é composto de dois fios elétricos em cobre, isolados, e
arranjados longitudinalmente de forma helicoidal. Esta técnica de enrolar os fios permite
diminuir os efeitos das induções eletromagnéticas parasitas provenientes do ambiente no
qual este estiver instalado.
A utilização mais típica deste suporte de transmissão é a rede telefônica, onde,
graças às suas características elétricas, os sinais podem percorrer várias dezenas de
quilômetros, sem a necessidade de amplificação ou regeneração de sinal.
Estes podem, ainda, ser utilizados para a transmissão de sinais analógicos quanto
de sinais digitais, a banda passante atingida sendo função da sua composição
(particularmente, diâmetro e pureza dos condutores, natureza dos isolantes e do
comprimento do cabo). A taxa de transmissão obtida pela utilização deste suporte de
transmissão situa-se na faixa de algumas dezenas de Kbits/s, podendo atingir, em
condições particulares, na faixa dos Mbits/s em pequenas distâncias.
O fato de representar um baixo custo e uma grande faixa de utilização o torna um dos
suportes mais utilizados atualmente e, provavelmente, nos próximos anos.
2.1.2. Os cabos coaxiais
Os cabos coaxiais são também altamente empregados como suporte de

transmissão. Dois tipos de cabos são tipicamente utilizados: o primeiro tipo apresenta uma
impedância característica de 50 ohms, utilizado nas transmissões digitais denominada
transmissão em banda de base; o segundo tipo, com uma impedância característica de 75
ohms, é mais adequado para a transmissão de sinais analógicos. Eles são constituídos de
dois condutores arranjados de forma concêntrica: um condutor central, a alma, envolto por
um material isolante de forma cilíndrica. Esta capa isolante é, por sua vez, envolta por uma
trança metálica condutora em cobre. Finalmente, o conjunto é envolto numa capa de
proteção em plástico isolante.
Em relação aos pares de fios trançados, os cabos coaxiais apresentam melhores
características elétricas, oferecendo um boa relação entre a banda passante e a proteção
contra interferências eletromagnéticas.
A largura de banda vai depender igualmente da qualidade da composição do cabo e
do seu comprimento. Para distâncias em torno de 1 km, é possível obter uma taxa de
transmissão em torno de 10 Mbits/segundo, podendo-se obter taxas superiores para
distâncias mais curtas. Os cabos coaxiais são altamente utilizados como suporte de
transmissão nas Redes Locais Industriais.
A informação transmitida pelos cabos coaxiais é geralmente codificada sob a forma
de um sinal binário, onde os dígitos 0 e 1 são representados por dois diferentes níveis... por
exemplo, 1 volt para o bit 1 e 0 volt para o bit 0. Esta forma de codificação, embora seja uma
convenção bastante adequada, não permite ao receptor do sinal detectar o início e o fim da
transmissão de um dígito binário.
2.1.3. As fibras óticas
As fibras óticas são o meio de transmissão pelo qual os sinais binários são
conduzidos sob a forma de impulsos luminosos. Um impulso luminoso representa um bit a
1, enquanto a ausência deste impulso representa um bit a 0. A luz visível é uma onda
luminosa cuja freqüência está na ordem de 108 Hz, o que dá ao sistema uma banda
passante potencial bastante grande. As taxas de transmissão num suporte a fibra ótica ficam
na faixa dos Gbit/s (109 bit/s).
Um sistema de transmissão a base de fibra ótica é composto de três principais
elementos: o suporte de transmissão (a fibra ótica), o dispositivo de emissão e o dispositivo
de recepção da onda luminosa.
A fibra ótica é constituída de um fio de vidro bastante fino, à base de silício e outros
componentes. Ela consiste de um núcleo no qual se propaga a luz e uma capa externa de
proteção que mantém a luz no interior do núcleo. O dispositivo de emissão consiste, ou de
— 3.2 —
um diodo emissor de luz (LED) ou de um diodo laser. O dispositivo de recepção é

constituído geralmente de um fotodiodo ou de um fototransistor.
O princípio da transmissão das fibras óticas é o da reflexão da luz na interface entre
dois meios. Quando um raio luminoso deixa um meio homogêneo para se propagar num
outro meio, o seu percurso sofre um desvio na interface entre os dois meios. Entretanto,
existe um ângulo de incidência limite, a partir do qual o raio luminoso, ao invés de ser
refratado ele será refletido na interface, sendo mantido no meio no qual ele havia sido
introduzido. Desta forma, a luz poderá ser propagada ao longo do meio, em distâncias de
alguns quilômetros.
Atualmente, os suportes de comunicação à base de fibra ótica são utilizados em
redes de comunicação em longa distância, substituindo sistemas mais antigos à base de
cabos coaxiais. Isto deverá continuar a ocorrer nos próximos anos, contribuindo para que se
tenha, num futuro próximo, em distâncias relativamente grandes, sistemas de comunicação
oferecendo altas taxas de transmissão garantindo assim o salvamento de grandes volumes
de informação.
2.2. Aspectos da Transmissão de Dados
O meio de transmissão consiste geralmente de um conjunto de recursos e regras

que permitem a transmissão de informação de um ponto a outro numa rede de
comunicação. A transmissão a nível de bit é uma das formas mais simples de transferência
de informação. Este processo é ilustrado pela figura 3.1(a), onde podemos observar os
seguintes elementos:
• a fonte de informação, que pode ser um computador ou um terminal, por exemplo,

que gera as informações que deverão ser transmitidas, estas sendo
representadas, usualmente, por um conjunto de dígitos binários, ou bits;
• o transmissor, que é responsável da adaptação ou conversão do conjunto de
informações, de bits, para sinal elétrico ou eletromagnético, adaptando-o ao meio
de transmissão;
• o suporte de transmissão, encarregado do transporte dos sinais representando a
informação e que pode ser caracterizado por uma das técnicas apresentadas na
seção precedente; é o suporte de transmissão quem realiza a “ligação física”
entre os elementos envolvidos na comunicação;
RUÍDO
DESTINATÁRIO
FONTE DE
RECEPTOR DA
INFORMAÇÃO TRANSMISSOR SUPORTE DE TRANSMISSÃO
INFORMAÇÃO
BINÁRIA
BINÁRIA
(a)
RUÍDO
FONTE OU FONTE OU
DESTINATÁRIO TRANSMISSOR TRANSMISSOR DESTINATÁRIO
SUPORTE DE TRANSMISSÃO
INFORMAÇÃO RECEPTOR INFORMAÇÃO
RECEPTOR
BINÁRIA BINÁRIA
(b)
Figura 3.1 - (a) Sistema de transmissão ponto-a-ponto unidirecional; (b) modelo bidirecional.
— 3.3 —
• o receptor, responsável pela reconstituição da informação a partir dos sinais

recebidos via suporte de transmissão, e que, inclusive pode ter sofrido distorções
provocadas por ruídos existentes no meio;
• o destinatário da informação, que pode ser um computador, um terminal ou outro
equipamento e que vai consumir a informação gerada pelo elemento fonte.
Geralmente, a transmissão a nível de bits pode ser realizada de forma bidirecional,

esta podendo ainda ser realizada de forma alternada ou simultânea. Assim, a cada nó deverá
estar associado um equipamento transmissor e um receptor compondo o conjunto
transceptor como mostrado na figura 3.1(b).
A transmissão de dados, quando realizada nos dois sentidos é denominada duplex.
No caso em que ela se realiza alternadamente, ou seja, ora num sentido, ora no outro, ela se
denomina half-duplex. No caso em que ela se realiza simultaneamente nos dois sentidos,
esta será denominada full-duplex.
Os modos de transmissão caracterizam as diferentes formas como os bits de
informação transmitidos são delimitados e encaminhados ao longo da linha de comunicação.
No que diz respeito à forma como os bits são encaminhados ao longo de uma linha
de comunicação, pode-se distinguir o modo de transmissão paralelo e o modo serial,
conforme já mencionado anteriormente.
Na transmissão paralela, os bits são transportados simultaneamente por um suporte
composto de várias linhas em paralelo. É um modo de transmissão mais adequado à
comunicação entre equipamentos localizados a curtas distâncias. A ligação interna na
arquitetura de computadores ou entre computadores e periféricos próximos são exemplos da
aplicação da transmissão paralela.
Na transmissão serial, mais adequada a comunicação entre equipamentos
separados por grandes distâncias, os bits são encaminhados serialmente através de uma
única linha de comunicação.
Pode-se considerar outros parâmetros para a classificação dos modos de
transmissão, como, por exemplo, o fator tempo. No caso particular das transmissões
seriais, a forma de delimitar os bits pode levar em conta duas diferentes filosofias — a
transmissão síncrona e a transmissão assíncrona.
Na transmissão síncrona, os bits de dados são transmitidos segundo uma cadência
pré-definida, obedecendo a um sinal de temporização (clock). O receptor, por sua vez,
conhecendo os intervalos de tempo permitindo delimitar um bit, poderá identificar a
seqüência dos bits fazendo uma amostragem do sinal recebido.
Na transmissão assíncrona, não existe a fixação prévia de um período de tempo de
emissão entre o transmissor e o receptor. A separação entre os bits é feita através de um
sinal especial com duração variável. Um caso típico de transmissão assíncrona é a
transmissão de caracteres; neste caso, a cada grupo de bits constituindo um caractere são
adicionados bits especiais para representar o início (start bit) e final deste (stop bit). Neste
tipo de comunicação, apesar de assíncrona ao nível de caracteres, ocorre uma
sincronização ao nível de bit.
Um outro aspecto a ser destacado aqui é aquele da forma como os sinais são
transmitidos num suporte de comunicação, particularmente no que consiste à maneira como
a banda passante do canal de comunicação é explorada.
No primeiro modo, a transmissão em banda de base (baseband), a banda passante
do suporte de transmissão é atribuída totalmente a um único canal de transmissão. Neste
modo, os sinais são transmitidos através do meio de comunicação multiplexados no tempo.
No segundo modo, a transmissão em barda larga (broadband), a banda passante do
suporte de transmissão é dividida num determinado número de canais de faixa de freqüência
estreita, permitindo que estes possam então ser transmitidos utilizando uma técnica de
multiplexação em freqüência. A banda passante dos canais é normalmente definida em
função da taxa de transmissão desejada e do modo de modulação empregado. Neste modo
— 3.4 —
de transmissão, cada canal pode atingir uma taxa de transmissão de até 3 Mbits/s, inferior,
portanto, à transmissão em banda de base.
3. A CAMADA DE ENLACE DE DADOS
A camada de Enlace de Dados tem por função oferecer um caminho para o

transporte das informações entre entidades da Camada de Rede, que será estudada na
parte seguinte do documento. Dentre os fatores com os quais a camada de Enlace deve
preocupar-se estão:
• a forma como os bits provenientes da camada Física serão agrupados em
quadros;
• os mecanismos de detecção e correção de erros a serem implantados, uma vez
que as informações trocadas através da camada Física não são isentas de erros
de transmissão, pelos fatores que foram levantados na parte anterior deste
documento;
• os mecanismos de controle de fluxo para limitar o volume de informação trocados
entre entidades fonte e destino;
• a gestão das ligações entre as entidades.
3.1. As Classes de Serviços de Enlace
A camada de Enlace de Dados oferece serviços classificados em três principais

categorias, estas dependendo do sistema no qual elas serão implantadas:
• serviço sem conexão e sem reconhecimento;
• serviço sem conexão com reconhecimento;
• serviço orientado à conexão.
Na primeira classe de serviços, a máquina fonte da informação envia os quadros de

dados à máquina destinatária sem recepção de reconhecimento da informação enviada;
além disso, não existe estabelecimento prévio de conexão e, por conseqüência, não existe
liberação desta ao final do diálogo. Se um quadro de dados é perdido no suporte de
transmissão como conseqüência de um ruído, não existe nenhum mecanismo que permita
solucionar o problema. Esta classe de serviços é adequada quando implantados sobre um
suporte de comunicação cuja taxa de erros é muito baixa ou que a correção dos erros é
prevista nas camadas superiores. Eles podem ser empregados particularmente no caso de
aplicações tempo real e em redes locais.
A segunda classe de serviços, embora ainda não defina o estabelecimento prévio de
conexão, prevê a existência de quadros de reconhecimento, de modo que a máquina fonte
será notificada pela máquina destinatária da recepção do quadro previamente enviado. Um
mecanismo que pode ser implantado no caso de perda do quadro — o que corresponde à
não recepção do quadro de reconhecimento após um certo tempo (timeout) — é a
retransmissão daquele. Num serviço sem conexão, existe a possibilidade da retransmissão
de quadros provocando a recepção múltipla do mesmo quadro (duplicação de mensagem).
A terceira classe de serviços é a mais sofisticada, uma vez que ela define a
necessidade do estabelecimento prévio de conexão e a liberação destas ao final do diálogo.
Neste caso, cada quadro enviado é numerado e a camada de Enlace garante que cada
quadro enviado será recebido, uma única vez, e que o conjunto de quadros enviados será
recebido ordenado da mesma forma que foi enviado. Esta classe de serviços oferece à
camada de Rede um canal de comunicação confiável.
Os serviços orientados conexão são caracterizados por três principais etapas:
• a etapa de estabelecimento de conexão, durante a qual são definidos todos os
parâmetros relacionados à conexão, como por exemplo, os contadores de
seqüência de quadros;
— 3.5 —
• a etapa de transmissão de dados, durante a qual são realizadas todas as trocas

de informação correspondentes ao diálogo entre duas máquinas;
• a etapa de liberação da conexão, que caracteriza o fim do diálogo e na qual todas
as variáveis e outros recursos alocados à conexão serão novamente disponíveis.
A comunicação entre as camadas de Rede e de Enlace é feita através de primitivas

de serviço (request, indication, response e confirm) como definidas na parte relativa à
apresentação do modelo OSI. Um esquema permitindo demonstrar o modo de utilização das
primitivas é mostrado na figura 3.2. Neste esquema, representa-se nas extremidades a
camada de Rede, caracterizada pelos dois sistemas envolvidos no diálogo (no caso, A e B)
e no centro a camada de Enlace.
Os deslocamentos verticais das primitivas representam o tempo decorrido entre as
ocorrências destas. Por exemplo, no caso das primitivas de request e indication, o tempo
decorrido entre o envio da primeira pela camada de Rede do sistema A e a recepção da
segunda pela camada de Rede do sistema B.
3.2. O conceito de quadro
Para que o serviço seja oferecido à camada de Rede, a camada de Enlace utiliza-se
dos serviços fornecidos pela camada Física que, como já foi descrito na parte precedente, é
responsável da transmissão de bits de um ponto a outro na rede de comunicação, sendo
que o conjunto de bits transmitido pode sofrer distorções produzindo erros de transmissão.
Uma conseqüência típica pode ser que o número de bits recebidos seja inferior ao
número de bits enviados ou os valores de alguns bits podem ter sido modificados.
Com o objetivo de permitir um controle de erro eficiente, a camada de Enlace
decompõe as mensagens em porções menores denominadas quadros, aos quais são
adicionados códigos especiais de controle de erro. Desta forma, o receptor pode verificar se
o código enviado no contexto de um quadro indica ou não a ocorrência de erros de
transmissão e ele pode, assim, tomar as providências necessárias para evitar as
conseqüências devido àquele erro.
A definição e delimitação dos quadros pode obedecer a diferentes políticas. Uma das
políticas adotadas pode ser a contagem de caracteres. Nesta política, é introduzido um
caractere especial que indica o número de caracteres compondo o quadro. Deste modo, a
nível da camada de Enlace do receptor, basta que a entidade leia este caractere e em
seguida conte o número de caracteres para definir o tamanho do quadro. O inconveniente
desta técnica, portanto, é o fato de que o caractere que define o tamanho do quadro pode ser
modificado, o que significa que o receptor vai ler, erroneamente os quadros transmitidos. A
figura 3.3 ilustra este problema.
camada de rede camada de enlace camada de rede
request
indication
response
confirm
sistema A sistema B
Figura 3.2 - Primitivas de serviço trocadas entre as camadas de Rede e de Enlace.
— 3.6 —
contadores de caracteres
(a) 5 1 2 3 4 5 6 7 8 9 8 0 1 2 3 4 5 6
quadro1 (5 car.) quadro2 (5 car.) quadro3 (8 car.)
erro contador de caracteres
(b) 5 1 2 3 4 7 6 7 8 9 8 0 1 2 3 4 5 6
Figura 3.3 - Sequência de caracteres: (a) sem erro; (b) com erro.
Uma técnica que apresenta uma solução a este problema consiste na adição de
seqüências especiais de caracteres de modo a representar o início e fim da transmissão de
um quadro.
A figura 3.4 ilustra um caso relativo a esta técnica, onde a seqüência de caracteres
DLE (Data Link Escape) e STX (Start of TeXt) é inserida para representar o início de um
quadro e a seqüência DLE e ETX (End of TeXt) para representar o fim do quadro. Esta
técnica apresenta, ainda, um ponto de vulnerabilidade: se, dentro do texto, dado que os bits
podem assumir qualquer combinação de valores, uma seqüência de bits coincide com uma
das seqüências de caracteres citada, a entidade receptora na camada de Enlace pode ser
“enganada” por esta seqüência e, assim, receber erroneamente o quadro.
A solução a este problema vem através da introdução, pela entidade de Enlace
emissora, de um caractere DLE a cada vez que, uma seqüência de bits correspondente à
parte de dados, coincidir com um caractere DLE. Desta forma, basta à entidade de dados
receptora eliminar os caracteres DLE dos dados antes de transmití-los à camada de Rede.
Isto vai permitir então, às entidades receptoras de Enlace, fazer a distinção entre as
seqüências delimitadoras de quadro (DLE-STX e DLE-ETX) das seqüências «acidentais»
nos dados. Os caracteres DLE introduzidos a nível dos dados são denominados caracteres
de transparência.
Uma técnica ainda utilizada e definida mais particularmente para a utilização em
redes de comunicação é aquela em que os quadros são delimitados por uma seqüência de
bits particular, mas desta vez dissociados da codificação de caracteres. A seqüência
01111110 é adotada para representar a delimitação dos quadros.
De maneira análoga à utilização dos caracteres de transparência da técnica anterior,
bits de transparência são introduzidos a nível da parte de dados para evitar a confusão, por
parte do receptor, com os delimitadores de quadro. Assim, no receptor, a cada vez que 5 bits
“1” consecutivos são detectados na parte de dados, um bit 0 é adicionado após a seqüência.
Do lado do receptor, a cada vez que ocorrer uma seqüência de 5 bits “1” consecutivos de
dados seguidos de um bit 0, este último será eliminado da parte de dados. A figura 3.5 ilustra
a aplicação desta técnica. Em 3.5(a) são apresentados os dados originais e, em 3.5(b), os
mesmos dados com a introdução dos bits de transparência.
3.3. O controle de erro
Os erros podendo ocorrer sobre os suportes de transmissão podem ter como

causas os mais diversos fenômenos físicos, como por exemplo, o ruído térmico, provocado
pela agitação dos elétrons nos cabos de cobre. Outro fenômeno importante são os ruídos
impulsivos, capazes de provocar, numa linha transmitindo dados a 9600 bit/s, a perda de 96
— 3.7 —
bits. Os ruídos impulsivos são causados pelos arcos devido ao chaveamento de relês ou
outros dispositivos eletromecânicos.
O que se tem notado, entretanto, é que, independentemente do fenômeno causador
de erro, estes tendem a gerar normalmente verdadeiros pacotes de erros e não erros
simples.
Isto pode ter um aspecto positivo, uma vez que, num conjunto relativamente grande
de bits, um menor número de pacotes vai conter erros. Por outro lado, os erros agrupados
em pacotes são mais difíceis de modelizar e de detectar.
O controle de erros de transmissão é uma das funções mais importantes
asseguradas pela camada de enlace. Esta função é baseada na informação, à entidade
emissora da mensagem do que ocorreu na extremidade de recepção.
Os protocolos de controle de erro são caracterizados, em geral, pela definição de um
quadro de controle, correspondente a um reconhecimento positivo ou negativo.
Caso a entidade emissora receba um reconhecimento positivo de um quadro
previamente enviado, ela entende que aquele foi corretamente recebido.
Por outro lado, se ela recebe um reconhecimento negativo, ficará consciente que o
quadro foi mal transmitido e que, neste caso, ele deverá ser retransmitido.
Ainda, se, por uma intensidade relativamente forte de ruído, o quadro inteiro não é
recebido pela entidade destinatária, esta não vai reagir ao quadro emitido e a entidade
emissora corre o risco de esperar indefinidamente pelo reconhecimento — isto é evitado
pela adição de temporizadores, estabelecendo assim um tempo máximo de espera pelo
reconhecimento, antes da retransmissão. O tempo de espera deve ser determinado em
função dos atrasos relativos à transmissão dos quadros de modo que os quadros de
reconhecimento, se existentes, cheguem antes do esgotamento da temporização (timeout).
Deste modo, se o quadro ou o reconhecimento são perdidos, a temporização será
esgotada, podendo provocar a retransmissão do quadro. Neste caso, é possível que o
quadro seja aceito mais de uma vez pela camada de Enlace e transmitido à camada de Rede
— duplicação de quadros. Para evitar este problema, deve-se introduzir um mecanismo de
distinção dos quadros a fim de que o receptor possa separar os quadros duplicados de seus
originais.
(a) DLE STX A B DLE C DLE ETX
(b) DLE STX A B DLE DLE C DLE ETX
Figura 3.4 - (a) Dados enviados pela camada de Rede com seqüências de delimitação; (b) idem, com
introdução dos caracteres de transparência.
(a) 0 1 1 0 1 1 1 1 1 1 1 1 0 1
(b) 0 1 1 0 1 1 1 1 1 0 1 1 1 0 1
bit de transparência
Figura 3.5 - (a) dados originais; (b) dados com adição do bit de transparência.
— 3.8 —
3.3.1. Os códigos de correção de erro
Existem praticamente duas técnicas para a correção de erro. A primeira, consiste na

introdução, a nível dos quadros, de informações suficientemente redundantes que permitam
ao receptor reconstituir os dados enviados a partir da informação recebida. A segunda
técnica consiste em adicionar unicamente um conjunto de informações redundantes o
suficiente para que o receptor possa detectar a ocorrência de um erro (sem corrigí-lo) e
requisitar a retransmissão do quadro. Ao primeiro tipo de informação é dado o nome de
código corretor e ao segundo tipo de informação código detector.
3.3.2. Os códigos de detecção de erro
Os códigos corretores são utilizados para as transmissão de dados em casos

particulares como, por exemplo, quando os canais são unidirecionais ou quando é
impossível requisitar a retransmissão de um quadro.
Quando possível, porém, uma solução mais adequada é através de uma técnica de
detecção com retransmissão por razões de eficiência.
Um método de detecção de erros largamente utilizado é a definição de códigos de
detecção de erros polinomiais, também denominados CRC (cyclic redundancy code). Nos
códigos polinomiais, considera-se que os bits de uma cadeia de caracteres são os
coeficientes de um polinômio, coeficientes estes, capazes de assumir apenas dois valores:
0 ou 1. Assim, um bloco de k bits é visto como uma série de coeficientes de um polinômio de
k termos, indo de x k-1 a x 0. A palavra 110001 contém 6 bits — ela representa então o
seguinte polinômio: x 5 + x 4 + x 0 .
A utilização de códigos de detecção polinomiais é baseada na escolha de um código
especial que caracteriza um polinômio gerador, ou G(x). Uma exigência em relação a este
polinômio é que os bits mais significativo e menos significativo (correspondendo,
respectivamente aos coeficientes de mais alta ordem e de mais baixa ordem do polinômio)
sejam de valor 1. A técnica consiste em adicionar a um bloco de dados (caracterizando um
polinômio M(x)) um conjunto de bits de controle de modo que o quadro (dados + bits de
controle) seja divisível por G(x). Na recepção, a entidade de Enlace efetua a divisão dos bits
compondo o quadro pelo polinômio gerador. Caso o resto seja diferente de zero, é
caracterizada então a ocorrência de um erro de transmissão.
Alguns exemplos de códigos polinomiais adotados na detecção de erros são:
CRC-12 = x 12 + x 11 + x 3 + x 2 + x 1 + 1
CRC-16 = x 16 + x 15 + x 2 + 1
CRC-CCITT = x 16 + x 12 + x 5 + 1
4. A CAMADA DE REDE
O objetivo da camada de Rede é assegurar o transporte de unidades de dados

denominadas pacotes do sistema fonte ao sistema destinatário, definindo uma trajetória
apropriada. Esta trajetória pode significar a passagem por diversos nós intermediários da
rede, o que significa que a camada de Rede deve ter o conhecimento de todos os aspectos
topológicos da rede considerada e, com esta informação, ser capaz de escolher o caminho
a ser traçado pelas mensagens. Nesta escolha, é interessante que seja levado em conta o
estado corrente da rede, particularmente no que diz respeito ao tráfego das mensagens,
evitando assim a sobrecarga de certos trechos das linhas de comunicação. Ainda, se o
sistemas fonte e destinatário estão conectados a redes diferentes, estas diferenças devem
ser levadas em conta e compensadas pela camada de Rede.
Duas funções essenciais da camada de Rede, descritas brevemente aqui, refletem,
respectivamente, os problemas de roteamento e colisão serão tratados nesta parte do
— 3.9 —
documento. Os mecanismos relacionados à funções de interconexão merecerão uma parte

dedicada, mais adiante, no curso.
4.1. Serviços oferecidos pela camada de Rede
Segundo a bibliografia, uma das primeiras discussões realizadas no que diz respeito
à concepção da camada de Rede foi a questão do tipo de serviço a ser oferecido às camadas
superiores, particularmente relacionado à existência ou não de conexão.
O resultado desta discussão foi a definição, a nível do modelo OSI, de duas classes
de serviço, sem conexão e orientado à conexão, sendo que uma certa liberdade foi dada no
sentido de se definir a que nível o serviço com conexão seria implantado, ou mesmo se este
seria implantado. Abriu-se, assim, a possibilidade de se ter, nos diferentes níveis, as duas
classes de serviço, isto sendo ilustrado pela figura 3.6.
Os SAPs são localizados na interface entre duas camadas, permitindo que uma
camada tenha acesso aos serviços oferecidos pela camada inferior. Como se pode ver na
figura, da camada de Enlace para cima, os serviços podem ser sem ou orientados à
conexão.
Uma conexão de Rede é vista, da ótica do modelo OSI, como um par de filas FIFO
(FIrst In FIrst Out), cada uma orientada num sentido, conectado entre dois NSAPs
(endereços de rede). A figura 3.7 ilustra o estado da conexão, considerando a adoção de um
serviço orientado conexão. A figura 3.7(a) ilustra o estado da conexão antes do seu
estabelecimento; 3.7(b) após o estabelecimento da conexão e, 3.7(c), após o envio de três
pacotes de dados.
4.1.1. As primitivas de serviço
O quadro a seguir apresenta as primitivas de serviço disponíveis pela camada de

Rede do modelo OSI, tanto para o serviço orientado conexão como para o sem conexão.
SERVIÇO ORIENTADO CONEXÃO

N_CONNECT.request (called, calling,acks_wanted,exp_wanted,qos,user_data)
N_CONNECT.indication (called, calling,acks_wanted,exp_wanted,qos,user_data)
N_CONNECT.response (responder, acks_wanted,exp_wanted,qos,user_data)
N_CONNECT.confirm (responder, acks_wanted,exp_wanted,qos,user_data)
N_DISCONNECT.request (source, reason, user_data, responding_address)
N_DISCONNECT.indication (source, reason, user_data, responding_address)
N_DATA.request (user_data)
N_DATA.indication (user_data)
N_DATA_ACKNOWLEDGE.request ( )
N_DATA_ACKNOWLEDGE.indication ( )
N_EXPEDITED_DATA.request (user_data)
N_EXPEDITED_DATA.indication (user_data)
N_RESET.request (source, reason)
N_RESET.indication (source, reason)
N_RESET.response ( )
N_RESET.confirm ( )
SERVIÇO SEM CONEXÃO
N_UNITDATA.request (source_address,dest_address, qos, user_data)
N_UNITDATA.indication (source_address,dest_address, qos, user_data)
N_FACILITY.request (qos)
N_FACILITY.indication (dest_address, qos, reason)
N_REPORT.indication (dest_address, qos, reason)
— 3.10 —
serviço orientado serviço sem

conexão conexão
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
SAP
FÍSICA
Figura 3.6 - Ilustração das classes de serviço do modelo OSI.
usuário usuário usuário usuário usuário usuário

1 2 1 2 1 2
NSAPs NSAPs NSAPs
camada Rede camada Rede camada Rede
(a) (b) (c)
Figura 3.7 - Modelo de uma conexão de Rede: (a) antes do estabelecimento; (b) após o
estabelecimento; (c) após o envio de três pacotes (de 1 para 2).
N_CONNECT.request é a primitiva utilizada para requisitar o estabelecimento de

uma conexão de Rede e através de seus parâmetros deve-se indicar o endereço ao qual se
deseja conectar (calling), assim como o endereço do iniciador (called). Encontra-se, ainda,
nos seus parâmetros, duas variáveis booleanas que permitem requisitar serviços adicionais.
O parâmetro acks_wanted permite indicar o pedido de reconhecimento de pacotes.
Se a camada de Rede não permite o fornecimento de reconhecimento, o fornecedor
vai colocar esta variável a falso na primitiva de indicação; da mesma forma, se a entidade
destinatária não pode fornecer reconhecimento, ela mesma o fará (colocar acks_wanted a
falso) na primitiva de resposta.
O outro parâmetro booleano, exp_wanted, permite a utilização de serviços de dados
expressos (ou urgentes), o que significa que um pacote pode violar a ordem normal dos
pacotes na fila para se colocar na cabeça desta. Isto permite, de certo modo, estabelecer
um nível de prioridade entre as mensagens a nível de Rede.
O parâmetro qos permite determinar a qualidade do serviço a ser oferecido, sendo
composto de duas listas de valores. A primeira lista contém o contexto desejado pela
entidade iniciadora; a segunda indica os valores mínimos aceitáveis. Se o serviço de Rede é
incapaz de fornecer pelo menos os valores mínimos estabelecidos pelo usuário iniciador, a
conexão não será estabelecida.
Os valores estabelecidos neste parâmetro são a taxa de erro, a taxa de transmissão,
a confidencialidade e custo da transmissão.
O iniciador pode, através do parâmetro user_data, introduzir dados no pedido de
conexão, podendo a entidade chamada consultar estes dados antes da aceitação da
conexão.
A aceitação de uma conexão é feita pelo iniciador através da primitiva
N_CONNECT.indication; por outro lado, a recusa é implementada através da primitiva
— 3.11 —
N_DISCONNECT.request, que informa, através do parâmetro reason, o motivo do não

estabelecimento da conexão.
Se a conexão é estabelecida, a transmissão de dados é feita utilizando a primitiva
N_DATA.request, que será refletida no receptor por uma primitiva N_DATA.indication. Caso
um pedido de reconhecimento de pacotes foi acertado entre os usuários da camada no
momento da conexão, o reconhecimento será implementado através do envio, pelo receptor,
de uma primitiva N_DATA_ACKNOWLEDGE.request.
As primitivas N_RESET são utilizadas para sinalizar problemas de comunicação, tais
como o bloqueio de uma entidade de transporte envolvida na comunicação ou mesmo do
fornecedor do serviço. O efeito deste serviço é o esvaziamento das filas de espera, sendo
que as informações presentes nestas serão perdidas. As perdas deverão ser recuperadas
pela camada de Transporte.
As primitivas N-UNITDATA são utilizadas para o envio de dados no serviço sem
conexão; elas não oferecem nem controle de erros nem de fluxo. N_FACILITY é o serviço
que permite ao usuário obter informações sobre as características da transmissão de
informação, por exemplo, a porcentagem de pacotes distribuídos.
Finalmente, a primitiva N_REPORT permite à camada de Rede informar a ocorrência
de problemas relativos ao serviço de Rede, como, por exemplo, a indisponibilidade
momentânea de um determinado endereço destinatário.
4.1.2. O endereçamento de Rede
Uma função importante desta camada é o fornecimento de uma codificação espacial

coerente para uso da camada de Transporte. O fato é que, para cada rede, foi definida uma
estrutura distinta de endereçamento, o trabalho de uniformização ficando a cargo da camada
de Rede.
Assim, a estrutura de endereçamento a nível de Rede foi concebida de modo a
incorporar as características das diversas estruturas de endereçamento existentes. Todas
as primitivas de serviço de Rede utilizam o endereçamento orientado aos NSAPs para
identificar a origem de o destinatário de um pacote. O endereço de NSAP é composto de três
campos:
• AFI (Authority and Format Identifier), identifica o tipo de endereçamento existente
no terceiro campo do endereço, possibilitando uma numeração entre 10 e 99,
correspondente aos diferentes formatos existentes e deixando ainda
possibilidades de extensão;
• IDI (Initial Domain Identifier) indica o domínio ao qual pertence o número do DSP
(o terceiro campo) — se o DSP é um número de telefone, este campo indicará o
código do país;
• DSP (Domain Specific Part) contém o endereço específico do NSAP no domínio
considerado.
4.2. A função de Roteamento
Como dito na parte introdutória, a função principal da camada de Rede é efetuar o

encaminhamento dos pacotes trocados entre duas entidades oferecendo uma comunicação
fim-a-fim. Durante a trajetória os pacotes sofrerão uma série de saltos, sendo que a decisão
de que caminho utilizar é feita a nível da camada de Rede, esta decisão podendo levar em
conta (ou não) a situação da rede do ponto de vista do tráfego de informação.
Num primeiro ponto, dado este último aspecto, pode-se distinguir os diferentes
algoritmos de roteamento em duas principais classes: os algoritmos adaptativos e não
adaptativos. Os algoritmos não adaptativos não levam em conta a situação de tráfego da
rede, fazendo o denominado roteamento estático; já os adaptativos o fazem, considerando
modificações de topologia da rede e do tráfego real.
— 3.12 —
As seções que seguem vão discutir alguns dos conjuntos de algoritmos de

roteamento existentes.
4.2.1. Algoritmo do caminho mais curto
Este algoritmo é baseado numa representação da subrede na forma de um grafo,

onde os nós são os IMP e os arcos são as linhas de comunicação. E escolha de uma
trajetória é, então, baseada neste grafo, o objetivo sendo encontrar o caminho mais curto
entre dois IMPs.
O conceito de caminho mais curto pode levar em conta diferentes aspectos:
• o número de nós entre os dois pontos;
• a distância geográfica entre os pontos;
• os tempos de espera em cada nó da trajetória;
• etc...
No terceiro caso, por exemplo, os arcos são etiquetados com um valor que
representa o tempo médio de espera entre o envio e a recepção de um pacote de teste,
expedido periodicamente.
Um exemplo de algoritmo do caminho mais curto é aquele definido por Dijkstra, onde
cada nó é etiquetado pela distância do nó fonte seguindo o caminho mais curto conhecido.
Como, inicialmente, nenhum caminho é conhecido, os nós são etiquetados com a etiqueta
«infinito», ou .... Estas vão sendo atualizadas à medida que o algoritmo progride e que os
caminhos vão se tornando conhecidos, as etiquetas vão indo do provisório ao permanente
uma vez que o caminho mais curto foi encontrado para os diferentes nós.
A figura 3.8 ilustra o funcionamento deste algoritmo. Vamos considerar o grafo
apresentado em 3.8(a), onde os arcos são etiquetados com o valor da distância entre os
nós. Vamos considerar que o objetivo aqui é encontrar o caminho mais curto entre A e D.
Como o nó A é o nó de origem, ele será marcado por um nó de referência (fundo
cinza) e serão analisados os nós adjacentes. Estes serão etiquetados pela distância que os
separa de A, marcando também, na etiqueta, o último nó a partir do qual o cálculo foi feito.
Após a análise dos nós adjacentes a A, marca-se aquele contendo a etiqueta de
menor valor, como mostrado em 3.8(b), este nó passando a ser o nó ativo (ou de referência).
Repetindo a análise para o nó B, define-se o nó E como sendo o novo nó ativo,
mostrado em 3.8(c). O algoritmo vai progredindo até que o caminho mais curto seja então
encontrado, as etiquetas sendo modificadas segundo as análises efetuadas. A progressão
do algoritmo para o exemplo é ilustrada por 3.8(d), 3.8(e) e 3.8(f).
4.2.2. Roteamento multicaminhos
Este algoritmo leva em conta a possibilidade de existência de diversos caminhos

entre dois nós de valores quase equivalentes. Desta forma, o desempenho da rede pode ser
melhorado, se o tráfego é assumido por vários caminhos, reduzindo assim a carga de uma
dada linha de comunicação.
Esta técnica de roteamento é implantada da seguinte forma: cada IMP mantém
atualizada uma tabela com uma linha para cada IMP da rede. Para cada IMP, tem-se as
diferentes linhas de saída para este destino, classificadas em ordem decrescente, do melhor
ao menos eficiente, com um peso relativo.
Antes do envio de um pacote, o IMP gera um número aleatório para definir o caminho,
utilizando os pesos como probabilidade. As tabelas são criadas de maneira estática pelo
administrador do sistema e carregadas em cada IMP na inicialização da rede. O grafo da
figura 3.9(a) ilustra o desenvolvimento deste algoritmo, sendo que em 3.9(b) está
apresentada a tabela para o IMP J. Se J recebe um pacote destinado a A, ele pode optar por
um dos três caminhos, consultando a tabela na linha associada ao nó A. A primeira escolha
é o caminho direto a A, as outras sendo via I e H, respectivamente.
— 3.13 —
B C B (2,A) C ( ,-)
7
2 2 3 3 E ( ,-)
2
A E F D A F ( ,-) D ( ,-)
6 1 2 2
4
G H G (6,A) H ( ,-)
(a) (b)
B (2,A) C (9,B) B (2,A) C (9,B)
E (4,B) E (4,B)
A F ( ,-) D ( ,-) A F (6,E) D ( ,-)
G (6,A) H ( ,-) G (5,E) H ( ,-)
(c) (d)
B (2,A) C (9,B) B (2,A) C (9,B)
E (4,B) E (4,B)
A F (6,E) D ( ,-) A F (6,E) D ( ,-)
G (5,E) H (9,G) G (5,E) H (8,F)

(e) (f)
Figura 3.8 - Ilustração do algortimo de Dijkstra.
A A 0,63 I 0,21 H 0,16

A B C D B A 0,46 H 0,31 I 0,23
C A 0,34 I 0,33 H 0,33
D H 0,50 A 0,25 I 0,25
E A 0,40 I 0,40 H 0,20
E F G H F A 0,34 0,33 0,33
H I
G H 0,46 A 0,31 K 0,23
H H 0,63 K 0,21 A 0,16
I I 0,65 A 0,22 H 0,13
· · · · · · ·
I J K L K K 0,67 H 0,22 A 0,11
L K 0,42 H 0,42 A 0,16
(a) (b)
Figura 3.9 - Ilustração do algoritmo multicaminho: (a) grafo da rede; (b) tabela para o nó J.
A decisão é, então, baseada na geração de um número aleatório entre 0,00 e 0,99.

Se o número é inferior a 0,63, a linha A será escolhida, se estiver entre 0,63 e 0,83, a linha
passando por I será escolhida; senão, será a linha que passa por H.
A vantagem desta técnica sobre a anterior é a possibilidade de definir diferentes
classes de tráfego sobre diferentes caminhos. Uma outra vantagem é a confiabilidade ganha,
uma vez que várias linhas podem ser perdidas sem que a rede perca a sua conectividade.
— 3.14 —
4.3. O controle de congestionamento
Durante o funcionamento de uma aplicação distribuída construída sobre uma rede,

vão existir instantes em que o fluxo de mensagens sendo trocadas pode atingir valores
bastante importantes, de tal forma que os nós intermediários, responsáveis do tratamento
dos pacotes, não sejam mais capazes de tratar os pacotes para retransmissão. Isto,
naturalmente, vai ter como conseqüência uma degradação no funcionamento da rede,
podendo trazer prejuízos (lentidão, perdas de pacotes) ao desempenho da aplicação e
comprometendo o seu correto funcionamento. As causas desta sobrecarga, conhecida por
congestionamento, podem ser de várias naturezas. Um exemplo disto pode ser a lentidão
dos nós na realização do roteamento ou um mal funcionamento do mecanismos de controle
de fluxo.
O congestionamento consiste, normalmente de um processo a realimentação
positiva, o número de mensagens tendendo a crescer se a rede está congestionada. Sendo
assim, a camada de Rede deve também fazer este papel, através da implementação de
funções de controle de congestionamento, alguns dos quais serão descritos a seguir.
4.3.1. A pré-alocação de buffers
Uma primeira forma de controlar o congestionamento da rede é através da

préalocação de buffers, particularmente se o serviço é orientado à conexão. Isto significa que,
no momento do estabelecimento do circuito virtual que vai caracterizar a conexão, um
determinado número de buffers deve ser alocado em cada nó para permitir o
armazenamento dos pacotes a serem retransmitidos.
Evidentemente, o número de buffers a ser alocado vai depender do protocolo
implementado entre cada par de nós intermediários (IMPs). Um algoritmo do tipo «envia-
espera» vai exigir um número de buffers evidentemente menor do que um algoritmo que
autorize o envio de diversos pacotes antes da retransmissão.
4.3.2. A destruição de pacotes
Um outro mecanismo que é adotado para o controle de congestionamento é o da

destruição de pacotes. Neste caso, não existe reserva prévia de buffers, de modo que, se
um pacote chega num IMP e este não dispõe de buffer para o seu armazenamento, este é
simplesmente destruído (ou descartado). Se o serviço oferecido é do tipo «datagrama», não
há mais nada a fazer; por outro lado, se este é orientado à conexão, o pacote deverá ser
armazenado em algum nó para uma possível retransmissão. Ainda, a destruição de pacotes
deve seguir uma certa disciplina... por exemplo, destruir um pacote de reconhecimento pode
não ser uma boa solução, uma vez que este pacote poderia permitir ao nó o apagamento de
um pacote de informação e, por consequência, a liberação de um buffer. Uma solução para
isto é a reserva, para cada linha de chegada, de um buffer que possibilite a recepção de
pacotes de reconhecimento endereçados àquele nó.
4.3.3. O controle de fluxo
O controle de fluxo consiste em outra técnica de controle de congestionamento,

embora não muito eficiente nesta tarefa. O problema do controle do fluxo é o fato que, os
limites do tráfego não podem ser estabelecidos a valores muito baixos, pois isto pode
provocar problemas de eficiência na aplicação se um pico de tráfego é requerido. Por outro
lado, a escolha de um limite alto de tráfego pode resultar num controle medíocre de
congestionamento.
Outras técnicas de controle de congestionamento são ainda implementadas, como
por exemplo:
— 3.15 —
• o controle isarítmico, baseado na existência em cada nó de um certo número de

fichas. O nó que tiver um pacote a transmitir, deve obter uma ficha, se existir
alguma disponível. Isto permite manter constante o número de pacotes em
circulação na rede;
• os pacotes de estrangulamento, enviados por um nó ao usuário do serviço de
rede, indicando que determinadas linhas de saída estão no limite da saturação.
Isto faz com que o usuário reduza o envio de pacotes para o destino utilizando
aquela linha até que a situação retome a normalidade.
5. A CAMADA DE TRANSPORTE
A função da camada de Transporte é permitir a transferência de informações do

sistema emissor ao sistema receptor de forma confiável e econômica, independentemente
da natureza da informação ou das redes suportando a comunicação.
A importância dos serviços fornecidos por esta camada está no fato que muitas
aplicações existentes podem funcionar simplesmente com a existência de um serviço
confiável de transporte de informação, o que quer dizer que os serviços que poderiam ser
fornecidos pelas camadas superiores são dispensável. Um exemplo disto é a interconexão
de estações no sistema UNIX.
Nesta parte do documento, serão apresentadas as principais definições relacionadas
aos serviços e protocolos de transporte, particularmente do ponto de vista do modelo OSI.
5.1. O serviço oferecido à camada de Sessão
Segundo o modelo OSI, os usuários da camada de Transporte são as entidades de

Sessão, às quais deve ser oferecido o serviço confiável de transporte dos bits de informação
fim-a-fim, este serviço sendo fornecido através de uma entidade de software ou de hardware
denominada entidade de transporte.
De maneira similar à camada de Rede, a de Transporte pode fornecer duas classes
de serviço, ou seja, sem conexão e orientados à conexão.
Os serviços de Transporte orientados à conexão são caracterizados pelas três
etapas já descritas para outros níveis do modelo OSI, isto é, estabelecimento de conexão,
transferência de dados e liberação da conexão.
Estes serviços são bastante similares aos serviços oferecidos pela camada de
Rede, o que poderia colocar em dúvida a necessidade desta camada. No entanto, a sua
existência se justifica pela necessidade de serviços de supervisão da camada de Rede do
ponto de vista das entidades efetivamente envolvidas na comunicação. Uma supervisão fim-
a-fim, uma vez que, até o nível Rede, as comunicações se fazem ponto-a-ponto.
Outra contribuição importante da camada de Transporte é que ela permite a
utilização de primitivas de serviço padrão pelas diversas aplicações construídas sobre a
rede efetuando um perfeito «isolamento» em relação às camadas superiores e tornando
transparentes as possíveis alterações tecnológicas que poderiam ocorrer nos níveis
inferiores. Por esta razão, costuma-se fazer uma distinção entre os níveis de 1 a 4 e os de 5
a 7. Os primeiros quatro níveis seriam mais orientados ao transporte efetivo das
informações e os três níveis superiores, mais orientados às aplicações que serão
construídas sobre a rede.
Poderíamos sintetizar o serviço fornecido pela camada de Transporte como de
supervisor da qualidade de serviço oferecido pela camada de Rede. Isto significa que, se a
camada de Rede é confiável, a camada de Transporte não terá muito a fazer.
Por outro lado, se o serviço de Rede é deficiente, a camada de Transporte assume a
função de suprir as diferenças entre a qualidade de serviço que a camada de Sessão
necessita e aquilo que a camada de Rede pode oferecer.
Para isto, o conceito de qualidade de serviço (QOS para Quality Of Service) é um
aspecto importante na concepção da camada de Transporte, baseado sobre um certo
conjunto de parâmetros, entre os quais:
— 3.16 —
• o tempo de estabelecimento de uma conexão;

• a probabilidade de falha de um estabelecimento;
• a taxa de débito da conexão;
• o tempo de trânsito;
• a taxa de erro residual;
• a probabilidade de incidente de transferência;
• o tempo de desconexão;
• a prioridade;
• etc...
No momento do pedido de um estabelecimento de conexão, o usuário iniciante

encaminha estes parâmetros nas primitivas de serviço. Se a camada de Transporte julga
certos parâmetros longe da realidade, ela pode sinalizar isto ao usuário iniciante, sem
mesmo ter tentado estabelecer a conexão, através de uma mensagem de erro que vai,
também, indicar a natureza do erro sinalizado.
Outra possibilidade é a camada de Transporte julgar que um certo valor para um
parâmetro seja impossível de ser oferecido mas que um valor não muito longe daquele
poderia ser oferecido. Neste caso, ela pode modificar os valores dos parâmetros
enquadrados e encaminhar o pedido de conexão à máquina remota.
Ainda, se a máquina distante verifica que ela não pode oferecer determinados valores
especificados nos parâmetros do pedido, ela pode modificar também aqueles parâmetros.
Se ela verifica não poder determinados parâmetros nos valores mínimos permitidos, neste
caso ela vai rejeitar a conexão.
5.2. As primitivas de serviço de Transporte
As primitivas de serviço de Transporte do modelo OSI são apresentadas no quadro a

seguir, existindo para os serviços orientados conexão e sem conexão.
SERVIÇO ORIENTADO CONEXÃO

T_CONNECT.request (called, calling,exp_data,qos,user_data)
T_CONNECT.indication (called, calling, exp_data,qos,user_data)
T_CONNECT.response (qos, responder, exp_data, user_data)
T_CONNECT.confirm (qos, responder, exp_data, user_data)
T_DISCONNECT.request (user_data)
T_DISCONNECT.indication (reason, user_data)
T_DATA.request (user_data)
T_DATA.indication (user_data)
T_EXPEDITED_DATA.request (user_data)
T_EXPEDITED_DATA.indication (user_data)
SERVIÇO SEM CONEXÃO
T_UNITDATA.request (called, calling,qos,user_data)
T_UNITDATA.indication (called, calling,qos,user_data)
Como podemos ver, as primitivas de serviço de Transporte se assemelham bastante

àquelas do serviço de Rede. Existe, porém, uma diferença fundamental entre os dois níveis.
No caso do nível Rede, considera-se que o serviço oferecido corresponde ao
funcionamento real do sistema, representando inclusive suas falhas. Desta forma, podem
ocorrer perdas de pacotes ou a emissão de comandos N_RESET de sua própria iniciativa.
Já no caso do nível Transporte, os comandos N_RESET não são propagados aos
usuários (as camadas superiores), uma vez que o objetivo principal desta camada é o
tratamento de todos os problemas de comunicação evitando que os usuários do serviço
— 3.17 —
tomem conhecimento das más condições de funcionamento da rede de comunicação (se tal
é o caso!).
Uma outra diferença entre os dois serviços são os usuários destes... no caso do
serviço de Rede, os usuários são as entidades de Transporte, normalmente elementos
associados ao sistema operacional considerado ou a uma carta específica instalada nos
sistemas.
Já os usuários do serviço de Transporte podem ser programas escritos pelos
programadores de aplicações, uma vez que, como já foi dito, muitas aplicações podem
comunicar-se diretamente através do uso direto das primitivas de serviço de Transporte (não
fazendo uso dos serviços de Sessão ou de Apresentação).
As possíveis relações entre as primitivas de serviço da camada de Transporte são
apresentadas na figura 3.10. As duas extremidades das ilustrações caracterizam os
usuários do serviço de Transporte, o fornecedor sendo representado pelo espaço separando
os dois usuários.
Em 3.10(a) é ilustrada um estabelecimento normal de conexão, onde o usuário da
esquerda envia uma primitiva T_CONNECT.request à camada de Transporte. O usuário da
direita vai receber então uma primitiva T_CONNECT.indication, cujos parâmetros vão
conduzir os valores, particularmente, da qualidade de serviço a serem negociados. Este
aceita o estabelecimento da conexão, retornando à camada de Transporte uma primitiva
T_CONNECT.response, que será refletida, via serviço de Transporte, no usuário da
esquerda na forma de uma primitiva T_CONNECT.confirm. A figura 3.10(b) apresenta uma
tentativa de estabelecimento de conexão, rejeitada, porém, pelo usuário da direita, que utiliza
as primitivas de serviço T_DISCONNECT.request e T_DISCONNECT.indication para
sinalizar a rejeição. O caso é similar na figura 3.10(c), porém, desta vez, é o próprio
fornecedor do serviço de Transporte quem rejeita a conexão, enviando uma primitiva
T_DISCONNECT.indication ao usuário da esquerda. No que diz respeito à liberação da
conexão, pode-se considerar três diferentes maneiras: a primeira, ilustrada em 3.10(d),
considera o caso em que a liberação é iniciada por um dos usuários (no caso o da
esquerda). A conexão é liberada no momento em que o usuário da direita recebe uma
primitiva T_DISCONNECT.indication, reflexo da primitiva T_DISCONNECT.request emitida
pelo usuário que iniciou a liberação.
Em 3.10(e) é considerado o caso em que os dois usuário iniciam, simultaneamente,
a liberação da conexão, neste caso, a conexão é liberada sem a emissão de outras
primitivas de serviço; finalmente, em 3.10(f), a liberação é iniciada pelo próprio serviço de
Transporte, que vai emitir primitivas T_DISCONNECT.indication aos dois usuários
conectados. Já as figuras 3.10(g) e 3.10(h), representam, respectivamente, a etapa de
transferência de dados, para dados normais e expressos.
5.3. Os protocolos de Transporte
Como definido pelo modelo OSI, o serviço oferecido por uma camada N é o resultado
da implementação de um protocolo N regendo a comunicação entre duas entidades N. Em
princípio, os protocolos de Transporte apresentam preocupações similares à dos protocolos
de Enlace, ou seja, o controle de erros, o controle de fluxo, o seqüenciamento dos dados.
No entanto, algumas diferenças podem ser levantadas:
• no caso da camada de Enlace, dois IMPs comunicam-se via um canal de

comunicação; a nível de Transporte, a comunicação é feita via uma subrede;
• no que diz respeito ao endereçamento, a nível de Enlace, um IMP não necessita
referir-se explicitamente com qual IMP ele quer dialogar, uma vez que dois IMPs
são conectados por uma via única; já, no nível Transporte, o endereço do
destinatário deve ser explicitamente definido;
— 3.18 —
T_CONNECT T_CONNECT T_CONNECT

request request request
T_CONNECT T_CONNECT
indication indication
T_CONNECT T_DISCONNECT
response request
T_CONNECT T_DISCONNECT T_DISCONNECT
confirm indication indication
(a) (b) (c)
T_DISCONNECT T_DISCONNECT T_DISCONNECT

request request request T_DISCONNECT T_DISCONNECT
T_DISCONNECT indication indication
indication
(d) (e) (f)
T_DATA T_EXPEDITED_DATA
request request
T_DATA T_EXPEDITED_DATA
(g) (h)
Figura 3.10 - As diversas interações entre as primitivas de serviço de Transporte.
• um outro problema é a questão do controle de fluxo; ao contrário do nível de

Enlace, onde cada conexão pode alocar um determinado número de buffers para o
armazenamento dos quadros, no nível Transporte isto fica mais difícil dado o
número de conexões que pode estar sendo gerenciado num dado instante.
Um aspecto a ser levado em conta no momento da concepção da camada de

Transporte é o serviço oferecido pela camada de Rede, que pode ser classificado da
seguinte maneira:
• serviços do tipo A, que caracteriza os serviços perfeitos, onde a fração de pacotes

perdidos, duplicados ou corrompidos é desprezível; é o tipo de serviço dificilmente
encontrado em redes públicas, mas algumas redes locais são bastante próximas
deste tipo de serviço;
• serviços do tipo B, onde a perda de pacotes também é rara, mas a comunicação é
freqüentemente interrompida (serviço N_RESET) devido a problemas de
congestão, de hardware ou software;
• serviços do tipo C, não confiáveis, sendo caracterizados normalmente pelas redes
a longa distância do tipo datagrama.
Para cada tipo de serviço, de A a C, o nível do serviço de Transporte caminha do

mais simples ao mais complexo, ou seja, quanto pior o serviço oferecido pela camada de
Rede, melhor (e mais complexo) deverá ser o serviço oferecido pela camada de Transporte.
Para permitir a definição de vários níveis de oferecimento de serviço, o modelo OSI, a
nível da camada de Transporte, define cinco classes de serviço:
— 3.19 —
• classe 0, que são os serviços mais simples, capazes de estabelecer uma

conexão, mas baseados na hipótese que o serviço de Rede não gera erros de
transmissão; não existe tratamento de erros, controle de fluxo nem
seqüenciamento;
• classe 1, corresponde à classe 0, mas permite implementar a retomada de
diálogo, considerando que pode ocorrer quebra do diálogo a nível de Rede (serviço
N_RESET); ele permite a retomada da comunicação entre duas entidades de
Transporte após a interrupção de uma conexão de Rede;
• classe 2, que torna mais sofisticada a classe 0 pela introdução da possibilidade de
manutenção de diversas conexões de Transporte sobre uma única conexão de
Rede (multiplexação);
• classe 3, que agrupa os mecanismos de retomada de diálogo da classe 1 com os
de multiplexação da classe 2;
• classe 4, definida para operar sobre os serviços de Rede do tipo C cuja falta de
confiabilidade é conhecida, devendo tratar então os erros, perdas, duplicações,
retomada de diálogo e todos os possíveis problemas não resolvidos pela camada
de Rede.
No momento do estabelecimento de uma conexão, são as entidades pares que

devem tomar a decisão sobre qual classe de serviço adotar, uma classe sendo proposta
pelo iniciante e negociada para permitir o estabelecimento da conexão.
As funções do protocolo de Transporte vão depender do ambiente no qual ele vai
operar assim como da natureza dos serviços que devem ser supridos. Um mínimo de
funções deve, todavia, ser oferecido por um protocolo de Transporte, entre as quais:
• o estabelecimento de conexão;
• transferência de TPDUs;
• segmentação de mensagens;
• etc...
O termo TPDU indicado acima serve para definir a unidade de dados trocada entre
duas unidades de Transporte que é a unidade de dados de protocolo de transporte (em
inglês, Transport Protocol Data Unit). Por outro lado, a unidade de dados emitida por um
usuário do serviço Transporte será referenciado como sendo uma mensagem.
Uma mensagem a ser transmitida pode ter um tamanho qualquer, a segmentação
das mensagens devendo ser assumida por esta camada. Isto significa que, se uma unidade
de dados apresenta um tamanho superior ao de um pacote, ela deve ser segmentada em
tantos pacotes quantos sejam necessários para efetuar a sua completa emissão.
Ainda, se uma entidade de Transporte gerencia várias conexões num dado instante,
ela deve numerar as conexões e inserir o número correspondente nas unidades de dados, a
fim de permitir à entidade receptora de identificar corretamente a conexão à qual esta unidade
de dados deve ser associada. Independente da classe de protocolo considerada, deve
sempre existir um mecanismo de liberação de conexão, esta liberação sendo, porém,
diferente dependendo da classe de protocolo considerada.
6. A CAMADA DE SESSÃO
Como foi mencionado anteriormente, o modelo hierárquico de comunicação proposto

no modelo OSI pode fazer distinção em duas classes de camadas: as camadas inferiores,
concretizadas pelas camadas de 1 a 4, já vistas, cujos serviços são orientados ao transporte
de informação propriamente dito, tratando essencialmente de problemas de comunicação
como, por exemplo, codificação e transmissão de bits, controle de fluxo e de erros,
seqüenciamento, roteamento, controle de tráfego e gerenciamento de conexões; as
camadas superiores, concretizadas pelas camadas de 5 a 7, cujos serviços se orientam
— 3.20 —
mais às aplicações escritas pelos usuários no sentido de facilitar ou simplificar as suas

tarefas, fornecendo serviços padronizados os mais diversos.
A camada de Sessão é a primeira camada (no sentido bottom-up) enquadrada na
segunda classe. Ao contrário de outras camadas já estudadas e outras que serão vistas
mais adiante, a camada de Sessão foi introduzida no momento da definição do modelo OSI.
As demais camadas presentes no OSI foram, de certo modo, inspiradas de modelos pré-
existentes na concepção de redes já existentes na época como, por exemplo, ARPANET.
Esta é, na verdade, uma das camadas mais simples do modelo OSI, oferecendo uma
quantidade relativamente limitada, longe dos serviços oferecidos por camadas como a de
Transporte, por exemplo.
Nesta parte do documento, veremos então os serviços oferecidos pela Sessão e
como estes são implementados através dos protocolos.
6.1. Serviços oferecidos à camada de apresentação
Segundo o modelo OSI, os usuários dos serviços de Sessão são as entidades de

Apresentação, a posição desta camada estando ilustrada na figura 3.11. A principal função
desta camada é oferecer aos seus usuários meios para o estabelecimento das conexões,
denominadas sessões, de modo que estes possam trocar dados.
Uma sessão pode ser utilizada para permitir a conexão à distância a um computador,
por exemplo, através de um terminal, para uma transferência de arquivo, para o
carregamento de programas à distância, etc... Apesar de que, ao nível de Sessão, são
oferecidas primitivas de serviço para a comunicação sem conexão, neste modo, não é
possível explorar os serviços orientados aos usuários, disponíveis nesta camada.
No que diz respeito à conexão de Sessão (ou à sessão, como definido acima), pode-
se estabelecer as diferentes possíveis relações entre uma conexão de Sessão e uma
conexão de Transporte, como mostra a figura 3.12. Em 3.12(a), é mostrada uma
correspondência de 1 a 1 entre uma conexão de Sessão e uma de Transporte. Por outro
lado, como mostrado em 3.12(b), pode-se utilizar uma mesma conexão de Transporte para
suportar diferentes sessões consecutivas (ver exemplo da agência de reservas de
passagens em Tanenbaum 90). Ainda, pode-se ter o quadro inverso, onde, pela quebra de
uma conexão de Transporte, a abertura de uma nova é providenciada para garantir a
continuidade de uma mesma sessão. Este último cenário, ilustrado em 3.12(c), se
caracteriza, por exemplo, quando as entidades de Transporte assumem a tarefa de
retomada de diálogo após uma pane.
6.2. Sessão x Transporte: similaridades e diferenças
Esta é a principal função da camada de Sessão e, da mesma forma como foi visto
para camadas inferiores, o diálogo via esta camada é caracterizado pelas três etapas a
seguir: estabelecimento de sessão, transferência de dados e liberação da sessão.
7
serviços oferecidos APRESENTAÇÃO APRESENTAÇÃO
à camada de apresen- 6
SSAP SSAP
tação SPDUs
ENTIDADE ENTIDADE
serviços oferecidos DE SESSÃO DE SESSÃO
à camada de sessão 5
TSAP TSAP
TRANSPORTE
4 protocolo de TRANSPORTE
sessão
1a3
Figura 3.11 - Posição da camada de Sessão no modelo OSI.
— 3.21 —
Sessão
Sessão Sessão
Transporte Transporte Transporte
(a) (b) (c)
Figura 3.12 - Diferentes relações entre conexão de Sessão e de Transporte: (a) correspondência 1 a 1;
(b) uma conexão de Transporte para várias sessões; (c) várias conexões de Transporte para uma única
sessão.
As primitivas de estabelecimento e liberação de sessão oferecidas à camada de

Apresentação são similares àquelas oferecidas à própria camada de Sessão pelo Transporte.
Esta similaridade ocorre a tal ponto que, em muitos casos, a recepção de uma primitiva de
serviço da camada de Apresentação reflete-se imediatamente no envio de uma primitiva de
serviço equivalente da camada de Transporte.
Um exemplo disto é a primitiva de estabelecimento de Sessão,
S_CONNECT.request, que é refletida no envio de uma primitiva T_CONNECT.request.
Na fase de estabelecimento de uma conexão, da mesma forma que na camada de
Transporte, ocorre a negociação, entre as duas entidades envolvidas (de Apresentação)
sobre que parâmetros vão definir a comunicação.
Dentre estes parâmetros, encontram-se parâmetros já conhecidos de outros níveis
do modelo OSI (por exemplo, a necessidade de transferência de dados expressos) e
também parâmetros específicos à camada de Sessão (por exemplo, na abertura de uma
sessão para troca de informações via correio eletrônico, um parâmetro pode ser qual usuário
vai tomar a iniciativa do diálogo).
Apesar das semelhanças já levantadas, pode-se destacar também algumas
diferenças entre uma sessão e uma conexão de Transporte, essas diferenças estando
particularmente associadas ao procedimento de liberação das conexões. No caso da
camada de Transporte, a primitiva T_DISCONNECT.request que causa a terminação
abrupta da conexão, pondendo ocorrer inclusive perda dos dados ainda em trânsito. Já, no
caso das sessões, a primitiva responsável da liberação é S_RELEASE.request que permite
terminar, de maneira ordenada a conexão, sem ocorrência de perda dos dados (liberação
negociada). É possível, no entanto, em caso de necessidade, promover uma liberação
abrupta da sessão, isto, graças à utilização da primitiva S_ABORT.request. A diferença entre
as duas formas de liberação de uma conexão é mostrada na figura 3.13. Em 3.13(a) é
apresentada a liberação abrupta de uma conexão de Transporte; em 3.13(b), é apresentada
a liberação negociada de uma sessão. Como se pode ver em 3.13(b), ao contrário dos
serviços de liberação de conexão apresentados até o momento, o serviço de liberação
negociada S_RELEASE é um serviço confirmado, caracterizado pelas primitivas request,
indication, response e confirm.
Como mostra a figura, mesmo após ter emitido o pedido de liberação, a entidade
usuária pode continuar a receber primitivas de serviço de indicação de transferência de
dados (no caso, S_DATA.indication), sendo que a desconexão só será efetivada após a
recepção da primitiva S_RELEASE.confirm.
Um outro ponto de bastante similaridade entre as camadas de Sessão e Transporte é
o endereçamento. Da mesma forma que no Transporte, a nível de Sessão é necessário
indicar um SSAP (Ponto de Acesso ao Serviço de Sessão ou Session Service Access
Point) na fase de estabelecimento de sessão.
Normalmente, um endereço de SSAP nada mais é que um endereço de TSAP
enriquecido com outras informações. Ainda, uma diferença entre Sessão e Transporte está
nos tipos de dados transmitidos. Como foi visto no caso da camada de Transporte, existem
dois tipos de fluxos de dados — os dados normais e os dados expressos (ou urgentes).
— 3.22 —
S_DATA
request S_RELEASE
T_DATA request
request perda S_RELEASE
T_DISCONNECT indication S_DATA
dado indication
request
T_DISCONNECT S_RELEASE
indication response
S_RELEASE
confirm
(a) (b)
Figura 3.13 - (a) liberação abrupta; (b) liberação negociada.
Já na camada de Sessão, além destes dois tipos de dados, podem ocorrer outros
dois — os dados tipados (typed data) e os dados de capacidade (capacity data). Estes tipos
de dados serão explicados mais adiante, neste documento.
6.3. A gestão do diálogo
Segundo o modelo OSI, todas as conexões estabelecidas são, a princípio, do tipo full
duplex (ou seja, bidirecionais simultâneas, conforma mostrado na figura 3.14(a)). Por outro
lado, existem muitas aplicações nas quais a possibilidade de operação em half duplex pode
ser mais interessante.
Este serviço é implementado a nível da camada de Sessão graças à definição de
uma ficha de dados (data token), como ilustrado na figura 3.14(b). A comunicação em half
duplex é uma opção negociada no momento do estabelecimento de uma sessão. Se esta
opção é adotada, deverá ser definido também qual dos usuários envolvidos no diálogo
poderá tomar a iniciativa (possuidor da ficha).
Quando este usuário terminar a sua transmissão, ele pode ceder a ficha ao usuário
par para que ele possa efetuar a sua transmissão. A passagem de ficha de um usuário a
outro é implementada através da primitiva S_TOKEN_GIVE.
Ainda, se um dos usuários querendo efetuar uma transmissão não possui a ficha
naquele instante, ele pode requisitá-la a seu par através da emissão de uma primitiva
S_TOKEN_PLEASE.request.
O usuário receptor da primitiva S_TOKEN_PLEASE.indication pode ou não querer
ceder a ficha. Em caso negativo, o usuário que a requisitou não fará outra coisa senão
esperar a «boa vontade» do seu interlocutor (ou ainda, enviar dados urgentes que não
necessitam a possessão da ficha).
A ficha só passa a ter algum sentido no caso de comunicação half duplex. Se full
duplex é a opção adotada, ela não é levada em conta.
6.4. A sincronização
A camada de Sessão deve cobrir igualmente os problemas relacionados à

sincronização. Esta tarefa é útil para a manutenção da coerência do estado entre dois
usuários interlocutores em caso de erro ou outro problema.
Apesar de que a camada de Transporte tenha, por princípio, a função de cobrir todos
os problemas relacionados à retomada após ou erros ou panes, esta camada cobre
unicamente os problemas relacionados à transmissão de dados propriamente dita, não
levando em conta os problemas podendo ocorrer nas camadas superiores. Estes erros
podem ocasionar perdas de dados que a camada de Transporte é incapaz de detectar (uma
vez que esta não é a sua função!).
— 3.23 —
S_DATA
S_DATA S_DATA request
request request S_DATA
S_DATA
S_DATA S_DATA request indication
S_TOKEN_GIVE S_DATA
request indication
S_DATA S_DATA
request request S_TOKEN_GIVE
indication
S_DATA S_DATA
S_DATA
indication indication S_DATA
indication
request
(a) (b)
Figura 3.14 - (a) comunicação full duplex; (b) comunicação half duplex com ficha.
A camada de Sessão vem, então ao socorro do sistema efetuando a tarefa de

sincronização, através da inserção a nível dos dados de pontos de sincronização, que
permitem manter a sessão num estado correspondendo a um antigo ponto de
sincronização.
A figura 3.15(a) ilustra o procedimento de inserção de pontos de sincronização. Um
exemplo disto pode ser ilustrado na transmissão de um documento via rede, no qual este
pode ser decomposto em páginas às quais se pode associar os pontos de sincronização.
Neste caso, a resincronização vai consistir na retransmissão do documento a partir de uma
dada página que estava sendo transmitida quando o problema ocorreu.
A sincronização é implementada da seguinte forma: o usuário emissor insere, nas
suas mensagens, pontos de sincronização, cada ponto contendo um número de série.
Quando um usuário envia uma primitiva (request) para inserir um ponto de sincronização, o
outro usuário vai receber uma primitiva de indicação correspondente, isto ocorrendo de igual
maneira no caso de uma resincronização.
É importante notar aqui que a camada de Sessão oferece unicamente as
ferramentas para a solução dos problemas de erros e incoerência por
sincronização/resincronização. Na realidade, quem ativa estas ferramentas quando da
ocorrência de um problema são as entidades das camadas superiores. O mecanismo de
sincronização define dois tipos distintos de pontos de sincronização — os pontos de
sincronização máximos e mínimos.
SESSÃO
1 2 3 4 5 6 7 8 9
ponto de sincronização
(a)
SESSÃO
DIÁLOGO
1 5 9
2 3 4 6 7 8
ponto de sincronização
mínimo ponto de sincronização
máximo
(b)
Figura 3.15 - (a) Pontos de sincronização; (b) Pontos de sincronização máximos e mínimos.
— 3.24 —
Os pontos de sincronização máximos são utilizados para delimitar trechos da

informação denominados diálogos, que representam uma decomposição lógica da
informação (capítulos de um livro, por exemplo). Já os pontos de sincronização mínimos são
utlizados para separar porções menores da informação. No caso de um livro, esta porção
poderia ser as páginas dos capítulos. A figura 3.15(b) ilustra os pontos de sincronização
máximos e mínimos.
Uma diferença fundamental entre os pontos máximos e mínimos reside na
capacidade de resincronização. No caso de um ponto de sincronização máximo, após uma
pane, é possível resincronizar, no máximo, de um ponto de sincronização máximo para trás.
A partir deste ponto, é impossível recuperar informação. Isto ocorre porque um ponto
máximo é visto como uma fronteira de proteção, cuja informação anterior é garantida ter sido
recebida, o que significa que ela pode ser apagada da extremidade emissora. Isto já não
ocorre no caso dos pontos de sincronização mínimos.
Alem disso, pelo fato de que os pontos de sincronização máximos são tidos como
fronteiras de proteção da informação, estes devem ser explicitamente reconhecidos pelo
receptor, o que não é necessário no caso dos pontos de sincronização mínimos.
6.5. Gerenciamento de atividades
Outra função importante da camada de Sessão é o controle de atividades. Esta tarefa

é baseada no conceito de decomposição do fluxo de dados em atividades, independentes
umas das outras. O conceito de atividade vai depender da aplicação considerada, o usuário
sendo o responsável desta definição.
Um exemplo típico de utilização do conceito é a transferência de arquivos, onde cada arquivo
deve ser separado, de alguma forma dos demais. A forma de fazê-lo é através da definição,
de cada arquivo, como sendo uma atividade, como mostra a figura 3.16. Para fazê-lo, antes
da emissão de cada arquivo, o usuário deve enviar uma primitiva
S_ACTIVITY_START.request para marcar o início de uma atividade; isto vai gerar, no lado
do receptor, uma primitiva S_ACTIVITY_START.indication sinalizando o início do envio de
uma nova atividade (neste caso particular, o arquivo).
O fim da transferência de um arquivo é marcado, então, pelo envio, por parte do
emissor, de uma primitiva S_ACTIVITY_END.request. O interesse da definição de atividade
é o fato que certas aplicações podem ter a garantia de atomicidade, evitando erros devido a
panes ocorridas entre ações de uma mesma atividade.
Um exemplo de aplicação é o de uma operação bancária realizada através de um
terminal informatizado. A operação normal se desenrola da maneira seguinte:
• o proprietário da conta emite um comando informando o seu número de conta (e a

senha correspondente) — o computador do banco verifica o número e a senha, e
bloqueia o código correspondente a fim de evitar o acesso concorrente;
• o proprietário da conta envia um novo comando informando o número da conta
para onde o dinheiro deve ser transferido — o computador verifica o número da
conta e bloqueia o código correspondente pela mesma razão já apresentada;
• o proprietário, finalmente, emite um terceiro comando informando o montante a ser
transferido — o computador efetiva, então, a transferência para a conta
destinatária.
Um caso típico deste cenário é aquele em que uma pane (falta de energia, por
exemplo) ocorre no terminal sendo utilizado pelo cliente proprietário da conta imediatamente
após o primeiro comando. O computador vai bloquear o código correspondente à conta, mas
os demais comandos não serão efetuados. A aplicação do conceito de atividade via camada
de Sessão permite solucionar este problema, garantindo a atomicidade da operação. A
operação completa pode ser vista como uma atividade.
— 3.25 —
SESSÃO
ATIVIDADE ATIVIDADE
arquivo 2 arquivo 1
início atividade fim atividade
Figura 3.16 - Conceito de atividade aplicado a uma transferência de arquivo.
Assim, após a recepção de uma primitiva S_ACTIVITY_START.indication, o

computador do banco ficaria armazenando as mensagens (de comando) até a recepção de
uma primitiva S_ACTIVITY_END.indication. Só neste momento, os comandos seriam
efetivados pelo computador.
Uma outra propriedade interessante das atividades é a capacidade de ser
interrompida e retomada sem a perda das informações. Isto pode ser feito através da
primitiva S_ACTIVITY_INTERRUPT que permite iniciar uma nova atividade e retomar aquela
ao final desta segunda atividade a partir do ponto onde ela tinha sido interrompida.
Um exemplo típico é aquele da transferência de um arquivo de tamanho relativamente
grande, no qual, durante a transferência, seja necessário, com relativa urgência, efetuar a
consulta a uma base de dados (anuário telefônico, agenda, por exemplo). Este exemplo é
ilustrado na figura 3.17.
6.6. As primitivas de serviço de Sessão
O quadro a seguir apresenta a lista das primitivas de serviço oferecidas pela camada
de Sessão, indicando as classes de primitivas compondo cada serviço (R - request, I -
indication, Rs - response e C - confirm). São 58 primitivas organizadas em 7 grupos:
estabelecimento de conexão, liberação de conexão, transferência de dados, gerenciamento
de fichas, sincronização, gerenciamento de atividades e relatório de anomalias. Os dois
primeiros grupos são relacionados, respectivamente, à inicialização e término das sessões.
As primitivas S_CONNECT, conduzem, em seus parâmetros, informações tais como:
SSAPs dos interlocutores, qualidade do serviço, números iniciais dos pontos de
sincronização, etc...
Já os serviços de liberação de sessão podem ser de três tipos: o primeiro,
caracterizado pela primitivas S_RELEASE, especificando um serviço confirmado de término
negociado de sessão (sem perda de dados); os dois outros, para e liberação abrupta de
sessão (com eventual perda de dados), caracterizados pelas primitivas S_U_ABORT e
S_P_ABORT, indicando, respectivamente, terminação de iniciativa do usuário (U - user) e do
fornecedor do serviço (P - provider).
1 2 3 4 5 6
transf. arquivo consulta transf. arquivo

1ª parte anuário 2ª parte
1 início atividade 1 4 fim atividade 2
2 interrupção atividade 1 5 retomada atividade 1
3 início atividade 2 6 fim atividade 1
Figura 3.17 - Exemplo da interrupção de um atividade para a realização de outra.
— 3.26 —
PRIMITIVA R I Rs C FUNÇÃO
ORIENTADO CONEXÃO
S_CONNECT • • • • estabelecimento de conexão
S_RELEASE • • • • liberação negociada de conexão
S_U_ABORT • • liberação abrupta (usuário)
S_P_ABORT • liberação abrupta (fornecedor)
S_DATA • • transferência de dados normais
S_EXPEDITED_DATA • • transferência de dados urgentes
S_TYPED_DATA • • transferência de dados tipados
S_CAPABILITY_DATA • • • • transf. de dados de capacidade
S_TOKEN_GIVE • • passagem de ficha de dados
S_TOKEN_PLEASE • • pedido de ficha
S_CONTROL_GIVE • • passagem de todas as fichas
S_SYNC_MAJOR • • • • inserção de pto. de sincro. máximo
S_SYNC_MINOR • • • • inserção de pto. de sincro. mínimo
S_RESYNCHRONIZE • • • • pedido de resincronização
S_ACTIVITY_START • • início de uma atividade
S_ACTIVITY_END • • • • fim de uma atividade
S_ACTIVITY_DISCARD • • • • abandono de uma atividade
S_ACTIVITY_INTERRUPT • • • • interrupção de uma atividade
S_ACTIVITY_RESUME • • retomada de uma atividade
S_U_EXCEPTION_REPORT • • relatório de anomalia (usuário)
S_P_EXCEPTION_REPORT • relatório de anomalia (fornecedor)
SEM CONEXÃO
S_UNITDATA • • transferência de dados (s/ conexão)
O terceiro grupo é caracterizado pelas quatro classes de primitivas para a

transferência de dados (S_DATA, S_EXPEDITED_DATA, S_TYPED_DATA e
S_CAPABILITY_DATA) cada uma para um dos quatro tipos de dados (normais, urgentes,
tipados e de capacidade). Os dados normais e urgentes tendo sido discutidos em outras
oportunidades, cabe aqui uma apresentação dos dois outros tipos de dados.
Os dados tipados são similares aos dados normais do ponto de vista da
transferência, a diferença fundamental sendo a liberdade de transmissão sem a necessidade
de posse da ficha de dados. Este tipo de dados são utilizados, principalmente, para a troca
de mensagens de controle entre os dois usuários.
Os dados de capacidade são utilizados para a transferência de mensagens de
controle da própria cada de Sessão. O serviço S_CAPABILITY_DATA, como se pode ver na
tabela, é um serviço confirmado, fornecendo um reconhecimento dos dados de capacidade.
Ainda, ao contrário dos dados tipados, estes dados só podem ser transmitidos se a entidade
possui a ficha de transferência de dados.
O quarto grupo de serviços é relacionado ao gerenciamento das fichas, que são em
número de 4: as fichas de dados (para a transferência em half-duplex), as fichas de
liberação (para o início de uma liberação negociada), as fichas de sincronização mínima
(para a inserção de pontos de sincronização mínimos) e as fichas de sincronização máxima
e atividade (para o gerenciamento das atividades e da sincronização). S_TOKEN_GIVE
permite efetuar a transferência de uma ou mais fichas à entidade remota, as fichas a
transferir sendo indicadas nos parâmetros das primitivas.
O quinto grupo contém os serviços relativos à sincronização, seja para inserção de
pontos de sincronização (através dos serviços S_SYNC_MAJOR e S_SYNC_MINOR,
dedicados, respectivamente, à introdução de pontos de sincronização máximos e mínimos),
seja para a resincronização a partir de um ponto dado (S_RESYNCHRONIZE).
— 3.27 —
O sexto grupo, através dos serviços, S_ACTIVITY_START, S_ACTIVITY_END,

S_ACTIVITY_DISCARD, S_ACTIVITY_INTERRUPT e S_ACTIVITY_RESUME é dedicado
ao gerenciamento das atividades (início, fim, abandono, interrupção e retomada).
O sétimo grupo é dedicado à geração de relatórios de anomalia, tanto da parte de um
dos usuários (S_U_EXCEPTION_REPORT) quanto da camada de Sessão
(S_P_EXCEPTION_REPORT).
7. A CAMADA DE APRESENTAÇÃO
Quando foi concebida, a camada de Apresentação era responsável unicamente das

funções de conversão entre dados representados em ASCII e EBCDIC. Em seguida, novos
serviços foram introduzidos de forma que, atualmente, pode-se descrever a tarefa desta
camada por tudo o que possa estar relacionado à representação dos dados a serem
transmitidos, particularmente as funções de: conversão de dados, criptografia e
compressão.
As seções que seguem apresentarão os principais problemas e as soluções
encontradas na realização destas funções.
7.1. As primitivas de serviço da camada de apresentação
O quadro a seguir apresenta a lista de primitivas de serviço de Apresentação. Como

se pode notar, quase todas as primitivas são idênticas àquelas apresentadas na parte
anterior, relativa à camada de Sessão.
PRIMITIVA R I Rs C FUNÇÃO
ORIENTADO CONEXÃO
P_CONNECT • • • • estabelecimento de conexão
P_RELEASE • • • • liberação negociada de conexão
P_U_ABORT • • liberação abrupta (usuário)
P_P_ABORT • liberação abrupta (fornecedor)
P_DATA • • transferência de dados normais
P_EXPEDITED_DATA • • transferência de dados urgentes
P_TYPED_DATA • • transferência de dados tipados
P_CAPABILITY_DATA • • • • transf. de dados de capacidade
P_TOKEN_GIVE • • passagem de ficha de dados
P_TOKEN_PLEASE • • pedido de ficha
P_CONTROL_GIVE • • passagem de todas as fichas
P_SYNC_MAJOR • • • • inserção de pto. de sincro. máximo
P_SYNC_MINOR • • • • inserção de pto. de sincro. mínimo
P_RESYNCHRONIZE • • • • pedido de resincronização
P_ACTIVITY_START • • início de uma atividade
P_ACTIVITY_END • • • • fim de uma atividade
P_ACTIVITY_DISCARD • • • • abandono de uma atividade
P_ACTIVITY_INTERRUPT • • • • interrupção de uma atividade
P_ACTIVITY_RESUME • • retomada de uma atividade
P_U_EXCEPTION_REPORT • • relatório de anomalia (usuário)
P_P_EXCEPTION_REPORT • relatório de anomalia (fornecedor)
P_ALTER_CONTEXT • • • • alteração de contexto
SEM CONEXÃO
P_UNITDATA • • transferência de dados (s/ conexão)
— 3.28 —
No caso dos serviços orientados à conexão, por exemplo, os usuários desta camada,
ou seja, as entidades da camada de Aplicação podem abrir uma sessão utilizando a primitiva
P_CONNECT.request, que se reflete, na camada de Apresentação, pelo envio de uma
primitiva S_CONNECT.request, já descrita quando da apresentação da camada de Sessão.
De fato, a maior parte das primitivas de serviço de Apresentação atravessam desta
forma a camada. A novidade mostrada na camada são as primitivas P_ALTER_CONTEXT,
que compõem o serviço de alteração de contexto de Apresentação.
Um contexto é a unidade na qual são reagrupados as estruturas de dados utilizadas
pelas entidades de Aplicação. Ao longo de uma sessão, é possível utilizar um contexto
durante um determinado tempo e utilizar um outro num outro momento. O serviço
P_ALTER_CONTEXT permite fazer a modificação.
A camada de Apresentação viabiliza a negociação sobre que forma de representação
será adotada para os dados manipulados pela aplicação.
A negociação é baseada no fornecimento, por parte de um usuário, de todas as
estruturas de dados que ele deseja utilizar, sendo que o usuário par pode ou não aceitar a
proposta.
Durante o diálogo, ainda é possível que novas propostas de estruturas de dados
sejam negociadas pelos dois usuários.
7.2. A notação ASN.1
ASN.1 (Abstract Syntax Notation One) é uma sintaxe abstrata que foi definida na ISO
para solucionar a problemática da representação dos dados.
Isto foi motivado pela necessidade da existência de uma forma de representação de
dados que fosse suficientemente flexível e genérica para que pudesse ser utilizada pelas
mais diversas aplicações existentes.
ASN.1 é definida pela norma ISO 8824, que apresenta as estruturas de dados
previstas na sintaxe; outra norma, ISO 8825, define a sintaxe de transferência, ou seja, a
forma como as estruturas de dados ASN.1 podem ser mapeadas em binário.
As estruturas de dados ASN.1 foram definidas para prever as complexas estruturas
de dados que poderiam ser manipuladas a nível de uma dada aplicação. Um registro ou uma
estrutura de dados utilizada numa aplicação bancária pode conter os mais diversos campos,
como por exemplo o nome, o endereço, os números de conta, as taxas de câmbio do dia, a
data e hora, etc... Em outras aplicações, pode existir a necessidade de troca de estruturas
de dados as mais diversas possível, sendo que cada aplicação pode ter as suas próprias
estruturas de dados. Ainda, algumas estruturas de dados podem ser típicas de certas
aplicações, outras específicas a uma determinada empresa ou instituição.
Nos estudos apresentados das camadas inferiores, particularmente na apresentação
dos protocolos existentes, muitas estruturas de dados foram apresentadas na forma de
figuras, com seus campos sendo apresentados por retângulos. Estas estruturas podem ser
formalizadas por registros, filas, vetores, etc...
A camada de Aplicação, cujas entidades são os usuários da camada de
Apresentação, é caracterizada por muitas estruturas de dados, transmitidas na forma de
APDUs (Application Protocol Data Units), compostas de diferentes campos, cada campo
tendo um determinado tipo (booleano, inteiro, etc...).
A notação ASN.1 permite formalizar os diversos tipos de dados podendo compor os
campos de uma APDU, reagrupando-os inclusive num módulo de biblioteca para cada
aplicação típica. Desta forma, é possível a uma aplicação enviar uma estrutura de dados à
camada de Apresentação, dando a ela o nome da estrutura ASN.1 correspondente. A
camada de Apresentação poderá, então, conhecer o tipo e o tamanho de cada campo
compondo a estrutura de dados e, desta forma, codificá-los para a transmissão. A entidade
de Apresentação receptora, por sua vez, conhecendo a estrutura ASN.1 dos dados
recebidos, pode fazer todas as conversões que sejam necessárias para adaptar à máquina
receptora.
— 3.29 —
O interesse da existência de ASN.1 é que esta notação serve como uma linguagem
comum para todas as máquinas. Isto evita que todas as máquinas tivessem de conhecer
todas as possíveis formas de representação de cada uma das máquinas com as quais elas
teriam de se comunicar. Com ASN.1, basta apenas que cada máquina conheça como
codificar seus dados nesta notação. A norma ISO 8824 define a notação de sintaxe abstrata
ASN.1, onde os principais pontos serão apresentados a seguir. Um primeiro exemplo de
como um dado pode ser descrito em ASN.1, vamos fazer um paralelo entre uma estrutura
de dados Pascal e uma estrutura de dados ASN.1.
Vamos considerar que pretendemos representar por uma estrutura em Pascal as
principais características dos dinossauros. Isto poderia ser feito através de uma estrutura do
tipo record, onde cada campo teria seu tipo específico e representando uma característica
dos dinossauros. Um exemplo disto é mostrado a seguir:
type dinossauro = record

nome : array [1..12] of char;
tamanho : integer;
carnivoro : boolean;
ossos : integer;
descoberta : integer;
end;
No caso de ASN.1, a mesma estrutura de dados poderia ser representada da

seguinte forma:
dinossauro ::= SEQUENCE {

nome OCTET STRING, --12 chars
tamanho INTEGER,
carnivoro BOOLEAN,
ossos INTEGER,
descoberta INTEGER
}
Como se pode notar, não existem muitas diferenças entre a forma de especificar um
record Pascal e uma seqüência ASN.1. De fato, tipos complexos ASN.1 são gerados a partir
de tipos de base, denominados tipos primitivos. Os tipos primitivos ASN.1 são apresentados
na tabela a seguir.
TIPO SIGNIFICADO
INTEGER inteiro de valor arbitrário
BOOLEAN verdadeiro / falso
BIT STRING lista de bits
OCTET STRING lista de bytes
ANY conjunto de todos os tipos
NULL nenhum tipo
OBJECT IDENTIFIER nome de um objeto
Como foi dito, estes tipos podem ser combinados para a definição de estruturas de
dados mais complexas, isto pela utilização de construtores de ASN.1, onde os mais
utilizados são:
CONSTRUTOR SIGNIFICADO
SEQUENCE seqüência de elementos de diversos tipos
SEQUENCE OF seqüência de elementos de um mesmo tipo
SET conjunto (não ordenado) de elementos de diversos tipos
SET OF conjunto (não ordenado) de elementos de um mesmo tipo
CHOICE escolha de um tipo entre uma lista de tipos
— 3.30 —
O construtor SEQUENCE permite construir uma estrutura de dados cujos campos

sejam de tipos diferentes. Ele é bastante similar a um registro Pascal, como já foi visto no
exemplo anteriormente apresentado. SEQUENCE OF permite construir vetores de
elementos de um mesmo tipo. O construtor SET é similar ao SEQUENCE, com uma
diferença apenas — os elementos de um SET não ordenados como no caso do
SEQUENCE.
Da mesma forma, SET OF é similar a SEQUENCE OF, a mesma diferença sendo
válida para este caso.
O construtor CHOICE permite especificar um dado cujo formato pode assumir
diversas opções. Um exemplo da utilização deste construtor é mostrado abaixo.
PDU_Comando ::= CHOICE {
Comando_local,
Comando_remoto
}
Além dos tipos primitivos e construtores, existem ainda os tipos pré-definidos de

ASN.1, como por exemplo:
• NumericString, que define uma lista de numerais de 0 a 9 mais os brancos;
• PrintableString, que define uma lista cujos elementos podem ser as letras
maiúsculas, as minúsculas, os números e os caracteres ( ) ‘ + - . , / : = ?
• GeneralizedTime, para definir datas e horas.
Existe ainda, em ASN.1, a possibilidade de expressar estruturas de dados onde

alguns dos campos possam ou não estar presentes em tempo de execução — são os
campos opcionais. Isto é representado através da cláusula OPTIONAL.
Ainda, pode-se atribuir a um dado um valor inicial (por default) através da cláusula
DEFAULT.
Finalmente, ASN.1 define ainda o conceito de etiqueta (ou TAG), que permite
identificar um valor associando-o a um dado campo. Para mais detalhes sobre ASN.1,
aconselha-se uma consulta às normas ISO 8824/8825 e outros documentos disponíveis
sobre esta notação.
7.3. A compressão de dados
De um ponto de vista genérico, os dados transmitidos através de um canal podem

ser vistos como uma seqüência de símbolos S1, S2, ..., SN, pertencentes a um dado
alfabeto (bits, dígitos decimais, letras, palavras de uma língua, etc...).
As técnicas de compressão de dados existentes são baseadas sobre três diferentes
aspectos da representação de dados: a limitação do alfabeto, as freqüências relativas dos
símbolos, o contexto de aparecimento dos símbolos. Estes três pontos de vista serão
analisados a seguir.
7.3.1. Codificação de um alfabeto finito de símbolos
Muitas aplicações são baseadas na representação dos dados através de alfabetos

finitos de símbolos. Um exemplo disto são as aplicações relacionadas à utilização de
terminais, onde os dados são representados pelo alfabeto ASCII.
Consideremos o exemplo do gerenciamento de uma biblioteca, onde um livro poderia
ser identificado pelo seu título, o título de um livro podendo ser expresso em 20 caracteres
(ou 140 bits).
Isto significa que, com uma palavra de 140 bits, poderíamos identificar até 2140 livros.
No entanto, não existem biblioteca no mundo que possua esta quantidade de livros. Assim,
se, ao invés de identificarmos os livros pelo seu título escolhermos um sistema de
— 3.31 —
numeração, poderemos diminuir em muito a quantidade de bits necessária para a

identificação de um livro de qualquer biblioteca.
7.3.2. Codificação dependente da freqüência
Em determinadas aplicações, muitos símbolos de um alfabeto são muito mais

utilizados que outros. Nos textos em Inglês, por exemplo, a letra “E” aparece 100 vezes mais
freqüentemente que a letra “Q”, a palavra “THE” aparecendo 10 vezes mais que “BE”.
Baseados nestas informações, os dados podem ser codificados de tal forma que
símbolos ou seqüências de símbolos sabidamente mais freqüentes que outros sejam
representados de uma forma especial, simplificada no que diz respeito à quantidade de
informação necessária.
As técnicas consistem normalmente em codificar os símbolos mais freqüentes por
códigos curtos e os menos freqüentes por códigos mais longos. Um exemplo desta técnica
de compressão foi apresentada em 6.1.2.
7.3.3. Codificação baseada no contexto
A técnica apresentada acima é baseada na ocorrência de símbolos ou determinadas

seqüências de maneira isolada, como se a probabilidade de ocorrência dos símbolos ou
seqüências fosse independente daquela que os precede. Na verdade, estas probabilidades
podem ser altamente dependentes da informação precedente. Por exemplo, no caso de um
texto em Português, a probabilidade de ocorrer a letra “T” após a letra “Q” é muitas vezes
inferior que a probabilidade de ocorrer uma letra “U” após “Q”. A probabilidade de ocorrência
de uma letra “P” após uma letra “N” numa palavra é nula, a menos que um erro de ortografia
tenha sido cometido.
Uma técnica mais sofisticada que aquela é de levar em conta este aspecto
calculando a probabilidade relativa de ocorrência de cada símbolo após os demais símbolos
de um alfabeto.
No caso das letras, como o exemplo citado acima, isto vai significar na construção de
26 tabelas, cada uma contendo as probabilidades das letras seguindo uma letra do alfabeto.
Se uma forte correlação existir entre os símbolos, a taxa de compressão vai ser muito
melhor que aquela obtida com a utilização da técnica apresentada anteriormente.
Uma desvantagem desta técnica é a grande quantidade de tabelas requerida para a
definição das probabilidades relativas. No caso de um alfabeto composto de k símbolos,
serão necessárias k 2 entradas em tabela.
Um método possível de compressão é a organização dos símbolos em tipos, por
exemplo, no caso de letras e números, pode-se classificá-los em maiúsculas, minúsculas,
caracteres numéricos e caracteres especiais. Assim, quatro códigos podem ser associados
aos quatro tipos e 28 códigos vão permitir codificar os caracteres. A idéia de base desta
técnica é que, a princípio, todo símbolo após uma letra minúscula tem fortes possibilidades
de ser também uma letra minúscula, todo símbolo seguindo um caractere numérico é
também um caractere numérico, etc... Quando se quer chavear de um tipo de símbolo a
outro, basta inserir o código associado ao novo tipo.
Uma técnica similar pode ser utilizada para codificar longas seqüências de dados
binários contendo grandes quantidades de zeros. Cada símbolo de k bits indica quantos
zeros separam dois 1’s consecutivos. Assim, para tratar grandes faixas de zeros, o símbolo
1 indica que uma faixa de 2k - 1 mais o valor do símbolo seguinte separa os dois uns. Por
exemplo, para a seqüência
000100000100000010000000000000010000001000100000001100000101
que contém as faixas de zeros de comprimentos: 3,5,6,14,6,3,7,0,1,5 e 1, pode-se

utilizar a codificação seguinte:
— 3.32 —
011 101 110 111 111 000 110 011 111 000 000 001 101 001
onde a faixa de 14 zeros é codificada por 111 111 000 (ou seja, 7 + 7 + 0 = 14). Neste
caso, a compressão permitiu reduzir em 34% o tamanho da informação.
Uma aplicação desta técnica pode ser feita, com algumas modificações, na
transmissão digital de imagens de televisão colorida. O sinal é constituídos de uma
seqüência de quadros, de 25 a 30 por segundo, cada um contendo um vetor retangular de
pontos (pixels) da imagem. Uma imagem de televisão pode ser composta de 1000 linhas de
600 pixels, cada pixel sendo codificado em 16 bits, 15 bits para a cor (com 32 níveis para
cada cor) e 1 bit para informação de controle (enquadramento vertical ou horizontal).
Uma codificação direta desta informação necessitaria 600000 pixels por quadro, ou
seja, uma taxa de transmissão de 240 a 288 Mbits/s. Com uma codificação binária, seria
necessário dispor de uma faixa de freqüência de quase 600 MHz. Uma vez que a
transmissão analógica ocupa faixas de freqüência de apenas 6 MHz, a transmissão digital,
sem compressão de imagem, poderia tornar-se inviável.
A solução está no fato que, em transmissão de imagens, existe uma forte
probabilidade de que muitos quadros consecutivos sejam idênticos àqueles que os
precederam. Desta forma, basta providenciar, a nível dos televisores, uma memória que
possa armazenar o último quadro recebido e, assim, transmitir apenas as diferenças entre o
quadro anterior e o atual.
7.4. A criptografia
A criptografia é uma técnica bastante antiga, introduzida principalmente pelas

organizações militares, particularmente na troca de mensagens em tempo de guerra.
Nessas ocasiões, um problema da criptografia era a dificuldade de decodificação das
mensagens criptografadas, muitas vezes tendo de ser feitas nos campos de batalha em
condições totalmente adversas. Outro problema era a dificuldade na mudança de uma
técnica a outra, particularmente devido à dificuldade em informar o grande número de
pessoas que deveria estar consciente da mudança.
O processo de criptografia de uma mensagem é ilustrado pela figura 3.18. As
mensagens a serem criptografadas são codificadas graças a uma função parametrizada por
uma chave, gerando, na saída o texto criptografado ou o criptograma. Este texto é
transmitido por um mensageiro ou rádio, este podendo ser «escutado» por um espião.
A diferença entre o espião e o destinatário é que, como o primeiro não tem a chave
de decodificação, ele dificilmente vai poder decodificar a mensagem. Os espiões podem
efetuar dois tipos de ação sobre os criptogramas, copiá-los unicamente para conhecer o seu
conteúdo (espião passivo) ou modificá-los de modo a confundir o destinatário destes (espião
ativo).
Um princípio das técnicas de criptografia é a suposição de que o espião conhece
sempre as técnicas gerais da criptografia, ou seja, que pelo menos o esquema apresentado
na figura 3.18 é conhecido. Por outro lado, criar a cada vez um método diferente de
criptagem a cada vez que um outro é considerado conhecido representa um trabalho
considerável.
A forma mais eficiente de tentar «esconder o jogo» é através da introdução das
chaves. As chaves consistem de seqüências de caracteres relativamente curtas que
permitem escolher um método de criptagem em função do seu valor. A vantagem disto é
que, enquanto uma técnica de criptagem pode ser modificada numa escala de anos, uma
chave pode ser modificada quando se julgar necessário.
Os métodos de criptografia podem ser organizados em duas principais classes: os
métodos por substituição e os métodos por transposição cujos principais pontos serão
vistos a seguir.
— 3.33 —
espião passivo espião ativo
ESPIÃO
Processo de Processo de
M M
codificação decodificação
criptograma
chave de chave de
codificação (k) decodificação
Figura 3.18 - O processo de criptografia.
7.4.1. A criptagem por substituição
Nestes métodos, cada letra ou grupo de letras é literalmente substituído por outra
letra ou outro grupo de letras. A técnica mais antiga de criptagem é atribuída a Júlio César,
que definiu uma técnica onde cada letra do alfabeto seria substituída por uma letra que
estivesse 3 passos à sua frente ou seja, a seria codificada em D, b seria codificada em E, c
seria codificada em F, etc..., e isto de maneira rotativa, de modo que z seria codificado em C.
Desta forma, a palavra REDE ficaria... UHGH, portanto, irreconhecível.
Esta técnica poderia ainda ser generalizada, pelo deslocamento do alfabeto de k
passos ao invés de 3. A esta técnica generalizada, dá-se o nome de permutação circular.
Uma outra técnica, a substituição monoalfabética, é uma extensão à permutação
circular, mas, desta vez, as letras podem ser substituídas por qualquer outra. Por exemplo,
se o alfabeto
abcdefghijklmnopqrstuvwxyz
é substituído por
N B V C X W M L K J H G F D S Q P O I U Y T R E Z A,
a palavra REDE torna-se, agora, OXCX.
Com esta técnica, existem 26! (4.1026) chaves possíveis. Mesmo que o espião
conheça a técnica, como ele não conhece a chave, ele teria dificuldade para descobrir o
significado do criptograma. No entanto, esta dificuldade pode ser diminuída se forem
consideradas as propriedades naturais da língua utilizada. Na língua inglesa, por exemplo,
existem letras que são mais freqüentemente utilizadas, como por exemplo, as letras e, t, o,
..., os digramas mais freqüentes são th, in, er, ... e os trigramas mais utilizados são the, ing,
and e ion. E o trigrama mais utilizado da lÍngua portuguesa? Nos últimos meses, deve ter
sido CPI.
Desta forma, a decodificação de um criptograma obtido com a substituição
monoalfabética, é feita associando-se a letra mais freqüente à letra mais freqüente da língua
considerada, os digramas mais freqüentes àqueles mais freqüentes da língua considerada,
etc...
7.4.2. A criptagem por transposição
Na criptagem por substituição, apesar da substituição das letras, os códigos mantém

a ordem correta das letras nas palavras e frases. Na codificação por transposição, as letras
— 3.34 —
não são substituídas, mas de fato, transpostas de tal forma a esconder o verdadeiro
significado do texto.
Uma técnica de criptagem é mostrada na figura 3.19, denominada transposição por
colunas. Nesta técnica as linhas serão trocadas pelas colunas numeradas em função de
uma chave que é, normalmente, uma palavra não contendo nenhuma letra repetida. No
exemplo, a chave considerada é a palavra PESCAR, onde a ordem das colunas associadas
a cada uma das letras vai ser 4-3-6-2-1-5. Assim, um texto como...
TRANSFERIR UM M ILHÃO PARA A CONTA DE COLLOR o criptograma obtido será ...
SUAADONRHAALRRIANOTEM POCFM OCERAILRTL.
8. A CAMADA DE APLICAÇÃO
A camada de Aplicação tem por função o gerenciamento dos programas de usuário

(programas de aplicação) que executam em máquinas conectadas e utilizam o sistema de
comunicação para a troca de informações.
Os programas de aplicação executando via um sistema de comunicação baseada no
modelo OSI vão utilizar-se dos serviços de comunicação oferecidos pela camada de
Apresentação, descrita na parte anterior do documento.
Esta camada é a que mantém o contato direto com os usuários da arquitetura de
comunicação, abrindo caminho para todos os serviços oferecidos pelas camadas inferiores.
Dentro desta parte, serão estudados os principais aspectos relacionados à camada
de Aplicação, particularmente, a sua estrutura e os conceitos associados e alguns exemplos
de serviços oferecidos a nível de Aplicação.
8.1. Estrutura da camada de Aplicação
A grande diversidade das aplicações podendo ser construídas sobre uma arquitetura
de comunicação e a questão da heterogeneidade dos sistemas, fator importante da
concepção do modelo OSI, conduziu, no âmbito da ISO, à definição de uma arquitetura
unificada para a camada de Aplicação, ALS (Application Layer Structure), definida pela
norma ISO 9545.
Nesta definição, a norma não propõe serviço de Aplicação, mas introduz um conjunto
de conceitos relacionados à estrutura da camada, que pode servir como base para a
definição de outras normas ou propostas de serviços de Aplicação.
P E S C A R
4 3 6 2 1 5 Texto original:
T R A N S F TRANSFERIR UM MILHAO PARA A

CONTA DE COLLOR
E R I R U M
Texto codificado
M I L H A O
SUAADONRHAALRRIANOTEMPOC
P A R A A C FMOCERAILRTL
O N T A D E
C O L L O R
Figura 3.19 - Exemplo da transposição por colunas.
— 3.35 —
8.1.1. Características específicas da camada de Aplicação
Dado que a camada de Aplicação é a mais alta do modelo OSI, ela não fornece
serviço a nenhuma outra camada, a noção de conexão ficando, então, inadequada a nível de
Aplicação. Por outro lado, a comunicação entre entidades de Aplicação pares deve ser
suportada por alguma forma de relação que permita a troca de informações de controle dos
protocolos de Aplicação, esta forma de relação sendo definida como uma Associação de
Aplicação.
Os elementos compondo a arquitetura da camada de Aplicação vão se utilizar das
facilidades oferecidas pela camada de Apresentação para a manipulação e a representação
de dados, e os mecanismos de controle de diálogo oferecidos pela camada de Sessão. As
interações entre os programas aplicativos permitem modelizar a operação cooperativa entre
os sistemas abertos reais, necessitando porém o compartilhamento de uma quantidade de
informações que viabilize estas interações, a fim de que o tratamento das atividades seja
feito de maneira coerente.
Três tipos de informação são, particularmente, relacionados à natureza das
interações entre os programas aplicativos:
• o conjunto de objetos sujeito às atividades de tratamento de informação;
• os procedimentos de controle e de cooperação do tratamento distribuído para a
comunicação entre programas;
• os estados das interações passadas entre programas de aplicação.
8.1.2. Conceitos relacionados à camada de Aplicação
As seções que seguem permitem introduzir alguns elementos relacionados à

arquitetura da camada de Aplicação, particularmente, os Processos de Aplicação, as
Entidades de Aplicação, as Associações de Aplicação, etc...
Um Processo de Aplicação ou AP (Application Process) representa, de forma
abstrata os elementos de um sistema aberto real que realiza o tratamento de informação no
contexto de uma aplicação particular. Dependendo da natureza da aplicação considerada,
um processo de Aplicação pode ter necessidade de trocar informações com outros
processos de Aplicação, as interações necessárias a esta troca podendo ser realizadas a
partir de um número distinto de partes invocáveis simultaneamente ou seqüencialmente. A
atividade de um Processo de Aplicação é caracterizada, formalmente por uma instância ou
Invocação de Processo de Aplicação ou API (Application Process Invocation).
Uma Entidade de Aplicação ou AE (Application Entity) representa as capacidades de
comunicação (dentro do contexto OSI) de um Processo de Aplicação. Uma ou várias
Entidades de Aplicação permitem definir o que o ambiente OSI leva em conta para a
comunicação de um processo de comunicação. Uma Entidade de Aplicação representa um
único Processo de Aplicação. Por outro lado, um mesmo Processo de Aplicação pode
reagrupar diversas Entidades de Aplicação. Além disso, diferentes Processos de Aplicação
podem ser representados por Entidades de Aplicação de mesmo tipo, um Processo de
Aplicação podendo reagrupar diversas Entidades de Aplicação de tipos diferentes. Uma
Invocação de Entidade de Aplicação ou AEI (Application Entity Invocation) é uma utilização
das capacidades de uma AE para as atividades de comunicação específicas de um
Processo de Aplicação.
Uma Associação de Aplicação ou AA (Application Association) é uma relação
cooperativa estabelecida entre duas AEIs para a troca de informações. Uma ou mais AAs
são criadas quando duas AEIs devem trocar informações no contexto de uma dada
aplicação. Isto significa que uma AEI pode manter, simultânea ou sequencialmente, mais de
uma AA com uma ou diversas AEIs.
Um Elemento de Serviço de Aplicação ou ASE (Application Service Element)
compreende um par serviço-protocolo normalizado que pode constituir uma Entidade de
Aplicação. Ele corresponde a um subconjunto das funções ou facilidades de comunicação
— 3.36 —
oferecidas para o suporte de cooperação entre Entidades de Aplicação. Estas funções e

facilidades são definidas pela especificação de um conjunto de Unidades de Dados de
Protocolo de Aplicação ou APDUs (Application Protocol Data Units) assim como os
procedimentos associados à sua utilização, definindo o Protocolo de Aplicação entre dois
ASEs.
Finalmente, um conceito importante é o de um Contexto de Aplicação, que
corresponde ao conjunto de regras e funções a serem implementadas ao longo da duração
de uma Associação de Aplicação para a gestão das trocas de informações entre AEIs.
As possíveis relações entre os conceitos aqui descritos são ilustradas pela figura 3.20.
Outros conceitos importantes no que diz respeito à estrutura da camada de Aplicação
são os Objetos de Associação Simples e a Função de Controle de Associação Simples.
Os Objetos de Associação Simples ou SAO (Single Association Object) são os elementos
que representam as funções e as informações de estado relacionadas às operações de uma
associação de aplicação simples, o conceito de «simples» estando relacionado ao sentido
de «único». Os componentes básicos de um SAO são o Elemento de Serviço de Controle
de Associação ou ACSE (Association Control Service Element) e a Função de Controle de
Associação Simples ou SACF (Single Association Control Function) que serão definidas
mais adiante. Um SAO representa igualmente a operação de um conjunto de ASEs
existentes numa AEI para uma associação de Aplicação particular.
A Função de Controle de Associação Simples é o elemento que representa a
coordenação das interações e a utilização dos elementos de um SAO.
8.1.3. Exemplos de Estruturas de AEIs
A forma como uma AEI pode ser composta a partir dos diversos elementos definidos
acima é ilustrada a partir de dois exemplos, apresentados nas figuras 3.21 e 3.22,
respectivamente.
Em 3.21, é apresentado um caso simples de uma AEI envolvida numa associação de
Aplicação única. Ela é composta então de um SAO, constituído por dois ASEs e uma função
de controle.
Em 3.22, é apresentada uma AEI envolvida em três associações. No caso de
múltiplas associações, algumas atividades de uma mesma aplicação podem ser distribuídas
sobre várias associações. Neste caso, estas atividades devem ser coordenadas e
ordenadas através de um conjunto de funções da própria aplicação. Este conjunto defunções
é reagrupado, no modelo da camada de Aplicação, por um elemento denominado Função de
Controle de Associações Múltiplas ou MACF (Multiple Association Control Function).
AP API AP API
AE AEI
AE AEI CONTEXTO DE AE
ASEs APLICAÇÃO ASEs AEI
ASSOCIAÇÕES CONSECUTIVAS
OU SIMULTÂNEAS
Figura 3.20 - Conceitos da arquitetura da camada de Aplicação.
— 3.37 —
Camada de Aplicação
AEI
SAO
S
ASE
A
C
ACSE
F
D
A E
S
S A
O P
Camada de C L
Apresentação I I
A C
Ç A
Ã Ç
O Ã
O
Figura 3.21 - Uma AEI simples.
Camada de Aplicação
AEI
MACF
SAO 1 SAO 2 SAO 3

S ASE 1 S ASE 3 S ASE 3
A A A
ASE 2 ASE 4 ASE 5
C C C
F ACSE F ACSE F ACSE
Camada de
Apresentação
Figura 3.22 - AEI com múltiplas associações.
Na figura 3.22, uma das associações é utilizada de maneira totalmente independente

das demais, enquanto as duas outras são utilizadas num mesmo conjunto de atividades que
requerem a existência de uma MACF, como mostrado na figura.
8.2. ACSE e os serviços de gestão das conexões
A gestão de conexões é um dos problemas a serem resolvidos pela camada de

Aplicação, de forma a evitar que cada aplicação desenvolvida tenha de resolver esta questão
à sua maneira. Assim, a nível desta camada, foi definido um Elemento de Serviço de
Controle de Associação, o ACSE (Association Control Service Element) que assume esta
tarefa.
— 3.38 —
Como a totalidade das aplicações conhecidas requer, normalmente os serviços de

gestão de conexão, este elemento de serviços deve estar sempre presente a nível dos
contextos de Aplicação.
Nas seções que seguem, apresentaremos os serviços supridos por este elemento
de serviço, assim como as interfaces deste com os serviços das camadas inferiores.
8.2.1. Os serviços oferecidos pelo ACSE
Os serviços oferecidos pelo ACSE são definidos pelas primitivas apresentadas no

quadro a seguir.
A-ASSOCIATE Estabelecimento de conexão
A-RELEASE Liberação negociada de conexão
A-ABORT Liberação abrupta de conexão (usuário)
A-P-ABORT Liberação abrupta de conexão (fornecedor)
A_ASSOCIATE é um serviço confirmado que permite estabelecer uma associação a

partir de um elemento de serviço de aplicação. Dentre os parâmetros da primitiva de serviço,
é enviada a proposição de contexto de Aplicação. Em caso de aceitação por parte do
receptor da indicação, a associação será, então, estabelecida.
O serviço A_RELEASE é um serviço confirmado que permite liberar, de maneira
ordenada, uma associação estabelecida entre duas AEIs, caracterizando uma liberação
negociada, como definido na parte relativa à camada de Sessão.
A_ABORT é um serviço não confirmado que permite «abortar», ou liberar de forma
abrupta uma associação existente. Como já descrito anteriormente, neste caso podem
ocorrer perdas de informações sendo trocadas através da associação. A ativação deste
serviço é de iniciativa do usuário do ACSE. A_ABORT pode ser ativado pelo iniciador do
serviço A_ASSOCIATE, no caso em que não exista concordância a respeito do contexto de
aplicação a utilizar.
A_P_ABORT é o serviço que efetua o mesmo que A_ABORT, sendo que, desta vez,
a iniciativa é do fornecedor do serviço.
8.2.2. As interfaces do ACSE com os serviços de Apresentação
O ACSE tem acesso a serviços de duas das camadas inferiores, particularmente, a

camada imediatamente inferior, de Apresentação, e a camada de Sessão.
No que diz respeito aos serviços de Apresentação, uma primeira correspondência
que se pode estabelecer é o de uma associação com uma conexão de Apresentação. Deste
ponto de vista, existem uma correspondência de 1 para 1, ou seja, uma associação de
Aplicação corresponde a uma conexão de Apresentação. O ACSE necessita utilizar
unicamente os serviços de base da camada de Apresentação, ou seja, os serviços
P_CONNECT, P_RELEASE e P_U_ABORT. O iniciador do serviço A_ASSOCIATE deve
determinar o contexto de Apresentação pretendido.
8.3. Os serviços de acesso e transferência de arquivos (FTAM)
Em 1987, foi publicada pela ISO a versão definitiva da norma de serviços de acesso e
transferência de arquivos, FTAM (File Transfer, Access and Management), com o número
ISO 8571.
A norma cobre um dos assuntos mais importantes da interconexão de sistemas,
uma vez que ela normaliza o protocolo que permite oferecer os serviços de acesso e
transferência de arquivos.
FTAM permite a transferência do todo ou de parte de um arquivo, ao destinatário ou a
uma estação (sistema) distante, oferecendo ainda serviços de controle de erros, retomada
— 3.39 —
imediata ou não, controle de acesso a arquivos (acesso seletivo, proteção, ...) e modificação
dos atributos de um arquivo.
O tratamento de arquivos via FTAM é baseado no conceito de arquivo virtual, que
permite representar, para os serviços FTAM o arquivo real. A relação entre estes elementos
é apresentada na figura 3.23. A noção de arquivo virtual permite tornar transparente ao
usuário as diferentes formas de armazenamento e os métodos de acesso dos sistemas de
arquivo real. FTAM permite estabelecer as relações entre o sistema de arquivos real e os
sistemas de arquivos virtuais.
8.3.1. O servidor virtual de arquivos
Um servidor virtual de arquivos reagrupa todas as informações relativas aos

arquivos, estas, permitindo conhecer o estado de um arquivo num dado instante. O modelo
definido para o servidor de arquivos virtuais contém atributos os mais genéricos possíveis
quanto à representação dos aspectos de um servidor de arquivos reais.
Este é modelado como uma entidade endereçável com a qual um usuário remoto
pode se comunicar, utilizando os serviços FTAM. A princípio, um número arbitrário de
usuários pode ser associado a um mesmo servidor virtual de arquivos num dado instante.
Ainda, um servidor virtual de arquivos pode gerenciar um número arbitrário de
arquivos, onde cada arquivo é caracterizado por atributos tais como: o nome, ações
possíveis sobre o arquivo (leitura, inserção, substituição, ...), controle de acesso (somente
leitura, somente escrita, ...), tamanho do arquivo, identidade do criador, data e hora de
criação, identidade do último modificador, data e hora de modificação, etc... A seleção de um
arquivo é caracterizada por duas etapas: o estabelecimento de uma associação entre o
usuário querendo selecioná-lo e o servidor virtual de arquivos; o fornecimento da identidade
do arquivo a selecionar.
A estrutura de acesso aos arquivos num servidor virtual de arquivos assume a forma
arborescente, coerente com as estruturas mais genéricas dos sistemas reais de arquivos.
Esta estrutura é ilustrada pela figura 3.24, onde se pode ver um único nó raiz (R), nós
internos (A, E) e folhas (B, C, D, F) conectadas por arcos dirigidos.
Sistema Real A Sistema Real B
ARQUIVO ARQUIVO
REAL A REAL B
Ambiente OSI
ARQUIVO protocolo FTAM ARQUIVO

VIRTUAL A VIRTUAL B
ARQUIVO
VIRTUAL C
ARQUIVO
REAL C
Sistema Real C
Figura 3.23 - Relação entre arquivos virtuais e arquivos reais.
— 3.40 —
Um nó da árvore pode pertencer a um único nível, podendo, por sua vez, servir de
acesso à sua subárvore, conhecida como uma Unidade de Dados de Acesso a Arquivo ou
FADU (File Access Data Unit). O conteúdo de um arquivo pertencente ao servidor de
arquivos é mantido numa ou mais Unidade de Dados ou DU (Data Unit). Uma DU é um
objeto de dados tipado (escalar, vetor, conjunto, ...), contendo elementos de dados atômicos
denominados Elementos de Dados, aos quais é normalmente associada uma sintaxe
abstrata (caractere, byte, inteiro, ...). Os serviços associados a um servidor virtual de
arquivos são acessados via primitivas de serviço, que serão apresentadas na seção a
seguir.
8.3.2. As primitivas de serviço de FTAM
Os serviços oferecidos por FTAM para o acesso e a transferência de arquivos são

organizados em unidades denominadas regimes. Os regimes correspondem a etapas da
manipulação de arquivos, o quadro a seguir apresenta o conjunto de primitivas associado a
cada um deles.
O FTAM, como foi apresentado, constitui-se de um importante elemento de serviço
de aplicação (ASE) para as aplicações que exijam manipulação ou transferência de arquivos,
sejam aplicações de automação de escritório ou de automação da manufatura. No que diz
respeito a esta segunda classe de aplicações, podemos destacar como um importante
elemento de serviço de aplicação, o ASE MMS (Manufacturing Message Services).
CONEXÃO DE APLICAÇÃO autorização e informações para operação

F_INITIALIZE inicialização da associação
F_TERMINATE terminação negociada de associação
F_ABORT terminação abrupta da associação
SELEÇÃO DE ARQUIVO identificação de arquivos a manipular
F_SELECT seleção de um arquivo existente
F_CREATE criação de um arquivo
F_DESELECT liberação de um arquivo
F_DELETE eliminação de um arquivo
F_READ_ATTRIB leitura dos atributos do arquivo
F_CHANGE_ATTRIB modificação de atributos de um arquivo
ACESSO A ARQUIVO abertura, fechamento, etc...
F_OPEN abertura de um arquivo
F_CLOSE fechamento de arquivo
F_LOCATE localização de um arquivo
F_ERASE eliminação de conteúdo de um arquivo
TRANSF. DE DADOS transferência de dados entre arquivos
F_READ leitura do conteúdo de um arquivo
F_WRITE escrita sobre um arquivo
F_DATA transferência de dados
F_DATA_END transferência de fim de dados
F_TRANSFER_END fim de transferência de dados
— 3.41 —
FADU
R
DU NÍVEL 0
FADU
FADU E
A
DU DU NÍVEL 1
B C D F
DU DU DU DU NÍVEL 2
Figura 3.24 - Estrutura de acesso do servidor virtual de arquivos.
— 3.42 —
Capítulo 4
AS RE D E S LO C A I S
1. INTRODUÇÃO
A solução para o compartilhamento de recursos físicos e lógicos juntamente com a

vantagem de se ter um sistema descentralizado foi alcançada através da interconexão das
CPUs entre si. É a isso que se propõem as redes de computadores. A solução para a
comunicação de computadores em termos de longa distância foi a tecnologia de comutação
de pacotes, que solucionou o problema da linha telefônica dedicada. Para pequenas
distâncias a solução foi a implantação de redes locais.
De uma forma geral, o objetivo de uma rede é tornar disponível a qualquer usuário
todos os programas, dados e outros recursos independente de suas localizações físicas.
Outro objetivo é proporcionar uma maior disponibilidade e confiabilidade, dada a possibilidade
de migração para outro equipamento quando a máquina sofre alguma falha. O uso de uma
rede de computadores proporciona um meio de comunicação poderoso devido a sua
velocidade e confiabilidade.
2. CLASSIFICAÇÃO DAS REDES DE COMPUTADORES
Uma rede de computadores é formada por um conjunto de módulos processadores

capazes de trocar informações e compartilhar recursos, interligados por um sistema de
comunicação. O sistema de comunicação vai se constituir de um arranjo topológico
interligando os vários módulos processadores através de enlaces físicos, através dos meios
de transmissão, e de um conjunto de regras com fim de organizar a comunicação, os
protocolos de comunicação.
Redes Locais (LANs - Local Area Networks) surgiram dos ambientes de institutos de
pesquisa e universidades. Elas surgiram para viabilizar a troca e o compartilhamento de
informações e dispositivos periféricos preservando a independência das várias estações de
processamento e permitindo a integração em ambientes de trabalho cooperativo. Pode-se
caracterizar uma rede local como sendo uma rede que permite a interconexão de
equipamentos de comunicação de dados numa pequena região. Nas redes locais as
distâncias entre os módulos processadores se enquadram na faixa de alguns metros a
alguns poucos quilômetros. Esta definição é bastante vaga, considerando “pequenas
distâncias” entre 100m e 25km, embora as limitações associadas às técnicas utilizadas em
redes locais não imponham limites a essas distâncias.
Quando a distância de ligação começa a atingir distâncias metropolitanas chamamos
estes sistemas de Redes Metropolitanas (MANs - Metropolitan Area Networks). Uma rede
metropolitana apresenta características semelhantes às redes locais, porém cobrindo
distâncias maiores e operando em velocidades maiores. Esta definição surgiu com o
aparecimento do padrão de protocolos para redes metropolitanas IEEE 802.6, que faz parte
do padrão IEEE 802 e é denominado DQDB (Distributed Queue Dual Bus).
— 4.1 —
CAP. 4 — AS REDES LOCAIS PROF. VITÓRIO BRUNO MAZZOLA
Redes Geograficamente Distribuídas (WANs - Wide Area Networks), ou Redes

de Longa Distância, são utilizadas para compartilhar recursos especializados por uma
maior comunidade de usuários geograficamente dispersos. Em função dos custos de
comunicação serem bastante altos estas redes são, em geral, públicas, isto é, o sistema de
comunicação, chamado sub-rede de comunicação, é mantido, gerenciado e de propriedade
pública. Em função dos custos as velocidades empregadas são relativamente baixas, de
alguns kilobits/segundo, podendo chegar a megabits/segundo.
3. PARÂMETROS DE COMPARAÇÃO
A escolha de um tipo de rede para suporte a um dado conjunto de aplicações é uma

tarefa difícil. Cada arquitetura de rede possui características que afetam sua adequação a
uma aplicação em particular. Muitos podem ser os atributos que fazem parte do rol possível
de ser considerado para comparação. Dentre eles estão custo, tempo de resposta,
velocidade, desempenho, confiabilidade, modularidade, compatibilidade, e facilidade de
adaptação na mudança de tecnologia. Estes pontos serão discutidos brevemente a seguir.
3.1. Custo
O custo de uma rede é composto pelo custo das estações de processamento, das
interfaces com o meio físico de comunicação e o custo do próprio meio físico. Uma vez que
os custos das estações estão cada vez menores é necessário que o custo das interfaces
seja minimizado.
O que irá determinar o custo das interfaces é proporcional ao desempenho que se
espera da rede. Redes de baixo a médio desempenho usualmente empregam poucas
estações com uma demanda de taxas de dados e volume de tráfego pequeno, permitindo o
uso de interfaces de baixo custo. Redes de alto desempenho já requerem interfaces de
custo mais elevado.
3.2. Retardo de Transferência
Retardo de acesso é o tempo que uma estação espera, a partir do momento que
uma mensagem está pronta para ser transmitida, até o momento em que ela consegue
transmitir com sucesso esta mensagem. Retardo de transmissão é o intervalo de tempo
decorrido desde o início da transmissão de uma mensagem por uma estação de origem até
o momento em que a mensagem chega à estação de destino. Por fim retardo de
transferência eqüivale à soma dos retardos de acesso e de transmissão.
O retardo de transferência é, na maioria dos casos, uma variável aleatória, porém em
algumas redes o seu valor pode ser calculado, ou melhor, ele é determinístico. A rede deve
ser adequada ao tipo particular de aplicação para o qual ela foi concebida. Por exemplo, para
aplicações de controle em tempo real, o retardo de transferência limitado é de vital
importância.
3.3. Desempenho
Pode-se definir como desempenho a capacidade efetiva de transmissão da rede. Por

exemplo as redes locais de alta velocidade (High-Speed Local Networks - HSLN) são
projetadas de forma a fornecer um alto desempenho na comunicação entre dispositivos,
embora o custo de conexões seja mais elevado.
Na verdade os termos velocidade, desempenho e retardo de transferência estão
intimamente relacionados. A escolha de um mecanismo de interconexão orientado para a
natureza das aplicações é essencial para o bom desempenho de uma rede.
— 4.2 —
3.4. Confiabilidade
Confiabilidade pode ser avaliada em termos de tempo médio entre falhas (Medium
Time Between Failures - MTBF), tolerância a falhas, degradação amena, tempo de
reconfiguração após falhas e tempo médio de reparo (Medium Time to Repair - MTTR). O
MTBF é geralmente medido em horas.
A degradação amena está ligada à aplicação e mede a capacidade da rede continuar
operando em presença de falhas, embora com desempenho menor. Reconfiguração após
falhas requer que alternativas redundantes sejam acionadas tão logo uma falha ocorra. O
tempo médio de reparo pode ser diminuído com o auxílio de redundância, mecanismos de
autoteste e diagnóstico, e manutenção eficiente.
3.5. Modularidade
Modularidade pode ser caracterizada como o grau de alteração de desempenho e

funcionalidade que uma rede pode sofrer sem mudar seu projeto original. Os maiores
benefícios de uma arquitetura modular incluem a facilidade para modificação, facilidade para
crescimento e facilidade para o uso de um conjunto de componentes básicos. A
modularidade está intimamente ligada às aplicações do sistema. Uma rede bem projetada
deve poder se adaptar modularmente às várias aplicações a que é dedicada, como também
prever futuras utilizações.
3.6. Compatibilidade
Também conhecida como interoperabilidade, a compatibilidade pode ser vista como

a capacidade que a rede possui para se ligar a dispositivos de vários fabricantes, a nível de
software ou de hardware. Esta característica é bastante importante e valiosa por dar ao
usuário grande flexibilidade e poder de barganha perante os fabricantes.
3.7. Sensibilidade Tecnológica
Este tópico diz respeito à modularidade. Uma rede deve ter a capacidade de suportar
todas as aplicações para a qual ela foi projetada, mais aquelas que no futuro possam ser
requeridas, incluindo transmissão de vídeo, voz e interconexão com outras redes, por
exemplo.
4. CARACTERÍSTICAS DAS REDES LOCAIS
Geralmente uma rede local serve a uma área geograficamente limitada, isto é, um
ambiente de trabalho, um edifício, um campus universitário, uma fábrica, etc. As distâncias
podem variar de metros até alguns poucos quilômetros e a velocidade de transmissão é da
ordem de milhões de bits por segundo. A maioria dos produtos existentes na área utiliza uma
forma simples de interligação física entre os equipamentos e talvez esta seja uma das
características mais atrativas das redes locais.
Estas características, no entanto, não são suficientes para garantir o sucesso de
uma rede local. Para o usuário final, é muito importante ter um mecanismo de transmissão
de informação eficiente, sem que haja a necessidade de conhecer os detalhes técnicos para
efetuar a ligação com a rede.
Uma rede local pode ser descrita através das seguintes características:
• completamente contida dentro de uma área geográfica limitada;

• equipamentos interconectados porém independentes;
• alto grau de interconexão entre os equipamentos da rede;
• transmissão de informação geralmente na forma digital;
— 4.3 —
• interface com a rede feita através de equipamentos e meios de transmissão

relativamente baratos;
• possível comunicação entre dois equipamentos quaisquer da rede.
Outros aspectos que não são definidos explicitamente incluem:
• distâncias envolvidas;
• equipamentos envolvidos;
• velocidade de transmissão;
• topologia da rede;
• meio físico utilizado;
• protocolos e métodos de acesso usados;
• existência ou não de um nó controlador.
A escolha de um tipo de rede para suporte a um dado conjunto de aplicações é uma

tarefa por vezes difícil. Cada arquitetura de rede possui características que afetam sua
adequação a uma aplicação em particular. Muitos podem ser os atributos que fazem parte
do rol possível de ser considerado para comparação. Dentre eles estão: custo, tempo de
resposta, velocidade, desempenho, confiabilidade, modularidade, compatibilidade, e
facilidade de adaptação na mudança de tecnologia.
5. HISTÓRICO
As redes locais surgiram inicialmente em centros de pesquisa e universidades. Elas

constituem uma parte da evolução da pesquisa em redes de transmissão de dados em geral
e da tecnologia de comutação de pacotes em particular.
Uma das primeiras redes desenvolvidas usando as técnicas que agora são
associadas às redes locais foi um sistema de controle de terminais remotos no qual o custo
e a dificuldade de proporcionar enlaces com cabos normais foi proibitivamente alto. Tal
sistema, conhecido como rede ALOHA no Hawai, tinha como objetivo interligar um grande
número de terminais a um computador central. A característica principal do sistema ALOHA
é o uso de um canal de rádio difusão por todos os usuários. Na rede ALOHA, cada terminal
de usuário compete com os outros pela utilização do canal de rádio.
Uma das primeiras redes locais desenvolvidas foi o Distributed Computing System
(DCS) da Universidade da Califórnia em 1971/72. O DCS consiste em um conjunto de
microcomputadores conectados através de um anel por onde fluem, à velocidade de 3,5
Mbps (megabits por segundo), as mensagens trocadas entre processos residentes nos
diferentes computadores. O objetivo do projeto foi construir um sistema distribuído em
termos de hardware, software e controle.
Nos anos seguintes, diversos projetos de redes locais estavam em andamento. Um
dos mais importantes foi a rede Ethernet, desenvolvida conjuntamente pela Xerox, Intel e
Digital. Esta rede tinha como objetivos ser um sistema de comunicação de baixo custo para
interligar minis e micros e ter o controle distribuído. A Ethernet é hoje um dos sistemas de
rede local mais vendidos no mundo. O padrão Token Ring, definido pela IBM, também tem
sua parcela de mercado atualmente.
6. DEFINIÇÕES BÁSICAS
Podemos dizer que atualmente uma redes local (LAN - Local Area Network) é,
basicamente, um grupo de PCs (desktops) ou estações de trabalho interligados a
servidores. Os usuários de uma LAN executam suas tarefas a partir de seus PCs. Estas
tarefas normalmente são edição de texto, planilhas eletrônicas ou aplicações gráfica e o
acesso a aplicações disponíveis nos servidores.
Os módulos mais importantes de uma LAN são:
— 4.4 —
• servidores;
• estações de trabalho;
• recursos de comunicação.
Um servidor é um computador com elevada capacidade de processamento, cuja

função é disponibilizar serviços à rede. Em geral esta máquina processa grandes volumes de
dados, requerendo CPUs rápidas e dispositivos de armazenamento de alta capacidade e
rápido acesso. Alguns dos servidores mais utilizados são:
• servidor de aplicação;
• servidor de arquivos;
• servidor de impressora;
• servidor de rede;
• servidor de banco de dados.
Atualmente o hardware servidor é composto por um PC-Pentium mono ou

multiprocessado, ou então máquinas RISC de fabricantes como HP, Sun, Digital ou IBM. O
sistema operacional do servidor pode ser enquadrado como Sistema Operacional de Rede
(SOR). Os SOR mais adotados pelo mercado são:
• Netware 4.1 (Novel Inc.);

• Windows NT Server (Microsoft Corp);
• LAN Server 4.0 (IBM);
• Unix (IBM, Sun, HP, SCO e outras);
• Banyan ENS 6.0 (Banyan-Vines).
Os SOR são fundamentais na definição de uma rede local. Um estudo criterioso deve
ser realizado visando a escolha do SOR mais adequado às necessidades de uma LAN. Este
estudo deve levar em consideração diversos aspectos tais como: quantidade de PCs,
aplicações envolvidas, necessidade de interfaces com outros SOR e com os sistemas
operacionais dos próprios PCs, aderência a padrões, desempenho, etc.
Através dos PCs e das estações de trabalho os usuários acessam arquivos e
aplicações no servidor e executam tarefas locais. Conforme veremos posteriormente, as
aplicações Cliente/Servidor são compartilhadas, ou seja, uma parte é executada no módulo
Cliente e outra parte no módulo Servidor
Os desktops mais populares consistem de um PC 486 ou Pentium, com MS-
Windows (3.11 ou 95). Existem outras boas opções como OS/2 e o Windows NT Client.
Os recursos de comunicação constituem a definição da infra-estrutura de hardware e
de software necessária para a comunicação entre os diversos componentes de uma LAN.
Os recursos mais comuns são os hubs, as placas de rede, repetidores (repeaters), pontes
(bridges), roteadores (routers), cabeamento, etc.
A comunicação entre os elementos da rede deve ser o mais transparente possível,
permitindo que as aplicações sejam independentes da plataforma de comunicação adotada.
7. O RM-OSI E AS REDES LOCAIS
Redes locais possuem características que afetam principalmente os níveis mais

baixos de protocolo. Esses níveis não devem deixar de levar em consideração o elevado
desempenho, o baixo retardo, a baixa taxa de erros, o roteamento simples (em geral único) e
as aplicações a que se destinam as redes locais.
O RM-OSI, embora teoricamente, pode ser utilizado tanto em redes geograficamente
distribuídas como para redes locais. No entanto ele foi pensado para uso em redes
— 4.5 —
geograficamente distribuídas. Sua aplicabilidade em redes locais não pode deixar de levar
em consideração as características intrínsecas destas redes.
As distâncias limitadas a que são destinadas as redes locais permitem que seu
protocolo de nível físico possa utilizar um meio de alta velocidade com baixíssimas taxas de
erros. Este fato vai influenciar em muito os outros níveis de protocolo.
Várias diferenças existem na camada de enlace de dados, a começar pela
delimitação dos quadros. Ao contrário das redes de longa distância, nas redes locais o
método mais apropriado para delimitação de quadro pode ser a simples presença ou
ausência de sinal no meio.
Devido ao alto desempenho do meio de transmissão e sua baixa taxa de erros, não
cabe ao nível de enlace utilizar muitos bits de redundância para a recuperação de erros. Mais
ainda, se levarmos em consideração que para determinadas aplicações os requisitos de
tempo real são bem mais importantes do que sua confiabilidade exagerada da transmissão.
Muitas vezes nem a recuperação de erros por retransmissão é desejável neste nível. Ao
nível de enlace caberia apenas um esforço máximo para entregar pacotes de nível 3 sem
erros, mas não a sua recuperação caso esse serviços ocorram.
Em redes locais as regras que disciplinam o acesso ao meio físico para transmissão
de dados são chamadas protocolos de acesso. Como exemplo pode-se citar as regras para
controle de acesso ao barramento compartilhado. Nas redes locais a transmissão de dados
é feita por difusão ou possuem roteamento único. Neste sentido os protocolos de ligação
poderiam estar no nível 2 do RM-OSI, uma vez que tratam do envio do pacote de uma
máquina para outra, mas igualmente poderiam ser colocados no nível de rede uma vez que
se trata do envio de um pacote da estação de origem até a estação de destino, isto é, fim-a-
fim. Existem também proposta que os colocam no nível físico, uma vez que determinam a
ligação física ao meio. O comitê de padronização de redes locais, o IEEE 802, os coloca
como parte do nível 2.
Como nas redes locais a transmissão de dados é feita por difusão ou possuem
roteamento único o nível de rede não tem aqui grande relevância. Em muitas redes o nível de
transporte vai ser construído imediatamente acima do nível de enlace. Opcionalmente
devemos permitir que o nível de transporte seja construído acima do nível inter-redes.
O nível 3 em redes locais teria então como função o roteamento de pacotes entre
estação origem e destino em redes diferentes ou na interconexão de redes locais entre si.
Neste nível ainda o mais adequada a utilização de datagrama não confiável, deixando para
os níveis superiores a recuperação, se necessária, dos erros. A arquitetura Internet TCP/IP,
que utiliza essa abordagem, é uma alternativa bastante utilizada para interligação de redes
locais de computadores.
Em redes locais o nível de transporte, ao tornar transparente para os níveis
superiores toda a parte de transmissão, pode ainda tirar vantagem que o meio lhe oferece,
como por exemplo, a confirmação de vários circuitos virtuais em uma única mensagem em
uma rede do tipo difusão.
A implementação dos demais níveis de protocolo depende muito das aplicações da
rede. O RM-OSI pode ser seguido na íntegra, podendo suas funções serem realizadas por
processos de um sistema operacional distribuído, onde a interface do nível 4 seria vista
simplesmente como primitivas de comunicação do núcleo desse mesmo sistema
operacional.
8. OS SISTEMAS OPERACIONAIS DE REDE
Os sistemas operacionais de rede (SOR) utilizados em redes locais, são uma

extensão dos sistemas operacionais locais dos computadores interconectados,
complementando-os com um conjunto de funções básicas, e de uso geral, necessárias à
operação das estações, de forma a tornar transparente o uso dos recursos compartilhados.
A interface entre as aplicações e o sistema operacional baseia-se, usualmente, em
interações do tipo solicitação/resposta. No modo de interação cliente-servidor a entidade
— 4.6 —
que solicita um serviço é chamada “cliente” e a que presta o serviço é o “servidor”. Nas
estações que funcionam como clientes, o SOR, ao receber uma solicitação de um recurso
localizado remotamente, monta uma mensagem de pedido e envia ao módulo servidor da
estação onde será executado o serviço. Na estação remota, o SOR recebe a mensagem,
providencia a execução do serviço solicitado, monta uma ou mais mensagens com o
resultado da execução e as envia de volta para o SOR na estação requerente. Quando o
SOR na estação que requisitou o serviço recebe a mensagem de resposta, ele faz a entrega
à aplicação local. Nota-se que as funções do SOR nos módulos cliente e servidor são
bastante diferentes. Resumindo, podemos classificar os módulos de um SOR instalados
nas estações em dois tipos:
• SORC: módulo cliente do sistema operacional;

• SORS: módulo servidor do sistema operacional.
Na arquitetura de redes Peer-to-Peer, em todas as estações as estações o SOR

possui os dois módulos SORC e SORS. Na arquitetura de redes Cliente-Servidor, as
estações da rede dividem-se em estações clientes, que só possuem as funções do módulo
cliente acopladas ao seu sistema operacional local, e em estações servidoras. As estações
servidoras possuem necessariamente as funções do módulo servidor e podem,
opcionalmente, possuir também as funções do módulo cliente.
A arquitetura cliente-servidor possui duas variações, definidas pela forma como são
utilizados os servidores:
• arquitetura cliente-servidor com servidor dedicado;
• arquitetura cliente-servidor com servidor não dedicado.
A diferença básica entre elas é a disponibilidade ou não da estação servidora para

utilização por usuários locais. Estações servidoras, ou mais comumente chamadas de
servidores, possuem software de suporte a determinados serviços e, por vezes, algum
hardware especial.
9. O PADRÃO IEEE802
O projeto IEEE 802 teve origem na Sociedade de Computação do Instituto de

Engenheiros Eletricistas e Eletrônicos dos EUA, ou IEEE Computer Society. O comitê 802
publicou um conjunto de padrões que foram adotados como padrões nacionais americanos
pelo American National Standards Institute (ANSI). Estes padrões foram posteriormente
revisados e republicados como padrões internacionais pela ISO com a designação ISO
8802.
O objetivo foi o estabelecido de uma arquitetura padrão, orientada para o
desenvolvimento de redes locais, que apresentasse as seguintes características:
• correspondência máxima com o RM-OSI;

• interconexão eficiente de equipamentos a um custo moderado;
• implantação da arquitetura a custo moderado.
A estratégia adotada na elaboração da arquitetura IEEE 802 é a de definir mais de um

padrão de forma a atender aos requisitos dos sistemas usuários da rede. Na verdade, a
arquitetura IEEE 802 pode ser vista como uma adaptação das duas camadas inferiores da
arquitetura RM-OSI da ISO. Nesta arquitetura existem 3 camadas, ou seja, uma equivalente à
camada física e duas sub-camadas que juntas equivalem a camada de enlace. Elas são
assim denominadas:
• camada física (PHY);
• sub-camada de controle de acesso ao meio (MAC);
• sub-camada de controle de enlace lógico (LLC).
— 4.7 —
Para atender o modelo elaborado devemos observar que as funções de comunicação

mínimas e essenciais de uma rede local, equivalentes aos níveis inferiores do RM-OSI,
podem ser assim definidas:
• fornecer um ou mais SAPs (pontos de acesso ao serviço) para os usuários da
rede;
• na transmissão, montar os dados a serem transmitidos em quadros com campos
de endereço e detecção de erros;
• na recepção, desmontar os quadros, efetuando o reconhecimento de endereço e
detecção de erros;
• gerenciar a comunicação no enlace.
Estas quatro funções são fornecidas pelo nível de enlace do RM-OSI. A primeira
função, as sub-funções a ela relacionadas, são agrupadas pelo IEEE 802 na camada Logical
Link Control (LLC). As três restantes são tratadas em uma camada separada, chamada
Medium Access Control (MAC), que podem, então ser otimizadas para as diferentes
topologias de redes locais, mantendo uma interface única, a camada LLC, para os usuários
da rede local.
Em um nível físico mais baixo estão as funções normalmente associadas ao nível
físico: codificação/decodificação de sinais, geração e remoção de preâmbulos para
sincronização e transmissão/recepção de bits. Como no RM-OSI, essas funções foram
atribuídas ao nível físico no modelo de referência elaborado pelo IEEE 802.
A figura 4.1 apresenta a relação entre alguns dos principais padrões IEEE 802 e o
RM-OSI. É importante ressaltar que já existem outros padrões IEEE 802.X, que já foram ou
serão aqui citados, tais como IEEE 802.11 (FDDI) e IEEE 802.12 (100VGAnyLAN).
O padrão IEEE 802.1 é um documento que descreve o relacionamento entre os
diversos padrões IEEE 802 e o relacionamento deles com o modelo de referência OSI. Este
documento contém também padrões para gerenciamento da rede e informações para
ligação inter-redes. O padrão ANSI/IEEE 802.2 (ISO 8802/2) descreve a sub-camada
superior do nível de enlace, que utiliza o protocolo Logical Link Control Protocol. Os outros
padrões que aparecem na figura 4.1 especificam diferentes opções de nível físico e
protocolos da sub-camada MAC para diferentes tecnologias de redes locais. São eles:
• padrão IEEE 802.3 (ISO 8802/3), rede em barra utilizando CSMA/CD como
método de acesso;
• padrão IEEE 802.4 (ISO 8802/4), rede em barra utilizando passagem de
permissão como método de acesso;
OSI IEEE
802.1
LLC 802.2
ENLACE
MAC
FÍSICO 802.3 802.4 802.5 802.6
Figura 4.1 - Relação entre os padrões IEEE 802 e RM-OSI
— 4.8 —
• padrão IEEE 802.5 (ISO 8802/5), rede em anel utilizando passagem de permissão
como método de acesso;
• padrão IEEE 802.6 (ISO 8802/6), rede em barra utilizando o Distributed Queue
Dual Bus (DQDB) como método de acesso.
O padrão IEEE 802.4, denominado Token Bus, é o padrão para redes em barra com
sinalização em banda larga utilizando a passagem de permissão como método de acesso
ao meio de transmissão. Ele define o método de acesso passagem de permissão sobre
uma topologia física barramento, simulando um anel lógico. Este padrão não é muito
conhecido, porém ele oferece a opção de um método de acesso determinístico sobre uma
topologia em barramento.
O padrão IEEE 802.6, denominado DQDB, é o padrão para redes metropolitanas
(MANs - Metropolitan Area Network). Segundo a definição do grupo IEEE 802.6, o propósito
de uma rede metropolitana é prover serviços integrados, tais como texto, voz e vídeo, em
uma grande área geográfica. DQDB é uma sub-rede que pode ser usada como uma parte
componente de uma MAN. Tipicamente uma MAN consiste em sub-redes DQDB
interconectadas.
Nos capítulos posteriores serão feitas discussões detalhadas sobre os padrões IEEE
802.3 e IEEE 802.5, que são os mais utilizadas em redes locais. A seguir serão descritas,
resumidamente, as principais funções de cada uma das camadas do padrão IEEE 802.
9.1. Camada Física
Esta camada tem como função prover os serviços básicos de transmissão e

recepção de bits através de conexões física. Assim, ela define as características elétricas
(níveis de tensão, impedância, etc.), as características mecânicas (tipo de conectores,
dimensões do suporte físico de transmissão, etc.) e as características funcionais e de
procedimentos (tempo de duração de bit ou velocidade de transferência de bits, inicialização
das funções de transmissão e recepção de bits, etc.) das conexões físicas.
9.2. Sub-camada de Controle de Acesso ao Meio
A sub-camada de Controle de Acesso ao Meio (MAC) especifica os mecanismos que

permitem gerenciar a comunicação a nível de enlace de dados. Em particular, a sub-camada
MAC fornece os serviços que permitem disciplinar o compartilhamento de um meio de
transmissão comum aos sistemas usuários da rede. As unidades de transferência de
informação ao nível da sub-camada MAC correspondem aos quadros MAC .
A existência da sub-camada MAC na arquitetura IEEE 802 reflete uma característica
própria das redes locais, que é a necessidade de gerenciar enlaces de dados com origens e
destinatários múltiplos num mesmo meio físico de transmissão, como no caso das
topologias em anel e barramento. Além disso, a existência da sub-camada MAC permite o
desenvolvimento da sub-camada superior (LLC) com um certo grau de independência da
camada física, no que diz respeito à topologia e ao meio de transmissão propriamente dito.
Por outro lado, a própria sub-camada MAC é bastante sensível a esses elementos.
Os mecanismos de controle de acesso distribuído apresentam uma forte
dependência quanto à topologia da sub-rede de comunicação. Um resultado das diferentes
características topológicas é a existência de técnicas de controle de acesso exclusivas a
uma determinada topologia. Alguns mecanismos de acesso podem ser implementados em
topologias diferentes (barramento e anel) mas esta não é a regra geral.
9.3. Sub-camada de Controle de Enlace Lógico
A sub-camada de Controle de Enlace Lógico (LLC) é a camada da arquitetura IEEE

802 que se encarrega de prover às camadas superiores os serviços que permitem uma
comunicação confiável de seqüência de bits (quadros) entre os sistemas usuários da rede. A
— 4.9 —
especificação da sub-camada LLC prevê a existência de três tipos de serviços básicos,

fornecidos à camada superior.
Um primeiro serviço oferecido pela sub-camada LLC permite que as unidades de
informação sejam trocadas sem o estabelecimento prévio de uma conexão a nível de enlace
de dados. Neste tipo de serviço não há, portanto, nem controle para recuperação de erros ou
anomalias, nem controle da cadência de transferência das unidades de dados (controle de
fluxo). É suposto que as camadas superiores possuam tais mecanismos de modo a tornar
desnecessária sua duplicação nas camadas inferiores.
Um segundo serviço fornecido pela sub-camada LLC consiste no estabelecimento de
uma conexão a nível de enlace de dados, antes da fase de troca de dados propriamente dita,
de modo a incorporar as funções de recuperação de erros, de seqüenciamento e de controle
de fluxo.
O terceiro refere-se a um serviço sem conexão com reconhecimento utilizado em
aplicações que necessitam de segurança mas não suportam o overhead de
estabelecimento de conexão.
10. ETHERNET E IEEE 802.3
Este capítulo tem por objetivo mostrar o padrão IEEE 802.3 e o principal produto que
segue este padrão, a Ethernet. Este é um esquema que está no mercado desde os anos 70
e continua sendo um padrão respeitado até hoje. O produto Ethernet foi desenvolvida
conjuntamente pelas empresas Xerox, Intel e Digital. O método de acesso ao meio de
transmissão utilizado neste padrão é o CSMA/CD. Este método será descrito a seguir.
10.1. CSMA/CD
A técnica CSMA/CD (Carrier Sense Multiple Access with Collision Detection) foi
baseada na rede ALOHA no Hawai, que iniciou sua operação em 1970, e que consistia de
uma forma de comunicação de um computador central e seus terminais espalhados pelas
várias ilhas do arquipélago. Eram utilizadas duas freqüências de rádio: uma para difusão de
mensagens do computador central para os terminais e outra para mensagens dos terminais
para o computador. Uma vez que existe apenas um transmissor no primeiro canal, nenhuma
dificuldade é encontrada. O problema aparece no segundo canal, onde todos os terminais
transmitem em uma mesma freqüência. Esta situação é a mesma encontrada em uma rede
com topologia em barramento.
Uma rede com topologia em barramento apresenta as seguintes características:
canal de transmissão eletricamente aberto, transmissão por difusão (nos dois sentidos) e
estações de acesso passivas. Uma vez que o barramento é um canal de transmissão
aberto, não existe a necessidade de se prover mecanismos para a retirada das mensagens
transmitidas, o esvaziamento do meio é feito naturalmente. Isto dificulta a implantação de um
serviço de resposta automática, mas as características inerentes a esta topologia permitem
a implantação de técnicas de controle de acesso com funções totalmente distribuídas.
Uma rede em barramento é comumente chamada de rede em difusão. Um sistema
de difusão é aquele no qual uma mensagem transmitida no meio é ouvida, mais ou menos
simultaneamente, por todos os nós de comunicação ligados à rede. No método CSMA/CD,
uma estação só transmite sua mensagem após “escutar” o meio de transmissão e
determinar que o mesmo não está sendo utilizado. Qualquer nó de comunicação pode ouvir
qualquer mensagem transmitida, não importando se o destinatário é ele, outro nó, ou ambos.
Caso a estação detecte o meio ocupado, ela deve aguardar até que o sinal desapareça para
então iniciar a sua transmissão. Pode ocorrer que duas ou mais estações estejam
aguardando que o meio fique desocupado e ao detectarem silêncio ambos transmitam suas
mensagens. Isto ocasionará uma “colisão” de mensagens das estações ao transmitirem
simultaneamente. Existe, então, a necessidade de se estabelecer uma política de
compartilhamento deste meio de transmissão entre as várias estações que estão utilizando
o barramento.
— 4.10 —
Quando duas mensagens são transmitidas ao mesmo tempo, diz-se que elas
colidiram e o resultado é que as informações de ambas são corrompidas ou perdidas. Os
métodos de acesso para redes com topologia em barramento devem, portanto, atender
situações como: evitar o máximo possível a ocorrência de colisões e no caso de ocorrência
de colisão, as mensagens perdidas ou danificadas devem ser identificadas para posterior
retransmissão. Uma vez que duas ou mais estações tenham transmitido simultaneamente
ocasionando colisão de mensagens, um esquema de prioridade deve ser providenciado para
evitar que ocorram novas colisões envolvendo as mesmas estações.
A maneira de se evitar que a colisão só seja percebida quando uma resposta não for
recebida, é “escutar” o meio de transmissão antes (carrier sense) e durante (collision
detection) a transmissão da mensagem. Desta forma, a estação emissora poderá identificar
se existe outro sinal misturado com o seu e, uma vez detectada a colisão, todas as estações
envolvidas param de transmitir e tentam transmitir outra vez após um tempo de espera. Uma
vez que a janela de transmissão é relativamente curta, o tempo perdido na transmissão é
muito pequeno quando comparado com o tamanho médio das mensagens transmitidas.
Para evitar que as mesmas mensagens colidam novamente, o tempo que cada
estação aguarda para transmitir novamente é calculado de forma randômica o que não evita
que a mensagem desta estação colida com a mensagem de uma outra. Neste caso, o
procedimento se repete, mas o tempo de espera para uma nova tentativa é maior que o
anterior, penalizando a estação que colide muitas vezes. Após um número específico de
tentativas sem sucesso, a estação envia uma mensagem ao seu usuário indicando a
impossibilidade de efetuar o serviço solicitado. À medida que a carga da rede cresce, cada
equipamento tem a sua taxa de transmissão reduzida, desta forma, com a redução total da
carga da rede, as transmissões vão se ajustando gradativamente.
Em relação a definição do tamanho mínimo e máximo dos quadros MAC, várias
considerações podem ser feitas. Quanto maior o tamanho do quadro maior será a eficiência
na utilização do canal, por outro lado se ele for muito pequeno, para haver detecção de
colisão, as mensagens devem ter um tamanho mínimo pré-estabelecido, uma vez que o
tempo de propagação é finito. Existem outros fatores que tendem a limitar o tamanho do
quadro que incluem a limitação do tamanho dos buffers de recepção e transmissão dos
quadros e a necessidade de diminuir o retardo de transferência.
Este método de acesso foi um dos escolhidos como padrão, e é de fato o método
mais difundido em redes locais. Na prática, o método CSMA/CD é muito eficiente,
apresentando uma ocupação do meio acima de 90%. O resultado é que o CSMA/CD tem
sido escolhido para a maioria dos projetos de redes locais. O principal exemplo de utilização
do CSMA/CD é dado pela rede Ethernet que é uma rede local comercializada pela Xerox e
utilizada como base para muitos de seus produtos.
10.2. O padrão IEEE 802.3
O padrão IEEE 802.3 (ISO 8802/3) foi projetado para redes em barra utilizando
CSMA/CD como método de acesso. O padrão provê a especificação necessária para redes
em banda básica operando em 1 a 10 Mbps, e para redes em banda larga operando a 10
Mbps.
Ao tratar de redes em banda básica a 10 Mbps, o padrão converge para a
especificação da rede Ethernet. Nesta etapa serão detalhadas a sintaxe e a semântica do
protocolo de controle de acesso ao meio.
A figura 4.2 apresenta o formato do quadro MAC. O campo de preâmbulo possui sete
octetos usados para sincronização do transmissor e receptor. Cada octeto é formado pela
seqüência 10101010. O campo delimitador de início de quadro, SFD (Start Frame Delimiter),
é composto da seqüência 10101011 e indica o início de um quadro.
Para que as unidades de dados sejam adequadamente transmitidas e recebidas,
cada estação conectada à rede deve possuir um endereço que o identifique de modo único.
De um modo ainda mais geral, quando duas ou mais redes são interconectadas, deve-se
— 4.11 —
garantir que os endereços dos dispositivos continuem identificando-os univocamente. Para

atender a esses requisitos, o projeto IEEE 802 permite que sejam utilizadas duas formas de
endereçamento.
Na primeira delas é responsabilidade da organização que instala a rede atribuir
endereços aos dispositivos nela conectados. Os endereços podem ter 16 ou 48 bits de
comprimento. Os endereços manipulados dessa forma são denominados localmente
administrados. A segunda forma de endereçamento utiliza endereços de 48 bits e um
esquema de endereçamento universal. Neste esquema, blocos de endereços distintos são
distribuídos aos fabricantes que responsabilizam-se pela atribuição de endereços aos
produtos que fabricam. Esse esquema garante que não haja duplicação de endereços,
mesmo quando redes distintas são interligadas. O uso do esquema universal simplifica o
gerenciamento porém aumenta o overhead da transmissão. Os fornecedores de produtos de
rede devem decidir se usarão uma ou ambas as formas, cabe aos usuários a escolha da
forma que irão utilizar em suas redes.
Os campos de endereço especificam o(s) endereço(s) de destino do quadro e o
endereço da estação que originou o quadro, respectivamente. Cada campo de endereço
contém 16 ou 48 bits, como já mencionado. No entanto, devem ter o mesmo comprimento
para todas as estações em uma rede particular. O primeiro bit do campo de endereço de
destino identifica o endereço como sendo individual (bit = 0) ou de grupo (bit = 1).O endereço
de grupo com todos os outros bits restantes iguais a 1 é reservado para o grupo a que todas
as estações pertencem, ou endereço de difusão. Um quadro enviado com endereço de
difusão deve ser copiado por todas as estações. Qualquer outro grupo que não o de difusão
deve ser definido por regras em níveis mais altos de protocolo. Para endereços de 48 bits, o
segundo bit é usado para distinguir os endereços administrados localmente (bit = 1) dos
administrados globalmente (bit = 0), isto é, endereços universais.
O campo de comprimento possui dois octetos cujo valor indica o número de octetos
de dados da camada LLC. O campo de dados da camada MAC contém uma seqüência de n
octetos, n menor que o número máximo especificado na implementação particular.
Conforme já mencionado, um tamanho mínimo de quadro é requerido para o funcionamento
correto do método CSMA/CD. Assim, se necessário, o campo de dados deve ser estendido
com a incorporação de bits extras (o campo PAD) antes do campo FCS.
O campo FCS (Frame Check Sequence) contém um verificador de redundância
cíclica (CRC - Cyclic Redundancy Check) de quatro octetos, cujo valor é computado a partir
do campo de endereço de destino, inclusive, tomando como base o polinômio gerador:
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x +1
56 bits 8 bits 16 ou 48 bits 16 ou 48 bits 16 bits 368 bits - 12 Kbits 32 bits

preâmbulo SFD destinatário remetente comprimento dados LLC PAD FCS
Figura 4.2 - Formato do quadro MAC 802.3
11. A REDE LOCAL ETHERNET
A rede local Ethernet foi otimizada para troca de dados a altas velocidades entre
equipamentos processadores de informação dentro de áreas geográficas de tamanho
moderado, permitindo maximizar as comunicações entre uma grande variedade de
equipamentos oriundos de diversos fabricantes. A implementação desta rede seguiu as
seguintes especificações: os dois níveis mais baixos das camadas do RM-OSI, ou seja, as
camadas física e de enlace de dados, bem como as interfaces entre eles; a interface entre a
camada de enlace de dados e as camadas de níveis mais altos da arquitetura do sistema; e
duas interfaces na camada física que permitem a compatibilidade entre equipamentos
utilizados em diferentes implementações da Ethernet.
— 4.12 —
A camada física da Ethernet proporciona 10 Mbps em um canal cujo meio de

transmissão é o cabo coaxial ou o par trançado. Esta especifica todas as características
essenciais da Ethernet, tais como: codificação, temporização, níveis de voltagem e
interfaces de compatibilidade. Executa também a recepção dos bits de preâmbulo para
sincronismo dos quadros.
A transmissão de uma mensagem é iniciada por uma requisição das camadas mais
altas da estação. A estação deve passar os dados, endereço de origem e destino, e tipo de
formato dos dados para o buffer de armazenamento da camada de enlace de dados, através
de respectiva interface. A camada de enlace de dados LLC constrói um quadro, colocando
cada componente da informação em seu respectivo campo e então anexa uma seqüência
de checagem de quadro para detecção de erro na transmissão. Antes de transmitir um
quadro, a camada de enlace de dados tenta evitar colisão avaliando o tráfego do canal pela
monitoração do sinal de portadora da camada física. Neste exato instante a camada física
está apta para detectar a presença de portadora ou não, nesse caso definida como um sinal
elétrico em banda base que está presente no cabo coaxial quando temos um quadro sendo
transmitido. A camada física sinaliza para a camada de enlace de dados quando há tráfego
detectado no canal.
Quando o canal está livre, a camada de enlace de dados passa o quadro a ser
transmitido para a camada física através de um fluxo de bits serial. Porém, antes de enviar
os bits do quadro, a camada física envia um preâmbulo codificado que permite aos
receptores de todos os nós da rede sincronizar seus relógios.
A camada física, então, começa a translação dos bits da mensagem em codificação
de fase Manchester, gerando um sinal elétrico dentro do cabo coaxial, ou do par trançado,
que representa os bits da mensagem. Assim, a camada física do nó transmissor monitora o
canal durante todo o tempo da transmissão, ou seja, monitora o nível de energia (nível do
sinal elétrico) do canal. Ela sabe de antemão qual é o nível ideal de energia de um canal
durante a transmissão. Se acontecer uma colisão, teremos mais energia no canal, sendo
logo detectada. Essa detecção de colisão do sinal só pode ser feita por um nó enquanto
encontra-se no estado de transmissão.
Quando a transmissão for completada sem contenção, a camada de enlace de
dados informa às camadas mais altas, aguardando outras requisições de novas
transmissões. Quando um nó começa a transmissão, as camadas físicas de todos os nós
da rede “sentem” o sinal da portadora e alertam suas respectivas camadas de enlace de
dados para que não haja nenhum conflito devido a tentativas de transmissão. Neste ponto,
todos os demais nós da rede se transformam em nós receptores. A camada física de cada
nó receptor sincroniza-se através dos bits do preâmbulo, recebe estes bits já codificados, e
translada a fase codificada do sinal de volta para os dados binários, descartando o
preâmbulo.
O fluxo de bits é passado para a camada de enlace de dados dos nós de destino. O
fluxo de bits é coletado até que o sinal de portadora desapareça, indicando o fim do quadro. A
camada de enlace de dados checa o endereço de destino do quadro, logo que o fluxo de bits
entra para determinar se está endereçado a este nó ou não. Se estiver, a mensagem é
inspecionada para avaliar o alinhamento dos bits e, então é passada para as camadas de
protocolos mais altas com uma indicação de sua condição. Se não, o fluxo de bits para a
camada de enlace de dados é parado logo depois do preâmbulo e do endereço de destino, e
assim, o quadro não é aceito.
É possível que dois ou mais nós possam determinar que o canal esteja livre
simultaneamente, tentando iniciar uma transmissão. Quando isso ocorre, suas
transmissões se sobrepõem, interferindo uma na outra. O resultado denomina-se de colisão.
Um nó pode experimentar uma colisão durante sua “janela de colisão” (intervalo de tempo
antes que o sinal tenha tido tempo de viajar de um extremo a outro da rede, e voltar),
também chamado de slot-time. Uma vez que o tempo da janela de colisão passou, é dito que
o nó “obteve o canal”, desde que todos os demais nós detectaram o sinal de portadora neste
intervalo de tempo, desistindo assim da transmissão.
— 4.13 —
O quadro da Ethernet está especificado com um tamanho mínimo de 64 bytes, por

uma razão: o slot-time é aproximadamente o mesmo tempo que leva para transmitir 64
bytes de dados a 10 Mbps sobre a configuração máxima da Ethernet (2,8 Km entre dois nós
comunicantes). Assim, quando um dado nó está transmitindo uma mensagem, um outro nó
que ainda não detectou o sinal de portadora também começa a transmitir irá ocorrer uma
colisão no trajeto. Contudo, o primeiro nó ainda estará transmitindo o mesmo quadro inicial,
pois quando ele sentir que houve uma colisão terá passado um slot-time. Portanto, essa é a
única maneira do nó associar o sinal de colisão com o quadro que está sendo transmitindo.
Poder ocorrer de o nó perceber o sinal de colisão após ter terminado a transmissão
de sua mensagem. Neste caso, ele não associará a colisão com a sua transmissão, não
retransmitindo o quadro. A esta altura, o quadro só poderá ser retransmitindo por uma
requisição das camadas mais altas. Quando ocorre uma colisão durante a transmissão, a
camada física do nó transmissor detecta o sinal de colisão. A camada de enlace de dados
percebe isso e começa com os procedimentos de contenção. Primeiro, o quadro que está
sendo transmitido permanece sua transmissão por um curto intervalo de tempo, denominado
jam, para que a colisão seja percebida pelos demais nós que também estiverem
transmitindo. Então, a camada de enlace de dados suspende a transmissão e planeja uma
tentativa de retransmissão. O período de tempo que um nó espera antes de tentar uma nova
transmissão é um múltiplo do slot-time (esse número é selecionado randomicamente por
cada nó envolvido). Se mais algumas colisões ocorrerem, o nó irá proceder com uma nova
tentativa dentro dos padrões da anterior. Eventualmente, a transmissão é completada com
sucesso, ou a tentativa é abandonada por suposição que o canal está desvanecido ou que
está com problemas de sobrecarga. Nos nós receptores, os bits de uma colisão são
recebidos e decodificados pela camada física como se fossem bits de um quadro, pois o
sinal de detecção de colisão não é reconhecido nos nós receptores. A camada de enlace de
dados pode distinguir entre um quadro recebido fragmentado, como resultado de uma
colisão, e um quadro válido, verificando simplesmente seu tamanho.
As características básicas da rede Ethernet são descritas a seguir. Estes
parâmetros são descritos com o objetivo de analisar algumas características consideradas
relevantes, sem ser exaustivo no assunto.
11.1. Velocidade de Transmissão
A Ethernet é considerada como uma rede local que apresenta alta velocidade de
transmissão de sinais de dados, devido a combinação de mecanismo de controle de acesso
CSMA/CD (proporcionando acesso distribuído a todos os nós), sinalização em banda de
base e cabo coaxial de alta performance. Pode-se conectar até 1.024 nós na Ethernet,
garantindo uma taxa de transferência de 10 Mbps, sendo que todos os nós apresentam
oportunidades iguais de enviar seus quadros, desde que o canal esteja livre. Uma das
principais características se traduz na difusão das mensagens sobre o meio físico de
transmissão, dando oportunidade de todos os nós ouvirem as mensagens.
11.2. Desempenho
A Ethernet não apresenta nenhuma instabilidade quando submetida a cargas

pesadas. Mesmo nas horas de maior movimento, o mecanismo de acesso CSMA/CD
proporciona capacidade plena distribuída aos nós.
11.3. Qualidade
Existem certas implementações que controlam o funcionamento da rede, tornando-a

mais segura:
• falhas no cabo de transmissão podem ser localizadas através de um temporizador que é
acionado quando um quadro é transmitido; e o tempo de cada colisão é anotado; se o
defeito for no cabo, o tempo de colisão será constante, sendo assim possível localizar-se
— 4.14 —
o ponto que apresenta defeito através de uma relação tempo/velocidade, associadas a

fórmulas específicas;
• os nós e componentes defeituosos podem ser prevenidos para se auto-desligarem da
rede em caso de suas transmissões ultrapassarem o tamanho permitido pela Ethernet;
• tem-se uma controladora monitorando continuamente os aspectos operacionais da rede;
por exemplo, após cada transmissão o circuito sensor de colisão é testado.
11.4. Custo
Os equipamentos da rede Ethernet apresentam um custo relativamente baixo em

comparação com o que a rede pode proporcionar: compatibilidade de recursos; flexibilidade
de instalação em vários tipos de lugares quer seja num edifício, num campus, num
complexo industrial, etc; grande capacidade de incorporação de novos nós no sistema sem
com isso perturbar o funcionamento da rede; e, simplicidade em sua configuração e na
conexão, uma vez que os cabos podem correr dentro das paredes ou sobre o teto.
12. CONFIGURAÇÃO DA ETHERNET
A configuração completa depende principalmente de tipo de cabo sendo utilizado. A

tabela 4.1 define algumas características destas configurações.
Tabela 4.1 - Configurações Ethernet

Parâmetro 10Base-T 10Base-2 10Base-5
Tipo de cabo par trançado não cabo coaxial fino cabo coaxial grosso
blindado
Topologia estrela (hub) barramento barramento
Conector utilizado RJ-45 conector T + tranceiver + cabo +

BNC DB-15
Comprimento máximo do cabo 100 m 185 m 500 m
Comprimento máximo da rede 2500 m (usando um 925 m 2500m

backbone coaxial)
Número de nós por segmento 1 30 100
Distância mínima entre dois nós não há 0,5 m 2,5 m
Técnica de sinalização banda base com codificação Manchester
Velocidade 10 Mbps
13. FAST ETHERNET
As redes Fast Ethernet representam uma evolução das redes Ethernet no que tange à
taxa de transmissão, sendo padronizada através das normas IEEE 802.3u. O quadro Fast
Ethernet é o próprio quadro Ethernet.
São especificadas três configurações físicas diferentes para as redes Fast Ethernet,
correspondentes aos padrões 100BaseTX, 100BaseFX e 100BaseT4. Estas são assim
definidas:
• 100BaseT4: baseia-se na utilização de um hub ao qual estão conectadas
estações através de cabos de par trançado não blindado, com distância máxima
de 100 m da estação até o hub; o clock interno é de 25 MHz;
• 100BaseTX e 100BaseFX: baseiam-se na utilização de um hub ao qual estão
conectadas estações através de cabos de par trançado ou fibra ótica, com
— 4.15 —
distância máxima de 100m (TX) ou 400m (FX) da estação até o hub; o clock
interno é de 125 MHz.
14. TOKEN RING E IEEE 802.5
Esta técnica é adotada com o padrão IEEE 802.5 e na prática constitui-se na principal
opção de implementação do mecanismo de controle de acesso por ficha. A topologia em
anel apresenta as seguintes características físicas: transmissão unidirecional e ponto a
ponto, estações de acesso ativas, isto é, funcionam como repetidoras, e canal de
transmissão fechado. Um mecanismo de controle de acesso para a sub-rede de
comunicação estruturada em anel envolve a definição de procedimentos quanto à inserção
de mensagem no anel, recepção de mensagem e remoção de mensagem do anel.
Este mecanismo é baseado em uma mensagem de controle que, uma vez
inicializada, circula entre todos os nós da rede, transportando o direito de transmissão no
meio compartilhado. O procedimento de inserção de mensagem num anel com acesso
controlado por ficha obedece às seguintes etapas:
• a estação que deseja transmitir aguarda a chegada da ficha;
• uma vez de posse da ficha, a estação transmite a sua mensagem;
• ao final da transmissão, a estação devolve a ficha enviando-a ao próximo nó da
rede.
A restituição da ficha pode ser feita imediatamente após o término da transmissão da

mensagem transmitida. Dependendo das dimensões do anel físico e da velocidade de
transmissão usada, a forma de restituição da ficha pode permitir a existência de várias
mensagens simultaneamente em trânsito no anel, denominada ficha múltipla, o que oferece
um melhor desempenho em situações onde as mensagens são relativamente curtas. Note
que o termo múltipla não se refere ao número de fichas e sim ao número de mensagens
circulando no anel. Por exemplo, no caso em que o tempo de propagação da mensagem no
anel é bem menor que o tempo de transmissão, o fim da transmissão ocorre antes do
retorno do início da mensagem transmitida e, no caso de restituição da ficha ao final da
transmissão, teremos mais de uma mensagem circulando no anel. A estratégia de restituir a
ficha somente após o retorno da mensagem é conhecida como ficha simples e facilita a
implantação de funções de supervisão e controle (recuperação de erros, reconhecimento,
etc). Uma vez que o início da mensagem passa por todos os nós de comunicação antes da
ficha, fica fácil implantar um esquema que avise a todas as estações, previamente, sobre a
prioridade de acesso à ficha a ser restituída.
A remoção da mensagem do anel é tarefa do nó de comunicação que originou a
mensagem. Essa estratégia simplifica a implantação dos serviços baseados na difusão de
mensagens e também dos serviços de controle de erros e reconhecimento. As funções de
gerência e manutenção da ficha podem ser centralizadas ou distribuídas e devem atender
situações tais como a perda ou duplicação da ficha.
Um exemplo de token-ring são as redes locais FDDI (Fiber Distributed Data
Interface), que se constitui de uma rede de alto desempenho que geralmente é utilizada
como backbone para interconectar outras redes locais entre si. As redes FDDI serão vistas
mais adiante neste capítulo.
14.1. O Padrão IEEE 802.5
ANSI/IEEE 802.5 (ISO 8802-5) é o padrão para redes em anel utilizando passagem
de permissão como método de acesso. O padrão provê a especificação necessária para
redes em banda básica operando a 4 ou 16 Mbps, utilizando como meio de transmissão o
par trançado.
O acesso ao meio físico é controlado pela passagem da permissão no anel. No
método ficha simples (single token), depois da transmissão dos quadros, a estação verifica
— 4.16 —
se seu endereço retornou no campo SA. Em caso negativo, a estação transmite 0s e 1s até
que tenha retornado, só então a estação transmite a permissão para o próximo nó. O
protocolo de acesso ao meio permite o uso de prioridades.
Todo quadro transmitido, inclusive a permissão, tem um campo designando a
prioridade corrente(PPP) e outro para a reserva de prioridade (RRR). Uma estação só pode
transmitir um quadro se receber a permissão e se o seu quadro tiver prioridade maior ou
igual à designada no campo PPP da permissão.
Se a estação receber uma permissão com prioridade maior que a necessária para
transmissão de suas mensagens ela faz uma reserva de permissão, através dos bits RRR,
solicitando a diminuição da prioridade. É importante notar que o campo de prioridades é
sempre verificado, em cada estação do anel, sempre no recebimento de uma permissão e
também na passagem de uma mensagem para outro destinatário. O mecanismo de controle
de prioridades é relativamente complexo e pode ser visto em detalhes na bibliografia
recomendada.
De forma a permitir uma maior eficiência na utilização do anel, uma opção multiple
token (chamada early-token-release - ETR) foi adicionada ao padrão IEEE 802.5. Neste
método é permitido que uma estação envie uma permissão livre assim que terminar de
transmitir seus quadros, independente dela ter começado ou não a receber seus quadros de
volta. Estações que implementam o mecanismo ETR são compatíveis com as que não
possuem essa facilidade, podendo operar conjuntamente.
Cada estação da rede possui funções de uma estação monitora de forma a
recuperar o anel de vários tipos de erros tais como perda ou duplicação da permissão,
sincronização no anel, criação da permissão.
A versão atual do padrão IEEE 802.5, especifica como meio de transmissão o par
trançado blindado operando a 4 ou 16 Mbps com no máximo 250 repetidores ligados ao anel;
ou o par trançado comum operando a 4 Mbps com no máximo 250 repetidores ligados ao
anel. Está sendo elaborada pelo IEEE uma revisão deste padrão que inclui o par trançado
sem blindagem operando a 16 Mbps. Essa revisão inclui a definição de dois tipos de
concentradores, um passivo e outro ativo, que permite a ligação de uma grupo de estações
ao meio. A revisão especifica também o uso de um caminho redundante entre
concentradores, através de um anel backup.
A referência do padrão IEEE 802.5 de 1992 define uma rede token ring como sendo
um sistema cuja topologia lógica é em anel e a topologia da fiação é uma estrela. Segundo
esta topologia anel-estrela cada estação é conectada a uma TCU (Trunk Coupling Unit). A
TCU tem como função prover os meios necessários para inserir uma estação no anel, ou
retirá-la, funcionando como um relê de bypass. O concentrador, ponto central da topologia
em estrela da fiação, contém um conjunto de TCUs. Os concentradores são ligados em
série através de portas de entrada e saída, formando os anéis principal e de reserva.
15. CABEAMENTO ESTRUTURADO
Atualmente, é consenso geral que um projeto bem feito do cabeamento em uma rede
é o primeiro passo para garantir a implantação de uma rede com sucesso. A escolha correta
do tipo de cabo para um segmento em um projeto de uma rede local é uma parte vital para o
seu bom funcionamento. Considerando projetos de médio e grande porte, onde várias redes
de diferentes topologias e métodos de acesso convivem interligadas, as opções de
instalação se tornam a parte mais custosa do projeto. Esforços tem surgido no sentido de
organizar e compilar as opções de instalação de forma a fornecer um conjunto básico de
configurações para os tipos de instalações mais comuns. Essas configurações definem o
que comumente tem sido chamado de cabeamento estruturado.
Dentro deste contexto, vários órgãos de padronização, tais como ISO/IEC, EIA/TIA e
IEEE, entre outros, além de algumas empresas privadas, têm se preocupado em
desenvolver padronizações de sistemas de cabeamento estruturado. Estes sistemas
— 4.17 —
apresentam como principais vantagens a alta escalabilidade e disponibilidade, facilidade de

manutenção e mobilização das estações, entre outras.
Os sistemas de cabeamento estruturado são normalmente, organizados segundo
uma estrutura hierárquica, que engloba:
• tomada de comunicação: consiste de um espelho e conectores através dos quais os

equipamentos dos usuários finais são conectados ao sistema de cabeamento de um
prédio;
• quadros de distribuição: correspondem a sistemas a partir dos quais são distribuídas
as tomadas de comunicação para equipamentos de rede ou para outros quadros de
distribuição; os primeiros são denominados quadros de distribuição satélite e os
segundos quadros de distribuição intermediários;
• sistema de distribuição horizontal: corresponde ao sistema de distribuição de
cabeamento usado na conexão entre tomadas de comunicação e os quadros de
distribuição ou entre dois quadros de distribuição, todos existentes em um mesmo andar
de um prédio;
• sistema de distribuição vertical: refere-se ao sistema de distribuição de cabeamento
usado na conexão de um quadro de distribuição predial e os quadros de distribuição
intermediários, localizados em cada andar deste prédio;
• sistema de distribuição de campus: engloba o sistema de cabeamento empregado na
interconexão do quadro de distribuição do campus e os quadros de distribuição de cada
um de seus prédios.
— 4.18 —
Capítulo 5
RE D E S LO C A I S I N D U S T R I A I S
1. INTRODUÇÃO
No capítulo anterior foram apresentados os principais resultados no que diz respeito

as redes locais de computadores. A importância das arquiteturas de comunicação para
redes locais é, sem dúvida, um resultado que trouxe contribuição significativa em todos os
setores de atuação da sociedade, tendo permitido automatizar uma grande quantidade de
processos antes realizados por técnicas tradicionais e ineficazes.
O desenvolvimento das redes locais de computadores não ocorreu apenas na área
da automação de escritório, mas também na automação industrial.
Este capítulo vai apresentar os resultados obtidos nesta área.
2. NÍVEIS HIERÁRQUICOS DA INTEGRAÇÃO FABRIL
A fabricação de produtos ou o fornecimento de um serviço da parte de uma empresa

põe em jogo uma série de atividades e etapas, dedicadas à manutenção e ao aprimoramento
do produto ou do serviço. A implementação destas etapas através de processos com maior
ou menor grau de automatização fica a critério da empresa.
A tendência de informatização crescente das empresas e outras organizações, por
um lado, permite acelerar cada processo fazendo parte das atividades de fabricação de um
produto ou do oferecimento de um serviço e, por outro lado, cria uma nova necessidade no
que diz respeito ao modo como as informações serão trocadas.
As redes locais industriais permitem levar em conta as particularidades de um
processo de fabricação do ponto de vista das necessidades de comunicação, tais como o
compartilhamento de recursos, evolutividade, gerenciamento da heterogeneidade e os
diversos tipos de diálogo podendo ocorrer no ambiente industrial. Ainda, a nível de um
processo de fabricação, certos requisitos tornam-se fundamentais, envolvendo
principalmente os fatores econômicos que o cercam. A garantia de um tempo de resposta
médio ou máximo, o débito de informação, a robustez (confiabilidade dos equipamentos e da
informação), a flexibilidade (evolutividade e heterogeneidade dos equipamentos) são alguns
exemplos destes requisitos.
Nos últimos anos, um esforço considerável tem sido realizado no sentido de definir
arquiteturas de comunicação que respondam às características e aos requisitos
mencionados acima. O exemplo mais evidente de resultados deste esforço é a arquitetura
MAP (Manufacturing Automation Protocol), definida por iniciativa da General Motors e
baseada no modelo OSI.
Por outro lado, considerando que as necessidades de comunicação em cada classe
de atividades de uma empresa pode assumir diferente importância, outras propostas de
arquiteturas podem ser consideradas, como por exemplo as arquiteturas da classe
barramento de campo (fieldbus), mais dedicadas ao chão de fábrica, como o nome sugere.
— 5.1 —
CAP. 5 — R EDES LOCAIS I NDUSTRIAIS PROF. VITÓRIO BRUNO MAZZOLA
O objetivo desta parte do documento, além de apresentar algumas propostas de

arquiteturas de redes locais industriais, édiscutir os principais aspectos relacionados com
esta classe particular de redes.
Dados os requisitos e características apresentados anteriormente, um ponto que
deve ser levantado como conseqüência disto é a necessidade de descentralização das
funções de comunicação a serem implementadas. Este aspecto pode ter importância
fundamental na escolha das soluções de comunicação a serem adotadas a nível de uma
indústria. As redes do tipo ponto-a-ponto, por exemplo, são um exemplo típico de
centralização das funções de comunicação, uma vez que os equipamentos compondo os
nós da rede fazem papel de comutadores das mensagens transmitidas entre dois nós que
não estejam ligados diretamente. Soluções do tipo rede de difusão são largamente adotadas
levando em conta as possibilidades de descentralização da comunicação.
É preciso assumir a realidade de que não existe uma rede única que poderia
corresponder às necessidades de todas as classes ou níveis de atividade existentes em uma
fábrica, a solução sendo, de fato, a adoção de várias redes interconectadas, cada rede
servindo de suporte à comunicação no contexto de uma ou diversas atividades.
3. AS REDES NA EMPRESA
Já há algum tempo vem se verificando uma tendência para a descentralização da

inteligência e da capacidade decisória dos componentes de sistemas de automação
industrial. Estes sistemas são decompostos em diferentes níveis hierárquicos de
automação, cujos elementos inteligentes são interligados entre si através de redes
industriais, conforme mostrado na figura 5.1.
A tendência desta estruturação hierárquica é se aproximar cada vez mais do
processo, de forma a obter-se cada vez mais subsistemas independentes e dotados de uma
inteligência local, sem no entanto perder as vantagens de uma supervisão e condução
central do sistema como um todo. Esta descentralização traz consigo uma série de vanta-
gens técnicas, tais como a diminuição da sobrecarga de processamento da unidade central,
entre outras.
Cada nível da hierarquia fabril é representado por um conjunto de ações e
processamentos que possuem requisitos de comunicação diferentes. A característica
predominante nos níveis hierárquicos inferiores é a transferência de mensagens curtas com
alta freqüência, entre um número elevado de estações.
Nos níveis hierárquicos superiores há a predominância de transferência de
mensagens longas entre um número menor de estações e a uma freqüência
consideravelmente mais baixa, este aspecto sendo ilustrado pela figura 5.2.
Deste modo, não existe um sistema de comunicação único capaz de atender a todas
as aplicações existentes na organização industrial, mas sim uma série de sub-redes locais
adequada aos requisitos de comunicação de cada nível.
As sub-redes serão conectadas à linha tronco ("Backbone") através de "Gateways",
"Bridges" e "Routers" de modo que todas as estações possam ser acessadas, formando um
sistema de comunicação coêso que atenda toda a fábrica, conforme os preceitos da filosofia
CIM (Computer Integrated Manufacturing).
4. ASPECTOS DA COMUNICAÇÃO EM AMBIENTE INDUSTRIAL
A maioria das redes de comunicação existentes no mercado procuraram atender a

demanda existente na automação de escritórios. A grande maioria destas redes são
baseadas no protocolo CSMA/CD (Carrier Sense Multiple Access with Collision Detection),
com o qual se iniciaram os desenvolvimentos de redes locais (LANs) e que será estudado
mais adiante. A comunicação de dados em ambiente industrial apresenta, no entanto,
características e necessidades que tornam a maioria das redes para automação de
escritório inadequadas.
— 5.2 —
Administração
Corporativa
SISTEMA DE
COMUNICAÇÃO
Planejamento
(Factory) CAD, CAE, CAP,
MAP, TOP
CAPP, CAQ, etc...
Área
(Shop) MAP-EPA,
FMS Mini-MAP
Célula
(Cell)
FMC
Fieldbus
Subsistema
(Subsystem)
Torno, Manipulador,
Centro de Usinagem,
etc... Fieldbus
Tempo-Real
Componente
S A S A S A S A Motores, Chaves,
(Component)
Relés, etc...
Figura 5.1 - As redes de comunicação e o modelo CIM
Vida Útil dos Tempo entre

Administração Transmissões
Dados
Corporativa
Planejamento
Área
Célula
Subsistema
Número de Quantidade
Componente
Estações de Quadros
Figura 5.2 - Características da comunicação em CIM
Algumas destas características são:
• ambiente hostil para operação dos equipamentos (perturbações eletromagnéticas,

elevadas temperaturas, sujeira, etc);
• a troca de informações se dá, na maioria das vezes entre equipamentos e não
entre um operador e o equipamento;
• os tempos de resposta e a segurança dos dados são críticos em diversas
situações;
• uma grande quantidade de equipamentos pode estar conectada na rede.
— 5.3 —
5. CARACTERÍSTICAS BÁSICAS DAS REDES INDUSTRIAIS
Os seguintes aspectos tecnológicos básicos diferenciam as redes locais para

aplicações industriais das demais redes:
5.1. Tempo de acesso ao meio físico
Como foi dito na seção anterior, as redes de difusão apresentam aspectos

interessantes que as tornam uma solução bastante adequada aos requisitos de
comunicação industrial. Um problema importante na utilização das redes de difusão é o
acesso ao meio, pois, uma vez que vários equipamentos deverão trocar informações num
dado instante, a decisão de quem vai ter o direito de acesso ao meio para o envio de uma
mensagem não é uma tarefa evidente, como será visto nesta seção.
Do ponto de vista da programação distribuída, o meio de transmissão das redes
locais constitui um recurso compartilhado entre as estações a ela conectadas. Os métodos
de definição de direito de acesso utilizados nas redes locais são os denominados protocolos
de acesso ao meio.
Com relação ao seu comportamento temporal, podemos organizar os protocolos de
acesso ao meio em duas principais classes: os protocolos determinísticos e os não
determinísticos.
Os protocolos de acesso determinísticos são caracterizados pela concessão do
direito ao acesso independentemente das necessidades de transmissão de cada nó da
estação. Dentre os protocolos conhecidos desta classe, podemos destacar o protocolo
TDMA (Time Division Multiple Access), onde o acesso é dado a cada estação considerando
faixas de tempo bem definidas. Este método apresenta um baixo desempenho, uma vez que
muito tempo pode ser perdido no caso de estações que não tenham mensagens a transmitir.
Outro exemplo de protocolos de acesso determinísticos são aqueles baseados na
passagem de ficha (token passing), onde uma ficha correspondendo ao direito de
transmissão é passada de estação a estação da rede. Ao receber a ficha, uma estação que
não tenha mensagens a transmitir repassa a ficha à estação seguinte na lista de estações
compondo a rede. Vamos analisar alguns destes protocolos mais adiante nesta seção.
Os protocolos de acesso não determinísticos, podem ser também denominados
protocolos de competição, uma vez que as estações querendo transmitir vão competir pelo
meio de transmissão. Estes protocolos são mais adaptados às condições de transmissão da
rede local. Um exemplo desta classe são os protocolos de tipo CSMA, cujas variações serão
estudadas nos parágrafos a seguir.
5.2. Confiabilidade
Em aplicações industriais onde são transmitidos muitos códigos de comando, leitura

de medidores e comando de atuadores, um erro de um Bit qualquer pode ter conseqüências
desastrosas. A transferência de programas para máquinas de Comando Numérico, por
exemplo, exige um sistema altamente confiável, pois são transmitidos códigos de comando
cuja mínima alteração pode produzir danos de elevado custo. Desta forma, redes industriais
de comunicação tem que oferecer uma elevada confiabilidade.
Para aumentar esta confiabilidade nas mensagens transmitidas, normalmente é
usado um teste cíclico de redundância (CRC - Cyclical Redundance Check). Define-se
como Distância de Hamming (Hd) de um CRC o número mínimo de Bits que devem estar
alterados em uma mensagem para que o CRC não consiga detectar esta mudança. Em
ambientes industriais é usualmente recomendada uma Distância de Hamming de pelo
menos 4.
Em sistemas que necessitem de uma operação contínua, pode ser utilizado um meio
de transmissão e estações de controle redundantes.
— 5.4 —
5.3. Requisitos do meio ambiente
Devido às características do ambiente industrial, a presença de perturbações

eletromagnéticas, provocadas principalmente pelos acionamentos de motores elétricos de
grande porte ou outras fontes chaveadas (estações de solda, conversores estáticos,etc),
não pode ser desprezada na escolha de uma rede de comunicação.
Para a definição do meio físico de transmissão e do protocolo de comunicação, estas
características devem ser consideradas. O meio de transmissão deve possuir uma boa
resistência mecânica e deve estar elétricamente isolado.
O meio físico a ser adotado não depende apenas de aspectos técnicos mas também
(e muito especialmente no chão de fábrica) do aspecto de custo. Cabos coaxiais são menos
afetados por perturbações eletromagnéticas do que o par trançado. No entanto, o custo do
cabo coaxial é consideravelmente superior ao do par trançado.
Futuramente, a adoção de fibras óticas poderá vir a ser a melhor solução tanto do
ponto de vista técnico quanto econômico. Atualmente ainda há dificuldades na realização de
bifurcações com este meio físico, necessárias para as conexões em T usadas em redes
com topologia em barramento, de modo que as fibras óticas são mais utilizados em
sistemas com topologia em estrela ou anel. A realização de bifurcações tem alcançado
melhores resultados adotando acopladores ativos (com eletrônica adicional para conversão
do sinal ótico em elétrico e vice-versa nos pontos de derivação), o que torna a solução anti-
econômica para o nível de chão de fábrica. Com fibras óticas, no entanto, pode-se trabalhar
com freqüências da ordem de 100 MBaud, o que permitiria uma melhoria de performance do
sistema. Diversos trabalhos de pesquisa vem sendo realizados no sentido de resolver os
problemas técnicos existentes.
A figura 5.3 apresenta uma comparação sumária entre os três tipos de meio.
5.4. Tipo de mensagens e volume de informações
Nos níveis hierárquicos superiores de automação (por ex. a nível de planejamento)

são freqüentemente trocados telegramas de vários KByte, que requerem tempos de
transmissão de alguns segundos até vários minutos. Nas aplicações mais próximas ao
processo, normalmente são enviadas mensagens curtas, tais como:
Sensibilidade
Par Trançado a
perturbações
(assíncrono)
Par Trançado
(síncrono)
Cabo Coaxial
Fibra Ótica
Taxa de
Custo Distância
Transmissão
Figura 5.3 - Meios de transmissão
— 5.5 —
• ligar ou desligar uma unidade;

• fazer leitura de um sensor / medidor;
• alterar o estado de um atuador;
• verificar o estado de uma chave ou relé.
Estas operações podem ser feitas normalmente com um único código acrescido dos
respectivos dados, quando existirem. Como conseqüência, pode haver uma baixa taxa de
transmissão de dados com um elevado número de mensagens transmitidas.
Para dispositivos programáveis encontrados no ambiente industrial (CLPs, CNCs,
RCs, etc), normalmente é necessário o envio de programas no inicio da produção de um
lote. Estes programas raramente ultrapassam 10 KBytes em tamanho e dificilmente são
utilizados mais de 3 programas por unidade de fabricação durante um turno de trabalho.
6. PROJETOS DE PADRONIZAÇÃO DE REDES INDUSTRIAIS
As exigências de comunicação entre unidades para a integração flexível dos

sistemas de automação, descritas nos itens anteriores, evidenciam a necessidade de uma
especificação de redes locais para aplicações industriais diferente daquela adotada em
automação de escritório. Existem diversas redes proprietárias para ambiente fabril,
desenvolvidas por grandes empresas e que normalmente utilizam um protocolo específico
desenvolvido pelo próprio fabricante. Estas redes não permitem a interligação de
equipamentos de outros fabricantes. Desta forma o usuário fica na total dependência de um
único fornecedor.
A arquitetura das redes de comunicação industrial deve integrar sistemas
heterogeneos de diferentes fabricantes, suportando tanto a operação de chão de fábrica
quanto as funções de apoio à produção. A definição de padrões de protocolos de
comunicação e a sua adoção por diferentes fabricantes deverá permitir a interconexão e até
mesmo a intercambiabilidade das várias unidades de processamento. Neste caso,
equipamentos produzidos por fabricantes diferentes podem ser facilmente incorporados à
instalação, simplesmente conectando-os ao sistema de comunicação. Entre as diversas
iniciativas para padronização para redes industriais, podemos destacar: Projeto PROWAY,
Projeto MAP (incluindo MAP/EPA e MINI-MAP), projeto TOP e Projeto FIELDBUS.
6.1. Projeto PROWAY
Em 1975 um grupo da IEC (International Electrotechnical Comission) iniciou seus

trabalhos para a normalização de redes de comunicação para controle de processos.
Destes trabalhos resultou a proposta PROWAY (Process Data Highway). O Proway passou
por diversas fases (Proway A, B e C) em função dos trabalhos de padronização
internacionais. Proway A e B utilizavam o protocolo HDLC da ISO na camada de enlace,
adequando-se assim apenas a sistemas tipo mestre/escravos. Proway C adotou a técnica
de token-passing. Sua arquitetura é composta de 4 camadas do modelo de referencia
ISO/OSI, denominadas "Line" (camada física), "highway" (camada de enlace), "network"
(camada de rede) e "application" (camada de aplicação).
6.2. Projeto MAP
O projeto MAP ("Manufacturing Automation Protocol") foi uma iniciativa da General

Motors, iniciada em 1980, com a finalidade de definir dentro do modelo OSI um ambiente de
comunicação voltado para a automação da manufatura. MAP define mecanismos de
comunicação entre equipamentos de chão de fábrica, tais como Robôs, CNCs, CLPs,
terminais de coleta de dados, Computadores, etc.
Esta proposta encontra boa aceitação a nível mundial por parte de usuários e
fornecedores de bens de automação, mas ainda esta sendo questionada pelos altos custos
de cada estação.
— 5.6 —
Para aplicações voltadas ao controle da manufatura com tempos críticos foi definida
a versão MAP/EPA (Enhanced Performance Architecture) para conseguir tempo de resposta
menores. A Versão MAP/EPA apresenta para algumas estações da rede a arquitetura MAP
completa (7 camadas) e uma arquitetura simplificada com as camadas 1,2 e 7 do modelo
OSI como caminho alternativo para satisfazer os requisitos de tempo. A versão mais
simplificada é conhecida como MINI-MAP e implementa somente as camadas 1, 2 e 7 do
modelo OSI. O projeto MAP será discutido mais detalhadamente mais adiante.
6.3. Projeto TOP
Com objetivos semelhantes ao MAP, foi desenvolvido pela BOEING a partir de 1983
o projeto TOP ("Technical and Office Protocol"), voltado à redes para automação de áreas
técnicas e administrativas. Também é baseado no modelo OSI de 7 camadas e tem como
finalidade fornecer aos usuários os seguintes serviços: correio eletrônico, processamento de
textos, acesso a base de dados, transferência de arquivos, CAD/CAM distribuído, troca de
documentos, transações bancárias, entre outros.
A partir de 1986 os projetos MAP e TOP passaram a ser coordenados
conjuntamente, resultando no projeto MAP/TOP.
6.4. Projeto FIELDBUS
O Fieldbus é uma solução de comunicação para os níveis hierárquicos mais baixos

dentro da hierarquia fabril, interconectando os dispositivos primários de automação
instalados na área de campo (Sensores, atuadores, chaves, etc) e os dispositivos de
controle de nível imediatamente superior (CLPs, CNCs, etc).
Ainda estão sendo definidos os padrões para o Fieldbus. Os principais grupos
envolvidos nos trabalhos de padronização são:
• Avaliadores: IEC, ISA, EUREKA, NEMA

• Proponentes: PROFIBUS, FIP, ISA-SP50
O Fieldbus e suas principais propostas de padronização serão discutidos em detalhe

mais adiante.
7. O PROJETO MAP
O projeto MAP tem como mérito a apresentação de uma proposta concreta para a
comunicação no ambiente de fábrica, estabelecendo as condições necessárias para a
integração dos componentes de automação em um ambiente integrado segundo a filosofia
CIM (Computer Integrated Manufacturing). Ao contrário do que se propunha inicialmente, hoje
está claro que não existe uma solução única de rede que atenda aos requisitos de todos os
níveis de comunicação em uma fábrica.
O projeto MAP nasceu no início dos anos 80 por iniciativa da GM (General Motors). Na
época, apenas 15% dos equipamentos programáveis de suas fábricas eram capazes de se
comunicar entre si.
Além disso, os custos de comunicação eram muito elevados, avaliados em 50% do
custo total da automação, isto devido às conexões especiais necessárias entre cada
equipamento. Ainda, cada nova instalação ou expansão no sistema existente estava
associada a uma despesa não desprezível. Considerando que, na época, estava previsto
que a quantidade de equipamentos programáveis deveria sofrer uma expansão de 400 a
500% num prazo de 5 anos, o problema de comunicação tornou-se, efetivamente, uma
prioridade a nível da empresa.
Diante do grave problema, a decisão deveria ser tomada no sentido de definir a
solução, cujas opções eram as seguintes:
— 5.7 —
• continuar a produção utilizando máquinas programáveis isoladas (stand-alone) de

uma variedade de fabricantes e solucionar o problema da maneira como vinha sendo
feito;
• basear os processos de produção na aquisição de equipamentos de um único
fabricante;
• desenvolver uma proposta padronizada que permitisse interconectar todos os
equipamentos da planta.
Dadas as perspectivas de evolução e o grande desenvolvimento dos equipamentos

de automação, a primeira proposta era, naturalmente, inviável. Com relação à segunda
proposta, era (e continua sendo) impossível encontrar um único fabricante capaz de fornecer
todos os equipamentos necessários (robôs, máquinas de comando numérico, CLPs,
sensores, etc) ao processo de fabricação.
A solução viria, então, pela terceira opção, que foi o ponto de partida para o projeto
MAP, através da criação de uma força tarefa reunindo profissionais das diversas divisões da
GM, cujo objetivo inicial era investigar a possibilidade de utilização do modelo de referência
OSI como base para a proposta padronizada da empresa.
Um ano mais tarde, em 1981, a GM uniu-se a outras empresas -Digital Equipment
Corporation (DEC), Hewlett-Packard (HP) e IBM -definindo a solução do problema baseada
na utilização de uma arquitetura de comunicação para rede local baseada no modelo a sete
camadas do OSI. Uma primeira preocupação deste grupo de trabalho foi a seleção de alguns
dos padrões de protocolo definidos para o modelo OSI que pudessem ser adotados na
arquitetura MAP.
A partir dai o projeto foi ganhando corpo e adesões por parte de outras empresas,
tornando-se uma realidade nos anos 90 e dando origem a outras propostas de arquiteturas
de comunicação orientadas a outros níveis das atividades da empresa.
7.1. A arquitetura MAP
Uma vez adotado o modelo OSI como referência para a arquitetura de comunicação,
o problema era selecionar as propostas a serem implementadas a nível de cada camada.
Para as camadas 1 e 2, foram selecionados, respectivamente, as normas IEEE 802.4
(barramento com ficha) e IEEE 802.2 (LLC).
Do ponto de vista da camada Física, foi escolhido o suporte de comunicação em
banda larga (broadband). A escolha foi baseada nas razões seguintes:
• possibilidade de definição de vários canais de comunicação sobre um mesmo

suporte de comunicação, o que permitiria a coexistência de várias redes,
minimizando as modificações de cablagem durante a transição para MAP;
• permitiria a troca de outros sinais, como voz e imagem para determinadas
aplicações, tais como a supervisão, o circuito fechado de TV, a teleconferência, etc;
• broadband é parte da norma IEEE 802.4 e estava sob estudos suportar o padrão
IEEE 802.3 (CSMA/CD);
• a GM já possuía muitas instalações operando em broadband.
As razões que conduziram à escolha do barramento com ficha foram as seguintes:
• inicialmente, era o único protocolo suportado em broadband;

• muitos equipamentos programáveis já eram providos com o protocolo de
enlace suportado por broadband e IEEE 802;
• a possibilidade de implementar um esquema de prioridades de mensagens;
• em caso de falhas físicas, mensagens de alta prioridade poderiam ser
enviadas num tempo limitado.
— 5.8 —
Apesar das razões expostas acima para a escolha do barramento com ficha, esta foi
uma escolha relativamente debatida, principalmente porque a arquitetura MAP é a única a
adotá-la e os circuitos integrados implementando IEEE 802.4 são utilizados exclusivamente
para esta arquitetura. Além disso, outras propostas tinham sido adotadas pelos grandes
fabricantes: Ethernet (IEEE 802.3) no caso da DEC e IEEE 802.5 no caso da IBM.
A nível da camada de Enlace, embora as funções associadas sejam principalmente a
detecção e recuperação de erros, optou-se por um protocolo que não implementasse estes
serviços, o LLC tipo 1, deixando estas funções a cargo dos níveis superiores (mais
particularmente, o nível Transporte).
O serviço de Rede é sem conexão, cada mensagem sendo roteada individualmente
através da rede. A norma ISO 8348, adotada a este nível, permite definir um conjunto de
regras de endereçamento através da rede. O protocolo de roteamento utilizado aqui foi
definido pelo projeto MAP e é atualmente normalizado na ISO sob o número 9542.
A nível do Transporte, foi adotada a classe 4 do protocolo de Transporte da ISO (TP4,
ISO 8072/73), orientado à conexão, com controle de erros. O serviço de Transporte oferece,
então, um canal de comunicação confiável, sem perdas, erros, nem duplicação de
mensagens. TP4 assegura ainda as funções de fragmentação e montagem de mensagens,
o que permite que as mensagens trocadas a este nível sejam de qualquer dimensão.
A norma ISO 8326/27 foi adotada para a camada de Sessão, assegurando as
funções de comunicação full-duplex e de resincronização.
Na camada de Apresentação, os problemas de representação de dados são
resolvidos com a adoção da sintaxe abstrata ASN.1, que serve de linguagem comum às
diferentes formas de representação dos dados, características de cada equipamento.
Dentre as funções oferecidas aos processos de aplicação, foram definidas, na
camada de Aplicação, as seguintes normas:
• MMS, para a troca de mensagens entre equipamentos de produção (que será visto
em detalhes mais a frente);
• FTAM, para o acesso e a transferência de arquivos;
• ROS, para a gestão de nomes (diretório);
• funções de gerenciamento de rede, para a gestão dos recursos, medição de
desempenho e modificação dos parâmetros da rede.
A figura 5.4 apresenta as escolhas efetuadas a nível do projeto MAP, incluindo as

versões EPA e Mini-MAP. Como a partir da versão 3.0 ocorreu uma unificação dos projetos
MAP e TOP, a figura apresenta também as normas adotadas para a arquitetura TOP.
7.2. A arquitetura MAP-EPA
Dadas as necessidades específicas de cada nível hierárquico de uma empresa,

verificou-se que a proposta MAP original não permitia cobrir todos os níveis considerados,
sendo mais adequada aos níveis superiores. Uma razão principal disto é que, apesar da
excelente qualidade dos serviços oferecidos, a arquitetura a sete camadas oferece um
overhead que passa a ser indesejável nos níveis mais baixos das atividades de uma
empresa.
Uma primeira solução a este problema foi a definição de uma versão simplificada da
arquitetura MAP, denominada MAP-EPA (Enhanced Performance Architecture). A figura 5.5
apresenta a proposta MAP-EPA.
Esta proposta foi baseada na definição de duas pilhas de protocolos, a pilha normal
Full-MAP e a pilha MAP-EPA, desprovida das camadas de Rede, Transporte, Sessão e
Apresentação.
Do ponto de vista das camadas baixas, o protocolo IEEE 802.4 continuava sendo
adotado, porém sobre um suporte de transmissão em banda de base (baseband) a 5 Mbit/s.
— 5.9 —
Espec.
Camadas
TOP MAP MAP-EPA MiniMAP
ACSE, FTAM
Aplicação MMS, FTAM, ROS
VTP
Apresentação ISO 8822 - ASN.1
Sessão ISO 8326 e 8327

VAZIO
Transporte ISO 8072 e 8073 Classe 4
Rede ISO 8348 s/ conexão
LLC 802.2 Tipo1 LLC 802.2 Tipo 1 LLC 802.2 Tipos 1 e 3

Enlace MAC 802.3 CSMA/CD MAC 802.4 Token Bus
MAC 802.4
Banda Base Banda Larga
Física Banda Base (5 Mbps)
(10 Mbps) (10 Mbps)
Figura 5.4 - Especificação MAP/TOP 3.0
MAP EPA
Aplicações
tempo-real
Aplicação
Apresentação
Sessão
Transporte
Rede
Enlace LLC 802.2 Tipos 1 e 3

MAC 802.4 Token Bus
Física
Figura 5.5 - Arquitetura MAP-EPA
Nesta arquitetura, um processo de aplicação tem a opção de enviar seus dados

através da pilha normal ou, em casos onde o requisito seja um tempo de resposta rápida,
pela pilha MAP-EPA. Evidentemente, o fato das camadas 3 a 6 estarem ausentes acarreta a
perda dos serviços oferecidos por estas.
7.3. A arquitetura Mini-MAP
Uma terceira opção relacionada com a norma MAP foi a arquitetura Mini-MAP,
baseada igualmente na supressão das camadas 3 a 6 para eliminar o overhead dos
protocolos daquelas camadas. A arquitetura Mini-MAP é composta unicamente do segmento
simplificado de MAP-EPA, e foi assim definida para evitar o alto custo das pilhas de
protocolos paralelas de MAP-EPA (figura 5.6). Esta nova proposta era dedicada aos níveis
mais baixos, permitindo a comunicação em aplicações mais simples como, por exemplo,
entre sensores inteligentes.
— 5.10 —
O fato de não possuir a camada de Transporte fez introduzir um protocolo de Enlace

mais sofisticado que o da proposta MAP, o LLC tipo 3, datagrama com reconhecimento.
7.4. Os serviços de mensagem industrial (MMS)
MMS (Manufacturing Message Services) foi normalizado na ISO como sendo o

conjunto de serviços de comunicação oferecido às aplicações industriais, particularmente
para viabilizar, dentro do ambiente OSI, as interações entre equipamentos de produção
programáveis.
MMS é o resultado dos trabalhos realizados no contexto do projeto MAP, para a
definição de um conjunto de serviços de comunicação orientados às aplicações industriais.
A primeira proposta de MMS/RS-511 foi apresentada em junho de 1985, na forma de
um documento organizado em duas partes:
• Manufacturing Message Services: Definição dos Serviços;

• Manufacturing Message Specification: Especificação do Protocolo.
Atualmente, MMS tornou-se norma internacional, fazendo parte da camada de

Aplicação da versão 3.0 de MAP, publicada em agosto de 1988. Os dois documentos
mencionados acima apresentam, de forma geral, como os serviços e o protocolo podem ser
aplicados no contexto da utilização de um equipamento de produção genérico, sem levar em
conta as particularidades de uma classe de equipamentos específica. Para complementar a
norma existente, outros documentos foram e estão sendo produzidos, denominados normas
de acompanhamento ("Companion Standards"), cujo objetivo é levar em conta as
especificidades de classes de equipamentos tais como os robôs, as máquinas de comando
numérico, os sistemas de visão, os controladores lógicos programáveis e os sistemas de
controle de processos.
O objetivo de MMS é oferecer serviços de comunicação que permitam a um sistema
aberto (no sentido OSI) acessar os recursos existentes em outros sistemas abertos
conectados à rede de comunicação. Eles permitem cobrir grande parte das necessidades de
comunicação entre sistemas de produção, como, por exemplo, o carregamento remoto de
programas, o controle remoto de um equipamento, a elaboração de relatórios de produção,
etc.
Os programas escritos pelos programadores de aplicação vão acessar (direta ou
indiretamente) as primitivas de serviço MMS, que vão manipular objetos virtuais
representando os recursos reais disponíveis num equipamento de produção distante.
Aplicação
Conexão com LSAPs
LLC Tipos 1 e 3
MAC 802.4
Banda Base
(5 Mbps)
Figura 5.6 - Arquitetura Mini-MAP
— 5.11 —
Os objetos MMS
Os usuários dos serviços MMS são os processos de Aplicação (APs - Application

Processes) executando num equipamento de produção ou num computador de supervisão.
A comunicação entre dois APs através dos serviços MMS é realizada segundo um modelo
Cliente-Servidor, onde o usuário Cliente é aquele que requisita operação sobre os recursos
disponíveis num equipamento de produção distante, este sendo modelizado por um usuário
Servidor.
O objeto de base definido em MMS é o Dispositivo Virtual de Produção ou VMD
(Virtual Manufacturing Device), que representa, no contexto dos serviços MMS, um
equipamento real de produção. Todo processo de aplicação modelizado por um Servidor
MMS possui, no mínimo, um objeto VMD (figura 5.7). O principal componente do VMD é a
Função Executiva, responsável pela gestão de acesso aos diferentes recursos do
equipamento considerado, tais como memória, processadores, portas de E/S, etc...
O VMD define uma classe de objetos denominados domínios (Domains), que
permitem reagrupar os programas e os dados necessários à execução do equipamento
considerado. Estes programas e dados podem ser definidos de maneira estática ou
dinâmica por meio dos serviços MMS.
A execução de programas é gerenciada através de objetos denominados Invocação
de Programa (Program Invocation), que podem, também, ser criados estática ou
dinamicamente. Um operador humano pode se comunicar com um equipamento de
produção, fazendo a entrada e saída de dados graças à definição de um objeto Estação
Operador, sendo que um VMD pode gerenciar uma ou mais estações de operador.
A norma prevê, ainda, objetos permitindo gerenciar a sincronização de processos e o
acesso concorrente a recursos, que são os objetos Semáforos; para a detecção e o
tratamento de eventos, os objetos Condição de Evento, Ação de Evento e Inscrição de
Evento; e para a produção de relatórios de produção, os objetos Jornais.
Foram definidos também objetos denominados variáveis (variables), que podem ser
alocados dentro de um VMD. A cada classe de objetos MMS é associada uma classe de
serviços responsáveis da sua manipulação, sob demanda de um usuário Cliente remoto.
Os serviços MMS
A norma MMS define 84 serviços, dos quais 3 não confirmados, organizados em 9

classes distintas. Os serviços de Gestão de Contexto são utilizados para o estabelecimento
e a manutenção do diálogo entre usuários MMS, nenhum serviço podendo ser ativado sem
que o contexto tenha sido estabelecido, suportado por uma associação. O serviço Initiate é o
serviço definido para o estabelecimento da associação, este sendo mapeado diretamente
sobre o serviço A_ASSOCIATE do ACSE. Esta classe de serviços reagrupa, ainda, serviços
para a terminação negociada do contexto (Conclude), a liberação abrupta (Abort). Uma
requisição de serviço pode ser anulada por um usuário MMS cliente, através da ativação do
serviço Cancel.
...
VMD Estação
...
Operador 1
...
Objetos
MMS
Função Executiva Estação

Operador N
Figura 5.7 - Estrutura geral de um VMD
— 5.12 —
Ainda, o fornecedor de serviço MMS pode sinalizar a ocorrência de um erro de

protocolo através do envio de uma primitiva de serviço (indicação) Reject, informando o tipo
de erro detectado.
Os serviços de Suporte de VMD permitem a um usuário Cliente MMS obter
informações de estado sobre um objeto VMD, assim como sobre os objetos gerenciados por
este. As informações possíveis de serem obtidas são:
• Estado lógico do VMD (Status);

• Lista dos objetos do VMD (GetNameList);
• Características do equipamento de produção (Identify).
Finalmente, é ainda possível modificar os identificadores dos objetos de um VMD, isto

através do serviço Rename.
Os serviços de Gestão de Domínio são utilizados para o carregamento e
armazenamento à distância de programas e dados de um equipamento de produção. Estas
operações são baseadas na realização de duas seqüências de serviços MMS, a primeira
para o carregamento remoto, DownLoadSequence, a outra para a recuperação do conteúdo
de domínios, UpLoadSequence.
Um usuário MMS ativa a seqüência DownLoad para pedir a criação e o carregamento
de informações para um domínio. Esta seqüência é caracterizada por três etapas:
• inicialização da seqüência e criação de um domínio (InitiateDownLoadSequence);

• transferência das informações para o domínio (DownLoadSegment);
• terminação da seqüência (TerminateDownLoadSequence).
Os serviços de Gestão de Programa permitem a um usuário MMS manipular, de

maneira remota, os programas num VMD, para a criação, eliminação e controle de
execução. As operações podendo ser efetuadas sobre um objeto Invocação de Programa
são as seguintes:
• criação e eliminação (CreateProgramInvocation e DeleteProgramInvocation);

• controle de execução de um programa (Start, Stop, Resume, Reset e Kill);
• obtenção de atributos (GetProgramInvocationAttributes).
Os serviços de Acesso às Variáveis permitem a um cliente MMS definir e acessar

variáveis definidas num VMD de um servidor MMS. O acesso às variáveis reais de um
equipamento é possível graças àdefinição de um conjunto de objetos variáveis MMS,
manipulados pelos 14 serviços definidos nesta classe. Os serviços Read e Write, por
exemplo, permitem acessar, respectivamente em leitura e escrita, uma variável. Existem
ainda serviços permitindo definir os diferentes objetos associados às variáveis, tais como
DefineNamedVariable, DefineScatteredAccess, DeleteVariableAccess, DefineNamed-
VariableList, DeleteNamedVariableList, DefineNamedType e DeleteNamedType.
Os serviços de Gestão de Semáforos permitem gerenciar o acesso concorrente aos
recursos compartilháveis de um VMD. Os objetos associados a esta classe são os
Semáforos, organizados em duas classes específicas:
• os Semáforos Banalizados (Token Semaphores), que gerenciam um número N de

fichas de mesmo tipo;
• os Semáforos Etiquetados (Pool Semaphores), que gerenciam uma lista de fichas
etiquetadas, cada uma associada a um recurso particular do VMD.
Um usuário MMS pode requisitar o acesso a um recurso do VMD através do serviço

TakeControl, indicando o semáforo responsável por aquele recurso. Um aspecto
interessante desta classe de serviços é a existência de um modificador
— 5.13 —
AttachToSemaphore, que permite condicionar a execução de um serviço MMS à posse de

um semáforo.
Esta classe oferece, ainda, serviços para a liberação, a criação e a obtenção de
informações de estado sobre os objetos semáforo.
Os serviços de Gestão da Estação de Operador implementam a comunicação,
através de uma estação de operador, com um VMD. Eles permitem, particularmente, a
entrada e a obtenção de dados relativos à execução do VMD considerado.
Os serviços de Gestão de Eventos oferecem facilidades para um Cliente MMS definir
e tratar a ocorrência de eventos num VMD. O tratamento de eventos é associado à definição
de três objetos:
• as Condições de Evento, que representam as précondições associadas a um dado

eventos num VMD (modificação de uma variável, fim de execução de um programa,
etc);
• as Ações de Evento, que representam o que deve ser feito quando um evento é
detectado (execução de um serviço MMS, por exemplo);
• as Inscrições de Evento, que permitem associar uma Condição de Evento a uma ou
mais Ações de Evento.
Um usuário MMS é notificado da ocorrência de um evento através do serviço

EventNotify, esta notificação podendo ser reconhecida pelo usuário através do serviço
AcknowledgeEventNotification. A ocorrência de um evento pode servir a ativar a execução de
um serviço MMS, isto sendo feito através do modificador AttachToEvent. Nesta classe,
tem-se, ainda, serviços para a criação, destruição de objetos, obtenção de informações
(estado, atributos, etc) dos objetos e modificação de atributos dos objetos de evento.
Os serviços de Gestão de Jornais fornecem facilidades para o armazenamento e a
recuperação, de maneira ordenada, a partir dos objetos Jornais, das informações e variáveis
associadas a eventos, assim como de texto que pode servir como comentários ou
explicações. Estes serviços são utilizados principalmente para a produção de relatórios
sobre o funcionamento de um equipamento de produção.
Ainda, a norma MMS prevê uma classe de serviços para o tratamento de arquivos,
particularmente para pequenos serviços de criação, eliminação, etc. No caso de aplicações
que requisitem serviços mais sofisticados para o acesso e a transferência de arquivos, a
entidade de Aplicação deverá, então, ser composta do elemento de serviço de Aplicação
FTAM, que oferece estes serviços.
Os quadros a seguir apresentam uma síntese das diferentes classes de serviços do
MMS.
8. REDES FIELDBUS
A evolução dos microprocessadores conduziu a estruturação hierárquica fabril até o

nível de simples componentes de automação, envolvendo elementos diretamente ligados ao
processo a ser controlado ou supervisionado, tais como sensores, atuadores e
controladores.
Através da aplicação de microprocessadores em sistemas sensórios é possível
realizar um pré-processamento do sinal diretamente no local de medição, diminuindo assim
a probabilidade de deturpação do sinal por perturbações eletromagnéticas, às quais sinais
analógicos são em geral muito suscetíveis. Além disto, a unidade que requer os dados do
sensor é aliviada destas funções. O mesmo principio é aplicado aos atuadores, que passam
a poder interpretar e executar comandos complexos advindos da unidade central.
Uma vez que os sinais utilizados por tais componentes inteligentes já se encontram
em forma digital, é conveniente definir sistemas de comunicação de dados também digitais
para substituir as clássicas interfaces analógicas de corrente e tensão. As interfaces de
corrente (4..20 mA) são bem mais difundidas em ambientes industriais, devido a menor
suscetibilidade às interferências eletromagnéticas.
— 5.14 —
Classe Primitivas de Serviço Comentários

TakeControl são encarregados da
RelinquishControl sincronização e do controle
Gestão de DefineSemaphore do acesso aos recursos de
Semáforos DeleteSemaphore um VMD pelos processos de
ReportSemaphoreStatus aplicação
ReportPoolSemaphoreStatus
ReportSemaphoreEntryStatus
Estação Input controlam a entrada e saída
Operador Output de informações via estações
de operador
DefineEventCondition permitem a definição e o
DeleteEventCondition tratamento de eventos via
GetEventConditionAttribute serviços MMS. A
ReportEventConditionStatus possibilidade de associar a
AlterEventConditionMonitoring execução de um serviço
TriggerEvent MMS àocorrência de um
DefineEventAction evento é um aspecto
DeleteEventAction interessante, implementado
GetEventActionAttributes pelo Modificador
ReportEventActionStatus AttachToEvent
Gestão de
DefineEventEnrollment
Eventos DeleteEventEnrollment
GetEventEnrollment
ReportEventEnrollment
AlterEventEnrollment
EventNotification*
AcknowledgeEventNotification
GetAlarmSummary
GetAlarmEnrollmentSummary
AttachToEventModifier
ReadJournal permitem o salvamento de
Gestão de WriteJournal informações sobre a
Jornal InitializeJournal execução de um VMD,
ReportJournalStatus particularmente no que diz
respeito à ocorrência de
eventos e à afetação de
variáveis.
Gestão de Initiate iniciação, liberação,
Contexto Conclude abandono e rejeição de
Abort* conexão com outro usuário
Cancel MMS
Reject*
Status oferece serviços de VMD,
Gestão de UnsolicitedStatus* particularmente informações
VMD GetNameList sobre os objetos
Identify
Rename
* serviços não confirmados
— 5.15 —
Classe Primitivas de Serviço Comentários

InitiateDownLoadSequence permitem transferir
DownLoadSegment informações, tais como
TerminateDownLoadSequence códigos e dados de
InitiateUpLoadSequence programa, para serem
UpLoadSegment carregados num domínio de
Gestão de TerminateUpLoadSequence forma dinâmica: as
Domínio RequestDomainDownLoad seqüências DownLoad e
RequestDomainUpLoad UpLoad são atividades que
LoadDomainContent permitem gerenciar as
StoreDomainContent transferências entre Cliente e
DeleteDomain Servidor
GetDomainAttribute
DomainFile
CreateProgramInvocation permitem que um usuário
DeleteProgramInvocation Cliente MMS gerencie a
Start execução remota de
Gestão de Stop programas num usuário
Programas Resume Servidor
Reset
Kill
GetProgramInvocationAttributes
Read permitem a definição e o
Write acesso às variáveis de um
InformationReport VMD e estabelecer a relação
GetVariableAccessAttributes entre as variáveis de um VMD
DeleteNamedVariable (objetos) e as variáveis real
Acesso a DefineScatteredAccessAttributes de um equipamento de
Variáveis DeleteVariableAccess produção
DefineNamedVariableList
GetNamedVariableListAttributes
DeleteNamedVariableList
DefineNamedType
GetNamedTypeAttributes
DeleteNamedType
* serviços não confirmados
Inicialmente foram definidas e grandemente difundidas interfaces digitais para

interligação ponto-a-ponto, tipo RS 232 C que, no entanto, devido à utilização de sinal
referenciado ao terra (v24) se mostram mais adequadas à utilização em aplicações de
escritório. Para reduzir a influência das perturbações foram desenvolvidas interfaces com
sinal diferencial (v11), tipo RS 422 e RS 423. Estas interfaces oferecem no entanto a
desvantagem de que não permitem o acoplamento simultâneo de vários elementos inteli-
gentes entre si. Para suprir esta necessidade foram desenvolvidas interfaces multiponto,
adequadas a interconexão dos elementos em redes tipo barramento (bus), como por
exemplo a RS 485. Esta tendência é mostrada na figura 5.8.
Para uma rede aplicada à interligação de elementos simples a nível de chão de
fábrica é utilizada a denominação genérica de "barramentos de campo", ou Fieldbus.
O Fieldbus pode ser definido como uma linha de comunicação serial, digital, bidirecio-
nal (de acesso compartilhado) para a interligação dos dispositivos primários de automação
(instrumentos de medição, atuação e controle final e outros pequenos dispositivos "inte-
ligentes" com capacidade de processamento local) a um sistema integrado de automação e
controle de processos.
— 5.16 —
As principais vantagens e benefícios da utilização do Fieldbus em relação às

conexões convencionais podem ser resumidas como segue:
Vantagens econômicas
• drástica redução da cablagem pela utilização de um meio físico compartilhado;

• redução do número de canais de comunicação com o processo;
• redução do tempo e complexidade do projeto de layout;
Vantagens técnico-operacionais
• facilidade de instalação e manutenção, pela manipulação de um menor número de

cabos e conexões;
• facilidade de detecção, localização e identificação de falhas, através de funções de
monitoração automática;
• maior modularidade no projeto e instalação, aumentando a flexibilidade de expansão
de funções e módulos;
Vantagens sistêmicas
• aumento da consistência e da confiabilidade da informação advinda dos instrumentos

de campo, através da digitalização e pré-processamento;
• possibilidade de sincronização dos instantes de amostragem de Entrada/Saída;
• melhoria do desempenho global da aplicação pela descentralização do
processamento;
• maior facilidade de interconexão entre níveis hierárquicos diferentes de automação;
Vantagens mercadológicas
• redução dos custos de sistemas através da aquisição seletiva de dispositivos

compatíveis de diferentes fornecedores, eliminando a dependência de somente um
fornecedor;
• desacoplamento do software de supervisão da dependência de um fornecedor
específico do Hardware;
TENDÊNCIA
Centralizado / Decentralizado /
Decentralizado / Digital
Analógico Multipontos
Keyboard Keyboard Keyboard
RS 232C RS 422
D A
A D FIELDBUS
MUX
P P P
P P
Sample/ P
Holder D A
A C D D A
4..20 mA
0..10 v A D
4..20 mA 0..10 v C
Adaptador Amp.
/Amp. Potência
Y Y Y Y Y Y
X X X X X X
sensores atuador sensores atuador
sensores atuador inteligentes inteligente inteligentesinteligente
Figura 5.8 - Tendências na interligação de sensores / atuadores.
— 5.17 —
Inicialmente se supunha que uma única rede iria cobrir todas as necessidades de
interconexão no chão de fábrica. Notadamente a proposta MAP, acrescida das versões de
maior performance e menor custo MAP/EPA e MINI-MAP se propunham também a integrar
elementos de automação ao nível hierárquico de componente. No entanto, logo pode ser
verificado que estas propostas eram demasiado caras e muito lentas para as aplicações
típicas a nível hierárquico de componente.
Enquanto os segmentos de banda base do MAP (MAP-EPA e Mini-MAP) permitem a
realização de tempos de resposta de cerca de 100 ms, sistemas tipo Fieldbus se propõe a
reduzir este tempo para a faixa de 1 a 10 ms, como requerido para o controle e supervisão
de importantes grandezas envolvidas na automação, tais como velocidade, posição de eixos,
torque, aceleração e força.
Um aspecto essencial na definição de protocolos de comunicação para o Fieldbus é
a redução a um mínimo estritamente necessário das informações adicionais incluídas nos
telegramas, de forma a permitir uma adequada performance em tempo real. Estas
simplificações em relação a sistemas tipo MAP e TOP são indispensáveis quando se
pretende interligar componentes simples tais como sensores e atuadores. Para sistemas
tipo Fieldbus são definidas, por questões de eficiência, somente as camadas 1, 2 e 7 do
modelo de referência OSI. As funções das camadas 3 até 6 que são indispensáveis para a
comunicação são aqui absorvidas pelas camadas 2 ou 7.
O aspecto de custo também assume grande importância, uma vez que os
dispositivos a serem interligados tem em geral custo inferior ao da própria interface MAP,
como pode ser visto na tabela que segue. São requeridos aqui nós a um custo da ordem de
U$ 50 ou inferior.
Componente MAP Preço médio Elemento Campo Preço médio

Cabo Coaxial U$ 2,5 / m CLP U$ 3.000
Controlador U$ 5.000 Controle Robô $20.000
Demodulador U$ 15.000 PC U$ 2.000
Componente Ethernet / IBM Preço médio Sensor/Atuador U$ 50 a 1000
Nó CSMA/CD U$ 500 - 1500 I/O Binária U$ 50 a 1000
Nó Token-Ring U$ 750 - 1500
O Fieldbus deve atender igualmente aos requisitos impostos pelos sistemas

discretos (Manufatura) e os sistemas contínuos de produção (Controle de Processos).
Podem-se considerar em principio três classes distintas de aplicação:
• sistemas "Stand-Alone", nos quais as transações ocorrem somente entre

dispositivos ligados em um mesmo segmento de rede. Aqui teríamos, por exemplo,
sensores e atuadores ligados a um CNC dentro de uma máquina.
• sistemas em cascata, nos quais dispositivos conectados a segmentos distintos
podem trocar informações por meio de um "bridge". Situação típica é a encontrada
em um SDCD (Sistema Distribuído de Controle Digital).
• sistemas hierárquicos, nos quais o segmento Fieldbus esta interligado via "gateway"
a uma rede interligando dispositivos de um nível hierárquico superior da automação
fabril. É o tipo de situação encontrado em uma estrutura CIM.
O fluxo de dados nestas aplicações pode se dar em dois sentidos:
• no sentido vertical, entre níveis hierárquicos diferentes, de modo a permitir a

supervisão do sistema. Para esta forma de comunicação deverão ser oferecidos
serviços de instalação, start-up, parametrização da aplicação, visualização de dados
para supervisão, etc. Estes serviços não são críticos no tempo.
— 5.18 —
• no sentido horizontal, entre elementos do mesmo nível, compondo um sistema

distribuído. Os serviços oferecidos para este tipo de comunicação se destinam
basicamente àatualização e consumo de dados e a checagem de "status". A
execução destes serviços é crítica no tempo.
Em função do tipo de aplicações que se propõe a atender, um conjunto de requisitos

básicos são impostos ao Fieldbus:
• necessidade de elevado desempenho para atender as aplicações com requisitos de

tempo críticos;
• método e meio de transmissão simples e de preço acessível. Os sistemas tipo
Fieldbus utilizam transmissão tipo Baseband. Como meio de transmissão adota-se o
par trançado;
• necessidade de consistência de dados;
• necessidade de serviços compatíveis com redes dos níveis hierárquicos superiores.
Em geral, se procura uma compatibilidade com os serviços oferecidos pelo MMS;
Diversos fabricantes de sistemas de comunicação industriais tem desenvolvidos

suas próprias soluções para o Fieldbus que, no entanto, não apresentam todos os requisitos
necessários às diversas aplicações na área de chão de fábrica. Para suprir esta deficiência,
vários esforços nacionais e internacionais tem sido feitos no sentido de definir uma norma
universalmente aceita para o Fieldbus, conforme mostrado na figura 5.9.
Dentre os sistemas Fieldbus atualmente em discussão, os mais fortes candidatos à
normalização são o PROFIBUS (Process Fieldbus, proposta alemã) e o FIP (Factory
Instrumentation Protocol, proposta francesa). Nos Estados Unidos foi definido o grupo de
estudos SP-50 da ISA (Intrumentation Society of America), que deverá apresentar
brevemente uma proposta de normalização americana e que leva em consideração partes
das propostas FIP e PROFIBUS bem como as propostas das firmas Faxboro e Rosemount /
Philips.
Todas estas propostas serão examinadas pela comissão SC65C/WG6 da IEC
(International Electrotechnical Comission) para a elaboração de uma norma internacional. As
expectativas são de que a passagem da norma americana elaborada pela ISA SP-50 para a
norma internacional da IEC deverá representar um passo meramente formal.
ESPRIT CNMA/
Fieldbus
PROFIBUS D Sistemas Fieldbus p/

Processos deFabricação
Norma nacional em
abril/91
Siemens
Foxboro ISA SP-50 USA IEC SC65C

Norma em preparação
Rosemount
Norma em 199?
variantes tipo SINEC L2
MIL 1553 eF
outros...
FIP F
EUREKA
Norma nacional início
1988 Fieldbus
Desenvolvimento e teste
de um Fieldbus para
Processos Unitários
Figura 5.9 - Atividades de Normalização do Fieldbus.
— 5.19 —
Processador Central
Cont. Atuador Processo
Sensor
Fieldbus
Processador Central Atuador
Cont.
Processo
Sensor
Figura 5.10 - Malha Fechada de Controle por Fieldbus.
Ao lado das questões de normalização permanecem ainda abertas à discussão

questões referentes ao espectro de aplicações a ser atendido pelo Fieldbus. Por um lado é
desejada uma boa compatibilidade e interconectabilidade com os níveis hierárquicos
superiores de automação, por outro devem ser considerados os requisitos técnicos e
econômicos para a conexão de componentes inteligentes simples e de baixo custo.
Enquanto soluções que permitam uma compatibilidade com a definição da camada
de aplicação adotada no sistema MAP através da definição de Subsets do MMS são
nitidamente favorizadas, permanece aberta a questão da adequação de tais sistemas para o
acoplamento direto de sensores e atuadores em processos com dinâmica elevada, como é
o caso de sistemas de controle em malha fechada na fabricação. A forma de estruturação
física de uma tal malha de controle com Fieldbus é mostrada na figura 5.10.
Nos itens seguintes apresentaremos as principais características dos sistemas
Fieldbus atualmente propostos para padronização internacional.
8.1. A Proposta FIP (Factory Instrumentation Protocol)
O projeto FIP foi elaborado por um conjunto de empresas européias

(Telemecanique,CEGELEC, CGEE Alsthom), órgãos do governo francês e centros de
pesquisa conglomerados em torno do chamado "Club FIP". A proposta procurou levar em
consideração as restrições de tempo real impostas por um grande número de aplicações a
nível de chão de fábrica. Definiu-se um modelo de transmissão "produtor-consumidor", que
difere das soluções mais usualmente encontradas em redes locais. Para este fieldbus
existem "chips" integrados que implementam as funções das três camadas (FIPART,
FULLFIP).
A camada Física
FIP oferece opcionalmente como meios de transmissão a fibra ótica e o par trançado
(blindado ou não). Para o par trançado são previstas três velocidades de transmissão de
dados:
• S1: 31.25 Kbps, distância até 2000 m;

• S2: 1 Mbps, distância até 500 m, par trançado blindado;
• S3: 2.5 Mbps, distância até 200 m, par trançado blindado.
— 5.20 —
A velocidade padrão é a S2. As velocidades S1 e S3 são utilizadas apenas para

aplicações especiais. Para uso com fibra ótica é prevista uma velocidade adicional de 5
Mbps.
Os bits a serem enviados são codificados em Manchester, que permite o envio
simultâneo do sinal de sincronização e dos dados propriamente ditos.
A camada física do FIP suporta segmentos com comprimento de até 2000 m e até
256 estações. O barramento principal pode ser decomposto em vários segmentos, que são
ligados a este por meio de "taps". Os segmentos podem ser interligados por meio de
repetidores, que fortalecem e reconstituem o sinal.
A camada física oferece os seguintes serviços de comunicação:
• PHY_data_request: pedido de transmissão de dados;

• PHY_data_indication: indicação de serviço concluído;
Além disso, a camada física oferece serviços de gerenciamento, que são:
• PHY_Reset: reinicialização do nível físico;

• PHY_SetValue: ajuste de parâmetros da camada física;
• PHY_ReadValue: leitura de parâmetros ajustados;
• PHY_Event: comunicação de eventos do nível físico.
A camada de Enlace
A camada de enlace do FIP não faz uma distinção formal entre subcamadas LLC e
MAC, como proposto na norma IEEE 802.
O método de acesso ao meio da rede FIP é baseado na difusão ("Broadcasting"). A
difusão é organizada por uma entidade centralizada denominada "árbitro de barramento". O
projeto FIP baseou-se no fato de que, nas redes industriais, uma informação gerada em um
determinado ponto pode interessar a várias outras estações (por exemplo, o dado gerado por
um sensor de temperatura pode interessar ao controlador, ao atuador e ao terminal de vídeo
do operador, simultaneamente).
A maioria dos dados transmitidos pelo barramento érepresentada por objetos
(variáveis). Cada objeto é representado por um "nome" único no sistema. Um objeto é, por
definição, elaborado por um único transmissor (produtor) e levado em conta por qualquer
número de receptores (consumidores). Devido ao uso da difusão, os endereços de
transmissores e receptores não precisam ser conhecidos pelas aplicações.
A comunicação transcorre da seguinte forma (figura 5.11):
• Em uma primeira fase, o árbitro difunde na rede o nome da variável (objeto) a ser
transmitida (quadro de identificação);
• O produtor da variável difunde, em seguida, a informação ligada ao identificador
(quadro de dados);
• todos os consumidores interessados passam a copia-la na fase final.
Cada estação é completamente autônoma. O único requisito imposto às estações é o

de difundir, por solicitação do árbitro de barramento, a variável ou variáveis por elas
produzidas.
Naturalmente, as estações devem também aceitar as variáveis que lhe são enviadas.
A varredura das variáveis periódicas é feita a partir de uma lista implementada no árbitro na
fase de inicialização e que, em geral, não é alterada posteriormente.
A transmissão de mensagens é feita conforme a norma IEEE 802.2, LLC tipos 1
(sem conexão) e 3 (com reconhecimento). Até 24.000 objetos (variáveis) são identificáveis e
podem ser trocados de forma cíclica utilizando uma tabela configurável.
O formato do quadro do FIP é mostrado na figura 5.12, onde:
— 5.21 —
• PRE: preâmbulo, utilizado para sincronização entre emissor e receptores. Compõe-

se de um caractere de 16 bits com alterações dos bits adjacentes de 1 para 0;
• FSD/FED: delimitadores de inicio e fim de quadro, respectivamente. São codificados
de forma a não serem confundidos com dados;
• EB: Bits de equalização, que operam como bits de interface entre os delimitadores e
os dados codificados em Manchester II;
• Controle: define tipo de quadro, podendo ser quadro de identificação de informação
ou de envio de informação (6 bits);
• Dados: pode conter um identificador representando o endereço lógico de uma
variável, o valor de uma variável, uma mensagem, o reconhecimento de uma
mensagem ou uma lista de identificadores;
• FCS: o controle de erros é feito utilizando a técnica polinomial, permitindo uma
distância de Hamming de 4 e adotando o polinômio gerador proposto pela CCITT.
Os serviços oferecidos pela camada de enlace são apresentados na tabela abaixo.

Foram especificadas quatro classes de serviços:
• atualização cíclica de dados;

• atualização não periódica de dados;
• transferência de mensagem com ACK;
• transferência de mensagem sem ACK.
Maior importância foi atribuída aos serviços cíclicos, de forma que não houve
preocupação com uma otimização das demais classes.
ID_DAT
Árbitro
C P C
RP_DAT
Árbitro
C P C
Figura 5.11 - Método de acesso ao meio do FIP. a) Árbitro difunde identificador.

b) Produtor difunde dados pedidos.
PRE FSD EB DFS EB FED EB
FSS FES
PRE — Preâmbulo
FSD — Frame Start Delimiter
EB — Equalization Bit
DFS — Data Frame Sequence (Controle, Dados, FCS)
FSS — Frame Start Sequence
FED — Frame End Delimiter
FES — Frame End Sequence
Figura 5.12 - Formato do quadro do FIP
— 5.22 —
Classe Primitiva de serviço Comentários

Atualização cíclica de dados L_PUT.req/cnf atualiza dados
L_SENT.ind sinaliza envio
L_GET.req/cnf busca de dados
L_RECEIVED.ind sinaliza recepção
Atualização não periódica de dados L_PARAM.req/cnf requisita um dado
Transmissão de mensagem com ACK L_MESSAGE_ACK.req/ind/cnf com reconhecimento
Transmissão de mensagem sem ACK L_MESSAGE.req/ind sem reconhecimento
A Camada de Aplicação
O projeto FIP propõe, a nível da camada de aplicação, um sub-conjunto do MMS

apresentado no projeto MAP, definindo serviços de mensagem industrial que não interferem
com o tráfego de tempo real. Além disso, foi definida uma segunda família de serviços,
denominada MPS ("Message Periodic/Aperiodic Services"), apresentada na tabela a seguir.

Leitura de variáveis A_READ.req/cnf lê nomes de variáveis,
A_READFAR.ind estruturas, status, valores
Escrita de variáveis A_WRITE.req/cnf escreve especificação,
A_WRITEFAR.ind valor, status
Leitura do tipo de variável A_GETOBJECT_DESCRIPTION.req/cnf lê especificação
Acesso à listas de A_READLIST.req/cnf lê e escreve atributos,
variáveis A_WRITELIST.req/cnf valores
Serviços de A_SEND.ind sincronização local e
sincronização A_RECEIVE.ind remota
Funções de gerenciamento da rede
O projeto FIP definiu uma série de funções de gerenciamento de rede, que permitem
coordenar as várias fases do ciclo de vida da mesma. Para inicializar a rede é preciso:
• Configurar a rede (definição de parâmetros, identificadores e listas de objetos, gerar

tabelas de varredura);
• Implementar e testar a configuração.
Durante a operação da rede, é necessário realizar sua manutenção, que inclui:
• Atualização das listas de objetos;

• Atualização das tabelas de varredura;
• Gerenciamento das operações de partida e parada;
• Detecção e correção de falhas;
8.2. A proposta PROFIBUS (PROcess FIeld BUS)
O PROFIBUS (Process Field Bus) foi desenvolvido na Alemanha, inicialmente pela

Siemens em conjunto com a Bosch e Klockner-Moeller em 1987. Em 1988 tornou-se um
"Trial Use Standard" no contexto da norma DIN (DIN V 19245, parte 1), que define as
camadas Física e Enlace. Posteriormente, um grupo de 13 empresas e 5 centros de
pesquisa propuseram alterações nas camadas Física e Enlace e definiram a camada de
Aplicação (norma DIN V 19245, parte 2). O PROFIBUS representa a proposta alemã para a
padronização internacional do fieldbus. Esta proposta é atualmente apoiada por cerca de 110
empresas européias e internacionais (Siemens, ABB, AEG, Bosch, entre outras).
— 5.23 —
Como nas demais redes Fieldbus para aplicações industriais, para atender aos
requisitos de tempo de resposta, o PROFIBUS implementa o modelo de referência ISO/OSI
reduzido a três camadas (1, 2 e 7), descritas a seguir.
A camada física
A camada física do PROFIBUS baseia-se no padrão EIA RS-485 (EIA - Eletronic

Insdustries Association), topologia barramento, utilizando como meio um par trançado
blindado (130 Ohms). Permite a interligação de até 32 elementos (estações ativas, passivas
ou repetidoras) por segmento. São permitidos até 4 segmentos, totalizando assim um
máximo de 122 estações.
A codificação utilizada é a NRZ, podendo ser implementada com uma USART
simples (assíncrona). As taxas suportadas são 9.6, 19.2 e 93.75 kbps para distâncias até
1200 m, 187.5 kbps para distâncias até 600 m e 500 kbps até 200 m.
A camada física oferece duas primitivas de serviço acessíveis à camada de enlace:
PHY_DATA.request (requisição de envio de dados) e PHY_DATA.indication (indicação da
presença de dados).
A camada de enlace
A exemplo da norma IEEE 802, o PROFIBUS define duas subcamadas para a

camada de Enlace de Dados: a subcamada de controle de acesso ao meio (MAC) e a
subcamada de controle de ligação lógica (LLC).
Na subcamada MAC, o PROFIBUS combina dois métodos determinísticos de acesso
ao meio: as estações ditas "ativas" encontram-se em um anel lógico, no qual o direito de
acesso ao meio é repassado ciclicamente por passagem de token (baseado na
especificação IEEE 802.4), enquanto as estações ditas "passivas" comportam-se como
escravas, isto é, só tem acesso ao meio por requisição da estação ativa detentora do token.
O PROFIBUS representa assim uma combinação dos métodos "Master/Slave" e "Token-
Passing" (figura 5.13). O token só é repassado entre as estações ativas.
Estações ativas podem entrar e saír do anel lógico de forma dinâmica, como previsto
na norma IEEE 802.4. O token é repassado na ordem ascendente de endereços, seguindo
uma lista de estações ativas (LAS, List of Active Stations). Esta lista é gerada na inicialização
e atualizada sempre que uma estação entra ou sai do anel lógico.
O PROFIBUS prevê uma série de quadros diferentes, agrupados em duas classes,
uma para transmissão entre estações mais complexas (quadros longos) e outra para
dispositivos de campo simples (quadros curtos). Os quadros previstos incluem:
• quadro longo sem campo de dados;
• quadro longo com campo de dados fixo;
• quadro longo com campo de dados variável;
• quadro curto sem campo de dados;
• quadro curto com campo de dados;
• quadro curto de passagem de token.
Cada quadro é formado por vários caracteres UART. Um caracter UART é composto
de 11 bits: 1 bit de inicio ("start bit"), 8 bits de dados, 1 bit de paridade e 1 bit de finalização
("stop bit"). Em particular tem-se os seguintes campos em cada quadro:
• SD: Start Delimiter (delimitador de inicio de quadro);

• DA: Destination Address (Endereço de destino do quadro);
• SA: Source Address (Endereço de origem do quadro);
• FC: Frame Control (Controle de quadro);
• DATA_UNIT: Dados propriamente ditos;
• FCS: Frame Check Sequence (seqüência de checagem de erros);
• ED: End Delimiter (Delimitador de fim de quadro).
— 5.24 —
O protocolo implementado a nível da camada de enlace é denominado FDL

("Fieldbus Data Link"), que oferece serviços de administração do token, de atualização das
estações e de transferência de dados. Estes últimos são apresentados na tabela abaixo. A
troca de dados é feita em ciclos compostos por um "send-request" de parte da estação ativa
e seguida por um "ack-response" de parte de uma estação passiva ou de outra estação
ativa.
anel lógico
Mestre 1 Mestre 2
token
Escravo Escravo Escravo Escravo

1 2 3 N
Figura 5.13 - Método de acesso ao meio do PROFIBUS

SDN (Send Data with No FDL_DATA envio de dados sem
Acknowledge) reconhecimento
SDA (Send Data with FDL_DATA_ACK envio de dados com
Acknowledge) reconhecimento
RDR (Request Data with FDL_REPLY requisição de dados com
Reply) FDL_REPLY_UPDATE reconhecimento
CRDR (Cyclic Request FDL_CYC_REPLY estação local requisita
Data with Reply) FDL_CYC_DEACT ciclicamente dados ao
FDL_REPLY usuário remoto.
FDL_REPLY_UPDATE
CSRD (Cyclic Send and FDL_SEND_UPDATE estação local envia
Request Data) FDL_CYC_DATA_REPLY ciclicamente e requisita
FDL_CYC_DEACT simultaneamente dados de
FDL_DATA_REPLY resposta.
FDL_DATA_UPDATE
SRD (Send and Request FDL_DATA_REPLY estação local envia e requisita
Data) FDL_REPLY_UPDATE dados.
A camada de Aplicação
Na camada de aplicação foi definido um subset do MMS (ISO 9506), utilizando

primitivas de serviços apropriadas para atender os aspectos específicos do barramento de
campo. A Camada de Aplicação está dividida em três subcamadas:
• Fieldbus Message Specification (FMS), que é o protocolo propriamente dito, derivado

do MMS;
— 5.25 —
• Lower Layer Interface (LLI), responsável pela interface com a camada de Enlace,
mapeando os serviços FMS e FMA (Fieldbus Management) em serviços
correspondentes do FDL;
• Application Layer Interface (ALI), responsável pela interface com as aplicações do
usuário. A ALI opera como solicitador de serviços("Cliente") a um Dispositivo Virtual
de Campo (VFD, Virtual Field Device), que opera como fornecedor de serviços
("Servidor").
O VFD é equivalente ao VMD (Virtual Manufacturing Device) do MMS usado em MAP,

constituindo uma representação abstrata de várias classes de dispositivos reais.
As classes de onjetos definidas são: Variáveis, Domínios, Alarmes, Listas de
Variáveis e Invocações de Programa. Todos os objetos da rede são cadastrados em um
dicionário de dados, denominado OV (Objekt Verzeichniss). Cada estação contem uma
cópia total ou parcial do OV.
São definidos serviços com e sem conexão, cíclicos e acíclicos, entre estações
ativas e entre estas e estações passivas. Os serviços sem conexão são usados para
"Broadcast" e "Multicast" (difusão de quadros entre todas as estações ou entre certos
agrupamentos pré-definidos de estações). Os serviços com conexão são usados para
garantir uma troca de dados confiável.
A tabela a seguir apresenta uma visão geral dos serviços oferecidos, que podem ser
decompostos em três classes: serviços de Aplicação, serviços de Adminstração e serviços
de Gerenciamento de Rede.
Em relação ao MMS, tem-se como novidade os serviços Phy_Read e Phy_Write, que
permitem acesso direto a strings de octetos para os quais não se tenha uma descrição no
OV.
8.3. A proposta ISA SP-50
Os projetos FIP e PROFIBUS contribuíram grandemente para o projeto SP-50

(Standards & Practices 50), em elaboração na ISA (instrumentation Society of America), que
deverá tornar-se a proposta definitiva para o fieldbus padronizado. Os trabalhos de
padronização ainda estão em andamento.
A ISA adotou a terminologia da CCITT, na qual um elemento de comunicação é
composto de duas partes:
• DTE (Data Terminal Equipment), que aqui inclui as funcionalidades das camadas
de aplicação, de enlace e a parte da camada física independente do meio de
transmissão adotado;
• DCE (Data Communication Equipment), que aqui inclui as partes da camada física
que dependem do meio.
A camada Física
A camada física da ISA SP-50 se compõe de três subcamadas (figura 5.14):
• Subcamada DIS (Data Independent Sublayer): atua como interface com a camada
de enlace, recebendo pedidos de serviço desta e repassando os dados recebidos
(DTE);
• Subcamada MDS (Medium Dependent Sublayer): codifica os dados a enviar para
um formato compatível com o meio físico a ser adotado. Por enquanto, somente
foi especificada a subcamada MDS para o par trançado, onde se adota a
codificação tipo Manchester bifásico (DCE);
— 5.26 —
• Subcamada MAU (Medium Attachment Unit): descreve o transceptor propriamente

dito para o meio físico (DCE). Para a camada física foram inicialmente propostos
dois tipos de meio:
Classe Primitivas de serviço Comentários

READ leitura e escrita de
Serviços de WRITE variáveis contidas
Acesso a INFORMATION_REPORT em dispositivos
variáveis PHY_WRITE servidores
PHY_READ
DEFINE_VARIABLE_LIST
DELETE_VARIABLE_LIST
INITIATE_DOWNLOAD_SEQUENCE transferência de
DOWNLOAD_SEGMENT dados ou programas
Serviços de TERMINATE_DOWNLOAD_SEQUENCE de dispositivo cliente
Acesso a INITIATE_UPLOAD_SEQUENCE para dispositivo
Domínios UPLOAD_SEGMENT servidor e vice-versa
TERMINATE_UPLOAD_SEQUENCE
REQUEST_DOMAIN_DOWNLOAD
REQUEST_DOMAIN_UPLOAD
Serviços de CREATE_PROGRAM partida, parada,
Invocação de INVOCATION_DELETE_PROGRAM retorno da execução,
Programas INVOCATION_START retorno ao estado
INVOCATION_STOP inicial e deleção de
INVOCATION_RESUME programas
INVOCATION_RESET
Serviços de ALTER_EVENT_COND._MONITORING servidor notifica
Notificação de EVENT_NOTIFICATION cliente a ocorrência
Eventos ACK_EVENT_NOTIFICATION de um evento
(alarme)
Serviços de STATUS informações acerca
Leitura de Status UNSOLICITED_STATUS do estado dos
STATUS_IDENTIFY dispositivos
servidores
Serviços de GET_OV descrição de todos
Gerenciamento PUT_OV os objetos na rede
de Dicionário de INITIATE_PUT_OV (nomes, endereços,
Objetos TERMINATE_PUT_OV tipos de dados, etc)
INITIATE estabelecimento e
Serviços de REJECT encerramento de
Gerenciamento ABORT associação entre
de Contexto dois dispositivos e a
rejeição de
mensagens
recebidas
• meio H1, para aplicações de baixo desempenho em controle de processos

tradicional, usando par trançado, com taxa de transmissão de 31,25 Kbps e
que é também utilizado para a alimentação dos dispositivos de campo. As
topologias propostas são barramento e estrela;
— 5.27 —
• meio H2, para processos de controle de alta velocidade, com taxa de

transmissão de 1 Mbps, topologia em barramento e distância máxima de 750
m com 30 estações.
Propostas alternativas utilizando fibra ótica e sinais de rádio estão sendo estudadas.
A camada de Enlace
A camada de Enlace oferece quatro classes de funções, a serem implementados

nas estações de acordo com as necessidades:
• funções de "Responder": estação só transmite dados em resposta a uma solicitação

(estação "escrava");
• funções de "Initiator": estação pode se apoderar do direito de acesso ao meio (token),
podendo enviar e requisitar dados a outras estações por iniciativa própria;
• funções de "Linkmaster": inclui as funções de responder e initiator, mas a estação
pode exercer o papel de escalonador de enlace, administrando o token e gerenciando
o tempo interno do sistema (semelhante ao papel do árbitro de barramento do FIP);
• funções de "Bridge": estação capaz de interligar entidades de enlace diferentes;
Se há mais de uma estação com as funcionalidades de um "Link-master" no sistema,

estas disputam entre si na inicialização o papel de escalonador de enlace (árbitro). A estação
vencedora échamada LAS (Link Active Scheduler). Existem, para isto, três tipos de token
(figura 5.15):
• Token de escalonamento: disputado na inicialização por todas as estações

Linkmaster, define a estação LAS.
• Token circulado: distribuído pela estação LAS às demais estações com
funcionalidade de Linkmaster, que formam um anel lógico conforme a norma IEEE
802.4.
• Token delegado: enviado pela estação LAS a uma estação qualquer por solicitação
desta ou para atender às necessidades de um serviço de comunicação escalonado
pela LAS.
Funcionalmente, a camada de Enlace está subdividida em quatro subcamadas,

conforme mostrado na figura 5.16:
Camada de Enlace
DIS
(Data Independent Sublayer)
MDS
(Medium Dependent Sublayer)
MAU
(Medium Attachment Unit)
Figura 5.14 - A camada física do SP-50.
— 5.28 —
LAS
Estação
LM qualquer
Token de Escalonamento
Token Delegado
Token Circulado
LM LM
Figura 5.15 - Operação dos tokens no SP-50.
• Subcamada de acesso a Enlace: estabelece a interface com a camada física,

gerencia o token e serviços de resposta imediata;
• Subcamada de escalonamento de Enlace: providencia as funções de escalonamento
de atividades na própria entidade de enlace. Esta subcamada é mais complexa em
estações com as funcionalidades de Linkmaster e que podem assumir a função de
LAS;
• Subcamada de gerenciamento de conexões: executam todas as funções referentes
ao estabelecimento e rompimento de conexões;
• Subcamada de gerenciamento de Ponte: só existe em estações com funcionalidades
de Bridge.
A camada de enlace oferece quatro classes de serviços às entidades da camada de

aplicação:
• Serviços de gerenciamento de Buffers e filas: através deles, usuários da camada de

enlace podem alocar permanentemente buffers ou filas com profundidade
especificada, a serem usados posteriormente para a transferência de dados;
• Serviços de transferência de dados com conexão: permitem o estabelecimento de
uma conexão e o envio de dados entre estações, garantindo serviços altamente
confiáveis;
• Serviços de transferência de dados sem conexão: permitem o envio de dados sem o
estabelecimento prévio de uma conexão e que, apesar da menor confiabilidade, são
úteis no envio de telegramas de difusão (multicast e broadcast);
• Serviços de escalonamento de transações: permitem programar o árbitro de
barramento (LAS), definindo a seqüência de passagem de token (escalonamento).
A camada de Aplicação
A camada de aplicação do SP-50 ainda se encontra em discussão e procura

conjugar as idéias básicas do MMS, para aplicações sem restrições temporais, com
serviços tipo READ/WRITE inspirados no FIP e que atendem o tráfego cíclico e acíclico com
requisitos de tempo real "duro".
A camada de aplicação prevê, em sua fase atual, os seguintes conjuntos de serviços:
• Serviços MCSE (Message Common Service Element): estabelece e interrompe

conexões entre processos de aplicação (Correspondem aos serviços ACSE da ISO).
— 5.29 —
Camada de
Aplicação
Subcamada de Gerenciamento de Ponte
Subcamada de Gerenciamento de
Conexões
Subcamada de Escalonamento
Subcamada de Acesso a Enlace
Camada Física
Figura 5.16 - A camada de Enlace do SP-50.
• Serviços IMSE (Industrial Message Service Element): serviços semelhantes aos

oferecidos pelo MMS do projeto MAP.
• Serviços DDM (Distributed Database Maintenance): Serviços de acesso à bases de
dados distribuídas.
Camada do Usuário
Uma proposta inovadora no SP-50 é a definição de uma camada do usuário, situada

acima da camada de aplicação, destinada a aliviar o programador de detalhes de acesso ao
sistema de comunicação e a oferecer serviços adequados a diversos tipos diferentes de
aplicações (a semelhança dos "companion standards" propostos no projeto MAP).
Os trabalhos atuais estão restritos a definição de funções para aplicações em
controle de processos, agrupadas na chamada PCUL ("Process Control User Layer").
Outros trabalhos deverão atender as áreas de automação da manufatura, controle predial,
eletrônica embarcada (automóveis), aplicações domésticas, entre outras.
Serviços de Gerenciamento de rede
Além das funcionalidades das camadas já vistas, a proposta SP-50 inclui um

conjunto de funções de gerenciamento de rede, como:
• Gerenciamento de configuração de rede: carregamento, inicialização de endereços,

configuração de comunicação e aplicação, partida, etc;
• Controle de operação: ferramentas de sincronização, escalonamento, etc;
• Monitoração de desempenho: detecção, diagnose e recuperação de erros, avaliação
e otimização de desempenho, etc.
Uma vez definido um padrão internacionalmente aceito, o Fieldbus deverá

revolucionar o setor de instrumentação. Esta tecnologia permite que a inteligência seja
totalmente distribuída pelo campo e favorece o surgimento de dispositivos com capacidades
locais de processamento cada vez mais sofisticadas. A integração total dos equipamentos
permitirá alterações nos procedimentos de operação das plantas industriais. O Fieldbus
deverá também propiciar a intercambiabilidade a nível de sensores, atuadores,
transmissores e controladores, trazendo ao usuário uma maior flexibilidade na compra de
produtos e abrindo espaço para novos fabricantes.
— 5.30 —
Capítulo 6
INTERCONEXÃO DE REDES
1. INTRODUÇÃO
O problema da interconexão aparece no momento em que dois usuários que

necessitam dialogar não estão conectados necessariamente à mesma subrede. Um
exemplo típico deste problema é encontrado nas propostas de comunicação em automação
industrial. Como é sabido, tanto as empresas como as arquiteturas de comunicação de
dados obedecem, geralmente a uma organização hierárquica. As fábricas podem ser
divididas em células, enquanto o setor administrativo pode ser dividido em departamentos,
sessões, divisões, coordenadorias.
Estas divisões são normalmente baseadas no estabelecimento de critérios
funcionais, tendo as funções de cada divisão significado especial na empresa.
As razões que podem conduzir a sistemas integrando diferentes subredes podem
ser de naturezas as mais diversas:
• é muito mais econômico interligar computadores geograficamente próximos

através de uma rede local e compartilhar uma interface única com uma rede
externa do que conectá-los, cada um deles a esta mesma rede externa;
• é tecnologicamente limitante a interconexão (via uma rede local) de um grande
número de computadores separados por grandes distâncias; por exemplo, os
diversos computadores localizados em diferentes prédios de um campus de
universidade... neste caso, é mais interessante interligar os computadores de
cada prédio por uma rede local sendo que as diversas redes locais serão
interconectadas;
• o desempenho e a confiabilidade de um sistema podem ser fortemente
aumentados se, ao invés de interligar um grande número de estações por uma
única rede, esta for particionada em duas ou mais redes; cada rede local
associaria aquelas estações que possuam maior tráfego entre elas, diminuindo
assim o tráfego no suporte de transmissão, sendo que elementos de interconexão
das diversas redes garantiriam a comunicação entre as estações conectadas a
diferentes redes;
• é funcionalmente mais interessante interligar estações que realizem trabalhos
pertencentes a atividades compatíveis por redes locais adequadas ao perfil destas
atividades; as diferentes redes associadas a cada nível de atividade continuariam
a permitir a comunicação entre estações pertencentes a diferentes atividades
através dos elementos de interconexão.
O problema da interconexão é derivado de três questões importantes:
— 6.1 —
CAP. 6 — I NTERCONEXÃO DE REDES PROF. VITÓRIO BRUNO MAZZOLA
• a primeira está relacionada à função de roteamento, dado que, dois equipamentos

envolvidos num diálogo podem não pertencer à mesma subrede;
• a segunda está relacionada com a possibilidade (bastante realista) de que duas
subredes interconectadas não implementem o mesmo protocolo, o que representa
um problema não trivial a ser resolvido;
• a terceira está relacionada com a hipótese de que as duas subredes a serem
interconectadas não sejam baseadas na mesma arquitetura de protocolos; por
exemplo, uma das subredes é não-OSI.
O objetivo desta seção é discutir os principais aspectos associados à interconexão de

subredes, abordando, desde a forma como a interconexão é vista via modelo OSI, até a
resolução das questões apresentadas acima.
2. ASPECTOS DA CONECTIVIDADE
Retornando às duas questões levantadas acima, uma série de pontos técnicos

devem ser resolvidos para possibilitar a interconexão de redes. Vamos discutir alguns destes
pontos a seguir.
2.1. Endereçamento
A função essencial de uma rede de computadores é permitir a troca de informações

entre os equipamentos a ela conectados. Dada a possibilidade de interligação de
equipamentos heterogêneos, torna-se necessária a definição de uma política de
representação dos nomes e endereços dos processos, que sejam reconhecidos em
qualquer ponto da rede. Uma forma de fazê-lo é permitir que os usuários possam ser
identificados por nomes (ou cadeias de caracteres). Isto significa que os nós da rede devem
manter tabelas que efetuem o mapeamento entre os nomes dos processos usuários da rede
e os seus endereços.
Entretanto, quando duas ou mais subredes são interconectadas, os padrões de
endereçamento podem ser distintos e um meio de identificar (de maneira transparente) os
processos situados nas diferentes subredes deve ser implementado.
A política adotada para resolver esta questão é aquela do endereçamento hierárquico,
como por exemplo a definida pelo CCITT, onde cada endereço apresenta três componentes:
um código de país (3 dígitos), um código da rede (1 dígito) e um campo para o endereço
dentro da rede (10 dígitos). Isto significa que cada país pode definir até 10 redes, cada rede
tendo 10 dígitos para definir seus endereços, o formato dependendo de cada rede.
2.2. Encaminhamento das mensagens
Este aspecto está diretamente ligado às funções de roteamento implementadas na

camada de Rede. A questão colocada aqui está relacionada com a forma de
encaminhamento de uma mensagem quando esta é trocada entre dois equipamentos
situados em subredes distantes. Um aspecto a ser ressaltado aqui é o problema de
roteamento, já abordado anteriormente (camada de Rede), sendo que alguns dos algoritmos
de roteamento foram lá apresentados.
2.3. A fragmentação de mensagens
Este é um outro problema importante, dado que diferentes subredes podem trabalhar
com tamanhos distintos de mensagens (os tamanhos máximos). É óbvio que uma solução
seria limitar o tamanho máximo das mensagens podendo transitar em todas as subredes
como sendo o menor tamanho máximo de todas as subredes... mas esta é uma solução
pouco eficiente.
— 6.2 —
A solução mais interessante é a seguinte... quando uma mensagem deve transitar

entre diferentes subredes, se ela ultrapassa o tamanho máximo da subrede pela qual ela vai
transitar, esta é decomposta em várias mensagens (ou fragmentos), cujas dimensões serão
adaptadas às limitações da subrede considerada. É evidente que, caso estes fragmentos
sejam enviados a uma nova subrede que suporte o tamanho máximo da subrede de origem,
estes poderão ser reagrupados para recompor a mensagem original.
Estes são alguns dos pontos a serem discutidos no momento em que um elemento
deve ser projetado para a interconexão de duas subredes. Outros pontos não menos
importantes são: o controle de erros, o tipo de serviço (orientado conexão ou não), o nível da
interconexão, o controle de fluxo, o controle de congestionamento, a segurança, a tarifação
de serviços.
3. A INTERCONEXÃO SEGUNDO O MODELO OSI
Antes de estudarmos os elementos responsáveis da interconexão de redes, vamos

analisar a abordagem do modelo OSI no que diz respeito a este problema particular.
Segundo o que foi estabelecido no modelo OSI no que diz respeito à interconexão, a camada
de Rede, que assume a resolução destes problemas, pode ser subdividida em três
subcamadas, como mostra a figura 6.1: a subcamada de acesso à subrede, a subcamada
de adaptação da subrede e a subcamada de interconexão.
A primeira subcamada, representada pelos níveis 3a na figura 6.1, é responsável do
gerenciamento do protocolo da subrede considerada, assumindo a recepção e o envio dos
pacotes de controle e implementando as funções de base da camada de Rede.
A segunda subcamada, representada por 3b em 6.1, é responsável de todas as
adaptações necessárias entre as subredes interconectadas.
Finalmente, a terceira subcamada, 3c em 6.1, é a que implementa efetivamente a
interconexão das subredes responsabilizando-se pelo roteamento entre as subredes.
As diferenças entre as subredes interconectadas podem ser de diferentes naturezas.
No caso de subredes conformes ao modelo OSI, a interconexão é feita apenas através da
transmissão, via subcamada de interconexão dos pacotes às subcamadas de acesso à
subrede da subrede considerada. Neste caso, a função da subcamada de adaptação é
inexistente, esta camada sendo então vazia.
Por outro lado, se uma rede não-OSI deve ser interconectada a uma baseada no
modelo OSI, as adaptações deverão ser implementadas, isto sendo função daquela
subcamada. A tarefa de roteamento de subrede a subrede é similar àquela a nível de uma
única subrede, o que significa que as técnicas apresentadas na seção 3 podem ser
utilizadas.
sistema A sistema B
4a7 4a7
relay
3c 3c'
3c'
3b 3b 3b' 3b'
3a 3a' 3a'
3a
2 2 2 2
1 1 1 1
subrede 1 subrede 2
Figura 6.1 - Estrutura interna da camada de rede do ponto de vista da interconexão, segundo o OSI.
— 6.3 —
4. AS DIFERENTES POSSIBILIDADES DE INTERCONEXÃO
A figura 6.2 ilustra diferentes possibilidades de interconexão de redes (locais ou de

longa distância). Em cada caso, é necessário introduzir um elemento intermediário ou relay,
responsável das adaptações de protocolo que sejam necessárias, podendo ser uma ponte
(ou bridge) ou passarela (gateway), dependendo do tipo de interconexão.
Saindo um pouco do contexto do modelo OSI, no caso mais geral, a tarefa efetuada
pelos relays pode ser implementada em qualquer camada, os quatro tipos de relays mais
comuns sendo:
• os repetidores (repeaters), implementados no nível físico, que permitem

unicamente amplificar e retransmitir os sinais elétricos representando os bits de
dados entre dois segmentos de cabo;
• as pontes (bridges), implementadas no nível enlace, que efetuam o
armazenamento e retransmissão dos quadros entre redes locais; a retransmissão
do quadro pode ser caracterizada por algumas modificações nos formatos dos
quadros, se necessário;
• os roteadores (routers), implementados no nível rede, que retransmitem pacotes
entre duas redes;
• os gateways (gateways), implementados ao nível aplicação, cuja tarefa é bem
mais complexa que as dos elementos anteriores, utilizados para a interconexão de
subredes incompatíveis até mesmo do ponto de vista da arquitetura (redes OSI x
redes não-OSI).
Apresentaremos, a seguir, algumas características importantes das pontes,

roteadores e gateways, elementos dos mais utilizados na tarefa de interconexão de redes.
5. AS PONTES (BRIDGES)
Se duas subredes apresentam compatibilidade em relação à camada de enlace de

dados, uma ponte pode ser utilizada para interconectá-las.
Uma ponte é um equipamento inteligente (baseado em microprocessador) conectado
a duas subredes ou entre uma subrede e a backbone. Dado que as duas redes estão
conectadas à ponte utilizam a mesma política de endereçamento na camada 2 do modelo
OSI, ela examina os endereços de ambas as redes para definir que mensagens devem ser
passadas de uma rede à outra.
LAN
G WAN
G
LAN LAN
B G WAN G
LAN-LAN WAN-WAN B BRIDGE
LAN-WAN LAN-WAN-LAN G GATEWAY
Figura 6.2 - Possibilidades de interconexão de redes.
— 6.4 —
As pontes são bidirecionais por natureza, o que significa que elas são responsáveis
do encaminhamento de todos os pacotes emitidos ao nível das duas redes. A figura 6.3
ilustra a forma de interconexão através de uma ponte.
A operação de uma ponte é baseada na manutenção de uma tabela contendo os
endereços dos equipamentos compondo a rede à qual ela está associada.
Quando um pacote é recebido, esta examina o conteúdo do campo “endereço do
destinatário” para verificar se ele está endereçado a um equipamento desta rede ou não.
Em caso positivo, o pacote é encaminhado ao equipamento considerado. Caso
contrário, este será despachado para uma ponte associada a uma outra subrede, sendo
que, esta, por sua vez, realizará o mesmo tipo de verificação, através de consulta à sua
tabela. Normalmente, as pontes implementam um algoritmo de "aprendizagem", utilizado
para inicializar a tabela de endereçamento existente em cada uma delas.
Do ponto de vista do desempenho, as pontes são elementos de interconexão que
apresentam um tempo de resposta relativamente mais curto, uma vez que, em grande parte
de sua operação, os pacotes não sofrem nenhum processo de reformatação para serem
despachados.
Um caso bastante comum encontrado nas empresas é a necessidade de
interconexão de redes Ethernet com as redes do tipo Token Ring (Anel com Ficha). Um
primeiro problema a resolver, neste caso, é a grande diferença estrutural dos pacotes
utilizados por cada um destes tipos de rede.
Uma rede Ethernet utiliza pacotes cujo tamanho não deve ultrapassar os 1.500 bytes;
uma rede Token Ring a 4 Mbit/s pode transmitir pacotes de até 4.000 bytes. Uma ponte
orientada à interconexão destes dois tipos de rede deve, então, oferecer a possibilidade de
segmentação dos pacotes de grandes dimensões das redes Token Ring em pacotes
menores da Ethernet.
Dado que, no modelo OSI, a independência de redes é uma das características
enfatizadas, é bem possível que as duas subredes utilizem suportes de transmissão
(camada física) distintos. Um exemplo disto é a possibilidade do estabelecimento de
interconexões por pontes nas arquiteturas MAP/TOP. Por utilizar a mesma camada de
enlace (IEEE 802.2), as duas arquiteturas podem ser interconectadas, apesar de uma (MAP)
utilizar o suporte de transmissão em banda larga e a outra (TOP) utilizar banda básica.
SUBREDE A SUBREDE B
Camada 7 Camada 7
Camada 6 Camada 6
Camada 5 Camada 5
Camada 4 Camada 4
Camada 3 PONTE Camada 3
Camada 2 Camada 2 Camada 2 Camada 2
SUBREDE A PONTE SUBREDE B
Figura 6.3 - Ponte interconectando duas sub-redes (nível Enlace).
— 6.5 —
Na filosofia do modelo OSI, uma ponte pode interconectar duas redes quaisquer,
desde que estas sejam totalmente compatíveis em suas camadas de enlace de dados
(principalmente, no endereçamento). Ainda deste ponto de vista, dois usuários finais não
precisam tomar conhecimento da existência de uma ponte na rede; esta é vista como um
equipamento "observador" nas redes às quais ela está conectada. Sua função é monitorar
todo pacote que circula em cada uma das redes à qual ela está associada.
6. OS ROTEADORES (ROUTERS)
Como foi dito acima, as pontes são equipamentos que permitem interconectar as
subredes, duas a duas. Apesar de sua grande utilidade neste caso bastante comum, as
pontes apresentam limitações que impedem outras maneiras também importantes de
interconexão.
Os roteadores são elementos operando ao nível de Rede, que se utilizam do
endereçamento definido a este nível para transferir e rotear as mensagens de uma rede a
outra. Ao contrário das pontes que interligam as subredes duas a duas, os roteadores
podem interligar duas ou mais subredes, sendo que a escolha de que linha utilizar é feita
com base na execução de um algoritmo de roteamento, como já discutido anteriormente
(camada de Rede).
A política de endereçamento implementada a nível da camada de Rede é bastante
similar à codificação de números telefônicos numa rede de telefonia. Se alguém, por
exemplo, quer fazer uma chamada telefônica de Florianópolis para Paris, ele deve discar
inicialmente (após o código de discagem direta internacional) o código do país (no caso, 33
para a França), em seguida, o código da cidade (1, para Paris) e, finalmente, o número do
telefone da pessoa com quem ele vai querer dialogar. No modelo OSI, o esquema de
endereçamento é definido de forma a cobrir os múltiplos formatos de endereçamento de
rede (ver parte relativa à camada de Rede).
SUBREDE A SUBREDE B
Camada 7 Camada 7
Camada 6 Camada 6
Camada 5 Camada 5
Camada 4 Camada 4
ROTEADOR
SUBREDE B
SUBREDE A ROTEADOR
SUBREDE D
SUBREDE C
Figura 6.4 - Roteador interligando duas subredes.
— 6.6 —
Uma das desvantagens das pontes que é o fato de que, todo pacote transitando ao
longo das subredes é recebido por cada uma das estações conectadas a estas subredes,
implicando, em condições normais, num aumento considerável de tráfego. Ainda, a
possibilidade de um congestionamento não está muito distante uma vez que uma interface
de rede em pane poderá despejar uma grande quantidade de pacotes incompatíveis na rede.
Ao contrário das pontes, um roteador não tem necessidade de analisar todos os
pacotes circulando na rede. Isto significa que, no caso dos roteadores, o problema descrito
acima pode ser evitado pois eles seriam capazes de bloquear aqueles pacotes que não
obedecessem a um determinado perfil.
É um equipamento bastante poderoso, dado que ele pode interconectar um número
relativamente grande de redes, de uma forma transparente ao usuário do serviço. Em
aplicações onde haja necessidade de interligação de mais de duas subredes, um roteador
deverá certamente o elemento escolhido para realizar a conexão (em lugar de uma ponte).
Em aplicações industriais, por exemplo, um bom número de empresas se
caracteriza por possuir suas usinas, fornecedores, depósitos, lojas de venda, etc... em
locais geograficamente dispersos. A fim de trocar informações entre estes setores, a
conexão das diversas redes locais a uma rede de longa distância pode ser viabilizada
através de um roteador.
Um papel importante desempenhado pelos roteadores está na interconexão de redes
heterogêneas. Quando um pacote pertencente a uma subrede implementando um protocolo
X deve ser encaminhado a uma subrede implementando um protocolo Y, o roteador deverá
realizar as conversões de formato necessárias para que o pacote seja encaminhado
respeitando os requisitos impostos pelo protocolo Y. A interconexão entre subredes através
de um roteador é ilustrada na figura 6.4.
7. AS PASSARELAS (GATEWAYS)
Os gateways são os elementos de interconexão de concepção mais complexa. A sua

importância no que diz respeito às necessidades de interconexão das redes é o fato de que
nem todas as redes de comunicação implantadas e em funcionamento atualmente foram
construídas com base no modelo OSI, muitas soluções "proprietárias" e "padrões de fato"
sendo adotados na forma de redes locais.
Isto significa que está longe do incomum a necessidade de interligação de redes
baseadas no modelo OSI com redes não-OSI. Isto requer, então, a construção de um
equipamento de interconexão que seja capaz de compatibilizar as diferenças estruturais e de
protocolo existentes entre as duas redes. Este equipamento é o gateway.
REDE MAP (OSI) GATEWAY REDE SNA

TRADUTOR
Aplicação Aplicação Usuário Usuário
Apresentação Apresentação serviços NAU serviços NAU
Fluxo Dados Fluxo Dados

Sessão Sessão
Controle Controle
Transporte Transporte Transmissão Transmissão
Controle Controle
Rede Rede
Caminho Caminho
Controle Controle
Enlace Enlace
Enlace Enlace
Física Física Ligação Ligação

Física Física
Figura 6.5 - Interconexão baseada em gateway.
— 6.7 —
Os gateways são elementos que devem possuir duas pilhas de protocolos, um sendo
baseado na arquitetura a 7 camadas do modelo OSI e o outro, baseado na arquitetura
proprietária considerada.
Normalmente, os gateways são construídos com uma orientação a uma dada
aplicação, como, por exemplo, a interconexão entre uma rede proprietária e uma rede MAP.
Outro exemplo disto é a interconexão de uma rede SNA (rede proprietária da IBM) na qual um
mainframe IBM está interconectado com uma rede MAP.
O gateway a ser construído para realizar esta conexão deveria possuir as 7 camadas
(OSI-like) definida pela arquitetura MAP, um programa de aplicação para realizar a
transferência de arquivos, e um conjunto de protocolos necessários para a comunicação
dentro da rede SNA.
— 6.8 —
Capítulo 7
ENGENHARIA DE P ROTOCOLOS
1. INTRODUÇÃO
A concepção de uma arquitetura de comunicação consiste basicamente do projeto e

implementação das entidades de protocolo associadas a cada uma de suas camadas, de
modo que estas ofereçam completamente os serviços para os quais elas foram definidas.
Esta tarefa deve levar em conta a adoção de uma metodologia que permita produzir o
software necessário, uma metodologia podendo ser caracterizada pelos mais diversos
aspectos: as diferentes etapas a serem realizadas, os conceitos fundamentais, as técnicas
existentes, as ferramentas suportando as diferentes etapas, etc_
À concepção realizada sob tais condições, ou seja, com a utiização de um
metodologia orientada ao problema dos protocolos, chamamos Engenharia de Protocolos,
que pode ser vista como uma aplicação dos conceitos e métodos da Engenharia de
Software à concepção de protocolos de comunicação.
Neste documento, serão apresentados os principais conceitos da Engenharia de
Protocolos, particularmente, as principais etapas da concepção de uma entidade de
protocolo, as diferentes técnicas orientadas a cada etapa, as ferramentas existentes para a
concepção dos protocolos.
2. AS ETAPAS DE CONCEPÇÃO DOS PROTOCOLOS DE COMUNICAÇÃO
O objetivo da concepção de uma camada de protocolos é gerar um programa

concretizando uma entidade de protocolos que ofereça os serviços requeridos para o nível
considerado. A concepção deve ser realizada, seguindo um conjunto de procedimentos, ou
etapas, que permitam atingir este objetivo num menor tempo e com um maior grau de
confiabilidade e de «conformidade», esta segunda característica sendo definida mais à
frente.
A concepção de uma camada de protocolo segue os mesmos procedimentos
definidos pelas técnicas de Engenharia de Programação, onde as principais etapas são:
• a etapa de análise de requisitos, onde são levantados todos os pontos relativos ao

problema a ser resolvido, o resultado deste levantamento sendo a realização de
uma especificação funcional;
• a etapa de projeto, caracterizada pela realização de uma especificação detalhada,
descrevendo, se possível, de maneira não ambígua, o comportamento de cada
componente do software a ser realizado e as suas interações para a resolução dos
problemas levantados na primeira etapa;
• a etapa de implementação, que consiste na geração e implantação do código
executável, o software devendo ser o mais fiel possível do que foi definido na
especificação detalhada;
— 7.1 —
CAP. 7 — ENGENHARIA DE PROTOCOLOS PROF. VITÓRIO BRUNO MAZZOLA
• a etapa de manutenção do software, onde atualizações podem ser introduzidas de

modo a se obter novas versões, mais eficientes e mais completas do programa.
A figura 7.1 ilustra estas etapas e as possíveis interações durante o processo de

desenvolvimento do programa.
A concepção dos protocolos, no entanto, representa um caso particular da
concepção de um programa distribuído, apresentando especificidades que devem ser
levadas em conta em cada etapa do processo, técnicas e ferramentas tendo sido definidas
para esta classe de problemas.
A Engenharia de Protocolos tornou-se um tema de pesquisa bastante amplo, os
principais trabalhos desenvolvidos estando orientados à definição de técnicas de
especificação de protocolos, à definição de metodologias de validação (simulação e
verificação) de protocolos, à implementação de camadas de protocolos a partir de
especificações formais, à geração de sequências e métodos de teste de protocolos.
As seções que seguem apresentarão os principais elementos de cada uma das
atividades relacionadas à concepção dos protocolos de comunicação, particularmente no
que diz respeito à especificação, validação, implementação e testes de protocolos.
3. A ESPECIFICAÇÃO DE PROTOCOLOS DE COMUNICAÇÃO
Os protocolos de comunicação são definidos e apresentados pelas organizações de

normalização, na forma de documentos (normas) definindo os principais aspectos
relacionados ao funcionamento do protocolo, o formato das unidades de dados, os serviços
oferecidos, etc_
especificação
informal dos
requisitos
realização da ANÁLISE DE
especificação validação da REQUISITOS
funcional especificação
funcional
especificação
funcional
realização da definição de
especificação validação da sequências
sequências
detalhada especificação de teste
de teste
detalhada
PROJETO
especificação
detalhada
teste do
código de
implementação
geração do
código de validação do
implementação código de
implementação
código de IMPLEMENTAÇÃO
implementação
Figura 7.1 - As atividades de desenvolvimento do software.
— 7.2 —
Estes aspectos, na grande maioria dos documentos (com raras exceções), são
apresentados em linguagem natural, podendo conduzir, muitas vezes a implementações
diferentes e incoerentes de uma mesma norma.
A importância da etapa de especificação está no fato de que, uma vez que ela vai
servir de referência para a etapa de geração do código de implementação, ela deve eliminar,
por um lado, a totalidade ou grande parte das ambigüidades que possam surgir no que diz
respeito aos pontos de funcionamento do protocolo, isto sendo possível graças à utilização
de técnicas apropriadas de especificação.
3.1. Aspectos da especificação dos protocolos de comunicação
Como foi visto nas partes precedentes do documento, os protocolos de comunicação

são organizados segundo uma estrutura hierárquica de diferentes camadas. A especificação
dos protocolos, deve levar em conta, num primeiro tempo, os seguintes aspectos:
• o serviço a ser oferecido por uma dada camada de protocolos, levando em conta
as propriedades locais do ponto de vista de um único ponto de acesso a serviço
(SAP), assim como as propriedades globais, levando em conta a existência de
vários SAPs;
• o protocolo a ser implementado pelas entidades de protocolo de uma dada
camada, principalmente o comportamento interno das entidades;
• a interface, através da qual o serviço é oferecido num ponto de acesso ao serviço
particular.
A figura 7.2 ilustra os aspectos apresentados acima. Em 7.2(a), a camada de

protocolo é vista como uma caixa preta, cujos serviços serão acessados através dos SAPs;
em 7.2(b), o comportamento de uma entidade de protocolo, vista inicialmente como uma
caixa preta, será o ponto abordado.
Do ponto de vista das interações de usuários e fornecedores de serviço, deve-se
levar em conta ainda as primitivas de serviço, caracterizadas por parâmetros que podem
incluir informações de controle e dados de usuário e as unidades de dados de protocolo ou
PDUs , trocadas entre entidades de protocolos pares. É importante lembrar aqui que, de
fato, as PDUs não são trocadas diretamente entre duas entidades de protocolo de um
mesmo nível, mas conduzidas através das primitivas de serviço das camadas inferiores. A
figura 7.3 ilustra este aspecto, a parte superior da entidade representando a PDU
propriamente dita, a parte inferior representando o seu mapeamento nas primitivas de
serviço da camada inferior.
pontos de acesso
ao serviço (SAPs)
entidade de
protocolo
CAMADA DE PROTOCOLO
(a) (b)
Figura 7.2 - (a) especificação do serviço oferecido por uma camada; (b) especificação do
comportamento de uma entidade de protocolo.
— 7.3 —
PDUs
entidade de
protocolo
camada
inferior
Figura 7.3 - Relação entre PDUs e primitivas de serviço.
Um exemplo da representação destes aspectos pode ser visto na figura 7.4, onde
uma especificação da camada de Transporte do modelo OSI é proposta. Pode-se notar as
duas entidades de Transporte que oferecem o serviço de Transporte através dos pontos de
acesso a serviço, respectivamente TSAP1 e TSAP2. Estas entidades trocam suas PDUs
utilizando o serviço de Rede, oferecido pela camada inferior nos pontos de acesso a serviço
correspondentes, respectivamente, NSAP1 e NSAP2.
As possíveis interações entre usuários da camada de Transporte, entidades de
Transporte e a camada de rede podem ser expressas na forma de um diagrama de tempo
como mostra a figura 7.5.
Os pontos apresentados até aqui representam aspectos arquiteturais da
especificação, os aspectos de comportamento devendo também ser levados em conta.
Os aspectos de comportamento a serem levados em conta no momento de uma
especificação são:
• o sequenciamento temporal das interações, de modo a definir a ordem na qual as

operações devem ser efetuadas, incluindo também os diferentes tipos de
interações (primitivas de serviço, PDUs) e as regras de ordenação associadas a
cada tipo; ainda, devem ser levadas em conta as questões de envio ou recepção
de uma interação;
TSAP1 TSAP2
ENTIDADE ENTIDADE
DE DE
TRANSPORTE TRANSPORTE
1 2
NSAP1 NSAP2
SERVIÇO DE REDE
Figura 7.4 - Exemplo de uma arquitetura de comunicação oferecendo um serviço de Transporte.
— 7.4 —
TSAP1 NSAP1 NSAP2 TSAP2
TCON.req
CR
TCON.ind
TCON.rsp
CC
DATA (SDU)
TCON.cnf DT
DT
AK
DATA (SDU)
Figura 7.5 - Diagrama de tempo ilustrando as diferentes interações para o exemplo da figura anterior.
• os possíveis valores dos parâmetros de uma interação, que vai permitir tipos e
valores a serem associados a cada um dos parâmetros de uma primitiva de
serviço ou PDU;
• as regras de interpretação e seleção de valores dos parâmetros das interações,
que permite definir o significado de cada parâmetro de uma primitiva de serviço ou
PDU; assim como o comportamento a ser assumido por uma entidade em função
de valores de determinados parâmetros;
• a codificação das PDUs, definindo a estrutura de dados que vai permitir representá-
las;
• as propriedades do protocolo, que permitirão definir que regras devem ser
satisfeitas pelas entidades para que o protocolo progrida; ou ainda, propriedades de
tempo real, que permitem associar medidas quantitativas sobre o protocolo
(desempenho).
Resumindo, a especificação de um protocolo de comunicação deve levar em conta

estas duas classes de características: as estruturais, que permitem definir a composição de
uma camada em termos de entidades de protocolo e as suas interações; e as de
comportamento, que permitem conhecer o comportamento de uma entidade e como ela vai
provocar e reagir perante os diferentes eventos relacionados ao funcionamento do protocolo.
A representação destas características pode ser feita segundo diferentes técnicas e
modelos, uma descrição de algumas delas sendo apresentada na seção que segue.
3.2. Técnicas de especificação de protocolos
Muitas especificações de protocolos de comunicação, particularmente aqueles

definidos nos órgãos de normalização, utilizam a linguagem natural para expressar os
aspectos apresentados na seção anterior. A razão deste aspecto é o fato de que a
linguagem natural é o meio mais próximo de conduzir a informação ao leitor de um tal
documento. No entanto, para fins de desenvolvimento de um protocolo, é mais interessante
que a etapa de especificação seja suportada por um modelo que permita expressar, de
maneira mais formal, os mecanismos a serem implantados a nível de uma entidade de
protocolo, isto pelas duas razões seguintes:
• a linguagem natural pode conduzir à geração de implementações contendo

ambigüidades ou incoerências e não permitem a realização de validação e testes;
— 7.5 —
• não permite automatizar o processo de desenvolvimento do protocolo, seja para a

validação, a implementação ou o teste pois elas não podem ser suportadas por
ferramentas automatizadas.
Os trabalhos de pesquisa no sentido de definir e aplicar modelos para a

especificação de protocolos de comunicação iniciaram há muitos anos atrás, mesmo antes
da definição do modelo OSI. Estes conduziram à definição de diversos modelos e técnicas,
mais ou menos poderosos na definição, mais ou menos adequados à representação de um
subconjunto dos aspectos apresentados na seção 3.1.
Exemplos destas técnicas são as máquinas de estado finito, as gramáticas formais,
as redes de Petri, os cálculos algébricos, os tipos abstratos de dados, a lógica temporal e as
técnicas de descrição formal. Algumas destas técnicas poderiam ser organizadas segundo
o modelo matemático sobre o qual são fundadas. Algumas técnicas de descrição formal, por
exemplo, combinam o modelo de máquinas de estado finito com o poder de expressão de
manipulação de dados das linguagens de programação de alto nível (Estelle, por exemplo).
A seção que segue apresenta, através de um exemplo simples, a utilização de
algumas das técnicas citadas acima para a especificação dos protocolos de comunicação.
3.3. Um exemplo de especificação de protocolo de comunicação
A figura 7.6 apresenta a arquitetura de um protocolo de comunicação a ser

considerado na seção. O protocolo define uma relação mestre-escravo (ou cliente-servidor)
entre uma entidade fonte e uma entidade destino comunicando-se em half duplex.
O comportamento das duas entidades, fonte e destino é apresentado, na forma de
fluxogramas na figura 7.7. Como se pode ver na figura, o par de mensagens pedido envio e
pronto p/ recepção é relacionado à fase de controle; o par envio dado e dado consumido é
relacionado à fase de dados.
Ainda, os eventos diretamente relacionados ao protocolo são as chegadas das
mensagens pronto p/ recepção e dado consumido. O evento dado a enviar é considerado
como interno à entidade fonte, portanto, fora do retângulo pontilhado da figura 7.6.
O par de fluxogramas da figura 7.7 não deixa de ser um modelo do protocolo
analizado. Nos parágrafos a seguir, vamos introduzir e aplicar duas das técnicas conhecidas
para a especificação do protocolo exemplo: as máquinas de estado finito e as redes de Petri.
O modelo de máquina de estado finito é baseado sobre uma 5-tupla
<X,I,O,N,M> , onde:
FONTE DESTINO
Figura 7.6 - Arquitetura do exemplo de protocolo de comunicação.
— 7.6 —
dado a
não enviar ?
sim
obtém dado pronto
PEDIDO ENVIO pedido

notifica destino
envio ? não
sim
prepara recepção
destino PRONTO P/ RECEPÇÃO

não pronto ? notifica fonte
sim
envio dado
ENVIO DADO chegada

notifica destino dado ? não
sim
leitura dado
dado DADO CONSUMIDO

não recebido ?
notifica fonte
sim
FONTE DESTINO
Figura 7.7 - Representação das entidades de protocolo (fluxograma).
X é um conjunto finito de estados;

I é um conjunto finito de entradas;
O é um conjunto finito de saídas;
N é uma função de transição de estado (N: I x X → X)
M é uma função de saída (M: X x I → O)
As funções N e M permitem expressar o comportamento da máquina de estados em

função dos eventos de entrada. Se, de um dado estado, um ou mais eventos de entrada
ocorrem, estas funções vão permitir, respectivamente, gerar o novo estado da máquina e as
saídas (se for o caso) correspondentes ao evento.
No modelo, além de eventos de entrada e saída, que pertenceriam, respectivamente,
aos conjuntos I e O, deve-se considerar, como elementos do conjunto I, a ocorrência de
eventos internos para permitir especificar a ocorrência de eventos não especificados a nível
do sistema a representar (no caso, o protocolo), mas que podem ser importantes para o seu
comportamento.
Uma máquina de estados finitos pode ser representada segundo diversos métodos,
dentre os quais o diagrama de transição de estado. A figura 7.8 apresenta os dois diagramas
de estado gerados para o protocolo sob análise.
— 7.7 —
OCIOSO
Ei1
OCIOSO
!pedido envio
?pedido envio
PRONTO P/
ENVIO !pronto p/ recepção
?pronto p/ recepção RECEPÇÃO
ENVIO ?envio dado

Ei2
!envio dado CONSUMO

DADO
Ei
ESPERA
ACK !dado consumido
?dado consumido
FONTE DESTINO
Figura 7.8 - Máquinas de estado finito para as entidades fonte e destino do protocolo considerado.
Estes foram construídos com base nos fluxogramas da figura 7.7 e obedecendo aos
seguintes critérios:
• para a entidade fonte, foram considerados dois eventos internos: Ei1 e Ei2,
respectivamente para representar a chegada de um dado a enviar e o fim da
transmissão do dado;
• para a entidade destino, foi considerado um evento interno, Ei, que representa o
final da recepção de um dado.
A máquina de estados que representa a entidade fonte é composta de 4 estados

(ocioso, pronto p/ envio, envio e espera ack). A entidade destino é representada por uma
máquina de estados composta dos estados ocioso, recepção e consumo dado. Outros
estados poderiam ainda ser definidos no modelo, como por exemplo, na entidade fonte,
poderia-se introduzir um estado preparando dado entre os estados ocioso e pronto p/ envio.
Isto, porém, corresponderia não unicamente à representação do protocolo mas também à
detalhes da implementação da entidade.
A rede de Petri é o modelo também bastante utilizado para a representação dos
aspectos ligados aos protocolos de comunicação. Este modelo é baseado na definição de
lugares (representando condições) e transições (representando eventos) conectados
através de arcos direcionados (por flechas). Os lugares sendo conectados a por um arco
dirigido para uma transição são ditos lugares de entrada da transição. Os lugares
conectados às transições através de arcos direcionados para eles são denominados os
lugares de saída da transição.
O estado de uma rede de Petri é definido como sendo a posição de elementos,
denominados ficha (em inglês, token), no interior dos lugares. Num dado instante, um lugar
pode conter zero, uma ou mais fichas. A figura 7.9(a) mostra a representação gráfica das
definições relacionadas ao modelo.
De uma forma geral, a execução de uma rede de Petri obedece a um conjunto de
regras denominadas regras de tiro das transições, que são as seguintes:
— 7.8 —
lugares de entrada
ficha
transição
lugares de saída
(a) (b)
Figura 7.9 - Princípio das redes de Petri: (a) antes do tiro; (b) depois do tiro.
• uma transição é dita habilitada (ou sensibilizada) se cada um dos seus lugares de
entrada possui pelo menos uma ficha;
• o tiro de uma transição consiste da remoção de uma ficha de cada lugar de entrada
e a adição de uma ficha em cada lugar de saída da transição;
• o tiro de uma transição toma um tempo nulo, mas pode não ocorrer imediatamente.
Matematicamente, uma rede de Petri pode ser representada por uma 4-tupla
C = (P,T,I,O), onde:
P é o conjunto de lugares (condições) P = {p1, p2, _, pN}

T é o conjunto das trasições (eventos) T = {t1, t2, _, tN}
I é a função entrada I(tk )= {pi, pj, _}
O é a função saída O(tk )= {pm , pn, _}
A figura 7.10 mostra as redes de Petri obtidas para o protocolo considerado. Da

mesma forma que para o modelo de máquinas de estados finitos, os eventos internos são
representados:
• o evento interno Ei1 (entidade fonte) é aqui representado pela chegada de uma
ficha no lugar B;
• o evento interno Ei2 (entidade fonte) é representado pelo tiro da transição t3;
• o evento Ei (entidade destino) é representado por pela transição representando
uma interação com o ambiente.
A distribuição das fichas ao longo dos lugares de uma rede de Petri (que, como foi
dito anteriormente, define o estado da rede) é denominada marcação. A partir de uma
marcação inicial é possível construir (manualmente ou automaticamente) o conjunto das
marcações acessíveis desta. A este conjunto, que pode ser também ser representado
graficamente, dá-se o nome de grafo de marcações. A análise do grafo de marcações é um
elemento importante na verificação de propriedades de uma rede de Petri, permitindo
analizar os principais aspectos do comportamento do sistema (no caso, o protocolo de
comunicação) modelizado. No caso do protocolo considerado, a marcação inicial da rede
corresponde a uma ficha no lugar A e outra no lugar A’.
3.4. Especificação do serviço de comunicação
O exemplo considerado na seção anterior levou em conta a existência de um serviço

de comunicação (ou um meio de transmissão) perfeito, sem perda de mensagens,
duplicação, erros, etc_
— 7.9 —
A B
1 ta
t1 A'
B'
D tb
C
2
t2
3 tc D'
t3
C'
E'
F'
G td
F
4
t4
FONTE DESTINO
Figura 7.10 - Representação em rede de Petri do protocolo considerado.
Dependendo do nível do protocolo a especificar, no entanto, pode ser necessário

levar em conta a possibilidade de tais eventos ocorrerem. Assim, a incorporação destes
aspectos relativos ao funcionamento do suporte de comunicação utilizado para a troca de
informação entre duas entidades de protocolo pode tornar-se um aspecto importante na
análise do protocolo.
Considerando o exemplo da seção anterior, a introdução do comportamento do
serviço de comunicação (meio de transmissão, neste caso), a estrutura da especificação
teria de ser revista, assumindo o aspecto apresentado na figura 7.11.
No que diz respeito à especificação do comportamento, esta deve levar em conta as
diferentes ações sob as quais as mensagens consideradas seriam sujeitas, como por
exemplo, um atraso variável de transmissão, uma perda de mensagem, a duplicação de
uma mensagem, etc_
Numa especificação em máquinas de estado finito, por exemplo, determinados
aspectos do comportamento do meio de transmissão podem ser expressos através de
eventos internos, como já introduzidos no exemplo da seção 3.3.
A figura 7.12 ilustra a especificação, em máquinas de estado de dois modelos de
meio de transmissão. Em 7.12(a) é apresentada a modelização de um meio de transmissão
perfeito, sem perdas e sem duplicação, onde cada mensagem m recebida é entregue
corretamente ao seu destinatário.
No modelo apresentado, os caracteres ? e ! acompanhando o identificador m da
mensagem indicam, respectivamente, a recepção e o envio de m.
Já em 7.12(b) é apresentado um meio de transmissão com possibilidade de perdas,
a perda do dado sendo representada por um evento interno (etiqueta τ).
— 7.10 —
FONTE DESTINO
MEIO DE TRANSMISSÃO
Figura 7.11 - Introdução dos aspectos de comportamento relativos ao meio no protocolo considerado.
3.5. Outras técnicas de especificação
Os modelos utilizados na seção 3.3 permitem especificar e, particularmente, analizar

o comportamento dos protocolos de comunicação de maneira eficiente, particularmente para
a representação dos eventos e estados relacionados ao comportamento.
No entanto, uma vez que a complexidade do protocolo a representar aumenta, a
especificação através destas duas técnicas atinge uma dimensão tal, que torna-se difícil a
representação de todos os aspectos do comportamento do protocolo.
Devido a este ponto, novas técnicas, baseadas nestes modelos, obtidas pela
introdução de extensões ou a combinação com outros modelos, foram definidas e aplicadas
à especificação de protocolos, dentre as quais:
• as redes de Petri coloridas, que constituem uma extensão das redes de Petri
ordinária, onde «cores» podem ser associadas às fichas; isto permite aumentar o
poder de expressão da rede, extendendo as regras de tiro, mas simplificando a
estrutura da rede construída;
• as redes de Petri temporais, que permitem associar um intervalo de tempo (t1,t2)
às transições, de modo a tornar possível a representação de mecanismos de
temporização, como por exemplo, os mecanismos de timeout nos protocolos
baseados na retransmissão de dados;
• as técnicas de descrição formal baseadas nas máquinas de estados finitos, como
Estelle (ISO) e SDL (CCITT) que introduzem a possibilidade da representação e
manipulação de estruturas de dados complexas.
4. A VALIDAÇÃO DE PROTOCOLOS DE COMUNICAÇÃO
4.1. As diferentes facetas da validação de um protocolo de comunicação
Como foi mostrado na figura 7.1, o desenvolvimento de um programa é caracterizado

por atividades orientadas em dois sentidos opostos (caracterizados, lá, pelas flechas
dirigidas para baixo ou para cima): as atividades de síntese, caracterizadas pelas etapas de
elaboração dos diferentes níveis de especificação ou da geração do código executável; as
atividades de análise ou validação associadas às diferentes fases do desenvolvimento.
Sendo assim, é importante levantar os diferentes aspectos da validação de um
programa, no caso particular, de um protocolo de comunicação, para bem posicionar as
técnicas que serão comentadas nesta seção:
— 7.11 —
• o aspecto da validação do protocolo de comunicação está relacionado à

investigação se um serviço especificado corresponde ou satisfaz às necessidades
do usuário ou da aplicação considerada. Esta validação pode ser concretizada
através da análise de um modelo ou protótipo que permita ao usuário determinar se
era bem o comportamento esperado.
• a investigação de que o protocolo definido permite, efetivamente oferecer o serviço
especificado. Este ponto é realmente importante, particularmente no processo de
padronização de novos pares de serviços e protocolos, ou na etapa de projeto de
um protocolo proprietário.
• o teste de uma implementação de uma camada de protocolo para determinar se,
efetivamente, ela corresponde àquilo que foi estabelecido nas etapas anteriores de
análise de requisitos e especificação.
Como podemos, ver, o termo validação atinge uma dimensão bastante abrangente no
que diz respeito às etapas de desenvolvimento de um protocolo de comunicação. Nesta
seção, vamos limitar o significado da palavra validação associando-o ao segundo ponto
levantado, ou seja, aquele relacionado à determinação de que o comportamento das
entidades de protocolo especificadas permite oferecer o serviço requerido pelo usuário.
Por outro lado, não vamos abandonar o terceiro aspecto, o teste de implementação,
também importante, dedicando a este uma seção, mais adiante, no documento.
4.2. Análise estática x análise dinâmica
A tarefa de validação de uma especificação de um protocolo de comunicação pode

representar um grau de dificuldade relativamente elevado, particularmente devido às
características de concorrência e não determinismo, intrínsecas às entidades de protocolos.
O interesse da utilização de modelos e métodos formais para especificar protocolos de
comunicação reside, principalmente, na possibilidade de implementação de técnicas de
validação eficientes.
Uma primeira classificação no que diz respeito às técnicas de validação de uma
especificação de protocolo pode ser caracterizada na forma como os aspectos do
funcionamento das entidades de protocolo são analizados. Sob este ponto de vista,
podemos destacar as duas classes seguintes de validação:
• análise estática, onde o funcionamento do protocolo é validado através de uma

inspeção detalhada da sua especificação formal (texto da especificação,
representação gráfica, modelo matemático, _); esta classe de validação permite
detectar e corrigir uma série de erros, como erros de sintaxe e semântica, regras
de escôpo, conformidade de tipos, etc_, que pode ser automatizada em muitos
casos, é similar ao trabalho efetuado pelos tradutores (compiladores) para as
linguagens de programação;
• análise dinâmica, onde é levado em conta o comportamento do sistema

especificado num determinado ambiente de execução; evidentemente, esta classe
de validação pode tornar-se muito mais complexa do que as técnicas de análise
estática, principalmente devido aos diferentes aspectos dinâmicos relacionados ao
comportamento do protocolo; ela permite, porém, detectar tipos de erros que são
impossíveis de serem detectados na análise estática.
— 7.12 —
ESPERA DADO ESPERA DADO
!m ?m !m τ ?m
DADO RECEBIDO DADO RECEBIDO
(a) (b)
Figura 7.12 - Representação em máquinas de estados finitos do meio de transmissão: (a) perfeito; (b)
com perda de mensagens.
4.3. Análise dinâmica: simulação x verificação
Dentro do universo das técnicas de validação por análise dinâmica, podemos

destacar subclasses, isto sob o ponto de vista de como é realizada a exploração do
comportamento do protocolo de comunicação. Desta forma, podemos destacar os métodos
exaustivos (ou de verificação) e os não exaustivos (ou de simulação).
Os métodos exaustivos são assim denominados pelo fato de explorarem
completamente o comportamento do sistema especificado, ou seja, todas as possibilidades
de execução do protocolo de comunicação (eventos, possíveis valores de parâmetros, etc_).
Naturalmente, estes métodos são bastante difíceis de serem implementados principalmente
devido à grande quantidade de pontos que devem ser examinados, pontos estes, relativos à
execução da especificação. Entretanto, os métodos de análise exaustiva permitem obter
bons resultados quando aplicados sobre especificações simplificadas ou abstratas do
protocolo (neste caso, como garantir a exaustividade?). Exemplos desta classe de técnicas
de análise são:
• a análise de alcançabilidade, baseada na construção de um grafo de

alcançabilidade do sistema especificado através de modelos baseados em
máquinas de estados finitos, redes de Petri, etc_;
• a verificação de programas e asserções, no caso da utilização de gramáticas
formais ou álgebras de processos.
Os métodos não exaustivos ou de simulação realizam uma validação parcial, onde

apenas determinados aspectos do comportamento do protocolo podem ser analizados. São
métodos que podem ser aplicados sem problemas a especificações de porte real, uma vez
que uma seleção pode ser efetuada no que diz respeito aos aspectos a analizar.
Uma questão que se coloca aí é relacionada à que método é o mais eficiente ou que
método escolher para a realização de uma validação eficiente. Não é uma questão fácil a ser
respondida. Pode-se, porém colocar o problema do seguinte ponto de vista: no caso de
especificações de pequeno porte ou especificações abstratas de um protocolo de
comunicação, as técnicas exaustivas permitem explorar totalmente as possibilidades de
comportamento da especificação, apresentando resultados menos bons (quando algum
resultado pode ser obtido!) no caso de grandes especificações (neste caso, o que é uma
especificação de pequeno porte e uma especificação de grande porte_como é possível
medí-las?), as técnicas de simulação sendo, então, mais adequadas a esta classe de
especificações.
Mas, ainda, por que impor uma escolha com relação à utilização de um método ou
outro? Por que não os dois? Por que não utilizá-los de maneira complementar? São
— 7.13 —
questões que podem ser colocadas e que poderiam ajudar a responder a uma necessidade
de validação crescente no domínio dos protocolos e sistemas distribuídos.
Ou então, por que não uma técnica híbrida? Por que não juntar as vantagens de uma
simulação com as potencialidades (as características de exaustividade) de uma análise de
alcançabilidade, por exemplo?
Muitos dos trabalhos realizados hoje, no campo da validação de protocolos de
comunicação orientam-se à resposta a estas questões.
4.4. A validação de protocolos de comunicação (o que validar?)
Como foi determinado na seção 4.1, o sentido dado aqui ao termo validação é
associado à investigação de que a especificação de um protocolo de comunicação permite o
oferecimento do serviço requerido. A figura 7.13 retrata este aspecto, de modo que o
resultado da validação deve basear-se numa comparação entre a especificação do serviço
requerido e aquele oferecido pela especificação do protocolo de comunicação.
A essência da especificação de um protocolo, como já levantado na seção 3, é o
comportamento das entidades de protocolo e do meio de transmissão, na forma das
possíveis sequências de eventos associados à execução de cada elemento e às interações
dos diferentes elementos. A especificação dos serviços pode ser expressas na forma de
propriedades que, uma vez verificadas, permitem demonstrar que o serviço oferecido pela
camada de protocolo vai corresponder, efetivamente, ao serviço requerido.
Uma primeira classe de propriedades a serem verificadas deve permitir garantir que
eventos prejudiciais não devem ocorrer durante o funcionamento do protocolo — um
exemplo destes eventos são aqueles que possam conduzir a um estado de bloqueio. A esta
classe de propriedades, dá-se o nome de propriedades de segurança (safety properties).
A segunda classe de propriedades, as propriedades de progressão (liveness
properties), deve permitir garantir que uma vez que o protocolo evolui, ele realiza tarefas
úteis, como, por exemplo, a transmissão de uma mensagem.
4.5. Análise de alcançabilidade
Como vimos na seção 3, uma boa parte dos modelos utilizados para a especificação
dos protocolos de comunicação é baseada sobre o formalismo dos sistemas de transição
(máquinas de estados finitos, redes de Petri, Estelle, _).
Uma técnica das mais aplicadas à validação de protocolos especificados segundo
este modelo é a análise de alcançabilidade, cujos primeiros trabalhos foram realizados sobre
as máquinas de estado finito.
primitivas
de serviço
primitivas
de serviço especificação
do protocolo N
entidade N entidade N
oferece
especificação
do
serviço N
serviço N-1
Figura 7.13 - Princípio da validação de um protocolo de comunicação.
— 7.14 —
A construção do grafo de alcançabilidade visa dar uma visão de todas as possíveis

sequências de eventos podendo ocorrer num protocolo especificado por um sistema de
transições. Um aspecto importante desta atividade, é o fato que, uma tal especificação pode
ser caracterizada pela existência de diversos componentes, cada um representando um
elemento importante da camada ou da arquitetura considerada.
Sendo assim, o paralelismo existente na especificação deve ser considerado, a
operação que vai permitir representar este aspecto sendo a composição paralela.
A figura 7.14 mostra o exemplo de uma especificação de um serviço de Enlace,
utilizando o modelo de máquinas de estado finito.
Este serviço é representado sob a forma de duas filas de capacidade 1, para
construir uma fila de capacidade 2. Os processos envolvidos podem efetuar as seguintes
operações:
1 aceitar uma mensagem 0 ou 1 na porta a;

2 sincronizar-se na porta c como resultado de um dos pares de eventos <c?0;c!0>
ou <c?1;c!1>;
3 emitir a primeira mensagem na porta b, e reinicializar ou aceitar a segunda
mensagem na porta a;
4 emitir a primeira mensagem na porta b e sincronizar na porta c para a emissão da
segunda mensagem;
5 emitir a segunda mensagem na porta b e reinicializar ou aceitar a terceira
mensagem na porta a.
Utilizando os operadores de composição paralela existentes para os sistemas de

transição, o espaço de estados global pode ser construído. O resultado é mostrado na figura
7.15.
Como se pode ver, a porta c não é representada nesta figura. Isto porque, como os
eventos ocorrendo na porta c, são unicamente relacionados com os dois processos
representando cada uma das filas, estes são considerados eventos internos, não
aparecendo nem mesmo na descrição do comportamento da composição paralela. Estes
são representados pela etiqueta τ.
O estado inicial do espaço de estados é representado, lá, pela etiqueta ( • , • ). Os
possÍveis comportamentos descritos nos parágrafos de 1 a 5 podem ser relacionados às
seguintes transições de estado:
1 ( •,• ) → ( 0,• ) e ( •,• ) → ( 1,• )

2 os arcos etiquetados por τ;
3 ( •,0 ) → ( •,• ) e ( •,1 ) → ( •,• ) ou ( •,0 ) → ( 0,0 ), ( •,0 ) → ( 1,0 ), ( •,1 ) → ( 1,1 )
e ( •,1 ) → ( 0,1 )
4 ( 1,0 ) → ( 1,• ) → ( •,1 ) ou ( 0,1 ) → ( 0,• ) → ( •,0 ) ou ( 0,0 ) → ( 0,• ) → ( •,0 )
ou ( 1,1 ) → ( 1,• ) → ( •,1 )
5 ( •,0 ) → ( •,• ) ou ( •,0 ) → ( 1,0 ) ou ( •,0 ) → ( 0,0 ) e ( •,1 ) → ( •,• ) ou ( •,1 ) → (
1,1 ) ou ( •,1 ) → ( 0,1 )
a b
c!0 c!1 b!0 b!1
0 1 c c 0 1
a?0 a?1 c?0 c?1
Figura 7.14 - Especificação de um canal com fila de mensagem de capacidade 2.
— 7.15 —
a b
a?0 a?1
0,1 ·,1 1,1
τ
b!1 b!1 b!1
a?0 a?1
0,· ·,· 1,·
τ
b!0 b!0 b!0
a?0 a?1
0,0 ·,0 1,0
Figura 7.15 - Grafo de alcançabilidade gerado para a especificação da figura 7.14.
O exemplo considerado apresenta um nível de complexidade bastante baixo, o que

permite efetuar a composição paralela e a análise do comportamento global sem a utilização
ferramentas automatizadas.
No entanto, no caso de especificações de protocolos de porte realista, esta análise
vai requerer a aplicação de algoritmos de geração do grafo de alcançabilidade dentro do
contexto de uma ferramenta de validação.
Ainda assim, o processo de verificação da especificação de um protocolo através de
uma ferramenta automatizada pode não apresentar um resultado bem adaptado à análise
devido ao grande número de estados e caminhos possíveis entre os estados.
Existem várias técnicas que permitem resolver este problema, uma delas sendo a da
verificação por abstração.
4.6. A verificação por abstração
A verificação por abstração é baseada na construção do grafo de alcançabilidade e a

sua posterior redução (obtenção de um autômato quociente) através da aplicação de
princípios de equivalência entre processos. O autômato quociente obtido a partir do grafo de
alcançabilidade vai oferecer uma visão abstrata do sistema, graças à eliminação de grande
parte dos eventos, considerados irrelevantes à análise em curso. A análise de
comportamento torna-se, então mais simples (ou possível) de ser realizada pela obtenção
de um autômato comportando um número muito menor de estados que aquele do grafo de
alcançabilidade a partir do qual ele foi gerado.
A aplicação da verificação por abstração é baseada na definição de duas classes de
eventos associadas ao comportamento de um processo:
• os eventos externos ou observáveis, caracterizando normalmente as interações do

processo com o seu ambiente (usuários da camada de protocolo, o suporte de
transmissão, etc_);
• os eventos internos, caracterizando ou os eventos expontâneos dos processos, ou
as interações entre componentes do processo (com relação ao exemplo
apresentado anteriormente, as interações realizadas na porta c são consideradas
eventos internos — na composição paralela, eles foram etiquetados por ). τ
A diferença entre estas duas classes de evento se traduz a nível do autômato
quociente. Os eventos observáveis aparecendo no grafo de alcaçabilidade são, normalmente
repassados ao autômato quociente, representados na forma de transições etiquetadas. Já
— 7.16 —
os eventos internos podem, ou desaparecer, ou aparecer na forma de transições «invisíveis»

(etiquetados por τ) no autômato quociente.
Diferentes relações de equivalência podem ser consideradas, onde cada relação vai
permitir obter uma visão distinta do comportamento do sistema a verificar, entre elas: a
equivalência de rastro (ou de linguagem), a equivalência observacional e a equivalência de
teste.
A equivalência de rastro é baseada na análise de comportamento de um processo
em função das possíveis sequências de eventos observáveis que ele é capaz de oferecer. A
aplicação desta relação sobre um grafo de alcançabilidade se traduz, de um lado pela
eliminação de todos os eventos internos ou invisíveis e, por outro lado, da manutenção de
apenas uma instância de um mesmo evento observável associada a um mesmo estado.
Esta relação pode ser ilustrada com o auxílio dos pares de processos representados na
figura 7.16, todos equivalentes segundo esta relação.
4.7. Exemplo de verificação de um protocolo: o bit alternado
O protocolo do bit alternado representa um protocolo de enlace, utilizado

principalmente para ilustrar procedimentos de especificação e validação de protocolos.
As características do protocolo são as seguintes:
• o receptor deve enviar reconhecimento das mensagens recebidas corretamente

(as mensagens incorretas podendo ser detectadas com o auxílio de códigos de
detecção de erros — CRC, por exemplo);
• as mensagens são numeradas sequencialmente para o controle de perdas; o
emissor vai retransmitir uma mesma mensagem periodicamente (mecanismo de
timeout) até que ele receba o reconhecimento com o número de sequência da
mensagem corespondente;
• quando um reconhecimento da mensagem enviada é recebido, o emissor
incrementa o seu estado e para o próximo número de sequência a considerar;
• uma vez que os reconhecimentos podem também ser perdidos, o receptor deve
retransmitir os reconhecimentos (pelo mesmo mecanismo de retransmissão) até
que uma mensagem contendo o próximo número de sequência seja recebida;
• o protocolo é do tipo «envia-espera», de modo que apenas dois números de
sequência (0 e 1) podem ser definidos para as mensagens e os reconhecimentos
(assim, um bit alternando entre 0 e 1 — vem daí o nome do protocolo — permite
implementar o sequenciamento das mensagens).
A figura 7.17 representa a especificação, em máquinas de estado finito do

protocolo considerado. As portas c e d são utilizadas, para o envio das mensagens geradas
pelo emissor (a partir da recepção de uma mensagem m na porta a). As portas e e f são
utilizadas para o envio dos reconhecimentos ao emissor, quando da recepção de uma
mensagem de sequência correta.
a a a a a a
A B C D E F
1 1 1
1
a a
a a
1 1
a
a a
2 2 2 3 a
a a
t a a
2 2 2 3
3 4 b c
3 4 5 b c
b b c
b b c 3 4
4 5
4 3 5 6 6 7
b b b c b c b c b c
Figura 7.16 : Ilustração da equivalência de traço.
— 7.17 —
Para efeito de simplificação, o comportamento dos canais é representado por

eventos representando simultaneamente, a recepção de uma mensagem no canal numa
porta e a sua reemissão na porta correspondente. Os eventos c?0 e c?1, f?0 e f?1,
representam, respectiva-mente, as perdas das mensagens e dos reconhecimentos no meio.
Os estados r e s representam, respectivamente, a recepção de uma mensagem na
porta d e a recepção de uma mensagem na porta a.
O grafo de acessibilidade gerado para esta especificação é apresentado na figura
7.18. As transições etiquetadas por τ
representam as perdas e retransmissões de
mensagens e de reconhecimentos (para facilitar o entendimento do grafo, as portas
associadas aos eventos internos foram também especificadas).
Como se pode verificar o protocolo especificado não apresenta situações de bloqueio
(deadlocks). Por outro lado, os diversos loops presentes no grafo de acessibilidade podem
indicar situações de não progresso do protocolo. Os loops representam as retransmissões
provocadas pela expiração do mecanismo de timeout associado.
a b
c!0 c?0 f!1 f!0
a? c?0/d!0 d?0
s c c d d r
e?1 c?1/d!1
e?1 d?0
c?1 d?1
e?1 e?0 b! b!
f?0
e?0 d?1 d?0
e?0
f?0/e!0
s e e f f r
a? f?1/e!1 d?1
c!1 f!0
f!1
f?1
Emissor Meio Receptor
Figura 7.17 - Especificação do protocolo bit alternado em máquinas de estado finito.
a b
a?m
τ s τ
b!m
τ fe(1) τ cd(0)
τ τ
τ
τ r
fe(1) b!m b!m
τ fe(0)
τ r
τ τ
τ τ
cd(1)
fe(0) b!m
τ s τ
a?m
Figura 7.18 - Grafo de alcançabilidade gerado para a especificação da figura 7.17.
— 7.18 —
5. A IMPLEMENTAÇÃO DOS PROTOCOLOS DE COMUNICAÇÃO
Esta seção descreve as linhas gerais relativas à obtenção de um programa

executável implementando o protocolo a partir de uma especificação formal baseada numa
das técnicas de descrição existentes.
Como foi observado nas duas seções precedentes, a especificação de um protocolo
de comunicação para análise do comportamento não deve levar em conta unicamente os
aspectos relativos ao comportamento das entidades de protocolo envolvidas, mas também,
os aspectos relativos ao comportamento do ambiente no qual elas vão executar. No caso
particular dos protocolos de comunicação, o ambiente de execução consiste dos usuários
do serviço oferecido (as entidades de protocolo da camada superior) e do serviço oferecido
pela camada inferior (serviço de rede, de enlace, meio de transmissão, etc_).
Sendo assim, podemos definir, numa especificação de uma camada de protocolo,
duas porções distintas:
• a parte independente de máquina, relativa à descrição do comportamento e das

interfaces associadas às entidades de protocolos em desenvolvimento;
• a parte dependente de máquina, que só pode ser refinada no momento da
integração do programa executável no sistema alvo; a nível de especificação, esta
parte deve ser descrita, da forma mais abstrata possível, mas tentando traduzir, de
forma fiel os possíveis comportamentos do ambiente no qual as entidades vão
executar.
O processo de implementação de uma camada de protocolo a partir de uma

especificação formal é caracterizado, geralmente por um processo semiautomatizado, onde
aqueles aspectos dependentes de máquina devem ser substituídos, normalmente de
maneira «artesanal» pelos aspectos reais do sistema (suporte de comunicação disponível,
estruturas de dados a considerar, _).
Isto corresponde, normalmente, à transformação da especificação de validação em
uma especificação orientada à implementação, que leva em conta as substituições
mencionadas. A partir desta nova especificação, ferramentas de tradução vão permitir gerar,
um programa em linguagem de programação de alto nível (C, Pascal, _), que será
compilado e integrado ao ambiente de execução.
Atualmente, um extenso conjunto de ferramentas está disponível para a geração de
código a partir de especificação formal de protocolos, particularmente a partir de
especificações baseadas nas técnicas de descrição formal como Estelle e LOTOS.
6. O TESTE DE PROTOCOLOS DE COMUNICAÇÃO
Na etapa de testes aplicados sobre uma especificação, dois principais aspectos

devem ser abordados:
• o primeiro aspecto diz respeito à verificação se uma dada implementação

corresponde efetivamente à especificação do serviço como foi estabelecido no
documento de normalização;
• o segundo aspecto, diz respeito à verificação se uma implementação executa
corretamente no contexto de um sistema de comunicação heterogêneo, objetivo
essencial da definição do modelo de referência OSI.
A atividade de teste que permite assegurar o primeiro aspecto é denominada o teste

de conformidade do protocolo, o segundo aspecto sendo coberto pelos testes de
interoperabilidade.
O teste de uma implementação é caracterizado normalmente pela análise do
comportamento da especificação em função de todas as possíveis interações ocorrendo
nas suas interfaces (primitivas de serviço, por exemplo). A determinação de todas as
— 7.19 —
possíveis interações podendo intervir nas interfaces de uma implementação de protocolo é

denominada a geração de sequência de testes.
A tendência dos trabalhos realizados no domínio da Engenharia de Protocolos vai no
sentido principalmente do desenvolvimento da primeira classe de testes. Dentro desta
perspectiva, os trabalhos visam, fundamentalmente:
• à definição de métodos de testes de implementação, a técnica podendo variar em

relação a como a implementação é submetida;
• à definição de sequências de testes a nível dos organismos de normalização;
• à definição de blocos de conformidade a serem utilizados como referência no
momento da realização de testes;
• à definição de técnicas para a representação de sequências de teste, um resultado
importante obtido a nível da ISO, sendo o formalismo TTCN (Tree and Tabular
Combined Notation);
• à geração de sequências de teste na etapa de projeto (como mostrado em 7.1), isto
podendo ser automatizado por métodos e ferramentas de software; trabalhos têm
sido realizados nesta área para permitir a geração das sequências de teste a partir
de especificações formais em máquinas de estados finitos, Estelle e Lotos, alguns
dos quais permitem obter a representação da sequência de testes segundo a
notação TTCN.
7. CONCLUSÃO
Nesta parte do documento foram analizados os principais pontos relativos ao

desenvolvimento de protocolos de comunicação, fazendo uma distinção entre as diferentes
etapas deste desenvolvimento, particularmente a especificação, a validação, a
implementação e os testes. Maior ênfase foi dada às duas primeiras etapas, a bibliografia
especializada podendo servir como base para o aprofundamento dos conhecimentos em
qualquer das etapas citadas.
Um ponto fundamental porém, não aprofundado nesta parte do documento foi a
importância das técnicas de descrição formal normalizadas na ISO e no CCITT, Estelle e
Lotos de um lado e SDL do outro. Este aspecto será aprofundado na parte seguinte, sendo
que vamos estudar detalhadamente os mecanismos oferecidos pela Técnica de Descrição
Formal Estelle e a utilização destes e das ferramentas associadas para a concepção dos
protocolos de comunicação.
— 7.20 —
Capítulo 8
P1
P2 P3
REDES DE PETRI b c
1. INTRODUÇÃO
As Redes de Petri foram introduzidas em 1962, a partir de uma tese de doutorado

desenvolvida na Alemanha por Carl Adam Petri. Traduzido para o português, o título de sua
tese corresponderia a “Comunicação com Autômatos” e o objetivo era o estabelecimento de
um modelo matemático que permitisse expressar os aspectos de comunicação num
sistema computacional. A partir de 1968, o interesse deste modelo motivou o aparecimento
de trabalhos os mais diversos para a representação de problemas computacionais,
consolidando o modelo, que passou a ser conhecido como Redes de Petri na modelagem e
análise de programas das mais diversas naturezas.
As primeiras aplicações das Redes de Petri foram realizadas sobre sistemas de
produção, para a representação de tarefas de montagem e a geração de planos, através de
um grande número de pesquisas realizadas na França, aproveitando as experiências
utilizando o Grafcet, uma linguagem de programação de controladores programáveis.
Na continuidade dos estudos sobre as Redes de Petri, diversos trabalhos mostraram
sua utilidade para a modelagem e análise dos problemas inerentes aos protocolos de
comunicação e extensões e modelos foram desenvolvidos a partir daí.
O objetivo deste capítulo é apresentar os principais conceitos associados às Redes
de Petri e como estas podem ser utilizada para o desenvolvimento de modelos e análise dos
problemas intrínsecos aos protocolos de comunicação.
2. REDES DE PETRI — DEFINIÇÃO BÁSICA
2.1. Elementos de uma rede de Petri
Matematicamente, uma Rede de Petri é definida com um quádruplo
R = <P,T,Pre,Post>
Onde:
• P, é um conjunto finito de lugares;

• T, é um conjunto finito de transições;
• Pre, é uma aplicação incidência precedente;
• Post, é uma aplicação incidência posterior.
Graficamente, os elementos de uma Rede de Petri podem ser ilustrados como

mostrado na figura 8.1.
— 8.1 —
CAP. 8 — R EDES DE PETRI PROF. VITÓRIO BRUNO MAZZOLA
a c
P2
3
P1 P3
b d
Figura 8.1 — Ilustração dos elementos de uma Rede de Petri.
Utiliza-se também a notacão:
C = Post - Pre
2.2. Marcação de uma Rede de Petri
Uma Rede de Petri marcada é representada matematicamente por uma dupla
N = <R,M>
Onde:
• R, é uma Rede de Petri;

• M, é uma marcação inicial, sendo uma aplicação do tipo
M:P → N
M(p) é o número de marcas, ou fichas contidas no lugar p.
2.3. Grafo e notações matriciais
Como se pode verificar na figura 8.1, as Redes de Petri podem ser expressas
graficamente por um grafo onde se observam dois tipos de nó: os lugares e as transições.
Um arco conecta um lugar p a uma transição t se e somente se Pre(p,t) ≠ 0. Um arco
conecta uma transição t a um lugar p se e somente se Post(p,t) ≠ 0. Os valores não nulos de
Pre e Post são associados aos arcos como rótulos. Quando um arco não possui rótulo, o
valor default é 1.
A marcação M pode ser representada por um vetor que tem por dimensão o número
de lugares; Pre, Post e C podem ser representados por matrizes cujo númeroo de linhas é
igual ao número de lugares e o número de colunas é igual ao número de transições.
Para o exemplo da figura 8.1, pode-se obter as seguintes notações:
• P = {p1,p2,p3}
• T = {a,b,c,d}
0 1 0 0 
• Pr e = 1 0 3 0 
0 0 0 1
— 8.2 —
1 0 0 0 
•  
Post = 0 1 0 3 
0 0 1 0 
 1 −1 0 0
•  
C = − 1 1 − 3 3 
 0 0 1 − 1
0 
• M = 3 
0 
2.4. Definições e regras de disparo
2.4.1. Rede de Petri Pura
Uma Rede de Petri é definida como pura, se para todas as transições, não existe
nenhum lugar que esteja, ao mesmo tempo, na entrada e na saída, ou seja, a rede não
possui nenhuma malha elementar. A Rede de Petri da figura 8.1 é uma Rede de Petri Pura,
enquanto que a rede da figura 8.2 não apresenta esta propriedade.
2.4.2. Transição Habilitada
Uma transição t é dita habilitada se e somente se:
∀p ∈ P M(p) ≥ Pre(p,t)
Ou seja, todos os lugares de entrada da transição considerada devem possuir, no

mínimo, o número de fichas correspondentes ao peso do arco que liga o lugar à transição.
Por exemplo, para a rede da figura 8.1, considerando a marcação inicial igual a:
0 
M = 3 
0 
as transições habilitadas são a e c, porque
0  0 
Pr e(•,a ) = 1 e Pr e(•, c ) = 3 
 
0  0 
e, portanto,
M(p) > Pre(•,a) e M(p) > Pre(•,c)
2.4.3. Disparo de uma Transição
Se t é uma transição habilitada a partir da marcação M, o disparo de t origina uma

nova marcação M‘ de forma que:
∀p ∈ P M’(p) = M(p) – Pre(p,t) + Post(p,t)
— 8.3 —
a c
P2
3
P1 P3 e
3
b d
Figura 8.2 — Exemplo de uma Rede de Petri não pura.
Por exemplo, na rede da figura 8.1, após o disparo da transição a, considerando a

marcação inicial M, obtém-se a seguinte marcação M’:
0  0  1 1
       
M ' = 3  − 1 + 0  = 2
0  0  0  0 
2.4.4. Conflito e Paralelismo
O conflito em Redes de Petri pode ser definido em dois níveis: o conflito estrutural e o
conflito efetivo. O conflito estrutural refere-se àquele estabelecido em função da estrutura
(layout) da própria rede. Duas transições t1 e t2 encontram-se em conflito estrutural se
existe pelo menos um lugar de entrada comum entre as duas.
∃p Pre(p,t1).Pre(p,t2) ≠ 0
O conflito efetivo está relacionado a questões circunstancial de disparo das

transições. Duas transições t1 e t2 encontram-se em conflito efetivo se elas encontram-se
em conflito estrutural e se:
M ≥ Pre(•,t1)
M ≥ Pre(•,t2)
O paralelismo é visto igualmente nos mesmo níveis que o conflito. Duas transições,
t1 e t2 encontram-se em paralelismo estrutural se:
(Pre(•,t1))T x Pre(•,t2) = 0
Ou seja, elas não possuem nenhum lugar de entrada em comum.

Duas transições, t1 e t2 estão em paralelismo efetivo se elas possuem paralelismo
estrutural e se:
M ≥ Pre(•,t1)
M ≥ Pre(•,t2)
Para o exemplo da figura 8.1, as transições a e c estão em conflito estrutural, pois
Pre(p2,a).Pre(p2,c) = 3 e as transições b e d estão em paralelismo estrutural.
Para a marcação inicial da rede considerada, a e c estão em conflito efetivo. Por
outro lado, se for considerada a marcação M’ descrita abaixo, pode-se dizer que as
transições b e d são efetivamente paralelas.
— 8.4 —
1
 
M ' = 0 
1
2.4.4. Seqüência de Disparo numa Rede de Petri

ta tb
Se M 0 → M1 e M 1 → M 2 pode-se dizer que a seqüência “ta tb” é disparável a
partir de M 0, o que pode ser notado como:
M 0 
ta

tb
→M2
Seja s um vetor cujos componentes s (t ) são os números de ocorrências das

transições t numa seqüência de disparo s, este vetor é denominado vetor característico de s
e sua dimensão é igual ao número de transições da Rede de Petri.
Tomando como exemplo a Rede de Petri da figura 8.1, tem-se, por exemplo, a
seqüência “s = a a b”:
0  1 2 1
3  →
a 2 →a 1 →
b 2 
       
0  0  0 0 
e
2
1
a a b=  
0 
 
0 
As evoluções da marcação de uma Rede de Petri podem ser dadas pela equação:
M’ = M – Pre. s + Post. s
A mesma equação pode ser escrita como sendo:
M’ = M + C. s com M ≥ 0, s ≥ 0
Esta equação é denominada equação fundamental de uma Rede de Petri.
É importante notar que não basta encontrar um vetor que satisfaça a equação acima
para garantir que existe uma seqüência de disparo da marcação M à marcação M’. É preciso
também que a marcação inicial seja tal que as transições serão efetivamente habilidatas
para cada marcação intermediária. Tomando como exemplo a Rede de Petri da figura 8.3,
se:
1 − 1 − 1 1 1  1
0  1 −1 0 0  1
M =  C =  abcd =  
0 0 1 −1 0  1
     
0 0 0 1 − 1 1
— 8.5 —
P1
P2
P3
P4
Figura 8.3 — Exemplo de seqüência inválida.
No entanto, analisando-se a rede, observa-se que a seqüência abcd não é válida,

pois, após o disparo de a, a transição b, fica desabilitada. Portanto, não se pode escrever:
M  → M
abcd
2.4.5. Conjunto das Marcações Acessíveis
O conjunto das marcações acessíveis A(R;M 0) de uma Rede de Petri marcada é o

conjunto de marcações que se pode atingir a partir da marcação inicial M 0 por uma
seqüência de disparo. A notação utilizada para isto é:
A(R;M 0) = { M i , ∃ s M 0 →
s
Mi }
Considerando que este conjunto é finito, é possível representá-lo sob a forma de um

grafo G A(R;M 0). Este grafo terá por vértices o conjunto das marcações acessíveis A(R;M 0),
um arco orientado conecta dois nós M i e M j se existe uma transição t disparável que permita
passar da marcação M i a M j , ou seja: M i →
t
Mj
Em geral os arcos do grafo são etiquetados pelas transições correspondentes, o que
caracteriza o grafo de marcações como a máquina de estados equivalente da Rede de Petri.
A figura 8.4 ilustra o grafo de marcações obtido para a Rede de Petri da figura 8.1.
3. PROPRIEDADES DAS REDES DE PETRI
Um modelo descrito na forma de uma Rede de Petri pode oferecer importantes

informações relacionadas ao problema ou sistema para o qual o mesmo foi construído. As
propriedades que podem ser observadas num modelo em Rede de Petri podem estar ou não
associadas à marcação inicial da mesma.
No caso de propriedades associadas à marcação inicial, não é evidente que
conclusões poderão ser obtidas facilmente, uma vez que nem sempre o conjunto de
marcações acessíveis é finito.
— 8.6 —
0
3
a c
0
b d
1 0
2 0
0 1
a b
2
1
0
a b
3
0
0
Figura 8.4 — Grafo de marcação para a Rede de Petri da figura 8.1.
Por outro lado, no caso de propriedades que não dependem da marcação (as
propriedades estruturais), podem permitir a obtenção de resultados importantes, a partir da
resolução de sistemas de equações lineares.
3.1. Rede de Petri K-limitada (Limitação)
Esta definição está associada à definição de lugar k-limitado e binário.
3.1.1. Lugar K-limitado e Binário
Um lugar p de uma rede marcada é dito k-limitado se e somente se:
∀M’ ∈ A(R;M 0) M’ ≤ k
Se k = 1, diz-se que o lugar é binário (ou salvo). Considerando a Rede de Petri da

figura 8.1, pode-se verificar que para a marcação inicial considerada desde o início, o lugar
P3 é salvo, enquanto os lugares P1 e P2 são 3-limitados.
3.1.2. Rede de Petri marcada K-limitada e salva
Uma Rede de Petri marcada N é dita k-limitada se e somente se todos os lugares

são k-limitados. Uma Rede de Petri marcada é dita salva se e somente se todos os seus
lugares são salvos (binários).
A Rede de Petri da figura 8.1 é 3-limitada para a marcação inicial que foi considerada
desde o início deste capítulo (3 fichas no lugar P2). Se a marcação inicial fosse de apenas
uma ficha em P2, a Rede de Petri seria salva, observando que, para esta marcação, as
transições c e d jamais seriam habilitadas.
Por outro lado, se considerarmos a Rede de Petri da figura 8.5, para a marcação
inicial indicada na figura, a cada vez que a seqüência de transições a b ocorre, uma ficha é
gerada no lugar P3. Sendo assim, a Rede de Petri considerada não é limitada porque o lugar
P3 não é limitado. Se aprofundarmos a análise desta rede, vamos concluir que os lugares P1
e P2 também não são limitados.
— 8.7 —
P1
P2 P3
b c
Figura 8.5 — Uma Rede de Petri não limitada.
Esta propriedade de limitação pode ter interpretações diversas, dependendo, é claro,

do sistema representado na rede. Por exemplo, no caso do modelo de um protocolo de
comunicação, a produção de fichas num lugar pode significar o aparecimento de mensagens
numa entidade que não tem capacidade de dar vazão a estas.
Portanto, em grande parte dos modelos construídos com base nas Redes de Petri, a
verificação desta propriedade é um bom sinal para o sistema. Sendo assim, diz-se que esta
é uma boa propriedade.
3.2. Rede de Petri Viva (Vivacidade)
A vivacidade de uma Rede de Petri é uma propriedade relacionada à marcação e às

transições da rede.
3.2.1. Transição Quase-Viva
Uma transição t de uma Rede de Petri Marcada N com:
N = <R,M 0>
é dita quase-viva se e somente se existe uma seqüência de disparo s tal que:
M0 
→s
M' e M'
→t
Pode-se, ainda, escrever esta condição por:
M 0 →
st
3.2.2. Transição Viva
Uma transição t de uma Rede de Petri Marcada N com:
N = <R,M 0>
é dita viva se e somente se:
— 8.8 —
∀M’ ∈ A(R;M 0) ∃ s M →

st
Traduzindo em texto, pode-se dizer que uma transição é quase-viva se existe uma
seqüência de transições a partir da marcação inicial que vai conduzir a seu disparo. Uma
transição será dita viva quando, para qualquer marcação da Rede de Petri existir uma
seqüência de transições que vai conduzir a seu tiro.
3.2.3. Rede de Petri Viva
Uma Rede de Petri Marcada N = <R,M 0> é dita viva se e somente se todas as suas
transições forem vivas.
Para a Rede de Petri Marcada da figura 8.6, por exemplo, o Grafo de Marcação para a
marcação inicial indicada na figura é mostrado na figura 8.7. Analisando o grafo, pode-se
concluir que a transição d é quase-viva, mas não-viva, pois ela só é disparada uma vez, já
que, uma vez disparada, a evolução da Rede de Petri fica “presa” no sub-grafo da direita. Já,
as transições a, b, c, e e f são vivas, pois elas aparecem no subgrafo da direita e,
observando o grafo, veremos que será possível, a partir de qualquer marcação, encontrar
uma seqüência de disparo que conduza a estas.
Com relação a esta propriedade, pode-se dizer:
• para a verificação desta propriedade, é verificado sempre uma Rede de Petri

Marcada;
• a verificação desta propriedade garante que, para a marcação inicial considerada,
sua estrutura não permite a existência de loops no sistema;
• uma Rede de Petri Viva garante ainda a ausência de uma parte morta (inatingível)
no sistema.
P1
P2
b c
P3 P4
e d f
Figura 8.6 — Transição quase-viva e não viva.
— 8.9 —
3 4 d 1
e f
f e
3 a 4
1 3 c b 1 4 d c
2
a e f a
e 2 3 b 1 1 c 2 4 f
b a f c
e
3 3 1 2 4 4
b c
2 2
Figura 8.7 — Grafo de Marcação contendo uma transição quase-viva.
Analisando exemplos de Redes de Petri anteriormente apresentadas, pode-se

observar que a Rede de Petri da figura 8.1 é viva, enquanto a da figura 8.6 não é.
3.3. Rede de Petri Reinicializável
A vivacidade de uma Rede de Petri Marcada N = <R,M 0> é reinicializável se e

somente se seu grafo de marcação for fortemente conexo, ou melhor,
∀M’ ∈ A(R;M 0) ∃ s M ' →

st
M0
A maior parte dos sistemas, incluindo-se nesta classe os protocolos de

comunicação, possuem comportamento repetitivo e, portanto, suas Redes de Petri serão
reinicializáveis.
Tomando como exemplo a Rede de Petri da figura 8.8, cujo grafo de marcação está
apresentado na figura 8.9, pode-se verificar que ela não é reinicializável, pois não existe
nenhuma seqüência que permita retornar à marcação inicial. Por outro lado, é importante
verificar que ela é viva, uma vez que sempre é possível disparar as transições a, b e c.
3.4. Invariantes de Lugar e Componentes Conservativas
Esta é uma das propriedades relacionadas à estrutura da Rede de Petri,

independente da marcação. Para ilustrar o significado desta propriedade, será utilizado um
exemplo de Rede de Petri, cuja estrutura está apresentada na figura 8.10.
Considerando esta estrutura e observando os lugares P1 e P2 e as transições a e b,
pode-se verificar que a soma das marcações considerando estes dois lugares e os disparos
das duas transições citadas se mantém constante, ou melhor, M(P1) + M(P2) = 1. Mesmo
considerando os disparos de outras transições da Rede, observaremos que não ocorrerão
mudanças nesta soma. Pode-se afirmar, então que, para todas as marcações da rede,
M(P1) + M(P2) = M 0(P1) + M 0(P2) ∀M’ ∈ A(R;M 0)
Com base nisto, o par de lugares P1 e P2 é chamado uma componente

conservativa e a forma linear M(P1) + M(P2) é denominada um invariante de lugar. Pode-se
— 8.10 —
definir um invariante linear de lugar como uma função linear das marcações cujo valor é uma
constante, dependendo apenas da marcação inicial da rede. Os invariantes de lugar
correspondem a uma restrição em termos de estados e eventos do sistema que serão
verificadas em qualquer circunstância.
Uma componente conservativa corresponde à solução da equação fT.C = 0
e C = Post – Pre e f é a função linear que define a componente. Do ponto de vista gráfico,
uma componente conservativa define uma sub-rede de Petri composta pelos lugares cuja
componente de f é diferente de zero e as transições de entrada e saída destes lugares.
Se f é solução da equação citada acima, então,
fT.M = fT. M 0 ∀M ∈ A(R;M 0)
é o invariante linear de lugar correspondente.
3.5. Invariantes de Transição e Componentes Repetitivas
Tomando novamente a Rede de Petri da figura 8.10, pode-se verificar que o disparo
da seqüência c d gera a mesma marcação. A sub-rede que será observada agora é a
formada pelos lugares P3, P4 e P5, com as transições c e d. Esta sub-rede é dita ser uma
componente repetitiva estacionária.
Um invariante de transição é uma seqüência de disparos de transições que não
provoca modificações na marcação da rede. A presença de um invariante de transições no
modelo de um sistema pode indicar a existência de uma seqüência cíclica de eventos que
pode ser repetida indefinidamente.
Toda solução da equação C. s = 0 constitui uma componente repetitiva estacionária.
Uma componente repetitiva estacionária define uma subrede onde só são consideradas as
transições para as quais as componentes do vetor s são diferentes de 0, com seus lugares
de entrada e de saída. A componente repetitiva estacionária não depende da marcação
inicial, mas a existência de um invariante linear de transição depende.
P1
P2 c P3
P4
Figura 8.8 — Rede de Petri não reinicializável.
a b a
14 24 13 23
Figura 8.9 — Grafo de Marcação da Rede de Petri da figura 8.8.
— 8.11 —
a c
P1 P2 P3 P4 P5
b d
Figura 8.10 — Rede de Petri com invariante de lugar.
4. REPRESENTAÇÃO DE DADOS E DE ASPECTOS TEMPORAIS
As Redes de Petri são úteis para efetuar a modelagem de qualquer tipo de aplicação
que apresente riqueza em termos de paralelismo, comunicação, competição por recursos e
outras características típicas dos sistemas distribuídos. Nesta família de aplicações,
encontram-se os protocolos de comunicação, tema central desta disciplina.
Assim como as demais aplicações distribuídas, os protocolos de comunicação
requerem um modelo que possibilite expressar os aspectos de processamento e as
restrições temporais.
Apesar de poderoso, o modelo original das Redes de Petri não foi concebido para
expressar, de forma explícita estes aspectos e, por esta razão, outros modelos (ou
extensões ao modelo original) foram desenvolvidos.
4.1. Interpretação das Redes de Petri
4.1.1. Lugares, transições e fichas
Na construção de modelos utilizando técnicas formais, é importante que se tenha

condições de dar um significado físico aos diversos elementos sintáticos da notação
utilizada. Sendo assim, interpretar um modelo descrito em Redes de Petri ou um resultado
de análise, é fundamental dar um sentido aos conceitos de lugares, transições e fichas.
É evidente que o significado específico de cada uma destas entidades será
fortemente dependente do sistema sob estudo. No entanto, pode-se dar significados mais
genéricos a estes elementos.
Sob esta ótica, os lugares podem ser interpretados como atividades de um sistema a
eventos discretos. Áreas de estoque num sistema de produção, condições lógicas num
sistema seqüencial, procedimentos a serem executados num sistema operacional, são
alguns exemplos de elementos que podem ser representados por lugares num modelo a
base de Redes de Petri.
Às transições, geralmente, são associados eventos considerados instantâneos num
sistema, que possuem duração nula ou desprezível na escala de tempo fundamental do
sistema. O clique de um mouse, a usinagem de uma peça, o envio de uma mensagem, a
ativação de um processo são alguns exemplos disto. É possível também associar atividades
ou procedimentos às transições, principalmente quando, do ponto de vista do sistema estas
sejam consideradas atômicas ou indivisíveis. Neste caso, as transições podem ser
consideradas simplificações de um trecho de Rede de Petri caracterizado por uma transição
de início, um lugar representando a atividade ou procedimento e uma transição de fim, como
ilustrado na figura 8.11.
— 8.12 —
Finalmente, as fichas podem ser interpretadas como objetos físicos (por exemplo,
peças ou ferramentas num sistema de fabricação), informações, estruturas de dados ou
recursos do sistema. Estas entidades são submetidas a eventos (disparos de transição) que
as fazem mudar de estado (passar de um lugar para o outro na Rede de Petri).
4.1.2. Interação com Dados e Ambiente
Quando se considera um sistema capaz de realizar o tratamento de informação ou

de objetos físicos, este tratamento deve ser especificado. Por esta razão, além do título do
tratamento, é, muitas vezes, necessário, explicitar como este tratamento é realizado, seja a
nível das transições, seja a nível dos lugares.
Na primeira situação, considera-se que o tratamento será realizado de forma
instantânea e ininterrupta, no momento do disparo da transição. Na segunda situação,
considera-se que seja uma atividade de tratamento que toma certo tempo para ser realizada,
tempo este que envolve a duração da permanência da ficha no lugar considerado.
No seu modelo original, uma Rede de Petri permite descrever o fluxo dos tratamentos
a serem realizados, ou melhor, a estrutura de controle do sistema sob estudo. Entretando,
nem sempre determinados tratamento são imediatamente realizados a partir do momento
em que o tratamento precedente foi finalizado. Ainda, a sua realização ou não pode estar
associada a condições verificadas sobre as estruturas de dados do sistema (condições do
tipo if, por exemplo). Estas situações podem ser representadas por um trecho de Rede de
Petri, caracterizado por diversos lugares e transições que irão expressar as restrições
associadas ao tratamento.
Do ponto de vista da teoria das Redes de Petri, tais condições representam
situações de conflito, onde o disparo das próximas transições depende da verificação de
propriedades associadas às estruturas de dados do sistema. Por exemplo, num protocolo de
comunicação, a ação a ser tomada por uma entidade de protocolo depende fortemente dos
campos da PDU recebida.
No caso de sistemas que interagem com o ambiente, podem existir condições
suplementares de disparo associadas às transições (ou aos lugares). Estas ações
(tratamentos particulares) e estas condições estarão relacionadas a dados ou eventos
externos, como sensores, atuadores, recebimentos ou envios de mensagem. Os relógios de
tempo real podem também representar um aspecto importante no comportamento dos
sistemas e o tempo intervem de forma explícita.
P1 P2
P1 P2
t1
t Atividade Atividade
t2
P3 P4
P3 P4
Figura 8.11 — Associação de uma atividade a uma transição.
— 8.13 —
4.1.3. Controle, Dados e Ambiente
Para que se possa realizar o modelo de um sistema aberto (um sistema que se
comunique freqüentemente com o ambiente), é importante que e Rede de Petri possa ser
estruturada em duas partes, que permitam explicitar os elementos que compõem o sistema
sob estudos e aqueles que caracterizam o ambiente.
Além disso, é importante explicitar as partes da rede que estão associadas ao
controle e aquela que representa os aspectos relacionados aos dados do sistema. Além dos
dados internos, pode ser importante representar o tempo e os dados trocados com o
ambiente.
4.1.4. Representação Explícita do Tempo
A representação explícita do tempo pode ser feita a partir de variáveis booleanas que
serão associadas a condições e ações associadas às transições. Os valores destas
variáveis são, obviamente, dependentes do tempo.
Consideremos mon(θ) uma variável booleana dependente do tempo. Se é atribuído a
ela o valor 0, ela pode reassumir o valor 1 após um determinado período de tempo (um
monoestável). Vamos supor que no momento do disparo de uma transição t1, esta variável
seja colocada a 0. Se uma dada transição t2 que fica sensibilizada imediatamente após o
disparo de t1 tem, associada a ela a condição mon(θ) = 1, então, o intervalo de tempo entre
o disparo de t1 e o disparo de t2 será igual a θ.
4.2. Análise de Redes de Petri Interpretadas
4.2.1. Resultados
É importante notar que uma Rede de Petri ordinária descreve apenas a parte controle
de um sistema. Neste caso, a marcação da Rede de Petri vai fornecer apenas informações
sobre o estado de controle do sistema. Numa Rede de Petri interpretada, o estado do
sistema será descrito pela marcação associada ao estado dos dados. Sendo assim, numa
Rede de Petri interpretada:
Estado do Sistema = Marcação + Estado dos Dados
Estado dos Dados = Estado das Variáveis Internas + Tempo
Por outro lado, é preciso observar que a evolução da marcação numa Rede de Petri
interpretada vai estar relacionada a restrições da evolução da marcação de uma Rede de
Petri ordinária. Por esta razão, pode-se dizer que o conjunto das marcações acessíveis de
uma Rede de Petri interpretada é um subconjunto daquele das marcações acessíveis de
uma Rede de Petri ordinária. Entretanto, para que uma transição possa ser disparada numa
Rede de Petri interpretada, é preciso que ela possa ser disparada na Rede de Petri ordinária.
Mas, a interpretação pode levar ao fato de que uma transição que é disparável numa Rede
de Petri ordinária pode, num dado instante não ser disparável numa Rede de Petri
interpretada, em função das restrições impostas no modelo (por exemplo, a progressão do
tempo, o valor de uma variável, etc...).
Sendo assim, do ponto de vista de análise de uma Rede de Petri, é importante
observar as seguintes relações.
Rede de Petri Autônoma Rede de Petri Interpretada

k-limitada para M k-limitada para estado
f invariante de lugar f invariante de lugar
— 8.14 —
Por outro lado:
Rede de Petri Autônoma Rede de Petri Interpretada

Viva (≠) Viva
Reinicializável (≠) Reinicializável
4.3. Outros Modelos de Redes de Petri
As Redes de Petri Interpretadas permitem expressar, de forma bastante precisa, a

parte controle de um sistema ou protocolo de comunicação. Por outro lado, a representação
da parte dados não é o forte deste modelo.
Em razão disto, muitos trabalhos foram desenvolvidos em torno das Redes de Petri
com o objetivo de oferecer um mecanismo de estruturação que permita isolar dados locais e
dados globais. Nas seções seguintes, serão apresentados os modelos de Redes de Petri
Coloridas, as Redes de Petri Predicados-Transições, as Redes de Petri Temporais e as
Redes de Petri Temporizadas.
5. REDES DE PETRI COLORIDAS
5.1. Características do Modelo
A separação entre o que é a parte dados e a parte controle num sistema não é
necessariamente evidente, sendo, na maior parte das vezes tomada pelo desenvolvedor no
momento da Análise de Requisitos e do Projeto do Sistema. No limite, toda a parte controle
do sistema pode ser integrada às condições de execução dos tratamentos e ser
representada estruturalmente por uma Rede de Petri. Por outro lado, se o desenvolvedor
atribui muito do comportamento à parte controle, o modelo em Rede de Petri pode tornar-se
extremamente complexo e de difícil representação e análise.
Uma técnica que permite expressar sistemas complexos por modelos relativamente
simples é, quando possível, replicar conjuntos de processos similares (com a mesma
estrutura de controle) numa única componente conservativa. O inconveniente desta técnica
é a perda do aspecto individualidade comportamental que cada processo pode apresentar,
levando em conta, principalmente, a parte dados a que cada processo pode estar sujeito.
A idéia de individualizar as fichas numa Rede de Petri permite replicar os
comportamentos de vários processos por uma única estrutura de Rede sem correr o risco
de perder informação sobre sua individualidade.
Vamos tomar como exemplo a Rede de Petri da figura 8.12, que descreve um
problema clássico de algoritmo distribuído, no caso o problema dos leitores e escritores. No
exemplo, são representados 3 leitores e 1 escritor. Não é difícil observar que os três leitores
apresentam estrutura comportamental idêntica e, utilizando esta identidade, é possível
replicar seus lugares e suas transições numa única estrutura. O resultado desta replicação é
mostrado na figura 8.13. A grande vantagem desta estratégia é a obtenção de um modelo
mais simples para construção e para análise. Por outro lado, perde-se informação, pois
quando um leitor evolui, é impossível conhecer sua identidade.
5.2. Associando «Cores» às Fichas
Uma forma de diferenciar as fichas numa Rede de Petri é associar a elas «cores»,
que são expressas na forma de números inteiros ou de conjunto de etiquetas.
Conseqüentemente, associa-se cada lugar um conjunto de cores de fichas que podem
posicionar-se nele. Ainda, associa-se a cada transição um conjunto de cores que
corresponde às possibilidades de disparos da transição.
No caso mais simples, quando todos os processos possuem rigorosamente a
mesma estrutura de controle, o conjunto de cores para os lugares e para as transições são
— 8.15 —
os mesmos, sendo que as cores serão, usualmente, associadas às diferentes instâncias de

processos.
11 12 13 1E
d1 d2 d3 dE
21 22 23 2E
a1 a2 a3 aE
3
31 32 33 3E
3
f1 f2 f3 fE
Figura 8.12 — Rede de Petri representando o problema dos leitores x escritores.
1L 1E
dL dE
2L 2E
aL aE
3
3L 3E
3
fL fE
Figura 8.13 — Problema dos leitores x escritores com replicação dos leitores.
ini
peça máquina
id
PI US MA
peça máquina
fim
Figura 8.14 — Exemplo de Rede de Petri Colorida.
— 8.16 —
No caso do problema dos leitores e escritores, por exemplo, os processos

correspondem à identidade dos leitores, o que implica que os lugares 1L, 2L e 3L e as
transições dL, aL e fL podem ter associado o conjunto (L1,L2,L3).
Por outro lado, quando os lugares são comuns a diversos processos, é necessário
introduzir o conceito de «cores compostas». A Rede de Petri da figura 8.14 ilustra o modelo
de uma linha de montagem composta por duas máquinas e dois tipos de peças a serem
usinadas.
O lugar PI possue as cores pi1 e pi2 que correspondem aos nomes das peças, o
lugar MA as cores ma1 e ma2 que são os nomes das máquinas e o lugar US vai conter as
cores pi1.ma1, pi1.ma2, pi2.ma1 e pi2.ma2 que correspondem às diversas operações
possíveis, e que serão denotadas u11, u12, u21 e u22.
5.2. Associando Funções aos Arcos
Numa Rede de Petri Colorida, os arcos não são mais representados por números
inteiros, mas devem ser especificadas as ações que deverão ser realizadas considerando
cada cor possível num lugar. Cada arco deverá ter, então, associado a ele, uma matriz cujas
linhas serão as possibilidades de disparo da transição e as colunas as possíveis cores das
fichas nos lugares. Retomando o exemplo da figura 8.14, pode-se verificar que, no caso do
arco que conecta o lugar PI à transição ini e o arco que conecta MA a ini, serão descritos
por:
pi1 pi2 ma1 ma2
u11 1 0 u11 1 0
u22 1 0 u22 0 1
u21 0 1 u21 1 0
u22 0 1 u22 0 1
5.3. Definição Formal de uma Rede de Petri Colorida
Uma Rede de Petri Colorida associada a uma marcação inicial é um hexupla dada
por:
NC = <P,t,Cor,Csc,W,M0>
Onde:
• P, é um conjunto finito de lugares;

• T, é um conjunto finito de transições;
• Cor , é um conjunto finito de cores;
• Csc , é uma função subconjunto de cores associada a cada lugar e a cada
transição;
• W, é a função de incidência (equivalente a C = Pre – Post); cada elemento
de W corresponde a uma função do tipo:
W(p,t) : Csc (t) x Csc (p) → Ν1
• M 0, é a marcação inicial para cada lugar e para cada cor possível neste
lugar:
M 0(p) : Csc (p) → Ν
1
Ν é o conjunto dos naturais.
— 8.17 —
5.4. Exemplo
Retomando o exemplo da figura 8.14, teremos:
• Cor = {pi1,pi2,ma1,ma2,u11,u12,u21,u22}
• Csc(PI) = {pi1,pi2}
• Csc(MA) = {ma1,ma2}
• Csc(US) = Csc(ini) = Csc(fim) = {u11,u12,u21,u22}
• as funções definidas para W são:
§ id(uij) = uij
§ máquina(uij) = maj
§ peça(uij) = pii
• a matriz W fica:
 − peça peça 

W = id − id 
§
− máquina máquina 
• a marcação inicial M 0:
 1 1 0 0 0 0 0 0
§ M 0 =  0 0 0 0 0 0 0 0
 0 0 1 1 0 0 0 0
6. REDES DE PETRI PREDICADOS-TRANSIÇÕES
6.1. Variáveis
Nas Redes de Petri Coloridas, o poder de expressão é reforçado pela substituição

dos números inteiros da matriz de incidência de uma Rede de Petri Ordinária por funções.
Nas Redes de Petri Predicados-Transições, as transições de uma Rede de Petri Ordinária
são consideradas como regras num sistema de lógica proposicional e o poder de expressão
é reforçado pela substituição das transições por regras de uma lógica de primeira ordem,
onde variáveis são consideradas. Uma regra (ou transição) descreve um conjunto de
eventos e não mais um único evento. O conjunto de eventos é descrito pelo conjunto das
possíveis substituições das variáveis por valores.
Desta forma, em lugar de regras do tipo...
SE pelo menos uma peça e pelo menos uma máquina, FAZER usinagem
teremos regras do tipo...
SE uma peça <x> e uma máquina <y>, FAZER usinagem <u>

As variáveis <x>, <y> e <u> assumirão valores num conjunto de constantes
descrevendo as peças em espera na usinagem e as máquinas livres. Estas constantes
assumem um papel análogo ao das cores numa Rede de Petri Colorida. As variáveis são
associadas aos arcos da Rede de Petri, em lugar das funções definidas nas Redes de Petri
— 8.18 —
Coloridas. Para o exemplo considerado anteriormente, a Rede de Petri Predicados-

Transições que o representa está ilustrado na figura 8.15.
Numa Rede de Petri Predicados-Transições não se tem a necessidade de definir a
priori que fichas deverão estar presentes nos lugares como se faz no caso das Redes de
Petri Coloridas (ver o exemplo descrito pela figura 4.6). Isto é definido pelas próprias regras
associadas aos arcos, ou seja, uma vez que se conhece os possíveis valores a serem
assumidos pelas variáveis, a cada vez que a transição for disparada, basta avaliar os valores
de cada variável para se conhecer em que condições ela foi disparada.
O mecanismo de substituição das variáveis por constantes no momento do disparo
de uma transição é denominado unificação. Quando o mecanismo de unificação produz
mais de uma solução, considera-se a ocorrência de um conflito. O espaço de conflito
compreende todas as transições habilitadas para uma dada marcação e, para cada
transição, o conjunto de substituições possíveis.
Para permitir a escolha das fichas e transições a serem disparadas, associa-se
condições suplementares de disparo (por exemplo, especificar que determinadas máquinas
só podem manipular algumas peças), como no caso das Redes de Petri Interpretadas.
Entretando, estas condições influem apenas nas constantes a serem associadas às
fichas, ou melhor, sobre as constantes que substituem as variáveis no momento do disparo
das transições. As condições são escritas como funções das variáveis associadas aos
arcos de entrada e de saída da transição.
6.2. Noção de n-upla de Constantes e Variáveis
No momento do disparo da transição ini, toma-se uma constante representando uma

peça no lugar PI, uma outra representando uma máquina no lugar MA e coloca-se no lugar
US uma constante que representa a relação temporária entre a peça e a máquina. No
momento do disparo da transição fim, o contrário é efetivado.
Em lugar de codificar este relacionamento temporário de duas informações, pode-se
justapor numa lista (como se fosse um record de Pascal), exceto que existirá uma relação
temporária no momento do disparo da transição. Desta forma, estabelece-se uma relação
dinâmica entre as constantes.
Estas listas de constantes serão denominadas n-uplas. Desta forma, no lugar US, a
constante u12 será substituída pela n-upla <pi1,ma1>. A marcação não será mais uma
distribuição de constantes nos lugares mas uma distribuição de n-uplas de constantes. A
figura 8.16 apresenta a Rede de Petri Predicados-Transições para o exemplo do sistema de
produção utilizado para ilustrar os diversos modelos aqui apresentados.
6.3. Definição Formal das Redes de Petri Predicados-Transições
Uma Rede de Petri Predicados-Transições inicialmente marcada é uma tripla:
NPT = <R,A,M0>
Onde:
• R, é uma Rede de Petri Ordinária <P,T,C>, C = Post - Pre;

• A, é a anotação de N, A = <Const,V,Atc,Ata,Ac>:
• Const , é um conjunto de constantes (o conjunto dos N, por exemplo);
• V, é um conjunto de variáveis formais que serão substituídas por
constantes de Const no momento do disparo das instruções;
• Atc, é uma aplicação: Atc :T → Lc(Const,V) associando a cada transição
uma condição sob a forma de predicado, utilizando constantes e
variáveis formais;
— 8.19 —
ini
<x> <y>
<u>
PI US MA
<u>
<x> fim <y>
Figura 8.15 — Exemplo de Rede de Petri Predicados-Transições.
ini
<x> <y>
<x,y>
PI US MA
<x,y>
<x> <y>
fim
Figura 8.16 —Rede de Petri Predicados-Transições fazendo uso n-uplas.
• Ata, é uma aplicação: Ata :T → La(Const,V) associando a cada transição

uma ação sob a forma de predicado, utilizando constantes e variáveis
formais;
• Ac, é uma aplicação associando a cada arco (elemtno de C) uma
soma formal de n-uplas de elementos de V de tal forma que o módulo
(soma de todos os elementos) seja igual ao peso do arco
correspondente;
• M 0, é a marcação inicial para cada lugar associando uma soma formal de
n-uplas de constantes de Const.
6.4. Exemplo
Na definição das Redes de Petri Predicados-Transições aparece a noção de rede

subjascente, obtida a partir da substituição das variáveis por um peso unitário que permite
explodir as n-uplas. A figura 8.17 representa a rede subjascente da figura 8.16. Este modelo
define, de fato, a estrutura de controle do sistema representado, uma vez que a Rede de
Petri Predicados-Transições é uma forma estruturada de expressar o conjunto
controle/dados de um sistema.
Com este exemplo, tem-se:
• Const = {pi1,pi2,ma1,ma2}
• V = {x,y}
• neste exemplo, não foram definidas nem condições, nem ações
— 8.20 —
ini
2
PI US MA
2
fim
Figura 8.17 —Rede subjascente para a rede da figura 8.16.
ini fim
PI -<x> <x> PI <pi1>+<pi2>
Ac = US <x,y> -<x,y> M0 = US 0
MA -<y> <y> MA <ma1+ma2>
7. REDES DE PETRI TEMPORIZADAS
Uma Rede de Petri Ordinária descreve uma relação de causalidade entre eventos.
Um evento a é a causa de b, a sempre precede b, a e b são ordenados no tempo. O tempo é
levado em conta apenas de maneira qualitativa. Entretanto, a consideração do tempo de
forma quantitativa é um requisito importante na descrição de muitos sistemas de software,
principalmente no caso de aplicações distribuídas e protocolos de comunicação.
Numa Rede de Petri Temporizada, o tempo é diretamente associado à Rede de Petri,
integrando-se à parte controle do sistema.
7.1. Associando o Tempo aos Lugares
Como foi visto no início deste capítulo, os lugares representam as atividades. Sendo
assim, a associação de tempo aos lugares objetiva descrever a duração da atividade. Pode-
se considerar que um lugar com uma duração associada pode ser descrito por uma
seqüência lugar-transição-lugar, onde o primeiro lugar corresponde à atividade em curso, a
transição representa o evento passagem do tempo e outro lugar corresponde a uma espera
pelo final da atividade (sincronização com outras atividades). Esta correspondência é
ilustrada na figura 8.18.
7.2. Associando o Tempo às Transições
Esta associação tem sentido quando se considera a transição como uma atividade e
não como um evento instantâneo. Uma atividade deve ser vista como uma ocorrência
ininterruptível sob a ótica do comportamento global do sistema sob análise.
Pode-se considerar que esta transição pode ser expressa por uma seqüência
transição-lugar-transição, na qual a primeira transição corresponde a um evento instantâneo
de início de atividade, o lugar corresponde à atividade em curso e a última transição
corresponde a outro evento instantâneo de fim de atividade. Esta equivalência é ilustrada na
figura 8.19.
— 8.21 —
t1
t1 duração p indisponível
duração p
t2 p disponível
t2
Figura 8.18 —Tempo associado a um lugar.
O disparo da primeira transição seguindo o lugar p1 corresponde à reserva de fichas

(as fichas reservadas não podem mais ser utilizadas para o disparo de outra transição
senão a transição t). Após o disparo da segunda transição, as fichas são, finalmente,
liberadas.
Neste caso, da mesma forma que no caso anterior, existem fichas que desaparecem
ou que tornam-se indisponíveis durante um certo intervalo de tempo e, em seguida,
reaparecem na marcação. Comparando-se as duas figuras, observa-se que as duas
abordagens são equivalentes.
7.3. Definição Formal
Uma Rede de Petri Temporizada é um par Nt = <N,θf> com:.
• N é uma Rede de Petri <P,T,Pre,Post> com uma marcação inicial M 0;

• θf é a função duração de disparo: θf : T → ℜ+ , que a cada transição estabelece a
correspondência entre um número racional positivo descrevendo a duração do
disparo.
8. REDES DE PETRI TEMPORAIS
8.1. Representando Timeouts
Alguns mecanismos implicam na colocação em disponibilidade das fichas num

determinado instante. A figura 8.20 apresenta um caso típico onde este tipo de mecanismo é
implementado. O lugar rotulado espera permita a recepção (disparo da transição fim1) na
ocorrência de um evento (condição verdadeira) sob a forma de uma ficha no lugar condição.
Mas, se a ficha não estiver posicionada ao final de um tempo θ, então um alarme é ativado
(disparo da transição fim2). Um tempo de atividade associado à transição espera atrasaria o
disparo da transição fim1 mesmo com a existência de uma ficha no lugar condição. Um
tempo de atividade associado à transição fim2 faria com que a ficha no lugar espera fosse
imediatamente absorvido de forma irreversível e que o alarme fosse então disparado após o
intervalo de tempo θ mesmo se uma nova ficha chega no lugar condição.
A solução é a introdução de uma duração de habilitação θs(t) a cada transição. Uma
transição t só pode disparar se ela fica habilitada durante o intervalo θs(t). A diferença com
relação as durações de disparo é que durante este intervalo as fichas estão disponíveis nos
lugares de entrada de t e podem eventualmente ser utilizadas por uma transição em conflito
com t.
— 8.22 —
Se reconsideramos o exemplo apresentado acima, basta associar uma duração θs à

transição fim2 igual ao valor do tempo de espera e a fim1 uma duração de sensibilização
imediata.
p1
p1 reserva p/ t
t duração
p2 t
p2
Figura 8.19 —Tempo associado a uma transição.
condição
espera
fim2 [θ,θ] fim1 [0,0]
alarme seqüência
normal
Figura 8.20 —Exemplo de Redes de Petri Temporais.
O domínio principal de utilização deste modelo (a validação de protocolos de

comunicação) fez com que, desde o início, foi definida uma duração imprecisa de
sensibilização de t sob a forma de um intervalo i(t) = [θs,min(t), θs,max(t)]. A transição t só pode
ser disparada após o tempo θs,min(t) e não poderá mais ser disparada após a passagem do
tempo θs,max(t). Todos os valores dentro do intervalo definido serão valores possíveis para
disparo de t.
8.2. Definição Formal
Uma Rede de Petri Temporal é um par Ntl = <N,I> onde:
• N é uma Rede de Petri <P,T,Pre,Post> com uma marcação inicial M 0;

• I é uma função que a cada transição t associa um intervalo fechado racional i(t)
= [θs,min(t), θs,max(t)], que descreve uma duração de sensibilização.
— 8.23 —
8.3. Comparação com outros modelos
As Redes de Petri Temporais são mais genéricas que as Redes de Petri

Temporizadas, porque elas permitem a descrição de timeouts que aqueles modelos não
permitem. Por outro lado, para passar de uma Rede Temporizada a uma Rede Temporal,
basta substituir cada transição t do primeiro par por uma seqüência [t1,t2] com:
• θs,min(t1) = θs,max(t1) = 0 e θs,min(t2) = θs,max(t2) = θ(t)
Por outro lado, pode-se dizer que uma Rede de Petri Ordinária é uma Rede de Petri
Temporal onde todas as transições possuem intervalos de sensibilização igual a [0,∞].
9. CONCLUSÃO
Neste capítulo foram apresentados os principais conceitos associados às Redes de

Petri e a suas extensões. Como pôde ser observado, os mecanismos presentes neste
formalismo permitem expressar de forma bastante precisa os relativos a um vasto leque de
aplicações, incluindo os sistemas de produção, software distribuído, sistemas operacionais,
interfaces homem máquina e protocolos de comunicação, entre outras.
O poder de expressão dos diversos modelos de Redes de Petri permitem
representar e obter informações interessantes nas etapas iniciais da concepção de sistemas
e, por isso, sua aplicação à área dos protocolos de comunicação foi uma conseqüência
inevitável.
No capítulo que segue, serão descritos alguns resultados da aplicação deste
formalismo à área dos protocolos de comunicação.
— 8.24 —
Capítulo 9
A T É C N I C A E STELLE
1. INTRODUÇÃO
No capítulo 7, foram apresentados os principais aspectos relativos à concepção dos

protocolos de comunicação, do ponto de vista das etapas do desenvolvimento e das
técnicas associadas a cada uma das etapas.
As técnicas de descrição formal, que serão apresentadas nesta seção,
desempenham um papel importante na Engenharia de Protocolos. Estas técnicas são
baseadas principalmente em modelos já citados na parte anterior do documento (máquinas
de estados finitos, álgebra de processos), apresentando fatores importantes para a
representação dos aspectos relativos à estruturação de uma camada de protocolo e ao
comportamento das entidades de protocolo compondo a camada.
Esta parte do documento pretende dar uma breve introdução às técnicas de
descrição formal, dando ênfase à técnica Estelle, padronizada na ISO e aos trabalhos
realizados em torno desta técnica.
2. AS TÉCNICAS DE DESCRIÇÃO FORMAL PADRONIZADAS
Como já foi citado, a complexidade dos mecanismos a implementar no contexto de

um sistema distribuído, e, particularmente, no projeto das entidades de protocolo, requer a
utilização de modelos que permitam representar, de maneira precisa e não ambígua, o
paralelismo e a comunicação. Esta foi a principal motivação da definição das Técnicas de
Descrição Formal (ou FDT, Formal Description Techniques) para a especificação dos
protocolos e serviços do modelo OSI.
Os principais resultados deste esforço foram Estelle e LOTOS, padronizadas pela
ISO (International Standardization Organization) e a técnica SDL, definida no CCITT (Comité
Consultatif International Télégraphique et Téléphonique).
LOTOS (Language Of Temporal Ordering Specification) é uma técnica baseada na
álgebra de processos para a representação dos comportamentos paralelos. Uma
especificação LOTOS é composta de unidades executáveis denominadas processos, que
sincronizam-se através de portas de comunicação. A versão completa de LOTOS inclui uma
linguagem de descrição de tipos abstratos de dados, denominada ACT ONE, de forma que
dois ou mais processos sincronizando-se em portas de comunicação podem também trocar
valores representados neste formalismo. Um grande número de trabalhos foi desenvolvido
sobre LOTOS desde a sua definição, particularmente para a definição de metodologias e
ferramentas de concepção e a aplicação de LOTOS à especificação de protocolos de
comunicação.
SDL (Specification and Description Language) é uma linguagem de especificação
baseada no formalismo das máquinas de estados finitos comunicantes. Uma especificação
SDL é definida como sendo um sistema, este podendo ser decomposto em diversos blocos
que se executam concorrentemente e comunicam através de troca de mensagens,
— 8.1 —
CAP. 9 — A TÉCNICA ESTELLE PROF. VITÓRIO BRUNO MAZZOLA
denominadas sinais. O mecanismo de comunicação adotado aí é assíncrono (filas FIFO).

Do ponto de vista da estruturação de uma especificação SDL, um bloco pode, por sua vez,
ser decomposto em diversos blocos e assim por diante_ a decomposição feita no nível mais
baixo sendo em termos de processos. Similarmente a LOTOS, SDL representa os dados
através do formalismo de dados abstratos. Uma característica original de SDL é o fato de
que ela é definida segundo duas sintaxes de linguagem, uma versão textual (denominada
SDL/PR, SDL Phrase Representation) e uma versão gráfica (SDL/GR, SDL Graphical
Representation). No que diz respeito a esta técnica, diversas ferramentas foram realizadas
para a concepção de protocolos de comunicação e programas distribuídos, particularmente,
editores gráficos, simuladores, verificadores e geradores de código (SDL → C, SDL → ADA,
etc_).
No que diz respeito à técnica de descrição formal Estelle, a seção seguinte será
dedicada à apresentação, mais detalhada dos seus aspectos sintáticos e semânticos.
3. A TÉCNICA DE DESCRIÇÃO FORMAL ESTELLE
Estelle, Extended State Transition Language, é uma técnica de descrição formal

definida e padronizada pela ISO para a especificação formal de protocolos de comunicação
e sistemas distribuídos. O formalismo no qual se baseia esta técnica é aquele das máquinas
de estados extendidas, sendo que a representação e a manipulação de dados é possível
pela introdução de um subconjunto da linguagem Pascal à Estelle. Nas seções que seguem
apresentaremos, sucessivamente, os principais mecanismos de Estelle, as experiências
realizadas em torno desta técnica e um exemplo de aplicação ao domínio dos protocolos.
3.1 Arquitetura de uma Especificação Estelle
Uma especificação Estelle é composta de elementos sequenciais não

determinísticos chamados instâncias de módulo (module instances). Estes comunicam-se
por um mecanismo de troca de mensagens, ou interações (interactions), que são enviadas e
recebidas através de interfaces (ou portas) chamadas pontos de interação (interaction
points). A figura 9.1 ilustra estes conceitos.
Da mesma forma que uma especificação pode ser decomposta em módulos, como
é mostrado na figura 9.2, um módulo pode, por sua vez, ser decomposto em outros
módulos, estes em outros módulos, e assim por diante, o que dá um caractére hierárquico a
uma especificação. Se um determinado módulo é decomposto em outros módulos, diz-se
que estes são módulos filhos do módulo considerado; este, por sua vez, é considerado o
módulo pai daqueles módulos. A figura 9.2 mostra a decomposição do módulo A2 da figura
9.1 em dois módulos, A21 e A22. Seguindo a terminologia, A21 e A22 são módulos filhos de
A2, que é considerado o módulo pai destes dois módulos. Esta definição será posta em
evidência quando formos comentar os princípios de escalonamento envolvidos na execução
de uma especificação Estelle.
A arquitetura de uma especificação Estelle pode ser modificada em tempo de
execução, tanto do ponto de vista da sua composição em termos de módulos, como das
ligações entre os módulos existentes. Veremos mais tarde como isto é implementado.
Do ponto de vista sintático, uma especificação Estelle é assim definida:
specification <id_especificação> [<atributo>]

[default <disciplina_fila>]
[timescale <unidade_tempo>]
_
end.
Nas definições sintáticas da técnica Estelle realizadas neste documento, a seguinte

notação será adotada:
• expressões em negrito correspondem a palavras reservadas da linguagem;
— 9.2 —
• expressões colocadas entre “<“ e “>“ correspondem a partes da especificação

(identificadores, parâmetros, _) a serem definidos pelo usuário;
• expressões colocadas entre “[“ e “]” correspondem a comandos opcionais da
especificação;
• os “_” correspondem a partes (instruções, blocos de instrução, declarações, etc_)
existentes, mas irrelevantes para a definição considerada.
Na declaração Estelle mostrada acima, o comando opcional default permite definir a

disciplina de filas a ser adotada por default na especificação. As disciplinas de fila serão
definidas posteriormente neste documento. O comando (também opcional) timescale
permite definir a unidade de tempo adotada para propósitos de temporização (ver definição
da cláusula delay).
3.2. Os Módulos Estelle
Um módulo é um objeto a partir do qual são derivados os componentes executáveis

de uma especificação Estelle — as instâncias de módulo. As características de um módulo
Estelle são obtidas graças a duas definições que são o tipo de módulo (module header) e o
corpo de módulo (module body), estes conceitos sendo ilustrados pela figura 9.3.
especificação
A0
A1 A2
instância de módulo
ponto de interação
A3
Figura 9.1 - Conceitos associados a uma especificação Estelle.
A2
A21
A21 e A22 são módulos
filhos do módulo A2
A22
Figura 9.2 - Ilustração da decomposição de um módulo Estelle.
— 9.3 —
O tipo de módulo permite definir as interfaces de acesso ao módulo, seja do ponto de

vista das mensagens — interações — que podem ser trocadas com os demais módulos,
como do ponto de vista das variáveis acessíveis externamente — as variáveis exportadas.
As variáveis exportadas de um módulo A são aquelas variáveis visíveis ao módulo
imediatamente superior na hierarquia (o módulo pai). Assim, este módulo terá direito de
acesso à leitura e escrita sobre todas as variáveis de A que tenham sido declaradas como
variáveis exportadas. Na sua forma mais geral, um tipo de módulo é declarado da seguinte
forma em Estelle:
module <id_tipo_módulo> <atributo>;

ip <lista_de_pontos_de_interação>
export <lista_de_variáveis_exportadas>
end;
O corpo de módulo é o objeto que permite declarar o comportamento interno de um

módulo, através da definição de uma máquina de estados extendida. Vários corpos de
módulo podem ser associados a um mesmo tipo de módulo, o que significa que é possível
definir módulos apresentando a mesma interface mas com comportamentos internos
distintos. A declaração de um corpo de módulo é feita da seguinte maneira:
body <id_corpo> for <id_tipo_módulo>;

...
end;
, onde id_tipo_módulo designa o tipo do módulo ao qual o corpo estará associado.
3.3. A Comunicação entre Instâncias de Módulo
As instâncias de módulo em Estelle comunicam-se graças à definição de canais

bidirecionais que efetuam a ligação entre seus pontos de interações. Uma fila de política
FIFO (First-In-First-Out) é associada a cada uma das extremidades de um canal, de modo
que uma mensagem enviada por um módulo é armazenada na fila associada à extremidade
oposta àquela do canal por onde esta foi enviada, caracterizando, assim, um mecanismo de
comunicação assíncrona.
tipo de módulo
B instâncias
módulo de módulo
corpo de módulo
Figura 9.3 - Definição de módulos e instâncias de módulos.
— 9.4 —
Isto significa que não existe um compromisso estabelecido entre a emissão e a

recepção de uma mensagem; não existindo também bloqueio ao envio de uma mensagem
se o módulo receptor não se encontra pronto para consumí-la.
Em Estelle, um canal é declarado da forma:
channel <id_canal> (r1,r2);

by r1 : <lista_interações_r1>
by r2 : <lista_interações_r2>
Nesta declaração, além do identificador do canal (id_canal), devem ser declaradas as

diferentes interações que serão enviadas pelas duas extremidades do mesmo. Isto é feito
considerando os dois sentidos, formalizados aqui através dos papéis (role), simbolizados
nesta declaração por r1 e r2. Estes não são identificadores reservados, mas podem ser
definidos pelo usuário conforme o significado do canal dentro da especificação — por
exemplo, usuário e fornecedor, mestre e escravo, produtor e consumidor, etc_
As interações definidas na declaração dos canais permitem definir diferentes tipos ou
classes de mensagens sendo trocadas entre duas ou mais instâncias de módulos. A
declaração das interações não implica, porém, na declaração de valores associados. Para a
definição de valores, devem ser associados parâmetros (variáveis Pascal) às interações,
como é mostrado no exemplo abaixo:
channel C1 (cliente,servidor);
by cliente : pedido; servico(tipo:integer);
by servidor : resposta(resultado:boolean);
A declaração de canal serve de base para a declaração dos pontos de interação que
vão definir as interfaces de cada tipo de módulo, e que são feitas da maneira seguinte:
ip <id_ip> : <id_canal>(r);
Assim, além do identificador do canal (id_canal), deve-se também definir o sentido r

ao qual será associado o ponto de interação identificado por id_ip. Isto vai permitir a definição
das interações que poderão ser emitidas pelo módulo que possui o ponto de interação
declarado.
Cabe aqui a ilustração destes conceitos atraves de um exemplo simples. Vamos
supor um trecho de uma especificação formal em Estelle, onde as seguintes declarações
são definidas:
specification exemplo1;
_
_
channel C1 (mestre,escravo);
by mestre : ordem_inicio; pedido_status;
by escravo : resposta_serviço; info_status;
module tipo_cliente;
ip A : C1(mestre);
end;
module tipo_servidor;
ip B : C1(escravo);
end;
_
_
end.
— 9.5 —
Como podemos ver, os dois sentidos definidos na declaração do canal C1 são

mestre e escravo, aos quais estão associadas as interações ordem_inicio, pedido_status e
resposta_serviço, info_status, respectivamente. Assim, se considerarmos as declarações
dos módulos tipo_cliente e tipo_servidor, notamos que os pontos de interação A e B fazem
referência à declaração do canal C1, definindo, respectivamente, os papéis mestre e
escravo. Isto significa que as instâncias de módulo derivadas do tipo de módulo tipo_cliente
poderiam enviar, através do ponto de interações A, as interações ordem_inicio e
pedido_status e poderiam receber, por este ponto, as interações resposta_serviço e
info_status. Analogamente, as instâncias de módulo derivadas do tipo de módulo
tipo_servidor poderiam enviar, através do ponto de interações B, as interações
resposta_serviço e info_status e poderiam receber, por este ponto, as interações
ordem_inicio e pedido_status.
No caso de módulos que possuam n pontos de interações similares, a declaração
pode ser feita segundo um vetor ou um vetor de pontos de interação:
ip <id_ip> : ARRAY[1..n] OF <id_canal>(r);
Neste caso, da mesma forma que um elemento de uma matriz definida na linguagem
Pascal, o ponto de interação deverá ser designado pelo seu identificador, acompanhado do
índice correspondente no vetor. A figura 9.4 ilustra o caso de um módulo possuindo 6 pontos
de interação similares.
A associação de filas FIFO aos pontos de interação obedece a duas políticas
distintas:
• na primeira, a fila individual (individual queue), uma fila é associada a cada ponto de
interação;
• na segunda, a fila comum ou global (common queue) a fila é compartilhada por
diversos pontos de interação.
Embora as duas políticas possam coexistir no contexto de uma mesma
especificação Estelle, a sua definição é obrigatória no contexto da declaração dos pontos de
interação, isto podendo ser feito de duas maneiras:
• explícita, na declaração do ponto de interação

(Ex.: ip A : F_D (fonte) individual queue; );
• implícita, através da cláusula default
(Ex.: default individual queue;).
module tipo_A;
ip a : ARRAY[1..6] OF Ca(r1);
end;
a[1] a[2] a[3] a[4] a[5] a[6]
Figura 9.4 - Módulo definindo 6 pontos de interação similares.
— 9.6 —
3.4. Exemplo 1 - O protocolo mestre-escravo
A figura 9.5 representa o exemplo mostrado na seção 3 da parte anterior do

documento (figura 10.11). Como, em Estelle, os canais são bidirecionais, representamos por
um único canal a comunicação nas duas direções consideradas.
Os pontos de interação F e D representam, respectivamente, as portas de
comunicação das entidades fonte e destino com o meio de comunicação. Estes pontos de
interação são conectados, respectivamente, aos pontos A e B do módulo representando o
meio.
Desta forma, a declaração dos objetos Estelle representando a arquitetura mostrada
na figura 9.5 fica como mostrado a seguir.
Esta especificação apresenta unicamente a declaração dos objetos representando
cada elemento da especificação, particularmente, os canais, as interações, e os tipos de
módulos (e seus respectivos pontos de interação) que definirão a estrutura da especificação.
specification mestre_escravo systemactivity;

_
_
channel F_D (fonte,destino)
by fonte : pedido_envio; dado;
by destino : pronto_recepção; dado_consumido;
module tipo_fonte activity;

ip F : F_D(fonte);
end; { tipo_fonte }
module tipo_destino activity;

ip D : F_D(destino);
end; { tipo_destino }
module tipo_meio activity;

ip A : F_D(destino);
B : F_D(fonte);
end; { tipo_meio }
_
_
end. { mestre_escravo }
MESTRE_ESCRAVO
FONTE DESTINO
F D
A B
MEIO
Figura 9.5 - Estrutura da especificação do protocolo mestre-escravo.
— 9.7 —
A estrutura da especificação só será concretizada através da execução de instruções

de estruturação, presentes numa parte de inicialização da especificação.
3.5. Instruções de estruturação de uma especificação
O nível de superior de uma especificação Estelle é caracterizado, geralmente por

duas partes distintas — a parte declaração e a parte inicialização.
A parte declaração caracteriza as declarações dos objetos Pascal (tipos, variáveis,
funções e procedimentos) e dos objetos Estelle (canais, tipos de módulo, corpos de módulo,
pontos de interação, etc_) como apresentados nas seções anteriores. Os objetos Pascal
são declarados em Estelle de maneira análoga a um programa naquela linguagem de
programação (type, var, function e procedure). Esta parte contém, ainda, a declaração
das variáveis módulo que permitem referenciar as instâncias de módulo que vão compor a
especificação. As variáveis módulo são declaradas de maneira análoga às variáveis Pascal,
utilizando a cláusula modvar, sendo que os tipos associados às variáveis módulo devem ser
os identificadores designados nas declarações dos tipos de módulo da especificação.
Podemos representar, sintaticamente, a declaração de variáveis módulo da seguinte
forma:
modvar
<id_varmod1> : <id_tipo1>;
<id_varmod2> : <id_tipo2>;
_
<id_varmod3> : <id_tipoN>;
Podemos utilizar, como exemplo, duas variáveis especificando os módulos entidades

fonte e destino e do módulo representando o meio de comunicação da especificação
baseada na figura 9.5. Deste modo, a declaração destas variáveis módulo ficaria.
modvar
fonte : tipo_fonte;
destino : tipo_destino;
meio : tipo_destino;
No caso de várias instâncias de módulo baseadas num mesmo tipo de módulo, as

variáveis podem ser declaradas na forma de um vetor Pascal, sendo que a referência a cada
instância será feita de forma indexada. O exemplo abaixo ilustra esta forma de declaração:
modvar
A : ARRAY[1..MAX] OF tipo_fonte;
A referência às instâncias de módulo geradas a partir desta declaração será, então,

feita da seguinte forma — A[1], A[2], _, A[MAX].
A parte de inicialização é a parte que vai dar «vida» a uma especificação Estelle. Ela
é caracterizada pela expressão Estelle initialize seguida de um bloco begin_end (como na
linguagem Pascal) cujas instruções vão permitir inicializar os objetos Pascal
(particularmente as variáveis) e os objetos Estelle. No que diz respeito aos objetos Estelle,
esta parte permite:
• inicializar (criar) as instâncias de módulo;

• inicializar a arquitetura da especificação efetuando as ligações dos pontos de
interação de cada instância de módulo criada para compor a especificação.
— 9.8 —
A criação das instâncias de módulo é feita através do comando init que vai permitir
inicializar uma variável módulo com um corpo de módulo declarado na especificação. O
formato geral deste comando é:
init <id_varmod> with <id_corpo>;
A necessidade da especificação do corpo no momento da criação da instância de

módulo se justifica pela possibilidade de atribuição de diferentes comportamentos a um
mesmo tipo de módulo. Naturalmente, apenas um corpo de módulo que tenha sido declarado
para o tipo de módulo que gerou a variável módulo pode ser especificado na sua criação.
No que diz respeito ao estabelecimento das ligações entre pontos de interação das
instâncias de módulo, dois comandos são disponíveis:
• o primeiro, connect, permite ligar dois pontos de interação de instâncias de módulo

localizadas no mesmo nível hierárquico;
• o segundo, attach, permite ligar um ponto de interação de uma dada instância de
módulo a um ponto de interação de uma instância de módulo filha da primeira
instância considerada.
Do ponto de vista sintático, estes comandos apresentam-se da seguinte forma:
connect <id_varmod1>.<id_ip> to <id_varmod2>.<id_ip>;

e
attach <id_ip> to <id_varmod2>.<id_ip>;
Como podemos ver, no caso do comando attach, não é necessário especificar uma
das instâncias, pois ela é conhecida implicitamente (é a instância na qual o comando está
sendo realizado). Os seguintes comentários podem ainda ser feitos com relação aos
comandos de estruturação de Estelle:
1 Os comandos connect e attach só podem ser executados sobre um par de

instâncias de módulo que tenha sido previamente inicalizado por comandos init;
2 Os comandos connect e attach só podem ser efetuados sobre dois pontos de
interação declarados a partir de um mesmo tipo de canal; ainda, no caso do
connect os pontos de interação devem ter papéis complementares (opostos); no
caso do attach os dois pontos de interação devem ter o mesmo papel;
3 Os comandos podem ser utilizados também durante a execução das transições
Estelle (como será definido mais adiante) caracterizando o aspecto dinâmico de
uma especificação Estelle (instâncias de módulo podem ser criadas e ligadas em
execução);
4 Finalmente, são definidas em Estelle instruções complementares (inversas) a
estas três, respectivamente release, disconnect e dettach.
Para ilustrar a utilização destes comandos, vamos retomar o exemplo ilustrado pela
figura 9.5, completando a especificação do ponto de vista das declarações e inicializações
dos objetos. Esta é mostrada a seguir.
3.6. A descrição do comportamento dos módulos (declaração do corpo)
Como já foi mencionado, o objeto que permite declarar a máquina de estados

representando o comportamento de um módulo é o corpo de módulo (module body).
— 9.9 —
specification mestre_escravo systemactivity;

default individual queue;
{ #### PARTE DECLARACAO #### }
channel F_D (fonte,destino)

by fonte : pedido_envio; dado;
by destino : pronto_recepção; dado_consumido;
module tipo_fonte activity;

ip F : F_D(fonte);
end; { tipo_fonte }
module tipo_destino activity;

ip D : F_D(destino);
end; { tipo_destino }
module tipo_meio activity;

ip A : F_D(destino);
B : F_D(fonte);
end; { tipo_meio }
body corpo_fonte for tipo_fonte;

_
end; { corpo_fonte }
body corpo_destino for tipo_destino;

_
end; { corpo_destino }
body corpo_meio for tipo_meio;

_
end; { corpo_meio }
modvar
fonte : tipo_fonte;
destino : tipo_destino;
meio : tipo_meio;
{ #### PARTE INICIALIZACAO #### }
initialize
begin
init fonte with corpo_fonte;
init destino with corpo_destino;
init meio with corpo_meio;
connect fonte.F to meio.A;
connect destino.D to meio.B;
end;
end. { mestre_escravo }
O objeto corpo de módulo é composto de três partes de base: a parte declaração,

análoga à da especificação, apresentada anteriormente, a parte inicialização, também similar
à da especificação e a parte transição que permite efetivamente descrever o comportamento
do módulo através de um conjunto de transições de uma máquina de estados.
— 9.10 —
Na parte declaração de um corpo de módulo, além da declaração dos objetos já

mencionados anteriormente (tipos, variáveis, funções e procedimentos Pascal, canais, tipos
de módulo e corpos de módulo das instâncias de módulo filhas, _), declara-se ainda, quando
for o caso (esta declaração é opcional), os estados globais (major states) da máquina de
estados considerada. Isto é feito através do comando Estelle, state cuja sintaxe geral é:
state id_estado1, id_estado2, _, id_estadoN;
Para o exemplo considerado na figura 9.5, a declaração dos estados globais para a
instância de módulo fonte ficaria, então:
state ocioso,pronto_envio,envio, espera_ack;
A parte inicialização, além da inicialização das variáveis Pascal e objetos Estelle

(instâncias de módulo e ligações), deve permitir definir o estado global inicial da máquina de
estados que representa o comportamento do módulo. Isto é feito associando-se a cláusula
to à expressão initialize que marca o início da parte inicialização da seguinte forma:
initialize to <id_estado_inicial>;
begin
_
end;
, sendo que id_estado_inicial deve ser um dos identificadores de estado global

declarados previamente através do comando state.
A parte transição permite definir o conjunto das transições que vai descrever o
comportamento dos módulos. Uma transição é caracterizada de três partes principais: a
parte pré-condições, a parte de pós-condições e a parte ação. A definição de uma ou mais
transições deve ser caracterizada pela definição de uma cláusula trans.
A parte pré-condições permite definir quais são as condições a serem satisfeitas

para que a transição seja considerada em condições de executar. As pré-condições são
definidas através de cláusulas Estelle, que são:
from
permite definir em que estado global deve encontrar-se o módulo para que a
transição esteja em condições de executar.
SINTAXE EXEMPLO
from <id_estado> from ocioso
when
permite definir a recepção de uma dada interação sobre um ponto de interação para
que a esteja em condições de executar.
SINTAXE EXEMPLO
when <id_ip>.interação when D.dado
no caso desta cláusula, a condição é satisfeita se a interação especificada encontra-

se no topo da fila FIFO associada ao ponto de interação considerado. Em caso, positivo, se
a transição é executada, a interação é retirada do topo da fila, caracterizando a recepção de
uma mensagem. Uma transição que não contenha uma cláusula when na sua parte de pré-
condições é dita uma transição expontânea, uma vez que esta não depende da recepção de
— 9.11 —
uma interação para executar (depende apenas de aspectos internos do módulo

considerado).
provided
permite testar uma condição na forma de uma expressão booleana, envolvendo
variáveis Pascal do módulo ou mesmo, no caso de uma transição contendo uma cláusula
when, parâmetros da interação especificada naquela cláusula.
SINTAXE EXEMPLO
provided <exp_booleana> provided dado_lido*
ou provided otherwise
*dado lido é uma variável booleana!
priority
permite associar um nível de prioridade de modo a modificar a política de
escalonamento entre as transições de um mesmo módulo.
SINTAXE EXEMPLO
priority <inteiro> priority 1
delay
permite associar um intervalo de tempo para fins de representação de mecanismos
de temporização (timeout, por exemplo). A semântica de tempo associada a esta cláusula
será explicada mais adiante. A cláusula delay não pode ser utilizada numa transição onde a
cláusula when esteja presente. Em outras palavras, esta só pode ser utilizada em
transições expontâneas, como definido anteriormente.
SINTAXE EXEMPLO
delay (T1,T2) delay (1,5)
A parte pós-condições permite definir o estado global que será assumido pelo módulo
após a execução da transição considerada. A cláusula de pós-condição definida em Estelle é
a cláusula to cuja sintaxe e exemplo de utilização são dados abaixo:
SINTAXE EXEMPLOS
to <id_estado> to espera_ack
ou to same to same
A parte ação de uma transição Estelle é caracterizada por um bloco begin_end em

cujo interior podem ser declaradas instruções Pascal (com restrições) e instruções Estelle.
A parte ação de uma transição Estelle é considerada um bloco atômico e indivisível, ou seja,
uma vez iniciada, ela não pode ter a sua execução interrompida.
Dentre as instruções Estelle podendo constituir a parte ação de uma transição, além
dos comandos init, connect, attach, release, disconnect e dettach, podemos citar o
comando output, que permite expressar o envio (não bloqueante) de uma interação através
de um ponto de interação, a sintaxe e um exemplo de utilização sendo dados a seguir.
SINTAXE EXEMPLOS
output <id_ip>.interação output F.dado
Convém, aqui, invocar os conceitos de instâncias de módulo ativas e inativas. Uma

instância de módulo é dita inativa se a sua parte transição é vazia. Caso contrário, ela é dita
ser uma instância de módulo ativa.
— 9.12 —
Além das instruções acima, Estelle oferece, ainda, algumas facilidades de

especificação, como, por exemplo:
• os comandos all e any;
• a fatorização (nesting) de transições;
• a nomeação de transições.
Os comandos all e any permitem simplicar uma sequência de comandos Pascal e

Estelle que deva ser feita de maneira repetitiva. Ambos são declarado de forma similar a
uma malha for do Pascal, com uma diferença fundamental. O acesso aos valores
estabelecidos no intervalo considerado é feito de maneira aleatória e não de maneira
ordenada. Exemplos da utilização destes dois comandos são mostrados a seguir:
• Comando all
all i : 1..n
do
begin
_ sequência de instruções _
end;
• Comando any (manipulação de vetores de pontos de interação)
any i : 1..n
do when ip_id[i].interação
A fatorização de transições permite simplificar a apresentação da especificação,

regrupando, a diferentes níveis, cláusulas comuns a diferentes transições. Por exemplo,
considerar o trecho de especificação abaixo:
trans
from ocioso
when D.pedido_envio
to pronto_recepcao
begin
output D.pronto_rec
end;
from ocioso
when D.dado
to same
begin
end;
Como podemos ver, a cláusula «from ocioso» é comum às duas transições. Assim,
elas podem ser fatoradas da seguinte forma:
trans
from ocioso
when D.pedido_envio
to pronto_recepcao
— 9.13 —
begin
output D.pronto_rec
end;
when D.dado
to same
begin
end;
Finalmente, a nomeação das transições permite enriquecer o poder de

documentação de uma especificação Estelle, através da cláusula name. O exemplo a seguir
ilustra a utilização desta cláusula.
trans
from ocioso
when D.pedido_envio
to pronto_recepcao
name aviso_dado:
begin
output D.pronto_rec
end;
Para ilustrar a descrição do comportamento em Estelle, vamos especificar o

comportamento da instância de módulo fonte do protocolo mestre-escravo definido na parte
anterior do documento. Para isto, podemos tomar como ponto de partida, a especificação
em máquinas de estados finitos daquela entidade, apresentada, aqui, na figura 9.6.
A especificação Estelle fica, então, da seguinte forma:
body corpo_fonte for tipo_fonte;
state ocioso,pronto_envio,envio,espera_ack;
initialize to ocioso
begin
end;
trans
from ocioso
when U.mensagem
to pronto_envio
begin
output F.pedido_envio;
end;
from pronto_envio
when F.pronto_rec
to envio
begin
{ preparacao do dado a enviar }
end;
trans
from envio
to espera_ack
begin
output F.envio_dado;
end;
— 9.14 —
trans
from espera_ack
when F.ack
to ocioso
begin
end;
end; { corpo_fonte }
Como podemos notar na especificação, foi considerado aí, um ponto de interação U,

através do qual é recebido o dado a ser enviado. Isto significa que a instância de módulo que
representa esta entidade é conectada, através deste ponto de interação, a uma instância de
módulo que representa o usuário do serviço oferecido.
3.7. Aspectos da execução de uma especificação Estelle
A execução de uma especificação Estelle leva em consideração um conjunto de

regras semânticas que cobrem diferentes aspectos da definição desta técnica, da
estruturação da especificação aos atributos que permitem definir a semântica de paralelismo
a ser considerada.
Um primeiro aspecto importante a ser levado em conta é o não determinismo
implícito na seleção das transições a serem executadas num dado instante. Uma transição
pode ser executada se ela está sensibilizada, ou seja, todas as suas cláusulas de pré-
condição são satisfeitas. A nível de uma mesma instância de módulo, diversas transições
podem estar sensibilizadas num dado instante, sendo que apenas uma delas pode ser
executada por vez, podendo inclusive modificar o conjunto das transições sensibilizadas
para aquela instância de módulo. Neste caso, a escolha da seleção a executar é feita de
forma não determinista (é impossível prever qual delas será executada em circunstâncias
semelhantes).
Outro ponto importante das regras de execução de uma especificação Estelle é a
chamada prioridade pai-filho. A prioridade pai-filho determina que, no caso em que uma
instância de módulo ativa contenha pelo menos uma transição sensibilizada, independente
do estado de sensibilização das transições das instâncias de módulo filhas, será sempre
uma transição da instância de módulo considerada que vai ser executada.
OCIOSO
Ei1
!pedido envio
PRONTO P/
ENVIO
?pronto p/ recepção
ENVIO
Ei2
!envio dado
ESPERA
ACK
?dado consumido
Figura 9.6 - Máquina de estados finitos representando a entidade fonte do exemplo considerado.
— 9.15 —
Isto significa que a forma como a especificação é estruturada tem grande influência
na maneira como as transições das diferentes instâncias de módulo vão se relacionar no
que diz respeito à sua seleção para execução.
Um terceiro ponto diz respeito às diferentes semânticas de paralelismo podendo ser
representadas em Estelle, isto sendo função dos atributos associados, de um lado, à
especificação e, do outro lado, às instâncias de módulo que a compõem.
Estelle permite definir quatro classes de atributos que vão desempenhar um papel
importante na representação do paralelismo entre as instâncias de módulo de uma
especificação. Os atributos são systemactivity, systemprocess, activity e process. Os
atributos prefixados por system permitem definir subsistemas no contexto de uma
especificação, dentro dos quais a semântica de paralelismo considerada pode ser diferente.
As regras de utilização destes atributos são descritas nos parágrafos que seguem:
• todo módulo ativo deve ter um atributo associado;

• os atributos systemactivity e systemprocess podem ser associados a um módulo
para definir um subsistema dentro de uma especificação Estelle;
• os atributos systemactivity e systemprocess não podem ser associados a
módulos filhos de módulos atribuídos;
• a especificação pode definir um subsistema único, através da associação de um
dos dois atributos system (systemactivity ou systemprocess);
• módulos com atributo process ou systemprocess podem ser estruturados
unicamente em módulos atribuídos por process e activity;
• módulos atribuídos por systemactivity ou activity podem ser estruturados
unicamente em módulos atribuídos por activity.
A figura 9.7 permite ilustrar o papel dos atributos na definição do paralelismo entre as
instâncias de módulo de uma especificação Estelle, onde um módulo atribuído
systemactivity é estruturado em dois módulos activity.
Os identificadores entre colchetes representam as transições sensibilizadas em
cada instância de módulo. Em 9.7(a), observa-se as transições T1 (systemactivity), T2 e T3
(systemactivity da esquerda) e T4 (activity da direita). Neste caso, a prioridade pai-filho é
levada em conta e a transição selecionada para execução será, invariavelmente, T1. Já em
9.7(b), T1 não está sensibilizada, de modo que a seleção deverá ser feita a nível das
instâncias de módulo activity.
Neste caso, a seleção é não detertminista, apenas uma transição sendo selecionada
para execução, ou seja, T2 ou T3 ou T4.
A figura 9.8 ilustra, de maneira análoga, a política para as instâncias atribuídas
systemprocess e process. Em 9.8(a), temos sensibilizadas as transições T5
(systemprocess), T6 e T7 (process da esquerda) e T8 (process da direita). Neste caso, vale,
ainda a prioridade pai-filho e a transição T5 será selecionada para execução.
[T1] Systemactivity [--] Systemactivity
activity activity activity activity
[T2,T3] [T4] [T2,T3] [T4]
Execução de T1 Execução de T2 ou T3 ou T4
(a) (b)
Figura 9.7 - Comportamento paralelo no caso de um módulo atribuído systemactivity.
— 9.16 —
Já, em 9.8(b), como T5 não está sensibilizada, a seleção é feita no nível das
instâncias process. Estes atributos impõem uma sincronização implícita entre ações de
processos num mesmo sistema. Desta forma, será escolhida, em cada instância, uma
transição, que será sincronizada com as demais, selecionadas a nível das demais
instâncias. Para o exemplo, isto significa que serão executadas T6 e T8 ou T7 e T8.
3.8. A semântica do tempo em Estelle
A técnica Estelle não prevê um mecanismo de representação do tempo que permita

associar uma duração à execução de uma especificação. O tempo relativo à execução da
parte ação de uma transição é considerado nulo para efeito de análise. Por outro lado, a
definição da cláusula delay, associada a uma transição permite representar mecanismos de
temporização interessantes, como os mecanismos de timeout.
Como já foi apresentado, a cláusula delay é definida como uma das cláusulas de
pré-condição de uma transição Estelle, podendo ser associada unicamente a transições
expontâneas (que não têm associadas a elas uma cláusula when).
Esta cláusula, quando associada a uma transição Estelle, permite associar um

intervalo de tempo, cujos limites são Tmín e Tmáx, definidos como segue:
• Tmín é o tempo mínimo que deve ser decorrido entre a sensibilização de uma
transição e a sua execução;
• Tmáx é o tempo máximo que pode decorrer a partir do instante que a transição foi
sensibilizada para que a transição (se continuar sensibilizada) executar.
A cláusula delay pode ser especificada na forma
delay(Tmín,Tmáx)
, onde Tmáx _ Tmín, ou ainda
delay(T)
, onde Tmín = Tmáx = T.
[T5] Systemprocess
[--] Systemprocess
process process process process
[T6,T7] [T8] [T6,T7] [T8]
Execução de T5 Execução de (T6 et T8) v (T7 e T8)

(a) (b)
Figura 9.8 - Comportamento paralelo no caso de um módulo atribuído systemprocess.
— 9.17 —
4. OS TRABALHOS REALIZADOS EM TORNO DE ESTELLE
O interesse da técnica Estelle motivou a realização de um conjunto de projetos em

torno de vários temas visando o seu desenvolvimento para uma futura utilização em escala
industrial.
Os aspectos abordados nestes projetos envolviam três principais pontos de vista:
• a definição de uma semântica formal para Estelle;

• a realização de ferramentas de suporte à concepção para Estelle;
• a definição de metodologias e a realização de especificações formais no domínio
dos protocolos de comunicação e outros mais.
Esta seção visa a apresentar alguns dos importantes resultados em torno destes
aspectos, particularmente no que diz respeito à definição de uma semântica formal para
Estelle, que culminou na definição de uma versão mais poderosa, denominada Estelle* e no
que diz respeito ao desenvolvimento de ferramentas de concepção para Estelle (e Estelle*).
4.1. A técnica Estelle*
Os trabalhos realizados no sentido de definir uma semântica formal para a técnica

Estelle, permitiram, por outro lado, encontrar algumas limitações no que diz respeito à
representação de alguns mecanismos a serem implantados a nível dos protocolos de
comunicação da ISO. Dois importantes aspectos foram os seguintes:
• a existência de um mecanismo único de comunicação, assíncrono, o que, de certo

modo podia gerar alguns problemas de representação no que diz respeito à
comunicação entre entidades de protocolo situados en diferentes camadas;
• a forma de representação do paralelismo utilizando os atributos systemprocess e
process (apresentados na seção 3.7) e a imposição da prioridade pai-filho para a
seleção da transição a executar, o que, na maior parte dos casos, situa-se longe da
realidade quando se considera entidades executando em diferentes sistemas.
Estes dois principais pontos foram privilegiados na definição da técnica Estelle*, que
introduz, de um lado, extensões no que diz respeito aos mecanismos de comunicação e, do
outro lado, simplificações no que diz respeito à representação do paralelismo. O resultado
disto é um ganho em termos de poder de expressão que simplifica o trabalho do usuário da
técnica, permitindo representar aspectos de comportamento dos protocolos de
comunicação.
Estelle* introduz um mecanismo síncrono de comunicação, denominado rendez-
vous, onde duas instâncias de módulo devem sincronizar para que a troca de mensagem
ocorra e que as transições associadas executem.
Este mecanismo é caracterizado, em Estelle*, pela definição de duas novas
cláusulas a serem associadas à parte de précondições das transições, denominadas
cláusulas de sincronização. Sintaticamente, estas cláusulas são especificadas da maneira
seguinte:
<id_ip>?<interação> { sincronização em recepção }
<id_ip>!<interação> { sincronização em emissão }
As condições para que duas instâncias de módulo, A e B sejam sincronizadas via

rendez-vous são:
— 9.18 —
• A contém uma transição tendo uma cláusula de sincronização em emissão e B

uma cláusula de sincronização em recepção ou vice-versa;
• os pontos de interação referenciados pelas duas cláusulas devem estar ligados por
um canal;
• as duas cláusulas devem fazer referência à mesma interação;
• as duas transições, em A e B, respectivamente, devem estar sensibilizadas e
serem selecionadas no processo de execução.
Quando a sincronização ocorre, as partes ação das duas transições são executadas
«simultaneamente», podendo ocorrer passagem de valores se a interação referenciada tem
parâmetros associados a ela.
Os pontos de interação sobre os quais uma sincronização deverá ocorrer devem ser
declarados com uma nova política de fila, no queue, introduzida em função do referido
mecanismo de comunicação.
Isto significa a impossibilidade de coexistência, num mesmo ponto de interação, dos
dois mecanismos de comunicação. Por outro lado, estes podem (e devem!) coexistir numa
especificação Estelle*.
As duas transições Estelle* abaixo, consideradas em duas diferentes instâncias de
módulo ilustram a utilização deste mecanismo. Os pontos de interação F e D são
declarados com política no queue e são supostos estar conectados.
_
trans
from espera_ack
F?ack
to ocioso
begin
end;
_
_
trans
from dado_consumido
D!ack
to ocioso
begin
end;
_
Com relação à associação dos atributos à especificação e aos módulos e à política de

seleção da transição a ser executada, duas simplificações foram propostas em Estelle*:
• a primeira, diz respeito à supressão dos atributos systemprocess e process e à

adoção, de forma rígida, do atributo systemactivity associado à especificação e o
atributo activity associados aos módulos componentes, o que, sob determinadas
condições, aproxima-se bastante da representação mais geral do paralelismo entre
sistemas;
• a segunda, a supressão da prioridade pai-filho como política de seleção da
transição a ser executada, o que é uma das condições mencionadas acima.
4.2. Algumas ferramentas Estelle
Os mecanismos de representação oferecidos por técnicas como Estelle, LOTOS e

SDL tornam evidente a sua adoção no contexto da concepção dos protocolos de
comunicação e das aplicações distribuídas. Entretanto, a existência de ferramentas
— 9.19 —
coerentes para a automatização das diferentes etapas da concepção de um tal sistema são
essenciais para a escolha de uma destas técnicas dentre as disponíveis.
O interesse da adoção de uma técnica de concepção como Estelle é traduzida pelo
grande número de trabalhos consagrados ao desenvolvimento de ferramentas de suporte à
concepção.
Vamos apresentar, nesta seção, duas das diversas ferramentas desenvolvidas neste
contexto, as quais, utilizadas de maneira complementar, permitem cobrir a quase totalidade
das etapas de concepção de um protocolo de comunicação, como apresentado na parte
anterior deste documento.
As duas ferramentas, ESTIM e EWS, foram desenvolvidas dentro do contexto de
projetos do programa europeu ESPRIT, respectivamente os projetos SEDOS (Software
Environment for the Design of Open Distributed System) e Sedos/Estelle/Demonstrator.
ESTIM (Estelle SimulaTor based on an Interpretative Machine) foi desenvolvida no

LAAS/CNRS (Toulouse - França), no contexto do projeto SEDOS. Ela apresenta facilidades
para a validação de especificações formais em Estelle. A ferramenta foi escrita em ML e
suporta principalmente os mecanismos definidos para Estelle*, descrita anteriormente. No
que diz respeito à simulação, ESTIM suporta dois modos de pilotagem de uma sessão de
simulação:
• uma simulação passo-a-passo, na qual o usuário escolhe, no conjunto das

transições sensibilizadas, qual transição deverá executar; este modo permite a
definição e a condução de cenários de simulação, permitindo validar muitos
aspectos do sistema especificado; por outro lado, ele exige a presença do usuário
da ferramenta durante toda a sessão de simulação;
• uma simulação automática, na qual o usuário define um número N de transições a
serem executadas, a escolha, neste, caso, sendo aleatória, a ferramenta sendo
encarregada desta tarefa; neste caso, a sessão é encerrada quando, ou o número
de transições requisitadas foi executado, ou uma situação de bloqueio (deadlock)
foi encontrada.
Durante uma sessão de simulação, ESTIM permite o acesso a todos os objetos,

Pascal e Estelle, compondo a especificação — variáveis, conteúdos de filas FIFO, estados
globais, etc_ — possibilitando a fácil identificação de erros de especificação. Ainda, ele
permite o acesso a informações estatísticas sobre a sessão de simulação, como, por
exemplo, a lista das transições já executadas, a lista das transições que não foram
executadas, instâncias de módulo criadas, e outras informações mais.
ESTIM implementa igualmente uma técnica de verificação, através da construção de
um grafo de alcançabilidade a partir da especificação Estelle* considerada. Este grafo é
reduzido através da interface de ESTIM com ferramentas dedicadas (PIPN, ALDEBARAN,
etc_) que implementam técnicas de redução por equivalência de processos.
Deste modo, o grafo obtido (autômato equivalente) pode ser analizado para a
verificação das propriedades do protocolo. O modo de utilização de ESTIM em verificação
será apresentado mais adiante neste documento. A figura 9.9 apresenta um esquema das
funcionalidades desta ferramenta.
EWS (Estelle Work Station) foi desenvolvida no contexto do projeto Sedos Estelle
Demonstrator, oferecendo facilidades para a edição (editor orientado à sintaxe), simulação
(motor de simulação) e implementação (gerador de código e motor de implementação). A
estrutura da ferramenta é mostrada à figura 9.10.
O editor da ferramenta EWS permite a entrada de texto Estelle, sem erros de sintaxe,
os erros sendo notificados e corrigidos durante a digitação do texto. Ele permite ainda
realizar a formatação de texto digitado em outro editor (emacs, por exemplo). Um outro ponto
interessante deste editor é a seleção de diversas vistas da especificação Estelle (apenas
transições, apenas cabeçalhos Estelle, apenas corpos de módulo, etc_).
— 9.20 —
O tradutor EWS traduz uma especificação Estelle na forma de uma estrutura mais
apropriada à representação dos diferentes objetos Estelle. A esta estrutura de dados é dado
o nome de forma intermediária que foi definida num espírito de expansão da ferramenta ou
da sua interligação com outras ferramentas em desenvolvimento. O tradutor produz um
diagnóstico completo dos erros de sintaxe, e uma referência cruzada da especificação.
O gerador de código de EWS permite gerar, a partir de uma especificação Estelle,
um programa fonte em linguagem C que poderá, em seguida, ser compilado e linkado a
bibliotecas especiais de Estelle. O código C pode ser gerado dentro de dois objetivos — para
simulação ou para execução num ambiente de implementação.
O motor de simulação permite uma execução interativa da especificação Estelle,
dando acesso às diversas opções e objetos da técnica. De modo similar à ferramenta ESTIM,
o simulador EWS permite conduzir a simulação em dois modos: passo-à-passo e
automático.
Um aspecto interessante do simulador é o seu acoplamento a uma interface gráfica,
que permite, inclusive, acompanhar o ponto sendo simulado através da visualização da
listagem da especificação Estelle.
O motor de implementação, finalmente, oferece uma biblioteca de rotinas
necessárias à gestão da execução do código executável gerado a partir da especificação
Estelle. Embora o código executável possa ser gerado sobre qualquer tipo de máquina, EWS
já vem dotada de um conjunto de rotinas orientadas ao sistema UNIX.
As duas ferramentas são operacionais e executam sobre estações de trabalho do
tipo SUN.
Fonte Estelle*
Erros Estelle*
GENESTIM
Construções
não suportadas
Árvore abstrata ML
ESTIM
SIMULAÇÃO VERIFICAÇÃO
Traços e Cenários Grafo de
Alcançabilidade
PIPN
ou
ALDEBARAN
Autômato
quociente
(projeção)
Figura 9.9 - Funcionalidades da ferramenta ESTIM.
— 9.21 —
Fonte Estelle
Editor orientado
à sintaxe
Fonte Estelle sem

Erros de Sintaxe
Mensagens Tradutor
de erro
Forma intermediária
Gerador de
Código
Código executável Código instrumentado
Motor de Simulador
Implementação
Traços e Cenários
Figura 9.10 - Estrutura da ferramenta EWS.
— 9.22 —
Capítulo 10
E STADO DA ARTE EM REDES
1. INTRODUÇÃO
Apesar de que em muitas instituições a palavra rede de comunicação assuma o

tradicional significado da rede telefônica, em boa parte delas as comunicações entre
computadores vem se tornando uma realidade (que o digam os felizes distribuidores de
redes locais para microcomputadores).
No entanto, apesar dos grandes resultados obtidos e concretizados na forma de
produtos para a interconexão de sistemas, como as redes locais de microcomputadores, os
sistemas operacionais de rede, etc..., a tecnologia resta em evolução, motivando a
continuidade de trabalhos de pesquisa e desenvolvimento em redes de comunicação, no
sentido de superar as limitações dos produtos atuais, mas também com o objetivo de
oferecer novas possibilidades de interconexão e transmissão, visando o aparecimento de
novas aplicações, algumas das quais eram consideradas fantasias de ficção científica há
poucos anos atrás.
O objetivo deste capítulo é, sem a pretensão de esgotar o assunto, apresentar alguns
temas e resultados dos desenvolvimentos em redes de comunicação.
Nas seções 2 e 3 apresentaremos duas concepções em termos de redes de
comunicação, as redes ISDN — redes digitais de serviços integrados, e a rede FDDI,
baseada em fibra ótica.
Finalmente, na seção 4 serão mencionados e discutidos alguns dos temas de
pesquisa em desenvolvimento nas instituições nacionais e internacionais.
2. A REDE DIGITAL DE SERVIÇOS INTEGRADOS - ISDN
A rede telefônica vem, após muito tempo, servindo de suporte às comunicações no

mundo inteiro. A rede; que foi concebida inicialmente para transmitir o sinal analógico de voz
é inadequada para o transporte de outras naturezas de informação, tais como dados,
imagens, etc...
Por outro lado, as diversas necessidades em termos de serviços de comunicação
expressas pelos usuários terminaram por conduzir a estudos de um novo conceito em
termos de comunicação, que deverá substituir a tradicional rede telefônica por um sistema
baseado na transmissão digital.
A este novo sistema, é dado o nome de Rede Digital de Serviços Integrados,
conhecido também pela sigla ISDN (Integrated Services Digital Network). O ISDN tem por
objetivo oferecer serviços de comunicação capazes de suportar as atuais necessidades das
aplicações que requerem o transporte de sinais de voz (como o serviço telefônico) mas
também integrando novos serviços que viabilizem a transmissão de outras naturezas de
informação.
—10.1 —
CAP. 10 — ESTADO DA ARTE EM REDES PROF. VITÓRIO BRUNO MAZZOLA
Os trabalhos sendo conduzidos em torno do ISDN são coordenados, a nível

internacional, pelo CCITT, sendo que as primeiras normas foram editadas em 1984, tendo
sido revisadas em 1988.
2.1. Conceitos de base do ISDN
A principal característica do ISDN, como definida pelo CCITT, é a capacidade de “assegurar,

a nível de uma mesma rede, uma larga gama de possibilidades de aplicações telefônicas ou
não. Um elemento chave da integração de serviços nas ISDN é o fornecimento de um
conjunto de serviços com o auxílio de um número limitado de tipos de conexões e interfaces
usuário-rede polivalentes”.
Esta definição, do CCITT, evidencia os pontos mais importantes sendo tratados pelos
trabalhos conduzidos em ISDN:
• a conectividade digital, que permite assegurar que, independente da natureza da

informação (dados, voz, imagem, etc...), a rede suporte o transporte de um ponto
a outro, de usuário a usuário, na forma digital, utilizando recursos homogêneos de
tratamento para a transmissão e comutação;
• a modelização dos serviços ISDN, que é baseada no modelo de referência OSI,
definindo uma organização das funções relativas aos serviços de comunicação
num número limitado de elementos homogêneos e hierarquizados, sendo que as
interações entre os níveis adjacentes é realizada através de primitivas de serviço;
• a polivalência da interface usuário-rede, que prevê a possibilidade de dispor, numa
interface comum, de uma grande variedade de serviços, tais como a telefonia, a
troca de dados informatizados, o intercâmbio de imagens, etc...
• um modo de endereçamento integrado, com base no modo de endereçamento
utilizado em telefonia onde um endereço é composto de um indicativo do país, um
indicativo nacional e um número de assinante; em adição, um esquema de sub-
endereçamento permite a distinção de diferentes equipamentos conectados à
instalação de um assinante.
2.2. Serviços oferecidos pelas ISDN
Apesar de que o grande atrativo das ISDN é o oferecimento de um conjunto de novos

serviços de comunicação, o oferecimento do serviço de transporte de voz continua a ser um
aspecto de grande importância.
A organização dos serviços em camadas como sugere o modelo OSI permite a
definição de duas diferentes categorias de serviços: os serviços de suporte e os
teleserviços. Os serviços de suporte são aqueles providos pelas camadas baixas (camadas
de 1 a 3) e que permitem garantir o envio da informação de um ponto a outro, superando as
imperfeições e problemas que advindos du suporte de comunicação e do ambiente. Os
teleserviços são aqueles providos pelas camadas mais altas (de 4 a 7), cujo conjunto de
protocolos permite colocar, à disposição do usuário, as diferentes facilidades sugeridas pelo
ISDN.
Ainda, para garantir a compatibilidade com os serviços atualmente existentes, será,
muito provavelmente necessária a existência de funções de conversão de protocolos, estas
podendo residir nos terminais, nos próprios equipamentos ou na rede.
O CCITT define, assim três tipos de serviço: os serviços de suporte, os teleserviços
e os complementos de serviços.
Os serviços de suporte são aqueles diretamente relacionados à transmissão entre
assinantes e às características de acesso e utilização da rede. São caracterizados por um
certo número de atributos associados à taxa de transmissão, o modo de transmissão, as
possibilidades de transferência (voz, dados, imagens, etc...), o estabelecimento da
— 10.2 —
comunicação (sob demanda, reservado, etc...), a configuração da rede (ponto a ponto,

multiponto), a qualidade de serviço, etc...
Os teleserviços correspondem, em termos de aplicação, à associação de um
terminal particular com um ou vários serviços de suporte. Estes são, de forma similar aos
serviços de suporte, especificados por atributos, sendo que, desta vez, os atributos referem-
se a outros aspectos mais ligados aos usuários, tais como, o tipo de informação manuseada
pelo usuário (som, imagem, vídeo, dados, etc...), os protocolos adotados nas camadas 4 a
7, etc...
Os complementos de serviços expressam os acessórios que permitem modificar ou
adaptar as funções providas nas redes atuais.
Um exemplo típico de serviço a ser fornecido pelas ISDN é aquele de um aparelho de
telefone moderno, dotado de múltiplas teclas de função que permitam, por simples pressão
do usuário, estabelecer contato com um outro assinante presente numa lista previamente
construída. É também possível, visualizar, na tela do aparelho telefônico, enquanto a
chamada está sendo realizada, o número, o nome e endereço do assinante que está sendo
contactado.
Um outro exemplo interessante é transferência de chamadas para qualquer lugar do
mundo, contatos múltiplos, conferências, etc... Ainda, é possível que o usuário, dado que a
voz é digitalizada, tenha condições de deixar registrado qualquer recado para posterior
consulta (é evidente que este serviço é possível hoje com as secretárias eletrônicas, mas,
se este serviço for uma facilidade existente a nível de rede, para que comprar secretária
eletrônica???).
Um outro aspecto interessante das redes ISDN é a facilidade com a qual aparelhos
telefônicos e informáticos poderão interagir, uma vez que estes vão possuir características
similares.
Podemos ainda enumerar outros aspectos de importância previstas no RNIS e que
constituem-se hoje em áreas importantes de trabalhos de pesquisa em todo o mundo:
• o conceito de de grupo fechado de usuários, onde todo usuário pertencente ao

grupo tem a possibilidade de entrar em comunicação com qualquer outro membro
deste; por outro lado, usuários que não pertençam ao grupo estão proibidos de ter
acesso a informações trocadas entre os membros;
• o videotexto, que permite o oferecimento de um serviço de acesso interativo a
bases de dados a partir de um terminal (catálogo telefônico, páginas amarelas,
serviço metereológico, informações sobre a situação de tráfego de estradas,
compras via rede, acesso a extrato e saldo de contas bancárias, e muitas outras
aplicações incluindo aplicações de lazer como jogos eletrônicos e até correio
sentimental);
• a telemedida, que pode permitir à concessionária de energia elétrica o acesso via
rede aos medidores de energia, eliminando a necessidade da utilização de
pessoas para esta finalidade;
• o telealarme, que permite a chamada automática dos bombeiros ou ambulâncias
na ocorrência de uma situação de emergência (incêndio, ataque cardíaco, etc...);
• o envio de documentos via rede, já existente através dos serviços de fax.
2.3. A implementação das ISDN
É claro que a implementação de redes deste tipo deverá tomar um tempo

considerável, considerando principalmente os grandes investimentos que deverão ser feitos
para transformar a rede telefônica atual numa rede totalmente digital. As duas tecnologias,
analógica e digital, deverão coexistir durante diversos anos, num contexto de cooperação, o
que permitiu definir diversos aspectos da forma final das ISDN.
Abaixo são apresentados alguns pontos que permitirão mostrar as dificuldades que
deverão ser contornadas (em relação ao sistema atual) para viabilizar a instalação das ISDN.
— 10.3 —
Um primeiro ponto diz respeito à transmissão dos sinais de controle na rede

telefônica. Nestas, estes sinais são transmitidos dentro de uma faixa de freqüência de 4 kHz,
sendo que as combinações destes sinais são denominadas sinalização na faixa. Esta forma
de implementação apresenta alguns inconvenientes, principalmente a possibilidade de
surgimento de interferências entre os sinais de telefone e os de sinalização.
Uma solução interessante a este ponto é a chamada sinalização fora de faixa, onde
uma rede independente é utilizada para conduzir os sinais de controle da comunicação. Esta
técnica, além de contornar os problemas de interferência entre sinais de telefone e de
sinalização, permitiu ainda aumentar a possibilidade de aplicações nas redes telefônicas,
como por exemplo, a coleta de dados relativos ao consumo dos assinantes, a fatura
detalhada, o acesso a bases de dados, o acompanhamento de operações de supervisão e
manutenção, etc...
A primeira tarefa na definição das ISDN foi a padronização da interface usuário-rede.
A segunda etapa, mais lenta será a substituição dos centros de distribuição atuais pelos
centros digitais, capazes de oferecer aos usuários a interface de acesso a ISDN. Neste
estágio, os usuários poderão utilizar os serviços ISDN, independentemente da sua natureza.
Uma terceira etapa, será a total substituição das redes de transmissão e dos centros de
comutação pelas redes de transmissão e comutação integradas. A figura 10.1, a seguir,
ilustra estas duas últimas etapas.
2.4. Aspectos arquiteturais de ISDN
A idéia principal da ISDN é o oferecimento direto ao usuário de uma interface digital

que assegure a transmissão de fluxos de informação binária de qualquer natureza: voz,
dados informáticos, som, imagens, etc... Esta ligação digital deve suportar diversos canais
de comunicação independentes e multiplexados.
Duas formas de ligações foram definidas: a primeira, com pequena faixa passante,
destinada principalmente ao grande público e que vai oferecer um pequeno número de
canais, e a segunda, destinada a empresas e grandes “consumidores” que deverá ser capaz
de oferecer um grande número de canais.
A figura 10.2 ilustra uma configuração mínima para um assinante particular, onde
pode-se verificar os diferentes elementos da instalação: a interface de rede, ou NT1 (para
Network Termination 1, como definido pelo CCITT), que é conectada ao centro ISDN de
distribuição mais próximo, sendo que o cabo utilizado é o mesmo que aquele da rede
telefônica tradicional.
A NT1 possui uma interface de acesso, à qual pode ser ser conectado um
barramento passivo (multiponto), onde o assinante poderá ligar até oito equipamentos
independentes, tais como: aparelhos telefônicos, aparelhos de fax, computadores, terminais
ISDN, etc... Para o assinante, a fronteira entre a sua instalação e a rede ISDN é o conector
NT1.
Na sua forma atual, a NT1 é mais que uma simples caixa de conexão, uma vez que
ela contém um conjunto de circuitos eletrónicos destinados a cooperar com o sistema de
gerenciamento da rede ISDN, ao estabelecimento e à liberação de conexões, às operações
de verificação e manutenção dos meios de transmissão e à coleta de informações relativas
ao desempenho efetivo da rede.
Cada terminal conectado ao barramento é dotado de um endereço único a fim de
permitir a sua seleção, sendo que a forma mais básica de realizar a afetação dos endereços
é a utilização de um contactor mecânico e o acionamento de manual para a conexão de um
equipamento particular.
Uma outra solução, mais interessante, é a atribuição de endereços pela própria NT1
a cada vez que um novo equipamento é ativado no barramento do assinante.
— 10.4 —
interface
ISDN interface
ISDN
REDE COMUTAÇÃO DE CIRCUITOS
acesso acesso
REDE DE SINALIZAÇÃO
ISDN ISDN
REDE A COMUTAÇÃO DE PACOTES Terminal

Terminal
ISDN
ISDN
interface
interface
ISDN ISDN
acesso acesso
ISDN REDE ISDN
ISDN
Terminal Terminal
ISDN ISDN
Figura 10.1 - As duas últimas etapas da implantação da ISDN: a instalação dos centros digitais; a
instalação da rede ISDN integrada.
CENTRO DE
NT1
DISTRIBUIÇÃO
equipamentos
ISDN
Figura 10.2 - Instalação básica para um assinante particular.
A interface digital é dotada ainda de uma função de resolução de conflitos sobre o

barramento do assinante, provocados pela tentativa de envio simultâneo por parte dos
diversos equipamentos conectados. Para isto, a NT1 opera como um árbitro do barramento,
definindo, em caso de conflito, que equipamento terá o direito de acesso ao barramento.
Considerando o modelo OSI, a interface digital oferece serviços relacionados à
camada física, definindo as especificações mecânicas e elétricas da interface, mas não
existe nenhuma preocupação com o significado dos quadros transmitidos.
Para os usuários considerados grandes consumidores, porém, a configuração
apresentada na figura 10.2 não é adequada, uma vez que estes apresentam uma maior
demanda em termos de possíveis conversações a serem tratadas de forma simultânea.
Para isto, a utilização de uma simples NT1 não é a solução ideal, pois esta não é
concebida para suportar grandes volumes de conversações. Sendo assim, foi definida uma
outra categoria de interface, a interface digital de assinante, ou NT2 (Network Termination 2),
que é conectada como mostra a figura 10.3. Uma NT2 fornece serviços relacionados às
camadas de 1 a 3 do modelo OSI, podendo ser mais ou menos complexas, segundo a
instalação considerada, e permite a conexão de equipamentos mais diversos, tais como os
aparelhos telefônicos RNIS, os terminais RNIS, etc..., podendo ainda suportar a conexão de
equipamentos não compatíveis RNIS ou mesmo redes locais previamente instaladas na
empresa. Evidentemente, para a conexão desta última classe de equipamentos, será
necessária a existencia de uma passarela de interconexão, dedicada a realizar as
conversões de protocolos necessárias à conexão, são os adaptadores de terminais, ou TA.
2.5. Interfaces de acesso ISDN
O termo interface interpretado no mundo ISDN difere um pouco daquele empregado

quando nos referimos ao modelo OSI. No mundo OSI, uma interface é vista como o meio de
interação entre duas camadas adjacentes compondo a arquitetura de comunicação. Já no
mundo ISDN, a interface é vista como as relações entre a rede e os equipamentos do
assinante. As figuras 10.4 (a) e (b) ilustram esta diferença.
— 10.5 —

Arquitetura de Redes de Computadores

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Redes de Computadores

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

Arquitetura de Redes de Computadores

Enviado por

Direitos autorais:

Formatos disponíveis

SUMÁRIO

CAPÍTULO 1 INTRODUÇÃO ÀS REDES DE COMUNICAÇÃO

1. Histórico das Redes de Comunicação.................................................................1.1

CAPÍTULO 2 O MODELO DE REFERÊNCIA OSI

CAPÍTULO 3 AS SETE CAMADAS DO MODELO OSI

CAPÍTULO 4 AS REDES LOCAIS

CAPÍTULO 5 REDES LOCAIS INDUSTRIAIS

CAPÍTULO 6 INTERCONEXÃO DE REDES

CAPÍTULO 7 ENGENHARIA DE PROTOCOLOS

CAPÍTULO 8 REDES DE PETRI

1. Introdução ........................................................................................................... 8.1

CAPÍTULO 9 A TÉCNICA ESTELLE

CAPÍTULO 10 ESTADO DA ARTE EM REDES

1. HISTÓRICO DAS REDES DE COMUNICAÇÃO

A evolução da microeletrônica e da informática tem possibilitado a obtenção de

das necessidades de processamento das aplicações. Além disso, a modularidade natural

2. IMPORTÂNCIA DAS REDES DE COMUNICAÇÃO

Um grande número de empresas possui atualmente uma quantidade relativamente

3.1. Redes locais e redes de longa distância

Na seção anterior foram apresentados dois exemplos de implementação de Redes

3.2. As diferentes topologias

Um ponto importante no que diz respeito à concepção de uma rede de comunicação

4.1. Serviços necessários à comunicação

Como visto nas seções precedentes, as redes de computadores podem se

Figura 1.2 - Topologias das redes de difusão: barramento, satélite e anel

O problema que se coloca é então relacionado à especificação dos procedimentos e

Figura 1.3 - Terminal conectado a um computador central

Figura 1.4 - Configuração com vários terminais

Por outro lado, se o número de terminais conectados ao computador central torna-se

4.2. Questões organizacionais

Uma vez listadas as diferentes necessidades relacionadas a uma rede de

Figura 1.5 - Configuração com vários computadores e terminais.

Este processo caracteriza, na verdade, a filosofia de concepção das redes de

Todos estes aspectos nos conduzem a conceber uma arquitetura de comunicação

4.3. A estruturação em camadas

Os conceitos de hierarquia e descentralização podem ser empregados de diferentes

Figura 1.7 - Modelo hierarquizado em 7 camadas.

Cada camada comunica-se com as camadas adjacentes através de uma interface,

5. TECNOLOGIAS DE TRANSMISSÃO DE DADOS

5.1. Principais Características

Podemos definir transmissão como a técnica do transporte do sinal por um meio, de

Figura 1.9 - Transmissão serial.

A sincronização na transmissão síncrona se faz antes que um bloco de informação

5.2. Largura de Banda e Capacidade de Canal

A taxa em que podemos enviar dados sobre um canal é proporcional à largura de

outros fatores que influenciam a capacidade de um canal. Conhecida, pois, a largura de

5.3. Distorção e Ruído na Transmissão

A função de comutação, ou chaveamento, em uma rede de comunicação refere-se

A comutação de pacotes é semelhante à comutação de mensagens, sendo que a

Computadores são equipamentos que armazenam, processam e codificam

§ modulação por amplitude (AM)

5.7. Sistemas em Banda Larga e em Banda Básica

Duas técnicas de transmissão são as mais empregadas: sinalização em banda

A grande importância da interconexão dos computadores através de redes de

O conjunto de camadas ou níveis compondo um conjunto de regras de comunicação

camada n, ou, simplesmente, protocolo n. As entidades representando camadas

Figura 2.1 - Modelo hierarquizado em 7 camadas.

No exemplo considerado na figura, a mensagem não sofre modificações, mas esta

Embora sejam freqüentemente confundidos, serviço e protocolo são dois conceitos

Figura 2.2 - Ilustração da comunicação virtual numa arquitetura de rede.