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]