idnits 2.17.1 draft-ietf-payload-rtp-klv-04.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 (March 1, 2012) is 4439 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 informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group J. Downs, Ed. 3 Internet-Draft PAR Government Systems Corp. 4 Intended status: Standards Track J. Arbeiter, Ed. 5 Expires: September 2, 2012 March 1, 2012 7 RTP Payload Format for SMPTE 336M Encoded Data 8 draft-ietf-payload-rtp-klv-04 10 Abstract 12 This document specifies the payload format for packetization of KLV 13 (Key-Length-Value) Encoded Data, as defined by the Society of Motion 14 Picture and Television Engineers (SMPTE) in SMPTE 336M, into the 15 Real-time Transport Protocol (RTP). 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 2, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 53 3. Media Format Background . . . . . . . . . . . . . . . . . . . 3 54 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5 59 4.3. Implementation Considerations . . . . . . . . . . . . . . 6 60 4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6 61 4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6 62 4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 8 63 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 65 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 66 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2.1. Offer/Answer Model and Declarative Considerations . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 "Universal Label Key" is used in this document to refer to a 95 fixed-length, 16-byte SMPTE-administered Universal Label (see 96 [SMPTE298M]) that is used as an identifying key in a KLV item. 98 The term "KLV item" is used in this document to refer to one single 99 Universal Label Key, length, and value triplet encoded as described 100 in [SMPTE336M]. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Media Format Background 108 [SMPTE336M], Data Encoding Protocol Using Key-Length-Value, defines a 109 byte-level data encoding protocol for representing data items and 110 data groups. This encoding protocol definition is independent of the 111 application or transportation method used. 113 SMPTE 336M data encoding can be applied to a wide variety of binary 114 data. This encoding has been used to provide diverse and rich 115 metadata sets that describe or enhance associated video 116 presentations. Use of SMPTE 336M encoded metadata in conjunction 117 with video has enabled improvements in multimedia presentations, 118 content management and distribution, archival and retrieval, and 119 production workflow. 121 The SMPTE 336M standard defines a Key-Length-Value (KLV) triplet as a 122 data interchange protocol for data items or data groups where the Key 123 identifies the data, the Length specifies the length of the data and 124 the Value is the data itself. The KLV protocol provides a common 125 interchange point for all compliant applications irrespective of the 126 method of implementation or transport. 128 The Key of a KLV triplet (a Universal Label Key) is coded using a 129 fixed-length 16-byte SMPTE-administered Universal Label. [SMPTE298M] 130 further details the structure of 16-byte SMPTE-administered Universal 131 Labels. Universal Label Keys are maintained in registries published 132 by SMPTE (see, for example, [SMPTE335M] and [SMPTERP210]). 134 The standard also provides methods for combining associated KLV 135 triplets in data sets where the set of KLV triplets is itself coded 136 with KLV data coding protocol. Such sets can be coded in either full 137 form (Universal Sets) or in one of four increasingly bit-efficient 138 forms (Global Sets, Local Sets, Variable Length Packs and Defined 139 Length Packs). The standard provides a definition of each of these 140 data constructs. 142 Additionally, the standard defines the use of KLV coding to provide a 143 means to carry information that is registered with a non-SMPTE 144 external agency. 146 4. Payload Format 148 The main goal of the payload format design for SMPTE 336M data is to 149 provide carriage of SMPTE 336M data over RTP in a simple, yet robust 150 manner. All forms of SMPTE 336M data can be carried by the payload 151 format. The payload format maintains simplicity by using only the 152 standard RTP headers and not defining any payload headers. 154 SMPTE 336M KLV data is broken into KLVunits. A KLVunit is simply a 155 logical grouping of otherwise unframed KLV data, grouped based on 156 source data timing (see Section 4.2.1). Each KLVunit is then placed 157 into one or more RTP packet payloads. The RTP header marker bit is 158 used to assist receivers in locating the boundaries of KLVunits. 160 4.1. RTP Header Usage 162 This payload format uses the RTP packet header fields as described in 163 the table below: 165 +-----------+-------------------------------------------------------+ 166 | Field | Usage | 167 +-----------+-------------------------------------------------------+ 168 | Timestamp | The RTP Timestamp encodes the instant along a | 169 | | presentation timeline that the entire KLVunit encoded | 170 | | in the packet payload is to be presented. When one | 171 | | KLVunit is placed in multiple RTP packets, the RTP | 172 | | timestamp of all packets comprising that KLVunit MUST | 173 | | be the same. The timestamp clock frequency is defined | 174 | | as a parameter to the payload format (Section 6). | 175 | M-bit | The RTP header marker bit (M) is used to demarcate | 176 | | KLVunits. Senders MUST set the marker bit to '1' for | 177 | | any RTP packet which contains the final byte of a | 178 | | KLVunit. For all other packets, senders MUST set the | 179 | | RTP header marker bit to '0'. This allows receivers | 180 | | to pass a KLVunit for parsing/decoding immediately | 181 | | upon receipt of the last RTP packet comprising the | 182 | | KLVunit. Without this, a receiver would need to wait | 183 | | for the next RTP packet with a different timestamp to | 184 | | arrive, thus signaling the end of one KLVunit and the | 185 | | start of another. | 186 +-----------+-------------------------------------------------------+ 188 The remaining RTP header fields are used as specified in [RFC3550]. 190 4.2. Payload Data 192 4.2.1. The KLVunit 194 A KLVunit is a logical collection of all KLV items that are to be 195 presented at a specific time. A KLVunit is comprised of one or more 196 KLV items. Compound items (sets, packs) are allowed as per 197 [SMPTE336M], but the contents of a compound item MUST NOT be split 198 across two KLVunits. Multiple KLV items in a KLVunit occur one after 199 another with no padding or stuffing between items. 201 4.2.2. KLVunit Mapping to RTP Packet Payload 203 An RTP packet payload SHALL contain one, and only one, KLVunit or a 204 fragment thereof. KLVunits small enough to fit into a single RTP 205 packet (RTP packet size is up to implementation but should consider 206 underlying transport/network factors such as MTU limitations) are 207 placed directly into the payload of the RTP packet, with the first 208 byte of the KLVunit (which is the first byte of a KLV Universal Label 209 Key) being the first byte of the RTP packet payload. 211 KLVunits too large to fit into a single RTP packet payload MAY span 212 multiple RTP packet payloads. When this is done, the KLVunit data 213 MUST be sent in sequential byte order, such that when all RTP packets 214 comprising the KLVunit are arranged in sequence number order, 215 concatenating the payload data together exactly reproduces the 216 original KLVunit. 218 Additionally, when a KLVunit is fragmented across multiple RTP 219 packets, all RTP packets transporting the fragments of a KLVunit MUST 220 have the same timestamp. 222 KLVunits are bounded with changes in RTP packet timestamps. The 223 marker (M) bit in the RTP packet headers marks the last RTP packet 224 comprising a KLVunit (see Section 4.1). 226 4.3. Implementation Considerations 228 4.3.1. Loss of Data 230 RTP is generally deployed in network environments where packet loss 231 might occur. RTP header fields enable detection of lost packets, as 232 described in [RFC3550]. When transmitting payload data described by 233 this payload format, packet loss can cause the loss of whole KLVunits 234 or portions thereof. 236 4.3.1.1. Damaged KLVunits 238 A damaged KLVunit is any KLVunit that was carried in one or more RTP 239 packets that have been lost. When a lost packet is detected (through 240 use of the sequence number header field), the receiver: 242 o MUST consider the KLVunit partially received before a lost packet 243 as damaged. This damaged KLVunit includes all packets prior to 244 the lost one (in sequence number order) back to, but not 245 including, the most recent packet in which the M-bit in the RTP 246 header was set to '1'. 248 o MUST consider the first KLVunit received after a lost packet as 249 damaged. This damaged KLVunit includes the first packet after the 250 lost one (in sequence number order) and, if the first packet has 251 its M-bit in the RTP header is set to '0', all subsequent packets 252 up to and including the next one with the M-bit in the RTP header 253 set to '1'. 255 The above applies regardless of the M-bit value in the RTP header of 256 the lost packet itself. This enables very basic receivers to look 257 solely at the M-bit to determine the outer boundaries of damaged 258 KLVunits. For example, when a packet with the M-bit set to '1' is 259 lost, the KLVunit that the lost packet would have terminated is 260 considered damaged, as is the KLVunit comprised of packets received 261 subsequent to the lost packet (up to and including the next received 262 packet with M-bit set to '1'). 264 The example below illustrates how a receiver would handle a lost 265 packet in another possible packet sequence: 267 +---------+-------------+ +--------------+ 268 | RTP Hdr | Data | | | 269 +---------+-------------+ +--------------+ 270 .... | ts = 30 | KLV KLV ... | | | >---+ 271 | M = 1 | | | | | 272 | seq = 5 | ... KLV KLV | | | | 273 +---------+-------------+ +--------------+ | 274 Last RTP pkt for time 30 Lost RTP Pkt | 275 (seq = 6) | 276 | 277 +--------------------------------------------------------+ 278 | 279 | +---------+-------------+ +---------+-------------+ 280 | | RTP Hdr | Data | | RTP Hdr | Data | 281 | +---------+-------------+ +---------+-------------+ 282 +--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+ 283 | M = 0 | | | M = 1 | | | 284 | seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | | 285 +---------+-------------+ +---------+-------------+ | 286 RTP pkt for time 45 Last RTP pkt for time 45 | 287 KLVunit carried in these two packets is "damaged" | 288 | 289 +----------------------------------------------------------------+ 290 | 291 | +---------+-------------+ 292 | | RTP Hdr | Data | 293 | +---------+-------------+ 294 +--> | ts = 55 | KLV KLV ... | .... 295 | M = 1 | | 296 | seq = 9 | ... KLV ... | 297 +---------+-------------+ 298 Last and only RTP pkt 299 for time 55 301 In this example, the packets with sequence numbers 7 and 8 contain 302 portions of a KLVunit with timestamp of 45. This KLVunit is 303 considered "damaged" due to the missing RTP packet with sequence 304 number 6, which might have been part of this KLVunit. The KLVunit 305 for timestamp 30 (ended in packet with sequence number 5) is 306 unaffected by the missing packet. The KLVunit for timestamp 55, 307 carried in the packet with sequence number 9, is also unaffected by 308 the missing packet and is considered complete and intact. 310 4.3.1.2. Treatment of Damaged KLVunits 312 SMPTE 336M KLV data streams are built in such a way that it is 313 possible to partially recover from errors or missing data in a 314 stream. Exact specifics of how damaged KLVunits are handled are left 315 to each implementation, as different implementations can have 316 differing capabilities and robustness in their downstream KLV payload 317 processing. Because some implementations can be particularly limited 318 in their capacity to handle damaged KLVunits, receivers MAY drop 319 damaged KLVunits entirely. 321 5. Congestion Control 323 The general congestion control considerations for transporting RTP 324 data apply; see RTP [RFC3550] and any applicable RTP profile like AVP 325 [RFC3551]. 327 Further, SMPTE 336M data can be encoded in different schemes which 328 reduce the overhead associated with individual data items within the 329 overall stream. SMPTE 336M grouping constructs, such as local sets 330 and data packs, provide a mechanism to reduce bandwidth requirements. 332 6. Payload Format Parameters 334 This RTP payload format is identified using the application/smpte336m 335 media type which is registered in accordance with [RFC4855] and using 336 the template of [RFC4288]. 338 6.1. Media Type Definition 340 Type name: application 342 Subtype name: smpte336m 344 Required parameters: 346 rate: RTP timestamp clock rate. Typically chosen based on 347 sampling rate of metadata being transmitted, but other rates 348 can be specified. 350 Optional parameters: None 351 Encoding considerations: This media type is framed and binary; see 352 Section 4.8 of [RFC4288]. 354 Security considerations: See Section 8 of RFCXXXX (note to RFC 355 editor: please replace XXXX with the number assigned to this RFC). 357 Interoperability considerations: Data items in smpte336m can be 358 very diverse. Receivers might only be capable of interpreting a 359 subset of the possible data items; unrecognized items are skipped. 360 Agreement on data items to be used out of band, via application 361 profile or similar, is typical. 363 Published specification: RFCXXXX 365 Applications that use this media type: Streaming of metadata 366 associated with simultaneously streamed video and transmission of 367 [SMPTE336M] based media formats (e.g. MXF [SMPTE377M]). 369 Additional Information: none 371 Person & email address to contact for further information: J. 372 Downs ; IETF Payload Working Group 373 375 Intended usage: COMMON 377 Restrictions on usage: This media type depends on RTP framing, and 378 hence is only defined for transfer via RTP ([RFC3550]). Transport 379 within other framing protocols is not defined at this time. 381 Author: 383 J. Downs 385 J. Arbeiter 387 Change controller: IETF Payload working group delegated from the 388 IESG. 390 6.2. Mapping to SDP 392 The mapping of the above defined payload format media type and its 393 parameters SHALL be done according to Section 3 of [RFC4855]. 395 6.2.1. Offer/Answer Model and Declarative Considerations 397 This payload format has no configuration or optional format 398 parameters. Thus, when offering SMPTE 336M Encoded Data over RTP 399 using Session Description Protocol (SDP) in an Offer/Answer model 400 [RFC3264] or in a declarative manner (e.g., SDP in the Real-time 401 Streaming Protocol (RTSP) [RFC2326] or the Session Announcement 402 Protocol (SAP) [RFC2974]), there are no specific considerations. 404 7. IANA Considerations 406 This memo requests that IANA registers application/smpte336m as 407 specified in Section 6.1. The media type is also requested to be 408 added to the IANA registry for "RTP Payload Format MIME types" 409 (http://www.iana.org/assignments/rtp-parameters). 411 8. Security Considerations 413 RTP packets using the payload format defined in this specification 414 are subject to the security considerations discussed in the RTP 415 specification [RFC3550], and in any applicable RTP profile. The main 416 security considerations for the RTP packet carrying the RTP payload 417 format defined within this memo are confidentiality, integrity and 418 source authenticity. Confidentiality is achieved by encryption of 419 the RTP payload. Integrity of the RTP packets through suitable 420 cryptographic integrity protection mechanism. Cryptographic systems 421 may also allow the authentication of the source of the payload. A 422 suitable security mechanism for this RTP payload format should 423 provide confidentiality, integrity protection and at least source 424 authentication capable of determining if an RTP packet is from a 425 member of the RTP session or not. 427 Note that the appropriate mechanism to provide security to RTP and 428 payloads following this memo may vary. It is dependent on the 429 application, the transport, and the signaling protocol employed. 430 Therefore a single mechanism is not sufficient, although if suitable 431 the usage of SRTP [RFC3711] is recommended. Other mechanisms that 432 may be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 433 also other alternatives may exist. 435 This RTP payload format presents the possibility for significant non- 436 uniformity in the receiver-side computational complexity during 437 processing of SMPTE 336M payload data. Because the length of SMPTE 438 336M encoded data items is essentially unbounded, receivers must take 439 care when allocating resources used in processing. It is trivial to 440 construct pathological data that would cause a naive decoder to 441 allocate large amounts of resources, resulting in denial-of-service 442 threats. Receivers SHOULD place limits on resource allocation that 443 are within the bounds set forth by any application profile in use. 445 This RTP payload format does not contain any inherently active 446 content. However, individual SMPTE 336M KLV items could be defined 447 to convey active content in a particular application. Therefore, 448 receivers capable of decoding and interpreting such data items should 449 use appropriate caution and security practices. In particular, 450 accepting active content from streams that lack authenticity or 451 integrity protection mechanisms places a receiver at risk of attacks 452 using spoofed packets. Receivers not capable of decoding such data 453 items are not at risk; unknown data items are skipped over and 454 discarded according to SMPTE 336M processing rules. 456 9. References 458 9.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 464 Jacobson, "RTP: A Transport Protocol for Real-Time 465 Applications", STD 64, RFC 3550, July 2003. 467 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 468 Video Conferences with Minimal Control", STD 65, RFC 3551, 469 July 2003. 471 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 472 Registration Procedures", BCP 13, RFC 4288, December 2005. 474 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 475 Formats", RFC 4855, February 2007. 477 9.2. Informative References 479 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 480 Streaming Protocol (RTSP)", RFC 2326, April 1998. 482 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 483 Announcement Protocol", RFC 2974, October 2000. 485 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 486 with Session Description Protocol (SDP)", RFC 3264, 487 June 2002. 489 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 490 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 491 RFC 3711, March 2004. 493 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 494 Internet Protocol", RFC 4301, December 2005. 496 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 497 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 499 [SMPTE298M] 500 Society of Motion Picture and Television Engineers, "ANSI/ 501 SMPTE 298M-1997: Universal Labels for Unique 502 Identification of Digital Data", 1997, 503 . 505 [SMPTE335M] 506 Society of Motion Picture and Television Engineers, "SMPTE 507 335M-2001: Metadata Dictionary Structure", 2001, 508 . 510 [SMPTE336M] 511 Society of Motion Picture and Television Engineers, 512 "SMPTE336M-2007: Data Encoding Protocol Using Key-Length- 513 Value", 2007, . 515 [SMPTE377M] 516 Society of Motion Picture and Television Engineers, "SMPTE 517 377M-2004: Material Exchange Format (MXF) File Format 518 Specification", 2004, . 520 [SMPTERP210] 521 Society of Motion Picture and Television Engineers, "SMPTE 522 RP 210v12: Metadata Dictionary Registry of Metadata 523 Element Descriptions", 2010, . 525 Authors' Addresses 527 J. Downs (editor) 528 PAR Government Systems Corp. 529 US 531 Phone: 532 Email: jeff_downs@partech.com 533 J. Arbeiter (editor) 534 US 536 Phone: 537 Email: jimsgti@gmail.com