Subject: [Detnet] DetNet Use Case Statements: Traffic Segregation (multicast to many devices)

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 7 Apr 2016 21:09:59 +0000

Statement:
Traffic Segregation (multicast to many devices)
Discussion:
This is from the Pro Audio use case. The Use Case draft text is included below. It looks to me like this is a use case that would benefit from being configured via a central controller rather than having to do discovery on all of the devices? The assumption is that this is a plug-and-play (e.g. AVB) network. So in implementations where we include the plug-and-play feature, would it also include "traffic segregation" capability?  Perhaps the techniques suggested below might be appropriate for this case?

                <section title="Traffic Segregation">
                    <t>Sink devices may be low cost devices with limited processing power. In order
                        to not overwhelm the CPUs in these devices it is important to limit the
                        amount of traffic that these devices must process.</t>
                    <t>As an example, consider the use of individual seat speakers in a cinema.
                        These speakers are typically required to be cost reduced since the
                        quantities in a single theater can reach hundreds of seats. Discovery
                        protocols alone in a one thousand seat theater can generate enough broadcast
                        traffic to overwhelm a low powered CPU. Thus an installation like this will
                        benefit greatly from some type of traffic segregation that can define groups
                        of seats to reduce traffic within each group. All seats in the theater must
                        still be able to communicate with a central controller.</t>
                    <t>There are many techniques that can be used to support this requirement
                        including (but not limited to) the following examples.</t>

                    <section title="Packet Forwarding Rules, VLANs and Subnets">
                        <t>Packet forwarding rules can be used to eliminate some extraneous
                            streaming traffic from reaching potentially low powered sink devices,
                            however there may be other types of broadcast traffic that should be
                            eliminated using other means for example VLANs or IP subnets.</t>
                    </section>

                    <section title="Multicast Addressing (IPv4 and IPv6)">
                        <t>Multicast addressing is commonly used to keep bandwidth utilization of
                            shared links to a minimum.</t>
                        <t>Because of the MAC Address forwarding nature of Layer 2 bridges it is
                            important that a multicast MAC address is only associated with one
                            stream. This will prevent reservations from forwarding packets from one
                            stream down a path that has no interested sinks simply because there is
                            another stream on that same path that shares the same multicast MAC
                            address.</t>
                        <t>Since each multicast MAC Address can represent 32 different IPv4
                            multicast addresses there must be a process put in place to make sure
                            this does not occur. Requiring use of IPv6 address can achieve this,
                            however due to their continued prevalence, solutions that are effective
                            for IPv4 installations are also required.</t>
                    </section>