Ethernet VLAN using LLC/SNAP encapsulation

Oct 23, 2007 5 Replies
A

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



Vote
Twitter Facebook LinkedIn
A

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

Vote
Twitter Facebook LinkedIn
A

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

Vote
Twitter Facebook LinkedIn
M

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

Vote
Twitter Facebook LinkedIn
M

Sorry, the G.8012 amendment.

Vote
Twitter Facebook LinkedIn
A

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

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required