FEC Framework Working Group M. Watson Internet-Draft Netflix Intended status: Standards Track T. Stockhammer Expires: May 29, 2011 Nomor Research November 25, 2010 RTP Payload Format for Raptor FEC draft-ietf-fecframe-rtp-raptor-04 Abstract This document specifies an RTP payload format for Forward Error Correction /(FEC) repair data produced by the Raptor FEC schemes. Raptor FEC schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the payload format which is required for the use of RTP to carry Raptor repair flows. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 29, 2011. Copyright Notice Copyright (c) 2010 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 Watson & Stockhammer Expires May 29, 2011 [Page 1] Internet-Draft RTP Payload Format for Raptor November 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 5. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Registration of the application/raptorfec media type . . . 7 5.1.1. Media Type Definition . . . . . . . . . . . . . . . . 7 5.2. Registration of the video/raptorfec media type . . . . . . 8 5.2.1. Media Type Definition . . . . . . . . . . . . . . . . 8 5.3. Registration of the audio/raptorfec media type . . . . . . 10 5.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 5.4. Registration of the text/raptorfec media type . . . . . . 12 5.4.1. Media Type Definition . . . . . . . . . . . . . . . . 12 6. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . 14 7. Offer/Answer considerations . . . . . . . . . . . . . . . . . 15 8. Declarative SDP Considerations . . . . . . . . . . . . . . . . 16 9. FEC Generation and Recovery Procedures . . . . . . . . . . . . 17 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Repair Packet Construction . . . . . . . . . . . . . . . . 17 9.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 17 10. Session Description Protocol (SDP) Example . . . . . . . . . . 18 11. Congestion Control Considerations . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Watson & Stockhammer Expires May 29, 2011 [Page 2] Internet-Draft RTP Payload Format for Raptor November 2010 1. Introduction The FEC Framework [I-D.ietf-fecframe-framework] defines a general framework for the use of Forward Error Correction (FEC) in association with arbitrary packet flows, including flows over UDP and RTP [RFC3550]. FECs operates by generating repair data packets ("repair data") which are sent separately from the source flow. At a receiver the source flow can be reconstructed provided a sufficient set of source and repair data packets are received. The FEC Framework provides for independence between application protocols and FEC codes. The use of a particular FEC code within the framework is defined by means of an FEC scheme which may then be used with any application protocol compliant to the framework. Repair data flows may be sent directly over a transport protocol such as UDP, or they may be encapsulated within RTP. In the latter case, an RTP payload format must be defined for each FEC scheme. This document defines the RTP payload format for the Raptor FEC schemes defined in [I-D.ietf-fecframe-raptor]. Watson & Stockhammer Expires May 29, 2011 [Page 3] Internet-Draft RTP Payload Format for Raptor November 2010 2. Conventions, Definitions and Acronyms 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]. Watson & Stockhammer Expires May 29, 2011 [Page 4] Internet-Draft RTP Payload Format for Raptor November 2010 3. Media Format Background The Raptor and RaptorQ codes are efficient block-based fountain codes, meaning that from any group of source packets (or 'source block') an arbitrary number of repair packets may be generated. The Raptor and RaptorQ codes have the property that the original group of source symbols can be recovered with very high probability from any set of symbols (source and repair) only slightly greater in number than the original number of source symbols. The RaptorQ code additionally has the property that the probability that the original group of source symbols can be recovered from a set of symbols (source and repair) equal in number to the original number of source symbols is in many cases also very high. [I-D.ietf-fecframe-raptor] defines six FEC schemes for the use of the Raptor and RaptorQ codes with arbitary packet flows: the first two schemes are fully applicable to arbitary packet flows (using Raptor and RaptorQ respectively). The third and fourth schemes are slightly optimised versions of the first two schemes which are applicable in applications with relatively small block sizes. The fifth and sixth schemes are variants of the third and fourth schemes which are applicable to a single source flow which already has some kind of identifiable sequence number. The presence of a sequence number in the source flow allows for backwards compatible operation (the source flows do not need to be modified in order to apply FEC). In this case, in the language of the FEC Framework, there is no need for an Explicit FEC Source Payload ID and it is therefore not included in the packets. This document specifcies the payload format for RTP repair flows and can be used with any of the FEC schemes defined in [I-D.ietf-fecframe-raptor]. Watson & Stockhammer Expires May 29, 2011 [Page 5] Internet-Draft RTP Payload Format for Raptor November 2010 4. Payload Format 4.1. RTP Header Usage The following rules SHALL be followed for the RTP header used with FEC repair packets: o Marker bit: The marker bit SHALL be set 1 for the last protection RTP packet sent for each source block, and otherwise set to 0 o Timestamp: The timestamp SHALL be set to a time corresponding to the packet's transmission time. The timestamp value has no use in the actual FEC protection process. It may be used for packet arrival timing and jitter calculations. The timestamp rate SHALL be specified using the "rate" media type parameter defined below. Other header fields SHALL be set according to the rules of [RFC3550]. 4.2. Payload Header There is no Payload Header in this payload format. 4.3. Payload Data Procedures and data formats for the use of Raptor FEC in an FECFRAME context are fully defined in [I-D.ietf-fecframe-raptor] and are not duplicated here. The procedures of those documents SHALL be followed in order to generate repair data streams to be carried by the payload formats defined in this document. The RTP Payload SHALL contain an FEC Repair Payload as defined in [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. Watson & Stockhammer Expires May 29, 2011 [Page 6] Internet-Draft RTP Payload Format for Raptor November 2010 5. Media Types 5.1. Registration of the application/raptorfec media type This RTP payload format is identified using the application/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 5.1.1. Media Type Definition Type name: application Subtype name: raptorfec Required parameters: o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate SHALL be larger than 1000 to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o raptor-scheme-id: The value of this parameter is the FEC scheme Id for the specific Raptor FEC scheme that will be used as defined in [I-D.ietf-fecframe-raptor]. o Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I-D.ietf-fecframe-raptor]. If this parameter is missing then the value "A" shall be assumed. Watson & Stockhammer Expires May 29, 2011 [Page 7] Internet-Draft RTP Payload Format for Raptor November 2010 Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: None Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watsonm@netflix.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Netflix Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.2. Registration of the video/raptorfec media type This RTP payload format is identified using the video/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 5.2.1. Media Type Definition Type name: video Subtype name: raptorfec Required parameters: Watson & Stockhammer Expires May 29, 2011 [Page 8] Internet-Draft RTP Payload Format for Raptor November 2010 o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate SHALL be larger than 1000 to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o raptor-scheme-id: The value of this parameter is the FEC scheme Id for the specific Raptor FEC scheme that will be used as defined in [I-D.ietf-fecframe-raptor]. o Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I-D.ietf-fecframe-raptor]. If this parameter is missing then the value "A" shall be assumed. Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: None Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): Watson & Stockhammer Expires May 29, 2011 [Page 9] Internet-Draft RTP Payload Format for Raptor November 2010 File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watsonm@netflix.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Netflix. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.3. Registration of the audio/raptorfec media type This RTP payload format is identified using the audio/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 5.3.1. Media Type Definition Type name: audio Subtype name: raptorfec Required parameters: o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate SHALL be larger than 1000 to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o raptor-scheme-id: The value of this parameter is the FEC scheme Id for the specific Raptor FEC scheme that will be used as defined in [I-D.ietf-fecframe-raptor]. o Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. Watson & Stockhammer Expires May 29, 2011 [Page 10] Internet-Draft RTP Payload Format for Raptor November 2010 o T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I-D.ietf-fecframe-raptor]. If this parameter is missing then the value "A" shall be assumed. Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: None Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watsonm@netflix.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Netflix. Watson & Stockhammer Expires May 29, 2011 [Page 11] Internet-Draft RTP Payload Format for Raptor November 2010 Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.4. Registration of the text/raptorfec media type This RTP payload format is identified using the text/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 5.4.1. Media Type Definition Type name: text Subtype name: raptorfec Required parameters: o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate SHALL be larger than 1000 to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o raptor-scheme-id: The value of this parameter is the FEC scheme Id for the specific Raptor FEC scheme that will be used as defined in [I-D.ietf-fecframe-raptor]. o Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For specific requirements for this value refer to [I-D.ietf-fecframe-raptor]. o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I-D.ietf-fecframe-raptor]. If this parameter is missing then the value "A" shall be assumed. Watson & Stockhammer Expires May 29, 2011 [Page 12] Internet-Draft RTP Payload Format for Raptor November 2010 Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: None Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watsonm@netflix.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Netflix. Change controller: IETF Audio/Video Transport working group delegated from the IESG. Watson & Stockhammer Expires May 29, 2011 [Page 13] Internet-Draft RTP Payload Format for Raptor November 2010 6. Mapping to SDP Parameters Applications that are using RTP transport commonly use Session Description Protocol (SDP) [RFC4566] to describe their RTP sessions. The information that is used to specify the media types in an RTP session has specific mappings to the fields in an SDP description. Note that if an application does not use SDP to describe the RTP sessions, an appropriate mapping must be defined and used to specify the media types and their parameters for the control/description protocol employed by the application. The mapping of the media type specification for "raptorfec" and its parameters in SDP is as follows: o The media type (e.g., "application") goes into the "m=" line as the media name. o The media subtype ("raptorfec") goes into the 'a=rtpmap' line as the encoding name. The RTP clock rate parameter ("rate") also goes into the 'a=rtpmap' line as the clock rate. o The remaining required payload-format-specific parameters go into the 'a=fmtp' line by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs. An SDP Example is provided in Section 10. Watson & Stockhammer Expires May 29, 2011 [Page 14] Internet-Draft RTP Payload Format for Raptor November 2010 7. Offer/Answer considerations When offering Raptor FEC over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply: o Each combination of the Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender application may desire to offer multiple offers with different sets of Kmax and T values as long as the parameter values are valid. The receiver SHOULD normally choose the offer with the largest value of the product of Kmax and T that it supports. o The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side and the receiver must consider this when choosing an offer. o When the P parameter is omitted, FEC Payload ID Format A MUST be assumed. In an answer which selects an offer in which the P parameter was omitted, the P parameter MUST either be omitted, or included with value "A". Watson & Stockhammer Expires May 29, 2011 [Page 15] Internet-Draft RTP Payload Format for Raptor November 2010 8. Declarative SDP Considerations In declarative usage, like SDP in the Real-time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2947], the following considerations apply: o The payload format configuration parameters are all declarative and a participant MUST use the configuration that is provided for the session. o More than one configuration may be provided (if desired) by declaring multiple RTP payload types. In that case, the receivers should choose the repair flow that is best for them. Watson & Stockhammer Expires May 29, 2011 [Page 16] Internet-Draft RTP Payload Format for Raptor November 2010 9. FEC Generation and Recovery Procedures 9.1. Overview This document only specifies the repair packet construction when the repair packets are delivered with RTP. Source packet construction is covered in [I-D.ietf-fecframe-raptor]. This section provides an overview on how to generate repair packets and on how to reconstruct missing source packets from a set of available source and repair packets. Detailed algorithms for the generation of Raptor and RaptorQ symbols are provided in [RFC5053] and [I-D.ietf-rmt-bb-fec-raptorq], respectively. 9.2. Repair Packet Construction The construction of the repair packet is fully specified in Section 4. A repair packet is constructed by the concatenation of o an RTP header as specified in Section 4.1, and o payload data as defined in Section 4. Repair Packet Construction may make use of the Sender Operation for RTP repair flows as specified in see [I-D.ietf-fecframe-framework], section 4.2. 9.3. Source Packet Reconstruction Source Packet Reconstruction may make use of the Receiver Operation for the case of RTP repair flows as specified in see [I-D.ietf-fecframe-framework], section 4.3. Depending on the FEC scheme in use of the ones defined in [I-D.ietf-fecframe-raptor], the appropriate source blocks are formed. If enough data for decoding of any or all of the missing source payloads in the source block has been received, the respective FEC decoding procedures are applied. In case the FEC scheme uses Raptor codes as defined in [RFC5053], then the Example FEC decoder as specifed in [RFC5053], section 5.5, may be used. In case the FEC scheme uses RaptorQ codes as defined in [I-D.ietf-rmt-bb-fec-raptorq], then the Example FEC decoder as specifed in [I-D.ietf-rmt-bb-fec-raptorq], section 5.4, may be used. Watson & Stockhammer Expires May 29, 2011 [Page 17] Internet-Draft RTP Payload Format for Raptor November 2010 10. Session Description Protocol (SDP) Example This section provides an SDP [RFC4566] example. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group with the "a=group:FEC S1 R1" line. The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms. An Explicit Source FEC Payload ID is used for the source flow. v=0 o=ali 1122334455 1122334466 IN IP4 fec.example.com s=Raptor RTP FEC Example t=0 0 a=group:FEC-FR S1 R1 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0; tag-len=4 a=mid:S1 m=application 30000 RTP/AVT c=IN IP4 233.252.0.2/127 a=rtpmap:110 raptorfec/90000 a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128; P=A; repair-window=200000 a=mid:R1 Watson & Stockhammer Expires May 29, 2011 [Page 18] Internet-Draft RTP Payload Format for Raptor November 2010 11. Congestion Control Considerations FEC is an effective approach to provide applications resiliency against packet losses. However, in networks where the congestion is a major contributor to the packet loss, the potential impacts of using FEC SHOULD be considered carefully before injecting the repair flows into the network. In particular, in bandwidth-limited networks, FEC repair flows may consume most or all of the available bandwidth and consequently may congest the network. In such cases, the applications MUST NOT arbitrarily increase the amount of FEC protection since doing so may lead to a congestion collapse. If desired, stronger FEC protection MAY be applied only after the source rate has been reduced. In a network-friendly implementation, an application SHOULD NOT send/ receive FEC repair flows if it knows that sending/receiving those FEC repair flows would not help at all in recovering the missing packets. Such a practice helps reduce the amount of wasted bandwidth. It is RECOMMENDED that the amount of FEC protection is adjusted dynamically based on the packet loss rate observed by the applications. In multicast scenarios, it may be difficult to optimize the FEC protection per receiver. If there is a large variation among the levels of FEC protection needed by different receivers, it is RECOMMENDED that the sender offers multiple repair flows with different levels of FEC protection and the receivers join the corresponding multicast sessions to receive the repair flow(s) that is best for them. For more background and normative requirements, see [I-D.ietf-fecframe-framework], section 8. Watson & Stockhammer Expires May 29, 2011 [Page 19] Internet-Draft RTP Payload Format for Raptor November 2010 12. Security Considerations Security Considerations related to the use of the FEC Framework are addressed in [I-D.ietf-fecframe-framework], section 9. These consideration apply in full to users of the RTP payload formats defined in this document, since these are defined in terms of the FEC Framework. No further security considerations related specifically to the Raptor FEC schemes defined in [I-D.ietf-fecframe-raptor] have been identified. RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, transport and signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, using the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist. Watson & Stockhammer Expires May 29, 2011 [Page 20] Internet-Draft RTP Payload Format for Raptor November 2010 13. IANA Considerations New media subtypes are subject to IANA registration. For the registration of the payload format and its parameters introduced in this document, refer to Section 5. Watson & Stockhammer Expires May 29, 2011 [Page 21] Internet-Draft RTP Payload Format for Raptor November 2010 14. Acknowledgements Thanks are due to Ali C. Begen and Colin Perkins for thorough review of earlier draft versions of this document. Watson & Stockhammer Expires May 29, 2011 [Page 22] Internet-Draft RTP Payload Format for Raptor November 2010 15. References 15.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, RFC 3550, July 2003. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4855] Casner, S., "Media Type Registration of RTP payload formats", RFC 4855, February 2007. [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-10 (work in progress), September 2010. [I-D.ietf-fecframe-raptor] Watson, M., "Raptor FEC Schemes for FECFRAME", draft-ietf-fecframe-raptor-02 (work in progress), March 2010. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007. [I-D.ietf-rmt-bb-fec-raptorq] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", draft-ietf-rmt-bb-fec-raptorq-04 (work in progress), August 2010. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 15.2. Informative References [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Watson & Stockhammer Expires May 29, 2011 [Page 23] Internet-Draft RTP Payload Format for Raptor November 2010 [RFC2947] Altman, J., "Telnet Encryption: DES3 64 bit Cipher Feedback", RFC 2947, September 2000. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Watson & Stockhammer Expires May 29, 2011 [Page 24] Internet-Draft RTP Payload Format for Raptor November 2010 Authors' Addresses Mark Watson Netflix 100 Winchester Circle Los Gatos, CA 95032 U.S.A. Email: watsonm@netflix.com Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany. Email: stockhammer@nomor.de Watson & Stockhammer Expires May 29, 2011 [Page 25]