Enciclopedia e desciclopedia da telecom - Histórico de revisão

Leonardo.furtado em 22h56min de 15 de junho de 2020

2020-06-15T22:56:07Z

Leonardo.furtado em 20h56min de 15 de junho de 2020

2020-06-15T20:56:12Z

Leonardo.furtado em 20h10min de 15 de junho de 2020

2020-06-15T20:10:08Z

Leonardo.furtado em 19h37min de 15 de junho de 2020

2020-06-15T19:37:38Z

Leonardo.furtado em 19h01min de 15 de junho de 2020

2020-06-15T19:01:33Z

Leonardo.furtado em 05h06min de 12 de maio de 2020

2020-05-12T05:06:40Z

Leonardo.furtado em 03h36min de 12 de maio de 2020

2020-05-12T03:36:39Z

Leonardo.furtado: /* Jitter */

2020-04-21T04:17:27Z

Jitter

Leonardo.furtado: /* PPPoE */

2020-04-21T03:51:26Z

PPPoE

Leonardo.furtado: /* VxLAN */

2020-04-21T03:27:41Z

VxLAN

@@ Linha 555: / Linha 555: @@
 ==== Rota Presa ====
-O termo "rota presa" ganhou tração há alguns anos, juntamente com o impulsionamento do crescimento de provedores de acesso à Internet de pequeno porte. Na ocasião, muitos ISPs de pequeno porte, a maioria destes, na verdade, contavam com classes de equipamentos roteadores equipados com arquiteturas de processamento de pacotes baseadas em software (''soft routers''). Com o crescimento da empresa no que diz respeito à base de assinantes, consumo de recursos de rede (banda, enlaces de trânsito IP, sessões, traduções de endereços, etc.), diversos ISPs passaram a experimentar rotineiramente problemas com o BGP, em particular com rotas ficando "presas" na tabela BGP e/ou RIB, mesmo com a sessão BGP correspondente ao recebimento daquelas rotas estando indisponível. Como as situações reportadas por profissionais e consultores da área eram um tanto frequentes, o termo "Rota Presa" acabou generalizando e tornando-se versátil para descrever o óbvio: para tudo há limites. Mesmo que um equipamento ''soft router'' possa ser bastante atraente na relação custo x benefício, e ser capaz de agregar muitos recursos e facilidades interessantes, uma arquitetura de roteamento baseada em processamento de pacotes por interrupções de software frequentemente possui problemas de escalabilidade. Na medida em que aumenta-se o consumo de recursos de rede (banda, sessões, traduções simultâneas de NAT, etc.), o processamento será aumentado proporcionalmente. Até que isto comece a provocar problemas de desempenho e outros incidentes. Isto porque a combinação de classe de hardware de alguns equipamentos conhecidos do mercado, e a arquitetura de soft router, possui limitações nas questões de desempenho e escalabilidade, algo que é igualmente e rotineiramente negligenciado por ISPs e consultores. Mesmo após esta constatação, muitos ISPs continuavam apostando nesta abordagem em termos de arquitetura de roteador para a função de borda, ou seja, postergando o inevitável: já estava na hora de migrar aquela arquitetura para plataformas mais especializadas para esta missão.
+O termo "rota presa" ganhou tração há alguns anos, juntamente com o impulsionamento do crescimento de provedores de acesso à Internet de pequeno porte. Na ocasião, muitos ISPs de pequeno porte, a maioria destes, na verdade, contavam com classes de equipamentos roteadores equipados com arquiteturas de processamento de pacotes baseadas em software, especialmente aqueles que implementavam mecanismos de ''route cache''. Com o crescimento da empresa no que diz respeito à base de assinantes, consumo de recursos de rede (banda, enlaces de trânsito IP, sessões, traduções de endereços, etc.), diversos ISPs passaram a experimentar rotineiramente problemas com o BGP, em particular com rotas ficando "presas" na tabela BGP e/ou RIB, mesmo com a sessão BGP correspondente ao recebimento daquelas rotas estando indisponível. Como as situações reportadas por profissionais e consultores da área eram um tanto frequentes, o termo "Rota Presa" acabou generalizando e tornando-se versátil para descrever o óbvio: para tudo há limites. Mesmo que um equipamento ''soft router'', e que implemente ''route cache'', possa ser bastante atraente na relação custo x benefício, e ser capaz de agregar muitos recursos e facilidades interessantes, uma arquitetura de roteamento baseada em processamento de pacotes por interrupções de software, nestas características, frequentemente possui problemas de escalabilidade, dentre outros problemas. Na medida em que aumenta-se o consumo de recursos de rede (banda, sessões, traduções simultâneas de NAT, etc.), o processamento será aumentado proporcionalmente. Até que isto comece a provocar problemas de desempenho e outros incidentes. Isto porque a combinação de classe de hardware de alguns equipamentos conhecidos do mercado, e a arquitetura de soft router com route cache, possui limitações nas questões de desempenho e escalabilidade, algo que é igualmente e rotineiramente negligenciado por ISPs e consultores. Mesmo após esta constatação, muitos ISPs continuavam apostando nesta abordagem em termos de arquitetura de roteador para a função de borda, ou seja, postergando o inevitável: já estava na hora de migrar aquela arquitetura para plataformas mais especializadas para esta missão.
 O interessante é que há uma relação muito íntima entre a "Rota Presa" e o "Ajuste Fino"! Para alguns, o problema de "rotas presas" e sintomas similares somente pode ser saneado com a migração de arquitetura (trocando o roteador), enquanto, para outros, especialmente os "magos da telecom", o problema de "rota presa" é provocado pela incompetência de quem configura o equipamento, pois basta o sujeito executar alguns procedimentos secretos ("Ajuste Fino") para que este problema não ocorra. :-)

← Edição anterior		Edição das 20h56min de 15 de junho de 2020
Linha 495:		Linha 495:

	==== Bridge Roteada ====		==== Bridge Roteada ====
		+
		+	==== Hiluxer ====
		+	Hiluxer é como são chamados os donos de ISPs que preferem investir em conforto pessoal do que em seus próprios negócios. O "X" da questão não está no fato do dono do ISP querer e poder usufruir daquilo que construiu, ou seja, de ter os seus "mimos", usufruir de sua riqueza e de prover conforto para si e para seus familiares, e sim na forma em que ele negligencia o seu próprio empreendimento. É óbvio que o dono do ISP pode e deve usufruir de tudo aquilo que ele conseguiu conquistar com o sucesso de seu negócio! O problema é que alguns donos de ISPs não fazem a menor idéia do quão necessário é manter a regularidade de investimentos para a engenharia e a operação de redes de um ISP, por mais que sejam... donos de um ISP! Para estes indivíduos, para tudo há uma solução mais simples: investimentos orientados às necessidades de curto prazo apenas (desprezando o longo prazo), soluções minimalistas e centradas no fator de menor custo. O Hiluxer quer fornecer um serviço de primeira qualidade, mas com processos e investimentos de <u>''quinta categoria''</u>!
		+
		+	Os Hiluxers não compreendem alguns fundamentos importantes para a sustentação do próprio negócio, tais como a gestão da cadeia de fornecedores, engenharia e operação de redes (desempenho, disponibilidade, confiabilidade, resiliência, escalabilidade, matriz funcional de qualidade, usabilidade, gerenciamento, segurança, QoE, etc.), além de roadmap de produto, marketing, vendas, logística, atendimento a clientes, e tantos outros. Quando confrontado por times internos (por exemplo, colaboradores da área técnica) para que sejam tomadas decisões importantes para uma questão tecnológica ou desafio operacional da empresa, o Hiluxer interfere de forma improdutiva e frequentemente desviando da solução ou mitigação ideal para sanear o problema ou desafio exposto. Os colaboradores da área técnica de um ISP "Hiluxer" tem que se virar como podem para manter a parte técnica da empresa funcionando, usando todo o tipo de artifício e gambiarra que puderem.
		+
		+	Mas, no entanto, na hora de comprar a nova versão do Hilux... o referido indivíduo não pensa duas vezes, e parte para visitar a concessionária! Isto é real!
		+	[[Arquivo:Bpf-desc-hiluxer.jpg\|centro\|miniaturadaimagem\|600x600px\|Desciclopédia: Toyota Hilux GR Sport - um carro top, sem dúvidas!]]

	==== IP Confinado ====		==== IP Confinado ====

@@ Linha 524: / Linha 524: @@
 Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em "público" e "privado", e não em válido ou inválido (quando o endereço for privativo).
 ==== IX Confinado ====
@@ Linha 546: / Linha 547: @@
 ==== Rota Presa ====
 ==== SkyGato ====

@@ Linha 13: / Linha 13: @@
 OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente.
-Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não as gambiarras!
+Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não às gambiarras!
 [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]
@@ Linha 120: / Linha 120: @@
 Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.
 ==== CPAK ====
@@ Linha 127: / Linha 128: @@
 Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.
 ==== DDoS ====
@@ Linha 220: / Linha 222: @@
 O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das "especificações biológicas" (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.
 ==== L2VPN ====
@@ Linha 242: / Linha 245: @@
 ==== Latência ====
 Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de "rede lenta". O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.
 ==== MPLS ====
@@ Linha 339: / Linha 343: @@
 O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.
 ==== PTT ====
@@ Linha 355: / Linha 360: @@
 O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links.
 ==== QSFP ====
@@ Linha 397: / Linha 403: @@
 Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.
 ==== SeAC ====
@@ Linha 425: / Linha 432: @@
 ==== SNMP ====
 Acrônimo: ''Simple Network Management Protocol''.
 ==== SSH ====
@@ Linha 502: / Linha 510: @@
 ==== IP Puro ====
-O "IP Puro" nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado.
+O "IP Puro" nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado, muitas das vezes até mesmo excluindo tráfego originado de sessões de peering privado (PNI). Ou seja, tráfego exclusivamente obtido por upstreams de trânsito IP. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado.
-O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado "IP Puro" acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O "IP Puro" é um exemplo clássico de nossa Desciclopédia!
+O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs (e de peerings também, em muitos casos) não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado "IP Puro" acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O "IP Puro" é um exemplo clássico de nossa Desciclopédia!
 ==== IP Real ====
@@ Linha 550: / Linha 559: @@
 Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que "''é mentira que o IPv4 está se esgotando''" e coisas deste tipo é um verdadeiro desserviço para a comunidade!
-[[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|700x700px|Desciclopédia: terraplanistas da telecom]]
+[[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|600x600px|Desciclopédia: terraplanistas da telecom]]
 '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''
 [[Categoria:Geral]]

← Edição anterior		Edição das 19h01min de 15 de junho de 2020
Linha 489:		Linha 489:

	==== IP Confinado ====		==== IP Confinado ====
		+	Conheça mais: [[CDN Peering e PNI - Brasil\|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]
		+
		+	O "IP Confinado" é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de "CDNs apenas" para clientes interessados neste tipo de serviço. O que justifica o "IP Confinado" estar sendo listado em nossa desciclopédia não é a parte técnica da "solução" em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que "vende tráfego de CDN", muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na "oferta"; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o "IP Confinado" está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins.
		+
		+	Entenda: é permitido que o ISP venda "implicitamente" o conteúdo de CDNs como parte de uma oferta de "Trânsito IP Parcial" e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.
		+	[[Arquivo:Ipconfinado.png\|centro\|miniaturadaimagem\|600x600px\|Desciclopédia: IP Confinado]]

	==== IP Ilegal ====		==== IP Ilegal ====

← Edição anterior		Edição das 05h06min de 12 de maio de 2020
Linha 1:		Linha 1:
	=== Enciclopédia e "Desciclopédia" da Telecom ===		=== Enciclopédia e "Desciclopédia" da Telecom ===
		+
		+	==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====
		+	Consulte [[Direitos Autorais Licenca de Uso\|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].
		+
	'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''		'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''

← Edição anterior		Edição das 04h17min de 21 de abril de 2020
Linha 213:		Linha 213:

	==== Jitter ====		==== Jitter ====
		+	Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes\|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]
		+
		+	O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das "especificações biológicas" (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.

	==== L2VPN ====		==== L2VPN ====

@@ Linha 330: / Linha 330: @@
 ==== PPPoE ====
 Acrônimo: ''Point-to-Point Protocol over Ethernet''.
 ==== PTT ====

@@ Linha 464: / Linha 464: @@
 ==== VxLAN ====
 Acrônimo: ''Virtual Extensible LAN''.
 === Desciclopédia ===