idnits 2.17.1 draft-ietf-tsvwg-admitted-realtime-dscp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 817. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4594, but the abstract doesn't seem to directly say this. It does mention RFC4594 though, so this could be OK. -- The draft header indicates that this document updates RFC4542, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 328 has weird spacing: '...olicers pri...' == Line 351 has weird spacing: '...olicers pri...' (Using the creation date from RFC4542, updated by this document, for RFC5378 checks: 2005-02-08) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-charny-pcn-single-marking-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group F. Baker 3 Internet-Draft J. Polk 4 Updates: 4542,4594 Cisco Systems 5 (if approved) M. Dolly 6 Intended status: Best Current AT&T Labs 7 Practice November 16, 2007 8 Expires: May 19, 2008 10 DSCPs for Capacity-Admitted Traffic 11 draft-ietf-tsvwg-admitted-realtime-dscp-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 19, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document requests one DSCP from the IANA for real-time traffic 45 classes similar to voice conforming to the Expedited Forwarding Per 46 Hop Behavior, and admitted using a CAC procedure involving 47 authentication, authorization, and capacity admission, as compared to 48 a class of real-time traffic conforming to the Expedited Forwarding 49 Per Hop Behavior but not subject to capacity admission or subject to 50 very coarse capacity admission. 52 It also recommends that certain classes of video traffic described in 53 RFC 4594 and which have similar requirements be require admission 54 using a CAC procedure involving authentication, authorization, and 55 capacity admission. 57 One of the reasons behind this is the need for classes of traffic 58 that are handled under special policies, such as the non-preemptive 59 Emergency Telecommunication Service, the US DoD's Assured Service 60 (which is similar to MLPP), or e-911. Capacity-admitted traffic 61 classes need separation from traffic not subject to admission 62 control, from which they can deterministically obtain their service 63 requirements, including SLA matters. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 8 77 2. Implementation of the Admitted Service Classes . . . . . . . . 8 78 2.1. Potential implementations of EF in this model . . . . . . 8 79 2.2. Capacity admission control . . . . . . . . . . . . . . . . 10 80 2.2.1. Capacity admission control by assumption . . . . . . . 10 81 2.2.2. Capacity admission control by call counting . . . . . 11 82 2.2.3. End-point capacity admission performed by probing 83 the network . . . . . . . . . . . . . . . . . . . . . 11 84 2.2.4. Centralized capacity admission control . . . . . . . . 12 85 2.2.5. Distributed capacity admission control . . . . . . . . 12 86 2.3. Prioritized capacity admission control . . . . . . . . . . 13 87 3. Recommendations on implementation of an Admitted Telephony 88 Service Class . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 94 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 Intellectual Property and Copyright Statements . . . . . . . . . . 19 98 1. Introduction 100 This document requests one DSCP from the IANA for a class of real- 101 time traffic conforming to the Expedited Forwarding [RFC3246] 102 [RFC3247] Per Hop Behavior and admitted using a CAC procedure 103 involving authentication, authorization, and capacity admission, as 104 compared to a class of real-time traffic conforming to the Expedited 105 Forwarding Per Hop Behavior but not subject to capacity admission or 106 subject to very coarse capacity admission. 108 It also recommends that certain classes of video described in 109 [RFC4594] be treated as requiring capacity admission as well. 111 These applications have one or more potential congestion points 112 between the video distribution/conferencing bridge or gaming server 113 and the user(s), and reserving capacity for them is important to 114 application performance. All of these applications have low 115 tolerance to jitter (aka delay variation) and loss, as summarized in 116 Section 2, and most (except for multimedia conferencing) have 117 inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow 118 behavior and low jitter/loss tolerance are the service 119 characteristics that define the need for admission control behavior. 121 One of the reasons behind this is the need for classes of traffic 122 that are handled under special policies, such as the non-preemptive 123 Emergency Telecommunication Service, the US DoD's Assured Service 124 (which is similar to MLPP and uses preemption), or e-911, in addition 125 to normal routine calls that use call admission. It is possible to 126 use control plane protocols to generally restrict session admission 127 such that admitted traffic should receive the desired service, and 128 the policy (e.g. Routine, National Security or Emergency 129 Preparedness [NS/EP] communications, e-911, etc) need not be signaled 130 in a DSCP. However, service providers need to distinguish between 131 special-policy traffic and other classes, particularly the existing 132 VoIP services that perform no capacity admission or only very coarse 133 capacity admission and can exceed their allocated resources. 135 The requested DSCP applies to the Telephony Service Class described 136 in [RFC4594]. The video classes addressed include the 138 o interactive real-time traffic (CS4, used for Video conferencing 139 and Interactive gaming), 141 o broadcast TV (CS3) for use in a video on demand context, and 143 o AF4 Multimedia conferencing (video conferencing). 145 Other video classes are not believed to be required by the targeted 146 services and to not have the current problem of confusion with 147 unadmitted traffic. Within an ISP and on inter-ISP links (i.e. 148 within networks whose internal paths are uniform at hundreds of 149 megabits or faster), one would expect all of this traffic to be 150 carried in the Real Time Traffic Class described in 151 [I-D.ietf-tsvwg-diffserv-class-aggr]. 153 1.1. Definitions 155 The following terms and acronyms are used in this document. 157 PHB: A Per-Hop-Behavior (PHB) is the externally observable 158 forwarding behavior applied at a DS-compliant node to a DS 159 behavior aggregate [RFC2475]. It may be thought of as a program 160 configured on the interface of an Internet host or router, 161 specified drop probabilities, queuing priorities or rates, and 162 other handling characteristics for the traffic class. 164 DSCP: The Differentiated Services Codepoint (DSCP), as defined in 165 [RFC2474], is a value which is encoded in the DS field, and which 166 each DS Node MUST use to select the PHB which is to be experienced 167 by each packet it forwards [RFC3260]. It is a 6-bit number 168 embedded into the 8-bit TOS field of an IPv4 datagram or the 169 Traffic Class field of an IPv6 datagram. 171 CAC: Call Admission Control, which includes concepts of 172 authorization (an identified and authenticated user is determined 173 to also be authorized to use the service) and capacity admission 174 (at the present time, under some stated policy, capacity exists to 175 support the call). In the Internet, these are separate functions, 176 while in the PSTN they and call routing are carried out together. 178 UNI: A User/Network Interface (UNI) is the interface (often a 179 physical link or its virtual equivalent) that connects two 180 entities that do not trust each other, and in which one (the user) 181 purchases connectivity services from the other (the network). 182 Figure 1 shows two user networks connected by what appears to each 183 of them to be a single network ("The Internet", access to which is 184 provided by their service provider) which provides connectivity 185 services to other users. 187 UNIs tend to be the bottlenecks in the Internet, where users 188 purchase relatively low amounts of bandwidth for cost or service 189 reasons, and as a result are most subject to congestion issues and 190 therefore issues requiring traffic conditioning and service 191 prioritization. 193 NNI: A Network/Network Interface (NNI) is the interface (often a 194 physical link or its virtual equivalent) that connects two 195 entities that trust each other within limits, and in which the two 196 are seen as trading services for value. Figure 1 shows three 197 service networks that together provide the connectivity services 198 that we call "the Internet". They are different administrations 199 and are very probably in competition, but exchange contracts for 200 connectivity and capacity that enable them to offer specific 201 services to their customers. 203 NNIs are not as commonly bottlenecks in the Internet, because 204 service providers contractually agree to provision serious amounts 205 of excess capacity at them. However, they are policy-controlled 206 interfaces (especially in BGP), and therefore may require policy 207 to be applied in traffic prioritization. 209 Queue: There are multiple ways to build a multi-queue scheduler. 210 Weighted Round Robin (WRR) literally builds multiple lists and 211 visits them in a specified order, while a calendar queue (often 212 used to implement Weighted Fair Queuing, or WFQ) builds a list for 213 each time interval and enqueues at most a stated amount of data in 214 each such list for transmission during that time interval. While 215 these differ dramatically in implementation, the external 216 difference in behavior is generally negligible when they are 217 properly configured. Consistent with the definitions used in the 218 Differentiated Services Architecture [RFC2475], these are treated 219 as equivalent in this document, and the lists of WRR and the 220 classes of a calendar queue will be referred to uniformly as 221 "queues". 223 _.--------. 224 ,-'' `--. 225 ,-' `-. 226 ,-------. ,',-------. `. 227 ,' `. ,',' `. `. 228 / User \ UNI / / Service \ \ 229 ( Network +-----+ Network ) `. 230 \ / ; \ / : 231 `. ,' ; `. .+ : 232 '-------' / '-------' \ NNI \ 233 ; \ : 234 ; "The Internet" \ ,-------. : 235 ; +' `. : 236 UNI: User/Network Interface / Service \ | 237 | ( Network ) | 238 NNI: Network/Network Interface \ / | 239 : +. ,' ; 240 : / '-------' ; 241 : / ; 242 ,-------. \ ,-------. / NNI / 243 ,' `. : ,' `+ ; 244 / User \ UNI / Service \ ; 245 ( Network +-----+ Network ) ,' 246 \ / \ \ / / 247 `. ,' `.`. ,' ,' 248 '-------' `.'-------' ,' 249 `-. ,-' 250 `--. _.-' 251 `--------'' 253 Figure 1: UNI and NNI interfaces 255 1.2. Problem 257 In short, the Telephony Service Class described in [RFC4594] permits 258 the use of capacity admission in implementing the service, but 259 present implementations either provide no capacity admission services 260 or do so in a manner that depends on specific traffic engineering. 261 In the context of the Internet backbone, the two are essentially 262 equivalent; the edge network is depending on specific engineering by 263 the service provider that may not be present. 265 However, services are being requested of the network that would 266 specifically make use of capacity admission, and would distinguish 267 among users or the uses of available Voice-on-IP or Video-on-IP 268 capacity in various ways. Various agencies would like to provide 269 services as described in section 2.6 of [RFC4504] or in [RFC4190]. 270 This requires the use of capacity admission to differentiate among 271 users (which might be 911 call centers, other offices with 272 preferential service contracts, or individual users gaining access 273 with special credentials) to provide services to them that are not 274 afforded to routine customer-to-customer IP telephony sessions. 276 1.3. Proposed Solution 278 The IETF is asked to differentiate, in the Telephony Service, between 279 sessions that are originated without capacity admission or using 280 traffic engineering and sessions that are originated using more 281 robust capacity admission procedures. Sessions of the first type use 282 a traffic class in which they compete without network-originated 283 control as described in Section 2.2.1 or Section 2.2.2, and in the 284 worst case lose traffic due to policing. Sessions of the second type 285 cooperate with network control, and may be given different levels of 286 preference depending on the policies that the network applies. In 287 order to provide this differentiation, the IETF requests that the 288 IANA assign a separate DSCP value to admitted sessions using the 289 Telephony service (see Section 4 ). 291 2. Implementation of the Admitted Service Classes 293 2.1. Potential implementations of EF in this model 295 There are at least two possible ways to implement the Expedited 296 Forwarding PHB in this model. They are to implement separate classes 297 as a set of 299 o Multiple data plane traffic classes, each consisting of a policer 300 and a queue, and the queues enjoying different priorities, or 302 o Multiple data plane traffic classes, each consisting of a policer 303 but feeding into a common queue or multiple queues at the same 304 priority. 306 We will explain the difference, and describe in what way they differ 307 in operation. The reason this is necessary is that there is current 308 confusion in the industry, including a widely reported test for NS/EP 309 services that implemented the policing model and described it as an 310 implementation of the multi-priority model, and discussion in other 311 environments of the intermixing of voice and video traffic at 312 relatively low bandwidths in the policing model. 314 The multi-priority model is shown in Figure 2. In this model, 315 traffic from each service class is placed into a separate priority 316 queue. If data is present in both queues, traffic from one of them 317 will always be selected for transmission. This has the effect of 318 transferring jitter from the higher priority queue to the lower 319 priority queue, and reordering traffic in a way that gives the higher 320 priority traffic a smaller average queuing delay. Each queue must 321 have its own policer, however, to protect the network from errors and 322 attacks; if a traffic class thinks it is carrying a certain data rate 323 but an abuse sends significantly more, the effect of simple 324 prioritization would not preserve the lower priorities of traffic, 325 which could cause routing to fail or otherwise impact an SLA. 327 . 328 policers priorities |`. 329 EF ---------> <=> ----------||----+ `. 330 high| `. 331 EF2---------> <=> ----------||----+ .'----------- 332 . medium .' 333 rate queues |`. +-----+ .' Priority 334 AF1------>||----+ `. / low |' Scheduler 335 | `. / 336 AF2------>||----+ .'-+ 337 | .' 338 CS0------>||----+ .' Rate Scheduler 339 |' (WFQ, WRR, etc) 341 Figure 2: Implementation as a data plane priority 343 The multi-policer model is shown in Figure 3. In this model, traffic 344 from each service class is policed according to its SLA requirements, 345 and then placed into a common priority queue. Unlike the multi- 346 priority model, the jitter experienced by the traffic classes in this 347 case is the same, as there is only one queue, but the sum of the 348 traffic in this higher priority queue experiences less average jitter 349 than the elastic traffic in the lower priority. 351 policers priorities . 352 EF ---------> <=> -------\ |`. 353 --||----+ `. 354 EF2---------> <=> -------/ high| `. 355 . | .'-------- 356 rate queues |`. +-----+ .' 357 AF1------>||----+ `. / low | .' Priority 358 | `. / |' Scheduler 359 AF2------>||----+ .'-+ 360 | .' 361 CS0------>||----+ .' Rate Scheduler 362 |' (WFQ, WRR, etc) 364 Figure 3: Implementation as a data plane policer 366 The difference between the two operationally is, as stated, the 367 issues of loss due to policing and distribution of jitter. 369 If the two traffic classes are, for example, voice and video, 370 datagrams containing video data are relatively large (generally the 371 size of the path MTU) while datagrams containing voice are relatively 372 small, on the order of only 40 to 200 bytes, depending on the codec. 373 On lower speed links (less than 10 MBPS), the jitter introduced by 374 video to voice can be disruptive, while at higher speeds the jitter 375 is nominal compared to the jitter requirements of voice. At access 376 network speeds, therefore, [RFC4594] recommends separation of video 377 and voice into separate queues, while at optical speeds 378 [I-D.ietf-tsvwg-diffserv-class-aggr] recommends that they use a 379 common queue. 381 If, on the other hand, the two traffic classes are carrying the same 382 type of application with the same jitter requirements, then giving 383 one preference in this sense does not benefit the higher priority 384 traffic and may harm the lower priority traffic. In such a case, 385 using separate policers and a common queue is a superior approach. 387 2.2. Capacity admission control 389 There are five major ways that capacity admission is done or has been 390 proposed to be done in real-time applications: 392 o Capacity admission control by assumption, 394 o Capacity admission control by call counting, 396 o End-point capacity admission performed by probing the network, 398 o Centralized capacity admission control, and 400 o Distributed capacity admission control 402 2.2.1. Capacity admission control by assumption 404 The first approach is to ignore the matter entirely. If one assumes 405 that the capacity available to the application is uniformly far in 406 excess of its requirements, it is perhaps overhead that can be 407 ignored. This assumption is currently made in Internet VoIP 408 offerings such as Skype and Vonage; the end user is responsible to 409 place his service on a LAN connected to the Internet backbone by a 410 high speed broadband connection and use capable ISPs to deliver the 411 service. There is an authorization step in the sense that the 412 service ensures that the user pays his bills, but no capacity 413 admission is considered because there is a clear separation from the 414 application service provider admitting the calls and the access 415 network provider admitting the traffic. The two have no way of 416 knowing about each other, except maybe in the abstract sense. 418 2.2.2. Capacity admission control by call counting 420 The H.323 gatekeeper, originally specified in 1996, operates on the 421 model that the considerations of Section 2.2.1 generally apply, and 422 that it is therefore sufficient to count calls in order to ensure 423 that any bottlenecks in the network are never overloaded. Which 424 phone is calling which phone is configured information into the 425 Gatekeeper, ensuring it doesn't admit too many calls across a low 426 speed link. The area of influence of a Gatekeeper is called a Zone, 427 and limits how far away a Gatekeeper can influence calls. This is 428 because call counting doesn't scale when more than one server is 429 admitting flows across the same limited speed links. This approach 430 is consistent with the original design of H.323, which in 1996 was a 431 mechanism for connecting H.320 media gateways across a LAN. VoIP has 432 come a long way since then, however, and the engineering trade-offs 433 this approach requires in complex networks are unsatisfactory. 435 SIP provides the option to go down another path, to admit its servers 436 at layer 7, have no awareness of lower layer connectivity, resulting 437 in a divorce from infrastructure knowledge - save for [RFC3312], 438 which binds the two, but only at the endpoints. 440 In short, if there is a bottleneck anywhere in the network that might 441 be used to connect two gatekeepers, SIP proxies that do not implement 442 or do not configure the use of [RFC3312], or other call management 443 systems, the amount of traffic between the two must be contained 444 below that bottleneck even if the normal path is of much higher 445 bandwidth. In addition, the multiplexing of traffic streams between 446 different pairs of gatekeepers over a common LAN infrastructure is 447 not handled by the application, and so must be managed in the 448 engineering of the network. 450 2.2.3. End-point capacity admission performed by probing the network 452 The IETF started looking into the use of Pre-Congestion Notification 453 mechanism to full fill the need of admission control for real-time 454 traffic. The main contribution of this work for admission control is 455 to allow the network to provide the network's pre-congestion 456 information using encoding of a field in the IP header. This network 457 pre-congestion information is then used for making admission control 458 decisions. With the decision influenced by this network pre- 459 congestion notification information and any applicable policy 460 information with possible user credentials and situational 461 information. The pre-congestion notification mechanism does not 462 limit the placement of the admission control decision point or the 463 signaling protocol used. 465 The overview of one of the current proposals is provided by 466 [I-D.chan-pcn-problem-statement]. With the pre-congestion 467 notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An 468 initial deployment model provided by 469 [I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in 470 [I-D.charny-pcn-single-marking]. Similar approaches have been 471 proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars 472 and Karlsson in their PBAC work, and many others. 474 Current simulation work have shown the pre-congestion notification 475 mechanism works well with large number of audio and video flows on 476 high speed lines. This work is ongoing. 478 2.2.4. Centralized capacity admission control 480 The concept of a Bandwidth Broker was first discussed in the research 481 world surrounding ESNET and Internet II in the late 1990's, and has 482 been discussed in the literature pertaining to the Differentiated 483 Services Architecture [RFC2475]. It is, in short, a central system 484 that performs a variety of services on behalf of clients of a network 485 including applying AAA services (as in [RFC2904] )and authorizing 486 them to use specified capacity at specified times. Its strength is 487 that it is relatively simple, at least in concept, and can keep track 488 of simple book-keeping functions apart from network elements such as 489 routers. Its weakness is that it has no idea what the specific 490 routing of any stated data flow is, or its capacity apart from 491 services such as MPLS Traffic Engineering or engineering assumptions 492 specified by the designers of a network, and obtaining that 493 information from the network via SNMP GET or other network management 494 action can impose a severe network overhead, and is obviously not in 495 real-time. 497 For scaling reasons, operational Bandwidth Brokers generally take on 498 a semi-distributed or fully distributed nature. They are implemented 499 on a per-point-of-presence basis, and in satellite networks might be 500 implemented in each terminal. At this point, they become difficult 501 to operationally distinguish from distributed capacity admission 502 services such as described in Section 2.2.5. 504 2.2.5. Distributed capacity admission control 506 The IETF developed the Integrated Services Model [RFC1633] and the 507 RSVP capacity admission protocol [RFC2205] in the early 1990's, and 508 then integrated it with the Differentiated Services Architecture in 509 [RFC2998]. Since then, the IETF has been working on a next 510 generation signaling protocol called NSIS that can be used for 511 capacity admission protocol, and which is limited in scope to 512 considering unicast sessions. [RFC4542] looked at the issue of 513 providing preferential services in the Internet, and determined that 514 RSVP with its defined extensions could provide those services to 515 unicast and multicast sessions. 517 As with the Bandwidth Broker model, there are concerns regarding 518 scaling, mentioned in [RFC2208]. Present implementations that have 519 been measured have been found to not display the scaling concerns, 520 however, and in any event the use of RSVP Aggregation enables the 521 backbone to handle such sessions in a manner similar to an ATM 522 Virtual Path, bundling sessions together for capacity management 523 purposes. 525 2.3. Prioritized capacity admission control 527 Emergency Telecommunication Service, the US DoD's Assured Service, 528 and e-911 each call for some form of prioritization of some calls 529 over others. Prioritization of the use of bandwidth is fundamentally 530 a matter of choices - at a point where one has multiple choices, 531 applying a policy that selects among them. In the PSTN, GETS 532 operates in favor of an authorized caller either by routing a call 533 that would otherwise be refused by a path unavailable to the general 534 public or by queuing the call until some existing call completes and 535 bandwidth becomes available. e-911 is similar, but the policy is 536 based on the called party, the emergency call center. MLPP operates 537 by preempting an existing call to make way for the new one. 539 In the Internet, routing is not performed on a per-call basis, so, 540 apart from interconnections to the PSTN, re-routing isn't an option. 541 On the other hand, in the Internet there are more classes of traffic 542 than in the PSTN. In the PSTN, all calls are uses of circuits, while 543 in the Internet some bandwidth is always reserved for elastic 544 applications - at least, it must be available for routing, and there 545 is generally significant consideration of the web, instant messaging, 546 and other applications. In essence, any capacity admission policy 547 that differentiates between calls has the option of temporarily 548 borrowing bandwidth from the capacity reserved for elastic traffic by 549 accepting new sessions under some prioritized policy while refusing 550 sessions of lower priority because the threshold at that priority has 551 been reached. 553 For example, regardless of the type of capacity admission that is 554 used (apart from "no admission process"), one might admit prioritized 555 sessions using a higher bandwidth threshold than one admits lower 556 priority sessions. 558 If capacity admission as described in Section 2.2.2 is in use, the 559 thresholds must be set low enough that bandwidth would be available 560 anywhere in the network. This greatly limits the utility of such a 561 service due to the level of bandwidth waste that results. 563 If capacity admission as described in Section 2.2.3 is in use, then 564 either multiple thresholds must be applied in marking the traffic, 565 multiple traffic marks must be applied, or there must be multiple 566 ways to interpret the result. In any event, this is only applicable 567 in domains in which the law of large numbers applies. 569 If capacity admission as described in Section 2.2.4 is in use, 570 thresholds can be applied related to a general policy or SLA, or 571 related to the network ingress and egress in use. It requires them 572 to maintain state regarding network traffic routing separate from the 573 network; to the extent that is variable, it requires direct 574 monitoring in the OSS. 576 If capacity admission as described in Section 2.2.5 is in use, 577 thresholds can be applied to the critical points of the path that the 578 traffic in question actually takes because one is asking the 579 equipment that the path traverses. 581 3. Recommendations on implementation of an Admitted Telephony Service 582 Class 584 It is the belief of the authors that either data plane PHB described 585 in Section 2.1, if coupled with adequate AAA and capacity admission 586 procedures as described in Section 2.2.5, are sufficient to provide 587 the services required for an Admitted Telephony service class and an 588 Admitted Multimedia Conferencing Service Class. If preemption is in 589 view, as described in section 2.3.5.2 of [RFC4542], this provides the 590 tools for carrying out the preemption. If preemption is not in view, 591 or in addition to preemptive services, the application of different 592 thresholds depending on call precedence has the effect of improving 593 the probability of call completion by admitting preferred calls at a 594 time that other calls are being refused. Routine and priority 595 traffic can be admitted using the same DSCP value, as the choice of 596 which calls are admitted is handled in the admission procedure 597 executed in the control plane, not the policing of the data plane. 599 On the point of what protocols and procedures are required for 600 authentication, authorization, and capacity admission, we note that 601 clear standards do not at this time exist for bandwidth brokers, NSIS 602 has not at this time been finalized and in any event is limited to 603 unicast sessions, and that RSVP has been standardized and has the 604 relevant services. We therefore recommend the use of RSVP at the 605 UNI. Procedures at the NNI are business matters to be discussed 606 between the relevant networks, and are recommended but not required. 608 4. IANA Considerations 610 This note requests that IANA assign a DSCP value to a second EF 611 traffic class consistent with [RFC3246] and [RFC3247]. It implements 612 the Telephony Service Class described in [RFC4594] at lower speeds 613 and is included in the Real Time Treatment Aggregate 614 [I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The 615 recommended value for the code point 101101, paralleling the EF code 616 point, which is 101110, and is allocated from the pool set aside for 617 experimental use but potentially available for standards use as well 618 in [RFC2474]. The code point should be referred to as VOICE-ADMIT. 620 This traffic class requires the use of capacity admission such as 621 RSVP services together with AAA services at the User/Network 622 Interface (UNI); the use of such services at the NNI is at the option 623 of the interconnected networks. 625 5. Security Considerations 627 A major requirement of this service is effective use of a signaling 628 protocol such as RSVP, with the capabilities to identify its user 629 either as an individual or as a member of some corporate entity, and 630 assert a policy such as "routine" or "priority". 632 This capability, one has to believe, will be abused by script kiddies 633 and others if the proof of identity is not adequately strong or if 634 policies are written or implemented improperly by the carriers. This 635 goes without saying, but this section is here for it to be said... 637 6. Acknowledgements 639 Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3. 640 Georgios Karagiannis offered additional comments on the same section. 641 The impetus for including Video in the discussion, which initially 642 only targeted voice, is from Dave McDysan, and text he suggested was 643 included. 645 7. References 646 7.1. Normative References 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 652 "Definition of the Differentiated Services Field (DS 653 Field) in the IPv4 and IPv6 Headers", RFC 2474, 654 December 1998. 656 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 657 J., Courtney, W., Davari, S., Firoiu, V., and D. 658 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 659 Behavior)", RFC 3246, March 2002. 661 7.2. Informative References 663 [I-D.briscoe-tsvwg-cl-architecture] 664 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 665 Congestion Notification: Admission Control over a 666 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 667 (work in progress), October 2006. 669 [I-D.briscoe-tsvwg-cl-phb] 670 Briscoe, B., "Pre-Congestion Notification marking", 671 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 672 October 2006. 674 [I-D.chan-pcn-problem-statement] 675 Chan, K., "Pre-Congestion Notification Problem Statement", 676 draft-chan-pcn-problem-statement-01 (work in progress), 677 October 2006. 679 [I-D.charny-pcn-single-marking] 680 Charny, A., "Pre-Congestion Notification Using Single 681 Marking for Admission and Termination", 682 draft-charny-pcn-single-marking-02 (work in progress), 683 July 2007. 685 [I-D.ietf-tsvwg-diffserv-class-aggr] 686 Chan, K., Babiarz, J., and F. Baker, "Aggregation of 687 DiffServ Service Classes", 688 draft-ietf-tsvwg-diffserv-class-aggr-07 (work in 689 progress), November 2007. 691 [I-D.morita-tsvwg-pps] 692 Morita, N. and G. Karlsson, "Framework of Priority 693 Promotion Scheme", draft-morita-tsvwg-pps-01 (work in 694 progress), October 2003. 696 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 697 Services in the Internet Architecture: an Overview", 698 RFC 1633, June 1994. 700 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 701 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 702 Functional Specification", RFC 2205, September 1997. 704 [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, 705 M., Romanow, A., Weinrib, A., and L. Zhang, "Resource 706 ReSerVation Protocol (RSVP) Version 1 Applicability 707 Statement Some Guidelines on Deployment", RFC 2208, 708 September 1997. 710 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 711 and W. Weiss, "An Architecture for Differentiated 712 Services", RFC 2475, December 1998. 714 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 715 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 716 D. Spence, "AAA Authorization Framework", RFC 2904, 717 August 2000. 719 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 720 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 721 Felstaine, "A Framework for Integrated Services Operation 722 over Diffserv Networks", RFC 2998, November 2000. 724 [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 725 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 726 Ramakrishnan, "Supplemental Information for the New 727 Definition of the EF PHB (Expedited Forwarding Per-Hop 728 Behavior)", RFC 3247, March 2002. 730 [RFC3260] Grossman, D., "New Terminology and Clarifications for 731 Diffserv", RFC 3260, April 2002. 733 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 734 "Integration of Resource Management and Session Initiation 735 Protocol (SIP)", RFC 3312, October 2002. 737 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 738 Supporting Emergency Telecommunications Service (ETS) in 739 IP Telephony", RFC 4190, November 2005. 741 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 742 Device Requirements and Configuration", RFC 4504, 743 May 2006. 745 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency 746 Telecommunications Service (ETS) for Real-Time Services in 747 the Internet Protocol Suite", RFC 4542, May 2006. 749 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 750 Guidelines for DiffServ Service Classes", RFC 4594, 751 August 2006. 753 Authors' Addresses 755 Fred Baker 756 Cisco Systems 757 Santa Barbara, California 93117 758 USA 760 Phone: +1-408-526-4257 761 Email: fred@cisco.com 763 James Polk 764 Cisco Systems 765 Richardson, Texas 75082 766 USA 768 Phone: +1-817-271-3552 769 Email: jmpolk@cisco.com 771 Martin Dolly 772 AT&T Labs 773 Middletown Township, New Jersey 07748 774 USA 776 Phone: +1-732-420-4574 777 Email: mdolly@att.com 779 Full Copyright Statement 781 Copyright (C) The IETF Trust (2007). 783 This document is subject to the rights, licenses and restrictions 784 contained in BCP 78, and except as set forth therein, the authors 785 retain all their rights. 787 This document and the information contained herein are provided on an 788 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 789 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 790 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 791 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 792 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 793 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 795 Intellectual Property 797 The IETF takes no position regarding the validity or scope of any 798 Intellectual Property Rights or other rights that might be claimed to 799 pertain to the implementation or use of the technology described in 800 this document or the extent to which any license under such rights 801 might or might not be available; nor does it represent that it has 802 made any independent effort to identify any such rights. Information 803 on the procedures with respect to rights in RFC documents can be 804 found in BCP 78 and BCP 79. 806 Copies of IPR disclosures made to the IETF Secretariat and any 807 assurances of licenses to be made available, or the result of an 808 attempt made to obtain a general license or permission for the use of 809 such proprietary rights by implementers or users of this 810 specification can be obtained from the IETF on-line IPR repository at 811 http://www.ietf.org/ipr. 813 The IETF invites any interested party to bring to its attention any 814 copyrights, patents or patent applications, or other proprietary 815 rights that may cover technology that may be required to implement 816 this standard. Please address the information to the IETF at 817 ietf-ipr@ietf.org. 819 Acknowledgment 821 Funding for the RFC Editor function is provided by the IETF 822 Administrative Support Activity (IASA).