BR112012018762B1 - Sistema, componente de rede e método para promover uma comunicação entre uma pluralidade de domínios de acesso - Google Patents

Abstract

CAMADA 2 VIRTUAL E MECANISMO PARA FAZÊ-LA DE FORMA ESCALONÁVEL. Um aparelho que compreende uma rede de serviços e uma pluralidade de redes de Camada 2 em uma pluralidade de diferentes localizações físicas acopladas à rede de serviços através de uma pluralidade de nós de borda nas redes de Camada 2, em que os nós de borba são cinfigurados para manter uma pluralidade de endereços de Protocolo Internet (IP) de uma pluralidade de hosts ao longo das redes de camada 2, e em que os endereços IP dos hosts em cada uma das redes de Camada 2 são mapeados pelas outras redes de camada 2 para um endereço de Controle de Acesso ao Meio (MAC) de cada um dos nós de borda nas mesmas redes de Camada 2 dos hosts.

Description

DECLARAÇÃO SOBRE PESQUISA OU DESENVOLVIMENTO PATROCINADO PELO GOVERNO FEDERAL

[001] Não aplicável.

REFERÊNCIA A UM APÊNDICE DE MICROFICHA

[002] Não aplicável.

FUNDAMENTOS

[003] As comunicações modernas e redes de dados são compostas de nós que transportam dados através da rede. Os nós podem incluir roteadores, comutadores, pontes, ou suas combinações, que transportam os pacotes de dados individuais ou quadros através da rede. Algumas redes podem oferecer serviços de dados que encaminham quadros de dados de um nó para outro nó na rede sem o uso de rotas pré- configuradas ou nós intermediários. Outras redes podem transmitir os quadros de dados de um nó para outro nó através da rede ao longo de caminhos pré-configurados ou pré-estabelecidos.

RESUMO

[004] Em uma modalidade, a divulgação inclui um aparelho que compreende uma rede de serviços e uma pluralidade de redes de Camada 2 a uma pluralidade de diferentes localizações físicas acoplados à rede de serviços através de uma pluralidade de nós de borda nas redes de Camada 2, em que os nós de borda são configurados para manter uma pluralidade de endereços de Protocolo Internet (IP) de uma pluralidade de hosts ao longo das redes de Camada 2, e em que os endereços IP dos hosts em cada uma das redes de Camada 2 são mapeados pelas outras redes de Camada 2 para um endereço de Controle de Acesso ao Meio (MAC) de cada um dos nós de borda nas mesmas redes de Camada 2 dos hosts.

[005] Em outra modalidade, a revelação inclui um componente de rede que compreende um receptor configurado para receber uma pluralidade de endereços IP para uma pluralidade de hosts em uma pluralidade de redes de Camada 2 externas localizadas em uma pluralidade de localizações físicas e interligadas através de um serviço, um circuito lógico configurado para mapear os endereços IP dos hosts nas redes de Camada 2 externas para uma pluralidade de endereços MAC de uma pluralidade de gateways correspondentes nas mesmas redes de Camada 2 externas, e um transmissor configurado para enviar para a redes de Camada 2 externas uma pluralidade de uma pluralidade de endereços IP para uma pluralidade de hosts locais uma rede de Camada 2 local acoplada às redes de Camada 2 externas através do serviço.

[006] Em ainda outra modalidade, a revelação inclui um método compreendendo receber um quadro a partir de um primeiro host em um primeiro local de centro de dados (DC) que se destina a um segundo host em uma segunda localização DC, mapear um endereço de destino (DA) para o segundo host no quadro para um endereço MAC de um Gateway de Camada 2 (L2GW) na segunda localização DC, adicionar um cabeçalho MAC exterior que suporta padrão de Instituto de Engenheiros Elétricos e Eletrônicos (IEEE) 802.1ah para MAC-em-MAC para obter um quadro interior que indica o endereço MAC do L2GW, e enviar o quadro interior para a segunda localização DC através de uma instância de serviço acoplada à segunda localização DC.

[007] Estas e outras características serão mais claramente compreendidas a partir da seguinte descrição detalhada tomada em conjunto com os desenhos e reivindicações anexos.

BREVE DESCRIÇÃO DOS DESENHOS

[008] Para uma compreensão mais completa da presente divulgação, é agora feita referência à seguinte breve descrição, tomada em conexão com os desenhos anexos e descrição detalhada, em que mesmos números de referência representam partes iguais.

[009] A Figura 1 é um diagrama esquemático de uma modalidade de Serviço de Rede de Área Local (LAN) Privado Virtual (VPLS) interligado por LANs.

[0010] A Figura 2 é um diagrama esquemático de uma modalidade de uma rede de Camada 2 virtual.

[0011] A Figura 3 é um diagrama esquemático de uma modalidade de um mecanismo de controle de fronteira.

[0012] A Figura 4 é um diagrama esquemático de uma modalidade de um esquema de encaminhamento de quadro de dados.

[0013] A Figura 5 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0014] A Figura 6 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0015] A Figura 7 é um diagrama esquemático de uma modalidade de domínios de Camada 2 interconectados.

[0016] A Figura 8 é um diagrama esquemático de uma modalidade de uma extensão de Camada 2 sobre domínios de endereço múltiplos.

[0017] A Figura 9 é um diagrama esquemático de uma modalidade de pseudo redes de Camada 2 sobre domínios de endereço múltiplos.

[0018] A Figura 10 é um diagrama esquemático de uma modalidade de um mecanismo de restrição de domínio de endereço.

[0019] A Figura 11 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0020] A Figura 12 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0021] A Figura 13 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0022] A Figura 14 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0023] A Figura 15 é um diagrama esquemático de uma modalidade de um esquema de transmissão.

[0024] A Figura 16 é um diagrama esquemático de outra modalidade de um sistema de transmissão.

[0025] A Figura 17 é um diagrama esquemático de uma modalidade de distritos de rede interconectados.

[0026] A Figura 18 é um diagrama esquemático de outra modalidade de distritos de rede interconectados.

[0027] A Figura 19 é um diagrama esquemático de uma modalidade de um esquema de proxy ARP.

[0028] A Figura 20 é um diagrama esquemático de outra modalidade de um sistema de encaminhamento de quadro de dados.

[0029] A Figura 21 é um diagrama esquemático de outra modalidade de um esquema de proxy ARP.

[0030] A Figura 22 é um diagrama esquemático de uma modalidade de um servidor físico.

[0031] A Figura 23 é um diagrama esquemático de uma modalidade de um esquema de superação de falhas.

[0032] A Figura 24 é um diagrama esquemático de uma modalidade de um esquema de encapsulamento de endereços de rede assimétrico.

[0033] A Figura 25 é um diagrama esquemático de uma modalidade de um esquema de processamento ARP.

[0034] A Figura 26 é um diagrama esquemático de uma modalidade de uma carga ARP estendida.

[0035] A Figura 27 é um diagrama esquemático de uma modalidade de outro esquema de encaminhamento de quadro de dados.

[0036] A Figura 28 é um diagrama de protocolo de uma modalidade de um método de processamento ARP melhorado.

[0037] A Figura 29 é um diagrama de protocolo de uma modalidade de um método de resolução de endereço estendido.

[0038] A Figura 30 é um diagrama esquemático de uma modalidade de uma unidade de componente de rede.

[0039] A Figura 31 é um diagrama esquemático de uma modalidade de um sistema de computador de uso geral.

DESCRIÇÃO DETALHADA

[0040] Deve ser entendido, no início, que embora uma aplicação ilustrativa de uma ou mais modalidades sejam fornecidas a seguir, os sistemas e / ou métodos divulgados podem ser implementados usando qualquer número de técnicas, tanto atualmente conhecidas ou na existência. A divulgação deve de modo algum ser limitada às implementações ilustrativas, desenhos, e técnicas ilustradas abaixo, incluindo os desenhos exemplares e implementações ilustradas e descritas aqui, mas podem ser modificados dentro do âmbito das reivindicações anexas, juntamente com o seu âmbito completo de equivalentes.

[0041] Modernas redes de dados podem incluir serviços de nuvem e VMs que suportam aplicações na camada de enlace de dados, também conhecida como Camada 2, que pode ter de abranger vários locais. Essas redes podem incluir um aglomerado de servidores (ou VMs), como em um DC, que devem ser divididos entre vários locais e comunicar ao nível de Camada 2 para suportar aplicações já implantadas e, assim, economizar custos, por exemplo, em milhões de dólares. Comunicações de Camada 2 entre o Aglomerado de servidores incluem balanceamento de carga, agrupamento de banco de dados, recuperação de falhas do servidor virtual, funcionamento transparente abaixo da camada de rede (Camada 3), espalhar uma sub-rede em vários locais, e redundância. Comunicações de Camada 2 também incluem um mecanismo de “manter-ativo” entre as aplicações. Algumas aplicações precisam dos mesmos endereços IP para se comunicar em vários locais, onde um servidor pode ser ativo e outro servidor pode estar em espera. Os servidores ativos e em espera (em locais diferentes) podem trocar mensagens “manter-ativo” entre eles, que podem exigir um mecanismo de “manter-ativo” de Camada 2.

[0042] A Figura 1 ilustra uma modalidade de VPLS interconectado por Redes de Área Local (LANs) 100. O VPLS interligado por LANs 100 é um mecanismo escalonável que tem sido proposto para a conexão de redes de Camada 2 em vários locais DC, por exemplo, locais físicos, para estabelecer uma rede de Camada 2 unificada ou plana. O VPLS interligado por LANs 100 pode compreender um VPLS 110 e uma pluralidade de LANs 120 que podem ser acopladas ao VPLS 110 através de uma pluralidade de nós de borda 112, tais como roteadores de borda. Cada LAN 120 pode compreender uma pluralidade de comutadores de Camada 2 122 acoplados a nós de borda correspondentes 112, uma pluralidade de comutadores de acesso 124 acoplados a comutadores de Camada 2 correspondentes, uma pluralidade de VMs 126 acoplados comutadores de acesso correspondentes 124. Os componentes do VPLS interligado por LANs 100 podem ser dispostos como mostrado na Figura 1.

[0043] O VPLS 110 pode ser qualquer rede que é configurada para se conectar a LANs 120 em diferentes locais ou DCs. Por exemplo, o VPLS 110 pode compreender uma rede de Camada 3 para interligar as LANs 120 através de DCs diferentes. Os comutadores de Camada 2 122 podem ser configurados para se comunicar na camada de enlace de dados de modelo de Interconexão de Sistema Aberto (OSI). Exemplos de protocolos de enlace de dados incluem Ethernet para LANs, o Protocolo Ponto-a-Ponto (PPP), Controle de Enlace de Dados de Alto Nível (HDLC) e Protocolo de Controle de Comunicações de Dados Avançado (ADCCP) para as conexões ponto-a-ponto. Os comutadores de acesso 124 podem ser configurados para transmitir dados entre os comutadores de Camada 2 122 e as VMs 126. As VMs 126 podem incluir máquinas virtuais de sistema que fornecem plataformas de sistema, por exemplo, sistemas operacionais (OSs) e / ou máquinas virtuais de processos que executam programas ou aplicações. As VMs 126 em cada LAN 120 podem ser distribuídas sobre uma pluralidade de processadores, unidades de processamento central (CPU), ou sistemas de computador. Uma pluralidade de VMs 126 em uma LAN 120 também pode compartilhar os mesmos recursos do sistema, tais como espaço em disco, memória, processador e / ou outros recursos de informática. As VMs 126 podem ser dispostas em uma prateleira e acopladas às LANs correspondentes 120, por exemplo, através dos comutadores de acesso 124.

[0044] Alguns aspectos de VPLS interligado por LANs 100 podem representar problemas de implementação impraticáveis ou indesejáveis. Em um aspecto, o VPLS 110 pode exigir a implementação de uma Rede de Área Ampla (WAN) que suporta Comutação de Rótulo de Protocolo de Rótulo Múltiplos (MPLS). No entanto, alguns operadores, como a China Telecom, não suportam MPLS sobre WAN e, portanto, pode ter dificuldades na implementação de VPLS interligado por LANs 100. Além disso, para resolver endereços de camada de enlace de host, por exemplo, para as VMs 126 através das LANs 120, um ARP pode ser necessário, como o ARP descrito no Pedido de Força Tarefa de Engenharia de Internet (IETF) para comentários (RFC) 826, que é aqui incorporado por referência. O ARP pode inundar solicitações para todas as LANs interligadas 120 e, assim, esgotar uma quantidade substancial dos recursos do sistema (por exemplo, largura de banda). Tal mecanismo de inundação ARP pode sofrer de problemas de escalabilidade, como o número de LANs 120 e / ou VMs aumenta 126. O VPLS interligado por LANs 100 pode também configurar malha de pseudofios (PWS) para conectar às LANs 120, que pode precisar de configuração e manutenção de estado de túneis. Em alguns cenários, o VPLS 110 pode usar um Protocolo de Gateway de Fronteira (BGP) para descobrir uma LAN 120 e construir uma malha de PW para cada LAN 120.

[0045] Virtualização de Transporte Óptico (OTV) é outro mecanismo escalonável que foi proposto para conectar redes de Camada 2 em vários locais ou DCs para estabelecer uma de rede de Camada 2 plana. OTV é um método proposto pela Cisco, que depende de encapsulamento IP de comunicações de Camada 2. OTV pode utilizar um protocolo de roteamento de Sistema Intermediário para Sistema Intermediário (IS-IS) para distribuir acessibilidade MAC dentro de cada local (por exemplo, DC) para outros locais. O esquema de OTV também pode ter alguns aspectos impraticáveis ou indesejáveis. Em um aspecto, OTV pode exigir a manutenção de um número relativamente grande de grupos multicast por uma rede IP de núcleo provedor. Uma vez que cada LAN pode ter uma topologia de sobreposição separada, pode haver uma quantidade relativamente grande de topologias de sobreposição que são mantidas pela rede IP de provedor de serviço, o que pode representar um fardo sobre a rede central. OTV também pode exigir que um nó de borda use Protocolo de Gestão de Grupo de Internet (IGMP) para unir diferentes grupos de multicast no domínio IP. Se cada nó de borda é acoplado a uma pluralidade de LANs virtuais (VLAN), o nó de borda pode precisar participar em grupos de IGMP múltiplos.

[0046] Em OTV, dispositivos de borda, tais como um gateway em cada local, podem ser hosts IP que são um salto de distância um do outro, o que pode não exigir a implementação de um protocolo de estado de enlace entre os dispositivos de borda para troca de informações de acessibilidade. No entanto, o estado de enlace também pode ser usado para autenticar um ponto, que pode ser necessário a OTV se o ponto junta uma VLAN através do envio de um relatório de IGMP versão 3 (IGMPv3). Alternativamente, OTV pode utilizar um método de autenticação BGP. No entanto, o sincronismo de autenticação BGP pode ser diferente do que o sincronismo de autenticação IS-IS. Por exemplo, BGP pode ser ajustado para um desempenho de segundos e IS-IS pode ser ajustado para desempenho de subsegundos. Além disso, o protocolo IS-IS pode não ser adequado para o tratamento de um número substancialmente grande de hosts e VMs, por exemplo, dezenas de milhares, em cada local no sistema de OTV. OTV também pode ser inadequada para suportar dezenas de milhares de grupos de usuários fechados.

[0047] Aqui revelados são os sistemas e métodos para proporcionar um mecanismo escalonável para conectar uma pluralidade de redes de Camada 2 a uma pluralidade de localizações diferentes, para obter uma rede de Camada 2 plana ou única. O mecanismo escalonável pode resolver alguns dos aspectos ou desafios para a obtenção de uma rede de Camada 2 plana que se estende por vários locais. O mecanismo escalonável pode facilitar a descoberta da topologia entre os locais pelo suporte de resolução de endereço escalonável para aplicações e permitindo comutadores de rede para manter uma pluralidade de endereços associados com a totalidade ou uma pluralidade de máquinas ao longo das localizações. O mecanismo escalonável também pode facilitar o tráfego de encaminhamento entre as diferentes localizações e tráfego de transmissão, por exemplo, para endereços de hosts desconhecidos, e suportar grupos de multicast.

[0048] Os métodos incluem um mecanismo de controle de fronteira para escalonar uma relativamente grande Camada 2 plana sobre vários locais. Como tal, aplicações, servidores e / ou máquinas virtuais podem estar cientes de uma rede de Camada 2 virtual que compreende várias Redes de Camada 2 interconectadas por uma outra rede, como uma rede de Camada 3, uma de Camada 2,5, ou uma de Camada 2. As redes de Camada 2 podem ser localizadas em diferentes ou separados locais físicos. Um mecanismo de resolução de endereço independente de protocolo pode também ser utilizado e pode ser adequado para lidar com uma relativamente grande rede de Camada 2 virtual e / ou um número substancialmente grande de Redes de Camada 2 ao longo de vários locais.

[0049] A Figura 2 ilustra uma modalidade de uma rede de Camada 2 virtual 200 através diferentes DC ou locais físicos. A rede de Camada 2 virtual 200 pode ser um mecanismo escalonável para conectar redes de Camada 2 em vários locais, por exemplo, localizações geográficas ou DCs, para estabelecer um sistema unificado ou rede de Camada 2 plana. A rede de Camada 2 virtual 200 pode compreender uma rede de serviços 210 e uma pluralidade de redes de Camada 2 220 que podem ser acopladas à rede de serviços 210 através de uma pluralidade de nós de borda 212, tal como roteadores de borda. Cada rede de Camada 2 220 pode compreender uma pluralidade de L2GWs 222 acoplados a nós de borda correspondentes 212, e uma pluralidade de comutadores intermediários 224 que podem ser acoplados aos L2GWs 222. Os componentes de rede de Camada 2 virtual 200 podem ser dispostos como mostrado na Figura 2. Os comutadores intermediários 224 podem também ser acoplados a uma pluralidade de hosts e / ou VMs (não mostrado).

[0050] A rede de serviços 210 pode ser qualquer rede estabelecida para interligar as Redes de Camada 2 220, tais como uma rede de provedor de serviço. Por exemplo, a rede de serviços 210 pode ser uma rede de Camada 2, Camada 2,5, ou Camada 3, como uma rede privada virtual (VPN). A rede de serviços 210 pode estar ciente dos endereços de todos os endereços, por exemplo, MAC, dos L2GWs 222. Os L2GWs 222 podem ser nós de fronteira em cada local DC e ter interfaces de Camada 2 para comunicar internamente nos locais DC. Os L2GWss 222 podem utilizar os seus respectivos endereços MAC para comunicar, por exemplo, através dos comutadores intermediários 224, com os hosts e / ou VMs nos mesmos locais dentro das mesmas redes de Camada 2 220 dos L2GWs 222 e nas outras redes de Camada 2 220. No entanto, os L2GWs 222 e os comutadores intermediários 224 podem não estar cientes dos endereços MAC dos hosts / VMs nas outras redes de Camada 2 220. Em vez disso, os endereços MAC do host / VMs podem ser traduzidos nos L2GWs 222 em outras redes de Camada 2 220, por exemplo, usando uma tabela de tradução de endereços de rede (NAT) ou uma tabela de tradução de endereços MAC (MAT), como descrito abaixo.

[0051] Em uma modalidade, cada L2GW 222 pode manter os endereços de todos os hosts / VMs dentro da mesma rede de Camada 2 220 do L2GW 222 em uma tabela de informação de endereço IP local (Local-IPAddrTable). O L2GW 222 pode também ser configurado para implementar uma função ARP proxy, como descrito abaixo. Além disso, o L2GW 222 pode manter uma tabela de encaminhamento MAC, que pode compreender os endereços MAC para aplicações não IP. Os endereços MAC podem compreender os endereços MAC dos hosts / VMs e os comutadores intermediários 224 no mesmo local, por exemplo, a mesma rede de Camada 2 220.

[0052] O L2GW 222 pode informar os seus pares (por exemplo, outros L2GWs 222) em outros locais (por exemplo, redes de Camada 2 220) de todos os endereços IP dos hosts locais em sua localização, mas não os endereços MAC mantidos localmente (para aplicações não IP). Como tal, os L2GWs 222 entre os diferentes locais podem obter os endereços IP de host de todos os outros locais. Assim, cada L2GW 222 pode mapear cada grupo de endereços IP que pertence a um local para o endereço MAC do L2GW correspondente 222 que pertence ao mesmo local. O L2GW 222 também pode reenviar as informações de endereço para os pares quando há uma mudança em sua local-IPAddrTable para atualizar as informações nos outros pares. Isso pode permitir a atualização das informações de endereços e mapeamento em cada L2GW 222 de forma incremental.

[0053] A Figura 3 ilustra uma modalidade de um mecanismo de controle de fronteira 300. O mecanismo de controle de fronteira 300 pode ser um mecanismo escalonável para o estabelecimento de um rede de Camada 2 virtual ou plana em vários locais ou DCs. A rede de Camada 2 virtual pode compreender uma rede de serviços 310 e uma pluralidade de redes de Camada 2 320 que podem ser acopladas à rede de serviços 310 através de uma pluralidade de nós de borda 312, tais como roteadores de borda. Cada rede de Camada 2 220 pode compreender uma pluralidade de L2GWs 322 acoplados a nós de borda correspondentes 312, e uma pluralidade de comutadores intermediários 324 que podem ser acoplados aos L2GWs 322. Os comutadores intermediários 324 podem também ser acoplados a hosts 326, por exemplo, VMs. Os componentes de rede de Camada 2 virtual podem ser dispostos como mostrado na Figura 2 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0054] Com base no mecanismo de controle de fronteira 300, cada L2GW 322 pode manter os endereços IP dos hosts em todos os locais, por exemplo, as redes de Camada 2 320. Os endereços IP podem também pertencer aos hosts em diferentes domínios, como por exemplo, domínios de Camada 2 que podem estender por vários locais físicos e podem ser acoplados por uma rede IP / MPLS. Cada L2GW 322 pode também estar ciente dos endereços MAC dos L2GWs de par 322 em outros locais. No entanto, o L2GW 322 pode não manter os endereços MAC dos hosts em outros locais, o que pode reduzir substancialmente o tamanho dos dados trocados (e armazenados) entre os L2GWs 322. Os endereços IP mantidos no L2GW 322 podem ser mapeados para os endereços MAC dos L2GWs correspondentes 322 dos mesmos locais. Especificamente, cada conjunto de endereços IP de host que pertence a cada local ou rede de Camada 2 300 pode ser mapeado para o endereço MAC do L2GW 322 naquele local. No entanto, os L2GWs 322 podem trocar, em diferentes locais, uma pluralidade de endereços MAC para nós que executam aplicações não IP.

[0055] Para suportar resolução de endereço através dos diferentes locais da rede de Camada 2 virtual, um pedido ARP pode ser enviado a partir de um primeiro host 326 (host A) para um L2GW local correspondente 322 em um primeiro local ou rede de Camada 2 320. O host A pode enviar o pedido ARP para obter o endereço MAC de um segundo host 326 (host B) em um segundo local ou rede de Camada 2 320. Se o L2GW local 322 tem uma entrada para o host B, por exemplo, o endereço IP do host B, o L2GW local 322 pode responder ao pedido ARP enviando seu próprio endereço MAC para o host A. Se o L2GW local 322 não mantém ou armazena uma entrada para o host B, o L2GW local 322 pode supor que o host B não existe. Por exemplo, os L2GWs 322 podem atualizar os seus pares com seus endereços IP de host locais em uma base regular ou periódica. Neste caso, alguns L2GWs 322 podem não ter recebido atualizações para os endereços IP de hosts recém configurados em outros locais.

[0056] A Tabela 1 ilustra um exemplo de mapeamento de endereços de host para os endereços MAC de L2GW correspondente de acordo com o mecanismo de controle de fronteira 300. Uma pluralidade de endereços MAC de L2GW (por exemplo, L2GW1 MAC e L2GW2 MAC) pode ser mapeada para uma pluralidade de endereços de host correspondentes. Cada endereço MAC de L2GW pode ser mapeado para uma pluralidade de endereços IP de host (ou MAC) em uma pluralidade de VLANs (por exemplo, VLAN#, VLAN-x, ...) que podem estar associados a um mesmo local ou DC. Cada VLAN pode também compreender uma pluralidade de grupos particulares virtuais (VPGs) (ou grupos fechados de usuários) de hosts. Um VPG pode ser um aglomerado de hosts e / ou VMs que pertencem a um domínio de Camada 2 e podem comunicar uns com os outros através da camada 2. Os hosts no VPG também podem ter grupos de multicast estabelecidos entre eles. Os hosts / VMs dentro de um VPG podem estender por vários locais físicos.

[0057] Por exemplo, VLAN# pode compreender uma pluralidade de hosts em VPGs múltiplos, incluindo G-x1, G- x2, ... Do mesmo modo, VLAN-x pode compreender uma pluralidade de hosts em VPGs múltiplos (incluindo G-xj, ...) , e VLAN-X1 pode compreender uma pluralidade de hosts em VPGs múltiplos (incluindo G-j1, G-j2, ...). Para aplicações IP, os endereços IP de hosts em cada VPG de cada VLAN podem ser mapeados para o endereço MAC de L2GW correspondente no mesmo local, tal como no caso da VLAN# e VLAN-x. ...). Para aplicações não IP, os endereços MAC de hosts em cada VPG de cada VLAN podem ser mapeados para o endereço MAC de L2GW correspondente no mesmo local, tal como no caso da VLAN-x1. Tabela 1: Mecanismo de Controle de Fronteiras

[0058] Figura 4 ilustra uma modalidade de um sistema de encaminhamento de quadro de dados 400 que pode ser utilizado em uma rede de Camada 2 virtual em vários locais ou DCs. A rede de Camada 2 virtual pode compreender uma rede de serviços 410 e uma pluralidade de redes de Camada 2 420 que podem ser acopladas à rede de serviços 410 através de uma pluralidade de nós de borda 412, tais como roteadores de borda. Cada rede de Camada 2 420 pode compreender uma pluralidade de L2GWs 422 acoplados a nós de borda correspondentes 412, e uma pluralidade de comutadores intermediários 424 que podem ser acoplados aos L2GWs 422. Os comutadores intermediários 424 podem também ser acoplados a hosts 426, por exemplo, VMs. Os componentes de rede de Camada 2 virtual podem ser dispostos como mostrado na Figura 4 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0059] Com base no esquema de encaminhamento de quadro de dados 400, os L2GWs 422 podem suportar um padrão do Instituto de Engenheiros Elétricos e Eletrônicos 802.1ah (IEEE) para MAC-em-MAC, que é aqui incorporado por referência, utilizando um campo de Tipo Ether para indicar que um quadro interior precisa de tradução de endereço MAC. Por exemplo, um primeiro L2GW 422 (GW1) pode receber um quadro 440, por exemplo, um quadro Ethernet, a partir de um primeiro host 426 (host A) em um primeiro local (Loc. 1). O quadro 440 pode ser destinado a um segundo host 426 (host B) em uma segunda localização (Loc. 2). O quadro 440 pode incluir um endereço MAC de destino (MAC-DA) 442 para GW1 (L2GW-Loc1), um endereço MAC de origem (MAC-SA) 444 para o host A (MAC de A), um endereço de destino IP (IP-DA) 446 para o host B (B), um endereço IP de origem (IP-SA) 448 para o host A (A), e carga. GW1 pode então adicionar um cabeçalho MAC exterior para o quadro 440 para obter um quadro interior 460. O cabeçalho MAC exterior pode compreender um MAC-DA 462 para GW2 (L2GW-Loc2), um MAC-SA 464 para GW1 (L2GW-Loc1), e um Tipo Ether 466 que indica que o quadro interior 460 precisa de tradução de endereço MAC. O quadro interior 460 pode também compreender um MAC- DA 468 para GW1 (L2GW-Loc1) e um MAC-SA 470 para host A (MAC de A). O quadro interior 460 pode então ser encaminhado na rede de serviços 410 para GW2, o qual pode processar o cabeçalho MAC exterior para traduzir os endereços MAC do quadro. Como tal, GW2 pode obter um segundo quadro 480, que pode compreender um MAC-DA 482 para host B (MAC de B), um MAC-SA 484 para o host A (MAC de A), um IP-DA 486 para o host B (B), um IP-SA 488 para host A (A), e carga. O segundo quadro 480 pode então ser encaminhado para o host B em Loc. 2.

[0060] O esquema de encaminhamento de quadro de dados 400 pode ser mais simples de implementar do que esquema OTV da Cisco que requer encapsular um cabeçalho IP exterior. Além disso, muitos chips Ethernet suportam IEEE 802.1ah. Uma etiqueta de instância de serviço (I-TAG), tal como especificado em 802.1ah, pode ser utilizada para diferenciar entre diferentes VPGs. Assim, um campo I-TAG pode também ser utilizado no esquema de encaminhamento de quadro de dados 400 para separar entre VPGs múltiplos do domínio de provedor, por exemplo, na rede de serviços 410. GW2 pode realizar o sistema de tradução de MAC descrito acima, usando uma MAT, que pode ser semelhante ao uso de uma NAT para traduzir um IP público em um IP particular. Ao contrário do esquema de NAT, que é baseado em uma sessão de Protocolo de Controle de Transmissão (TCP), o esquema MAT pode ser baseado na utilização de um endereço IP interior para encontrar o endereço MAC.

[0061] A Figura 5 ilustra uma modalidade de um outro esquema de encaminhamento de quadro de dados 500 para aplicações não IP. O esquema de encaminhamento de quadro de dados 500 pode usar os endereços MAC de hosts não IP ou hosts que implementam aplicações não IP em vez de endereços IP para encaminhar quadros entre os hosts em diferentes locais em uma rede de Camada 2 virtual. A rede de Camada 2 virtual pode compreender uma rede de serviços 510 e uma pluralidade de redes de Camada 2 520 que podem ser acopladas à rede de serviços 510 através de uma pluralidade de nós de borda 512, tais como roteadores de borda. Cada rede de Camada 2 520 pode compreender uma pluralidade de L2GWs 522 acoplados a nós de borda correspondentes 512, e uma pluralidade de comutadores intermediários 524 que podem ser acoplados aos L2GWs 522. Os comutadores intermediários 524 podem também ser acoplados a hosts 526, por exemplo, VMs. Os componentes de rede de Camada 2 virtual podem ser dispostos como mostrado na Figura 5 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0062] Com base no esquema de encaminhamento de quadro de dados 500, os L2GWs 522 podem suportar IEEE 802.1ah para MAC-em-MAC. Por exemplo, um primeiro L2GW 520 (GW1) pode receber um quadro 540, por exemplo, um quadro Ethernet, a partir de um primeiro host 526 (host A) em um primeiro local (Loc. 1). O quadro 540 pode ser pretendido ou destinado a um segundo host 526 (host B) em uma segunda localização (Loc. 2). O quadro 540 pode compreender um MAC- DA 542 para GW1 (L2GW-Loc1), um MAC-SA 544 para o host A (MAC de A), e carga. GW1 pode então adicionar cabeçalho MAC exterior para o quadro 540 para obter um quadro interior 560. O cabeçalho MAC exterior pode compreender um MAC-DA 562 para GW2 (L2GW-Loc2), um MAC-SA 564 para GW1 (L2GW- Loc1), e um Tipo Ether 566 que indica que o quadro interior 560 é um quadro MAC-em-MAC. O campo interior 560 pode também incluir um MAC-DA 568 para o host B (MAC de B) e um MAC-SA 570 para o host A (MAC de A). O quadro interior 560 pode então ser encaminhado na rede de serviços 510 para GW2, o qual pode processar o quadro interior 560 para obter um segundo quadro 580. O segundo quadro 580 pode compreender um MAC-DA 582 para o host B (MAC de B) e um MAC-SA 584 para o host A (MAC de A), e carga. O segundo quadro 580 pode então ser encaminhado para o host B em Loc. 2.

[0063] O esquema de encaminhamento de quadro de dados 500 pode ser mais simples de implementar do que esquema OTV da Cisco que requer encapsulamento de cabeçalho IP exterior. Além disso, muitos chips Ethernet suportam IEEE 802.1ah. Uma I-TAG, como descrito em 802.1ah, pode ser utilizada para diferenciar entre diferentes VPGs. Assim, um campo I-TAG pode também ser utilizado no esquema de encaminhamento de quadro de dados 500 para separar entre VPGs múltiplos do domínio de provedor, por exemplo, na rede de serviços 510. GW2 pode processar o segundo quadro 580, como descrito acima, sem a realização de um sistema de tradução de MAC.

[0064] A Figura 6 ilustra uma modalidade de um outro esquema de encaminhamento de quadro de dados 600 que pode ser utilizado em uma rede de Camada 2 virtual em vários locais. O esquema de encaminhamento de quadro de dados 600 pode ser usado para encaminhar quadros a partir de um host que se move a partir de uma localização anterior para uma nova localização na rede de Camada 2 virtual e mantém o mesmo endereço MAC aprendido para um segundo host. A rede de Camada 2 virtual pode compreender um serviço de rede 610 e uma pluralidade de redes de Camada 2 620 que podem ser acopladas à rede de serviços 610 através de uma pluralidade de nós de borda 612, tais como roteadores de borda. Cada rede de Camada 2 620 pode compreender uma pluralidade de L2GWs 622 acoplados a nós de borda correspondentes 612, e uma pluralidade de comutadores intermediários 624 que podem ser acoplados aos L2GWs 622. Os comutadores intermediários 624 podem também ser acoplados a hosts 626, por exemplo, VMs. Os componentes de rede de Camada 2 virtual podem ser dispostos como mostrado na Figura 6 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0065] Quando um primeiro host 626 (host A) se move de um local anterior (Loc. 1) para um novo local (Loc. 3), o host A pode ainda usar o mesmo endereço MAC aprendido para um segundo host 626 (host B). De acordo com o esquema de encaminhamento de quadro de dados 600, um L2GW 622 de Loc. 3 (GW3) pode suportar 802.1ah MAC-em-MAC usando um campo Tipo Ether para indicar que um quadro interior precisa de tradução de endereço MAC. GW3 pode implementar um esquema de encaminhamento de quadro de dados semelhante ao esquema de encaminhamento de quadro de dados 400 para enviar dados para um segundo L2GW 622 de Loc. 2 (GW2) usando o endereço MAC do GW2 em um cabeçalho MAC exterior. Assim, GW2 pode de-encapsular o cabeçalho MAC exterior e executar a tradução de endereço MAC, como descrito acima (para o esquema de encaminhamento quadro de dados 400).

[0066] Por exemplo, GW3 pode receber um quadro 640, por exemplo, um quadro Ethernet, do host A depois de passar para Loc. 3. O quadro 640 pode ser destinado para o Host B em Loc. 2. O quadro 640 pode compreender um MAC-DA 642 para um L2GW anterior 622 (GW1) de Loc. 1 (L2GW-Loc1), um MAC-SA 644 para host A (MAC de A), um IP-DA 646 para o host B (B), um IP-SA 648 para o host A (A), e carga. GW3 pode então adicionar um cabeçalho MAC exterior para o quadro 640 para obter um quadro interior 660. O cabeçalho MAC exterior pode compreender um MAC-DA 662 para GW2 (L2GW-Loc2), um MAC-SA 664 para GW1 (L2GW-Loc1), e um Tipo Ether 666 que indica que o quadro interior 660 precisa de tradução de endereço MAC. O quadro interior 660 pode também compreender um MAC- DA 668 para o host B (MAC de B) e um MAC-SA 670 para o host A (MAC de A). O quadro interior 660 pode então ser encaminhado na rede de serviços 610 para GW2, o qual pode processar o cabeçalho MAC exterior para traduzir os endereços MAC do quadro. Como tal, GW2 pode obter um segundo quadro 680, que pode compreender um MAC-DA 682 para o host B (MAC de B), um MAC-SA 684 para host A (MAC de A), e carga. O segundo quadro 680 pode então ser encaminhado para o host B em Loc. 2.

[0067] Além disso, host B pode mover-se a partir de Loc. 2 para outro local, por exemplo, Loc. 4 (não mostrado). Se GW2 tem conhecimento de que host B mudou de Loc. 2 para Loc. 4, em seguida, GW2 pode usar o endereço MAC de outro L2GW 622 em Loc. 4 (GW4) como um MAC-DA em um cabeçalho MAC exterior, como descrito acima. Se GW2 não tem conhecimento de que o host B passou de Loc. 2 para 4 Loc, o quadro pode ser encaminhado pelo GW2 sem o cabeçalho MAC exterior. Como tal, o quadro pode ser perdido, por exemplo, na rede de serviços 610. O quadro pode ser perdido temporariamente até que o quadro é reenviado pelo GW2 após host B anunciar seu novo local para GW2 ou Loc. 2.

[0068] A Figura 7 ilustra uma modalidade dos domínios de Camada interconectados 2 700 que podem implementar um mecanismo de controle de fronteira semelhante como as redes de camada 2 virtual acima. Os domínios de Camada 2 interconectados 700 podem compreender uma pluralidade de L2GWs 722 acoplados a uma pluralidade de nós de borda ou de fronteira 712. Os nós de borda, por exemplo, roteadores de borda, podem pertencer a uma rede de serviço, por exemplo, uma rede de Camada 3. Os domínios de Camada 2 interconectados 700 podem também compreender uma pluralidade de comutadores intermediários 724 acoplados aos L2GWs 722, e uma pluralidade de VMs 726 acopladas aos comutadores intermediários 724. Os L2GWs 722, comutadores intermediários 724, e VMs 726 podem ser divididos em subconjuntos que correspondem a uma pluralidade de domínios de endereço de Camada 2 (L2). Os componentes dos domínios de Camada 2 interconectados 700 podem ser dispostos como mostrado na Figura 7 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0069] Cada domínio de endereço de L2 pode usar um mecanismo de controle de fronteira, como o mecanismo de controle de fronteira 300, onde os comutadores intermediários 724 e máquinas virtuais 726 dentro de cada domínio de endereço L2 podem estar cientes de endereços MAC locais, mas não os endereços MAC para hosts IP, servidores e / ou VMs 726 nos outros domínios de endereço de L2. No entanto, os hosts, servidores e / ou VMs 726 podem se comunicar uns com os outros como em uma rede de Camada 2 plana única sem estar ciente dos domínios de endereço de L2 diferentes. Os domínios de endereço de L2 podem ser interconectados uns aos outros através dos nós de borda ou de fronteira 712, os quais podem ser interconectados através de uma rede de núcleo ou rede de provedor de serviço (não mostrados). Os domínios de endereço de L2 podem estar localizados em um local DC ou em uma pluralidade de localizações geográficas. A arquitetura dos domínios de Camada 2 interconectados 700 através dos domínios de endereço de L2 múltiplos pode também ser referida aqui como uma extensão de Camada 2 sobre domínios de endereço múltiplos, pseudo redes de Camada 2 sobre domínios de endereço múltiplos, ou pseudo redes de Camada 2.

[0070] A Figura 8 ilustra uma modalidade de uma extensão de Camada 2 800 sobre domínios de endereço múltiplos. A extensão de Camada 2 800 pode compreender uma pluralidade de L2GWs 822 acoplados a uma pluralidade de nós de borda ou de fronteira 812, que podem pertencer a um provedor de serviço ou rede de núcleo (não mostrado). A extensão de Camada 2 800 pode também compreender uma pluralidade de comutadores intermediários 824 acoplados aos L2GWs 822, e uma pluralidade de hosts / servidores / VMs 826 acoplados aos comutadores intermediários 824. Os comutadores intermediários 824 e hosts / servidores / VMs 826 podem ser separados ou dispostos em uma pluralidade de domínios de endereço de L2. Por exemplo, um dos domínios de endereço de L2 é indicado pelo círculo de linha tracejada na Figura 8. Os L2GWs 822, comutadores intermediários 824, e hosts / servidores / VMs 826 podem corresponder a uma rede de Camada 2 em um ou em locais DC múltiplos. Os componentes da extensão de Camada 2 800 podem ser dispostos como mostrado na Figura 8 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0071] A Figura 9 é um diagrama esquemático de uma modalidade das pseudo redes de Camada 2 900 ao longo de vários locais. As pseudo redes de Camada 2 900 podem ser um mecanismo para conectar domínios de endereço de Camada 2 em vários locais, por exemplo, localizações geográficas ou DCs, para estabelecer um sistema unificado ou rede de Camada 2 plana. As pseudo redes de Camada 2 900 podem compreender um provedor de serviço ou rede de núcleo 910 e uma pluralidade de domínios de rede de Camada 2 920, que podem ser acoplados ao provedor de serviço ou rede central 910 através de uma pluralidade de nós de borda 912, tais como roteadores de borda. Cada domínio de rede de Camada 2 920 pode estar localizado em uma diferente localização DC ou localização e pode compreender uma pluralidade de L2GWs 922 acoplados a nós de borda correspondentes 912, e uma pluralidade de comutadores intermediários 924 acoplados a L2GWs correspondentes 922. Os comutadores intermediários 924 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs (não mostrado). Os componentes das pseudo redes de Camada 2 900 podem ser dispostos como mostrado na Figura 9 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0072] A Figura 10 ilustra uma modalidade de um mecanismo de restrição de domínio de endereço 1000. O mecanismo restrição de domínio de endereço 1000 pode ser utilizado em pseudo redes de Camada 2 sobre domínios de endereço múltiplos para lidar com a resolução de endereço entre os domínios de endereço diferentes L2. As pseudo redes de Camada 2 ao longo dos domínios de endereço podem compreender um provedor de serviço ou rede central 1010 e uma pluralidade de domínios de rede de Camada 2 1020 que podem ser acoplados ao provedor de serviço ou rede central 1010 por meio de uma pluralidade de nós de borda 1012. Os domínios de rede de Camada 2 1020 podem estar localizados nos locais DC iguais ou diferentes e podem compreender uma pluralidade de L2GWs 1022 acoplados a nós de borda correspondentes 1012, e uma pluralidade de comutadores intermediários 1024 acoplados a L2GWs correspondentes 1022. Os comutadores intermediários 1024 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs 1026. Os componentes das pseudo redes de Camada 2 podem ser dispostos como mostrado na Figura 10 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0073] Com base no mecanismo de restrição de domínio de endereço 1000, um endereço MAC de um L2GW 1022 em um domínio de rede de Camada 2 1020 pode ser usado como um proxy para todos ou uma pluralidade de endereços IP dos hosts (por exemplo, que executa aplicações IP ) nos outros domínios de rede de Camada 2 1020. Em uma primeira opção (opção 1), um endereço MAC local para um L2GW local 1022 nos domínios de rede de Camada 2 1020 pode ser usada como proxy para os endereços IP dos hosts nos outros domínios de rede de Camada 2 1020. Neste cenário, apenas os endereços IP dos hosts locais podem ser aprendidos pelos comutadores intermediários 1024 e hosts / servidores / VMs 1026 nos mesmos domínios de rede de Camada 2 locais 1020. Os endereços MAC de L2GWs exteriores 1022 em outros domínios de rede de Camada 2 1020 podem não ser expostos aos domínios de rede de Camada 2 locais 1020. Por exemplo, a opção 1 pode ser usada se o L2GW local 1022 pode não terminar um quadro de dados de entrada que não é destinado ou orientado para o L2GW local 1022.

[0074] Alternativamente, em uma segunda opção (opção 2), os endereços MAC de L2GWs locais 1022 em domínios de rede de Camada 2 locais 1020 e os endereços MAC de L2GWs exteriores 1022 em outro domínio de rede de Camada 2 1020 podem ser aprendidos em cada domínio de rede de Camada 2 1020. Nesta opção, os endereços MAC de L2GWs exteriores 1022, que correspondem a domínios de rede de Camada 2 exteriores 1020 podem ser devolvidos em resposta a pedidos de host locais em um domínio de rede de Camada 2 local 1020, por exemplo, quando um host pretende comunicar com um host exterior em um domínio de rede de Camada 2 exterior e solicita o endereço do host exterior. Opção 2 pode ter algumas vantagens sobre a opção 1 em algumas situações.

[0075] De acordo com o mecanismo de restrição de domínio de endereço 1000, cada L2GW 1022 pode estar ciente de todos os endereços de hosts no mesmo domínio de rede de Camada 2 local 1020 do L2GW 1022, por exemplo, usando um esquema ARP reverso ou outros métodos. Cada L2GW 1022 pode também informar outros L2GWs 1022 em outros domínios de endereço de Camada 2 1020 os endereços de hosts IP, os quais podem ser associados com um ou uma pluralidade de VLANs ou identificadores de VLAN (VIDs) no domínio de endereço de Camada 2 local.

[0076] Para resolver endereços através dos domínios de endereço diferentes, um pedido ARP pode ser enviado a partir de um primeiro host 1026 (host A) para um L2GW local correspondente 1022 em um primeiro domínio de endereço (domínio 1). O host A pode enviar o pedido ARP para obter o endereço MAC de um segundo host 1026 (host B) em um segundo domínio de endereço (domínio 2). Se o L2GW local 1022 tem uma entrada para o host B, por exemplo, o endereço IP do host B, o L2GW local 1022 pode responder ao pedido ARP enviando seu próprio endereço MAC (opção 1) ou o endereço MAC de um segundo L2GW 1022 associado com host B no domínio 2 (opção 2) para o host A. O pedido ARP enviado em um domínio de endereço, por exemplo, o domínio 1, pode não ser encaminhado (pelo L2GW local 1022) para um outro domínio de endereço, por exemplo, domínio 2. Se o L2GW local 1022 não inclui uma entrada para um VID e / ou endereço IP para o host B, o L2GW local 1022 pode assumir que o host B não existe e pode não enviar uma resposta de endereço para host A. Por exemplo, os L2GWs 1022 podem empurrar seus endereços IP de host locais em uma base regular ou periódica para seus pares L2GWs 1022. Como tal, alguns L2GWs 1022 podem não ter recebidos os endereços IP de hosts recém configurados em outras localizações.

[0077] A Figura 11 ilustra uma modalidade de um sistema de encaminhamento de quadro de dados 1100 que pode ser usado para transmitir mensagens ou quadros entre pseudo redes de Camada 2 sobre domínios de endereço múltiplos. As pseudo redes de Camada 2 ao longo dos domínios de endereço podem compreender um provedor de serviço ou rede central 1110 e uma pluralidade de domínios de rede de Camada 2 1120 que podem ser acoplados ao provedor de serviço ou rede de núcleo 1110 através de uma pluralidade de nós de borda 1112. Os domínios de rede de Camada 2 1120 podem ser localizados em um ou mais localizações DC ou localizações e podem compreender uma pluralidade de L2GWs 1122 acoplados a nós de borda correspondentes 1112, e uma pluralidade de comutadores intermediários 1124 acoplados a L2GWs correspondentes 1122. Os comutadores intermediários 1124 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs 1126. Os componentes das pseudo redes de Camada 2 podem ser dispostos como mostrado na Figura 11 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0078] Com base no esquema de encaminhamento de quadro de dados 1100, um primeiro L2GW 1022 (GW1) pode receber um primeiro quadro 1140, por exemplo, um quadro Ethernet, a partir de um primeiro host 1126 (host A) em um primeiro domínio de endereço 1120 (domínio 1). O primeiro quadro 1140 pode ser destinado a um segundo host 1126 (host B) em um segundo domínio de endereço 1120 (domínio 2). O primeiro quadro 1140 pode compreender um MAC-DA 1142 para um L2GW 1122 (GW). O Host A pode obter o endereço MAC do GW em uma resposta ARP de GW1 em troca de um pedido ARP para o host B. GW pode corresponder a GW1 no domínio 1 (de acordo com a opção 1) ou a um segundo L2GW 1122 (GW2) no domínio 2 (de acordo com a opção 2). O primeiro quadro 1140 pode também compreender um MAC-SA 1144 para o host A (MAC de A), um IP-DA 1146 para o host B (B), um IP-SA 1148 para o host A (A), e carga.

[0079] Com base na opção 1, GW1 pode receber o primeiro quadro 1140, procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP-DA 1146 para o host B), e substituir o MAC-DA 1142 para GW no primeiro quadro 1140 com um MAC-DA 1162 para GW2 em um quadro interior 1160. GW1 também pode substituir o MAC-SA 1144 para o host A (MAC de A) no primeiro quadro 1140 com um MAC-SA 1164 para GW1 no quadro interior 1160. O quadro interior 1160 pode incluir também um IP-DA 1166 para host B (B), um IP-SA 1168 para o host A (A), e carga. GW1 pode enviar o quadro interior 1160 para o domínio 2 via o provedor de serviço ou a rede de núcleo 1110. Com base na opção 2, GW1 pode filtrar todos os quadros de dados destinados a GW2 ou qualquer outro L2GW exterior 1122, por exemplo, com base em uma lista de acesso, substituir os endereços de origem dos quadros de dados (MAC-SA 1144 para o host A ou MAC de A) com o endereço MAC do próprio GW1, e em seguida, encaminhar os quadros de dados com base no MAC de destino.

[0080] GW2 pode receber o quadro interior 1160 e processar o quadro interior 1160 para traduzir os endereços MAC do quadro. Com base na opção 1, GW2 pode receber o quadro interior 1160, procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP-DA 1166 para o host B), e substituir o MAC-DA 1162 para GW2 no quadro interior 1160 com um MAC-DA 1182 para o host B (MAC de B) em um segundo quadro 1180. GW2 pode também substituir o MAC-SA 1164 para GW1 no quadro interior 1160 com um MAC- SA 1184 para GW2 no segundo quadro 1180. O segundo quadro 1180 pode incluir também um IP-DA 1186 para o host B (B), um IP-SA 1188 para o host A (A), e carga. GW2 pode então enviar o segundo quadro 1180 para o host de destino B. Com base na opção 2, GW2 pode apenas procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP- DA 1166 para o host B), e substituir o MAC-DA 1162 para GW2 com um MAC-DA 1182 para o host B (MAC de B) no segundo quadro 1180. No entanto, GW2 pode manter o MAC-SA 1164 para.

[0081] Como descrito acima, GW2 pode realizar a tradução de endereço MAC usando o IP-DA 1166 para host B no quadro interior 1160 para encontrar um MAC-DA correspondente 1182 para o host B (MAC de B) em um segundo quadro 1180. Este passo de tradução MAC pode exigir cerca da mesma quantidade de trabalho como um esquema de NAT, por exemplo, para traduzir o endereço IP público para o endereço IP privado. A tradução de endereço MAC no esquema de encaminhamento de quadro de dados 1100 pode ser baseada em usar o endereço IP de host para encontrar o endereço MAC correspondente, enquanto o esquema de NAT é baseado em uma sessão TCP.

[0082] A Figura 12 ilustra uma modalidade de outro esquema de encaminhamento de quadro de dados 1200 que pode ser usado para transmitir mensagens ou quadros entre pseudo redes de Camada 2 sobre domínios de endereço múltiplos. Especificamente, as pseudo redes de Camada 2 podem ser interligadas através de uma rede IP / MPLS. As pseudo redes de Camada 2 ao longo dos domínios de endereço pode compreender uma rede IP / MPLS 1210 e uma pluralidade de domínios de rede de Camada 2 1220 que podem ser acoplados à rede IP / MPLS 1210 através de uma pluralidade de nós de borda 1212. A rede IP / MPLS 210 pode oferecer um serviço IP para suportar um inter domínio entre os domínios de endereço, por exemplo, os domínios de rede de Camada 2 1220. Os domínios de rede de Camada 2 1220 podem ser localizados em um ou mais locais DC ou localizações e podem compreender uma pluralidade de L2GWs 1222 acoplados a nós de borda correspondentes 1212, e uma pluralidade de comutadores intermediários 1224 acoplados a L2GWs correspondentes 1222. Os comutadores intermediários 1224 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs 1226. Os componentes das pseudo redes de Camada 2 podem ser dispostos como mostrado na Figura 12 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0083] Com base no esquema de encaminhamento de quadro de dados 1200, um primeiro L2GW 1022 (GW1) pode receber um primeiro quadro 1240, por exemplo, um quadro Ethernet, a partir de um primeiro host 1226 (host A) em um primeiro domínio de endereço (domínio 1). O primeiro quadro 1240 pode ser destinado a um segundo host 1226 (host B) em um segundo domínio de endereço (domínio 2). O primeiro quadro 1240 pode compreender um MAC-DA 1242 para um L2GW 1222 (GW). O Host A pode obter o endereço MAC do GW em uma resposta ARP de GW1 em troca de um pedido ARP para o host B. GW pode corresponder a GW1 no domínio 1 (de acordo com a opção 1) ou a um segundo L2GW 1222 (ou GW2) em domínio 2 (de acordo com a opção 2). O primeiro quadro 1240 pode também compreender um MAC-SA 1244 para o host A (MAC de A), um IP-DA 1246 para o host B (B), um IP-SA 1248 para o host A (A), e carga.

[0084] GW1 pode receber um primeiro quadro 1240 e processar o quadro com base em uma das duas opções. Em uma primeira opção, GW1 pode receber o primeiro quadro 1240 e adicionar um cabeçalho IP para obter um quadro interior 1250. O cabeçalho IP pode incluir um IP-DA 1251 para GW2 e um IP-SA 1252 para GW1. GW1 também pode processar o primeiro quadro 1240 semelhante ao esquema de encaminhamento de quadro de dados 1100 para obter no quadro interior 1250 um MAC-DA 1253 para GW2, um MAC-SA 1254 para GW1, um IP-DA 1256 para o host B (B), e um IP-SA 1257 para host (A). GW1 pode enviar o quadro interior 1250 para GW2 através da rede IP / MPLS 1210. GW2 pode receber o quadro interior 1250 e processar o quadro interior 1250 semelhante ao esquema de encaminhamento de quadro de dados 1100 para obter um segundo quadro 1280, que compreende um MAC-DA 1282 para o host B (MAC de B), um MAC-SA 1284 para GW1 (de acordo com a opção 1) ou GW2 (de acordo com a opção 2), um IP-DA 1286 para o host B (B), um IP-SA 1288 para o host A (A), e carga. GW2 pode então encaminhar o segundo quadro 1250 para host B.

[0085] Em uma segunda opção, GW1 pode receber o primeiro quadro 1240 e substituir o MAC-DA 1242 para GW no primeiro quadro 1240 com um IP-DA 1262 para GW2 em um quadro interior 1260. GW1 também pode substituir o MAC-SA 1244 para o host A (MAC de A) no primeiro quadro 1240 com um IP-SA 1264 para GW1 no quadro interior 1260. O quadro interior 1260 pode incluir também um IP-DA 1266 para host B (B), um IP-SA 1268 para o host A (A), e carga. GW1 pode enviar o quadro interior 1260 para GW2 através da rede IP / MPLS 1210. GW2 pode receber o quadro interior 1260 e substituir o IP-DA 1162 para GW2 no quadro interior 1260 com um MAC-DA 1282 para o host B (MAC de B) em um segundo quadro 1280. GW2 pode também substituir o PI-SA 1264 para GW1 no quadro interior 1260 com um MAC-SA 1284 para GW2 (de acordo com a opção 1) ou GW1 (de acordo com a opção 2) no segundo quadro 1280. O segundo quadro 1280 pode incluir também um IP-DA 1286 para o host B (B), um IP-SA 1288 para o host A (A), e carga. GW2 pode então encaminhar o segundo quadro 1250 para host B.

[0086] Na extensão ou pseudo redes de Camada 2 acima em vários domínios, cada L2GW pode ser configurado para mapeamento IP-MAC de todos os hosts em cada VLAN no domínio de endereço correspondente do L2GW. Cada L2GW também pode enviar os endereços IP de todos os hosts em cada VLAN no domínio de endereço correspondente para outros L2GWs em outros domínios de endereço em uma base regular ou periódica. Assim, os L2GWs nos domínios de endereço podem obter endereços IP de hosts em cada VLAN para todos os domínios de endereço da rede de pseudo Camada 2. Os endereços MAC dos hosts em cada domínio de endereço não podem ser enviados pelo L2GW local para os L2GWs dos outros domínios de endereço, o que pode reduzir substancialmente o tamanho dos dados trocados entre os L2GWs. No entanto, os L2GWs de domínios de endereço diferentes podem trocar entre eles os endereços MAC correspondentes às aplicações não IP, por exemplo, se o número de aplicações não IP é relativamente pequeno. Um método BGP ou semelhante pode ser usado para trocar a informação de endereço, incluindo as atualizações, entre os L2GWs através dos domínios de endereço.

[0087] A Tabela 2 ilustra um exemplo de mapeamento de endereços de host para endereços MAC do L2GW correspondente em pseudo redes de Camada 2. Uma pluralidade de endereços MAC de L2GW (por exemplo, GW-A MAC e GW-B MAC) pode ser mapeada para uma pluralidade de endereços de host correspondentes. Cada endereço MAC de L2GW pode ser mapeado para uma pluralidade de endereços IP de host (ou MAC) em uma pluralidade de VLANs (por exemplo, VID-1, VID-2, VID-n, ...), que podem ser do mesmo domínio de endereço. Tabela 2: Mapeamento IP-MAC

[0088] Os esquemas de extensão ou pseudo redes de Camada 2 acima podem restringir os endereços MAC de um domínio de endereço de ser aprendido por quaisquer comutadores / servidores / VMs em outro domínio de endereço. Os esquemas podem também fornecer um mecanismo escalonável para conectar substancialmente grandes redes de Camada 2 em vários locais. Em relativamente grandes redes de Camada 2 que abrangem domínios de endereço múltiplos, os esquemas podem limitar o número de endereços MAC que podem ser aprendidos por qualquer comutador nas pseudo redes de Camada 2, onde cada comutador pode apenas aprender os endereços MAC do domínio de endereço local do comutador. O sistema também pode fornecer descoberta de acessibilidade através de múltiplos domínios de endereço usando a resolução de endereço escalonável através dos domínios de endereço. Além disso, os esquemas podem facilitar o encaminhamento entre domínios de endereço e a transmissão para endereços desconhecidos, e suportar grupos de multicast.

[0089] A Figura 13 ilustra uma modalidade de outro esquema de encaminhamento de quadro de dados 1300 que pode ser usado para encaminhar mensagens ou quadros entre pseudo redes de Camada 2 sobre domínios de endereço múltiplos e localizações. O esquema de encaminhamento de quadro de dados 1300 pode ser baseado em opção 1 descrita acima, e pode ser usado para transmitir quadros a partir de um host que se move a partir de uma localização anterior para uma nova localização nas pseudo redes de Camada 2 e mantém o mesmo endereço MAC aprendido para um segundo host. As pseudo redes de Camada 2 podem compreender um provedor de serviço ou rede central 1310 e uma pluralidade de domínios de rede de Camada 2 1320 que pode ser acoplada ao provedor de serviço ou rede de núcleo 1310 através de uma pluralidade de nós de borda 1112. Os domínios de rede de Camada 2 1320 podem estar localizados em locais DC múltiplos ou localizações e podem compreender uma pluralidade de L2GWs 1322 acoplados a nós de borda correspondentes 1312, e uma pluralidade de comutadores intermediários 1324 acoplados a L2GWs correspondentes 1322. Os comutadores intermediários 1324 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs 1326. Os componentes das pseudo redes de Camada 2 podem ser dispostos como mostrado na Figura 13 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0090] Com base no esquema de encaminhamento de quadro de dados 1300, GW3 pode receber um primeiro quadro 1340, por exemplo, um quadro Ethernet, a partir de um primeiro host 1326 (host A) após a passagem da Loc. 1 para Loc. 3. O quadro 1340 pode ser destinado a um segundo host 1326 (host B) em Loc. 2. O primeiro quadro 1340 pode compreender um MAC-DA 1342 para GW1 em Loc. 1, um MAC-SA 1344 para o host A (MAC de A), um IP-DA 1346 para o host B (B), um IP-SA 1348 para host A (A), e carga. GW3 pode processar o primeiro quadro 1340 e substituir o MAC-SA 1344 para host A (MAC de A) no primeiro quadro 1340 com um MAC- SA 1354 para GW3 em um primeiro quadro interior 1350, por exemplo, semelhante ao esquema de encaminhamento de quadro de dados 1100. O primeiro quadro interior 1350 também pode incluir um MAC-DA 1352 para GW1, um IP-DA 1356 para o host B (B), um IP-SA 1358 para o host A (A), e carga. GW3 pode enviar o primeiro quadro interior 1350 para Loc. 1 via provedor de serviço ou a rede de núcleo 1310.

[0091] GW1 pode receber o primeiro quadro interior 1350, procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP-DA 1356 para o host B), e substituir o MAC-DA 1352 para GW1 no primeiro quadro de 1340 com um MAC-DA 1362 para GW2 em uma segundo quadro interior 1360. O segundo quadro interior 1360 também pode incluir um MAC-SA 1364 para GW3, um IP-DA 1366 para o host B (B), um IP-SA 1368 para o host A (A), e carga. GW1 pode enviar o segundo quadro interior 1360 para Loc. 2 via provedor de serviço ou a rede de núcleo 1310.

[0092] GW2 pode receber o segundo quadro interior 1360 e processar o segundo quadro interior 1360 para traduzir os endereços MAC do quadro. GW2 pode receber o segundo quadro interior 1360, procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP-DA 1366 para o host B), e substituir o MAC-DA 1362 para GW2 no quadro interior 1360 com um MAC-DA 1382 para o host B (MAC de B) em um segundo quadro 1380. GW2 também pode substituir o MAC-SA 1364 para GW3 no segundo quadro interior 1360 com um MAC-SA 1384 para GW2. GW2 pode então enviar o segundo quadro 1380 para o host de destino B.

[0093] Além disso, host B pode mover-se a partir de Loc. 2 para outro local, por exemplo, Loc. 4 (não mostrado). Se GW2 aprendeu que o host B passou de Loc. 2 para Loc. 4, então GW2 pode enviar atualizações para seus pares (outros L2GWs 1322 em outros locais). Quando um L2GW 1322 em Loc. 4 (GW4) descobre que o host B é adicionado ao seu domínio, GW4 também pode atualizar seus pares. Como tal, cada L2GW 1322 pode ter informações atualizadas sobre o endereço de host B. Se um L2GW 1322 não tem conhecimento de que o host B passou de Loc. 2 para Loc. 4, então L2GW 1322 ainda pode enviar um quadro destinado a host B a partir de hosts locais para Loc. 2. Por sua vez, GW2 pode receber e transmitir o quadro em Loc. 2, onde o quadro é perdido desde que o host B passou de Loc. 2. O quadro pode ser perdido temporariamente até que o quadro é reenviado pelo L2GW 1322 após host B anunciar sua nova localização para o L2GW 1322.

[0094] A Figura 14 ilustra uma modalidade de outro esquema de encaminhamento de quadro de dados 1400 que pode ser usado para transmitir mensagens ou quadros entre pseudo redes de Camada 2 sobre domínios de endereço múltiplos e localizações. O esquema de encaminhamento de quadro de dados 1400 pode ser baseado em opção 2 descrita acima, e pode ser usado para transmitir quadros a partir de um host que se move a partir de uma localização anterior para uma nova localização nas pseudo redes de Camada 2 e mantém o mesmo endereço MAC aprendido para um segundo host. As pseudo redes de Camada 2 podem compreender um provedor de serviço ou rede central 1410 e uma pluralidade de domínios de rede de Camada 2 1420 que podem ser acoplados ao provedor de serviço ou rede central 1410 por meio de uma pluralidade de nós de borda 1112. Os domínios de rede de Camada 2 1420 podem estar localizados em locais DC múltiplos ou localizações e podem compreender uma pluralidade de L2GWs 1422 acoplados a nós de borda correspondentes 1412, e uma pluralidade de comutadores intermediários 1424 acoplados a L2GWs correspondentes 1422. Os comutadores intermediários 1424 podem também ser acoplados a uma pluralidade de hosts / servidores / VMs 1426. Os componentes das pseudo redes de Camada 2 podem ser dispostos como mostrado na Figura 14 e podem ser semelhantes aos componentes correspondentes da rede de Camada 2 virtual 200.

[0095] Com base no esquema de encaminhamento de quadro de dados 1400, GW3 pode receber um primeiro quadro 1440, por exemplo, um quadro Ethernet, a partir de um primeiro host 1426 (host A) após a passagem da Loc. 1 para Loc. 3. O quadro 1440 pode ser destinado a um segundo host 1426 (host B) em Loc. 2. O primeiro quadro 1340 pode compreender um MAC-DA 1442 para GW2 em Loc. 2, um MAC-SA 1444 para o host A (MAC de A), um IP-DA 1446 para o host B (B), um IP-SA 1448 para host A (A), e carga. GW3 pode processar o primeiro quadro 1440 e substituir o MAC-SA 1444 para host A (MAC de A) no primeiro quadro 1440 com um MAC- SA 1464 para GW3 em um quadro interior 1460, por exemplo, semelhante ao esquema de encaminhamento de quadro de dados 1100. O quadro interior 1460 também pode incluir um MAC-DA 1462 para GW2, um IP-DA 1466 para o host B (B), um IP-SA 1468 para o host A (A), e carga. GW3 pode enviar o quadro interior 1460 para Loc. 2 via provedor de serviço ou a rede de núcleo 1410.

[0096] GW2 pode receber o quadro interior 1460 e processar o quadro interior 1460 para traduzir os endereços MAC do quadro. GW2 pode receber o quadro interior 1460, procurar o endereço IP VID / de destino do host B (por exemplo, como indicado pelo IP-DA 1466 para o host B), e substituir o MAC-DA 1462 para GW2 no quadro interior 1460 com um MAC-DA 1482 para o host B (MAC de B) em um segundo quadro 1480. O quadro interior 1460 pode também enviar um 1484 MAC-SA para GW3. GW2 pode então enviar o segundo quadro 1480 para o host de destino B.

[0097] Além disso, host B pode mover-se a partir de Loc. 2 para outro local, por exemplo, Loc. 4 (não mostrado). Se GW2 aprendeu que o host B passou de Loc. 2 para Loc. 4, então GW2 pode enviar atualizações para seus pares (outros L2GWs 1322 em outros locais). Quando um L2GW 1322 em Loc. 4 (GW4) descobre que o host B é adicionado ao seu domínio, GW4 também pode atualizar seus pares. Como tal, cada L2GW 1322 pode ter informações atualizadas sobre o endereço de host B. Se um L2GW 13222 não tem conhecimento de que o host B passou de Loc. 2 para Loc. 4, então L2GW 1322 ainda pode enviar um quadro destinado a host B a partir de hosts locais para Loc. 2. Por sua vez, GW2 pode receber e transmitir o quadro em Loc. 2, onde o quadro é perdido desde que o host B passou de Loc. 2. O quadro pode ser perdido temporariamente até que o quadro é reenviado pelo L2GW 1322 após host B anunciar sua nova localização para o L2GW 1322.

[0098] As redes ou extensão de pseudo Camada 2 descritas acima podem suportar a resolução de domínio de endereço em cada endereço e podem usar um mecanismo para manter os L2GWs atualmente atualizados com endereços IP de todos os hosts em seus domínios / locais. Resolução de endereço e atualização de endereço IP podem ser implementadas em um dos dois cenários. O primeiro cenário corresponde a quando um host ou VM está configurado para enviar mensagens ARP gratuitas ao ser adicionado ou depois de se mudar para uma rede. O segundo cenário corresponde à quando um host ou VM que é adicionado ou mudou-se para uma rede não envia anúncios ARP. Os dois cenários podem ser tratados como descritos nas redes de Camada 2 virtual acima.

[0099] As redes de Camada 2 virtual e da mesma forma as pseudo redes de Camada 2 descritas acima podem suportar a resolução de endereço em cada local / domínio e um mecanismo para manter cada L2GW atualmente atualizado com os endereços IP dos hosts locais em sua localização / domínio. Em um cenário, quando um host ou uma máquina virtual é adicionado à rede, o host ou VM pode enviar um anúncio ARP, como uma mensagem ARP gratuita, para a sua rede de Camada 2 ou área local. Em outro cenário, o host ou VM adicionado à rede pode não enviar um anúncio ARP.

[00100] No primeiro cenário, uma nova VM em uma rede de Camada 2 ou localização / domínio pode enviar uma mensagem ARP gratuita a um L2GW. Quando o L2GW recebe a mensagem ARP gratuita, o L2GW poderá atualizar sua IPAddrTable local, mas não pode encaminhar a mensagem ARP gratuita para outros locais / domínios ou redes de Camada 2. Além disso, o L2GW pode usar um temporizador para cada entrada na IPAddrTable para tratar o caso de desligamento ou remoção de um host de uma localização / domínio. Se o temporizador de uma entrada está prestes a expirar, o L2GW pode enviar um ARP (por exemplo, através de unicast) para o host da entrada. Enviando o ARP como uma mensagem de unicast em vez de transmitir o ARP pode evitar inundar o domínio de Camada 2 local do host e o L2GW. Quando um host se move a partir de um primeiro local para um segundo local, um L2GW pode receber uma mensagem de atualização da primeira localização e / ou segunda localização. Se o L2GW detecta que o host existe tanto no local da primeira e segunda localização, o L2GW pode enviar uma mensagem ARP local na primeira localização para verificar que o host não existe mais na primeira localização. Ao determinar que o host não está mais presente na primeira localização, por exemplo, se nenhuma resposta à mensagem ARP é detectada, o L2GW poderá atualizar sua IPAddrTable local de acordo. Se o L2GW recebe uma resposta para a mensagem ARP para sua própria localização, em seguida, um mecanismo de multi- regresso MAC de BGP pode ser usado.

[00101] No segundo cenário, o novo host em um local pode não enviar um anúncio ARP. Neste caso, quando uma aplicação (por exemplo, em um host) precisa resolver o endereço MAC de um host IP, a aplicação pode enviar um pedido ARP que pode ser transmitido na localização. O pedido ARP pode ser interceptado por um L2GW (ou Comutador Topo de Rack (ToR)), por exemplo, através da implementação de uma função ARP proxy. Em um DC relativamente grande, o L2GW pode não ser capaz de processar todos os pedidos ARP. Em vez disso, uma pluralidade de representantes L2GW (por exemplo, comutadores de ToR) pode interceptar os anúncios ARP. O L2GW pode empurrar para baixo os endereços IP (por exemplo, um resumo de endereços IP) que são aprendidos a partir de outros locais para seus representantes correspondentes (comutadores de ToR). Os representantes podem, então, interceptar os pedidos ARP dos hosts ou servidores locais. Se um endereço IP no pedido ARP de um host ou servidor está presente no IPAddrTable do L2GW, o L2GW pode retornar uma resposta ARP com o endereço MAC do L2GW para o host ou servidor, sem encaminhar o pedido ARP encaminhado adicionalmente. Para as aplicações não IP, por exemplo, as aplicações que rodam diretamente sobre Ethernet sem IP, as aplicações podem usar endereços MAC como DAs ao enviar dados. As aplicações não IP não poderão enviar uma mensagem ARP antes de enviar os quadros de dados. Os quadros de dados podem ser encaminhados através de Protocolos de inundação desconhecidos ou Protocolos de Registro de MAC Múltiplos (MMRP).

[00102] Em um cenário, uma aplicação (por exemplo, em um host) pode enviar uma mensagem ARP gratuita ao entrar em uma das redes de Camada 2 interconectadas em um local para obter um endereço MAC para um endereço de destino IP. Quando o L2GW ou seu representante (por exemplo, comutador de ToR) pode receber o pedido ARP e verificar sua tabela de hosts IP. Se o endereço IP é encontrado na tabela, o L2GW pode enviar uma resposta ARP para a aplicação. O L2GW pode enviar seu endereço MAC na resposta se o endereço de destino IP corresponde a um host IP em outro local. Se o endereço IP não for encontrado, nenhuma resposta pode ser enviada a partir do L2GW, que pode manter os atuais ou últimos atualizados endereços IP dos hosts em todos os locais. Em DCs relativamente grandes, L2GWs múltiplos podem ser utilizados, por exemplo, no mesmo local, em que cada L2GW pode lidar com um subconjunto de VLANs. Como tal, cada L2GW pode precisar manter um subconjunto de endereços IP que compreende os endereços IP dos hosts da VLAN correspondente.

[00103] No caso de DCs substancialmente grandes, por exemplo, que compreendem dezenas de milhares de máquinas virtuais, pode ser difícil para um único nó lidar com todos os pedidos ARP e / ou mensagens ARP gratuitas. Neste caso, os vários esquemas podem ser considerados. Por exemplo, uma pluralidade de nós ou L2GWs pode ser utilizada para tratar diferentes subconjuntos de VLANs dentro de um DC, como descrito acima. Adicionalmente ou alternativamente, vários representantes podem ser atribuídos para um L2GW em cada localização. Por exemplo, uma pluralidade de comutadores de ToR ou comutadores de acesso pode ser usada. Cada representante do L2GW pode ser responsável por interceptar mensagens ARP gratuitas sobre seus enlaces descendentes correspondentes ou sob a forma de um Protocolo de Conexão de Porta. Os representantes podem enviar uma lista de endereços consolidada (AddressList) para seus L2GWs. O L2GW também pode empurrar para baixo suas listas de endereços IP aprendidas de outros locais para seus representantes. Se houver L2GWs múltiplos em um local que é responsável por diferentes subconjuntos de VLANS, os representantes podem precisar enviar uma pluralidade de mensagens consolidadas que compreende cada AddressLists nas VLANs associadas aos L2GWs correspondentes.

[00104] Em comparação com o esquema OTV da Cisco, usar a rede de Camada 2 virtual descrita acima pode reduzir substancialmente o tamanho de tabelas de encaminhamento em comutadores intermediários em cada localização. Os comutadores em um local podem não precisar aprender endereços MAC de hosts IP em outros locais, por exemplo, assumindo que a maioria dos hosts executam aplicações IP. Este esquema pode também reduzir substancialmente o tamanho da informação de endereço trocada entre os L2GWs. Por exemplo, uma sub-rede que pode compreender milhares de VMs pode ser mapeada para um endereço MAC de L2GW. O esquema de Camada 2 hierárquico de rede de Camada 2 virtual pode usar o padrão 802.1ah, que pode ser suportado por conjuntos de chips Ethernet comerciais, enquanto esquema da Cisco usa encapsulamento IP proprietário. Ambos os esquemas podem usar pares de endereço de dispositivo de gateway de localização (L2GW) como endereço de destino exterior. O esquema de Camada 2 hierárquico pode também utilizar tradução de endereço, o que pode ser suportada por gateways IP atuais. No entanto, o esquema de Camada 2 hierárquico pode usar tradução de endereço MAC, em vez da tradução de endereço IP. A tradução de endereço MAC pode precisar de implementação de NAT grau de portador que pode realizar a tradução de endereço para dezenas de milhares de endereços.

[00105] Em uma modalidade, uma VLAN pode se estender por vários locais. Assim, um grupo de multicast também pode se estender em vários locais. Especificamente, o grupo de multicast pode abranger todo um subconjunto de locais na rede de Camada 2 virtual. Por exemplo, se há cerca de 10 localizações na rede de Camada 2 virtual, o grupo de multicast pode apenas abranger três dos dez locais. Um grupo de multicast dentro de uma instância de serviço pode ser configurado por um sistema de administrador de rede (NMS) ou pode ser automaticamente estabelecido na Camada 2 usando MMRP. Desde que L2GW suporta 802.1ah, o L2GW pode ter um componente embutido para mapear grupos de multicast de clientes para próprios grupos de multicast na rede de núcleo. Em um cenário de pior caso, o L2GW pode replicar os quadros de dados de multicast para todos os locais da instância de serviço. Por exemplo, segundo dados de pesquisa de Microsoft, cerca de um em cada quatro tráfegos pode ir para um local diferente. Assim, a replicação L2GW pode ser mais simples do que implementar um mecanismo complicado no núcleo de Provedor.

[00106] A rede de Camada 2 virtual pode suportar o tráfego de transmissão, como para pedidos ARP e / ou pedidos de Protocolo de Configuração de Host Dinâmico (DHCP). O tráfego de transmissão pode ser suportado pela criação de vários representantes ARP, tais como comutadores de Tor, em cada localização. O tráfego de transmissão também pode ser suportado pela adição de um novo componente para o Protocolo de Conexão de Porta para os representantes para manter atualizações atuais de todos os hosts IP a partir dos servidores. Além disso, o L2GW pode empurrar para baixo em uma base periódica ou regular todos os endereços IP de host aprendidos de outros locais.

[00107] Em alguns casos, o L2GW pode receber DAs desconhecidos. O L2GW pode manter atualizações atuais de todos os hosts (ou aplicações) em seu local e periodicamente ou regularmente empurrar sua informação de endereço para todos os pares (outros L2GWs em outros locais). Se o L2GW recebe um quadro composto por um DA desconhecido, o L2GW pode transmitir o quadro para as demais localizações. Para evitar ataques à rede, um limite pode ser imposto sobre o número máximo de vezes que o L2GW pode encaminhar ou transmitir um DA desconhecido recebido. O L2GW pode ser configurado para aprender os endereços dos comutadores intermediários em outro local para evitar confundir um endereço de comutador intermediário para um endereço desconhecido antes de enviar o endereço para outra localização. Embora possa haver dezenas de milhares de VMs em cada localização DC, o número de comutadores de cada DC pode ser limitado, tal como o número de comutadores de acesso ou ToR, comutadores de final de linha ou de agregação e / ou comutadores centrais. O L2GW pode aprender os endereços MAC de todos os comutadores intermediários em uma localização antes do tempo, por exemplo, através de uma Unidade de Dados de Protocolo de Ponte (BPDU) a partir de cada comutador. As mensagens podem não ser enviadas diretamente aos comutadores intermediários, exceto para sistema de gestão ou mensagens de Operações, Administração e Manutenção (OAM). Um comutador intermediário que espera ou está configurado para receber mensagens NMS / OAM pode permitir que outros comutadores na localização aprendam seu endereço MAC, pelo envio de uma mensagem de autonomia para um anúncio MMRP ou NMS.

[00108] Em algumas modalidades, os L2GWs podem utilizar BGP, por exemplo, em vez de IS-IS, para troca de informações de endereço. Uma pluralidade de opções pode ser utilizada para controlar comunicações de Camada 2 (L2). Por exemplo, opções de encaminhamento podem incluir encaminhamento de Camada 2 somente com MAC e MAC, encaminhamento de Camada 2 sobre MPLS, e encaminhamento de Camada 2 em rede de Camada 3. Opções de plano de controle de Camada 2 podem incluir uma controle de malha IS-IS de Camada 2, controle estático MPLS de Camada 2,5, Protocolo de Distribuição de Rótulo (LDP), Engenharia de Tráfego (TE) de Protocolo de Reserva de Recurso (RSVP) utilizando Primeiro Caminho Mais Curto baseado em Constante de Protocolo de Gateway Interior (IGP) (CSFP), e descoberta BGP. Alguns problemas de mapeamento de VLAN podem também ser considerados, tais como o mapeamento de VLAN-MAC necessário para a singularidade e se VLANs de Ponte de Rede (por exemplo, VLANs-4K) podem ser muito pequenas para um DC. A Tabela 3 ilustra uma pluralidade de opções de plano de controle que podem ser utilizadas para o plano de controle de Camada 2. As opções podem ser baseadas em IEEE 802.1ah, IEEE 802.1q, e 802.1aq IEEE, todos os quais são aqui incorporados por referência. A Tabela 4 ilustra algumas das vantagens e desvantagens (prós e contras) das opções de plano de controle na Tabela 2. Tabela 3: Opções de Plano de Controle de Camada 2

Tabela 4: Opções de plano de controle

[00109] Pode haver uma pluralidade de diferenças entre OTV da Cisco e BGP que podem ser suportadas na rede de Camada 2 virtual. Por exemplo, aspectos básicos de OTV podem incluir grupos de multicast OTV, uso OTV IS-IS, que pode exigir MT-IS-IS, e encaminhamento OTV. Além disso, BGP pode suportar mapeamento BGP-MAC e sobreposição de IP, como para grupo de multicast DC. Mapeamento BGP-MAC pode também usar MT-BGP. Além disso, IBGP pode ser suportado por MT-IS- IS e utilizar IS-IS para topologia de par (por exemplo, Verificação de Caminho Comutado de Rótulo (LSVP)).

[00110] Na rede de Camada 2 virtual acima, o número de aplicações dentro uma rede de Camada 2 (ou DC) pode aumentar substancialmente, por exemplo, ao longo do tempo. Assim, um mecanismo pode ser necessário para evitar problemas associados com redes de Camada 2 substancialmente grandes. Esses problemas podem incluir um comportamento imprevisível de servidores / hosts e suas aplicações. Por exemplo, os servidores / hosts podem corresponder a diferentes fornecedores, onde alguns podem ser configurados para enviar mensagens ARP e outros podem ser configurados para transmitir mensagens. Além disso, típicos comutadores de Camada 2 de menor custo podem não ter recursos sofisticados para bloquear quadros de dados de transmissão de ter política implementada para limitar as inundações e transmissão. Hosts ou aplicações também podem envelhecer endereços MAC para direcionar mapeamento IP com frequência, por exemplo, em cerca de minutos. O host pode também frequentemente enviar mensagens ARP gratuitas, tais como quando o host desempenha uma passagem (de ativo para espera) ou quando o host tem uma falha de software. Em alguns casos, os componentes de rede de Camada 2 são divididos em subgrupos menores para confinar transmissão em um menor número de nós.

[00111] A Figura 15 ilustra uma modalidade de um esquema de transmissão típico 1500 que pode ser utilizado em uma rede / domínio de Camada 2, por exemplo, uma VLAN, que pode ser parte da redes de Camada 2 virtuais ou as pseudo redes de Camada 2 acima. A rede / domínio de Camada 2 ou VLAN pode compreender uma pluralidade de comutadores de acesso (SP) 1522 localizados em um Pod 1530, por exemplo, em um DC. A VLAN pode também compreender uma pluralidade de grupos de usuários fechados (CUGs) 1535 acoplados às ASs 1522. Cada CUG 1535 pode compreender uma pluralidade de comutadores de fim de linha (EOR) 1524 acoplados às ASs 1522, uma pluralidade de comutadores de ToR 1537 acoplados aos comutadores EoR 1524, e uma pluralidade de servidores / VMs 1539 acoplados aos comutadores de ToR 1537. As ASs 1522 podem ser acopladas a uma pluralidade de Pods (não mostrado) em outros DCs que podem corresponder a outras redes / domínios de Camada 2 de redes de Camada 2 virtual ou as pseudo redes de Camada 2. Os componentes da rede / domínio de Camada 2 ou o Pod 1530 podem ser dispostos como mostrado na Figura 15.

[00112] O esquema de transmissão típico 1500 pode sofrer de problemas de escalabilidade de transmissão. Por exemplo, quadros com DAs desconhecidos podem ser inundados no Pod 1530 para todos os sistemas finais na VLAN. Por exemplo, os quadros com DAs desconhecidos podem ser inundados para todos ou a pluralidade de servidores / VMs 1539 nas ASs 1522 nos CUGs 1535, tal como indicado pelas setas tracejadas na Figura 15. Os quadros com endereços desconhecidos podem também ser inundados na direção oposta, através de uma AS 1522, para uma pluralidade de outros Pods (em outros DCs) no núcleo, que podem ser associados com o mesmo serviço que o Pod 1530. Os quadros podem ser ainda inundados a uma pluralidade de VMs nos outros Pods, que podem atingir milhares de VMs. Tal esquema de transmissão para DAs desconhecidos pode não ser eficiente em redes relativamente grandes, por exemplo, que compreendem muitos DCs.

[00113] A Figura 16 ilustra uma modalidade de outro esquema de transmissão 1600 que pode ser utilizado em uma rede / domínio de Camada 2, por exemplo, uma VLAN, que pode ser parte das redes de Camada 2 virtuais ou as pseudo redes de Camada 2 acima. O esquema de transmissão 1600 pode ser mais controlado e, portanto, mais escalonável e eficiente do que o esquema de transmissão 1500. A rede / domínio de Camada 2 ou VLAN pode compreender uma pluralidade de ASs 1622 localizadas em um Pod 1630, por exemplo, em um DC. A VLAN pode também compreender uma pluralidade de CUGs 1635 acoplados às ASs 1622. Cada CUG 1635 pode compreender uma pluralidade de comutadores EoR 1624 acoplados às ASs 1622, uma pluralidade de comutadores de ToR 1637 acoplados aos comutadores EoR 1624, e uma pluralidade de servidores / VMs 1639 acoplados aos comutadores de ToR 1637. As ASs 1622 podem ser acopladas a uma pluralidade de Pods (não mostrado) em outros DCs que podem corresponder a outras redes / domínios de Camada 2 de redes de Camada 2 virtual ou as pseudo redes de Camada 2. Os componentes da rede / domínio de Camada 2 ou o Pod 1630 podem ser dispostos como mostrado na Figura 16.

[00114] Para controlar ou limitar o alcance de transmissão do esquema de transmissão 1600, quadros com DAs desconhecidos podem apenas ser inundados no Pod 1530 para uma única raiz, por exemplo, para um servidor / VM 1639 que pode ser designado como um servidor de transmissão ou para uma AS 1622. Os quadros podem ser inundados para a raiz usando uma configuração VLAN multiponto enraizada (PGR), por exemplo, uma etiqueta VLAN de impulso para RMP VLAN que está enraizada em um servidor de transmissão. No entanto, o quadro inundado pode não ser encaminhado a todos os outros servidores, por exemplo, que não são servidores de transmissão, o que pode economizar recursos de enlace e processamento do servidor de quadros estranhos. Além disso, os quadros encaminhados podem não ser encaminhados para o núcleo, por exemplo, para outros Pods ou DCs.

[00115] Em algumas modalidades, o servidor de transmissão pode hospedar um servidor ARP proxy, um servidor DHCP, e / ou outros servidores de funções específicas, por exemplo, para melhorar a eficiência, escalabilidade e / ou segurança. Por exemplo, o servidor de transmissão pode ser configurado para fornecer segurança em DCs que só permitem serviços de transmissão selecionados. Se nenhum serviço conhecido é selecionado, quadros de dados com DAs desconhecidos podem ser inundados a partir do servidor de transmissões em uma VLAN primeira ou original. O esquema de transmissão 1600 pode ser usado para lidar com casos em que as aplicações dos clientes estão autorizadas a utilizar transmissão de Camada 2. Um limitador de taxa de dados pode também ser usado para proteger contra tempestades de transmissão, por exemplo, evitar o tráfego de transmissão substancial.

[00116] Tal como descrito acima, quando introduzindo virtualização de servidor em DCs, o número de hosts em um DC pode aumentar substancialmente, por exemplo, ao longo do tempo. Usando virtualização de servidores, cada servidor físico, o qual pode originalmente hospedar uma estação final, pode tornar-se capaz de hospedar centenas de estações finais e VMs. As VMs podem ser adicionadas, excluídas e / ou movidas de forma flexível entre os servidores, que podem melhorar o desempenho e utilização dos servidores. Esse recurso pode ser usado como um bloco de construção para serviços de computação na nuvem, por exemplo, para oferecer sub-redes virtuais controladas por clientes e hosts virtuais. As sub-redes virtuais controladas por cliente oferecidas pelos serviços de computação em nuvem podem permitir que os clientes definam as suas próprias sub-redes com endereços IP correspondentes e políticas.

[00117] O rápido crescimento de hosts virtuais pode impactar substancialmente redes e servidores. Por exemplo, um problema resultante pode ser o tratamento dos pedidos ARP frequentes, tais como pedidos ARP IP versão 4 (IPv4), ou pedidos de Descoberta de Vizinhança (ND), como os pedidos ND IP versão 6 (IPv6) de hosts. Os hosts em um DC podem enviar estes pedidos frequentemente devido a caches ou entradas que podem envelhecer em cerca de minutos. No caso de dezenas de milhares de hosts em um DC, que pode ter diferentes endereços MAC, a quantidade de mensagens ARP ou ND ou pedidos por segundo pode chegar a mais de cerca de 1000 a 10000 pedidos por segundo. Esta taxa ou frequência de pedidos pode impor ônus computacional considerável sobre os hosts. Outra questão associada a um número substancialmente grande de hosts virtuais em um DC pode ser existir endereços IP duplicados dentro de uma VLAN, o que pode afetar o esquema ARP ou ND de funcionar adequadamente. Algumas técnicas de balanceamento de carga também podem exigir vários hosts que servem a mesma aplicação para utilizar o mesmo endereço IP, mas com diferentes endereços MAC. Alguns serviços de computação em nuvem podem permitir que usuários usem suas próprias sub-redes com endereços IP e políticas autodefinidas entre as sub-redes. Como tal, pode não ser possível designar uma VLAN por cada cliente uma vez que o número máximo de VLANS disponíveis pode ser de cerca de 4095 em alguns sistemas embora possa haver centenas de milhares de sub-redes de cliente. Neste cenário, pode haver endereços IP duplicados em sub-redes de clientes diferentes que terminam em uma VLAN.

[00118] Em uma modalidade, um mecanismo de resolução de endereço escalonável que pode ser utilizado em redes de Camada 2 substancialmente grandes, que pode compreender uma única VLAN que inclui um número substancial de hosts, tais como VMs e / ou de estações terminais. Além disso, um mecanismo é descrito para a resolução de endereço correta em uma VLAN com endereços IP duplicados. O mecanismo pode ser usado para ambas os endereços ARP IPv4 e os endereços ND IPv6.

[00119] A Figura 17 ilustra uma modalidade de distritos de rede interconectados 1700 em uma rede de Camada 2 de ponte, por exemplo, uma Ethernet. A rede em ponte de Camada 2 pode compreender uma pluralidade de pontes de núcleo 1712 em um distrito de núcleo 1710, o qual pode ser acoplado a uma pluralidade de distritos 1720. A rede em ponte de Camada 2 pode também compreender uma pluralidade de DBBs 1722 que podem ser parte do distrito de núcleo 1710 e os distritos 1720, e assim podem interligar o distrito de núcleo 1710 e os distritos 1720. Cada distrito 1720 pode também compreender uma pluralidade de comutadores intermediários 1724 acoplados o DBBs correspondentes 1722, e uma pluralidade de estações de terminais 1726, por exemplo, os servidores / VMs, acopladas a correspondentes comutadores intermediários 1724. Os componentes dos distritos de rede interconectados 1700 podem ser dispostos como mostrado na Figura 17.

[00120] A Figura 18 ilustra outra modalidade dos distritos de rede interconectados 1800 que podem ser configurados semelhantes aos distritos de rede interconectados 1700. Os distritos de rede interconectados 1800 podem compreender uma pluralidade de pontes de núcleo 1812 e uma pluralidade de DBBs 1822 (por exemplo, comutadores de ToR) ou comutadores de fronteira de distrito em um distrito de núcleo 1810. Os distritos de rede interconectados 1800 podem também compreender uma pluralidade de comutadores intermediários 1824 e uma pluralidade de estações de terminais 1826, por exemplo, os servidores / VMs, em uma pluralidade de zonas 1820. Os distritos 1820 poderão também incluir os DBBs 1822 que acoplaram os distritos 1820 para o distrito de núcleo 1810. Os componentes dos distritos de rede interconectados 1800 podem ser dispostos como mostrado na Figura 18. Uma VLAN pode ser estabelecida nos distritos de rede interconectados 1800, como indicado pelas linhas sólidas em negrito na Figura 18. A VLAN pode ser associada com um VID e pode ser estabelecida entre as pontes de núcleo 1812 na ponte de núcleo 1810, um subconjunto dos DBBs 1822 nos distritos 1820, e um subconjunto de comutadores intermediários 1824 e servidores / VMs 1826 nos distritos 1820.

[00121] Os DBBs 1822 nos distritos 1820 podem ser conscientes e manter um par <MAC,VID> para cada estação final 1826 nos distritos 1820. Esta informação de endereço pode ser comunicada pelas estações finais 1826 aos DBBs correspondentes 1822 nos distritos correspondentes 1820 via Protocol de Descoberta e Configuração de Interface de Estação Virtual (VSI) de Ponte Virtual de Borda (EVB) (VDP). O DBB 1822 também pode registrar esta informação com os outros DBBs 1822, por exemplo, através de MMRP. Alternativamente, a informação de endereço pode ser comunicada pelas estações finais 1826 para seus DBBs 1822 usando mensagens ARP gratuitas ou enviando mensagens de configuração de um NMS.

[00122] Em uma modalidade, um mecanismo de resolução de endereço escalonável pode ser implementado para suportar uma VLAN que compreende um número relativamente grande de hosts nos distritos de rede interconectados 1800. Especificamente, o endereço MAC de um DBB 1822 em um distrito 1820 e o VVLAN ID podem ser usados como uma resposta a um pedido ARP para endereços de host do distrito a partir de outros distritos 1820. Em alguns casos, um DS pode ser configurado para obter informação de endereço resumida para as estações finais 1826 em um distrito 1820, quando o DS pode não ser capaz de lidar com um número relativamente grande de mensagens para estações finais individuais 1826 ou hosts. Nesses casos, o DBB 1822 em um distrito 1820 pode terminar todas as mensagens ARP gratuitas para os hosts de distritos ou bisbilhotar todas as mensagens ARP gratuitas enviadas a partir de seu distrito 1920, e enviar ao invés um anúncio de grupo gratuito, por exemplo, que resume a informação de endereço de host para o DS. O DBB pode enviar o seu próprio anúncio ARP gratuito para anunciar todos os endereços IP de host em seu distrito 1820 para outros distritos 1820.

[00123] Além disso, o DBB 1822 em um distrito 1820 pode servir como um proxy ARP pelo envio de seu próprio endereço MAC para outros distritos 1820, por exemplo, através de uma ponte de núcleo 1812 no distrito de núcleo 1810. As pontes de núcleo 1812 podem apenas estar cientes dos endereços MAC dos DBBs 1822 nos distritos 1820, mas não dos endereços MAC dos comutadores intermediários e estações finais 1824 1826 ou hosts, o que torna este sistema mais escalonável. Por exemplo, quando uma primeira estação final 1826 em um primeiro distrito 1820 envia um pedido ARP para o endereço de uma segunda estação final 1826 em um segundo distrito 1820, o endereço MAC de um DBB 1822 do segundo distrito 1820 pode ser devolvido em resposta para a primeira estação final 1826.

[00124] A Figura 19 ilustra uma modalidade do esquema de proxy ARP 1900 que pode ser utilizado em uma rede em ponte de Camada 2, por exemplo, para os distritos de rede interconectados 1800. A rede em ponte de Camada 2 pode compreender um distrito de núcleo 1910, uma pluralidade de DBBs 1922 ou comutadores de fronteira de distrito acoplados ao distrito de núcleo 1910, e uma pluralidade de estações finais 1926 (por exemplo, VMs), acopladas aos DBBs correspondentes 1922 nos seus distritos. A rede em ponte de Camada 2 pode também compreender um DS 1940, que pode ser acoplado aos DBBs 1922, por exemplo, através do distrito de núcleo 1910. Os DBBs 1922 e estações finais 1926 podem pertencer a uma VLAN estabelecida na rede em ponte de Camada 2 e associada com um VID. Os componentes da rede em ponte de Camada 2 podem ser dispostos como mostrado na Figura 19.

[00125] Com base no esquema de proxy ARP 1900, um primeiro DBB 1922 (DBB X) pode interceptar um pedido ARP de uma primeira estação final 1926 em seu distrito local. O pedido ARP pode ser para um endereço MAC para uma segunda estação final 1926 em outro distrito. O pedido ARP pode compreender o IP DA (10.1.0.2) da segunda estação final 1926, e o endereço de fonte IP (SA) (10.1.0.1) e MAC SA (A) da primeira estação final 1926. A primeira estação final 1926 pode manter os endereços IP das outras estações finais 1922 em uma tabela VM ARP 1960. DBB X pode enviar uma consulta DS para obter um endereço MAC para a segunda estação final 1926 a partir do DS 1940. A consulta DS pode compreender o endereço IP (10.1.0.2) da segunda estação final 1926, e a IP SA (10.1.0.1) e MAC SA (A) da primeira estação final 1926. O DS 1940 pode manter os endereços IP, endereços MAC, e informações sobre os DBBs associados 1922 ou locais das estações finais 1926 (hosts) em uma tabela de endereço DS 1950.

[00126] O DS 1940 poderá então voltar ao DBB X uma resposta DS que inclui o endereço IP (10.1.0.2) da segunda estação final 1926 e o endereço MAC (Y) de um segundo DBB 1926 (DBB Y) associado à segunda estação final 1926 no outro distrito, como indicado na tabela de endereço DS 1950. Por sua vez, DBB X pode enviar uma resposta ARP para a primeira estação final 1926 que compreende o IP DA (10.1.0.1) e MAC DA (A) da primeira estação final 1926, o IP SA (10.1.0.2) da segunda estação final 1926, e o endereço MAC do DBB Y (Y). A primeira estação final 1926 pode, então, associar o endereço MAC do DBB Y (Y) com o endereço IP (10.1.0.2) da segunda estação final 1926 na tabela VM ARP 1960. A primeira estação final 1926 pode usar o endereço MAC do DBB Y como o DA para encaminhar quadros que são destinados para a segunda estação final 1926.

[00127] No esquema de proxy ARP 1900, os DBBs 1922 podem apenas precisar manter o endereço MAC dos outros DBBs 1922 nos distritos sem os endereços MAC e IP dos hosts nos distritos. Desde que os DAs nos quadros de dados enviados para os DBBs 1922 apenas correspondem a endereços DBBs MAC, como descrito acima, os DBBs 1922 podem não precisar de estar cientes dos outros endereços, o que torna este sistema mais escalonável.

[00128] A Figura 20 ilustra uma modalidade de um sistema de encaminhamento de quadro de dados 2000 que pode ser utilizado em uma rede em ponte de Camada 2, por exemplo, para os distritos de rede interconectados 1800. A rede em ponte de Camada 2 pode compreender um distrito de núcleo 2010, uma pluralidade de DBBs 2022 ou comutadores de fronteira de distrito em uma pluralidade de distritos 2020 acoplados ao distrito de núcleo 2010, e uma pluralidade de comutadores intermediários 2024 e estações finais 2026 (por exemplo, VMs ) acoplados aos DBBs correspondentes 2022 em seus distritos 2020. Alguns dos DBBs 2022, comutadores intermediários 2024, e estações finais 2026 através dos distritos 2020 podem pertencer a uma VLAN estabelecida na rede em ponte de Camada 2 e associada com um VID. Os componentes da rede em ponte de Camada 2 podem ser dispostos como mostrado na Figura 20.

[00129] O esquema de encaminhamento de quadro de dados 2000 pode ser baseado em MAT nos DBBs 2022, o qual pode ser semelhante ao IP NAT. O MAT podem compreender o uso interior IP DAs e tabelas ARP para encontrar MAC DAs correspondentes. Por exemplo, um primeiro DBB 2022 (DBB1) pode receber um quadro 2040, por exemplo, um quadro Ethernet, a partir de uma primeira estação final 2026 (host A) em uma primeira zona (distrito 1). O quadro 2040 pode então ser destinado a uma segunda estação final 2026 (host B), em um segundo distrito (distrito 2). O quadro 2040 pode compreender um MAC-DA 2042 para um segundo DBB em distrito 2 (DBB2), um MAC-SA 2044 para o host A (MAC de A), um IP-DA 2046 para o host B (B), um IP-SA 2048 para o host A (A), e carga. DBB1 pode transmitir o quadro 2040 para distrito 2 via distrito de núcleo 2010. O segundo DBB 2022 (DBB2) no distrito 2 pode receber o quadro 2040 e substituir o MAC-DA 2042 para DBB2 (DBB2) no quadro 2040 com um MAC-DA 2082 para o host B (MAC de B) em um segundo quadro 2080. DBB2 pode determinar MAC B, baseado no IP-DA 2046 para o host B (B) e uma entrada correspondente em sua tabela ARP. O segundo quadro também pode incluir um MAC-SA 2084 para o host A (MAC de A), um IP-DA 2086 para o host B (B), um IPSA 2088 para o host A (A), e carga. DBB2 pode enviar o segundo quadro para o host B 2080 no distrito 2. Desde que os SAs nos quadros recebidos no distrito 2 não são alterados, os esquema de encaminhamento de quadro de dados 2000 pode não afetar DHCP implementado na rede.

[00130] Na rede acima, as pontes de núcleo ou comutadores do distrito de núcleo, por exemplo, as pontes de núcleo 1812 no distrito de núcleo 1810, só precisam manter os endereços MAC dos DBBs nos distritos sem os endereços MAC e IP dos hosts nos distritos. Uma vez que os DAs nos quadros de dados encaminhados através do distrito de núcleo podem apenas corresponder aos endereços DBBs MAC, como descrito acima, as pontes de núcleo podem não necessitar de estarem cientes dos outros endereços. Os endereços MAC dos DBBs podem ser mantidos em bancos de dados de encaminhamento das pontes de núcleo (FDBs). As pontes de núcleo ou comutadores podem aprender a topologia de todos os DBBs através de um protocolo baseado no estado de enlace. Por exemplo, os DBBs podem enviar avisos de estado de enlace (LSAs), por exemplo, usando IEEE 802.1aq, Interconexão Transparente de Muitos Enlaces (TRILL), ou núcleo baseado em IP. Se Protocolo de Árvore de Alcance (STP) é usado entre as pontes de núcleo, aprendizagem de endereço MAC pode ser desativada nas pontes de núcleo. Neste caso, os DBBs podem registrar-se com as pontes de núcleo.

[00131] Em uma modalidade, os DBBs podem atuar como proxies ARP, como descrito acima, se um DS não é utilizado. Mensagens ARP gratuitas poderão ser enviadas pelas estações finais para anunciar seus próprios endereços MAC. Anúncios de grupo gratuitos também podem ser enviados pelos DBBs para anunciar seus próprios endereços MAC e os endereços IP para todos os hosts dentro de seus distritos locais. Os anúncios de grupo gratuitos podem ser usados para anunciar endereços MAC e IP para os outros DBBs nos outros distritos. Os endereços MAC e endereços IP anunciados podem ser usados nos outros DBBs para traduzir DBB MAC DAs em quadros recebidos de acordo com hosr IP DAs. Um ARP de grupo gratuito pode ser enviado por um DBB para anunciar um subconjunto de endereços IP de host para cada VLAN associada com o DBB. O ARP de grupo gratuito pode compreender um mapeamento de subconjuntos de endereços IP de host para uma pluralidade de VLANs para o DBB.

[00132] A Tabela 5 ilustra um exemplo de mapeamento de endereços IP de host para os endereços DBB MAC correspondentes nos distritos interconectados. O mapeamento pode ser enviado em um ARP de grupo gratuito por um DBB para anunciar seus endereços IP de host para cada VLAN associada com o DBB. Um endereço DBB MAC (DBB-MAC) pode ser mapeado para uma pluralidade de endereços IP de host correspondentes. Cada endereço DBB MAC pode ser mapeado para uma pluralidade de endereços IP de host em uma pluralidade de VLANs (por exemplo, VID-1, VID-2, VID-n, ...), que podem ser nos distritos iguais ou diferentes. Tabela 5: Informações carregadas pelo ARP de Grupo Gratuito

[00133] Em algumas situações, vários hosts nos distritos interconectados podem ter os mesmos endereços IP e podem estar associados com a mesma VLAN (ou VID). Por exemplo, uma sub-rede virtual de um serviço de computação em nuvem pode permitir que os clientes nomeiem seus próprios endereços IP privados. O número de sub-redes virtuais oferecidas por um serviço de computação em nuvem pode exceder substancialmente o número total de VLANs permitidas (por exemplo, cerca de 4095 VLANs). Como tal, uma pluralidade de máquinas virtuais (por exemplo, VM ou estações finais virtuais) pode utilizar ser autorizada para ter os mesmos endereços IP, mas com diferentes endereços MAC. Em outros casos, várias estações finais podem servir a mesma aplicação usando os mesmos endereços IP, mas endereços MAC diferentes.

[00134] Em uma modalidade, um DBB pode ser atribuído uma pluralidade de endereços MAC, aqui referidos como endereços MAC de representante, por exemplo, para diferenciar entre diferentes hosts que usam o mesmo endereço IP (duplicado). O DBB também pode estar associado com uma pluralidade de VLANs. Além disso, cada VLAN no DBB pode estar associada com uma pluralidade de sub-redes ou sub-redes virtuais, por exemplo, que compreendem diferentes subconjuntos de hosts dentro da VLAN. As sub-redes virtuais podem estar associadas com uma pluralidade de IDs de sub- rede. Se o número de endereços IP duplicados para os hosts é substancialmente menor do que o número de sub-redes virtuais da VLAN, então o número de endereços MAC de representante para o DBB também pode ser substancialmente menor.

[00135] A Figura 21 ilustra uma modalidade de um esquema de proxy ARP 2100 que pode ser utilizado para distritos de rede interconectados em uma rede em ponte de Camada 2. A rede em ponte de Camada 2 pode compreender um distrito de núcleo 2110, uma pluralidade de DBBs 2122 ou comutadores de fronteira de distrito acoplados ao distrito de núcleo 2110, e uma pluralidade de estações finais 2126 (por exemplo, VMs), acopladas aos DBBs correspondentes 2122 nos seus distritos. A rede em ponte de Camada 2 pode também compreender um DS 2140 que pode ser acoplado aos DBBs 2122, por exemplo, através do distrito de núcleo 2110. Os DBBs 2122 e estações finais 2126 podem pertencer a uma VLAN estabelecida na rede em ponte de Camada 2. Os componentes da rede em ponte de Camada 2 podem ser dispostos como mostrado na Figura 21.

[00136] Com base no esquema de proxy ARP 2100, um primeiro DBB 2122 (DBB X) pode interceptar um pedido ARP de uma primeira estação final 2226 em seu distrito local. O pedido ARP pode ser para um endereço MAC para uma segunda estação final 2126 em outro distrito. O pedido ARP pode compreender o IP DA (10.1.0.2) da segunda estação final 2126, e o IP SA (10.1.0.1) e MAC SA (A) da primeira estação final 2126. A primeira estação final 2126 pode manter os endereços IP das outras estações finais 2122 em uma tabela VM ARP 2160. DBB X pode então encaminhar uma consulta DS para obter um endereço MAC para a segunda estação final 2126 a partir do DS 2140. A consulta DS pode compreender o endereço IP (10.1.0.2) da segunda estação final 2126, e o IP SA (10.1.0.1) e MAC SA (A) da primeira estação final 2126. O DS 2140 pode manter os endereços IP, endereços MAC, VLAN IDs ou VIDs, IDs de cliente (sub-rede virtual) e outras informações sobre os DBBs associados 2122 ou locais das estações finais 2126 em uma tabela de endereço DS 2150.

[00137] O DS 2140 pode usar o MAC SA (A) na consulta DS para determinar qual ID de cliente (sub-rede virtual) pertence à VM requerente (primeira estação final 2126). Por exemplo, de acordo com a tabela de endereço DS 2150, o ID de cliente, Joe, corresponde ao MAC SA (A). O DS 2140 pode então voltar para DBB X uma resposta DS que compreende o endereço IP (10.1.0.2) da segunda estação final 2126 e um endereço MAC de representante (Y1) de um segundo DBB 2126 (DBB Y) associado com o ID de cliente (Joe) da primeira estação final 2126. Por sua vez, DBB X pode enviar uma resposta ARP para a primeira estação final 2126 que compreende o IP DA (10.1.0.1) e MAC DA (A) da primeira estação final 2126, o IP SA (10.1.0.2) da segunda estação final 2126, e o endereço MAC de representante do DBB Y (Y1). A primeira estação final 2126 pode, então, associar o endereço MAC de representante do DBB Y (Y1) com o endereço IP (10.1.0.2) da segunda estação final 2126 na tabela VM ARP 2160. A primeira estação final 2126 pode usar o endereço MAC de representante do DBB Y como o DA para encaminhar quadros que são destinados para a segunda estação final 2126.

[00138] Uma terceira estação final 2126 em outro distrito também pode enviar um pedido ARP (para a segunda estação final 2126 para um DBB local correspondente 2122 (DBB Z) no terceiro distrito da estação final. DBB Z pode então comunicar com o DS 2140, como descrito acima, e devolver de acordo para a terceira estação final 2126 uma resposta ARP que compreende o IP DA (10.1.0.3) e MAC DA da terceira estação final 2126, o IP SA (10.1.0.2) da segunda estação final 2126, e um endereço MAC de representante de DBB Y (Y2) associado com o ID de cliente, Bob, da terceira estação final 2126 na tabela de endereço DS 2150. A terceira estação final 2126 pode, em seguida, associar o endereço MAC de representante do DBB Y (Y2) com o endereço IP (10.1.0.2) da segunda estação final 2126 em uma tabela VM ARP 2170 da terceira estação final 2126. A terceira estação final 2126 pode usar este endereço MAC de representante do DBB Y como o DA para encaminhar quadros que são destinados para a segunda estação final 2126.

[00139] A Tabela 6 ilustra um exemplo de mapeamento de um endereço IP de host duplicado para endereços DBB MAC de representante correspondentes em uma VLAN nos distritos interconectados. O endereço de host duplicado pode ser utilizado por uma pluralidade de hosts para uma aplicação pretendida ou de host. Os endereços MAC DBB de representante podem ser atribuídos para as diferentes máquinas que usam a mesma aplicação (ou se comunicam com o mesmo host). Para cada VLAN, um endereço IP de host pode ser mapeado para uma pluralidade de endereços DBB MAC de representante (MAC-12, MAC-13, MAC-14, ...) para uma pluralidade de hosts, por exemplo, associados com diferentes sub-redes da VLAN. Os endereços DBB MAC de representante podem também estar associados com um endereço DBB MAC de base (original) (MAC-11). Os endereços DBB MAC de representante e de base para o mesmo IP podem ser diferentes para diferentes VLANs. Quando uma VLAN não tem endereços de representante, o endereço de base DBB pode ser utilizado para a VLAN. Se existem cerca de 10 endereços IP duplicados no dentro de uma VLAN, então cerca de 10 colunas (dez endereços MAC) na tabela 6, podem ser utilizadas. Tabela 6: MAT para endereços IP duplicados.

[00140] A Tabela 7 ilustra um exemplo de mapeamento de endereços IP de host para uma pluralidade de endereços MAC de representante, por exemplo, para várias sub-redes. O mapeamento pode ser enviado em um ARP de grupo gratuito por um DBB para anunciar seus endereços IP de host para cada VLAN associada com o DBB. Cada endereço MAC de representante (DBB-MAC1, DBB-Mac2, ...) pode ser mapeado para uma pluralidade de endereços IP de host correspondentes em uma sub-rede. Cada endereço DBB MAC de representante pode ser associado com um ID de cliente ou de sub-rede virtual para os endereços IP de host. Os endereços IP de host para cada endereço DBB MAC representante também podem corresponder a uma pluralidade de VLANs (VID-1, VID2, VID-n, ...). Os endereços IP de host em cada sub-rede podem ser diferentes. Endereços IP de host duplicados, que podem ser associados com as mesmas VLANs, mas com IDs de clientes diferentes, podem ser mapeados para diferentes endereços DBB MAC de representante. Tabela 7: Informação carregada pelo ARP de grupo gratuito

[00141] A Figura 22 ilustra uma modalidade de um esquema de superação de falha 2200 que pode ser utilizado para distritos de rede interconectados em uma rede em ponte de Camada 2. O esquema de superação de falha 2100 pode ser utilizado no caso de qualquer dos DBBs (por exemplo, um comutador de ToR) nos distritos interconectados falhar. A rede em ponte de Camada 2 pode compreender uma pluralidade de pontes de núcleo 2212 e uma pluralidade de DBBs 2222 ou comutadores de fronteira de distrito em uma distrito de núcleo 1810, e uma pluralidade de distritos 2220. Os distritos 2220 podem compreender os DBBs 2222, uma pluralidade de comutadores intermediários 2224, e uma pluralidade de estações finais 2226, por exemplo, os servidores / VMs. A rede em ponte de Camada 2 pode também compreender um DS (não mostrado) que pode ser acoplado aos DBBs 2222, por exemplo, através do distrito de núcleo 2210. Alguns dos DBBs 2222, comutadores intermediários 2224, e estações finais 2226 podem pertencer a uma VLAN estabelecida na rede em ponte de Camada 2. Os componentes da rede em ponte de Camada 2 podem ser dispostos como mostrado na Figura 22.

[00142] Quando um DBB ativo 2222 falha em uma VLAN, a VLAN pode ser estabelecida utilizando um ou mais de DBBs em espera 2222. Os DBBs em espera 222 podem estabelecer conexões ativas com, pelo menos, alguns dos comutadores intermediários 2224 que pertencem à VLAN e, possivelmente, com uma nova ponte de núcleo 2212. Isto é indicado pelas linhas tracejadas na Figura 22. Como tal, os caminhos para as estações finais 2226 da VLAN podem não ser perdidos os quais permite que as estações finais 2226 se comuniquem através da VLAN. Quando o DBB 222 na VLAN falha, o DS pode ser notificado da falha, por exemplo, pelo envio de uma mensagem explícita para o DS ou usando um método de “manter-ativo”. Assim, um DBB pode substituir a informação de endereço do DBB falhado e possivelmente outros DBBs originais 2222 na VLAN nas entradas da tabela de endereços DS com a informação dos novos DBBs 2222 que estavam em espera, e, em seguida, utilizados para substituir os DBBs falhados e outros originais 2222. O DBB original e falhado substituído são indicados por círculos na Figura 22. Ao detectar o DBB falhado 2222, um DBB de substituição pode enviar um LSA para o DS ou o distrito de núcleo 2010 para indicar que os endereços do DBB falhado, incluindo todos os endereços de representante, são alcançáveis pelo DBB de substituição 2222.

[00143] Com a virtualização de servidor, um servidor físico pode hospedar mais VMs, por exemplo, dezenas a centenas de estações finais virtuais e VMs. Isto pode resultar em um aumento substancial no número de hosts virtuais em um DC. Por exemplo, para um DC relativamente grande com cerca de 50000 servidores, que podem, cada um, suportar até cerca de 128 VMs, o número total de VMs no DC pode ser igual a cerca de 50000 x 128 ou cerca de 6400000 VMs. Para alcançar a alocação dinâmica de recursos em tal conjunto de servidores tão grande, redes de Camada 2 baseadas em Ethernet podem ser usadas em DCs. Tal grande rede de Camada 2 com potencialmente um número significativo de hosts virtuais pode representar novos desafios para a tecnologia Ethernet subjacente. Por exemplo, um problema pode ser escalabilidade de tabela de encaminhamento MAC devido ao espaço de endereço MAC plano. Outro problema pode ser lidar com uma tempestade de transmissão causada pelo ARP e outros tráfegos de transmissão.

[00144] Uma abordagem para reduzir o tamanho da tabela de encaminhamento MAC, também aqui referido como um FDB, no núcleo da rede pode ser usar encapsulamento de endereços de rede, por exemplo, de acordo com IEEE 802.1ah e TRILL. Os encapsulamentos de endereços de rede de 802.1ah e TRILL são descritos em padrão IEEE P802.1ah/D4.2 e projeto IETF projeto-ietf-trill-rbridge-protol-12-txt, respectivamente, ambas os quais são aqui incorporados por referência. Com encapsulamento de endereços de rede, o número de entradas FDB em comutadores de núcleo pode ser reduzido para o número total de comutadores (incluindo borda e núcleo) na rede, independente do número de VMs. Por exemplo, com cerca de 20 servidores por comutador, o número de comutadores de borda em uma rede de cerca de 50000 servidores pode ser igual a cerca de 50000 / 20 ou cerca de 2500. No entanto, com aprendizagem de endereço MAC de caminho de dados, o tamanho FDB de comutadores de borda (por exemplo, comutadores de ToR em DCs) pode ser aproximadamente o mesmo que quando o encapsulamento de endereços de rede não é usado, o que pode ser substancialmente grande.

[00145] Mesmo com a aprendizagem MAC seletiva em comutadores de ToR, o tamanho FDB pode ainda ser substancialmente grande. Por exemplo, se um comutadores de ToR tem cerca de 40 portas a jusante, um par de comutadores de ToR pode ter até cerca de 40 servidores “dual-homed” ligados aos comutadores de ToR. Se um servidor suporta até cerca de 128 VMs, um comutador de ToR pode ter cerca de 128 x 40 / 2 ou cerca de 2560 VMs ligadas ao comutador de ToR em operação normal, por exemplo, quando os comutadores de ToR lidam com aproximadamente o mesmo número de VMs. O número de VMs pode aumentar para cerca de 5120 se um comutador de ToR falhar. Se cada VM comunica, em média, com cerca de 10 VMs remotas simultaneamente, o tamanho FDB de comutador de ToR (por exemplo, número de entradas) pode ser pelo menos proporcional a cerca de 2560 (VMs locais) + 2560 x 10 (VMs remotas) + 2500 (comutadores de ToR) ou cerca de 30660 entradas, que podem ser ainda dobrados no cenário de falha.

[00146] Os encapsulamentos de endereços de rede em 802.1ah e TRILL podem ser simétricos. Especificamente, os mesmos comutadores, tais como comutadores de borda, podem realizar o encapsulamento de endereço. O problema com os encapsulamentos de endereços de rede simétricos em 802.1ah e TRIL é que um comutador de borda precisa manter o controle das VMs remotas que se comunicam com VMs locais. O número das VMs remotas pode variar substancialmente. Uma solução proposta por A. Greenberg et al. em um artigo intitulado “Towards a Next Generation Data Center Architecture: Scalability and Commoditization”, publicado em PRESTO 08, que é aqui incorporado por referência, é mover o processo de encapsulamento de endereços de rede dentro das VMs, reduzindo assim o tamanho FDB de comutador para a sua mínimo, que pode ser igual à soma do número de VMs locais e o número de comutadores de borda na rede (por exemplo, igual a cerca de 2560 + 2500 ou cerca de 5060 entradas no exemplo acima). A desvantagem dessa abordagem é a mudança da pilha de protocolo de sistema de operação convidado (OS).

[00147] Em vez disso, mover o encapsulamento de endereços de rede para um comutador virtual de um servidor físico (por exemplo, dentro de um hipervisor) pode reduzir o tamanho FDB de comutador de borda e evitar a alteração da pilha de protocolo de OS convidado, tal como descrito mais abaixo. Tal encapsulamento de endereços de rede é aqui referido como encapsulamento de endereços de rede assimétrico já que de-encapsulamento de endereços ainda é feito em outros lugares em comutadores de borda. Este mecanismo de encapsulamento de endereços de rede assimétrico pode reduzir a quantidade de endereços mantida nos FDBs de roteadores ou comutadores intermediários / de borda.

[00148] O esquema de encapsulamento de endereços de rede assimétrico pode ser executado em uma rede da camada 2 que compreende comutadores de borda e núcleo, tais como nas modalidades diferentes de rede descritas acima. Por exemplo, os comutadores de borda podem corresponder aos comutadores de ToR em DCs. Cada comutador de borda pode ser atribuído um ID único, que pode ser um endereço MAC (como em 802.1ah), um apelido de cerca de 16 bits (como em TRILL), ou um endereço IP. A rede pode ser configurada para transmitir um quadro com base no ID de comutador de borda de destino carregado no cabeçalho do quadro de um comutador de borda de ingresso para o comutador de borda de saída. O quadro pode ser encaminhado dentro da rede utilizando qualquer tecnologia de transporte. O esquema de encapsulamento de endereços de rede assimétrico pode ser semelhante ao esquema de encapsulamento de endereços em 802.1ah, também referido como MAC-em-MAC. Aprendizagem MAC pode ser desativada na rede, mas habilitada no servidor de comutador de borda de frente para as portas. O servidor de termos, estação final, e host podem ser usados indistintamente aqui. O servidor virtual de termos, VM, estação final virtual, e host virtual podem também ser aqui utilizados indiferentemente.

[00149] Em MAC-em-MAC, existem dois tipos de endereços MAC: os endereços MAC atribuídos a comutadores de borda, também referidos como endereços de rede ou backbone MAC (B-MAC), e os endereços MAC usados por VMs, também referidos como cliente MAC (C-MAC). A Figura 23 ilustra uma modalidade de um servidor físico típico 2300, o qual pode ser um servidor “dual-homed” em um DC. O servidor físico 2300 pode compreender um comutador virtual 2310, uma pluralidade de VMs 2340, e uma pluralidade de Placas de Interface de Rede físicas (pNICs) 2350. O comutador virtual 2310 pode compreender um proxy ARP 2330 e um FDB 2320, que pode compreender um FDB local 2322 e um FDB remoto 2324. O comutador virtual 2310 pode ser localizado dentro de um hipervisor do servidor físico 2300. O comutador virtual 2310 pode ser acoplado às VMs através de uma pluralidade de Placas de Interface de Rede virtuais correspondentes (NIC) 2342 das VMs 2340 e uma pluralidade de portas de comutador virtuais correspondentes 2312 do comutador virtual 2310. O comutador virtual 2310 pode também ser acoplado às pNICs 2312 através de uma pluralidade de portas de tronco de comutador virtuais correspondentes 2314 do comutador virtual 2310. As pNICs 2350 podem servir como enlaces ascendentes ou troncos para o comutador virtual 2310. O servidor físico 2300 pode ser acoplado a uma pluralidade de comutadores de borda 2360 através de pNICs correspondentes 2350 do servidor físico 2300. Assim, os comutadores de borda 2360 podem ser acoplados através dos componentes do servidor físico 2300 (as pNICs 2350 e o comutador virtual de 2310) para as VMs 2340. Os componentes do servidor físico 2300 podem ser dispostos como mostrado na Figura 23.

[00150] Para o balanceamento de carga, o tráfego pode ser distribuído aos troncos (pNICs 2350) com base nos IDs de porta virtual ou endereços C-MAC de fonte VM do tráfego. Cada VM 2340 pode ter um NIC virtual 2342 com um endereço de C-MAC unicamente atribuído. A VM 2340 pode enviar o tráfego para um comutador de borda 2360 durante a operação normal. Por exemplo, uma primeira VM 2340 (VM1) pode enviar uma pluralidade de quadros destinados a VMs externas em outros servidores físicos na rede (não mostrado) através de um primeiro comutador de borda correspondente 2350 (comutador de borda X). Um segundo comutador de borda 2360 (comutador de borda R) pode ser uma cópia de segurança para comutador de borda X. Quando comutador de borda X torna-se inacessível devido a uma falha (por exemplo, a PNIC correspondente 2350 falha, a conexão entre a PNIC 2350 e o comutador de borda X falha, ou comutador de borda X falha), o comutador virtual 2310 pode então enviar os quadros para o comutador de borda R.

[00151] No FDB 2320, o local de FDB 2322 pode corresponder às VMs locais (VMs 2340) e pode compreender uma pluralidade de endereços de destino C-MAC (C-MAC DAs), uma pluralidade de IDs de VLAN, e uma pluralidade de IDs de portas de comutador virtual associados . Os C-MAC DAs e VLAN IDs podem ser usados para procurar o FDB local 2322 para obter os IDs de porta de comutador virtual correspondentes. O FDB remoto 2324 pode corresponder a VMs exteriores (em outros servidores físicos) e pode compreender uma pluralidade de endereços de destino B-MAC (B-MAC DAs) e uma pluralidade de C-MAC DAs associados com os B-MAC DAs. O C-MAC DAs pode ser usado para procurar o FDB remoto 2324 pelas VMs locais para obter os B-MAC DAs correspondentes. O FDB remoto 2324 pode ser preenchido pelo proxy ARP 2330, conforme descrito abaixo.

[00152] Com base no encapsulamento de endereços simétrico, um quadro Ethernet de um VM 2340 pode ser desmarcado ou marcado. Se o quadro é desmarcado, o VLAN ID atribuído à porta de comutador virtual correspondente 2312 pode ser usado. Em direção a montante a partir da VM 2340 para um comutador de borda 2360, o comutador virtual 2310 pode realizar os seguintes passos após receber um quadro Ethernet a partir da VM 2340:

[00153] Passo 1: Usar C-MAC DA e VLAN ID na consulta à tabela do FDB local 2322. Se for encontrada uma correspondência, encaminhar o quadro para a porta de comutador virtual 2312 que é especificada na entrada FDB de correspondência (pelo ID de porta de comutador virtual). Caso contrário, vá para o passo 2.

[00154] Passo 2: Usar C-MAC DA na consulta à tabela do FDB remoto 2324. Se for encontrada uma correspondência, executar um encapsulamento MAC-em-MAC com base em encapsulamento de endereços de rede assimétrico (descrito abaixo) e encaminhar o quadro para a porta de tronco de comutador virtual 2314 que está associada com o C-MAC SA no quadro. Caso contrário, vá para o passo 3.

[00155] Passo 3: Descartar o quadro e enviar um pedido ARP melhorado para um servidor ARP na rede (não mostrado).

[00156] A Figura 24 ilustra uma modalidade de um esquema de encapsulamento de endereços de rede assimétrico 2400 que podem ser utilizados no servidor físico. Com base no esquema de encapsulamento de endereços de rede assimétrico 2400, uma VM 2402 pode enviar, na direção a montante, um quadro destinado a outra VM remota ou externa, em outro servidor físico na rede (não mostrado). O quadro pode compreender um C-MAC DA (B) 2410 da VM remota, um C- MAC SA (A) 2412 da VM 2402, um C-VLAN ID 2414 para a VLAN da VM 2402, dados ou carga 2416 , e uma Sequência de Verificação de Quadro (FCS) 2418. A VM 2402 pode enviar o quadro para um comutador virtual 2404.

[00157] O comutador virtual 2404 (no mesmo servidor físico) pode receber o quadro a partir da VM 2402. O comutador virtual 2404 pode processar o quadro e adicionar um cabeçalho para o quadro para obter um quadro MAC-em-MAC. O cabeçalho pode compreender um B-MAC DA (Y) 2420, um B-MAC SA (0) 2422, um B-VLAN ID 2424, e um ID de Serviço de Instância (I-SID) 2426. O endereço de B-MAC (Y) pode ser associado com o C-MAC DA (B) 2410 em um comutador de borda 2406. O endereço de B-MAC (Y) pode indicar a localização da VM remota que tem o endereço de C-MAC (B). O B-MAC SA 2422 pode ser definido como zero pelo comutador virtual 2404. O B-VLAN ID 2424 pode ser definido como o C-VLAN ID 2414. O I-SID 2426 pode ser opcional e pode não ser usado no cabeçalho se o quadro Ethernet é enviado apenas para o C- MAC DA (B). O comutador virtual 2404 pode então enviar o quadro MAC-em-MAC para o comutador de borda 2406.

[00158] O comutador de borda 2406 (acoplado ao servidor físico) pode receber o quadro MAC-em-MAC a partir do comutador virtual 2404. O comutador de borda 2406 pode processar o cabeçalho do quadro MAC-em-MAC para obter um novo cabeçalho no quadro MAC-em-MAC. O novo cabeçalho pode compreender um B-MAC DA (Y) 2440, um B-MAC SA (X) 2442, um B-VLAN ID 2444, e um I-SID 2446. O B-MAC SA (X) 2442 pode ser definido como o endereço B-MAC (X) do comutador de borda 2406. O B-VLAN ID 2444 pode ser alterado se necessário, para corresponder a uma VLAN na rede. Os campos restantes do cabeçalho podem não ser alterados. O comutador de borda 2406 pode então encaminhar o quadro MAC-em-MAC novo baseado no B-MAC DA (Y) 2442 e possivelmente o B-VAN ID 2444 através da rede de núcleo 2408, por exemplo, uma rede de núcleo ou um distrito de rede de núcleo.

[00159] Na direção a jusante, o comutador de borda 2406 pode receber um quadro MAC-em-MAC a partir da rede de núcleo 2408 e realizar uma de-encapsulamento de quadro. O quadro MAC-em-MAC pode compreender um cabeçalho e um quadro original enviado a partir da VM remota para a VM 2402. O cabeçalho pode compreender um B-MAC DA (X) 2460 para o comutador de borda 2406, um B-MAC SA (Y) 2462 que corresponde a VM remota e o comutador de borda 2406, um B- VLAN ID 2464 da VLAN da VM remota, e um I-SID 2466. O quadro original para a VM remota pode compreender um C-MAC DA (A) 2470 para a VM 2402, a C-MAC SA (B) 2472 da VM remota, um C-VLAN ID 2474 associado com a VM 2402, dados ou carga 2476, e um FCS 2478. O comutador de borda 2406 pode remover o cabeçalho do quadro MAC-em-MAC e encaminhar o quadro remanescente original para o comutador virtual 2404. O comutador de borda 2406 pode procurar sua tabela de encaminhamento usando C-MAC DA (A) 2470 e C-VLAN ID 2474 para obter um ID de porta de comutador de saída e encaminhar o quadro original para fora no servidor físico de frente ou acoplado à porta de comutador correspondente. Por sua vez, o comutador virtual 2404 pode encaminhar o quadro original para a VM 2402. O comutador virtual 2404 pode encaminhar o quadro original para a VM 2402 baseado no C-MAC DA (A) 2470 e C-VLAN ID 2474.

[00160] As tabelas de encaminhamento no comutador de borda 2406 podem incluir um FDB local e um FDB remoto. O FDB local pode ser utilizado para encaminhar os quadros para VMs locais e pode ser preenchido por meio de aprendizagem MAC e indexado pelo C-MAC DA e C-VLAN ID no quadro recebido. O FDB remoto pode ser utilizado para encaminhar os quadros para VMs remotas e pode ser preenchido por um protocolo de encaminhamento ou um plano de controle / gestão centralizado e indexado pelo B-MAC DA e, possivelmente, o B-VLAN ID no quadro recebido.

[00161] No esquema de encapsulamento de endereços assimétrico 2400, o encapsulamento MAC-em-MAC pode ser realizado através do comutador virtual 2404, enquanto o de- encapsulamento MAC-em-MAC pode ser realizado através do comutador de borda 2406. Como tal, o tamanho FDB nos comutadores de borda pode ser substancialmente reduzido e tornar-se mais manejável mesmo para uma rede de Camada 2 substancialmente grande, por exemplo, em um mega DC. O tamanho FDB remoto no comutador virtual 2404 pode depender do número de VMs remotas em comunicação com as VMs locais, por exemplo, a VM 2402. Por exemplo, se um comutador virtual suporta cerca de 128 VMs locais e cada VM local, em média, comunica com cerca de 10 VMs remotas concorrentemente, o FDB remoto pode compreender cerca de 128 x 10 ou cerca de 1289 entradas.

[00162] A Figura 25 ilustra uma modalidade de um esquema de processamento ARP 2500 que pode ser utilizado no servidor físico 2300. Com base no esquema de processamento ARP 2500, uma VM 2502 pode transmitir um pedido ARP para uma VM remota. O pedido ARP pode compreender um C-MAC DA (BC) 2510 que indica uma mensagem de transmissão, um C-MAC SA (A) 2512 da VM 2502, um C-VLAN ID 2514 para a VLAN da VM 2502, carga ARP 2516, e um FCS 2518.

[00163] Um comutador virtual 2504 (no mesmo servidor físico), que pode ser configurado para interceptar todas as mensagens ARP de VMs locais, pode interceptar o pedido ARP para uma VM remota. Um proxy ARP no comutador virtual 2504 pode processar o pedido ARP e adicionar um cabeçalho para o quadro para obter uma mensagem ARP estendida de unicast (ERAP). O quadro pode ser encapsulado utilizando MAC-em- MAC, por exemplo, semelhante ao esquema de encapsulamento de endereços de rede assimétrico 2400. O cabeçalho pode compreender um B-MAC DA 2520, um B-MAC SA (0) 2522, um B- VLAN ID 2524, e um I-SID 2526. O B-MAC DA 2520 pode ser associado com um servidor ARP 2508 na rede. O B-VLAN ID 2524 pode ser definido como o C-VLAN ID 2514. O I-SID 2526 pode ser opcional e pode não ser usado. A mensagem EARP pode também compreender um C-MAC DA (Z) 2528, um C-MAC SA (A) 2530, um C-VLAN ID 2532, uma carga EARP 2534, e um FCS 2536. O proxy ARP pode substituir o C-MAC DA (BC) 2510 e a carga ARP 2516 no quadro recebido com o C-MAC DA (Z) 2528 para a VM remota e a carga EARP 2534, respectivamente, na mensagem EARP. O comutador virtual 2504 pode então enviar a mensagem EARP para o comutador de borda 2506.

[00164] O comutador de borda 2506 pode processar o cabeçalho na mensagem EARP para obter um novo cabeçalho. O novo cabeçalho pode compreender um B-MAC DA (Y) 2540, um B- MAC SA (X) 2542, um B-VLAN ID 2544, e um I-SID 2546. O B- MAC SA (X) 2542 pode ser definido como o endereço B-MAC (X) do comutador de borda 2506. O B-VLAN ID 2544 pode ser alterado se necessário, para corresponder a uma VLAN na rede. Os campos restantes do cabeçalho podem não ser alterados. O comutador de borda 2506 pode então encaminhar a mensagem EARP nova para o servidor ARP 2508 na rede.

[00165] O servidor ARP 2508 pode processar a mensagem EARP recebida e retornar uma resposta EARP para o comutador de borda 2506. A resposta EARP pode incluir um cabeçalho e um quadro ARP. O cabeçalho pode compreender um B-MC DA (X) 2560 para o comutador de borda 2506, um B-MAS SA 2562 do servidor ARP 2508, um B-VLAN ID 2564, e um I-SID 2566. O quadro ARP pode compreender um C-MAC DA (A) 2568 para a VM 2502, um C-MAC SA (Z) 2570 para a VM remota requerida, um C-VLAN ID 2572, uma carga EARP 2574, e um FCS 2576. O comutador de borda 2506 pode de-encapsular a mensagem EARP, remover o cabeçalho e depois encaminhar o quadro ARP para o comutador virtual 2504. O comutador virtual 2504 pode processar o quadro ARP e enviar uma resposta ARP 2502 de acordo com a VM. A resposta ARP pode compreender um C-MAC DA (A) 2590 para a VM 2502, um C-MAC SA (B) 2592 associado com localização da VM remota, um C- VLAN ID 2594, uma carga ARP 2596, e um FCS 2598 .

[00166] O proxy ARP no comutador virtual 2504 também pode usar a mensagem EARP para preencher o FDB remoto no comutador de borda 2506. O proxy ARP pode preencher uma entrada na tabela de FDB com um C-MAC remoto e par B-MAC de comutador remoto, o que pode ser encontrado na carga EARP 2574. O C-MAC e B-MAC de comutador remoto podem ser encontrados em um campo de endereço de hardware de remetente (SHA) e um campo de endereço de localização de remetente (SLA), respectivamente, na carga EARP 2574.

[00167] Um hipervisor no servidor físico que compreende o comutador virtual 2504 pode também registrar uma VM, por exemplo, a VM local 2502 ou uma VM remota, com o servidor ARP 2508 de uma maneira semelhante do esquema de processamento ARP 2500. Neste caso, o comutador virtual 2504 pode enviar um quadro EARP de unicast para o servidor ARP 2508 com todos os campos de remetente iguais para todos os campos de destino. Outra forma de registrar a VM é descrita no Pedido de Patente Provisório No. US 61/389,747 por Y. Xiong et al. intitulado “A MAC Address Delegation Scheme for Scalable Ethernet Networks with Duplicated Host IP Addresses”, que é aqui incorporado por referência, como se reproduzido em sua totalidade. Este esquema pode lidar com o cenário de endereço IP duplicado.

[00168] A Figura 26 ilustra uma modalidade de uma carga EARP 2600 que pode ser utilizada no esquema de processamento ARP 2500, tal como a carga EARP 2574. A carga EARP 2600 pode compreender um tipo de hardware (HTYPE) 2610, um tipo de protocolo (PTYPE) 2612, um comprimento de endereço de hardware (HLEN) 2614, um comprimento de endereço de protocolo (PLEN) 2616, um campo de operação (OPER) 2618, um SHA 2620, um endereço de protocolo de remetente (SPA) 2622, um endereço de hardware de destino (THA) 2624, e um endereço de protocolo de destino (TPA) 2626, que podem ser elementos de uma mensagem ARP típica. Além disso, a carga EARP 2600 pode compreender um SLA 2628 e um endereço de localização de destino (TLA) 2630. A Figura 6 mostra também o bit de deslocamento para cada campo na carga EARP 2600, que também indica o tamanho de cada campo em bits.

[00169] Uma questão com o uso do servidor ARP (por exemplo, o servidor ARP 2508) e desabilitando aprendizagem MAC na rede é o caso onde uma VM se torna inacessível devido a uma falha de seu comutador de borda ou o enlace conectando o servidor ARP para o comutador de borda. Neste caso, pode demorar algum tempo para o comutador virtual conhecer o novo local de um comutador de borda novo ou substituto para a VM. Por exemplo, se o comutador de borda X no servidor físico 2300 torna-se inacessível, o comutador virtual 2310 pode transmitir quadros a partir de VM1 para o comutador de borda R, que pode se tornar o novo local para VM1.

[00170] Para reduzir o tempo de atualização do FDB remoto em um comutador virtual 2310 sobre a nova localização de uma VM, uma mensagem de EARP gratuita pode ser usada. O comutador virtual 2310 pode primeiramente enviar uma mensagem EARP gratuita para o comutador de borda R em um quadro de encapsulamento MAC-em-MAC, incluindo um B-MAC DA definido para endereço de transmissão (BC). Na mensagem EARP gratuita, o SHA (por exemplo, SHA 2620) pode ser definido igual ao THA (por exemplo, THA 2624), o SPA (por exemplo, SPA 2622) pode ser definido igual ao TPA (por exemplo, TPA 2626), e o SLA (por exemplo, SLA 2628) pode ser definido igual ao TLA (por exemplo, a TLA 2630). O comutador de borda R pode então enviar a mensagem EARP gratuita a uma pluralidade de ou para todos os outros comutadores na rede, por exemplo, através de uma árvore de distribuição. Quando um comutador de borda recebe a mensagem EARP gratuita, o comutador de borda pode de- encapsular a mensagem e enviar a mensagem no servidor do comutador de borda, de frente para as portas. Quando um comutador virtual, em seguida, recebe a mensagem EARP gratuita, o comutador virtual pode atualizar seu FDB remoto se o SHA já existe no FDB remoto. O servidor ARP na rede pode atualizar a nova localização da VM afetada da mesma maneira.

[00171] O esquema de encapsulamento de endereços de rede assimétrico descrito acima pode usar o encapsulamento MAC-em-MAC em uma modalidade. Alternativamente, este esquema pode ser estendido a outros métodos de encapsulamento. Se TRILL é suportado e utilizado em uma rede, onde um comutador de borda é identificado por um apelido de cerca de 16 bits, o encapsulamento TRILL pode ser utilizado no esquema de encapsulamento de endereços de rede assimétrico. Alternativamente, um encapsulamento IP- em-IP pode ser usado se um comutador de borda é identificado por um endereço IP. Além disso, o encapsulamento de endereços de rede pode ser realizado ao nível de comutador virtual e o de-encapsulamento de endereços de rede pode ser realizado no nível de comutador de borda. Em geral, o esquema de encapsulamento de endereços de rede pode ser aplicado em qualquer nível ou em qualquer dos componentes da rede, desde que o encapsulamento e de-encapsulamento sejam mantidos em diferentes níveis ou componentes.

[00172] Em uma rede em ponte que é dividida em distritos, como nos distritos de rede interconectados 1800, um DBB pode ser uma ponte participando em vários distritos. O endereço do DBB pode ser aqui referido como um endereço de rede para diferenciar o endereço do DBB dos endereços C- MAC das VMs em cada distrito. Usando o esquema de encapsulamento de endereços assimétrico acima, o encapsulamento de endereço de rede pode ser realizado no comutador mais perto dos hosts ou o comutador virtual mais perto dos hosts virtuais. Por exemplo, os comutadores intermediários 1824, por exemplo, comutadores de ToR, podem executar o encapsulamento de endereços de rede. Os comutadores intermediários 1824 podem encapsular os quadros de dados provenientes dos subconjuntos de hosts e que compreendem um endereço DBB de destino. No entanto, os comutadores intermediários 1824 podem não alterar os quadros de dados chegando a partir do lado de rede, por exemplo, os DBBs 1822 no distrito de núcleo 1810. O DBB de destino 1822, que é um nível acima do comutador intermediário 1824, pode de-encapsular os quadros de dados do lado de rede (distrito de núcleo 1810) e encaminhar o quadro de dados de-encapsulado para hosts dentro de seu distrito.

[00173] Em uma modalidade, um comutador virtual dentro de um servidor físico (por exemplo, uma estação final 1826), pode realizar o encapsulamento de endereços de rede, enquanto o DBB de destino 1822 pode realizar o de- encapsulamento de endereços de rede. Neste caso, o DBB 1822 que executa o de-encapsulamento pode ser dois níveis acima do comutador virtual (na estação final 1826) que executa o encapsulamento.

[00174] A rede em ponte acoplada ao DBB 1822 (por exemplo, o distrito de núcleo 1810) pode ser baseada em IP. A rede de núcleo (ou distrito) que interliga os DBBs pode ser uma Rede Privada Virtual de L3 (VPN), uma VPN de L2, ou redes IP padrões. Em tais cenários, o DBB pode encapsular os quadros de dados MAC de seu distrito local com um endereço DBB de destino apropriado, que pode ser um cabeçalho MPLS ou IP.

[00175] A Figura 27 ilustra uma modalidade de um sistema de encaminhamento de quadro de dados 2700 que pode ser utilizado em uma rede em ponte de Camada 2, tal como para os distritos de rede interconectados 1800. O esquema de encaminhamento de quadro de dados 2700 pode também implementar o esquema de encapsulamento de endereços de rede assimétrico acima. A rede em ponte de Camada 2 pode compreender um distrito de núcleo 2710, uma pluralidade de DBBs 2722 ou comutadores de fronteira de distrito em uma pluralidade de distritos 2720 acoplados ao distrito de núcleo 2710, e uma pluralidade de comutadores intermediários ou de borda 2724 e servidores físicos 2726 acoplados a DBBs correspondentes 2022 nos seus distritos 2720. Os servidores físicos 2726 podem compreender uma pluralidade de VMs e comutadores virtuais (não mostrado). Alguns dos DBBs 2722, comutadores intermediários / de borda 2724, e servidores físicos 2726 em todos os distritos 2720 podem pertencer a uma VLAN estabelecida na rede em ponte de Camada 2 e associada a um VLAN ID. Os componentes da rede em ponte de Camada 2 podem ser dispostos como mostrado na Figura 27.

[00176] De acordo com o esquema de encapsulamento de endereços de rede assimétrico, um comutador intermediário / de borda 2724 pode receber um quadro 2740, por exemplo, um quadro Ethernet, a partir de uma primeira VM (host A) em um servidor físico 2726 em um primeiro distrito (distrito 1 ). O quadro 2040 poderá ser destinado a uma Segunda VM (host B), em um segundo servidor físico 2726 em um segundo distrito (distrito 2). O quadro 2040 pode compreender um B- MAC DA 2742 para um segundo DBB (DBB2) no distrito 2, o B- MAC SA 2744 para o host A (ToR A), o C-MAC DA 2746 para o host B (B), um C-MAC SA 2748 para o host A (A), um IP-SA 2750 para host A (A), um IP-DA 2752 para o host B (B), e carga. O comutador intermediário / de borda 2724 pode encaminhar o quadro 2040 para um primeiro DBB 2722 (DBB1) no distrito 1. DBB1 pode receber e processar o quadro 2740 para obter um quadro interior 2760. O quadro interior 2760 pode compreender um B-MAC DA 2762 para DBB2, um B-MAC SA 2764 para DBB1, um C-MAC DA 2766 para o host B (B), um C- MAC SA 2768 para o host A, (A) um IP-SA 2770 para o host A (A), um IP-DA 2752 para o host B (B), e carga. DBB1 pode então encaminhar o quadro interior 2760 do distrito 2 via distrito de núcleo 2710.

[00177] DBB2 no distrito 2 pode receber e de- encapsular o quadro interior 2740 para obter um segundo quadro 2780. DBB2 pode remover B-MAC DA 2762 para DBB2 e um B-MAC SA 2764 a partir do quadro interior 2760 para obter o segundo quadro 2780. Assim, o segundo quadro 2780 pode compreender um C-MAC DA 2782 para o host B (B), um C-MAC SA 2784 para o host A (A), um IP-SA 2786 para o host A (A), um IP-DA 2788 para o host B (B), e carga. DBB2 pode enviar o segundo quadro para o host B 2780 no distrito 2.

[00178] No esquema de encaminhamento de quadro de dados 2700, o comutador intermediário / de borda 2724 não pode desempenhar a função de MAC-em-MAC para quadros recebidos a partir de servidores físicos locais 2724 acoplados ao comutador intermediário / de borda 2724. Em outra modalidade, o procedimento de encapsulamento do primeiro quadro 2740 pode ser realizado por um comutador virtual no servidor físico 2726 em vez do comutador de intermediário / de borda 2724, que pode transmitir o primeiro quadro 2740 sem processamento a partir do servidor físico 2726 para o DBB correspondente 2722.

[00179] A Figura 28 ilustra uma modalidade de um método de processamento ARP melhorado 2900 que pode ser utilizado em uma rede em ponte de Camada 2, tal como para os distritos de rede interconectados 1800. O melhor método de processamento ARP 2900 pode começar no passo 2801, onde um host local 2810 pode enviar um pedido ARP para uma localização local 2830 através de uma primeira ponte 2820, por exemplo, um DBB local. A localização local 2830 pode corresponder ao mesmo local ou distrito que o host local 2810. O pedido ARP pode ser enviado para obter um endereço MAC associado com um host remoto 2860. O host local 2810 pode ser atribuído um endereço IP IPA e um endereço MAC A. O host remoto 2860 pode ser atribuído um endereço IP IPB e um endereço MAC B. O pedido ARP pode compreender um endereço SA MAC A e endereço IP A SA IPA para o host local 2810. O pedido ARP pode também incluir um endereço DA MAC definido para zero e um endereço DA IP IPB para o host remoto 2860. A localização local 2830 pode encaminhar o pedido ARP para um servidor ARP 2840 na rede.

[00180] No passo 2802, o servidor ARP 2840 pode enviar uma resposta EARP para a primeira ponte 2820. A resposta EARP pode compreender um endereço SA MAC A e um endereço SA IP IPA para o host local 2810, um endereço DA MAC B e um endereço DA IP IPB para o host remoto 2860, e um endereço MAC para uma segunda ponte em uma localização remota 2850 do host remoto 2860. No passo 2803, a primeira ponte 2820 pode processar / de-encapsular a resposta EARP e enviar uma resposta ARP para o host local 2810. A resposta ARP pode compreender o endereço MAC A e endereço IP IPA para o host local 2810, e o endereço MAC B e o endereço IP IPB para o host remoto 2860. Assim, o host local 2810 pode tornar-se consciente do endereço MAC B do host remoto 2860. A primeira ponte 2820 pode também associar (em uma tabela local), o endereço MAC Y da ponte remota na localização remota 2850 com o endereço IP IPB do host remoto 2860. A primeira ponte 2820 pode não precisar armazenar o endereço MAC B do host remoto 2860.

[00181] No passo 2804, o host local 2810 pode enviar um quadro de dados destinado ao host remoto 2860 para a primeira ponte 2820. O quadro de dados pode incluir um endereço SA MAC e endereço SA IP do host local 2810, e o endereço DA MAC e o endereço DA IP do host remoto 2860. No passo 2805, a primeira ponte 2820 pode receber e processar / encapsular o quadro de dados para obter um quadro interior. O quadro interior pode incluir uma endereço SA MAC X da primeira ponte 2820, um endereço DA MAC Y da ponte remota, um endereço DA MAC B e um endereço DA IP IPB do host remoto 2860, e um endereço SA MAC A e um endereço SA IP IPA do host local 2810. No passo 2806, a ponte remota na localização remota 2850 pode receber o quadro interior e processar / de-encapsular o quadro interior para obter um segundo quadro pela remoção do endereço SA MAC X da primeira ponte 2820 e o endereço DA MAC Y da ponte remota. Assim, o segundo quadro pode ser semelhante ao quadro inicial enviado a partir do host local 2810. A ponte remota pode então enviar o segundo quadro para o host remoto 2860. O método pode, então, 2800 terminar.

[00182] No método de processamento ARP melhorado 2900, a rede de núcleo pode usar 802.1aq ou TRILL para a descoberta de topologia. Se a rede de núcleo utiliza 802.1aq para a descoberta de topologia, então a primeira ponte 2820 pode não encapsular o quadro enviado a partir do host local 2810 e pode encaminhar o quadro para a localização remota 2850 sem processamento. Além disso, o quadro transmitido através da rede de núcleo pode ser inundado apenas no segundo local 2850 e só quando a porta de saída indicada no quadro não foi aprendida.

[00183] Em uma modalidade, um esquema de resolução de endereço estendido pode ser implementado por gateways de distrito ou nós de gateway que podem ser nós de borda TRILL, nós de borda MAC-em-MAC, ou qualquer outro tipo de sobreposição de nós de borda de rede. O esquema de resolução de endereço estendido pode ser baseado no esquema proxy ARP implementado por um DBB em uma pluralidade de distritos em uma rede em ponte de Camada 2, tal como o esquema de proxy ARP 1900. Por exemplo, os nós intermediários / de borda 2724 que podem ser acoplados a uma pluralidade de servidores físicos e / ou VMs podem implementar um esquema de resolução de endereço estendido semelhante ao esquema de proxy ARP descrito acima. O nó de gateway pode utilizar o servidor DS no esquema de proxy ARP para resolver mapeamento entre um destino de destino (por exemplo, host) e um nó de borda de saída. O nó de borda de saída pode ser um gateway de distrito de destino, um nó de saída TRILL, um nó de borda MAC-em-MAC, ou qualquer outro tipo de sobreposição de nó de borda de rede. A resposta a partir do DS pode também ser uma resposta EARP como descrito acima.

[00184] O esquema de resolução de endereço estendido pode ser usado para dimensionar redes DC com um número substancial de hosts. A rede de sobreposição (por exemplo, rede em ponte) pode ser uma rede MAC-em-MAC, TRILL, ou outros tipos de redes de Camada 3 ou de Camada 2 sobre Ethernet. A borda de rede de sobreposição pode ser um comutador de rede, como um comutador de acesso (ou comutador de ToR) ou um comutador de agregação (ou comutador de EoR). A borda de rede de sobreposição também pode corresponder a um comutador virtual em um servidor. Pode haver dois cenários para redes de sobreposição para o uso do esquema de resolução de endereço estendido. O primeiro cenário corresponde a um esquema simétrico, tal como, por redes TRILL ou MAC-em-MAC. Neste cenário, o nó de borda de sobreposição pode executar tanto as partes de encapsulamento e de-encapsulamento. O segundo cenário corresponde a um esquema assimétrico, onde a rede de sobreposição pode implementar o esquema de encapsulamento de endereços de rede assimétrico acima.

[00185] A Figura 29 ilustra uma modalidade de um método de resolução de endereço estendido 2900 que pode ser implementado em uma rede de sobreposição. O método de resolução de endereço estendido 2900 pode começar no passo 2901, onde uma primeira VM 2910 (VM A) pode enviar um quadro ou pacote endereçado para uma segunda VM 2980 (VM B) para um primeiro hipervisor (HV) 2920 (HV A). VM A e VM B podem ser hosts finais em diferentes distritos. VM A pode ser acoplada a HV A em um primeiro distrito e VM B pode ser acoplado a um segundo HV 2970 (HV B) em um segundo distrito. O HV pode ser um nó de rede de sobreposição configurado para encapsular ou adicionar o cabeçalho de endereço de rede de sobreposição em um quadro de dados ou pacote. No cenário de esquema simétrico, o HV pode ser um DBB, um nó de borda TRILL, ou um nó de borda MAC-em-MAC. No cenário de esquema assimétrico, o HV pode ser um comutador virtual dentro de um hipervisor ou um comutador de acesso.

[00186] No passo 2902, HV A pode enviar um pedido de resolução de endereço (AR) para um servidor ARP 2930 para recuperar o mapeamento de endereço VM B IP para um endereço VM B MAC e par de endereços HV B MAC, no caso do esquema simétrico. O servidor ARP pode compreender ou corresponder a um servidor DS, tal como o DS 1940. No esquema assimétrico, o mapeamento pode ser de endereço VM B IP para um endereço VM B MAC e segundo DBB 2960 (DBB B) par de endereços MAC. DBB B pode ser um DBB remoto no mesmo distrito de VM B.

[00187] HV A pode também ser configurado para interceptar pedidos ARP (transmitido) de VMs locais e encaminhar os pedidos ARP para o servidor DS. HV A pode, em seguida, recuperar respostas EARP a partir do servidor DS e salvar em cache os mapeamentos entre endereços de destino e endereços de gateway de destino (como indicado pelas respostas EARP). O endereço de gateway de destino pode também ser referido aqui como um endereço de local de destino. Em outra modalidade, em vez de interceptar pedidos ARP por HV A, o servidor DS pode enviar informação de mapeamento consolidada para HV A na base regular ou periódica ou quando VMs movem ou migram entre distritos. A informação de mapeamento consolidada pode compreender a mesma informação trocada com L2GWs nas redes de Camada 2 virtuais descritas acima. Por exemplo, a informação de mapeamento consolidada pode ser formatada como anúncios de grupo gratuitos, como descrito acima.

[00188] No passo 2903, HV A pode criar um cabeçalho de endereço interior que compreende (SA: VM A MAC, DA: VM B MAC), e um cabeçalho exterior que compreende (SA: HV A MAC, DA: HV B MAC) no caso do esquema simétrico. No esquema assimétrico, o cabeçalho exterior pode compreender (SA: HV A MAC, DA: DBB B MAC). HV A pode adicionar o cabeçalho interior e cabeçalho exterior para o quadro recebido a partir de VM A e enviar o quadro resultante para uma ponte 2940 acoplada a HV A no mesmo distrito. Dentro do distrito, o DA do cabeçalho exterior, que pode ser HV B MAC ou DBB B MAC, não pode ser conhecido.

[00189] No passo 2904, o quadro pode ser encaminhado a partir da ponte 2940 para um primeiro DBB 2950 (DBB A) no distrito. Em DBB A, o DA HV B MAC ou DBB B MAC pode ser conhecido já que o núcleo pode estar operando em encaminhamento roteado (por exemplo, 802.1aq SPBM ou TRILL) e aprendizagem pode ser desativada no núcleo. No passo 2905, DBB A pode encaminhar o quadro para DBB B.

[00190] No passo 2906, DBB B pode transmitir o quadro para HV B, já que DBB pode conhecer todos os endereços HV do subsistema de roteamento, no caso do esquema simétrico. No esquema assimétrico, DBB pode remover o cabeçalho exterior que compreende (DA: DBB MAC) e encaminhar o quadro para VM B MAC no cabeçalho restante, já que o endereço local para o distrito pode ser registrado e conhecido dentro do distrito.

[00191] No passo 2907, HV B pode receber o quadro, remover o cabeçalho exterior compreendendo (DA: HV B MAC), e encaminhar o quadro resultante para VM B MAC no cabeçalho restante, já que os endereços locais para o servidor são conhecidos por HV B, no caso do esquema simétrico. Além disso, HV B pode aprender o mapeamento a partir de VM A MAC (SA no cabeçalho restante) para HV A MAC (SA no cabeçalho removido), que pode ser subsequentemente utilizado em quadros de resposta a partir de VM B para VM A. No esquema assimétrico, além de encaminhamento do quadro para VM B, HV B pode enviar uma mensagem ARP para o servidor ARP (ou DS) 2930 para recuperar o mapeamento a partir de VM A MAC (SA no cabeçalho restante) para DBB A MAC, que pode ser posteriormente utilizado em quadros de resposta a partir da VM B para VM A.

[00192] VM B pode então enviar quadros endereçados para VM A (endereço de destino IP). No passo 2908, HV B pode criar um cabeçalho de endereço interior que compreende (SA: VM B MAC, DA: VM A MAC) e um cabeçalho exterior que compreende (SA: HV B MAC, DA: HV A MAC) em um quadro, no caso do esquema simétrico. HV B pode manter mapeamento VM A IP para VM A MAC e mapeamento VM A MAC para HV A MAC a partir de uma mensagem recebida anteriormente ou resposta AR. No esquema assimétrico, o cabeçalho exterior pode compreender (SA: HV B MAC, DA: DBB A MAC). HV B pode manter mapeamento VM A MAC para DBB A MAC a partir de uma resposta AR recebida anteriormente. Alternativamente, HV B pode enviar uma mensagem ARP para o servidor ARP (ou DS) para recuperar o mapeamento quando necessário. O quadro pode, então, ser encaminhado a partir de VM B para VM A da mesma maneira descrita nos passos acima (por exemplo, na direção inversa). O método pode, então, 2900 terminar.

[00193] A Figura 30 ilustra uma modalidade de uma unidade de componente de rede 3000, que pode ser qualquer dispositivo que envia / recebe pacotes através de uma rede. Por exemplo, a unidade de componente de rede 3000 pode ser localizada nos L2GWs através das diferentes localizações / domínios nas redes Camada 2 virtuais / pseudo. A unidade de componente de rede 3000 pode compreender uma ou mais portas de ingresso ou unidades 3010 para recebimento de pacotes, objetos, ou TLVs a partir de outros componentes de rede lógica, circuitos lógicos 3020 para determinar quais componentes de rede enviar os pacotes para, e uma ou mais portas de saída ou unidades 3030 para a transmissão de quadros para os outros componentes de rede.

[00194] Os componentes de rede descritos acima podem ser implementados em qualquer componente de rede de propósito geral, como um sistema de computador ou componente de rede com poder de processamento suficiente, recursos de memória e capacidade de transferência de rede para lidar com a carga de trabalho necessária colocada em cima deles. A Figura 31 ilustra um típico, sistema de computador de uso geral 3100 adequado para a execução de uma ou mais modalidades dos componentes aqui descritos. O sistema de computador de uso geral 3100 inclui um processador 3102 (que pode ser referido como uma CPU) que está em comunicação com dispositivos de memória, incluindo armazenamento secundário 3104, memória só de leitura (ROM) 3106, memória de acesso aleatório (RAM) 3108, dispositivos de entrada / saída (I / O) 3110 e dispositivos de conectividade de rede 3112. O processador 3102 pode ser implementado como um ou mais chips de CPU, ou pode ser parte de um ou mais circuitos integrados de aplicação específica (ASIC).

[00195] O armazenamento secundário 3104 é normalmente composto por um ou mais discos rígidos ou drives de fita e é usado para armazenamento não volátil de dados e como um dispositivo de armazenamento de dados de sobre fluxo se RAM 3108 não é suficientemente grande para conter todos os dados de trabalho. Armazenamento secundário 3104 pode ser usado para armazenar programas que são carregados para a RAM 3108 quando tais programas são selecionados para a execução. A ROM 3106 é usada para armazenar instruções e, talvez, dados que são lidos durante a execução do programa. ROM 3106 é um dispositivo de memória não volátil que tem tipicamente uma capacidade de memória pequena em relação à capacidade de memória maior de armazenamento secundário 3104. A RAM 3108 é usada para armazenar dados voláteis e talvez para armazenar instruções. O acesso a ambas ROM 3106 e RAM 3108 é tipicamente mais rápido do que ao armazenamento secundário 3104.

[00196] Pelo menos uma modalidade é divulgada e variações, combinações e / ou modificações da modalidade (s) e / ou características da modalidade (s) feitas por uma pessoa com conhecimentos atuais na arte estão dentro do âmbito da divulgação. Modalidades alternativas que resultam da combinação, integração, e / ou omissão de características da modalidade (s) estão também dentro do âmbito da revelação. Onde intervalos numéricos ou limitações são expressamente indicados, esses intervalos expressos ou limitações devem ser entendidos para incluir intervalos iterativos ou limitações de magnitude semelhante caindo dentro dos intervalos indicados expressamente ou limitações (por exemplo, desde cerca de 1 a cerca de 10 inclui, 2, 3, 4 , etc; maior do que 0,10 inclui 0,11, 0,12, 0,13, etc.) Por exemplo, sempre que um intervalo numérico com um limite inferior, R1, e um limite superior, Ru, é divulgado, qualquer número caindo dentro do intervalo é especificamente divulgado. Em particular, os seguintes números dentro do intervalo são especificamente descritos: R = R1 + k * (Ru - R1), em que k é uma variável que varia de 1 por cento a 100 por cento, com um incremento de 1 por cento, isto é, k é 1 por cento, 2 por cento, 3 por cento, 4 por cento, 7 por cento, ..., 70 por cento, 71 por cento, 72 por cento, ..., 95 por cento, 96 por cento, 97 por cento, 98 por cento, 99 por cento, ou 100 por cento. Além disso, qualquer intervalo numérico definido por dois números R como definido acima é também especificamente divulgado. O uso do termo "opcionalmente" em relação a qualquer elemento de uma reivindicação significa que o elemento é necessário, ou alternativamente, o elemento não é necessário, ambas as alternativas estando dentro do âmbito da reivindicação. A utilização de termos mais gerais, tais como compreende, inclui, e tendo deve ser entendida para fornecer suporte para termos mais estreitos, como consistindo de, essencialmente consistindo de, e composto substancialmente de. Por conseguinte, o âmbito de proteção não é limitado pela descrição acima referida, mas é definido pelas reivindicações que seguem, esse âmbito incluindo todos os equivalentes do objeto das reivindicações. Cada e todas reivindicações são incorporadas como divulgação adicional na especificação e as reivindicações são modalidade (s) da presente divulgação. A discussão de uma referência na divulgação não é uma admissão de que é arte anterior, especialmente qualquer referência que tem uma data de publicação após a data de prioridade deste pedido. A divulgação de todas as patentes, pedidos de patentes e publicações citados na divulgação são aqui incorporadas por referência, na medida em que elas fornecem detalhes exemplares, processuais, ou outros detalhes complementares para a divulgação.

[00197] Embora várias modalidades tenham sido fornecidas na presente descrição, deve ser entendido que os sistemas e métodos divulgados podem ser incorporados em muitas outras formas específicas sem se afastar do espírito ou o âmbito da presente divulgação. Os presentes exemplos devem ser considerados como ilustrativos e não restritivos, e a intenção não deve ser limitada aos detalhes apresentados neste documento. Por exemplo, os vários elementos ou componentes podem ser combinados ou integrados em um outro sistema ou certas características podem ser omitidas, ou não implementadas.

[00198] Além disso, técnicas, sistemas, subsistemas, e os métodos descritos e ilustrados nas várias modalidades como discretos ou separados podem ser combinados ou integrados com outros sistemas, módulos, técnicas, ou métodos sem se afastar do âmbito da presente descrição. Outros itens mostrados ou discutidos como acoplados ou integrados diretamente ou comunicando uns com os outros podem ser acoplados ou indiretamente comunicar através de alguma interface, dispositivo ou componente intermediário tanto de forma elétrica, mecânica ou de outra forma. Outros exemplos de modificações, substituições e alterações são determináveis por um perito na arte e podem ser feitas sem se afastar do espírito e do âmbito aqui descrito.

Claims (17)

1. Sistema (400), caracterizado pelo fato de que compreende: uma rede de serviços (410); e uma pluralidade de domínios de acesso (Loc 1, Loc 2) em uma pluralidade de diferentes localizações físicas acopladas à rede de serviços (410) através de uma pluralidade de nós de borda (GW1, GW2) nos domínios de acesso (Loc 1, Loc 2), em que um primeiro nó de borda (GW1) localizado em um primeiro domínio de acesso (Loc 1) da pluralidade de domínios de acesso é configurado para: manter uma pluralidade de endereços de Protocolo Internet (IP) de uma pluralidade de hosts (B) localizados em um segundo domínio de acesso (Loc 2) da pluralidade de domínios de acesso, e manter uma pluralidade de endereços de Controle de Acesso ao Meio (MAC) para uma pluralidade de nós de borda (422); receber um quadro que compreende um endereço IP de destino que corresponde a um dos endereços IP para um dos hosts (B) localizados no segundo domínio de acesso (Loc 2); determinar, com base em uma tabela de mapeamento e com base no endereço IP de destino de um dos hosts (B) localizados no segundo domínio de acesso (Loc 2), um endereço MAC de destino do segundo nó de borda (GW2) pertencente ao segundo domínio de acesso (Loc 2), em que a tabela de mapeamento é usada para mapear os endereços IP da pluralidade de hosts (B) no segundo domínio de acesso (Loc 2) para a pluralidade de endereços MAC da pluralidade de nós de borda (422), e em que cada endereço IP de um host entre a pluralidade de hosts (B) é mapeado para um endereço MAC, entre a pluralidade de endereços MAC, do segundo nó de borda (GW2) pertencente ao segundo domínio de acesso (Loc 2); adicionar um cabeçalho MAC exterior ao quadro, chegando assim a um quadro encapsulado (460), o cabeçalho MAC exterior compreendendo: o endereço MAC do segundo nó de borda (GW2) pertencente ao segundo domínio de acesso (Loc 2) como endereço MAC de destino, o endereço MAC do primeiro nó de borda (GW1) do primeiro domínio de acesso (Loc 1) como endereço MAC de origem, e um Tipo Ether que indica que o endereço MAC de destino do quadro encapsulado (460) precisa de tradução de endereço MAC; e transmitir o quadro encapsulado (460) através da rede de serviço (410) para o segundo nó de borda (422) do segundo domínio de acesso (Loc 2) de acordo com o endereço MAC de destino do segundo nó de borda (422) do segundo domínio de acesso (Loc 2), de modo que o quadro é encaminhado para um dos hosts (B) através do segundo nó de borda (GW2), em que o quadro é recebido de um host de origem (A) localizado no primeiro domínio de acesso (Loc 1), e em que o quadro é recebido do host de origem (A) quando o host de origem (A) não conhece um endereço de Controle de Acesso ao Meio (MAC) de um dos hosts (B) localizados no segundo domínio de acesso (Loc 2).

2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que uma pluralidade de endereços MAC de host é usada para identificar os hosts (B) localizados no segundo domínio de acesso (Loc 2), em que o primeiro nó de borda (GW1) não está localizado no segundo domínio de acesso (Loc 2), em que a pluralidade de domínios de acesso (Loc 1, Loc 2) são domínios de acesso de camada 2 e camada 3, em que o primeiro nó de borda (GW1) não está ciente dos endereços MAC para os hosts (B) localizados no segundo domínio de acesso (Loc 2), e em que o endereço do segundo nó de borda (GW2) é um endereço MAC.

3. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro nó de borda (GW1) e o segundo nó de borda (GW2) são gateways de Camada 2, em que os hosts (B) localizados no segundo domínio de acesso (Loc 2) compreendem uma pluralidade de aplicações, servidores, e / ou máquinas virtuais, e em que o primeiro domínio de acesso (Loc 1) e o segundo domínio de acesso (Loc 2) estão localizados em diferentes centros de dados (DCs).

4. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que uma pluralidade de segundos endereços identifica uma pluralidade de segundos hosts (A) localizados dentro do primeiro domínio de acesso (Loc 1), em que uma pluralidade de segundos endereços IP é associada aos segundos hosts, e em que o primeiro nó de borda (GW1) é configurado para armazenar os segundos endereços IP.

5. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que uma pluralidade de comutadores (624) no primeiro domínio de acesso (Loc 1) atua como representantes para o primeiro nó de borda (GW1), e em que os comutadores (624) recebem e mantém uma pluralidade de diferentes subconjuntos de endereços IP do primeiro nó de borda (GW1).

6. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que uma pluralidade de comutadores (624) no primeiro domínio de acesso (Loc 1) atua como proxies de Protocolo de Resolução de Endereço (ARP) ou proxies de Descoberta de Vizinhança (ND), e em que os proxies ARP ou proxies ND trocam uma pluralidade de pedidos e respostas ARP ou ND com uma pluralidade de segundos hosts, e em que o host de origem (A) é localizado no primeiro domínio de acesso (Loc 1).

7. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o segundo nó de borda (GW2) é configurado para: receber o quadro encapsulado; traduzir o quadro encapsulado para obter um segundo endereço MAC que identifica o um dos hosts (B) no segundo domínio de acesso (Loc 2); modificar o quadro encapsulado com o segundo endereço MAC para formar um quadro interior; e transmitir o quadro interior para o um dos hosts (B), em que o um dos hosts (B) foi designado para receber o quadro.

8. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que um host de destino é movido do primeiro domínio de acesso (Loc 1) para o segundo domínio de acesso (Loc 2), e em que o endereço de destino corresponde a um endereço MAC do host de destino.

9. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o quadro encapsulado compreende ainda um Tipo Ether que indica que o quadro encapsulado precisa de tradução de endereço MAC.

10. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro nó de borda (GW1) é configurado adicionalmente para: receber um pedido de Protocolo de Resolução de Endereço (ARP) ou um pedido de Descoberta de Vizinhança (ND) de um host de origem (A) no primeiro domínio de acesso (Loc 1) para o um dos hosts (B) localizados no segundo domínio de acesso (Loc 2); e enviar um endereço MAC do primeiro nó de borda (GW1) para um primeiro host em resposta à determinação de que um dos hosts (B) é mapeado para o segundo nó de borda (GW2).

11. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que mapear o endereço de destino não compreende transmitir um pedido de Protocolo de Resolução de Endereço (ARP) ou um pedido de Descoberta de Vizinhança (ND) dentro da rede de serviços (410).

12. Componente de rede (3100), caracterizado pelo fato de que compreende: uma memória (3104, 3106, 3108); e um processador (3102) acoplado à memória (3104, 3106, 3108), em que a memória armazena instruções que, quando executadas, fazem com que o componente de rede (3100) execute o seguinte: manter uma pluralidade de endereços de Protocolo Internet (IP) de uma pluralidade de hosts (B) localizados em uma rede (Loc 2), e manter uma pluralidade de endereços de Controle de Acesso ao Meio (MAC) para uma pluralidade de gateways de Camada 2 (422); receber um quadro que compreende um endereço IP de destino que corresponde a um dos endereços IP para um dos hosts (B) localizados na rede (Loc 2); determinar, com base em uma tabela de mapeamento e com base no endereço IP de destino de um dos hosts (B) localizados na rede (Loc 2), um endereço MAC de destino de um gateway de Camada 2 (GW2) localizado em uma borda da rede (Loc 2), em que a tabela de mapeamento é usada para mapear os endereços IP da pluralidade de hosts (B) na rede (Loc 2) para a pluralidade de endereços MAC da pluralidade de gateways de Camada 2 (422), e em que cada endereço IP de um host entre a pluralidade de hosts (B) é mapeado para um endereço MAC, entre a pluralidade de endereços MAC, do gateway de Camada 2 (GW2) localizado em uma borda da rede (Loc 2); adicionar um cabeçalho MAC exterior ao quadro, chegando assim a um quadro encapsulado (460), o cabeçalho MAC exterior compreendendo: o endereço MAC do gateway de Camada 2 (GW2) localizado em uma borda da rede (Loc 2) como endereço MAC de destino, o endereço MAC do componente de rede (3100) localizado em uma borda de uma segunda rede (Loc 1) como endereço MAC de origem, e um Tipo Ether que indica que o endereço MAC de destino do quadro encapsulado (460) precisa de tradução de endereço MAC; e transmitir o quadro encapsulado (460) através da rede de serviço (410) para o gateway de Camada 2 (GW2) localizado em uma borda da rede (Loc 2) de acordo com o endereço MAC de destino do gateway de Camada 2 (GW2) localizado em uma borda da rede (Loc 2), de modo que o quadro é encaminhado para um dos hosts (B) através do gateway de Camada 2 (GW2), em que o gateway de Camada 2 (GW2) não está localizado na segunda rede (Loc 1), em que o quadro é recebido de um host de origem (A) localizado na segunda rede (Loc 1), em que o quadro é recebido do host de origem (A) quando o host de origem (A) não está ciente de um endereço de Controle de Acesso ao Meio (MAC) que identifica um dos hosts (B) localizados na rede (Loc 2).

13. Componente de rede (3100), de acordo com a reivindicação 12, caracterizado pelo fato de que o componente de rede (3100) não é configurado para manter uma pluralidade de endereços MAC de host associados aos hosts (B) localizados na rede (Loc 2), e em que o componente de rede (3100) é configurado adicionalmente para manter uma pluralidade de segundos endereços MAC de host que são associados a uma pluralidade de segundos hosts localizados dentro da segunda rede (Loc 1), e em que o endereço do gateway de Camada 2 (GW2) é um endereço MAC.

14. Componente de rede (3100), de acordo com a reivindicação 12, caracterizado pelo fato de que mapear o endereço de destino não compreende a transmissão de um pedido de protocolo de resolução de endereço (ARP) para a rede (Loc 2).

15. Método para promover uma comunicação entre uma pluralidade de domínios de acesso (Loc 1, Loc 2), caracterizado pelo fato de que o método compreende: manter, em um nó de borda (GW1), uma pluralidade de endereços de Protocolo Internet (IP) de uma pluralidade de hosts (B) localizados em um domínio de acesso (Loc 2), e manter uma pluralidade de endereços de Controle de Acesso ao Meio (MAC) para uma pluralidade de nós de borda (422); receber um quadro que compreende um endereço IP de destino que corresponde a um dos endereços IP para um dos hosts (B) localizados no domínio de acesso (Loc 2); determinar, com base em uma tabela de mapeamento e com base no endereço IP de destino de um dos hosts (B) localizados no domínio de acesso (Loc 2), um endereço MAC de destino de um segundo nó de borda (GW2) localizado em uma borda do domínio de acesso (Loc 2), em que a tabela de mapeamento é usada para mapear os endereços IP da pluralidade de hosts (B) no domínio de acesso (Loc 2) para a pluralidade de endereços MAC da pluralidade de nós de borda (422), e em que cada endereço IP de um host entre a pluralidade de hosts (B) é mapeado para um endereço MAC, entre a pluralidade de endereços MAC, do segundo nó de borda (GW2) localizado em uma borda do domínio de acesso (Loc 2); adicionar um cabeçalho MAC exterior ao quadro, chegando assim a um quadro encapsulado (460), o cabeçalho MAC exterior compreendendo: o endereço MAC do segundo nó de borda (GW2) localizado em uma borda do domínio de acesso (Loc 2) como endereço MAC de destino, o endereço MAC do nó de borda (GW1) localizado em uma borda de um segundo domínio de acesso (Loc 1) como endereço MAC de origem, e um Tipo Ether que indica que o endereço MAC de destino do quadro encapsulado (460) precisa de tradução de endereço MAC; e transmitir o quadro encapsulado (460) através da rede de serviço (410) para o segundo nó de borda (422) localizado em uma borda do domínio de acesso (Loc 2) de acordo com o endereço MAC de destino do segundo nó de borda (422) localizado em uma borda do domínio de acesso (Loc 2), de modo que o quadro é encaminhado para um dos hosts (B) através do segundo nó de borda (GW2), em que o segundo nó de borda (GW2) não está localizado no segundo domínio de acesso (Loc 1), em que o quadro é recebido de um host de origem (A) localizado no segundo domínio de acesso (Loc 1), e em que o quadro é recebido do host de origem (A) quando o host de origem (A) não armazena um endereço de Controle de Acesso ao Meio (MAC) que corresponde ao endereço de destino.

16. Método, de acordo com a reivindicação 15, caracterizado pelo fato de que mapear o endereço de destino não compreende a transmissão de um pedido de Protocolo de Resolução de Endereço (ARP) para o domínio de acesso (Loc 2).

17. Método, de acordo com a reivindicação 15, caracterizado pelo fato de que o endereço do segundo nó de borda (GW2) é um endereço MAC.

Images