Why use a Type field in an Ethernet frame?

Beyond my scope of knowledge but I believe they come in handy when doing things like virtualisation, SANs, etc.

The way it's conceptually explained in TCP/IP texts is that the TCP/IP stack has different modules. The IP module, the ARP module, the RARP module, the TCP module, the UDP module, etc. The type fields are used to instruct one layer of the stack which module it is supposed to send it to next. I guess it's used for efficiency, to not have to have an intermediate step at each layer that does this. The key word you want to research is 'demultiplexing'.

PS.
However, this is not really how modern network hardware works. In short, if you encapsulate a TCP segment in an IP packet, in a frame, you have a series of three headers:

[frame header][ip packet header][tcp header][.................data payload...................]

It would be inefficient to check the frame for the type, strip that header, send it to the ip module (or another module), check the ip header's destination address to determine if the packet is destined for a local interface, or if it is transit, etc. Instead, you use a concept called 'classification' that essentially looks at the series of 1s and 0s formed by all headers, and then makes a decision based on that.

How would the receiver know how to handle the bits after the ethernet header? Without a type field you would need to program the receiver to expect a specific packet type, then you would be limiting yourself to one layer 3 protocol per interface. How would the interface know a regular ipv4 packet from arp, dhcp, mpls ? The only way is to have some kind of identifier in the frame to tell it how to interpret the bits following the frame header. If a packet doesn't conform to what its expected to be it gets dropped as a malformed packet.
The type field in ethernet is similar to the protocol field in the ip header, they perform the same job, telling the upper layer how to handle the bits.

Now for some Trivia.

A packet arrives on an interface, a lookup reveals that the packet must be label switched, a label is placed between the l2 and l3 header, the l2 type field is modified to indicate an mpls header is present. The packet gets label switched until it arrives a the remote PE where the label is removed. How does the remote router know what l3 protocol is being used?

added to the post above instead.

EdTheLad wrote: »

Now for some Trivia.

A packet arrives on an interface, a lookup reveals that the packet must be label switched, a label is placed between the l2 and l3 header, the l2 type field is modified to indicate an mpls header is present. The packet gets label switched until it arrives a the remote PE where the label is removed. How does the remote router know what l3 protocol is being used?

Again beyond my knowledge but doesn't MPLS encapsulate the original packet in it's own MPLS-y packet? So that would be dropped at the PE router revealing the actual original packet?

EdTheLad wrote: »

Now for some Trivia.

A packet arrives on an interface, a lookup reveals that the packet must be label switched, a label is placed between the l2 and l3 header, the l2 type field is modified to indicate an mpls header is present. The packet gets label switched until it arrives a the remote PE where the label is removed. How does the remote router know what l3 protocol is being used?

Because the ethernet frame has an Type field which indicates IP (type 0800)? I think.. and what has been just posted above.

EdTheLad wrote: »

Now for some Trivia.

A packet arrives on an interface, a lookup reveals that the packet must be label switched, a label is placed between the l2 and l3 header, the l2 type field is modified to indicate an mpls header is present. The packet gets label switched until it arrives a the remote PE where the label is removed. How does the remote router know what l3 protocol is being used?

Like this:

If you have an arriving label switched packet and the label is removed and the frame header is useless, you could just wildcard the entire frame header and then have the action for the pattern be to rewrite a new frame header and send out a particular interface. Essentially, it doesn't matter a priori what the layer 3 protocol is because what matters is if a pattern for that protocol has been installed in the TCAM.

FrankGuthrie wrote: »

Because the ethernet frame has an Type field which indicates IP (type 0800)? I think.. and what has been just posted above.

But it has been modified to indicate MPLS.

Magic Johnson wrote: »

Again beyond my knowledge but doesn't MPLS encapsulate the original packet in it's own MPLS-y packet? So that would be dropped at the PE router revealing the actual original packet?

Could you explain to me what would make it handy, when talking about SAN and virtualisation?

Magic Johnson wrote: »

But it has been modified to indicate MPLS.

Not when it reaches the PE as you have stated.

fredrikjj wrote: »

Like this:

If you have an arriving label switched packet and the label is removed and the frame header is useless, you could just wildcard the entire frame header and then have the action for the pattern be to rewrite a new frame header and send out a particular interface. Essentially, it doesn't matter a priori what the layer 3 protocol is because what matters is if a pattern for that protocol has been installed in the TCAM.

Whaaaaaaaa.... This look like higher math to me.

FrankGuthrie wrote: »

Could you explain to me what would make it handy, when talking about SAN and virtualisation?

I don't feel confident in answering that question mate, but fibre channel over ethernet is one.

Fibre Channel over Ethernet - Wikipedia, the free encyclopedia

So Fred, you've explained how subsequent packets are forwarded, but you need to answer how the TCAM is updated for the first packet?

To be clearer!
On the first PE the ethernet type field is modified from 0x0800 to 0x8847 i.e. changed from ipv4 to mpls. On the remote PE the type code is checked and seen to be mpls, the mpls header is examined and the lfib table indicates to pop the label, the mpls header has no protocol type field. How does the PE know what l3 protocol?

FrankGuthrie wrote: »

Not when it reaches the PE as you have stated.

That's the label that gets stripped not the type.

EdTheLad wrote: »

So Fred, you've explained how subsequent packets are forwarded, but you need to answer how the TCAM is updated for the first packet?

To be clearer!
On the first PE the ethernet type field is modified from 0x0800 to 0x8847 i.e. changed from ipv4 to mpls. On the remote PE the type code is checked and seen to be mpls, the mpls header is examined and the lfib table indicates to pop the label, the mpls header has no protocol type field. How does the PE know what l3 protocol?

Is it something to do with the label stack? I've just imaged it to see what an MPLS packet looks like and it is just behind the IP Header.

Mpls label is 32 bits, 20 for label, 8 ttl, 1 for "bottom of stack" and 3 for EXP(qos marking), so nothing there to indicate higher layer protocol type.

I'll give the answer in a couple of hours if no one gets it. My moneys on Fred though! no pressure Fred lol.

This feels like I've been blindfolded, put in the middle of a playing field, told my target is the size of a peanut and given a Gatling gun.

EdTheLad wrote: »

I'll give the answer in a couple of hours if no one gets it. My moneys on Frank though! no pressure Frank lol.

Hey that's unfair lol!

So...MPLS has two ethertype fields, one for upstream one for downstream? EDIT: No that's to tell it whether upstream or downstream MPLS right?

It has to be something to do with the label values?

EDIT: No, clarity gone, I'm chasing dead ends. Sorry for confusion.

Was supposed to say Fred, edit it lol. You mean in ethernet? there are 2, one for unicast, one for multicast.

EdTheLad wrote: »

I'll give the answer in a couple of hours if no one gets it. My moneys on Fred though! no pressure Fred lol.

Not enough time to research it at the moment, and my MPLS knowledge is fairly close to zero. Though, I still think that it sounds plausible that you could just tell the switch that it's an MPLS endpoint/egress/whatever the official name is, which makes it ignore the label. The packet is then matched against a TCAM built using CEF, or whatever method you use to build a FIB. An outgoing interface is selected based on this matching, and a new frame is used for the encapsulation that uses the correct ethertype. I figure that there is some MPLS specific mechanism for determining the payload since you're asking about it, but it doesn't seem totally necessary to know this, assuming that you can match against the entire TCAM and the TCAM isn't separated into several different data structures depending on what kind of protocol you want to forward (which it probably is then).