idnits 2.17.1 draft-ietf-mmusic-traffic-class-for-sdp-04.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 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC5194' is mentioned on line 569, but not defined == Unused Reference: 'RFC5865' is defined on line 1262, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Subha Dhesikan 4 Expires: January 14, 2014 Paul Jones 5 Intended Status: Standards Track (PS) Cisco Systems 6 July 14, 2013 8 The Session Description Protocol (SDP) 'trafficclass' Attribute 9 draft-ietf-mmusic-traffic-class-for-sdp-04 11 Abstract 13 This document proposes a new Session Description Protocol (SDP) 14 attribute to identify the traffic class a session is requesting 15 in its offer/answer exchange. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 14, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Traffic Class Framework and Component Definitions . . . . . . 5 53 3. Traffic Class Attribute Definition . . . . . . . . . . . . . 6 54 3.1 Categories within the SDP Traffic Class Label . . . . . . 8 55 3.2 Applications within the SDP Traffic Class Label . . . . . 9 56 3.3 Adjectives within the SDP Traffic Class Label . . . . . . 9 57 3.3.1 Qualified Adjectives . . . . . . . . . . . . . . . . . 9 58 4. Matching Categories with Applications and Adjectives . . . . 11 59 4.1 Conversational Category Traffic Class . . . . . . . . . . 11 60 4.2 Multimedia-Conferencing Category Traffic Class . . . . . 12 61 4.3 Realtime-Interactive Category Traffic Class . . . . . . . 14 62 4.4 Multimedia-Streaming Category Traffic Class . . . . . . . 15 63 4.5 Broadcast Category Traffic Class . . . . . . . . . . . . 17 64 4.6 Intermittent Category Traffic Class . . . . . . . . . . . 18 65 5. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 19 66 5.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 20 67 5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 20 68 6. Security considerations . . . . . . . . . . . . . . . . . . . 21 69 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 9.1. Normative References . . . . . . . . . . . . . . . . . 25 73 9.2. Informative References . . . . . . . . . . . . . . . . 26 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 75 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 1. Introduction 83 The Session Description Protocol (SDP) [RFC4566] provides a means 84 for an offerer to describe the specifics of a session to an 85 answerer, and for the answerer to respond back with its session 86 specifics to the offerer. These session specifics include offering 87 the codec or codecs to choose from, the specific IP address and port 88 number the offerer wants to receive the RTP stream(s) on/at, the 89 particulars about the codecs the offerer wants considered or 90 mandated, and so on. 92 There are many facets within SDP to determine the Real-time 93 Transport Protocol (RTP) [RFC3550] details for the session 94 establishment between one or more endpoints, but identifying how the 95 underlying network should process each stream still remains 96 under-specified. 98 The ability to identify a traffic flow by port number gives an 99 indication to underlying network elements to treat traffic with 100 dissimilar ports in a different way, the same or in groups the same 101 - but different from other ports or groups of ports. 103 Within the context of realtime communications, the labeling of an 104 RTP session based on media descriptor lines as just a voice and/or 105 video session is insufficient, and provides no guidelines to the 106 underlying network on how to treat the traffic. A more granular 107 labeling helps on several fronts to 109 - inform application layer elements in the signaling path the 110 intent of this session. 112 - inform the network on how to treat the traffic if the network is 113 configured to differentiate session treatments based on the type 114 of session the RTP is, including the ability to provide call 115 admission control based on the type of traffic in the network. 117 - allow network monitoring/management of traffic types realtime and 118 after-the-fact analysis. 120 Some network operators want the ability to guarantee certain traffic 121 gets a minimum amount of network bandwidth per link or through a 122 series of links that make up a network such as a campus or WAN, or a 123 backbone. For example, a call center voice application might get at 124 least 20% of the available link bandwidth. 126 Some network operators want the ability to allow certain users or 127 devices access to greater bandwidth during non-busy hours than 128 during busy hours of the day. For example, all desktop video might 129 operate at 1080p during non-peak times, but a similar session might 130 be curtailed between the same users or devices to 720p or 360p 131 during peak hours. Another example would be to reduce the frames 132 per second (fps) rate, say from 30fps to 15fps. This case is not as 133 clear as accepting or denying similar sessions during different 134 times of the day, but tuning the access to the bandwidth based on 135 the type of session. In other words, tune down the bandwidth for 136 desktop video during peak hours to allow a 3-screen Telepresence 137 session that would otherwise look like the same type of traffic 138 (RTP, and more granular, video). 140 RFC 4594 established a guideline for classifying the various flows 141 in the network and the Differentiated Services Codepoint (DSCP) 142 values that apply to many traffic types (table 3 of [RFC4594]), 143 including RTP based voice and video traffic sessions. The RFC also 144 defined the per hop network behavior that is strongly encouraged for 145 each of these application traffic types based on the traffic 146 characteristics and tolerances to delay, loss and jitter within each 147 traffic class. 149 Video was broken down into four categories in that RFC, and voice in 150 another single category. We do not believe this satisfies the 151 technical and business requirements to accomplish sufficiently 152 unique labeling of RTP traffic. 154 If the application becomes aware of traffic labeling, 156 - this can be coded into layer 3 mechanisms. 158 - this can be coded into layer 4 protocols and/or mechanisms. 160 - this can be coded into a combination of mechanisms and protocols. 162 The layer 3 mechanism for differentiating traffic is either the port 163 number or the Differentiated Services Codepoint (DSCP) value 164 [RFC2474]. Within the public Internet, if the application is not 165 part of a managed service, the DSCP value likely will be best effort 166 (BE), or reset to BE when ingressing a provider's network. Within 167 the corporate LAN, this is usually completely configurable and a 168 local IT department can take full advantage of this labeling to 169 shape and manage their network as they see fit. 171 Within a network core, DiffServ typically does not apply. That said, 172 DiffServ can be used to identify which traffic goes into which MPLS 173 tunnel [RFC4124]. 175 Labeling realtime traffic types using a layer 4 protocol would 176 likely involve RSVP [RFC2205] or NSIS [RFC4080]. RSVP has an 177 Application Identifier (app-ID) defined in [RFC2872] that provides a 178 means for carrying a traffic class label along the media path. An 179 advantage of this mechanism is that the label can inform each domain 180 along the media path what type of traffic this traffic flow is, and 181 allow each domain to adjust the appropriate DSCP value (set by each 182 domain for use within that domain). Meaning, if a DSCP value is set 183 by an endpoint or a router in the first domain and gets reset by a 184 service provider, the far-end domain will be able to reset the DSCP 185 value appropriate for the intended traffic class. There is a 186 proposed extension to RSVP which creates individual profiles for 187 what goes into each app-ID field to describe these traffic classes 188 [ID-RSVP-PROF], which will take advantage of what is described in 189 this document. 191 There are several proprietary mechanisms that can take advantage of 192 this labeling, but none of those will be discussed here. 194 The idea of traffic - or service - identification is not new; it has 195 been described in [RFC5897]. If that RFC is used as a guideline, 196 identification that leads to stream differentiation can be quite 197 useful. One of the points within RFC 5897 is that users cannot be 198 allowed to assign any identification (fraud is one reason given). In 199 addition, RFC 5897 recommends that service identification should be 200 done in signaling, rather than guessing or deep packet inspection. 202 Currently, any network would have to guess or perform deep 203 packet inspection to classify traffic and offer the service as per 204 RFC 4594 as such service identification information is currently 205 not available in SDP and therefore to the network elements. Since 206 SDP understands how each stream is created (i.e., the particulars of 207 the RTP stream), this is the right place to have this service 208 differentiated. Such service differentiation can then be 209 communicated to and leveraged by the network. 211 [Editor's Note: the words "traffic" and "service" are similar enough 212 that the above paragraph talks about RFC 5897's 213 "service identification", but this document only 214 discusses and proposes traffic indications in SDP.] 216 This document proposes a simple attribute line to identify the 217 application a session is requesting in its offer/answer exchange. 218 This document uses previously defined service class strings for 219 consistency between IETF documents. 221 This document modifies the traffic classes originally created in RFC 222 4594 in Section 2, incrementing each class with application 223 identifiers and optional adjective strings. Section 3 defines the 224 new SDP attribute "trafficclass". Section 4 discusses the offerer 225 and answerer behavior when generating or receiving this attribute. 227 2. Traffic Class Framework and Component Definitions 229 The framework of the traffic class attribute will have at least two 230 parts, called components, allowing for several more to be included 231 further distinguishing a particular session's traffic classification 232 from another session's traffic classification. The amount of 233 indicated differentiation between sessions is not a goal, and should 234 only have additional components for differentiation if there is a 235 need to uniquely identify traffic in different sessions. 237 The intention is to have a category component (e.g., conversational) 238 that identifies the traffic pattern for a session. Is the traffic 239 within a session one-way or two-way? Can the traffic be buffered 240 before reaching the destination or not? What is this session's 241 tolerance to packet loss and can there be retransmissions? 243 The application component (e.g., video) identifies the basic type of 244 traffic within a category. Is it media or data packets? If media, 245 which type of media? If data packets, which application of data 246 packets are in this session? 248 The optional adjective component(s) (e.g., immersive) help to 249 further refine the traffic within a session by providing more 250 description. For instance, if a session is two-way voice, what 251 additional information can be given about this particular session to 252 refine its description? Is it part of a conference or telepresence 253 session? Is it just standalone voice call? Has a capacity admission 254 protocol or mechanism been applied to this session? 256 The traffic class label will have the following structure, 258 category.application(.adjective)(.adjective)... 260 [Editor's Note: the above is not the exact ABNF to be used. 261 The order is right. The category and application 262 MUST appear first (each only once) and zero or more 263 adjectives can appear following the application 264 component.] 266 Where 267 1) the 1st component is the category, and is mandatory; 268 2) the 2nd component is the application, and is mandatory; 269 3) an optional 3rd component or series of components are 270 adjective(s) used to further refine the application component; 272 The construction of the traffic class label for Telepresence video 273 would follow the minimum form of: 275 conversational.video.immersive 277 where there might be one or more adjective after '.immersive'. 279 There is no traffic class or DSCP value associated with just 280 "conversational". There is a traffic class associated with 281 "conversational.video", creating a differentiation between it and a 282 "conversational.video.immersive" traffic class, which would have 283 DSCP associated with the latter traffic class, depending on local 284 policy. Each category component is defined below, as are several of 285 application and adjective strings. 287 3. Traffic Class Attribute Definition 289 This document proposes the 'trafficclass' session and media-level 290 SDP attribute. The following is the Augmented Backus-Naur Form 291 (ABNF) [RFC5234] syntax for this attribute, which is based on the 292 SDP [RFC4566] grammar: 294 attribute =/ traffic-class-label 296 traffic-class-label = "trafficclass" ":" [SP] category 297 "." application *( "." adjective ) 299 category = "broadcast" / 300 "realtime-interactive" / 301 "multimedia-conferencing" / 302 "multimedia-streaming" / 303 "conversational" / 304 "intermittent / tcl-token 306 application = tcl-token 308 adjective = classified-adjective / 309 unclassified-adjective 311 classified-adjective = tcl-token ":" tcl-token 313 unclassified-adjective = tcl-token 315 tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT ) 317 The attribute is named "trafficclass", for traffic classification, 318 identifying which one of the six categories applies to the 319 media stream associated with this m-line. There MUST NOT be more 320 than one category component per media line. 322 The categories in this document are an augmented version of the 323 application labels introduced by table 3 of RFC 4594 (which will be 324 rewritten based on the updated labels and treatments expected for 325 each traffic class defined in this document). 327 +-------------------------+------------------------------+ 328 | Application Labels | Category Classes Defined | 329 | Defined in RFC 4594 | in this document | 330 +=========================+==============================+ 331 | broadcast-video | broadcast | 332 +-------------------------+------------------------------+ 333 | realtime-interactive | realtime-interactive | 334 +-------------------------+------------------------------+ 335 | multimedia-conferencing | multimedia-conferencing | 336 +-------------------------+------------------------------+ 337 | multimedia-streaming | multimedia-streaming | 338 +-------------------------+------------------------------+ 339 | telephony | conversational | 340 +-------------------------+------------------------------+ 342 Figure 1. Label Differences from RFC 4594 344 As is evident from the changes above, from left to right, two labels 345 are different and each of the meanings are different in this 346 document relative to how RFC 4594 defined them. These differences 347 are articulated in Section 4 of this document. 349 Applications and adjectives are defined using the syntax of 350 "tcl-token" defined above. 352 RFC 4566 defined SDP as case sensitive. Everything is here as well. 354 An algorithm such as alphabetizing the list of components and 355 matching the understood strings SHOULD be used for determining the 356 traffic within a session. Strings not understood by an entity MUST 357 be ignored during processing, but MUST NOT be deleted. 359 Any category, application, or adjective string component within this 360 attribute that is not understood MUST be ignored, leaving all that 361 is understood to be processed. Ignored components SHOULD NOT be 362 deleted, as a downstream entity could understand the component(s) 363 and use it/them during processing. 365 The following is an example of media level description with a 366 'trafficclass' attribute: 368 m=video 50000 RTP/AVP 112 369 a=trafficclass conversational.video.immersive.aq:admitted 371 The above indicates the video part of a Telepresence session that 372 has had capacity admission process applied to its media flow. 374 3.1 Categories within the SDP Traffic Class Label 376 The category component within the traffic class attribute describes 377 the type of communication that will occur within that session. It 378 answers these questions, is the traffic 380 - one-way or two-or-more-way interactive? 382 - elastic or inelastic (as far as retransmissions)? 384 - buffered or (virtually) non-buffered? 386 - media or non-media (data)? 388 The six category components of the traffic class attribute defined 389 within this specification are as follows: 391 o conversational 392 o multimedia-conferencing 393 o realtime-interactive 394 o multimedia-streaming 395 o broadcast 396 o intermittent 398 Sections 4.1 through 4.6 define each of the above. 400 The category component MUST NOT be the only component present in a 401 traffic class attribute. The category component MUST BE paired with 402 an 'application' component to give enough meaning to the traffic 403 class labeling goal. 405 Not understanding the category component SHOULD mean that this 406 attribute is ignored, because of the information about the 407 expected behavior of this communication flow is identified by or 408 within that component. 410 3.2 Applications within the SDP Traffic Class Label 412 The application component identifies the application of a particular 413 traffic flow, for example, audio or video. The application types are 414 listed and defined in Section 2 of this document. Not every category 415 is paired with every application listed, at least as defined in this 416 document. One or more applications are inappropriate in one or more 417 categories. For example, iptv is a single directional traffic 418 application that is suited for the broadcast (one-way) category 419 rather than categories like realtime-interactive or conversational. 421 Section 4.1 through 4.6 list many of the expected combinations. 423 3.3 Adjectives within the SDP Traffic Class Label 425 For additional application type granularity, adjective components 426 can be added. One or more adjectives can be within the same traffic 427 class attribute to provide more differentiation. 429 It is important to note that while the order of component types 430 matter, the order of the adjective components do not. There might be 431 local significance to the ordering of adjectives though, such as 432 having a pattern matching algorithm in which labels are matched 433 exactly (i.e., the order matters), or not at all. In other words, 434 the category class component MUST be before the application 435 component, which MUST be before any and all adjective component(s). 437 There is no limit to the number of adjectives allowed. 439 Adjective components come in two versions, unqualified and 440 qualified. One has a prefix (qualified), the other (unqualified) 441 does not. A defined qualified adjective MUST NOT appear without its 442 qualifier name, even in future extensions to this specification. 443 Some implementations will likely perform a search within this 444 attribute for the presence of qualifiers, which might be as simple 445 as searching for the ":" COLON character. Implementations will be 446 confused with inconsistent coding, therefore strict adherence is 447 necessary. 449 3.3.1 Qualified Adjectives 451 Adjectives can be either unqualified or qualified. Qualified 452 adjectives have a delimiter ":" character between the "qualifier 453 name" and the "qualifier value". As one example, we introduce in 454 this specification the "admission qualifier" and it has a qualifier 455 name of "aq". We also define several possible qualifier values for 456 the admission qualifier, namely "admitted", "non-admitted", 457 "partial", and "none". When present in a TCL string, the qualified 458 adjectives look like these admission qualifier adjectives: 460 aq:admitted 461 aq:non-admitted 462 aq:partial 463 aq:none 465 Defining some adjectives as qualified adjectives allows entities 466 processing the traffic class label to potentially recognize a 467 particular qualifier name and act on it, even if it does not 468 understand the qualifier value. In the future, a new admission 469 qualifier value might be defined, e.g. "foo", and entities could at 470 least recognize the admission qualifier adjective, even if it did 471 not understand the qualifier value "foo". 473 Like all adjectives, it is OPTIONAL to include the admission 474 qualifier adjective in any trafficclass attribute. 476 The admission qualifier and its qualifier values are defined as: 478 - aq - 'admission qualifier' - this is the qualifier name for 479 the admission qualifier adjectives, wherein the 480 following qualifier values indicate the admission 481 status for the traffic flow described by this m-line. 483 - admitted - capacity admission mechanisms or protocols are to be or 484 were used for the full amount of bandwidth in relation 485 to this m= line. 487 - non-admitted - capacity admission mechanisms or protocols were 488 attempted but failed in relation to this m= line. This 489 does not mean the flow described by this m= line 490 failed. It just failed to attain the capacity admission 491 mechanism or protocol necessary for a predictable 492 quality of service, and is likely to continue with only 493 a class of service marking or best effort. 495 - partial - capacity admission mechanisms or protocols are to be or 496 were used for the part of the amount of bandwidth in 497 relation to this m= line. All traffic above a certain 498 amount will have no capacity admission mechanisms 499 applied. In other words, there is more traffic sent 500 than was agreed to. The burden is on the sender and 501 receiver to deal with any sent and lost information. 503 - none - no capacity admission mechanisms or protocols are or 504 were attempted in relation to this m= line. 506 The default for any flow generated from an m-line not having a 507 trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be 508 the equivalent of 'aq:none', whether or not it is present. 510 4. Matching Categories with Applications and Adjectives 512 This section describes each component within this document, as well 513 as provides the combinations of categories and applications and 514 adjectives. Given that not every combination makes sense, we express 515 the limits here - which will be IANA registered. 517 4.1 Conversational Category Traffic Class 519 The "conversational" traffic class is best suited for applications 520 that require very low delay variation and generally intended to 521 enable realtime, bi-directional person-to-person or 522 multi-directional via an MCU communication. Conversational flows are 523 inelastic, and with few exceptions, use a UDP transport. 525 +--------------------------------------------------------------------+ 526 | Traffic Class | | Tolerance to | 527 | Name | Traffic Characteristics | Loss |Delay |Jitter| 528 |===============+===============================+======+======+======| 529 | | High priority, typically | Very | Very | Very | 530 |conversational | small packets (large video | Low | Low | Low | 531 | | frames produce large packets),| | | | 532 | | generally sustained high | | | | 533 | | packet rate, low inter-packet | | | | 534 | | transmission interval, | | | | 535 | | usually UDP framed in (S)RTP | | | | 536 +---------------+-------------------------------+------+------+------+ 538 Figure 2. Conversational Traffic Characteristics 540 The following application components are appropriate for use with 541 the Conversational category: 543 o audio (voice) 545 o video 547 o text (i.e., real-time text required by deaf users) 549 o multiplex (i.e., combined a/v streams) 551 With adjective substrings to the above 553 immersive (TP) - An interactive audio-visual communications 554 experience between remote locations, where the users enjoy a 555 strong sense of realism and presence between all participants 556 by optimizing a variety of attributes such as audio and video 557 quality, eye contact, body language, spatial audio, 558 coordinated environments and natural image size. 560 avconf - An interactive audio-visual communication experience 561 that is not immersive in nature, though can have a high 562 resolution video component. 564 text - a term for real-time transmission of text in 565 a character-by-character fashion for use in conversational 566 services, often as a text equivalent to voice-based 567 conversational services. Conversational text is defined in the 568 ITU-T Framework for multimedia services, Recommendation F.700 569 [RFC5194]. 571 Multiplex - an application wherein media of different forms (e.g., 572 audio and video) is multiplexed within the same media flow. 574 +----------------------+---------------------+---------------------+ 575 | Category | Application | Adjective | 576 +----------------------+---------------------+---------------------+ 577 | conversational | audio | immersive | 578 | | | avconf | 579 | | | aq:admitted | 580 | | | aq:non-admitted | 581 | | | aq:partial | 582 | | | aq:none | 583 | | | | 584 | | video | immersive | 585 | | | avconf | 586 | | | aq:admitted | 587 | | | aq:non-admitted | 588 | | | aq:partial | 589 | | | aq:none | 590 | | | | 591 | | text | aq:admitted | 592 | | | aq:non-admitted | 593 | | | aq:partial | 594 | | | aq:none | 595 | | | | 596 | | multiplex | aq:admitted | 597 | | | aq:non-admitted | 598 | | | aq:partial | 599 | | | aq:none | 600 +----------------------+---------------------+---------------------+ 602 Figure 3. Conversational Applications and Adjective Combinations 604 4.2 Multimedia-Conferencing Category Traffic Class 606 The "multimedia-conferencing" traffic class is best suited for 607 applications that are generally intended for communication between 608 human users, but are less demanding in terms of delay, packet loss, 609 and jitter than what conversational applications require. These 610 applications require low to medium delay and may have the ability to 611 change encoding rate (rate adaptive) or transmit data at varying 612 rates. 614 +--------------------------------------------------------------------+ 615 | Traffic Class | | Tolerance to | 616 | Name | Traffic Characteristics | Loss |Delay |Jitter| 617 |===============+===============================+======+======+======| 618 | multimedia- | Variable size packets, | Low | Low | Low | 619 | conferencing | Variable transmit interval, | - | - | - | 620 | | rate adaptive, reacts to |Medium|Medium|Medium| 621 | | loss, usually TCP-based | | | | 622 +---------------+-------------------------------+------+------+------+ 624 Figure 4. Multimedia Conferencing Traffic Characteristics 626 Multimedia-conferencing flows are not to be media based. Media 627 sessions use other categories. Multimedia-conferencing flows are 628 those data flows that are typically transmitted in parallel to 629 currently active media flows. For example, a two-way conference 630 session in which the users share a presentation. The presentation 631 part of that conference call uses the Multimedia-conferencing 632 category, whereas the audio and any video uses the conversational 633 category indication. 635 The following application components are appropriate for use 636 with the Multimedia-Conferencing category: 638 o application-sharing (that webex does or protocols like T.128) - 639 An application that shares the output of one or more running 640 applications or the desktop on a host. This can utilize 641 vector graphics, raster graphics or video. 643 o presentation-data - can be a series of still images or motion 644 video. 646 o whiteboarding - an application enabling the exchange of graphical 647 information including images, pointers and filled and 648 unfilled parametric drawing elements (points, lines, 649 polygons and ellipses). 651 o (RTP-based) file-transfer 653 o instant messaging 654 +----------------------+---------------------+---------------------+ 655 | Category | Application | Adjective | 656 +----------------------+---------------------+---------------------+ 657 | multimedia- | application-sharing | aq:admitted | 658 | conferencing | | aq:non-admitted | 659 | | | aq:partial | 660 | | | aq:none | 661 | | | | 662 | | whiteboarding | aq:admitted | 663 | | | aq:non-admitted | 664 | | | aq:partial | 665 | | | aq:none | 666 | | | | 667 | | presentation-data | aq:admitted | 668 | | | aq:non-admitted | 669 | | | aq:partial | 670 | | | aq:none | 671 | | | | 672 | | instant-messaging | aq:admitted | 673 | | | aq:non-admitted | 674 | | | aq:partial | 675 | | | aq:none | 676 | | | | 677 | | file-transfer | aq:admitted | 678 | | | aq:non-admitted | 679 | | | aq:partial | 680 | | | aq:none | 681 +----------------------+---------------------+---------------------+ 683 Figure 5. Multimedia Conferencing Applications and Adjective 684 Combinations 686 4.3 Realtime-Interactive Category Traffic Class 688 The "Realtime-Interactive" traffic class is intended for interactive 689 variable rate inelastic applications that require low jitter and 690 loss and very low delay. Many of the applications that use the 691 Realtime-Interactive category use TCP or SCTP, even gaming, because 692 lost packets is information that is still required - therefore it is 693 retransmitted. 695 +--------------------------------------------------------------------+ 696 | Traffic Class | | Tolerance to | 697 | Name | Traffic Characteristics | Loss |Delay |Jitter| 698 |===============+===============================+======+======+======| 699 | realtime- | Inelastic, mostly variable | Low | Very | Low | 700 | interactive | rate, rate increases with | | Low | | 701 | | user activity | | | | 702 +---------------+-------------------------------+------+------+------+ 704 Figure 6. Realtime Interactive Traffic Characteristics 706 The following application components are 707 appropriate for use with the Realtime-Interactive category: 709 o gaming - interactive player video games with other users on other 710 hosts (e.g., Doom) 712 o remote-desktop - controlling a remote node with local peripherals 713 (i.e., monitor, keyboard and mouse) 715 o telemetry - a communication that allows remote measurement and 716 reporting of information (e.g., post launch missile status or 717 energy monitoring) 719 With adjective substrings to the above 721 o virtual - To be used with the remote-desktop application component 722 specifically when the traffic is a virtual desktop similar to 723 an X-windows station, has no local hard drive, or is operating 724 an computer application with no local storage. 726 +----------------------+---------------------+---------------------+ 727 | Category | Application | Adjective | 728 +----------------------+---------------------+---------------------+ 729 | realtime-interactive | gaming | aq:admitted | 730 | | | aq:non-admitted | 731 | | | aq:partial | 732 | | | aq:none | 733 | | | | 734 | | remote-desktop | virtual | 735 | | | aq:admitted | 736 | | | aq:non-admitted | 737 | | | aq:partial | 738 | | | aq:none | 739 | | | | 740 | | telemetry | aq:admitted | 741 | | | aq:non-admitted | 742 | | | aq:partial | 743 | | | aq:none | 744 +----------------------+---------------------+---------------------+ 746 Figure 7. Realtime-Interactive Applications and Adjective 747 Combinations 749 4.4 Multimedia-Streaming Category Traffic Class 751 The "multimedia-streaming" traffic class is best suited for variable 752 rate elastic streaming media applications where a human is waiting 753 for output and where the application has the capability to react to 754 packet loss by reducing its transmission rate. 756 +--------------------------------------------------------------------+ 757 | Traffic Class | | Tolerance to | 758 | Name | Traffic Characteristics | Loss |Delay |Jitter| 759 |===============+===============================+======+======+======| 760 | multimedia- | Variable size packets, |Low - |Medium| High | 761 | streaming | elastic with variable rate |Medium|- High| | 762 | | | | | | 763 +---------------+-------------------------------+------+------+------+ 765 Figure 8. Multimedia Streaming Traffic Characteristics 767 The following application components are appropriate for use with 768 the Multimedia-Streaming category: 770 o audio (see Section 4.1) 772 o video (see Section 4.1) 774 o webcast - is a media file distributed over the Internet or 775 enterprise network using streaming media technology. 777 o multiplex (see Section 4.1) 779 The primary difference from the multimedia-streaming category and 780 the broadcast category is about the length of time for buffering. 781 Buffered streaming audio and/or video which are initiated by SDP, 782 and not HTTP. Buffering here can be from many seconds to hours, and 783 is typically at the destination end (as opposed to Broadcast 784 buffering which is minimal at the destination). The buffering aspect 785 is what differentiates this category class from the broadcast 786 category (which has minimal or no buffering). 788 +----------------------+---------------------+---------------------+ 789 | Category | Application | Adjective | 790 +----------------------+---------------------+---------------------+ 791 | multimedia-streaming | audio | aq:admitted | 792 | | | aq:non-admitted | 793 | | | aq:partial | 794 | | | aq:none | 795 | | | | 796 | | video | aq:admitted | 797 | | | aq:non-admitted | 798 | | | aq:partial | 799 | | | aq:none | 800 | | | | 801 | | webcast | live | 802 | | | aq:admitted | 803 | | | aq:non-admitted | 804 | | | aq:partial | 805 | | | aq:none | 806 | | | | 807 | | multiplex | aq:admitted | 808 | | | aq:non-admitted | 809 | | | aq:partial | 810 | | | aq:none | 811 +----------------------+---------------------+---------------------+ 813 Figure 9. Multimedia Streaming Applications and Adjective 814 Combinations 816 4.5 Broadcast Category Traffic Class 818 The "broadcast" traffic class is best suited for inelastic streaming 819 media Applications, which might have a 'wardrobe malfunction' delay 820 at or near the source but not typically at the destination, that may 821 be of constant or variable rate, requiring low jitter and very low 822 packet loss. 824 See Section 4.4 for the difference between Multimedia-Streaming and 825 Broadcast; it all has to do with buffering. 827 +--------------------------------------------------------------------+ 828 | Traffic Class | | Tolerance to | 829 | Name | Traffic Characteristics | Loss |Delay |Jitter| 830 |===============+===============================+======+======+======| 831 | broadcast | Constant and variable rate, | Very |Low - |Low - | 832 | | inelastic, generally | Low |Medium|Medium| 833 | | non-bursty flows, generally | | | | 834 | | sustained high packet rate, | | | | 835 | | low inter-packet transmission | | | | 836 | | interval, usually UDP framed | | | | 837 | | in (S)RTP | | | | 838 +---------------+-------------------------------+------+------+------+ 840 Figure 10. Broadcast Traffic Characteristics 842 The following application components are appropriate for use with 843 the Broadcast category: 845 o audio (see Section 4.1) 847 o video (see Section 4.1) 849 o iptv - is one-way television content that, instead of being 850 delivered through traditional broadcast and cable formats, 851 is received by the viewer through the technologies used for 852 computer networks. IPTV is can be service provider or 853 enterprise network based. 855 o multiplex (see Section 4.1) 856 With adjective substrings to the above: 858 o live (non-buffered) - refers to various types of media broadcast 859 without a significant delay, typically measured in 860 milliseconds to a few seconds only. 862 o surveillance - one way audio from a microphone or video from a 863 camera (e.g., observing a parking lot or building exit), 864 typically enabled for long periods of time, usually stored 865 at the destination. 867 +----------------------+---------------------+---------------------+ 868 | Category | Application | Adjective | 869 +----------------------+---------------------+---------------------+ 870 | broadcast | audio | surveillance | 871 | | | live | 872 | | | aq:admitted | 873 | | | aq:non-admitted | 874 | | | aq:partial | 875 | | | aq:none | 876 | | | | 877 | | video | surveillance | 878 | | | live | 879 | | | aq:admitted | 880 | | | aq:non-admitted | 881 | | | aq:partial | 882 | | | aq:none | 883 | | | | 884 | | iptv | live | 885 | | | aq:admitted | 886 | | | aq:non-admitted | 887 | | | aq:partial | 888 | | | aq:none | 889 | | | | 890 | | multiplex | aq:admitted | 891 | | | aq:non-admitted | 892 | | | aq:partial | 893 | | | aq:none | 894 +----------------------+---------------------+---------------------+ 896 Figure 11. Broadcast Applications and Adjective Combinations 898 4.6 Intermittent Category Traffic Class 900 The "intermittent" traffic class is best suited for inconstant rate 901 applications such as those from a sensor device, where tolerance to 902 loss, delay and jitter is often medium to high in nature. This 903 category is not to be used for bulk file transfers, rather it can be 904 sometimes bursty for brief periods of time, but then not produce 905 traffic for short or long (i.e., hours or days) durations. Nor is 906 this category to be used for any kind of regular paced rate of 907 transmission, no matter how long the interval. 909 +--------------------------------------------------------------------+ 910 | Traffic Class | | Tolerance to | 911 | Name | Traffic Characteristics | Loss |Delay |Jitter| 912 |===============+===============================+======+======+======| 913 | intermittent | Inconstant rate, infrequent |Medium|Medium| High | 914 | | but sometimes bursty flows, |- High|- High| | 915 | | generally non-regular, | | | | 916 | | variable inter-packet | | | | 917 | | transmission interval, can be | | | | 918 | | UDP framed in (S)RTP or in | | | | 919 | | TCP/SCTP | | | | 920 +---------------+-------------------------------+------+------+------+ 922 Figure 12. Intermittent Traffic Characteristics 924 The following application components are appropriate for use with 925 the Broadcast category: 927 o sensor - a flow containing information obtained from a sensor, 928 such as a temperature or motion sensor. 930 With adjective substrings to the above: 932 o there are no defined adjectives for the 'sensor' application at 933 this time. There are many examples one could think would be viable 934 adjectives, such as light, motion, temperature, magnetic fields, 935 gravity, humidity, moisture, vibration, pressure, electrical 936 fields, and other physical aspects of the external environment 937 measured by the sensor. 939 +----------------------+---------------------+---------------------+ 940 | Category | Application | Adjective | 941 +----------------------+---------------------+---------------------+ 942 | intermittent | sensor | (undefined at this | 943 | | | time) | 944 +----------------------+---------------------+---------------------+ 946 Figure 13. Intermittent Applications and Adjective Combinations 948 5. Offer/Answer Behavior 950 Through the inclusion of the 'trafficclass' attribute, an 951 offer/answer exchange identifies the application type for use by 952 endpoints within a session. Policy elements can use this attribute 953 to determine the acceptability and/or treatment of that session 954 through lower layers. One specific use-case is for setting of the 955 DSCP specific for that application type (say a broadcast instead 956 of a conversational video), decided on a per domain basis - 957 instead of exclusively by the offering domain. 959 5.1 Offer Behavior 961 Offerers include the 'trafficclass' attribute with a single string 962 comprised of two or more components (from the list in Section 2) to 963 obtain configurable and predictable classification between the 964 answerer and the offerer. The offerer can also include a private set 965 of components, or a combination of IANA registered and private 966 components within a single domain (e.g., enterprise networks). 968 Offerers of this 'trafficclass' attribute MUST NOT change the label 969 in transit (e.g., wrt to B2BUAs). Session Border Controllers (SBC) 970 at domain boundaries can change this attribute through local policy. 972 Offers containing a 'trafficclass' label not understood are ignored 973 by default (i.e., as if there was no 'trafficclass' attribute in the 974 offer). 976 5.2 Answer Behavior 978 Upon receiving an offer containing a 'trafficclass' attribute, if 979 the offer is accepted, the answerer will use this attribute to 980 classify the session or media (level) traffic accordingly towards 981 the offerer. This answer does not need to match the traffic class in 982 the offer, though this will likely be the case most of the time. 984 In order to understand the traffic class attribute, the answerer 985 MUST check several components within the attribute, such as 987 1 - does the answerer understand the category component? 989 If not, the attribute SHOULD be ignored. 991 If yes, it checks the application component. 993 2 - does the answerer understand the application component? 995 If not, the answerer needs to check if it has a local policy to 996 proceed without an application component. The default for this 997 situation is as if the category component was not understand, 998 the attribute SHOULD be ignored. 1000 If yes, it checks to see if there are any adjective components 1001 present in this attribute to start its classification. 1003 3 - does the answerer understand the adjective component or 1004 components if any are present? 1006 If not present, process and match the trafficclass label value 1007 as is. 1009 If yes, determine if there is more than one. Search for each 1010 that is understood. Any adjectives not understood are to be 1011 ignored, as if they are not present. Match all remaining 1012 understood components according to local policy and process 1013 attribute. 1015 The answerer will answer the offer with its own 'trafficclass' 1016 attribute, which will likely be the same value, although this is not 1017 mandatory (at this time). The Offerer will process the received 1018 answer just as the answerer processed the offer. In other words, the 1019 processing steps and rules are identical for each end. 1021 The answerer should expect to receive RTP packets marked as 1022 indicated by its 'trafficclass' attribute in the answer itself. 1024 An Answer MAY have a 'trafficclass' attribute when one was not in 1025 the offer. This will at least aid the local domain, and perhaps 1026 each domain the session transits, to categorize the application type 1027 of this RTP session. 1029 Answerers that are middleboxes can use the 'trafficclass' attribute 1030 to classify the RTP traffic within this session however local policy 1031 determines. In other words, this attribute can help in deciding 1032 which DSCP an RTP stream is assigned within a domain, if the 1033 answerer were an inbound SBC to a domain. 1035 6. Security considerations 1037 RFC 5897 [RFC5897] discusses many of the pitfalls of service 1038 classification, which is similar enough to this idea of traffic 1039 classification to apply here as well. That document highly 1040 recommends the user not being able to set any classification. 1041 Barring a hack within an endpoint (i.e., to intentionally 1042 misclassifying (i.e., lying) about which classification an RTP 1043 stream is), this document's solution makes the classification part 1044 of the signaling between endpoints, which is recommended by RFC 1045 5897. 1047 7. IANA considerations 1049 7.1 Registration of the SDP 'trafficclass' Attribute 1051 This document requests IANA to register the following SDP att-field 1052 under the Session Description Protocol (SDP) Parameters registry: 1054 Contact name: jmpolk@cisco.com 1056 Attribute name: trafficclass 1057 Long-form attribute name: Traffic Classification 1059 Type of attribute: Session and Media levels 1061 Subject to charset: No 1063 Purpose of attribute: To indicate the Traffic Classification 1064 application for this session 1066 Allowed attribute values: IANA Registered Tokens 1068 Registration Procedures: Specification Required 1070 Type SDP Name Reference 1071 ---- ------------------ --------- 1072 att-field (both session and media level) 1074 trafficclass [this document] 1076 7.2 The Traffic Classification Category Registration 1078 This document requests IANA to create a new registry for the 1079 traffic Category classes similar to the following table within 1080 the Session Description Protocol (SDP) Parameters registry: 1082 Registry Name: "trafficclass" SDP Category Attribute Values 1083 Reference: [this document] 1084 Registration Procedures: Standards-Track document Required 1086 Category Values Reference 1087 ---------------- --------- 1088 broadcast [this document] 1089 realtime-interactive [this document] 1090 multimedia-conferencing [this document] 1091 multimedia-streaming [this document] 1092 conversational [this document] 1094 7.3 The Traffic Classification Application Type Registration 1096 This document requests IANA to create a new registry for the 1097 traffic application classes similar to the following table 1098 within the Session Description Protocol (SDP) Parameters registry: 1100 Registry Name: "trafficclass" SDP Application Attribute Type Values 1101 Reference: [this document] 1102 Registration Procedures: Specification Required 1103 Application Values Reference 1104 ------------------ --------- 1105 audio [this document] 1106 video [this document] 1107 text [this document] 1108 application-sharing [this document] 1109 presentation-data [this document] 1110 whiteboarding [this document] 1111 instant-messaging [this document] 1112 gaming [this document] 1113 remote-desktop [this document] 1114 telemetry [this document] 1115 multiplex [this document] 1116 webcast [this document] 1117 iptv [this document] 1119 7.4 The Traffic Classification Adjective Registration 1121 This document requests IANA to create a new registry for the 1122 traffic adjective values similar to the following table 1123 within the Session Description Protocol (SDP) Parameters registry: 1125 Registry Name: "trafficclass" SDP Adjective Attribute Values 1126 Reference: [this document] 1127 Registration Procedures: Specification Required 1129 Adjective Values Reference 1130 ------------------ --------- 1131 immersive [this document] 1132 avconf [this document] 1133 realtime [this document] 1134 web [this document] 1135 virtual [this document] 1136 live [this document] 1137 surveillance [this document] 1138 aq:admitted [this document] 1139 aq:non-admitted [this document] 1140 aq:partial [this document] 1141 aq:none [this document] 1143 7.5 The Traffic Classification Component Mapping 1145 7.5.1 Broadcast Applications and Adjective Combinations 1147 This document requests IANA to create a new registry for the 1148 Broadcast category mapping similar to Figure 11 in Section 4.5 of 1149 this document within the Session Description Protocol (SDP) 1150 Parameters registry: 1152 Registry Name: Broadcast Applications and Adjective Combinations 1153 Table 1154 Reference: [this document] 1155 Registration Procedures: Specification Required 1157 7.5.2 Realtime Interactive Applications and Adjective Combinations 1159 This document requests IANA to create a new registry for the 1160 Realtime Interactive category mapping similar to Figure 7 in Section 1161 4.3 of this document within the Session Description Protocol (SDP) 1162 Parameters registry: 1164 Registry Name: Realtime Interactive Applications and Adjective 1165 Combinations Table 1166 Reference: [this document] 1167 Registration Procedures: Specification Required 1169 7.5.3 Multimedia Conferencing Applications and Adjective Combinations 1171 This document requests IANA to create a new registry for the 1172 Multimedia Conferencing category mapping similar to Figure 5 in 1173 Section 4.2 of this document within the Session Description Protocol 1174 (SDP) Parameters registry: 1176 Registry Name: Multimedia Conferencing Applications and Adjective 1177 Combinations Table 1178 Reference: [this document] 1179 Registration Procedures: Specification Required 1181 7.5.4 Multimedia-Streaming 1183 This document requests IANA to create a new registry for the 1184 Multimedia-Streaming category mapping similar to Figure 9 in Section 1185 4.4 of this document within the Session Description Protocol (SDP) 1186 Parameters registry: 1188 Registry Name: Multimedia-Streaming Applications and Adjective 1189 Combinations Table 1190 Reference: [this document] 1191 Registration Procedures: Specification Required 1193 7.5.5 Conversational Applications and Adjective Combinations 1195 This document requests IANA to create a new registry for the 1196 conversational category mapping similar to Figure 3 in Section 4.1 1197 of this document within the Session Description Protocol (SDP) 1198 Parameters registry: 1200 Registry Name: Conversational Applications and Adjective 1201 Combinations Table 1202 Reference: [this document] 1203 Registration Procedures: Specification Required 1205 7.5.6 Intermittent Applications and Adjective Combinations 1207 This document requests IANA to create a new registry for the 1208 intermittent category mapping similar to Table 13 in Section 4.6 of 1209 this document within the Session Description Protocol (SDP) 1210 Parameters registry: 1212 Registry Name: Intermittent Applications and Adjective 1213 Combinations Table 1214 Reference: [this document] 1215 Registration Procedures: Specification Required 1217 8. Acknowledgments 1219 To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David 1220 Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, 1221 Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings 1222 and Peter Saint-Andre for their comments and suggestions. 1224 9. References 1226 9.1. Normative References 1228 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1229 Requirement Levels", RFC 2119, March 1997 1231 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 1232 "Resource ReSerVation Protocol (RSVP) -- Version 1 1233 Functional Specification", RFC 2205, September 1997 1235 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 1236 Differentiated Services Field (DS Field) in the IPv4 and 1237 IPv6 Headers ", RFC 2474, December 1998 1239 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application 1240 Identity Policy Element for Use with RSVP", RFC 2872, 1241 June 2000 1243 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1244 Jacobson, "RTP: A Transport Protocol for Real-Time 1245 Applications", STD 64, RFC 3550, July 2003. 1247 [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, 1248 "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 1249 2005 1251 [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of 1252 Diffserv-aware MPLS Traffic Engineering ", RFC 4124, 1253 June 2005 1255 [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session 1257 Description Protocol", RFC 4566, July 2006 1259 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1260 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1262 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 1263 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 1264 May 2010 1266 [RFC5897] J. Rosenberg, "Identification of Communications Services in 1267 the Session Initiation Protocol (SIP)", RFC 5897, June 2010 1269 9.2. Informative References 1271 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for 1272 Diffserv Service Classes", RFC 4594, August 2006 1274 [ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol 1275 (RSVP) Application-ID Profiles for Voice and Video Streams", 1276 work in progress, Feb 2013 1278 Author's Addresses 1280 James Polk 1281 3913 Treemont Circle 1282 Colleyville, Texas, USA 1283 +1.818.271.3552 1285 mailto: jmpolk@cisco.com 1287 Subha Dhesikan 1288 170 W Tasman St 1289 San Jose, CA, USA 1290 +1.408-902-3351 1292 mailto: sdhesika@cisco.com 1294 Paul E. Jones 1295 7025 Kit Creek Rd. 1296 Research Triangle Park, NC, USA 1297 +1 919 476 2048 1298 mailto: paulej@packetizer.com 1300 Appendix - Changes from Previous Versions 1302 A.1 From -03 to -04 1304 These are the following changes made between the WG -03 version and 1305 the -04 version: 1307 - minimal text changes. 1309 - introduced the "intermittent" category based on IETF86 feedback in 1310 the WG. 1312 A.2 From -02 to -03 1314 These are the following changes made between the WG -02 version and 1315 the -03 version: 1317 - Rearranged a fair amount of text 1319 - Separated and defined the components into separate subsections. 1321 - built 5 different tables, one per category, that lists within each 1322 category - what applications are appropriate as well as what 1323 adjectives are appropriate for each application within that 1324 category. 1326 - added the 'partial' admission qualifier for those flows that have 1327 only part of their respective flow admitted (i.e., CAC'd). 1329 A.3 From -01 to -02 1331 These are the following changes made between the WG -01 version and 1332 the -02 version: 1333 - converged the use of terms 'parent' and 'category' to just 1334 'category' for consistency. 1336 - changed ABNF to reflect extensibility by not having applications 1337 and adjectives named in the ABNF, rather have them merely IANA 1338 registered. 1340 - merged the qualified and unqualified adjective sections into a 1341 single section on adjectives, but allowing some to have a 1342 preceding qualifier. 1344 - text clean-up 1346 A.4 From -00 to -01 1348 These are the following changes made between the WG -00 version and 1349 the -01 version: 1351 - removed the non-SDP applications Netflix and VOD 1353 - switched the adjective 'desktop' to 'avconf' 1355 - Labeled each of the figures. 1357 - clarified the differences between Multimedia-Streaming and 1358 Broadcast category categories. 1360 - defined Video surveillance 1362 - added the concept of a 'qualified' adjective, and modified the 1363 ABNF. 1365 - deleted the idea of a 'cac-class' as a separate component, and 1366 made the equivalent a qualified adjective. 1368 - modified the answerer behavior because of the removal of the 1369 'cac-class' component. 1371 - created an IANA registry for qualified adjectives 1373 - general clean-up of the doc.