idnits 2.17.00 (12 Aug 2021) /tmp/idnits32419/draft-carlberg-avtext-classifier-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 38 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Oct 21, 2013) is 3127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT Working Group Ken Carlberg 3 INTERNET-DRAFT G11 4 Intended Status: Standards Track Toerless Eckert 5 Expires: April 21, 2014 Cisco 6 Oct 21, 2013 8 A Real-time Transport Protocol (RTP) Classifier Header Extension 9 draft-carlberg-avtext-classifier-01 11 Abstract 13 This document defines a new RTP header extension. The purpose of the 14 extension is to provide additional information that further 15 distinguishes the RTP datagram (and its payload) from other datagrams 16 containing the same type of payload. The information may be used to 17 assist functions performed by application layer gateways (such as 18 Session Border Controller or MCUs) and/or by routers/switches through 19 deep packet inspection. Examples of these functions include intelligent 20 dropping of packets or (re)setting the IP header diff-serv code points 21 at ingress/egress boundaries of a diff-serv domain. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the provisions 26 of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering Task 29 Force (IETF). Note that other groups may also distribute working 30 documents as Internet-Drafts. The list of current Internet-Drafts is 31 at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference material 36 or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 14, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 46 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 47 effect on the date of publication of this document. Please review these 48 documents carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this document 50 must include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 This document defines a new RTP Header extension. The purpose of the 57 extension it to provide additional information that distinguishes the 58 RTP datagram (and its payload) from other datagrams containing the same 59 type of payload. This distinction can be viewed as a generalized 60 abbreviation of the significance of the payload. 62 It is important to note that this document uses the term classification, 63 NOT priority, in distinguishing payloads. This is because the word 64 priority tends to convey a definitive importance of the packet, as well 65 as an expected Quality of Service (QoS). In addition, the concept of 66 priority may be different on per-application or per-user community 67 basis. Hence, local policy is required to determine the relationship of 68 various classifications. This policy may be associated with the 69 administrative policy defined for a domain. The form, support of, and 70 dissemination of local policy is outside the scope of this document. 72 Another advantage in appending a classifier extension to the RTP header 73 is that it provides a means by which a forwarding node acquires 74 information from the source without the need to breach confidentiality 75 (through the use of Secure RTP) or support of the codec used to produce 76 the RTP payload. 78 1.2 Terminology and Abbreviations 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC2119 [rfc2119]. 84 2. Related Work 86 There have been several efforts that have added classification, in the 87 more narrow scope of priority to other applications. These efforts 88 include: (1) a Resource Priority Header in the Session Initiation 89 Protocol (SIP) [rfc4412] and (2) a priority extension for the Simple 90 Mail Transfer Protocol (SMTP) [rfc6710], and (3) a priority policy 91 element for the Resource Reservation Protocol (RSVP) [rfc6401]. 93 In each of these examples, the priority classification was accomplished 94 by dividing the solution space into two parts. The first identified a 95 namespace associated with the set of priorities. The second part 96 identified the specific priority. Initial example values would be 97 defined in the respective RFC, while future values would be placed in a 98 registry maintained by IANA. The advantage in using this two-part 99 solution was that various "communities of interest" had the freedom to 100 define the form of the classification (in their case, priority) and the 101 number of classifications. In addition, the registry provided a common 102 place where various vendors and user groups could access and agree on a 103 single set of values that assisted in interoperability. 105 3. Classifier Header Extension 107 The classifier header extension for RTP is divided into two parts: a 108 Namespace entry and a Value entry. This information is carried in an 109 RTP header extension element as by "A General Mechanism for RTP Header 110 Extensions" [rfc5285]. 112 The payload of the classifier header extension element can be encoded 113 using either the one-byte or two-byte header defined in [rfc5285] and 114 shown below in Figure 1 and 2 below. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | ID | len=1 | Namespace | Value | 0 (pad) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: Classifier Using the One-Byte Header 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | ID | len=2 | Namespace | Value | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 2: Classifier Using the Two-Byte Header 132 Author's notes: There have been recent discussions in the Transport 133 Services working group (TSVWG) on the relative importance of different 134 types of payloads. There has also been recent work concerning the 135 mapping of diff-serv code points related to RTP payloads. In both of 136 these cases, the focus has been with the characteristics of specific 137 types of applications. 139 On the other hand, and as discussed above in section 2, previous related 140 work has gravitated to supporting classifications (specifically, 141 priorities) based on a user community. One can easily observe that 142 these are two different and possibly divergent motivations in adding 143 classification information to an RTP payload. A question to the 144 community is should both interests be supported by a new RTP classifier 145 header? (the author's position is yes) 147 Examples exist in the case of Namespaces correlating to a user 148 community. This section should, at a minimum, present an example 149 Namespace that correlates to either a specific application or a set of 150 applications. Another question to the community is whether the latter 151 can be achieved since it would reduce the number of Namespaces that 152 would need to be supported by implementors. The author's position is 153 that this could be achieved by having a Namespace and set of values that 154 correspond to the existing set of defined differentiated services code 155 points. As such, we recommend a Namespace assigned to a per-hop 156 behaviour (e.g., the AFxx set of code points) 158 Finally, we anticipate the possibility that two sets of users groups may 159 choose to inject their own classifier information: one that corresponds 160 to hop-by-hop forwarding, and the other at the destination end-point. 161 However, we should encourage a minimalistic approach and discourage more 162 than two (namespace, value) entries. 164 3.1 Example: AF Namespace 166 TBD 168 4. SDP Signaling 170 TBD 172 5. IANA Considerations 174 At present, this section is listed as To Be Done. Eventually, a 175 description and statement requirement of a registry will be needed. 177 6. Security Considerations 179 To Be Done 181 7. Acknowledgements 183 An earlier work-in-progress related effort concerning the specification 184 of a classifier extension header for RTP was presented to the IETF 185 community in 2002. The author thanks James Polk and Dave Oran for 186 earlier discussions on this topic. The authors also thanks Cheng-Jai 187 Lai for recent discussion on the topic. 189 8. References 191 8.1 Normative 193 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, March 1997. 196 [rfc5285] Singer, D., et. al., "A General Mechanism for RTP 197 Header Extensions", RFC 5285, IETF, July 2008 199 8.2 Informative 201 [rfc4412] Schulzrinne, H., J. Polk, "Communications Resource 202 Priority for the Session Inititiation Protocol (SIP)" 203 RFC 4412, IETF, Feb 2006 204 [rfc6401] Le Faucher, F, et al, "RSVP Extensions for Admission 205 Priority", RFC 6401, IETF, Oct 2011 207 [rfc6710] Melnikov, A., K. Carlberg, "Simple Mail Transfer 208 Protocol Extension for Message Transfer Priorities", 209 RFC 6710, IETF, Aug 2012 211 Author?s Addresses 213 Ken Carlberg 214 G11 215 Arlington VA 216 USA 218 Email: carlberg@g11.org.uk 220 Toerless Eckert 221 Cisco Systems, Inc. 222 San Jose 223 USA 225 Email: eckert@cisco.com