One document matched: draft-ietf-payload-rtp-klv-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- Based on template draft-davies-template-bare.xml -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml">
<!ENTITY RFC2974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4855 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
I-Ds might want to use. (Here they are set differently than their
defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-payload-rtp-klv-04" ipr="trust200902">
<front>
<title abbrev="RTP Format for SMPTE 336M Data">RTP Payload Format for SMPTE 336M Encoded Data</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="J. Downs" initials="J.D." role="editor"
surname="Downs">
<organization>PAR Government Systems Corp.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>US</country>
</postal>
<phone></phone>
<email>jeff_downs@partech.com</email>
</address>
</author>
<author fullname="J. Arbeiter" initials="J.A." role="editor"
surname="Arbeiter">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>US</country>
</postal>
<phone></phone>
<email>jimsgti@gmail.com</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month
for you. If the year is not the current one, it is necessary to
specify at least a month (xml2rfc assumes day="1" if not specified
for the purpose of calculating the expiry date). With drafts it is
normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Real-time Applications and Infrastructure</area>
<workgroup>Payload Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>RTP</keyword>
<keyword>KLV</keyword>
<keyword>SMPTE</keyword>
<keyword>336M</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document specifies the payload format for packetization
of KLV (Key-Length-Value) Encoded Data, as defined by the Society of
Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into
the Real-time Transport Protocol (RTP).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies the payload format for packetization
of KLV (Key-Length-Value) Encoded Data, as defined by the Society of
Motion Picture and Television Engineers (SMPTE) in
<xref target="SMPTE336M"/>, into the Real-time Transport
Protocol (RTP) <xref target="RFC3550"/>.
</t>
<t>
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 used.
</t>
<t>
A brief description of SMPTE 336M, KLV Encoded Data, is given.
The payload format itself, including use of the RTP header fields, is
specified in <xref target="payloadfmt"/>. The media type and IANA
considerations are also described. This document concludes with
security considerations relevant to this payload format.
</t>
</section>
<section title="Conventions, Definitions and Acronyms">
<t>
The term "Universal Label Key" is used in this document to refer to
a fixed-length, 16-byte SMPTE-administered Universal Label (see
<xref target="SMPTE298M"/>) that is used as an identifying key
in a KLV item.
</t>
<t>
The term "KLV item" is used in this document to refer to one single
Universal Label Key, length, and value triplet
encoded as described in <xref target="SMPTE336M"/>.
</t>
<t>
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 <xref
target="RFC2119"/>.
</t>
</section>
<section title="Media Format Background">
<t>
<xref target="SMPTE336M"/>, Data Encoding Protocol Using
Key-Length-Value, defines a byte-level data encoding protocol for
representing data items and data groups. This encoding protocol
definition is independent of the application or transportation
method used.
</t>
<t>
SMPTE 336M data encoding can be applied to a wide variety of binary
data. This encoding has been used to provide diverse and rich
metadata sets that describe or enhance associated video
presentations. Use of SMPTE 336M encoded metadata in conjunction
with video has enabled improvements in multimedia presentations,
content management and distribution, archival and retrieval, and
production workflow.
</t>
<t>
The SMPTE 336M standard defines a Key-Length-Value (KLV) triplet as
a data interchange protocol for data items or data groups where the
Key identifies the data, the Length specifies the length of the data
and the Value is the data itself. The KLV protocol provides a
common interchange point for all compliant applications irrespective
of the method of implementation or transport.
</t>
<t>
The Key of a KLV triplet (a Universal Label Key)
is coded using a fixed-length 16-byte
SMPTE-administered Universal Label. <xref target="SMPTE298M"/>
further details the structure of 16-byte SMPTE-administered
Universal Labels. Universal Label Keys are maintained in
registries published by SMPTE (see, for example,
<xref target="SMPTE335M"/> and <xref target="SMPTERP210"/>).
</t>
<t>
The standard also provides methods for combining associated KLV
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 form (Universal Sets) or in one of four increasingly
bit-efficient forms (Global Sets, Local Sets, Variable Length Packs
and Defined Length Packs). The standard provides a definition of
each of these data constructs.
</t>
<t>
Additionally, the standard defines the use of KLV coding to provide
a means to carry information that is registered with a non-SMPTE
external agency.
</t>
</section>
<section title="Payload Format" anchor="payloadfmt">
<t>
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
manner. All forms of SMPTE 336M data can be carried by the payload
format. The payload format maintains simplicity by using only the
standard RTP headers and not defining any payload headers.
</t>
<t>
SMPTE 336M KLV data is broken into KLVunits. A KLVunit is simply a
logical grouping of otherwise unframed KLV data, grouped based on
source data timing (see <xref target="klvunit"/>). Each KLVunit is
then placed into one or more RTP packet payloads. The RTP header
marker bit is used to assist receivers in locating the boundaries of
KLVunits.
</t>
<section title="RTP Header Usage" anchor="rtpheader">
<t>
This payload format uses the RTP packet header fields as
described in the table below:
</t>
<texttable>
<ttcol align="left">Field</ttcol>
<ttcol align="left">Usage</ttcol>
<c>
Timestamp
</c>
<c>
The RTP Timestamp encodes the instant along a presentation
timeline that the entire KLVunit encoded in the packet payload
is to be presented. When one KLVunit is placed in multiple
RTP packets, the RTP timestamp of all packets comprising that
KLVunit MUST be the same.
The timestamp clock frequency is
defined as a parameter to the <xref target="payloadformat">
payload format</xref>.
</c>
<c>
M-bit
</c>
<c>
The RTP header marker bit (M) is used to demarcate KLVunits.
Senders MUST set the marker bit to '1' for any RTP packet which
contains the final byte of a KLVunit. For all other packets,
senders MUST set the RTP header marker bit to '0'.
This allows receivers to pass a KLVunit for
parsing/decoding immediately upon receipt of the last RTP packet
comprising the KLVunit. Without this, a receiver would need
to wait for the next RTP packet with a
different timestamp to arrive, thus signaling the end of one
KLVunit and the start of another.
</c>
</texttable>
<t>
The remaining RTP header fields are used as specified in
<xref target="RFC3550"/>.
</t>
</section>
<section title="Payload Data">
<section anchor="klvunit" title="The KLVunit">
<t>
A KLVunit is a logical collection of all KLV items that are to be
presented at a specific time. A KLVunit is comprised of one or
more KLV items. Compound items (sets, packs) are allowed as per
<xref target="SMPTE336M"/>, but the contents of a compound item
MUST NOT be split across two KLVunits. Multiple KLV items in a
KLVunit occur one after another with no padding or stuffing
between items.
</t>
</section>
<section anchor="klvunit_mapping"
title="KLVunit Mapping to RTP Packet Payload">
<t>
An RTP packet payload SHALL contain one, and only one, KLVunit
or a fragment thereof. KLVunits small enough to fit into a single
RTP packet (RTP packet size is up to implementation but should
consider underlying transport/network factors such as MTU
limitations) are placed directly into the payload of the RTP
packet, with the first byte of the KLVunit (which is the first
byte of a KLV Universal Label Key) being the first byte of the RTP
packet payload.
</t>
<t>
KLVunits too large to fit into a single RTP packet payload MAY
span multiple RTP packet payloads. When this is done, the
KLVunit data MUST be sent in sequential byte order, such that
when all RTP packets comprising the KLVunit are arranged in
sequence number order, concatenating the payload data together
exactly reproduces the original KLVunit.
</t>
<t>
Additionally, when a KLVunit is fragmented across multiple RTP
packets, all RTP packets transporting the fragments of a KLVunit
MUST have the same timestamp.
</t>
<t>
KLVunits are bounded with changes in RTP packet timestamps. The
marker (M) bit in the RTP packet headers marks the last RTP
packet comprising a KLVunit (see <xref target="rtpheader"/>).
</t>
</section>
</section>
<section title="Implementation Considerations">
<section anchor="loss_of_data" title="Loss of Data">
<t>
RTP is generally deployed in network environments where packet
loss might occur. RTP header fields enable detection of lost
packets, as described in <xref target="RFC3550"/>. When
transmitting payload data described by this payload format,
packet loss can cause the loss of whole KLVunits or portions
thereof.
</t>
<section title="Damaged KLVunits">
<t>
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 use of the sequence number header field),
the receiver:
<list style="symbols">
<t>
MUST consider the KLVunit partially received before a lost
packet as damaged. This damaged KLVunit includes all packets
prior to the lost one (in 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'.
</t>
<t>
MUST consider the first KLVunit received after a lost
packet as damaged. This damaged KLVunit includes the first
packet after the lost one (in sequence number order) and,
if the first packet has its M-bit in the RTP header is set
to '0', all subsequent packets up to and including the next
one with the M-bit in the RTP header set to '1'.
</t>
</list>
</t>
<t>
The above applies regardless of the M-bit value in the RTP
header of the lost packet itself. This enables very basic
receivers to look solely at the M-bit to determine the outer
boundaries of damaged KLVunits. For example, when a packet
with the M-bit set to '1' is lost, the KLVunit that the lost
packet would have terminated is considered damaged, as is the
KLVunit comprised of packets received subsequent to the lost
packet (up to and including the next received packet with M-bit
set to '1').
</t>
<t>
The example below illustrates how a receiver would handle a
lost packet in another possible packet sequence:
<figure>
<artwork>
<![CDATA[
+---------+-------------+ +--------------+
| RTP Hdr | Data | | |
+---------+-------------+ +--------------+
.... | ts = 30 | KLV KLV ... | | | >---+
| M = 1 | | | | |
| seq = 5 | ... KLV KLV | | | |
+---------+-------------+ +--------------+ |
Last RTP pkt for time 30 Lost RTP Pkt |
(seq = 6) |
|
+--------------------------------------------------------+
|
| +---------+-------------+ +---------+-------------+
| | RTP Hdr | Data | | RTP Hdr | Data |
| +---------+-------------+ +---------+-------------+
+--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+
| M = 0 | | | M = 1 | | |
| seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | |
+---------+-------------+ +---------+-------------+ |
RTP pkt for time 45 Last RTP pkt for time 45 |
KLVunit carried in these two packets is "damaged" |
|
+----------------------------------------------------------------+
|
| +---------+-------------+
| | RTP Hdr | Data |
| +---------+-------------+
+--> | ts = 55 | KLV KLV ... | ....
| M = 1 | |
| seq = 9 | ... KLV ... |
+---------+-------------+
Last and only RTP pkt
for time 55
]]>
</artwork>
</figure>
In this example, the packets with sequence numbers 7 and 8
contain portions of a KLVunit with timestamp of 45. This
KLVunit is considered "damaged" due to the missing RTP packet
with sequence number 6, which might have been part of this
KLVunit. The KLVunit for timestamp 30 (ended in packet with
sequence number 5) is unaffected by the missing packet. The
KLVunit for timestamp 55, carried in the packet with sequence
number 9, is also unaffected by the missing packet and is
considered complete and intact.
</t>
</section>
<section title="Treatment of Damaged KLVunits">
<t>
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
stream. Exact specifics of how damaged KLVunits are handled
are left to each implementation, as different implementations
can have differing capabilities and robustness in their
downstream KLV payload processing. Because some
implementations can be particularly limited in their capacity
to handle damaged KLVunits, receivers MAY drop damaged
KLVunits entirely.
</t>
</section>
</section>
</section>
</section>
<section title="Congestion Control">
<t>
The general congestion control considerations for transporting RTP
data apply; see RTP <xref target="RFC3550"/> and any applicable
RTP profile like AVP <xref target="RFC3551"/>.
</t>
<t>
Further, SMPTE 336M data can be encoded in different schemes which
reduce the overhead associated with individual data items within the
overall stream. SMPTE 336M grouping constructs, such as local sets
and data packs, provide a mechanism to reduce bandwidth requirements.
</t>
</section>
<section title="Payload Format Parameters" anchor="payloadformat">
<t>
This RTP payload format is identified using the
application/smpte336m media type which is registered in accordance
with <xref target="RFC4855"/> and using the template of
<xref target="RFC4288"/>.
</t>
<section title="Media Type Definition" anchor="mediatype">
<t>
<list style="empty">
<t>Type name: application</t>
<t>Subtype name: smpte336m</t>
<t>Required parameters:
<list style="empty">
<t>
rate: RTP timestamp clock rate. Typically chosen based
on sampling rate of metadata being transmitted, but
other rates can be specified.
</t>
</list>
</t>
<t>Optional parameters: None</t>
<t>
Encoding considerations: This media type is framed and
binary; see Section 4.8 of <xref target="RFC4288"/>.
</t>
<t>
Security considerations: See <xref target="security"/>
of RFC&rfc.number; (note to RFC editor: please replace XXXX
with the number assigned to this RFC).
</t>
<t>
Interoperability considerations: Data items in smpte336m
can be very diverse. Receivers might only be capable of
interpreting a subset of the possible data items; unrecognized
items are skipped. Agreement on data items to be used out of
band, via application profile or similar, is typical.
</t>
<t>Published specification: RFC&rfc.number;</t>
<t>
Applications that use this media type: Streaming of metadata
associated with simultaneously streamed video and transmission
of <xref target="SMPTE336M"/> based media formats (e.g. MXF <xref
target="SMPTE377M"/>).
</t>
<t>Additional Information: none</t>
<t>
Person & email address to contact
for further information: J. Downs
<jeff_downs@partech.com>; IETF Payload Working Group
<payload@ietf.org></t>
<t>Intended usage: COMMON</t>
<t>
Restrictions on usage: This media type depends on RTP framing,
and hence is only defined for transfer via RTP
(<xref target="RFC3550"/>). Transport within other framing
protocols is not defined at this time.
</t>
<t>
Author:
<list style="empty">
<t>J. Downs <jeff_downs@partech.com></t>
<t>J. Arbeiter <jimsgti@gmail.com></t>
</list>
</t>
<t>
Change controller: IETF Payload working
group delegated from the IESG.
</t>
</list>
</t>
</section>
<section title="Mapping to SDP">
<t>
The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of
<xref target="RFC4855"/>.
</t>
<section title="Offer/Answer Model and Declarative Considerations">
<t>
This payload format has no configuration or optional format
parameters. Thus, when offering SMPTE 336M Encoded Data over
RTP using Session Description Protocol (SDP) in an Offer/Answer
model <xref target="RFC3264"/>
or in a declarative manner (e.g., SDP in the Real-time Streaming
Protocol (RTSP) <xref target="RFC2326"/> or the Session
Announcement Protocol (SAP) <xref target="RFC2974"/>), there are
no specific considerations.
</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>
This memo requests that IANA registers application/smpte336m as
specified in <xref target="mediatype"/>.
The media type is also requested to be added to
the IANA registry for "RTP Payload Format MIME types"
(http://www.iana.org/assignments/rtp-parameters).
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification <xref target="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 encryption of the RTP payload. Integrity of the RTP
packets through suitable cryptographic integrity protection
mechanism. Cryptographic systems 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 or not.
</t>
<t>
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP <xref target="RFC3711"/> is recommended.
Other mechanisms that may be used are IPsec <xref target="RFC4301"/>
and TLS <xref target="RFC5246"/> (RTP over TCP), but
also other alternatives may exist.
</t>
<t>
This RTP payload format presents the possibility for significant
non-uniformity in the receiver-side computational complexity during
processing of SMPTE 336M payload data. Because the length of
SMPTE 336M encoded data items is essentially unbounded, receivers
must take care when allocating resources used in processing.
It is trivial to construct pathological data that would cause
a naive decoder to allocate large amounts of resources, resulting
in denial-of-service threats. Receivers SHOULD place
limits on resource allocation that are within the bounds set forth
by any application profile in use.
</t>
<t>
This RTP payload format does not contain any inherently active
content. However, individual SMPTE 336M KLV items could be defined
to convey active content in a particular application. Therefore,
receivers capable of decoding and interpreting such data items
should use appropriate caution and security practices. In
particular, accepting active content from streams that lack
authenticity or integrity protection mechanisms places a receiver at
risk of attacks using spoofed packets. Receivers not capable of
decoding such data items are not at risk; unknown data items are
skipped over and discarded according to SMPTE 336M processing rules.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3550;
&RFC3551;
&RFC4288;
&RFC4855;
</references>
<references title="Informative References">
&RFC2326;
&RFC2974;
&RFC3264;
&RFC3711;
&RFC4301;
&RFC5246;
<reference anchor="SMPTE298M"
target="http://www.smpte.org">
<front>
<title>
ANSI/SMPTE 298M-1997: Universal Labels for Unique Identification
of Digital Data
</title>
<author>
<organization>Society of Motion Picture and Television Engineers
</organization>
</author>
<date year="1997" />
</front>
</reference>
<reference anchor="SMPTE335M"
target="http://www.smpte.org">
<front>
<title>SMPTE 335M-2001: Metadata Dictionary Structure</title>
<author>
<organization>Society of Motion Picture and Television Engineers
</organization>
</author>
<date year="2001" />
</front>
</reference>
<reference anchor="SMPTE336M"
target="http://www.smpte.org">
<front>
<title>SMPTE336M-2007: Data Encoding Protocol Using Key-Length-Value</title>
<author>
<organization>Society of Motion Picture and Television Engineers
</organization>
</author>
<date year="2007" />
</front>
</reference>
<reference anchor="SMPTE377M"
target="http://www.smpte.org">
<front>
<title>SMPTE 377M-2004: Material Exchange Format (MXF) File Format
Specification</title>
<author>
<organization>Society of Motion Picture and Television Engineers
</organization>
</author>
<date year="2004" />
</front>
</reference>
<reference anchor="SMPTERP210"
target="http://www.smpte.org">
<front>
<title>SMPTE RP 210v12: Metadata Dictionary Registry of
Metadata Element Descriptions</title>
<author>
<organization>Society of Motion Picture and Television Engineers
</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:06 |