One document matched: draft-williams-avtext-avbsync-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-williams-avtext-avbsync-02"
ipr="trust200902">
<front>
<title abbrev="AVB/RTP Synchronisation">IEEE 1588/802.1AS Synchronisation
for RTP Streams</title>
<author fullname="Aidan Williams" initials="A.M." surname="Williams">
<organization>Audinate</organization>
<address>
<postal>
<street>Level 1, 458 Wattle St</street>
<city>Ultimo</city>
<code>2007</code>
<region>NSW</region>
<country>Australia</country>
</postal>
<phone>+61 2 8090 1000</phone>
<facsimile>+61 2 8090 1001</facsimile>
<email>aidan.williams@audinate.com</email>
</address>
</author>
<date day="31" month="October" year="2011" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>Audio/Video Transport Extensions</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>This memo specificies an RTP header extension for carrying in-band
synchronization metadata provided by the IEEE1588/802.1AS Precision Time
Protocols.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Outline">
<t></t>
<t>Alternative approach</t>
<t> Use existing header extension for timestamps. (RFC 6051)</t>
<t> Create additional small header extension for metadata (traceability,
uncertainty, media clock discontinuity).</t>
<t> 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.</t>
</section>
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Three flavours of IEEE1588 are in use today:</t>
<t><list style="symbols">
<t><xref target="IEEE1588-2002">IEEE 1588-2002</xref>: the original
"Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems". This is often called
IEEE1588v1 or PTPv1.</t>
<t><xref target="IEEE1588-2008">IEEE 1588-2008</xref>: 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.</t>
<t><xref target="IEEE802.1AS-2011">IEEE 802.1AS</xref>: "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.</t>
</list>By using an IEEE 1588 derived reference clock, synchronisation
of RTP streams and devices in LANs can be considerably improved.</t>
</section>
<section title="Reference Clocks and Clock Domains">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 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.</t>
<t>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).</t>
</section>
<section anchor="timestamp_formats" title="Timestamp formats">
<t>IEEE 1588/802.1AS timestamps use International Atomic Time (TAI)
rather than UTC. Timestamps are 80 bits in total, divided into two
parts:</t>
<t><list style="empty">
<t>PTP_sec: 48 bits seconds since epoch</t>
<t>PTP_nsec: 32 bits nanoseconds</t>
</list></t>
<t>A shorter 32 bit timestamp has also been defined for use in streaming
media protocols in the following way:<list style="empty">
<t>as_timestamp = (PTP_sec * 10^9 + PTP_nsec) modulo 2^32</t>
</list></t>
<t>The shorter as_timestamp field covers a time interval slightly larger
than 4 seconds.</t>
</section>
<section anchor="IEEE1733_RTCP" title="IEEE 1733 / AVB RTCP Packet Type">
<t><xref target="IEEE1733">IEEE 1733</xref> defines the "AVB RTCP
packet" type reproduced in <xref target="fig_rtcp_avb"></xref>. RTCP AVB
packets contain a mapping between RTP timestamp and an 802.1AS timestamp
as well as additional clock and QoS information.</t>
<t>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 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.</t>
<t><figure align="center" anchor="fig_rtcp_avb"
title="IEEE 1733 / AVB RTCP packet format">
<preamble></preamble>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>A brief description of the major fields follows:</t>
<t><list style="hanging">
<t hangText="name">Reserved, must be set to zero and ignored on
reception.</t>
<t hangText="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.</t>
<t hangText="gmPortNumber">An integer identifying the port used on a
grand master.</t>
<t hangText="gmClockIdentity">An EUI-64 identifying the grand master
clock used by the source to generate as_timestamps for this
flow.</t>
<t hangText="stream_id">A 64 bit number identifying the <xref
target="IEEE802.1Qat-2010">802.1Qat</xref> QoS reservation
associated with this RTP flow.</t>
<t hangText="as_timestamp">The <xref target="timestamp_formats">32
bit 802.1AS timestamp</xref> associated with the RTP timestamp
carried in this packet.</t>
<t hangText="rtp_timestamp">The RTP timestamp of a media packet.</t>
</list>Please consult the <xref target="IEEE1733">IEEE 1733
specification</xref> for more details.</t>
<section title="Observations">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="rtcp_subtypes" title="RTCP Packet Subtypes">
<t>Systems not using the full AVB protocol suite can still benefit
from timing improvements offered by IEEE 1588v1 and IEEE 1588v2. In
general, the <xref target="fig_rtcp_avb">IEEE 1733 / AVB RTCP packet
format</xref> 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.</t>
<t>The subtype field indicates which IEEE 1588 protocol was used by
the timestamping clock:<list style="hanging">
<t hangText="0x00">IEEE 802.1AS (defined by IEEE 1733)</t>
<t hangText="0x01">IEEE 1588v1</t>
<t hangText="0x02">IEEE 1588v2</t>
</list></t>
</section>
</section>
<section title="Timing Header Extension">
<t>The header extension shown below provides a combination of media
timestamps and timing metadata.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 change in the
media clock restart bit to mute audio or to hold a frame or to trigger
resynchronisation to the new media clock.</t>
<t>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.</t>
<t><xref target="fig_1733_hdrext"></xref> shows the fields of the AVB
sync header extension. It uses the standard RTP header extension
mechanism defined in <xref target="RFC5285">RFC 5285</xref>.</t>
<figure align="center" anchor="fig_1733_hdrext"
title="Timestamp Header Extension">
<preamble></preamble>
<artwork><![CDATA[ 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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are defined as follows:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="subtype">See <xref target="rtcp_subtypes"></xref>.</t>
<t hangText="as_timestamp">A 32 bit IEEE 1588/802.1AS timestamp as
defined in <xref target="timestamp_formats"></xref>.</t>
<t hangText="reserved">As this specification evolves, additional
fields may be included in this header.</t>
</list>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 <xref target="RFC5576">RFC 5576</xref>, 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.</t>
</section>
<section title="SDP signalling">
<t>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.</t>
<section title="Clock domain">
<t>General format for signalling clock domains (todo: convert to
EBNF):</t>
<figure align="center">
<preamble></preamble>
<artwork><![CDATA[a=clockdomain:ptp-version=PTP-PROTOCOL gmid=EUI-64 traceable=YES-OR-NO
]]></artwork>
</figure>
<t>Examples:</t>
<figure align="center">
<artwork><![CDATA[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
]]></artwork>
</figure>
</section>
<section title="Quality of Service">
<t>General format for signalling AVB QoS to a receiver:</t>
<figure align="center">
<artwork><![CDATA[a=8021qat-qos:stream-id=EUI-64
]]></artwork>
</figure>
<t>Example:</t>
<figure align="center">
<artwork><![CDATA[a=8021qat-qos:stream-id=00-1D-C1-97-BB-3A-01-01
]]></artwork>
</figure>
</section>
</section>
<section title="An Alternative Approach">
<t>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).</t>
<t>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.</t>
<t>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:</t>
<t><list style="numbers">
<t>Use the existing RFC 6051 to carry timestamps in RTP media
packets (nothing to be done).</t>
<t>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.</t>
<t>Create a new specification augmenting RFC 6051 which carries the
timing metadata (ptp uncertainty, media clock change,
traceability).</t>
<t>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.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD: A URN will be required to signal the presence of this header
extension, such as:</t>
<t><list style="empty">
<t>urn:ietf:params:rtp-hdrext:avb-sync</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The timing metadata (U and M) bits were inspired by the IEEE 1722
specification.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5285"?>
<?rfc include="reference.RFC.5576"?>
</references>
<references title="Informative References">
<?rfc include="reference.IEEE.802.1Qat-2010"?>
<?rfc include='reference.IEEE.802.1AS-2011'?>
<reference anchor="IEEE1588-2002"
target="http://standards.ieee.org/findstds/standard/1588-2002.html">
<front>
<title>1588-2002 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2002" />
</front>
<seriesInfo name="" value="IEEE Std 1588-2002" />
</reference>
<reference anchor="IEEE1588-2008"
target="http://standards.ieee.org/findstds/standard/1588-2008.html">
<front>
<title>1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="" value="IEEE Std 1588-2008" />
</reference>
<reference anchor="IEEE1733"
target="http://standards.ieee.org/findstds/standard/1733-2011.html">
<front>
<title>1733-2011 - IEEE Standard for Layer 3 Transport Protocol for
Time-Sensitive Applications in Local Area Networks</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date month="February" year="2011" />
</front>
<seriesInfo name="" value="IEEE Draft Std 1733/D7.0" />
</reference>
</references>
<section title="An Appendix">
<t></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:53:22 |