Re: [RE] Background for stream addressing
Thanks David for your summary of the RE addressing discussion. My
comments (mostly for clarification) are as below <DC></DC> This is for
clarification purposes, so I can understand a comparison table later...
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).
<DC> So an audio stream coming out of a CE Ethernet interface has a
fixed UA1(interface MAC address), and originates frames with SA=UA1 and
DA=GA1 multicast address, to be obtained via a m-cast address server. An
audio stream front-left-speaker would use DA=GA1, whereas a
front-right-speaker would use DA=GA2</DC>
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.
<DC> So a CE Ethernet interface of UA1 MAC address originates frames
with SA=UA1, and DA = GA2, where 16 LSBS of GA2 identify a stream within
A1 interface? If that is the case, the DA would contain info about the
source of the frame? That being the case, a front-left-speaker stream
would have DA=GA1, whereas a front-right-speaker stream would have
DA=GA2, the difference being in the 16 LSBS, which uniquely identify
which is which.</DC>
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.
<DC> A CE Ethernet interface of address UA1 originates frames with
SA=UA1 and DA=GA2, with a specific priority included in the VLAN tag
vtag=P. Listeners would filter DA=GA2 only, but would not be able to
identify within UA1 which stream that frame belongs to. So a
front-left-speaker stream and front-right-speaker stream would both have
frames with DA=GA2.</DC>
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.
<DC> A CE Ethernet interface of address UA1 originates frames with
SA=UA1 and DA=GA2, with a specific VLAN tag vtag=VT3. Listeners to such
stream would filter (DA=GA2 + vtag=VT3) frames, but would be able to
identify the source of the frame via (UA1 + VT3) address/tag. So, a
front-left-speaker wound have DA=GA2 + vtag=VT2, whereas a
front-right-speaker would have DA=GA2 + vtag=VT3 (with the caviat that
both VT2 and VT3 have same priority bit encoding in the speakers'
case).</DC>
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.
<DC> A CE Ethernet interface of address UA1 originates frames with
SA=UA1 and DA=GA for all streams originated by that interface (e.g.,
audio front-left, video, etc). All listeners to any of the streams
generated by UA1 need to filter DA=GA, and sort out which frames belong
to each stream. A front-left-speaker and front-right speaker would both
have DA=GA.</DC>
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@ieee.org [mailto:owner-stds-802-3-re@ieee.org]
On Behalf Of David V James
Sent: Thursday, July 28, 2005 5:49 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: [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