AVTEXT Working Group                                Ken Carlberg
INTERNET-DRAFT                                      G11
Intended Status: Standards Track                    Toerless Eckert
Expires: April 21, 2014                             Cisco
                                                    Oct 21, 2013

    A Real-time Transport Protocol (RTP) Classifier Header Extension


   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 to
   assist functions performed by application layer gateways (such as
   Session Border Controller or MCUs) and/or by routers/switches through
   deep packet inspection. Examples of these functions include intelligent
   dropping of packets or (re)setting the IP header diff-serv code points
   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

Carlberg                            Expires April 21, 2014      [Page 1]

Internet Drafts    Classifier Extension Header for RTP      Oct 21, 2013

   documents carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this document
   must 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 per-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 acquires
   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",
   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], and (3) a priority policy
   element for the Resource Reservation Protocol (RSVP) [rfc6401].

   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

Carlberg                            Expires April 21, 2014      [Page 2]

Internet Drafts    Classifier Extension Header for RTP      Oct 21, 2013

   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
   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 interoperability.

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] and
   shown below in Figure 1 and 2 below.

      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

   Author's notes: 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

Carlberg                            Expires April 21, 2014      [Page 3]

Internet Drafts    Classifier Extension Header for RTP      Oct 21, 2013

   classification information to an RTP payload.  A question to the
   community is should both interests be supported by a new RTP classifier
   header? (the author's position is yes)

   Examples exist in the case of Namespaces correlating to a user
   community.  This section should, at a minimum, present an example
   Namespace that correlates to either a specific application or a set of
   applications.  Another 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.  The author's position is
   that this could be achieved by having a Namespace and set of values that
   correspond to the existing set of defined differentiated services code
   points.  As such, we recommend a Namespace assigned to a per-hop
   behaviour (e.g., the AFxx set of code points)

   Finally, we anticipate the possibility that two sets of users groups may
   choose to inject their own classifier information: one that corresponds
   to hop-by-hop forwarding, and the other at the destination end-point.
   However, we should encourage a minimalistic approach and discourage more
   than two (namespace, value) entries.

3.1 Example: AF Namespace


4. SDP Signaling


5.  IANA Considerations

   At present, this section is listed as To Be Done.  Eventually, a
   description and statement requirement of a registry will be needed.

6.  Security Considerations

   To Be Done

7. 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 authors also thanks Cheng-Jai
   Lai for recent discussion on the topic.

Carlberg                            Expires April 21, 2014      [Page 4]

Internet Drafts    Classifier Extension Header for RTP      Oct 21, 2013

8.  References

8.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

8.2 Informative

   [rfc4412] Schulzrinne, H., J. Polk, "Communications Resource
             Priority for the Session Inititiation Protocol (SIP)"
             RFC 4412, IETF, Feb 2006
   [rfc6401] Le Faucher, F, et al, "RSVP Extensions for Admission
             Priority", RFC 6401, IETF, Oct 2011

   [rfc6710] Melnikov, A., K. Carlberg, "Simple Mail Transfer
             Protocol Extension for Message Transfer Priorities",
             RFC 6710, IETF, Aug 2012

Author?s Addresses

   Ken Carlberg
   Arlington  VA

   Email: carlberg@g11.org.uk

   Toerless Eckert
   Cisco Systems, Inc.
   San Jose

   Email: eckert@cisco.com

Carlberg                            Expires April 21, 2014      [Page 5]