idnits 2.17.1 draft-ietf-avt-rtp-klv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2010) is 5084 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE336M' -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio Video Transport Working J. Arbeiter, Ed. 3 Group Harris Corporation 4 Internet-Draft J. Downs, Ed. 5 Intended status: Standards Track PAR Government Systems Corp. 6 Expires: October 30, 2010 April 28, 2010 8 RTP Payload Format for SMPTE 336M Encoded Data 9 draft-ietf-avt-rtp-klv-00 11 Abstract 13 This document specifies the payload format for packetization of KLV 14 (Key-Length-Value) Encoded Data, as defined by the Society of Motion 15 Picture and Television Engineers (SMPTE) in SMPTE 336M, into the 16 Real-time Transport Protocol (RTP). 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 30, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 54 3. Description of SMPTE 336M Data . . . . . . . . . . . . . . . . 3 55 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5 59 4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5 60 4.3. Implementation Considerations . . . . . . . . . . . . . . 6 61 4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6 62 4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6 63 4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 7 64 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 66 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 67 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 This document specifies the payload format for packetization of KLV 78 (Key-Length-Value) Encoded Data, as defined by the Society of Motion 79 Picture and Television Engineers (SMPTE) in [SMPTE336M], into the 80 Real-time Transport Protocol (RTP) [RFC3550]. 82 The payload format is defined in such a way that arbitrary KLV data 83 can be carried. No restrictions are placed on which KLV data keys 84 can be used. 86 A brief description of SMPTE 336M, KLV Encoded Data, is given. The 87 payload format itself, including use of the RTP header fields, is 88 specified in Section 4. The media type and IANA considerations are 89 also described. This document concludes with security considerations 90 relevant to this payload format. 92 2. Conventions, Definitions and Acronyms 94 The term "KLV item" is used in this document to refer to one single 95 universal key, length, and value triplet, or one single SMPTE 96 Universal Label, encoded as described in [SMPTE336M]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Description of SMPTE 336M Data 104 [SMPTE336M], Data Encoding Protocol Using Key-Length-Value, defines a 105 byte-level data encoding protocol for representing data items and 106 data groups. This encoding protocol definition is independent of the 107 application or transportation method used. 109 SMPTE 336M data encoding can be applied to a wide variety of binary 110 data. This encoding has been used to provide diverse and rich 111 metadata sets that describe or enhance associated video 112 presentations. Use of SMPTE 336M encoded metadata in conjunction 113 with video has enabled improvements in multimedia presentations, 114 content management and distribution, archival and retrieval, and 115 production workflow. 117 The SMPTE 336M standard defines a Key-Length-Value (KLV) triplet as a 118 data interchange protocol for data items or data groups where the Key 119 identifies the data, the Length specifies the length of the data and 120 the Value is the data itself. The KLV protocol provides a common 121 interchange point for all compliant applications irrespective of the 122 method of implementation or transport. 124 The standard also provides methods for combining associated KLV 125 triplets in data sets where the set of KLV triplets is itself coded 126 with KLV data coding protocol. Such sets can be coded in either full 127 form (Universal Sets) or in one of four increasingly bit-efficient 128 forms (Global Sets, Local Sets, Variable Length Packs and Defined 129 Length Packs). The standard provides a definition of each of these 130 data constructs. 132 The standard also describes implications of KLV coding including the 133 use of a SMPTE Universal Label as a value within a KLV coding triplet 134 or whose meaning is entirely conveyed by the SMPTE UL itself. The 135 two kinds of usage for such standalone SMPTE Universal Labels are a) 136 as a value in a K L V construct and b) as a Key that has no Length 137 and no Value. 139 The standard also defines the use of KLV coding to provide a means to 140 carry information that is registered with a non-SMPTE external 141 agency. 143 The encoding byte range (length of the payload) may accommodate 144 unusually large volumes of data. Consequently, a specific 145 application of KLV encoding may require only a limited operating data 146 range and those details shall be defined in a relevant application 147 document. 149 4. Payload Format 151 The main goal of the payload format design for SMPTE 336M data is to 152 provide carriage of SMPTE 336M data over RTP in a simple, yet robust 153 manner. All forms of SMPTE 336M data can be carried by the payload 154 format. The payload format maintains simplicity by using only the 155 standard RTP headers and not defining any payload headers. 157 SMPTE 336M KLV data is broken into KLVunits (see Section 4.2.1) based 158 on source data timing. Each KLVunit is then placed into one or more 159 RTP packet payloads. The RTP header marker bit is used to assist 160 receivers in locating the boundaries of KLVunits. 162 4.1. RTP Header Usage 164 This payload format uses the RTP packet header fields as described in 165 the table below: 167 +-----------+-------------------------------------------------------+ 168 | Field | Usage | 169 +-----------+-------------------------------------------------------+ 170 | Timestamp | The RTP Timestamp encodes the instant along a | 171 | | presentation timeline that the entire KLVunit encoded | 172 | | in the packet payload is to be presented. When one | 173 | | KLVunit is placed in multiple RTP packets, the RTP | 174 | | timestamp of all packets comprising that KLVunit MUST | 175 | | be the same. The timestamp clock frequency SHALL be | 176 | | defined as a parameter to the payload format | 177 | | (Section 6). | 178 | M-bit | The RTP header marker bit (M) SHALL be set to '1' for | 179 | | any RTP packet which contains the final byte of a | 180 | | KLVunit. For all other packets, the RTP header marker | 181 | | bit SHALL be set to '0'. This allows receivers to | 182 | | pass a KLVunit for parsing/decoding immediately upon | 183 | | receipt of the last RTP packet comprising the | 184 | | KLVunit. Without this, a receiver would need to wait | 185 | | for the next RTP packet with a different timestamp to | 186 | | arrive, thus signaling the end of one KLVunit and the | 187 | | start of another. | 188 +-----------+-------------------------------------------------------+ 190 The remaining RTP header fields are used as specified in [RFC3550]. 192 4.2. Payload Data 194 4.2.1. The KLVunit 196 A KLVunit is a logical collection of all KLV items that are to be 197 presented at a specific time. A KLVunit is comprised of one or more 198 KLV items. Compound items (sets, packs) are allowed as per 199 [SMPTE336M], but the contents of a compound item MUST NOT be split 200 across two KLVunits. Multiple KLV items in a KLVunit occur one after 201 another with no padding or stuffing between items. 203 4.2.2. KLVunit Mapping to RTP Packet Payload 205 An RTP packet payload SHALL contain one, and only one, KLVunit or a 206 fragment thereof. KLVunits small enough to fit into a single RTP 207 packet (RTP packet size is up to implementation but should consider 208 underlying transport/network factors such as MTU limitations) are 209 placed directly into the payload of the RTP packet, with the first 210 byte of the KLVunit (which is the first byte of a KLV universal key) 211 being the first byte of the RTP packet payload. 213 KLVunits too large to fit into a single RTP packet payload MAY span 214 multiple RTP packet payloads. When this is done, the KLVunit data 215 MUST be sent in sequential byte order, such that when all RTP packets 216 comprising the KLVunit are arranged in sequence number order, 217 concatenating the payload data together exactly reproduces the 218 original KLVunit. 220 Additionally, when a KLVunit is fragmented across multiple RTP 221 packets, all RTP packets transporting the fragments a KLVunit MUST 222 have the same timestamp. 224 KLVunits are bounded with changes in RTP packet timestamps. The 225 marker (M) bit in the RTP packet headers marks the last RTP packet 226 comprising a KLVunit (see Section 4.1). 228 4.3. Implementation Considerations 230 4.3.1. Loss of Data 232 RTP is generally deployed in network environments where packet loss 233 may occur. RTP header fields enable detection of lost packets, as 234 described in [RFC3550]. When transmitting payload data described by 235 this payload format, packet loss can cause the loss of whole KLVunits 236 or portions thereof. 238 4.3.1.1. Damaged KLVunits 240 A damaged KLVunit is any KLVunit that was carried in one or more RTP 241 packets that have been lost. When a lost packet is detected (through 242 use of the sequence number header field), the receiver: 244 o SHOULD consider the KLVunit carried in the prior packet (in 245 sequence number order) as damaged unless that prior packet's M bit 246 in the RTP header was set to '1'. 248 o SHOULD consider all subsequent packets (in sequence number order) 249 up to and including the next one with the M-bit in the RTP header 250 set to '1' as part of a damaged KLVunit. 252 The example below illustrates how a receiver would handle a lost 253 packet in one possible packet sequence: 255 +---------+-------------+ +--------------+ 256 | RTP Hdr | Data | | | 257 +---------+-------------+ +--------------+ 258 .... | ts = 30 | KLV KLV ... | | | >---+ 259 | M = 1 | | | | | 260 | seq = 5 | ... KLV KLV | | | | 261 +---------+-------------+ +--------------+ | 262 Last RTP pkt for time 30 Lost RTP Pkt | 263 For time 30 (seq = 6) | 264 | 265 +--------------------------------------------------------+ 266 | 267 | +---------+-------------+ +---------+-------------+ 268 | | RTP Hdr | Data | | RTP Hdr | Data | 269 | +---------+-------------+ +---------+-------------+ 270 +--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+ 271 | M = 0 | | | M = 1 | | | 272 | seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | | 273 +---------+-------------+ +---------+-------------+ | 274 RTP pkt for time 45 Last RTP pkt for time 45 | 275 KLVunit carried in these two packets is "damaged" | 276 | 277 +----------------------------------------------------------------+ 278 | 279 | +---------+-------------+ 280 | | RTP Hdr | Data | 281 | +---------+-------------+ 282 +--> | ts = 55 | KLV KLV ... | .... 283 | M = 1 | | 284 | seq = 9 | ... KLV ... | 285 +---------+-------------+ 286 Last and only RTP pkt 287 for time 55 289 In this example, the packets with sequence numbers 7 and 8 contain 290 portions of a KLVunit with timestamp of 45. This KLVunit is 291 considered "damaged" due to the missing RTP packet with sequence 292 number 6, which may have been part of this KLVunit. The KLVunit for 293 timestamp 30 (ended in packet with sequence number 5) is unaffected 294 by the missing packet. The KLVunit for timestamp 55, carried in the 295 packet with sequence number 9, is also unaffected by the missing 296 packet and is considered complete and intact. 298 4.3.1.2. Treatment of Damaged KLVunits 300 SMPTE 336M KLV data streams are built in such a way that it is 301 possible to partially recover from errors or missing data in a 302 stream. Exact specifics of how damaged KLVunits are handled are left 303 to each implementation, as different implementations may have 304 differing capabilities and robustness in their downstream KLV payload 305 processing. Because some implementations may be particularly limited 306 in their capacity to handle damaged KLVunits, receivers MAY drop 307 damaged KLVunits entirely. 309 5. Congestion Control 311 The general congestion control considerations for transporting RTP 312 data apply; see RTP [RFC3550] and any applicable RTP profile like AVP 313 [RFC3551]. 315 Further, SMPTE 336M data can be encoded in different schemes which 316 reduce the overhead associated with individual data items within the 317 overall stream. SMPTE 336M grouping constructs, such as local sets 318 and data packs, provide a mechanism to reduce bandwidth requirements. 320 6. Payload Format Parameters 322 This RTP payload format is identified using the media type 323 application/smpte336m, which is registered in accordance with 324 [RFC4855] and using the template of [RFC4288]. 326 6.1. Media Type Definition 328 Type name: application 330 Subtype name: smpte336m 332 Required parameters: 334 rate: RTP timestamp clock rate. Typically chosen based on 335 sampling rate of metadata being transmitted, but other rates 336 may be specified. 338 Optional parameters: 340 Encoding considerations: This media type is framed and binary; see 341 Section 4.8 of [RFC4288]. 343 Security considerations: See Section 8 of XXXX. 345 Interoperability considerations: Data items in smpte336m can be 346 very diverse. Receivers may only be capable of interpreting a 347 subset of the possible data items; unrecognized items are skipped. 349 Agreement on data items to be used out of band, via application 350 profile or similar, is typical. 352 Published specification: XXXX 354 Applications that use this media type: Audio and video streaming 355 and conferencing tools 357 Additional Information: none 359 Person & email address to contact for further information: J. 360 Arbeiter 362 Intended usage: COMMON 364 Restrictions on usage: This media type depends on RTP framing, and 365 hence is only defined for transfer via RTP ([RFC3550]). Transport 366 within other framing protocols is not defined at this time. 368 Author: 370 J. Arbeiter 372 J. Downs 374 Change controller: IETF Audio/Video Transport working group 375 delegated from the IESG 377 6.2. Mapping to SDP 379 The mapping of the above defined payload format media type and its 380 parameters to SDP [RFC4566] SHALL be done according to Section 3 of 381 [RFC4855]. 383 7. IANA Considerations 385 This memo requests that IANA registers application/smpte336m as 386 specified in Section 6.1. The media type is also requested to be 387 added to the IANA registry for "RTP Payload Format MIME types" 388 (http://www.iana.org/assignments/rtp-parameters). 390 8. Security Considerations 392 RTP packets using the payload format defined in this specification 393 are subject to the security considerations discussed in the RTP 394 specification [RFC3550], and in any applicable RTP profile. The main 395 security considerations for the RTP packet carrying the RTP payload 396 format defined within this memo are confidentiality, integrity and 397 source authenticity. Confidentiality is achieved by encryption of 398 the RTP payload. Integrity of the RTP packets through suitable 399 cryptographic integrity protection mechanism. Cryptographic system 400 may also allow the authentication of the source of the payload. A 401 suitable security mechanism for this RTP payload format should 402 provide confidentiality, integrity protection and at least source 403 authentication capable of determining if an RTP packet is from a 404 member of the RTP session or not. 406 Note that the appropriate mechanism to provide security to RTP and 407 payloads following this memo may vary. It is dependent on the 408 application, the transport, and the signalling protocol employed. 409 Therefore a single mechanism is not sufficient, although if suitable 410 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 411 be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 412 also other alternatives may exist. 414 This RTP payload format presents the possibility for significant non- 415 uniformity in the receiver-side computational complexity during 416 processing of SMPTE 336M payload data. Because the length of SMPTE 417 336M encoded data items is essentially unbounded, receivers must take 418 care when allocating resources used in processing. It is trivial to 419 construct pathological data that would cause a naive decoder to 420 allocate large amounts of resources, resulting in denial-of-service 421 threats. Receivers are encouraged to place limits on resource 422 allocation that are within the bounds set forth by any application 423 profile in use. 425 This RTP payload format does not contain any inheritly active 426 content. However, individual SMPTE 336M KLV items could be defined 427 to convey active content in a particular application. Therefore, 428 receivers capable of decoding and interpreting such data items should 429 use appropriate caution and security practices. Receivers not 430 capable of decoding such data items are not at risk; unknown data 431 items are skipped over and discarded according to SMPTE 336M 432 processing rules. 434 9. References 436 9.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 443 Jacobson, "RTP: A Transport Protocol for Real-Time 444 Applications", STD 64, RFC 3550, July 2003. 446 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 447 Video Conferences with Minimal Control", STD 65, RFC 3551, 448 July 2003. 450 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 451 Registration Procedures", BCP 13, RFC 4288, December 2005. 453 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 454 Description Protocol", RFC 4566, July 2006. 456 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 457 Formats", RFC 4855, February 2007. 459 [SMPTE336M] 460 SMPTE, "SMPTE336M-2007: Data Encoding Protocol Using Key- 461 Length-Value", 2007, . 463 9.2. Informative References 465 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 466 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 467 RFC 3711, March 2004. 469 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 470 Internet Protocol", RFC 4301, December 2005. 472 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 473 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 475 Authors' Addresses 477 J. Arbeiter (editor) 478 Harris Corporation 479 US 481 Phone: 482 Email: jarbeite@harris.com 483 J. Downs (editor) 484 PAR Government Systems Corp. 485 US 487 Phone: 488 Email: jeff_downs@partech.com