Pourquoi utilisons-nous toujours Ethernet?

Il ne fait aucun doute que la grande majorité des trames Ethernet transportent des paquets IP. Je sais qu'il existe également divers autres protocoles qui peuvent être transportés sur Ethernet, mais ceux-ci peuvent également être transportés sur IP.

Avec les réseaux Ethernet modernes en duplex intégral, Ethernet s'est effectivement transformé en une interconnexion point à point entre un point d'extrémité et un commutateur, qui commute le paquet en fonction de la destination MAC. Les commutateurs L3 font la même chose mais effectuent également un routage IP.

Puisque nous utilisons Ethernet principalement uniquement comme moyen de transport IP, y a-t-il une raison d'avoir cette couche supplémentaire de surcharge L2? Pourquoi ne pas simplement acheminer les paquets en fonction de l'adresse IP de destination? Je suppose que cela briserait le modèle OSI, dans une certaine mesure, dans la mesure où L2 cesserait d'exister.

Imaginez une technologie de couche liaison qui a été conçue uniquement pour le transport IP et qui ne possède pas de fonctionnalité ou d'en-tête L2 spécifique. Les commutateurs et les routeurs continueraient d'exister comme aujourd'hui: les commutateurs seraient des "routeurs de base" (tout comme les commutateurs L3) et ne prennent généralement que des routes fixes et une route par défaut. Flux de commutation: y a-t-il une route en place pour cette destination? Collez-le dans la file d'attente de cette interface. Sinon, collez-le dans la file d'attente de l'interface de la route par défaut.

Y a-t-il un argument convaincant pour garder les choses telles qu'elles sont?

Puisque nous utilisons Ethernet principalement uniquement comme moyen de transport IP, y a-t-il une raison d'avoir cette couche supplémentaire de surcharge L2?

Nommer quelques protocoles ou fonctionnalités communs qui nécessitent une surcharge L2 tels que Ethernet:

• Spanning-Tree (nécessite 802.2 LLC)
• ISIS (nécessite 802.2 LLC)
• Vlans
• ARP (qui n'est pas seulement pour Ethernet)
• Choisir entre IPv4 et IPv6
• Wifi IEEE 802.11 (qui partage de nombreuses fonctions de base avec Ethernet 802.3, mais est fondamentalement un protocole différent)

Ethernet s'est effectivement transformé en une interconnexion point à point entre un point d'extrémité et un commutateur, qui commute le paquet en fonction de la destination MAC. Y a-t-il un argument convaincant pour garder les choses telles qu'elles sont?

Vous simplifiez exagérément l'argument pour suggérer qu'Ethernet est uniquement destiné à l'adressage et au point à point. IEEE 802.3 couvre également la couche physique: diverses formes de supports en cuivre et en fibre, codage sur le fil, récupération d'erreur, conditionnement de ligne, etc. Si vous ajoutez toutes ces fonctions directement sur IPv4, vous avez maintenant dupliqué de nombreuses fonctions dans Ethernet et qu'avez-vous vraiment enregistré? Cela ignore également les efforts monumentaux de normalisation et d'ingénierie pour les intégrer directement dans IPv4 et IPv6. Mon cerveau me fait mal de penser comment cela fonctionnerait de toute façon au niveau pratique.

En fin de compte, l'argument est d'ordre économique. La planète entière a conçu des serveurs, des commutateurs, des systèmes d'exploitation, etc. Autour de l'hypothèse d'une couche de liaison entre IP et le codage du signal sur le fil. Ethernet fait beaucoup pour nous, et il est extrêmement bon marché car il est désormais devenu la technologie d'interconnexion de facto pour la plupart des ordinateurs de la planète. Remplacer Ethernet revient un peu à remplacer le Congrès américain en tant qu'organe directeur. Ce n'est peut-être pas parfait, mais il est inconcevable de faire autre chose à ce stade.

C'est une très bonne question.

Je ne pense pas que nous allons nous débarrasser d'Ethernet, car les liaisons multi-accès seront toujours nécessaires indéfiniment.

Cependant, une grande partie du réseau principal n'a vraiment aucune utilité pour DMAC / SMAC, il devrait donc certainement y avoir une variante «point à point» d'Ethernet avec une trame beaucoup plus courte. Au lieu du 18B actuel (DMAC + SMAC + Type + FCS), vous pourriez le faire avec 6B (Type + FCS).
Cette variante point à point d'Ethernet compenserait bien la surcharge nécessaire dans le cœur (étiquettes MPLS, étiquettes VLAN), de sorte que la taille de trame client / bord suivrait de plus près la taille de trame principale. Cela supprimerait également le besoin d'ARP et de ND, réduisant les risques et simplifiant le cœur.
Techniquement, il n'y a aucune raison pour que vous ne puissiez pas supprimer entièrement la partie L2 d'Ethernet, mais vous allez avoir besoin de sa partie L1, car IP lui-même n'a aucune spécification sur la façon de le coder sur n'importe quel fil. Vous pouvez donc exécuter Ethernet L1 avec la charge utile (IP) L2 directement par-dessus.

Je suis personnellement convaincu que lorsque le moment sera venu de spécifier un nouvel en-tête Ethernet pour utiliser EUI64 au lieu d'EUI48, les gens voudront une version point à point de ce protocole L2. Je ne pense pas que ce sera «null L2», car au moins Frame Check Sequence (FCS) et le type de charge utile (IP? MPLS? Ethernet?) Semblent souhaitables.

J'y répondrai par une question absurde ... Pourquoi n'utilisons-nous pas encore ARCnet ? Ou Token Ring?

Il existe (étaient et seront) de nombreuses technologies de couche 2. Pour les systèmes "de bureau", Ethernet a gagné. Pourquoi l'utilisons-nous encore ... la réponse la plus simple est parce que cela fonctionne; la technologie est simple, bon marché, robuste et abondante. (lire: technologie éprouvée ) Pour mémoire, il existe des cartes ATM "de bureau" PCI - je n'en ai pas vu depuis des années, et je n'en ai jamais vu une réellement utilisée.

Ce que vous proposez est simplement une nouvelle technologie de couche 2. Je vous souhaite bonne chance pour que le monde l'adopte.

[Ok, l'anneau à jetons existe toujours, mais il est extrêmement rare.]

Y a-t-il un argument convaincant pour garder les choses telles qu'elles sont?

Bonne question, quelques réflexions.

1. La compatibilité est souvent plus importante que l'efficacité.
2. La plupart des constructeurs de réseaux (en dehors de certaines applications de très haute sécurité) ne veulent pas affecter statiquement des périphériques aux ports. Il faut donc une sorte de système pour localiser automatiquement les appareils.
3. Il est utile d'avoir un identifiant qui identifie un matériel spécifique où qu'il se trouve branché.
4. Pour IPv4 au moins, nous ne voulons probablement pas gaspiller une adresse IPv4 sur chaque port de commutateur.

Il serait probablement possible de concevoir un protocole de liaison qui a résolu de 2 à 4 tout en ayant une surcharge d'encapsulation inférieure à la trame Ethernet ou éventuellement pas de surcharge d'encapsulation, mais ce ne serait pas un cas trivial de dire "utilisez simplement IP".

Et puis il faut encore convaincre les gens sur 1, beaucoup de peine à adopter une nouvelle norme pour un gain relativement faible.

Augmenter les vitesses tout en conservant le même format de cadrage est le chemin de la moindre résistance. C'est donc ce qui se passe.

Ethernet P2P est possible. Mais

• Il nécessite un réseau L3 complet (chaque lien utilise un adressage IP fixe)
• La surcharge des adresses MAC est sensible pour les petits paquets et dans les tunnels L2.
• À propos des performances des liens. Si la liaison n'est pas assez rapide, ne créez pas de nouveaux protocoles et logiciels, faites simplement les mêmes choses simples en 10X plus rapidement. C'est ainsi qu'Ethernet a gagné.
• À propos des tunnels L2. Dans le réseau L3 uniquement, les tunnels L2 n'ont aucun sens.
• L'unification est une bonne chose.