#001 – Bare IP, No Eth header

Did you ponder of getting rid of the Ethernet header from the frame? This idea came to my mind couple of years ago. Weird, isn’t it? On the other side in the WAN there are many point to point connections. If you send packets through p2p links you can receive them on a far end only. No redirections. This is not the multiple access and destination network. Even for a shared segment switches could forward the traffic based on the IP destination address not on the MAC address. What do you think? It could be possible. Let’s have a look on pros and cons.

Possible advantages:

  • Overhead is not an issue today when we have so much bandwidth. 14 bytes less overhead. Around 17% savings for a 64 bytes frame (84 bytes including preamble and IFG), but just 2% for 576 bytes frame.  Note: I would leave CRC 4 bytes at the end of the packet. The IP checksum does not provide error detection for data and the TCP checksum cannot cover non-TCP protocols like UDP for example.
  • No need for ARP in IPv4. Simplicity rules!
  • No need to trace endpoints by MAC addresses on switches.
  • No excessive flooding when ARP timeout on endpoints/service nodes > MAC aging on switches.
  • No MAC address duplication for some multicast groups.
  • No need to map COS to DSCP and vice versa.
  • No need for the broadcast traffic. Broadcast storms no more!
  • IPv4 address is easier to remember than a MAC address.
  • MACinMAC in McDonalds only!
Can IP header be without Ethernet header on the Ethernet line?
Can IP header be without Ethernet header on the Ethernet line? What about VLANs?
source: https://en.wikipedia.org/wiki/IPv4#Header

Possible disadvantages:

  • No VLANs. We could use an IP option header (see a packet structure) but there would be a performance penalty. No priority tagging.
  • No layer-2 services like CDP, LLDP, QinQ, .1ad, .1x. No xSTP, oh wait…
  • Still flooding in the case of an unknown IP destination and multicast.
  • Issues to assign an IP address from DHCP. Identification required.
  • No MAB authentication.
  • Many applications would have to be rewritten. Also FHRP, NLB, clustering, all.
  • Issues with use of MPLS and other specific protocols. Ether-type in Ethernet informs about an incoming MPLS packet. There is no such field in the MPLS header. We could use some first bits from the label field. Let’s say a sequence ‘010101’ would inform a device about MPLS packet otherwise IP packet.
  • TRILL/SPB IETF Workgroup would be unhappy. Save their mood! Kill MPLS!
  • Nobody would change Ethernet physical interfaces. Too expensive.
  • No backward compatibility.
  • Not scalable option. Switches would need to store host routes. Layer 2 + 3 offers better scalability for LAN environments.

Ok, let’s leave it. I convienced myself. Get used to Layer 2 header. It is simply needed! At least in the LAN. 😉

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s