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