Subject: [rbridge] Where do VLAN tags go in forwarded frames?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 3 Feb 2006 16:05:50 -0500

Radia, 

	Please see below...

--
Eric

--> 
--> How do RBridges know a packet is for a particular VLAN? 
-->

Without going into the details (most people won't really 
want to hear them, and those who might can find them in 
appropriate 802.## specifications), there is a code point
in the basic Ethernet/802.3 header to determine which (of
several) encapsulations applies to this frame.

If the code point indicates it is VLAN tagged, then the
forwarding device may look at the appropriate offset to
determine which VLAN this frame applies to.

-->
--> For originating frames, it would be the same as for bridges, 
--> i.e., sometimes the endnode fills it in, sometimes a bridge 
--> between the RBridge and the endnode fills it in, and sometimes 
--> the RBridge fills it in. (I assume bridges today are configured 
--> as to whether they should add VLAN tags for untagged packets
--> from a particular link?)
-->

There is a concept of "port-based" VLANs - in which the port
to VLAN information is (typically) configured.  If frames are
received on such a port, and the forwarding device determines
that they need to be forwarded on one or more ports that use
VLAN-tagged frames (to allow support of multiple VLANs on the
port), the receiving port-to-VLAN information is used to map
the frame encapsulation for a transmitting (forwarding) port.

This may done on a port by port basis, but it is typically the
case that a single VLAN is identified by a common tag on all
ports for any individual device (thus allowing for identical
VLAN-tagged encapsulation to be used).

Forwarding from port-based VLAN port to port-based VLAN port
(where both are mapped to the same VLAN context), or from 
VLAN-tagged port to VLAN-tagged port (where the mappings of
VLAN tag values are the same) - requires no special forwarding
or encapuslation activities.

--> 
--> However, for packets in transit between RBridges, is there any 
--> reason to duplicate the VLAN tag into the outer header? 
--> (review...the original frame is "inside", then there's a shim 
--> header with ingress/egress RBridge and TTL, and an "outer" 
--> Ethernet header with Ethertype "RBridge-forwarded frame".)
-->

This depends on whether this additional level of multiplexing
is required to support the number of potential encapsulations
required.

In the MPLS label encapsulated approach proposed at the last
meeting, this might not be required.  We could - for example 
- use different labels associated with the same egress to de-
multiplex different VLAN contexts.

Given that this would allow for intermediate RBridges to easily
distinguish forwarding on a VLAN basis, using a single field
look-up, this might be highly desirable (and probably should be
considered, if it is not already).

Also it is not necessary that an outer VLAN tag mapping would 
be on a one-to-one basis with the innner VLAN tag in any case - 
unless this was desired in order to reduce requirements for 
configuration.

-->
--> It doesn't seem necessary for correctness, but it might be more 
--> convenient for RBridge forwarding (only for unknown destinations  
--> and multicasts) if they didn't need to look inside at the inner  
--> header to find out if the scope of delivery is just to a VLAN.
-->

It would be a matter of using one off-set verses another, as long 
as a two field look-up is required in any case.  The real issue is
whether or not it is appropriate to assume "correct" format using
well understood off-set values is guaranteed in RBridge forwarded
frames.  

As long as formatting is reasonably consistent (having a smallish 
number of possible, easily distinguishable, formats), it should not 
matter whether you look N bits into the frame or N+M bits into the 
frame to find a VLAN tag.

--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->