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]