Internet DRAFT - draft-carlberg-rtp-classifier-extension
draft-carlberg-rtp-classifier-extension
Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT UCL
October 4, 2001
The Classifier Extension Header for RTP
<draft-carlberg-rtp-classifier-extension-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This document describes a new RTP header extension. The purpose of
the extension is to provide an additional information that further
distinguishes the RTP datagram (and its payload) from other datagrams
containing the same type of payload. Specifically, a classifier
field is defined in the extension header that contains value such as
"emergency". RTP compliant implementations that do not recognize the
classifier extension header must continue to process the packet and
not take no adverse action. Criteria for inserting the values in the
classifier header, and any QoS treatment of the packet based on those
values, is outside the scope of this specification.
1. Introduction
This document describes a new RTP header extension. The purpose of
the extension is to provide an additional information that further
Carlberg Expires April 4, 2002 [Page 1]
Internet Draft Classifier Extension October 4, 2001
distinguishes the RTP datagram (and its payload) from other datagrams
containing the same type of payload. Specifically, our goal is to be
able to mark packets with different types of classifications, such as
emergency versus normal.
It is important to note that we use 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). QoS, and how it is
achieved by the network is outside the scope of this document. The
fact that one can distinguish a packet in the same way as one
distinguishes applications or payloads does not automatically mean
that a different measure of QoS will exist per classification.
Rather, the classification provides a specific marking so that other
mechanisms MAY take additional action, depending on what has been
defined for the network or host/server via statically configured
information, Service Level Agreements (SLA), and/or policies.
1.1 Background: RTP
The Real-Time Transport Protocol (RTP) provides end-to-end delivery
services for data with real-time characteristics. The type of data
is generally in the form of audio or video type applications, and are
frequently interactive in nature. RTP is typically run over UDP and
has been designed with a fixed header that identifies a specific type
of payload -- typically representing a specific form of application
media.
The designers of RTP also assumed an underlying network providing
best effort service. As such, RTP does not provide any mechanism to
ensure timely delivery or provide other QoS guarantees. Nor, in its
current form, does RTP provide any field distinguishing one set of
payloads from another.
2. Motivation & Scope
The service offerings of the Internet, and many of its protocol
building blocks, have evolved since the initial specification of
RTP/RTCP. The emergence of IP telephony and the associated on-going
work in protocols like SIP [5], and indirectly related work like
differentiated services [4], traffic engineering, and congestion
avoidance, have shown the introduction of services beyond that of
just best effort. In addition, [2, 3] have raised the issue of an
additional axis of emergency status of flows in addition to simply
the type of application generating the traffic onto a network.
The purpose of this document is to define a new header extension for
both RTP and RTCP packets in order to be able to add additional
Carlberg Expires April 4, 2002 [Page 2]
Internet Draft Classifier Extension October 4, 2001
distinction to the payloads that are being sent end-to-end.
The initial motivation to add additional classifier information to an
RTP/RTCP packet is so that is so that applications can distinguish a
flow as being associated with or sent as a result of an emergency.
The actions taken by intermediate or end nodes based on additional
classification information are outside the scope of this document.
Use of this extension is optional. The application decides whether
to use the extension for RTP and/or RTCP.
3. "Classifier" Header Extension
This section defines a new header extension for RTP and RTCP. The
new extension value is termed the "Classifier".
3.1 RTP
The format of the fixed portion of the RTP header, including a newly
defined header extension, is shown below. A detailed description of
each field of the fixed header is found in [1]. The existance of the
header extension means that field "M" is set to "1".
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Extension Type | Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | Reserved | Classifier | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+----RTP "Classifier" Header Extension |
Fixed RTP Header----+
Carlberg Expires April 4, 2002 [Page 3]
Internet Draft Classifier Extension October 4, 2001
Extension Type: 16 bits
The Extension Type field identifies the type of extension to
be added to the RTP header. As stated in [1], only a single
extension is allowed to be appended to the RTP data header.
To date, there are no pre-existing defined extensions. A
value of one (1) shall be requested from IANA and assigned as
a "Classifier" value.
Length: 16 bits
The length field contains the number of 32-bit words in the
extension. The four-octet fixed extension header (which
includes the Extension-Type and Length fields) is excluded
from the count. Since the Classifier header extension
includes two 16-bit fields, the value stored in the Length
field is one (1).
Reserved: 16 bits
This field is reserved for future use. Eventhough the value
stored in this field must be ignored because it has no
significance, it should be set to zero (0).
Classifier: 16 bits
The Classifier field contains a value that defines additional
classification of the RTP data packet. Currently, we define
the following values for this field:
Zero (0) - Normal
One (1) - Authorized Emergency
Two (2) - General Emergency
Three (3) - Urgent
Four (4) - Non-Urgent
The "Normal" value correlates to best effort traffic and is
synonymous with RTP without the new extension field defined
by this document. It can be expected that this value will
not be used, but it is included for the sake of completeness.
The "Authorized Emergency" indicates that the packet is part of
a flow that has been generated by an application/user sending
data that has been authorized in some way to do so. The means
of the authorization is outside the scope of this document.
Background on this type of emergency servcie can be found in
[2].
The "Urgent" and "Non-Urgent" values are included for
compatibility with the priority values defined in SIP.
Author's Note: Do we want to add other classifications, such
as those defined for MLPP [3]?
Carlberg Expires April 4, 2002 [Page 4]
Internet Draft Classifier Extension October 4, 2001
3.2 RTCP
In the case of RTCP packets, a new source description (SDES) type is
defined to reflect the classifier values defined above in section
3.1. While the ability exists to define an extension for RTCP, it is
felt that the definition of a new SDES type is easier and more in
line with the existing best practice associated with RTCP.
The format of the new SDES type and associated values is shown below.
A detailed description of each field of the RTCP header is found in
[1].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CLASSIFIER=10 | length=2 | classifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CLASSIFIER: 8 bits
The Classifier SDES identifier represents a value indicating
that the following session has an additional classifier for
the RTCP packet. The length field is a fixed value of 2
(correlating to the length value defined in section 3.1 for
RTP packets). The classifier values defined in this document
are:
Zero (0) - Normal
One (1) - Authorized Emergency
Two (2) - General Emergency
Three (3) - Urgent
Four (4) - Non-Urgent
The "Normal" value correlates to best effort traffic and is
synonymous with RTP without the new extension field defined
by this document. It can be expected that this value will
not be used, but it is included for the sake of completeness.
The "Authorized Emergency" indicates that the packet is part of
a flow that has been generated by an application/user sending
data that has been authorized in some way to do so. The means
of the authorization is outside the scope of this document.
Background on this type of emergency servcie can be found in
[2].
The "Urgent" and "Non-Urgent" values are included for
compatibility with the priority values defined in SIP.
Carlberg Expires April 4, 2002 [Page 5]
Internet Draft Classifier Extension October 4, 2001
4. Issues
This draft defines an extension that provides additional
classification to RTP/RTCP packets. The objective is to add this
additional coloring of packets with minimal impact on existing
implementations and no changes required in currently defined
payloads. However, as noted by Colin Perkins, extensions may
adversely affect header compression for those implementations that
are not expecting an extra four octets in RTP packets.
4.1 Security Issues
RTP Packets using the header extension defined in this specification
are subject to the security considerations discussed in the RTP
specification [1]. This implies that confidentiality of the media
streams is achieved by encryption.
Since this specification centers on additional classification of an
RTCP/RTCP packet, the potential exists for denial of service if
special consideration is placed on specific classifications (e.g.,
authorized emergency).
It is recomended that if special consideration is placed on
"emergency" related payloads by intermediate or end nodes, then the
procedures and considerations presented in [6] should be followed.
In addition, it is recommended that [5] should be used by end nodes
sending traffic augmented with the classifier field over the
Internet, as opposed to closed private networks.
5. Acknowledgements
Grateful acknowledgement is passed along to Colin Perkins for his
initial review of this draft, helpful suggestions, and observations.
6. References
[1] Schulzrinne, H., et. al., "RTP: A Transport Protocol for Real-
Time Applications", IETF Request For Comments RFC 1889.
[2] Carlberg, K., Brown, I., "Framework for Supporting IEPS in IP
Telephony", work in progress, IETF Internet Draft, July, 2001
[3] Polk, J., "SIP Extension for MLPP", work in progress, IETF
Internet Draft, March, 2001
Carlberg Expires April 4, 2002 [Page 6]
Internet Draft Classifier Extension October 4, 2001
[4] Blake, S., et. al., "An Architecture for Differentiated
Service", IETF Request For Comments 2475, Dec. 1998.
[5] Handley, M., et. al., "SIP: Session Initiation Protocol", work
in progress, IETF Internet Draft, July, 2001
[6] Blom, R., "The Secure Real Time Transport Protocol", work in
progress, IETF Internet Draft, July, 2001
7. Author's Addresses
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
Carlberg Expires April 4, 2002 [Page 7]
