Introducao aos conceitos de programabilidade de infraestruturas de redes

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes

Introdução

Este artigo apresentará os fundamentos mais importantes acerca do gerenciamento de infraestruturas de redes e pavimentará a sua jornada, caro leitor da Wiki do BPF, para as questões de programabilidade de infraestruturas de redes e com foco aos ambientes de ISP. Este é mais um daqueles artigos que publico aqui onde a principal intenção ou motivação é a de ensinar, educar, e capacitar e, portanto, o artigo não vai direto ao ponto: conto uma história primeiro, volto no tempo para mostrar algumas coisas e eventos importantes e, lá para o final, é que comento com mais propriedade sobre os aspectos de programabilidade pretendidos por este artigo. Esta abordagem mais didática poderá ser melhor apreciada por leitores mais "leigos".

Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo!

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes: comparando a rede ideal versus os modelos tradicionais

Pré-requisitos

A leitura deste artigo fará muito mais sentido caso você reúna determinados pré-requisitos em termos de conhecimentos técnicos. Recomendo que certifique-se de possuir os conhecimentos equivalentes aos temas discutidos nos seguintes artigos, já publicados na Wiki do Brasil Peering Forum (BPF).

Revisão dos principais conceitos e componentes de uma infraestrutura de redes Metro e IP

Para começarmos com o pé direito, que tal fazermos uma boa revisão sobre os principais componentes e conceitos presentes em uma infraestrutura de redes? Ao término do artigo, talvez esta seção tenha sido bastante útil para você entender melhor as complicações no que diz respeito à manutenção das infraestruturas de redes e como as tecnologias e ferramentas de programabilidade poderão drasticamente atenuar os esforços e custos operacionais.

Dispositivos de rede

Em uma rede de ambiente ISP (aka "service provider") é comum encontrarmos os seguintes tipos de equipamentos ou elementos ativos, que são referências aos dispositivos de rede:

Roteadores: devidamente categorizados por suas funções e missões, em especial em alinhamento com uma infraestrutura de redes hierárquica, modular e estruturada, ou seja roteadores de Acesso, Pré-Agregação, Agregação, Core, Borda de Serviços e Borda de Internet, e também os roteadores de clientes, sejam estes de propriedade do ISP (comodato) ou mantidos pelo próprio cliente. Aqui entram os termos CE ou CPE (Customer Premises Equipment), PE (Provider Edge), P (Provider), e cada um destes, além de seu respectivo posicionamento na hierarquia topológica física e lógica da rede, desempenhando funções tais como LSR (Label Switch Router), LER (Label Edge Router), BNG (Broadband Network Gateway), dentre outros casos.
Switches: praticamente a mesma coisa com relação aos roteadores no que diz respeito ao seus posicionamentos em uma rede, hierarquia e afins. Podendo ser elementos ativos desempenhando funções de encaminhamento de dados puramente de Camada 2 (L2), neste caso o processamento dos quadros (frames), ou multicamadas (L3), neste caso o processamento de pacotes, em ambientes Ethernet ou Ethernet + IP nativos, ou ainda em ambientes MPLS.
GPON: neste caso aqui, sumarizando os dispositivos desta infraestrutura, tais como OLT (Optical Line Terminal), ONU (Optical Network Unit), ONT (Optical Network Terminal), e, por que não, toda a parte passiva (leia-se: não ativa) da infraestrutura, denominada Optical Distribution Network (ODN), e que incluem as fibras ópticas e passivos ópticos, como splitters, conectores, cordões, extensões, caixas de emenda e terminação.

Dispositivos de rede Metro Ethernet, IP, MPLS: roteadores e switches

Protocolos e serviços de infraestruturas de redes

Uma coisa são os dispositivos de redes mencionados anteriormente, outra coisa são as tecnologias (embarcadas nestes dispositivos) que viabilizam o funcionamento de uma rede, em especial no que diz respeito à comunicação necessária entre os elementos ativos para o efetivo transporte do tráfego da rede e dos serviços contratados por seus usuários. Nem de longe atreverei-me a listar tudo, pois isto seria obviamente inviável! Tentemos sintetizar os exemplos a serem citados aqui, pois uma versão completa disso seria quilométrica!

O arranjo destas tecnologias, devidamente organizadas em suas respectivas categorias funcionais, é que costumo chamar de "Salada de Tecnologias"!

Protocolos e serviços de camada 2 (L2): em referência ao modelo de referência OSI (RM-OSI) ou ao modelo TCP/IP, são tecnologias primariamente envolvidas na viabilidade de uma infraestrutura redundante (com foco na maior disponibilidade) isenta de bridging loops, e com capacidades de recuperação de falhas envolvendo enlaces de transmissão ou dos próprios elementos de rede. Exemplos de tecnologias assim: Spanning Tree Protocol (e suas variações, 802.1d (STP), 802.1w (RSTP), 802.1s (MSTP), 802.1aq (Shortest Path Bridging (SPB), e revisões incorporadas ao 802.1Q-2014), Resilient Ethernet Protocol (REP, proprietário), Ethernet Automatic Protection Switching (EAPS, proprietário), G.8032 (Ethernet Ring Protection (ERP) protocol), coexistência de Inter-Chassis Communication Protocol (ICCP) e STP, etc. E, claro, não poderia deixar de mencionar aqui o mais óbvio, que são tecnologias mais básicas e elementares tais como o próprio endereçamento físico (Media Access Control (MAC)) dos dispositivos, Virtual LAN (VLAN), entroncamento 802.1q e 802.1ad (Q-in-Q), etc. E isto focando apenas no óbvio, pois há uma gama muito grande de tecnologias e serviços que implementam funções ou que atuam na camada 2. E, para concluir, L2VPN (VPLS, VPWS, EVPN) também são exemplos de tecnologias para o transporte de tráfego/serviços L2 em uma rede MPLS (VPLS/VPWS) ou MPLS ou VxLAN (EVPN). Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), Layer 2 Protocol Tunneling (L2PT), Point-to-Point Tunneling Protocol (PPTP) são outros exemplos clássicos e empregando conceitos de túneis.
Protocolos e serviços de camada 3 (L3): também em alinhamento ao RM-OSI, são tecnologias que tem como propósito a construção e manutenção de uma rede IP "roteada". Enquadram-se aqui o endereçamento IPv4 e IPv6, protocolos de roteamento dinâmicos (ex: OSPF, IS-IS, EIGRP, BGP, RIPv2 para IPv4, e RIPng, OSPFv3, IS-IS for IPv6, EIGRP for IPv6, BGP para o IPv6), além de rotas conectadas, rotas estáticas, serviços de roteamento por políticas (PBR, ABF ou nome similar usado pelo seu fabricante de equipamento). Enquadram-se também, à título de serviços L3, mas com algumas destas tecnologias implementando funções também em outras camadas, os seguintes: Network Address Translation (NAT), Carrier Grade NAT (CGN), Broadband Network Gateway (BNG, como concentrador PPPoE e/ou IPoE).
Protocolos e serviços orientados à confiabilidade, resiliência e disponibilidade: compreenda estes como serviços periféricos e pensados para melhorarmos a confiabilidade geral da infraestrutura, seja em cenários L2 ou L3, ou ainda ambos. Exemplos de tecnologias que enquadram-se aqui temos o Unidirectional Link Detection (UDLD), Bidirectional Forwarding Detection (BFD), In-Service Software Upgrade (ISSU), Online Insertion and Removal (OIR), Stateful Switchover (SSO), Nonstop Forwarding (NSF) ou Graceful Restart (GR), Non Stop Routing (NSR), MPLS Traffic Engineering Fast Reroute (FRR), Topology Independent LFA (TI-LFA) e RLFA, Segment Routing TI-LFA (SRTILFA), Link Aggregation Control Protocol (LACP), enfim, são exemplos clássicos. Outros exemplos aqui incluem os protocolos de resiliência de primeiro salto ou de default gateway, conhecidos por FHRP (First Hop Redundancy Protocol), tais como o HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol) e GLBP (Gateway Load Balancing Protocol). Isto para não mencionar os mecanismos periféricos presentes em outros protocolos já apresentados, tais como o OSPF LSA e SPF Throttling, BGP Prefix Independent Convergence (PIC), etc.
Protocolos e serviços de suporte à infraestrutura: enquadram-se aqui protocolos e serviços tais como o PPPoE (Point-to-Point Protocol over Ethernet), IPoE (Internet Protocol over Ethernet), DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name System), AAA (Authentication, Authorization, Accounting), RADIUS (Remote Authentication Dial In User Service), TACACS+ (Terminal Access Controller Access-Control System), Diameter, NTP (Network Time Protocol), PTP (Precision Time Protocol), SyncE (Synchronous Ethernet), e outros. As tecnologias com foco no Quality of Service (QoS) também podem ser descritas aqui.
Protocolos e serviços de gerenciamento: figuram aqui, dentre tantos, o Simple Network Management Protocol (SNMP), Remote Network MONitoring (RMON) MIB, Netflow, Internet Protocol Flow Information Export (IPFIX), Telnet, Secure Shell (SSH), SSH File Transfer Protocol (SFTP), Operations, Administration and Maintenance (OAM) incluindo Ethernet OAM Link Fault Management (EOAM LFM), 802.1ag Connectivity Fault Management (CFM), Ethernet Local Management Interface (E-LMI), Ethernet Performance Management, MPLS OAM; Network Configuration e modelos Yang (NETCONF/Yang), interface RESTful para a modelagem Yang com RESTCONF, Technical Report 069 (TR-69) e substitutos, dentre tantos outros protocolos, serviços e procedimentos.
Protocolos e serviços de segurança da infraestrutura: há tantos casos para citar aqui, tentarei ser mais prático. Port Security, 802.1X IBNS, Network Admission Control (NAC), Private VLAN, Dynamic ARP Inspection (DAI), DHCP Snooping, IP Source Guard (IPSG), Root Guard, BPDU Guard, BPDU Filtering, mecanismos de autenticação dos protocolos de roteamento, mecanismos de autenticação de protocolos MPLS (LDP e RSVP-TE), filtros e políticas de roteamento, BGP Flowspec, Remotely Triggered Black Hole (RTBH), stateful packet filtering, BGP Resource Public Key Infrastructure (RPKI), Control Plane Policing (CoPP/dCoPP), Broadcast, Unicast and Multicast (BUM) Storm Control, limitação de prefixos mantidos em tabelas de roteamento, Unicast Reverse Path Forwarding (uRPF), e tantas outras. E isto com relação às tecnologias, pois devem ser considerados também os appliances (dispositivos) de segurança que embarcam estas tecnologias e serviços, tais como firewalls, UTMs, etc.

Que "salada" de tecnologias! É tanta coisa que temos que nos preocupar em fazer funcionar corretamente e conforme as boas práticas!

Sistemas e serviços de suporte à infraestrutura

A lista de situações aqui é mais simples, mas não menos complexa:

Sistemas de Suporte ao Negócio (BSS)
Sistemas de Suporte à Operação (OSS)
Serviços de Diretório (ex: LDAP, Active Directory)
Infraestrutura Public Key Infrastructure (PKI)
Sistema IP Address Management (IPAM)
Sistemas específicos para fins de gerenciamento de elementos e de infraestrutura (EMS e NMS), com baixa ou parcial aderência aos padrões OSS.
Etc.

Exemplo de integrações de sistemas OSS e BSS, demonstrando a solução IBM Catalog Driven Order Management Solution. Note o "SID", um dos padrões do TM Forum Frameworx!

OBS: no segmento de ISPs regionais de pequeno e médio portes é onde compreendemos, também, uma diferença bastante acentuada entre os padrões de sistemas empregados por estes quando comparados aos sistemas de gestão operacional e de negócios dos operadores de redes "grandes". Nos ISPs regionais, é muito mais comum o uso de sistemas específicos que operam de forma completamente independente e com nenhuma ou mínima troca ou compartilhamento de dados entre si, para lidar com as necessidades gerais, técnicas e operacionais inclusive, mesmo que sendo funcionais para a realidade desta empresas. No entanto, a ausência das devidas e desejadas integrações entre estes sistemas (vide Frameworx (eTOM BPF, SID, TAM, TNA)) dificulta ou literalmente inviabiliza uma solução legitimamente projetada para fins de automação, orquestração e provisionamento, exigindo que ocorram, quase que para todos os casos e situações, ações diretas com intervenção humana sobre os equipamentos (por meios de acessos via CLI, por exemplo) para a ativação ou provisionamento de serviços de clientes.

Áreas sistêmicas das arquiteturas de roteadores e switches

Tantos destes protocolos e serviços de rede citados na seção anterior precisam ser selecionados e configurados por você, um por um, e conforme diretivas do seu projeto técnico (ex: configurações homologadas, boas práticas, validação de sintaxe e semântica, etc.) para que possam convergir e fornecer o transporte e a efetiva viabilidade dos serviços e produtos contratados pelos clientes. Para fazer toda a coisa acontecer, há um determinado arranjo de dependências entre as tecnologias necessárias onde, em muitos casos, para que uma determinada tecnologia que você configurou possa funcionar, são necessários o suporte e o funcionamento de outras tecnologias e serviços, as quais, por sua vez, precisarão ser também pensadas, projetadas, e configuradas por... você! Para exemplificar aqui, para que o BGP de seu AS possa operar é necessário o roteamento recursivo para o transporte das sessões IBGP e a devida resolução do atributo NEXT_HOP das rotas mantidas pelo BGP, e isto significa que você precisará adotar um protocolo de roteamento interior (IGP), provavelmente o OSPF aqui, o qual, por sua vez, depende de endereçamento IP, definição das tecnologias de enlace (VLANs, entroncamentos, etc.) e das tecnologias de transmissão (L1). Ou seja, uma coisa depende da outra.

Em particular, roteadores e switches em uma rede mantém áreas sistêmicas e funcionais para os propósitos de conectividade e de serviços:

Plano de Controle: área sistêmica responsável por hospedar protocolos que forneçam entendimento e convergência para fins de encaminhamento de tráfego L2 (ex: STP, REP, EAPS...) e L3 (ex: OSPF, IS-IS, BGP, etc.), e até mesmo "L2.5" (ex: MPLS). Não somente os protocolos são mantidos nesta área, mas também as suas respectivas estruturas de dados, tais como o Link-State Database (LSDB) do OSPF, o Label Information Base (LIB) do MPLS LDP, a BGP Table do BGP, e a própria tabela de roteamento IP (Routing Information Base ou RIB) do roteador.
Plano de Dados: área sistêmica responsável por hospedar as estruturas de dados especificamente orientadas ao processamento e efetivo encaminhamento de pacotes, tais como a Forwarding Information Base (FIB) ou Forwarding Table, Label Forwarding Information Table (LFIB), Adjacency Table (ADJ) ou similar, isto no caso dos roteadores, e Content Addressable Memory (CAM) ou MAC Table, no caso dos switches, além de outras estruturas de dados que possam servir para funções adicionais da cadeia de processamento de pacotes, geralmente organizadas em TCAMs (Ternary Content Addressable Memory), para o acionamento de manipulações de cabeçalhos, QoS, ACL, etc.
Plano de Gerenciamento: responsável por hospedar e manter os serviços de gerenciamento do dispositivo, tais como Telnet, SSH, SNMP, NETCONF, HTTP server, Syslog, NTP, etc.
Plano de Serviços: responsável por manter processos relacionados ao RADIUS, TACACS+, PPPoE, IPoE, IPsec, NAT, QoS, Stateful Firewall, AVC, etc.

É importante salientar que o modelo de computação em rede tradicional é completamente distribuído, ou seja, que estas áreas sistêmicas supracitadas são independentes e localmente significantes para cada dispositivo. Isto significa que o estado de informação de cada processo de software referente a um destes protocolos e serviços é mantido por cada equipamento, independentemente, podendo haver, em alguns casos, alguma integração entre equipamentos distintos para um determinado componente.

Projeto técnico compatível com o plano de negócios

Você deve ter notado a quantidade brutal de componentes e recursos tecnológicos listados até agora! No que tange aos tipos de equipamentos que você precisa utilizar, como deverão ser feitas as conexões físicas e lógicas, quais protocolos e serviços deverão ser projetados e empregados (configurados, ativados...), e tudo mais, enfim, isto dependerá muito de como o seu projeto técnico for construído, e este projeto precisa "casar" com o seu plano de negócios. A dissertação disto está fora do escopo deste artigo e por razões bem óbvias, pois seria um baita off-topic. Isto será tema para futuros artigos aqui na Wiki do BPF. Todavia, caso tenha curiosidade de saber um pouco mais sobre o tema, talvez estes dois vídeos possam ser úteis neste sentido, pois, neles, tento apresentar de forma bem objetiva estes conceitos:

É importante salientar que há muita redundância entre as tecnologias citadas previamente, particularmente no que concerne às aplicabilidades, cenários e casos de uso. Por exemplo, você não irá realmente rodar o protocolo de roteamento EIGRP no backbone do seu provedor, pois será óbvia e natural a escolha pelo protocolo de roteamento OSPF (as razões quanto a isto podem ser estudadas no artigo Boas Práticas para a Implantação do OSPF em Ambientes de ISP), embora ambos sejam protocolos de roteamento, e muito bons por sinal. Assim como, caso a sua rede de Acesso seja L2, será muito provável que você vá optar por tecnologias de resiliência Ethernet mais sofisticadas, preferindo o G.8032 ou EAPS, ao invés do protocolo Spanning Tree, mesmo que ambos sejam protocolos de resiliência destinados ao mesmo propósito (vide artigo Proteção e Resiliência em Redes L2 de Provedores para saber o por que). Assim como você optará pelo IPoE ou PPPoE, ou ainda rodando os dois serviços simultaneamente por um tempo em caráter de transição tecnológica, mas, no final das contas, é provável que você vá manter apenas o IPoE, embora ambos PPPoE e IPoE tenham como proposta a mesma missão (apenas a cumprem de formas distintas). Quanto aos protocolos FHRP, é bem provável que você vá optar pelo VRRP (até mesmo pela provável natureza multivendor da sua rede), e não o HSRP, que é uma tecnologia proprietária. A maioria absoluta das instalações de rede de Internet residencial emprega o protocolo/serviço RADIUS como um dos componentes de integração requeridos, mas a tendência é que, com o passar do tempo, vejamos cada vez mais instalações operando com o protocolo Diameter. Enfim, acho que você conseguiu me entender aqui.

Para tudo isto que escrevi acima, o que escolher, o que adotar, "o que comer, o que vestir", enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do ciclo de vida do projeto (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.

Qual é a relação entre a "seção de revisão de componentes tecnológicos" deste artigo e os objetivos específicos do mesmo?

Talvez você esteja se perguntando: "Tá, Leonardo, mas.... o que tem isso a ver?".

Em primeiro momento, informo que nem todos os leitores de nossa Wiki são profissionais altamente experientes quanto você, nobre leitor! Há indivíduos que nos visitam aqui que já reportaram dificuldades em absorver conhecimentos mais avançados ou complexos, e que estão em processo de aperfeiçoamento de carreira. Para este perfil de nosso público, tenho certeza que as informações apresentadas na seção anterior são tidas como muito úteis e, portanto, achei prudente lembra-los da magnitude em termos de quantidade e diversidade de componentes, conceitos, procedimentos e especificações tipicamente encontrados nas redes de service providers.

A pergunta que faço agora: como você projeta, implementa (as tecnologias, protocolos, serviços, etc.), opera (a manutenção geral), suporta (diagnóstico, troubleshooting), e provisiona clientes e seus respectivos produtos contratados?

Na grande maioria dos casos, a coisa não funciona por pura e simples "mágica", e quase tudo depende de ações e intervenções humanas. Aposto que hoje, no seu ambiente, mais de 95% de tudo o que a sua rede precisa fazer é fruto de uma configuração realizada inteiramente pelas mãos de um operador da sua rede, um profissional de operações (NOC), provisionamento ou da engenharia! O camarada foi lá e configurou elemento por elemento, "na mão", e todo o ambiente é mantido assim, desta forma.

Cada vez que você tiver que adicionar um novo elemento/equipamento na sua rede, como você faz? Cada vez que você precisa suportar novos prefixos IP, como você lida com as modificações nas suas políticas de roteamento? Cada vez que você precisa ativar um cliente corporativo para um produto do seu ISP, como você faz para provisionar este serviço? Ativar uma L2VPN ponto a ponto ou multiponto, ou uma extensão entre data centers (Data Center Interconnect), ou uma L3VPN (simple, complex, managed services, e Internet), ou um serviço SD-WAN gerenciado e em combinação com proteção de DNS e outros "mimos"? E com relação ao assinante residencial, como você faz? Tenho certeza que hoje a maior parte destes processos, pra não citar "todos", é manual ou, no melhor caso, uma ação humana realizada sobre algum tipo de ferramenta que atenua estes esforços, mas que, mesmo assim, precisa ser realizada sobre diversos equipamentos da infraestrutura.

Para efeitos comparativos aqui: nos melhores casos e envolvendo grandes empresas do setor de tecnologia, quando você contrata uma plataforma como serviço (PaaS) ou uma infraestrutura como serviço (IaaS) de uma destas consagradas empresas globais, você realmente acredita que alguém recebe um email (referente a sua solicitação) e o encaminha internamente para as áreas técnicas para que estes mobilizem qualquer atividade de ativação manualmente, tais como a instalação de equipamentos, instalação e atualização de software, configuração de dispositivos e serviços? Claro que não! Nestes perfis de organizações, tudo isso é orquestrado e automatizado a partir do momento em que você passa o seu cartão de crédito durante o procedimento de subscrição!

E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.

A relação deste artigo com os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP

Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.

Talvez você queira aprofundar-se um pouco mais sobre esta área com a leitura do artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP, caso não tenha feito isso ainda.

Há muitos anos o ITU-T introduziu o termo Telecommunications Management Network (TMN) para a descrição de uma rede dedicada com interfaces orientadas ao gerenciamento de redes de telecomunicações, e buscando definir os pontos de interconexão entre as duas redes, além de especificar as diversas funcionalidades de gerenciamento. A proposta deste framework foi ilustrar as áreas funcionais distintas e como estas deveriam interoperar. E isto foi originalmente especificado pelo ITU-T M.3400 e X.700, em especial a classificação das funcionalidades de gerenciamento, mas sem a descrição detalhada dos componentes destas funções, algo que foi tratado mais apropriadamente por outros padrões periféricos mais específicos e que nasceram mais ou menos no mesmo período.

Por sua vez, o FCAPS é um modelo de gerenciamento de redes produzido pela ISO, e não pelo ITU-T, descrito inicialmente como Working Drafts (N1719) da norma ISO 10040, e com o intuito de definir cinco padrões de protocolos distintos, sendo cada um para uma área funcional específica. Posteriormente, dadas as similaridades entre muitas funções pretendidas por estes protocolos, os cinco foram consolidados em um só (Common Management Information Protocol ou CMIP). No entanto, a coisa não parou por aí, e muitas evoluções ocorreram, até que o próprio ITU-T, nos anos 90, passasse a integrar o FCAPS como parte de seu framework TMN. Esta integração entre TMN e FCAPS está mostrada na ilustração logo abaixo.

Posteriormente, o FCAPS evoluiu para o que chamamos de FAB (Fulfillment, Assurance, Billing), conforme definido pelo framework Business Process Framework (BPF), que foi bem esclarecido no mapa eTOM apresentado no artigo "Frameworks de Indústria para a Reestruturação e Profissionalização do ISP", publicado em nossa Wiki. Ou seja, resumindo aqui, tanto a ISO quanto o ITU-T tinham propostas e modelos bastante interessantes para compreendermos as questões associadas ao gerenciamento de infraestruturas, e houve este esforço ou intenção de ambas as partes para que o melhor dos dois mundos pudessem se encontrar, promover uma certa unificação e direcionamento para os melhores resultados para a indústria. No que concerne ao FCAPS em si, para todos os efeitos, as classificações das funções de gerenciamento para cada uma das áreas de negócios e funcionais de um ISP foram inicialmente especificadas pelo FCAPS da ISO, posteriormente integradas pelo TMN da ITU-T, e aprimoradas e portadas para o eTOM BPF. Atualmente, o framework BPF é um dos frameworks do Frameworx, criado e mantido pelo TM Forum.

Visualização da integração entre TMN e FCAPS, e a ênfase no conceito de Configuration, que será o foco do artigo a partir deste ponto

A relação entre eTOM BPF ou FAB ou FCAPS, enfim, e este artigo, é buscar capacitá-los com informações fundamentais sobre o Gerenciamento de Configurações de uma rede de ISP.

Por que o FCAPS é útil, inclusive para o nosso artigo aqui? Assim como temos o hábito de usarmos frequentemente o modelo de referência OSI (RM-OSI), ou seja, aquelas 7 camadas (Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação) para ensinarmos os fundamentos de redes para profissionais da área ou indivíduos que estejam começando nela, usamos também o FCAPS para este mesmo propósito, que é o de ensinar e capacitar, só que, neste caso, sobre os conceitos e fundamentos de gerenciamento de infraestruturas!

O FCAPS, mesmo que o "original" esteja um pouco defasado (pois hoje está incorporado, mais amplo e melhor especificado no eTOM BPF), é uma excelente ferramenta de aprendizado! Por este motivo decidi escrever um pouco a respeito dele nesta seção do artigo. Quer ensinar redes para alguém? O modelo de referência OSI é ótimo para isso! Quer ensinar fundamentos de gerenciamento de redes? O FCAPS é certamente um dos recursos mais interessantes e valiosos para concebermos estes ensinamentos!

Para concluir, a sequência deste artigo estará centrada no Gerenciamento de Configurações (o "C" do modelo FCAPS). Além do artigo, você talvez tenha interesse em consultar a recomendação ITU-T G.7710/Y.1701 (08/2019) - Common Equipment Management Function Requirements para ampliar seus horizontes.

Como o gerenciamento de configurações é realizado pela maioria dos ISPs regionais de pequeno e médio portes

É de amplo conhecimento que, em parâmetros tecnológicos, os provedores de acesso à Internet de pequeno e médio portes evoluíram muito de uns anos para cá. Em termos de sofisticação de equipamentos e tecnologias, estes ISPs tem "encostado" nos grandes operadores de rede, geralmente ficando as principais diferenças entre ambos os perfis nas questões associadas ao porte dos equipamentos utilizados (capacidade, densidade, quantidade, volume), tamanhos das áreas de concessão, tamanho da base de assinantes, sendo estas diferenças até bastante expressivas, mas não no tipo ou na qualidade da tecnologias empregadas. E, nas questões administrativas, claro, a quantidade de colaboradores, o orçamento, áreas internas do negócio, e diversos outros casos que não convém elencar no momento.

Mas há uma diferença muito significativa, importantíssima, e que tem a ver com o que este artigo propõe-se a discutir: o gerenciamento da infraestrutura como um todo, incluindo frameworks, processos, procedimentos, metodologias, integrações, o tanto de programabilidade, automação e orquestração, os respectivos padrões de ferramentas empregadas... e isto são algumas das principais comparações operacionais e procedurais que faço quando analisando um operador de redes de grande porte e um ISP regional de pequeno ou médio porte, quanto a estes quesitos.

No que diz respeito ao gerenciamento de configurações, mais especificamente quando um ISP regional de menor porte precisa ativar ou provisionar um novo serviço, geralmente são necessários os seguintes procedimentos (estou generalizando aqui):

Se a manobra tiver que incluir a instalação física de um novo equipamento em um site/Pop do ISP, conduzir e documentar um Projeto Provisório de Instalação (PPI) ou Projeto Definitivo de Instalação (PDI), juntamente com os demais procedimentos homologados pela Engenharia da empresa, tais como Plano de Instalação e Ativação, etc.
1. Sejamos realistas: a instalação física de um equipamento não pode ser automatizada! (exceto, talvez, por robôs, o que não será o nosso caso tão cedo)
Configuração de equipamento para a sua efetiva integração com a rede, o que, por sua vez, normalmente ou quase sempre, exige a condução de outros procedimentos aprovados pela Engenharia da empresa, em particular a atualização do software para a versão homologada e a condução de um extenso roteiro/script contendo os parâmetros de configuração, apoiados por artefatos tais como um Plano de Instalação e Configuração Lógica.
1. Aqui temos a primeira oportunidade de automação e orquestração, via métodos de provisionamento tais como o de zero toque ou "Zero Touch Provisioning", os quais propõem-se a simplesmente exigir do profissional lá no site/Pop a energização e cabeamento/conectorização das portas do equipamento, que a rede automaticamente se encarregará de todo o resto e fornecerá a configuração definitiva do equipamento.
Em seguida, o provisionamento do serviço do cliente! É aqui que você terá que "visitar" a CLI (linha de comando) de vários equipamentos para realização das configurações necessárias para a viabilidade fim-a-fim do serviço contratado pelo assinante, e geralmente apoiado por um formato pré-estabelecido para aquele tipo de produto/configuração. Ou seja, definir as VLANs, entroncamentos de VLAN, os mecanismos de controle de admissão à rede, recursos de segurança, endereços IP, roteamento, QoS, policies, etc., e fazendo isto para as tecnologias requeridas, caso a caso, sobre todo e qualquer dispositivo exigido para a viabilidade quanto à "ativação" (fim a fim) daquele produto que aquele assinante contratou.
1. Talvez uma das áreas operacionais mais frágeis da organização seja exatamente esta baixa aderência quanto às boas práticas regidas pelo "C" do FCAPS, ou seja, da disciplina de gerenciamento de configurações! Muito frequentemente, para não dizer "quase sempre", é um processo estritamente manual e associado a custos mais elevados, maiores esforços e complexidades operacionais, maiores riscos de incidentes e downtime (decorrentes de falha humana durante o processo de configuração de elementos de rede), dentre muitas situações eventual e obviamente indesejadas.
2. E é aqui que enxergo uma excelente oportunidade para os ISPs regionais poderem se modernizar!
O serviço que foi ativado (produto + assinante) é testado e validado, e posicionado para produção em caráter definitivo. A partir deste ponto, a Operação da rede (ex: NOC) deverá ficar responsável por assegurar que as métricas do SLA contratado sejam respeitados, tais como capacidade, consumo de banda dentro do perfil, latência, jitter, perda de pacotes, disponibilidade/uptime, etc.
1. Outra seara repleta de procedimentos manuais e ferramentas dissimilares que não "conversam" entre si, não compartilham dados, e fica bem mais difícil encontrar uma utilidade real para os sistemas de gerenciamento de elementos (EMS) e de rede (NMS), como partes integrantes ou isoladamente dos sistemas de suporte a operação (OSS) da organização.
2. Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!

O roteiro tradicional de implantação e provisionamento de serviços de um ISP

Compreendendo a programabilidade de infraestruturas

Tentarei ser muito objetivo ao explicar logo a seguir algumas verdades, assim como aproveitar a oportunidade para esclarecer algumas "inverdades", sobre este universo envolvendo programabilidade, orquestração, automação, provisionamento, SDN, NFV, etc. Vamos lá?

O provisionamento é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes.
- Este provisionamento de um serviço (ex: um L2VPN "LAN-to-LAN" ou "DCI", uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais) ou de forma bem mais "programável"; orquestrada e automatizada.
A orquestração é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, para um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.
- A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).
A automação é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam "zero" ou o mínimo possível de ações humanas.
- Desejavelmente, a automação deve estar contida na orquestração, pois, por exemplo, do contrário, não fará muito sentido "juntar as peças de sistemas dissimilares" (alçada da orquestração) se você tiver que executar os blocos do contrato manualmente depois, na CLI ou GUI/WebUI de vários equipamentos.
- A orquestração e automação devem andar lado a lado.
  - Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples frontend, os parâmetros são preenchidos/fornecidos para que, no backend, a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).
  - Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.
A programabilidade tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações de serviços.
- Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para um provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, "zero" ou menor esforço de implementação, e menores riscos para a rede e para o negócio.
Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.
Programabilidade e Software-Defined Networking (SDN) são coisas completamente distintas.
Orquestração e Software-Defined Networking (SDN) são coisas distintas. Nem toda orquestração ocorre em um ambiente SDN, mas quase sempre o oposto é verdadeiro.
Software-Defined Networking (SDN) e Network Functions Virtualization (NFV) são coisas completamente distintas.
As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de recursos e ferramentas específicas, e isto valendo para cada equipamento.
Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.

A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.

Componentes fomentadores da programabilidade de infraestruturas

Ferramentas e soluções orientadas aos princípios de programabilidade

Caso você tenha ficado impressionado com a "salada de tecnologias" ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais. Aliás, a intenção a seguir é apenas listas estas ferramentas e soluções, e não esmiuçar como são implementadas ou inseridas nas infraestruturas.

A ilustração a seguir mostra algumas destas soluções e ferramentas.

Descrição das principais ferramentas e soluções para programabilidade
Ferramenta	Disponibilidade	Descrição
VMware vSphere		O vSphere é o software de virtualização de servidores líder do setor e o núcleo de um SDDC moderno. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens. A solução é amplamente utilizado no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração.
VMware vRealize		VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a comstrução de núveis heterogêneas híbridas.
Cisco APIC-EM		O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN. A sua proposta é a de fornecer uma plataforma elástica paraa a automação, simplificação e abstração da rede, acomodando apliações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.
Cisco DNA Center		O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco. Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.
Cisco Crosswork Network Automation		O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursoos para o gerenciamento proativo fim a fim das redes. Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.
Cisco Network Services Orchestrator		O Cisco NSO é uma solução muito robusta de abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de oquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound. O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.
Cisco Open SDN Controller		O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogênas para a entrega de serviços.
Microsoft System Center		O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.
BMC Software		A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global. Tem conquistado o reconhecimento como Líder no Quadrante Mágico da Gartner em ITSM por cinco anos consecutivos. A BMC possui sofisticadas soluções para o grenciamento multi-cloud, automação e DevOps, segurança e conformidade, otimização de TI, inteligência artificial e machine learning, e gerenciamento de serviços. Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.
Juniper Contrail		A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010. O Contrail pode ser utilizado por service providers / ISPs para agilizar o provisionamento de serviços, e também atende a muitos casos e necessidades de empresas do segmento corporativo. A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.
Huawei Agile SDN Controller		O controlador Agile para campus é a última geração de controladores da Huawei para redes de campus e de ramificação. Utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de política e SD-WAN. O controlador Agile para campus reduz as despesas operacionais (OPEX) e os custos de operações e manutenção (O&M) das empresas, aceleram a mudança dos serviços para a nuvem e a transformação digital, além de tornar o gerenciamento de rede mais ágil e os procedimentos de O&M de rede mais inteligentes.
Ansible		O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. É executado em muitos sistemas semelhantes ao Unix e pode configurar sistemas semelhantes ao Unix e também o Microsoft Windows. O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações. É uma ferramenta bastante popular!
Chef		Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever "receitas" na configuração do sistema. O Chef transforma a infraestrutura em código, onde você pode automatizar a criação criar, implantação e gerenciamento da sua infraestrutura, e de forma bastante versátil, testável e repetível quanto o código do aplicativo. O servidor Chef armazena suas receitas e outros dados de configuração. O cliente Chef fica instalado em cada servidor, máquina virtual, conteiner ou dispositivo de rede que você gerencia, chamados de "nodes". O cliente consulta periodicamente a política e o estado mais recentes da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.
Puppet		O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.
Python		Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender. O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de código. É certamente um dos "queridinhos" dos times de DevOps para as necessidades de automação de infraestruturas de redes.
SaltStack		O SaltStack ou "Salt" é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de softwareem servidores físicos, virtuais e cloud. O SaltStack automatiza tarefas repetidas de implementação administrativa e de código do sistema, eliminando processos manuais de maneira a reduzir os erros que ocorrem quando as organizações de TI configuram os sistemas. O Salt é bastante usado nas organizações do DevOps porque extrai o código do desenvolvedor e as informações de configuração de um repositório de código central, como o GitHub ou o Subversion, e envia esse conteúdo remotamente para os servidores. Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.
Ruby		Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script. Seu criador (Yukihiro “Matz” Matsumoto) juntou o "melhor dos mundos" de suas liguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.
OpenStack		O OpenStack é um sistema operacional em nuvem que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo "SDN" sem que o nome OpenStack seja lembrado.
OpenDaylight		O OpenDaylight (ODL) é uma plataforma aberta modular para a personalização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes.
OpenContrail (Tungsten Fabric)		O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, conteiners ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.
OpenFlow		O OpenFlow não é uma solução em si, mas sim um protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento e outros. O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN). Dentre outras coisas, o OpenFlow permite a administração remota de tabelas de encaminhamento de pacotes de roteadores, adicionando, modificando e removendo regras e ações de correspondência ou de incidência de pacotes. Dessa forma, as decisões de roteamento podem ser tomadas periodicamente ou ad hoc pelo controlador, e traduzidas em regras e ações com uma lifecycle configurável, que são, então, aplicadas automaticamente nas tabelas dos equipamentos. Apesar de bastante promissor, o OpenFlow nunca "deslanchou" como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!
Kubernetes		Kubernetes é um formidável sistema de orquestração de conteiners open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em conteiners. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um "must have" em ambientes onde conteiners são fundamentais para os projetos de infraestrutura.
Docker, Jails, LXC, LXD, etc.		FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a eslasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.
Recursos proprietários de equipamentos		Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.) possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação. Citarei alguns exemplos aqui: Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação. Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações. Antes que você me questione ou reclame por eu ter citado apenas tecnologias "Cisco" aqui, relaxe: consulte a documentação de SEU fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento!

Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade

O que é e o que não é o Software-Defined Networking (SDN)

Conforme antecipado na seção anterior, não há uma dependência direta entre programabilidade e SDN, neste exato sentido, pois, por exemplo, é possível instrumentar a rede com bons padrões de automação usando ferramentas e recursos embarcados nos dispositivos da rede e sem que isto vá exigir uma adoção de SDN, e isto será discutido posteriormente neste artigo. Por outro lado, em parâmetros de eficiência de automação, o SDN possui uma relação direta com a programabilidade. Curioso, não? Para automatizar e até mesmo contar com padrões razoáveis de programabilidade na sua rede, o SDN não é necessariamente exigido. No entanto, ao considerar o SDN, este promove um padrão de programabilidade incomparável aos modelos de projetos de redes tradicionais, e isto é um fato!

A propósito, você compreende o mínimo de SDN? Para os mais leigos, isto será bastante apropriado:

O SDN não pode ser representado como se fosse um simples "botão", onde clica-se e temos um ambiente pronto, rodando! Não é bem por aí... e está longe de ser algo deste tipo.
O SDN tem como uma de suas principais propostas a atenuação drástica dos esforços e complexidades operacionais associados com o provisionamento e manutenção de infraestruturas de redes.
O SDN é um esforço da indústria para a caracterização de redes mais automatizadas, ágeis, elásticas, e empregando menos esforços e custos operacionais, assim como a diminuição de riscos para os negócios das empresas.
O SDN não obrigará que você torne-se um programador do dia para a noite, mas saber o essencial de lógica de programação e algumas linguagens de programação será muito útil para você poder destravar potenciais incríveis de seu ambiente!
O SDN não substituirá a necessidade da sua empresa em continuar contando com engenheiros e operadores de NOC, muito pelo contrário! Todavia, a tendência é que consolidem-se no setor os profissionais mais especializados e diferenciados. Os negócios precisam evoluir (sempre para melhor), e por que você não pode fazer o mesmo com a sua carreira?
O SDN busca promover uma abordagem de arquitetura que realiza uma separação bem legítima entre os planos de controle e de dados (control plane e data plane), levando o estado de informações, juntamente com a inteligência para tomadas de decisões, para um conceito logicamente centralizado. Ou seja, a centralização do estado de informações em uma zona estratégica da infraestrutura, enquanto os dispositivos de redes ficam dedicados e especializados em executar o processamento de pacotes e afins.
O SDN promove excepcional abstração entre a infraestrutura de rede (com seus protocolos e serviços mais básicos ou essenciais (ex: IGP da infraestrutura, o MPLS, o QoS do backbone, etc.)) e as aplicações e demais serviços da rede. Ou seja, uma separação bastante interessante entre rede underlay e rede overlay.
O SDN pode ser representado como um conceito de interfaces programáticas que permitem que sistemas externos influenciem no provisionamento de serviços, controle e operações da rede.
O SDN fornece novas formas de interação com os equipamentos e serviços da rede via controladoras e APIs (Application Programming Interface).
O SDN permite formidáveis capacidades de provisionamento, orquestração, automação e normalização de equipamentos e serviços.
O SDN pode destravar diversas barreiras do seu negócio ao permitir que agentes externos - devidamente integrados à rede - consigam influenciar nas características de seu projeto e na sua operação, promovendo melhor alinhamento entre as tecnologias empregadas e os resultados almejados pelos modelos de negócios.
O SDN poderá ser:
- Uma rede onde os dispositivos retém os seus próprios planos de controle, mas que uma controladora SDN contém/mantém o estado de informação de todos os protocolos e serviços. Isto seria o exemplo de uma abordagem híbrida.
- Uma rede onde todo o plano de controle é centralizado na(s) controladora(s) SDN, enquanto os equipamentos ficam dedicados para as funções de processamento de pacotes.

A ilustração a seguir mostra um excelente comparativo entre redes tradicionais e SDN, "for dummies" (para os leigos).

Comparativos entre redes tradicionais e SDN, para os leigos