CDN Peering e PNI - Brasil

Introdução

Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.

É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.

Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e PeeringDB auxiliam bastante. Cerifique-se que você atende à TODOS os requisitos antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para ambos CDN e ISP, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.

Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI é o IPv6. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 a maioria das grandes CDNs já possuem suporte completo à IPv6 portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.

A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.

Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: Modelos_Interconexão

Última atualização - 25/06/2021

Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP

Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:

Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: Bring-Home e Enter-Deep Cache. Foquemos no segundo caso (Enter-Deep), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura Enter-Deep Cache possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:

• Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.
• Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.
• Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.
• O assinante (cliente) é beneficiado por contar com uma Internet "mais fluida", e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.

No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um privilégio. O que muitos ISPs fazem é tratar a CDN como um "direito" deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para "obter uma CDN", e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos "ISP e CDN" (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.

Práticas ilegais exercitadas por alguns ISPs:

• Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.
• Promover abertamente na sua cesta de produtos e soluções que aquele ISP "vende tráfego de CDNs". O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de "Trânsito IP Parcial" ou nome qualquer, desde que não divulgue que "vende CDN" e muito menos expondo logomarcas, fotos dos servidores, etc.
• Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como "IP Confinado" e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.
• Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem "servidores de CDN da empresa X, Y e Z". Isto é igualmente não permitido.

Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do "tequiniquês".

Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual.

Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecermos suas dúvidas. Utilizem as nossas listas de discussão!

CDNs

As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.

O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.

Akamai (AANP)

• Banda mínima: 10 Gbps
• Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
• Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf
• PeeringDB: https://www.peeringdb.com/net/2

Apple

• Banda mínima: 25 Gbps
• Informações: https://cache.edge.apple/
• Solicitação: https://cache.edge.apple/inquire
• PeeringDB: https://peeringdb.com/asn/714
• Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente.

Facebook (FNA)

• Banda mínima: 5 Gbps
• Email: fna@fb.com
• PeeringDB: https://www.peeringdb.com/net/979
• Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.
• Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.

Google (GGC)

• Banda mínima maior que: 3 Gbps - 95 percentil por pelo menos 3 meses.
• Informações: https://peering.google.com/#/options/google-global-cache
• Solicitação: http://isp.google.com/iwantpeering
• Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf
• Troubleshooting: https://cloud.google.com/cdn/docs/support
• Portal: https://isp.google.com/dashboard/
• PeeringDB: https://www.peeringdb.com/net/433https://www.peeringdb.com/net/4319
• Necessário ter registrado em IRR, todos os prefixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690
• Prefixos CGNAT: Aceitos com community. Acesse a documentação no portal.

Globo (GCA)

• Banda mínima: 2 Gbps (Todos os estados)
• Email para dúvidas: gca@g.globo
• Formulário de requisição: https://gca.globo.com/
• PeeringDB: https://www.peeringdb.com/net/5703

Edgio (Edgecast Verizon Digital Media)

• Banda mínima: 10 Gbps
• Email: edgecast-peering@edg.io
• Informações: https://edg.io/peering/
• Solicitação: edgecast-peering@edg.io
• PeeringDB: http://as15133.peeringdb.com/

Netflix (OCA)

• Banda mínima: 5 Gbps (Todos os estados)
• Solicitação: https://openconnect.netflix.com/en/request/
• Instalação: https://openconnect.netflix.com/deploymentguide.pdf
• Troubleshooting: https://openconnect.netflix.com/en/faq/
• Portal: https://my.oc.netflix.com/
• PeeringDB: https://www.peeringdb.com/net/457
• Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.

Azion (ANA)

• Banda mínima: 15 Gbps (Seletiva)
• Email: cdn@azion.com
• Informações: https://www.azion.com.br/developers/peering/
• PeeringDB: https://www.peeringdb.com/net/14511

SourceForge.Net

• Banda mínima: 150Mbps
• Hardware por conta do provedor, com 8TB de disco no mínimo.
• Email: staff@sourceforge.net
• Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/

Microsoft

• Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)
• Email: ispnode@microsoft.com
• Informações: https://peering.azurewebsites.net/Peering/Caching
• PeeringDB: http://as8075.peeringdb.com/

CloudFlare

• Hardware fornecido pela CloudFlare.
• Conexão para os equipamentos em 40GbE ou 100GbE.
• Espaço em rack para acomodação dos equipamentos.
• Conectividade para fazer o cache-fill dos servidores de cache.
• Conectividade para gerência remota da CloudFlare.
• Banda mínima: em revisão junto ao planejamento da nova geração dos servidores, avaliação caso a caso no momento (edição solicitada por Ticiane da Cloudflare).
• PeeringDB: https://www.peeringdb.com/net/4224
• Informações: ticiane@cloudflare.com

Peerings - Sessões Bilaterais

É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte Modelos_Interconexão). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.

Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.

Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.

Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.

A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:

Akamai

• Email: peering@akamai.com e peering-tix@akamai.com
• PeeringDB: https://www.peeringdb.com/net/2

Amazon

• Email: peering@amazon.com
• PeeringDB: https://www.peeringdb.com/net/1418
• Política: Seletiva

Apple

• Email: peering-tech@apple.com
• PeeringDB: https://www.peeringdb.com/asn/714
• Política: Seletiva

Edgio (Edgecast Verizon Digital Media)

• Email NOC: edgecast-noc@edg.io
• Solicitação: edgecast-peering@edg.io
• Informações: https://edg.io/peering/
• PeeringDB: http://as15133.peeringdb.com/
• Política: Seletiva

Microsoft

• Email: peering@microsoft.com
• Solicitação: http://www.microsoft.com/peering
• PeeringDB: http://as8075.peeringdb.com/
• Política: Seletiva

Hurricane Electric

• Email: peering@he.net
• Email NOC: noc@he.net (após sessão estar ativada)
• Informações: http://he.net/peering.html
• PeeringDB: https://www.peeringdb.com/net/291

A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net

Cloudflare

• Email: peering@cloudflare.com
• PeeringDB: https://www.peeringdb.com/net/4224

Azion

• Banda mínima: 5 Gbps (Seletiva)
• Email: peering@azion.com
• PeeringDB: https://www.peeringdb.com/net/14511

Twitch TV

• Email: peering@twitch.tv
• Contato: https://noc.twitch.tv/
• PeeringDB: https://www.peeringdb.com/asn/46489
• Política: Seletiva

Oath/Yahoo

• Email: peering-requests@oath.com
• Informações: https://peering.oath.com/policy
• PeeringDB: https://www.peeringdb.com/asn/10310/
• Política: Seletiva

Netflix

• Banda Minima: 3Gbps
• Email: peering@netflix.com
• PeeringDB: https://www.peeringdb.com/net/457
• Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.

Google

• Email: noc@google.com
• Solicitação: https://isp.google.com/iwantpeering
• PeeringDB: https://www.peeringdb.com/net/433
• Necessário ter registrado em IRR, todos os prefixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690

Facebook

• Email: peering@fb.com
• Informação e Solicitar (on-line): https://www.facebook.com/peering/
• PeeringDB: https://www.peeringdb.com/net/979
• Política: Seletiva
• Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.

IBM Cloud (Softlayer)

• Email: peering@softlayer.com
• PeeringDB: https://www.peeringdb.com/asn/36351
• Política: Seletiva

Riot Games

• Email: peering@riotgames.com
• PeeringDB: https://www.peeringdb.com/asn/6507
• Política: Seletiva

i3D.net / Ubisoft

• Email: peering@i3d.net
• PeeringDB: https://www.peeringdb.com/asn/49544
• Política: Seletiva

Twitter

• Banda mínima: 100 Mbps
• Email: peering@twitter.com
• PeeringDB: https://www.peeringdb.com/asn/13414
• Política: Seletiva

Globo

• Email: peering@peering.globo
• Informações: https://peering.globo
• PeeringDB: https://www.peeringdb.com/net/5703
• Locais: https://peering.globo
• Troubleshooting: https://browserreport.globo.com/isp

Tencent

• Email: peering@tencent.com
• Informações: https://peering.tencent.com/request
• PeeringDB: https://www.peeringdb.com/asn/132203

PNIs - Private Network Interconnection

PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: Modelos_Interconexão). Geralmente é um cross-connect ou golden-jumper entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No PeeringDB é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção "Private Peering Facilities".

Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.

Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.

Normalmente envolve um custo que é o do cross-connect ou golden-jumper que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.

A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:

Facebook

• Banda mínima: 1 Gbps
• Email: peering@fb.com
• Datacenters: Equinix-SP2, Equinix-SP4, Equinix-RJ1, Globenet Fortaleza CLS
• PeeringDB: https://www.peeringdb.com/net/979
• Informações: https://wiki.brasilpeeringforum.org/images/a/ad/Peering_with_Meta.pdf

Google

• Informações: https://peering.google.com/#/options/peering
• Solicitação: http://isp.google.com/iwantpeering
• Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.
• PeeringDB: https://www.peeringdb.com/net/433https://www.peeringdb.com/net/4319
• Necessário ter registrado em IRR, todos os prefixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690
• Modelo LoA: https://isp.google.com/static/downloads/LOA.pdf

Edgio (Edgecast Verizon Digital Media)

• Banda mínima: 1 Gbps
• Email NOC: edgecast-noc@edg.io
• Solicitação: edgecast-peering@edg.io / CarrierRelations@edgecast.com
• Informações: https://edg.io/peering/
• PeeringDB: http://as15133.peeringdb.com/
• Datacenters: Equinix-SP4, Equinix-RJ2

Netflix

• Banda Mínima: 3 Gbps
• Email: peering@netflix.com
• Informações: https://openconnect.netflix.com/en/guidelines/
• Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza
• PeeringDB: https://www.peeringdb.com/net/457

Akamai

• Banda Mínima: 5 Gbps
• Email: netsupport-tix@akamai.com
• Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
• PeeringDB: https://www.peeringdb.com/net/2
• Datacenters: Equinix-SP4, Teleporto-RJ

Azion

• Banda mínima: 20 Gbps
• Email: peering@azion.com / noc@azion.com
• Informações: https://www.azion.com.br/developers/peering/
• Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador
• PeeringDB: https://www.peeringdb.com/net/14511

Twitch TV

• Banda mínima: 2.5 Gbps
• Email: interconnection@twitch.tv
• Contato: https://noc.twitch.tv/
• Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro
• PeeringDB: https://www.peeringdb.com/asn/46489

Globo

• Banda mínima: Não aplicável
• Requisitos: Conexões com fibras apagada de 10Gbps ou 100Gbps, fornecimento dos cordões necessários na localidade.
• Email: peering@peering.globo
• Informações: https://peering.globo
• PeeringDB: https://www.peeringdb.com/net/5703
• Locais: https://peering.globo
• Troubleshooting: https://browserreport.globo.com/isp