IP sobre ATM
Razões para ter-se IP sobre ATM
• O IP é o padrão predominante nas redes de
dados.
• O ATM oferece qualidade de serviço e
permite a implementação de comutadores
de alta capacidade a um custo menor.
• O ATM está se tornando realidade no
backbone das operadoras de Telecom
Diferenças entre o IP e o ATM
• IP é não-orientado a conexão, enquanto o
ATM é orientado a conexão
• Os formatos de endereçamento são
distintos.
• Os algoritmos de roteamento são distintos.
• O ATM possuí sinalização para o
estabelecimento da conexão, enquanto o IP
não possuí.
Modelos para Interconexão
• Modelo Overlay
• Modelo Peer
Modelo Overlay
• As estações IP tem uma visão opaca da
nuvem ATM
• Necessidade de mapeamento de endereço IP
em endereço ATM
• Duplicidade de funções nas duas redes
No modelo Overlay os nós na borda, que pertencem à mesma sub-rede lógica, vêm a nuvem ATM como uma estrutura de enlace através da qual todos os nós são vizinhos entre si, ou seja, os nós encontram-se à distância de um hop uns dos outros.
O processo de mapeamento do endereço IP em endereço ATM exige a
utilização de servidores especializados, uma vez que a rede ATM não possui a facilidade de broadcast e, portanto, não permite a utilização de soluções como o ARP utilizado para mapeamento de endereço IP em endereço MAC
Modelo Peer
• Utiliza-se, dentro da rede ATM, da mesma
estrutura de endereços e roteamento da
camada de rede.
• Os comutadores ATM tornam-se roteadores
IP, e os roteadores de borda não são mais
vizinhos entre si.
• Elimina a duplicidade de funções presente
no modelo overlay
Soluções para IP sobre ATM
• Classical IP over ATM (IETF)
• Lan Emulation - LANE (ATM-Fórum)
• Multiprotocol over ATM - MPOA (
ATM-Fórum)
• Multiprotocol Label Switching - MPLS
(IETF)
Classical IP over ATM
• Definido na RFC 2225 (anteriormente pelas
RFCs 1577 e 1626)
• Utiliza o modelo overlay
• Utiliza o encapsulamento LLC/SNAP (RFC
1483)
• Operação similar a IP sobre Ethernet,
utilizando-se o protocolo ATMARP e um
servidor de resolução de endereços
O modelo clássico foi definido originalmente pela RFC 1577 e atualizado posteriormente pela RFC 1626, estando hoje em vigência a RFC 2225.
A rede IP está sobreposta à rede ATM, mantendo-se inalterado os
procedimentos de roteamento do IP. A vantagem oferecida por esta abordagem está em se aproveitar a familiaridade que os operadores de rede possuem com a arquitetura IP, além de se permitir a utilização de Firewalls (que operam no nível de rede) para aumentar a segurança.
Os datagramas são transportados em células ATM, utilizando-se a camada AAL5 para adaptação.
O protocolo de resolução de endereço é o ATMARP (similar ao ARP), sendo necessária a presença de um servidor especial, uma vez que a rede ATM não permite o broadcast.
O modelo clássico pode resultar em ineficiência, devido ao processo de segmentação e remontagem dos datagramas em cada roteador ao longo do caminho do datagrama.
Multiprotocol Encapsulation over
ATM AAL 5
• Vários protocolos sobre o mesmo VCC
• Protocolo transportado é especificado
através de um cabeçalho LLC (Logical Link
Control) seguido de um cabeçalho SNAP
(Subnetwork Attachment Point), que é
anexado à SDU a ser transportada.
O encapsulamento utilizado é definido pela RFC 1483 ( Multiprotocol Encapsulation over ATM Adaptation Layer 5).
O modo de encapsulamento LLC/SNAP permite que vários protocolos possam ser transportados sobre o mesmo VCC.
Um mecanismo para identificação do protocolo que está sendo transportado deve ser criado: inclusão de um cabeçalho anexado ao pacote de dados a ser transportado.
Encapsulamento LLC/SNAP
• O valor 0xAA-AA-03 no cabeçalho LLC indica a presença do cabeçalho SNAP
• O valor 0x00-00-00 no campo OUI (Organizationally Unique Identifier) do cabeçalho SNAP indica um protocolo do tipo Ethertype no campo PID (Protocol Identifier).
• O valor 0x08-00 no campo PID do tipo EtherType indica o protocolo IP
LLC 0xAA-AA-03 3 bytes OUI 0x00-00-00 PID 0x08-00 Datagrama IP SNAP = 3 + 2 bytes
Sub-redes lógicas
A nuvem ATM pode ser constituída de uma ou mais LIS (Logical IP Subnet). As LIS constituem redes IP independentes, interconectadas através de
roteador.
No modelo clássico dispositivos pertencentes a LIS distintas não podem se comunicar diretamente, mesmo que estejam conectados à mesma rede ATM. A comunicação entre estes dispositivos se dá através de roteadores.
Os dispositivos pertencentes à mesma LIS podem estabelecer circuitos virtuais ATM para troca de datagramas IP entre si.
Sub-redes IP Lógicas
Nuvem ATM LIS 1 LIS 2 LIS 2 LIS 1 LIS 1,2A separação entre LISs é lógica, e não física. Estações próximas
geograficamente podem pertencer a LISs distintas, enquanto estações distantes podem pertencer à mesma LIS. De qualquer forma, a comunicação entre LISs se dá através de roteadores.
Problema com o modelo overlay
LIS 1
LIS 2
Resolução de endereço IP-ATM
• Utiliza-se o protocolo ATMARP
• Utiliza-se um servidor ATMARP que
Protocolo ATMARP
O campo Hardware Type indica o uso do ATM (0x0013), enquanto o campo Protocol Type indica o uso do IP (0x0800).
O campo Operation define os tipos de mensagem ATMARP: 1 (decimal) = ATMARP_Request
2 = ATMARP_Reply 8 = InATMARP_Request 9 = InATMARP_Reply 10 = ATMARP_NAK
Mensagens ATMARP
• ATMARP_Request
• ATMARP_Reply
• InATMARP_Request
• InATMARP_Reply
• ATMARP_NAK
A mensagem ATMARP_Request é enviada pela estação ao servidor ATMARP solicitando a resolução de um endereço IP em um endereço ATM. A
mensagem ATMARP_Reply é a resposta enviada pelo servidor à mensagem ATMARP_Request.
As mensagens InATMARP_Request e InATMARP_Reply são utilizadas para se descobrir os endereços IP e ATM de um dispositivo conectado na
extremidade de um circuito virtual já estabelecido (exemplo: PVC).
As mensagens ATMARP devem ser transportadas em uma PDU da camada de adaptação AAL5 usando encapsulamento LLC/SNAP.
Servidor ATMARP
• Um para cada LIS.
• As estações devem se conectar ao servidor e
informar seus endereços IP e ATM
(InATMARP).
• Servidor mantém tabela cache com os
endereços IP e ATM das estações de sua
LIS.
As estações da rede devem se conectar ao servidor ATMARP. Para tal, deve existir um PVC pré-configurado ou a estação deve possuir o endereço ATM do servidor armazenado em disco.
Através de uma troca de mensagens InATMARP, o servidor descobre os endereços IP e ATM da estação, e os armazena em cache.
Cada entrada do cache do servidor tem duração de 20 minutos. Decorrido este tempo, se ainda houver uma conexão entre o servidor e a estação, uma nova troca de mensagens InATMARP é feita no sentido de revalidar o cache, caso contrário, a entrada do cache é descartada. O temporizador de 20 minutos é reinicializado toda vez que o servidor recebe uma requisição ATMARP da estação associada à entrada em questão; ou seja, o recebimento de uma mensagem ATMARP_Request de uma dada estação revalida a entrada do cache associado a esta estação.
Um mesmo servidor (físico) pode atender a várias LISs, desde que se tenha um endereço IP para cada LIS. Ou seja, pode-se ter diversos servidores lógicos em um único servidor físico.
Resolução de endereço
ATM ARP_ Request ATM ARP_ Reply SVC IP_Aa ATM_A IP_Ab ATM_B Cache LISNo exemplo mostrado a estação A deseja transmitir uma mensagem para a estação B, da qual ela conhece o endereço IP mas não conhece o endereço ATM. As estações A e B já estão registradas no servidor ATMARP. A estação A possui endereços IP_Aa (net_id A e host_id a) e ATM_A, e a estação B possui endereços IP_Ab e ATM_B. Os seguintes passos ocorrem:
1) Estação A envia um ATMARP_Request para o servidor solicitando o endereço ATM associado ao endereço IP da estação B (IP_Ab). 2) O servidor consulta sua tabela cache e verifica que o endereço ATM associado ao endereço IP_Ab é ATM_B.
3) O servidor envia um ATMARP_Reply à estação A informando o endereço ATM da estação B (ATM_B). Caso o servidor não conheça o endereço ATM associado ao endereço IP_Ab, a resposta será uma mensagem ATMARP_NAK.
4) A estação A estabelece um SVC com a estação B e passa a trocar dados diretamente com esta estação.
5) A estação A armazena em cache a associação IP_Ab - ATM_B, para uso posterior. Cada entrada de cache da estação tem validade de 15 minutos, após os quais a entrada deve ser revalidada ou apagada.
Operação com PVC
InATMARP_Request InATMARP_Reply PVC LIS A BEm uma rede que suporta apenas PVCs, os mesmos são pré-configurados pelo administrador da rede, manualmente ou através de procedimentos de gerencia.
Um dispositivo conectado à extremidade de um PVC pode conhecer os endereços do dispositivo da outra extremidade (por exemplo, os endereços estão armazenados em disco). Caso contrário, as mensagens InATMARP são utilizadas.
No exemplo a estação A não conhece os endereços da estação B, e envia a esta uma mensagem InATMARP_Request. Em resposta, a estação B envia um InATMARP_Reply, que contém seus endereços IP e ATM. Após a troca de
Lan Emulation LANE
-Objetivos
• Introduzir o ATM no ambiente das redes
locais sem alterar os protocolos existentes,
preservando portanto o investimento já
realizado.
• Tornar a existência do backbone ATM
transparente para as aplicações Ethernet.
LANE - Dificuldades
• ATM é orientado a conexão, Ethernet não.
• ATM não suporta broadcast, que é utilizado
frequentemente pelo Ethernet
• Resolução de endereços MAC e ATM
• LAN não suporta QoS.
LANE - Tipos de LAN
• Ethernet, Token Ring, etc.
• Não permite conexão entre LANs distintas.
• Uma ou mais LANs emuladas podem
coexistir numa mesma rede ATM, mas a
comunicação entre elas só é possível através
de roteadores ou mecanismos que estendam
o serviço de LANE (ex.: MPOA)
O serviço de LAN emulada permite a emulação dos diversos tipos de redes locais existentes. No entanto, o serviço de LAN emulada não faz conversão de protocolo, não permitindo a conexão direta de uma rede Ethernet com uma rede Token Ring através do backbone ATM, mesmo que ambas as redes pertençam à mesma LAN emulada.
LANE - Ambiente
ATM LAN legada LAN legada Estação ATM Estação ATMO cenário mostra redes Ethernet interligadas através de um backbone ATM, ao qual estão conectadas algumas estações ATM.
É possível troca de mensagens entre estações Ethernet, entre estações ATM, e entre uma estação Ethernet e uma estação ATM.
Tem-se um único domínio de broadcast em toda a estrutura, mas domínios de colisão distintos.
LANEs distintas interconectadas
ATM LAN legada LAN legada Estação ATM LANE 1 LANE 1 LANE 1 LANE 2 LANE 2 LANE 2 LANEs 1 e 2A figura mostra um cenário onde tem-se duas LANs emuladas coexistindo em uma mesma rede ATM. A comunicação entre dispositivos das LANs emuladas distintas só pode se dar através do roteador.
Veremos, posteriormente, que a solução MPOA permite a criação de um atalho na rede ATM para comunicação entre LANEs distintas, estendendo o serviço de LAN emulada.
Componentes da LANE
• Lan Emulation Client - LEC
• Serviço de LAN emulada, composto de:
– Lan Emulation Server - LES
– Lan Emulation Configuration Server - LECS
– Broadcast and Unknown Server - BUS
Lan Emulation Client: Qualquer dispositivo ATM que deseje utilizar os serviços da rede legada (Ethernet) deve ter um LEC. São exemplos de LECs: estação ATM conectada diretamente ao backbone, e Proxy LEC, LAN switch ou bridge, servindo de interface entre o ambiente Ethernet e o ambiente ATM.
O Proxy LEC registra os endereços MAC das estações para as quais ele atua como procurador (uma estação Ethernet normal não pode ser um LEC). O Proxy LEC pode também registrar apenas a informação de que atua como Proxy, sem registrar os endereços de suas estações Ethernet.
Cada LEC possui um único endereço ATM, e pode estar associado a um único endereço MAC (LEC é uma estação ATM) ou a vários endereços MAC (LEC é um switch atuando como proxy).
Componentes da LANE
LECS LAN legada LAN legada Estação ATM LECs LES BUS Proxy Proxy ATMO serviço de LAN emulada é oferecido através dos servidores LES, LECS e BUS, que podem residir no mesmo dispositivo (estação ou switch).
A função básica do LECS é associar um cliente (LEC) à LAN emulada correspondente. Existe um LECs por domínio administrativo, que serve todas as LANs emuladas.
O LES controla a adesão dos clientes (LECs) e provê o serviço de resolução de endereço MAC em endereço ATM. Existe um LES para cada LAN emulada.
Interfaces do serviço de LANE
LEC LEC LECS LES BUS LECS LES BUSServiço de LANE Serviço de LANE
LUNI
LNNI
LUNI = Lan Emulation User to Network Interface LNNI = Lan Emulation Network to Network Interface
A interface LUNI é utilizada para a comunicação entre os clientes e os servidores do serviço de LAN emulada. Os seguintes passos podem ser identificados no processo de comunicação:
1) Inicialização: obtenção do endereço ATM dos servidores de LAN emulada.
2) Registro: registro nos servidores dos endereços (MAC e ATM) dos clientes de LAN emuladada.
3) Resolução de endereço: processo de descoberta do endereço ATM de um cliente (LEC), a partir do seu endereço MAC.
4) Transferência de dados: troca de mensagens entre LECs, através de uma conexão ATM.
A interface LNNI define a interoperabilidade entre servidores no ambiente da LAN emulada. Esta interface foi especificada na versão 2.0 do LANE, que prevê a utilização de múltiplos servidores LES, LECS e BUS, com o objetivo de aumentar a confiabilidade e o desempenho (eliminação de gargalos) do sistema.
Tipos de conexões
LECS LES BUS LEC LEC VCC direto de configuração VCC direto de controle VCC distribuído de controle VCC direto de dados VCC de envio de multicast VCC de reenvio de multicast LUNI Estação BridgeOs seguintes tipos de conexões são especificados para a LANE V1.0:
CONEXÕES DE CONTROLE: interligam os LECs ao LECS e LES. Transportam quadros LE_ARP e quadros de controle; nunca transportam quadros de dados. Os VCCs de controle são estabelecidos como parte da fase de inicialização. Se classificam em VCC direto de configuração, VCC direto de controle e VCC de distribuição de controle (opcional).
CONEXÕES DE DADOS: interligam os LECs entre si e ao BUS.
Transportam quadros MAC (IEEE 802.3 ou 802.5) e mensagens de Flush. Não transportam qualquer outra mensagem de controle além da mensagem de
Funções do serviço de LAN
Emulada
• Inicialização e Registro
• Resolução de endereço
• Gerenciamento da conexão
• Transferência de dados
• Ordenação de quadros
INICIALIZAÇÃO e REGISTRO: Esta função engloba todos os passos, desde o estado inicial até o momento em que o LEC torna-se operacional. Nestes passos os clientes se juntam à LAN emulada, estabelecem suas conexões de controle e dados com os servidores (LECS, LES e BUS), e registram seus endereços. Um cliente pode registrar todos os endereços MAC para os quais ele é responsável ou pode se registrar como um Proxy.
RESOLUÇÃO DE ENDEREÇO: Procedimento pelo qual um cliente associa um endereço MAC a um endereço ATM. Um LEC utiliza este procedimento para descobrir o endereço ATM de outros LECs ou do BUS.
GERENCIAMENTO DA CONEXÃO: Esta função diz respeito ao
estabelecimento e manutenção das conexões ATM dentro da rede, para fins de controle e troca de dados. As conexões ATM são criadas utilizando-se a sinalização UNI.
TRANSFERÊNCIA DOS DADOS: Os dados unicast podem ser enviados diretamente de um cliente para outro ou, opcionalmente, pelo BUS, se a conexão entre clientes ainda não está estabelecida. Dados multicast ou broadcast são enviados através do BUS.
ORDENAÇÃO DE QUADROS: A possibilidade de enviar quadros de dados por caminhos distintos (mesmo que não simultaneamente) pode fazer com que os quadros cheguem fora de ordem ao destino. O protocolo Flush é utilizado
Inicialização e Registro
Estado Inicial Conexão ao LECS Configuração Associação Registro Inicial Conexão ao BUS OperacionalPerda da conexão com o BUS Outras falhas
As operações de inicialização e registro englobam diversos passos, a seguir descritos:
CONEXÃO AO LECS: O cliente (LEC) estabelece conexão com o LECS.
CONFIGURAÇÃO: LECS informa ao cliente dados básicos referentes à sua LAN emulada.
ASSOCIAÇÃO: nesta fase o LEC estabelece sua conexão de controle com o LES e envia uma mensagem de associação à LAN emulada. Se o LES aceitar a associação, um LECID (LE Client Identifier) é fornecido ao cliente de LAN
Operação da LANE
Conexão ao LECS e configuração
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LECS LE_Configure_ Request LE_Configure_Response
CONEXÃO AO LECS: O cliente descobre o endereço do LECS e estabelece uma conexão com o mesmo. O endereço do LECS pode ser obtido de três formas:
- do comutador ATM ao qual o cliente está conectado, via procedimento ILMI ( Interim Link Management Interface);
- utilizando-se um endereço bem-conhecido fixado pelo ATM-Fórum. - utilizando-se um PVC bem-conhecido (VPI = 0 e VCI = 17).
CONFIGURAÇÃO: O LEC envia uma mensagem de Requisição de
Configuração (LE_Configure_Request), especificando seu endereço ATM e, caso a solicitação de configuração tenha sucesso, recebe uma mensagem de resposta (LE_Configure_Response) que contém, dentre outros, os seguintes parâmetros de configuração: tipo de LAN (Ethernet ou Token Ring); tamanho máximo do campo de dados para os quadros MAC; nome da LAN emulada; endereço ATM do LES associado.
Operação da LANE
Associação
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LE_ Join _Request LE_ Join _Response LECS CacheO LEC se conecta ao LES e envia uma mensagem de requisição de associação (LE_Join_Request) a uma dada LAN emulada, informando seus endereços ATM e MAC (ou a informação de que vai atuar como Proxy).
O LES salva no cache o par de endereços MAC-ATM do cliente que está se associando.
O LES envia uma mensagen LE_Join_Response ao LEC aceitando-o (ou não) na LAN emulada. A resposta pode ser enviada através do VCC direto de controle ou do VCC distribuído de controle.
Operação da LANE
Registro
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LE_ Register _Request LE_ Register _Response LECS CacheApós a associação à LAN emulada o LEC pode registrar outros endereços MAC associados a seu endereço ATM (ex.: ponte transparente que vai aprendendo outros endereços MAC).
O LES salva no cache os pares de endereços MAC-ATM registrados pelo LEC.
Um cliente LEC com um único endereço MAC não precisa utilizar o protocolo de registro, uma vez que todo cliente LEC registra implicitamente um
endereço MAC durante a fase de associação. Note que fazer uma associação com um endereço MAC é funcionalmente equivalente a fazer uma associação sem endereço MAC e fazer um registro com um endereço MAC.
Operação da LANE
Conexão ao BUS
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LE_ARP_ Request LE_ARP_Response LECS VCCPara se conectar ao BUS o LEC deve primeiro descobrir seu endereço ATM. Para tal, o LEC envia uma mensagem de resolução do endereço de broadcast (FFFFFFFFFFFF) ao LES (LE_ARP_Request). O LES retorna uma mensagem LE_ARP_Response contendo o endereço ATM do BUS.
De posse do endereço ATM do BUS o LEC pode então abrir a conexão de envio de difusão com o mesmo. O BUS responderá automaticamente abrindo a conexão de reenvio de difusão com o LEC (é esperado que esta conexão seja multiponto, mas ela também pode ser implementada como VCCs ponto-a-ponto.
Operação da LANE
Resolução de endereço (1)
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LE_ARP_ Request LE_ARP_Response LECS Cache VCCQuando um LEC deseja se comunicar com um dispositivo cujo endereço ATM é ainda desconhecido, ele envia uma mensagem LE_ARP_Request ao LES, solicitando o endereço ATM associado ao endereço MAC informado na mensagem.
Caso o LES saiba o endereço ATM associado ao endereço MAC solicitado (par de endereços foi anteriormente registrado por outro LEC), ele informa o LEC através de uma mensagem LE_ARP_Response. A resposta pode ser enviada pelo VCC direto de controle ou, opcionalmente, pelo VCC distribuído de controle.
O LEC chamador pode então abrir uma conexão com o LEC chamado para posterior troca de dados.
Operação da LANE
Resolução de endereço (2)
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LE_ARP_ Request LE_ARP_Response LECS Cache VCC LE_A RP_ Request LE_ARP_ Request LE_ARP_ResponseQuando o LES recebe a solicitação de resolução de endereço de um par de endereços MAC-ATM desconhecidos (ainda não registrados), ele deve reencaminhar esta requisição para todos os LECs que se registraram como Proxy (e opcionalmente para outros LECs).
O Proxy que estiver atuando como procurador do endereço MAC procurado irá responder à requisição, enviando uma mensagem LE_ARP_Response ao LES, informando seu próprio endereço ATM. O LES irá então encaminhar o endereço ATM do Proxy para o LEC, que poderá abrir um VCC para troca de dados.
Operação da LANE
Envio de dados unicast
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LECS Dados Dados
Quando um cliente LEC sabe o endereço ATM do LEC de destino e já possui uma conexão VCC com o mesmo, os dados são enviados diretamente para o cliente de destino.
Se o LEC de origem ainda não conhece o endereço ATM do LEC de destino, ou ainda não possui uma conexão com este, ele pode optar por enviar os quadros através do BUS. O BUS, ao receber o quadro, irá reencaminhá-lo pelo menos para o cliente de destino. Se o cliente ainda não está registrado, o BUS deve encaminhar o quadro ao menos para os clientes Proxy e opcionalmente para todos os clientes. Esta facilidade é importante, pois a estação MAC de destino pode estar atrás de uma bridge transparente que ainda não tomou conhecimento da estação, e o envio do quadro pelo BUS pode ser a única forma de alcançar a estação.
Após estabelecer a conexão com o LEC de destino, os dados podem passar a ser enviados pela conexão direta de dados (LEC-LEC). Mas para tal o protoclo Flush (descrito posteriormente) deve antes ser executado.
A conexão direta de dados é desfeita após um período configurável (tipicamente 20 minutos) de inatividade.
Operação da LANE
Operação da LANE
Protocolo Flush
LAN legada LAN legada Estação ATM LES BUS Proxy Proxy LECS Flush Request Flush _Response DadosComo foi visto, o LEC pode iniciar o envio de dados para outro LEC através do BUS, antes que a conexão com o LEC de destino esteja estabelecida. O processo de chaveamento do caminho de envio dos quadros (do caminho via BUS para o caminho direto entre LECs) pode fazer com que os quadros cheguem no destino fora da ordem em que foram transmitidos (o quadro enviado via caminho direto entre LECs pode chegar depois de um quadro enviado via BUS).
O recebimento de quadros fora de ordem não é esperado em um ambiente de rede local, e muito menos em um ambiente ATM.
Para evitar este problema, um LEC que tenha enviado um quadro através do BUS deve enviar uma mensagem denominada Flush_Request pelo mesmo caminho, e aguardar o recebimento da mensagem Flush_Response por parte do LEC de destino, para só então iniciar o envio dos quadros pelo caminho direto. Este procedimento garante a ordem de entrega dos quadros ao LEC de destino.
O BUS irá encaminhar a mensagem Flush_Request até o LEC de destino. A mensagem Flush_Response será encaminhada pelo LEC de destino através do LES (VCC direto de controle e VCC de distribuição de controle).
NHRP - Next Hop Resolution Protocol
Objetivo
LIS 1 LIS 2 LIS 3 LIS 4 IPx,ATMj IPy,ATMk Modelo clássico NHRPNo modelo clássico a comunicação entre dispositivos pertencentes a LIS distintas se dá através de roteadores, podendo resultar em ineficiência.
O NHRP é um protocolo de resolução de endereço para redes NBMA (Non-Broadcast-Multi-Access) que mapeia endereços IP em endereços ATM, com o objetivo de criar um atalho na rede ATM para a comunicação de dispositivos pertencentes a LIS distintas.
O NHRP procura mapear o endereço ATM mais próximo do destino. Este endereço pode ser o de um dispositivo de borda, e não da estação IP final.
Componentes do NHRP
LIS 1 LIS 2 LIS 3 LIS 4 NHS NHS NHS NHC NHC NHCA estrutura do NHRP é baseada no modelo cliente-servidor, com Clientes NHRP (NHC - Next Hop Client) e Servidores NHRP (NHS - Next Hop Server).
Os servidores NHS normalmente residem nos roteadores que interligam as sub-redes lógicas, e são responsáveis pela resolução de endereços IP e ATM. Existindo pelo menos um NHS por sub-rede.
Os clientes residem em qualquer dispositivo conectado à sub-rede lógica (roteador inclusive) e são usuários do serviço de resolução de endereços para estabelecerem seus atalhos na rede ATM. Os clientes devem se registrar em seu servidor NHS, informando seus endereços IP e ATM. É permitido ao cliente enviar seus pacotes pelo caminho roteado normal enquanto o endereço ATM está sendo resolvido.
Os NHSs e NHCs mantém caches, com vida limitada, com os pares de endereços (IP,ATM) já resolvidos.
Princípio de operação do NHRP
LIS 1 LIS 2 LIS 3 LIS 4 NHS NHS NHS NHC NHC NHC VCC NHRP_ Request NHRP_ Reply IPx,ATMj IPy,ATMk Cache CacheQuando um NHC precisa resolver o endereço de uma estação de destino, ele envia uma mensagem de requisição de endereço a seu servidor. Se o servidor possui, armazenado em seu cache, o registro associado ao endereço solicitado, ele informa o cliente do endereço ATM do destino. Caso contrário, o NHS envia a requisição para o NHS “next-hop” na direção do destino (para tal, o roteamento IP tradicional é utilizado). O processo continua até que a
requisição chegue a um NHS que possua em seus registros informação para resolver o endereço. Uma mensagem de resposta NHRP (NHRP_Reply) é gerada, contendo o endereço ATM associado ao endereço IP do destino (o endereço ATM pode ser de um dispositivo de borda). Os NHSs e NHC armazenam em seus caches o endereço resolvido, para utilização futura.
Multiprotocol Over ATM
MPOA
• Elimina o roteamento hop-by-hop, criando
um atalho na rede ATM.
• O processo de criação do atalho é disparado
pela detecção de um fluxo, por um host ou
dispositivo de borda MPOA-capaz
O Multiprotocol Over ATM (MPOA) tenta contornar a ineficiência do modelo clássico devido aos processos de remontagem e segmentação dos datagramas em cada roteador ao longo do caminho entre origem e destino.
O MPOA estabelece, a partir da detecção de um fluxo por um host ou
dispositivo de borda MPOA-capaz, um atalho entre o dispositivo de ingresso e o dispositivo de egresso na rede ATM, no caminho entre origem e destino, evitando com isto o caminho roteado.
Um fluxo é definido como um tráfego de pacotes entre uma origem e um destino com uma taxa (pacotes/seg) superior a um certo limiar.
Componentes do MPOA
• MPOA Client - MPC
– Dispara o processo de criação do atalho para o encaminhamento dos pacotes
• MPOA Server - MPS
– Reside em um roteador.
– Resolve o endereço IP de destino no endereço ATM de saída mais próximo do destino.
Componentes do MPOA
MPOA
Next Hop Resolution Protocol - NHRP
LAN Emulation -LANE
O MPOA utiliza o serviço de LAN emulada (LANE) para troca de mensagens entre seus componentes no âmbito de uma LANE. Para a resolução de
Princípio de operação do MPOA
MPC MPC MPOA Resolution Request NHRP Resolution Request NHRP Resolution Request MPOA Cache Imposition Request MPOA Cache Impos . Reply NHRP Resolution Reply NHRP Resolution Reply MPOA Resolution Reply VCC MPS MPS MPSUm cliente MPOA que detecte um fluxo para um dado destino inicia o estabelecimento de um atalho pela rede ATM. Para tal, o cliente envia uma mensagem MPOA_Resolution_Request para o seu servidor (MPS), solicitando o endereço ATM associado ao endereço IP de destino. O servidor consulta seu cache e, caso já conheça a associação ATM-IP solicitada, informa o endereço ATM para seu cliente. Caso contrário, o MPS envia uma mensagem
NHRP_Resolution_Request para o próximo servidor MPS na direção do destino. Este processo continua até que a resolução NHRP chegue a um MPS (MPS de egresso) que possa resolver o endereço IP no endereço ATM. O MPS de egresso envia uma mensagem de Imposição de Cache ao MPC de egresso (MPOA_Cache_Imposition_Request) e, após receber o reply do MPC, envia o endereço ATM solicitado de volta ao MPS anterior, através de uma
Gerenciamento do cache e atalho
MPC de Ingresso MPS de Ingresso MPS de Egresso MPC de egresso A MPC de egresso B Invalidação de Cache Invalidação de Cache Invalidação de CacheOs atalhos devem ser gerenciados de forma cooperativa entre os MPCs e os MPSs de ingresso e egresso, de modo a reagir a situações que podem levar a inconsistências na rede.
No exemplo, um atalho foi estabelecido com um dado MPC de egresso, mas uma mudança no roteamento alterou o MPC de egresso. Esta mudança é percebida pelo MPS de egresso, que envia uma mensagem de invalidação de cache ao antigo MPC de egresso e para o MPS anterior a ele, indicando a estes dispositivos que uma ocorreu uma alteração envolvendo o MPC A, e que as entradas no cache envolvendo este dispositivo devem ser apagadas. A invalidação de cache caminha até o MPC de ingresso, que desfaz a conexão com o MPC A e reinicia o procedimento de resolução de endereço.
Multiprotocol Label Switching
MPLS
• Padrão emergente do IETF.
• Utiliza o modelo peer.
• Pacotes são encaminhados pela rede com
base em um label, e não com base no
endereço IP.
Princípio do MPLS
Plano de roteamento Plano de encaminhamento IPx IPy IPy Label LSP FEC L1 L2 L3 LSPO MPLS separa os planos de roteamento e encaminhamento. No plano de roteamento os pacotes são enviados pela rede com base no endereço IP de destino, utilizando-se o roteamento IP normal, enquanto no plano de
encaminhamento os pacotes são enviados com base em um label acrescentado ao pacote.
O envio dos pacotes pelo plano de encaminhamento requer que um caminho seja estabelecido entre origem e destino (LSP - Label Switched Path) e que labels sejam atribuídos a cada enlace ao longo deste caminho. O LSP está associado a uma FEC (Forward Equivalence Class), que foi associada aos datagramas entre IPx e IPy pelo roteador de borda.
MPLS - Princípios
• Pacotes que chegam a um roteador de borda são
analisados e associados a uma FEC (Forward
Equivalence Class)
• Às FECs estão associados LSPs (Label Switched
Path).
• Um label é acrescentado ao pacote, de acordo com
o LSP ao qual ele está associado.
• Os pacotes são transferidos pela rede
comutando-se com bacomutando-se no label, e não no endereço IP.
Formas de implementação do MPLS
• Solução de nível 3
– O label é adicionado ao datagrama IP e utilizado como base para a comutação
• IP sobre Frame Relay
– O label é o DLCI do cabeçalho Frame Relay, e o datagrama é transportado em quadro Frame Relay
• IP sobre ATM
– O datagrama é transportado em células ATM e o label é composto pelos campos VPI/VCI da célula ATM.
IP sobre ATM com MPLS
• Mantém-se o hardware ATM
• Elimina-se o endereço ATM, a sinalização
UNI e PNNI e o roteamento PNNI
• Utiliza-se o endereçamento e o roteamento
IP.
• Utiliza-se um protocolo de distribuição de
label para o estabelecimento do caminho
No uso do MPLS como uma solução de IP sobre ATM os nós da rede tornam-se uma mistura de um comutador ATM com um roteador IP.
A forma de comutar e o hardware de comutação são do ATM, mas a rota ao longo da rede e os endereços de todos os dispositivos são baseados no IP.
Para o estabelecimento do caminho comutado por label utiliza-se um protocolo de distribuição de label (LDP). Vale salientar que outros protocolos estão sendo considerados para a distribuição de labels, como por exemplo uma extensão do RSVP.
Componentes da rede MPLS
• Label Edge Router (LER)
– Roteador na fronteira entre o mundo MPLS e o
mundo não-MPLS.
• Label Switching Router (LSR)
– Roteador no núcleo da rede MPLS.
Os LERs estão na interface entre redes não-MPLS e a rede MPLS. Eles são responsáveis por iniciar o processo de estabelecimento de um caminho (LSP) na rede. O LER associa os datagramas às FECs estabelecidas e acrescenta o label inicial, encaminhando o datagrama para o próximo nó no caminho.
Os LSRs comutam os pacotes ao longo do LSP tomando como base o label. A comutação baseada em label permite a implementação de LSRs de alto
Forward Equivalence Class - FEC
• Uma FEC é vista como um grupo de pacotes que
podem ser encaminhados pela rede da mesma
maneira.
• A FEC está associada a um LSP.
• A definição da FEC pode levar em conta
parâmetros diversos. A forma mais simples é
associar a FEC ao endereço de destino. Formas
mais sofisticadas podem levar em conta o tipo de
serviço, endereço da fonte, etc.
Pacotes associados a uma mesma FEC são encaminhados pela rede da mesma maneira, através do mesmo LSP.
A estratégia para se definir uma FEC pode ser simples, levando em conta apenas o endereço do destino, por exemplo, ou complexa, onde diversos outros fatores podem ser considerados.
Por exemplo, um provedor pode definir classes de serviço, tais como serviço premiun e serviço olímpico (ouro, prata e bronze), com tarifas diferenciadas. Neste caso, a FEC pode levar em conta o endereço do destino e o tipo de serviço que está sendo solicitado pelo cliente, ou seja, datagramas entrando
Definição da rota
• Roteamento hop-by-hop
– O LSP é criado seguindo as definições do algoritmo de roteamento IP
– Cada nó, independentemente, escolhe o próximo nó para cada FEC
• Roteamento explícito
– O LSP é criado seguindo uma rota específica definida pelo LSR de ingresso (ou egresso) origem
– Útil para engenharia de tráfego
O roteamento explícito torna-se viável com o MPLS pois, uma vez criado o LSP, os datagramas não mais precisam transportar os endereços dos roteadores ao longo do caminho, bastando associar ao LSP a característica de operação baseada em roteamento explícito. Nesta solução, mudanças no roteamento IP não afetarão o LSP, e o mesmo se aproxima em termos de comportamento de um circuito virtual.
Estabelecimento do caminho
• Disparado por topologia (Topology driven)
– Tráfego de controle proporcional ao número de
destinos.
• Disparado por fluxo (Flow driven)
– Tráfego de controle proporcional ao número de
fluxos.
– Pode não ser adequado para backbones
No método de alocação de label disparado por topologia um label é associado em resposta ao processamento normal do protocolo de roteamento. Se uma rota existe, um label é associado a ela e distribuído, sendo a quantidade de tráfego de controle proporcional ao número de rotas. Neste tipo de solução o tráfego chegando por uma dada rota pode ser associado imediatamente a um label, sem latência.
No método disparado por fluxo a detecção de um fluxo dispara o processo de estabelecimento de um LSP e distribuição de labels. A quantidade de tráfego de controle gerado é proporcional ao número de fluxos. Esta característica faz com que redes com fluxos recorrentes e com vida curta possam ter um excesso de tráfego de controle para o estabelecimento dos caminhos. Neste método
Alocação de label
• Downstream
– Um LSR faz a distribuição de labels para LSRs que estejam a upstream, mesmo que os nós a upstream não tenham solicitado explicitamente.
• Downstream sob demanda
– Um LSR solicita explicitamente a seu nó subsequente (downstream) que ele faça a associação de um rótulo para uma determinada FEC
Exemplo de operação
Downstream sob demanda
A Requisição de label VPI = 0, VCI = 28 VPI = 0, VCI = 49 VPI = 0, VCI = 97 Ingresso Egresso
VPI=0 VCI=97 dados
VPI=0 VCI=49 dados
VPI=0 VCI=28 dados
Requisição de label Requisição de label
Na operação a downstream sob demanda um LER de ingresso solicita, quando detecta um fluxo para um dado destino, o estabelecimento de um LSP e distribuição de label, através de uma mensagem de Requisição de Label. A mensagem trafega pela rede até o LER de egresso, segundo o roteamento IP (ou através de roteamento explícito), que aloca um label ao LSP em questão e o distribui para o LSR à uspstream. Este LSR também aloca um label
associado ao LSP e o envia ao LSR à upstream. O processo continua até que o último LSR envia o label alocado ao LER de ingresso, quando então o
caminho está estabelecido, e os pacotes podem ser enviados através do mesmo e comutados com base no label. As mensagens de requisição de label trafegam por um canal default, definido pelo par VPI = 0 e VCI = 32.
