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