draft-fairman-rtp-61883
Internet Engineering Task Force A/V Transport Working Group
Internet Draft B. Fairman
Document: draft-fairman-rtp-61883-00.txt SONY-PTCA-NSA
Expires: November 2003 June 2003
RTP Payload Format for 1394/61883 Isochronous Streams
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This document describes a payload format for transporting IEC 61883-1[2]
(CIP) compliant IEEE1394 isochronous transport data using RTP. A 1394[3]
CIP isochronous transport may carry a stream format, such as DV[4],
AM824[5] or MPEG[6], that has been packetized for isochronous transport
by the source. The format is opaque to the transport mechanism. The
isochronous transport clock is derived from the 1394 cycle timer clock.
This protocol may be used to transport 1394 61883 streams between 1394
buses by IP, specifically Ethernet/IP.
Conventions used in this document
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[7].
Table of Contents
1. Introduction 3
1.1 Overview of 61883-1 Isochronous Transport 3
1.2 The 1394 Cycle Master, Cycle Timer and Bandwidth 4
1.3 Brief Description of 1394 Isochronous Traffic 5
1.4 Cycle time use by 61883-1 5
1.5 Missing Cycles, under-runs and over-runs 6
1.6 Maintaining Cycle timing across non-isochronous networks 6
1.7 All Participating endpoints are Isochronous 6
2. Structure of the RTP Packet 7
3. 61883-1 Isochronous Streams Packaging for RT 8
3.1 1394 Isochronous Packet 8
Fairman Expires - December 2003 page [1]
RTP Payload for 1394/61883 Isochronous Streams June 2003
4. Security Considerations 10
Acknowledgments 10
Author's Addresses 10
References 10
Fairman Expires - December 2003 page [2]
RTP Payload for 1394/61883 Isochronous Streams June 2003
1. Introduction
The ability to transport 61883-1 (CIP) isochronous streams, originated
on IEE1394 networks (buses), over IP networks is important for multi-
media applications centered around the consumer digital Audio/Video
space. There are some unique characteristics of 61883-1 that must be
addressed in order to use RTP as the transport protocol. The issue of
resource management (bandwidth, delay) to ensure temporal reliability is
not addressed.
This draft specifies an RTP[8] payload format for transporting 1394
transported 61883-1 isochronous data streams. Familiarity with 1394 and
61883-1 details is assumed.
The benefits of using RTP for 61883-1 isochronous stream transport
include:
i. Ability to deliver 61883-1 isochronous streams on distinct IEEE1394
buses.
ii. Typically, a number of 1394 isochronous interval's data can be
transmitted in one RTP packet (based on the MTU), improving the
efficiency of using an IP network.
iii. IP based applications can access 1394 isochronous streams by
implementing CIP processing of the RTP stream.
1.1 Overview of 61883-1 Isochronous Transport
The transport of IEC 61883-1 compliant isochronous data is based on an
isochronous clock at the source that is used to packetize application
streams (i.e., source packets) that are, in turn, based on their
applications' source clocks. The 61883-1 isochronous packets are called
data blocks. The sender application clocks are not inherently
synchronized to the isochronous clock. The receivers' isochronous clock
is synchronized with sender's isochronous clock (that is, on the same
bus with the same cycle master).The per isochronous cycle bit rate of
the isochronous packet transport is generally not constant. For the 1394
bus, bandwidth is allocated based on the maximum data rate and the
sender transmits truncated or null packets such that the average data
rate requirement of the application is met. Packets never exceed the
allocated bus bandwidth.
The isochronous nature of 61883-1 makes RTCP [8] unnecessary since the
data rate of the isochronous source may not be directly adjusted.
Application level protocols may accomplish this end, if needed.
Further, there is a 61883-1 defined connection control method called
Connection Management Procedures/Plug Control Registers (CMP/PCR). This
method allows an observer to determine the state of a particular
connection.
1.2 The 1394 Cycle Master, Cycle Timer and Bandwidth
The 1394 cycle master is the provider of the bus-wide clock on which
isochronism is based. The cycle master function is always operating on
an isochronous capable 1394 bus. The cycle master is selected by the
self-id process and is always the root (which controls arbitration). The
cycle timer value is written to all nodes by a broadcast write (cycle
start transaction) of the contents of the cycle master's cycle timer
Fairman Expires - December 2003 page [3]
RTP Payload for 1394/61883 Isochronous Streams June 2003
register when isochronous arbitration is successful. Isochronous
arbitration is initiated upon the cycle count incrementing in the cycle
master's cycle count. The bus cycle clock's period is nominally 125us
(8Khz). It is derived from the 24.576Mhz PHY clock (40.690 nsec
granularity) which increments the cycle timer. The tolerance of the
clock used to derive the master cycle clock is +/-100PPM. However, due
to the 1394 arbitration and bus occupancy mechanism, there is a maximum
delay of 78 usec[9]for the occurrence of a cycle start transaction. The
maximum delay for the recurrence of a particular stream (channel ID) is
185.5 usec - (channel's bandwidth in use). The cycle clock is used to
packetize the application generated source packets, such that the
bandwidth allocated for the application is never exceeded. The well-
defined maximum delay allows applications to have well defined and
limited buffering for 61883 streams.
Bandwidth is allocated as time on the bus, rather than data rate per
unit time. The IRM is responsible for managing the bandwidth available
register, from which bandwidth units are subtracted by nodes requiring
bandwidth. Bandwidth units are a time of 20 nsec (approximately). Each
cycle consists of 6144 bandwidth units, of which 4915 may be used for
isochronous traffic. 1 usec is about 49 bandwidth allocation units.
The 1394 specification states that the cycle timer 'never moves
backwards'. This does not account for bus resets that select a new cycle
master (e.g. joining 2 buses). In this case, there will likely be a
discontinuity in the cycle timer value. This discontinuity is not
relevant to the actual timing, as long as arbitrated bus resets are
used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycle sec | cycle count | cycle offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - 1394 Cycle Timer
cycle offset: counter incremented by PHY clock ticks with rollover at a
count of 3071 (125 usec with 40.69 nsec tick).
cycle count: counter incremented by cycle offset rollover with a
rollover at a count of 7999 (1 sec/8 KHz).
cycle sec: counter incremented by cycle count rollover with a rollover
at a count of 127 (128 sec).
As mentioned above, 1394 arbitration can introduce jitter to the start
time of an isochronous period (the time following the first isochronous
arbitration grant). This is accommodated by the cycle master
transmitting its cycle timer (which includes cycle offset) at the actual
transmission of the cycle start transaction.
1.3 Brief Description of 1394 Isochronous Traffic
An isochronous stream on 1394 is identified by the channel number
contained in its isochronous header. This is a unique identifier managed
by the Isochronous Resource Manager (IRM) function. It is possible for a
given program to occupy multiple channels. The channel number has
meaning only on the particular 1394 bus on which it is used. These
factors lead to a need to allow for multiple channels to be mapped into
a single RTP session. Briefly, for each isochronous cycle (nominally,
Fairman Expires - December 2003 page [4]
RTP Payload for 1394/61883 Isochronous Streams June 2003
125 usec), there are zero or one occurrences of data for a given
channel. The order in which channels occur in an isochronous cycle is
not guaranteed. Also, packets may be shorter than the maximum allowed by
the bandwidth allocated to the channel. It is possible for a node to
miss a cycle start to be "missed" if there is a transmission problem
with the cycle start packet. However, there may be nodes on the bus that
that successfully receive the cycle start. This can cause a situation
wherein isochronous traffic is observed without a node being in an
isochronous mode.
1.4 Cycle time use by 61883-1
The IEC 61883-1 specification for the two-quadlet CIP header defines two
uses of a value derived from the cycle timer: the SYT field and the
source packet header (SPH). The values in these fields are a function of
the cycle timer on the bus where the packets exist. These fields usually
relate to timing of the delivery of the ensuing data block to the
consuming application. These fields are absolute values tied to the
value of the cycle timer. The function which generates the value is tied
to the kind of data block being transported and typically is the
presentation time to the receiver application.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| SID | DBS |FN | QPC |S|RSV| DBC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0| FMT | FDF | SYT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Two-quadlet CIP header with SYT
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| SID | DBS |FN | QPC |S|RSV| DBC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1| FMT | FDF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Two-quadlet CIP header without SYT
The SYT field contains a value derived from the lower 16 bits of the
cycle timer. The SYT value derivation is from 4 bits of cycle count and
12 bits of cycle offset. The SYT field spans 16 cycles (approx. 2ms). It
is typically some absolute time in the future, cycle timer based. If
the S bit == 1 then the quadlet following the CIP header contains the
Source Packet Header (SPH) timestamp. The SPH consists of the lower 25
bits of the cycle counter and spans 8000 cycles (one second). It is
typically some absolute time in the future, cycle timer based.
Fairman Expires - December 2003 page [5]
RTP Payload for 1394/61883 Isochronous Streams June 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SPH Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Data Block
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Source packet header
1.5 Missing Cycles, under-runs and over-runs
The IEEE1394 bus has a very low error rate. That said, it is still
possible to have an error. For isochronous traffic, there is no
retransmission, so there should be a strategy implemented to allow for
recovery from missing cycle start packets or missing or corrupted data
packets.
1.6 Maintaining Cycle timing across non-isochronous networks
Cycle time is local to a IEEE1394 bus. It cannot be used by another
IEEE1394 bus directly. By communicating the absolute value of the local
cycle timer, the relative passage of time at the sender can be observed
at the receivers. It would also be possible to detect cycle timer
discontinuities at the transmitter. Any imbedded reference to absolute
cycle time is adjusted to relative offset by the transmitter (SPH, SYT)
to avoid dependence on the sender's cycle timer. The problem of
synchronizing distinct IEE1394 buses is not addressed here. 1.7 All
Participating endpoints are Isochronous
In RFC1257, the argument is made that bounded delay and guaranteed
bandwidth are the only requirements of the network transporting time
based data (streams), when the applications are isochronous. The need to
consider jitter is demonstrated to be unnecessary. When 61883-1
isochronous streams are transported by RTP, all participants are, by
definition, isochronous. Thus the protocols used to manage network
resources such that there is timely delivery (bounded maximum delay) of
transported isochronous streams is simplified because jitter is not a
problem.
The receivers will have to accommodate the maximum delay in the sense
that buffering is needed to accommodate the maximum delay. There is also
a minimum delay associated with the flow. Thus, it can be conceptualized
that the receivers will see an average jitter of .5(max delay - min
delay) in the clock implied by the rate of delivery of packets on the
non-isochronous transport.
Fairman Expires - December 2003 page [6]
RTP Payload for 1394/61883 Isochronous Streams June 2003
2. Structure of the RTP Packet
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|X| CC=1 |M| PT | sequence number | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | Hdr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifier |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | RTP
| 61883-1 isochronous streams(quadlet aligned) | Pay-
/ / load
. . .
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - An RTP packet for 61883-1 isochronous stream
Padding (P): 0
Extension (X) bit: the extension bit is set to zero.
CSRC count (CC): the CSRC count is set to 1.
Marker (M) bit: the marker bit is set to zero.
Synchronization source (SSRC): the high order 32 bits of the sources
EUI64.
Contributing source (CSRC: the low order 32 bits of the sources EUI64.
Payload Type (PT): the assignment of the RTP payload type for this
packet format is outside the scope of this document, and will not be
specified here. It is expected that the RTP profile for a particular
class of applications will assign a payload type for this encoding, or
if that is not done then a payload type in the dynamic range SHALL be
chosen by means of an out of band signaling protocol (e.g., UPnP, etc).
Sequence Number: incremented by the number of isochronous cycles in the
RTP data packet, starting, for security reasons, with a random initial
value.
Timestamp: The timestamp is the value of the isochronous cycle start
transaction corresponding to the receipt of the first isochronous packet
contained in the RTP packet.
61883-1 isochronous streams: the content of the isochronous channels for
this session. The format of this data is covered in the next section.
3. 61883-1 Isochronous Streams Packaging for RTP
3.1 1394 Isochronous Packet Below is a representation of a 1394
isochronous packet detailing the header fields. An isochronous period
may contain multiple packets, each occurring at most once for a channel.
Fairman Expires - December 2003 page [7]
RTP Payload for 1394/61883 Isochronous Streams June 2003
Thus a unit of information recorded for an isochronous cycle consists of
information about the cycle (cycle start) and information for each of
the desired channels. Typically, the CRCs are stripped by the 1394
interface.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394
| data length (bytes) |tag| channel |1 0 1 0| sy | hdr
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| header CRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| isochronous payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : zero padding as needed |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| data CRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 6 - 1394 Isochronous packet
Isochronous packets for 61883-1 use the tag field to indicate the
presence of CIP header quadlets. 00b means no CIP header while 01b means
CIP header quadlets are present.
Combining this information with cycle start information yields a record
for an isochronous cycle. Some of the fields are processed by the sender
to introduce a degree of independence from local conditions. Figure 7
represents the record for a particular cycle, containing at least the
cycle mark and ACC. The example shows that there may be more than one
61883-x stream captured per cycle.
Fairman Expires - December 2003 page [8]
RTP Payload for 1394/61883 Isochronous Streams June 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cycle
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 0 0 1 0 1 1 0 1 1 1 1 1 1| mark
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjusted Cycle Counter (ACC) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1394
| data length (bytes) |tag| xchannel0 |1 0 1 0| sy | hdr
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 61883-1 payload |
/ /
. . .
/ /
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| data length (bytes) |tag| xchannel1 |1 0 1 0| sy |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 61883-1 payload |
/ /
. . .
/ /
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| subsequent isochronous cycle packets |
/ /
. . .
/ /
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 7 - RTP Isochronous cycle record
Cycle mark: a constant value for synchronization purposes.
Adjusted cycle counter: this is the cycle counter that represents the
cycle containing the subsequent isochronous packets. It is derived from
the cycle start packet (unless it has to be derived from the local cycle
counter). The ACC cycle count (and the cycle seconds) is 0 for the first
cycle transmitted and is increased by one cycle per isochronous cycle.
The cycle offset is recorded as received in the cycle start packet. If a
missing cycle start causes synthesis of a cycle mark, the offset is
captured from the local cycle counter. xchanneln: the number mapped to
the received 1394 isochronous channel. It identifies the 1394 channel
assigned to the isochronous payload for transmission purposes. The
protocol for determining the mapping is beyond the scope of this
document.
tag: from the isochronous packet (00b or 01b).
sy: from the isochronous packet.
isochronous payload: from the packet.
Since the payload is by definition 61883-1 compliant, if the CIP headers
are present, then the SYT (if present) and SPH (if present) are adjusted
to relative values, based on the current cycle timer. This is
accomplished by subtracting the current cycle start cycle count/cycle
seconds value from the fields such that the cycle difference is the
result, preserving the cycle offset of the input SYT or SPH.
Fairman Expires - December 2003 page [9]
RTP Payload for 1394/61883 Isochronous Streams June 2003
4. Security Considerations
RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP
specification, and any appropriate RTP profile. This implies that
confidentiality of the media streams is achieved by encryption. Because
the data compression used with this payload format is applied to end-to-
end, encryption may be performed after compression so there is no
conflict between the two operations.
A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end computational
load. The attacker can inject pathological datagrams into the stream
which are complex to decode and cause the receiver to be overloaded.
However, this encoding does not exhibit any significant non-uniformity.
As with any IP-based protocol, in some circumstances a receiver may be
overloaded simply by the receipt of too many packets, either desired or
undesired. Network-layer authentication may be used to discard packets
from undesired sources, but the processing cost of the authentication
itself may be too high. In a multicast environment, pruning of specific
sources may be implemented in future versions of IGMP and in multicast
routing protocols to allow a receiver to select which sources are
allowed to reach it.
Acknowledgments
The author thanks Scott Smyers, Richard Bardini, Thomas Swidler and Glen
stone of Sony for their inputs to this document.
Author's Addresses
Bruce Fairman Sony Electronics, Inc. PTCA-NSA 3300 Zanker Road San
Jose, CA 95134 Phone: 408-955-5739 Email: bruce.fairman@am.sony.com
Fairman Expires - December 2003 page [10]
RTP Payload for 1394/61883 Isochronous Streams June 2003
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
2 IEC 61883-1:1998 "Consumer audio/video equipment - Digital interface
-Part 1:General"
3 IEEE1394-2000 "IEEE Standard for a High Performance Serial Bus"
4 IEC 61883-2,-3,-5:1998 "Consumer audio/video equipment - Digital
interface -Part 2, Part 3, Part 5"
5 IEC IEC 61883-6:1998 "Consumer audio/video equipment - Digital
interface - Part 6: Audio and music data transmission protocol"
6 IEC 61883-4:1998 "Consumer audio/video equipment - Digital interface
- Part 4: MPEG2-TS data transmission"
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A
Transport Protocol for Real Time Applications", RFC 1889, January 1996.
9 Smyers, S. "Scott's ppt presentation re: jitter"
Fairman Expires - December 2003 page [11]