[rbridge] Trivial (I hope) 802 VLAN encoding question

[Silvano Gai]

I haven't seen a large use of Priority tagged frames, 

But anyhow they are easy to deal with

 

-- Silvano

 

________________________________

From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake at motorola.com] 
Sent: Tuesday, January 09, 2007 7:36 PM
To: Silvano Gai; rbridge at postel.org
Subject: RE: [rbridge] Trivial (I hope) 802 VLAN encoding question

 

So presumably a "priority tagged frame" would normally be from an end
station that was trying to assert some priority but not claim a
particular VLAN. (Presumably you don't want to have to configure VLAN
IDs into end devices most of the time.)

 

Donald

 

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Tuesday, January 09, 2007 4:57 PM
To: Radia Perlman; rbridge at postel.org
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question

 

Radia,

 

Inside a bridge ALL frames are VLAN tagged. The cases of NULL VLAN, VLAN
0 or no VLAN do not exist once the frame enters the bridge. These are
only link concepts.

 

Each port has a Port_VLAN parameter that is assigned by management. On
many switches its default value is 1.

 

When a port receives the frame it does the following:

 

if (1Q tag exists)

{ 

   if (1Q.VID == 0)

   {

      VLAN = Port_VLAN';  // Priority tagged frame

   }

   else

   {

      VLAN = 1Q.VID; // 1Q tagged frame

   }

}

else

{

   VLAN = Port_VLAN; // Untagged frame

}

 

Therefore you can assume that any frame inside an RBridge has an inner
VLAN Tag.

 

This is consistent with IEEE 802.1Q that states:

 

VLAN technology introduces the following three basic types of frame:

a) Untagged frames;

b) Priority-tagged frames; and

c) VLAN-tagged frames.

 

An untagged frame or a priority-tagged frame does not carry any

identification of the VLAN to which it belongs. Such frames are

classified as belonging to a particular VLAN based on parameters

associated with

the receiving Port, or, through proprietary extensions to IEEE 802.1Q

standard, based on the data content of the frame (e.g., MAC Address,

layer 3 protocol ID, etc.).

 

A VLAN-tagged frame carries an explicit identification of the VLAN to

which it belongs; i.e., it carries a tag header that carries a non-null

VID. Such a frame is classified as belonging to a particular VLAN based

on the value of the VID that is included in the tag header. The presence

of the tag header carrying a non-null VID means that some other device,

either the originator of the frame or a VLAN-aware Bridge, has mapped

this frame into a VLAN and has inserted the appropriate VID.

 

-- Silvano

 

 

> -----Original Message-----

> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On

> Behalf Of Radia Perlman

> Sent: Sunday, January 07, 2007 6:53 PM

> To: rbridge at postel.org

> Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question

> 

> Is there a distinction between VLAN 0 and null VLAN? In other words,
if

> there is

> no VLAN tag, is that the same as being in VLAN 0?

> 

> I'm trying to specify how to distinguish the per-VLAN instance of
IS-IS

> from the core instance.

> I was assuming it would be done based on an inner VLAN tag. But
suppose

> there were no VLANs,

> but you still wanted different instances for the endnode information
and

> the core information (so that

> truly inner guys wouldn't have to store all the endnode membership
link

> state information).

> You couldn't do that with a VLAN tag, unless you used VLAN tag with

> VLAN=0 for the endnoe

> membership instance.

> 

> Not a really horrible problem -- we can certainly find a way of
encoding

> this, but just wondering if

> VLAN tag will work (where we use VLAN tag explicitly with VLAN = 0 to

> indicate the endnode

> membership inforamtion for the null VLAN?)

> 

> Radia

> 

> _______________________________________________

> rbridge mailing list

> rbridge at postel.org

> http://mailman.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20070109/82f0affc/attachment-0001.html