Pourquoi utilisons-nous toujours Ethernet?

29

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?

rfb
la source
Même si ce que vous dites se produisait, L2 ne cesserait pas d'exister. Frame-Relay est L2, PPP est L2, HDLC est L2, ATM est L2, 802.11 est L2, IPSec est L2, etc.
codé
Une réponse vous a-t-elle aidé? Si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
Ron Maupin

Réponses:

27

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.

Mike Pennington
la source
1
Votre argument sur le fait que certains protocoles nécessitent Ethernet est à l'envers. Ces protocoles ont été inventés pour Ethernet. Si nous n'avons pas de domaines Ethernet L2, nous n'avons pas besoin de STP. ARP est utilisé pour mapper les informations IP sur Ethernet et encore, si nous n'avons pas Ethernet, nous n'en aurions pas besoin. Choisir entre IPv4 et IPv6 sur un lien serait facile si nous supposons plutôt raisonnablement que nous n'avons que IP sur le lien, car la version IP est les 4 premiers bits des en-têtes IPv4 et IPv6. ISIS exécute 802.2 LLC sur des réseaux Ethernet mais ne le fait évidemment pas sur d'autres supports tels que SDH ou des liaisons série.
kll
1
Vous avez mal compris le point. Je réponds "Puisque nous utilisons Ethernet principalement comme moyen de transport IP, y a-t-il une raison pour avoir cette couche supplémentaire de surcharge L2?" en 2013 . Oui, certaines de ces choses ont été inventées pour Ethernet, mais ce n'est pas la question qui a été posée. L'OP veut savoir pourquoi nous avons encore besoin de la surcharge des trames Ethernet.
Mike Pennington
2
Je pense que vous ne lisez pas toute la réponse. Le dernier paragraphe explique très clairement pourquoi utiliser toujours l'encapsulation Ethernet. Si vous êtes si confiant dans vos idées, allez-y et démarrez une entreprise qui implémente IP directement sur le fil. Mais s'il s'agit d'une entreprise publique, je la mettrai en bourse à partir du jour de son introduction en bourse.
Mike Pennington
2
@kll, "Ces protocoles ont été inventés pour Ethernet." Si vous envisagez d'anciens messages, veuillez clarifier vos faits. "Si nous n'avons pas de domaines Ethernet L2, nous n'avons pas besoin de STP." STP fait partie de l'IEEE 802.1; Ethernet fait partie de l'IEEE 802.3. Tout comme les VLAN, STP a été conçu indépendamment d'Ethernet et, en tant que tel, peut être utilisé dans n'importe quel environnement à plusieurs ponts pour empêcher les boucles L2. "ARP est utilisé pour mapper les informations IP sur Ethernet et encore, si nous n'avons pas Ethernet, nous n'en aurions pas besoin." Encore une fois, faux. ARP existait également pour les technologies L2, Token Ring étant l'une d'entre elles.
YLearn
2
@kll, j'ai voté pour les deux réponses. Ils abordent tous les deux différentes parties de la question posée par l'utilisateur. Oui, ytti répond mieux à une partie de la question que vous avez citée du PO. Cependant, en plus de votre devis, il y a "Pourquoi utilisons-nous toujours Ethernet?" et "y a-t-il une raison d'avoir cette couche supplémentaire de surcharge L2?" » et « Y a-t-il un argument convaincant pour garder les choses telles qu'elles sont? » Tout cela n'est pas bien traité par la réponse de ytti. En outre, le PO égalisant le point final à commuter en "point à point" est au mieux défectueux pour une variété de raisons non évoquées.
Apprendre
16

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.

ytti
la source
Très bonnes pensées. J'ai également pensé à pouvoir supprimer ARP - je suppose que c'est juste un autre bonus.
rfb
8

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.]

Ricky Beam
la source
2

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.

Peter Green
la source
0

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.
mmv-ru
la source