Subject: [rbridge] VLANs and type field

From: Vishwas at sinett.com (Vishwas Manral)
Date: Tue, 9 Aug 2005 23:52:26 -0700

Hi Radia/ Joe,

I got the use of the "type" field. The original packet is still saved so
is the type field in the header.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Tuesday, August 09, 2005 11:09 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] VLANs and type field

Re: Vishwas's question about VLANs (I'm changing the subject line to be 
more explicit), and the "protocol type"
question later

If I understand your question...

 >>Vishwas Manral wrote:

>>Would "Protocol VLAN's" work with rbridges? With the etherType
pointing to the Rbridge >>and not the protocol above I think it would
not.

It is our intent that VLANs work with RBridges. The way it would work is

that the VLAN tag
would be in the inner header, and ignored by the intermediate RBridges 
while the packet is in
transit. So there would be a core infrastructure that can forward any 
packet from any VLAN, but
the links upon which endnodes reside would be configured (as they are 
today) with VLAN numbers.
The first RBridge, if it is configured to add a VLAN tag of "VLAN A" to 
a packet from port p, will
add the VLAN tag to the inner header (just like a bridge would do 
today), and then look up the
egress RBridge, put the ID of the egress RBridge in the shim header, and

then put on the encapsulation
header.

Intermediate bridges would not see this as a VLAN packet...just an 
ordinary packet delivered hop by hop to
each RBridge.

The final RBridge would remove the VLAN tag before sending it to the 
final endnode (just as a bridge would do
today).

If there were a bridge between the source endnode and the first RBridge,

and that bridge is configured to
insert a VLAN tag, then that bridge would do exactly as it does today, 
and the first RBridge would
not add a VLAN tag, but would still add the shim and encapsulation
header.

In this way packets can transit any intermediate RBridge-RBridge link 
regardless of which VLAN the inner
packet is marked with. And I think that is the behavior that is wanted.

The RBridges have to ensure that a VLAN A packet is not delivered to an 
endnode on a link marked as not
allowing VLAN A traffic, but it's OK to transit such a link provided 
that endnodes don't see the packet (which
they wouldn't if it has the encapsulation header.
*******************

As for the other question...

 >Vishwas Manral wrote:

>>Besides is there a reason to not have a "type" field in the shim
header?

Not sure why that would be needed. What would you want to use that for?
The
type of the original packet is preserved already (with the original
frame, inside
the shim header).

Radia