Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RE] Background for stream addressing



Dirceu,

Yesterday you requested feedback on the motivations
for stream addressing. Here are a few thoughts that
might help.

I have CC'd this to the reflector, with the hope of
stimulating other comments and helpful suggestions.

For classA streams, the following requirements apply:

  1) Routing. Frames from the talker can reach one
     or more listeners.
  2) Distinct. The classA-stream frames have a distinct
     label that allows bridges to give them preferential
     treatment.

For classA streams, the following objectives apply
(no known alternative appears to meet all of these):
  3) Compact. Frames are small, so low-bandwidth traffic
     can also be efficient.
  4) Similar. Few changes to bridges are not required,
     in order to detect and/or route classA-stream frames.
  5) Simple. Any/all multicast addresses can be easily
     obtained from each station without necessitating
     a central or distributed multicast-address server.

Viable solutions include:
  a) DA-multicast.
     All classA-stream traffic has a multicast address.
     Bridges lookup the multicast address to determine
      its class, as well as forwarding decision.
     The multicast-DA is obtained from a central or
      distributed multicast address server (TBD).
  b) SA-multicast.
     All classA-streams use one of 64k multicast DAs,
      where the 16 LSBS identify the plugID and the SA
      specifies the address of the source.
     Bridges lookup the SA/plugID address to determine
      its class, as well as forwarding decision.
     No multicast address server is required.
  c) VLAN-priority.
     All classA-stream traffic has a multicast address
      and a VLAN tag.
     Bridges lookup the multicast address to determine
      only its forwarding decision.
     The vlanTag.priority identifies the frame's class.
     The meaning of the vlanTag.vlanID remains unchanged.
     (Please excuse my naming abuse above).

Nonviable solutions include:
  d) VLAN-routing.
     All classA-stream traffic has a single multicast
      address and a VLAN tag.
     Bridges use the vlalTag.vlanID to determine
      their forwarding decision.
     The vlanTag.priority identifies the frame's class.
     REJECTED: The use of vlanID would be overloaded and
      possibly conflict with established systems.
  e) Broadcast-routing.
     All classA-stream traffic has a single multicast
      address.
     Bridges use the SRP connectivity map to make their
      forwarding decision, so that all traffic goes to
      all listeners.
     REJECTED: Unnecessary broadcasts could swamp a system,
      since traffic is sent to all potential listeners.

A table of objective tradeoffs follows:

             a) DA-multicast     b) SA-multicast    c) VLAN-priority
3) Compact         good                good                poor
4) Similar         good                poor                best
5) Simple          poor                good                poor


Dirceu: Hope this helps!
Others: Any comments, questions, or other ideas?

DVJ