BR112016025264B1 - Dispositivo de plano de controle em um sistema de computação em nuvem para executar uma pluralidade de máquinas virtuais para implantar a virtualização de função de rede - Google Patents

Abstract

IMPLANTAÇÃO DE UM NÚCLEO DE PACOTE 3G EM UM COMPUTADOR EM NUVEM COM DADOS DE OPENFLOW E PLANOS DE CONTROLE. Um dispositivo de plano de controle em um sistema de computação em nuvem que executa uma pluralidade de máquinas virtuais para implantar virtualização de função de rede (NFV). O dispositivo de plano de controle é operável para gerar a implantação de um protocolo de túnel (GTP) de serviço de rádio de pacote geral (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) que tem uma arquitetura dividida em que um plano de controle do PC da rede de 3G está no sistema de computação em nuvem. O plano de controle se comunica com um plano de dados do PC através de um protocolo de plano de controle. O plano de dados é implantado em uma pluralidade de dispositivos de rede da rede de 3G. O dispositivo de plano de controle e a pluralidade de máquinas virtuais são operáveis para se comunicarem com outros dispositivos de plano de controle no sistema de computação em nuvem e com a pluralidade de dispositivos de rede do plano de dados.

Description

REFERÊNCIA CRUZADA AO PEDIDO RELACIONADO

[0001] O presente pedido de patente é uma Continuação em Parte do Pedido N° 13/220.471, depositado em 29 de agosto de 2011.

CAMPO DA INVENÇÃO

[0002] As modalidades da invenção referem-se a um método e um sistema para implantar um plano de controle de um núcleo de pacote de terceira geração em um sistema de computador em nuvem. Especificamente, as modalidades da invenção se referem ao uso do protocolo de OpenFlow para implantar o controle de um plano de dados pelo plano de controle que é executado em um sistema de computador em nuvem.

ANTECEDENTES

[0003] O sistema de raio de pacote geral (GPRS) é um sistema que é usado para transmitir pacotes de Protocolo de Internet entre dispositivos de usuário como telefones celulares e a Internet. O sistema de GPRS inclui a rede principal de GPRS, que é uma parte integral do sistema global para comunicação móvel (GSM). Esses sistemas são amplamente utilizados por fornecedores de rede de telefone celular para permitir serviços de telefone celular sobre áreas grandes.

[0004] O protocolo de túnel de GPRS (GTP) é um protocolo de comunicação importante utilizado dentro da rede principal de GPRS. O GTP permite dispositivos de usuário final (por exemplo, telefones celulares) em uma rede de GSM para se mover de lugar para lugar enquanto continua a se conectar à Internet. Os dispositivos de usuário final são conectados à Internet através de um nó de suporte de GPRS de porta de comunicação (GGSN). O GGSN rastreia os dados do dispositivo de usuário final provenientes do nó de suporte de GPRS de serviço (SGSN) do dispositivo de usuário final que maneja a sessão que se origina a partir do dispositivo de usuário final.

[0005] Três formas de GTP são usadas pela rede principal de GPRS. O GTP-U é usado para a transferência dos dados de usuário em túneis separados para cada contexto de protocolo de dados de pacote (PDP). O GTP-C é usado dentro da rede principal de GPRS para sinalização entre o GGSN e o SGSN. O GTP' é usado para portar dados de carga provenientes da Função de Dados de Carga (CDF) da rede de GSM ou de UMTS para uma função de porta de comunicação de carga (CGF), que fornece informações de uso de dispositivo de usuário final necessários a um sistema de cobrança. O GTP’ usa a mesma estrutura de mensagem que o GTP-C e o GTP-U.

SUMÁRIO

[0006] Um dispositivo de plano de controle em um sistema de computação em nuvem executa uma pluralidade de máquinas virtuais para implantar virtualização de função de rede (NFV). O dispositivo de plano de controle é operável para gerar a implantação de um protocolo de túnel (GTP) de serviço de rádio de pacote geral (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) que tem uma arquitetura dividida em que um plano de controle do PC da rede de 3G está no sistema de computação em nuvem. O plano de controle se comunica com um plano de dados do PC através de um protocolo de plano de controle. O plano de dados é implantado em uma pluralidade de dispositivos de rede da rede de 3G. O dispositivo de plano de controle e a pluralidade de máquinas virtuais são operáveis para se comunicarem com outros dispositivos de plano de controle no sistema de computação em nuvem e com a pluralidade de dispositivos de rede do plano de dados.

[0007] O dispositivo de plano de controle inclui um meio de armazenamento para armazenar um software de plano de controle centralizado que inclui módulos do plano de controle para implantar o plano de controle do PC e um processador acoplado de modo comunicativo ao meio de armazenamento. O processador é operável para executar a pluralidade de máquinas virtuais, em que pelo menos uma dentre a pluralidade de máquinas virtuais é operável para executar o software de plano de controle (CCP) centralizado que inclui pelo menos um dos módulos do plano de controle. Cada módulo do plano de controle fornece um conjunto de funções de plano de controle para gerenciar o plano de dados. O software de CCP é operável para receber uma solicitação para criar um túnel de GTP no PC da rede de 3G entre um nó de suporte de GPRS de serviço (SGSN) e um nó de suporte de GPRS de porta de comunicação (GGSN) para uma sessão de assinante. O software de CCP é operável para configurar uma implantação de comutador de um plano de dados do SGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular pacotes da sessão de assinante e para estabelecer um primeiro ponto de extremidade do túnel de GTP. O software de CCP é operável para configurar pelo menos um comutador em uma rota do túnel de GTP, por meio do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel de GTP, e o software de CCP é operável para configurar uma implantação de comutador de um plano de dados do GGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e para estabelecer um segundo ponto de extremidade do túnel de GTP.

BREVE DESCRIÇÃO DOS DESENHOS

[0008] A presente revelação é ilustrada a título de exemplo, e não a título de limitação, nas Figuras dos desenhos anexos nos quais referências similares indicam elementos similares. Deve ser notado que diferentes referências a "uma" ou "uma (1)" modalidade nesta revelação não são necessariamente à mesma modalidade, e tais referências significam pelo menos uma. Ademais, quando um recurso, estrutura ou característica específica for descrita em conexão com uma modalidade, sugere- se que esteja dentro do conhecimento de um elemento versado na técnica executar tal recurso, estrutura ou característica em conexão com outras modalidades independentemente de serem ou não explicitamente descritas.

[0009] A Figura 1 é um diagrama de uma modalidade de uma rede exemplificativa com um comutador de OpenFlow.

[0010] A Figura 2 é um diagrama que ilustra uma modalidade do conteúdo de uma entrada da tabela de fluxo.

[0011] A Figura 3 ilustra outra arquitetura exemplificativa que implanta OpenFlow.

[0012] A Figura 4 ilustra uma modalidade do processamento de pacotes através de uma pipeline de processamento de pacote do comutador de OpenFlow.

[0013] A Figura 5 é um fluxograma de uma modalidade do processo de correspondência de regra de OpenFlow.

[0014] A Figura 6 é um diagrama dos campos, em que um processo de correspondência pode ser utilizado para identificar regras a serem aplicadas um pacote.

[0015] As Figuras 7A e 7B são um fluxograma de uma modalidade de um processo para processamento de cabeçalho de OpenFlow.

[0016] A Figura 8 é um diagrama de uma modalidade de um núcleo de pacote (PC) de terceira geração (3G).

[0017] A Figura 9 é um diagrama de uma modalidade dos campos de cabeçalho no cabeçalho de encapsulamento de GTP-U primário.

[0018] A Figura 10 é um diagrama de uma modalidade de um sistema de computação em nuvem que presta serviços a um conjunto de clientes.

[0019] A Figura 11 é um diagrama de outra modalidade de um sistema de computação em nuvem que mostra o processo de adição de uma nova ocorrência de serviço a um VPC de cliente.

[0020] A Figura 12 é um diagrama de uma modalidade do PC de 3G implantado no sistema de computação em nuvem.

[0021] A Figura 13 é um fluxograma de uma modalidade de um processo para a operação básica da rede de PC de 3G.

[0022] A Figura 14 é um diagrama de uma modalidade de como o PC de 3G no sistema de computação em nuvem permite que uma empresa de serviços gerenciados gere múltiplas redes de operador fora de um único centro de dados.

[0023] A Figura 15 é um diagrama de uma modalidade de um processo para emparelhamento e direcionamento diferencial de PC de 3G para tratamento de serviço especializado.

[0024] A Figura 16 é um diagrama de uma modalidade da modificação de tabela de fluxo de OpenFlow para direcionamento de TEID de GTP.

[0025] A Figura 17 é um diagrama da estrutura de uma fileira da tabela de fluxo.

[0026] As Figuras 18A a 18C são fluxogramas da criação, modificação e eliminação de sessão no PC de 3G.

[0027] A Figura 19 é um diagrama de uma modalidade de um fluxo de mensagem de OpenFlow para o procedimento de solicitação de criar sessão.

[0028] A Figura 20 é um diagrama de uma modalidade da sequência de mensagem de OpenFlow para o procedimento de solicitação de modificar sessão.

[0029] A Figura 21 é um diagrama de uma modalidade da sequência de mensagem de OpenFlow para o procedimento de solicitação de eliminar sessão.

[0030] A Figura 22A ilustra a conectividade entre dispositivos de rede (NDs) dentro de uma rede exemplificativa, assim como três implantações exemplificativas dos NDs, de acordo com algumas modalidades da invenção.

[0031] A Figura 22B ilustra um modo exemplificativo de implantar o dispositivo de rede de propósito especial 602 de acordo com algumas modalidades da invenção.

[0032] A Figura 22C ilustra diversos modos exemplificativos nos quais os elementos de rede virtuais (VNEs) podem ser acoplados de acordo com algumas modalidades da invenção.

[0033] A Figura 22D ilustra uma rede com um único elemento de rede (NE) em cada um dos NDs da Figura 22A, e dentro dessa abordagem direta contrasta com uma abordagem distribuída tradicional (normalmente usada por roteadores tradicionais) com uma abordagem centralizada para manter informações de alcance e encaminhamento (também denominadas controle de rede), de acordo com algumas modalidades da invenção.

[0034] A Figura 22E ilustra o caso simples de quando cada um dos NDs 2200A a 2200H implanta um único NE 2270A a 2270H (ver Figura 22D), mas o plano de controle centralizado 2276 abstraiu múltiplos dentre os NEs em diferentes NDs (os NEs 2270A a 2270C e 2270G a 2270H) em (para representar) um único NE 2270I em uma dentre a(s) rede(s) virtual (ou virtuais) 2292 da Figura 22D, de acordo com algumas modalidades da invenção.

[0035] A Figura 22F ilustra um case em que múltiplos VNEs (VNE 2270A.1 e VNE 2270H.1) estão implantadas em diferentes NDs (ND 2200A e ND 2200H) e estão acopladas uma à outra, e em que o plano de controle centralizado 2276 abstraiu esses múltiplos VNEs de modo que os mesmos aparecem como um único VNE 670T dentro de uma das redes virtuais 2292 da Figura 22D, de acordo com algumas modalidades da invenção.

[0036] A Figura 23 ilustra um dispositivo de plano de controle de propósito geral 2304 que inclui o hardware 2340 que compreende um conjunto de um ou mais processadores 2342 (que são frequentemente processadores de prateleira comercial (COTS)) e controlador(es) de interface de rede 2344 (NICs; também conhecidos como cartões de interface de rede) (que incluem NIs físicas 2346), assim como meios de armazenamento legíveis por máquina não transitórios 748 que têm armazenados em si o software de plano de controle (CCP) centralizado 2350), de acordo com algumas modalidades da invenção.

DESCRIÇÃO DAS MODALIDADES

[0037] A descrição a seguir descreve métodos e aparelho para computação de *. Na descrição a seguir, diversos detalhes específicos como implantações lógicas, opcodes, meios para especificar operandos, implantações de particionamento/compartilhamento/duplicação de recurso, tipos e interrelações de componentes de sistema, e escolhas de particionamento/integração de lógica são estabelecidas a fim de fornecer um entendimento mais abrangente da presente invenção. Será apreciado, entretanto, por uma pessoa versada na técnica que a invenção pode ser praticada sem tais detalhes específicos. Em outras ocorrências, estruturas de controle, circuitos de nível de porta de comunicação e sequências de instrução de software completas não foram mostradas em detalhes a fim de não obscurecer a invenção. As pessoas de habilidade comum na técnica, com as descrições incluídas, terão capacidade para implantar a funcionalidade apropriada sem a devida experimentação.

[0038] As referências no relatório descritivo a “uma (1) modalidade”, “uma modalidade”, “uma modalidade exemplificativa”, etc., indicam que a modalidade descrita pode incluir um recurso, estrutura ou característica específica, mas cada modalidade pode não incluir necessariamente o recurso, estrutura ou característica específico. Além do mais, tais frases não se referem necessariamente à mesma modalidade. Ademais, quando um recurso, estrutura ou característica específica for descrita em conexão com uma modalidade, sugere-se que esteja dentro do conhecimento de uma pessoa versada na técnica afetar tal recurso, estrutura ou característica em conexão com outras modalidades independentemente de serem ou não explicitamente descritas.

[0039] Os textos entre colchetes e blocos com bordas tracejadas (por exemplo, traços grandes, traços pequenos, pontilhado e ponto) podem ser usados no presente documento para ilustrar operações opcionais que adicionam recursos adicionais às modalidades da invenção. Entretanto, tal observação não deve ser tomada como significando que esses são apenas opções ou operações opcionais e/ou que blocos com bordas sólidas não são opcionais em certas modalidades da invenção.

[0040] Na descrição e reivindicações a seguir, os termos “acoplado” e “conectado”, junto com seus derivados, pode ser usado. Deve ser entendido que esses termos não são destinados a serem sinônimos entre si. “Acoplado” é usado para indicar que dois ou mais elementos, que podem estar ou não em contato físico direto ou em contato elétrico entre si, cooperar ou interagir entre si. “Conectado” é usado para indicar o estabelecimento de comunicação entre dois ou mais elementos que são acoplados entre si.

[0041] Um dispositivo eletrônico armazena e transmite (internamente e/ou com outros dispositivos eletrônicos por uma rede) código (que é composto por instruções de software e que é referido às vezes como código de programa de computador ou um programa de computador) e/ou meios legíveis por computador com o uso de dados (também denominados meios legíveis por computador), como meios de armazenamento legíveis por máquina (por exemplo, discos magnéticos, discos ópticos, memória de apenas leitura (ROM), dispositivos de memória flash, memória de mudança de fase) e meios de transmissão legíveis por máquina (também denominado um portador) (por exemplo, sinal elétrico, óptico, de rádio, acústico ou outra forma de sinais propagados - como ondas portadoras, sinais infravermelhos). Dessa forma, um dispositivo eletrônico (por exemplo, um computador) inclui hardware e software, como um conjunto de um ou mais processadores acoplados a um ou mais meios de armazenamento legíveis por máquina para armazenar código para execução no conjunto de processadores e/ou para armazenar dados. Por exemplo, um dispositivo eletrônico pode incluir memória não volátil que contém o código visto que a memória não volátil pode persistir em código/dados mesmo quando o dispositivo eletrônico estiver desligado (quando a potência for removida), e enquanto o dispositivo eletrônico estiver ligado, aquela parte do código que deve ser executada pelo(s) processador(es) daquele dispositivo eletrônico é copiado tipicamente da memória não volátil mais lenta na memória volátil (por exemplo, memória de acesso aleatório dinâmica (DRAM), memória de acesso aleatório estática (SRAM)) daquele dispositivo eletrônico. Os dispositivos eletrônicos típicos também incluem ou conjunto ou uma ou mais interface(s) de rede física(s) para estabelecer conexões de rede (para transmitir e/ou receber código e/ou dados com o uso de sinais de propagação) com outros dispositivos eletrônicos. Uma ou mais partes de uma modalidade da invenção podem ser implantadas com o uso de diferentes combinações de software, firmware e/ou hardware.

[0042] As operações nos diagramas de fluxo serão descritas com referência às modalidades exemplificativas das outras Figuras. Entretanto, deve ser entendido que as operações dos diagramas de fluxo podem ser realizadas por modalidades da invenção que não sejam aquelas discutidas com referência às outras Figuras, e as modalidades da invenção discutidas com referência a essas outras Figuras podem realizar operações diferentes daquelas discutidas com referência aos diagramas de fluxo.

[0043] As modalidades da presente invenção fornecem um método e um sistema para evitar as desvantagens da técnica anterior. As desvantagens da técnica anterior são aquelas implantações anteriores do núcleo de pacote de 3G que usam um pool de servidores que são dedicados a uma entidade de rede específica, como um pool de servidores que é dedicado à hospedagem de um SGSN. Quando demandas de sinalização adicionais exigem que uma capacidade extra, então, uma nova ocorrência de SGSN é mantida no pool de servidores. Entretanto, quando a demanda for alta para os serviços do servidor de assinante inicial (HSS), o pool de servidores dedicado aos servidores de HSS serão muito utilizados, mas o pool de servidores para o SGSN é subutilizado. Esses pools de servidores subutilizados continuam a precisar de uma manutenção e incorrer em gastos operacionais, mas que não fornecem desempenho ideal para o operador de rede.

[0044] Em algumas situações, as empresas de serviços gerenciados constroem e executam redes de operador móveis, enquanto o próprio operador móvel maneja com a propaganda, o faturamento e as relações com o cliente. A sinalização e o tráfego de dados para cada rede de operador móvel são mantidos privados e isolados do tráfego de seus competidores, mesmo que suas redes e as redes de seus competidores podem ser gerenciadas pela mesma empresa de serviços gerenciados. A empresa de serviços gerenciados deve permanecer um pool de servidores e uma rede de sinalização física completamente separadas para cada operador móvel que suporta. Como resultado, há uma grande duplicação de recursos e uma subutilização de capacidade de servidor. Isso aumenta os gastos operacionais para as empresas de serviços gerenciados e a rede de operador móvel devido ao equipamento adicional, potência e exigências de resfriamento.

[0045] A arquitetura do núcleo de pacote de 3G conforme definido atualmente permite apenas um ponto de presença (PoP) entre o núcleo fixo/Internet do operador móvel e a rede de agregação móvel, ou seja, há um único nó de suporte de GPRS de porta de comunicação (GGSN). Os operadores de rede móvel não conseguem configurar múltiplos pontos de emparelhamento e PoPs entre operadores vizinhos dentro da rede de agregação. Isso reduziria a quantidade de tráfego que segue para a rede principal do operador móvel, o que, desse modo, reduz a necessidade por atualizações de rede principal custosas e demoradas. Além disso, os pontos de emparelhamento normalmente não têm custos aos operadores contanto que os acordos de nível de serviço (SLAs) sejam observados. Entretanto, essa flexibilidade de instalação está indisponível a operadores móveis devido à necessidade de ancorar seu PoP com o núcleo/Internet em uma única porta de comunicação móvel.

[0046] A arquitetura de PC de 3G também contém pouca flexibilidade para tratamento especializado de fluxos de usuários. Embora a arquitetura, de fato, forneça suporte para estabelecer qualidade de serviço (QoS), outros tipos de gerenciamento de dados não estão disponíveis. Por exemplo, os serviços que envolvem middleboxes, como inspeção ou interação profunda e especializada de pacote com armazenamento em cache de dados locais e recursos de processamento que podem ser utilizados para transcodificação ou aplicativos de realidade aumentada é difícil de suportar com a arquitetura atual de PC de 3G. Quase todos os tais aplicativos necessitam que o pacote flua para sair através do GGSN, que, desse modo, fica fora do túnel a partir do GTP, e para ser processado dentro da rede com fio.

[0047] A implantação do plano de controle de um PC de 3G em uma instalação de computação em nuvem e o plano de dados do PC de 3G com o uso de um conjunto de comutadores de OpenFlow, assim como comunicação de gerenciamento entre o plano de controle e o plano de dados com o uso do protocolo de OpenFlow (por exemplo, OpenFlow 1.1), cria um problema de que o protocolo de OpenFlow não suporte GTP ou o direcionamento identificador do ponto de extremidade do túnel de GTP (TEID), que é necessário para implantar o plano de dados do PC de 3G.

[0048] As modalidades da invenção superam essas desvantagens da técnica anterior. As desvantagens da técnica anterior são evitadas dividindo-se o plano de controle e o plano de dados para a arquitetura de PC de 3G e para implantar o plano de controle instalando-se as entidades do plano de controle do PC de 3G em uma instalação de computação em nuvem, enquanto o plano de dados é implantado por uma coleção distribuída de comutadores de OpenFlow. O protocolo de OpenFlow é usado para conectar os dois, com melhorias ao suporte de direcionamento de GTP. Embora a arquitetura de PC de 3G já tenha uma divisão entre o plano de controle e o plano de dados, no sentido de que o SSGN e o GGSN sejam primariamente entidades de plano de dados enquanto o registro de localização inicial (HLR), o servidor de assinante inicial (HSS) e o centro de autenticação (AUC) são primariamente entidades do plano de controle, essa divisão foi feita no nível do protocolo de gerenciamento de mobilidade, GTP.

[0049] A arquitetura padrão de PC de 3G presume uma rede de IP direcionado padrão para o transporte no topo do qual as entidades e protocolos de rede móvel são implantadas. A arquitetura aprimorada de PC de 3G descrita no presente documento está, em vez disso, no nível de comutação de direcionamento de IP e controle de acesso de mídia (MAC). Em vez de usar o direcionamento de L2 e os protocolos de porta de comunicação internos de L3 para distribuir o direcionamento de IP e gerenciar Ethernet e o direcionamento de IP como um conjunto de entidades de controle distribuídas, o gerenciamento de direcionamento de L2 e L3 é centralizado em uma instalação em nuvem e o direcionamento é controlado a partir da instalação em nuvem com o uso do protocolo de OpenFlow. Conforme usado no presente documento, o “protocolo de OpenFlow” se refere ao protocolo de rede de OpenFlow e à especificação de comutação definida na Especificação de Comutação de OpenFlow em www.openflowswitch.org um site da web hospedado pela Universidade de Stanford. Conforme usado no presente documento, um “comutador de OpenFlow” se refere a um dispositivo de rede que implanta o protocolo de OpenFlow.

[0050] As entidades padrão de plano de controle do PC de 3G HSS, HLR, AUC, o registro de localização de visitante (VLR), o registro de identidade de equipamento (EIR), o centro de mensagem de interfuncionamento de serviço de classificação de mensagem (SMS-IWMSC), o centro de mensagem de porta de comunicação de SMS (SMS-GMSC) e a função de localização de assinante (SLF) e os aspectos de plano de controle do SGSN e do GGSN são instalados na nuvem. O plano de dados consiste em comutadores padrão de OpenFlow com melhorias conforme necessário para os pacotes de direcionamento GTP, ao invés de roteadores de IP e comutadores de Ethernet. No mínimo, as partes do plano de dados do SGSN e do GGSN e parte do direcionamento de pacote no NodeB no E-UTRAN necessitam de melhorias de OpenFlow para o direcionamento de GTP. As melhorias adicionais para p direcionamento de GTP podem ser necessárias em outros comutadores dentro da arquitetura de PC de 3G dependendo de quanto controle refinado sobre o direcionamento um operador precisa. As melhorias para o direcionamento de GTP incluem processos para estabelecer túneis de GTP, modificar túneis de GTP e destruir túneis de GTP dentro da arquitetura de PC de 3G.

[0051] A divisão entre o controle e as partes do plano de dados do PC de 3G pode ser usada junto com tecnologia de nuvem privada virtual (VPC) para implantar múltiplos PoPs dentro de um único PC de 3G, fornecer direcionamento específico de fluxo de GTP para aplicativos especializados, e executar múltiplas redes de operador a partir de uma única instalação de computação em nuvem.

[0052] Em uma modalidade, o sistema de PC de 3G com base em nuvem pode ser implantado como um conjunto de dispositivos de hardware. Em outra modalidade, os componentes de sistema são implantados em software (por exemplo, microcódigo, linguagem de montagem ou linguagens de nível mais alto). Essas implantações de software podem ser armazenadas em um meio legível por computador não transitório. Um meio "legível por computador" não transitório pode incluir qualquer meio que possa armazenar informações. Os exemplos do meio legível por computador não transitório incluem uma memória de apenas leitura (ROM), um disquete, um CD Rom, um DVD, uma memória flash, um disco rígido, um disco óptico ou meio similar.

REDES DE OPENFLOW 1.0

[0053] A Figura 1 é um diagrama de uma modalidade de uma rede exemplificativa com um comutador de OpenFlow, que se conforma ao especificação de OpenFlow 1.0. O protocolo de OpenFlow 1.0 permite que um controlador 101 se conecte a um comutador habilitado de OpenFlow 1.0 109 com o uso de um canal seguro 103 e controle uma única tabela de encaminhamento 107 no comutador 109. O controlador 101 é um componente de software externo executado por um dispositivo de computação remoto que permite que um usuário configure o comutador de OpenFlow 1.0 109. O canal seguro 103 pode ser fornecido por qualquer tipo de rede que inclua uma rede de área local (LAN) ou uma rede de área ampla (WAN), como a Internet.

[0054] A Figura 2 é um diagrama que ilustra uma modalidade do conteúdo de uma entrada da tabela de fluxo. A tabela de encaminhamento 107 é preenchida com entradas que consistem em uma regra 201 que definem correspondências para campos em cabeçalhos de pacote; uma ação 203 associada à correspondência de fluxo; e um conjunto de estatísticas 205 no fluxo. Quando um pacote de entrada for recebido, uma pesquisa por uma regra de correspondência é feita na tabela de fluxo 107. Se o pacote de entrada corresponder a uma regra particular, a ação associada definida naquela entrada da tabela de fluxo é realizada no pacote.

[0055] Uma regra 201 contém campos chave provenientes de diversos cabeçalhos na pilha de protocolos, por exemplo, endereços de origem e de destino de MAC de Ethernet, endereços de origem e de destino de IP, número de tipo de protocolo de IP, números de porta de TCP ou UDP de entrada e saída. Para definir um fluxo, todos os campos correspondentes disponíveis podem ser usados. Embora também seja possível restringir a regra de correspondência a um subconjunto dos campos disponíveis com o uso de curingas para os campos não procurados.

[0056] As ações que são definidas pela especificação de OpenFlow 1.0 são Liberar, que libera os pacotes correspondentes; Encaminhar, que encaminha o pacote para uma ou todas as portas de saída, a própria porta física de entrada, o controlador por meio do canal seguro, ou a pilha de rede local (se existir). As unidades de dados do protocolo de OpenFlow 1.0 (PDUs) são definidas com um conjunto de estruturas especificadas com o uso da linguagem de programação C. Algumas das mensagens mais usadas normalmente são: mensagem de relato de configuração de comutador; mensagens de modificação de estado (que inclui uma mensagem de modificação de entrada de fluxo e mensagem de modificação de porta); mensagem de leitura de estado, em que, enquanto o sistema estiver em execução, a trajetória de dados pode ser posta em espera sobre seu estado atual com o uso dessa mensagem; e a mensagem de envio de pacote, que é usada quando o controlador desejar enviar um pacote para fora através da trajetória de dados.

[0057] O OpenFlow 1.0 suporta “extensões de venda” que permitam que certos elementos de protocolo seja estendido. As mensagens de protocolo e as ações de tabla podem ser estendidos, mas as regras de correspondência de fluxo não podem. O uso dessas extensões em conexão com a arquitetura de EPC com base em nuvem é discutido adicionalmente abaixo no presente documento.

REDES DE OPENFLOW 1.1

[0058] A Figura 3 ilustra outra arquitetura exemplificativa que implanta OpenFlow, que se conforma à especificação de OpenFlow 1.1. Nessa modalidade, há uma provisão explícita para múltiplas tabelas de fluxo 301. Isso permite que o pipeline de processamento de pacote misture e corresponda regras particulares e ações sem causar uma explosão combinatória no tamanho de tabela. Por exemplo, uma tabela de fluxo pode realizar o processamento de QoS enquanto uma segunda tabela de fluxo realiza o direcionamento.

[0059] A Figura 4 ilustra uma modalidade do processamento de pacotes através de uma pipeline de processamento de pacote comutado de OpenFlow 1.1. Um pacote recebido é comparado a cada uma das tabelas de fluxo 401. Após cada correspondência de tabela de fluxo, as ações são acumuladas em um conjunto de ações. Se o processamento precisar de correspondência contra outra tabela de fluxo, as ações na regra correspondente incluem uma ação que direciona o processamento para a próxima tabela no pipeline. A ausência da inclusão de uma ação no conjunto para executar todas as ações acumuladas imediatamente, as ações são executadas na extremidade 403 do pipeline de processamento de pacote. Uma ação permite a gravação de dados a um registro de metadados, que é executada ao longo de uma pipeline de processamento de pacote como o cabeçalho de pacote.

[0060] A Figura 5 é um fluxograma de uma modalidade do processo de correspondência de regra de OpenFlow 1.1. O OpenFlow 1.1 contém suporte para etiquetamento de pacote. O OpenFlow 1.1 permite a correspondência com base em campos de cabeçalho e rótulos de comutação de rótulo com múltiplos protocolos (MPLS). Um rótulo de LAN virtual (VLAN) e um rótulo de MPLS pode ser correspondida por tabela. O processo de correspondência de regra é iniciado com a chegada de um pacote a ser processado (Bloco 501). A começar pela primeira tabela 0, uma pesquisa é realizada para determinar uma correspondência com o pacote recebido (Bloco 503). Se não houver correspondência nessa tabela, a uma dentre um conjunto de ações padrão é tomada (isto é, enviar o pacote para o controlador, liberar o pacote ou continuar para a próxima tabela) (Bloco 509). Se houver uma correspondência, então, uma atualização ao conjunto de ações é feita junto com contadores, pacote ou campos de conjunto de correspondências e metadados (Bloco 505). É feita uma verificação para determinar a próxima tabela ao processo, que pode ser a próxima tabela em sequência ou uma especificada por uma ação de uma regra de correspondência (Bloco 507). Uma vez que todas as tabelas tenham sido processadas, então o conjunto de ações resultante é executado (Bloco 511).

[0061] A Figura 6 é um diagrama dos campos, em que um processo de correspondência pode ser utilizado para identificar regras a serem aplicadas um pacote. As ações permitem a manipulação de pilhas de rótulos pela aplicação de push e ativação dos rótulos. Combinado com múltiplas tabelas, as pilhas de rótulos de VLAN ou de MPLS podem ser processadas correspondendo-se um rótulo por tabela.

[0062] A Figura 7 é um fluxograma de uma modalidade de um processo de análise de cabeçalho. O processo de análise corresponde a um cabeçalho de pacote inicializando-se um conjunto de campos de correspondência (Bloco 701) e verificando-se a presença de um conjunto de diferentes tipos de cabeçalho. O processo verifica uma etiqueta de VLAN (Bloco 703). Se a etiqueta de VLAN estiver presente, então, há uma série de etapas de processamento para a etiqueta de VLAN (Blocos 705 a 707). Se o comutador suportar MPLS (Bloco 709), então, existe uma série de etapas para detectar e processar as informações de cabeçalho de MPLS (Blocos 711 a 715). Se o comutador suportar o protocolo de resolução de endereço (ARP), então, há uma série de etapas para processar o cabeçalho de ARP (Blocos 719 e 721). Se o pacote tiver um cabeçalho de IP (Bloco 723), então existe uma série de etapas para processar o cabeçalho de IP (Blocos 725 a 733). Esse processo é realizado para cada pacote recebido.

[0063] Em uma modalidade, uma tabela de grupo pode ser suportada em conjunto com o protocolo de OpenFlow 1.1. As tabelas de OpenFlow 1.1 habilitam um método para permitir uma única correspondência de fluxo para disparar o encaminhamento em múltiplas portas. As entradas da tabela de grupo consistem em quatro campos: um identificador de grupo, que é um número inteiro não atribuído de 32 bits que identifica o grupo; um tipo de grupo que determina a semântica do grupo; contadores que mantêm as estatísticas no grupo; e uma lista de buckets de ações, que é uma lista ordenada de buckets de ação, em que cada bucket contém um conjunto de ações para executar junto com seus parâmetros.

[0064] Existem quatro tipos diferentes de grupos: Todos, que executam todas as ações na lista de buckets, isso é usado para encaminhamento de transmissão por broadcast ou por difusão seletiva; Selecionados, que executam um bucket por pacote, com base em um algoritmo determinado pelo comutador que está do lado de fora do protocolo de OpenFlow, isso é usado para implantar encaminhamento com múltiplas trajetórias; Indiretos, que executam o único bucket em todos os pacotes, isso permite que múltiplos fluxos ou grupos apontem um único conjunto de ações ao invés de ter as ações definidas em múltiplas entradas da tabela de encaminhamento; de Falha Rápida, que executam o primeiro bucket em tempo real, em que cada bucket está associado a uma porta que controla seu tempo real, isso permite que o comutador falhe em outra porta sem envolver o controlador.

[0065] O OpenFlow 1.1 pode ser usado para suportar portas virtuais. Uma porta virtual, conforme usado no presente documento, é um “bloco de ação” que realiza algum tipo de ação de processamento que não seja simplesmente o encaminhamento do pacote para fora em direção a uma conexão de rede como fazem as portas físicas. Os exemplos de algumas portas virtuais embutidas incluem: ALL, que encaminha a porta para fora de todas as portas exceto pela porta de entrada e quaisquer portas que estejam marcadas “Não Encaminhar”; CONTROLLER, que encapsula o pacote e envia o mesmo para o controlador; TABLE, que insere o pacote na pipeline de processamento de pacote submetendo- se o mesmo à primeira tabela de fluxo, essa ação só é válida no conjunto de ações de uma mensagem para fora do pacote; e IN_PORT, que envia o pacote para fora da porta de entrada. Em outras modalidades, também podem ser portas virtuais definidas comutadas.

ARQUITETURA DE PC DE 3G

[0066] A Figura 8 é um diagrama de uma modalidade de uma rede principal de pacote (PC) de 3G (3GPC). A rede de PC de 3G consiste em três domínios em interação: uma rede principal (CN) 801, uma rede de acesso de rádio (RAN) 803 e o Equipamento de Usuário (UE) 805. O equipamento de usuário 805 pode ser dispositivo de computação, telefones celulares e dispositivos similares. As redes de acesso de rádio 803 pode ser qualquer quantidade ou combinação de redes que inclua o sistema de telecomunicações móveis universal (UMTS) 841 ou redes de sistemas globais para comunicações móveis (GSM) 843. Essas redes podem fazer interface com a rede principal 801 através de um centro de rede de rádio (RNC) 831 ou uma unidade de controle de pacote (PCU) 833.

[0067] A função principal da rede principal 801 é fornecer comutação, direcionamento e trânsito para o tráfego de usuário a partir do equipamento de usuário 805. A rede principal 801 também contém bases de dados e funções de gerenciamento de rede. Este é a rede principal de pacote comum para GSM/GPRS, múltiplo acesso de divisão de código de banda larga (WCDMA)/ acesso de pacote de alta velocidade (HSPA) e redes móveis que não sejam 3GPP. A rede principal 801 é usada para transmitir pacotes de Protocolo de Internet (IP). A rede principal 801 faz interface com a Internet 851 e outras redes 853 através do GGSN 819.

[0068] A rede principal 801 é dividida nos domínios de circuito comutado e de pacote comutado. Os elementos de circuito comutado incluem um centro de comutação de serviços móveis (MSC) 811, o registro de localização de visitante (VLR) 813 e o MSC de Porta de comunicação 815. Os elementos comutados de pacote são os SGSNs 817 e o GGSN 819. Outros dispositivos de rede, como EIR 821, HLR 823, VLR 813 e AUC 825 são compartilhados por ambos os domínios.

[0069] A arquitetura da rede principal 801 pode mudar quando novos serviços e recursos forem introduzidos. Em outras modalidades, uma base de dados de portabilidade numérica (NPDB) pode ser usada para permitir que um usuário mude as redes enquanto mantém um número de telefone antigo. Um registro de localização de porta de comunicação (GLR) pode ser usado para otimizar o manuseio do assinante entre os limites de rede.

[0070] As funções primárias da rede principal 801 em relação à rede sem fio móvel são o gerenciamento de mobilidade e a QoS. Essas funções não são fornecidas tipicamente em uma rede de banda larga fixa, mas as mesmas são cruciais para redes sem fio. O gerenciamento de mobilidade é necessário para garantir conectividade de rede de pacote quando um terminal sem fio se mover de uma estação-base para outra. A QoS é necessária porque, ao contrário de redes fixas, o enlace sem fio é severamente restringindo em quanta largura de banda o mesmo pode fornecer ao terminal, então a largura de banda precisa ser gerenciada de modo mais rígido que em redes fixas a fim de fornecer a qualidade de serviço adequada ao usuário.

[0071] A sinalização para implantar as funções de gerenciamento de mobilidade e de QoS é fornecida pelo Protocolo de Túnel de GPRS (GTP). O GTP tem dois componentes: GTP-C - um protocolo de plano de controle que suporta o estabelecimento de túneis para o gerenciamento de mobilidade e portadores para o gerenciamento de QoS que corresponde ao tráfego de retorno com fio e à QoS de núcleo de pacote para a QoS de enlace de rádio; e GTP-U - um protocolo de plano de dados usado para implantar túneis entre dispositivos de rede que atuam como roteadores. Existem duas versões de protocolo de GTP-C, isto é, versão 1 de GTP (GTPv1-C e GTPv1-U) e versão 2-C de GTP (atribuído à LTE). O GTPv1 é utilizado primariamente em conjunto com o sistema com base em PC de 3G.

[0072] Os Serviços de Rede são considerados como sendo de ponto-a-ponta, isso significa, de um Equipamento de Terminal (TE) a outro TE. Um Serviço de Ponto-a-Ponta pode ter certa Qualidade de Serviço (QoS) que é fornecida para o usuário de um serviço de rede. É o usuário que decide se está satisfeito com a QoS fornecida ou não. Para realizar certa QoS de rede, o serviço com características e funcionalidade claramente definidas deve ser configurado da fonte até o destino de um serviço.

[0073] Além disso, para os parâmetros de QoS, cada portador tem um túnel de GTP associado. Um túnel de GTP consiste no endereço de IP dos nós de ponto de extremidade do túnel (estação-base de rádio, SGSN e GGSN), uma porta de UDP de fonte e de destino, e um Identificador de Ponto de Extremidade do Túnel (TEID). Os túneis de GTP são monodirecionais, para que cada portador esteja associado a dois TEIDs, um para o túnel de enlace ascendente e um para o túnel de enlace descendente. Um conjunto de túneis de GTP (enlace ascendente e enlace descendente) se estende entre a estação-base de rádio e o SGSN e um conjunto se estende entre o SGSN e o GGSN. O número da porta de destino de UDP para o GTP-U é 2152 enquanto o número da porta de destino para GTP-C é 2123. O número da porta de origem é alocado de modo dinâmico pelo nó de envio. A Figura 9 é um diagrama de uma modalidade dos campos de cabeçalho no cabeçalho de encapsulamento de GTP-U primário.

COMPUTAÇÃO EM NUVEM

[0074] Os centros de dados oferecem recursos de computação, armazenamento e comunicação de rede a usuários externos. Os serviços oferecidos podem consistir em processamento elástico sob demanda, armazenamento que para maioria dos propósitos práticos está limitado apenas pela capacidade do cliente de pagar, e largura de banda de rede na Internet. Esse conjunto de serviços fornecido por um centro de dados é referido no presente documento como computação em nuvem.

[0075] A tecnologia de visualização de servidor permite que um pool de servidores seja gerenciado essencialmente como um grande recurso de computação. Uma camada de software denominada hipervisor fica entre o sistema operacional e o hardware. O hipervisor programa a execução de máquinas virtuais (VMs). Uma VM é uma imagem de sistema operacional empacotada com alguns aplicativos. O hipervisor permite que uma VM seja suspendida e movida entre os servidores para carregar o balanço. O balanceamento e o monitoramento de carga da execução de VM para detectar panes fornece o mesmo tipo de tolerância a falhas e serviços de escalabilidade para aplicativos empresariais que são alcançados a custo muito mais alto com soluções especializadas. Um sistema de gerenciamento em nuvem fiscaliza a execução as VMs, a programação da execução para cumprir a demanda das VMs e a otimização da utilização de servidor e a minimização do consumo de potência. O gerente em nuvem ou sistema operacional em nuvem é um programa de software que pode programar a execução para permitir que uma atualização em serviço de hardware e software sem impactar o serviço em andamento, provendo às VMs e seus aplicativos no sistema de computação em nuvem.

[0076] Para suportar o movimento arbitrário das VMs entre máquinas, a rede dentro do centro de dados também deve ser virtualizada. Os sistemas de computação em nuvem podem virtualizar a rede incorporando-se um comutador virtual no hipervisor. O comutador virtual fornece portas de rede virtual às VMs em execução sob o controle do hipervisor. O software de comutador virtual também permite que os recursos de rede sejam virtualizados de modo similar como os recursos de servidor são virtualizados pelo hipervisor. O hipervisor e o comutador virtual podem, dessa forma, cooperar para permitir que as VMs sejam movidas entre servidores. Quando o hipervisor move uma VM, o mesmo se comunica com o comutador virtual a respeito da nova localização, e o comutador virtual garante que as tabelas de direcionamento de rede para os endereços de VM (endereços de MAC de L2, também em potencial os endereços de IP) sejam atualizados para que os pacotes sejam roteados para a nova localização.

[0077] Um sistema de computação em nuvem pode ser composto por qualquer quantidade de dispositivos de computação que tenham qualquer faixa de capacidades (por exemplo, capacidade de processamento ou capacidade de armazenamento). O sistema de computação em nuvem pode ser um sistema público ou privado. Os dispositivos de computação podem estar em comunicação um com o outro ao longo de qualquer sistema ou rede de comunicação. Um sistema de computação em nuvem pode suportar uma única nuvem ou serviço ou qualquer quantidade de nuvens ou serviços discretos. Os serviços, aplicativos e programas similares podem ser virtualizados ou executados como código padrão. Em uma modalidade, os sistemas de computação em nuvem podem suportar aplicativos de serviços da web. Os aplicativos de serviços da web consistem em uma extremidade frontal de balanceamento de carga que despacha solicitações para um pool de servidores da Web. As solicitações se originam de aplicativos em máquinas remotas na Internet e, portanto, os requerimentos de segurança e privacidade são muito mais amplos para aplicativos em uma rede corporativa privada.

[0078] Os sistemas de computador em nuvem também podem suportar propriedade múltipla segura, na qual o fornecedor do sistema de computador em nuvem oferece conexões similares a uma rede privada virtual (VPN) entre as redes de escritório distribuídas dos clientes fora da nuvem e um VPN dentro do sistema de computação em nuvem. Isso permite que os aplicativos dos clientes dentro do sistema de computação em nuvem operem em um ambiente de rede que relembra uma WAN corporativa. Para centros de dados privados, nos quais os serviços são oferecidos apenas a clientes dentro da corporação que detém o centro de dados, os requerimentos de segurança e privacidade para propriedade múltipla são ampliados. Entretanto, para centros de dados públicos, o operador em nuvem deve garantir que o tráfego proveniente de múltiplos detentores está isolado e que não haja possibilidade do tráfego proveniente de um cliente alcançar outra rede de cliente.

[0079] A Figura 10 é um diagrama de uma modalidade de um sistema de computação em nuvem que presta serviços a um conjunto de clientes. Um ‘conjunto’, conforme usado no presente documento, se refere a qualquer número inteiro positivo de itens. Na modalidade mostrada na Figura 10, duas nuvens privadas virtuais (VPCs) são configuradas para dois clientes empresariais externos diferentes. Uma VPC consiste em um conjunto de VMs, armazenamento e recursos de rede que fornecem propriedade múltipla segura às empresas que alugam espaço na nuvem. Os clientes da empresa se conectam às VPCs por meio de VPNs pela Internet em execução em uma rede de operador pública.

[0080] A Figura 11 é um diagrama de outra modalidade de um sistema de computação em nuvem que mostra o processo de adição de uma nova ocorrência de serviço a um VPC de cliente. Nesse caso, a VPN em nuvem é implantada com o uso de LANs Virtuais (VLANs) de camada de MAC. A VM é criada em um servidor gerenciado por hipervisor dentro da VPC para a empresa que solicita a nova ocorrência de serviço (etapa 1). A VLAN de comutador virtual é configurada para incluir a nova VM na VPN em nuvem empresarial, o que, desse modo, estabelece conectividade de serviço dentro da nuvem (etapa 2). O roteador de borda de cliente (CE) virtual é atualizado para o novo serviço (etapa 3). O roteador de borda de fornecedor na rede de operador em que a VPN empresarial é executada é atualizada com o novo serviço (etapa 4).

IMPLANTAÇÃO DE PC DE 3G EM SISTEMA DE COMPUTAÇÃO EM NUVEM

[0081] A Figura 12 é um diagrama de uma modalidade do EPC implantado no sistema de computação em nuvem. As entidades do plano de controle do PC de 3G (AUC, HLR, HSS) 1207 e as partes do plano de controle dos nós de suporte (SGSN, GGSN) 1207, isto é, as partes que manejam a sinalização de GTP, são implantadas no sistema de computação em nuvem 1201 como parte do controlador de OpenFlow 1205. As entidades do plano de controle 1207 e o controlador de OpenFlow 1205 são embalados como VMs. A interface de programação do aplicativo (API) entre o controlador de OpenFlow 1205 e as entidades do plano de controle 1207 podem ser uma interface de chamada de procedimento remoto (RPC) ou uma interface similar. Essa tecnologia de implantação é favorável para o gerenciamento escalável das entidades do plano de controle dentro da nuvem, visto que permite que a execução das entidades do plano de controle 1207 e do controlador 1205 sejam gerenciadas separadamente de acordo com a demanda. O gerenciador em nuvem 1203 pode ser uma VM ou um aplicativo executado dentro do sistema de computação em nuvem 1201.

[0082] O gerenciador em nuvem 1203 monitora a utilização da unidade de processador central (CPU) das entidades do plano de controle do PC de 3G 1207 e do tráfego do plano de controle entre as entidades do plano de controle do PC de 3G 1207 dentro da nuvem. O mesmo também monitora o tráfego do plano de controle entre os dispositivos de usuário final (UEs) 1225 e os NodeBs 1217, que não têm entidades do plano de controle no sistema de computação em nuvem 1201, e as entidades do plano de controle do PC de 3G 1207. Se as entidades do plano de controle do PC de 3G 1207 começarem a exibir sinais de sobrecarga, como a utilização de tempo de CPU demais, ou o que o enfileiramento de tráfego demais seja processado, a entidade sobrecarregada do plano de controle 1207 solicita que o gerenciador em nuvem 1203 inicie uma nova VM para manejar a carga. Adicionalmente, as próprias entidades do plano de controle do PC de 3G 1207 podem emitir notificações de evento ao gerenciador em nuvem 1203 se as mesmas detectarem internamente que começam a passar por sobrecarga.

[0083] O gerenciador em nuvem 1203 também fornece confiabilidade e falha reiniciando-se uma VM para uma entidade ou função particular do plano de controle 1207 se qualquer uma das entidades do plano de controle do PC de 3G 1207 entrar em pane. Durante esse processo de reinicio, o gerenciador em nuvem pode coletar dados de diagnóstico, guardar quaisquer arquivos principais da entidade falhada do plano de controle do PC de 3G, e informar aos administradores de sistema que uma falha ocorreu. As entidades do plano de controle 1207 mantêm a mesma interface de protocolo entre si mesmas como na arquitetura de PC de 3G de 3GPP mostrada na Figura 8.

[0084] O plano de controle de OpenFlow 1221, mostrado no presente contexto como uma linha pontilhada, gerencia a configuração de direcionamento e comutação na rede. O plano de controle de OpenFlow 1221 conecta o sistema de computação em nuvem 1203 aos SGSN-Ds 1215 (isto é, o plano de dados do SGSN), aos comutadores padrão de OpenFlow 1213 e ao GGSN-D 1211 (isto é, o plano de dados do GGSN). A implantação física do plano de controle de OpenFlow 1221 pode ser como uma rede física completamente separada, ou pode ser uma rede virtual em execução pela mesma rede física que o plano de dados, implantada com uma VLAN priorizada ou com uma trajetória comutada do rótulo de MPLS ou mesmo com um encapsulamento de direcionamento genérico (GRE) ou outro túnel de IP. O plano de controle de OpenFlow 1221 pode, em princípio, usar as mesmas trajetórias físicas do plano de controle que o GTP-C e outra sinalização de rede móvel. Os SGSN-Ds 1215 e os GGSN-Ds 1211 atuam como portas de comunicação estendidas por GTP de OpenFlow, pacotes de encapsulamento e desencapsulamento com o uso das extensões de comutador do GTP de OpenFlow descritas adicionalmente abaixo no presente documento.

[0085] Os NodeBs 1217 não têm entidades do plano de controle na nuvem devido ao fato de que a sinalização da rede de acesso de rádio (RAN) necessária entre o PC de 3G e o NodeB inclui parâmetros de rádio, e não apenas os parâmetros do direcionamento de IP. Portanto, não há a conexão do plano de controle de OpenFlow 1221 entre o controlador de OpenFlow 1205 no sistema de computação em nuvem 1201 e os NodeBs 1217. Os NodeBs 1217 podem atuar, entretanto, como portas de comunicação estendidas por GTP de OpenFlow implantando-se um controle local à conexão do plano de dados com o uso de OpenFlow. Isso permite que o pacote comute o lado dos NodeBs 1217 para utilizar as mesmas extensões de comutação do GTP de OpenFlow como as portas de comunicação de pacote.

[0086] A operação do sistema de computador em nuvem de PC de 3G funciona conforme a seguir. O UE 1225, o NodeB 1217, o SGSN 1207 e o sinal de GGSN 1207 para o HLR, o HSS, o AUC, o SMS-GMSC 1207 com o uso dos protocolos padrão do PC de 3G, para estabelecer, modificar e eliminar os túneis de GTP. A sinalização dispara chamadas de procedimento com o controlador de OpenFlow para modificar o direcionamento no PC de 3G conforme solicitado. O controlador de OpenFlow configura os comutadores padrão de OpenFlow, o SGSN de OpenFlow 1215 e o GGSN 1211 com regras de fluxo e ações para habilitar o direcionamento solicitado pelas entidades do plano de controle. Os detalhes dessa configuração são descritos em detalhes adicionais abaixo no presente documento.

[0087] A Figura 13 é um fluxograma de uma modalidade da operação básica de PC de 3G. Em uma modalidade, o processo começa com a inicialização dos módulos do plano de controle do PC de 3G dentro do controlador de OpenFlow no sistema de computação em nuvem (Bloco 13401). Cada módulo do plano de controle na pluralidade de módulos do plano de controle é inicializado como uma VM separada pelo gerenciador em nuvem. O gerenciador em nuvem, então, monitora a utilização de recurso de cada módulo do plano de controle assim como a quantidade e o tipo de tráfego do plano de controle manejado por cada módulo do plano de controle (Bloco 1303). O gerenciador em nuvem pode monitorar diretamente esses dados, receber relatórios dos módulos do plano de controle ou qualquer combinação dos mesmos.

[0088] Se o gerenciador em nuvem detectar um nível limiar de utilização de recurso ou carga de tráfego para qualquer um dentre a pluralidade de módulos do plano de controle que é monitorado (Bloco 1305), o gerenciador em nuvem pode tomar etapas para responder automaticamente a esse cenário. O gerenciador em nuvem pode inicializar um novo módulo do plano de controle ou uma ocorrência de tal módulo do plano de controle como uma máquina virtual separada (Bloco 1307). Esse novo módulo do plano de controle ou ocorrência pode, então, compartilhar a carga de módulos existentes do plano de controle ou ocorrências do mesmo tipo, o que, desse modo, alivia a carga nesses módulos de modo dinâmico.

[0089] De modo similar, o gerenciador em nuvem pode detectar a falha ou a subutilização de um dentre a pluralidade de módulos do plano de controle (Bloco 1309). O gerenciador em nuvem pode, então, reiniciar um módulo falhado do plano de controle ou encerrar um módulo subutilizado do plano de controle (Bloco 1311). Reiniciar o módulo do plano de controle garante um nível de compartilhamento de carga para um pool de módulos do plano de controle. Desativar um módulo do plano de controle libera os recursos e reduz a projeção criada pelo módulo do plano de controle. O gerenciador em nuvem pode realizar essas funções ao longo das VPCs e operadores móveis com o uso dos recursos do sistema de computação em nuvem, o que, desse modo, maximiza o uso de recursos disponíveis e reduz o custo de operação enquanto mantém a separação estrita de dados e tráfego entre os operadores móveis.

[0090] A Figura 14 é um diagrama de uma modalidade de como o PC de 3G no sistema de computação em nuvem permite que uma empresa de serviços gerenciados gere múltiplas redes de operador fora de um único centro de dados. A instalação de computação em nuvem dos serviços gerenciados 1401 executa ocorrências separadas do plano de controle do PC de 3G para cada operador móvel com o qual a empresa de serviços gerenciados tem um contato. Cada ocorrência de PC de 3G está em uma VPC 1403A, 1403B que isola o tráfego do operador móvel proveniente de outros proprietários na instalação de computação em nuvem 1401 do centro de dados. O plano de controle da ocorrência de PC de 3G para um operador móvel está conectado à malha de comutação do plano de dados de OpenFlow do PC de 3G distribuído geograficamente do operador móvel 1407A, 1407B e as estações-base do operador móvel através de um roteador de borda virtual 1409A, 1409B. O roteador de borda virtual 1409A, 1409B direciona o tráfego proveniente centro de dados para e a partir da malha de comutação do plano de dados do PC de 3G do operador móvel 1407A, 1407B apropriado. Em alguns casos, os operadores móveis podem, até mesmo, compartilhar malhas de comutação de estações-base e de PC de 3G, embora a modalidade exemplificativa na Figura 14 mostre um caso no qual dois operadores móveis têm malhas de comutação separados.

EMPARELHAMENTO DE PC DE 3G E ROTEAMENTO DIFRENCIAL EM UM SISTEMA DE COMPUTAÇÃO EM NUVEM

[0091] A Figura 15 é um diagrama de uma modalidade de um processo para emparelhamento e direcionamento diferencial de PC de 3G para tratamento de serviço especializado. A sinalização de OpenFlow, indicada pelas linhas e setas sólidas 1501, configura regras de fluxo e ações nos comutadores e portas de comunicação dentro do PC de 3G para direcionamento diferencial. Essas regras de fluxo direcionam fluxos de GTP a localizações particulares. Nesse exemplo, o operador, nesse caso, emparelha seu PC de 3G com dois outros operadores fixos. O direcionamento através de cada ponto de emparelhamento é manejado pelos respectivos GGSN1 e GGSN2 1503A, 1503B. As linhas e setas tracejadas 1505 mostram o tráfego proveniente de um UE 1507 que precisa ser direcionado a outro operador de emparelhamento. As regras de fluxo e as ações para distinguir qual ponto de emparelhamento o tráfego deve atravessar são instaladas nos comutadores de OpenFlow 1509 e portas de comunicação 1503A, 1503B pelo controlador de OpenFlow 1511. O controlador de OpenFlow 1511 calcula essas regras de fluxo e ações com base nas tabelas de direcionamento que mantém para o tráfego externo, e a origem e destinação dos pacotes, assim como por qualquer tratamento de encaminhamento especializado necessário para os pacotes marcados de DSCP.

[0092] As linhas e setas pontilhadas e de traços longos 1515 mostram um exemplo de um UE 1517 que obtém conteúdo de uma fonte externa. O conteúdo não é formulado originalmente para a tela do UE 1517, então o controlador de OpenFlow 1511 instalou as regras de fluxo e ações no GGSN1 1503B, SGSN 1519 e nos comutadores de OpenFlow 1509 para direcionar o fluxo através de um aplicativo de transcodificação 1521 na instalação de computação em nuvem. O aplicativo de transcodificação 1521 reformata o conteúdo para que o mesmo se ajuste à tela do UE 1517. Um MSC solicita o tratamento especializado no momento em que o UE configura sua sessão com a fonte de conteúdo externo por meio do Subsistema de Multimídia de IP (IMS) ou outro protocolo de sinalização.

ROTEAMENTO DE TEID DE GTP

[0093] Em uma modalidade, o OpenFlow é modificado para fornecer regras para Roteamento de TEID de GTP. A Figura 16 é um diagrama de uma modalidade da modificação de tabela de fluxo de OpenFlow para direcionamento de TEID de GTP. Um comutador de OpenFlow que suporta correspondências de direcionamento de TEID no conjunto de campos de cabeçalho de 2 bytes (16 bits) e no TEID de GTP de 4 bytes (32 bits), além de outros campos de cabeçalho de OpenFlow, em pelo menos uma tabela de fluxo (por exemplo, a primeira tabela de fluxo). O sinalizador de TEID de GTP pode ter curingas (isto é, correspondências são “não é importante”). Em uma modalidade, os protocolos de PC de 3G não atribuem qualquer significado aos TEIDs que não estejam como um identificador de ponto de extremidade para túneis, como portas nos protocolos padrão de transporte de UDP/TCP. Em outras modalidades, os TEIDs podem ter um significado ou semântica correlatos. O campo dos sinalizadores de cabeçalho de GTP também podem ter curingas, isso pode ser parcialmente cumprido combinando-se as seguintes máscaras de bits: OxFFOO - Corresponder o campo Tipo de Mensagem; 0xe0 - Corresponder o campo Versão; 0x10 - Corresponder o campo PT; 0x04 - Corresponder o campo E; 0x02 - Corresponder o campo S; e 0x01 -Corresponder o campo PN.

[0094] Em uma modalidade, o OpenFlow pode ser modificado para suportar portas virtuais para encapsulamento e desencapsulamento rápido de TEID de GTP de trajetória. Uma porta de comunicação móvel de OpenFlow pode ser usada para suportar encapsulamento e desencapsulamento de GTP com portas virtuais. As portas virtuais de encapsulamento e desencapsulamento de GTP podem ser usadas para o encapsulamento e desencapsulamento rápido dos pacotes de dados de usuário dentro de túneis de GTP-U, e podem ser projetadas simplesmente o bastante para que possam ser implantadas em hardware ou firmware. Por esse motivo, as portas virtuais de GTP podem ter as seguintes restrições no tráfego com o qual as mesmas manejam: campo Tipo de Protocolo (PT) = 1, em que portas de encapsulamento de GTP só suportam GTP, não GTP’ (campo PT = 0); sinalizador de Cabeçalho de Extensão (E) = 0, em que nenhum cabeçalho de extensão é suportado, sinalizador de Número de Sequência (S) = 0, em que nenhum número de sequência é suportado; sinalizador de N-PDU (PN) = 0; e tipo de Mensagem = 255, em que mensagem Apenas G-PDU, isto é, dados de usuário de túnel, são suportados na trajetória rápida.

[0095] Se um pacote tanto precisar de encapsulamento quanto já estiver encapsulado com sinalizadores de cabeçalho diferentes de zero, extensões de cabeçalho e/ou o pacote de GTP-U não for um pacote de G-PDU (isto é, for um pacote de controle de GTP-U), o processamento deve prosseguir por meio do plano de controle da trajetória lenta da porta de comunicação (software). Os pacotes de GTP-C e GTP’ direcionados para os endereços de IP da porta de comunicação são resultado de configuração errada e estão em erro. Os mesmos devem ser enviados para o controlador de OpenFlow, visto que esses pacotes são manejados pelas entidades do plano de controle do SGSN e do GGSN no sistema de computação em nuvem ou para a entidade de faturamento que maneja o GTP’ e não os comutadores dos planos de dados do SGSN e do GGSN.

[0096] As portas virtuais de GTP são configuradas a partir do controlador de OpenFlow com o uso de um protocolo de configuração. Os detalhes do protocolo de configuração são dependentes do comutador. O protocolo de configuração deve suportar mensagens que realizam as seguintes funções: permitir que o controlador enfileire e devolva uma indicação de se o comutador suporta portas virtuais da trajetória rápida de GTP e quais números de porta virtual são usados para processamento de GTP-U de trajetória rápida e de trajetória lenta; e permitir que o controlador inicie uma porta virtual de trajetória rápida de GTP-U dentro de uma trajetória de dados do comutador para uso na ação de definir para fora da porta na tabela de OpenFlow. O comando de configuração deve ser executado em uma transação para que, quando os resultados da ação forem relatados de volta para o controlador, tanto uma porta virtual de trajetória rápida de GTP-U para a trajetória solicitada de dados ocorreu quanto um erro voltou indicando porque a solicitação não pode ser cumprida. O comando também permite que o controlador de OpenFlow associe uma porta virtual de GTP-U a uma porta física. Para portas virtuais de desencapsulamento, a porta física é uma porta de entrada. Para portas virtuais de encapsulamento, a porta física é uma porta de saída.

[0097] O controlador de OpenFlow cria uma instância de uma porta virtual para cada porta física que possa transmitir ou receber pacotes direcionados através de um túnel de GTP, antes de instalar quaisquer regras no comutador para o direcionamento de TEID de GTP.

[0098] Em uma modalidade, uma porta de comunicação de GTP de OpenFlow mantém uma tabela de hash que mapeia TEIDs de GTP nos campos de cabeçalho de túnel para seus portadores. A Figura 17 é um diagrama da estrutura de uma fileira da tabela de fluxo. As chaves de hash de TEID são calculadas com o uso de um algoritmo de hash adequado com baixa frequência de colisão, por exemplo SHA- 1. A porta de comunicação mantém tal fileira da tabela de fluxo para cada TEID de GTP/portador. O campo TEID contém o TEID de GTP para o túnel. Os campos de etiquetas de VLAN e de rótulos de MPLS contêm uma lista ordenada de etiquetas de VLAN e/ou rótulos de MPLS que definem túneis nos quais o pacote precisa ser direcionado. Os bits de prioridade de VLAN e os bits de classe de tráfego de MPLS estão incluídos nos rótulos. Tais túneis podem ou não ser necessários. Se os mesmos não forem necessários, então, esses campos estão vazios. O endereço de IP de fonte de origem de túnel contém o endereço na porta de comunicação de encapsulamento à qual qualquer tráfego de controle que envolve o túnel deve ser direcionado (por exemplo, indicações de erro). O campo de endereço de IP de destino de extremidade de túnel contém o endereço de IP da porta de comunicação à qual o pacote de túnel deve ser direcionado, no qual o pacote será desencapsulado e removido do túnel de GTP. O campo DSCP de QoS contém o Ponto de Código DiffServe, se houver, para o portador no caso de um portador dedicado. Esse campo pode estar vazio se o portador for um portador padrão com a QoS de melhor esforço, mas irá conter valores diferentes de zero se a QoS de portador for mais que o melhor esforço.

[0099] Em uma modalidade, o suporte de trajetória lenta para GTP é implantado com um comutador de porta de comunicação de OpenFlow. Um comutador de porta de comunicação móvel de OpenFlow também contém suporte no plano de controle de software para o processamento de pacote de trajetória lenta. Essa trajetória é tomada pelos pacotes de G-PDU (tipo de mensagem 255) com campos de cabeçalho ou cabeçalhos de extensão diferentes de zero, e pacotes de plano de dados de usuário que necessitam de encapsulamento com tais campos ou adição de cabeçalhos de extensão, e por pacotes de controle de GTP-U. Para esse propósito, o comutador suporta três portas locais no plano de controle de software: LOCAL_GTP_CONTROL - a trajetória rápida de comutador encaminha pacotes encapsulados de GTP direcionados para o endereço de IP de porta de comunicação que contém mensagens de controle de GTP-U e o plano de controle de software de comutador local inicia local as ações do plano de controle dependendo da mensagem de controle de GTP-U; LOCAL_GTP_U_DECAP - a trajetória rápida de comutador encaminha pacotes de G-PDU para essa porta, que tem campos de cabeçalho ou cabeçalhos de extensão diferentes de (isto é, E != 0, S != 0 ou PN != 0). Esses pacotes necessitam de manuseio especializado. A trajetória lenta do software de comutador local processa os pacotes e realiza o manuseio especializado; e LOCAL_GTP_U_ENCAP - a trajetória rápida de comutador encaminha pacotes de plano de dados de usuário para essa porta que necessita de encapsulamento em um túnel de GTP com campos de cabeçalho ou cabeçalhos de extensão diferentes de zero (isto é, E != 0, S != 0 ou PN != 0). Esses pacotes necessitam de manuseio especializado. A trajetória lenta do software de comutador local encapsula os pacotes e realiza o manuseio especializado. Além disso para encaminhar o pacote, a trajetória rápida de comutador torna o campo de metadados de OpenFlow disponível ao software de trajetória lenta.

[00100] Para suportar o encapsulamento de trajetória lenta, o plano de controle de software no comutador mantém uma tabela de hash com chaves calculadas a partir do TEID de GTP-U. As chaves de hash de TEID são calculadas com o uso de um algoritmo de hash adequado com baixa frequência de colisão, por exemplo SHA-1. As entradas da tabela de fluxo contêm um registro de como o cabeçalho de pacote, que inclui o cabeçalho de encapsulamento de GTP, deve ser configurado. Isso inclui: os mesmos campos de cabeçalho que para a tabela de encapsulamento de hardware ou firmware na Figura 18; valores para os sinalizadores de cabeçalhos de GTP (PT, E, S e PN); o número de sequência e/ou o número de N-PDU, se houver; se o sinalizador E for 1, então, a tabela de fluxo contém uma lista dos cabeçalhos de extensão, que inclui seus tipos, cuja trajetória lenta deve inserir no cabeçalho de GTP.

[00101] Em uma modalidade, o sistema implanta uma porta virtual de encapsulamento da trajetória rápida de GTP. Quando solicitado pelo software de plano de controle do SGSN e do GGSN em execução no sistema de computação em nuvem, o controlador de OpenFlow programa o comutador de porta de comunicação para instalar regras, ações e as entradas da tabela de hash de TEID para pacotes de direcionamento em túneis de GTP por meio de uma porta virtual de encapsulamento do GTP de trajetória rápida. As regras correspondem ao filtro de pacote para o lado de entrada do portador do túnel de GTP. Isso será tipicamente quádruplos de: endereço de origem do IP; endereço de destino do IP; porta de origem de UDP/TCP/SCTP; e porta de destino de UDP/TCP/SCTP. O endereço de origem e o endereço de destino do IP são tipicamente os endereços para o plano de tráfego de dados do usuário, isto é, um UE ou serviço de Internet com o qual um UE realiza transação, e, de modo similar, com os números de porta. Para um lado de entrada do túnel de GTP-U de correspondência de regra, as instruções associadas são as seguintes: Gravar Metadados (GTP-TEID,0xFFFFFFFF) Aplicar Ações (Definir Porta de Saída GTP-Encap-VP)

[00102] O comutador também grava uma entrada na tabela de hash de TEID que contém os campos de cabeçalho de túnel para o pacote. O GTP-TEID é o identificador do ponto de extremidade do túnel de GTP. O GTP-Enacap-VP é a ligação da porta virtual de encapsulamento da trajetória rápida de GTP à porta física fora da qual o pacote encapsulado será finalmente direcionado.

[00103] Quando um cabeçalho de pacote cumpre uma regra associada à porta virtual, o TEID de GTP é gravado aos 32 bits inferiores dos metadados e o pacote é direcionado para a porta virtual. A porta virtual calcula o hash do TEID e busca as informações de cabeçalho de túnel na tabela de cabeçalho de túnel. Se nenhuma das tais informações de túnel estiver presente, o pacote é encaminhado para o controlador com uma indicação de erro. De outro modo, a porta virtual constrói um túnel de cabeçalho de GTP e encapsula o pacote. Quaisquer bits de DSCP ou bits de prioridade de VLAN são definidos adicionalmente nos cabeçalhos de túnel de IP ou MAC, e quaisquer etiquetas de VLAN ou rótulos de MPLS sofrem push para o pacote. O pacote encapsulado é encaminhado para fora da porta física à qual a porta virtual é ligada.

[00104] Em uma modalidade, o sistema implanta uma porta virtual de desencapsulamento da trajetória rápida de GTP. Quando solicitado pelo software de plano de controle do SGSN e do GGSN em execução no sistema de computação em nuvem, o comutador de porta de comunicação instala regras e ações para pacotes de direcionamento encapsulados de GTP fora dos túneis de GTP. As regras correspondem aos sinalizadores de cabeçalhos de GTP e ao TEID de GTP para o pacote, na tabela de fluxo de OpenFlow modificada mostrada na Figura 16 conforme a seguir: o endereço de destino do IP é um endereço de IP no qual a porta de comunicação espera tráfego de GTP; o tipo de protocolo de IP é UDP (17); a porta de destino de UDP é a porta de destino de GTP-U (2152); e os campos de cabeçalho e o campo de tipo de mensagem tem curingas com o sinalizador 0XFFF0 e os dois bytes superiores do campo correspondem ao tipo de mensagem de G-PDU (255) enquanto os dois bytes inferiores correspondem a 0x30, isto é, o pacote é um pacote de GTP e não um pacote de GTP’ e o número de versão é 1. A porta virtual simplesmente remove o túnel de cabeçalho de GTP e encaminha o pacote fechado do plano de dados do usuário para fora da porta física ligada.

[00105] Em uma modalidade, o sistema implanta o manuseio dos pacotes de controle de GTP-U. O controlador de OpenFlow programa as tabelas de fluxo do comutador de porta de comunicação com 5 regras para cada endereço de IP do comutador de porta de comunicação usado para o tráfego de GTP. Essas regras contêm valores especificados para os seguintes campos: o endereço de destino do IP é um endereço de IP no qual a porta de comunicação espera o tráfego de GTP; o tipo de protocolo de IP é UDP (17); a porta de destino de UDP é a porta de destino de GTP-U (2152); os sinalizadores de cabeçalhos de GTP e o campo de tipo de mensagem tem curingas com 0xFFF0; o valor do campo de sinalizadores de cabeçalho é 0x30, isto é, o número de versão é 1 e o campo PT é 1; e o valor do campo de tipo de mensagem é uma dentre 1 (Solicitação de Eco), 2 (Resposta de Eco), 26 (Indicação de Erro), 31 (Suporte para Notificação de Cabeçalhos de Extensão) ou 254 (Marcador de Extremidade).

[00106] A instrução associada a uma correspondência a uma dessas regras é: Aplicar Ações (Definir Porta de Saída LOCAL_GTP_CONTROL)

[00107] Isso faz com que o pacote seja encaminhado para que a porta de controle de GTP-U local do comutador de porta de comunicação seja processada pelo plano de controle de software de local. Os pacotes de controle de GTP-U que são originados pelo comutador são gerados no plano de controle de software e são direcionados pelo plano de controle.

[00108] Em uma modalidade, o sistema implanta o manuseio de pacotes de G- PDU com cabeçalhos de extensão, números de sequência e números de N-PDU. Os pacotes de G-PDU com cabeçalhos de extensão, os números de sequência e os números de N-PDU precisam ser encaminhados para o plano de controle de software de comutador local para processamento. O controlador de OpenFlow programa 3 regras para esse propósito. Os mesmos têm os seguintes campos de cabeçalho comuns: o endereço de destino do IP é um endereço de IP no qual a porta de comunicação espera pelo tráfego de GTP; e o tipo de protocolo de IP é UDP (17); a porta de destino de UDP é a porta de destino de GTP-U (2152).

[00109] Os sinalizadores de cabeçalho e o tipo de mensagem campos para as três regras têm curingas com as seguintes máscaras de bits e são cumpridas conforme o seguinte: a máscara de bits 0xFFF4 e os dois bytes superiores correspondem ao tipo de mensagem de G-PDU (255) enquanto os dois bytes inferiores são 0x34, que indicam que o número de versão é 1, o pacote é um pacote de GTP, e há um cabeçalho de extensão presentes; a máscara de bits 0xFFF2 e os dois bytes superiores correspondem ao tipo de mensagem de G-PDU (255) enquanto os dois bytes inferiores são 0x32, que indicam que o número de versão é 1, o pacote é um pacote de GTP, e há um número de sequência presente; e a máscara de bits 0xFF01 e os dois bytes superiores correspondem ao tipo de mensagem de G-PDU (255) enquanto os dois bytes inferiores são 0x31, que indicam que o número de versão é 1, o pacote é o pacote de GTP, e um N-PDU está presente.

[00110] A instrução para essas regras é a seguinte: Aplicar Ações (Definir Porta de Saída LOCAL_GTP_U_DECAP)

[00111] Isso envia o pacote para a trajetória de desencapsulamento de GTP-U de trajetória lenta de software para processamento especial.

[00112] Em uma modalidade, o sistema implanta o manuseio de pacotes de plano de dados de usuário que necessitam de encapsulamento de GTP-U com cabeçalhos de extensão, números de sequência e números de N-PDU. Os pacotes do plano de dados do usuário que necessitam de cabeçalhos de extensão, números de sequência ou números de N-PDU durante encapsulamento de GTP necessitam de manuseio especial pela trajetória lenta de software. Para esses pacotes, o controlador de OpenFlow programa uma correspondência de regra o quádruplo: endereço de origem do IP; endereço de destino do IP; porta de origem de UDP/TCP/SCTP; e porta de destino de UDP/TCP/SCTP. As instruções para os pacotes correspondentes são: Gravar Metadados (GTP-TEID,0xFFFFFFFF) Aplicar Ações (Definir Porta de Saída LOCAL_GTP_U_ENCAP)

[00113] Isso envia o pacote para a porta de encapsulamento de GTP de trajetória lenta de software e, além disso, torna o TEID disponível para a trajetória lenta.

[00114] A mensagem de OpenFlow que programa a inserção de regra também inclui informações sobre os valores para o número de sequência, o número de N- PDU ou o tipo de conteúdo do cabeçalho de extensão, assim como os campos de cabeçalho de pacote que projetam a porta de comunicação de desencapsulamento e o transporte de portador e o TEID de GTP. Essas informações são inseridas pelo software de plano de controle do comutador na tabela de encapsulamento de software, chaveadas pelo TEID.

[00115] Em uma modalidade, o sistema implanta o manuseio de pacotes de controle de GTP-C e GTP’. Quaisquer pacotes de controle de GTP-C e GTP’ que são direcionados para os endereços de IP em um comutador de porta de comunicação estão em erro. Esses pacotes precisam ser manejados pelas entidades de protocolo de SGSN, GGSN e GTP’ no sistema de computação em nuvem, não nas entidades de SGSN e GGSN nos comutadores. Para capturar tais pacotes, o controlador de OpenFlow deve programar o comutador com as duas regras seguintes: o endereço de destino do IP é um endereço de IP no qual a porta de comunicação espera pelo tráfego de GTP; o tipo de protocolo de IP é UDP (17); para uma regra, a porta de destino de UDP é a porta de destino de GTP-U (2152), para o outro, a porta de destino de UDP é a porta de destino de GTP-C (2123); os campos de sinalizadores de cabeçalhos de GTP e tipo de mensagem têm curingas.

[00116] Essas regras devem ter a prioridade mais baixa de todas as regras de GTP na tabela de fluxo do comutador de porta de comunicação. As mesmas corresponderão a quaisquer pacotes de GTP que não correspondem aos outros, regras mais específicas. A instrução para essas regras é a seguinte: Aplicar Ações (Definir Porta de Saída CONTROLLER)

[00117] Isso encapsula o pacote e envia o mesmo para o controlador de OpenFlow.

[00118] Em uma modalidade, o sistema implanta direcionamento de GTP de não porta de comunicação. Um comutador de OpenFlow estendido por GTP também pode alcançar o direcionamento de GTP sem realizar as funções de porta de comunicação de encapsulamento e desencapsulamento. A função de direcionamento de GTP pode ser realizada por um comutador de porta de comunicação além de sua função de porta de comunicação, ou a mesma pode ser realizada por outro comutador que não tem uma função de porta de comunicação, dentro da malha de comutação de EPC distribuída.

[00119] Um comutador de OpenFlow estendido por GTP contém pelo menos uma tabela de fluxo que maneja as regras que correspondem aos campos de cabeçalho de GTP como na Figura 16. O controlador OpenFlow programa as regras do campo de cabeçalho de GTP além dos outros campos para realizar o direcionamento de GTP e adiciona ações apropriadas se a regra for cumprida. Por exemplo, a seguinte regra corresponde a um pacote de controle de GTP-C direcionado para uma entidade de plano de controle (MSC, SGSN,GGSN) no sistema de computação em nuvem, que não está na VLAN de plano de controle: a etiqueta de VLAN não é definida para o VLAN de plano de controle, o campo de destino do endereço de IP é definido para o endereço de IP da entidade alvo de plano de controle, o tipo de protocolo de IP é UDP (17), a porta de destino de UDP é a porta de destino de GTP- C (2123), os sinalizadores de cabeçalhos de GTP e o tipo de mensagem tem curingas com 0xF0 e os campos de versão correspondida e tipo de protocolo são 2 e 1, que indicam que o pacote é um pacote de plano de controle de GTPv1 e não GTP’.

[00120] As seguintes ações realizam push em um plano de controle etiqueta de VLAN no pacote e encaminha o mesmo para a nuvem para processar pela entidade de plano de controle relevante. O pacote é encaminhado sem qualquer processamento de L3 (isto é, sem modificar o TTL de IP): Gravar Ação (Definir-VLAN-ID CP_VLAN_TAG) Gravar Ação (Definir Endereço de MAC de Fonte SWITCH_MAC_ADDR) Gravar Ação (Definir Endereço de MAC de Destino NEXT_HOP_MAC_ADDR) Definir Porta de Saída NEXT_HOP_PORT

EXTENSÕES DE GTP PARA OPENFLOW

[00121] O protocolo de OpenFlow pode ser modificado para fornecer extensões para GTP que permitam o gerenciamento do PC de 3G. O OpenFlow utiliza estruturas de dados referidas como estruturas de correspondência de fluxo que permitem que o protocolo defina critérios para corresponder regras a fluxos particulares. A estrutura de correspondência de fluxo de OpenFlow ofp_match, contém dois campos, tipo e comprimento, que permitem que a estrutura de correspondência de fluxo seja estendida. O campo de tipo pode ser definido para o tipo do campo de extensão e comprimento pode ser definido para o comprimento da estrutura de ofp_match de estendida. Em uma modalidade, um novo tipo com base em um número aleatório para correspondência de fluxo de GTP é definido: enum ofp_match_type_ext { ERSMT_GTP = 48696, };

[00122] O tipo pode ser gerado de modo aleatório de modo a não interferir com outros tipos estendidos. Não há atualmente mecanismo organizacional para registrar identificadores de tipo no OpenFlow.

[00123] A estrutura de ersmt_gtp define os campos de tabela de fluxo para direcionamento de fluxo de GTP como: struct ersmt_gtp { unitt8_t gtp_wildcard; uint16_t gtp_type_n_flags; uint16_t gtp_flag_mask; uint32_t gtp_teid; };

[00124] O campo gtp_type_n_flags contém o tipo de mensagem de GTP nos 8 bits superiores e os sinalizadores de cabeçalhos de GTP nos 8 bits inferiores. O campo gtp_teid contém o TEID de GTP. O campo gtp_wildcard se os sinalizadores e o tipo de GTO devem ser compatíveis. Se os quatro bits inferiores forem 1, o campo tipo e sinalizadores deve ser ignorado, enquanto se os quatro bits superiores forem 1, o TEID deve ser ignorado. Se os bits inferiores forem 0, os campos tipo e sinalizador devem ser sujeitos correspondidos aos sinalizadores no campo gtp_flag_mask, enquanto se os bits superiores forem 0, o TEID deve ser correspondido. A máscara é combinada com o tipo de mensagem e o campo de cabeçalho do pacote com o uso de AND lógico; o resultado se torna o valor da correspondência. Apenas aquelas partes do campo nas quais a máscara tem um valor 1 são correspondidas.

[00125] Além dos campos de tabela de fluxo, é necessário que um objeto codifique o encapsulamento da entrada da tabela de hash do TEID de porta virtual. A estrutura ersmt_gtp_tuninfo pode ser usada para definir essas informações: struct ermst_mpls_lbl { uint8_t mpls_lbl_low; uint8_t mpls_lbl_mid; uint8_t mpls_lbl_high; }; struct ersmt_gtp_tuninfo { uint16_t gtp_tuninfo_length; uint32_t gtp_tuninfo_saddr; uint32_t gtp_tuninfo_daddr; uint8_t gtp_tuninfo_dscp; uint8_t gtp_tuninfo_vlan_len; unit16_t gtp_tuninfo_vlan_tags[0]; /*comprimento variável*/ uint8_t gtp_tuninfo_mpls_len; struct mpls_lbl gtp_tuninfo_mpls_labels[0]; /*comprimento variável*/ };

[00126] A estrutura ermst_mpls_lbl fornece uma estrutura de dados de 24 bits para codificar rótulos de MPLS. A estrutura ersmt_gtp_tunifo contém campos que descrevem um túnel de GTP. Esses são inseridos na porta virtual de encapsulamento. A estrutura tem comprimento variável devido ao fato de que a mesma contém uma quantidade variável de etiquetas de VLAN e/ou rótulos de MPLS. O campo gtp_tuninfo_length contém o comprimento da estrutura. Os campos gtp_tuninfo_saddr, gtp_tuninfo_daddr e gtp_tuninfo_dscp contêm o endereço de origem do túnel (o endereço da interface no comutador que realiza o encapsulamento), o endereço de destino do túnel (o comutador ao qual o pacote de túnel será direcionado e que desencapsulará o pacote), e o Ponto de Código DiffServ (se houver) atribuído ao portador do túnel. O DSCP de portador será diferente de zero se o portador for um portador dedicado e não for um portador de melhor esforço.

[00127] O gtp_tuninfo_vlan_len e o gtp_tuninfo_mpls_len contêm o comprimento do campo de etiquetas de VLAN e do campo de rótulos de MPLS, respectivamente. Os campos gtp_tuninfo_vlan_tags[0] e gtp_tuninfo_mpls_labels[0] contêm as etiquetas reais de VLAN e/ou os rótulos de MPLS que precisam receber push no cabeçalho de túnel do pacote. Esses campos estarão ausentes (e os campos de comprimento correspondentes serão zero) se nenhuma das Trajetórias Comutadas de Rótulo de VLAN ou MPLS (LSPs) for usada para o túnel.

[00128] Em uma modalidade, o OpenFlow é modificado para adicionar mensagens de extensão para adicionar, eliminar ou modificar um portador do PC de 3G ou o túnel de GTP. A sinalização de OpenFlow para adicionar, modificar ou eliminar um portador do PC de 3G ou túnel de GTP consiste em uma mensagem de OpenFlow, a mensagem ofp_flow_mod, que contém uma definição de fluxo de GTP de ersmt_gtp. A mensagem de OpenFlow padrão de ofp_flow_mod pode ser usada contanto que o analisador do protocolo de OpenFlow possa manejar fluxos estendidos. Se a modificação de fluxo necessitar de uma mudança à tabela de hash do TEID da porta virtual de encapsulamento, o controlador de OpenFlow pode emitir uma mensagem de extensão de OpenFlow de GTP que contém a entrada da tabela de hash de TEID. O controlador de OpenFlow deve emitir ambas mensagens em sequência, a mensagem de ofp_flow_mod primeiro, então, a mensagem de modificação da tabela de hash do TEID, então, o controlador de OpenFlow deve emitir uma mensagem OFPT_BARRIER_REQUEST para forçar o processamento de ambas mensagens pelo comutador de OpenFlow.

[00129] O ofp_experimenter_header da estrutura do cabeçalho de extensão da mensagem de OpenFlow contém um campo de id experimentador, denominado experimentador. Em uma modalidade, esse campo pode ser definido para o OUI de IEEE da Ericsson, 0x01ec ou fabricante similar ou o OUI de fornecedor. O resto da estrutura contém as mensagens de extensão de GTP. Essas mensagens podem ser identificadas pelos seguintes códigos de mensagem: enum ermst_gtp_message_code { GTP_ADD_TEID_TABLE_ENTRY = 0, GTP_DEL_TEID_TABLE_ENTRY = 1, };

[00130] A extensão de OpenFlow de GTP contém uma mensagem para adicionar e para eliminar uma entrada da tabela de hash de TEID. As entradas são modificadas pela eliminação, primeiro, da entrada para o TEID, então, a adição de uma nova entrada para o mesmo TEID. A mensagem de extensão de OpenFlow de GTP para inserir uma nova entrada de TEID na tabela de hash da porta virtual de encapsulamento é: struct ermst_teid_table_add { ermst_gtp_message_code teid_table_add_type; uint16_t teid_table_add_teid; struct ermst_gtp_tuninfo teid_table_add_entry; };

[00131] O campo teid_table_add_type é definido para GTP_ADD_TEID_TABLE_ENTRY enquanto o campo teid_table_add_teid contém o TEID e o teid_table_add_entry contém a entrada da tabela a ser adicionada. A mensagem de extensão de OpenFlow de GTP para eliminar uma entrada de TEID da tabela de hash da porta virtual de encapsulamento é: struct ermst_teid_table_del { ermst_gtp_message_code teid_table_del_type; uint16_t teid_table_del_teid; };

[00132] O campo teid_table_del_type é definido para GTP_DEL_TEID_TABLE_ENTRY enquanto o campo teid_table_del_teid contém o TEID para a entrada a ser eliminada.

[00133] Em uma modalidade, as extensões a OpenFlow para GTP também abrange a configuração do comutador de OpenFlow. Antes de aceitar qualquer direcionamento de GTP atualização RPCs das entidades do plano de controle em nuvem do PC de 3G, o controlador de OpenFlow deve configurar encapsulamento de GTP e/ou portas virtuais de desencapsulamento nos comutadores de porta de comunicação de OpenFlow estendidos por GTP. A configuração é alcançada com o uso de um protocolo de configuração específico do comutador, e é descrita acima.

[00134] Além disso, para a configuração de porta virtual nas portas de comunicação de OpenFlow estendidos por GTP, pode ser necessária configuração de fila de QoS em qualquer comutador de OpenFlow que será encaminhada melhor que o tráfego de portador de GTP de melhor esforço. O protocolo de OpenFlow não contém mensagens para configurar filas, essa configuração é deixada para o protocolo de configuração, como é o caso com as portas virtuais. Antes de instalar quaisquer rotas de fluxo, o controlador de OpenFlow deve configurar quaisquer filas para se conectar com portas físicas e/ou virtuais em comutadores que direcionarão melhor que portadores de GTP de melhor esforço. Essa etapa de configuração pode ser feita tanto para comutadores de OpenFlow estendidos por GTP e comutadores padrão de OpenFlow.

[00135] Em uma modalidade, os fluxos de mensagem de OpenFlow para operações de GTP são modificados. Conforme descrito acima, as entidades do plano de controle do PC de 3G, que incluem partes do plano de controle do PC de 3G do SGSN e do SSSN residem em uma instalação de computação em nuvem em um centro de dados. O plano de controle do SGSN e GGSN se comunicam por meio de chamadas de procedimento remoto (RPCs) ou um mecanismo similar com o controlador de OpenFlow dentro da nuvem quando o direcionamento muda são disparadas pela sinalização de GTP. O controlador de OpenFlow habilita as mudanças no plano de dados às portas de comunicação do plano de dados habilitadas por OpenFlow estendido por GTP, ao plano de controle do SGSN e do GGSN, e a comutadores de OpenFlow que são estendidos para direcionamento de GTP, referido no presente documento como ‘GxOFS’, através da sinalização de OpenFlow na rede do plano de controle que conecta a nuvem às portas de comunicação e comutadores.

[00136] Em geral, nenhuma sinalização é necessária para o GxOFS se nenhum tratamento de direcionamento especial for necessário para fluxos de GTP. Os casos nos quais o tratamento pode ser necessário são, por exemplo: quando o PC de 3G do operador tiver pontos de emparelhamento com a Internet em mais de um ponto e consequentemente tem mais de uma porta de comunicação, o direcionamento à porta de comunicação ideal pode necessitar de direcionamento de tráfego dentro do PC de 3G em comutadores intermediários; e em que o fluxo de GTP deve receber tratamento especial de um aplicativo em algum ponto dentro da rede do operador, por exemplo, dentro da nuvem. Um exemplo de tal tratamento especial é a transcodificação. Os comutadores intermediários podem necessitar de programação para direcionar os pacotes de plano de usuário para o aplicativo de transcodificação. Essa lista não é extensa, muitos outros aplicativos de direcionamento de GTP em comutadores intermediários são possíveis.

[00137] Os túneis de contexto de PDP de GTP podem ser configurados com o uso do GTP-C criam mensagens de solicitação do contexto de PDP. Esse procedimento é usado em uma diversidade de sequências de mensagem, por exemplo, em um procedimento de anexação inicial de E-UTRAN.

[00138] As Figuras 18A a 18C são fluxogramas da criação, modificação e eliminação de sessão no PC de 3G. O processo para criar uma sessão é ilustrado na Figura 18A. O processo é iniciado em resposta a uma solicitação para criar um túnel de GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1801). A sessão de assinante é iniciada para conectar o equipamento de usuário no PC de 3G a outro ponto de extremidade da sessão de assinante, que pode ser outro equipamento de usuário (UE), um servidor ou ponto de extremidade similar. O túnel de GTP estabelece a rota da sessão de assinante ao longo da rede principal da rede de PC de 3G a um ponto de emparelhamento, a Internet ou ponto de extremidade similar. O controlador configura uma implantação de comutador do SGSN para encapsular e desencapsular pacotes de dados para a sessão de assinante e para estabelecer um primeiro ponto de extremidade do túnel de GTP (Bloco 1803). O controlador também configura cada comutador na rota do túnel de GTP para encaminhar pacotes em cada direção de acordo com a rota do túnel de GTP (Bloco 1805). O controlador configura um plano de dados do GGSN para encapsular e desencapsular os pacotes da sessão de assinante para estabelecer um segundo ponto de extremidade do túnel de GTP no GGSN (Bloco 1807).

[00139] O processo para modificar uma sessão é ilustrado na Figura 18B. O processo é iniciado em resposta a uma solicitação para modificar um túnel de GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1811). A sessão de assinante conecta o equipamento de usuário no PC de 3G a outro ponto de extremidade da sessão de assinante, que pode ser outro equipamento de usuário (UE), um servidor ou ponto de extremidade similar. O túnel de GTP é uma rota da sessão de assinante estabelecida ao longo da rede principal da rede de PC de 3G a um ponto de emparelhamento, a Internet ou ponto de extremidade similar. Um processo de modificação pode ser utilizado para redirecionar uma sessão de assinante ao longo da rede de PC de 3G aos mesmos pontos de extremidade ou a diferentes pontos de extremidade. Qualquer combinação dos pontos de extremidade do túnel de GTP e a trajetória do GTP pode ser mudada com o uso desse processo. O controlador modifica a configuração da implantação de comutador do SGSN para encapsular e desencapsular pacotes de dados para a sessão de assinante e para modificar um primeiro ponto de extremidade do túnel de GTP (Bloco 1813). O controlador também configura cada comutador na rota atual e na nova rota do túnel de GTP para encaminhar pacotes em cada direção de acordo com a rota do túnel de GTP (Bloco 1815). O controlador modifica a configuração de um plano de dados do GGSN para encapsular e desencapsular os pacotes da sessão de assinante para estabelecer um segundo ponto de extremidade do túnel de GTP no GGSN (Bloco 1817).

[00140] O processo para eliminar uma sessão é ilustrado na Figura 18C. O processo é iniciado em resposta a uma solicitação para eliminar um túnel de GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1821). A sessão de assinante conecta o equipamento de usuário no PC de 3G a outro ponto de extremidade da sessão de assinante, que pode ser outro equipamento de usuário (UE), um servidor ou ponto de extremidade similar. O túnel de GTP é uma rota da sessão de assinante estabelecida ao longo da rede principal da rede de PC de 3G a um ponto de emparelhamento, a Internet ou ponto de extremidade similar. A sessão de assinante e o túnel de GTP associado são eliminados quando o aplicativo associado no equipamento de usuário ou o aplicativo no outro equipamento de usuário ou o aplicativo de servidor na outra extremidade da sessão de assinante encerra a conexão. Os recursos da sessão de assinante são, então, reivindicados eliminando-se a sessão de assinante e o túnel de GTP. O controlador remove a configuração do túnel de GTP em uma implantação de comutador do SGSN que encapsulava e desencapsulava pacotes de dados para a sessão de assinante e o que, desse modo, remove um primeiro ponto de extremidade do túnel de GTP (Bloco 1823). O controlador também remove a configuração para o túnel de GTP de cada comutador na rota do túnel de GTP que encaminhou pacotes em cada direção de acordo com a rota do túnel de GTP (Bloco 1815). O controlador remove a configuração para o túnel de GTP de um plano de dados do GGSN que encapsulou e desencapsulou os pacotes da sessão de assinante e o que, desse modo, remove um segundo ponto de extremidade do túnel de GTP no GGSN (Bloco 1827).

[00141] Na Figura 19, um exemplo dos fluxos de mensagem de OpenFlow para o procedimento de solicitação para criar sessão é mostrado. No exemplo ilustrado, o componente do plano de controle do SSGN envia uma solicitação de criar sessão ao componente do plano de controle do GGSN no sistema de computação em nuvem, que, então, envia a solicitação ao controlador através de uma chamada de atualização de RPC do direcionamento de GTP. A chamada de RPC solicita que o controlador de OpenFlow estabeleça um novo ponto de extremidade do túnel de GTP no SGSN e no GGSN no plano de dados, e para instalar rotas para o novo portador de GTP ou túnel em comutadores intermediários, caso necessário.

[00142] Antes de devolver um resultado ao GGSN do plano de controle a partir do RPC de atualização do direcionamento de GTP, o controlador de OpenFlow emite uma sequência de mensagens de OpenFlow à entidade apropriada de porta de comunicação do plano de dados. Na modalidade exemplificativa, a sequência começa com um OFP_BARRIER_REQUEST para garantir que não haja mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT_FLOW_MOD é emitida, o que inclui a estrutura ofp_match com a extensão GTP como o campo de correspondência e OFPFC_ADD como o campo de comando. A mensagem especifica ações e instruções, conforme descrito acima, para estabelecer uma rota de fluxo para o túnel de GTP que encapsula e desencapsula os pacotes através da porta virtual apropriada. Além disso, imediatamente após a mensagem OFPT_FLOW_MOD, o controlador de OpenFlow emite uma mensagem GTP_ADD_TEID_TABLE_ENTRY às portas de comunicação que contêm as entradas da tabela de hash de TEID para a porta virtual de encapsulamento. Conforme descrito acima, as duas mensagens de OpenFlow são seguidas por uma mensagem OFPT_BARRIER_REQUEST para forçar as portas de comunicação para processar a rota de fluxo e a atualização da tabela de hash do TEID antes de prosseguir.

[00143] Antes de retornar do RPC de atualização do direcionamento de GTP, o controlador de OpenFlow também emite atualizações do fluxo de GTP direcionamento a quaisquer Comutações de OpenFlow estendidas por GTP (GxOFSs) que precisam estar envolvidas no direcionamento personalizado do fluxo de GTP. As mensagens nessas atualizações consistem em uma OFP_BARRIER_REQUEST seguida por uma mensagem OFPT_FLOW_MOD que contém a estrutura ofp_match com extensão de GTP para o novo fluxo de GTP como o campo de correspondência e OFPFC_ADD como o campo de comando, e as ações e instruções descritas acima para o direcionamento personalizado do fluxo de GTP. Uma OFP_BARRIER_REQUEST final força o comutador a processar a mudança antes de responder. As rotas de fluxo em qualquer GxOFSs são instaladas após instalar a rota do ponto de extremidade do túnel de GTP no SGSN no plano de dados e antes de instalar a rota do ponto de extremidade do túnel de GTP no GGSN no plano de dados, conforme ilustrado na Figura 19. O controlador de OpenFlow não responde ao RPC de GGSN do plano de controle até que todas as atualizações do direcionamento de fluxo tenham sido alcançadas.

[00144] Uma vez que os RPCs tenham retornado, o plano de controle GGSN e SGSN devolvam mensagens de resposta de contexto de criação de PDP. As características do portador de GTP são mudadas com o uso de um processo de solicitação do contexto do PDP de atualização. Tais mudanças podem incluir, por exemplo, a QoS atribuída aos pacotes de IP. Esse procedimento é usado em uma diversidade de sequências de mensagem do PC de 3G, por exemplo, uma solicitação de serviço disparada pelo UE.

[00145] A Figura 20 é um diagrama de uma modalidade da sequência de mensagem de OpenFlow para o procedimento de solicitação de modificar sessão. Como com a criação de sessão, o SGSN do plano de controle em nuvem do PC de 3G emite uma mensagem de solicitação do contexto de PDP de atualização para o GGSN do plano de controle e o GGSN do plano de controle emite um RPC de atualização do direcionamento de GTP ao controlador de OpenFlow que inclui as novas informações de atualização de túnel. O controlador de OpenFlow, então, emite mensagens de OpenFlow estendidas por GTP ao SGSN do plano de dados, GxOFSes e o GGSN do plano de dados.

[00146] Antes de devolver um resultado ao GGSN do plano de controle a partir do RPC de atualização do direcionamento de GTP, o controlador de OpenFlow emite uma sequência de mensagens de OpenFlow à entidade apropriada de porta de comunicação do plano de dados. A sequência começa com um OFP_BARRIER_REQUEST para garantir que não haja mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT_FLOW_MOD é emitida, o que inclui a estrutura ofp_match com a extensão GTP como o campo de correspondência e OFPFC_MODIFY ou OFPFC_MODIFY_STRICT como o campo de comando. Caso necessário, a mensagem especifica ações e instruções, conforme descrito acima, para estabelecer uma nova rota de fluxo para o túnel de GTP que encapsula e desencapsula os pacotes através da porta virtual apropriada. Além disso, se forem necessárias mudanças na tabela de hash do TEID, imediatamente após a mensagem OFPT_FLOW_MOD, o controlador de OpenFlow emite um TP_DEL_TEID_TABLE_ENTRY para eliminar a entrada seguida por uma mensagem TP_ADD_TEID_TABLE_ENTRY para instalar a nova entrada. Conforme descrito acima, as duas mensagens de OpenFlow são seguidas por uma mensagem OFPT_BARRIER_REQUEST para forçar as portas de comunicação para processar a rota de fluxo e a atualização da tabela de hash do TEID antes de prosseguir.

[00147] Antes de retornar do RPC de atualização do direcionamento de GTP, o controlador de OpenFlow também emite atualizações necessárias do fluxo de GTP direcionamento a quaisquer Comutações de OpenFlow estendidas por GTP (GxOFSs) que precisam estar envolvidas no direcionamento personalizado do fluxo de GTP. As mensagens nessas atualizações consistem em uma OFP_BARRIER_REQUEST seguida por uma mensagem OFPT_FLOW_MOD que contém a estrutura ofp_match com extensão de GTP para o novo fluxo de GTP como o campo de correspondência e OFPFC_MODIFY ou OFPFC_MODIFY_STRICT como o campo de comando, e, caso necessário, as ações e instruções, conforme descrito acima, para o direcionamento personalizado do fluxo de GTP. Uma OFP_BARRIER_REQUEST final força o comutador a processar a mudança antes de responder. As rotas de fluxo em qualquer GxOFSs são instaladas após instalar a rota do ponto de extremidade do túnel de GTP no SGSN do plano de dados e antes de instalar a rota do ponto de extremidade do túnel de GTP no GGSN do plano de dados, conforme ilustrado na Figura 20. O controlador de OpenFlow não responde ao RPC de GGSN do plano de controle até que todas as atualizações do direcionamento de fluxo tenham sido alcançadas. Uma vez que os RPCs tenham retornado, o plano de controle GGSN e SGSN devolvam mensagens de contexto de atualização de PDP.

[00148] Os túneis de GTP são eliminados com o uso do procedimento de solicitação da sessão de eliminação. Esse procedimento pode ser usado em uma diversidade de sequências de mensagem do PC de 3G, por exemplo, uma solicitação de desacoplamento disparada pelo UE. A Figura 21 é um diagrama de uma modalidade da sequência de mensagem de OpenFlow para o procedimento de solicitação de eliminar sessão. De modo similar à criação e à modificação de sessão, o SGSN do plano de controle em nuvem do PC de 3G emite uma mensagem de solicitação do contexto de PDP de eliminação para o GGSN do plano de controle e o GGSN do plano de controle emite um RPC de atualização do direcionamento de GTP ao controlador de OpenFlow que inclui as informações de eliminação de túnel. O controlador de OpenFlow, então, emite mensagens de OpenFlow estendidas por GTP ao SGSN do plano de dados, GxOFSes e o GGSN do plano de dados.

[00149] A sinalização de OpenFlow é conduzida antes de devolver o RPC de atualização do direcionamento de GTP para a participante que realiza a chamada. A sequência começa com um OFP_BARRIER_REQUEST para garantir que não haja mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT_FLOW_MOD é emitida, o que inclui a estrutura ofp_match com a extensão GTP como o campo de correspondência e OFPFC_DELETE ou OFPFC_DELETE_STRICT como o campo de comando. Além disso, imediatamente após a mensagem OFPT_FLOW_MOD, o controlador de OpenFlow emite uma GTP_DEL_TEID_TABLE_ENTRY para eliminar a entrada da tabela de hash de TEID. Conforme descrito acima, essa mensagem de OpenFlow é seguida por uma mensagem OFPT_BARRIER_REQUEST para forçar as portas de comunicação para processar a rota de fluxo e a atualização da tabela de hash do TEID antes de prosseguir.

[00150] Antes de retornar do RPC de atualização do direcionamento de GTP, o controlador de OpenFlow também emite atualizações necessárias do fluxo de GTP direcionamento a quaisquer Comutações de OpenFlow estendidas por GTP que precisam estar envolvidas no direcionamento personalizado do fluxo de GTP. As mensagens nessas atualizações consistem em uma OFP_BARRIER_REQUEST seguida por uma mensagem OFPT_FLOW_MOD que contém a estrutura ofp_match com extensão de GTP para o novo fluxo de GTP como o campo de correspondência e OFPFC_DELETE ou OFPFC_DELETE_STRICT como o campo de comando. Uma OFP_BARRIER_REQUEST final força o comutador a processar a mudança antes de responder. As rotas de fluxo em qualquer GxOFSs são instaladas após instalar a rota do ponto de extremidade do túnel de GTP no SGSN do plano de dados e antes de instalar a rota do ponto de extremidade do túnel de GTP no GGSN do plano de dados, conforme ilustrado na Figura 21. O controlador de OpenFlow não responde à entidade de chamada até que todas as atualizações do direcionamento de fluxo tenham sido alcançadas.

IMPLANTAÇÕES ALTERNATIVAS

[00151] Em outras modalidades, a arquitetura dividida de PC de 3G pode ser implantado em sistemas que não estejam em nuvem e não virtualizados. As entidades do plano de controle da arquitetura de PC de 3G podem ser armazenadas e executadas em um único servidor ou distribuídas ao longo de qualquer quantidade de servidores ou dispositivos de computação similares. De modo similar, as entidades do plano de controle podem ser executadas como código e módulos de software padrão sem virtualização ou sistemas similares. Essas entidades do plano de controle podem se comunicar entre si através do sistema local ou de chamadas de procedimento, chamadas de procedimento remoto ou mecanismos similares. Em modalidades adicionais, um subconjunto das entidades do plano de controle pode ser virtualizado ou executado em um sistema de computação em nuvem enquanto outro subconjunto das entidades do plano de controle puderem ser executadas em um servidor, sistema de servidor distribuído ou sistema similar. As entidades do plano de controle podem se comunicar com o plano de dados através do uso do protocolo de OpenFlow conforme descrito no presente documento acima ou através de outros protocolos de controle conforme descrito no presente documento abaixo.

[00152] O sistema de computação em nuvem descrito no presente documento acima é fornecido a título de exemplo e não a título de limitação. Uma pessoa versada na técnica deve entender que os princípios e recursos descritos acima em relação ao sistema de computação em nuvem também podem ser implantados em outras configurações como os únicos servidores ou sistemas de servidores distribuídos. Princípios e recursos similares àqueles descritos acima podem ser implantados em sistemas de servidores únicos, sistemas de servidores distribuídos e ambientes de computação similares. Esses princípios e recursos também podem ser implantados com o uso de um ambiente não virtualizado que inclui entidades não virtualizadas do plano de controle que são executadas em qualquer combinação dos sistemas de computação em nuvem, servidores únicos, sistemas de servidores distribuídos e sistemas similares.

[00153] Em outras modalidades, outros protocolos de controle podem ser utilizados em lugar de OpenFlow conforme descrito no presente documento. O uso de OpenFlow é apresentado a título de exemplo e não de limitação. Outros protocolos de controle também podem ser utilizados para gerar a comunicação entre o plano de controle e o plano de dados e configuração do plano de dados da arquitetura dividida de PC de 3G. Um exemplo de tal protocolo é FORCES, um protocolo padrão de IETF para dividir o plano de controle e encaminhar o plano em redes. A especificação do protocolo FORCES é descrita no RFC 5810. O RFC 5812 descreve a arquitetura de um elemento de encaminhamento de FORCES, o equivalente de um comutador de OpenFlow. O próprio protocolo FORCES não suporta diretamente rotas de programação no elemento de encaminhamento, o mesmo é, em vez disso, uma estrutura para o manuseio da interação entre o controlador de FORCES e um elemento de encaminhamento de FORCES. A arquitetura do elemento de encaminhamento descreve como projetar o protocolo que, de fato, permite que um controlador de FORCES programe um elemento de encaminhamento de FORCES. Uma pessoa versada na técnica deve entender que um sistema com base em FORCES pode incluir recursos descritos no presente documento acima em relação à modalidade OpenFlow, como a extensão de OpenFlow de GTP, para permitir que o controlador programe os comutadores para o direcionamento de TEID de GTP.

[00154] O FORCES e o OpenFlow são fornecidos a título de exemplo e não de limitação. Uma pessoa versada na técnica deve entender que os princípios e recursos descritos acima em relação aos protocolos de FORCES e de OpenFlow também podem ser implantados em outros protocolos de controle similares.

[00155] Conforme usado no presente documento, um dispositivo de rede (ND) é um dispositivo eletrônico que interconecta de modo comunicativo outros dispositivos eletrônicos na rede (por exemplo, outros dispositivos de rede, dispositivos de usuário final). Alguns dispositivos de rede são “múltiplos dispositivos de rede de serviços” que fornecem suporte para múltiplas funções de rede (por exemplo, direcionamento, formação de ponte, comutação, agregação de Camada 2, controle de borda de sessão, Qualidade de Serviço e/ou gerenciamento de assinante) e/ou fornecer suporte para múltiplos serviços de aplicativo (por exemplo, dados, voz e vídeo). Os dispositivos de rede podem incluir os dispositivos que implantam os comutadores de OpenFlow da placa de dados, os dispositivos que implantam o SGSN-D, o GGSN-D e dispositivos similares na rede A.

[00156] Figura 22A ilustra a conectividade entre dispositivos de rede (NDs) dentro de uma rede exemplificativa, assim como três implantações exemplificativas dos NDs, de acordo com algumas modalidades da invenção. A Figura 22A mostra os NDs 2200A a 2200H, e sua conectividade por meio de linhas entre A-B, B-C, C-D, DE, E-F, F-G e A-G, assim como entre H e cada um dentre A, C, D e G. Esses NDs são dispositivos físicos, e a conectividade entre esses NDs pode ser sem fio ou com fio (frequentemente referidos como um enlace). Uma linha adicional que se estende de NDs 2200A, E e F ilustram que esses NDs atuam como pontos de ingresso e de egresso para a rede (e, assim, esses NDs são referidos às vezes como NDs de borda; enquanto os outros NDs podem ser denominados NDs principais).

[00157] Duas das implantações de ND na Figura 22A são: 1) um dispositivo de rede de propósito especial 2202 que usa circuitos integrados específicos de aplicativo personalizados (ASICs) e um sistema operacional (OS) proprietário; e 2) um dispositivo de rede de propósito geral 2204 que usa processadores comuns de prateleira (COTS) e um OS padrão.

[00158] O dispositivo de rede de propósito especial 2202 inclui hardware de rede 2210 que compreende recurso(s) de computador 2212 (que incluem tipicamente um conjunto de um ou mais processadores), recurso(s) de encaminhamento 2214 (que incluem tipicamente um ou mais ASICs e/ou processadores de rede), e interfaces de rede (NIs) físicas 2216 (às vezes denominadas portas físicas), assim como meios de armazenamento legíveis por máquina não transitórios 2218 que tem armazenados em si o software de rede 2220. Uma NI física é um hardware em um ND através do qual uma conexão de rede (por exemplo, de modo sem fio através de um controlador de interface de rede sem fio (WNIC) ou através de conexão em um cabo a uma porta física conectada a um controlador de interface de rede (NIC)) é feita, como aquela mostrada pela conectividade entre os NDs 2200A a 2200H. Durante a operação, o software de rede 2220 pode ser executado pelo hardware de rede 2210 para criar uma instância de um conjunto de uma ou mais ocorrência(s) do software de rede 2222. Cada uma das ocorrências do software de rede 2222, e aquela parte do hardware de rede 2210 que executa aquela ocorrência do software de rede (seja este o hardware dedicado àquela ocorrência do software de rede e/ou fatias de tempo do hardware compartilhado em tempo por aquela ocorrência do software de rede com outras das ocorrências do software de rede 2222), a partir de um elemento de rede virtual separado 2230A a 2230R. Cada um dos elementos de rede virtuais (VNEs) 2230A a 2230R inclui um módulo de comunicação e configuração de controle 2232A a 2232R (às vezes referido como um módulo de controle local ou módulo de comunicação de controle) e tabelas de encaminhamento 2234A a 2234R, de modo que um dado elemento de rede virtual (por exemplo, 2230A) inclui o módulo de comunicação e configuração de controle (por exemplo, 2232A), um conjunto de uma ou mais tabelas de encaminhamento (por exemplo, 2234A), e aquela porção do hardware de rede 2210 que executa o elemento de rede virtual (por exemplo, 2230A).

[00159] Nas modalidades descritas no presente documento acima, os dispositivos de rede podem implantar qualquer funcionalidade do plano de dados do PC de 3G como módulos do conjunto de plano de dados 2233A. Os módulos do plano de dados 2233A pode ser configurado por meio de um plano de controle de ND 2224 e fazer interface com o plano de encaminhamento 2226 do ND. Em algumas modalidades, os módulos do plano de dados podem implantar a funcionalidade do plano de dados do SGSN (SGSN-D) ou do plano de dados do GGSN (GGSN-D) ou componentes similares no PC de 3G.

[00160] O dispositivo de rede de propósito especial 2202 é considerado frequentemente de modo físico e/ou de modo lógico como incluindo: 1) o plano de controle de ND 2224 (às vezes referido como um plano de controle) que compreende o(s) recurso(s) de computador 2212 que executa(m) o(s) módulo(s) de comunicação e configuração de controle 2232A a 2232R; e 2) um plano de encaminhamento de ND 2226 (às vezes referido como um plano de encaminhamento, um plano de dados ou um plano de mídia) que compreende o(s) recurso(s) de encaminhamento 2214 que utiliza(m) as tabelas de encaminhamento 2234A a 2234R e as NIs físicas 2216. A título de exemplo, em que o ND é um roteador (ou implanta funcionalidade de direcionamento), o plano de controle de ND 2224 (o(s) recurso(s) de computador 2212 que executa(m) o(s) módulo(s) de comunicação e configuração de controle 2232A a 2232R) é tipicamente responsável por participar no controle de como dados (por exemplo, pacotes) devem ser direcionados (por exemplo, o próximo salto para os dados e a NI física de saída para aqueles dados) e armazena aquelas informações de direcionamento nas tabelas de encaminhamento 2234A a 2234R, e o plano de encaminhamento de ND 2226 é responsável por receber aqueles dados nas NIs físicas 2216 e encaminhar aqueles dados para fora daqueles apropriados das NIs físicas 2216 com base nas tabelas de encaminhamento 2234A a 2234R.

[00161] A Figura 22B ilustra um modo exemplificativo de implantar o dispositivo de rede de propósito especial 2202 de acordo com algumas modalidades da invenção. A Figura 22B mostra um dispositivo de rede de propósito especial que inclui os cartões 2238 (tipicamente com hot plug). Embora em algumas modalidades, os cartões 2238 são de dois tipos (um ou mais que operam como o plano de encaminhamento de ND 2226 (às vezes denominados cartões de linha), e um ou mais que operam para implantar o plano de controle de ND 2224 (às vezes denominados cartões de controle)), as modalidades alternativas podem combinar funcionalidade em um único cartão e/ou incluem tipos de cartão adicionais (por exemplo, um tipo adicional de cartão é denominado um cartão de serviço, cartão de recurso ou cartão de múltiplos aplicativos). Um cartão de serviço pode fornecer processamento especializado (por exemplo, serviços da Camada 4 para Camada 7 (por exemplo, firewall, Segurança de Protocolo de Internet (IPsec) (RFC 4301 e 4309), Camada de Soquetes Segura (SSL) / Segurança de Camada de Transporte (TLS), Sistema de Detecção de Intrusão (IDS), par-a-par (P2P), Voz por IP (VoIP) Controlador de Borda de Sessão, Portas de comunicação Sem Fio Móveis (Nó de Suporte de Serviço de Rádio de Pacote Geral de Porta de comunicação (GPRS) (GGSN), Porta de comunicação do Núcleo de Pacote Evoluído (EPC))). A título de exemplo, um cartão de serviço pode ser usado para encerrar túneis de IPsec e executar a autenticação de atendente e algoritmos de encriptação. Esses cartões são acoplados juntos através de um ou mais mecanismos de interconexão ilustrados como backplane 2236 (por exemplo, um primeiro acoplamento completo de malha dos cartões de linha e um segundo acoplamento completo de malha de todos os cartões).

[00162] Voltando-se para a Figura 22A, o dispositivo de rede de propósito geral 2204 inclui o hardware 2240 que compreende um conjunto de um ou mais processador(es) 2242 (que são frequentemente processadores de COTS) e controlador(es) de interface de rede 2244 (NICs; também conhecidos como cartões de interface de rede) (que incluem NIs físicas 2246), assim como meios de armazenamento legíveis por máquina não transitórios 2248 que tem armazenados em si o software 2250. Durante a operação, o(s) processador(es) 2242 executa(m) o software 2250 para criar uma instância de um hipervisor 2254 (às vezes referido como um monitor de máquina virtual (VMM)) e uma ou mais máquinas virtuais 2262A a 2262R que são executadas pelo hipervisor 2254, que são referidos coletivamente como ocorrência(s) de software 2252. Uma máquina virtual é uma implantação de software de uma máquina física que executa programas como se os mesmos fossem executados em uma máquina física não virtualizada; e os aplicativos em geral não sabem se os mesmos estão em execução em uma máquina virtual em oposição a estarem em execução em um dispositivo eletrônico que hospeda “bare metal”, embora alguns sistemas forneçam paravirtualização que permitir que um sistema operacional ou aplicativo esteja ciente da presença de virtualização para propósitos de otimização. Cada uma das máquinas virtuais 2262A a 2262R, e aquela parte do hardware 2240 que executa aquela máquina virtual (seja este um hardware dedicado àquela máquina virtual e/ou fatias de tempo de hardware compartilhado em tempo por aquela máquina virtual com outras das máquinas virtuais 2262A a 2262R) forma elementos de rede virtual separados 2260A a 2260R.

[00163] O(s) elemento(s) de rede virtuais 2260A a 2260R realiza(m) funcionalidade similar ao(s) elemento(s) de rede virtuais 2230A a 2230R. Por exemplo, o hipervisor 2254 pode apresentar uma plataforma virtual operante que aparece como hardware de rede 2210 para a máquina virtual 2262A, e a máquina virtual 2262A pode ser usada para implantar funcionalidade similar ao(s) módulo(s) de comunicação e configuração de controle 2232A e a(s) tabela(s) de encaminhamento 2234A (essa virtualização do hardware 2240 é referida às vezes como virtualização de função de rede (NFV)). Dessa forma, NFV pode ser usado para consolidar muitos tipos de equipamento de rede no hardware industrial padrão de servidor de alto volume, comutadores físicos e armazenamento físico, que pode estar localizado nos Centros de Dados, NDs e equipamento de premissa do cliente (CPE). Entretanto, diferentes modalidades da invenção podem implantar uma ou mais das máquinas virtuais 2262A a 2262R de modo diferente. Por exemplo, embora as modalidades da invenção sejam ilustradas com cada máquina virtual 2262A a 2262R que correspondem a um VNE 2260A a 2260R, as modalidades alternativas podem implantar essa correspondência a um nível de granularidade mais fino (por exemplo, máquinas virtuais de cartão de linha virtualizam cartões de linha, máquina virtual de cartão de controle virtualizam cartões de controle , etc.); deve ser entendido que as técnicas descritas no presente documento com referência a uma correspondência de máquinas virtuais a VNEs também se aplicam a modalidades em que tal nível de granularidade mais fino é usado.

[00164] Em certas modalidades, o hipervisor 2254 inclui um comutador virtual que fornece serviços de encaminhamento similares como um comutador Ethernet físico. Especificamente, esse comutador virtual encaminha o tráfego entre máquinas virtuais e NIC(s) 2244, assim como, opcionalmente, entre as máquinas virtuais 2262A a 2262R; além disso, esse comutador virtual pode reforçar o isolamento de rede entre os VNEs 2260A a 2260R que, por política, não são permitidos à comunicação entre si (por exemplo, honrando-se as redes de área local virtuais (VLANs)).

[00165] Nas modalidades descritas no presente documento acima, as máquinas virtuais 2262A a 2262R podem implantar qualquer funcionalidade do plano de dados do PC de 3G como os módulos do conjunto de plano de dados 2263A. Os módulos do plano de dados 2263A podem controlar o plano de encaminhamento do ND local ou qualquer outro ND na rede do PC de 3G. Em algumas modalidades, os módulos do plano de dados podem implantar toda a funcionalidade ou uma porção da funcionalidade do plano de dados do SGSN (SGSN-D) ou plano de dados do GGSN (GGSN-D) ou componentes similares no PC de 3G em um esquema distribuído dentro do conjunto de ND da rede do PC de 3G.

[00166] A terceira implantação de ND exemplificativa na Figura 22A é um dispositivo de rede híbrido 2206, que inclui tanto ASICs de cliente/OS de proprietário quanto processadores de COTS/OS padrão em um único ND ou um único cartão dentro de um ND. Em certas modalidades de tal dispositivo de rede híbrido, uma plataforma de VM (isto é, uma VM que implanta a funcionalidade do dispositivo de rede de propósito especial 2202) pode prever paravirtualização ao hardware de rede presente no dispositivo de rede híbrido 2206.

[00167] Independentemente das implantações exemplificativas acima de um ND, quando um único uma dentre múltiplos VNEs implantado por um ND for considerado (por exemplo, apenas um dos VNEs é parte de uma dada rede virtual) ou em que apenas um único VNE é, de fato, implantado por um ND, o elemento de rede (NE) de termo encurtado é usado às vezes para se referir àquele VNE. Também, em todas as implantações exemplificativas acima, cada um dos VNEs (por exemplo, VNEs 2230A a 2230R, VNEs 2260A a 2260R, e aqueles no dispositivo de rede híbrido 2206) recebe dados nas NIs físicas (por exemplo, 2216, 2246) e encaminha aqueles dados a partir daqueles apropriados dentre as NIs físicas (por exemplo, 2216, 2246). Por exemplo, um VNE que implanta a funcionalidade do roteador de IP encaminha pacotes de IP com base em algumas das informações de cabeçalho de IP no pacote de IP; em que as informações de cabeçalho de IP incluem o endereço de origem de IP, o endereço de destino de IP, a porta de origem, a porta de destino (em que “porta de origem” e “porta de destino” se referem no presente documento a portas de protocolo, em oposição a portas físicas de um ND), protocolo de transporte (por exemplo, protocolo de datagrama de usuário (UDP) (RFC 768, 2460, 2675, 4113 e 5405), Protocolo de Controle de Transmissão (TCP) (RFC 793 e 1180), e valores de serviços diferenciados (DSCP) (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290 e 3317).

[00168] A Figura 22C ilustra diversos modos exemplificativos nos quais os VNEs podem ser acoplados de acordo com algumas modalidades da invenção. A Figura 22C mostra os VNEs 2270A.1 a 2270A.P (e opcionalmente os VNEs 2280A.Q a 2280A.R) implantados no ND 2200A e no VNE 2270H.1 no ND 2200H. Na Figura 22C, os VNEs 2270A.1 a P são separados um do outro no sentido que os mesmos podem receber pacotes de fora do ND 2200A e encaminhar os pacotes fora do ND 2200A; o VNE 2270A.1 está acoplado ao VNE 2270H.1, e, assim, os mesmos comunicam pacotes entre seus respectivos NDs; os VNE 2270A.2 a 2270A.3 podem encaminhar opcionalmente os pacotes entre si sem encaminhar os mesmos para fora do ND 2200A; e o VNE 2270A.P pode ser opcionalmente o primeiro em uma cadeia de VNEs que inclui o VNE 2270A.Q seguido pelo VNE 2270A.R (isso é referido às vezes como formação de cadeia de serviço dinâmico, em que cada um dos VNEs na série de VNEs fornece um serviço diferente - por exemplo, um ou mais serviços de rede da camada 4 à camada 7). Embora a Figura 22C ilustre diversas relações exemplificativas entre os VNEs, as modalidades alternativas podem suportar outras relações (por exemplo, mais ou menos VNEs, mais ou menos cadeias de serviço dinâmico, múltiplas cadeias de serviço dinâmico diferentes com alguns VNEs comuns e alguns VNEs diferentes).

[00169] O NDs da Figura 22A, por exemplo, pode fazer parte da Internet ou de uma rede privada; e outros dispositivos eletrônicos (não mostrados; como dispositivos de usuário final que incluem estações de trabalho, computadores do tipo laptop, computadores do tipo netbook, dispositivos do tipo tablet, dispositivos do tipo palm top, telefones móveis, smartphones, telefones de multimídia, Telefones de Voz Por Protocolo de Internet (VOIP), terminais, reprodutores de mídia portáteis, unidades de GPS, dispositivos descartáveis, sistemas de jogo, conversores de sinais, aplicativos domésticos habilitados pela Internet) podem ser acoplados à rede (diretamente ou através de outras redes como redes de acesso) para se comunicar pela rede (por exemplo, a Internet ou redes privadas virtuais (VPNs) sobrepostas (por exemplo, em túnel através de) Internet) entre si (diretamente ou através de servidores) e/ou conteúdo e/ou serviços de acesso. Tal conteúdo e/ou serviços são fornecidos tipicamente por um ou mais servidores (não mostrados) que pertencem a um fornecedor de serviço/conteúdo ou um ou mais dispositivos de usuário final (não mostrados) que participam de um serviço par-a-par (P2P), e podem incluir, por exemplo, páginas da web públicas (por exemplo, conteúdo livre, frentes de armazenamento, serviços de busca), páginas da web privadas (por exemplo, páginas da web acessadas por nome de usuário/senha que fornecem serviços de email) e/ou redes corporativas por VPNs. Por exemplo, os dispositivos de usuário final podem ser acoplados (por exemplo, através de equipamento de premissa do cliente acoplado a uma rede de acesso (com fio ou sem fio)) a NDs de borda, que são acoplados (por exemplo, através de um ou mais NDs principais) a outros NDs de borda, que são acoplados a dispositivos eletrônicos que atuam como servidores. Entretanto, através da virtualização de computação e armazenamento, um ou mais dos dispositivos eletrônicos que operam como os NDs na Figura 22A também podem hospedar um ou mais tais servidores (por exemplo, no caso do dispositivo de rede de propósito geral 2204, uma ou mais das máquinas virtuais 2262A a 2262R podem operar como servidores; o mesmo seria verdade para o dispositivo de rede híbrido 2206; no caso do dispositivo de rede de propósito especial 2202, um ou mais tais servidores também poderiam ser executados em um hipervisor executado pelo(s) recurso(s) de computador 2212); em cujo caso os servidores são tidos como coalocados com os VNEs daquele ND.

[00170] Uma rede virtual é uma abstração lógica de uma rede física (como aquela na Figura 22A) que fornece serviços de rede (por exemplo, serviços de L2 e/ou L3). Uma rede virtual pode ser implantada como uma rede de sobreposição (às vezes referida como uma sobrecamada de virtualização de rede) que fornece serviços de rede (por exemplo, serviços de camada 2 (L2, camada de enlace de dados) e/ou de camada 3 (L3, camada de rede)) por uma rede subjacente (por exemplo, uma rede L3, como uma rede de Protocolo de Internet (IP) que usa túneis (por exemplo, encapsulamento de direcionamento genérico (GRE), protocolo de túnel de camada 2 (L2TP), IPSec) para criar a rede de sobreposição).

[00171] Uma borda da virtualização de rede (NVE) fica na borda da rede subjacente e participa na implantação da virtualização de rede; no lado voltado para a rede do NVE usa a rede subjacente aos quadros de túnel para e provenientes dos NVEs; o lado voltado para fora do NVE envia e recebe dados para e a partir de sistemas fora da rede. Uma ocorrência de rede virtual (VNI) é uma ocorrência específica de uma rede virtual em um NVE (por exemplo, um NE/VNE em um ND, uma parte de um NE/VNE em um ND em que aquele NE/VNE é dividido em múltiplos VNEs através de emulação); um ou mais VNIs podem ter instâncias em um NVE (por exemplo, como diferentes VNEs em um ND). Um ponto de acesso virtual (VAP) é um ponto de conexão lógico no NVE para conectar sistemas externos a uma rede virtual; um VAP pode ser físico ou as portas virtuais identificadas através de identificadores de interface lógicos (por exemplo, um ID de VLAN).

[00172] Os exemplos de serviços de rede incluem: 1) um serviço de emulação de LAN de Ethernet (um serviço de múltiplos pontos com base em Ethernet similar a um serviço de Comutação de Rótulo de Múltiplos Protocolos (MPLS) da Força-Tarefa de Engenharia de Internet (IETF) ou VPN de Ethernet (EVPN)) no qual os sistemas externos são interconectados ao longo da rede por um ambiente de LAN pela rede subjacente (por exemplo, um NVE fornece VNIs de L2 separados (ocorrências de comutação virtual) para diferentes das tais redes virtuais, e encapsulamento de túnel de L3 (por exemplo, IP/MPLS) ao longo da rede subjacente); e 2) um serviço de encaminhamento de IP virtualizado (similar a VPN de IP de IETF (por exemplo, Protocolo de Porta de comunicação de Borda (BGP)/RFC de IPVPN de MPLS 4364) a partir de uma perspectiva de definição de serviço) na qual os sistemas externos são interconectados ao longo da rede por um ambiente de L3 pela rede subjacente (por exemplo, um NVE fornece VNIs de L3 separadas (ocorrências de encaminhamento e direcionamento ) ara diferentes dentre as tais redes virtuais, e encapsulamento de túnel de L3 (por exemplo, IP/MPLS) ao longo da rede subjacente)). Os serviços de rede também podem incluir capacidades de qualidade de serviço (por exemplo, marcação de qualificação de tráfego, condicionamento e programação de tráfego), capacidades de segurança (por exemplo, filtros para proteger premissas de cliente a partir da rede - ataques originados, para evitar anúncios de rota malformada), e capacidades de gerenciamento (por exemplo, detecção e processamento totais).

[00173] A Figura 22D ilustra uma rede com um único elemento de rede em cada um dos NDs da Figura 22A, e dentro dessa abordagem direta contrasta com uma abordagem distribuída tradicional (normalmente usada por roteadores tradicionais) com uma abordagem centralizada para manter informações de alcance e encaminhamento (também denominadas controle de rede), de acordo com algumas modalidades da invenção. Especificamente, a Figura 22D ilustra elementos de rede (NEs) 2270A a 2270H com a mesma conectividade que os NDs 2200A a 2200H da Figura 22A.

[00174] A Figura 22D ilustra que a abordagem distribuída 2272 distribui a responsabilidade para gerar as informações de alcance e encaminhamento ao longo dos NEs 2270A a 2270H; em outras palavras, o processo de descoberta de vizinhança e de descoberta de topologia é distribuído.

[00175] Por exemplo, quando o dispositivo de rede de propósito especial 2202 for usado, os módulos de comunicação e configuração de controle 2232A a 2232R do plano de controle de ND 2224 incluem tipicamente um módulo de informações de alcance e encaminhamento module para implantar um ou mais protocolos de direcionamento (por exemplo, um protocolo de porta de comunicação exterior como o Protocolo de Porta de comunicação de Borda (BGP) (RFC 4271), Protocolo(s) de Porta de comunicação Interior (IGP) (por exemplo, Abrir a Trajetória Mais Curta Primeiro (OSPF) (RFC 2328 e 5340), o Sistema Intermediário para Sistema Intermediário (IS-IS) (RFC 1142), Protocolo de Informações de Direcionamento (RIP) (RFC de versão 1 1058, RFC de versão 2 2453, e RFC de próxima geração 2080)), Protocolo de Distribuição de Rótulo (LDP) (RFC 5036), Protocolo de Reserva de Recurso (RSVP) (RFC 2205, 2210, 2211, 2212, assim como Engenharia de Tráfego (TE) de RSVP: As extensões a RSVP para RFC de Túneis de LSP 3209, RFC de RSVP-TE de Sinalização da Comutação de Rótulo de Múltiplos Protocolos Generalizados (GMPLS) 3473, RFC 3936, 4495 e 4558)) que se comunicam com outros NEs para trocar rotas, e, então, seleciona aquelas rotas com base em uma ou mais métricas de direcionamento. Dessa forma, os NEs 2270A a 2270H (por exemplo, o(s) recurso(s) de computador 2212 que executam o(s) módulo(s) de comunicação e configuração de controle 2232A a 2232R) realizam suas responsabilidades para participar no controle de como dados (por exemplo, pacotes) devem ser direcionados (por exemplo, o próximo salto para os dados e a NI física de saída para aqueles dados) determinando-se de modo distribuído o alcance dentro da rede e calculando-se suas respectivas informações de encaminhamento. As rotas e adjacências são armazenadas em uma ou mais estruturas de direcionamento (por exemplo, Base de Informações de Roteamento (RIB), Base de Informações de Rótulo (LIB), uma ou mais estruturas de adjacência) no plano de controle de ND 2224. O plano de controle de ND 2224 programa o plano de encaminhamento de ND 2226 com informações (por exemplo, informações de adjacência e rota) com base nas estruturas de direcionamento. Por exemplo, o plano de controle de ND 2224 programa as informações de adjacência e rota em uma ou mais tabelas de encaminhamento 2234A a 2234R (por exemplo, Base de Informações de Encaminhamento (FIB), Base de Informações de Encaminhamento de Rótulo (LFIB) e uma ou mais estruturas de adjacência) no plano de encaminhamento de ND 2226. Para o encaminhamento da camada 2, o ND pode armazenar uma ou mais tabelas de ponte que são usadas para encaminhar dados com base nas informações da camada 2 naqueles dados. Embora o exemplo acima use o dispositivo de rede de propósito especial 2202, a mesma abordagem distribuída 172 pode ser implantada no dispositivo de rede de propósito geral 2204 e no dispositivo de rede híbrido 2206.

[00176] A Figura 22D ilustra que uma abordagem centralizada 2274 (também conhecida como rede definida por software (SDN)) que desacopla o sistema que toma decisões sobre quando o tráfego é enviado a partir de sistemas subjacentes que encaminham tráfego para o destino selecionado. A abordagem centralizada ilustrada2274 tem responsabilidade pela geração de informações de alcance e encaminhamento em um plano de controle centralizado 2276 (às vezes referido como um módulo de controle de SDN, controlador, controlador de rede, controlador de OpenFlow, controlador de SDN, nó de plano de controle, autoridade de virtualização de rede ou entidade de controle de gerenciamento), e, assim, o processo de descoberta de vizinhança e descoberta de topologia é centralizado. O plano de controle centralizado 2276 tem uma interface de união sul 2282 com um plano de dados 2280 (às vezes referido à camada de infraestrutura, ao plano de encaminhamento de rede ou ao plano de encaminhamento (que não deve ser confundido com o plano de encaminhamento de ND)) que inclui os NEs 2270A a 2270H (às vezes referidos como comutadores, elementos de encaminhamento, elementos do plano de dados ou nós). Em uma modalidade, o plano de controle centralizado 2276 inclui o conjunto de módulos do plano de controle 2281 conforme descrito no presente documento acima, o que implanta as funções do PC de 3G. Conforme discutido adicionalmente no presente documento abaixo e acima, essas funções podem ser implantadas também na camada de aplicativo 2286 ou por meio de uma abordagem distribuída 2272 ou qualquer combinação dos mesmos com funções diferentes do módulo do plano de controle 2281 do PC de 3G manejado qualquer dessas abordagens. O plano de controle centralizado 2276 inclui um controlador de rede 2278, que inclui um módulo centralizado de informações de alcance e encaminhamento 2279 que determina o alcance dentro da rede e distribui as informações de encaminhamento aos NEs 2270A a 2270H do plano de dados 2280 pela interface de união sul 2282 (que pode usar o protocolo de OpenFlow). Dessa forma, a inteligência de rede é centralizada no plano de controle centralizado 2276 em execução nos dispositivos eletrônicos que são tipicamente separados dos NDs.

[00177] Por exemplo, quando o dispositivo de rede de propósito especial 2202 for usado no plano de dados 2280, cada um dos módulos de comunicação e configuração de controle 2232A a 2232R do plano de controle de ND 2224 inclui tipicamente um agente de controle que fornece o lado de VNE da interface de união sul 2282. Nesse caso, o plano de controle de ND 2224 (o(s) recurso(s) de computador 2212 que executam os módulos de comunicação e configuração de controles 2232A a 2232R) realiza sua responsabilidade por participar no controle de como os dados (por exemplo, pacotes) devem ser direcionados (por exemplo, o próximo salto para os dados e a NI física de saída para aqueles dados) através do agente de controle que se comunica com o plano de controle centralizado 2276 para receber as informações de encaminhamento (e, em alguns casos, as informações de alcance) provenientes do módulo centralizado de informações de alcance e encaminhamento 2279 (deve ser entendido que em algumas modalidades da invenção, os módulos de comunicação e configuração de controle 2232A a 2232R, além de se comunicar com o plano de controle centralizado 2276, também podem desempenhar algum papel na determinação do alcance e/ou cálculo de informações de encaminhamento - embora menos que no caso de uma abordagem distribuída; tais modalidades são consideradas em geral como abrangidas pela abordagem centralizada 2274, mas também podem ser consideradas como uma abordagem híbrida).

[00178] Embora o exemplo acima use o dispositivo de rede de propósito especial 2202, a mesma abordagem centralizada 174 pode ser implantada com o dispositivo de rede de propósito geral 2204 (por exemplo, cada um dos VNEs 2260A a 2260R realiza sua responsabilidade por controlar como dados (por exemplo, pacotes) devem ser direcionados (por exemplo, o próximo salto para os dados e a NI física de saída para aqueles dados) comunicando-se com o plano de controle centralizado 2276 para receber as informações de encaminhamento (e, em alguns casos, as informações de alcance) provenientes do módulo centralizado de informações de alcance e encaminhamento 2279; deve ser entendido que, em algumas modalidades da invenção, os VNEs 2260A a 2260R, além de se comunicar com o plano de controle centralizado 2276, também podem desempenhar algum papel na determinação do alcance e/ou cálculo de informações de encaminhamento - embora menos que no caso de uma abordagem distribuída) e o dispositivo de rede híbrido 2206. De fato, o uso de técnicas de SDN pode melhorar as técnicas de NFV usadas tipicamente nas implantações do dispositivo de rede de propósito geral 2204 ou do dispositivo de rede híbrido 2206 já que o NFV tem capacidade para suportar SDN fornecendo-se uma infraestrutura mediante a qual o software de SDN pode ser executado, e tanto NFV quanto SDN objetivam o uso de hardware de servidor de mercadoria e comutadores físicos.

[00179] A Figura 22D também mostra que o plano de controle centralizado 2276 tem uma interface de união norte 2284 a uma camada de aplicativo 2286, na qual reside(m) o(s) aplicativo(s) 2288. O plano de controle centralizado 2276 tem capacidade para formar redes virtuais 2292 (às vezes referidas como um plano de encaminhamento lógico, serviços de rede ou redes sobrepostas (com os NEs 2270A a 2270H do plano de dados 2280 sendo a rede subjacente)) para o(s) aplicativo(s) 2288. Dessa forma, o plano de controle centralizado 2276 mantém uma vista global de todos os NDs e NEs/VNEs configurados, e o mesmo mapeia as redes virtuais aos NDs subjacentes de modo eficiente (o que inclui manter esses mapeamentos conforme a rede física muda tanto através de hardware (ND, enlace ou componente de ND) falha, adição ou remoção).

[00180] Embora a Figura 22D mostre a abordagem distribuída 2272 separada da abordagem centralizada 2274, o esforço de controle de rede pode ser distribuído de modo diferente ou os dois combinados em certas modalidades da invenção. Por exemplo: 1) as modalidades podem usar, em geral, a abordagem centralizada (SDN) 2274, mas têm certas funções delegadas aos NEs (por exemplo, a abordagem distribuída pode ser usada para implantar um ou mais dentre monitoramento de falha, monitoramento de desempenho, comutação de proteção e primitivos para descoberta de vizinho e/ou topologia); ou 2) as modalidades da invenção podem realizar a descoberta de vizinhança e a descoberta de topologia por meio tanto do plano de controle centralizado quanto dos protocolos distribuídos, e os resultados comparados para elevar as exceções em que os mesmos não concordam. Tais modalidades são consideradas, em geral, como abrangidas pela abordagem centralizada 2274, mas também podem ser consideradas como uma abordagem híbrida.

[00181] Embora a Figura 22D ilustre o caso simples em que cada um dos NDs 2200A a 2200H implanta um único NE 2270A a 2270H, deve ser entendido que as abordagens de controle de rede descritas com referência à Figura 22D também funcionam para redes em que um ou mais dos NDs 2200A a 2200H implantam múltiplos VNEs (por exemplo, VNEs 2230A a 2230R, VNEs 2260A a 2260R, aqueles no dispositivo de rede híbrido 2206). Alternativa ou adicionalmente, o controlador de rede 2278 também pode emular as implantações de múltiplos VNEs em um único ND. Especificamente, em vez de (ou além de) implantar múltiplos VNEs em um único ND, o controlador de rede 2278 pode apresentar a implantação de um VNE/NE em um único ND como múltiplos VNEs nas redes virtuais 2292 (todos na mesma uma dentre a(s) rede(s) virtual (ou virtuais) 2292, cada um em diferentes redes virtuais 2292, ou alguma combinação). Por exemplo, o controlador de rede 2278 pode fazer com que um ND implante um único VNE (um NE) na rede subjacente, e, então, divida de modo lógico os recursos daquele NE dentro do plano de controle centralizado 2276 para apresentar diferentes VNEs na(s) rede(s) virtual (ou virtuais) 2292 (quando esses VNEs diferentes nas redes sobrepostas compartilharem os recursos da única implantação de VNE/NE no ND na rede subjacente).

[00182] Por outro lado, as Figuras 22E e 22F ilustra respectivamente as abstrações exemplificativas de NEs e VNEs que o controlador de rede 2278 pode apresentar como parte de diferentes redes virtuais 2292. A Figura 22E ilustra o caso simples de quando cada um dos NDs 2200A a 2200H implanta um único NE 2270A a 2270H (ver Figura 22D), mas o plano de controle centralizado 2276 abstraiu múltiplos dentre os NEs em diferentes NDs (os NEs 2270A a 2270C e 2270G a 2270H) em (para representar) um único NE 2270I em uma dentre a(s) rede(s) virtual (ou virtuais) 2292 da Figura 22D, de acordo com algumas modalidades da invenção. A Figura 22E mostra que nessa rede virtual, o NE 2270I é acoplado ao NE 2270D e 2270F, que continuam, ambos, acoplados ao NE 2270E.

[00183] A Figura 22F ilustra um case em que múltiplos VNEs (VNE 2270A.1 e VNE 2270H.1) estão implantadas em diferentes NDs (ND 2200A e ND 2200H) e estão acopladas uma à outra, e em que o plano de controle centralizado 2276 abstraiu esses múltiplos VNEs de modo que os mesmos aparecem como um único VNE 2270T dentro de uma das redes virtuais 2292 da Figura 22D, de acordo com algumas modalidades da invenção. Dessa forma, a abstração de um NE ou VNE pode disseminar múltiplos NDs.

[00184] Embora algumas modalidades da invenção implantem o plano de controle centralizado 2276 como uma única entidade (por exemplo, uma única ocorrência de software em execução em um único dispositivo eletrônico), as modalidades alternativas podem espalhar a funcionalidade ao longo de múltiplas entidades para propósitos de redundância e/ou escalabilidade (por exemplo, múltiplas ocorrências de software em execução em diferentes dispositivos eletrônicos).

[00185] De modo similar às implantações do dispositivo de rede, o(s) dispositivo(s) eletrônico(s) que executa(m) o plano de controle centralizado 2276, e, assim, o controlador de rede 2278 que inclui o módulo centralizado de informações de alcance e encaminhamento 2279, pode ser implantado uma diversidade de modos (por exemplo, um dispositivo de propósito especial, um dispositivo de propósito geral (por exemplo, COTS) ou um dispositivo híbrido). Esses dispositivos eletrônicos incluiriam, de modo similar, recursos de computação, ou um conjunto ou um ou mais NICs físicos, e um meio de armazenamento legível por máquina não transitório que tem armazenado e si o software de plano de controle centralizado. Por exemplo, a Figura 23 ilustra um dispositivo de plano de controle de propósito geral 2304 que inclui um hardware 2340 que compreende um conjunto de um ou mais processador(es) 2342 (que são frequentemente processadores de COTS) e controlador(es) de interface de rede 2344 (NICs; também conhecidos como cartões de interface de rede) (que incluem NIs físicas 2346), assim como meios de armazenamento legíveis por máquina não transitórios 2348 que têm, armazenado nos mesmos, um software de plano de controle (CCP) centralizado 2350. O dispositivo de plano de controle 2304 pode ser um dentre diversos tais dispositivos juntos em rede para formar um sistema de computação em nuvem ou um sistema similar, conforme descrito no presente documento acima, e, em particular, para implantar o plano de controle de um PC de 3G.

[00186] Em modalidades que usam virtualização de computador, o(s) processador(es) 2342 tipicamente executam software para criar uma instância de hipervisor 2354 (às vezes referido como um monitor de máquina virtual (VMM)) e uma ou mais máquinas virtuais 2362A-R que são are executadas pelo hipervisor 2354; que são coletivamente referidas como ocorrência(s) de software 2352. Uma máquina virtual é uma implantação de software de uma máquina física que executa programas como se estivessem sendo executados em uma máquina física não virtualizada; e os aplicativos em geral não estão cientes que os mesmos estão sendo executados em uma máquina virtual em oposição a serem executados em um dispositivo eletrônico que hospeda “bare metal”, embora alguns sistemas forneçam para-virtualização que permite que um sistema operacional ou aplicativo esteja ciente da presença de virtualização para propósitos de otimização. Novamente, em modalidades em que a virtualização de computador é usada, durante a operação uma ocorrência do software de CCP 2350 (ilustrado como uma ocorrência de CCP 2376A) em cima de um sistema operacional 2364A é tipicamente executada dentro da máquina virtual 2362A. Em modalidades em que a virtualização de computador não é usada, a ocorrência de CCP 2376A em cima do sistema operacional 2364A é executada no dispositivo de plano de controle de propósito geral de “bare metal” 2304.

[00187] O sistema operacional 2364A fornece as capacidades de processamento, entrada/saída (I/O) e de rede básicas. Em algumas modalidades, a ocorrência de CCP 2376A inclui uma ocorrência de controlador de rede 2378. A ocorrência de controlador de rede 2378 inclui uma ocorrência de módulo de informações de alcance e encaminhamento centralizada 2379 (que é uma camada de middleware que fornece o contexto do controlador de rede 2278 ao sistema operacional 2364A e se comunica com vários NEs), e uma camada de aplicativo de CCP 2380 (às vezes referida como uma camada de aplicativo) sobre a camada de middleware (que fornece a inteligência exigida para várias operações de rede, tais como protocolos, reconhecimento situacional de rede e interfaces de usuário). Em um nível mais abstrato, essa camada de aplicativo de CCP 2380 dentro do plano de controle centralizado 2276 trabalha com exibição (ou exibições) de rede virtual (exibição (ou exibições) lógicas da rede) e a camada de middleware fornece a conversão das redes virtuais par a exibição física.

[00188] Em uma modalidade, qualquer número ou combinação dos módulos do plano de controle 2381 que implante as funções do plano de controle do PC de 3G pode ser executada por uma máquina virtual 2362A como parte de uma ocorrência de plano de controle centralizado (CCP) 2376A (do software de CCP) ou em uma configuração virtualizada similar. Os módulos do plano de controle 2381 podem incluir os AUC, HLR, HSS, SGSN-C, GGSN-C ou módulos do plano de controle 2381 similares do PC de 3G. Os módulos do plano de controle 2381 de um PC de 3G específico podem ser executados pela mesma máquina virtual 2362A ou distribuídos ao longo de qualquer número de máquinas virtuais e ao longo de qualquer número de dispositivos de plano de controle 2304. Essa distribuição pode ser dinâmica para permitir o balanceamento de carga e um gerenciamento de recurso semelhante dentro de um sistema de computação em nuvem. Em uma modalidade, os módulos do plano de controle 2381 podem fazer parte da camada de aplicativo de CCP 2381 de uma ocorrência de controlador de rede 778.

[00189] O plano de controle centralizado 2276 transmite mensagens relevantes ao plano de dados 2280 com base em cálculos de camada de aplicativo de CCP 2380 e mapeamento de camada de middleware para cada fluxo. Um fluxo pode ser definido como um conjunto de pacotes cujos cabeçalhos se equiparam a um determinado padrão de bits; nesse sentido, o encaminhamento de IP tradicional também é um encaminhamento à base de fluxo em que os fluxos são definidos pelo endereço de destino de IP por exemplo; entretanto, em outras implantações, o determinado padrão de bits usado para uma definição de fluxo pode incluir mais campos (por exemplo, 10 ou mais) nos cabeçalhos de pacote. Diferentes NDs/NEs/VNEs do plano de dados 2280 podem receber diferentes mensagens e, portanto, diferentes informações de encaminhamento. O plano de dados 2280 processa essas mensagens e programa as informações de fluxo e ações correspondentes adequadas nas tabelas de encaminhamento (à vezes referidas como tabelas de fluxo) dos NE/VNEs adequados e, então, os NEs/VNEs mapeiam os pacotes de entrada para fluxo representados nas tabelas de encaminhamento e encaminha os pacotes com base nas correspondências nas tabelas de encaminhamento.

[00190] Padrões, tais como OpenFlow, definem os protocolos usados para as mensagens, assim como um modelo para processar os pacotes. O modelo para processar os pacotes inclui análise de cabeçalho, classificação de pacote e a realização de decisões de encaminhamento. A análise de cabeçalho descreve como interpretar um pacote com base em um conjunto de protocolos bem conhecido. Alguns campos de protocolo são usados para construir uma estrutura de correspondência (ou chave) que será usada na classificação de pacote (por exemplo, um primeiro campo chave pode ser um endereço de controle de acesso de mídia (MAC) de fonte, e um segundo campo chave pode ser um endereço MAC de destino).

[00191] A classificação de pacote envolve executar uma pesquisa na memória para classificar o pacote através da determinação de qual entrada (também referida como uma entrada de tabela de encaminhamento ou entrada de fluxo) nas tabelas de encaminhamento melhor corresponde ao pacote com base na estrutura de correspondência, ou chave, das entradas da tabela de encaminhamento. É possível que muitos fluxos representados nas entradas da tabela de encaminhamento possam corresponder/se equiparar a um pacote; nesse caso, o sistema é tipicamente configurado para determinar uma entrada de tabela de encaminhamento dentre as diversas, de acordo com um esquema definido (por exemplo, selecionar uma primeira entrada de tabela de encaminhamento que foi equiparada). As entradas de tabela de encaminhamento incluem tanto um conjunto específico de critérios de correspondência (um conjunto de valores ou curingas ou uma indicação de quais porções de um pacote devem ser comparadas a um valor/valores/curingas específicos, conforme definido pelas capacidades de correspondência - para campos específicos no cabeçalho de pacote, ou para algum outro conteúdo de pacote), quanto um conjunto de uma ou mais ações para que o plano de dados realize ao receber um pacote correspondente. Por exemplo, uma ação pode ser realizar o push de um cabeçalho no pacote, para o pacote com o uso de uma porta específica, para inundar o pacote, ou simplesmente liberar o pacote. Dessa forma, uma entrada de tabela de encaminhamento para os pacotes de IPv4/IPv6 com uma porta de destino de protocolo de controle de transmissão (TCP) específica pode conter uma ação que especifica que esses pacotes podem ser liberados.

[00192] A realização de decisões de encaminhamento e a execução de ações ocorrem, com base na entrada de tabela de encaminhamento identificada durante a classificação de pacote, executando-se o conjunto de ações identificado na entrada de tabela de encaminhamento correspondente no pacote.

[00193] Entretanto, quando um pacote desconhecido (por exemplo, um “pacote perdido” ou uma “não correspondência” conforme usado na linguagem de OpenFlow) chega no plano de dados 2280, o pacote (ou um subconjunto do cabeçalho e conteúdo de pacote) é tipicamente encaminhado ao plano de controle centralizado 2276. O plano de controle centralizado 2276 irá, então, programar as entradas da tabela de encaminhamento no plano de dados 2280 para acomodar os pacotes que pertencem ao fluxo do pacote desconhecido. Uma vez que uma entrada de tabela de encaminhamento específica foi programada no plano de dados 2280 pelo plano de controle centralizado 2276, o próximo pacote com credenciais de correspondência irá se equiparar a essa entrada de tabela de encaminhamento e realizar o conjunto de ações associado àquela entrada equiparada.

[00194] Uma interface de rede (NI) pode ser física ou virtual; e, no contexto de IP, um endereço de interface é um endereço de IP designado a uma NI, seja a mesma uma NI física ou uma NI virtual. Uma NI virtual pode ser associada a uma NI física, com outra interface virtual, ou pode estar sozinha (por exemplo, uma interface de loopback, uma interface de protocolo de ponto a ponto). Uma NI (física ou virtual) pode ser numerada (uma NI com um endereço de IP) ou não numerada (uma NI sem um endereço de IP). Uma interface de loopback (e seu endereço de loopback) é um tipo específico de NI virtual (e endereço de IP) de uma NE/VNE (física ou virtual) usado frequentemente para propósitos de gerenciamento; em que tal endereço de IP é referido como o endereço de loopback de nó. O(s) endereço(s) de IP designados às NI(s) de um ND são referidos como os endereços de IP daquele ND; em um nível mais detalhado, o(s) endereço(s) de IP designados às NI(s) designadas a uma NE/VNE implantada em um ND podem ser referidos como os endereços de IP daquela NE/VNE.

[00195] A seleção de próximo salto pelo sistema de direcionamento para um determinado destino pode determinar uma trajetória (ou seja, um protocolo de direcionamento pode gerar um próximo salto em uma trajetória mais curta); mas, se o sistema de direcionamento determinar que há múltiplos próximos saltos viáveis (ou seja, a solução de encaminhamento gerada pelo protocolo de direcionamento oferece mais que um próximo salto em uma trajetória mais curta - múltiplos próximos saltos de mesmo custo), alguns critérios adicionais são usados - por exemplo, em uma rede sem conexão, múltiplas trajetórias de custo igual (ECMP) (também conhecida como trajetórias múltiplas de custo igual, encaminhamento com múltiplas trajetórias e múltiplas trajetórias de IP) (RFC 2991 e 2992) pode ser usada (por exemplo, implantações típicas usam como critérios os campos de cabeçalho específicos para assegurar que os pacotes de um fluxo de pacote específico sejam sempre encaminhados no mesmo próximo salto para preservar a disposição de fluxo de pacote). Para propósitos de encaminhamento com múltiplas trajetórias, um fluxo de pacote é definido com um conjunto de pacotes que compartilham uma restrição de disposição. Como um exemplo, o conjunto de pacotes in em uma sequência de transferência TCP específica precisa chegar em ordem, se não a lógica de TCP irá interpretar a entrega fora de ordem como congestão e diminuirá a taxa de transferência de TCP.

[00196] Embora a invenção tenha sido descrita em termos de algumas modalidades, os indivíduos versados na técnica reconheceram que a invenção não é limitada às modalidades descritas, pode ser praticada com modificações e alterações que estejam dentro do espírito e escopo das reivindicações em anexo. A descrição deve ser considerada, portanto, como ilustrativa em vez de limitadora.

Claims (8)

1. Dispositivo de plano de controle (2304) em um sistema de computação em nuvem para executar uma pluralidade de máquinas virtuais para implantar virtualização de função de rede, NFV, o dispositivo de plano de controle (2304) operável para gerenciar a implantação de um protocolo de túnel, GTP, de serviço de rádio de pacote geral, GPRS, em um núcleo de pacote, PC, de terceira geração, rede de 3G, tendo um plano de controle do PC da rede de 3G, onde o plano de controle está no sistema de computação em nuvem, o plano de controle operável para se comunicar com um plano de dados do PC através de um protocolo de plano de controle, o plano de dados implantado em uma pluralidade de dispositivos de rede da rede de 3G, o dispositivo de plano de controle (2304) e a pluralidade de máquinas virtuais operáveis para se comunicarem com outros dispositivos de plano de controle (2304) no sistema de computação em nuvem e com a pluralidade de dispositivos de rede do plano de dados, o dispositivo de plano de controle (2304) caracterizado pelo fato de que compreende: um meio de armazenamento (2348) para armazenar umas instruções executáveis de plano de controle centralizado, CCP, (2350) que inclui os módulos do plano de controle para implantar o plano de controle do PC; em que módulos do plano de controle são distribuídos de modo dinâmico sobre uma pluralidade de máquinas virtuais e sobre uma pluralidade dos outros dispositivos de plano de controle (2304); e um processador (2342) acoplado de modo comunicativo ao meio de armazenamento (2348), o processador (2342) operável para executar a pluralidade de máquinas virtuais, em que pelo menos uma dentre a pluralidade de máquinas virtuais é operável para executar as instruções executáveis CCP (2350) que inclui pelo menos um dos módulos do plano de controle, cada módulo do plano de controle para fornecer um conjunto de funções de plano de controle para gerenciar o plano de dados, as instruções executáveis de CCP (2350) operáveis para receber uma solicitação para criar o túnel de GTP no PC da rede de 3G entre um nó de suporte de GPRS de serviço, SGSN, e um nó de suporte de GPRS de porta de comunicação, GGSN, para uma sessão de assinante, as instruções executáveis de CCP (2350) operáveis para configurar uma implantação de comutador de um plano de dados do SGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e para estabelecer um primeiro ponto de extremidade do túnel de GTP, as instruções executáveis de CCP (2350) operáveis para configurar pelo menos um comutador em uma rota do túnel de GTP, por meio do protocolo de plano de controle, para encaminhar os pacotes da sessão de assinante de acordo com o túnel de GTP, e as instruções executáveis de CCP (2350) operáveis para configurar uma implantação de comutador de um plano de dados do GGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e para estabelecer um segundo ponto de extremidade do túnel de GTP.

2. Dispositivo de plano de controle (2304), de acordo com a reivindicação 1, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para receber a solicitação para criar o túnel de GTP como uma solicitação de criação de contexto de pacote de dados de protocolo, PDP, a partir de um componente do plano de controle do SGSN.

3. Dispositivo de plano de controle (2304), de acordo com a reivindicação 1, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para receber a solicitação para criar o túnel de GTP como uma solicitação de atualização de direcionamento de GTP a partir de um componente do plano de controle do GGSN.

4. Dispositivo de plano de controle (2304), de acordo com a reivindicação 1, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para receber uma solicitação para modificar o túnel de GTP no PC da rede de 3G entre o SGSN e o GGSN para a sessão de assinante, as instruções executáveis de CCP (2350) operáveis para modificar a configuração da implantação de comutador do plano de dados do SGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e para modificar o primeiro ponto de extremidade do túnel de GTP, e as instruções executáveis de CCP (2350) são operáveis para modificar a configuração da implantação de comutador do plano de dados do GGSN, por meio do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e para modificar o segundo ponto de extremidade do túnel de GTP.

5. Dispositivo de plano de controle (2304), de acordo com a reivindicação 4, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para remover a configuração do pelo menos um comutador na rota do túnel de GTP, por meio do protocolo de plano de controle, e para terminar o encaminhamento dos pacotes da sessão de assinante de acordo com o túnel de GTP.

6. Dispositivo de plano de controle (2304), de acordo com a reivindicação 5, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para configurar um comutador em uma nova rota do túnel de GTP, por meio do protocolo de plano de controle, para encaminhar os pacotes da sessão de assinante de acordo com o túnel de GTP.

7. Dispositivo de plano de controle (2304), de acordo com a reivindicação 1, caracterizado pelo fato de que o processador (2342) é operável para executar as instruções executáveis de CCP (2350) para receber uma solicitação para eliminar o túnel de GTP no PC da rede de 3G entre o SGSN e o GGSN para a sessão de assinante, para remover a configuração da implantação de comutador do plano de dados do SGSN, por meio do protocolo de plano de controle, para terminar o encapsulamento e o desencapsulamento de pacotes da sessão de assinante e para remover o primeiro ponto de extremidade do túnel de GTP, e para remover a configuração da implantação de comutador do plano de dados do GGSN, por meio do protocolo de plano de controle, para terminar o encapsulamento e o desencapsulamento dos pacotes da sessão de assinante e para remover o segundo ponto de extremidade do túnel de GTP.

8. Dispositivo de plano de controle (2304), de acordo com a reivindicação 1, caracterizado pelo fato de que o protocolo de plano de controle é um protocolo OpenFlow.

Images