En tant que nouveau projet de la « Linux Foundation », Dent utilise le noyau Linux, Switchdev et d’autres projets basés sur Linux comme base pour construire un nouveau système d’exploitation réseau normalisé sans abstractions ni surcharge. Toutes les infrastructures sous-jacentes – y compris ASIC et Silicon – sont traitées de la même manière, tandis que les abstractions existantes sont simplifiés. Dent réunit les fournisseurs de silicium, les ODM, les SI, les OEM et les utilisateurs finaux dans tous les secteurs verticaux et permet la transition vers des réseaux désagrégés. Le plan d’action prévisionnel laisse entrevoir un système, avec toutes ses fonctions essentielles, finalisé pour fin 2021.
L’avènement de la désagrégation, c’est à dire du remplacement du modèle propriétaire matériel/logiciel proposé par les acteurs historiques du réseau, a posé le problème de la banalisation de la couche matérielle. En effet, si on est amené à réaliser autant de logiciels spécifiques qu’il y a de types de matériels avec ses SDKs, l’objectif de la désagrégation n’est pas facile à atteindre. La banalisation du matériel passe par une couche d’abstraction qui permet à la couche logicielle de s’adapter à plusieurs types de matériels différents.
On a beaucoup parlé de SAI (Switch Abstraction Interface) qui est un modèle de couche d’abstraction tournant dans le « User space » Linux, ce qui implique qu’une application située dans le « User space » pilote l’ASIC en contournant le Kernel. Une représentation du cache matériel (service d’état de commutation) est également conservée dans l’espace utilisateur. Il s’agit généralement d’un stockage clé-valeur comme Redis (ACS) ou OVSDB (Open vSwitch). Un des avantages de tout faire en « User space » est que le développeur peut prendre une distribution Linux standard et ajouter simplement les modifications nécessaires. Aucune expertise du noyau Linux n’est requise, il y a juste besoin du pilote SAI pour l’ASIC concerné. On peut également changer de matériel en changeant simplement le pilote SAI. SONIC est une exemple de NOS (Network Operating System) qui utilise SAI.
Il y a déjà de nombreuses années que les fabricants d’ASIC supportent Linux, mais avec SAI ils doivent maintenir une application SDK en « User space » avec un pilote de Kernel. De plus, pour pouvoir fonctionner, les applications doivent être réécrite spécifiquement pour SAI. C’est là que SwitchDev entre en scène. C’est un modèle d’abstraction tournant dans le « Kernel space ». Les applications Linux existantes peuvent fonctionner sans aucune modification. Ce que switchdev exige, c’est que les fournisseurs d’ASICs élaborent leurs pilotes et que les développeurs de NOS soient, éventuellement, sur un noyau différent de celui de la distribution standard.
SwitchDev est une couche d’infrastructure du Kernel Linux qui permet d’offloader le « Data plane » du Kernel vers l’ASIC du commutateur. De cette façon, il permet le remplacement des SDK et NOS propriétaires par une interface Linux ouverte standard. Pour les fournisseurs de matériels OEM / ODM, ce pilote Linux ne nécessite pas de processeur puissant pour fonctionner. Le NOS alimenté par Switchdev est plus léger que, par exemple, SONiC.
DentOS est un NOS basé sur SwitchDev et construit sur la base du système Open Network Linux, lui même inspiré de Debian Linux. A la base, Open Network Linux supporte plusieurs APIs telles que OF-DPA (OpenFlow Data Plane Abstraction) et OpenNSL (Open Network Switch Library) portés par Broadcom, ainsi que SAI. Vous noterez que DentOS/SwitchDev est actuellement supporté sur des ASICs Mellanox et Marvell et que Broadcom n’est pas encore dans la liste HCL (Hardware Compatibility List) des fournisseurs d’ASIC supportés.
La version 1.0 de DentOS se nomme « Arthur », supporte les systèmes ARM64 et AMD64, les ASICs Mellanox et Marvell et se met en place avec l’installateur ONIE. Les fonctions attendues dans la version 1.0 sont les suivantes :
- NAT-46,44, and PT
- NAT on pure Layer-3 port
- NAT on VLAN tagged port (bridge)
- NAT support across LAG port
- Configuring 802.1q interface (IpRoute2, Ifupdown2)
- Configure using IpRoute2
- Configure using ifupdown2
- Configuring IP on 802.1Q interface
- Configure using IpRoute2
- Configure using ifupdown2
- Routing on 802.1Q interface
- Configure static routing using IpRoute2
- Configure routing using FRR
- PoE controller
- Support for DNI platforms
- Support for Accton platforms
- Support for new ODM platforms
- Telemetry
- Platform Telemetry
- Network Telemetry
- Netconf
- Netconf Edit
- Netconf Get
- Netconf replace
- gNMI
- gNMI get
- gNMI set
- gNMI subscribe
- gNMI response
- Configuration schema modelling
- YANG modelling for platform
- YANG modelling for Network
- Dynamic Routing
- Support for OSPF via FRR
- Support for ISIS via FRR
- Scale & Performance Improvements
- Improve Firewall Scaling numbers
- Improve Firewall Programming Performance
- Resource management for ACLs
- Add Flags to recognize LOCAL Ips
- Dataplane policing
- BUM traffic Policing
- Data packet policing
- Control packet policing
- User application support
- Extend TC persistency tool for policers
- IPv6 parity with IPv4
- Et bien d’autres…