Internet DRAFT - draft-williams-avtext-avbsync
draft-williams-avtext-avbsync
Audio/Video Transport Extensions A. Williams
Internet-Draft Audinate
Intended status: Standards Track October 31, 2011
Expires: May 3, 2012
IEEE 1588/802.1AS Synchronisation for RTP Streams
draft-williams-avtext-avbsync-02
Abstract
This memo specificies an RTP header extension for carrying in-band
synchronization metadata provided by the IEEE1588/802.1AS Precision
Time Protocols.
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 [1].
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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 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
Williams Expires May 3, 2012 [Page 1]
Internet-Draft AVB/RTP Synchronisation October 2011
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.
Table of Contents
1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Clocks and Clock Domains . . . . . . . . . . . . . . 4
4. Timestamp formats . . . . . . . . . . . . . . . . . . . . . . 5
5. IEEE 1733 / AVB RTCP Packet Type . . . . . . . . . . . . . . . 5
5.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. RTCP Packet Subtypes . . . . . . . . . . . . . . . . . . . 7
6. Timing Header Extension . . . . . . . . . . . . . . . . . . . 8
7. SDP signalling . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Clock domain . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Quality of Service . . . . . . . . . . . . . . . . . . . . 11
8. An Alternative Approach . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Williams Expires May 3, 2012 [Page 2]
Internet-Draft AVB/RTP Synchronisation October 2011
1. Outline
Alternative approach
Use existing header extension for timestamps. (RFC 6051)
Create additional small header extension for metadata (traceability,
uncertainty, media clock discontinuity).
IDMS wants accurate timing too and has a method for describing
clocks. Create a single specification for signalling clock domains
which covers both use cases. IDMS can use that too.
2. Introduction
Synchronisation between RTP flows and between devices rendering RTP
flows is currently facilitated by means of NTP format timestamps
taken with respect to a shared reference clock. In many applications
(e.g. professional, commercial and automotive AV), the NTP clock
synchronisation protocol does not meet the necessary time alignment
and synchronisation speed requirements.
Like NTP, the IEEE1588 Precision Time Protocol (PTP) family of clock
synchronisation protocols provide a shared reference clock in an
network - typically a LAN. IEEE1588 provides sub-microsecond
synchronisation between devices on a LAN and typically locks within
seconds at startup rather than minutes. With support from Ethernet
switches, IEEE1588 protocols can achieve nanosecond timing accuracy
in LANs. Network interface chips and cards supporting hardware time-
stamping of timing critical protocol messages are also available.
When using IEEE1588 clock synchronisation, networked AV systems can
achieve sub 1 microsecond time alignment accuracy when rendering AV
signals and can support latencies less than 1ms through a gigabit
LAN.
Three flavours of IEEE1588 are in use today:
o IEEE 1588-2002 [4]: the original "Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems". This is often called IEEE1588v1 or PTPv1.
o IEEE 1588-2008 [5]: the second version of the "Standard for a
Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems". This is a revised version of the original
IEEE1588-2002 standard and is often called IEEE1588v2 or PTPv2.
Williams Expires May 3, 2012 [Page 3]
Internet-Draft AVB/RTP Synchronisation October 2011
o IEEE 802.1AS [6]: "Timing and Synchronization for Time Sensitive
Applications in Bridged Local Area Networks". This is a Layer-2
only profile of IEEE 1588-2008 for use in Audio/Video Bridged
LANs.
By using an IEEE 1588 derived reference clock, synchronisation of RTP
streams and devices in LANs can be considerably improved.
3. Reference Clocks and Clock Domains
RTP uses NTP format timestamps to exchange information about media
clock timing. NTP timestamps may come from a clock which is
synchronised to a global time reference, but this is not assumed nor
is there a standardised mechanism available to indicate that
timestamps are derived from a common reference clock. Therefore, RTP
implementations typically assume that NTP timestamps are taken using
unsynchronised clocks and must compensate for absolute time
differences and rate differences. Without a shared reference clock,
RTP can time align flows from the same source at a given receiver
using relative timing, however tight synchronisation between two or
more different receivers (possibly with different network paths) or
between two or more senders is not possible.
Each IEEE1588 clock is identified by a globally unique EUI-64 called
a "ClockIdentity". A slave clock using one of the IEEE1588 family of
network time protocols acquires the ClockIdentity/EUI-64 of the
grandmaster clock that is the ultimate source of timing information.
A master clock which is itself slaved to another master clock passes
the grand master clock identity through to its slaves. The
grandmaster clock identity can be used to identify a set of clocks in
a single clock domain.
The IEEE1588 protocol family also carries an indication that the
grand master clock provides traceable time. Traceablility of a time
source implies that the clock is ultimately slaved to a global time
source (e.g. GPS). A slave may consider one or more grandmaster
clocks providing traceable time as belonging to the same (global)
clock domain. Informally, traceabiliity trumps ClockIdentity when
comparing clock domains. Traceable time is particularly applicable
for wide area applications such as broadcast, transport and
reflection seismology.
Several instances of the IEEE1588v1/v2 protocol may operate
independently on a single network, forming distinct PTP network
protocol domains each of which may have a different master clock. As
the IEEE1588 standards have developed, the definition of PTP domains
has changed. IEEE1588v1 identifies protocol subdomains by a textual
Williams Expires May 3, 2012 [Page 4]
Internet-Draft AVB/RTP Synchronisation October 2011
name and IEEE1588v2 identifies protocol domains using a numeric
domain number. 802.1AS is a Layer2 profile of IEEE1588v2 supporting a
single numeric clock domain (0). This specification assumes that an
IEEE1588 clock master for multiple domains will provide the same
timing information to all domains or that each clock domain has a
different master. In other words, this specification assumes that a
timing domain can be uniquely identified using the ClockIdentity of
the grandmaster clock alone.
Accurate signal playout time alignment and accurate capture of input
signal phase relationships are important requirements for A/V
systems. In distributed AV systems containing many senders/receivers
and differing network path lengths, a shared reference clock
providing absolute time is needed. Relative timing using
unsychronised clocks cannot provide the required level of time
alignment (+/- 1us).
4. Timestamp formats
IEEE 1588/802.1AS timestamps use International Atomic Time (TAI)
rather than UTC. Timestamps are 80 bits in total, divided into two
parts:
PTP_sec: 48 bits seconds since epoch
PTP_nsec: 32 bits nanoseconds
A shorter 32 bit timestamp has also been defined for use in streaming
media protocols in the following way:
as_timestamp = (PTP_sec * 10^9 + PTP_nsec) modulo 2^32
The shorter as_timestamp field covers a time interval slightly larger
than 4 seconds.
5. IEEE 1733 / AVB RTCP Packet Type
IEEE 1733 [7] defines the "AVB RTCP packet" type reproduced in
Figure 1. RTCP AVB packets contain a mapping between RTP timestamp
and an 802.1AS timestamp as well as additional clock and QoS
information.
The RTCP packet type shown below provides the corresponding IEEE1588
timestamp for an RTP timestamp in a similar fashion to an RTCP Sender
Report (SR). In addition, the source of the timing information (i.e.
the grandmaster ClockIdentity) is included. Clock domain information
Williams Expires May 3, 2012 [Page 5]
Internet-Draft AVB/RTP Synchronisation October 2011
allows an RTP implementation to determine whether sender and receiver
timestamps have been taken using a shared reference clock. If the
sender and receiver share a common clock domain, timestamps and be
used and compared in an absolute sense.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|subtype=0| PT=208 | length=9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| gmTimeBaseIndicator | gmPortNumber |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C
| |P
+ gmClockIdentity (EUI-64) +
| |A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V
| |B
+ stream_id (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| as_timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rtp_timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IEEE 1733 / AVB RTCP packet format
A brief description of the major fields follows:
name Reserved, must be set to zero and ignored on reception.
gmTimeBaseIndicator This field identifies the clock master time
base. The gmTimeBaseIndicator increments each time a step change
in time or frequency occurs. If the value of the
gmTimeBaseIndicator and gmIdentity in the RTCP packet (i.e., of
the sender) match the gmTimeBaseIndicator and gmIdentity at the
receiver, the receiver is assured that timestamps have been taken
using a shared reference clock. If they do not match, actions
performed by the receiver are application dependent but may
include entering a holdover mode until a positive match is again
achieved.
Williams Expires May 3, 2012 [Page 6]
Internet-Draft AVB/RTP Synchronisation October 2011
gmPortNumber An integer identifying the port used on a grand master.
gmClockIdentity An EUI-64 identifying the grand master clock used by
the source to generate as_timestamps for this flow.
stream_id A 64 bit number identifying the 802.1Qat [8] QoS
reservation associated with this RTP flow.
as_timestamp The 32 bit 802.1AS timestamp (Section 4) associated
with the RTP timestamp carried in this packet.
rtp_timestamp The RTP timestamp of a media packet.
Please consult the IEEE 1733 specification [7] for more details.
5.1. Observations
The RTCP packet type above provides the basic information for linking
IEEE1588 time to RTP timestamps, however there are some additions
which would improve the functionality provided.
The IEEE1733 specifcation does not define any SDP signalling. This
means that the QoS parameters (ie the stream_id) cannot be signalled
at call/flow setup time using SIP/RTSP. Whilst IEEE1733 provides
clock domain information, it doesn't really define how clock domains
work. Further, IEEE1733 does not include metadata to indicate clock
changes. This specification addresses each of these issues.
5.2. RTCP Packet Subtypes
Systems not using the full AVB protocol suite can still benefit from
timing improvements offered by IEEE 1588v1 and IEEE 1588v2. In
general, the IEEE 1733 / AVB RTCP packet format (Figure 1) can be
used to relate RTP timestamp instants in media packets to a reference
clock provided by any of the IEEE 1588/PTP family of clock
synchronisation protocols.
The subtype field indicates which IEEE 1588 protocol was used by the
timestamping clock:
0x00 IEEE 802.1AS (defined by IEEE 1733)
0x01 IEEE 1588v1
0x02 IEEE 1588v2
Williams Expires May 3, 2012 [Page 7]
Internet-Draft AVB/RTP Synchronisation October 2011
6. Timing Header Extension
The header extension shown below provides a combination of media
timestamps and timing metadata.
The provision of IEEE1588 timestamps in the RTP header is analogous
to the existing NTP timestamp header extension supporting rapid
synchonisation of RTP flows. High performance systems often handle
RTP media packets in hardware and carriage of timing metadata in the
media packets provides increased performance (e.g. faster lock times)
and simplifies the system. In contrast to using RTCP, a header
extension guarantees that timing metadata arrives at the receiver
with the first media packet allowing them to be processed
immediately. This approach facilitates fast switching between
sources as is commonly used in zoned paging applications.
If the sender and receiver share a clock domain, source timestamps in
media packets facilitate the collection of high quality information
about the actual delays experienced by media packets through the
network. Accurate delay information is important for diagnosing
operational problems and for system optimisation.
The metadata included in the header allows senders to signal changes
in clock disposition to receivers. Since IEEE1588 uses an election
mechanism to determine the clock master it is possible for the master
and/or grand master to change during the transmission of an RTP flow.
Changing from one master clock to another may involve changes in
clock frequency and/or phase. Additionally, the election protocol is
not guaranteed to complete at the same time at all nodes in the clock
domain, so there will be a transition period during which timestamps
at the sender and receiver are not directly comparable. A sender
indicates changes in IEEE1588 clocking by setting the timestamp
uncertain (U) bit in the header. For example, the bit may be set
when the best master clock election process is triggered due to loss
of the current master clock. Once set, this bit should remain set
during the entire period where PTP timing is in flux and for at least
5 seconds after PTP timing has stabilised (5 seconds allows
as_timestamps which cover about 4 seconds to be disambiguated). When
PTP timestamps are uncertain the receiver may refrain from updating
the rtp_timestamp to wallclock mapping, effectively processing
packets on the basis of rtp_timestamp alone.
In AV systems, media clocks are often provided via an external
connection. When a media clock is disconnected or switched from one
source to another (e.g. between two different SP/DIF ports),
synchronisation may be lost and noise may be generated. A sender can
indicate the loss of a media clock for a transmitted signal by
toggling the media clock restart (M) bit. A receiver may use a
Williams Expires May 3, 2012 [Page 8]
Internet-Draft AVB/RTP Synchronisation October 2011
change in the media clock restart bit to mute audio or to hold a
frame or to trigger resynchronisation to the new media clock.
In some systems, senders and receivers are on different networks with
different grand master clocks however they may be part of a single
global clock domain that uses traceable time. A sender can indicate
that media packet timestamps have been taken with a traceable clock
by setting T=1. Since it is possible for a PTP clock master to
change during an RTP flow, the T bit may change. For example, if the
traceable grand master clock used by the sender fails, PTP will elect
a new grand master which may not be slaved to a global time source.
In systems where traceable time is important, all candidate PTP
masters should support traceable time and media signals timestamps
should be clearly marked as traceable or not traceable. If
timestamps are not traceable, T MUST be set to zero.
Figure 2 shows the fields of the AVB sync header extension. It uses
the standard RTP header extension mechanism defined in RFC 5285 [2].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID=7 | L=6 | subtype |T|M|U| reserved |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| as_timestamp |n
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Timestamp Header Extension
The fields are defined as follows:
T Bit field indicating traceable timestamps. If T=1, the timestamp
in this packet was taken by a clock slaved to a global time source
otherwise T MUST be set to zero.
Williams Expires May 3, 2012 [Page 9]
Internet-Draft AVB/RTP Synchronisation October 2011
M Toggling the value of the media clock restart field (M) indicates
a change in the source of the media clock. This kind of change
need not be seamless but allows the receiver to take any
appropriate action to minimize the disruption to the stream. The
value of the M bit is toggled once by the sender each time the
media clock source is changed. Toggling the bit rather than
setting/resetting ensures media clock restarts will not be missed
if it were to appear in a single RTP packet which happens to be
dropped.
U The sender sets U=1 to indicate that timestamps may not be
globally synchronized with network time. An example is the
invocation of the best master clock algorithm because of a PTP
SYNC timeout . Receivers may use the U bit, possibly in
conjunction with their knowledge of the status of the PTP clock,
to prevent unacceptable disturbances in the recovered media
streams.
subtype See Section 5.2.
as_timestamp A 32 bit IEEE 1588/802.1AS timestamp as defined in
Section 4.
reserved As this specification evolves, additional fields may be
included in this header.
The as_timestamp MUST correspond to the same instant as the RTP
timestamp in the packet's header, and MUST be derived from the same
clock used to generate the as_timestamps in the RTCP AVB packets.
Provided that it has knowledge of the SSRC to CNAME mapping, either
from prior receipt of an RTCP CNAME packet or via out of band
signalling such as RFC 5576 [3], the receiver can use the information
provided as input to the synchronization algorithm, in exactly the
same way as if an additional RTCP AVB packet had been received for
the flow.
7. SDP signalling
The Session Description Protocol (SDP) allows clock domain and QoS
information to be signalled via SIP or RTSP at call setup time. In
the case of SIP, changes in information can also be signalled during
the RTP session.
7.1. Clock domain
General format for signalling clock domains (todo: convert to EBNF):
Williams Expires May 3, 2012 [Page 10]
Internet-Draft AVB/RTP Synchronisation October 2011
a=clockdomain:ptp-version=PTP-PROTOCOL gmid=EUI-64 traceable=YES-OR-NO
Examples:
a=clockdomain:ptp-version=IEEE1588v1 gmid=39-A7-94-FF-FE-07-CB-D0 traceable=yes
a=clockdomain:ptp-version=IEEE1588v2 gmid=39-A7-94-FF-FE-07-CB-D0 traceable=yes
a=clockdomain:ptp-version=802.1AS gmid=39-A7-94-FF-FE-07-CB-D0 traceable=no
7.2. Quality of Service
General format for signalling AVB QoS to a receiver:
a=8021qat-qos:stream-id=EUI-64
Example:
a=8021qat-qos:stream-id=00-1D-C1-97-BB-3A-01-01
8. An Alternative Approach
Some RTP specifications already exists which cover aspects of the
functionality described in this specification. Most notably, there
is a specification for a header extension allowing NTP format
timestamps to be included in RTP media packet headers (RFC 6051).
In addition, some new work
(http://tools.ietf.org/html/draft-ietf-avtcore-idms-02) specifies a
mechanism for describing clock sources including those based on IEEE
1588.
Rather developing new specifications based on the 32 bit as_timestamp
format, an alternative approach which could fulfil the goals of this
specification could be to:
1. Use the existing RFC 6051 to carry timestamps in RTP media
packets (nothing to be done).
2. Create a new specification describing clock sources/domains and
their signalling that is independent of both this specification
and the IDMS specification. This would allow clock domains to be
signalled generally in RTP. This might be done in avtcore.
3. Create a new specification augmenting RFC 6051 which carries the
timing metadata (ptp uncertainty, media clock change,
Williams Expires May 3, 2012 [Page 11]
Internet-Draft AVB/RTP Synchronisation October 2011
traceability).
4. This specification: the header extension and clock domain
signally go into other documents. There may be some remaining
text describing how AVB systems in particular would use the above
mechanisms.
9. IANA Considerations
TBD: A URN will be required to signal the presence of this header
extension, such as:
urn:ietf:params:rtp-hdrext:avb-sync
10. Acknowledgements
The timing metadata (U and M) bits were inspired by the IEEE 1722
specification.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Singer, D. and H. Desineni, "A General Mechanism for RTP Header
Extensions", RFC 5285, July 2008.
[3] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media
Attributes in the Session Description Protocol (SDP)", RFC 5576,
June 2009.
11.2. Informative References
[4] Institute of Electrical and Electronics Engineers, "1588-2002 -
IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems", IEEE Std 1588-2002,
2002,
<http://standards.ieee.org/findstds/standard/1588-2002.html>.
[5] Institute of Electrical and Electronics Engineers, "1588-2008 -
IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems", IEEE Std 1588-2008,
2008,
Williams Expires May 3, 2012 [Page 12]
Internet-Draft AVB/RTP Synchronisation October 2011
<http://standards.ieee.org/findstds/standard/1588-2008.html>.
[6] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks - IEEE Draft
Standard for Local and Metropolitan Area Networks - Timing and
Synchronization for Time-Sensitive Applications in Bridged Local
Area Networks", IEEE Std 802.1AS-2011, 2011,
<http://standards.ieee.org/findstds/standard/802.1AS-2011.html>.
[7] Institute of Electrical and Electronics Engineers, "1733-2011 -
IEEE Standard for Layer 3 Transport Protocol for Time-Sensitive
Applications in Local Area Networks", IEEE Draft Std 1733/D7.0,
February 2011,
<http://standards.ieee.org/findstds/standard/1733-2011.html>.
[8] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks---Virtual
Bridged Local Area Networks Amendment 14: Stream Reservation
Protocol (SRP)", IEEE Std 802.1Qat-2010 (Revision of IEEE Std
802.1Q-2005), 2010, <http://standards.ieee.org/about/get/>.
Appendix A. An Appendix
Author's Address
Aidan Williams
Audinate
Level 1, 458 Wattle St
Ultimo, NSW 2007
Australia
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
Email: aidan.williams@audinate.com
Williams Expires May 3, 2012 [Page 13]
