Internet Engineering Task Force C. Gunther, Ed.
Internet-Draft HARMAN
Intended status: Informational March 4, 2015
Expires: September 5, 2015
Deterministic Networking Professional Audio Requirements
draft-gunther-detnet-proaudio-req-00
Abstract
This draft documents the needs in the Professional Audio industry to
establish multi-hop paths and optional redundant paths for
characterized flows with deterministic properties.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gunther Expires September 5, 2015 [Page 1]
Internet-Draft DetNet Pro Audio requirements March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Stream Characteristics . . . . . . . . . . . . . . . . . . . 3
3.1. Emergency Notifications . . . . . . . . . . . . . . . . . 3
3.2. Content Protection . . . . . . . . . . . . . . . . . . . 4
3.3. Multiple Sinks . . . . . . . . . . . . . . . . . . . . . 4
3.4. Super Stream = Two or More Serial Streams . . . . . . . . 4
3.5. Unused Reservations and Best-Effort Traffic . . . . . . . 5
3.6. Maximum and Acceptable Latency . . . . . . . . . . . . . 5
3.7. Latency Per Sink . . . . . . . . . . . . . . . . . . . . 6
3.8. Layer 3 Interconnecting Layer 2 Islands . . . . . . . . . 6
3.9. Link Aggregation . . . . . . . . . . . . . . . . . . . . 6
3.10. Layer 3 Multicast . . . . . . . . . . . . . . . . . . . . 6
3.11. Segregate Traffic . . . . . . . . . . . . . . . . . . . . 7
3.12. Elapsed Time to Build a Reservation . . . . . . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Singularity of IT and AV Networks . . . . . . . . . . . . 7
4.2. Combining Local and Remote Content . . . . . . . . . . . 8
4.3. Lots of Small Devices . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. Content Protection . . . . . . . . . . . . . . . . . . . 9
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
7.3. Control Protocols . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Professional Audio (Pro-A) includes the simple and small network used
by a garage band which may contain a handful of devices, as well as
the large theme park spread across 25,000 acres or more. It is worth
noting that these theme parks may exist on multiple continents and
share content around the world.
Some examples of Pro-A networks include:
o Garage bands
o Portable PA
o Churches
Gunther Expires September 5, 2015 [Page 2]
Internet-Draft DetNet Pro Audio requirements March 2015
o Concert halls
o Recording and broadcasting studios
o Cinema and theater sound
o Train stations
o Stadiums
o Airports
While many of these uses have common requirements there are some
unique usage models that will be highlighted in this document.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Stream Characteristics
All streams of interest to the Pro-A world have the same requirements
related to establishing a path and allocating bandwidth as any other
type of network application. This section of the draft is meant to
introduce other concerns associated with streams in a Pro-A network.
3.1. Emergency Notifications
Audio systems installed in public environments have unique
requirements with regards to health, safety and fire concerns. For
example [ISO7240-16] subjects equipment to tests that can simulate an
emergency situation. The purpose of this section is to provide a
very basic set of requirements that an underlying network must
provide if it is to be used in public areas. It would be
advantageous to establish a liaison with the International Standards
Organization (ISO) so that the referenced ISO 7240 standards could be
made available for Deterministic Networking (DetNet) review for the
specific details.
The remainder of this section is simply a synopsis of some of the
requirements found in the ISO 7240 standard. The wording in that
standard supersedes anything specified in this section and it should
be referenced for the specific requirements.
Gunther Expires September 5, 2015 [Page 3]
Internet-Draft DetNet Pro Audio requirements March 2015
Any numbers in this section surrounded by braces refers to the
specific section within ISO 7240-16:2007 (for example {7.1.1} is a
reference to section 7.1.1).
One such requirement is a maximum of 3 seconds {7.1.1} for a system
to respond to an emergency detection and begin sending appropriate
warning signals and alarms. When these conditions occur the audio
system must be able to disable normal functions {7.1.4} not
associated with emergency functionality, without the need for human
intervention.
Announcements must be able to be made within 20 seconds of a system
reset {7.9.2.2}.
In the event of equipment failure the backup equipment must be able
to take over within 10 seconds {14.4.1}. This would include detection
time, new path configuration, etc.
3.2. Content Protection
Digital Rights Management (DRM) is very important to the Pro-A and
Professional Video industries. Any time that protected content is
introduced into a network there are DRM concerns that must be
maintained. (See [CONTENT_PROTECTION]).
As an example, two techniques are Digital Transmission Content
Protection (DTCP) and High-Bandwidth Digital Content Protection
(HDCP). HDCP content is not approved for retransmission within any
other type of DRM, while DTCP may be retransmitted under HDCP.
Therefore if the source of a stream is outside of the network and it
uses HDCP protection it is only allowed to be placed on the network
with that same HDCP protection.
3.3. Multiple Sinks
Pro Audio systems often have multiple sinks (e.g.: speakers)
connected to a single source. In order to keep bandwidth utilization
of shared links to a minimum multicast addressing is commonly used.
3.4. Super Stream = Two or More Serial Streams
Audio content delivered from a source (e.g.: microphone or guitar)
can be sent through one or more stages of processing before it
reaches the sink(s). For example, one stream may be used to send
audio from a microphone hub to a digital processor that will match
the singers pitch to that of a guitar. A second stream will then
take that processed audio to a mixing console. A third stream is
then required to move the mixed audio to an amplified speaker. Not
Gunther Expires September 5, 2015 [Page 4]
Internet-Draft DetNet Pro Audio requirements March 2015
only does this one super "stream" require three physical streams to
be created, but the overall latency of all three streams plus the
digital processing at each hop must not exceed 10-15 msec. See slide
6 of [SRP_LATENCY].
3.5. Unused Reservations and Best-Effort Traffic
Often times reservations are created, but not used until some time
later in a live show. This is really more of a comfort issue for the
show's producers; they just want to know that there is no reason an
important reservation's request could be refused during a live
performance.
In other situations a single reservation may be used for different
content at different times throughout the day. It is convenient to
create a single reservation that is large enough for the biggest
bandwidth consumer although that could be wasteful on smaller
streams.
In both these cases it is advantageous for other best-effort traffic
to be able to use that unused bandwidth so that the full bandwidth of
the network can be utilized at all times. This best-effort traffic
could consist of "meter data" which helps an operator understand what
is going on at the other end of Pro-A system in an amusement park.
Or it could be used for file transfers or venue updates. Regardless
of the reason, Pro-A installations will want to be able to use any
reserved bandwidth that is unused.
3.6. Maximum and Acceptable Latency
In order to synchronize speakers throughout a venue it is critical
for each sink (amplified speaker) to know what the maximum latency is
it can expect to see from the network. That maximum latency from
each sink is sent back to the source, or an associated Controller, so
the presentation time of the Pro-A audio data samples can be set. In
addition, sinks that are fewer hops away from the source will know
how much memory they will need to provide in order to buffer the
content that will be presented at some later time.
A Controller may also collect the various maximum latency numbers and
decide to exclude the sinks that are too many hops away since they
will place unrealistic buffering requirements on the sinks that are
very few hops from the source.
Additionally, sinks that are closer to the source can inform the
network that they can accept more latency than the network is
currently offering since they will be buffering packets to match
play-out time of father away sinks. This acceptable latency can be
Gunther Expires September 5, 2015 [Page 5]
Internet-Draft DetNet Pro Audio requirements March 2015
used by the network to move a reservation on a short path to a longer
path in order to free up bandwidth for other critical streams on that
short path. See slides 3-5 of [SRP_LATENCY].
3.7. Latency Per Sink
As previously mentioned a single stream may be sent to multiple
sinks. This use case introduces the concept of more stringent
latency requirements for some sinks, whereas other sinks have more
flexible latency requirements. A live outdoor concert has stringent
requirements for delivering the audio to the speaker systems, yet can
have very flexible requirements for that same audio content that is
delivered to a mobile recording studio that is set up nearby. See
slide 7 of [SRP_LATENCY].
3.8. Layer 3 Interconnecting Layer 2 Islands
The DetNet solution for Layer 3 networks should support Layer 3
segments that can connect to Layer 2 networks that do not support
Layer 3 protocols.
3.9. Link Aggregation
If any type of link aggregation is proposed as part of the DetNet
solution there must be a technique used that can determine the
maximum latency that a packet may experience when flowing across any
links in that aggregation.
Or, an alternative could be to report the maximum latency of a single
link within the link aggregation and then enforce that the stream
will only use that link when establishing the path.
3.10. Layer 3 Multicast
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.
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. Optionally it could be stated that
Deterministic Networking will recommend the use of IPv6, although the
impact of such a decision upon existing IPv4 installations should be
discussed.
Gunther Expires September 5, 2015 [Page 6]
Internet-Draft DetNet Pro Audio requirements March 2015
3.11. Segregate Traffic
Sink devices may have 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. Packet forwarding
rules should eliminate extraneous streaming traffic from reaching
these devices; however there may be other types of broadcast traffic
that should be eliminated where possible. This is often done by
VLANs or IP subnets.
3.12. Elapsed Time to Build a Reservation
During a venue change in a show various modifications to reservations
may be required. Some existing reservation may be torn down and
other reservations may be established. On the Pro-A side this may be
a simple reconfiguration of the speakers so the sound field can be
created in a different way, or inclusion or exclusion of certain
areas in the physical environment.
When video is added to the mix this may be switching from one camera
to another. Currently video systems use expensive switching hardware
to switch inputs at the head-end of the final feed. Interest has
been expressed from the Broadcast industry to the IEEE AVB group for
using the network as the video switch (see [STUDIO_IP]).
There is also the issue of the time between power-on and
establishment of the first set of reservations. In many situations
the appropriate thing to do is simply reestablish all paths and
bandwidth reservations as were in place when the power was turned
off, doing this as quickly as possible. This is particularly true
when recovering from a power failure, or accidental removal of an
Ethernet cable or power cord.
4. Use Cases
4.1. Singularity of IT and AV Networks
A recent large installation of a Pro-A network based on IEEE 802.1
AVB technology encompassed a 194,000 sq ft, $125 million facility.
The network is capable of handling 46 Tbps of throughput with 60,000
simultaneous signals. Inside the facility are 1,100 miles of fiber
feeding four audio control rooms. Phase I of this project was for
audio, the next phase will include video as well. One of the future
goals of this project is to have the capability to integrate IT
infrastructure with the audio streaming technology. Details of this
installation can be found here [ESPN_DC2].
Gunther Expires September 5, 2015 [Page 7]
Internet-Draft DetNet Pro Audio requirements March 2015
4.2. Combining Local and Remote Content
One advantage of a guaranteed reservation with a small bounded
latency is the reduced buffering requirements on sink devices. As
mentioned earlier there are large theme parks, megachurches, and
other venues that wish to broadcast a live event from one physical
location to another physical location. These may be across town or
across the globe and the content would be delivered via a layer 3
protocol. Depending on the technology available, latency bounds and
jitter caused by Internet delivery of content can have a huge impact
on the buffering requirements at the receiving site.
In these situations it is acceptable at the local location for
content from the live remote site to be delayed (buffered) a
reasonable amount to allow for a statistically acceptable amount of
latency in order to reduce jitter. However, once the content begins
playing in the local location any audio artifacts caused by the local
network are unacceptable, especially in those situation where a live
local performer is "mixed" into the feed from the remote location.
With these scenarios a single gateway device at the local network
that is receiving the feed from the remote site would provide the
expensive buffering required to mask the latency and jitter issues
associated with long distance delivery. Sink devices in the local
location would have no additional buffering requirements, and thus no
additional costs, beyond those required for delivery of local
content. The sink device would be receiving the identical packets as
those sent by the source and would be unaware that there were any
latency or jitter issues along the path.
4.3. Lots of Small Devices
Consumers expect more and more from their theater experiences. One
example is the use of individual theater seat speakers and effects
systems. In order to be cost effective these systems must be
inexpensive per seat since the quantities in a single theater can
reach hundreds or thousands of seats.
Discovery protocols alone in a one thousand seat theater can generate
a lot of broadcast traffic that can put an unnecessary load on a low
powered CPU. An installation like this will require some type of
traffic segregation that can create groups of seats to reduce traffic
within that group. All seats in the theater must still be able to
communicate with a central controller.
Gunther Expires September 5, 2015 [Page 8]
Internet-Draft DetNet Pro Audio requirements March 2015
5. Acknowledgements
The editor would like to acknowledge the help of the following
individuals and the companies they represent:
Jeff Koftinoff, Meyer Sound
Jouni Korhonen, Associate Technical Director, Broadcom
Pascal Thubert, CTAO, Cisco
Kieran Tyrrell, Sienda New Media Technologies GmbH
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
7.1. Content Protection
As mentioned earlier any solutions that would be recommended for the
Professional A/V space must support DRM.
7.2. Denial of Service
Many industries that are moving from the analog wire world to the
digital network world have little understanding of the pitfalls that
they can create for themselves by an improperly installed system.
DetNet should consider ways to provide security against DoS attacks
in solutions directed at these markets.
One example this author is aware of involved the use of technology
that allows a presenter to "throw" the content from their tablet or
smart phone onto the A/V system that is then viewed by all those in
attendance. The facility introducing this technology was quite
excited to allow such modern flexibility to those who came to speak.
One thing they hadn't realized was that since no security was put in
place around this technology it left a hole in the system that
allowed other attendees to "throw" their own content onto the A/V
system.
7.3. Control Protocols
Pro-A systems can include amplifiers that are capable of generating
several hundreds or thousands of watts of audio power. If used
incorrectly these systems can cause hearing damage to those in the
vicinity of the speaker arrays. The traffic that controls these
Gunther Expires September 5, 2015 [Page 9]
Internet-Draft DetNet Pro Audio requirements March 2015
devices must be protected and that is mostly a concern of those
providing that service. However, the configuration protocols that
create the network paths used by the Pro-A traffic should be
protected as well so that high-volume content cannot be sent to areas
that are not meant to receive it.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[CONTENT_PROTECTION]
Olsen, D., "1722a Content Protection", 2012,
<http://grouper.ieee.org/groups/1722/contributions/2012/
avtp_dolsen_1722a_content_protection.pdf>.
[ESPN_DC2]
Daley, D., "ESPN's DC2 Scales AVB Large", 2014,
<http://sportsvideo.org/main/blog/2014/06/
espns-dc2-scales-avb-large>.
[ISO7240-16]
ISO, "ISO 7240-16:2007 Fire detection and alarm systems --
Part 16: Sound system control and indicating equipment",
2007, <http://www.iso.org/iso/
catalogue_detail.htm?csnumber=42978>.
[SRP_LATENCY]
Gunther, C., "Specifying SRP Latency", 2014,
<http://www.ieee802.org/1/files/public/docs2014/
cc-cgunther-acceptable-latency-0314-v01.pdf>.
[STUDIO_IP]
Mace, G., "IP Networked Studio Infrastructure for
Synchronized & Real-Time Multimedia Transmissions", 2007,
<http://www.ieee802.org/1/files/public/docs2047/
avb-mace-ip-networked-studio-infrastructure-0107.pdf>.
Author's Address
Gunther Expires September 5, 2015 [Page 10]
Internet-Draft DetNet Pro Audio requirements March 2015
Craig Gunther (editor)
Harman International
10653 South River Front Parkway
South Jordan, UT 84095
USA
Phone: +1 801 568-7675
Email: craig.gunther@harman.com
URI: http://www.harman.com
Gunther Expires September 5, 2015 [Page 11]