draft-ietf-payload-rtp-klv-02.txt   draft-ietf-payload-rtp-klv-03.txt 
Payload Working Group J. Downs, Ed. Payload Working Group J. Downs, Ed.
Internet-Draft PAR Government Systems Corp. Internet-Draft PAR Government Systems Corp.
Intended status: Standards Track J. Arbeiter, Ed. Intended status: Standards Track J. Arbeiter, Ed.
Expires: July 12, 2012 January 9, 2012 Expires: August 4, 2012 February 1, 2012
RTP Payload Format for SMPTE 336M Encoded Data RTP Payload Format for SMPTE 336M Encoded Data
draft-ietf-payload-rtp-klv-02 draft-ietf-payload-rtp-klv-03
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 33 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 July 12, 2012. This Internet-Draft will expire on August 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 4, line 40 skipping to change at page 4, line 40
application 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. A KLVunit is simply a
on source data timing. Each KLVunit is then placed into one or more logical grouping of otherwise unframed KLV data, grouped based on
RTP packet payloads. The RTP header marker bit is used to assist source data timing (see Section 4.2.1). Each KLVunit is then placed
receivers in locating the boundaries of KLVunits. into one or more RTP packet payloads. The RTP header marker bit is
used to assist receivers in locating the boundaries of KLVunits.
4.1. RTP Header Usage 4.1. RTP Header Usage
This payload format uses the RTP packet header fields as described in This payload format uses the RTP packet header fields as described in
the table below: the table below:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Field | Usage | | Field | Usage |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Timestamp | The RTP Timestamp encodes the instant along a | | Timestamp | The RTP Timestamp encodes the instant along a |
skipping to change at page 6, line 15 skipping to change at page 6, line 15
comprising the KLVunit are arranged in sequence number order, comprising the KLVunit are arranged in sequence number order,
concatenating the payload data together exactly reproduces the concatenating the payload data together exactly reproduces the
original KLVunit. original KLVunit.
Additionally, when a KLVunit is fragmented across multiple RTP Additionally, when a KLVunit is fragmented across multiple RTP
packets, all RTP packets transporting the fragments a KLVunit MUST packets, all RTP packets transporting the fragments a KLVunit MUST
have the same timestamp. have the same timestamp.
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). A receiver MUST consider a
KLVunit to be completed when it receives either a packet with M=1 or
a packet with a new timestamp. In the former case, the packet
payload is included in the completed KLVunit; in the latter case, it
is not.
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
might 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.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
also other alternatives may exist. also other alternatives may exist.
This RTP payload format presents the possibility for significant non- This RTP payload format presents the possibility for significant non-
uniformity in the receiver-side computational complexity during uniformity in the receiver-side computational complexity during
processing of SMPTE 336M payload data. Because the length of SMPTE processing of SMPTE 336M payload data. Because the length of SMPTE
336M encoded data items is essentially unbounded, receivers must take 336M encoded data items is essentially unbounded, receivers must take
care when allocating resources used in processing. It is trivial to care when allocating resources used in processing. It is trivial to
construct pathological data that would cause a naive decoder to construct pathological data that would cause a naive decoder to
allocate large amounts of resources, resulting in denial-of-service allocate large amounts of resources, resulting in denial-of-service
threats. Receivers are encouraged to place limits on resource threats. Receivers SHOULD place limits on resource allocation that
allocation that are within the bounds set forth by any application are within the bounds set forth by any application profile in use.
profile in use.
This RTP payload format does not contain any inheritly active This RTP payload format does not contain any inheritly active
content. However, individual SMPTE 336M KLV items could be defined content. However, individual SMPTE 336M KLV items could be defined
to convey active content in a particular application. Therefore, to convey active content in a particular application. Therefore,
receivers capable of decoding and interpreting such data items should receivers capable of decoding and interpreting such data items should
use appropriate caution and security practices. Receivers not use appropriate caution and security practices. In particular,
capable of decoding such data items are not at risk; unknown data accepting active content from streams that lack authenticity or
items are skipped over and discarded according to SMPTE 336M integrity proteciton mechanisms places a receiver at risk to attacks
processing rules. 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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
 End of changes. 7 change blocks. 
15 lines changed or deleted 21 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/