N. Venna
Internet Draft Brix Networks
Expires: January 2008 K. Hedayat
Brix Networks
R.Krzanowski
Verizon
G.Dion
Ineoquest
July 2007
RTCP XR - Report Block for IPTV Metrics
draft-venna-avt-rtcpxr-iptv-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 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."
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Venna, et al. Expires January 2008 [Page 1]
Internet-Draft RTCP XR for IPTV Streams July, 2007
Abstract
This document defines a new report block for the Extended Report
(XR) packet type of the RTP Control Protocol (RTCP) for use by IPTV
applications. The report block supports monitoring of IPTV streams
by providing a mechanism for IPTV clients to report on the
performance of different aspects of the IPTV stream.
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Background....................................................3
4. IPTV Metrics Report Block.....................................3
4.1 Main Block Format.........................................4
4.2 Program sub-block Format..................................6
4.3 Elementary Stream sub-block Format........................8
5. Security Considerations.......................................9
6. IANA Considerations..........................................10
7. Normative References.........................................10
8. Informative References.......................................10
1. Introduction
As the number of IPTV deployments continue to increase, it becomes
necessary for the operator to collect various metrics on the
streams that are being delivered to understand the quality of the
service that a user is receiving. This draft defines a new report
block for the Extended Report (XR) packet type of the RTP Control
Protocol (RTCP) that allows IPTV clients to report to a server on
various aspects of the stream that is being delivered to them.
[RFC3611] defines the XR packet type for RTCP as well as how XR
packets can be signaled by an application that uses Session
Description Protocol (SDP). The document further defines seven
report block formats to convey information beyond that already
contained in the reception report blocks of RTCP's Sender Report
(SR) or Receiver Report (RR) packets.
The new block type defined in this draft is the IPTV Metrics block.
The data reported by a client is intended to be useful in
understanding the short-term performance of the IPTV service as
well as long-term indicators for network configuration.
Venna, et al. Expires September 2007 [Page 2]
Internet-Draft RTCP XR for IPTV Streams July, 2007
2. Terminology
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 [RFC2119].
3. Background
[RFC2250] specifies the RTP payload format for MPEG1/MPEG2 Video.
The specification describes how to encapsulate MPEG System and
Transport streams within the RTP payload. For MPEG2 transport
streams, the RTP payload will contain an integral number of MPEG2
transport packets. Futher, a small number of these transport
packets (normally fixed in size at 188 bytes) are aggregated into a
single RTP packet. The number of transport packets contained is
computed by dividing the RTP payload length by the length of a
transport packet.
ISO/IEC 13818-1 addresses the combining of one or more elementary
streams of video and audio, as well as other data, into single or
multiple streams eligible for transmission. MPEG-2 Transport stream
packets are made of packets from various elementary streams (audio,
video, data) and Program Specific Information (PSI) tables. The
four PSI tables viz. Program Association Table (PAT), Program Map
Table (PMT), Conditional Access Table (CAT), and Network
Information Table (NIT) contain the necessary and sufficient
information to demultiplex and present programs. The audio and
video elementary streams can carry data encoded using various
codecs such as MPEG-1 Audio, MPEG-2 Video, H.264 etc.
The new reporting blocks defined in this draft report metrics from
various encapsulations and views of the media stream - RTP, MPEG-2
TS, Programs, Elementary Streams.
An IPTV client SHOULD use report blocks specified in [RFC3611] and
[RFC3550] to report metrics that are relevant to understanding the
performance of the media stream. For instance, the client SHOULD
use RTCP Reception Report (RR) to report on the cumulative number
of packets lost, interarrival jitter etc. The client SHOULD also
use the Statistics Summary Report Block of the RTCP Extended
Reports to report detailed metrics about lost and duplicate
packets, min/max/avg/standard deviation of jitter for a range of
sequence numbers.
4. IPTV Metrics Report Block
Venna, et al. Expires September 2007 [Page 3]
Internet-Draft RTCP XR for IPTV Streams July, 2007
This block reports metrics on a range of RTP packets received for
the IPTV stream by a client.
4.1 Main Block Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=X | reserved | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_rtp_seq | end_rtp_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate RTP Pkts | Out of Order RTP Pkts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost RTP Pkts | Noticeable Lost RTP Pkts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min RTP Jitter | Max RTP Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Avg RTP Jitter | Std Dev of RTP Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of RTP Loss Periods | Min RTP Loss Period size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max RTP Loss Period size | Avg RTP Loss Period size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of First Priority Errors | # of Second Priority Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max PAT Gap | Avg PAT Gap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Programs |Loss Constaint | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Program Data (Program Sub block) ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A IPTV Metrics Report Block is identified by the constant TBD.
reserved: 8 bits
This field is reserved for future definition. In the absence
of such definition, the bits in this field MUST be set to zero
and MUST be ignored by the receiver.
block length: 16 bits
As defined in Section 3 of [RFC3611].
SSRC of source: 32 bits
Venna, et al. Expires September 2007 [Page 4]
Internet-Draft RTCP XR for IPTV Streams July, 2007
As defined in Section 4.1 of [RFC3611].
begin_rtp_seq: 16 bits
The first RTP sequence number that this block reports on.
end_rtp_seq: 16 bits
The last RTP sequence number that this block reports on plus
one.
duplicate RTP packets: 16 bits
The number of duplicate RTP packets received in the above
sequence number interval.
out of order RTP packets: 16 bits
The number of out-of-order RTP packets received in the above
sequence number interval.
Lost RTP packets: 16 bits
The number of lost RTP packets in the above sequence number
interval.
noticeable lost RTP packets: 16 bits
The number of noticeable lost RTP packets as defined in RFC
3357. The loss constraint is specified later.
min RTP jitter: 16 bits
The minimum jitter of received RTP packets in the above
sequence specified in milli seconds.
max RTP jitter: 16 bits
The maximum jitter of received RTP packets in the above
sequence specified in milli seconds.
avg RTP jitter: 16 bits
The average jitter of received RTP packets in the above
sequence specified in milli seconds.
std deviation of RTP jitter: 16 bits
The standard deviation of jitter of received RTP packets in
the above sequence specified in milli seconds.
# of RTP loss periods: 16 bits
The number of loss periods in the above sequence as defined
in [RFC3357] for RTP packets.
min RTP loss period size: 16 bits
The number of RTP packets lost in the loss period of the
smallest size.
max RTP loss period size: 16 bits
The number of RTP packets lost in the loss period of the
Venna, et al. Expires September 2007 [Page 5]
Internet-Draft RTCP XR for IPTV Streams July, 2007
largest size.
avg RTP loss period size: 16 bits
The avg number of RTP packets lost in each of the loss
periods.
# of First Priority Errors: 16 bits
The number of first priority errors in the MPEG-2 TS as
specified in ETSI TR 101 290. This includes Sync loss errors,
Sync byte errors, PAT errors, Continuity counter errors, PMT
errors, and PID errors.
# of Second Priority Errors: 16 bits
The number of second priority errors in the MPEG-2 TS as
specified in ETSI TR 101 290. This includes TS errors, CRC
errors, PCR errors, PTS errors, and CAT errors.
max PAT gap: 16 bits
The maximum gap between two successive PAT pkts in milli
seconds. This metric is related to channel change time.
avg PAT gap: 16 bits
The average gap between two successive PAT pkts in milli
seconds. This metric is related to channel change time.
# of programs: 16 bits
The total number of programs carried in this transport stream.
For each program, a separate block is reported.
loss constraint: 8 bits
The value of loss constraint used to compute noticeable lost
RTP packets.
4.2 Program sub-block Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max PMT Gap | Avg PMT Gap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max PCR Gap | Avg PCR Gap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min PCR Jitter | Max PCR Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Avg PCR Jitter | Std Dev of PCR Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
Venna, et al. Expires September 2007 [Page 6]
Internet-Draft RTCP XR for IPTV Streams July, 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stop Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Program Pkts | # of ES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ES Data (ES Sub block) ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PID: 16 bits
The Packet ID of the PMT for this program.
Number: 16 bits
The program number.
max PAT gap: 16 bits
The maximum gap between two successive PMT pkts in
milliseconds. This metric is related to channel change time.
avg PAT gap: 16 bits
The average gap between two successive PMT pkts in
milliseconds. This metric is related to channel change time.
max PCR gap: 16 bits
The maximum gap between two successive pkts that have a PCR in
them.
avg PCR gap: 16 bits
The average gap between two successive pkts that have a PCR in
them.
min PCR jitter: 16 bits
The minimum jitter of PCR clock in the above sequence
specified in milliseconds.
max PCR jitter: 16 bits
The maximum jitter of PCR clock in the above sequence
specified in milliseconds.
avg PCR jitter: 16 bits
The average jitter of PCR clock in the above sequence
specified in milliseconds.
std deviation of PCR jitter: 16 bits
The standard deviation of the jitter of PCR clock in the above
sequence specified in milliseconds.
Start time: 32 bits
The middle 32 bits of the 64 bits of the NTP timestamp when the
presence of this program was first detected.
Stop time: 32 bits
Venna, et al. Expires September 2007 [Page 7]
Internet-Draft RTCP XR for IPTV Streams July, 2007
The middle 32 bits of the 64 bits of the NTP timestamp when
the presence of this program was terminated. If the program is
still running, it should be set to 0.
# of program packets: 16 bits
The number of packets in the above sequence that belong to this
program.
# of ES: 16 bits
The total number of ES that belong to this program. For each
ES, a separate block is reported.
4.3 Elementary Stream sub-block Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | Number of PES Pkts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Frames | Complete Frames Lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate Pkts | Out of Order Pkts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Pkts | Partial Frames Rcvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Loss Periods | Min Loss Period size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Loss Period size | Avg Loss Period size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Noticeable lost |Loss Constaint | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stop Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PID: 16 bits
The Packet ID of the ES.
Number of PES Pkts: 16 bits
The number of TS pkts that belong to this ES.
Number of Frames: 16 bits
The number of frames received for this ES.
Complete Frames Lost: 16 bits
The number of complete frames lost for this ES.
duplicate packets: 16 bits
Venna, et al. Expires September 2007 [Page 8]
Internet-Draft RTCP XR for IPTV Streams July, 2007
The number of duplicate packets received in the above sequence
number interval.
out of order packets: 16 bits
The number of out-of-order packets received in the above
sequence number interval.
lost packets: 16 bits
The number of lost packets in the above sequence number
interval.
Partial Frames Rcvd: 16 bits
The number of partial frames rcvd for this ES.
# of loss periods: 16 bits
The number of loss periods in the above sequence as defined in
[RFC3357].
min loss period size: 16 bits
The number of packets lost in the loss period of the smallest
size.
max loss period size: 16 bits
The number of packets lost in the loss period of the largest
size.
avg loss period size: 16 bits
The avg number of packets lost each of the loss periods.
noticeable lost packets: 16 bits
The number of noticeable lost packets as defined in [RFC3357].
The loss constraint is specified later.
loss constraint: 8 bits
The value of loss constraint used to compute noticeable lost
packets.
Start time: 32 bits
The middle 32 bits of the 64 bits of the NTP timestamp when the
presence of this program was first detected.
Stop time: 32 bits
The middle 32 bits of the 64 bits of the NTP timestamp when the
presence of this program was terminated. If the program is
still running, it should be set to 0.
5. Security Considerations
The security considerations of [RFC3611] apply.
Venna, et al. Expires September 2007 [Page 9]
Internet-Draft RTCP XR for IPTV Streams July, 2007
6. IANA Considerations
A new block type for IPTV Metrics block should be registered with
IANA.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
and M. Westerlund, "RTP Control Protocol Extended
Reports (RTCP XR)", RFC 3611, November 2003.
8. Informative References
[RFC2250] Hoffman, D., Fernand, G., Goyal, V., Civanlar, M.,
"RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
January 1998.
[RFC3357] Koodli, R., Ravikanth, R., "One-way Loss Pattern
Sample Metrics", RFC 3357, August 2002.
Authors' Addresses
Nagarjuna Venna
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
Phone: +1 978 367 5703
Venna, et al. Expires September 2007 [Page 10]
Internet-Draft RTCP XR for IPTV Streams July, 2007
EMail: nvenna@brixnet.com
URI: http://www.brixnet.com/
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
Phone: +1 978 367 5611
EMail: khedayat@brixnet.com
URI: http://www.brixnet.com/
Roman M. Krzanowski, Ph.D.
Verizon Technology Organization
500 Westchester Ave.
White Plains, NY 10604
US
Phone: +1 914 644 2395
EMail: roman.krzanowski@verizon.com
URI: http://www.verizon.com/
Gino Dion
Ineoquest
Phone: +1 613 862 3399
EMail: gino.dion@ineoquest.com
IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
Venna, et al. Expires September 2007 [Page 11]
Internet-Draft RTCP XR for IPTV Streams July, 2007
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Venna, et al. Expires September 2007 [Page 12]