Internet Engineering Task Force Ken Carlberg INTERNET DRAFT UCL October 4, 2001 The Classifier Extension Header for RTP 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]