BR112014012931A2 - interfaces para gerenciar trocas de tráfego de rede diretas - Google Patents

interfaces para gerenciar trocas de tráfego de rede diretas Download PDF

Info

Publication number
BR112014012931A2
BR112014012931A2 BR112014012931-2A BR112014012931A BR112014012931A2 BR 112014012931 A2 BR112014012931 A2 BR 112014012931A2 BR 112014012931 A BR112014012931 A BR 112014012931A BR 112014012931 A2 BR112014012931 A2 BR 112014012931A2
Authority
BR
Brazil
Prior art keywords
connectivity
network
client
customer
request
Prior art date
Application number
BR112014012931-2A
Other languages
English (en)
Other versions
BR112014012931B1 (pt
Inventor
Kevin Christopher Miller
Andrew J. Doane
Mahmoud A. Abuelela
Michael B. Furr
David B. Lennon
Anish Sukumaran
Jeremy T. Hall
Original Assignee
Amazon Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/306,775 external-priority patent/US8724642B2/en
Priority claimed from US13/335,465 external-priority patent/US10015083B2/en
Priority claimed from US13/335,490 external-priority patent/US8495199B2/en
Application filed by Amazon Technologies, Inc. filed Critical Amazon Technologies, Inc.
Publication of BR112014012931A2 publication Critical patent/BR112014012931A2/pt
Publication of BR112014012931B1 publication Critical patent/BR112014012931B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051Service on demand, e.g. definition and deployment of services in real time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5077Network service management, e.g. ensuring proper service fulfilment according to agreements wherein the managed service relates to simple transport services, i.e. providing only network infrastructure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath

Abstract

INTERFACES PARA GERENCIAR TROCAS DE TRÁFEGO DE REDE DIRETAS. Métodos e aparelhos para interfaces para gerenciar trocas de tráfego de re-de diretas. Um sistema pode incluir um centro de dados, roteadores de ponto de extremidade e um coordenador de conectividade. O coordenador implementa uma interface de programática que define as operações de conectividade. O coordenador recebe uma solicitação para a conectividade dedicada para os recursos do centro de dados, formatados de acordo com a interface. O coordenador seleciona um roteador de ponto de extremidade de destino no qual se deseja estabelecer um link físico para implementar a conectividade dedicada, e transmite uma resposta, identificando o roteador de ponto de extremidade de destino e incluindo instruções de configuração para configurar um link físico para a conectividade dedicada.

Description

“INTERFACES PARA GERENCIAR TROCAS DE TRÁFEGO DE REDE DIRETAS” FUNDAMENTOS
[0001] Muitas empresas e outras organizações operam redes de computado- res que interconectam inúmeros sistemas computacionais para suportar suas opera- ções e os serviços que fornecem aos seus consumidores finais distribuídos em todo o mundo. Por exemplo, os centros de dados que abrigam números significativos de sistemas computacionais interconectados tornaram-se comuns, tais como centros de dados privados que são operados por e em nome de uma única organização, e cen- tros de dados públicos que são operados por entidades como empresas para forne- cer recursos de computação para os consumidores. Em muitos casos, os provedores configuram grandes redes que podem logicamente abranger várias regiões ou mes- mo países e podem incluir inúmeros centros de dados com níveis variáveis de servi- ços e instalações disponíveis, utilizados juntos para fornecer um conjunto unificado de serviços aos seus consumidores finais.
[0002] Em alguns centros de dados que foram configurados para fornecer instalações de computação e/ou de armazenamento para clientes remotos, o conjun- to de recursos computacionais, no centro de dados, pode ser dinamicamente dividi- do em pools de recursos, com cada pool estando disponível para uso exclusivo por um determinado cliente por períodos de tempo designados. Há um número de alter- nativas disponíveis para como os clientes dessas instalações estabelecem a conec- tividade de rede aos pools de recursos que foram designados para seu uso. As soli- citações do consumidor podem se originar de uma ampla variedade de dispositivos - computadores pessoais tipo desktop, laptops, servidores de cliente-escritório, ta- blets, smartphones e similares. Esses dispositivos podem usar quaisquer links de rede de longa duração (por exemplo, usando uma rede de escritórios do cliente com uma conexão de T1) para se comunicar com sua rede privada próxima e/ou a Inter-
net pública, ou eles podem ter conectividade transitória (por exemplo, no caso onde o consumidor usa um telefone smartphone). As redes próximas às quais os disposi- tivos do consumidor estão conectados diretamente podem, por sua vez, solicitar a rota do tráfego para centros de dados da rede do provedor ao longo de uma ampla variedade de caminhos. Esses caminhos, em muitos casos, podem ter característi- cas de desempenho, confiabilidade e segurança um pouco imprevisíveis.
[0003] Para alguns tipos casuais de solicitações de serviço, tal como uma solicitação de um consumidor para ler um artigo recente de um provedor de notícias baseado na web, uma variação razoável na capacidade de resposta e uma conexão que cai ocasionalmente podem ser aceitáveis. No entanto, para muitas transmissões de dados relacionadas a negócios, tal como serviços de cotação de ações e serviços de ordem de compra de ações fornecidos pelos comerciantes de ações online, ou para implantações de pacote de software de alta largura de banda que se origina em um centro de desenvolvimento de software, podem existir necessidades mais rigoro- sas de desempenho, confiabilidade e segurança. Nesses ambientes, um consumidor de rede do provedor pode necessitar de um maior nível de isolamento e controle de rede do que os que estão geralmente disponíveis através da Internet pública. Por exemplo, o cliente pode desejar estabelecer, se possível, links de rede física dedica- dos entre a rede própria do consumidor e a rede do provedor, tal que o único tráfego transmitido por esses links é o tráfego gerado em nome do consumidor e em con- formidade com as políticas estabelecidas pelo consumidor. Além disso, para atender as necessidades de negócios que mudam rapidamente, os consumidores podem querer a capacidade de habilitar e desabilitar esses links dedicados dinamicamente e com um mínimo de esforço e atraso.
BREVE DESCRIÇÃO DAS FIGURAS
[0004] A Figura 1 ilustra um sistema de exemplo, de acordo com pelo menos algumas modalidades.
[0005] A Figura 2 fornece uma vista geral de alto nível das etapas que po- dem ser tomadas com a ajuda dos serviços fornecidos por um coordenador de co- nectividade para estabelecer a conectividade dedicada entre uma rede do cliente e uma coleção de recursos, de acordo com pelo menos algumas modalidades.
[0006] A Figura 3 ilustra um exemplo de elementos constituintes de uma so- licitação para a conectividade dedicada a partir de um cliente, de acordo com pelo menos algumas modalidades.
[0007] A Figura 4 ilustra um exemplo de elementos constituintes de uma resposta a uma solicitação de conectividade dedicada, de acordo com pelo menos algumas modalidades.
[0008] A Figura 5 ilustra um exemplo de elementos constituintes de uma so- licitação para um caminho de rede isolada logicamente, de acordo com pelo menos algumas modalidades.
[0009] A Figura 6 ilustra um exemplo dos conteúdos de uma mensagem de confirmação indicando que a conectividade solicitada foi estabelecida, de acordo com pelo menos algumas modalidades.
[0010] A Figura 7 ilustra um exemplo de dois caminhos de rede isolada logi- camente que compartilham um link físico estabelecido usando uma interface forneci- da por um coordenador de conectividade, de acordo com pelo menos algumas mo- dalidades.
[0011] A Figura 8 é uma ilustração de uma porção de uma interface baseada na web exemplar que pode ser fornecida pelo coordenador de conectividade, de acordo com pelo menos algumas modalidades.
[0012] A Figura 9 é um fluxograma de um método para o fornecimento de serviços relacionados à conectividade, de acordo com pelo menos algumas modali- dades.
[0013] A Figura 10 é um fluxograma de um método para o fornecimento de serviços relacionados à conectividade, incluindo orientação sobre a configuração de um dispositivo de rede do cliente, de acordo com pelo menos algumas modalidades.
[0014] A Figura 11 ilustra um exemplo de um sistema incluindo uma rede do provedor à qual pode ser fornecida conectividade a partir de redes do cliente através de provedores de conectividade de "last mile" ("última milha"), de acordo com pelo menos algumas modalidades.
[0015] A Figura 12 ilustra um exemplo de elementos constituintes de uma solicitação para a conectividade dedicada através de um provedor de conectividade, de acordo com pelo menos algumas modalidades.
[0016] A Figura 13 ilustra um exemplo de elementos constituintes de uma resposta a uma solicitação de conectividade dedicada que inclui informações sobre provedores de conectividade disponíveis, de acordo com pelo menos algumas mo- dalidades.
[0017] A Figura 14 ilustra uma comunicação de exemplo a partir de um clien- te identificando um provedor de conectividade selecionado, de acordo com pelo me- nos algumas modalidades.
[0018] A Figura 15 ilustra as comunicações de exemplo a partir de um coor- denador de conectividade para um provedor de conectividade e um cliente após o cliente ter selecionado o provedor de conectividade, de acordo com uma modalida- de.
[0019] A Figura 16 é uma ilustração de uma porção de uma interface basea- da na web exemplar que pode ser fornecida para iniciar a seleção do provedor de conectividade, de acordo com algumas modalidades.
[0020] A Figura 17 é um fluxograma de um método para permitir que os cli- entes selecionem provedores de conectividade, de acordo com pelo menos algumas modalidades.
[0021] A Figura 18 é um fluxograma de um método para o fornecimento de serviços dinâmicos relacionados à conectividade, de acordo com pelo menos algu- mas modalidades.
[0022] A Figura 19 é um fluxograma de um método que compreende a res- posta dinâmica aos níveis de tráfego variáveis, de acordo com pelo menos algumas modalidades.
[0023] A Figura 20 é um diagrama de bloco ilustrando um sistema computa- cional de exemplo que pode ser usado em algumas modalidades.
[0024] Embora as modalidades sejam descritas neste documento à título de exemplo, para várias modalidades e figuras ilustrativas, aqueles versados na técnica reconhecerão que as modalidades não estão limitadas às modalidades ou figuras descritas. Deve ser entendido que as figuras e a descrição detalhada nele não se destinam a limitar as modalidades ao modo específico divulgado, mas pelo contrário, a intenção é cobrir todas as modificações, equivalentes e alternativas que estejam dentro do espírito e do escopo, conforme definido pelas reivindicações anexas. Os títulos usados neste documento são apenas para fins organizacionais e não se des- tinam a serem usados para limitar o escopo da descrição ou das reivindicações.
Conforme usado em todo o pedido, a palavra "pode" é usada num sentido permissi- vo (isto é, que significa ter o potencial para), ao invés do sentido obrigatório (isto é, que significa deve). De forma semelhante, as palavras "incluir", "incluindo" e "inclui" significam incluindo, mas não limitado a.
DESCRIÇÃO DETALHADA DAS MODALIDADES
[0025] Várias modalidades dos métodos e aparelhos para o uso de interfa- ces, tais como interfaces de programação de aplicativos (APIs) para gerenciar a co- nectividade de rede dedicada entre as redes do consumidor e as redes do provedor, são descritas. As redes configuradas por uma entidade, tal como uma empresa ou uma organização do setor público para fornecer um ou mais serviços acessíveis através da Internet (tais como vários tipos de computação ou armazenamento base-
ado em nuvem) para um conjunto distribuído de clientes, podem ser denominadas redes do provedor neste documento. Essa rede de provedor pode incluir inúmeros centros de dados que hospedam vários pools de recursos, tais como coleções de servidores de computadores, dispositivos de armazenamento, equipamento de rede e similares, necessários para implementar e distribuir os serviços oferecidos pelo provedor.
[0026] A fim de estender as áreas geográficas sobre as quais seus serviços podem ser acessados com níveis desejados de desempenho, confiabilidade e segu- rança, um operador de uma rede de provedor pode estabelecer caminhos de rede privada dedicada entre seus centros de dados e um ou mais roteadores que estão fisicamente localizados em uma instalação remota dos centros de dados. As instala- ções nas quais esses roteadores estão alojados são denominadas "instalações de colocalização de roteador" neste documento, uma vez que eles podem às vezes abrigar roteadores e outros equipamentos de rede próprios e/ou gerenciados por entidades comerciais diferentes do operador da rede do provedor, tal como por pro- vedores de serviço de rede independentes ou pelos próprios clientes. Os roteadores próprios ou gerenciados por, ou em nome do operador de rede do provedor nas ins- talações de colocalização do roteador são chamados de roteadores de "ponto de extremidade" neste documento, uma vez que podem representar os pontos mais distantes aos quais se estende o controle da rede ou a posse dos equipamentos da rede. Por exemplo, apenas o tráfego que passou através de um dispositivo próprio ou gerenciado pelo operador da rede do provedor e, portanto, está em conformidade com as políticas definidas pelo operador da rede do provedor, pode ser permitido nos caminhos privados entre os roteadores de ponto de extremidade e outros com- ponentes de rede do provedor. Em algumas modalidades, um ou mais outros rotea- dores nas instalações de colocalização do roteador podem ser parte de uma rede do cliente - isto é, esses roteadores próprios e/ou gerenciados por, ou em nome dos clientes, ou os outros roteadores podem ter conectividade privada aos sistemas nos quais os clientes da rede do provedor geram solicitações de serviço para a rede do provedor. Esses outros roteadores são denominados roteadores "client-side" ("lado do cliente") neste documento.
[0027] A fim de facilitar o gerenciamento da conectividade de rede entre as redes do cliente e a rede do provedor, em algumas modalidades, um coordenador de conectividade responsável pela implementação de uma ou mais interfaces pro- gramáticas, através das quais as solicitações relacionadas à conectividade dos clien- tes são manipuladas, podem ser configuradas. Uma variedade de diferentes tipos de solicitações relacionadas à conectividade, tais como solicitações para descobrir os tipos de opções de conectividade que podem ser acessíveis, solicitações para sele- cionar uma opção de conectividade particular ou serviço, solicitações para configurar ou desmontar um link físico, e similares, pode estar disponível através da interface em diferentes implementações. A interface pode ser exposta ao cliente de muitas formas diferentes em várias modalidades: por exemplo, como uma API, através de uma interface gráfica do usuário, uma página da web ou web site, ou mesmo como uma coleção de comandos que podem ser emitidos a partir do prompt de linha de comando de um sistema computacional.
[0028] Em uma modalidade, uma ou mais coleções ou pools de recursos em um centro de dados pode ser alocado para uso por um cliente particular, isto é, para implementar a funcionalidade necessária para satisfazer os serviços solicitados a partir dos dispositivos da rede do cliente. Nessa modalidade, um coordenador de conectividade pode ser operável para receber uma solicitação para estabelecer a conectividade dedicada a partir de um cliente para um ou mais dos pools de recur- sos. A solicitação de conectividade pode ser gerada ou formatada para se adaptar à interface implementada pelo coordenador de conectividade - por exemplo, ela pode ser recebida através da submissão de um formulário com base na web, em um caso onde a interface é apresentada ao cliente como um conjunto de páginas da web. Em resposta à solicitação de conectividade dedicada, o coordenador de conectividade pode selecionar um roteador de ponto de extremidade específico dentre o conjunto de roteadores de ponto de extremidade da rede do provedor, assim como o roteador de destino a partir do qual a conectividade dedicada deve ser fornecida ao cliente solicitante. Por exemplo, o roteador de destino pode ser selecionado a partir de rote- adores de ponto de extremidade disponíveis em uma instalação de colocalização de roteador geograficamente mais próxima ao estabelecimento do cliente, no qual o cliente tem acesso a um roteador de lado do cliente existente. Em algumas imple- mentações, a interface pode permitir que o cliente especifique vários detalhes na solicitação que podem ajudar o coordenador de conectividade a escolher um rotea- dor de ponto de extremidade de destino apropriado, como um ou mais nomes e/ou endereços de instalações de colocalização do roteador, uma largura de banda dese- jada, faixas de preço desejada e similares.
[0029] Tendo selecionado o roteador de ponto de extremidade de destino, o coordenador de conectividade pode gerar instruções de configuração para um ou mais links de rede física a serem estabelecidos para fornecer a conectividade dedi- cada desejada e transmitir as instruções de volta para o cliente em resposta à solici- tação do cliente. A resposta também pode ser gerada para se adaptar à interface implementada pelo provedor de conectividade: por exemplo, em um caso onde uma página da web com um formulário foi usada para a solicitação do cliente, as instru- ções de configuração também podem ser especificadas como uma ou mais páginas da web, ou como links para os documentos acessíveis pelo web site. As instruções de configuração podem, por exemplo, identificar uma localização física do roteador de ponto de extremidade, uma porta física do roteador de ponto de extremidade de destino, o rack no qual está alojado, o tipo de conector necessário para o link físico, e assim por diante. Após o cliente configurar o link da rede física em conformidade com as instruções, o provedor de conectividade, em algumas modalidades, pode verificar que o link foi configurado corretamente e enviar uma mensagem de confir- mação para o cliente, indicando que a conectividade dedicada solicitada foi estabe- lecida.
Ambiente do sistema de exemplo
[0030] A Figura 1 ilustra um ambiente de sistema de exemplo, de acordo com pelo menos algumas modalidades. O sistema 100 pode incluir uma rede de provedor 105 com um ou mais centros de dados 110 mantidos para fornecer servi- ços aos clientes, tais como serviços computacionais em nuvem ou serviços de ar- mazenamento em nuvem. Os centros de dados 110, por sua vez, podem incluir co- leções de recursos, tais como 120A e 120B. Cada coleção de recurso 120 pode in- cluir um conjunto de recursos (por exemplo, servidores de computador, dispositivos de armazenamento, dispositivos de rede, etc.) tais como os recursos 112A na cole- ção de recursos 120A e os recursos 112B na coleção de recursos 120B. O sistema 100 também pode incluir um coordenador de conectividade 114 configurado para fornecer um serviço de conectividade para os clientes, um banco de dados de co- nectividade 115, e uma pluralidade de roteadores de ponto de extremidade, tais co- mo os roteadores de ponto de extremidade 132A e 132B em algumas modalidades.
Os roteadores de ponto de extremidade 132 podem estar ligados às coleções de recurso 120 através de caminhos de rede privada, tais como os caminhos 170A, 170B, 170C e 170D. O uso direto de um caminho de rede privada 170, tal como 170A-170D, pode estar limitado a dispositivos e servidores da rede do provedor, isto é, um pacote de rede só pode ser transmitido fisicamente sobre um link do caminho de rede privada a partir um dispositivo próprio ou gerenciado pelo proprietário da rede do provedor. O termo "caminho", conforme usado neste documento, refere-se amplamente ao conjunto de links e dispositivos atravessados por uma mensagem de rede ou pacote entre um dispositivo de origem e um dispositivo de destino. O conjun-
to de links de um determinado caminho pode, em alguns casos, compreender um único fio, como quando a origem e o destino podem estar ligados diretamente por um cabo físico. Em outros casos, o caminho pode incluir vários links com fio e/ou sem fio e vários dispositivos intermediários, tais como switches, gateways, roteado- res e similares. Os caminhos podem compreender links físicos unidirecionais e/ou bidirecionais.
[0031] Na modalidade ilustrada, duas redes de exemplo do cliente 162A e 162B representando os respectivos clientes da rede do provedor 105 são mostradas.
Cada rede de cliente compreende uma pluralidade de dispositivos do cliente 148 (por exemplo, 148A e 148B) a partir dos quais as solicitações que são finalmente atendidas nas coleções de recurso 120 podem ser geradas. Esses dispositivos do cliente 148 podem incluir uma variedade de sistemas, tais como sistemas de compu- tador desktop ou em rack, laptops, notebooks, tablets, smartphones e similares. Al- guns dispositivos do cliente 148 podem estar alojados nos estabelecimentos do es- critório de dados do cliente, centros de dados do cliente, ou em estabelecimentos na casa do cliente em várias modalidades, e os outros podem ser dispositivos móveis sem nenhuma localização física fixa. No ambiente ilustrado, os dispositivos do clien- te 148 de um cliente específico têm acesso a um roteador do lado do cliente - por exemplo, dispositivos do cliente 148A da rede do cliente 162A estão conectados ao roteador do lado do cliente 142A através do caminho 160A, e os dispositivos do cli- ente 148B da rede do cliente 160B estão conectados ao roteador do lado do cliente 142B através do caminho 160B.
[0032] O roteador do lado do cliente 142A no exemplo mostrado na Figura 1 está alojado em uma instalação de colocalização do roteador 150A, onde o roteador de ponto de extremidade 132A também está presente, e o roteador do lado do clien- te 142B está alojado em uma instalação de colocalização do roteador 150B onde o roteador de ponto de extremidade 132B está alojado. Em geral, um número de dife-
rentes tipos de caminhos para vários componentes do centro de dados 110, tal como o coordenador de conectividade 114 e as coleções de recurso 120, pode estar dis- ponível a partir das redes do cliente 162A em várias modalidades. Por exemplo, um caminho 175 que não inclui o roteador de ponto de extremidade 132A é mostrado na Figura 1 entre os dispositivos do cliente 148A da rede do cliente 162A e o provedor de conectividade 114; esse caminho 175 pode incluir vários roteadores, gateways e dispositivos da Internet pública, por exemplo, que podem ou não fornecer níveis de- sejados de desempenho, disponibilidade, confiabilidade ou outras características de serviço necessárias para alguns dos serviços fornecidos pela rede do provedor 105.
Outros caminhos semelhantes ao 175, mas não ilustrados na Figura 1, também po- dem estar disponíveis para as coleções de recurso 120 a partir dos dispositivos do cliente 148A e/ou 148B.
[0033] O serviço de conectividade fornecido pelo coordenador de conectivi- dade 114 pode incluir um número de técnicas implementadas para ajudar os clientes da rede do provedor a estabelecer e gerenciar os caminhos da rede dedicada desde as redes do cliente 162 às coleções de recurso 120 em várias modalidades. Por exemplo, uma conexão de rede cruzada 191, incluindo um link físico ou cabo entre o roteador do lado do cliente 142B e o roteador de ponto de extremidade 132B, pode ter sido estabelecida com a ajuda de algumas das características do serviço de co- nectividade fornecido pelo coordenador de conectividade 114. O termo conexão de rede cruzada, conforme usado neste documento, refere-se a uma conexão de rede física configurada entre duas redes autônomas. Por exemplo, dentro da Internet, uma rede autônoma pode ser identificada por um identificador de Sistema Autônomo (AS) exclusivo - uma coleção de prefixos de roteamento do Protocolo de Internet (IP) conectados sob o controle de um ou mais operadores de rede que apresenta uma política de roteamento comum, claramente definida para a Internet. Na modalidade ilustrada, o coordenador de conectividade 114 pode ser operável para implementar uma interface que define várias operações de conectividade disponíveis para os cli- entes, incluindo o estabelecimento de conexões de rede cruzada, tal como a cone- xão 191, e o estabelecimento de conexões logicamente isoladas ou caminhos usan- do esses links de rede cruzada. A interface pode ser implementada usando uma va- riedade de abordagens: por exemplo, como uma interface de programação de apli- cativo (API), uma interface baseada na web, outras interfaces gráficas do usuário, ou interfaces de linha de comando, em diferentes modalidades. O coordenador de co- nectividade 114 também pode tornar a interface conhecida aos clientes usando vá- rios mecanismos - por exemplo, uma notificação detalhando a interface pode ser publicada em um ou mais web sites corporativos em uma modalidade. O coordena- dor de conectividade 114 em si pode ser residente fora da rede do provedor 105 em algumas modalidades e, em outras modalidades, pode estar incorporado dentro da rede do provedor 105.
[0034] Usando a interface implementada pelo coordenador de conectividade 114, um cliente pode gerar uma solicitação de conectividade dedicada. O cliente, ao fazer tal pedido, pode indicar que um link de rede física (semelhante à conexão de rede cruzada 191 mostrada na Figura 1) pode ser exclusivamente estabelecido para uma rede do cliente 162A para se comunicar com um ou mais pools de recursos 120, por qualquer uma de uma série de razões, tais como melhor desempenho, mai- or confiabilidade, melhor segurança ou custo mais baixo ou mais previsível. A exi- gência de exclusividade pode indicar que apenas o tráfego para ou a partir de um conjunto ou conjuntos especificados de endereços de rede na rede do cliente deve ser permitido sobre o link de rede física dedicada solicitado. O conjunto ou conjuntos de endereços físicos podem ser identificados e/ou modificados pelo cliente após o link físico ter sido configurado em algumas implementações, isto é, eles não podem ter que ser especificados antes do estabelecimento inicial do link físico. A solicitação pode fornecer qualquer combinação de uma série de detalhes diferentes que podem ser de uso para o provedor de conectividade 114 em várias modalidades - por exemplo, a localização física de um ou mais roteadores de lado do cliente que pode- riam ser usados, uma largura de banda desejada e, ou outras exigências de serviço.
Em algumas implementações, exigências de serviço específicas podem ser forneci- das em solicitações subsequentes após a solicitação inicial para estabelecer que a conectividade física dedicada foi enviada.
[0035] Em resposta ao recebimento dessa solicitação, o coordenador de co- nectividade 114 pode selecionar um roteador de ponto de extremidade específico 132 que pode ser apropriado para atender as exigências do cliente. Por exemplo, o roteador de ponto de extremidade que é fisicamente mais próximo de um ou mais estabelecimentos do cliente, onde se espera que a maioria das solicitações do clien- te sem originem, pode ser escolhido em uma implementação. Tendo selecionado o roteador de ponto de extremidade de destino para fornecer a conectividade dedica- da, o coordenador de conectividade 114 pode gerar uma resposta ou notificação que compreende as instruções de configuração para um link de rede física para ser esta- belecido para o roteador de ponto de extremidade de destino 132 para fornecer pelo menos uma porção da conectividade dedicada desejada. As instruções podem inclu- ir uma variedade de elementos em várias modalidades, incluindo, por exemplo, um número de porta, identificador de rack e similares para identificar o roteador de ponto de extremidade de destino. As instruções também podem ser geradas em conformi- dade com a interface - por exemplo, como os conteúdos de uma página da web em uma implementação onde a solicitação foi recebida como uma submissão do formu- lário baseado na web. Em alguns casos, múltiplas respostas podem ser enviadas pelo coordenador de conectividade - por exemplo, uma combinação de uma ou mais respostas da web para o solicitante, e uma ou mais mensagens de e-mail, algumas das quais podem ser enviadas para outras entidades que não o cliente, tal como o operador da instalação de colocalização do roteador 150. A resposta ou respostas do coordenador de conectividade 114 podem ser usadas para configurar o link físico necessário. O tempo necessário para estabelecer o link físico pode variar ampla- mente, dependendo da capacidade de resposta do cliente, da capacidade de res- posta do operador da instalação de colocalização do roteador 150, e de vários pro- cedimentos que podem ter que ser concluídos para segurança, autorização e simila- res. Após o link de rede física ter sido configurado, o coordenador de conectividade 114 pode, em algumas modalidades, transmitir uma mensagem de confirmação para o cliente, indicando que a conectividade dedicada desejada foi estabelecida. Várias informações relacionadas à conectividade, incluindo, por exemplo, dados que identi- ficam detalhes de links físicos, tais como a conexão de rede cruzada 191, os dados que identificam os clientes para os quais esses links foram estabelecidos, as datas ou horas do estabelecimento da conectividade dedicada e similares, podem ser ar- mazenados em bancos de dados de conectividade 115 em algumas modalidades.
[0036] Além dos caminhos de rede ilustrados na Figura 1, em muitos ambi- entes, pode haver vários outros caminhos de rede alternativos disponíveis entre as redes do cliente 162 e os diversos componentes do sistema 100. Por exemplo, al- gumas solicitações de conectividade podem ser transmitidas para o provedor de co- nectividade 114 ao longo de um caminho que inclui links públicos ou compartilhados, e os diversos serviços fornecidos às coleções de recurso 120 podem ser acessados através de links públicos ou compartilhados também. Em alguns casos, os caminhos alternativos podem servir como backups, no caso de a conectividade ao longo dos caminhos dedicados desejados ser interrompida.
Estabelecimento de conectividade física e lógica
[0037] A Figura 2 fornece uma vista geral de alto nível das etapas que po- dem ser tomadas com a ajuda dos serviços fornecidos por um coordenador de co- nectividade 114 em uma modalidade para estabelecer a conectividade dedicada en- tre uma rede do cliente 162 e uma coleção de recursos 120. Conforme mostrado na entrada marcada 201 na Figura 2, o coordenador de conectividade 114 pode imple- mentar uma interface que define um conjunto de operações relacionadas à conecti- vidade disponíveis para os clientes da rede do provedor 105, para outras entidades (tais como um ou mais servidores administrativos, agentes de medição, agentes de cobrança e similares) e/ou outras partes. O conjunto de operações disponíveis pode incluir, por exemplo, operações de criar, consultar, recuperar, atualizar ou excluir registros de conectividade ou objetos em algumas implementações. As operações disponíveis podem ser expostas através de interfaces de programação de aplicativos (APIs), em qualquer uma de uma variedade de especificações padrão ou linguagens de programação, tais como a Linguagem de Descrição de Serviços Web (WSDL), XML, Java, C, C++, Python, Perl ou seus derivados, em alguns ambientes, onde os clientes podem interagir com o provedor de conectividade programaticamente atra- vés da emissão de chamadas de método, chamadas de função e similares. Em ou- tros ambientes, além ou ao invés de fornecer uma API pública usando o que os cli- entes podem escrever em código, o coordenador de conectividade pode fornecer uma interface de usuário mais amigável, tal como uma coleção de páginas da Web.
Em uma implementação, o coordenador de conectividade pode, por exemplo, publi- car um conjunto de documentos (semelhante ao Javadocs em um caso onde o Java ou uma linguagem de programação Java é usada) que fornece uma lista completa das APIs, e pode expor um subconjunto frequentemente usado de operações relaci- onadas à conectividade através de uma página ou páginas da Web. Nesse ambien- te, um cliente pode optar por usar as páginas da Web para operações comuns e po- de recorrer a programas que invocam as chamadas de API para operações mais complexas ou para operações para as quais uma interface da web não é fornecida pelo coordenador de conectividade 114. Uma interação específica baseada na web com o cliente pode resultar em uma invocação de uma ou mais das APIs interna- mente no coordenador de conectividade 114 em algumas dessas modalidades. Ou-
tros tipos de interfaces, tais como ferramentas de linha de comando, interfaces gráfi- cas de usuário independentemente instaláveis (GUIs) (isto é, GUIs que não depen- dem de páginas da Web e de interações baseadas em HTTP), clientes grossos, cor- reio eletrônico, ou protocolos de mensagens, podem ser usados isoladamente ou em combinação para implementar os serviços fornecidos pelo coordenador de conectivi- dade 114 em várias modalidades. Em alguns casos, a interface pode consistir em múltiplas camadas, onde uma camada de interface pode invocar outra, e uma ou mais das camadas podem ser expostas para as interações diretas do cliente.
[0038] Em uma modalidade, o coordenador de conectividade pode fornecer um "Guia de Iniciação" ou alguma outra documentação semelhante que pode forne- cer exemplos de como a interface pode ser usada. A lista seguinte, com as entradas marcadas como API-1 através de API-18, é um conjunto de exemplos de invocação de chamada de API que pode ser fornecido nessa documentação para um subcon- junto de serviços de conectividade fornecidos pelo coordenador de conectividade
114. [API-1] Customerld customerld = createNewCustomer(CustomerInfo cus- tomerlnfo); A API createNewCustomer pode ser usada para criar uma conta do consu- midor no provedor de conectividade. Ela pode pegar as informações do cliente (por exemplo, nome, endereço, detalhes relacionados ao pagamento) como entrada, e retornar um identificador do cliente. [API-2] ConnectionRequestld requestld = requestDirectConnec- tion(CustomerId customerld, ConnectionSpecification connectionSpecification); A API requestDirectConnection pode ser usada por um cliente para enviar uma solicitação para a conectividade dedicada, com vários detalhes das proprieda- des da conectividade desejada encapsulada em um objeto ConnectionSpecification. [API-3] RequestStatus requestStatus = getConnectionRequestSta-
tus(CustomerID customerld, Requestld requestld);
Um cliente pode usar a API getConnectionRequestStatus para consultar o status atual de uma solicitação de conexão - por exemplo, o provedor de conectivi-
dade pode indicar no objeto RequestStatus retornado que o estado atual está "em andamento", "concluído" ou "rejeitado". [API-4] Connectionld connectionld = getConnectionId(CustomerID custom-
erld, Requestld requestld);
Se um Objeto de Conexão é criado com êxito pelo coordenador de conecti-
vidade (e, por exemplo, armazenado no banco de dados da conectividade 115), um cliente pode usar a API getConnectionld para obter um identificador para esse objeto de conexão. [API-5] Connectionlnfo connectionlnfo = getConnectionInfo(ConnectionId connectionld);
A API getConnectionlnfo pode ser usada para obter as propriedades do obje-
to de conexão, incluindo essas propriedades como a localização física de um rotea-
dor, um número de porta, métricas de uso de tráfego, etc. [API-6] PhysicalConnectionlnfo physicallnfo = getPhysicalConnectionIn-
fo(ConnectionInfo connectionlnfo);
A API getPhysicalConnectionlnfo pode ser usada para extrair as proprieda-
des específicas da localização do objeto de conexão a partir do objeto Connectionln-
fo. [API-7] Authlnfo authlnfo = getAuthInfo(PhysicalConnectionInfo( physical-
Connectionlnfo);
A API getAuthlnfo pode ser usada para extrair informações relacionadas à autorização para a conexão - por exemplo, um documento que permite a um técnico entrar no estabelecimento onde um roteador de ponto de extremidade 132 está alo-
jado, e fazer um link de rede física a um roteador de ponto de extremidade.
[API-8] RequestStatus modificationStatus = modifyConnection(ConnectionId connectionld, Modificationlnfo modificationlnfo); A API modifyConnection pode ser usada para solicitar alterações a uma Co- nexão existente - por exemplo, para solicitar mais largura da banda. [API-9] RequestStatus disableStatus = disableConnection(ConnectionId con- nectionld); A API disableConnection pode ser usada para solicitar que uma conexão existente seja desabilitada, isto é, que nenhum tráfego seja permitido fluir através do link físico previamente configurado para essa conexão.
[API- 10] RequestStatus enableStatus = enableConnection(ConnectionId connectionld); A API enableConnection pode ser usada para solicitar que uma conexão existente (por exemplo, atualmente desabilitada) seja habilitada. [API-11] RequestStatus deleteStatus = deleteConnection(ConnectionId con- nectionld); A API deleteConnection pode ser usada para solicitar que uma conexão seja removida permanentemente. [API-12] LogicalRequestld logicalRequestld = setUpLogicalConnec- tion(ConnectionId connectionld, LogicalConnectionParameters IcParameters); A API setUpLogicalConnection pode ser usada para solicitar que um cami- nho de rede isolada logicamente seja configurado usando uma conexão física previ- amente estabelecida e um conjunto de propriedades de conexão lógica encapsula- das em um objeto LogicalConnectionParameters. [API-13] LogicalConnectionld logicalConnectionld = getLogicalConnec- tionId(LogicalRequestId logicalRequestld); Um cliente pode usar a API getLogicalConnectionId para obter um identifica- dor para uma conexão lógica específica.
[API-14] LogicalConnectionlnfo logicalConnectionlnfo = getLogicalConnec- tionInfo(LogicalConnectionId logicalConnectionld); A API getLogicalConnectionlnfo pode ser usada para obter as propriedades da conexão lógica, incluindo essas propriedades como a identificação VLAN, sendo usada para a conexão lógica, e/ou outras informações relacionadas ao roteamento associado à conexão lógica. [API-15] LogicalConnectionRequestStatus modificationStatus = modifyLogi- calConnection(LogicalConnectionId logicalConnectionld, LogicalConnectionModificationlnfo modificationlnfo); A API modifyLogicalConnection pode ser usada para solicitar alterações em uma conexão lógica existente - por exemplo, para modificar o conjunto de prefixos de rede associado a ela. [API-16] LogicalConnectionRequestStatus disableLogicalConnectionStatus = disableLogicalConnection(LogicalConnectionId connectionld); A API disableLogicalConnection pode ser usada para solicitar que uma co- nexão lógica existente seja desabilitada, isto é, que nenhum tráfego seja permitido fluir através do caminho logicamente isolado associado à conexão lógica.
[API-17] LogicalConnectionRequestStatus enableLogicalConnectionStatus = enableLogicalConnection(LogicalConnectionId connectionld); A API enableLogicalConnection pode ser usada para solicitar que uma co- nexão lógica existente (por exemplo, atualmente desabilitada) seja habilitada. [API-18] LogicalConnectionRequestStatus deleteLogicalConnectionStatus = deleteLogicalConnection(LogicalConnectionId connectionld); A API deleteLogicalConnection pode ser usada para solicitar que uma cone- xão lógica seja removida permanentemente.
[0039] Voltando-se novamente para a Figura 2, a próxima etapa de alto nível ilustrada em 206 é o estabelecimento de uma conta do cliente, a qual pode ser usa-
da, por exemplo, para fins de faturamento. Em algumas modalidades, a interface fornecida pelo coordenador de conectividade 114 pode ser usada (tal como através de uma invocação de uma API createNewCustomer ou através de uma interface da web que, por sua vez, invoca uma API semelhante) para configurar a conta do clien- te. Em outras modalidades, o coordenador de conectividade 114 pode não estar en- volvido na criação da conta diretamente, e algum outro mecanismo (tal como intera- ções com um componente gerenciador de conta não mostrado na Figura 1) pode ser usado para configurar as contas do cliente.
[0040] Um cliente que tem uma conta configurada pode usar a interface im- plementada pelo coordenador de conectividade 114 para primeiro estabelecer um link físico para a conectividade dedicada desejada (entrada 211 na Figura 2), e en- tão estabelecer um ou mais caminhos de rede isolada logicamente que usam esse link físico (entrada 221). Finalmente, a funcionalidade da conectividade dedicada pode ser verificada ou validada (entrada 231), por exemplo, em algumas modalida- des, o cliente e/ou o coordenador de conectividade 114 pode executar uma ou mais operações de verificação e confirmar que a solicitação do cliente tenha sido imple- mentada de forma satisfatória. Cada uma das etapas de alto nível ilustradas nas en- tradas 211, 221 e 231 da Figura 2 pode envolver várias interações e/ou operações na extremidade do cliente e no provedor de conectividade 114, e mais detalhes de cada etapa de alto nível são fornecidos abaixo.
Solicitações e respostas de exemplo para o estabelecimento da conectivida- de
[0041] A Figura 3 ilustra elementos exemplares de uma solicitação 351 para a conectividade dedicada a partir de um cliente, de acordo com uma modalidade.
Conforme mostrado, a solicitação, que pode ser gerada em um dispositivo do cliente 148 e pode ser formatada em conformidade com a interface fornecida para os servi- ços relacionados à conectividade pelo coordenador de conectividade 114, compre-
ende informações de localização 360, exigência de largura de banda 361, exigência de disponibilidade 363, exigência de múltiplos caminhos 365, informações sobre equipamentos de rede do cliente 367, e especificações adicionais 368. Nem todos esses elementos podem estar incluídos em uma solicitação de conectividade; qual- quer combinação ou subconjunto desses e outros elementos pode estar incluído nas solicitações em várias modalidades. Em implementações onde uma API semelhante à API requestDirectConnection descrita acima é usada, alguns ou todos os elemen- tos da solicitação podem ser fornecidos como campos de um objeto ConnectionSpe- cification ou seu equivalente.
[0042] As informações de localização 360 podem incluir detalhes de uma lo- calização física na qual a conectividade dedicada é desejada: por exemplo um ende- reço da rua onde um roteador do lado do cliente 142 existe atualmente ou onde esse roteador do lado do cliente possa precisar ser configurado, por exemplo, com a aju- da de um provedor de serviço de rede de terceiros. Em alguns casos, o cliente pode simplesmente listar uma ou mais cidades ou até mesmo estados onde porções da rede do cliente 162 estão localizadas e solicitar que o coordenador de conectividade 114 forneça um conjunto de sites possíveis onde uma conexão física poderia ser configurada para servir a rede do cliente.
[0043] Em algumas implementações, o cliente pode especificar uma largura de banda desejada para a conectividade dedicada através da exigência de largura de banda 361. A interface fornecida ao cliente pelo provedor de conectividade pode, por exemplo, permitir que o cliente escolha dentre um conjunto discreto de opções de largura de banda, tais como 500 Megabits/segundo, 1 Gigabit/segundo ou 10 Gi- gabits/segundo, onde as opções podem ser derivadas dos detalhes do hardware de rede específico disponível para o estabelecimento de um link físico a um roteador de ponto de extremidade 132. Por exemplo, em algumas instalações de colocalização do roteador, as opções de links físicos podem incluir conexões de fibra monomodo
1Gbps 1000BASE-LX (1310nm) sobre fibra monomodo, e conexões de fibra mono- modo 10Gbps 10GBASE-LR (1310nm) sobre fibra monomodo, e o coordenador de conectividade 114 pode permitir que o cliente escolha entre a opção de 1Gbps e a opção de 10Gbps. Em outros casos, pode ser permitido que o cliente solicite qual- quer largura de banda arbitrária e o coordenador de conectividade 114 pode respon- der à solicitação, indicando que a largura de banda está habilitada ou disposto a for- necer. Em uma implementação, o coordenador de conectividade pode não fornecer quaisquer garantias da disponibilidade da largura de banda e, em vez disso, por exemplo, indicar para o cliente que uma abordagem de melhor esforço será usada - isto é, o coordenador de conectividade irá tentar fornecer o máximo de largura de banda (até o limite desejado pelo cliente) quanto possível. Em outra implementação, o coordenador de conectividade pode indicar que mais de um link físico pode ser necessário - por exemplo, se o cliente solicitar 20Gbps e a máxima largura de banda disponível ao longo de um único cabo for 10Gbps. Também pode ser possível confi- gurar múltiplos links físicos distribuídos ao longo de diferentes instalações de coloca- lização do roteador 132 em resposta a uma única solicitação para a conectividade dedicada - por exemplo, se um cliente específico tem acesso aos roteadores do lado do cliente 142A e 142B nas respectivas instalações 132A e 132B, um ou mais links físicos podem ser configurados em cada instalação, se necessário ou solicitado. A interface fornecida pelo coordenador de conectividade 114 pode permitir que os cli- entes especifiquem se localizações físicas distintas devem ser usadas para fornecer a conectividade desejada e, se em caso afirmativo, quantas localizações devem ser usadas.
[0044] O cliente pode, em algumas modalidades, fornecer também uma exi- gência de disponibilidade 363 e/ou uma exigência de múltiplos caminhos 365. A exi- gência de disponibilidade pode ser expressável em qualquer uma das diversas mé- tricas, tais como limites de interrupção de rede máxima desejados (por exemplo,
uma hora por tempo de interrupção máxima do ano) ou tempo médio entre as inter- rupções. Uma exigência de múltiplos caminhos 365 pode indicar o número de links físicos que deve ser configurado entre um roteador do lado do cliente 142 e um rote- ador de ponto de extremidade 132. Múltiplos links físicos podem, por exemplo, ser solicitados para o desempenho (por exemplo, para que o tráfego a partir da rede do cliente 162 possa ter carga equilibrada ou, de outra forma, ser distribuído ao longo de múltiplos caminhos físicos, reduzindo, desse modo, o congestionamento da rede), para maior disponibilidade (por exemplo, fornecendo múltiplos caminhos, um cami- nho alternativo pode estar disponível como um caminho de backup, em caso de uma falha em um dos links físicos), ou uma combinação de razões de desempenho e de disponibilidade. Além de especificar quantos links físicos são necessários, um cliente também pode especificar o modo como o tráfego deve ser distribuído entre eles. Em um caso onde dois caminhos são solicitados, por exemplo, o cliente pode especificar se eles devem ser estabelecidos de um modo ativo/ativo (por exemplo, onde Múlti- plos Caminhos do Protocolo de Gateway Limite (BGP) são usados para equilibrar a carga entre os dois links e, em caso de falha, um link assume o tráfego do outro), ou no modo ativo/standby, onde apenas um dos links está em uso em um momento, e o segundo link é ativado apenas no caso de uma falha no primeiro link. As opções pa- drão (por exemplo, ativo/ativo) podem ser indicadas através da interface para o cli- ente em algumas implementações, para que o cliente não precise especificar explici- tamente o tipo de configuração de múltiplos caminhos, se o cliente não desejar fazê- lo. Em alguns casos, a indicação de uma exigência de múltiplos caminhos 365 pode negar a necessidade (ou contradizer) de uma exigência de disponibilidade 363, en- tão pode ser permitido que o cliente especifique apenas um desses dois tipos de opções.
[0045] Em uma modalidade, a fim, por exemplo, de simplificar ainda mais as tarefas que o cliente pode precisar fazer para estabelecer a conectividade em sua extremidade, ou para otimizar o desempenho, o coordenador de conectividade 114 também pode ser capaz de fornecer instruções de configuração, sugestões e/ou configurações preferidas para o tipo específico de equipamentos de rede que o cli-
ente possa ter.
Nesse ambiente, um cliente pode fornecer cliente informações de equipamento de rede 367 ao coordenador de conectividade 114, que pode, por exemplo, consultar um banco de dados dos dados de configuração (por exemplo,
banco de dados 115) para procurar por instruções de configuração para o equipa-
mento, e fornecer sugestões ou instruções de configuração para o cliente.
Se um cliente indicar através de informações 367 que deseja usar um tipo ou classe especí-
fico de roteador de um fornecedor específico (por exemplo, um roteador Cisco, um roteador Juniper, ou um roteador Yamaha), por exemplo, o coordenador de conecti-
vidade pode ser capaz de fornecer dicas de configuração específicas do fornecedor para um tipo específico de roteador ou para uma versão específica do software exe-
cutado nesse roteador específico.
Essas dicas podem incluir exemplos de como con-
figurar ou verificar as configurações de BGP, configurações relacionadas ao tunela-
mento, configurações de IKE (Troca de Chave de Internet), e também podem incluir instruções sobre como testar se o dispositivo específico do fornecedor está funcio-
nando de forma eficaz.
Solucionando problemas de dicas e/ou ajustando as dicas,
tal como tamanhos de buffer preferidos e similares, que podem ser específicas do fornecedor e/ou específicas do dispositivo também podem ser fornecidas pelo coor-
denador de conectividade 114 em algumas modalidades.
Uma vez que pelo menos em alguns ambientes, a rede do provedor 105 pode ter um grande número de clien-
tes usando uma ampla variedade de equipamentos de rede, o coordenador de co-
nectividade 114 pode ser capaz de desenvolver uma base de conhecimentos que cobre uma ampla variedade de configurações de equipamentos de rede, os tipos de configurações do lado do cliente que funcionam melhor com o equipamento do pro-
prietário da rede do provedor e assim por diante, o que podem ser muitos clientes úteis que iniciam o processo de ligação de suas redes de cliente 160 à rede do pro- vedor 105. Em algumas implementações, especificações adicionais 368 para a co- nectividade desejada também podem estar incluídas em uma solicitação do cliente - por exemplo, especificações de um momento de início desejado ou momento de término para a conectividade dedicada, ou uma reconhecimento de que uma versão do BGP e/ou Detecção de Encaminhamento Bidirecional (BFD) específicas são su- portadas na rede do cliente 162.
[0046] Em várias modalidades, informações semelhantes àquelas mostradas na Figura 3 podem ser comunicadas em múltiplas etapas para o coordenador de conectividade 114 - por exemplo, as primeiras informações de localização e a largu- ra de banda desejada podem ser comunicadas, em seguida, o coordenador de co- nectividade pode fornecer uma resposta com uma lista de opções possíveis, e então, dentre as opções possíveis, o cliente pode escolher uma opção e fornecer especifi- cações adicionais em mensagens subsequentes. As informações podem ser trans- mitidas para o coordenador de conectividade 114 a partir do cliente (ou de terceiros em nome do cliente), usando qualquer caminho de rede disponível - por exemplo, um caminho 175 que pode incluir porções da internet pública. Algumas ou todas as interações entre o cliente e o coordenador de conectividade 114 podem ser codifica- das em várias modalidades. Em alguns casos onde o cliente não tem atualmente um roteador do lado do cliente já disponível numa instalação de colocalização do rotea- dor apropriada 150, outras interações podem ser necessárias entre o cliente e o co- ordenador de conectividade 114, em que, por exemplo, o coordenador de conectivi- dade fornece sugestões para os provedores de serviços de rede de terceiros que o cliente pode ser capaz de usar para obter acesso a um roteador adequado.
[0047] A Figura 4 ilustra um exemplo de elementos constituintes de uma resposta que pode ser gerada a uma solicitação para a conectividade dedicada a partir de um cliente, de acordo com pelo menos algumas modalidades. O exemplo ilustrado mostra o coordenador de conectividade 114 enviando uma resposta 451 de volta para o dispositivo solicitante do cliente 148, e também uma notificação opcional 452 que pode ser enviada a um operador ou gerente de uma instalação de colocali- zação do roteador 150 em algumas implementações. Tendo examinado os diversos parâmetros ou propriedades da conectividade dedicada solicitada pelo cliente, con- forme ilustrado na Figura 3, o coordenador de conectividade 114 pode eventualmen- te decidir sobre um roteador de ponto de extremidade específico 132 que pode ser apropriado para um link físico para ser configurado à rede do cliente. Por exemplo, na Figura 1, o roteador de ponto de extremidade 132A na instalação de colocaliza- ção do roteador 150A pode ser escolhido para fornecer conectividade física à rede do cliente 162A. A resposta 451 pode incluir qualquer combinação de instruções de configuração de link físico 471, informações de autorização 482, um identificador de conexão 482, e instruções de configuração específicas do dispositivo 483. As instru- ções de configuração de link físico 471 podem, por exemplo, identificar as coorde- nadas físicas exatas, onde um cabo proveniente de um roteador do lado do cliente, tal como o roteador 142A deve ser anexado: uma identificação 467 da porta física (por exemplo, "porta 3" ou "a terceira porta da esquerda"), um identificador de caixa 461, um identificador de rack 463, e um identificador do painel de conexões 465.
[0048] Em muitos casos, equipamentos de rede, tais como os roteadores 132 e 142 estão abrigados em ambientes seguros, onde nem todos podem ter aces- so físico. Nesses casos, as informações de autorização 481, que podem, por exem- plo, compreender um acordo de vinculação legal para permitir que um técnico aces- se o roteador de ponto de extremidade 132A pode ser fornecido ao cliente. Em al- guns ambientes, um documento semelhante ou derivado de um formato de comuni- cação de autorização padrão comumente usado chamado "LOA-CFA" (Carta de Au- toridade e Atribuição de Instalação do Cliente) pode ser usado para informações de autorização 481. As informações de autorização 481, em si, podem incluir as coor-
denadas de link físico, tal como o identificador de porta 467, identificador de caixa 461, identificador de rack 462, e identificador do painel de conexões 465 em alguns casos. A resposta 451 também pode incluir um identificador de conexão 482 corres- pondendo à conectividade dedicada solicitada, que pode ser usada em outras co- municações do cliente para o coordenador de conectividade 114, tais como uma so- licitação de estabelecimento de caminhos logicamente isolados através da API se- tUpLogicalConnection descrita anteriormente e discutida ainda em conjunto com a descrição da Figura 5 abaixo.
[0049] Em algumas modalidades, o coordenador de conectividade 114 tam- bém pode fornecer instruções de configuração 483 para o equipamento de rede do lado do cliente. Essas instruções podem ser fornecidas em casos onde as informa- ções do equipamento de rede do cliente 367 foram fornecidas anteriormente ao co- ordenador de conectividade 114, e também podem ser fornecidas para um conjunto padrão de dispositivos (por exemplo, os tipos mais comumente usados de roteado- res) até mesmo quando o cliente não forneceu detalhes anteriormente do equipa- mento do lado do cliente em algumas implementações. Dependendo as especifici- dades do roteador de ponto de extremidade 132 selecionado para a conexão física, diferentes conjuntos de configurações do lado do cliente podem, em geral, ser apro- priados mesmo para uma determinada peça do equipamento de rede do cliente, e o coordenador de conectividade pode consultar sua base de conhecimento de configu- ração para escolher as instruções apropriadas após o roteador de ponto de extremi- dade 132 ter sido selecionado.
[0050] Conforme descrito anteriormente, a autorização pode ser necessária para configurar a conectividade física para um roteador de ponto de extremidade 132 em alguns ambientes. Em algumas modalidades, as informações de autorização 481 também podem (ou em vez disso) ser enviadas a um operador 433 da instala- ção de colocalização do roteador 150 pelo coordenador de conectividade. Em algu-
mas jurisdições, restrições legais podem impedir essa comunicação direta entre o coordenador de conectividade 114 e os operadores da instalação de colocalização 433, cujo caso as informações de autorização podem, se necessário, ser fornecidas pelo cliente para o operador 433.
[0051] Em muitos casos, um cliente pode estar interessado em usar as cole- ções de recurso 120 para uma variedade de finalidades diferentes - por exemplo, um fornecedor de software pode desejar usar um conjunto de recursos 112A para confi- gurar um ambiente de desenvolvimento e compilação para seus engenheiros de sof- tware, outro conjunto de recursos 112B para uma intranet para armazenar e compar- tilhar informações corporativas internamente dentro da empresa, e um terceiro con- junto de recursos 112C (não mostrado na Figura 1) para um web site que pode ser acessado pelos clientes do fornecedor de software. Conforme um cliente pode dese- jar, por exemplo, para fins administrativos, fins de contabilidade/faturamento, e/ou motivos de segurança, que o tráfego de rede para cada conjunto de recursos 112 seja isolado do tráfego para os outros conjuntos de recursos 112. Por exemplo, o fornecedor de software pode desejar garantir que o tráfego relacionado à compilação seja mantido separado do tráfego da intranet, que o tráfego das máquinas de compi- lação ou recursos 112A não sejam permitidos alcançar um ou mais servidores da intranet 112B, e assim por diante. Ao mesmo tempo, como um cliente pode desejar utilizar a mesma conectividade física dedicada fornecida através de um roteador de ponto de extremidade 132 para todas essas funções diferentes, isto é, o cliente pode desejar estabelecer múltiplos caminhos de rede isolada logicamente em que todos compartilham o mesmo link físico semelhante ao link da rede cruzada 191 estabele- cido para a conectividade dedicada às coleções de recurso 120. Em algumas moda- lidades, a interface configurada pelo coordenador de conectividade 114 pode ser capaz de fornecer suporte para várias operações relacionadas a esses caminhos logicamente isolados, tal como criar, modificar, excluir e recuperar ou consultar o estado dos caminhos.
[0052] A Figura 5 ilustra um exemplo dos elementos constituintes de uma so- licitação de isolamento 551 para um caminho logicamente isolado que pode ser en- viada para o coordenador de conectividade 114, de acordo com pelo menos algu- mas modalidades. Antes de fazer uma solicitação para um caminho de rede logica- mente isolado, um cliente pode ter estabelecido um link físico para obter a conectivi- dade dedicada, conforme ilustrado na etapa de alto nível 211 da Figura 2, e ter obti- do um identificador de conexão 482 durante o processo de estabelecimento do link físico. O identificador de conexão pode estar incluído na solicitação 551 na modali- dade ilustrada. A solicitação 551 também pode compreender vários critérios de sele- ção, tais como qualquer combinação de uma identificação VLAN 501, um BGP ASN 511, um conjunto de prefixos de rede 521, informações de emparelhamento 531, informações de gateway privado virtual 541, e/ou outras informações que podem ser úteis no isolamento de rede em várias modalidades.
[0053] Uma Rede de Área Local Virtual (VLAN) é um método frequentemen- te usado para a criação de múltiplas redes isoladas logicamente dentro de uma úni- ca rede física. Uma identificação ou um identificador chamado de identificação VLAN pode ser inserida no cabeçalho de cada pacote sendo transmitido dentro de um de- terminado ambiente de VLAN para habilitar os switches ou outros dispositivos de rede para identificar a VLAN a qual o pacote pertence. Em uma modalidade, o coor- denador de conectividade 114 pode exigir que o cliente forneça uma única identifica- ção VLAN 501 para cada caminho de rede logicamente isolada que o cliente deseja estabelecer, isto é, não pode ser permitido a um cliente usar a mesma identificação VLAN para múltiplos caminhos logicamente isolados. Em uma implementação, a identificação VLAN 501 pode ser necessária para dar corresponder a um padrão, tal como a Ethernet 802.1q padrão.
[0054] Um cliente também pode ser solicitado a fornecer um Número de Sis-
tema Autônomo de BGP (ASN) 511. Conforme observado anteriormente, um Siste-
ma Autônomo (AS) é uma coleção de prefixos de roteamento do Protocolo de Inter-
net (IP) conectados sob o controle de um ou mais operadores de rede que apresenta uma política de roteamento comum, claramente definida para a Internet.
Um ASN único é normalmente atribuído a cada AS para uso no roteamento de BGP.
O ASN
511 pode ser público (isto é, pode estar exposto a vários roteadores da Internet pú-
blica) ou privado (exposto apenas aos roteadores da rede do provedor 100 e da rede do cliente 162), dependendo do tipo de conectividade lógica que o cliente deseja estabelecer em várias modalidades.
O cliente também pode fornecer um conjunto de prefixos de rede 521 a ser anunciado para a rede logicamente isolada, por exemplo,
em conformidade com o BGP ou outro protocolo de roteamento.
O emparelhamento de informações 531, indicando, por exemplo, se o caminho logicamente isolado de-
sejado deve ser emparelhado em um modo ativo/ativo ou ativo/standby com qual-
quer outro caminho, também pode estar incluído na solicitação 551 em algumas mo-
dalidades.
Em algumas implementações, a rede do provedor pode apoiar o estabe-
lecimento de gateways privados virtuais para dar suporte à funcionalidade de VPN
(rede virtual privada) entre uma rede do cliente 162 e as coleções de recurso 120, e a solicitação 551 também pode incluir uma identificação desse gateway virtual priva-
do a ser usado para o caminho de rede logicamente isolado.
Em algumas modalida-
des, as técnicas de Multiple Protocol Label Switching (MPLS) podem ser usadas pa-
ra implementar o isolamento de rede lógica.
Embora os elementos exemplares ilus-
trados na Figura 5 possam ser aplicáveis em ambientes onde o BGP e os protocolos relacionados estão em uso, em outras modalidades, outros mecanismos de isola-
mento de rede (por exemplo, quaisquer outras técnicas utilizáveis para conexão a nuvens virtuais privadas ou VPNs) podem ser fornecidos pelo cliente e usados pelo provedor de conectividade para o isolamento da rede lógica.
Na chamada da API setUpLogicalConnection de exemplo descrita anteriormente, alguns ou todos os di-
versos elementos da solicitação 551 podem estar incluídos, por exemplo, nos cam- pos do objeto LogicalConnectionParameters passado como um parâmetro.
[0055] Em uma modalidade, após receber a solicitação 551 para estabelecer um caminho de rede logicamente isolada, o coordenador de conectividade 114 pode executar um conjunto de operações, tal como a atualização do banco de dados de conectividade 115, a propagação de informações de roteamento apropriadas para vários roteadores da rede do provedor 105, a atualização de vários caches relacio- nados ao roteamento e similares, para completar a configuração solicitada. Depois de estabelecer o caminho da rede logicamente isolada com êxito, em algumas mo- dalidades, o coordenador de conectividade 114 pode enviar uma mensagem de con- firmação de volta para o cliente, indicando que a conectividade dedicada solicitada e/ou o isolamento lógico foi fornecido com êxito. A Figura 6 ilustra um exemplo dos conteúdos dessa mensagem de confirmação 651, indicando que a conectividade solicitada foi estabelecida, de acordo com pelo menos algumas modalidades. No exemplo ilustrado, os detalhes da confirmação da conexão física 601 podem confir- mar algumas das informações relacionadas ao link físico estabelecido na solicitação do cliente, tais como o identificador de porta 467, identificador de rack 463, largura de banda disponível, etc. Os detalhes da confirmação da conexão lógica 621 podem confirmar as propriedades dos caminhos de rede logicamente isolada, tais como a identificação VLAN 501, BGP ASN 511, prefixos de rede 521, informações de empa- relhamento 531, e informações de gateway virtual privado 541. No exemplo ilustra- do, a mensagem de confirmação 651 também inclui o identificador de conexão 482 e as informações de suporte 611 - por exemplo, informações que o cliente pode usar para obter ajuda no caso de uma interrupção do tráfego, mau desempenho ou outro problema que possa surgir. As mensagens de confirmação 651 podem excluir qual- quer combinação dos elementos mostrados na Figura 6 em diferentes modalidades, e podem incluir informações adicionais em algumas modalidades. Em uma modali-
dade, múltiplas mensagens de confirmação podem ser enviadas pelo coordenador de conectividade 114 - por exemplo, uma primeira mensagem de confirmação pode ser enviada após o link físico ser estabelecido, e uma segunda mensagem de con- firmação pode ser enviada após o caminho de rede logicamente isolada ter sido es- tabelecido. O coordenador de conectividade 114 também pode enviar instruções ao cliente para verificar ou validar que a conectividade desejada está funcionando cor- retamente na extremidade do cliente - por exemplo, numa modalidade onde os re- cursos 112 incluem servidores virtuais de computação com endereços de IP públicos e/ou privados, essas instruções podem direcionar o cliente a iniciar um servidor vir- tual de computação e alertar um dos seus endereços de IP.
Exemplo de caminhos de rede logicamente isolada sobre link físico comparti- lhado
[0056] A Figura 7 ilustra um exemplo de dois caminhos de rede logicamente isolada 752A e 752B compartilhando um único link físico dedicado, tal como uma conexão de rede cruzada estabelecida usando uma interface fornecida pelo coorde- nador de conectividade 114, de acordo com pelo menos algumas modalidades. No ambiente mostrado na Figura 2, o cliente solicita que a conectividade seja estabele- cida e mantida entre a rede interna 732 e uma área de recurso de acesso restrito
712. Ao mesmo tempo em que o cliente configurou uma zona de rede desmilitariza- da (DMZ) 722 (que também pode ser denominada rede de perímetro) - uma sub- rede da rede do cliente 162A que pode expor alguns dos serviços do cliente à Inter- net pública ou não confiável através da área de recurso de acesso público 702 den- tro dos centros de dados da rede do provedor 105. Para garantir que o tráfego para a área de recurso de acesso restrito 712 e a área de recurso de acesso público 702 atenda as exigências de desempenho, segurança e custo desejadas, o cliente pode primeiro usar a interface fornecida pelo coordenador de conectividade 114 para es- tabelecer uma conexão de rede cruzada 791 entre o roteador do lado do cliente
142A e o roteador de ponto de extremidade 132A, usando, por exemplo, as etapas descritas na Figura 2. O cliente pode ainda usar outros componentes da interface para estabelecer dois caminhos de rede logicamente isolada que compartilham a conexão de rede cruzada 791: caminho 752A para o tráfego entre DMZ 722 e a área de recurso de acesso público 702, e o caminho 752B para o tráfego entre a rede in- terna do cliente 732 e a área de recurso de acesso restrito 712.
[0057] Em algumas modalidades, múltiplos links físicos dedicados, tais como conexões de rede cruzada 791 ou 191 podem ser configurados em nome de um úni- co cliente, dentro de uma instalação de colocalização do roteador 150 ou através de múltiplas instalações de colocalização do roteador. Por exemplo, uma empresa mul- tinacional pode ter instalações de escritório em diversos países diferentes, que po- dem todos se beneficiar da conectividade dedicada a um conjunto de coleções de recurso 120; nesse caso, um ou mais links físicos dedicados podem ser configura- dos para as respectivas localizações de escritórios geograficamente separadas. Um único link físico pode ser compartilhado através de inúmeros caminhos logicamente isolados, tais como os caminhos 752 da Figura 7. Além disso, uma determinada co- leção de recurso, tal como uma área de recurso 702 ou 712 pode ser acessada atra- vés de uma pluralidade de caminhos logicamente isolados 752, onde alguns dos caminhos logicamente isolados 752 podem usar diferentes links físicos dedicados
791.
Exemplo de interface baseada na web
[0058] A Figura 8 é uma ilustração de uma porção de uma interface baseada na web exemplar que pode ser fornecida pelo coordenador de conectividade 114 em algumas modalidades. Conforme observado anteriormente, a interface implementa- da pelo coordenador de conectividade 114 para fornecer serviços de conectividade pode ser exposta aos clientes como um conjunto de páginas da web em algumas modalidades. A página da web 800 da Figura 8 é uma representação de um exem-
plo dessa página da web que inclui vários campos de formulário que um cliente pode preencher para fornecer detalhes sobre as exigências de conectividade dedicada desejada. Em algumas implementações, a submissão dos dados do formulário atra- vés de uma interface semelhante a uma página da web 800 pode resultar em uma invocação de uma ou mais chamadas de API semelhantes àquelas listadas anteri- ormente, em conjunto com a descrição do elemento 201 da Figura 2.
[0059] Na área 803 da página da web 800, uma mensagem de saudação amigável e de uma visão geral podem ser fornecidas. Os campos do formulário 805 podem ser fornecidos para permitir que o cliente especifique uma localização física onde a conectividade dedicada é desejada. Usando o campo do formulário 807, o cliente pode especificar a largura de banda desejada, para a qual um valor padrão de 1Gbps é mostrado preselecionado na Figura 8. Os campos do formulário 809 po- dem ser usados para fornecer emparelhamento opcional ou informações de múlti- plos caminhos; conforme mostrado, um padrão de duas conexões no modo ati- vo/ativo é preselecionado. Para os campos 811 pode permitir que o cliente especifi- que um nome do fornecedor e modelo para um roteador do cliente a ser usado para um link físico dedicado. O campo do formulário 813 pode permitir que o cliente iden- tifique um provedor de serviços de rede que também pode estar envolvido na confi- guração da conectividade dedicada - por exemplo, um operador da instalação de colocalização do roteador que pode ser usada. Em algumas modalidades, quando o cliente preenche as informações de endereço nos campos do formulário 805, o co- ordenador de conectividade 114 pode automaticamente preencher o campo do for- mulário do provedor de serviços de rede 813, ou pode preencher um conjunto de opções suspensas a partir do qual o cliente pode selecionar um provedor preferido através do campo do formulário 813. O cliente pode submeter o formulário concluí- do, usando o botão enviar 815 no exemplo ilustrado. Em algumas implementações, ao empregar uma interface de página da web, várias páginas da web diferentes po-
dem ser empregadas durante o processo de estabelecimento da conectividade física e lógica desejada. Conforme o cliente preenche uma entrada do formulário, o coor- denador de conectividade pode ser capaz de personalizar ou restringir o conjunto de opções disponíveis para as entradas do formulário subsequentes.
[0060] A Figura 9 é um fluxograma de um método para fornecer serviços re- lacionados à conectividade, de acordo com pelo menos algumas modalidades. Con- forme mostrado no elemento 900, no fluxograma, uma interface que define um con- junto de operações de conectividade pode ser implementada, por exemplo, por um coordenador de conectividade 114. As operações de conectividade fornecidas atra- vés da interface podem incluir serviços para configurar, consultar, modificar, desabili- tar e destruir vários tipos de conexões físicas e lógicas, em várias modalidades. A interface pode compreender qualquer combinação de um conjunto de APIs, uma GUI baseada na web ou independente, ferramentas de linha de comando e similares.
[0061] Uma solicitação para a conectividade dedicada pode ser recebida, em conformidade com a interface, conforme mostrado no elemento 910. Por exemplo, em um ambiente onde a interface é baseada na web, a solicitação pode compreen- der uma ou mais solicitações de HTTP ou HTTPS, enquanto em uma modalidade diferente, a solicitação pode compreender uma ou mais chamadas de método de um programa codificado e executado em nome do cliente. A solicitação pode compreen- der uma enumeração de vários detalhes que podem ser necessários para tomar uma decisão como onde e como a conectividade dedicada pode ser fornecida, e quais entidades de negócios, tais como provedores de serviços de rede de terceiros ou operadores de centros de dados de rede, podem precisar estar envolvidas. Por exemplo, a solicitação pode especificar um endereço físico desejado, no qual um roteador do lado do cliente 142 está disponível para uso, uma largura de banda de- sejada e várias outras exigências.
[0062] Ao receber a solicitação, um roteador de ponto de extremidade de destino 132 de uma rede do provedor 105 pode ser selecionado, através do qual pode ser configurável uma rota para fornecer a conectividade dedicada desejada ao cliente, conforme mostrado no elemento 920 da Figura 9. O roteador de ponto de extremidade de destino pode ser selecionado com base em qualquer um de uma variedade de fatores em diferentes modalidades, incluindo a localização física, níveis de utilização de largura de banda medidos e/ou esperados, custos, experiências an- teriores positivas ou negativas com o operador da instalação onde se localiza o rote- ador, compatibilidade com o equipamento de rede do cliente e similares.
[0063] Um conjunto de informações e instruções de configuração podem, em seguida, ser gerado para a configuração de um link físico para o roteador de ponto de extremidade de destino, conforme mostrado no elemento 930, e uma resposta pode então ser transmitida (elemento 940). Em algumas modalidades, a resposta pode ser submetida apenas para o cliente solicitante, enquanto em outras modalida- des, uma resposta pode ser submetida a um operador de uma instalação de coloca- lização do roteador 150, onde o link físico deve ser estabelecido, ou as respostas podem ser submetidas para o cliente solicitante e para o operador da instalação. A resposta pode incluir os dados que identificam a porta física particular, a caixa, rack, e/ou o painel de conexões, onde um cabo físico pode ser anexado em algumas im- plementações. As informações de autorização, por exemplo, concessão de permis- são a um técnico para acessar o roteador de ponto de extremidade podem estar in- cluídas na resposta, ou podem se tornar acessíveis através da resposta.
[0064] Em uma implementação, após o link físico ser estabelecido, uma mensagem de confirmação, indicando que a conectividade desejada foi estabelecida com êxito, pode ser transmitida para o cliente (elemento 950 da Figura 9). Em outras implementações, uma mensagem de confirmação pode ser gerada após um ou mais caminhos de rede logicamente isolada terem sido estabelecidos usando o link físico recentemente estabelecido.
[0065] A Figura 10 é um fluxograma de um método de fornecimento de ser- viços relacionados à conectividade, incluindo orientação na configuração de um dis- positivo de rede do cliente, de acordo com pelo menos algumas modalidades. Uma interface, que permite que um cliente faça uma variedade de solicitações relaciona- das à conectividade, incluindo solicitações de assistência na configuração de um ou mais dispositivos de rede que podem ser usados para estabelecer a conectividade dedicada com uma rede do provedor, pode ser implementada, conforme mostrado no elemento 1000. Uma solicitação, que fornece uma identificação dos equipamen- tos de rede (por exemplo, qualquer combinação de um nome do fornecedor, um no- me do modelo e um identificador de versão do software para o software sendo exe- cutado no equipamento de rede) disponíveis para uso pelo cliente, pode ser recebi- da (elemento 1010), em conformidade com a interface. Essa solicitação também po- de incluir outros detalhes da conectividade solicitada pelo cliente, tal como uma lar- gura de banda desejada, exigências de disponibilidade/redundância e similares.
[0066] Em resposta à solicitação, em algumas implementações, um coorde- nador de conectividade 114 pode consultar um banco de dados de informações de configuração, por exemplo, usando uma combinação d nome do fornecedor, nome do modelo, versão do software e/ou exigências de conectividade (elemento 1020).
Se a orientação de configuração apropriada for encontrada, por exemplo, com base nas informações de identificação fornecidas na solicitação, uma resposta contendo as informações ou instruções de configuração pode ser gerada (elemento 1030) e transmitida para o cliente solicitante (elemento 1040). Em algumas implementações, o banco de dados das informações de configuração pode incluir um inventário de onde (isto é, por quais clientes) diferentes tipos de equipamentos de rede estão sen- do usados; nesse caso, um registro indicando que o cliente solicitante usa o equi- pamento especificado pode ser inserido no banco de dados (elemento 1050). Algu- mas informações adicionais dos ambientes nas experiências com diferentes tipos de equipamentos de rede, tais como pesquisas de satisfação do cliente com seus equi- pamentos de rede, tempos médios de falha, dados de disponibilidade e similares também podem ser mantidas em uma base de conhecimento pelo coordenador de conectividade 114, e algumas ou todas as informações adicionais também podem ser disponibilizadas através da interface.
Interações com provedores de conectividade de última milha
[0067] A Figura 11 ilustra um exemplo de um sistema 1105 incluindo uma rede do provedor 1100 à qual a conectividade pode ser fornecida a partir de redes do cliente tais como 1162A e 1162B através dos provedores de conectividade de "última milha" (por exemplo, 1150A, 1150B, e 1150C), de acordo com pelo menos algumas modalidades. Em muitos ambientes, dispositivos do cliente tais como 1148A e 1148B podem ser provisionados dentro de redes (por exemplo, 1162A e 1162B) que não podem ter caminhos privados disponíveis a partir de seus roteado- res do lado do cliente 1142 para instalações de colocalização de roteador (seme- lhantes às instalações 150 da Figura 1) onde roteadores de ponto de extremidade tais como 1132A e 1132B podem ser localizados. Isto pode ser especialmente pro- vável no caso de empresas do cliente relativamente pequenas, ou quando estabele- cimentos comerciais do cliente são localizados em áreas que são um pouco remotas de centros de colocalização de roteador. Essas redes do cliente 1162 podem ter acesso através dos caminhos de rede compartilhados (por exemplo, as partes da Internet pública, incluindo, por exemplo, partes do caminho 1175) para várias cole- ções de recurso 1120 da rede do provedor 1100, mas os operadores das redes do cliente podem querer aproveitar das vantagens dos caminhos dedicados para as coleções de recurso. Vários provedores de conectividade da terceira parte 1150 (isto é, entidades empresariais que não sejam o operador da rede do provedor) podem ser capazes de fornecer os caminhos dedicados para os roteadores de ponto de ex- tremidade 1132 - por exemplo, na Figura 11, o provedor de conectividade 1150C é mostrado fornecendo um caminho dedicado ou direto 1149 entre o roteador ponto de extremidade 1132B e a rede do cliente 1162B. Tais provedores de conectividade podem ajudar os clientes a fazer uma ponte entre as redes do cliente 1162 e os ca- minhos privados 1170 (por exemplo, caminhos 1170A, 1170B, 1170C e 1170D, se- melhantes aos caminhos 170 da Figura 1) disponíveis entre os roteadores de ponto de extremidade 1132 e as coleções de recurso 1120. Estes provedores de conectivi- dade da terceira parte podem ser referidos como provedores de conectividade de "última milha" (ou provedores de conectividade de "último quilômetro" em ambientes onde as unidades de distância métrica são mais populares), como muitas vezes são responsáveis pela implementação de conectividade de rede física mais próxima aos estabelecimentos do cliente e, portanto, mais distante dos estabelecimentos de pro- vedores de infraestrutura de rede principal. Neste documento, provedores de conec- tividade de última milha podem também ser referidos usando a abreviação "LMCP".
[0068] Identificar que, se for o caso, os provedores de conectividade de últi- ma milha podem estar disponíveis e dispostos para conectar uma rede do cliente à rede do provedor 1100 pode ser, muitas vezes, trabalhoso a partir de uma perspecti- va do cliente. Em alguns casos, um número de LMCPs pode operar nas proximida- des dos estabelecimentos do cliente, mas apenas um subconjunto pode ser supor- tado ou preferido pelo operador da rede do provedor 1100. Na modalidade ilustrada na Figura 11, o coordenador de conectividade 1114 pode ser operável para imple- mentar uma interface definindo uma variedade de serviços relacionados à conectivi- dade, que pode permitir que os clientes facilmente determinem quais LMCPs 1150 podem ser usados para se conectar à rede do provedor 1100. Tal interface pode adicionalmente permitir que os clientes estabeleçam a conectividade dedicada dese- jada (por exemplo, ao longo de um caminho direto 1149) para coleções de recurso 1120 com a ajuda de provedores de conectividade de última milha selecionados. O coordenador de conectividade 1114 pode implementar um ou mais bancos de dados
1115 para armazenar informações relacionadas à conectividade, incluindo, por exemplo, um diretório de provedores de conectividade de última milha 1150 e suas ofertas. A interface pode ser publicada ou disponibilizada aos clientes pelo coorde- nador de conectividade 1114 usando qualquer técnica apropriada, tais como uma ou mais mensagens de e-mail a todos os clientes da rede do provedor 1100, estabele- cendo um web site ou página da web com os detalhes da interface, e assim por dian- te. A própria interface pode, por exemplo, ser programática, e pode compreender qualquer combinação de uma coleção de APIs, uma ou mais páginas da web, ferra- mentas de linha de comando, uma interface gráfica de usuário instalável, ou simila- res. O coordenador de conectividade 1114 em si pode ser residente fora da rede do provedor 1100 em algumas modalidades, e em outras modalidades, pode ser incor- porado dentro da rede do provedor 1100.
[0069] Usando a interface, por exemplo, de um dos dispositivos do cliente 1142A, um cliente pode enviar uma solicitação para conectividade dedicada, por exemplo, ao longo de um caminho 1175 que pode incluir links de Internet pública. A solicitação pode, por exemplo, incluir o endereço físico ou endereços em que o clien- te deseje conectividade dedicada. Em resposta à solicitação, o coordenador de co- nectividade pode ser operável para identificar um ou mais LMCPs 1150 que podem estar disponíveis para estabelecer conexões dedicadas entre a rede do provedor 1100 e a rede do cliente solicitante (por exemplo, 1162A), e gerar e transmitir uma resposta que lista os LMCP ou LMCPs selecionados. O LMCP selecionado pode operar ou gerenciar um ou mais roteadores que podem ser colocalizados com um dos roteadores de ponto de extremidade 1132 da rede do provedor 1100, ou podem ter a capacidade de configurar esses roteadores se eles não estiverem mais dispo- níveis. Em algumas modalidades, o coordenador de conectividade 1114 pode permi- tir que o cliente selecione um LMCP dentre um conjunto de LMCPs disponíveis, en- quanto em outras modalidades o coordenador de conectividade 1114 pode determi-
nar os LMCP ou LMCPs específicos que devem ser usados, e informar ao cliente da determinação. Posteriormente, após a conectividade dedicada ter sido criada, por exemplo, através de etapas semelhantes às descritas na Figura 2, o coordenador de conectividade 1114 pode em algumas modalidades fornecer uma confirmação ao cliente indicando que a conectividade desejada foi verificada. A interface pode ser usada para a comunicação entre o cliente e o coordenador de conectividade 1114 durante qualquer um dos estágios de estabelecimento e uso de conectividade dedi- cada - por exemplo, um cliente pode consultar o estado de uma conexão solicitada ou uma conexão estabelecida usando a interface, e pode solicitar várias modifica- ções de conectividade, desativação e ativação de conectividade, e similares. As res- postas às solicitações do cliente também podem ser formatadas em conformidade com a interface.
[0070] O coordenador de conectividade 1114 pode, por exemplo, procurar in- formações de LMCP no banco de dados 1115 para responder à solicitação inicial para conectividade dedicada. Em casos onde múltiplos LMCPs 1150 estão disponí- veis, o coordenador de conectividade 1114 pode em algumas implementações for- necer uma enumeração ordenada de todos os LMCPs disponíveis para o cliente. Em outras implementações os LMCPs disponíveis podem ser classificados de acordo com qualquer um de uma variedade de critérios, com base nos detalhes da solicita- ção do cliente e na base de conhecimento de LMCP do coordenador de conectivida- de. Por exemplo, se o provedor de conectividade 1114 estiver ciente do ranking de qualidade de serviço ou classificações dos vários LMCPs, poderá classificar os LMCPs da mais alta à mais baixa qualidade. Se o provedor de conectividade 1114 tiver informações sobre preços disponíveis para os diferentes LMCPs este poderá classificar os mesmos de acordo com os preços, e assim por diante. O coordenador de conectividade 1114 pode em algumas implementações periodicamente consultar os clientes sobre rankings de qualidade ou classificações de diferentes LMCPs e armazenar os resultados de tais pesquisas no banco de dados 1115, ou poderá mo- nitorar paralisações ou oferecer suporte a solicitações para estabelecer seu próprio ranking de qualidade. Em uma implementação, na qual os clientes podem especifi- car períodos de estabelecimento de conectividade desejados (por exemplo, o equi- valente lógico de "Eu preciso desta conectividade até 1 de Agosto de 2011 às 08:00h"), o coordenador de conectividade pode ser capaz de eliminar alguns LMCPs da lista de LMCPs disponíveis com base em quão rápido os LMCPs foram conheci- dos para estabelecer conectividade no passado. Em algumas modalidades, a inter- face suportada pelo coordenador de conectividade 1114 pode permitir que os clien- tes consultem sua base de conhecimento de LMCPs. Além dos caminhos ilustrados na Figura 11, em muitos ambientes, pode haver vários outros caminhos de rede al- ternativos disponíveis entre as redes do cliente 1162 e vários componentes do sis- tema 1105 - por exemplo, as solicitações de conectividade podem ser transmitidas para o provedor de conectividade 1114 ao longo de um caminho que inclui links pú- blicos ou compartilhados, e diversos serviços prestados às coleções de recurso 1120 podem ser acessados através dos links públicos ou compartilhados também.
Comunicações relacionadas ao LMCP com o coordenador de conectividade
[0071] A Figura 12 ilustra um exemplo de elementos constituintes de uma solicitação inicial 1251 para a conectividade dedicada através de um provedor de conectividade 1150, de acordo com pelo menos algumas modalidades. Conforme mostrado, a solicitação compreende informações de localização 1260 para a rede do cliente 1162, e detalhes de conectividade opcionais 1261, um momento de início op- cional 1268, e momento de término opcional 1269. O coordenador de conectividade 1114 pode usar informações de localização 1260 como critério principal para consul- tar seu banco de dados de LMCP para identificar os LMCPs disponíveis. Os detalhes de conectividade opcionais 1261 podem incluir requisitos semelhantes àqueles mos- trados na Figura 3, por exemplo, requisito de banda larga 361, requisito de disponibi-
lidade 363, e/ou requisito de múltiplos caminhos 365. Em algumas modalidades o cliente pode também especificar um momento de início desejado 1268 e/ou um mo- mento de término desejado 1269 - por exemplo, indicando que a conectividade dedi- cada só vai ser necessária por 3 meses com início em 1 de Janeiro de 2011. Em alguns casos, os tempos de início e de término podem indicar que o cliente deseja apenas usar parte do tempo de conectividade dedicada - por exemplo, o momento de início e o momento de término podem ser especificados como "08:00h às 20:00h, de segunda à sexta-feira". Em algumas implementações onde os momentos de iní- cio desejados 1268 são indicados pelo cliente, os momentos de término 1269 podem não ser necessários. As solicitações de cronometragem compreendendo os momen- tos de início e/ou de término desejados podem ser enviadas separadamente da soli- citação inicial 1251 em algumas modalidades.
[0072] A Figura 13 ilustra um exemplo de elementos constituintes de uma resposta 1301 a uma solicitação de conectividade dedicada que inclui informações sobre provedores de conectividade disponíveis 1150, de acordo com pelo menos algumas modalidades. A resposta 1301 pode compreender uma lista de um ou mais registros de detalhes de LMCP 1361, por exemplo, 1361A e 1361B, que o coorde- nador de conectividade 1114 pode ter encontrado para atender à solicitação 1251 do cliente. Diferentes tipos de informações sobre os LMCPs disponíveis podem ser for- necidos ao cliente em várias modalidades. Por exemplo, o registro de detalhes de LMCP 1361A pode compreender uma identificação (por exemplo, informações de nome e contato) 1311A do LMCP 1150A, informações sobre preços nos campos 1321A e 1321B, tempo de estabelecimento de conectividade estimado 1341A, e/ou uma classificação de satisfação 1351A. As informações sobre preços podem ser di- vididas em um componente de preço recorrente 1321A (por exemplo, "X dólares por mês, independente do uso real") e um componente de preço não-recorrente 1331A (por exemplo,com base no uso de banda larga medido pelo cliente). Em algumas implementações as informações de preços podem ser descriminadas adicionalmente em componentes que devem ser pagos ao LMCP 1150A diretamente pelo cliente, e que devem ser pagos ao operador da rede do provedor 1100. A interface suportada pelo coordenador 1114 pode permitir que os clientes enviem consultas relacionadas aos preços como solicitações separadas em algumas implementações. O momento mais remoto em que o LMCP 1150A e/ou operador da rede de provedor 1100 pode ser capaz de estabelecer a conectividade dedicada desejada pode ser indicado atra- vés do campo 1341A. Em alguns casos, um índice de satisfação 1351A (por exem- plo, com base em levantamentos dos clientes do LMCP 1150A) pode ser incluído, que pode ser útil para o cliente na escolha entre os LMCPs disponíveis. O registro de detalhes 1361B pode incluir campos semelhantes como registro 1361A para um LMCP diferente, por exemplo, para LMCP 1150B.
[0073] A Figura 14 ilustra uma comunicação exemplar de um cliente identifi- cando um provedor de conectividade selecionado 1150A, que pode ser gerada pelo cliente após ter recebido uma resposta 1301, de acordo com pelo menos algumas modalidades. A notificação de seleção 1451 também pode ser formatada em con- formidade com a interface implementada pelo coordenador de conectividade 1114, por exemplo, como uma chamada de API ou uma seleção de formulário da web. A Figura 15 ilustra as comunicações exemplares do coordenador de conectividade 1114 a um LMCP 1150 e ao cliente após o cliente ter selecionado o LMCP, de acor- do com uma modalidade. Como mostrado, na resposta 1551 ao cliente, o coordena- dor de conectividade 1114 pode fornecer a confirmação 1583 da seleção do LMCP.
Em uma modalidade, o coordenador de conectividade 1114 pode determinar o LMCP 1150 a ser usado, por exemplo, com base nas informações de localização do cliente, e pode não exigir que o cliente faça uma seleção; em outras modalidades, o coordenador de conectividade 1114 pode esperar a seleção ou confirmação do cli- ente antes de fazer a determinação do LMCP. Em algumas implementações, o clien-
te pode sugerir ou recomendar um ou mais LMCPs na solicitação inicial para a co- nectividade dedicada (por exemplo, solicitação 1251 da Figura 12), e o coordenador de conectividade 1114 pode determinar o LMCP a ser usado com base na solicita- ção inicial. Um identificador de conexão 1581 também pode ser fornecido ao cliente na resposta 1551. Em algumas modalidades, informações de autorização 1582 que permitem acesso físico ao roteador de ponto de extremidade do provedor de rede 1132, semelhantes às informações de autorização 481 mostradas na Figura 4, po- dem ser fornecidas ao cliente também. Na notificação 1552 enviada ao LMCP sele- cionado 1150, o coordenador de conectividade 1114 pode também fornecer informa- ções de autorização 1582, bem como instruções de configuração do link físico 1571 (semelhante a instruções de configuração de link físico 471 da Figura 4) que podem incluir identificadores de porta, caixa, rack e/ou painel de conexões 1567, 1561, 1563 e 1565 respectivamente para o roteador de ponto de extremidade 1132 ao qual um link físico pode ser estabelecido por ou em nome do LMCP selecionado. Em al- gumas modalidades, as informações de autorização 1582 podem ser enviadas ao cliente ou ao LMCP, mas não a ambos.
[0074] Após comunicações similares àquelas mostradas na Figura 15 serem recebidas pelo cliente e/ou pelo LMCP selecionado 1150, um caminho (semelhante ao caminho direto 1149 da Figura 11) compreendendo um link físico dedicado pode ser estabelecido entre o equipamento da rede do provedor (como um roteador de ponto de extremidade 1132) e a rede do cliente 1162 usando a rede do LMCP sele- cionado e/ou o equipamento em uma modalidade. Como desejado, um ou mais ca- minhos logicamente isolados, semelhantes aos discutidos em conjunto com a des- crição das Figuras 5 e 7 então podem ser estabelecidos usando o link físico dedica- do recém-criado. Em algumas implementações, o coordenador de conectividade 1114 pode verificar, por exemplo, trocando um ou mais pacotes ou mensagens de rede com o cliente e examinando as rotas tomadas pelas mensagens, que a conecti-
vidade dedicada desejada foi fornecida, e pode enviar uma mensagem de confirma- ção ao cliente e/ou ao LMCP 1150 indicando esta realização.
[0075] Em ambientes onde restrições de cronometragem (tais como momen- tos de início e/ou momentos de término) foram solicitadas pelo cliente, o provedor de conectividade 1114 também pode ser operável para implementar essas restrições de cronometragem, por exemplo, por mudanças de roteamento de agendamento ou fazendo outras mudanças de configuração em momentos apropriados. Por exemplo, em um ambiente onde o BGP é usado como um protocolo de roteamento, um con- junto de prefixos de rede para a rede do cliente pode ser anunciado em ou um pouco antes de um momento de início desejado para ativar ou desativar a conectividade dedicada. Em algumas implementações, a conectividade dedicada fornecida a um cliente com a ajuda de um LMCP pode ter um limite de banda larga associado, e a interface suportada pelo coordenador de conectividade 1114 também pode permitir que os clientes façam as solicitações de modificação de banda larga - por exemplo, para solicitar uma maior ou menor taxa de tráfego do que o inicialmente acordado.
Em resposta a essas solicitações o coordenador de conectividade 1114 pode dina- micamente alterar as definições de configuração em um ou mais dispositivos para cumprir com o novo requisito de banda larga. Em uma modalidade, o próprio coor- denador de conectividade 1114 pode monitorar a taxa na qual o tráfego flui para uma rede do cliente 1162. Se o tráfego durante um período de tempo medido atingir um limite (por exemplo, 80% ou mais do tráfego máximo permitido), o coordenador de conectividade 1114 poderá informar ao cliente que uma modificação de banda larga pode ser aconselhável, e o cliente por sua vez poderá solicitar um aumento de banda larga usando a interface. Em algumas implementações, o coordenador de conectividade 1114 também pode ser configurado para notificar a um cliente se pode ser aconselhável reduzir o limite de banda larga associado a um caminho direto de- dicado, por exemplo, se as medições indicarem que o cliente aparece para usar apenas uma pequena fração da banda larga solicitada.
Interface da web exemplar para iniciar a seleção de LMCP
[0076] A Figura 16 é uma ilustração de uma porção de uma interface basea- da na web exemplar que pode ser fornecida para iniciar a seleção do provedor de conectividade, de acordo com algumas modalidades. Como mostrado, a interface baseada na web pode incluir uma página da web 1600 com vários campos de formu- lário que podem ser apresentados ao cliente pelo coordenador de conectividade
1114. A página da web pode incluir uma área de mensagem de boas vindas 1603, e campos de formulário 1605 para o cliente especificar um endereço físico onde a co- nectividade dedicada é desejada. Nos campos 1607, o cliente pode indicar se a as- sistência na seleção de um provedor de conectividade é desejada. Os requisitos de banda larga podem ser especificados nos campos 1609, e requisitos relacionados ao tempo para a conectividade dedicada, tal como um momento de início desejado e/ou um momento de término desejado, podem ser especificados no campo 1611. O botão de envio 1615 pode ser usado para enviar o formulário preenchido para o co- ordenador de conectividade 1114.
[0077] Em uma modalidade, a apresentação de tal formulário pode resultar na invocação de uma ou mais APIs no coordenador de conectividade semelhantes às APIs API-1 a API-18 listadas em conjunto com a descrição da Figura 2. Algumas APIs adicionais, incluindo algumas APIs específicas para LMCP e APIs para forne- cer a modificação dinâmica das conexões existentes e/ou operações relacionadas ao preço também podem ser suportadas em algumas implementações, para que invocações exemplares possam incluir o seguinte: [API-21] ProviderList providerList = getConnectionProviders (CustomerID customerld, CustomerLocationRecord local); A API getConnectionProviders pode ser usada para encontrar LMCPs dispo- níveis baseados nas informações de localização especificadas em um objeto de
CustomerLocationRecord. [API-22] RequestStatus status = setConnectionProvider (Pro- viderIdproviderId, CustomerlD customerld, Requestld requestld); A API setConnectionProvider pode ser usada para especificar que um de- terminado LMCP identificado por seu Providerld foi selecionado pelo cliente. [API-23] RequestStatus status = setConnectionStartTime (ConnectionId con- nectionlD); A API setConnectionStartTime pode ser usada para especificar um momento de início para a conectividade dedicada. [API-24] RequestStatus status = setConnectionEndTime (ConnectionId con- nectionlD); A API setConnectionEndTime pode ser usada para especificar um momento de término desejado para a conectividade dedicada. [API-25] Pricinglnfo pricinglnfo = getConnectionPricingInfo (ConnectionId connectionlD); A API getConnectionPricinglnfo pode ser usada para consultar informações relacionadas aos preços para uma conexão existente ou para uma conexão que ain- da não foi estabelecida.
[0078] Em algumas modalidades, APIs tais como aquelas às quais os exem- plos são fornecidos acima podem estar disponíveis para uso diretamente pelos clien- tes, LMCPs 1150 e/ou outros provedores de rede, ou por provedores de instalações tais como operadores de instalações de colocalização de roteador 150. Em algumas implementações, múltiplas camadas de interfaces podem ser suportadas, permitindo que os clientes solicitem algumas operações relacionadas à conectividade usando uma interface da web, por exemplo, e para executar ou solicitar outras operações usando uma API.
[0079] A Figura 17 é um fluxograma de um método para permitir que os cli-
entes selecionem provedores de conectividade, de acordo com pelo menos algumas modalidades. O método (como mostrado no elemento 1700 da Figura 17) compre- ende a implementação de uma interface que define um conjunto de operações de conectividade disponibilizado aos clientes de uma rede do provedor 1100 por um coordenador de conectividade 1114. A interface pode compreender uma API, uma interface de linha de comando, uma interface baseada na web, alguma outra GUI, ou qualquer outra interface programática, por exemplo. Uma solicitação para a conecti- vidade dedicada, formatada em conformidade com a interface, pode ser recebida (elemento 1702). A solicitação pode em alguns casos diretamente indicar que o soli- citante requer assistência na seleção de um provedor de conectividade. Em outros casos a solicitação pode simplesmente conter algumas informações (como um ende- reço físico onde um cliente deseja obter conectividade dedicada) a partir das quais o coordenador de conectividade 1114 pode inferir, com base em seu conhecimento de onde os roteadores de ponto de extremidade 1132 da rede do provedor 1100 estão fisicamente localizados, que um provedor de conectividade pode ser necessário para cumprir o pedido do cliente. Conforme indicado no elemento 1704, um ou mais pro- vedores de conectividade podem então ser selecionados, e uma resposta para iden- tificar o provedor ou provedores de conectividade selecionados pode ser gerada (elemento 1706 da Figura 17) e transmitida (elemento 1708). Em algumas implemen- tações a resposta pode ser transmitida para o cliente solicitante, enquanto em outras implementações uma resposta e/ou notificação pode também ou em vez disso ser transmitida para o provedor de conectividade selecionado.
[0080] Quando o cliente recebe informações de identificação de provedores de conectividade candidatos tais como LMCPs 1150, este pode selecionar um (se mais de um forem identificados pelo coordenador de conectividade 1114) e notificar o coordenador de conectividade de sua escolha. O coordenador de conectividade 1114 pode então comunicar-se com o LMCP selecionado 1150, e com o cliente, pa-
ra coordenar o estabelecimento de um link físico (e em alguns casos uma ou mais conexões lógicas que usam o link físico) para cumprir as exigências de conectivida- de do cliente. Após a conectividade ter sido estabelecida com êxito, o coordenador de conectividade 1114 pode em algumas implementações enviar uma confirmação da conclusão do estabelecimento (elemento 1710 da Figura 17).
[0081] Em algumas modalidades um número de capacidades adicionais, além da seleção do provedor de conectividade e do estabelecimento de conectivida- de, pode ser suportado através da interface fornecida pelo coordenador de conecti- vidade 1114. A Figura 18 é um fluxograma de um método para o fornecimento de serviços dinâmicos relacionados à conectividade, de acordo com pelo menos algu- mas modalidades. O coordenador de conectividade 1114 pode esperar por solicita- ções relacionadas à conectividade dos clientes, conforme mostrado no elemento
1800. Quando uma solicitação é recebida, se a solicitação for um tipo suportado de solicitação, o coordenador de conectividade 1114 pode tomar a ação solicitada. Por exemplo, se uma solicitação de habilitação dinâmica de conectividade for recebida e suportada na modalidade (elemento 1810), o coordenador de conectividade poderá permitir o fluxo de tráfego, conforme mostrado no elemento 1815. Em alguns casos habilitar ou desabilitar o tráfego pode exigir interação ou coordenação entre o coor- denador de conectividade 1114 e um LMCP 1150. De forma similar, se a solicitação for para desabilitar a conectividade (elemento 1820), a mudança desejada poderá ser colocada em efeito pelo coordenador de conectividade 1114 (elemento 1825). Se a solicitação for para uma mudança dos limites de banda larga associados ao cami- nho de conexão dedicada do cliente (elemento 1830), a mudança solicitada poderá ser implementada, por exemplo, fazendo mudanças de configuração em um ou mais dispositivos de rede da rede do provedor 1100 e/ou um LMCP. Se a solicitação compreender uma consulta de preços (elemento 1840), o coordenador de conectivi- dade 1114 poderá fornecer as informações de preços solicitadas (elemento 1845),
que podem, por exemplo, incluir informações de custos recorrentes e/ou não recor- rentes que o operador da rede do provedor e/ou o LMCP poderão cobrar do cliente.
Se uma solicitação inválida ou sem suporte for recebida, conforme mostrado no ele- mento 1850, o coordenador de conectividade poderá transmitir uma resposta indi- cando que recebeu uma solicitação inesperada. Em cada caso, como as setas que conduzem de volta ao elemento 1800 indicam, o coordenador de conectividade eventualmente reinicia a espera por solicitações relacionadas à conectividade. Em- bora a determinação do tipo de solicitação seja mostrada como uma série de verifi- cações na Figura 1800 por simplicidade (primeiramente verificando solicitações di- nâmicas de ativação e, em seguida, solicitações de invalidez, e assim por diante), em várias implementações o tipo de solicitação pode ser determinado em uma única etapa usando uma lógica semelhante a uma declaração de "caso" ou "switch" em C ou Java.
[0082] A Figura 19 é um fluxograma de um método que compreende a res- posta dinâmica aos níveis de tráfego variáveis, de acordo com pelo menos algumas modalidades. Conforme mostrado no elemento 1900, o coordenador de conectivida- de pode monitorar taxas de tráfego ao longo do caminho dedicado para um cliente.
Se um limite de tráfego for atingido ou mantido ao longo de um período de tempo (como detectado no elemento 1910), o coordenador de conectividade pode fornecer uma indicação ao cliente de que uma mudança da banda larga pode ser apropriada (elemento 1915). Se uma solicitação para alterar a banda larga for recebida em res- posta à indicação (elemento 1920), o coordenador de conectividade poderá imple- mentar a mudança solicitada (elemento 1925). O coordenador de conectividade en- tão poderá retomar o monitoramento do tráfego. Cada uma das interações ilustradas nas Figuras 18 e 19 entre o coordenador de conectividade 1114 e o cliente pode ser implementada usando a interface ou interfaces (por exemplo, uma ou mais páginas da web) fornecidas pelo coordenador de conectividade.
Casos de uso exemplares
[0083] As técnicas descritas acima de fornecimento de interfaces fáceis de usar para operações de conectividade dedicada podem ser usadas em uma varie- dade de ambientes. Por exemplo, se a rede do provedor for se expandindo rapida- mente em novas regiões geográficas onde a confiabilidade, desempenho e/ou segu- rança das instalações de rede publicamente disponíveis são limitados, cada vez mais clientes poderão desejar utilizar a conectividade dedicada, especialmente se esta for fornecida por um preço razoável. Além disso, em casos onde um operador da rede do provedor já pode fornecer um conjunto de interfaces para o gerenciamen- to de recursos de armazenamento e/ou computação (tais como coleções de recurso 120 ou 1120) que atualmente são acessados através de caminhos compartilhados (não-dedicados), o fornecimento de interfaces adicionais para gerenciar as opções de conectividade dedicada pode aumentar significativamente a taxa de adoção dos serviços de conectividade dedicada, em que o operador tem investido.
[0084] As modalidades exemplares podem ser descritas tendo em vista as seguintes cláusulas:
1. Sistema, que compreende: um centro de dados incluindo uma coleção de recursos designada para res- ponder a solicitações de serviços recebidas de um cliente; uma pluralidade de roteadores de ponto de extremidade ligados ao centro de dados por um ou mais caminhos de rede privada; e um coordenador de conectividade; em que o coordenador de conectividade é operável para: implementar uma interface que define operações de conectividade disponí- veis para o cliente; receber uma solicitação de conectividade do cliente para conectividade dedi- cada para a coleção de recursos, em que a solicitação de conectividade é formatada em conformidade com a interface; em resposta à solicitação de conectividade, selecionar um roteador de ponto de extremidade de destino da pluralidade de roteadores de ponto de extremidade, em que o roteador de ponto de extremidade de destino é configurável para fornecer uma rota ao longo de um caminho de rede privada a um ou mais caminhos de rede privada em conformidade com a solicitação de conectividade; gerar uma resposta que compreende as instruções de configuração para um link de rede física a ser estabelecido para o roteador de ponto de extremidade de destino para fornecer pelo menos uma porção da conectividade dedicada; e transmitir a resposta ao cliente.
2. Sistema conforme relatado na cláusula 1, em que a interface compreende pelo menos um de: uma interface de programação de aplicativos (API), uma interfa- ce gráfica do usuário (GUI), ou uma interface de linha de comando.
3. Sistema conforme relatado na cláusula 1, em que o roteador de ponto de extremidade de destino está alojado dentro de uma instalação que requer autoriza- ção para acesso físico, e em que a resposta inclui uma indicação de uma autoriza- ção de acesso físico para o roteador de ponto de extremidade de destino na instala- ção.
4. Sistema conforme relatado na cláusula 1, em que o coordenador de co- nectividade é adicionalmente operável para: receber uma solicitação de isolamento do cliente para estabelecer um cami- nho de rede logicamente isolada para a coleção de recursos através do link físico; e implementar um mecanismo de isolamento de rede para estabelecer o cami- nho de rede logicamente isolada em conformidade com a solicitação de isolamento.
5. Sistema conforme relatado na cláusula 4, em que o mecanismo de isola- mento de rede compreende pelo menos um de: um mecanismo de rede de área local virtual (VLAN) ou uma técnica de Multi-Protocol Label Switching (MPLS).
6. Sistema conforme relatado na cláusula 1, em que o coordenador de co- nectividade é adicionalmente operável para: receber, do cliente, informações de identificação de um dispositivo de rede a ser usado para transmitir o tráfego de rede do cliente para a coleção de recursos; e fornecer, ao cliente, uma ou mais instruções de configuração para o disposi- tivo de rede com base nas informações de identificação.
7. Método, que compreende: apresentar um serviço de conectividade a um cliente de uma rede do prove- dor, em que o referido serviço de conectividade inclui um coordenador de conectivi- dade, implementando uma interface programática que define as operações de co- nectividade disponíveis para a o cliente; receber, no coordenador de conectividade, uma solicitação de conectividade para conectividade dedicada para uma coleção de recursos da rede do provedor, em que a solicitação de conectividade é formatada em conformidade com a interface; em resposta à solicitação de conectividade, selecionar um roteador de ponto de extremidade de destino de uma pluralidade de roteadores de ponto de extremi- dade da rede do provedor, em que o roteador de ponto de extremidade de destino é configurável para fornecer uma rota ao longo de uma rede privada para a coleção de recursos em conformidade com a solicitação de conectividade; gerar uma notificação que compreende as informações de configuração para um link de rede física a ser estabelecido para o roteador de ponto de extremidade alvo 132 para fornecer pelo menos uma porção da conectividade dedicada; e transmitir a notificação.
8. Método, conforme relatado na cláusula 7, que compreende adicionalmen- te: receber informações de identificação de um dispositivo de rede a ser usado para transmitir o tráfego de rede do cliente para a coleção de recursos; e fornecer uma ou mais instruções de configuração para o dispositivo de rede com base nas informações de identificação.
9. Método como relatado na cláusula 7, em que a coleção de recursos com- preende uma pluralidade de recursos, que compreende adicionalmente: receber um ou mais critérios de seleção, identificando um subconjunto da pluralidade de recursos para que uma conexão isolada seja fornecida no link de rede física; e rotear o tráfego de rede em conformidade com os critérios de seleção.
10. Método como relatado na cláusula 9, em que um critério de seleção dos um ou mais critérios de seleção compreende uma marca de rede de área local virtual (VLAN).
11. Método como relatado na cláusula 7, em que o roteador de ponto de ex- tremidade de destino está alojado dentro de uma instalação que requer autorização para acesso físico, e em que a notificação inclui uma indicação de uma autorização de acesso físico para o roteador de ponto de extremidade de destino na instalação.
12. Método como relatado na cláusula 7, em que transmitir a notificação compreende enviar a notificação a um operador de uma instalação na qual o rotea- dor de ponto de extremidade de destino está alojado.
13. Meio de armazenamento acessível por computador não-transitório que armazena as instruções do programa que quando executadas em um ou mais pro- cessadores: implementam uma interface programática que define operações de conecti- vidade disponíveis para um cliente de uma rede do provedor; recebem uma solicitação de conectividade do cliente para uma conectivida- de dedicada para uma coleção de recursos da rede do provedor, em que a solicita- ção de conectividade é formatada em conformidade com a interface;
em resposta à solicitação de conectividade, geram uma notificação compre- endendo informações de configuração para um link de rede física para estabelecer- se a um roteador de ponto de extremidade de destino da rede do provedor para for- necer pelo menos uma porção da conectividade dedicada, em que o roteador de ponto de extremidade de destino é configurável para fornecer uma rota ao longo de um caminho de rede privada para a coleção de recursos em conformidade com a solicitação de conectividade; e transmitem a notificação.
14. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que as instruções do programa, quando executa- das em um ou mais processadores: após o link de rede física ter sido estabelecido, transmitem uma mensagem de confirmação indicando que a conectividade dedicada foi fornecida.
15. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que as informações de configuração compreen- dem pelo menos um de: uma porta física do roteador de ponto de extremidade de destino, um identificador de rack, um identificador de caixa, ou um identificador de painel de conexões.
16. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que a solicitação de conectividade compreende um ou mais de: um requisito de banda larga, um requisito de disponibilidade, ou um requisito de uma pluralidade de caminhos físicos para a coleção de recursos.
17. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que as instruções do programa, quando executa- das em um ou mais processadores: recebem informações de identificação de um dispositivo de rede a ser usado para transmitir o tráfego de rede do cliente para a coleção de recursos; e fornecem uma ou mais instruções de configuração para o dispositivo de rede com base nas informações de identificação.
18. Meio de armazenamento acessível por computador não-transitório, con- forme indicada na cláusula 13, em que a coleção de recursos compreende uma plu- ralidade de recursos, em que as instruções do programa, quando executadas em um ou mais processadores: recebem um ou mais critérios de seleção, identificando um subconjunto da pluralidade de recursos para que uma conexão isolada seja fornecida no link de rede física; e geram informações de roteamento para rotear o tráfego de rede em confor- midade com os critérios de seleção.
19. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 18, em que um critério de seleção dos um ou mais crité- rios de seleção compreende uma identificação de rede de área local virtual (VLAN).
20. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que o roteador de ponto de extremidade de desti- no está alojado dentro de uma instalação que requer autorização para acesso físico, e em que a notificação inclui uma indicação de uma autorização de acesso físico para o roteador de ponto de extremidade de destino na instalação.
21. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 13, em que as informações de configuração compreen- dem uma identificação de uma localização física do roteador de ponto de extremida- de de destino.
22. Sistema, que compreende: uma pluralidade de coleções de recursos de uma rede do provedor, incluindo uma primeira coleção de recursos dentro de uma primeira zona geográfica da rede do provedor e uma segunda coleção de recursos dentro de uma segunda zona geo-
gráfica da rede do provedor; um roteador de ponto de extremidade dentro da primeira zona geográfica, conectando a primeira coleção de recursos a uma rede do cliente de um cliente atra- vés de um link de rede física dedicada; e um coordenador de conectividade; em que o coordenador de conectividade é operável para: implementar uma interface para receber solicitações de conectividade do cli- ente; receber uma solicitação de conectividade do cliente para estabelecer um caminho de rede logicamente isolada para a segunda coleção de recursos, em que a solicitação de conectividade é formatada em conformidade com a interface; e executar uma ou mais operações de configuração para permitir que o tráfego flua da rede do cliente para a segunda coleção de recursos ao longo de um caminho de rede logicamente isolada usando o link de rede física dedicada.
23. Sistema, conforme relatado na cláusula 22, em que o coordenador de conectividade é operável adicionalmente para: em resposta à solicitação de conectividade, enviar instruções ao cliente para transmitir metadados de conectividade associados ao caminho de rede logicamente isolada para um endereço de destino dentro da segunda zona geográfica; e antes de executar uma ou mais operações de configuração, verificar se os metadados de conectividade foram transmitidos em conformidade com as instru- ções.
24. Sistema, conforme relatado na cláusula 22, em que o coordenador de conectividade é operável adicionalmente para: implementar uma primeira política de preços para a primeira zona geográfi- ca, e uma segunda política de preços para a segunda zona geográfica; e fornecer uma indicação das primeira e segunda políticas de preços ao clien-
te em conformidade com a interface.
25. Sistema, conforme relatado na cláusula 22, em que o coordenador de conectividade é operável adicionalmente para: fornecer uma enumeração para o cliente de uma ou mais coleções de recur- sos às quais conexões logicamente isoladas podem ser estabelecidas no link de re- de física dedicada, em que a enumeração é formatada em conformidade com a inter- face.
26. Sistema, conforme relatado na cláusula 22, em que a interface compre- ende um ou mais de: uma interface de programação de aplicativos, uma interface de linha de comando, uma interface gráfica do usuário, ou uma interface da web.
27. Método, que compreende: apresentar um serviço de conectividade de um cliente de uma rede do pro- vedor, em que a rede do provedor compreende uma primeira zona geográfica, inclu- indo uma primeira coleção de recursos alocada para o cliente, e uma segunda zona geográfica, incluindo uma segunda coleção de recursos alocada para o cliente, em que o referido serviço de conectividade inclui um coordenador de conectividade que implementa uma interface programática definindo operações de conectividade dis- poníveis para o cliente; receber uma solicitação de conectividade do cliente para estabelecer um caminho de rede logicamente isolada para a segunda coleção de recursos usando um link físico dedicado estabelecido em nome do cliente para um roteador de ponto de extremidade dentro da primeira zona geográfica, em que o pedido de conectivi- dade é formatado em conformidade com a interface; e executar uma operação de configuração para permitir que o tráfego flua ao longo do segundo caminho de rede logicamente isolada através do link de rede físi- ca dedicada.
28. Método, conforme relatado na cláusula 27, que compreende adicional-
mente: em resposta à solicitação de conectividade, enviar instruções ao cliente para transmitir metadados de conectividade associados ao caminho de rede logicamente isolada para um endereço de destino dentro da segunda zona geográfica; e antes de executar a operação de configuração, verificar se os metadados de conectividade foram transmitidos em conformidade com as instruções.
29. Método, como relatado na cláusula 28, em que os metadados de conec- tividade são codificados em conformidade com um algoritmo de criptografia criado para comunicação segura entre o coordenador de conectividade e um dispositivo de rede na segunda zona geográfica.
30. Método, conforme relatado na cláusula 27, que compreende adicional- mente: implementar uma primeira política de preços para a primeira zona geográfi- ca, e uma segunda política de preços para a segunda zona geográfica; e fornecer uma indicação da segunda política de preços ao cliente em confor- midade com a interface.
31. Método, conforme relatado na cláusula 30, em que pelo menos uma polí- tica de preço das primeira e segunda políticas de preço compreende um indicador de preços baseado em pelo menos um de: uma quantidade de tráfego de rede gerado, uma distância na qual o tráfego de rede é transmitido, o uso de um mecanismo de balanceamento de carga ou um uso de um mecanismo de escalada de WAN (rede de área ampla).
32. Método, conforme relatado na cláusula 27, que compreende adicional- mente: validar, antes de realizar a operação de configuração, se a operação de con- figuração está em conformidade com uma ou mais políticas de acesso associadas à segunda coleção de recursos.
33. Método, conforme relatado na cláusula 27, que compreende adicional- mente: fornecer uma enumeração para o cliente de uma ou mais coleções de recur- sos às quais conexões logicamente isoladas podem ser estabelecidas no link de re- de física dedicada, em que a enumeração é formatada em conformidade com a inter- face.
34. Método, conforme relatado na cláusula 27, que compreende adicional- mente: fornecer uma indicação para o cliente de um primeiro nível de serviço de de- sempenho para o tráfego dentro da primeira zona geográfica, e um segundo nível de serviço de desempenho para o tráfego entre a primeira zona geográfica e segunda zona geográfica, em que a indicação é formatada, em conformidade com a interface.
35. Método, conforme relatado na cláusula 27, em que a operação de confi- guração compreende uma mudança de roteamento no roteador de ponto de extre- midade.
36. Meio de armazenamento acessível por computador não-transitório que armazena as instruções do programa que quando executadas em um ou mais pro- cessadores: implementam uma interface programática que define operações de conecti- vidade disponíveis a um cliente de uma rede do provedor, em que a rede do prove- dor compreende uma primeira zona geográfica compreendendo uma primeira cole- ção de recursos alocada para o cliente, e uma segunda zona geográfica compreen- dendo uma segunda coleção de recursos alocada para o cliente; recebem uma solicitação de conectividade do cliente para estabelecer um caminho de rede logicamente isolada para a segunda coleção de recursos usando um link físico dedicado estabelecido em nome do cliente para um roteador de ponto de extremidade dentro da primeira zona geográfica, em que a solicitação de conecti-
vidade é formatada em conformidade com a interface; e executam uma operação de configuração para permitir que o tráfego flua ao longo do segundo caminho de rede logicamente isolada através do link de rede físi- ca dedicada.
37. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 36, em que as instruções, quando executadas em um ou mais processadores: em resposta à solicitação de conectividade, enviam instruções ao cliente pa- ra transmitir metadados de conectividade associados ao caminho de rede logica- mente isolada para um endereço de destino dentro da segunda zona geográfica em um caminho que exclui o link de rede física dedicada; e antes de executar a operação de configuração, verificar se os metadados de conectividade foram transmitidos em conformidade com as instruções.
38. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 37, em que os metadados de conectividade são codifica- dos em conformidade com um mecanismo de criptografia.
39. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 36, em que as instruções quando executadas em um ou mais processadores: implementam uma primeira política de preços para a primeira zona geográfi- ca, e uma segunda política de preços para a segunda zona geográfica; e fornecem uma indicação da segunda política de preços ao cliente em con- formidade com a interface.
40. Meio de armazenamento acessível por computador não-transitório, con- forme relatado na cláusula 36, em que as instruções quando executadas em um ou mais processadores: fornecem uma enumeração para o cliente de uma ou mais coleções de re-
cursos às quais conexões logicamente isoladas podem ser estabelecidas no link de rede física dedicada, em que a enumeração é formatada em conformidade com a interface.
41. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 36, em que as instruções, quando executadas em um ou mais processadores: fornecem uma indicação para o cliente de um primeiro nível de serviço de desempenho para o tráfego dentro da primeira zona geográfica, e um segundo nível de serviço de desempenho para o tráfego entre a primeira zona geográfica e segun- da zona geográfica, em que a indicação é formatada de acordo com a interface.
42. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 36, em que as instruções, quando executadas em um ou mais processadores, em que a operação de configuração compreende uma mudan- ça de roteamento no roteador de ponto de extremidade.
43. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 36, em que a interface compreende pelo menos um de: uma interface de programação de aplicativos, uma interface de linha de comando, uma interface gráfica do usuário, ou uma interface da web.
44. Sistema que compreende: uma coleção de recursos alocados a um primeiro cliente de uma rede do provedor e ligada a uma primeira rede do cliente do primeiro cliente através de um primeiro link físico dedicado; e um coordenador de conectividade; em que o coordenador de conectividade é operável para: implementar uma interface que define as operações de conectividade dispo- níveis a uma pluralidade de clientes da rede do provedor, incluindo o primeiro cliente e um segundo cliente;
transmitir uma notificação formatada de acordo com a interface para o se- gundo cliente, indicando que o acesso a um serviço implementado pelo primeiro cli- ente na coleção de recursos é configurável através de um caminho que compreende um segundo link físico dedicado, em que o segundo link físico dedicado conecta uma segunda rede do cliente para a rede do provedor; e em resposta a uma solicitação de assinatura do segundo cliente formatada de acordo com a interface, executar uma ou mais operações de configuração para permitir que uma solicitação para o serviço da rede do segundo cliente seja roteada para a coleção de recursos, usando o segundo link físico dedicado.
45. Sistema, conforme relatado na cláusula 44, em que o coordenador de conectividade é operável ainda para: receber uma solicitação de descoberta de serviço a partir do segundo clien- te, formatada de acordo com a interface; em que a notificação formatada de acordo com a interface é gerada em res- posta à solicitação de descoberta de serviço.
46. Sistema, conforme relatado na cláusula 44, em que o coordenador de conectividade é operável ainda para: receber uma solicitação de anúncio de serviço do primeiro cliente, formatada de acordo com a interface, indicando que o serviço está disponível para assinatura; em que a notificação formatada de acordo com a interface é gerada após a solicitação de anúncio de serviço ser recebida.
47. Sistema, conforme relatado na cláusula 44, em que a notificação com- preende um indicador de preço para o serviço.
48. Sistema, conforme relatado na cláusula 44, em que a interface compre- ende pelo menos um de: uma interface de programação de aplicativos, uma interfa- ce de linha de comando, uma interface gráfica do usuário, ou uma interface da web.
49. Método que compreende:
apresentar um serviço de conectividade a uma pluralidade de clientes de uma rede do provedor, incluindo um primeiro cliente e um segundo cliente, em que o referido serviço de conectividade inclui um coordenador de conectividade, implemen- tando uma interface programática que define as operações de conectividade dispo- níveis para a pluralidade de clientes; transmitir, ao segundo cliente, de uma notificação formatada de acordo com a interface, indicando que um serviço implementado pelo primeiro cliente em uma primeira coleção de recursos da rede do provedor está disponível para assinatura; e, em resposta a uma solicitação de assinatura do segundo cliente formatada de acordo com a interface, executar uma ou mais operações de configuração para permitir que uma solicitação para o serviço a partir da rede do cliente do segundo cliente seja roteada para a primeira coleção de recursos, usando um link físico dedi- cado estabelecido entre a rede do cliente e a rede do provedor.
50. Método, conforme relatado na cláusula 49, em que a notificação com- preende um ou mais indicadores de preço para o serviço.
51. Método, conforme relatado na cláusula 50, em que um ou mais indicado- res de preço para o serviço incluem um primeiro indicador de preço para um primeiro período de tempo, e um segundo indicador de preço para um segundo período de tempo.
52. Método, conforme relatado na cláusula 50, em que um ou mais indicado- res de preço para o serviço incluem uma taxa de assinatura cobrada pelo primeiro cliente, e uma taxa de uso de rede cobrada por um operador da rede do provedor.
53. Método, conforme relatado na cláusula 50, em que um indicador de pre- ço de um ou mais indicadores preço baseia-se em pelo menos um de: uma quanti- dade de tráfego de rede associado ao serviço, ou uma distância pela qual o tráfego da rede associado ao serviço é transmitido.
54. Método, conforme relatado na cláusula 49, que compreende ainda:
validar, antes de transmitir a notificação, que a notificação está em conformi- dade com uma ou mais políticas de acesso associada à primeira coleção de recurso; e validar, antes de realizar uma ou mais operações de configuração, que uma ou mais operações de configuração estão em conformidade com uma ou mais políti- cas de acesso.
55. Método, conforme relatado na cláusula 49, que compreende ainda: antes de realizar uma ou mais operações de configuração em resposta à so- licitação de inscrição, verificar, usando uma ou mais comunicações com o primeiro cliente formatado de acordo com a interface, que a solicitação de assinatura é acei- tável para o primeiro cliente.
56. Método, conforme relatado na cláusula 49, que compreende ainda: receber uma solicitação de anúncio de serviço do primeiro cliente, formatada de acordo com a interface, indicando que o serviço está disponível para assinatura;
57. Método, conforme relatado na cláusula 49, que compreende ainda: receber um indicador de disponibilidade de campo de assinatura do primeiro cliente, formatado em conformidade com a interface, compreendendo uma indicação do número de assinaturas disponíveis para o serviço.
58. Método, conforme relatado na cláusula 49, que compreende ainda: receber uma solicitação de descoberta de serviço do segundo cliente, forma- tada de acordo com a interface; em que a transmissão da notificação é responsiva à solicitação de descober- ta de serviço.
59. Método, conforme relatado na cláusula 49, em que uma ou mais opera- ções de configuração compreendem o estabelecimento de um caminho de rede logi- camente isolada ao longo do link físico dedicado.
60. Método, conforme relatado na cláusula 49, em que uma ou mais opera-
ções de configuração compreendem uma mudança de roteamento em um roteador da rede do provedor.
61. Meio de armazenamento acessível por computador não transitório que armazena as instruções do programa que, quando executadas em um ou mais pro- cessadores: implementam uma interface programática que define as operações de co- nectividade disponíveis para uma pluralidade de clientes de uma rede do provedor, incluindo um primeiro cliente e um segundo cliente; transmitem, ao segundo cliente, uma notificação formatada de acordo com a interface, indicando que um serviço implementado pelo primeiro cliente em uma pri- meira coleção de recursos da rede do provedor está disponível para assinatura; e, em resposta a uma solicitação de assinatura do segundo cliente formatada de acordo com a interface, executam uma ou mais operações de configuração para permitir que uma solicitação para o serviço a partir da rede do cliente do segundo cliente seja roteada para a primeira coleção de recursos, usando um link físico dedi- cado estabelecido entre a rede do cliente e a rede do provedor.
62. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 61, em que a notificação compreende um ou mais indica- dores de preço para o serviço.
63. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 61, em que as instruções, quando executadas em um ou mais processadores: antes de realizar uma ou mais operações de configuração em resposta à so- licitação de assinatura, verifica, usando uma ou mais comunicações formatadas de acordo com a interface, que a solicitação de assinatura é aceitável para o primeiro cliente.
64. Meio de armazenamento acessível por computador não transitório, con-
forme relatado na cláusula 61, em que as instruções, quando executadas em um ou mais processadores: recebem uma solicitação de anúncio de serviço do primeiro cliente, formata- da de acordo com a interface, indicando que o serviço está disponível para assinatu- ra;
65. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 61, em que as instruções, quando executadas em um ou mais processadores: recebem um indicador de disponibilidade de campo de assinatura do primei- ro cliente, formatado de acordo com a interface, compreendendo uma indicação do número de assinaturas disponíveis para o serviço.
66. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 61, em que as instruções, quando executadas em um ou mais processadores: recebem uma solicitação de descoberta de serviço do segundo cliente, for- matada de acordo com a interface; em que a notificação é transmitida em resposta à solicitação de descoberta de serviço.
67. Meio de armazenamento acessível por computador não transitório, con- forme relatado na cláusula 61, em que uma ou mais operações de configuração compreendem o estabelecimento de um caminho de rede logicamente isolada ao longo do link físico dedicado.
68. Meio de armazenamento acessível por computador não transitório, con- forme indicada na cláusula 61, em que uma ou mais operações de configuração compreendem uma mudança de roteamento em um roteador da rede do provedor.
Sistema computacional ilustrativo
[0085] Em pelo menos algumas modalidades, um servidor que implementa uma porção ou a totalidade de uma ou mais das tecnologias descritas neste docu- mento, incluindo as técnicas para implementar uma interface que define diversos serviços de conectividade e operações, e para receber e responder a vários tipos de solicitações de conectividade através da interface, pode incluir um sistema computa- cional de uso geral que inclui ou está configurado para acessar um ou mais meios de comunicação acessíveis por computador, tais como o sistema computacional 2000 ilustrado na Figura 20. Na modalidade ilustrada, o sistema computacional 2000 inclui um ou mais processadores 2010 acoplados a uma memória do sistema 2020, atra- vés de uma interface de entrada/saída (I/O) 2030. O sistema computacional 2000 inclui ainda uma interface de rede 2040 acoplada à interface de I/O 2030.
[0086] Em várias modalidades, o sistema computacional 2000 pode ser um sistema de uniprocessador, incluindo um processador 2010, ou em um sistema de multiprocessadores, incluindo vários processadores 2010 (por exemplo, dois, quatro, oito, ou outro número adequado). Os processadores 2010 podem ser quaisquer pro- cessadores adequados capazes de executar instruções. Por exemplo, em várias modalidades, os processadores 2010 podem ser de uso geral ou processadores embutidos que implementam qualquer um de uma variedade de arquiteturas de con- junto de instruções (ISAs), tais como os ISAs x86, PowerPC, SPARC, ou MIPS, ou qualquer outro ISA adequado. Em sistemas com multiprocessadores, cada um dos processadores 2010 pode comumente, mas não necessariamente, implementar a mesma ISA.
[0087] A memória do sistema 2020 pode ser configurada para armazenar instruções e dados acessíveis pelo(s) processador(s) 2010. Em várias modalidades, a memória do sistema 2020 pode ser implementada usando qualquer tecnologia de memória adequada, tal como a memória estática de acesso aleatório (SRAM), RAM dinâmica síncrona (SDRAM), memória do tipo Flash/não volátil, ou qualquer outro tipo de memória. Na modalidade ilustrada, as instruções do programa e os dados que implementam uma ou mais funções desejadas, tais como esses métodos, técni- cas e dados descritos acima, são mostradas armazenadas dentro da memória do sistema 2020 como o código 2025 e os dados 2026.
[0088] Em uma modalidade, a interface de I/O 2030 pode ser configurada para coordenar o tráfego de I/O entre o processador 2010, a memória do sistema 2020, e quaisquer dispositivos periféricos no dispositivo, incluindo a interface da re- de 2040 ou outras interfaces periféricas. Em algumas modalidades, a interface de I/O 2030 pode executar qualquer protocolo necessário, cronometragem ou outras transformações de dados para converter sinais de dados de um componente (por exemplo, memória do sistema 2020) em um formato adequado para uso por outro componente (por exemplo, processador 2010). Em algumas modalidades, a interface de I/O 2030 pode incluir suporte para os dispositivos anexados através de vários tipos de barramentos periféricos, tais como uma variante do barramento de Interco- nexão de Componentes Periféricos (PCI) padrão ou o Barramento Serial Universal (USB) padrão, por exemplo. Em algumas modalidades, a função da interface de I/O 2030 pode ser dividida em dois ou mais componentes separados, tal como uma pon- te norte e ponte sul, por exemplo. Além disso, em algumas modalidades, alguma ou toda a funcionalidade da interface de I/O 2030, tal como uma interface para a memó- ria do sistema 2020, pode ser incorporada diretamente no processador 2010.
[0089] A interface de rede 2040 pode ser configurada para permitir que os dados sejam trocados entre o sistema computacional 2000 e outros dispositivos 2060 anexados a uma rede ou redes 2050, tais como sistemas ou dispositivos com- putacionais, conforme ilustrado nas Figuras 1 a 20, por exemplo. Em várias modali- dades, a interface de rede 2040 pode suportar a comunicação através de quaisquer redes adequadas de dados gerais com fio ou sem fio, tais como os tipos de rede Ethernet, por exemplo. Adicionalmente, a interface da rede 2040 pode suportar a comunicação através das redes de telecomunicações/telefonia, tais como redes de voz analógicas ou redes de comunicações de fibra digital, através das redes de área de armazenamento, tais como Canal de Fibra SANs, ou através de qualquer outro tipo adequado de rede e/ou protocolo.
[0090] Em algumas modalidades, a memória do sistema 2020 pode ser uma modalidade de um meio acessível por computador configurado para armazenar ins- truções e dados de programa, conforme descrito acima para as Figuras 1 a 19, para a implementação de modalidades de métodos e aparelhos para as interfaces geren- ciarem trocas de tráfego de rede diretas. No entanto, em outras modalidades, as ins- truções e/ou dados do programa podem ser recebidos, enviados ou armazenados em diferentes tipos de meios acessíveis por computador. De forma geral, um meio acessível por computador pode incluir mídias de armazenamento não transitórias ou mídias de memória, tais como mídias magnéticas ou ópticas, por exemplo, disco ou DVD/CD acoplado ao sistema computacional 2000 através da interface de I/O 2030.
Um meio de armazenamento acessível por computador não transitório pode incluir também quaisquer mídias voláteis ou não voláteis, tais como RAM (por exemplo, SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc, que podem estar incluídas em algumas modalidades do sistema computacional 2000 como memória do sistema 2020 ou outro tipo de memória. Além disso, um meio acessível por computador pode incluir meios de transmissão ou sinais, tais como sinais elétricos, eletromagnéticos ou digitas, transportados através de um meio de comunicação, tal como uma rede e/ou um link sem fio, tal como pode ser implementado através da interface da rede
2040.
Conclusão
[0091] Várias modalidades podem incluir ainda receber, enviar ou armazenar instruções e/ou dados implementados, de acordo com a descrição acima sobre um meio acessível por computador. De forma geral, um meio acessível por computador pode incluir mídias de armazenamento ou mídias de memória, tais como mídias magnéticas ou ópticas, por exemplo, disco ou DVD/CD-ROM, mídias voláteis ou não voláteis, tais como RAM (por exemplo, SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., bem como mídias de transmissão ou sinais, tais como sinais elétricos, eletro- magnéticos ou digitas, transmitidos através de um meio de comunicação, tal como uma rede e/ou um link sem fio.
[0092] Os diversos métodos, conforme ilustrado nas Figuras e descrito neste documento, representam modalidades exemplares dos métodos. Os métodos podem ser implementados em software, hardware ou uma combinação dos mesmos. A or- dem do método pode ser mudada, e vários elementos podem ser adicionados, reor- denados, combinados, omitidos, modificados, etc.
[0093] Várias modificações e alterações podem ser feitas, como estaria ób- vio para uma pessoa versada na técnica tendo o benefício desta divulgação. Desti- na-se a abranger todas essas modificações e alterações e, nesse sentido, a descri- ção acima deve ser considerada em um sentido ilustrativo, em vez de um sentido restritivo.

Claims (15)

REIVINDICAÇÕES
1. Método CARACTERIZADO pelo fato de que compreende: apresentar um serviço de conectividade a um cliente de uma rede do prove- dor, em que o referido serviço de conectividade inclui um coordenador de conectivi- dade, implementando uma interface programática que define as operações de co- nectividade disponíveis para o cliente; receber, no coordenador da conectividade, uma solicitação de conectividade para a conectividade dedicada para uma coleção de recursos da rede do provedor, em que a solicitação de conectividade é formatada de acordo com a interface; em resposta à solicitação de conectividade, selecionar um roteador de ponto de extremidade de destino de uma plurali- dade de roteadores de ponto de extremidade da rede do provedor, em que o rotea- dor de ponto de extremidade de destino é configurável para fornecer uma rota ao longo de uma rede privada para a coleção de recursos em conformidade com a soli- citação de conectividade; gerar uma notificação que compreende as informações de configuração para um link da rede física a ser estabelecido para o roteador de ponto de extremidade de destino para fornecer pelo menos uma porção da conectividade dedicada; e transmitir a notificação.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende ainda: receber informações de identificação de um dispositivo de rede a ser usado para transmitir o tráfego de rede do cliente para a coleção de recursos; e fornecer uma ou mais instruções de configuração para o dispositivo de rede com base nas informações de identificação.
3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a coleção de recursos compreende uma pluralidade de recursos, compreenden-
do ainda: receber um ou mais critérios de seleção, identificando um subconjunto da pluralidade de recursos para os quais uma conexão isolada deve ser fornecida ao longo do link da rede física; e rotear o tráfego de rede em conformidade com os critérios de seleção.
4. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que um critério de seleção de um ou mais critérios de seleção compreende uma identificação da rede de área local virtual (VLAN).
5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o roteador de ponto de extremidade de destino está alojado dentro de uma ins- talação que requer autorização para o acesso físico, e em que a notificação inclui uma indicação de uma autorização do acesso físico para o roteador de ponto de ex- tremidade de destino na instalação.
6. Método, de acordo coma a reivindicação 1, CARACTERIZADO pelo fato de que a transmissão da notificação compreende o envio da notificação a um opera- dor de uma instalação na qual o roteador de ponto de extremidade de destino está alojado.
7. Sistema CARACTERIZADO pelo fato de que compreende: um ou mais processadores; e um meio de armazenamento acessível por computador não transitório que armazena instruções do programa que, quando executado em um ou mais proces- sadores, faz com que o sistema: implemente uma interface programática que define as operações de conecti- vidade disponíveis para um cliente de uma rede do provedor; e receba uma solicitação de conectividade do cliente para a conectividade de- dicada para uma coleção de recursos da rede do provedor, em que a solicitação de conectividade é formatada em conformidade com a interface;
em resposta à solicitação de conectividade, gere uma notificação que compreende informações de configuração para um link da rede física a ser estabelecido para um roteador de ponto de extremidade de destino da rede do provedor para fornecer, pelo menos, uma porção da conectivida- de dedicada, em que o roteador de ponto de extremidade de destino é configurável para fornecer uma rota ao longo de um caminho de rede privada para a coleção de recursos em conformidade com a solicitação de conectividade; e transmita a notificação.
8. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que as instruções do programa, quando executadas em um ou mais processado- res, fazem com que o sistema: após o link da rede física ter sido estabelecido, transmita uma mensagem de confirmação, indicando que a conectividade dedicada foi fornecida.
9. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que as informações de configuração compreendem pelo menos um de:uma porta física do roteador de ponto de extremidade de destino, um identificador de rack, um identificador de caixa ou um identificador do painel de conexões.
10. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a solicitação de conectividade compreende um ou mais de: uma exigência de largura de banda, uma exigência de disponibilidade, ou uma exigência de uma plura- lidade de caminhos físicos para a coleção de recursos.
11. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que as instruções do programa, quando executadas em um ou mais processado- res, fazem com que o sistema: receba informações de identificação de um dispositivo de rede a ser usado para transmitir o tráfego de rede do cliente para a coleção de recursos; e forneça uma ou mais instruções de configuração para o dispositivo de rede com base nas informações de identificação.
12. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a coleção de recursos compreende uma pluralidade de recursos, em que as instruções do programa, quando executadas em um ou mais processadores, fazem com que o sistema: receba um ou mais critérios de seleção que identificam um subconjunto da pluralidade de recursos para os quais uma conexão isolada deve ser fornecida ao longo do link da rede física; e gere informações de roteamento para rotear o tráfego da rede em conformi- dade com os critérios de seleção.
13. Sistema, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que um critério de seleção de um ou mais critérios de seleção compreende uma identificação da rede de área local virtual (VLAN).
14. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que o roteador de ponto de extremidade de destino está alojado dentro de uma instalação que requer autorização para o acesso físico, e em que a notificação inclui uma indicação de uma autorização do acesso físico para o roteador de ponto de ex- tremidade de destino na instalação.
15. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que as informações de configuração compreendem uma identificação de uma localização física do roteador de ponto de extremidade de destino.
BR112014012931-2A 2011-11-29 2012-11-26 Método e sistema para proporcionar conectividade dedicada BR112014012931B1 (pt)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US13/306,775 US8724642B2 (en) 2011-11-29 2011-11-29 Interfaces to manage direct network peerings
US13/306,775 2011-11-29
US13/306.775 2011-11-29
US13/335,465 US10015083B2 (en) 2011-12-22 2011-12-22 Interfaces to manage inter-region connectivity for direct network peerings
US13/335,465 2011-12-22
US13/335.465 2011-12-22
US13/335.490 2011-12-22
US13/335,490 2011-12-22
US13/335,490 US8495199B2 (en) 2011-12-22 2011-12-22 Interfaces to manage service marketplaces accessible via direct network peerings
PCT/US2012/066517 WO2013081962A1 (en) 2011-11-29 2012-11-26 Interfaces to manage direct network peerings

Publications (2)

Publication Number Publication Date
BR112014012931A2 true BR112014012931A2 (pt) 2021-05-25
BR112014012931B1 BR112014012931B1 (pt) 2021-09-14

Family

ID=48535962

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112014012931-2A BR112014012931B1 (pt) 2011-11-29 2012-11-26 Método e sistema para proporcionar conectividade dedicada

Country Status (9)

Country Link
EP (3) EP2786261B1 (pt)
JP (5) JP2014534789A (pt)
CN (2) CN109039772B (pt)
AU (1) AU2012346263B2 (pt)
BR (1) BR112014012931B1 (pt)
CA (1) CA2857132C (pt)
RU (1) RU2595942C2 (pt)
SG (1) SG2014013510A (pt)
WO (1) WO2013081962A1 (pt)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9692732B2 (en) * 2011-11-29 2017-06-27 Amazon Technologies, Inc. Network connection automation
JP2014534789A (ja) * 2011-11-29 2014-12-18 アマゾン・テクノロジーズ・インコーポレーテッド 直接ネットワークピアリングを管理するためのインターフェース
US9984158B2 (en) 2014-03-18 2018-05-29 Axis Ab Finding services in a service-oriented architecture (SOA) network
US9647883B2 (en) 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US9059941B1 (en) * 2014-05-29 2015-06-16 Amazon Technologies, Inc. Providing router information according to a programmatic interface
US10079779B2 (en) 2015-01-30 2018-09-18 Nicira, Inc. Implementing logical router uplinks
US10129142B2 (en) 2015-08-11 2018-11-13 Nicira, Inc. Route configuration for logical router
US10075363B2 (en) 2015-08-31 2018-09-11 Nicira, Inc. Authorization for advertised routes among logical routers
CN106528362B (zh) * 2015-09-10 2019-03-19 阿里巴巴集团控股有限公司 一种流量隔离方法及装置
US10095535B2 (en) 2015-10-31 2018-10-09 Nicira, Inc. Static route types for logical routers
US10153973B2 (en) 2016-06-29 2018-12-11 Nicira, Inc. Installation of routing tables for logical router in route server mode
CN107707583B (zh) * 2016-08-08 2020-11-17 环旭电子股份有限公司 云端数据传输系统及其动态分流方法
US10454758B2 (en) 2016-08-31 2019-10-22 Nicira, Inc. Edge node cluster network redundancy and fast convergence using an underlay anycast VTEP IP
CN110557332B (zh) * 2018-05-31 2022-05-06 阿里巴巴集团控股有限公司 网络构建方法、系统及路由设备
US10931560B2 (en) 2018-11-23 2021-02-23 Vmware, Inc. Using route type to determine routing protocol behavior
US10797998B2 (en) 2018-12-05 2020-10-06 Vmware, Inc. Route server for distributed routers using hierarchical routing protocol
US10938788B2 (en) 2018-12-12 2021-03-02 Vmware, Inc. Static routes for policy-based VPN
JP7205443B2 (ja) * 2019-10-29 2023-01-17 日本電信電話株式会社 通信システム
CN111818183B (zh) * 2020-08-31 2021-12-03 江苏未来智慧信息科技有限公司 一种基于设备特性的电力生产工况监控方法
US20230254321A1 (en) * 2022-02-09 2023-08-10 Microsoft Technology Licensing, Llc Adaptive authorization with local route identifier

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998000784A1 (en) * 1996-06-28 1998-01-08 Mci Communications Corporation System and method for reporting telecommunication service conditions
EP0883075A3 (en) * 1997-06-05 1999-01-27 Nortel Networks Corporation A method and apparatus for forecasting future values of a time series
US6574661B1 (en) * 1997-09-26 2003-06-03 Mci Communications Corporation Integrated proxy interface for web based telecommunication toll-free network management using a network manager for downloading a call routing tree to client
EP1002398A1 (en) * 1998-06-08 2000-05-24 Gatespace AB Application and communication platform for connectivity based services
US6459702B1 (en) * 1999-07-02 2002-10-01 Covad Communications Group, Inc. Securing local loops for providing high bandwidth connections
JP4141106B2 (ja) * 2001-02-06 2008-08-27 富士通株式会社 帯域制御装置
US7313628B2 (en) * 2001-06-28 2007-12-25 Nokia, Inc. Protocol to determine optimal target access routers for seamless IP-level handover
US7197550B2 (en) * 2001-08-23 2007-03-27 The Directv Group, Inc. Automated configuration of a virtual private network
US7292577B1 (en) * 2001-09-19 2007-11-06 Cisco Technology, Inc. End-to-end preservation of VLAN priority in connection-oriented networks
JP3879471B2 (ja) 2001-10-10 2007-02-14 株式会社日立製作所 計算機資源割当方法
US7616746B2 (en) * 2004-08-13 2009-11-10 Qualcomm Incorporated Methods and apparatus for tracking and charging for communications resource reallocation
JP2008523652A (ja) * 2004-12-06 2008-07-03 ネクサジェント リミテッド 仮想プライベートネットワークサービスのサプライチェーンマネジメントのための相互接続システム
US7373661B2 (en) * 2005-02-14 2008-05-13 Ethome, Inc. Systems and methods for automatically configuring and managing network devices and virtual private networks
JP2006245894A (ja) 2005-03-02 2006-09-14 Nippon Telegr & Teleph Corp <Ntt> 転送経路制御装置および転送経路制御プログラム
US7630392B2 (en) * 2005-05-31 2009-12-08 Cisco Technology, Inc. Multi-homing using controlled route leakage at a backup service provider
US7623548B2 (en) * 2005-12-22 2009-11-24 At&T Intellectual Property, I,L.P. Methods, systems, and computer program products for managing access resources in an internet protocol network
JP4879643B2 (ja) 2006-04-28 2012-02-22 株式会社エヌ・ティ・ティ・データ ネットワークアクセス制御システム、端末、アドレス付与装置、端末システム認証装置、ネットワークアクセス制御方法、及び、コンピュータプログラム
US7782801B2 (en) * 2007-05-29 2010-08-24 Red Hat, Inc. Flush support for virtual synchrony
US20080298374A1 (en) * 2007-06-04 2008-12-04 At&T Knowledge Ventures, L.P. Apparatus for monitoring network connectivity
US8028090B2 (en) * 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
CN101483558B (zh) * 2008-01-10 2012-07-04 华为技术有限公司 网络设备接入分组交换网络的方法、系统及装置
EP3002684A1 (en) * 2008-03-31 2016-04-06 Amazon Technologies, Inc. Configuring communications between virtual machines
US8121118B2 (en) * 2008-10-31 2012-02-21 At&T Intellectual Property I, L.P. Methods and apparatus to dynamically control connectivity within virtual private networks
US8230050B1 (en) * 2008-12-10 2012-07-24 Amazon Technologies, Inc. Providing access to configurable private computer networks
US9137209B1 (en) * 2008-12-10 2015-09-15 Amazon Technologies, Inc. Providing local secure network access to remote services
US8306935B2 (en) * 2008-12-22 2012-11-06 Panduit Corp. Physical infrastructure management system
CN101465811A (zh) * 2009-01-07 2009-06-24 上海大学 基于分层移动IPv6协议资源预留方法
US20100226280A1 (en) * 2009-03-03 2010-09-09 Erf Wireless, Inc. Remote secure router configuration
US9106540B2 (en) * 2009-03-30 2015-08-11 Amazon Technologies, Inc. Providing logical networking functionality for managed computer networks
US20100318918A1 (en) * 2009-06-16 2010-12-16 Alireza Mahmoodshahi Communication Path Exchange Service
US8125928B2 (en) * 2009-07-24 2012-02-28 Juniper Networks, Inc. Routing frames in a shortest path computer network for a multi-homed legacy bridge node
US8369333B2 (en) * 2009-10-21 2013-02-05 Alcatel Lucent Method and apparatus for transparent cloud computing with a virtualized network infrastructure
US20110131647A1 (en) * 2009-11-30 2011-06-02 Scott Sanders Virtual Endpoint Solution
US20110231654A1 (en) 2010-03-16 2011-09-22 Gurudas Somadder Method, system and apparatus providing secure infrastructure
EP2630630A2 (en) * 2010-10-21 2013-08-28 Net Power And Light, Inc. System architecture and method for composing and directing participant experiences
US20120151057A1 (en) * 2010-12-03 2012-06-14 Level 3 Communications, Llc Virtualized connectivity in a cloud services environment
CN102026390B (zh) * 2010-12-31 2013-01-09 大唐移动通信设备有限公司 基站及其实现小区间干扰协调的资源分配方法
JP2014534789A (ja) 2011-11-29 2014-12-18 アマゾン・テクノロジーズ・インコーポレーテッド 直接ネットワークピアリングを管理するためのインターフェース

Also Published As

Publication number Publication date
JP6454665B2 (ja) 2019-01-16
RU2595942C2 (ru) 2016-08-27
JP2022050663A (ja) 2022-03-30
JP6674012B2 (ja) 2020-04-01
CA2857132A1 (en) 2013-06-06
EP4009606A1 (en) 2022-06-08
JP2014534789A (ja) 2014-12-18
JP2019071641A (ja) 2019-05-09
EP3678027A1 (en) 2020-07-08
CN109039772A (zh) 2018-12-18
RU2014121322A (ru) 2016-01-27
WO2013081962A1 (en) 2013-06-06
CN109039772B (zh) 2021-08-10
CA2857132C (en) 2018-07-03
BR112014012931B1 (pt) 2021-09-14
EP2786261B1 (en) 2020-02-26
AU2012346263B2 (en) 2015-09-24
CN103959273A (zh) 2014-07-30
EP4009606B1 (en) 2023-09-20
SG2014013510A (en) 2014-07-30
JP7014838B2 (ja) 2022-02-01
EP2786261A1 (en) 2014-10-08
JP2020092462A (ja) 2020-06-11
AU2012346263A1 (en) 2014-06-19
JP7381621B2 (ja) 2023-11-15
EP2786261A4 (en) 2015-07-08
JP2016220247A (ja) 2016-12-22
EP3678027B1 (en) 2022-02-16
CN103959273B (zh) 2018-10-12

Similar Documents

Publication Publication Date Title
US20230239277A1 (en) Interfaces to manage direct network peerings
JP7381621B2 (ja) 直接ネットワークピアリングを管理するためのインターフェース
US10069908B2 (en) Interfaces to manage last-mile connectivity for direct network peerings
US11463351B2 (en) Interfaces to manage inter-region connectivity for direct network peerings
US8495199B2 (en) Interfaces to manage service marketplaces accessible via direct network peerings
AU2017206220B2 (en) Interfaces to manage direct network peerings

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B350 Update of information on the portal [chapter 15.35 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 26/11/2012, OBSERVADAS AS CONDICOES LEGAIS.