NOT AS D E AULA , R EV 7.0 U ERJ 201 8 FLÁVIO ALEN CAR...

N O T A S D E A U L A , R E V 7 . 0 – U E R J 2 0 1 8 – F L Á V I O A L E N C A R D O R Ê G O B A R R O S

Redes de Comunicações 2

Infraestrutura: Roteamento e IP

Flávio Alencar do Rego Barros Universidade do Estado do Rio de Janeiro

E-mail: [email protected]

Capítulo

3

UERJ 2018 Redes de Comunicações 2 Pg.1

Cap.3 – IP e Roteamento



Elementos do Roteador



Principais Funções da Camada Rede

É bom lembrar que a camada de rede se incumbe de “acertar” a máquina destinatária,

enquanto a camada de transporte “acerta” o processo na máquina destinatária. Para

cumprir sua missão, a camada rede deve, no mínimo, fazer:

1- Encaminhamento: Move um pacote de uma entrada do roteador para a saída

conveniente. Uma tabela de encaminhamento deve ser produzida em RAM no roteador.

2- Roteamento: Determina a rota conveniente do pacote da origem até o destino.

Um algoritmo de roteamento deve ser processado no roteador e seu resultado prepara a

tabela de encaminhamento. Observe aqui que se estivéssemos falando mais

genericamente, deveríamos incluir a terceira função: o call setup. Porém, no escopo de

redes de datagramas esta função não existe (só existe em circuito virtual, em redes

ATM, que não é nosso objetivo)

Nesta seção passamos a analisar os algoritmos de roteamento.



Um argumento mais compreensível da patologia de algoritmos de roteamento

tipo vetor-distância – redes lineares – será abordado em sala de aula. Em resumo, “boas

notícias” não causam problemas, porém “más notícias” são problemáticas, com todas

consequências associadas. Enfim, aguarde a aula! O remédio para esta patologia é o

“poison reverso”, que consiste em informar corretamente em uma direção e “mentir” em

outra direção. Também os detalhes desta técnica serão vistos em sala de aula.



PPoorr qquuee ddiiffeerriirr rrootteeaammeennttoo iinnttrraa-- ee iinntteerr--SSAAss??

• Política: roteamento interdomínio é associado a políticas (que provedor devemos

selecionar/evitar, etc.). Roteamento intradomínio está contido em uma única

organização, assim, nenhuma decisão política se faz necessária.

• Escala: roteamento interdomínio oferece um nível extra de tamanho de tabela de

roteamento com a conseqüente redução de tráfego de atualização de roteamento

acima da camada intradomínio. Neste sentido, aguarde a discussão de sub-rede,

CIDR e NAT.

• Desempenho: roteamento intradomínio é focado em métricas de desempenho, o

alvo é manter o custo baixo. Em roteamento interdomínio é difícil propagar métricas

de desempenho eficientemente (latência, privacidade, etc.). Neste âmbito, políticas

relacionadas com a informação são mais significativas.

Conclusão: Necessitamos de ambos!!



Números de rede são gerenciados por uma entidade chamada ICANN (Internet

Corporation for Assigned Names and Numbers, ONG americana, mas que procura

relacionar-se com entidades em outros países), que por sua vez delega a entidades

regionais a tarefa de distribuir endereços. Atualmente o ICANN (e seus delegados) só

distribui endereços classe C, e a subdivisão dos endereços dentro de uma entidade será

assunto para abordar brevemente.

Alguns endereços são reservados. Com 32 bits iguais a zero, o emissor do pacote

se refere a sua própria rede, e seu uso é útil quando em processo de “boot”. O endereço

contendo todos os bits “1” significa a intenção de promover broadcast na rede local.

Quando se acrescentar ao endereço de rede todos os bits iguais a “1” no campo host, se

pretende fazer um broadcast remoto, ou seja, broadcast na rede de destino. Finalmente,

os endereços 127.xx.yy.zz são reservados para testes em loopback.



Em termos práticos, portanto, o campo host dá um limite superior do número de

estações que certa rede ou uma sub-rede pode utilizar. Por exemplo, Uma rede classe C

(8 bits do campo host) tem em princípio a possibilidade de conter 254 estações, ou seja,

256 endereços menos o endereço base (todos os bits do campo host iguais a “0”) e

menos o endereço de broadcast (todos os bits do campo host iguais a “1”). Mais à

frente, quando analisarmos sub-redes, nós vamos modificar ligeiramente este conceito.



O problema com a atribuição de um endereço de qualquer das três classes A, B

ou C é que ele se refere a uma LAN. Muitas instituições, no entanto, mantêm não uma,

mas uma coleção de LANs.

Uma solução é dividir o espaço de endereçamento de hosts em dois: um para identificar

sub-redes, outro para identificar os hosts propriamente ditos. Para implementar um

sistema de sub-redes, o roteador principal precisa de uma máscara de sub-rede. Duas

notações alternativas são usadas para exprimir a máscara. Por exemplo, seja um

endereço classe B onde se queira dividir 64 sub-redes para uma mesma corporação.

Nestes termos, tanto pode ser usada a máscara 255.255.252.0 quanto o sufixo

x.x.x.x/22, significando que a máscara de sub-rede tem tamanho de 22 bits.

Definida desta maneira, o potencial máximo de estações em uma sub-rede modifica

ligeiramente. Supondo uma rede classe C corporativa onde se dividiu 8 sub-redes (3 bits

no campo host original), o potencial máximo de estações por sub-rede passa a ser de 30

estações, resultado de 32 endereços possíveis (com os 5 bits restantes) menos o

endereço base e o endereço de broadcast.

Roteamento InterDomínio Sem Classe



Um roteador precisa lidar com endereços de rede (24 bits para classe C) e isto

pode tornar a tabela de roteamento muito grande. Para reduzir este armazenamento foi

criado o CIDR (Classless InterDomain Routing) cuja idéia é alocar os endereços IP

ainda não atribuídos em blocos de tamanho variável, sem considerar classes. Se um site

necessita 2000 endereços, lhe é atribuído um bloco de 2048 endereços, e assim por

diante. Por exemplo, se um ISP conecta 8 organizações com endereços CIDR, incluindo

este site mencionado, o ISP anuncia ao mundo exterior o endereço 200.23.16.0/21. O

resto do mundo não precisa saber que lá dentro, na verdade, existem 8 organizações.

Chama-se isto de agregação de endereços, que funciona bem se os endereços são

alocados em blocos contíguos. Os novos roteadores são projetados para lidar com

algoritmos que tratam endereços CIDR em hardware.



Voltemos agora a analisar formas de se obter um endereço IP de host. Isto pode

ser feito por configuração manual ou de uma forma dinâmica com DHCP. Esta última

forma adquiriu importância por causa da computação móvel, ela é ideal para usuários

em trânsito utilizando endereços temporariamente.



Passemos agora a analisar formas práticas de lidar com o endereçamento e sua

alocação. Elas são as redes privadas virtuais (VPN) e os tradutores de endereços de

redes (NAT).

Rede Privada Virtual (VPN)

Esta é outra forma de lidar com endereços.

No exemplo do slide 03-62 o envio de host da rede 128.10.2.0 para host da rede

128.210.0.0 segue os passos:

1) Emissor encaminha datagrama original para R2

2) R2 encaminha para R1

3) R1 criptografa datagrama na área de dados do datagrama externo

4) R1 envia datagrama externo (túnel) a R3 via ISP

5) R3 recebe, reconhece como tunelado de R1

6) R3 decriptografa área de dados e recupera datagrama original

7) R3 encaminha datagrama para R4 para distribuição.



Este procedimento pode ser estendido para hosts individuais. Portanto, VPN oferece

a uma corporação as mesmas opções de endereçamento de uma rede privada, porém,

diferente desta, de mais baixo custo.

Translação de Endereços de Rede (NAT)

A necessidade que se impôs de termos uma Internet completa dentro de uma corporação

acabou por tornar de fato um padrão que rigorosamente viola os princípios de redes de

computadores: o NAT.

O banco de IPs dinâmicos mantidos por ISPs trabalha bem para clientes

domésticos que fazem uso eventual da Internet. O mesmo não acontece para clientes

corporativos que precisam manter-se on-line durante horas. Mesmo para clientes

domésticos que estão aderindo a tecnologias ADSL e cabo, o mesmo problema também

aparece. A solução definitiva para a escassez de endereços IP virá com a adoção do



IPv6 de 128 bits, mas até chegarmos lá vai ser demorado. NAT (Network Address

Translation, RFC 3022) é uma solução de curto termo para isto.

A idéia por trás do NAT é que cada companhia tenha um único endereço IP para

tráfego Internet, mas dentro da companhia cada computador tenha um único endereço

(da forma 10.x.y.z) para roteamento no interior dela. Quando um pacote sai da

companhia e vai para o ISP acontece uma translação de endereço. O NAT converte o

endereço interno no endereço geral externo, como mostra o slide 03-64. O problema

será a resposta que chega de volta, como se deve imaginar. O NAT resolve a seleção do

destinatário certo dentro da rede em questão através do uso do endereço de porta (UDP

ou TCP) que identifica univocamente o destinatário. Sempre que um pacote de saída

entra no NAT ele é substituído pelo IP padrão e a porta fonte de 16 bits (TCP ou UDP)

é substituída por um índice dentro de uma tabela (de 64K registros) de translação no

NAT. Quando um pacote chega do ISP, a porta fonte do TCP é extraída para indexar

aquela tabela que conterá o endereço interno de destino (e o endereço fonte TCP interno

de destino), 10.x.y.z. Este esquema recebe várias críticas (você faça uma!), mas

funciona! Trata-se de uma solução de espera (de curto termo) do IPv6. Observe que

com o uso da porta (16 bits) são possíveis 60.000 conexões simultâneas com um único

endereço do lado WAN! Por outro lado, NAT é controverso por que:

a) roteadores deveriam processar apenas até a camada 3;

b) viola o argumento fim-a-fim, portanto, a possibilidade de NAT deve ser levada

em conta pelos projetistas de aplicações como o caso peer-to-peer.

c) A escassez de endereços seria resolvida com IPv6.



(Material de apoio: Uma análise do Skype – skype-schulzerinne.pdf)

Formato do IP



Características:

- Apresenta dois níveis de hierarquia: área local e backbone

- Mensagens “advertisements” e de “link state” não navegam além das respectivas áreas

- Os nós em cada área conhecem detalhes da sua própria topologia, eles conhecem

somente direções (caminho mais curto) para redes em outras áreas

- Os roteadores de borda de área (em vermelho na figura) sumarizam distâncias para

redes na área e as informa para outros roteadores de borda de área

- Os roteadores de backbone (cinza, vermelho e azul) rodam um algoritmo de

roteamento OSPF limitado ao backbone

Os roteadores limite ou de fronteira (azuis) conectam a outros SAs. Estes veremos

mais adiante.



Cada Gateway de fronteira difunde (por broadcast) para seus vizinhos

(parceiros) o caminho completo (isto é, seqüências de SAs, chamaremos AS-PATH)

para o destino. Por exemplo, o Gwy X pode armazenar o seguinte caminho para o

destino Z: caminho (X,Z) – X, Y1, Y2, Y3, ... , Z

Suponha agora que Gwy X envia seu caminho para Gwy W . Este pode ou não

selecionar o caminho oferecido por Gwy X, então:

caminho (W,Z) = w, caminho (X,Z)

Observe que a seleção do caminho não é apenas baseada em custo (por exemplo, o

número de hops SA), mas, principalmente, por questões políticas e administrativas (por

exemplo, decisão de não rotear pacotes através de SAs competidores). Veremos a seguir

isto com maiores detalhes.

O mecanismo BGP apresenta as seguintes características:

- os parceiros (“peers”) trocam mensagens BGP usando TCP;

- a mensagem OPEN abre conexão TCP para parceiro e autentica o emissor;

- a mensagem UPDATE anuncia novo caminho (ou retira velho);

- a mensagem KEEPALIVE mantém conexão viva na ausência de mensagens

UPDATE. Ela também serve como reconhecimento (ACK) para um pedido OPEN;

-a mensagem NOTIFICATION reporta erros na mensagem anterior e também é usada

para fechar uma conexão.



Observe que BGP ajuda a tornar as redes escaláveis, pois o número de nós que

participam do BGP é aproximadamente igual ao número de sistemas autônomos (só

participa gateway de fronteira), portanto, muito menor que o número de redes. Portanto,

para qualquer roteador de um domínio, todo trabalho é tão somente encontrar uma boa

rota para o seu respectivo roteador de borda. Mas este trabalho pode não ser tão trivial

assim, como veremos a seguir.



A motivação inicial da mudança no IP vem da previsão de que o espaço de

endereços de 32 bits estaria totalmente ocupado até, no máximo, 2008. Acrescente-se a

oportunidade propiciada pela mudança de IP oferecerá processamento mais rápido e

suporte a serviços diferenciados. Em resumo, isto aconteceu com o IPv6, o formato do

pacote se tornou mais simples, com um cabeçalho fixo de 40 bytes mais algumas

opções. Os campos fixados do cabeçalho são:

Versão: indica agora IPv6

Prioridade: 4 bits. O objetivo é dar prioridade a certos pacotes dentro de um fluxo. São

estabelecidos valores de 0 a 7 para tráfego com congestionamento controlado, enquanto

valores de 8 a 15 destinam-se a outros tráfegos (por exemplo, tráfego de bit rate

constante)

Rótulo de fluxo: destinado a apoiar serviços diferenciados baseado em fluxos. Um

fluxo não é definido na proposta IPv6, mas pode ser entendido como o tráfego de

usuário que paga mais por ele, tráfego de tempo real, etc., caracterizado pelo tratamento

similar de seus pacotes



Tamanho do payload: valor de 16 bits identificando o número de bytes seguindo os 40

bytes do cabeçalho IPv6

Próximo cabeçalho: similar ao campo PPrroottooccoolloo no IPv4, identifica o protocolo da

camada superior (TCP ou UDP ou ?)

Limite de Hop: o mesmo que TTL, ainda um byte

Endereços Fonte e Destino: 128 bits, com uma nova estrutura hierárquica (endereços

podem implicar localização geográfica, diferente de IPv4); inclui novos tipos de

endereços como anycast, que entrega para um dentre certo número de destinatários.

Alocação de Espaços de Endereços:

Mais um proveito que se pode tirar da imensa disponibilidade de códigos em

IPv6 é a forma de alocar endereços. Endereços IPv6 não apresentam classes, mas o

espaço de endereços é subdividido de várias maneiras, segundo seus bits iniciais

(prefixo), da seguinte forma:

Prefixo Uso

0000 0000 Reservado

0000 0001 Não atribuído

0000 001 Reservados para alocação NSAP

0000 010 Reservados para alocação IPX



0001 Não atribuído

001 Endereços unicast globais agregados

010 Não atribuído

011 Não atribuído

100 Não atribuído

101 Não atribuído

110 Não atribuído

1110 Não atribuído




1111 1110 0 Não atribuído

1111 1110 10 Endereços de uso local do enlace

1111 1110 11 Endereços de uso local do site

1111 1111 Endereços de multicast



A funcionalidade completa das classes IPv4 é coberta com o prefixo 001.

Endereços NSAP são usados por protocolos ISO e endereços IPX pelo protocolo da

camada de rede da Novell. O “uso local do enlace” significa que um host pode construir

um endereço que funcione na rede local à qual está ligado sem preocupações com a

exclusividade global do endereço. Da mesma forma, endereços “uso local do site”

permitem que uma rede corporativa privada possa usar endereços globais internamente,

desde que não esteja conectada à Internet maior. Em uma palavra, são prefixos que

permitem a mesma funcionalidade do NAT. Dentre os endereços reservados (prefixo

0000 0000), um host ou roteador pode receber um endereço IPv6 compatível com IPv4

completando com zeros um endereço IPv4 de 32 bits. Um host ou roteador que só é

capaz de entender IPv4 pode receber um “endereço IPv6 mapeado para IPv4” iniciando

o endereço IPv4 de 32 bits com 2 bytes de 1s e depois estendendo com zeros até

completar 128 bits. Isto servirá para a transição IPv4-IPv6 que detalharemos a seguir.



Fragmentação: não é mais oferecida em IPv6. O roteador que tenha um pacote maior

que o máximo admitido em um próximo hop descarta este pacote, e envia uma

mensagem ICMPv6 “Packet Too Big” para a fonte do pacote. O resultado é

claro: reduz o tempo de processamento de pacotes.

Checksum: inteiramente retirado para reduzir o tempo de processamento em cada hop.

Options: são admitidas opções, indicadas pelo campo “Next Header”. O conteúdo deste

campo indica o protocolo de mais alto nível ou a existência de uma opção após

os 40 bytes do cabeçalho IPv6.

ICMPv6: nova versão do ICMP, com tipos adicionais de mensagens, por exemplo,

“Packet Too Big”, função de gerência de grupo multicast, etc.



Multicast:

Ao invés da comunicação tradicional unicast, a comunicação multicast envolve

mandar pacotes em direção a um grupo inscrito em um endereço classe D. Os receptores

sintonizados naquele endereço classe D não precisam conhecer os outros parceiros de

recepção, nem mesmo o emissor. Este nem sequer precisa fazer parte do grupo. Em uma

palavra, o multicast “esconde” a topologia física.

O modelo multicast IP, também conhecido como modelo de Deering, tem mais que 10

anos, e é:

- simples: acesso ao grupo classe D

- escalável: aceita heterogeneidade de emissores e receptores

- elegante: é baseado no anonimato da fonte e dos receptores

eficiente: múltiplos receptores atendidos por um único pacote



É importante observar que as regras da camada de rede têm que ser modificadas

para suportar multicast. Primeiro, o hardware dos roteadores deve estar apto para

“clonar” pacotes, naturalmente o software também, vale dizer, os protocolos de

roteamento para multicast são diferentes dos protocolos para unicast. Segundo, passa a

ser possível um host da Internet ter mais que um endereço IP a cada momento (apenas

um endereço unicast, número indefinido de endereços multicast). Por estas razões existe

uma classe específica (classe D) para multicast.

Lembre-se que para unicast o protocolo ICMP era mero coadjuvante, só servia

para informações e suporte das transações. Agora não, o seu equivalente para multicast,

IGMP, tem papel essencial no início (e no final) de associação na árvore de distribuição

multicast.



São duas as estratégias para construir a árvore de distribuição multicast: Baseada

em fonte e compartilhada. Cada uma destas estratégias resulta em uma série de

protocolos propostos. A idéia subjacente a cada uma delas é desenvolvida a seguir.



Na árvore compartilhada o core (ou núcleo) é pré-definido para cada grupo

multicast (por exemplo, via página Web, ou qualquer outro mecanismo “fora de

banda”). Novos membros da sessão se associam a partir de mensagens IGMP “join” (se

desassociam com mensagens IGMP “leave”) realizada no âmbito local entre o host e o

roteador local. A partir de um pedido de associação, o roteador se incumbe de enviar

mensagem de pedido de “enxerto” na árvore mandando a mensagem em direção ao

core. O primeiro roteador no caminho da mensagem de “join” se incumbirá de

responder ao solicitante e informar o core, garantindo o enxerto do novo ramo na

árvore. Um procedimento dual para "poda" na árvore acontece quando um roteador

descobre não ter mais estações “clientes” do grupo multicast. Quanto ao emissor, este

descobre o core da sessão multicast, a partir daí transmite todos seus dados da sessão

para este core, e caberá a este (e não o emissor!) promover a distribuição dos dados

através da árvore multicast.

A árvore baseada na fonte apresenta funcionalidade parecida, apenas as

funções de fonte e de núcleo da árvore ficarão concentradas no roteador associado à



fonte emissora. Pacotes são entregues na árvore usando o algoritmo RPF (Reverse Path

Forwarding), isto é, um roteador aceita um pacote originado na fonte somente se tal

pacote é encaminhado pelo vizinho no menor caminho em direção à fonte.

Vejamos agora os principais representantes (protocolos) de cada uma destas

estratégias de construção de árvores de distribuição multicast. Preliminarmente observe

que o IGMP é o protocolo inicial para associação em uma ou outra estratégia de árvore

de distribuição.



Como já mencionamos, o modelo multicast IP é composto pelo modelo de grupo

de estações (implementado via IGMP) e pelo(s) protocolo(s) de roteamento

especial(ais). Pelas mesmas razões já apontadas para unicast, são na realidade dois

protocolos envolvidos:

Protocolos intradomínio: DVMRP, PIM-DM, PIM-SM, CBT (Core-Based Tree),

MOSPF (Multicast Extensions to OSPF) e outros;

Protocolo interdomínio: A solução atual, considerada de curto termo é o protocolo

MSDP (Multicast Source Discovery Protocol).



Mesmo sendo o modelo de Deering de multicast admitido como padrão na

Internet, ele sempre sofreu críticas:

- os protocolos são muitos e são também complexos, o que está na contramão do

modelo unicast que é um exemplo de modelo vencedor. O slide 03-107 ilustra isto.

- falta inteligência dentro da rede, perdendo-se com isto oportunidades de um controle

mais efetivo do tráfego circulante.

- existem problemas de endereçabilidade, sendo possível colisão de endereços e não

sendo possível a organização do grupo por preferências de dados numa certa sessão.

- persistem problemas de funcionalidade, sendo difícil (por causa do anonimato)

gerência de contabilização (e tarifação!), proteção a ataques e geração de tráfego inútil.

- A forma mais popular de árvore de distribuição multicast, a árvore compartilhada,

apresenta o problema de dependência de terceiros (imagine uma fonte em um domínio e

o grupo de receptores em outro, e um core colocado num terceiro domínio)

Por conta destas críticas, novas propostas têm sido feitas, uma delas se tornou o

desenvolvimento “oficial” deste modelo, mas este também tem sido contestado.

Convido-o a verificar estes novos padrões em: “Are alterations needed to the IP



multicast service model?”, F. A. R. Barros, M. A. Stanton, Revista do JBCS, 2003

(arquivo jbcs03.pdf).

Material de apoio:

Uma análise do Skype – skype-schulzerinne.pdf

Uma análise do multicast IP: jbcs03.pdf

NOT AS D E AULA , R EV 7.0 U ERJ 201 8 FLÁVIO ALEN CAR...

Documents

Transcript of NOT AS D E AULA , R EV 7.0 U ERJ 201 8 FLÁVIO ALEN CAR...