idnits 2.17.1 draft-ietf-tsvwg-admitted-realtime-dscp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 and authors Copyright Line does not match the current year == Line 333 has weird spacing: '...olicers pri...' == Line 356 has weird spacing: '...olicers pri...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. (Using the creation date from RFC4542, updated by this document, for RFC5378 checks: 2005-02-08) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5162 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 (~~), 4 warnings (==), 5 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: Sept 8, 2010 March 8, 2010 9 DSCP for Capacity-Admitted Traffic 10 draft-ietf-tsvwg-admitted-realtime-dscp-07 12 Abstract 14 This document requests one Differentiated Services Code Point (DSCP) 15 from the Internet Assigned Numbers Authority (IANA) for a class of 16 real-time traffic. This class conforms to the Expedited Forwarding 17 Per Hop Behavior. It is also admitted using a CAC procedure 18 involving authentication, authorization, and capacity admission. 19 This differs from a real-time traffic class conforming to the 20 Expedited Forwarding Per Hop Behavior but not subject to capacity 21 admission or subject to very coarse capacity admission. 23 Legal 25 This documents and the information contained therein are provided on 26 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 27 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 28 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 29 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 30 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 31 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 32 FOR A PARTICULAR PURPOSE. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with 37 the provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on September 8, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 93 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 94 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6 95 2. Candidate Implementations of the Admitted Telephony 96 Service Class . . . . . . . . . . . . . . . . . . . . . . . 7 97 2.1. Potential implementations of EF in this model . . . . . . 7 98 2.2. Capacity admission control . . . . . . . . . . . . . . . 8 99 2.3. Recommendations on implementation of an Admitted 100 Telephony Service Class . . . . . . . . . . . . . . . . . 10 101 3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 10 102 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 103 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 106 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 107 7.2. Informative References . . . . . . . . . . . . . . . . . 12 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 110 1. Introduction 112 This document requests one Differentiated Services Code Point (DSCP) 113 from the Internet Assigned Numbers Authority (IANA) for a class of 114 real-time traffic. This class conforms to the Expedited Forwarding 115 [RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a 116 CAC procedure involving authentication, authorization, and capacity 117 admission. This differs from a real-time traffic class conforming 118 to the Expedited Forwarding Per Hop Behavior but not subject to 119 capacity admission or subject to very coarse capacity admission. 121 It also recommends that certain classes of video described in 122 [RFC4594] be treated as requiring capacity admission as well. 124 Real-time traffic flows have one or more potential congestion points 125 between the endpoints. Reserving capacity for these flows is 126 important to application performance. All of these applications 127 have low tolerance to jitter (aka delay variation) and loss, as 128 summarized in Section 2, and most (except for multimedia 129 conferencing) have inelastic flow behavior from Figure 1 of 130 [RFC4594]. Inelastic flow behavior and low jitter/loss tolerance 131 are the service characteristics that define the need for admission 132 control behavior. 134 One of the reasons behind this is the need for classes of traffic 135 that are handled under special policies. Service providers need to 136 distinguish between special-policy traffic and other classes, 137 particularly the existing VoIP services that perform no capacity 138 admission or only very coarse capacity admission and can exceed 139 their allocated resources. 141 The requested DSCP applies to the Telephony Service Class described 142 in [RFC4594]. 144 Since video classes have not had the history of mixing admitted and 145 non-admitted traffic in the same Per-Hop Behavior (PHB) as has 146 occurred for EF, an additional DSCP code point is not recommended 147 within this document for video. Instead, the recommended "best 148 practice" is to perform admission control for all traffic in three 149 of [RFC4594]'s video classes: the 151 o Interactive Real-Time Traffic (CS4, used for Video conferencing 152 and Interactive gaming), 154 o Broadcast TV (CS3) for use in a video on demand context, and 155 o AF4 Multimedia Conferencing (video conferencing). 157 Other video classes are believed to not have the current problem of 158 confusion with unadmitted traffic and therefore would not benefit 159 from the notion of a separate DSCP for admitted traffic. Within an 160 ISP and on inter-ISP links (i.e. within networks whose internal 161 paths are uniform at hundreds of megabits per second or faster), one 162 would expect all of this traffic to be carried in the Real-Time 163 Traffic (RTP) Class described in [RFC5127]. 165 1.1. Definitions 167 The following terms and acronyms are used in this document. 169 PHB: A Per-Hop-Behavior (PHB) is the externally observable 170 forwarding behavior applied at a Differentiated Services 171 compliant node to a DS behavior aggregate [RFC2475]. It may be 172 thought of as a program configured on the interface of an 173 Internet host or router, specified in terms of drop 174 probabilities, queuing priorities or rates, and other handling 175 characteristics for the traffic class. 177 DSCP: The Differentiated Services Code Point (DSCP), as defined in 178 [RFC2474], is a value which is encoded in the DS field, and which 179 each DS Node MUST use to select the PHB which is to be 180 experienced by each packet it forwards [RFC3260]. It is a 6-bit 181 number embedded into the 8-bit TOS field of an IPv4 datagram or 182 the Traffic Class field of an IPv6 datagram. 184 CAC: Call Admission Control includes concepts of authorization and 185 capacity admission. "Authorization" refers to any procedure that 186 identifies a user, verifies the authenticity of the 187 identification, and determines whether the user is authorized to 188 use the service under the relevant policy. "Capacity Admission" 189 refers to any procedure that determines whether capacity exists 190 supporting a session's requirements under some policy. 192 In the Internet, these are separate functions, while in the PSTN 193 they and call routing are carried out together. 195 UNI: A User/Network Interface (UNI) is the interface (often a 196 physical link or its virtual equivalent) that connects two 197 entities that do not trust each other, and in which one (the 198 user) purchases connectivity services from the other (the 199 network). 201 Figure 1 shows two user networks connected by what appears to 202 each of them to be a single network ("The Internet", access to 203 which is provided by their service provider) that provides 204 connectivity services to other users. 206 UNIs tend to be the bottlenecks in the Internet, where users 207 purchase relatively low amounts of bandwidth for cost or service 208 reasons, and as a result are most subject to congestion issues 209 and therefore issues requiring traffic conditioning and service 210 prioritization. 212 NNI: A Network/Network Interface (NNI) is the interface (often a 213 physical link or its virtual equivalent) that connects two 214 entities that trust each other within limits, and in which the 215 two are seen as trading services for value. Figure 1 shows three 216 service networks that together provide the connectivity services 217 that we call "the Internet". They are different administrations 218 and are very probably in competition, but exchange contracts for 219 connectivity and capacity that enable them to offer specific 220 services to their customers. 222 NNIs may not be bottlenecks in the Internet if service providers 223 contractually agree to provision excess capacity at them, as they 224 commonly do. However, NNI performance may differ by ISP, and the 225 performance guarantee interval may range from a month to a much 226 shorter period. Furthermore, a peering point NNI may not have 227 contractual performance guarantees or may become overloaded under 228 certain conditions. They are also policy-controlled interfaces, 229 especially in BGP. As a result, they may require traffic 230 prioritization policy. 232 Queue: There are multiple ways to build a multi-queue scheduler. 233 Weighted Round Robin (WRR) literally builds multiple lists and 234 visits them in a specified order, while a calendar queue (often 235 used to implement Weighted Fair Queuing, or WFQ) builds a list 236 for each time interval and queues at most a stated amount of data 237 in each such list for transmission during that time interval. 238 While these differ dramatically in implementation, the external 239 difference in behavior is generally negligible when they are 240 properly configured. Consistent with the definitions used in the 241 Differentiated Services Architecture [RFC2475], these are treated 242 as equivalent in this document, and the lists of WRR and the 243 classes of a calendar queue will be referred to uniformly as 244 "queues". 246 _.--------. 247 ,-'' `--. 248 ,-' `-. 249 ,-------. ,',-------. `. 250 ,' `. ,',' `. `. 251 / User \ UNI / / Service \ \ 252 ( Network +-----+ Network ) `. 253 \ / ; \ / : 254 `. ,' ; `. .+ : 255 '-------' / '-------' \ NNI \ 256 ; \ : 257 ; "The Internet" \ ,-------. : 258 ; +' `. : 259 UNI: User/Network Interface / Service \ | 260 | ( Network ) | 261 NNI: Network/Network Interface \ / | 262 : +. ,' ; 263 : / '-------' ; 264 : / ; 265 ,-------. \ ,-------. / NNI / 266 ,' `. : ,' `+ ; 267 / User \ UNI / Service \ ; 268 ( Network +-----+ Network ) ,' 269 \ / \ \ / / 270 `. ,' `.`. ,' ,' 271 '-------' `.'-------' ,' 272 `-. ,-' 273 `--. _.-' 274 `--------'' 276 Figure 1: UNI and NNI interfaces 278 1.2. Problem 280 In short, the Telephony Service Class described in [RFC4594] permits 281 the use of capacity admission in implementing the service, but 282 present implementations either provide no capacity admission 283 services or do so in a manner that depends on specific traffic 284 engineering. In the context of the Internet backbone, the two are 285 essentially equivalent; the edge network depends on specific 286 engineering by the service provider that might not be present, 287 especially in a mobile environment. 289 However, services are being requested of the network that would 290 specifically make use of capacity admission, and would distinguish 291 among users or the uses of available Voice-over-IP or Video-over-IP 292 capacity in various ways. Various agencies would like to provide 293 services as described in section 2.6 of [RFC4504] or in [RFC4190]. 295 This requires the use of capacity admission to differentiate among 296 users to provide services to them that are not afforded to 297 non-capacity admitted customer-to-customer IP telephony sessions. 299 2. Candidate Implementations of the Admitted Telephony Service Class 301 2.1. Potential implementations of EF in this model 303 There are at least two possible ways to implement isolation between 304 the Capacity Admitted PHB and the Expedited Forwarding PHB in this 305 model. They are to implement separate classes as a set of 307 o Multiple data plane traffic classes, each consisting of a policer 308 and a queue, and the queues enjoying different priorities, or 310 o Multiple data plane traffic classes, each consisting of a policer 311 but feeding into a common queue or multiple queues at the same 312 priority. 314 We will explain the difference, and describe in what way they differ 315 in operation. The reason this is necessary is that there is current 316 confusion in the industry. 318 The multi-priority model is shown in Figure 2. In this model, 319 traffic from each service class is placed into a separate priority 320 queue. If data is present in more than one queue, traffic from one 321 of them will always be selected for transmission. This has the 322 effect of transferring jitter from the higher priority queue to the 323 lower priority queues, and reordering traffic in a way that gives 324 the higher priority traffic a smaller average queuing delay. Each 325 queue must have its own policer, however, to protect the network 326 from errors and attacks; if a traffic class thinks it is carrying a 327 certain data rate but an abuse sends significantly more, the effect 328 of simple prioritization would not preserve the lower priorities of 329 traffic, which could cause routing to fail or otherwise impact an 330 SLA. 332 . 333 policers priorities |`. 334 Admitted EF <=> ----------||----+ `. 335 high| `. 336 Unadmitted EF <=> ----------||----+ .'----------- 337 . medium .' 338 rate queues |`. +-----+ .' Priority 339 AF1------>||----+ `. / low |' Scheduler 340 | `. / 341 AF2------>||----+ .'-+ 342 | .' 343 CS0------>||----+ .' Rate Scheduler 344 |' (WFQ, WRR, etc) 346 Figure 2: Implementation as a data plane priority 348 The multi-policer model is shown in Figure 3. In this model, 349 traffic from each service class is policed according to its SLA 350 requirements, and then placed into a common priority queue. Unlike 351 the multi-priority model, the jitter experienced by the traffic 352 classes in this case is the same, as there is only one queue, but 353 the sum of the traffic in this higher priority queue experiences 354 less average jitter than the elastic traffic in the lower priority. 356 policers priorities . 357 Admitted EF <=> -------\ |`. 358 --||----+ `. 359 Unadmitted EF <=> -------/ high| `. 360 . | .'-------- 361 rate queues |`. +-----+ .' 362 AF1------>||----+ `. / low | .' Priority 363 | `. / |' Scheduler 364 AF2------>||----+ .'-+ 365 | .' 366 CS0------>||----+ .' Rate Scheduler 367 |' (WFQ, WRR, etc) 369 Figure 3: Implementation as a data plane policer 371 The difference between the two operationally is, as stated, the 372 issues of loss due to policing and distribution of jitter. 374 If the two traffic classes are, for example, voice and video, 375 datagrams containing video data can be relatively large (often of 376 variable sizes up to the path MTU) while datagrams containing voice 377 are relatively small, on the order of only 40 to 200 bytes, 378 depending on the codec. On lower speed links (less than 10 MBPS), 379 the jitter introduced by video to voice can be disruptive, while at 380 higher speeds the jitter is nominal compared to the jitter 381 requirements of voice. At access network speeds, therefore, 382 [RFC4594] recommends separation of video and voice into separate 383 queues, while at optical speeds [RFC5127] recommends that they use a 384 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 at least six major ways that capacity admission is done or 395 has been proposed to be done for real-time applications. Each will 396 be described below, then Section 3 will judge which ones are likely 397 to meet the requirements of the Admitted Telephony service class. 398 These include: 400 o Drop Precedence used to force sessions to voluntarily exit, 402 o Capacity admission control by assumption or engineering, 404 o Capacity admission control by call counting, 406 o End-point capacity admission performed by probing the network, 408 o Centralized capacity admission control via bandwidth broker, and 410 o Distributed capacity admission control using protocols such as 411 RSVP or NSIS. 413 The problem with dropping traffic to force users to hang up is that 414 it affects a broad class of users - if there is capacity for N calls 415 and the N+1 calls are active, data is dropped randomly from all 416 sessions to ensure that offered load doesn't exceed capacity. On 417 very fast links, that is acceptable, but on lower speed links it can 418 seriously affect call quality. There is also a behavioral issue 419 involved here, in which users who experience poor quality calls tend 420 to hang up and call again, making the problem better - then worse. 422 The problem with capacity admission by assumption, which is widely 423 deployed in today's VoIP environment, is that it depends on the 424 assumptions made. One can do careful traffic engineering to ensure 425 needed bandwidth, but this can also be painful, and has to be 426 revisited when the network is changed or network usage changes. 428 The problem with call counting based admission control is it gets 429 exponentially worse the farther you get from the control point 430 (e.g., it lacks sufficient scalability out into the network). 432 There are two fundamental problems with depending on the endpoint to 433 perform capacity admission; it may not be able to accurately measure 434 the impact of the traffic it generates on the network, and it tends 435 to be greedy (e.g., it doesn't care). If the network operator is 436 providing a service, he must be able to guarantee the service, which 437 means that he cannot trust systems that are not controlled by his 438 network. 440 The problem with capacity controls via a bandwidth broker is 441 centralized servers lack far away awareness, and also lack effective 442 real-time reaction to dynamic changes in all part of the network 443 at all instances of time. 445 The problem with mechanisms that do not enable the association of a 446 policy with the request is that they do not allow for multi-policy 447 services, which are becoming important. 449 The operator's choice of admission procedure MUST, for this DSCP, 450 ensure the following: 452 o The actual links that a session uses have enough bandwidth to 453 support it. 455 o New sessions are refused admission if there is inadequate 456 bandwidth under the relevant policy. 458 o If multiple policies are in use in a network, that the user is 459 identified and the correct policy applied. 461 o Under periods of network stress, the process of admission of new 462 sessions does not disrupt existing sessions, unless the service 463 explicitly allows for disruption of calls. 465 2.3. Recommendations on implementation of an Admitted Telephony 466 Service Class 468 When coupled with adequate AAA and capacity admission procedures as 469 described in Section 2.2, either of the two PHB implementations 470 described in Section 2.1 is sufficient to provide the services 471 required for an Admitted Telephony service class. If preemption is 472 required, as described in section 2.3.5.2 of [RFC4542], this 473 provides the tools for carrying out the preemption. If preemption is 474 not in view, or if used in addition to preemptive services, the 475 application of different thresholds depending on call precedence has 476 the effect of improving the probability of call completion by 477 admitting preferred calls at a time that other calls are being 478 refused. Routine and priority traffic can be admitted using the 479 same DSCP value, as the choice of which calls are admitted is 480 handled in the admission procedure executed in the control plane, 481 not the policing of the data plane. 483 On the point of what protocols and procedures are required for 484 authentication, authorization, and capacity admission, we note that 485 clear standards do not exist at this time for bandwidth brokers, 486 NSIS has not been finalized at this time and in any event is limited 487 to unicast sessions, and that RSVP has been standardized and has the 488 relevant services. We therefore RECOMMEND the use of a protocol, 489 such as RSVP, at the UNI. Procedures at the NNI are business 490 matters to be discussed between the relevant networks, and are 491 I RECOMMENDED but NOT REQUIRED. 493 3. Summary: changes from RFC 4594 495 To summarize, there are two changes to [RFC4594] discussed in this 496 document: 498 Telephony class: The Telephony Service Class in RFC 4594 does not 499 involve capacity admission, but depends on application layer 500 admission that only estimates capacity, and that through static 501 engineering. In addition to that class, a separate Admitted 502 Telephony Class is added which performs capacity admission 503 dynamically. 505 Video classes: Capacity admission is added to three video classes. 506 These are the Interactive Real-Time Traffic class, Broadcast TV 507 class when used for video on demand, and the Multimedia 508 Conferencing class. 510 4. IANA Considerations 512 This note requests that IANA assign a DSCP value to a second EF 513 traffic class consistent with [RFC3246] and [RFC3247] in the 514 "Differentiated Services Field Codepoints" registry. It implements 515 the Telephony Service Class described in [RFC4594] at lower speeds 516 and is included in the Real Time Treatment Aggregate [RFC5127] at 517 higher speeds. The recommended code point value should be from pool 518 1 within the dscp-registry. This document RECOMMENDS retaining a 519 parallel with the existing EF code point (101110) by assigning a 520 value for the code point of 101100 -- keeping the (left to right) 521 first 4 binary values the same in both. The code point described 522 within this document should be referred to as VOICE-ADMIT. Here is 523 the recommended addition to the Pool 1 Codepoint registry: 525 Sub-registry: Pool 1 Codepoints 526 Reference: [RFC2474] 527 Registration Procedures: Standards Action 529 Registry: 530 Name Space Reference 531 --------- ------- --------- 532 VOICE-ADMIT 101100 [this document] 534 This traffic class REQUIRES the use of capacity admission, such as 535 RSVP services together with AAA services, at the User/Network 536 Interface (UNI); the use of such services at the NNI is at the 537 option of the interconnected networks. 539 5. Security Considerations 541 A major requirement of this service is effective use of a signaling 542 Protocol, such as RSVP, with the capabilities to identify its user 543 either as an individual or as a member of some corporate entity, and 544 assert a policy such as "normal", "routine" or some level of 545 "priority". 547 This capability, one has to believe, will be abused by script 548 kiddies and others if the proof of identity is not adequately strong 549 or if policies are written or implemented improperly by the 550 carriers. This goes without saying, but this section is here for it 551 to be said... 553 Much of the security considerations from RFC 3246 [RFC3246] applies 554 to this document, as well as the security considerations in RFC 555 2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some 556 gap analysis to the NSIS WG as they started their work. Keep in mind 557 that this document is advocating RSVP at the UNI only, while RFC 558 4230 discusses (mostly) RSVP from a more complete point of view 559 (i.e., e2e and edge2edge). When considering the RSVP aspect of this 560 document, understanding Section 6 of RFC 4230 is a good source of 561 information. 563 6. Acknowledgements 565 Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe 566 commented and offered text. The impetus for including Video in the 567 discussion, which initially only targeted voice, is from Dave 568 McDysan. 570 7. References 572 7.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 578 "Definition of the Differentiated Services Field (DS 579 Field) in the IPv4 and IPv6 Headers", RFC 2474, 580 December 1998. 582 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 583 J., Courtney, W., Davari, S., Firoiu, V., and D. 584 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 585 Behavior)", RFC 3246, March 2002. 587 7.2. Informative References 589 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 590 and W. Weiss, "An Architecture for Differentiated 591 Services", RFC 2475, December 1998. 593 [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 594 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 595 Ramakrishnan, "Supplemental Information for the New 596 Definition of the EF PHB (Expedited Forwarding Per-Hop 597 Behavior)", RFC 3247, March 2002. 599 [RFC3260] Grossman, D., "New Terminology and Clarifications for 600 Diffserv", RFC 3260, April 2002. 602 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 603 Supporting Emergency Telecommunications Service (ETS) in 604 IP Telephony", RFC 4190, November 2005. 606 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 607 Device Requirements and Configuration", RFC 4504, 608 May 2006. 610 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency 611 Telecommunications Service (ETS) for Real-Time Services 612 in the Internet Protocol Suite", RFC 4542, May 2006. 614 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 615 Guidelines for DiffServ Service Classes", RFC 4594, 616 August 2006. 618 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 619 DiffServ Service Classes", RFC 5127, February 2008. 621 [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", 622 RFC4230, December 2005 624 Authors' Addresses 626 Fred Baker 627 Cisco Systems 628 Santa Barbara, California 93117 629 USA 631 Phone: +1-408-526-4257 632 Email: fred@cisco.com 634 James Polk 635 Cisco Systems 636 Richardson, Texas 75082 637 USA 639 Phone: +1-817-271-3552 640 Email: jmpolk@cisco.com 642 Martin Dolly 643 AT&T Labs 644 Middletown Township, New Jersey 07748 645 USA 647 Phone: +1-732-420-4574 648 Email: mdolly@att.com