A Real-time Transport Protocol (RTP) Classifier Header Extension
draft-carlberg-avtext-classifier-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ken Carlberg | ||
| Last updated | 2013-10-17 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-carlberg-avtext-classifier-00
AVTEXT Working Group K. Carlberg
Internet-Draft G11
Intended Status: Standards Track Oct 14, 2013
Expires: April 14, 2014
A Real-time Transport Protocol (RTP) Classifier Header Extension
draft-carlberg-avtext-classifier-00
Abstract
This document defines a new RTP header extension. The purpose of the
extension is to provide additional information that further
distinguishes the RTP datagram (and its payload) from other datagrams
containing the same type of payload. The information may be used by
application layer gateways to drop packets, or place them in a lower
priority outbound queue. Or, through deep packet inspection,
information stored in the classifier header extension may be used to
(re)set diff-serv code points set in the IP header that may be have
reset at ingress/egress boundaries of a diff-serv domain.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Carlberg Expires April 14, 2014 [Page 1]
Internet Drafts Classifier Extension Header for RTP Oct 14, 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This document defines a new RTP Header extension. The purpose of the
extension it to provide additional information that distinguishes the
RTP datagram (and its payload) from other datagrams containing the same
type of payload. This distinction can be viewed as a generalized
abbreviation of the significance of the payload.
It is important to note that this document uses the term classification,
NOT priority, in distinguishing payloads. This is because the word
priority tends to convey a definitive importance of the packet, as well
as an expected Quality of Service (QoS). In addition, the concept of
priority may be different on aper application or per user community
basis. Hence, local policy is required to determine the relationship of
various classifications. This policy may be associated with the
administrative policy defined for a domain. The form, support of, and
dissemination of local policy is outside the scope of this document.
Another advantage in appending a classifier extension to the RTP header
is that it provides a means by which a forwarding node aquires
information from the source without the need to breach confidentiality
(through the use of Secure RTP) or support of the codec used to produce
the RTP payload.
1.2 Terminology and Abbreviations
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 RFC2119 [RFC2119].
2. Related Work
There have been several efforts that have added classification, in the
more narrow scope of priority to other applications. These efforts
include: (1) a Resource Priority Header in the Session Initiation
Protocol (SIP) [rfc4412] and (2) a priority extension for the Simple Mail
Transfer Protocol (SMTP) [rfc6710].
In each of these examples, the priority classification was accomplished
by dividing the solution space into two parts. The first identified a
namespace associated with the set of priorities. The second part
identified the specific priority. Initial example values would be
defined in the respective RFC, while future values would be placed in a
registry maintained by IANA. The advantage in using this two-part
Carlberg Expires April 14, 2014 [Page 2]
Internet Drafts Classifier Extension Header for RTP Oct 14, 2013
solution was that various "communities of interest" had the freedom to
define the form of the classification (in their case, priority) and the
number of classifications. In addition, the registry provided a common
place where various vendors and user groups could access and agree on a
single set of values that assisted in interopability.
3. Classifier Header Extension
The classifier header extension for RTP is divided into two parts: a
Namespace entry and a Value entry. This information is carried in an
RTP header extension element as by "A General Mechanism for RTP Header
Extensions" [rfc5285].
The payload of the classifier header extension element can be encoded
using either the one-byte or two-byte header defined in [RFC5285].
Figures 1 and 2 show sample audio level encodings with each of these
header formats.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=1 | Namespace | Value | 0 (pad) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Classifier Using the One-Byte Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Len=2 | Namespace | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Classifier Using the Two-Byte Header
3.1 Example A
Authors note: There have been recent discussions in the Transport
Services working group (TSVWG) on the relative importance of different
types of payloads. There has also been recent work concerning the
mapping of diff-serv code points related to RTP payloads. In both of
these cases, the focus has been with the characteristics of specific
types of applications.
On the other hand, and as discussed above in section 2, previous related
work has gravitated to supporting classifications (specifically,
priorities) based on a user community. One can easily observe that
these are two different and possibly divergent motivations in adding
classification information to an RTP payload. A question to the
Carlberg Expires April 14, 2014 [Page 3]
Internet Drafts Classifier Extension Header for RTP Oct 14, 2013
community is should both interests be supported by a new RTP classifier
header?
Examples exist in the case of Namespaces correlating to a user
community. This section shoulw, at a minimum, present an example
Namespace that correpates to eitehr a specific application or a set of
applications. A question to the community is whether the latter can be
achieved since it would reduce the number of Namespaces that would need
to be supported by implementors.
4. IANA Considerations
At present, this section is listed as To Be Done. Eventually, a
description and statement requirement of a registry will need to be
described.
5. Security Considerations
To Be Done
6. Acknowledgements
An earlier work-in-progress related effort concerning the specification
of a classifier extension header for RTP was presented to the IETF
community in 2002. The author thanks James Polk and Dave Oran for
earlier discussions on this topic. The author also thanks Toerless
Eckert and Cheng-Jai Lai for recent discussion on the topic.
7. References
7.1 Normative
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc5285] Singer, D., et. al., "A General Mechanism for RTP
Header Extensions", RFC 5285, IETF, July 2008
7.2 Informative
[rfc4412] Schulzrinne, H., J. Polk, "Communications Resource
Priority for the Session Inititiation Protocol (SIP)"
RFC 4412, IETF, Feb 2006
[rfc6710] Melnikov, A., K. Carlberg, "Simple Mail Transfer
Protocol Extension for Message Transfer Priorities",
Carlberg Expires April 14, 2014 [Page 4]
Internet Drafts Classifier Extension Header for RTP Oct 14, 2013
RFC 6710, IETF, Aug 2012
Author's Addresses
Ken Carlberg
G11
1600 Clarendon Blvd
Arlington VA
USA
Email: carlberg@g11.org.uk
Carlberg Expires April 14, 2014 [Page 5]