DCSG-P4: Disaggregated Cell Site Gateway (DCSG) em pipeline programável de pacotes interoperável

DCSG-P4: Disaggregated Cell Site Gateway (DCSG) em pipeline program´avel de pacotes interoper´avel Kleber M. S. Rezende1, Alan T. da Silva1, Rodrigo Pierini1, Christian E. Rothenberg1 1Faculdade de Engenharia El´etrica e de Computa¸c˜ao (FEEC) Universidade Estadual de Campinas (UNICAMP), Campinas/SP, Brasil {k232154,a265560}@dac.unicamp.br, {rpierini,chesteve}@unicamp.br Resumo. ` A medida que a arquitetura de redes 5G amadurece, novos servi¸cos tornam-se dispon´ıveis para as operadoras de redes m´oveis e provedores de servi¸co. A implementa¸c˜ao de tais servi¸cos, aliada `a busca pela independˆencia de fornecedor e potencializada pelas tecnologias SDN, ´e um dos fatores que impulsionam a inova¸c˜ao. Dentro deste contexto, o cell site gateway (CSG) se destaca como um elemento de grande densidade e, por isso, solu¸c˜oes que reduzam os custos destes equipamentos sem comprometer qualidade s˜ao bem vindas. O Telecom Infra Project (TIP) estabeleceu algumas especifica¸c˜oes que orientam o desenvolvimento destes elementos de rede, considerando a separa¸c˜ao dos planos de controle e de dados, denominados de Disaggregated CSG (DCSG). Este trabalho apresenta uma proposta para a implementa¸c˜ao de um DCSG virtualizado, com caracter´ısticas comumente utilizadas por Provedores de Servi¸co, baseadas nas especifica¸c˜oes do TIP. As principais contribui¸c˜oes deste trabalho incluem a implementa¸c˜ao do pipeline projetado, a adapta¸c˜ao para hardware Tofino de baixo custo e a valida¸c˜ao experimental em testbed no qual foram conduzidos testes funcionais e de interoperabilidade. Os resultados obtidos demostraram que o encaminhamento de pacotes realizado pela nossa solu¸c˜ao ´e adequado para a interoperar com equipamentos IP/MPLS tradicionais de fun¸c˜ao fixa. Abstract. As 5G network architecture matures, new services become available to mobile network operators and service providers. The adoption of such services, coupled with the pursuit for supplier independence, enhanced by SDN technologies, drives increased pace for innovation. Within this context, the cell site gateway (CSG) represents high density elements and, therefore, solutions that reduce the equipment costs without loss of quality are being pursued. The Telecom Infra Project (TIP) brought some specifications that guide the creation of these network elements, considering the disaggregation of control and data planes, known as Disaggregated CSG (DCSG). In this work, we propose the implementation of a virtualized DCSG, incorporating characteristics normally used by Service Providers, based on the TIP specifications. Our main contributions are: implementation of the designed pipeline; prototype implementation in low-cost Tofino hardware; testbed experiments for functional and interoperability tests. The obtained results indicate that the packet forwarding, performed by our solution, is suitable for interoperability with legacy fixed-function equipment. 1. Introdu¸c˜ao Operadoras de redes m´oveis e provedores de servi¸cos de Internet, tradicionalmente, dependem de fornecedores espec´ıficos para projetar e construir sua estrutura de comunica¸c˜ao. Tal dependˆencia torna as atualiza¸c˜oes mais lentas, aumenta os custos e dificulta a inova¸c˜ao. Com o esperado aumento da densidade das redes m´oveis celulares de quinta gera¸c˜ao (5G) em rela¸c˜ao `as redes de quarta gera¸c˜ao (4G), mais equipamentos de um mesmo fornecedor ser˜ao necess´arios para atender `as demandas de densidade destas redes. Isto pode contribuir para um risco extra de aprisionamento a um determinado fornecedor [Chaudhary 2020]. A ado¸c˜ao de solu¸c˜oes abertas e desagregadas, como Software-Defined Networking (SDN) [Kreutz et al. 2014] [Foundation 2024] e Network Function Virtualization (NFV) [Rosa et al. 2014], permitiu que os Provedores de Servi¸cos em Nuvem pudessem realizar inova¸c˜oes mais rapidamente. Neste contexto, o Programming Protocol-Independent Packet Processors (P4) [Org 2024] apresenta-se como um dos principais marcos no mundo SDN. P4 refere-se a uma linguagem espec´ıfica de dom´ınio para dispositivos de rede que permite definir como o plano de dados de roteadores e switches processam pacotes. Estes dispositivos, quando habilitados para P4, s˜ao independentes de protocolo. Al´em disso, o P4 fornece um modelo abstrato adequado para programar o plano de dados da rede que delineia os cabe¸calhos e especifica os comportamentos do parser/deparser e processamento dos pacotes. Na arquitetura de redes 5G encontram-se distribu´ıdos diversos dispositivos de encaminhamento de pacotes, dentre eles o Cell Site Gateway (CSG), tamb´em conhecido como Cell Site Router (CSR). Este elemento de rede ´e um componente de Camada 2 (L2) e Camada 3 (L3) da rede backhaul de telecomunica¸c˜oes que realiza o transporte de dados da rede de acesso celular para a rede core do lado do provedor de servi¸co e vice-versa, conforme ilustrado na Figura 1. Normalmente, as esta¸c˜oes base m´oveis s˜ao conectadas a um CSG usando interfaces Gigabit Ethernet RJ45 ou Small Form-factor Pluggable (SFP) tradicionais. No entanto, com a recente implanta¸c˜ao de redes 5G, as esta¸c˜oes base utilizar˜ao interFigura 1. DCSG localizado na borda da Rede Backhaul. Adaptado de [Marcom 2021] faces SFP+ de 10 Gigabit Ethernet para acomodar os crescentes requisitos de alta capacidade. Isso significa que a maioria dos CSGs atualmente implantados tornaram-se inadequados para transportar o tr´afego da esta¸c˜ao base 5G. A observa¸c˜ao destes fatos instigou o surgimento de iniciativas como o Telecom Infra Project (TIP) e seus diversos projetos como o Disaggregated Cell Site Gateway (DCSG) sob gest˜ao do grupo Open Optical and Packet Transport (OOPT) [Atrio et al. 2019]. Com a arquitetura de plataforma de hardware aberta, as operadoras agora tˆem a op¸c˜ao de escolher um dos v´arios sistemas operacionais de rede oferecidos pelo fornecedor de software de sua preferˆencia. O protocolo Multi-Protocol Label Switching (MPLS) [Rosen et al. 2001] fornece tratamento eficiente para transmiss˜ao de pacotes IP na rede ao facilitar o roteamento desses pacotes em rotas pr´e-determinadas, chamadas de Label-Switched Path (LSP). As redes tradicionais utilizam o MPLS para troca de r´otulos sempre que um fluxo de tr´afego precisa ser habilitado na topologia da rede, e cada n´o mant´em um estado de perfluxo exclusivo. Embora seja um protocolo com mais de duas d´ecadas de uso, de acordo com o levantamento feito por [Depasquale et al. 2023], o servi¸co MPLS ainda ´e dominante quando ´e preciso executar a escolha da tecnologia fronthaul emidhaul para sites de macroc´elulas. O estudo ainda conclui que o MPLS foi identificado como uma etapa intermedi´aria e de interesse atual para os Provedores de Servi¸cos de Comunica¸c˜oes. Ainda segundo o TIP [Atrio et al. 2019], o principal caso de uso previsto para o DCSG ´e atuar em backhaul 2G/3G/4G/5G para a rede IP/MPLS de transporte m´ovel. No entanto, a natureza de rede aberta do DCSG permite que diversas aplica¸c˜oes de backhaul diferentes sejam implementadas na mesma plataforma whitebox. Aplica¸c˜oes adicionais, al´em da agrega¸c˜ao de cell site para backhaul m´ovel, incluem: •Unidade interna para backhaul de micro-ondas •Roteador de borda do provedor •Agrega¸c˜ao de fronthaul com suporte TSN1 •DCI2efronthaul regional com suporte OpenZR+ •Redes 5G privadas Este trabalho visa a implementa¸c˜ao de um DCSG para atuar como roteador de borda de um provedor de servi¸cos, usando a linguagem P4. A inten¸c˜ao final ´e apresentar uma solu¸c˜ao de software que utiliza tecnologias open source e que possa ser executada em uma plataforma de hardware de baixo custo, como o Tofino ASIC, em conjunto com equipamentos legados. A organiza¸c˜ao deste trabalho segue a seguinte ordem. Se¸c˜ao 2 descreve os trabalhos relacionados. A Se¸c˜ao 3 aborda a defini¸c˜ao do problema e a solu¸c˜ao proposta. Os resultados obtidos s˜ao apresentados na Se¸c˜ao 4, enquanto a Se¸c˜ao 5 exp˜oe as conclus˜oes e discuss˜oes sobre trabalhos futuros. 1Time-Sensitive Networking - https://1.ieee802.org/tsn/ 2Data Center Interconnect - https://www.ciena.com/insights/what-is/What-is-DCI.html 2. Trabalhos Relacionados Ao passo que o paradigma SDN se estabelece como sucessor das redes tradicionais, existem desafios pertinentes de interoperabilidade entre protocolos de comunica¸c˜ao destas redes IP/MPLS legadas com dispositivos program´aveis do plano de dados, tais como os switches P4. Alguns trabalhos com essa perspectiva foram analisados. Uma arquitetura baseada em SDN para gerenciamento de uma rede Traffic Engineering Diffserv Aware (DS-TE) MPLS ´e apresentada em [Bahnasse et al. 2018]. Um ambiente h´ıbrido simulado foi desenvolvido para testar a arquitetura proposta: o plano de dados emulado no software Graphical Network Simulator 3 (GNS3) com roteadores CiscoXR e 7200 IOS e o OpenDayLight como o plano de controle. O tr´afego de dados foi composto por VoIP, video, HTTP e ICMP. Apesar da abordagem inserida no contexto SDN, ´e ausente no trabalho a quest˜ao da programabilidade de redes com uma linguagem espec´ıfica como, por exemplo, P4. Em [Liu et al. 2022] ´e apresentado o modelo Domain Programming Router (DPRouter), baseado na arquitetura Server-Switch [Lu et al. 2011] que utiliza um processador de dados dpDPU baseado em Reconfigurable Match Tables (RMT) com suporte ao gerenciamento unificado da tabela de fluxo do plano de dados, implementado em FPGA program´avel. Embora o artigo, mencione o uso de programabilidade P4, apenas o roteamento e encaminhamento baseado em nome Named-Data Network (NDN) e algumas funcionalidades relacionadas com seguran¸ca s˜ao apresentados como a¸c˜oes realizadas pelo plano de dado. Nada ´e informado acerca do suporte de features relacionadas com protocolos conhecidos. No entanto, os autores mencionam que o conjunto de instru¸c˜oes personalizadas de dom´ınio RMT pode ser estendido num trabalho futuro. O BNG constru´ıdo por [Kundel et al. 2019] refere-se ao projeto e `a implementa¸c˜ao de um plano de dados BNG de c´odigo aberto que atende `as demandas de Gateways de Rede de Banda Larga em ambientes de n´ıvel de operadora. A implementa¸c˜ao ´e baseada na arquitetura Central Office Re-architected as a Datacenter (CORD), criada pela Open Networking Foundation (ONF), que suporta a execu¸c˜ao da funcionalidade de escrit´orio central, usando VNFs em hardware commodity, cujo objetivo ´e superar a dependˆencia de fornecedores e hardware propriet´ario em redes de operadoras. O pipeline constru´ıdo aborda fluxo upstream edownstream de forma diferente e utiliza de um controlador para auxiliar na tarefa de autentica¸c˜ao e autoriza¸c˜ao do assinante e configura¸c˜ao da sess˜ao PPPoE. Os testes e avalia¸c˜ao do pipeline foram realizados nos targets BMv2, P4-NetFPGAs e Netronome P4SmartNICs. Al´em disso, algumas estimativas s˜ao dadas para a implementa¸c˜ao no Tofino. A arquitetura ainda disp˜oe de mecanismo de seguran¸ca para evitar a falsifica¸c˜ao de endere¸co de origem IP. O paradigma da desacopla¸c˜ao das fun¸c˜oes de identifica¸c˜ao e de localiza¸c˜ao de um host na Internet foi abordado por [Steinert et al. 2023], que criaram o pipeline P4-LISP. Trata-se de um roteador LISP (Locator/Identifier Separation Protocol) de alto desempenho, implementado em P4, que suporta todos os recursos relevantes, como Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), dentre outros. O c´odigo foi compilado no Tofino ASIC e o seu desempenho foi exaustivamente testado. Embora tenha suporte para o IPv4, o foco principal do trabalho est´a na defini¸c˜ao dos t´uneis que permitem a comunica¸c˜ao entre hosts de diferentes dom´ınios LISP. [Abhishek Singh et al. 2021] criaram um cen´ario onde foi configurado o Segment Routing – Traffic Engineering (SR-TE) usando roteadores CISCO IOSXRv no Cisco Modeling Labs. O SR Path Computation Element (SR-PCE) constru´ıdo no IOS-XRv tamb´em se enquadra na topologia. Sempre que a situa¸c˜ao da rede muda, as pol´ıticas de caminho dinˆamico, como m´etrica IGP, m´etrica TE, m´etrica HopCount e m´etrica de latˆencia, s˜ao introduzidas na topologia da rede e o caminho ´e recalculado e implementado automaticamente. Sob essas condi¸c˜oes de pol´ıtica, um desempenho de escalabilidade melhor e eficaz ´e alcan¸cado. Neste artigo, o SR-TE ´e implementado com roteamento por segmentos sobre o plano de dados MPLS de pol´ıticas dinˆamicas. Em [Ollora Zaballa et al. 2021], ´e abordada a implementa¸c˜ao e integra¸c˜ao do protocolo In-Band Network Telemetry em switches program´aveis P4 sobre uma rede SDN h´ıbrida. Neste cen´ario, s˜ao discutidas as restri¸c˜oes que precisam ser administradas de forma que os switches program´aveis P4 possam interagir com os dispositivos MPLS legados. Tabela 1. Compara¸c˜ao de trabalhos relacionados. Referˆ encia do trabalho Implementac¸˜ ao Programabilidade do Data Plane Target Features configur´ aveis [Bahnasse et al. 2018] Arquitetura baseada em SDN para o gerenciamento de uma rede DS-TE N˜ao Cisco IOS-XR e 7200 IOS executados no GNS3 N˜ao se aplica [Liu et al. 2022] Modelo gen´erico de router Sim (P4) FPGA, ServerSwitch N˜ao informado [Kundel et al. 2019] BNG Sim (P4) BMv2, FPGA, P4-SmartNIC, Tofino ASIC PPPoE, VLAN, MPLS, IPv4 [Steinert et al. 2023] Router LISP Sim (P4) Tofino ASIC NAT, IPv4 [Abhishek Singh et al. 2021] Pol´ıticas de caminho dinˆamico N˜ao CISCO IOSXRv no Cisco Modeling Labs N˜ao se aplica [Ollora Zaballa et al. 2021] Modelo gen´erico de router Sim (P4) P4-SmartNIC, Tofino ASIC MPLS Nossa Solu¸c˜ao para DCSG DCSG Sim (P4) BMv2, Tofino ASIC VLAN, QinQ, MPLS, IPv4 3. DCSG-P4: Projeto do DCSG na linguagem P4 3.1. Defini¸c˜ao do Problema Os CSGs, atualmente utilizados nas redes 4G, possuem arquiteturas monol´ıticas que dificultam a diversifica¸c˜ao de fornecedores por parte das operadoras e provedores. Esta ´e uma caracter´ıstica que torna desafiadora a implementa¸c˜ao de redes de comunica¸c˜ao no padr˜ao 5G e 5G-and-Beyond, a curto e m´edio prazo, e no padr˜ao 6G, a longo prazo, devido `a necessidade latente de interoperabilidade entre os equipamentos tradicionais e os novos dispositivos de rede program´avel. A desagrega¸c˜ao dos planos de controle e de dados, principal caracter´ıstica trazida pelo paradigma SDN, ´e usada como alternativa para minimizar este problema e, com ela, iniciativas de constru¸c˜ao de CSG desagregados come¸cam a ficar em evidˆencia, como o DCSG proposto pelo TIP. 3.2. Desenvolvimento em P4 da l´ogica do pipeline DCSG De forma que os crit´erios e caracter´ısticas discutidos nas se¸c˜oes anteriores fossem devidamente correspondidos na implementa¸c˜ao do projeto, foi desenvolvido um programa na linguagem P4 denominado dcsg.p4. Uma vis˜ao geral do pipeline do programa ´e apresentada na figura 2 e permite a an´alise e encaminhamento de pacotes Ethernet com ou sem marca¸c˜ao de VLAN/QinQ3, al´em de pacotes MPLS e IPv4. Figura 2. Pipeline do DCSG implementado 3.2.1. Detalhamento do Parser O bloco Parser ´e respons´avel pela an´alise dos cabe¸calhos encontrados nos pacotes que chegam ao switch program´avel. Tal an´alise consiste na verifica¸c˜ao do conte´udo de campos presentes nestes cabe¸calhos, para tomada de decis˜oes dentro do pr´oprio bloco e nos blocos subsequentes. Uma vis˜ao mais detalhada do parser pode ser vista na figura 3. A primeira coisa que deve ser verificada ´e se o pacote veio do controlador (via CPU PORT). Se for este caso, deve-se analisar o conte´udo constante no cabe¸calho especialmente criado para este tipo de comunica¸c˜ao. Como ser´a mostrado mais adiante, a principal informa¸c˜ao obtida nesta situa¸c˜ao ´e a porta de sa´ıda indicada pelo controlador. Na sequˆencia, o Parser verifica a existˆencia de marca¸c˜oes de VLAN no pacote. Se houver, os valores de vlan id encontrados s˜ao armazenados em campos espec´ıficos nos metadados locais. Caso contr´ario, um vlan id padr˜ao ser´a definido. Se o pacote chegar com marca(s) de VLAN, o valor do vlan id mais externo, contido na pilha de cabe¸calhos, tamb´em ser´a armazenado nos metadados locais. Finalmente, se o campo Ether type sinalizar a presen¸ca de outra marca de VLAN no mesmo pacote (QinQ), o Bloco Parse Inner VLAN Tag far´a o armazenamento do vlan id mais interno, informado no cabe¸calho, no campo inner vlan id dos metadados locais. 3https://www.ieee802.org/1/pages/802.1ad.html Posteriormente, verifica-se qual estrutura est´a encapsulada no frame Ethernet. Para este projeto, espera-se pacotes MPLS, IPv4, ARP/RARP. Os protocolos Link Layer Discover Protocol (LLDP) e Broadcast Domain Discovery Protocol (BDDP) foram considerados apenas para que controladores, que venham a interagir com nosso pipeline, possam ter meios de descobrir a topologia da rede que est´a sendo controlada, por´em, a discuss˜ao e an´alise destes mecanismos est˜ao fora do escopo deste projeto. Pacotes que n˜ao contenham os cabe¸calhos previstos neste parser, s˜ao marcados para serem descartados na etapa de processamento que ser´a detalhada mais adiante. O bloco Deparser ´e respons´avel pela inser¸c˜ao de cabe¸calhos nos pacotes que ser˜ao enviados por uma ou mais interfaces do equipamento. Figura 3. Detalhamento do Parser do DCSG implementado 3.2.2. Detalhamento do Pipeline de Processamento de Pacotes O Pipeline de Processamento de Pacotes ´e composto por blocos de controle combinados com tabelas match-action, por meio das quais definem-se as a¸c˜oes que podem ser executadas e as chaves que s˜ao consideradas para selecionar a a¸c˜ao desejada. A figura 4 mostra que, logo ap´os a etapa de Parser, ´e feita uma verifica¸c˜ao para determinar se o pacote foi marcado para descarte. Caso n˜ao tenha havido tal marca¸c˜ao, alguns campos dos metadados intr´ınsecos do target s˜ao copiados para os metadados locais. O objetivo desta a¸c˜ao ´e tornar mais f´acil o processo de portabilidade do c´odigo entre targets diferentes. Na eventualidade do pacote ser recebido a partir do controlador, utiliza-se a porta de sa´ıda determinada pelo plano de controle. Em seguida, realiza-se o mapeamento de campos de QoS conforme definido na tabela qos mapping, atualiza-se os metadados intr´ınsecos com as informa¸c˜oes relevantes e encaminha-se o pacote para pipeline de sa´ıda (egress pipeline). Caso contr´ario, o pacote ser´a submetido a etapa de filtragem, podendo ser descartado ou n˜ao. Se aceito, o processo de aprendizagem Figura 4. Vis˜ao macro do Pipeline de Entrada do DCSG-P4 layer 2 ser´a executado, enviando pacotes ARP/RARP para o controlador. Se o pacote n˜ao for deste tipo, inicia-se o processo de determina¸c˜ao do tipo encaminhamento que ser´a executado. As etapas de filtragem, de encaminhamento layer 2 e encaminhamento layer 3 ser˜ao detalhadas a seguir. Etapa de Filtragem Inicialmente, as informa¸c˜oes de QoS contidas no pacote recebido (MPLS - Experimental Bits - Exp; IPv4 - Differentiated Services Field Codepoints - DCSP; e/ou Ethernet - Class of Service - CoS) s˜ao extra´ıdas conforme ilustrado na figura 5(a). Estas informa¸c˜oes s˜ao copiadas para campos espec´ıficos dos metadados locais, de acordo com a presen¸ca do respectivo cabe¸calho no pacote. Listas de controle de acesso podem ser especificadas por meio da tabela ACL, considerando os campos mostrados na figura. Por meio da tabela ingress port vlan pode ser realizado o processo de filtragem baseado em VLANs. Basicamente, ela leva em considera¸c˜ao a porta de entrada (ig port) e a presen¸ca de uma marca de VLAN (hdr.vlan tag.isValid) no pacote. Se chegar um pacote marcado (tagged), o vlan id encontrado ser´a usado para decidir sobre seu descarte (action deny) ou n˜ao (action permit). No caso de chegar um pacote untagged numa porta de acesso, a chave hdr.vlan tag.vlan id ser´a desconsiderada e a action permit with internal vlan pode ser chamada para vincular um vlan id ao pacote. A a¸c˜ao padr˜ao (quando n˜ao h´a correspondˆencia de chaves) ´e negar (descartar) um pacote. Processo similar ´e usado no pipeline de sa´ıda. Encaminhamento L2 ´ E poss´ıvel que o pipeline implementado realize 3 tipos de encaminhamento, conforme descrito na figura 4: Bridging L2 (multicast/broadcast ou unicast), IPv4 e MPLS. O tipo de encaminhamento ´e definido por meio de uma action, chamada set forwarding type, dispon´ıvel na tabela fwd classifier, que utiliza um parˆametro com um dos seguintes valores: Bridging (0x0); MPLS (0x1) ou IPv4 (0x2). O tipo de encaminhamento padr˜ao ´e Bridging. Assim sendo, recomenda-se o uso de um controlador L2 Learning a fim de evitar a inunda¸c˜ao (flooding) da rede. O (a) Etapa de Filtragem do Pipeline de Entrada (b) Mecanismo de Encaminhamento L2 (c) Mecanismo de Encaminhamento L3 Figura 5. Processos de filtragem e encaminhamentos L2/L3 usados pelo DCSG-P4 mecanismo de encaminhamento L2, mostrado na figura 5(b), consiste na an´alise de duas tabelas. Primeiramente, analisa-se a tabela mac forward em busca da porta de sa´ıda vinculada `a chave (key)hdr.ethernet.dstAddr e, caso nenhuma entrada (entry) seja compat´ıvel (miss) com o endere¸co MAC de destino encontrado na cabe¸calho Ethernet do pacote, realiza-se um brodcast de acordo com a porta de ingresso (tabela mac broadcast). Encaminhamento L3 Conforme mostrado na figura 5(c), caso o pacote possua um cabe¸calho MPLS, a defini¸c˜ao da porta de sa´ıda ser´a realizada com base neste protocolo. O switch realizar´a a troca de label ou manter´a o r´otulo atualmente utilizado, caso esteja desempenhando o papel de Label Switch Router (switch P), ou far´a a remo¸c˜ao da label, caso esteja na borda da malha MPLS (Label Edge Router -switch PE). Caso possua apenas cabe¸calho IPv4, primeiramente ser´a verificado se o endere¸co IP de destino pertence a uma Forwarding Equivalency Class (FEC) do MPLS. Neste caso, um cabe¸calho MPLS ser´a acrescentado antes do envio do pacote para a porta de sa´ıda. Caso contr´ario, o roteamento IP tradicional ser´a realizado. Em compara¸c˜ao com o pipeline descrito em [Kundel et al. 2019], al´em de algumas features distintas, tivemos o cuidado de criar um mecanismo para a defini¸c˜ao