idnits 2.17.1 draft-ietf-mmusic-traffic-class-for-sdp-05.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 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 3, 2014) is 3579 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC5194' is mentioned on line 937, but not defined == Unused Reference: 'RFC5547' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC5865' is defined on line 1319, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 6 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 3, 2015 Paul Jones 5 Intended Status: Standards Track (PS) Cisco Systems 6 July 3, 2014 8 The Session Description Protocol (SDP) 'trafficclass' Attribute 9 draft-ietf-mmusic-traffic-class-for-sdp-05 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 July 4, 2015. 34 Copyright Notice 36 Copyright (c) 2014 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 1. Introduction 79 The Session Description Protocol (SDP) [RFC4566] provides a means 80 for an offerer to describe the specifics of a session to an 81 answerer, and for the answerer to respond back with its session 82 specifics to the offerer. These session specifics include offering 83 the codec or codecs to choose from, the specific IP address and port 84 number the offerer wants to receive the RTP stream(s) on/at, the 85 particulars about the codecs the offerer wants considered or 86 mandated, and so on. 88 There are many facets within SDP to determine the Real-time 89 Transport Protocol (RTP) [RFC3550] details for the session 90 establishment between one or more endpoints, but identifying how the 91 underlying network should process each stream still remains 92 under-specified. 94 The ability to identify a traffic flow by port number gives an 95 indication to underlying network elements to treat traffic with 96 dissimilar ports in a different way, the same or in groups the same 97 - but different from other ports or groups of ports. 99 Within the context of realtime communications, the labeling of an 100 RTP session based on media descriptor lines as just a voice and/or 101 video session is insufficient, and provides no guidelines to the 102 underlying network on how to treat the traffic. A more granular 103 labeling helps on several fronts to 105 - inform application layer elements in the signaling path the 106 intent of this session. 108 - inform the network on how to treat the traffic if the network is 109 configured to differentiate session treatments based on the type 110 of session the RTP is, including the ability to provide call 111 admission control based on the type of traffic in the network. 113 - allow network monitoring/management of traffic types realtime and 114 after-the-fact analysis. 116 Some network operators want the ability to guarantee certain traffic 117 gets a minimum amount of network bandwidth per link or through a 118 series of links that make up a network such as a campus or WAN, or a 119 backbone. For example, a call center voice application might get at 120 least 20% of the available link bandwidth. 122 Some network operators want the ability to allow certain users or 123 devices access to greater bandwidth during non-busy hours than 124 during busy hours of the day. For example, all desktop video might 125 operate at 1080p during non-peak times, but a similar session might 126 be curtailed between the same users or devices to 720p or 360p 127 during peak hours. Another example would be to reduce the frames 128 per second (fps) rate, say from 30fps to 15fps. This case is not as 129 clear as accepting or denying similar sessions during different 130 times of the day, but tuning the access to the bandwidth based on 131 the type of session. In other words, tune down the bandwidth for 132 desktop video during peak hours to allow a 3-screen Telepresence 133 session that would otherwise look like the same type of traffic 134 (RTP, and more granular, video). 136 RFC 4594 established a guideline for classifying the various flows 137 in the network and the Differentiated Services Codepoint (DSCP) 138 values that apply to many traffic types (table 3 of [RFC4594]), 139 including RTP based voice and video traffic sessions. The RFC also 140 defined the per hop network behavior that is strongly encouraged for 141 each of these application traffic types based on the traffic 142 characteristics and tolerances to delay, loss and jitter within each 143 traffic class. 145 Video was broken down into four categories in that RFC, and voice in 146 another single category. We do not believe this satisfies the 147 technical and business requirements to accomplish sufficiently 148 unique labeling of RTP traffic. 150 If the application becomes aware of traffic labeling, 152 - this can be coded into layer 3 mechanisms. 154 - this can be coded into layer 4 protocols and/or mechanisms. 156 - this can be coded into a combination of mechanisms and protocols. 158 A lower layer mechanism for differentiating traffic is either the 159 port number or the Differentiated Services Codepoint (DSCP) value 160 [RFC2474]. Within the public Internet, if the application is not 161 part of a managed service, the DSCP value likely will be best effort 162 (BE), or reset to BE, at ingress to a provider's network. Within 163 the corporate LAN, this is usually completely configurable and a 164 local IT department can take full advantage of this labeling to 165 shape and manage their network as they see fit. 167 Within a network core, DiffServ typically does not apply. That said, 168 DiffServ can be used to identify which traffic goes into which MPLS 169 tunnel [RFC4124]. 171 Labeling realtime traffic types using a layer 4 protocol would 172 likely involve RSVP [RFC2205] or NSIS [RFC4080]. RSVP has an 173 Application Identifier (app-ID) defined in [RFC2872] that provides a 174 means for carrying a traffic class label along the media path. An 175 advantage of this mechanism is that the label can inform each domain 176 along the media path what type of traffic this traffic flow is, and 177 allow each domain to adjust the appropriate DSCP value (set by each 178 domain for use within that domain). Meaning, if a DSCP value is set 179 by an endpoint or a router in the first domain and gets reset by a 180 service provider, the far-end domain will be able to reset the DSCP 181 value appropriate for the intended traffic class. There is a 182 proposed extension to RSVP which creates individual profiles for 183 what goes into each app-ID field to describe these traffic classes 184 [ID-RSVP-PROF], which will take advantage of what is described in 185 this document. 187 There are several proprietary mechanisms that can take advantage of 188 this labeling, but none of those will be discussed here. 190 The idea of traffic - or service - identification is not new; it has 191 been described in [RFC5897]. If that RFC is used as a guideline, 192 identification that leads to stream differentiation can be quite 193 useful. One of the points within RFC 5897 is that users cannot be 194 allowed to assign any identification (fraud is one reason given). In 195 addition, RFC 5897 recommends that service identification should be 196 done in signaling, rather than guessing or deep packet inspection. 197 Currently, any network would have to guess or perform deep 198 packet inspection to classify traffic and offer the service as per 199 RFC 4594 as such service identification information is currently 200 not available in SDP and therefore to the network elements. Since 201 SDP understands how each stream is created (i.e., the particulars of 202 the RTP stream), this is the right place to have this service 203 differentiated. Such service differentiation can then be 204 communicated to and leveraged by the network. 206 [Editor's Note: the words "traffic" and "service" are similar enough 207 that the above paragraph talks about RFC 5897's 208 "service identification", but this document only 209 discusses and proposes traffic indications in SDP.] 211 This document proposes a simple attribute line to identify the 212 application a session is requesting in its offer/answer exchange. 213 This document uses previously defined service class strings for 214 consistency between IETF documents. 216 This document utilizes the traffic classes originally created in RFC 217 4594 in Section 2, enhancing each class with application identifiers 218 and optional adjective strings. Section 3 defines the new SDP 219 attribute "trafficclass". Section 4 discusses the offerer and 220 answerer behavior when generating or receiving this attribute. 222 1.1 Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in RFC 2119 [RFC2119]. 228 2. Traffic Class Framework and Component Definitions 230 The framework of the traffic class attribute will have at least two 231 parts, called components, allowing for several more to be included 232 further distinguishing a particular session's traffic classification 233 from another session's traffic classification. The amount of 234 indicated differentiation between sessions is not a goal, and should 235 only have additional components for differentiation if there is a 236 need to uniquely identify traffic in different sessions. 238 The intention is to have a category component (e.g., conversational) 239 that identifies the traffic pattern for a session. Is the traffic 240 within a session one-way or two-way? Can the traffic be buffered 241 before reaching the destination or not? What is this session's 242 tolerance to packet loss and can there be retransmissions? 244 The application component (e.g., video) identifies the basic type of 245 traffic within a category. Is it media or data packets? If media, 246 which type of media? If data packets, which application of data 247 packets are in this session? 249 The optional adjective component(s) (e.g., immersive) help to 250 further refine the traffic within a session by providing more 251 description. For instance, if a session is two-way voice, what 252 additional information can be given about this particular session to 253 refine its description? Is it part of a conference or telepresence 254 session? Is it just standalone voice call? Has a capacity admission 255 protocol or mechanism been applied to this session? 257 The 'traffic class label' (TCL) will have the following structure, 259 category.application(.adjective)(.adjective)... 261 [Editor's Note: the above is not the exact ABNF to be used. 262 The order is right. The category and application 263 MUST appear first (each only once) and zero or more 264 adjectives can appear following the application 265 component.] 267 Where 268 1) the 1st component is the category, and is mandatory; 269 2) the 2nd component is the application, and is mandatory; 270 3) an optional 3rd component or series of components are 271 adjective(s) used to further refine the application component; 273 The construction of the traffic class label for Telepresence video 274 would follow the minimum form of: 276 conversational.video.immersive 278 where there might be one or more adjective after '.immersive'. 280 There is no traffic class or DSCP value associated with just 281 "conversational". There is a traffic class associated with 282 "conversational.video", creating a differentiation between it and a 283 "conversational.video.immersive" traffic class, which would have 284 DSCP associated with the latter traffic class, depending on local 285 policy. Each category component is defined below, as are several of 286 application and adjective strings. This is shown in [ID-RSVP-PROF] 287 for the RSVP mapping of distinguishable traffic types. 289 Mapping a specific Traffic Class Label to a DSCP value might be 290 accomplished in any of the following ways: 292 o statically within the offerer and/or answerer; or 294 o taken from a local mapping table/file, which might be downloaded 295 once, periodically or as changes in the network are observed; or 297 o from feedback from the network. 299 3. Traffic Class Attribute Definition 301 This document defines the 'trafficclass' media-level SDP attribute. 302 The following is the Augmented Backus-Naur Form (ABNF) [RFC5234] 303 syntax for this attribute, which is based on the SDP [RFC4566] 304 grammar: 306 attribute =/ traffic-class-label 308 traffic-class-label = "trafficclass" ":" [SP] category 309 "." application *( "." adjective ) 311 category = "broadcast" / 312 "realtime-interactive" / 313 "multimedia-conferencing" / 314 "multimedia-streaming" / 315 "conversational" / 316 "intermittent / tcl-token 318 application = tcl-token 320 adjective = classified-adjective / 321 unclassified-adjective 323 classified-adjective = tcl-token ":" tcl-token 325 unclassified-adjective = tcl-token 327 tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT ) 329 A TCL "component" is any of the following: 331 - category, 332 - application, or 333 - adjective (which is the only optional component, and can have zero 334 or more of these type of components) 336 The attribute is named "trafficclass", for traffic classification, 337 identifying which one of the six categories applies to the 338 media stream associated with this m-line. There MUST NOT be more 339 than one category component per SDP media line. 341 The categories in this document are an augmented version of the 342 application labels introduced by table 3 of RFC 4594 (which will be 343 rewritten based on the updated labels and treatments expected for 344 each traffic class defined in this document). 346 +-------------------------+------------------------------+ 347 | Application Labels | Category Classes Defined | 348 | Defined in RFC 4594 | in this document | 349 +=========================+==============================+ 350 | broadcast-video | broadcast | 351 +-------------------------+------------------------------+ 352 | realtime-interactive | realtime-interactive | 353 +-------------------------+------------------------------+ 354 | multimedia-conferencing | multimedia-conferencing | 355 +-------------------------+------------------------------+ 356 | multimedia-streaming | multimedia-streaming | 357 +-------------------------+------------------------------+ 358 | telephony | conversational | 359 +-------------------------+------------------------------+ 361 Figure 1. Label Differences from RFC 4594 363 As is evident from the changes above, from left to right, two labels 364 are different and each of the meanings are different in this 365 document relative to how RFC 4594 defined them. These differences 366 are articulated in Section 4 of this document. 368 Applications and adjectives are defined using the syntax of 369 "tcl-token" defined above. 371 RFC 4566 defined SDP as case sensitive. Everything is here as well. 373 An algorithm such as alphabetizing the list of components and 374 matching the understood strings SHOULD be used for determining the 375 traffic within a session. Strings not understood by an entity MUST 376 be ignored during processing, but MUST NOT be deleted. 378 Any category, application, or adjective string component within this 379 attribute that is not understood MUST be ignored, leaving all that 380 is understood to be processed. Ignored components SHOULD NOT be 381 deleted, as a downstream entity could understand the component(s) 382 and use it/them during processing. 384 The following is an example of media level description with a 385 'trafficclass' attribute: 387 m=video 50000 RTP/AVP 112 388 a=trafficclass:conversational.video.immersive.aq:admitted 390 The above indicates the video part of a Telepresence session that 391 has had capacity admission process applied to its media flow. 393 3.1 Categories within the SDP Traffic Class Label 395 The category component within the traffic class attribute describes 396 the type of communication that will occur within that session. It 397 answers these questions, is the traffic 399 - one-way or two-or-more-way interactive? 401 - buffered or (virtually) non-buffered? 402 - media or non-media (data)? 404 The six category components of the traffic class attribute defined 405 within this specification are as follows: 407 o conversational 408 o multimedia-conferencing 409 o realtime-interactive 410 o multimedia-streaming 411 o broadcast 412 o intermittent 414 Sections 4.1 through 4.6 define each of the above. 416 The category component MUST NOT be the only component present in a 417 traffic class attribute. The category component MUST BE paired with 418 an 'application' component to give enough meaning to the traffic 419 class labeling goal. 421 Not understanding the category component SHOULD mean that this 422 attribute is ignored, because of the information about the 423 expected behavior of this communication flow is identified by or 424 within that component. 426 3.2 Applications within the SDP Traffic Class Label 428 The application component identifies the application of a particular 429 traffic flow, for example, audio or video. The application types are 430 listed and defined in Section 4 of this document. Not every category 431 is paired with every application listed, at least as defined in this 432 document. One or more applications are inappropriate in one or more 433 categories. 435 Section 4.1 through 4.6 list many of the expected combinations. 437 3.3 Adjectives within the SDP Traffic Class Label 439 For additional application type granularity, adjective components 440 can be added. One or more adjectives can be within the same traffic 441 class attribute to provide more differentiation. 443 It is important to note that while the order of component types 444 matter, the order of the adjective components do not. In other 445 words, the category class component MUST be before the application 446 component, which MUST be before any and all adjective component(s). 448 There is no limit to the number of adjectives allowed. 450 Adjective components come in two versions, unqualified and 451 qualified. One has a prefix (qualified), the other (unqualified) 452 does not. A defined qualified adjective MUST NOT appear without its 453 qualifier name, even in future extensions to this specification. 454 Some implementations will likely perform a search within this 455 attribute for the presence of qualifiers, which might be as simple 456 as searching for the ":" COLON character. Implementations will be 457 confused with inconsistent coding, therefore strict adherence is 458 necessary. 460 3.3.1 Qualified Adjectives 462 Adjectives can be either unqualified or qualified. Qualified 463 adjectives have a delimiter ":" character between the "qualifier 464 name" and the "qualifier value". As one example, we introduce in 465 this specification the "admission qualifier" and it has a qualifier 466 name of "aq". We also define several possible qualifier values for 467 the admission qualifier, namely "admitted", "non-admitted", 468 "partial", and "none". When present in a TCL component, the 469 qualified adjectives look like these admission qualifier adjectives: 471 aq:admitted 472 aq:non-admitted 473 aq:partial 474 aq:none 476 Defining some adjectives as qualified adjectives allows entities 477 processing the traffic class label to potentially recognize a 478 particular qualifier name and act on it, even if it does not 479 understand the qualifier value. In the future, a new admission 480 qualifier value might be defined, e.g. "foo", and entities could at 481 least recognize the admission qualifier adjective, even if it did 482 not understand the qualifier value "foo". 484 Like all adjectives, it is OPTIONAL to include the admission 485 qualifier adjective in any trafficclass attribute. 487 The admission qualifier and its qualifier values are defined as: 489 - aq - 'admission qualifier' - this is the qualifier name for 490 the admission qualifier adjectives, wherein the 491 following qualifier values indicate the admission 492 status for the traffic flow described by this m-line. 494 - admitted - capacity admission mechanisms or protocols are to be or 495 were used for the full amount of bandwidth in relation 496 to this m= line. 498 - non-admitted - capacity admission mechanisms or protocols were 499 attempted but failed in relation to this m= line. This 500 does not mean the flow described by this m= line 501 failed. It just failed to attain the capacity admission 502 mechanism or protocol necessary for a predictable 503 quality of service, and is likely to continue with only 504 a class of service marking or best effort. 506 - partial - capacity admission mechanisms or protocols are to be or 507 were used for the part of the amount of bandwidth in 508 relation to this m= line. All traffic above a certain 509 amount will have no capacity admission mechanisms 510 applied. In other words, there is more traffic sent 511 than was agreed to. The burden is on the sender and 512 receiver to deal with any sent and lost information. 514 - none - no capacity admission mechanisms or protocols are or 515 were attempted in relation to this m= line. 517 The default for any flow generated from an m-line not having a 518 trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be 519 the equivalent of 'aq:none', whether or not it is present. 521 4. Matching Categories with Applications and Adjectives 523 This section describes each component within this document, as well 524 as provides the combinations of categories and applications and 525 adjectives. Given that not every combination makes sense, we express 526 the limits here - which will be IANA registered. The majority of 527 these TCLs in this document are found in [ID-RSVP-PROF], where RSVP 528 is appropriate. Look at that other document for example usage of a 529 specified TCL here. 531 4.1 Conversational Category Traffic Class 533 The "conversational" traffic class is best suited for applications 534 that require very low delay variation and generally intended to 535 enable realtime, bi-directional person-to-person or 536 multi-directional via an MCU communication. Conversational flows are 537 inelastic, and with few exceptions, use a UDP transport. 539 +--------------------------------------------------------------------+ 540 | Traffic Class | | Tolerance to | 541 | Name | Traffic Characteristics | Loss |Delay |Jitter| 542 |===============+===============================+======+======+======| 543 | | High priority, typically | Very | Very | Very | 544 |conversational | consistent sized packets | Low | Low | Low | 545 | | (small audio samples produce | | | | 546 | small packets and large video | | | | 547 | samples produce large packets),| | | | 548 | | generally sustained at a high | | | | 549 | | packet rate, low inter-packet | | | | 550 | | transmission interval | | | | 551 +---------------+-------------------------------+------+------+------+ 552 Figure 2. Conversational Traffic Characteristics 554 The following application components are appropriate for use with 555 the Conversational category: 557 o audio (voice) 559 o video 561 o multiplex (i.e., combined a/v streams) an application wherein 562 media of different forms (e.g., audio and video) is multiplexed 563 within the same media flow. 565 With adjective substrings to the above 567 immersive (TP) - An interactive audio-visual communications 568 experience between remote locations, where the users enjoy a 569 strong sense of realism and presence between all participants 570 by optimizing a variety of attributes such as audio and video 571 quality, eye contact, body language, spatial audio, 572 coordinated environments and natural image size. 574 avconf - An interactive audio-visual communication experience 575 that is not immersive in nature, though can have a high 576 resolution video component. 578 +----------------------+---------------------+---------------------+ 579 | Category | Application | Adjective | 580 +----------------------+---------------------+---------------------+ 581 | conversational | audio | immersive | 582 | | | avconf | 583 | | | aq:admitted | 584 | | | aq:non-admitted | 585 | | | aq:partial | 586 | | | aq:none | 587 | | | | 588 | | video | immersive | 589 | | | avconf | 590 | | | aq:admitted | 591 | | | aq:non-admitted | 592 | | | aq:partial | 593 | | | aq:none | 594 | | | | 595 | | multiplex | immersive | 596 | | | avconf | 597 | | | aq:admitted | 598 | | | aq:non-admitted | 599 | | | aq:partial | 600 | | | aq:none | 601 +----------------------+---------------------+---------------------+ 603 Figure 3. Conversational Applications and Adjective Combinations 605 4.2 Multimedia-Conferencing Category Traffic Class 607 The "multimedia-conferencing" traffic class is best suited for 608 applications that are generally intended for communication between 609 human users, but are less demanding in terms of delay, packet loss, 610 and jitter than what conversational applications require. These 611 applications require low to medium delay and may have the ability to 612 change encoding rate (rate adaptive) or transmit data at varying 613 rates. 615 +--------------------------------------------------------------------+ 616 | Traffic Class | | Tolerance to | 617 | Name | Traffic Characteristics | Loss |Delay |Jitter| 618 |===============+===============================+======+======+======| 619 | multimedia- | Variable size packets, | Low | Low | Low | 620 | conferencing | Variable transmit interval, | - | - | - | 621 | | rate adaptive, reacts to |Medium|Medium|Medium| 622 | | loss, often one-way or | | | | 623 | | unidirectional | | | | 624 +---------------+-------------------------------+------+------+------+ 626 Figure 4. Multimedia Conferencing Traffic Characteristics 628 Multimedia-conferencing flows are not media flows which are 629 conversational in nature. Multimedia-conferencing flows are those 630 data flows that are typically transmitted in parallel to currently 631 active conversational media flows. For example, a two-way conference 632 session in which the users share a presentation. The presentation 633 part of that conference call uses the Multimedia-conferencing 634 category, whereas the audio and any video uses the conversational 635 category indication. 637 The following application components are appropriate for use 638 with the Multimedia-Conferencing category: 640 o application-sharing (that webex does or protocols like T.128) - 641 An application that shares the output of one or more running 642 applications or the desktop on a host. This can utilize 643 vector graphics, raster graphics or video. 645 o presentation-data - can be a series of still images; could be at a 646 rapid or busty rate, just not a continuous 24 fps or greater. 648 o presentation-video - motion video that is transmitted and rendered 649 as part of a presentation. 651 o presentation-audio - the audio that is transmitted and rendered as 652 part of a presentation. 654 o whiteboarding - an application enabling the exchange of graphical 655 information including images, pointers and filled and 656 unfilled parametric drawing elements (points, lines, 657 polygons and ellipses). 659 o (RTP-based) file-transfer as defined in RFC 5547 661 o instant messaging 663 +----------------------+---------------------+---------------------+ 664 | Category | Application | Adjective | 665 +----------------------+---------------------+---------------------+ 666 | multimedia- | application-sharing | aq:admitted | 667 | conferencing | | aq:non-admitted | 668 | | | aq:partial | 669 | | | aq:none | 670 | | | | 671 | | whiteboarding | aq:admitted | 672 | | | aq:non-admitted | 673 | | | aq:partial | 674 | | | aq:none | 675 | | | | 676 | | presentation-data | aq:admitted | 677 | | | aq:non-admitted | 678 | | | aq:partial | 679 | | | aq:none | 680 | | | | 681 | | presentation-video | aq:admitted | 682 | | | aq:non-admitted | 683 | | | aq:partial | 684 | | | aq:none | 685 | | | | 686 | | presentation-audio | aq:admitted | 687 | | | aq:non-admitted | 688 | | | aq:partial | 689 | | | aq:none | 690 | | | | 691 | | instant-messaging | aq:admitted | 692 | | | aq:non-admitted | 693 | | | aq:partial | 694 | | | aq:none | 695 | | | | 696 | | file-transfer | aq:admitted | 697 | | | aq:non-admitted | 698 | | | aq:partial | 699 | | | aq:none | 700 +----------------------+---------------------+---------------------+ 702 Figure 5. Multimedia Conferencing Applications and Adjective 703 Combinations 705 4.3 Realtime-Interactive Category Traffic Class 707 The "Realtime-Interactive" traffic class is intended for interactive 708 variable rate inelastic applications that require low jitter and 709 loss and very low delay. Many of the applications that use the 710 Realtime-Interactive category use TCP or SCTP, even gaming, because 711 lost packets is information that is still required - therefore it is 712 retransmitted. 714 +--------------------------------------------------------------------+ 715 | Traffic Class | | Tolerance to | 716 | Name | Traffic Characteristics | Loss |Delay |Jitter| 717 |===============+===============================+======+======+======| 718 | realtime- | Inelastic, mostly variable | Low | Very | Low | 719 | interactive | rate, rate increases with | | Low | | 720 | | user activity | | | | 721 +---------------+-------------------------------+------+------+------+ 723 Figure 6. Realtime Interactive Traffic Characteristics 725 The following application components are appropriate for use with 726 the Realtime-Interactive category: 728 o gaming - interactive player video games with other users on other 729 hosts (e.g., Doom) 731 o remote-desktop - controlling a remote node with local peripherals 732 (i.e., monitor, keyboard and mouse) 734 o telemetry - a communication that allows remote measurement and 735 reporting of information (e.g., post launch missile status or 736 energy monitoring) 738 With adjective substrings to the above 740 o virtual - To be used with the remote-desktop application component 741 specifically when the traffic is a virtual desktop similar to 742 an X-windows station, has no local hard drive, or is operating 743 a computer application with no local storage. 745 +----------------------+---------------------+---------------------+ 746 | Category | Application | Adjective | 747 +----------------------+---------------------+---------------------+ 748 | realtime-interactive | gaming | aq:admitted | 749 | | | aq:non-admitted | 750 | | | aq:partial | 751 | | | aq:none | 752 | | | | 753 | | remote-desktop | virtual | 754 | | | aq:admitted | 755 | | | aq:non-admitted | 756 | | | aq:partial | 757 | | | aq:none | 758 | | | | 759 | | telemetry | aq:admitted | 760 | | | aq:non-admitted | 761 | | | aq:partial | 762 | | | aq:none | 763 +----------------------+---------------------+---------------------+ 765 Figure 7. Realtime-Interactive Applications and Adjective 766 Combinations 768 4.4 Multimedia-Streaming Category Traffic Class 770 The "multimedia-streaming" traffic class is best suited for variable 771 rate elastic streaming media applications where a human is waiting 772 for output and where the application has the capability to react to 773 packet loss by reducing its transmission rate. 775 +--------------------------------------------------------------------+ 776 | Traffic Class | | Tolerance to | 777 | Name | Traffic Characteristics | Loss |Delay |Jitter| 778 |===============+===============================+======+======+======| 779 | multimedia- | Variable size packets, |Low - |Medium| High | 780 | streaming | elastic with variable rate |Medium|- High| | 781 | | | | | | 782 +---------------+-------------------------------+------+------+------+ 784 Figure 8. Multimedia Streaming Traffic Characteristics 786 The following application components are appropriate for use with 787 the Multimedia-Streaming category: 789 o audio (see Section 4.1) 791 o video (see Section 4.1) 793 o webcast - is a media file distributed over the Internet or 794 enterprise network using streaming media technology. 796 o multiplex (see Section 4.1) 798 The primary difference between the multimedia-streaming category and 799 the broadcast category is the length of time for buffering. Buffered 800 streaming of audio and/or video which is often initiated by HTTP, 801 and not SDP. Buffering here can be from many seconds to hours, and 802 is typically at the destination end (as opposed to Broadcast 803 buffering which is minimal at the destination). The buffering 804 aspect is what differentiates this category class from the broadcast 805 category (which has minimal or no buffering). 807 +----------------------+---------------------+---------------------+ 808 | Category | Application | Adjective | 809 +----------------------+---------------------+---------------------+ 810 | multimedia-streaming | audio | aq:admitted | 811 | | | aq:non-admitted | 812 | | | aq:partial | 813 | | | aq:none | 814 | | | | 815 | | video | aq:admitted | 816 | | | aq:non-admitted | 817 | | | aq:partial | 818 | | | aq:none | 819 | | | | 820 | | webcast | aq:admitted | 821 | | | aq:non-admitted | 822 | | | aq:partial | 823 | | | aq:none | 824 | | | | 825 | | multiplex | aq:admitted | 826 | | | aq:non-admitted | 827 | | | aq:partial | 828 | | | aq:none | 829 +----------------------+---------------------+---------------------+ 831 Figure 9. Multimedia Streaming Applications and Adjective 832 Combinations 834 4.5 Broadcast Category Traffic Class 836 The "broadcast" traffic class is best suited for inelastic streaming 837 media Applications, which might have a 'wardrobe malfunction' delay 838 at or near the source but not typically at the destination, that may 839 be of constant or variable rate, requiring low jitter and very low 840 packet loss. 842 See Section 4.4 for the difference between Multimedia-Streaming and 843 Broadcast; it all has to do with buffering. 845 +--------------------------------------------------------------------+ 846 | Traffic Class | | Tolerance to | 847 | Name | Traffic Characteristics | Loss |Delay |Jitter| 848 |===============+===============================+======+======+======| 849 | broadcast | Constant and variable rate, | Very |Low - |Low - | 850 | | inelastic, generally | Low |Medium|Medium| 851 | | non-bursty flows, generally | | | | 852 | | sustained high packet rate, | | | | 853 | | low inter-packet transmission | | | | 854 | | interval | | | | 855 +---------------+-------------------------------+------+------+------+ 856 Figure 10. Broadcast Traffic Characteristics 858 The following application components are appropriate for use with 859 the Broadcast category: 861 o audio (see Section 4.1) 863 o video (see Section 4.1) 865 o multiplex (see Section 4.1) 867 With adjective substrings to the above: 869 o live (non-buffered) - refers to various types of media broadcast 870 without a significant delay, typically measured in 871 milliseconds to a few seconds only. 873 o surveillance - one way audio from a microphone or video from a 874 camera (e.g., observing a parking lot or building exit), 875 typically enabled for long periods of time, usually stored 876 at the destination. 878 +----------------------+---------------------+---------------------+ 879 | Category | Application | Adjective | 880 +----------------------+---------------------+---------------------+ 881 | broadcast | audio | surveillance | 882 | | | live | 883 | | | aq:admitted | 884 | | | aq:non-admitted | 885 | | | aq:partial | 886 | | | aq:none | 887 | | | | 888 | | video | surveillance | 889 | | | live | 890 | | | aq:admitted | 891 | | | aq:non-admitted | 892 | | | aq:partial | 893 | | | aq:none | 894 | | | | 895 | | multiplex | surveillance | 896 | | | live | 897 | | | aq:admitted | 898 | | | aq:non-admitted | 899 | | | aq:partial | 900 | | | aq:none | 901 +----------------------+---------------------+---------------------+ 903 Figure 11. Broadcast Applications and Adjective Combinations 905 4.6 Intermittent Category Traffic Class 907 The "intermittent" traffic class is best suited for inconstant rate 908 applications such as those from a sensor device, where tolerance to 909 loss, delay and jitter is often medium to high in nature. This 910 category is not to be used for bulk file transfers, rather it can be 911 sometimes bursty for brief periods of time, but then not produce 912 traffic for short or long (i.e., hours or days) durations. Nor is 913 this category to be used for any kind of regular paced rate of 914 transmission, no matter how long the interval. 916 +--------------------------------------------------------------------+ 917 | Traffic Class | | Tolerance to | 918 | Name | Traffic Characteristics | Loss |Delay |Jitter| 919 |===============+===============================+======+======+======| 920 | intermittent | Inconstant rate, infrequent |Medium|Medium| High | 921 | | but sometimes bursty flows, |- High|- High| | 922 | | generally non-regular, | | | | 923 | | variable inter-packet | | | | 924 | | transmission interval | | | | 925 +---------------+-------------------------------+------+------+------+ 927 Figure 12. Intermittent Traffic Characteristics 929 The following application components are appropriate for use with 930 the Broadcast category: 932 o text (i.e., text required by deaf users) a term for seemingly 933 real-time transmission of text in a character-by-character 934 fashion, often as a text equivalent to voice-based 935 conversational services, without the timing constraints of 936 conversational text is defined in the ITU-T Framework for 937 multimedia services, Recommendation F.700 [RFC5194]. 939 o sensor - a flow containing information obtained from a sensor, 940 such as a temperature or motion sensor. 942 With adjective substrings to the above: 944 o there are no defined adjectives for the 'sensor' application at 945 this time. There are many examples one could think would be viable 946 adjectives, such as light, motion, temperature, magnetic fields, 947 gravity, humidity, moisture, vibration, pressure, electrical 948 fields, and other physical aspects of the external environment 949 measured by the sensor. 951 +----------------------+---------------------+---------------------+ 952 | Category | Application | Adjective | 953 +----------------------+---------------------+---------------------+ 954 | intermittent | sensor | (undefined at this | 955 | | | time) | 956 | | | | 957 | | text | aq:admitted | 958 | | | aq:non-admitted | 959 | | | aq:partial | 960 | | | aq:none | 961 | | | | 962 +----------------------+---------------------+---------------------+ 964 Figure 13. Intermittent Applications and Adjective Combinations 966 5. Offer/Answer Behavior 968 Through the inclusion of the 'trafficclass' attribute, an 969 offer/answer exchange identifies the application type(s) for use by 970 the endpoints within the media streams of a session. Signaling 971 elements can use this attribute to determine the acceptability 972 and/or treatment of that session through lower layers, communicating 973 a desired treatment for a particular flow to endpoints using SDP, 974 interacting with network elements using some unspecified mechanism, 975 or having endpoints communicate with network elements using some 976 unspecified mechanism. 978 In order to understand the traffic class attribute, the SDP entity 979 MUST check several components within the Traffic Class Label. By 980 understand, we mean that the value of each component of the TCL is 981 recognized, i.e., both the category and application components 982 MUST be a recognized set for a TCL to be understood. Adjectives 983 that are not recognized are simply ignored and MAY be discarded, 984 however many there are. Adjectives which are not understood SHOULD 985 NOT be discarded, as each/any adjective might be understood by some 986 or all other downstream nodes in the signaling path. 988 The following pertains to both the receiver of an offer and receiver 989 of an answer when either or both contain a Traffic Class Label 990 attribute. 992 1 - can the receiver of the SDP containing a trafficclass attribute 993 successfully process the category component? 995 If not, the attribute SHOULD be ignored. 997 If yes, it checks the application component. 999 2 - can the receiver of the SDP containing a trafficclass attribute 1000 successfully process the application component? 1002 If not, the answerer needs to check if it has a local policy to 1003 proceed without an application component. The default for this 1004 situation is as if the category component was not understood, 1005 meaning the attribute SHOULD be ignored. 1007 If yes, it checks to see if there are any adjective components 1008 present in this attribute to start its classification. 1010 3 - can the receiver of the SDP containing a trafficclass attribute 1011 successfully process the adjective component or components if 1012 any are present? 1014 If not present, process and match the trafficclass label value 1015 as is. 1017 If yes, determine if there is more than one. Search for each 1018 that is understood. Any adjectives not understood are to be 1019 ignored, as if they are not present. Match all remaining 1020 understood components according to local policy and process 1021 attribute. 1023 5.1 Offer Behavior 1025 Offerers include the 'trafficclass' attribute within a single string 1026 per m= line comprised of at least a category and application 1027 component (see Section 4) to establish the non-generic 1028 classification of the media stream between the answerer and the 1029 offerer. The offerer can also include one or more adjective 1030 components, which might be a combination of registered and private 1031 adjectives to further refine the identification of what this 1032 particular media stream is. 1034 Session Border Controllers (SBC) at domain boundaries can change 1035 this attribute through local policy. 1037 5.2 Answer Behavior 1039 Upon receiving an offer containing a 'trafficclass' attribute, if 1040 the offer is accepted - including the ability to process the 3 1041 bulleted rules in Section 5.0, the answerer will use this attribute 1042 to classify the media level traffic accordingly towards the offerer. 1044 The answerer will answer the offer with its own 'trafficclass' 1045 attribute, which will likely be the same value, although this is not 1046 mandatory (at this time). The Offerer will process the received 1047 answer just as the answerer processed the offer. In other words, the 1048 processing steps and rules are identical for each end (see Section 1049 5). 1051 An Answer MAY have a 'trafficclass' attribute when one was not in 1052 the offer. This will at least aid the local domain, and perhaps 1053 each domain the session transits, to categorize and in some cases 1054 group the media-types of this session. 1056 6. Security considerations 1058 The security considerations from RFC 4566 are also applicable, 1059 particularly since intermediary devices might be able to look at an 1060 m= line and determine, not only is it audio, but that it is 1061 presentation-audio (i.e., 1062 'multimedia-conferencing.presentation-audio') versus conversational 1063 audio. 1065 RFC 5897 [RFC5897] discusses many of the pitfalls of service 1066 classification, which is similar enough to this idea of traffic 1067 classification to apply here as well. That document highly 1068 recommends the user not being able to set any classification. 1069 Barring a hack within an endpoint (i.e., to intentionally 1070 misclassifying (i.e., lying) about which classification an RTP 1071 stream is), this document's solution makes the classification part 1072 of the signaling between endpoints, which is recommended by RFC 1073 5897. 1075 7. IANA considerations 1077 7.1 Registration of the SDP 'trafficclass' Attribute 1079 This document requests IANA to register the following SDP att-field 1080 under the Session Description Protocol (SDP) Parameters registry: 1082 Contact name: jmpolk@cisco.com 1084 Attribute name: trafficclass 1086 Long-form attribute name: Traffic Classification 1088 Type of attribute: Media levels 1090 Subject to charset: No 1092 Purpose of attribute: To indicate the Traffic Classification 1093 application for this session 1095 Allowed attribute values: IANA Registered Tokens 1097 Registration Procedures: (there are multiple RFC5226 registration 1098 procedures; see below within each 1099 sub-section) 1101 Designated Experts: James Polk (jmpolk@cisco.com) 1102 Paul Jones (paulej@packetizer.com) 1104 Type SDP Name Reference 1105 ---- ------------------ --------- 1106 att-field (media level) 1107 trafficclass [this document] 1109 7.2 The Traffic Classification Category Registration 1111 This document requests IANA to create a new registry for the 1112 traffic category classes similar to the following table within 1113 the Session Description Protocol (SDP) Parameters registry: 1115 Registry Name: "trafficclass" SDP Category Attribute Values 1116 Reference: [this document] 1117 Registration Procedures: Standards Action Required [RFC5226] 1119 Category Values Reference 1120 ---------------- --------- 1121 broadcast [this document] 1122 realtime-interactive [this document] 1123 multimedia-conferencing [this document] 1124 multimedia-streaming [this document] 1125 conversational [this document] 1126 intermittent [this document] 1128 7.3 The Traffic Classification Application Type Registration 1130 This document requests IANA to create a new registry for the 1131 traffic application classes similar to the following table 1132 within the Session Description Protocol (SDP) Parameters registry: 1134 Registry Name: "trafficclass" SDP Application Attribute Values 1135 Reference: [this document] 1136 Registration Procedures: Specification Required [RFC5226] 1138 Application Values Reference 1139 ------------------ --------- 1140 audio [this document] 1141 video [this document] 1142 text [this document] 1143 application-sharing [this document] 1144 presentation-data [this document] 1145 presentation-video [this document] 1146 presentation-audio [this document] 1147 whiteboarding [this document] 1148 instant-messaging [this document] 1149 gaming [this document] 1150 remote-desktop [this document] 1151 telemetry [this document] 1152 multiplex [this document] 1153 webcast [this document] 1154 sensor [this document] 1156 7.4 The Traffic Classification Adjective Registration 1158 This document requests IANA to create a new registry for the 1159 traffic adjective values similar to the following table 1160 within the Session Description Protocol (SDP) Parameters registry: 1162 Registry Name: "trafficclass" SDP Adjective Attribute Values 1163 Reference: [this document] 1164 Registration Procedures: Specification Required [RFC5226] 1166 Adjective Values Reference 1167 ------------------ --------- 1168 immersive [this document] 1169 avconf [this document] 1170 realtime [this document] 1171 web [this document] 1172 virtual [this document] 1173 live [this document] 1174 surveillance [this document] 1175 aq:admitted [this document] 1176 aq:non-admitted [this document] 1177 aq:partial [this document] 1178 aq:none [this document] 1180 7.5 The Traffic Classification Component Mapping 1182 7.5.1 Broadcast Applications and Adjective Combinations 1184 This document requests IANA to create a new registry for the 1185 Broadcast category mapping similar to Figure 11 in Section 4.5 of 1186 this document within the Session Description Protocol (SDP) 1187 Parameters registry: 1189 Registry Name: Broadcast Applications and Adjective Combinations 1190 Table 1191 Reference: [this document] 1192 Registration Procedures: Specification Required [RFC5226] 1194 7.5.2 Realtime Interactive Applications and Adjective Combinations 1196 This document requests IANA to create a new registry for the 1197 Realtime Interactive category mapping similar to Figure 7 in Section 1198 4.3 of this document within the Session Description Protocol (SDP) 1199 Parameters registry: 1201 Registry Name: Realtime Interactive Applications and Adjective 1202 Combinations Table 1203 Reference: [this document] 1204 Registration Procedures: Specification Required [RFC5226] 1206 7.5.3 Multimedia Conferencing Applications and Adjective Combinations 1208 This document requests IANA to create a new registry for the 1209 Multimedia Conferencing category mapping similar to Figure 5 in 1210 Section 4.2 of this document within the Session Description Protocol 1211 (SDP) Parameters registry: 1213 Registry Name: Multimedia Conferencing Applications and Adjective 1214 Combinations Table 1215 Reference: [this document] 1216 Registration Procedures: Specification Required [RFC5226] 1218 7.5.4 Multimedia-Streaming Applications and Adjective Combinations 1220 This document requests IANA to create a new registry for the 1221 Multimedia-Streaming category mapping similar to Figure 9 in Section 1222 4.4 of this document within the Session Description Protocol (SDP) 1223 Parameters registry: 1225 Registry Name: Multimedia-Streaming Applications and Adjective 1226 Combinations Table 1227 Reference: [this document] 1228 Registration Procedures: Specification Required [RFC5226] 1230 7.5.5 Conversational Applications and Adjective Combinations 1232 This document requests IANA to create a new registry for the 1233 conversational category mapping similar to Figure 3 in Section 4.1 1234 of this document within the Session Description Protocol (SDP) 1235 Parameters registry: 1237 Registry Name: Conversational Applications and Adjective 1238 Combinations Table 1239 Reference: [this document] 1240 Registration Procedures: Specification Required [RFC5226] 1242 7.5.6 Intermittent Applications and Adjective Combinations 1244 This document requests IANA to create a new registry for the 1245 intermittent category mapping similar to Table 13 in Section 4.6 of 1246 this document within the Session Description Protocol (SDP) 1247 Parameters registry: 1249 Registry Name: Intermittent Applications and Adjective 1250 Combinations Table 1251 Reference: [this document] 1252 Registration Procedures: Specification Required [RFC5226] 1254 7.6 Designated Expert Reviewers 1256 The following will be the designated expert reviewers of new 1257 'trafficclass' registry requests: 1259 - James Polk 1261 - Paul E. Jones 1263 There SHALL remain two designated Expert reviewers at all times. The 1264 MMUSIC WG chairs should be consulted for replacements, if one or 1265 both are needed. 1267 8. Acknowledgments 1269 To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David 1270 Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, 1271 Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings 1272 and Peter Saint-Andre for their comments and suggestions. 1274 9. References 1276 9.1. Normative References 1278 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1279 Requirement Levels", RFC 2119, March 1997 1281 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 1282 "Resource ReSerVation Protocol (RSVP) -- Version 1 1283 Functional Specification", RFC 2205, September 1997 1285 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 1286 Differentiated Services Field (DS Field) in the IPv4 and 1287 IPv6 Headers ", RFC 2474, December 1998 1289 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application 1290 Identity Policy Element for Use with RSVP", RFC 2872, 1291 June 2000 1293 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1294 Jacobson, "RTP: A Transport Protocol for Real-Time 1295 Applications", STD 64, RFC 3550, July 2003. 1297 [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, 1298 "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 1299 2005 1301 [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of 1302 Diffserv-aware MPLS Traffic Engineering ", RFC 4124, 1303 June 2005 1305 [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session 1307 Description Protocol", RFC 4566, July 2006 1309 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1310 Considerations Section in RFCs", RFC 5226, May 2008 1312 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1313 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1315 [RFC5547] M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. , 1316 Kyzivat, "A Session Description Protocol (SDP) Offer/Answer 1317 Mechanism to Enable File Transfer ", RFC 5547, May 2009 1319 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 1320 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 1321 May 2010 1323 [RFC5897] J. Rosenberg, "Identification of Communications Services in 1324 the Session Initiation Protocol (SIP)", RFC 5897, June 2010 1326 9.2. Informative References 1328 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for 1329 Diffserv Service Classes", RFC 4594, August 2006 1331 [ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol 1332 (RSVP) Application-ID Profiles for Voice and Video Streams", 1333 work in progress, Feb 2013 1335 Author's Addresses 1337 James Polk 1338 3913 Treemont Circle 1339 Colleyville, Texas, USA 1340 +1.818.271.3552 1342 mailto: jmpolk@cisco.com 1344 Subha Dhesikan 1345 170 W Tasman St 1346 San Jose, CA, USA 1347 +1.408-902-3351 1349 mailto: sdhesika@cisco.com 1350 Paul E. Jones 1351 7025 Kit Creek Rd. 1352 Research Triangle Park, NC, USA 1353 +1 919 476 2048 1355 mailto: paulej@packetizer.com 1357 Appendix - Changes from Previous Versions 1359 A.1 From -04 to -05 1361 These are the following changes made between the WG -03 version and 1362 the -04 version: 1364 - general clean-up of text. 1366 - added presentation-video and presentation-audio to the 1367 multimedia-conferencing section. 1369 - brought forward the text describing how a SDP entity handles 1370 receiving a session description containing the trafficclass 1371 attribute to Section 5, from 5.2. 1373 - added RFC 5547 as a normative reference. 1375 - expended the security considerations section. 1377 A.2 From -03 to -04 1379 These are the following changes made between the WG -03 version and 1380 the -04 version: 1382 - minimal text changes. 1384 - introduced the "intermittent" category based on IETF86 feedback in 1385 the WG. 1387 A.3 From -02 to -03 1389 These are the following changes made between the WG -02 version and 1390 the -03 version: 1392 - Rearranged a fair amount of text 1394 - Separated and defined the components into separate subsections. 1396 - built 5 different tables, one per category, that lists within each 1397 category - what applications are appropriate as well as what 1398 adjectives are appropriate for each application within that 1399 category. 1401 - added the 'partial' admission qualifier for those flows that have 1402 only part of their respective flow admitted (i.e., CAC'd). 1404 A.4 From -01 to -02 1406 These are the following changes made between the WG -01 version and 1407 the -02 version: 1408 - converged the use of terms 'parent' and 'category' to just 1409 'category' for consistency. 1411 - changed ABNF to reflect extensibility by not having applications 1412 and adjectives named in the ABNF, rather have them merely IANA 1413 registered. 1415 - merged the qualified and unqualified adjective sections into a 1416 single section on adjectives, but allowing some to have a 1417 preceding qualifier. 1419 - text clean-up 1421 A.5 From -00 to -01 1423 These are the following changes made between the WG -00 version and 1424 the -01 version: 1426 - removed the non-SDP applications Netflix and VOD 1428 - switched the adjective 'desktop' to 'avconf' 1430 - Labeled each of the figures. 1432 - clarified the differences between Multimedia-Streaming and 1433 Broadcast category categories. 1435 - defined Video surveillance 1437 - added the concept of a 'qualified' adjective, and modified the 1438 ABNF. 1440 - deleted the idea of a 'cac-class' as a separate component, and 1441 made the equivalent a qualified adjective. 1443 - modified the answerer behavior because of the removal of the 1444 'cac-class' component. 1446 - created an IANA registry for qualified adjectives 1448 - general clean-up of the doc.