draft-ietf-payload-rtp-klv-00.txt   draft-ietf-payload-rtp-klv-01.txt 
Payload Working Group J. Arbeiter, Ed. Payload Working Group J. Downs, Ed.
Internet-Draft Harris Corporation Internet-Draft PAR Government Systems Corp.
Intended status: Standards Track J. Downs, Ed. Intended status: Standards Track J. Arbeiter, Ed.
Expires: December 3, 2011 PAR Government Systems Corp. Expires: December 17, 2011 June 15, 2011
June 1, 2011
RTP Payload Format for SMPTE 336M Encoded Data RTP Payload Format for SMPTE 336M Encoded Data
draft-ietf-payload-rtp-klv-00 draft-ietf-payload-rtp-klv-01
Abstract Abstract
This document specifies the payload format for packetization of KLV This document specifies the payload format for packetization of KLV
(Key-Length-Value) Encoded Data, as defined by the Society of Motion (Key-Length-Value) Encoded Data, as defined by the Society of Motion
Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Picture and Television Engineers (SMPTE) in SMPTE 336M, into the
Real-time Transport Protocol (RTP). Real-time Transport Protocol (RTP).
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2011. This Internet-Draft will expire on December 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5 4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5
4.3. Implementation Considerations . . . . . . . . . . . . . . 6 4.3. Implementation Considerations . . . . . . . . . . . . . . 6
4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6
4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6 4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6
4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 7 4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 7
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8
6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Offer/Answer Model and Declarative Considerations . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document specifies the payload format for packetization of KLV This document specifies the payload format for packetization of KLV
(Key-Length-Value) Encoded Data, as defined by the Society of Motion (Key-Length-Value) Encoded Data, as defined by the Society of Motion
Picture and Television Engineers (SMPTE) in [SMPTE336M], into the Picture and Television Engineers (SMPTE) in [SMPTE336M], into the
Real-time Transport Protocol (RTP) [RFC3550]. Real-time Transport Protocol (RTP) [RFC3550].
The payload format is defined in such a way that arbitrary KLV data The payload format is defined in such a way that arbitrary KLV data
can be carried. No restrictions are placed on which KLV data keys can be carried. No restrictions are placed on which KLV data keys
skipping to change at page 4, line 16 skipping to change at page 4, line 16
The standard also provides methods for combining associated KLV The standard also provides methods for combining associated KLV
triplets in data sets where the set of KLV triplets is itself coded triplets in data sets where the set of KLV triplets is itself coded
with KLV data coding protocol. Such sets can be coded in either full with KLV data coding protocol. Such sets can be coded in either full
form (Universal Sets) or in one of four increasingly bit-efficient form (Universal Sets) or in one of four increasingly bit-efficient
forms (Global Sets, Local Sets, Variable Length Packs and Defined forms (Global Sets, Local Sets, Variable Length Packs and Defined
Length Packs). The standard provides a definition of each of these Length Packs). The standard provides a definition of each of these
data constructs. data constructs.
The standard also describes implications of KLV coding including the The standard also describes implications of KLV coding including the
use of a SMPTE Universal Label as a value within a KLV coding triplet use of a SMPTE Universal Label (UL) as a value within a KLV coding
or whose meaning is entirely conveyed by the SMPTE UL itself. The triplet or whose meaning is entirely conveyed by the SMPTE UL itself.
two kinds of usage for such standalone SMPTE Universal Labels are a) The two kinds of usage for such standalone SMPTE ULs are a) as a
as a value in a K L V construct and b) as a Key that has no Length value in a KLV construct and b) as a Key that has no Length and no
and no Value. Value.
The standard also defines the use of KLV coding to provide a means to The standard also defines the use of KLV coding to provide a means to
carry information that is registered with a non-SMPTE external carry information that is registered with a non-SMPTE external
agency. agency.
The encoding byte range (length of the payload) may accommodate The encoding byte range (length of the payload) can accommodate
unusually large volumes of data. Consequently, a specific unusually large volumes of data. Consequently, a specific
application of KLV encoding may require only a limited operating data application of KLV encoding might require only a limited operating
range and those details shall be defined in a relevant application data range and those details shall be defined in a relevant
document. application document.
4. Payload Format 4. Payload Format
The main goal of the payload format design for SMPTE 336M data is to The main goal of the payload format design for SMPTE 336M data is to
provide carriage of SMPTE 336M data over RTP in a simple, yet robust provide carriage of SMPTE 336M data over RTP in a simple, yet robust
manner. All forms of SMPTE 336M data can be carried by the payload manner. All forms of SMPTE 336M data can be carried by the payload
format. The payload format maintains simplicity by using only the format. The payload format maintains simplicity by using only the
standard RTP headers and not defining any payload headers. standard RTP headers and not defining any payload headers.
SMPTE 336M KLV data is broken into KLVunits (see Section 4.2.1) based SMPTE 336M KLV data is broken into KLVunits (see Section 4.2.1) based
skipping to change at page 6, line 22 skipping to change at page 6, line 22
KLVunits are bounded with changes in RTP packet timestamps. The KLVunits are bounded with changes in RTP packet timestamps. The
marker (M) bit in the RTP packet headers marks the last RTP packet marker (M) bit in the RTP packet headers marks the last RTP packet
comprising a KLVunit (see Section 4.1). comprising a KLVunit (see Section 4.1).
4.3. Implementation Considerations 4.3. Implementation Considerations
4.3.1. Loss of Data 4.3.1. Loss of Data
RTP is generally deployed in network environments where packet loss RTP is generally deployed in network environments where packet loss
may occur. RTP header fields enable detection of lost packets, as might occur. RTP header fields enable detection of lost packets, as
described in [RFC3550]. When transmitting payload data described by described in [RFC3550]. When transmitting payload data described by
this payload format, packet loss can cause the loss of whole KLVunits this payload format, packet loss can cause the loss of whole KLVunits
or portions thereof. or portions thereof.
4.3.1.1. Damaged KLVunits 4.3.1.1. Damaged KLVunits
A damaged KLVunit is any KLVunit that was carried in one or more RTP A damaged KLVunit is any KLVunit that was carried in one or more RTP
packets that have been lost. When a lost packet is detected (through packets that have been lost. When a lost packet is detected (through
use of the sequence number header field), the receiver: use of the sequence number header field), the receiver:
o SHOULD consider the KLVunit carried in the prior packet (in o MUST consider any KLVunit presently being received as damaged.
sequence number order) as damaged unless that prior packet's M bit The damaged KLVunit includes all packets prior to the lost one (in
in the RTP header was set to '1'. sequence number order) back to, but not including, the most recent
packet in which the M bit in the RTP header was set to '1'.
o SHOULD consider all subsequent packets (in sequence number order) o MUST consider all subsequent packets (in sequence number order) up
up to and including the next one with the M-bit in the RTP header to and including the next one with the M-bit in the RTP header set
set to '1' as part of a damaged KLVunit. to '1' as part of a damaged KLVunit.
The example below illustrates how a receiver would handle a lost The example below illustrates how a receiver would handle a lost
packet in one possible packet sequence: packet in one possible packet sequence:
+---------+-------------+ +--------------+ +---------+-------------+ +--------------+
| RTP Hdr | Data | | | | RTP Hdr | Data | | |
+---------+-------------+ +--------------+ +---------+-------------+ +--------------+
.... | ts = 30 | KLV KLV ... | | | >---+ .... | ts = 30 | KLV KLV ... | | | >---+
| M = 1 | | | | | | M = 1 | | | | |
| seq = 5 | ... KLV KLV | | | | | seq = 5 | ... KLV KLV | | | |
+---------+-------------+ +--------------+ | +---------+-------------+ +--------------+ |
Last RTP pkt for time 30 Lost RTP Pkt | Last RTP pkt for time 30 Lost RTP Pkt |
For time 30 (seq = 6) | (seq = 6) |
| |
+--------------------------------------------------------+ +--------------------------------------------------------+
| |
| +---------+-------------+ +---------+-------------+ | +---------+-------------+ +---------+-------------+
| | RTP Hdr | Data | | RTP Hdr | Data | | | RTP Hdr | Data | | RTP Hdr | Data |
| +---------+-------------+ +---------+-------------+ | +---------+-------------+ +---------+-------------+
+--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+ +--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+
| M = 0 | | | M = 1 | | | | M = 0 | | | M = 1 | | |
| seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | | | seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | |
+---------+-------------+ +---------+-------------+ | +---------+-------------+ +---------+-------------+ |
skipping to change at page 7, line 42 skipping to change at page 7, line 42
+--> | ts = 55 | KLV KLV ... | .... +--> | ts = 55 | KLV KLV ... | ....
| M = 1 | | | M = 1 | |
| seq = 9 | ... KLV ... | | seq = 9 | ... KLV ... |
+---------+-------------+ +---------+-------------+
Last and only RTP pkt Last and only RTP pkt
for time 55 for time 55
In this example, the packets with sequence numbers 7 and 8 contain In this example, the packets with sequence numbers 7 and 8 contain
portions of a KLVunit with timestamp of 45. This KLVunit is portions of a KLVunit with timestamp of 45. This KLVunit is
considered "damaged" due to the missing RTP packet with sequence considered "damaged" due to the missing RTP packet with sequence
number 6, which may have been part of this KLVunit. The KLVunit for number 6, which might have been part of this KLVunit. The KLVunit
timestamp 30 (ended in packet with sequence number 5) is unaffected for timestamp 30 (ended in packet with sequence number 5) is
by the missing packet. The KLVunit for timestamp 55, carried in the unaffected by the missing packet. The KLVunit for timestamp 55,
packet with sequence number 9, is also unaffected by the missing carried in the packet with sequence number 9, is also unaffected by
packet and is considered complete and intact. the missing packet and is considered complete and intact.
4.3.1.2. Treatment of Damaged KLVunits 4.3.1.2. Treatment of Damaged KLVunits
SMPTE 336M KLV data streams are built in such a way that it is SMPTE 336M KLV data streams are built in such a way that it is
possible to partially recover from errors or missing data in a possible to partially recover from errors or missing data in a
stream. Exact specifics of how damaged KLVunits are handled are left stream. Exact specifics of how damaged KLVunits are handled are left
to each implementation, as different implementations may have to each implementation, as different implementations can have
differing capabilities and robustness in their downstream KLV payload differing capabilities and robustness in their downstream KLV payload
processing. Because some implementations may be particularly limited processing. Because some implementations can be particularly limited
in their capacity to handle damaged KLVunits, receivers MAY drop in their capacity to handle damaged KLVunits, receivers MAY drop
damaged KLVunits entirely. damaged KLVunits entirely.
5. Congestion Control 5. Congestion Control
The general congestion control considerations for transporting RTP The general congestion control considerations for transporting RTP
data apply; see RTP [RFC3550] and any applicable RTP profile like AVP data apply; see RTP [RFC3550] and any applicable RTP profile like AVP
[RFC3551]. [RFC3551].
Further, SMPTE 336M data can be encoded in different schemes which Further, SMPTE 336M data can be encoded in different schemes which
skipping to change at page 8, line 38 skipping to change at page 8, line 38
6.1. Media Type Definition 6.1. Media Type Definition
Type name: application Type name: application
Subtype name: smpte336m Subtype name: smpte336m
Required parameters: Required parameters:
rate: RTP timestamp clock rate. Typically chosen based on rate: RTP timestamp clock rate. Typically chosen based on
sampling rate of metadata being transmitted, but other rates sampling rate of metadata being transmitted, but other rates
may be specified. can be specified.
Optional parameters: Optional parameters: None
Encoding considerations: This media type is framed and binary; see Encoding considerations: This media type is framed and binary; see
Section 4.8 of [RFC4288]. Section 4.8 of [RFC4288].
Security considerations: See Section 8 of RFCXXXX. Security considerations: See Section 8 of RFCXXXX (note to RFC
editor: please replace XXXX with the number assigned to this RFC).
Interoperability considerations: Data items in smpte336m can be Interoperability considerations: Data items in smpte336m can be
very diverse. Receivers may only be capable of interpreting a very diverse. Receivers might only be capable of interpreting a
subset of the possible data items; unrecognized items are skipped. subset of the possible data items; unrecognized items are skipped.
Agreement on data items to be used out of band, via application Agreement on data items to be used out of band, via application
profile or similar, is typical. profile or similar, is typical.
Published specification: RFCXXXX Published specification: RFCXXXX
Applications that use this media type: Audio and video streaming Applications that use this media type: Streaming of metadata
and conferencing tools associated with simultaneously streamed video and transmission of
[SMPTE336M] based media formats (e.g. MXF [SMPTE377M]).
Additional Information: none Additional Information: none
Person & email address to contact for further information: J. Person & email address to contact for further information: J.
Arbeiter <jarbeite@harris.com> Downs <jeff_downs@partech.com>; IETF Payload Working Group
<payload@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP ([RFC3550]). Transport hence is only defined for transfer via RTP ([RFC3550]). Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Author:
J. Arbeiter <jarbeite@harris.com>
J. Downs <jeff_downs@partech.com> J. Downs <jeff_downs@partech.com>
Change controller: IETF Audio/Video Transport working group J. Arbeiter <jimsgti@gmail.com>
delegated from the IESG.
Change controller: IETF Payload working group delegated from the
IESG.
6.2. Mapping to SDP 6.2. Mapping to SDP
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of [RFC4855]. parameters SHALL be done according to Section 3 of [RFC4855].
6.2.1. Offer/Answer Model and Declarative Considerations
This payload format has no configuration or optional format
parameters. Thus, when offering SMPTE 336M Encoded Data over RTP
using SDP in an Offer/Answer model [RFC3264] or in a declarative
manner (e.g., SDP in the Real-time Streaming Protocol (RTSP)
[RFC2326] or the Session Announcement Protocol (SAP) [RFC2974]),
there are no specific considerations.
7. IANA Considerations 7. IANA Considerations
This memo requests that IANA registers application/smpte336m as This memo requests that IANA registers application/smpte336m as
specified in Section 6.1. The media type is also requested to be specified in Section 6.1. The media type is also requested to be
added to the IANA registry for "RTP Payload Format MIME types" added to the IANA registry for "RTP Payload Format MIME types"
(http://www.iana.org/assignments/rtp-parameters). (http://www.iana.org/assignments/rtp-parameters).
8. Security Considerations 8. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
skipping to change at page 11, line 17 skipping to change at page 11, line 30
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[SMPTE336M] [SMPTE336M]
SMPTE, "SMPTE336M-2007: Data Encoding Protocol Using Key- Society of Motion Picture and Television Engineers,
Length-Value", 2007, <http://www.smpte.org>. "SMPTE336M-2007: Data Encoding Protocol Using Key-Length-
Value", 2007, <http://www.smpte.org>.
9.2. Informative References 9.2. Informative References
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SMPTE377M]
Society of Motion Picture and Television Engineers,
"SMPTE377M-2004: Material Exchange Format (MXF) File
Format Specification", 2004, <http://www.smpte.org>.
Authors' Addresses Authors' Addresses
J. Arbeiter (editor) J. Downs (editor)
Harris Corporation PAR Government Systems Corp.
US US
Phone: Phone:
Email: jarbeite@harris.com Email: jeff_downs@partech.com
J. Downs (editor) J. Arbeiter (editor)
PAR Government Systems Corp.
US US
Phone: Phone:
Email: jeff_downs@partech.com Email: jimsgti@gmail.com
 End of changes. 32 change blocks. 
55 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/