Curso de TCPIP Avançado v.2

Curso de
TCP-IP
Avançado
V.2.0
abril de 2004
AVISO IMPORTANTE
Esta apostila é parte integrante do Curso de TCP-IP Avançado,
desenvolvido pela TopMaster para a Embratel.
O objetivo deste documento é apresentar uma versão textual
do conteúdo do curso online para a conveniência do aluno.
Sua leitura não substitui o estudo online, pois este oferece interações e
animações que não podem ser representadas no formato impresso.
Curso de TCP-IP Avançado 2 de 126

1. Roteamento IP Avançado
1.1. O Conceito de AS
A definição clássica de um Autonomous System é um conjunto de roteadores sob uma única
administração técnica que usam um mesmo IGP (Interior Gateway Protocol) e métricas comuns
para efetuar o roteamento dos pacotes dentro do AS, além de utilizarem um EGP (Exterior
Gateway Protocol) para rotear os pacotes aos outros ASs. No entanto, desde que esta definição
clássica foi desenvolvida, tornou-se comum um único AS usar vários IGP's e até diversas
métricas para a troca de informações de roteamento internas ao AS.
Com isso, uma definição mais apropriada para o termo Autonomous System deve considerar que,
mesmo quando existem múltiplos IGPs e métricas, um AS aparece para outros ASs como um
conjunto coerente de redes que possui uma única e clara política de roteamento totalmente 'invisível'
para os outros ASs, e que permite que estes alcancem as redes internas do AS através do uso dos
EGPs, que são executados nos roteadores que fazem a interface entre os Autonomous Systems.

Os ASs são identificados por um número globalmente unívoco, freqüentemente referido como
ASN (Autonomous System Number). Este número é usado tanto na troca da informação entre
ASs quanto como um identificador interno do AS.
Os valores de AS variam de 0 a 65535 para o BGP (Border Gateway Protocol), que vem a ser o
EGP usado para roteamento entre ASs na Internet, sendo que os valores de 64512 a 65535 são
destinados a ASs privativos usados em redes internas e não propagados externamente.
Como regra geral, recomenda-se colocar o maior número de blocos de endereçamento IP dentro
de um mesmo AS, respeitando a premissa de que todos devem estar em conformidade com a
mesma política de roteamento.
Considera-se fundamentalmente que a obtenção de um AS para um conjunto de blocos de

endereçamento IP somente é necessária quando temos uma política de roteamento diferente à dos
roteadores de borda que nos conectam com o resto da Internet. Definimos como política de
roteamento o modo pelo qual os outros ASs tomam decisões de roteamento para alcançar os blocos
de endereço IP do meu Autonomous System baseadas nas informações fornecidas por ele.
Tipos de AS
AS Trânsito São ASs usados como passagem de tráfego entre ASs.
Stub AS São ASs como um único ponto de entrada/saída. Não há tráfego de outros ASs
passando por um Stub AS.

1.2. Protocolo EGP
O protocolo EGP (Exterior Gateway Protocol) é um protocolo de roteamento do tipo externo, ou
seja, é utilizado pelos roteadores que conectam diferentes ASs (Autonomous Systems), os
chamados 'exterior routers', para anunciar as informações que permitem a comunicação entre
diferentes ASs.
O EGP foi o protocolo de roteamento externo mais utilizado para interligação dos diversos ASs
da Internet até o início dos anos 90, quando o principal backbone da grande rede pertencia à
National Science Foundation, instituição de pesquisa vinculada ao governo dos EUA.
O EGP está fundamentado em três tipos de processo de comunicação:

• Estabelecimento de vizinhança: para que a troca de informação entre exterior
routers seja possível, é preciso que os mesmos estabeleçam uma relação de
vizinhança (neighboring). A partir daí, as informações de controle e roteamento
poderão ser trocadas entre os, agora, exterior neighbors routers.
• Verificação do estado do roteador neighbor: Os exterior neighbors checam
periodicamente se o seu parceiro está UP por meio de mensagens de controle
trocadas entre eles.
• Troca de informação de roteamento: Após o estabelecimento da vizinhança e
depois da verificação do estado do EGP neighbor, os exterior neighbor routers
estão prontos para trocarem as informações de roteamento que permitirão que os
hosts localizados em seus respectivos ASs consigam comunicar-se entre si.

Tipos de mensagem do protocolo EGP
O funcionamento do EGP baseia-se em três tipos de comunicação entre os roteadores que
executam o protocolo: estabelecimento de vizinhança (Neighbor Acquisition), verificação do
estado do roteador neighbor (Neighbor Reachability) e troca de informação de roteamento.
Essas três categorias ou tipos de mensagens podem ser divididas em nove subtipos definidos pelo
protocolo EGP para sua execução.
Independentemente do tipo de mensagem EGP que está sendo enviada, encontraremos os

seguintes campos comuns a todos os pacotes de mensagens:
Version
Identifica a versão do EGP usada pelo remetente. O roteador que recebe a mensagem verifica se a versão
do EGP que se está usando é compatível.
Type
Identifica o tipo de mensagem.
Code
Identifica o subtipo para cada tipo de mensagem.
Status
Informa o status. Os valores diferem dependendo do tipo de mensagem.
Checksum
Verifica a integridade da mensagem.
Autonomous System Number (ASN)
Identifica o AS ao qual pertence o roteador remetente.
Sequence Number
Número usado para identificar mensagens enviadas e suas respostas. Quando dois roteadores tornam-se
neighbors, cada um determina um número seqüencial inicial para suas mensagens. Cada mensagem é
enviada com o seqüencial e as respostas a essas mensagens contêm o mesmo número de seqüência.
Descrição das mensagens EGP

A tabela, a seguir, resume os tipos de mensagens do protocolo EGP, bem como os subtipos de
mensagens. Clique em cada um deles para saber mais sobre o tipo ou subtipo referido.

Neighbor Acquisition Request: Solicitação para torna-se um neighbor
Acquisition Acquisition Confirm: Resposta positiva ao Acquisition Request
Acquisition Refuse: Resposta negativa ao Acquisition Request
Cease Request: Solicita o fim de uma relação de neighbor
Cease Confirm: Resposta de confirmação ao Cease Request
Neighbor Hello: Solicita ao neighbor que responda se estiver 'vivo'

Reachability I Heard You: Resposta ao Hello
Informação de Poll Request: Solicita a atualização das informações de roteamento

roteamento Routing Update: Informações de roteamento
Mensagens de Estabelecimento de Vizinhança (Neighbor

Acquisition Messages)
A fim de iniciar o processo de comunicação EGP, um roteador envia uma mensagem de Neighbor
Aquisition ao seu par pertencente a outro AS para, com isso, criar a relação de vizinhança entre
ambos.
Além dos campos comuns a todas as mensagens EGP, dois campos são específicos das
mensagens de Neighbor Acquisition: Hello Interval e Poll Interval.
As mensagens de Neighbor Acquisition são do tipo 3 e possuem 5 subtipos identificados pelos

códigos de 0 a 4.
O cabeçalho completo deste tipo de mensagem fica, portanto, como se segue:
Code (0 a 4)
Subtipos das Mensagens de Neighbor Acquisition (Type 3)
Code 0: Acquisition Request
Code 1: Acquisition Confirm
Code 2: Acquisition Refuse
Code 3: Cease Request
Code 4: Cease Confirm
Hello Interval - Especifica o intervalo de tempo que deverá ser usado entre os neighbors para a
verificação de estado de seus pares (se Up ou Down).

Mensagens de Verificação do Estado do Roteador Neighbor
(Neighbor Reachability Messages)
O mecanismo pelo qual o EGP verifica se o roteador neighbor está UP, ou seja, apto a receber as
mensagens de atualização de rotas, é o envio de mensagens de Hello. A cada n segundos,
definidos no estabelecimento dos neighbors, um dos pares envia uma mensagem de Hello para o
seu neighbor que responde com a mensagem I Heard You, confirmando, dessa forma, seu estado
de 'vivo' e operante.
Considerando a hipótese de perda de mensagens por motivos como congestionamento na rede ou

aumento na taxa de erros do meio físico, o EGP tem como padrão aguardar 2 pacotes de
mensagem de Hello não respondidas para considerar o estado do neighbor como DOWN. Da
mesma forma, é preciso que haja 2 respostas consecutivas a mensagens de Hello para que um
neighbor que encontrava-se em estado DOWN seja considerado novamente operante.
O formato das mensagens de Hello e sua resposta I Heard You consiste no cabeçalho padrão do
EGP com campo de tipo igual a 5 e dois subtipos (códigos) iguais a 0 e 1, significando Hello e I
Heard You, respectivamente.
Code (0 a 1)
Subtipos das Mensagens de Neighbor Reachability (Type 5)
Code 0: Hello
Code 1: I Heard You

Mensagens de troca de informação de roteamento
As informações de atualização de rotas são passadas via mensagens de Routing Update em
resposta a mensagens de solicitação de informações de roteamento do tipo Poll Request.
Mensagem Poll Request

Depois de transcorrido o tempo acordado durante o processo de estabelecimento de
vizinhança para solicitação de informação de rotas (Poll Interval), um dos pares envia um
Poll Request contendo o cabeçalho padrão EGP e o campo IP Source Network. Esse
campo identifica a rede comum aos ASs de ambos os EGP neighbors, que muitas das
vezes consiste na própria rede que conecta os EGP neighbors.
Mensagem de Routing Update

A mensagem de Routing Update, enviada em resposta ao Poll Request, contém uma lista
de gateways localizados na rede comum (IP Source Network) e a lista de redes que
podem ser acessadas através desses gateways.
Dois tipos de listas de gateways podem ser enviadas:
Lista Interna (Interior Gateways)

Contém somente os gateways pertencentes ao mesmo AS do EGP neighbor que
envia a mensagem de Routing Update.

Lista Externa (Exterior Gateways)
Contém gateways de outros ASs que são também caminho para as redes em
questão.
É importante observar que as listas internas e externas NÃO são incluídas na mesma
mensagem; elas são sempre anunciadas em mensagens distintas.
As distâncias são medidas em hop counts, isto é, pela quantidade de roteadores que são
transpassados entre a Source Network e as redes contidas no bloco de mesma distância
(Distance 1, Distance 2,..., Distance n).

Entretanto, essas distâncias não são levadas em conta como indicadores de melhor rota na
comunicação entre os exterior routers de diferentes ASs. O fato de existir uma métrica de
distância somente indica que a rede anunciada pode ser alcançada através do gateway
associado. Na verdade, a arquitetura do EGP considera que somente deve haver 1
caminho para qualquer rede participante, não considerando, portanto, rotas alternativas.
A mensagem de Routing Update tem a seguinte estrutura:
# Interior Gateways: Número de Interior Gateways que aparecem na mensagem.

# Exterior Gateways: Número de Exterior Gateways que aparecem na mensagem.
IP Source Network: Rede a partir da qual as distâncias são medidas.

Gateway n IP Address: Endereço IP do gateway n da lista.
# Distances: Número de distâncias existentes para um mesmo gateway.
Distance n: Identifica a quantidade de hop counts para se alcançar as redes contidas neste
bloco.
# Networks: Número de redes existentes alcançáveis através da mesma distância.
Network n: Endereço IP da rede.
Limitações do Protocolo EGP

O EGP foi inicialmente projetado para uma Internet de dimensões reduzidas onde o backbone
NFSNet era formado por uma quantidade muito pequena de roteadores. Com o estouro da Internet
comercial, este protocolo mostrou muitas deficiências que fizeram com que o BGP fosse a
solução escolhida a partir do início dos anos 90.
Algumas das limitações do EGP que lhe conferem um baixo grau de escalabilidade, são:
- Toda a conectividade é perdida em caso de falha dos roteadores conectados
diretamente ao backbone principal (core system routers);
- O EGP somente permite o anúncio de 1 caminho para cada rede;
- Não permite balanceamento de carga entre ASs mesmo que existam múltiplos
roteadores fazendo a conexão entre eles;
- O EGP não se adequa à arquitetura de redes com múltiplos backbones.
A seção sobre o protocolo BGP mostra, entre outros assuntos, como o BGP trata estas limitações.
1.3. Protocolo BGP

O Border Gateway Protocol (BGP) é um protocolo de roteamento tipicamente usado para
viabilizar a comunicação entre ASs. Foi construído baseado na experiência obtida com o EGP no
backbone da NSFNET como descrito nas RFCs 1092 e 1093.
O BGP é um protocolo bastante robusto e escalável, evidenciado pelo fato de que o BGP é
amplamente empregado no backbone da Internet nos dias de hoje.
O BGP necessita estabelecer uma sessão TCP para que a troca de informações possa acontecer. O
TCP atende às exigências de transporte do BGP e é suportado por praticamente todos os
roteadores e hosts comerciais. O BGP usa a porta TCP/179 em suas conexões.
Estima-se que as tabelas de rotas BGP da Internet somam atualmente mais de 90.000 entradas.
Para conseguir uma escalabilidade nesse patamar, o BGP usa atributos para definir políticas de
distribuição de rotas e manter um ambiente de roteamento estável.

Além dos atributos que definem as políticas de roteamento, o suporte ao CIDR (Classless Inter-
Domain Routing) é outra feature importante do BGP, que permite reduzir o tamanho das tabelas
de rotas da Internet.
Exemplo:
CIDR - Classes Inter-Domain Routing
Suponha que um ISP tenha recebido o bloco 195.10.x.x do espaço de endereçamento da classe C. Este
bloco consiste em 256 redes classe C: de 195.10.0.x até 195.10.255.x. Consideremos então que o ISP
ceda um bloco de rede classe C a cada um de seus clientes. Sem CIDR, o ISP anunciaria 256 entradas de
rede classe C a seus pares BGP. Com CIDR, é possível fazer o supernetting desse bloco, anunciando
somente uma rota para os outros roteadores, o que significa somente uma entrada na tabela de
roteamento: 195.10.x.x. Ou seja, o BGP desconsidera as distinções tradicionais de classes de
endereçamento (A, B e C) graças ao suporte ao CIDR, permitindo uma redução significativa em suas
tabelas de rotas.
Outra característica importante do BGP consiste no fato de que os roteadores somente trocam as
tabelas de rotas completas quando a conexão TCP entre os pares (peers) ou neighbors BGP é
estabelecida inicialmente. A partir daí, apenas as alterações são enviadas. Além disso, os roteadores
BGP não emitem updates periódicos de suas tabelas de roteamento e sim utilizam o método de
Triggered Updates onde as atualizações de rotas são enviadas somente quando algum evento pré-
definido dispara o processo de emissão de informações. Dessa forma, o uso da banda dos circuitos
de longa distância que comumente conectam os pares BGP (BGP peers) é otimizado.
iBGP e eBGP
iBGP ou Internal BGP é usado para troca de informações de roteamento entre roteadores dentro
do mesmo AS. Para que as mensagens iBGP possam ser trocadas, é preciso que exista a conexão
entre todos os roteadores do AS constituindo uma topologia lógica de Full-Mesh. eBGP ou
External BGP é usado para troca de informações de roteamento entre diferentes ASs. É preciso
que seja apenas estabelecida a sessão entre os Neighbors BGP diretamente conectados entre si.
Quando usar ou não o BGP

O BGP é um protocolo de roteamento bastante complexo e, portanto, a primeira análise a ser feita
é a que define a necessidade de usá-lo em detrimento a rotas estáticas ou rotas default.
Devemos usar o BGP quando:

- For necessária a comunicação entre ASs;
- Precisa-se manipular o tráfego de saída de nosso ASs. Por exemplo, quando
desejamos definir que o tráfego X sairá pelo roteador RX e o tráfego Y sairá pelo
roteador RY;
- Deseja-se conectar dois ou mais ISPs entre si;
- Deseja-se conectar uma empresa a mais de um ISP.

Não devemos usar o BGP quando:
- O hardware do roteador não suporta a carga de processamento e de memória
exigida. Lembre-se de que a tabela BGP da Internet hoje contém em torno de
90.000 entradas;
- A empresa possui apenas 1 ligação com a Internet. Nesse caso, recomenda-se o
uso de rota default;
- Quando a conexão não possui banda suficiente para atender à carga de tráfego
requerida pelo BGP.
Mensagens BGP
Cabeçalho comum
Antes de entrarmos na análise dos detalhes de cada tipo de mensagem, apresentaremos os campos
do cabeçalho BGP comuns a todos os tipos de mensagem.
Marker
Serve para verificar a autenticidade da mensagem recebida e se houve perda de sincronização entre os
roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem seja do tipo OPEN (abrir), ou se a
mensagem tipo OPEN não possuir informação de autenticação, o campo deve estar todo preenchido com
números um (1); caso contrário, o campo terá o seu conteúdo baseado em parte do mecanismo de
autenticação usado.
Length
Indica o tamanho total da mensagem BGP, incluindo o cabeçalho.
Type
Tipo da mensagem que está sendo enviada. São 4 os tipos de mensagens utilizadas pelo BGP em seus
processos de roteamento:
Valor do campo Type 1: Mensagem OPEN
Valor do campo Type 2: Mensagem UPDATE
Valor do campo Type 3: Mensagem NOTIFICATION
Valor do campo Type 4: Mensagem KEEPALIVE
BGP OPEN Message

Esta é a primeira mensagem emitida logo após a sessão TCP ter sido estabelecida entre os BGP
peers. Nesta mensagem, é identificado o AS ao qual pertence o roteador. São acertados os
parâmetros do protocolo e temporizadores que serão usados ao longo da sessão.

Mensagem BGP OPEN
Version
Indica a versão do BGP. Este campo permite que os BGP peers negociem a maior versão comum a ambas
as partes. Quando, por exemplo, um peer recebe uma mensagem indicando que a outra parte executa a
versão 4 e ele suporta uma versão inferior. O recipiente envia uma mensagem de erro e o remetente
solicita uma nova sessão com os parâmetros usados pela versão inferior.
My Autonomous System
ASN do roteador que envia a mensagem de OPEN.
Hold Time
Tempo máximo que os peers esperam antes de considerar a conexão terminada. O valor mínimo permitido
para este parâmetro é de 3 segundos.
BGP Identifier
Pela especificação do BGP, o identificador é um valor randômico e único escolhido pelo roteador no
momento do envio da mensagem OPEN. As implementações práticas usam o endereço IP da interface em
saída da mensagem ou, se definido, o endereço de loopback.
Optional Parameters Length
Indica o tamanho do campo de parâmetros opcionais (Optional Parameters).
Optional Parameters
Parâmetros opcionais incluídos na mensagem BGP OPEN.
BGP UPDATE Message

Esta mensagem carrega as mudanças de topologia. A mensagem de UPDATE pode conter uma
nova rota, rotas a serem removidas ou ambas.
Mensagem BGP UPDATE
Withdrawn Routes Lengh

Tamanho do campo Withdrawn Routes em octetos.

Withdrawn Routes
Lista de rotas a serem excluídas, seja pelo fato de o caminho não mais existir ou pela inclusão de políticas
que limitem o acesso à rede destino.
Total Path Attributes Length
Tamanho do campo Total Path Attributes.
Path Attributes
São um conjunto de parâmetros associados a uma determinada rota que influenciam no processo de
decisão do BGP em relação à escolha da melhor rota. Mais adiante, estes atributos serão vistos com mais
detalhes.
Network Layer Reachability Information (NLRI)
São prefixos de endereços IP de informações no formato <comprimento, prefixo>. Um exemplo de
entrada seria: <24,200.210.10.0>, que indica uma rota para 200.210.10.0 255.255.255.0 (ou
200.210.10.0 /24, na notação CIDR).
Atributos BGP
Conforme visto, as mensagens UPDATE incluem o campo PATH Attributes que carrega
as informações dos atributos BGP para as rotas anunciadas no campo NLRI. Os Path
Attributes podem ser considerados como métricas usadas pelo BGP que passam pelos
routers para seus peers.
Categorias de atributos
Existem as seguintes categorias de atributos:

• Well-Known Mandatory
Trata-se de um atributo definido na especificação original do protocolo BGP.
Deve estar obrigatoriamente presente em todas as mensagens do tipo UPDATE e
deve ser reconhecido em todas as implementações do protocolo. Caso não esteja
presente na mensagem UPDATE, será enviada uma mensagem do tipo
NOTIFICATION informando o erro.
• Well-Known Discretionary
É o tipo do atributo reconhecido por todas as implementações do protocolo BGP
mas que não precisa estar obrigatoriamente presente em todas as mensagens
UPDATE enviadas.
Além dos atributos Well-Known, existem os opcionais, que podem ser transitivos ou não
e que não são obrigatoriamente suportados por todas as implementações do BGP.
Atributos transitivos são repassados nas mensagem de UPDATE para os peers seguintes.
• Optional Transitive
Se determinada implementação do BGP não reconhecer um atributo opcional ao
receber uma mensagem UPDATE, ela verificará se a flag Transitive está ativada
ou não para aquele atributo. Caso esteja, esse atributo é repassado nas mensagens
UPDATE seguintes, enviadas pelo roteador para seus pares.
• Optional Non-Transitive
Inverso do opcional transitivo. Se a implementação do BGP não reconhecer o
atributo opcional e não encontrar a flag transitive ativada, o atributo é ignorado e
NÃO é repassado para os vizinhos BGP nas mensagens UPDATE subseqüentes.

Vale observar que TODOS os atributos Well-Known são transitivos.
Tipos de atributos
Vistas as quatro categorias de atributos, vamos descrever agora os tipos de atributos
encontrados nas mensagens de UPDATE do BGP.
ORIGIN
Well-Known Mandatory
Indica a origem do anúncio de rota ou NLRI (que indica o prefixo e a máscara de
bits) em relação ao AS que o originou. Pode conter um dos seguintes valores:
Valor Descrição
0 IGP
A origem é interna ao AS originário da mensagem (indicado por um "i"
na tabela de rotas), seja ela recebida através da redistribuição das rotas do
IGP para o BGP (do mesmo AS) ou pela simples configuração do BGP
naquele roteador.
1 EGP
A origem é de um AS externo e foi recebida por um anúncio de um EGP.
É identificada por um "e" na tabela de rotas. Este tipo de entrada
dificilmente será visto nas tabelas de rotas atualmente.
2 INCOMPLETE
A NLRI é desconhecida ou aprendida por outros meios (além dos acima).
Geralmente acontece quando uma rota estática (configurada
manualmente por um operador) é redistribuída no BGP e a origem da rota
fica incompleta. É indicada por um "?" na tabela de rotas.
AS PATH
É uma seqüência de ASNs que uma rota cruza para alcançar uma determinada
rede de destino. O AS que origina uma rota acrescenta seu ASN ao anunciar uma
rota sua para seus peers BGP externos. Daí em diante, cada AS que receber a rota
acrescenta seu próprio ASN no início da seqüência de ASNs e repassa a rota para
outros peers seus que irão fazer o mesmo. A lista final vai representar todos os
ASNs que uma rota atravessou com o ASN do AS de origem da rota no final da
seqüência, também conhecida como AS_Sequence.
Caso um AS receba um anúncio de rota que contenha seu próprio ASN na seqüência
inclusa no AS_PATH, este anúncio será rejeitado e descartado, garantindo assim que não
haverá loop de roteamento na tabela BGP desse AS.

Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informação contida
no AS_PATH não é alterada.
A informação contida no AS_PATH é uma das usadas no processo de seleção da

melhor rota para determinado destino. Ao comparar duas rotas para um mesmo
destino (considerando que os outros atributos sejam idênticos), o BGP vai
preferir a que possuir o AS_PATH menor. Caso o caminho (path) seja do mesmo
tamanho, o BGP vai usar outros atributos para fazer a sua escolha da melhor rota.
NEXT HOP
Este atributo contém o endereço IP da interface do próximo roteador - próximo
salto (next hop) a ser dado - para se chegar a determinado destino, ou seja, às
redes de destino incluídas na mensagem UPDATE.
Um roteador BGP nunca deve anunciar como NEXT_HOP o IP do roteador de

onde foi originada a mensagem de UPDATE recebida, a fim de evitar loops de
roteamento.
MED - MULTI_EXIT_DISCRIMINATOR
Optional Non-Transitive
Este atributo tem como finalidade informar para os vizinhos BGP externos
(peers) qual o melhor caminho (path) para uma determinada rota do próprio AS,
influenciando-os, assim, em relação ao caminho a ser seguido no caso de o AS
possuir diversos pontos de entrada.
O MED é anunciado somente entre ASs. No entanto, só o AS de origem pode

fazer anúncios com valores neste atributo. Um AS vizinho que receba o atributo
via mensagem UPDATE não pode repassar o valor desse atributo a outros ASs
fazendo uso dos mesmos apenas para tomadas de decisão internas do AS.
Um exemplo seria quando o anúncio da rota é repassado a um terceiro AS e o
atributo MED recebe o valor 0 (zero). O BGP seleciona a rota que possuir o
atributo MED com menor valor. Havendo contato com mais de um vizinho BGP
pertecentes a um mesmo AS que façam anúncios com métrica, o roteador (do AS
vizinho) que receber os UPDATEs vai comparar as métricas para os caminhos
oferecidos por estes roteadores, se ele não for configurado para o contrário.
LOCAL_PREF (Local Preference)

Well-Known Discretionary
Este atributo anuncia qual é o caminho preferencial de saída (de pacotes) para
uma determinada rota, destinada a uma rede externa ao AS. Como o próprio
nome do atributo sugere, o LOCAL_PREF somente é anunciado (repassado)
entre os roteadores vizinhos BGP (iBGP) do mesmo AS e não é repassado aos
roteadores vizinhos externos (eBGP). Caminhos (paths) que possuem o
LOCAL_PREF com maior valor são preferidos pelo BGP. O valor padrão do
LOCAL_PREF é 100.
ATOMIC_AGGREGATE
Well-Known Discretionary
Este atributo é usado por um roteador que, ao ter que selecionar uma rota dentre

outras recebidas de seu peer que se sobrepõem, escolhe uma, ignorando a mais
específica. Então, ele deve incluir o atributo ATOMIC_AGGREGATE à rota
quando for propagá-la a seus vizinhos (caso o atributo ainda não esteja presente
na rota menos específica recebida).
Um roteador que receba uma rota com o atributo ATOMIC_AGGREGATE não

deve removê-lo e não deve fazer nenhum NLRI da rota mais específica quando
for propagar a rota aos vizinhos BGP. Ele precisa também reconhecer que o
caminho atual para os destinos (como especificado no campo NLRI da rota),
respeitando a ausência de loops de roteamento, pode cruzar ASs que não estejam
listados no AS_PATH.
Outra observação importante: não é possível agregar um endereço sem ter uma
rota mais específica daquele endereço na tabela de roteamento. Por exemplo: um
roteador não pode gerar uma rota agregada para 196.0.0.0 sem possuir
previamente uma rota de 196.10.0.0 em sua tabela de roteamento.
AGGREGATOR
Optional Transitive
Este atributo pode ser incluído em mensagens UPDATE que sejam formadas por
agregação. O atributo AGGREGATOR contém o ASN do último roteador que
formou uma rota agregada, seguido de seu próprio ASN e endereço IP.
COMMUNITY
Optional Transitive
Este atributo é usado para representar um agrupamento de destinos que
compartilhem uma ou mais características que não estão restritas a um mesmo
AS, rede ou conjunto de redes. As delimitações do agrupamento são em termos
de Routing Policies (políticas de roteamento), podendo envolver mais de um AS,
inclusive. As comunidades (Communities) podem ser compostas de diversas
redes pertencentes a qualquer AS, usadas para simplificar políticas de roteamento
através da identificação de rotas por algum parâmetro lógico ao invés de prefixos
CIDR ou ASNs. Usando esses atributos, um roteador pode combiná-los com
outros para determinar para cada comunidade as rotas a serem aceitas,
descartadas, preferidas ou repassadas para outros vizinhos.
WEIGHT
Definido pela Cisco Systems, o WEIGHT não é propriamente um atributo BGP.
Ele influencia no processo de seleção da melhor rota do roteador onde for
definido e, como é um atributo local ao roteador, não é repassado e nem
propagado aos seus vizinhos nas mensagens UPDATE. O WEIGHT é um valor
decimal entre 0 e 65535, sendo o valor padrão igual a 32768, assumido para rotas
originadas pelo roteador. Outras rotas possuem o WEIGHT igual a 0 (zero), por
padrão. Havendo mais de uma possível rota para um mesmo destino, o BGP-4
seleciona a que possuir o atributo WEIGHT com maior valor.
Este atributo é comumente usado pelos operadores de redes para influenciar o

processo de escolha de rotas do BGP.

BGP NOTIFICATION Message
Este tipo de mensagem é enviada no caso de detecção de erros durante ou após o estabelecimento
de uma sessão BGP.
Cód. Descrição Sub-códigos de erro
1 Erro no cabeçalho da mensagem Sub-código Descrição
1 Conexão não sincronizada
2 Comprimento da
mensagem inválido
3 Tipo de mensagem
inválido
2 Erro na mensagem OPEN Sub-código Descrição
1 Número de versão não

suportado
2 Número de AS vizinho
inválido
3 Identificador BGP inválido
4 Parâmetro opcional não

suportado
5 Falha na autenticação
6 Tempo de espera
inaceitável
3 Erro na mensagem UPDATE Sub-código Descrição
1 Lista de atributos mal

formada
2 Atributo Well-Known
desconhecido

3 Atributo Well-Known
faltando
4 Erro nas flags de atributos
5 Erro no comprimento do
atributo
6 Atributo origem inválido
7 Loop de roteamento em
AS
8 Atributo NEXT_HOP
inválido
9 Erro no atributo Opcional
10 Campo de rede inválido
11 AS_path mal formado
KEEPALIVE Message
São mensagens trocadas periodicamente com o propósito de verificar se a comunicação entre os
vizinhos está ativa. A mensagem do tipo KEEPALIVE é composta apenas do cabeçalho padrão
das mensagens BGP, sem dados transmitidos após o cabeçalho. O tempo máximo permitido para
o recebimento de mensagens KEEPALIVE ou UPDATE é definido pelo hold time, como foi visto
na descrição do tipo de mensagem OPEN.
BGP Light
A Embratel oferece uma modalidade de BGP a seus clientes chamada de BGP Light.
Conforme especificado na RFC 1930, o bloco de ASNs entre 64512 e 65535 é reservado para uso
privado e estes não devem ser anunciados para o restante da Internet. Dessa forma, é possível
criar uma AS para um cliente, com os benefícios de administração, redundância dos links e
distribuição de tráfego, sem a necessidade de arcar com altos custos de roteadores de grande porte
capazes de manter a tabela inteira de BGP em sua memória.
Duas formas de roteamento são oferecidas:

• Full route: mantém todas as tabelas de rotas, o que exige muita memória do
roteador. Logo, este terá que ser de maior porte

• Partial route: mantém as rotas nacionais, as rotas conectadas ao AS e as rotas
default com redundância, permitindo o roteamento em caso de queda de um link
pelo roteador remanescente.
Note que o cliente fica conectado a dois centros de roteamento diferentes, efetivamente
garantindo a redundância do link.
Lógica para seleção de rotas BGP

Com os conceitos básicos do BGP e, principalmente, com a compreensão dos atributos incluídos
nas mensagens de atualização (UPDATE), mostraremos como o BGP escolhe a melhor rota entre
dois pontos baseado nos PATH Attributes.

1.4. Protocolo EIGRP
O protocolo Enhanced Interior Gateway Routing Protocol (EIGRP) é um protocolo de roteamento
interno (IGP) desenvolvido pela Cisco Systems. Conceitualmente, o EIGRP é um protocolo do
tipo Distance-Vector que possui algumas características comumente encontradas em protocolos
do tipo Link-State, o que o torna um protocolo de roteamento bastante versátil.

O algoritmo de cálculo de melhor rota, DUAL (Diffusing Update Algorithm), permite uma rápida
convergência quando ocorrem mudanças na topologia. Uma rede converge quando, após uma
alteração de estado em um circuito, as tabelas de todos os roteadores que “conhecem” o circuito
são atualizadas.
O EIGRP somente envia Updates (atualizações) quando há alterações na topologia da rede e

apenas para os roteadores que precisam saber destas alterações (neighbors). Quando não existem
alterações, somente mensagens de Hello são trocadas entre vizinhos . Por não enviar Updates
periódicos para todos os roteadores, o uso da banda da rede é bastante otimizado.
O EIGRP suporta os principais protocolos rateáveis em uso atualmente – IP, IPX e Appletalk –
tornando-o uma opção apropriada para redes heterogêneas.
Relações de Vizinhança
Usando mensagens de Hello, o EIGRP estabelece e mantém relações de vizinhança (Neighboring
Relationship), sendo elas responsáveis por determinar o estado da conexão entre os neighbors. Ao
ser estabelecida a relação de vizinhança, as informações de roteamento podem ser trocadas entre
os neighbors.
As mensagens de Hello são trocadas por default a cada 5 segundos em circuitos ponto a ponto
como PPP, HDLC e Frame-Relay point-to-point. Este período é chamado de Hello Interval. O
período de tempo que um roteador aguarda antes de considerar o neighbor fora de operação é
chamado Hold-Time interval e o seu valor padrão é três vezes o Hello Interval, portanto, 15
segundos.

Cada instância EIGRP sendo executada cria e mantém uma tabela de neighbors, contendo
informações como endereço IP e Hold-Time Interval referente a cada Neighbor.
O único momento em que o EIGRP anuncia as informações completas de roteamento é quando os

neighbors iniciam a comunicação. A partir daí, somente as alterações são divulgadas.
O EIGRP baseia-se em três tabelas para seu processo de descoberta, cálculo e anúncio de rotas.
São elas:
• Tabela de neighbors: Contém as informações de todos os vizinhos, tais como
endereço IP e Hold-Time Interval.
• Tabela de topologia: Contém as informações conseguidas pelo próprio roteador,
assim como as recebidas dos neighbors sobre todos os caminhos possíveis para
um determinado destino.
• Tabela de rotas: Contém os caminhos de menor custo para os destinos
aprendidos pelo próprio roteador ou via neighbors.
Cálculo da melhor rota

O algoritmo DUAL usado para o cálculo de melhor rota tem como importantes características a
possibilidade de uso de rotas secundárias ou stand-by, suporte a VLSM (Variable Length Subnet
Mask) e envio de querie para os neighbors em busca de rotas para destinos que não possuem
entradas na tabela de rotas do roteador local.
Sempre que uma mensagem de Update é recebida tratando de uma alteração na rota para um
destino ou destinos existentes na tabela de rotas local ou anunciando uma nova rota para um novo
destino, o processo de recálculo de rotas é iniciado.

Quando a nova informação chega, é criada uma nova entrada na tabela de topologia. Essa tabela
pode armazenar até seis caminhos para o mesmo destino, o que significa que o EIGRP pode
selecionar a melhor rota dentre até seis caminhos redundantes.
A seleção é feita com base no custo de cada caminho que, por sua vez, é o resultado de métricas
que consideram fatores como banda passante (bandwidth), atraso (delay), confiabilidade
(reliability) e taxa de uso do circuito (load).
• Bandwidth: A vazão ou banda passante de um circuito. O valor default é dado
baseado no tipo de interface do roteador onde o circuito conecta-se, mas deve ser
alterado manualmente pelo administrador da rede visando refletir corretamente a
banda real contratada.
• Delay: O atraso na propagação do sinal dado fundamentalmente pelo tipo de
meio de transmissão. Uma transmissão via satélite, por exemplo, terá um atraso
maior do que uma transmissão via fibra ótica se tivermos como premissa que a
distância percorrida seja a mesma.
• Reliability: A confiabilidade do circuito dada pela média de erros ou
indisponibilidade do mesmo em um período de tempo (default é de 5 minutos nos
roteadores Cisco).
• Load: A taxa média de utilização do circuito em um período de tempo (default é
de 5 minutos).
A composição de alta banda, baixo atraso, alta confiabilidade e baixa carga é o que o EIGRP
busca para escolher a rota com custo inferior. A rota de menor custo dentre as existentes na tabela
de topologia é transferida para a tabela de rotas e designada como Ativa (Active Route). As rotas
com custos superiores a ela são marcadas como Possíveis sucessoras (feasible sucessors) em caso
de falha da rota Ativa.
Obs: Na prática, os roteadores Cisco somente consideram por default Bandwith e Delay para
composição do custo, podendo-se configurar Reliability e Load manualmente caso haja interesse
do administrador.
O processo de seleção de rotas

A figura, a seguir, ilustra o processo de seleção de rotas.

Balanceamento de carga
O EIGRP é capaz de balancear a carga entre circuitos de mesmo custo para um mesmo destino,
distribuindo o tráfego igualitariamente entre os mesmos. Até aqui não há nenhuma grande
vantagem em relação a outros protocolos de roteamento como OSPF, que podem também efetuar
este tipo de balanceamento.
A grande diferença é a capacidade do EIGRP em balancear circuitos com custos diferentes. Isto é
possível quando usamos o comando variance , que faz com que sejam incluídas como rotas ativas
as feasible sucessors que tenham custo menor ou igual a menor custo computado * variance.
Exemplo:
Temos 3 rotas para um mesmo destino. O menor custo é 20. Caso definamos uma variância de 2,
teríamos as rotas com custo <= 40 incluídas no rol de rotas ativas. Com isso, a rota 2 também
seria considerada ativa e colocada na tabela de rotas.
A inteligência do EIGRP faria a distribuição do tráfego na proporção de 2/1, ou seja, para cada
pacote que passasse pela Rota 2, dois passariam pela rota 1.

1.5. Protocolo Is-Is
O protocolo de roteamento Intermediate System-Intermediate System foi desenvolvido pela ISO
(International Standards Organization) para prover roteamento em ambientes baseados nos
protocolos especificados pelo OSI, órgão da ISO responsável pela definição dos protocolos de
interconexão de sistemas abertos, isto é, não proprietários.
Intermediate System é o termo usado pela ISO para definir roteador. O IS-IS é, portanto, um
protocolo usado para comunicação entre IS’s ou, usando o termo mais familiar para nós, entre
roteadores. Utilizaremos os nomes IS e roteador para nos referirmos ao mesmo objeto de rede em
nosso curso.

O IS-IS é um protocolo de roteamento que fornece as facilidades de roteamento dentro de um
mesmo domínio. Podemos entender como domínio no mundo OSI/ISO o que chamamos de AS
em nosso conhecido mundo TCP/IP. Portanto, o IS-IS é o equivalente a um IGP (Interior
Gateway Protocol), que é o protocolo de roteamento executado dentro de um mesmo AS. Como
exemplos, teríamos o OSPF e o EIGRP.
Similar a outros protocolos já vistos neste curso, tais como BGP e EIGRP, o IS-IS precisa
estabelecer uma relação de vizinhança para que as informações de roteamento possam ser
trocadas.
Tipos de IS
O IS-IS usa uma estrutura hierárquica de 2 níveis em seu processo de roteamento: domínio e área,
sendo que áreas são subdivisões lógicas dos domínios.
Com base nessa estrutura hierárquica, temos dois tipos de roteadores no ambiente IS-IS:
• Nível 1: Conhecem e trocam informações sobre a topologia interna de uma área
com todos os outros IS’s da mesma área. Por outro lado, não têm qualquer
conhecimento sobre os IS’s ou redes destino de outras áreas.
• Nível 2: Conhecem todas as outras áreas de um mesmo domínio mas não têm a
visibilidade do que existe em termos de roteadores e redes dentro das áreas. Para
que um roteador de nível 1 possa comunicar-se com outra área, ele deve enviar o
pacote para um roteador de nível 2 localizado em sua área, que encaminhará o
pacote para outra através de outro roteador de nível 2 localizado na área destino.

Tipos de pacotes
São 3 os tipos de pacotes usados pelo IS-IS em seu processo de roteamento: Hello, Link State e
Sequence Number.
• Hello Packets: São usados para iniciar e manter adjacências ou relações de
vizinhança entre neighbors IS-IS. Temos 3 tipos de Hello: Nível 1, trocados entre
IS’s de nível 1; nível 2 LAN, trocados entre IS’s de nível 2 em redes locais; e
nível 2 ponto-a-ponto, que são usados em redes ponto-a-ponto não orientadas a
broadcast.
• Link State Packets: Usados para troca de informação sobre o estado dos
circuitos (Links). São 2 os tipos de LSPs: LSP nível 1, trocados entre os IS’s de
nível 1 e LSP nível 2 trocados entre os IS’s de nível 2. Vale observar que os IS’s
de nível 2 normalmente também consistem em IS’s de nível 1, já que conhecem
seus pares e a topologia de dentro da sua própria área. Com isso, os IS’s de nível
2 também trocam LSPs de nível 1.
• Sequence Number Packets: Têm como função controlar o tráfego de LSPs,
servindo como um pacote de ACK no sentido de controlar o recebimento de
pacotes de LSP baseados no número de seqüência.
Interação.
Processo de roteamento
O processo de roteamento pode ser decomposto em 4 funções:
• Decision Process: Calcula as rotas para cada destino. Se o IS for de nível 2, há
um processo separado para cada nível. Baseia-se na tabela de Link-State para o
calculo da melhor rota.
• Update Process: Este processo monta, propaga e recebe as informações de Link-
State. Este processo também é responsável pela manutenção da tabela de link-
state.
• Forward Process: É responsável pelo processo de roteamento propriamente dito.
Faz a busca na tabela de roteamento bem como aloca buffers de recepção e envio.
• Receive Process: Responsável pelo recebimento dos pacotes. Interage com
outros processos como FP, caso o pacote recebido deva ser roteado.

2. Protocolo IP Avançado
2.1. Conceitos de Aplicações

QoS – Qualidade de Serviço
A qualidade do serviço (Quality of Service - QoS) é a capacidade de uma rede em fornecer
serviços com qualidade garantida baseando-se em métricas claramente definidas para tipos de
tráfego específicos, ou seja, uma rede com suporte a QoS é capaz de reconhecer classes de tráfego
e tratá-las diferentemente.
As redes de hoje necessitam suportar múltiplos tipos de tráfego sobre os mesmos circuitos. Os
tipos diferentes do tráfego exigem tratamentos diferentes da rede. Assim como um passageiro da
primeira classe está disposto a pagar mais pelo melhor serviço, as empresas hoje estão dispostas a
pagar um adicional pelo tratamento preferencial de seu tráfego de rede. E da mesma forma que
não podemos ter um avião separado para cada passageiro da primeira classe, nós não podemos ter
conexões de redes separadas para cada uma das empresas. Conseqüentemente, o tráfego de
"primeira classe" e o de outras classes têm que compartilhar a mesma largura de banda disponível
(como passageiros da classe econômica compartilham o avião com os passageiros da primeira
classe).

A diferenciação do tráfego somente pode ser feita nos elementos ativos da rede. Exemplos de tais
elementos são roteadores e switches.
Para definir a qualidade de serviço é preciso conhecer as métricas que, em última instância, são os
parâmetros que definem o QoS de uma determinada rede. As principais métricas são:
• Service Availability (Disponibilidade do serviço)
Confiabilidade das conexões fim-a-fim.
• Delay (Atraso)
Tempo que um pacote leva para percorrer a rede do ponto de origem ao ponto de
destino.
• Delay Jitter (Atraso irregular)
Variação no atraso encontrado pelos pacotes similares que seguem a mesma rota
através da rede. Há casos como o de tráfego de voz sobre IP, onde um atraso
constante não ocasiona problemas na conversação, porém, caso tenhamos um
atraso irregular, as sílabas soarão "emboladas" no destino. Nesse caso, o controle
dessa característica da rede é fundamental em termos de QoS para o tráfego de voz.
• Throughput (vazão)
Taxa de transmissão dos pacotes através da rede.
• Packet Loss Rate (Taxa de perda de pacotes)
Taxa que representa o número de pacotes recusados, perdidos ou corrompidos em
relação ao total de pacotes enviados na rede.
Componentes de QoS
Diversos componentes são necessários de forma a se atingir uma QoS efetiva. Observe a imagem
a seguir:

Da mesma forma que protocolos de rede e equipamentos especificamente projetados são
necessários para garantir uma determinada QoS no backbone da Embratel, o mesmo deve
acontecer com a rede do cliente.
Um conjunto específico de equipamentos e protocolos (CPE - Customer Premise Equipment, ou

equipamento nas instalações do cliente) é exigido para garantir o QoS:
• Roteador com FRF-12
Permite fragmentação em interleaving, colocando os pacotes de dados entre os de
áudio e vídeo. O FRF-12 foi desenvolvido de modo a permitir que frames de
dados muito longos sejam fragmentados em pedaços menores e intercalados
(interleaving) com frames pertencentes a transmissões em tempo real. Desta
forma, frames de voz e vídeo, sensíveis ao tempo, e de dados, não sensíveis ao
tempo, podem ser transmitidos simultaneamente em links de menor velocidade
sem causar atrasos excessivos ao tráfego em tempo real. Veja mais em
http://www.frforum.com.
• Filas CBWFQ e LLQ, proprietárias da Cisco
CBWFQ (Class-based weighted fair queueing) é uma extensão da funcionalidade
WFQ (weighted fair queueing) padrão que permite a definição de classes de
tráfego pelo usuário. É possível utilizar diversos critérios na definição dessas
classes, incluindo protocolos, listas de controle de acesso (ACLs) e interfaces de
entrada. LLQ (Low latency queueing) permite que o CBWFQ seja realizado com
base em prioridades estrita
• Marcação de pacotes com IP Precedence ou DSPC
• Utilização de CRTP
O CRTP (Compressed RTP), proprietário da Cisco, comprime o cabeçalho
IP/UDP/RTP de 40 bytes para entre 2 e 4 bytes, na maioria das vezes. Isso é
conseguido aproveitando o fato que metade das informações de um cabeçalho
normalmente não muda ao longo da transmissão e que, mesmo a parte que muda,
o faz de maneira determinística e não precisa ser transmitida. CRTP deve ser
utilizado em qualquer interface WAN onde exista uma preocupação com largura
de banda e alto tráfego de RTP.

Atenção: A fragmentação em interleaving e o uso de CRTP são primordiais para a implantação
de QoS em links de baixa velocidade.
CoS – Classe de Serviço

A classe de serviço (Class of Service - CoS) é uma maneira de controlar o tráfego em uma rede
agrupando os tipos de tráfego similares, como email, streaming de vídeo, tráfego de voz e
transferência de arquivo, e tratando cada tipo como uma classe com seu próprio nível da
prioridade do serviço. Ao contrário da qualidade de serviço (QoS), a CoS não garante um nível de
qualidade em termos das métricas analisadas no item QoS; somente oferecem um nível de serviço
na base do "melhor-esforço" (best-effort), onde o tráfego concorrente será tratado de acordo com
níveis de prioridade.
As garantias dadas por mecanismos de CoS são bastante limitadas. O CoS somente garante que os
pacotes com prioridade mais elevada tenham um melhor serviço do que pacotes com prioridade
mais baixa. Não há controle da admissão do pacote de entrada, portanto não há nenhum
mecanismo para impedir que as classes fiquem sobrecarregadas. Conseqüentemente, a qualidade
do serviço não é previsível, mas depende da quantidade de tráfego competindo pelos mesmos
recursos. É possível haver congestionamento dentro das classes, o que pode levar a delay jitter e
perda do pacote.
As classes de QoS são completamente isoladas. Tráfego de dados e tráfego real-time, por
exemplo, podem ser totalmente separados. Com isso, o tráfego de dados não causaria delay jitter
às aplicações real-time e, da mesma forma, ele não é prejudicado por uma quantidade excessiva
de tráfego real-time.
Por outro lado, com o CoS, recursos de processamento e memória não são gastos em tarefas como
gerenciamento do fluxo, scheduling do tráfego e ordenação como é feito no QoS. Assim, os
recursos exigidos aos roteadores para oferecer o CoS são inferiores aos requeridos pelo QoS.

DiffServ X IntServ
Há dois mecanismos principais de QoS em redes IP: Integrated Services (IntServ) e
Differenciated Services (DiffServ).
• IntServ
É um mecanismo baseado em reserva antecipada de recursos. Isto significa que o
IntServ reserva recursos para cada fluxo usando um protocolo dinâmico para este
fim e emprega o controle de admissão, a classificação dos pacotes e scheduling
para conseguir o QoS desejado.
• DiffServ
É um mecanismo que não trabalha com a reserva de recursos antecipada. Isto
significa que o DiffServ classifica os pacotes em um número reduzido de tipos de
serviço e usa prioridades para fornecer QoS ao tráfego. Nenhuma reserva de
recursos ou controle de admissão explícitos são utilizados, embora tenhamos que,
de alguma forma, implementar um método para diferenciar o tráfego.
Integrated Services
IntServ é um mecanismo de QoS orientado a fluxo. Um fluxo é definido como uma seqüência de
pacotes originados a partir de uma atividade específica do usuário, como, por exemplo, uma
sessão transferência de arquivo. Um fluxo pode ser identificado por uma variedade de
informações encontradas nos pacotes, como os endereços IP origem, IP de destino e o número da
porta TCP destino.
O IntServ requer que os recursos sejam reservados para cada fluxo, a fim de prover o QoS
solicitado. Isto pode ser feito através de um protocolo dinâmico de reserva de recursos (Dynamic
Reservation Protocol) ou de configuração manual. Ainda que o IntServ não esteja amarrado a

nenhum método específico, o RSVP (Resource reSerVation Protocol) é o protocolo dinâmico de
reserva de recursos comumente empregado.
Existem quatro funcionalidades básicas na implementação do IntServ, conforme descrito abaixo:

• Packet Scheduler
O scheduler de pacotes, como o nome sugere, programa a transmissão dos
pacotes colocando-os nas filas de trasmissão adequadas para transmiti-los no
momento apropriado.
• Admission Control
O controle da admissão decide se um roteador ou host concedem a um novo fluxo
o QoS solicitado, sem causar impacto nas garantias fornecidas a fluxos anteriores.
A decisão de aceitar ou rejeitar um pedido de reserva é feita com base no QoS
pedido e no QoS disponível no link de saída.
• Classifier
O classifier relaciona cada pacote de entrada a uma classe de serviço específica, a
fim de ser apropriadamente transmitido pelo scheduler. Os pacotes são
classificados baseando-se em determinadas informações contidas no cabeçalho do
pacote. Todos os pacotes que pertencem à mesma classe são tratados
similarmente. Há diversos critérios para classificação, como, por exemplo,
considerar todos os fluxos de vídeo como pertencendo à mesma classe de serviço.
• Resource reSerVation Protocol
O Resource reSerVation Protocol (RSVP) é responsável pela distribuição das
informações específicas de cada fluxo por todos os roteadores ao longo do
caminho entre origem e destino, além dos hosts localizados nas duas
extremidades da comunicação. A aplicação especifica o QoS requerido e o RSVP
utiliza esta informação para reservar os recursos ao longo de todo o caminho. O
protocolo RSVP é abordado com mais detalhes na porta Protocolos associados
deste andar.

Funcionamento do IntServ
Limitações do IntServ
O maior problema com relação ao uso do IntServ é quanto à sua escalabilidade. Em uma rede de
grande porte, a quantidade de mensagens de controle necessárias à solicitação de reserva para um
grande número de fluxos certamente exigirá um alto volume de processamento por parte dos
dispositivos de rede.
Da mesma forma, a manutenção de tabelas de estado dos fluxos em cada nó da rede demandaria
uma grande necessidade de memória. Além disso, a classificação e programação (scheduling) do
tráfego tornaria o processo de roteamento em cada dispositivo bastante complexo. A questão da
segurança também é uma preocupação, já que o IntServ carece de um mecanismo que evite o
pedido de alocação de recursos por fontes não autorizadas.
Os Differenciated Services, em função de suas características e funcionamento, conseguem

solucionar algumas das deficiências do IntServ, tornando-o mais apropriado a redes de maior porte.
Differenciated Services
Os Differenciated Services (DiffServ - DS) utilizam o conceito de domínios para modelar sua
estrutura de QoS. Um domínio de DiffServ é um conjunto contínuo de nós de rede que suportam
um mesmo método de provisionamento de recursos e políticas de QoS. O domínio tem uma
fronteira bem definida e há dois tipos de nós associados com um domínio do DS: border nodes
(nós de borda) e interior nodes (nós internos).

Os border nodes conectam um domínio DS a outros domínios. Eles classificam o tráfego de
modo que os pacotes de entrada sejam marcados apropriadamente para que recebam o tratamento
adequado dentro do domínio. Os interior nodes são conectados a outros interior nodes ou a
border nodes dentro do mesmo domínio.
Algumas definições merecem serem apresentadas, visando a melhor compreensão do mecanismo

de QoS do DiffServ:
• DiffServ CodePoint (DSCP)
O Diffserv utiliza um campo que sempre existiu no cabeçalho IP mas que até o
advento das tecnologias de QoS, na prática, não era utilizado. Estamos falando do
campo ToS (Type of Service), que é composto por 8 bits, sendo que somente 6
são usados para definir o DSCP. Na terminologia do DiffServ, ele é chamado de
DS-Field e o código especificado neste campo (DSCP) indica qual o tipo de
tratamento que o pacote receberá dos roteadores de um domínio DS.
• DS Behavior Aggregate (DSBA)
Um conjunto de pacotes com o mesmo DS Codepoint e que, portanto, devem
receber o mesmo tratamento de QoS pelos DS-Routers.
• Per Hop Behavior (PHB)
Consiste no tratamento que é dado em cada DS-Router a cada DS Behavior
Aggregate com relação a como serão repassados os pacotes, a fim de manter a
QoS requerida.
• PHB group
Um conjunto de PHBs com características comuns que recebem o mesmo
tratamento no DS-Router.

Funcionamento do DiffServ
O pacote entra no domínio DS através de um border node, responsável pela classificação e
condicionamento do mesmo. Classificar consiste em identificar o tráfego que irá receber um
serviço diferenciado baseando-se no DS Codepoint e associá-lo a um DS Behavior Aggregate.
Condicionar significa aplicar ao tráfego regras pré-acordadas e pré-definidas, como limites
máximos de vazão e condições que levam ao descarte de pacotes.
Com base no DS Codepoint, em cada interior node um determinado DS Behavior Aggregate é

mapeado para um PHB que define o tipo de serviço que será fornecido ao DS Behavior Aggregate.
Os PHBs podem ser definidos em função da prioridade de uso de recursos (como buffers e
largura de banda) em relação a outros PHBs ou nos termos das características de tráfego
requeridas, como atraso máximo e perda de pacotes suportada para um determinado DSBA. Em
síntese, os PHBs são as bases para alocação de recursos no mecanismo de DiffServ.

Comparativo das duas soluções
Terminamos o módulo que trata do IntServ mostrando as limitações deste mecanismo de QoS e
apresentaremos agora algumas das características do DiffServ que superam tais limitações.
O DiffServ não diferencia o tráfego por fluxo como é o caso do IntServ. Ao invés disso, há um
número pequeno de classes para as quais são oferecidos serviços diferenciados e essas classes, na
verdade, são agregações de diversos fluxos que solicitam o mesmo tipo de QoS.
No DiffServ não há classificação de pacotes nos interior nodes da rede. Já no IntServ/RSVP, cada
router interno executa a classificação do pacote, a fim fornecer diferentes níveis de serviço. No
DiffServ, a classificação do pacote é movida para a borda da rede, isto é, os border nodes
classificam e marcam pacotes apropriadamente e os interior nodes processam os pacotes
baseados nessas marcas.
Outra diferença importante entre as duas soluções é o fato de que o IntServ/RSVP explicitamente
reserva, de forma antecipada, os recursos ao longo do trajeto, enquanto o DiffServ não fornece
garantias prévias. O objetivo em DiffServ é monitorar o tráfego que entra na rede pelo border
node e verificar sua adequação a perfis de serviços pré-definidos com base em acordos de nível
de serviço (SLAs). Baseado nos SLAs, os pacotes podem ser marcados como estando dentro (IN)
ou fora (OUT) de seus perfis. Dentro da rede, os interior nodes descartam preferencialmente os
pacotes que são marcados como OUT.
Como o DiffServ move a classificação dos pacotes para a borda da rede, não trata fluxos
individuais e não possui controles para reserva antecipada de recursos, esta solução é mais
escalável que a IntServ, pois reduz o custo para o controle do QoS como banda passante no
interior da rede, memória e processamento nos interior nodes.

Unicast x Multicast
A transmissão de áudio e vídeo através do método convencional de comunicação direta ponto-a-
ponto, ou Unicast, sobrecarrega tanto os servidores transmissores quanto as redes por onde
passam estas aplicações. Para solucionar este tipo de problema, veremos que a trasmissão
multiponto, ou Multicast, é a opção mais apropriada.
Unicast
O IP Unicast é o método comumente usado nas típicas comunicações cliente/servidor. Neste
contexto, cada conexão usa uma parte exclusiva da banda total disponível. Isto significa que se
um servidor de streaming de áudio/vídeo como o Windows Media Server, por exemplo,
transmitisse em Unicast para 100 clientes, 100 cópias dos mesmos dados seriam enviadas na rede.
Devido à relação linear entre o número de conexões e a quantidade de banda consumida e de

consumo de CPU e memória dos hosts e roteadores envolvidos, o Unicast não é a melhor opção
para transmissões para vários hosts simultâneos tendo em vista a falta de escalabilidade.
O IP Unicast, portanto, é uma tecnologia que trabalha muito bem em comunicação ponto-a-ponto,
mas não em comunicação ponto-a-multiponto. Para esse tipo de comunicação, a transmissão em
Multicast é a forma que melhor se adequa às características deste tráfego, como veremos a seguir.
MultiCast
O princípio fundamental que permite o IP Multicast é o tratamento eficiente de comunicações
entre grupos de hosts em uma rede IP. Esta tecnologia permite o envio de uma única mensagem
(data stream) na rede e que vários hosts recebam a mesma mensagem.
Neste método, uma banda adicional não precisa ser alocada para cada nova conexão. Ao invés
disso, cada novo usuário conecta-se ao único fluxo de dados transmitido. Conseqüentemente, há

um uso muito mais eficiente da largura de banda da rede quando se trata de comunicação entre
grupos de host. Com isso, um grupo de usuários assistindo a uma transmissão de vídeo via
Internet, por exemplo, consumiria somente a banda equivalente à alocada a um único usuário em
um ambiente Unicast.
Quando falamos em IP Multicast, estamos falando de um conjunto estável e já maduro de

protocolos que, contudo, não tinham sido usados em todo seu potencial até a recente
popularização das tecnologias de banda larga para acesso à Internet. A utilização do Multicast
exige um novo conjunto de protocolos nas redes unicast existentes, como teremos a oportunidade
de apresentar ao longo deste módulo.
Quando IP Multicast necessita transpassar diferentes segmentos de rede via roteadores, três
requisitos precisam ser atendidos:
• Grupo de destinatários: A camada de rede deve conter um endereço que
represente um grupo de destinatários, ao invés de apenas um receptor. Isto é
realizado usando a faixa de endereçamento IP de classe D, e não endereços da
classe A, B ou C.
• Método de adesão: Deve haver um método para que os computadores dos clientes
associem-se ao grupo que recebe os pacotes de IP Multicast. Isto é realizado
usando-se protocolos como o IGMP, que gerenciam os grupos Multicast.
• Infra-estrutura de rede: A infra-estrutura da rede deve ter uma maneira de
comunicar as decisões de roteamento multicast. Alguns exemplos de protocolo de
roteamento multicast são o Distance Vector Multicast Routing Protocol e PIM
(Protocol Independent Multicast).
Endereçamento IP Multicast
Diferentemente da comunicação Unicast, onde cada endereço IP identifica um único host, no
Multicast um endereço IP representa um grupo ao qual os hosts podem associar-se para receber
pacotes referentes a uma mesma transmissão.

A faixa de endereços IP de classe D utilizada no Multicast compreende os valores iniciados em
224.0.0.0 até 239.255.255.255. Da mesma forma que os endereços Unicast, há endereços que
podem ser atribuídos às aplicações Multicast e os que são reservados. Vejamos alguns exemplos
de endereços Multicast e seu uso:
Os endereços da faixa de 224.0.0.0 até 224.0.0.255 são do tipo locais, isto é, não são roteados pelos
roteadores Multicast e, portanto, restritos ao uso dentro de uma mesma subrede IP. Os endereços da
faixa 224.0.1.0 à 224.0.1.255 são roteáveis e portanto podem passar através dos roteadores.
A faixa de endereços dita como endereços privativos (239.0.0.0 a 239.255.255.255) tem a função
semelhante à dos endereços privativos das classes A, B e C (10.0.0.0, 172.16.0.0 a 172.31.0.0 e
192.168.0.0), ou seja, são endereços inválidos e controlados pelo IANA, mas que podem ser
utilizados dentro da empresa para aplicações restritas.
Gerenciamento de Grupos de IP Multicast

O controle da comunicação através dos grupos Multicast funciona de forma similar a um clube.
Quando uma estação quer receber os pacotes Multicast de uma determinada aplicação, é preciso
associar-se ao grupo para que a informação seja passada pelos roteadores Multicast para a estação
de trabalho. Da mesma forma, quando não se quer mais receber as informações originadas a partir
de uma aplicação Multicast, é preciso informar o desejo de retirar-se do grupo.
O principal protocolo responsável pelo gerenciamento dos grupos Multicast é o IGMP (Internet
Group Management Protocol), atualmente em sua versão 2. Com a mesma funcionalidade, temos
também o protocolo proprietário da Cisco CGMP (Cisco Group Management Protocol).
Vejamos como são os principais processos envolvidos no gerenciamento dos grupos Multicast:
• Query Process - Os roteadores Multicast passam o tráfego Multicast destinado a
grupos somente para os segmentos de rede diretamente conectados a ele e que
tenham, pelo menos, um host nesses grupos. Para saber que hosts estão
associados a que grupos em um determinado segmento, os roteadores enviam
uma query (pergunta) para todos os hosts do segmento por meio do endereço
224.0.0.1. Os hosts que pertençam a grupos Multicast reportam ao roteador suas
informações. Desde que haja, pelo menos, um host em um determinado grupo, o
roteador enviará o tráfego referente a esse grupo para o segmento em questão.

• Joining Process - Quando um host deseja associar-se a um grupo Multicast para
receber o tráfego da aplicação que transmite para este grupo, ele envia uma
solicitação ao roteador pedindo para que o tráfego seja passado para o segmento
de rede IP onde se encontra.
• Leaving Process - Para solicitar a sua remoção de um grupo Multicast, um host

envia uma mensagem a todos os roteadores de seu segmento (endereço 224.0.0.2)
pedindo o desligamento do grupo. Neste momento, os roteadores enviam uma
query para o grupo do host que quer se desligar para saber se ainda há algum host
remanescente do mesmo grupo. Em caso afirmativo, o tráfego para este grupo
continua sendo repassado para o segmento, caso contrário, não serão enviados
pacotes, para o segmento de rede, referentes ao grupo em questão.

Virtual Private Network (VPN)
A maneira pela qual as empresas fazem seus negócios tem mudado muito nos últimos anos. Em
vez de simplesmente tratarem dos interesses locais ou regionais, as empresas agora têm que
pensar nos mercados e logística globais. As empresas globalizadas têm com freqüência suas
linhas de produção em unidades de negócios espalhadas por todo o mundo, além da mobilidade
cada vez maior de suas equipes de vendas e suporte técnico. Existe, portanto, uma necessidade
comum a este tipo de organização: uma maneira de viabilizar as comunicações da forma mais
segura e de menor custo possível entre suas unidades distribuídas geograficamente pelo mundo.
Até recentemente, as possibilidades existentes para efetuar este tipo de conexão eram o uso de
linhas dedicadas ou contratação de serviços de redes comutadas, como Frame-Relay e X.25, de
operadoras internacionais. Hoje, podemos utilizar com segurança uma rede pública que oferece
maior capilaridade e menor custo entre todas as outras soluções. Esta rede é a Internet e a
tecnologia que viabiliza esta solução com segurança é a rede privativa virtual (Virtual Private
Network - VPN).
Certamente, as soluções tradicionais ainda oferecem vantagens sobre uma rede pública, como a
Internet, quanto à confiabilidade e ao desempenho; porém, essas vantagens tendem a diminuir
com as novas tecnologias de QoS. Por outro lado, manter uma estrutura baseada em circuitos
dedicados de longa distância é muito caro, e os custos aumentam em função da distância entre os
pontos conectados.
Conceitualmente, uma VPN é uma rede privativa que utiliza uma rede pública (geralmente a
Internet) para conectar localidades e usuários remotos a redes privadas. Em vez de usar um
circuito dedicado, uma VPN utiliza conexões virtuais através da Internet, ligando a rede privada
da empresa à uma localidade remota.

Típicas ligações que usam VPN
Tipos de VPN
Acesso Remoto
Também chamada de client-to-LAN, este tipo de conexão VPN é utilizada para ligar as estações
de trabalho, tipicamente laptops ou PDAs de funcionários que necessitam se conectar à rede da
empresa quando estão em localidades remotas, como hotéis e clientes.
Neste caso, é comum a empresa terceirizar o acesso à Internet junto à uma provedora de acesso
que ofereça números locais em diversas das principais cidades do país ou do mundo, além de
números 0800 para as cidades onde números de acesso locais não estejam disponíveis.
Após a conexão discada ter sido estabelecida, o funcionário usa um cliente VPN instalado em sua
estação para estabelecer a conexão com o servidor VPN localizado na sua empresa e passa então
a ter acesso seguro aos recursos da rede corporativa.
Consultores, equipes de venda e equipes de suporte são usuários típicos deste tipo de VPN.
Site-to-Site
Também conhecida como LAN-to-LAN, este tipo de VPN é feita por meio da conexão dedicada
de escritórios remotos à Internet. São comumente utilizados dispositivos especializados na
manutenção do circuito dedicado (roteadores), além dos dispositivos com o fim específico de
tratar os processos inerentes à conexão VPN (firewalls), como autenticação e criptografia.
Neste mecanismo, após autenticação, os firewalls de ambos os lados combinam o método de

criptografia a utilizar, trocam as chaves criptográficas necessárias e estabelecem a comunicação

segura. Além disso, é também normalmente responsabilidade dos firewalls iniciar e encerrar o
encapsulamento dos dados.
Ligações entre matriz e filiais e entre a empresa com seus fornecedores são os usos mais comuns
deste modo de conexão VPN.
VPN e Criptografia
Este mecanismo envolve normalmente dois métodos de criptografia:
• Criptografia de chaves simétricas
Envolve o conhecimento de uma única chave, por ambos os lados, capaz de
criptografar e descriptografar a informação transmitida. É o método escolhido
quando a performance é o requisito fundamental.
• Criptografia de chaves públicas
Método onde as duas partes possuem duas chaves: uma privada de conhecimento
exclusivo do '"dono" da chave e uma pública que, como o nome sugere, é de
conhecimento de todos. Estas duas chaves têm a seguinte propriedade: o que é
criptografado com uma delas somente será descriptografado pela outra, isto é, o
que é criptografado com a chave privada somente pode ser descriptografado com
a chave pública e vice-versa.
Os dois métodos de criptografia são utilizados no processo de estabelecimento e troca de

informações da conexão VPN segura ,da forma descrita a seguir:
- O lado transmissor usa a chave pública do receptor para enviar a chave simétrica
que servirá para criptografar os dados a serem enviados;
- Como somente a chave privada do receptor consegue "abrir" a mensagem
criptografada com sua chave pública, a troca de chaves é feita com segurança e o
receptor fica ciente da chave para criptografar os dados;
- O transmissor passa a enviar os dados criptografados com a chave simétrica
acordada;
- O receptor decodifica as mensagens recebidas com a chave simétrica recebida.
Note que em virtude de sua melhor performance, graças ao menor consumo de recursos em
relação aos algoritmos de chave pública, os algoritmos de chave simétricas são preferenciais para
o processo de criptografia dos dados.
VPN e encapsulamento
As VPNs baseiam-se em encapsulamento de pacotes (tunneling) para criar uma rede privada
através da Internet. Essencialmente, tunneling é o processo de colocar um pacote inteiro (headers
e dados) dentro de um outro pacote e transmiti-lo na rede pública que liga as duas redes privadas.
O protocolo do pacote "externo" é compreendido pela rede pública e por ambos os pontos que
abrem e fecham a VPN, também designados de interfaces de tunelamento, onde o pacote é
inserido e retirado da rede pública. Existem três tipos de protocolos que compõem o mecanismo
de encapsulamento:

• Protocolo externo: O protocolo usado pela rede pública que conecta as
interfaces de tunelamento. No caso da Internet seria o próprio IP.
• Protocolo de encapsulamento: O protocolo utilizado para encapsular o pacote
original. Alguns exemplos são o GRE, IPSec, L2F, PPTP, L2TP, que serão vistos
com mais detalhes mais à frente, neste curso.
• Protocolo original dos dados: Os protocolos utilizados dentro da empresa que
podem ser o próprio IP, IPX ou mesmo protocolos não roteáveis como NetBEUI.
Pelo encapsulamento, é possível, por exemplo, colocar um pacote que use um protocolo não
suportado na Internet (como NetBEUI) dentro de um pacote IP e enviá-lo pela Internet.
Poderíamos também usar a faixa de endereços privativos (10.x.x.x, por exemplo) nas redes
privadas conectadas via Internet e colocar este pacote dentro de outro pacote cujos endereços IP
sejam válidos para transmissão via Internet.
2.2. Protocolos associados

Protocolo ICMP
Em uma rede de pacotes não orientada à conexão, como a Internet, diversos problemas podem
ocorrer durante a transmissão de uma mensagem. Um exemplo bastante comum ocorre quando o
host destino não está disponível (unreachable) para receber a mensagem. Outro exemplo seria
quando um roteador está com algum tipo de problema e não tem como reencaminhar o tráfego.
Em ambos os casos, uma mensagem de erro deve ser retornada ao host origem para que alguma
ação seja tomada.

No modelo Internet, o protocolo ICMP (Internet Control Message Protocol) tem como principal
função reportar à origem problemas na transmissão de uma mensagem envolvendo os roteadores
que reencaminham o datagrama e o host destino. O ICMP reside na camada de rede, juntamente
com o protocolo IP. Mensagens ICMP são encapsuladas em datagramas IP e enviadas da mesma
forma que os demais pacotes. Em função disso, mensagens ICMP podem ter os mesmos
problemas em alcançar o seu destino.
Formato de mensagem ICMP

O protocolo ICMP reporta diferentes tipos de problemas, implementando diversos tipos de
mensagens. No entanto, todas apresentam três campos:
Type
Especifica o tipo da mensagem ICMP.
Checksum
Utilizado para garantir a integridade da mensagem IGMP.
Code
Permite especificar informações adicionais sobre a mensagem ICMP.
A seguir são listados os principais tipos e uma breve explicação de algumas funcionalidades e
problemas que podem se reportados:

Tipo Descrição
0 Echo Reply
3 Destination Unreachable
4 Source Quench
5 Redirect
8 Echo Request
11 Time Exceeded on a Datagram
12 Parameter Problem on a
Datagram
13 Timestamp Request
14 Timestamp Reply
17 Address Mask Request
18 Address Mask Reply
Mensagens ICPM
As mensagens do tipo echo request e echo reply permitem testar uma conexão de rede, e são
utilizadas, por exemplo, no comando ping. O comando ping envia uma ou mais mensagens do
tipo echo request para um determinado host. O destino, por sua vez, responde utilizando uma
mensagem do tipo echo reply. Desta forma, é possível identificar problemas na rede.
C:\>ping www.embratel.com.br
Pinging www.embratel.net.br [200.255.125.213] with 32 bytes of data:
Reply from 200.255.125.213: bytes=32 time=130ms TTL=243

Ping statistics for 200.255.125.213:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 130ms, Average = 77ms

A mensagem destination unreachable indica que o roteador não pôde reencaminhar o datagrama
ou não pôde entregá-lo ao destino. Existem diversas razões para que um host esteja indisponível.
Código Descrição
0 Network unreachable
1 Host unreachable
2 Protocol unreachable
3 Port unreachable
4 Fragmentation needed and DF set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated
9 Communication with destination network prohibited
10 Communication with destination host prohibited
11 Network unreachable for type of service
12 Host unreachable for type of service
A mensagem time exceeded indica que o tempo de vida (Time-To-Live) do datagrama está
esgotado e deve ser descartado da rede pelo roteador.
A mensagem source quench permite implementar uma forma simples de controle de fluxo, onde o
destino pode solicitar à origem que reduza a sua taxa de transmissão, conseqüentemente evitando
ou reduzindo problemas de congestionamento e buffer overflow.
As mensagens timestamp request e timestamp reply permitem que um host solicite a hora do dia a
uma determinada máquina na rede. A partir destas mensagens é possível avaliar o atraso no
envio/recebimento de datagramas na rede.

IGMP
No endereçamento ponto-a-ponto, também conhecido como unicast, uma mensagem é
endereçada para um único host destino. Se for necessário enviar uma mesma mensagem para
diversos hosts, serão enviadas tantas mensagens quanto for o número de hosts. Nesse caso, o host
origem deverá enviar várias mensagens idênticas, consumindo seus recursos computacionais.
Além disso, a rede de interconexão deverá transportar as mesmas mensagens para os diversos
hosts destino, consumindo banda da rede.
O endereçamento multicast ou IP multicast permite que uma mesma mensagem seja enviada uma
única vez e diversos hosts possam recebê-la. Um bom exemplo de aplicação que se beneficia com
o endereçamento multicast pode ser observado em uma vídeo-conferência, onde vários
participantes devem receber as mesmas imagens. Em um ambiente unicast, para cada participante
da vídeo-conferência deve ser enviada a mesma mensagem.
A comunicação multicast é implementada através de grupos multicast. Um grupo multicast é

formado por hosts que possuem o mesmo endereço multicast. Os endereços multicast são
formados pelos endereços classe D, que estão no intervalo de 224.0.0.0 a 239.255.255.255. Cada
grupo possui um único endereço multicast.
Para receber as mensagens de um determinado grupo multicast, um host deve solicitar sua
inclusão no grupo. Da mesma forma, quando um host não deseja mais receber tais mensagens, ele
deve solicitar sua saída do grupo. Para que um host envie mensagens multicast não é necessário
que ele faça parte de nenhum grupo multicast.
Formato da mensagem IGMP

O protocolo IGMP (Internet Group Management Protocol) faz parte da camada de rede do
modelo Internet, juntamente com o protocolo IP. Mensagens IGMP são encapsuladas em
datagramas IP e enviadas da mesma forma que os demais pacotes. Em função disso, mensagens

IGMP podem não alcançar seu destino. Na nova versão do protocolo IP (IPv6), o IGMP foi
incorporado ao ICMP, ou seja, o ICMPv6 inclui as funções dos protocolos ICMPv4 e IGMPv4.
A função do protocolo IGMP é permitir a troca de informações multicast entre hosts e roteadores
multicast, responsáveis por implementar a comunicação multicasting. Por exemplo, sempre que
um host deseja tornar-se membro de um grupo multicast, ele deverá enviar uma mensagem IGMP
especificando o endereço multicast do grupo desejado. O protocolo permite que os roteadores
multicast identifiquem quais grupos continuam ativos, enviando periodicamente uma mensagem
IGMP para todos os hosts de um determinado grupo. Os hosts que desejarem permanecer no
grupo devem responder, utilizando uma mensagem IGMP.
Uma mensagem IGMP possui os seguintes campos:
Version: versão do produto.

Type: Especifica o tipo da mensagem IGMP.
Tipo 0: Identifica uma resposta enviada por um host.
Tipo 1: Identifica uma solicitação enviada por um roterador multicast.
Checksum: Utilizado para garantir a integridade da mensagem IGMP.
Group Address: Identifica o endereço de um grupo multicast (classe D).
Protocolo RSVP
O protocolo RSVP (Resource reSerVation Protocol) tem a função de garantir a QoS (Quality of
Service) em redes do tipo Integrated Services (IntServ), como a Internet, implementando o
esquema de pré-alocação de recursos para um determinado fluxo de dados (data flow) unicast ou
multicast.
Antes de estabelecer uma conexão, a aplicação especifica os parâmetros necessários para garantir
a QoS desejada. Os roteadores responsáveis pelo encaminhamento das mensagens verificam a
possibilidade de oferecer essa QoS. Se for possível, os recursos necessários são reservados e a
conexão pode ser estabelecida. Caso contrário, informa-se à aplicação que a QoS desejada não
pode ser atendida. Nesse caso, a aplicação pode baixar seu nível de exigência ou decidir tentar
uma nova conexão posteriormente.

O RSVP não é um protocolo de roteamento, apesar de estar na camada de rede do modelo
Internet. O RSVP trabalha juntamente com os protocolos de roteamento, como OSPF, de forma a
permitir que os requisitos de QoS sejam mantidos dinamicamente, embora haja possíveis
mudanças de tráfego e rotas. Isto é possível devido ao conceito de soft state, que é o conjunto de
informações de estado mantido nos roteadores e atualizado periodicamente pelo RSVP para
garantir a QoS. Esta é uma grande diferença em relação aos protocolos ATM e Frame Relay, que
oferecem serviços orientados à conexão com base no conceito de hard state.
De forma simplificada, o RSVP estabelece o caminho dos dados entre origem/destino (data path)
e a pré-alocação de recursos em duas etapas. Inicialmente, o transmissor informa, através de uma
mensagem (PATH), o tipo de dado que será enviado (data flow). Essa mensagem percorrerá todo
o caminho até o host destino (downstream), passando a ser conhecida por todos os dispositivos
que fazem parte do data path. O host destino, depois de receber a mensagem PATH, solicita a
reserva dos recursos necessários através de uma outra mensagem (RESV). A mensagem RESV
irá percorrer o mesmo caminho que a mensagem PATH, mas no sentido contrário (upstream).
Após esse processo, o soft state criado em cada dispositivo no data path deve ser mantido por
mensagens periódicas PATH e RESV.
A seguir, são apresentadas as principais características do protocolo RSVP:

- Pode ser utilizado tanto para conexões unicast, quanto multicast;
- A reserva é feita em uma única direção, ou seja, uma transmissão bidirecional
necessita de duas reservas individuais;
- O host origem define as características do data flow e inicia o data path;
- O host destino inicializa e mantém a reserva dos recursos, permitindo que em
transmissões multicast cada host possa especificar níveis de QoS diferentes;
- Utiliza o esquema de agregação de mensagens para reduzir o tráfego na rede;

- É possível conviver na mesma rede roteadores que implementam RSVP e outros
que utilizem apenas o esquema de best-effort;
- Suporta tanto IPv4, quanto IPv6.
Formato da mensagem RSVP

O RSVP é um protocolo de sinalização, ou seja, não transporta dados, apenas mensagens de
controle. As mensagens RSVP são encapsuladas diretamente em datagramas IP e consistem em
um header comum de tamanho fixo, seguido por um ou mais objetos de tamanho variável.
Version: Especifica a versão do protocolo (1).

Flags: Reservado.
Msg Type: Especifica o tipo da mensagem RSVP, que pode ser:
Tipo 1 – Path: Mensagem enviada da origem para destino para criar o caminho de dados.
Tipo 2 – Resv: Mensagem enviada do destino para a origem para a reserva de recursos.
Tipo 3 – PathErr: Reporta erros na criação do caminho de dados.
Tipo 4 – ResvErr: Reporta erros na reserva de recursos.
Tipo 5 – PathTear: Solicita explicitamente a desalocação do caminho.
Tipo 6 – ResvTear: Solicita explicitamente a desalocação dos recursos.
Tipo 7 – ResvConf: Indica êxito na reserva dos recursos.
RSVP Checksum: Utilizado para garantir a integridade da mensagem.
Send_TTL: Time-to-live do pacote IP em que a mensagem RSVP foi enviada.
RSVP Length: Tamanho da mensagem, incluindo o header e os objetos.
Cada objeto é formado por um header de 32 bits e uma seqüência variável que define as
características do objeto.
Length: Tamanho, em bytes, do objeto.

Class-Num: Identifica a classe do objeto.
C-Type: Identifica o tipo de objeto dentro de sua classe.

2.3. Comutação IP
MPLS
MPLS significa Multiprotocol Label Switching. O termo multiprotocol é proveniente do fato de
que este protocolo foi projetado para funcionar em conjunto com os diversos protocolos das
camadas 2 e 3 do modelo OSI. Na prática, o que vemos hoje em relação à implementação do
MPLS é seu uso em redes onde a camada 3 é ocupada pelo protocolo IP. Quanto ao termo label
switching ou comutação baseada em rótulos, vamos utilizar uma analogia bastante específica para
explicar o controle de tráfego baseado em labels: o sistema de correios.
Imagine que sua empresa tenha contratado três tipos de serviço junto à ECT: serviço regular,
Sedex e Sedex 10. O primeiro não possui qualquer garantia quanto ao prazo de entrega, sendo
tratado pelos correios na base do melhor prazo possível. O segundo serviço tem a entrega
garantida no prazo de 24 horas e, por fim, o terceiro serviço contratado tem a garantia de ser
entregue até as 10 hs da manhã do dia seguinte.
Certamente o custo das soluções com garantia de entrega é maior em relação ao serviço regular e,
entre esses, maior custo para o que oferece rapidez superior. No exemplo, o Sedex 10 é o mais
caro entre todos. Com isso, uma empresa não vai enviar toda a sua correspondência pela via mais
cara, apenas aquela sensível ao prazo de entrega.
Como os postos de triagem da ECT identificam as correspondências que deverão tomar o

caminho expresso ou o caminho regular? Com base em rótulos nos envelopes no momento da
postagem, ou seja, no momento em que entraram na rede dos correios. O MPLS funciona de
forma bastante similar. Vejamos como.
Quando um pacote de dados entra na rede MPLS, ele recebe um rótulo indicando o tratamento em
relação à qualidade de serviço que será dado ao mesmo. Com base neste rótulo, o pacote tomará o
caminho já previamente estabelecido que atende aos requisitos exigidos para os pacotes daquele
tipo. Portanto, em cada switch MPLS (similar aos postos de distribuição da ECT), será analisado
o rótulo do pacote e decidido em qual circuito de saída será colocado o pacote.
Componentes da Arquitetura MPLS

Visto o MPLS em linhas gerais, vamos agora ao detalhamento técnico do seu funcionamento.

Label Edge Router (LER)
São os roteadores localizados de forma lógica na borda da rede MPLS, responsáveis pela
inserção e retirada dos labels, mapeamento dos protocolos de camada 2 e 3 para o MPLS,
classificação do tráfego e decisão de quais pacotes farão parte da rede MPLS e de quais
serão roteados dentro da estrutura tradicional.
Label Switch Router (LSR)

Responsáveis pela comutação dos pacotes dentro do perímetro da rede MPLS. Baseiam-
se nos labels inseridos pelos LERs para efetuar esta função.
Label Information Base (LIB)

Tabela usada pelos LSRs que contém as instruções que relacionam o circuito de saída de
um pacote com o label encontrado no mesmo. Informa, ainda, qual o novo label que o
pacote receberá antes de ser colocado no próximo trecho do caminho.
Label Switch Path (LSP)

O caminho estabelecido desde a entrada até a saída da rede MPLS para cada tipo de
tráfego considerando os requisitos de qualidade de serviço.
Forwarding Equivalence Class (FEC)

É o fluxo de dados classificado pelo LER ao qual um label será associado. Podem ser
usados como subsídios para a classificação do tráfego de informações em pacotes
associados a um mesmo AS, originados em um mesmo prefixo CIDR ou mesmo com
campo TOS similar definido pelo DiffServ.
Label Distribution Protocol (LDP)

Protocolo usado com a finalidade de distribuir os labels entre os LSRs e com isso garantir
que todos os LSRs possam tomar as decisões de comutação baseadas nos labels, traçando
o caminho fim-a-fim (LSPs).
Funcionamento do MPLS
O MPLS trabalha com a idéia de fluxo de dados. Um fluxo de dados consiste no tráfego fim-a-
fim identificado e classificado, eventualmente requerendo uma mesma qualidade de serviço

(QoS). No mundo do MPLS, esse fluxo é denominado Forwarding Equivalence Class ou
simplesmente FEC.
Ao entrar na rede MPLS, o LER classifica o pacote como membro de um determinado FEC. Caso
este seja o primeiro pacote do fluxo, protocolos de roteamento modificados com extensões que
permitem atender às especificidades do MPLS, como BGP com Traffic Engineering (BGP-TE) ou
OSPF-TE, determinam a rota que todos os pacotes subseqüentes do mesmo fluxo deverão seguir.
Após determinar a rota do FEC, o LER insere o mesmo label em cada pacote do fluxo. Ele
consiste em um segmento de 32 bits, sendo que 20 bits destinados ao identificador do label
propriamente dito e 12 bits contendo informações de controle. O label é inserido entre o
cabeçalho da camada de enlace e o da camada de rede, como mostra a figura a seguir. O label tem
significância local, ou seja, ele somente faz sentido para os LSRs adjacentes, que são aqueles que
compartilham o mesmo link.
A fim de garantir que o fluxo (FEC) tenha as mesmas características fim a fim, o MPLS usa um
protocolo de distribuição de labels (Label Distribution Protocol ou LDP) para fazer a distribuição
dos labels nos quais os LSRs baseiam-se para direcionar o tráfego para o caminho especificado
para cada FEC. É também através deste mecanismo que se torna possível garantir a qualidade de
serviço (QoS) desde o início até o fim de um dado percurso de rede.
Após o LDP ter sido executado em cada LSR do caminho e, portanto, os labels terem sido
devidamente distribuídos, um caminho fim-a-fim é criado desde o LER de entrada até o LER de
saída. Tal caminho é definido como Label Switch Path ou simplesmente LSP e é por onde todos
os pacotes do mesmo FEC devem passar. Da mesma forma que na entrada da rede MPLS o LER
insere o label no pacote de entrada (procedimento denominado PUSH), o LER de saída retira o
label do pacote retornando o mesmo à sua forma original (procedimento chamado POP).
Graças ao uso dos labels, o MPLS calcula a rota apenas uma vez para cada fluxo na entrada da
rede. Todas as decisões de roteamento feitas dentro da rede pelos LSRs são baseadas nos labels,
não sendo necessário o cálculo de rotas em cada nó. Desta forma, o tempo necessário à análise do
caminho por onde deve seguir cada pacote de um mesmo fluxo é reduzido.

Exemplo prático passo-a-passo
2.4. Segurança IP
IPSec
O IP Security (IPSec) é parte integrante do novo protocolo IP, conhecido como IPv6, que irá
substituir a atual versão IPv4. O IPSec é um conjunto de padrões abertos desenvolvidos pelo
IETF (Internet Engineering Task Force) que envolve diversos protocolos e algoritmos. Ao
contrário dos protocolos de segurança que atuam nas camadas de enlace e aplicação, o IPSec
trabalha na camada de rede, oferecendo autenticidade, integridade e confidencialidade em redes
públicas, como a Internet.
O IPSec pode ser utilizado em diversas soluções para a conexão segura de redes, como a ligação
de filiais à matriz, conexão de usuários remotos às aplicações internas da empresa e criação de
extranets e intranets. A utilização da rede pública para trafegar dados de forma segura gera uma
grande economia, pois não há necessidade de ligações privadas.

O IPSec é implementado como uma extensão do header IPv6, por meio de dois headers
adicionais: Authentication Header (AH) e Encapsulation Security Payload Header (ESP), que
serão apresentados nos próximos itens. Ele também pode ser utilizado em redes.
Os headers AH e ESP permitem dois tipos de utilização: modo de transporte e modo de

tunelamento. O modo de transporte oferece segurança apenas para as camadas acima da camada
de rede, ou seja, transporte e aplicação, sendo utilizado tipicamente para comunicação fim-a-fim
entre dois hosts.
O modo de tunelamento oferece proteção integral para o pacote IP, incluindo o seu header. Nesse
caso, o pacote IP original pode ser totalmente criptografado e encapsulado dentro de outro pacote

IP, criando a idéia de túnel. Geralmente, este modo é implementado ligando duas redes através de
roteadores e/ou firewalls. Os hosts pertencentes a redes diferentes podem comunicar-se de forma
segura sem implementarem IPSec.
Um conceito muito importante no IPSec é o de Security Association (SA), pois é utilizado pelos
headers AH e ESP. Um SA é uma relação entre origem e destino que permite identificar
unicamente uma conexão e implementar a sua segurança. Um SA é formado por três campos:
• Security Parameters Index (SPI) - Funciona como um identificador da SA e
aparece em ambos os headers;
• IP Destination Address - Endereço IP do destinatário;
• Security Protocol Identifier - Indica se o SA está associado ao header do tipo
AH ou ESP.
A criação e gerência dos SAs é função do protocolo IKE (Internet Key Exchange). O IKE
também tem a função de gerenciamento e troca de chaves criptográficas.
Protocolo AHIP
Authentication Header
O Authentication Header (AH) oferece os serviços de autenticidade e integridade de pacotes IPv4
e IPv6, mas não oferece confidencialidade (criptografia). Desta forma, é possível autenticar o
sistema que está enviando a mensagem e evitar, assim, ataques do tipo spoofing. Além disso,
também permite evitar ataques do tipo replay.
O AH utiliza, atualmente, quatro algoritmos para a implementação da autenticação do pacote:

Message Digest 5 (MD-5), Secure Hashing Algorithm (SHA), Hashed Message Authentication
Code MD-5 (HMAC-MD5) e HMAC-SHA
A seguir, são apresentados os campos do header do protocolo AH:

Next Header: Identifica o header seguinte ao AH.
Payload Length: Tamanho do AH.
Security Parameters Index (SPI): Identifica um security association (SA).
Sequence Number: Utilizado no mecanismo para evitar ataques do tipo replay.
Authentication Data: Utilizado no mecanismo de autenticação do pacote.
O esquema de autenticação implementado pelo AH pode ser empregado nos modos de transporte
ou tunelamento. A seguir, são apresentados os formatos dos pacotes IPv4 e IPv6 nos dois modos:

Protocolo ESP IP
Encapsulating Security Payload

O Encapsulating Security Payload (ESP) permite implementar a confidencialidade (criptografia)
de pacotes IPv4 e IPv6, não oferecida pelo protocolo Authentication Header (AH). Além disso, é
possível também implementar a autenticidade do pacote.
O ESP pode utilizar diversos algoritmos para a implementação da criptografia, no entanto, o

DES-CBC (Data Encryption Standard-Cipher Block Chaining) e o 3DES-CBC são os algoritmos
mais comuns.
O formato do header ESP não é igual ao AH, pois o payload fica dentro do header, criando a idéia
de trailer. A seguir, são apresentados os campos do header/trailer do protocolo ESP.
Security Parameters Index (SPI): Identifica um security association (SA).

Sequence Number: Utilizado no mecanismo para evitar ataques do tipo replay.
Payload: Dado sendo efetivamente criptografado.
Padding: O campo possui diversas funções, como, por exemplo, garantir o alinhamento do campo Next
Header dentro do trailer.
Pad Length: Tamanho do campo Padding.
Next Header: Identifica o header seguinte ao ESP.
Authentication Data: Utilizado, opcionalmente, no mecanismo de autenticação do pacote, podendo ser
implementado utilizando os mesmos algoritmos do protocolo AH.
O esquema de ciframento e/ou autenticação implementado pelo ESP pode ser empregado nos
modos de transporte ou tunelamento. A seguir, são apresentados os fomatos dos pacotes IPv4 e
IPv6 nos dois modos:

2.5. Tunelamento
GRE
O protocolo GRE (Generic Routing Encapsulating) é uma solução genérica para encapsulamento
e roteamento de pacotes, também chamados payloads. O payload é encapsulado em um pacote
GRE, que pode ser encapsulado em algum outro protocolo e reencaminhado, formando o túnel.

GRP
O payload pode ser IPX, AppleTalk, DECnet Phase IV, XNS, VINES ou o próprio IP. Na
Internet, o pacote GRE é encapsulado em um datagrama IP. Por exemplo, suponha a conexão de
duas redes SPX/IPX através de uma rede IP. Primeiramente, o pacote IPX é encapsulado em um
pacote GRE que, por sua vez, é encapsulado em um pacote IP. O pacote IP é roteado até o seu
destino, desencapsulado para obter-se o pacote GRE e novamente desencapsulado para obter-se o
payload a ser entregue à rede IPX.
O GRE é normalmente implementado nos roteadores, sendo uma solução de fácil implementação,
baixo custo e bom desempenho. Túneis GRE são compulsórios, ou seja, são estabelecidos
manualmente ligando dois pontos pré-definidos, geralmente LANs. O GRE não implementa
criptografia, porém pode-se utilizar o protocolo IPSec para oferecer um túnel criptografado.
O header do pacote GRE possui alguns campos. Os mais importantes estão detalhados a seguir:

Checksum (C) Present (bit 0): Indica se o campo de Checksum está presente e contém uma informação
válida.
Routing (R) Present (bit 1): Indica se o campo de Routing está presente e contém informação válida.
Key Present (K) (bit 2): Indica se o campo Key está presente.
Sequence (S) Number Present (bit 3): Indica se o campo Sequence Number está presente.
Recursion Control (bits 5-7): Define o número máximo de encapsulamentos permitidos.
Version Number (bits 13-15): Normalmente igual a zero.
Protocol Type (2 octets): Define o tipo de payload que está sendo encapsulado.
Checksum (2 octets): Contém o Checksum do header GRE e do payload.
Offset (2 octets): Permite identificar o tamanho da parte variável do header.
Key (4 octets): Utilizado como forma de autenticação do transmissor.
Sequence Number (4 octets): Permite ao receptor seqüenciar os pacotes recebidos.
Routing (variable): Lista de SREs (Source Route Entries) que permite definir questões sobre o
roteamento do pacote.
L2F
O protocolo L2F (Layer 2 Forwarding) foi desenvolvido pela Cisco Systems e implementa o
conceito de tunelamento na camada de enlace (nível 2). O L2F está em desuso, pois está sendo
substituído pelo protocolo Internet L2TP.
O L2F pode trafegar em diversos tipos de redes, como IP, X.25, Frame Relay e ATM
(Asynchronous Transfer Mode). Além disso, permite encapsular diferentes tipos de protocolos,
como SNA, IPX/SPX, NetBEUI e o próprio TCP/IP. A autenticação de usuários L2F pode ser
feita pelos mesmos protocolos disponíveis no protocolo PPP, além de suporte para TACACS+ e
RADIUS.

O formato do pacote L2F é semelhante ao do protocolo GRE. A seguir, é apresentado o formato
do L2F e com descrição de seus principais campos:
Packet (P) priority: Se o bit P estiver definido, indica que o pacote é prioritário e deve ser processado
antes daqueles sem bit definido.
Ver: O campo indica a versão do protocolo (001).
Sequence: Este campo está presente se o bit S estiver definido e permite ao receptor seqüenciar os
pacotes recebidos.
Multiplex ID (MID): Permite identificar uma conexão dentro do túnel.
Cliente ID (CLID): Permite auxiliar na demultiplexação de túneis.
Length: Indica o tamanho total do pacote, incluindo o header, todos os campos e o payload.
Payload Offset: Este campo está presente se o bit F estiver definido e indica onde o payload se inicia
dentro do pacote.
Key: Este campo está presente se o bit K estiver definido e é utilizado como mecanismo de autenticação,
funcionando como chave para evitar ataques do tipo spoofing.
Checksum: Checksum do pacote, incluindo header e payload.
PPTP
O protocolo PPTP (Point-to-Point Tunneling Protocol) foi proposto por um grupo de empresas,
incluindo a Microsoft, que adotou este protocolo como solução para VPNs nos seus sistemas
operacionais Windows. Apesar disso, o PPTP não é um protocolo proprietário, sendo uma
extensão do protocolo PPP (Point-to-Point Protocol) utilizado amplamente em conexões discadas
na Internet.
Um pacote PPTP utiliza o conceito de tunneling, encapsulando o frame PPP dentro de um

datagrama IP, utilizado para ligar as duas pontas de uma conexão PPTP. Por esse motivo, o PPTP
não pode ser utilizado em redes X.25, Frame Relay ou ATM. Ele não possui um header próprio,
pois utiliza uma versão modificada do protocolo GRE (Generic Routing Encapsulation),
permitindo a conexão de outros tipos de redes (como SNA, IPX/SPX e NetBEUI) além do
próprio TCP/IP. O header PPP implementa a segurança do túnel PPTP, oferecendo autenticação,
criptografia e compressão. A área de dados do PPP (payload) encapsula os protocolos originais e
os dados da aplicação.

O PPTP pode ser utilizado para criar VPNs (1) interligando LANs e (2) interligando usuários
remotos à LAN. No segundo caso, as conexões discadas podem ser de dois tipos: com suporte do
provedor e sem o seu suporte. Quando o provedor oferece suporte ao PPTP no servidor de acesso
remoto (NAS - Network Access Server), o usuário é autenticado no próprio provedor. Nesse caso,
o usuário precisa apenas do protocolo PPP, pois o NAS cria o túnel com o servidor PPTP. No
entanto, a conexão entre o usuário e provedor não é criptografada (2a). Caso o provedor não
ofereça suporte ao PPTP, o próprio cliente deverá criar o túnel com o servidor PPTP (2b).
PPTP interligando LANs
PPTP interligando usuários remotos e uma LAN
A autenticação de usuários remotos PPTP pode ser implementada utilizando os protocolos CHAP
(Challenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake
Authentication Protocol), PAP (Password Authentication Protocol) e EAP (Extensible
Authentication Protocol). A criptografia é implementada utilizando o protocolo MPPE (Microsoft
Point-to-Point Encryption), que é baseado no algoritmo simétrico RSA RC4 e pode trabalhar com
chaves criptográficas de 40, 56 e 128 bits.

L2TP
O protocolo L2TP (Layer 2 Tunneling Protocol) é uma combinação dos protocolos PPTP e L2F
(Layer 2 Forwarding), este último desenvolvido pela Cisco Systems. O L2TP deverá tornar-se o
padrão Internet para tunelamento na camada de enlace (nível 2) e o IPSec, padrão para camada de
rede.
Um pacote L2TP também utiliza o conceito de tunneling, encapsulando o frame PPP dentro de
um datagrama UDP/IP. Apesar disso, o L2TP pode trafegar também em outros tipos de redes,
como X.25, Frame Relay e ATM. O L2TP possui um header próprio, herdado do protocolo L2F.
O header PPP permite implementar a segurança da conexão L2TP, porém, existem formas
alternativas de implementar autenticação e criptografia. A área de dados do PPP (payload)
encapsula os protocolos originais e os dados da aplicação.
A autenticação de usuários L2TP pode ser feita pelos mesmos protocolos disponíveis no
protocolo PPP, como CHAP, MS-CHAP, PAP e EAP, além de outros mecanismos de
autenticação (como RADIUS). Também é possível implementar a autenticação de computadores
utilizando o IPSec. Em geral, a criptografia é implementada utilizando o protocolo IPSec a partir

do algoritmo DES e 3DES. A figura abaixo mostra um pacote L2TP encapsulado em uma
estrutura IPSec.
O L2TP utiliza o mesmo formato de header para mensagens de dados e controle. A seguir, é
apresentado o formato do protocolo e seus principais campos. Os campos marcados com um x
estão reservados para uso futuro.
Type (T) bit: Indica o tipo da mensagem, ou seja, dado (0) ou controle (1).
Length (L) bit: Indica se o campo Length está presente.
Sequence (S) bit: Indica que os campos Ns e Nr estão presentes.
Offset (O) bit: Indica que os campos de Offset estão presentes.
Priority (P) bit: Indica que o pacote é prioritário e deve receber um tratamento especial.
Ver: Indica a versão do protocolo L2TP (2).
Length: Indica o tamanho total do frame.
Tunnel ID: Permite identificar o túnel para o controle da conexão.
Session ID: Permite identificar uma conexão dentro do túnel.
Ns e Nr: Permitem ao receptor seqüenciar os pacotes recebidos.
Offset Size: Permite identificar onde inicia o payload dentro do pacote.

3. O transporte e a sessão
3.1. Protocolo TCP

O protocolo TCP (Transmission Control Protocol), juntamente com o IP (Internet Protocol), são
considerados os dois protocolos mais importantes da arquitetura Internet. O protocolo IP
encontra-se na camada de rede e está preocupado com o endereçamento do pacote e seu
reencaminhamento entre os roteadores.
O IP não tem uma preocupação com a entrega dos pacotes no destino, além de não garantir a
seqüência na qual os pacotes são entregues. Por isso, ele é definido como sendo um serviço não
orientado à conexão, também conhecido como datagrama não-confiável.
O protocolo TCP fica na camada de transporte e se preocupa em oferecer um serviço orientado à

conexão, também conhecido como circuito virtual. Neste caso, a camada de transporte garante a
entrega e a seqüência dos pacotes enviados ao destino. Sua principal função é criar uma conexão
lógica confiável, livre de erros, entre o host transmissor e o receptor. Para aplicação no host
transmissor, é como se existisse uma ligação física com a aplicação no host destino, que
desconhece a rede de interconexão e seus problemas. Esse conceito é conhecido como
comunicação fim-a-fim.
Todas as conexões TCP são full-duplex, ou seja, a comunicação pode acontecer nos dois sentidos
simultaneamente. As conexões são ponto-a-ponto, o que significa que o TCP não suporta
endereçamento broadcast ou multicast. Por oferecer um serviço orientado à conexão, o TCP é um
protocolo complexo que implementa diversos mecanismos de controle. A seguir, veremos os mais
importantes.

Início e término de conexão lógica
Para que duas aplicações comuniquem-se utilizando a rede, é necessário que seja estabelecida
primeiramente uma conexão lógica entre a aplicação origem e destino. O TCP utiliza para iniciar
uma conexão o mecanismo chamado three-way handshake. Quando um host deseja estabelecer
uma conexão com outra estação, a origem envia um segmento com o bit SYN ligado. Ao receber
a mensagem, o destino responde com um segmento com os bits SYN e ACK ligados. Por fim, a
origem confirma para o destino que a conexão foi estabelecida.
Início e término de conexão lógica
Como o TCP implementa comunicação full-duplex para encerrar uma conexão, tanto a origem
quanto o destino devem solicitar o seu término. O pedido de fim de conexão é implementado
através do bit FIN no segmento TCP, que indica que não há mais dados a serem transmitidos.
Depois do reconhecimento do pedido de término de conexão, a comunicação pode ser encerrada.
Endereçamento de transporte
Além do endereçamento IP, implementado pela camada de rede, a camada de transporte também
utiliza um esquema de endereçamento, conhecido como portas TCP. Para compreendermos a
necessidade de endereços de transporte, vejamos dois exemplos práticos.
Suponha um servidor que ofereça diferentes tipos de serviços, como Web, mail e transferência de
arquivos. Como o servidor tem apenas um único IP, como seria possível diferenciar os vários
serviços de rede oferecidos? No lado do cliente, o usuário abre diversas conexões Web diferentes
utilizando o browser. Como o cliente tem apenas um IP, como seria possível para o servidor
diferenciar para qual dos browsers a resposta deveria ser enviada?
Em ambos os casos, as portas TCP são utilizadas como mecanismo para a criação de conexões
lógicas únicas que diferenciam as aplicações dentro de um mesmo endereço IP. A combinação de
um endereço IP e uma porta forma o que é chamado de socket. Uma conexão lógica é formada
por um par de sockets: um na origem e outro no destino.

A grande maioria dos sistemas operacionais oferece suporte à criação e utilização de sockets,
através de system calls e APIs (Application Program Interfaces), o que torna o desenvolvimento
de aplicações em rede bastante simplificado.
As portas TCP são números de 16 bits que variam entre 0 e 65.535. Por questões de
padronização, as portas abaixo de 1.024 são reservadas para serviços pré-definidos (well-known
ports), como apresentado na tabela a seguir. No primeiro exemplo, o servidor utilizaria uma porta
pré-definida para cada serviço oferecido. Nesse caso, utilizaria as portas 80 (Web), 25 (correio
eletrônico) e 20/21 (transferência de arquivos).
Serviço Porta
Transferência de arquivos (FTP) 20 e 21
Telnet 23
Correio eletrônico (SMTP) 25
Serviços de nomes (DNS) 53
Web (HTTP) 80
Correio eletrônico (POP) 110
As portas acima de 1.023 são portas que podem ser utilizadas dinamicamente, conforme a
necessidade das aplicações. No segundo exemplo, a cada conexão aberta pelo browser seria
associado um socket diferente, contendo o mesmo IP, porém com portas diferentes.

É possível que os clientes tenham acesso a uma aplicação sem ter o conhecimento da porta na
qual o serviço está sendo oferecido. Nesse caso, o cliente deve conhecer, pelo menos, o nome da
aplicação e solicitar o número da porta correspondente ao nome do serviço.
Controle de erro fim-a-fim

Como já sabemos, a camada de rede oferece um serviço não orientado à conexão através do
protocolo IP. É responsabilidade da camada de transporte, mais especificamente do protocolo
TCP, garantir a entrega e a seqüência correta dos datagramas. Para implementar esse serviço, o
TCP utiliza a técnica de reconhecimento com retransmissão.
De forma simplificada, sempre que o host origem envia uma mensagem, o host destino deve
informar através de um reconhecimento (ACK) que recebeu a mensagem.
Como não existe a garantia de que a mensagem alcançará o destino, o host origem ao enviar a
mensagem, também inicializa um temporizador. Caso um ACK não chegue no tempo previsto, a
origem retransmite a mensagem.

Na situação anterior, pode ocorrer a duplicação de uma mensagem no destino, caso a mensagem
tenha sido corretamente recebida pelo destinatário. No entanto, o ACK enviado pode não alcançar
a origem por algum problema. Nesse caso, o receptor deve reconhecer o problema e descartar as
mensagens repetidas. Para isso, cada mensagem deve ser numerada de forma a permitir sua
identificação.
Se o esquema adotado pelo TCP fosse exatamente como descrito, haveria um grande desperdício
da capacidade de transmissão da rede, pois, para cada mensagem enviada, um ACK deveria ser
retornado. Na verdade, o TCP utiliza a técnica de reconhecimento cumulativo para implementar o
controle de erro de forma eficiente. Nessa técnica, o transmissor pode enviar várias mensagens
sem aguardar um ACK individual para cada mensagem. O host destino pode receber um certo
número de mensagens e reconhecer apenas a última recebida. Dessa forma, é possível reconhecer
um conjunto de mensagens, evitando o ACK individual para cada mensagem.
Para implementar a técnica de reconhecimento cumulativo, o TCP utiliza o mecanismo de sliding

window. O sliding window implementa o conceito de janelas deslizantes, sendo que a origem
possui uma janela de envio e o destino uma janela de recepção. A janela de envio desliza
conforme os ACKs do destino são recebidos, sendo que o número máximo de mensagens que
podem ser enviadas sem reconhecimento dependerá do tamanho da janela de recepção. A janela
de recepção permite receber várias mensagens, armazená-las e reconhecer apenas a última

mensagem recebida. Por exemplo, se o tamanho da janela de recepção for igual a quatro, o host
origem poderá transmitir até quatro mensagens sem receber ACKs.
A animação ao lado apresenta uma seqüência de mensagens, uma janela de transmissão de quatro
posições e três ponteiros que permitem o controle da envio e reconhecimento das mensagens. O
intervalo em amarelo indica as mensagens que já foram transmitidas e reconhecidas. O intervalo
em azul indica as mensagens transmitidas, mas ainda não reconhecidas. O intervalo em verde
indica as mensagens que podem ainda ser transmitidas, sem a necessidade de recebimento de
qualquer ACK do destino. As demais mensagens no intervalo vermelho apenas poderão ser
transmitidas quando houver o deslocamento da janela.
Para cada conexão TCP existem quatro janelas. Como a conexão é full-duplex, existe uma janela
de transmissão e uma janela de recepção para cada sentido da comunicação.
Controle de fluxo fim-a-fim

O controle de fluxo é a capacidade do host receptor avisar ao host transmissor sobre sua
capacidade de recebimento de mensagens, a fim de evitar o problema de overflow. O problema de
overflow ocorre quando o buffer do host destino fica cheio e novas mensagens continuam
chegando. Nesse caso, o host destino deve descartar todas as mensagens recebidas enquanto o seu
buffer não tiver espaço disponível. Conseqüentemente, o host origem deverá retransmitir todas as
mensagens descartadas pelo destino.
Esse problema também é resolvido utilizando o esquema de sliding window, sendo que o tamanho
da janela varia em função do tempo. Nesse caso, o receptor, quando reconhece uma ou mais

mensagens, também informa ao transmissor o tamanho de sua janela disponível para recepção de
novos dados. A partir dessa informação, disponível no campo window size, o transmissor pode
aumentar ou diminuir sua janela de transmissão. Por exemplo, se o receptor avisa que sua janela
de recepção é zero, o transmissor deve parar de enviar novas mensagens imediatamente, pois o
buffer do receptor está cheio. Posteriormente, quando o buffer tiver espaço disponível, o
transmissor pode ser avisado que pode novamente enviar dados.
Segmento TCP
Um segmento TCP é formado por um cabeçalho de 20 bytes, seguido de um número variável de
opções e finalizado por uma área de dados também opcional. Em geral, o tamanho máximo de um
segmento é limitado pelo campo de dados do datagrama IP, ou seja, 65.515 bytes (64 Kb menos
20 bytes do cabeçalho IP). O formato do segmento TCP pode ser observado na figura abaixo.

Source port: Identifica a porta de origem. Juntamente com o IP de origem formam o socket de origem.
Destination port: Identifica a porta de destino. Juntamente com o IP de destino formam o socket de
destino.
Sequence number: Identifica a mensagem que está sendo enviada. Na verdade, o TCP numera os bytes
dentro do segmento e o sequence number identifica a posição do byte dentro do segmento.
Acknowledgement number: Identifica o número do próximo byte que o transmissor espera receber.
TCP header length: Identifica o tamanho do cabeçalho TCP, incluindo as opções, quando utilizadas.
URG (Urgent): Flag que indica que o campo urgent pointer é válido e deve ser utilizado.
ACK: Flag que indica que o campo acknowledgement number é válido e deve ser utilizado para
reconhecimento.
PSH (Push): Flag utilizado para forçar o envio do segmento imediatamente, independentemente do seu
tamanho.
RST (Reset): Flag utilizado para a reinicialização da conexão.
SYN (Synchronize): Flag utilizado para a abertura de uma conexão lógica.
FIN: Flag utilizado para a finalização de uma conexão lógica.
Window size: Utilizado para informar ao transmissor o tamanho da janela ainda disponível para o
recebimento de dados no receptor, a fim de implementar o controle de fluxo fim-a-fim e evitar overflow.
Checksum: Utilizado para garantir a integridade do segmento, ou seja, cabeçalho e dados.
Urgent pointer: Permite implementar um mecanismo de sinalização, pelo qual a origem informa ao
destino que o processamento do segmento deve ser interrompido.
Options: Permitem definir opções adicionais não disponíveis no cabeçalho padrão, como o tamanho
máximo do segmento, ampliar a capacidade da janela de recebimento e utilização da retransmissão
seletiva com o uso de NAKs.
Data: Área onde são encapsulados os dados vindos da camada de aplicação. O tamanho máximo do
campo de dados está limitado ao campo de dados do datagrama IP, ou seja, 65.495 bytes (64 Kb menos
20 bytes do cabeçalho IP menos 20 bytes do cabeçalho TCP). O campo de dados pode não estar presente
em segmentos que, por exemplo, apenas realizam a função de reconhecimento ou que iniciam ou
finalizam uma conexão.
3.2. Protocolo UDP

O protocolo UDP (User Data Protocol) está na mesma camada que o TCP, no entanto, eles são
bastante diferentes. Enquanto o protocolo TCP está preocupado em oferecer um serviço orientado
à conexão, o UDP oferece um serviço não orientado. Quando se utiliza o UDP na camada de
transporte significa que não há garantias de entrega e seqüência de pacotes a serem entregues à
camada de aplicação. Nesse caso, a implementação do serviço é delegada para a camada de
aplicação.

A grande maioria dos protocolos de aplicação, como HTTP, FTP e SMTP, utiliza o TCP na
camada de transporte. Por outro lado, existem alguns protocolos que utilizam o UDP, como o
DNS, TFTP e BOOTP. Os protocolos de aplicação que utilizam o UDP levam em conta que o
meio de transmissão oferece baixas taxas de erros, como no caso de redes locais.
A principal função do UDP é implementar o endereçamento no transporte e oferecer integridade

dos dados transmitidos. Sua maior vantagem é o desempenho, pois dispensa a necessidade de
estabelecer uma conexão lógica e depois desfazê-la. Um segmento UDP é formado por um
cabeçalho de 8 bytes e uma área de dados opcional. O formato do segmento UDP pode ser
observado na figura abaixo.
Source Port: Identifica a porta de origem. Juntamente com o IP de origem formam o socket de origem.
Destination port: Identifica a porta de destino. Juntamente com o IP de destino formam o socket de
destino.
Length: Identifica o tamanho do segmento UDP, incluindo o cabeçalho e a área de dados.
Checksum: Utilizado para garantir a integridade do segmento. A utilização deste campo é opcional.

3.3. Protocolo LDAP
O protocolo LDAP (Lightweight Directory Access Protocol) é um padrão para a utilização de
serviços de diretório em uma rede de computadores. Um diretório é uma base de dados com
informações sobre os diversos objetos da rede, como impressoras, usuários e servidores. O
serviço de diretório permite que um cliente obtenha informações sobre os objetos disponíveis da
rede a partir dessa base de dados.
Um serviço de diretório é semelhante a um serviço de páginas amarelas, onde várias empresas

estão organizadas por áreas de atuação com seus nomes, endereços e telefones. No caso de um
serviço de diretório, um usuário pode pesquisar, por exemplo, por uma impressora colorida de
alta resolução que aceite um determinado tipo de arquivo e que esteja próxima de seu local de
trabalho. O usuário poderia também pesquisar por um usuário em especial e localizar seu email e
telefone para contato.
O LDAP está na camada de aplicação, utiliza o protocolo TCP como transporte e funciona no
modelo cliente/servidor. Nesse modelo, o cliente solicita uma informação ao servidor responsável
por manter o serviço de diretório, o servidor recebe a solicitação, processa o pedido e envia a
resposta para o cliente.
Existem vários produtos que oferecem serviços de diretórios, como o Novell Directory Services
(NDS) e o Active Directory da Microsoft. É importante verificar o grau de compatibilidade com o
padrão LDAP nos produtos que oferecem esse tipo de serviço.

3.4. Serviço DNS
Protocolo DNS
Em uma rede TCP/IP, os hosts comunicam-se utilizando o endereço IP; no entanto, os usuários da
rede preferem utilizar nomes em vez de endereços. Para facilitar o acesso aos hosts da rede, cada
endereço IP deve estar associado a um nome de host. Sempre que o usuário refere-se a um nome
de host, esse nome deve ser convertido antes para o endereço IP correspondente.
Uma forma bastante simples de implementar esse esquema de endereçamento é utilizar um

arquivo em cada estação contendo uma lista com o nome de cada host existente na Internet e seu
respectivo IP. Quando o usuário refere-se a um host, o nome é pesquisado no arquivo e o
endereço IP retornado. Em função do número de hosts da Internet e suas constantes mudanças,
manter tal arquivo seria, na prática, impossível. Logo, esse método é indicado apenas para
pequenas redes.

# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
200.255.253.239 pop-gw.embratel.com.br
200.255.125.213 www.embratel.com.br
200.162.224.82 edu.topmaster.com.br
200.225.79.48 www.topmaster.com.br
O exemplo acima refere-se ao arquivo host utilizado na maioria dos sistemas operacionais para
criar o mapeamento estático de endereços.
O protocolo DNS (Domain Name System) foi desenvolvido com a finalidade de servir como
tradutor de nomes em grandes redes, como a Internet. Por exemplo, quando o usuário digita o
endereço da Embratel, o nome www.embratel.com.br deve ser traduzido antes para o IP
correspondente ao servidor Web (200.255.125.213). Depois de obtido o endereço IP, o acesso ao
servidor poderá ser realizado.
O serviço de nomes é implementado por servidores DNS que possuem tabelas relacionando os
nomes de hosts e seus respectivos IPs. Quando um usuário utiliza o nome www.embratel.com.br,
um servidor DNS é consultado e o IP correspondente retornado. Se o usuário souber o IP do
servidor da Embratel, o servidor DNS não será consultado.
; Hosts para: embratel.net.br
@ IN SOA ns.embratel.net.br. admin.embratel.net.br. (
1999052101; Serial (aaaammddvv)
3600 ; Refresh (1 hour)

900 ; Retry (1/4 hour)
604800 ; Expire (1 week)
86400) ; Minimum (1 day)
IN NS ns.embratel.net.br.
IN NS ns2.embratel.net.br.
IN MX 100 mailhost.embratel.net.br.
ns2 IN A 200.245.255.33
ns IN A 200.255.253.241
mailhost IN A 200.255.253.239
rjo01 IN A 200.208.155.102
rjo02 IN A 200.208.155.150
www 60 IN CNAME rjo02
home IN CNAME rjo02
infoserv 60 IN CNAME rjo02
news IN A 200.208.155.103

rjo04 IN A 200
Espaço de endereçamento
O espaço de endereçamento (namespace) utilizado pelo DNS é hierárquico, semelhante ao
modelo de árvore de diretórios e subdiretórios utilizado na maioria dos sistemas operacionais. O
DNS é formado por domínios e subdomínios, sendo que o domínio raiz é conhecido como root.
Abaixo do root existem os domínios de primeiro nível (top-level) que podem representar
domínios genéricos ou países. Abaixo dos domínios de primeiro nível, estão os subdomínios que,
por sua vez, podem ser formados por outros subdomínios. Os hosts ficam nas folhas.
Para se ter acesso a um host que faça parte do esquema de domínios, basta fazer referência ao
caminho a partir da raiz. Por exemplo, o servidor Web da Embratel pode ser referenciado como
www.embratel.com.br e o servidor correio poderia ser referenciado como smtp.embratel.com.br.

Genérico Descrição Domínio de país Descrição
gov Governo br Brasil
com Comercial us Estados Unidos
mil Militar de Alemanha
org Organização sem fins jp Japão

lucrativos
nl Holanda
edu Educacional
net Provedores
O esquema de nomes hierárquico torna o DNS bastante flexível. Quando um novo subdomínio
precisa ser criado, basta apenas solicitar sua criação abaixo do domínio desejado, sem interferir
nos demais domínios. No caso do domínio de uma empresa, é possível a criação de subdomínios
apenas com a alteração do servidor DNS da própria empresa. Por exemplo, se for preciso criar o
subdomínio ead abaixo do domínio Embratel, basta que o administrador da rede registre no
servidor DNS do domínio embratel.com.br o novo domínio ead.embratel.com.br.
Busca de nomes
O DNS, além de hierárquico, também é um esquema distribuído. Devido ao grande número de
hosts na Internet, seria complicado que todos os servidores DNS fossem capazes de traduzir
qualquer nome para seu respectivo IP. No modelo distribuído, os servidores DNS mapeiam
apenas um pequeno número de hosts, formando uma zona de autoridade.
Uma zona de autoridade pode responder por um ou mais domínios, sendo esta uma decisão do
gerente da rede. Cada zona possui um servidor DNS primário, que possui o arquivo com a
configuração utilizada pelo servidor e um ou mais servidores secundários. Esses sevidores
secundários possuem uma cópia da configuração e funcionam como backup do servidor primário.
O esquema de busca de um nome dentro da estrutura de domínios é conhecido como lookup,

sendo iniciado pelo cliente chamando a rotina resolver. Para exemplificar o seu funcionamento,
vejamos o exemplo de um usuário localizado no domínio www.mci.com acessando o site de
treinamento à distância da Embratel ead.embratel.com.br.

Registros de DNS
Um servidor DNS é responsável por várias outras informações além do mapeamento host-IP,
sendo que cada uma delas é representada por um tipo de registro. Observe, a seguir, os principais
tipos de registro do DNS:

Tipos de registro do DNS Descrição
SOA (Start Of Authority) Define uma zona de autoridade e fornece algumas

informações gerais sobre o domínio.
Informações contidas no registro SOA
Serial Indica a versão da informação. O

servidor secundário compara de tempos
em tempos (refresh) o serial da zona que
ele possui com o serial no servidor
primário.
Refresh Indica a freqüência com que o

secundário checará com o primário se
uma zona deve ser atualizada.
Retry Informa quanto tempo um secundário

deve aguardar antes de tentar
novamente uma transferência de zona
que tenha falhado.
Expire Tempo máximo que um secundário pode

usar uma informação sobre uma zona
antes que ela expire por falta de refresh.
Minimum Especifica o valor default para uma zona

TTL que especifica o tempo em que uma
informação ficará cacheada antes de ser
descartada.
Indica os servidores autoritativos para uma zona. Cada zona

NS (Name server)
deve possuir pelo menos dois servidores autoritativos.
A (Address) Permite mapear o nome do host e seu respectivo IP. Uma

determinada máquina deve ter um registro A para cada
endereço IP que possuir.
MX (Mail eXchange) Define o servidor configurado para o recebimento de e-mails

para o domínio.
PTR (Pointer) Permite mapear o IP ao nome do host, sendo utilizado para

buscas reversas.

CNAME (Canonical Name) Permite criar alias (apelidos) para os nomes de hosts.
Tabela de DNS Interativa

Conheça melhor os registros da tabela de DNS clicando no nome do registro abaixo:

|

3.5. Protocolo RTP/RTCP
O protocolo RTP (Real-time Transport Protocol) é direcionado à transmissão de dados em tempo
real, como áudio e vídeo interativos, tendo sido projetado principalmente para a transmissão
multicast. O RTP é muito utilizado em aplicações para vídeo-conferência, ferramentas de
apresentação multimídia e tráfego de voz (VoIP).
O RTP localiza-se na camada de aplicação e utiliza o protocolo UDP na camada de transporte,

basicamente para oferecer endereçamento e verificação de integridade da mensagem. A figura, a
seguir, apresenta o encapsulamento da mensagem RTP dentro de um segmento UDP, que por sua
vez está encapsulado em um pacote IP.
É importante ressaltar que o protocolo RTP não garante a qualidade do serviço, pois não tem
qualquer influência na pré-alocação de recursos na rede de interconexão. Para isso, devem ser
utilizados outros protocolos, como o RSVP (Resource reSerVation Protocol) e MPLS
(MultiProtocol Label Switching), apresentados anteriormente.

Principais funções do protocolo RTP
Timestamping As mensagens RTP enviadas possuem o

momento exato no qual foram geradas. Com
esta informação, o destinatário pode
implementar a temporização da mensagem,
ou seja, reproduzi-la da mesma forma que a
original.
Controle de erro e seqüenciamento As mensagens RTP enviadas possuem o

momento exato no qual foram geradas. Com
esta informação, o destinatário pode
implementar a temporização da mensagem,
ou seja, reproduzi-la da mesma forma que a
original.
Identificação do tipo da mensagem O protocolo RTP permite definir diferentes

formatos de dados que podem ser enviados,
como PCM, MPEG, JPEG e H.261. Essa
característica torna o protocolo bastante
flexível para o tráfego de áudio e vídeo,
além de simplificar a inclusão de novos
formatos.
O protocolo RTCP (Real-time Transport Control Protocol) foi projetado para trabalhar em
conjunto com o protocolo RTP. As suas principais funções são a monitoração da qualidade do
serviço e a identificação dos participantes da transmissão. Durante uma sessão RTP, os
participantes periodicamente trocam mensagens RTCP com o objetivo de informar aos demais a
qualidade dos dados recebidos. Com isso, é possível que o emissor ajuste a sua transmissão em
função das informações recebidas.

4. Os Serviços e Aplicações
4.1. Servidores Web

Protocolo HTTP
O serviço World Wide Web (WWW) ou, simplesmente, Web é basicamente um conjunto de
documentos (páginas) contendo texto, imagens, áudio e/ou vídeo. As páginas são interconectadas
através de hiperlinks, permitindo ao usuário navegar entre os diversos documentos de forma
bastante intuitiva. O esquema de hiperlinks que liga os documentos forma o que é conhecido
como hipertexto.
Os documentos disponibilizados na Internet são desenvolvidos em HTML (HyperText Markup

Language), que é uma linguagem de marcação de texto responsável apenas pela forma na qual as
informações são apresentadas na tela. Depois de desenvolver as páginas HTML, os arquivos
devem ser copiados para um servidor Web, como o Apache e Microsoft Internet Information
Server (IIS).
Um cliente que deseja acessar uma determinada página deve utilizar sua respectiva URL
(Uniform Resource Locator), como, por exemplo, http://www.embratel.com.br/ index.html, sendo
que:
• http especifica o protocolo responsável pela comunicação entre o browser e o
servidor;
• www.embratel.com.br representa o domínio DNS;
• index.html é a página HTML.
Depois que a página é localizada e copiada do servidor Web para o cliente, o browser interpreta
as marcações (tags) da página e a exibe na tela.

O protocolo HTTP (HyperText Transfer Protocol) faz parte da camada de aplicação do modelo
Internet, utiliza o protocolo TCP como transporte e funciona no modelo cliente-servidor. Nesse
modelo, quando um cliente deseja um serviço, abre-se uma conexão TCP e o pedido é enviado. O
servidor processa e devolve a solicitação pela mesma conexão TCP, que é desfeita em seguida.
Esse esquema de comunicação é conhecido como conexão sem estado (stateless connection).
Foram introduzidos alguns artifícios para manter o controle das conexões, tais como cookies.
O HTTP é formado por dois tipos de mensagens: solicitações do cliente para o servidor e
respostas do servidor para o cliente. As mensagens utilizadas no HTTP são do formato texto. Nas
versões iniciais do protocolo, as mensagens de solicitações e respostas eram bastante simples
(simple-request e simple-response). O HTTP/1.1 implementa mensagens mais complexas (full-
request e full-response).
Uma mensagem de solicitação completa é formada por um método, a URL que deseja-se acessar
e a versão do protocolo HTTP que está sendo utilizada pelo cliente.
Solicitação completa:
<Método> <URL> <Versão do HTTP>
O método, na verdade, indica o comando que está sendo solicitado ao servidor. A tabela, a seguir,
apresenta os principais métodos disponíveis:

Método Descrição
GET Permite solicitar uma página em uma URL.
HEAD Permite solicitar apenas o cabeçalho da página.
PUT Permite transferir uma página para uma URL.
POST Permite acrescentar uma página.
DELETE Permite eliminar uma página.
Apesar da simplicidade, uma solicitação HTTP pode conter informações adicionais a serem
enviadas ao servidor. Essas informações são descritas como uma seqüência de cabeçalhos
(request headers) que são enviados juntamente com uma solicitação.
O exemplo abaixo ilustra o que o servidor Web irá receber do browser. A primeira linha indica o
método utilizado (GET), a URL contendo o nome do arquivo desejado e a versão do HTTP, no
caso a 1.0. A segunda linha identifica o browser que está sendo usado pelo usuário, no caso o
Navigator (também conhecido como Mozilla), componente do Netscape Communicator. Essa
linha, assim como as demais, contém informações complementares ao pedido HTTP. As quatro
linhas seguintes trazem diversas informações úteis. A terceira linha, por exemplo, indica que o
browser está preparado para receber documentos texto (text/plain), documentos HTML
(text/html) e diversos tipos de imagens, como GIF (image/gif) e JPEG (image/jpeg). Essa lista é
codificada de acordo com regras MIME (Multipurpose Internet Mail Extensions), que identificam
o tipo de documento. Na terceira linha, o */* indica que o browser aceita qualquer tipo de
arquivo.
GET /internet/index.html HTTP/1.0

User-agent: Mozilla/4.5b1 [en] (WinNT; I)
Accept: text/plain, text/html, image/gif,
image/x-xbitmap, image/jpeg, image/pjpeg,
image/png, */*
Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding: gzip
Accept-Language: en
Uma mensagem de resposta completa é formada pela versão do protocolo HTTP que está sendo
utilizada pelo cliente, por um código de status e uma pequena frase explicando o código de status.
Resposta completa
<Versão do HTTP> <Status> <Frase>

Existem inúmeros códigos de status que podem indicar sucesso na solicitação, falha no cliente ou
no servidor. Alguns exemplos de códigos bastante comuns são apresentados a seguir:
Código Frase Descrição
200 Document follows Solicitação bem sucedida e o

documento será enviado.
403 Unauthorized Acesso não autorizado.
404 Not found Documento não localizado.
O exemplo, a seguir, seria a resposta enviada a partir da solicitação apresentada anteriormente. A

primeira linha indica a versão 1.0 do HTTP, o código de status 200 e que a informação
requisitada será retornada. Nas linhas seguintes são identificados o servidor Web, o tamanho do
documento (5807 bytes, de acordo com o exemplo) e outras informações. A mais importante,
entretanto, é a Content-type, que informa ao browser o tipo de informação que está sendo
retornada, de modo que ele possa exibi-la da forma adequada. Essa informação é codificada pelo
tipo MIME no pedido do browser, do mesmo modo que a lista de tipos na linha Accept.
Em outras palavras, o servidor Web, ao receber o pedido, procura o arquivo e verifica a sua
extensão (.html) através de uma consulta a uma grande tabela de tipos MIME que indica o código
que deverá ser usado para cada extensão existente. No caso, o tipo usado foi o text/html,
indicando que o arquivo que está sendo enviado é do tipo HTML. Após as linhas iniciais e uma
linha intermediária em branco, vem o documento propriamente dito ou alguma resposta acusando
erro ou arquivo não encontrado. Essa informação será, então, exibida pelo browser segundo o tipo
MIME informado na linha Content-type. Nesse momento, a página requisitada aparece na tela do
browser do usuário.
HTTP/1.0 200 Document follows

Date: Thu, 20 Aug 1998 18:47:27 GMT
Server: NCSA/1.4.2
Content-type: text/html
Last-modified: Fri, 14 Aug 1998 20:14:23 GMT
Content-length: 5807
... conteúdo do arquivo index.html ...

4.2. Servidores FTP
Protocolo FTP
O protocolo FTP (File Transfer Protocol) permite a transferência de arquivos entre hosts
utilizando a rede de comunicação. O usuário remoto pode, além de copiar arquivos, visualizar o
conteúdo de arquivos e diretórios, definir o formato dos arquivos (texto e executável) além de
criar e eliminar arquivos e diretórios.
O FTP está na camada de aplicação e utiliza o protocolo TCP no transporte. O FTP utiliza o
modelo cliente/servidor, sendo necessário um cliente FTP e um servidor FTP. O servidor FTP
utiliza duas portas pré-definidas: 20 (dados) e 21 (controle). A porta 20 é reservada para a
transferência de dados entre cliente e servidor, enquanto a porta 21 é utilizada para a troca de
comandos.
O usuário tem acesso aos serviços de transferência de arquivo a partir do utilitário FTP, que
geralmente acompanha a maioria dos sistemas operacionais. A tabela, a seguir, descreve os
principais comandos disponíveis no utilitário:
Comando Descrição
open Abre uma conexão.
close Encerra uma conexão.
get Copia um arquivo do host remoto para o host

local.
put Copia um arquivo do host local para o host

remoto.
dir Lista o conteúdo do diretório remoto.

ascii/binary Permite definir o formato do arquivo.
Após o comando open, o usuário é solicitado a identificar-se através de um login e senha. Apesar
dessa facilidade, o protocolo FTP não oferece qualquer confidencialidade no envio das
informações, inclusive em relação à senha, que é enviada abertamente. Alguns servidores FTP
permitem o login anônimo, utilizando a conta anonymous.
No exemplo a seguir, estamos conectando o servidor FTP da Embratel ftp.embratel.net.br

utilizando a conta anonymous e verificando o conteúdo do diretório default de login.
Exemplo:
ftp> open ftp.embratel.net.br

Connected to ftp.embratel.net.br.
220 wks01.rjo.embratel.net.br FTP server (Version wu-2.6.2(1) Tue Dec 4
17:42:05
EDT 2001) ready.
User (ftp.embratel.net.br:(none)): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230-+-----------------------------------------------------------------------+
230-Servicos Internet Via EMBRATEL
230-Bem-vindo ao Servidor de FTP da Embratel ! (ftp://ftp.embratel.net.br)
230- Horario Local : Mon Jul 22 23:34:32 2002
230- Sua maquina : dial237.ism.com.br
230- Voce e' o usuario numero 2.
230- Numero maximo de usuarios anonimos : 400
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 16
-rw-r--r-- 1 1 1242 Oct 26 1999 .welcome
lrwxrwxrwx 1 1 7 Aug 31 2000 bin -> usr/bin
dr-xr-xr-x 2 1 512 Oct 26 1999 dev
dr-xr-xr-x 3 1 512 Oct 26 1999 etc
drwxr-xr-x 2 70 512 Oct 26 1999 incoming
drwxr-xr-x 23 70 512 May 16 14:06 pub
drwxr-xr-x 5 1 512 Oct 26 1999 usr
226 Transfer complete.
ftp: 381 bytes received in 0,09Seconds 4,19Kbytes/sec.
Protocolo TFTP
O protocolo TFTP (Trivial File Transfer Protocol), assim como o FTP, também permite a
transferência de arquivos, porém de forma mais simples. Um exemplo de utilização do TFTP
acontece na implementação de boot remoto em estações diskless (sem disco).
O TFTP está na camada de aplicação e utiliza o protocolo UDP no transporte, o que obriga o
TFTP a implementar seus próprios mecanismos de controle de erro. O TFTP também utiliza o
modelo cliente/servidor, sendo necessário um cliente e um servidor TFTP. O servidor TFTP
utiliza apenas a porta 69 para dados e controle.

4.3. Servidores de correio eletrônico
Protocolo SMTP
O serviço de email (electronic mail) ou correio eletrônico é um dos mais antigos e importantes
serviços da Internet. O serviço é formado por clientes (user agents) e servidores (Message
Transfer Agents - MTAs). Os clientes, como Eudora e Microsoft Outlook, são responsáveis por
enviar e receber as mensagens. Os servidores, como Sendmail, Lotus Notes e Microsoft
Exchange, são responsáveis por reencaminhar a mensagem até seu destino.
Um email é muito semelhante a uma carta convencional, sendo formado por um envelope com
informações do destinatário, um cabeçalho com informações do remetente e o texto propriamente
dito. Inicialmente, a área de texto permitia apenas mensagens simples utilizando caracteres ASCII,
no entanto, o protocolo MIME (Multipurpose Internet Mail Extensions) foi concebido para ser uma
extensão, oferecendo suporte a outros alfabetos e mídias, como imagens, som e vídeo.
O protocolo SMTP (Simple Mail Transfer Protocol) está na camada de aplicação e utiliza o
protocolo TCP no transporte. O servidor de email recebe conexões na porta pré-definida 25. Após
estabelecida a conexão, a mensagem é armazenada na caixa postal (mailbox) do destinatário. Por
exemplo, quando enviamos um email para rbmaia@embratel.com.br, a mensagem é armazenada
na mailbox referente ao usuário rbmaia.

Protocolo POP3 e IMAP
O protocolo POP3 (Post Office Protocol versão 3) permite que um cliente acesse um servidor de
email, onde está sua caixa postal, e transfira suas mensagens do servidor para a máquina local.
Em geral, as mensagens são apagadas do servidor depois de copiadas para o cliente.
O protocolo IMAP (Interactive Mail Access Protocol) permite que um cliente acesse um servidor
de email, onde está sua caixa postal, e apenas consulte suas mensagens no servidor, sem copiá-las
para a máquina local. A grande vantagem do IMAP é permitir que o usuário possa ter acesso à
sua caixa postal em qualquer máquina, ou seja, ele poderá consultar seus emails em um desktop
no trabalho ou em um laptop em casa.
4.4. Aplicações de Segurança

Firewall
Um firewall permite implementar um esquema de segurança centralizado, onde todo o tráfego
que sai ou entra de/para a empresa pode ser monitorado. Com esse monitoramento, é possível
restringir o acesso da rede interna de/para a rede externa, normalmente a Internet.
Em geral, o firewall é um software que é executado em um servidor Unix, Microsoft Windows

NT ou Windows 2000, dedicado exclusivamente para essa função. Também existem soluções que
englobam hardware e software proprietários. Independentemente da plataforma, as soluções de
firewall podem ser divididas em dois tipos: firewall de rede e firewall de aplicação.

Firewall de rede
O tipo mais simples de firewall atua apenas na camada de rede, basicamente monitorando
informações do datagrama IP, como endereço de origem e destino e o tipo de protocolo.
Opcionalmente, também monitora portas de origem e destino pertencentes à camada de
transporte, por isso esse tipo de firewall também é chamado de filtro de pacotes.
Aplicação
Transporte
Rede
Enlace/Físico
Firewalls deste tipo são utilizados nas bordas da rede, funcionando como um primeiro nível de
defesa, podendo ser implementado no próprio roteador que conecta a rede interna e externa.
A partir de regras previamente definidas, o firewall pode permitir ou não certos tipos de tráfego
entre a rede interna e a Internet. Por exemplo, a tabela abaixo apresenta algumas das regras que
podem ser implementadas em um firewall para a rede 192.168.1.0.
IP Porta IP Porta Ação Descrição

origem origem destino destino
* * 192.168.1.0 > 1023 Permite Permite que as conexões solicitadas

internamente possam ser estabelecidas
* * 192.168.1.2 25 Permite Permite que qualquer usuário acesse o

(SMTP) serviço de mail
* * 192.168.1.3 80 Permite Permite que qualquer usuário acesse o

(HTTP) serviço de Web
* * * * Nega Qualquer acesso que não tenha sido

permitido é negado
Apesar da simplicidade, a definição e a manutenção das regras do firewall podem tornar-se

difíceis, em função do grande número de regras especificadas. Um dos principais problemas com
firewalls de rede é a possibilidade de não se identificar ataques que falsifiquem o endereço IP de

origem, conhecidos como IP spoofing. Devido à fragilidade do protocolo, não se recomenda a
autenticação baseada em endereços IP.
Os firewalls de rede evoluíram e passaram a utilizar também informações da camada de

transporte para identificar e monitorar uma conexão lógica.
Esse tipo de firewall é conhecido como stateful inspection e atua, basicamente, no controle das
portas de origem e destino. Quando um cliente solicita uma conexão TCP, a porta origem deve
estar entre 1024 e 16384, enquanto a porta destino deverá ter um número entre 0 e 1023.
Aplicação
Transporte
Rede
Enlace/Físico
Por exemplo, uma conexão a um servidor Web utilizará, por default, a porta destino 80 e como
porta origem alguma porta disponível acima de 1023. O firewall stateful controla cada porta
origem utilizada na abertura de uma conexão externa, permitindo respostas apenas para as portas
de onde partiram as solicitações. Esta solução é mais segura que a oferecida por firewalls de rede,
que permitem a entrada de qualquer porta acima de 1023.
Além disso, o firewall stateful reconstrói os pacotes fragmentados e analisa o conteúdo por
completo, impedindo que um conjunto de pacotes aparentemente inócuos se transforme em um
ataque.
Firewall de aplicação (Proxy)

O firewall de aplicação ou proxy, além de poder executar as funções de filtro de pacotes, pode
examinar os protocolos da camada de aplicação, como HTTP e SMTP. Ao monitorar os
protocolos de aplicação, o controle é maior em relação a apenas realizar a verificação de
endereços IP e portas.
Aplicação
Transporte
Rede
Enlace/Físico

O proxy funciona como um intermediador entre o cliente e o servidor. O cliente solicita um
serviço ao servidor e o proxy intermedia a conexão, criando uma conexão com cliente e uma
outra com o servidor. Todas as mensagens enviadas ou recebidas podem ser analisadas pelo
proxy, que pode permitir ou não o envio/recebimento de uma determinada mensagem.
Proxy
Como proxy, atua na camada de aplicação e pode desempenhar diversas funções. O proxy pode
ser utilizado como um filtro de protocolos de alto nível, como SMTP e HTTP, pode verificar o
conteúdo de emails e páginas Web, além de decidir se o acesso será permitido ou não. Por
exemplo, se um email contém palavras que não estejam de acordo com as regras de segurança da
empresa, o proxy pode barrar a entrada ou saída de emails que contenham tais palavras. Além
disso, pode impedir a entrada de arquivos anexados e verificar a existência de vírus. Um processo
semelhante pode ser implementado também no tratamento do conteúdo de páginas Web,
impedindo a entrada de páginas que contenham certas palavras, componentes Active X, Applets
Java e código JavaScript.
Enquanto os firewalls de rede podem autenticar as conexões utilizando apenas IPs e portas, que
podem ser facilmente forjadas (IP spoofing), os proxies permitem implementar diversos
mecanismos de autenticação, como login e senha, token e biométrica. Por exemplo, para que os
usuários da rede interna possam ter acesso à Internet, eles devem ser autenticados primeiro no
proxy.
Por questões de desempenho, o proxy geralmente não implementa o controle em todas as

camadas que lhe são permitidas. Na prática, as funções de filtro de pacotes são implementadas

por um firewall preocupado apenas com as camadas de rede e transporte, enquanto o proxy
implementa apenas o controle na camada de aplicação.
O proxy também pode funcionar como cache de páginas Web. Quando um usuário realiza um
acesso a uma determinada página na Internet, o conteúdo da página é copiado para o proxy e
repassado ao usuário. Quando um outro usuário acessar a mesma página, não será preciso buscá-
la novamente, pois a página estará localizada no cache do proxy e poderá ser entregue ao cliente
sem a necessidade de acesso à Internet. Dependendo da política de atualização de cache do proxy,
é possível que os usuários acessem páginas com conteúdo desatualizado.
NAT
O NAT (Network Address Translation) geralmente é implementado no roteador que liga a rede
interna à Internet e tem duas funções principais: endereçamento e segurança.
Com o crescimento da Internet, a distribuição de endereços IP tornou-se um problema. Como os

endereços IP classes A e B estão esgotados, restam apenas endereços classe C, que permitem no
máximo 254 hosts por endereço. Para contornar o problema, as empresas passaram a utilizar um
endereço inválido na rede interna e um endereço válido para acessar a rede externa.
Quando se implementa o esquema de NAT, os usuários da rede externa desconhecem os

endereços da rede interna, não tendo acesso direto às estações. Nesse caso, o dispositivo que
implementa o NAT intermedia o acesso da rede externa para a rede interna, escondendo os

endereços internos e aumentando o nível de segurança. O mecanismo de NAT só é possível
devido ao esquema de portas que permite mapear vários clientes internos em apenas um endereço
de saída.
Criptografia
A criptografia permite implementar uma série de atributos indispensáveis para uma comunicação
segura em uma rede de computadores, como a Internet. Seguem as implementações permitidas:
• Confidencialidade: é a garantia de que a comunicação entre o transmissor e
receptor seja implementada de forma sigilosa, sem o conhecimento de terceiros.
Por exemplo, quando utilizamos o Internet Banking, a comunicação entre o
cliente e o servidor do banco deve ser feita de forma confidencial;
• Integridade: é a garantia de que a informação trocada entre o transmissor e
receptor não será alterada. Por exemplo, quando enviamos um email, nada
impede que alguém intercepte a mensagem e altere seu conteúdo;
• Autenticidade: é a garantia de que a pessoa que realizou a operação é de fato
aquela que diz ser. Por exemplo, quando recebemos um email de alguém, não
temos qualquer garantia de que a mensagem foi enviada pela pessoa que consta
no cabeçalho do email, pois essa informação é facilmente forjada;
• Não repúdio: é a possibilidade de provar a terceiros a autoria de uma operação
após a mesma ter ocorrido. Por exemplo, quando enviamos um email, a pessoa
que recebe a mensagem não tem como provar quem foi a pessoa que o enviou.
A criptografia moderna está baseada no conceito de chaves criptográficas, que consistem em uma
seqüência de bits. Existem duas técnicas atualmente utilizadas: chaves simétricas e assimétricas.
Chaves simétricas
No esquema de chaves simétricas, também conhecidas como chaves secretas, o transmissor e o
receptor devem possuir a mesma chave criptográfica. O transmissor utiliza sua chave para
criptografar a mensagem, que pode então ser enviada. O receptor utiliza a mesma chave para
descriptografar a mensagem recebida. Caso a mensagem seja interceptada, não será possível ler o
seu conteúdo, a não ser que se descubra a chave secreta utilizada.

A criptografia de chave simétrica é muito rápida, mas apresenta dois problemas: a troca e
gerência das chaves.
Chaves assimétricas
No esquema de chaves assimétricas, também conhecidas como chaves públicas, o transmissor
possui um par de chaves e o receptor outro. O par de chaves é formado por uma chave privada e
uma pública. A chave privada é de conhecimento apenas do dono do par, enquanto a chave
pública é amplamente divulgada e pode ser consultada por qualquer usuário.
Quando o transmissor deseja enviar uma mensagem confidencial, ele utiliza a chave pública do
receptor que está disponível na rede. O receptor, ao receber a mensagem, utiliza sua chave
privada para abrir a mensagem. Caso alguém intercepte a mensagem, não será possível a sua
leitura, pois apenas a chave privada do receptor pode ler uma mensagem criptografada com sua
chave pública.
Chaves assimétricas - Criptografia
Além de garantir a confidencialidade e integridade da mensagem, o esquema de chave pública

permite também implementar a assinatura digital, garantindo autenticidade da operação. Nesse
caso, o transmissor utiliza a sua chave privada para assinar (criptografar) a mensagem e o
receptor, por sua vez, utiliza a chave pública do transmissor para abri-la. Caso o receptor consiga
abrir a mensagem, está garantida a autenticidade da operação.

Chaves assimétricas - Assinatura digital
É importante perceber que é possível utilizar os dois serviços de forma isolada ou combinada, ou
seja, apenas confidencialidade, apenas autenticidade ou os dois serviços simultaneamente.
Autoridades certificadoras
As autoridades certificadoras ou CAs (Certification Authorities) são cartórios virtuais onde as
chaves públicas ficam armazenadas de forma segura, ou seja, podem ser consultadas mas não
alteradas. Verisign, Certisign, Entrust, Serasa, Serpro são apenas alguns exemplos de CA's que
atuam no Brasil.
A chave pública fica armazenada em um certificado digital que, além da chave, possui
informações da certificadora e do dono da chave pública. Existem diferentes tipos de certificados
que podem ser emitidos, como certificados para servidores, email, autoria de software e
delegação de autoridade. O padrão X.509v3 é, atualmente, o padrão para certificados digitais e
define diversas informações que devem compor um certificado.
Informações sobre a CA
Informações sobre o
possuidor da chave pública
Chave pública
Assinatura da CA
Um certificado passa por diversas fases, que se iniciam na sua criação. Os certificados devem ser
periodicamente renovados, caso contrário, são revogados.

HTTPS
O protocolo HTTP não foi concebido para oferecer segurança, porém, a maioria das operacões
em sites de comércio eletrônico utilizam esse protocolo. Para garantir segurança para operações
na Web, utiliza-se o HTTP seguro ou HTTPS. O HTTPS é o protocolo HTTP combinado ao
protocolo Secure Sockets Layer (SSL).
O SSL trabalha entre os protocolos da camada de aplicação e a camada de transporte (TCP),

oferecendo diversos serviços, como criptografia simétrica, assimétrica, certificação digital e
hashing. O SSL faz parte do browser e do servidor Web, que utiliza a porta 443 para conexões
Web seguras, ao contrário da porta default 80.
Aplicação
SSL
Transporte
Rede
Enlace/Físico

O SSL foi inicialmente desenvolvido pela Netscape e hoje é um padrão para a implementação de
segurança na Internet, sendo utilizado por diversas aplicações de comércio eletrônico, como no
exemplo de Internet Banking a seguir:
IDS (Intrusion Detection Systems)

A função de um sistema de detecção de intrusão (IDS - intrusion-detection system) é automatizar
a identificação de ataques e intrusões por hackers. Ainda que o uso de IDS seja cada vez mais
comum, também os ataques contra este tipo de sistema também se tornam mais comuns.
Modelos de IDS
Um IDS pode ser implantado de duas formas, individualmente ou combinadas:
• baseados no host: são sistemas que se prestam principalmente a monitorar os
ataques no nível do próprio computador. Em outras palavras, IDS baseados no
host detectam alterações no sistema de arquivos, nos arquivos de log e em
aplicativos em cada computador. Normalmente, um servidor de administração
central do IDS recebe atualizações de cada host conforme essas mudanças são
detectadas.

• baseados na rede: são sistemas que normalmente inspecionam a rede no nível
dos pacotes, de forma similar a um sniffer. Isto permite que o IDS monitore todos
os dados que trafegam em uma rede e que detecte a atividade de hackers ao
comparar esses dados com um conjunto de regras. Desta forma, o IDS não precisa
interagir com cada um dos computadores na rede - apenas com aqueles que estão
interferindo nos pacotes de dados. Além disso, um IDS baseado na rede pode ter
diversos sistemas de log espalhados por toda a rede, monitorando todos os
segmentos de forma abrangente
Tipos de IDS
Os IDS podem variar desde sistemas corporativos complexos a até aplicativos comuns para o
desktop. Independentemente do nível de complexidade, todos os IDS compartilham características
de operação comuns. Os tipos de IDSs disponíveis e seus métodos de operação são:
Monitor de arquivos de Log

A forma mais simples de um IDS é o monitor de arquivos de log, que procura detectar
intrusões ao analisar os logs de eventos do sistema. Por exemplo, um monitor de arquivo
de log básico poderia varrer o log de acesso de um servidor web procurando por
requisições /cgi-bin/ específicas. A limitação desta tecnologia reside no fato de só
detectar eventos que tenham sido registrados no log - algo que os invasores podem
facilmente alterar. Além disso, um sistema desse tipo perderia eventos de baixo nível no
sistema, posto que o registro de eventos é uma operação de alto nível na hierarquia dos
sistemas operacionais.

Amostra de um log gerado por um script de ataque em cgi-scan
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]

"HEAD /cgi-bin/test-cgi HTTP/1.0" 404 0
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]
"HEAD /cgi-bin/nph-test-cgi HTTP/1.0" 404 0
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]
"HEAD /cgi-bin/phf HTTP/1.0" 404 0
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]
"HEAD /cgi-bin/phf.pp HTTP/1.0" 404 0
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]
"HEAD /cgi-bin/phf.cgi HTTP/1.0" 404 0
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc]
"HEAD /cgi-bin/websendmail HTTP/1.0" 404 0
Monitor de integridade
Um monitor de integridade acompanha mudanças em estruturas chave do sistema. Por
exemplo, um monitor de integridade básico utiliza arquivos do sistema ou chaves no
registro como "iscas" para rastrear mudanças efetuadas por um invasor. Ainda que sua
funcionalidade seja limitada, monitores de integridade adicionam uma camada extra de
proteção a outras formas de detecção de intrusão.
Entre os atributos que podem ser rastreados por um monitor de integridade temos:
- Adição, exclusão e modificação de arquivos
- Mudança nos atributos dos arquivos (ocultos, somente para leitura, arquivo etc.)
- Último acesso ao arquivo
- Última escrita ao arquivo
- Data de criação
- Tamanho do arquivo
- Verificação por Hash
Scanner de assinatura
Da mesma forma que os scanners de vírus tradicionais, a maioria dos IDS tenta detectar
os ataques com base em um banco de dados de assinaturas de ataques conhecidas.
Quando um hacker tenta um ataque conhecido, o IDS procura por um padrão coincidente
em seu banco de dados.
Um exemplo clássico de assinatura detectada por um IDS são os scripts CGI. As

ferramentas de um hacker normalmente incluem um scanner CGI que sonda o servidor
Web alvo por bugs conhecidos no CGI. Por exemplo, um ataque phf conhecido permite
que o atacante recupere qualquer arquivo ao invés do arquivo HTML adequado. Para
detectar um ataque phf, o IDS deve vasculhar os pacotes por um pedaço da string:

GET /cgi-bin/phf?
Quando esta string é detectada, o IDS reage de acordo com as instruções pré-
programadas. Como se trata de um comando CGI básico, o nível de periculosidade deste
ataque é médio, quando muito. Entretanto, se o IDS encontrasse a string:
cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
...e criasse um registro em seu log como:
GET /cgi-bin/phf?Qalias x%0a/bin/cat%20/etc/passwd HTTP/1.0" 200

267
...então o problema seria mais sério e o servidor está vulnerável. Verificando o arquivo de
log, é possível observar que a requisição phf foi bem sucedida (código 200), o que
significa que o hacker foi capaz de visualizar o conteúdo do arquivo passwd, que contém
as senhas do sistema.
Detetores de anomalias
A detecção de anomalias normalmente compreende o estabelecimento de uma curva
padrão de atividade da rede ou do sistema e de um aviso quando houver um desvio dessa
curva. Posto que o tráfego de rede está constantemente mudando, este tipo de IDS é mais
adequado para implementação baseada em host. A detecção de anomalias fornece alta
sensibilidade porém baixa especificidade, sendo mais útil em máquinas da rede que sejam
absolutamente críticas porém razoavelmente estáticas. Nesta situação, quando um detetor
de anomalias indica alguma mudança com relação à curva padrão de atividade, será
necessária a intervenção humana para investigar as razões. Assim sendo, esta alta
sensibilidade apresenta um alto custo em termos de necessidade de recursos humanos.
Ataques ao IDS
Entender as vulnerabilidades de um IDS e a forma como estas são exploradas é um meio de
garantir uma melhor implementação da segurança na rede do cliente.
Fragmentação
Fragmentação é a forma mais comum de ataque contra IDS. Os pacotes são divididos em
pedaços menores, o que pode enganar um IDS. Um IDS stateful pode recompor os
pacotes fragmentados para a análise porém, conforme aumenta o tráfego, esta operação
consome mais recursos e se torna menos precisa. Quando a técnica de fragmentação é
utilizada, firewalls e IDS normalmente vêem apenas o pacote parcial, o que não ativa
nenhum dos tipos de alarme
Spoofing (fingimento)
É possível forjar (spoof) o número de seqüência do protocolo TCP visto pelo IDS. Por
exemplo, enviando um pacote SYN com um número de seqüência forjado após o início
da conexão, o IDS pode sair de sincronia com o host. Isto acontece porque o host é capaz

de ignorar o pacote SYN inesperado e incorreto, ao passo que o IDS pode se reconfigurar
para seguir o novo número de seqüência. Desta forma, o IDS ignora o fluxo de dados real
e fica esperando pacotes com um novo número de seqüência que não existe. Ao enviar
um pacote RST com um endereço forjado que corresponde ao SYN forjado pode
inclusive fechar esta nova conexão com o IDS.
Tipos de IDS
Mutação do HTTP
Requisições HTTP complexas podem freqüentemente enganar IDS que simplesmente verificam o
tráfego Web. Se um IDS está procurando pela vulnerabilidade phf conforme abaixo:
GET /cgi-bin/phf
é possível enganá-lo simplesmente adicionando dados extras à requisição:
GET /cgi-bin/subdirectory/../phf HTTP/1.0
Neste caso, foi solicitado um diretório qualquer e então utilizado o comando /../ para subir para o
diretório pai e então executar o script desejado. Esta técnica é chamada de "directory traversal", e
é atualmente uma das formas de ataque mais comuns.
O futuro dos IDS

A tecnologia para sobrepujar os IDS continua a evoluir. Os fornecedores de IDS devem manter a
evolução, preferencialmente estando sempre um passo a frente. Alguns dos avanços futuros são:
IDS incorporado
O protocolo IPSec em breve se tornará o padrão para a segurança da transmissão de
dados em rede. A implementação deste padrão permite que pacotes de uma determinada
empresa trafeguem por uma infra-estrutura não confiável como a Internet, ao mesmo
tempo que previne o roubo, a alteração ou mesmo a falsificação de dados por hackers.
Como o IPSec garante a conexão segura fim-a-fim e realiza a criptografia na camada de

rede, este processo se torna transparente para as aplicações que geram o tráfego IP.
Infelizmente para os IDS, o IPSec se torna uma faca de dois gumes: ainda que permita o
acesso seguro a redes corporativas através de VPNs, a criptografia dos pacotes impede a
ação de IDS que vasculham os dados por ataques maliciosos. Dessa forma, se um hacker
conseguir acesso a um cliente remoto, terá um túnel seguro através do qual poderá
acessar a rede corporativa.
A forma de prevenir quanto a esta possível brecha de segurança é introduzir IDS em

todos as camadas do TCP/IP. Dessa forma, o pacote será analisado conforme é
desencapsulado e processado, inclusive nas camadas mais altas.

Detecção estrita de anomalias
Conforme a velocidade e a complexidade dos ataques aumentar, logo será atingida a
capacidade dos IDS atuais de lidar com a carga de análise necessária. Uma forma de
resolver este dilema consiste na adoção mais ampla de detecção estrita de anomalias. Isso
significa que qualquer comportamento fora do normal, não importando quão pequeno,
será considerado um alarme positivo e verdadeiro.
Obviamente, para que seja exeqüível, esse método requer que o IDS atue em cada um dos
hosts ao invés de na rede como um todo. Dessa forma, é possível traçar uma curva de
utilização normal para cada host, que certamente será mais previsível do que a da rede
como um todo. Regras específicas de exceção aceitável são configuradas para cada um
dos hosts e o IDS monitora o comportamento da mesma forma que o firewall monitora a
rede.
Quando uma anomalia for detectada, quer no nível da rede, quer no nível da aplicação,
um alerta é enviado para o console central. Este método apresenta uma alta sensibilidade
a ataques porém gera uma quantidade significativa de dados.
IDS baseado em host vs. IDS baseado na rede

O uso cada vez mais comum de redes comutadas se torna um empecilho para IDS que
realizam a análise passiva de protocolos. Desta forma, a monitoração simultânea de
diversos hosts fica mais difícil. Além disso, o uso crescente de tráfego criptografado
também prejudica a análise passiva. Desta forma, é possível antever uma tendência de
cada vez mais mover o IDS da rede para os próprios hosts.
4.5. Aplicações em banda larga

Voz sobre IP
Voz sobre IP (Voice over IP - VoIP) é um serviço que permite conversas telefônicas ou áudio-
conferências utilizando uma rede TCP/IP, como a Internet, em tempo real. A grande vantagem em
utilizar esse tipo serviço é a convergência de voz e dados e, conseqüentemente, a redução de
custo com ligações interurbanas e internacionais que podem ser realizadas pelo custo de uma
ligação local.
O primeiro passo para enviar voz por uma rede de pacotes, como a Internet, é converter a voz,
que é um sinal analógico, em uma informação digital. Esse processo é implementado por um
dispositivo chamado codec, que normalmente utiliza uma técnica conhecida como PCM (Pulse
Code Modulation).

A técnica de PCM mostra o sinal analógico periodicamente (a cada 125 ms) e gera uma informação
de 8 bits. Os vários bytes gerados são agrupados em uma seqüência que é submetida a um algoritmo
de compressão, como ADPCM ou CS-ACELP. O processo de compressão é utilizado para reduzir o
tamanho da mensagem a ser enviada e, conseqüentemente, a necessidade de banda.
A seqüência compactada é então encapsulada no protocolo RTP (Real-time Transport Protocol),

que, por sua vez, é encapsulado no datagrama UDP e, por fim, no pacote IP. O pacote, ao chegar
ao destinatário, é desencapsulado e a seqüência de bytes é descompactada e convertida
novamente para um sinal analógico, ou seja, para voz.
Em 1996, o ITU (International Telecommunications Union) ratificou o padrão H.323, que define
como áudio e vídeo devem ser transmitidos em uma rede IP. Em 1998, o padrão foi atualizado. O
H.323 é na verdade uma família de padrões, sendo vários deles especificações de codecs de áudio
(G.711, G.722, G.723, G.728 e G729). A recomendação baseia-se nos protocolos RTP e RTCP
para o gerenciamento da conexão.

O grande problema com a transmissão de voz e demais informações multimídia em uma rede de
pacotes é a qualidade da transmissão. Em uma rede de pacotes, é possível que os pacotes sofram
atrasos para chegar ao destino e que esses atrasos sejam variáveis (jitter). Além disso, é possível
que alguns pacotes sejam perdidos e nunca cheguem. Algumas aplicações, como o correio
eletrônico, são pouco afetadas por esses problemas, mas aplicações de áudio e vídeo podem ser
seriamente comprometidas.
Video-conferência
Vídeo-conferência é um serviço que permite a transmissão de vídeo e áudio entre dois ou mais
pontos em tempo real, utilizando câmeras, monitores, microfones e auto-falantes. Existem
inúmeras aplicações para serviços de vídeo-conferência, como reuniões, ensino à distância,
telemedicina, home office, aplicações jurídicas, laboratórios virtuais e segurança. A vídeo-
conferência reduz principalmente custos, como, por exemplo, o deslocamento e possível estadia
dos envolvidos nos encontros.
O número de participantes de uma vídeo-conferência pode variar. Na figura 1, temos um exemplo

de uma vídeo-conferência bidirecional entre duas pessoas apenas. Na figura 2, temos uma
conferência entre diversos participantes de ambos os lados. É possível termos também apenas uma
única pessoa em um dos lados da transmissão. No caso de conferências com vários participantes em
diversos pontos, utiliza-se a técnica de MCU (Multi-point Conferencing Unit) ou multi-casting.

A vídeo-conferência com linhas privadas é um serviço bastante difundido. No entanto, o grande
desafio é implementá-lo utilizando uma rede de pacotes. Em uma rede de pacotes, como já
abordamos em VoIP, existem problemas de latência na entrega, jitter e perda de pacotes.
A especificação H.323 também é utilizada como padrão para a transmissão de vídeo-conferência

em redes TCP/IP. O H.323, além de definir diversos codecs para áudio, ofecere várias opções de
codificadores para vídeo, que permitem transformar as imagens (sinal analógico) em informação
digital. O padrão também define os conceitos de gatekeepers, gateways e MCUs.
Um gatekeeper H.323 controla os dispositivos envolvidos em uma vídeo-conferência e os

serviços oferecidos, como endereçamento, controle de admissão, gerência de banda, sinalização
etc. Gateways são responsáveis por conectar sistemas de vídeo-conferência que utilizem padrões
incompatíveis, como H.320 (ISDN) e H.321 (ATM).
Streaming
O áudio e vídeo-conferência são realizados em tempo real. Streaming consiste na possibilidade de
armazenar áudio e vídeo em servidores para, posteriormente, serem transmitidos. Por exemplo,
uma vídeo-conferência pode ser gravada e armazenada para depois ser reapresentada. O vídeo-
streaming pode ser amplamente utilizado para ensino à distância, permitindo que os alunos
possam assistir ou rever uma determinada aula sempre que desejarem.
Uma das características mais importantes em aplicações que utilizam streaming é a possibilidade
de a apresentação ser iniciada antes mesmo do término da transmissão. Por exemplo, quando um
usuário solicita um vídeo, o servidor envia apenas uma pequena seqüência (stream) do vídeo
compactado. Recebido o primeiro stream, o vídeo pode ser descompactado, enquando um
segundo stream está sendo recebido. Após a descompactação, o primeiro stream pode, então, ser
exibido, enquanto o segundo é descompactado e o terceiro recebido. Quando implementado
adequadamente, o streaming permite criar um fluxo contínuo de apresentação, mesmo que a
transmissão não seja contínua.

Protocolo RTSP
O protocolo RTSP (Real-Time Streaming Protocol) permite a apresentação de conteúdo
multimídia em redes IP, utilizando o conceito de streaming. O protocolo tem como principal
função estabelecer e controlar a exibição de áudio e vídeo streaming entre servidores de
multimídia e clientes. O RTSP permite implementar funções semelhantes a de um vídeo cassete
ou CD, como iniciar e finalizar a transmissão, gravação, pausa e avanço rápido, funcionando
como um "controle remoto". Suas principais funções são:
- Permitir ao cliente obter apresentações multimídia de algum servidor de mídia;
- Permitir a criação e gravação de conferência com vários participantes;
- Permitir a inserção de novas mídias em apresentações em tempo real.
O RTSP é implementado na camada de aplicação e utiliza em geral o protocolo RTP (Real-Time

Protocol), que por sua vez pode utilizar como transporte o TCP ou UDP. A sintaxe e operação do
RTSP são muito parecidas com as do protocolo HTTP/1.1, como pode ser observado no exemplo
abaixo, onde uma URL RTSP é especificada:
rtsp://media.example.com:554/twister/audiotrack
Apesar das inúmeras semelhanças, os protocolos RTSP e HTTP guardam certas diferenças. Por
exemplo, enquando o HTTP não guarda o estado da conexão (stateless), o RTSP a mantém.
Enquanto no HTTP apenas o cliente realiza solicitações, no RTSP tanto o cliente quanto o
servidor podem realizar solicitações.
Uma mensagem de solicitação RTSP é formada por um método, pela URL que se deseja acessar e
pela versão do protocolo que está sendo utilizada pelo cliente.

Solicitação = <Método> <URL> <Versão do RTSP>
Os métodos mais importantes são:
Método Descrição
OPTIONS Permite que clientes e servidores troquem informações sobre as opções que
podem ser aceitas.
SETUP Permite inicializar uma conexão RTSP.
PLAY Permite começar a transmissão, inicializada pelo SETUP.
PAUSE Permite parar a transmissão, sem liberar os recursos alocados.
TEARDOWN Permite encerrar uma transmissão liberando os recursos alocados.
RECORD Permite gravar uma transmissão.
4.5. Serviços de Gerenciamento

SNMP
O protocolo SNMP (Simple Network Management Protocol) permite o gerenciamento remoto de
dispositivos em rede, como roteadores, switches, servidores e impressoras. A partir desse
protocolo, é possível monitorar e gerenciar remotamente os diversos dispositivos, simplificando o
trabalho de administração da rede.
Para que um dispositivo possa ser gerenciado remotamente, é necessário que o dispositivo suporte
o protocolo SNMP, ou seja, execute um processo específico para essa função, conhecido como
agente. O agente tem a função de receber e processar comandos remotos, além de armazenar
localmente as informações relacionadas ao dispositivo.
Os agentes dos dispositivos comunicam-se com uma ou mais estações de gerenciamento, que
enviam comandos para os agentes e recebem as respectivas respostas. Uma estação de
gerenciamento é, geralmente, uma máquina dedicada para essa tarefa que processa um software
de gerência de rede, como o HP OpenView, IBM Tivoli NetView ou CA Unicenter.
O protocolo SNMP faz a ligação entre a estação de gerenciamento e os vários agentes, permitindo
que a estação faça uma consulta ao agente, ele processe o pedido e retorne uma resposta. É possível

também que o agente comunique determinados eventos sem a solicitação da estação de
gerenciamento.
Cada dispositivo mantém uma base de dados local, onde são armazenadas as variáveis que
descrevem o estado atual do dispositivo e histórico previamente armazenado.
A base de dados onde são armazenadas as variáveis correspondentes ao dispositivo se chama

MIB (management information base). Como diferentes serviços de gerenciamento de rede são
utilizados para diferentes tipos de dispositivos e protocolos, cada serviço terá o seu próprio
conjunto de variáveis (também chamadas objetos).
As mensagens de requisição que o agente pode receber da estação de gerenciamento podem ser
dos seguintes tipos:
• Get: O comando Get solicita uma determinada informação do agente sobre o
dispositivo que representa.
• Set: O comando Set modifica o valor de uma determinada informação no agente
• GetNext: Similar ao comando Get, o comando GetNext traz o próximo valor na
ordem léxica da MIB. É útil para os casos onde o tamanho da tabela é
desconhecido.
• GetBulkj: Similar ao comando Get, o comando GetBulk traz todos os valores da
MIB do agente em particular.
Ao receber qualquer uma dessas requisições, o agente executará a função específica: localizar o
valor de um determinado objeto e enviá-lo à estação de gerenciamento ou ajustar o valor do
objeto conforme solicitado.
Além disso, o agente pode enviar à estação de gerenciamento uma mensagem de Trap quando um
evento significativo ocorrer com o dispositivo que representa.

Uma mensagem de Trap pode ser enviada quando:
- uma porta ou módulo é ativado ou desativado
- limites de temperatura são ultrapassados
- há mudanças na topologia da rede e ocorrem falhas na autenticação
- ocorre um problema com a fonte de alimentação

5. SLA - Service Level
Agreement (Acordo de Nível
de Serviço)
5.1. O que é SLA?

Um acordo de nível de serviço (SLA) é um contrato formal negociado entre o fornecedor de
serviços de rede e o cliente, idealizado para definir um entendimento comum sobre a definição de
qualidade do serviço, das responsabilidades, prioridades etc. Ele especifica os serviços a serem
fornecidos e a qualidade. Na Embratel, este contrato é denominado Garantia de Desempenho.
Um SLA pode cobrir os mais diversos aspectos do relacionamento entre o fornecedor e o cliente,
tais como desempenho dos serviços, atendimento ao cliente, cobrança e provisionamento de
serviços. Entretanto, é preciso sempre ter em mente que a concordância quanto ao nível de
serviços prestados é o propósito primordial de um SLA.

5.2. A cadeia de valor
Sempre que falamos em cliente, nos referimos a quem solicita e recebe o serviço. O fornecedor,
por sua vez, é quem entrega o serviço. Dessa forma, é possível que uma determinada entidade
dentro de uma cadeia de valor do fornecimento de serviço seja tanto fornecedor quanto cliente.
Nesse caso, teremos tantos SLAs quantos forem os pares fornecedores-clientes.
Um ponto que deve ser definido no SLA é sobre quem detém a responsabilidade de serviços
terceirizados. O nível de serviço de diversos fornecedores pode estar sob a gerência de um único
fornecedor de valor agregado, caso assim seja acordado.
5.3. Métricas
"Métrica é uma forma de medida do desempenho ou
eficiência de alguma característica de um serviço ou atividade."
Ao estabelecermos o SLA, é preciso definir não apenas quais tipos de serviços serão prestados
mas também as métricas que serão utilizadas para mensurar a sua qualidade, bem como o índice
mínimo de qualidade que deve ser entregue ao cliente.
Alguns exemplos de métricas que podem ser incluídas em um SLA são:

- Percentual de tempo da disponibilidade da rede
- Percentual de tempo da disponibilidade do serviço
- Latência da rede
- Número de usuários que podem ser atendidos simultaneamente
- Padrões de desempenho com os quais os serviços serão comparados
periodicamente
- Antecedência de avisos sobre modificações na rede que possam afetar os usuários

- Tempo de resposta do "help desk" para diversas classes de problemas, tanto de
reparo quanto de reação
- Estatísticas de uso que serão fornecidas
5.4. SLA na Embratel

As métricas da Embratel
A Embratel oferece, em seu contrato de Garantia de Desempenho, três métricas para a
mensuração do nível de serviço:
• Latência média mensal da rede: É o tempo que um pacote IP leva para ir e
voltar (round-trip) de um ponto a outro da rede. É normalmente medida em
milissegundos. Quanto menor a latência, melhor o tempo de resposta da rede.
• Perda média mensal de pacotes da rede: É o índice que mede a taxa de sucesso
na transmissão de pacotes IP entre dois pontos da rede. É normalmente exibida
como uma porcentagem, indicando o percentual de pacotes perdidos. Quanto
menor a perda de pacotes, maior a eficiência da rede.
• Disponibilidade média do núcleo da rede: É o índice que mede o tempo que
uma rede esteve operacional para transmissão e recepção de pacotes IP. É
normalmente registrada como uma porcentagem, indicando o percentual de
tempo em que a rede esteve no ar. Quanto maior a disponibilidade, maior a
confiabilidade da rede.
O cálculo das métricas

Como são calculadas cada uma das três métricas utilizadas na mensuração do nível de serviço:
• Latência média mensal da rede: A cada dia do mês, durante todos os dias, são
tomadas 1440 medidas de latência entre o Centro de Gerência da Rede Internet e
todos os Centros de Roteamento da Rede Internet Via Embratel. Essas medidas
comporão uma média horária a cada 60 minutos. A média diária será calculada
em função das médias horárias a cada 24 horas e a média mensal será a média
aritmética das médias diárias do mês. Links de satélite não entram nessa medição!
• Perda média mensal de pacotes da rede: A cada dia do mês, durante todos os
dias, são tomadas 1440 medidas de perda de pacotes entre o Centro de Gerência
da Rede Internet e todos os Centros de Roteamento da Rede Internet Via
Embratel. Essas medidas comporão uma média horária a cada 60 minutos. A
média diária será calculada em função das médias horárias a cada 24 horas e a
média mensal será a média aritmética das médias diárias do mês.

• Disponibilidade média do núcleo da rede: Todos os dias, para o Business Link
Direct, são tomadas 1440 medidas de disponibilidade do Roteador de Acesso da
Rede Internet Via Embratel ao qual a porta do Cliente está especificamente
conectada. No caso do Business Link Flex e Business Link On Demand, a
referência a ser considerada é a média do conjunto de roteadores do Backbone.
Essas medidas comporão uma média horária a cada 60 minutos. A média diária
será calculada em função das médias horárias a cada 24 horas e a média mensal
será a média aritmética das médias diárias do mês.
Avaliação do desempenho
O acordo especificado na Garantia de Desempenho da Embratel define os seguintes índice:
Latência média mensal da rede não pode ultrapassar 75 ms
Perda média mensal de pacotes da rede menor que 1%
Disponibilidade média do núcleo da rede maior ou igual a 99,7%
5.5. SLA, QoS e GoS

O acordo de nível do serviço (SLA), a qualidade do serviço (QoS) e o grau do serviço (GoS)
estão intimamente relacionados. O SLA pretende alinhar as seguintes expectativas em relação ao
serviço:
- Fornecedor: qualidade que espera estar fornecendo
- Cliente: qualidade que espera estar recebendo
O grau do serviço consiste justamente nas expectativas alinhadas, no conjunto de métricas que se
pretende alcançar, ao passo que a qualidade do serviço é justamente o desempenho real do serviço
oferecido, medido através da utilização do mesmo conjunto de métricas.
Para saber mais sobre acordos de nível de serviço, sugerimos a leitura do SLA Management
Handbook, redigido pelo TeleManagement Forum.

Curso de TCPIP Avançado v.2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curso de TCPIP Avançado v.2

Transféré par

Droits d'auteur :

Formats disponibles

Curso de

Curso de TCP-IP Avançado 2 de 126

Curso de TCP-IP Avançado 3 de 126

Considera-se fundamentalmente que a obtenção de um AS para um conjunto de blocos de

Curso de TCP-IP Avançado 4 de 126

O EGP está fundamentado em três tipos de processo de comunicação:

Curso de TCP-IP Avançado 5 de 126

Independentemente do tipo de mensagem EGP que está sendo enviada, encontraremos os

Descrição das mensagens EGP

Curso de TCP-IP Avançado 6 de 126

Neighbor Hello: Solicita ao neighbor que responda se estiver 'vivo'

Informação de Poll Request: Solicita a atualização das informações de roteamento

Mensagens de Estabelecimento de Vizinhança (Neighbor

As mensagens de Neighbor Acquisition são do tipo 3 e possuem 5 subtipos identificados pelos

O cabeçalho completo deste tipo de mensagem fica, portanto, como se segue:

Curso de TCP-IP Avançado 7 de 126

Considerando a hipótese de perda de mensagens por motivos como congestionamento na rede ou

Curso de TCP-IP Avançado 8 de 126

Mensagem Poll Request

Mensagem de Routing Update

Dois tipos de listas de gateways podem ser enviadas:

Lista Interna (Interior Gateways)

Curso de TCP-IP Avançado 9 de 126

Curso de TCP-IP Avançado 10 de 126

A mensagem de Routing Update tem a seguinte estrutura:

# Interior Gateways: Número de Interior Gateways que aparecem na mensagem.

Curso de TCP-IP Avançado 11 de 126

Limitações do Protocolo EGP

1.3. Protocolo BGP

Curso de TCP-IP Avançado 12 de 126

CIDR - Classes Inter-Domain Routing

Quando usar ou não o BGP

Devemos usar o BGP quando:

Curso de TCP-IP Avançado 13 de 126

BGP OPEN Message

Curso de TCP-IP Avançado 14 de 126

BGP UPDATE Message

Mensagem BGP UPDATE

Withdrawn Routes Lengh

Curso de TCP-IP Avançado 15 de 126

Existem as seguintes categorias de atributos:

Curso de TCP-IP Avançado 16 de 126

Curso de TCP-IP Avançado 17 de 126

A informação contida no AS_PATH é uma das usadas no processo de seleção da

Um roteador BGP nunca deve anunciar como NEXT_HOP o IP do roteador de

O MED é anunciado somente entre ASs. No entanto, só o AS de origem pode

LOCAL_PREF (Local Preference)

Curso de TCP-IP Avançado 18 de 126

Um roteador que receba uma rota com o atributo ATOMIC_AGGREGATE não

Este atributo é comumente usado pelos operadores de redes para influenciar o

Curso de TCP-IP Avançado 19 de 126

Cód. Descrição Sub-códigos de erro

1 Erro no cabeçalho da mensagem Sub-código Descrição

1 Conexão não sincronizada

2 Erro na mensagem OPEN Sub-código Descrição

1 Número de versão não

3 Identificador BGP inválido

4 Parâmetro opcional não

3 Erro na mensagem UPDATE Sub-código Descrição

1 Lista de atributos mal

Curso de TCP-IP Avançado 20 de 126

4 Erro nas flags de atributos

6 Atributo origem inválido

9 Erro no atributo Opcional