Internet DRAFT - draft-fineberg-avtext-temporal-layer-ext
draft-fineberg-avtext-temporal-layer-ext
AVTEXT A. Fineberg
Internet Draft vLine, Inc.
Intended status: Standards Track July 8, 2013
Expires: January 8, 2014
A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
draft-fineberg-avtext-temporal-layer-ext-00
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), 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
This Internet-Draft will expire on December 9, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Fineberg Expires January 8, 2014 [Page 1]
Internet-Draft VP8 Temporal Layer Information July 2013
Abstract
This document defines a mechanism by which packets of Real-Time
Tranport Protocol (RTP) video streams encoded with the VP8 codec can
indicate, in an RTP header extension, the temporal layer information
about the frame encoded in the RTP packet. This information can be
used in a middlebox performing bandwidth management of streams
without requiring it to decrypt the streams.
Table of Contents
1. Introduction.................................................2
2. Conventions used in this document............................3
3. Temporal Layer Information...................................3
4. Signaling (Setup) Information................................3
5. Considerations on Use........................................4
6. Security Considerations......................................4
7. IANA Considerations..........................................4
8. References...................................................5
8.1. Normative References....................................5
8.2. Informative References..................................5
1. Introduction
In a centralized Real-Time Transport Protocol (RTP) [RFC3550] video
conference, a video mixer or forwarder receives video streams from
many or all of the conference participants. It then selectively
forwards some or all of the video streams to other participants in
the conference.
It is often necessary to manage the bandwidth usage when forwarding
these streams. One tool provided to manage the bandwidth usage when
handling video streams that are encoded using the VP8 codec is the
use of temporal scaling by selectively forwarding only the desired
temporal layers. These layers are defined by their temporal layer
index. The temporal layer information is encoded in the RTP payload
format for VP8 video [draft-ietf-payload-vp8-08].
It is desirable however in the case of Secure Real-Time Transport
Protocol (SRTP) [RFC3711] to be able to manage the temporal scaling
without having to decrypt the SRTP packets.
As an alternative, this document defines an RTP header extension
[RFC5285] through which senders of video packets can indicate the
temporal layer information of the packets' payload, reducing the
processing load for a server.
Fineberg Expires January 9, 2013 [Page 2]
Internet-Draft VP8 Temporal Layer Information July 2013
2. 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 [RFC2119].
3. Temporal Layer Information
The VP8 temporal layer information header extension carries the 2-bit
temporal layer index (TID), layer sync bit (Y), and 15-bit running
index of the frames (PictureID), as defined in [draft-ietf-payload-
vp8-08], of the VP8 encoded video frame in the RTP [RFC3550] payload
of the packet it is associated with. This information is carried in
an RTP header extension element as defined by the ''General Mechanism
for RTP Header Extensions'' [RFC5285].
The payload of the VP8 temporal layer information header extension
element can be encoded using the one-byte header defined in
[RFC5285]. Figure 1 shows a representative VP8 temporal layer
information encoding.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=2 | pad=0 |TID|Y| PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Representative VP8 temporal layer information encoding using
the one-byte header format
Note that, as indicated in [RFC5285] length field in the one-byte
header format takes the value 2 to indicate that 3 byte follows.
4. Signaling (Setup) Information
The URI for declaring this header extension in an extmap attribute is
"urn:ietf:params:rtp-hdrext:vp8tlinfo". It does not contain any
extension attributes.
An example attribute line in the SDP, might look like:
a=extmap:3 urn:ietf:params:rtp-hdrext:vp8tlinfo
If this extension is signaled when the VP8 codec is not in use, it
SHOULD be ignored and this header extension element SHOULD NOT be
included in the RTP header. If the header extension element is
included in the RTP header when VP8 is not in use or when VP8 is in
Fineberg Expires January 9, 2013 [Page 3]
Internet-Draft VP8 Temporal Layer Information July 2013
use but temporal layering is disabled, the value for the temporal
layer index (TID) MUST be 0.
5. Considerations on Use
This header extension makes no attempt to change the values already
contained in the RTP Payload Format for VP8 [draft-ietf-payload-vp8].
Therefore when this header extension is present, the values in the
header extension MUST be faithful representations of the values
contained in the RTP payload. Any discrepancy between the values
MUST be treated as an error.
6. Security Considerations
A malicious endpoint could choose to set the values in this header
extension falsely so as to claim a different encoding state. It is
not clear what could be gained by falsifying the encoding state as it
would only impact the decoding of the senders video. While this
might not impact a receiving endpoint that chooses to use the values
contained in the RTP payload instead of those in the RTP header
extension, it could impact endpoints that rely solely on the values
form the RTP header extension as well as adversely impact the work
done on a middlebox. As typically a middlebox will only use this
information for bandwidth management (which includes in this context
handling endpoints without the capability to decode a stream at full
frame rate), this falsified data could convince the middlebox that
every frame is a required frame and thereby implement a denial of
service attack on an endpoint. Thus if a middlebox device relies on
data from an untrusted endpoint, it SHOULD periodically audit the
data to ensure the RTP payload values match those in the RTP header
extension.
In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP
header extensions are authenticated but not encrypted. When this
header extension is used, VP8 temporal layer information is therefore
visible on a packet-by-packet basis to an attacker passively
observing the video stream. As this information provides no insight
into the contents of the video stream, it is not considered a high
risk exposure.
7. IANA Considerations
This document defines a new extension URI to the RTP Compact
HeaderExtensions subregistry of the Real-Time Transport Protocol
(RTP) Parameters registry, according to the following data:
Fineberg Expires January 9, 2013 [Page 4]
Internet-Draft VP8 Temporal Layer Information July 2013
Extension URI: urn:ietf:params:rtp-hdrext:vp8tlinfo
Description: VP8 Temporal Layer Information
Contact: fineberg@vline.com
Reference: RFC XXXX
Note to RFC Editor: please replace RFC XXXX with the number of this
RFC.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, ''RTP: A Transport Protocol for Real-Time
Applications'', STD 64, RFC3550, July 2003.
[RFC4301] Kent, S. and K. Seo, ''Security Architecture for the
Internet Protocol'', RFC 4301, December 2005.
[RFC5285] Singer, D. and H. Desineni, ''A General Mechanism for RTP
Header Extensions'', RFC 5285, July 2008.
8.2. Informative References
[I-D.ietf-payload-vp8-08] Westin, P., Lundin, H., Glover, M.,Uberti,
J., and F. Galligan, "RTP Payload Format for VP8 Video",
(work in progress) January, 2013.
[I-D.ietf-avtcore-srtp-encrypted-header-ext] Lennox, J., ''Encryption
of Header Extensions in the Secure Real-Time Transport
Protocol (SRTP)'' (work in progress) October, 2011.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, ''VP8 Data Format and Decoding
Guide'', RFC 6386, November 2011.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, ''The Secure Real-Time Transport Protocol (SRTP)'',
RFC3711, March 2004.
Fineberg Expires January 9, 2013 [Page 5]
Internet-Draft VP8 Temporal Layer Information July 2013
Authors' Addresses
Adam Fineberg
vLine, Inc.
116 Hamilton Ave
Palo Alto, CA 94301
Email: fineberg@vline.com
Fineberg Expires January 9, 2013 [Page 6]
