Exibir código-fonte para Enciclopedia e desciclopedia 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]'''

=== Introdução ===
Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma "Desciclopédia" (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. 

A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! 

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 às gambiarras!
[[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]

==== Como consultar este artigo ou buscar os termos e expressões desejadas ====
Para este procedimento, sugiro:
* Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;
* Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!
Aprecie sem moderação!

=== Enciclopédia ===

==== 6PE ====
Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.

Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''

O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado "''6PE com BGP-Free Core''" mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.
[[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]

==== 6VPE ====
Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.

Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''

O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.
[[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]

==== AAA ====
Acrônimo: ''Authentication, Authorization, Accounting''.

O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.

<u>Exemplos de cenários onde o AAA é empregado:</u> controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.

==== Access-List ====
Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.

<u>Exemplos de cenários onde uma ACL é empregada:</u> filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego "bypassando" a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.

Uma ACL pode ser considerada um verdadeiro "canivete suíço"! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.

==== AS ====
Acrônimo: ''Autonomous System''.

Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].

Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a "rede" daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.

No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.
[[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]

==== BGP ====
Acrônimo: ''Border Gateway Protocol.''

Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].

O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.

O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:
* [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.

==== BNG ====
Acrônimo: ''Broadband Network Gateway''.

Conheça mais: [[Concentradores PPPoE com IPv6]].

O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo "concentrador BNG"). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que "casam" com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.

==== BRAS ====
Acrônimo: ''Broadband Remote Access Server''.

Vide o acrônimo BNG (Broadband Network Gateway).

==== Caches Enter-Deep ou Bring-Home ====
O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a "nutshell", e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.

Já a estratégia Bring Home ("trazer para casa"), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para "casa", conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.

==== CDN ====
Acrônimo: ''Content Delivery Network''.

Conheça mais: [[CDN Peering e PNI - Brasil]].

Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.

Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.

==== CFP ====
Acrônimo: ''C form-factor pluggable (CFP)''.

O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:

<u>CFP</u> (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). <u>CFP2</u> (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). <u>CFP4</u> (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). <u>CFP8</u> (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). <u>MSA 5″×7″ (Gen 1)</u> (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). <u>MSA 4″×5″ (Gen 2)</u> (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).

==== CGNAT ====
Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''

O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo "''carrier grade''". A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas <u>sem</u> manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E

Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!

==== Control Plane ====
Conheça mais: [[Fundamentos de Roteamento para Provedores]].

Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.

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.
[[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]

==== CPAK ====

==== Data Plane ====
Conheça mais: [[Fundamentos de Roteamento para Provedores]].

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.
[[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]

==== DDoS ====
Acrônimo: ''Distributed Denial of Service''.

Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A <nowiki>[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS</nowiki>].

Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por "profissão e esporte", exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.

==== De-Peering ====
Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um "de-peer" ou "de-peering" frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de "network clean-up". Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e "vacilos" similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.

==== EAQ ====
Acrônimo: ''Entidade Aferidora de Qualidade''

A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.

==== eNodeB ====
O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.

==== Ethernet ====
Conheça mais: [[Fundamentos de Roteamento para Provedores]].

O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.

==== EVPN ====
Acrônimo: ''Ethernet Virtual Private Network''.

Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]

Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância "''All-Active''", além de outras interessantíssimas capacidades e recursos.

==== FlowSpec ====
Acrônimo: ''BGP Flow Specification''.

O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou "buraco negro disparado remotamente"), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo "NEXT_HOP" da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte "cru e nu" do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos "a", "b" e "c" citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência ("matching") suportados e ação de filtragem de tráfego.

O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.

==== FTTH ====
Acrônimo: ''Fiber-to-the-Home''.

O "''Fiber To The Home''" (FTTH), também chamado de "''Fiber To The Premises''" (FTTP) ou ''"Fiber To The Building''" (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.

==== GGSN ====
Acrônimo: ''Gateway GPRS Support Node''.

O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por "ocultar" a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).

==== GPON ====
Acrônimo: ''Gigabit Passive Optical Network''.

==== H-VPLS ====
Acrônimo: ''Hierarchical Virtual Private LAN Service''.

Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).

==== Hub-and-Spoke ====

==== IPFIX ====
Acrônimo: ''Internet Protocol Flow Information Export''.

O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, "''top talkers''", dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão "10", 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide <nowiki>RFC 7011</nowiki> (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.

==== IPoE ====
Acrônimo: ''IP over Ethernet.''

O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais "problemas" do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro "problema" do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o "the new kid on the block", e está por aí desde os primórdios do <nowiki>RFC 894</nowiki>, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.

==== IPv4 ====
Acrônimo: ''Internet Protocol version 4''.

==== IPv6 ====
Acrônimo: ''Internet Protocol version 6''.

==== IRR ====
Acrônimo: ''Internet Routing Registry''.

O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos "''route''" e "''route6''"), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos "''as-set''"), a divulgação da intenção em termos de política de roteamento (por meios de objetos "''aut-num''", com campos "''import''", "''export''", "''mp-import''" e "''mp-export''"), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos "''person''" e "''role''"). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a "Coordenação" e "Validação Global" entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto "''as-set''" principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.

==== IRU ====
Acrônimo: ''Indefeasible Right of Use''.

O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra "indefiável" significa "incapaz de ser anulado ou desfeito". O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.

==== IX ====
Acrônimo: ''Internet Exchange''.

Vide Ponto de Troca de Tráfego (PTT).

==== 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.
[[Arquivo:Bpf-qos-6.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Jitter]]

==== L2VPN ====
Acrônimo: ''Layer 2 Virtual Private Network''.

Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]

O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.

Tecnologias de "''tunneling''" não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).

No entanto, quando utilizando o termo "L2VPN", estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.

O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', "''Clear Channel''", dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.

As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. 
[[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]

==== L3VPN ====
Acrônimo: ''Layer 3 Virtual Private Network''.

==== 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.
[[Arquivo:Bpf-qos-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: latência]]

==== MPLS ====
Acrônimo: ''Multiprotocol Label Switching''.

Conheça mais: [[Redes MPLS para Provedores]].

Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas "''labels''", os quais são especificados em cabeçalhos enxutos chamados de "''shim header''", e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.

==== MPLS Traffic Engineering ====
Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].

O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por "''Make-before-Break''", viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.

==== Multi-CDN ====

==== Multi-tenant ====

==== NAT ====
Acrônimo: ''Network Address Translation''.

Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o "desmatamento" do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como "unha e carne", com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou "''masquerading''" é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT "convencional", e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.

==== NETCONF/Yang ====
Acrônimo: ''Network Configuration''.

Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].

O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no <nowiki>RFC 6241</nowiki>. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração "na mão". O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, "automatizados", é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.

O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.

==== NetFlow ====
A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta "simples" para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.

O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).

==== NFV ====
Acrônimo: ''Network Functions Virtualization''.

Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].

O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware "''commodity''". Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. 

==== NodeB ====
Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).

==== OM ====
OM1 - 

OM2 - 62,5/125 microns

OM4 - 50/125 microns

==== Open/R ====
(IGP virtualizado)

==== OSPF ====
Acrônimo: ''Open Shortest Path First''.

Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]

Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.

==== PCC ====
Acrônimo: ''Path Computation Client.'' 

O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).

==== PCE ====
Acrônimo: ''Path Computation Element''.

O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).

==== PCEP ====
Acrônimo: ''Path Computation Element Communication Protocol''.

O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.

==== Peering ====
Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].

Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').

==== PGW ====
Acrônimo: ''Packet Data Network Gateway''.

==== PNI ====
Acrônimo: ''Private Network Interconnection''.

Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].

O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou "''golden jumper''" ou até por capacidade em redes de transporte ''LAN-to-LAN''.

==== PPPoE ====
Acrônimo: ''Point-to-Point Protocol over Ethernet''.

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.
[[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|600x600px|Enciclopédia: PPPoE]]

==== PTT ====
Acrônimo: ''Ponto de Troca de Tráfego''.

Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].

Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.

==== QoS ====
Acrônimo: ''Quality of Service''.

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 ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka "Telefonia IP e/ou Colaboração"), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. 

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. 
[[Arquivo:Bpf-qos-9.png|centro|miniaturadaimagem|600x600px|Enciclopédia: QoS]]

==== QSFP ====
Acrônimo: ''Quad Small Form Factor Pluggable''.

==== RADIUS ====
Acrônimo: ''Remote Authentication Dial In User Service''.

==== RGI Classe V da Anatel para SCM ====

==== RNC ====
Acrônimo: ''Radio Network Controller''.

==== Roteador ====
Conheça mais: [[Fundamentos de Roteamento para Provedores]].

==== Route-policy ====
Uma route policy é uma ferramenta que "materializa" ou "instrumentaliza", através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma "política de roteamento" é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a "política no papel", como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a "policy" na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, "os comandos" da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos "na forma de CLI" as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos "entrada" (''import'' ou "''in''") e "saída" (''export'' ou "''out''") de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software "JUNOS") implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos ("''terms''") definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de "''route-policy''", com operações intuitivas na forma de "''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.". Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras "''Route Maps''", as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do "vendor" ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.

==== RPKI ====
Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.

==== RTBH ====
Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.

==== RUM ====

==== SBI ====
Acrônimo: ''Settlement Based Interconnect''.

Conheça mais: [[Modelos Interconexão]].

Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.

==== SCM ====
Acrônimo: ''Serviço de Comunicação Multimídia''.

==== SDN ====
Acrônimo: ''Software-Defined Networking''.

Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].

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.
[[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SDN]]

==== SeAC ====
Acrônimo: ''Serviço de Acesso Condicionado''.

==== SFI ====
Acrônimo: ''Settlement-free Interconnect''.

Conheça mais: [[Modelos Interconexão]].

Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.

==== SFP ====
Acrônimo: ''Small Form Factor Pluggable''.

==== Segment Routing (SR) ====

==== Segment Routing v6 (SRv6) ====

==== SGSN ====
Acrônimo: ''Serving GPRS Support Node''.

==== STFC ====
Acrônimo: ''Serviço Telefônico Fixo Comutado''.

==== SMP ====

==== SNMP ====
Acrônimo: ''Simple Network Management Protocol''.
[[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SNMP]]

==== SSH ====
Acrônimo: ''Secure Shell''.

==== Switch ====
Conheça mais: [[Fundamentos de Roteamento para Provedores]].

==== SyncE ====
Acrônimo: ''Synchronous Ethernet''.

O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.

==== TACACS+ ====
Acrônimo: ''Terminal Access Controller Access-Control System Plus''.

==== Telnet ====

==== Trânsito ====

==== uRPF ====
Acrônimo: ''Unicast Reverse Path Forwarding''.

O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de "antispoofing", ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de "antispoofing" de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados ("zumbis"), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem "spoofados" (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o "Antispoofing", que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu "downstream". Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o "''Strict''", "''Feasible''" e "''Loose''". Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo "Antispoofing" do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!

==== VPLS ====
Acrônimo: ''Virtual Private LAN Service''.

Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. 
[[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]

==== VPNv4 ====
Acrônimo: ''Virtual Private Network version 4''.

O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (<nowiki>RFC 4364</nowiki> e <nowiki>RFC 4659</nowiki>), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).

==== VPNv6 ====
Acrônimo: ''Virtual Private Network version 6''.

O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o "''Route Distinguisher''" e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso ("''BGP speaker requesting IPv6 transport''" ou "''BGP speaker requesting IPv4 transport''"). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).

==== VPWS ====
Acrônimo: ''Virtual Private Wire Service''.

Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.
[[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]

==== VxLAN ====
Acrônimo: ''Virtual Extensible LAN''.

Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.

=== Desciclopédia ===

==== Ajuste Fino ====
Ajuste Fino descreve medidas paliativas ou "''worarounds''" para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), "trava" rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização ("reboot") do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) "''você que não sabe configurar''", ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) "''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''". O argumento "b" é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de "Ajuste Fino", e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme "by the books".
[[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]

==== Balance Soma-Link ====
Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de "solução" somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão "genial" quanto os malandros que inventaram o "Balance Soma-Link"! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...
[[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]

==== 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 ====
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 ====
Vide "IP Válido".

Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou <nowiki>RFC 6598</nowiki>).

==== 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, 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 (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!
[[Arquivo:Ippuro.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Puro]]

==== IP Real ====
Vide "IP Válido".

Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou <nowiki>RFC 6598</nowiki>).

==== IP Válido ====
Endereços IP "válidos", na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo <nowiki>RFC 1918</nowiki> (''Address Allocation for Private Internets'') ou <nowiki>RFC 6598</nowiki> (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.

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). 
[[Arquivo:Bpf-desc-ipvalido.png|centro|miniaturadaimagem|421x421px|Desciclopédia: o que seria um IP "inválido"...]]

==== IX Confinado ====

==== Link Dedicado Full Duplex ====

==== Link Semi-Dedicado ====
O "Link Semi-Dedicado" é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.

Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.

Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.

O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?

O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o "meio-termo". Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo "banda larga", usando o termo "dedicado ou semi-dedicado" para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram "driblar", evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é "Semi Dedicado" (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).

Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!
[[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]

==== Lupebequi ====

==== 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, 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. :-)
[[Arquivo:Bpf-desc-rotapresa.png|centro|miniaturadaimagem|518x518px|Desciclopédia: Rota Presa

Fonte: Consultores da Depressão]]

==== SkyGato ====

==== Terraplanistas da Telecom ====
O que seriam "terraplanistas da telecom"? Analogia aos terraplanistas "originais": indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão ("terraplanistas") usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: "A TERRA É PLANA!". Surreal!

Na mesma moeda, analogias aqui, os "''terraplanistas da telecom''" são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''<u>rasgam</u>''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos "gênios da nossa área"; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''<u>nada</u>''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!

Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: "''é mentira que o IPv4 está se esgotando!''", "''o OSPF está morrendo!''", "''operadoras estão deixando de usar o MPLS''", "''a navegação por IPv6 prejudica a performance da minha Internet"'', "''não preciso implantar o IPv6, porque o IPv6 ainda não é usado"'', ''"blackhole é mitigação de DDoS''", "''trânsito sem PTT é melhor''", "''existe trânsito IP puro''", "''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''", dentre outras coisas engraçadas. Note que não são apenas "opiniões": essas situações fazem parte de recomendações de fato que os "terraplanistas da telecom" promovem!

O meu termo aqui de "terraplanistas da telecom" não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?

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|600x600px|Desciclopédia: terraplanistas da telecom]]

'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''
[[Categoria:Geral]]