=========================================================================
pfrantz@baynetworks.com
----------------------------------------

Notes on the Short Tag breakout session Thursday aftertnoon 1/25/96

The desire for short tags came from people with two different applications in
mind, so the discussions did not always lead in a consistent direction.  The
two application drivers were:

1. For cheap edge switches, it is desired to avoid the overhead associated
with two-level addressing, including the need for edge switches to maintain
remote DA to remote switch DA association tables.

2. For Gbps-rate core switches, the simplest possible silicon-friendly
lookup/forwarding engine is strongly desired.

Interoperability:  It was agreed that VLANs could span both short-tagged and
long-tagged trunks, with switches providing the tag translation.  There was
discussion of the value of making the short and long tags similar so as to
simplify translation.

A proposal originated by Martin McNealis was presented
on his behalf based on the (hopefully accurate) recollections of a couple of
people who had discussed it with him:

+-----------------+-----+-----------+-------------------
|   VLAN          |FLAGS|    VID    |     Original
|   MCAST         |     |           |     Frame . . .
+-----------------+-----+-----------+-------------------

         3           1        2

A VLAN OUI is obtained, so that the first three bytes
can look like the beginning of a VLAN-owned Mcast
address.
This approach only adds 6 bytes, provides a way to distinguish encapsulated
frames from ordinary frames
and potentially allows the same lookup engine which
handles 6-byte MAC address to be used to parse the
tag fields.  It has the advantage that itUs easier to add
data to one end of the frame than to insert it in the middle.  It assumes the
CRC would be recalculated.

Anil Rijsinghani presented an alternative which is to split
the original frame between the MAC SA and the Type/Length
field and insert a new ethertype value and a two-byte VLAN ID.
This has the advantages of minimal frame expansion, preservation of a valid
frame format and itUs conceptually
very simple.  The CRC would be recalculated.

The group then stepped back and created a Twish-listU of goals for the short
tag.  The list is not filtered - items on the list indicate somebody wanted
them, not that the group reached consensus on them:

1. Performance
  A. Network performance - implies a short tag
  B. Lookup engine performance - mechanical simplicity

2. Simplicity

3. Backwards-compatibility (with existing bridges and
   end-stations)

4. Interoperability with long tags

5. CRC-preservation and protection against VID corruption

6. Short forms should be created for all media types

7. Self-indentifying frames (untagged vs. short-tagged
    vs. long-tagged)

8. Support for cut-through switching.

9. Support for trunks and access links.

There was discussion but no agreement about whether the scope
of short-tagged applications could be restricted to
point-to-point inter-switch links (i.e. no hybrid links)
or to like-media applications (i.e. no translational bridging
or tunneling among ethernet, FDDI and TR)

Also discussed was whether optimizing for an efficient core switch is the
right tradeoff, given that edge switches outnumber core switches, and whether
a short tag would really turn out to be any  better than the current strawman
long-tag proposal from the core switchUs point of view.

John Wakerly proposed this:


+------------+-----------------------+-------------------
|   FLAGS &  |         CRC           |     Original
|   VID      |         FIXUP         |     Frame . . .
+------------+-----------------------+-------------------

         2               4

This has the advantages of minimal growth given CRC
preservation, and preserving the original frame
but it does not provide robust discrimination between
encapsulated and unencapsulated frames.
This may be acceptable on point-to-point links, although
it was mentioned that being able to receive both types
of frames can help deal with problems which can occur during transition
states while the network is being reconfigured.

CONTRIBUTIONS ARE SOLICITED FOR MARCH on the issues raised here, on the
question of whether having both short and long formats is worth the costs,
and on alternative short-tag proposals.  Additionally we need to figure out
whether the short-tag is aimed at cheap edge switches or fast core switches
as optimizing for both seems problematic.