idnits 2.17.1 draft-polk-mmusic-traffic-class-for-sdp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 20 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 11, 2011) is 4670 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC5194' is mentioned on line 358, but not defined == Missing Reference: 'SP' is mentioned on line 521, but not defined == Unused Reference: 'RFC5865' is defined on line 904, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) 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 11, 2012 Paul Jones 5 Intended Status: Standards Track (PS) Cisco Systems 6 July 11, 2011 8 The Session Description Protocol (SDP) 'trafficclass' Attribute 9 draft-polk-mmusic-traffic-class-for-sdp-02 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 Legal 19 This documents and the information contained therein are provided on 20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 21 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 22 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 23 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 24 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 25 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 26 FOR A PARTICULAR PURPOSE. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on January 11, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Traffic Class Framework and String Definitions . . . . . . . 5 70 3. Traffic Class Attribute Definition . . . . . . . . . . . . . 11 71 4. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 14 72 4.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 14 73 4.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 14 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 16 75 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 8.1. Normative References . . . . . . . . . . . . . . . . . 18 79 8.2. Informative References . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 1. Introduction 88 The Session Description Protocol (SDP) [RFC4566] provides a means 89 for an offerer to describe the specifics of a session to an 90 answerer, and for the answerer to respond back with its session 91 specifics to the offerer. These session specifics include offering 92 the codec or codecs to choose from, the specific IP address and port 93 number the offerer wants to receive the RTP stream(s) on/at, the 94 particulars about the codecs the offerer wants considered or 95 mandated, and so on. 97 There are many facets within SDP to determine the Real-time 98 Transport Protocol (RTP) [RFC3550] details for the session 99 establishment between one or more endpoints, but identifying how the 100 underlying network should process each stream still remains 101 under-specified. 103 The ability to identify a traffic flow by port number gives an 104 indication to underlying network elements to treat traffic with 105 dissimilar ports in a different way, the same or in groups the same 106 - but different from other ports or groups of ports. 108 Within the context of realtime communications, the labeling of an 109 RTP session based on media descriptor lines as just a voice and/or 110 video session is insufficient, and provides no guidelines to the 111 underlying network on how to treat the traffic. A more granular 112 labeling helps on several fronts to 114 - inform application layer elements in the signaling path the 115 intent of this session. 117 - inform the network on how to treat the traffic if the network is 118 configured to differentiate session treatments based on the type 119 of session the RTP is, including the ability to provide call 120 admission control based on the type of traffic in the network. 122 - allow network monitoring/management of traffic types realtime and 123 after-the-fact analysis. 125 Some network operators want the ability to guarantee certain traffic 126 gets a minimum amount of network bandwidth per link or through a 127 series of links that perhaps makes up a network such as a campus or 128 WAN, or a backbone. For example, a call center voice application 129 gets at least 20% of a link as a minimum bandwidth. 131 Some network operators want the ability to allow certain users or 132 devices access to greater bandwidth during non-busy hours, than 133 during busy hours of the day. For example, all desktop video to 134 operate at 1080p during non-peak times, but curtail a similar 135 session between the same users or devices to 720p or 360p during 136 peak hours. This case is not as clear as accepting or denying 137 similar sessions during different times of the day, but tuning the 138 access to the bandwidth based on the type of session. In other 139 words, tune down the bandwidth for desktop video during peak hours 140 to allow a 3-screen telepresense session that would otherwise look 141 like the same type of traffic (RTP, and more granular, video). 143 RFC 4594 established a guideline for classifying the various flows 144 in the network and the Differentiated Services Codepoints (DSCP) 145 that apply to many traffic types (table 3 of [RFC4594]), including 146 RTP based voice and video traffic sessions. The RFC also defines the 147 per hop network behavior that is strongly encouraged for each of 148 these application traffic types based on the traffic characteristics 149 and tolerances to delay, loss and jitter within each traffic class. 151 Video was broken down into 4 categories in that RFC, and voice into 152 another single category. We do not believe this satisfies the 153 technical and business requirements to accomplish sufficiently 154 unique labeling of RTP traffic. 156 A question arises about once we properly label the traffic, what 157 does that get us? This is a fair question, but out of scope for 158 this document because that answer lies within other RFCs and IDs in 159 other WGs and/or Areas (specifically the Transport Area). That 160 said, we can discuss some of the ideas here for completeness. 162 If the application becomes aware of traffic labeling, 164 - this can be coded into layer 3 mechanisms. 166 - this can be coded into layer 4 protocols and/or mechanisms. 168 - this can be coded into a combination of mechanisms and protocols. 170 The layer 3 mechanism for differentiating traffic is either the port 171 number or the Differentiated Services Codepoint (DSCP) value 172 [RFC2474]. Within the public Internet, if the application is not 173 part of a managed service, the DSCP likely will be best effort (BE). 174 Within the corporate LAN, this is usually completely configurable 175 and a local IT department can take full advantage of this labeling 176 to shape and manage their network as they see fit. Communications 177 between enterprise networks will likely have to take advantage of 178 MPLS. 180 Within a network core, where only MPLS is used, Diffserv typically 181 does not apply. That said, Diffserv can be used to identify which 182 traffic goes into which MPLS tunnels [RFC4124]. 184 Labeling realtime traffic types using a layer 4 protocol would 185 likely mean RSVP [RFC2205] or NSIS [RFC4080]. RSVP has an 186 Application Identifier (app-ID) defined in [RFC2872] that provides a 187 means for carrying a traffic class label along the data path. An 188 advantage with this mechanism is for the label to inform each domain 189 along the media path what type of traffic this traffic flow is, and 190 allow each domain to adjust the appropriate DSCP (set by each domain 191 for use within that domain). Meaning, if a DSCP is set by an 192 endpoint or a router in the first domain and gets reset by a SP, the 193 far end domain will be able to reset the DSCP to the intended 194 traffic class. There is a proposed extension to RSVP which creates 195 individual profiles for what goes into each app-ID field to describe 196 these traffic classes [ID-RSVP-PROF], which will take advantage of 197 what is described in this document. 199 There are several proprietary mechanisms to take advantage of this 200 labeling, but none of those will be discussed here. 202 The idea of traffic - or service - identification is not new; it has 203 been described in [RFC5897]. If that RFC is used as a guideline, 204 identification that leads to stream differentiation can be quite 205 useful. One of the points within RFC 5897 is that users cannot be 206 allowed to assign any identification (fraud is but one reason 207 given). In addition, RFC 5897 recommends that service identification 208 should be done in signaling, rather than guessing or deep packet 209 inspection. The network will have to currently guess or perform deep 210 packet inspection to classify and offer the service as per RFC 4594 211 since such service identification information is currently not 212 available in SDP and therefore to the network elements. Since SDP 213 understands how each stream is created (i.e., the particulars of the 214 RTP stream), this is the right place to have this service 215 differentiated. Such service differentiation can then be 216 communicated to and leveraged by the network. 218 [Editor's Note: the words "traffic" and "service" are similar enough 219 that the above paragraph talks about RFC 5897's 220 "service identification", but this document is only 221 wanting to discuss and propose traffic indications 222 in SDP.] 224 This document proposes a simple attribute line to identify the 225 application a session is requesting in its offer/answer exchange. 226 This document uses previously defined service class strings for 227 consistency between IETF documents. 229 This document modifies the traffic classes originally created in RFC 230 4594 in Section 2, incrementing each class with application 231 identifiers and optional adjective strings. Section 3 defines the 232 new SDP attribute "trafficclass". Section 4 discusses the offerer 233 and answerer behavior when generating or receiving this attribute. 235 2. Traffic Class Framework and String Definitions 237 The framework of the traffic class attribute will have at least two 238 parts, allowing for several more to be included. The intention is to 239 have a parent class (e.g., Conversational) that merely serves as the 240 anchor point for an application component that when paired together, 241 form the highest level traffic class. An adjective component 242 provides further granularity for the application. 244 The traffic class label will have the following structure, 246 parent.application(.adjective)(.adjective)(.admitted/non-admitted) 248 [Editor's Note: the above is not exactly the ANBF to be used. 249 The order is right. The parent and application 250 MUST appear (each only once) and zero or more 251 adjectives can appear.] 253 Where 254 1) the 1st component is the human understandable category; 255 2) the 2nd component is the application; 256 3) an optional 3rd component or series of components are 257 adjective(s) used to further refine the application component; 258 and 259 4) an optional 4th component is to classify this flow as a CAC 260 admitted or non-admitted traffic flow. The default is 261 non-admitted, whether present or not. 263 The construction of the traffic class label for Telepresence video 264 would follow the form like this: 266 Conversational.video.immersive 268 There is no traffic class or DSCP value associated with just 269 "Conversational". There is a traffic class associated with 270 "Conversational.video", creating a differentiation between it and a 271 "Conversational.video.immersive" traffic class, which would have 272 DSCP associated with the latter traffic class, depending on local 273 policy. Each parent component is defined below, as are several of 274 application and adjective strings. 276 [Editor's Note: We're not yet sure how much of what's below will be 277 proposed for IANA registration, but the 5 parent 278 components will be, as well as at least some 279 application components per parent component. Some 280 adjective components will also likely be proposed 281 for IANA registration. 283 The 5 parent components of the traffic class attribute are as 284 follows: 286 o Conversational 287 o Multimedia Conferencing 288 o Real-Time Interactive 289 o Multimedia Streaming 290 o Broadcast 292 The following application components of the traffic class attribute 293 are as follows: 295 o Audio 296 o Video 297 o Text 298 o application-sharing 299 o Presentation-data 300 o Whiteboarding 301 o Web (conference) chat/instant messaging 302 o Gaming 303 o Virtual-desktop (interactive) 304 o Remote-desktop 305 o Telemetry (e.g., NORAD missile control) 306 o Multiplex (i.e., combined streams) 307 o (something to cover theater quality Netflix movies) 308 o (something to cover YouTube) 309 o Webcast 310 o IPTV 311 o Live-events (though not the buffered ones) 312 o surveillance 314 The following adjective components of the traffic class attribute 315 are as follows: 317 o Immersive 318 o Desktop-video 319 o Realtime-Text 320 o web 322 Each of the above 3 lists will be defined in the following 323 subsections. 325 2.1 Conversational Parent Traffic Class 327 The Conversational traffic class is best suited for applications 328 that require very low delay variation and generally intended to 329 enable real-time, bi-directional person-to-person or 330 multi-directional via an MTP communication, such as the following 331 application components: 333 o Audio (voice) 335 o Video 337 o Text (i.e., real-time text required by deaf users) 339 With adjective substrings to the above (which may or may not get 340 IANA registered) 342 Immersive (TP) - An interactive audio-visual communications 343 experience between remote locations, where the users enjoy a 344 strong sense of realism and presence between all participants 345 by optimizing a variety of attributes such as audio and video 346 quality, eye contact, body language, spatial audio, 347 coordinated environments and natural image size. 349 Desktop-video - An interactive audio-visual communication 350 experience that is not immersive in nature, though can have a 351 high resolution video component. 353 Realtime-Text (RTT) - a term for real-time transmission of text in 354 a character-by-character fashion for use in conversational 355 services, often as a text equivalent to voice-based 356 conversational services. Conversational text is defined in the 357 ITU-T Framework for multimedia services, Recommendation F.700 358 [RFC5194]. 360 Web - for realtime aspects of web conferencing; mutually exclusive 361 of both Immersive and Desktop video experiences 363 **The above substrings might also be used within Multimedia 364 Conferencing** 366 +--------------------------------------------------------------------+ 367 |Traffic Class | | Tolerance to | 368 | Name | Traffic Characteristics | Loss |Delay |Jitter| 369 |===============+===============================+======+======+======| 370 | | High priority, typically | Very | Very | Very | 371 |Conversational | small packets (large video | Low | Low | Low | 372 | | frames produce large packets),| | | | 373 | | generally sustained high | | | | 374 | | packet rate, low inter-packet | | | | 375 | | transmission interval, | | | | 376 | | usually UDP framed in (S)RTP | | | | 377 +---------------+-------------------------------+------+------+------+ 379 2.2 Multimedia-Conferencing Parent Traffic Class 381 Multimedia-Conferencing traffic class is best suited for 382 applications that are generally intended for communication between 383 human users, but are less demanding in terms of delay, packet loss, 384 and jitter than what Conversational applications require. These 385 applications require low to medium delay and may have the ability to 386 change encoding rate (rate adaptive) or transmit data at varying 387 rates, such as the following application components: 389 o application-sharing (that webex does or protocols like T.128) - 390 An application that shares the output of one or more running 391 applications or the desktop on a host. This can utilize 392 vector graphics, raster graphics or video. 394 o Presentation-data - can be a series of still images or motion 395 video. 397 o Whiteboarding - an application enabling the exchange of graphical 398 information including images, pointers and filled and 399 unfilled parametric drawing elements (points, lines, 400 polygons and ellipses). 402 o (RTP-based) file transfer 403 o Web (conference) chat/instant messaging 405 +--------------------------------------------------------------------+ 406 |Traffic Class | | Tolerance to | 407 | Name | Traffic Characteristics | Loss |Delay |Jitter| 408 |===============+===============================+======+======+======| 409 | Multimedia | Variable size packets, | Low | Low | Low | 410 | Conferencing | Variable transmit interval, | - | - | - | 411 | | rate adaptive, reacts to |Medium|Medium|Medium| 412 | | loss, usually TCP-based | | | | 413 +---------------+-------------------------------+------+------+------+ 415 2.3 Realtime-Interactive Parent Traffic Class 417 Realtime-Interactive traffic class is intended for interactive 418 variable rate inelastic applications that require low jitter and 419 loss and very low delay, such as the following application 420 components: 422 o Gaming - interactive player video games with other users on other 423 hosts (e.g., Doom) 425 o Virtual desktop (interactive) - similar to an X-windows station, 426 has no local harddrive, or is operating an application with no 427 local storage 429 o Remote Desktop - controlling a remote node with local peripherals 430 (i.e., monitor, keyboard and mouse) 432 o Telemetry - a communication that allows remote measurement and 433 reporting of information (e.g., post launch missile status or 434 energy monitoring) 436 +--------------------------------------------------------------------+ 437 |Traffic Class | | Tolerance to | 438 | Name | Traffic Characteristics | Loss |Delay |Jitter| 439 |===============+===============================+======+======+======| 440 | Realtime | Inelastic, mostly variable | Low | Very | Low | 441 | Interactive | rate, rate increases with | | Low | | 442 | | user activity | | | | 443 +---------------+-------------------------------+------+------+------+ 445 2.4 Multimedia-Streaming Parent Traffic Class 447 Multimedia-Streaming traffic class is best suited for variable rate 448 elastic streaming media applications where a human is waiting for 449 output and where the application has the capability to react to 450 packet loss by reducing its transmission rate, such as the following 451 application components: 453 o Audio 455 o Video 457 o Multiplex (i.e., combined streams) 459 With adjective substrings to the above (which may or may not get 460 IANA registered) 462 (something to cover theater quality Netflix movies) 464 (something to cover YouTube) 466 Webcast 468 The primary difference from the Multimedia-streaming parent class 469 and the Broadcast parent class is about the length of time for 470 buffering. Buffered streaming audio and/or video (e.g., Netflix or 471 previously-recorded videos on web sites like CNN, ESPN or from an 472 internal corporate server). Buffering here can be from seconds to 473 hours (as opposed to Broadcast buffering which is minimal). The 474 buffering aspect is what differentiates this parent class from the 475 Broadcast class (which has minimal or no buffering). 477 +--------------------------------------------------------------------+ 478 |Traffic Class | | Tolerance to | 479 | Name | Traffic Characteristics | Loss |Delay |Jitter| 480 |===============+===============================+======+======+======| 481 | Multimedia | Variable size packets, |Low - |Medium| High | 482 | Streaming | elastic with variable rate |Medium|- High| | 483 | | | | | | 484 +---------------+-------------------------------+------+------+------+ 486 2.5 Broadcast Parent Traffic Class 488 Broadcast traffic class is best suited for inelastic streaming media 489 applications that may be of constant or variable rate, requiring low 490 jitter and very low packet loss, such as the following application 491 components: 493 o IPTV 495 o Live events (though not the buffered ones) 497 o Video surveillance 499 +--------------------------------------------------------------------+ 500 |Traffic Class | | Tolerance to | 501 | Name | Traffic Characteristics | Loss |Delay |Jitter| 502 |===============+===============================+======+======+======| 503 | Broadcast | Constant and variable rate, | Very |Low - |Low - | 504 | | inelastic, generally | Low |Medium|Medium| 505 | | non-bursty flows, generally | | | | 506 | | sustained high packet rate, | | | | 507 | | low inter-packet transmission | | | | 508 | | interval, usually UDP framed | | | | 509 | | in (S)RTP | | | | 510 +---------------+-------------------------------+------+------+------+ 512 3. SDP Attribute Definition 514 This document proposes the 'trafficclass' session and media-level 515 SDP [RFC4566] attribute. The following is the Augmented 516 Backus-Naur Form (ABNF) [RFC5234] syntax for this attribute, which 517 is based on the SDP [RFC4566] grammar: 519 attribute =/ traffic-classification 521 traffic-classification = "trafficclass" ":" [SP] parent-class 522 "." app-type *( app-param ) 524 parent-class = "Broadcast" / 525 "Realtime-Interactive" / 526 "Multimedia-Conferencing" / 527 "Multimedia-Streaming" / 528 "Conversational" / 529 extension-mech 531 extension-mech = token 533 app-type = "audio" / "video" / "text" / 534 "application-sharing" / 535 "presentation-data" / 536 "whiteboarding" / "webchat/IM" / 537 "gaming" / "virtual-desktop" / 538 "remote-desktop" / "telemetry"/ 539 "multiplex" / "Netflix" / "youtube" / 540 "webcast" / "IPTV" / "live-events" / 541 "surveillance" 543 app-param = "." adjective / "." cac-class 545 adjective = "immersive" / "desktop-video" / 546 "Realtime-Text" /"web" / 547 generic-param ; from RFC3261 549 cac-class = "admitted" / "non-admitted" 551 The attribute is named "trafficclass", for traffic classification, 552 identifying which one of the five traffic classes applies to the 553 media stream. There MUST NOT be more than one trafficclass attribute 554 per media line. Confusion would result in where more than one exists 555 per m= line. 557 The parent classes in this document are an augmented version of the 558 application labels introduced by table 3 of RFC 4595 (which will be 559 rewritten based on the updated labels and treatments expected for 560 each traffic class defined in this document). 562 +-------------------------+------------------------------+ 563 | Application Labels | Parent Classes Defined | 564 | Defined in RFC 4594 | in this document | 565 +=========================+==============================+ 566 | Broadcast-video | Broadcast | 567 +-------------------------+------------------------------+ 568 | Realtime-Interactive | Realtime-Interactive | 569 +-------------------------+------------------------------+ 570 | Multimedia-Conferencing | Multimedia-Conferencing | 571 +-------------------------+------------------------------+ 572 | Multimedia-Streaming | Multimedia-Streaming | 573 +-------------------------+------------------------------+ 574 | Telephony | Conversational | 575 +-------------------------+------------------------------+ 577 Table 6. Label Changes from RFC 4594 579 As is evident from the changes above, from left to right, two labels 580 are different and each of the meanings are different in this 581 document relative to how RFC 4594 defined them. These differences 582 are articulated in Section 2 of this document. 584 A parent class is a human understandable categorization, and MUST 585 NOT be the only part of the traffic class label present in the 586 attribute. The parent class string MUST always be paired with an 587 application type, with a "." as the string separator. 589 The application types (app-type) define the application of a 590 particular traffic flow. The application types are listed both in 591 the ABNF and defined in Section 2 of this document. Not every 592 combination parent class is paired with application types, at least 593 as defined in this document. Section 2.1 through 2.5 list many of 594 the expected combinations. 596 For additional application type granularity, adjective strings can 597 be added (also listed in Section 2). One or more adjectives can be 598 within the same traffic class attribute. It is also permitted to 599 include one or more non-IANA registered adjective label, but these 600 MUST be prefaced by the additional delimiter "_", creating a 601 possibility such as 602 parent-class.application-type.adjective._non-standard-adjective 603 ^^^^ 604 See the underscore 606 For example, this is valid: 608 m=audio 50000 RTP/AVP 112 609 a=trafficclass Conversational.video.immersive._foo._bar 611 Where both "foo" and "bar" are not IANA registered adjectives, but 612 immersive is IANA registered. However, including non-registered 613 adjectives without the "_" delimiter is not permitted, such as the 614 following: 616 m=audio 50000 RTP/AVP 112 617 a=trafficclass Conversational.video.immersive.foo.bar 619 There is no limit to the number of adjectives allowed, without 620 regard for whether they are registered or not. These non-registered 621 adjectives can be vendor generated, or merely considered to be 622 proprietary in nature. 624 It is important to note that the order of components matters, but 625 only for the components. In other words, the parent class component 626 MUST be before the application component, which MUST be before the 627 adjective component, which MUST be before the cac-class component. 628 If there are no adjective components, the cac-class component is 629 immediately after the application component. 631 If there is more than one adjective component describing a traffic 632 class, the order of the adjectives MUST NOT matter. Some algorithm 633 such as alphabetizing the list and matching the understood strings 634 SHOULD be used. 636 In addition to, or as an alternative to one or more adjectives , a 637 cac-class value MAY be present indicating whether or not a session 638 has had call admission control applied to it. The following two 639 values are created by this document for the cac-class value: 641 - admitted 642 - nonadmitted 644 The default cac-class value for any trafficclass attribute is 645 nonadmitted, even if not present. There MUST NOT be more than one 646 cac-class sub-string per m=line. 648 Any application, adjective or cac-class string component within this 649 attribute that is not understood MUST be ignored, leaving all that 650 is understood to be processed. Ignored string components SHOULD NOT 651 be deleted, as a downstream entity could understand the component(s) 652 and use it/them. 654 Not understanding the parent class string SHOULD mean that this 655 attribute is ignored. 657 The following is an example of media level description with a 658 'trafficclass' attribute: 660 m=audio 50000 RTP/AVP 112 661 a=trafficclass conversational.video.immersive.admitted 663 The above indicates a multiscreen telepresence session that has had 664 call admission control applied to the media flow. 666 4. Offer/Answer Behavior 668 Through the inclusion of the 'trafficclass' attribute, an 669 offer/answer exchange identifies the application type for use by 670 endpoints within a session. Policy elements can use this attribute 671 to determine the acceptability and/or treatment of that session 672 through lower layers. One specific use-case is for setting of the 673 DSCP specific for that application type (say a Broadcast instead 674 of a converstaional video), decided on a per domain basis - 675 instead of exclusively by the offering domain. 677 4.1 Offer Behavior 679 Offerers include the 'trafficclass' attribute with a single well 680 string comprised of two or more components (from the list in Section 681 2) to obtain configurable and predictable classification between the 682 answerer and the offerer. The offerer can also include a private set 683 of components, or a combination of IANA registered and private 684 components within a single domain (e.g., enterprise networks). 686 Offerers of this 'trafficclass' attribute MUST NOT change the label 687 in transit (e.g., wrt to B2BUAs). SBCs at domain boundaries can 688 change this attribute through local policy. 690 Offers containing a 'trafficclass' label not understood are ignored 691 by default (i.e., as if there was no 'trafficclass' attribute in the 692 offer). 694 4.2 Answer Behavior 696 Upon receiving an offer containing a 'trafficclass' attribute, if 697 the offer is accepted, the answerer will use this attribute to 698 classify the session or media (level) traffic accordingly towards 699 the offerer. This answer does not need to match the traffic class in 700 the offer, though this will likely be the case most of the time. 702 In order to understand the traffic class attribute, the answerer 703 MUST check several components within the attribute, such as 705 1 - does the answerer understand the parent component? 707 If not, the attribute SHOULD be ignored. 709 If yes, it checks the application component. 711 2 - does the answerer understand the application component? 713 If not, the answerer needs to check if it has a local policy to 714 proceed without an application component. The default for this 715 situation is as if the parent component was not understand, 716 i.e., the attribute SHOULD be ignored. 718 If yes, it checks there are any other component present in this 719 attribute to start its classification. 721 3 - does the answerer understand the adjective component or 722 components if any are present? 724 If not present, see if there is a cac-class component, and 725 before processing classification. 727 If yes, determine if there are more than one. Alphabetize all of 728 the adjective components and match the traffic classification. 730 4 - does the answerer understand the cac-class component if present? 732 If not, consider the media flow for this m= line to be 733 nonadmitted. 735 If yes, classify whether this component is CAC admitted or 736 nonadmitted. 738 The answerer will answer the offer with its own 'trafficclass' 739 attribute, which will likely be the same value, although this is not 740 mandatory (at this time). 742 The answerer should expect to receive RTP packets marked as 743 indicated by its 'trafficclass' attribute in the answer itself. 745 An Answer MAY have a 'trafficclass' attribute when one was not in 746 the offer. This will at least aid the local domain, and perhaps 747 each domain the session transits, to categorize the application type 748 of this RTP session. 750 Answerers that are middleboxes can use the 'trafficclass' attribute 751 to classify the RTP traffic within this session however local policy 752 determines. In other words, this attribute can help in deciding 753 which DSCP an RTP stream is assigned within a domain, if the 754 answerer were an inbound SBC to a domain. 756 5. Security considerations 758 RFC 5897 [RFC5897] discusses many of the pitfalls of service 759 classification, which is similar enough to this idea of traffic 760 classification to apply here as well. That document highly 761 recommends the user not being able to set any classification. 762 Barring a hack within an endpoint (i.e., to intentionally 763 mis-classifying (i.e., lying) about which classification an RTP 764 stream is), this document's solution makes the classification part 765 of the signaling between endpoints, which is recommended by RFC 766 5897. 768 6. IANA considerations 770 6.1 Registration of the SDP 'trafficclass' Attribute 772 This document requests IANA to register the following SDP att-field 773 under the Session Description Protocol (SDP) Parameters registry: 775 Contact name: jmpolk@cisco.com 777 Attribute name: trafficclass 779 Long-form attribute name: Traffic Classification 781 Type of attribute: Session and Media levels 783 Subject to charset: No 785 Purpose of attribute: To indicate the Traffic Classification 786 application for this session 788 Allowed attribute values: IANA Registered Tokens 790 Registration Procedures: Specification Required 792 Type SDP Name Reference 793 ---- ------------------ --------- 794 att-field (both session and media level) 796 trafficclass [this document] 798 6.2 The Traffic Classification Application Type Registration 800 This document requests IANA to create a new registry for the 801 traffic application classes similar to the following table within 802 the Session Description Protocol (SDP) Parameters registry: 804 Registry Name: "trafficclass" SDP Application Type Attribute Values 805 Reference: [this document] 806 Registration Procedures: Specification Required 808 Parent Values Reference 809 ---------------- --------- 810 Broadcast [this document] 811 Realtime-Interactive [this document] 812 Multimedia-Conferencing [this document] 813 Multimedia-Streaming [this document] 814 Conversational [this document] 816 6.3 The Traffic Classification Application Type Registration 818 This document requests IANA to create a new registry for the 819 traffic application classes similar to the following table 820 within the Session Description Protocol (SDP) Parameters registry: 822 Registry Name: "trafficclass" Attribute Application Type Values 823 Reference: [this document] 824 Registration Procedures: Specification Required 826 Application Values Reference 827 ------------------ --------- 828 Audio [this document] 829 Video [this document] 830 Text [this document] 831 application-sharing [this document] 832 Presentation-data [this document] 833 Whiteboarding [this document] 834 Webchat/instant messaging [this document] 835 Gaming [this document] 836 Virtual-desktop [this document] 837 Remote-desktop [this document] 838 Telemetry [this document] 839 Multiplex [this document] 840 Netflix* [this document] 841 YouTube* [this document] 842 Webcast [this document] 843 IPTV [this document] 844 Live-events [this document] 845 surveillance [this document] 847 [Editor's Note: these are placeholders until a more generic string 848 can be agreed to by the WG] 850 6.4 The Traffic Classification Adjective Registration 852 This document requests IANA to create a new registry for the 853 traffic application classes similar to the following table 854 within the Session Description Protocol (SDP) Parameters registry: 856 Registry Name: "trafficclass" Attribute Adjective Values 857 Reference: [this document] 858 Registration Procedures: Specification Required 860 Application Values Reference 861 ------------------ --------- 862 Immersive [this document] 863 Desktop-video [this document] 864 Realtime-Text [this document] 865 web [this document] 867 6.5 The Traffic Classification Attribute Call Admission Control Class 868 Registration 870 This document requests IANA to create a new registry for the 871 Call Admission Control Class similar to the following table within 872 the Session Description Protocol (SDP) Parameters registry: 874 Registry Name: "trafficclass" SDP Call Admission Control Class 875 (cac-class) Attribute Values 876 Reference: [this document] 877 Registration Procedures: Specification Required 879 Attribute Values Reference 880 ---------------- --------- 881 Admitted [this document] 882 Non-admitted [this document] 884 7. Acknowledgments 886 To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David 887 Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, 888 and Greg Edwards for their comments and suggestions. 890 8. References 892 8.1. Normative References 894 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 895 Requirement Levels", RFC 2119, March 1997 897 [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session 898 Description Protocol", RFC 4566, July 2006 900 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 901 Jacobson, "RTP: A Transport Protocol for Real-Time 902 Applications", STD 64, RFC 3550, July 2003. 904 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 905 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 906 May 2010 908 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 909 Differentiated Services Field (DS Field) in the IPv4 and 910 IPv6 Headers ", RFC 2474, December 1998 912 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 913 "Resource ReSerVation Protocol (RSVP) -- Version 1 914 Functional Specification", RFC 2205, September 1997 916 [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, 917 "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 918 2005 920 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application 921 Identity Policy Element for Use with RSVP", RFC 2872, 922 June 2000 924 [RFC5897] J. Rosenberg, "Identification of Communications Services in 925 the Session Initiation Protocol (SIP)", RFC 5897, June 2010 927 [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of 928 Diffserv-aware MPLS Traffic Engineering ", RFC 4124, 929 June 2005 931 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 932 Specifications: ABNF", STD 68, RFC 5234, January 2008. 934 8.2. Informative References 936 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for 937 Diffserv Service Classes", RFC 4594, August 2006 939 [ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol 940 (RSVP) Application-ID Profiles for Voice and Video Streams", 941 work in progress, Mar 2011 943 Author's Addresses 945 James Polk 946 3913 Treemont Circle 947 Colleyville, Texas, USA 948 +1.818.271.3552 950 mailto: jmpolk@cisco.com 952 Subha Dhesikan 953 170 W Tasman St 954 San Jose, CA, USA 955 +1.408-902-3351 957 mailto: sdhesika@cisco.com