Conference netcad::hub_mgnt

The term "switching" has become one of the latest buzz-words when discussing
networks today.  As with most buzz-words, the definition of the term ends up
being different things to different people.  I will attempt to explain the 
various types of switching that vendors use and point out the "pros and cons" 
of each.

Cut-Through Switches:

This is a type of switching where the decision to forward a packet is typically
made PRIOR to the complete packet being received.  As soon as the source and
destination address is received (at the beginning or "header" of the packet), 
the cut-through switch makes the decision whether to forward and if the outbound
port is not busy, it starts forwarding the initial bytes of the not yet 
completely received packet.  If the outbound port is busy, the switch will
typically buffer the packet for a very short time thereby acting as a "store
and forward" type of device.

This cut-through technique will greatly reduce the "latency" or delay in 
forwarding a data packet from one LAN to another since it does not have to wait 
for the complete packet to be received before taking action.  Low latency is 
the major selling point made by vendors that support cut-through switching.

A major drawback of cut-through switching is that it propogates "bad" packets
throughout a network.  Since a packet starts to get forwarded onto the next
network prior to the complete receipt of the packet, it is impossible for the
switch to check the CRC validity of the packet.  Therefore packet fragments
(typically the result of collisions on Ethernets) and corrupted packets will
be forwarded by cut-through switches.

Another drawback of many cut-through switches is that they cannot be used to 
connect dissimilar LANs together.  There are Ethernet cut-through switches and 
FDDI cut-through switches but you must bridge or route between FDDI and Ethernet
because packet formats need to be translated from one LAN to another.  Pure 
cut-through switches can not do packet translation since a complete packet 
must be received BEFORE it can be translated.

Kalpana's EtherSwitches are examples of cut-through switches.


"Collision Window" Avoidance Switches:

This type of switching attempts to solve the problem of forwarding packet
fragments due to collisions on Ethernet that cut-through switches suffer from.
Basically these switches wait 511 bit times which is the window when a collision
can occur on Ethernet before forwarding the packet.  The decision can be made
in parallel to receiving but the actual forwarding does NOT occur until the 
collision window timer expires.  This technique solves the fragment problem but 
does increase the latency.  Since 511 bits is 64 bytes (the minimum size packet 
for Ethernet), the latency is basically the same as a bridge that is forwarding 
minimum size packets.  These products still suffer from the propogation of  
"bad" (CRC errors) packets throughout a network and have the same problems with
connecting dissimilar networks (Ethernet & FDDI)

ORNET's LANBooster products are an example of this type of switching.  


Buffered Switches:

Buffered switching is a new term that is now being used quite extensively by
many vendors.  Buffered switches completely receive a packet prior to making
the forwarding decision - they do packet switching.  If you believe that this 
sounds very similar to bridging, you are correct!  Basically buffered switches 
are bridges that do not necessarily adhere to the standards for bridging.  

Buffered switches address some of the disadvantages that pure switches have.  
They do not propogate back packets or fragments and can connect dissimilar LANs 
together since they completely receive the whole packet before forwarding.

Buffered switches do have some drawbacks in that they have higher latencies 
than cut-through switches and they typically do not support bridging standards
such as the IEEE 802.1d Spanning Tree Standard which allows bridges to be
placed in parallel thereby increasing the redundancy and reliability of the
overall network.

NPI's EIFO or SMC's Elite SwitchingHub are examples of buffered switches.


Bridging Switches:

Bridges have all the same advantages that buffered switches have.  They do not 
propogate back packets or fragments and can connect dissimilar LANs together 
since they completely receive the whole packet before forwarding.  True bridges
also support the necessary IEEE standards for bridging (IEEE 802.1d Spanning
Tree, IEEE 802.1i FDDI supplement and the IEEE 802.1h Ethernet V2.0 MAC Bridging
standards).  These standards assure that bridges can be placed in parallel,
FDDI to IEEE 802 LAN bridging is done correctly and FDDI to Ethernet V2.0
bridging is done correctly.

Bridges do have the drawback of higher latencies than cut-through switches but
are typically identical to buffered switches.  The term "bridge" may not be
the term that is most currently in vogue but it is the most reliable and most
redundant way to accomplish "switching".

The DECbridge 900MX is a good example of a standards-compliant bridging switch.

The DECbridge 900MX is a full "wire-speed" bridge between ANY of the Ethernet
ports.  This means that 10 Mb worth of minimum-size packets be forwarded between
Ethernets.  Three Ethernets can be blasting 10 Mb to the other three Ethernets
simultaneously (in other words Ethernet to Ethernet traffic is supported at
45,000 packets per second - the maximum rate with minimum size packets!)  The
DECbridge 900MX can translate between FDDI and Ethernet packets at a rate of
62,500 packets per second.  This means that communication between FDDI and
Ethernet can occur at 10 Mb rates per Ethernet as long as the average packet
size is greater than 90 bytes.  Since the average packet size on Ethernets
today is typically 150 bytes or more, this means the DECbridge 900MX can
realistically support 6 Ethernets to FDDI at full 10 Mb rates.

Hope this helped answer some of your questions/concerns.

    From an external point of view, most people equate switches with the
    following properties:
    
    - large number of ports (=> significantly greater than 2)
    - relatively low cost per port
    - high throughput
    - low latency
    
    The DB900MX has all of the above, and can be referred to as a switch -
    a bridging switch as Karl puts it, with a lot more features than a
    typical switch.  Indeed, it was suggested by an external consultant that
    we change the name to something with "switch" in it.  There have also
    been some negative connotations attributed to them after it was found that
    cut-through switches don't comply to Ethernet spec (collision windows),
    as well as forward bad packets.
    
    Anil

    Thanks very much for the information.
    
    Regards Ole.

>> This cut-through technique will greatly reduce the "latency" or delay in 
>> forwarding a data packet from one LAN to another since it does not have to wait 
>> for the complete packet to be received before taking action.  Low latency is 
>> the major selling point made by vendors that support cut-through switching.

    Latency, smatency but you tell the customer that.  When you really
    think about it, a cut-thru bridge is only one packet ahead of a store 
    and forward bridge.  Even in cut-thru mode you cannot send out a
    packet until the outbound port is free.  On a lightly loaded network 
    the cut-thru will forward the packet faster yes.  Each packet will
    come out from 51-1500 uS faster than a store and forward bridge.  But 
    the packet rate will be very close either way.
    
    Now load both down.  Chances are the cut-thru bridge will have to
    start buffering packets as the output ports will be busy sending
    packets.  As it has to buffer packets it now starts looking like
    a store and forward bridge in terms of latency.  Again packet rates
    should be roughly the same.  Unless you are a Kalpana switch.  Digital
    News and Review had an article about this cut-thru switch (bridge).
    In their tests they found as the network load increased and buffering
    started to occur, the switch started dropping packets.  Performance
    went down hill even more so as nodes started retransmitting packets
    that were dropped.

    Kalpana has sent out a letter to customers telling them about the
    benefits of forwarding bad packets.  Amazing piece of marketing.
    They tell you that if you confine all those bad packets to a segment
    or workgroup, rather than spread them around, you will not know
    there is a problem as it remains hidden.  Unless of course you waste
    all that time checking out each LAN regularily.  You leave your
    monitor on one segment happily knowing if an Ethernet card pukes,
    the bad packets will get out so the monitor will catch them.  The
    only thing they don't tell you is when something goes bad, how do
    you find the problem when each segment sees the same bad packets?
    Details, details.  When I get back to the office, I'll type it in.

    
>>  The DB900MX has all of the above, and can be referred to as a switch -
>>  a bridging switch as Karl puts it, with a lot more features than a
>>  typical switch.  Indeed, it was suggested by an external consultant that
>>  we change the name to something with "switch" in it.
    
    I used this tactic on a router bigot on a customer site.  He hates
    bridges with a passion but he loved the DB 900 as it would not forward 
    bad packets and it would move (switch) the packet only to the port(s) 
    that it was destined for and no others.
    
    Perception is reality.  8^)
    
    dave