1. Home
  2. Ethernet LAN
  3. Ethernet VLAN using LLC/SNAP encapsulation

Ethernet VLAN using LLC/SNAP encapsulation

IEEE 802.1Q seems not to be terribly clear in answering this question: can a VLAN-tagged frame use LLC/SNAP encapsulation within the tagged frame?

Clause 9.4 says that a VLAN over Ethernet, i.e. which supports the Protocol Type field, uses the TPID indicating VLAN tag (which is

0x81-00).

Say this is followed by the expected TCI tag, and that the CFI bit is

0 (indicating canonical format of MAC addresses). In this case, the 16- bit TCI tag is not followed by any other header extension. Simple case.

Now comes the Protocol ID encapsulated within the tagged frame.

The question is, is there any reason why I can't encode that 2-byte field following the TCI tag as a length, i.e. less than 1500, and follow that with LLC header 0xAA-AA-03 and a SNAP header?

Should be legitimate, but I wanted to be sure.

Thanks.

Bert

Reply to
Albert Manfredi
Loading thread data ...

It is legitimate and it should be fairly clear from the spec. Fig C-9 in Annex C of 802.1Q covers exactly this. All that adding the VLAN tag does is displace the original contents of the frame starting with the type/length by 4 bytes.

Anoop

Reply to
anoop

Thanks, Anoop. Also Figure C-6 shows this, but never the complete example, explicitly showing the SNAP header. On the other hand, no reason why they should get so specific about just one type of LLC encpapsulation, I suppose.

Thanks again.

Bert

Reply to
Albert Manfredi

Bonjour Albert,

Perhaps you can see much more in the G.8012 (08/2004) ITU-T recommendation, for example the figure 6-15.

You have : (1) LLC encapsulation : DSAP 0xAA, SSAP 0xAA, Control 0x03 (2) SNAP encapsulation : OUI 0x00-80-C2, Pid 0X00-07 (for MAC without FCS and no padding), PAD 0x00-00 (3) SNAP payload : DA, SA followed by the MAC SDU.

The MAC SDU could be a tagged MAC.

You can see also RFC 2684 and RFC 2364 to see all the possible client services.

Take profit of the amendment 05/2006: "the length encapsulation of client data since that encapsulation is not used for Ethernet over Transport" only TYPE is recommended for the transport.

Best regards, Michelot

Reply to
Michelot

Sorry, the G.8012 amendment.

Reply to
Michelot

Bonjour Michelot,

I had to smile when you mentioned the ATM RFC (2684). I agree, though, that VLANs and ATM VCs are now very similar beasts. Especially with Ethernet now being capable of very long distances.

Indeed, RFC 2684 goes into considerably more detail in describing all the possible encapsulations than does 802.1Q.

Merci.

Albert

Reply to
Albert Manfredi

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.