Ethernet over Ethernet

Bonjour,

I don't know the reason why it is not possible to have an Ethernet frame (ETH) directly encapsulated in an Ethernet frame (ETH).

Take care, I'm not talking about 802.1ah-2008 MAC-in-MAC, or

802.1ad-2005 Q-in-Q.

There is no Ethertype.

The only possibility is: ETH over MPLS over ETH, with the Ethertype

0x8847.

Thanks for your opinion, Michelot

Reply to
Michelot
Loading thread data ...

On 04.06.2010 13:39 Michelot wrote

Look for Provider Backbone Bridges and Provider Backbone Transport.

Provider Backbone Bridges (aka IEEE 802.1ah, Mac-in-Mac, or MinM) overcome the service scaling limitations present into today's native Ethernet networks - which are primarily based on QinQ implementations (aka IEEE 802.1ad or Stacked VLANs). QinQ only allows for 4094 service instances per metro due to the number of bytes of the VLAN tag in the Ethernet header - not nearly enough to accommodate the anticipated subscriber base for IPTV, wireless, and other next-generation services.

Provider Backbone Bridges allow for orders of magnitude greater scalability (up to millions of service instances per metro) by physically providing more addressing space in the Ethernet frame. Additionally, it reduces the amount of state the network is required to maintain and enhances security by clearly separating the customer and provider addressing space.

HTH, Arnold

Reply to
Arnold Nipper

Of course it is possible. It's just not very *useful*. Are you talking about something like the following?

Outer Ethernet frame: DST - SRC - TYP - Payload - CRC

and the outer frame payload is another Ethernet frame,

Inner Ethernet frame: DST - SRC - TYP - Payload - CRC

If this is what you're thinking of - the problem is that there is little (if any) hardware today that will do something sensible with the combined outer/inner Ethernet frame.

If there is no Ethertype, how do you know which upper layer protocol should handle the inner frame?

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Reply to
Steinar Haug

Bonsoir Arnold,

Thanks very much for your description. Perhaps you don't read my topic sentence above. I'm not talking about 802.1ah-2008 MAC-in-MAC, or

802.1ad-2005 Q-in-Q.

It could be another possibility.

Customer Ethernet > Ethertype > provider Ethernet

Would you know the Ethertype for that?

Best regards, Michelot

Reply to
Michelot

Bonsoir Steinar,

Sorry for my writing, I didn't see the Ethertype for the encapsulation of an Ethernet frame in an Ethernet frame.

Customer Ethernet > Ethertype and provider Ethernet

We have commonly that

Customer Ethernet > MPLS > Provider Ethernet

For this case the Ethertype is 0x8847 as noted in :

formatting link
Would you have an idea for an Ethertype corresponding to an Ethernet frame (from a customer) over an Ethernet frame (from a provider).

Perhaps it doesn't exist.

Best regards, Michelot

Reply to
Michelot

I haven't seen one. Furthermore, I don't know of any equipment which handles such an encapsulation. It could certainly be *done*... but I guess there hasn't been much demand.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Reply to
Steinar Haug

you are treating labels as a "global resource" where numbers need to be kepy unique - surely they are more like Frame Relay PVC numbers and should be re-useable on each link?

If the equipment you use imposes more restrictions than that, then that is down to how the equipment is built / confiugred....

Also, even several years ago QinQ was not limited to 2 levels on Nortel passport switches - you could have 7.

So - leaving 1 for customer Q labels 4096 ^ 6 is probably enough for a while......

Systems using L2 over MPLS also have ways around VLAN numbers being a limiting factor.

Reply to
Stephen

Bonsoir Stephen,

Do you remember what was the Qtags for these levels?

Not really!

Could we refer to EVP-LAN? We could have L2 (C-VLAN or S-VLAN) over MPLS.

Today, it's S-VLAN. Before, it was C-VLAN (the classical VLAN).

In fact, using C-VLAN over MPLS is just for the separation of the multiplexing channels in an MPLS connection to join a distinct egress PE. Each channel is associated to a VSI table in the ingress PE.

To have 4096 channels in such a connection is already important (STM-4 if each channel is 100 Mbit/s). And, if we need others channels, we can create another MPLS connection and multiplex all that in a server layer.

The limitation is not in this case.

Best regards, Michelot

Reply to
Michelot

Bonsoir Steinar,

I just realize that

The case (1): customer Ethernet > MPLS > Provider Ethernet could be similar to the case (2), the PBB variant.

- The Ethertype 0x8847 for MPLS in the case (1) is replaced by the Ethertype 0x88E7 for the I-TAG TCI in the case (2).

- The MPLS label (20 bits) is replaced by I-SID field (24 bits).

- The customer Ethernet is same in the both cases.

The possibility I was looking for could be:

Customer Ethernet with C-VLAN > Provider Ethernet with S-VLAN

In this case Ethertypes are 0x8100 (for C-TAG) and 0x88A8 (for S-TAG).

Best regards, Michelot

Reply to
Michelot

Bonsoir,

Euh.. sorry, I wrote to Arnold that I was not interested by 802.1ad. So we can remove S-VLAN.

I was simply impressed by the 7 levels of Stephen.

Best regards, Michelot

Reply to
Michelot

You can chain Ethernet switches together and get as many levels as you want, really. Think of it as an extension of QinQ.

We use 2 levels of VLAN tagging normally. In specific situations we also use 3 levels - but we try to avoid it.

There is no magic here. It's a question of scaling your network versus how much info you lose by having the switches only look at the outer VLAN tag (even when you know there are one or more inner VLAN tags).

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Reply to
Steinar Haug

Steinar Haug wrote: (snip)

Or, to continue with the OP's quesition ... since we have VLAN tags there is no need for an encapsulation ethertype.

Just use ethertype X'8100', add two more bytes of zeros, and you have a nicely encapsulated ethernet packet, fully conforming (even though it can be more than 1500 bytes).

Now, if you want to encapsulate including source and destination MAC address, that is another question. If I thought of a reason why you would want to do that, then maybe I would try to find an answer. Note, though, that in that case you are way over the maximum length.

-- glen

Reply to
glen herrmannsfeldt

Well, standard VLAN tagging uses ethertype X'8100' so it isn't right to say that there is no ethertype.

I just noticed Cisco's ISL, though, which really does encaplsulate the whole frame from destination address through FCS. It adds a

26 byte header and an additional FCS trailer for 30 more bytes.

There has always been the question about the length limit and normal VLAN (four byte) tags. Well, wikipedia seems to suggest up to three levels of VLAN, so 12 extra bytes.

Cisco seems to call ISL tagged frames jumbo, such that they might not be supported going through other devices. I don't see any description of the ISL header, but suspect that the first two bytes are a registered ethertype to avoid confusion.

-- glen

Reply to
glen herrmannsfeldt

outer tag was normal 802.1Q, then some Nortel numbers i dont remember

- probably related to what they pushed for provider Ethernet.

We use 2 layers of tags as do many other providers on Ethernet WAN delivery pipes.

1 tag gets stripped by an Ethernet NTE type device to flag traffic to a specific LAN port or management (the device is an Adva FSP 150 at work) - remaining tags are for VPW type point to multipoint, or just passed transparently depending on service.

Reply to
Stephen

Bonsoir Stephen,

Thanks for these words.

I would say that VPW is point to point. But it doesn't care, we need labels if the transport layer is shared by several users.

Best regards, Michelot

Reply to
Michelot

Bonsoir Glen,

You're right. I realized after writing that Qtag (C- or S- or B-) are also Ethertypes.

Best regards, Michelot

Reply to
Michelot

I didn't find the ethertype for Cicso's ISL, though.

It would be interesting to know.

-- glen

Reply to
glen herrmannsfeldt

Bonjour Glen,

By chance, I found a link that describes ISL in details and with figures, in particular the 24-byte header.

formatting link
Do you see something that would interesting to mention?

Best regards, Michelot

Reply to
Michelot

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.