Cap258 2 2

CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLOS LÓGICOS DE COMUNICAÇÃO
Redes - Parte II PROTOCOLOS LÓGICOS DE COMUNICAÇÃO _________________ 67
1 INTRODUÇÃO _______________________________________________________ 67
2 Protocolos NETBIOS/NetBEUI __________________________________________ 68
2.1 INTRODUÇÃO ___________________________________________________________ 68
2.2 ARQUITETURA __________________________________________________________ 69

2.2.1 Protocolo LLC _______________________________________________________________ 69
2.2.2 Protocolo NetBIOS ___________________________________________________________ 69
2.2.3 SERVIÇOS _________________________________________________________________ 70
2.2.4 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 70
2.3 SEGMENTAÇÃO DA REDE________________________________________________ 70
2.4 IDENTIFICAÇÂO ________________________________________________________ 71
3 Protocolo IPX_________________________________________________________ 72
3.1 INTRODUÇÃO ___________________________________________________________ 72
3.2 ARQUITETURA __________________________________________________________ 72

3.2.1 PROTOCOLO IPX ___________________________________________________________ 73
3.2.2 PROTOCOLO SPX ___________________________________________________________ 73
3.2.3 PROTOCOLO PEP ___________________________________________________________ 74
3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:________________________________________ 74
3.3 IDENTIFICAÇÃO ________________________________________________________ 75
3.4 SERVIÇOS_______________________________________________________________ 75
4 Protocolo TCP/IP______________________________________________________ 79
4.1 INTRODUÇÃO ___________________________________________________________ 79
4.2 ARQUITETURA __________________________________________________________ 80

4.2.1 CAMADA DE INTERFACE____________________________________________________ 82
04/03/01
65
Ulisses Thadeu V Guedes
4.2.2 CAMADA DE REDE _________________________________________________________ 84
4.2.3 CAMADA DE TRANSPORTE__________________________________________________ 84
4.2.4 CAMADA DE APLICAÇÃO ___________________________________________________ 85
4.2.5 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 86
4.3 IDENTIFICAÇÃO ________________________________________________________ 86
4.4 SERVIÇOS_______________________________________________________________ 87
5 Encapsulamento De Protocolos __________________________________________ 87
5.1 ENCAPSULAMENTO POR-INTERFACE. ___________________________________ 87
5.2 ENCAPSULAMENTO POR SERVIÇO (APLICAÇÃO) _________________________ 88
6 Exercícios * __________________________________________________________ 89
04/03/01
66
Redes - Parte II
PROTOCOLOS LÓGICOS DE COMUNICAÇÃO
1 INTRODUÇÃO
Protocolo de Comunicação é a formalidade adotada para estabelecer a comunicação

entre nós de uma rede. Nestes termos, não podemos tratar um protocolo de comunicação
de forma isolada. Devemos, sim, avaliar o conjunto de formalidades devidamente
identificadas nas diversas camadas ou nos níveis que elas acontecem. Os protocolos
lógicos são aquelas formalidades adotadas para tratar a rede lógica e os protocolos físicos
são as formalidades adotadas para o meio físico correspondente.
Somente os protocolos usados na camada física podem ser insuficientes ou carentes de

recursos, por exemplo, para garantir o envio e o recebimento da informação. Para esta
garantia faz-se necessário a inclusão de camadas de software auxiliares, estabelecendo
assim os protocolos lógicos.
Admita uma interface de rede enviando um frame para um certo destino. Como esta
interface pode ter certeza que o frame foi enviado? Como ela pode ter certeza de que
o frame foi recebido?
É intuitivo que o envio só será confirmado caso o destinatário e os equipamentos

intermediários, se existirem, retornarem algum outro frame para o remetente informando-o
do fato. Receber também não implica que a informação foi entendida ou processada
corretamente. A informação, ou o pacote que a transporta, pode ter defeitos gerados por
ruídos na transmissão ou na própria montagem inadequada, deteriorando seu conteúdo ou
modificando um padrão adotado. Assim, o receber pode implicar numa confirmação de
todas as camadas superiores ou apenas de uma camada mais baixa. Neste último caso, a
confirmação pode acontecer por camadas ou seguir um mecanismo de confirmação
descendente (a camada mais baixa retornará ao remetente se todas as camadas acima dela
confirmarem o recebimento de forma correta ou vice-versa).
Como o remetente deve proceder caso não receba uma confirmação do recebimento?
Reenvia o mesmo frame, continua enviando novos frames?
Este tratamento é aplicável tanto às redes físicas (caso o hardware disponibilize recursos)
quanto às lógicas (implementado por software). Temos, então, protocolos destinados ao
tratamento da informação quanto ao envio e recebimento desta nas várias camadas. O
reenvio do frame ou a confirmação de recebimento pode ocorrer após o reconhecimento ou
análise feita por alguma camada superior. Além disto, tem-se protocolos correspondentes
(ou associados) à prestação de serviços em camadas mais altas. A prestação de serviços
estabelece ou seguem modelos de comunicação, um deles denominado Paradigma Cliente
x Servidor. Neste modelo, o servidor executa alguma aplicação específica (com finalidade
bem definida) e esta prepara o sistema para atender solicitações ou "request" de uma
04/03/01
67
aplicação cliente compatível. Assim, o cliente inicia a comunicação. Devemos observar que
o "servidor" é um servidor de aplicação.
Vimos que os Sistemas Operacionais são projetados para algum tipo de tarefa e atender às
aplicações que seus fabricantes adotaram ou criaram. Junto com tais aplicações os
fabricantes do SO também incluem os protocolos de comunicação. Discutiremos alguns
protocolos de comunicação dando uma ênfase superficial e o analisaremos o protocolo
TCP/IP com maiores detalhes por ter sido adotado para uma grande número de aplicações
e apresentar código aberto.
Assim, veremos os seguintes protocolos:
• NETBIOS/NetBEUI
• SAP/IPX
• TCP/IP
2 Protocolos NETBIOS/NetBEUI
2.1 INTRODUÇÃO
Em 1985, a IBM (e não a Microsoft como muita gente pensa!!!) introduziu o NetBEUI como
um protocolo que poderia ser usado em aplicações desenvolvidas para redes, considerando
a interface do Sistema de Entrada/Saída Básico de Redes (ou, em inglês, Network Basic
Input/Output System - NETBIOS).
O NetBEUI foi projetado como um pequeno e eficiente protocolo (sob algum ponto de vista)
para uso em redes departamentais (locais) contendo entre 20 e 200 computadores, e que
não precisavam ser roteadas para outras sub-redes, embora aceite o roteamento quando
explorado o roteamento Token-Ring da IBM. Inicialmente o protocolo NetBEUI é o protocolo
padrão dos Sistema Operacional DOS (IBM/Microsoft). Hoje, este protocolo pode ser
executado em diversos sistemas operacionais, onde citamos: DOS + LAN Manager,
Windows (todos), Unix assim como IBM PCLAN, OS/2 (LAN Server), etc.
O NetBEUI pode ser usado com programas que implementam uma variedade se serviços
baseados nas seguintes interfaces de programação de aplicações (ou APIs - Application
Programming Interface) e interfaces de programação NETBIOS
• Named Pipes
• Mailslot
• Network DDE (dynamic data exchange)
• Remote Procedure Call (RPC) sobre NetBIOS
• RPC sobre Named Pipes.
04/03/01
68
2.2 ARQUITETURA
O NetBEUI é um veículo de transporte. É um protocolo de rede e de enlace e não o

protocolo de transporte. Sua estrutura é composta por drivers (interface, protocolo LLC) que
denominamos de NBF (NetBEUI Frame), o protocolo de transporte (NETBIOS) e o protocolo
de aplicações. O exemplo a seguir considera uma máquina cliente executando este
protocolo, conectada à outra que serve como gateway para uma rede local (LAN - Local
Access Network) através de um acesso Dial-up.
Fonte: Microsoft Windows NT Resource Kit. Arquivo network.hlp
2.2.1 Protocolo LLC + Driver = NETBEUI
Corresponde a camada de Controle de Link Lógico (LLC) do modelo OSI. No protocolo LLC
realizam-se códigos e protocolos voltados ao meio (hardware), endereços físicos, controle
de fluxos dos frames, e transferência de dados com ou sem garantias de conexão e abrange
as camadas NetBEUI e de interface. Aqui encontramos os endereços físicos das placas de
rede, e os protocolos usados para transmitir os frames.
OBS: Reparem que não existe uma camada de rede definida. Apesar disto, o NetBEUI
(também conhecido como NBF) permite um roteamento em gateway baseado na
tecnologia de redes Token-Ring.
2.2.2 Protocolo NetBIOS

Corresponde às camadas de transporte e de sessão do modelo OSI. Aqui, o NetBIOS
estabelece a sessão, o multiplex/demultiplex, o término da sessão, a segmentação de
mensagens, delimitações, montagem e reconhecimentos de envio ou recebimento dos
pacotes.
04/03/01
69
2.2.3 SERVIÇOS
O NETBIOS implementa um conjunto de serviços tais como: compartilhamento de

periféricos: discos, impressoras, fax/modems, áreas de trabalho (memória); envio e
recebimento de mensagens, e um ilimitado número de outros serviços que podem ser
programados via RPC.
Os serviços NETBIOS também podem ser encapsulados em outros protocolos de rede

roteáveis para romper a restrição de rede local, como por exemplo: NETBIOS/TCP-IP. Este
tipo de encapsulamento pode ser encontrado em diversos tipos de plataforma e sistemas
operacionais. Uma destas aplicações que implementam tal encapsulamento chama-se
SAMBA (distribuição gratuita), cuja implementação abrange sistemas operacionais UNIX,
(Open)VMS. Os sistemas Windows já trazem este tipo de recurso sem a necessidade de
software adicional. Alguns Sistemas Windows (NT, 9x) podem servir como "gateway" para
estes protocolos nas conexões de redes DIALUP e ETHERNET.
2.2.4 SEQUENCIA DE ENCAPSULAMENTOS
O DADO é a informação (requisição ou resposta) que será envolvida pelo protocolo da

aplicação. Este, por sua vez, é evolvido pelo protocolo NETBIOS. Este "envolvimento"
representa que o NETBIOS inseriu alguma forma de cabeçalho, especificando a finalidade
daquela aplicação, o nome da máquina, o grupo que pertence, o domínio... Agora a
finalidade é enviar tudo isto para o meio físico, o que é preparado pelo protocolo NetBEUI
e enviado para o meio físico (tamanho do frame, forma, tipo do meio, etc).
2.3 SEGMENTAÇÃO DA REDE
Uma vez que o NetBEUI é NÃO-ROTEÁVEL por roteadores "normais", a solução adotada
para estabelecer alguma divisão de forma lógica é através de GRUPO DE TRABALHO (para
compartilhamento) e DOMÍNIO, usado para AUTENTICAÇÃO.
04/03/01
70
Nos GRUPOS DE TRABALHO (ou WORGROUP), uma máquina pertencente ao grupo vê

as outras máquinas do mesmo grupo num primeiro plano. As máquinas de outros grupos
podem ser acessadas escolhendo o grupo correspondente.
As máquinas controladoras de domínio, rodando Windows NT Server ou equivalente, usam

diretórios compartilhados para armazenar informações para todo o domínio, concebendo
uma administração única. Há dois tipos de controladores:
• Os controladores de domínio primários (PDC - Primary Domain Controller), que

mantém as modificações feitas nas contas do domínio e armazenam as
informações num banco de dados. Um domínio tem um PDC.
• Os controladores de domínio de backup (BDC - Backup Domain Controller), que

mantém uma cópia do banco de dados do PDC através de mecanismos de
sincronização. Um domínio pode ter múltiplos BDCs.
2.4 IDENTIFICAÇÂO
As máquinas são identificadas através de nomes únicos independente de grupo no qual elas
pertencem. Estes nomes estão associados aos Endereços Ethernet de forma direta (MAC -
Media Access Control), que podem ser simulados de forma lógica (Ex. conexões PPP via
modem).
Os nomes são propagados através de frames tipo broadcast, enviados periodicamente por
cada máquina (talvez a eficiência esteja aqui!). Todas as máquinas recebem aquele frame e
vão, assim, atualizando suas tabelas contendo as máquinas "vivas" na rede e os recursos
que elas disponibilizam. Cada máquina mantém sua própria tabela de nomes, atualizando-
as periodicamente. A resolução de nomes depende do tipo de configuração e do nó
empregado em cada computador. São aceitos os seguintes tipos de nós:
• b-node -- usam broadcast para o registro e resolução de nomes.
• p-node -- usam solicitações de nomes em conexões ponto-a-ponto feitas ao

servidor de nomes NetBIOS (servidores WINS - Windows Internet Name Server)
onde os nomes estão registrados e resolvidos. Este tip de nó existirá se o
transporte NetBIOS estiver encapsulado (envolvido) pelo protocolo TCP/IP.
• m-node -- usam broadcast para o registro de nomes; para resolver os nomes estas
máquinas tentam os frames de broadcast (b-node), e no caso de não receberem
resposta, comutam para a forma p-node.
• h-node -- usam um servidor de nomes NetBIOS para o registro e tradução;

entretanto, se o servidor de nomes não está disponível (não pode ser localizado),
um h-node tenta a forma de um b-node. A busca por um servidor de nomes é
contínua, e um h-node comutará para a forma p-node tão logo encontre um
04/03/01
71
servidor de nomes disponível. Equipamentos configurados como clientes WINS

são do tipo h-node.
• Microsoft-enhanced -- Usam os arquivos locais LMHOSTS ou proxies WINS mais

a chamada de funções de Socket gethostbyname() ( chamadas a DNS ou arquivos
HOSTS) além dos tipos de node citados anteriormente. Este caso é aplicável
quando consideramos o encapsulamento NETBIOS/TCP.
Informações complementares podem ser encontradas no arquivo network.hlp do Windows

NT Resouce Kit.
3 Protocolo IPX
3.1 INTRODUÇÃO
O protocolo IPX (Internetwork Packet Exchange) foi desenvolvido pela NOVELL e é o

protocolo de rede padrão para redes NETWARE. Estas redes usam uma variedade de
protocolos, sendo muitos destes desenvolvidos especialmente para redes Netware e
baseados no protocolo da Xerox, o XNS (Xerox Network System). De fato, os dois são
quase idênticos, exceto por uma pequena diferença em alguns sub-protocolos. Por exemplo,
o IPX da Novell (ou Internetwork Packet Exchange) é baseado no IDP da XEROX (ou
Internetwork Datagram Packet). O XNS inclui protocolos para aplicações com propósitos
especiais como a manipulação de mensagens enquanto o NetWare usa, apenas, algumas
funções básicas ignorando o resto.
Neste modelo de rede, todas as transações entre máquinas são autenticadas e verificadas
pela máquina servidora Netware, mesmo que a informação esteja em outra máquina cliente.
Ou seja, a servidora Netware tem controle total sobre as ações de seus clientes.
3.2 ARQUITETURA
A arquitetura do conjunto IPX em relação ao modelo de referencia OSI é apresentado

abaixo.
04/03/01
72
3.2.1 PROTOCOLO IPX
O IPX é o protocolo freqüentemente associado com redes NetWare e restabelece a parte

lógica da arquitetura, proporcionando as funções de "rede". O IPX caminha nos vários
segmentos de rede disponíveis e trata do envio dos dados.
O endereço IPX é uma combinação de um endereço de rede e do endereço da placa de

rede. A parte de rede é um número hexadecimal de 32 bits representado numa cadeia de
caracteres de 64 bits (ver identificação). Na maioria das vezes, a parte de rede está
associada ao servidor Netware ou roteador. Uma máquina cliente Netware obterá esta
parcela de endereçamento a partir do servidor ou do roteador, durante a fase de
inicialização e a associará ao endereço de hardware existente (MAC). Se não existir um
servidor Netware então o roteador alimentará a rede com esta informação, caso contrário a
identidade IPX ficará limitada à rede local através do endereço físico.
Uma vez que o endereço de um nó IPX de tem seu endereço de hardware, os sistemas
podem se comunicar diretamente em uma mesma rede física, sem se preocupar com o
endereço de rede. Se o sistema de destino é uma máquina de uma rede remota então o
dado é direcionado para o roteador e este tratará do envio para o segmento de rede
adequado.
OBS: O IPX não garante o envio, ou proporciona serviços de correção ou detecção de

erros. Estas funções são de responsabilidade da camada de transporte (o SPX e
PEP).
3.2.2 PROTOCOLO SPX
O SPX (Sequenced Packet Exchange) é um protocolo de transporte confiável que usa o IPX
para o envio. Uma vez que o IPX (o protocolo de rede) não oferece qualquer confiabilidade,
as aplicações que usam a rede devem ter algum protocolo confiável, no caso,
disponibilizada pelo SPX.
Exemplos destas aplicações podemos incluir, um cliente-servidor de banco de dados, ou um

produto de antivírus. Ao invés da aplicação cliente ler diretamente um arquivo armazenado
no servidor, como acontece com o NetBIOS/NETBEUI, a aplicação cliente solicita a
04/03/01
73
informação desejada à aplicação no servidor e esta faz o acesso ao arquivo e envia o

registro (informação), através de comandos enviados e envolvidos pelo SPX.
O SPX trata esta conectividade como circuitos virtuais, que proporcionam conexões entre
aplicações através do IPX. O tratamento de erros e de reenvio é feito por janelas. Ou seja,
ao enviar um conjunto de pacotes e se um deles apresentar algum erro, então todo o
conjunto será retransmitido. Caso o recebimento tenha sucesso, então a máquina de origem
recebe uma confirmação de todo o conjunto. A confirmação individual dos pacotes é feita
pelo protocolo PEP. O mecanismo adotado no SPX permite o fluxo de uma grande
quantidade de dados de forma rápida com um pequeno risco de dados serem corrompidos.
(Será que isto é tanto assim? E no caso da rede apresentar colisões? Eis o motivo pelo qual
os servidores IPX travam sob algum problema de rede! Por outro lado, quando a rede está
bem dimensionada o desempenho é alto!)
3.2.3 PROTOCOLO PEP
O PEP (Packet Exchange Protocol) é um outro protocolo de transporte similar ao SPX. O

PEP é usado, exclusivamente, para o envio dos pacotes NCP usados para a leitura e escrita
de arquivos nos servidores Netware, e proporciona grande confiabilidade. Quando o pacote
é enviado usando o PEP, cada pacote é verificado independentemente, e neste caso é
disparado um relógio. Nenhum outro pacote será enviado até que a origem receba uma
resposta confirmando a sua chegada. Se o tempo expira, o PEP remonta e retransmite o
pacote e reinicializa a contagem de tempo. Este tratamento (handshake) e espera
consomem uma grande banda de passagem da rede, mas garante, de forma absoluta, que
o pacote foi enviado e recebido. Em pequenas redes locais (mesma rede física e pequeno
número de máquinas) este tratamento passa desapercebido, mas em redes grandes ou
complexas a queda do desempenho é sensivelmente prejudicado quando envolve grandes
períodos de espera.
3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:
04/03/01
74
No envio, a solicitação, resposta, a informação, ou seja o DADO é envolvido pela aplicação

ou serviço (NCP, SAP, RIP, etc). Se o serviço não for o SAP, o pacote é envolvido pelo
protocolo de transporte correspondente (PEP e SPX). O serviço SAP, como veremos, não
usa qualquer protocolo de transporte. Quase pronto para o meio físico, o conjunto é
envolvido pelo protocolo de rede (IPX) que identificará a rede+máquina de destino e
orígem do pacote IPX. Se o destino for uma máquina de outra rede uma função de
roteameno é executada, e, finalmente, o pacote IPX é depositado na fila da interface de rede
(ou canal de saída) correspondente e envolvido pelo frame físico.
No recebimento, o frame identificado pela interface e endereço do nó e depositado nas filas

de entrada do IPX que analisará o destino do pacote. Caso o pacote apresente uma rede
de destino diferente daquela interface recebida, estabelece-se o roteamento IPX. Não
havendo identificação do serviço SAP, o pactote é direcinoado para a camada de SPX ou
PEP que estabelecem o mecanismo de confirmação de recebimento, e automaticamente
direcionado para o serviço final. Tratando-se de um acesso a arquivo, a aplicação tratará de
fazê-lo e retornará o registro solicitado
3.3 IDENTIFICAÇÃO
A identificação dos nós lógicos no protocolo IPX é composto por duas partes: a
primeira identifica a rede Netware e é composto por 24 bits (representados na forma
hexadecimal, e valor entre 1 e FFFFFFFF. A segunda parte contém 6 bytes e
corresponde ao endereço MAC (Media Access Control). Todos as máquinas que
pertencem ao mesmo segmento lógico possuem o mesmo endereço de rede.
Endereço de Endereço do
Rede Host
00000001 00:5F:68:4D:2A:43
00000001:00:5F:68:4D:2A:43
3.4 SERVIÇOS
04/03/01
75
O protocolo SAP (Service Advertising Protocol) habilita os nós provedores de

serviço -- tais como servidores de arquivos, servidores de impressão, servidores de
roteamento, e servidores de aplicação -- anunciarem seus serviços e endereços. O
SAP realiza a tarefa de adicionar e remover serviços na dinâmica entre redes.
Como os servidores estão ativos, eles anunciam seus serviços usando SAP.
Durante a fase de "shutdown" eles anunciam que seus serviços não estarão mais
disponíveis. Os recursos disponibilizados são, normalmente, identificados por
nomes. O SAP traduz tais nomes para os endereços das máquinas que os
disponibiliza
Propagação do SAP
Através do SAP, os clientes de uma rede podem identificar quais serviços estão
disponíveis e obtém o endereço dos servidores de onde eles podem acessar
aqueles serviços. Isto é uma função importante porque uma estação não pode
iniciar uma sessão com um provedor de serviço sem que ela (estação) conheça o
endereço físico do servidor.
Um servidor gateway, por exemplo, propagará pacotes SAP em cada 60 segundos

(o período é definido para todos os servidores que anunciam via SAP) para os
segmentos de rede aos quais está conectado. O agente SAP em cada roteador
daquele segmento copia a informação contida no pacote SAP para uma tabela
interna do servidor gateway. Uma vez que em cada roteador o agente SAP mantém
SAP a informação sempre atualizada, um cliente que precise localizar um servidor
gateway pode acessar o roteador mais próximo para obter o endereço IPX correto.
O SAP é realmente um protocolo da camada de aplicação, mas não usa qualquer

protocolo de transporte (nem o PEP nem o SPX.) O envio é feito diretamente no
IPX. Na verdade, o SPX usa o SAP para localizar os servidores pelos seus nomes
ao invés de seus endereços físicos.
Quando um cliente precisa localizar um periférico (ou serviço) pelo nome, ele questiona o
servidor SAP mais próximo. Estas solicitações podem ser para um servidor Netware, ou
para um servidor de aplicações usando o SPX.
04/03/01
76
O protocolo de roteamento (Routing Information Protocol) facilita o intercâmbio de

informações de rotas numa rede Netware. Assim como o IPX, o protocolo RIP tem
origem do XNS. Entretanto, um campo extra, "número de saltos", foi adicionado à
estrutura dos pacotes para melhorar o critério de decisão quando na seleção da rota
mais rápida para o destino do pacote. A inclusão deste campo proíbe uma
integração do RIP de Netware com a implementação do XNS.
Propagação RIP
A propagação de pacotes RIP permitem que:
• As estações localizarem a rota mais rápida para aquele número de rede;

• Roteadores solicitem informações de outros roteadores para atualizarem suas
próprias tabelas internas;
• Roteadores respondam às solicitações de estações e de outros roteadores;
• Roteadores tenham certeza de que todos os roteadores estão compatíveis
com a configuração das redes envolvidas;
• Roteadores detectem as modificações na configuração das redes.
Os roteadores também enviam pacotes RIP cada 60 segundos, assim em poucos

RIP minutos cada roteador da rede reconhecerá a existência de outros roteadores e
sobre as redes acopladas a eles. Se um roteador deixa de enviar suas tabelas de
atualizações, o outro roteador assume que o primeiro está desligado e o remove de
tabelas de roteamento. .
04/03/01
77
Como no tráfego do SAP, o protocolo RIP pode sobrecarregar o tráfego da rede

quando esta é complexa ou grande demais. Em redes pequenas ou médias, estas
atualizações constantes não induzem grandes tratamentos, mas em grandes redes ,
a troca constante dos mapas de roteamento pode se tornar problemáticos.
Para resolver este problema, a Novell desenvolveu um protocolo de estado de

roteamento denominado NLSP (Netware Link State Protocol) que trabalha de forma
NLSP bem mais eficiente em grandes redes. Ao invés dos roteadores anunciarem suas
informações sobre cada rede ou roteador conhecidos, é anunciado apenas as rotas
conhecidas (invés de todos os roteadores conhecidos pela rede), e somente quando
ocorrer uma modificação nas rotas. Ao usar o NLSP reduz-se a quantidade de
banda exigida para os serviços de roteamento e de anúncios de serviços. .
O Netware Core Protocol (NCP) define o controle da conexão e dos códigos de

requisição de serviço que tornam possíveis a interação entre clientes e servidores.
O serviço NCP disponibiliza um "dicionário" de comandos de rede associados às

operações de I/O e corresponde ao coração do sistema de arquivos de servidores
Netware. Os comandos padrões do NCP atuam para a abertura de arquivos, leitura
e escrita, etc.
NCP Se um cliente deseja abrir um arquivo no servidor, o cliente Netware intercepta o
comando de sistema e o converte para o comando equivalente NCP e o envia para
o servidor. O Servidor recebe aquele comando, abre o arquivo, e envia somente a
informação desejada para o cliente. Desta forma, um cliente Netware não depende
das funções básicas do sistema operacional, e a rede pode ser otimizada para um
conjunto consistente de serviços.
Reparem que nas redes NETWARE o modelo Cliente/Servidor seguido considera a

existência de um "servidor concentrado" e clinte "distribuido". Os clientes não são
autônomos e tem uma grande dependência do "Servidor". Portanto, neste modelo de rede
existe o sentido "literal" das definições de uma máquina cliente (se prestar algum recurso
este é gerenciado completamente pelo "servidor") e o servidor, o real prestador de serviço.
Apesar deste comportamento ser característico (e particular) das redes Novel, é comum
denominarmos de "servidor" algumas máquinas que usam outros protocolos que não
seguem este modelo de rede (TCP/IP por exemplo que adota um modelo differente!)
Para mais informações sobre roteadores IPX e as funções que eles realizam numa rede
Netware, vejam a documentação de redes Netware. Uma boa fonte de referencia está
disponível no site da UNOVERICA de onde foram colhidas estas informações.
04/03/01
78
4 Protocolo TCP/IP
4.1 INTRODUÇÃO
Em 1969, por questões militares, o governo americano iniciava os estudos sobre um

protocolo que atendesse certos requisitos de comunicação. Dentre eles, destacam-se:
1) Grande número de conexões lógicas

2) Capacidade de transferencia de mensagens de controle;
3) Capacidade de execução remota em batch ou interativo;
4) Transferência de arquivos, e
5) Independência da Plataforma
Para atender tais requisitos foi criado um grupo de redes que plantariam a semente da
Internet. O grupo: Steve Carr da Universidade de Utah, Jeff Rulifson e Bill Duvall da SRI,
Steve Crocker e Gerard Deloche da Universidade da Califórnia - Los Angeles (UCLA).
(rfc003)
A ARPANET, a rede do sistema de defesa americano, estava começando. Em 1970

testavam o RJE e posteriormente o TELNET. Em 1973 estabeleciam os objetivos da
transferência de arquivos, o FTP. Até então, existiam uma "meia dúzia de máquinas"
interligando centros militares, governamentais e educacionais usando o protocolo TCP/IP
ainda precário. Em 1980, a ARPANET migrava todas as suas máquinas para uma nova
versão do TCP/IP. A migração levou 3 anos e no final deste prazo a ARPANET era dividida
em duas grandes redes: A ARPANET para pesquisas, que se tornaria a INTERNET, e a
MILNET para os militares (Como será que anda a MILNET? Aderiu à InterNET ou ainda
permanece nos secretos corredores de rede dos militares americanos?).
A INTERNET invadiu o mundo encontrando as portas abertas para uma tecnologia que viria
romper todas as fronteiras territoriais. Chegou às casas, escritórios, hospitais, e governos.
Com a divulgação da mesma veio novos produtos e ferramentas para transferir e armazenar
a maior das riquezas, a informação. Surgiram vários outros grupos de estudiosos (os
hackers). Uma facção dedicou à entender aquela "formosura de tecnologia". Um outro, além
de entender, buscam romper e assumir o controle das máquinas, das informações, a
propriedade e em situações extremas, destruir o que, para ele não tem o mesmo valor de
liberdade (os crackers). Supõe-se que tais "estudiosos", sejam hackers ou crackers, são até
financiados por empresas concorrentes, governos dominantes ou dominados.
Por isto hoje, o ato de ADMINISTRAR redes não se resume à instalação, configuração e uso
de aplicações. É preciso entender o ambiente, os protocolos, e proporcionar soluções
também no desenvolvimento ou migração de produtos. Configurar sem saber o porquê é
abrir portas para invasões ou impedir o funcionamento de uma rede e seu uso.
Neste curso, estudaremos o conjunto de protocolos que compõem o TCP/IP, as camadas e

aplicações sob o ponto de vista funcional, porém com um nível de detalhe necessário
visando a administração e o desenvolvimento de produtos de software.
04/03/01
79
Um comentário para os "comodistas": Se existe alguma aplicação pronta é porque alguém

fez. Usá-la, simplesmente, é tão perverso e perigoso quanto uma bomba relógio ou uma
arma desconhecida onde o tiro pode sair pela culatra. Não se busca um expert, mas
profissionais sem inocência. Para justificar este ponto de vista busque informações sobre
"cavalos de Tróia".
4.2 ARQUITETURA
Comparado ao OSI, o modelo TCP/IP é muito mais simples e consta de apenas 4 níveis
(camadas), podendo englobar um ou mais níveis do modelo OSI. Não considerando todo o
rigor das atividades das camadas do TCP/IP em relação o modelo OSI, podemos comparar
os dois protocolos como segue:
TCP/IP OSI
APLICAÇÃO
(NIVEL 7)
APLICAÇÃO APRESENTAÇÃO
SERVIÇOS E CLIENTES (NIVEL 6)
(PING, FTP, TELNET, HTTP, DNS, ... ) SESSÃO
(NIVEL 5)
TRANSPORTE TRANSPORTE
(TCP, UDP...) (NIVEL 4)
REDE REDE
(IP) (NÍVEL 3)
INTERFACE ENLACE
LINK (ETHERNET) +FÍSICO (NÍVEL 2)
(COAXIAL, PAR-TRANÇADO, FIBRA- FÍSICA
ÓTICA...) (NÍVEL 1)
Cabe, aqui, alguns comentários sobre a distribuição destas camadas. Alguns autores
(Douglas E Comer - Internetworking with TCP/IP - VOL.1, e, W Richard Stevens - Unix
Networking Programming - Vol 1) tratam a camada de interface do TCP/IP correspondendo
às camadas de enlace e física do modelo OSI (Níveis 1 e 2), embora nem todas as funções
destas camadas possam ser encontradas na camada de interface (tratamento de problemas
de hardware tipo colisão ou de envio). Por outro lado, existe um tratamento na camada de
rede (via ICMP, por exemplo), o que implicaria numa pequena expansão da camada de rede
do modelo TCP/IP em direção ao nível de enlace (modelo seguido por Tanembaumm e
outros). A razão pela qual os primeiros autores citados consideram a camada de Interface
apenas a junção das camadas de enlace e física está no fato de que o acesso aos pacotes
diretamente na camada de interface permite estabelecer um controle mais eficiente através
de bibliotecas especiais. Uma dessas é a biblioteca libpcap, que implementa o DLPI - DATA
LINK PROVIDER INTERFACE - usado para aplicações tipo TCPDUMP em diversos
04/03/01
80
sistemas operacionais. O DLPI é um protocolo de interface desenvolvido pela AT&T que

fornece os recursos da camada de enlace e não é, oficialmente, integrante do TCP/IP, mas
acompanha alguns sistemas operacionais.
A STD5A (INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL

SPECIFICATION - RFC 791), não compara o TCP/IP com o modelo de referencia OSI.
Numa mesma rede física, a troca de mensagens, datagramas, pacotes e frames entre os
nós estabelecem conexões entre os vários níveis (ou camadas), deixando-a transparecer
conexões entre as camadas lógicas num nível mais alto. A figura abaixo mostra estas
conexões considerando uma mesma rede física. Ou seja, a mensagem enviada por um nó é
idêntica aquela recebida pelo outro nó. Neste caso, a igualdade se estende até a camada de
frames.
Na próxima figura, temos a presença de roteador. Neste caso, a igualdade só é satisfeita até
os pacotes. Ao receber o frame na interface de entrada do roteador, este é transferido para
a camada de rede, o datagrama é extraído do frame, analisado, o cabeçalho para identificar
a rede de destino (e não a máquina). Uma vez conhecida a interface de destino, é montado
um novo datagrama e enviado à ela. Esta, por sua vez, monta o frame adequado para o
novo meio físico usando o endereço físico do roteador.
04/03/01
81
O tratamento do TCP/IP em camadas facilita sua implementação, mas complica na

otimização dos procedimentos. Uma boa explicação está no conhecimento dos tamanhos
dos dados envolvidos nas passagens entre as camadas. O tamanho de uma mensagem, por
exemplo, poderá acarretar em fragmentação desta, considerando o tamanho do frame
usado por aquele meio físico. Este tipo de problema foi resolvido na versão mais nova do IP,
conhecida como IPv6 ou IPng (New Generation).
4.2.1 CAMADA DE INTERFACE
Adotaremos que a camada de interface englobe funções das camadas de enlace e física de
um modelo OSI.
A camada Física (ou nível Físico) prepara o datagrama para o meio na qual a informação
trafegará. Ex.: Cabo coaxial, fibra ótica, par trançado, rádio, linhas privativas, etc, o modelo
de empacotamento dos frames em função deste meio.
E o que notamos neste meio quanto aos sinais que ali circulam?
Notamos sinais de sincronismo, modulações em fase e dados que correspondem aos níveis
superiores. Ou seja, notamos sinais elétricos que excitam os dispositivos ou equipamentos.
Não é raro a necessidade de conectarmos um meio físico a outro ou mesmo unir vários
meios físicos. Os equipamentos que prestam este serviço, sem se preocupar com a
informação transmitida, são os transceivers, repetidores e hubs.
Na parte correspondente à camada de enlace já se observa alguma identificação das

máquinas e/ou equipamentos envolvidos. Esta identificação é o endereço Ethernet, que
consiste em um conjunto de 6 bytes: os 3 bytes menos significativos identificam o número
04/03/01
82
da interface da máquina e os 3 bytes mais significativos identificam o fabricante daquela

interface.
00:40:C7:29:4C:F6
00:40:C7 29:4C:F6
FABR. INTERF.
Todas as máquinas com TCP/IP mantém em memória um banco de dados que associa o
este endereço físico ao endereço lógico IP (Tabela ARP). Uma vez que as máquinas não
sinalizam suas presenças na rede, como acontece com os protocolos IPX e NetBEUI, e
quando um datagrama IP deve ser enviado (Endereço IP fornecido pela aplicação), o
software TCP/IP prepara um frame de broadcast, ou seja, um endereço "coringa". O
exemplo de um endereço Ethernet: 0A:00:1B:7F:8A:CC . O endereço "coringa" é
FF:FF:FF:FF:FF:FF. Quando um frame circula pela rede, todas as máquinas verificam se
aquele frame contém o endereço de sua interface. A operação é feita usando uma
sequencia de operações aritméticas e lógicas entre o endereço de sua interface e o
endereço de destino contido naquele frame, ou através de uma comparação, que considera
o endereço coringa como um valor válido. Se o resultado for satisfatório então aquele frame
é transferido para as filas das camadas superiores.
Por que o endereço FF:FF:FF:FF:FF:FF é coringa?
Sejam A e B dois números quaisquer entre 0 e 255. Tome o B como sendo seu valor de
referencia (qualquer que seja ele!). Calcule a diferença entre eles (em bits). Calcule a função
NOT da diferença. Somente o A=255 (0xFF) resulta no próprio valor de B. Teste! O valor
0xFF é especial, não?
Por que uma operação tão complicada e não uma mera comparação, ou algo mais
simples?
A forma de implementação fica aos cuidados do fabricante. Apenas provamos que o valor
255 é muito especial.
Esta camada é a responsável pelo envio dos pacotes para os nós da rede local. Um pacote
com destino para uma outra rede é enviado para o roteador IP, cujo endereço Ethernet é
bem identificado e começa com o primeiro byte igual a 0x08. Enviando um frame para
08:FF:FF:FF:FF:FF é suficiente para que todos os roteadores da rede local recebam aquele
frame. Para evitar redundâncias e propagação desnecessária de um mesmo frame, o
TCP/IP envia um frame tipo broadcast em datagrama IP para o endereço fornecido como
"endereço do gateway" requsitando o endereço Ethernet associado à aquele IP. Conseguido
o endereço Ethernet do roteador, já não há um datagrama com endereço IP destinado ao
roteador, mas um frame destinado especificamente ao roteador, com o endereço IP do nó
de destino.
Toda interface é, para o TCP/IP, como uma fila (ou um buffer) onde será depositado o frame
ethernet.
04/03/01
83
4.2.2 CAMADA DE REDE
No protocolo TCP/IP, esta camada de rede trata os datagramas de entrada e saída

separadamente, logo o IP considera duas partes. A comunicação entre estes procedimentos
denominamos de roteamento (Routing), e é implementado através de um procedimento
(mecanismo) de roteamento. No cabeçalho dos datagramas IP identificamos a origem e o
destino destes e o tipo de protocolo usado pela camada superior (transporte).
As máquinas são identificadas pelo seu Número IP ou endereço IP. Este número tem um
tamanho de 32 bits e é representado, normalmente, na forma decimal byte-a-byte separado
por um "." (ponto). Existem outras notações.
Por exemplo: 192.168.45.10 é a representação de um número IP na forma decimal byte-a-

byte. Na forma binária, este número é: 11000000 10101000 00101101 00001010, que
representa o número decimal: 3232247050 ! As notações em negrito são aceitas pela
grande maioria das aplicações.
A capacidade de roteamento completa não está disponível em todas as implementações do

TCP/IP. Quando disponível, estamos, na verdade, empregando a comunicação entre as
tarefas que analisam os datagramas de entrada e saída. No roteamento, a tarefa IP analisa
o endereço IP da rede através de operação de uma máscara e não exclusivamente o
endereço IP do nó.
Para um datagrama que chega, após a analise de roteamento - se existir - testa-se se o

endereço IP do nó de destino coincide com aquele nó. Caso seja confirmado, o datagrama é
enviado para a camada do protocolo de transporte correspondente. Caso contrário, o
datagrama pode ser descartado ou, na presença de mecanismos de roteamento entre
interfaces, o datagrama é enviado para aquela interface informada pelo mecanismo de
roteamento.
4.2.3 CAMADA DE TRANSPORTE
O protocolo IP não disponibiliza qualquer forma de controle. Este controle pode ser realizado
através da camada de transporte. Esta camada, portanto, define a forma que os pacotes
serão enviados quanto ao controle destes através dos protocolos de transporte. Os
protocolos de transporte podem ser classificados em orientados ou não à conexão. Embora
a tradução "ao pé da letra" seja "orientado" (de connection oriented e connectionless - talvez
"desorientada" (:)) ) a idéia passada é "com garantias de conexão ou com controle da
conexão" e "sem garantias de conexão ou sem controle de conexão".
Um protocolo é dito "sem garantia" ou "não orientado à conexão" quando o pedido de

conexão de uma máquina para a outra pode ser aceito, estabelecido e a transferencia da
informação realizada, contudo, não há mecanismo que sinalize o recebimento,
estabelecimento ou transferência da informação. Para este tipo de comportamento foram
definidos vários protocolos. Exemplo: UDP (User Datagram Protocol), e RIP (Routing
Internet Protocol). O próprio IP (protocolo de rede ou Internet Protocol) não garante que
aquele pacote chegará ou se foi recebido pelo destinatário.
04/03/01
84
O protocolo dito "orientado" ou "com garantia" quando o envio do pacote de uma máquina
para a outra é verificado se foi aceito e estabelecido, e se a transferencia da informação foi
realizada com sucesso. Ou seja, há confirmação quanto ao recebimento da informação e da
conexão propriamente dita. Para este tipo de conexão utilizamos o protocolo TCP
(Transmission Control Protocol) que implementa um conjunto de controle: tempo, seqüência,
urgência, etc.O "como" será visto oportunamente.
Esta camada implementa uma interface com a camada de aplicação onde se define um
protocolo de portas. Tais portas são usadas como um sistema de identificação da aplicação
de origem e destino.
4.2.4 CAMADA DE APLICAÇÃO
Nesta camada estão as aplicações. Estas são identificadas por portas e estão intimamente
relacionadas com o protocolo de transporte utilizado.
O protocolo de Rede TCP/IP implementa o paradigma cliente/servidor. Ou seja, uma

aplicação é composta por um software cliente e outro, compatível, denominado software
servidor. A despeito de outros protocolos, não há uma máquina servidora, mas uma
máquina que executa uma aplicação de serviço e, assim, uma conexão se dá entre
aplicações e não entre máquinas. Isto implica que uma mesma máquina pode ser usuária
(ou cliente) e servidora simultaneamente quando executa o software cliente e servidor
concorrentemente. Uma máquina que executa uma aplicação servidora pode ser cliente de
uma outra máquina que executa aquele mesmo tipo de aplicação. Assim não tem muito
sentido dizer que a máquina é a "máquina servidora" num sentido genérico ou exclusivo
como no protocolo IPX.
Um software servidor aguarda uma conexão (portanto é executado primeiro) e o cliente

inicia esta conexão. O protocolo TCP/IP não possue uma camada de sessão. Assim, a
camada de aplicação é responsável por:
• inicio e término das conexões,

• estabelecer a lógica ou finalidade daquela aplicação
• preparar o ambiente para o protocolo de transporte
• tratar das representações (apresentação)
• chamar funções de tradução de nomes, e
• adequar a ordem dos bytes quando na transferencia binária.
Todas estas atividades seguem um algoritmo bem conhecido e que será estudado
posteriormente.
As aplicações também estabelecem um protocolo de diálogo. Ou seja, para que se explore

os recursos disponibilizados por um software de um serviço é necessário um software
cliente associado que fale, ou permita que se emule, o diálogo do serviço. O serviço TCP/IP
mais popular é o HTTP (Hiper Text Transfer Protocol) (ou WWW, como é "carinhosamente"
conhecido). O "diálogo" (ou protocolo HTTP) apresenta poucas opções. Eis algumas delas:
PUT, DELETE, GET, UNLINK.
04/03/01
85
Sim. Um outro serviço muito utilizado (e nem sempre notado) é o de ICMP (Internet Control
Message Protocol) embora não seja considerado nem um serviço nem um protocolo de
transporte. Uma grande maioria das implementações do TCP/IP não apresentam uma forma
de controle sobre este serviço. Ele é utilizado automaticamente pela camada de rede (IP) e
pode ser usado para o reconhecimento de máscaras, rotas, etc. A aplicação cliente
parcialmente controlável é o PING. Os Sistemas Windows, por exemplo, utilizam somente
do ICMP para o traçado do caminho dos datagramas, conhecido como TRACEROUTE, mas
este mesmo serviço pode ser através do protocolo UDP (sistemas UNIX).
4.2.5 SEQUENCIA DE ENCAPSULAMENTOS
No TCP/IP o protocolo de IP (Internet Protocol) sempre estará presente em qualquer

datagrama, (execto nos protocolos ARP e RARP. Cada camada apresenta seu "carimbo" ou
cabeçalho., como veremos nos capítulos seguintes. Assim como no IPX, há certos serviços
(sim, não deixam de ser servços) que não querem um protocolo de transporte. É o caso do
protocolo ICMP (Internet Control Message Protocol).
No envio o DADO (resposta ou solicitação que define a mensagem propriamente dita: o

nome do usuário, sua senha, o nome de um arquivo, etc). Este dado está associado ao
protocolo da aplicação padronizado. Esta aplicação ou serviço dependerá de algum
protocolo de transporte e este do protocolo de rede, para prováveis roteamentos e,
certamente, a identificação dos canais de saída (interface).
4.3 IDENTIFICAÇÃO
A identificação das máquinas é através do endereço IP, como visto na camada de Rede. As
redes lógicas são identificadas através da aplicação da máscara utilizada. Uma vez que a
rede é identificavel (mesmo que implicita no endereço IP), isto significa que o protocolo é
roteável. Estaremos vendo mais detalhes relacionados à identificação no próximo capítulo.
04/03/01
86
4.4 SERVIÇOS
Os serviços do protocolo TCP/IP estão associados não exclusivamente aos protocolos de

transporte mas, também, ao que denominamos de protocolo de portas. As aplicações
servidoras são identificadas pela tripla: endereço IP, protocolo de transporte e porta. Alguns
protocolos (roteamento, por exemplo) não usam portas específicas. O protocolo ICMP
implementa um protocolo de identificação de finalidade que se assemelha ao protocolo de
portas, como veremos adiante.
5 Encapsulamento De Protocolos
Denominamos de encapsulamento a condição de envolver um protocolo em outro. Os

encapsulamentos estão presentes em todas as arquiteturas de protocolos quando o
protocolo de uma camada superior é encapsulado pelo protocolo da camada inferior. Em
certas camadas podemos ter a ocorrência de mais de um encapsulamento.
O mecanismo de encapsulamento de protocolos lógicos pode se basear em:
a) Uso de serviço que tratará da montagem e desmontagem do protocolo interno;

b) Uso das interfaces de camadas, criando uma espécie de canal lógico entre máquinas;
Da mesma forma que o TCP é montado sobre o IP, podemos ter, teoricamente, IPX sobre
IP, IPX sobre TCP, ou NetBEUI sobre TCP, ou mesmo IP sobre IPX, DECnet sobre TCP,
DECnet sobre UDP, IP sobre DECnet, etc.
Este leque de possibilidades permite transportar o protocolo existente numa rede local para
outras redes remotas usando o protocolo básico que interliga estas suas redes. Desta idéia
surgiram os conceitos de VPN (Virtual Private Network), PPTP (Point-to-Point Tunneling
Protocol) dentre outras denominações. De qualquer forma todas elas baseiam-se no fato de
transportar um protocolo como dado usando algum outro protocolo como transportador. As
máquinas que executam ais encapsulamentos são consideradas gateways locais.
OBS: Os exemplos de encapsulamentos citados tem efeito puramente didático e tem

o objetivo de mostrar as técnicas de encapsulamento e não a existência delas.
5.1 ENCAPSULAMENTO POR-INTERFACE.
No encapsulamento por interface, por exemplo IP sobre IP, um datagrama de uma rede
lógica IP privativa é encapsulada no protocolo IP de uma rede lógica pública, estabelecendo
uma espécie de roteamento em túnel IP e aproveitando a interface entre camadas. Neste
caso, um novo cabeçalho IP é criado com destino à máquina remota específica e tendo
como origem o endereço publico da máquina que está "funcionando" como um túnel. A
função de roteamento é adaptada para criar uma interface lógica (pseudo interface,
semelhante à de loopback). Esta interface tem o papel de embutir o datagrama IP original
(rede privativa) num datagrama IP com destino à máquina remota. O novo datagrama criado
04/03/01
87
retorna para o sistema de roteamento IP e segue para a interface necessária. No outro lado,
lado da máquina remota, quando a interface recebe o datagrama IP com a origem
especificada, a função de roteamento de por túnel direciona para uma interface também
especial, que tratará de remover o datagrama IP interno e devolve-lo para o sistema de
roteamento normal. Reparem que neste caso, não encapsulamos um protocolod e rede
sobre um protocolo de transporte. Alguém poderia explicar o por quê[U1]?
Na figura abaixo, temos uma forma de encapsulamento por interface de IPX sobre IP.
Neste caso, e embora o IP não possua garantias de envio ou recebimento, a interface de

protocolos pode explorar os recursos de controle do protocolo de transporte do IPX (PEP ou
SPX), e a Interface de protocolos se comportaria como uma pseudo interface de um
hardware para o lado IPX e um pseudo-protocolo de transporte para o IP.
Esta interface de protocolos pode se deslocar até a camada de aplicação do IP.
5.2 ENCAPSULAMENTO POR SERVIÇO (APLICAÇÃO)
No encapsulamento por serviço, as aplicações são projetadas para servir como o elo de
ligação entre os protocolos. Explorando o caso IPX sobre IP, uma aplicação do IPX seria
também uma aplicação IP, extraindo a mensagem de um protocolo e transferindo-a para o
outro.
04/03/01
88
Especial atenção deve ser dada ao NETBIOS sobre TCP. Neste caso a aplicação
implementa os serviços propriamente ditos como uma aplicação normal não havendo
qualquer transferencia ou roteamento de qualquer espécie.
6 Exercícios *
1. Vimos alguns protocolos de comunicação. Descreva os motivos pelos quais um

equipamento que adote um protocolo físico e um certo protocolo lógico não é capaz de
se comunicar com outra máquina configurada para usar um mesmo protocolo físico
porém com um protocolo lógico diferente.
2. Para confirmar sua resposta na questão anterior, considere duas máquinas A e B que
rodam de exclusivamente os protocolos NetBEUI e TCP/IP, respectivamente. Define
para esta última o endereço IP 192.168.10.20. Anote o endereço ethernet da máquina
"A" que usa o protocolo NetBEUI. Na máquina com o TCP/IP, máquina B, carregue a
tabela ARP com o endereço físico da de "A" associando o endereço IP 192.168.10.30
para a máquina "A". Usando um comando PING (ping 192.168.10.30) envie um frame
ethernet para a máquina não TCP. Com a ajuda de um software de captura de frames
(TCPDUMP, SNOOP ou MS-Network Monitor) verifique se o datagrama IP foi enviado
para a rede. A máquina "A" reconheceu o pacote? A máquina com NetBEUI vê a de
TCP/IP no ambiente de rede?
3. Repita o mesmo com a máquina A e B rodando somente o TCP/IP e com os endereços

citados. E agora? Houve a transmissão e recebimento do datagrama?
4. Repita com o NetBEUI nas duas máquinas. As máquinas se vêem mutuamente? Por
quê? Experimente modificar a identificação do grupo de trabalho. Elas continuam se
vendo?
04/03/01
89
Page: 88
[U1]Se temos IP sobre IP, já estamos encapsulando o protocolo de transporte entre as duas
máquinas. O protocolo de transporte mais interno em uso implementa o controle da conexão.

Cap258 2 2

Enviado por

Dados do documento

Título original

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

Cap258 2 2

Enviado por

Direitos autorais:

Formatos disponíveis

CAP 258 - REDES E COMUNICAÇÃO DE DADOS

Redes - PROTOCOLOS LÓGICOS DE COMUNICAÇÃO

Redes - Parte II PROTOCOLOS LÓGICOS DE COMUNICAÇÃO _________________ 67

2 Protocolos NETBIOS/NetBEUI __________________________________________ 68

2.1 INTRODUÇÃO ___________________________________________________________ 68

2.2 ARQUITETURA __________________________________________________________ 69

2.2.2 Protocolo NetBIOS ___________________________________________________________ 69

2.2.3 SERVIÇOS _________________________________________________________________ 70

2.2.4 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 70

2.3 SEGMENTAÇÃO DA REDE________________________________________________ 70

2.4 IDENTIFICAÇÂO ________________________________________________________ 71

3.1 INTRODUÇÃO ___________________________________________________________ 72

3.2 ARQUITETURA __________________________________________________________ 72

3.2.2 PROTOCOLO SPX ___________________________________________________________ 73

3.2.3 PROTOCOLO PEP ___________________________________________________________ 74

3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:________________________________________ 74

3.3 IDENTIFICAÇÃO ________________________________________________________ 75

4.1 INTRODUÇÃO ___________________________________________________________ 79

4.2 ARQUITETURA __________________________________________________________ 80

4.2.2 CAMADA DE REDE _________________________________________________________ 84

4.2.3 CAMADA DE TRANSPORTE__________________________________________________ 84

4.2.4 CAMADA DE APLICAÇÃO ___________________________________________________ 85

4.2.5 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 86

4.3 IDENTIFICAÇÃO ________________________________________________________ 86

5 Encapsulamento De Protocolos __________________________________________ 87

5.1 ENCAPSULAMENTO POR-INTERFACE. ___________________________________ 87

5.2 ENCAPSULAMENTO POR SERVIÇO (APLICAÇÃO) _________________________ 88

Protocolo de Comunicação é a formalidade adotada para estabelecer a comunicação

Somente os protocolos usados na camada física podem ser insuficientes ou carentes de

É intuitivo que o envio só será confirmado caso o destinatário e os equipamentos

Assim, veremos os seguintes protocolos:

O NetBEUI é um veículo de transporte. É um protocolo de rede e de enlace e não o

Fonte: Microsoft Windows NT Resource Kit. Arquivo network.hlp

2.2.1 Protocolo LLC + Driver = NETBEUI

2.2.2 Protocolo NetBIOS

O NETBIOS implementa um conjunto de serviços tais como: compartilhamento de

Os serviços NETBIOS também podem ser encapsulados em outros protocolos de rede

2.2.4 SEQUENCIA DE ENCAPSULAMENTOS

O DADO é a informação (requisição ou resposta) que será envolvida pelo protocolo da

2.3 SEGMENTAÇÃO DA REDE

Nos GRUPOS DE TRABALHO (ou WORGROUP), uma máquina pertencente ao grupo vê

As máquinas controladoras de domínio, rodando Windows NT Server ou equivalente, usam

• Os controladores de domínio primários (PDC - Primary Domain Controller), que

• Os controladores de domínio de backup (BDC - Backup Domain Controller), que

• b-node -- usam broadcast para o registro e resolução de nomes.

• p-node -- usam solicitações de nomes em conexões ponto-a-ponto feitas ao

• h-node -- usam um servidor de nomes NetBIOS para o registro e tradução;

servidor de nomes disponível. Equipamentos configurados como clientes WINS

• Microsoft-enhanced -- Usam os arquivos locais LMHOSTS ou proxies WINS mais

Informações complementares podem ser encontradas no arquivo network.hlp do Windows

O protocolo IPX (Internetwork Packet Exchange) foi desenvolvido pela NOVELL e é o

A arquitetura do conjunto IPX em relação ao modelo de referencia OSI é apresentado

3.2.1 PROTOCOLO IPX

O IPX é o protocolo freqüentemente associado com redes NetWare e restabelece a parte

O endereço IPX é uma combinação de um endereço de rede e do endereço da placa de

OBS: O IPX não garante o envio, ou proporciona serviços de correção ou detecção de

3.2.2 PROTOCOLO SPX

Exemplos destas aplicações podemos incluir, um cliente-servidor de banco de dados, ou um

informação desejada à aplicação no servidor e esta faz o acesso ao arquivo e envia o

3.2.3 PROTOCOLO PEP

O PEP (Packet Exchange Protocol) é um outro protocolo de transporte similar ao SPX. O

3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:

No envio, a solicitação, resposta, a informação, ou seja o DADO é envolvido pela aplicação